我第一次认真思考 Agent 应该在哪里停下来，不是因为它做不了，而是因为它做得太顺了。
它能读来源材料、整理方案、填完表格，再把结果写进共享系统。最后一步改变了前面所有工作的性质。分析时，它还只是一个候选结果；写回以后，它就成了别人会相信、会继续使用的当前状态。
如果来源已经过时，或者某个字段还需要客户确认，错误就不再只留在聊天里。它会进入文档、表格、线上配置，以及后续的自动化。
做得到和有权做，是两个问题。
现在，我用四件事判断停在哪里：这次修改会影响多大范围、出错后有多容易撤回、证据有多确定，以及谁对结果负责。
风险不只在生成，更在于改变状态
起草文案通常风险较低，因为我可以不用。下面这些动作看起来都只是一次工具调用，后果却不一样：
- 覆盖共享事实源中的字段；
- 把草稿改成可以发送的版本；
- 创建或修改线上广告配置；
- 根据不完整的数据写下业务结论；
- 发出一条代表当前进展的消息。
它们会改变外部状态。其他人可能直接沿用结果，并不会看到 Agent 当时依据了什么。
我以前把格式正确和允许写入当成同一道检查。字段齐全、链接有效、API 返回成功，好像就够了。真实使用暴露了两者的差距：格式只能证明结果长得像预期的对象，不能证明事实仍然有效，也不能证明一个有争议的选择已经获得授权。
决定停止位置的四个问题
1. 这会影响谁？
本地候选稿影响的是操作者。更新团队记录、发给客户或者改变线上系统，影响范围就会迅速扩大。
| 层级 | 常见动作 | 默认处理方式 |
|---|---|---|
| 个人候选稿 | 起草、总结、准备备选方案 | Agent 可以自动完成 |
| 团队状态 | 更新共享表格、项目状态或知识库 | 写入前检查字段及负责人 |
| 外部结果 | 发给客户、上线广告或修改公开页面 | 核实明确授权是否覆盖该动作；只有出现新决定时才再询问 |
越多人会把结果当成事实，就越不能把 Agent 自己的判断当成授权。
2. 撤回错误的成本有多低？
可撤回不只是技术上能不能恢复，还要看恢复成本。
本地草稿可以丢弃。客户已经读过的消息，无法让他没看过。配置可以改回去，但期间可能已经产生了数据或费用。
一个动作越难撤回，确认就越应该靠近真正执行的时刻。
只要目标、允许修改的字段、限制和停止条件都明确，持续授权就可以覆盖重复工作。新的不可逆决定，需要先准备好具体结果供人审阅。对模糊方案的批准不能代替这个决定；但已有的有效授权，也不应导致每次运行都重复询问。
3. 这个决定依据的是证据，还是推测？
有些条件可以确定地检查：必填字段、字数限制、文件格式，以及链接是否可访问。
另一些决定依赖业务事实和上下文。这个主张有支持吗？空白代表零，还是无法取得数据？这是内部草稿，还是已经批准的交付物？
如果 Agent 必须靠推测跨过缺失材料，就应该把缺口说出来并停下。最危险的信号不一定是报错，而是一个没有证据、听起来却十分完整的结论。
4. 谁对最终结果负责？
负责人应该知道授权覆盖什么。他可以批准一份具体候选稿，也可以委托有边界的日常修改。当决定超出约定，Agent 再回来找他。
人工复核不应意味着重做 Agent 的工作。Agent 应该降低判断成本：给出来源、拟议修改、已完成的检查和仍然存在的不确定性。
复核者决定的是自己是否愿意为结果负责，而不是重新翻一遍原始材料。
使用工具的 Agent，可以分成三个阶段
- 读取和分析。 在允许的范围内收集证据，整理事实、冲突和候选方案。
- 准备修改。 做出即将写入的完整内容，运行确定性检查，并展示差异。
- 提交并回读。 获得批准后执行外部写入，再读取目标位置，核对实际结果。
已有授权范围内、低风险且可撤回的工作，可以自动走完三个阶段，包括已经允许的共享系统更新。只有任务跨过影响或责任边界，才需要人工介入。
好的人工确认不会把人塞回每一步。它只在确实需要人承担判断的地方停一次。
确认本身也是设计问题
只问一句“继续吗？”不够。确认请求应该展示：
- 当前采用的来源，以及核验时间；
- 即将新增、替换或发送的准确内容；
- 已完成的确定性检查；
- 未经核实的假设或缺失信息；
- 谁会受到影响，以及如何撤回。
没有回复不等于批准。超时不应悄悄触发高风险写入。如果这个动作确实需要授权，停下来就是正确行为。
哪些情况可以自动继续
以下条件都满足时，我通常允许完整执行：
- 目标、允许的动作和限制已经获得授权；
- 结果容易撤回，不会污染共享事实；
- 来源明确，也足够新；
- 可以用确定性检查验收；
- 失败会显露出来，不会被悄悄跳过；
- 系统会自动回读并验证结果。
起草未发送的消息、整理主题和检查链接，通常可以继续。明确授权修改一组约定的共享字段，也可以。发送一种新的消息、改变收件对象或超出预算，则是新的决定，即使调用的 API 很熟悉。
同一个委托任务，两种不同结果
以一个假设的每日价格检查为例。负责人允许系统从指定来源采集，并更新由机器维护的观测字段。Agent 可以完成这项日常更新，不必每次再问。人工判断保存在另外的字段里。
新发现的价格变化，并不自动授权 Agent 修改已认可的基线或者给客户发邮件。那些是独立动作。它应该先准备证据，再请求必要的决定。如果读不到某个来源，本次运行应记录为不完整，而不是悄悄宣布“没有变化”。
一张实际可用的判断表
| 问题 | 如果答案是“是” |
|---|---|
| 这次共享或公开修改已经在明确授权内吗？ | 在范围内执行，然后验证 |
| 是否会超出约定的动作、收件人、费用或可撤回性限制？ | 准备好准确的修改内容，再请求新的决定 |
| 决定是否依赖缺失、冲突或过时的证据？ | 补证据或确认 |
| 最终结果是否必须由一个明确的人负责？ | 给这个人看最终候选结果 |
| 结果是否无法通过回读验证？ | 不自动写入 |
我不再用“能连续完成多少步”评价一个 Agent。更值得看的是：它是否分得清哪些步骤是在准备，哪些动作会改变现实，以及什么时候必须把决定交回给人。