目标： 从Quality engineering的角度，理解AgentEvoler中self-question部分的实现，思考这个部分是否可以作为对Agent/Multi-Agent workflows的测试生成方法
AgentEvolver中的一个模块是self-question， 总体思路是根据在一个可交互的沙盒中，根据人类编写的environment profile， 通过可交互沙盒中自带的seed tasks，使用SOTA大参数模型(qwen-plus)来探索沙盒，探索的结果是沙盒的能力范围（trajectory），再将每一个seed task和对应沙盒的能力范围(trajectories)传入给一个更大的SOTA模型(qwen3-235b-a22b-instruct-2507)，让它通过能力范围反推出新的合成task（更广范围，更深层次)， 再通过2次过滤（重复task, 无法执行的task），剩下可以执行的合成task, 这些可以执行的合成task的trajectory将会变成ground_truth（标准答案），因此在整个self-question阶段，没有任何对self-question的奖励机制。
因此在self-question的部分，核心逻辑就是用大模型来生成合成task, 这就是ground_truth, 来强化学习小模型(qwen-2.5-14B-Instruct)
以下是在self-question中每个阶段的重要步骤：
思考
1. 交互沙盒的特殊性和局限性
沙盒是有限的，但是实际用户的世界是无限的，合成的task仅局限于当前的沙盒，如果需要新的世界，那么需要建立不同的可交互沙盒，这增加了在测试过程中的成本。
除此之外，该文在self-question中的主要核心思想，是在SOTA LLM的基座上，如果能完成的task，他的trajectory就是ground truth, 也就是这一步是生成ground truth的步骤，但如果可交互沙盒内的状态机本来就有bug，这可能会导致生成的测试也不完全正确，那么对于可交互沙盒内的状态机还需要测试，也增加了单独使用self-question模块作为测试用例生成的成本和不确定性
2. 大模型到小模型的强化训练中task生成，这种思路是否可以移植到QA的测试用例生成？
部分可以，但是当测试agent / multi-agent workflow时， 当前self-question生成的测试都是大模型已经可以完成的，如果大模型可以成功执行的task在小模型中执行失败，这种test case 可以发现小模型的局限性，但是别人可以说-为什么我的被测agent/multi-agent workflow 不直接使用大模型，这种测试在一定情况下是有用的，例如agent/multi-agent workflow由于成本和效率的原因，必须使用较小模型。
3. 双重成本
在探索可交互沙盒时，需要使用高温SOTA来实际运行, 而在过滤阶段，为了生成ground_truth, 我们让然需要再次使用SOTA来实际执行合成的task。
4. task生成的深度和广度
为了合成更广和更深层次的task, 必须需要使用极大的LLM基座，在本文中是qwen3-235b-a22b-instruct-2507，task生成的广度和深度完全由一个静态prompt控制，好处是整个生成过程不需要vLLM，但不太理想的地方是全程SOTA模型， 且遗传生成的控制方法单一。
5. 在探索和回放时的Multi-turn 交互
在探索和过滤阶段，他都使用了multi-turn的方式，这样可以得到更准确的trajectory, 即更加精确的ground_truth。
Top comments (0)