实战案例¶
这一页回答一个很直接的问题：这本书落到真实系统里，到底会长成什么样？
下面有三个场景。在这些场景里，架构层、防护栏和编排选择已经可以被讨论成工程决策，而不只是漂亮的表述。
如果你需要的不是场景，而是可以直接复用的策略工件，请去看策略模板。如果你想看这本书接下来还要补什么，则看社区路线图。
现在如何阅读这个案例
支持分流（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）。
规范案例对齐（Canonical case alignment）
这些场景对应书籍计划里的三个规范案例（canonical cases）。支持分流（Support triage） 是案例 1，用来承载写入能力（write capability）、审批（approvals）和重复工单恢复（duplicate-ticket recovery）。内部知识助手（Internal knowledge assistant） 是案例 2，用来承载检索（retrieval）、记忆（memory）、访问控制（access control）、新鲜度（freshness）和知识来源（knowledge provenance）。事件协调（Incident coordination） 是案例 3，用来承载追踪（traces）、服务级目标（SLO）、升级（escalation）、通知副作用（notification side effects）、响应归属（response ownership）和事件后学习（post-incident learning）。
跨章节路线¶
阅读正文时，应把这三个案例当作覆盖检查：
- 第 1 章： 工作流、单智能体循环和多智能体形态之间的选择；
- 第 2 章： 穿过参考架构、控制平面和数据边界的路径；
- 第 3-4 章： 信任边界、审批、策略和智能体行动权；
- 第 5-7 章： 记忆、检索、新鲜度、知识来源证明和投毒防护；
- 第 8-10 章： 工具网关、MCP/A2A、幂等性、重试和回滚；
- 第 13 章： 评测、验证器和回归门禁；
- 第 18 章： 发布就绪度和扩大规模前的审查；
- 第 21-27 章： 生命周期、保障、来源证明、退役、遥测和注册表。
工业运行时模式（Industrial runtime patterns）¶
把这些案例放在工业实践旁边会更容易阅读。它们不是要求读者复制某个供应商产品，而是展示哪些生产形态已经变得可识别。
Cloudflare Agents SDK：作为命名持久对象的智能体¶
Cloudflare Agents SDK 展示了一种模式：智能体不只是围绕模型的一次性循环，而是运行在 Durable Object 之上的可寻址 Agent 实例。它有稳定名称、持久 SQL/key-value 状态、WebSocket 连接、定时任务、唤醒和休眠。对本书来说，架构结论很简单：当智能体绑定到真实实体——客户案例、租户工作区、事故房间、设备、项目或研究档案——运行时就应该明确展示谁拥有状态、哪些运行修改过它、哪些定时任务可以唤醒实例，以及哪些追踪证明可以安全恢复。
这里的实践契约是：稳定名称 → 持久状态 → 唤醒/休眠 → 定时/后台工作 → 审批门禁 → 追踪证据。这把记忆、后台更新、执行、追踪和发布章节连成一个形状：schedule 不应该是不可见 callback，WebSocket UI 不应该暴露智能体的全部状态，approval 应该位于真正发生 side effect 的边界。
GitHub Copilot cloud agent：云端编码智能体契约¶
GitHub Copilot cloud agent 展示了另一种生产形态：智能体从 GitHub、IDE、CLI、API 或集成入口接收任务，研究仓库，规划修改，把代码推送到独立分支，暴露 session logs，然后打开 pull request 供人工 review。关键点不只是“智能体会写代码”，而是自治被包装进了熟悉的工程生命周期。
对本书有用的契约是：request/issue → isolated task session → branch → commits/logs → validation/security checks → human review → pull request。分支成为变更边界，session logs 成为可观测性表面，PR 成为审批门禁，而是否允许 GitHub Actions 在智能体分支上运行则是独立风险决策，因为 workflow 可能接触 secrets 或 write permissions。这个模式也应该迁移到其他 cloud coding agents：自治 worker 可以做准备性工作，但 merge、privileged workflows 和 production impact 必须保持为可 review 的控制点。
案例 1：支持分诊智能体¶
系统做什么¶
这个智能体接收客户请求，收集上下文，检查历史工单，然后选择下一个安全动作：
- 直接回复；
- 请求补充信息；
- 创建工单；
- 转交人工。
为什么这里值得用智能体¶
这里适合智能体，因为：
- 输入消息是非结构化的；
- 决策依赖文本、客户历史和策略的组合；
- 路径不是完全固定的，但也不需要完全自治。
这是一个很典型的“工作流 + 受保护智能体循环”场景。
推荐形态¶
- 一个主分诊智能体；
- 读取客户画像和工单历史的读密集工具；
- 只保留一个
create_ticket写工具； - 敏感动作前设置审批边界；
- 每次运行都输出结构化决策。
主要风险¶
- 客户文本里的提示注入；
- 相邻租户上下文泄漏；
- 在不稳定集成中触发多余写动作；
- 分诊智能体自由度过大。
架构里最重要的点¶
- 严格把指令和客户文本分开；
- 不让智能体直接访问客服 API；
- 把停止条件放进分诊例程；
- 记录所有写入意图和审批。
运营最低要求¶
- 成功标准： 回复或工单只创建一次，位于正确租户上下文中，并且依据可解释。
- 失败标准： 多余写动作、相邻上下文泄漏、审批丢失，或无法恢复 trace。
- 最低遥测：
session_id、trace_id、所选动作、检索来源、策略决策、审批状态和幂等键。 - 最低评测集： 正常请求、含糊请求、提示注入尝试、timeout 后重试，以及重复工单场景。
- 审批模型： 普通工单创建可按策略自动执行；优先级变更、升级、批量通知，以及未知副作用后的重试都需要新的审批。
- 记忆策略： 长期记忆不得把客户文本当作可信事实；只允许写入带来源、TTL、租户范围和清理路径的已验证偏好。
- 工具风险画像： 读取客户画像和历史工单是低风险；创建工单是带幂等性的中风险；修改状态、优先级或接收人是需要审批的高风险。
- MCP/A2A 暴露面： 支持系统 MCP 服务器必须在已批准注册表中，并过滤返回值；转交给支持团队的 A2A 交接不得在没有独立决策时传递写入权限。
- 发布门禁： canary 不产生重复写入，verifier 确认租户隔离和正确审批路径。
- 事故示例：
create_ticket之后发生 timeout，留下side_effect_unknown，重试又尝试创建第二张工单。 - 复盘问题： 幂等性在哪里失效，谁看到了审批状态，为什么追踪（trace）没有阻止重试，现在应该用哪个评测（eval）阻挡这类回归？
- 退役条件： 旧工单写入路径已关闭，挂起审批已过期，工具主体已撤销，注册表只指向新的写入契约。
书里对应阅读¶
案例 2：内部知识智能体¶
系统做什么¶
这个智能体帮员工在文档、运行手册、工单和内部知识库里找到知识。
它会：
- 理解问题；
- 做检索；
- 生成有依据的答案；
- 给出来源；
- 如果置信度低，就收敛回答，而不是瞎编。
为什么这里往往一个智能体就够了¶
这个场景里，很多团队会过早走向多智能体。大多数时候其实没必要。
通常只需要：
- 一个智能体循环；
- 一条好的检索流水线；
- 独立策略层；
- 明确标记不可信内容；
- 答案生成的质量闸门。
主要风险¶
- 检索噪声；
- 越权访问文档；
- 私有知识区泄漏；
- 依据不足时的幻觉。
架构里最重要的点¶
- 租户和角色维度的检索范围；
- 短期状态和长期记忆分开；
- 输出里有来源引用；
- 检索和答案组装都有追踪。
运营最低要求¶
- 成功标准： 答案基于允许访问的来源，显示引用，并诚实限制置信度。
- 失败标准： 没有来源的答案、越权访问、短期状态和长期记忆混用，或虚构策略。
- 最低遥测： 查询（query）、检索范围、来源 ID（source IDs）、置信信号、被拒绝来源和答案锚定结论（grounding verdict）。
- 最低评测集： 已知答案、上下文不足、角色不可访问文档、冲突来源和过期知识。
- 审批模型： 读取已授权来源不需要审批；写入记忆、扩大检索范围和回答敏感请求需要策略审批或人工审查。
- 记忆策略： 短期状态在会话结束后清理；长期记忆只保存带来源、TTL、租户范围的已验证事实，并禁止从不可信文本直接写入。
- 工具风险画像： 在已批准语料中检索是低风险；写入记忆和更新语料是中风险；扩展访问权限和修改租户过滤器是高风险。
- MCP/A2A 暴露面： MCP 检索必须返回来源标识和访问标签；A2A 专家交接只能共享问题和选定引用，不能共享完整隐藏会话上下文。
- 发布门禁： 回归集（regression set）确认锚定（grounding）、角色隔离和低置信度时的正确行为。
- 事故示例： 智能体引用过期运行手册（runbook）回答，没有引用（citations），并向员工暴露了超出角色权限的文档。
- 复盘问题： 检索范围（retrieval scope）为什么扩大，哪个来源（source）被当作可信（trusted），低置信度停止（low-confidence stop）应该在哪里触发，哪个评测（eval）覆盖陈旧知识（stale knowledge）？
- 退役条件： 旧语料、向量表示和记忆写入规则已禁用，替代语料通过来源和访问审查。
书里对应阅读¶
案例 3：事故协调智能体¶
系统做什么¶
这个智能体在事故处理中帮助团队：
- 收集监控信号；
- 用上下文补全它们；
- 创建事故线程；
- 提议下一个运行手册步骤；
- 把任务交给正确角色。
这已经不只是一个聊天助手，而是一个运行系统组件。
为什么这里尤其需要编排纪律¶
这个场景特别容易犯两种错误：
- 做出一个过载的管理者智能体；
- 或者太早引入交接，结果责任被弄丢。
通常比较好的起点是：
- 接收和协调使用管理者模式；
- 只有真正进入另一条角色边界时才做交接；
- 所有写动作都走能力契约。
主要风险¶
- 噪声告警下的虚假确定性；
- 重复副作用；
- 交接过程里审计轨迹丢失；
- 运行时权限过宽。
架构里最重要的点¶
- 整个事故运行共享一条追踪；
- 每次交接都有明确负责人；
- 工单和通知具备幂等性；
- 高风险修复动作需要人工审批。
运营最低要求¶
- 成功标准： 事故有一条统一追踪（trace）、正确负责人（owner）和一个一致的下一步。
- 失败标准： 重复通知、交接时责任丢失、没有审批的高风险修复，或多个渠道出现脑裂（split-brain）。
- 最低遥测： 告警来源（alert source）、事件线程 ID（incident thread ID）、交接负责人（handoff owner）、运行手册步骤（runbook step）、写入意图、审批和通知幂等键。
- 最低评测集： 噪声告警（noisy alert）、重复通知、错误负责人（owner）交接、缺失运行手册上下文（runbook context）和高风险修复请求。
- 审批模型： 创建事故线程和建议下一步可按策略执行；升级、外部通知和修复动作需要事故负责人或值班审批者确认。
- 记忆策略： 事故工作记忆保留到复盘关闭；长期只保存已批准教训、运行手册更新和工件链接。
- 工具风险画像： 读取告警和运行手册是低风险；创建线程和通知团队是中风险；修复动作和外部通知是高风险。
- MCP/A2A 暴露面： 监控和通知 MCP 工具需要窄范围令牌；A2A 响应者交接需要关联 ID、委派深度和责任返回规则。
- 发布门禁： 演练运行（dry run）显示单一追踪链（trace chain）、无重复副作用，并且高风险步骤（high-risk steps）需要人工审批。
- 事故示例： 噪声告警（noisy alert）触发两条并行交接（handoff），并向不同渠道发送重复通知。
- 复盘问题： 脑裂（split-brain）是从哪里进入流程的，每一步负责人（owner）是谁，哪些幂等键（idempotency keys）缺失，哪个演练运行（dry run）应该捕捉到重复？
- 退役条件： 仅应急使用的路径已关闭，临时令牌和通知渠道已撤销，注册表只保留有效角色和运行手册。
书里对应阅读¶
下一步做什么¶
最好不要把它们当连续章节来读，而是把它们当地图：
- 先选一个最像你自己任务的案例；
- 再顺着它的链接去读对应章节；
- 然后回来看一遍，检查自己的设计是不是已经被你自己过度复杂化了。
如果这本书真的要对社区有用，这类页面最终应该增长得最快，因为它们能把架构真正变成工程上的支点。