Tool Use Incentivization via Reward Shaping

编码Agent在仅以最终任务成功为优化目标时，往往未能充分利用专用工具（如编译器、代码检查器、测试运行器）。它们会默认依赖“思维令牌”——即生成内部思维链——而非调用外部工具，这会拖慢开发进程，并导致代码输出质量欠佳。

• 像R1这类模型几乎完全“依赖自身思维令牌”，而非调用工具，只有当使用工具能获得明确奖励时才会例外。
• 若缺乏中间激励机制，Agent在任务推进至最终阶段前，不会有动力去编写代码、编译程序或运行测试。

为每个对最终代码正确性有贡献的中间工具调用提供密集型塑形奖励。核心组件如下：

1. 定义工具专属奖励信号

• 编译奖励：若代码编译无错误，奖励+1。
• 代码检查奖励：若代码检查工具（linter）返回无问题，奖励+0.5。
• 测试奖励：若测试套件通过新测试用例，奖励+2。
• 文档奖励：若添加或修正文档字符串（docstring），奖励+0.2。

2. 回合级聚合

• 将所有中间奖励求和，生成累积的「编码进度」得分。
• 结合最终奖励（例如全测试套件通过或PR合并），指导策略更新。

3. 策略更新机制

• 结合上述塑形奖励，使用近端策略优化（Proximal Policy Optimization, PPO）或优势演员-评论家（Advantage Actor-Critic, A2C）算法。
• 在每轮RL滚动过程中，跟踪(state, action, tool_result, local_reward)元组。

# 伪代码：在每步RL步骤中，完成工具调用后：
if action == "compile":
    local_reward = 1 if compile_success else -0.5
elif action == "run_tests":
    local_reward = 2 if new_tests_passed else 0
# ... 其他工具奖励逻辑 ...
trajectory.append((state, action, tool_output, local_reward))

• 工具插桩：将compile()、run_linter()、pytest等工具调用用可返回二进制或分级成功信号的函数进行封装。
• 超参数调优：调整奖励幅度，避免Agent“过拟合”单一工具（例如反复获取代码检查奖励却未实现实际功能）。
• 课程式任务设计：从简单任务（如“修复一个失败的测试用例”）入手，收集早期正向反馈信号，逐步扩展至多文件重构任务。

• 优点：
  • 更密集的反馈：逐步引导Agent，减少对稀疏的最终成功信号的依赖。
  • 工具使用：鼓励Agent学习如何以及何时调用编译器和测试运行器。
• 缺点/注意事项：
  • 奖励工程开销：需要为每个工具精心设计和维护奖励函数。
  • 潜在过拟合问题：Agent可能会钻中间奖励的空子（例如，反复运行lint工具而不修改代码）。