CoTrace提出终端智能体训练新思路：运行时与模型协同进化，Qwen3.5-9B任务通过率提升

事件核心：发生了什么

终端智能体的能力不只取决于模型权重，还取决于它周围的运行时环境——即负责格式化提示、绑定工具、解析反馈和处理错误的harness。现有协同进化方法虽然能同时改进模型和运行时，却把搜索过程中产生的轨迹当作无差别的回放池，忽略了轨迹的价值与生成它的运行时强相关。

这篇论文建立了交替协同进化框架，将 harness 搜索与策略训练解耦，并引入 CoTrace 数据配方，明确管理轨迹路由、来源匹配和课程刷新。具体做法是：反复出现的执行失败被用来改进 harness；而模型训练则严格使用与当前采用运行时匹配的、已验证的 rollout——SFT 使用离线数据，RL 使用在线新交互。

实验基于 Qwen3.5-9B，在 Tmax 的 102 项冻结评测集上，CoTrace-SFT 将解决任务数从 78 提升到 88（其中 +4 来自 harness 更新，+6 来自模型更新），在线 RL 变体则达到 90。在数据对比中，保持 tournament search、meta-agent、trainer 和晋级协议不变，混合兄弟运行时池每轮提供 149–308 条轨迹，5 次模型候选中 0 次被接受；而仅用优胜者加新鲜 harness 匹配 rollout 的方案每轮提供 30–50 条轨迹，5 次中 2 次被接受，累计 +6 任务。每轮成本约为 47 GPU 小时对 54 GPU 小时；但总计算量上，混合兄弟方案约 162 GPU 小时，CoTrace-SFT 约 235 GPU 小时。论文同时指出，该结果受 freshness、覆盖度和提示等多因素共同影响，尚未单独隔离每个机制的效果。

为什么重要

这条路线把「运行时」从工程细节提升为模型训练的一等公民。过去许多团队把训练数据当作通用资产，忽略了数据与部署环境之间的兼容性；CoTrace 用来源匹配证明，不匹配的轨迹可能不仅无益，还会拖累模型。对于正在投入终端智能体、代码助手或自动化运维的团队，这意味着算力预算的分配方式可能需要调整——更小但匹配的语料，可能比更大但混杂的语料更有效。

此外，论文在 Terminal-Bench 2.1 和 SWE-bench Lite 上的评测显示，分布外迁移能力根本上取决于 harness 兼容性：训练与评测运行时保持一致，可以避免在陌生 scaffold 下出现的程序性执行崩溃。这为「评测分数能不能代表真实部署」提供了一个新的解释维度。

对用户/开发者/创作者的影响

对开发者而言，如果正在基于终端、IDE 或 CI 流程构建 AI 代理，需要开始记录并管理轨迹的来源元数据——是哪个 harness、哪套工具绑定、哪版提示模板生成的。直接混用不同框架下的成功案例，可能降低微调收益。使用 SFT 或 RL 时，优先考虑与生产运行时匹配的数据，而非单纯堆量。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

对企业采购方来说，评估终端智能体产品时，除了看模型榜单，还应关注厂商是否公开其训练与推理时的一致性策略；一个在 demo 上表现好但 harness 频繁切换的产品，实际落地可能出现执行稳定性问题。

对算力敏感的小团队，CoTrace 的思路提供了一个务实方向：用失败的执行来驱动运行时改进，用少量高质量、来源清晰的轨迹来训练模型，可能比租用大规模集群跑混杂数据更划算。不过论文也提醒，总计算量并不一定更低，需要结合自身流水线判断。

值得关注的后续

一是 CoTrace 是否会开源代码或数据配方，让更多团队复现这套路由与匹配机制；二是 Terminal-Bench 2.1 和 SWE-bench Lite 上的迁移结论能否在更广泛的终端任务和模型规模上成立；三是主流 agent 框架（如 LangChain、AutoGen 等）是否会在工具链中内置轨迹来源标记，推动「运行时匹配」成为默认实践。目前公开信息显示，该工作仍处于论文阶段，尚未见产品化或同行评审状态的明确说明。

来源：alphaXiv