Agent落地元年:标准化协议驱动应用爆发,开放世界训练成新突破

Agent迎来工程落地元年,MCP和A2A协议驱动应用爆发,多Agent协作的低效与幻觉是挑战,AI Coding和自动化运维率先落地。

原文标题:效率狂飙数倍后:Coding Agent已然成熟,但开放世界仍是“无人区”

原文作者:AI前线

冷月清谈:

2025年被定义为Agent(智能体)的“工程落地元年”,标志着大模型从被动问答到主动干活的范式转移。MCP协议和A2A协议的发布,以及多智能体协同的工程化实现,是推动Agent应用爆发的关键因素。MCP协议统一了AI模型访问外部工具、数据库和服务的方式,降低了集成成本并提升了可靠性。A2A协议定义了智能体间的“通用语言”和协作规范,使不同背景下的智能体可以标准化地互相协作。尽管Agent应用呈现爆发趋势,但在企业级生产环境中,多Agent协作面临着“低效”与“幻觉”的挑战。现阶段Agent与BPM的关系并非替代,而是融合,Agent作为一个“增强组件”被精心设计和集成到现有生产体系中。AI Coding和自动化运维是目前Agent落地最成熟、收益最可观的领域。未来,Agent将从攻克编程与运维的确定性堡垒,到勇敢迈向充满未知的开放世界训练,Agent的终极形态可能是高度自制的智能体或数字员工。Agent将不再是特定领域的应用,而是一种像数据库、中间件一样的“新兴基础设施”。

怜星夜思:

1、文章提到MCP协议类似于“USB-C接口”,这种比喻你觉得恰当吗?除了文章中提到的,你认为MCP协议还能带来哪些潜在的好处或风险?
2、文章中提到多Agent协作可能导致“无效沟通”和Token消耗激增,你认为有什么方法可以解决这个问题?如果让你来设计一个多Agent协作系统,你会考虑哪些因素?
3、文章提到Agent可能会以“数字员工”的身份在企业中入职,你认为“数字员工”会给职场带来哪些变化?你是否期待与“数字员工”一起工作?

原文内容

图片
作者|冬梅

如果说 2024 年是属于大模型的“奇迹之年”,那么刚刚过去的 2025 年,则可以被定义为 Agent(智能体)的“工程落地元年”。

在技术圈的语境里,大模型正经历从“被动问答”到“主动干活”的范式转移。过去没有 Agent 的时候,大模型是在被动地回答问题;Agent 诞生后,它变成了主动执行。这不仅仅是业务模式的变化,更是从聊天程序到生产组件的根本性变革。

但这种根本性的变革却不是一蹴而就的,而是由多个重要的、里程碑式的“协议”和框架强力驱动的。这一点与早期互联网协议定义推动 Web 应用爆发式增长的逻辑类似——标准化不是为了漂亮的规范,是要真正去解决跨系统、跨场景、跨团队协作的实际工程痛点。

2025 年,两大协议推动了 Agent 应用的爆发

阿里云容器计算服务 ACS Agent Sandbox 技术负责人黄涛在最近的一次深度对谈中将其归结为三个关键事件:MCP 协议的爆火、A2A 协议的发布,以及多智能体协同的工程化实现。

首先是 Anthropic 发布的 MCP(Model Context Protocol,模型上下文协议),旨在定义 AI 模型如何访问外部工具、数据库和服务的标准化方式。与过去每个模型厂商根据自有接口定制不同,MCP 提供了类似 “USB-C 接口” 的统一协议,使得智能体能跨平台访问外部能力。

例如,MCP 能够让智能体通过统一的协议访问数据库、库存系统、工作流 API 等,而不需要针对每种服务和接口写特定的适配代码。 这种标准化的好处,在企业级应用场景中尤为显著:

  • 减少集成成本:应用方不再为大量不同的 API 写 glue code。

  • 提升可靠性与一致性:统一格式、统一调用流程让错漏减少。

  • 加速自动化能力落地:智能体能快速理解系统数据并据此执行任务。

起初,这看起来只是一个单纯的技术协议,但在刚刚过去的一整年,它彻底引爆了应用层。

以阿里集团内部为例,为了加速 AI 在电商领域的渗透,阿里孵化出了名为“TMCP”的电商 MCP 网关平台。大量业务方通过编写 MCP Server,将复杂的供应链、库存数据、用户信息等通过标准化协议“喂”给 Agent。

“MCP 解决的是 Agent 看世界、调工具的‘语言统一’问题。”黄涛解释道。以前 Agent 调用工具需要针对每个接口做定制,现在有了标准网关,Agent 可以更快速地理解客户需求,从一个只会聊天的程序,变成真正能调度阿里复杂业务逻辑的“超级组件”。

此外,另一款协议也值得重点关注。Agent-to-Agent(A2A)是由谷歌发布的,其核心目标是定义智能体间的“通用语言”和协作规范,使不同背景、不同厂商或不同开发框架下的智能体,可以像微服务一样,通过标准化方式互相发现、协商任务、交换状态、协调工作流。

这类似于 Web 发展的历史中 HTTP、REST API 为服务间通信提供标准一样——如果没有可互操作的通讯协议,大规模协作系统无法自然形成。

在过去,不同功能的 Agent 之间想要对话,往往需要开发者编写极其复杂的“粘合代码”。而 A2A 标准的出现,意味着不同背景、不同厂商的 Agent 可以像人类员工一样,通过一套标准的交互准则进行协作。

协议能力上看,MCP 与 A2A 都可以用于描述智能体之间的交互,但二者的设计侧重点存在差异。MCP 更强调通用的调用与连接能力,统一智能体与外部工具、系统乃至其他智能体的交互方式;相比之下,A2A 在设计上更聚焦于多智能体场景本身,试图为智能体之间的协作、状态同步与交互模式提供更直接的抽象支持。因此,在早期多 Agent 系统实践中,即便采用了 MCP 这类通用协议,智能体之间的协调逻辑仍常常依赖开发者手工实现,难以随着系统规模的增长而自然演进。

与此同时,Manus 等框架提出的多智能体协同概念,不仅停留在交互层,更深入到了底层的基座能力。比如安全沙箱(Sandbox)技术的引入,解决了 Agent 在执行代码或处理敏感数据时的隔离问题,让“协作”不再是裸奔。

繁荣背后的工程陷阱:多 Agent 协作的“收敛性”困局

尽管应用层呈现爆发趋势,但当 Agent 真正走进企业级生产环境时,工程性挑战接踵而至。最让开发者头疼的,莫过于多 Agent 协作中的“低效”与“幻觉”。

OpenAI CEO 奥特曼曾描绘过一个超级个体带领一堆 Agent 协作的未来。但在实际操作中,守辰发现了一个尴尬的现实:Agent 之间会产生大量“无效沟通”。

“多个 Agent 协作时,经常会出现不聚焦的情况,聊着聊着就聊开了。”阿里云智能容器服务高级专家, OpenKruise Agents 项目发起人张振举例说,有些框架下,Agent 之间会互相委派任务,甚至出现死循环。这种“社交式发散”直接导致了 Token 消耗的激增,但最终得到的推理效果却可能不如一个定义明确的单 Agent。

这种成本不仅仅是金钱上的,更是算力资源的浪费。对于企业而言,如何量化 Agent 之间的协作模式,识别并固化有效的沟通路径,避免像人类会议一样的“低效扯皮”,是目前的重难点。

另一个挑战在于 Agent 的“自制能力”尚浅。在传统的 BPM(业务流程管理)或 RPA(机器人流程自动化)领域,追求的是强约束、强工程化。

目前的 Agent 虽然有灵性,但离完全自制还有很大差距。黄涛认为,现阶段 Agent 与 BPM 的关系并非“替代”,而是“融合”。“我们要给 Agent 定义清晰的边界和子系统,明确它的输入、输出和约束,而不是把它当作一个泛化的、人格化的机器人。”

在阿里的实践中,开发者尝试在现有的工具流中加入 Agent 节点,让它处理那些“不那么确定”的子任务,而将确定性的逻辑依然留给脚本或流程引擎。

黄涛的这一观点,为 Agent 当前的发展阶段进行了精准锚定。它摒弃了不切实际的科幻幻想,转而拥抱一种务实、可工程化的演进路径:Agent 并非一个从天而降、全知全能的“取代者”,而是一个需要被精心设计和集成到现有生产体系中的“增强组件”

这种“融合”思维,决定了 Agent 价值的兑现方式——它必须深入具体业务的血肉之中,在解决真实痛点、优化既有流程的过程中证明自己。那么,Agent 究竟在哪些场景里产生了真实价值?

业内普遍认为,最先被 Agent 攻陷的堡垒是编程和运维。

AI Coding 是目前 Agent 落地最成熟、收益最可观的领域。黄涛分享了自己的体感:“以前写一段代码需要一个小时,现在 Agent 一分钟生成,我再改个十来分钟,效率提升是巨大的。”

更显著的变化发生在自动化运维。2024 年的运维 AI 更多是基于 RAG 查手册,而 2025 年的 Agent 则学会了“模仿工程师经验”。当系统报错时,Agent 会自动执行一系列命令去定位问题,甚至能感知真实的运行环境并做出反馈。

张振对 2026 年最期待的突破点是“开放世界训练”。随着 Agent 被装进手机(如字节跳动与中兴的合作)或机器人(如宇树机器人),它面临的是未知的、非实验室的环境。一个典型的挑战是:Agent 操作某个 App 时被封禁了,它该怎么办?

“让 AI 知道自己不知道,是走向真智能的关键一步。”张振提到。阿里云正在通过发布像 OpenKruise Agents 这样的基础设施,提供检查点(Checkpoint)和克隆功能,来加速这种在开放世界中的训练效率。值得一提的是,OpenKruise Agents 是阿里云容器计算服务 ACS 的 Agent Sandbox(ACS Agent Sandbox)逐步开源的能力之一。与 OpenKruise Agents 不同,ACS Agent Sandbox 面向企业级 AI Agent 应用规模化落地,内存级休眠唤醒与 checkpoint 克隆能力 ,支持结合云端弹性调度与微虚拟化隔离,以缩短沙箱启动与恢复时间,提升并行探索效率以及降低训练成本。

Agent 的终极形态:超级自动化还是数字员工?

从攻克编程与运维的确定性堡垒,到勇敢迈向充满未知的开放世界训练,Agent 的能力边界正在实践中被不断拓展和重新定义。

这种从“专用工具”到“适应环境”的演进路径,自然引发了更深层次的思考:Agent 进化的终点究竟在何处?是成为无所不能的超级自动化智能,还是先成为我们身边协同工作的可靠伙伴?

关于 Agent 的终极形态,黄涛和张振两位专家给出了略有分歧但互补的视角。

黄涛的视角更偏向“高度自制的智能体”:他认为 Agent 最终会演化成在家庭助理、工厂、无人驾驶等场景中完全自主运行的实体。它能完美感知环境差异,自主决策,彻底解放人类。

而张振的视角则更务实,倾向于“数字员工”:他认为短期内,AI Agent 会以数字员工的身份在企业中入职。“员工”这个角色方便企业进行 KPI 评估,也方便人类与之协作。

尽管愿景不同,但共识已成:Agent 将不再是特定领域的应用,而是一种像数据库、中间件一样的“新兴基础设施”。

这一年,我们经历了对 Agent 能力的盲目崇拜,也正在经历对其工程化落地的痛苦磨合。当 MCP 协议把业务的大门敲开,当沙箱技术把安全的篱笆扎紧,当开放世界训练让 AI 开始学会“思考”,Agent 就不再是 PPT 上的概念,而是真正开始改变生产力逻辑的底层变量。

正如张振所强调的那样,AI 可能无法立即成为那个“超级智能体”,但它会以无数个“数字员工”的身份,渗透进代码的每一行、运维的每一次报警、以及每一个复杂的商业决策中。

这才是 Agent 时代的真实叙事:不在于取代,而在于进化。

采访嘉宾简介:
  • 黄涛 ,阿里云容器计算服务 ACS 技术负责人

  • 张振,阿里云智能容器服务高级专家, OpenKruise Agents 项目发起人

会议推荐

InfoQ 2026 全年会议规划已上线!从 AI Infra 到 Agentic AI,从 AI 工程化到产业落地,从技术前沿到行业应用,全面覆盖 AI 与软件开发核心赛道!集结全球技术先锋,拆解真实生产案例、深挖技术与产业落地痛点,探索前沿领域、聚焦产业赋能,获取实战落地方案与前瞻产业洞察,高效实现技术价值转化。把握行业变革关键节点,抢占 2026 智能升级发展先机!

今日荐文

图片

你也「在看」吗?👇

我觉得数据格式协议也很重要,现在各种数据格式五花八门,Agent 处理起来很麻烦。如果能统一数据格式,Agent 的效率肯定能提高不少。

一想到以后要跟机器人一起上班,就觉得有点恐怖… 不过话说回来,如果“数字员工”能帮我处理那些繁琐的报表和会议记录,那我举双手欢迎!希望“数字员工”能成为真正的“打工人”,而不是只会内卷的“卷王”。最重要的是,希望老板不要因为有了“数字员工”就随意裁员,毕竟人还是要有情感的,不能只追求效率。

从一个程序员的角度来说,这个比喻非常容易理解!之前对接不同的API简直是噩梦,恨不得把所有接口都改成一样的。MCP如果真能做到标准化,那绝对是开发者的福音!不过话说回来,标准这东西,制定起来容易,推广起来难啊。希望MCP能真正落地,而不是变成少数厂商的自娱自乐。另外,安全性也是个问题,统一接口意味着一旦出现漏洞,影响面也会更大。

Token啥的最讨厌了, burn我的钱!我觉得可以给Agent设定一个“沉默成本”的概念,如果Agent在一个任务上投入了太多的时间和资源,它可能会倾向于继续投入,即使这个任务已经没有价值了。为了避免这种情况,可以定期评估Agent的投入产出比,及时止损。另外,我觉得加入人类干预也是很重要的,不能完全依赖Agent自己解决问题,必要时需要人工介入。

我觉得解决“无效沟通”的关键在于明确Agent的职责和目标,避免Agent之间互相委派任务,导致死循环。可以引入类似项目管理的机制,每个Agent负责特定的任务,并定期汇报进度,由一个中心化的调度器来协调。设计多Agent协作系统,我会考虑以下因素:1. 任务分解:如何将一个大任务分解成多个小任务,并分配给不同的Agent;2. 通信协议:Agent之间如何高效地通信,避免信息过载;3. 冲突解决:当Agent之间发生冲突时,如何进行仲裁;4. 监控与调试:如何监控Agent的运行状态,并及时发现和解决问题。

“数字员工”绝对是未来趋势!以后面试可能不是跟HR,而是跟AI Agent聊天了。我觉得最大的变化是工作时间的弹性会更大,可以随时随地工作,不再受时间和地点的限制。而且“数字员工”可以24小时不间断工作,效率会大大提高。当然,也可能会出现一些问题,比如“数字员工”的版权归谁所有?“数字员工”犯错了谁来负责?这些都需要进一步探讨。

“USB-C接口”这个比喻不能说完全贴切,只能说有相似之处。USB-C更多是物理层面的统一,而MCP涉及到数据格式、交互协议等更复杂的层面。好处方面,我觉得标准化以后,Agent的可移植性会大大提高,今天用在阿里云的Agent,明天可能就能在其他云平台上运行。但风险也不小,标准化可能会限制Agent的创新,大家都按照一个模子来,反而失去了特色。

token消耗激增的问题,本质上是计算资源使用的优化问题。我的想法是引入一个“价值评估”机制,Agent在发起沟通前,先评估这次沟通的潜在价值,如果价值低于某个阈值,就取消这次沟通。设计多Agent系统,我会格外注意Agent的“涌现”行为,多个Agent协同工作时,可能会产生意想不到的结果,好的坏的都有可能。如何引导Agent朝着期望的方向发展,是一个很有挑战性的问题。

我觉得这个比喻挺形象的,USB-C确实统一了接口标准,让各种设备都能方便连接。MCP协议也是一样,统一了Agent访问外部资源的接口,降低了学习成本和集成难度。潜在好处方面,我认为它可能会催生出更多的第三方工具和服务,因为开发者不再需要为每个Agent单独适配,可以专注于提供更优质的服务。风险的话,如果MCP协议被少数大厂控制,可能会形成新的垄断,中小企业可能会面临更大的竞争压力。