DeepSeek新论文公开Agent训练！梁文锋署名——这句话在AI圈里比“又发了个新模型”更具杀伤力。它把Agent能力怎么练出来的问题，从“调提示词加套框架”的暗箱里拖到了台前。这几天技术群里反复讨论，但很多人还停留在“就是教模型调用工具”的层面，这理解偏差挺大。真正值得拆的，是这篇论文对训练数据、中间反馈、探索与停止这几件事的组合方式，而这些刚好也是我做Agent落地这两年里反复踩坑的地方。

我先把它的价值定个调：如果论文的核心趋势成立，那意味着Agent能力会从“外挂式推理”变成“内建式反射”，模型不再需要每次都在上下文里现学工具用法，而是在训练阶段就把“行动→观察→反思→再行动”的节奏沉淀进权重里。下面我会按五条线走：论文释放的信号、训练方法论、最小可复现环境、数据与评测闭环、故障排查。我不打算复述论文目录，而是把它翻译成能直接落进你项目的动作。

1. 这篇论文输出的最大信号:Agent从“外挂”转向“内建”

1.1 以前我们做的Agent，本质是给语言模型贴一层行动包装

回看2023到2024年做的Agent，绝大部分是外挂式:选一个基座模型，塞进一大段工具描述，规定输出的JSON格式，再写一个外层循环去解析模型返回的function call,执行完把结果塞回历史记录。整个链路里，模型被当成“决策大脑”，但它从没在训练阶段真正看过“工具返回报错应该怎么办”这类数据。它只是在上下文里随机应变，变好变坏全靠提示词写得多细致。

这个模式有三个绕不开的痛点。第一是token浪费严重，每轮把工具描述重复一遍，长任务跑下来成本非常难看。第二是模型容易沿着错误中间结果继续编，工具没调用成功，它也能顺着假想的结果往下输出。第三是上下文一长，模型很难记得早前哪一步吃了亏，经常在同一个坑里反复横跳。说到底，底层训练目标还是“下一个token预测”的打法，没有把“失败的尝试也是一种轨迹”纳入监督信号。

外挂Agent像什么?像一个只会背规则书的新员工，你每次把操作手册塞到他面前，他照着做，但一遇到手册没写的情况就手足无措。内建Agent则是一个在学校里直接做过完整项目的毕业生，他见过失败的流程，也见过怎么从失败里爬出来，这些东西已经变成他处理问题的本能。

1.2 署名位置透露的方向判断

这篇论文的署名结构很有意思。深度学习论文里，前排作者通常是直接动手设计实验、洗数据、调训练的成员，而靠后的署名往往代表研究方向的实际掌舵者。你的名字出现在Agent训练论文上，信号很直接:这个团队认为，Agent能力不应该永远停留在“框架+提示词”层面，而是要在模型训练环节里解决。

我把这件事翻译成工程语言就是:未来半年到一年，Agent相关的进展会更多出现在数据配方、奖励设计、训练策略和评测方法上，而不是只在应用层堆更长的提示词。对做业务的人来说，这意味着过去靠“加工具描述、加few-shot示例”换来的效果提升会遇到天花板，真正有壁垒的是谁能拿到更高质量的多轮轨迹数据，谁能让模型把“怎么用工具”内化成稳定能力。

1.3 这篇内容适合谁

我把目标读者分成三类。第一类是业务集成工程师，他们更关心“怎么把DeepSeek的API、本地部署、Codex接入、企业微信机器人这些事跑通”。第二类是算法工程师，他们关心SFT的数据格式、RL的奖励设计，以及从业务日志里反哺训练数据的方法。第三类是想转型Agent开发的初学者，可以先通过后面的最小harness代码理解整套循环是什么，跑通后再回头研究训练细节。每一类都能在下面的章节里找到对应的操作入口。

2. 拆解Agent训练方法论:SFT、RL、探索与停止

2.1 冷启动别用“完美轨迹”，要带伤的

不管哪个Agent训练pipeline，第一步都是准备多轮轨迹数据。所谓轨迹，就是“用户提出任务→模型决定调用某工具→工具返回结果→模型继续决策→最后给出答案”这样的完整记录。很多人准备数据时有个误区:只挑成功路径，把失败过程全部过滤掉。结果模型上线后遇到第一个异常返回，立刻不知道怎么处理，因为它压根没见过长得这么丑的中间状态。

以我的经验，至少保留三类轨迹。第一类是成功且顺畅的，用来保证基础正确率。第二类是开头失败、后来通过换工具或换参数纠正的，用来教模型“试错和恢复”。第三类是最终放弃或请求用户澄清的，用来教模型“什么时候该止损”。后面两类看起来像脏数据，实际是Agent训练里含金量最高的部分。数据格式通常是一行一个JSON对象，字段包含用户的输入、模型的推理内容、工具调用名和参数、工具返回结果，这四样缺一不可。

这里有个容易忽略的小技巧:长轨迹需要切片。一个真实任务动不动几十轮，直接整段扔进训练会让上下文窗口爆炸，而且模型也学不到“局部回合”的决策规律。我习惯按“目标拆分点”切，比如某个临时子任务结束，就切一段;或者按token预算自动断，再给每段补上精简的背景说明。这样既保留多轮参考价值，又不至于把算力都耗在长序列上。

2.2 SFT之后的RL，才是Agent训练的关键增量

冷启动用SFT，目的是让模型学会基本动作格式:看到工具描述能输出合法参数，看到工具返回能理解当前状态。但SFT教会的是“一步应该怎么走”，它教不会模型“整条任务怎么走得通”。想在多步决策上拉开差距，就得进入强化学习阶段，让模型通过试错去优化整条轨迹的长期收益。

为什么直接RL容易崩?因为Agent任务里奖励信号很稀疏，用户只说一句“帮我分析这个网站的数据”，十步之后才知道成没成功。中间任何一步都很难用最终结果来归因。解决办法是把奖励拆细，引入可自动验证的中间信号:代码任务可以用单测和断言，数据库任务可以检查查询是否落在合法约束内，网页任务可以断言关键元素是否出现。这种“过程奖励”比只算最终准确率稳定得多。

我注意到DeepSeek团队在推理模型上验证过一类叫GRPO的策略优化方法，它不依赖一个独立的价值模型，而是通过组内相对优势来估计收益。这个特性对Agent训练特别友好，因为Agent状态空间比纯文本推理更复杂，单独训练一个critic模型又贵又难稳定。社区里已经有大量复现沉淀，你完全可以在小规模模型上先做验证，而不必一上来就堆满资源。

2.3 让模型学会“知进退”比学会“调用工具”更难

Agent训练里一个常见的翻车现场:模型发现调用工具能带来更多探索空间，于是陷入死循环，反复执行同一个无效动作，要么烧光预算，要么把记录刷到上下文爆炸。训练时需要专门建模“停止”这个动作，包括两类:一类是任务实质性完成或不可继续，要能自然收敛到最终答案;另一类是连续几次失败后，要允许模型放弃并如实告诉用户“这个做不了”。

我自己的日记里有太多“机器人疯跑”的记录。一个负责批量读取网页的Agent，遇到反爬或超时后，会反复用同样的参数重试十几次，最后还编出一个假结果。后来我加了惩罚逻辑:同一工具调用失败超过两次，必须输出中间结论并请求人工确认;连续三个动作内容相似，视为无效探索，直接终止该分支。这些约束放到提示词里只能治标，真正治本的做法是把它们写进奖励函数，让“不撞南墙不回头”成为被惩罚的策略，模型才会真正长记性。

3. 从论文到工程:本地部署、API接入与最小Agent循环

3.1 本地部署从vLLM开始，不必一上来就追满血模型

很多人看到“Agent训练”四个字，第一反应是“我得先部署一个巨大的模型”。实际上个人开发场景用蒸馏后的小模型就够了，重点是验证循环逻辑，不是刷榜单。我个人推荐用vLLM起步，它自带OpenAI兼容的API入口，后面接什么客户端都不用改代码。

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-local \ --port 8000 \ --gpu-memory-utilization 0.9

启动后先拿curl探测一下:

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-local","messages":[{"role":"user","content":"你好"}]}'

7B这个量级的模型在做单工具、单目标Agent实验时够用了，占显存规模也很友好。手里只有Jetson Orin这类边缘设备，就去拉量化版本，用4bit或8bit推理，速度虽然不如大卡，但跑通一个端到端demo绰绰有余。想要冲更强效果，再考虑更大的模型或API方案，毕竟本地跑一次失败的Agent轨迹，成本约等于零，非常适合做数据收集。

3.2 把DeepSeek接进Codex、VS Code和Claude Code的工具链

线上API的接入就简单多了，DeepSeek提供OpenAI兼容接口，这意味着大量现有工具可以直接改环境变量或配置指向它。常见的做法是在终端里设置:

export OPENAI_API_BASE="https://api.deepseek.com/v1" export OPENAI_API_KEY="sk-你的key"

不同工具对模型名的要求不太一样，基础对话一般用deepseek-chat，复杂推理用deepseek-reasoner，具体以官网模型列表为准。接Codex类工具时，关键是确认它读取的是OPENAI_API_BASE还是自己的配置文件，一般在工具的config目录里改model_provider和base_url两个字段。

VS Code里用Continue或Cline这类插件，也是同样的思路。配置片段大致是这样:

{ "name": "DeepSeek API", "baseUrl": "https://api.deepseek.com/v1", "apiKey": "sk-你的key", "models": [ { "name": "deepseek-chat", "roles": ["chat", "edit"], "functionCalling": true } ] }

注意functionCalling这个字段。Agent场景必须让工具意识到模型支持原生函数调用，否则很多插件会退化成纯文本补全，压根触发不了工具循环。接入后先跑一个最简单的“列出目录文件”任务验证链路，再上复杂的自动化任务。

3.3 一个最小Agent Harness:让论文里的循环跑起来

为了把论文思路落地，我习惯搭一个尽量薄的harness:模型负责决策，外部代码负责执行，两者通过工具调用协议对话。这里给一个用Python和Playwright搭的最小版，目标是让模型能打开网页并总结内容。

import os import json from openai import OpenAI from playwright.sync_api import sync_playwright client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") MODEL_NAME = "deepseek-local" history = [ {"role": "user", "content": "打开 https://example.com 并总结第一屏内容"} ] def open_url(url: str) -> str: with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto(url, timeout=15000) text = page.inner_text("body")[:2000] browser.close() return text tools = [{ "type": "function", "function": { "name": "open_url", "description": "打开一个网页并返回正文前2000个字符", "parameters": { "type": "object", "properties": { "url": {"type": "string"} } } } }] for step in range(8): resp = client.chat.completions.create( model=MODEL_NAME, messages=history, tools=tools, tool_choice="auto" ) msg = resp.choices[0].message if msg.tool_calls: history.append({ "role": "assistant", "content": msg.content, "tool_calls": [ { "id": c.id, "type": "function", "function": c.function.model_dump() } for c in msg.tool_calls ] }) for call in msg.tool_calls: args = json.loads(call.function.arguments) result = open_url(args["url"]) history.append({ "role": "tool", "tool_call_id": call.id, "content": result }) else: print(msg.content) break

这段代码就是论文里“行动→观察”的最小运行时版本。模型如果连续失败，也只会按循环上限终止，不会写垃圾消息。把它跑熟以后，你可以把它接上数据库查询、内部API，渐渐扩展成自己的专用Agent。这里的关键不是框架多漂亮，而是历史消息里“assistant的tool_calls”和“随后紧跟的tool结果”必须严格配对，任何一步漏了，API都会直接报错。

3.4 把Agent暴露进企业微信这类业务入口

工具闭环跑通后，你真正想要的是让真实业务用户能用上它。企业微信这类IM是目前很常见的入口，因为业务同学不需要学习新的界面，发条消息就能触发后台处理。接入逻辑不复杂:后台开一个回调地址接收消息，解析文本后丢给模型，模型返回工具调用就执行对应动作，把结果生成回复再推回会话。

我通常会保留一个可配置的“人工确认”开关。比如Agent要执行写操作或外发消息时，先把结果推给审批人确认，点了同意才真正执行。这跟Agent训练的奖励设计是同一套逻辑——在线系统比起“每一步都自动”，更怕“出错后没有挽回机会”。日志是顺手攒下来的宝贵资产，每一段真实对话都记录了用户意图、模型决策、工具结果和用户反馈，这些正是下一轮迭代的轨迹数据来源。

3.5 成本与token消耗控制

很多团队兴冲冲把Agent接上线，跑了一周发现账单吃紧。Agent任务和普通聊天不同，20步的任务很常见，每步包含历史累积的输入，一轮下来几万token就没了。我的做法是三层控制:第一，把工具返回的长文本截断或摘要后再喂给模型;第二，历史消息窗口只保留最近几轮关键信息，更早的退化成总结;第三，给单任务设定时间上限和预算上限，达到后强制让模型产出阶段性结论。

4. 数据、评测与训练闭环:从业务日志里攒出自己的Agent语料

4.1 把日志结构化成一条可训练的轨迹

无论你接的是API还是本地模型，系统里每天都在产生大量对话和工具调用日志。把这些日志整理成训练语料，比从零开始标注省力得多。我推荐直接存成JSONL格式，每一行代表一个动作或一个结果:

{"role": "user", "content": "请查询昨天华南区的销售订单量"} {"role": "assistant", "content": null, "tool_calls": [{"id": "call_001", "type": "function", "function": {"name": "query_orders", "arguments": "{\"region\":\"华南\",\"date\":\"2025-02-01\"}"}}]} {"role": "tool", "tool_call_id": "call_001", "content": "{\"total\":120,\"orders\":[...]}"} {"role": "assistant", "content": "昨天华南区共120笔订单，明细如下..."}

这里要强调的是“状态标记”。每条tool消息必须能对回具体的tool_call_id，模型才能学会“哪个动作对应哪个结果”。不少团队第一批训练数据质量差，问题就出在日志系统把id弄丢了，导致模型被迫在动作和结果之间“猜关系”。

4.2 合成数据要谨慎，别让模型教自己学会小聪明

没有足够日志时，很多人会走Self-play或合成数据这条路。老模型生成轨迹，再由大模型过滤和修正，好处是量大，坏处是模型会把自己幻觉里的错误推理路径固化进新模型。我用合成数据时有三条铁律:一是必须有规则校验器过滤，工具调用格式不对的直接淘汰;二是每条合成轨迹至少混入一个真实人工日志，避免分布漂移;三是失败轨迹的比例不低于两成，否则模型上线后遇到异常还是会手足无措。

4.3 评测闭环:离线跑通不等于线上好用

训练Agent最容易遇到的问题，是离线评测一片绿灯、线上运行一地鸡毛。原因很简单，离线环境里工具返回是模拟的，线上工具会超时、报错、返回垃圾数据。我把评测拆成两层。离线层看几个硬指标:任务成功率、平均步数、无效工具调用率、预算内完成率。线上层则在灰度环境里记录同样的指标，同时留人工抽检日志判断答案是否合理。

我见过很多团队在离线评测上做得很漂亮，一脚踢到线上才发现最脆弱的环节是工具本身的不可靠性。所以在训练数据里刻意纳入“工具超时”“返回空结果”“输入参数非法”这些脏样本，看起来拉低离线分数，实际上是把线上防御能力提前训了进去。

4.4 小团队也可以做一个轻量RL实验

提起RL，小团队容易打退堂鼓。实际上只做一个子任务闭环并不夸张:选定一类任务，比如“查库存并给出补货建议”，准备一千条左右轨迹，用SFT冷启动一个7B模型，再套用GRPO或PPO优化。关键点是要有一条快速的模拟环境——库存查询mock、可重复执行的脚本——让模型在训练中能快速获得反馈。这一步的价值不只是刷分，而是验证“过程奖励”在你们业务场景下到底有没有用。

5. 常见问题与排查:这几个坑我基本都踩过

5.1 “messages tool calls need immediate results”是什么鬼

不少人在跑Agent框架时遇到“本轮运行失败，DeepSeek messages tool calls need immediate results”。这其实是API协议层面的硬约束:如果assistant消息里带了tool_calls字段，客户端必须在紧接着的消息列表里立即放上对应的tool结果，不能先插入其他内容，也不能漏掉某个tool_call_id。修复时最稳妥的做法是严格按照“assistant消息→tool结果消息→再发下一轮”的顺序追加历史，每个tool结果都要带上对应的tool_call_id。上面3.3的代码就是能跑通的参照结构。

5.2 “request extension preparation failed”怎么查

这通常是IDE或Agent客户端在调用本地扩展时报的错，根源大概率是配置对不上:base_url指向一个不通的地址、模型名和server端不一致、本地服务还没启动完毕。排查顺序我从上到下走一遍:先curl一下本地服务的/v1/models，确认模型名;再检查客户端的baseUrl是否以/v1结尾;最后看插件日志有没有拿到401或404。只要把最小请求用curl先跑通，问题十有八九会暴露在配置差异上。

5.3 部署时显存不够怎么办

vLLM跑大模型对显存极其敏感。遇到OOM，先砍--max-model-len，从默认长度降到4096或2048，比直接降低线程数更有效。再用--gpu-memory-utilization 0.8留出临时上下文空间。量化优先选FP8或AWQ，个人开发机实在不够跑7B，也可以用更小的蒸馏版本。Jetson Orin这类设备上优先选4bit量化，跑起来不会那么心疼散热。

5.4 Agent烧token和死循环的止损方案

业务Agent烧钱走火很容易被忽略，因为每一步看起来都便宜，乘上几十步就相当可观。我习惯在代码里写死三件事:最大步骤数、单步骤最大工具返回长度、连续相同调用最大次数。跑挂时先看日志，确认是哪一步触发了上限，再去调整提示词或奖励设置。死循环查下来最常见的原因是模型判断“再试一次有概率成功”，所以停不下来。判别逻辑里加上“同一工具同一参数重试两次即强制放弃”的规则，能过滤掉大部分无用消耗。

5.5 版本回退这件事，别硬追新

社区工具经常一天一个版本，源码仓库里大家也都在追rc版。如果你遇到新版本行为不一致，按自己项目锁定版本是正常操作。Git仓库直接看tag，比如v0.1.5-rc.2就在历史tag里;Python工具用pip install 包名==0.1.5rc2精确安装，别用latest。生产环境要的是可复现，不是最新。等你确认新版本的价值，再在测试环境里逐步升级也不迟。

写在最后:先跑通最小闭环，再谈复现论文

我看完这篇论文后的第一反应不是“好厉害，马上复现”，而是“这和我踩坑的路高度重合”。轨迹数据要带失败场景，奖励要拆细，模型必须学会停止，这三件事放到任何Agent项目里都是定海神针。如果你现在手头有一批业务日志，我建议别等FLOPs够大的团队出完整复现，先自己把“收集轨迹→SFT→跑通一轮评测”的最小闭环搭起来。你并不需要复现整篇论文，只要把“行动→观察→反思”这个循环从提示词层面搬进训练数据里，就已经比大多数外挂式Agent往前迈了一大步。