一句话：智能体翻车，锅常常不在模型，在你给的目标太大。LangChain 在博客里提出一个叫 goal engineering（目标工程）的理念——设计智能体目标时，核心度量不是「说得清不清楚」，而是「人类反馈容易不容易给」。目标切得越窄，反馈越便宜，智能体纠错越快。
反馈易度：一个被忽略的度量
我们习惯用「指令明确不明确」来衡量任务下发质量，但 LangChain 的说法更狠：就算指令字面清楚，只要反馈成本高，智能体照样跑偏。判断标准就一条——出错之后，你能不能十秒内说出「对」还是「不对」。能，目标就是好的；要查半小时资料才能判断，目标就是坏的。
这里有个常被忽略的账：反馈不是免费的。你每判断一次「不对」，都要花自己的时间；目标越宽，你花的判断时间越多，很快就没人愿意一个个看了。智能体不是不聪明，是没人有空告诉它哪步错了。反馈贵到一定程度，等于没有反馈。
说白了，这不是措辞问题，是信息分布问题。智能体看到的上下文有限，而任务相关的隐性知识（tacit context）只存在于你脑子里：为什么这个页面要快、为什么这个按钮不能红。目标一宽，这些知识就进不了它的决策，出错时你自己也懒得细究——反馈就断了。
划重点：给智能体下任务前问自己一句，「它做错的时候，我判断成本多高？」高，就先切目标。
隐性上下文：专家脑子里的暗账
LangChain 指出的关键点：智能体出错，常源于缺乏只存在于专家脑中的隐性上下文。一个资深工程师看新同事的代码，三秒知道哪行有问题，因为他脑子里装着整个系统的历史包袱、过往踩坑、团队约定。这些东西没写进任何文档。
把这类任务直接丢给智能体，等于让一个陌生人裸考。它不会写出来的不是代码，是那层「为什么」：为什么这里要兼容旧接口、为什么这个字段不能改名。目标越大，需要隐性知识的环节越多，智能体蒙对的比例就越低。
我自己的判断：大多数「智能体不听话」的抱怨，本质是隐性上下文没显性化。与其骂模型笨，不如先把自己脑子里那层暗账摊开——哪怕只写三行注释，反馈链路就通了一半。
一个具体例子：优化网站 vs 首屏加载
假设你对智能体说「优化我们的网站」。它能做的动作有几百种：改文案、换配色、调路由、压图片、改数据库查询。它做了一版，你看完说「还行，感觉没变快」——这个反馈值多少钱？几乎为零。下次它还是不知道往哪使劲。
换成「把落地页首屏加载从 3.2 秒压到 2 秒以内」。现在反馈链路完全变了：它跑一次，测一下，数字说话。压没压到，十秒内可验证；没压到，错误定位也具体——是图片没懒加载，还是 JS 阻塞了渲染。每一步迭代都是便宜、明确、可累积的。
说白了，同一个任务，目标宽窄不同，智能体的「学习速度」差一个数量级。因为反馈价格变了：宽目标的反馈要么没有，要么贵到没人愿意给；窄目标的反馈是免费且自动的。
目标切太碎，会不会养出点子公司
但这里有个前提，也是我要泼的冷水。切目标不是越小越好。把「优化网站」切到「把这张图片压 2KB」，智能体确实能做完，但它永远不知道三张图之间的布局关系、不知道压缩后清晰度掉了对转化有什么影响——它被养成了点子公司：点哪一下，动一下。
我自己的判断：目标工程是个双刃尺度。切得太宽，反馈断掉；切得太碎，智能体丢失全局意图，产出局部正确但整体拧巴。合适的粒度是：单次可验证，但验证结果能指向全局目标的一个维度。就像「首屏加载 2 秒」——验证便宜，且服务于「网站体验」这个上位目标。
划重点：给智能体定目标，别问「我能拆多细」，问「拆完之后，它做完一件事能不能自己知道离目标近了多远」。能，粒度就对；不能，要么再合一层，要么给它一个看总表的权限。目标工程做到底，本质是给智能体修一条能看见自己坐标的路——路太宽它迷路，路太窄它走不出去，宽度刚好才跑得快。
说到底，LangChain 这套说法没有新模型、没有新算法，就是把「任务管理」这件老事重新标了价。模型越来越聪明，但反馈这条链没变。你的团队今天给智能体下任务的方式，和二十年前给外包下需求的方式，问题可能一模一样：需求一句「做个好点的」，验收一句「感觉不对」。
智能体只是把「感觉不对」的代价，从一周压缩到了十秒。用不用好，就看你愿不愿意在那十秒里，把话说清楚。
