企业级 Agent 平台参考架构 ​

本文的任务不是罗列平台组件，而是给出企业级 Agent 的架构升级路径。 本文综合第一性原理、可验证的生产故障模式与主流 Agent Platform（智能体平台）的公开实现进行推导，不把任何一家云厂商的能力清单直接当作参考架构。

本篇讨论的不是“应该选哪个 Agent 框架”，而是：当企业已经出现多个 Agent（智能体）产品以后，哪些能力值得沉淀成共享平台，哪些能力必须留在业务域，以及平台应该怎样逐步演进、怎样避免过度建设、怎样证明自己真的创造了价值。

全文沿着两次跨越展开：第一次从单点实验跨到生产可用，解决身份、权限、状态、执行、验证和可观测等基本保证；第二次从“能够上线”跨到优秀的企业级架构，让多个业务在稳定契约上复用能力，同时保持领域自治、故障隔离、成本可控和可替换性。第二次跨越不是再加一层“大平台”，而是把本系列前置专题分析过的 Agent Loop、Context、Knowledge、Memory / Skill、Runtime、Execution、Multi-Agent 与 Integration，通过清晰的 Owner（责任主体）、契约和故障语义组合起来。

两次跨越的能力要求不同，不能用“组件是否齐全”验收：

这里的“最低保证”是进入下一状态前不可缺少的条件；“条件能力”不是更高成熟度，而是特定压力出现后的响应。

事实边界：文中的产品能力以 2026-09-13 可核验的公开材料为准；跨产品抽象和建设建议属于工程判断，二者不等同。

本篇默认读者已经知道 Agent（智能体）会通过模型、工具和外部系统完成任务，但不要求读者提前掌握 Harness、Runtime、Sandbox、Memory 等平台术语。核心概念在第一次出现时解释它是什么、为什么存在、负责什么，以及与相邻概念有什么区别。

一、为什么企业最终会需要智能体平台 ​

1.1 平台解决的不是“更多智能体”，而是重复问题 ​

企业最开始做 Agent，通常不会先建设平台。

更常见的路径是：

团队 A
→ 做一个 Data Agent

团队 B
→ 做一个 Coding Agent

团队 C
→ 做一个 Ops Agent

早期这样做是合理的，因为：

• 每个团队都在验证业务价值；
• Agent 的产品形态还没有稳定；
• 很多所谓“通用能力”其实还没有经过真实生产验证。

真正的问题通常出现在第二阶段。

不同团队开始重复建设：

Run ID（运行实例标识）
Trace（执行追踪）
Tool Contract（工具契约）
Permission（权限检查）
Approval（审批）
Retry（重试）
Recovery（状态恢复）
Sandbox（沙箱）
Browser（浏览器执行）
Cost Accounting（成本统计）
Evaluation（评测）

此时企业面对的已经不是“怎么做一个 Agent”，而是：

怎样避免十个 Agent 团队重复建设十套基础设施，同时又不把所有业务强行塞进一个超级框架。

这才是 Agent Platform（智能体平台）真正出现的原因。

1.2 平台应该从问题里长出来 ​

企业平台比较健康的演进路线是：

1～2 个高价值 Agent
→ 先证明业务价值

真实事故和重复建设出现
→ 找出稳定共性

稳定共性形成 Contract（契约）
→ 多团队共同复用

复用规模继续扩大
→ 形成 Shared Capability（共享能力）

共享能力需要统一版本、治理和运维
→ Platform（平台）

所以平台建设应该遵循：

Problem（真实问题）
→ Repeated Pattern（重复模式）
→ Stable Contract（稳定契约）
→ Shared Capability（共享能力）
→ Platform（平台化）

而不是：

先看行业架构图
→ 把所有 Feature（功能）一次性建出来

这里的 Stable Contract（稳定契约） 指的是跨业务长期不容易变化的系统接口和语义，例如：

• Run 如何被唯一标识；
• Tool 怎样声明输入、输出和副作用；
• 高风险动作怎样经过权限和审批；
• Trace 怎样串起一次完整执行；
• Verification 怎样判断一次任务是否真的完成。

这些东西一旦跨多个业务重复，就适合平台化。

1.3 什么情况下反而不应该建“大平台” ​

如果企业当前仍然满足：

• Agent 数量很少；
• 业务还在找真正有价值的场景；
• 不同 Agent 差异非常大；
• 还没有明显重复建设；
• 风险和治理要求不高；
• Cloud / Open Source Software（云服务 / OSS，开源软件）已经可以满足需求；

那么更合理的方案通常是：

Thin Shared Software Development Kit（轻量共享 SDK，软件开发工具包）
+
Existing Cloud / OSS（现有云服务 / 开源能力）
+
Strong Domain Ownership（强业务域自治）

而不是中央大平台。

例如，只有两个简单 Agent 时，没有必要提前建设：

• Organization-wide Memory（全组织统一记忆）；
• Agent Marketplace（智能体市场）；
• Protocol Federation（协议联邦）；
• Global Dynamic Router（全局动态路由器）；
• 自研 Workflow Engine（工作流引擎）；
• 自研 Browser Cloud（浏览器云）。

判断标准不是“以后会不会用到”，而是：

现在是否已经出现真实 Failure（失败）、Scale（规模）、Risk（风险）、Reuse（复用）或 Governance（治理）问题。

1.4 平台不会消灭复杂度，只会重新分配复杂度 ​

平台化的本质不是让复杂度消失，而是把原本散落在各业务团队里的复杂度，集中到更适合统一治理的位置。

所以 CTO（首席技术官）或 Principal Architect（首席架构师）不能只问：

“平台以后可以少写多少代码？”

还必须问：

“复杂度集中到平台以后，平台团队真的有能力长期治理这些复杂度吗？”

二、企业智能体平台到底是什么 ​

本章只给 Architecture Map（架构地图）和行业证据。 先回答平台负责什么、业务域负责什么，以及主流平台为什么支持这些边界；具体机制为什么这样协作统一放到第三章。

2.1 平台的责任边界和运行主线是什么 ​

一个完整平台包含三条主路径和一条横切保障路径 ​

企业 Agent Platform 最容易被误解成“一套 Agent Framework（智能体开发框架）”。

平台不是按产品菜单分层，而是按变更速度、在线依赖和故障语义划分责任：

Control Plane（控制面）
→ 发布规则、策略和版本，决定系统应该怎样运行

Data Plane（数据面）
→ 承载 Run 的在线决策、上下文与观察结果流转

Execution Plane（执行面）
→ 持久化运行状态，并把动作安全作用到真实环境

Assurance Plane（生产保障面）
→ 横切前三者，证明系统是否安全、稳定、可观测、可评测

这些 Plane（责任面）是逻辑分工，不意味着一定部署成四个服务。拆分的价值在于明确谁拥有规则、谁承载在线流量、谁对副作用负责，以及依赖失效时应该阻断还是降级。

Control Plane（控制面） ​

负责管理：

• Agent Definition（智能体定义）：一个 Agent 有哪些能力、配置和依赖；
• Agent Version（智能体版本）：每次发布到底改变了什么；
• Capability Registry（能力注册表）：有哪些 Tool、Skill、Remote Agent 可以被发现；
• Knowledge Registry（知识注册表）：有哪些 Knowledge Source、谁负责，以及权威性、新鲜度、Access Control List（ACL，访问控制列表）和 Region 怎样治理；
• Policy（策略）：哪些动作在什么条件下允许；
• Routing（路由）：选择哪个模型、Tool 或执行环境；
• Quota（配额）：每个团队、租户、模型或执行资源能用多少；
• Rollout（灰度发布）：新版本如何逐步放量。

控制面回答的是：

“系统应该按照什么规则运行？”

Data Plane（数据面） ​

负责真正处理：

• Model Call（模型调用）；
• Context Assembly（上下文组装）；
• Knowledge Retrieval（知识检索）：从 Indexed / Remote / Structured / Live Source 获取证据；
• Tool Call（工具调用）；
• Remote Agent（远程智能体）。

它回答的是：

“这一轮真实发生了什么？”

Execution Plane（执行面） ​

执行面内部包含两个不能混为同一 Owner 的子责任域。

Runtime 子责任域负责 Run 的 Checkpoint、调度、等待、唤醒和恢复，并在 Run State 中保存 Operation ID 引用。它不拥有外部动作的最终结果，也不能自行把一次超时改写成失败。

Execution / Operation Service 子责任域负责校验授权票据、调用真实环境，并维护权威 Operation Ledger（操作账本）。账本记录动作参数摘要、幂等键、执行身份、授权票据、外部业务键和最终结果，是判断副作用是否发生的唯一依据。

因此执行面共同提供：

• Run State（运行状态）与 Checkpoint（检查点）；
• Operation Ledger（操作账本）引用与未知结果对账；
• Workspace（工作空间）、Sandbox（沙箱）和 Browser（浏览器执行）；
• 短期执行凭证与网络边界；
• Raw Result（原始结果）和 Artifact（产物）的持久化。

它回答的是：

“动作是否真的发生、发生到哪一步，故障后如何安全继续？”

Assurance Plane（生产保障面） ​

负责：

• Security（安全）；
• Reliability（可靠性）；
• Observability（可观测性）；
• Evaluation（评测）；
• Cost（成本）；
• Governance（治理）。

它回答的是：

“系统运行得是否可信、稳定、可证明？”

这一区分非常重要，因为不同责任面的失败语义不同。

例如：

Trace Export 暂时失败
→ 通常允许降级，不应该直接阻塞业务

Authorization 无法判断
→ 高风险场景通常应该 Fail-closed（失败即拒绝）

Durable State Store 不可用
→ 不能继续声称长任务仍然可以安全恢复

平台与业务域如何分工 ​

企业 Agent Platform 最重要的组织边界，可以压缩成一句话：

Platform owns Guarantees；Domain owns Meaning。
平台负责系统保证，业务域负责业务含义。

这里的 Guarantee（系统保证）包括：

• 状态不会无故丢失；
• 高风险动作一定经过权限；
• Trace 可以关联完整链路；
• 版本可以回滚；
• Sandbox 有隔离；
• 失败可以恢复；
• Artifact 有来源；
• Knowledge Evidence 可以追到 Source、版本、权限和有效时间。

Meaning（业务含义）包括：

• 什么叫 GMV；
• 哪个指标属于销售域；
• 哪个代码修改算正确；
• 某个运维动作在业务上是否允许；
• 什么结果才算真正完成。

为什么要这样分？

如果平台团队开始负责：

所有业务 Prompt（提示词）
所有指标定义
所有业务 Workflow（工作流）
所有 Domain Skill（领域技能）

它会变成业务瓶颈。

反过来，如果每个 Domain Team（业务域团队）都自己建设：

Runtime（运行时）
Identity（身份体系）
Trace（执行追踪）
Sandbox（沙箱）
Policy Engine（策略引擎）

企业又会重新回到重复建设。

所以真正稳定的边界是：

跨业务稳定的不变量
→ Platform

高变化业务语义
→ Domain

共享 Harness 应该统一什么 ​

Harness（执行外壳）可以理解为：

把模型的不确定决策放进可控制、可验证的工程边界。

Shared Harness Core（共享执行外壳核心）适合统一：

• Run / Turn 语义；
• Tool / Capability Contract；
• Context Interface；
• Policy Hook（策略钩子）；
• Verification Hook（验证钩子）；
• Trace Event；
• Budget / Cancellation（预算 / 取消）。

但不应该把所有东西都塞进 Core。

例如：

• Planning（规划）；
• Subagent（子智能体）；
• Compaction（上下文压缩）；
• Knowledge Retrieval / Rerank（知识检索 / 重排）；
• Skill（技能）；
• Approval（审批）；

更适合做成 Replaceable Standard Capability（可替换标准能力）。

而：

• Data Semantic Layer（数据语义层）；
• Repo Intelligence（代码仓库理解）；
• Research Citation（研究引用）；
• Ops Runbook（运维手册）；

应该继续属于 Domain Layer（业务域层）。

前置专题的关键能力如何协作 ​

可以把《Agent Loop 与 Harness 架构》《Agent 上下文工程》《Agent 知识检索与治理架构》《Agent 记忆、技能与持续学习》《Agent Runtime 与持久执行》《Agent 安全执行与结果验证》《Multi-Agent 与工作流编排》《Agent 跨系统交互与集成治理》讨论的能力理解成下面的协作关系：

Harness（执行外壳）
→ 控制 Agent 怎样工作

Context（上下文）
→ 决定模型这一轮看什么

Knowledge（知识）
→ 提供有来源、权限、版本和时效的候选证据

Runtime（运行时）
→ 保证 Run 跨时间和故障继续活着

Execution（执行层）
→ 把 Action 真正作用到现实世界

Memory / Skill（记忆 / 技能）
→ 把高价值经验带到未来 Run

Multi-Agent / Workflow（多智能体 / 工作流）
→ 处理多个决策主体和显式流程

Protocol / Integration（协议 / 集成）
→ 让独立系统稳定互操作

它们不是互相孤立的产品模块。

把这些能力组合起来时，不应让模块彼此读取内部表，而应通过少量稳定对象协作：

平台共享的是这些契约及其保证；业务域仍然拥有指标口径、成功条件、领域工具和具体工作流。这样底层 Provider 或 Framework 可以替换，而业务含义不会随之迁移。

例如一次 Coding Agent：

用户任务
→ Harness 创建 Run
→ Context 选择相关代码
→ 模型提出修改 Action
→ Execution 在 Sandbox 修改文件
→ Runtime 保存 Checkpoint
→ 测试失败后继续
→ Verification 检查测试
→ Trace 记录全过程
→ 成功经验可能进入 Skill Candidate

只有把这些责任拼起来，才是真正的平台。

一次 Run 怎样穿过整个平台 ​

前面讲了平台有哪些层，但真正理解平台，还要看一次 Run（运行实例）怎样从用户请求一路走到最终验证。

以一个 Data Agent（数据智能体）为例，用户问：

“帮我分析华东区上个月 GMV 为什么下降。”

完整链路可以拆成：

1. User Request（用户请求）
→ 明确用户目标、身份和租户

2. Create Run（创建运行实例）
→ 生成唯一 Run ID，绑定 Agent Version

3. Identity / Policy（身份 / 策略）
→ 确定这个用户和 Agent 能访问哪些数据与能力

4. Context Assembly（上下文组装）
→ 读取指标定义、Schema、历史澄清和当前状态

5. Model Routing（模型路由）
→ 根据任务复杂度、成本和数据约束选择模型

6. Model Decision（模型决策）
→ 生成下一步 Action Proposal（动作提议）

7. Capability Check（能力检查）
→ 判断 SQL、Python、Browser 等能力是否当前可用

8. Operation Ledger Entry（操作账本条目）
→ Runtime 请求 Operation Service 预留 Operation ID，并在 Run State 中保存引用

9. Authorization（授权）
→ 对真实动作重新检查权限和风险，签发绑定 Operation ID 的授权票据

10. Execution（执行）
→ 在数据库、Sandbox、Browser 或 API 中真正执行

11. Raw Result / Artifact（原始结果 / 产物）
→ 保存完整结果和可追踪产物

12. Observation（观察）
→ 把原始结果转换成模型可以消费的结构化反馈

13. State Update（状态更新）
→ 更新当前 Run 做到哪一步

14. Next Turn（下一轮）
→ 新 Observation 重新进入 Context

15. Verification（验证）
→ 判断业务目标是否真的完成

16. Verified Result（已验证结果）
→ 返回最终结果

17. Trace / Eval / Cost（追踪 / 评测 / 成本）
→ 记录行为链路、质量和资源消耗

18. Memory / Skill Candidate（记忆 / 技能候选）
→ 只有高价值、可复用经验才进入学习候选

这里最重要的不是记住 18 个步骤，而是理解：

每一层都在解决一种不同的不确定性。

例如：

• Context 解决“模型到底看到了什么”；
• Policy 解决“这个动作能不能做”；
• Runtime 解决“任务失败后还能不能继续”；
• Execution 解决“动作在哪里真实发生”；
• Verification 解决“结果到底是不是真的完成”。

因此，成熟平台不是把这些能力堆在一起，而是让它们沿着同一条 Run 主线协作。

哪些步骤可以降级，哪些必须阻断 ​

并不是所有平台组件故障都应该让 Run 失败。

例如：

Trace Export 失败
→ 可以先缓存，业务继续

Cost Aggregation 延迟
→ 可以异步补算

High-risk Authorization 无法判断
→ 必须阻断

Durable State 写入失败
→ 长任务不能继续声称可恢复

Artifact Persistence 失败
→ 如果 Artifact 是最终证据，不能直接返回成功

这就是 Failure Semantics（故障语义）：

平台不仅要知道“哪个服务挂了”，还要知道“这个故障是否允许业务继续”。

2.2 行业实现怎样验证并修正这套参考架构 ​

这一节固定按四步阅读：

① 先看 AWS / Microsoft / Google / OpenAI 的真实实现
② 再抽取四家共同收敛的系统责任
③ 再保留它们真正没有统一答案的架构分歧
④ 最后回到企业参考架构，说明哪些判断被验证、修正或否定

这样竞品研究不是产品功能罗列，而是架构证据链。

主流平台怎样验证这套参考架构 ​

如果一套 Reference Architecture（参考架构）只来自内部推理，很容易把团队自己的经验误当成行业规律。

所以企业参考架构还需要第二条证据链：

第一性原理
+
真实生产 Failure（失败）
+
主流平台实现

本篇重点选择四条当前最有代表性的企业平台路线：

AWS Bedrock AgentCore
Microsoft Foundry Agent Service
Google Vertex AI Agent Engine / Agent Platform
OpenAI Agents API / Agents SDK

选择它们不是因为“品牌最大”，而是因为四者恰好代表了四种不同的平台化方式：

AWS
→ Composable Infrastructure（可组合基础设施）

Microsoft
→ Managed Agent Platform（托管智能体平台）

Google
→ Managed Runtime + Context / Memory / Eval

OpenAI
→ Managed Harness + Agent Environment

真正要研究的不是谁 Feature（功能）最多，而是：

每个平台把复杂度放在哪里，哪些能力被平台统一，哪些能力仍然留给业务和 Framework。

AWS：把智能体基础设施拆成可组合资源 ​

Amazon Bedrock AgentCore 当前把平台能力拆成多个可以独立使用、也可以组合使用的资源：

• Runtime（运行时）：托管 Agent / Tool 的安全、弹性运行环境；
• Memory（记忆）：管理短期和长期记忆；
• Gateway（网关）：把 API、Lambda、MCP Server 等统一暴露给 Agent；
• Identity（身份）：让 Agent 代表用户或自身访问 AWS 和第三方资源；
• Policy（策略）：控制 Agent 能执行哪些动作；
• Browser（浏览器）：提供隔离的浏览器运行环境；
• Code Interpreter（代码解释器）：提供安全代码执行环境；
• Observability（可观测性）：追踪 Agent 执行路径；
• Evaluations（评测）：做生产和离线质量评估；
• Registry（注册表）：统一发现 Agent、Tool、Skill 等资源。[^aws-agentcore]

它的设计哲学很清楚：

不要强制企业使用某一个 Agent Framework，而是把运行、身份、工具连接、执行、安全、观测等基础设施资源化。

AgentCore Runtime 官方明确支持不同 Framework、模型和协议，包括 MCP（模型上下文协议）与 A2A（智能体到智能体协议）；Gateway 则把 MCP / HTTP / Inference Target 统一到一个安全入口。[^aws-runtime][^aws-gateway]

这条路线验证了我们参考架构中的一个核心判断：

Framework（开发框架）
≠
Platform（生产平台）

Framework 主要帮助开发者组织 Agent 逻辑；Platform 则负责跨业务稳定、长期存在的系统保证。

企业真正值得平台化的通常包括：

• Runtime（运行时）：让 Run 跨等待、故障和重启仍能继续；
• Identity（身份）：明确用户、Agent、Workload 到底是谁；
• Policy（策略）：决定当前身份对当前资源能做什么；
• Execution（执行）：把模型提出的动作安全落到真实环境；
• Gateway（网关）：统一路由、凭证、限流、版本和调用治理；
• Observability（可观测性）：解释一次 Run 发生了什么、为什么失败；
• Evaluation（评测）：验证版本在任务分布上的整体质量。

这些能力之所以适合平台化，是因为它们跨 Domain 重复出现，而且一旦每个团队各自实现，就会产生安全、可靠性和治理不一致。

但它也把复杂度转移到了：

• IAM（身份与访问管理）；
• Resource Configuration（资源配置）；
• VPC / Network（网络）；
• 多个 AgentCore Resource 的生命周期和成本治理。

所以 AWS 路线的代价是：

模块化程度越高，企业越需要一个清晰的 Control Plane 把这些资源重新组织成自己的平台语义。

Microsoft：把框架与托管平台分离 ​

Microsoft Foundry Agent Service 当前把平台能力组织成：

• Agent Runtime（智能体运行时）；
• Toolboxes（工具箱）；
• Models（模型）；
• Observability（可观测性）；
• Optimization（优化）；
• Identity & Security（身份与安全）；
• Publishing（发布）。[^ms-foundry]

尤其值得研究的是 Hosted Agent（托管智能体）。

企业可以把不同 Framework（开发框架）或自有 Agent 代码部署到 Foundry，例如 Microsoft Agent Framework、LangGraph、OpenAI Agents SDK、Anthropic Agent SDK。

这说明 Hosted Agent 的核心不是“统一 Framework”，而是把不同实现放进统一托管边界。平台负责：

• Scaling（弹性伸缩）：流量变化时自动调整运行实例；
• Session State（会话状态）：让长交互不依赖某一台临时容器；
• Identity（身份）：给 Agent 一个可被企业 IAM 治理的身份；
• Managed Endpoint（托管端点）：把容器稳定暴露成可调用服务；
• Observability（可观测性）：统一 Trace、日志和运行指标。

因此“自带 Framework”并不意味着“自带全部生产基础设施”。[^ms-hosted]

它还把 Toolbox（工具箱）设计成独立、可版本化的 Server-side Tool Bundle（服务端工具集合），可以通过统一 MCP Endpoint 被不同 Agent / Framework 使用。[^ms-toolbox]

这条路线进一步验证：

平台应该统一 Tool / Identity / Runtime / Publishing 等稳定语义，但不必统一 Agent Framework。

Microsoft 甚至明确把“Hosting Model（托管方式）”与“Protocol（协议）”分开：同一个 Agent 可以选择 Foundry 托管或 Self-host，同时又可以通过 Responses、A2A、AG-UI（智能体与用户界面交互协议）、MCP 等不同协议暴露。[^ms-hosting]

这给企业一个很重要的启发：

Hosting
≠
Protocol
≠
Agent Logic

三者应该可以独立演进。

Google：托管运行、会话、记忆与评测 ​

Google Vertex AI Agent Engine / Agent Platform 的路线，更强调把几类生产责任拆成独立托管能力：

• Agent Runtime（智能体运行时）：承载 Agent 的持续运行和生命周期；
• Sessions（会话）：保存用户与 Agent 的交互连续性；
• Memory Bank（记忆库）：保存跨 Session 可复用的长期信息；
• Code Execution（代码执行）：提供受控的代码运行环境；
• Observability（可观测性）：追踪 Run、调用和错误；
• Evaluation（评测）：验证 Agent 版本在任务集上的整体质量。

这种拆分的设计意义是：会话、长期记忆、执行环境和评测拥有不同生命周期，因此不应该被一个笼统的“Agent State”全部吞掉。

Sessions（会话）和 Memory Bank（记忆库）已经被拆成独立托管资源；Memory Bank 可以独立于 Runtime 使用，也可以和 ADK / Agent Engine Runtime 结合。[^google-memory]

这说明 Google 在架构上明确区分：

Session
≠
Long-term Memory

这与《Agent 上下文工程》和《Agent 记忆、技能与持续学习》定义的数据边界一致。

Google 还提供独立 Code Execution（代码执行）Sandbox；在 ADK 场景中，一个 Sandbox 可以跨同一任务多次调用持续保留文件和变量状态。[^google-code]

在生产层，Agent Engine 还提供：

• Cloud Monitoring；
• Trace；
• Evaluation；
• User Simulator（用户模拟器）；
• Runtime / Session / Memory 等资源。[^google-monitor][^google-eval]

这条路线验证了：

Context / Session / Knowledge / Memory、Runtime、Execution 和 Eval 并不是一个对象，也不应该被一个“Agent State”全部吞掉。

Google 的复杂度主要被放进 Cloud-native Resource Model（云原生资源模型）：

• Google Cloud Project / IAM（项目 / 身份权限）：Tenant、身份和资源边界主要复用 Google Cloud；
• Managed Runtime（托管运行时）：Agent 生命周期和弹性运行由云平台承担；
• Agent Engine Resource（智能体资源）：Agent 本身成为可部署、可治理的云资源；
• Session / Memory Resource（会话 / 记忆资源）：不同生命周期的数据被拆成独立服务；
• Cloud-native Operations（云原生运维）：Monitoring、Trace、Quota、区域和故障治理复用既有云基础设施。

因此它更适合已经在 Google Cloud 体系里的企业，但参考架构不应该把这种 Cloud Resource Model 当成唯一标准。

OpenAI：把 Harness（执行外壳）产品化 ​

OpenAI 的路线与前三家又不完全一样。

Agents SDK 本身强调少量稳定 Primitive（原语），每个原语解决不同边界：

• Agent（智能体）：封装指令、模型和可用能力；
• Tool（工具）：让模型把决策作用到外部系统；
• Guardrail（护栏）：在输入、输出或工具调用阶段增加确定性约束；
• Handoff（移交）：把任务交给另一个 Agent，而不是把所有能力塞进一个主体；
• Session（会话）：保存多轮交互连续性；
• Tracing（追踪）：记录模型、工具、移交等执行事件；
• Human-in-the-loop（人在回路）：高风险或需要业务判断的步骤由人确认。[^openai-sdk]

而 2026 年 9 月发布的 Agents API，则进一步把 Codex 使用的 Harness（执行外壳）作为托管基础设施提供：

• 长 Session；
• Context Compaction（上下文压缩）；
• Tool 使用；
• Subagent（子智能体）；
• OpenAI Sandbox；
• 自有或合作方 Sandbox。[^openai-api]

OpenAI 官方明确表达：

Harness 会随着模型一起持续优化，并提供版本化访问。

这意味着 OpenAI 走的是一条很有代表性的路线：

Model
+
Managed Harness
+
Optional Managed Environment

它验证了《Agent Loop 与 Harness 架构》的一个重要判断：

Harness 不是几段 Glue Code（胶水代码），而可以成为独立、可版本化、可持续演进的平台能力。

同时 Agents SDK 的 RunState（运行状态快照）支持序列化和恢复中断 Run；Tracing 默认记录 Model、Tool、Handoff、Guardrail 等 Agent-native Event（智能体原生事件）。[^openai-runstate][^openai-tracing]

但它和完整 Enterprise Platform 仍然不是同一个概念。

企业仍需要自己掌握一组厂商无法替代的业务治理语义：

• Domain Identity（领域身份）：企业内部用户、组织、业务主体到底是谁；
• Business Policy（业务策略）：哪些动作在什么业务条件下允许；
• Data Residency（数据驻留）：哪些数据必须在哪个区域处理和存储；
• Business Verification（业务验证）：什么才算真正完成，而不是模型自报完成；
• Cost Allocation（成本归属）：一次 Run 的模型、Tool、Sandbox 成本应该算给哪个团队 / 租户；
• Organization-level Governance（组织级治理）：版本、审批、审计、发布和责任归属。

所以：

Managed Harness 可以显著降低 Agent 工程复杂度，但不能替代企业自己的业务治理层。

四条路线放在一起看什么 ​

如果把四家放在同一个机制坐标系里：

这张表最重要的不是“谁更完整”，而是能看出三类稳定规律。

四家共同收敛出了什么 ​

虽然产品形态完全不同，但四家已经明显共同收敛到一些能力。

第一，共同把 Runtime（运行时）从业务代码中抽出来。

AWS、Microsoft、Google 都明确提供 Managed Runtime；OpenAI 则通过 Agents API / SDK 把 Agent Run 和 Harness Runtime 上移。

这验证：

长任务、Session、Tool、恢复和生命周期不应该永远留在业务 while loop 里。

第二，共同把真实执行环境独立出来。

AWS 有 Browser / Code Interpreter；Google 有 Code Execution；Microsoft Hosted Agent 使用 Managed Container 和 Hosted Tool；OpenAI 支持 Hosted / External Sandbox。

这验证：

Agent Decision（智能体决策）和 Execution Environment（执行环境）应该分层。

第三，共同强化 Tool / Capability（工具 / 能力）的平台治理。

AWS 用 Gateway，Microsoft 用 Toolbox，Google 有 Tool / API Registry 路线，OpenAI 有 Hosted Tool / MCP / Tool Search。

这验证：

Tool 不再只是一个 Python Function，而是需要 Discovery（发现）、Identity（身份）、Version（版本）、Policy（策略）和 Observability（观测）的企业资源。

第四，共同把 Observability / Evaluation（可观测性 / 评测）上升为平台能力。

四家都不再把 Log（日志）当成足够的生产治理能力。

平台开始直接理解 Agent-native（智能体原生）的运行对象：

• Session（会话）：一次持续交互的上下文边界；
• Trace（追踪）：一次 Run 内部的完整执行链；
• Tool（工具）：外部能力调用；
• Agent（智能体）：谁在做决策；
• Evaluation（评测）：版本在任务集上的质量结果；
• Usage（用量）：Token、Tool、Sandbox 等资源消耗；
• Latency（时延）：模型、工具和端到端耗时。

这验证：

Assurance Plane（生产保障面）应该与 Agent Runtime 一起设计，而不是上线后再补日志。

行业实现已经进一步说明：Observability（可观测性）和 Evaluation（评测）不是两套互不相关的系统，而应该共享同一套 Agent-native Telemetry（智能体原生遥测）。

OpenAI Agents SDK

OpenAI 当前默认 Trace 层级已经覆盖：

Trace
└─ Task / Agent / Turn Span
   ├─ Generation Span
   ├─ Function Tool Span
   ├─ Guardrail Span
   └─ Handoff Span

这类 Span 不只是记录“耗时多少”，而是在保存 Agent 的决策结构：哪一轮模型生成、调用了哪个 Tool、发生了哪个 Handoff、哪个 Guardrail 触发。[^openai-platform-tracing]

AWS AgentCore

AgentCore Observability 输出 OpenTelemetry（开放遥测）兼容的 Trace / Span / Metric / Log，并把这些 Trace 直接交给 Evaluation 系统。AgentCore Evaluations 可以基于完整 Session / Trace / Span 做 Online、On-demand、Batch 评测，也可以单独评估 Tool Selection / Tool Use。[^aws-platform-observability][^aws-platform-evaluation]

这带来一个重要平台原则：

Production Trace
→ Failure Mining
→ Eval Dataset
→ Regression Evaluation
→ Release Gate
→ New Production Trace

最有价值的 Eval 数据集不是凭空编出来的 Benchmark，而应该不断吸收真实生产 Trace 中的失败、长尾和高风险样本。

因此平台应该把 Trace ID、Session ID、Agent / Model / Prompt / Tool / Skill / Context / Runtime / Environment Version 和 Eval Result 连起来，而不是把“监控”和“评测”建成两个数据孤岛。

第五，共同避免把 Framework（框架）直接等同于 Platform（平台）。

尤其 AWS、Microsoft 和 Google，都明确允许不同 Framework 或自定义 Agent。

这验证：

企业最应该平台化的是 Stable Contract（稳定契约）和 Guarantee（系统保证），而不是某个快速变化的 Framework。

四家真正的分歧在哪里 ​

行业没有收敛成唯一架构。

真正分歧主要在：

分歧一：Harness 由谁拥有

OpenAI
→ 平台强拥有 Harness

AWS
→ Harness 更多留给 Framework

Microsoft
→ Prompt Agent 平台拥有；Hosted Agent 可由开发者拥有

Google
→ ADK 与 Managed Runtime 配合，但 Runtime / Session / Memory 可拆

这说明：

企业是否自建 Harness，不应该有一个固定答案。

如果企业业务高度依赖某个模型厂商的 Agent 能力，Managed Harness 可能更划算。

如果企业需要：

• 多模型；
• 多 Framework；
• 强 Domain Control；

则 Harness Contract 自己掌握更重要。

分歧二：Memory 放在哪里

AWS / Google 都把 Memory 做成明显独立平台资源。

OpenAI 更强调 Session / Harness 侧的 Context 和 Memory 能力。

这说明：

Memory 不应该和 Runtime State 混合，但是否一定需要中央 Memory Platform，取决于业务复用价值。

分歧三：工具治理应该做到多重

大型企业最终不会只有几十个 Tool，而会出现多个 Team、MCP Server、API、Remote Agent 和 Skill 共同进入能力目录。

因此平台 Tool Governance（工具治理）至少要拆成六层：

Registry
→ Search / Discovery
→ Visibility Filter
→ Identity / Policy
→ Approval / Guardrail
→ Invocation Trace / Eval

当前行业已经出现明确证据：

• OpenAI Agents SDK 支持 Deferred Tool + Tool Search 和 MCP Tool Filter；
• AWS AgentCore Gateway 支持 Tool Semantic Search，并把 Tool Call Policy 放到 Gateway Policy Engine；
• Microsoft Agent Framework 把 Tool Approval 做成 Middleware / Approval Flow，而不是写进 Prompt。[^openai-platform-tool-search][^aws-platform-tool-search][^aws-platform-policy][^ms-platform-tool-approval]

这对大型企业特别重要，因为：

Capability Registry 是“企业拥有的能力集合”，Model-visible Tools 只是“当前 Run 被允许看到的小投影”。

平台如果不把两者拆开，Tool 数量增长最终会同时击穿 Context、Permission 和 Debuggability。

回到企业架构：为什么不能照抄任何一家

企业 Reference Architecture 最容易犯的错误是：

AWS 有什么
→ 我们照着建

或者

Microsoft 有什么
→ 我们照着建

但四家产品的边界都受到自己的：

• Cloud Platform；
• Model Strategy；
• 商业模式；
• Existing IAM；
• Existing Observability；
• Customer Base；

影响。

所以我们真正应该吸收的是它们背后的 Architecture Invariant（架构不变量）。

例如：

AWS Identity
Microsoft Entra Identity
Google IAM
OpenAI + Enterprise IAM Integration

实现不同，但共同问题都是：

Agent 以谁的身份访问真实世界。

又例如：

AgentCore Gateway
Foundry Toolbox
Google Tool Registry
OpenAI Tool / MCP

产品不同，但共同问题是：

如何把大量能力安全、可发现、可治理地暴露给 Agent。

因此本篇参考架构采用的是：

产品 Feature
↓
还原它解决的 Failure / Scale / Governance Problem
↓
抽象稳定系统责任
↓
跨产品验证
↓
形成企业 Reference Architecture

而不是：

四家 Feature 求并集

补充证据：为什么还要看专项系统

四大平台适合验证“企业平台怎么组织能力”，但它们不能单独回答所有机制问题。

所以本系列还用第二圈专项系统做机制验证：

这样可以避免一个偏差：

只研究云厂商，就容易把 Cloud Product Boundary（云产品边界）误认为 Architecture Boundary（架构边界）。

四大平台负责验证“平台级共性”；专项系统负责验证“机制级边界”。

证据收束：竞品研究修正了哪些架构判断

这一轮竞品对照没有替代内部架构推导，而是为几条判断补充了外部实现证据。

结论一：Platform 不应该等于 Framework。

AWS、Microsoft、Google 的开放 Framework 路线都支持这一点。[^aws-agentcore][^ms-foundry][^google-platform]

结论二：Runtime、Execution、Identity、Tool Governance 应该是一等平台问题。

AWS 的资源化拆分最直接，Microsoft / Google 也给出相似的生产边界。[^aws-agentcore][^ms-foundry][^google-platform]

结论三：Harness 本身也可以被平台化。

OpenAI Agents API 说明 Harness 不是只能留在业务代码里的 Glue Code。[^openai-api]

结论四：Session / State / Memory 必须分生命周期。

Google Sessions / Memory Bank、OpenAI Session / RunState、AWS Memory 的产品拆分都提供了现实证据。[^google-memory][^openai-runstate][^aws-agentcore]

结论五：Observability / Evaluation 不应该被视为辅助功能。

AWS、Microsoft、Google、OpenAI 都已经把 Agent-native Trace / Eval 提升到核心产品能力。[^aws-eval][^ms-foundry][^google-eval][^openai-tracing]

因此，本文的参考架构证据链是：

第一性原理
+
生产 Failure / Scale / Risk
+
主流 Agent Platform 实现
↓
Architecture Invariant
↓
Enterprise Reference Architecture

三、平台内部到底怎样工作 ​

第二章回答“平台有什么”，本章只回答“为什么这些层必须这样协作”。 因此 Run、Gateway、State / Context / Memory、Runtime、Execution、Tenant、Verification 都按机制因果展开，而不再重复平台能力清单。

3.1 Run 为什么应该成为中心对象 ​

Run（运行实例）指：

一次具体 Agent 任务的完整执行。

例如：

“修复支付服务里的一个 401 Bug。”

这一次从开始到结束，就是一个 Run。

企业应该让所有关键对象都能关联到 Run：

• 花了多少钱；
• 用了哪个 Agent Version；
• 看了什么 Context；
• 调用了哪些 Tool；
• 哪些动作产生了副作用；
• 谁批准；
• 生成了什么 Artifact；
• 为什么失败；
• 是否恢复过；
• 最终是否验证成功。

如果没有稳定 Run ID，后面很多能力都会碎掉：

成本
Trace
评测
恢复
审批
事故定位
版本归因

都难以串起来。

3.2 为什么需要模型网关 ​

Model Gateway（模型网关）不是简单把多个模型 API 包装成一个 HTTP 接口。

它真正解决的是：

不同任务应该使用哪个模型，以及模型不可用、太贵、太慢或不符合数据要求时怎么办。

企业通常同时面对：

• 多个 Model Provider（模型供应商）；
• 不同 Context Window（上下文窗口）；
• 不同成本；
• 不同延迟；
• 不同 Tool Calling 能力；
• 不同多模态能力；
• 不同数据驻留要求；
• Provider 故障和限流。

因此更合理的选择过程是：

Task Requirement（任务要求）
↓
Model Profile（模型配置）
↓
Capability Requirement（能力要求）
↓
Context Requirement（上下文要求）
↓
Data Residency（数据驻留）
↓
Latency / Cost Budget（时延 / 成本预算）
↓
Provider Health（供应商健康）
↓
Model Routing（模型路由）

Model Profile 是什么 ​

Model Profile（模型配置）描述一个模型对平台有意义的能力，而不是只记录模型名称。

例如一个 Model Profile 可以记录：

平台不应该让业务代码到处写：

if model == "xxx":

而应该让业务声明：

“这个任务需要长上下文、工具调用、低时延，而且数据必须留在指定区域。”

Model Gateway（模型网关）再根据能力和约束选择模型。

Fallback 为什么不能只是“换下一个模型” ​

Fallback（故障切换）也需要语义。

例如：

Model A（模型 A）
→ 高能力、高成本

Model B（模型 B）
→ 中等能力、低成本

如果 A 挂了，不能所有任务都直接切 B。

应该区分：

简单分类任务
→ 可以 Fallback

高风险代码修改
→ 如果模型能力不足，宁可等待 / Fail

受监管数据
→ 不能 Fallback 到不满足 Residency 的 Provider

所以 Model Gateway 是：

能力、成本、时延、合规和可靠性的统一决策层。

3.3 状态、上下文与长期信息如何分层 ​

这是企业 Agent 数据模型里最容易混淆的一组概念。

Run State（运行状态） ​

表示：

这次任务真实执行到了哪里。

例如：

• 当前 Step；
• 已完成 Tool；
• 当前预算；
• 审批状态；
• 最新失败；
• 已产生 Artifact。

Session（会话） ​

表示：

用户与 Agent 的持续交互历史。

一个 Session 可以包含多个 Run。

Context（模型上下文） ​

表示：

这一轮 Model Call 实际能看到什么。

Context 是从 State、Session、Knowledge、Memory、Tool 等来源中选择出来的一小部分。

Knowledge（企业知识） ​

表示：

来自企业权威系统、领域数据源或外部世界，可以通过 Source / Authority / Freshness / Permission / Evidence 证明其可信性的事实与语义。

例如：

• Metric Registry 中的正式指标定义；
• CMDB 中的服务依赖和 Owner；
• 合同系统中的正式条款；
• Search Index 中的制度文档；
• Remote Source 中的实时组织 / 业务事实。

Knowledge 和 Context 的关系是：

Knowledge
→ 提供候选事实和 Evidence

Context Engineering
→ 决定当前这一轮哪些 Evidence 进入模型

Knowledge 和 Memory 也不同：

Knowledge
→ 企业 / 外部权威事实

Memory
→ 历史交互和 Run 中值得跨任务保留的经验

平台层不应该强行统一所有 Knowledge Storage，而应该统一：

Knowledge Source Contract
Authority / Freshness / ACL
Retrieval / Rerank Interface
Evidence Contract
Trace / Eval
Version / Revoke

具体机制由《Agent 知识检索与治理架构》展开。

Memory（长期记忆） ​

表示：

哪些信息值得跨 Run 长期保留。

例如用户长期偏好、稳定环境事实、被验证过的经验。

Skill（技能） ​

表示：

可以被重复执行的方法或流程。

Skill 比 Memory 更接近“怎么做”。

所以不能设计一张：

agent_memory

把所有东西都塞进去。

它们的：

Lifecycle（生命周期）
Permission（权限）
Retention（保留期限）
Version（版本）
Injection Policy（注入策略）

都不同。

尤其 Knowledge 还多出一组平台级治理语义：

Authority
Freshness Service Level Agreement（新鲜度 SLA，服务等级协议）
Source Status / Revoke
Data Residency
Citation / Evidence
Index / Retrieval Version

因此平台不能把 Knowledge 简化成“另一张 Memory 表”或“一个共享 Vector DB”。

3.4 工具与能力契约要统一什么 ​

Tool（工具）不是只有一个函数名。

一个生产级 Tool Contract（工具契约）至少要表达：

例如：

create_ticket

真正需要回答：

• 输入字段是什么；
• 会不会产生外部副作用；
• 哪些用户可以调用；
• 是否支持 Idempotency Key（幂等键）；
• Timeout 后怎样确认是否已经创建；
• 谁维护这个 Tool；
• Tool Schema 升级是否兼容旧 Agent。

因此统一 Tool Contract 的价值不是“方便调用”，而是：

让权限、重试、审计、恢复和版本治理拥有共同语义。

Tool Contract 只说明“这种能力在一般情况下怎样使用”，不能替代对本次动作的授权。运行时需要把静态能力定义和动态授权分开：

Action Proposal（动作提议）
→ 根据当前用户、Agent、租户、资源和环境评估策略
→ 签发 Authorization Ticket（授权票据）
→ Execution 校验票据与 Operation ID、资源、参数摘要和有效期
→ 执行后把票据标识写入 Operation Ledger 与 Audit

授权票据应短期有效、限定范围并绑定单次操作。执行层不能只相信 Harness 传来的 allowed=true，也不能拿一个宽泛的服务账号替代用户委托；否则审批后的参数替换、跨租户重放或凭证泄漏都可能绕开策略。对于数据查询、代码执行和生产变更，平台还要区分 User Identity（用户身份）、Agent Identity（智能体身份）和 Execution Identity（执行身份），并记录三者之间的委托链。

规模继续上升后，这些信息应该进入独立的 Capability Control Plane（能力控制面）：

Capability Registry
Tool / Agent Search
Schema / Version Registry
Identity / Policy
Approval
Quality / Eval
Deprecation / Revoke
Usage / Cost

业务 Agent 不应该各自重新实现这些能力。

3.5 为什么要独立运行时 ​

Runtime（运行时）负责：

让一个 Run 在等待、故障、重启和版本变化后仍然可以正确继续。

它通常提供：

• Checkpoint（检查点）：保存可恢复状态；
• Wait / Signal（等待 / 信号）：支持审批或外部事件；
• Resume（恢复）：故障后继续；
• Operation Reference（操作引用）：关联由 Execution / Operation Service 维护的权威操作账本；
• Lease / Fencing（租约 / 栅栏）：避免两个 Worker 同时执行；
• Version（版本）：旧 Run 恢复时使用正确代码。

为什么不能每个 Agent 自己写：

while true + Redis + cron

因为一旦出现：

Tool 已成功
→ 进程崩溃
→ Result 还没写状态

恢复以后系统就不知道：

“刚才到底成功没？”

这不是 Prompt 能解决的问题，而是分布式系统问题。

3.6 动作如何安全落到真实环境 ​

Execution Fabric（执行基础设施）指：

统一管理 Agent 的真实执行环境和执行通道。

它不是单纯的 Sandbox。

它至少需要管理：

Workspace（工作空间） ​

保存：

• 文件；
• Diff；
• 中间结果；
• 测试报告；
• Artifact。

Workspace 解决的是：

Agent 的工作状态放在哪里。

Sandbox（沙箱） ​

提供隔离执行环境。

Sandbox 解决的是：

不可信代码在什么边界里运行。

Identity（身份） ​

回答：

Agent 到底以谁的身份访问真实资源。

企业通常至少区分：

• User Identity（用户身份）；
• Agent Identity（智能体身份）；
• Execution Identity（执行身份）。

例如：

用户有数据库权限，不代表 Agent 就可以自动把数据发到公开频道。

身份解决“谁在请求”，策略解决“当前条件下能否做”，授权票据则把一次策略决策安全交给执行层。三者缺一不可。票据只携带执行所需的最小声明，不把长期密钥暴露给模型；执行环境再按票据范围获取短期 Credential（凭证）。

Secret（密钥） ​

Secret 不应该直接进入 Prompt。

更合理是：

Agent 提出 Action
→ Policy 判断
→ 签发绑定 Operation ID 的授权票据
→ Execution Environment 校验票据并按 Scope 注入短期 Credential
→ 执行
→ Credential 过期 / 回收

Network（网络边界） ​

即使文件系统隔离，也要限制：

• 内网访问；
• Metadata Service；
• 外部数据外泄；
• 未授权 SaaS。

所以真正的平台执行链应该是：

Action Proposal
→ Policy / Identity
→ Authorization Ticket
→ Operation Ledger
→ Execution Environment
→ Raw Result
→ Evidence
→ Verification

而不是：

Model
→ Tool
→ success

执行请求超时尤其不能直接进入重试，因为外部系统可能已经完成动作，只是响应丢失。Runtime 应先把 Operation 标为 UNKNOWN（结果未知），再通过幂等查询、外部业务键、回调或人工复核完成 Reconciliation（对账）；只有确认“未执行”后才允许重试。无法对账的高风险写操作应暂停并升级处理，而不是猜测结果。

3.7 多租户和资源治理怎么做 ​

Multi-tenant（多租户）指：

同一套平台同时服务多个团队、业务线、客户或组织空间，但它们之间的数据、权限和资源不能互相污染。

企业平台真正 Scale（规模化）以后，常见层级是：

Organization（组织）
↓
Tenant（租户）
↓
Project / Team（项目 / 团队）
↓
Agent（智能体）
↓
Run（运行实例）

每一层都可能拥有独立：

• Budget（预算）；
• Quota（配额）；
• Policy（策略）；
• Data Scope（数据范围）；
• Cost Center（成本中心）。

Tenant ID 不能只是 API 参数。平台要把租户范围写入身份声明、授权票据、状态主键、队列分区、缓存键、向量检索过滤、Artifact 路径、加密密钥和审计事件，并在服务端从可信身份推导，不能接受模型或客户端任意覆盖。对于高敏租户，还需要独立密钥、计算池或网络边界；是否做物理隔离应由数据等级、威胁模型和成本共同决定，而不是把所有租户一律拆成独立集群。

验证隔离时既要测试直接越权，也要覆盖缓存命中、异步任务、恢复后的旧 Checkpoint、共享 Memory / Skill、Trace 导出和备份恢复等派生路径。很多跨租户泄漏并不发生在主数据库查询，而发生在这些旁路。

为什么只做权限不够 ​

即使权限完全正确，也可能出现 Noisy Neighbor（吵闹邻居）：

某个 Tenant 短时间创建大量 Run，把模型并发、Browser Slot 和 Sandbox 全部占满，导致其他业务不可用。

所以资源治理至少要覆盖：

Model Concurrency（模型并发）
Tool QPS（工具每秒请求数）
Sandbox Slots（沙箱槽位）
Browser Slots（浏览器槽位）
Subagent Count（子智能体数量）
Storage（存储）
Token Budget（Token 预算）
Cost Budget（成本预算）

四个关键机制 ​

Quota（配额）
规定每个 Tenant 最多能占多少资源。

Rate Limit（限流）
限制单位时间内请求速度。

Admission Control（准入控制）
系统资源不足时，决定新的 Run 是否允许进入。

Fair Scheduling（公平调度）
避免一个大客户或高流量任务饿死其他业务。

所以平台的资源治理目标不是：

“把机器利用率打满。”

而是：

在资源有限时，仍然保证关键业务的公平性、优先级和可预测性。

3.8 验证与评测为什么要分开 ​

Verification（验证）回答：

这一次 Run 真的完成了吗？

例如 Coding Agent：

tests passed
build passed
diff符合约束

Evaluation（评测）回答：

这个版本在一组任务上整体是不是更好。

例如：

Agent 新版本
在具有代表性的内部任务集上
成功率是否高于当前生产版本
成本是否下降
事故率是否增加

如果不区分，两种错误很常见：

一次任务成功
→ 误认为新版本整体更好

Benchmark 提升
→ 误认为每次生产任务都可以不验证

Eval 还要区分开发期、回归期和生产期 ​

企业评测至少有三种时间尺度：

Microsoft Agent Framework 当前提供 provider-agnostic 的 Evaluation Framework，可组合本地 Evaluator 和 Foundry Evaluator；AWS AgentCore 则直接支持 Online / On-demand / Batch Evaluation。[^ms-platform-evaluation][^aws-platform-evaluation-types]

所以：

Eval 不是上线前跑一次 Benchmark，而是覆盖 Build → Release → Production 的持续质量系统。

所以生产平台需要：

Online Verification（在线验证）
+
Offline / Continuous Evaluation（离线 / 持续评测）

四、企业应该怎样建设和演进平台 ​

4.1 平台建设应该怎样起步和分工 ​

先诊断问题，再规划路线 ​

Roadmap（路线图）不应该从 Feature List 开始，而应该先检查五类 Trigger（触发条件）。

Failure Trigger（失败触发）

例如：

• Tool 重复执行；
• Run 无法恢复；
• Trace 找不到根因；
• 权限事故重复出现。

Scale Trigger（规模触发）

例如：

• Tool 数量增长到人工目录和逐项配置难以治理；
• Agent 增长到跨团队共享能力成为持续需求；
• Waiting Run 达到几十万；
• Sandbox / Browser 数量快速增长。

Risk Trigger（风险触发）

例如：

• PII（个人可识别信息）；
• Production Write（生产写操作）；
• Payment（支付）；
• 外部网络；
• 高权限基础设施。

Reuse Trigger（复用触发）

例如同一个能力已经在多个独立 Domain 稳定重复：

Trace
Policy
Sandbox
Context Snapshot
Verification Hook

Governance Trigger（治理触发）

例如：

• 多团队；
• 多版本；
• 多 Tenant（租户）；
• 跨组织调用；
• 需要统一审计。

只有：

“以后可能会有很多 Agent。”

不构成建设复杂平台的充分理由。

平台能力应该怎样分阶段建设 ​

推荐顺序不是固定成熟度，而是“迁移成本 × 风险 × 复用价值”。

第一阶段：先统一治理主键

先统一四个基础对象：

• Run ID（运行实例标识）：每一次任务执行的唯一编号；
• Agent Version（智能体版本）：明确本次执行使用哪一版配置和逻辑；
• Trace Correlation（追踪关联）：把模型、工具、子智能体、审批和执行环境串成一条链路；
• Usage / Cost（用量 / 成本）：把 Token、模型、工具和执行资源消耗归属到具体 Run。

因为这些越晚统一，历史系统迁移越痛苦。

第二阶段：控制 Agent 能做什么

统一：

• Tool / Capability Contract（工具 / 能力契约）：统一输入、输出、副作用、权限、版本和重试语义；
• Identity / Policy（身份 / 策略）：明确“谁以什么身份对什么资源做什么”；
• Verification Hook（验证钩子）：允许业务域接入自己的成功判定；
• Artifact Contract（产物契约）：统一文件、报表、Diff、截图等产物的来源和生命周期。

这一步解决的是：

“不同 Agent 不能各自定义一套安全和结果语义。”

第三阶段：沉淀稳定执行契约 ​

例如：

• Loop（循环）：一轮 Agent 如何从决策进入执行并读取反馈；
• Context Interface（上下文接口）：业务域怎样提供本轮模型需要的信息；
• Budget（预算）：限制 Token、Tool、时间和子任务数量；
• Cancellation（取消）：用户取消后真实执行也必须停止；
• Trace Event（追踪事件）：把关键状态变化记录成可诊断事件。

第四阶段：长任务出现后建设运行时 ​

加入：

• Checkpoint（检查点）：保存可以安全恢复的运行状态；
• Wait / Signal（等待 / 信号）：让任务可以等待审批、回调或外部事件；
• Operation Ledger（操作账本）：记录真实副作用是否已经发生；
• Resume（恢复）：故障或长时间等待后从正确状态继续。

第五阶段：真实执行增加后建设执行层 ​

加入：

• Workspace（工作空间）：保存任务文件和中间状态；
• Sandbox（沙箱）：隔离不可信代码和工具执行；
• Browser / Shell（浏览器 / 命令行执行）：连接真实外部环境；
• Secret / Network（密钥 / 网络边界）：限制身份凭据和网络访问范围；
• Artifact（产物）：保存可验证、可审计的执行结果。

第六阶段：长期经验有价值后建设记忆与技能 ​

加入：

• Candidate Memory（候选记忆）：先把可能值得长期保存的信息作为候选；
• Governed Memory（受治理记忆）：经过权限、时效、来源和删除治理后再长期保存；
• Skill Registry（技能注册表）：统一管理可复用方法和流程；
• Learning Release（学习发布）：新经验经过评测、审核、灰度和回滚后再影响生产。

第七阶段：跨系统增长后建设协作与协议层 ​

加入：

• Delegation（任务委托）：把明确边界的子任务交给另一个 Agent；
• Registry（注册表）：让 Tool、Agent 和服务可被发现；
• Gateway（网关）：统一处理认证、路由、版本和审计；
• Federation（联邦）：在跨团队、跨组织或跨供应商场景下建立互信和互操作。

关键是：

不同业务可以停在不同阶段，没有必要追求“全部平台化”。

阶段不是按时间自动升级的成熟度勋章。每一步都需要进入条件、退出证据和回退路径；没有触发条件时，明确“不建设”也是架构决策。下面五个建设关口与上面的七个阶段严格对应：治理主键与执行契约覆盖第一至第三阶段，后四个关口分别对应第四至第七阶段。

这里的退出证据同时也是下一阶段的前置条件。若一个业务连统一 Run 和权限链都没有稳定，就不应因为行业产品提供了多智能体或长期记忆而提前引入它们。

自研、采购与开源如何选择 ​

Build vs Buy（自研还是采购）真正要回答的不是：

“核心能力要不要全部自己写？”

更稳定的判断维度是：

通常更适合复用：

• Model SDK；
• 通用 Workflow Runtime；
• Browser / Sandbox Provider；
• Tracing Storage；
• Protocol SDK；
• 通用 Eval Infrastructure。

企业必须掌握的是 Semantic Control（语义控制权）。

所谓语义控制权，不是要求企业自己实现所有基础设施，而是：

即使底层 Runtime（运行时）、Sandbox（沙箱）、Gateway（网关）来自外部产品，企业仍然掌握自己的 Run（运行实例）定义、权限模型、Domain Context（领域上下文）、业务验证标准、Skill（技能）治理、成本归属和审计语义。

换句话说，底层 Provider（供应商）可以替换，但“企业自己的系统到底怎样工作”不能由 Provider 定义。

所以：

Managed Runtime（托管运行时）
≠
把业务语义交给 Provider（供应商）

采购评估不能停留在 Feature Demo（功能演示）。候选产品应使用同一组真实任务和故障场景完成 PoC（概念验证），再比较三类成本：产品费用，集成、迁移和合规的人力成本，以及被锁定后替换供应商的退出成本。

采购结论应记录适用边界，而不是简单写“通过”。例如托管 Sandbox 可以用于通用代码执行，但生产数据库写操作仍必须走企业自己的身份、策略与审计链。这样 Buy 的是通用能力，不是把责任一起外包。

PoC 通过后还要把结论写进可运营的合同与运行手册。SLA 应明确统计对象、分子分母、排除条件、数据来源、故障通知时限、升级路径和违约处理，不能只写一个可用率数字；供应商维护窗口、版本弃用通知期、容量扩展提前量和安全事件协作也要有双方 Owner。

退出条款应约定配置、Run、Trace、Artifact 和审计数据的导出格式与时间窗口，迁移期间的只读访问、供应商协助、凭证撤销、派生数据删除证明和合同终止后的保留边界。平台 Owner 应按约定周期执行抽样导出和替代 Provider 演练，并把恢复时间、数据完整性和业务改造量回写采购评审。只有合同、日常监控、升级响应和退出演练形成闭环，“可替换”才不是纸面承诺。

平台团队和业务团队如何分工 ​

平台团队负责系统保证：

Contract 稳定
基础设施可用
策略可执行
版本可回滚
Trace 可关联
故障可恢复

Domain Team 负责业务含义：

用户目标
Domain Context（领域上下文）
Domain Tool（领域工具）
Business Invariant（业务不变量）
Verification Criteria（业务验证标准）
Domain Skill（领域技能）

可以进一步用 RACI（职责分工模型）理解。R 表示实际执行者，A 表示对最终结果唯一负责的人，C 表示决策前必须咨询的协作者，I 表示需要被同步结果的相关方。每项能力必须有且只有一个 A，否则事故发生时“共同负责”往往等于无人作最终决策。

RACI 只解决决策权，不替代运行手册。每个共享能力还应登记服务 Owner、值班方式、升级路径、依赖方和回滚权限，并在发布与事故演练中验证这些联系人确实能完成动作。

4.2 生产治理怎样覆盖发布、可靠性和合规 ​

发布时到底要版本化什么 ​

一次 Agent Release（智能体发布）通常不是只发布一段代码。

真正影响结果的版本不止一个，而且每一种版本变化都可能改变最终结果：

• Agent Version（智能体版本）：整套 Agent 配置和发布批次；
• Model Version（模型版本）：推理能力和行为可能发生变化；
• Prompt Version（提示词版本）：指令、约束和输出格式变化；
• Harness Version（执行外壳版本）：Loop、Observation、Tool 编排逻辑变化；
• Context Policy Version（上下文策略版本）：检索、排序、压缩和注入规则变化；
• Knowledge Snapshot / Source Version（知识快照 / 来源版本）：本次 Run 使用了哪一版权威来源、索引和撤销状态；
• Tool Version（工具版本）：输入输出 Schema 和副作用语义变化；
• Skill Version（技能版本）：可复用流程 / 经验变化；
• Policy Version（策略版本）：权限、审批和风险判断依据变化；
• Eval Dataset / Evaluator Version（评测集 / 评测器版本）：发布结论使用了什么样本和判断规则；
• Runtime Version（运行时版本）：Checkpoint、Retry、恢复语义变化；
• Execution Image Version（执行镜像版本）：依赖、系统环境和执行工具变化。

平台应生成不可变的 Agent Release Manifest（智能体发布清单），把上述版本、兼容范围、数据驻留要求和回滚目标绑定为一个可部署单元。Run 创建时只绑定发布清单标识，不能在执行途中悄悄读取“最新配置”。只有把这些版本都绑定到 Run，出现回归时才能定位“到底哪一层变了”。

例如：

成功率相对当前生产基线明显下降

可能来自：

• 模型升级；
• Tool Schema 改变；
• Prompt 修改；
• Skill 新版本；
• Context Ranking 改变；
• Harness Observation 格式改变。

一个成熟发布链路 ​

Build（构建）
↓
Offline Eval（离线评测）
↓
Replay（回放历史任务）
↓
Shadow（影子运行）
↓
Canary（小流量灰度）
↓
Progressive Rollout（逐步放量）
↓
Full Release（全量发布）
↓
Monitor（监控）
↓
Rollback（回滚）

每一道门禁都要有明确 Owner、输入证据和失败动作。离线评测不通过就停止发布；影子运行发现副作用差异时禁止放量；灰度阶段超过业务 SLO（服务等级目标）或风险阈值时，控制面应停止新 Run 使用新发布清单，并把流量切回上一个兼容版本。在途 Run 是否回滚则由状态兼容性决定，不能把流量回切等同于强制换掉在途代码。

长任务为什么让版本治理更复杂 ​

普通 HTTP 请求几十秒结束。

但一个 Agent Run 可能：

周一开始
→ 等待审批
→ 周三恢复

两天之间：

• Agent Version 变了；
• Tool Schema 变了；
• Runtime 升级了。

恢复时必须明确：

Pin Old Version（继续旧版本）
or
Migrate State（迁移状态）
or
Restart / Reconcile（重新执行 / 对账）

不能默认：

旧 Checkpoint
→ 最新代码

所以版本治理不是发布系统的“附属功能”，而是 Durable Agent（持久智能体）正确恢复的一部分。

高可用与灾难恢复怎么设计 ​

High Availability（高可用）关注：

局部组件故障时，系统能否继续服务。

Disaster Recovery（灾难恢复）关注：

更大故障域失效后，系统怎样恢复业务。

先要定义 Failure Domain（故障域）：

单 Worker
单 Sandbox
单服务实例
单 Availability Zone（可用区）
单 Region（区域）
外部 Model Provider
外部 Tool Provider

不同故障域需要不同策略。

RPO 和 RTO 是什么 ​

RPO（Recovery Point Objective，恢复点目标）
最多允许丢多少状态。

例如可以由业务先提出一个假设目标：“核心 Run State 最多允许丢失一个检查点周期”，再用故障演练确认该目标是否可达。具体时长必须来自任务价值、状态写入成本和恢复语义，不能从通用架构图直接给出。

RTO（Recovery Time Objective，恢复时间目标）
故障后多久必须恢复。

例如可以要求“核心 Agent Runtime 必须在业务允许的中断窗口内恢复”。具体窗口应由业务连续性分析和恢复演练共同确定。

平台至少要考虑 ​

• Multi-AZ（多可用区）；
• State Replication（状态复制）；
• Queue Recovery（队列恢复）；
• Artifact Backup（产物备份）；
• Provider Fallback；
• Runtime Store Failover；
• Region Recovery；
• Recovery Drill（恢复演练）。

多区域不是默认等于“所有 Run 主动双活”。控制面中的版本和策略可以跨区域复制，入口与无状态查询也可以主动双活；但带有顺序状态和副作用的 Run 通常应绑定 Home Region（归属区域），由单一写入者推进。跨区域接管必须带 Fencing Token（栅栏令牌）阻止旧区域继续写，并恢复同一份发布清单、状态和 Operation Ledger。

区域恢复顺序也不能只看基础设施：

冻结旧区域写入并提升新主
→ 校验状态、队列、计时器和 Artifact 完整性
→ 对 UNKNOWN Operation 向外部系统对账
→ 检查模型、Tool、Sandbox 等依赖健康与区域合规
→ 按租户和业务优先级分批恢复
→ 验证业务结果后再扩大流量

如果外部系统不支持幂等键或状态查询，高风险副作用 Run 不能自动跨区重放，只能暂停并进入人工对账。多区域投入只有在单区域故障影响超过建设和演练成本、且数据驻留允许跨区复制时才成立；否则更稳妥的选择可能是单区域多可用区加经过演练的冷备或温备。

Agent 平台特有的 Resume Storm ​

灾备恢复后还有一个传统系统经常低估的问题：

大量 Waiting Run
→ Region 恢复
→ 同时被唤醒
→ Model / Tool / Sandbox 再次被打爆

这叫 Resume Storm（恢复风暴）。

因此灾备恢复不能简单：

全部恢复

而需要：

• Staggered Wake-up（分批唤醒）；
• Admission Control；
• Priority Queue；
• Dependency Health Gate；
• Tenant Quota。

所以：

DR 成功不是“数据库恢复了”，而是业务在恢复后仍然能稳定继续。

数据治理与合规怎么落到平台 ​

Agent Platform 比普通应用更容易复制、转换和长期保存数据。

敏感数据可能出现在：

Prompt（提示词）
Context（上下文）
Tool Arguments（工具参数）
Tool Result（工具结果）
Artifact（产物）
Trace（追踪）
Memory（长期记忆）
Eval Dataset（评测数据集）

因此平台需要统一 Data Governance（数据治理）能力。

至少包括：

Classification（数据分级）
识别普通数据、内部数据、敏感数据、PII 等。

Residency（数据驻留）
规定数据必须存放在哪个国家、区域或 Provider。

Retention（保留期限）
不同数据保存多久。

Encryption（加密）
传输和存储过程中的加密要求。

Redaction（脱敏）
日志、Trace、Prompt 中哪些字段必须隐藏。

Deletion（删除）
用户或业务要求删除时，怎样沿派生链真正清理。

Audit Access（审计访问）
谁可以查看完整 Prompt、Tool 参数和敏感 Artifact。

Artifact 是最容易被忽略的风险 ​

例如 Data Agent：

数据库权限控制正确
↓
查询敏感数据
↓
生成 Excel
↓
Excel Artifact 被分享到公开频道

数据库本身没有越权，但最终数据仍然泄漏。

因此：

数据治理必须覆盖“数据从哪来、经过哪里、最后变成什么”，而不是只保护数据库入口。

平台能力怎样排优先级 ​

可以用一个概念模型：

Platform Priority（平台优先级）
≈
Reuse Frequency（复用频率）
× Failure / Risk Cost（失败 / 风险成本）
× Standardization Stability（标准化稳定性）
× Migration Urgency（迁移紧迫度）
-
Coordination Cost（协作成本）
-
Platform Complexity（平台复杂度）

不要求真的算分数。

它的价值在于阻止团队用：

“这个技术很新”
“这个功能别人有”

决定投资优先级。

基础优先级：越晚统一迁移越痛苦 ​

这些能力一旦历史数据和多个业务都依赖，再统一会非常昂贵：

• Run / Agent Version（运行实例 / 智能体版本）：所有 Trace、成本、事故都需要稳定主键；
• Trace Correlation（追踪关联）：没有统一关联键，跨模型 / Tool / Runtime 无法重建链路；
• Tool Contract（工具契约）：越晚统一输入、输出、副作用和权限语义，Adapter 越多；
• Identity / Policy Hook（身份 / 策略钩子）：安全边界不能等业务规模起来后再补；
• Artifact Contract（产物契约）：文件、报告、Diff 等长期留存对象要尽早统一来源和生命周期；
• Verification Hook（验证钩子）：单次 Run 是否完成必须有稳定接入点；
• Usage / Cost（用量 / 成本）：早期不归集，后面很难补历史账。

条件优先级：真实复杂度出现后共享 ​

这些能力确实重要，但通常只有场景出现后共享才有正收益：

• Durable Runtime（持久运行时）：出现长任务、等待、恢复需求后再上；
• Context Governance（上下文治理）：多数据源、多团队后才需要统一策略；
• Sandbox / Workspace（沙箱 / 工作空间）：有真实代码、浏览器或文件执行后再平台化；
• Approval（审批）：高风险写操作出现后成为一等能力；
• Eval / Observability Infrastructure（评测 / 可观测基础设施）：多个 Agent 开始共享质量闭环后再集中建设；
• Skill Registry（技能注册表）：只有 Skill 真正跨场景复用后才值得共享。

规模优先级：规模真正出现后再建设 ​

这些能力容易“看起来先进”，但规模不够时往往只增加复杂度：

• Dynamic Capability Router（动态能力路由）：只有 Tool / Agent 数量很大时才需要自动路由；
• Organization Memory（组织级记忆）：跨团队长期知识复用稳定后再建设；
• Cross-agent Learning（跨智能体学习）：先有稳定 Eval / Release 治理，再谈跨 Agent 学习；
• Multi-Agent Platform（多智能体平台）：只有并行、隔离、专业化收益明显时才有价值；
• Protocol Federation（协议联邦）：跨组织 / Vendor 后才需要；
• Global Scheduler（全局调度器）：资源规模和优先级冲突足够大时再建设。

“规模优先级”不是更高级，只表示：

更晚才可能产生正 ROI（投资回报）。

4.3 平台怎样提升效率并迁移存量系统 ​

平台怎样提升开发者效率 ​

Developer Experience（开发者体验）决定业务团队愿不愿意使用平台。

一个平台即使技术能力很强，如果：

创建 Agent 需要跨团队等待
申请权限缺少可预测时限
接一个 Tool 需要大量人工协调
上线依赖重复的手工配置

业务团队一定会绕开。

因此平台应该提供一条 Golden Path（推荐开发路径）：

Create Agent（创建智能体）
↓
选择模板
↓
声明 Context Source（上下文来源）
↓
注册 Capability（能力）
↓
配置 Policy（策略）
↓
接入 Verification（验证）
↓
自动生成 Trace / Eval
↓
本地测试
↓
Canary
↓
上线

配套能力通常包括：

• SDK（开发工具包）；
• CLI（命令行工具）；
• Developer Portal（开发者门户）；
• Local Debug（本地调试）；
• Test Harness（测试外壳）；
• Eval Dataset（评测数据集）；
• Template（模板）；
• Self-service Provisioning（自助资源申请）。

平台真正创造价值，不只是运行时更稳定，还应该让：

业务团队能更快、更安全地把 Agent 从想法带到生产。

已有系统时怎样迁移 ​

企业很少从 Greenfield（全新系统）开始。

更常见的是：

已经有多个 Agent
多种 Framework
多套 Trace
重复的 Runtime
每个业务有自己的 Tool 接法

这时不能 Big Bang Migration（一次性大迁移）。

更稳妥的是 Strangler Pattern（绞杀者模式）：

用新平台能力逐步包围并替代旧能力，而不是一次重写全部系统。

推荐顺序：

先统一 Run ID / Trace
↓
再统一 Tool Contract / Policy
↓
用 Adapter 兼容旧 Framework
↓
新 Agent 默认走新平台
↓
旧 Agent 按业务价值逐步迁移
↓
最后淘汰重复基础设施

迁移时要给旧系统留 Escape Hatch（逃生口）：

• 不强迫一次性迁移所有功能；
• 不要求业务先重写 Domain Logic；
• 先统一低风险、高收益的 Contract；
• 每次迁移都能回滚。

好的平台迁移应该让业务感觉：

“逐步接入以后更省事。”

而不是：

“为了接平台先把现有系统重写一遍。”

五、真实生产中最容易踩哪些坑 ​

本章案例用于推演生产机制，不指向某一家企业已经发生的具体事故。每个失败模式都从可观察现象反推责任边界，再给出修复和验证方式；真实项目应以自身 Trace、工单、审计和故障演练结果确认它是否存在。

5.1 贯穿案例：一次数据分析任务 ​

先看一个正向案例，再看后面的失败案例。

用户问：

“帮我分析华东区上个月 GMV 为什么下降，并给出主要原因。”

第一步：建立身份和 Run ​

平台首先确定：

user_id
tenant_id
agent_id
agent_version
run_id

这一步的意义是：

后面所有 Context、Tool、Artifact、Trace 和 Cost 都能回到同一个 Run。

第二步：构建业务上下文 ​

Context Engine（上下文引擎）读取：

• 当前最新 GMV 定义；
• 华东区域定义；
• 用户只看自营业务的历史澄清；
• 当前用户可访问的数据集；
• SQL Tool 定义。

平台不会把整个数仓都给模型，而只提供当前决策所需信息。

第三步：选择模型 ​

Model Gateway 根据：

• 任务复杂度；
• Context 长度；
• Tool Calling 能力；
• 成本预算；
• 数据驻留；

选择合适模型。

第四步：模型提出查询动作 ​

模型生成：

Action Proposal:
execute_sql(...)

这还不代表 SQL 已经执行。

Harness 只检查 Tool 的能力声明、当前可见性和输入契约是否匹配；它不能决定本次动作是否获准。完成契约检查后，Runtime 进入操作预留与授权步骤。

第五步：预留操作并完成授权 ​

在真正执行前，Runtime 请求 Operation Service 创建权威账本条目，并在 Run State 中保存 operation_id 引用：

operation_id
status = PLANNED

Policy Service 再基于以下信息独立授权，并签发绑定该 Operation ID 的授权票据：

• 用户身份；
• 数据集权限；
• 查询风险；
• 当前环境。

这样即使 SQL 执行后进程崩溃，Runtime 也能用引用查询权威账本，确认这一步是否发生过，而不是从自己的 Checkpoint 猜测外部结果。

第六步：Execution 执行查询 ​

Data Engine 做真正计算。

如果原始查询返回大量明细行，不应该全部送给模型。

正确处理：

Warehouse
→ Aggregate / Filter
→ Structured Result
→ Artifact / Query ID

模型只看到：

• row_count；
• GMV；
• YoY；
• top negative dimensions；
• query_id；
• artifact_ref。

第七步：继续下钻 ​

模型发现：

华东区某个品类贡献了主要降幅。

下一轮只对这个维度继续 Drill-down（下钻），而不是重新扫描所有数据。

第八步：Verification ​

最终不能只相信模型说：

“原因找到了。”

Verification 检查：

• 指标口径版本；
• SQL 是否成功；
• 时间范围是否正确；
• 结论是否有 Evidence；
• Artifact 是否可追溯。

第九步：Trace、Eval 和 Cost ​

整次 Run 记录：

• Context Snapshot；
• Model Version；
• SQL Tool Version；
• Token；
• Query Cost；
• Latency；
• Verified Result。

如果以后新版本回归，就能和当前生产版本做真实比较。

第十步：Learning Candidate ​

假设这次发现一个稳定经验：

“分析同比下降时，优先检查区域 × 类目贡献度。”

它只能先成为 Skill Candidate（技能候选）。

经过 Eval / Review / Release 后，才可以进入生产 Skill。

这个案例说明：

平台不是一个“大服务”，而是一组围绕 Run 协同工作的契约、运行、执行和治理能力。

同一套契约在不同 Agent 上承受的压力并不相同。平台不能把 Data Agent 的路径复制成所有业务模板，而要从场景特征推导重点保证：

这张表的推导方式比“为每类 Agent 建一套平台”更重要：场景改变的是保障强度和领域插件，不应改变 Run、授权、执行、证据、验证和追踪的基本语义。

5.2 过度平台化和抽象错误会怎样失败 ​

这一组事故表面上不同：

• 先建超级平台；
• 强制所有团队统一 Framework；
• 把 Multi-Agent 当平台卖点；
• 抽象错误导致业务不断 Escape Hatch。

但共同根因只有一个：

Platform 试图统一业务差异，而不是统一稳定系统不变量。

所以阅读下面几个事故时，重点不是记住四个案例，而是观察“平台越权”怎样以不同形式出现。

先建超级平台，再去找业务 ​

现象

平台团队一开始就规划：

Unified Harness
Memory Platform
Multi-Agent
Marketplace
Dynamic Router
Global Gateway

半年以后：

• 只有极少数 Agent 有稳定生产流量；
• 很多平台能力没人真正使用；
• 为了兼容未来场景，接口极度复杂；
• Domain Team 接入成本越来越高。

为什么一开始看起来合理

因为团队希望：

“一次把未来所有基础设施问题解决掉。”

但这里隐藏了一个假设：

未来问题
已经足够清楚

实际上 Agent 产品形态和业务边界还没有稳定。

根因

没有经过：

真实业务
→ 重复问题
→ 稳定语义
→ Shared Contract

直接跳到了 Platform。

常见错误修复

看到接入率低以后继续：

• 强制业务使用平台；
• 再增加 Feature；
• 再抽象一层；
• 用“长期战略”解释短期低使用率。

这通常会进一步恶化问题。

正确做法

选择少量高价值 Domain Agent
→ 找重复故障和重复建设
→ 抽稳定 Contract
→ 小范围共建
→ 观察多个独立团队是否自然复用
→ 再平台化

验证指标

• Shared Capability Adoption；
• Time-to-production；
• Escape Rate；
• Domain Team 接入工时；
• 平台能力真实调用量。

架构结论

平台是重复问题的结果，不是架构图的起点。

强制所有团队使用同一框架 ​

现象

平台为了统一：

• 强制所有团队用同一个 Python Framework；
• 统一 Agent Base Class；
• 统一 Planner；
• 统一 Prompt 组织方式。

开始时开发体验很好。

几个月后：

• Coding Agent 需要更深 Workspace 能力；
• Data Agent 需要 Semantic Layer；
• Research Agent 需要 Source / Citation；
• Ops Agent 需要强 Approval / Audit。

Framework 开始出现大量：

if domain == ...
special hook
custom override
escape hatch

根因

企业真正稳定的是：

Run
Tool Contract
Policy
Trace
Verification

而不是：

某个 Python 类库
某种 Planner
某个 Agent 抽象

错误修复 ​

继续扩展超级 Framework。

结果通常是：

• Core 越来越厚；
• 升级风险越来越大；
• Domain 反而被限制。

正确做法

统一：

Stable Contract
+
Shared Runtime / Execution / Governance

允许：

多 Framework
多语言
多 Domain Agent

通过 Adapter（适配层）接入平台。

验证方式

观察：

• 新框架能否在不修改平台 Core 的情况下接入；
• Framework 升级是否只影响 Adapter，而不是所有业务；
• Domain Team 是否仍然需要大量私有 Hook；
• 平台升级后的跨 Agent 回归率是否下降。

架构结论

企业应该统一协议和系统语义，而不是统一某一个快速变化的开发框架。

把多智能体当成平台卖点 ​

现象

系统设计一开始就出现：

Planner Agent
Coder Agent
Reviewer Agent
Tester Agent
Security Agent
Release Agent

看起来“组织完整”。

生产后发现：

• Token 成本显著增加；
• Handoff 很多；
• Context 大量复制；
• 错误在 Agent 间传播；
• 出问题时没人知道 Owner 是谁。

为什么会犯这个错误

团队把人类组织结构映射成 Agent 架构：

人类有 PM / 开发 / 测试
→ Agent 也应该这样拆

但 Agent 的合理边界应该来自：

• Context；
• Capability；
• Permission；
• Parallelism；
• Model Specialization；
• Ownership。

正确做法

先算：

Multi-Agent Net Benefit（多智能体净收益）
=
并行收益
+ Context Isolation（上下文隔离）收益
+ 权限隔离收益
+ 专业化收益

-
Coordination Cost（协调成本）
-
Context Duplication（上下文复制）
-
Merge Cost（合并成本）
-
Error Propagation（错误传播）

只有净收益为正，才值得拆。

验证方式

至少做：

• Single Agent 与 Multi-Agent 的 A/B；
• 比较 Verified Success、端到端时延和总 Token；
• 统计 Handoff 次数、Merge 失败和错误传播；
• 检查每个子 Agent 是否真的具有独立 Context / Permission / Parallelism 价值。

架构结论

Multi-Agent 不是成熟度等级，而是一种有明确成本的架构选择。

5.3 保障和治理缺失会怎样失败 ​

只看成功率，不做根因归因 ​

现象

团队只维护一个指标：

Task Success = 某个汇总值

当汇总成功率相对基线下降时，没人知道原因。

可能来自：

Model
Context
Tool
Permission
Runtime
Execution
Verification

任何一层。

错误做法

看到失败直接：

换更强模型

结果：

• 成本增加；
• 某些 Case 仍然失败；
• 真正问题可能是 Tool 不可见或 Context 过期。

正确做法

统一 Failure Taxonomy（失败分类）：

Task Understanding（任务理解）
→ 是否正确理解了用户目标和约束

Context（上下文）
→ 是否给模型看到了正确、最新、可信的信息

Capability Exposure（能力暴露）
→ 当前需要的工具和能力是否真的可见

Model Decision（模型决策）
→ 模型是否做出了合理的下一步判断

Permission（权限）
→ 动作是否因为权限、审批或风险策略被阻止

Execution（执行）
→ 真实工具、浏览器、代码或 API 是否执行成功

Observation（观察结果）
→ 原始执行结果是否被正确解释并反馈给模型

Verification（验证）
→ 最终结果是否真的满足业务完成条件

并在 Trace 中记录第一处偏离。

验证方式

比较：

same model + different harness
same harness + different model
same model + different context policy

做受控实验。

架构结论

成功率告诉你“系统好不好”，Failure Taxonomy 才告诉你“应该改哪里”。

长期记忆上线后无法真正删除 ​

现象

用户要求删除某条个人信息。

系统删除了：

memory table row

但信息仍然存在于：

• Vector Index；
• Summary；
• Skill；
• Eval Dataset；
• Trace；
• Offline Cache。

根因

系统把 Memory 当普通 KV Store（键值存储），没有建立 Data Lineage（数据血缘）。

正确做法

每个 Memory Item 都应记录：

source
derived_from
written_to
merged_into
used_by_skill
used_by_eval

Delete 必须沿血缘传播：

Primary Memory
→ Index
→ Derived Summary
→ Skill Candidate
→ Eval / Dataset

验证方式

删除一条测试数据后，主动扫描：

• 主存储；
• 向量索引；
• Summary；
• Skill Candidate；
• Eval Dataset；
• Cache；
• Trace 中允许被再次消费的 Payload。

只有所有“可用于未来推理”的派生数据都不可再读取，删除才算真正完成。

并区分：

• 立即删除；
• 软删除；
• 法规要求保留；
• 审计不可删除但不可再用于推理。

架构结论

长期学习一旦进入企业系统，就会变成数据治理问题。

共享核心升级引发全量回归 ​

现象

Harness Core 的新版本修改了 Observation Normalization（观察结果归一化）。

发布后：

• Coding Agent Tool Selection 下降；
• Data Agent SQL Retry 增加；
• Research Agent Source Ranking 异常。

几十个 Agent 同时受影响。

根因

共享能力提高了复用，但也扩大了 Shared Blast Radius（共享故障半径）。

正确做法

Shared Core 必须拥有比普通业务代码更严格的：

Version Pin（版本固定）
Replay（离线回放）
Shadow（影子运行）
Canary（小流量灰度）
Progressive Rollout（逐步放量）
Rollback（回滚）

同时：

Model Version（模型版本）
Prompt Version（提示词版本）
Tool Version（工具版本）
Harness Version（执行外壳版本）

都必须可以归因。

验证方式

用固定任务集执行：

• Offline Replay（离线回放）；
• Shadow Run（影子运行）；
• Small Canary（小流量灰度）；
• Progressive Rollout（逐步放量）。

比较成功率、成本、时延、Tool Error 和人工介入率，再决定是否扩大范围。

架构结论

平台化会集中故障风险，因此平台能力的发布纪律必须更强。

中央网关变成企业单点故障 ​

现象

所有：

Model
Tool
MCP
A2A
Browser

都必须经过一个中央 Gateway（网关）。

Gateway 故障后：

所有 Agent 同时不可用。

根因

团队为了统一治理，把 Control Plane 和 Data Plane 的所有关键流量都绑到了同一个组件。

正确做法

根据风险定义：

• 配置缓存；
• Local Decision Cache；
• HA（高可用）；
• Bulkhead（舱壁隔离）；
• Fail-open / Fail-closed；
• Emergency Bypass（紧急旁路）。

不是所有能力都应该“网关挂了就停”。

例如：

High-risk Authorization
→ Fail-closed

Trace Export
→ 可以 Degrade

静态 Tool Metadata
→ 可以 Cache

验证方式

至少演练：

• Gateway 单实例故障；
• Registry 不可用；
• Policy Service 延迟；
• Trace Backend 故障；
• 一个 Tenant 流量异常暴涨。

观察哪些能力被阻塞、哪些可以降级，以及是否会扩大成全平台事故。

架构结论

治理中心化，不等于数据路径必须单点中心化。

平台抽象错误导致业务团队不断绕行 ​

现象

平台统一：

• Prompt；
• Context Schema；
• Workflow；
• Memory。

Domain Team 开始出现：

• 私接 Tool；
• 关闭平台 Context；
• 自建 Runtime；
• 复制一套旁路。

平台把这种行为理解成：

“业务团队不愿意遵守规范。”

根因

真正的问题往往是：

平台把高变化业务语义错误提升成了 Shared Core。

正确做法

重新检查：

Stable Invariant（稳定不变量）
→ Platform（平台）

High-change Domain Meaning（高变化业务语义）
→ Domain（业务域）

并监控 Escape Rate：

业务团队为了绕开平台而自建旁路的比例。

Escape Rate 持续升高，通常说明：

• 抽象错误；
• Extension 不够；
• Developer Experience（开发体验）太差；
• 平台响应速度太慢。

验证方式

定期统计：

• 业务自建 Runtime / Tool Gateway / Trace 的比例；
• 私有 Hook 数量；
• 平台 Feature 被关闭的比例；
• Domain Team 接入周期；
• 平台需求平均响应时间。

架构结论

好的平台不是让业务无法绕开，而是让业务没有必要绕开。

六、怎样证明平台真的有效 ​

6.1 怎样从业务、质量和效率证明平台价值 ​

先看业务结果，而不是接入数量 ​

平台最容易自我满足的指标是：

已有很多 Agent 接入

但接入数量多并不代表平台创造了价值。

平台核心指标要能回答“是否创造业务价值、是否守住生产底线、是否值得继续共享”。建议只把下面八项放进管理看板，其余模型、工具和沙箱明细用于诊断：

可验证成功率不是模型自报“完成”，必须由外部业务条件确认。单位成功成本也不能只看 Token，因为低价但高失败率的 Agent 可能消耗更多重试、运行时、沙箱和人工复核成本。

端到端时延分位数、首 Token 时间、Tool 时延、沙箱供给时延、模型调用失败、权限拒绝原因、恢复阶段耗时和 Trace 覆盖率仍然重要，但它们负责解释核心指标为什么变化，不应与业务结果并列成一长串“平台成功指标”。

6.2 怎样证明平台具备长期治理能力 ​

平台治理要用核心指标触发动作 ​

治理不再另建一组英文指标清单，而是复用上面的高风险控制失效率、平台绕行率和可回滚发布覆盖率。Version Coverage（版本覆盖率）、Trace Coverage（追踪覆盖率）、Audit Completeness（审计完整率）、Shared Capability Adoption（共享能力采用率）和 Provider Swap Cost（供应商替换成本）作为诊断证据，用来解释发布为何不可归因、业务为何绕行或替换为何困难。

其中供应商替换成本非常重要。

如果换一个 Sandbox Provider、Model Provider 或 Runtime，需要重写所有业务 Agent，说明企业并没有真正掌握 Semantic Control。

上线前应该通过哪些门槛 ​

一个 Agent 从实验进入生产，至少应该经过：

Task Eval（任务评测）
Adversarial Eval（对抗评测）
Permission Test（权限测试）
Side-effect Test（副作用测试）
Recovery Drill（恢复演练）
Cost Load Test（成本压测）
Privacy Review（隐私审查）
Observability Review（可观测性检查）
Rollback Plan（回滚方案）

不同风险等级要求不同。

例如：

只读 Research Agent
→ 可以降低审批要求

Production Ops Agent
→ 必须提高权限、恢复、审计和 Verification 要求

成熟度不是“功能越多”，而是：

当前最关键的风险边界是否已经可靠。

七、企业最终应该形成什么架构判断 ​

7.1 最终应该坚持哪些平台边界原则 ​

平台不是智能体项目的默认终点 ​

平台应该来自：

真实业务
→ 重复问题
→ 稳定抽象
→ 共享能力
→ 治理

而不是来自行业架构图。

平台只统一稳定不变量 ​

值得长期统一：

Run（运行实例）
Identity（身份）
Policy（策略）
Tool Contract（工具契约）
Trace（执行追踪）
Verification（验证）
Artifact（产物）
Version（版本）

不应该强行统一：

业务 Prompt（提示词）
Domain Workflow（领域工作流）
Domain Context（领域上下文）
业务成功标准

不确定性应该局部化 ​

模型适合处理高不确定性的：

理解
推理
规划
探索
选择

软件和平台必须保证确定性的：

身份
权限
状态
版本
副作用
审计
恢复

7.2 最终应该怎样做投资和架构判断 ​

自研还是采购，关键看语义控制权 ​

企业不一定自己实现所有基础设施。

但必须掌握：

• 自己的 Contract；
• 自己的数据；
• 自己的 Policy；
• 自己的 Verification；
• 自己的 Eval；
• 自己的 Audit 语义。

平台能力必须证明正 ROI ​

每一个复杂平台能力都应该回答：

Trigger（触发原因）
→ 为什么当前方案已经不够

Decision（架构决策）
→ 要增加什么能力

Trade-off（代价与权衡）
→ 新增了什么复杂度

Evidence（验证证据）
→ 用什么指标证明它值得

如果回答不了 Evidence：

就不应该默认建设。

最终参考架构 ​

最终企业形态通常不是：

一个万能 Agent

也不是：

一个超级 Agent Framework

而更接近：

Shared Agent Platform（共享智能体平台）
+
Domain-specific Layer（领域专用层）

从一次 Run 的主路径看，最终架构应保持横向可追踪，而不是让各平台模块彼此旁路调用：

读图时先从左到右看一次任务怎样完成，再看保障轨怎样提供生产证明、控制轨怎样施加发布和治理约束。图中连到单个节点只是为了保持线条可读，两条轨道的语义覆盖整条 Run 链路。任何模块都不能跳过授权直接执行，也不能跳过领域验证把模型输出宣布为成功。

共享平台提供：

Stable Contract（稳定契约）
Runtime Guarantee（运行时保证）
Execution Boundary（执行边界）
Identity / Policy（身份 / 策略）
Trace / Eval（追踪 / 评测）
Version / Rollback（版本 / 回滚）

业务域提供：

Domain Context（领域上下文）
Domain Tool（领域工具）
Business Meaning（业务含义）
Verification Criteria（业务验证标准）
Domain Skill（领域技能）

这是一种比“统一所有 Agent 行为”更长期稳定的组织和架构方式。它也给出了第二次跨越的验收标准：生产可用解决单个 Agent 能否安全上线；企业级优秀架构还要证明多个业务能够在共享保证上独立演进，单个故障不会扩散，关键决策可以归因，供应商能够替换，平台投入能够用业务结果、质量、交付效率和总体成本共同解释。

附录 A：高频架构问题与快速回答 ​

附录用于快速架构判断，不再复制正文完整推导。

A.1 企业什么时候应该建设智能体平台 ​

不是 Agent 数量一多就应该建设。

真正值得平台化通常同时出现三类信号：

第一，多个团队重复建设同一种基础能力，例如 Trace、Policy、Sandbox、Runtime。

第二，这些能力已经形成相对稳定语义，不再每周变化。

第三，不统一会产生明显风险或迁移成本。

因此更合理的判断公式是：

Platform Value（平台价值）
≈
Reuse Benefit（复用收益）
+ Risk Reduction（风险降低）
+ Incident Reduction（事故减少）
+ Faster Delivery（交付加速）
-
Coordination Cost（协调成本）
-
Migration Cost（迁移成本）
-
Shared Blast Radius（共享故障半径）

如果只有少量 Agent，而且业务方向还在变化，优先保持简单通常更好。

A.2 Harness、运行时和执行层有什么区别 ​

可以用一句话记：

Harness
→ Agent 怎样工作

Runtime
→ Run 怎样可靠活着

Execution
→ Action 在哪里真正发生

Harness 关心：

• Context；
• Tool；
• Policy；
• Verification；
• Loop。

Runtime 关心：

• State；
• Checkpoint；
• Retry；
• Wait；
• Resume；
• Version。

Execution 关心：

• Workspace；
• Sandbox；
• Browser；
• Shell；
• Identity；
• Network。

三者协作，但不能混成一个“大 Agent Service”。

A.3 为什么状态、上下文和记忆不能混在一起 ​

因为它们解决完全不同的问题。

State 是：

当前任务真实发生了什么。

Context 是：

这一轮模型被允许看到什么。

Memory 是：

哪些信息值得跨任务长期保留。

如果把三者混在一起：

• Context 压缩可能误删真实 State；
• Memory 过期可能覆盖当前事实；
• 权限边界难以定义；
• Resume 无法重建真实执行状态。

所以必须在数据模型层分开。

A.4 为什么不应该默认使用多智能体 ​

Multi-Agent 会增加：

• Context 复制；
• Delegation；
• Merge；
• Runtime；
• Error Propagation；
• Trace Complexity。

只有当它带来的：

• 并行收益；
• Context 隔离；
• 权限隔离；
• 模型专业化；

明显大于这些成本时才值得。

所以默认策略通常是：

Single Agent
→ Workflow
→ Agent as Tool
→ Multi-Agent

逐步升级。

A.5 为什么不能只买一个智能体框架 ​

Framework 主要解决开发体验。

企业长期需要掌握的是这些不会随着 Framework 更换而消失的业务语义：

• Run Contract（运行契约）：一次任务怎样被唯一标识和追踪；
• Identity / Policy（身份 / 策略）：谁能代表谁做什么；
• Context Contract（上下文契约）：模型能看什么、来源和版本是什么；
• Verification（验证）：什么才算一次任务真正完成；
• Eval Dataset（评测数据集）：怎样判断新版本整体是否更好；
• Audit（审计）：谁在什么时候做了什么；
• Artifact（产物）：文件、报告、Diff 的来源和生命周期；
• Cost Allocation（成本归属）：模型 / Tool / Runtime 成本归谁。

Framework 可以换，但这些企业语义不能跟着一起丢。

所以：

Framework 可以 Buy；Semantic Control 必须自己掌握。

A.6 怎样判断平台建设成功还是失败 ​

不要只看：

接入多少 Agent

应该同时看：

Verified Success（可验证成功率）
Time-to-production（从开发到生产的时间）
Incident Rate（事故率）
MTTR（平均修复时间）
Cost per Successful Run（单次成功任务成本）
Shared Capability Adoption（共享能力采用率）
Escape Rate（业务绕过平台的比例）
Provider Swap Cost（供应商替换成本）

如果接入 Agent 很多，但：

• Domain Team 大量绕平台；
• Debug 更慢；
• 发布风险更高；
• 成本没有下降；

说明平台并没有真正成功。

A.7 为什么需要模型网关 ​

因为企业很少只使用一个模型。

不同任务在：

• 能力；
• Context Window；
• 成本；
• Latency；
• Tool Calling；
• 数据驻留；

方面要求不同。

Model Gateway 的价值是把：

Task Requirement
+ Model Profile
+ Cost / Latency Budget
+ Provider Health
+ Compliance

统一成模型路由决策。

它不应该只做“统一 API”，还要支持 Quota、Fallback、A/B、Provider Failover 和版本归因。

不适用场景：

只有一个模型、没有路由和治理需求的简单 Agent，不需要先建设复杂 Gateway。

A.8 多租户平台最容易漏什么 ​

最容易漏的是：

资源隔离，而不仅是数据权限。

即使 Tenant A 看不到 Tenant B 的数据，A 仍然可能通过大量 Run 占满：

• Model Concurrency；
• Browser；
• Sandbox；
• Tool QPS。

因此需要：

Quota
Rate Limit
Admission Control
Fair Scheduling
Cost Allocation

并按 Organization / Tenant / Project / Agent / Run 分层治理。

A.9 一个 Agent Release 应该版本化什么 ​

至少要能追踪：

Agent
Model
Prompt
Harness
Context Policy
Tool
Skill
Runtime
Execution Image

否则一旦回归，很难知道真正变化来自哪里。

长任务还必须解决旧 Run 与新代码共存问题，因此需要 Version Pin、Migration 和 Resume Compatibility Test（恢复兼容性测试）。

A.10 平台怎样做高可用和灾备 ​

先定义 Failure Domain，再定义 RPO / RTO。

不能只做数据库备份。

还要考虑：

• Queue；
• Timer；
• Artifact；
• Provider；
• Waiting Run；
• Resume Storm。

真正的 DR 成功标准是：

故障恢复后，Run 能继续，而且不会因为集中恢复再次把下游打垮。

A.11 已经有很多 Agent，怎样迁到统一平台 ​

不要一次性重写。

推荐 Strangler Pattern（绞杀者模式）：

统一 Run / Trace
→ 统一 Tool Contract / Policy
→ Adapter 兼容旧 Framework
→ 新 Agent 默认新平台
→ 旧 Agent 逐步迁移
→ 淘汰重复基础设施

每一步都要可以独立回滚。

A.12 怎样避免平台成为单点故障 ​

需要区分：

Control Plane
Data Plane
Assurance Plane

并为不同能力定义：

Fail-open
Fail-closed
Degrade
Cache
Bypass

例如：

• Authorization 无法判断：Fail-closed；
• Trace Backend 故障：Degrade；
• 静态 Tool Metadata：Cache；
• 非关键 Cost Aggregation：异步补偿。

平台化的目标是降低重复风险，而不是制造一个更大的共享故障域。

附录 B：竞品研究主要官方来源 ​

[^aws-agentcore]: AWS, Amazon Bedrock AgentCore FAQs, https://aws.amazon.com/bedrock/agentcore/faqs/ [^aws-runtime]: AWS, AgentCore Runtime, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html [^aws-gateway]: AWS, AgentCore Gateway Core Concepts, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-core-concepts.html [^aws-eval]: AWS, AgentCore Evaluations, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html

[^ms-foundry]: Microsoft, Foundry Agent Service Overview, https://learn.microsoft.com/en-us/azure/ai-foundry/agents/overview [^ms-hosted]: Microsoft, Foundry Hosted Agents, https://learn.microsoft.com/en-us/agent-framework/hosting/foundry-hosted-agent [^ms-toolbox]: Microsoft, Foundry Toolbox, https://learn.microsoft.com/en-us/agent-framework/integrations/by-component/tools/foundry-toolbox [^ms-hosting]: Microsoft, Hosting Agent Framework Applications, https://learn.microsoft.com/en-us/agent-framework/hosting/

[^google-platform]: Google Cloud, Vertex AI Agent Engine / Agent Platform, https://cloud.google.com/vertex-ai/generative-ai/docs/reasoning-engine/overview [^google-memory]: Google Cloud, Agent Engine Memory Bank, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/set-up [^google-code]: Google ADK, Agent Runtime Code Execution, https://google.github.io/adk-docs/tools/google-cloud/code-exec-agent-engine/ [^google-monitor]: Google Cloud, Monitor an Agent, https://cloud.google.com/agent-builder/agent-engine/manage/monitoring [^google-eval]: Google Cloud, Evaluate Agents, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/evaluate

[^openai-api]: OpenAI, Introducing the Agents API, https://openai.com/index/introducing-the-agents-api/ [^openai-sdk]: OpenAI, Agents SDK, https://openai.github.io/openai-agents-python/ [^openai-runstate]: OpenAI Agents SDK, Run State, https://openai.github.io/openai-agents-python/ref/run_state/ [^openai-tracing]: OpenAI Agents SDK, Tracing, https://openai.github.io/openai-agents-python/tracing/

[^openai-platform-tool-search]: OpenAI Agents SDK, Tool Search and MCP Tool Filtering. https://openai.github.io/openai-agents-python/tools/ [^aws-platform-tool-search]: Amazon Bedrock AgentCore, Semantic search for Gateway tools. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-mcp-semantic-search.html [^aws-platform-policy]: Amazon Bedrock AgentCore, Policy Engine for Gateway tool calls. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-core-concepts.html [^ms-platform-tool-approval]: Microsoft Agent Framework, Tool Approval. https://learn.microsoft.com/en-us/agent-framework/agents/tools/tool-approval

[^openai-platform-tracing]: OpenAI Agents SDK, Tracing. https://openai.github.io/openai-agents-python/tracing/ [^aws-platform-observability]: Amazon Bedrock AgentCore, Observability. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html [^aws-platform-evaluation]: Amazon Bedrock AgentCore, Evaluations. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html [^aws-platform-evaluation-types]: Amazon Bedrock AgentCore, Evaluation types. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations-types.html [^ms-platform-evaluation]: Microsoft Agent Framework, Evaluation. https://learn.microsoft.com/en-us/agent-framework/agents/evaluation

附录 C：参考资料与时效说明 ​

本文涉及的产品能力和行业实现会持续变化，动态事实以 2026-09-13 为核验基线。核心架构结论不依赖具体产品版本，但涉及以下产品时应优先查看官方文档：

• OpenAI Agents SDK / Agents API
• Google ADK
• Microsoft Agent Framework
• OpenHands
• Snowflake Cortex Agents
• Databricks Genie
• A2A Protocol