JIT-Agent：让 AI 为每个任务动态生成专属 Agent 架构 · 干货攻略

• 链接:https://x.com/omarsar0/status/2093056965568332236
• 分类:x-tips
• 来源:X @omarsar0
• 作者:Jay
• 更新:2026-09-25
• 仓库:bingreeky/JIT

这是什么

JIT-Agent（arXiv:2608.25593）是一个任务时动态生成 Agent 架构的研究系统。与其给所有任务预配置一套固定的 Agent 框架，JIT-Agent 用一个 27B 的元模型（meta-model）在看到任务时才生成专属 harness——包含 memory（记忆）、planning（规划）、action（执行）、capability（工具编排）四个模块的完整 Python 代码。

核验来源：arXiv:2608.25593 · GitHub README (bingreeky/JIT) · Starlog 技术解读 · HuggingFace Paper Page

为什么值得关注

谁在推

@omarsar0（Mohamed_bin_Rekaya）在 X 上分享了这篇论文，指出 JIT Harness 是 Agent 架构设计的新方向。论文作者来自多家机构（见 arXiv 作者列表），代码已在 GitHub 开源（bingreeky/JIT）。

解决什么问题

当前 Agent 框架的最大局限：架构是预先固定的。ReAct 循环适合简单任务，但深度研究任务需要分层规划 + 长期记忆；代码执行任务需要紧凑的行动循环；旅行预订任务需要多步状态机。这些不同的需求被强制塞进同一套框架，导致某个任务"受限于最差的那个设计决策"。

JIT-Agent 的核心洞察：与其争论哪个固定架构更好，不如让模型自己为每个任务生成最合适的架构。

核心概念：Model-as-a-Harness

传统模式：选定模型 + 套用固定框架（如 LangGraph / AutoGen / CrewAI）

JIT-Agent 模式：

1. Meta-model（27B JIT-27B 或 GPT-4）：拿到任务描述 + 工具注册表 + 历史 harness 存档 → 生成特定任务的 harness Python 代码
2. Execution model（可以是 7B 等小模型）：执行生成的 harness 内的 Agent 循环
3. Judge model：评估输出质量，给出反馈

关键是分离生成与执行：执行模型既不写 harness、也看不到生成的代码，彻底解耦。

核验过程

交叉验证注意：OpenTrain AI 摘要 对 benchmark 证据评级为"limited"（低置信度），提示具体数字需谨慎对待。攻略正文对性能数字做保守描述。

上手步骤

环境准备

# 1. 克隆仓库
git clone https://github.com/bingreeky/JIT.git
cd JIT

# 2. 创建环境
conda env create -f environment.yml && conda activate jit
# 或直接 pip install
pip install -r requirements.txt

# 3. 配置凭证
cp .env.example .env
# 填写以下环境变量（按角色）：
# EXEC_MODEL / OPENAI_API_KEY  → 执行模型
# JUDGE_MODEL                   → 评判模型
# META_MODEL / META_API_KEY    → 元模型（JIT-27B 或 OpenAI）

.env 配置说明（来源：GitHub README）：

运行模式

模式 1：测试固定 HarnessFactory 设计（不用元模型，直接测手工设计）

# 列出可用 harness
python -m scripts.run_seed_harness --bench xbench --list-harnesses

# 运行指定 seed harness
python -m scripts.run_seed_harness --bench xbench --harness <name>

模式 2：使用托管 API 作为元 agent（最常用的方式）

# 需要在 .env 中配置 EXEC_MODEL、JUDGE_MODEL、META_MODEL
python -m scripts.run_jit --bench xbench

模式 3：本地评估 JIT-27B 检查点

# 启动本地元模型服务（vLLM / SGLang）
bash serve_meta_model.sh
# 然后运行 JIT 流水线
python -m scripts.run_jit --bench xbench --meta-model local

下载评测数据

# 检查数据集状态
python scripts/check_datasets.py

# 下载指定 benchmark（约 1GB）
bash scripts/fetch_datasets.sh travel
# 或下载全部
bash scripts/fetch_datasets.sh all

核心目录结构（来源：GitHub README）

bingreeky/JIT/
├── jit/               # 元 agent：生成/修复 prompt、best-of-N 选择
├── scripts/           # agent 内核、工具、模型、评测引擎、两个 runner
├── harness_factory/   # 手工 harness 实现及设计文档
├── benchmark/         # 每个 benchmark 的适配器、配置和评估器
└── dataset/          # benchmark 数据本身

核心机制：HarnessFactory 四模块协议

JIT-Agent 将所有 harness 分解为四个标准化模块（来源：Starlog + GitHub harness_factory）：

class HarnessFactory:
    def create_memory(self) -> Memory:
        """记忆系统：对话历史、事实、上下文"""
        pass

    def create_planner(self, memory: Memory) -> Planner:
        """规划策略：分层、反应式、无规划"""
        pass

    def create_action_executor(self) -> ActionExecutor:
        """工具/API 执行逻辑"""
        pass

    def create_orchestrator(self, memory, planner, executor) -> Orchestrator:
        """协调上述三者的主循环"""
        pass

研究任务的生成示例（来源：Starlog）：

class ResearchHarness(HarnessFactory):
    def create_memory(self):
        return HierarchicalMemory(
            short_term_capacity=10,
            long_term_indexer="semantic"
        )
    def create_planner(self, memory):
        return HierarchicalPlanner(
            decomposition_depth=3,
            memory=memory
        )
    def create_orchestrator(self, memory, planner, executor):
        return PlanExecuteOrchestrator(
            planning_threshold=5,
            memory=memory, planner=planner, executor=executor
        )

代码执行任务的生成示例（同一元模型生成，完全不同的架构）：

class CodeExecHarness(HarnessFactory):
    def create_memory(self):
        return BufferMemory(capacity=3)  # 最小化记忆
    def create_planner(self, memory):
        return NullPlanner()  # 无规划，ReAct 直觉式
    def create_orchestrator(self, memory, planner, executor):
        return ReActOrchestrator(
            max_iterations=10,
            memory=memory, executor=executor
        )

Harness 优选策略

元模型生成 N 个候选 harness（JIT-27B 默认 N=3~5），支持两种优选方式（来源：Starlog）：

1. Judge-based：LLM 评判每个候选与任务的匹配度——精确但昂贵
2. Log-probability：用元模型生成代码时的 token 级别置信度作为质量信号——更便宜，且不需要额外 judge 调用

Test-Time 演进

Harness 档案随运行累积。成功的 harness 模式被记住；当某 harness 失败，JIT-Agent 会修复并重新生成，且元模型本身保持冻结——演进发生在任务端，而不是重训模型。

坑与适用边界

适用场景 ✅

• 异构任务批量处理：一个流水线覆盖研究型 / 编码型 / 操作型任务，每个任务自动获得专属架构
• 小模型跑大任务：执行模型可以仅 7B，元模型（27B JIT-27B）负责架构设计，两阶段分离
• 快速探索最优 Agent 架构：不需要手工试错，元模型直接探索 harness 设计空间
• 多模型家族一致性优化：DeepSeek V4、Mimo-V2.5、Qwen3.6 等多规模模型均可受益（据论文）

不适用场景 ⚠️

• 实时性要求极高：元模型生成 harness 有额外延迟（需要生成 + 编译 Python 代码）
• 无代码执行环境：生成的 harness 是 Python 代码，需要可执行的 Python 环境
• 仅需简单任务：对于简单问答类任务，固定 ReAct 循环已经足够，动态生成反而是过度工程
• 需要训练复现：GitHub 仅发布推理 checkpoint 和代码，无训练流程（来源：Starlog），无法自行训练 JIT-Agent

已知局限

1. Benchmark 数字需谨慎对待：OpenTrain AI 对论文性能数字评级为"有限证据"（low grounding），建议自行跑 benchmark 验证
2. 工具生态依赖：需要配置 SERPER_API_KEY、JINA_API_KEY 等工具凭证，无工具时能力受限
3. 多模型调用成本：一次任务至少涉及元模型 + 执行模型 + Judge 三个模型的调用，成本高于单模型方案

一句话结论

JIT-Agent 证明了一个新方向：Agent 智能 = 模型权重 + Harness 架构，且 Harness 本身可以被学习和演进——既不需要重训模型，也不需要手工设计最优架构，但目前仅发布推理代码，benchmark 数字需自行验证。