核心结论：多Agent系统的可靠性，不取决于最强推理Agent的智商，而取决于最弱信息采集Agent的底线。RDD的设计证明了一个反直觉的道理：有时候，不做推理的Agent，才是整个系统最聪明的Agent。
对于正在构建多Agent系统的开发者来说，与其在Prompt里反复叮嘱"请确保信息准确"，不如在架构层面给信息采集一个独立的位置，这个位置不需要最聪明的模型，但需要最清晰的边界。
一、问题的引入：一个贷款审批系统的级联错误
Kore.ai在2025年发表的一篇文章中，用一段说明性场景揭示了多Agent管道中的典型级联错误风险。
想象一个贷款审批多Agent系统：前端接口Agent接收客户申请，传递给数据采集Agent，后者负责从银行数据库和第三方征信平台抓取信息，信用评估Agent据此计算风险评分，最终由决策Agent输出审批结论。
某一时刻，数据采集Agent从一个第三方平台抓取到过时的征信记录,客户的逾期还款记录实际上已经结清，但平台数据未更新。
信用评估Agent收到这条"过时数据"，结合自己的评分模型，输出了一个偏高的风险评分。
决策Agent基于这个评分，给出了"拒绝放款"的结论。
整个过程中，没有一个Agent意识到问题的根源在于数据本身——它们只是在各自的职责范围内，把错误一步步放大。
这个场景的核心警示在于：数据采集Agent的职责边界只到"抓取"为止，它既不对数据的时效性做深度校验，也不会主动标记"这个数据可能有问题"。
信用评估Agent同样没有动力去质疑数据来源——它收到的输入看起来是"结构化事实"，于是按照既定模型执行推理。错误就这样在"各司其职"的表象下畅通无阻。
这类风险并非纸上谈兵。
Galileo在2025年7月发布的多Agent协调失败分析中指出，通信协议崩溃是Agent系统产生幻觉的首要原因：当信息检索Agent发现冲突信源却无法在传递中保留这种不确定性时，下游Agent就会把推测信息当作既定事实来处理。
更棘手的是，这种错误往往带有高度置信度和结构化表达，让人很难在第一时间察觉。
这个问题的本质是多Agent系统中的一个架构盲区：我们花了很多精力设计推理Agent的CoT、规划Agent的任务分解、审核Agent的质量把关，却很少专门设计一个只负责把事实搞清楚的角色。
二、行业实践：情报采集正在从"附属功能"走向"独立职能"
2.1 Anthropic的分工实验
2025年6月，Anthropic详细披露了Claude Research功能背后的多Agent研究系统。这是一个典型的Orchestrator-Worker架构：一个Lead Researcher负责制定研究策略、拆解任务，然后并行启动3-5个Subagents去不同方向独立搜索，每个Subagent都有自己的上下文窗口和工具访问权限。
内部评估数据显示：多Agent系统比单Agent Claude Opus 4的研究准确率高出90.2%，复杂查询的研究时间因并行化设计减少了90%。
但代价也不小：Token消耗约为标准聊天的15倍。
这里有一个值得开发者关注的信号：Anthropic明明有能力用一个更强的模型搞定一切，却选择把"搜索信息采集"拆成独立的子Agent。为什么？
答案在他们的设计细节里。Anthropic给每个Subagent的指令非常明确：
”你的职责是搜索、压缩信息、返回发现——不做判断，不输出结论。“
这与Subagents使用的"交错思考"（interleaved thinking）机制配合：每次工具调用后评估结果质量，识别信息缺口，优化下一次查询。但评估的是搜索策略，不是事实本身的对错。
这种设计背后的工程逻辑很清晰：当信息采集和推理判断耦合在同一个上下文窗口里，模型会不自觉地用推理意图去"筛选"信息：只想找支持自己判断的证据。
这在认知心理学里叫确认偏误，在多Agent系统里叫级联幻觉。
2.2 主流框架的情报职能对比
如果把Anthropic的做法放在更大的行业图景里看，会发现不同框架对"情报采集"的定位存在有趣的差异，这些差异不是优劣之分，而是场景选择的不同。
- CrewAI采用了最直接的角色化方案。
它内置了"Researcher"角色，可以自主迭代查询，也支持多Agent协作中的信息流转。 比如一个典型的内容生产工作流：Researcher负责搜集资料，Writer负责写作，Editor负责审核，三个角色通过任务依赖串联起来。
CrewAI的典型工作流由三个角色串联：Researcher负责搜集资料，Writer负责写作，Editor负责审核。Researcher的输出通过context参数直接传递给Writer，Writer接收到的不是经过独立验证的"事实"，而是Researcher整理后的"研究笔记"。
这种模式的优势在于上手简单、角色定义直观，适合需要快速搭建研究团队原型的场景。
- AutoGen走了另一条路。
微软设计的这个框架强调对话驱动：搜索不是预设角色，而是在Agent对话中动态触发的。
任一Agent觉得需要检索时，可以提议调用工具。
这种方式更灵活，适合探索性强的研究场景。
- LangGraph的选择更激进。
检索被降级为工具节点或子图节点，被动触发。
在LangGraph的世界里，信息采集不是角色，而是工作流中的一个步骤。
这种设计适合结构清晰、可预定义的任务。
| 框架 | 情报职能的定位 | 适合的场景 | 设计哲学 |
|---|---|---|---|
| CrewAI | 预定义Researcher角色，自主迭代 | 结构化研究团队、内容生产流水线 | 角色驱动 |
| AutoGen | 对话中动态触发，无固定角色 | 探索性研究、协作式编码 | 对话驱动 |
| LangGraph | 检索是工具节点，被动触发 | 结构化工作流、确定性流程 | 流程驱动 |
| Anthropic Subagents | 专门执行搜索的子Agent，不推理 | 复杂研究任务、需要并行探索 | 分工驱动 |
这四个方案代表了四种不同的产品假设：
CrewAI假设"研究"是一个可角色化的职能；
AutoGen假设搜索应该是对话的自然延伸；
LangGraph假设检索是可编排的流程步骤；
Anthropic假设搜索需要专门的能力单元，且必须与推理解耦。
这些假设没有绝对的对错，只有与场景的匹配度高低。
三、学术证据：数据客观性需要架构级保障
行业实践正在向"情报职能独立化"收敛，学术论文则从另一面给出了支撑：数据客观性不是"提示词工程"能解决的问题，需要架构级保障。
3.1 MAFC多Agent事实核查框架
2026年发表在Nature上的MAFC（Multi-Agent Fact-Checking）框架提供了一个极具说服力的实验设计。研究团队构建了三个独立Agent，分别使用不同信息源对同一事实进行判断：
Google Agent：通过Google搜索API检索网页片段作为证据
Wikipedia Agent：通过Wikipedia API提取最相关页面摘要
LLM Agent：基于GPT-4-turbo自身知识，使用SelfCheckGPT检测幻觉
每个Agent输出事实性判断（True/False）+ 置信度（0-1），然后通过对数加权聚合得出最终可信度分数。这个设计的精妙之处在于：多Agent一致性有加成，但增长缓慢，弱置信度的支持者不会冲淡强置信度的反对者。
实验结果：
| 任务 | MAFC准确率 | 基线方法 | 提升幅度 |
|---|---|---|---|
| SciFact 二元核查 | 79% | 72% (SelfCheckGPT) | +7% |
| SciFact-Mixed 多标签 | 97% | 57% | +40% |
| FEVER（零样本） | 68% | 与最佳监督模型持平 | — |
最值得注意的是两个发现：
第一，单一信息源的平均评分机制表现最差（55%准确率）——错误判断来源主导了结果。
第二，当不同来源证据冲突时，MAFC倾向于给出中间可信度分数而非自信的二元标签，显式保留不确定性。
这组实验从学术上证明了"多源独立信息采集 → 交叉验证 → 信誉加权"这条路径的有效性。
但MAFC也暴露了一个局限：所有Agent基于同一LLM，骨干模型的系统性偏差可能跨Agent传播甚至被放大。
3.2 Multi-Agent Debate的退化风险
Du等人在ICML 2024年发表的多Agent辩论研究提供了另一组关键数据：多Agent交叉辩论使事实准确性提升约89%。
更令人惊讶的是，即使所有参与Agent最初都给出了错误回答，多Agent辩论甚至可以导出正确答案。因为辩论过程中的相互批评催生了新的推理路径。
但后续研究也揭示了辩论的退化风险。Johns Hopkins与Vector Institute的合作研究发现，在异构设置下辩论可能降低准确率（MMLU任务上从33.6%降至24.4%）。
三种退化机制尤其值得警惕：
谄媚（sycophancy）：Agent开始迎合多数派观点而非坚持独立判断
从众（conformity）：Agent放弃自己的分析，选择"随大流"
推理表面化（superficial reasoning）：Agent追求辩论技巧而非真相
这些发现对系统架构设计有直接影响：退化机制恰恰证明了"独立于推理链的、只负责事实交付的情报角色"为什么必要：不参与辩论，就不会被辩论压力扭曲。
3.3 涌现集体记忆的临界密度
2025年底的一篇论文研究了去中心化多Agent系统中的集体记忆涌现现象。研究团队在20×20到50×50的网格环境中部署了5-625个Agent，发现了一个临界密度阈值 ρc ≈ 0.230：当Agent密度超过这个阈值后，基于环境痕迹的协调（stigmergic coordination）开始超越纯个体记忆系统，性能提升36-41%。
这个数字对系统架构设计的启示在于：多Agent集群的"智能"不只取决于单个Agent的能力，更取决于信息在集群中的流动密度。
如果一个Agent集群中的每个成员都在各自搜索、各自为战，信息密度永远达不到临界阈值，就像一个会议室里每个人都在偷偷查手机，但是却不共享一份经过整理的材料。
四、枢衡RDD的架构设计与五大原则
基于前面的行业实践和学术证据，我们可以更清晰地理解枢衡RDD（资源探测，Resource Detection Department）的架构设计逻辑。
它不是"又一个搜索Agent"，而是针对"信息采集→事实交付→推理决策"链条中的系统性风险，所做的架构级回应。
4.1 RDD在认知链中的位置
在枢衡的五核心Agent架构中，RDD位于认知链的第一环，信息进入层。
它的下游是CAD（中央审计，Central Audit Department），再下游是SDC（战略决策中枢，Strategic Decision Center）。
在V1.0到V2.0的架构精简中，Agent数量从9个砍到5个，RDD是被明确保留的五个核心之一。 精简逻辑很直接：数据客观性是认知链的基石，RDD的职能边界足够窄且不可替代。其他四个Agent都不包含"原始信息采集"的职责。
4.2 原则一：只交付事实，不参与推理
RDD的输出包含原始数据和多源差异标注，但不含任何推理、判断或建议
举个例子：
{
"query_id": "q_20250618_001",
"topic": "AI Agent市场规模2025",
"sources": [
{
"source_id": "src_1",
"source_type": "industry_report",
"source_name": "Gartner 2025",
"data": "全球AI Agent市场规模52.9亿美元",
"timestamp": "2025-03-15",
"confidence": "high"
},
{
"source_id": "src_2",
"source_type": "research_paper",
"source_name": "MoonFox + 中国信通院",
"data": "预计2030年达471亿美元，CAGR 45%",
"timestamp": "2025-01-20",
"confidence": "medium"
}
],
"discrepancies": [
{
"between": ["src_1", "src_2"],
"description": "Gartner未提供2030年预测，MoonFox预测与Gartner基线数据存在时间跨度差异",
"severity": "low"
}
],
"inference_note": "NONE - 本素材包仅包含原始数据，不含推理结论"
}
这个设计的反直觉之处在于：它主动限制了RDD的能力。
一个通用LLM天然就能推理，但RDD被架构级约束禁止调用这种能力，不是通过提示词"希望你别推理"，而是通过架构设计"你根本进不了推理环节"。
为什么要做这种"减法"？
回看贷款审批场景中的数据采集Agent：如果信息采集环节同时具备推理能力，它就会在采集过程中不自觉地"选边站"，觉得这个来源可信、那个来源可疑。
这种判断可能是对的，也可能是错的，但关键是它无法被审计。
当错误发生时，你分不清是信息采集出了问题，还是推理判断出了问题。
4.3 原则二：多源并行采集 + 差异标注
RDD对同一信息需求从多个来源获取数据，并在交付时标注差异，不是选择"看起来最可信"的来源，而是把所有来源的原始数据连同差异一起打包。
RDD的多源采集流程可以概括为五个步骤，每一步都有明确的边界约束：
| 步骤 | 动作 | 关键约束 |
|---|---|---|
| 1. 查询解析 | 解析信息需求，确定数据源列表 | 只解析需求，不做预判 |
| 2. 并行采集 | 从多个数据源同时抓取原始数据 | 并行执行，超时容错 |
| 3. 去噪格式化 | 清洗明显噪声（重复、空值、格式错误） | 不做可信度判断 |
| 4. 差异标注 | 识别并标注不同来源之间的矛盾 | 只标注，不裁决 |
| 5. 打包交付 | 向下游CAD输出 | 强制包含inference_note: NONE |
这与MAFC框架的多源独立判断逻辑一致，但RDD不做判断，只呈现差异。
判断权交给下游的CAD（中央审计）。
这种"采审分离"确保了信息采集不被审计标准污染，也不被审计结果影响。
4.4 原则三：角色边界硬隔离
在枢衡的架构中，RDD的隔离不是提示词层面的"希望"，而是架构层面的"不可能"。
RDD的输出接口被严格定义为素材包，这个格式本身就不包含推理字段，即使RDD内部的LLM产生了推理冲动，输出协议也会将其过滤掉。
这种硬隔离的好处是可审计性：如果下游Agent收到了包含推理的素材包，系统可以100%确定问题出在RDD的输出协议层，而不是其他环节。
4.5 原则四：与CAD的对抗性协作
RDD与CAD之间构成了一种精妙的双向制衡：
RDD与CAD之间的协作遵循以下流程：
- RDD交付事实 → CAD验证事实 → 如果发现问题，驳回RDD重新采集
但CAD自身也受信誉积分约束，如果CAD错误裁定RDD的数据为"不合格"，CAD自身扣分。
这意味着RDD不能糊弄CAD，CAD也不能滥权打压RDD。
这种对抗性设计确保了事实质量不会被任何一方的偏见主导。
4.6 原则五：构建环境，而非发号施令
RDD的设计本质不是在"命令"一个Agent去搜集信息，而是在构建一个确保信息质量的环境。
多源采集降低单一信源偏差，差异标注保留不确定性，架构级隔离防止角色漂移，对抗性协作防止审计失效。
我认为，真正成熟的Agent集群，是能自我分工、自我质疑、自我修复的环境。RDD就是这种环境的第一块地基。
五、实战：如何判断系统是否需要RDD
以下是一套可落地的自检清单，帮助开发者判断自己的Agent集群是否需要引入专职情报官角色。
检查项1：是否出现过"自信的错误"？
如果你的系统经常给出看起来很有道理、但经不起事实核查的结论，问题很可能出在信息采集环节。典型的信号包括：
系统引用了"不存在"的数据源
时间戳混乱（把2023年的数据当作最新数据使用）
同一问题多次查询得到截然不同的"事实"
检查项2：是否存在"信息孤岛"？
如果每个Agent都在各自搜索、各自为战，没有统一的事实交付标准，集群的信息密度永远无法达到涌现集体智能所需的临界阈值。
检查方法：查看Agent之间的通信日志，如果发现同一个事实在不同Agent上下文中有不同版本，说明缺乏统一事实源。
检查项3：审计机制是否"既当运动员又当裁判"？
如果负责核查事实的Agent同时也参与信息采集或推理决策，审计闭环就已经失效了。架构层面的分离需要满足：
- 采集者 ≠ 审计者 ≠ 决策者
检查项4：Token投入是否被"带偏"？
Anthropic的数据表明，多Agent系统的Token消耗是单Agent的15倍。
如果这15倍的投入中有相当一部分被浪费在"基于错误信息的推理"上，那么引入专职情报官的ROI是正向的。
| 检查项 | 是 | 否 |
|---|---|---|
| 出现过"自信的错误" | 需要RDD | 继续观察 |
| 存在信息孤岛 | 需要RDD | 继续观察 |
| 审计机制不独立 | 需要RDD | 继续观察 |
| Token投入产出比低 | 需要RDD | 继续观察 |
如果以上任意一项为"是"，建议考虑在架构中引入专职情报采集角色。
六、总结
在多Agent集群的喧嚣中，RDD可能是那个最不起眼的存在。
它不生成华丽的结论，不参与激烈的辩论，不产出引人注目的洞察。
它只做一件事：确保系统认知地基的坚固。
但这种"不起眼"恰恰是它最珍贵的地方。
正如餐厅后厨的采购员。客人只评价菜好不好吃，没人关心食材从哪里来。直到某天吃坏了肚子，才会意识到采购环节的重要性。
【看山 Agent 架构】
工信部 AI 技术应用（高级）认证
30次集群崩溃复盘 | 20+智能体实战
深耕 Agent 集群架构，用商科思维重构复杂系统效率
注：本文内容由 AI 辅助创作，作者对内容结果负责
