这两年我参与过的Agent项目十有八九是从“一个Agent干所有事”开始的。等到要接十几个工具、几十个API需求变成“能不能让两个Agent各自管一摊再互相通气”单体方案就明显撑不住了。与其继续堆Prompt不如把工程结构拆开DeepAgents负责想MCP负责连A2A负责传话Skills负责复用。这套思路不是新瓶装旧酒而是把“单体应用”重构成“组织化协作”的老经验搬到了智能体领域。这篇文章面向的读者是已经被“一个Agent接一堆工具”搞到维护成本爆炸的开发者以及正在规划下一代智能体架构的技术负责人。我会把四个关键词背后的工程逻辑拆开讲清楚它们分别解决什么问题、怎么组合在一起、落地时会踩什么坑。不写概念堆砌尽量给你能直接拿去用的判断依据。1. 为什么“单体智能体”做不下去了四个词背后的工程转向1.1 单体Agent的典型瓶颈和你一定遇到过的现象单体智能体的经典形态是一个Agent 一串System Prompt 一堆自定义工具函数。初期非常好用因为任务少、工具少Prompt里写清楚规则模型基本不会乱来。但项目只要活过三个月问题就开始排队出现。首先是上下文爆炸。每个工具说明、每条业务规则、每个历史对话片段都在挤占上下文窗口。你明明只用了5个工具Prompt里却要塞进专门为第6个、第7个工具写的大段描述否则模型遇到相关任务时不会用。这就像你给新同事发了一本500页的员工手册让他干任何事之前先通读一遍结果他翻到第200页时已经忘了第50页写了什么。其次是工具选型错误率飙升。工具一多模型经常在“该调用A还是B”上犯迷糊。尤其两个工具功能相近时它会随机挑一个然后产出错误结果。我见过一个电商客服Agent同时接了订单查询和物流查询两个工具因为描述写得含糊它能把“查快递”的请求调用成“查订单”用户体验直接崩掉。再次是任务链变长后不可控。单体Agent在长任务里容易“迷路”做了第3步就忘了第1步的目标或者在某个子任务里反复打转。你很难干预它因为它把所有逻辑都揉在一个黑色盒子里。出了问题只能加Prompt加完又影响别的行为陷入“按下葫芦浮起瓢”的循环。最后是复用性差。今天在这个项目里写的工具函数明天换了项目基本带不走。因为工具和业务逻辑深度耦合换个场景就得重写。这跟当年单体应用拆微服务之前的状态几乎一模一样不是技术不行是组织形态撑不住了。1.2 DeepAgents、MCP、A2A、Skills 各自补哪块短板面对单体Agent的四个问题四个词其实给出了四种对症药。DeepAgents解决的是“想不清楚”的问题。它不是一个简单的“提问-回答”模型而是具备长程规划、自我反思、中间结果验证能力的智能体。它会在动手前拆解目标每完成一步检查一下“方向对不对”发现偏了立刻调整。类比的话它更像项目经理而不是只会执行命令的实习生。MCP解决的是“连不上”的问题。它是模型上下文协议把工具、数据、工作流统一成标准接口Agent不用再为每个系统单独写胶水代码。只要对方提供了MCP ServerAgent就能像插USB一样直接使用。这解决的是工具碎片化的问题。A2A解决的是“说不通”的问题。它是Agent与Agent之间的通信标准定义了任务怎么委托、状态怎么同步、结果怎么回传。只要所有Agent都按这个协议说话就不用做N×N的定制化接口对接。Skills解决的是“不会干”的问题。它把某个场景的最佳实践、操作步骤、检查清单、输出格式打包成一个可加载的模块。Agent在执行特定任务时按需加载对应Skill不用把所有知识都塞进上下文。这四者不是并列关系更像一个组织里的不同角色DeepAgents是管理层MCP是基础设施A2A是沟通机制Skills是每个岗位的作业指导书。1.3 为什么非要“协议化”软件协议与硬件协议的老话题有朋友问过我一个很实在的问题“MCP是软件协议那硬件协议那个概念叫什么来着这俩有啥关系”概念本身不复杂协议就是双方提前约定好的“黑话语法”硬件里有USB、PCIe软件里有HTTP、gRPC本质上都是为了“对齐预期”。硬件协议解决了乱接线的混乱以前每台设备一个专用充电口后来USB-C统一了。MCP在软件层做的是同一件事以前每个Agent接数据库、接浏览器、接内部系统都要单独写适配层现在只要实现了MCP谁都能接。A2A也一样它统一的是Agent之间的“会话格式”相当于让两个团队用同一种工单系统协作而不是这家用邮件、那家用微信互相还得配个翻译。还有个很容易被忽略的点协议化之后单个组件就能独立升级。你换掉一个MCP Server不用动Agent主体你更新某个Skill其他Agent照样跑。这就是从单体走向组织化之后最实在的工程红利。2. MCP连通外部世界的标准插座2.1 MCP 解决的真实痛点以及它被过度神化的部分先说真实痛点。在没有MCP的时候每个Agent项目都要写大量“工具接入层”调数据库要写数据库客户端查文档要写文档解析器操作浏览器要写Playwright封装。这些胶水代码本身不难但特别耗时间而且换一个模型就得重新适配。我记得早期做一个内部问答Agent光适配公司内部的Wiki系统就花了两周写出来的东西换个项目完全没法复用。MCP把这件事标准化了工具提供方只需实现一个MCP Server暴露接口Agent这边通过MCP Client连接。无论底层是数据库、API、文件系统还是浏览器对Agent而言都是同一种交互方式。这一点非常关键它让“工具生态”开始像App Store一样生长起来。你不用再回答“怎么让Agent连上Figma”因为社区已经有现成的Figma MCP Server。但MCP也没必要神化。它不是一个分布式服务框架也不解决任务编排。它只负责“让模型能稳定地发现并调用能力”。有些团队把它当成万金油什么事都往MCP里塞反而把简单问题搞复杂了。我的建议是MCP优先解决“重复接入”的问题一次性业务逻辑该写代码就写代码别硬包一层协议。2.2 一个最小MCP Server是怎么跑起来的如果你还没碰过MCP最快上手的方式是用Python写一个极简Server。下面这个示例暴露了一个查询订单状态的工具from mcp.server.fastmcp import FastMCP mcp FastMCP(order-service) mcp.tool() def get_order_status(order_id: str) - str: 根据订单号查询订单当前状态 # 这里换成你的数据库或API查询逻辑 return shipping if __name__ __main__: mcp.run()然后在客户端比如Claude Desktop、Codex、自研Agent的配置文件里注册这个Server{ mcpServers: { order-service: { command: python, args: [server.py] } } }光这两步Agent就具备了查询订单状态的能力。你看核心思路就是把工具变成“服务”用标准协议暴露出去。后续如果换了底座模型配置基本不用动。2.3 MCP的三类能力Resource、Tool、Prompt很多新手只看得到Tool忽略了MCP其实定义了三种能力模型能力类型作用类比典型场景Tool可执行的动作能改变状态员工的手查数据、发消息、提交PRResource只读的资料不可改变状态员工的资料库加载文档、读取配置、查看代码Prompt预制好的提示词模板话术模板快速生成周报、代码审查开场区别很重要。Tool适合“做完一个操作拿到结果”Resource适合“让模型把大批量上下文拉进来阅读”。如果你有一份很长的内部规范文档不要写进System Prompt也尽量不要做成Tool让它逐段查最好的做法是暴露成Resource需要时按段落读取。这样既节省上下文又能保证信息不过期。我在实战里见过很多团队把“读文件”做成Tool结果模型必须把整个文件读一遍再丢掉碰上几百页的文档直接上下文爆掉。正确的做法是把文件切块用Resource暴露分页读取能力让模型只读它真正关心的部分。这个细节能直接影响长文档场景的成败。2.4 工具选型Browser Use MCP 和 Playwright MCP 到底怎么选MCP生态里最容易混的是两类浏览器工具。一个是Browser Use MCP一个是Playwright MCP。两者虽然都操作浏览器但设计思路完全不同。Browser Use MCP偏“让Agent像人一样使用网页”它会自己读取页面内容、定位可交互元素、决定点击哪里适合让模型自主探索完成任务的场景比如自动填报表单、爬取动态页面。缺点是同等任务下token消耗更高行为不确定性也更大。Playwright MCP偏“精确控制执行流程”你指定选择器、指定点击序列、指定等待条件它严格按脚本执行适合自动化回归、截图对比这类需要确定性的场景。缺点是只适合写得很细的任务不适合让模型自由发挥。我的选择建议是需要Agent“看懂网页并自己决策”时用Browser Use需要“按固定步骤反复执行”时用Playwright。两者不是替代关系很多系统会同时挂两个分别面向不同任务。2.5 MCP接入的三个实操坑第一Server数量别贪多。不少人把十几个MCP Server一股脑全挂上结果Agent在工具选择上反复横跳每个Server的描述都要占上下文反而更慢更不准。我一般控制在5个以内按任务动态加载。第二鉴权和网络隔离要提前设计。MCP Server一旦要访问内部系统Token、白名单、审计日志都得有。不然模型“不小心”调用一个高危接口出问题的不是模型是你自己。多智能体无人值守运行的时候这个风险会被放大很多倍。第三给工具的命名和描述留出足够心思。“get_data”这种名字模型看了根本不知道能用来干嘛。每个工具描述里应该写清楚“什么时候用、入参是什么、别拿来干嘛”别嫌啰嗦这比你在Prompt里苦口婆心一百句都管用。3. A2A让智能体之间说“人话”3.1 Agent之间协作为什么不能靠“互相调API”单体Agent转多智能体的第一反应往往是给每个Agent开REST API让它们互相调用。这个方案在3个以内还能跑Agent一多就乱套。A调用B、B调用C谁负责什么全得写死在代码里新增一个角色就得改一圈接口。而且状态难以追踪B的请求超时了到底是谁的问题任务跑到哪一步了没有人能说清楚。A2A协议要解决的就是这件事。它不是去规定Agent内部怎么思考而是约定Agent之间怎么交互。核心概念有三个Agent Card负责能力发现Task负责任务单元Message负责消息流转。Agent Card相当于每个Agent的“名片”上面写着这个Agent能做什么、输入输出格式是什么、通过什么地址联系。其他Agent拿到这张卡片就能判断“这个活儿该不该派给它”。Task是整条协作链路的最小追踪单元每个任务都有状态可以异步跟踪进度。Message则是实际传输信息的载体承载任务内容、中间结果和最终产物。用人话翻译以前你要跟别的部门协作得先要对方的负责人微信然后拉个群出了问题还得一个个现在公司上了统一工单系统每个人都在系统里更新状态你只要提交一张工单就能看到流转到哪一步。A2A就是这个工单系统。3.2 一次标准A2A协作是怎么流转的拿一个已经跑通的内部场景举例需求分析Agent和代码开发Agent协作。流程是这样需求Agent在Agent Registry里发现开发Agent的Agent Card确认它接受“需求描述”输入产出“代码提交”。需求Agent发送一个Task给开发AgentTask里包含需求文本、验收标准、环境信息。开发Agent接收Task执行一段时间后通过A2A消息回调更新状态比如从“processing”变成“waiting_for_input”。需求Agent收到状态更新后可以补充信息或流转给下一个Agent。开发Agent完成后把PR链接和变更摘要作为输出工件回传。整个过程的关键点是任务和结果都是结构化数据不是一句“帮我写个代码”的模糊指令。这能让多智能体系统在无人值守时仍然保持可控。3.3 用A2A解决真实业务从研发流水线到工业协同A2A最典型的战场是研发流水线。我们的实践是让三个Agent分别承担编码、测试、交付中间用A2A传工件编码Agent拿到需求产出代码把变更集作为一个Task的交付物。测试Agent收到交付物后自动跑用例把测试报告回传。交付Agent确认所有检查通过后触发部署流程。没有A2A之前这三个环节的衔接用代码写死换一个环节就全得改。有了A2A之后每个Agent只关心“接收什么格式的任务、产出什么格式的结果”加新角色不用改旧代码这个红利会随Agent数量增长被持续放大。换个领域看工业场景的“多智能体协同的电网可靠运行”也是同一个逻辑设备监测Agent可以持续上报运行状态调度决策Agent接收这些状态数据做风险评估。两者之间不需要提前绑定接口只要遵循同一套A2A规范和各自的数据Schema就能搭出一条动态协作链。这类场景一旦跑通扩展性远比单体方案好。3.4 A2A落地最容易犯的三个错误一个常见错误是过度设计消息格式。一开始就想把消息协议做成万能的塞了几十个字段结果每个Agent接入成本暴涨。实际上一开始只用几个字段就够了task_id、agent_id、status、payload、timestamp。另一个错误是忽略异常链路。Agent之间传输“成功结果”时很顺但遇到失败怎么重试超时怎么判定结果校验失败是重跑还是升级给人工这些问题不提前定义好系统一上线就全面卡壳。我们内部的原则是宁可让Agent多传失败状态也不要让它静默吞掉异常。第三个错误是把A2A当成同步调用。远程Agent执行任务可能要几分钟甚至几小时如果全程同步等待任何一个环节慢都会拖垮整条链路。A2A的设计应该以异步任务为主配合状态查询和回调通知这才是组织化协作的正确姿势。4. Skills把“会做事”变成可复用的资产4.1 Skills 和“提示词模板”“插件”到底有什么区别很多团队刚开始会把Skills理解成“复杂一点的Prompt模板”这是最大的误解。Skills不只是告诉你“该怎么做”它还携带了完成这件事所需的完整上下文步骤清单、行业知识、代码规范、输出模板、常见错误与规避方法。它更像一份“标准化作业指导书”而不是一句口号。举个例子一个“前端代码审查Skill”不只会说“请检查代码质量”它还会包含哪些安全漏洞是优先项、命名规范是什么、性能检查应该关注哪几个指标、最后按什么格式输出审查结论。Agent加载这个Skill之后行为会从“随便看看”变成“按统一标准执行”。Skills和插件也不一样。插件通常是一段可执行代码而Skills更偏“知识指令规则的集合”它可以引用插件但本身不一定带可执行逻辑。你可以把“插件”理解成工具箱里的电钻把“Skill”理解成一本“如何使用电钻并把墙打直”的施工手册。这也是为什么现在生态里出现了“Skills大全”“Skills推荐”这类资源大家缺的从来不是工具而是“怎么把活干得专业”的方法沉淀。4.2 怎么设计一个真正好用的Skill设计Skill的黄金法则是“单一职责、边界清晰”。一个好用的Skill只解决一个具体问题宁可用5个轻量Skill也不用一个“万能Skill”。以一个我们已经落地的“SQL调优Skill”为例它的内部结构是这样的name: sql-tuning description: 当Agent需要分析慢查询或优化SQL时使用 trigger: - 收到数据库慢查询报告 - 用户要求优化某条SQL - 性能测试出现明显瓶颈 steps: - 获取执行计划 - 检查是否全表扫描 - 检查索引命中情况 - 检查是否有N1查询 - 根据结果给出优化建议 rules: - 禁止直接修改线上数据 - 必须给出“改动前/改动后”对比 - 涉及索引变更必须标注影响范围 output: format: markdown sections: - 问题定位 - 优化方案 - 风险提示 - 验证建议注意到没有Skill里不但有步骤还有“禁止做什么”和“必须给什么”。这两个部分特别重要因为模型很容易在自由度高的环境中“发挥过头”。限制越多产出越可控。再补充一个经验Skills要做版本管理。我见过最头疼的情况是两个Agent用了同一个Skill的不同版本行为表现不一致排错排了半天最后发现是版本差异。用Git管理Skill目录每次修改走评审这个成本一定要付。4.3 初期值得优先沉淀的Skills有哪些按性价比排序我建议先做这几类代码审查类Skill把你们团队的代码规范、检查清单沉淀进去比让模型自由发挥稳定得多。安全排查类Skill把常见漏洞特征、排查路径、修复方案固化下来这类知识最容易流失。数据处理类Skill比如CSV清洗、日志解析凡是重复性高且步骤清晰的任务都适合做成Skill。文档写作类Skill把周报、接口文档、用户手册的格式要求做成模板团队写出来的内容风格会比较统一。前端开发类Skill包含项目目录结构、组件规范、样式约定让Agent写代码时不再“每次风格都不一样”。现在社区里也有“find skills”这类搜索工具能帮你发现现成的技能包。但我的建议是外部Skill可以参考别全盘照搬。真正好用的Skill必须和你们团队的流程、规范、工具链深度对齐否则就是“别人的SOP硬套自己的团队”效果会很差。4.4 Skills和MCP、A2A组合起来是什么效果这三个东西的组合威力我在实际项目中体会很深。假设你要做一个自动代码审查的AgentMCP负责接通GitHub获取PR的diff和文件变更列表。Skill负责告诉Agent“按照什么标准来审查重点看什么输出什么报告格式”。A2A负责把这个审查任务派给专门的Review Agent再把结论送回来给调度层。如果没有MCPAgent连代码都拿不到没有Skill它审出来的东西浮于表面没有A2A它不会主动把结果交给下一个人。只有三者配合才算把“能做事”和“会做事”统一起来。5. DeepAgents给组织加一个“会想”的调度层5.1 DeepAgents 到底指什么又不止是什么“DeepAgents”这个词在不同语境下含义有差异但工程上的共识是它指具备深度推理能力的智能体能在复杂任务中自主规划、执行、反思和修正。普通的Agent是“你问我答最多帮你调个工具”DeepAgents是“你告诉我目标我自己拆解方案干完还自查一遍”。要和后面的工程结构联系起来看DeepAgents更像“大脑皮层”负责统筹全局MCP、A2A、Skills则像四肢和神经负责具体执行。它不只是某一个模型而是一套包含规划、记忆、验证、纠错能力的系统设计。很多人以为“DeepAgents就是模型更大、上下文更长”这个理解是片面的。长上下文只是基础真正的深度体现在它能主动验证中间结果。比如写代码时每完成一个模块就测一遍写文档时每写完一节就对照原始需求检查一次。这种“自己给自己设检查点”的能力才是它跟传统Agent拉开差距的地方。5.2 DeepAgents 和 MCP、A2A、Skills 怎么配合作战我常用的架构可以这样描述规划层用DeepAgents接收目标拆解成子任务决定每个子任务用什么工具、交给哪个Agent。感知层用MCP让规划层实时获取外部信息比如从代码仓库读到最新的代码结构从监控系统拿到线上状态。协作层用A2A规划层把具体子任务派发给专业Agent执行A2A负责状态同步和结果回收。执行层用Skills每个专业Agent在某些特定动作上加载对应Skill保证输出稳定高效。用文本形式画一下DeepAgents规划/调度/反思 ├─ MCP访问工具、数据、系统 ├─ A2A向专业Agent委派任务并回收结果 └─ Skills为Agent提供标准作业方法我实际跑下来最明显的感受是DeepAgents不亲自干每一件事它的价值在于“分诊准确”。它能判断“这个任务是应该自己干还是派给别的Agent更合适”这一点直接决定了整套系统的效率上限。5.3 落地DeepAgents时几个容易被忽略的工程要点一是调度策略先集中后分散。初期建议用一个集中的Orchestrator统一调度哪怕它有些环节跑得慢至少可控。等系统稳定了再逐步允许部分Agent自主协作。一上来就设计“全对等市场式调度”排错会让你崩溃。二是深度推理的成本要控制。DeepAgents的每一次规划、反思都很烧token。不是所有任务都值得“深度思考”。执行非常简单的任务时几秒钟就能出结果你让它反复验证三遍成本和延迟都受不了。我的做法是给任务分级简单任务走预设流程复杂任务才交给DeepAgents规划。三是必须设计“人的回退点”。完全无人值守的DeepAgents在早期风险很高。关键节点比如对外发送消息、修改生产配置一定要留人工审批入口。等运行稳定再逐步放权别一上来就开“自动驾驶”。6. 从单体到组织的实战路径6.1 三步走先盘点、再治理、后拆分想从单体Agent平滑迁移到多智能体组织别一上来就重写。我建议按三步走。第一步是盘点现状。把当前Agent所有能力列出来它能调什么工具、读什么数据、里面有哪些隐含的业务规则、哪部分逻辑是“只有它自己能跑”的。这一步看起来简单却最容易被忽视。我见过有人什么都不盘点直接照着一篇博客拆服务结果拆完发现很多能力是耦合的硬拆之后互相之间传参数传得头大。第二步是治理工具层。把所有稳定的、重复使用的能力封装成MCP Server把核心业务流程沉淀成Skills。这个阶段先不拆Agent只把底座换掉。改完之后你通常会立刻感受到一个好处Prompt变短了上下文腾出来了模型选错工具的概率也降下来了。第三步是引入A2A并拆分角色。先把“规划”和“执行”拆开做一个Orchestrator再做两到三个专业执行Agent。角色不用一次拆太多两到三个就能验证整条链路。6.2 一个最小的多智能体系统长什么样用“研发助手”为例三到四个Agent就能组成一个完整的组织Orchestrator AgentDeepAgents接收需求拆任务汇结果。Code Agent负责写代码加载“前端开发Skills”通过GitHub MCP提交PR。Review Agent负责审查代码加载“代码审查Skill”阅读PR diff。流程很直白Orchestrator拿到需求后先用MCP读取项目文档和代码结构然后判断这活儿自己能不能干、要不要派出去需要写代码就通过A2A给Code Agent发任务Code Agent写完后提交PROrchestrator再通知Review Agent去审Review Agent用Skill里的检查清单审完把结论回传。最后Orchestrator汇总“已实现功能审查结论风险项”输出给用户。这套系统并不复杂但它能跑通全部关键技术链路MCP负责接入外部系统Skills保证执行质量A2A负责Agent之间的协作DeepAgents负责整体调度。任何一个环节出问题都能被单独定位。6.3 什么时候适合启动这场迁移不是所有项目都值得从单体拆成多智能体。我的判断标准很朴素单体Agent的工具超过10个、Prompt超过2000字、任务链涉及多个不同领域的时候就可以考虑拆了。反过来如果它只有两三个工具、任务比较固定硬拆只会徒增维护成本。还有一点要特别提醒多智能体带来的收益是“结构性的”而不是“模型能力性的”。它不会让单个任务的智能化程度变高但会让系统的可维护性、可扩展性、可复用性显著提升。你要想清楚自己到底要的是“更聪明”还是“更可控”。要更聪明可以换模型、加RAG要更可控、更容易规模化才是多智能体的主场。7. 常见问题与排查技巧实录7.1 Agent之间出现消息环路或任务死锁多Agent协作最常见的问题是消息环路A派给BB派给CC又派给A永远转不完。这是A2A落地时的头号坑。我在系统里加了四个保护措施最大委托深度一个任务最多只能被转派三次超过直接返回失败。单任务超时每个Task设置最长执行时间超时后由Orchestrator接管。循环检测在消息头里带task_id的完整路径发现重复出现直接终止。人工兜底连续重试三次仍然失败转给人工处理。这些措施听起来简单但少一个都会出事。我们早期没加循环检测有一次两个Agent因为一个字段格式不对互相踢了三小时的皮球最后整个队列全被堵死了。7.2 MCP Server连接失败工具时有时无MCP Server的稳定性直接影响Agent的可用性。最常见的问题表现是某一次对话中工具还能用重启一下客户端就消失了。排除顺序我一般是这样现象最可能原因快速检查方法MCP工具直接不显示配置未重新加载重启客户端确认JSON配置路径调用时提示连接失败Server进程没起来终端单独跑一次server命令看报错调用超时网络或依赖不可达检查Server后续依赖的数据库/API鉴权失败Token过期或环境变量缺失检查MCP Server进程读到的环境变量工具描述不一致旧Server进程残留杀掉所有残留进程再重启我踩得最深的一个坑是环境变量本地调试没问题部署到服务器上工具就消失排查半天发现是MCP Server启动时没有读取到新环境变量token全是旧值。从那以后我给所有MCP Server都加了启动日志第一行打印配置状态排查效率提升了一个量级。7.3 Skills冲突两个Agent行为对不上Skills多了之后一定会遇到冲突同名不同内容、优先级不确定、版本不一致。我们现在的规范是每个Skill都有命名空间比如 company-frontend-review 而不是 review。每个Skill保存到独立目录不允许互相覆盖。版本号写进元数据引用时锁定大版本。Agent每次加载Skill都记录加载来源方便复盘“它是怎么想的”。这个规范看起来简单但能避免大量“我怀疑模型傻其实它用了旧Skill”的坑。团队里如果有人发现Agent行为突变先查Skill版本有没有被动过大概率有惊喜。7.4 上下文窗口不够用加载了太多东西多智能体系统天然比单体Agent消耗更多上下文因为没有“主Prompt”可以容纳所有知识。解决办法不是强行加长窗口而是减少无用加载。我的原则是“按需加载”四个字MCP Server不是全量挂载而是根据任务路由动态挂载Skills不会一次性全加载而是由Orchestrator根据子任务类型指定加载哪几个长文档优先走MCP Resource按需读取绝不整篇塞进System Prompt。另外状态同步也让A2A的上下文压力不小我通常会要求消息体只传“必要字段”大文件通过引用或对象存储传地址而不是直接内嵌整段内容。这跟微服务间传引用不传大对象的思路完全一致。我个人在实际操作中的体会是这套多智能体架构最难的地方不在技术选型而在克制。克制“让一个Agent包揽一切”的习惯克制“一次加载所有技能”的冲动克制“一上来就设计十种Agent角色”的野心。从最小闭环开始跑把MCP和Skills的基础打牢再让DeepAgents和A2A进场这个顺序能少踩八成坑。后面真正跑起来你会看到它走向组织化的过程和当年单体应用拆服务的那些经验惊人地一致——而这次我们至少提前有了协议和规范。