2025 Agent元年回顾与2026趋势展望:从模型壁垒到生产落地
此前,我们从工程实践的角度对智能体(Agent)的发展脉络进行了一次概括性的梳理(详见:《万字:Agent概述》)。
时值2025年——这个被广泛称为“Agent元年”的最后一周,我们有必要以一种更为全面的视角,审视Agent技术在过去的这一年里究竟取得了哪些实质进展,各家公司的实际落地情况如何。所有这些观察与总结,都将为我们明确在2026年应该如何对待和布局Agent技术提供清晰的方向指引。

首先,让我们一同回顾2025年人工智能领域那些标志性的大事件。
模型能力构筑核心壁垒
本年度的开端便由两笔巨额融资奠定基调:
- 软银(SoftBank)为履行对OpenAI总额225亿美元的资金承诺,在年底前紧急筹措资金,此时OpenAI的估值已攀升至约3000亿美元。
- 以Claude模型闻名的Anthropic成功完成了130亿美元的融资,其估值也超过了1800亿美元。
与此同时,Meta公司也启动了一项规模浩大的人才争夺计划:

趋势非常明确:资本正以前所未有的规模涌入基础大模型领域,并且呈现出愈发显著的头部聚集效应。模型,作为未来AI时代的“操作系统”,正逐渐扮演起“赢家通吃”的核心角色。这意味着,顶尖的模型几乎可能渗透所有应用层。其他公司若想生存与发展,则需要围绕这些核心模型构建自身的生态。
AI编程:已验证的Agent成功范式
AI编程领域已成为当前最具确定性的现金流入口。其中,Cursor累计融资达32亿美元,估值接近300亿。Cognition / Devin、Replit、Lovable等公司也均有不俗的收获。
国内相关领域的发展相对滞后,虽有硅心科技、言创万物等参与者,但知名度有限。究其原因,在编程IDE(集成开发环境)这类核心生产力工具上,开发者群体普遍更信赖拥有强大技术背书的大厂产品。
事实上,市场上已涌现出一大批无需依赖风险投资的公司和产品,例如微软的GitHub Copilot、谷歌的Gemini Code Assist、阿里的通义灵码、Trae、CodeBuddy等。
AI编程之所以特别值得深入探讨,是因为它是目前少数能够真正令用户感到满意的Agent应用场景。该领域付费意愿强烈,验证链路清晰明确(能够运行测试、集成到CI/CD流程),并且直接替代的是成本高昂的人力资源。
AI编程能在众多Agent设想中脱颖而出,很大程度上得益于程序员群体对自身工作流(KnowHow)有着极为清晰的定义,同时GitHub等平台积累了海量高质量、结构化的代码语料。这种数据与认知的双重优势,是其他行业短期内难以复制的。
从AI编程的成功案例开始,我们可以窥见基于大模型的Agent大致分化为两种路径:
- 通用型Agent,以Manus为代表;
- 垂直领域Agent,以Cursor为典型。
就现阶段而言,通用型Agent的普遍用户反馈并不理想,但垂直领域Agent已经开始切实地解决特定场景下的实际问题。
垂直领域Agent备受市场青睐
除了AI编程,还有几款垂直Agent获得了业界的高度评价。首推Lovart,这是一款面向设计师的Agent。
它能够依据一句简单的提示词,直接生成一套完整的品牌级设计成果,包括主视觉(KV)、海报、多种尺寸的社交媒体图片等。用户无需搭建复杂的工作流程,上手即用且自由度极高,堪称当前最接近真实设计团队协作能力的AI产品。
另一款典范是OpenEvidence,一个专注于循证医学的“证据供给链Agent”。该产品旨在从根本上解决医疗场景中AI可能产生的“幻觉”问题。其核心功能是:紧密围绕医学文献与权威信息来源,生成有证据支持的回答并自动附上引用来源。
这些垂直Agent能取得成功,核心原因在于其所在领域的工作本身已经实现了高度的标准化流程(SOP)。对于Lovart而言,互联网上存在海量的图像及相关数据;对于OpenEvidence,医疗侧的临床指南、教材等信息数字化和标准化程度本身就非常高。
类似的产品还包括红杉资本青睐的法律AI——Harvey。它与Cursor、OpenEvidence一样,都获得了可观的融资。这揭示了一个重要趋势:资本市场并未盲目追捧所有标榜“Agent”的概念,而是有选择地押注于那些能解决真问题、具备清晰商业路径的垂直应用。
我认为,Agent技术正在从一个充满“泡沫”的故事概念,走向工程化、可交互的真实产品。一个简单的原因是:从纯工程实现角度看,一个基础的Agent框架技术壁垒并不高。因此,除了少数具备先发优势和生态的通用型Agent(如Manus)表现尚可外,其他通用方案普遍反响平平。与此同时,各大科技厂商也都在积极分食通用Agent平台这块蛋糕。
流量入口变革:从SEO到GEO
当前的流量分发逻辑已经发生了深刻变化。一个最明显的趋势是,企业不再愿意为传统的搜索引擎优化(SEO)支付过高费用。虽然AI应用获得的流量在增多,但围绕AI生成的、以答案为导向的流量获取(GEO)模式整体上仍不成熟。这导致许多公司虽有付费意愿却找不到有效渠道,该领域也因此成为“割韭菜”的重灾区。
本轮流量入口变革最直接的竞争体现是,各大公司都在竞相推出或强化自己的“AI浏览器”,包括Chrome(集成AI助手)、Dia、QQ浏览器、ChatGPT Atlas等。
其核心逻辑高度一致:用户获取信息的体验正从“搜索链接”转变为“直接提问获取答案”,各大巨头都在全力争夺这一新的核心入口。
企业数据资产成为竞争焦点
另一个竞争白热化的板块是AI办公自动化(AI OA)领域,这在国内主要对应两大即时通讯与协作平台:飞书与钉钉。对于大多数企业而言,引入AI的最大瓶颈往往不是模型能力不够强,而是企业内部不清楚有哪些流程可以且应该被自动化。
因此,这些平台的核心工作路径是:先帮助企业梳理和标准化工作流程(SOP),然后将其Agent化。有趣的是,飞书与钉钉在该领域的核心武器颇为相似:AI表格。它们本质上是在侵蚀传统Excel在企业数据处理中的市场份额。
在AI表格这类核心应用之下,还存在一些如Coze、Dify等定位“低代码/无代码AI应用搭建”的边缘角色。它们都希望分食AI OA这块蛋糕,但实际市场表现并不尽如人意。
尤其是Dify这类拖拽式低代码平台,其定位在一定程度上与强调代码生成的AI编程存在冲突。对于它们在2026年的整体发展方向,我持相对谨慎的态度。
可以预见的是,经过2025、2026两年的市场教育与实践洗礼,当各企业内部SOP梳理清晰、数据资产准备就绪后,真正的企业级Agent时代才会步入正轨。
在此需要特别提及钉钉最近的“木兰1.1”产品发布会。钉钉正试图提出一套标准化的范式,来系统性协助企业客户整理和激活自身的数据资产。
工程视角的观察与总结
从前述行业与市场情况来看,2025年确实可以被称作“Agent元年”,因为产业上下的一切动向都在为Agent技术的成熟铺平道路。
Agent的效能高度依赖于底层模型的基础能力。上文提到的几个成功Agent案例,其崛起也离不开大模型在编程、图像生成(尤其是“Nano Banana”这类技术)、医疗问答等特定领域本身就已展现出强大实力,而这些领域通常也是各类基准测试的重点。
这也引申出一种务实的开发策略:模型在哪个方面强,我们就做哪个方面的Agent;模型能力达到60分,我们通过工程和产品化将其体验提升到70分即可。
最后进行一下总结。从上述案例中,我们其实可以逐渐梳理出构建一个成功Agent的基本脉络:领域知识(KnowHow) → 高质量数据 → 标准化工作流(Workflow) → 可靠的Agent。
我的观点是:Workflow是通向实用Agent的必经之路。尤其是对于企业市场所需的Agent,其对稳定性的要求极高。然而,传统的Workflow系统维护到一定阶段后,复杂度会急剧攀升,维护起来异常痛苦:

为了解决Workflow维护困难、并提升其泛化能力,Agent架构应运而生。但早期Agent的表现往往不稳定,于是工程上尝试通过增加Token消耗、以“Token换架构”的方式来解决问题,不过实际执行下来效果并不理想。
随后,模型侧又提出了更多的工程优化策略,近期Claude推出的“Skill”策略可谓是集大成者。但问题也随之转移:之前是显式的代码化Workflow调用,现在则转移到了各个“Skill”的协调上,流程的复杂度被编码进了提示词中。简而言之:之前是用代码写Workflow,现在是用提示词写Workflow。
因此,MCP(Model Context Protocol)的提出是为了解决工具调用的工程问题,Skill的提出也是为了优化复杂任务处理。我们再来看看模型能力优化的演进图:

可以看出,模型能力的进化一直围绕着工具调用(Tool Use)进行优化。纵观整个2025年,模型在支持Agent方面的改进,我认为在“工具调用”相关问题上已经达到了及格线。接下来,模型很可能将啃另一块硬骨头:记忆系统。
现阶段,无论是RAG(检索增强生成)还是复杂的上下文工程设计,其构建难度和复杂度仍然过高。预计模型提供商将会推出类似Skill的、更工程化的记忆系统接口,大幅降低高效记忆系统的构建门槛。
但大家也不必过早乐观。就像Skill上线后能将稳定性从70分提升到90分一样,该做的底层数据治理、知识梳理等工程化动作,一个也少不了。
综上所述,无论是模型基础能力的针对性增强,还是各种工程化接口的开放,都标志着Agent技术在2026年将步入一个更为成熟的阶段。因此,2026年很有可能成为一个“Agent应用大年”。
接下来,让我们从宏观趋势转向微观实践,通过观察各类企业的实际落地情况,来审视Agent的真实面貌。
生产环境中的Agent实践
本节多数数据来源于研究报告《Measuring Agents in Production》。该研究基于306份从业者问卷,并在26个业务领域进行了20个深度案例访谈,重点聚焦四个核心问题:为什么做Agent、怎么做、如何评估效果、以及遇到的最大挑战是什么。
我们将结合这份论文的发现,并融入我实际观察到的行业情况,进行综合解读。
效率优先:企业务实的选择
在“为什么要做Agent”这一问题上,企业表现出高度务实的态度。**提升效率/生产力(72.7%)、减少人力工时(63.6%)、自动化重复劳动(50%)**位列动机前茅;而“风险缓释、加速故障恢复”这类更难量化或反馈周期更长的价值,则排在后面。

这背后也形成了一个未来评估Agent项目的重要决策准则:
能否清晰计算投资回报率(ROI)。能够计算高ROI的项目优先启动和落地。在项目规划中,需要明确量化指标,例如具体节省了多少人/小时、缩短了多少处理时长,如下例所示:

相应地,凡是ROI不明确、难以证明的项目,企业会选择暂时不碰,或仅在内部进行小范围试点。
Agent定位:人类助手而非完全替代
目前,绝大多数投入生产的Agent定位依然是“服务于人”。它们的主要作用是减轻人员在某一特定环节的工作负担。因此,Agent的落地路径通常遵循“由内而外”的原则:先在容错率较高的内部场景使用并优化,待稳定后再面向外部客户开放。
另一方面,企业对Agent的响应延迟(Latency)容忍度其实相当高。报告指出得非常直白:只要对比的对象是“需要人工处理几小时甚至几天”的流程,那么Agent即使花费几分钟来完成,也依然是数量级上的效率提升。
强可控性远胜于开放式智能
报告中有一个关键发现,与我线下调研十数家企业观察到的情况完全吻合:生产环境追求的不是更强的自主性,而是更强的可控性,其对系统稳定性的要求是极高的。
此外,许多团队吃够了此前“百模大战”时期频繁切换模型的苦头,现在更倾向于直接调用云端成熟的模型API,仅有极少团队会进行模型的后训练(fine-tuning)。
原因很直观:自行训练模型耗时费力,且一旦外部主流模型迭代更新,自己的模型很容易落后,得不偿失,不如保持观望。
与此同时,提示词工程正日益“代码工程化”。由于越来越多的业务逻辑从硬编码转向由提示词驱动,导致提示词变得越来越庞大和复杂。如何将提示词写得优雅、可控、可维护、可迭代,正逐渐成为AI工程师的一项基础且关键的能力。
再者,由于当前模型能力仍有局限,相应的系统设计会趋向保守。数据显示,68%的系统在运行最多10个步骤后就需要人工介入。步骤越多,评估越困难,延迟越高,整体失败的概率也越大。
最后,也是最关键的一点:80%的深度案例采用了结构化的控制流。系统最核心的业务流程会在一个清晰定义的SOP框架内运行,不会放任Agent自由规划和发挥。也就是说:
生产级Agent的主流形态,非常接近于 “内嵌了LLM的、强约束性工作流(Workflow)”。
AI产品效果评估的困境
这也是一个关键痛点,与我们之前的实际生产经验相符。大型AI产品在效果评估上,仍然在很大程度上依赖人工评估。虽然会部分借助模型基于已有数据集进行自动判断,但最终往往需要真人进行复核。
这自然会引出一个疑问:为什么AI产品的自动化评估如此困难?为什么不直接使用公开数据集?
原因很简单:成本太高,且不适用。许多垂直行业根本没有可用的高质量公共数据集,团队只能从零开始手工构建测试基准(benchmark);有团队为了将测试场景从40个扩展到100个,花费了数月到半年的时间。
而且,真实用户的提问和交互是不可控的。即使有好的静态数据集,评估结果与线上真实效果也常常存在差距。因此,最终很多团队选择放弃复杂的自动化测评体系,直接采用真人评估作为黄金标准。
Agent落地的最大挑战
当前Agent落地最难、且尚未被完美解决的问题依然是:可观测性与可靠性保证。
评估本身极其困难。如果你无法建立一个能即时、自动判断对错的验收标准,那么Agent执行得是否正确,往往只能等到它在真实业务中产生后果后才能知晓。而这些后果通常反馈缓慢、代价高昂,且很难被程序自动判定。
整个生产级Agent的落地现状,可以用一句话总结:将不可靠的模型能力,封装成可交付的稳定业务结果。这里的核心难点在于如何实现Workflow与Agent能力的有效结合。
接下来,我们将探讨关于Agent的两个反直觉认知:多Agent系统不一定更好用、更多的Token投入并不必然带来更高的稳定性。
多Agent系统的效能陷阱
当前行业中存在一种普遍直觉:任务越复杂 → 就需要加入更多Agent进行分工协作 → 系统性能理应更强。但在真实落地场景中,经常出现反直觉的现象:增加Agent数量后,系统反而变得更慢、更昂贵,且更容易出错。
这个结论得到了论文《Towards a Science of Scaling Agent Systems》的支持。该研究设计了一个干净的对照实验:在同一批Agent任务、同一套工具接口、相同的Token预算约束下,尝试不同的Agent协作架构(如独立并行、中心化调度、去中心化协商、混合模式),并跨不同能力级别的模型进行大量测试。
最终得出的结论,与我们在一线实践中踩过的坑高度一致:引入多Agent架构会带来一种新的“系统税”。
许多人想象中多Agent相当于“多了几个大脑”协同思考,但实际情况可能更接近于**“多了几个部门”**:组织一旦复杂化,产出未必提升,大量无实质产出的内部沟通(好比部门间冗长的会议)却急剧增加。
在固定Token预算下,多Agent之间需要更多的消息传递、状态同步、上下文重复描述,导致本应用于有效推理的预算被内耗吃掉。你以为是在增加“思考能力”,实际上可能是在扩张“沟通成本”。
多Agent架构可能会消耗数倍于单体Agent的Token,目的仅仅是为了维持多智能体间上下文的一致性。
进而,跳出效率视角,我们最关心的是多Agent架构能否提升系统的整体稳定性(鲁棒性)。答案通常是否定的:
多Agent之间并非简单地“互相监督纠错”,更多时候可能是在“互相传染错误”。这很像一个戴着耳机传话的游戏,一旦第一个Agent出错,后续的Agent很可能沿着错误路径一路错下去。
当然,多Agent架构也并非总是低效的,其效果高度依赖于任务类型,以及每个Agent的职责边界是否清晰且彼此间是否存在必要的信息依赖。在此我们不做深入展开。
循环反思次数 ≠ 任务成功率
最后一个反直觉点,甚至对经典的ReAct(推理-执行)架构构成了一定冲击。通常我们会认为:通过多轮反思、并行采样、多数投票等机制,只要让Agent“思考”和“讨论”得足够多(增加循环次数),最终输出的结果就一定会更好(这包括了调用更多次工具进行验证)。
然而,论文《Budget-Aware Tool-Use Enables Effective Agent Scaling》给出了不同的答案:
工具调用次数直接决定了Agent与外部世界交互的深度和广度,但盲目增加反思和工具调用循环,常常导致:重复搜索相同信息、无效浏览、策略陷入死循环而无法更新等问题。
这里我做一个通俗的解读:当前模型的智能水平,存在一种**“懂的部分一点就通,稍加提示即可;但不懂的领域,即使反复提示和追问,也可能无法突破其认知边界”**的现象。
论文后续主要探讨的是一套成本控制工程逻辑,对于多数实践者的直接借鉴意义有限,在此不再赘述。
回顾与展望
回望2025这个“Agent元年”,行业真正确立下来的并非“通用人工智能”的愿景,而是“可交付、可度量”的实用主义精神。真正跑出来的基本都是垂直领域Agent,因为它们所在的领域知识更明晰、数据更标准、效果验收更容易,从而能够将模型的不稳定性封装成相对稳定的业务结果。
生产环境的实践也给了我们两条反共识的教训:多Agent系统往往更慢、更贵、更易出错;更多的反思循环和Token消耗,并不必然换来更高的任务成功率。企业最终需要的不是更炫酷的智能,而是更强大的可控性。因此,Workflow的道路依然漫长,并且其思想正进一步向模型侧渗透。
最后,关于2026年该如何行动,这需要回归我们一贯倡导的务实原则:先评估预算与资源,再将复杂任务合理拆分,凡是能用AI提升效率的环节就优先尝试AI化。只不过,现在或许可以加上一句:经过元年的积淀,真正能够创造价值的Agent,可能真的要开始大规模来了。