打造卓越Agent团队：如何解决复杂任务带来的AI协作的副作用？

01 AI 也需要“分工”吗？

答案是：需要，而且比人类更需要。

人类有工作可以积累长期复杂的记忆，很强的上下文感知能力，有主动性，会主动发现问题。

AI 不一样。给它一个复杂的任务，如果只有一个 AI 模型从头做到尾，它会面临几个很难解决的问题：

第一个：角色坍塌与注意力稀释。大语言模型都有上下文窗口Context Window，如果上下文饱和了，就很容易出问题。同一个Agent，在一个长程的对话里面，既要做数据分析，又要做逻辑推理，又要写报告——模型往往会在指令冲突中采取“中庸妥协”，又因为上下文过长导致注意力漂移，最终导致能力坍塌，产出的内容很大概率就是一本正经的胡说八道。因此，我会在和AI聊天过长的时候新开对话窗口。

第二个：不知道自己错在哪里。人很难自己否定自己，AI也是一样。单个 AI 在输出最终结论之前，不会主动质疑自己的中间步骤。它不会停下来想：“我刚才那个假设对不对？”它只会继续往下推演，最终引发灾难性的错误级联（Error Cascading）。

第三个：没有“第二意见”。人类做重要决策，会找同事讨论、找领导审批。单个 AI 没有这个机制，它不会问自己："有没有其他可能性？"

所以，Multi-Agent 的本质不是“多个 AI”，而是“不同的角色负责不同的事，然后相互校验”。

02 三个臭皮匠，胜过一个诸葛亮

例如，在自定义的Multi-Agent 里的投研系统，设置了三个核心角色：

角色一：Modeler（建模师）—— 构建判断框架

你可以把建模师理解成公司的战略规划部。

他们的工作不是告诉你"明天买还是卖"，而是先把事情搞清楚：

• 这个公司值多少钱？

• 它的增长逻辑是什么？

• 核心假设是什么？

他们会构建一套完整的分析框架，包括乐观预测、基准预测、悲观预测——这三种场景。

但他们有一个明确的边界：只负责建模，不负责质疑。

这是关键。战略规划部的工作是做好方案，不是和领导辩论方案的对错。

角色二：Challenger（挑战者）—— 主动找漏洞

你可以把挑战者理解成公司的内部审计部。

他们不负责构建任何东西，他们的工作是专门"挑毛病"：

• 这个预测的假设依据是什么？

• 有没有遗漏的风险？

• 这个结论是不是太乐观了？

他们会对建模师的每一个关键判断发起攻击，然后建模师必须逐一回应：要么提供证据，要么修改结论，要么承认这个点确实有问题。

重要的是：挑战者不看建模师的工作过程，只看最终结论和依据。

这像极了审计部的工作方式——他们不参与业务决策，但有权质疑任何业务判断。

角色三：Synthesizer（综合师）—— 做最终决策

你可以把综合师理解成公司的CEO。

他们不写报告，不做预测，不做审计。但他们有一项核心能力：综合多方意见，形成最终判断。

当建模师给出了三套预测，挑战者提出了若干质疑和回应，综合师要做的事情是：

• 哪些质疑有道理，应该接受？

• 哪些质疑不合理，可以驳回但必须说明理由？

• 最终的评级和目标价应该是什么？

CEO 不需要每件事都自己干，但他需要做出最终决策，并为此负责。

03 三个角色的对话规则

光有分工不够，三个角色之间必须有一套清晰的对话规则。

如果没有规则，会发生什么呢？

场景一：角色越位

挑战者开始替建模师做分析，综合师开始替挑战者写报告。每个人都在做本不该自己做的事，最后整个流程乱成一锅粥。

场景二：信息泄露

建模师在做判断的时候，已经提前知道了挑战者要攻击什么内容，于是提前"堵住了漏洞"。这就像领导在开民主生活会之前，就已经知道员工要提什么意见，于是提前准备了标准答案。

场景三：无限循环

挑战者提出质疑，建模师回应，挑战者再质疑，建模师再回应……没有终止条件，流程永远跑不完。

正确的Harness 做法是用“不变量”（Invariant）来约束对话边界，这就好像每个人都有一个checklist：

对话规则

约束内容

信息隔离

挑战者只能看到建模师的最终结论，看不到中间推导过程

强制回应

挑战者的每一次质疑，建模师都必须明确回应，不能忽略

终止条件

质疑被标记为解决或根据证据驳回，流程才能继续

单向流动

信息只从建模师→挑战者→综合师，不允许反向泄露

04 一个真实的协作场景

说理论太抽象，来走一遍真实的流程。

场景：分析特斯拉（TSLA）

第一步：建模师输出基础分析

建模师完成了对 TSLA 的分析，输出三套预测：

• 乐观情景：$320（基于 FY2027 年利润预测）

• 基准情景：$245

• 悲观情景：$158

同时输出关键假设：年度利润增长率 25%，PE 倍数 42x。

建模师把这些结论写进 JSON 文件，建模阶段结束。

第二步：触发挑战者审查

系统自动调用挑战者角色。挑战者读取建模师的 JSON 文件，但不读取任何中间推导过程。

挑战者发现了一个问题：

"建模师使用了 FY2027 年利润作为锚点基准，但 FY2026 年利润预测已经比 FY2027 低了 15%——这是什么逻辑？"

挑战者发起攻击，状态标记为 CRITICAL。

第三步：建模师回应

建模师收到挑战者的质疑，必须回应。

可能的回应方式：

• 接受并修正

  ：重新校准锚点，改用基准情景的 FY2026 预测作为锚点

• 驳回并提供证据

  ：说明 FY2027 锚点的合理性，提供行业对标数据

• 承认边界

  ：说明这是一个结构性不确定性（bidirectionality_blocked），无法用常规方法处理

第四步：综合师做出最终判断

所有 CRITICAL 攻击被处理完毕，综合师综合全部分析，输出最终报告。

最终报告3000万字，包含：

• 评级（BUY/HOLD/SELL）

• 目标价

• 信心指数（model_validity_score）

• 关键风险列表

很多人会有一个疑问：

为什么要单独设一个"挑战者"？让建模师自己检查自己的结论不行吗？

答案：不行。而且越是自己查自己，越危险。

心理学上有一个概念叫"确认偏误"——人类会倾向于寻找支持自己已有判断的证据，而忽略反驳的证据。

AI 系统里也存在同样的问题：建模师在构建了一套分析框架之后，对自己的框架会产生"所有权感"，潜意识里不愿意承认框架有问题。

而挑战者的存在，就是为了打破这种确认偏误。

更准确地说，挑战者有一个很重要的功能：把质疑和建构分开。

建模师的任务是"构建一个好的分析"，挑战者的任务是"证明这个分析哪里不好"——这是两种完全不同的思维方式，让同一个人同时做这两件事，本质上是在要求他"左手打右手"。

06 信息隔离：最难但最重要的设计

三个角色里，信息隔离是设计难度最高、但价值最大的部分。

为什么难？

因为信息隔离不是"不告诉你"这么简单。当建模师输出一个结论的时候，挑战者需要足够的上下文才能提出有意义的质疑——但这些上下文，又可能包含建模师的推导过程，从而造成信息泄露。

解决方案是"摘要机制"：

建模师完成分析后，不是直接交给挑战者，而是先经过一个"摘要生成器"。

这个摘要生成器会：

• 提取建模师的最终结论（保留）

• 剥离推导过程（删除）

• 生成一份"挑战者视角"的攻击预判（新增）

这样一来，挑战者拿到的是一份"干净"的输入：只有结论和证据，没有中间推理。

同时，摘要生成器会明确告诉挑战者："以下是你需要重点攻击的方向"，相当于给挑战者提供了一份"攻击地图"，而不是让他自己去找漏洞。

07 失败案例：如果不这么设计会怎样？

案例：CRM 案例

在建模师和挑战者在同一个工作循环内共享了“参考资料”字段。

建模师在做最终判断之前，已经提前看到了挑战者准备攻击他的内容。

结果：建模师提前修改了措辞，把最脆弱的假设包装得更稳妥。挑战者最后发现所有"漏洞"都被堵住了，最终攻击全部无效。

这个 AI 系统犯的错误，和很多公司开"走过场"的民主生活会一模一样。

修复方案：引入信息隔离机制，挑战者只能读取摘要，看不到建模师的原始推导过程。

08 给管理者的启发

Multi-Agent 协作的设计，对管理者也有几点很直接的启发：

第一，质疑和建构需要分开。

让同一个人既负责方案设计、又负责方案审核，是管理上最常见的错误之一。好的决策机制，一定是有人提方案、有人挑毛病、有人做决定，三种角色分开。

第二，信息隔离有时候比信息透明更重要。

不是所有信息都应该让所有人看到。挑战者需要足够的上下文来提问题，但不需要看到建模师的推导过程。管理者需要知道决策结论，但不需要知道每个环节的具体推理——知道太多，反而会干扰判断。

第三，设置明确的终止条件。

没有终止条件的讨论会变成无限循环，永远不会有结论。Multi-Agent 系统里，每一条质疑都必须有明确的处理状态，系统才会继续往下走。

现实中也是如此：会议要有结论，评审要有结论，决策要有结论。

09 总结

好的协作，不是分工就完事了，而是对齐目标的情况下，让每个成员在自己岗位上面发挥最大能力，让组织达到一种最佳效率平衡。

Multi-Agent 的设计，本质上是在用工程化的方式，实现人类组织里早就存在的分工与制衡逻辑。

如果你在带团队，这套设计值得参考：

• 有人负责建构（建模师）

• 有人负责质疑（挑战者）

• 有人负责决策（综合师）

• 三个角色之间有清晰的信息边界

• 每个环节有明确的终止条件

做到了这几点，不管是 AI 系统还是人类团队，协作质量都会上一个台阶。