跳转至

Agent & Agentic RL

导言

Agentic RL 和 memory 是2026年的发展方向。本文将调研 Agentic RL 在多模态的发展潜力。

智能体的等级和发展

OpenAI 24年7月就提出 5种水平的AI。

  • 一级：聊天机器人，这是能以对话语言和人类互动的AI。
  • 二级：推理者，这种AI可以解决人类级别的问题。
  • 三级：智能体，这种AI是可以采取行动的系统。
  • 四级：创新者，这是可以帮助发明创造的AI。
  • 五级：组织，这种AI可以完成一个组织的工作。

Agent 大火，就是第二级到第三级到体现。

25年年中，有论文细化了该智能体的分类：受汽车工程师协会（SAE）自动驾驶六级分类的启发，智能体也根据其功能和能力被划分为以下层级：

  • L0——无 AI，具备工具（有感知能力）和行动；
  • L1——使用基于规则的 AI；
  • L2——用基于模仿学习（IL）/强化学习（RL）的 AI 替代基于规则的 AI，增加推理和决策能力；
  • L3——应用基于大型语言模型（LLM）的AI 替代基于 IL/RL 的 AI，并设置记忆和反思功能；
  • L4——在 L3 的基础上，实现自主学习和泛化能力；
  • L5——在 L4 的基础上，增加个性（情感 + 性格）和协作行为（多智能体）。

可以见得后续的发展方向：记忆、反思、自主学习、泛化、个性和协作。

Agent

核心特质

特性：自主、主动、响应、目标导向；2 能力：工具、记忆、通信。 价值：结构化、复用性、可靠性与效率，聚焦应用创新。

未来：五大假设

  • 通才 Agent：稳定处理模糊、长期目标。
  • 主动个性化：从被动响应到主动协助。
  • 具身交互：走出屏幕，进入物理世界。
  • Agent 经济：自治体成为生产与交易主体。
  • 目标驱动与动态编队：按目标自组多 Agent。

设计模式

21种设计模式2

  1. 任务与控制模式
  2. 记忆与知识模式
  3. 工具与环境交互模式
  4. 协作与多 Agent 模式
  5. 安全与治理模式

具体如下：2

  1. 提示链（Prompt Chaining） 定义：任务分步拆解，步步相承。 关键做法：系统提示、上下文构建、结构化输出。 场景：抽取→转换、复杂问答、代码生成。
  2. 路由（Routing） 定义：按意图/状态分流到子流程/工具。 关键做法：LLM/规则/嵌入/ML 路由。 场景：客服分流、多工具/多模型选择。
  3. 并行化（Parallelization） 定义：独立子任务并发执行，汇总合并。 关键做法：fan-out/fan-in、去重与融合。 场景：多源检索、批量分析、多候选生成。
  4. 反思（Reflection） 定义：自评 → 修正 → 迭代。 关键做法：Producer/Critic、反思提示、自动回环。 场景：写作/代码优化、复杂问题求解。
  5. 工具使用（Tool Use / Function Calling） 定义：以函数调用接入外部 API/系统。 关键做法：清晰 schema、参数校验、错误回退。 场景：检索、计算、数据库、执行动作。
  6. 规划（Planning） 定义：面向目标的动态计划与调整。 关键做法：任务分解、依赖排序、滚动更新。 场景：自动化流程、长任务、研究报告。
  7. 多智能体协作（Multi-Agent Collaboration） 定义：专长代理分工协作，整体优于个体。 关键形态：顺序/并行/辩论/层级/监督。 场景：研发、运营、客户支持、供应链。
  8. 记忆管理（Memory Management） 定义：短期上下文 + 长期向量库。 关键做法：消息/状态/Memory Service，检索策略。 场景：个性化助手、任务型代理、RAG。
  9. 学习与适应（Learning & Adaptation） 定义：基于反馈持续改进与自我优化。 关键做法：RL/监督/在线学习，自我改进编码。 场景：交易、推荐、机器人、编码代理。
  10. 模型上下文协议（Model Context Protocol, MCP） 定义：标准化上下文/工具/资源的接口层。 关键做法：客户端 - 服务器，资源/工具/Prompt 可发现。 场景：数据库、API、文件系统、跨工具互操作。
  11. 目标设定与监控（Goal Setting & Monitoring） 定义：目标 → 里程碑 → 进度追踪与校验。 关键做法：状态机、成功条件、自动评估。 场景：项目助手、客服、机器人、合规。
  12. 异常处理与恢复（Exception Handling & Recovery） 定义：检测 → 处理 → 恢复/回滚。 关键做法：重试、降级、备用路径、告警。 场景：工具失败、API 限流、数据错误。
  13. 人类参与环节（Human-in-the-Loop, HITL） 定义：关键节点引入人工判断与监督。 关键做法：升级策略、人工反馈驱动学习。 场景：内容安全、法律/金融、复杂支持。
  14. 知识检索（RAG） 定义：检索增强生成，外部知识入模。 关键做法：分块/嵌入、召回→重排→融合。 场景：企业搜索、客服、知识问答。
  15. 智能体间通信（Agent-to-Agent, A2A） 定义：跨代理通信与协作协议。 关键做法：Agent Card、异步任务、鉴权审计。 场景：跨框架协作、工作流编排。
  16. 资源感知优化（Resource-Aware Optimization） 定义：在成本/延迟预算内优化效果。 关键做法：多模型路由、故障转移、上下文裁剪。 场景：成本控制、SLA、移动端/边缘。
  17. 推理技术（Reasoning Techniques） 定义：为推理阶段分配更多算力。 关键做法：CoT/ToT、ReAct、代码执行、辩论。 场景：复杂推理、数学、规划、调试。
  18. 护栏与安全（Guardrails & Safety） 定义：输入→行为→输出全链路约束。 关键做法：策略提示、模式校验、内容审查。 场景：生成式应用、客服、教育、社媒。
  19. 评估与监控（Evaluation & Monitoring） 定义：质量/成本/延迟与轨迹评估。 关键做法：LLM 评审 + 指标、A/B、日志追踪。 场景：上线验证、漂移检测、治理。
  20. 优先级排序（Prioritization） 定义：按价值/紧急度排队并调度。 关键做法：评分模型、依赖/资源感知调度。 场景：个人助理、队列系统、运营自动化。
  21. 探索与发现（Exploration & Discovery） 定义：在不确定环境中试错学习。 关键做法：随机性、奖励信号、环境模拟。 场景：研发、内容生成、游戏、机器人。

可见完整体的Agent是相当复杂的，但是什么能力能够沉淀到框架，需要分析。

AI Infra的新形态：Agentic Infra

作为Ascend的一员，我们理应牵头设计统一的AI Infra核心，避免客户各自为战，让Ascend的适配压力巨大。但同时AI发展迅速，我们需要拨云见日，看清AI Infra的长期形态，和我们应该构筑的长期竞争力。

传统代码是固定逻辑，是极高可用性的。但是到Agent场景下，代码大多是agent生成的，后续人们甚至会超发请求，来选择方案。3

今天，当代码的生成和执行都开始带有概率性时，可靠性将越来越依赖于冗余、约束、隔离和可恢复性。 未来高可靠系统可能在很多地方变得更重、更保守。 AI 让生成代码变得言出法随，却让执行的边界变得异常模糊。它没有减轻基础设施的责任，而是把更多责任重新压回了 Infra 执行层。

如果说上一次 Infra 的代际变化，核心是把资源虚拟化出来，让开发者不用再关心物理机在哪里，那么这一次更值得被虚拟化的，可能是执行本身，也就是把恢复、隔离、分叉、续跑这些复杂性压到 runtime 下面。

核心构建概念

  • 协调与编排（Agent 本质是分布式系统）
  • 资源争用
  • 故障隔离
  • 可观测性与回滚
  • 阶段间的确定性产物

看趋势Agentic RL，最终会做到OS这一层，成为现代系统的基础。

与当前商业模式的结合

作为训练开发部的一员，在现场的几点局点待过后，客户可以分成几类：

  • 有大型基础模型需求的：（有训练的完整流程：数据处理、预训练、SFT、RL）
    • 这些客户多数是GPU为主：ZJ智创、电信、浦江。
    • 这些客户Agentic RL的流程算法，有专门的算法团队（10人+），基本在GPU就设计好了/边设计边迁移到NPU。
    • 基本没有Ascend方主导的空间。
  • 业务面还有垂类模型需求的：（也有训练的完整流程，但是数据集规模和参数量会小一个数量级）
    • 这些客户多数是NPU为主，新浪、ZJ电商
    • 多模态理解这边都是围绕应用审核场景；生成也是围绕将不合规的图片改成合规之类的。
    • 这些客户的算法团队往往只有1人，Agentic RL的流程算法也是需要摸索的，如果Ascend方有可信的方案，客户比较容易接受。
  • 更小的微调场景：版本能力基本覆盖了。

可见，Ascend需要优先构建面向业务面效果提升的垂类Agentic RL方案。

核心指标

为了减少不同框架迁移的成本，将从下面的维度评价不同的开源框架：

  • 垂类场景覆盖度：agent有很多子类场景：code、gui 控制等。
  • 算法支持情况
  • 新模型接入难度：
  • 新算法接入难度：
  • Agent逻辑复杂度
  • Agentic RL效率
  • Agentic RL的核心功能
    • 可观测性与回滚
    • 评测
    • 多任务能力
    • 多工具链

目标是面向自身方案不明晰的客户，能针对其业务特性，快速打通一套有效的agent rl的通路。

开源实现

slime的思考和设计

之前的Agentic RL，类似Search-R1 , ToRL是在verl上拓展agentic能力，但是这种零散的设计，有很多重复工作， 同时agentic RL有些通用问题有待从架构层面解决：4

  1. 代理们在接口层面差异大，难以统一抽象；-> 需要接口抽象层，和统一推理Buffer
  2. 推理的结果需要过滤不完整和无效轨迹；-> 需要推理后处理（故障处理、重试、过滤），和统一推理Buffer
  3. 轨迹耗时过大，甚至30mins+，静态推理不行。-> 需要推理服务化，甚至是超发，避免阻塞。

设计1: Agent缓冲区

过滤和预处理逻辑完全可定制。

设计2: 服务化推理

verl 这种基于推理引擎（服务端）的实现，（1）无法兼容调用类OpenAI API的工具（客户端）。 （2）这种引擎在内部做批处理，很容易遇到长尾问题。

设计3: 完全异步RL

相对于同步是1.6x提升。

对比

基于25年3月版本。

  • Slime : 稼先
  • ROLL
  • verl

对比

｜ 开源框架 ｜ star | 场景｜算法 ｜ |---|---|---| | slime ｜ 4.8k ｜ Qwen3VL的GEO3k的多轮 ｜ GRPO、GSPO、TIS ｜ | OpenClaw-RL 基于 slime ｜ 3.3k ｜ Terminal+GUI+SWE+Tools ｜

OpenClaw-RL：（问题：暂时不支持vllm，现在只有sglang+megatron）

  • Terminal 能够自己搭建docker来支持并发的终端操作。
  • GUI是云服务虚拟机，提供画面截图，和执行操作动作。
  • SWE 能够自己搭建docker来支持github的问题修复。
  • Tools，需要自定义html接口。

参考文献

  1. Agent 设计模式 ↩

  2. Antonio Gulli 的新书 Agentic Design Patterns ↩↩↩

  3. 对话 Google 首席 Jeff Dean：概率性执行的 Agent 时代，Infra 必须重塑！ ↩

  4. slime的思考和设计 ↩

评论