引言：一个反直觉的现象
去年我在搭建多Agent内容审稿系统时，碰到一个有意思的现象：当多个Agent独立工作时，它们发现重复版式的能力，远强于让它们"协同工作"或共享上下文。
这个发现让我重新审视"多Agent协作"的假设。我们直觉上认为，让Agent们互相交流、共享信息，应该比各自为战效果更好。但在版式检测这个具体任务上，事实正好相反。
过去几个月，我把这个发现应用到了实际的内容生产流程中，积累了一些值得记录的经验和思考。
什么是"重复版式"问题
先说清楚我在说什么。
在内容生产，尤其是批量内容生产（比如公众号日更、小红书矩阵、电商详情页）中，"重复版式"是一个常见问题。它指的是：
- 多篇文章用了相同的开头模板（"今天要和大家分享的是..."）
- 段落结构高度雷同（三段式：问题-分析-总结，每篇都这样）
- 过渡句重复使用（"接下来我们看看..."、"话说回来..."）
- 结尾call-to-action千篇一律（"如果觉得有用，请点赞收藏..."）
这些问题单独看不明显，但放在一起来看，读者会觉得"怎么每篇都长得一样"。
人工审稿时，这些问题很容易被忽略——因为人是按顺序读文章的，读完一篇就换下一篇，很难跨文档对比版式。
但Agent审稿时，理论上可以同时处理多篇文章，做跨文档的版式分析。问题来了：怎么设计这个审稿流程？
协同模式的第一直觉
我最初的设计是"协同模式"：
- 创建一个"主审稿Agent"
- 它读取所有待审文章
- 它调用多个"子Agent"分别分析不同维度（语法、逻辑、版式...）
- 子Agent把结果返回给主Agent
- 主Agent汇总，输出最终审稿报告
这个设计看起来很合理，符合我们对"多Agent协作"的典型理解。主Agent负责协调，子Agent负责执行，有点像人类团队的项目经理和组员。
但实测效果很差，尤其是版式检测这块。子Agent经常"看不到"重复版式，即使我把多篇文章的内容都塞进它的上下文。
问题出在哪里？
独立Worker的关键优势
经过多次实验和复盘，我发现问题核心在于：当Agent共享上下文或被嵌入协作框架时，它会失去"全局对比"的视角。
独立Worker模式是这样的：
- 启动N个独立的Agent实例（Worker）
- 每个Worker只拿到一篇文章（注意：不是所有文章）
- 每个Worker被明确要求：检查这篇文章的版式特征，并用标准化格式输出
- 所有Worker的输出被收集起来
- 用一个专门的对比模块（可以是另一个Agent，也可以是简单的数据结构对比）分析所有输出，找出重复模式
这个模式的关键点是：每个Worker在审稿时，不知道其他文章的存在。它只专注于"把这篇文章的版式特征描述清楚"。
然后，重复版式的发现，不是由Worker完成的，而是由对比模块完成的。
这看起来违反了直觉：要让Agent发现"多篇文章的版式重复"，难道不应该让Agent看到多篇文章吗？
答案是否定的。原因如下：
1. 注意力分散效应
当Agent同时处理多篇文章时，它的注意力被分散了。大模型的工作记忆（context window）虽然大，但"同时记住多篇文章的版式细节"仍然是个高认知负载任务。
结果就是：Agent会对每篇文章做"局部优化"式的审稿（这篇语法对不对？逻辑通不通？），而不是"全局对比"式的审稿（这篇和其他篇有没有重复？）。
独立Worker模式把这个任务拆开了：Worker只负责"描述"，对比模块负责"对比"。每个任务都简单明确，反而做得更好。
2. 标准化输出的力量
独立Worker模式的另一个关键点是：强制标准化输出。
每个Worker都必须用相同的格式输出版式特征：
- 开头类型: [模板化/原创/引用]
- 段落结构: [三段式/总分总/问题递进/...]
- 过渡句特征: [具体描述]
- 结尾类型: [模板化/原创/互动引导/...]
- 标题句式: [疑问/陈述/命令/...]
当所有文章都用这个结构描述时，"对比模块"的工作就变得非常简单：只需要做字符串匹配或轻量级语义对比，就能发现重复模式。
而如果让一个"协同Agent"同时审稿多篇文章，它输出的审稿报告往往是自由格式的，不同文章的审稿报告难以直接对比。
3. 隔离带来的"陌生感"优势
这点最反直觉，但也最有趣。
当Agent独立工作时，它对每篇文章的版式判断是"孤立"的。它不知道其他文章，所以它在描述版式时，会用自己"最自然"的方式去描述。
然后，当对比模块把这些描述放在一起时，重复模式会自动跳出来。
举个例子：
- Worker 1描述文章A的结尾："用'如果觉得有用，请点赞关注'做互动引导"
- Worker 2描述文章B的结尾："以'觉得有用就点个赞吧'结尾，引导互动"
- Worker 3描述文章C的结尾："结尾是标准的互动引导语：'点赞收藏不迷路'"
如果让一个协同Agent同时看这三篇文章，它可能会输出："三篇文章结尾都有互动引导"。这个信息是对的，但太粗糙了。
而独立Worker的输出，保留了描述的细节。对比模块可以做更精细的分析：虽然三篇的互动引导语句不完全一样，但都出现在"结尾"位置，且功能相同——这就是"重复版式"。
隔离带来了"陌生感"：每个Worker对版式的描述不受其他文章影响，保留了更多的细节信息，反而让后续的对比分析更准确。
实际部署中的经验
把这个模式部署到实际内容生产流程后，我总结了几点经验：
经验1：Worker数量不是越多越好
我有次同时启动了20个Worker审稿20篇文章，结果发现对比模块的准确度反而下降了。原因是：当文章数量太多时，一些"伪重复"会被误判为真的重复（比如多篇文章都用了"首先...其次...最后..."这个通用结构，这不算版式重复，而是正常的论述结构）。
现在的经验是：每批审稿文章控制在5-10篇，这个范围内，对比模块的准确度最高。
经验2：对比模块要用"模糊匹配"
最初我用精确字符串匹配做版式对比，结果发现漏报很多。因为重复版式往往不是"一模一样"，而是"高度相似"。
比如：
- 文章A开头："今天要和大家分享一个话题"
- 文章B开头："今天想和大家聊一个话题"
这两句显然是一个模板，但字面不完全一样。
后来我改用模糊匹配+语义向量对比做版式对比，漏报率大幅下降。具体来说：
- 对版式描述做分词和向量化
- 计算向量相似度
- 相似度>0.8的，标记为"疑似重复版式"
- 人工复核疑似案例
经验3：独立Worker不是完全独立
说"独立Worker"，不是说它们完全隔离。实际上，它们共享：
- 同样的Prompt（确保输出格式标准化）
- 同样的版式特征提取逻辑
但不共享：
- 文章内容（每个Worker只看到分配给它的那篇）
- 其他Worker的输出（对比前不互通）
这个"有限共享"的设计，是独立Worker模式的关键。
一个完整的流程示例
让我用一个完整示例来说明这个流程。
假设我有5篇待审稿的文章，主题是"AI工具测评"。
步骤1：启动5个独立Worker
每个Worker拿到一篇文章，Prompt是：
你是一个内容审稿员。请阅读以下文章，并提取它的版式特征。
输出格式（严格遵循）：
- 开头类型:
- 开头句式（前50字）:
- 段落结构:
- 每段平均字数:
- 过渡句特征:
- 结尾类型:
- 结尾句式（后50字）:
- 标题句式:
- 小标题使用:
文章内容：
[文章内容]
步骤2：收集5个Worker的输出
假设输出是：
Worker 1:
- 开头类型: 模板化
- 开头句式: "今天要和大家分享的是..."
- 段落结构: 总分总
...
Worker 2:
- 开头类型: 模板化
- 开头句式: "今天想和大家聊一聊..."
- 段落结构: 总分总
...
步骤3：对比模块分析
对比模块发现：
- 5篇文章的开头类型都是"模板化"
- 开头句式高度相似（模糊匹配相似度>0.85）
- 段落结构都是"总分总"
步骤4：生成审稿报告
报告指出："这5篇文章存在明显的版式重复，主要体现在开头模板和段落结构上。建议对开头进行差异化改写，并考虑调整部分文章的段落结构。"
这个过程，从Worker启动到最终报告，可以在几分钟内完成（取决于文章长度和大模型响应速度）。
而如果让一个人工会怎么做？他可能需要几小时，逐篇阅读、做笔记、对比分析。
为什么这个方法有通用价值
这个"独立Worker+对比模块"的模式，不仅仅适用于版式检测。我发现它在以下场景也很有用：
场景1：代码审查
让多个独立Agent分别审查同一段代码的不同方面（安全、性能、可读性...），然后用对比模块分析它们的审查意见，找出被多个Agent同时标记的问题——这些往往是真正的高优先级问题。
场景2：数据清洗
让多个独立Agent分别检测数据集中的异常值，然后用对比模块找出被多个Agent同时标记为异常的数据点——降低误报率。
场景3：竞品分析
让多个独立Agent分别分析不同竞品的产品文档，然后用对比模块对比它们的功能描述——快速找出差异化定位和雷同宣传语。
这些场景的共同特点是：任务可以拆解为"独立观察"+"集中对比"两个阶段。
反思：多Agent系统的设计原则
从这个案例中，我提炼出几个多Agent系统设计的原则：
原则1：明确分工，而不是模糊协作
"协同"听起来很好，但如果每个Agent的职责不清晰，它们会互相干扰。独立Worker模式的成功，很大程度上是因为每个Worker的职责非常明确：只描述，不对比。
原则2：标准化中间输出
多Agent系统的一个常见失败原因是：Agent之间的"沟通"不顺畅。这里的"沟通"不是指它们用自然语言对话，而是指它们的输出格式不兼容，导致后续处理困难。
标准化中间输出，可以大大降低多Agent系统的复杂度。
原则3：用简单逻辑做集成
对比模块不需要是另一个大模型。实际上，我用的是很简单的Python脚本：做分词、计算相似度、输出报告。这个模块可靠、快速、易调试。
多Agent系统的集成模块，应该尽量简单。把复杂性留在各个Agent内部，而不是集成层。
结语：回到问题本身
回头看，这个发现的核心其实很简单：有些任务，拆开来做比合起来做更好。
我们容易被"多Agent协作"的概念吸引，觉得Agent之间应该像人一样"讨论"、"协作"、"达成共识"。但在很多实际任务中，让Agent们独立完成各自的任务，然后用确定性的逻辑做集成，反而更有效。
版式检测只是其中一个例子。我相信，在更多的任务和场景中，这个原则也适用。
多Agent系统的设计，不应该是"让Agent更像人一样协作"，而应该是"让每个Agent都做自己最擅长的事，然后用最简单的逻辑把它们集成起来"。
这需要我们对任务本身有深入理解，而不是盲目追求"协作"的概念。
（字数统计：约3200字）