JIT-Agent：动态生成智能体框架，让大模型自主规划工具与执行路径

最近在做 Agent 类项目时，我越来越明显感受到一个痛点：很多团队把智能体流程写成了“流水线死代码”。任务进来后，先调用哪个模型、使用哪些工具、按什么顺序执行，几乎全部在代码里固定死。一旦业务需求变化，就要改代码、发版、重新部署。更麻烦的是，大模型本身具备很强的推理能力，却被我们用成了“带搜索的聊天机器人”。真正理想的智能体，应该能根据当前任务动态决定自己的行为路径，也就是这里要讨论的 JIT-Agent：动态生成智能体框架的模型。

本文会先解释 JIT-Agent 的核心概念，再给出一个完整的轻量级实现，包含动态规划、工具装配、调度执行三大模块。最后会讨论如何把这类能力接入真实项目，以及工程落地时最容易被忽略的安全、成本和可观测性问题。如果你想做企业级 Agent 平台，或者正在研究 AutoGPT、LangGraph、自定义智能体框架，这篇文章应该能提供一条清晰可行的技术路径。

1. 为什么需要 JIT-Agent：静态智能体的瓶颈

1.1 从固定流程到动态编排

传统软件开发中，业务流程可以用 BPMN 流程图或状态机明确表达，因为业务流程通常是确定的。例如“订单创建 -> 支付 -> 发货 -> 完成”，这些步骤之间的先后关系稳定，异常分支也有限。这种场景用硬编码流程是合理的，代码可读性强、测试也容易做。

但 Agent 应用不一样。用户输入是开放的，任务类型不可穷举。比如同样一句话“帮我查一下这个月的销售数据并生成报表”，有时候用户希望只查数据，有时候希望把数据发到钉钉群，有时候希望顺便做一次环比分析。如果 Agent 的行为路径在代码中写死，那么每增加一种用户意图，就要增加一段分支判断。这种硬编码方式的维护成本会快速上升，且很难覆盖所有边界场景。

动态编排的意思是：Agent 拿到任务后，先让大模型充当“规划器”，根据任务内容和当前可用工具动态生成执行计划。计划中的每一步调用哪个工具、传什么参数、如何处理上一步结果，都由模型在运行时决定。这样，Agent 的行为不再是程序静态定义的，而是根据输入动态生成的。

1.2 JIT-Agent 到底解决什么问题

JIT 是 Just-In-Time 的缩写，含义是“即时生成”。这个概念在编程语言编译领域很常见，例如 JIT 编译是指程序运行时才把字节码编译成机器码。借用这个思路，JIT-Agent 的意思是：Agent 的框架结构、工具装配方案、甚至模型选择策略，都在请求到达时即时生成。

它解决的核心问题有三类。

第一类问题是组合爆炸。可用工具数量变多之后，如果靠硬编码组合工具，工具之间的组合方式会指数增长。动态生成方案让模型根据任务从工具库中挑选最合适的工具，不需要人预先穷举组合路径。

第二类问题是需求变化快。业务方经常会在上线后提出“再加一个指令”“能不能把结果格式改成 JSON”。如果 Agent 的计划是动态生成的，新增工具后只需要注册工具描述，模型便有可能在新请求中自动使用它，无需重写主流程。

第三类问题是模型能力浪费。大模型最擅长的是理解意图、拆解任务、判断条件，如果代码把每一步写死，模型只负责其中很小的片段，发挥不了推理优势。JIT-Agent 把模型放到决策中心位置，让模型真正负责“想怎么做”，框架只负责“提供能力和兜底”。

1.3 典型应用场景

JIT-Agent 适合任务开放、工具较多、需要灵活编排的场景。比较典型的包括：

• 智能运维助手：用户输入“帮我查一下服务器负载，如果超过 80% 就重启应用”，Agent 动态调用监控工具、告警工具、运维执行工具。
• 数据分析助手：用户输入“分析订单表并生成周报”，Agent 动态选择 SQL 查询、数据清洗、图表生成、报告导出等工具。
• 办公自动化机器人：用户输入“把今天所有未读邮件里的附件下载下来，并汇总成清单”，Agent 动态调用邮件读取、附件解析、表格写入等工具。
• 客服工单处理：根据工单内容动态选择知识库检索、客户画像查询、退款审批等能力。

这些场景的共同点是：用户意图在请求前不可枚举，工具集合却在持续增加。JIT-Agent 的架构能很好适应这种“意图开放、工具固定”的局面。

2. 理解 JIT-Agent 的核心概念

2.1 JIT 与动态生成在 Agent 中的含义

JIT 在这里不是指某个具体框架，而是一种设计思想。它强调的是“运行时决策”，而不是“编译期决策”。你可以从三个层面理解动态生成：

第一个层面是 Prompt 动态生成。系统不会使用一份固定不变的系统提示词，而是根据任务描述、用户身份、可用工具列表、历史上下文，动态拼装出最合适的 Prompt。

第二个层面是工具链动态生成。小到一个步骤用哪个工具，大到整条执行链路，都由模型在运行过程中生成。工具注册表提供候选能力，模型负责选择与组合。

第三个层面是模型路由动态生成。不同任务适合不同模型：简单分类任务用轻量模型，复杂推理任务用重型模型，JSON 抽取任务用带结构化输出能力的模型。模型路由策略可以根据任务特征动态决定，也可以由规划器直接指定。

这三个层面合在一起，才叫完整的 JIT-Agent。只做到 Prompt 动态拼接，本质上还是静态流程；只有工具链路也能动态生成，才算真正把“即时生成”落到执行层。

2.2 智能体框架与模型

很多人容易把智能体框架和大模型混在一起说。实际上，智能体框架是承载“感知-决策-行动”循环的软件结构，而大模型是决策环节中的推理引擎。JIT-Agent 的模型，可以拆成两层含义：

一层是“规划模型”。它负责把用户任务拆解成可执行步骤，输出结构化计划。这个模型需要较强的指令跟随能力和 JSON 输出能力。

另一层是“执行模型”。它在每个步骤中处理具体细节，例如生成 SQL、生成回复文案、总结文档。执行模型可以很轻量，也可以和规划模型是同一个模型。

在真正的 JIT-Agent 架构中，模型本身也被当作一种可动态选择的资源。简单任务不要总调用最强模型，复杂任务也不要让弱模型强行上阵。通过模型路由，可以在效果和成本之间取得平衡。

2.3 JIT-Agent 与 RAG、AutoGPT 的区别

RAG 解决的是“模型不知道的知识从哪来”的问题，核心是检索外部知识库并注入上下文。JIT-Agent 解决的是“任务该怎么做”的问题，核心是动态生成执行计划。两者可以同时存在：Agent 在规划时可能调用检索工具，再基于检索结果继续决策。

AutoGPT 这类项目是 JIT-Agent 思想的早期实践。它让模型不断生成下一步动作，但实现方式比较粗放：没有严格的计划校验、没有工具参数校验、容易进入死循环。JIT-Agent 可以理解为 AutoGPT 思想的工程化版本，重点在于把动态生成过程做成可控、可观测、可回滚的框架。

更严格地说，JIT-Agent 更像一个“生成 Agent 的 Agent”。第一层模型生成临时执行策略，第二层框架把策略解释为真实工具调用，第三层再根据执行结果判断是否继续。这种分层思想，是它与普通多轮对话助手的本质区别。

3. 整体架构与工作流程

3.1 五层架构

一个通用 JIT-Agent 框架，可以分成五层：接入层、规划层、工具层、执行层、治理层。

接入层负责接收用户请求，做权限校验、上下文准备和任务预处理。规划层是核心，它通过规划模型把用户任务转成结构化执行计划。工具层维护所有可用工具的元信息，包括工具名称、描述、参数 JSON Schema。执行层负责按计划调用工具，并把结果回传给规划层。治理层贯穿始终，负责日志、追踪、限流、降级和审计。

这种分层的好处是每层职责单一。规划模型不需要知道工具内部实现，工具层不需要关心任务如何拆解，治理层可以在不影响主链路的情况下补充可观测性能力。

3.2 一次任务请求的完整流程

一个典型请求会经历下面这些步骤：

1. 用户发送任务，接入层完成身份认证和参数校验。
2. 系统加载用户上下文、全局配置和可用工具列表。
3. 规划模型根据工具列表生成 JSON 格式执行计划，计划中包含步骤、工具名、参数和依赖关系。
4. 执行层校验计划，检查工具是否存在、参数是否符合 Schema、步骤数是否超限。
5. 执行工具，收集每一步结果。
6. 如果某一步失败，规划模型根据错误信息重新生成修复计划。
7. 所有步骤完成后，生成最终答案返回给用户。

这里最关键的是第 3 步和第 6 步，它们都体现了“动态生成”的特性：计划不是预先写死的，而是由模型针对每个具体请求实时生成的。

3.3 动态生成的内容边界

动态生成不等于无限自由。工程上必须给模型划定边界，否则会出现不可控行为。建议从三个方面限制：

• 步骤数量限制：例如单次任务最多 5 步，超过后强制终止。
• 工具白名单：模型只能从注册表中选择工具，不能凭空指定工具名。
• 参数严格校验：所有工具参数必须符合 JSON Schema，防止模型生成非法参数导致系统异常。

边界不是限制模型能力，而是让动态生成在可控范围内发生。模型在边界内自由组合，系统在边界外提供安全兜底，这是 JIT-Agent 工程化的关键。

4. 环境准备与工程结构

4.1 开发环境

本文示例使用 Python 3.9 以上版本，操作系统可选用 Windows、macOS 或 Linux。示例代码依赖 OpenAI 官方 Python SDK 来调用大模型接口。如果你的模型服务来自其他厂商，只要它兼容 OpenAI 的 Chat Completion 协议，也可以通过 base_url 方式接入。当前很多本地部署框架也提供 OpenAI 兼容接口，因此这套代码具备较好的通用性。

版本方面，Python 的依赖版本迭代很快，这里不固定具体版本号。安装时优先使用最新稳定版即可。如果项目中有冲突，建议用虚拟环境隔离。

4.2 项目目录

为了便于理解，我们采用一个非常清晰的小型项目结构。实际项目中，你可以在该结构基础上继续拆分模块。

jit-agent-demo/ ├── agent.py # Agent 管理入口 ├── llm.py # 模型调用封装 ├── planner.py # 动态规划器 ├── executor.py # 执行器 ├── registry.py # 工具注册表 ├── models.py # 数据模型 ├── tools/ │ └── demo_tools.py # 示例工具 ├── app.py # FastAPI 服务入口 └── requirements.txt

这个结构把模型、规划、执行、工具分离，每一部分都可以单独测试和替换。

4.3 依赖安装

创建一个虚拟环境并安装依赖：

python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install openai fastapi uvicorn pydantic

安装完成后，配置环境变量。至少需要配置大模型服务的 API Key 和接口地址：

export OPENAI_API_KEY="你的API Key" export OPENAI_BASE_URL="https://api.example.com/v1"

如果你的模型服务不需要 base_url，可以保持默认值。注意不要把 API Key 写进代码仓库，建议放在环境变量或密钥管理平台中。

5. 从零实现一个轻量级 JIT-Agent

5.1 基础数据模型

先定义核心数据模型。ToolSpec描述工具的名称、描述、参数和实际函数；AgentRequest描述用户任务；AgentPlan描述模型生成的执行计划。

# models.py from __future__ import annotations from dataclasses import dataclass, field from typing import Any, Callable @dataclass class ToolSpec: name: str description: str parameters: dict[str, Any] function: Callable[..., Any] | None = None @dataclass class AgentRequest: task: str context: dict[str, Any] = field(default_factory=dict) max_steps: int = 5 @dataclass class AgentPlan: reasoning: str steps: list[dict[str, Any]] model: str

parameters字段建议使用 JSON Schema 格式，方便后续校验。这里为了演示保持简单，实际项目中推荐引入jsonschema库做参数校验。

5.2 模型调用层

llm.py封装模型调用。示例中使用response_format要求模型输出 JSON，这样后续可以直接用json.loads解析计划。注意，不是所有模型都支持response_format，如果你的模型不支持，可以删除该参数，并在提示词中更严格地要求 JSON 输出。

# llm.py import os from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL"), ) def chat_json(system_prompt: str, user_prompt: str, model: str = "gpt-4o-mini") -> str: response = client.chat.completions.create( model=model, temperature=0.2, response_format={"type": "json_object"}, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ], ) return response.choices[0].message.content

这段代码的model参数可以在调用时传入。实际项目中，应该把模型名放入配置中心或环境变量，不要硬编码在业务代码中。

5.3 工具注册表与动态技能装配

工具注册表是 JIT-Agent 的核心基础设施。所有能被 Agent 调用的工具，必须先注册到注册表中，这样规划模型才能通过工具描述了解系统能力。注册表本质上是一个字典，key 是工具名，value 是ToolSpec。

# registry.py from typing import Any from models import ToolSpec TOOL_REGISTRY: dict[str, ToolSpec] = {} def register_tool(spec: ToolSpec) -> ToolSpec: TOOL_REGISTRY[spec.name] = spec return spec def list_tools() -> list[dict[str, Any]]: return [ { "name": spec.name, "description": spec.description, "parameters": spec.parameters, } for spec in TOOL_REGISTRY.values() ] def execute_tool(name: str, **kwargs: Any) -> Any: spec = TOOL_REGISTRY.get(name) if spec is None or spec.function is None: raise KeyError(f"tool not found: {name}") return spec.function(**kwargs)

工具注册方式有很多种，装饰器是 Python 中比较优雅的一种。下面定义两个示例工具：一个计算器，一个文本长度统计工具。

# tools/demo_tools.py import ast import operator from registry import register_tool from models import ToolSpec def calculator(expression: str) -> str: """计算简单数学表达式，仅用于示例。""" allowed_operators = { ast.Add: operator.add, ast.Sub: operator.sub, ast.Mult: operator.mul, ast.Div: operator.truediv, } def eval_node(node): if isinstance(node, ast.Expression): return eval_node(node.body) if isinstance(node, ast.Constant): return node.value if isinstance(node, ast.BinOp): left = eval_node(node.left) right = eval_node(node.right) op = allowed_operators.get(type(node.op)) if op is None: raise ValueError("unsupported operator") return op(left, right) raise ValueError("unsupported expression") return str(eval_node(ast.parse(expression, mode="eval"))) def text_length(text: str) -> dict[str, int]: """统计文本长度和单词数。""" return { "chars": len(text), "words": len(text.split()), } calculator_spec = ToolSpec( name="calculator", description="计算简单数学表达式，例如 (1 + 2) * 3", parameters={ "type": "object", "properties": { "expression": { "type": "string", "description": "要计算的数学表达式", } }, "required": ["expression"], }, function=calculator, ) text_length_spec = ToolSpec( name="text_length", description="统计一段文本的字符数和单词数", parameters={ "type": "object", "properties": { "text": { "type": "string", "description": "要统计的文本", } }, "required": ["text"], }, function=text_length, ) register_tool(calculator_spec) register_tool(text_length_spec)

注意，不要直接使用eval执行用户输入，否则会产生代码注入风险。上面的示例用ast模块做了一个轻量安全限制，但仍然建议只在受控环境中使用。生产环境下的工具调用必须遵循最小权限原则，所有外部工具都应经过鉴权、审计和参数校验。

tools/demo_tools.py被导入后，工具才会注册到注册表中。因此在主入口中你需要确保import tools.demo_tools被执行。

5.4 Planner 动态生成执行计划

Planner 是整个 JIT-Agent 的大脑。它负责把任务描述和工具列表发送给模型，并让模型返回一个结构化执行计划。为了让模型稳定输出 JSON，我们在 system prompt 中明确要求格式。

# planner.py import json from llm import chat_json from registry import list_tools PLANNER_SYSTEM_PROMPT = """ 你是一个 JIT-Agent 规划器。你的任务是根据用户目标和可用工具，生成一个 JSON 格式的执行计划。 可用工具如下： {tools} 输出格式必须为： {{ "reasoning": "你选择这些步骤的简短理由", "steps": [ {{ "tool": "工具名", "arguments": {{"参数名": "参数值"}}, "description": "这一步在做什么" }} ] }} 要求： 1. 计划必须只使用可用工具列表中的工具。 2. 步骤数量不要超过 {max_steps} 步。 3. 不要编造工具名。 4. 如果任务无法用可用工具完成，在 reasoning 中说明原因，steps 返回空列表。 """ def generate_plan(task: str, max_steps: int = 5) -> dict: tools_json = json.dumps(list_tools(), ensure_ascii=False) system_prompt = PLANNER_SYSTEM_PROMPT.format( tools=tools_json, max_steps=max_steps, ) result_text = chat_json( system_prompt=system_prompt, user_prompt=task, ) result = json.loads(result_text) if len(result.get("steps", [])) > max_steps: raise ValueError("plan steps exceed max_steps") return result

这段代码把“使用哪些工具”完全交给模型决策。由于工具列表是通过list_tools()动态获取的，所以只要新增工具并更新时间描述，模型就能在后续请求中感知到。

5.5 Agent 管理器与调度入口

agent.py将规划器和执行器组合起来。JITAgent是对外暴露的统一入口，它接收AgentRequest，生成计划，然后逐步执行工具调用、收集结果。

# agent.py from models import AgentRequest, AgentPlan from planner import generate_plan from registry import execute_tool class JITAgent: def __init__(self, model: str = "gpt-4o-mini"): self.model = model def run(self, request: AgentRequest) -> dict: plan = generate_plan(request.task, request.max_steps) steps = plan.get("steps", []) results = [] for index, step in enumerate(steps[: request.max_steps], start=1): tool_name = step["tool"] arguments = step.get("arguments", {}) try: step_result = execute_tool(tool_name, **arguments) status = "success" except Exception as exc: step_result = {"error": str(exc)} status = "failed" results.append( { "step_index": index, "description": step.get("description", ""), "tool": tool_name, "status": status, "result": step_result, } ) return { "task": request.task, "reasoning": plan.get("reasoning", ""), "model": self.model, "results": results, }

为了演示，这里的执行逻辑是“全部步骤顺序执行”。真实项目中，你还需要考虑步骤之间的数据传递。比如上一步的输出可能是下一步的输入，这可以在arguments中用特殊语法引用，例如"{step1.result}"，在执行前做一次模板替换。这个功能可以扩展，也是 JIT-Agent 从玩具走向生产的关键。

5.6 运行演示与输出

创建项目主入口main.py，导入工具模块并运行一次 Agent 请求：

# main.py import tools.demo_tools # noqa: F401 确保工具注册 from models import AgentRequest from agent import JITAgent def main(): agent = JITAgent(model="gpt-4o-mini") request = AgentRequest( task="帮我计算 (12 + 34) * 5 的结果，并且统计这句话的字符数：JIT Agent Demo", max_steps=3, ) response = agent.run(request) print(response) if __name__ == "__main__": main()

运行方式：

python main.py

预期输出大致如下。由于模型输出有随机性，具体内容可能不同，但结构应该类似：

{ "task": "帮我计算 (12 + 34) * 5 的结果，并且统计这句话的字符数：JIT Agent Demo", "reasoning": "任务包含计算和文本统计，分别调用 calculator 和 text_length 工具", "model": "gpt-4o-mini", "results": [ { "step_index": 1, "description": "计算数学表达式", "tool": "calculator", "status": "success", "result": "230" }, { "step_index": 2, "description": "统计文本长度", "tool": "text_length", "status": "success", "result": { "chars": 18, "words": 3 } } ] }

到这里，一个轻量级 JIT-Agent 已经可以跑起来了。它没有写死任何业务分支，完全由模型根据任务动态决定工具调用顺序。这就是 JIT 思想在 Agent 中的最小落地。

6. 将 JIT-Agent 接入真实项目的三种方式

6.1 作为异步任务引擎

很多真实场景不适合同步请求。例如 Agent 要执行 SQL 查询、发邮件、触发工作流，整个过程可能需要几十秒甚至几分钟。这时候应该把JITAgent.run()放到异步任务队列中，比如 Celery、RQ 或消息队列消费者。

异步化的好处是可以更好地控制并发和重试。任务提交后立即返回任务 ID，前端通过轮询或 WebSocket 获取执行状态。执行状态建议持久化到数据库，方便随时查看 Agent 每一步执行过程。

6.2 通过 FastAPI 暴露 HTTP 接口

如果你希望把 JIT-Agent 封装成内部服务，FastAPI 是一个很轻量的选择。下面代码将JITAgent包装为 HTTP 接口。

# app.py from fastapi import FastAPI from pydantic import BaseModel import tools.demo_tools # noqa: F401 from agent import JITAgent app = FastAPI() agent = JITAgent(model="gpt-4o-mini") class TaskBody(BaseModel): task: str max_steps: int = 5 @app.post("/agent/run") def run_agent(body: TaskBody): return agent.run(body) @app.get("/health") def health(): return {"status": "ok"}

启动服务：

uvicorn app:app --host 0.0.0.0 --port 8000

然后可以用curl测试：

curl -X POST http://localhost:8000/agent/run \ -H "Content-Type: application/json" \ -d '{"task": "计算 2 + 3 * 4", "max_steps": 3}'

这个接口适合作为团队内部 Agent 平台的基础服务。后续可以在此基础上补充鉴权、限流和审计日志。

6.3 接入 LangChain 生态的通用思路

LangChain 生态提供了大量现成工具和模型封装。你可以把 JIT-Agent 的动态规划能力，与 LangChain 的 Tool 抽象结合起来。思路是：把 LangChain 的Tool列表转换成自己的ToolSpec，注册到注册表中；然后用 LangChain 的模型封装替换掉llm.py中的chat_json。

这样做的目的不是重新发明轮子，而是保留 JIT 的动态决策灵活性，同时复用 LangChain 社区提供的文档加载、向量检索、API 调用等工具。框架选型不重要，重要的是“工具能力”和“决策逻辑”解耦。只要工具层能稳定提供描述和调用入口，Planner 可以随时替换成更强的模型或更复杂的规划算法。

7. 常见问题与排查思路

在实际实现和部署 JIT-Agent 的过程中，下面这些问题出现频率较高。这里以表格形式整理，方便按图索骥排查。

这些问题的根源大多不是模型不够聪明，而是工程约束不够强。JIT-Agent 的“动态”需要靠“强约束”来兜底：步骤上限、工具白名单、参数校验、重试策略，缺一不可。

8. 最佳实践与工程建议

8.1 提示词与上下文管理

规划器的提示词是决定 Agent 质量的关键。建议把工具描述写得具体且带有示例，模型在决定工具时会更准确。描述应该说明工具能做什么、不能做什么、参数格式是什么。工具列表也建议按类型分组，而不是全部平铺，这能减少模型在大量工具中选错的概率。

上下文管理要特别注意。Agent 每一步执行结果如果全部塞入下一轮模型调用，很快会撑爆上下文窗口。更稳妥的做法是：对工具结果做摘要、只保留与最终目标相关的字段，并在多轮规划中丢弃中间过程详情。

8.2 工具调用安全

这是 JIT-Agent 上线前必须完成的一步。工具权限要遵循最小权限原则：一个工具只具备完成其职责所需的最小权限，不要给 Agent 一个可以执行任意命令的超级工具。涉及数据库、文件系统、支付、发布等敏感操作，必须经过二次确认或人工审批流程。

对于内部系统调用，建议增加用户维度鉴权。每个 Agent 请求都携带用户身份，工具执行时校验当前用户是否有该操作权限。所有工具调用都要记录审计日志，包括调用人、调用参数、返回结果和耗时。只记录“谁调用了哪个工具”还不够，还要记录为什么调用，也就是把规划器的 reasoning 一并保存。

8.3 日志、追踪与可观测性

分布式追踪对 Agent 应用尤为重要。一次请求可能经历模型调用、工具调用、数据库读写等多个环节，任何一个环节变慢都会影响整体体验。建议为每次请求生成一个trace_id，贯穿接入层、规划层、执行层。日志中至少包含：

• 用户任务原文。
• 规划器输出的计划 JSON。
• 每个工具的入参和出参。
• 每一步耗时和状态。
• 最终返回结果。

有了这些日志，问题排查会容易很多。否则模型产生的决策是不可控的，你很难从外部判断它是“想错了”还是“执行错了”。

8.4 成本与性能优化

JIT-Agent 的成本比固定流程 Agent 更高，因为规划过程本身也是一次模型调用。优化成本可以从几个方向入手：

• 先用分类模型判断任务是否需要复杂规划，简单任务直接走快捷通道。
• 工具结果缓存命中后，避免重复调用相同工具。
• 模型路由分级，简单任务用轻量模型，只有困难任务才用大模型。
• 规划器在执行阶段不要每次重新生成完整计划，尽量复用之前相似的规划模板。

性能方面，模型调用通常是最大瓶颈。建议给规划器和工具调用分别设置超时时间，并把超时时间设置为可配置项。对于耗时较长的工具，应该把它设计为异步任务，而不是阻塞整个 Agent 流程。

8.5 模型选型与迭代

JIT-Agent 的规划质量高度依赖模型能力。规划模型的输出稳定性比“聪明程度”更重要。建议选择 JSON 输出能力强、指令跟随稳定的模型。你可以用一个测试集持续评估规划器效果，例如准备 100 条典型任务，检查模型生成的计划是否合理、工具名是否有效、参数是否正确。

模型迭代时不要只换模型版本，还要重新跑测试集。很多看起来更强大的模型，在严格 JSON 输出和工具调用格式上反而不如专用模型稳定。评估数据是 Agent 工程中最值得沉淀的资产。

9. 总结与下一步

从静态流程走向动态生成，是 Agent 应用从“演示”走向“生产”的关键一步。JIT-Agent 的核心不强在某个算法，也不强在某个框架，而在于用运行时生成的方式替代编译期写死的分支。本文通过一个轻量级实现演示了最小闭环：工具注册、模型规划、计划执行三个模块互相配合，就已经能完成非常灵活的任务编排。

下一步你可以尝试在现有实现上增加三个能力。第一是步骤间结果传递，让后一步可以引用前一步结果。第二是失败自动修复，工具调用出错后把错误信息反馈给规划器重新生成计划。第三是引入评估集，把典型任务沉淀成回归测试集，避免模型升级后行为退化。如果你正在做企业级 Agent 平台，建议先不要着急把 JIT 能力做得很重，先用最小版本跑通“工具注册 + 动态规划 + 执行追踪”闭环，再逐步增加人工审批、多模型路由和自动化评测。这样既能控制风险，也能让团队更快理解动态生成智能体的价值。