动态生成智能体框架JIT-Agent：从概念到最小实现

AI 应用开发正在快速从“单次 Prompt 调用”转向“多工具、多步骤、动态决策”的智能体形态。但很多团队在搭建智能体应用时都卡在一个地方：Agent 的任务一变化，整个服务的结构就要跟着改——工具列表要重新配置，提示词模板要重写，工作流要重新编排，然后经历一次完整的发版流程。这种“静态”的智能体，本质上只是把一套固定的逻辑包装成 API，距离真正意义上的智能体还有不小差距。

这也是 JIT-Agent 这类“动态生成智能体框架”的思考来源。JIT 一词原本来自编译原理，指“即时编译”。把同样的思路迁移到智能体框架中，核心就变成一句话：让 Agent 的结构在任务到达时按需生成，而不是在启动前被写死。这篇文章会从概念拆解、架构对比、最小实现、常见坑和工程化建议几个角度，把这种动态生成智能体框架的模型讲清楚。读完你不仅能理解它的价值，还能照着实现一个可用的小型框架原型。

1. 为什么智能体框架需要“动态生成”这个思路

先看一个典型的业务场景。假设你要做一个客服智能体，它需要查询订单、处理退款、回答商品问题、推荐优惠活动。传统做法通常是写一个CustomerServiceAgent类，把所有工具函数都注入进去，再配合一个固定的系统提示词。上线时一切正常，但第二天运营说要增加一个“物流催单”能力，或者要在大促期间临时关掉“退款处理”功能，问题就来了。

如果工具列表是在启动时写死的，那每一次业务变更都意味着：改代码、跑测试、重新构建镜像、滚动发布。这个循环在许多团队里要走小半天甚至一天。“让业务快速变化”这件事情，在静态智能体架构下变得非常昂贵。

动态生成的思路截然不同。它把 Agent 视作一个运行时产物：请求到达后，系统先解析出任务意图，再从一组可注册、可替换的组件中挑选合适的工具、模型和提示词模板，临时组装出一个 Agent 实例。当任务结束后，这个实例如果不需要持久化，就可以直接回收。下次请求来了，再按新的任务情况重新生成。

这种设计解决的不只是“发版频繁”的问题，它带来三个更本质的改变。第一，扩展方式变了——新增能力不需要改已有代码，只需要往组件注册表里增加一条记录；第二，隔离粒度变了——每个任务实例拥有自己独立的工具集合与提示词组合，一个 Agent 的内部问题不会因为代码耦合而传导到另一个 Agent；第三，使用门槛变了——任务描述与组件配置的关系越清晰，业务人员甚至可以通过配置来参与智能体编排，而不必每次都依赖开发改代码。

当然，动态化不是免费午餐。组件注册表会变成一个新的复杂源，配置管理、安全边界、可观测性问题都会随之而来。这也是本文后半部分要重点讨论的内容。

2. 核心概念拆解：从 JIT 编译到 JIT-Agent

“JIT-Agent”不是某一家公司推出的固定产品，它更像一种架构模式的统称。要理解它，建议先把三个关键词拆开看。

2.1 JIT 的含义

JIT 是 Just-In-Time 的缩写，最经典的应用场景是 Java 虚拟机中的即时编译器。在没有 JIT 的年代，Java 代码要么边解释边执行，性能较差；要么提前编译成机器码，但失去了跨平台灵活性。JIT 的做法是在程序运行过程中，对热点代码进行即时编译，让程序兼顾“启动灵活”与“执行高效”。

把这个概念映射到智能体框架中，可以做一组类比：

• 传统 Agent 框架像“提前编译”——系统启动时就把 Agent 类、工具函数、Prompt 全部加载到内存，运行时只做调用。
• JIT 式 Agent 框架像“运行时编译”——系统只负责维护组件注册表和组装规则，直到某个任务真正到达，才动态决定用哪些工具、选哪个模型、拼接什么提示词，然后实例化这个 Agent。

这种“先不决定，任务到了再决定”的设计，就是 JIT-Agent 最核心的哲学。

2.2 什么是 Agent

在 AI 应用语境下，Agent（智能体）可以理解为一个具备感知、决策、行动能力的程序实体。它接收用户请求后，会分解任务、选择工具、调用外部系统，并把最终结果整理成回答。不同于单纯的大模型聊天接口，Agent 的核心特征是“能做事”——它通过函数调用（Function Calling）或代码执行来影响真实世界。

但 Agent 本身并不神秘。它的行为边界完全由三个要素决定：能调用哪些工具、使用什么模型、遵循怎样的提示词约束。这三个要素恰好就是 JIT-Agent 可以在运行时动态控制的对象。

2.3 动态生成智能体框架

综合来看，“动态生成智能体框架”可以定义为：一套在运行时根据任务输入，从组件注册表中动态挑选并组装模型、工具、提示词模板，从而生成智能体实例的框架。

一个完整的 JIT-Agent 架构通常包含三个核心模块：

任务解析层解决“你是什么任务”，组件注册表解决“我有什么可用组件”，运行时组装器解决“怎么把组件组合起来完成任务”。这三者协同运作，构成了 JIT-Agent 的基本运行模型。

3. 动态生成式 Agent 框架与传统 Agent 框架的对比

要判断 JIT-Agent 是否适合你的项目，最直接的方式是对比它与传统 Agent 框架的差异。

从表格可以看出一条清晰的判断线索：如果一个项目中智能体的任务形态基本稳定，半年都不怎么变化，那么传统框架的简单性和稳定性反而是优势；但如果你的系统经常要接入新工具、调整新流程、或者需要面向不同用户群体定制不同行为，JIT-Agent 风格的架构会显著降低变更成本。

需要特别提醒的是：动态生成不是银弹。它把“复杂度”从代码层转移到了配置层和运行时层。如果没有配套的注册表管理、版本控制和监控机制，动态化之后可能制造出一个难以排查的“配置地狱”。这也是部分团队尝试动态 Agent 后又退缩的原因。

4. 环境准备与最小实现思路

下面进入动手环节。这一节不会牵扯复杂分布式组件，而是用 Python 实现一个最小的 JIT-Agent 原型。项目的核心目标是展示三件事：如何维护组件注册表、如何在运行时解析任务、如何根据任务动态生成 Agent 实例。

4.1 环境准备

建议环境如下：

• Python 3.10 或更高版本
• 一个可用的模型推理接口。如果本机无法访问云端模型服务，可以用 Ollama 拉取本地模型，例如运行ollama pull qwen2.5:7b后通过http://localhost:11434/v1调用兼容接口
• 如果希望让 Agent 具备“调用真实工具”的能力，还需要准备一个具备函数调用能力的模型接口

这里需要注意一个关键原则：模型接口地址和密钥通过环境变量管理，不要写死在代码里。这在任何智能体项目中都应该成为默认习惯。

export LLM_API_BASE="http://localhost:11434/v1" export LLM_API_KEY="ollama" export LLM_MODEL="qwen2.5:7b"

如果使用的是云端模型服务，将LLM_API_KEY替换为真实的密钥，同时要注意密钥的存储安全，不要提交到 Git 仓库。

4.2 项目结构规划

一个最小化但具备扩展性的项目结构可以这样规划：

jit_agent_demo/ ├── main.py # 入口，HTTP 接口或命令行入口 ├── registry/ │ ├── __init__.py │ ├── tool_registry.py # 工具函数注册表 │ └── prompt_registry.py # Prompt 模板注册表 ├── core/ │ ├── __init__.py │ ├── task_parser.py # 任务解析器 │ └── agent_builder.py # 动态组装 Agent 的生成器 └── tools/ ├── __init__.py └── order_tools.py # 示例工具集

这个结构的核心思想是“注册表与组装器分离”。工具注册表负责登记所有可用的工具函数，Prompt 注册表负责维护不同任务对应的提示词模板，任务解析器负责从输入中识别任务类型，而 agent_builder 则是整个框架的“JIT 引擎”。

5. 核心代码实现：从注册表到运行时组装

下面逐步实现这个最小 JIT-Agent 框架。我会把代码分成几段，每一段对应一个核心文件。

5.1 工具注册表：让工具可以被动态发现

工具注册表是整个框架的基础。它维护一张工具名 -> 函数对象的映射表，并提供注册和获取能力。实际项目中，工具函数可能散落在不同模块中，我们可以通过 Python 的装饰器语法自动注册。

# 文件路径：registry/tool_registry.py from typing import Callable, Dict class ToolRegistry: """工具注册表：负责登记和查询可被 Agent 调用的函数。""" def __init__(self): self._tools: Dict[str, Callable] = {} def register(self, name: str): """装饰器，用于自动注册工具函数。 用法： tool_registry = ToolRegistry() @tool_registry.register("查询订单") def query_order(order_id: str) -> str: return f"订单 {order_id} 的状态是已发货" """ def decorator(func: Callable): self._tools[name] = func return func return decorator def get(self, name: str) -> Callable: if name not in self._tools: raise KeyError(f"工具 [{name}] 未注册，请检查 tools 目录下的注册代码") return self._tools[name] def list_tools(self) -> list: return [ {"name": name, "doc": getattr(func, "__doc__", "") or ""} for name, func in self._tools.items() ] # 全局工具注册表单例 tool_registry = ToolRegistry()

为什么使用装饰器注册？因为这让工具函数无需修改核心框架代码，只要在模块加载时执行到@tool_registry.register(...)这一行，就会被自动登记。新增工具时，只需要新写一个函数并加上注册装饰器，相当于给“组件注册表”增加了一条记录。

5.2 编写示例工具集

为了让运行时组装有意义，我们需要准备几个业务工具。下面这段代码模拟一个客服场景的工具集：查询订单、查询退货政策。

# 文件路径：tools/order_tools.py from registry.tool_registry import tool_registry @tool_registry.register("查询订单") def query_order(order_id: str) -> str: """根据订单 ID 查询订单状态。""" # 真实项目中这里会调用订单系统接口 return f"订单 {order_id} 当前状态：已发货，预计 2 天后送达" @tool_registry.register("查询退货政策") def query_return_policy() -> str: """查询该店铺的退货政策。""" return "商品签收后 7 天内支持无理由退货，食品与定制类商品除外" @tool_registry.register("计算退款金额") def calculate_refund(order_id: str, reason: str) -> str: """计算退款金额，需要订单 ID 和退款原因。""" # 真实项目中这里会调用结算服务 return f"订单 {order_id}，退款原因：{reason}，预计退款 199.00 元"

注意每个工具函数都写了 docstring，这是因为组装 Agent 时，我们通常需要把“工具的描述信息”转换成模型可以理解的函数调用说明书。工具描述越清晰，模型就越容易在正确场景选中正确工具。

5.3 Prompt 注册表：让提示词按任务可配

Prompt 模板同样是动态生成的组成部分。不同任务使用不同的系统提示词，这是 JIT-Agent 实现“行为差异”的重要手段。

# 文件路径：registry/prompt_registry.py from typing import Dict PROMPT_TEMPLATES: Dict[str, str] = { "售后咨询": ( "你是一名售后客服。你的责任是帮助用户解决订单查询、退货退款等问题。\n" "在回答前，请先判断是否需要调用工具。如果需要查询订单，必须使用工具，" "不要凭记忆编造订单信息。回答要简洁、友好。" ), "商品推荐": ( "你是一名商品推荐专员。你需要根据用户描述的需求推荐合适的商品。\n" "如果无法从已有信息中确认用户需求，请主动提问澄清。" ), "默认": ( "你是一名通用 AI 助手，请使用注册表中的工具来帮助用户完成任务。" ), } class PromptRegistry: """Prompt 模板注册表：根据任务类型获取系统提示词。""" def __init__(self, templates: Dict[str, str]): self._templates = templates def get_prompt(self, task_type: str) -> str: return self._templates.get(task_type, self._templates["默认"]) prompt_registry = PromptRegistry(PROMPT_TEMPLATES)

这里有一个很实用的设计：get_prompt方法带有“默认兜底”。如果任务解析器识别出一个未注册的任务类型，框架不会抛异常，而是退回默认 Prompt。这个兜底策略在动态系统中非常重要——你永远无法枚举所有任务，必须允许“未知任务走通用流程”。

5.4 任务解析器：从用户输入判断任务类型

任务解析器是 JIT-Agent 的“输入分析器”。它的目标是从一句自然语言请求中提取出任务类型和关键参数。

# 文件路径：core/task_parser.py from typing import Dict class TaskParser: """基于关键词规则的任务解析器。 生产环境可以替换为大模型分类器或意图识别服务。 这里使用规则是为了让最小原型更容易理解。 """ KEYWORD_MAP = { "售后咨询": ["订单", "退款", "退货", "物流", "发货"], "商品推荐": ["推荐", "买", "适合", "想要", "种草"], } def parse(self, user_input: str) -> Dict[str, str]: task_type = "默认" for candidate_type, keywords in self.KEYWORD_MAP.items(): for keyword in keywords: if keyword in user_input: task_type = candidate_type break if task_type != "默认": break return {"task_type": task_type, "raw_input": user_input}

这个解析器使用的是朴素的“关键词命中”规则。真实生产环境中，这里更适合引入一个小模型分类器，或者在任务切换频率不高时让用户主动指定任务类型。但最小原型用规则做解析，足够让人理解 JIT-Agent 的完整链路。

从材料角度看，这里的任务解析层正好对应 JIT-Agent 模型中的“任务画像”环节。你可以认为它是整个动态生成流程的第一个触发点。

5.5 Agent 生成器：JIT 的核心

接下来是整个框架中最关键的部分：Agent 生成器。它负责获取任务类型、选择 Prompt、筛选工具、选定模型，然后组装出一个可执行的 Agent 实例。

# 文件路径：core/agent_builder.py from typing import List import openai from registry.tool_registry import tool_registry from registry.prompt_registry import prompt_registry from core.task_parser import TaskParser class Agent: """运行时生成的 Agent 实例。""" def __init__(self, model: str, system_prompt: str, tools: List[dict]): self.model = model self.system_prompt = system_prompt self.tools = tools self.client = openai.OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", ) def run(self, user_input: str) -> str: """按顺序执行：调用模型 -> 判断是否需要调用工具 -> 返回结果。""" messages = [ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": user_input}, ] # 第一轮：请求模型给出回复 response = self.client.chat.completions.create( model=self.model, messages=messages, tools=self.tools, tool_choice="auto", ) assistant_message = response.choices[0].message # 如果模型决定调用工具，则执行对应的本地函数 if assistant_message.tool_calls: for tool_call in assistant_message.tool_calls: fn_name = tool_call.function.name args = tool_call.function.arguments fn = tool_registry.get(fn_name) # 动态执行工具函数 tool_result = fn(**args) # 将工具结果追加到消息中，让模型生成最终回答 messages.append(assistant_message) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": str(tool_result), }) final_response = self.client.chat.completions.create( model=self.model, messages=messages, ) return final_response.choices[0].message.content return assistant_message.content class AgentBuilder: """JIT-Agent 运行时组装器：任务到达时动态生成 Agent。""" def __init__(self): self.task_parser = TaskParser() def build_agent(self, model: str, user_input: str) -> Agent: task_info = self.task_parser.parse(user_input) task_type = task_info["task_type"] # 1. 动态选择系统提示词 system_prompt = prompt_registry.get_prompt(task_type) # 2. 动态绑定工具列表 # 售后任务绑定订单查询和退货政策工具，商品推荐任务不绑定工具 if task_type == "售后咨询": tools = [ {"type": "function", "function": { "name": "查询订单", "description": "根据订单 ID 查询物流与订单状态", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单 ID"} }, "required": ["order_id"], }, }}, {"type": "function", "function": { "name": "查询退货政策", "description": "查询平台退货政策", "parameters": {"type": "object", "properties": {}}, }}, ] else: tools = [] # 3. 组装 Agent 实例 agent = Agent( model=model, system_prompt=system_prompt, tools=tools, ) return agent

这段代码需要特别说明几个细节。

第一，工具绑定是动态的。同样是“查询订单”，如果任务类型是售后咨询，Agent 就具备工具调用能力；如果任务类型是商品推荐，Agent 就不携带工具。这避免了所有模型请求都携带大量无关工具，既节省 token，也减少模型误调用。

第二，组装 Agent 时采用“任务画像 -> 组件选择 -> 实例化”的顺序。这是 JIT-Agent 架构的核心时序：先判断用户要什么，再决定给 Agent 装什么。

第三，模型选择也可以动态化。在这个示例中，build_agent接收model参数，调用方可以根据任务类型传入不同模型。实际项目中可以进一步做成“路由规则表”，例如简单问题用轻量模型，复杂推理任务用大参数模型。

第四，Agent 实例是临时创建的。每次请求都会新建一个 Agent 对象，请求结束后即可回收。这种生命周期管理方式让 Agent 状态变得可控，不会出现“上次请求的残留状态影响下次请求”的问题。

5.6 主程序入口：把完整链路串起来

最后需要一个入口来模拟一次完整的调用。

# 文件路径：main.py from core.agent_builder import AgentBuilder from registry.tool_registry import tool_registry def main(): print("=== JIT-Agent 最小原型 ===") print("已注册工具：", [t["name"] for t in tool_registry.list_tools()]) print() builder = AgentBuilder() while True: user_input = input("请输入你的问题（输入 exit 退出）：") if user_input.strip().lower() == "exit": break # JIT 核心：任务到达时动态生成 Agent agent = builder.build_agent(model="qwen2.5:7b", user_input=user_input) print("\n[正在执行] 已根据任务动态生成 Agent") print(f"[系统提示词] {agent.system_prompt[:50]}...") print(f"[绑定工具数] {len(agent.tools)}") print() result = agent.run(user_input) print("[Agent 回复]", result) print("-" * 60) if __name__ == "__main__": main()

6. 运行结果与效果验证

把上述文件按项目结构保存后，在项目根目录执行：

python main.py

如果一切正常，你会先看到框架打印出已注册的工具列表，然后进入交互界面。

输入“我想查一下订单 20241001 的物流情况”，预期输出大致如下：

=== JIT-Agent 最小原型 === 已注册工具： ['查询订单', '查询退货政策', '计算退款金额'] 请输入你的问题（输入 exit 退出）：我想查一下订单 20241001 的物流情况 [正在执行] 已根据任务动态生成 Agent [系统提示词] 你是一名售后客服。你的责任是帮助用户解决订单查询、退款退货等... [绑定工具数] 2 [Agent 回复] 您的订单 20241001 当前状态：已发货，预计 2 天后送达。

这里最值得关注的验证点有三处：

1. 任务是否被正确识别：在输出中查看“系统提示词”前缀，如果识别为售后咨询，说明任务解析层生效。
2. 工具是否按需绑定：售后咨询任务应该绑定 2 个工具；如果输入“帮我推荐一部手机”，工具数应该是 0。
3. 工具函数是否被实际调用：如果回复中包含“当前状态：已发货”这类来自工具函数的数据，说明动态组装后的 Agent 正确执行了工具调用链路。

如果运行失败，第一步要看的不是业务代码，而是模型服务是否可用。用下面这个命令单独测试模型接口：

curl http://localhost:11434/v1/models

如果这个请求长时间无响应或返回连接错误，说明 Ollama 服务没有启动，或者接口地址配置不对。第二部再检查main.py中的base_url和api_key是否与本地模型服务匹配。这一步排查顺序可以避免在框架逻辑里空转。

7. 常见问题与排查思路

动态生成框架的排查链路比普通脚本长，因为问题可能出在注册表、任务解析、模型调用、工具执行等多个环节。下面整理了几类最典型的问题。

这里有一个容易被忽视的心法：排错时要先确认“问题出在生成之前还是生成之后”。生成之前的问题，比如任务解析错误、注册表缺失，往往在打印出的系统提示词里就能看出来；生成之后的问题，比如模型没有正确调用工具、回答内容编造事实，则与模型能力和工具描述质量相关。先把问题归位，再处理具体错误，效率会高很多。

8. 工程化最佳实践与生产环境建议

最小原型演示了 JIT-Agent 的核心流程，但把它真正放到生产环境中，还需要补充很多工程化细节。以下是我认为最值得重视的几个方向。

8.1 动态组件要纳入配置管理

动态生成让 Agent 不再由代码结构约束，但也意味着组件注册表可能变成一个新的“混乱源”。生产项目中，工具注册表、Prompt 模板、模型路由规则都应该纳入 Git 管理，并且通过配置中心推送。每次组件变更都要有明确的版本号，以便在线上出现问题时快速回滚到上一个版本。

一个常见做法是：把“组件注册表”落到数据库或配置中心，而不是散落在 Python 装饰器中。这样运营人员可以在后台查看当前系统有哪些工具、哪些 Prompt 模板处于在线状态，开发人员则通过发布流程控制组件上线。

8.2 安全边界要前置设计

动态生成最危险的地方在于“动态执行”。如果 Agent 的某个工具需要执行用户传入的代码或者拼装命令，一定要设置强校验。比如，不让模型直接调用任意 Python 表达式，开放给 Agent 的工具应该是白名单机制。对于需要访问外部系统的工具，必须增加鉴权、限流和审计日志。

在最小原型中，tool_registry.get只能获取已注册的函数，这已经是一个相对安全的模型。但真实系统里，“注册”这个动作本身也要受控，不能让外部输入直接往注册表里写内容。

8.3 可观测性是动态系统生存的前提

静态 Agent 的逻辑链路相对固定，出了问题容易定位。动态生成的 Agent 每次都不一样，如果日志不完整，排错就像大海捞针。建议从三个层面加强可观测性：

• 结构化日志：在任务解析、组件组装、工具调用、模型返回四个阶段各打一条结构化日志，记录任务类型、组件版本、耗时等关键字段。
• 链路追踪：为每次请求生成唯一 request_id，贯穿整个 Agent 生命周期。
• 组件调用统计：统计每个工具函数的调用次数、成功率、平均耗时，及时发现组件劣化。

8.4 模型路由要结合成本和能力

动态生成的优势之一是可以在运行时根据任务难度选择模型。简单问题使用轻量模型，可以显著降低成本；复杂推理任务使用强模型，可以保证回答质量。实践时建议维护一张模型路由表，设定任务类型与模型档位的映射关系，并配合超时、重试策略。

需要注意，模型路由切换对用户体验影响很大。首次接入某一款新模型时，应先在灰度环境中验证其函数调用能力和回答质量，再逐步放量。

8.5 从最小原型到生产架构的演进路径

如果要在真实项目落地 JIT-Agent，不建议直接照着最小原型做。

建议分三步走：

第一步，把最小原型中的“任务解析器”替换为大模型意图分类或规则引擎，先保证任务识别足够准确。 第二步，把“组件注册表”外置到配置中心或数据库中，做到组件动态生效，不需要重启服务。 第三步，增加 Agent 运行时的监控、限流和审计能力，再接入外部业务系统的工具函数。

当这三步完成时，你的 JIT-Agent 就已经从一个演示原型变成了一套可承载业务变更的动态智能体平台。到了这个阶段，业务人员甚至可以通过平台页面配置工具和 Prompt，而不需要直接修改代码。

9. 总结与后续学习方向

JIT-Agent 的核心贡献不是发明了某种新算法，而是提供了一种组织智能体系统的架构模型：把 Agent 从“被定义好的对象”变成“按需生成的运行时产物”。这种模型与编译领域的 JIT 思想一脉相承，解决的核心问题也类似——在系统变化频繁、场景差异明显的环境中，保留灵活性并降低变更成本。

沿着这个方向继续深入，有几个值得关注的子方向：函数调用机制的设计与调优、多模型路由策略、动态工作流引擎、组件注册中心的产品化设计，以及 Agent 运行时的可观测性建设。每个方向单独拿出来都足以构成一篇独立的技术文章。

如果现在的你正准备搭建一个面向多业务场景的智能体系统，不妨从本文的最小原型开始，先把注册表、任务解析器、Agent 组装器这条链路跑通，然后再逐步引入配置中心与监控体系。动态生成的边界在哪里、哪些组件适合动态化、哪些模块还是静态更稳妥，这些经验只有在自己动手之后才最可信。建议把本文收藏，作为后续实践的起点。