实战案例¶

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

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

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

OpenAI / Ironclad：检查智能体创建的流程¶

OpenAI 于 2026 年 10 月 6 日发表的文章介绍了协议、审批和可复用法律条款的配置。智能体不仅要创建规则，还要检查金额高于和低于阈值时是否走正确路径。研究评估包含 11 个任务，每个任务有 8–50 项标准。

Astra 平均得分为 55.0%，Sol 为 41.6%；这不是完全成功任务的比例。作者使用 Astra 的 Max 推理设置和 Sol 的 High 设置。每次尝试 19.2 分钟与 37.0 分钟是估算时间，不是生产 SLO。小规模专业任务集及作者开展的研究评估不能保证任意合同流程的正确性。

本书建议独立定义低于、等于和高于阈值的矩阵，并设置不能由平均分抵消的强制标准。恰好等于阈值的场景是本书建议，不代表已发表基准的明确组成部分。参见第 13 章和评估模式。这些场景并未在 Ironclad 上执行；人工监督和业务规则验证仍然必要。

Strands Box：策略深度、可信代码与过期证据¶

Strands Box: The Big Picture介绍开发者预览版的本地沙箱。操作系统隔离强制交互经过 Dogwood 语义层；Strands Shell 与 Monty 支持对生成代码中的调用应用策略。作者承认解释器和拦截器扩大了 TCB，并建议云端多租户部署增加每会话独立的 MicroVM。这不是隔离认证，也不是对任意 Shell/Python 程序完全兼容的承诺。

以下是使用合成数据的建议检查，不是我们已经执行的 Box 测试：

1. 直接及经由 MCP、Shell、Python 请求同一被禁止的副作用。所有可用路径都应在副作用前拒绝；不支持的路径不能回退到不受限制的宿主。允许的对照操作应成功，并留下决策及执行证据。
2. 尝试通过不受控子进程或直接网络访问同一资源。阻断应来自底层隔离，而不是依赖模型主动调用策略工具。检查实际副作用未发生，而不只是 deny 日志。
3. 成功测试树 A 后，切换到不同的树 B，或修改相关文件/依赖。使用 A 的证据发布 B 必须拒绝；重测 B 并独立授权后才允许。还应覆盖决策与 push 之间发生变化的情况。
4. 重启策略层或丢失事件历史。未知状态不能变成“测试通过”；恢复必须依赖可验证证据或新测试。

层级比较见第 9 章，状态绑定证据见第 17 章。未安装该产品；这些场景未执行真实代码发布或外部副作用。

跨章节路线¶

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

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

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

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

GitHub Copilot：SDK 迁移破坏测量，而非执行¶

GitHub 于 2026 年 10 月 6 日发布的通知指出，多种 IDE 将代理会话迁移到 Copilot SDK 后，不再标明来源 IDE。仅这些版本受影响，较早版本仍被统计。多数受影响活动未出现在报表中，部分被错误归为 CLI。GitHub 表示计费未受影响，缺失数据无法回填，历史 CLI 数值也无法通过拆分混合来源来修正。

通知发布时，VS Code 1.139.0 已提供修复；其他 IDE 的版本仍待发布，计划于 2026 年 11 月前完成。这记录的是公告状态，不意味着整个客户端群已经修复。升级前相关指标仍不完整；逐步恢复的覆盖率可能看起来像使用增长。Copilot CLI 用户本身无需为此问题升级。

以下是使用合成事件的本书建议检查，不是已执行的 Copilot 测试：

1. 来源丢失。 操作已执行，但来源客户端字段缺失。最终报表显示归属不完整或 unknown，报告测量缺陷，不代入零活动或 CLI。已知来源的对照事件应正确分类。
2. 新旧客户端混合。 对旧版、缺陷版和修复版重放相同数量的测试操作，核对预期事件、最终报表及各群组覆盖率。升级后恢复统计不得被解释为执行了更多操作；重复投递不得重复计数。
3. 未知客户端误归 CLI。 真正的 CLI 与另一客户端使用相同 SDK。分类器保留前者的明确来源，将后者标为未知，不在缺少证据时追溯拆分历史聚合。修复规则不等于恢复丢失数据。

迁移检查见第 20 章，测量可信度见第 26 章。计费正确、任务成功，都不能证明分析数据完整。

AWS Lake Formation：用户权限贯穿代理工具链¶

AWS 于 2026 年 10 月 6 日发布的文章描述了在提示词和工具模式之外传递身份的方式：AgentCore 将头部交给 Lambda，由后者通过 IAM Identity Center 和 STS 交换凭据；Athena 以用户身份访问数据。示例中，具有 SELECT 的用户得到记录，没有授权的用户被拒绝。文章还描述了行列限制能力，但这不是完整过滤器测试的已发表结果。

以下是使用合成表和测试用户的本书建议检查；此次文档修改没有执行这些检查，也不代表参考运行时已提供保证：

1. 替换用户身份。 在提示词或参数中放入另一用户的标识，再单独测试属于不同用户的有效令牌。模型文本不得改变 principal；可信层拒绝不一致的上下文。检查实际返回的行列和审计身份，而不只是模型生成的拒绝文字。
2. 身份缺失或无效。 删除头部、使令牌过期或修改 audience。交换和数据访问不得退回共享角色；拒绝信息不得暴露令牌。入口认证不能证明单独的身份令牌有效。
3. 通过共享角色或保存结果绕过。 无授权用户重复有权用户的查询；另行检查没有身份上下文的路径，以及保存结果或缓存的访问。其他 IAM/S3 权限不得暴露数据。另一用户的合法对照查询仍应正常工作。

审计应关联请求、经验证的 principal、角色、Athena 查询标识和访问决定，不记录令牌；结合查询结果检查 onBehalfOf。还应单独测试授权撤销、凭据有效期以及断线后的重试：短期令牌本身既不保证立即撤销，也不防止重复使用。参见第 7 章和第 9 章。

OpenAI 托管浏览器：origin 访问与强制操作确认¶

在 2026 年 10 月 6 日核对的 Computer use 文档中，OpenAI 区分了 origin 访问与单次操作确认。单独的批准工具不能保证模型在购买或删除前调用它。对于强制控制，来源建议使用不具备这些能力的资源，或使用自己能够控制的浏览器运行时。

以下是本书建议在使用合成数据的测试网站上执行的检查，并非托管浏览器的实测结果，也不是参考运行时已实现的保证：

1. 允许 origin，但未批准操作。 测试网站可读取；删除尝试由资源的技术权限或可控运行时中经过验证的屏障阻止。分别记录 origin 许可、缺少操作批准以及资源数据未改变。无法提供该屏障的后端不能用于此场景。
2. 模型跳过批准工具。 执行器模拟器将操作直接送至执行边界。操作不得通过：检查不依赖模型是否愿意询问人类。仅记录“未调用批准工具”不够，必须检查测试资源的状态。
3. 确认过程中连接中断。 决定已提交但回执尚未收到时断线，不得重新启动任务。应用恢复同一会话，核对当前请求并移除过期表单；409 要求刷新状态，而不是提交相反的新决定。检查是否出现重复任务或意外重复操作。操作结果未知时，应与资源核对，而非盲目重试。

该案例连接第 4 章的批准边界与第 9 章的浏览器运行时选择。截图与决定成功送达只是不同阶段的证据，并不能证明操作已获授权且已完成。

Protected Quick Tunnels：外部链接是一项受治理的发布¶

Cloudflare 于 2026 年 10 月 2 日发布的文章将身份认证集中在 Access，而由 cloudflared 在本地执行授权。邀请列表留在本机，但这不代表所有流量或登录信息都留在本地。代理返回短期签名断言，绑定隧道主机名及一次性浏览器状态。连接器验证断言、消耗状态，再将邮箱与允许列表匹配。断言通过 POST 而不是 URL 传送；认证凭据在转发给应用前被移除。

作者描述的登录状态有效期为 10 分钟，本地会话最长四小时，若 Access 登录更早到期则更短。连接器终止会结束访问；这不意味着隧道本身有四小时自动寿命限制。文档区分仅供浏览器使用的邮箱登录与非交互客户端，并明确不支持 SSE。上述能力来自来源说明，不是本书实际测试服务的结果。

以下是在受控测试环境中建议执行的检查，本次补充未执行：

1. 保护未确认： 模拟未收到受保护模式确认。启动失败，不将 URL 宣告为就绪，不降级到公开模式；成功确认作为正向对照。
2. 访问者范围错误： 分别测试无会话访问者、已验证但不在列表中的邮箱及允许访问者。只有最后一种可到达无害的源站端点；域名规则测试不能由单个地址测试替代。
3. 认证交接重放： 在协议测试夹具中重放已消耗状态、过期断言，以及属于其他主机名或浏览器状态的断言。全部应在到达源站前被拒绝；全新且有效的组合应成功。这不是建议将真实代码或 cookie 收集到日志中。
4. 终止： 在会话活动时停止连接器，检查旧 URL、现有连接与重连，再以新访问者范围重启。旧会话不能授权访问新发布。已开始的业务操作需要单独核对；智能体故障不能让隧道失去负责人和关闭期限。

与本书的对应关系：第 9 章区分访问通道，第 16 章定义建议的发布契约。允许访问预览不等于允许调用任意应用工具。

Anthropic CVD：报告、审核和补丁是不同结果¶

Anthropic 漏洞披露仪表板在 2026 年 10 月 2 日 19:47 UTC 的快照中列出 29,439 个候选项、6,123 个由外部公司独立审核的发现项，以及 5,674 个确认有效项——92.7% 仅针对已审核集合。向维护者报告的 6,157 项中，1,333 项走独立审核路径，4,824 项未经同等审核直接发送。不能认为所有已确认项都已报告：作者指出审核和通知能力有限。

已知维护者回复为 5,103 项，上游补丁为 516 项。回复不等于确认漏洞；可能未回复但已发布补丁；发布不保证用户已经安装。584 个标识符（219 个 CVE 和 365 个 GHSA）覆盖整个登记表：一项发现可同时拥有两者，因此不是 584 个唯一且已修复的漏洞。

这是流程运营方的报告，不是针对随机样本的独立模型质量评估。确认有效的项可以包含已知缺陷和 wont_fix；研究人员也可能判断错误。不能将 92.7% 外推到未审核候选项或直接报告，也不能将 516 解释为实际修复总数。日期、严重性与评估来源筛选会改变队列。

可迁移的经验是保留路径和证据历史（第 21 章、事件记录模式），并以不同分母衡量未结审核队列年龄与修复耗时（第 12 章）。这些是本书建议的契约，不是仪表板承诺的保证。

LangChain Open SWE：在执行框架内选择模型¶

2026 年 10 月 1 日的文章报告了覆盖 973 个会话线程的 A/B 测试：一半使用路由器，另一半使用最强的基线模型。中位成本为 $0.94 对 $2.61（降低 64%），平均成本降低 42%，p90 降低 37%。以合并 PR 结束的线程占比为 29.2% 对 27.3%，p = 0.49。这是作者在特定流量上的结果，不证明质量相等或普遍节约。用户反馈较少；与仅用快速模型比较的第二次测试因投诉在一天内停止，尚未得到有统计意义的结果。

每个线程固定模型；子智能体独立于该路由器选择模型。统一子智能体路由与线程中途切换是未来工作。执行框架/网关职责见第 16 章，非劣效评估见第 13 章。Auto Router 案例已覆盖缓存经济性；这里新增的是任务上下文的责任归属及实验结果的解释边界。

Cloudflare Clef：概率式支持分流¶

2026 年 10 月 1 日 Clef 与 Clef-flash 公告描述了模式选项评分，以及使用 Brier 损失进行校准训练。这一训练目标不能保证模型在新的支持流量上仍然校准。作者的速度和质量测量针对其自身负载，不证明在读者数据上的优势。公告时，微调由 FDE 团队协助提供；自助平台属于后续发展。

建议示例：为支持工单评估紧急程度与目标团队，应用经过验证的阈值，路由到团队或人工。“billing”类别并不授权退款。与通用 LLM 的比较、陌生类别及自动决策错误见第 13 章；策略契约见第 17 章。这是实验计划，不是已执行的产品测试，也不是取消强制人工审批的理由。

Cloudflare AI Search：找到截图不等于验证截图¶

2026 年 10 月 1 日的正式发布公告 描述了通过 Qwen3-VL-Embedding 进行原生图像检索，同时保留描述文字，并支持为扫描 PDF 启用 OCR。使用纯文本嵌入模型时，查询图像由 ToMarkdown 转为描述文字。这并不保证识别所有细节，也不是任意答案生成模型都具备的属性。

建议示例：支持智能体要查找开关处于关闭状态的截图。两张截图的描述都是“设置页面”，但开关状态不同。智能体记录检索路径和来源修订版本，打开检索到的原件，检查相关区域，然后才给出带引用的答案。若原件不可用或清晰度不足，应报告不确定性；描述文字不能证明开关状态。

来源契约见第 7 章，三个建议场景见第 13 章。这是本书的说明性示例，不是已执行的产品测试。应根据证据是否适合任务来比较原生检索、OCR 和描述文字，而不只是检查接口调用是否成功。

Monetization Gateway：授权、执行与结算是不同阶段¶

2026 年 9 月 30 日的 beta 公告扩展了此前引用的 Monetization Gateway 计划。公告时为面向符合条件的美国买卖双方的封闭测试，描述的结算方式是在 Base 上通过 Coinbase x402 Facilitator 使用 USDC。文档采用 x402 v2：固定价格使用 exact，变动价格授权上限使用 upto。¹

买方收到 PAYMENT-REQUIRED，签署所选条件并携带 PAYMENT-SIGNATURE 重发请求。源站必须验证签名的 PAYMENT-CONTEXT；成功的变动价格响应通过 PAYMENT-SETTLEMENT 报告实际金额。这些是网关和源站之间的内部请求头，不是客户端支付契约。网关在交付结果前结算。文档说明，超过授权上限的金额按上限结算，零金额不结算；这并不保证业务正确性或响应送达。详见源站验证文档。

以下三个场景建议使用模拟器，不涉及已执行的金融交易，也不是通过测试确认的提供商保证：

1. 价格变化： 批准后价格或收款方变化。重新签名前再次评估；超过委托上限或收款方不合格时阻止。在明确允许范围内的变化不必人为强制人工批准，但仍须是可审查的策略决定。
2. 结算后响应丢失： 模拟器确认结算，客户端却未收到结果。分别保存各项结果，先核对并获取原结果，不进行新付款或重复外部动作。无法恢复时应报告“已付款但未交付”，而非“没有付款”。
3. 并发调用： 剩余预算为 10 个假设单位，两个调用各请求上限 7。只能一个预留成功，另一个等待或被拒绝。重启和重复收据不能丢失预留或重复记账；第一个结果未知不能为第二个释放资金。

第 10、16、17 章给出的是本书契约建议，并非参考运行时已实现的支付模块，也不保证付款与任意工具之间形成事务。

Cloudflare Issues：将重复错误转为有边界的调查¶

Cloudflare 在 2026 年 9 月 30 日的公告中推出公开测试版 Issues：重复异常、5xx 响应及错误日志被归为一个 issue。阈值或静默后复发自动化向配置好的编码智能体发送摘要、堆栈、日志、追踪、Worker 版本及应用补充的上下文。内置集成包括 Claude Code、Cursor 和 Devin，也可用 webhook 连接自定义接收方。深入调查所需的 Workers Observability MCP 权限必须单独配置；投递 issue 不会授予账户查询权限。

作者描述了 Workflows 中发现的两个问题：SQLite 外键错误引发的迁移重试循环，以及超过子请求限制后无法完成的删除。Cloudflare OS 提出了修复。这是作者报告的经验，不是独立复现，也不承诺自动修复任意生产故障。自动化文档区分接受投递与智能体执行；用户负责审查和发布变更。

第 26 章契约和以下三个场景是本书建议，并非 Cloudflare 已声明的保证或已执行的产品测试：

1. 相同错误突发： 同一阶段出现一千次观测，并重复投递通知。保留准确观测计数，只建立一个活动调查并追加新证据；超过总并发限制的其他任务排队。启动后、确认前崩溃时，应核对已有运行。
2. 修复后复发： 经验证的部署之后，新版本再次出现错误。创建新阶段并关联先前 PR 和验证证据，不能让永久去重键屏蔽复发。先前 PR 或没有流量的静默期都不能自动关闭新阶段。
3. 旧版本迟到事件： 修复发布后收到旧日志。保留事件时间与修订并补充历史，但无证据时不能宣布新版本回归。如果旧版本仍在服务流量，这属于另一项有效信号，不能简单丢弃。

Cloudflare Auto Router：节省取决于切换成本¶

Cloudflare 在 2026 年 9 月 30 日的文章中宣布 Auto Router 进入公开测试。筛选兼容且可用的模型后，分类器与评分矩阵结合预期质量和成本。针对长会话，文章描述了缓存读写成本及随上下文增长的切换惩罚；首选不可用时，网关可以尝试下一个合格候选。

文章指出，许多模型不能复用另一模型的推理状态，因此可能按输出费率重新推理。然而，为保留推理而优先选择同一模型家族属于未来改进，不是当前保证。零数据保留要求的筛选也列在路线图中；不能假定该产品自动满足严格的数据保留要求。

作者的内部基准包含 97 个任务，每个重复三次。Auto Router 完成 252/291 次（86.6%），总费用 $2.10；Claude Opus 5.5 完成 281/291 次（96.6%），费用 $5.91；GPT-6 Sol 完成 245/291 次（84.2%），费用 $2.64。这是使用模拟工作区工具的作者报告结果，不是独立复现，也不能证明质量相同。总成本与每次成功成本的分母不同；节省不能直接推广到另一种任务组合。第 12、13、16 章的契约及三个建议场景是本书建议，并非提供商已实现它们的证据。

Cloudflare Containers：工作区拥有自己的镜像版本¶

Cloudflare 在 2026 年 9 月 30 日的文章中描述了 durable_object 调度：控制器代码在启动时选择镜像和实例规格。“Rollouts are now just code”一节展示了灰度、固定活动项目版本、检查点迁移以及未来启动的镜像选择。文件系统快照宣布进入公开测试阶段；保存文件不等于承诺进程续跑或跨镜像自动迁移状态。

可迁移的经验是：发布新默认值与迁移具体工作区必须分开。第 16、20 章中的不可变镜像身份、代次和兼容性检查是本书建议，并非 Cloudflare 已声明的保证或参考运行时已实现的功能。

以下三个合成数据验证场景是建议，不是已经执行的实验结果：

1. 任务中升级： v1 命令运行时发布 v2。活动工作区在协调边界前保持 v1；新的灰度工作区获得 v2，迟到的 v1 命令不能在新代次执行。
2. 固定环境重启： 改变默认值后重启 v1 工作区。应获得同一不可变镜像；若不可用或已撤销则明确停止。验证保存文件，而不只检查启动成功。
3. 写入后回滚： v2 修改测试文件格式，并在模拟外部服务中产生副作用。为未来启动选择 v1 不能宣称这些变更已撤销；不兼容的重启应阻止，等待独立恢复，且未经核对不得重复副作用。

Cloudflare：自适应 WAF 测试与指标的虚假成功¶

在 2026 年 9 月 29 日的文章中，Cloudflare 描述了在获准客户预发布环境中测试一种 WAF 配置。45 个场景中，44 个覆盖六类攻击，另一个涉及日志注入。模型提出变体并另行评审响应，但发送由代码控制：主机名允许列表、禁用重定向、尝试记录及硬性上限。模型看不到 WAF 内部规则，也不能部署防护规则。

作者报告了 1,107 次已记录尝试和 607 个审查后结果：558 个被阻止请求与 49 个值得调查的 WAF 相关发现，其中 48 个涉及 CMDi 和 SSRF。审查排除了格式错误、无害、范围外的观察和到达目标前的失败，并合并重复项。49 不是已确认入侵数，607 也不是原始尝试总数。这些聚合值不能确定成功利用率。

一个有启发性的请求返回了重定向，而非预期的阻止页面：它被保留为通过边缘防护的观察，但没有成功源站响应或应用效果证据。其他变体可能因为变得无害而“成功”通过。可迁移的结论是分别检查传输、防护决策、语义和效果，不能依赖单一模型评分。

结果针对特定配置：Attack Score 阻止 ≤30 的分值，完整启用 Cloudflare Managed Ruleset，OWASP Core Ruleset 使用 Paranoia Level 3；测试 User-Agent 被允许通过自动流量控制。这不是所有防护层或单条规则的测量，也不保证其他配置的表现。发布修改前，发现经过工程复现和误报风险检查。本书建议与三个合成场景见评测模式；此处引用作者结果，不是独立复现实验。

Cloudflare CryptoLabe：独立扫描之间共享冷却期¶

在 2026 年 9 月 29 日的文章中，Cloudflare 描述了仍在演进的内部密码学清单工具 CryptoLabe。本案例关注负载控制，而非密码学：仓库扫描有各自的持久协调器，并通过 AI Gateway 调用模型。并发增加后出现 HTTP 429，独立重试进一步放大突发请求。作者报告使用一个全局 Durable Object 调节每个模型请求，包括重试，并把一次扫描触发的冷却共享给其他扫描。

文章没有给出该调节器的通用恢复算法，也没有证明其他系统可达到某个特定 SLO。以下是本书建议的三个场景，不是已经执行的 CryptoLabe 测试：

1. 同时出现 429。 同一配额池中的多个运行遇到临时限流。并发更新不能缩短共享暂停；新请求等待后逐步消耗许可。独立配额池中的对照运行不应被阻塞，过期任务不能发送。
2. 重试绕过。 SDK 或 workflow 在失败后重试。实际网络尝试计数应表明，首次请求和重试都取得了共享准入；隐藏重试或重新入队均不能重置尝试预算。
3. 协调器重启。 在冷却期间、队列非空且已发出许可时停止协调器。新所有者恢复或保守核对状态，阻止旧所有者继续发放许可，不一次释放整个队列。已发送请求的未知结果在核对前仍是未知。

第 10 章定义共享配额范围和准入规则，第 16 章描述协调器位置与恢复。共享队列不得跨租户暴露请求内容，也不得借用其他运行来扩大权限。

Cloudflare Kitesurf/WebMCP：执行与确认是不同能力¶

2026 年 9 月 28 日的 Kitesurf 更新增加了 WebMCP；限制文档另行指出，尚未实现 tools 权限策略、基于 origin 的工具过滤，也不通过 CDP 提供 iframe/popup 中的工具。智能体 CDP 会话没有实时视图，因此人无法完成等待交互的工具，例如演示中的 complete_booking。playground 中存在手动 WebMCP 面板，但它不能在已经等待的智能体会话内提供确认。不能把这些限制推广到所有 WebMCP 实现，也不能将其解释为 Kitesurf 完全没有隔离。

以下是本书建议的负面场景，并非已经执行的供应商测试：

1. 发现后发生导航。 发现工具后改变 origin，或在同一 origin 内替换文档，再使用旧引用调用。适配器应拒绝过期绑定；新页面上的同名工具不能继承旧授权。
2. 没有 UI 的确认。 在缺少人工通道的后端上选择已知需要人工交互的工具。敏感调用应在执行前被阻止并说明原因；若交互要求在调用后才被发现，应限制等待并核对结果，不能盲目重试。
3. 审批后替换上下文。 修改账号、参数或工具定义。即使 URL 不变，旧审批也不能授权新调用。
4. 目录不完整。 将必需工具放入 iframe/popup。Kitesurf CDP 未发现它意味着发现能力有限，而不是证明功能不存在；改用其他路径不能绕过策略和确认。

实践结论：第 9 章描述后端矩阵，第 16 章描述可验证的调用绑定及有界等待。协议支持、功能可用性和动作授权必须分别检查。

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 章。

AWS Lambda MicroVMs：谁可以终止共享环境¶

OpenAI Cookbook 的 AWS 示例用具体共享资源扩展前述案例：主智能体与子智能体使用同一台 MicroVM。示例检查 hello.txt 的创建与下载，挂起恢复模式检查跨轮次文件持久性。这是在描述示例检查，不表示我们运行过 AWS 基础设施或证明了任意应用的可靠性。

新增重点是终结事件范围及相互独立的时钟。子智能体终结流事件不能清理整台 VM；主智能体通过 event.turn.subagent_id: null 识别。最后一轮结束后，应用取回文件、调用 TerminateMicrovm 并验证 TERMINATED。仅有 agent.session.failed webhook 不能覆盖所有轮次失败。基础设施空闲计量入站流量，而非 executor 出站活动；仅向 Agents API 发输入不会唤醒挂起 VM。总生命周期包含运行和挂起时间。完整契约见第 16 章。

以下是受控测试环境中的建议场景，本次未执行：

1. 子智能体先完成： 主轮次仍运行时交付子分支终结事件。VM 保持运行；最后一个主轮次完成并取回文件后，清理确认 TERMINATED。迟到的旧轮次重复事件不得停止新代次 VM。
2. 等待输入前收到 idle： 在 AWS 适配器中复现上文生命周期竞态；控制器不能仅因 idle 而终止。对挂起 VM，新输入需通过显式恢复或启动器，随后 executor 连接并读取保留文件；输入已提交不等于已唤醒。
3. 只有出站工作、没有入站流量： 设置较短 idle 限制并持续执行测试工作。验证 VM 的实际状态变化且没有虚假的成功报告，再用覆盖负载的限制重复测试。另在 idle 预算充足时耗尽总生命周期，并检查挂起时间计入情况。恢复不得盲目重复结果未知的操作。

不要把短计时器测试当作生产 SLO 结论。应核对负责人、当前轮次、VM 与保留结果的一致性；防止重复资源配置以及会话删除与计算释放分离，已在上文说明。

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：事故协调智能体¶

Cloudflare：固定证据与三种负面状态¶

Cloudflare 于 2026 年 10 月 7 日介绍的 Managed Defense先进行确定性收集，再分析；专家获得有边界的证据包，建议保留覆盖缺口。证据不足时，不提供分类或处置结论建议。分析人员仍负责决策和缓解措施。来源描述的是面向符合条件告警与案件的早期测试版，而非通用准确性保证或自动修复事故。

以下是在合成数据上建议进行的检查，不是我们已执行的服务测试：

1. 来源超时： 保留本地观察，将不可用的全局检查标为 not_checked；不能捏造广泛攻击活动存在或不存在的结论。
2. 空结果： 已完成查询返回零，但已知收集有缺口。记录 checked_no_match，而非“没有威胁”；暂不提供依赖完整性的建议。
3. 有依据的不存在： 一个封闭时间窗口的完整合成日志，且所有事件的送达已验证，显示没有某项具体操作。仅允许限定范围的 absence_supported 结论。删除部分日志后，该结论不再允许；加入该操作后应记录正向发现。这不能证明其他威胁不存在。
4. 他方引用： 有效标识指向其他租户或调查的记录。在模型接收前阻止准入，并拒绝最终建议中的替换引用。同一案件中有效但不能支持断言的引用，也应无法通过支持性复核。

参见第 21 章和事故记录模式。结果比较使用同一保存的证据包；新数据需要新版本，并重新考虑受影响的结论。这些检查未使用真实客户数据或缓解工具。

系统做什么¶

这个智能体在事故处理中帮助团队：

• 收集监控信号；
• 用上下文补全它们；
• 创建事故线程；
• 提议下一个运行手册步骤；
• 把任务交给正确角色。

这已经不只是一个聊天助手，而是一个运行系统组件。

为什么这里尤其需要编排纪律¶

这个场景特别容易犯两种错误：

• 做出一个过载的管理者智能体；
• 或者太早引入交接，结果责任被弄丢。

通常比较好的起点是：

• 接收和协调使用管理者模式；
• 只有真正进入另一条角色边界时才做交接；
• 所有写动作都走能力契约。

主要风险¶

• 噪声告警下的虚假确定性；
• 重复副作用；
• 交接过程里审计轨迹丢失；
• 运行时权限过宽。

架构里最重要的点¶

• 整个事故运行共享一条追踪；
• 每次交接都有明确负责人；
• 工单和通知具备幂等性；
• 高风险修复动作需要人工审批。

运营最低要求¶

• 成功标准： 事故有一条统一追踪（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 章：生产上线检查清单

下一步做什么¶

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

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

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