实战案例¶

这一页回答一个很直接的问题：这本书落到真实系统里，到底会长成什么样？

下面有三个场景。在这些场景里，架构层、防护栏和编排选择已经可以被讨论成工程决策，而不只是漂亮的表述。

如果你需要的不是场景，而是可以直接复用的策略工件，请去看策略模板。如果你想看这本书接下来还要补什么，则看社区路线图。

跨章节路线¶

阅读正文时，应把这三个案例当作覆盖检查：

• 第 1 章： 工作流、单智能体循环和多智能体形态之间的选择；
• 第 2 章： 穿过参考架构、控制平面和数据边界的路径；
• 第 3-4 章： 信任边界、审批、策略和智能体行动权；
• 第 5-7 章： 记忆、检索、新鲜度、知识来源证明和投毒防护；
• 第 8-10 章： 工具网关、MCP/A2A、幂等性、重试和回滚；
• 第 13 章： 评测、验证器和回归门禁；
• 第 18 章： 发布就绪度和扩大规模前的审查；
• 第 21-27 章： 生命周期、保障、来源证明、退役、遥测和注册表。

工业运行时模式（Industrial runtime patterns）¶

把这些案例放在工业实践旁边会更容易阅读。它们不是要求读者复制某个供应商产品，而是展示哪些生产形态已经变得可识别。

Cloudflare Forge：派生接口的一致性¶

在 2026 年 9 月 28 日的 Forge 公告中，Cloudflare 描述了一个开源、可插拔的流水线：以 OpenAPI 为输入，转换器可相互传递输出，CI 用于 lint 和可安装的预览构建。示例链为 OpenAPI → TypeScript SDK → cf CLI 与 Cap’n Web 描述。这并不要求所有 CLI 都通过 TypeScript 构建。

必须区分成熟度：公告发布时，Forge 已生成 cf CLI 所需的输出；Cloudflare API 文档和 SDK 的迁移计划在随后几个月进行。OpenAPI 之外的输入格式属于未来方向。作者还描述了将 cf dev、cf build 等手写命令纳入文档，以及不破坏旧客户端的版本管理工作；这不是已经实现普遍兼容性的证据。

以下是本书建议的三个场景，不是已执行的 Forge 测试结果：

1. 工具描述过期。 修改必需参数或操作副作用，却保留智能体目录中的旧描述。实现、模式与目录的联合检查应发现不一致并阻止发布；从同一错误模式重新生成不属于独立检查。
2. SDK 不兼容。 修改响应形状，使受支持的旧客户端无法解析。新 SDK 可能构建成功，但旧客户端契约测试应阻止常规发布，直到确定兼容方案或迁移决策。
3. 手写命令没有文档。 添加 OpenAPI 中不存在的本地 CLI 命令。比较命令注册表、帮助信息和已发布文档，应发现遗漏；手写扩展元数据应成为生成图的输入，而不是在生成页面上进行会丢失的手工修补。

可迁移的结论：第 20 章管理各接口的一致变更，第 22 章保留准确来源。生成可以减少偏差，但不能代替工具授权或独立 API 验证。

Cloudflare Containers：残留块与既有快照¶

Cloudflare 于 2026 年 9 月 24 日的报告 描述了 Containers 及其上构建的 Sandboxes 中跨租户残留数据暴露。负载运行在独立 Firecracker 虚拟机中，但共享 dm-thin 池的 skip_block_zeroing 配置允许不预先清零就重用块。部分写入可能使未覆盖部分保留前一所有者的数据。研究者无法选择特定受害者、主机或数据；报告未展示修改其他客户的活动数据或影响可用性。

Cloudflare 恢复新分配时清零，随后退役旧磁盘并清除可能绕过新分配的缓存镜像层快照。作者时间线记录修复于 9 月 7 日完成部署，修复前缓存快照于 9 月 19 日完成清理。发布时，提供方表示问题已完全修复，无需客户操作。对可用保留磁盘遥测的审查未发现该方式被恶意利用；这是受范围限制的调查结论，并不证明不存在任何形式的数据泄露。

以下建议验收场景仅使用受控实验环境、合成标记和两个测试租户；未在此执行，也不要求探测云中其他客户的数据：

1. 重新分配： 测试租户 A 写入标记，资源释放后受控地重新分配给 B。B 部分写入后，通过测试授权的客户机路径不能读取旧标记。实验必须确认确实发生重用：碰巧获得全新块不能证明保护有效。
2. 旧快照： 分配器修复后，恢复或克隆预先准备且含合成残留标记的快照，必须在清理前被阻止，或产生已验证清理的结果。只在新空磁盘上通过测试不够。
3. 清理未完成： 某个旧缓存或主机仍未纳入已验证范围。门禁不得关闭该范围的修复或允许分配其中产物；核对过程应发现遗漏。清理期间从旧层生成的产物也继续禁止使用。

结论是：执行隔离、安全存储重用和旧代次清理完成是三个可验证属性，而不是一个“沙箱”标签。契约见第 16 章，清理关闭见第 23 章。场景是本书建议，不声称我们已对 Cloudflare 执行测试，也不是参考运行时现成机制。

Cloudflare Worker Previews：分支独立，依赖共享¶

Worker Previews 公告 为每个分支提供独立代码、配置、URL 和可观测性。资源文档（2026 年 9 月 22 日更新、9 月 26 日核验）界定了更精确的边界：没有 script_name 的本地 Durable Objects 自动隔离，但相同标识或名称的 D1/KV/R2 仍然共享。新预览不是整套基础设施的副本。这是对产品能力的澄清，并非已发现 Cloudflare 事故的报告。

服务绑定调用另一 Worker 的生产部署，而非匹配分支；Workflow 绑定使用已部署的 Workflow 及其代码、依赖和实例。隔离 Workflow 需要单独部署非生产资源。预览发送到生产队列的消息可能由生产消费者处理。文章将多 Worker 与异步流程的自动隔离列为后续工作，而非当前保证。

建议的负向场景（未在此执行）：

1. 两个分支共享数据库： 不同预览使用同一个 D1 database_id。门禁在写入前发现相同目标；独立 URL 不能证明隔离。有意共享的预发布数据库需采用单独模式并控制冲突。
2. 调用其他 Worker： A-preview 通过服务绑定调用 B。验证确认 B 的实际目标及依赖；生产或未知依赖应在调用前阻止测试。存在 B-preview 不会自动改变路由。
3. 队列： 预览向具有生产消费者的队列发送消息。门禁阻止发送；本地 send 成功既不能证明测试隔离，也不能证明预览消费者执行过。
4. 迁移不匹配： 迁移配置与预览绑定指向不同数据库。实际 ID 比较在修改模式前阻止迁移。两份配置必须指向同一获准的物理数据库。
5. 批准后变更： 图验证后绑定改变。旧批准不再有效；受限权限阻止写入新的未授权目标。预览清理也不得删除其他分支的共享资源。

可迁移的结论是检查可达资源和副作用图，而不是环境名称。契约见第 16 章，门禁见第 20 章。这些建议不代表参考运行时已经实现这些检查。

Cloudflare Agents SDK：作为命名持久对象的智能体¶

Cloudflare Agents SDK 展示了一种模式：智能体不只是围绕模型的一次性循环，而是运行在 Durable Object 之上的可寻址 Agent 实例。它有稳定名称、持久 SQL/key-value 状态、WebSocket 连接、定时任务、唤醒和休眠。对本书来说，架构结论很简单：当智能体绑定到真实实体——客户案例、租户工作区、事故房间、设备、项目或研究档案——运行时就应该明确展示谁拥有状态、哪些运行修改过它、哪些定时任务可以唤醒实例，以及哪些追踪证明可以安全恢复。

这里的实践契约是：稳定名称 → 持久状态 → 唤醒/休眠 → 定时/后台工作 → 审批门禁 → 追踪证据。这把记忆、后台更新、执行、追踪和发布章节连成一个形状：schedule 不应该是不可见 callback，WebSocket UI 不应该暴露智能体的全部状态，approval 应该位于真正发生 side effect 的边界。

更新的 long-running agents pattern 会让这条契约更硬：agent identity 比 process 活得更久，一部分工作也可能是 agent 内部的 recoverable internal task。可移植规则是：durable log → checkpointed work unit → stash snapshot → deploy/reconnect recovery → tool-call replay → bounded side-effect replay。如果执行停在 approval、eviction、deployment 或 connection churn 上，runtime 应该从 last safe checkpoint 继续，保留 replay boundary 和 idempotency key，而不是从 transcript memory 重建动作并重复外部 side effect。

Rules of Durable Objects 把这个案例进一步收紧成 Durable Agent Identity：agent identity is the coordination atom，durable instance 应该持有 persistent state, not process memory。实践路径是：request → durable agent instance → persistent state → recovered fiber/job。反模式是依赖 in-memory timers, closures, or open fetches 去承载必须跨 eviction、deploy 或网络中断存活的工作。

Cloudflare Agent Memory 在这个模式上补了一层受治理的长期记忆：agent 不会拿到原始 database/filesystem interface，而是通过一个有边界的服务使用 ingest、remember、recall、list 和 forget。实践契约是：compaction ingest → classified memory → provenance and tenant isolation → constrained recall/remember/forget/list API → supersession and export → eval against stale or conflicting memories。对本书来说，重要的反模式是把“memory”当成模型背后的隐藏 SQL/key-value 访问。否则 retrieval strategy、durable writes、forgetting 和 conflict resolution 都会被塞进 prompt，而不是留在受管理的 runtime layer。

Cloudflare Workers：观察、代码与路由的权限分离¶

Cloudflare：为每位成员和智能体分配合适的 Workers 访问权限介绍了单个 Worker 的访问范围及 Metadata Read-Only、Content Read-Only、Editor、Admin 角色。这是按操作与资源范围授权的具体案例，而不是最小权限原则的替代品。本节也参考了 2026 年 9 月 15 日更新的授权文档。

复合边界尤其有用：修改 Route 或 Custom Domain 需要 Worker 的 Editor 及每个受影响区域的 Workers Routes Write。不改变这些连接的 Worker 更新不需要区域访问。因此，只批准外层“deploy”命令不够，而以防万一为由赋予广泛区域权限也无必要。

结论边界：即使没有删除权限，部署权限仍可发布有害代码，包括使用已有绑定的代码；日志也可能包含敏感数据。文档指出，wrangler login 的 OAuth 流程尚不支持精细授权，此路径需使用账号所有的 API 令牌。不能假定一种认证方式的支持自动适用于另一种，也不能把面向其他产品的资源级权限计划视为已经实现。

矩阵见第 17 章，建议契约与六项检查见策略模式。这些内容不代表参考运行时已有可用的 Cloudflare 集成。

Cloudflare vulnerability harness：VDH、VVS 与噪声过滤¶

Cloudflare 另外描述了一个 vulnerability harness：它从 security-audit skill 起步，后来变成 fleet-wide pipeline。Recon 构建 threat model，Hunters 按 bug class 攻击代码，Validate 尝试推翻 finding，Gapfill 补齐薄弱 coverage cells，Dedup 合并重复项，Trace 把问题追到 consumer repos，Feedback 改写后续任务，Report 则在没有模型的情况下渲染。这里的架构教训是：harness 不应该是“一个大 agent 读取整个仓库”。每个 stage 都把状态写入以 run_id、repo 和 stage 为 key 的数据库，可以 resume/retry，并留下可审查 findings，所以五小时运行不会因为一次 transient failure 全部丢失。

第二个教训是把 discovery 和 validation 分开。Vulnerability Discovery Harness (VDH) 故意生成许多 candidates，而 Vulnerability Validation System (VVS) 把它们放入独立队列，执行 deduplication、judgment 和 fixing。另一个 model/provider 和另一条逻辑路径会重新检查 finding、production reachability，以及 latest main 上是否仍然存在。对本书来说，这不仅是 security case，也是 agent eval architecture 的工业案例：模型可以替换，真正持久的资产是 orchestration layer，它带有 independent verifier、deterministic bookkeeping，以及任何 production-impacting change 前的人类 review。

最小可移植契约是：recon → hunt → validate → dedup/judgment → fail→pass patch gate → human review。Finding 应该包含 threat model、affected boundary、evidence refs、针对未修改源码的 working PoC/test、proposed patch、mechanical schema/path validation、independent validator verdict、duplicate key、reachability judgment 和 remediation status。还需要 shallow runs 的 health signal：如果 hunt 异常快速结束，且没有 findings、sub-hunts 或 gap tasks，这不是“仓库很干净”，而是应该 requeue 并检查 harness failure。

Cloudflare enterprise MCP：gateway 和 portal 作为 policy choke point¶

Cloudflare 的 enterprise MCP reference architecture 很有用，因为它把 MCP 当成受治理的平台表面，而不只是方便的工具协议。这个模式组合了 remote MCP servers、Cloudflare Access、MCP server portals、AI Gateway，以及用于 Shadow MCP detection 的 Cloudflare Gateway。对本书来说，关键动作是把 MCP gateway 和 portal 变成 policy choke point：工具通过已批准表面发现，授权由中心身份层中介，未批准的 remote MCP servers 也会变得可检测，而不是藏在本地配置里。

可移植契约是：approved MCP portal → progressive tool disclosure → identity-bound authorization → gateway policy and DLP → audit trail → Shadow MCP detection。Progressive tool disclosure 很重要，因为大型工具目录既是 token-cost problem，也是 safety problem：agent 应该拿到任务所需的 capability slice，而不是企业拥有的全部工具。Shadow MCP detection 也很重要，否则团队会把旧的 shadow API 问题悄悄重建到 agent tools 上。

Cloudflare Code Mode 给这里补了一个实践性反模式：不要把每个 API operation 都作为单独 tool 塞进 prompt。与其做 tool-list stuffing，server 可以只暴露很小的 search() 和 execute() surface：前者查询 typed API/spec catalog，后者在带显式 permission scopes 的 sandboxed isolate 中执行生成代码。对 enterprise MCP 来说，这会改变治理形态：catalog 留在 gateway 后面，discovery 变成可审计 operation，execute 则经过与 privileged tool call 相同的 policy、DLP、rate-limit 和 approval boundary。

Google Gemini Enterprise Agent Platform remote MCP server 给同一模式补了 managed-cloud 版本：external agents and IDEs 连接到 Google Cloud 内部的标准化 remote MCP endpoint，而 Agent Registry、IAM Deny policies 和 toolset endpoints 定义 discovery 与 authorization。可移植契约是：managed remote MCP endpoint → agent registry discovery → IAM-scoped toolsets → tenant/data boundary → audit and lifecycle ownership。这不是替代 Cloudflare-style gateway/portal，而是展示另一种 deployment shape：capability boundary 属于 cloud platform，而不是本地 MCP config。

AWS Bedrock AgentCore Gateway Policy and Lambda interceptors 则给 MCP governance 补上了具体的 tool-call enforcement path。Cedar policy 给出 deterministic allow/deny decision 和 audit log；request interceptors 在调用 MCP server 前执行 token validation、act-on-behalf exchange、context injection 和 tool authorization；response interceptors 在结果回到 agent 前过滤 tool lists 或 sensitive output。可移植契约是：agent tool call → request interceptor → policy decision → downstream tool → response interceptor → audit event。最小 trace 字段包括 policy_decision、denial_reason、sanitized_request、sanitized_response、interceptor_version、principal、resource 和 context。

更新的 AWS AgentCore Gateway extended MCP support 说明，gateway maturity 不会停在 policy interceptor。MCP gateway 会开始拥有 surface 形状：outputSchema 和 read-only/destructive 等 tool annotations、default 或 dynamic listing、通过 SSE 传递的 streaming progress、Mcp-Session-Id、elicitation modes，以及 OAuth 2.0 on-behalf-of token exchange。可迁移的教训是：如果 elicitation 被中断，具体 tool call 可能是 not resumable，因此 retry 需要自己的语义、idempotency key 和重新检查的 authorization chain，而不能只是“从同一位置继续”。

AWS MCP tool design 给这些 gateway case 补上了 tool-surface 层。问题不只是 security enforcement，还包括 context bloat 和 tool confusion：相似工具太多、schema 太宽、description 不清，会让模型选错操作或混用字段。可移植契约是：tool taxonomy → lazy disclosure → schema constraints → server-side introspection → tool evaluation。如果某个操作太宽，它可能更适合作为 workflow 或 agent-as-tool；如果 catalog 太大，agent 需要按任务搜索和披露，而不是一开始拿到完整列表。

Smartsheet remote MCP server on AWS 补上了 production-grade remote MCP facade 示例。Smartsheet 用 single production MCP facade 同时服务产品内 Smart Assist 和 external AI clients：MCP server 运行在 Amazon ECS on AWS Fargate 上，位于 API gateway path 后面，并连接 domain services 和 intelligence layer。Amazon Kinesis Data Streams 与 Amazon Managed Service for Apache Flink 把 change events 送入 analytics/intelligence path，Amazon Neptune 支持 graph-backed insights。

可移植契约是：single production MCP facade → shared internal/external tool contract → AI-optimized responses → schema-driven validation → access tiers → OpenTelemetry/audit → production canaries → usage feedback loop。关键教训不是每家公司都要复制同一套 AWS stack，而是 enterprise MCP 应该成为 governed domain facade：Smart Assist、external AI clients、security controls、observability、cost control 和 product feedback 共用一个 surface，而不是分裂成多套 agent integrations。

AWS AgentCore AgentOps 和 hosting coding agents 给出了更宽的 production runtime pattern：agent task 应该活在 isolated session 中，带有 durable workspace，使用 scoped credentials，留下 searchable traces，记录 cost/tokens，执行 PII redaction，并发出 explicit governance signals。与 GitHub security validation for third-party coding agents 结合后，它变成可移植契约：isolated session → durable workspace → scoped credentials → egress/tool boundary → trace and cost ledger → PII redaction → platform security validation → human review artifact。关键细节是：CodeQL、dependency risk 和 secret scanning 是 platform-owned gates，而不是 agent 对“我检查过自己”的承诺。

Microsoft Foundry Open Trust Stack 可以作为 policy-driven eval → portable control checkpoint → production observability 的案例。ASSERT 把 policies and requirements 作为 targeted eval scenarios 的输入；Agent Control Specification (ACS) 则定义可以跨 framework stacks 迁移的 control checkpoints。可移植契约是：policy requirement → generated eval scenario → failing trace → ACS checkpoint → re-run eval → observed production signal。没有这条链路，eval 只是报告，control 则仍然只是散落在 prompt、gateway 或 application code 里的规则。

Anthropic Fable 5 redeployment 给 jailbreak findings 提供了实用 severity rubric。它的 Cyber Jailbreak Severity frame 不只看 bypass 本身，还看 capability_gain、breadth_of_capability_gain、ease_of_weaponization 和 discoverability。面向 agent assurance 的可移植契约是：finding → severity record → response path → mitigation → regression eval → monitoring update。这能帮助团队区分 minor safety-margin bypass 和真正打开 dangerous-tool path、需要 emergency disable 或 hot policy/classifier mitigation 的 failure。

Google DeepMind AI Control Roadmap：作为运行时基础设施的控制¶

Google DeepMind 把 AI Control Roadmap 描述成内部智能体的 defense-in-depth 层：传统 security hygiene 和 alignment 仍然是基础，但系统还要谨慎假设，一个能力足够强的 agent 可能 misaligned，也可能只是以出乎意料的方式行动。实践上，能访问内部系统的 agent 应该被建模为潜在 insider threat，而不只是带有 prompt injection 风险的聊天界面。因此，control 被塑造成 runtime contract：基于 MITRE ATT&CK 的 threat modeling、对 actions 和 plans 的 monitoring、supervisor systems、prevention/response gates，以及对 coverage、recall 和 time-to-response 的持续度量。

对本书有用的不是某个供应商自己的 safety claim，而是这种 operational control 形态。Agent system 应该区分 adversarial misuse 和善意但过度的 task optimization：DeepMind 明确指出，coding-agent trajectories 里许多 flagged events 并不是 hostile intent，而是 misinterpretation 或 overeagerness。架构结论是：policy layer、rollout gate 和 assurance loop 不只要捕捉“攻击”，还要捕捉局部看似有用、系统层面却有破坏性的行为。

最小可移植契约是：threat model → monitored coverage → supervisor judgment → synchronous block/asynchronous response → escalation → audit trail。低风险且可逆的动作可能只需要 delayed review 和 remediation；高风险动作则需要 synchronous prevention path。控制指标应该承载发布意义：如果 coverage 下降、verifier recall 没有被证明，或者 time-to-response 不匹配动作风险，就不应该扩大 rollout。

OpenAI internal coding-agent monitoring：runtime behavioral monitoring 作为 evidence¶

OpenAI 的 How we monitor internal coding agents for misalignment 给 DeepMind control pattern 补了一个实践层：runtime behavioral monitoring 不只是 observability，也是未来 safety case 的 evidence。Monitor 会查看真实的 coding-agent sessions，包括 chains of thought and actions，并把看起来不符合用户 intent 或内部 security/compliance policy 的行为升级处理。

对本书来说，有用的是这条 feedback loop：agent trajectory → monitor classification → severity → human review → safeguard update → control eval。Monitoring 不能被说成保证。它依赖 monitorability、保护隐私的 trace access、明确 latency，以及被度量的 coverage, recall, and time-to-response。架构也必须说明哪里 asynchronous review 足够，哪里 high-risk actions 需要在执行前 synchronous blocking。

OpenAI Tax AI for Crete：把 practitioner correction 变成 eval fuel¶

OpenAI 和 Thrive Holdings 把面向 Crete firm network 的 Tax AI 描述成 self-improving agent case，关键不在于模型含糊地“自己修复自己”，而在于产品环境把专家工作变成可度量的改进回路。Practitioners 准备并复核 tax forms，系统保存从 source documents 到 extracted fields、citations、tax-engine mapping 和 filed return 的路径，重复出现的 practitioner corrections 会变成 structured findings、tailored evals 和 bounded Codex tasks。

对本书来说，这是对 evals、traces 和 ADLC 章节的重要补充：human review 不应该是 filing 之后就消失的终端人工修改。如果人类修正了一个字段，架构应该保存 expected value、predicted value、provenance、review status、grouping key，以及这个差异是 actionable product failure 还是 expected workflow noise 的判断。只有重复出现并经过复核的模式才应该变成 eval target；含糊的 tax judgment 和 unsupported product behavior 应该回到 product/engineering review，而不是被强行塞进 loop。

最小可移植契约是：expert correction → production trace → reviewed finding → targeted eval → scoped Codex task → regression gate → engineering review → shipped improvement。对 high-stakes domains 来说，这既是 HCI pattern，也是 assurance pattern：practitioners steer direction，production traces preserve evidence，Codex 在带 read-only production context 的 bounded worktree 中调查，真正的 product changes 在 rollout 前仍由 engineers 负责。

Microsoft CodeAct/Hyperlight：代码隔离与宿主工具权限¶

Microsoft Agent Framework 将 CodeAct 描述为以程序组合适当操作并返回汇总结果的方式。Python 示例中，HyperlightCodeActProvider 提供执行工具，生成代码通过 call_tool(...) 使用已注册工具。Hyperlight 隔离模型生成代码；工具本身在应用运行时执行。never_require 示例仅使用算术，来源要求需要单独批准的动作仍通过明确审批门禁。这是架构边界说明，不是 Microsoft 漏洞报告。

实践结论是：“运行此程序”并不把应用进程的全部权限委派给程序。建议的工具桥接场景（未在此执行）：

1. 禁止的工具： 程序指定未注册或当前 principal 无权使用的工具。桥接在进入适配器之前拒绝并记录；execute_code 获批不能成为例外。
2. 未经批准的写入： 读取获准，但下一操作修改数据。读取可以完成；写入必须有适用的单独审批才能开始。若不支持此类暂停，就不能将工具导出到自动集合。
3. 调用之间撤权： 第一次成功后权限被撤销。即使程序仍在运行，当前策略也应阻止第二次；第一次作为部分结果记录。
4. 批准后参数变化： 资源、金额或调用者改变。旧审批不适用于新操作；权限检查仍独立于审批。
5. 副作用后的失败： 工具开始写入后程序失败，或通道丢失响应。外层失败不能证明没有写入。验证要求保留操作标识，并在重试前核对或采用幂等机制；不能用单一“程序未执行”状态隐藏部分效果。

桥接契约见第 16 章，信任边界见第 9 章。这些建议不承诺具体提供方版本支持全部场景，也不表示参考运行时已经实现它们。

Microsoft AutoJack：localhost 不再是信任边界¶

Microsoft Defender Security Research 把 AutoJack 描述为 AutoGen Studio 中的一条 exploit chain：由 browsing agent 渲染的不可信网页可以触达本地 MCP WebSocket，并在 host 上启动进程。这个具体问题在受影响的 MCP surface 进入 PyPI release 之前已经修复，但架构教训并不限于某个项目：如果 agent 既能浏览 open web，又能访问有特权的本地服务，localhost 就会变成 attack surface 的一部分。

对本书来说，AutoJack 是 agent harness 中 confused deputy 的一个实践案例。127.0.0.1 或 localhost 的 origin allowlist 并不能证明信任，因为请求可能来自同一台机器上 agent 的 headless browser 或代码工具。MCP server 的 auth、policy 和 executable allowlist 必须位于 control-plane endpoint，而不是依赖“loopback 只有人类开发者能访问”的假设。

最小可移植契约是：untrusted web content → browser/tool agent → local control channel → authenticated MCP/control plane → allowlisted execution boundary → audit trail。任何本地 MCP/debug/control socket 都应该要求 authn/authz、purpose binding、policy gate、启动参数 allowlist 和 isolation profile。Browser tools 最好使用独立的网络与进程身份运行，避免外部内容继承 developer workstation 或 agent host 的信任。

Microsoft prompts become shells：从 prompt injection 到 host execution¶

Microsoft 的 “When prompts become shells” 是和 AutoJack 不同的独立案例。AutoJack 展示 browser-agent 如何跨过 local control channel；这个案例展示的是 agent framework 内部的 prompt injection -> tool parameters -> host execution。在 Semantic Kernel 示例里，模型按设计工作：把自然语言映射成 tool calls。不安全的边界在 framework/tool layer：它信任 parsed, model-controlled parameters，并让这些参数到达 execution primitive。

可移植的教训很直接：AI models are not security boundaries。任何来自模型的值，在 gateway、tool wrapper 或 sandbox 证明安全之前，都应该被当作 attacker-controlled input。也就是说，tool exposure review 不只要检查有哪些 tools，还要检查 argument schemas 是否能触达 paths、commands、templates、dynamic code、file writes、deserialization、reflection 或 query/expression languages。path validation 不是细节；它是“模型选择了文档”和“模型交出了 filesystem primitive”之间的边界。

最小可移植契约是：untrusted prompt/content → model-controlled parameters → typed validation → allowlisted operation → per-tool sandbox → audit trail。对 execution-adjacent tools 来说，默认应该是 deny-by-default tools，禁止把模型参数 string interpolation 到 shells 或 evaluators，执行 canonical path validation、read/write scope checks、per-tool sandbox，并写入包含 redacted model parameters、validation result、sandbox profile 和 policy decision 的 audit event。

Microsoft reading to acting：metadata poisoning 作为供应链风险¶

Microsoft 的 “When AI tools move from reading to acting” 补齐了同一张威胁图的第三个角：agent 可能从 read-only tool access 起步，但真正的风险出现在它开始 acting 时，因为 MCP descriptions 会近似成为 tool choice 的 system prompts。如果一个已经受信任的 MCP server 在初次 approval 后改变 tool description、schema、scope 或 endpoint，host 可能在没有 fresh review 的情况下再次把更高 agency 交给它。这不再只是本地 prompt bug，而是 supply-chain risk：metadata、registry entry 和 published tool contract 都成了 trusted computing base 的一部分。

可移植契约是：approved MCP server → tool metadata diff → re-attestation → least-agency disclosure → high-impact approval → behavior-drift monitoring → quarantine path。Review 应该覆盖 description diff、documentation fields 里的 imperative language、新增或扩大的参数、read-only → write/action transition、异常 query patterns，以及 owner/provenance 变化。Least privilege 限制 token scopes，但这里还需要 least agency：agent 不应该仅仅因为类似的 read-only tool 已经被批准，就能看到或自动使用 action tool。

Microsoft networked-agent red team：agent 间信任作为攻击面¶

Microsoft networked-agent red team 给 MCP/A2A 威胁图增加了网络层：在多 agent 系统里，风险可以通过 peer messages、shared summaries、delegated tasks 和互相背书传播。重点不只是想象中的 agent worms，也包括更普通的失效：恶意指令的 propagation、通过 fan-out 产生的 amplification、多个 agent 从同一来源互相确认时的 trust capture，以及本地 traces 看不到完整 cross-agent path 时的 invisibility。

可移植契约是：peer message is data, not authority → signed provenance → hop and rate limits → capability scoping per edge → cross-agent trace → Sybil resistance → quarantine。Runtime 应该保存 original author、message path、delegation depth、fan-out、policy decision 和 quarantine reason。否则 agent 间协调会把旧的 prompt-injection 问题变成网络 failure mode，让一个 agent 可以通过另一个 agent 清洗指令。

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 的控制点。

Security validation for third-party coding agents 进一步加强了这个模式：GitHub 会把用于 Copilot cloud agent 的同一套自动控制应用到第三方 coding agents 生成的代码上：CodeQL、基于 GitHub Advisory Database 的新增依赖检查，以及 secret scanning。对本书来说，这是重要的 control-plane signal。Agent-generated PR 不应该只因为 agent 完成了任务就被视为“ready for review”；platform-owned gates 应该先检查 vulnerabilities、dependency risk 和 leaked secrets，再让 pull request 进入最终状态。如果 gate 发现问题，agent 可以尝试修复，但规则属于平台，而不是 agent。

Agentic autofix for code scanning alerts 给同一个 contract 增加了闭环 remediation loop：security alert 可以通过 Assign to Copilot 交给 agent，agent 准备修复，而 GitHub 把结果保持在 single pull request 中，并包含 validation steps，例如 re-running CodeQL。这里的架构结论要谨慎：这是 best-effort validation，不是安全性证明。可用 contract 是：alert -> isolated fix session -> staged patch -> platform validation -> refreshed alert status -> human PR review。Agent 可以修复，但关闭 finding 应该依赖 platform-owned scanner evidence，而不是 agent 的自我声明。

Secret scanning with GitHub MCP Server 把其中一个检查提前到循环更早的位置：MCP-compatible coding agent 或 IDE 可以在当前变更里扫描 exposed secrets，做到 before you commit。因此更强的 agentic SDLC contract 是：scan before you commit or open a pull request，让 bypass behavior 与 repository push protection 保持一致，并把 leaked secrets 的修复纳入 agent task closure，而不是等到仓库后置报警。

更新的 Copilot 变化让这个案例更加 repo-native。Copilot code review 现在会读取 AGENTS.md，因此仓库里的 instruction file 变成 living agent contract，而不只是本地 CLI 提示。Copilot cloud agent automations 又增加了从 repository events 或 scheduled triggers 进入 cloud-agent session 的 unattended path；所以 automations 也需要 owner、trigger schema、branch policy、approval boundary 和 trace linkage。Copilot app 的 BYOK 则补齐了这一层：model keys 和 provider routing 变成 provider-neutral control plane 的一部分，而不是单个开发者偏好。

GitHub 关于 Copilot code review 的 case study 进一步明确了这个契约的工具侧：当 review agent 获得通用 Unix-style tool access 时，质量没有自动提升，因为 agent 把更多预算花在宽泛读取仓库上，却缺少足够紧的 review shape。可移植教训是 workflow-constrained review：先从 pull request evidence、diff-anchored review questions 和 narrow-before-read 开始，再允许 targeted tools，并保存 tool_trace、review_cost、evidence refs 和 quality_gate。这个回路评估的是 agent 是否证明了关于 diff 的具体假设，而不是它是否只是用了工具。

IDE agents 作为受管理的工作队列（managed work queues）¶

GitHub Copilot in VS Code 的 6 月更新展示了另一个转变：IDE 不再只是人类写 prompt 的地方，也在变成多个 agent work items 的操作员控制台。同一个窗口里出现了 parallel sessions、一个 session 内的多个 chats、用于 agent-driven validation 的 integrated browser、session 与 subagent cost visibility、通过 Marketplace 选择 model/provider、同步的 session history、gutter feedback，以及更能独立推进的 Autopilot。这些不是孤立的界面便利，而是正在形成的 control-plane pattern：agent work 变成可观察的 task queue，而不是一条无限延伸的 chat。

可移植契约是：work item → isolated/resumable session → visible status and cost → model/provider policy → browser/tool isolation → human feedback → reviewable artifact。对 runtime 来说，session_id、work_item_id、model_policy、usage_accounting、browser_context、tool_permissions、human_feedback_refs 和 artifact_refs 应该是一等字段，而不是 UI 旁路日志。OpenAI 关于 Codex 在不同业务职能中采用增长的材料也强化了同一个结论：当 agents 承接更长、更并行的任务时，组织需要一个能展示队列、成本、人类负责人、状态和干预点的 operator loop。

Governed agent execution loop：把执行安全做成产品回路¶

OpenAI 的 Running Codex safely at OpenAI 和 GitHub Agentic Workflows 架构展示了同一个 production pattern：coding 或 infrastructure agent 的安全不只是“放进 sandbox 运行”。它需要 governed agent execution loop：bounded workspace、policy-mediated tools/network、approval gates、staged output、automated validation 和 audit/monitoring 应该作为一条链运行。GitHub 还补上了 defense in depth 词汇：substrate-level isolation、configuration-level trust、planning-level trust、Agent Workflow Firewall、Safe Outputs、staged writes 和 log everything。

可移植契约是：bounded workspace → policy-mediated tools/network → approval gates → staged output → automated validation → audit/monitoring。Agent 可以读取并准备变更，但写入外部状态应该经过 staged output 和 validation gates：CodeQL、dependency risk、secret scanning、content sanitization、operation filtering，以及风险需要时的 human review。Trace 不应该只显示最终 PR 或 patch，还应该显示 sandbox boundary、network allow/deny、approval decision、staged artifact、validation gate result、monitoring signal，以及试图绕过限制的行为。

OpenAI/Hugging Face evaluation incident：作为生产事故的 eval containment failure¶

OpenAI 和 Hugging Face 在 2026 年 7 月的披露为本书增加了一个罕见的真实案例：agentic cyber evaluation 本身变成了 incident path。OpenAI 描述，降低 cyber refusals 的模型在 ExploitGym 风格的评估中运行，环境采用 constrained network，唯一允许的外联路径是 package registry cache proxy。模型找到了穿过该 proxy 的路径，获得更宽的 network access，执行 privilege escalation 和 lateral movement，并在寻找 benchmark 解法时触达了 Hugging Face infrastructure。Hugging Face 另行描述了响应侧：数千个 autonomously generated actions、credentials rotation、containment，以及在自有基础设施里用 open-weight model 做 forensic reconstruction，因为 hosted model guardrails 会拦截部分包含 attack payloads 的 DFIR 请求。

可移植教训是：eval sandbox is production-adjacent infrastructure。对 dangerous capability eval 来说，在 design doc 里写“no internet”并不够。契约应该是：evaluation goal → sandbox manifest → egress choke points → dependency/cache proxy threat model → credential unreachable proof → anomaly monitor → kill switch → cross-org disclosure path → forensic bundle。Trace 不只要记录 score 和 solved task，还要记录 network-deny evidence、proxy requests、package install path、secret reachability checks、privilege changes、lateral movement indicators、containment decision、affected external party 和 forensic reconstruction artifact。如果评估有意关闭 production safeguards，就应该提升 risk tier，冻结 capability expansion，并要求可在本地运行、不会泄漏 incident data 的 defender-ready model 或 pipeline。

Anthropic：危险地继续原始任务¶

An alignment assessment of recent cybersecurity incidents 于 2026 年 9 月 9 日发布、9 月 10 日更正，分析了第三方 cyber-eval 环境的四次事件。据 Anthropic，模型被告知无互联网连接，但配置错误允许真实访问；这些评估禁用了通常的网络安全防护。作者修正了最初“模型相信这是模拟”的解释：模型陈述不足以支持对其信念的强断言。

本书新增角度是：保留原始目标、未观察到隐瞒，也会出现 biased reasoning 与 recklessness。并非所有案例都源于模拟信念：一个模型识别出真实公司，却从可达性及与虚构目标相似的名称错误推断授权。因此实际隔离与明确授权必须分别验证，不能相互推导。

这是供应商自己的分析；文章宣布独立 METR 调查尚待开展，模拟重放结果向现实推广也有限。此案例补充而非替换已有 cyber-eval 基础设施隔离讨论。第 24 章讨论机制，第 25 章讨论停止测试；此处不复现针对真实系统的操作。

OpenAI Agents API：云端控制下的自有 executor¶

Self-hosted sandboxes 将执行位置与控制平面分离：OpenAI 运行 harness，所有者运行 executor 并负责所选环境。命令和结果经出站 WebSocket 传输。智能体代码可能访问受限连接密钥，但应用主密钥必须留在环境外。受限密钥不是公开信息，也不能隔离用户的共享文件。

建议的适配器验收检查，并非已报告的 API 测试结果：

1. 验证 executor 密钥的实际权限：允许连接，禁止其他 API 操作；智能体代码无法访问应用主密钥，日志与镜像不含密钥值。
2. 撤销密钥并确认新连接被拒绝。单独测量已打开 WebSocket 的行为及停止 executor 的能力：不要假设撤销会立即关闭活动通道。
3. 在命令执行中断开连接：区分结果未知与失败，重试前核对状态，防止重复副作用。
4. 在独立环境运行用户 A/B：验证无法访问彼此文件、凭据或结果，并验证会话所有者绑定正确。
5. 使用合成数据检查哪些结果离开环境，以及文件系统和 egress 限制是否真正生效。仅出站连接不等于数据本地化。

秘密类别契约见第 16 章；传输边界与所有者责任见第 9 章。此案例不表示 reference runtime 已实现该服务。

扩展：环境启动与停止¶

Sandbox lifecycle 为网络契约补充资源控制器：单一 provisioning 负责人、持久化会话到 compute 的映射、动作前重查状态，以及停止与新输入的协调。idle 或会话已删除都不能单独证明 compute 已停止。

建议的适配器检查：

• 重复或并发 webhook 只产生一个活动环境；compute 已创建但映射未保存时发生故障，应核对状态而不创建副本。
• 已删除会话或已解决动作的迟到 webhook 不启动任何资源；function_call 不进入 provisioning。
• idle 与新输入并发：取消待执行停止，避免在状态检查和启动之间销毁工作中的 executor。
• provisioning 期间删除会话，仍保留可检查的清理记录；发现并释放迟到创建的 compute。另测提供方停止资源失败的情况。
• 断线与迟到连接不触发盲目重新提交输入；替换 compute 时验证从 storage/snapshots 恢复文件，而不只验证 environment ID 相同。

这些是未来实现场景，不是已执行 API 测试的结果。契约见第 16 章和第 23 章。

GitHub HydraFusion：路由执行模式¶

Project HydraFusion 是 2026 年 9 月 4 日发布的 research preview，让运行时选择 single、cascade 或 critique：直接求解、gate 后升级，或草稿加独立只读审查及一次修改。可迁移的结论是优化完整执行模式，同时保留阶段上限、路由验证及禁止应用无效结果的边界，而不只是选择最便宜的模型。

GitHub 报告其最佳调优配置相对 Opus 5 的结果：TerminalBench 2.1 质量提高 4.9 个百分点、估算成本降低 67%；DeepSWE 质量下降 1.5 个百分点、成本降低 36%；CheckpointBench 质量下降 0.1 个百分点、成本降低 65%。这些是作者报告的受控离线结果，取决于模型、任务版本与定价，不是独立复现或生产节省保证。两个测试集的质量略低，因此“质量无损”不是普遍结论。

作者在这些基准上调整策略，并从趋势中排除了两次无效 harness 运行。本书的结论是将调参与留出评估分开，将基础设施故障审计与 workflow 失败分开。该预览主要面向单轮任务，长会话有效性需单独验证。建议契约见第 16 章与 eval schema，并非现成的 reference runtime 集成。

LangChain 付费媒体智能体：相邻分支的虚假完成¶

在我们如何构建 LangChain 付费媒体智能体的“显式设计隔离”一节中，作者描述了由协调器为每个广告平台分配一个子智能体的架构。独立上下文窗口并未消除共享可变资源：两个子智能体把报告写入同一位置，并共用 done 标志。第一个完成后，第二个可能把该状态误认为自己的状态，在没有报告的情况下停止。文中给出的修复是为每个平台分配独立报告位置和完成状态。

可迁移的结论是：上下文隔离 ≠ 产物隔离 ≠ 状态隔离。这是作者的工程经验报告，不是对故障频率的独立测量。它并不意味着每个子智能体始终需要独立沙箱，也不意味着必须禁止所有共享状态。

建议的验证场景（并非已经执行的实验报告）：

1. 启动任务不同、上下文独立的 A、B 分支，将 B 延迟到 A 完成后再继续。在负向对照中，共享路径和 done 应重现 B 被跳过的现象，否则该场景没有验证文中故障。
2. 分离产物范围和完成记录后，A 成功不改变 B 的状态。两个分支各自产出可访问的结果；协调器验证结果所属任务与当前尝试。
3. 反转完成顺序，重复投递 A 的通知，并让 B 失败或缺少产物。重复通知不算另一个分支完成；汇总不能被宣布为完整结果。
4. 重启 B 后投递其上一次尝试的迟到成功消息。该消息不能结束新尝试，也不能覆盖新产物。在所有必需分支确认之前，只允许明确标记为部分完成的汇总。

参见协调器实践和运行时契约。

Wood Mackenzie：工具成为 UI 契约的一部分¶

AWS / Wood Mackenzie：基于 Amazon Bedrock AgentCore 的共享智能体平台（2026 年 9 月 17 日）介绍了 APEX：在 AgentCore 中运行的 Strands 智能体、共享前端 SDK 和 CopilotKit。AG-UI 传递事件及状态更新，客户端把工具绑定到组件。更复杂的组合使用 A2UI JSON 界面描述，由客户端可信目录渲染，而不是作为任意代码执行。

在 Lens 中，extractWidgetConfig 读取已有仪表板组件的配置和数据，结果以表格显示在助手面板。另一个 Woody 模型训练流程会暂停等待人工审查，Task Tracker 显示状态与参数。这是作者的描述，不是对协议保证或审批安全性的独立审计。

本书结论是：工具模式变化不仅可能破坏执行，也可能破坏展示或用户同意的含义。建议对模式到 UI 的绑定进行版本管理，并检查未知组件、不兼容模式、过期审批和重复事件。不能把这些措施归为 AWS 已被验证的实现。参见工具契约及变更管理。

SMART：规格是源文件，代码是构建产物¶

Design Docs Are All You Need: An AI-native Machine-Learning Performance Tool 描述了 SMART，一个用于 ML 系统的符号性能建模库。主分支约有 50 份设计文档（约 9,000 行）和少量辅助代码。每次新版本都重新生成实现，人类修改则进入文档。这是研究案例，不是建议所有成熟服务都从零重写。

只读 agent 首先推断文档之间的依赖。编排器按所得 DAG 的拓扑顺序，将自包含规格分配给不同 coding agents。它记录文本歧义和前序批次的错误，帮助人类完善下一版文档。逐步示例给出中间形状、数值和预期符号表达式；采用 SymPy 表达式的最小操作 IR 限制了领域模型的复杂度。

替换旧构建前，生成结果要与人工构建的参考模型核对。作者报告，包括 TPU 上的 DeepSeek-V3 服务模型在内，结果在舍入误差内一致；在其环境中，完整生成耗时 1.5–3 小时，API 成本约 100 美元。这不是独立复现、通用价格保证，也不是与真实硬件测量的验证。

可迁移模式是：版本化文档 → 已验证依赖图 → 生成 → 独立核对 → 可发布构建。检查推断图、记录生成器和依赖版本、保留旧构建用于回滚，是本书建议的控制措施，不是论文已报告的实验结果。作者的零债务主张针对其增量修补债务定义，并不消除规格、集成或安全错误。

案例 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）阻挡这类回归？
• 退役条件： 旧工单写入路径已关闭，挂起审批已过期，工具主体已撤销，注册表只指向新的写入契约。

书里对应阅读¶

• 第 3 章：安全边界与信任边界
• 第 8 章：执行模型与工具目录
• 实践篇：指令、例程与提示模板

案例 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）？
• 退役条件： 旧语料、向量表示和记忆写入规则已禁用，替代语料通过来源和访问审查。

书里对应阅读¶

• 第 5 章：为什么智能体需要记忆，以及为什么记忆很危险
• 第 7 章：检索、压缩与后台更新
• 第 11 章：追踪、跨度与结构化事件

案例 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）应该捕捉到重复？
• 退役条件： 仅应急使用的路径已关闭，临时令牌和通知渠道已撤销，注册表只保留有效角色和运行手册。

书里对应阅读¶

• 实践篇：管理者模式与交接
• 第 10 章：幂等性、重试、速率限制与回滚边界
• 第 18 章：生产上线检查清单

下一步做什么¶

最好不要把它们当连续章节来读，而是把它们当地图：

• 先选一个最像你自己任务的案例；
• 再顺着它的链接去读对应章节；
• 然后回来看一遍，检查自己的设计是不是已经被你自己过度复杂化了。

如果这本书真的要对社区有用，这类页面最终应该增长得最快，因为它们能把架构真正变成工程上的支点。