Agent 开发正从“原型验证”走向“工程落地”而模块化管理是这轮演进里绕不开的关键词。无论是社区里高频出现的 Hermes Studio、Agent 框架选型还是围绕 Skill、MCP、多 Agent 协作的讨论背后其实都指向同一个诉求Agent 不能再用一个巨大 Prompt 和一堆 if-else 硬撑下去。本文会从 Agent 模块化管理的概念、核心模块拆分、配置驱动组装、最小可运行示例到常见报错和工程最佳实践做一次完整的梳理。理论与实践都会覆盖适合正在入门 Agent 开发、或者已经在项目里被单体 Agent 维护成本困扰的同学阅读。1. 背景Agent 开发为什么需要模块化管理1.1 单体 Agent 带来的维护困境先看一个很常见的开发场景。项目早期我们把系统提示词、工具函数、上下文拼接逻辑全部写在一个 Python 文件或一个 Prompt 文件里。业务简单时还能跑通但随着工具数量变多、记忆策略变复杂问题会集中爆发Prompt 越来越长改任何一个功能都可能牵动全局。工具函数直接写在业务逻辑里新增工具需要频繁修改核心代码。记忆管理的代码和对话流程耦合在一起排查一次“模型为什么答非所问”要翻好几层调用链。多个子任务不能灵活复用新功能只能复制粘贴导致代码重复率迅速上升。这些问题其实和传统后端开发里“巨石应用”带来的痛苦非常相似。Agent 本质上是复杂业务逻辑的载体当它承载的任务变多时模块化就不再是架构上的“讲究”而是一个实际的效率与可维护性问题。1.2 Agent 模块化管理的价值模块化管理的核心思路是把 Agent 按职责拆成多个相对独立的模块每个模块只负责一件明确的事再通过统一的接口和编排机制把它们组合起来。这样做至少带来三方面收益可复用性。记忆模块、工具注册模块、安全校验模块可以跨项目复用换模型、换场景时不需要重写整份 Agent。可测试性。每个模块可以单独写单元测试定位问题不需要再跑通完整对话链路。可观测性与可控性。模块边界清晰后日志、权限、审计可以按模块维度独立配置对生产环境尤其重要。从社区讨论来看越来越多的 Agent 项目开始引入模块化管理说明这已经成为 Agent 工程化的普遍趋势而不只是某一个项目的内部设计选择。1.3 本文的讲解范围本文不会只停留在概念层面。接下来会先梳理 Agent 模块化涉及的核心概念再解读当前社区关注的热点问题然后给出一个不依赖特定框架的最小可运行示例最后补充常见问题排查和工程建议。Hermes Studio 的相关内容会结合公开信息做介绍但更核心的是从通用架构视角讲清楚模块化管理怎么做。2. 核心概念Agent、模块化、Skill 与 Tool 的边界2.1 先理解 Agent 是什么用通俗的话说Agent 是一个能感知环境、做出决策、调用工具并完成任务的智能体。和专业定义比起来日常开发中我们更关注它的外在表现给定一个目标Agent 能自动拆解步骤决定每一步是直接回复、查数据库、调接口还是请求用户补充信息。理解 Agent 时有一个容易混淆的点Agent 不等于大模型。大模型是 Agent 的“大脑”负责理解和生成Agent 则是包裹在大模型外围的一套工程系统负责计划、记忆、工具调用、结果校验和异常处理。这也是为什么 Agent 开发越来越像后端工程而不只是面向 Prompt 的提示词工程。2.2 Skill、Tool、MCP 如何区分在 Agent 相关讨论中Skill、Tool、MCP 是高频词但它们的分工并不一样。Tool 是最基础的能力单元可以理解为 Agent 可以调用的一个函数或 API比如“查询订单状态”“发送邮件”“执行一段 SQL”。Skill 通常指面向特定场景封装的一组能力集合可能包含多个 Tool、一段 Prompt 模板、必要的参数校验逻辑。比如“订单处理 Skill”可以是查询订单、修改订单、通知用户等多个 Tool 的组合。MCPModel Context Protocol则是一种标准化协议它解决的是“Agent 如何统一发现和调用外部工具”的通信问题。可以把它理解为 Tool 与 Agent 之间的一套通用接口规范。在模块化管理的视角里Tool 是原子能力Skill 是场景化组合MCP 是跨系统集成的标准化通道。三者不是竞争关系而是不同层次的抽象。2.3 模块化管理的核心要素模块化管理要求我们把 Agent 拆成几类模块规划模块负责拆解目标、生成执行计划。记忆模块负责短期对话上下文和长期知识存储。工具模块负责注册、校验、调用外部能力。执行模块负责驱动大模型、执行计划、处理中间结果。安全与审计模块负责权限校验、敏感操作拦截、日志记录。配置管理模块负责把上面这些模块按场景组合起来。这些模块之间通过定义清晰的接口通信而不是互相直接调用内部实现。配置驱动是实现这种松耦合的关键手段。2.4 模块化与多 Agent 的关系搜索热词里频繁出现“多 Agent 协作”“主从模式”“把 subagent 当作另类 tool 调用”这其实和模块化是同一件事的两个层次。模块化解决的是单个 Agent 内部结构的清晰度多 Agent 则解决的是多个 Agent 之间的协作方式。两者都强调“边界清晰、职责单一、接口统一”。有一种常见的多 Agent 设计是主从模式主 Agent 负责任务拆解和调度子 Agent 像工具一样被调用。这种模式在实现层面非常依赖底层模块化设计因为每个子 Agent 本身必须是一个可被独立创建、配置和销毁的模块否则主从协作很快就会变成互相嵌套的混乱调用链。3. 从社区热门问题看 Agent 开发的真实痛点3.1 高频问题汇聚出的趋势观察近期的技术热搜词可以明显看到 Agent 开发的热度已经从“Agent 是什么”转向“Agent 工程怎么做”。下面这些关键词出现频率最高关键词类型具体例子代表问题框架选型Agent 框架、Hermes Agent、Agent 框架与编排用什么框架搭 Agent如何选型开发路线Agent 开发学习路线、Agent 从入门到精通、Agent 面经新手如何系统学习 Agent 开发核心机制Agent 记忆、Agent 安全、Agent 架构、Agent 编排记忆怎么做、安全边界怎么划工程实践Agent 部署、Agent 获客转化、ES Rest API 日志分析Agent 在真实业务中怎么落地多 Agent多 Agent 协作、主从模式、subagent 调用多 Agent 之间如何协作不混乱工具生态Skill 与 MCP 的区别、Agent Skill、Tool 注册工具能力如何组织与标准化这些问题的共性其实很明确Agent 开发正在从“写一个能跑通的 Demo”过渡到“写一个能上线、能维护、能扩展的系统”。而模块化管理恰好是回应这些问题的系统性方案。3.2 Agent 执行不响应问题为何高频热搜词里有一句非常具体“the agent execution provider did not respond in time. this may indicate the...”。很多 Agent 开发者在实际运行中都遇到过类似超时问题。这类报错的常见原因有大模型 API 调用超时但 Agent 没有重试机制。工具调用卡在某个外部服务上没有设置超时。上下文过长导致响应时间增加。编排逻辑陷入循环Agent 反复规划却无法进入执行阶段。如果整个 Agent 是单体结构排查这类问题会非常痛苦因为你只能靠日志一行行猜。如果采用模块化管理则可以把“模型调用”“工具调用”“执行计划”分别隔离开针对每个模块单独配置超时、重试和熔断问题定位和修复都会快很多。3.3 为什么模块化管理是这些问题的公约数换个角度看Agent 开发中遇到的大多数问题都能归因到“职责边界不清晰”。记忆混在业务逻辑里工具调用散落在各处安全校验重复且不统一这些问题在单体结构里根深蒂固。模块化管理不直接解决每一个技术细节但它通过划定边界、统一接口、配置驱动让每个具体问题都有了一个明确的归属模块和排查入口。这也是未来 Agent 框架发展的一个重要方向。4. Hermes Studio 的 Agent 模块化探索4.1 Hermes Studio 与 Agent 开发的关系根据社区公开信息和项目动态Hermes Studio 是一个面向 Agent 开发方向持续迭代的工具链项目。围绕它的讨论往往涉及 Hermes Agent、Agent 框架、Agent 编排等话题可以看出它瞄准的正是 Agent 在设计、开发和运行管理环节的工程化问题。需要说明的是工具类项目在迭代阶段能力变化较快且不同来源的公开信息存在差异。本文不展开具体版本功能细节重点从架构方向上理解它正在做的 Agent 模块化管理。4.2 它选择的模块化方向从项目动态和社区讨论可以梳理出以下几个方向这些方向也是 Agent 工程化目前普遍关注的重点模块化的 Agent 构建流程。把 Agent 的定义从代码中解耦通过配置或可视化方式描述模块组成。标准化的工具与技能接入方式。对 Tool 和 Skill 提供统一注册、发现和调用机制降低外部能力接入成本。可观测性与运行管理。关注 Agent 运行时的日志、监控、审计让生产环境里的 Agent 可以被追踪和治理。多 Agent 协作的编排支持。通过模块化管理降低多个 Agent 之间的耦合支持主从、路由、并行等协作模式。这些方向都不是孤立的它们共同指向一个目标让 Agent 从“实验品”变成“可运营的软件系统”。4.3 对开发者的启示无论 Hermes Studio 最终以什么样的形式呈现它关注的模块化管理问题对普通开发者都有借鉴意义。我们在自己的项目里同样可以按照模块化思路来设计 Agent不一定要依赖特定框架。掌握 Agent 的模块化设计能力比只会调用某一个框架的 API 更有长期价值因为框架会迭代而合理的架构思想是稳定的底层能力。5. 模块化 Agent 架构设计从单体到可编排模块5.1 核心模块如何划分一个适合模块化管理的 Agent 系统通常可以拆成下面几个核心模块。规划模块Planner 规划模块负责把用户目标拆解成可执行步骤。它接收任务描述和当前状态输出一个有序或可并行的执行计划。设计时要注意规划模块不应该直接执行工具调用它只负责生成计划执行交给执行模块。记忆模块Memory 记忆模块负责管理 Agent 的上下文信息。在实践中通常会区分短期记忆和长期记忆。短期记忆对应对话窗口内的上下文长期记忆则可能存到向量数据库或传统数据库中。模块化的好处是可以随时更换记忆底层存储而不影响其他模块。工具模块Tool / Skill 工具模块是 Agent 能力的延伸。它维护一个注册表每个工具都有名称、描述、参数结构和执行函数。Skill 在这个模块里作为工具的组合出现一个 Skill 内部可以编排多个 Tool但对外暴露统一的调用入口。执行模块Executor 执行模块是 Agent 的“引擎”它负责驱动大模型、执行规划模块生成的计划、调用工具模块并把结果反馈给规划模块做下一步判断。执行模块是所有模块中与大模型交互最频繁的部分。安全与审计模块Guard / Audit 安全模块在工具调用前后做校验例如权限检查、参数白名单、敏感操作拦截。审计模块记录每次关键操作的日志方便追溯和排查。配置管理模块Config Manager 配置管理模块负责把上述模块按照特定场景组装成可运行的 Agent 实例。通过配置文件或配置中心开发者可以在不修改代码的情况下切换模型、调整记忆策略、增删工具。5.2 模块间如何通信与编排模块间通信遵循一个基本原则模块之间不直接访问内部实现只通过接口调用。不过考虑到实际项目的复杂程度不同模块之间的调用方式可以灵活调整。在单 Agent 内部通常采用顺序调用和路由调用两种方式顺序调用规划模块生成计划后执行模块按顺序逐条执行每一步都依赖上一步的结果。路由调用根据任务类型动态决定使用记忆模块、工具模块还是子 Agent 模块。在模块化基础上做多 Agent 协作时编排模式可以进一步细分顺序模式多个 Agent 按固定顺序执行前一个 Agent 的输出是后一个 Agent 的输入。并行模式多个 Agent 同时处理互不依赖的子任务。路由模式主 Agent 根据任务内容动态选择子 Agent 处理。主从模式主 Agent 负责统一调度子 Agent 通过标准接口被调用这种方式在实现上可以看作把子 Agent 当作特殊工具进行调用。5.3 配置驱动的模块组装方式模块化设计强调配置驱动目的是让 Agent 的组装过程变成一个声明式过程。下面是一个简化示例展示如何通过 YAML 配置文件描述一个 Agent 的模块组成agent: name: order_assistant model: provider: openai name: gpt-4o temperature: 0.2 modules: planner: enabled: true max_steps: 5 memory: type: short_term max_tokens: 3000 tools: - name: query_order endpoint: http://internal-api/order/query - name: refund_order endpoint: http://internal-api/order/refund permission_required: order_admin guard: enabled: true blocked_actions: - delete_order executor: max_retries: 2 timeout_seconds: 30这里面的重点是模块的启停、参数调整、权限配置都通过配置项控制而不是硬编码在代码逻辑里。不同环境的配置差异也通过配置文件隔离。6. 模块化 Agent 实战一个可运行的最小示例这一节给出一个不依赖特定框架的 Python 示例。为了能本地运行示例用简单规则模拟了大模型的调用实际项目中只需要替换为真实的模型 API 调用即可。6.1 项目结构规划modular_agent/ ├── agent/ │ ├── __init__.py │ ├── base.py # 模块基础接口 │ ├── planner.py # 规划模块 │ ├── memory.py # 记忆模块 │ ├── tool_registry.py # 工具注册模块 │ ├── executor.py # 执行模块 │ └── agent.py # Agent 组装 ├── tools/ │ ├── __init__.py │ └── order_tools.py # 示例工具 ├── config/ │ └── agent.yaml # Agent 配置文件 └── main.py # 启动入口6.2 定义模块基础接口所有模块都继承 BaseModule统一初始化方法和元数据描述能力。这样后续新增模块时只要按这套接口实现即可。# 文件路径modular_agent/agent/base.py from abc import ABC, abstractmethod from typing import Any, Dict class BaseModule(ABC): 所有 Agent 模块的基类。 模块之间不直接访问内部实现统一通过这里的接口通信。 def __init__(self, config: Dict[str, Any]): self.config config or {} self.name self.config.get(name, self.__class__.__name__) abstractmethod def run(self, *args, **kwargs): 执行模块的核心逻辑由子类实现。 raise NotImplementedError def get_meta(self) - Dict[str, Any]: 返回模块元数据用于日志和调试。 return { name: self.name, type: self.__class__.__name__, }6.3 实现记忆模块记忆模块维护短期对话上下文并提供读取和追加能力。为了节约内存这里简单限制最大条数实际项目中可以根据 token 数或时间窗口来控制。# 文件路径modular_agent/agent/memory.py from typing import Any, Dict, List from .base import BaseModule class ShortTermMemory(BaseModule): 基于列表的短期记忆模块记录最近 N 条消息。 def __init__(self, config: Dict[str, Any]): super().__init__(config) self.max_messages int(self.config.get(max_messages, 10)) self._messages: List[Dict[str, str]] [] def add_message(self, role: str, content: str) - None: self._messages.append({ role: role, content: content, }) if len(self._messages) self.max_messages: self._messages self._messages[-self.max_messages:] def get_messages(self) - List[Dict[str, str]]: return self._messages def clear(self) - None: self._messages [] def run(self, *args, **kwargs): # 记忆模块的 run 方法在实际项目里可以返回给 Agent 使用的上下文 return self.get_messages()6.4 实现工具注册模块工具模块维护一个注册表每个工具包含名称、描述和可调用函数。这样新增工具时不需要修改 Agent 核心逻辑只需要调用注册方法。# 文件路径modular_agent/agent/tool_registry.py from typing import Any, Callable, Dict, Optional from .base import BaseModule class ToolRegistry(BaseModule): 工具注册模块负责工具的统一注册和调用。 def __init__(self, config: Dict[str, Any]): super().__init__(config) self._tools: Dict[str, Dict[str, Any]] {} def register_tool(self, name: str, description: str, func: Callable, **kwargs) - None: if name in self._tools: raise ValueError(fTool {name} already registered) self._tools[name] { name: name, description: description, func: func, params: kwargs, } def list_tools(self) - list: return [{name: t[name], description: t[description]} for t in self._tools.values()] def call_tool(self, name: str, *args, **kwargs) - Any: if name not in self._tools: raise KeyError(fTool {name} not found) return self._tools[name][func](*args, **kwargs) def run(self, *args, **kwargs): return self.list_tools()6.5 实现规划模块和执行模块规划模块根据任务内容返回一个简单的执行计划。示例中直接规则匹配实际项目可以由大模型动态生成计划。# 文件路径modular_agent/agent/planner.py from typing import Any, Dict, List from .base import BaseModule class SimplePlanner(BaseModule): 简单规划模块根据关键词生成执行步骤。 def __init__(self, config: Dict[str, Any]): super().__init__(config) self.max_steps int(self.config.get(max_steps, 5)) def plan(self, task: str) - List[str]: # 一个很简单的规则包含“订单”则先查询订单信息 # 实际项目中这里是 LLM Plan 的调用点 if 订单 in task or order in task.lower(): return [query_order] return [reply] def run(self, *args, **kwargs): return self.plan(kwargs.get(task, ))执行模块是整个示例的核心它把规划结果和工具调用串联起来。# 文件路径modular_agent/agent/executor.py from typing import Any, Dict from .base import BaseModule from .memory import ShortTermMemory from .tool_registry import ToolRegistry class Executor(BaseModule): 执行模块负责执行计划并调用工具。 def __init__(self, config: Dict[str, Any], tools: ToolRegistry, memory: ShortTermMemory): super().__init__(config) self.tools tools self.memory memory self.max_retries int(self.config.get(max_retries, 1)) self.timeout_seconds int(self.config.get(timeout_seconds, 10)) def execute_plan(self, plan: list, user_input: str) - str: results [] for step in plan: # 每一步执行前先尝试调用工具工具不存在时返回提示 if step reply: results.append(这是一个普通回复不需要调用工具。) continue try: result self.tools.call_tool(step, queryuser_input) results.append(f工具 {step} 返回: {result}) except KeyError: results.append(f工具 {step} 未注册) except Exception as exc: results.append(f工具 {step} 调出异常: {exc}) return \n.join(results) def run(self, *args, **kwargs): plan kwargs.get(plan, []) user_input kwargs.get(user_input, ) return self.execute_plan(plan, user_input)6.6 实现 Agent 组装类Agent 组装类负责把记忆、工具、规划、执行等模块组合成一个可用的整体。# 文件路径modular_agent/agent/agent.py from typing import Dict, Any from .planner import SimplePlanner from .memory import ShortTermMemory from .tool_registry import ToolRegistry from .executor import Executor class ModularAgent: 组装模块的 Agent 入口。 def __init__(self, config: Dict[str, Any]): self.config config self.memory ShortTermMemory(config.get(memory, {})) self.tools ToolRegistry(config.get(tools, {})) self.planner SimplePlanner(config.get(planner, {})) self.executor Executor(config.get(executor, {}), self.tools, self.memory) # 注册默认工具 self._register_default_tools() def _register_default_tools(self): from tools.order_tools import query_order # 局部导入避免循环 self.tools.register_tool( namequery_order, description查询订单信息, funcquery_order, ) def chat(self, user_input: str) - str: self.memory.add_message(user, user_input) plan self.planner.plan(user_input) response self.executor.execute_plan(plan, user_input) self.memory.add_message(assistant, response) return response def get_context(self): return self.memory.get_messages()6.7 提供示例工具函数# 文件路径modular_agent/tools/order_tools.py from typing import Any def query_order(query: str) - str: 模拟查询订单接口实际项目替换为真实 HTTP 调用即可。 if A100 in query: return 订单 A100 状态已发货 return f未找到与 {query} 相关的订单6.8 运行与验证在项目根目录创建 main.py# 文件路径modular_agent/main.py from agent.agent import ModularAgent def main(): agent_config { memory: {max_messages: 10}, planner: {max_steps: 5}, tools: {}, executor: {max_retries: 2, timeout_seconds: 30}, } agent ModularAgent(agent_config) print(agent.chat(帮我查一下订单 A100)) print(agent.chat(今天天气怎么样)) print(当前上下文条数:, len(agent.get_context())) if __name__ __main__: main()运行命令cd modular_agent python main.py预期输出工具 query_order 返回: 订单 A100 状态已发货 这是一个普通回复不需要调用工具。 当前上下文条数: 4这个示例展示了模块化设计的基本思路用户输入先进记忆模块规划模块决定调用哪个工具执行模块统一执行最后把结果再写回记忆模块。每个模块都可以单独替换或扩展这正是模块化管理的核心价值。7. 常见问题与排查思路7.1 Agent 执行超时或 Provider 不响应搜索热词中出现过的“the agent execution provider did not respond in time”是一类典型的执行超时问题。问题现象常见原因解决思路模型调用长时间无响应大模型 API 超时时间设置过短或网络不稳定在 Executor 模块中增加超时和重试配置工具调用卡住外部服务响应慢未设置超时给工具调用增加统一超时控制上下文过长导致响应慢记忆模块没有做裁剪设置上下文窗口上限超限时自动摘要或丢弃排查这类问题的方法是看日志里卡在了哪个环节。模块化设计的好处是每个模块有独立的超时配置能快速缩小范围。7.2 模块依赖关系混乱新同学在实现模块化时容易犯的一个错误是模块 A 直接 import 模块 B 的内部函数模块 B 又引用模块 A 的配置最后形成循环依赖代码很难维护。解决思路是让模块之间的依赖都通过接口或依赖注入完成。例如在上面的示例中Executor 依赖 ToolRegistry 和 Memory但它是通过构造函数注入的而不是在模块内部直接 new 一个 ToolRegistry。这样模块之间的耦合是单向且清晰的。7.3 工具注册重复或冲突在 ToolRegistry 的实现中重复注册同名工具会抛出 ValueError。实际项目中建议在 Agent 启动阶段做一次工具完整性校验确保所有配置里声明的工具都注册成功。否则运行到一半才发现工具缺失会白白消耗大模型调用成本。7.4 记忆模块无限增长如果不限制记忆条数长时间运行的 Agent 会积累越来越多的上下文最终超过模型输入限制。建议在实际实现中加入 token 数统计和会话裁剪策略例如只保留最近 N 轮对话或者对早期对话做摘要压缩。7.5 安全配置不生效安全模块是 Agent 模块化管理中比较容易忽略的部分。有些项目把所有工具都配置为可调用没有区分普通操作和敏感操作。建议在工具注册时显式声明权限级别并在 Executor 调用工具前经过 Guard 模块校验而不是在工具函数内部临时判断。8. 最佳实践与工程建议8.1 配置与代码分离模块化管理最重要的工程原则就是配置与代码分离。Agent 的模型选择、记忆策略、工具列表、权限配置都应该放在配置文件里而不是写死在 Python 代码中。这样不同环境、不同客户可以通过配置快速组装出不同的 Agent 实例。8.2 模块接口保持稳定模块拆分的粒度要有收放。拆得太细模块数量膨胀接口通信成本高拆得太粗模块内部仍然是大杂烩。建议遵循“一个模块一个职责”的原则对外暴露的接口尽量稳定内部实现可以自由变化。这样后续替换组件时只需要改一个模块。8.3 可观测性优先Agent 项目里“为什么模型返回了这个结果”是排查频率最高的问题。建议在关键位置埋入结构化日志例如规划结果、工具调用输入输出、模型 Token 消耗、异常堆栈。有条件的话还可以把 Agent 运行轨迹输出为可视化的 trace这对多 Agent 协作场景尤其重要。8.4 安全与权限最小化Agent 调用工具的时候权限校验必须前置。建议把安全模块放在执行模块之前对每个工具调用做一次权限检查。生产环境下用最小权限原则配置避免 Agent 因 Prompt 注入或异常指令触发危险操作。8.5 测试策略给每个模块写单元测试核心是模拟外部依赖。比如测试 Executor 时使用假的 memory 和 tool registry不发起真实网络请求。这样 CI 流水线跑起来又快又稳定。集成测试可以单独用一个测试环境跑完整链路但不要和单元测试混在一起。8.6 版本与兼容性管理Agent 模块化之后模块的升级和兼容性管理值得重视。建议给核心模块接口做好版本管理工具配置变更时先走配置中心灰度发布。避免出现“执行模块升级了但某个工具还是旧参数结构”这样的兼容性问题。9. 总结与学习路线本文从 Agent 开发的维护困境出发梳理了 Agent、Skill、Tool、MCP 等核心概念分析了当前 Agent 社区高频关注的问题并结合 Hermes Studio 在 Agent 模块化管理方向上的探索给出了一套通用的模块化架构设计和可运行的最小示例。希望读者读完以后不只停留在“模块化好”的认知层面而是能在自己的项目里真正动手拆分一个 Agent。如果你刚开始接触 Agent 开发学习路线可以这样规划先跑通一个最简单的 Agent理解大模型调用和 Prompt 的基本交互。引入工具调用学会把外部接口封装成 Tool。引入记忆模块理解上下文管理和消息历史裁剪。按本文的模块化思路重构项目拆分规划、记忆、工具、执行。再深入多 Agent 协作和主从编排模式理解子 Agent 与 Tool 的相似性与差异。在实际项目里优先关注的安全风险是工具权限和 Prompt 注入优先关注的稳定性风险是超时与重试机制优先关注的可维护性风险是模块间的依赖关系是否清晰。模块化不是银弹但它能让你在这些风险出现时有足够清晰的边界去定位和解决。后续可以多关注 Hermes Studio 等 Agent 工具链的动态对比它们的设计思路和本文的架构场景会有更直观的收获。