治理与进化，如何成为企业级 Agent 的两条生死线？

AI 降本增效的故事，在 B 端的进展，似乎比预想的要更慢一些。

就在一周前，深度拥抱 AI 多年的福特汽车承认，过去三年，由于人工智能系统不够完善、频频在车辆质量检测上掉链子，福特已经雇佣、晋升或重新召回了超过 350 名 经验丰富的工程师。

几乎同一时间，给出 70% 的企业将在 2026 年底在生产环境运行 AI Agents 预测的 Gartner，也在最新的 AI 报告中写下：到 2027 年，因为人工智能裁掉客服的公司，有一半需要重新招人。

市场决策的反复横跳背后是大模型与企业级应用之间难以磨灭的根本悖论：大模型的智慧涌现能力与幻觉是一体两面；但企业级应用需要绝对的确定性。

其中，福特式失控的根本在于汽车行业安全标准与司乘性命直接挂钩，而 Agent 行为不可观测、权限不可控、责任不可追溯的治理缺位，会直接影响品牌用百年时间塑造起的安全形象。

Gartner 式反复的根本，则是在于技术不断变化，需求也在持续调整，把 Agent 放进生产环境只是开始，它能不能在真实业务中持续被观测、被评估、被优化，才决定了企业能否真正吃到 AI 红利，并将 Agent 战略持续下去。

相应的，如何在 infra 层面同时解决「治理」与「进化」这两组矛盾，就成了当下行业最重要的命题。

让我们先把目光投向更宏观的行业全貌，当下市面上的各种主流 Agent，不外乎三种模式：

最早爆火的 Manus 代表了行业早期流行的成品黑盒方案。这一时期的产品，平台会统一管控记忆、提示词、知识库、工作流、MCP 等完整能力层，用户仅可通过浏览器交互界面进行操作。这种厚重完整的能力栈架构，本质上是用多层配套体系来弥补早期模型泛化能力不足、上下文腐烂、技术债累积等问题。

今年后来者居上的 OpenClaw 选择了一条不同的路——它将能力层拆解为 agent.md、soul.md、User.md 等文本协议，搭配心跳、技能、会话管理模块，交由可以用户自主配置调试。并通过交互兼容浏览器与各类办公 IM 工具，把多模块工程复杂度简化为文本配置复杂度，以轻量化约束机制来发挥模型自身能力。

而最近爆火的 Claude 托管 Agent，则将能力层进一步精简为环境、会话、事件三大模块。它不再单独设置记忆、知识库与工作流，相关能力下沉至模型内部，由厂商根据需求定制搭建——同样支持多端交互。

随着时间的推移与技术的进步，位于中间层的 Agent 编排正变得越来越轻量化。

相应的，在后端的基础设施层，从前规律可预测的流量，人类为主导的登录交互模式，对长期稳定资源的需求，彻底成为过去式。云服务也需要从过去的卖资源、卖流量，进化成为一朵专门 Agent 时代打造的Agent Native Cloud。

那么，如何理解 Agent Native Cloud 的概念？

以阿里云为例，这是一个与早期提出的「AI Native Cloud」相对的概念。AI Native Cloud 服务的是大模型厂商的训练与推理；Agent Native Cloud 则向前再走一步，针对 Agent 的短生命周期、无规律突发负载、动态环境依赖、任务级安全管控、大规模动态编排、复杂数据模态六大特性，分别用运行时、编排与治理、安全、记忆、数据平面六大能力来进行应对。

具体到Agent 编排与治理上，阿里云智能集团云原生应用平台负责人周琦分享：

过去，企业会按销售、运营等业务部门拆分为销售、订单、运营的独立微服务，客户需求流转依靠各微服务互相调用协作完成闭环。这一时期，治理上，需要完成标准化、确定性的 API 接口做流量、稳定性、权限与运行态治理，解决结构化、固定规则下的服务管控问题。

但步入 Agent 时代后，原有微服务体系完成智能化升级，服务间的交互逻辑转化为 Agent 与 Agent 之间协同通信。传统静态 API 接口也被 AI 智能体赋能，从确定性调用升级为具备自主理解、自主编排、动态执行的智能能力入口，治理对象也从微服务接口升级为动态运行的 AI Agent。

要理解 AgentTeams，就需要先思考清楚一件事，Agent 从 C 端走向 B 端，到底什么变了？

周琦分享了一个有意思的观察：To C 场景的 Agent 使用，更多偏向于个人创造与娱乐（没有统一的衡量指标）；但是在 B 端，企业需要追求 ROI，稳定性、成本、性能、可靠性等一系列指标。

他举了个简单例子，一个客服 Agent 的 demo，使用 AI coding 挂载一些简单工具，可能几个小时就能搭建完成。

但是要将它在生产环境中，我们需要把它接入 CIM 系统来读取更多的上下文，那些为人设计的 OA 系统，要如何将 Agent 纳入闭环？人又要如何与 Agent 协同？

更进一步，我们还需要在一次事件处理结束后，让 Agent 能够主动学习交互中人提供的经验，并以更高维度去观察整个客服交互过程中，agent 的行为是否可以被观察、token 的消耗是否合理……

在这一背景下，企业的需求，早就从能这个系统能不能跑，变成了如何设计权限管控、安全兜底机制，让我们能够更加信任的把任务交给 Agent。

这还仅是单 Agent 落地企业场景面临的顾虑，从完整的企业视角出发来看，面临的问题还要更加复杂。

以小型创业公司为例，他们的团队往往分布在不同城市，合伙人、远程员工、外包开发者各自在本地环境中使用 AI 编码工具。

于是就会出现，不同 Agent 各自为政，云端与本地 Agent 割裂。那么这些 Agent 之间如何通信？由谁来协调它们的分工？当某个 Agent 的执行结果出现问题时，如何追溯问题的根源？开发者本地 Agent 的 prompt、工具链、上下文知识都是独立维护的，如何让组织内的更多人能够复用、协同。

最重要的是，Agent 直持凭证带来的安全风险。大多数 Agent 在执行任务时需要访问企业的各种系统和数据。如何保证这些 Agent 不会在未经授权的情况下泄露敏感信息？如何监控 Token 消耗、控制成本？

基于以上行业洞察，以及团队多年积累下的微服务分域、分工协作的成熟治理思路，AgentTeams 诞生了。

周琦介绍，AgentTeams 可以理解为是面向企业的多智能体治理与协作平台，支持企业在统一的控制台中创建和管理 AI Worker。

打个通俗的比方，过去一个 Agent 是一名单兵作战的"AI 员工"，而聚集起多个 Agent 的 AgentTeams 就是把这些员工组织起来干活的"公司的规章制度与运行规范"。它要解决的核心问题是——这群 AI 员工在协作过程中，权限怎么分、任务怎么派、凭证怎么管、出了事谁来兜底，才让企业放心地把活儿交给它们，发挥出 1+1+1 大于 3 的效果。

它首先解决的是，企业最关心的安全问题。能力上，平台可无缝对接企业 idP 体系并安全托管各类凭证，让 Agent 无需明文存储密钥、仅按需临时获取权限；所有工具与 MCP 调用都会经过平台统一拦截校验，依据预设访问策略动态放行；配套沙箱运行环境实现资源、网络、存储三层强隔离，可以保障各智能体运行互不干扰；同时集中纳管企业模型、MCP 服务、Skill、Agent 模板等核心 AI 资产，提供统一鉴权与安全审核能力，实现 AI 资产 BYOC 自主可控。

权限设计上，AgentTeams 则设计了用户和 Agent 角色，用户分为 Admin 和普通用户，每个普通用户可以独立配置是否可以使用 TeamLeader Agent 和哪些 Workers 的权限，用于保证人与 AI 协同中的精细权限管控。

更进一步，AgentTeams 还同时集成钉钉、飞书、企业微信等企业主流 IM 工具。员工在熟悉的聊天窗口即可发起任务、实时监督、审批干预，Agent 执行结果回传 IM。

当一个项目负责人需要让 Agent 完成一些复杂任务时，他可以通过一个 Leader Agent 拆解研发任务，将不同的子任务分派给最合适的 Agent 执行，各 Agent 完成各自的任务后，结果汇总到 Leader，由 Leader 进行整合和质量把控，最终直接在 IM 中，像个普通同事一样，直接交付完整的成果，实现人在回路的高效协作编排。

AgentTeams 客户端

知识沉淀方面， AgentTeams 提供了独立的 AI Registry 注册中心，可以统一管理组织的 Skills、MCP Servers、Agents、Team Templates，形成跨聊天、跨个体、跨部门的复用，并支持版本管理、安全审查、热加载。

对照组织管理学的基础理论，AgentTeams 已经解决了组织的边界以及具体管理流程问题；那么，层层约束之下，组织又该如何不断进化？

当个体聚集成企业，就需要建立组织部或者人力资源部，去建立选拔考评制度，决定群体的资源管理分配标准，才能让有限的资源不断发挥出更大的效益。

Agent 组织成 AgentTeams 后，同样需要一个组织部扛起监察与优化的责任。

在阿里云的Agent Native Cloud 战略中，承担这个任务的，是 AgentLoop，一个面向企业级智能体的一站式自进化平台，可以提供 Agent 全栈观测与审计、Agent 评估与实验、Agent 资产管理与持续优化等核心能力，来持续优化企业 Agent 的质量、效率、成本与安全性。

但对于它的效果究竟体验如何，在正式推出前，团队一度遇到了非常多的技术挑战。

因为微服务时代，传统应用的输出是确定性的——同样的输入必然产生同样的输出，质量问题容易复现。

但 Agent 的输出天然具有随机性。这次回答得挺好，下次怎么变差了？可能是模型的更换，可能是系统产生了错误的记忆，也可能只是模型的一次随机幻觉，而传统的 APM 工具对此毫无办法。再加上，企业级智能体相比通用智能体，容错空间更小，但由于 Agent 的多步骤执行特性，异常的根源可能隐藏在几十步甚至百步的某个工具调用中，很难定位。

但阿里向来有推出产品前，内部先 dogfooding 的习惯。过去，神龙服务器、盘古存储、云原生架构等核心产品，都是先先承载淘宝、天猫双 11 亿级流量、钉钉爆发式扩容等内部极端业务场景，在真实峰值压力下验证稳定性、优化性能，打磨成熟后再作为云服务对外输出。

AgentLoop 也不例外。团队为它找到的第一个超级场景，就是阿里云内部的实际的产品研发流程。

现如今，借助 AgentLoop，阿里云团队将需求 → Spec → 代码 → Review → 测试 → 发布整个端到端链路上的多个独立智能体，进行执行效果的持续优化，从而提升流水线的自动化，人只在关键决策点介入：需求澄清、PR 合并、生产发布。

在这个过程中，AgentLoop 提供的，是一套生产环境从观测、到分析评估，再到优化的完整链路。

在观测分析层面，AgentLoop 能将原子化的观测指标转化为 Agent 的完整推理轨迹（Trajectory），端到端还原每一步的输入输出、工具调用与执行路径，在此基础上实现 Token 成本归因与全链路智能诊断。

在评估层面，AgentLoop 采用 Agent-as-a-Judge 机制，并提供了 20+在主流业务场景下经过工程实战的开箱即用的评估器 Agent，基于完整推理轨迹进行深度判断。

优化则通过将线上真实数据自动回流为评估数据集，配合 Prompts 和 Skills 等资产，形成持续进化的闭环。过去，阿里云在客户服务 Agent、Coding Agent、Data Agent 等主流场景积累了大量的进化经验，并和企业客户持续共创，如今，这些 FDE 场景下的智能体资产，可以直接反哺到 AgentLoop 的经验库中。

周琦总结，过去阿里云团队在微服务时代就积累了大量治理经验，从流量管控到稳定性保障，底层逻辑是给不确定性建立确定性的兜底机制。如今升级到 Agent 时代，观测对象从确定性的 API 接口变成了非确定性的推理轨迹，难度系数更高，但方法论一脉相承。

也正是借助这样一套架构，AgentLoop 可以把每一次 Agent 运行时产生的日志数据变成自我优化的飞轮，让所有企业都能获得阿里云团队一样的自动化开发维护体验。

为什么 Agent 尚未在企业市场彻底爆发，就需要先为它定好约束与进化规范？

历史其实早就给出了答案。

1880 年代之后，电力正式从实验室走向生产，几乎同一时间，爱迪生为代表的直流电派与特斯拉为代表的交流电派产生了正面对决。

双方你来我往的对战中，特斯拉在后来的芝加哥世界博览会，用十万盏灯泡照亮了整个会场，向全世界证明了交流电无可撼动的地位；爱迪生也一度为了证明交流电的危险性，在公开实验中电死了小猫、小狗乃至一头大象。纽约康尼岛月神公园被铜电极击穿的大象痛苦嘶吼的画面，已然成为当代科技史上足以载入史册的公关事件。

于是，此后十几年里，尽管交流电技术已经成熟，但社会基础设施与约束远远跟不上，很多电线只是用布和沥青随便裹一下，老鼠一咬或者墙壁受潮就会引发火灾，不同发电厂送来的电电压也忽高忽低，频繁烧毁当年还很昂贵的灯泡。导致保险公司不敢承保，居民也始终不敢把电线拉进卧室。

直到 1897 年美国国家消防协会联合各方制定的第一版《国家电气规范》，这套标准严格规定了室内布线的绝缘材质、电流负载上限与接地规范。它没有发明任何新技术，但它解锁了电力的全部潜力。

有了规范，保险公司才敢承保。敢承保，银行才敢贷款。敢贷款，建筑商才敢把电线设计进每一栋新楼。有了这套标准，交流电才真正走向了全球千家万户。

一定程度上，技术能力只决定了一件事能不能做到，而治理与进化体系才决定了它能不能低成本、低风险地复制一万次。

如今的 AI Agent，正站在这个历史拐点上。