Signal #20：当 Agent 开始塑造模型

过去，我们通常把模型和 Agent 看成上下两层。模型先被训练出来，Agent 产品再把它接入代码仓库、终端、浏览器和测试环境。模型负责理解与推理，Harness 负责组织上下文、调用工具、维护状态并验证结果。

这套分工没有消失。但本周三条信息放在一起，说明两层之间的关系正在变化。

Cursor 将开发者与 Agent、Agent 与执行环境的交互用于模型训练；OpenAI 把工具协调和多 Agent 并行放进模型接口；NVIDIA 则根据具体模型的失败轨迹调整 Harness。

Agent 不再只处在模型的下游。它在真实任务中的行为，开始影响模型学习什么、如何行动，以及以什么方式接入工程系统。

Cursor 与 SpaceXAI 联合训练 Grok 4.5 时，使用了数万亿 Token 的 Cursor 数据。根据官方披露，这些数据覆盖了用户如何与代码库和软件工具交互，也包含开发者与 Agent 的互动，以及 Agent 如何在执行环境中工作。

强化学习也被放进了更接近真实工作的环境。模型需要调查问题、调用工具、从错误中恢复并验证结果。为了批量构造这些环境，Cursor 还搭建了一套分布式 Agent 系统，由多个 Agent 创建、测试和改进训练任务。《Introducing Grok 4.5》 (Cursor)

这类数据与传统代码语料提供的信息并不相同。

代码仓库、Issue 和 Patch 可以告诉模型，一个问题最终如何被解决；Agent 在任务中的行为记录，则保留了到达结果之前的过程：它先搜索了哪些文件，调用了什么工具，在哪一步判断失误，测试失败后如何继续，以及开发者在什么位置进行了纠正。

对于长时间运行的 Coding Agent，这些过程会直接影响任务能否完成。模型需要掌握的不只有代码知识，还要学会如何在一个有状态、会出错、信息经常不完整的环境中持续行动。

这也带来了一种新的数据循环：真实任务进入 Agent 产品，产生工具调用、失败恢复和人工反馈；这些数据进入训练与评测后，模型会更适应产品里的工作方式，随后又在更多真实任务中产生新的反馈。

以往讨论 Coding 模型的训练优势，注意力更多集中在代码语料、模型能力和公开评测上。接下来，高质量的 Agent 执行轨迹也会成为重要资产。它不仅记录任务结果，也记录模型如何在工作现场行动。

另一项变化发生在模型接口上。

传统的 Agent Loop 大多由应用层维护：模型选择工具，应用执行工具，再把结果放回上下文；模型继续判断下一步，直到任务完成。工具返回的筛选、子 Agent 的启动、中间状态的管理和多个结果的汇总，也主要由外部系统完成。

GPT-5.6 在 Responses API 中引入了 Programmatic Tool Calling。模型可以编写并运行轻量程序，在内存中协调工具、处理大量中间结果、监控进度，并根据执行情况决定下一步。Multi-agent Beta 则允许模型并发运行多个子 Agent，再在一次请求中综合它们的结果。《GPT-5.6》 (OpenAI)

过去完全位于应用层的一部分编排逻辑，正在成为模型服务提供的原生能力。

这并不意味着外部 Harness 会消失。执行环境、权限控制、凭证、任务状态、成本预算和最终验证，仍然需要工程系统承担。变化在于，模型接口已经不再只面向一次问答或一次工具选择，也开始面向一段持续执行的 Agent 工作过程。

Agent 不只改变模型训练的数据，也开始改变模型以什么方式被调用。

变化并非只有一个方向。模型在适应 Agent 工作负载，Harness 也在根据模型的具体行为进行调整。

NVIDIA 最近介绍了如何为 Nemotron 3 Ultra 建立 LangChain Deep Agents Harness Profile。基本过程是先运行评测、分析失败轨迹，再调整 System Prompt、工具描述、Middleware 或子 Agent 配置，随后重新运行完整评测，检查改动是否有效、是否引入回归。《Create a LangChain Deep Agents Harness Profile for NVIDIA Nemotron 3 Ultra》 (NVIDIA Developer)

其中一个案例很能说明问题。

任务要求 Agent 找到一个大文件的最后一个非空行，但 read_file 第一次只返回前 100 行。Nemotron 3 Ultra 没有继续分页读取，直接根据当前结果作答，因此漏掉了位于文件后部的正确内容。

团队没有重新训练模型，也没有修改底层工具，而是在 Harness 中加入一段 Middleware：当工具返回的内容可能被截断时，显式提醒模型文件还有后续内容，并告诉它下一次应该使用什么 offset 继续读取。加入这个适配后，相关测试全部通过，完整评测结果也有所提升。(NVIDIA Developer)

这个案例说明，同一套 Harness 并不能默认适配所有模型。

不同模型对工具名称、返回格式、分页方式、错误提示和上下文结构的反应可能不同。有些模型会主动检查工具结果是否完整，有些模型会把当前返回当成全部内容；有些模型善于拆分子任务，有些模型在长任务中更容易偏离目标。

更换模型因此不只是修改一个模型名称。Prompt、Tool Schema、Middleware、重试方式和验证策略，都可能需要一起调整。

模型开始学习 Agent 如何工作，Harness 也开始学习模型如何工作。

当模型与 Agent 系统共同优化，单看公开 Benchmark 会越来越难判断真实效果。

JetBrains 最近研究了 Coding Benchmark 的迁移问题。结果显示，模型在被训练过的特定任务上可以取得明显提升，但这些收益经常无法迁移到其他 Benchmark，甚至无法稳定迁移到同一代码库中稍有变化的任务。《The Benchmark Meaning Gap》 (The JetBrains Blog)

一项真实 Agent 任务的结果，同时受到模型、代码搜索工具、上下文策略、执行环境、测试条件和 Harness 的影响。排行榜说明的是某个模型在一套固定设置下的表现，很难直接回答它在另一个团队、另一类仓库和另一套交付流程中的效果。

研发团队需要沉淀自己的工作负载。

可以从历史需求、Bug、PR Review 和线上问题中整理一批可回放任务，固定仓库版本、输入材料、执行环境和验收方式；同时保留关键工具调用、失败位置、人工纠正、测试结果和最终 Review 意见。

当模型切换或 Harness 调整后，再用同一批任务检查改善与回归。评估对象也应当从单独的模型，扩展为“模型 × Harness”的组合。

大多数研发团队没有必要训练基础模型，但可以把真实任务、验证环境和失败轨迹组织起来。这样既能更准确地选择模型，也能判断问题究竟来自模型能力、上下文供给、工具设计，还是验证环境。

Agent 依然建立在模型之上，只是这段关系正在由单向调用变成双向反馈。

真实任务把新的训练信号带回模型，模型暴露出的具体问题又推动 Harness 调整。对模型厂商来说，Agent 产品正在成为训练与评测环境；对研发团队来说，真实任务和失败轨迹会成为更有价值的工程资产。

下一轮 AI Coding 的差距，会越来越取决于模型、Harness、工具和评测环境，能否围绕同一组真实工作负载持续迭代。

这周值得记录的变化就在这里：Agent 开始塑造模型。