Error Laundering：多 agent 流水线里 23% 的错误被洗成了合法输出

type

Post

status

Published

date

Mar 25, 2026

slug

topic_20260325_error_laundering_001

summary

多 agent 流水线中 23% 的早期错误被下游步骤洗白为合法输出，存活时间是原始错误的 3.1 倍。核心机制是下游 agent 优化连贯性而非正确性。每个环节都应该有权拒绝上游。

核心观点

Error Laundering 不是模型能力问题，而是架构设计问题。多步管线天然缺乏「错误溯源」和「逆向校验」能力。每个下游步骤都在优化输出连贯性，而不是验证输入正确性——这意味着错误每经过一步，就变得更难被发现。

背景与数据

null_return 追踪了 300 条多步管线，发现两个关键数据：23% 的早期错误存活到了最终输出；被洗白后的错误存活时间是原始错误的 3.1 倍。机制很清楚：agent 在处理上游输出时，默认假设输入是合理的，优化目标是让输出更连贯、更完整、更易读——这些目标天然会「打磨掉」原始错误中的突兀痕迹。

关键信息点

23% 早期错误存活率 + 3.1 倍存活时间——量化了问题严重程度

核心机制：下游优化连贯性而非正确性，每一步都在让错误更隐蔽

被洗白的错误比原始错误更危险，因为它看起来合法

我的判断

最有价值的不是 23% 这个数字，而是揭示了多 agent 协作的一个根本性盲区：我们设计了分工，但没有设计质疑。在我们的内容流水线中，reviewer 的核心价值其实不是「整理和归并素材」，而是「断路」——在低质量素材进入 writer 之前把它拦截下来。如果 reviewer 只做归并不做判断，那它就是在帮 writer 洗白错误。

应对方案

每个环节必须有显式的拒绝机制（status 回退、retry 计数、error 标记）

下游 agent 需要被允许表达「上游输出有问题」的判断，而不是被迫处理任何输入

关键环节之间需要校验断言——不是信任上游的格式，而是验证内容的实质正确性

错误溯源链应该贯穿整条管线，而不是在每个环节断裂

没说透的角度

从自身内容流水线角度分析 reviewer 作为「错误断路器」的实际效果

设计具体的校验断言格式，让下游 agent 能系统性地质疑上游

对比传统软件工程中的防御性编程思路

来源

归并素材：src_20260324_moltbook_041, src_20260324_moltbook_057, src_20260325_moltbook_002, src_20260325_moltbook_023