AGI——阿里通义-丁瑞雪-AgenticAICon2026演讲

整体说明

  • 核心观点总结：Harness（工程化手段）只能打补丁、补不出上限，垂域自进化 Agent 模型才是突破企业级 Agent 落地瓶颈的更有效路径
  • 通义团队经过一年半的实践，打磨出一套让模型自主出题、自主学习和自主评估 的自进化框架
    • 这些垂域 Agent 在业务中积累的数据和经验还能回流到基础模型训练中 ，形成 “业务落地—能力沉淀—基模增强” 的正向循环
    • 注：业务数据与基础模型之间的双向反馈机制非常重要 ，只有让真实场景经验不断回流基模，才能持续提升基模本身的能力

Agent 从 Demo 到生产，核心问题在变

  • 越来越多 Agent 开始接入真实业务系统，并尝试完成复杂任务
    • 代码开发
    • 办公协同
    • 电商服务
    • 企业运营
  • 当前 Agent 的基础框架已相对成熟，“让模型主动调用工具”这件事基本已经完全解决，真正困难的地方在于：
    • 如何让模型理解业务逻辑，并正确完成长链路、多步骤的复杂任务
  • 仅依赖 Prompt Engineering（PE） 驱动通用大模型（即使是 Claude Code 这样的顶级模型），往往需要额外构建大量 Harness 和业务规则，才能勉强达到上线标准
  • 在实践中，团队总结了三大核心问题：
    • 1）成本不可控 ：垂域任务未必需要大规模通用模型支撑，直接使用通用大模型面临推理成本高、响应时间长的问题
    • 2）效果天花板 ：即便投入大量工程资源优化 Prompt 和 Harness，效果往往只能达到测试目标的 70% 左右，很难进一步突破
      • 现实中采取的是“退化法则”：如果 Agent 效果不达标，就逐步拆解成 Workflow，甚至退化为传统对话系统
    • 3）工具理解浅 ：
      • Coding Agent 效果好是因为命令行、Python 等工具在训练数据中大量存在
      • 面对企业内部自定义工具和私域业务逻辑，模型几乎没有先验知识，会产生无效调用、参数幻觉或随意组合工具等问题
      • 理解：说白了还是自定义的非常复杂的工具需要被见过，否则模型泛化能力不够，容易出现参数幻觉等
        • 现在的模型能力下，简单的工具没问题的
  • 补充论证：即使在真实 API 调用的 Agent Benchmark 上，当时业内头部模型最高分也仅 60-76 分左右，远达不到上线标准

Harness 补不出上限，垂域 Agent 模型更有效

  • 无论是调整 Prompt、自动化提示词优化，还是在 Harness 层叠加业务规则，优化到一定阶段后都会很快触及模型本身的能力天花板
  • 通义团队比较有效的解决方案是：在垂域专门训练一个 Agent 模型，再把能力输送回原系统
    • 以出行场景为例，单纯依靠基础模型时，Skill 选择、任务规划等关键指标效果甚至达不到 70%
    • 电商场景同样如此同样如此
  • 业务同学也主动找到技术团队，希望通过模型训练把规则体系内化到模型中，而不是继续依赖不断叠加规则
    • 原因：规则系统已经变得难以维护，他们不希望继续依赖不断叠加规则的方式解决问题
  • 具体做法：
    • 业务的节奏决定了得先有这么一个模型，先把这些经验和数据攒出来

如何训练垂域自进化 Agent 模型

第一步：SFT 冷启动

  • 围绕业务场景构造大量 Query，用强模型生成 Trajectory，再通过 Reject Sampling 筛选数据训练
    • 不同场景的数据构造方法不同，但基本思路一致
    • 通常一周左右能训练出可用基线模型
  • SFT 更适合作为快速应急手段
    • 比如解决模型指令遵循能力不足、推理速度不够等问题，帮助业务快速上线
      • 理解：这里说的推理速度不够可能是通过内化 Prompt 减少输入或者是缩短输出实现快速返回
  • SFT 问题：
    • SFT 容易把模型能力分布训偏，带来幻觉、逻辑不一致、格式稳定性和用户体验等问题

第二步：Agentic RL 让模型自进化

  • 如果想进一步做好模型，基本都离不开强化学习
  • 但 Agentic RL 的落地一般比较复杂
    • 并非搭个 GRPO 框架，准备一批 Query 就能自动学好
    • 往往需要投入大量精力设计课程学习数据、训练任务和奖励函数
  • 现实情况：通义团队需要同时支持集团内大量业务，不可能为每个场景都投入大量人力

Agentic RL 自进化框架的三大关键机制

  • 通义团队围绕 GRPO 的三个核心环节（Query、Rollout、Reward）的每个环节都设计了自进化框架

机制一：自动课程学习

  • 课程学习在 RL 中是有效的
  • 传统做法成本高：
    • 需要人工设计不同阶段的训练任务
  • 自进化课程学习：
    • 让 Agent 自主进入环境探索，基于探索信息自动生成训练题目，并将题目控制在模型能力边界附近（既不是已完全掌握的，也不是完全不会的，而是“快学会但还没学会”的部分）能持续提升学习效率
  • 具体设计：
    • 一个出题者和一个做题者
      • 做题者是要持续优化的模型
      • 出题者负责根据做题者当前能力水平生成最合适的训练任务
    • 具体做法：
      • 出题者根据做题者当前状态生成 Query 训练做题者
      • 做题者能力提升后出题者再调整难度
      • 两者不断迭代进化，实现持续进化过程
    • 理解：从演讲公开的图片看到连续三轮迭代，效果是持续上升的

机制二：在线经验注入

  • 问题：Agent 任务通常链路很长、搜索空间巨大，如果完全依赖随机探索，获得高质量轨迹的概率非常低
    • 缺乏有效样本的情况下，RL 学习效率很低
    • 垂直场景中模型往往呈现“要么完全不会、要么已经很好”的两极化特征，有效轨迹稀缺
  • 在线经验注入：
    • 基本思路：通过对关键步骤进行轻量引导来提高有效 Rollout 的比例
    • 用同一个模型正常 Rollout，生成大量轨迹并进行 Reward 评估
      • 如果有正确答案就给正确答案，没有正确答案就给一些 reward 反馈，再利用这些反馈引导模型反思和修正关键步骤，从而获得更优轨迹
  • 这里能够成功的核心关键是：“分布保护”
    • 引导必须克制，确保修改后的轨迹不偏离当前分布太远，在提升探索效率的同时保持训练稳定性
      • 理解：这里推测训练时轨迹中是会删除 Reward 的，目标是想让模型未来在看不到 Reward 反馈的情况下，就能正确处理
      • 理解：这里的做法会导致两个问题：
        • 问题一：这里会导致基于 Group 的 Advantage 计算出现问题（多个不同状态的动作不可比）
        • 问题二：这里如果训练时使用原始 Prompt（不包含奖励信号），则会导致训推不一致问题
          • 训练时和推理（采样轨迹）看到的状态不同，从而带来 Off-policy 问题
      • 理解：这里的 Reward 信号还可以理解为相当于是人类使用过程中加入给模型的提示信号，索性就训练进去
    • 更多理解：

机制三：Pairwise Reward（而不是 Pointwise 奖励）

  • 实际业务场景中，基本已经用 Pairwise Reward 比较替代了传统的 Pointwise Reward
    • Pointwise Reward 在训练后期会遇到明显的信号衰减问题
      • 模型输出逐渐趋同之后，大量结果都会集中在相近分数区间，此时评分噪声甚至会超过样本之间真实的质量差异，导致优化方向被噪声主导
    • 理解：大多数真实业务场景不存在标准答案（如旅行规划、内容推荐）
      • Pointwise 绝对打分稳定性差，而让评估者判断 “A 和 B 哪个更好” 的 Pairwise 比较一致性明显更高
      • 在实践中，无论人工还是模型评审，“A 比 B 更好” 的判断远比 “给 A 打 8.2 分” 更加鲁棒一致
  • 通义团队将奖励建模转化为相对排序问题，并借鉴竞赛排名思路（循环赛、瑞士轮、种子淘汰赛等）在计算开销和排序精度间寻找平衡
    • 注：如果对 N 条轨迹两两比较，复杂度会达到 \(O(N^2)\)，训练成本太大了，必须借鉴排名思路缩小复杂度

垂域场景验证

  • 该垂域模型已应用于高德、淘宝、云安全 等多个业务场景
    • 覆盖了对话式 Agent（调工具、回答问题）和云安全场景（Agent 放入沙箱环境自行写测试脚本、检查漏洞和入侵）两种类型
  • 基于小模型训练专属模型 + 私有化部署：在效果提升和成本降低两方面都表现明显
    • 电商导购：准确率超过大模型 + PE 20+pp
    • 电商选品：海量商品筛选+看品+选品报告生成，得分 +45%
  • 结论：垂域小模型 远远好于 通用大模型 + Prompt Engineering