插件化Agent框架核心架构与从零实现：一切皆插件

最近做智能体开发的朋友应该都有同感大模型的能力边界其实已经比较清晰真正容易翻车的地方往往在工程一侧。工具怎么接入、上下文怎么管理、多个智能体怎么协作、插件怎么热插拔这些问题如果全靠自己从头搭工作量一点都不比写业务代码小。这段时间 DeepSeek 相关 Agent 框架的开源讨论热度很高社区里无论是 Harness、Hermes 这类智能体项目还是各类插件化工具核心思路都指向同一个方向把智能体的能力拆成插件模型只负责决策工程负责组装。本文不对具体开源仓库做逐行源码解读公开资料有限而是围绕“一切皆插件”的设计范式拆解插件化 Agent 框架的核心架构并带大家从零实现一个可扩展的最小 Agent 系统。学完以后你能理解智能体框架的分层思路能自己写插件、挂工具也能对接 OpenAI 兼容接口的大模型服务。1. 背景与核心概念1.1 智能体开发为什么需要框架很多人刚接触 Agent 时第一反应是“调大模型接口把用户问题丢进去拿到结果返回”。但真实的智能体应用远不止这些。一个稍微完整一点的智能体至少需要处理多轮对话中的上下文维护。调用搜索、数据库、业务 API 等外部工具。根据模型输出决定下一步动作而不是一次对话就结束。错误重试、超时控制、日志追踪。多个智能体之间的协作与编排。这些能力如果全部写在业务代码里项目很快就会变成一个大杂烩。今天接了一个搜索工具明天要加一个天气插件后天又要换成另一个大模型每次改动都可能牵一发动全身。Agent 框架要解决的核心问题就是把“模型能力”和“工程能力”解耦。模型负责理解用户意图、生成回复、决定调用哪个工具框架负责工具的注册与调用、上下文存储、执行流程控制、日志和监控。DeepSeek 这套开源 Agent 框架受关注度高正是因为它把这种解耦做到了比较彻底的程度不只工具可以做成插件模型、记忆、后处理逻辑也全部插件化。1.2 “一切皆插件”到底是什么意思插件化架构在 IDE、构建工具、浏览器里已经很常见。VS Code 的插件体系、Chrome 扩展、Maven 插件都是把某种能力封装成独立单元通过统一接口挂载到主程序上。Agent 框架里的“一切皆插件”思路类似但它把插件化的范围扩大了很多传统 Agent 框架插件化 Agent 框架工具列表写死在代码里每个工具是一个插件按需加载模型固定绑定某一个厂商模型调用层是插件可以随时切换上下文管理封装在框架内部记忆策略是插件可替换为不同的存储方式编排逻辑难以扩展每个执行步骤也可作为插件挂载新能力需要改框架代码新能力只需要新增一个插件包所以“一切皆插件”不是把代码拆得细一点那么简单而是从架构层面重新划定了边界。插件与插件之间通过协议通信插件不关心其他插件是怎么实现的只关心自己收到的输入和需要返回的输出。这种设计的直接好处是生态化。官方只需要维护一套稳定协议和少量内置插件社区可以围绕这个协议贡献大量插件。用户不需要自己实现复杂逻辑只需要“装插件”。1.3 Agent 框架、插件与工作流编排的关系这里需要区分三个容易混淆的概念。Agent 框架是底座负责主循环、事件分发、状态管理、插件生命周期管理。它本身不解决具体业务问题只是提供一套运行环境。插件是能力的载体比如“天气查询插件”“数据库查询插件”“长时记忆插件”。插件实现具体功能并声明自己可以被框架调用。工作流编排是更高层的应用方式它决定“什么时候调用哪个插件”“插件返回结果后下一步做什么”。在插件化 Agent 框架中编排本身也可以做成插件这样就可以在不停机的情况下调整智能体的行为。理解这三层关系以后后面看架构设计就会清楚很多。2. 插件化 Agent 框架的架构设计2.1 整体分层一个典型的插件化 Agent 框架通常会分成下面几层用户输入 ↓ [接入层] 处理用户消息格式、权限校验、会话识别 ↓ [模型决策层] 大模型根据上下文和插件清单决定调用哪个插件或直接回复 ↓ [插件路由层] 解析模型输出匹配插件校验参数 ↓ [插件执行层] 执行插件代码返回结构化结果 ↓ [记忆层] 追加上下文保存关键信息 ↓ [输出层] 生成最终回复返回用户纵向贯穿所有层的是事件总线和日志追踪。每一层都通过事件通知框架“我开始了”“我成功了”“我失败了”这样上层可以决定是继续执行还是终止。2.2 插件协议与注册机制插件化架构最重要、也最容易设计失败的是插件协议。协议定义得不清晰后面每个插件都会写得很难受。一个合理的插件协议至少包含以下部分插件名称全局唯一标识。插件描述告诉模型“这个插件是干什么的”“什么时候该调用它”。参数声明插件接受哪些参数每个参数的类型、是否必填。执行方法接收参数返回结构化结果。生命周期回调加载时初始化、卸载时清理资源。注册机制通常有两种。一种是启动时集中注册框架扫描指定目录自动加载插件另一种是运行时动态注册通过接口或配置文件加载。生产环境多采用“启动时扫描 运行时按需实例化”的方式既能保证可控性又能降低资源占用。2.3 Agent 主循环与工具调用协议传统的一次问答只需要“用户输入 → 模型输出”两步但 Agent 需要循环执行。主循环大致可以描述为接收用户输入追加到上下文。把上下文和可用插件列表交给模型。模型输出结果。判断输出是最终答案还是工具调用指令。如果是工具调用执行插件把结果追加到上下文。回到第 2 步让模型基于工具结果生成下一步内容。如果达到最大步数或模型输出最终答案结束循环。这个循环在普通代码里写起来并不复杂但工程上要考虑很多边界条件工具调用超时怎么办工具返回结果太长导致上下文溢出怎么办模型连续调用工具进入死循环怎么办框架层把这些策略收敛成可配置项比每个业务团队各自实现要省力得多。2.4 记忆、上下文与可观测性插件化框架里的记忆层比较容易被忽略但它往往是决定智能体体验的关键。短期记忆处理当前会话内的上下文通常就是消息列表但随着工具调用变多上下文会膨胀很快。长期记忆负责跨会话保存用户偏好、历史结论、业务知识通常需要向量数据库或普通数据库支持。可观测性同样重要。生产环境里的智能体几乎一定会出现“模型乱调用工具”“某个插件响应慢”“上下文被无关信息塞满”的问题。如果框架没有提供完整的 trace 和日志排错会非常痛苦。这也是插件化框架比自研脚本更有价值的地方。3. 环境准备3.1 开发环境与依赖为了能把上面的架构思路落到代码里我们来实现一个最小可运行的插件化 Agent。示例使用 Python需要准备依赖用途Python 3.9运行环境openai调用 OpenAI 兼容的大模型接口python-dotenv读取 .env 配置文件pydantic参数校验与数据模型定义版本不需要完全和本文一致Python 3.9 以上即可openai 库建议使用 1.x 版本接口和 0.x 差别比较大。先创建项目目录mkdir plugin_agent cd plugin_agent # 创建虚拟环境 python -m venv venv # 激活虚拟环境 # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate安装依赖pip install openai python-dotenv pydantic3.2 项目结构示例项目采用扁平化结构但保留“插件化”的目录边界plugin_agent/ ├── .env.example ├── requirements.txt ├── main.py └── agent/ ├── __init__.py ├── core.py ├── registry.py └── plugins/ ├── __init__.py ├── tool_plugins.py └── llm_plugin.py说明一下各文件职责core.py插件基类、上下文数据结构。registry.py插件注册表。tool_plugins.py内置的工具插件。llm_plugin.py大模型调用插件。main.py启动入口包含 Agent 主调度循环。3.3 配置文件创建.env.example内容如下# 大模型 API Key LLM_API_KEYsk-your-key-here # OpenAI 兼容接口地址DeepSeek 等平台请以官方文档为准 LLM_BASE_URLhttps://api.deepseek.com # 模型名称例如 deepseek-chat LLM_MODELdeepseek-chat # Agent 最大循环步数防止工具调用死循环 AGENT_MAX_STEPS5复制一份为.env填入自己的密钥。千万不要把.env提交到 Git 仓库。4. 完整实战构建一个最小插件化 Agent下面进入核心代码部分。我们会遵循“一切皆插件”的思路把工具、大模型都做成插件框架层只负责任务调度。4.1 定义插件基类与注册表首先定义插件的公共抽象。文件agent/core.pyfrom typing import Any, Dict, List, Optional from dataclasses import dataclass, field dataclass class PluginContext: 插件执行上下文所有插件都能访问。 session_id: str history: List[Dict[str, str]] field(default_factorylist) metadata: Dict[str, Any] field(default_factorydict) dataclass class PluginResult: 插件执行结果。 success: bool data: Any None error: Optional[str] None def to_prompt(self) - str: if self.success: return f工具执行成功结果为{self.data} return f工具执行失败错误为{self.error} class BasePlugin: 插件基类所有插件必须继承此类。 name: str base_plugin description: str 插件描述供模型判断何时调用 parameters: Dict[str, Dict[str, Any]] {} def __init__(self, config: Optional[Dict[str, Any]] None): self.config config or {} def execute(self, params: Dict[str, Any], context: PluginContext) - PluginResult: raise NotImplementedError这里的重点是BasePlugin的三个类属性。name是插件唯一标识description会拼进系统提示词里告诉模型该插件的用途parameters声明参数结构。模型看到这些信息后才能决定是否调用、传什么参数。接下来是注册表。文件agent/registry.pyfrom typing import Dict, Optional from agent.core import BasePlugin class PluginRegistry: 插件注册表负责管理所有插件的生命周期。 def __init__(self): self._plugins: Dict[str, BasePlugin] {} def register(self, plugin: BasePlugin) - None: if plugin.name in self._plugins: raise ValueError(f插件 {plugin.name} 已存在请勿重复注册) self._plugins[plugin.name] plugin def unregister(self, name: str) - None: self._plugins.pop(name, None) def get(self, name: str) - Optional[BasePlugin]: return self._plugins.get(name) def all_plugins(self) - Dict[str, BasePlugin]: return dict(self._plugins) def prompt_desc(self) - str: 生成模型可读的插件列表描述。 lines [] for name, plugin in self._plugins.items(): params_desc , .join(plugin.parameters.keys()) or 无 lines.append(f- {name}: {plugin.description}参数{params_desc}) return \n.join(lines)注册表本身不关心插件是怎么实现的只负责存储和查询。prompt_desc方法把插件列表格式化成自然语言方便拼接进系统提示词。4.2 实现内置工具插件文件agent/plugins/tool_plugins.pyimport datetime from typing import Any, Dict from agent.core import BasePlugin, PluginContext, PluginResult class TimePlugin(BasePlugin): 查询当前时间。 name get_current_time description 获取当前日期和时间当用户询问现在几点、今天几号时使用 parameters { format: { type: string, description: 时间格式可选 iso 或 cn, required: False, } } def execute(self, params: Dict[str, Any], context: PluginContext) - PluginResult: fmt params.get(format, iso) now datetime.datetime.now() if fmt cn: return PluginResult(successTrue, datanow.strftime(%Y年%m月%d日 %H:%M:%S)) return PluginResult(successTrue, datanow.isoformat()) class CalculatorPlugin(BasePlugin): 四则运算计算器。 name calculator description 执行简单的四则运算当用户要求数学计算时使用。例如 12 * 34 parameters { expression: { type: string, description: 数学表达式例如 12 * 34, required: True, } } def execute(self, params: Dict[str, Any], context: PluginContext) - PluginResult: expr params.get(expression, ) # 安全校验只允许数字、空白和四则运算符号 allowed_chars set(0123456789-*/(). ) if not set(expr).issubset(allowed_chars): return PluginResult(successFalse, error表达式包含非法字符) try: # 使用 eval 有安全隐患仅限演示生产环境请使用表达式解析库 result eval(expr, {__builtins__: {}}, {}) return PluginResult(successTrue, dataresult) except Exception as e: return PluginResult(successFalse, errorf表达式计算失败{e})说明几个细节。TimePlugin演示了带可选参数的插件。CalculatorPlugin演示了参数校验和错误返回。表达式计算直接用eval在真实项目里非常危险这里只是为了跑通演示流程后面会在最佳实践里再强调安全问题。4.3 实现大模型调用插件在插件化架构里大模型本身也可以是一个插件。这样做的好处是业务代码不需要关心模型是哪家的、接口长什么样只要通过插件名称调用就行。文件agent/plugins/llm_plugin.pyimport os from typing import Any, Dict, List from openai import OpenAI from agent.core import BasePlugin, PluginContext, PluginResult class LLMPlugin(BasePlugin): 大模型调用插件基于 OpenAI 兼容接口实现。 name llm description 调用大模型进行自然语言理解和生成 parameters { messages: { type: list, description: 消息列表包含 role 和 content, required: True, } } def __init__(self, config: Dict[str, Any] None): super().__init__(config) api_key self.config.get(api_key) or os.getenv(LLM_API_KEY) base_url self.config.get(base_url) or os.getenv(LLM_BASE_URL) self.model self.config.get(model) or os.getenv(LLM_MODEL, deepseek-chat) self.client OpenAI(api_keyapi_key, base_urlbase_url) def chat(self, messages: List[Dict[str, str]]) - str: resp self.client.chat.completions.create( modelself.model, messagesmessages, temperature0.3, ) return resp.choices[0].message.content def execute(self, params: Dict[str, Any], context: PluginContext) - PluginResult: messages params.get(messages, []) try: content self.chat(messages) return PluginResult(successTrue, datacontent) except Exception as e: return PluginResult(successFalse, errorf大模型调用失败{e})这里保留了execute方法方便和主循环统一调用同时增加了一个chat方法作为更语义化的接口。OpenAI 库只要设置了base_url就可以对接所有兼容 OpenAI 协议的模型服务。4.4 实现 Agent 主调度循环现在把框架骨架搭起来。为了不依赖特定的模型函数调用能力示例采用一种简单的文本协议模型输出如果包含[[插件名(参数)]]就认为需要调用工具否则视为最终回复。文件main.pyimport os import re import ast from dotenv import load_dotenv from agent.core import PluginContext from agent.registry import PluginRegistry from agent.plugins.tool_plugins import TimePlugin, CalculatorPlugin from agent.plugins.llm_plugin import LLMPlugin load_dotenv() # 初始化注册表 registry PluginRegistry() registry.register(TimePlugin()) registry.register(CalculatorPlugin()) llm_plugin LLMPlugin() registry.register(llm_plugin) SYSTEM_PROMPT 你是一个运行在插件化框架中的智能体。 当前可用插件如下 {plugins} 当用户的问题需要工具能力时你必须只输出以下格式不要输出任何多余内容 [[插件名(参数名参数值)]] 例如需要查询时间时输出 [[get_current_time(formatiso)]] 当用户的问题不需要工具能力或者工具结果已经足够回答问题时直接输出最终答案。 注意一次只能调用一个插件等结果返回后再继续。 TOOL_CALL_PATTERN re.compile(r\[\[(\w)\(([^)]*)\)\]\]) def parse_tool_call(text: str): match TOOL_CALL_PATTERN.search(text) if not match: return None plugin_name match.group(1) param_str match.group(2) params {} if param_str.strip(): try: params ast.literal_eval(f{{{param_str}}}) except Exception: # 简易解析kv 形式 for seg in param_str.split(,): if in seg: k, v seg.strip().split(, 1) params[k.strip()] v.strip().strip(\) return plugin_name, params def build_messages(history: list, user_input: str) - list: messages [{role: system, content: SYSTEM_PROMPT.format( pluginsregistry.prompt_desc() )}] messages.extend(history) messages.append({role: user, content: user_input}) return messages def run_agent(user_input: str, session_id: str demo): context PluginContext(session_idsession_id) history [] max_steps int(os.getenv(AGENT_MAX_STEPS, 5)) current_input user_input final_answer None for step in range(max_steps): print(f\n Step {step 1} ) messages build_messages(history, current_input) result llm_plugin.execute({messages: messages}, context) if not result.success: return f[LLM 错误] {result.error} model_output result.data print(f[模型输出] {model_output}) tool_call parse_tool_call(model_output) if tool_call is None: final_answer model_output break plugin_name, params tool_call plugin registry.get(plugin_name) if plugin is None: final_answer f找不到插件{plugin_name} break tool_result plugin.execute(params, context) print(f[工具结果] {plugin_name} - {tool_result.data if tool_result.success else tool_result.error}) history.append({role: user, content: current_input}) history.append({role: assistant, content: model_output}) # 把工具结果拼接成新的 user 消息继续让模型判断 current_input f{tool_result.to_prompt()} 现在请基于工具结果回答用户最初的问题{user_input} if final_answer is None: final_answer 达到最大步骤数Agent 停止执行。 print(f\n 最终回答 \n{final_answer}) return final_answer if __name__ __main__: while True: user_input input(\n请输入你的问题输入 exit 退出) if user_input.strip().lower() exit: break run_agent(user_input)这段代码的核心逻辑在主循环里每次循环都用“历史消息 当前输入”构造请求。拿到模型输出后用正则判断是否包含工具调用指令。如果包含解析出插件名和参数执行插件把工具结果拼回输入。如果不包含把模型输出作为最终回答循环结束。4.5 运行与结果说明启动程序前确认.env配置正确然后执行python main.py输入一个问题帮我算一下 123 * 456然后告诉我今天是星期几预期执行流程大致如下具体输出取决于大模型生成内容 Step 1 [模型输出] [[calculator(expression123 * 456)]] [工具结果] calculator - 56088 Step 2 [模型输出] [[get_current_time(formatcn)]] [工具结果] get_current_time - 2025年01月18日 14:30:22 Step 3 [模型输出] 计算结果为 56088今天是 2025年01月18日星期六。从输出可以看到模型并不是一次性给出所有答案而是先调计算器再查时间最后综合回答。整个决策过程由模型完成但工具调用逻辑完全由框架调度。4.6 扩展一个自定义插件插件化架构的好处新增能力不需要改主循环。我们再来加一个“字符串反转”插件。在agent/plugins/tool_plugins.py末尾追加class ReversePlugin(BasePlugin): 字符串反转工具。 name reverse_string description 反转用户输入的字符串当用户要求倒序输出文本时使用 parameters { text: { type: string, description: 需要反转的字符串, required: True, } } def execute(self, params: Dict[str, Any], context: PluginContext) - PluginResult: text params.get(text, ) return PluginResult(successTrue, datatext[::-1])修改main.py中的注册部分from agent.plugins.tool_plugins import TimePlugin, CalculatorPlugin, ReversePlugin registry.register(ReversePlugin())重新运行程序输入把 hello world 反转一下模型会输出[[reverse_string(texthello world)]]插件返回dlrow olleh模型再基于结果生成最终回答。全程主循环代码零改动这就是插件化架构的扩展优势。5. 对接 DeepSeek API 与本地部署5.1 使用 OpenAI 兼容接口对接 DeepSeek本文示例使用的是 OpenAI 兼容接口。很多大模型厂商都会提供兼容层DeepSeek 开放平台也提供类似能力。只要把.env里的LLM_BASE_URL改为平台提供的接口地址LLM_MODEL改为对应模型名称即可。需要注意不同平台的模型名称、接口路径可能存在差异。写代码前先查阅官方文档确认以下几点接口地址是否以v1结尾。认证方式是否是Authorization: Bearer token。模型名称是否区分大小写。是否支持max_tokens、temperature等参数。5.2 本地部署大模型时的接入方式有些项目对数据安全要求高不能调用外部 API这时可以把模型部署到内网。常见的本地部署方案有使用vllm或ollama启动 OpenAI 兼容服务。使用推理服务网关统一暴露接口。内网 DNS 和服务发现保证接口地址稳定。本地部署完成后同样只需要修改.env中的LLM_BASE_URL和LLM_MODEL指向本地服务地址。框架代码不需要改动。需要留意的是本地部署的模型参数量受显存和内存限制。同一模型在不同硬件上的推理延迟差异很大生产环境要先做压测确认首 token 延迟和吞吐量是否满足业务需求再决定是否全量上线。5.3 密钥管理与安全建议无论对接云端 API 还是本地模型服务密钥管理都要遵守基本规范密钥放在环境变量或加密配置中心不要写在代码里。.env文件必须加入.gitignore。不同环境使用不同的 API Key权限最小化。定期轮换密钥发现问题立即吊销。如果 Agent 会调用内部系统接口建议在插件层增加额外的鉴权机制不能因为“用户通过了 Agent 入口”就默认所有插件都可以执行。6. 常见问题与排查思路问题现象常见原因解决思路调用接口返回 401API Key 错误或过期检查.env配置确认没有多余空格在平台后台查看密钥状态提示找不到模型模型名称配置错误查阅平台文档确认LLM_MODEL是否支持注意大小写模型一直输出工具调用循环不结束系统提示词约束不够或插件描述不清晰增加最大步数限制优化插件 description让模型更容易判断何时直接回答插件返回结果太长上下文超限工具结果原样塞入对话历史对工具结果做截断或摘要把不必要的 detail 放到侧存储插件执行报错但不影响主流程框架缺少错误兜底在execute层捕获异常返回PluginResult(successFalse)不要抛出到外层本地部署模型响应极慢显存不足或并发过大减少最大并发数使用量化模型增加预热必要时扩容新插件没有被调用插件没有注册或描述不明确确认registry.register(...)已执行检查prompt_desc是否包含新插件逐条说明一下最关键的几个。“模型一直调用工具”是最典型的 Agent 翻车场景。根因通常是系统提示词里没有明确“何时停止调用工具”。解决方案除了优化提示词还要在框架层设置硬性最大步数防止无限循环消耗费用。“插件返回结果太长”也很常见。比如数据库插件返回 500 行记录模型根本不需要这么多内容。更合理的做法是插件只返回摘要或前 N 条用户需要更多信息时再调用另一个查询插件。7. 最佳实践与工程建议7.1 插件描述决定模型能否正确调用插件代码写得再好如果description含糊模型也不会正确调用。描述要包含“插件是做什么的”和“什么场景下使用”。例如description 获取指定城市的实时天气当用户询问天气、温度、降雨时使用不要写description 天气插件模型是通过文本理解来决策的描述越具体工具调用的准确率越高。7.2 插件参数需要严格校验parameters声明是给模型看的但插件执行时不能完全信任模型生成的参数。模型输出的参数格式可能不合法也可能包含恶意内容。生产环境建议使用pydantic声明参数模型统一做类型校验和范围校验。7.3 工具代码必须做安全隔离像示例里的eval表达式计算在真实项目里绝对不能直接使用。真实场景推荐使用asteval、py-expression等安全解析库。所有外部工具调用放到独立进程或容器中执行。设置超时时间防止插件挂死。插件访问数据库或文件系统时使用最小权限账号。7.4 插件注册表要支持动态加载与灰度小项目把所有插件写进同一个进程没有问题但规模化以后插件会变成独立部署的微服务。注册表不只维护进程内对象还需要支持通过服务发现动态增删插件。每个插件走独立版本控制灰度发布时先在小流量会话中验证再全量开放。7.5 上下文管理要有策略不要把所有历史消息无脑传给模型。推荐策略只保留最近 N 轮对话。工具结果截断到固定长度。关键信息写入长期记忆新会话开始时自动加载。定期清理系统提示词中已下线插件的描述。7.6 日志与可观测性生产 Agent 的排错能力直接决定项目存活率。需要记录的关键信息包括每次模型请求的耗时与 token 用量。模型输出内容。插件调用参数与返回结果。主循环步数。上下文长度变化。建议为每个会话生成唯一 trace ID贯穿所有日志方便后续检索。大模型接口调用经常出现延迟波动日志里最好记录响应时间分布。7.7 成本控制Agent 多轮工具调用会放大 token 消耗。一次简单问答如果中间调用了 3 次工具token 消耗可能是普通对话的 5 到 10 倍。上线前要做成本估算设置单会话最大步数和 token 上限还可以对工具结果做缓存相同参数直接返回历史结果。8. 总结与下一步学习方向这篇文章从智能体开发的工程痛点出发拆解了“一切皆插件”设计范式的核心思路然后用一个可运行的最小项目演示了插件基类、注册表、工具插件、大模型插件和主调度循环的实现方式。理解这套代码以后你会发现智能体框架的本质并不神秘模型负责决策插件负责能力框架负责流程控制与资源管理。接下来可以按这个路径继续深入把工具调用协议从“文本正则解析”升级为模型原生的 Function Calling减少解析错误。增加长期记忆插件接入向量数据库让 Agent 记住用户偏好。研究多智能体协作每个智能体也是一个插件由路由智能体决定把任务分发给谁。关注 DeepSeek 官方仓库和文档看它的插件协议、事件模型和内置插件实现对照本文的架构理解差异。实际项目中优先关注三件事插件权限边界、上下文长度控制、调用成本监控。这三件事做好Agent 才有资格从 Demo 走向生产环境。现在就可以动手改代码了。先给示例项目加一个你自己业务场景的插件比如“查订单状态”或者“读数据库”跑通一次完整的工具调用链路然后再考虑扩展更多复杂能力。