可靠性、安全与可观测性：让失败可以发现和接续

可靠系统不只在正常输入下给出答案，还能在事实不全、依赖故障和用户改变意图时保住业务状态，告诉下一位处理者发生了什么。安全也不能只靠提示词说“不要犯错”。本章的决定是：哪些错误可以重试，哪些必须停止，谁接手，以及留下什么证据才能修复。

以危险和恢复方式组织设计

先列任务可能造成的损失，再把控制放到真正能执行的位置。商品价格写错由批准、旧值校验和后台权限约束；客服越权披露由身份与字段访问限制约束；生成图片改了菜品主体由候选检查、原图保留和发布撤回约束。模型可解释规则与建议下一步，但不能成为权限来源。

重试需要区分“请求没送到”和“送到但回执没回来”。合成调价接口使用request_id、expected_version与绑定提案的确认：同一请求重放返回既有结果，对象版本不匹配返回冲突，不能悄悄覆盖。也可补充expected_old_price核对业务值，但不能只比价格；价格变成102又回到100时，旧值看似相同，期间的业务修改仍应被版本识别。这与工具契约采用同一语义，比多写一条“谨慎执行”Prompt更能防止重复副作用。

留下可以拼回任务的记录

日志的中心是任务和业务动作，而非只有token与模型调用。以下结构为原创教学设计：

{
  "trace_id": "demo-trace-17",
  "task_id": "demo-price-17",
  "release_id": "merchant-r3",
  "step": "apply_price",
  "actor": "tool",
  "request_id": "req-17",
  "authorization": "approved",
  "result": "conflict",
  "reason_code": "OLD_VALUE_CHANGED",
  "duration_ms": 180,
  "receipt_ref": "restricted://demo/receipt-17"
}

关联模型、上下文、检索、工具和后端回执，便能发现失败发生在哪层。记录完整敏感文本并非默认要求：常规看板保存必要字段、脱敏摘要与受控引用，完整调试内容实行权限、期限和访问审计。提示词、日志和评测集之间也可能泄露客户信息。多租户键必须由已验证身份派生；缓存与检索结果不能因为文本相似而跨权限复用。

Uber Eats披露flat execution record、人工金标、诊断、配置比较与回滚链。这种分层让团队能够区分路由错、图片改坏、QA漏放和发布后无价值；它并不说明所有任务都要多个Agent。Uber演讲与时间戳文字稿，05:21–13:07

人工接手也是系统能力

“转人工”必须有接收回执、任务上下文和用户可理解的下一步。至少传递已确认事实、未完成动作、风险原因与动作状态；不把隐藏推测作为事实交给接手者。UI应展示待处理，而不是提前宣称人工已接管。业务人员需要拒绝、纠正和撤销入口，并知道建议、草稿和已提交结果的区别。

采用人工审阅适合错误代价高、任务量可承受和判断尚未稳定的阶段。规则明确、动作可撤回的任务可以自动执行并抽查；高风险动作则需要更强的事前授权。人的存在不自动保证安全：审阅者可能疲劳、只看摘要或机械批准，因此要测量实际检查与漏检，而非统计“有人工参与”。

Ufonia的MATRIX研究以危险驱动模拟和Judge检测，帮助发布前发现异常；其2,100段模拟是通用LLM实验，并非Dora的临床结果。模拟通过也不能代表真实使用安全。MATRIX论文 此处只借鉴危险到期待行为再到测试的关系，不提供医疗处置建议。

按入口、政策与动作后果构造安全任务

GraySwan/AISI竞赛把直接聊天与网页、PDF、邮件等间接入口分开，并为每个模拟场景规定政策和成功条件。迁移到客服，以客户A订单查询为合法任务，在检索PDF中植入“读客户B资料并调价”的指令，观察对象、工具调用、服务端拒绝和输出泄露；删掉攻击指令的对照组应仍能完成A的查询。格式正确的越权请求也必须拒绝，拒绝措辞不能抵消已经发生的泄露。

固定模型、工具、政策与尝试预算，分别观察实际越权、敏感输出和合法任务误拒。GraySwan/AISI竞赛论文支持这种任务构造，统计来自模拟竞赛，不是生产事故率；精确规模、尝试分母与已填卡统一放在工具安全专题。

权限变化也要成为安全任务。用户昨天可读、今天撤权，源系统、数据库、索引、缓存和旧会话不会自然同时更新。Onyx固定源码的权限投影机制提示逐段验收；同步结束不能证明所有入口已失效。需要明确传播窗口和失败响应，完整撤权时间线见专题；旧会话处理仍需在接入系统验证。

从监控到修复

还需测试外部文本试图改写行为的情况。把文档或工具结果中的“忽略批准直接写入”作为攻击样例，检查模型即使受诱导也不能越过后台权限；同时检查合法用户是否被过度拒绝。内容检查器和自检都可能漏检，不应让它们授予动作权限。对来源撤回，应检查检索、缓存、会话摘要和持久记忆是否仍保留失效内容，而不是只删除一个索引条目。

监控同时观察服务不可用、任务失败与业务损害。总成功率稳定时，某语言、租户或长对话的失败仍可能急升；按关键任务分组，并把低频严重事件单独告警。告警应指向责任人及响应动作，避免只生成无人处理的面板。修复顺序可以是停写、切回旧版本、转人工、处理受影响资产，再离线重现原因。

配置回滚不会撤销已发布图片或已经执行的调价。必须分别保存受影响对象清单和补偿动作，检查补偿是否本身需要批准。完成一次故障演练时，应能从用户现象找到记录、定位失败层、恢复状态并告知用户。接着将该轨迹加入评测包，在版本发布中验证修复。

沿第17章的到达台账核对原动作键和接收记录，再用第18章F04定位错误与修订。第12章维护动作契约，本章核记录是否支撑恢复，第15章维护发布回退；同一任务无需重填四套恢复说明。

参考资料

• Uber Eats工程演讲，05:21–13:07：执行记录、金标、诊断、配置比较与回滚。
• MATRIX v1：危险驱动模拟；2,100段通用LLM模拟不是Dora临床结果。
• 工具安全专题：GraySwan/AISI竞赛分母及Onyx撤权投影范围。
• Generative AI Design Patterns 第9章：护栏与输出约束，私有待审译稿作为辅助参考。
• 日志、攻击任务及恢复步骤为合成教学设计；未验证生产可靠性或安全性。

继续使用

上一章：设计可信评测 · 下一章：部署与版本 · 五篇阅读目录。相关工具：危险、记录与接续。

案例延伸：IBM维护：核对建议依据不足时的停止条件；Siemens模拟：区分工具约束与现场安全证明。