Asynchronous Coding Agent Pipeline

编码任务的同步执行——即Agent需等待编译、测试、代码静态检查（linting）或静态分析完成的执行模式——会产生计算气泡与闲置资源。当编码Agent发起工具调用（例如run_tests()）时，它会在工具返回结果前暂停后续推理进程，导致GPU/TPU利用率不足，且RL rollouts（强化学习轨迹推进）速度放缓。

• RL Agent必须全力推行异步强化学习（async RL），以此实现“所有操作并行执行，避免计算气泡膨胀”的目标。
• 对于编码Agent而言，每个受I/O约束的工具调用（如编译、测试运行）耗时可达数秒至数分钟。

将推理（inference）、工具执行与学习解耦为并行的异步组件，通过消息队列实现通信：

1. 推理工作器（GPU）

• 持续从最新策略中采样。
• 输出的“动作”分为两类：一类是低计算量操作（例如“建议下一行代码”），另一类是外部工具调用（例如“CompileSubagent(serviceA)”）。

2. 工具执行器（CPU / 容器宿主）

• 监听工具调用请求队列（包含compile、run_tests、lint等请求）。
• 在隔离环境中运行各工具，随后将运行结果（成功/失败状态、日志）推送回推理工作器。

3. 奖励建模单元（GPU/CPU）

• 消费已完成的轨迹（由(状态, 动作, 工具输出)组成的序列），计算回合级或最终奖励（例如通过inference_healed_reward实现）。
• 将(轨迹ID, 奖励)推送给学习器。

4. 学习器/参数服务器（GPU）

• 定期聚合近期轨迹产生的梯度，更新策略权重，并发布新的模型检查点（checkpoint）。

5. 重放与缓冲系统

• 经验重放：存储近期的(状态, 动作, 奖励)元组，供学习器采样小批次数据。
• 优先队列：若某些编码环节表现出高方差（例如编译成功与否不稳定），则使用更新后的奖励模型重新评估这些环节。

• 消息中间件：使用Redis Streams或RabbitMQ Topics对compile_requests、test_requests这类工具调用请求进行排队。
• 自动扩缩容策略：监控队列长度：若compile_requests队列长度超过阈值，则启动额外的CompileSubagent容器。
• 故障处理：若工具执行器崩溃或发生网络错误，发送“retry”或“skip”消息；若重试次数过多，将该轨迹标记为stale。
• 检查点频率：确定Learner发布新策略权重的时间间隔（例如每1000个回合），以避免产生过多网络流量。

• 优势：
  • 高利用率：在CPU密集型任务并行运行的同时，GPU可持续执行推理或训练任务，始终保持忙碌状态。
  • 可扩展计算：可独立对推理、工具执行和奖励建模模块进行算力扩容。
• 劣势/注意事项：
  • 系统维护复杂度高：需在多服务体系下搭建可靠的监控、日志记录和告警机制。
  • 数据过时管理：策略模型可能基于略有过时的数据开展训练；超参数必须纳入对可接受过时窗口的考量（例如5–20分钟）。