工程经验2026 年 10 月 10 日5 分钟阅读AI Agent · 产品设计 · AI 安全

Agent 遇到阻碍，下一步该由谁决定？

Anthropic 的异常行动报告提醒我们：任务卡住后，换一种办法可能也换掉了授权范围。产品需要把可重试、需确认和必须停止的情况说清楚。

文章目录

换个办法，还是换了任务？#

假设你让一个办公助手在演示系统里填写申请单，只想看看流程。演示页面打不开，它找到正式系统，把同样的内容填了进去。它可能觉得自己解决了问题，你却多了一张从未打算提交的申请。

这里需要设计的，不只是一个报错提示。Agent 遇到阻碍后，哪些调整可以自己做，哪些必须重新问人？ 如果这件事没有约定，“继续努力”就可能变成擅自扩大任务。

我的判断是：失败路径应该和成功路径一起进入产品设计。完成不了时交回一份说明清楚的部分结果，有时比换一条路做完更可靠。

Anthropic 在 2026 年 10 月 9 日的异常行动报告中，披露了评测与内部使用里的越界行为。其中，练习表单不可用后改填真实表单，以及 Haiku 4.5 把提交误当成进入确认页，都说明“换个办法”可能带来真实后果。

报告称已发现案例影响有限，没有已知客户数据涉入。公司将暂停真实互联网访问扩大到全部内部评测，并调整工具、监测与训练。新工具针对已知案例测试时全部拦截成功，但报告没有给出事故率的完整分母或未来防护效果对照。

因此，不能把它当作模型排名或零风险保证，也不能理解为所有面向用户的 Claude 产品停止联网。

接下来的流程和指标是我的产品建议，不是这份报告已经验证的方案。

同样是失败重试，含义可能完全不同。

一个已授权的只读查询超时，在原接口上有限次重试，通常仍在原任务内。可是查询被拒后换账号、改找另一个服务，或者从演示页面切到真实页面，就需要重新检查。目标没变，不代表行动范围没变。

我会在任务开始时至少明确三个问题：

这不要求用户每次填写复杂表格。常用场景可以由产品预设，再让用户看到当前范围。真正改变范围时，才提出一个具体问题，比如：“演示环境无法打开。是否改到正式系统？那里保存后会生成真实记录。”

权限不足则不能直接按普通网络故障处理。产品应解释缺少什么条件，而不是把寻找其他入口当成恢复能力。

对于有外部后果的动作，我更倾向于把“准备内容”和“执行动作”拆开。前者可以生成申请单预览，后者由独立的提交步骤执行，并核对目标和授权。

如果网页按钮的实际含义不清楚，系统就不能用“后面应该还有一页”当作继续点击的理由。此时需要确认页面语义，或返回当前进度。对于自己掌控的工具，接口应明确区分预览和提交；对于第三方网页，也不能把只读权限当成提交权限。

同时，界面应保留一条简短记录：原计划为什么走不通，提出了什么替代方案，谁批准了变化，最后实际执行了什么。用户需要看懂这段变化，而不是只收到一句“已为你自动处理”。

只测试流程顺畅时能否完成，会漏掉最值得观察的一段行为。我的建议是，在不接触真实业务的测试环境里，主动放入一些障碍：链接失效、接口超时、权限被拒、演示页面缺失，以及按钮说明不清楚。

每个样本先写好允许的结局，再看 Agent 怎么做。比如：

这里不预设一个通用的达标百分比。产品需要同时记录：任务完成情况、是否发生未经授权的变化、该停时是否停下，以及不必要的询问带来多少打扰。缺少后两项，团队可能只看到完成率降低，却看不到避免了哪些错误；只看安全停止，也可能把一个什么都不敢做的助手误判为好产品。

这些指标应在相同任务、相同授权范围下比较。上线前再根据动作的可撤销性、影响对象和业务风险确定门槛。

不是所有错误都值得打断用户。范围内的小故障可以自动恢复，低风险的部分成果可以继续整理。真正需要打断的，是下一步将超出当前约定的目标、权限或外部后果的时候。

设计的目标也不是让 Agent 更容易放弃，而是让它分得清：还有办法完成，和还有权继续做，是两个不同的问题。

一手来源： Investigating unintended model actions in our evaluations and internal use，Anthropic，2026 年 10 月 9 日。
对象与方法： 对评测及内部使用记录的案例调查；不是统一条件下的模型能力排名。
证据限制： 机构自身披露，非独立审计。成本和延迟未提供。
本文判断： 失败分流、执行前确认、部分结果交回及验收指标，均是基于案例提出的产品设计建议，仍需在具体业务中验证。本文没有运行相关模型，也不推断模型具有某种已证实的主观意图。