实战案例¶
这一页回答一个很直接的问题：这本书落到真实系统里，到底会长成什么样？
下面有三个场景。在这些场景里，架构层、防护栏和编排选择已经可以被讨论成工程决策，而不只是漂亮的表述。
如果你需要的不是场景，而是可以直接复用的策略工件，请去看策略模板。如果你想看这本书接下来还要补什么，则看社区路线图。
现在如何阅读这个案例
support triage 案例已经成为本书的贯穿线索：从这里开始，然后看同一个重复工单故障如何穿过 trust boundaries、tool gateway、memory/retrieval、idempotency、traces、SLO、eval gates、ownership、runtime、policy、rollout、ADLC、assurance、provenance、retirement、misalignment controls、telemetry 和 registry。
案例 1：支持分诊智能体¶
系统做什么¶
这个智能体接收客户请求，收集上下文，检查历史工单，然后选择下一个安全动作：
- 直接回复；
- 请求补充信息；
- 创建工单；
- 转交人工。
为什么这里值得用智能体¶
这里适合智能体，因为：
- 输入消息是非结构化的；
- 决策依赖文本、客户历史和策略的组合；
- 路径不是完全固定的，但也不需要完全自治。
这是一个很典型的“工作流 + 受保护智能体循环”场景。
推荐形态¶
- 一个主分诊智能体；
- 读取客户画像和工单历史的读密集工具；
- 只保留一个
create_ticket写工具； - 敏感动作前设置审批边界；
- 每次运行都输出结构化决策。
主要风险¶
- 客户文本里的提示注入；
- 相邻租户上下文泄漏；
- 在不稳定集成中触发多余写动作；
- 分诊智能体自由度过大。
架构里最重要的点¶
- 严格把指令和客户文本分开；
- 不让智能体直接访问客服 API；
- 把停止条件放进分诊例程；
- 记录所有写入意图和审批。
运营最低要求¶
- 成功标准： 回复或工单只创建一次，位于正确租户上下文中，并且依据可解释。
- 失败标准： 多余写动作、相邻上下文泄漏、审批丢失，或无法恢复 trace。
- 最低遥测：
session_id、trace_id、所选动作、检索来源、策略决策、审批状态和幂等键。 - 最低评测集： 正常请求、含糊请求、提示注入尝试、timeout 后重试，以及重复工单场景。
- 发布门禁： canary 不产生重复写入，verifier 确认租户隔离和正确审批路径。
- 事故示例：
create_ticket之后发生 timeout，留下side_effect_unknown，重试又尝试创建第二张工单。 - 复盘问题： 幂等性在哪里失效，谁看到了审批状态，为什么 trace 没有阻止重试，现在应该用哪个 eval 阻挡这类回归？
书里对应阅读¶
案例 2：内部知识智能体¶
系统做什么¶
这个智能体帮员工在文档、运行手册、工单和内部知识库里找到知识。
它会：
- 理解问题；
- 做检索；
- 生成有依据的答案；
- 给出来源；
- 如果置信度低，就收敛回答，而不是瞎编。
为什么这里往往一个智能体就够了¶
这个场景里，很多团队会过早走向多智能体。大多数时候其实没必要。
通常只需要：
- 一个智能体循环；
- 一条好的检索流水线；
- 独立策略层；
- 明确标记不可信内容；
- 答案生成的质量闸门。
主要风险¶
- 检索噪声；
- 越权访问文档；
- 私有知识区泄漏；
- 依据不足时的幻觉。
架构里最重要的点¶
- 租户和角色维度的检索范围；
- 短期状态和长期记忆分开；
- 输出里有来源引用；
- 检索和答案组装都有追踪。
运营最低要求¶
- 成功标准： 答案基于允许访问的来源，显示引用，并诚实限制置信度。
- 失败标准： 没有来源的答案、越权访问、短期状态和长期记忆混用，或虚构策略。
- 最低遥测： query、检索范围、source IDs、置信信号、被拒绝来源和答案 grounding verdict。
- 最低评测集： 已知答案、上下文不足、角色不可访问文档、冲突来源和过期知识。
- 发布门禁： regression set 确认 grounding、角色隔离和低置信度时的正确行为。
- 事故示例： 智能体引用过期 runbook 回答，没有 citations，并向员工暴露了超出角色权限的文档。
- 复盘问题： retrieval scope 为什么扩大，哪个 source 被当作 trusted，low-confidence stop 应该在哪里触发，哪个 eval 覆盖 stale knowledge？
书里对应阅读¶
案例 3：事故协调智能体¶
系统做什么¶
这个智能体在事故处理中帮助团队：
- 收集监控信号；
- 用上下文补全它们；
- 创建事故线程；
- 提议下一个运行手册步骤；
- 把任务交给正确角色。
这已经不只是一个聊天助手，而是一个运行系统组件。
为什么这里尤其需要编排纪律¶
这个场景特别容易犯两种错误：
- 做出一个过载的管理者智能体；
- 或者太早引入交接，结果责任被弄丢。
通常比较好的起点是：
- 接收和协调使用管理者模式；
- 只有真正进入另一条角色边界时才做交接；
- 所有写动作都走能力契约。
主要风险¶
- 噪声告警下的虚假确定性；
- 重复副作用；
- 交接过程里审计轨迹丢失；
- 运行时权限过宽。
架构里最重要的点¶
- 整个事故运行共享一条追踪；
- 每次交接都有明确负责人；
- 工单和通知具备幂等性；
- 高风险修复动作需要人工审批。
运营最低要求¶
- 成功标准： 事故有一条统一 trace、正确 owner 和一个一致的下一步。
- 失败标准： 重复通知、交接时责任丢失、没有审批的高风险修复，或多个渠道出现 split-brain。
- 最低遥测： alert source、incident thread ID、handoff owner、runbook step、写入意图、审批和通知幂等键。
- 最低评测集： noisy alert、重复通知、错误 owner 交接、缺失 runbook context 和高风险修复请求。
- 发布门禁： dry run 显示单一 trace chain、无重复副作用，并且 high-risk steps 需要人工审批。
- 事故示例： noisy alert 触发两条并行 handoff，并向不同渠道发送重复通知。
- 复盘问题： split-brain 是从哪里进入流程的，每一步 owner 是谁，哪些 idempotency keys 缺失，哪个 dry run 应该捕捉到重复？
书里对应阅读¶
下一步做什么¶
最好不要把它们当连续章节来读，而是把它们当地图：
- 先选一个最像你自己任务的案例；
- 再顺着它的链接去读对应章节；
- 然后回来看一遍，检查自己的设计是不是已经被你自己过度复杂化了。
如果这本书真的要对社区有用，这类页面最终应该增长得最快，因为它们能把架构真正变成工程上的支点。