BloomBloom
发起研究

JIT-Agent：自动生成 Agent 外壳的模型，换壳胜过换模型

同一个模型，换一层“外壳”能强多少？

2026 年的一份 agent harness 综述里记录了一个近乎荒诞的实验：xAI 的 Grok Code Fast 1 在 SWE-bench 上只有 6.7% 的通过率，研究者没有动模型的一个参数，只改了编辑工具的调用格式，分数跳到了 68.3%。一个数量级。十倍的差距，全部来自模型外面那层东西 Harness 综述。这层东西叫 agent harness（智能体外壳）。模型负责想，外壳负责让想法落地：记忆怎么存怎么取、任务拆成几步、动作按什么协议写、工具何时调用谁。同一个员工，坐在顺手的工位上和处处卡壳的工位上，产出可以差出数量级；对 agent 来说，这个“工位”就是 harness。对使用者来说，这个视角还解释了一个日常困惑：同一款模型在不同产品里表现天差地别，很多时候不是模型换了，而是壳换了。

这个结论不是抽象判断，它指向一整个可拆解的工程层。上述综述把 agent harness 拆成六个治理组件：execution loop（执行循环）、tool registry（工具注册表）、context manager（上下文管理器）、state store（状态存储）、lifecycle hooks（生命周期钩子）、evaluation interface（评测接口）Harness 综述。链路里模型推理只是其中一环，其余全部发生在模型外面。

图注：综述定义的六组件 harness 架构 H=(E,T,C,S,L,V)。箭头沿“环境观察 → 上下文组装 → 模型推理 → 执行循环 → 工具分派 → 世界动作”走完一个执行步骤，上方状态存储跨轮持久化，底部评测接口记录轨迹。它标出的是任务进行中的运行时治理，不是 prompt、也不是开发期框架 Harness 综述。

既然壳决定表现，成熟产品也早就把这层工程当正式工作来做。Anthropic 官方博客就直接把 Claude Code 称作 agent harness，定义是“把原始智能变成可用 agent 的脚手架” Claude Code。那就怪了：如此决定表现的一层，到今天仍主要靠人手写、按任务族预置。每个新场景，工程师都要重新琢磨记忆方案和工具编排。决定成败的壳靠手写，于是答案只剩一种可能：让模型自己来写。

2026 年 8 月 26 日提交到 arXiv 的 JIT-Agent 给的就是这个答案：训练一个专门的模型，让它看到任务后当场把外壳写出来。据论文自述，这是第一个专门为“即时 harness 生成”训练出来的模型（未做穷举检索）。要让机器来写壳，先得有固定笔法。论文把外壳形式化为四模块协议 h=(M,P,A,F)：memory（记忆）、planning（规划）、action（动作）、capability orchestration（能力编排）。固定一套协议，按任务实例化出不同的实现 JIT-Agent。

图注：JIT-Agent 总览。左侧是任务输入，中间是生成上下文（任务、协议、能力注册表、参考样例），右侧是同一套四模块协议 (M,P,A,F) 在深研究、产品生成、自主研究三类任务上实例化出的三套不同实现，最右侧是执行轨迹与观察的反馈回环 JIT-Agent。

右侧三套 harness 只是示例形态，不是论文强制的产物清单。关键在于：外壳本身可以是按任务生成的。如果外壳能决定成败、又是跟着任务变的，那为什么到今天还在人手写？因为“让机器来写壳”这件事，此前的尝试全都卡在同一个隐含假设上。

“先造好再用”的老办法，卡在哪？

先把“harness”这个词的边界讲清楚。它从软件工程的 test harness、机器学习评测的 evaluation harness，一路用到 agent 上。测试 harness 是任务跑完后把代码吊起来检查的架子，评测 harness 是模型答完题后在外部打分的裁判，两者都不参与执行本身。agent harness 不一样，中间有个真正的分水岭：前两种 harness 的控制发生在任务结束之后，从外部观察、打分；agent harness 的控制发生在任务进行之中，从内部管理执行 Harness 边界。控制发生在执行现场，意味着没法写一份就完事，也就比前两种难自动化得多。

在这条路上，此前的自动化统称 AOT（ahead-of-time，先造好再用）。AutoHarness、Meta-Harness、AHE 靠离线搜索，Adaptive AH、TTHE、RHI、Harness-R1 做测试时编辑。七条路线的共同假设是：harness 是一个面向“累积经验分布”优化的持久工件，一次优化好，之后所有任务都复用它。论文的反驳很直接：合适的壳不仅随任务领域而变，甚至随单个任务实例而变。用大白话说，老办法相当于提前磨好一副“平均脸”眼镜，再期待它适合每一张具体的脸。

这两类各自的难处还不一样。搜索类的 AutoHarness、Meta-Harness、AHE 在离线数据上穷举或优化外壳结构，采样的都是历史任务，一次成型后就不再动；编辑类的 Adaptive AH、TTHE、RHI 在测试时对同一个持久外壳做增量修改，Harness-R1 更进一步，有了生成模型和用执行反馈修复的能力。但无论哪一类，产物都是一个面向“过去经验分布”的持久工件，在线部署时遇到的具体任务，只是它发挥作用时的一次抽样。分布一变，壳就过时。所以 AOT 的适用边界其实很明确：部署分布稳定且均匀的场景里它够用，真正失灵的是长尾世界，新任务族不断冒出来，每来一类都要重跑一遍优化循环，成本与延迟都跟不上。此刻再看下面表里前两列的全空，就不只是一张缺陷清单，而是方法选择的必然结果。

论文用一张四列对比表把这个分歧钉死了。左右两列是“能力项”，上下是 JIT-Agent 和七条 AOT 路线的对照：

Table 1 的四项能力AOT 七条路线JIT-Agent
Instance synthesis（按任务实例当场合成外壳）✗（全部）✓
Harness model（训练一个模型专门生成外壳）仅 Harness-R1 打 ✓✓
Learned repair（学会用执行反馈修复外壳）仅 Harness-R1 打 ✓✓
Online evolution（部署期在线进化）仅 Harness-R1 打 ✓✓

逐列翻译出来就是：七条 AOT 路线没有一个做“实例合成”；训练出“生成模型”的只有 Harness-R1，它同时触及修复与在线进化两项，但同样缺“实例合成”一列。JIT-Agent 是唯一四列全勾的方法 JIT-Agent。

同期还有一个很近的邻居能当参照。HarnessForge（2026 年 6 月，与 JIT-Agent 作者群部分重叠）把 agent 系统写成“外壳加策略”的可执行对，每轮先 rollout 一批任务，让 meta-agent 归因 planning、action、memory 三类故障，按 Pareto 信息改写外壳，再用成功轨迹为每个存活的壳训练一个条件化的策略适配器，默认跑 3 轮、每轮保留 2 个幸存壳。它最有辨识度的结果在 API-Bank 的交叉配对矩阵里：最终轮的配套对能做到 77.19%，而把新壳配旧策略、新策略配旧壳的混搭组合只有 71% 出头。壳和模型必须配套，这个事实反而衬托出“按任务现配”的必要 HarnessForge。

所以卡点不在于“有没有自动化”，而在于自动化的对象：一个提前造好的通用壳，还是一个当场为当前任务合成的壳？论文选了后者，而把“写壳”变成模型能力，需要一整套工程：协议、种子库、三阶段训练。

当场写外壳：四模块协议与三阶段训练

先看协议本身怎么工作。四个模块按 M→P→F→A 的顺序协作：memory 把不可变事件历史和可变控制状态压缩成当前视图；planning 把视图和任务目标转成本步指令；capability orchestration 按指令从能力注册表里激活相关工具或技能；action 更新控制状态并发出动作。论文承认这套协议刻意做得比 Codex、Claude Code 的生产级 runtime 薄，因为它要验证的是“即使是一个紧凑的外壳也能带来大幅增益”，而不是复刻一整个生产系统。

为了让“合规”有硬边界，论文给生成空间分了层：模型能输出的所有外壳，逐层收窄到“协议可合成”“协议合规”“既能合规又能跑起来”三个子集。协议验证器 Valid_Π 卡在第二道闸口上，只放行合规的输出，不合规的还会带回一份结构化诊断报告，留给后面的修复阶段用。训练和推理都在这套夹逼下进行，“生成”从来不是自由发挥。

为了让“生成”不是凭空造词，论文先搭了一个协议兼容的种子库 HarnessFactory，把 13 个有代表性的当代 agent 脚手架用统一四模块格式重新实现一遍（论文表 2，种子数以论文口径为准）：

种子 harness记忆 M规划 P动作 A / 能力编排 F
ReActFullHistory—ReAct 动作 / Full 工具
Plan-and-Execute—线性路线图—
ReSumReSum 式摘要——
Flash-Searcher—DAG 分解—
GAMGAM 检索DAG—
MemoBrain推理图—Marker 引导
AggAgent隔离 rollout 历史—多 rollout 聚合
OAgent协调者历史—集成投票
AgentFoldAgentFold 折叠记忆DAGReActFold
HiAgent层级记忆——
DeepAgent三层记忆—工具搜索
ROMA上下文隔离Atomizer + DAG递归 / Full
AOrchestra同 ROMA同 ROMAAgent 委派

表格里“—”表示论文表 2 未单列该字段，沿用通用默认。看这 13 行会得到一个直觉：当代脚手架的核心分歧就在记忆怎么管、规划怎么拆、动作怎么聚合这三处。有的靠摘要或推理图做记忆（ReSum、MemoBrain），有的把任务编译成 DAG 再执行（Flash-Searcher、GAM、ROMA），有的让多个独立解投票定夺（AggAgent、OAgent）。生成一个新壳，本质上是从这些既有招式里选型、改造、组合。这个种子库既当训练参照，也当档案库的起点。而“生成”的落地形态是结构化的：模型必须按五个 tagged block 输出，最终写成 memory.py、planning.py、action.py、tool_policy.py 和一份 prompt.yaml，少一个文件就被静态门控判负 JIT 仓库。这等于把“写壳”变成结构化代码生成，而不是开放式编程。

接下来是三阶段训练，中间目标逐级递进：从“协议合规”到“可执行”，再到“超越档案库”。

图注：训练 pipeline 横轴为 Stage I 定制、Stage II 修复、Stage III 自进化。Stage I 由教师模型生成协议合规外壳，通过验证后送入模仿与偏好训练；Stage II 把失败外壳连同执行诊断转成 1–2 步修补轨迹；Stage III 从档案库采样候选，用 reward、latency、cost 三通道奖励评估，只把突破档案库前沿的设计写回档案库 JIT-Agent。

Stage I 教的是“照葫芦画瓢”。教师在任务上下文里参照种子库生成协议合规的示范，只有通过协议验证和执行检查的样本才进训练集。训练目标除了模仿，还配了一个偏好规则：两个候选外壳相比，只有 reward 严格更高、latency 和 cost 都不退化、且至少一项严格更优的那个才算赢。第一步不只学“会写”，还学“写得不比原有方案差”。训练任务的来源也铺得很开：WebWalker、TaskCraft、DeepPlanning、CLAWGym、PaperSearchQA、EnvScaler 等公开基准加上合成数据，教师对每个任务从种子库里抽 3 个参考脚手架再动手。

Stage II 教的是“救场”。Stage I 被拒的失败外壳连同结构化诊断报告进入第二阶段，教师为每个失败给出修订，只保留能在 1–2 步内修回可执行的轨迹（K*≤2）。这个设计精确锁定了“短程高杠杆修订”：模型学到的是“拿到一个几乎正确但不稳的壳，用执行反馈把它救回来”，而不是推倒重写。一个典型的场景是接口不匹配：新壳调用的工具签名和注册表对不上，诊断报告把这步标出来，模型在随后一两步里把调用改对，任务就能继续。

Stage III 教的是“破纪录”，算法叫 Evo-GDPO。先补一句背景：强化学习里常用的 GRPO（Group Relative Policy Optimization，组相对策略优化）出自 2024 年的 DeepSeekMath，核心招数是对同一问题采样一组输出，用组内均值做归一化当作优势信号，从而省掉庞大的价值网络 GRPO 原文。Evo-GDPO 站在 GRPO 肩膀上，但有两个关键差异。其一是多通道：reward、latency、cost 各成一个通道，各自独立归一化再加权，且任务 reward 的权重必须压倒效率项。其二是更重要的：它把“档案库前沿”当对手。标准 GRPO 只在采样组内争高下，谁比组内平均强就奖励谁；Evo-GDPO 要求新候选与档案库里已有的最佳外壳比，只有匹配或超过当前 reward 前沿、且至少一项严格更优，才被写回档案库。细节上还有两层保险：效率通道（latency、cost）只在候选的 reward 不输给档案库现有成员时才激活，意思是先让成绩够格，才谈快不快、贵不贵。目标函数带着 PPO 式裁剪和相对参考模型的 KL 约束，防止一次更新把模型推得太远。训练期模型参数和档案库一起更新，部署期只剩档案库在长大。

可以把它想成田径纪录的运转方式：组内归一化是一场小组赛，你只要比同场选手强；档案库前沿是历史纪录，只有破纪录才进纪录册，而新纪录又成为下一轮的门槛，所以系统越用越强。三步下来，“写壳”从合规被逼到可执行，再被逼到超越已有记录。那么问题来了：这套工程换来的收益，是真的能打，还是只在自家赛场上自嗨？

换壳之后：分数、成本，以及它写出的外壳

先看主结果，注意每个数字“相对谁”。JIT-Agent 给 GLM-5.2 当换壳助手后，9 个 benchmark 的平均分从 74.1 涨到 81.8，其中 7 项拿到 Top-1；给 DeepSeek-V4-Flash 当助手，18 个直接配对全部改善，均值从 66.7 涨到 75.5。这些都是相对“原始 backbone 自己跑”的提升。本来就强的 GLM-5.2 带上新壳后，在 BC+ 和 DeepSearchQA 上分别到了 78.0 和 93.9。GLM-5.2 的最大单项增益是 DeepPlanning-Travel 上 +20.2（62.8 → 83.0），也就是摘要里“up to +20.2”的出处 JIT-Agent。

再看反超更大模型的那组数字，这也是摘要里最抓人的一句。

图注：四个面板对应深研究、日常任务、规划、工作区四类 benchmark 的 leaderboard。每个面板里，带 JIT-Agent 的 GLM-5.2 与 DeepSeek-V4-Flash 横条压在更大更贵的 baseline（GPT-5.6、Claude Code、OpenCode 等）附近或之上。图中分数条按视觉比例放大，精确数值以正文表格为准 JIT-Agent。

DeepSeek-V4-Flash 是响应快、成本低的中档模型，套上 JIT-Agent 生成的壳，在 DeepSearchQA 上拿到 85.1 分；同一 benchmark 上 GPT-5.6 是 76.0。85.1 减 76.0 等于 9.1，这就是摘要里“surpasses GPT-5.6 (+9.1)”的来历，它是相对 GPT-5.6 的差值；而相对 vanilla DeepSeek-V4-Flash（76.2）的提升是 +8.9。两个数字差在“相对谁”，引用时得拆清楚。摘要在同一句里给 DeepSeek-V4-Flash 的另一个数字 OdysseyBench +4.3，口径却不一样：它是相对 GPT-5.6 的差值（73.0 vs 68.7），相对 vanilla 只有 +2.0（71.0 → 73.0），摘要口径混用，不能都当作相对 vanilla 的提升。先读懂“相对谁”，再讨论“有多强”。一个中档模型靠换壳压过旗舰，这层工程的权重不再是轶事，而是可复现的实验结果。

而且不是刷了个榜。同一个壳生成器搬到另外三个模型族上，6 个 backbone 乘 4 个 benchmark 共 24 个直接配对全部赢过固定 ReAct 壳，平均 +7.6 分；按家族算，DeepSeek V4 平均 +10.2，Mimo 2.5 平均 +8.6，Qwen 3.6 平均 +4.0。也就是说这个能力跟着 harness 走，不绑定某个特定模型。

论文还做了一组更接近实战的对照：固定 backbone，让 JIT-Agent 生成的壳去和 Claude Code、Codex、OpenCode、Hermes、NanoBot 这些成熟 runtime 直接比。6 个设定里，JIT-Agent 4 项性能第一，全部 6 项 token 用量和单任务成本最低，平均降本 36%（单例节省 14.9% 到 54.1%）。具体到两个 backbone：DeepSeek-V4-Flash 配 JIT-Agent 在 DeepSearchQA（$0.066）和 xBench-DS（$0.039）双榜夺冠，Qwen3.6-Flash 配 JIT-Agent 在 xBench-DS 和 AgentIF 夺冠。分数不是靠多烧 token 换来的，token 用量同样全场最低。还要提醒一句：这组对照里 backbone 是固定的，同样的模型只换壳，就能拉开这么大的差距。leaderboard 上“谁更强”的判断，很难摆脱壳这一层的影响。这些对手并不弱：Claude Code 的动态工作流模式能让 Claude 现场写 JavaScript 编排子 agent，已经接近“当场造壳”，但它仍是产品层面预设的套路；JIT-Agent 把这件事整个变成了模型的输出 Claude Code。

把成本和分数放到同一张 Pareto 前沿图上看，收益就更直观。DeepSearchQA 上，DeepSeek-V4-Flash 配 JIT-Agent 以 $0.066 的单价拿到 85.1 分，相对 NanoBot 的 $0.131/80.4，多拿 4.7 分的同时便宜了 49.6%。Qwen3.6-Flash 配 JIT-Agent 以 3.9 分的小幅让价，换回 51.8% 的成本下降；在 AgentIF 上则干脆严格支配所有固定外壳。换壳的收益不是刷出来的榜，而是让中档价位上出现了原本属于旗舰的表现 JIT-Agent。

那它写出的壳到底长什么样？论文挑了两个差异最大的生成样例画成协议流程图。

图注：同一生成器、同一四模块协议产出的两种形态：跨应用工件生成任务上，Palimpsest 把需求编译成 DAG、按有界宽度/深度执行就绪节点、用记忆索引中间目标与工件；多跳身份研究任务上，Trapdoor 动态拆解子问题、新增 delegate 能力，用事实图记忆管理递归委派的子代理 JIT-Agent。

一个是 DAG 工件流水线，一个是递归委派研究，结构完全不同，却出自同一个生成器。这比单纯换 prompt 更有说服力：外壳的形态真的在跟着任务结构变。但真正让“换壳”区别于“换模型”的，是这张收益能不能复利，也就是部署之后它还能不能自己变强。

一条与“换更大模型”并行的路：价值、局限与判断

论文把部署形态分成两种。静态模式（Static）一次性并行生成多个候选壳，验证加修补后只执行一个，多样性不增加实际运行次数。流式模式（Streaming）里，模型参数完全冻结，但每完成一个真实任务，就把执行反馈按 frontier 规则写回档案库，再供下一个任务检索。这是 JIT 与 AOT 的运营分水岭：AOT 上线即定型，JIT 的档案库在部署后持续进化，经验只通过档案库迁移。流式模式下，一个任务走完四步：从档案库取参考，生成并选出一个壳，执行，再按 reward、latency、cost 评估结果，按 frontier 规则决定要不要把反馈写回档案库，供下一个任务检索。

图注：两种部署方式并置。静态模式并行生成候选壳只执行其一，档案库不随运行回流；流式模式每完成一个任务就把执行反馈按 frontier 规则写回档案库，再供下一个任务检索。差别在于“部署后还能不能变强” JIT-Agent。

实验显示，三条任务流上 Streaming 的累计准确率持续高于 Static，而且不是靠更多交互成本换来的。训练期它边学边更新档案库，部署期模型冻结后档案库仍然进化，这就是“可复利”的落点。论文把这条能力轴总结成 harness intelligence 三性，恰好与三阶段训练一一对应：adaptivity（适配性，Stage I 学会按任务定制）、reliability（可靠性，Stage II 学会修复）、evolvability（可进化性，Stage III 学会超越档案库）。可训练、可迁移、可复利，合起来构成一条与“换更大模型”正交的能力轴。同一份综述还替三者的分工划过线：framework 是开发期的构建原语，harness 管运行时的治理，platform 管组织级的编排。JIT-Agent 落的是 harness 这一格，只是它不再满足于治理，还要求现场把治理方案写出来。把它放上时间轴会更有坐标感：2026 年 4 月的综述给出三代范式，prompt engineering（2022–2024）之后是 context engineering（2025），再往后进入 harness engineering（2026），JIT-Agent 正落在第三代的中段。

这个主张要打几分折扣？把有原文支撑的自我设限摊开看。第一，论文在 §3 承认协议刻意比 Codex、Claude Code 那类生产 runtime 薄，能证明“紧凑外壳也有效”，但不等于覆盖它们的完整能力。第二，Stage II 只能修 1–2 步（论文将其限定为 K*≤2 的短程修补）；对彻底不可行的需求无能为力、需要更长程的规划，是从方法描述可以推断的。第三，训练与档案库维护都烧算力、所有结论都发生在协议能表达的范围内——这两点论文没有明说，同样是从方法描述可以推断的 JIT-Agent。作者还承认，“整套脚手架现场重建”不一定是生产 runtime 的最终形态，更可能是稳定内核加选择性可替换模块，JIT 与 AOT 两种优化路线共存。

工程上论文把底牌都亮了出来。GitHub 仓库以 MIT 协议开放代码，HuggingFace 上的 jit-27b 权重是 Apache-2.0，基座是开源的 Qwen3.6-27B。有一个细节值得想复现的人注意：论文表 2 写了 13 个种子 harness，仓库 README 实际只实装了 11 个，差异尚未收口，动手时以仓库为准。配套的 jit-meta-harness 数据集公开了 2852 条训练样本，每条都是一个任务配一套四模块加 YAML 的脚手架。模型卡还透露，公开的 jit-27b 是从最终研究 checkpoint 蒸馏出来的，不是训练末态本身。跑服务时 README 还有两条硬提醒：serving 上下文要拉到 163840 tokens，否则参考块会被截断；不要用 --reasoning-parser qwen3，它会把生成代码里像 re.sub 这样的表达式误判进 reasoning_content 直接丢掉。这些细节恰好印证了“生成”真的是在写代码，而不只是吐一段 prompt JIT 仓库。

换更大的模型是贵的，换一层壳是便宜的。JIT-Agent 证明的是一件事：模型之外还存在一条可训练、可迁移、可复利的能力轴，而今天它终于可以被直接训练出来。它最终会以什么形态进生产，是现场重建整套脚手架，还是作为稳定内核上的可替换模块，论文留下了一个诚实的问号。但方向已经很清楚了：别再只盯着买更大的模型，那层壳，本身就值不可忽视的差距。

想深入可以读原文：JIT-Agent: Scaling Harness Intelligence via Just-in-Time Harness Evolution — arXiv:2608.25593

参考文献

JIT-Agent：自动生成 Agent 外壳的模型，换壳胜过换模型