企业级 Agent 架构全景 ​

企业级 Agent 不是“LLM + Tools”的简单组合，而是一套由决策反馈、长期运行、真实执行、能力积累、系统协作和生产治理共同组成的工程系统。
本文用“三个阶段、两次跨越”建立全景：先解释 Agent Demo 为什么不能直接上生产，再回答已经能够生产运行的 Agent 如何继续升级为良好的企业级架构。

第一次跨越的核心是把“能跑通”变成“能被生产保证”；第二次跨越的核心是把“多个可生产 Agent”变成“能在多团队、多租户和多供应商环境中长期演进的企业架构”。后文的每个能力都必须能够说明：它解决哪次跨越中的什么问题，由什么生产信号触发，又把复杂度转移到了哪里。

一、从 Agent Demo 到可生产 Agent：第一次跨越 ​

假设我们做一个 Coding Agent。

用户说：

“把这个仓库的请求超时从 30 秒改成 60 秒，并确认修改后服务仍然正常。”

如果只看 Demo，这个任务似乎很简单：

用户问题
→ 模型理解
→ 调工具
→ 修改代码
→ 返回答案

但进入真实生产环境以后，马上会出现一系列问题：

• 模型应该看到整个仓库，还是只看相关文件？
• 模型说“我要改文件”，和文件真的被改，是不是一回事？
• Shell 返回 exit_code = 0，能不能说明修改正确？
• 如果任务执行一半进程崩溃，怎样恢复？
• 如果要等人工审批 8 小时，Run 怎么继续？
• Agent 到底用谁的身份访问仓库和生产环境？
• Shell、Browser、Code 到底在哪个环境执行？
• 修改产生的 Diff、日志、测试报告怎么保存？
• 下次遇到类似任务，哪些经验值得记住？
• 什么时候需要多个 Agent 协作？
• 另一个团队的 Agent 如何发现并调用它？
• 当企业有 100 个 Agent 后，Runtime、Trace、权限、评测、成本要不要每个团队都重做一遍？

于是问题从：

“模型会不会调用 Tool？”

升级成：

怎样把一个会推理、会调用工具的模型，建设成一个能够长期运行、可靠执行、受控访问真实世界、持续积累能力，并在企业规模下被治理和演进的生产系统？

1.1 最小行为闭环 ​

任何 Agent，最终都逃不开下面这条行为链：

这条闭环有三个最重要的“不等于”：

模型决定了
≠
真实动作已经发生

工具返回 success
≠
业务结果一定正确

模型说“完成了”
≠
系统已经验证完成

因此，企业 Agent 的核心不是“让模型多想几步”，而是让整条链路变得：

可控
可恢复
可验证
可观测
可扩展
可治理

1.2 为什么企业 Agent 架构会一步步“长出来” ​

企业 Agent 架构不是因为行业喜欢堆新名词，而是因为旧方案在新的任务形态和规模下逐渐失效。

可以把整个演进过程理解为：

LLM Application
→ 只能生成 / 理解

Tool-using Agent
→ 能对外产生动作

Agent Loop
→ 能根据环境反馈持续修正

Harness
→ 把自主行为放进可控制、可验证的工程边界

Durable Runtime
→ 让 Run 跨进程、等待、故障和版本继续活着

Execution Infrastructure
→ 让真实动作在正确身份、环境和隔离边界中发生

Memory / Skill
→ 把高价值历史经验转化为未来能力

Workflow / Multi-Agent
→ 当单一决策边界不够时，引入显式流程或多个决策主体

Protocol / Integration
→ 当跨系统、跨团队、跨 Vendor 协作增加时，建立稳定互操作契约

Enterprise Agent Platform
→ 当多个 Agent 重复建设基础能力时，把稳定不变量平台化

关键不是“从低级升级到高级”，而是：

每一层都应该由一个已经发生的 Failure Mode（失败模式）、Scale Problem（规模问题）或 Governance Problem（治理问题）触发。

因此，架构演进更准确的模型不是：

Feature 越多
= 越成熟

而是：

旧方案在当前约束下开始失效
→ 引入新的架构能力
→ 同时承担新的复杂度

但“可以上生产”仍然不是终点。当多个 Agent 分别完成第一次跨越后，企业会继续遇到语义不一致、基础能力重复、跨团队协作困难、供应商锁定和统一治理失效。这些问题不能靠“再把单个 Agent 做好一点”解决，而会触发第二次架构跨越。

1.3 四个视角怎样帮助理解企业 Agent ​

企业 Agent 很容易因为术语太多而失去主线。

一个更稳定的理解方法是从四个视角看同一个系统。

这四个视角不是成熟度等级，也不是四个互相独立的产品层。

它们是在回答同一个 Agent 系统的四类问题：

它怎样做出动作？
它怎样可靠活着？
它怎样形成长期能力并连接外部世界？
它怎样达到企业生产要求？

视角一：决策与反馈系统 ​

第一个问题是：

Agent 到底怎样工作？

最小闭环是：

Goal：明确目标
→ Context：准备当前模型真正需要的信息
→ Decide：判断下一步
→ Act：提出并执行动作
→ Observe：重新读取真实结果
→ Verify：判断是否满足完成条件
→ Continue / Finish：继续推进或结束

这组问题关心：

• 目标是什么；
• 模型这一轮应该看到什么；
• 模型如何选择下一步；
• 哪些动作允许被提出；
• 工具执行后如何形成新的 Observation；
• 系统如何判断是不是该继续；
• “完成”如何被重新验证。

它是 Agent 的“智能行为层”。

如果这一层设计不好，常见问题是：

上下文错误
工具选错
重复调用
无进展循环
模型假完成

这条主线主要对应：

• 《Agent Loop 与 Harness 架构》；
• 《Agent 上下文工程》。

视角二：长期运行的软件系统 ​

第二个问题是：

为什么一个能循环的 Agent，仍然不能直接上生产？

因为生产系统必须面对：

进程崩溃
机器重启
外部 API 超时
长时间等待
人工审批
部分副作用已经发生
版本升级
并发竞争
真实执行环境隔离

因此必须继续增加：

• Harness（执行外壳）：怎样把 Loop 工程化；
• Runtime（运行时）：Run 怎样跨失败、等待、重启继续；
• Execution（执行基础设施）：动作到底在哪里真实发生；
• State / Checkpoint（状态 / 检查点）；
• Workspace（工作空间）；
• Sandbox（沙箱）；
• Identity（身份）；
• Artifact（产物）。

可以先记一句：

Harness
→ Agent 怎么干活

Runtime
→ Run 怎么可靠活着

Execution
→ 动作在哪里真正发生

这条主线主要对应 Agent Loop 与 Harness、Agent Runtime 与持久执行、Agent 安全执行与结果验证。知识和上下文会影响决策质量，但不属于长期运行与真实执行的责任边界。

视角三：会积累、协作和连接的能力系统 ​

第三个问题是：

Agent 怎样从“一次任务”进化成长期能力和复杂系统？

这里其实有三个完全不同的方向。

方向一：纵向积累 ​

Agent 如何把过去经验转化成未来能力：

Session：保留持续交互历史
→ Memory Candidate：从历史中抽出“可能值得长期记”的候选信息
→ Memory：经过验证和治理后跨 Run 保留
→ Skill：把稳定经验进一步沉淀成可复用方法
→ Future Run：未来任务按需重新使用

需要区分：

• Session（会话）；
• Memory（记忆）；
• Knowledge（外部知识）；
• Skill（技能）。

方向二：横向协作 ​

一个 Agent 边界不够时：

常见协作机制包括：

Workflow：由程序预定义主要步骤
Multi-Agent：多个独立决策边界协作
Router：根据输入把任务路由到合适 Agent
Handoff：把后续控制权移交给另一个 Agent
Supervisor：一个 Agent 持续协调多个 Worker
Fan-out / Gather：把独立子任务并行发散，再汇总结果

但“更多 Agent”不代表更高级。

真正要问的是：

拆 Agent 是否带来 Context、权限、并行、专业化或 Ownership 的真实收益？

方向三：跨系统连接 ​

Agent 需要连接：

• Tool；
• 企业 API；
• UI / IDE；
• 远端 Agent；
• Event System。

这时才会出现：

不同边界通常使用不同连接方式：

MCP（Model Context Protocol，模型上下文协议）：Agent ↔ Tool / Data / App
A2A：Agent ↔ Remote Agent
ACP：IDE / Editor ↔ Coding Agent
AG-UI：Application / UI ↔ Agent Runtime
REST / gRPC / Event：成熟企业服务之间的传统集成

这条主线主要对应 Agent 记忆、技能与持续学习、Multi-Agent 与工作流编排、Agent 跨系统交互与集成治理。

视角四：企业生产系统 ​

第四个问题是：

技术上能跑，为什么还不能称为企业级？

因为企业真正关心的是：

因此，完整企业 Agent 体系必须同时看两个轴：

纵向：
Core Architecture
核心架构

横向：
Production Assurance
生产保障

也就是说：

核心架构回答“系统怎样工作”；生产保障回答“怎样确保它工作得好、稳、安全、可控、可评”。

二、两次跨越怎样推导完整企业 Agent 架构 ​

把前面的四个视角拼起来，可以得到下面的完整结构。

2.1 为什么自然形成 9 个专题 ​

这 9 个专题的顺序不是按“技术新不新”排列，而是按一个 Agent 从单次决策 → 当前信息 → 企业事实 → 跨 Run 经验 → 长任务存活 → 现实执行 → 多主体协作 → 外部互操作 → 企业平台化的依赖关系排列：

Agent Loop / Harness
→ Agent 怎样形成最小闭环、控制动作空间

Agent 上下文工程
→ 当前这一轮模型到底应该看到什么

Agent 知识检索与治理架构
→ Context 中那些“企业事实”从哪里来、为什么可信

Agent 记忆、技能与持续学习
→ 哪些经验值得跨 Run 保留，并升级成可复用能力

Agent Runtime / Durable Execution
→ 一个 Run 怎样跨等待、故障和升级继续活着

Agent 安全执行与结果验证
→ Action 最终在哪里、以什么隔离和身份真实发生

Multi-Agent / Workflow Orchestration
→ 一个决策主体不够时，怎样拆分和协调多个主体

Agent 跨系统交互与集成治理
→ 独立 Agent / Tool / System 怎样跨边界发现、授权和互操作

企业级 Agent 平台参考架构
→ 最后把前面稳定的不变量组装成共享平台能力

为什么 Knowledge、Memory、Runtime 必须按这个顺序展开：

先理解“模型这一轮需要什么信息”，再区分其中哪些是受治理的企业事实，继而判断哪些经验可以跨 Run 沉淀；完成信息生命周期的边界后，才讨论一个 Run 怎样跨时间和故障存活。

如果把 Knowledge 塞进 Context，Context 会吞掉 Source（来源）、Authority（事实权威性）、ACL（Access Control List，访问控制列表）、Freshness（新鲜度）和 Lineage（血缘）等独立治理责任；如果把 Knowledge 放到 Memory 后面，又容易让读者误以为企业知识来自 Agent 的历史经验。Memory 必须接在 Knowledge 之后，是为了先确立“企业事实不能被记忆覆盖”；Runtime 接在 Memory 之后，则是为了明确“跨 Run 保留经验”和“让当前 Run 跨故障存活”是两种不同生命周期。这个依赖关系分别在《Agent 知识检索与治理架构》《Agent 记忆、技能与持续学习》《Agent Runtime 与持久执行》中展开。

这 9 个专题不是按产品名拆出来的，而是从系统责任自然分解出来的。

2.2 Model Gateway 应该放在哪里 ​

模型当然是一等依赖，但它不适合再单独拆成“第 9 个核心架构专题”。

原因是：

模型负责推理能力；Harness 负责把模型放进一个可持续执行的系统；Model Gateway 负责企业规模下的模型路由和治理。

一个成熟系统通常要区分：

Model Provider：真正提供推理能力
Model Profile：某类任务需要什么能力、上下文、成本和时延
Model Gateway：统一路由、配额、审计、Fallback（故障回退）、A/B 实验和 Provider（模型供应商）切换
Harness：在每个 Run / Turn 上决定何时调用模型，并把结果接回 Agent Loop

这样既不会把企业架构绑死在某一个 Model Provider，也不会错误地把“模型选择”混进业务 Prompt。

但这不意味着所有团队第一天都应该建设独立 Model Gateway。
只有当多 Provider、统一配额、故障回退、A/B 实验、数据驻留或集中审计真正成为重复问题时，才值得把这一层独立平台化。

2.3 Knowledge 与 Context 有什么区别 ​

数据库、代码仓库、文档、搜索引擎等是信息源。

Context 是：

从这些信息源、State、Memory、Artifact 中选择并转换后，当前真正给模型看的内容。

因此：

Knowledge / Data Source
≠
Context

Retrieval
≠
Context Engineering 的全部

这也是为什么 Data Agent 的数据库、Coding Agent 的 Repo、Research Agent 的 Web，都可以共享同一套 Context Contract，但不会共享同一种 Retrieval 实现。

2.4 核心对象怎样划分 ​

企业架构很容易因为对象不分而变乱。

一个常见错误是：

一张 agent_state 表

同时装：

Conversation History：历史交互
Run Progress：当前任务执行到哪里
User Memory：值得长期保留的用户信息
Tool Result：工具原始返回
Artifact：需要保存或交付的产物
Trace：解释整个 Run 为什么这样执行

短期很方便，长期会导致：

• 生命周期混乱；
• 权限混乱；
• 删除困难；
• 恢复困难；
• Context 不可控。

更好的办法是把核心对象分成四组。

任务与执行对象 ​

Goal（目标） ​

用户真正想达成的结果。

例如：

“修复登录接口偶发 401，并确保测试通过。”

Task（任务） ​

为了实现 Goal 而形成的工作单元。

例如：

定位问题
修改代码
跑测试
验证结果

Session（会话） ​

持续交互容器。

一个用户可能连续几天和 Agent 围绕同一个仓库工作。

Run（运行实例） ​

围绕一个具体目标的一次可追踪执行。

Run 是企业治理最重要的主键之一，因为：

版本：这次到底跑了哪套 Agent 配置
成本：模型、工具、执行环境花了多少资源
Tool Call：调用了哪些能力
Artifact：产生了什么可交付结果
Approval：谁批准了高风险动作
Trace：为什么做出这些决定
Evaluation：这个版本整体表现怎样

最终都应该能关联 Run。

Turn / Step（回合 / 步骤） ​

Run 内更细粒度的推进单位。

一句话：

Session
→ 解决交互连续性

Run
→ 解决一次任务的执行和治理

信息与认知对象 ​

State（系统状态） ​

系统当前真正保存的相关事实。

例如：

任务已经完成哪些步骤
当前 Budget
等待哪个 Approval
已有 Artifact
工具调用结果

Context（模型上下文） ​

当前这一轮真正暴露给模型的信息。

所以：

State
≠
Context

更准确：

Context
=
从 State / Memory / Knowledge / Artifact 中
按任务、权限、预算、新鲜度
选出来的当前工作视图

Memory（记忆） ​

由过去 Run 或交互中沉淀、未来可能影响行为的信息。

例如：

“用户长期希望报告同时展示同比和环比。”

Knowledge（知识） ​

独立于具体 Run 的外部事实来源。

例如：

公司指标字典
产品文档
代码仓库
知识库

Skill（技能） ​

告诉 Agent：

“遇到某类问题，通常应该怎样做。”

它可以包含：

Instruction：什么时候、按什么步骤做
Script：适合交给确定性代码执行的部分
Reference：需要查阅的资料
Example：典型正确 / 错误示例
Verification：怎样证明 Skill 执行成功

所以：

Memory
≠
Knowledge
≠
Skill

动作与结果对象 ​

Capability（能力） ​

表示：

系统“能做什么”。

例如：

query_metric
modify_repository
send_notification

Tool（工具） ​

Capability 的具体实现入口。

同一个 query_metric 可以通过：

REST API：通过普通服务接口查询
SQL Tool：直接调用受控 SQL 能力
MCP Tool：通过 MCP 暴露能力
Remote Data Agent：把任务委托给远端 Data Agent

实现。

因此：

Capability 是稳定语义，Tool 是具体实现。

当企业能力规模扩大以后，还必须再区分三层：

Capability Registry（企业拥有的能力集合）
≠
Model-visible Tool Set（当前模型可见工具）
≠
Authorized Executable Set（当前身份真正可执行能力）

原因是“企业有这个能力”并不意味着每个 Agent、每个用户、每个阶段都应该看到它，更不意味着看到以后就自动获得执行权限。

因此大规模 Tool / Capability 的稳定主链路应该是：

Registry
→ Namespace / Search
→ Context / Phase / Identity Filter
→ Model-visible Tool Set
→ Model Selection
→ Authorization / Approval
→ Execution
→ Observation / Evidence

这条边界分别由《Agent Loop 与 Harness 架构》的执行外壳、《Agent 跨系统交互与集成治理》的协议与 Gateway（网关），以及《企业级 Agent 平台参考架构》的 Capability Control Plane（能力控制面）深入展开。

Action Proposal（动作提议） ​

模型提出：

“我要修改 config.yaml。”

此时真实世界还没有变化。

Execution（执行） ​

真正修改文件或调用 API。

Raw Result（原始结果） ​

Tool 的原始返回。

例如：

exit_code = 0
stdout = ...

Observation（观察结果） ​

把真实执行结果整理成 Agent 下一轮能理解的信息。

例如：

文件已修改
测试通过 123 项
当前 Diff 在 artifact://...

Artifact、Evidence、Verification 和 Evaluation ​

Artifact（产物） ​

Run 中产生、需要保存或交付的对象。

例如：

Report：报告
Dataset：数据集
Patch / Diff：代码修改差异
Chart：图表
Generated Code：生成代码

Evidence（证据） ​

用来证明某个结论成立的材料。

例如：

测试通过日志
Production Health Check
真实 SQL 结果

所以：

Artifact
→ 强调“产生和交付什么”

Evidence
→ 强调“凭什么相信”

Verification（验证） ​

回答：

“这一次 Run 真的完成了吗？”

Evaluation / Eval（评测） ​

回答：

“这个 AgentVersion 在一组任务上整体表现怎样？”

所以：

Verification
→ 单次任务闭环

Evaluation
→ 系统 / 版本级质量判断

Trace 和 Span 解决什么 ​

Trace（追踪链路）的目标不是“多记录日志”，而是让工程师可以回答：

这次 Run 用了哪个版本？
模型为什么调用这个 Tool？
传了什么参数？
动作在哪个环境执行？
发生了什么错误？
为什么 Retry？
最终为什么判断失败？

Span（追踪片段）是 Trace 中一个可独立计时、分析和诊断的动作。

例如：

Model Generation：一次模型推理
Tool Call：一次工具调用
Execution：一次真实执行
Approval：一次审批
Handoff：一次 Agent 控制权移交
Verification：一次完成条件验证

三、一次生产任务怎样穿过整套架构 ​

用一个 Coding Agent 看完整链路。

这张时序图只表达“一个 Run 中各责任层怎样协作”。
它不表示每个产品必须部署成独立服务。

用户：

“修复登录接口偶发 401，不修改数据库 Schema，并确保测试通过。”

3.1 建立任务边界 ​

系统首先形成：

Goal：最终目标
Constraints：不能违反的约束
Success Criteria：什么条件才算真正成功
Budget：允许消耗的时间、Token、成本和工具调用预算

例如：

Goal:
修复 401

Constraints:
不改数据库 Schema
不操作生产环境

Success:
相关测试通过
Build 成功
登录流程验证正常

这里主要涉及：

• 《Agent Loop 与 Harness 架构》；
• 《Agent Runtime 与持久执行》。

3.2 构建 Context ​

模型不应该直接看到整个 Repository。

系统选择：

Task
Repo Instructions
相关文件
错误日志
当前 Diff
历史尝试

这里主要涉及《Agent 上下文工程》和《Agent 知识检索与治理架构》：Knowledge Source（知识来源）、Authority（事实权威性）、Freshness（新鲜度）、Permission（访问权限）和 Evidence（证据）在这里进入 Context。

3.3 Agent 决定下一步 ​

模型判断：

“先检查 Token Refresh 逻辑。”

这仍然只是 Decision。

Harness 负责把：

Context
→ Decision
→ Action Proposal

形成可控闭环。

这里主要涉及：

• 《Agent Loop 与 Harness 架构》。

3.4 Tool 与权限判断 ​

Agent 想：

“读取 auth.ts。”

这对应：

Capability:
read_repository

Tool:
filesystem.read

如果下一步想修改文件，则：

Capability:
modify_repository

可能需要不同权限。

这里同时涉及：

• 《Agent Loop 与 Harness 架构》：哪些 Tool 应该进入当前模型动作空间；
• 《Agent 安全执行与结果验证》：动作最终在哪里真实发生；
• 《Agent 跨系统交互与集成治理》：能力怎样被发现、连接和治理；
• 《企业级 Agent 平台参考架构》：Registry、Identity、Policy、Approval 和 Eval 怎样平台化。

特别要注意：

Tool Discovery（发现）≠ Tool Visibility（可见）≠ Authorization（授权）≠ Execution（执行）。

3.5 Runtime 保存执行状态 ​

任务执行过程中：

已经读了哪些文件
已经完成哪些步骤
当前 Budget
当前版本
等待什么

必须被保存。

如果任务中途崩溃：

应该从 Checkpoint 恢复，而不是重新从第一轮 Prompt 开始。

这里主要涉及：

• 《Agent Runtime 与持久执行》。

3.6 Execution 真正修改代码 ​

修改不能只存在模型文本里。

需要进入：

Workspace：准备隔离工作空间
→ File / Shell：通过具体执行通道修改文件、运行命令
→ Sandbox：在受控资源和网络边界中运行
→ Real Action：真实世界状态发生变化

真实代码文件在这里发生变化。

这里主要涉及 Agent 安全执行与结果验证。

3.7 读取 Artifact 和 Evidence ​

执行产生：

patch.diff
test.log
build.log

其中：

patch.diff（代码差异）
→ 主要是 Artifact：需要保存、交付和继续消费

tests passed（测试通过结果）
→ 主要是 Evidence：用来证明修改没有破坏既有行为

这里同时涉及安全执行和 Harness 中的 Verification。

3.8 Verification 判断是否真的完成 ​

不能因为模型说：

“修好了。”

就结束。

系统重新验证：

测试是否通过
Build 是否成功
401 是否消失
是否违反“不改数据库 Schema”的约束

如果失败：

Observation
→ 回到 Context
→ Re-plan

如果成功：

Verified Result

3.9 Trace、Cost 和 Memory ​

Run 完成以后：

• Trace 记录为什么这样执行；
• Cost 记录模型、Tool、Sandbox 等成本；
• 成功经验可以成为 Memory / Skill Candidate。

于是：

Run 完成
→ 沉淀 Trace、Cost、Artifact
→ 从真实结果中提取 Memory / Skill Candidate
→ 经过验证、评测和治理
→ Future Run 再按需复用

这一条 Run 已经把 Loop、Context、Knowledge、Runtime、安全执行、Verification 和 Memory 的主要关系串起来。

如果还存在 Subagent / Remote Agent，Multi-Agent 与工作流编排、跨系统交互与集成治理也会进入同一 Run 的整体治理链路。

四、不同智能体场景为什么会给架构不同压力 ​

企业 Agent 不能只用一个对话场景验证架构。对话是否流畅，只能说明模型能够理解和生成；一旦 Agent 开始读取企业数据、修改代码或操作生产系统，架构面对的约束会完全不同。

这里选择 Data Agent、Coding Agent 和 Enterprise Ops Agent，不是因为它们覆盖所有业务，而是因为三者分别把架构推向三个不同的极端：企业事实是否可信、长链路执行是否可恢复、真实世界动作是否安全。

分析一个场景时，不能停在“它需要哪些能力”，而要沿着同一条链路推导：

业务目标
→ 场景的区别性特征
→ 简单方案从哪里失效
→ 需要什么系统机制
→ 机制引入什么新复杂度
→ 用什么证据证明设计有效

4.1 Data Agent（数据智能体） ​

用户问：

“为什么华东区域本月 GMV 下降？”

真正挑战不是 Text-to-SQL（自然语言生成 SQL），而是模型给出的结论能否代表企业认可的事实。

场景特征：答案来自受治理的数据，而不是模型记忆 ​

同一个“GMV 下降”问题可能同时涉及指标版本、退款口径、区域归属、统计时区、数据延迟和用户权限。SQL 即使能够执行，也可能查询了错误的数据集、使用了错误口径，或者把用户无权看到的数据带入分析。

它形成的压力链是：

自然语言问题存在歧义
→ 必须把“华东、本月、GMV”绑定到企业指标语义

企业数据具有行、列、租户和用途权限
→ 查询必须继承用户身份，并在数据侧再次授权

结果可能包含数百万行
→ 不能把原始结果全部塞进模型上下文

模型可以生成合理解释
→ 合理不等于结论正确，必须保留可核验的数据证据

关键机制：把语义决策、确定性计算和结论验证分开 ​

一个可生产的 Data Agent 至少需要以下链路：

问题解析
→ 指标与维度绑定
→ 数据源选择和权限检查
→ 查询计划与成本限制
→ 确定性执行、聚合和异常检测
→ 只把必要证据组装进 Context（模型上下文）
→ 生成解释
→ 业务规则与数据证据双重验证
→ 交付带来源、口径和时间范围的 Artifact（产物）

这里必须保持三个边界：

• 模型不拥有指标定义。 指标口径来自受版本治理的语义层。
• Agent 授权不替代数据授权。 即使 Agent 可以调用查询工具，数据平台仍要按最终用户、租户和用途执行行列级控制。
• 生成答案不代表验证完成。 系统要记录实际 SQL、数据快照或查询版本、过滤条件、指标版本和关键中间结果。

这套机制把复杂度从“模型自由理解所有企业数据”转移到语义治理、权限映射、结果物化和证据血缘。值得监控的不是回答是否流畅，而是：指标绑定准确率、越权查询数、证据覆盖率、成功任务查询成本，以及结论被业务规则否决的比例。

4.2 Coding Agent（编码智能体） ​

Coding Agent 的特点不是“会生成代码”，而是它要在一个有状态、包含不可信内容的工程环境里，连续执行读取、修改、构建和验证。一次任务通常跨越多个模型回合、多个进程和大量工具调用。

场景特征：执行链长、环境有状态、结果必须可复现 ​

典型闭环是：

Task：明确编码任务
→ Repo Context：读取相关仓库信息
→ Workspace：准备隔离工作区
→ Edit：修改代码
→ Shell：运行命令
→ Test：执行测试
→ Diff：生成修改差异
→ Verification：确认真的满足任务目标

简单方案会在下面几个位置失效：

任务持续时间超过一次请求或进程生命周期
→ 中断后丢失进度，或者只能从头重跑

仓库说明、依赖脚本和测试输出都可能是不可信输入
→ Prompt Injection（提示词注入）可能诱导高风险命令

修改文件、安装依赖、启动进程都会改变环境
→ Retry（重试）不再等价于安全重放

代码看起来正确
→ 不代表能够构建、通过测试或满足用户目标

因此，生产机制不只是增加一个 Shell（命令执行工具）：

Run / AgentVersion 固定任务与行为版本
→ 隔离 Workspace（工作空间）并建立基线快照
→ Policy（策略）筛选命令、文件和网络访问
→ 每个关键动作记录输入、结果和环境变化
→ Checkpoint（检查点）保存可恢复进度
→ Build / Test / Static Check 收集确定性证据
→ Diff 和任务级 Verification 判断是否真正完成
→ 产出可审查、可应用、可回滚的修改

这里的关键边界是：Harness 决定下一步做什么，Runtime 保证任务跨故障继续，Execution 提供隔离环境，Verification 根据测试和任务约束判断完成。把四者混在一个进程里，短任务看起来简单，但任务一旦中断、并发或升级，就很难判断哪些动作已经发生、哪些可以安全重试。

这套设计把复杂度转移到环境生命周期、检查点兼容、依赖缓存、进程回收和动作幂等。验证指标应至少包括：经过验证的任务成功率、相同环境下的复现率、中断恢复成功率、无效工具调用比例、每个成功任务的执行成本，以及失败后能否恢复到干净基线。

4.3 Enterprise Ops Agent（企业运维智能体） ​

面对：

“线上支付服务错误率突然上升。”

Ops Agent 面对的是持续变化的生产状态，并且可能执行扩缩容、隔离实例、调整流量或回滚版本等高影响动作。它和前两类场景最大的区别是：错误不仅会产生错误答案，还可能扩大真实事故。

成熟 Agent 不能：

看到告警
→ 猜原因
→ 直接重启生产

场景特征：状态短暂有效，诊断和执行风险不对称 ​

监控数据和服务拓扑会在诊断期间继续变化。Agent 在五分钟前形成的判断，到执行前可能已经失效；读取指标通常风险较低，而修改生产状态需要更强的授权、审批和审计。因此，诊断权限和生产写权限不能因为属于同一个 Agent 就合并。

正确闭环更像：

读取指标 / Runbook
→ 收集 Evidence
→ 形成诊断
→ 提出动作
→ Authorization
→ Approval
→ Production Execution
→ 重新读取环境
→ Verification
→ Audit

其中存在三条不能省略的控制链：

诊断结论
→ 只形成 Action Proposal（动作提议）
→ Policy / Authorization / Approval
→ 才能进入 Production Execution（生产执行）

调用超时或连接中断
→ 不能直接重试高风险动作
→ 通过 operation_id（动作唯一标识）和执行账本判断是否已经发生

动作返回成功
→ 不代表事故已经解决
→ 重新读取生产状态并执行 Verification

如果 Verification 失败，系统需要根据动作类型执行自动回滚、进入人工接管，或停止后续动作；如果授权或策略服务不可用，高风险写操作通常应该 Fail-closed（默认拒绝），而不是为了可用性继续放行。

Ops Agent 因此主要把压力施加在身份代理、最小权限、审批等待、幂等与对账、回滚、审计和实时验证上。关键指标包括：未授权生产动作数、动作审计完整率、错误动作拦截率、回滚成功率、人工接管率，以及 MTTR（平均恢复时间）是否在不增加事故率的前提下降低。

4.4 Shared Core 与领域能力怎样分工 ​

比较三个场景后，共享与领域边界才会自然出现：

推导结果不是“共同出现的功能都放进平台”，而是：

跨场景稳定且迁移代价高的语义
→ Run、Identity、Policy Hook、Trace、Artifact、Version
→ 适合形成 Shared Core（共享核心契约）

实现方式相似但允许替换的能力
→ Runtime、Sandbox、Approval、Evaluation Infrastructure
→ 适合成为 Standard Capability（标准平台能力）

决定业务含义和完成标准的内容
→ 指标语义、仓库规则、Runbook、业务 Verification
→ 必须留在 Domain-specific Layer（领域能力层）

平台统一的是系统保证，不是业务含义。反过来，业务团队拥有领域判断，也不意味着每个团队都应该重新定义 Run、身份、追踪和产物生命周期。

4.5 三类 Agent 对架构能力的压力并不一样 ​

这里的“压力”不是使用频率，也不是建设优先级，而是三个因素的组合：该约束出现的频率、缺失后的影响、系统需要提供的保证强度。

| 架构能力 | Data Agent | Coding Agent | Ops Agent | 为什么不同 | |---|---😐---😐---😐 | 上下文与业务语义 | 高 | 高 | 高 | Data Agent 的指标口径错误会产生形式正确但业务错误的结论 | | 持久运行与故障恢复 | 中 | 高 | 高 | 编码和运维任务更容易跨进程、等待与多次真实动作 | | 隔离执行环境 | 低~中 | 高 | 中~高 | Coding Agent 高频修改文件并运行不可信命令；Ops 执行通常由既有生产系统承载 | | 身份与权限 | 高 | 高 | 极高 | 数据越权会泄漏信息，生产越权还会直接改变业务状态 | | 产物与证据 | 高 | 高 | 高 | 数据结论和代码修改都依赖可交付、可复核的证据包 | | 完成验证 | 高 | 高 | 极高 | Ops 的“工具成功”与“事故恢复”之间风险差距最大 | | 记忆与技能 | 中~高 | 中~高 | 高 | 三者都有复用价值，但错误经验进入未来任务会形成不同治理风险 | | 审批与审计 | 中 | 高 | 极高 | 生产动作的不可逆性和影响范围最高 |

这个矩阵不能直接推出“高压力能力全部平台化”。例如，Data Agent 的业务语义压力很高，但指标定义仍应由数据业务域负责；Ops Agent 的审批压力极高，但具体变更规则仍应由服务 Owner（负责人）定义。是否平台化还要继续判断语义是否跨场景稳定、是否需要统一治理，以及复用收益是否高于协调成本。

因此，这一章真正得到的结论是：

企业级 Agent 架构不是为某一种 Agent 优化；它统一跨场景的系统保证，同时保留每个业务域对事实、动作和完成标准的定义权。

五、行业实现应该怎样作为架构证据 ​

行业调研最容易退化成：

“OpenAI 有什么、Microsoft 有什么、Google 有什么。”

这种方式很难形成架构能力。

真正应该问：

哪些实现代表了不同设计路线？

总纲中的目标不是证明某个产品“最先进”，而是从三类证据中提炼能够跨产品保留的架构规律。

三类证据的证明力不同。官方文档可以证明厂商公开承诺了什么，源码和公开实现可以说明机制如何组织，只有生产案例、事故和可重复评测才能进一步说明规模下的价值和代价。因此，本文的产品对照是架构输入，不是采购排名；表中的“企业最值得吸收什么”是基于公开材料的架构推导，不应被解读为未公开的生产结论。

5.1 不同技术路线分别验证什么架构问题 ​

Coding / Harness 路线 ​

代表实现可以关注：

• mini-SWE-agent；
• Pi；
• Claude Code / Claude Agent SDK；
• OpenAI Codex / Agents SDK / Agents API；
• DeepSeek Harness；
• OpenCode；
• OpenHands。

重点不是比较产品 Feature 数量，而是看：

Minimal Core：核心到底能有多小
Harness Boundary：Harness 与 Runtime / Execution 如何分边界
Plugin / Extension：扩展能力怎样插入而不污染 Core
Workspace：Agent 怎样管理工作目录
Sandbox：真实执行怎样隔离
Cloud Compute：Harness 与计算环境是否解耦
Verification：任务完成如何被系统验证

例如：

• mini-SWE-agent 帮助理解“最少需要什么”；
• Pi 强调 Core / Extension Boundary；
• Claude Code 更强调 Production Defaults；
• OpenAI Codex / Agents API 展示 Harness 与 Hosted / External Execution 的分离；[^openai-agents-api]
• DeepSeek Harness 展示 Plugin-first 思路。

通用 Agent / Workflow Framework ​

代表：

• LangGraph / LangChain；
• Microsoft Agent Framework；
• Google ADK；
• AutoGen。

重点研究：

State：执行状态怎样建模
Workflow：确定性流程怎样表达
Checkpoint：怎样保存可恢复点
HITL（Human-in-the-loop，人在回路）：怎样暂停并等待人工输入 / 审批
Multi-Agent：多个 Agent 怎样编排
Context Provider：不同上下文来源怎样接入
Runtime Boundary：框架和真正持久执行层的边界在哪里

目的不是选一个“最好框架”，而是理解：

确定性 Workflow 和 Agent Decision 怎样组合。

行业调研时还要区分三类证据：

官方产品 / 文档
→ 说明厂商“声称支持什么”

公开架构 / SDK / 代码
→ 说明机制“实际上怎么实现”

真实生产案例 / 事故 / Benchmark
→ 说明机制“在真实规模下有没有价值和代价”

只看产品文档，很容易得到“功能清单”；公开生产案例、事故和可重复评测才能补上 Failure、Scale 和 Trade-off。如果只有官方功能说明，就只能写成“官方文档显示具备该能力”，不能继续推导为“已在某种规模下被验证”。

Memory / Skill 路线 ​

代表：

• OpenAI Memory / Skills；
• Anthropic Agent Skills；
• Letta；
• Mem0；
• Zep / Graphiti；
• Hermes；
• Microsoft Agent Framework Memory / Context Provider。

重点研究：

Session vs Memory：持续交互和长期记忆怎样分开
Memory Scope：谁能看到 / 修改哪类记忆
Write Pipeline：什么信息有资格被长期保存
Authority / Confidence：来源是否有权威、判断有多确定
Progressive Disclosure：怎样按需逐层读取而不是一次全塞进 Context
Skill Lifecycle：技能怎样创建、验证、发布、回滚
Correction / Expiration：错误或过时记忆怎样纠正和过期

一个具有代表性的公开机制是 Agent Skills 的 Progressive Disclosure（渐进式披露）：先让模型看到技能名称和用途，只有选中后才继续读取详细说明和资源。它解决的是“技能一多就把全部说明塞进 Context，导致上下文膨胀和无关指令干扰”的失效；但它只解决按需加载，不自动解决技能内容是否可信、版本是否兼容、发布后是否回归。企业只有在技能数量已经造成稳定的上下文成本或发现困难，并且能够同时建立版本、评测、权限和回滚门禁时，才值得把它升级为共享 Skill Registry（技能注册中心）；少量静态技能用仓库目录和代码评审通常更简单。这里的机制事实来自公开产品说明，企业采用条件是本文基于责任边界作出的架构推导，不代表公开材料已经验证了所有规模与收益。

Runtime / Execution / Platform 路线 ​

代表：

• OpenAI；
• Microsoft；
• Google；
• AWS AgentCore；
• LangSmith；
• Temporal / Restate / DBOS 等 Durable Execution 体系。

重点研究：

Run Model：一次任务怎样成为可治理对象
Durability：任务怎样跨故障和等待继续
Execution Isolation：真实执行怎样隔离
Identity：谁在执行、代表谁执行
Observability：怎样解释一次 Run 为什么这样发生
Evaluation：怎样证明版本变好或变差
Control Plane：版本、Policy、Registry、Routing 怎样统一治理

这一组路线最值得吸收的代表机制不是某个产品的功能总量，而是 Durable Execution（持久执行）的“持久状态 + 可重放控制流 + 受约束副作用”：进程崩溃后由已记录的执行历史恢复，而不是从第一轮 Prompt 盲目重跑。它解决长任务因重启丢失进度、重复调用外部系统的问题；边界是外部副作用仍需幂等键、动作账本或对账机制，版本升级也必须处理旧状态兼容。企业只有在任务真实跨请求、跨进程、长时间等待，且失败重跑已经产生显著业务风险时才应引入；短事务 Agent 使用数据库状态机往往更经济。公开 Durable Execution 文档能够支持其恢复机制，至于某个 Agent 场景是否值得采用，仍需用本企业故障数据和恢复演练证明。

Platform 路线则可用 AWS AgentCore 将 Runtime、Identity、Gateway、Browser、Code、Observability 和 Evaluation 按资源边界拆分作为公开机制样本：它针对的是多个 Agent 重复建设运行、身份和观测能力而产生的治理不一致。代价是控制面依赖、资源模型约束和供应商退出成本；只有多个团队出现稳定复用需求，并完成身份映射、数据驻留、SLO（Service Level Objective，服务目标）和退出演练时，资源化平台才比团队自持组件更有价值。公开文档可以证明产品资源与契约，不能单独证明它在本企业的投资回报。

Domain Agent 路线 ​

必须关注：

• Snowflake Cortex / Cortex Agents；
• Databricks Genie；
• Coding Agent；
• Research Agent；
• Ops / IT Agent。

因为：

通用 Agent Platform 并不会消灭 Domain Context、Domain Permission 和 Business Verification。

这些路线不能只按产品名称记忆。把一个公开实现转化为企业架构结论，至少要完成四步：

例如，看到某个框架支持 Checkpoint，不能直接写成“支持持久执行”。还要检查它保存哪些状态、外部副作用是否可重放、升级后旧 Checkpoint 是否兼容，以及恢复时怎样确认上一次动作是否已经发生。只有对象、边界、故障和证据都闭环，功能名称才会变成可用于企业决策的架构机制。

5.2 为什么必须用统一机制横向比较 ​

行业调研最终不能停在“有哪些产品”。

真正有用的是把代表实现放到同一个机制坐标系里。

下表不是功能完整度排名，也不是“谁最好”；它用于识别不同产品 / 框架最值得学习的设计取向。

横向比较时固定问哪些问题 ​

对每一个实现都问同一组问题：

为什么不能按 Feature 数量选框架 ​

一个 Framework 支持：

Memory
Multi-Agent
Planning
Browser

并不能说明它更适合企业。

真正需要判断：

• 它的对象语义是否清楚；
• 生命周期是否完整；
• 是否能替换 Runtime / Execution Provider；
• 是否能接入企业 Identity / Policy；
• 是否支持 Trace / Eval；
• Failure 和 Version Boundary 是否明确；
• 团队是否愿意长期承担它的锁定成本。

所以：

行业调研的目标是理解 Design Pattern 和 Trade-off，不是得出“统一使用某框架”的答案。

什么时候更适合哪类技术路线 ​

这里不给“最佳框架”，而给选择条件：

最重要的原则：

先确认真实失败模式，再选择技术路线；不要因为某个 Framework 支持某个 Feature，就倒推自己需要它。

六、从可生产 Agent 到良好企业架构：第二次跨越 ​

一个 Agent 能够稳定服务真实用户，只能证明它完成了第一次跨越。当企业开始同时运行多个 Agent，问题会从“单个产品是否可用”变成“多个独立系统能否在共同规则下长期演进”。

第二次跨越通常不是由某个新 Framework 驱动，而是由下列可观测的生产症状共同推动：

读图的关键不是“所有能力都收到中央平台”，而是把跨业务稳定、迁移代价高、必须统一治理的语义抽成契约，同时让高变化的业务含义和验证标准留在 Domain Team。

企业平台在执行这次跨越时，最容易走两个极端。

极端一：每个 Agent 自己做所有基础能力 ​

结果：

权限不一致
Trace 分散
Runtime 重复
Sandbox 重复
Eval 各自为政

极端二：超级平台吞掉所有 Domain 逻辑 ​

结果：

平台团队成为瓶颈
业务无法快速演进
Core 不断膨胀
升级风险巨大

更健康的结构是：

Stable Core：跨 Domain 稳定、必须统一的核心契约
+
Standard Capabilities：平台提供默认实现、但允许替换的标准能力
+
Domain Extensions：由业务团队负责的领域专用能力
+
Independent Runtime / Execution：可独立演进的持久运行与真实执行层

6.1 Stable Core（稳定核心） ​

长期应该保持稳定的 Contract：

Run / Turn：统一执行身份与推进粒度
Tool / Capability Contract：统一能力调用语义
Context Interface：统一上下文进入模型的接口
Policy Hook：统一策略接入点
Budget：统一资源边界
Cancellation：统一取消语义
Verification Hook：统一完成验证入口
Trace Event：统一观测事件
Artifact Contract：统一产物生命周期

Stable Core 不是一组共享工具，而是一组跨团队不能各自解释的契约。以 Tool / Capability Contract 为例，至少要统一：调用主体、输入输出 Schema（结构约束）、风险等级、超时与取消、幂等要求、Artifact / Evidence 返回方式，以及版本兼容策略。平台可以允许不同执行实现，但不能允许同一个“成功”在不同 Agent 中代表不同语义。

判断某个对象是否真的属于 Stable Core，可以使用三个反事实问题：

如果两个团队定义不同，跨 Agent 追踪、授权或迁移是否会失败？
如果底层 Provider 被替换，上层业务是否仍需要这个语义？
如果平台暂时不可用，已经下发的契约能否让现有 Run 安全退化？

三个问题都成立，才说明需要稳定契约；仅仅“大家都调用过”并不足以进入核心。

6.2 哪些能力值得标准化 ​

平台提供默认实现，但允许替换：

Filesystem：文件读写能力
Shell：命令执行能力
Planning：显式规划能力
Compaction：上下文压缩
Skill：可复用方法包
Subagent：子 Agent 能力
Approval：人工审批能力

标准能力与稳定核心的区别在于：核心统一语义，标准能力提供可复用实现。企业可以把默认 Sandbox 从自研容器替换成托管执行环境，但 Workspace 隔离、身份注入、网络策略和结果证据的契约仍应保持。否则所谓“可替换”只是接口名称相同，迁移时仍要重写业务。

6.3 Domain Extensions（领域扩展） ​

Data：

Semantic Layer：业务语义层
Metric Definition：指标定义
SQL Verification：SQL 与结果验证

Coding：

Repository Intelligence：仓库结构与代码理解
Build / Test：构建与测试
Git：版本控制与 Diff / Merge

Ops：

Runbook：标准运维流程
Metrics：线上指标
Production Actions：生产环境动作

原则：

平台统一稳定不变量，Domain Team 保留业务语义。

6.4 一个能力什么时候才值得平台化 ​

不要因为第二个团队也需要，就立刻抽成 Platform Capability（平台能力）。

至少同时看四个条件：

如果一个能力：

业务语义很强
变化很快
只有一个 Domain 使用
平台团队无法定义正确的业务验证

就更应该留在 Domain。

一个非常实用的判断：

稳定不变量进入 Platform；高变化业务语义留在 Domain。

6.5 Primary Ownership 到底意味着什么 ​

主责任的含义是：

出现跨团队争议时，谁最终定义这个对象的 Contract、Lifecycle 和 Guarantee Boundary（保证边界）。

例如：

Runtime
→ Platform Team 定义 Run / Checkpoint / Resume 语义

Data Agent
→ Domain Team 定义 GMV 指标、业务校验和分析质量

两边可以共同开发，但不能出现：

大家都能改
+
没人真正负责

七、企业生产完整性怎样被保证 ​

企业架构不是把 9 个专题写全就自动完整。

下面这些问题必须有明确 Owner。

这些能力不会都属于某一篇，但整个企业架构中不能有“无人负责”的区域。

7.1 企业级能力至少要回答四个问题 ​

看到任何一个“企业能力”时，不要只问：

“有没有这个功能？”

还要继续问：

谁负责？
作用范围是什么？
失败时系统怎么退化？
保证边界在哪里？

例如“高可用”不能只写：

“服务部署多副本。”

而要说明：

• Control Plane 故障时，已有 Run 是否还能继续；
• Policy 服务不可用时，高风险动作是 Fail-closed（拒绝）还是 Fail-open（继续）；
• Trace Export 失败是否应该阻塞业务；
• Runtime Store 丢失时，哪些状态可以恢复，哪些不能。

企业级能力的关键不是 Feature Presence（功能存在），而是：

Failure Semantics（失败语义）是否明确。

7.2 三个典型故障场景怎样反推架构边界 ​

很多架构能力只有放入具体故障链，才能看清为什么存在。下列内容是用于架构推演的典型场景，不冒充某家企业未公开的真实事故。

Data Agent 把敏感数据发到公开频道 ​

链路：

用户有表权限
→ Agent 生成 SQL
→ 查询结果包含 PII
→ Chart Artifact
→ 分享到公开频道

问题不是 SQL 准不准。

真正失败的是：

Data Classification：数据是否包含 PII（个人可识别信息）/ 敏感字段
Artifact Policy：生成后的文件或图表允许怎样保存和传播
Destination Policy：结果允许发送到哪些目标
Identity / Authorization：当前主体是否有权执行和交付

架构结论：

权限不能只控制“能不能查询”，还要贯穿 Result → Artifact → Delivery。

Coding Agent Retry 导致重复发布 ​

链路：

Deploy Tool 已经成功
→ Runtime 等待结果时超时
→ 系统 Retry
→ 第二次 Deploy

如果发布动作不是 Idempotent（幂等）的，就会产生重复副作用。

架构结论：

Retry
≠
重新执行就好

必须有：

operation_id：给业务动作一个稳定唯一标识
idempotency：相同动作重复提交时只产生一次业务效果
operation ledger：记录动作是否已经真实执行
reconciliation：失败后重新读取真实世界并对账

Ops Agent 被网页 Prompt Injection 诱导执行命令 ​

链路：

Agent 搜索网页排障
→ 网页包含恶意指令
→ 指令进入 Context
→ Agent 提议 curl | sh
→ Shell 拥有外网和高权限

问题跨越了多层：

Context Trust：网页内容是否可信、能否影响决策
Execution Policy：哪些动作允许进入真实执行
Network Boundary：执行环境能访问哪些网络目标
Permission：当前主体是否有执行权限
Approval：高风险动作是否必须人工确认

架构结论：

企业安全不是一个 Guardrail 能解决的，而是多层边界共同约束。

八、架构为什么不断演进但复杂度不会消失 ​

这是理解企业 Agent 架构最重要的专家视角之一。

任何一个看起来“更先进”的架构方案，本质上都不是把复杂度消灭，而是把复杂度从一个难治理的位置，转移到另一个更适合被控制的位置。

因此，架构评审不能只问：

“这个方案解决了什么？”

还必须继续问：

“它把复杂度转移到哪里？我们是否有能力治理新的复杂度？”

这是避免“为了高级而架构”的关键。

8.1 生产症状怎样推动架构升级 ​

企业不应该把架构成熟度理解成固定的：

Stage 1
→ Stage 2
→ Stage 3

因为 Context、Runtime、Execution、Security、Learning 等维度会按照不同业务压力独立演进。

这一章先回答：

真实生产症状分别会把哪一个架构维度推向下一层。

症状如何映射到能力 ​

为什么成熟度不是单线 ​

企业可以在不同维度独立升级：

Loop：反馈闭环是否可靠
Context：模型输入是否可控
Harness：执行语义是否统一
Runtime：长任务是否可恢复
Execution：真实动作是否隔离
Control：权限、审批与策略是否成熟
Observability / Eval：是否可诊断、可证明版本质量
Learning：Memory / Skill 是否形成受治理的长期能力

例如：

• 一个 Ops Agent 可以很早拥有强 Approval，但没有 Memory；
• 一个 Research Agent 可以拥有复杂 Context，却不需要 Durable Runtime；
• 一个 Coding Agent 可以先有 Sandbox，再逐步引入 Multi-Agent。

所以：

成熟度不是用了多少高级 Feature，而是当前业务需要的关键边界是否已经可靠。

8.2 五类 Trigger 怎样驱动架构升级 ​

企业架构不应该按“别人有、所以我也要有”演进，而应该根据可观测信号升级。

可以统一用五类 Trigger 判断：

Failure Trigger
→ 现有方案已经频繁失败

Scale Trigger
→ 数量 / 并发 / 生命周期使简单方案失效

Risk Trigger
→ 副作用、权限或合规风险明显上升

Reuse Trigger
→ 多个 Agent 重复建设同一能力

Governance Trigger
→ 多团队、多版本、多租户开始失控

典型例子：

任何升级都应该同时写清：

Trigger
→ 为什么当前方案开始失效

Decision
→ 引入什么能力

Trade-off
→ 新增什么复杂度

Evidence
→ 用什么指标证明升级有效

这四步应该成为整个系列后续所有架构建议的统一格式。

九、企业真正应该优先投资什么 ​

Reference Architecture 的价值不是“图很漂亮”。

它必须能指导：

今年先建设什么
什么能力值得共建
什么应该留给业务
什么应该 Buy / OSS / Managed
怎么证明平台投入有效

建设顺序不是一张固定的产品路线图，而是一条由迁移代价、当前复杂度和真实规模共同驱动的升级路径。

这条路径允许不同架构维度以不同速度演进。高风险 Ops Agent 可能很早就需要 Approval 和 Sandbox，但长期都不需要 Multi-Agent；Data Agent 可能优先投资 Knowledge 和 Context，而不是 Durable Runtime。所以本文从首次出现起所说的 P0、P1、P2 均指投资优先级：它们表示投资逻辑，不是质量等级、成熟度等级，也不是强制每个 Agent 依次实施所有能力。

P0、P1、P2 也不是按年份排定的项目阶段，而是三种不同的投资依据：

每一项投资都必须能够回答“如果不建设，当前哪个可观测问题会继续恶化”。答不出来的能力进入候选池，而不是进入路线图。

9.1 P0：越晚统一，迁移代价越大的语义 ​

通常包括：

Run / AgentVersion：统一任务和版本身份
Tool / Capability Contract：统一能力调用语义
Identity / Permission：统一身份和授权边界
Trace Correlation：统一跨层追踪关联
Artifact：统一产物生命周期
Verification Hook：统一完成验证入口
Usage / Cost：统一资源使用与成本归因

这些定义如果被几十个 Agent 各自实现，后面很难统一。

P0 的决策增量不是再建一套平台，而是把已经重复出现、迁移代价高的语义变成可版本化契约；如果目前仍只有一个团队和一个 Agent，先保留清晰接口与 Owner 即可，不必提前建设集中控制面。

9.2 P1：复杂度出现后建设 ​

例如：

Durable Runtime：长任务持久执行
Sandbox / Workspace Platform：受控执行环境
Approval Workflow：人工审批与恢复
Context Platform：共享上下文契约与治理
Skill Registry：技能版本、发布和回滚
Evaluation Infrastructure：评测集、评测器和发布门禁

它们很重要，但不应该在没有真实需求时一次性建设完整平台。

P1 相比 P0 的决策增量，是针对已经发生的长任务中断、危险执行、人工等待或发布回归提供系统保证。每项能力应由对应故障或治理证据单独触发，不要求把 Runtime、Sandbox、Approval、Context、Skill、Evaluation 打包建设。

9.3 P2：规模真正出现后建设 ​

P2 不是“高级能力购物清单”。每一项都必须由可观察的规模瓶颈触发，并从最小机制开始：

P2 的决策增量是优化已经存在的跨团队规模问题；若触发指标、失败风险和退出条件都说不清，继续使用显式路由、团队配额和人工治理通常更稳妥。

9.4 Build、Buy、OSS 和 Managed 怎样决策 ​

这里的 OSS 指 Open-source Software（开源软件），Managed 指由供应商承担主要运行维护责任的托管服务。四类选择不是互斥标签：企业常见方案是掌握关键契约，自研差异化控制面，同时组合开源组件和托管基础设施。

采购流程中的 RFI 指 Request for Information（信息征询），用于在正式 PoC 前按数据驻留、安全、集成和服务边界等硬条件筛除明显不适配的候选方案。

判断不是：

“核心的一律自研。”

更合理的决策维度：

即使底层购买，也建议企业掌握：

Run Contract：企业自己的运行语义
Identity / Policy：身份和治理边界
Domain Context：业务语义与领域数据
Business Verification：什么才算业务真的完成
Eval Dataset：企业真实任务评测集
Skill Governance：技能发布、权限和回滚
Cost Allocation：成本归因规则
Audit Semantics：审计到底记录什么、如何追责

采购决策的关键不是选出功能最多的产品，而是在企业真实任务、风险和三年成本下，验证候选方案能否被接入、运营、替换和退出。

PoC（Proof of Concept，概念验证）怎样避免变成功能演示 ​

PoC 应使用企业自己的任务分布、权限边界和故障条件，而不是厂商准备的 Happy Path。一个能够影响决策的 PoC 至少要产出：

TCO（Total Cost of Ownership，总拥有成本）为什么不是 API 单价 ​

企业应该按同一个可验证的任务口径比较候选方案：

Three-year TCO
= 模型与 API 成本
+ Runtime / Sandbox / Storage / Network 成本
+ 平台接入与迁移成本
+ 安全、合规与运营人力
+ 故障、限流与人工介入成本
+ 退出和数据迁移预留

评估时还要分别对任务量、平均步数、模型结构、并发 Sandbox、人工审批率和失败重试率做敏感性分析。如果某个方案只在厂商假设的任务分布下便宜，它就不是可用的企业成本结论。

SLA（Service Level Agreement，服务等级协议）和退出路径怎样进入架构 ​

合同不能代替架构容错。企业需要同时明确：哪些故障由厂商负责，限流、区域故障或能力下线时系统如何降级，原始 Trace、Artifact、评测数据和配置能否导出，以及替换 Provider 时哪些企业 Contract 保持不变。

一个候选方案如果没有被实际执行过数据导出、Provider 替换或受控降级，“不锁定”就仍然只是合同或架构图上的承诺。

9.5 一个典型的建设优先级案例 ​

假设企业现在有 12 个 Agent：

每个 Agent 自己封装 Model Client
各自记录日志
Tool 权限规则不同
3 个 Agent 开始跑长任务
只有 1 个 Agent 使用 Browser
还没有真正跨团队 Multi-Agent

这时候不应该优先建设：

Agent Marketplace
复杂 Multi-Agent Supervisor
统一长期 Memory Platform

更合理的顺序通常是：

1. Run / Trace / AgentVersion 统一
2. Tool / Capability Contract + Identity / Policy
3. Shared Harness Primitive
4. 只给那 3 个长任务 Agent 补 Durable Runtime
5. Browser / Sandbox 在真实复用出现后平台化
6. Memory / Multi-Agent 在出现重复业务需求后再建设

为什么？

因为前 3 项解决的是：

已经发生的重复和治理问题。

后面的能力解决的是：

局部或未来可能出现的问题。

这体现的是：

Architecture Priority = 当前真实痛点 × 风险 × 复用收益，而不是技术新颖度。

9.6 平台 ROI（Return on Investment，投资回报） ​

平台成功不能只看：

“接入了 200 个 Agent。”

更应该看：

新 Agent 上线时间：开发效率
Shared Capability Reuse：共享能力真实复用率
Verified Success：经过验证的任务成功率
Incident Rate：生产事故率
Debug MTTR：平均定位 / 修复时间
Change Failure Rate：版本变更导致失败的比例
Cost per Verified Successful Task：每个验证成功任务的完整成本

这些指标必须按统一任务口径计算，否则平台可以通过接入更多简单 Agent、减少验证步骤或隐藏人工成本制造虚假收益。至少要固定：任务类型和难度分布、统计窗口、Agent / Model / Tool 版本、成功条件，以及模型、执行环境、存储和人工介入的完整成本。

三个最容易被误用的口径是：

平台 ROI 应与引入前基线或受控对照比较，并同时观察质量、事故和成本。只降低成本但降低验证成功率，或者提高成功率却让高风险事故上升，都不能被认定为正向收益。

十、最终企业级 Agent 参考架构 ​

经过前面的推导，完整企业 Agent Platform 可以进一步分成三个逻辑责任面。

这里的“平面”是架构责任划分，不代表必须部署成三个独立微服务或三个物理集群。
小规模系统完全可以由同一套代码承载多个责任面；规模扩大后再根据生命周期、SLO、风险和团队 Ownership 拆分。

三个平面不是三组功能清单，而是围绕一次 Run 形成控制闭环：控制面下发版本、策略和配额；数据与执行面在这些约束下推进任务并产生状态、Artifact 和 Evidence；生产保障面异步或同步评估运行证据，再把质量、风险和成本信号反馈给发布与治理决策。

这张表也是拆分服务时的约束：数据流量大或团队不同，不足以单独证明需要拆服务；只有生命周期、延迟、故障策略和责任主体出现稳定差异时，逻辑责任面才需要进一步物理拆分。

10.1 控制面（Control Plane） ​

负责：

Agent Registry：企业有哪些 Agent、谁负责
AgentVersion：当前生效的是哪套配置
Model Routing：模型选择与 Fallback
Tool / Capability Registry：有哪些可调用能力
Policy：授权与风险策略
Quota：配额与资源上限
Skill Version：技能版本
Context Policy：上下文选择策略
Experiment / Rollout：实验、灰度和发布

回答：

系统“应该怎样运行”。

10.2 数据与执行面负责什么 ​

真正承载：

Model Turn：模型推理
Context Build：组装当前模型输入
Tool Call：调用能力
Runtime State Transition：更新运行状态
Sandbox：隔离执行
Browser：网页操作
Shell / Code：命令或代码执行
Artifact IO：产物读写
Remote Agent Call：调用远端 Agent

回答：

系统“正在怎样运行”。

10.3 生产保障面（Assurance Plane） ​

横向负责：

Security：安全与信任边界
Observability：观测和根因定位
Evaluation：质量证明
Reliability：故障恢复和稳定性
Cost：完整成本与预算
Governance：版本、审计、合规和组织治理

回答：

系统“运行得是否可信、稳定、可解释、值得”。

10.4 三个平面为什么必须分开 ​

三个平面最大的区别不是“部署在哪个服务”，而是故障时是否应该阻塞真实任务。

例如：

Trace Export 暂时失败
→ 通常不应该让用户任务直接失败

Production Authorization 无法判断
→ 高风险写操作通常应该拒绝

Runtime Durable Store 不可用
→ 长任务不能假装仍具备恢复保证

因此：

企业架构必须明确每个依赖失败时是 Fail-open（失败时继续放行）、Fail-closed（失败时默认拒绝）、Degrade（降级执行）还是 Queue（进入队列等待）。

这就是真正的 Guarantee Boundary，而不只是画三层方框。

10.5 最终架构原则 ​

整个体系可以压缩成：

Domain Agent：承载业务目标与领域语义
+
Shared Harness / Context / Orchestration：共享 Agent 工作机制
+
Durable Runtime：可靠持久运行
+
Execution Infrastructure：真实动作执行
+
Memory / Skill / Integration：长期能力与外部连接
+
Production Assurance：质量、安全、可靠性、观测、评测、成本
+
Control Plane：版本、策略、Registry、Routing 等统一治理

企业真正应该统一的不是某个 Framework，而是稳定 Contract 和治理语义。

十一、最终应该留下哪些稳定架构判断 ​

这套系列最终不应该只留下术语，而应该留下可以跨框架、跨模型、跨业务复用的判断方式。

11.1 七个架构师级结论 ​

结论一：Agent 的核心不是“会调用 Tool”，而是“能在外部反馈下持续修正，并被系统验证”。

因此：

Tool Calling
≠
Agent System

真正决定生产能力的是反馈、状态、权限、执行和验证能否形成闭环。

结论二：不确定性应该被局部化，而不是扩散到整个系统。

不确定的理解 / 决策
→ 可以交给 Agent

确定性的状态、权限、版本、审计、不可逆动作
→ 应交给 Software / Platform

结论三：好的架构不会消灭复杂度，只会把复杂度转移到更可治理的位置。

所以任何新能力都必须同时评估：

Solved Complexity
vs
Transferred Complexity

结论四：平台化的对象应该是稳定不变量，而不是快速变化的业务逻辑。

因此长期值得企业掌握的是：

Run / Identity / Policy / Tool Contract / Trace / Verification / Artifact / Version

而不是把所有 Domain Prompt、业务语义和工作流都吞进中央平台。

结论五：架构成熟度不是用了多少高级 Feature，而是“当前最重要的风险边界是否已经可靠”。

一个没有 Memory、没有 Multi-Agent，但拥有正确 Run、Policy、Verification、Trace 和 Sandbox 的高风险 Ops Agent，可能比“功能齐全”的 Demo 更成熟。

结论六：平台拥有 Guarantee（系统保证），Domain 拥有 Meaning（业务含义）。

平台统一稳定 Contract、Identity、Runtime、Execution、Trace、Eval 等共性保证；业务团队继续拥有 Domain Context、Tool、Invariant 和 Verification Criteria。

结论七：Multi-Agent、Memory、Protocol 都不是默认升级项。

它们分别只有在：

Multi-Agent
→ 拆分净收益为正

Memory / Skill
→ 长期复用收益超过治理成本

Protocol
→ 独立系统 / 团队 / Vendor 的互操作收益超过标准化成本

时才值得平台化。

11.2 一个统一的架构决策公式 ​

后续每个专题都可以用同一个思路：

Architecture Value（架构价值）
≈
Failure Reduction（失败减少）
+ Risk Reduction（风险降低）
+ Reuse Benefit（复用收益）
+ Evolution Flexibility（演进灵活性）
-
Operational Complexity（运营复杂度）
-
Coordination Cost（协调成本）
-
Migration Cost（迁移成本）

不是为了精确计算，而是强迫架构讨论回到真实收益和真实代价。

11.3 架构评审和面试追问怎样讲完整 ​

高级架构表达不是在短时间内说出更多名词，而是能够根据追问深度逐层展开同一个决策。

30 秒
→ 说清问题、核心判断和责任边界

3 分钟
→ 说清输入、处理、输出、责任主体和关键契约

深度追问
→ 说清备选方案、未采用原因、失败路径、复杂度转移、指标和回滚

例如回答“什么时候建设 Durable Runtime”，不应从某个 Workflow Engine 的功能开始。应该先说明触发条件是任务开始跨请求、跨进程或长时间等待，再解释 Checkpoint、Resume、Idempotency 和 Version Boundary，最后说明为什么短任务可能不值得承担这组复杂度。这种表达方式同时适用于架构评审、技术方案和外部面试。

十二、全系列怎样保持跨篇不变量 ​

12.1 九条跨篇架构不变量 ​

Invariant 1：State ≠ Knowledge ≠ Memory ≠ Skill ≠ Context

State（状态）
→ 当前系统 / Run 的真实运行事实

Knowledge（知识）
→ 来自企业权威源、外部世界或领域系统的可验证事实与语义

Memory（记忆）
→ 从过去 Run / Interaction 中筛选出来、值得影响未来任务的经验信息

Skill（技能）
→ 可复用、可执行、可验证的程序性知识

Context（上下文）
→ 当前这一轮模型真正被允许、被选择看到的信息投影

因此：

State / Knowledge / Memory / Skill
        ↓
Context Engineering
        ↓
Model-visible Context

Context 可以引用前四者，但不拥有它们的生命周期。Knowledge 也不能因为被检索进 Context 就变成 Memory，Memory 更不能覆盖企业 Source of Truth（权威事实来源）。

Invariant 2：Action Proposal ≠ Real-world Effect

模型提出动作，不代表现实动作已经发生。真实动作必须经过：

Policy / Identity
→ Execution
→ Evidence
→ Verification

Invariant 3：Harness ≠ Runtime ≠ Execution

Harness
→ Agent 怎样工作、能做什么

Runtime
→ Run 怎样跨时间和故障可靠活着

Execution
→ Action 在哪里、以什么边界真实发生

Invariant 4：Verification ≠ Evaluation

Verification
→ 单次 Run / Action 是否真的完成

Evaluation
→ 某个版本在任务分布上是否真的更好

Invariant 5：Multi-Agent 不是成熟度等级

只有：

Multi-Agent Net Benefit > 0

即 Context / Permission / Parallelism / Specialization / Failure Isolation 的收益，大于 Coordination / Duplication / Merge / Runtime Cost，才值得拆。

Invariant 6：Learning ≠ Automatic Self-modification

企业级持续学习应该是：

Run / Feedback
→ Candidate
→ Eval / Review
→ Versioned Release
→ Canary（金丝雀灰度）/ Rollback（回滚）

本质是 Memory / Skill Governance（记忆 / 技能治理）+ Release Governance（发布治理），而不是让 Agent 自动修改权威企业 Knowledge 或模型权重。

Invariant 7：Protocol ≠ Integration

协议只解决稳定互操作契约。完整 Integration 仍然需要：

Identity
Authorization
Domain Contract
Version
Retry
Artifact
Trace
Ownership

标准化不会消灭复杂度，只会把复杂度从点对点 Adapter（适配器）转移到 Registry（注册中心）、IAM（身份与访问管理）、Compatibility（兼容性）、Gateway（网关）和 Federation（联邦协作）。

Invariant 8：Platform owns Guarantees；Domain owns Meaning

Platform（平台）应该拥有：

Stable Contract
Runtime Guarantee
Execution Boundary
Identity / Policy
Trace / Eval Infrastructure
Version / Rollback

Domain（领域）应该拥有：

Business Meaning
Domain Context
Domain Tool
Business Invariant
Verification Criteria
Domain Skill

平台不能把高变化业务语义吞进 Shared Core。

Invariant 9：Capability Registry ≠ Model-visible Tools ≠ Authorized Execution

企业平台可以注册成百上千种能力，但当前 Run 的模型只应该看到与任务、阶段和身份相关的一个小投影：

Enterprise Capability Registry
→ Search / Namespace
→ Visibility Filter
→ Model-visible Tool Set
→ Authorization / Approval
→ Execution

所以：

• Tool 越多，不应该越多地全量塞进 Context；
• Tool Search 解决“该发现什么”，Policy 解决“能不能看 / 能不能做”；
• Tool Schema 是模型动作空间的一部分，也是 Context Budget 和 Security Surface；
• Tool Eval 要同时评估发现、选择、参数、调用结果和不必要调用。

能力拥有权、模型可见权和真实执行权必须分开。

12.2 全系列统一架构决策闭环 ​

后续无论评审 Harness、Runtime、Memory、Multi-Agent 还是 Platform，都统一使用：

Problem / Failure
↓
Trigger
↓
Decision
↓
Transferred Complexity
↓
Trade-off
↓
Evidence / Metric
↓
Review / Rollback

其中 Trigger 统一分成：

Failure
Scale
Risk
Reuse
Governance

这条链比“用了什么框架 / Feature”更接近真正的企业架构决策。

12.3 跨篇不变量怎样约束后续演进 ​

跨篇更新至少要同时保持：

术语一致性
职责边界
架构演进逻辑
复杂度转移方向
升级触发条件
企业决策格式

局部实现和产品事实可以变化，但不应因为某个 Framework / Provider 的新 Feature，就轻易推翻 State / Context / Memory、Harness / Runtime / Execution、Verification / Evaluation 等稳定边界。

本篇总纲的职责因此进一步明确：

《企业级 Agent 架构全景》负责给出整个体系的第一性主线和稳定不变量；各机制专题负责逐层深挖；《企业级 Agent 平台参考架构》负责企业平台总装与投资、组织决策。

附录：专题导航 ​

1. 《Agent Loop 与 Harness 架构》
2. 《Agent 上下文工程》
3. 《Agent 知识检索与治理架构》
4. 《Agent 记忆、技能与持续学习》
5. 《Agent Runtime 与持久执行》
6. 《Agent 安全执行与结果验证》
7. 《Multi-Agent 与工作流编排》
8. 《Agent 跨系统交互与集成治理》
9. 《企业级 Agent 平台参考架构》

参考资料与当前行业核验 ​

本总纲的行业对照只用于验证架构抽象，不以产品功能数量作为优劣排名。代表实现优先选择官方文档、官方代码仓库和公开工程文章；详细机制与更多来源在后续各专题中继续展开。

• OpenAI Agents / Agents API：Harness、Sessions、Tools、Handoffs、Tracing、Sandbox / Execution。
• Anthropic Claude Code / Agent Skills：Coding Agent 工作闭环与 Progressive Disclosure。
• Microsoft Agent Framework：Agent / Workflow、Context、Execution、Operations & Trust。
• Google ADK / Agents CLI：Agent 编排与 Build → Eval → Deploy 生命周期。
• AWS AgentCore：Runtime、Identity、Gateway、Browser、Code Interpreter、Observability、Evaluation。
• LangGraph / LangSmith：State / Durable Workflow 与 Observability / Evaluation 分层。
• OpenHands / Pi / mini-SWE-agent / DeepSeek Harness：不同 Harness / Execution / Extension 路线。
• Temporal / Restate / DBOS：Durable Execution 的非 Agent 专用基础机制。
• Letta / Mem0 / Zep / Graphiti：不同长期 Memory 路线。
• Snowflake Cortex / Databricks Genie：Domain Agent 中语义、数据治理和业务验证的重要性。

[^openai-agents-api]: OpenAI — Introducing the Agents API, 2026-09-10. https://openai.com/index/introducing-the-agents-api/ [^ms-agent-capabilities]: Microsoft Agent Framework — Agent capabilities. https://learn.microsoft.com/en-us/agent-framework/agents/ [^aws-agentcore-obs]: AWS — Amazon Bedrock AgentCore Observability. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html [^aws-agentcore-eval]: AWS — Amazon Bedrock AgentCore Evaluations. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html [^google-agents-cli]: Google Agents CLI — Development Guide / Skills Reference. https://google.github.io/agents-cli/guide/development/ ; https://google.github.io/agents-cli/reference/skills/