JIT-Agent：让 AI Agent 学会"量体裁衣"

场景切入：一个困扰行业已久的悖论

2026 年的 AI 工程师们，正在经历一场甜蜜的烦恼：大模型越来越强，但花大价钱升级到最新旗舰模型后，Agent 的实际表现却常常令人失望——同样的任务，上一版模型可能反而更靠谱。这究竟是模型的问题，还是 Agent 框架的瓶颈？

JIT-Agent 团队给出了一个出人意料的答案：问题可能既不在模型，也不在框架，而在两者之间那个"连接器"——Agent Harness（运行时支架）。 他们在 2026 年 8 月发表的论文（arXiv: 2608.25593）中，通过一系列控制变量实验证明：在 DeepSeek V4 这同一个后端模型上，换一个精心设计的 Harness，DeepSearchQA 得分直接提升 +9.1 分，超越了 GPT-5.6；而在 GLM-5.2 上，更是实现了惊人的 +20.2 分增幅。换 Harness 的收益，有时候比换模型更大。

背景：Harness 是什么，为什么它如此关键

要理解 JIT-Agent 的创新，先要理解一个常被忽视的概念——Agent Harness。

简单来说，Harness 是 AI Agent 的"执行骨架"，定义了四件事：Memory（记忆管理）——Agent 记住什么、忘记什么；Planning（规划策略）——如何分解任务、制定步骤；Action（行动协议）——调用哪些工具、遵循什么流程；Capability Orchestration（能力编排）——如何组织和使用各类技能。

传统方案要么预制一个"通用型"Harness（泛用但平庸），要么为每个任务手写专用 Harness（效果好但不可扩展）。JIT-Agent 的核心洞察是：Harness 其实是一种可以被机器学习学会的东西，而且学会之后，它的改进具有可迁移性和可组合性——这正是 AI 能力的核心特征。

类比：就像给厨师定制厨房

如果说 AI 模型是一流厨师，那么 Harness 就是厨房的布局和动线设计。同一个厨师，给他一个混乱的厨房（低质量 Harness），他的厨艺也难以施展；换一个布局合理的厨房（高质量 Harness），他就能发挥出真实水平。更重要的是：JIT-Agent 不仅仅是一个静态推荐工具，它是一个能够动态生成 + 即时修复 + 持续进化 Harness 的"AI 厨房设计师"——每次处理新任务，它都会根据任务特征实时生成最合适的厨房布局。

核心架构：JIT Pipeline 三阶段循环

JIT-Agent 的工作流程分为三个可恢复阶段：GENERATE（生成）、SELECT（选择）、EXECUTE（执行）。

在 GENERATE 阶段，Meta 模型（JIT-27B 或任意 OpenAI 兼容 API）根据任务描述，从零生成 N 个候选 Harness——每个都包含 memory.py、planning.py、action.py、tool_policy.py 四个文件以及对应的 prompt.yaml。生成过程还包含内置的修复（repair）机制：当候选 Harness 存在语法或逻辑错误时，Meta 模型会自我修正。

在 SELECT 阶段，模型从 N 个候选中选择最优的那个。JIT-Agent 支持两种选择器：logprob（基于模型完成 token 的累积对数概率，适合本地有 tokenizer 的场景）和 judge（让另一个模型打分，适合纯 API 调用场景）。

在 EXECUTE 阶段，选中的 Harness 由执行模型（可以是任意支持工具调用的模型）运行，最终由 Judge 模型评分。

JIT-Agent 还内置了 HarnessFactory——一个包含 11 种预制 Harness 的"武器库"，包括 linear ReAct、Plan-and-Execute、DAG 规划、AgentFold 上下文折叠、Generative Agent Memory 等经典和高级设计。这些既是基准参照，也在 --harness-refs 模式下作为 Meta 模型生成时的参考素材。

上手体验：研究工具的本来面目

必须坦诚地说：JIT-Agent 不是那种"下载即用"的项目。 它是一个严肃的学术研究框架，对使用者有明确的技术要求：

环境与依赖：Python 3.11，通过 conda env create -f environment.yml 创建环境，依赖列表中有 30+ 核心包（openai、pyyaml、jinja2、tiktoken、tenacity 等），以及可选的 faiss（向量检索）、sentence-transformers（密集检索）、python-docx/pptx（办公基准）等扩展。

多模型配置：JIT-Agent 严格区分四种模型角色——Meta 模型（生成 Harness）、Execution 模型（运行 Harness 的 Agent）、Judge 模型（打分）和 Selector 模型（选择 Harness）。每种都需要独立的 API 配置，至少需要 3 套 Key。

Benchmark 数据：内置支持 7 个基准测试（xbench、deepsearchqa、agentif、officebench、odyssey、shopping、travel），部分数据集需要运行 scripts/fetch_datasets.sh 单独下载。

本地部署注意事项：如果想使用 JIT-Agent-27B 作为 Meta 模型（而非第三方 API），需要自行用 vLLM/SGLang 部署模型，该步骤不在项目包内（项目刻意回避了硬件相关的模型服务部分）。

局限与挑战：这不是银弹

JIT-Agent 的设计思路优雅，但落地存在现实约束。

API 成本不可忽视：GENERATE 阶段每个 case 需要生成 N 个候选（默认 N=3），而 N 越多、Harness 越长，Meta 模型的 token 消耗就越大。论文报告平均节省 36% token，但这是相对于"不必要的大模型调用"而言的——绝对成本依然显著。

任务适配性边界：JIT-Agent 适合需要工具调用、网页搜索、文档操作的"结构化任务"，对于纯文本生成、开放域对话等场景，Harness 优化的边际收益较小。

复现门槛：目前项目仅公开了模型权重（jit-27b 在 HuggingFace 可下载），但训练代码、原始数据集和 SFT 数据尚未开源，这意味着研究社区难以独立复现训练流程，只能使用预训练结果。

代码质量与文档：部分子模块的文档较简略，如 jit/harness_ops.py 等核心文件依赖内联注释而非系统文档；脚本参数众多，新用户的学习曲线较陡。

行业意义：Harness Intelligence 的元年

JIT-Agent 的最深远意义，不在于它生成了哪些具体 Harness，而在于它正式提出了一个命题：Harness Intelligence（支架智能）是一个独立的、可训练的、可迁移的 AI 能力维度。

过去十年，AI 社区普遍关注模型规模（Scaling Laws）和数据质量的提升。JIT-Agent 证明：在模型能力既定的前提下，通过优化 Agent 与模型的交互接口，可以释放出相当可观的性能空间。这一思路正在被后续工作跟进——2026 年下半年，多个研究团队开始探索"Harness 作为可微调参数"的方向，而这股趋势，很可能就是下一个 AI Agent 能力跃迁的起点。

对于希望深入 AI Agent 研究或在自己的工作流中引入任务自适应 Harness 的开发者而言，JIT-Agent 是一个值得关注的技术起点——它或许还不能直接用于生产，但它的框架设计和实验结果，已经为这个方向点亮了第一盏灯。