生产 Agent 有已知问题时，不要只写一句待优化

生产 Agent 有问题并不稀奇。真正危险的是团队只写一句“待优化”，然后继续让所有人凭记忆绕开。某个字段偶尔要手动修，某类来源会让 artifact 漂移，某个下游用户不能用新版格式。如果没有登记，问题会在聊天里反复出现，造成重复排查、低效沟通和耗时返工。Agent 已知问题登记，就是把“大家都知道”变成可复核、可修复、可停止的运营记录。

NIST AI Risk Management Framework 强调风险需要识别、测量和管理；Anthropic 的 building effective agents 也强调可靠系统来自清楚 workflow 和边界。Axon 的判断是：已知问题不一定要阻止 Agent 使用，但必须说明范围、临时处理和停止条件。

这篇文章连接 Agent 输出漂移复查、Agent 人工返工阈值、Agent 回滚决策规则 和 Agent 用户反馈闭环。登记不是制造问题感，而是防止问题在生产里散开。

已知问题不是普通 bug 列表

Agent 已知问题登记需要写使用影响，而不是只写技术描述。

记录项	应写内容
issue scope	哪类来源、字段、用户或 Schedule 受影响
affected artifact	哪个 artifact 区域可能不可靠
workaround	owner 或 reviewer 当前怎么处理
owner	谁负责修复或复查
next review	何时重新判断
stop condition	什么情况必须暂停、回滚或收紧范围

如果没有 stop condition，已知问题就容易变成长期默认风险。

一条清楚的问题登记

Agent: weekly renewal summary
known_issue: renewal status may be stale when CRM export is delayed
scope: Monday run only, renewal status field
affected_artifact: risk reason and next action
workaround: owner checks export timestamp before accepting artifact
next_review: after 3 Monday runs
stop_condition: any rejected external-use artifact

这条记录让团队知道问题在哪里，也知道当前仍可如何使用 Agent。它比“来源偶尔不准”更可操作。

按严重度处理，不要一刀切

不是所有已知问题都要暂停 Agent。可以分三类：

• 注意类：不影响事实，只影响格式或偏好。
• 修复类：影响局部字段，需要 owner 复核或 workaround。
• 停止类：影响事实、外发、下游决策或 Trust Mode 边界。

已知问题登记的价值，不是把问题都写出来，而是让团队知道哪些问题仍可控，哪些问题必须停止。

注意类可以在下一次维护时处理；修复类要进入变更请求；停止类应触发暂停、回滚或范围收紧。

让问题能关闭

很多登记失效，是因为没有关闭条件。建议每条问题都写：

第一步：需要什么证据证明问题已消失。
第二步：谁来复查。
第三步：到期未修时是否缩小范围。
第四步：是否需要更新 runbook 或发布说明。

这样已知问题不会变成永远存在的脚注。

FAQ

Q1：Agent 已知问题登记会不会让用户不敢用？

不会，如果写清范围和临时处理。模糊问题更容易破坏信任。

Q2：哪些问题必须登记？

重复出现、影响验收、影响下游、影响来源可靠性或 Trust Mode 的问题都应登记。

Q3：谁负责登记？

发现问题的人可以记录，Agent owner 负责确认范围、owner、next review 和 stop condition。

Q4：已知问题和反馈有什么区别？

反馈是输入信号；已知问题是已确认会影响某个范围的运营记录。

Q5：问题关闭后要保留记录吗？

建议保留关闭记录和修复证据，尤其是影响过外发、下游或管理层交付的 Agent。

下一步

开始使用 Axon 管理生产 Agent 问题时，为每个反复出现的问题写一条 Agent 已知问题登记：scope、affected artifact、workaround、owner、next review 和 stop condition。了解更多时，不要只写“待优化”，要写这个问题现在如何被控制。