本文作者主要阐述为什么大家认为 Agent 模式会在 2025 年开始爆发，我们有了哪些进步，我们又面临了哪些挑战。
随着人工智能、机器学习和自然语言处理等技术的飞速发展，Agent 技术已经从理论研究走向实际应用，展现出巨大的潜力和价值。
尽管我们负责的 AI Coding 产品 Aone Copilot 在阿里集团被广泛的使用，也在每个阶段使用 AI 做了许多的探索，但长期以来我对大模型能解决复杂问题长期以来都持怀疑态度，所以我们迟迟没有动手去做 Agent 产品。
一方面原因是当时我认为模型能力不够，基于概率的模型推理能力上存在天然缺陷，另一方面是业务逻辑的复杂性，让模型很难理解真实世界是如何运转的。
此前，我也分享过我对 Agent 的三种模式的思考，我认为 Agent 会经历三个模式：局部自动化，广泛自动化，和极端自动化，通过泛化程度对 Agent 能完成什么任务做划分，后面演化出仓库级别生成单测这种简单工作流模式，Extensions 这种与模型一起驱动的模式，在集团内都有不小的应用，也遇到了不少问题。
彼时的我对于如何实现极端自动化并没有清晰的答案，主要是我没有理清一些关键问题应当如何解决，但随着多模态模型的能力，以及 Resoning 模型能力的逐步强化，我认为我们可能来到了从“人驱动”到“模型驱动”的关键节点，通过这篇文章我会阐述为什么大家认为 Agent 模式会在 2025 年开始爆发，我们有了哪些进步，我们又面临了哪些挑战。
模型技术的进步推动了产品的进步
推理能力的进步更能理解用户的需求
去年下半年，尤其是以 O1 和 DeepSeek 为代表的模型在Resoning 模型的进步，基本打消了大家对模型推理能力的疑虑，模型开始变得越来越理解用户的需求是什么。以 Resoning 模型为代表，我们再也不需要在Prompt的设计上再大费周章，也不需要为Prompt的组装顺序那么在意，他就能更加深层次的理解用户在说什么，甚至在用户给出一个错误的问题时也能帮助纠正。
推理能力的进步使得我们在给定任务的时候不用告诉模型应该如何做和如何思考，它具备往往能帮助用户一次性的把事情做好，尤其是在需求理解层面能达到人类的水准，甚至能探查出人没有表达出来的意思。
多模态模型能力的进步，让模型能理解图片和架构，让许多之前不敢想象的场景成为现实
长期以来，我们总是认为数据很重要，尤其是散落在文档中的领域知识，所以我们会花很大的精力去总结文档，但总是容易遇到一个容易被忽视的问题，就是如何处理文档中的图片，过去的做法是，选择性的将图片保留成一个个链接切片再存储到Embedding数据库里。
但问题是，图片和文字都是穿插在一起的，不应该轻易的放弃文档中的图，图片中往往藏着领域架构，系统架构，演示，页面指引等。有时候模型要充分理解你的领域知识和文档，需要结合图和文字一起来看。
而随着模型能力的进步，大模型在理解图片有了很大的进步，即使是非常复杂的架构图也能抓出重要信息。
借助多模态模型，我们在处理领域知识时拥有了更多选择：可以将图片与文字整合处理，在检索增强生成（RAG）中同时召回图文信息，或者在生成摘要时让模型综合理解图像与文本内容。。
多模态模型的另一个重要价值在于能够帮助业务系统更准确地理解用户所处场景。在构建答疑系统时，我们经常面临一个挑战：难以确切了解用户当前所处的具体环境以及遇到的具体问题。例如，我们往往不清楚用户在哪个网页上遇到了什么类型的错误提示。因此，传统答疑系统常常需要通过猜测或要求用户填写表单来获取关键信息。
下图直观展现了在搭建答疑系统过程中遇到的这一典型问题。
过去，理解用户在业务系统中遇到的问题主要有两种方法：一是将当前网页链接提供给大模型分析。然而，这种方法存在明显缺陷——网页链接信息单一，且大量通过异步加载的内容使模型难以准确把握用户实际看到的信息。二是在业务系统中部署大量日志记录点，试图串联起用户的完整行为链路，从而帮助答疑系统理解用户当前处境。但这种方法不仅局限性较大，还需要对系统进行大量改造才能实现。
随着多模态模型能力的发展，这一难题可能有了更为优雅的解决方案。通过直接分析浏览器页面截图，模型可以绕过复杂的日志系统，直观理解用户可能面临的问题。这种方式免去了耗时费力地挖掘"用户在什么处境下遇到问题"这一关键信息的过程。
值得注意的是，人类日常接收的大量信息实际上是以图像而非纯文本形式呈现的。许多系统之所以设计精美，正是为了增强人类的理解和阅读体验。长期以来，这部分图像信息在模型理解中往往缺失，导致我们在处理复杂业务场景时的效果不尽如人意。多模态模型的发展有望显著改善这一状况，为业务系统的智能化提供新的可能。
代码能力的进步，让模型端到端的从图片生成代码
虽然代码能力是个老生常谈的话题，几乎每个新模型发布时都会强调其编程表现，但这半年来真正令我震撼的，却是模型在图片复刻方面的出色能力，以及它持续稳定地输出长篇内容的优异表现。
左边是原图，右边是一句 promot 生成的1比1复刻的图，还原度很高。
另外一些SVG图片也能直接通过Prompt很好的生成：
一次性生成代码的能力增强，甚至在前端代码场景下，一次生成上千行的代码而不会有任何语法问题，这极大的提升了从创意从0到1的效率。
模型更能理解自己的局限性，并用更合理的方式去解决它不能解决的问题
在解决问题时，模型对自身能力边界的认知程度直接影响其处理复杂问题的能力。这是因为，当模型无法准确评估自身局限时，往往会依赖概率预测结果，导致看似合理实则错误的输出。我们可以通过一个简单案例来对比不同模型在此问题上的表现差异。
询问GPT-4o 一亿以内最大的质数这个问题，它没有经过思考直接给出的是一个错误数字
但如果我问Claude 3.7 一个更复杂的数字2313133123113 ，他直接给出了无法计算，并给出了正确的Python脚本
能够认识到自身在特定领域的不足，并采取恰当的应对策略，这种能力是一项重大突破。试想，若缺乏这种自我认知能力，在处理复杂的多步骤问题时，错误便会层层累积。模型可能会陷入错误的结论中，却始终无法意识到问题所在，这无疑为解决更复杂问题设置了障碍。
产品的进步也推动了理论的进步
去年下半年以来， Cursor 经历了迅猛的增长。然而，在我看来，Devin 是一款更具革命性的产品：Cursor 创新了 IDE 领域，而 Devin 则引领了 Agent 领域的变革。作为首个具体化且功能广泛化的 Agent 产品，尽管 Devin 主打开发辅助（ Dev ），但在许多其他任务中它同样表现优异，尤其是在技术和市场研究方面。这些产品的进步不仅提升了各自的性能，还推动了 Agent 理论层面的发展。
Devin 开创了通用 Agent 时代
在 Devin 之前，大多数人提及的 Agent 主要在单一工作流中运用大型模型来解决特定的问题，例如进行某种判断或调用某个 Function Call 等等，这并未充分发挥模型的全部价值与潜能。而自 Devin 以来，人们开始深刻理解了“模型驱动”的真正意义。
Devin 通过模型驱动能够自主地进行规划任务、反思、使用工具、联网等活动。它具备异步任务自动搜索与执行的功能，从而解决了许多困扰业界的问题
长上下文的记忆压缩与记忆提取，这是目前在模型 context 长度受限情况下的唯一解决方案
规划与重新规划，它会在任务执行过程中不断调整自己的计划
自我总结与学习反思，这意味着它初步具备了规模效应，解决问题越多就越聪明，也越实用
在独立环境中联网或使用工具，甚至是安装新工具的能力
因为他解决了众多问题，并且是首个具体诠释 "Planning Pattern" 的产品。尽管每月 500 美元的订阅费用让许多人望而却步，但这并不能掩盖他在能力上的卓越之处。随后的所有产品，无论是 Manus 还是其他，都在某种程度上借鉴了他的理念。由于他的操作流程是从制定计划开始，然后再进行实施，因此这种代理模式也被称作“Planning Pattern”类型的代理。
此外， Devin 希望用户把他当作一个实习生来使用。用户可以异步地将一些复杂的任务交给他执行，因此我们也将其称为“异步 Agent”。同时，因为他并未限制自己只从事特定的任务，所以我们同样称他为“通用 Agent”。
另外，既然我们可以异步地将任务交给 Agent 执行，理论上人们无需时刻监督他的工作。若这样的 Agent 数量充足，人们只需负责分配任务并准备验收结果，这可能释放出人类“十倍”的潜能。因此，我们认为这种模式能够实现效率提升十倍的 Agent。
Cursor 和 Cline 共同开创了本地IDE上的 Agent 模式
Cursor 和 WindSuf 在产品上进行了诸多创新，包括 "Apply" 和多行编辑补全功能，这些都给人留下了深刻的印象。然而，给我留下最深印象的是他们在本地 IDE 中的 Agent 模式。
当用户提出一个需求时，Agent 会根据其对仓库的索引和理解自行修改代码，甚至可以执行命令来完成任务，这是以前难以想象的功能。过去，我们对大型模型的能力持怀疑态度，担心它们可能会生成一些不安全的命令，从而破坏用户的环境或错误地删除不应删除的本地文件等。
而 Cursor 很好地解决了在执行过程中用户的信任问题，因为它会告知执行的步骤、如何修改文件以及使用了哪些工具等。Cursor 的设计理念与 Devin 不同，它是先收集信息，然后执行任务，在接收到反馈后，通过数据反馈不断优化其执行路径，这是一种代理（Agent）模式。
我们称他为 “Reflection Pattern”的Agent，它不会先生成计划，它需要和人同步协作的Agent，在我们内部叫它“同步Agent”。
从本地 IDE 的角度看，衡量一个 Agent 的效果好坏，主要依赖于多个因素。一方面，这包括模型能力的强弱；另一方面，则是我们本地 IDE 上搜索功能的有效性。在本地 IDE 中，我们可以最大程度地利用本地资源，特别是 IDE 本身的强大功能，从而能够更好地处理一些先前难以解决的工程上下文问题。例如，可以直接通过本地 IDE 对外暴露的 API 向模型提供函数或类的定义、跳转，甚至是调用链路。
因为有了这些改进，我们可以将原本在服务器端难以处理的情景转移到本地进行优化，如在本地执行代码审查、查找代码缺陷等任务。这样一来，在编码阶段就能发现并修正代码中的缺陷和问题，用户不仅更愿意进行修复，而且修复的成本也将大大降低。这是一个值得探索的方向。
不同的场景导致了两种Agent模式在技术上的不同选择
两种 Agent 模式的实现存在差异，原因多种多样：
通用 Agent 需要具备独立的云端运行环境，而本地 Agent 则部署于本地 IDE 中，因此它们所采用的工具不尽相同。
本地 Agent 由于需与人类操作同步，故重视执行效率，力求迅速向用户提供反馈，并尽快完成交付。
相比之下，通用 Agent 可以支持异步交付，对延迟的要求不那么严格，其流程可被分解得更为细致，能够调用更多工具进行多次验证以获取中间结论。同时，鉴于它是异步交付，必须确保一定水平的交付质量，因而需要尽量考虑周全后再执行。
本地 Agent 的产品与 IDE 紧密结合，这意味着其任务不会无限制地扩展，相对而言较为简化。
通用 Agent 使用的工具种类不受限，而本地 IDE 中的 Agent 由于受限于 PC 设备，任意安装新工具可能会引发用户关于隐私或安全性的担忧。
作为异步模式的一部分，通用 Agent 必须达到一定程度的确定性，在执行过程中不断自我反省和总结，这会带来执行效率的降低。
但通用Agent 会遇到一些挑战。
通用 Agent 实施上会遇到的挑战
尽管我们现在可以看到市场上有很多标榜为通用 Agent 的产品，但实际上能够处理通用或复杂任务的并不多。这些产品要么不够通用，要么无法应对复杂的任务。我认为这主要是由于工程和技术模型两个方面所面临的挑战。
通用 Agent 在工程上的挑战
Agent 的大脑如何构建
其实当初我们看到 Devin 时，我们首先想到的是 Web IDE 的架构。我们认为，在浏览器中开启的任务应当由后台的一个独立容器来处理。这一想法立即让我联想到了 Web IDE 的架构。
具体任务在一个环境中执行。在这个环境中，有一个“大脑”负责知识的引入、工具的使用、知识的压缩以及模型的驱动。“大脑”的重要性体现在以下几个方面：
它具备任务规划与执行能力，可以被视为通用 Agent 的 '大脑'，负责管理整个任务流程，将复杂的任务分解成可以由子 Agent 执行的小任务。
它能够进行反思和重新规划。有时，某种实现方案可能走入死胡同，或模型坚持一条走不通的道路，“大脑”需识别这些问题并重新规划其他路径。
它能够识别并选择使用各种工具，例如通过浏览器打开网页、操作终端、文件的创建、删除、编辑等，以及在线搜索等。
它具有识别、正确压缩记忆、引入新知识及学习的能力，如将先前成功完成的任务归纳为经验，在面对类似任务时再次应用这些经验。
内置 IDE 功能通常也是必要的，这使得用户可以在 Agent 中调整生成内容的信息，尽管这不是强制性的要求。
并行处理子任务，通用 Agent 可以同时运行多个子任务，从而加速任务的完成。
如何评估通用 Agent
通用 Agent 的性能受到 Engine、模型、各种 Prompt、工具筛选等方面的影响。在评估时，对于那些不确定性强的内容，我们需要进行模拟，并通过控制变量的方法找出关键的优化点。因此，建立一个能够发现实现使用环境中问题的环境变得很重要只有通过评测我们才能明确改进的方向。
过去，在大规模模型的训练和评估中，通常采用的是以 Query 和 Answer 为核心的评价方式。
这种评测集的特点通常是易于实施和评估的，比如 Pass @ 1 或者 EM、ES 等评估策略，通常是一组标准化的测试数据（输入-输出对），用于量化模型在特定任务上的表现。其目的在于提供统一的评估标准，以便横向比较不同模型的能力（如准确性、稳健性和泛化能力）。例如 GLUE（自然语言理解）、MMLU（多学科知识）、HumanEval（代码生成）等。有些评测集，如 SWE-Bench，则设置了若干实际世界中的编程问题供智能体解决。
然而，这类评测集仅能用于评估与编码相关的智能体能力，而无法全面反映通用型智能体的综合能力。因为在很多情况下，仅仅评估最终结果并不合理，因为智能体产生的输出往往不是标准化的，例如在一个需求调研任务中，我们难以通过产出直接判断智能体的质量，或这种评价本身就是主观的。此外，评测的另一目的还在于优化整体设计架构，单纯的结果评估很难揭示问题究竟出现在规划阶段、记忆阶段还是工具选择阶段。
当然，评估过程本身也充满挑战，因为智能体的执行过程是动态变化的，由模型驱动，每次生成的计划不尽相同，所用工具也可能有所差异，因此严格对比变得困难。即便我们尝试评估过程细节，比如具体进行了哪些规划步骤，使用了多少步骤，这些数据的具体意义仍不易解释清楚。因此，针对通用型智能体产品的评测是一项行业难题，或许需要引入人工评估的方式，甚至为展示其通用性，还需构建多种突发场景来考察其应对能力，这些都是需要考虑的因素。
如何解决处理长步骤下的记忆问题
人在面对复杂问题时，尽管也是逐步推进，但在每完成一步后，往往会无意识地对信息进行压缩处理。例如，在理解一段复杂的代码逻辑时，你不必记住读过的每一个字符；相反，你会大致掌握其内容，然后转向其他文件。这样，你就能够持续处理新任务。当后续任务需要之前的具体信息时，再回过头来查阅细节。这就是人类如何通过信息压缩与提取来管理信息的方式，这一能力同样适用于 Agent。
Agent 的记忆机制分为两类：短期记忆和长期记忆，它们分别应对不同的需求。
在处理复杂任务时，由于模型的上下文长度受限，即便未来模型的上下文容量得以扩展，仍需依赖信息压缩功能。过多的信息可能会导致关键点被忽略，因此短期记忆中的信息压缩有助于提炼出核心要点。Devin 产品的界面设计体现了这种压缩能力，即在每个步骤完成后展示压缩后的记忆摘要，而不是详尽记录每项操作，以便为后续步骤提供概要参考。
但是，单纯地通过压缩也有其局限性，因为模型压缩可能会忽视某些对复杂任务至关重要的细节信息，例如我们在测试的时候发现 Agent 生成一组用户名和密码，然后转头就忘了，这就考验了解决问题的工程技术能力。
如前所述，通用 Agent 应该拥有反思与学习总结的能力，这也是模型与 Agent 之间的区别之一。Agent 在学习过程中不断进步，并掌握处理新任务的方法，因此 Agent 或许具有规模效应——使用者越多，它就越智能。这种能力的具体表现就是“长期记忆”。每当用户完成一项任务后，我们可以让模型整理出一份可供日后参考的经验数据。这样，在 Agent 遇到新问题时，可以调取这些经验来指导模型如何应对，从而实现了某种形式的长期记忆。Devin 则是通过 Knowledge 的方式来进行存储，例如，在执行某项任务的过程中，通过对模型输出进行校正，生成了一份可利用的知识。
不过，这种处理方式仍然显得相当粗犷。主要是因为，一种知识在一个特定情境中可能非常有效，但在另一个情境下却未必如此。例如，牛顿力学在宏观和低速的世界里表现得极为出色，然而当速度接近光速时便不再适用；同样地，抗生素能够有效地杀死细菌，但对于病毒则无能为力。因此，将成功的经验固化为固定的“Agent 心智”，实际上也限制了模型的能力。如何根据具体的情境来甄别并利用这些经验，并且恰当地掌握这一平衡点，本身就是一项重大的技术挑战。
模型的挑战
工程上的挑战其实还是能够克服的，毕竟有大量可借鉴的产品，我们也可以通过各种方法和产品手段来避免一些问题。然而，对于“模型驱动”的Agent产品来说，模型能力方面的挑战更为艰巨。当前，几乎所有开发通用Agent产品的公司都将 Claude Sonnet 视为首选模型，因为除此之外，其他模型都无法很好地推动复杂任务的解决，模型能力的欠缺是我们比较担心的问题。
模型的指令跟随能力不足
复杂的任务之所以复杂，在于判断与限制条件多，约束多，对模型的要求也随之增多，通常会组合成一个极其复杂的 Prompt，模型能遵循的指令越多，它能处理的问题就越复杂。然而，除 Claude 系列外，其他模型往往难以达到这一标准。
部分模型存在不遵循指令的情况，而且非常普遍，例如我明确告诉他不要转义
但代码还是转义了
模型的长上下文能力
主要体现为当噪音信息变多时，找到关键信息、理解能力会变弱。
某模型放入过多额外信息时生成的流程图，可以看到许多中间步骤被模型忽略了
某模型仅保留关键信息时生成的流程图，如果去除掉一些细节信息，模型就能找出更完整的链路。
复杂的任务之所以显得复杂，要么是因为其上下文本身就很长，例如 代码，或者在执行长步骤任务时，需要记忆更多上下文信息。对于复杂任务，特别是涉及几十甚至上百步的任务而言，把握住长上下文中关键的信息至关重要。
模型的推理规划和反思能力
推理与规划能力是通用 Agent 解决复杂问题的关键。这种能力使得智能体能够分析问题、制定解决方案的步骤，并在执行过程中进行调整。Devin 在产品上会先为任务制定一个计划，然后向用户展示执行规划的步骤。
而在我们执行任务的过程中遇到变化时， Devin 会调整他的计划。这与人类相似，在完成一项复杂的任务时，人们通常也无法一开始就制定出一个完美的计划，而是会在实施过程中不断进行调整。
这个图反应了，Agent 存在的挑战不仅仅是一次性就把事情做好，而是在一个长链路任务下需要具备反思和的能力
Agent 难以从错误的长轨迹中恢复（Difficult to recovery in long trajectory）
在任务执行过程中，智能体可能选择了错误的动作序列，导致偏离正确轨迹
智能体需要回顾并修正之前的错误动作，以完成任务
图中左侧展示了智能体在错误轨迹中浪费时间（例如开错门、走错路径），最终未能获得奖励
Agent 也容易陷入局部循环（Stuck into Loops）
智能体可能在某些状态中反复执行相同的动作，陷入局部循环，无法探索新的可能性
图中右侧展示了智能体重复执行“打开厨房门”的动作，未能有效推进任务
智能体需要跳出局部循环，探索更多可能的动作以完成任务
问题会随着开源模型的进步而消失吗
在之前，训练过程中通过计算 Loss 来降低梯度，从而提升模型效果。这种点对点的模型能力提升，在过去的打榜或 ChatBot 等产品形态中确实取得了巨大成功。然而，在 Agent 场景下，以往极致地优化局部最优解并不一定能成为全局最优解。例如，一个多步骤任务从 a 到 b 再到 c 和 d，虽然每一步都是最优的，但对于整个任务而言，a 直接到 d 可能才是最优路径。过去的经验表明，无论国外模型发布何种新功能，国内的开源模型总能迅速跟进，这一次是否依然能够顺利实现呢？
另一个问题是，Claude 作为一个断档级别的存在，其优秀之处远不止于编写代码的能力，它在几乎所有能力上都处于领先地位。近期与许多同行交流后发现，大家似乎尚未充分认识到这一点，在如何使我们的模型在指令遵循、长上下文理解、规划及反思等方面达到 Agent 能使用的水平的问题上毫无头绪。究竟是由于其基础能力强大且数据质量较高所致，还是采用了某些特殊的训练方法或标注手段使其具备如此强大，目前外界对此一无所知。要知道，Claude 3.5 Sonnet 已经是在去年六月发布的，这是令人比较担心的。
我们最近也在与其他算法团队进行沟通，希望能够尽快提升模型性能，包括建立适用于 Agent 任务的评估体系，以及创建能够让 Agent 运行的模拟环境等措施，以期帮助算法团队更快地缩短与 Claude 之间的差距，并推动国内尽快实现真正具备 Agent 能力的大模型。
通用 Agent 会被因为模型能力的增强失去价值吗
最近有一种观点认为，Agent 会被模型取代，认为“模型即应用”。但我的判断是：通用 Agent 并不会被取代。通用 Agent 与模型之间是一种共生的关系——Agent 像为模型这个“大脑”装上了“手脚”，赋予了它行动（Action）的能力。只要保持 Agent 架构的简洁性，并且不通过流程编排来限制模型的能力，Agent 就能够随着模型能力的提升变得更加强大和通用。实际上，Agent 会直接受益于模型泛化能力的提高。
目前，模型的结构和推理能力存在着固有的局限，而 Agent 正好可以帮助模型应对环境感知、记忆存储以及工具使用等一系列系统性的问题。“大脑”般的模型自身无法长出手脚去采取行动，通用 Agent 实质上就是一个为模型装备行动器官的技术解决方案。
甚至通用 Agent 还可能会产生规模效应，通过工程技术让模型具备持续反思和学习的能力，而这正是现有模型结构所无法实现的。
然而，随着模型能力的不断提升，那些以工作流（Workflow）为核心的专业 Agent 确实有可能被淘汰。因为现在许多专为人工编排设计的功能，在将来很可能可以由模型自动完成。这种更高层次的自动化编排能力，将会使某些专业 Agent 失去存在的意义。
