容错与可靠性工程：夜巡人与不断的钟
引言
报时塔建成后，镇长以为工程结束了。夜里下雨，钟锤卡住；第二天风大，塔顶的灯灭了；第三天，送零件的人走错了街。
镇上请来夜巡人。他不修所有东西，却做几件固定的事：每晚记录钟声是否准点，给每条街留一盏备用灯，发现塔门打不开就先绕到侧门，遇到大故障就敲响人工值守的铃。
镇长问："有你在，钟就不会坏了吗？"
夜巡人说："钟还会坏。我只是不让它坏得无人知晓，也不让一处故障拖垮全城。"
可靠性工程说的也是这件事。
TL;DR
Agent 系统会遇到工具失败、模型服务故障、资源不足、逻辑漂移和静默质量退化。可靠性工程用可观测性看见问题，用反馈机制让人接管，用断路器、隔舱、超时、重试和检查点扛住故障，再用轨迹评估把失败变成改进。
1. 可靠性要先量化
生产环境里会坏的东西很多：API 超时、限流、权限错误、模型不可用、上下文超限、数据库断连、内存耗尽、无限循环、死锁、幻觉输出。
还有一种更隐蔽的坏法：静默质量退化。系统没有报错，服务也可用，但模型输出质量下降了。原因可能来自请求路由、推理服务优化、硬件差异或编译器 bug。只盯可用性，根本看不见。
因此可靠性要落到指标上：可用性、错误率、P99 延迟、平均恢复时间、工具成功率、token 成本、Agent 迭代次数、任务成功率、幻觉率。没有这些数字，团队只能用感觉判断系统是否可靠。
2. 可观测性是所有防线的地基
可观测性由三根柱子组成。
指标看趋势，回答系统是否变慢、变贵、变不稳定。日志记录事件，回答具体发生了什么。追踪把一次请求穿过的模型调用、工具调用、状态变更和错误串起来，回答慢在哪、错在哪。
Agent 系统要特别重视 trace_id。它把同一任务里的指标、日志和 span 串在一起。没有 trace_id，工程师只能在散落事件里猜一条轨迹。
可观测性还应该驱动实时控制。某个工具连续超时，系统可以打开降级开关；某类任务 token 激增，系统可以切换压缩策略；某个模型错误率上升，系统可以触发熔断或回退。看见问题只是第一步，能在生产中安全调整才有价值。
3. 人在环要克制
高风险操作需要人介入，但审批不是越多越好。提示太多，用户会开始机械点击同意，监督变成形式。
更实用的方式，是先按风险分级。低风险读取自动执行，中风险操作首次询问并记住一段时间，高风险、不可逆或涉及敏感数据的操作走正式审批。
长任务还要支持运行时指令注入。用户可能在任务中途说"停下"、"换个方向"、"先别写文件"。这些指令不能在任意时刻打断执行，系统应在安全点处理：模型调用前、工具执行后、任务边界、状态提交前。
人在环不是把人塞进每一步，而是在真正需要判断和承担责任的位置，把控制权交回来。
4. 四个容错模式要配套使用
可靠系统常用四个模式。
断路器处理下游服务持续失败。失败达到阈值后快速拒绝请求，过一段时间再探测恢复，避免系统把资源浪费在已知坏掉的服务上。
隔舱把不同工具或任务分配到独立资源池。一个外部 API 卡死，不应该占满所有并发，让文件读取和本地分析也一起停摆。
超时防止无限等待。每类工具都要有合理上限，到点失败并返回可解释错误。
重试处理短暂故障。只重试可能恢复的问题，例如网络抖动和限流；参数非法、权限拒绝这类业务错误不应重试。重试要用指数退避和抖动，避免所有客户端同时再次冲向同一个故障点。
这些模式还需要幂等性和检查点。因为重试会制造重复请求，有副作用的操作必须用幂等键防止重复扣款、重复写入。长流程要定期保存已验证状态，故障后从检查点恢复。
5. 失败轨迹要回流
可观测性如果只停在仪表板，就是昂贵的日志系统。可靠性要形成闭环：观测、评估、修复、发布、再观测。
Agent 评估不能只看最终成功率。失败可能来自模型能力，也可能来自环境缺包、工具配置、权限、重试策略或上下文污染。完整轨迹能告诉团队：失败发生在哪一步，模型看到了什么，调用了哪个工具，错误是否被错误处理放大，状态有没有写坏。
失败轨迹比成功演示更有价值。成功只说明某条路径走通，失败会暴露系统的真实边界。把失败分析写回技能、提示、工具设计或记忆策略，系统才会从故障中变稳。
写在最后
夜巡人最后老了，把巡夜铃交给年轻人。他没有留下"让钟永不坏"的秘诀，只留下三本记录：哪天坏过，怎样恢复，下一次怎样少坏一点。
年轻人问："这就是可靠性吗？"
他说："可靠不是风雨不来。可靠是风雨来时，有人知道哪盏灯灭了，哪条路还能走，什么时候该叫醒工匠。"
Harness 的可靠性也不来自完美模型。它来自可见的轨迹、有限的故障半径、可恢复的状态、克制的人机协同，以及愿意从失败里修正系统的纪律。