AI Agent 技能演进深度解析：从技术革新到价值评估与应用实践

April 5, 2026

本文的思考源于我个人近半年在Agent领域的生产实践，以及与众多团队在过去一年间关于Agent的深入交流。这些讨论也源于我对诸如Manus这类项目所抱持的一些疑问。

当前，业界对于Agent的看法呈现出两种截然对立的观点：一方坚信Agent就是未来，将取代其他过时技术；另一方则断言Agent（如Manus）毫无用处，无法解决实际问题。

以下是两派观点的真实摘录：

Agent支持派 AI技术的发展日新月异，上半年的经验到了下半年可能就已经失效。去年Dify、n8n等工具备受推崇，但随着今年Agent模型的流行，新启动的项目普遍采用具备自主规划能力的Agent方案，已经很少有人再去考虑Dify、n8n这类被认为是过时的思路了。事实就是，新型Agent相较于旧式工作流，在效果上有着巨大提升。它缺乏专业数据、没有专属的工具链、没有行业认证、未能与业务深度集成，也没有绑定高价值的业务场景。换言之，任何人都可以模仿构建。因此，它更像是工程能力的延伸，而非在构建具有壁垒的场景护城河。用户会发现，当他们面临真正复杂的挑战时，这种通用Agent仍然无能为力，最终不得不转向专业的垂直解决方案或人工服务，这导致了用户留存率的持续低迷。 ……

总结来说，现状可以概括为一句话：有人认为Agent已近乎无所不能，代表着当前最先进的生产力；也有人认为Agent毫无价值，缺乏技术壁垒，耗费资源且无法解决实际问题。

如何理解这两种极端观点呢？过于悲观和过于乐观的认知都存在偏差，其直接后果是导致企业决策混乱——要么盲目投入，要么完全放弃投入。

在过去三年中，我全身心投入AI相关工作，先后接触了超过40家公司，主导或参与了25个AI项目（投入规模从过亿元到不足十万元不等）。基于在Agent领域的实践与思考，我希望能系统性地探讨以下核心问题：

Agent技术究竟先进在何处？它是否真的具备解决实际问题的能力？

Agent为何在2025年迎来元年

首先，必须明确Agent的核心在于调用外部工具。严格来说，Function Calling是Agent架构得以成立的基石，正是因为有了这项能力，模型才得以正式、规范地使用各类Tools。

虽然在OpenAI官方提出Function Calling概念之前，开发者也能通过训练特定模型或引导模型输出特定格式来模拟工具调用，但这终究不是通用、标准化的方法，因为更换模型后其效果往往难以保证。

当前最经典的Agent框架是ReAct（Reasoning and Acting），其思想大约在2022年提出，相关论文《ReAct: Synergizing Reasoning and Acting in Language Models》中就已包含了伪Function Calling的实现。直到2023年6月，OpenAI的一次更新正式推出了Function Calling，将其作为ChatGPT产品的核心能力之一。此后，这项能力逐渐成为行业事实标准，各大基座模型纷纷跟进实现。有了这个稳固的基础，Agent的构建与普及才真正变得顺理成章。

国内“Agent”概念的火爆始于年初的Manus。但如果追溯更早且具有广泛影响力的开源Agent项目，2023年3月发布的Auto-GPT是一个标志。然而，即便是今年初的Manus，也因早期基座模型能力不足而表现欠佳，更不用说更早期的Auto-GPT了。

自Manus发布后，行业焦点逐渐从“2025 AI应用元年”转向“2025 AI Agent元年”。与此同时，模型本身也取得了长足进步，包括整体推理能力和上下文长度都得到了极大增强。我个人相信，各主流基座模型一定在工具调用相关数据上进行了大量微调训练，其直接体现便是2025年下半年，模型的工具调用能力出现了显著提升。

尽管模型在工具调用的稳定性上已有不小改进，但当可用工具数量增多时，仍会出现“找不到合适工具”或“胡乱调用”的问题。为此，Claude团队总结了大量工具调优经验，于2025年10月正式提出了“Skills”技术。可以将其视为对Function Calling机制的重要补充（当然，Skills的目标远不止于提升工具识别能力）。

现阶段，通过结合使用Skills、Function Calling以及精心的上下文工程，已经能够将工具调用的准确率提升到相当不错的水平（例如，我们实践中的某些场景可以达到90%以上，这在之前是难以想象的）。

以上是我从技术演进视角观察到的近三年Agent发展脉络。简而言之：在2025年之前，想要构建一个真正好用的Agent几乎是不可能的任务；而从2025年下半年开始，这一难度已大幅降低。

因此，最终的结论是：此前对于Agent的诸多质疑以及糟糕的产品体验，预计在2026年将得到极大程度的缓解。从这个角度看，Agent的发展直接依赖于模型底层能力的跃迁，任何工程优化可能都比不上模型自身一次关键的能力升级。

接下来，我们将剖析其核心的编排层，这有助于解释Agent为何会变得越来越强大。

核心框架剖析：思考-行动-观察的循环机制

许多开发者知道Agent的工作模式在模仿人类，但未必熟悉“ReAct”这一术语，也未必能深刻理解**“思考-行动-观察”** 这一循环究竟有何价值。

毕竟，多一轮交互就意味着更慢的响应速度和更高的资源消耗（Token成本）。那么，为什么需要设计这样的多轮循环呢？我认为这主要是为了弥补模型自身规划能力的不足。通过多轮的自我调优与验证，模型才能最终生成一个相对合理的行动计划。

这就像一个需要引导的学生。一个生动的案例可以说明这种循环“调教”对于模型做出合理规划的重要意义：

“六顶思考帽”是一种经典的“平行思维”框架，旨在将混乱的思考过程结构化。其核心是为思考者赋予六种不同的角色（“帽子”）：

白帽：客观中立，只关注事实与数据。
红帽：感性直觉，表达情绪与直觉预感。
黑帽：谨慎批判，专注于风险与潜在缺陷。
黄帽：积极乐观，着眼于价值与机遇。
绿帽：创新创造，探索新想法与可能性。
蓝帽：统筹控制，管理整个思考流程并负责总结。

这一框架的威力在于强制切换视角，避免人们陷入单一的思维立场（例如一味批判或盲目乐观），从而实现对问题的全方位审视。以 “是否在公司启动一个Agent项目” 为例，运行一轮六顶思考帽，就相当于引导模型完成了一套ReAct循环：

白帽：我掌握哪些客观事实？公司现有基础如何？预算多少？有哪些现成的数据和系统可用？
黑帽：最坏的情况是什么？可能遇到哪些“坑”？哪些部门可能会强烈反对？
黄帽：如果项目成功，最大的收益是什么？对业务和团队能力会产生何种放大效应？
绿帽：在现有资源约束下，是否存在性价比更高的替代路线？例如，是否可以从改造一个小型流程开始，而非一上来就搭建全栈Agent平台？
蓝帽：将前述所有视角收束整合，形成一个可执行的行动计划：先做什么、如何分阶段、如何验证效果、失败后如何止损——最终由蓝帽角色收尾并输出结论。

这一整套流程跑下来，模型在持续地对自身的初步想法进行追问、纠偏和补充，实现了典型的“自我对话”。这带来了三个关键好处：第一，强制补全思考的视角盲区；第二，将“想清楚”这件事，从一次性的直觉判断，转变为逐步逼近最优解的迭代过程；最终，让决策规划从不可捉摸的“黑盒”，变为可复盘、可分析的清晰过程。

“六顶思考帽”这种模式，实质上为模型设计了一套自我对话与训练的框架。从Agent的视角看，这是对 “思考-行动-观察” 这一ReAct循环进行了更精细的角色化实现。其结果印证了一个观点：模型的规划能力并非凭空产生，而是在一次次结构化的自问自答中逐渐“生长”出来的。

随着模型底层能力的持续增强，其生成的解决方案自然会更加完善。因此，从框架设计层面看，Agent架构确实具备越来越强的潜力，尽管目前较高的Token消耗成本暂时无法完全避免。

在理解了Agent的进化史与核心框架后，我们再来审视一个经典的案例场景。

工具（Tools）的威力：有限元素的无限排列组合

首先，需要建立一个基本认知：大语言模型本身并不具备真正的“思考”能力，它的每次回应都是基于海量数据训练后，对文本概率分布的模仿与生成。例如，如果向DeepSeek询问Claude在2025年10月发布的Skills技术，它是无法准确识别的：

因为这些信息并不存在于它的训练数据中。对于模型“知识盲区”内的事物，它倾向于“胡编乱造”（即产生幻觉），OpenAI的研究论文《Why Language Models Hallucinate》也阐述了这一点。

为了解决知识实时性和准确性的根本局限，模型必须引入调用外部工具的能力。随着Function Calling、MCP（Model Context Protocol）等标准的出现，模型开始从纯粹的“问答机器人”向解决具体问题的“智能体（Agent）”进化。

这也正是许多人视Agent为先进技术与先进生产力代表的原因。严格来说，Agent在工具利用的效率和灵活性上确实更具优势：

在过去，我们解决问题的主要模式是 “工作流（Workflow）+ AI” ，模型只在流程的某个固定节点上贡献其特定能力（如文本生成、分类）。Workflow模式稳定且高效：

然而，Workflow模式面临一个根本性难题：总有大约20%的长尾、复杂或非标准化的场景是其预设流程无法覆盖的。并且，试图覆盖这些长尾需求的成本急剧上升：

或许10个精心设计的Workflow可以解决80%的常见问题，但若想将覆盖率从80%提升到85%，可能需要100个Workflow；想提升到90%，则可能需要1000个……

于是，核心矛盾凸显：Workflow模式难以满足用户无穷无尽的个性化需求，且边际成本越来越高。那么，出路何在？

答案是：用一组相对有限的工具（Tools），通过智能组合来应对用户千变万化的意图（Intent）。

这种思路得以成立，依赖于两个前提：第一，模型的基础能力（尤其是理解与规划能力）已经足够强大，ReAct（思考-行动-观察） 架构在多数情况下能有效完成任务的分解与规划；第二，经过互联网多年的发展，许多工具和服务已经高度标准化和API化：

常用工具如搜索引擎、地图服务、基础文件处理等接口非常规范；
非标准但高频的业务操作，如订票、支付、操作特定App（如抖音）等，短期内可通过RPA技术过渡，长期看垂直平台（如携程）终将开放标准接口；
更前沿的平台级技术，如Computer-Use（操控电脑）、Browser-Use（操控浏览器）乃至手机自动化，都在持续突破中；
当然，终极的“大杀器”是AI编程（AI Coding），理论上它能根据需求动态生成所需工具（尽管目前还无法完全实现）。

因此，模型的动态规划能力 + 有限工具的排列组合，在理论上具备了解决那20%长尾问题的潜力。即便不能完美解决所有边缘情况，它也能显著降低将问题覆盖率从80%提升到90%所需的工程成本。

下面，我将结合一个自身的实践案例来具体说明。

实践案例：规划（Planning）与工具（Tools）如何收束用户意图

从去年开始，我的工作变得异常繁杂：需要寻找研究课题、撰写技术文章、开发培训课件、拜访客户、出差提供咨询、处理各类售前需求……此外，还需要投入精力进行团队管理。事情一多，最直接的后果就是：很多任务会被遗漏或处理不当。

起初，我采用简单的待办清单（Todolist）加提醒的方式：

记录所有待办事项；
设置时间提醒以防遗忘；
完成后勾选标记。

然而，随着任务来源和类型日益复杂，这种简单模式很快捉襟见肘：

任务来源爆炸式增长：微信聊天、公众号文章、抖音/视频号、小程序消息等；
每条任务背后的上下文迥异：有的是一个选题灵感，有的是客户需求片段，有的只是一条值得记录的学习心得；
需要协同：很多任务需要与团队共享、分配并跟进进度。

于是，我转向了Workflow（工作流）方案：

如果消息来自某个特定微信群，则自动抄送到表格A；
如果内容包含“选题”关键词，则自动打上相应标签；
如果是抖音链接，则触发某个脚本进行预处理。

这确实解决了一部分问题，但很快就遇到了前文所述的困境：规则永远不够用。一旦信息入口再增加几个，或出现一两个新场景，预设的Workflow数量就会呈指数级增长，陷入“10个流程覆盖80%，想覆盖90%却需要1000个流程”的怪圈。

此时，正是引入Agent的恰当时机。对我而言，核心诉求并非重建一个极度复杂的任务管理系统，而是在一个相对稳定的待办清单/项目看板之上，增加一个**“项目小助理Agent”**，让它帮助我将散落在各处的“事务”智能地搬运并结构化到“中央任务列表”中。

这个小助理Agent只配备了有限的几类工具（Tools）：

文本提取类：从微信消息、抖音链接、网页URL中抽取核心正文内容。
内容加工类：对提取的文本进行摘要、改写或关键信息提炼。
结构化写入类：将处理后的信息，按照既定字段（如来源、类型、优先级、截止时间、负责人等）写入多维表格或项目看板。
通知提醒类：在需要时，向我或相关同事发送一条“有待处理任务”的提醒消息。

从工具视角看，这套能力非常“有限”，就是几种固定的操作。但从“用户意图”的视角看，它可以覆盖极其多样的变体：

“把这篇公众号文章发给你，帮我记成一个‘选题’待办。”
“这个抖音视频不错，帮我提炼核心观点，记成一条‘学习任务’。”
“客户在微信里提的需求，帮我拆解成三个可执行的子任务，并分别分配给不同的同事。”
“这篇长论文我只需要结论部分，帮我提取出来，保存为一条‘写作素材’。”

相信至此，Agent的核心价值已经凸显：它极大地增强了我原有任务管理系统的“泛化”能力。 模型运用ReAct式的“思考-行动-观察”循环，来决定如何排列组合这些有限的基础工具：

对于同一个输入（如一条微信消息），Agent会先判断其意图属于“选题”、“学习任务”还是“客户需求”，然后按照相应的逻辑链调用工具：

路径示例：提取文本 → 生成摘要 → 识别任务类型 → 写入对应的项目表格 → 根据需要创建提醒。
迭代优化：如果发现关键字段（如截止时间）缺失，则会主动询问用户进行补充，然后继续执行后续调用。

最终结果是：我不再需要为每一种可能出现的具体场景编写死板的Workflow规则。我只需提供一组通用的基础能力（Tools），然后把 “如何根据具体情况组合这些工具” 的决策权交给模型的规划能力。这样，就能在可控的成本下，应对用户几乎无穷的意图变化。

这正是前文观点的现实落地：有限的工具集（Tools）结合模型的动态规划能力，能够在成本可控的前提下，有效地“消化”大量的长尾、非标准化需求。

从这个角度看，Agent或许不能简单地定义为一项“尖端黑科技”，但在应对现实世界的复杂性与多样性方面，我尚未看到比它更优雅的工程解决方案。这本质上是一种设计权衡：用更多的时间（多轮交互）、空间（系统复杂度和Token成本）以及稳定性上的一点妥协，来换取对业务场景更强大的“兜底”能力。 既然设计初衷如此，我们就不应脱离这个前提去苛责Agent现有的某些“毛病”。

总结与展望

当然，一个优秀的Agent系统离不开复杂的记忆（Memory）模块。但需要明确的是：记忆体系虽然设计复杂，其在Agent架构中的核心使命，是帮助模型更精准地理解用户的长期偏好和历史上下文，从而做出更合理的规划，并调用更恰当的工具组合。

鉴于记忆系统衍生出的“上下文工程”是整个Agent工程架构中最复杂、最繁琐、成本也最高的部分——涉及复杂的结构设计、状态实时更新、偏好动态记录、知识高效增强等诸多挑战——本文暂不就此展开深入讨论。

最后，让我们回归最初的核心问题：Agent究竟是代表未来的先进生产力，还是一个谁都能复制的“伪概念”？ 相信读到此处，您心中已有更清晰的判断。

Agent不仅是一项先进的技术架构，更是当前AI应用演进中一次极具价值的范式突破。

它的出现并非偶然，而是建立在坚实的技术演进逻辑之上：从早期的伪工具调用摸索，到2023年OpenAI确立Function Calling标准，再到Claude Skills等工程优化实践。如今，模型在工具调用、任务规划与动态执行方面的综合能力已实现质的飞跃。这正是2025年Agent得以从“技术演示玩具”走向“实用生产工具”的根本原因。

从工程实践视角审视，Agent并非玄学，而是一种清醒而务实的取舍：用更多的Token消耗、更复杂的多轮交互循环以及更高的系统复杂度，来换取更高的场景覆盖率和前所未有的需求泛化能力。

本质上，这是以 「时间 + 成本 + 稳定性的微量牺牲」 为代价，换取 「对业务长尾需求的极大化收缩」 。如果你认同真实世界的业务需求必然是长尾分布且充满变化的，那么在现有的技术条件下，确实很难找到比Agent范式更合理的工程化解决方案。

再看以Manus为代表的产品路线，市场或许给出了更有说服力的答案。一个曾被无数人嘲讽为 “简陋套壳”、“一个周末就能抄出来” 的产品，几个季度过去了，不仅未被淹没，反而在RLI（Real-world Language Interaction）等面向实际应用的基准测试中长期位居前列。这说明了什么？

这说明它可能恰恰踩中了正确的结构性方向：Less structure, more intelligence （更少的硬编码结构，更多的智能涌现）。

展望未来，正如Manus创始人张涛所言，Agent将朝着几个方向持续演进：成为更通用的工具调度平台、提供更持久的伴随式服务、实现更主动和深层的用户意图理解。

它或许尚不完美，在成本控制、超复杂场景下的稳定性等方面仍有很长的路要走，但其发展路径已然清晰：作为扩展人类智能与工作效率的新一代“中介”，Agent正在将AI从“对话的奇迹”转变为“行动的伙伴”。

因此，对于身处这个时代的每一位技术构建者与产品使用者而言，理解并善用Agent，已不再是一道选择题，而是一道关乎未来效率与竞争力的必答题。

最后，请允许我引用张涛在清华大学一场分享中的结语，它很好地概括了当前我们所处的阶段：

现在已是2025年的最后一个月，如果你还没有真正使用过Agent，至少要在今年学会如何与它协作共事，就像几十年前人们学习使用个人电脑一样。

几年之后，你或许不会记得任何一篇谈论Agent概念的热门文章，但你一定会清楚地意识到：自己是从哪一年、哪一刻开始，真正把Agent当作日常工作中不可或缺的一部分的。

2025，Agent元年，仅仅只是序幕的拉开。