Multi-Agent 协作——让几只虾一起干活｜卷卷养虾记 · 第七篇

卷卷养虾记 · 第七篇先说一个让我意识到问题的瞬间财年年底我要做年度汇报。这事不简单。要从全年数据里提炼趋势把技术语言翻译成业务语言把复杂的风控逻辑变成领导能看懂的故事最后组织成一个有说服力的 PPT 结构。我让卷卷帮我做。它开始工作。然后我发现了一个问题它在做数据分析的时候上下文里塞满了原始数据。等它开始写叙事的时候已经「忘了」一开始分析出来的关键结论。等它开始做 PPT 结构的时候又把叙事的逻辑搞混了。一个 Agent同时做三件性质完全不同的事上下文越来越重注意力越来越分散。最后的结果每一块都差一点。那天晚上我第一次认真想了一个问题什么时候一只虾不够用什么时候需要多 Agent不是所有任务都需要多 Agent。大多数任务一个 Agent 就够了。多 Agent 的代价是真实的更复杂的配置、更多的 token 消耗、更难排查的问题。所以在决定用多 Agent 之前先看有没有这些信号① 任务需要同时保持多个「专业视角」同时需要数据分析师的严谨 产品经理的叙事 汇报者的政治敏感度。一个 Agent 很难同时扮演好三个角色。② 任务的不同阶段上下文会互相污染数据处理阶段的大量原始数据会干扰后续写作阶段的注意力。把它们分开每个 Agent 只看自己需要的信息。③ 任务的某些部分可以真正并行同时调研三个竞品互不依赖没有理由排队等一个 Agent 一个个来。④ 任务需要「互相审查」来保证质量一个 Agent 写另一个 Agent 挑毛病。同一个 Agent 自我审查效果很差。如果以上都不符合用一个 Agent 就好。别为了「高级」而复杂化。主 Agent 和子 Agent 的分工原则多 Agent 系统里最常见的结构是一个主 Agent若干个子 Agent。主 Agent 负责什么理解意图、拆解任务、分配工作、整合结果。它是项目经理不是执行者。子 Agent 负责什么在自己的专业范围内把一件事做好。它是专家不需要理解全局。一个容易犯的错误让主 Agent 既做管理又做执行。这就像让项目经理一边开会一边写代码两件事都做不好。主 Agent 的 AGENTS.md 里应该明确写## 我的职责边界 我负责 - 理解用户的最终目标 - 把目标拆解成子任务 - 决定哪个子 Agent 处理哪个子任务 - 整合子 Agent 的输出形成最终结果 - 向用户汇报进度和结果 我不负责 - 直接执行数据分析交给>边界写清楚主 Agent 才不会越权。三种常见的多 Agent 架构架构一串行Pipeline用户 → 主Agent → 子Agent A → 子Agent B → 子Agent C → 结果适合什么场景每个步骤依赖上一步的输出必须按顺序来。典型案例数据清洗 → 数据分析 → 报告撰写 → 格式排版优点逻辑清晰容易排查问题。缺点慢。任何一个环节出问题后面全卡住。关键配置每个子 Agent 的输出格式要严格定义因为它直接是下一个子 Agent 的输入。格式不对整条流水线断掉。架构二并行Fan-out / Fan-in→ 子Agent A ↘ 用户 → 主Agent → 子Agent B → 主Agent整合 → 结果 → 子Agent C ↗适合什么场景多个子任务互不依赖可以同时进行。典型案例同时调研三个竞品、同时翻译成三种语言、同时从三个数据源拉数据优点快。三件事同时做时间是最慢那个不是三个加起来。缺点整合阶段容易出问题。三个子 Agent 的输出风格、格式、详略程度可能差异很大主 Agent 整合起来很费劲。关键配置给每个子 Agent 规定统一的输出格式。整合才能顺畅。架构三专家委员会Panel用户 → 主Agent → 子Agent A发言 → 子Agent B发言 → 主Agent综合判断 → 结果 → 子Agent C发言适合什么场景需要从多个角度评估同一个问题最终做出综合判断。典型案例策略评审技术可行性 业务价值 风险评估、方案选择、复杂决策优点质量高。不同视角互相补充减少盲点。缺点贵。每个子 Agent 都要读完整的问题描述token 消耗是并行的几倍。关键配置每个子 Agent 要有明确的「立场」否则三个 Agent 会说出差不多的话失去了多视角的意义。案例我用三个 Agent 完成年度汇报回到开头那个场景。意识到问题之后我重新设计了整个流程。三个 Agent串行 并行混合我 → 主Agent协调 ↓ >data-agent 的职责只做数据。读原始报表提炼关键趋势输出一份结构化的「数据结论文档」。输出格式是固定的## 数据结论文档 ### 核心指标变化 - [指标名][今年数值] vs [去年数值]变化 [/-X%]趋势 [上升/下降/平稳] ### 值得关注的异常 - [异常描述][可能原因] ### 数据支持的核心结论不超过3条 1. ... 2. ... 3. ...格式固定writer-agent 才能直接用。writer-agent 的职责只做叙事。读>它不看原始数据。原始数据不是它的事。reviewer-agent 的职责只做审查。读 writer-agent 的草稿从「领导视角」挑毛病逻辑是否清晰有没有没说清楚的地方有没有可能引起误解的表述结论是否有数据支撑它不改稿只提意见。改稿是 writer-agent 的事。结果这次年度汇报是我做过质量最高的一次。不是 Agent 更聪明了。是每个 Agent 只做一件事做得更专注做得更好。多 Agent 系统的常见问题用了一段时间总结了几个高频问题⚠️问题一子 Agent 的输出格式不稳定同样的指令有时输出 JSON有时输出自然语言下一个 Agent 解析失败。→ 解决在子 Agent 的 SKILL.md 里用示例而不是描述来定义输出格式。「输出如下格式」不如「输出示例如下[具体示例]」。⚠️问题二主 Agent 越权执行主 Agent 觉得「我自己来更快」跳过子 Agent 直接执行结果质量下降还破坏了流程的可预期性。→ 解决在主 Agent 的 AGENTS.md 里明确写「我不直接执行以下任务」并列出清单。⚠️问题三子 Agent 之间互相等待本来可以并行的任务因为配置问题变成了串行速度没有提升成本却翻倍。→ 解决在主 Agent 的任务分配指令里明确标注哪些子任务可以并行启动哪些必须等待前置完成。⚠️问题四整合阶段信息丢失主 Agent 在整合三个子 Agent 的输出时把某个子 Agent 的关键结论漏掉了最终结果残缺。→ 解决要求主 Agent 在整合前先列出每个子 Agent 的核心输出摘要确认无遗漏后再整合。信息在 Agent 之间传递时的失真问题这是多 Agent 系统里最隐蔽、也最危险的问题。信息每经过一个 Agent就会发生一次「翻译」。每次翻译都有损耗。data-agent 分析出来的结论经过 writer-agent 的叙事加工再经过主 Agent 的整合到最终输出的时候原始数据的精确性可能已经面目全非。我遇到过一次真实的失真data-agent 的结论是「漏放率在 Q3 有一次短暂上升随后恢复正常全年整体下降」。经过 writer-agent 的加工变成了「漏放率在 Q3 出现波动」。经过主 Agent 的整合变成了「全年漏放率表现稳定」。三个描述说的是同一组数据但给人的感受完全不同。怎么解决失真问题三个方法我都在用方法一关键数据锚定在>[KEY-DATA] 全年漏放率1.23%同比下降 0.31 个百分点 [/KEY-DATA]要求后续所有 Agent 在引用这个数据时必须保留原始数字不能只用「下降」「上升」这样的定性描述。方法二结论溯源要求主 Agent 在最终输出里每个核心结论后面标注来源全年风控效果持续改善数据来源data-agent 结论 #1这样我能快速核查结论有没有被扭曲。方法三人工检查节点在关键的信息传递节点设置一个「人工确认」步骤。data-agent 完成分析后先把结论发给我看一眼我确认没问题再传给 writer-agent。多一步但关键信息不会在我不知情的情况下失真。一只虾能夹三只虾能搬山但三只虾要能配合。不然就是三只虾在互相夹。多 Agent 不是银弹。它解决的问题很具体当一个 Agent 同时承担太多角色、上下文太重、注意力太分散的时候把它拆开。拆开之后每个 Agent 更专注输出更稳定整体质量更高。但拆开本身有成本。配置更复杂排查更难token 消耗更多。所以先把一个 Agent 用好。真的遇到一个 Agent 搞不定的任务再考虑多 Agent。不要为了用多 Agent 而用多 Agent。本篇小结→ 多 Agent 适合多专业视角、上下文污染、真正可并行、需要互相审查的任务→ 主 Agent 是项目经理只做协调整合不越权执行→ 三种架构串行有依赖、并行无依赖、专家委员会多视角评估→ 子 Agent 的输出格式必须固定用示例定义不用描述定义→ 信息失真是最隐蔽的问题关键数据锚定 结论溯源 人工检查节点→ 先把一个 Agent 用好再考虑多 Agent下一篇Memory 自动化——让它在你睡觉的时候替你整理今天卷卷养虾记 · 持续更新中