先这样答
Agent 产出的需求直接上线面临四个核心风险。首要是正确性无保证，大模型的幻觉可能导致改错原本正常的业务逻辑。其次是不可解释，如果直接修改代码或配置，往往缺乏人类可审的差异说明。第三是责任主体不清，一旦引发故障，无法界定由谁对机器的产出签字负责。最后是级联影响，看似局部的改动可能破坏系统中未明文记录的隐式依赖。
针对这些风险，需要建立把关机制并设计严密的回滚策略。把关的核心是让 Agent 的产出变成可审形式，比如提供 diff 对比、测试报告和变更清单。人工审核点必须设置在代码合并与最终上线两个闸口。自动化校验如测试通过率、代码格式检查、回归测试集和灰度监控指标，应作为准入条件前置，但不能完全替代人工把关。
回滚机制的设计基础是每次变更都要有版本与快照，包括代码 tag、配置版本以及数据迁移的可逆脚本。回滚的触发条件需要分层设计。当错误率或延迟等指标触碰阈值，或者核心测试失败时，作为硬条件自动触发回滚。当指标出现劣化但未越过红线时，作为软条件触发告警，由人工决策是否回滚。执行回滚的动作必须经过演练且具备幂等性，同时回滚操作本身也要设置超时保护。
总结来说，Agent 交付的边界是产出可审、过程可溯、结果可回，这三点做不到的环节暂时不应交给 Agent 独立完成。
面试官会怎么追问
- 「出过 Agent 交付引发的风险吗？当时怎么解决的？」 可以结合实际项目说明，比如 Agent 修改某个接口时遗漏了对老版本客户端的兼容逻辑，导致部分请求报错。解决方式是立即触发预设的代码版本回滚，恢复上一个稳定 tag。事后复盘在自动化校验环节补充了向后兼容的回归测试集，并要求 Agent 在交付时强制输出接口变更的差异清单供人工复核。
- 「如果 Agent 自动回滚也失败了，或者回滚超时了，系统该怎么处理？」 回滚本身必须有超时保护机制。如果回滚动作超时或失败，系统会自动阻断 Agent 的后续操作权限，并升级告警级别呼叫人工介入。此时工程师会通过底层基础设施的快照或备用集群进行人工强制恢复，避免过度依赖自动化运维能力。
- 「自动回滚的触发条件具体怎么定？哪些需要人工看？」 硬条件通常是明确的核心业务受损指标，比如错误率超过设定阈值、核心链路的自动化测试直接失败、或者主流程响应延迟大幅超标。软条件则是非致命的指标劣化，比如缓存命中率轻微下降。前者需要机器立刻止损，后者需要人类结合业务上下文判断是否属于正常波动。
回答的坑
- 认为只要单测覆盖率够高就可以让 Agent 自动上线，忽略了幻觉可能导致测试用例本身被篡改，正确的做法是将自动化测试作为前置准入，合并和上线仍需人工审核。
- 把回滚设计等同于让 Agent 现场去写撤销代码，这会引入二次幻觉风险，正确的做法是依赖底层基础设施的版本控制和快照机制来进行幂等回滚。
同系列的题
—— 本题完 ——