刷到就进来接受八股拷打，尝试回答一下吧！
为什么原生GRPO不适合长程Agent任务？

GRPO在数学题、代码题上很好用，但放到长程Agent任务里，往往会遇到一个核心问题：GRPO更擅长“整条轨迹打分”，但长程Agent真正需要的是“每一步都知道自己做得好不好”。原生GRPO通常会针对同一个问题采样多条回答，再根据最终Reward做组内相对比较，算出Advantage，最后更新整条Trajectory。

但长程Agent往往是：思考→搜索→调用工具→读取结果→再次规划→继续调用工具→Compaction→最终回答一条轨迹可能有几十步，甚至几万Token，所以：

1.信用分配太粗：假设Agent前9步都对，第10步调用错了工具，最终任务失败。如果只看最终Reward，模型很难知道到底是哪一步出错，前面正确的步骤也可能一起被惩罚。这就是长程任务里非常典型的Credit Assignment问题。

2.不同轨迹很难直接比较：GRPO依赖Group Relative比较。但长程Agent里，一条轨迹可能10步完成，另一条30步完成，还有的搜索很多次、中途Compaction，甚至被拆成多个子轨迹。这些Trajectory长度、状态、工具路径差异都很大，组内比较会变得非常“吵”，Advantage也更不稳定。

3.奖励太稀疏：很多Agent任务只有最后才知道成功还是失败。比如执行了50步，最后Reward=1或0，那么前49步几乎没有直接监督。轨迹越长，最终奖励越难准确指导前面的每一步。

4.Rollout成本太高：GRPO还需要同一个问题采样多条完整轨迹。如果一条Agent轨迹本身就需要几十次LLM调用、搜索和Tool Call，再一次Rollout 8条，训练成本会非常高。

所以长程Agent用什么？目前更适合的是Actor-Critic类方法，比如PPO+Critic+GAE。Critic可以在每一步估计“从当前状态继续下去，未来大概能拿多少奖励”，再通过GAE计算更细粒度的Advantage。还可以结合Step Reward、Process Reward、子轨迹训练，把几十步任务拆开做信用分配。
面经 互联网大厂 大模型算法 agent算法 计算机专业 电子科技大学oc字节跳动