Axon Agent 什么时候应该停下来问人
Agent exception handling 是 AI 数字员工判断“该继续还是该停下”的产品机制：当来源冲突、负责人缺失、动作不可逆、权限不明或连续不确定时，Axon Agent 应该把任务交回给人，而不是假装自己有把握。团队最耗时的不是看到一次异常，而是重复手动修正、反复解释、最后仍然担心出错。很多自动化失败并不是模型不会写，而是系统没有设计停顿点。它一路往下跑，直到把错误带进邮件、文档、日程或客户沟通里。
NIST AI Risk Management Framework 把 AI 风险管理放在治理和可管理性框架里，OWASP LLM Top 10 也提醒应用层需要处理提示注入、敏感信息、过度代理等风险。对 Axon 来说，Trust Mode 不是一个漂亮的安全标签，而是 Agent exception handling 的核心界面：低风险步骤可以继续，高风险或不确定步骤必须停下来。
这篇文章不把异常写成“错误弹窗”。对团队来说，异常是工作事实：资料不一致、客户话术没有 owner、文件缺失、上游没有更新、同一字段出现两个版本。真正的产品质量，不是把这些问题藏起来，而是让 Agent 在合适的位置停下，并把原因说清楚。
异常不是失败，盲目继续才是失败
一个周报 Agent 读到两份状态相反的项目文档，应该继续生成吗？一个邮件 Agent 看到客户催促退款，但没有找到审批记录，应该自动回复吗？一个日程 Agent 发现会议时间冲突，应该自行删除旧会议吗？
这些问题的答案通常不是“让模型更聪明”。答案是让 Agent 有明确的异常规则。Codex 与 Axon 的自动化边界 讨论过类似原则：执行能力越强，越需要知道什么时候停。Axon Agent 的 Trust Mode 应该把这种停顿变成稳定体验，而不是靠用户事后发现问题。
自动化真正成熟的标志，不是永远不停，而是知道哪些不确定性不能继续传递。
四类应该停下来的情况
| 异常类型 | 例子 | Agent 应该怎么做 |
|---|---|---|
| 来源冲突 | 两份文件给出不同交付日期 | 标出冲突来源，请 owner 选择 |
| 权限不明 | 要发送外部邮件，但收件人和内容敏感 | 生成草稿，不自动发送 |
| 动作不可逆 | 删除邮件、删除日历、覆盖原始文件 | 进入确认或授权 |
| 连续不确定 | 连续两次无法判断分类 | 停止扩散，写出不确定原因 |
这里的重点是“停止扩散”。一个不确定的小点，如果被自动带进下游文档，就会变成团队需要排查的系统性问题。
异常处理要写进工作流，而不是留给运气
Axon Agent 是可解释、可检查、可定时运行的 Skill Pipeline。每一步都应该知道输入来自哪里、输出交给谁、遇到什么情况要停下来。Agent Exception Queue Runbook 这类异常队列思路能帮助团队理解：Agent 不是一条只会向前的线，它应该有继续、等待、失败、需要确认等状态。
可继续：输入完整，输出低风险，结果只进入 workspace
需确认：涉及外发、承诺、删除、覆盖或敏感资料
需补料：缺少关键来源，或来源时间过旧
需转交：Agent 连续无法判断，owner 必须接手
这段规则看起来简单，但它能让团队少很多返工。没有异常规则的自动化，短期看很流畅，长期看会让人不敢信任。
一份异常日记比一串错误码更有用
Agent exception handling 最好留下人能读懂的记录。它不需要写成复杂日志平台，但至少要回答四个问题：
- 停在哪一步。
- 为什么停。
- 需要谁决定。
- 下一次如何避免同类问题。
这和 Workspace Artifact Acceptance Contract 的思路相连：输出不是一句聊天回复，而是可以验收、可以追踪、可以修正的工作产物。
Trust Mode 是自动化的语法
很多产品把权限做成一个开关：自动或手动。Axon 不应该这么粗糙。更好的方式，是把 Trust Mode 作为工作流语法的一部分：哪些 Skill Action 可以 auto，哪些需要 confirm，哪些需要 auth。这样团队才知道 Agent 不是“想做就做”，而是在明确边界内执行。
例如：
- 读取 workspace 文件：通常可以自动。
- 生成文档草稿：通常可以自动。
- 修改原始文件：需要确认。
- 发送外部邮件：需要确认或授权。
- 删除资料：默认不应自动。
这不是为了降低效率，而是为了让自动化可以长期运行。团队真正害怕的不是 Agent 问一句“是否继续”，而是它在没人知道的情况下做了不该做的事。
FAQ
Q1：Agent exception handling 和普通报错有什么区别？
普通报错只是告诉用户系统失败了。Agent exception handling 要说明停在哪一步、为什么停、需要谁判断，以及下一次能否通过规则或资料补充减少同类停顿。
Q2：哪些动作必须进入 Trust Mode？
外发信息、删除资料、覆盖原始文件、修改日历、涉及客户承诺或敏感内容的动作，都应进入确认或授权。低风险读取和草稿生成可以更自动。
Q3：异常太多是不是说明 Agent 没价值？
不一定。早期异常能暴露团队资料边界和责任边界。真正的问题是异常没有被记录、没有 owner、也没有进入下一次工作流改进。
Q4：哪些步骤适合无人值守？
适合固定、低风险、可验证的步骤无人值守运行。涉及高风险、外发或不可逆动作时，必须保留 Trust Mode。这是产品边界，不是能力不足。
Q5：如何减少重复异常？
把高频异常归类：资料缺失、来源冲突、权限不明、输出格式不稳定。然后分别补充 workspace 资料、明确 owner、改写 User Skill 或调整 Agent 步骤。
下一步
如果你正在设计 Axon Agent，不要只写正常路径。想了解更多可控自动化的做法，可以从 Agent exception handling 开始：哪些情况继续，哪些情况停，停下来给谁看，下一次如何减少同类异常。开始使用 Axon 时，先把这些边界写进一个低风险工作流，再扩展到更复杂的团队任务。