长程规划能力正成为智能体从“会聊天”走向“会干活”的分水岭。如果你让一个普通对话模型帮你“规划一次跨三地的商务出差”它通常能给出漂亮的大纲但如果你让它真正调度会议、订票、写材料、处理突发变更并连续跟踪三十个步骤问题就会集中爆发早期的目标被遗忘中间步骤之间互相矛盾某一步失败后整个计划不会自动调整。这不是提示词写得不够好而是模型缺少长程规划的核心机制。这篇文章要解决的核心问题是帮助你把“长程规划智能体”这个研究概念落地为一套可理解、可实践的技术方案。我的判断是要让智能体真正具备长程规划能力不能只靠堆提示词而是要靠“预训练打底、蒸馏提效”两条腿走路。预训练负责让模型拥有足够的世界知识、推理常识和工具使用基础蒸馏则负责把大模型的能力迁移到更小、更快、更可控的模型上让规划能力真正进入可部署的智能体系统。读完本文你会得到三样东西第一搞清长程规划智能体的核心难点以及预训练、微调、蒸馏在其中的分工第二理解 OPD 蒸馏在智能体规划领域的技术定位它是如何把教师模型的经验“在线”地转交给学生模型的第三拿到一份可复制的工程化原型代码包括任务规划、轨迹蒸馏、效果评估三个最小模块。1. 这篇文章真正要解决的问题智能体Agent这个概念在最近两年热度极高但不同人说的“智能体”可能完全不是一回事。有人说的是一个能调用工具的聊天助手有人说的是一个能自主完成多步任务的工作流引擎还有人说的是一个完整的多智能体协同系统。本文讨论的是更接近后两种的形态能够接受一个高层目标自主完成任务分解、逐步执行、中途纠偏、最终输出的长程规划智能体。这类智能体最典型的痛点有三个你可以对照自己的项目看是否命中错误累积问题。一步推理错了后面所有步骤都会被带偏而且越到后面越难发现。上下文失控问题。任务越长历史记录越多模型越容易丢失最早期目标或者被中间信息干扰。反馈稀疏问题。计划中的某些步骤要等很久之后才能验证对错模型无法及时调整策略。传统方案依赖人工编写大量决策规则但规则之间容易冲突且维护成本极高。近两年大家转向用预训练语言模型充当“规划大脑”同时用蒸馏、微调等手段把大模型能力压缩到可用的工程形态。可以说预训练和蒸馏不是两个孤立的技术而是长程规划智能体落地链条上最重要的两个环节。这篇文章适合三类读者正在研发智能体产品的工程师想解决复杂任务自动化问题的算法工程师以及对大模型蒸馏感兴趣的研究者。如果你只是想要一个能聊天、能写文案的工具本文的路线对你来说偏重但你仍然可以从中理解大模型应用的架构思路。2. 长程规划智能体的核心概念与难点2.1 什么是长程规划要理解长程规划先要区分“短任务”short-horizon task和“长程任务”long-horizon task。短任务指单步或少量步骤即可完成的任务例如“把这句话翻译成英文”“总结这篇文档”。这类任务对模型的要求主要是语言理解和生成能力。长程任务则指需要多步决策、长时间跨度、中间状态依赖的复杂任务典型例子包括组织一次行业峰会、完成一份企业数字化转型方案、开发一个带前后端的中型 Web 项目。这类任务的特点是一步错、步步错而且中间环节无法完全预判。在智能体研究里长程规划通常包含四个子能力任务分解把高层目标拆成可执行的子任务序列。状态追踪记住当前执行到哪一步、环境发生了什么变化。决策调度根据当前状态选择下一步动作并处理多个子任务之间的依赖关系。失败恢复某一步执行失败时能够回溯并重新规划而不是死循环。这四个子能力缺一不可。大部分“看起来不太聪明”的智能体往往不是模型本身笨而是其中一个或几个子能力没有真正实现。2.2 为什么长程规划如此困难长程规划之所以难核心原因在于它把“语言能力”和“决策能力”同时推到了极限。从语言模型的角度看推理链条越长Attention 越难覆盖早期关键信息。虽然现在的模型都有很长的上下文窗口但术语叫“有效上下文长度”才是关键——模型并不是把所有早期内容都同等重视。让模型记住“用户最初真正想要什么”可能比让它记住最新一条工具返回结果更难。从决策系统的角度看长程规划本质上是序贯决策问题Sequential Decision Making这就需要处理不确定性和稀疏奖励。模型做了十步操作到第十一步才知道前面第三步做错了这种反馈延迟会让常规的学习方法失效。一个经典的类比是把短任务模型比作能答对每一道“单选题”的学生长程规划则要求这个学生“完成一份毕业论文”。单选题和毕业论文对能力的要求完全不同前者看知识储备后者看结构设计、过程管理和自我修正。2.3 长程规划与普通 Agent 的区别普通 Agent 也可以调用工具、读取文档但它通常是被动响应用户的每一条指令。长程规划智能体则更像一个“项目负责人”你给它一个目标它自己排期、自己执行、遇到问题自己调整最后向你汇报结果。这个区别导致了工程实现上的重大差异维度普通 Agent长程规划智能体目标输入单条明确指令高层模糊目标任务粒度单步或几步数十到上百步错误容忍度低可重来高需要自动纠偏记忆要求上下文近景即可需要长期记忆与索引评估方式单次输出质量路径质量与最终结果并重理解了这些差异你再去读预训练和蒸馏相关的论文就能明白为什么研究者要专门设计新的框架来处理这些问题。3. 预训练在智能体规划中的角色3.1 预训练给智能体带来了什么预训练语言模型的本质是通过海量文本学习语言规律、世界知识和推理模式。对智能体来说预训练提供了三样基础资产常识知识。模型知道“订机票需要先确定日期和目的地”这不是规则写出来的而是从文本中学习到的。推理模式。模型在预训练阶段见过大量“因为……所以……”“第一步……第二步……”的文本结构这为它提供了一定的思维链基础。工具使用语料。代码、API 文档、操作说明书等语料让模型理解了“调用函数”“读取文件”“发起请求”这类动作的基本语义。没有预训练智能体的一切高层能力都是空中楼阁。这也是为什么现在主流的 Agent 框架都选择在预训练模型之上构建规划器而不是从头训练一个专用模型——后者的成本极其高昂且效果远不如预训练模型。3.2 面向智能体规划的预训练方式在智能体研究领域预训练并不只是指“语言模型预训练”还包括面向智能体任务的专门预训练阶段。常见的做法有以下几类预训练方式核心思想优势局限纯文本预训练在通用语料上训练基础模型通用性强覆盖面广缺少交互经验行为克隆BC用人类或模型演示数据训练模型模仿直接学习任务轨迹依赖高质量演示数据环境交互预训练让模型在仿真环境中试错学习获得真实反馈信号环境构建成本高世界模型预训练先学习环境动态再基于模型做规划能进行想象的推演世界模型偏差会导致规划失误需要特别说明的是预训练不是“一次性解决所有问题”。更准确的实践路径是先在通用语料上完成基础预训练让模型具备语言和常识能力再在智能体轨迹数据上进行后训练或微调让模型学会“如何做决策”最后再用蒸馏等方式压缩模型适配不同部署场景。3.3 预训练模型不能替代规划机制一个很容易犯的误解是模型能力越强长程规划就不需要额外设计了。实际工程中你会发现即使是最强的通用模型在长程任务中也会出现目标漂移、步骤遗漏等问题。原因在于规划能力不只是“模型在生成文本”而是“系统在控制一个决策过程”。因此成熟的智能体系统通常采用“预训练模型 规划器 记忆模块 工具层”的组合架构。预训练模型负责局部的推理和生成规划器负责整体的任务分解和进度控制记忆模块负责跨步骤的信息保存与检索工具层负责与外部系统的交互。预训练是地基但房子需要其他构件才能立起来。4. 蒸馏原理与 OPD 蒸馏思路4.1 知识蒸馏的核心思想知识蒸馏Knowledge Distillation最早可以理解为“让一个小模型学习大模型的行为”。大模型被称作教师模型Teacher小模型被称作学生模型Student。训练时不仅用真实标签监督学生模型还让学生模型的输出分布去接近教师模型的输出分布。为什么这样有效因为教师模型的输出分布中包含了“软标签”信息。举个例子分类任务中真实标签只说“这是一只猫”但教师模型可能输出“75% 是猫20% 是狗5% 是其他”这个分布里隐含了“猫和狗在外观上更接近”这样的信息。学生模型从这个软分布中能学到的东西比单纯学习硬标签多得多。在自然语言处理领域知识蒸馏有几种常见形式输出蒸馏学生模型模仿教师的输出分布这是最经典的形式。特征蒸馏学生模型模仿教师中间层的特征表示。关系蒸馏学生模型模仿多个样本之间的相对关系。4.2 从知识蒸馏到策略蒸馏知识蒸馏主要面向监督学习任务而智能体的规划任务更接近强化学习中的策略学习。于是“轨迹级蒸馏”成为关键思路教师模型在环境中执行任务生成一条完整的决策轨迹状态、动作、奖励序列学生模型学习在这条轨迹上模仿教师的动作选择。这就是策略蒸馏的基本形态。策略蒸馏的优点是学生模型学到的不只是“单步答案”而是“在何种状态下采取何种动作”的完整决策策略。对长程规划来说策略蒸馏比单纯蒸馏文本输出要有效得多因为规划的本质是决策而不是生成。4.3 OPD 蒸馏在线策略蒸馏在智能体和长程规划相关的研究讨论中OPD 这个缩写通常被理解为 Online Policy Distillation即在线策略蒸馏。有一点要提前说明不同论文对 OPD 的展开可能不同Online Planning Distillation、Offline Policy Distillation 等也是常见候选但本文从工程直觉出发把 OPD 理解为“在线策略蒸馏”来展开这是当前智能体蒸馏体系里最贴合项目落地场景的解释。在线策略蒸馏与离线策略蒸馏的核心区别在于教师经验从哪里来。离线蒸馏用静态数据教师模型生成一批轨迹后保存下来然后反复训练学生模型。在线蒸馏则让教师模型在与环境交互的过程中持续生成新轨迹学生模型跟着实时学习。这个过程可以理解成教师一边做项目一边带新人而不是把过去的项目报告扔给新人自学。对长程规划智能体来说在线策略蒸馏有三个明显优势第一数据分布与当前任务保持对齐。环境会变任务类型会变离线数据容易过期在线生成的数据则始终反映最新情况。第二学生模型可以边学边用。当学生模型在真实任务中出现偏差时在线系统可以及时发现并让教师模型重新示范。第三更接近真实部署的反馈闭环。长程任务中间步骤的成败信号本来就需要在线收集离线数据往往缺少这种细节。当然在线策略蒸馏也有代价训练过程更复杂需要管理教师模型的推理成本、学生模型的采样、以及两者之间的同步节奏。工程上一般不会每一轮都蒸馏而是采用“教师批处理 学生异步更新”的模式。4.4 OPD 在长程规划中的典型工作流一个完整的 OPD 长程规划智能体训练循环大致如下给定一个目标任务教师模型先生成初始规划。教师模型逐步执行规划在每步记录状态、动作、中间结果、最终反馈。学生模型同步观察教师轨迹并尝试预测“教师下一步会做什么”。用蒸馏损失更新学生模型参数使学生模型的学生输出分布接近教师模型。定期将学生模型部署到低成本推理环境替代教师模型执行部分简单任务。当环境或任务分布发生变化时重新启动教师模型生成新轨迹继续蒸馏。这个循环看起来简单但工程实现中有很多细节值得注意例如教师模型和学生模型的能力差距、蒸馏温度的选择、在线数据的采样优先级等。这些内容我会在第 8 章和第 9 章展开。5. 从论文到工程搭建一个长程规划智能体原型概念终归要落在代码上。这一章我们用最少的依赖搭建一个可运行的长程规划智能体原型。原型的目标是演示“规划—执行—反馈—重规划”的主循环并为后续蒸馏提供轨迹数据。5.1 环境准备与依赖建议使用 Python 3.10 及以上版本主要依赖如下openai调用大模型 API没有 API 时可以替换为本地模型接口tenacity重试机制处理网络抖动pyyaml读取配置文件torch、transformers训练蒸馏模型时使用# 文件路径requirements.txt openai1.0.0 tenacity8.2.0 pyyaml6.0 torch2.0.0 transformers4.30.0安装命令pip install -r requirements.txt注意具体版本请以实际项目为准本文演示的是通用思路。如果你没有 OpenAI 的 API 密钥可以将配置项model_name指向任何兼容 OpenAI 协议的本地推理服务原理完全一致。5.2 项目目录结构建议按下面的目录组织代码agent_core/ ├── config.py ├── planner.py ├── executor.py ├── memory.py ├── plan_and_execute.py training/ ├── distill_trajectory.py evaluation/ ├── eval_agent.py requirements.txt其中planner.py负责任务分解executor.py负责调用工具或模拟动作memory.py负责记录历史步骤plan_and_execute.py是主循环。5.3 规划器实现规划器的核心是让大模型把高层目标拆解为可执行的步骤并要求输出严格的 JSON。这么做的好处是后续执行器可以直接解析不需要依赖额外的文本解析模块。# 文件路径agent_core/planner.py import json from typing import List from tenacity import retry, stop_after_attempt, wait_exponential SYSTEM_PROMPT 你是一个长程规划智能体负责将复杂目标拆解为可执行步骤。 要求 1. 输出严格的JSON数组不要包含任何额外说明。 2. 每个元素包含 step_id、description、depends_on 三个字段。 3. step_id 为从 1 开始的整数depends_on 为当前步骤依赖的 step_id 列表。 4. 每个步骤必须能够在单次工具调用中完成。 5. 如果目标过于复杂优先拆解为 5-10 个步骤不要贪多。 retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def generate_plan(client, model_name: str, task_description: str) - List[dict]: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请为以下目标生成规划{task_description}}, ] response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content data json.loads(content) if isinstance(data, dict) and steps in data: return data[steps] if isinstance(data, list): return data raise ValueError(f无法解析规划结果{content})代码中的关键点有两个一是强制的 JSON 输出格式二是depends_on字段它定义了任务之间的依赖关系。后续执行器会用它来判断哪些前置步骤必须提前完成。5.4 执行器与记忆模块执行器负责模拟每一步动作。真实项目中它可能是调用数据库、发送 HTTP 请求、操作文件在原型里我们可以用一个简单的模拟函数代替重点是验证规划闭环是否跑通。# 文件路径agent_core/executor.py import random def execute_step(step: dict, context: dict) - dict: 模拟执行一个步骤。 真实项目中这里应该调用具体工具 - 查询数据库 - 调用第三方 API - 操作文件系统 - 发送消息通知 原型中使用随机数模拟成功与失败方便验证重规划逻辑。 step_id step[step_id] description step[description] # 模拟执行结果80% 成功率 success random.random() 0.8 result { step_id: step_id, description: description, success: success, output: f步骤 {step_id} 执行完成 if success else f步骤 {step_id} 执行失败, } context[history].append(result) context[executed_steps].add(step_id) return result记忆模块负责维护两条信息所有已执行步骤的历史记录和当前已完成的步骤集合。这些信息会在重规划时传给规划器让模型了解“现在已经做到哪里了、哪里出了问题”。# 文件路径agent_core/memory.py class AgentMemory: def __init__(self): self.history [] self.executed_steps set() def add_step_result(self, result: dict): self.history.append(result) self.executed_steps.add(result[step_id]) def get_context(self) - dict: return { history: self.history, executed_steps: sorted(self.executed_steps), }5.5 主循环规划—执行—重规划主循环把上面几个模块串起来。整体逻辑是先规划再按依赖顺序执行如果某一步失败则带着失败信息重新规划最多重试若干次。# 文件路径agent_core/plan_and_execute.py import json import openai from planner import generate_plan from executor import execute_step from memory import AgentMemory def plan_and_execute(task_description: str, max_replan_times: int 3, model_name: str gpt-4o-mini): client openai.OpenAI() memory AgentMemory() plan generate_plan(client, model_name, task_description) replan_count 0 while replan_count max_replan_times: all_done True for step in plan: if step[step_id] in memory.executed_steps: continue deps step.get(depends_on, []) if any(dep not in memory.executed_steps for dep in deps): continue result execute_step(step, contextmemory.get_context()) if not result[success]: print(f[ERROR] 步骤 {step[step_id]} 执行失败触发重规划) replan_count 1 new_plan generate_plan( client, model_name, json.dumps({ task: task_description, executed_steps: memory.get_context(), failed_step: result, }, ensure_asciiFalse), ) plan new_plan all_done False break if all_done: break return { plan: plan, history: memory.history, replan_count: replan_count, }运行入口# 文件路径main.py from agent_core.plan_and_execute import plan_and_execute if __name__ __main__: task 撰写一份智能体技术在制造业落地的调研报告包括背景、方案、案例和风险分析。 result plan_and_execute(task) print(json.dumps(result, ensure_asciiFalse, indent2))这个原型已经把长程规划智能体的核心骨架搭出来了后续可以在此基础上扩展真实工具调用、向量记忆、异步执行等能力。6. 蒸馏流程的核心示例代码规划主循环跑通之后下一步是训练一个更小、更快的学生模型让它学习教师模型的规划能力。这里演示一条最核心的蒸馏训练路径。6.1 生成教师轨迹在真实项目中教师模型的轨迹来自第 5 章中plan_and_execute的完整执行记录。每条轨迹包含用户的初始目标、模型的每一步规划、每一步执行结果以及最终输出。为了保证蒸馏质量建议保存为统一的 JSON 格式{ task: 撰写一份智能体技术在制造业落地的调研报告, trajectory: [ { state: 初始状态, action: 分解为8个子任务, result: 成功 }, { state: 已完成子任务1-3, action: 执行子任务4收集制造业案例, result: 成功 } ], final_output: 报告正文... }6.2 学生模型蒸馏训练这里使用经典的 KL 散度损失让学生模型输出的 token 分布去对齐教师模型。需要注意实际训练时学生模型和教师模型需要使用同一个 Tokenizer否则 logits 无法对齐。# 文件路径training/distill_trajectory.py import torch import torch.nn.functional as F from transformers import AutoTokenizer, AutoModelForCausalLM from torch.utils.data import DataLoader, Dataset class TrajectoryDataset(Dataset): def __init__(self, trajectories, tokenizer, max_length1024): self.trajectories trajectories self.tokenizer tokenizer self.max_length max_length def __len__(self): return len(self.trajectories) def __getitem__(self, idx): traj self.trajectories[idx] # 将 trajectory 序列化成一段文本 text f任务{traj[task]}\n轨迹{traj[trajectory][:10]}\n结果{traj[final_output]} inputs self.tokenizer(text, truncationTrue, max_lengthself.max_length, return_tensorspt) return {k: v.squeeze(0) for k, v in inputs.items()} def distillation_loss(student_logits, teacher_logits, temperature2.0): 使用 KL 散度计算蒸馏损失。 核心思想不是让学生模型简单模仿教师的 argmax 输出 而是让整个输出分布接近教师保留教师对“次优选择”的偏好信息。 student_logits student_logits / temperature teacher_logits teacher_logits / temperature loss F.kl_div( F.log_softmax(student_logits, dim-1), F.softmax(teacher_logits, dim-1), reductionbatchmean, ) return loss * (temperature ** 2) def train_step(teacher_model, student_model, batch, optimizer, temperature2.0): teacher_model.eval() student_model.train() input_ids batch[input_ids] attention_mask batch[attention_mask] with torch.no_grad(): teacher_outputs teacher_model(input_ids, attention_maskattention_mask) teacher_logits teacher_outputs.logits student_outputs student_model(input_ids, attention_maskattention_mask) student_logits student_outputs.logits loss distillation_loss(student_logits, teacher_logits, temperature) optimizer.zero_grad() loss.backward() optimizer.step() return loss.item()训练主循环代码可以这样写# 文件路径training/train_distill.py import json import torch from transformers import AutoTokenizer, AutoModelForCausalLM from distill_trajectory import TrajectoryDataset, train_step def main(): # 加载教师模型和学生模型实际项目中请替换成你使用的模型 teacher_tokenizer AutoTokenizer.from_pretrained(your_teacher_model) teacher_model AutoModelForCausalLM.from_pretrained(your_teacher_model) student_tokenizer AutoTokenizer.from_pretrained(your_student_model) student_model AutoModelForCausalLM.from_pretrained(your_student_model) # 加载轨迹数据 with open(trajectories.json, r, encodingutf-8) as f: trajectories json.load(f) dataset TrajectoryDataset(trajectories, student_tokenizer) dataloader DataLoader(dataset, batch_size2, shuffleTrue) optimizer torch.optim.Adam(student_model.parameters(), lr5e-5) model_save_path student_model_finetuned for epoch in range(3): total_loss 0 for batch in dataloader: loss train_step(teacher_model, student_model, batch, optimizer) total_loss loss avg_loss total_loss / len(dataloader) print(fEpoch {epoch 1}, Average Loss: {avg_loss:.4f}) if (epoch 1) % 1 0: student_model.save_pretrained(f{model_save_path}_epoch_{epoch 1}) student_tokenizer.save_pretrained(f{model_save_path}_epoch_{epoch 1}) if __name__ __main__: main()这里需要你记住一个关键点蒸馏不是替代任务微调而是在微调基础之上进一步提升学生模型与教师模型的输出一致性。如果你的任务希望学生模型具备额外的对齐能力、工具调用格式等还是需要结合传统的监督微调数据一起训练。6.3 蒸馏效果评估脚本蒸馏之后不能只盯着 loss 数字下降更关键的是看模型在长程规划任务中的实际完成质量。评估脚本建议从四个维度展开# 文件路径evaluation/eval_agent.py import json def evaluate_trajectory(plan, executed_actions, final_result): 评估一次长程规划任务的执行质量。 参数 - plan: 模型规划出的步骤列表 - executed_actions: 实际执行的步骤列表 - final_result: 最终结果包含 success、replan_count、token_cost 等字段 返回指标字典 - plan_completeness: 计划完整度指计划步骤被实际执行的比例 - task_success: 任务是否最终成功 - replan_count: 重规划次数反映模型的纠偏能力 - token_cost: 总 token 消耗反映部署成本 metrics {} exec_ids {action.get(step_id) for action in executed_actions} plan_ids {step.get(step_id) for step in plan} metrics[plan_completeness] len(exec_ids plan_ids) / max(len(plan_ids), 1) metrics[task_success] 1 if final_result.get(success) else 0 metrics[replan_count] final_result.get(replan_count, 0) metrics[token_cost] final_result.get(token_cost, 0) metrics[success_rate] final_result.get(success_rate, 0.0) return metrics if __name__ __main__: sample_plan [{step_id: 1}, {step_id: 2}, {step_id: 3}] sample_actions [{step_id: 1}, {step_id: 2}, {step_id: 3}] sample_result { success: True, replan_count: 1, token_cost: 12000, success_rate: 0.92, } print(json.dumps(evaluate_trajectory(sample_plan, sample_actions, sample_result), ensure_asciiFalse, indent2))评估脚本的使用方式分两种离线评估时把历史轨迹灌入模型让它复现每一步决策与传统基线对比在线评估时直接接入当前任务流统计成功率、重规划率、token 成本。7. 运行结果与效果验证7.1 如何判断原型跑通拿到第 5 章的规划原型后第一次运行可能会得到类似下面的输出示例{ plan: [ {step_id: 1, description: 分析用户目标确定调研范围, depends_on: []}, {step_id: 2, description: 收集智能体在制造业的案例, depends_on: [1]}, {step_id: 3, description: 分析实施方案与风险, depends_on: [2]}, {step_id: 4, description: 撰写报告大纲, depends_on: [3]} ], history: [ {step_id: 1, success: true}, {step_id: 2, success: true}, {step_id: 3, success: false} ], replan_count: 1 }判断原型是否跑通有以下标志模型输出了合法 JSON 规划且步骤之间存在依赖关系。执行器按照依赖顺序逐步执行没有被某个长步骤卡死。某一步失败后模型收到了失败信息并触发了重规划。最终任务在指定重试次数内完成或者返回了明确的失败原因。如果程序直接崩溃优先检查 JSON 解析是否失败以及execute_step的返回格式是否被主循环正确读取。7.2 蒸馏训练的验证方式蒸馏训练结束后你最容易犯的错误是只看 loss 下降就认为成功。长程规划场景中更可靠的验证指标是“替代指标对比”在固定测试集上分别用教师模型、蒸馏前学生模型、蒸馏后学生模型生成规划。用第 6.3 节的评估脚本计算三种模型的任务成功率、平均规划步数、重规划次数。对比蒸馏前后学生模型在相同测试集上的表现差距。一个合理的验收标准是蒸馏后的学生模型任务成功率下降不要超过教师模型的 10% 到 15%但推理耗时和部署成本可以有明显下降。具体阈值因项目而异不设定统一数字。7.3 失败时的第一步排查如果蒸馏后学生模型的表现不升反降不要急着调模型按下面顺序排查检查训练数据是否包含足够多的“失败轨迹”。如果教师模型只生成成功轨迹学生模型就学不到失败恢复能力这是长程规划蒸馏中最常见的数据偏置问题。检查教师模型与学生模型的能力差。如果差距过大蒸馏损失会一直很大学生模型难以拟合可以考虑使用辅助输出损失。检查温度系数。温度太低软标签信息不足温度太高训练不稳定。常见范围是 2 到 4但需要实验来确定。8. 常见问题与排查思路问题现象可能原因排查方式解决方案规划结果无法解析成 JSON模型返回了额外文字或 Markdown 格式查看模型原始输出内容和错误堆栈使用response_format强制 JSON增加解析后校验规划步骤执行到一半就丢失目标上下文过长导致早期目标被覆盖检查主循环中传递给模型的 context 是否包含完整目标引入“目标固定区”重规划时始终保留原始目标字段重规划后执行了重复步骤执行器没有记录已完成步骤集合检查 memory 中的 executed_steps 是否持久化在重规划前将已完成的步骤 id 显式传给规划器蒸馏后的学生模型动作格式全错学生模型没有见过工具调用的格式规则查看学生模型生成样本与教师模型样本的差异在蒸馏数据中加入少量带格式注释的任务微调数据在线策略蒸馏训练不稳定教师模型在线生成的轨迹分布波动大监控每批次轨迹的成功率、平均长度方差引入经验回放缓冲区降低数据分布漂移长任务 token 消耗过大每次重规划都带着完整历史统计重规划时发送的 prompt 长度用摘要机制压缩历史或通过向量检索只返回相关步骤9. 最佳实践与工程建议9.1 数据层面长程规划智能体的训练数据优先级从高到低分别是真实用户轨迹、模拟环境轨迹、大模型蒸馏轨迹。真实用户轨迹最宝贵因为它包含了真实环境噪声和用户偏好模拟环境轨迹适合冷启动大模型蒸馏轨迹适合拓宽数据多样性。记录轨迹时不要只记录成功案例。失败案例、重规划案例、长尾任务案例对长程规划能力的提升更重要。一个只在“顺利”路径上训练的模型遇到一次意外几乎必然崩溃。9.2 模型与训练层面教师模型和学生模型的能力差距不建议过大。差距太大时直接蒸馏的收益很低建议先让学生模型在标准任务数据上做一轮监督微调再进入蒸馏阶段。蒸馏温度推荐在 2 到 4 之间做小范围搜索。长程规划任务中更高的温度通常能保留更多教师模型的决策多样性但也可能让学生模型输出过于平滑导致步骤含糊。在线策略蒸馏时建议同时使用经验回放缓冲区。教师模型最新生成的轨迹和过去几个批次的轨迹按一定比例混合避免模型过拟合到最近的任务分布。9.3 工程与安全层面长程规划智能体具备更强的自主性意味着它可能执行更多动作产生更大的影响边界。工程上必须有清晰的安全边界对高影响操作删除数据、发送邮件、修改配置增加人工审批环节。对智能体的每一步工具调用记录完整的日志包括输入参数、执行结果、耗时、调用链路。为智能体设置最大重规划次数和最大 token 预算防止失控循环。在生产环境执行任何变更前先在测试环境验证蒸馏后的模型表现尤其是工具调用格式和错误恢复能力。这些建议不是冗余流程而是长程规划智能体走向生产环境的必要保障。一个能自主执行多步任务的系统如果没有审计和熔断机制一次错误决策就可能造成不可逆的影响。9.4 评估层面强烈建议为长程规划智能体建立“固定评估集 持续回归”机制。固定评估集包含三类任务标准任务中等复杂度的典型业务任务验证核心能力。边界任务包含异常输入、歧义指令、资源限制的特殊任务。长尾任务真实用户遇到但频率较低的任务类型。每次修改规划器、更换模型或更新蒸馏数据后都跑一遍评估集比较成功率、重规划次数、token 成本三个核心指标。这样能快速发现模型能力回退避免线上问题。10. 总结与后续学习方向长程规划智能体是一个系统工程不是单靠某一个模型或某一种算法就能解决。从本文的拆解可以看出它至少涉及预训练模型的选择与适配、任务规划与执行的工程闭环、在线策略蒸馏的训练流程、以及围绕安全与评估的治理机制。如果用一句话总结就是预训练解决“模型有多强”的问题蒸馏解决“模型能不能低成本部署”的问题而规划器、记忆模块和评估体系解决“模型能不能在真实任务中稳定执行”的问题。三者缺一不可。建议你下一步这样实践基于第 5 章的原型把你的真实业务任务接入执行器跑通规划闭环接着收集一百条左右真实轨迹按照第 6 章的蒸馏代码训练一个学生模型最后用第 7 章的评估脚本建立回归指标。这个流程规模不大但能帮你完整理解长程规划智能体从研究到落地的全链路。如果想继续深入以下几个方向值得关注基于强化学习的长程奖励设计、基于世界模型的规划推演、多智能体协同中的任务分配蒸馏、以及更长上下文下的记忆压缩与检索。这些方向最终指向的是同一个问题让智能体不再是“单步问答工具”而是真正能够承担完整任务、对过程和结果负责的数字化执行者。 长程规划智能体落地：预训练与在线策略蒸馏的工程化实践
长程规划能力正成为智能体从“会聊天”走向“会干活”的分水岭。如果你让一个普通对话模型帮你“规划一次跨三地的商务出差”它通常能给出漂亮的大纲但如果你让它真正调度会议、订票、写材料、处理突发变更并连续跟踪三十个步骤问题就会集中爆发早期的目标被遗忘中间步骤之间互相矛盾某一步失败后整个计划不会自动调整。这不是提示词写得不够好而是模型缺少长程规划的核心机制。这篇文章要解决的核心问题是帮助你把“长程规划智能体”这个研究概念落地为一套可理解、可实践的技术方案。我的判断是要让智能体真正具备长程规划能力不能只靠堆提示词而是要靠“预训练打底、蒸馏提效”两条腿走路。预训练负责让模型拥有足够的世界知识、推理常识和工具使用基础蒸馏则负责把大模型的能力迁移到更小、更快、更可控的模型上让规划能力真正进入可部署的智能体系统。读完本文你会得到三样东西第一搞清长程规划智能体的核心难点以及预训练、微调、蒸馏在其中的分工第二理解 OPD 蒸馏在智能体规划领域的技术定位它是如何把教师模型的经验“在线”地转交给学生模型的第三拿到一份可复制的工程化原型代码包括任务规划、轨迹蒸馏、效果评估三个最小模块。1. 这篇文章真正要解决的问题智能体Agent这个概念在最近两年热度极高但不同人说的“智能体”可能完全不是一回事。有人说的是一个能调用工具的聊天助手有人说的是一个能自主完成多步任务的工作流引擎还有人说的是一个完整的多智能体协同系统。本文讨论的是更接近后两种的形态能够接受一个高层目标自主完成任务分解、逐步执行、中途纠偏、最终输出的长程规划智能体。这类智能体最典型的痛点有三个你可以对照自己的项目看是否命中错误累积问题。一步推理错了后面所有步骤都会被带偏而且越到后面越难发现。上下文失控问题。任务越长历史记录越多模型越容易丢失最早期目标或者被中间信息干扰。反馈稀疏问题。计划中的某些步骤要等很久之后才能验证对错模型无法及时调整策略。传统方案依赖人工编写大量决策规则但规则之间容易冲突且维护成本极高。近两年大家转向用预训练语言模型充当“规划大脑”同时用蒸馏、微调等手段把大模型能力压缩到可用的工程形态。可以说预训练和蒸馏不是两个孤立的技术而是长程规划智能体落地链条上最重要的两个环节。这篇文章适合三类读者正在研发智能体产品的工程师想解决复杂任务自动化问题的算法工程师以及对大模型蒸馏感兴趣的研究者。如果你只是想要一个能聊天、能写文案的工具本文的路线对你来说偏重但你仍然可以从中理解大模型应用的架构思路。2. 长程规划智能体的核心概念与难点2.1 什么是长程规划要理解长程规划先要区分“短任务”short-horizon task和“长程任务”long-horizon task。短任务指单步或少量步骤即可完成的任务例如“把这句话翻译成英文”“总结这篇文档”。这类任务对模型的要求主要是语言理解和生成能力。长程任务则指需要多步决策、长时间跨度、中间状态依赖的复杂任务典型例子包括组织一次行业峰会、完成一份企业数字化转型方案、开发一个带前后端的中型 Web 项目。这类任务的特点是一步错、步步错而且中间环节无法完全预判。在智能体研究里长程规划通常包含四个子能力任务分解把高层目标拆成可执行的子任务序列。状态追踪记住当前执行到哪一步、环境发生了什么变化。决策调度根据当前状态选择下一步动作并处理多个子任务之间的依赖关系。失败恢复某一步执行失败时能够回溯并重新规划而不是死循环。这四个子能力缺一不可。大部分“看起来不太聪明”的智能体往往不是模型本身笨而是其中一个或几个子能力没有真正实现。2.2 为什么长程规划如此困难长程规划之所以难核心原因在于它把“语言能力”和“决策能力”同时推到了极限。从语言模型的角度看推理链条越长Attention 越难覆盖早期关键信息。虽然现在的模型都有很长的上下文窗口但术语叫“有效上下文长度”才是关键——模型并不是把所有早期内容都同等重视。让模型记住“用户最初真正想要什么”可能比让它记住最新一条工具返回结果更难。从决策系统的角度看长程规划本质上是序贯决策问题Sequential Decision Making这就需要处理不确定性和稀疏奖励。模型做了十步操作到第十一步才知道前面第三步做错了这种反馈延迟会让常规的学习方法失效。一个经典的类比是把短任务模型比作能答对每一道“单选题”的学生长程规划则要求这个学生“完成一份毕业论文”。单选题和毕业论文对能力的要求完全不同前者看知识储备后者看结构设计、过程管理和自我修正。2.3 长程规划与普通 Agent 的区别普通 Agent 也可以调用工具、读取文档但它通常是被动响应用户的每一条指令。长程规划智能体则更像一个“项目负责人”你给它一个目标它自己排期、自己执行、遇到问题自己调整最后向你汇报结果。这个区别导致了工程实现上的重大差异维度普通 Agent长程规划智能体目标输入单条明确指令高层模糊目标任务粒度单步或几步数十到上百步错误容忍度低可重来高需要自动纠偏记忆要求上下文近景即可需要长期记忆与索引评估方式单次输出质量路径质量与最终结果并重理解了这些差异你再去读预训练和蒸馏相关的论文就能明白为什么研究者要专门设计新的框架来处理这些问题。3. 预训练在智能体规划中的角色3.1 预训练给智能体带来了什么预训练语言模型的本质是通过海量文本学习语言规律、世界知识和推理模式。对智能体来说预训练提供了三样基础资产常识知识。模型知道“订机票需要先确定日期和目的地”这不是规则写出来的而是从文本中学习到的。推理模式。模型在预训练阶段见过大量“因为……所以……”“第一步……第二步……”的文本结构这为它提供了一定的思维链基础。工具使用语料。代码、API 文档、操作说明书等语料让模型理解了“调用函数”“读取文件”“发起请求”这类动作的基本语义。没有预训练智能体的一切高层能力都是空中楼阁。这也是为什么现在主流的 Agent 框架都选择在预训练模型之上构建规划器而不是从头训练一个专用模型——后者的成本极其高昂且效果远不如预训练模型。3.2 面向智能体规划的预训练方式在智能体研究领域预训练并不只是指“语言模型预训练”还包括面向智能体任务的专门预训练阶段。常见的做法有以下几类预训练方式核心思想优势局限纯文本预训练在通用语料上训练基础模型通用性强覆盖面广缺少交互经验行为克隆BC用人类或模型演示数据训练模型模仿直接学习任务轨迹依赖高质量演示数据环境交互预训练让模型在仿真环境中试错学习获得真实反馈信号环境构建成本高世界模型预训练先学习环境动态再基于模型做规划能进行想象的推演世界模型偏差会导致规划失误需要特别说明的是预训练不是“一次性解决所有问题”。更准确的实践路径是先在通用语料上完成基础预训练让模型具备语言和常识能力再在智能体轨迹数据上进行后训练或微调让模型学会“如何做决策”最后再用蒸馏等方式压缩模型适配不同部署场景。3.3 预训练模型不能替代规划机制一个很容易犯的误解是模型能力越强长程规划就不需要额外设计了。实际工程中你会发现即使是最强的通用模型在长程任务中也会出现目标漂移、步骤遗漏等问题。原因在于规划能力不只是“模型在生成文本”而是“系统在控制一个决策过程”。因此成熟的智能体系统通常采用“预训练模型 规划器 记忆模块 工具层”的组合架构。预训练模型负责局部的推理和生成规划器负责整体的任务分解和进度控制记忆模块负责跨步骤的信息保存与检索工具层负责与外部系统的交互。预训练是地基但房子需要其他构件才能立起来。4. 蒸馏原理与 OPD 蒸馏思路4.1 知识蒸馏的核心思想知识蒸馏Knowledge Distillation最早可以理解为“让一个小模型学习大模型的行为”。大模型被称作教师模型Teacher小模型被称作学生模型Student。训练时不仅用真实标签监督学生模型还让学生模型的输出分布去接近教师模型的输出分布。为什么这样有效因为教师模型的输出分布中包含了“软标签”信息。举个例子分类任务中真实标签只说“这是一只猫”但教师模型可能输出“75% 是猫20% 是狗5% 是其他”这个分布里隐含了“猫和狗在外观上更接近”这样的信息。学生模型从这个软分布中能学到的东西比单纯学习硬标签多得多。在自然语言处理领域知识蒸馏有几种常见形式输出蒸馏学生模型模仿教师的输出分布这是最经典的形式。特征蒸馏学生模型模仿教师中间层的特征表示。关系蒸馏学生模型模仿多个样本之间的相对关系。4.2 从知识蒸馏到策略蒸馏知识蒸馏主要面向监督学习任务而智能体的规划任务更接近强化学习中的策略学习。于是“轨迹级蒸馏”成为关键思路教师模型在环境中执行任务生成一条完整的决策轨迹状态、动作、奖励序列学生模型学习在这条轨迹上模仿教师的动作选择。这就是策略蒸馏的基本形态。策略蒸馏的优点是学生模型学到的不只是“单步答案”而是“在何种状态下采取何种动作”的完整决策策略。对长程规划来说策略蒸馏比单纯蒸馏文本输出要有效得多因为规划的本质是决策而不是生成。4.3 OPD 蒸馏在线策略蒸馏在智能体和长程规划相关的研究讨论中OPD 这个缩写通常被理解为 Online Policy Distillation即在线策略蒸馏。有一点要提前说明不同论文对 OPD 的展开可能不同Online Planning Distillation、Offline Policy Distillation 等也是常见候选但本文从工程直觉出发把 OPD 理解为“在线策略蒸馏”来展开这是当前智能体蒸馏体系里最贴合项目落地场景的解释。在线策略蒸馏与离线策略蒸馏的核心区别在于教师经验从哪里来。离线蒸馏用静态数据教师模型生成一批轨迹后保存下来然后反复训练学生模型。在线蒸馏则让教师模型在与环境交互的过程中持续生成新轨迹学生模型跟着实时学习。这个过程可以理解成教师一边做项目一边带新人而不是把过去的项目报告扔给新人自学。对长程规划智能体来说在线策略蒸馏有三个明显优势第一数据分布与当前任务保持对齐。环境会变任务类型会变离线数据容易过期在线生成的数据则始终反映最新情况。第二学生模型可以边学边用。当学生模型在真实任务中出现偏差时在线系统可以及时发现并让教师模型重新示范。第三更接近真实部署的反馈闭环。长程任务中间步骤的成败信号本来就需要在线收集离线数据往往缺少这种细节。当然在线策略蒸馏也有代价训练过程更复杂需要管理教师模型的推理成本、学生模型的采样、以及两者之间的同步节奏。工程上一般不会每一轮都蒸馏而是采用“教师批处理 学生异步更新”的模式。4.4 OPD 在长程规划中的典型工作流一个完整的 OPD 长程规划智能体训练循环大致如下给定一个目标任务教师模型先生成初始规划。教师模型逐步执行规划在每步记录状态、动作、中间结果、最终反馈。学生模型同步观察教师轨迹并尝试预测“教师下一步会做什么”。用蒸馏损失更新学生模型参数使学生模型的学生输出分布接近教师模型。定期将学生模型部署到低成本推理环境替代教师模型执行部分简单任务。当环境或任务分布发生变化时重新启动教师模型生成新轨迹继续蒸馏。这个循环看起来简单但工程实现中有很多细节值得注意例如教师模型和学生模型的能力差距、蒸馏温度的选择、在线数据的采样优先级等。这些内容我会在第 8 章和第 9 章展开。5. 从论文到工程搭建一个长程规划智能体原型概念终归要落在代码上。这一章我们用最少的依赖搭建一个可运行的长程规划智能体原型。原型的目标是演示“规划—执行—反馈—重规划”的主循环并为后续蒸馏提供轨迹数据。5.1 环境准备与依赖建议使用 Python 3.10 及以上版本主要依赖如下openai调用大模型 API没有 API 时可以替换为本地模型接口tenacity重试机制处理网络抖动pyyaml读取配置文件torch、transformers训练蒸馏模型时使用# 文件路径requirements.txt openai1.0.0 tenacity8.2.0 pyyaml6.0 torch2.0.0 transformers4.30.0安装命令pip install -r requirements.txt注意具体版本请以实际项目为准本文演示的是通用思路。如果你没有 OpenAI 的 API 密钥可以将配置项model_name指向任何兼容 OpenAI 协议的本地推理服务原理完全一致。5.2 项目目录结构建议按下面的目录组织代码agent_core/ ├── config.py ├── planner.py ├── executor.py ├── memory.py ├── plan_and_execute.py training/ ├── distill_trajectory.py evaluation/ ├── eval_agent.py requirements.txt其中planner.py负责任务分解executor.py负责调用工具或模拟动作memory.py负责记录历史步骤plan_and_execute.py是主循环。5.3 规划器实现规划器的核心是让大模型把高层目标拆解为可执行的步骤并要求输出严格的 JSON。这么做的好处是后续执行器可以直接解析不需要依赖额外的文本解析模块。# 文件路径agent_core/planner.py import json from typing import List from tenacity import retry, stop_after_attempt, wait_exponential SYSTEM_PROMPT 你是一个长程规划智能体负责将复杂目标拆解为可执行步骤。 要求 1. 输出严格的JSON数组不要包含任何额外说明。 2. 每个元素包含 step_id、description、depends_on 三个字段。 3. step_id 为从 1 开始的整数depends_on 为当前步骤依赖的 step_id 列表。 4. 每个步骤必须能够在单次工具调用中完成。 5. 如果目标过于复杂优先拆解为 5-10 个步骤不要贪多。 retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min2, max10)) def generate_plan(client, model_name: str, task_description: str) - List[dict]: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f请为以下目标生成规划{task_description}}, ] response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content data json.loads(content) if isinstance(data, dict) and steps in data: return data[steps] if isinstance(data, list): return data raise ValueError(f无法解析规划结果{content})代码中的关键点有两个一是强制的 JSON 输出格式二是depends_on字段它定义了任务之间的依赖关系。后续执行器会用它来判断哪些前置步骤必须提前完成。5.4 执行器与记忆模块执行器负责模拟每一步动作。真实项目中它可能是调用数据库、发送 HTTP 请求、操作文件在原型里我们可以用一个简单的模拟函数代替重点是验证规划闭环是否跑通。# 文件路径agent_core/executor.py import random def execute_step(step: dict, context: dict) - dict: 模拟执行一个步骤。 真实项目中这里应该调用具体工具 - 查询数据库 - 调用第三方 API - 操作文件系统 - 发送消息通知 原型中使用随机数模拟成功与失败方便验证重规划逻辑。 step_id step[step_id] description step[description] # 模拟执行结果80% 成功率 success random.random() 0.8 result { step_id: step_id, description: description, success: success, output: f步骤 {step_id} 执行完成 if success else f步骤 {step_id} 执行失败, } context[history].append(result) context[executed_steps].add(step_id) return result记忆模块负责维护两条信息所有已执行步骤的历史记录和当前已完成的步骤集合。这些信息会在重规划时传给规划器让模型了解“现在已经做到哪里了、哪里出了问题”。# 文件路径agent_core/memory.py class AgentMemory: def __init__(self): self.history [] self.executed_steps set() def add_step_result(self, result: dict): self.history.append(result) self.executed_steps.add(result[step_id]) def get_context(self) - dict: return { history: self.history, executed_steps: sorted(self.executed_steps), }5.5 主循环规划—执行—重规划主循环把上面几个模块串起来。整体逻辑是先规划再按依赖顺序执行如果某一步失败则带着失败信息重新规划最多重试若干次。# 文件路径agent_core/plan_and_execute.py import json import openai from planner import generate_plan from executor import execute_step from memory import AgentMemory def plan_and_execute(task_description: str, max_replan_times: int 3, model_name: str gpt-4o-mini): client openai.OpenAI() memory AgentMemory() plan generate_plan(client, model_name, task_description) replan_count 0 while replan_count max_replan_times: all_done True for step in plan: if step[step_id] in memory.executed_steps: continue deps step.get(depends_on, []) if any(dep not in memory.executed_steps for dep in deps): continue result execute_step(step, contextmemory.get_context()) if not result[success]: print(f[ERROR] 步骤 {step[step_id]} 执行失败触发重规划) replan_count 1 new_plan generate_plan( client, model_name, json.dumps({ task: task_description, executed_steps: memory.get_context(), failed_step: result, }, ensure_asciiFalse), ) plan new_plan all_done False break if all_done: break return { plan: plan, history: memory.history, replan_count: replan_count, }运行入口# 文件路径main.py from agent_core.plan_and_execute import plan_and_execute if __name__ __main__: task 撰写一份智能体技术在制造业落地的调研报告包括背景、方案、案例和风险分析。 result plan_and_execute(task) print(json.dumps(result, ensure_asciiFalse, indent2))这个原型已经把长程规划智能体的核心骨架搭出来了后续可以在此基础上扩展真实工具调用、向量记忆、异步执行等能力。6. 蒸馏流程的核心示例代码规划主循环跑通之后下一步是训练一个更小、更快的学生模型让它学习教师模型的规划能力。这里演示一条最核心的蒸馏训练路径。6.1 生成教师轨迹在真实项目中教师模型的轨迹来自第 5 章中plan_and_execute的完整执行记录。每条轨迹包含用户的初始目标、模型的每一步规划、每一步执行结果以及最终输出。为了保证蒸馏质量建议保存为统一的 JSON 格式{ task: 撰写一份智能体技术在制造业落地的调研报告, trajectory: [ { state: 初始状态, action: 分解为8个子任务, result: 成功 }, { state: 已完成子任务1-3, action: 执行子任务4收集制造业案例, result: 成功 } ], final_output: 报告正文... }6.2 学生模型蒸馏训练这里使用经典的 KL 散度损失让学生模型输出的 token 分布去对齐教师模型。需要注意实际训练时学生模型和教师模型需要使用同一个 Tokenizer否则 logits 无法对齐。# 文件路径training/distill_trajectory.py import torch import torch.nn.functional as F from transformers import AutoTokenizer, AutoModelForCausalLM from torch.utils.data import DataLoader, Dataset class TrajectoryDataset(Dataset): def __init__(self, trajectories, tokenizer, max_length1024): self.trajectories trajectories self.tokenizer tokenizer self.max_length max_length def __len__(self): return len(self.trajectories) def __getitem__(self, idx): traj self.trajectories[idx] # 将 trajectory 序列化成一段文本 text f任务{traj[task]}\n轨迹{traj[trajectory][:10]}\n结果{traj[final_output]} inputs self.tokenizer(text, truncationTrue, max_lengthself.max_length, return_tensorspt) return {k: v.squeeze(0) for k, v in inputs.items()} def distillation_loss(student_logits, teacher_logits, temperature2.0): 使用 KL 散度计算蒸馏损失。 核心思想不是让学生模型简单模仿教师的 argmax 输出 而是让整个输出分布接近教师保留教师对“次优选择”的偏好信息。 student_logits student_logits / temperature teacher_logits teacher_logits / temperature loss F.kl_div( F.log_softmax(student_logits, dim-1), F.softmax(teacher_logits, dim-1), reductionbatchmean, ) return loss * (temperature ** 2) def train_step(teacher_model, student_model, batch, optimizer, temperature2.0): teacher_model.eval() student_model.train() input_ids batch[input_ids] attention_mask batch[attention_mask] with torch.no_grad(): teacher_outputs teacher_model(input_ids, attention_maskattention_mask) teacher_logits teacher_outputs.logits student_outputs student_model(input_ids, attention_maskattention_mask) student_logits student_outputs.logits loss distillation_loss(student_logits, teacher_logits, temperature) optimizer.zero_grad() loss.backward() optimizer.step() return loss.item()训练主循环代码可以这样写# 文件路径training/train_distill.py import json import torch from transformers import AutoTokenizer, AutoModelForCausalLM from distill_trajectory import TrajectoryDataset, train_step def main(): # 加载教师模型和学生模型实际项目中请替换成你使用的模型 teacher_tokenizer AutoTokenizer.from_pretrained(your_teacher_model) teacher_model AutoModelForCausalLM.from_pretrained(your_teacher_model) student_tokenizer AutoTokenizer.from_pretrained(your_student_model) student_model AutoModelForCausalLM.from_pretrained(your_student_model) # 加载轨迹数据 with open(trajectories.json, r, encodingutf-8) as f: trajectories json.load(f) dataset TrajectoryDataset(trajectories, student_tokenizer) dataloader DataLoader(dataset, batch_size2, shuffleTrue) optimizer torch.optim.Adam(student_model.parameters(), lr5e-5) model_save_path student_model_finetuned for epoch in range(3): total_loss 0 for batch in dataloader: loss train_step(teacher_model, student_model, batch, optimizer) total_loss loss avg_loss total_loss / len(dataloader) print(fEpoch {epoch 1}, Average Loss: {avg_loss:.4f}) if (epoch 1) % 1 0: student_model.save_pretrained(f{model_save_path}_epoch_{epoch 1}) student_tokenizer.save_pretrained(f{model_save_path}_epoch_{epoch 1}) if __name__ __main__: main()这里需要你记住一个关键点蒸馏不是替代任务微调而是在微调基础之上进一步提升学生模型与教师模型的输出一致性。如果你的任务希望学生模型具备额外的对齐能力、工具调用格式等还是需要结合传统的监督微调数据一起训练。6.3 蒸馏效果评估脚本蒸馏之后不能只盯着 loss 数字下降更关键的是看模型在长程规划任务中的实际完成质量。评估脚本建议从四个维度展开# 文件路径evaluation/eval_agent.py import json def evaluate_trajectory(plan, executed_actions, final_result): 评估一次长程规划任务的执行质量。 参数 - plan: 模型规划出的步骤列表 - executed_actions: 实际执行的步骤列表 - final_result: 最终结果包含 success、replan_count、token_cost 等字段 返回指标字典 - plan_completeness: 计划完整度指计划步骤被实际执行的比例 - task_success: 任务是否最终成功 - replan_count: 重规划次数反映模型的纠偏能力 - token_cost: 总 token 消耗反映部署成本 metrics {} exec_ids {action.get(step_id) for action in executed_actions} plan_ids {step.get(step_id) for step in plan} metrics[plan_completeness] len(exec_ids plan_ids) / max(len(plan_ids), 1) metrics[task_success] 1 if final_result.get(success) else 0 metrics[replan_count] final_result.get(replan_count, 0) metrics[token_cost] final_result.get(token_cost, 0) metrics[success_rate] final_result.get(success_rate, 0.0) return metrics if __name__ __main__: sample_plan [{step_id: 1}, {step_id: 2}, {step_id: 3}] sample_actions [{step_id: 1}, {step_id: 2}, {step_id: 3}] sample_result { success: True, replan_count: 1, token_cost: 12000, success_rate: 0.92, } print(json.dumps(evaluate_trajectory(sample_plan, sample_actions, sample_result), ensure_asciiFalse, indent2))评估脚本的使用方式分两种离线评估时把历史轨迹灌入模型让它复现每一步决策与传统基线对比在线评估时直接接入当前任务流统计成功率、重规划率、token 成本。7. 运行结果与效果验证7.1 如何判断原型跑通拿到第 5 章的规划原型后第一次运行可能会得到类似下面的输出示例{ plan: [ {step_id: 1, description: 分析用户目标确定调研范围, depends_on: []}, {step_id: 2, description: 收集智能体在制造业的案例, depends_on: [1]}, {step_id: 3, description: 分析实施方案与风险, depends_on: [2]}, {step_id: 4, description: 撰写报告大纲, depends_on: [3]} ], history: [ {step_id: 1, success: true}, {step_id: 2, success: true}, {step_id: 3, success: false} ], replan_count: 1 }判断原型是否跑通有以下标志模型输出了合法 JSON 规划且步骤之间存在依赖关系。执行器按照依赖顺序逐步执行没有被某个长步骤卡死。某一步失败后模型收到了失败信息并触发了重规划。最终任务在指定重试次数内完成或者返回了明确的失败原因。如果程序直接崩溃优先检查 JSON 解析是否失败以及execute_step的返回格式是否被主循环正确读取。7.2 蒸馏训练的验证方式蒸馏训练结束后你最容易犯的错误是只看 loss 下降就认为成功。长程规划场景中更可靠的验证指标是“替代指标对比”在固定测试集上分别用教师模型、蒸馏前学生模型、蒸馏后学生模型生成规划。用第 6.3 节的评估脚本计算三种模型的任务成功率、平均规划步数、重规划次数。对比蒸馏前后学生模型在相同测试集上的表现差距。一个合理的验收标准是蒸馏后的学生模型任务成功率下降不要超过教师模型的 10% 到 15%但推理耗时和部署成本可以有明显下降。具体阈值因项目而异不设定统一数字。7.3 失败时的第一步排查如果蒸馏后学生模型的表现不升反降不要急着调模型按下面顺序排查检查训练数据是否包含足够多的“失败轨迹”。如果教师模型只生成成功轨迹学生模型就学不到失败恢复能力这是长程规划蒸馏中最常见的数据偏置问题。检查教师模型与学生模型的能力差。如果差距过大蒸馏损失会一直很大学生模型难以拟合可以考虑使用辅助输出损失。检查温度系数。温度太低软标签信息不足温度太高训练不稳定。常见范围是 2 到 4但需要实验来确定。8. 常见问题与排查思路问题现象可能原因排查方式解决方案规划结果无法解析成 JSON模型返回了额外文字或 Markdown 格式查看模型原始输出内容和错误堆栈使用response_format强制 JSON增加解析后校验规划步骤执行到一半就丢失目标上下文过长导致早期目标被覆盖检查主循环中传递给模型的 context 是否包含完整目标引入“目标固定区”重规划时始终保留原始目标字段重规划后执行了重复步骤执行器没有记录已完成步骤集合检查 memory 中的 executed_steps 是否持久化在重规划前将已完成的步骤 id 显式传给规划器蒸馏后的学生模型动作格式全错学生模型没有见过工具调用的格式规则查看学生模型生成样本与教师模型样本的差异在蒸馏数据中加入少量带格式注释的任务微调数据在线策略蒸馏训练不稳定教师模型在线生成的轨迹分布波动大监控每批次轨迹的成功率、平均长度方差引入经验回放缓冲区降低数据分布漂移长任务 token 消耗过大每次重规划都带着完整历史统计重规划时发送的 prompt 长度用摘要机制压缩历史或通过向量检索只返回相关步骤9. 最佳实践与工程建议9.1 数据层面长程规划智能体的训练数据优先级从高到低分别是真实用户轨迹、模拟环境轨迹、大模型蒸馏轨迹。真实用户轨迹最宝贵因为它包含了真实环境噪声和用户偏好模拟环境轨迹适合冷启动大模型蒸馏轨迹适合拓宽数据多样性。记录轨迹时不要只记录成功案例。失败案例、重规划案例、长尾任务案例对长程规划能力的提升更重要。一个只在“顺利”路径上训练的模型遇到一次意外几乎必然崩溃。9.2 模型与训练层面教师模型和学生模型的能力差距不建议过大。差距太大时直接蒸馏的收益很低建议先让学生模型在标准任务数据上做一轮监督微调再进入蒸馏阶段。蒸馏温度推荐在 2 到 4 之间做小范围搜索。长程规划任务中更高的温度通常能保留更多教师模型的决策多样性但也可能让学生模型输出过于平滑导致步骤含糊。在线策略蒸馏时建议同时使用经验回放缓冲区。教师模型最新生成的轨迹和过去几个批次的轨迹按一定比例混合避免模型过拟合到最近的任务分布。9.3 工程与安全层面长程规划智能体具备更强的自主性意味着它可能执行更多动作产生更大的影响边界。工程上必须有清晰的安全边界对高影响操作删除数据、发送邮件、修改配置增加人工审批环节。对智能体的每一步工具调用记录完整的日志包括输入参数、执行结果、耗时、调用链路。为智能体设置最大重规划次数和最大 token 预算防止失控循环。在生产环境执行任何变更前先在测试环境验证蒸馏后的模型表现尤其是工具调用格式和错误恢复能力。这些建议不是冗余流程而是长程规划智能体走向生产环境的必要保障。一个能自主执行多步任务的系统如果没有审计和熔断机制一次错误决策就可能造成不可逆的影响。9.4 评估层面强烈建议为长程规划智能体建立“固定评估集 持续回归”机制。固定评估集包含三类任务标准任务中等复杂度的典型业务任务验证核心能力。边界任务包含异常输入、歧义指令、资源限制的特殊任务。长尾任务真实用户遇到但频率较低的任务类型。每次修改规划器、更换模型或更新蒸馏数据后都跑一遍评估集比较成功率、重规划次数、token 成本三个核心指标。这样能快速发现模型能力回退避免线上问题。10. 总结与后续学习方向长程规划智能体是一个系统工程不是单靠某一个模型或某一种算法就能解决。从本文的拆解可以看出它至少涉及预训练模型的选择与适配、任务规划与执行的工程闭环、在线策略蒸馏的训练流程、以及围绕安全与评估的治理机制。如果用一句话总结就是预训练解决“模型有多强”的问题蒸馏解决“模型能不能低成本部署”的问题而规划器、记忆模块和评估体系解决“模型能不能在真实任务中稳定执行”的问题。三者缺一不可。建议你下一步这样实践基于第 5 章的原型把你的真实业务任务接入执行器跑通规划闭环接着收集一百条左右真实轨迹按照第 6 章的蒸馏代码训练一个学生模型最后用第 7 章的评估脚本建立回归指标。这个流程规模不大但能帮你完整理解长程规划智能体从研究到落地的全链路。如果想继续深入以下几个方向值得关注基于强化学习的长程奖励设计、基于世界模型的规划推演、多智能体协同中的任务分配蒸馏、以及更长上下文下的记忆压缩与检索。这些方向最终指向的是同一个问题让智能体不再是“单步问答工具”而是真正能够承担完整任务、对过程和结果负责的数字化执行者。