Multi-Agent开会机制：如何解决复杂工程中的上下文碎片化问题

1. 先把痛点聊清楚：单模型为什么压不住复杂工程

我最近在推进某跨平台系统升级项目，需求面拉得很宽：前端交互、后端调度、数据迁移、性能优化都要同步推进。最初我图省事，把全部项目背景塞进单个模型的上下文，让它一口气输出整体方案。前面一两版看起来还有模有样，越往后越不对劲，模型开始忘掉之前定义过的接口名，逻辑前后打架，甚至同一段需求在不同模块里给出了两个相反的实现方式。

这种问题并不是模型“变笨了”，而是上下文碎片化的典型表现。单个模型在一个很长的会话里，需要同时跟踪几十个变量：接口字段、模块依赖、验收标准、历史决策……当这些信息叠加在一起，模型很难时刻牢记所有约束，注意力会被最近讨论的话题拽走。工程越复杂，这种“遗忘”和“自相矛盾”出现得越频繁。

我一开始以为换更强的模型能解决，结果只是缓解。原因是本质性的：问题不在于单次推理的能力，而是“单线程上下文”扛不住多领域并发。就像让一个全科医生同时做外科手术、影像诊断和药房管理，他再厉害也只长了一双手和一个大脑，撑不起多角色并发的局面。

1.1 上下文碎片化：复杂度的第一杀手

复杂工程的第一个敌人就是上下文碎片化。做过长对话的朋友都知道，模型对早期内容的记忆会随着轮次增加迅速衰减。当你在一个会话里既讨论前端组件，又讨论后端数据库索引，还讨论部署流水线，这几块内容根本没有天然的逻辑粘合度，模型就只能在“最近聊什么”的引导下做短时判断。

我实测下来的一个典型情况是这样的：在第三轮让模型补充“订单查询接口”的字段定义，它还知道要和前端的交易列表页对齐；到第八轮再问它同样的问题，它给出的字段名变成了另一套，和当初设计的完全不匹配。如果你追问，它还会斩钉截铁地告诉你这是“按你之前要求实现的”。这就是典型的上下文漂移。

要解决问题，光靠裁剪对话长度是不够的，因为在复杂工程里，这些信息都是“有用的”，剪掉哪一个都可能造成信息缺失。正因如此，才需要引入多Agent的“分舱”机制，把不同专业域的信息彼此隔离，各管各的一段，最后再靠会议机制统一结论。

1.2 角色冲突：一个人同时演多个角色必翻车

单模型处理复杂工程还有一个隐蔽问题，就是角色冲突。当你在提示词里写“你既要当架构师，又要当测试工程师，还要当运维专家”时，模型往往会在某一段变成“万能角色”，却在下一段忘记自己刚才的立场。

我之前让一个模型同时承担方案设计和代码审查，模型一开始热情地给出了一套方案，轮到自己审查时，却反过来给自己找各种理由开脱，把明显的缺陷包装成“后续优化点”。这不是态度问题，而是角色切换时输出分布不稳定，模型对多角色指令的执行往往不及单独设定时彻底。和人一样，你自己写的方案让你自己来挑刺，你会下意识护短，模型也会。

Multi-Agent开会最直接的价值，就是把“一个人演多个角色”变成“多个人各演一个角色”。角色分离以后，每个模型只需要维持一个稳定的小上下文，反而能更专注地做判断。工程上这个思路有一套成熟理论做支撑，就是关注点分离（Separation of Concerns），只不过这次被用在了模型协作层。

1.3 什么样的工程真的需要开会，哪些不需要

不是所有任务都值得请一桌Agent。我判断“要不要开会”主要看三条：

• 任务是否有明显的模块边界，而且模块之间存在强依赖关系
• 任务是否需要多轮验收，光靠一次生成很难把质量拉到位
• 任务是否包含多视角判断，比如既要效率又要合规，既要实现又要可维护

如果三条都不占，比如只想生成一个简单的脚本或一封简短邮件，别纠结Multi-Agent，单个模型一次搞定反而更高效。开会是有成本的，角色提示词、会议轮次、上下文隔离都需要消耗资源和时间，过度设计会把简单问题复杂化。

如果占了至少两条，比如跨平台系统的升级、大型报告写作、包含前后端联调的功能开发，那么把任务拆给多个Agent并行加审查，收益会非常明显。这个判断标准，就是我与“让Agent开会”之间的总体原则。

2. Multi-Agent开会的核心机制：角色、议程、黑板

开会不是把几个模型拉到一个群里自由讨论，而是有角色、有议程、有信息管理。这一节我把底层机制拆开讲，因为后面很多问题，追根溯源都出在这三项设计上。

2.1 角色设计：职责越不重叠，协作越稳定

Multi-Agent开会的第一步，是设计角色，而不是选框架、写代码。角色定不好，后面全是返工。我实战中偏爱的方案是四个核心角色：规划者、执行者、审查者、记录员。

规划者负责拆目标。它把一个大任务拆成一串可验证的子任务，明确每个子任务的输入、输出和验收标准。执行者负责动手，它可以有多个并行实例，比如一个写前端、一个写后端。审查者负责找茬，它只盯住产物是否满足验收标准，不做扩展，不改代码。记录员负责收敛，它把每轮讨论变成结论，维护“决定、待办、风险”三张表，供后续环节引用。

这四个角色的职责边界必须非常刻意地分割。规划者不能亲自写实现，审查者不能越位提需求，执行者不能顺手改变需求。角色之间的职责一旦重叠，就会出现“抢活儿”或“甩锅”，会议质量会成倍下降。

这里有个容易踩的坑：角色数量不是越多越好。我曾在一版设计里加了“用户体验顾问”“风险分析师”“技术顾问”等一堆角色，结果多个角色输入相似，提出的意见高度重复，既浪费了token，又把议题搅乱。后来我砍到四个核心角色，效果反而更好。如果你觉得项目需要更多专业视角，优先把审查者拆成不同的专业审查者，比如“前端审查Agent”“接口契约审查Agent”，而不是让每个人不谈全局。

2.2 回合制议程：从自由发言变成结构化表决

角色定好了，下一步是定“怎么说话”。最省事但效果最差的，是让所有Agent在同一个对话里自由发言。你会发现几个问题：没人聚焦当前议题；意见会互相传染；时常出现重复论证；最后结论是谁嗓门大谁说了算。

所以我把流程改成回合制。一个典型的会议回合是这样：

1. 规划者宣读任务，把任务拆成编号子任务
2. 执行者按编号认领子任务，在指定区域输出产物
3. 审查者读取对应区域，输出结构化判断：通过或打回
4. 如果打回，返回执行者重做；如果通过，进入记录员汇总
5. 记录员汇总当前回合的决定与待办事项，更新公共信息区

这里最关键的，是每一步都必须输出结构化的结果，而不是“口语化闲聊”。执行者输出代码或文档，审查者输出结构化判断，记录员输出三张表。这样整个会议流可以被自动化路由接管，而不是靠模型自由心证。

返工循环一定要有上限。我一般把每个子任务的最大返工次数设为3或4。超过上限后，我不会让会议继续耗下去，而是把争议交给规划者做降级决定——要么替换思路，要么把风险写入待办并先行交付主体。没有上限的会议，看起来像是在精益求精，实际上是在烧钱。

2.3 黑板模式：让每个Agent少读80%的上下文

复杂工程的上下文一定很大，如果不做裁剪，每个Agent都会被全量历史淹没。我采用的方案是黑板模式：把全局信息、私有信息、索引信息分开放，Agent只读取自己需要的分区。

具体实现上，可以简化成一个键值存储，每个分区对应一个键。公共区放项目背景、总体目标、全局约束。私有区放每个子任务自己的输入、输出、审查记录。索引区放决定表、待办表、风险表。Agent领取任务时，看到的是类似“任务编号T3：输入key_a_3，输出写到key_b_3，审查结果key_c_3”这样的指令，而不是整份聊天记录。

第一次改造时，我的体感是token消耗下降非常夸张。最初版本不做裁剪，四个Agent每一轮都读全部历史，一轮完整会议跑下来，成本高得接近失控。换成黑板模式以后，每个Agent平均只需要读原先五分之一的内容，而且单轮生成延迟也明显降下来了。会议能不能支撑复杂工程，信息组织方式往往比模型大小更关键。

3. 从零搭建一套可运行的Agent会议流

光聊概念没有用，这一节我分享一套最小可运行方案，包含框架选型、极简实现、提示词设计和参数初始化。你可以直接复用，也可以从这套模板出发，改成自己的结构。

3.1 框架选型：图编排与角色协作怎么选

实现Multi-Agent流程，市面上的框架其实分成两条路子。一条是图编排，把每个Agent作为图里的节点，把消息传递作为边，通过条件边控制路由。这条路子的优点是逻辑清晰，适合分支复杂、需要循环的流程。另一条是角色协作，用团队的概念把Agent和任务组合起来，上手快，适合相对固定顺序的流水线。

我给模拟项目X选型时，考虑的是项目里既有多模块并行，又有反复审查回环，所以用图编排的框架会更顺手，因为可以在图的层级控制“审查者打回执行者”这个循环。如果只需要做一个“搜集信息→分析→输出结果”的固定流水线，用角色协作框架会更省事。

这里提醒一句：不要因为框架热门就硬套。先画出你需要的会议流分支图，再选框架，否则后期改路由逻辑会非常痛苦。分支图的复杂程度直接决定了你应该选择哪一类框架，这个判断顺序不能反。

3.2 最小可运行的会议流实现

搭建其实就是定义角色、定义状态流、定义取舍逻辑。我贴一段接近项目的伪代码，方便说明整体结构：

# 伪代码：最小版本的Agent会议流 graph = Graph() # 用图结构编排 graph.add_node("planner", planner_agent) graph.add_node("executor", executor_agent) graph.add_node("critic", critic_agent) graph.add_node("scribe", scribe_agent) graph.add_node("start", start_event) graph.add_edge("start", "planner") # 实现者产出先交给审查者 graph.add_edge("planner", "executor") graph.add_edge("executor", "critic") # 审查者决定是回归还是进入记录会议 graph.add_conditional_edge( "critic", route_based_on_critic_result, {"redo_executor": "executor", "to_scribe": "scribe"} ) graph.add_edge("scribe", "end")

关键在于route_based_on_critic_result这一步。审查者不看完整对话，只看子任务的产物与验收标准，然后给出一个结构化判断：是“通过”“打回重做”还是“需要讨论”。这个判断字段必须是模型输出中的JSON，我限制它必须包含status和reason两个字段，少了任何一个字段，路由逻辑都把它当作无效结果处理。这能保证会议流的走向是可预测的，而不是模型随口一句“我觉得可以”就算通过。

3.3 提示词设计：把角色焊死在岗位上

Agent的提示词直接决定了会不会跑偏。以审查者为例，我使用的模板大概是这样：

你是项目审查者，只做一件事：检查执行者提交的产物是否满足验收标准。 验收标准如下：{验收标准} 请只输出JSON：{"status": "pass" 或 "redo", "reason": "..."} 不要尝试修改产出物，也不要输出报警标准之外的改进建议。

这个设定很刻意：一是限定“只做一件事”，防止审查者越权；二是要求输出结构化JSON，方便路由；三是禁止给出建议方案，防止审查者发散。很多Multi-Agent跑偏，经常是因为某个角色的提示词写得像“万能助手”，带了太多模棱两可的能力边界，根本没有约束力。

执行者的提示词则可以写成：

你是前端实现者，负责完成以下子任务：{任务描述} 只输出最终代码或文档，不要输出过程性讨论。 参考上下文：{黑板中的私有分区地址} 规则：如果输入不清晰，先输出 NEED_CLARIFY，不要猜测。

加上NEED_CLARIFY这个动作很关键，它把“信息缺失”和“执行失败”区分开了。否则执行者会自行补全不合理假设，埋下隐患，最后浪费好几轮审查才发现问题。这类小硬性规定，比反复告诉Agent“你要仔细”有效得多。

3.4 会议参数的初始设置

会议流程跑起来以后，有一批参数需要提前定好。我整理了一张初始参数表，可以作为起步配置：

这些参数不应该是一成不变的。比如执行阶段我习惯把返工次数设低一点，因为高频快速地出小版本，比硬磨一个大版本更划算。但如果是核心架构设计，我会把返工次数放宽，同时把置信度阈值抬高，让审查者更严格。参数背后的逻辑永远是对“质量”和“成本”的权衡，而不是盲目照搬。

4. 会议之外的工程化要点

很多人以为多Agent开会就是把“讨论”做好就完了，实际上真正决定项目成败的，反而是会议之外的信息工程。这里讲三个关键点：防止回声效应、控制上下文预算、规划并行边界。

4.1 防止回声效应

回声效应是Multi-Agent协作里最隐蔽的坑。现象是这样的：AgentA在讨论中说了一个不准确的推断，AgentB没有核实就把它当作既成事实，接着往下推导，再把结果传回给AgentA。几轮下来，两个Agent都坚定地相信了一个错误结论，而且因为“对方也这么认为”，各自都觉得自己是对的。

我踩过这个坑。某个图像处理Demo项目里，因为并行Agent自由讨论，最后整个方案在“图片缩放比例”上达成了一致错误，直到人工复核才发现。从那以后，我在每个Agent的提示词里都加了三条硬约束：必须有独立事实源，不能只依赖其他Agent的发言；遇到与事实冲突时，以独立验证结果为准；低于置信度阈值的结论不允许进入下一阶段。

这几条约束让会议从“互相客套”变成了“事实核查”。说白了，开会不是为了让各方越来越认同，而是要把分歧和证据留在桌面上，最后让人或决策逻辑来拍板。

4.2 上下文预算与成本控制

Multi-Agent最容易被忽视的成本，是上下文重复。假设五个Agent都读同样2万字的全局背景，每增加一个Agent就多两万字基础消耗。我之前用黑板模式，把原来的全量读取改成按需读取，成本立刻下来一大截，推理速度也变快了。

除了按需读取，还有几个降本技巧：

• 用短标题索引代替完整段落传给Agent
• 将局部结果用摘要替换原始转写
• 给公共信息设置过期时间，定期让记录员重写“会议概要”
• 对历史讨论做衰减加权，过期的旧讨论不再参与路由判断

有一次测试，Agent数量从4个增加到6个，没有做裁剪时，一次完整任务的令牌消耗上升了接近80%。加了按需读取和摘要重写后，同样是6个Agent，消耗只比4个时多了约25%。这个数字不见得有普适性，但思路是确定的：会议复杂度每增加一点，都要用信息的可控性去换。

4.3 并行任务和开会任务的边界

并不是所有任务都需要“开会”。如果子任务之间完全独立，就应该让多个Agent并行跑完，最后汇总，而不是设计一场“会议”把它们凑到一起。如果子任务之间有先后依赖、需要反复验收，那么让它们进入编排流程才是合理的。

我在模拟项目X里做过一个很典型的划分：数据迁移脚本与前端页面重构，彼此无强依赖，直接并行交给不同的执行者Agent；后端调度逻辑与前后端接口定义，有强依赖，放进同一个会议流，先定义接口，再编写调度，再审查。这个区分看似简单，但显著减少了无谓的会议轮次。开会是有成本的，要把成本花在真正跨域的问题上，而不是用会议代替普通并行任务。

5. 常见问题与排查速查

Multi-Agent流程跑起来以后，问题不会消失，只会换一种方式出现。下面几类问题是我实操中反复遇到过的，整理成速查表供你对照排查。

5.1 会议主题跑偏

典型症状是规划者宣布的任务没人遵守，执行者开始自作主张地给其他模块提需求，审查者变成“全能评审”。绝大多数情况是提示词职责不清，或者共享上下文里没有“当前议程”控制字段。

解决办法是把议程当成不可更改的全局变量：所有Agent的输入里都必须带“当前议程编号”，如果模型输出明显偏离当前议程，路由直接打回，不对跑偏发言做任何后续处理。这样跑偏内容会被“物理丢弃”。我实测后发现，加上这个机制后，跑偏率下降非常明显。

5.2 会议收敛不了

典型症状是审查者总是打回，循环次数到上限时，整个流程卡死或者原地转圈。先排查是不是验收标准过于模糊。没有明确的分值或通过条件，审查者永远能挑出毛病。一定要给出“通过”的明确标准，例如“编译通过、测试用例全部通过、代码里没有TODO”。

另外还要为“争论不止”设置熔断：返工次数超过上限就触发人工评审或降级方案。降级方案可以是“把未解决争议写入待办事项，优先保证主体交付”。一个项目能交付一个稳定版本，好过为了完美永远停在讨论阶段。

5.3 上下文膨胀导致延迟

典型症状是运行到中后段，每个Agent都在反复读写上下文，单轮延迟明显变长。解决思路是把会议历史改成增量存档：记录员只追加概要索引，原始细节放外部存储，需要时再检索。

还可以把讨论内容汇总成“决定、待办、风险”三张表，放回黑板。这个“三表约束”让Agent在取用信息时，不需要逐字回溯讨论内容，而是直接看结论和风险。处理后你会发现，越长的任务，这种优势越明显。

5.4 角色漂移

典型症状是规划者有时候像审查者在批评，有时候又像执行者在写代码，角色边界不稳定。解决办法是在结构化输出里增加角色校验：每个Agent输出时都必须带一个固定的role标签，路由层检测输出字段与目标角色不一致时，直接丢弃或要求重写。

很多框架在提示词里讲“你是一个规划者”，但光靠提示词不够，需要和路由约束绑定，输出层面的校验才有实际约束力。

5.5 快速排查表

最后整理成一张速查表，方便你直接对照：

6. 最终观察与一些经验

6.1 真正的关键是约束，不是智能

我折腾Multi-Agent的时间不算短，最深的体会是：Multi-Agent协作能不能成功，不取决于把几个聪明的大模型凑在一起，而在于你给它们划了多少条边界。边界越清晰，协作越高效；边界模糊时，哪怕底层模型再强，也会在会议里绕圈子。

刚开始我把“让多个Agent开会”简单理解成“让多个模型自由对话”，结果无非是上下文暴增、输出质量降级。后来把会议流程改成角色分工加回合制、加黑板模式、加条件路由，最大的变化不是“更智能”，而是“更可控”。模型本身还是同一个模型，但约束机制把它变成了一个能连续交付工程产出的团队。

6.2 值得一试的下一步扩展

这套会议流还可以再往前走半步。我个人目前在尝试把会议结论直接接入交付流水线，让审查者的“通过”信号变成自动发布的触发条件。这样一来，Multi-Agent就不只是讨论分任务，而是真正嵌入了交付链路。

不过要特别注意，接入自动化以后，人工总控环节还是要保留。我习惯在每个子任务的关键节点设置一个“人工确认闸口”，只有到了约定的检查点，才允许会议流自动推进。毕竟在不一致或卡住时，一个清醒的人工审查者，比上百个Agent绕圈子都重要。

最后分享一个小技巧：在每次会议开始时，让规划者先输出“本次会议的完成定义”，并发给所有参会Agent作为共同验收锚点。这个动作看似简单，却能避免至少一半以上的返工，因为多数返工不是Agent不会做，而是它们理解错了“做完”的标准。