Agent 的可靠性，不是少犯错，而是能完成

一个 Agent 每一步都有 95% 成功率，连续执行二十步时，全部成功的概率只剩约 36%。这解释了为什么单轮演示很惊艳，真实工作却常在登录、格式、网络或页面变化上失败。可靠性不是把模型错误率再降一点，而是设计整个任务如何走到终点。

Computer Use 与 Agents SDK 把浏览器、工具调用、交接和追踪纳入统一运行时，也暴露了新故障面：工具超时、权限不足、返回结构变化、重复执行和外部状态冲突。模型判断正确，动作仍可能失败；动作成功，业务结果也可能未达成。

端到端可靠性来自把长任务切成可检查的阶段。每一阶段都记录前置条件、动作、预期状态与幂等键；执行后从外部系统读取结果，而不是相信工具返回的成功文案。若失败，恢复器依据错误类型重试、改走替代路径或回滚到检查点。这样，单步的不确定性被限制在局部，不会无声扩散到最终交付。检查点还让人工接管时不必重新理解整段历史。

因此，评估单位必须从步骤准确率变成端到端完成。用户购买的是完成，不是平均正确。任务要有明确验收条件，例如文件已生成且能打开、订单草稿已保存但未付款、测试通过且 diff 在范围内，而不是“Agent 表示自己做完了”。

自动重试并非总能提高可靠性。对支付、发送和创建记录等非幂等动作，重复执行会比原始失败更糟；对权限不足或目标矛盾，重试只会累积费用和噪声。验证器也可能误判，例如页面出现“已保存”却保存了错误内容。若系统只优化成功状态的出现，就容易把形式完成误当作用户目标完成。无限恢复还会掩盖系统已经超出能力边界的事实。

可靠运行需要检查点。每个关键动作保存输入、输出和外部状态，失败后从最近安全点恢复；可重试操作要幂等，不可逆操作要预览或二次确认。系统还要区分暂时故障、能力不足与目标歧义，三者不能共享一个无限重试循环。

验证器是另一条关键链路。代码用测试，数据用约束，网页操作用页面状态，开放文本用来源与独立模型复核。没有外部验证的完成，只是模型的自我报告。验证失败时，Agent 应修复、换路径或诚实升级给人。

实践中应先为任务写出可观察的终态，再标注每一步是否可逆、可重试及需要何种证据。故障演练要覆盖超时、重复响应、页面变化、凭证失效和用户中途修改目标。除了首次成功率，还需观察恢复后成功、重复副作用、人工接管位置与未清理状态。评估必须从真实事故回流，才能覆盖想象之外的脆弱环节。每次演练都要确认失败后是否留下可安全继续的状态。

用户体验不应隐藏失败。清楚说明卡在哪一步、哪些结果已保存、需要用户提供什么，比一句笼统错误更能维持信任。对低风险任务可以自动恢复；对高风险或反复失败任务，应尽早停止，避免错误和费用累积。

团队需要维护故障分类与恢复指标，包括首次完成率、恢复后完成率、人工介入时间、重复副作用和不可恢复失败。把每次线上事故回放进评估集，才能让可靠性成为持续改进的工程，而不是发布前的愿望。

可靠 Agent 的核心不是消灭不确定性，而是对不确定性进行治理。传统软件把异常交给预先编写的分支，Agent 可以动态寻找路径，却更需要不可逾越的安全边界。两者结合后，模型负责适应，系统负责约束与验收。用户最终信任的不会是一个声称从不失败的角色，而是一套失败后仍能把事情交代清楚的机制。完成的定义由用户目标决定，不能由 Agent 自己降低标准。

最好的 Agent 并非从不出错，而是错误可发现、可隔离、可恢复，并最终给用户一个可信终态。可靠性是系统把不确定步骤组织成确定交付的能力。这也是 Agent 从玩具走向基础设施的真正门槛。

可靠性还取决于外部系统是否提供适合机器操作的接口。只靠像素点击时，页面布局、弹窗和加载状态都可能让 Agent 误判；结构化 API 能提供明确错误与幂等标识，却未必覆盖所有业务语义。成熟系统会优先使用可验证接口，仅在必要处使用界面操作，并对脆弱步骤设置更严格检查。

《Agent 的可靠性，不是少犯错，而是能完成》讨论的表面是功能，底层其实是一份委派契约。用户需要知道自己交出了什么目标、哪些资料会被使用、系统可以替他做到哪一步，以及什么情况下会停下来请求确认。把这四件事放在同一个可见界面中，比让 Agent 用更像人的语气解释自己，更能建立可以重复使用的信任。

体验失败往往不是发生在执行动作，而是发生在目标被悄悄误解之后。一个助手可能准确点击了按钮，却选择了错误候选、忽略了隐含约束，或把临时偏好当成长期授权。产品应在目标含糊、风险上升或上下文冲突时主动提出最小问题；高质量追问不是打断自动化，而是避免用户在最后才发现整条路径偏了。

故障升级给人也需要设计。系统应汇总目标、已尝试路径、当前外部状态和建议选项，而不是把全部日志丢给用户。接管后，Agent 要识别人做出的修改并从新状态继续，避免再次覆盖。人工介入不是可靠性的失败，而是一条正式恢复路径；真正失败的是介入后仍需从头重做。

衡量这类体验时，除了任务完成率，还要记录用户接管发生在哪一步、接管后系统能否理解修正、每次成功交付需要多少额外澄清，以及拒绝或取消是否真的生效。好的 Agent 会随着使用减少协调成本，而不是把交互从一串点击换成一串更难审阅的聊天消息。

当 Agent 进入关键基础设施，完成率之外还要关注失败的相关性。同一模型更新可能让大量任务同时在相同步骤出错，单任务的平均成功无法揭示这种集中风险。通过模型多样性、分批发布和可回滚执行降低共同故障，才能避免智能组件成为新的单点。可靠性最终是一种系统组合属性。

权限设计也需要与心理负担匹配。低风险、可逆动作可以在明确范围内自动完成；涉及外发、付款、删除、身份或敏感资料时，应把对象、影响和回滚方式呈现出来。重点不是制造更多弹窗，而是让少数真正关键的决定足够醒目，使用户能够理解并承担自己的选择。

未来的差异不会只来自谁能做更多动作，而来自谁能在持续关系里保持边界感：记得有用偏好，允许用户修改和遗忘；主动推进任务，又不把不确定性藏起来。用户最终留在一个 Agent 身边，不是因为它永远不犯错，而是因为它犯错后仍可被理解、纠正和重新委派。