RP-ReAct：面向复杂企业任务的推理-规划-执行多智能体架构

一句话定位

小学生也能听懂

这篇论文像搭积木一样，把大任务拆成“想计划”和“动手做”两个小人合作完成，聪明小人负责安排步骤，勤快小人负责操作工具，还聪明地只记关键信息，避免记太多忘掉重点，这样在复杂任务中更稳、更准、更通用。

为什么值得记录

解决单智能体架构在复杂多工具任务中因上下文过载导致的轨迹偏离问题
针对企业场景下必须使用本地开源模型（上下文窗口小）的数据隐私需求提供有效方案
在 ToolQA 基准测试中，在 hard 任务上显著优于 ReAct 和 Reflexion 基线，尤其展现更强的泛化性与跨模型稳定性
提出可复用的上下文管理机制，缓解大工具输出对 LLM 上下文的占用

核心方法

采用双角色多智能体架构：Reasoner-Planner Agent (RPA) 负责高层推理与动态重规划，Proxy-Execution Agent (PEA) 负责具体工具调用
RPA 使用 Large Reasoning Model 进行子步骤规划与执行结果分析，通过 <|begin_search_query|> 和 <|end_search_result|> 标签与 PEA 通信
PEA 基于 ReAct 框架实现‘思考-行动-观察’循环，将抽象指令转化为具体工具操作
引入上下文节省策略：当工具输出超过阈值 T=100 tokens 时，仅保留前 T 个 token 在上下文中，其余存入临时变量供按需调用
支持动态错误处理：RPA 可基于 PEA 返回结果判断成功/失败，并触发重规划或修正步骤
实验配置：1 RPA + 1 PEA，最大步数限制为 RPA 10 步 + PEA 每轮 10 步（总上限 100 步）

关键结果

在 ToolQA 的 5 个领域（Airbnb, Flight, Coffee, Scirex, Yelp）上评估，涵盖 easy 和 hard 难度任务
在 hard 任务中，RP-ReAct 平均准确率显著高于 ReAct 和 Reflexion，尤其在需要多步推理和跨工具协作的场景
在 open-weight 模型（gpt-oss-20b/120b, Qwen3-14B/32B, DeepSeek-7B/8B）上测试，RP-ReAct 表现出更低的性能标准差（Std），说明其跨模型稳定性更强
Combined Performance Score (CPS) 显示，RP-ReAct 在 hard 任务上实现最佳性能-稳定性权衡
消融实验表明，将 ReAct 步数上限从 20 提升至 100 仅带来平均 4.8% 的性能提升，证明轨迹稳定性比步数更重要

局限与风险

当前仅测试 1 RPA + 1 PEA 配置，未探索多 PEA 并行执行的可能性
未对 RPA 和 PEA 进行任务特定的微调（如 SFT 或 RL），性能仍有提升空间
上下文阈值 T=100 为固定值，未系统研究不同 T 值或引入摘要机制的影响
小模型（<10B 参数）仍难以稳定完成任务，主要因过早响应或轨迹偏离，表明架构对模型能力有下限要求

适合沉淀的概念

multi-agent-architecture, reasoner-planner-agent, proxy-execution-agent, context-window-management, tool-use-generalization, trajectory-stability, enterprise-ai-agents, react-vs-rp-react

阅读注意

关注 RPA 与 PEA 之间的通信协议设计，特别是标签化消息传递机制
注意上下文节省策略的具体实现：如何截断输出、存储变量、并在需要时触发 Python 分析
对比 ReAct 与 RP-ReAct 在 hard 任务上的失败模式差异：前者多因上下文过载导致轨迹偏离，后者更稳定
观察小模型表现差的原因：PEA 忽略指令直接回答，RPA 参数选择错误，反映提示工程对弱模型的重要性
附录中的提示模板具有高度复用性，可用于构建类似的企业级智能体系统

质量说明

采用来源：raw，raw/papers/2025/12/2512.03560.md
生成模型：LongCat-Flash-Chat
源材料判断：论文提供了完整的方法描述、实验设置、结果分析及消融研究，代码已开源，数据与模型选择透明，结论有充分实验支撑。