你让一个 AI Agent：“帮我研究一下竞争对手，整理成一份可以给老板看的报告。”
十分钟后，它返回了一份文档：列出了五家公司，简单介绍了产品和价格，最后告诉你：“任务已完成。”
但你打开一看，真正想要的市场定位、差异化、增长策略、风险判断，一个都没有。
Agent 没有偷懒。它甚至可能严格执行了自己理解的任务。
问题在于：它认为的“完成”，和你认为的“完成”，从一开始就不是同一件事。
这也是 Agent 系统里一个经常被低估的问题：在让模型拥有更多工具、更长上下文和更强执行能力之前，我们可能更应该先回答一个基础问题——什么叫做成功？
Agent 最大的风险，不一定是做错，而是过早宣布做完
传统聊天机器人答错了，我们很容易发现。
Agent 更麻烦。
因为 Agent 会自己拆解任务、搜索信息、调用工具、写文件、修改代码，甚至连续工作很多步骤。执行链条越长，“看起来做了很多事”和“真正完成目标”之间的差距就越大。
假设你对一个编程 Agent 说：
修复用户无法重置密码的问题。
Agent 找到一个报错，修改代码，单元测试通过，于是宣布完成。
但用户真正关心的可能包括：
-
重置邮件能不能收到；
-
链接是否会过期；
-
手机端流程是否正常；
-
已过期链接有没有正确提示；
-
修改密码后旧 Session 是否失效。
如果 Agent 的成功标准只是“测试通过”，它完全可能在完成 20% 的真实任务后，就合理地认为自己已经完成了 100%。
所以，Success Criteria 的作用并不是给 Agent 增加一张形式化清单。
它真正解决的是一个更根本的问题：
把模糊的用户意图，转换成可以判断是否完成的条件。
没有这一步，Agent 越自主，风险反而可能越大。
Success Criteria 应该在执行前明确，但不必一开始就完全固定
一个常见问题是：Agent 在开始工作前，是不是必须先把 Success Criteria 全部定义清楚？
我认为，大多数复杂任务应该有，但不必追求“一次定义完毕”。
简单任务没必要过度设计。
比如：
把这个 PDF 转成 Markdown。
成功标准非常直接：内容被转换、结构基本保留、文件能够打开。
但如果任务变成：
帮我设计一套新的会员增长方案。
这时直接执行就很危险。
什么叫“好的增长方案”？
是提高注册量，还是付费率？目标人群是谁？预算有没有限制？允许打折吗？三个月见效还是一年见效？
这些问题没有澄清，Agent 只能自己补全。
而 Agent 自动补全需求，恰恰是很多失败的开始。
更合理的方式，是把 Success Criteria 看成分层结构。
第一层是目标结果。
例如：“形成一套管理层可以用于决策的竞争分析。”
第二层是可验证条件。
例如：覆盖主要竞争者、比较产品与价格、说明差异化、分析风险，并给出明确结论。
第三层是约束条件。
例如：不能虚构数据，无法验证的信息必须标注，最终输出不超过十页。
这样，Agent 才不仅知道“做什么”，还知道“做到什么程度可以停”。
Success Criteria 不应该只由用户生成
要求用户自己写完整 Success Criteria，听起来合理，实际并不现实。
用户经常知道自己想解决什么问题，却不知道一个高质量结果应该包含哪些部分。
比如一个创业者可能会说：
帮我看看这个市场值不值得做。
他未必会主动提出：
竞争格局是什么？客户是谁？需求是否足够强？进入壁垒在哪里？商业模式是否成立？最关键的不确定性是什么？
这些恰恰应该由 Agent 帮忙补出来。
因此，更好的机制是共同生成。
用户提供目标、偏好和约束。
Agent 根据任务类型，把模糊目标转换成更具体的验收条件。
必要时，再通过工具、测试程序、规则系统或者另一个模型进行独立验证。
可以想象一个 Research Agent 接到：
调研三家公司的 AI 产品策略。
它可以自动推导出一组初始标准：
需要覆盖三家公司；每家公司都包含产品、目标用户、商业模式和战略方向；重要判断需要来源支持；最后进行横向比较；无法确认的内容不能写成确定事实。
这些标准不是用户逐字写出来的，却明显更接近用户真正需要的结果。
因此，Success Criteria 最合理的来源，并不是“用户还是模型”二选一。
而是：
用户定义什么值得成功，Agent 定义如何证明成功。
Success Criteria 可以修改，但不能偷偷修改
执行过程中，成功标准发生变化非常正常。
Agent 搜索资料后，可能发现原来的任务无法完成。
例如用户要求：
比较五家公司的最新收入数据。
执行后发现，其中两家公司并不公开相关数据。
这时坚持原标准，只会逼着系统走向两个糟糕结果：无限搜索，或者编造答案。
合理的 Agent 应该允许修改 Success Criteria。
比如变成：
“对公开数据完整的公司进行收入比较，其余公司使用能够验证的业务指标，并明确说明数据限制。”
问题不在于能不能改，而在于谁有权改，以及修改是否透明。
如果 Agent 为了让自己更容易完成任务，悄悄把：
“完成一份可以上线的功能”
改成：
“完成核心代码”
那 Success Criteria 就失去了意义。
因此，动态修改至少需要满足一个原则：
标准可以因为新信息而调整，但不能为了宣布完成而降低。
影响较小的调整，Agent 可以自行处理。
改变核心目标、明显降低质量或者放弃关键交付物，则应该重新获得用户确认。
这和项目管理很像。计划可以变，但不能项目做到一半，团队自己把验收标准删掉，然后宣布成功。
判断是否完成，不能只问 Agent 自己
这里有一个很容易忽略的问题：
如果执行任务的是同一个模型，判断“我是否完成”的也是这个模型，那么它既是运动员，又是裁判。
这很容易产生完成偏差。
Agent 做了大量工作后，会倾向于寻找支持“任务已经完成”的证据，而不是主动寻找缺失项。
所以，高可靠 Agent 需要把“执行”和“验收”适度分开。
最简单的方法，是在结束前进行一次 Completion Check。
不是问：
任务完成了吗？
而是逐条询问：
每一条 Success Criteria 对应的证据是什么？
比如一份市场研究要求：
覆盖五家公司。
那就应该明确列出五家公司。
要求每家公司分析定价。
那就检查五家公司是否都有定价信息，缺失的是否标注。
要求给出建议。
那最终文档中必须存在可以直接被识别为建议的内容，而不是让模型觉得“前面的分析已经暗含了建议”。
这背后有一个很重要的设计变化：
“完成”不应该是一种感觉，而应该是一组可以被检查的状态。
在软件里，这可以是测试。
在研究任务里，可以是证据和引用。
在文件操作里，可以验证文件是否真实存在、是否能打开。
在沟通任务里，可以检查消息是否真正发送，而不是只生成了草稿。
越能把 Success Criteria 转成外部可验证的信号，模型对“完成”的判断就越可靠。
防止 Agent 做了一半就停，需要一个“完成账本”
复杂任务还有一种常见失败：Agent 正确完成了其中几个步骤，然后忘记了剩余部分。
例如任务是：
找出 20 个潜在客户，筛选其中最合适的 10 个，找到负责人联系方式，写个性化邮件，并保存到 CRM。
Agent 可能成功找到 20 家公司，又筛选了 10 家，随后因为上下文变长，直接开始总结：
“已经完成潜在客户研究和筛选。”
从局部看，它没说错。
从用户目标看，任务只完成了一半。
解决这个问题，一个实用方法是维护一个显式的 Done Ledger，也就是完成账本。
它记录的不是 Agent “做过什么”，而是每一项成功标准现在处于什么状态：
未开始、进行中、已完成、受阻、需要用户确认。
这样，Agent 在结束之前不是回忆自己做了多少工作，而是检查：
还有没有 Success Criteria 处于未完成状态？
如果还有，就不能输出“任务完成”。
最多只能说：
“目前完成了其中 4 项，剩余 2 项因缺少权限而受阻。”
这两个表达看起来只差一句话，实际代表完全不同的 Agent 行为哲学。
前者围绕“我做了什么”。
后者围绕“用户要的结果实现了吗”。
而真正可靠的 Agent，应该始终站在第二个视角。
好的 Agent，不只是会执行，还应该知道什么时候不能停
我们经常把 Agent 能力理解成：会规划、会调用工具、会搜索、会写代码、会操作软件。
但随着 Agent 能够承担越来越长的任务，“停止条件”会变得和“执行能力”一样重要。
一个成熟的 Agent，在开始前应该形成初始 Success Criteria；执行过程中根据新信息透明地调整；结束前逐项验证，并拿出能够证明完成的证据。
如果做不到，就应该明确告诉用户哪里完成了，哪里没有完成，以及为什么。
以后设计一个 Agent 时，可以先不要问：
“它还需要什么工具？”
先问一个更简单的问题：
当它说“完成了”的时候，我们凭什么相信它真的完成了？
如果这个问题没有答案，那么再强的执行能力，也只是让 Agent 更快地抵达一个它自己定义的终点。
