这篇AI Agent漫游指南，带你建立全面的科技史观

以OpenAI o1与DeepSeek R1为代表的"类Agent"模型、OpenAI DeepResearch为代表的“真Agent”模型，正在重构AI Agent的技术范式。Agentic Workflow的王座还没坐热，强化学习驱动的端到端Agent模型训练已呼啸而来。未来趋势已指明：模型即产品，工程化Agent的命运将如何？一起来洞察全新的Agent技术范式底下的技术及演进过程，提前看到未来的模样。

欢迎乘坐Agent漫游列车，作为AI Agent的躬身入局者，我将为你讲解AI Agent的前世今生并推演一下未来。

时间线

我们先来回顾一下基于LLM的Agent发展时间线，LLM的实质性的起源时间只回溯到2017年的注意力机制的提出时间。

1. 在2017年前，AI的世界一片混沌，NLP领域更是停滞在RNN和LSTM止步不前。
2. 《人类群星闪耀时》如果有续集，我认为2017年《Attention Is All You Need》的作者应当在列，论文描述的注意力机制——Transformer架构划破了AI世界的第二个长夜，一个崭新的时代光速开启。
3. 接下来的标识性事件是GPT-3的诞生，代码生成场景，GitHub Copilot重新定义了代码补全。
4. 基于GPT 3.5的ChatGPT把通过自然语言聊天的形态把大模型带到了普罗大众面前，超越tiktok成为增长最快的app。
5. GPT-4是首个参数突破万亿的大模型，在2023年，GPT-4的性能无敌，OpenAI也放慢了继续扩大模型参数的路子，推出插件系统、GPTs等，当年业界大井喷出大量的LLM应用开发框架，CoT思维链，Agent理念的祖师爷ReAct都在那时候推出，OpenAI也把工具使用的能力训练进了模型里，推出FunctionCall，这一年，可谓AI agent的白银时代。
6. 2024年，Agent在水底下快速发展，模型的预训练Scaling Law好像失效了，GPT-4停滞不前，GPT-5难产，O1的出现宣告着训练的路径要转向了。
7. 2025年是后预训Scaling Law开始生效的时间，蛰伏了两年多的Agent得以浮出水面，而模型侧也因为强化学习迎来了第二春：后训练的Scaling Law。
   
   

AI Agent是怎样炼成的

AI Agent是大模型应用的一种特定形态，在深入理解什么是AI Agent之前，我们先直观理解一下大模型的工作方式：文本补全。

LLM工作的核心形态：文本补全

如下图所示，我们给LLM发一段文本：“下面我将要讲一个故事。在很久很久以前，有一个”，大模型会收到输入后，它会返回一段文本：“小村庄坐落在群山环换之中。村子里住着。。。（省略数百字）”，然后，结束了。

这就是大模型一次工作的典型表现，对输入的文本进行补全（Text Completion，这是为什么LLM们的接口都是completion、chat/completion的原因）。用户输入的部份内容，称之为提示词——Prompt，大模型生成的输出的文本是生成内容——Generated Text。

整个核心形态看似简单，一次输入输出。实际上提示词与生成内容两端分别是两个巨大的领域：提示词工程与模型预训练。

通过提示词，用户可以让大模型实现各种场景的文本生成任务，例如诗歌创作、语言翻译、代码生成、广告文案生成等，而提示词本身的编写方法和质量也会影响大模型生成内容的效果，因此，如何写好提示词是一门综合性的学问。另一方面，提示词是通过自然语言来表达的，所以这也造成了大量的非AI科班出身的且非专业开发人员投入到了大模型应用的开发浪潮当中，这个群体形成了提示词工程的阵营，我们看到的大部份LLM应用侧的工作都属于该阵营。

基于以上对LLM应用的了解，我们继续往下一站，了解什么是AI Agent。

什么是AI Agent

在业界一度有一个乱象，就是把所有基于大模型的聊天机器人都统称为智能体即AI Agent。不管你是一个角色扮演的应用，或者通过流程编排出来的一个大模型工作流，还是可以自主决策来去使用工具做任务的真Agent，这些都统称为AI agent，但这其实是一个误区和懒惰。现在都说2025年是AI Agent的元年，我们很有必要去澄清一下AI Agent它到底是什么。

AI agent是基于大模型，具备记忆能力、能够有自主推理和规划工具的使用，从而来解决问题的智能程序。即AI Agent = 大模型 + 记忆 + 使用工具 + 自主规划。

基于大模型意味着可以通过自然语言去交互，所以聊天是我们使用AI Agent最直观感受到的交互方式。

有记忆能力就意味着他能记得跟你过往跟你聊天和互动的历史，正因为如此，你昨晚和你的AI伴侣聊得火热，第二天起来TA也不会问你，你是谁，你想干什么？

AI agent要实现记忆能力，简单的做法就是把前序的聊天记录附在提示词里，但很快迎来新的问题，聊天记录多了，很容易就导致模型上下文爆token无法继续生成，随后又发展出只取最近N次聊天记录、只取与当前问题相关的聊天记录等等手段。

单有记忆能支持人机之间进行连续的多轮对话还不够，因为光说不练的也不能叫做Agent。

所以TA必须得懂得用工具。所谓的使用工具，就是去访问各种资源，调度数据接口等。例如，我们常见到的一种AI聊天的形态——联网搜索，你可以把它看成一种使用工具的能力，AI把你的问题和该问题在网络上相关的一些内容加到一起去，让大模型给你生成答案。

话又说回来，能使用工具的就是Agent了吗？我们来比较一下元宝联网搜索的自动挡和手动挡。

在元宝里面，你只要勾选了联网的手动挡，每次你提问他都会先联网查询再给你回答，而联网的自动挡会先判断你这个问题需不需要更多辅助它解决的信息，需要了再去联网搜索，不需要他就直接回答。同样是使用工具，但手动挡表现出来的是固定的工作模式，而自动挡做法是AI agent的模式，它有自己的自主的规划和反思过程，这是AI Agent的另一个重要的特征。这个容后详述。

回到工具，大模型是怎样使用工具的呢？我们都知道，大模型是一个文本模型，它只能输出文本，所以，实际上所谓的使用工具，只是大模型在文本里说明要使用什么工具，LLM的应用程序解释这段文本找到使用工具的信息，按照大模型的吩附来执行工具的调用，如下图所示：

上图中，我们在给大模型的输入的提示词内容包括：

1. 可用的工具说明，包括工具的功能、接受的参数明细等。
2. 工具的调用规范及示例，通过对工具调用的规范进行详细说明，并使用fewshot的技术来给大模型学习一些例子。
3. 用户问题，最后是附上用户的提问。

大模型在回复的时候，会按照提示词中的工具调用规范返回实际的工具使用例子，在上图中是一串json格式的配置数据，表达了要调用search_web这个工具，参数有query和limit两个。

后来，这种教大模型如何返回工具使用命令的工作，被OpenAI率先预训练到模型里面去了，并把这个功能叫Function Call，训练到模型去即意味着不需要再通过提示词指导大模型使用工具了，而只需要告知大模型你有什么工具可用即可，在OpenAI的接口中，通过tools指定可用的工具集。

再后来的事大家都知道了，主流的大模型都先后效仿openAI支持了function call。

MCP（Model Context Protocol)是由Anthropic(Claude母公司)在2024年底提出的一种大模型上下文模议，目的是让Agent能够更方便地发现和使用来自各处的工具，让Agent能做的事情更多。最早的落地场景是在Cluade的桌面端中使用，Claude通过MCP协议对用户计算机的文件进行读写和对用户的电脑进行操作。

MCP随着AI Agent的出圈也飞速流行起来，当前已然是一片不MCP无Agent的态势，国内外大模型厂纷纷下场支持MCP，MCP成了事实上的Agent工具使用标准。

关于MCP与大模型Function Call的关系， 经常会被误读，说MCP是替代Function Call的。但实际上，Function Call和MCP两者是不同层面的东西，甚至反过来说，是紧密配合的。如果 一个模型不具备Function Call或等价的能力，那它就用不了MCP。

Function Call是大模型返回调用工具指令的能力，MCP是Agent在工程侧的程序具体执行调用工具的手段，一个是说，一个是做。

在有MCP之前，Agent收到大模型的Function Call指令后通过各种方法去调用外部的各种资源和服务的，如要自己实现读写文件，查数据库，调搜索接口等等，这些方法可以千差万别，开发过程长，成本高。

而MCP的出现，统一了工程侧调用工具的规范，它服务的厂商按照MCP Server的标准提供服务，Agent的程序只需要统一使用call_tool这个MCP Client的功能来执行调用即可，一下子节省了大量的工具适配的工作。

所以，MCP不是来代替Function Call的，而是帮工程侧调用外部工具提效的。Function Call是使用工具的基石能力，MCP打开了AI Agent连接世界的大门，两者强强联合，才是提效的真相。

上面说过，只会无差别的使用工具，是不经过事先思考的行为，这种LLM应用不能被称之为AI Agent。 自主规划和反思甚至自我批评，是AI Agent模拟人类工作方式的体现，也是AI Agent的核心要素。

思维链（Chain of Thought，简称CoT；Wei等人2022年提出）已成为提升大模型处理复杂任务性能的事实上的标准提示词技术。人们通过引导模型"逐步思考"，将任务拆解为多个更小、更简单的子步骤，从而提供模型的输出性能。CoT不仅将庞大任务转化为可管理的分步流程，在DeepSeek R1这类推理模型中，还为理解模型的推理过程提供了透明化的解读路径。

除了思维链，类似的思路还有思维树（Tree of Thoughts， ToT）和思维图（Graph of Thoughts，GoT）。它们都对CoT进行了扩展，在特定的应用场景均有显著的提升。但是实际应用中，CoT是绝对的主流。

反思能力能让Agent具备迭代出可用答案的可能性。Agent通常不止一次调用LLM和工具，每一次采取行动调用工具后，都需要经过反思来确定是否做好了，不够好接下来该怎么做。

ReAct（Reasoing Acting， 由Yao在2023年提出）思考框架，它指导AI Agent通过思考、行动、观察的循环来实成任务。Agent接到任务后的工作流程大致如下：

1、 思考(thought)，要解决该问题，下一步需要采取什么行动。

2、 行动(action)，大模型输出行动指令，让Agent调用外部工具。

3、 观察(observation)，把工具执行的结果给大模型进行观察。

4.1、回答(answer)，如果工具执行的结果已能得到答案，组织语言回答。

4.2、如果目前得到的信息仍无法作答，进入下一次循环，继续思考使用工具。

看起来是不是很像咱们人类的PDCA（Plan Do Check Act）的翻版？

ReAct模式是当下AI Agent领域事实上的工作模式，包括基于OpenAI Function Call实现的Agent在内的背后也是同样的工作模式。只不过，使用内置的Function Call的方式，不需要额外提供提示词来指导模型行动罢了。

为什么Agent不Work

AI Agent在大众看到之前已经发展了两年多，直到最近Manus的爆火才被出现在大家面前，根本原因是，Agent的可靠性不足，上限较低。所以一直还摆不上台面，仅在有限的场景迭代和落地。

实现一个Agent不难，有开发经验的同学，通过学习在一两天内可以开发出一个可以运行的Agent，但要做一个可用的Agent，则还需要大量的工作。

判断一个Agent是否可用，主要取决于具体场景的错误容忍度和受众的介入程度。以AI编程为例，开发者对Agent生成代码的预期是“规模不大的需求，代码生成还不错，会有问题，但可以通过反复沟通去修正，最终达到相对可接受的结果”。所以，Vibe coding这个场景火了，大量不懂代码的开发者诞生了。Deep Research所关注的研报场景同理。

所以，当下大家能看到的生产级别的Agent，基本上都有这两个特征：复杂度与规模较低、容错水平高。

影响Agent在大规模复杂问题上的性能因素是幻觉和记忆管理的挑战。

大模型是一个概率模型，它生成的内容一定的概率是错误的，即我们常说的幻觉。

Agent执行一次任务，通常需要组合多次大模型的调用来完成工作，在总体的结果成功率上比单次的大模型调用会更加低。例如：假设平均单次调成大模型生成内容的正确率在90%，那4次组合调用后，正确率直接下降到60-70% 。

当前基于大语言模型的Agent普遍面临"记忆困境"，这种困境源于大模型自身的无状态特性与人类认知过程中持续演进的记忆机制之间的本质差异。传统采用简单对话历史堆砌的"伪记忆"实现方式，在应对需要长期记忆保持、复杂知识关联和动态经验积累的场景时，暴露出一系列结构性矛盾。

当前主流大模型的上下文处理能力受限于固定长度的窗口机制（如GPT-4的32k tokens）。这种物理限制导致对话轮次或任务复杂度超过窗口容量时，必然发生历史信息截断，造成关键记忆丢失；其次，随着上下文长度增加，模型处理效率呈指数级下降。这种矛盾在需要长期任务追踪的场景（如连续多日项目管理）中尤为突出。

大模型厂商不断推出支持更大size上下文的模型，截止发稿为止，最大的上下文是Meta的Llama scout 1000万token。

尽管上下的尺寸越来越大，甚至能塞下全集的哈里波特了，但是超长上下文注意力的准确性又成了另一个问题。

Transformer架构的自注意力机制虽然赋予了模型强大的上下文关联能力，但其计算复杂度O(n²)的特性导致随着上下文长度扩展，有效注意力的分布呈现显著稀释效应。根据ICLR 2023的研究成果，在16k tokens的上下文长度下，模型对前20%输入内容的注意力权重占比超过65%，而对后20%内容的注意力权重不足8%。这种"近因偏好"现象使得早期关键信息容易被后续内容覆盖，导致记忆保持的时序稳定性问题。更严重的是，当处理超长文档（如百页技术手册）时，模型可能陷入"注意力涣散"状态，出现关键信息漏读或误读。

Google的BigBird和DeepSeek的NSA(Native Sparse Attention)都在致力于解决这个问题。

相关记忆的准召问题

既然暴力的强塞所有的聊天记录不行，那就换一种思路吧，只取跟当前问题有关联的聊天记录总可以了吧？我们把聊天记录存在向量数据库中，通过向量检查召回关联的内容，实现按需注入历史。

然而，向量数据库的召回也是一个庞大复杂的工程（RAG中的R），召回数据的准确与否，直接决定了大模型回答的质量。为了提升准召率，RAG一路发展到基于知识图谱的RAG，又到了今天的Agentic RAG，仍然没有到头。

有办法！

方法总比问题多嘛，既然知道agent面临着怎样的挑战，就给出针对性的解决方案吧。为了提升agent的性能，业界提出了各种解决方案，总结起来有3大类。

● 引入workflow，使用固化的工作流程来提升确定性，但同时牺牲掉灵活性。

● 在ReAct框架的基础上做工程侧的极致优化

● 引入多agent，效仿人类团队协作，突破单agent的极限，发挥群集智慧。

workflow的第二春

AI Agent不稳定？那我们来固化工作流程，让AI在必要的时候工作就好？这个解题思路引出了AI workflow的技术形态。

从技术演进视角来看，Workflow本质上是将低代码开发框架与LLM相结合的产物，旧瓶装新酒。其在大模型时代的流行主要源于两个关键因素：首先，当前开发范式已从传统编码转向提示词工程，开发者需要高频迭代提示词而非底层代码；其次，可视化流程编排显著降低了调试门槛，使非技术背景人员也能通过直观界面完成AI能力集成。

现有Workflow更多是业务逻辑的标准化封装，AI仅作为模块化组件服务于特定环节。这种架构虽提升了开发效率，但也存在本质局限——既无法实现智能体（Agent）的自主推理能力，也难以支撑复杂场景的端到端智能化。

简单来说，workflow本身不是AI Agent，但基于workflow实现的功能可又作为Agent的工具，作为Agent的有机组成部份。

Beyond ReActAgent

之前说过ReAct Agent是当下主流Agent的思考与行动框架，但ReAct本身也有着很多的缺点：

1. 走一步看一步，缺乏全盘规划。每次的思考与决策需要依赖上一次工具的输出结果。
2. 串行调度工具，每次工具调用都跟随着一次LLM的调用，没能灵活高效的对工具的调度进行优化。
3. 所有工具的执行结果，都会追加到大模型的上下文中供观察使用，经过多次的工具调用来回后，很容易就触发上下文限制，任务以失败告终。

针对这些缺点，业界的优化方式也是五花八门，以下举一些代表性的例子：

该思路主要受到Plan-and-Solve论文和Baby-AGI项目的启发，其核心工作流程包含三个阶段：

● 规划阶段 ：首先生成一个全盘的多步骤的详细行动计划

● 执行阶段 ：按顺序执行每个计划步骤，返回结果

● 重规划阶段：根据执行结果动态调整计划或返回

这种模式引入了全盘规划，且子任务的执行分拆到Single-Task Agent上执行，避免了Token在同一个LLM会话上下文中堆积，降低爆Token的可能性。

manus的Agent显然是借鉴了这种Agent，先生成任务的清单，再对着清单逐个执行，但似乎并没有看到manus有重新规划这个步骤。

ReWOO（ Reasoning WithOut Observation ）是一种创新的增强语言模型（ALM）框架，旨在通过 模块化设计 显著提升多步推理任务的效率与性能。传统ALM（如ReAct）依赖交替的“推理-工具调用-观察”流程，导致大量上下文重复输入和计算资源浪费。ReWOO突破性地将任务分解为三个独立模块：

● Planner（规划器） ：基于大型语言模型（LLM）的推理能力，预先生成任务蓝图，规划多步推理路径（如调用工具的顺序与逻辑），无需等待工具实时反馈。

● Worker（执行器） ：根据蓝图并行调用外部工具（如搜索引擎、计算器、数据库），高效收集证据。

● Solver（求解器） ：综合规划与证据生成最终答案，具备纠错与总结能力。

ReWOO最显著的特点是拥有一个独立的Solver（求解器）模块，专门负责综合规划结果和工具执行证据，生成最终答案。在worker的执行过程中， ReWOO不去观察（Observation）工具返回的结果，可以减少token的使用及调用LLM的次数。

ReWOO与Plan and Execute相比有两个差异：

● worker的任务执行更多是工具执行，不需要额外的LLM来驱动。

● 没有重新规划的过程。

LLMCompiler专为优化大语言模型（LLM）的多工具协作效率而设计的框架。针对传统方法（如ReAct）因顺序执行函数调用导致的延迟高、成本大、准确率受限等问题，LLMCompiler 创新性地引入编译器式任务编排，通过并行化与动态规划显著提升LLM在复杂任务中的表现。

其核心架构：

● 智能规划器（Planner）：将用户查询解析为带依赖关系的任务DAG，识别可并行执行的函数调用（如并行的网络搜索与数学计算）。

● 动态调度器（Task Fetching Unit）：实时替换占位变量、分发独立任务，最大化并行资源利用率。

● 异步执行器（Executor）：通过工具API并发执行任务，支持自定义工具（如搜索引擎、计算器、API代理）。

LLMCompiler同样是提前做DAG规划，它通过任务依赖关系来对任务进行并行调度，还可以根据结果进行重新规则。

多Agent

人类社会有一句话“独行快，众行远”，指的是如果要走得更远，需要团队合作。在Agent的世界，单个Agent在简单任务方面的表达已经不错，但复杂的以及上规模的任务中的表现却乏善可陈。于是我们不由得去向人类的协同方式学习，让Agent组成团队，复刻人类的协同方式，看是否能够提升性能。

根据多Agent的应用场景，我把多Agent的产品形态分为社会协同模拟型与任务导向型 。

类如“斯坦福小镇”这一种agent社会化实验性的形态，称为社会协同模型型，这类产品不设定具体的任务让Agent来实现，而是提供了一个开放性的运行环境，让Agent自发地去协同和产生可能的“化学反应”，用于对Agent社会化协同的学习与研究。

另一种多agent的形态是目的性很明确的，有清晰的目标和标准的操作流程（SOP)，典型的代表如软件开发过程、较大篇幅的内容（如论文、小说）等的创作。

MetaGPT是此类型多Agent的代表框架，它通过拆解软件开发的标准流程，为每个过程设定不同的角色来完成对应的任务，最终实现一个软件的开完任务。

1. MetaGPT：基于多智能体协作的软件开发框架，通过模拟软件公司角色分工（产品经理/工程师等），将标准操作程序（SOP）编码为智能体协作流程，支持从需求分析到代码生成的全生命周期自动化开发，尤其擅长结构化输出文档与代码。
2. AutoGen：微软推出的多智能体对话框架，支持定制化代理角色与自然语言交互，通过模块化设计简化复杂任务编排，可无缝集成LLM和工具链，其核心优势在于实现人机混合协作与自动化工作流，特别适合需动态决策的场景。
3. CrewAI：开源协作型智能体框架，强调角色扮演与团队化任务管理，支持自定义代理角色、任务委派及流程控制（顺序/层级模式），提供工具集成与知识沉淀机制，适合构建需要明确分工的多代理协作系统（如市场分析/项目管理）。
4. Swarm：OpenAI实验性轻量级框架，聚焦智能体间的动态任务交接（Handoffs），通过函数调用实现执行权转移，保持高度可控性与透明性，与Chat Completions API深度整合，适合需细粒度控制的小规模多代理交互场景。

当然，langchain和langgraph这类框架同样是可以用于搭建多agent的，没把它们列在上面仅仅是因为这两个框架它的普适性更广，不是专为多agent而专门提供的。

langgraph把多Agent的协同架构做了一下汇总，除了自定义架构，大致有以下几种类型：

1. Network（网状），网状架构允许每个Agent间互相通讯，该架构的自由度高，但可控性差，适用于社会协同模拟型的Agent形态。
2. supervisor（监督者），该架构有一个管理者Agent，其他所有Agent之间不能直接沟通，只能与管理者Agent进行沟通。这种架构适用于对任务导向型的多Agent形态，可控性较高，但管理者Agent的智能程度会成为整个多Agent网络的瓶颈。

a. supervisor的结构看起来还跟单Agent的结构很相似，实际上，把非管理者Agent看成一个个工具的话，它就等同于一个单Agent，即图中的supervisor(as tools)的结构。

b. 所以，多Agent并不神秘，你在以前做单Agent的时候极有可能就已经实现过as tools这种supervisor架构的多Agent应用了。上面"plan and execute"中描述的形态也可以视为一种多Agent。

1. Hierarchial（层级监督者），层级监督者是由多个监督者网络进行堆叠而成的，如果把监督者网络看成一个小组由一个组长带领多个组员，那层级监督者网络则更大的的组织，例如是一个中心，甚至是部门，业务线等。

agentic workflow最早由吴恩达提出。简而言之，它的目标是解决复杂任务，通过分解任务、多角色Agent协同、迭代改进的手段来实现。它有以下四大机制：

● 工具调用(Tool Use)

● 多 Agent 协作（Multi-agent）

● 规划能力（Planning）

● 反思机制（Reflection）

光看上面的描述，定义是相当的模糊的，我们拿上文中出现过的LLM应用和Agent来对比一下，以便进一步理解agentic workflow。

上面讲的Plan and Execute形态的Agent看起来就具备”分解任务”、 “子任务执行Agent”、“迭代改进”等等环节，其中子任务执行Agent是一个通用的执行者，负责遍历任务并执行。

而Agentic workflow对任务执行的要求是由不同角色的Agent来执行不同性质的任务，哪个角色应该执行什么任务。

所以，如果把plan and execute模式升级一下，定义多个特定职能的Agent作为子任务的执行者，有针对性的选择任务来执行，可以得到近似agentic workflow的效果。

它和“workflow的第二春”中说的workflow + LLM又有什么区别呢？从几个维度来对比：

1). 动态规划能力

Agentic Workflow：通过 AI Agent 的推理能力动态分解复杂任务（任务分解模式），并根据环境反馈调整执行路径。

Workflow + LLM：LLM 仅作为静态模块嵌入预定义流程。

2). 自我迭代优化

Agentic Workflow：引入反思模式（Reflection），通过执行结果评估和策略校准形成闭环。

Workflow + LLM：缺乏反馈循环，输出质量依赖单次提示效果，无法自我优化。

3). 执行主体性质

Agentic Workflow：以 AI Agent 为核心，具备长期记忆（如向量数据库存储用户画像）和工具调用权限（如 API、搜索引擎），形成类人认知架构。

Workflow + LLM：LLM 作为流程中的“工具人”，仅处理特定环节（如文本生成），无自主决策权。

4). 任务协作模式

Agentic Workflow：支持多 Agent 协同（如数据分析 Agent 与优惠优化 Agent 联动），通过信息传递形成集体智能。

Workflow + LLM：流程由人工预先编排，各模块独立运行，缺乏动态协作。

5). 小结

Agentic Workflow是由AI Agent集体动态生成并可随机变动的协作流程，而workflow + LLM中的workflow是一种由开发者定义的静态工作流。

下图所描述的是一个通过CrewAI实现的多agent智能化的客户优惠推荐系统。

蓝色部份是定义了一种工作流程及每个节点的任务：

1. 提取购买记录：基于用户ID和时间范围查询数据。
2. 匹配最优优惠：通过SQL连接（JOIN）购买记录与优惠表，按折扣排序。
3. 生成通知文案：整合优惠信息，添加表情符号，生成吸引人的消息。

绿色部份是定义了三种不同职能的Agent：

1. 购买历史分析Agent：编写SQL查询客户购买记录。
2. 优惠管理Agent：结合购买历史与优惠表，筛选最优折扣。
3. 创意文案Agent：生成个性化优惠通知。

工作流程：CrewAI框架协调Agent们执行任务，输出最终优惠通知。

CrewAI在任务的调度模式上有两种，一种顺序执行(sequential)，一种是层级模式(hierarchical)，后者由一个管理者LLM来动态调度执行。

窃以为hierarchical模式才是真正意义上的agentic workflow，因为工作流是动态的，可通过反思机制进行实时调整的，是由管理者LLM来自主决定的。而顺序执行的模式，和workflow + LLM的模型没有本质的区别。

多Agent看起来很美，但在实际的落地过程却也有一地鸡毛的时候，加州大学伯克利分校等机构经过研究发表的《Why Do Multi-agent LLM Systems Fail》的论文指出了多Agent架构失败的原因：

1. 系统设计与规范问题（占37.2%）

核心问题：架构设计缺陷、角色定义模糊、对话流程管理不当。

● 违反任务规范：智能体未遵循任务约束

● 角色越权：智能体超出职责范围（如CPO擅自定义产品愿景）。

● 步骤重复：冗余步骤导致效率低下。

● 对话历史丢失：上下文截断引发逻辑断裂。

● 终止条件不明确：无法判断任务何时完成。

1. 智能体间协作错位（占31.4%）

核心问题：沟通机制低效、信息共享不足、协作流程失控。

● 对话重置：意外重启对话导致进展丢失。

● 信息隐瞒：关键数据未共享（如手机代理未告知API格式要求）。

● 任务偏离：讨论偏离核心目标（如32%的任务因跑题失败）。

● 推理-行动不匹配：逻辑推理与执行行为矛盾。

1. 任务验证与终止问题（占31.4%）

核心问题：验证机制缺失或低效、过早终止任务。

● 过早终止：未完成必要步骤即结束（如棋类游戏未验证规则）。

● 验证不完整：仅检查表面问题（如代码编译通过但功能错误）。

● 错误验证：验证逻辑存在缺陷（如接受非法棋步输入）。

从智能体间协作错位中可以看到，多agent不仅复刻了人类协同的形态，还把人与人沟通的坏毛病也学习了，会隐瞒，跑题和知行不一。

中场战事，推理“类Agent“的崛起

上面工程侧为了Agent输出更好的性能，想尽了办法极致压榨。模型侧也没闲着，也一直在探寻着新的Scaling Law。

OpenAI推出了推理模型O1，它的工作方式是在输出内容前先进行一次内部思考(推理)，然后再基于思考的结论来组织回答。这种分段式的生成像极了agent的工作方式，所以，我对O1的第一反应是openAI搞了个推理的agent？大模型Scaling Law到头了，改搞工程agent了？后来看到技术实现才得知O1是强化学习的产物，O1仍然是一个模型，但它像agent一样工作的模式以致我在后来把它们称为"类agent"模型。

犹抱琵琶半遮脸的O1

O1刚出来的时候，推理的过程是完全不可见的，一个Loading转了几分钟看不到里面发生了什么。OpenAI是这样解释原因的：

1. 技术权衡：思维链的忠实性和可读性是监控模型推理过程的前提，但若在思维链上加入政策合规性或用户偏好的训练，会破坏其有效性。因此，OpenAI选择不向用户展示原始思维链，以避免潜在的干扰。
2. 竞争优势：隐藏推理细节可保护核心技术不被竞争对手模仿，尤其是在模型逻辑推理能力显著超越同行的背景下。
3. 用户体验优化：原始思维链可能包含冗长且复杂的中间步骤，直接展示会影响交互效率。OpenAI转而提供模型生成的思维链摘要，以更简洁的方式呈现推理结果。

掀桌子的DeepSeek R1

DeepSeek是配得上伟大这样的赞誉的。

DeepSeek R1以更高的性能、低一个数量级的成本、开源的方式打脸了O1，掀翻了桌子。R1发布即公开了推理过程思维链的全部内容。DeepSeek成了真正的“OpenAI”。

DeepSeek公开了R1的训练技术细节：

● R1-Zero版本完全摒弃监督微调，通过多目标强化学习（创新的GRPO算法）整合准确性、推理速度与资源消耗指标。其中GRPO算法可以降低对标注数据的依赖，大大降低了训练成本。

● 但由于R1-Zero存在思维链的可读性问题，在R1的正式版的训练时，分拆成了两次的SFT+RL的步骤：

○ 加入了一些冷启动数据（思维链内容）对V3进行有监督微调，再强化学习得到较好的思维链可读效果；

○ 基于上一个Checkpoint模型生成60万条思维链内容再加上20万条生成的的示例数据进行监督微调，最后通过强化学习进行对齐得到R1。

过程如下图所示：

强化学习是后训练的Scaling Law

如果抛开思维链的可读性不谈，R1-Zero已经是一个高性能的推理模型，在Zero的训练细节上我们看到只需要强化学习就够了。R1-Zero向我们传递了一个最重要的信息：有针对性的强化学习训练的效果可能优于单纯增加大模型参数量做预训练的效果，这也是OpenAI O1背后的秘密。OpenAI看起来已经放弃了更大规模参数预训练模型的路子，而全面转向了后训练+强化学习，强化学习是新的Scaling Law。

强化学习，它不算是一种新技术了，它原理是通过生成结果对模型进行的奖励和惩罚反馈，让模型在无数次的生成和反馈中调整和优化并找到最有效的工作方式，而不需要教模型怎么做。

O1首先验证了新的训练路径，R1把全部的细节公诸于众，一时间，强化学习训练成了大模型厂商们的Next。Claude sonnet 3.7跟上了节奏推出推理版，并针对复杂的代码问题进行了强化学习，在生成代码方面性能较sonnet 3.5有显著提升；openAI 推出的DeepResearch就是基于O3端到端训练的Agent模型。

产品的R1“后遗症“

DeepSeek R1在2025年的春节期间爆火出圈，成了国民级的AI应用。R1的交互简单朴素，先是输出一大段思考过程，再生成最终的答案，输出推理的过程让用户避免了漫长的等待，在正式答案出来之前，阅读一下推理过程也是一件有意思的事。

R1的产品交互也瞬间成为了教科书级别的范例。它的两阶段输出的形态正快速统一Agent们的输出行为。

Agent不像LLM，能快速地开始输出答案，Agent通常有一系列的中间工作步骤，到最后一步才会输出给用户的答案，而这中间会有颇长的一段等待时间，为了缓解用户在等待过程的焦虑和优化等待体现，Agent们都很努力在尝试把中间过程也通过各种方式输出给用户：

例如ChatGPT是这样的：

dify是这样的：

我们的FoT Agent是这样的：

然而，这些努力并没有什么作用，Agent的用户们对这些输出的中间过程并不买单，抱怨看不懂，出结果又慢。

R1出来后，Agent产品们除了在模型层面光速接入DeepSeek之外，在产品交互也是象素级的致敬着R1。例如，我们的媒资助手Agent是一个基于DeepSeek V3的ReAct Agent，它把ReAct每一步思考（Thought）的过程组装起来，伪装成深度思考的过程，看起来毫无违和感：

还有微信读书的AI问书、微信输入法的问AI，底层的架构是基于小size的QWen模型做了SFT的Agent + Deepseek R1做最终解读，而在交互层，也是把Agent的工作过程和R1的思考融合呈现到深度思考的内容里了：

不再有花哨的loading和中间步骤的结构化呈现过程，只剩下朴实无华的“深度思考”样式的过程文本，也貌似让原来挑剔无比的用户满意了，感谢伟大的DeepSeek！端的是一个大道至简，大巧不工啊哈哈。

下半场：模型即产品与Agent社会化协同

我把OpenAI的Deep Research问世看作AI Agent下半场开始的标记性事件。Agent正式进入模型内化的新阶段。沿着中场战事的推理“类Agent”模型同样的进化路子，Deep Research基于O3通过端到端的强化学习得到了一个"真.Agent"模型。

模型即产品

Deep Research这个"真.Agent"有两个特点：

1. 端到端训练，就是它的训练是全链路的，对于做研报这个场景，从拿到问题、使用网络搜索工具、多轮验证重做到最终输出完整的研报的整个链路都在训练范围内。它不再像过去只让模型针对问题只做一次的文本输出。
2. Agent模型，对，Deep Research的工作形式是一个Agent，但技术上它是以一个模型出现的。在此之前，我们基于常规的LLM也可以做Deep Research这类型的工作，那就是写代码开发一个Agent（大家可以看到现在有很多开源版的Deep Research），这需要在工程侧来发力。但现在，OpenAI的Deep Research告诉大家，原来工程上要做的事情现在不需要了，我们只需要通过强化学习就可以让模型本身掌握原来要用工程来控制的工作方式，同时还能达到更高的质量。即，工程复杂度没了，效果还更好了。

对比一下O1和Deep Research:

● O1推理模通过强化训练“推理”能力，推理能力得到了质的飞跃

● Deep Research通过强化训练“做研报”的过程（包括使用搜索工具）和质量得到了一个做高质量研报的Agent。

嗯，AI Agent下半场的玩法变了：你想要什么样的Agent，通过强化学习训练一个Agent模型，而不一定要通过编写工程代码来实现它，而这个Agent模型就是一个产品。这就是最近流行起来的一个说法：模型即产品。说的是，未来针对场景化的产品需求，可以基于大模型通过强化学习对场景进行训练，最终交付一个Agent模型作为产品，不再区分什么模型层，应用层，而是模应一体了。就在前两周，OpenAI的O3也正式发布，O3表现出来的则是一个比Deep Research更通用的Agent模型。这进一步指明了Agent模型化、模应一体化的道路。

工程化Agent的生存空间

如果AI Agent的下半场是面向场景的端到端Agent模型的战场，那原来通过工程化手段做的Agent是否还有生存空间呢？答案是确定的，在接下来的一段时间内（至少两年），三种形态的Agent会持续共存：

1. 纯工程Agent，即由提示词工程加代码实现Agent，在产品的MVP阶段用于快速验证产品，或产品流量不大，对Token成本不敏感的场景，适合用这种方式落地。它的实现门槛低，包括技术实现和成本都一样，甚至通过当下流行的可视化Agent搭建平台，不用写代码就可以快速搭建起来。
2. SFT Agent，指针对Agent的行为（包括但不限规划和反思能力等）进行了有监督微调——目的是让指令跟随相对更稳定、节省提示词成本。实际上，节省提示词成本是做SFT Agent的最大的动机，相比起提示词token成本的下降，微调带来的指令跟随稳定性的提升可能没那么显著，这也是吴恩达一直说绝大多数Agent应用都能通过提示词来解决的原因。所以，SFT Agent较为适用于大流量但工具需要支持动态添加的场景。
3. 端到端Agent模型，即针对垂直场景，通过端到端强化学习进行后训练的模型。它适用于大流量且需求明确垂直的场景。

Agent才刚刚进入大众的视野，在技术和生态侧，随着MCP和A2A等协议的成熟及智能体生态的发展，Agent的进化会进一步加速，有更多的可能性在等待着我们。

Agent的社会化协同

以及A2A为代表的Agent间协同协议拉开了Agent社会化协同的大幕。

之前我们提的多agent和agentic workflo中的agent们的通讯，就如果我们在一个小团队里面紧密协同那样。而Google提出的A2A协议，把Agent之间的协同范围一下子提升到了全球的范围，它为每个Agent派发了身份证（AgentCard），在经过认识、握手后（鉴权），Agent们可以进行沟通和协作。

展开想象一下：

● 每个人都配套一个人个的Agent，用于代表你跟Agent的世界来交互，这个场景就很好玩了，跟朋友们约出去玩？让咱们的Agent们先商量一下，给我们一个方案；

● 买机票？我也不需要直接用某程的平台，只需要交代我的专属Agent，它自动发现和跟服务商的Agent（机构Agent）来沟通并支付就OK了。

● 你看，一个赛博数字世界就这么展开了。

我愿把这种场面称之为Agent的社会化协同，它将最大程度上复刻人类社会的形同范式，Agent间需要有验证机制，能互相加好友，具备支付能力，能主动发起任务等等。技术上，这将有模型技术之外的海量的agent社会基础平台等着被搭建。包括Agent通讯的安全、信用、支付体系等等。

致亲爱的乘客

做AI的领导者

AI正在对全行业进行无差别的颠覆，所有人都面临着工作方式的升级。不是说有全新职业的出现，而是大部份职业都会被要求原地升级 + AI。

我们每个人都会从个人劳动者转变成AI领导者，我们要提升自己的AI领导力。

过去，我们通过个人的专业能力来交付工作成果，个人要亲自去执行具体的任务。

现在到不远的未来，是我们带着AI一起工作并完成目标，我们作为AI的领导者，需要对AI团队进行目标设定，对AI协作过程进行管理和干预，对AI最终产出进行验收。

虽然执行性的工具会逐渐交给AI，但这并不意味着对个人的专业能力不作要求了。相反，它对我们的专业能力要求更高了，因为我们需要以内行人的角度来验收AI给我们产出的东西，减少的只是我们做具体任务的时间。

因为AI，未来可能每个行业都可能呈现出两头重，中间轻的形成。以软件开发这个岗位来做一下推演。

Vibe Coding这个词相信大家已有所耳闻，现在越来越多完全没有编程经验的人（暂称为小白）通过Cursor这类AI编程工具摇身变成了开发者，这类开发者自己动手解决长尾的、相对简单的个性化的需求，中低端的开发者的工作将会由小白们+AI来接管。但是大规模，严肃的生产型应用，小白 + AI也是无法掌控的，这个场景需要更专业的工程师，甚至是架构师+AI来支撑，AI一定是必备的了。可见，小白和架构师就是两头，初中级的工程师如果想要继续留在这个行业，是需要进一步提升自己的专业能力和AI领导力的。

所以：全面拥抱AI吧，以最快的速度。

我们的征程是星辰大海

当瓦特改良的蒸汽机轰鸣着撕裂中世纪余晖，当珍妮纺织机的梭子编织出工业文明的经纬，旧时代的质疑声总如潮水般涌来——1830年马车上挥舞的皮鞭在对抗铁路钢轨，1910年马车夫的咒骂声淹没在福特T型车的鸣笛中。历史总在证明：人类对变革的恐惧，终将被创新者的勇气锻造成进步的阶梯。

站在AI浪潮席卷全球的临界点，我们目睹着更宏大的技术跃迁。AlphaGo落子的清脆声响彻人类智慧圣殿，ChatGPT的字符洪流重塑知识生产边界，波士顿动力的机械骨骼正在突破生物运动的极限。如同十九世纪纺织女工面对蒸汽机时的惶恐，今日的焦虑不过是文明跃迁时的引力震荡。

但请记住：马车消亡时，人类获得了驾驭钢铁的速度；纺车停转时，世界收获了机械纺织的精度；而当AI接管程式化劳动，我们终将解锁更珍贵的创造力密码。凯恩斯曾在汽车取代马车的年代预言："我们终将学会游泳，在技术的海洋里。" 数据显示，自动驾驶技术每年将挽救全球130万条生命；AI医疗系统已能诊断出人类医生难以察觉的早期病症。

那些被技术重塑的行业，正在诞生更璀璨的新职业星辰：提示词工程师构筑人机对话的巴别塔，AI伦理师守护智能时代的道德罗盘，元宇宙建筑师在数字空间重构文明形态。正如马车夫转型为汽车司机，纺织女工成为流水线技师，每一次技术革命都在创造更高阶的人类价值。

不必困在技术性失业的叙事茧房，人类真正的对手从来不是机器，而是固守成规的思维惯性。当NASA用AI分析亿万光年外的星云数据，当脑机接口帮助渐冻症患者重获交流能力，我们分明看见：智能革命正在拓展人类探索的边疆。

心存焦虑时，请回望文明长河中的灯塔——蒸汽机没有埋葬人类，电力没有禁锢光明，互联网更未终结真实。我们的征途注定是星辰大海，在算法与神经元共舞的新纪元，唯有保持认知的流动性，在持续迭代中铸造不可替代性，方能在技术洪流中锚定航向。正如航海者从不诅咒潮汐，真正的勇者会将AI化作驶向星海的方舟。