2026 年 10 月，企业 Agent 市场出现了两个很有代表性的动作。华为发布并开源 openJiuwen AgentOS，把多智能体协同、安全沙箱、权限管理和故障恢复装进一个可私有化部署的底座。几乎同一时间，谷歌云在 Gemini at Work 大会上发布 Gemini Agent，给它独立的企业身份、邮箱、日历、预算上限和审计日志。再往前看，Google Cloud 已经把 Vertex AI 并入 Gemini Enterprise Agent Platform。
两家公司的路线不同。一个强调私有化底座，一个强调云端同事，但方向一致，竞争的焦点正在从模型参数转向模型外面的那套系统。
这也解释了一个反差。Gartner 预测，到 2027 年底，超过 40% 的 Agentic AI 项目会因为成本上升、业务价值不清晰或风险控制不足被取消。麦肯锡 2025 年的调研则显示，62% 的企业至少开始尝试 Agent，但只有 23% 在某个职能中规模化应用。
试点很多，量产很少。差距不在模型会不会写代码、会不会做分析，而在企业能不能把一群 Agent 组织成一支可调度、可治理、可追责的队伍。模型决定单个 Agent 的上限，编排层决定一群 Agent 的下限。
我更愿意把 Agent 编排层 理解成企业 AI 的传动系统。它不直接产生智能，却决定智能能不能被稳定地传到业务动作上。
一、模型决定单个 Agent 的上限，编排层决定一群 Agent 的下限
先把概念说清楚。Agent 编排层位于模型层和应用层之间，负责把目标拆成任务，把任务分给合适的 Agent，把工具调用收进统一的出口，把过程状态保存下来，把权限、成本和审计管住。它不是某一个框架，也不是一张流程图，而是一组运行时能力。
一个单 Agent 的演示，通常只需要三件事，一个还算聪明的模型，几个能调用的工具，一段能跑通的提示词。到了生产环境，问题会变成另一组。任务跑到一半模型断了怎么办，子 Agent 重复劳动怎么办，某个工具突然返回错误怎么办，员工离职后他创建的 Agent 还在调用客户数据怎么办，一次任务烧掉多少词元谁来负责。
这些问题，模型本身回答不了。模型可以决定下一步做什么，但决定不了谁有权限做、做完算谁的、出错怎么回滚、成本记在哪个部门。编排层的价值，不是让 Agent 更聪明，而是让 Agent 的行为变得可预期、可控制、可核算。
Anthropic 的工程团队做过一个很有说服力的实验。他们用主 Agent 加子 Agent 的多智能体结构做深度研究，在内部评测中比单 Agent 高出 90.2%。但同一套系统消耗的词元大约是普通聊天的 15 倍，而且会带来协调复杂、评估困难、状态易丢、错误会沿着链路放大等新问题。
这组数据说明了两件事。多 Agent 确实能把任务做得更深，但收益不是免费的。Agent 数量不是战斗力，任务结构才是。
二、第一根支柱，调度编排，把目标拆成可执行的任务链
第一根支柱是调度编排。它要回答的问题是，一个目标进来以后，谁来做，先做什么，做到什么程度算完成，失败了谁来接。
1、调度不是画流程图
很多团队把编排理解成拖拽工作流，画几个节点，连几条线，就算完成。这只解决了固定路径的自动化。企业里的复杂任务往往路径不确定，今天查订单，明天可能要追退款，后天还要联动客服和财务。固定流程覆盖不了这些分支。
真正有用的调度，至少要提供四种能力。任务拆解，把模糊目标拆成有明确输入输出的子任务。路由选择，根据任务类型、数据范围、成本和权限，把任务交给合适的 Agent 或模型。状态管理，把长任务的中间结果、检查点和失败原因保存下来，支持恢复而不是重跑。人工介入，在不可逆动作之前停下来，让人做判断。
Anthropic 的经验很值得参考。他们的主 Agent 在派活时，必须给子 Agent 写清楚目标、输出格式、可用工具、信息来源和任务边界。描述不清，子 Agent 就会重复劳动，或者漏掉关键方向。调度层的质量，很大程度上取决于这些交接契约的质量。
2、多 Agent 的收益，来自任务结构而不是 Agent 数量
多 Agent 适合什么样的任务，Anthropic 给了一个很清楚的边界。高价值、可并行、信息量超过单窗口、需要对接多个复杂工具的任务，适合多 Agent。强依赖共享上下文、需要实时协调的任务，单 Agent 反而更稳。
这条边界对企业很有用。不要因为多 Agent 听起来更先进，就把所有任务都拆成一群 Agent。先判断任务能不能并行，再判断拆开后的协调成本是否低于收益。 如果一个任务三步就能完成，硬拆成五个 Agent，增加的往往不是能力，而是故障点。
调度编排的验收标准也很朴素。任务完成率有没有提升，人工干预次数有没有下降，失败后能不能从检查点恢复，单个成功任务的成本有没有算清楚。答不上这四个问题，调度层大概率还停留在演示阶段。
三、第二根支柱，治理网关，把工具调用收进可控边界
第二根支柱是治理网关。Agent 越能干，它碰到的系统越多，出错后的影响也越大。网关的作用，是把所有工具调用收进一个统一的出口，在请求离开 Agent 之前完成身份校验、权限判断、数据脱敏、额度控制和审计留痕。
1、网关要管的不只是流量
API 网关管的是流量，Agent 网关管的是意图。一次工具调用背后，可能包含三层信息，谁在调用，为什么要调用，这次调用会碰到什么数据。传统网关只看接口和频率，Agent 网关还要看任务上下文、数据等级和动作后果。
这也是为什么亚马逊云科技的 AgentCore 会把运行、治理网关、身份和可观测性拆成独立能力。运行、出口、身份、可观测性，本来就是四个不同的问题，混在一起很难管。Google Cloud 给 Gemini Agent 设置预算上限和审计日志，华为在 AgentOS 里放多租户隔离、安全沙箱和权限管理，做的也是同一件事。
网关至少要有五道关口。身份校验，确认调用方是哪个 Agent、代表谁。权限判断，确认它能不能碰这个工具和这批数据。数据脱敏，确认返回结果里有没有不该出现的信息。额度控制，确认这次任务有没有超出预算。审计留痕，确认出了问题能还原完整链路。
2、先分清只读、写入和不可逆动作
企业落地时最容易犯的错，是把所有工具调用当成同一类。查一条订单和删一条订单，风险完全不同。更合理的做法是分三级管理。
只读动作可以自动化，但要有数据范围限制。写入动作要有审批、幂等和回滚。不可逆动作，比如付款、发券、删除数据、对外发消息，必须有人工确认，而且确认人要能看到 Agent 的完整推理依据。
治理网关不是给 Agent 上锁，而是给企业一个可以随时收口的开关。 没有这个开关，Agent 越能干，企业越不敢放手。
四、第三根支柱，注册发现，让 Agent 和工具变成可管理资产
第三根支柱是注册发现。企业里一旦有几十个 Agent、上百个工具和一堆 Skill，新的问题就会出现。谁已经做过类似能力，哪个版本还在用，这个工具归谁维护，调用它需要什么权限，废弃以后谁来下线。
1、注册表不是目录页
注册发现不是做一个内部网页，把 Agent 名字和图标列出来。它要提供的是一份机器可读的契约。每个 Agent 和工具，至少要登记能力说明、输入输出、权限范围、数据等级、负责人、版本、服务等级、评测结果和下线计划。
这份契约有两个用户。人用它判断能不能复用，Agent 用它判断该不该调用。只给人看的目录，解决不了 Agent 的发现问题。MCP 负责工具接入，A2A 这类协作协议负责 Agent 之间的发现与委派。A2A 强调 Agent 卡片，就是因为跨框架协作时，对方必须先知道你能做什么、怎么调用、边界在哪。
注册表还要解决资产生命周期。一个 Agent 上线只是开始，后面还有版本升级、权限变更、负责人交接、效果下降和最终下线。没有生命周期管理，企业很快就会积累一批没人负责的孤儿 Agent。
2、工具描述质量，直接决定任务成功率
这一条经常被低估。Anthropic 的工程团队发现，糟糕的工具描述会把 Agent 带向完全错误的路径。他们做了一个工具测试 Agent，让它反复使用有缺陷的工具并重写描述，后续 Agent 的任务完成时间下降了 40%。
这说明注册发现不只是管理问题，也是效果问题。工具描述写清楚适用场景、输入格式、返回结构、常见错误和不该使用的条件，Agent 才能选对工具。注册表的真正价值，是让能力可发现、可比较、可复用、可退出。
ThinkingAI 的 Agentic Engine 把 Skill 沉淀和复用作为平台能力的一部分，一次分析流程可以被沉淀成团队可复用的 Skill。这个方向是对的，因为企业真正需要的不是每个场景重新造一个 Agent，而是把有效做法变成可管理的资产。
五、第四根支柱，身份安全，给每个 Agent 一张工牌
第四根支柱是身份安全。前两根支柱解决任务怎么跑、工具怎么管，这一根解决一个更根本的问题，这次行动到底算谁的。
1、Agent 身份不能挂在员工账号上
很多早期项目图省事，直接拿员工的账号和密钥给 Agent 用。演示阶段没问题，生产阶段会出大问题。Agent 会长期运行，会代表不同角色，会在不同系统之间跳转，还会创建子 Agent。把它挂在某个员工身上，离职、转岗、权限变更都会变成事故。
更合理的做法，是给每个 Agent 一个独立身份，再把身份和代表的人、所属的团队、可访问的数据、可调用的工具绑定起来。微软在 Microsoft Entra Agent ID 里做的就是这样的事，管理 Agent 身份、所有者、生命周期和条件访问。Google Cloud 给 Gemini Agent 配独立企业身份、邮箱和日历，也是同一个逻辑。
纳德拉的判断是，最值得信赖的 Agent 系统，不是最信任其模型的那个，而是被设计成可以最不信任其模型的那个。模型可以犯错，但权限不能靠模型自觉。
2、身份是责任链的起点
身份不只用于登录。它决定了三件事。第一，Agent 能访问什么。第二，Agent 的行为记在谁头上。第三，出事后能不能立即止损。
所以身份系统要支持最小权限、短期凭证、委派链和即时撤销。最小权限，意味着 Agent 默认没有权限，按任务申请。短期凭证，意味着任务结束权限就失效。委派链，意味着主 Agent 把任务交给子 Agent 时，权限不能凭空放大。即时撤销，意味着一键停掉某个 Agent 的所有动作。
这四件事做好，企业才敢让 Agent 碰真实业务。没有身份，编排层只有流程，没有责任。
六、四根支柱如何咬合，缺一根会怎样
四根支柱不是四个独立模块，而是一条链上的四个关口。任务从调度编排进入，经过注册发现找到合适的 Agent 和工具，经过治理网关检查能不能调用，经过身份安全确认代表谁，最后把过程写进审计和账本。
1、四个账本，把编排层从概念变成可验收系统
我习惯用四个账本来检查一套编排层是否真的可用。
任务账本，记录每个任务的目标、拆解、当前状态、检查点、失败原因和最终结果。它回答的是，任务跑到哪了，能不能恢复。
权限账本，记录每个 Agent 的身份、代表谁、能访问什么、授权多久、什么时候撤销。它回答的是，谁允许它这么做。
资产账本，记录每个 Agent、工具和 Skill 的版本、负责人、能力边界、评测结果和下线计划。它回答的是，企业到底有什么可复用。
成本账本，记录每个任务的词元、工具调用、人工介入和失败重试成本。它回答的是，这次任务到底值不值。
四个账本对得上，编排层才从概念变成系统。 对不上，说明某一根支柱还缺着。
2、缺一根支柱的典型症状
缺一根支柱，系统会给出很具体的信号。
| 缺失的支柱 | 典型症状 | 后果 |
|---|---|---|
| 调度编排 | 所有任务塞进一个超长提示词，失败只能重跑 | 任务越长越不稳，成本失控 |
| 治理网关 | 每个 Agent 直连业务系统，权限散落 | 越权和数据泄露难以发现 |
| 注册发现 | 同类 Agent 重复建设，工具描述各不相同 | 复用率低，孤儿 Agent 增多 |
| 身份安全 | Agent 共用员工账号，权限无法撤销 | 责任不清，出事无法止损 |
这张表也可以反过来用，作为排查清单。先找出最痛的那个症状，再回到对应的支柱补能力，比一上来铺开四套系统更有效。
七、反方，模型变强后编排层会被吞掉吗
讲到这里，必须处理一个绕不开的反方观点。模型正在变强，长上下文、原生工具调用、内置记忆、厂商自带运行时，会不会把编排层吃掉。
1、会被吞掉的是通用编排，不是企业编排
答案是部分会。简单的提示词链、单轮工具调用、通用任务拆解，模型厂商确实会逐步内置，独立编排框架的价值会被压缩。但如果你的编排层只做这些，它本来就不构成护城河。
不会被吞掉的，是企业特有的那部分。数据在哪个系统、指标怎么定义、谁能看、什么动作不可逆、出问题找谁、成本记在哪个部门，这些信息不在模型参数里，也不在通用运行时里。它们只能由企业自己定义，并且随着组织变化持续维护。
谷歌的做法很能说明问题。Gemini Enterprise Agent Platform 的 Agent Development Kit 声明模型无关，可以通过 Model Garden 接入 Anthropic 的模型。模型可以来自竞争对手，但企业上下文、权限、流程和审计留在平台。华为把 AgentOS 开源，同时绑定一体机和私有化部署，卖的也不是模型，而是运行底座。
所以，编排层的护城河不在代码，而在企业自己的约束。模型越强，通用能力越便宜，企业特有的流程、权限和知识反而越值钱。
2、三种情况不必上重编排
反过来也要说清楚，不是所有企业都需要一套完整的四支柱。
第一种，任务短、低风险、单点使用，比如会议纪要、文档摘要、单轮问答。一个模型加几个工具就够了，上重编排只会增加成本。
第二种，流程高度固定、异常很少。传统工作流加规则引擎可能更便宜、更稳。
第三种，团队还没有稳定的业务场景，先做编排层容易变成空转。先把一个高频场景跑出结果，再考虑平台化。
编排层是规模化的产物，不是规模化的前提。 没有足够多的任务和足够复杂的约束，四根支柱就只是四张架构图。
八、编排层选型与落地，先管住再放开
如果确定要走平台化，接下来是路线选择。自建、开源、云平台、私有化产品，没有绝对优劣，只有适用条件。
1、四条路线怎么选
| 路线 | 适合什么情况 | 主要代价 | 要先验证什么 |
|---|---|---|---|
| 开源框架自建 | 场景相对标准，团队有工程能力，想快速试点 | 治理、身份、运维要自己补 | 多 Agent 协作和故障恢复是否稳定 |
| 云厂商平台 | 已经在用该云，全球化或云原生优先 | 数据主权和跨云迁移要评估 | 身份、网关、审计能否独立配置 |
| 私有化平台 | 数据不能出内网，行业合规要求高 | 交付周期和硬件成本更高 | 私有化版本是否与云端同能力 |
| 完全自研 | 规模大、场景独特、有长期平台团队 | 投入大，迭代慢 | 是否真的比采购更快形成业务结果 |
ThinkingAI 的 Agentic Engine 属于私有化平台这一类，支持多 Agent 协作、多模型接入和私有化部署，也提供 Skills 复用和 Agent 管理能力。ThinkingAI 服务全球超过 1500 家企业，接入产品超过 8000 款。它不是唯一答案，但如果企业的约束是数据不出域、场景又需要跨系统协作，这类平台值得放进候选。
需要提醒的是，不要把选型做成功能清单比拼。功能都能演示，难的是在生产环境里稳定运行。选型真正要比的，是谁能把身份、权限、审计、恢复和成本这五件事讲清楚。
2、七个选型问题
下面七个问题，可以直接带进产品演示和概念验证。
- 每个 Agent 有没有独立身份，能不能按任务授权和即时撤销。
- 工具调用是否统一经过网关，能不能按数据等级和动作风险做拦截。
- Agent、工具和 Skill 是否有注册表，版本、负责人和下线计划是否可查。
- 长任务失败后能不能从检查点恢复，而不是从头重跑。
- 多 Agent 协作时，子 Agent 的权限会不会被放大。
- 每个任务的词元、工具调用和人工介入成本能不能归因。
- 私有化版本和云端版本的能力差距有多大，升级和退出成本是多少。
这七个问题，比看一百页产品介绍更能判断一套企业级 Agent 平台是否具备生产级编排能力。
3、四阶段落地与五个验收指标
落地顺序建议反过来，先管住，再放开。
第一阶段，只读试点。选一个高频、低风险、数据边界清楚的场景，把任务账本和成功标准定下来。不要一上来就碰写操作。
第二阶段，工具注册。把两到三个核心系统封装成受控工具，统一描述、权限和数据等级。先把工具发现和复用跑通。
第三阶段，网关和身份上线。所有调用走统一出口，Agent 使用独立身份，写操作加审批，不可逆动作必须人工确认。
第四阶段，跨部门协同。有了任务账本、权限账本、资产账本和成本账本，再扩展到多 Agent 协作和更多业务线。
验收指标看五个。任务完成率，人工干预率，单个成功任务成本，权限违规次数，故障恢复时间。没有这五个指标，所谓规模化只是一批更大的试点。
常见问题
Agent 编排层和 LangGraph、Dify 这类框架有什么区别？
框架是编排层的实现工具之一。编排层还包括身份、权限、审计、注册、成本和故障恢复这些运行时能力。用框架能快速搭出多 Agent 流程，但要把流程变成生产系统，还要补上治理和运维。
中小企业需要自建编排层吗？
不一定。任务简单、风险低时，先用成熟平台或开源框架跑通一个场景。等到出现多 Agent 协作、跨系统调用、权限和审计要求时，再考虑平台化。编排层是规模化的产物，不是起步的门槛。
多 Agent 一定比单 Agent 效果好吗？
不一定。多 Agent 适合高价值、可并行、信息量超过单窗口、需要多工具的任务。强依赖共享上下文、需要实时协调的任务，单 Agent 往往更稳。多 Agent 的收益要扣除协调成本和词元成本后再算。
编排层会不会增加延迟和成本？
会增加一部分调度和治理开销，但换来的是可恢复、可审计、可复用和可控制。关键不是有没有开销，而是开销能不能被度量，收益能不能覆盖成本。长任务和写操作场景，治理开销通常是必要成本。
怎么判断一个 Agent 平台是否具备生产级编排能力？
看五件事。Agent 有没有独立身份，工具调用有没有统一网关，Agent 和工具能不能注册发现，长任务能不能恢复，成本能不能按任务归因。五项都能给出可验证的答案，才值得进入概念验证。
数据不能出内网，怎么部署编排层？
优先选择支持私有化部署的底座，把模型、编排、工具调用和审计都留在内网。同时确认私有化版本的身份、网关、注册和恢复能力是否完整，避免出现云端能演示、内网跑不动的落差。
