今年是我在LLM应用层做开发的第二个年头，最直接的体感是：Agent这个词的含义正在悄悄迁移。一年前大家说"做了一个Agent"，多半意思是"让模型能调几个API、走完一个固定流程"——本质上还是工具；而今天再看，真正有壁垒的Agent项目，拼的是状态记忆、自我修正、多角色协作甚至主动发起对话，像把一个实习生培养成能和同事配合的老员工。这就是标题里说的"从工具到伙伴的范式跃迁"。这篇文章我想结合我读过的论文，以及今年在工业界落地Agent项目踩过的坑，聊聊这次跃迁究竟在跃什么：Agent框架和编排怎么选、为什么你写的只是Harness而不是Agent、记忆和技能怎么设计、最小可跑的ReAct骨架怎么写。全文按"旧范式为什么不行——论文里发生了什么——工业界现在怎么做——手写骨架验证"这条线展开，适合正在做agent开发、AI Agent平台搭建，或者被"agent框架与编排"绕晕的工程师。
1. "工具人"Agent的黄昏：先看清楚上一个范式长什么样
1.1 从Function Calling到"假Agent"
2023年年中OpenAI开放Function Calling之后，市面上80%的"Agent"其实是这么做的：你定义十几个函数，模型根据用户意图从中选一个，填好参数，程序执行完再把结果拼回上下文，让模型基于结果继续回复。整个过程像一条流水线，模型扮演的是自然语言路由器的角色，看起来能"用工具"，实际上还是人在写状态机。
这种模式最典型的特征是三无：无状态，每个请求进来都是全新的，上一轮聊了什么要自己塞进上下文；无主动，模型不会在你没下指令时自己干活；无纠错，工具返回一个异常值，它大概率会顺着错误继续说下去。工业界愿意用这套，是因为它可控、便宜、好上线。本质上还是把LLM当成一个更聪明的意图识别器，工具是手动挂上去的配件。
我当时参与过一个客服项目，用的就是这套。用户问"我的订单为什么还没发货"，流程是：识别实体→查订单API→查物流API→拼接回复。上线第一天效果还行，等到用户问"如果地址写错了怎么改，改了会不会影响发货时间"，整个链路就断了，因为模型没有能力自己拆解子问题，更不会去查"修改地址"这个它根本没见过的工具。
1.2 为什么"工具人"范式会不够用
把Agent当工具用，最大的问题是它扛不住真实的开放任务。真实业务里的任务往往长这样："帮我做一份本周行业竞品分析报告""根据这个文档生成一批投放文案，再按渠道适配格式"。这些任务没有固定路径，用户也不会给精确到函数名级别的指令，你需要的是一个能自己规划、拆解、验证、复盘的东西。
工具人范式有几个硬伤。第一，上下文窗口有限，跨多轮复杂任务时，早期信息会被截断，模型会"失忆"。第二，工具调用是单次决策，模型看不到自己上一次操作带来的全局影响，犯了错也不会改。第三，所有路径都要预先设计，业务一变化就要改代码，本质上是把复杂性从模型转嫁回工程师。第四，用户要的是结果而不是接口，工具人只能保证"我调用了搜索API并返回了一段话"，不能保证"我完成了你想要的调研"。
这不是说Function Calling没用。恰恰相反，工具调用是后来所有Agent能力的地基，只是它不应该成为Agent的全部。真正的转折点是让模型和工具、环境、用户之间形成"行动—观察—再行动"的闭环。
1.3 工业界对"工具人"的清算
2024年下半年开始，很多团队发现自己辛辛苦苦接了几十个工具，效果却不如一个"搜索+RAG+让模型自己写答案"的简单组合。原因很简单：工具人模式里模型没有决策权，所有分支都是预先画好的，遇到长尾需求就露馅。业界开始讨论"Agent不是工具链，而是目标驱动的执行者"。
我自己的判断是：工具人范式并不会消失，它会沉淀成Agent底座里的Tool Calling功能，而真正的产品价值会转移到模型之上的"伙伴层"——也就是有记忆、有反思、能规划的多轮执行系统。所以接下来我会从论文角度，把"从工具到伙伴"的跃迁路径拆开。
2. 论文里发生的三次跃迁：模型怎么一步步长出"伙伴感"
2.1 第一次跃迁：ReAct让"想"和"做"交替发生，Agent开始试错
如果要给这次范式跃迁找一个起点，ReAct（Yao et al., 2022）一定绕不过去。这篇论文的核心思想非常朴素：把推理轨迹（Thought）和行动（Action）交错起来，模型每执行一步工具，都能看到Observation反馈，基于反馈继续推理，而不是一次性输出终局。
这个改动在学术上叫"让模型与环境交互"，在工业界翻译过来就是：Agent终于可以试错了。以前的工具人是一次判定，错了就得人肉改Prompt；ReAct循环让模型能够在执行过程中修正自己的中间决策。比如搜索返回的结果不够精准，模型可以换一个关键词再搜一次，这在固定流程里是做不到的。
很多同学上来就学LangGraph、AutoGen，反而忽略了这层最基础的结构。其实你去面试被问"手写react agent"，考察的就是这件事：你有没有真正理解"Thought→Action→Observation"的循环是Agent的最小闭环。这个循环一旦成立，Agent就不再是一个函数调用器，而是一个"会想一步、做一步、看一步"的执行者，这是伙伴感的第一要素：它不是蒙头干，它会边干边判断。
2.2 第二次跃迁：Reflection与自我纠错，Agent开始复盘
工具人不会复盘，做错了就错了，下一轮接着错。但如果你想让它像伙伴一样值得托付，它必须能从失败里学。这就是Reflexion（Shinn et al., 2023）那一批论文做的事：模型执行完任务后，根据外部反馈（比如测试用例跑不过、工具报错、用户说不对），生成一条语言反思，存进记忆，下一次尝试带着这条反思重新规划。
吴恩达在2024年的Agent教程里反复强调的四种设计模式——Reflection、Tool Use、Planning、Multi-Agent Collaboration——把Reflection排在第一位，是有道理的。它是给Agent装上"复盘"机制：每次任务结束，不只是交结果，还会更新自己的"行事档案"。
工业界的落地场景我再熟悉不过：模型写一段代码，跑测试挂了，如果只是把报错信息塞回去让它改，往往改两三次就陷入重复输出。加上一层反思Prompt之后，模型会明确说"上次失败是因为没有处理空指针，这次我先判断输入为空的情况"，之后成功率明显上升。这种"基于历史进行改进"的能力，才是从工具到伙伴的第二把钥匙：工具坏了就坏了，伙伴会说明天不再犯。
2.3 第三次跃迁：记忆与规划成为一等公民，Agent开始有连续性
伙伴不是陌生人。你上次跟它交代过什么、它上次犯过什么错、你偏好什么风格，这些信息如果全丢，每次都要重新自我介绍，那就还是工具。所以第三次跃迁来自记忆和规划两大方向。
MemGPT（Packer et al., 2023）提出了操作系统式的记忆管理：上下文相当于内存，外部向量库相当于磁盘，模型像操作系统调度进程一样，把重要信息随时换入换出。这解决了"长对话中模型失忆"的问题，也是现在Agent记忆系统的理论源头。ExpeL（2023）则让Agent把经验抽象成语料存下来，遇到类似任务直接调用，相当于人从过往项目里总结方法论。
规划方向更偏工程直觉：Plan-and-Execute（2023）让模型先写一份可执行的步骤清单，再逐布执行，而不是每一步都临时想。这对长周期任务极其重要，因为它给了Agent一个"全局视角"，让中间每一步都能对照目标，而不是走一步算一步。
至此，论文脉络里的"伙伴"已经轮廓清晰：它不是单个模型的能力，而是推理循环、反思机制、记忆管理、目标规划的组合装。你单独把模型扔给用户，它还是工具；把这些组件拼起来，它才开始像一个能共同做事的伙伴。
3. 工业界实战：框架、Harness和编排，别再被概念绕晕
3.1 先分清模型、Agent与Harness：你写的其实是个壳
很多同学以为Agent是模型的一个属性，选一个"聪明"的大模型就等于有了Agent。这是今年最常见的技术概念误区。实际上，Agent是一个系统，你可以把它拆成四层：模型大脑、Harness（运行时编排）、工具集（手）、记忆库（档案）。其中Harness这个词，最近在圈子里讨论度很高，我理解它指的是包在模型外面那层执行框架：负责推理循环、上下文组装、工具注册、状态管理、安全策略。
所以当有人问"Harness和Agent区别"，我的答案很简单：Agent是完整系统的抽象，Harness是让Agent跑起来的脚手架。你用LangGraph、CrewAI或者自研代码搭的那套东西，属于Harness；模型本身也只是组件；两部分合起来才构成一个随时可用的Agent。
这一点特别像公司里的大学生入职：模型是那个聪明但缺经验的新人，Harness是公司的管理体系——工牌、流程、会议、绩效考核，工具是办公电脑和软件，记忆则是员工档案。你光招一个聪明人回来，不给他流程和档案，他也成不了得力伙伴。
3.2 主流框架怎么选：别只看Star数
工业界的框架现在可以用"泛滥"来形容，我给团队选型时只看三件事：状态可控性、生态完整度、调试成本。下面这张表是我基于实战体验整理的，不完全权威，但可以帮你少走弯路。
| 框架 | 核心抽象 | 适合场景 | 上手成本 | 备注 |
|---|---|---|---|---|
| LangGraph | 图状态机 | 复杂流程、需要严格状态控制 | 中高 | 生态大，组件全，适合企业级 |
| AutoGen | 多Agent对话 | 研究、模拟、多人协作实验 | 中 | 微软维护，Human-in-the-loop方便 |
| CrewAI | 角色扮演 | 快速原型、小团队Agent | 低 | 理念清晰，但复杂流程控制较弱 |
| MetaGPT | SOP流水线 | 软件开发模拟、标准化任务 | 中 | 让不同角色按SOP协作 |
| OpenAI Agents SDK | 托管Agent循环 | 快速接入OpenAI生态 | 低 | 定制受限，深度逻辑要绕 |
| Spring AI AI Agent | Java原生 | Java团队转型LLM应用 | 中 | 如果你身处Java栈，建议看看 |
我给的建议是：做POC用CrewAI或OpenAI Agents SDK，因为快；做生产系统用LangGraph，因为你要的"人类审批、并行分支、状态回滚"它都有；如果你是Java团队，Spring AI Al Agent能少踩一半跨语言坑。但无论选哪个，先手写一个ReAct循环再去用框架，否则你根本看不懂框架的报错。
3.3 多Agent协作的正确姿势：不是拉群聊天
吴恩达教程里四种模式中，Multi-Agent Collaboration是让人最兴奋也最容易翻车的。很多人以为多Agent就是让两个模型互相发消息，结果跑起来发现两个Agent在那里绕圈聊"你觉得呢/我觉得可以"，钱花了一半没产出。
我的实践结论是：多Agent要生效，靠的不是模型对话，而是角色边界和消息路由。你要明确每个Agent的职责说明书（System Prompt），要约定它们共享的工作区（如数据库里的任务表），还要有一个Router或仲裁者去决定"这条消息该发给谁"。
举个例子，我做竞品分析Agent时用了三个角色：检索Agent负责找资料、分析师Agent负责提炼框架、主编Agent负责审核并定稿。它们之间不直接闲聊，而是把半成品写到共享状态里，主编Agent读取后决定"通过"还是"打回"，打回时带上具体修改意见。这样跑起来非常稳，因为每个Agent都在做自己最擅长的事，而不是互相假装做对方的事。
经验之谈：两个Agent时效果会有明显提升，超过三个Agent，必须在Harness层加上最大轮数限制和话题收敛机制，否则大概率会出现我反复遇到的"agent execution terminated due to error"——不是模型崩了，是死循环把任务执行器干超时了。
3.4 部署与并发：AI Agent怎么扛并发
热词里有个问题我很喜欢：AI Agent怎么扛并发。很多团队在开发环境跑通一个Agent就以为能上线，一压测就傻眼：Agent不是一个HTTP请求，它是一段可能运行几十秒甚至几分钟的任务流，普通的同步接口根本扛不住。
我的方案分四层。第一层是API无状态化，每次客户端请求只创建一个任务实例，拿到Task ID就走。第二层是任务队列，用Celery或Temporal托管工作流，让Agent的每个步骤变成可重试的任务，这样宕机也能从断点恢复。第三层是LLM调用限流与重试，给每家模型厂商单独建配置，比如QPS上限、超时时间、退避策略。第四层是状态外部化，把Agent的中间上下文放到Redis或向量库里，而不是留在内存里，这样多实例可以共享同一任务状态。
另外，长任务运行一定要有"观测面板"。轨迹追踪比指标更重要，我和团队Debug时最常用的就是一段段看Thought和Observation，看是哪一步让Agent跑偏了。如果你在docker容器里跑Agent，记得把日志和向量库目录挂到宿主机持久化，不然容器一重启，Agent失忆，那才是真的灾难。
4. 让Agent"有伙伴感"的三大基石：记忆、技能和安全
4.1 记忆体系：从"写在Prompt里"到"分层存储"
伙伴最大的特征是记得你们之前发生过什么。Agent要建立这个能力，不能只靠把聊天记录塞进上下文，而是要分层存储。
我现在的标准做法是三级记忆：短期记忆放当前会话，工作记忆放任务执行过程中的中间状态，长期记忆放知识沉淀。具体到存储：短期记忆就是上下文窗口，靠摘要压缩控制长度；工作记忆存到Redis，数据结构是一个Task ID对应的状态JSON；长期记忆放进向量库，同时配合一层摘要库做实体关系。
最接近这个理念的论文是MemGPT，它把上下文比作内存，外部存储比作磁盘，Agent在"内存不足"时自动把早期内容写到"磁盘"，需要时再读回来。工程上我复刻了这一套：每个会话维护一个摘要，摘要超过阈值就触发归档，把最新N轮文本和旧摘要一起发送给模型，让模型输出更新的压缩摘要。这样即使对话很长，Agent也始终记得"用户最在意什么、上次结论是什么"。
4.2 技能沉淀：Skill不只是"工具注册"
最近"Agent Skill"这个概念很火，尤其随着Claude Skills等新特性出现，大家意识到：Agent不应该只是调用一堆无脑函数，它应该拥有可以被复用的"技能包"。
我用了一个叫"技能契约"的文档格式，每个技能包含五个部分：使用场景描述、触发条件、输入输出Schema、工具调用示例、失败处理策略。比如"生成周报"这个技能，不只是调一个生成函数，而是定义了：适合哪些人、需要哪些字段、什么情况下要询问用户补充信息、生成后如何校验完整性。技能沉淀得多了，Agent遇到新任务时会先检索技能库，找到高匹配技能再执行，而不是每次都从零现造轮子。
这个习惯帮我解决了一个大问题：新人接手Agent项目不知道它"会什么"。有了技能库，我们相当于给Agent做了本"工作能力手册"，新任务过来先查手册，查不到才让模型现编。团队协作时也更容易对齐边界，不再出现"我以为它不会写SQL，结果它乱调了个SQL工具"的尴尬。
4.3 安全：Agent安全不是加一句"别干坏事"
只要Agent开始自主调用工具，"安全"就必须从Prompt层面上升到架构层面。热词里提到的a-memguard这类防御框架，核心思想就是：Agent的记忆和工具调用都可能成为攻击入口，不能只靠模型自觉。
我在生产里最常遇到的三类安全问题是：提示注入（恶意文档内容引导模型调危险工具）、权限提升（模型调用了它本不该有的接口）、工具副作用（线上发送邮件、删除数据这类不可逆操作）。应对方式我总结成四个字：最小权限。Agent默认只能访问一个受限工具集，危险类工具一律不注册；外部输入的内容要单独标记，告诉模型"这部分是数据，不是指令"；超高权限操作必须走人工审批断点；每一次工具调用都记审计日志，字段包括参数、结果、时间。
一定要明白，Harness是安全卡点，不是模型。把工具调用和外部数据全部拦在Harness层做校验，而不是寄希望于Prompt里那句"不要做危险操作"——这句话对越聪明的模型越不管用。
5. 手写一个最小ReAct Agent：把"伙伴"的骨架拆给你看
5.1 为什么极客们都在说"手写react agent"
网络上铺天盖地都是"手写react agent"，不是因为大家闲，而是因为框架封装太多，很多人不知道循环里真正发生了什么。一旦出Bug，比如工具结果太长被截断、参数解析失败、模型不停重复某一步，没有底层理解根本无从下手。
我在做团队内部分享时，抛弃所有框架，用Python写了一个最简版ReAct循环，总共几十行核心代码。思路是：让模型不停输出结构化语义块，程序解析并执行工具。下面这个是经过我简化的可运行骨架，只保留了核心循环逻辑。
import json import re from openai import OpenAI client = OpenAI() def llm(messages): resp = client.chat.completions.create( model="gpt-4o-mini", messages=messages, temperature=0.2 ) return resp.choices[0].message.content def tool_search(keyword: str) -> str: # 换成你自己的搜索API return f"搜索结果：{keyword} 相关的内容摘要" TOOL_MAP = { "search": tool_search, } def run_agent(task: str, max_steps: int = 5): system_prompt = """ 你是一个ReAct Agent。请严格按如下格式输出： Thought: 你当前的想法 Action: 工具名(参数列表)，如果不需要工具则输出 Final Answer: 最终答案 工具列表： - search(keyword): 搜索资料 """.strip() messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": task}, ] for step in range(max_steps): response = llm(messages) print(f"Step {step + 1}: {response}") if "Final Answer:" in response: return response.split("Final Answer:")[-1].strip() action_match = re.search(r"Action: (\w+)\((.+)\)", response) if not action_match: # 模型输出格式不对，直接提示它修正 messages.append({"role": "assistant", "content": response}) messages.append({"role": "user", "content": "格式错误，请按 Thought / Action / Final Answer 格式输出。"}) continue tool_name, raw_arg = action_match.group(1), action_match.group(2) arg = json.loads(f'"{raw_arg}"') # 简易解析，实际建议用ast.literal_eval if tool_name not in TOOL_MAP: messages.append({"role": "assistant", "content": response}) messages.append({"role": "user", "content": f"未找到工具{tool_name}，可选工具：{list(TOOL_MAP)}"}) continue observation = TOOL_MAP[tool_name](**{"keyword": arg}) messages.append({"role": "assistant", "content": response}) messages.append({"role": "user", "content": f"Observation: {observation}"}) return "达到最大步数，任务未完成" if __name__ == "__main__": print(run_agent("帮我搜索AI Agent的行业动态"))这个骨架谈不上工程化，但完整体现了Agent的核心循环：模型思考、决定动作、执行工具、把观察结果喂回去、再决定下一步。看懂它，你再看LangGraph的每个Node和Edge，会发现一切都是这个循环的抽象和扩展。
5.2 把记忆和反思加进去，代码就开始"像伙伴"了
光有ReAct循环，模型还是容易重复犯错。我给骨架加上一个极简的反思记忆：每轮结束后让模型用一句话总结"当前进展和失败原因"，存进messages数组，下一轮带进去。这样模型在遭遇一次失败后，下次会根据反思调整行动，而不是无脑重试。
这种做法其实已经把Reflexion的论文思想落地了。真正的生产系统里，你不需要让模型输出完整的反思长文，只让它输出一个"下一步修正计划"即可，同时控制反思令牌长度，避免上下文膨胀。加上这一步之后，Agent就具备了最基础的"从错误中学"的能力，这离伙伴感已经近了一大半。
5.3 一个真实"翻车"案例：模型陷入工具循环怎么办
这个骨架我第一次实际跑的时候，遇到一个特别典型的问题：模型每次搜索返回的长文本被截断，但它不知道内容不完整，仍然以为"没搜到"，于是反复调用同一个搜索词，直到步数耗尽。报错信息就是那行经典的"agent execution terminated due to error"。
后来我加了两个规则才解决：一是Observation必须限制长度，宁可截断也要明确告诉模型"以上是截断后的结果"，避免模型误以为自己拿到的就是全部信息；二是增加"重复动作检测"——如果连续三步都在调用同一个工具、同一个参数，Harness直接打断，提醒模型换策略。这个规则特别重要，不管用哪种框架，都建议在设计Agent时加上。
这个例子恰恰说明了为什么我坚持让大家手写一遍最小Agent：只有你亲手踩过"工具循环"的坑，才能在框架里找到对应的参数去防它。上来就用框架，你连该防什么都不知道。
6. 范式跃迁给工程团队带来的三个心法
6.1 把"结果保障"放在"模型聪明"之前
工具人时代，模型选对工具就行，系统哪怕笨一点也能跑。到了伙伴时代，系统必须在模型犯错时还能兜底。我不止一次看到团队沉迷于追最新大模型，却连最基础的输出校验都没做。
我的建议是，每个Agent步骤都要有三道闸：入口校验（输入是否符合预期）、执行校验（工具调用是否成功、结果是否合理）、出口校验（最终答案是否满足任务目标）。任何一道闸不过，要么触发重试，要么转人工。模型再聪明，也扛不住你不给它反馈机制。
6.2 评估指标要跟着范式变
工具人用"准确率"评价就够了，伙伴型Agent必须看"任务完成率和成本"。现在工业界聊Agent评测，离不开轨迹质量分析：模型有没有重复调用工具、有没有走过无效路径、有没有在关键步骤上做出正确判断。这些信息必须靠详细轨迹日志才能提取。
我们团队现在每周做一次Agent Case Review：把上周线上用户跑的轨迹抽出来，看完成率、平均步数、失败点分布，再决定是调Prompt、加工具还是改Harness。这套流程比任何Benchmark都实在，因为Agent的很多问题只有真实流量里才会暴露。
6.3 对工程师的技能要求变了
以前做LLM应用，核心技能是写Prompt和接API；现在做Agent开发，你得懂Harness、状态管理、任务编排、记忆存储、安全边界。所谓"agent八股"背后其实是这些知识，面试官追着问ReAct、Reflection、Multi-Agent，不是真让你背定义，而是考察你有没有把一个长任务从头到尾理清楚的能力。
如果让我规划一条学习路线，我会说：先手写一个ReAct循环，再把MemGPT的记忆分层用伪代码实现一遍，然后选一个框架做一个小型多Agent项目，最后认真做一轮评估与调优。走完这条路，你对"Agent"这个词的理解，会和拿Prompt模板糊出来的感觉完全不一样。
个人实际做项目最深的体会是：从工具到伙伴的范式跃迁，不是模型突然变聪明了，而是系统的分工变了。模型负责推理和表达，Harness负责流程和兜底，记忆负责延续，安全负责边界。把Agent当成刚入职的同事，给它目标、给它工具、让它犯错后复盘、必要的时候给它权限但留下审计——想清楚这一点，很多技术选型都会变得容易很多。这个系列后续我会继续写Agent的评估与可观测性、多Agent协作的工程化细节，如果你也在做类似的事，欢迎在评论区留下你踩过的坑。
