你让一个 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 更快地抵达一个它自己定义的终点。