★ FEATURED ARTICLE 去年底我把一个内部需求自动化项目从单Agent重构成了多智能体集群最后稳定跑起来的形态是DeepAgents做调度MCP接业务系统Skills沉淀团队操作规范A2A让各个Agent之间互相派活。这个过程里我最大的感受是大部分人聊多智能体时停留在有几个角色在群里互相对话的幻觉上真正落地时卡住的却是工具协议、任务状态、幂等重试这些不太性感的东西。这篇文章就是一次全流程复盘从四件套各自干什么、为什么这么组合到一份可以直接抄的端到端配置和调试记录。适合正在做Agent平台、或者在业务里集成AI自动化的工程团队也适合想从demo走向生产级多智能体架构的开发者。1. 单个Agent加十个工具一样会抓瞎四件套的分工逻辑1.1 我为什么放弃单Agent 工具函数的老路子早先版本里我的Agent只有一个给它塞了几十个Function Calling函数创建任务、读数据库、发通知、调API、跑测试。第一版确实跑通了但问题接踵而至。第一个问题是上下文污染。系统提示词里要描述每个函数什么时候该用、参数怎么填、返回结构长什么样Agent的注意力被摊薄了。实测里它经常在查用户信息和查订单状态之间犹豫甚至把参数搞混。第二个问题是改动成本高。每次加一个外部系统对接都要改主Agent的提示词和工具注册表改完还要重新跑回归一个Agent成了所有人的公共开发接口。第三个问题最致命没有谁真能独立完成整条业务链路。比如代码仓库操作、浏览器界面验证、数据库变更这几种能力对系统上下文、鉴权方式和风险等级要求完全不同硬塞进一个Agent里那就是用一把钥匙开所有锁。所以我不再把Agent看成一个什么都能干的大脑而是把Agent改造成一个指挥协调中心。它不需要拥有所有工具只需要知道谁能干这件事、怎么把任务派出去。1.2 MCP、A2A、Skills、DeepAgents在集群里各管什么我把这套架构里四件套的分工用一句话说清楚MCP管的是Agent的双手——让Agent用标准协议调用外部工具和数据源。Skills管的是Agent的肌肉记忆——把一套固定的操作套路预先写好按需加载。A2A管的是Agent之间的话筒——定义Agent之间如何发消息、派任务、回结果。DeepAgents管的是整个舞台——负责所有Agent的注册、路由、调度、状态跟踪和审计。这四层不是包含关系而是叠加关系。MCP解决的是Agent怎么接触世界Skills解决的是Agent该按什么套路做事A2A解决的是Agent怎么让另一个Agent替它做事DeepAgents解决的是谁来保证这一堆Agent不乱套。我用一张表把它们经常被搞混的边界固定下来组件解决的核心问题类比典型实现形态MCP外部工具与数据怎么统一接入USB-C接口MCP Server、stdio/HTTP传输Skills复杂操作流程怎么沉淀复用专家编写的操作手册SKILL.md 资源文件A2A智能体之间怎么通信协作对讲机任务单Agent Card、JSON-RPCDeepAgents集群怎么编排、调度、运维项目经理工单系统控制面服务、任务路由1.3 组合起来的集群形态长什么样实际部署里我不是让所有Agent都直连所有MCP Server。正确的做法是按角色绑定权限。比如前端开发Agent只挂浏览器自动化和设计稿相关的MCP后端开发Agent只挂数据库和CI相关的MCP测试Agent只挂测试执行和缺陷追踪相关的MCP。每个Agent的Skills也按岗位定制。然后这些Agent通过A2A协议接入DeepAgents控制面。控制面收到一个高层需求后拆分出子任务按Agent Card里的能力描述路由给对应Agent子Agent干完活把结果通过A2A回传控制面再做聚合和验收。这套结构的好处是某个Agent挂了不影响全局某个MCP Server升级也不需要改Agent的提示词新增一个Agent角色就是注册一个节点的事。我后面第6章会用一个完整案例演示这条链路。2. MCP落地细节Agent进入真实世界的统一接口2.1 MCP为什么不是又一个新名词包装MCPModel Context Protocol可以把它理解为AI世界的USB-C端口。早期集成外部能力是每个模型厂商一套私有规范你对接一个数据库就要写一个专用适配器对接一个浏览器又要写另一套。MCP把工具定义调用请求返回结果全部收敛成一套JSON-RPC消息标准。一个MCP Server会暴露三类能力Tools可执行的函数、Resources可读取的上下文数据、Prompts可复用的提示模板。客户端场景下Agent通过MCP Client连接Server运行时完成三件事拉取工具列表、把用户意图匹配到具体工具、把工具返回的结构化结果拼回对话上下文。这里我想强调一个容易被忽略的点MCP不是给Agent加技能它只是给Agent一个能调用外部能力的通道。工具原本是函数MCP管的是函数如何被发现、如何被调用、如何回传。至于Agent会不会用、用得对不对那是提示词和Skills的事。2.2 一次MCP工具调用的完整旅程要理解排错思路得先过一遍调用链。我在项目里给Agent接了一个PostgreSQL MCP Server整个过程分四步初始化握手。MCP Client与Server建立连接stdio或HTTP交换协议版本和capabilities。工具发现。Client调用tools/list拿到工具名、描述、JSON Schema参数定义。这组定义会被塞进Agent上下文。模型决策。Agent根据用户请求和工具描述选择要不要调用、填什么参数然后发出tools/call请求。结果回填。Server执行完返回内容Client把它作为函数返回结果交给模型模型据此生成最终回复。我在调试时踩过最多的坑就出在第二步和第四步。工具描述写得太短Agent不知道什么时候用返回内容结构不干净Agent把无关字段当成了有效数据。提示所有暴露给Agent的工具描述开头第一句一定要写什么时候用、什么时候不要用。第二句才写参数。把使用边界写清楚比详细解释参数更能降低误调率。2.3 Browser Use MCP和Playwright MCP到底怎么选选型时卡我最久的是浏览器自动化方案。网上问得最多的就是Browser Use MCP和Playwright MCP有什么区别。我的使用结论是这样的。Playwright MCP是标准浏览器自动化协议封装它把浏览器当测试工具来操作讲究的是稳定、可控、可复用。适合走严格步骤的验证场景比如登录、点按钮、断言页面元素、截图对比。它给你的是一个个明确的动作函数Agent很难自由发挥但每一步都可控。Browser Use MCP则更偏视觉语义理解。它把整个页面当成模型的感知输入让模型自己去决定下一步点哪里、输什么。适合探索式任务比如帮我看看这个页面哪里能导出报表对比一下两个页面的布局差异。它的容错性更好但代价是token消耗高、执行路径不可预测。我给团队的规则很简单凡是能写成确定性步骤的一律用Playwright MCP只有探索性和视觉判断任务才开Browser Use。因为生产流水线里可控比聪明值钱你可以接受Agent多问一句不能接受它把页面点乱了还告诉你说一切正常。2.4 我在项目里跑稳MCP Server的几条教训第一不要把所有MCP都全局挂载。MCP Server越权暴露工具既增加上下文长度又让Agent在工具选择上晕头转向。我后续会提到角色绑定的配置方法。第二超时和重试必须独立配置。数据库查询和应用内短接口的延迟完全不同。最好给每个MCP Server定义独立timeout并在外层做针对性的错误包装。否则一个慢查询能把整个Agent会话拖死。第三注意Resource的加载量。Resources是MCP里常被忽视的一块。比如把所有数据库表结构都暴露成Resource一张表动辄几百行定义多挂几张表上下文直接爆掉。要用按需读取的方式只在Agent明确要处理某张表时再加载它的schema。3. Skills让Agent学会一套动作而不是记住一个工具3.1 Skills与MCP Tool的本质区别很多初上手的人把Skills当成MCP工具的本地版这个理解会让架构变得很别扭。你想想MCP Tool是一次性动作比如查一下这个仓库的分支执行这条SQL。而Skills是一套完整动作序列它包含目标、步骤、约束、检查清单甚至附带参考文件。可以这样类比MCP给你的是螺丝刀、扳手、电钻Skills是更换轮胎标准作业流程——先做什么、后做什么、什么情况要停工、做完怎么自检。我用一个具体场景区分给Agent一个代码审查的MCP工具它只能逐文件读取并发表意见但给Agent一个代码审查Skill它会自动走完读需求文档→拉变更清单→检查潜在风险→对照团队规范→输出审查结论并整理成指定格式这一整套流程。3.2 SKILL.md的结构与加载时机我用的是社区通用的SKILL.md规范YAML frontmatter里写name和description正文写具体操作指令。文件放在skills/skill-name/目录下可以附带脚本、模板或参考文档。--- name: frontend-dev description: 按团队规范完成一个前端页面的开发。适用于需要实现UI组件、页面交互联调、响应式适配的任务。不要在纯后端逻辑或数据库变更任务中使用。 --- # 前端开发标准流程 1. 先阅读 docs/frontend-guidelines.md确认组件规范和样式要求。 2. 输出页面拆解方案包括组件划分、状态管理方式和接口对接点。 3. 使用 MCP 工具读取设计稿信息和现有代码结构。 4. 完成代码实现注意公共组件复用占比需大于60%。 5. 执行本地构建确保无类型错误和警告。 6. 自检清单响应式断点是否完整、键盘操作是否可用、图片有无懒加载。加载时机这件事值得单独说。Skills不要一股脑全塞进系统提示词那会让Agent的上下文负担暴涨。我在控制面里做的是按任务类型动态装配收到一个前端开发任务就把frontend-dev这个Skill注入对应Agent的上下文收到代码审查任务就注入另一个。这套机制跟后面A2A的任务路由是配套的。3.3 用代码审查Skill演示一个完整定义写Skill最容易犯的毛病是写得像通用建议。比如注意代码质量确保遵循最佳实践这种话Agent看了等于没看。好的Skill一定要把团队的验收标准具体化。我团队的code-review skill核心段落是这样的--- name: code-review description: 按团队规范审查代码变更识别严重缺陷与改进点。用于合并请求评审、疑难问题定位。不适用于需求拆解或进度管理。 --- # 代码审查执行步骤 1. 获取变更目标从 version control MCP 读取当前 MR 的变更文件列表。 2. 风险扫描优先检查鉴权、注入、敏感信息泄露、资源释放、并发安全五类问题。 3. 规范核对对照 docs/team-coding-guide.md 中的命名规范与模块边界。 4. 输出报告按「阻塞问题 / 主要问题 / 建议优化」三级输出每条必须带文件路径和行号。这里的关键是文件路径和行号这个硬性要求。没有这个约束AI审查经常给出建议优化注释这种无法落地的建议。把产出标准写死在Skill里效果立刻不一样。3.4 Skills仓库管理与冲突避坑Skills多了以后最大的问题不是找不到而是互相冲突。比如frontend-dev要求所有新页面必须多端适配另一个page-opt却要求首屏性能优先这两个约束在具体场景里可能打架。我的做法是给Skill加适用条件和优先级元数据。在description里明确写适用范围控制面路由时按任务类型排除掉互斥Skill。另外要建立版本管理每个Skill都纳入Git仓库改动走评审。团队成员可以直接提PR改进某个Skill这比改Agent提示词要安全得多。还要提一个经验Skills不需要多贵在准。团队攒了上百个Skill的制品库绝对是个灾难Agent在选择时根本分不清该用哪个。我在第4、5章会讲如何通过角色和路由让Skill的匹配面更窄。4. A2A协议Agent之间终于有了同声传译的渠道4.1 为什么不用Webhook或消息队列说A2A之前先聊聊我最早想偷懒的方案让Agent之间直接发HTTP请求或者用消息队列传消息。试过之后发现问题是会通信和会协作是两回事。消息队列擅长的是你把消息发出去我保证送达但它不管消息内容代表什么任务、任务谁负责、做到一半失败了怎么办。Webhook更简单只管回调通知。而Agent协作真正需要的是一套讲得清任务生命周期的对话协议谁发起的任务、当前什么状态、是否需要补充信息、结果以什么形式交付。A2AAgent-to-Agent解决的就是这件事。它由Google在2025年4月牵头发布目标是标准化Agent之间的发现、通信和协作。协议核心是客户端代理与远程代理之间建立会话传递任务Task、消息Message和工件Artifact每个任务都有一份明确状态机从submitted一直到completed或failed。4.2 Agent Card与任务生命周期A2A最有价值的第一个设计是Agent Card。每个A2A节点都暴露一个JSON格式的卡片里面写明这个Agent的名字、技能列表、能力描述、支持的传输方式。这相当于服务员菜单其他Agent和控制面看到卡片就知道这个活它能接、那个活它不接。{ name: frontend-agent, description: 负责前端页面开发与联调支持组件实现、状态管理、响应式适配, skills: [frontend-dev, component-optimize], capabilities: { streaming: true, pushNotifications: false } }第二个关键设计是任务状态机。一个A2A任务从提交开始经历working、input-required、completed、failed这几个状态。我最喜欢的是input-required它意味着Agent可以反问你这个需求里登录态怎么处理这给了集群一种很重要的能力——Agent不再傻乎乎地硬做而是可以主动要信息。4.3 Spring A2A落地一个最小节点团队里有成员提前接了Spring AI的A2A模块做验证我扒了它的思路这里给一个最小结构。Spring A2A要解决的是JVM生态下快速注册A2A节点的问题A2AClientAgent( name backend-agent, description 负责后端接口设计与实现熟悉订单、用户、统计域, skills {backend-dev, api-design} ) public class BackendAgentService { A2AMethod public TaskOutcome createOrderApi(TaskContext ctx) { // 解析任务消息里的需求描述 // 调用内部开发工作流 // 返回TaskOutcome } }它的好处是屏蔽了Agent Card的生成和JSON-RPC消息细节你只需要实现业务方法。但我要提醒一句任何一个框架生成的Agent节点都还不是真正的Agent它只是让程序具有了A2A通信能力。真正让它干活的知识、Skills、工具权限还是得靠你预先装配好。4.4 集群里最常用的三种A2A消息模式我日常在集群里用到的不外乎三种模式。第一种是任务委派。控制面把任务拆开后发给子Agent子Agent完成后回传结果。这是最基础的。第二种是信息求助。A Agent在干活过程中发现自己缺某个专业判断于是给B Agent发一个input-required任务B返回判定后A继续完成自己的工作。这个模式特别适合前端Agent不确定后端接口字段含义派个小任务问一下后端Agent的场景。第三种是并行分解。一个大任务拆成一个父任务和多个子任务多个Agent并行处理DeepAgents聚合结果。比如优化首页性能可以分解为前端优化、图片资源压缩、接口耗时排查三件事由三个Agent并行做。4.5 A2A与MCP的边界清单这是全篇我最想让大家想明白的一点。A2A和MCP经常被拿来对比因为它们都解决连接问题。我的判断标准很简单如果目标是一个Agent调用一个具体工具用MCP如果你的目标是让另一个有完整判断能力的实体接下一整块任务用A2A。一个反例能说明问题你在Agent A里装了一个GitHub MCP然后让Agent A调用GitHub API给Agent B创建了个仓库。这没错但这不是A2A这只是Agent A把GitHub当工具用。A2A的场景是Agent A发现自己需要一份尽调报告而控制面里恰好有一个专门做尽调的Agent于是把任务派过去拿到报告再继续干活。所以我的团队里有一条铁律能用一个MCP工具调用解决的绝对不要绕一层A2A任务委派。A2A有价值的前提是这个任务真的需要另一个上下文、另一套Skills才能完成。5. DeepAgents控制面集群不只要能聊还要好管5.1 控制面承担的四大职责如果MCP、Skills、A2A是个体能力层DeepAgents在这套方案里承担的就是控制面。把控制面拆开看有四个职责绕不开。第一是节点注册与发现。每个Agent上线时都得登记它是谁、有什么Skill、能用哪些MCP Server、负载上限是多少。控制面维护一张节点清单路由时先查这张清单。第二是任务路由与编排。拿到一个高层需求后控制面要能拆解成子任务分配到合适的Agent并记录每个子任务的上下游依赖。第三是状态与进度管理。所有A2A任务的状态都要汇聚到控制面形成一个全局视图。看板上一眼能看出哪个Agent卡住了、哪个任务在等用户输入。第四是权限与审计。每个Agent能调哪些MCP工具、能读哪些Resource、能对接哪套外部系统全部由控制面统一管控并记录日志。这既是安全需求也是事后排查的依据。5.2 角色身份与Skill、MCP权限的绑定我实现角色权限的第一版是各Agent自己写在配置里结果改个权限要逐个节点操作。后来统一到控制面配置文件里管理agents: frontend-agent: role: frontend mcp_servers: [playwright-mcp, design-token-mcp] skills: [frontend-dev, component-optimize] max_concurrent_tasks: 2 backend-agent: role: backend mcp_servers: [postgres-mcp, ci-mcp] skills: [backend-dev, api-design] max_concurrent_tasks: 3这种配置模式对我最大的价值是新上线一个Agent节点时不需要从零考虑权限只要声明角色控制面会自动匹配该角色的MCP和Skills白名单。角色本身就是一种安全边界。5.3 任务路由时必须想清楚的几件事路由不是简单的按名字找Agent。我踩过几次坑之后总结出三个必须考虑的点。一是技能匹配度。看Agent Card的skills字段只是第一步还得再读任务的语义。比如做个报表页面可能是前端任务但如果需求里重点是数据统计口径就得考虑是不是该先派给数据分析Agent。二是负载与并发。AI Agent集群不像微服务那样可以预估QPS一个长任务可能占住Agent十分钟。我给每个Agent设了两个参数的硬约束max_concurrent_tasks和task_timeout。超时的任务标记fail不让它无限占坑。三是失败转移要绑定角色而不是具体Agent。我的路由表里写的是frontend类任务→frontend角色节点而不是某台机器的agent-01。这样一台宕了控制面能把任务平滑转给同角色的另一节点。5.4 审计日志与可观测性设计多智能体集群一个容易失控的地方是消息满天飞根因无处查。我要求控制面对每个任务记录五个维度的日志任务输入摘要、路由目标与原因、每一步A2A消息记录、Token消耗、最终产出物地址。这五个维度里路由原因我觉得最值钱。没有它系统一旦出现为什么这个简单需求去了重度AI集群的疑问你只能在日志海里捞针。有了原因字段做成本优化和链路调整就有了依据。还有个建议给每条A2A消息加requestId贯穿全链路。控制面下发任务时生成一个全局ID后续所有子任务、MCP调用、回传结果都带上它。出问题时按ID一拉就是整条链路的全部上下文。6. 端到端实战四个Agent协作完成一个开发看板需求6.1 需求场景与角色划分这次实战我选一个非常典型的任务在公司内部系统里新增一个项目迭代看板页面要求展示各项目的进度、风险、负责人并且支持筛选和导出。这个需求横跨前端、后端、数据、测试四个域。我部署了四个Agent产品Agent负责把需求拆成用户故事和验收标准后端Agent负责建表和写查询接口前端Agent负责页面实现和交互测试Agent负责生成测试用例并执行冒烟验证。每个Agent只在自己角色权限内干活通过A2A传递任务总协调由DeepAgents控制面负责。这个组合的关键在于没有一个Agent见过完整需求但合起来能完成完整交付。产品Agent只输出规格说明后端只根据规格建表和写接口前端只按接口文档和设计规范做页面测试只验证验收标准是否满足。6.2 环境准备清单与配置示例按我团队的标准配置准备四样东西MCP Server集群PostgreSQL MCP、Git仓库MCP、Playwright MCP各一份。Skills库backend-dev、frontend-dev、test-case-gen、data-model-validator。A2A节点四个Agent各自注册Agent Card接在同一控制面下。DeepAgents控制面加载六点二节的角色配置文件。产品Agent收到需求后的第一件事不是写代码而是输出一份可路由的任务描述。我把这一步固化成了它独有的Skill产出的格式是标准化的目标、影响范围、数据字段、验收标准、涉及角色。这份任务描述是整个链路的起点。6.3 一次典型任务调用的完整链路一次实际运行的流程是这样的第一步用户在控制台提交新增项目迭代看板需求。DeepAgents把需求交给产品Agent产品Agent调用需求规划Skill生成包含功能点清单和验收标准的规格文档然后通过A2A把后端接口开发子任务发给后端Agent把前端页面实现子任务发给前端Agent。第二步后端Agent开始工作。它收到任务后自动加载backend-dev Skill通过PostgreSQL MCP读取现有表结构创建迭代表和风险字段再通过CI MCP执行数据库迁移。完成后后端Agent生成一份接口文档作为A2A task的artifact回传给控制面。第三步前端Agent同时开工。它先加载frontend-dev Skill通过design-token MCP读取设计变量根据产品Agent的规格文档和接口文档完成页面。期间它发现接口里缺少风险等级字段便通过A2A向后端Agent发起一个input-required子任务拿到确认后才继续。第四步所有子任务completed后控制面把产物聚合成一个完整需求包派发给测试Agent。测试Agent加载test-case-gen Skill用Playwright MCP启动页面按产品验收标准逐条执行发现两个交互问题后回传给控制面控制面再路由给前端Agent修复。第五步测试Agent复测通过控制面把完整交付报告返回用户侧。这条链路最值得品的地方在于任何一个环节的Agent都没有同时打开所有工具但它通过A2A把上下文和任务包装在最小范围内传递整个集群不会因为复杂度上线而陷入混乱。6.4 本次实战中遇到的三个真实问题第一个问题出在产品Agent生成的任务描述上。它把所有前后端细节全塞给后端Agent导致后端Agent上下文里塞满了不需要的UI信息决策质量下降。解法是在需求规划Skill里明确按角色裁剪信息后端只收数据模型和接口约束前端只收页面结构和交互要求。第二个问题是后端Agent在数据库迁移失败后连续重试三次还是失败但每次都重新连接数据库执行同样的SQL。后来我在控制面加了一条规则数据库类任务不允许无条件重试必须先回读变更历史确认迁移没有部分执行才能再试。多智能体集群里是否可重试不是通用属性而是跟任务类型强绑定的。第三个问题是A2A消息里的artifact体积。前端Agent把一个几兆字节的截图打进artifact结果所有下游节点都要解析这个大对象。后来约定大文件一律走对象存储A2A消息里只传引用地址。这个改动让整条链路速度提升了一个量级。7. 集群运行的三条底线上下文、重试、成本7.1 上下文长度是集群的隐形瓶颈多智能体集群的总上下文消耗不是各个Agent之和而是各个Agent乘以任务层级。一个A2A任务每转发一次就有一部分历史描述被重新带到下一个节点。我做过统计一个三级任务链路跑下来光任务背景重复描述就能消耗总token的20%到30%。应对办法有两点。一是A2A任务描述要做摘要化父节点只需要传递本子任务相关的必要背景。二是控制面定期做上下文压缩把已完成的早期交互浓缩成几行结论而不是保留完整对话历史。这是集群能跑长任务的基础。7.2 Agent失败时该重试谁不该重试什么集群稳定性的核心判断全在重试两个字上。我在团队里立了一条规矩重试之前先问三个问题——这是不是幂等操作失败在哪一层重试会不会放大副作用MCP工具调用和A2A任务是两种完全不同的重试对象。调用只读MCP工具失败基本可以直接重试写操作失败必须先查状态A2A子Agent失败则要判断是任务本身问题还是资源问题。尤其要警惕的是那种同一个任务派给同一个Agent重试但Agent日志明明显示上次已经成功完成了一半的情况——这种必须走对账流程而不是无脑重发。我在第5章配置里给每个Agent设的timeout和max_concurrent_tasks本质上就是在给重试设置边界。重试不能由子Agent自己决定必须由控制面统一裁决否则一个错误的Agent会在死循环里把整条链路的资源耗干。7.3 Token浪费的常见来源与控制手段我观察到的Token浪费主要来自三个地方过长的系统提示词、过大的MCP返回内容、无约束的A2A历史传递。系统提示词方面把每个角色的主提示词控制在Agent总上下文的15%以内剩下空间全部预留给动态注入的Skills和任务描述。MCP返回内容方面在Server端就做字段裁剪只返回Agent决策真正需要的字段而不是把整张表丢给它。A2A历史方面控制面定期做对话折叠把已完成子任务的对话摘要成一段结构化结论。我们的实际效果是经过这三项优化单次任务的平均Token消耗降了约45%而且不是靠牺牲质量换来的——准确率反而因为上下文更干净而提升了。最后说几句我自己的感受跑了几个月多智能体集群我最大的体会是这套东西的复杂度不在于某一个组件的技术难度而在于它们的组合节奏。MCP、A2A、Skills、DeepAgents每一个单独拿出来都是标准协议或规范文件可一旦组合在一起真正的工程量就到了协议选型、权限矩阵、任务生命周期、可观测性这些工程细节上。如果看完文章你想动手试我建议从最小闭环开始两个Agent各挂一个MCP Server控制面只做最简单的路由。先把一次完整任务调通再逐步横向扩展角色和Skill。多智能体的价值是多角色协同带来的但它的稳定性恰恰源于每一层都足够收敛。最后再分享一个小经验每增加一个Agent角色先在纸上画出它的输入、输出、权限和失败路径再动手配置。画不清楚就不要开工。集群规模越大这种先想清楚再实施的习惯就越值钱。
阅读完成 · 觉得有帮助？
