2025关于 AI Agent 的一些总结

2025年，大家都一致认为是AI Agent爆发的元年。

回顾整个2025以及过去几年，我们从2022年开始专注智能体创作方向，探索AI与内容创作的无限可能，到2024年推出AI搜索引擎hellomiku，再到今年12月推出了图文内容创作智能体01Agent。作为01Agent的联创，这几年在AI Agent应用落地实战不断的试错探索过程中，也有自己的一些经验和思考想在这里和大家一起分享。

站在2025年的尾声回望，这一年来Agent的发展并非一条直线，更多是在狂热与冷静、通用与垂直、Tools与skills的博弈中螺旋上升。

整篇文章首先将简单回顾一下2025年agent相关技术的发展情况，并就以下6个板块分享我的深度复盘：

1. 1.2025 AI Agent发展概况
2. 2.MCP之后为什么会出现 Skills
3. 3.只有充分上下文的信息，才能做出正确决策
4. 4.从上下文工程到Agent工程
5. 5.Agent 落地的关键还是在于交付
6. 6.数据资产与memory才是真正的护城河

一、2025 AI Agent发展概况

首先我们一致达成共识的是AGI目前仍处于 新兴AGI 阶段。尽管大模型能力不断在攀升，但它尚未达到全面执行人类所有智力任务的水平。相对于简单的信息整理或归纳总结生成任务，面对一些复杂的长链条任务，单纯依赖模型能力的提升远远不够。基于LLM为基座的Agent以及RAG的深度融合，特别是上下文工程的构建，成为了这一年Agent发展的重中之重。

当然不只是在今年，早在 2024 下半年开始就已经越来越多的厂商开始加入到Agent赛道，例如2024.10.24 Anthropic 首次推出computer use 、2024.11推出的MCP server以及智谱的Autoweb glm等。到了今年3月，技术的迭代速度实在太快，大模型关键里程碑技术的突破又诞生出了o1以及deepseek R1 等推理模型，以及类似Manus （整合computer use ，browser use，coding agent）等的新形态agent产品。

短短两个月，到5月份，由于manus的推出，这段时间各种类Manus的产品也相继推出，如genspark.ai、skywork.ai、纳米AI、lovartai、fowith.ai。这类agent产品大多数受Manus以及MCP server的启发，并基于agent工程，包括任务规划todolist，集成各类MCP工具，以及上下文等工程，组成的一个super agent。通过大量的工具，也让agent开始可以具备感知更多环境的能力，比如基于playwright mcp server，agent可以开始自主使用浏览器。相比于上一阶段类似基于LLM的AI搜索只能做一些信息整理生成输出，agent执行复杂的任务能力得到显著提升。当然这也离不开llm推理能力的不断进步，如claude那段时间最新推出的claude 4模型等。

在那段时间，MCP的发展也非常迅速，市面上从最开始1000多个mcp工具，已经发展到13473+mcp工具。并且也出现了各种一键封装集成mcp的工具，如fastmcp；谷歌也在那段时间推出了类似MCP关于Agent的A2A协议，MCP 侧重于智能体与外部数据/工具的连接，而 A2A 则侧重于智能体与智能体之间的协作。

随着agent工程不断复杂化，每一次执行任务都依赖大量的llm请求和工具调用以及不同agent的配合，其中在大模型上下文有限的情况下，如何跟踪不同agent的状态以及对每一次工具调用结果的管理变得至关重要，有效的管理不仅可以提升agent的任务完成率，并且也可以有效降低执行任务消耗的token成本。为此2025.06 AK在X提出了上下文工程的概念：[上下文工程是为下一步提供正确的信息填充上下文窗口的微妙艺术和科学]。

差不多到了8月份，身边许多朋友对通用agent能力的质疑声越来越大，特别是关于通用agent最终交付完成率，好看不好用？结果用户是否满意？是否愿意付费？总的来说目前整体市面上通用agent的任务交付率相对较差的。反而在垂直领域的agent表现效果突出，短短几个月，继cursor之后，国内字节，腾讯都推出或更新了自家的AI Coding产品，如字节的trae，腾讯的codebuddy，包括anthropic的claude code，当然AI coding效果表现出色离不开模型不断进化的代码编程能力，如claude sonnet 4.5 , gemini 3 pro ,glm4.7等。

再到10 月 16 日 Anthropic 正式推出Agent Skills，最近openai 官方也开始支持Skills功能了，Claude的Agent Skills将彻底改变行业格局，推动在编程、客服和文档生成等领域的深度任务集成，这也将标志着各种行业开始采用更专业、更高效的Agent。

总的来说，这一年我们见证了从 MCP 工具生态以及通用agent的‘寒武纪大爆发’，到下半年对通用 Agent 交付能力的冷静反思，再到垂直场景（如 Coding）和引入 Skills 机制的务实演进。这种极速迭代的背后，实际上是 Agent 发展逻辑从‘连接万物’向‘精准交付’的深刻转型。

二、MCP之后为什么会出现 Skills？

为什么会出现 Skills？ 可以这么说Skills的出现是Agent发展的必然产物。

无论是Manus的computer use还是claude code 的coding agent，当我们将终端命令行、文件系统等底层权限交给 Agent时，这里会暴露出一个问题：工具变得更精简了（比如filesystem、terminal、browser等），但任务的编排组合复杂度却呈指数级上升。比如给我一台顶配的电脑，但是我不知道怎么用不会用，再好的工具对我也没有意义。所以Agent也是一样的，再好的工具如果Agent不知道怎么用，怎么组合使用，那再好的工具也无济于事。我相信这也是大多数通用Agent任务完成率低的原因之一。

当前阶段的Agent 不再缺乏手脚，而是缺乏大脑中的规划逻辑。Skills 正是填补这一空白的拼图，它通过预设的专家经验或者任务场景工作流，引导 Agent 在复杂的本地环境中，以更规范、更稳定的路径去交付结果。在物理形态上，Skills它非常朴素：就是一个包含说明书（SKILL.md）和参考资料或脚本的文件夹。

如果说Mcp server Tools 是给 Agent 发了一把锤子，那么 Skills 就是塞给它一本使用手册。这里需要注意的是，在 Agent 开发中，我们往往容易陷入“工具堆叠”的陷阱：感觉工具越多，agent的能力边界就越大。其实，更高效的做法是将“怎么做”的经验打包。

最好的例子就是browser_use，用户每天都会在基于浏览器进行各种各样的任务，每个任务都有对应的sop链条，如何将这些链条转为skills，并在用户发送指令时精准识别对应的sop并召回将变得越来越重要。比如在01agent开发设计过程中，无论是发布还是选题都有对应的skills，并且会根据不同broswer_use的任务最终自我反思成一个可复用的sop。过去可能agent完成一个自动化发布的任务，需要走很多弯路，但是现在有了自己的sop，并且这个sop会不断自主反思进行更新的，整个browser_use的任务完成率也得到了大幅提升。

三、只有拥有充分上下文的信息，才能提高大模型做出正确决策的概率

LLM 的本质是输入和输出，每一次上下文的输入决定了每一次的输出是什么；那么你也可以理解为Agent只不过是基于上下文不断循环的输入输出。

如何做出正确决策？这不经让我思考，两个同样聪明的人，能让它们拉开差距最大的因素是什么？答案很可能是解决问题的能力，而解决问题的能力关键在于如何围绕问题本身尽可能获取全面的上下文信息，并基于上下文信息做出正确的决策。只有你获取的上下文信息足够多，你才能做出正确决策。这里有个极端的例子，比如如果我都知道全球关于某二手车的所有卖家的信息了，那么我一定可以做出正确的决策选择出最具性价比的那辆车。

如何做出正确的决策，关键在于决策环境下获取的信息充不充分，也就是说LLM需要评估所有可用的信息，然后决定：我需要采取哪些步骤？当前我应该采取的第一步是什么？

在每一次输入大模型上下文有限的情况下，怎么保证每一次输入都能是最好的输出，怎么让agent知道用户的需求市面哪个工具是最佳解决方案，怎么去找到这些工具，也是一个至关重要的部分。

四、从上下文工程到Agent工程

在构建 LLM 应用程序时，我们需要管理哪些类型的上下文？上下文工程作为适用于几种不同上下文类型：

• 指令说明：系统提示词、 few‑shot示例、工具描述等
• 知识 ：事实、记忆等
• 工具 ：来自工具调用的反馈，更多是让LLM感知更多环境，比如browse_use（最终也是把环境转为上下文的形式）

长时间运行的任务和工具调用的累积反馈意味着Agent经常使用大量token，会导致许多问题：它可能会超出上下文窗口大小、token成本/延迟或降低Agent性能。在一篇文章中Drew Breunig 很好概述了较长上下文可能导致执行问题的许多具体方式，包括：

• 语境中毒：当幻觉进入语境时
• 上下文分散注意力：当上下文压倒了培训时
• 上下文混淆：当多余的上下文影响响应时
• 上下文冲突：当上下文的某些部分不一致时

上下文工程作为今年的核心，以下是lanchain官方中分享的一些关于上下文工程比较好的策略，可以参考：

Agent经常进行跨越数百个回合的对话，需要仔细的上下文管理策略。我们将Agent上下文工程的常见策略分为四个部分—— 写入、选择、压缩和隔离

Write Context：编写上下文意味着将其保存在上下文窗口之外，以帮助Agent执行任务。

• Scratchpads ：当人类解决任务时，我们会做笔记并记住未来相关任务。Agent也正在获得这些功能！通过“ 暂存器 ”记笔记是在Agent执行任务时保留信息的一种方法。这个想法是将信息保存在上下文窗口之外，以便Agent可以使用它。暂存器可以通过几种不同的方式实现。它们可以是简单地写入文件的工具调用。它们也可以是运行时状态对象中的字段，在会话期间保留。无论哪种情况，暂存器都可以让Agent保存有用的信息以帮助他们完成任务。
• Memories：暂存本帮助Agent解决给定会话（或线程 ）中的任务，但有时Agent会从记住多个会话中的事情中受益！ 反射引入了在每次Agent回合后进行反思并重复使用这些自我生成的记忆的想法。 生成智能体创建了从过去智能体反馈的集合中定期合成的记忆。

Select Context：选择上下文意味着将其拉入上下文窗口以帮助Agent执行任务。

• Scratchpads ：从暂存器中选择上下文的机制取决于暂存器的实现方式。如果它是一个工具 ，那么Agent可以通过进行工具调用来简单地读取它。如果它是Agent运行时状态的一部分，则开发人员可以选择在每个步骤中向Agent公开哪些状态部分。这为在以后的回合中向 LLM 公开暂存器上下文提供了细粒度的控制级别。
• Memories：如果Agent有能力保存记忆，他们还需要能够选择与他们正在执行的任务相关的记忆。这可能很有用，原因有几个。Agent可能会选择少量示例（ 情景记忆 ）作为所需行为的示例，选择指令（ 程序记忆 ）来引导行为，或选择事实（ 语义记忆 ）作为任务相关上下文。

• Tools：Agent使用工具，但如果为他们提供过多的工具，可能会变得过载。这通常是因为工具描述重叠，导致模型对使用哪个工具感到困惑。一种方法是将 RAG（检索增强生成）应用于工具描述 ，以便仅获取与任务最相关的工具。最近的一些论文表明，这可以将刀具选择的准确性提高 3 倍。
• Knowledge：RAG 是一个丰富的主题， 它可能是一个核心的上下文工程挑战 。代码Agent是大规模生产中 RAG 的一些最佳示例。Windsurf 的 Varun 很好地抓住了其中一些挑战：

Compressing Context：压缩上下文涉及仅保留执行任务所需的令牌

• Context Summarization：座席交互可以跨越数百个回合 ，并使用令牌密集型工具调用。摘要是管理这些挑战的一种常见方法。如果您使用过 Claude Code，您就会看到这一点。Claude Code 在您超过 95% 的上下文窗口后运行“ 自动压缩 ”，它将总结用户与Agent交互的完整轨迹。这种跨Agent轨迹的压缩可以使用各种策略，例如递归或分层摘要。

• Context Trimming：摘要通常使用 LLM 来提炼最相关的上下文片段，而修剪通常可以过滤，或者正如 Drew Breunig 指出的那样，“ 修剪 ”上下文。这可以使用硬编码启发式方法，例如从列表中删除较旧的消息 。Drew 还提到了普罗旺斯，一个训练有素的问答上下文修枝剪。

Isolating Context ：隔离上下文涉及将其拆分以帮助Agent执行任务

• Multi-agent：隔离上下文的最流行方法之一是将其拆分为子Agent。OpenAI Swarm 库的动机是关注点分离 ，Agent团队可以处理特定的子任务。每个Agent都有一组特定的工具、说明和自己的上下文窗口。Anthropic 的多智能体研究人员对此提出了一个理由：许多具有隔离上下文的智能体的性能优于单智能体，这主要是因为每个子智能体上下文窗口都可以分配给更窄的子任务。正如博客所说：
• Context Isolation with Environments：HuggingFace 的深入研究者展示了上下文隔离的另一个有趣的例子。大多数Agent使用工具调用 API，它返回 JSON 对象（工具参数），这些对象可以传递给工具（例如搜索 API）以获取工具反馈（例如搜索结果）。HuggingFace 使用 CodeAgent，该 CodeAgent 输出包含所需工具调用的输出。然后，代码在沙盒中运行。然后，从工具调用中选定的上下文（例如，返回值）被传递回 LLM。
• State：值得指出的是，Agent的运行时状态对象也可以是隔离上下文的好方法。这可以起到与沙盒相同的作用。状态对象可以使用具有可以写入上下文的字段的架构来设计。模式的一个字段（ 例如消息） 可以在Agent的每个回合向 LLM 公开，但模式可以隔离其他字段中的信息，以便更有选择性地使用。

随着Agent的不断发展，目前的趋势看来，如果需要为每个agent都配一台电脑，当 Agent 的能力从对话扩展到如编写代码、分析数据、生成文件时，我们实际上是在为每个 Agent 分配一台“云端电脑”。当前01Agent也为每个用户的专属Agent配置了一台云端电脑。这标志着开发重点从单一的Prompt/Context 工程转移到了全栈Agent基础设施工程的构建。

这一阶段的挑战和工程重点主要体现在以下三个维度：

1.Sandbox基础设施的构建与编排

如果说上下文工程解决的是“大脑”怎么思考的问题，那么沙箱工程解决的就是“双手”在何处工作的问题。

环境隔离与安全性：当 Agent 执行 Python 代码或 Shell 命令时，必须在严格隔离的沙箱中运行，以防止对主机造成安全威胁（如 rm -rf / 这种容易造成安全事故的指令）。

• 环境一致性Agent 需要预装特定的依赖库。如何快速启动一个带有特定环境的“电脑”，成为了工程难题。
• 冷启动与延迟为每个任务瞬间启动一个虚拟机是有延迟的。Agent 工程需要通过热池或快照技术来最小化 Agent 启动时间，保证用户体验的流畅性。

在上下文窗口之外，文件系统是 Agent 最重要的“外挂硬盘”。

生成文件的生命周期管理：Agent 在执行任务过程中会产生大量中间文件（图片、代码文件、Pdf等）。如何存储这些文件？何时清理？如何让用户下载？这涉及到底层的对象存储与临时文件系统的协同。

持久化工作区：对于长时间运行的任务，Agent 需要一个持久的“工作台”。即使用户关闭了浏览器，Agent 所在的环境状态和文件也应该被保留，以便下次唤醒时能“接上断点”继续工作。比如01Agent关于用户浏览器cookie数据的持久化管理，方便用户下次执行相关任务不再需要登录，这实际上是在构建一个云端的 OS 文件管理系统。

3.成本控制与资源调度

“给每个 Agent 配一台电脑”意味着计算成本的指数级上升。

Token 成本 vs. 计算成本：以前主要关注 LLM 的 Token 消耗，现在必须关注sandbox的运行时间。长时间运行的 Agent会带来成本上更大的消耗。

• Serverless Agent 架构为了降低成本，Agent 工程趋势向 Serverless 靠拢——即“用完即走”。当 Agent 等待 LLM 思考时，暂停计算资源；当 Agent 执行代码时，毫秒级唤醒计算资源。这种精细化的调度是控制大规模 Agent 部署成本的关键。

在 Agent 工程中，“记忆”不再仅仅是塞进 Prompt 里的文字片段，而是变成了结构化的数据库系统。

记忆的存储层：短期记忆可能在内存或 Redis 中，长期记忆（如用户偏好、历史任务结果）则需要存入向量或图数据库。目前这一过程也是最容易被忽视的，但非常重要。

索引与检索：在工程层面，这意味着需要构建高效的检索引擎，无论是memory还是SKills，让 Agent 能够像访问硬盘一样，快速从海量历史数据中提取关键信息，而无需依赖昂贵的上下文窗口。

随着 Agent 的进化，上下文工程正在成为Agent 工程的一个子集。上下文工程 关注的是如何最优化 LLM 的输入输出，Agent 工程则关注的是如何构建一个稳定、安全、低成本的Agent计算机系统，让这个“大脑”能够真正地在数字世界中通过使用工具产生实际价值。这标志着我们从单纯的“调优模型”时代，正式迈入了“构建智能体操作系统”的软件工程深水区。

五、Agent 落地的关键还是在于交付

Agent 关键还是在于交付率，交付率高了用户自然愿意付费。相比于通用Agent，coding Agent场景为什么交付率那么高，关键是满足三个条件任务明确，场景封闭，结果可验证。

1. 1.任务明确：指的是Agent 需要解决的问题或执行的操作是具体、清晰且定义良好的；Coding Agent 用户提出的需求通常是直接的编程任务，比如修改这个bug，很少有直接生成xxxapp。相比于开放域的对话或任务（如“帮我生成一个xxx旅游攻略”），Coding任务的目标和成功标准通常更少歧义，也更方便于验证。
3. 2.场景封闭：Agent 的操作环境是受限的、边界清晰的。它主要在集成开发环境内部工作，与代码文件、项目结构等直接相关的元素交互。场景封闭的优势关键在于能获取尽可能丰富的上下文信息（代码，报错信息等），以及coding场景的规则相对固定，代码等语法规则相对固定，重要的是这些LLM都擅长理解。
5. 3.结果可验证：生成的代码可以立即编译、运行进行验证。运行成功还是报错一下就验证了。这种即时、客观的反馈循环极大地促进了 Agent 的成功。但类似旅游攻略，报告这种人为主观的验证，多多少少会增加结果可验证的不确定性。如何量化一个结果的验证机制至关重要。

对于像 Cursor 这样的Coding Agent，“任务明确”意味着它处理的是具体的、可定义的编码问题；“场景封闭”意味着它在 IDE 这个边界清晰、信息结构化、规则相对固定的环境中工作。这两个特性极大地缩小了问题域，让大模型能够高度聚焦其能力，特别是Claude这种擅长Coding以及支持长上下文的LLM，其充分利用可获取的精确上下文信息，并产生易于验证的结果，克服了通用Agent 常面临的模糊性、复杂性和难以验证的问题，最终实现了高交付率。也正是因为Agent执行任务高的交付率，解决了用户实质问题，用户觉得它有价值从而愿意付费。目前01Agent刚上线不到一周时间，大量的付费用户也一定程度证明了这一点：用户只为Agent交付的结果是否满意而决定是否买单。

六、数据资产与memory才是真正的护城河

如果说高交付率是 Agent 产品的敲门砖，那么用户数据沉淀与个性化记忆则是真正的护城河。随着 LLM 本身日益成为一种水电般的基础设施，不同 Agent 产品在模型能力上的差距终将缩小。在 2026 年，区分一个 Agent 是否具备不可替代性的核心，将取决于它有多懂它的用户。

1. 1.资产沉淀：从一次性交互到长期资产积累

在过去，我们使用工具产生的数据往往是割裂的。但在 Agent 时代，用户在使用过程中产生的所有交互、创作的内容（无论是文章还是海报），都不应仅仅是历史记录，而应转化为用户的数字资产。 以01Agent的内容创作为例，01Agent 不仅是在帮用户写一篇文章，设计一个海报，这些都可以作为你日后不断累积的数字资产，甚至是可以进行变现的资产。这种资产的沉淀，使得迁移成本变得极高——用户无法轻易离开一个已经存储了他们大量作品的系统。

1. 2.个性化与默契：打造“最懂你”的超级助手

通用 Agent 往往给人一种“千人一面”的感觉。但真正的超级助手，应该具备深度的个性化能力。这种个性化不仅仅是记住你的名字，而是基于长期记忆形成的默契。这种默契体现在 Agent 能够预判你的需求。例如，在创作场景中，一个懂你的 Agent 不需要你每次都提示“请使用xxx风格”，因为它从你过去修改的内容中已经学到了这些偏好。随着数据的不断沉淀，Agent 的每一次输出都更贴合用户的心意，从而形成一个正向的数据飞轮：

Agent 越懂用户 -> 用户体验越好 -> 用户使用频率越高 -> 沉淀数据越多 -> Agent 越懂用户

1. 3.信任阶梯：建立社会化关系 Agent 的终极形态，是与用户建立起一种类社会的信任关系。

用户对 Agent 的信任通常经历三个阶段：

• 怀疑期： 用户尝试性使用，不仅要检查结果，还要像防贼一样盯着每一步操作（如早期的 AI coding）。
• 验证期： 用户发现 Agent 在特定领域非常靠谱，开始在这些垂类任务上放权，但核心决策仍需人工介入。
• 依赖期： 当 Agent 通过长期的个性化服务证明了自己的稳定性后，用户开始产生绝对信任。

这种信任关系一旦建立，就是最高的壁垒。就像现实生活中，你可能因为哪个工具好用就换哪一个工具，但你很难因为好用一点就换掉一个跟随你十年、这懂你每一个眼神含义的助理。未来的 Agent 产品，竞争的不再是谁的模型参数更大，而是谁能更快地攀爬上用户的信任阶梯，成为用户数字生命中不可或缺的伙伴。

回顾 2025，这是 AI Agent 从玩具走向工具的关键一年。我们见证了从提示词工程到上下文工程的范式转移，也深刻体会到了 MCP、Skills 以及上下文工程在提升交付率中的决定性作用。

但正如我在文中提到的，技术的演进终将拉平模型能力的差距。当所有的 Agent 都拥有了类似的“手脚”（Tools）和“大脑”（LLM）时，2026 年真正的爆发机会，将属于那些能够构建扎实Agent工程以及信任壁垒的产品，2026年的01Agent也将重点朝着这个方向去努力。

Coding Agent 的成功不仅仅是因为它写代码快，更因为它通过每一次成功的编译、每一次精准的修复，建立起了用户敢于放手让它去干的信任。这种信任，建立在极高的交付率之上，固化在用户沉淀的私有数据与 Skills 之中。

未来的 Agent 竞争，不再是单纯的算力比拼，而是一场关于谁更懂用户的竞赛。2026 年，能够爆发的 Agent，一定不是那个声称无所不能的通用天才，而是那个在特定领域里，有着极高业务 Know-how，能像老伙计一样理解你、预判你，并稳定交付结果的Agent。

Agent 的探索之路注定不是一条直线。但幸运的是，我们已经走过了盲目狂热的阶段，正脚踏实地地迈向深水区。2026，愿我们都能打造出那个真正从0到1能真正落地交付的Agent。

2026，我们不再需要向世界证明“Agent 能做什么”，而是直接用一个 Case 告诉用户“Agent 能为你解决什么”。从连接万物回归到精准交付，从炫技工具进化为可信赖的伙伴，这不仅是技术的螺旋上升，更是 AI Agent 从0到1真正走向成熟的必经之路。

让我们在 2026 年，继续在实战中寻找答案。