1. Agent核心目标解析
在大模型应用中，我们经常会遇到模型内部知识不足以回答用户问题的情况。这时候就需要引入外部知识来增强模型能力，这就是典型的RAG（Retrieval-Augmented Generation）架构。但传统RAG存在一个关键问题：它获取外部知识时只考虑了问题本身，而没有考虑这些知识是否真的能帮助模型生成更好的答案。
1.1 传统RAG的局限性
传统RAG的工作流程可以表示为：
code复制R ← f(q)
o ～ π(?|q, R)
其中f代表检索工具（如向量数据库），π是大语言模型。这种模式下，检索过程完全独立于模型，可能导致检索到的内容R与模型的推理能力不匹配。
我在实际项目中发现，这种"检索-生成"的割裂设计会导致几个典型问题：
- 检索结果可能包含模型无法正确理解的专业术语
- 检索片段可能缺少模型生成完整答案所需的关键上下文
- 当需要多步检索时，各步检索之间缺乏协调
1.2 Agent的三大核心能力
基于这些观察，我们需要让Agent具备三种递进式的能力：
1. 初始规划能力
code复制tool_type, tool_args ～ π(?|q)
模型需要仅凭问题q就能规划出第一步的工具调用方案。这要求模型理解不同工具的特性和适用场景。
2. 单步决策能力
code复制o|tool_type, tool_args ～ π(?|q, R)
在获得外部知识R后，模型需要判断是继续调用工具还是直接生成最终答案。这个决策需要平衡工具调用成本和预期收益。
3. 轨迹协调能力
code复制o ～ π(?|q, R1, R2,...)
当问题需要多工具协作时，模型需要管理整个调用轨迹，确保各步骤间的信息流合理。例如在电商场景中，可能需要先查询商品库存，再检查用户会员等级，最后计算实际价格。
2. 训练数据构建方案
构建高质量的Agent训练数据需要针对上述三种能力分别设计。根据我的项目经验，数据构建是Agent开发中最耗时但也最关键的环节。
2.1 规划能力数据
这类数据用于训练模型的工具选择能力。每个样本应包含：
- 问题q
- 理想的首选工具类型tool_type
- 该工具所需的参数tool_args
注意：工具参数应该尽可能接近真实API调用格式。我们团队曾因为使用简化参数格式，导致模型在实际部署时出现参数转换错误。
建议收集方式：
- 人工标注真实用户问题的工具调用方案
- 通过反向生成：给定工具文档，人工设计适合该工具的问题
- 从现有工具日志中提取成功调用案例
2.2 单步决策数据
这类数据教会模型如何利用已有信息(R)做出下一步决策。每个样本应包含：
- 问题q
- 当前已获取的外部知识集合
- 下一步动作（继续调用工具或生成答案）
- 如果是调用工具，指定工具类型和参数
- 如果是生成答案，提供标准回复
我们在构建这类数据时发现一个常见陷阱：样本中的决策过于理想化。实际上，模型在推理时获得的信息R可能不完整或有噪声。因此建议：
- 对R人工添加适度噪声（如随机删除部分内容）
- 包含部分"继续探索"的样本，即使当前R看似足够
2.3 轨迹协调数据
完整的任务轨迹数据是最难获取的，但也是提升Agent协调能力的关键。每个样本应包含：
- 问题q
- 工具调用序列[tool_call1, tool_call2,...]
- 各步骤获得的响应[R1, R2,...]
- 最终答案o
这类数据的构建技巧：
- 优先选择有明确标准流程的领域（如客服、电商）
- 使用"反向链"构建法：先确定最终答案，再倒推需要哪些中间信息
- 对长轨迹进行分段标注，降低标注难度
3. 模型训练策略
有了合适的数据后，我们需要设计对应的训练策略。根据三种能力的不同特点，应该采用差异化的训练方法。
3.1 监督微调(SFT)阶段
规划能力和单步决策能力适合用SFT训练：
- 使用交叉熵损失函数
- 对工具调用和文本生成采用不同的attention mask
- 建议学习率设为普通文本生成的1/3到1/2
我们在训练中发现几个关键点：
- 工具调用token需要特殊处理 - 建议在vocabulary中添加专门的工具调用token
- 训练时要随机屏蔽部分历史工具调用结果，增强模型鲁棒性
- 对工具参数生成采用更严格的长度惩罚
3.2 强化学习(RL)阶段
轨迹协调能力最适合用RL训练：
- 奖励函数设计是关键，应该包含：
- 任务完成度（最终答案质量）
- 工具调用效率（最少必要调用）
- 中间步骤的正确性
- 建议使用PPO算法
- 初始训练时约束KL散度，防止策略偏离太大
重要经验：RL训练前，模型应该已经具备基本的工具调用能力。我们曾尝试从零开始RL训练，结果模型完全无法收敛。
3.3 课程学习安排
建议的训练顺序：
- 先训练规划能力（约占总训练时间的30%）
- 然后加入单步决策训练（40%）
- 最后进行轨迹协调的RL训练（30%）
在每个阶段，都可以使用以下技巧提升效果：
- 对困难样本进行过采样
- 逐步增加任务复杂度
- 定期在held-out测试集上评估各能力指标
4. 实际部署中的挑战与解决方案
将训练好的Agent部署到生产环境时，会遇到许多在开发阶段未曾预料的问题。以下是我们在多个项目中总结的经验。
4.1 工具API的稳定性处理
实际工具API可能不如训练时假设的那样可靠。必须为模型设计容错机制：
- 设置API调用超时（建议2-3秒）
- 对失败调用自动重试（最多2次）
- 提供API错误信息给模型，让它有机会调整策略
我们实现了一个"API状态感知"的Wrapper，可以自动将API状态编码为特殊token插入到模型输入中。
4.2 长轨迹任务的衰减问题
当工具调用链较长时，模型容易"遗忘"早期信息。解决方案包括：
- 关键信息摘要：自动提取各步骤的关键信息，在后续步骤中重复插入
- 轨迹压缩：将多个步骤的结果合并为简洁的表述
- 外部记忆：使用向量数据库存储整个轨迹的摘要
4.3 评估指标设计
传统的语言模型评估指标（如BLEU）不适合Agent评估。我们采用的指标包括：
- 任务完成率
- 平均工具调用次数
- 工具调用准确率
- 最终答案质量（人工评估）
建议构建一个专门的评估数据集，包含各种边界情况（如模糊请求、多跳问题等）。
5. 典型应用场景实现
让我们通过一个电商客服Agent的具体案例，看看如何将上述理论应用到实践中。
5.1 场景定义
用户问题："我上个月买的手机现在降价了，能退差价吗？"
这需要Agent：
- 验证用户身份和购买记录
- 查询当前商品价格
- 检查平台的差价退还政策
- 综合这些信息生成回复
5.2 工具设计
我们为该场景设计了三个工具：
- 用户服务API：验证用户+查询历史订单
- 商品API：获取当前价格信息
- 政策数据库：查询相关条款
每个工具都配有详细的参数说明和使用示例，这些说明也会作为模型训练数据的一部分。
5.3 预期轨迹
理想的工具调用序列应该是：
- 调用用户服务API验证用户并查询手机订单
- 调用商品API查询当前价格
- 调用政策数据库查询差价退还规则
- 综合所有信息生成回复
我们在训练数据中特意包含了一些非理想轨迹，比如：
- 先查政策再验证用户（可能泄露政策信息）
- 不验证用户直接查询（安全问题）
- 重复查询相同信息
这些负面样本帮助模型学习到更合理的决策流程。
5.4 实际部署表现
经过上述训练方案后，Agent在该场景的表现：
- 任务完成率：92%
- 平均工具调用次数：2.8次
- 平均响应时间：3.2秒
- 人工评估满意度：4.5/5
关键成功因素：
- 工具API设计考虑了模型的使用习惯
- 训练数据覆盖了各种边界情况
- 对政策查询结果做了标准化处理，便于模型理解
这个案例表明，当数据构建和训练策略都针对Agent的三大能力进行优化时，可以获得相当不错的效果。