1. 从单体到集群为什么我们需要重新思考 Agent 的构建方式过去一年里我几乎把市面上能叫得出名字的 Agent 框架都跑了一遍。从最早期那种“一个 Prompt 加几个工具函数”的玩具级实现到后来动辄几十个工具挂在一个 Agent 身上、上下文塞到爆的“巨无霸”方案踩过的坑可以说能写满一个笔记本。最让我头疼的问题始终是同一个当任务复杂度上升时单体 Agent 的能力边界会以肉眼可见的速度坍塌。具体表现是什么你给它挂二十个工具它开始乱选你让它同时处理代码生成、数据查询、文档检索三件事它会在中途“忘记”自己最初的目标你想把某个能力复用给另一个场景发现代码耦合得根本拆不开。这不是模型不够聪明的问题而是架构层面的先天缺陷——把所有的认知负荷压在一个决策单元上本身就违背了复杂系统的设计常识。于是“多智能体”这个概念被反复提起。但市面上很多所谓的多智能体本质上只是把几个 Prompt 拼在一起轮流调用既没有真正的编排能力也没有标准化的互通协议更谈不上可扩展。直到我系统性地接触到DeepAgents MCP A2A Skills这套组合拳才感觉找到了一个真正能落地的答案。这套方案的核心价值在于它把“构建 Agent 集群”这件事从手工作坊式的拼凑变成了有章法、有协议、有复用机制的工程实践。这篇文章适合谁看如果你正在做 AI Agent 相关的开发或者你所在的项目需要把多个 AI 能力整合成一条自动化流水线再或者你只是好奇“下一代 Agent 到底长什么样”那接下来的内容应该能给你不少可直接抄作业的东西。我会从整体设计思路讲到每个核心模块的实现细节再到实操中真正会遇到的坑尽量把我知道的都倒出来。2. 四层架构拆解DeepAgents、MCP、A2A、Skills 各自解决什么问题2.1 先搞清楚这四个词到底指什么很多人第一次看到这四个词并列会以为它们是同一层级的东西。其实不是它们分别处在 Agent 集群的不同层面上各司其职。我用一个生活化的类比来说明把整个 Agent 集群想象成一家公司。DeepAgents是这家公司的组织架构和管理制度。它定义了有哪些部门Agent 角色、谁向谁汇报编排关系、任务怎么流转调度逻辑。它是骨架。MCPModel Context Protocol是公司内部的“标准接口规范”。它规定了每个员工Agent 或工具怎么对外暴露自己的能力、怎么被其他人调用。有了它不管你是财务部还是技术部大家用同一套语言沟通。它是神经系统。A2AAgent to Agent是跨公司的合作机制。当你的公司需要和外部供应商协作时双方的对接方式不能靠内部规范得有一套更通用的协议。A2A 解决的就是 Agent 与 Agent 之间、尤其是跨系统跨平台的互通问题。它是外交渠道。Skills是每个员工的具体技能包。一个 Agent 会写代码、会查数据库、会做图表这些能力被封装成一个个可插拔的 Skill。它是肌肉。这四者组合起来才构成了一个可编排、可互通、可扩展的完整体系。缺了任何一个都会在某个环节卡住。2.2 为什么是这四个而不是别的组合我在选型阶段对比过不少方案。有的框架编排能力很强但工具接入很封闭有的协议设计很优雅但生态几乎为零有的 Skills 市场很热闹但缺乏统一的调用规范。DeepAgents MCP A2A Skills 这套组合之所以让我最终定下来是因为它在四个关键维度上都给出了可用的答案维度要解决的问题对应模块选它的理由编排多 Agent 如何协同完成复杂任务DeepAgents支持层级化任务分解和动态调度工具接入Agent 如何调用外部能力MCP协议标准化生态增长快跨系统互通不同平台的 Agent 如何协作A2A面向异构系统的通用通信层能力复用同一个能力如何被多个 Agent 使用Skills封装粒度清晰即插即用这个表格看起来简单但每一个维度的选择背后都有取舍。比如在工具接入这一层我一开始考虑过自己定义一套函数调用规范但很快就放弃了——因为一旦你的 Agent 需要接入第三方服务自定义规范就意味着你要为每一个服务写适配器维护成本会随着接入数量线性增长。MCP 的价值就在于它把这个适配工作标准化了服务提供方按 MCP 规范暴露能力消费方按 MCP 规范调用中间的胶水代码大幅减少。2.3 编排层DeepAgents 的核心设计逻辑DeepAgents 最让我欣赏的一点是它对“任务分解”的处理方式。传统的做法是让一个主 Agent 把任务拆成子任务然后分发给子 Agent。听起来合理但实际跑起来经常出问题主 Agent 拆得不够细子 Agent 拿到一个模糊的指令就开始瞎干或者主 Agent 拆得太细自己变成了瓶颈。DeepAgents 的思路是分层编排 动态调整。它允许你定义一个编排树树的每个节点是一个 Agent 或一个 Agent 组节点之间通过明确的输入输出契约连接。任务从上往下流动时每一层只负责自己那一层的决策不需要关心全局。这样做的好处是每个 Agent 的上下文窗口都被充分利用在真正需要它处理的信息上而不是被无关的全局状态占满。我实测下来一个三层编排结构顶层规划、中层协调、底层执行能覆盖绝大多数场景。顶层 Agent 只做任务理解和粗粒度规划中层 Agent 负责把规划拆成可执行步骤并监控执行状态底层 Agent 专注执行具体操作。每层的 Prompt 都可以针对性地优化不用在一个 Prompt 里塞进所有逻辑。2.4 互通层MCP 和 A2A 的分工与配合这两个协议经常被混淆我一开始也搞不清楚什么时候该用哪个。后来想明白了一个判断标准MCP 解决的是“Agent 怎么用工具”A2A 解决的是“Agent 怎么找 Agent”。举个例子。你的 Agent 需要查询一个数据库这是“用工具”走 MCP。你的 Agent 需要调用另一个团队开发的推荐系统 Agent这是“找 Agent”走 A2A。前者是主从关系后者是对等关系。在实际项目中这两个协议往往是配合使用的。一个典型的链路是这样的顶层 Agent 通过 A2A 发现了一个可用的“数据分析 Agent”然后这个数据分析 Agent 通过 MCP 调用数据库查询工具和图表生成工具最后把结果通过 A2A 返回给顶层 Agent。整条链路上A2A 负责 Agent 之间的发现和通信MCP 负责 Agent 与工具之间的调用。这种分工带来的一个直接好处是解耦。工具的实现可以独立于 Agent 的实现进行迭代Agent 的部署可以独立于工具的部署进行扩展。只要协议不变任何一方升级都不会影响另一方。2.5 能力层Skills 的封装哲学Skills 这个概念看起来简单但封装得好不好直接决定了整个系统的可维护性。我见过太多项目把 Skill 写成了一个巨大的函数里面什么逻辑都有参数十几个返回值结构复杂到没人愿意看第二遍。这种 Skill 本质上是一次性的根本谈不上复用。我的经验是一个好的 Skill 应该满足三个条件单一职责、明确契约、无状态。单一职责意味着一个 Skill 只做一件事比如“查询用户订单”就是一个 Skill“处理用户投诉”就不是。明确契约意味着输入输出的格式和语义都要清晰定义调用方不需要看实现就能知道怎么用。无状态意味着 Skill 不依赖任何外部上下文同样的输入永远得到同样的输出在外部依赖不变的前提下。满足这三个条件的 Skill才能真正做到即插即用。你可以把它挂到任何需要这个能力的 Agent 上不用担心引入意外的副作用。3. 核心细节深挖每个模块的关键实现要点3.1 DeepAgents 编排树的构建与调优构建编排树的第一步是确定分几层。我的建议是从两层开始只有当两层确实不够用时才加第三层。因为每增加一层通信开销和调试复杂度都会显著上升。两层结构通常是一个协调 Agent 加若干个执行 Agent。协调 Agent 负责接收任务、拆解、分发、汇总。执行 Agent 各自负责一类操作。这种结构适合任务类型相对固定的场景比如“接收用户请求 - 判断类型 - 分发给对应的处理 Agent”。三层结构适合任务本身需要动态规划的场景。顶层做战略规划中层做战术拆解底层做具体执行。比如一个自动化的市场分析任务顶层决定“先收集数据再分析趋势最后生成报告”中层把“收集数据”拆成“抓取竞品信息、查询内部销售数据、获取行业报告”底层分别执行这三个操作。调优的关键在于控制每层 Agent 的上下文长度。我踩过的一个坑是为了让顶层 Agent 做出更好的规划我把所有底层 Agent 的能力描述都塞进了它的 Prompt 里结果上下文直接爆了而且顶层 Agent 开始“越权”去指挥底层 Agent 的具体操作。后来我把顶层 Agent 的 Prompt 精简到只包含“有哪些中层 Agent 可用”和“它们各自负责什么领域”问题就解决了。实操心得编排树的每一层都应该只看到它下一层的能力摘要而不是全部细节。这和人管理团队是一个道理CEO 不需要知道每个员工的技能清单只需要知道每个部门负责人擅长什么。3.2 MCP 工具接入的标准化流程MCP 的核心价值在于它定义了一套标准的工具描述格式和调用协议。当你需要接入一个新的外部能力时流程大致是这样的能力分析明确这个工具能做什么、需要什么输入、返回什么输出。MCP Server 封装按照 MCP 规范把工具能力封装成一个 Server暴露标准的接口描述。注册与发现把 MCP Server 注册到 Agent 的工具列表中Agent 就能在需要时调用它。调用与结果处理Agent 发起调用MCP Server 执行并返回结果Agent 解析结果继续后续逻辑。这个流程看起来简单但有几个细节很容易出问题。第一个是工具描述的粒度。描述太粗Agent 不知道什么时候该用这个工具描述太细Agent 会被过多的细节干扰。我的经验是工具描述应该包含三部分一句话说明用途、输入参数的名称和类型、返回值的结构。不需要写使用示例那是文档该做的事。第二个是错误处理。MCP 调用失败时返回的错误信息必须足够清晰让 Agent 能判断是重试、换工具还是放弃。我见过很多 MCP Server 在出错时只返回一个“Internal Error”Agent 拿到这种信息完全无法决策。好的做法是返回结构化的错误码和错误描述比如“参数缺失缺少 user_id 字段”或者“服务暂时不可用建议 5 秒后重试”。第三个是超时控制。MCP 调用是跨进程甚至跨网络的必须设置合理的超时时间。超时太短正常调用也会被中断超时太长Agent 会卡在那里干等。我的经验值是本地工具 5 秒远程服务 30 秒涉及大量数据处理的可以放宽到 60 秒。超过这个时间还没返回大概率是出了问题让 Agent 走异常处理流程比干等更合理。3.3 A2A 跨 Agent 通信的落地实践A2A 的落地比 MCP 要复杂一些因为它涉及的是 Agent 之间的对等通信而不是主从调用。核心要解决的问题有三个发现、认证、通信。发现是指一个 Agent 怎么知道另一个 Agent 的存在和能力。A2A 通常通过一个注册中心来实现每个 Agent 启动时把自己的能力描述注册上去需要时从注册中心查询。这里的关键是能力描述的标准化否则查询方拿到一堆格式各异的描述根本没法自动匹配。认证是指 Agent 之间如何确认对方的身份和权限。这个环节在实际项目中经常被简化甚至忽略但我强烈建议不要省。因为一旦你的 Agent 集群对外开放没有认证机制就意味着任何 Agent 都可以调用你的 Agent这在安全和成本上都是不可接受的。最简单的做法是给每个 Agent 分配一个密钥调用时携带密钥进行验证。通信是指具体的消息传递机制。A2A 支持同步和异步两种模式。同步模式适合需要立即返回结果的场景异步模式适合耗时较长的任务。我的建议是默认用异步因为 Agent 之间的调用往往涉及复杂的处理逻辑同步等待很容易导致超时。异步模式下调用方发起请求后拿到一个任务 ID然后通过轮询或回调获取结果。注意事项A2A 通信中一定要做好幂等性设计。因为网络抖动或超时重试同一个请求可能被发送多次。如果接收方没有幂等处理就会重复执行操作造成数据不一致。3.4 Skills 的设计模式与复用策略Skills 的设计我总结了一个“三问法”这个 Skill 只做一件事吗调用方不看实现能正确使用吗同样的输入总是得到同样的输出吗三个问题都是“是”这个 Skill 的设计才算合格。在实际项目中Skills 通常分为几类数据获取类查询数据库、调用 API、数据处理类格式转换、计算、过滤、内容生成类生成文本、生成图表、操作执行类发送消息、写入文件。不同类型的 Skill 在设计上有不同的侧重点。数据获取类的 Skill 重点是错误处理和重试策略因为外部依赖最容易出问题。数据处理类的 Skill 重点是输入校验因为脏数据会导致难以排查的错误。内容生成类的 Skill 重点是输出格式的稳定性因为下游可能依赖特定的格式。操作执行类的 Skill 重点是幂等性和回滚机制因为操作一旦执行就可能产生副作用。复用策略上我建议把 Skill 按照业务领域分组管理。比如“用户相关”的 Skill 放在一起“订单相关”的放在一起。这样当一个新的 Agent 需要某个领域的能力时可以整组引入而不是一个一个挑。同时每个 Skill 都应该有版本号当 Skill 的实现发生变化时通过版本号来管理兼容性。4. 从零搭建一个 Agent 集群完整实操流程4.1 环境准备与基础依赖在开始搭建之前需要先把基础环境准备好。以下是我在实际项目中使用的依赖清单你可以根据具体情况调整# 核心框架 pip install deepagents-core pip install mcp-sdk pip install a2a-protocol # 工具与辅助 pip install pydantic pip install httpx pip install asyncio # 可选监控与调试 pip install structlog pip install opentelemetry-sdk环境准备阶段最容易忽略的是版本兼容性。DeepAgents、MCP SDK 和 A2A 协议库之间的版本依赖关系比较紧密建议在项目开始时就把版本锁定避免后续升级引入不兼容的问题。我一般会在项目根目录放一个requirements.txt把所有依赖的精确版本都写进去。另一个容易踩的坑是异步运行时。Agent 集群天然是异步的多个 Agent 可能同时在工作。如果你的代码里混用了同步和异步调用很容易出现死锁或性能瓶颈。我的建议是从一开始就统一用asyncio所有涉及 IO 的操作都用异步方式实现。4.2 定义第一个 Agent 与 Skill我们先从一个最简单的场景开始一个能查询天气并给出穿衣建议的 Agent。这个场景虽然简单但包含了 Agent 集群的所有核心要素。首先定义 Skill。查询天气是一个数据获取类 Skillfrom pydantic import BaseModel import httpx class WeatherQuery(BaseModel): city: str date: str today class WeatherResult(BaseModel): city: str temperature: float condition: str humidity: float async def get_weather(query: WeatherQuery) - WeatherResult: async with httpx.AsyncClient() as client: resp await client.get( https://api.weather.example.com/current, params{city: query.city, date: query.date}, timeout10.0 ) resp.raise_for_status() data resp.json() return WeatherResult(**data)这个 Skill 的设计遵循了前面说的三个原则单一职责只查天气、明确契约输入输出都有 Pydantic 模型定义、无状态不依赖任何外部上下文。接下来定义穿衣建议 Skill。这是一个内容生成类 Skill输入是天气数据输出是建议文本class ClothingAdvice(BaseModel): advice: str items: list[str] async def suggest_clothing(weather: WeatherResult) - ClothingAdvice: if weather.temperature 5: return ClothingAdvice( advice天气寒冷注意保暖, items[羽绒服, 围巾, 手套] ) elif weather.temperature 15: return ClothingAdvice( advice天气较凉建议穿外套, items[夹克, 长裤] ) else: return ClothingAdvice( advice天气温暖穿着舒适即可, items[T恤, 休闲裤] )4.3 通过 MCP 暴露 Skill 能力Skill 写好了接下来需要把它通过 MCP 暴露出去这样 Agent 才能调用。MCP Server 的封装大致如下from mcp_sdk import MCPServer, Tool server MCPServer(nameweather-tools) server.tool( nameget_weather, description查询指定城市的当前天气, input_schemaWeatherQuery, output_schemaWeatherResult ) async def handle_get_weather(query: WeatherQuery) - WeatherResult: return await get_weather(query) server.tool( namesuggest_clothing, description根据天气数据给出穿衣建议, input_schemaWeatherResult, output_schemaClothingAdvice ) async def handle_suggest_clothing(weather: WeatherResult) - ClothingAdvice: return await suggest_clothing(weather) if __name__ __main__: server.run(port8080)这里的关键点是工具描述要精准。get_weather的描述是“查询指定城市的当前天气”Agent 看到这个描述就知道什么时候该用它。如果写成“天气相关工具”Agent 就不确定它到底能做什么。4.4 用 DeepAgents 编排多 Agent 协作现在有了两个 Skill我们可以构建一个 Agent 来使用它们。但为了演示多 Agent 协作我们构建两个 Agent一个负责获取天气数据一个负责生成建议。from deepagents import Agent, Orchestrator # 天气查询 Agent weather_agent Agent( nameweather_agent, description负责查询天气数据, tools[get_weather], system_prompt你是一个天气查询助手根据用户提供的城市名称查询天气。 ) # 建议生成 Agent advice_agent Agent( nameadvice_agent, description根据天气数据生成穿衣建议, tools[suggest_clothing], system_prompt你是一个穿衣建议助手根据天气数据给出合理的穿衣建议。 ) # 编排器 orchestrator Orchestrator( namemain_orchestrator, agents[weather_agent, advice_agent], system_prompt你是一个任务协调器。当用户询问穿衣建议时 1. 先调用 weather_agent 获取天气数据 2. 再把天气数据传给 advice_agent 生成建议 3. 最后把建议返回给用户 ) async def main(): result await orchestrator.run(北京今天穿什么合适) print(result) if __name__ __main__: import asyncio asyncio.run(main())这个编排结构是两层的编排器负责协调两个执行 Agent 负责具体操作。编排器的 Prompt 里明确了任务流程这样它就知道先调谁后调谁。4.5 通过 A2A 实现跨系统 Agent 调用假设现在有一个外部的“时尚推荐 Agent”它部署在另一个系统上我们希望通过 A2A 来调用它。首先需要在 A2A 注册中心注册这个 Agent 的能力from a2a_protocol import A2AClient, AgentCard # 查询可用的外部 Agent client A2AClient(registry_urlhttps://a2a.example.com) # 发现时尚推荐 Agent fashion_agent_card await client.discover( capabilityfashion_recommendation ) # 调用外部 Agent result await client.call( agent_idfashion_agent_card.agent_id, input{weather: weather_data, style: casual}, timeout30 )A2A 调用的关键是AgentCard它描述了 Agent 的能力、输入输出格式、认证方式等信息。调用方通过 AgentCard 就能知道怎么正确地调用这个 Agent不需要额外的文档。4.6 完整链路的联调与验证把上面所有部分串起来完整的链路是这样的用户输入“北京今天穿什么合适”编排器接收请求判断需要先查天气编排器调用 weather_agentweather_agent 通过 MCP 调用 get_weather Skill拿到天气数据编排器把天气数据传给 advice_agentadvice_agent 通过 MCP 调用 suggest_clothing Skill生成建议编排器把建议返回给用户联调时我建议逐段验证不要一上来就跑全链路。先单独测每个 Skill 能不能正常工作再测每个 Agent 能不能正确调用 Skill最后测编排器能不能正确协调多个 Agent。这样出问题时能快速定位是哪一层的故障。验证通过后可以用一个简单的测试集来跑回归测试用例输入预期输出正常查询北京今天穿什么包含温度和穿衣建议城市不存在不存在的城市穿什么友好的错误提示缺少城市今天穿什么询问城市信息5. 常见问题与排查技巧实录5.1 Agent 调用工具时选错工具怎么办这是最常见的问题之一。Agent 面对多个工具时可能会选一个看起来相关但实际上不对的工具。排查思路是首先检查工具描述是否足够区分。如果两个工具的描述都是“查询数据”Agent 当然分不清。把描述改得更具体比如“查询用户订单数据”和“查询商品库存数据”问题往往就解决了。如果描述已经足够清晰但 Agent 还是选错那可能是工具数量太多了。我实测下来一个 Agent 挂载的工具超过 15 个时选择准确率会明显下降。这时候应该考虑拆分 Agent每个 Agent 只负责一类工具。还有一个技巧是在系统 Prompt 里加入工具选择的指导。比如“当用户询问订单相关问题时优先使用 order_query 工具”。这种显式的引导能显著提升准确率。5.2 MCP 调用超时或失败的处理策略MCP 调用失败的原因很多需要分类处理错误类型典型表现处理策略网络超时请求发出后无响应重试 2-3 次间隔递增参数错误返回 400 类错误检查参数格式修正后重试服务不可用返回 503 类错误等待后重试或降级到备用方案权限不足返回 401/403检查认证信息不可重试我的经验是在 Agent 层面实现一个统一的错误处理中间件根据错误类型自动决定重试策略。这样每个 Skill 不需要单独处理错误逻辑更清晰。5.3 A2A 跨 Agent 通信中的幂等性问题前面提到过幂等性这里展开说一下具体怎么做。最简单的方案是给每个请求分配一个唯一 ID接收方在处理前先检查这个 ID 是否已经处理过。如果处理过直接返回之前的结果如果没有正常处理并记录 ID。processed_requests {} async def handle_request(request): if request.id in processed_requests: return processed_requests[request.id] result await process(request) processed_requests[request.id] result return result这个方案在单机环境下够用但在分布式环境下需要考虑共享存储。可以用 Redis 之类的缓存来存储已处理的请求 ID设置合理的过期时间。5.4 Skills 版本升级导致的兼容性问题Skills 升级时最容易出的问题是输入输出格式变化导致调用方解析失败。避免这个问题的关键是版本化。每个 Skill 都应该有明确的版本号升级时如果格式有变化就发布一个新版本旧版本继续保留一段时间。调用方在调用时指定版本号这样即使 Skill 升级了已有的调用方也不会受影响。等所有调用方都迁移到新版本后再下线旧版本。实操心得我在项目里维护了一个 Skills 变更日志每次修改都记录改了什么、影响哪些调用方、迁移建议是什么。这个日志在排查问题时非常有用强烈建议你也建一个。5.5 Agent 集群的性能瓶颈定位当集群跑起来后性能问题往往出现在意想不到的地方。我总结了一个排查顺序先看编排层。编排器的调度逻辑是不是有串行等待能不能并行执行的任务被串行化了这是最常见的瓶颈。再看通信层。MCP 和 A2A 的调用有没有不必要的序列化/反序列化开销网络延迟是不是主要因素最后看执行层。单个 Agent 的处理时间是不是过长是不是有 Skill 在执行耗时操作定位到瓶颈后针对性地优化。编排层的问题通常通过调整调度策略解决通信层的问题通过批量化或缓存解决执行层的问题通过异步化或拆分解决。6. 扩展方向这套架构还能怎么玩6.1 接入更多类型的 Skill目前我们只接了查询和生成类的 Skill实际上这套架构可以接入几乎所有类型的 AI 能力。比如接入代码执行 Skill让 Agent 能运行代码并获取结果接入图像生成 Skill让 Agent 能根据描述生成图片接入搜索 Skill让 Agent 能获取实时信息。每接入一类新 SkillAgent 集群的能力边界就扩展一圈。而且因为 Skill 是即插即用的扩展成本很低。6.2 构建 Agent 市场当 Skill 和 Agent 的数量积累到一定程度后可以考虑构建一个内部的 Agent 市场。每个团队把自己开发的 Agent 注册到市场上其他团队按需调用。这样能避免重复开发也能促进能力的标准化。Agent 市场的关键是要有完善的能力描述和评价机制。调用方能看到每个 Agent 的能力、性能指标、用户评价从而做出选择。6.3 引入监控与可观测性生产环境的 Agent 集群必须有完善的监控。需要监控的指标包括每个 Agent 的调用次数和成功率、每个 Skill 的响应时间和错误率、编排链路的端到端延迟、资源使用情况等。我一般会用 OpenTelemetry 来做链路追踪每个请求从进入编排器到最终返回整条链路的每个环节都有 trace 记录。出问题时能快速定位是哪个环节的故障。6.4 安全与权限控制当 Agent 集群对外开放时安全就变得至关重要。需要控制的点包括哪些 Agent 可以被外部调用、每个 Agent 能访问哪些 Skill、调用频率限制、敏感操作的审批流程等。我的做法是在 A2A 层做统一的认证和授权每个外部请求都要携带有效的凭证编排器根据凭证判断是否有权限调用目标 Agent。同时在 Skill 层做细粒度的权限控制比如查询类 Skill 对所有 Agent 开放但写入类 Skill 只有特定 Agent 才能调用。这套架构我从最初的原型跑到现在的生产环境前后迭代了大概半年时间。最大的体会是Agent 集群的复杂度不在于单个 Agent 有多聪明而在于它们之间的协作有多顺畅。把编排、通信、能力这三层分清楚每一层用合适的协议和工具去解决整体就会变得可控。反过来如果一开始就把所有逻辑揉在一起后面每加一个功能都会变成一场噩梦。