25年什么样的 Agent 会脱颖而出：简单胜于复杂

        
        
            

          知乎：https://zhuanlan.zhihu.com/p/29553001484 
          
   

 
        
      

2025年被视为AI Agent元年，多家科技巨头已明确表态：

• OpenAI CEO奥特曼预测：https://blog.samaltman.com/reflections
• 微软在2025年AI六大趋势中强调：https://news.microsoft.com/source/features/ai/6-ai-trends-youll-see-more-of-in-2025/
• 谷歌2025年发布：https://drive.google.com/file/d/1oEjiRCTbd54aSdB\_eEe3UShxLBWK9xkt/preview

本文将从四个维度探讨AI Agent的发展：

1. 前沿Agent实例分析

• 深入解析OpenAI两款代表性Agent产品

2. Agent的本质与定义

• 基于Anthropic《Building Effective AI Agents》研究，探讨Agent与工作流(Workflow)的根本区别

3. Agent的核心竞争力

• 以Manus为例，分析Agent领域的技术护城河

4. 对算法工程师的启示

• 这波Agent浪潮算法工程师应该要关注哪些方面

OpenAI 25 年发布的两款agent 产品

随着各类Agent产品迅速涌入市场，让人目不暇接。看不过来怎么办？很简单，最直接的做法就是关注全球最top的AI公司 OpenAI 的发布动态，通过其发布的产品来洞察Agent未来的发展方向。

一月份 Open AI Operator

Operator是 openai 发布的第一款 agent 产品。 Operator是一款能够自主操作浏览器完成任务的AI智能代理。它基于名为 “计算机使用代理”（Computer-Using Agent，简称CUA）的新型模型，结合了GPT系列模型的视觉能力和强化学习的高级推理能力，采用端到端的训练优化方式 。

Operator基于云端的虚拟浏览器。当用户启用 Operator 时，系统会调用一个远程的虚拟浏览器来执行任务，在浏览器中Operator agent可以像人类一样通过输入、点击和滚动等方式与网页交互，无需依赖定制API集成。用户只需下达指令，它就能自动完成各种在线任务，如填写表单、预订餐厅、购买商品等。Operator 目前仅面向 ChatGPT Pro 订阅用户开放。

https://www.bilibili.com/video/BV1tYf7YnEvW/?spm\_id\_from=333.337.search-card.all.click

OpenAI 似乎希望将 Operator 打造为一种通用性强、适应性广的工具。Operator 的设计理念与传统的调用 Function API 的方式相比有本质区别。例如，开发一个网购 Agent，如果依赖于调用淘宝、京东等平台的 API，其迁移性会非常有限。一旦目标平台的 API 发生变化，或者需要迁移到其他平台（如抖音商城），模型就需要重新适配。而 Operator 通过抽象出人类使用浏览器的行为（如鼠标点击、键盘输入等），理论上能够实现人类通过浏览器完成的任何操作，从而具备更强的通用性和适应性。

不过，从直播展示的案例来看，Operator 的表现还有待优化。例如，

• 长链路任务表现欠佳：例如在多个搜索结果中找不到答案时容易失去方向导致卡住，这个主要是模型问题，应该很快能有所提升。如下面 openai 公布的 benchmark，operator还远远达不到人类水平。
• 交互形式与验证机制：频繁的用户确认容易中断任务流程，如中间老是要用户来填账号密码等关键信息。以及难以自动化验证操作正确性，如在购物场景中，难以确保Operator购买了正确的商品、数量和金额。这个主要是产品设计的问题。

二月份 Open AI Deep Research

Deep Research是专为 金融、科学、政策、工程等领域的深度研究 设计的AI Agent，提供全面、精准的研究支持，旨在解决高强度知识工作的需求。 OpenAI 号称 5-30分钟，能出一份专家级别的调研报告 。

https://openai.com/index/introducing-deep-research/ https://wiki.ds-int.cn/pages/viewpage.action?pageId=129440918

Openai 上官网的例子

• 商业问题 ：帮我查找过去10年按GDP排名前10的发达国家和前10的发展中国家的iOS和Android采用率、想学习另一种语言的人口百分比以及移动设备普及率的变化。将这些信息整理成表格，统计数据分列显示，并针对ChatGPT目前活跃的市场，为新推出的iOS翻译应用提供目标市场建议。
• 大海捞针问题 ：有一部我前段时间看过的电视节目，我忘了名字，但我记得其中一集的情节。你能帮我找到这集的名字吗？以下是我记得的情节：两个男人在玩扑克，其中一人在对方让他下注后选择了弃牌。实际上，弃牌的人手牌很好，却中了对方的虚张声势。第二局，同一个人再次弃牌，但这次他的手牌确实很差。一个男人被锁在房间里，随后他的女儿来敲门。两个男人去了一家肉店，其中一人带了伏特加作为礼物。请深入浏览网络，找到发生这些情节的电视节目那一集。
• 医学问题 ：深入研究通过直接修改四个Yamanaka因子的蛋白质序列来提高OSKM重编程效率的尝试。列出你找到的所有相关论文，作者，使用的方法和结果。研究论文中蛋白质变化和相应结果的模式，并列出科学家为提高效率而修改的前三个领域，以及他们为什么认为这些变化是有效的。
• 设计问题 ：找到证据表明，带有图标和标签的按钮比没有标签的按钮，或者没有图标的标签按钮更易用。我知道关于这一点已经有很多用户研究了，非常希望看到一份详细的报告，以及一个高级的、一次性的、明确的关于有效性的答案。
• 购物问题 ：我在寻找完美的滑雪板。冬天我主要在北海道每月大约两次进行滑雪。我喜欢经过整理的赛道，但也希望板子偶尔能应对一些新鲜粉雪。我更喜欢多功能的全地形或自由式滑雪板，具有中等弹性，既适合刻滑又能在多变条件下灵活操控。我希望有一个清新、柑橘色调的滑雪板，在雪道上能脱颖而出。我的预算是中档到略高端，并希望得到在日本可购买的特定品牌和型号的建议。请解释为什么每款推荐的滑雪板符合我的需求。还包括任何关于在北海道独特雪质条件下滑雪的建议或注意事项。请附上物品图片，并以易于阅读的表格格式呈现。
• 一般问题 ：NFL踢球者的平均退休年龄是多少？

个人实测的例子

• 例子一： 请你帮我列出openai、anthropic、 gemini、 meta 、 qwen、 deepseek、豆包、kimi 、零一万物、阶越星辰、minimax 、智谱、百穿智能、面壁智能在 22 年-25年，发表过的大模型，列出每一个大模型发表的时间，模型参数量多大，有什么版本，是什么大模型（输入是什么，输出是什么），是否开源，如开源则列出对应的 huggingface。

这个例子是，考察它深度搜索的能力。这个问题可能我自己整理要半天，想看看 deep research能帮我整理多少信息出来。

一开始把问题抛给 deep research，deep research 会从问题中找到不确定的因素让你确定，这种交互可能会持续几轮，然后才进入它的分析中。

例子的问题：这里如Claude 系列漏了 Claude3、 3.5、 3.7等、 deepseek-V3也不是 25 年 1 月出的，而是24年 12 月出的，这个应该是 deep research引用错了不正确的信息源，如把信息源中的“预测推出”理解成了正式推出等。

• 例子二： 研究《哪吒2》在国际市场的接受度与文化输出效果，分析其对提升中国文化软实力的贡献。 例子的问题：引用的信息源不够准确，有时候说引用了 CNN 的报道，但实际打开，发现并不是 CNN，容易捏造数据，例如说票房 60亿，但打开数据源，发现数据源并没有提到 60。

从上面两个例子可以看到， Deep Research 远远不能直接用于生产 。

• 最大的问题：幻觉，一方面，模型自身可能存在局限性，导致生成内容的准确性或可靠性不足；另一方面，信息源的干扰也可能引入错误或误导性的内容。
• 给我的感觉，Deep Research 不是一个 “无所不能” 的 “研究智能体”， 更像是一个 和你一起完成复杂工作的 “虚拟助手”。对于那些本就擅长搜索和信息处理的人而言，Deep Research 能够进一步提升他们的效率，使其如虎添翼。然而，对于那些原本就不擅长搜索和整理信息的人，可能并不会节省时间，甚至需要花费更多时间去核实信息的正确性。这有点像编程工具 Cursor，对于会写代码的人，它能极大地提高效率；而对于不会写代码的人，debug 的时间可能比自己从头开始写代码还要费时。

即使如此，Deep Research对比其它家也效果也领先一大截了，如 Perplexity、Grok3、秘塔AI搜索，我们也在调研开源的 deep research实现，效果是远远达不到 openai 的效果的。

以下是红杉资本对话OpenAI Deep Research团队：2025如何成为"智能体之年"，这篇访谈的信息量及其之高，全文的核心在于披露了 Deep Research的训练思路。许多人误解了Deep Research，尤其市面上出现了大量所谓的复现版本，让大家的认知出现了偏差。事实上， OpenAI并不是简单地在GPT基础上套壳（套壳指的是在 GPT 模型的基础上，通过定制化的 prompt 以及固定的代码流程来实现某功能） 。相反，OpenAI 基于 GPT-o3， 采用端到端强化学习+高质量训练数据的方式训练了一个全新的模型，能够完全在内部完成搜索任务 ：模型学习了基础的浏览能力（搜索、点击、滚动、文件解析），以及如何通过强化学习来整合大量网页信息，生成结构清晰、来源可靠的研究报告。

https://www.bilibili.com/video/BV14bPGejEmG/?spm\_id\_from=888.80997.embed\_other.whitelist&bvid=BV14bPGejEmG

什么是端到端的学习？

端到端训练与传统的工作流程截然不同。传统方法通常将复杂任务拆分成多个子任务，如上图的上面（后面会说到，这种是 workflow），分别处理后再整合结果。例如，某些开源的 Deep Research 项目中，有几种复现方式

• 方式一 ：将用户问题分解为多个子查询，每个子查询由不同模型或模块处理，最后由一个模型统一整合答案。
• 方式二 ：模型先给出初步回答，然后自我评价打分，假如评价不 ok，就循环修改，直到达到满意结果，类似于毕业论文的修改过程。

这些都是提前定义好的 workflow，这些workflow虽然在一定程度上能取得不错的效果，但存在明显的局限性：它们依赖于预先搭建好的workflow，限制了模型的自主性和灵活性，难以scaling，难以 cover 无穷无尽的边缘情况，每当有新的bad cases，可能就要在原来的工作架构上新增解决的模块，导致代码越来越臃肿，上限有限。以一个包含四个子任务的串联任务为例，如果每个子任务的成功率为95%，那么整体成功率仅为81%。而端到端训练的单个模型，通过高质量数据+强化学习的加持，有望将整体成功率提升至95%。

端到端训练是一种更直接、更高效的方法。它摒弃了传统的工作流程，将整个任务交给一个模型来完成。模型自行决定如何调用外部 tool、何时需要拆分子查询、何时进行自我校验等，真正实现了 “模型即服务” 。

说得有点虚，用个具体一点的例子来说明， 假如要端到端的学习，我应该怎么做数据标注呢？可以是，把用户的问题问 GPT-o3，让 o3 采样 10 个不同的答案，由标注者选择哪个答案最好，用偏好学习的方式训练奖励模型，然后再把这个奖励模型应用到强化学习中。本质在于激励AI自我学习，比试图教会AI每一项任务更重要。

https://mp.weixin.qq.com/s/oE5m4vCrvbpW\_51MRcy7XA

Anthropic：《Building Effective AI Agents》

2024年12月，Anthropic发布了一篇关于构建AI智能体的重要博客。Anthropic经过与数十个跨行业团队的合作，得出一个关键结论： 最成功的AI Agent并非依赖复杂框架或专用库，而是采用简单、可组合的构建模式 。简单点说，简洁的端到端流程往往比复杂设计更容易维护、优化，并取得更显著的效果提升，更容易取得成功。

https://www.anthropic.com/engineering/building-effective-agents

What are agents？

Anthropic 把下述两种统称为 agentic systems：

• Workflows : 通过预定义代码路径协调LLMs和Tools。
• Agents : LLM自主决定过程和Tools的使用，控制任务完成方式

从这个定义看，市场上大多数所谓的"智能体"(包括Manus)实际上是workflows。真正的agents相对较少，如OpenAI的Operator、Deep Research以及Cursor等产品。

When (and when not) to use agents

Anthropic提供了清晰的选择指南：

1. 从简单开始 ：为LLM应用选择最简单的解决方案，如一开始通过prompt 来解决，只在必要时增加复杂性
2. 根据任务特性选择 ：对于可预测、定义明确的任务，需要一致性时使用workflows；当需要大规模的灵活性和强大的模型来驱动决策时，使用真正的Agent
3. 避免过度设计 ：对许多应用来说，优化单个LLM调用(通过检索和上下文示例)已经足够

感同身受，很多时候业务部门过来问，能不能用 agents 的方式来解决，但深入分析后发现，简单的prompts搭配RAG或few-shots就能有效解决。正如Anthropic所言，不要用牛刀来杀鸡。

When and how to use frameworks

Anthropic 对市面上如LangGraph、Bedrock、Rivet的看法是，虽然这些框架能帮我们快速搭建应用，但它们往往会给系统增加一层"看不见的面纱"，说白了，就是有些框架会写得很重，不利于 debug 和优化。

Anthropic 的建议是：先试试直接用LLM的API，很多功能几行代码就能搞定。如果真要用框架，一定要了解它底层是怎么运作的。很多人踩坑，调优不到好的效果就是因为对框架底层机制不清楚。

记住，简单方案能解决的问题，就别引入不必要的复杂度。

Building blocks, workflows, and agents

Agent的构建分为不同复杂度级别，从基础的增强型大语言模型Augmented LLM开始，逐步发展到预定义的workflow，最终形成自主的 agent。

Building block: The augmented LLM

增强型大语言模型(augmented LLM)是Agent的基本构建单元，它集成了检索、工具和记忆等能力。现代模型能够主动使用这些功能，如生成搜索查询和选择适当工具。

Workflow

包含有以下几种：

Workflow: Prompt chaining

链式工作流就是将复杂任务分解为连续步骤，每步LLM调用处理前一步输出，可添加检查点（如下图的Gate）确保过程正确。适用于可清晰划分的任务，如营销文案生成后翻译或先创建文档大纲再撰写完整内容。

Workflow: Routing

路由工作流就是先给输入内容"分类"，然后根据这个分类标签把它送到最合适的专门处理流程去。这种方法在处理那些有明显不同类型的复杂任务时特别有用，比如可以把各种客服问题分类处理，或者根据问题难度路由到小模型或大模型来回答。

Workflow：Parallelization

并行工作流就是让多个大语言模型同时处理任务，可以分成两种方式：一种是"分子任务"，把大任务切成小任务同时处理；另一种是"投票"，让多个模型做同一件事然后综合结果。这种方法在需要提高处理速度或者想要多角度意见时非常有用，比如一个模型专注回答问题，另一个专门检查内容是否得当。具体应用例子包括代码安全审查、内容审核，或者让每个模型评估不同方面，这样比让单个模型同时兼顾所有方面效果更好。

Workflow: Orchestrator-workers

管理者-工作者流程就像有个主管模型当"老大"，它看情况拆任务，看情况把不同的任务派给"小弟"模型干活，最后把大家的成果合起来。这招最适合处理那种事先不知道要干啥的复杂活儿，比如改代码时不知道要动多少文件。跟并行不同的是，这种方式没固定套路，全凭"老大"随机应变。像复杂编程或多源搜索这种任务比较适合。

Workflow: Evaluator-optimizer

评估者-优化者工作流就像一个模型出方案，另一个当评委提意见，然后循环改进。适合那些有明确评价标准、需要反复打磨才能效果好的场景。有点像是我们写毕业论文，导师不断反馈，我们不断修改，直到达到要求。

Agent

相比于 workflow，Agent 的设计反而是很简单。背后依靠强大的推理模型，让模型自己去理解复杂输入、进行推理和规划、使用工具以及从错误中恢复。

Agent在循环(loop)中工作，根据输入自己选择合适的工具，并能根据环境反馈调整策略——例如当代码执行失败时，能根据错误信息自动修正；或根据问题性质自主决定采用sequence还是Parallel的workflow方式解决。

智能体的核心在于模型主导全部决策过程，人类无需预先定义详细流程，只需在特定情况下提供少量干预，如在Deep Research中我们只需要确认关键的信息或在Operator中当输入账号密码等敏感信息需要人类干预。本质上，agent将复杂任务的规划和执行权交给模型，所谓模型即服务，采用端到端的优化来提升效果。

Summary

最后 anthropic 的总结是：

做 LLM 项目最重要的不是构建最复杂的系统，而是为你的需求找到最合适的解决方案，建议从简单提示开始，只在必要时才引入复杂的智能体系统。

实施智能体时要坚持三个原则：保持设计简洁、确保模型规划过程透明、精心打造工具接口并做好测试。虽然框架能帮你快速起步，但随着项目走向生产环境，适当减少抽象层并直接使用基础组件可能更有优势。遵循这些原则，你将能创建既强大又可靠、易于维护且受用户信任的智能体系统。

对这篇博客的看法

十分的认同，Anthropic的博客阐述的就是 less is more 的道理，往往成功的应用都不会太复杂的真理。跟 openai 的采访中端到端优化的理念是 match 的，越是通用形型的 agent 构建应越要遵循这个思路。

聊聊 Manus

最后聊聊manus，manus 的账号我拿不到，还没体验过，看了些 b 站上的评测视频，原理应该好简单，核心工作流程如下：

1. 任务规划

• 使用Claude 3.7等高级LLM接收用户问题并规划出详细的ToDo List。

2. 任务分发

• 通过较小模型（如Qwen）判断每个子任务应该交给哪个专门的agent处理。

3. 执行代理

• 主要依靠三个agent： 浏览器操作代理（类似Operator）；搜索API调用代理；编写代码的 agent。

4. 结果汇总

• 当子任务完成后，任务汇总生成器（估计用的也是Claude）读取ToDo List和各子任务结果，整合为最终输出。

来自宝玉老师《Manus 的护城河在哪里？》：https://mp.weixin.qq.com/s/ji1YlVNarMfNCF3Fo6BwfQ

从技术角度看，Manus 其实没什么真正的护城河。它的架构说白了就是 workflow 和 agent 的组合：前面做任务规划和最后总结是 workflow 那一套，中间执行各个子任务就是靠独立 agent。

通用型 agent 面临两大难题：

1. 得把 OpenAI 那套端到端优化做到极致，这需要特别强的基模、高质量数据和稳定的强化学习算法
2. 通用就意味着在专业领域上洞察深度和效率比不过垂类的agent，这是先天限制

虽然技术门槛不高，但产品体验本身也能成为竞争力。当各家产品效果都差不多时，就看谁给用户的体验更好了。只要 Manus 能：

• 做出好用的产品体验
• 建立起用户反馈改进的飞轮
• 先一步占领通用 agent 市场

这样的策略其实挺合理的。

最终，怎么样的 Agent 能脱颖而出

做个不严谨的预测，仅供讨论

短期预测

在短期内，基于行业经验并结合微调的 Workflow 方案仍将占据主导地位。这一判断的依据是， 即使是强如 OpenAI 等顶级机构开发的接近通用形态的 Operator 和 Deep Research，也远远未能达到直接应用的效果 。具体原因如下：

• 推理模型有待发展 ：当前的推理模型，如 gpt-o3 和 deepseek-R1，仍存在一些问题。例如，幻觉问题尚未解决，且在一些高难度的 benchmark 上，其分数也未达到优秀水平。Deepseek号称 R2 将在性能上大幅提升，侧面证明现在的 R1 还有好大的提升空间。
• 强化学习方法仍需探究 ：目前，强化学习被认为是构建强大效果和泛化性的核心。然而，如何构建高质量的强化学习数据集，以及选择何种强化学习算法，这方面的论文研究好像比较少。例如，Deepseek 采用的是 GROP 算法，kimi1.5 采用的是在线策略镜像下降的变体，而 OpenAI 则采用 PPO 算法，不同机构选择的算法各不相同，这侧面证明还没探索出最佳实践。
• 业务场景尚在探索阶段 ：不同行业和应用场景对 Agent 的需求存在较大差异，需要时间来积累行业经验。

长期预测

从长期来看，端到端训练的 Agent 将逐渐崛起，成为主流。因为，端到端训练的 Agent 更符合 Agent 的本质形态，即模型能够在 in a loop 中自主处理问题，具有更高的上限。以包含 4 个子任务的串联任务为例，即使每个子任务的成功率为 95%，那么整体的成功率也仅为 81%。相比之下，端到端训练的单个模型，结合超高质量的数据+强化学习，是有望将整体成功率提升至 95%。基于这一趋势，未来可能出现以下情况：

• 顶级的 Agent 可能工程代码及其简洁，所谓模型即服务 ：这种简洁的背后，是超高质量的训练数据+极致的端到端强化训练。所有 if-else 和 workflow 的选择将由模型自身判断完成，而非依赖人工编写的规则代码。
• 通用 Agent 更有可能在 Openai 这种公司出现 ：通用型 Agent 的研发需要强大的基模和经验丰富的强化学习工程师。因此，像 OpenAI、Anthropic、DeepSeek 这样的搞基础模型公司的更具优势，更有可能率先推出通用型 Agent。想想其它公司，假如能o3这些基模都拿不到的情况下，又怎么微调出超强泛化性的模型呢？基本没可能。其他公司更有可能在垂直领域找到发展机会，通过专注于特定行业或应用场景，实现差异化竞争。

对于应用型算法工程师的启发

相信不会多久，老板就会让各位算法工程师做一些agent，毕竟现在的市场这么焦虑，应用型工程师嘛，就是为了用算法解决实际问题，这里聊聊应用型算法工程师怎么在这波 agent 浪潮中发育。

1. 积累场景测试集，持续测试新的模型 。

多积累业务场景测试集或自己感兴趣的测试集。当新的模型出现时，利用成熟的测试框架快速验证其性能和适用性。新模型层出不穷，而且现在好多都是付费营销啦～只有多测试，才能做到心中有数，应对自如。 2. 学会微调，积累微调insight 。

要取得好的效果还是需要微调。无论是SFT还是RL，日常阅读论文时，要重点关注论文中数据的构建和实验思路。虽然现在有如llama_factory、openrlhf等微调框架，让微调变得简单，但工程师更重要的是积累微调的insight。例如，何时需要微调，何时通过改prompt即可解决问题；如何构建高质量数据集，怎么让业务同事也心甘情愿帮你标数据，多少数据能达到什么效果；何时使用SFT，何时使用RL。这些除了通过阅读论文获取一些方向思路外，更重要的是在自己的业务场景中多尝试。 3. 工程实践中避免过度设计 。

遇到新场景时，优先考虑“做减法”，而非“加积木”。例如，你开发了一个算法应用，一段时间后产品经理提出需要处理一个边缘情况，此时你不应优先考虑叠加新的处理模型或增加模型，而是：查看新出的模型是否能解决该情况，并简化之前的流程。这对应第一点，积累场景测试集，持续测试新的模型；基于对业务和数据的理解，尝试通过高质量业务数据+微调的方式解决问题，甚至合并之前的流程。这对应第二点，学会微调，积累微调经验。 4. 选择与大模型协同发展的方向

尽可能选择那些随着大模型的升级，应用效果会变得更好的解决方案，而不是做那些更强大的模型出来后之前的努力就白费的解决方案。 5. 灵活运用workflow与端到端优化

对于能够快速通过workflow达到交付要求的场景，直接使用工作流即可。所以工程师还是需掌握各类框架 ，以快速灵活应对不同需求。但如果是一个长期需要不断优化的应用，那么请考虑一下采用端到端优化的形式。

PS：看到这里，如果觉得不错，可以来个 点赞 、 在看 、 关注 。 给公众号添加【星标⭐️】不迷路！您的支持是我坚持的最大动力！

欢迎多多关注公众号「NLP工作站」， 加入交流群 ，交个朋友吧，一起学习，一起进步！