40个 Haiku worker 喂给 Sonnet：纯代码 reducer 把多智能体成本砍掉 86%

一段不加任何 AI 的 Python 代码，把多智能体管道的单次成本从 1.38 美元压到 0.19 美元，延迟从 51 秒压到 11 秒。

降幅对齐得很干净——成本 -86%、延迟 -78%、输入 token -87%（41200 → 5300）。这不是"省着用"，是"用对了"。

案例来源

X 用户 Gipp 2026年8月11日的长文复盘：https://x.com/gippp69/status/2087120797206819322

架构对比

改造前：

• 40 个 Claude Haiku 并行 worker
• 所有 worker 输出原样堆给 Claude Sonnet 做汇总
• Sonnet 被迫先做数据清洗——最贵的模型干最便宜的活

改造后：

• 中间插了一层纯 Python reducer（不调任何 LLM）
• reducer 做四件事：去重、剔残缺、分组、标矛盾
• 输入 token 41200 → 5300（-87%）
• 还挖出 23 组 worker 间的矛盾——这些原本会被 Sonnet 当噪声吞掉

Gipp 视频讲清三件事

1. reducer 三步逻辑与四道护栏：把 worker 输出从噪声变成结构化输入的工程模式
2. 斯坦福 Lost in the Middle U 形曲线：LLM 在长上下文里对中间部分利用率最低——41200 token 的 raw 输出恰好把关键信息埋在塌陷区
3. 预算观：判断哪些活该还给代码——确定性高的（去重、校验、分组）给代码，概率性强的（推理、生成）给 LLM

Lost in the Middle 补充背景

"Lost in the Middle: How Language Models Fail to Use Long Contexts" 是 Stanford 2023 年的论文（Liu et al.）。它发现 LLM 在长上下文检索任务里，对开头和结尾的信息利用得好，对中间部分利用率最低，形成 U 形曲线。

Gipp 的 reducer 把 41200 token 压到 5300——等于把信息密度提高 8 倍，直接绕过 U 形曲线的塌陷区。这不是省钱，是让 Sonnet 真正"看见"它本来该看见的信息。

我的几个观察

1. MapReduce 范式在 LLM 时代的复活

reducer 这个词来自 Hadoop 时代的 MapReduce。有趣的是模式倒过来了：

• Hadoop 时代：大数据切成小块并行 map → 确定性 reduce 归并
• LLM 时代：多个 LLM 并行产出 → 确定性代码 reduce 归并

思想一脉相承：并行扩展 + 确定性归并。LLM 时代把"map"交给了概率模型，"reduce"反而回归到代码。

2. 跟之前话题的串联

• Frank Coyle（178585127）：给 LLM 套语义约束（Pydantic / Ontology）
• NVIDIA LocateAnything（178585126）：给 VLM 套几何约束（bbox 坐标）
• Gipp 这个：给多智能体管道套数据约束（纯代码 reducer）

三种约束本质上是同一个工程模式：神经网络负责"快和模糊"，符号系统负责"对和确定"。 视觉/语言/数据，都在重新发现这个分工。

3. 中间层缺失是个普遍现象

Agent 工程目前集中在两端：worker 层（LLM 调用）和 orchestrator 层（LLM 编排）。中间的 reducer / filter / validator 层几乎都是手写临时脚本。

跟 Frank Coyle 那篇呼应——他说 Pydantic 和 Ontology 之间是空白；我说 reducer 和 orchestrator 之间也是空白。LLM 时代的中间件市场正在浮出水面。 谁做出"开箱即用的多智能体 reducer 中间件"，谁就吃到这一波基础设施红利。

开放问题： 你们的多智能体管道现在卡在哪里？是 worker 输出原样堆给 Sonnet 没人管，还是已经写了 reducer 但维护不动？有没有人做过类似 Gipp 这种"纯代码 reducer 替代 LLM 清洗"的对比实验？求冒泡。