最近在做 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 一次任务请求的完整流程一个典型请求会经历下面这些步骤用户发送任务接入层完成身份认证和参数校验。系统加载用户上下文、全局配置和可用工具列表。规划模型根据工具列表生成 JSON 格式执行计划计划中包含步骤、工具名、参数和依赖关系。执行层校验计划检查工具是否存在、参数是否符合 Schema、步骤数是否超限。执行工具收集每一步结果。如果某一步失败规划模型根据错误信息重新生成修复计划。所有步骤完成后生成最终答案返回给用户。这里最关键的是第 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_URLhttps://api.example.com/v1如果你的模型服务不需要 base_url可以保持默认值。注意不要把 API Key 写进代码仓库建议放在环境变量或密钥管理平台中。5. 从零实现一个轻量级 JIT-Agent5.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_factorydict) max_steps: int 5 dataclass class AgentPlan: reasoning: str steps: list[dict[str, Any]] model: strparameters字段建议使用 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_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) def chat_json(system_prompt: str, user_prompt: str, model: str gpt-4o-mini) - str: response client.chat.completions.create( modelmodel, temperature0.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(ftool 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, modeeval))) def text_length(text: str) - dict[str, int]: 统计文本长度和单词数。 return { chars: len(text), words: len(text.split()), } calculator_spec ToolSpec( namecalculator, description计算简单数学表达式例如 (1 2) * 3, parameters{ type: object, properties: { expression: { type: string, description: 要计算的数学表达式, } }, required: [expression], }, functioncalculator, ) text_length_spec ToolSpec( nametext_length, description统计一段文本的字符数和单词数, parameters{ type: object, properties: { text: { type: string, description: 要统计的文本, } }, required: [text], }, functiontext_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_asciiFalse) system_prompt PLANNER_SYSTEM_PROMPT.format( toolstools_json, max_stepsmax_steps, ) result_text chat_json( system_promptsystem_prompt, user_prompttask, ) 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], start1): 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(modelgpt-4o-mini) request AgentRequest( task帮我计算 (12 34) * 5 的结果并且统计这句话的字符数JIT Agent Demo, max_steps3, ) 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(modelgpt-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 的过程中下面这些问题出现频率较高。这里以表格形式整理方便按图索骥排查。问题现象常见原因解决思路模型输出的 JSON 无法解析模型返回了多余文本或 JSON 格式不规范在提示词中强调 JSON使用response_format增加解析失败重试逻辑计划中的工具名不存在模型从上下文幻觉出了不存在的工具在规划器提示词中明确要求只能使用工具列表中的工具执行前校验工具名Agent 陷入无限循环规划器不断生成重复步骤没有终止条件在框架层面限制最大步骤数并做步骤去重检测工具参数不符合预期模型生成的参数类型不对或缺少必填字段引入 JSON Schema 参数校验校验失败时让模型参考错误信息重新生成模型调用超时任务复杂、模型响应慢或网络不稳定设置合理超时时间引入重试策略复杂任务改为异步执行多个工具调用结果无法传递执行器只是顺序执行没有做步骤间数据传递增加结果引用机制例如{步骤名.result}模板替换上下文窗口溢出工具结果过多或历史消息过长对工具结果做截断摘要只保留关键内容线上行为不可控缺少日志和追踪无法定位模型决策过程记录每次规划的完整输入输出、工具调用参数和错误信息这些问题的根源大多不是模型不够聪明而是工程约束不够强。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 能力做得很重先用最小版本跑通“工具注册 动态规划 执行追踪”闭环再逐步增加人工审批、多模型路由和自动化评测。这样既能控制风险也能让团队更快理解动态生成智能体的价值。