多 Agent 输出重复太吵？用输出去重器解决

你可能遇到过这样的场景：启动一群 Agent 来解决复杂任务——可能是研究某个主题、审计代码或抓取结构化数据。你期望得到一个干净、统一的结果。结果却得到三个版本的同一句话、四个略微不同的 JSON 摘要，冗余噪音足以让你的 token 预算爆表。

核心问题通常不是单个 LLM 的质量，而是输出层缺乏协调。在多 Agent 架构中，冗余不只是烦人——它既昂贵又会在技术上造成阻碍。如果 Agent A 和 Agent B 都得出"数据库迁移因超时而失败"的结论，把两个陈述都放进最终的 context window 并不会增加信号，只会增加熵。

我见过团队编写大量自定义 Python 胶水代码来对这些响应进行去重。他们编写正则表达式、实现模糊字符串匹配库，花在调试去重逻辑上的时间比改进实际 Agent 推理的时间还多。这成了另一个脆弱的基础设施组件，一旦模型的冗长程度发生变化就需要维护。

我们需要一个将输出协调作为标准原语而非事后考虑的方法。这正是我们构建 agent-output-deduplicator 的原因。

超越简单字符串匹配

对这个问题的朴素方法是检查 string_a == string_b。但即使说完全相同的事情，Agent 也极少产生完全相同的字符串。一个可能使用项目符号，另一个可能使用完整句子。

要使其对实际工程工作负载有用，你需要数学。具体来说，你需要相似度度量，能够处理语义重叠，而不需要为每次比较都运行繁重的 embedding 模型。

这个去重器利用了 Jaccard 相似度和 n-gram 重叠（具体是 $n=2$ 和 $n=3$）。通过查看交集词序列集合相对于总唯一序列的比例，它可以识别代表相同底层事实的信息簇，无论轻微的语法变化如何。

工具集如何运作

MCP 服务器暴露了三个主要工具，旨在融入 Agent 工作流的不同阶段：

get_similarity_score：这是你的低级探针。如果你想在决定合并或丢弃某个证据之前以编程方式检查两个特定的信息片段是否实际上是重复的，这会给你那个数学确定性。

identify_duplicates：这承担了更繁重的工作。不是手动比较配对，而是将整个输出集合——比如说，一个长时间运行的研究循环中收集的所有内容——输入给它，它会扫描冗余信息簇。你可以在这里传入自定义阈值（0 到 1 之间）；越高表示对唯一性的要求越严格，越低允许更激进的分组。

resolve_canonical_selection：一旦知道内容是冗余的，你实际上如何处理它们？大多数人会认为应该随机选一个或者选最短的。这是坏习惯，因为某些 Agent 在某些任务上天生就比其他 Agent 更好。解析工具允许你基于 Agent 优先级或执行顺序选择"规范"版本。如果你的"Senior Architect Agent"产生的输出与你的"Junior Intern Agent"相似，这个工具确保架构师的版本始终获胜。

为什么大多数开发者跳过这一步（以及为什么他们不应该跳过）

大多数开发者忽略冗余的原因是，在 Agent 工作流中管理状态已经感觉够难了。添加后处理步骤感觉像是额外的延迟。

但考虑一下成本：因上下文膨胀导致的下游 LLM 调用延迟增加、每次请求成本增加，以及最重要的是——在 prompt 历史中反复出现冲突但几乎相同的信息所引发的幻觉触发器。

失去对 context window 中内容的控制，就是小规模自动化脚本在扩展后变成无法收拾的烂摊子的原因。

你可以在 https://vinkius.com/mcp/agent-output-deduplicator 找到完整的实现和文档。

目标不只是减少 tokens；而是确保当你的系统最终向人类呈现答案或通过函数调用做出决策时，那个决策是基于提炼后的真相而非重复的回声。

MCP 是 AI Agent 的音乐。我们构建了目录。探索 Vinkius MCP Catalog。