如果你正在做 Agent 应用可能已经被这种问题卡住过任务稍微变一下就要改工具调用顺序甚至要重新设计整个流程。之前有个项目用户今天要“查资料并总结”明天要“查资料、对比价格再生成表格”后天又变成“先翻译再总结再发送到指定渠道”。用传统静态 Agent 框架做每改一次需求就要动代码、发版、重新测试。后来换了一种思路不把 Agent 流程写死让模型根据当前任务动态生成一套可执行的框架再交给执行器去跑。这个思路就是标题里说的 JIT-Agent动态生成智能体框架的模型。简单说JIT-Agent 不是一个已经打包好的开源工具也不存在哪个仓库 clone 下来就能直接用。它更像一套设计方法论通过模型在运行时生成 Agent 的子任务结构、工具调用顺序和数据流转方式然后由引擎执行这套生成结果。它适合正在做复杂 Agent 应用、任务流程经常变化、需要把工具调用编排自动化的开发者。这篇文章会把 JIT-Agent 的核心思路、实现前置条件、从单条流程到批量处理的落地步骤、常见报错排查和适用边界全部拆开讲一遍。下面按实际落地顺序来。1. 先搞清楚它要解决的是什么静态 Agent 框架的卡点在哪里1.1 静态框架为什么不够用大多数 Agent 应用在实现上其实还是“人写好的流程”。比如经典的查询型 Agent先判断意图再选工具再调用模型生成回答。如果业务路径不多这种静态结构完全够用。问题出在任务类型一多流程组合就会爆炸。假设你有五个工具搜索、网页阅读、翻译、表格生成、邮件发送。静态方案只能提前把“先搜索再阅读再总结”这种链路写进代码。用户如果临时需要“把结果翻译成英文再发邮件”就要新增一个分支。一次两次可以十次之后代码里全是 if-else、switch-case 和状态配置表。维护成本开始压过功能收益。JIT-Agent 的思路是反过来把“如何组织流程”这个决策交给模型。开发时不写死某一个任务链路而是注册一组工具、定义一组能力和约束然后让模型根据当前输入的复杂程度、目标和中间结果动态生成一个可执行的任务图。这个任务图再交给执行器去跑。1.2 JIT 在这里指什么JIT 来自编译领域的 Just-In-Time意思是“按需、在即将执行的时候才做”。放到 Agent 场景里动态生成的价值不是“启动快一点”而是流量和任务不固定时不至于每个请求都跑满整套流程。举个例子。用户 A 的问题很简单“今天北京天气怎么样”。这时动态生成器可以只生成一个节点调用天气工具返回结果。用户 B 的问题是“对比三款笔记本的参数整理成表格再用中文给个建议”。这时生成器需要生成多个节点搜索、解析、对比、生成表格、总结建议。静态框架为了兼容 B往往会让 A 也走一遍完整链路JIT-Agent 则根据任务动态调整生成结果简单任务生成轻量路径复杂任务生成完整路径。这带来一个额外优势执行链路是“刚刚生成的”你能通过日志看到模型认为应该先做什么、后做什么而不是只能看到一堆 if-else 的最终输出。对排查问题非常有用。1.3 和 LangChain、MetaGPT 这类框架的关系很多人在搜索时会纠结 JIT-Agent 和 LangChain 有什么区别。其实它们不在一个层面。LangChain 是基础设施提供工具调用、模型封装、记忆管理等组件MetaGPT 是多人协作式的 Agent 模拟框架。JIT-Agent 更接近一种编排策略你仍然可以用 LangChain 做底层工具调度用 OpenAI 或本地部署的大模型做决策但在流程组织层不再由人写死而是由模型动态生成。这也是为什么我不建议一开始就去搜“JIT-Agent 安装包”或者“JIT-Agent 源码”。你大概率找不到一个统一的仓库。更现实的做法是理解这套思路然后在自己的 Agent 项目里把“静态流程调度器”替换成“动态流程生成器”。下面几章就是围绕这个落地路径展开的。2. 动态生成智能体框架的前提能力注册、流程描述和运行环境动态生成不是让模型自由发挥而是在一个受控的边界里生成。这个边界需要提前设计好。如果什么约束都不给模型生成的流程可能包含不存在的工具、违反依赖关系、或者输出无法解析的格式。所以落地 JIT-Agent 的第一步不是写生成代码而是把“能被生成的世界”定义清楚。2.1 工具和能力注册模型能编排什么必须先明确什么在动态生成流程之前你需要有一份工具清单这份清单就是模型编排时的候选集合。每个工具建议至少包含以下字段工具名称比如web_search一句话描述说明这个工具解决什么问题输入参数用 JSON Schema 或简单字段列表描述输出格式是字符串、表格还是结构化 JSON执行方式是本地函数、HTTP 接口还是命令行脚本是否阻塞要不要等待外部系统返回工具描述的好坏直接影响生成结果质量。描述写得模糊模型就可能在调用时给错参数。例如search(query)描述成“搜索”模型可能传一个自然语言长句进去描述成“根据关键词搜索网页标题和摘要query 是字符串类型建议控制在 20 字以内”模型就会更规范地传参。这里我建议先做一个工具注册中心可以是简单的字典、JSON 文件也可以存到数据库里。重点不是技术选型而是让“工具信息”和“执行逻辑”分离。模型看到的是工具描述执行器调用的是真实函数两者通过工具名称关联。2.2 流程描述格式模型生成的东西必须能被机器解析动态生成的“框架”不可能是 Python 代码或自然语言必须是一种可校验、可执行的中间表示。常见做法有两种第一种是结构化 JSON描述节点列表和边列表。比如{ nodes: [ {id: n1, type: tool, tool: web_search, params: {query: JIT-Agent}}, {id: n2, type: tool, tool: summarize, params: {text_from: n1}} ], edges: [ {from: n1, to: n2} ] }第二种是 DSL 脚本定义一个简单的流程语言再由解析器转换成执行图。DSL 的优点是表达能力强但解析复杂JSON 的优点是模型不容易生成非法语法解析也简单。对于大多数场景我建议先选 JSON。在提示词中要明确告诉模型只能使用已注册的工具名称节点之间用什么字段引用前序结果当前任务无法拆解时返回一个直接回答节点输出必须符合指定 JSON Schema这样生成结果大概率是结构化的后面校验器不需要面对一堆自由文本。2.3 运行环境的硬性条件动态生成对运行环境的要求比普通 Agent 更高。因为它每一步都不是固定调用链模型要多次生成、多次校验、可能还要回滚。这块常见环境条件如下环境项入门级生产级说明推理模型API 模型例如通用对话模型支持 function calling 的模型或本地部署的 7B 以上模型function calling 能力能显著提升工具参数生成准确率内存16GB 以上32GB 以上主要看是否需要加载本地模型和缓存中间结果显存无要求如果走 API本地模型建议 24GB 以上7B 模型量化后一般 6GB 到 8GB但多实例需要更多显存执行引擎自己写 Python 脚本即可使用带 DAG 调度的流程引擎批量任务必须考虑并发、重试和失败隔离日志打印到控制台结构化日志记录每次生成的节点图和中间结果动态生成路径不固定日志是唯一可追溯手段如果你打算在本地部署模型先确认推理引擎对模型格式的支持情况。不同推理引擎支持的量化格式、精度类型和并行策略差别很大跨硬件环境部署时优先确认推理引擎是否支持当前模型格式再谈效果。不要一上来就追最新模型先把小模型跑通再逐步替换。2.4 延迟预期动态生成流程本身要消耗模型推理时间意味着响应不会像静态链路那样稳定地快。简单任务可能只多一次模型调用复杂任务可能要生成、校验、修正循环好几轮。我建议实测时记录两类指标生成耗时和执行耗时。生成耗时是模型从拿到用户输入到输出完整流程定义的时间执行耗时是执行器按流程图跑完工具调用并汇总结果的时间。如果生成耗时超过了总耗时的一半说明要么提示词太复杂要么模型选得不够准。这块没有绝对标准但可以作为一个判断参考。3. 让模型自己生成 Agent 框架从设计到单条流程跑通这一章讲具体怎么落地。我先给一个最小可行的实现路径再拆每一步的原因。3.1 第一步先定义输入和输出在写生成代码之前先确定输入输出格式。输入至少要包含用户原始请求工具注册表可选的上下文或历史记录约束规则比如“不得调用未注册工具”“最终必须返回中文答案”输出就是上一章说的流程定义 JSON。我建议加上一个final_answer节点类型表示流程结束后如何生成最终回复。没有这个节点工具都执行完了模型不知道该怎么汇集结果。输出示例{ nodes: [ {id: n1, type: tool, tool: web_search, params: {query: 笔记本 对比 推荐}}, {id: n2, type: tool, tool: parse_url, params: {url_from: n1}}, {id: n3, type: final_answer, params: {input_from: [n2], style: markdown_table}} ], edges: [ {from: n1, to: n2}, {from: n2, to: n3} ] }这里最需要注意的是参数引用的方式。不要让模型直接把上一个节点的完整输出传到下一个节点那样可能会超过上下文限制。正确做法是引用节点 ID由执行器在运行时把真实输出注入到下一个节点的输入中。3.2 第二步设计生成提示词给模型的提示词不建议写成长篇大论而是用清晰的规则块。我常用这种结构角色描述你是任务规划器负责拆解任务并生成可执行流程。工具列表列出工具名、能力、参数格式。输出格式给一个 JSON Schema 或一个示例。约束条件只能使用工具列表里的工具无合适工具时直接生成 final_answer输出必须能被 json.loads 解析。当前任务从每个请求动态插入。核心是约束优先于自由。让模型生成流程时倒不如让它“填空”。你可以把流程设计成一种接近模板骨架的 Schema模型只需要填具体节点参数。这样即使推理能力一般的小模型也能生成可用的流程。3.3 第三步加一个校验器不要盲目执行模型生成完 JSON 后不能直接拿去执行。原因很简单生成过程再严格也可能出现幻觉比如使用了不存在的工具名称、参数类型错误、节点引用了不存在的 ID。我建议至少做三层校验语法校验JSON 是否能解析必填字段是否存在。引用校验所有 edges 中的 from、to 是否都是已声明节点params 中引用的节点 ID 是否真实存在。能力校验tool 字段是否在注册表中参数是否满足该工具的必填要求。校验不通过时有两种处理方式。一种是直接把错误信息返回给模型让它修正最多重试两次另一种是走降级策略忽略工具调用直接让模型根据已有知识回答。两种方式都可以但建议生产环境选第一种加上限控制。校验器还有一个作用防止模型生成过深的链路。比如一个简单问题被生成了 20 个节点的长链明显不合理。你可以设一个最大节点数超过就提示模型重新生成。3.4 第四步执行器让生成结果跑起来生成校验通过后到执行阶段。执行器不关心业务逻辑只做三件事按节点顺序调用对应工具把前置节点的输出注入到后续节点输入收集日志、结果、错误信息执行器的顺序要根据 edges 构建拓扑顺序。为了简单第一版可以按节点列表顺序执行但从设计上要支持依赖编号。生产级执行器还需要支持并行执行没有依赖关系的节点。比如两个搜索节点互不依赖就可以并发执行减少总耗时。3.5 第五步单条任务验证第一次跑通时建议只选两条路径简单任务例如“用一句话介绍 JIT-Agent”预期只生成一个 final_answer 节点或一个搜索节点加 final_answer。复杂任务例如“搜索近期发布的 Agent 框架对比特点输出表格”预期生成搜索、解析、汇总、表格输出等多个节点。跑通后检查三件事流程定义是否符合预期各节点工具是否被正确调用final_answer 是否把前面的结果汇总成用户可读的答案如果第一步就卡住不要急着调模型先看日志模型输出的是什么、校验器报了什么错、是不是提示词里的工具描述和模型生成的参数不一致。动态生成系统里绝大多数问题都出在“模型生成结果能解析但语义不对”这个环节。4. 从单条 Demo 到生产级缓存、并发、失败重试和输出一致性单条跑通只是第一步。真正让 JIT-Agent 能用的是它能稳定处理一批不同任务而不是某个精心调试过的例子。这一章讲批量化和工程化时会遇到的真实问题。4.1 为什么不能直接开高并发动态生成流程比普通接口调用更消耗资源因为一次请求里可能包含多次模型推理。比如一个复杂任务生成流程要一次模型调用流程中某个节点又要调用一次模型做总结一次用户请求就可能消耗两到三次 LLM 推理。如果直接开 50 个并发请求底层模型服务很容易被打满出现超时或报错。尤其本地部署模型时显存和计算资源都是共享的并发一高推理延迟会迅速上升。我的建议是先按顺序跑 10 条不同任务观察平均生成耗时、工具执行耗时和失败率。确认稳定后再把并发调到 2、5、10 慢慢看。4.2 缓存是优化 JIT-Agent 的第一手段动态生成虽然灵活但很多任务的结构是相似的。比如同样是“搜索某某产品价格并整理成表格”只是关键词不同生成的流程节点几乎一样。这时可以对流程定义做缓存。缓存 key 可以是原始请求的哈希值请求的关键实体和动作类型工具注册表版本号缓存命中后直接用现成的流程定义不需要再调模型生成。好处很明显减少模型调用次数降低延迟同时避免模型对同一类任务生成不一致的流程。但缓存只缓存流程定义不能缓存工具执行结果否则数据会过期。每次执行节点时仍然实时调用工具只是少一步生成。4.3 失败重试和流程回滚静态 Agent 链路失败时可以按固定顺序重试。动态生成的流程失败时麻烦在于失败位置不固定。有可能是第三个节点调工具失败也有可能是模型生成的流程本身有问题。建议按这个顺序重试工具执行失败先看是否参数问题是则修正参数重试一次。节点引用失败说明流程定义有问题重新生成流程。模型生成超时降级为直接回答或者返回提示用户稍后再试。回滚策略不是撤销工具调用而是停止后续节点执行返回已执行节点的中间结果和错误位置。这样排查时能看到“流程执行到第几个节点失败、该节点输入是什么”。4.4 日志和输出命名动态生成流程的日志要把每次请求对应到一份完整的“流程定义快照”。也就是说不能只记录“用户问了什么、最后答了什么”还要把模型生成的节点图、参数、每一步的中间结果都记录下来。因为流程是动态的没有这份快照几天后用户反馈“某个结果不对”你根本不知道当时模型是怎么编排的。建议每条日志包含request_id最终流程定义 JSON每个节点的执行耗时和输入输出摘要校验器修正次数最终回复文本如果批量任务的输出要写到文件或数据库命名上要包含 request_id 或任务 ID避免动态流程跑完不同任务后输出内容互相覆盖。4.5 怎么判断成功率不要只看“最后有没有返回文本”。动态生成的流程可能最后返回了一段“看起来正常”的文本但中间工具全部没调用或者调用了错误的工具。这样用户可能一时察觉不到但结果其实不可信。我建议定义两个指标流程生成成功率模型输出的 JSON 通过全部校验的比例。节点执行成功率已生成流程中所有节点成功执行并产出预期输出的比例。两个比例都高说明动态生成系统才是真正稳定。如果生成成功率高但执行成功率低问题一般出在工具描述和真实工具能力不匹配如果生成成功率低问题出在提示词或模型选择上。5. 动态生成过程中的常见报错与排查顺序动态生成 Agent 框架的报错链路和普通 Agent 不太一样。普通 Agent 报错大多是工具调用失败动态生成还会多一类流程定义本身不合法。遇到问题时不要一上来就怀疑模型能力按顺序排查更高效。5.1 现象一模型输出 JSON 解析失败这是最常见的初期问题。模型返回的内容里混了解释文字或者 JSON 里多了注释、尾逗号。排查顺序先看原始输出确认是纯 JSON 还是夹杂了自然语言。看提示词是否给出了明确输出要求比如“只输出 JSON不要额外解释”。看模型类型通用对话模型对严格 JSON 输出的支持不如经过指令微调的模型。考虑是否用正则提取 JSON 片段或调用模型自带的 JSON 模式。如果只是少量请求失败用正则提取代码块里的 JSON 通常能解决。如果大量失败说明提示词边界没设置好或者模型本身不适合这个任务。5.2 现象二流程生成了但执行时找不到工具原因通常是模型把工具名称记错了比如注册表里叫web_search模型生成了search_web。排查顺序看校验器是否开启了“未注册工具”拦截。看工具注册表中的 name 是否容易让模型混淆。在提示词中强调工具名必须完全一致不能用近似表达。可以给工具加别名比如web_search同时支持search作为别名由执行器归一化处理。这里不建议把工具名称改得特别复杂比如search_web_v2_final。名称越长模型越容易出错。保持简短、语义清晰、稳定不变。5.3 现象三工具执行慢最后整体超时动态生成的流程可能包含多个串行工具。每个工具 1 秒五个节点串行就是五秒再加生成耗时用户可能已经等得不耐烦。排查顺序看日志中每个节点的耗时统计找到最耗时的节点。看节点之间是否有不必要的数据传递导致某个工具等待前序工具完成。看独立节点是否被串行执行了比如两个搜索节点可以并行。考虑缓存流程定义减少模型生成带来的延迟。执行器一定要设计好并行能力。即使第一版不支持也要在节点定义里预留depends_on字段后面加并行执行能力时不用改流程定义。5.4 现象四流程每一步都对但最终答案用户不满意这是最隐蔽的问题。动态生成出来的流程在技术上没有问题但用户觉得结果跑偏了。比如用户问“这几款显卡性能怎么样”模型生成了“搜索、读取详情、列出参数表格”但用户其实更希望得到“哪款性价比高”的推荐结论。这种情况不是模型生成流程的能力问题而是需求理解问题。排查顺序看流程定义中的 final_answer 节点是否包含了价值判断要求。看工具执行结果是否只是罗列而没有经过对比分析节点。在提示词中加入“如果任务包含对比、推荐倾向需要生成分析节点”。根据用户反馈补充工具能力比如增加“比价”或“提炼优缺点”的工具。很多时候不是动态生成不好用而是工具能力列表里没有能支撑用户最终需求的工具。模型只能编排你提供给它的能力能力有缺口生成结果就会看起来很“完整”但不解决问题。5.5 通用排查顺序清单每次出问题时建议按下面这个顺序过一遍不要跳步先看现象是报错、超时、无输出还是输出不符合预期。再看输入请求内容是否有歧义参数是否完整。看模型生成结果流程定义长什么样校验器报了什么错。看执行日志每个节点的耗时、输入输出摘要、错误信息。看工具本身工具是否真实可用参数格式是否匹配权限和路径是否有问题。看环境依赖版本、模型服务状态、内存和显存占用。大部分动态生成系统的故障都不是“模型太笨”而是前置的输入、工具描述、资源约束没有处理好。6. 什么场景适合用 JIT-Agent什么场景最好别碰动态生成不是银弹。它适合解决一类问题但在另一类问题里反而会引入麻烦。最后这些边界如果不讲清楚直接照搬思路会让你付出不必要的维护成本。6.1 适合动态生成的场景判断标准很简单任务路径是否不稳定以及是否需要根据用户输入进行个性化编排。适合的场景包括信息收集类任务搜索、阅读、整理、对比、总结路径随查询内容变化。工具组合类任务用户的请求可能需要调用不同的工具组合比如“翻译并发送到指定邮箱”和“翻译并保存到本地”。复杂数据加工任务需要把多个来源的数据合并、转换、输出不同格式动态编排能根据数据源结构生成合适流程。需要快速扩展工具的 Agent 系统新加一个工具后不需要为每个旧场景新增流程分支模型会自动在其能力范围内编排新工具。6.2 不适合动态生成的场景判断标准是流程是否必须稳定、可预期、强审计。不适合的场景包括支付、结算、订单状态流转这类流程每一步都强依赖前一步的结果而且必须符合业务规则。让模型动态生成流程虽然技术上可行但风险收益不匹配。严格合规场景比如审批流、告警推送、权限控制。一个错误生成的跳转可能造成越权或漏发。高频低变化场景如果任务只有一两种固定模式比如每天都跑同一个数据报表静态框架更简单更稳。动态生成只会增加延迟和失败点。对延迟极度敏感的场景比如用户输入十几个字希望几百毫秒内响应。动态生成至少多一次模型调用不适合。我见过有人把动态生成用到内部审批流上结果模型在某次运行中把“审批通过”和“转发给财务”两个节点连成串行差点造成非预期流转。动态生成适合探索性任务不适合强约束、强责任链路。6.3 实践中的折中方案如果既想要动态生成的灵活性又不想承担完全自由生成的风险可以折中模板加动态补全提前定义好一定数量的流程模板模型只在模板的“缺口处”生成参数而不是生成整张图。预生成加人工确认对复杂任务模型先生成流程展示给用户确认后再执行。动态生成加白名单限制模型只能生成指定范围内的节点组合超出范围直接拒绝。折中方案的效果往往比全动态生成更稳定也更容易在真实业务里落地。6.4 关于这套方案的长期维护动态生成系统上线后最重要的不是调模型而是维护“工具注册表”。工具数量越多模型在生成时越容易选错工具、传错参数。每新增一个工具都要重新跑一轮回归任务观察模型是否能正确生成包含新工具的流程。同时要持续收集失败样本。模型生成的流程一旦校验失败把请求、生成结果、错误信息、修正后的流程都记录下来。这些数据数量多了之后可以反哺到提示词里甚至用来微调一个小模型专门做流程生成任务。如果只是学习或做原型用 API 模型加 JSON Schema 校验就够。如果要长期生产运行我建议把流程生成器、校验器、执行器拆成独立模块日志和指标从第一天就开始埋点。这套架构真正落地时最该盯住的不是“模型多聪明”而是输入格式、工具描述质量、资源占用和失败重试这些工程细节。