智能体、框架与沙箱

智能体不等于给模型配上一段目标更宏大的系统提示词。它是一套软件系统：反复询问模型下一步该做什么，解析模型提出的方案，判断方案是否获准，执行已经批准的外部操作，记录结果，再决定是否继续。模型只是这个系统中的一个组件，不是调度器、授权服务、持久化存储或安全边界。

ReAct 研究提出了一种广泛使用的模式，把模型推理与外部环境中的操作交替进行 (Yao et al. 2023)。这种模式解释了如何生成一条行动轨迹，却没有提供生产运行时所需的控制。实际系统还必须补上类型化操作、完整中介、有界执行、持久化状态、故障恢复、人工审批、隔离和证据记录。

因此，实践中的基本单位是一项智能体发布：智能体执行契约、带版本的控制器、受治理的工具集、隔离策略、评估报告和可逆的部署。第 38 章 介绍行为模式，第 41 章 介绍持久化运行时。本章把二者与工具协议和沙箱约束连接起来。

固定智能体执行契约

选择框架之前，先固定智能体执行契约。契约说明一次运行可以完成什么、允许产生哪些外部操作、什么证据能够证明成功，以及系统如何安全停止。没有这份契约，一个偶然给出合理答案的演示很容易被误认为可靠的应用。

契约字段	需要记录的证据
任务边界	接受的请求、排除的用途、支持的环境和工作单位
成功证据	最终答案检查、外部终态检查、必需制品和不确定性处理方式
允许的外部操作	读取、创建、更新、删除、通信、付费、部署或执行，以及各自的资源限制
权限	用户或工作负载主体、租户、受委派执行者、允许使用的工具、权限范围和有效期
数据边界	模型与工具可以读取的输入、可以离开边界的数据、保留期限和脱敏要求
预算	步骤、词元、成本、墙钟时间、并发、存储和网络上限
人工控制	需要预览、审批、双人复核或禁止执行的操作
终止条件	成功、拒绝、取消、超时、预算耗尽、重复失败和无进展规则
恢复	检查点边界、重试策略、幂等性、补偿和继续执行的目标位置
回滚	上一已知正常的控制器、工具清单、策略、沙箱镜像和部署路由

“解决客户问题”不是任务边界。可执行的契约必须明确记录系统、客户范围、允许读写的操作、可以披露的字段、证明工单已经关闭的证据，以及必须升级给人工处理的条件。契约还要区分草稿与实际操作。起草退款申请和实际退款是两种不同的能力。

契约需要与完整的服务系统一起版本化，其中包括模型修订版本、提示词与上下文构建器、工具 Schema、策略、控制器、记忆规则、沙箱镜像和解码设置。即使框架包没有变化，其中任何一项改变也可能改变行动轨迹。

明确控制循环

受信任的控制器把随机的模型方案变成受治理的状态转移。可以用下面这组式子概括：

$$\begin{aligned} u_t &\sim \pi_{\theta}(\mathord{\cdot}\mid C(s_t)), \\ a_t &= V(u_t), \\ d_t &= A(p_t,a_t,r_t), \\ o_t &= \begin{cases} X(a_t), & d_t=\mathrm{allow}, \\ \bot, & \text{otherwise}, \end{cases} \\ s_{t+1} &= \delta(s_t,a_t,d_t,o_t). \end{aligned}$$

其中：

• $t$ 是步骤编号，$s_t$ 是当前的持久化运行状态；
• $C$ 是上下文投影，负责从状态中选择一个有界视图并序列化后交给模型；
• $\pi_{\theta}$ 是参数为 $\theta$ 的模型分布，$u_t$ 是一次采样得到的模型方案；
• $V$ 负责 Schema 验证和规范化，$a_t$ 是经过验证的候选操作或最终答案；
• $A$ 是外部授权函数，$p_t$ 是经过验证的主体和策略上下文，$r_t$ 是当前资源快照，$d_t$ 是 allow、deny 或 approve 三种授权决定之一；
• $X$ 是持有受控凭据的工具执行器，$o_t$ 是工具返回的观察结果，$\bot$ 表示没有执行工具；
• $\delta$ 是确定性的状态转移函数，它追加已经记录的事件，并生成下一步的持久化状态 $s_{t+1}$。

随机过程到模型提出方案为止。Schema 验证可以拒绝格式错误的参数，却不能判断一笔语法有效的转账是否获得授权。策略判断必须在模型之外，使用经过验证的身份和当前资源状态。策略要求时，人工审批是另一项独立决定。只有授权通过后才执行工具，而工具返回的内容应当作为不受信任的数据记录，不能悄悄升级成新指令。

区分不同类型的状态

“记忆”一词过于宽泛，无法直接指导恢复设计。一次智能体运行通常至少包含五类状态：

状态类别	常见内容	必须采用的处理方式
对话历史	用户消息、模型消息和工具结果	只通过有界上下文投影使用；需要脱敏；不能充当外部事实来源
工作状态	计划、选中的记录、中间制品和待解决问题	使用类型化 Schema 和带版本的更新；只有明确声明信息损失后才能压缩
持久化执行状态	当前节点、尝试次数、计时器、等待、租约和取消状态	继续执行前必须持久化；需要与控制器升级兼容
外部状态	数据库行、工单、付款、部署和运行之外的文件	修改前重新读取；使用稳定身份；保留外部操作回执或补偿路径
长期记忆	跨运行的偏好、事实和摘要	单独管理来源、授权、保留期限和删除策略

消息会话不是工作流检查点。检查点也不能证明外部副作用已经发生或尚未发生。追踪记录不会自动成为可重放的事件日志。把这些对象统称为一种“记忆”，会导致重复写入、使用陈旧审批，以及从错误的外部状态开始恢复。

按预先声明的原因停止

每次运行都必须设定步骤预算、词元预算、成本预算和墙钟时间期限。系统还要在达到连续失败上限或触发无进展检测时停止，例如反复执行相同操作，或任务状态始终没有变化。每个工具调用还需要自己的期限和输出上限。

终止原因属于 API 的一部分：succeeded、failed、refused、cancelled、timed_out、budget_exhausted 和 needs_human。因超时、取消或预算耗尽而结束的运行，不能报告为模型失败。运行进入终止状态后，不得以同一身份继续执行；重试必须创建一次关联的新尝试，获得新的租约，并明确记录恢复决定。

先选择控制语义，再选择框架

框架名称重叠严重，变化速度也远快于底层控制模式。先选择一种能把必需状态转移显式表达出来的模式，再验证候选库是否真正实现了这些语义。

控制模式	适用情况	主要设计责任
线性循环	一个控制器负责选择工具或结束任务，分支很少	限制循环次数，让每项外部操作都经过同一道授权门
状态图	需要显式表达分支、循环、汇合、等待和升级	对节点和边做版本管理，定义状态迁移与汇合语义
持久化工作流	工作必须经受长时间等待、工作进程丢失、回调和重试	把确定性控制与外部活动分开，让外部操作能够安全去重
文件系统运行框架	任务涉及编辑、测试、浏览代码库或操作 CLI	治理工作区、命令、进程、网络、制品和上下文压缩
监督者与工作进程	独立子任务可以由同一负责人统筹并行执行	为每个工作进程设置类型化信封、更窄权限、预算和返回契约

交接会把下一轮交互的责任转给接收方；有界的子智能体调用不会这样做，父智能体仍然负责，并等待返回结果。扇出与汇合还需要明确部分失败、取消、顺序和答案冲突的处理规则。“多智能体”这个名称本身不提供这些语义。

不要使用产品排行榜，应当建立一张能力矩阵：

能力	需要向候选运行时确认的问题
拓扑	线性流程、循环、扇出、汇合和交接是显式结构，还是隐藏在宿主代码里？
状态	哪个状态是权威来源，何时提交，检查点语义是什么？
恢复	崩溃后，重试、继续执行、取消、超时和进行中的任务分别如何处理？
并发	哪些更新可能竞争，冲突如何解决，后代任务能否取消？
审批	运行时能否连同具体候选操作一起暂停，并且只在重新授权后恢复？
工具边界	是否支持 Schema、策略钩子、幂等键、结果验证和错误分类？
提供商可移植性	哪些模型与工具功能确实能跨提供商、传输协议和修订版本运行？
证据	能否导出追踪、事件历史、策略决定、外部操作回执、用量和终止原因？
演进	控制器、Schema 或状态迁移后，等待中的运行能否继续执行？
运营	团队必须自行托管、修补、备份、计量和支持哪些部分？

现有库以不同组合提供这些能力。LangGraph 记录了带检查点的图状态和中断机制；Pydantic AI 把持久化执行交给工作流集成；OpenAI Agents SDK 同时记录了管理者式编排和交接 (LangChain 2026; Pydantic Services 2026; OpenAI 2026)。这些事实只适合作为本地验证的输入，不是通用产品推荐。

对每个候选框架运行同一套验证工作流：执行两次读取、一次需要审批的写入、一次扇出与汇合，再检查最终状态。让工作进程在外部写入成功但回执尚未保存时崩溃；把同一个回调发送两次；取消正在执行的工具；在等待审批时升级控制器，然后恢复运行。测量重复操作、工作丢失、状态分歧、延迟、成本和运营投入。这些证据比功能列表更经得起时间检验。

让外部操作可安全恢复

持久化执行能够保留控制状态，却不能让跨外部系统的操作自动获得“恰好一次”语义。工作进程可能已经完成写入，却在记录响应前崩溃，于是控制器面对的结果不明确。许多任务队列还采用至少一次交付，同一个逻辑请求可能被处理器收到多次。

因此，每项逻辑外部操作都需要：

• 根据运行身份和逻辑操作生成稳定的幂等键，而不是按网络尝试生成；
• 在发出请求前写入一条意图记录；
• 保存一份外部操作回执，记录外部操作身份、观察到的资源版本、结果和时间；
• 提供对账操作，用来查询结果不明确的请求；
• 当外部 API 无法安全去重时，提供补偿或升级处理路径。

所有重试必须沿用同一个幂等键。重试策略还要区分传输故障、可重试的工具故障、业务拒绝、策略拒绝和未知结果。“最多尝试一次”可以避免自动重复，却可能丢失工作；“至少尝试一次”则必须处理重复操作。两者都不能证明现实世界中恰好发生一次操作。持久化工作流文档同样区分可重放的控制逻辑与外部活动 (Temporal Technologies 2026; Amazon Web Services 2026)。

继续执行、重放和重新评估回答的是不同问题：

• 继续执行从持久化边界接续尚未完成的运行。
• 工作流重放根据已记录事件重建控制状态，不会重复已记录的外部操作。
• 已记录输出的测试重放把保存的模型和工具输出交给新的确定性控制器代码。
• 实时重新评估再次调用模型和工具，因此可能产生不同轨迹。

等待中的运行必须明确绑定版本。控制器或工具契约发生变化时，运行时只能迁移已保存状态、继续使用固定的旧版本，或安全终止。不能用新语义重新解释旧审批或旧的外部操作回执。

使用类型化信封委派任务

子智能体的权限范围必须窄于父智能体，不能复制父智能体的全部权限。委派信封应记录：

delegation:
  parent_run_id: run_85a
  child_run_id: run_85a_research_2
  objective: "Compare the two named incident records"
  input_refs: [incident_104, incident_119]
  permitted_tools: [read_incident, search_runbook]
  authority_scope: {tenant: acme, access: read_only}
  budget: {steps: 12, tokens: 18000, wall_clock: 5m}
  deadline: 2026-08-07T18:30:00Z
  result_schema: incident_comparison_v2
  completion: "return evidence for every difference"
  return_owner: run_85a

父智能体负责验证结果，并继续为后续产生的任何外部操作负责。子智能体不能扩大工具集、延长截止时间，也不能委派超出自身范围的权限。取消会沿所有权树向下传播；取消后才到达的结果仍需记录，但不得触发新的外部操作。

把每个工具都当作外部操作契约

只有工具名称和 JSON Schema 还不够。控制器还需要知道工具会读取或改变什么、需要什么权限、可能如何失败，以及重复调用是否安全。

带版本的工具契约包括：

字段	含义
身份	命名空间、工具版本、实现或软件包摘要，以及负责人
输入 Schema	严格类型、边界、枚举、必填字段，以及拒绝意外属性的规则
输出 Schema	类型化结果、外部操作回执、来源、脱敏和最大尺寸
前置条件	所需资源状态、调用方身份、租户和策略版本
后置条件	能够证明成功的可观察状态，而不是一句令人放心的消息
外部操作类别	只读、可逆写入、不可逆写入、通信、付费或代码执行
幂等性	业务键、重复调用行为、对账和补偿
运行约束	超时、取消、可重试错误类别、速率与并发上限，以及错误分类
数据与权限	数据分类、允许的目标位置、凭据范围和审批规则

执行器必须在真正执行时再次验证参数。即使控制器已经检查过，它仍要核对主体、租户、资源、当前版本和策略。这就是 Saltzer 与 Schroeder 所说的完整中介和最小权限 (Saltzer and Schroeder 1975)。工具服务器不能把模型提供的资源句柄当作所有权证明。

工具结果同样不受信任。网页、电子邮件、文档、议题或数据库字段都可能包含间接提示注入。InjecAgent 和 AgentDojo 的结果表明，受到污染的外部内容可能诱导会调用工具的智能体执行有害操作或泄露数据 (Zhan et al. 2024; Debenedetti et al. 2024)。工具返回的文本不能授予权限、修改策略、批准等待中的操作或扩展工具清单。应当把它作为带来源信息的受污染数据处理。

把审批绑定到实际执行的操作

人审批的是具体操作，而不是模型给出的摘要。审批界面需要展示工具、规范化参数、目标资源、当前资源版本、主体、租户、即将离开边界的数据、预期后置条件，以及回滚方式或不可逆性。审批记录需要包含这份内容的摘要、审批人、策略版本和有效期。

执行前，受信任的代码必须再次核对权限和资源状态。如果参数、资源、主体、策略版本或相关状态已经变化，原审批立即失效，运行时必须重新授权或再次请求审批。审批不能作为可重复使用的不记名权限凭证，也不能以秘密令牌的形式进入模型上下文。

把 MCP 当作传输协议，而不是信任标记

模型上下文协议（MCP）统一了工具发现与调用、Schema、传输协议、协议元数据和可选的 HTTP 授权。最终发布的 2026-07-28 版本采用无状态协议核心：请求元数据携带协议修订版本和能力，有状态工具则显式暴露应用句柄 (Parra and Delimarsky 2026; Model Context Protocol 2026)。

这种互操作性存在明确边界。客户端与服务器仍需采用兼容的修订版本、传输方式、内容类型、授权流程和扩展。必须针对实际部署的客户端与服务器组合测试版本协商和能力协商。符合传输格式不能授予信任、业务权限、安全重试语义、数据权利，也不能自动批准新发现的工具。

具体而言：

• inputSchema 和 outputSchema 只能验证数据形状，不能定义前置条件、后置条件、外部操作类别或权限。
• JSON-RPC 请求 ID 用于关联协议消息，不是业务幂等键。
• 状态句柄只是名称，不是权限凭证。每次调用都要重新核对所有者和租户。
• 工具发现只是清单，不是背书。固定服务器身份、软件包摘要、Schema 摘要和已经审查的工具清单；意外变化必须进入隔离区。
• 网关可以集中处理路由、计量和策略，却不能替代 MCP 服务器与外部资源自身的授权检查。

MCP 中的 HTTP 授权是可选功能。启用后，客户端和服务器必须验证签发方、签名、有效期、令牌受众和目标资源。授权规范禁止令牌透传：服务器不能接受原本签发给其他服务的令牌，再把它转发到下游 (Model Context Protocol 2026)。客户端访问 MCP 的凭据必须与 MCP 服务器访问下游的凭据分开。拥有环境权限的代理否则会变成混淆代理，因此还需要逐客户端同意、受众绑定、最小权限范围和独立的资源授权 (Model Context Protocol Contributors 2026)。

本地 stdio 服务器是子进程，拥有从宿主继承的权限。只能运行已经固定版本并审查过的二进制文件，使用无特权身份，并明确限制文件系统、环境变量、进程和网络。通过 MCP 调用子进程并不会隔离它。

从威胁模型出发定义沙箱

沙箱（sandbox） 是一条执行边界，用来承载行为不可信的代码和进程。它可以降低模型被攻破、工具输出受污染、依赖恶意或普通程序错误造成的后果。沙箱不能判断操作是否获得授权，也不能让原本不该披露的数据变得安全。

首先建立威胁模型，明确攻击者和需要保护的资产：

• 主机逃逸或访问其他租户；
• 跨租户或跨运行的数据泄露；
• 通过网络、日志、制品或获准服务进行数据外泄；
• 通过 CPU、内存、进程、磁盘、输出或网络消耗造成拒绝服务；
• 软件包、镜像、扩展和构建脚本带来的供应链执行风险；
• 在覆盖层、快照、缓存、日志或外部 API 中形成非预期持久化；
• 窃取或重放凭据；
• 受信任操作人员滥用权限，或控制平面遭到入侵。

沙箱保证由多项条件共同构成，缺一不可，而不是一个产品标签：

$$\begin{aligned} G ={}& K \land P \land F \land N \\ &{}\land I \land R \land T \land C. \end{aligned}$$

其中，$G$ 是所声称的沙箱保证；$K$ 是内核或系统调用边界；$P$ 是进程、用户、进程间通信和租户隔离；$F$ 是文件系统、挂载、设备和制品隔离；$N$ 是入站与网络出站策略；$I$ 是工作负载身份和凭据权限；$R$ 是资源控制；$T$ 是工作区生命周期、持久化、清理和数据残留控制；$C$ 是控制平面的完整性、修补、审计和配置。如果威胁模型所需的任意一项缺失，整体保证就不成立。

按调用路径比较隔离机制

机制	引入的边界	重要限制
加固容器	Linux namespace、cgroup、capability、seccomp 和 LSM 在共享主机内核上约束进程	正确配置和主机修补仍然关键；应用系统调用会到达共享内核实现
用户态内核	类似 Sentry 的层重新实现大部分来宾 ABI，只向宿主发出有限的调用	用户态内核、文件代理、宿主内核和控制平面仍在信任范围内；兼容性与成本取决于具体工作负载
微虚拟机	来宾内核和虚拟设备模型运行在 VMM 与硬件虚拟化边界之后	VMM、KVM、宿主内核、jailer、存储、网络、快照路径和控制平面仍在信任范围内
语言隔离环境	V8、WebAssembly 或其他运行时只暴露一组刻意缩小的宿主 API	只适用于能装入该 API 的任务；宿主绑定和运行时实现本身就是边界
浏览器进程	渲染器沙箱和站点隔离把恶意网页内容与高权限浏览器组件分开	浏览器控制仍然能够触及账号、Cookie、下载、本地端点和真实外部操作

Firecracker 展示了小型虚拟机监视器如何为无服务器工作负载组合独立的来宾内核和精简设备模型 (Agache et al. 2020)。gVisor 在应用与宿主之间加入用户态应用内核，避免把应用系统调用直接交给宿主，但它的 Sentry 和宿主接口仍然属于可信计算基 (gVisor Project 2026)。NIST 的容器指南也把镜像、注册表、编排器、运行时、宿主和数据视为不同风险区域 (Souppaya et al. 2017)。

不存在适用于所有场景的唯一答案。微虚拟机、用户态内核、加固容器、语言隔离环境或浏览器执行器，都可能在特定威胁模型下成立。应采用纵深防御，并测试实际配置。启动时间、密度、兼容性、加速器、快照支持和成本都必须针对工作负载实测，不能当作隔离能力的证明。

定义完整的沙箱边界

只给出隔离机制名称，会遗漏大部分运营权限。可部署的边界需要固定所有约束点：

sandbox:
  image_digest: sha256:<immutable-image>
  runtime_revision: <runtime-and-host-policy-version>
  identity: {tenant: acme, run_id: run_85a, uid: 10000}
  filesystem:
    root: read_only
    inputs: [{digest: sha256:<input>, mode: read_only}]
    workspace: {mode: fresh_overlay, max_bytes: 2147483648}
    devices: []
  network_egress:
    default: deny
    allowed_destinations: [artifact-mirror.internal]
    methods: [GET]
    max_bytes: 104857600
  resources:
    cpu: 2
    memory_bytes: 4294967296
    process_count: 128
    disk_bytes: 2147483648
    open_files: 512
    output_bytes: 16777216
    wall_clock: 10m
  workspace_lifetime: one_run
  artifacts: {allow: [result.json], scan: true, hash: true}
  cleanup: {lease: 15m, revoke_credentials: true, verify_process_tree: true}

运行时在工作负载之外执行文件系统挂载、只读输入、网络出站、CPU、内存、进程数、磁盘、文件描述符、输出量和墙钟时间限制。限制必须覆盖所有后代进程，而不只是第一个进程。允许访问的网络目标要通过受信任的 DNS 解析，并在使用时重新验证；IPv4、IPv6、重定向、替代协议和元数据端点都必须服从同一策略。

把凭据留在工作负载之外

关键约束不是“任何受信任组件都不得持有凭据”，而是不受信任的执行环境不能获得可重复使用的环境权限。优先在沙箱外使用语义操作代理。若必须直接访问模型，使用由 网关（gateway） 签发的 虚拟密钥（virtual key），也就是有明确范围和短有效期的提供商密钥替代物。原始提供商密钥不会进入沙箱。

访问其他服务时，应签发绑定工作负载身份、租户、受众、资源、操作和有效期的短期令牌。服务无法签发此类令牌时，可以让受信任代理执行出站替换，把占位符换成真实凭据，但代理必须把请求绑定到确切的目标、方法、路径、配额和操作。否则，这个代理本身就成了持有凭据的混淆代理。凭据不得写入镜像、工作区快照、导出制品、崩溃转储、模型上下文或日志，租约结束时必须撤销。

默认拒绝的网络策略很有必要，却仍不完整。还要测试 DNS 重绑定、重定向、原始 IP 地址、IPv6、WebSocket、向获准主机上传数据，以及云元数据端点。允许访问某个主机名，不等于允许在该主机上执行任意操作。

把工作区状态视为受治理的制品

每次临时运行都应从干净基线创建，固定不可变镜像摘要，并显式声明只读输入。记录输入摘要、依赖锁文件、工具版本、运行时和内核修订版本、区域设置、时钟与随机性策略、资源限制和网络夹具。工作区快照是可变状态，不是干净基线，其中可能残留进程、凭据、随机数状态、缓存和恶意文件。

只导出预先声明的路径。扫描输出中的恶意软件、秘密、意外代码库、链接、设备文件、压缩包和可执行内容。控制器消费或发布制品前，必须记录每个输出摘要和制品来源。失败或可疑输出进入隔离区。重置测试需要证明，新运行无法读取上一运行写入的金丝雀数据，包括经由快照、缓存、后端卷、日志或导出镜像读取。

持久化工作区是另一项功能，需要单独的保留与授权策略。暂停进程不会让状态变得安全或可复现。删除覆盖层也不会清除外部 API 操作、备份或保留日志。

为浏览器智能体设置两道边界

浏览器智能体同时需要网页内容隔离和租户隔离。全新的浏览器配置文件为每次运行分开 Cookie 和存储。渲染器沙箱与站点隔离负责约束恶意页面；外层的微虚拟机、用户态内核或加固容器负责保护代理和其他租户。另一套操作策略还要约束导航、下载、上传、剪贴板、文件 URL、本地地址与元数据地址、登录状态下的写入和付款。

WebDriver 是高权限远程控制接口，不是不受信任的工具端点 (World Wide Web Consortium 2026)。不要把它暴露到沙箱网络，也不要复用个人浏览器配置文件。浏览器沙箱可以限制渲染器代码，却无法阻止自动化浏览器滥用一个本来合法的账号。

通过受治理的边界连接运行时

控制器使用各项服务，但不充当信任中心。模型、工具、状态和计算资源必须经过各自独立的约束点。

第 82 章 和 第 88 章 中的模型网关控制模型身份、路由、预算和用量。工具代理验证调用方，授权具体操作，并获取范围尽可能小的凭据。沙箱监督器分配隔离边界，执行资源和出站策略，并对账清理结果。持久化状态记录决定和回执。任何一份网关日志都不足以证明四条路径的完整行为。

记录能够支持恢复和审计的证据

可观测性追踪用于诊断运行，审计记录用于支撑问责结论，事件日志用于恢复状态。三者可以共用标识符，却不能混为同一个对象。

至少需要记录：

• 运行 ID、尝试 ID、追踪 ID、父 Span、时间戳和控制器修订版本；
• 用户或工作负载主体、租户、受委派执行者和权限有效期；
• 模型修订版本、提示词与上下文构建器版本、词元用量和延迟；
• 工具版本与 Schema 摘要、规范化参数摘要、资源身份、策略决定、策略版本和拒绝原因；
• 审批人身份、获批操作内容的摘要、有效期和重新验证结果；
• 幂等键、重试次数、外部操作回执、外部状态版本和补偿操作；
• 沙箱镜像摘要、运行时策略、资源用量、网络目标、制品摘要和清理证据；
• 终止原因、成功证据、尚未解决的不明确结果和上一已知正常发布版本。

W3C Trace Context 统一了追踪 ID 和父 Span 在服务之间的传递方式，却不定义智能体语义，也不能保证所有重要事件都已采样并保留 (World Wide Web Consortium 2021)。默认不得把令牌、可重复使用的凭据和敏感内容写入日志。事件接收端应位于沙箱之外，执行保留与访问策略，并通过测试确认崩溃和被拒绝的操作仍会留下完整记录。

授权前先验证失败行为

评估需要覆盖最终答案、外部终态、策略合规性、行动轨迹、延迟、成本和多次运行的可靠性。第 87 章 提供统计测试框架。智能体特有的验收测试还必须覆盖控制平面：

场景	必须获得的证据
间接提示注入或恶意工具输出	权限没有扩大，策略没有被重写，污染标记和来源信息仍然保留
工具 Schema 格式错误或发生漂移	调用在暴露给模型前被拒绝，或工具清单进入隔离区
错误租户、过期令牌、错误受众或令牌透传	工具代理和资源端分别拒绝请求，下游没有产生外部操作
陈旧审批或参数已经变化	原审批失效，必须重新做出针对具体操作的决定
重复交付，或结果不明确的写入后发生重试	只产生一项逻辑操作，或明确完成对账和升级处理
外部操作前后工作进程崩溃	根据事件日志恢复，不悄悄丢失或重复操作
工具执行期间超时或取消	派生进程停止，迟到结果进入隔离区，终止原因得到记录
进程炸弹、内存压力、磁盘写满或输出洪泛	CPU、内存、进程、磁盘和输出限制能够约束运行
文件系统逃逸或读取其他运行的金丝雀数据	访问被拒绝，主机与跨租户金丝雀数据保持不可读
通过原始 IP、重定向、IPv6 或获准主机上传进行出站访问	工作负载之外的默认拒绝策略阻止未声明的操作
浏览器导航到本地服务，或执行破坏性的登录态操作	来源与操作策略阻止执行，或要求重新审批
清理控制器故障	租约对账能够清除进程、存储、凭据和仍在计费的资源

这些测试必须经过实际部署的模型网关、工具服务器、策略引擎、沙箱镜像和控制器，不能用模拟对象绕开正在验证的边界。对于高影响写入，应先做影子执行或使用模拟器，再在失败预算很窄的金丝雀租户中试运行。在任务与隔离两道门都通过前，始终保留上一已知正常路由。

运营智能体生命周期

一套可执行流程如下：

1. 固定契约。 定义任务边界、成功证据、允许的外部操作、权限、数据、预算、终止原因、恢复和回滚。
2. 构建最小的显式循环。 确定性工作留在代码中，只有契约确实需要不确定解释或选择时才调用模型。
3. 定义每个工具。 固定 Schema 和实现摘要，并补齐策略、幂等性、错误、数据、凭据和后置条件。
4. 选择控制语义。 根据任务所需的状态转移，在线性循环、状态图、持久化工作流、文件系统运行框架或监督者与工作进程之间选择。
5. 选择并测试隔离机制。 从威胁模型出发，定义完整沙箱边界，并运行逃逸、外泄、资源、残留和清理测试。
6. 演练恢复。 通过故障注入模拟工作进程崩溃、重复回调、超时、取消、陈旧审批和结果不明确的外部操作。
7. 封存发布。 把模型、提示词、控制器、工具清单、策略、沙箱镜像、状态 Schema 和评估计划绑定到摘要。
8. 评估并进行影子运行。 测量成功率、外部状态、策略合规性、多次运行可靠性、成本、延迟和故障隔离能力。
9. 以最小权限进行金丝雀发布。 限制租户、工具、凭据、出站访问、并发和支出，同时保持上一已知正常路由在线。
10. 监控并重新验证。 审查失败，对账租约与不明确操作，轮换凭据，修补边界，并重新运行受影响的测试门。

重新验证触发条件包括模型修订版本变化、提示词或上下文变化、控制器或状态迁移、工具 Schema 或实现变化、策略变化、授权流程变化、沙箱镜像或运行时变化、新宿主或设备、浏览器修订版本、网络策略、制品流水线、租户边界，或流量结构出现显著变化。每项触发条件都会创建新的发布身份，并重新运行与受影响约束边界相关的测试。

最终产物是一份智能体发布记录，把智能体执行契约、控制器与状态 Schema、模型修订版本、工具与策略摘要、沙箱边界、审批和外部操作证据、评估报告、金丝雀结果和回滚结果连接起来。让智能体成为基础设施中可运营的一部分，靠的是这份记录，而不是框架名称。

下层约束

控制器无法恢复外部 API 无法识别的操作，无法隔离超出宿主约束边界的代码，也无法重建网关和事件存储从未记录的证据。模型服务限制决定延迟与成本，工具和身份系统决定权限，存储决定恢复能力，计算与网络策略决定隔离能力。智能体契约必须适配这些下层保证。

反过来，微虚拟机或持久化工作流也无法补救过宽的业务权限。隔离限制代码在哪里运行，授权限制经过验证的主体可以做什么。二者都必须在 第 56 章 所述的执行边界成立。

延伸阅读

一手论文界定了行动模式和已经观察到的攻击面；标准与系统资料则定义工具、授权、追踪、持久化执行和隔离边界。