企业官网建设流程全解析

最近做智能体开发的朋友应该都有同感：大模型的能力边界其实已经比较清晰，真正容易翻车的地方往往在工程一侧。工具怎么接入、上下文怎么管理、多个智能体怎么协作、插件怎么热插拔，这些问题如果全靠自己从头搭，工作量一点都不比写业务代码小。

这段时间 DeepSeek 相关 Agent 框架的开源讨论热度很高，社区里无论是 Harness、Hermes 这类智能体项目，还是各类插件化工具，核心思路都指向同一个方向：把智能体的能力拆成插件，模型只负责决策，工程负责组装。本文不对具体开源仓库做逐行源码解读（公开资料有限），而是围绕“一切皆插件”的设计范式，拆解插件化 Agent 框架的核心架构，并带大家从零实现一个可扩展的最小 Agent 系统。学完以后，你能理解智能体框架的分层思路，能自己写插件、挂工具，也能对接 OpenAI 兼容接口的大模型服务。

1. 背景与核心概念

1.1 智能体开发为什么需要框架

很多人刚接触 Agent 时，第一反应是“调大模型接口，把用户问题丢进去，拿到结果返回”。但真实的智能体应用远不止这些。一个稍微完整一点的智能体，至少需要处理：

• 多轮对话中的上下文维护。
• 调用搜索、数据库、业务 API 等外部工具。
• 根据模型输出决定下一步动作，而不是一次对话就结束。
• 错误重试、超时控制、日志追踪。
• 多个智能体之间的协作与编排。

这些能力如果全部写在业务代码里，项目很快就会变成一个大杂烩。今天接了一个搜索工具，明天要加一个天气插件，后天又要换成另一个大模型，每次改动都可能牵一发动全身。

Agent 框架要解决的核心问题，就是把“模型能力”和“工程能力”解耦。模型负责理解用户意图、生成回复、决定调用哪个工具；框架负责工具的注册与调用、上下文存储、执行流程控制、日志和监控。DeepSeek 这套开源 Agent 框架受关注度高，正是因为它把这种解耦做到了比较彻底的程度：不只工具可以做成插件，模型、记忆、后处理逻辑也全部插件化。

1.2 “一切皆插件”到底是什么意思

插件化架构在 IDE、构建工具、浏览器里已经很常见。VS Code 的插件体系、Chrome 扩展、Maven 插件，都是把某种能力封装成独立单元，通过统一接口挂载到主程序上。

Agent 框架里的“一切皆插件”，思路类似，但它把插件化的范围扩大了很多：

所以“一切皆插件”不是把代码拆得细一点那么简单，而是从架构层面重新划定了边界。插件与插件之间通过协议通信，插件不关心其他插件是怎么实现的，只关心自己收到的输入和需要返回的输出。

这种设计的直接好处是生态化。官方只需要维护一套稳定协议和少量内置插件，社区可以围绕这个协议贡献大量插件。用户不需要自己实现复杂逻辑，只需要“装插件”。

1.3 Agent 框架、插件与工作流编排的关系

这里需要区分三个容易混淆的概念。

Agent 框架是底座，负责主循环、事件分发、状态管理、插件生命周期管理。它本身不解决具体业务问题，只是提供一套运行环境。

插件是能力的载体，比如“天气查询插件”“数据库查询插件”“长时记忆插件”。插件实现具体功能，并声明自己可以被框架调用。

工作流编排是更高层的应用方式，它决定“什么时候调用哪个插件”“插件返回结果后下一步做什么”。在插件化 Agent 框架中，编排本身也可以做成插件，这样就可以在不停机的情况下调整智能体的行为。

理解这三层关系以后，后面看架构设计就会清楚很多。

2. 插件化 Agent 框架的架构设计

2.1 整体分层

一个典型的插件化 Agent 框架，通常会分成下面几层：

用户输入 ↓ [接入层] 处理用户消息格式、权限校验、会话识别 ↓ [模型决策层] 大模型根据上下文和插件清单，决定调用哪个插件或直接回复 ↓ [插件路由层] 解析模型输出，匹配插件，校验参数 ↓ [插件执行层] 执行插件代码，返回结构化结果 ↓ [记忆层] 追加上下文，保存关键信息 ↓ [输出层] 生成最终回复返回用户

纵向贯穿所有层的是事件总线和日志追踪。每一层都通过事件通知框架“我开始了”“我成功了”“我失败了”，这样上层可以决定是继续执行还是终止。

2.2 插件协议与注册机制

插件化架构最重要、也最容易设计失败的是插件协议。协议定义得不清晰，后面每个插件都会写得很难受。

一个合理的插件协议至少包含以下部分：

• 插件名称：全局唯一标识。
• 插件描述：告诉模型“这个插件是干什么的”“什么时候该调用它”。
• 参数声明：插件接受哪些参数，每个参数的类型、是否必填。
• 执行方法：接收参数，返回结构化结果。
• 生命周期回调：加载时初始化、卸载时清理资源。

注册机制通常有两种。一种是启动时集中注册，框架扫描指定目录，自动加载插件；另一种是运行时动态注册，通过接口或配置文件加载。生产环境多采用“启动时扫描 + 运行时按需实例化”的方式，既能保证可控性，又能降低资源占用。

2.3 Agent 主循环与工具调用协议

传统的一次问答只需要“用户输入 → 模型输出”两步，但 Agent 需要循环执行。主循环大致可以描述为：

1. 接收用户输入，追加到上下文。
2. 把上下文和可用插件列表交给模型。
3. 模型输出结果。
4. 判断输出是最终答案还是工具调用指令。
5. 如果是工具调用，执行插件，把结果追加到上下文。
6. 回到第 2 步，让模型基于工具结果生成下一步内容。
7. 如果达到最大步数或模型输出最终答案，结束循环。

这个循环在普通代码里写起来并不复杂，但工程上要考虑很多边界条件：工具调用超时怎么办？工具返回结果太长导致上下文溢出怎么办？模型连续调用工具进入死循环怎么办？框架层把这些策略收敛成可配置项，比每个业务团队各自实现要省力得多。

2.4 记忆、上下文与可观测性

插件化框架里的记忆层比较容易被忽略，但它往往是决定智能体体验的关键。

短期记忆处理当前会话内的上下文，通常就是消息列表，但随着工具调用变多，上下文会膨胀很快。长期记忆负责跨会话保存用户偏好、历史结论、业务知识，通常需要向量数据库或普通数据库支持。

可观测性同样重要。生产环境里的智能体，几乎一定会出现“模型乱调用工具”“某个插件响应慢”“上下文被无关信息塞满”的问题。如果框架没有提供完整的 trace 和日志，排错会非常痛苦。这也是插件化框架比自研脚本更有价值的地方。

3. 环境准备

3.1 开发环境与依赖

为了能把上面的架构思路落到代码里，我们来实现一个最小可运行的插件化 Agent。示例使用 Python，需要准备：

版本不需要完全和本文一致，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 pydantic

3.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_KEY=sk-your-key-here # OpenAI 兼容接口地址，DeepSeek 等平台请以官方文档为准 LLM_BASE_URL=https://api.deepseek.com # 模型名称，例如 deepseek-chat LLM_MODEL=deepseek-chat # Agent 最大循环步数，防止工具调用死循环 AGENT_MAX_STEPS=5

复制一份为.env，填入自己的密钥。千万不要把.env提交到 Git 仓库。

4. 完整实战：构建一个最小插件化 Agent

下面进入核心代码部分。我们会遵循“一切皆插件”的思路，把工具、大模型都做成插件，框架层只负责任务调度。

4.1 定义插件基类与注册表

首先定义插件的公共抽象。

文件：agent/core.py

from typing import Any, Dict, List, Optional from dataclasses import dataclass, field @dataclass class PluginContext: """插件执行上下文，所有插件都能访问。""" session_id: str history: List[Dict[str, str]] = field(default_factory=list) metadata: Dict[str, Any] = field(default_factory=dict) @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.py

from 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.py

import 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(success=True, data=now.strftime("%Y年%m月%d日 %H:%M:%S")) return PluginResult(success=True, data=now.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(success=False, error="表达式包含非法字符") try: # 使用 eval 有安全隐患，仅限演示；生产环境请使用表达式解析库 result = eval(expr, {"__builtins__": {}}, {}) return PluginResult(success=True, data=result) except Exception as e: return PluginResult(success=False, error=f"表达式计算失败：{e}")

说明几个细节。

TimePlugin演示了带可选参数的插件。CalculatorPlugin演示了参数校验和错误返回。表达式计算直接用eval在真实项目里非常危险，这里只是为了跑通演示流程，后面会在最佳实践里再强调安全问题。

4.3 实现大模型调用插件

在插件化架构里，大模型本身也可以是一个插件。这样做的好处是：业务代码不需要关心模型是哪家的、接口长什么样，只要通过插件名称调用就行。

文件：agent/plugins/llm_plugin.py

import 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_key=api_key, base_url=base_url) def chat(self, messages: List[Dict[str, str]]) -> str: resp = self.client.chat.completions.create( model=self.model, messages=messages, temperature=0.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(success=True, data=content) except Exception as e: return PluginResult(success=False, error=f"大模型调用失败：{e}")

这里保留了execute方法，方便和主循环统一调用，同时增加了一个chat方法作为更语义化的接口。OpenAI 库只要设置了base_url，就可以对接所有兼容 OpenAI 协议的模型服务。

4.4 实现 Agent 主调度循环

现在把框架骨架搭起来。为了不依赖特定的模型函数调用能力，示例采用一种简单的文本协议：模型输出如果包含[[插件名(参数)]]，就认为需要调用工具；否则视为最终回复。

文件：main.py

import 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(format=iso)]] 当用户的问题不需要工具能力，或者工具结果已经足够回答问题时，直接输出最终答案。 注意：一次只能调用一个插件，等结果返回后再继续。 """ 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: # 简易解析：k=v 形式 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( plugins=registry.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_id=session_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)

这段代码的核心逻辑在主循环里：

1. 每次循环都用“历史消息 + 当前输入”构造请求。
2. 拿到模型输出后，用正则判断是否包含工具调用指令。
3. 如果包含，解析出插件名和参数，执行插件，把工具结果拼回输入。
4. 如果不包含，把模型输出作为最终回答，循环结束。

4.5 运行与结果说明

启动程序前确认.env配置正确，然后执行：

python main.py

输入一个问题：

帮我算一下 123 * 456，然后告诉我今天是星期几？

预期执行流程大致如下（具体输出取决于大模型生成内容）：

===== Step 1 ===== [模型输出] [[calculator(expression=123 * 456)]] [工具结果] calculator -> 56088 ===== Step 2 ===== [模型输出] [[get_current_time(format=cn)]] [工具结果] 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(success=True, data=text[::-1])

修改main.py中的注册部分：

from agent.plugins.tool_plugins import TimePlugin, CalculatorPlugin, ReversePlugin registry.register(ReversePlugin())

重新运行程序，输入：

把 hello world 反转一下

模型会输出[[reverse_string(text=hello 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. 常见问题与排查思路

逐条说明一下最关键的几个。

“模型一直调用工具”是最典型的 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 走向生产环境。

现在就可以动手改代码了。先给示例项目加一个你自己业务场景的插件，比如“查订单状态”或者“读数据库”，跑通一次完整的工具调用链路，然后再考虑扩展更多复杂能力。