说实话在Agent开发这个圈子里泡久了你会发现一个特别有意思的演进路径年初大家都在卷单个Agent的上下文窗口年中开始有人把Agent拆成不同角色互相协作到最近光有两个Agent互相发消息已经不够了还得给Agent配上标准化的工具接入、可复用的技能模块、Agent之间的通信协议——整套东西拎出来活脱脱就是一个分布式系统。我最近把DeepAgents MCP A2A Skills这条技术栈完整走了一遍从零搭了一个多智能体集群架构并把它用在实际的协同开发场景里。这篇文章就是这次全流程实战的复盘不写PPT式的理论只讲我踩过的坑、验证过的方案、以及可以直接抄走的工程结构。无论你是刚开始接触MCP协议还是已经在用Codex、Claude做单Agent开发但想往多Agent方向升级这篇内容应该都能给你一条可落地的路径。1. 四个关键词各管哪一段先搞清楚谁在解决什么问题很多人在接触这套组合拳的时候第一个反应是这四样东西是同一个层面的吗答案是不是。它们解决的是完全不同的四个问题我一个个说清楚。1.1 MCP给智能体装上一个标准化的外设总线MCP全称Model Context Protocol是Anthropic在2024年11月开源的一套协议。你可以把它理解成智能体的USB接口——在这之前每接一个工具就要给Agent写一套专用的函数调用逻辑接数据库一套、接浏览器一套、接Git仓库又一套有了MCP之后所有工具都按统一规范暴露给模型。MCP的传输层走JSON-RPC 2.0支持stdio和HTTP/SSE两种方式。它的核心原语有三个tools可被模型调用的函数、resources只读的数据源、prompts预置的提示模板。一个MCP Server本质上就是告诉模型我这里有什么工具、每个工具接收什么参数、调用之后返回什么结构。举个例子我给数据库写一个MCP Servertools里就有query和list_tables这两个工具。宿主Agent启动后模型会自动发现这两个工具在需要查数据的时候就发起JSON-RPC调用。整个过程模型是主动方MCP Server是被动响应方。1.2 Skills把一次性提示词升级成可复用的能力模块MCP解决的是Agent的手能伸到哪里Skills解决的则是Agent遇到某类事情时该怎么干活。一个Skill实际上是一个文件夹里面有一个SKILL.md作为入口附带scripts可执行脚本、resources参考数据、expected_outputs输出格式示例。它把提示词工作流工具调用策略打包成了一个可被Agent按需加载的能力单元。用生活化的方式理解MCP是外设Skills是肌肉记忆。外设可以随时插拔但肌肉记忆是长在身体里的。比如做Code Review这件事你可以每次都在提示词里重新写一遍请检查SQL注入、检查鉴权漏洞、检查异常处理……也可以把它固化成一份code-review-skill让Agent一遇到评审任务就自动加载这套SOP。我现在的习惯是两者配合使用Skill里写清楚要调用哪个MCP工具、按什么顺序调、拿到结果后做什么判断整体就是一个完整的操作手册。1.3 A2A让智能体之间说上同一门普通话MCP是智能体到工具的协议A2AAgent2Agent Protocol是智能体到智能体的协议。Google在2025年4月把它开源核心思想跟HTTP很像每个Agent发布一张名片叫AgentCard放在/.well-known/agent-card.json路径下其他Agent通过这个名片发现彼此的能力和通信地址。A2A里几个关键概念AgentCardAgent的名片声明了名称、URL、能力描述、是否支持流式响应等。Task一个Agent发给另一个Agent的任务对象有生命周期状态submitted、working、completed、failed等支持异步轮询和流式推送。Artifact任务完成后产生的产物可以是文本、文件、结构化数据。Message Part消息的组成部分分为TextPart、FilePart、DataPart让Agent之间能传递文件、JSON等结构化内容。用一句话总结MCP和A2A的分工MCP解决Agent的手A2A解决Agent的嘴。一个工具要对所有Agent开放用MCP一个Agent要对其他Agent可见可协作用A2A。1.4 DeepAgents多智能体集群不是堆数量是工程问题DeepAgents这个词最近有两种用法。一种是Google Gemini 3发布时提到的Deep Agent架构核心思想是解决复杂多步推理任务把一个大任务拆给多个子Agent每个子Agent聚焦单一目标narrow scope并行执行后再汇总避免单个Agent在超长链路上思维走散。另一种是更广义的工程语义指高深度的Agent系统设计——把状态管理、通信协议、任务编排、容错机制当做一个真正的软件系统来设计。我在这篇文章里取的是后者而且我认为它才是多智能体真正难的地方。你可以在一个进程里塞10个Agent让它们互相发消息但如果没有清晰的分层架构最终一定是消息风暴、上下文爆炸、任务无限返工。DeepAgents的核心就是别把多智能体当成提示词工程要当成架构工程来做。2. 多智能体集群的三层架构通信平面、能力平面和编排平面想明白四个概念各管哪一段之后下一步就是把这些东西组装成一个集群。我的做法是严格分成三个平面每个平面只解决自己那一层的问题绝不越界。2.1 一张三层模型图就能说清整个系统的骨架我习惯把这个架构叫两个总线加一个大脑能力平面底层所有MCP Server Skills。这里跑着数据库查询服务、浏览器自动化服务、Git仓库操作服务、静态扫描服务旁边放着一排Skills目录。它们不关心Agent是谁只按照MCP协议暴露能力。通信平面中间层每个Agent注册一个AgentCard通过A2A协议互相发消息。这里管的是任务下发、状态同步、产物传递。它不关心消息内容是什么只保证消息能到达、状态能被追踪。编排平面顶层这是真正干活的大脑。可以是一个主Agent也可以是一个调度服务甚至是一段业务流程代码。它决定当前这个需求该派给谁、谁先谁后、产出物交给谁。这三层的关系等价于一个真实团队里底层是设备数据库、浏览器、代码仓库中间是办公协作协议邮件、会议、任务系统顶层是项目经理拆活、派活、验收。每一层都可以独立替换比如今天你用的宿主Agent是Claude明天换成Codex通信平面和编排平面的代码完全不用动。这里有个很多人问我的问题MCP和Skills都算能力平面它们什么关系我的答案是MCP定义Agent能触及什么Skills定义Agent知道怎么做。一个Skill内部会引用若干MCP工具比如order-export-skill里写了先调用query查订单数据再调用file_writer写入CSV这就是能力平面内部的协作。2.2 为什么MCP不适合充当Agent之间的通信协议圈子里有段时间流行一个玩法让一个Agent把另一个Agent封装成MCP工具A想用B的能力就直接调B暴露的MCP接口。听起来很优雅实践上是灾难。第一个问题是模型不匹配。MCP的工具调用是请求-响应模式一次调用必须同步拿到结果。但Agent之间的协作往往是长任务B可能要跑几分钟甚至几十分钟中间还要跟A确认信息。你用MCP传递这种任务就只能让A死等B的响应没有异步任务状态没有任务生命周期一旦超时就是一团乱。第二个问题是语义不对。工具调用是我命令某个函数执行Agent协作是我委托一个平级角色帮我干一件完整的事。前者是命令后者是协商。你在MCP里表达不出这个任务我还在处理中先发中间产物给你看这种协作语义。第三个问题是职责混乱。如果把Agent互相暴露成MCP工具那整个集群就变成了一张网状的工具调用图没有层级、没有边界、没有任务归属。出问题的时候日志里根本分不清谁在指挥谁。所以我的结论很明确MCP管能力接入A2A管Agent互联两者一个在应用层之下一个在应用层之上各司其职不要混用。这也是为什么Google推A2A的时候特别强调它是Agent互操作协议而不是工具调用协议。2.3 编排模式串行流水线、并行扇出、评审循环怎么混用有了三层架构之后真正的业务逻辑在编排平面。我在实际项目里总结出四种常用的任务编排模式它们不是互斥的而是按需组合。流水线模式Pipeline。一个任务从Agent A流到B再到C上一步的产物是下一步的输入。典型场景是需求分析 → 技术设计 → 编码实现 → 评审验收每个Agent干完自己的活就把Artifact传给下一个。这种模式的好处是职责清晰、每步可验收坏处是整体耗时是各环节之和。并行扇出模式Fan-out。一个调度Agent把一个任务拆成N份广播给多个Worker同时干最后汇总。典型场景是对20个文件做代码扫描——你不会让一个Agent串行看20个文件而是拆成5个批次并发执行。这种模式最考验A2A的任务管理能力每个子任务的状态都要被追踪。竞争评估模式Evaluate。多个Agent各自给出方案由一个评审Agent做选择或投票。典型场景是技术选型比如这个方案用A架构还是B架构可以同时让两个架构Agent出方案再让资深评审Agent做决策。这个模式在AI Agent身上特别有意思因为不同模型、不同提示词方案差异很大竞争评估能减少盲区。评审循环模式Review-loop。编码Agent和评审Agent来回沟通评审不通过就打回编码改了再提交直到评审通过。这个模式最接近真实团队的工作状态但也最容易出问题——两个Agent可能陷入无限返工必须有终止条件比如最大轮次、超时时间。实际项目中我通常是混用的大流程是流水线文件扫描部分做扇出技术选型阶段做竞争评估编码和评审之间永远开着review-loop。这套编排逻辑要么写在一个编排Agent的提示词里要么写在一个调度服务的代码里取决于你的集群规模。3. 从零搭建一个可运行的开发协作者集群前面把原理讲透了下面进入实操。我会带你从零搭一个最小可用的多智能体开发协作者集群每一步都给代码和验证方法。3.1 环境准备宿主Agent、MCP SDK、A2A SDK的选择我这次实战用的组合是Claude Desktop / Codex CLI作为宿主AgentTypeScript版MCP SDK写MCP ServerPython版A2A SDK做Agent互联。选型逻辑很简单MCP生态里TypeScript的文档和示例最全A2A生态里Python的SDK相对成熟宿主Agent选你日常用得最顺的那个就行。环境依赖如下# Node.js 18 环境 node -v # 建议 v18 或 v20 # Python 3.10 环境 python --version # 安装MCP SDK (TypeScript) npm init -y npm install modelcontextprotocol/sdk zod pg # 安装A2A SDK (Python) pip install a2a-sdk装完之后先别急着联调把宿主Agent、MCP Server、A2A Server分开跑各自验证通了再合并。我最开始图省事把MCP Server和宿主Agent塞在同一个进程里跑结果日志全混在一起出了问题根本分不清是Agent的问题还是Server的问题。分开跑这个习惯能帮你省很多排查时间。3.2 第一个MCP Server给Agent接上数据库查询能力以一个简化版的PostgreSQL查询服务为例。这个Server暴露两个工具list_tables和query其中query只允许SELECT语句从源头挡住危险操作。import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; import { Pool } from pg; const pool new Pool({ connectionString: process.env.DATABASE_URL }); const server new McpServer({ name: order-db-mcp, version: 0.1.0, }); server.tool( list_tables, 列出订单数据库中的所有业务表, {}, async () { const result await pool.query( SELECT tablename FROM pg_tables WHERE schemaname public ); return { content: [{ type: text, text: JSON.stringify(result.rows) }], }; } ); server.tool( query, 执行只读SQL查询仅允许SELECT开头的语句, { sql: z.string().describe(只读SQL语句必须SELECT开头) }, async ({ sql }) { const trimmed sql.trim().toLowerCase(); if (!trimmed.startsWith(select)) { return { content: [{ type: text, text: 已拒绝仅允许SELECT查询 }], }; } const result await pool.query(sql); return { content: [{ type: text, text: JSON.stringify(result.rows.slice(0, 50)) }], }; } ); const transport new StdioServerTransport(); await server.connect(transport);这段代码里有一个细节值得注意我加了一个SELECT开头校验。很多人写MCP Server的时候觉得工具是给模型用的模型不会乱来但实际运行中你根本没法保证模型不会构造出危险SQL更没法保证Skill脚本里不会因为参数注入而拼出危险语句。在工具的入口处做一次硬校验是MCP Server最基本的自我保护手段。跑起来之后在Claude Desktop的配置文件里加入这个stdio server并重启然后直接对话问一句你现在有哪些数据库工具如果配置正确模型会告诉你它发现了list_tables和query两个工具。到了这一步第一个MCP接入就算通了。3.3 第一个Skill把Code Review流程打包成技能MCP通了之后我给这个集群加了一个code-review-skill目录结构如下code-review-skill/ ├── SKILL.md ├── checklist.md └── review.pySKILL.md是这个技能的灵魂它告诉模型什么时候该用我、该怎么干--- name: code-review-guard description: 对MR做规范检查输出问题列表与严重级别 when_to_use: 收到评审请求、合并前检查、代码提交后自动触发 --- ## 执行步骤 1. 获取MR的diff或待审文件列表通过git mcp工具 2. 逐项对照checklist.md检查 3. 调用静态扫描工具如sonarqube mcp 4. 输出符合expected_outputs/review_result.md格式的结论 ## 注意事项 - 只报告客观问题不主观评价代码风格 - SQL注入、鉴权漏洞、敏感信息硬编码标记为严重 - 每个问题必须给出文件路径和行号写Skill最容易踩的坑是description写得太含糊。模型是靠description字段决定要不要加载这个Skill的你写代码评审工具四个字模型可能根本不会在合适的时机想到它。我一般会在description里写清楚触发条件、输入是什么、输出是什么。另外一个坑是SKILL.md正文写太长模型读的时候注意力会集中在后半段所以关键的执行步骤写前面注意事项放后面。3.4 第一个A2A互通AgentCard、Task与PostTask能力和技能都有了接下来把两个Agent真正连起来。这里我用A2A协议每个Agent先发布一张AgentCardfrom a2a.sdk import A2AHandler, A2AClient from a2a.types import AgentCard, AgentCapabilities agent_card AgentCard( nameorder-analysis-agent, description分析订单数据的异常与趋势输出结构化结论, urlhttp://localhost:8001/, capabilitiesAgentCapabilities( skills[data-analysis], streamingTrue ) )这个AgentCard就是Agent的名片发布在/.well-known/agent-card.json路径下。其他Agent拿到这个URL之后通过A2A客户端发任务from a2a.sdk import A2AClient client A2AClient(http://localhost:8001/) task await client.post_task( message请分析orders表中过去7天的退款异常数据 ) print(task.task_id) # 拿到任务IDA2A的任务模型是提交-轮询工作方式拿到的task_id可以反复查询状态。一条简化版Task消息长这样{ type: Task, id: task-order-analysis-01, status: working, body: [ { kind: Text, text: 请分析orders表中过去7天的退款异常数据 } ], from: agent-coder, to: agent-analysis }刚开始调试A2A的时候我犯过一个低级错误把AgentCard地址写成了localhost但两个Agent跑在不同Docker容器里互相根本访问不到。A2A互联第一件事就是把网络拓扑画清楚谁在哪个网络、谁通过什么域名访问谁不然光一个地址连通性问题就能让人排查半天。3.5 用一句话验证整个闭环全部接好之后我习惯用一个最小场景做闭环验证。向编码Agent提问查一下orders表里最近7天的数据量然后让分析Agent给出趋势结论。完整链路是这样的编码Agent通过MCP发现数据库查询工具 → 执行list_tables和query拿到数据 → 编码Agent通过A2A把数据作为Task发给分析Agent → 分析Agent返回结构化趋势结论 → 编码Agent把结论整理成文件写入本地。如果这个闭环能在3分钟内跑通说明三层架构的基本盘已经立住了。接下来再往里塞角色、塞编排逻辑都是在扩展这个骨架而不是重新搭一套。4. 全流程协同开发需求、编码、评审、测试四个Agent的一次真实协作骨架搭好之后我把它用在一个真实的开发场景里给一个Java后端项目加一个订单导出功能。整个过程由四个Agent协作完成我用这个案例把编排、通信、上下文管理的细节都讲清楚。4.1 角色分工每个Agent该握有什么工具、产出什么工件多Agent集群最忌讳的事情就是人人有责但没人负责所以角色边界必须先定死。我这套集群的角色分工如下角色核心工具MCP/Skills主要职责交付物架构Agent代码库浏览MCP、设计文档Skill分析需求、产出技术方案设计文档Artifact编码Agent代码库读写MCP、编码规范Skill实现功能、修复合入问题代码变更、MR评审Agent静态扫描MCP、code-review-skill检查MR、发现问题评审报告测试AgentPlaywright MCP、测试用例Skill冒烟测试、回归验证测试报告可以看到每个Agent握的工具和Skills都是不完全一样的。架构Agent不需要数据库查询工具测试Agent必须要有浏览器操作能力。工具按角色绑定是控制集群复杂度的重要手段如果你给每个Agent都配上全部工具模型的工具选择空间太大反而容易在错误的场景调用错误的工具还会增加上下文负担。4.2 一次迭代里的A2A消息流从需求到测试报告的完整链路这个功能迭代的真实流程是这样的第一步架构Agent接收到订单导出需求通过代码库浏览MCP摸清了现有订单模块的代码结构产出设计文档。第二步编码Agent收到架构Agent发来的设计文档Artifact通过代码库读写MCP新增导出接口和前端按钮生成代码变更提交MR。第三步评审Agent收到编码Agent的评审请求消息拉取MR中的diff触发静态扫描MCP同时用code-review-skill逐项检查发现了一个问题导出SQL用了动态拼接存在注入风险。第四步评审Agent把问题列表通过A2A反馈给编码Agent编码Agent收到后修改代码把SQL改成了预编译参数化查询重新提交。第五步测试Agent收到测试请求用Playwright MCP打开导出页面点击导出按钮验证CSV文件生成成功且数据正确产出测试报告。整条链路的关键在于每一条Agent间的消息都比上一轮的更收敛。架构Agent传给编码Agent的是设计文档的一句话摘要编码Agent传给评审Agent的是要评审的MR链接变更范围评审Agent传回来的是一条条带文件路径、行号的具体问题。消息不是越详细越好而是越刚刚够越好。4.3 上下文爆炸的解法产物小步快跑与任务断点续跑多Agent协作最大的技术敌人是上下文爆炸。如果Agent A把整个设计文档原文传给Agent BB又把全部内容传给C三轮之后每个Agent的上下文里都塞满了重复信息模型表现会急剧下降。我的解法是两条原则第一条Artifact小步快跑。A2A传递的产物只保留下游Agent真正需要的那部分。比如架构Agent产出10页设计文档但传给编码Agent的只需要其中接口定义、表结构变更、涉及文件清单三块。我会在架构Agent的Skill里写死输出格式让它把设计文档拆成几个标准字段而不是输出一整篇散文。第二条任务状态可追踪、可续跑。A2A的任务状态机和Artifact版本化机制让断点续跑成为可能。比如评审Agent发现10个问题返回给编码Agent编码Agent修完一半的时候宿主崩溃了——没关系重启后只要找到那个task_id就能看到任务当前状态和已完成的Artifact版本从断点继续而不是全盘重来。这也是我强烈建议用A2A而不是用简单消息队列的原因消息队列只保证消息到达A2A还管理任务生命周状态这是多Agent长跑到最后不散架的关键。5. 接入路上的坑Codex授权、浏览器MCP选型、企业内网集成这套架构跑通之后我又花了一周时间把宿主Agent从Claude切换到了Codex并且把它接到各种真实环境里。这段路上踩的几个坑我认为比搭建过程本身更有分享价值。5.1 Codex接入远程MCP的授权细节Codex CLI接入本地stdio MCP Server是可以自动发现的但接远程HTTP的MCP Server就得手动配置。配置写在app.json的mcpServers字段里有两个坑特别容易踩。第一个是Authorization头。远程MCP Server通常要token认证很多人习惯直接把token拼在URL里比如http://user:passhost/mcp这在日志里会泄露凭据而且有些HTTP client解析这种URL还会报错。正确做法是在配置里用环境变量引用{ mcpServers: { order-db: { type: http, url: https://mcp.internal.example.com/order-db, headers: { Authorization: Bearer ${MCP_ACCESS_TOKEN} } } } }第二个是超时设置。Codex调用远程MCP工具的时候如果Server没在预期时间内返回工具调用就会失败。有些MCP Server初始化要加载大数据字典很容易超时。我的经验是给远程MCP Server加上健康检查和预热机制首次调用前先拉一次initialize别让模型去承担冷启动的延迟。还有个更隐蔽的问题Codex对工具参数的类型校验特别严格你在zod里写z.string().default()模型不一定理解为什么默认值是空字符串可能直接就不传这个参数了。尽量别给MCP工具设计带default值的参数要么必填要么真的可选。5.2 Browser Use MCP与Playwright MCP两套思路别选错做前端开发或测试相关的Agent集群迟早要接浏览器自动化。市面上最常用的两个方案是Playwright MCP和Browser Use MCP很多同学拿不准选哪个。我两条路都用过简单说结论维度Playwright MCPBrowser Use MCP定位方式DOM选择器、Accessibility树视觉理解页面截图适用场景表单填写、按钮点击、端到端测试内容抓取、跨站点操作、页面结构不清晰的场景依赖本地Node/Python环境浏览器扩展 视觉模型能力稳定性高操作可精确复现中依赖视觉模型判断精度调试难度低选择器可直接查偏高模型眼瞎时很难定位我的选择逻辑是凡是我知道页面结构、操作路径明确的活儿比如测试Agent点击导出按钮、填写搜索框一律用Playwright MCP因为它的DOM选择器定位精确、速度快、错误可复现。凡是要在页面结构我不关心只要把信息抓全的场景比如期望Agent自己找到某个链接点进去再用Browser Use方案。还有一条安全提醒浏览器MCP属于高危能力。如果你的多Agent集群接入了浏览器自动化必须限制只有测试Agent能用而且要么在无头环境里跑要么加白名单只允许访问特定域名。否则某个Agent被恶意页面提示词注入可能被诱导去执行危险操作这不是危言耸听是已经发生过真实案例的风险。5.3 企业项目融合MCP/Skills内网隔离、权限收敛与审计很多读者会问这是不是只能玩玩具Demo能不能接进真实的企业项目我正好做过一个把MCP能力合并到若依这类企业级Java后台的改造说三个最要命的注意点。第一MCP Server必须做网络隔离。企业项目的数据库查询MCP、代码库MCP绝对不要直接暴露在公网。我的做法是让MCP Server只监听内网回环地址通过反向代理加IP白名单发布涉及数据库的MCP Server连反向代理都不挂只允许宿主Agent所在的内网网段访问。第二工具权限必须收敛到用户维度。如果一个企业后台接入了MCP让Agent以数据库超级账号的身份直查那就等于给模型发了一张万能通行证。正确的做法是MCP Server在工具方法内部做二次鉴权先解析当前会话的用户身份再决定这个查询可不可以执行。比如普通用户只能查自己创建的订单管理员才能全量查询。第三审计日志必须落到业务系统里。MCP调用不能只打印在Agent的进程日志里要回写到企业自身的操作日志表尤其是write类工具。这样出了问题能追踪到哪个Agent、在哪个时间、以哪个用户身份、执行了什么操作。我在改造中见过不少项目只关心功能通不通完全不关心权限和审计这在企业环境里是过不了安全评审的。5.4 为MCP工具分级只读、低危写入、危险操作最后分享一个我在多Agent集群里强制的工具分级策略。不管接了多少MCP Server我都会把它们暴露的工具按危险程度分成三级只读级SELECT查询、文件读取、列表获取。这类工具所有Agent可用。低危写新增数据、生成文件、发送消息。限定特定角色比如编码Agent才能写代码文件。高危操作删除数据、改表结构、执行任意脚本、修改权限。默认禁用只能在编排层通过显式授权命令临时开通且必须留审计日志。这套分级我会通过两层来实施一层在MCP Server内部直接做强校验另一层在Skills层面Skill里写明本Skill涉及的操作为低危写仅限编码Agent调用。两条线同时卡住才能防止模型在单个Agent内部被绕过去。为什么不直接让编排层做全部限制因为我发现模型在工具选择上偶尔会灵机一动如果你只在编排层设置权限Agent可能会绕过编排层直接跟MCP Server对话。纵深防御的思路放在多Agent集群里同样适用能力平面自己守住第一道关编排平面守第二道别把所有信任放在某一个点上。把这套架构从零搭起来、又从单Agent切换到多Agent再到接真实项目最大的感受是多智能体的价值从来不在数量多而在于把每一个Agent的边界定义清楚。两个硅基员工之间如果没有协议和编排一样会互相踢皮球、无限返工但当你给它们配上了MCP这个手、A2A这张嘴、Skills这套肌肉记忆它们就能像一支纪律严明的团队一样把一个需要数天的需求迭代压缩到几十分钟跑完。最后分享一个排查问题的小技巧从第一天起就给你的Agent日志加上固定前缀比如[ARCH]、[DEV]、[REV]、[TEST]并把A2A的task_id印在每一条关键日志里。多智能体跑起来的噪音量远超单Agent没有前缀和任务ID出了Bug你根本没法定位是哪一环出的问题。这也是我整个实战项目里成本最低、收益最高的一次改进。