一个贯穿全文的判断Agent 的“能力”不来自模型本身而来自四个底层机制如何协同地管理有限资源——有限的上下文窗口、有限的推理步数、有限的注意力预算、有限的信任边界。检索决定“什么时候该看外部世界”规划决定“走哪条路以及何时承认走错了”记忆决定“什么值得留下来”多智能体协作决定“多个不完全可靠的推理者如何在不互相拖垮的前提下组合出可靠性”。这四者共享同一个约束每一次额外的检索、每一步额外的规划、每一条额外的记忆、每一轮额外的通信都在消耗同样的 token 预算和延迟预算。不理解这个共享约束就只能在“多加点东西”和“系统变慢变贵”之间反复撞墙。一、检索从“查一下”到“知道自己该查、知道查得够不够”1.1 五代演进揭示的真实趋势RAG 在 2023 年至今的演进可以被压缩成一条主线检索决策权从“人”和“固定管线”逐步转移给 Agent 自身。第一代是静态的“切块—向量化—Top-K 拼接”问题不在于检索本身而在于系统没有能力判断“这次检索到底有没有用”。第二代引入重排序和混合检索解决的是召回精度但检索仍然是一个无条件执行的固定步骤。第三代查询改写让系统在检索前先“想一下怎么问”HyDE 让模型先生成一段假想答案再用它去检索抹平疑问句和陈述句之间的语域差Step-back 则把具体问题后退到更上位的概念再查。第四代自适应检索做出了关键一跃系统动态判断当前问题是否需要检索、需要检索几次在生成中途发现知识不足时主动触发新一轮检索形成迭代的检索—推理循环。第五代的变化不是“检索更准了”而是检索在架构中的位置变了RAG 从独立的管线模块变成 Agent 记忆中枢的一部分Agent 根据任务需要自主选择访问实时数据库、历史对话或结构化知识库。这对工程的含义是深远的检索不再是一个可以单独调参优化的“环节”它的触发时机、查询构造和结果消费都嵌入在 Agent 的控制流里。1.2 自适应检索的工程核心置信度信号从哪里来“判断是否需要检索”听起来像是一个分类问题但工程上真正可用的方案不是训练一个“该不该检索”的分类器而是从生成过程中提取在线信号。当前可用的信号大致分三类生成前的自知识信号模型判断问题是否落在自身参数化能力范围内生成中的置信度信号基于自一致性、矛盾检测和依赖风险计算逐步的置信分以及检索后的边际收益信号新检索到的证据是否显著改变了模型对答案的可靠性估计。一个容易踩的坑是只依赖“生成前的判断”。模型对“自己知不知道”的自我评估存在系统性偏差尤其在长尾知识和多跳问题上倾向于高估自身能力。更稳健的做法是把检索决策做成一个评估—控制循环先决定是否检索再判断检索回来的东西质量如何然后基于这个判断选择跳过、继续、重查或切换到其他来源。这与 Agent 规划中的“检查点”思想是同构的——关键不是一次决策做对而是系统有能力发现自己做错了并修正。1.3 迭代检索的收敛控制Agentic RAG 的迭代循环必须有明确的收敛机制否则会陷入“越查越不确信、越不确信越查”的消耗战。实践中的控制手段包括硬性的最大迭代次数常见 3—5 次、子查询分解把复合问题拆成原子查询每个原子查询有独立的终止条件、以及“信息增益阈值”——如果新一轮检索没有带来未见过的新事实立即终止。最后这一条尤其重要因为它把终止条件从“查了几次”升级为“查出了什么”避免了“轮次用完才停”的机械收敛。二、规划从“让模型多想一会儿”到可中断、可恢复的控制系统2.1 三个范式各自的失败模式当前 Agent 规划收敛到三个主导范式反应式ReAct、审慎式plan-and-execute和探索式tree-of-thought。它们的区别不在于“谁更聪明”而在于失败时会发生什么。ReAct 的失败模式是局部修正的极限它在 think-act-observe 的循环中处理异常但当错误的原因不在最近一步、而在若干步之前的错误前提时反应式修正无法回溯。Plan-and-execute 的失败模式是静态计划的脆性如果第 2 步失败第 3 到 10 步可能全部作废重新生成计划的代价又远高于初次生成。Tree-of-thought 的失败模式是搜索成本显式的前瞻和回溯在受控环境中有效但在工具调用代价高、状态不可逆的真实业务中探索本身可能就是不可承受的。一个被低估的事实是2025—2026 年大量标榜“规划能力”的 Agent实质上是 CoT 加 while 循环的套壳缺乏真正的任务拆解、状态管理和环境校正。区分“真规划”和“套壳规划”的试金石很简单当环境在中途发生变化时系统是继续沿着旧计划推进还是能够检测到偏差并触发重规划。2.2 Checkpointed Planning当前最务实的工程折中2025 年后期收敛出的最佳实践不是纯动态规划也不是纯静态规划而是检查点规划Agent 在完成每个主要子目标后被强制把进度提交到一个状态存储中从而在计划失败时具备恢复和回溯的能力。这个机制的关键设计选择是“提交什么”如果只提交“做到了哪一步”恢复时需要重新推导已完成步骤的中间结果如果提交完整的执行轨迹状态存储又会膨胀到不可管理。实践中更可行的粒度是提交产物和决策——已经生成的文档、已经确认的事实、已经排除的路径——而不是原始的推理 trace。配套需要解决的是循环的终止条件。仅靠 max turns 是不够的因为“达到轮次上限”只说明被截停不说明为什么没收敛。生产级系统区分至少四种终止语义MAX_TURNS预算耗尽、BUDGET_EXHAUSTEDtoken 或工具调用成本超限、STAGNATION状态摘要连续 N 轮不变即“在动但没有推进”、PARKED因审批超时或外部依赖挂起。STAGNATION 检测的价值在于它捕捉的是一种“看起来在工作、实际上在原地”的失败而这种失败在只限制轮次的系统中会一直消耗到预算烧尽。2.3 重规划为什么比重规划生成更贵规划生成是“从零开始”模型只需要给出一个合理的路径。重规划是“在废墟上重建”模型必须理解哪些已经完成了、哪些因为失败而失效、哪些不能撤销、新路径如何与已完成部分衔接而不推翻已有的有效成果。这解释了为什么实践中常见的做法是初次规划用小模型或低成本推理重规划用更强的模型但重规划的触发条件必须严格——只在“已确认的失败使得原计划不可能完成”时触发而不是每一步不顺利就推翻重来。增量化的重规划保留已验证的子目标只替换失效的分支是控制成本的关键。三、记忆三种“记住”是完全不同的问题3.1 短期、工作、长期混在一起设计必然做砸Agent 记忆最常见的工程错误是把所有“跨轮次需要保留的信息”塞进同一个向量库然后用检索解决一切。短期记忆是上下文窗口里的被动原始缓冲——最近几轮对话和工具返回它会随窗口推进被挤出处理方式就是截断或递归摘要摘要本身是有损的人名和数字往往熬不过几轮压缩。工作记忆是 Agent 主动维护的“当前状态白板” 这一步要做什么、已经做到哪里、中间结论是什么它在上下文里但它是被整理和改写的结构化状态而不是原始流水。长期记忆是跨会话的外部持久化事实偏好、约束、教训它不在上下文里需要时检索回填。三者最危险的混淆是把工作记忆写进长期记忆库。工作记忆的每条信息都有半衰期——上周的进度这周可能已经作废。三个月后检索回来一堆过期状态比没有记忆更糟因为它会以“有据可查”的形式污染当前决策。工作记忆的正确存储形态往往是“一个可整体覆盖更新的文件或记录”而不是“逐条追加的向量条目”。3.2 从短期到长期不是复制是编译短期记忆进入长期记忆不应该是把整段会话原样复制到向量库而应该是一套受控的记忆编译过程从原始经历中提取结构化事实、合并重复、消解冲突、并在写入时标注来源和置信度。Generative Agents 给出的经典范式是“观察 → 反思 → 检索”系统把经历存成记忆流定期触发反思将零散观察蒸馏成更高层的结论检索时再按需取用。遗忘同样需要机制不能靠“反正检索不到就不会被用到”的自觉。两种可落地的手段TTL 未命中清理超过时间阈值且从未被检索命中的条目定期清除和蒸馏压缩把数十条碎片记忆合并成几条结构化事实比如把二十条零散的部署记录合并成“部署环境”一节。遗忘不只是节省存储更是维持记忆信噪比的必要操作。3.3 检索式记忆的隐藏代价向量检索看起来是长期记忆的“标准答案”但它引入了一个容易被忽略的问题检索到的记忆是脱离原始语境的。一条“用户不喜欢冗长解释”的偏好记忆可能来自某次特定任务中的反馈被检索到之后却可能被不适当地泛化到所有场景。缓解手段包括在记忆条目上保留适用条件和来源上下文以及在注入时区分“事实性记忆”和“情境性记忆”——前者可以直接作为约束使用后者需要模型判断当前情境是否匹配。这也是为什么在一些单用户、单项目的场景中一个结构化 Markdown 文件整体注入 system prompt反而比向量检索更可靠它保留了记忆之间的结构和关系而不是把记忆打散成孤立的相似度匹配单元。四、多智能体协作协议解决“能不能通”治理解决“该听谁的”4.1 MCP 与 A2A 的分工不是可选项而是架构必需多智能体系统最常见的故障不是“Agent 不够聪明”而是协作边界不清工具参数没有统一格式代理之间传递了无法解析的自然语言执行代理重复提交订单一个代理失败后上游无法判断任务是否已经执行。MCP 和 A2A 分别解决两个正交方向的问题MCP 管“Agent 如何发现和调用能力”把工具从提示词中分离出来每个工具有独立的权限、超时和审计策略A2A 管“Agent 之间如何提交任务、查询状态和交换结果”核心是让 Agent 作为对等方通信而不是被当作工具调用。一个关键的设计原则是Agent 之间的协作接口不应该传递自然语言而应该传递结构化任务契约。一个可执行的任务消息至少包含任务标识、发起方、目标代理、输入数据、幂等键、截止时间和当前状态状态变化由服务端记录而不是由模型自行声称“已经完成”。这背后的工程直觉很直接模型对自身状态的陈述是不可信的审计来源。如果“任务完成了”这句话是模型说的而不是服务端状态机记录的那么整个协作链路就失去了可恢复性和可追责性。当前协议格局已经趋于稳定MCP 由 Anthropic 发起并转入 Agentic AI Foundation 治理A2A 由 Google 发起、2025 年底捐赠给 Linux 基金会2026 年两者出现融合草案形成“Agent 之间用 A2A 协调Agent 内部用 MCP 连接工具”的分层共识。4.2 冲突消解从“投票”到“可审计的仲裁”协议解决了消息能不能送达但没有解决多个 Agent 给出矛盾结论时该信谁。工程上可用的冲突消解机制大致分三档。最轻的是优先级仲裁为不同角色或不同来源设定明确的优先级冲突时高优先级覆盖低优先级代价是可能压制正确的少数意见。中间档是证据加权投票每个 Agent 的结论附带置信度和支撑证据按权重聚合权重可以来自历史准确率或当前证据的充分性。最重的是共享黑板 人工升级所有 Agent 向一个共享知识空间贡献发现、假设和方案冲突在黑板层面被检测无法自动达成共识时升级到人类。没有一种机制是普遍最优的。选择取决于错误的代价结构如果错误可以事后纠正且代价低加权投票的效率更高如果错误不可逆或涉及权限和资金黑板加人工升级是唯一负责任的选择。一个容易被忽略的点是仲裁机制本身必须是可审计的——不仅要记录“最终选了哪个结论”还要记录“哪些 Agent 提出了异议、异议的依据是什么、仲裁规则如何被应用”。这在多智能体系统中比单 Agent 的日志重要得多因为故障往往出在协作层而非单个 Agent 层。4.3 子 Agent 孵化递归分解的治理红线多智能体协作最危险的形态是递归孵化失控一个 Agent 把任务分解给子 Agent子 Agent 继续分解形成分叉炸弹式的 API 预算消耗。可落地的治理规则包括分解深度上限通常 3 层、粒度检查在孵化子 Agent 之前问“这个任务是否已经小到一次工具调用可以解决”如果是就停止分解、以及全局 Agent 计数控制器防止单个任务分支无限增殖。这些规则的价值不在于“防止极端情况”而在于它们强制设计者在系统上线前回答一个基本问题这个任务的分解结构长什么样、最坏情况下会花多少钱。五、统一视角四个机制共享同一个稀缺性把检索、规划、记忆和多智能体协作放在一起看会发现它们竞争的是同一组资源上下文窗口的 token、模型的推理步数、以及用户的等待时间。一次额外的检索占用上下文空间也排挤了本可以用于推理的注意力预算一步额外的规划消耗推理步数也推迟了首个可观察输出一条额外的记忆注入增加了信息也增加了噪声和冲突风险一轮额外的 Agent 间通信提高了协作可靠性也放大了端到端延迟。因此这四个方向的工程判断有一个共同的检验标准 “这个机制在什么条件下应该停止、应该退化为更简单的方式” 。自适应检索的成熟标志不是“总能查到”而是“知道什么时候不查也够用”规划的成熟标志不是“计划更复杂”而是“能在正确的时刻承认计划失效并以最小代价重建”记忆的成熟标志不是“记住更多”而是“知道什么该忘、什么该整体覆盖”多智能体协作的成熟标志不是“Agent 更多”而是“能用结构化契约和仲裁规则把多个不完全可靠的推理者组合成一个可运维的系统”。深挖底层的终点不是掌握更多组件而是理解每个组件在什么边界内值得存在。 
长河君 · 2026/11/4 12:12:20 · 阅读 1.2k 深挖 Agent 底层：检索、规划、记忆与多智能体协作
一个贯穿全文的判断Agent 的“能力”不来自模型本身而来自四个底层机制如何协同地管理有限资源——有限的上下文窗口、有限的推理步数、有限的注意力预算、有限的信任边界。检索决定“什么时候该看外部世界”规划决定“走哪条路以及何时承认走错了”记忆决定“什么值得留下来”多智能体协作决定“多个不完全可靠的推理者如何在不互相拖垮的前提下组合出可靠性”。这四者共享同一个约束每一次额外的检索、每一步额外的规划、每一条额外的记忆、每一轮额外的通信都在消耗同样的 token 预算和延迟预算。不理解这个共享约束就只能在“多加点东西”和“系统变慢变贵”之间反复撞墙。一、检索从“查一下”到“知道自己该查、知道查得够不够”1.1 五代演进揭示的真实趋势RAG 在 2023 年至今的演进可以被压缩成一条主线检索决策权从“人”和“固定管线”逐步转移给 Agent 自身。第一代是静态的“切块—向量化—Top-K 拼接”问题不在于检索本身而在于系统没有能力判断“这次检索到底有没有用”。第二代引入重排序和混合检索解决的是召回精度但检索仍然是一个无条件执行的固定步骤。第三代查询改写让系统在检索前先“想一下怎么问”HyDE 让模型先生成一段假想答案再用它去检索抹平疑问句和陈述句之间的语域差Step-back 则把具体问题后退到更上位的概念再查。第四代自适应检索做出了关键一跃系统动态判断当前问题是否需要检索、需要检索几次在生成中途发现知识不足时主动触发新一轮检索形成迭代的检索—推理循环。第五代的变化不是“检索更准了”而是检索在架构中的位置变了RAG 从独立的管线模块变成 Agent 记忆中枢的一部分Agent 根据任务需要自主选择访问实时数据库、历史对话或结构化知识库。这对工程的含义是深远的检索不再是一个可以单独调参优化的“环节”它的触发时机、查询构造和结果消费都嵌入在 Agent 的控制流里。1.2 自适应检索的工程核心置信度信号从哪里来“判断是否需要检索”听起来像是一个分类问题但工程上真正可用的方案不是训练一个“该不该检索”的分类器而是从生成过程中提取在线信号。当前可用的信号大致分三类生成前的自知识信号模型判断问题是否落在自身参数化能力范围内生成中的置信度信号基于自一致性、矛盾检测和依赖风险计算逐步的置信分以及检索后的边际收益信号新检索到的证据是否显著改变了模型对答案的可靠性估计。一个容易踩的坑是只依赖“生成前的判断”。模型对“自己知不知道”的自我评估存在系统性偏差尤其在长尾知识和多跳问题上倾向于高估自身能力。更稳健的做法是把检索决策做成一个评估—控制循环先决定是否检索再判断检索回来的东西质量如何然后基于这个判断选择跳过、继续、重查或切换到其他来源。这与 Agent 规划中的“检查点”思想是同构的——关键不是一次决策做对而是系统有能力发现自己做错了并修正。1.3 迭代检索的收敛控制Agentic RAG 的迭代循环必须有明确的收敛机制否则会陷入“越查越不确信、越不确信越查”的消耗战。实践中的控制手段包括硬性的最大迭代次数常见 3—5 次、子查询分解把复合问题拆成原子查询每个原子查询有独立的终止条件、以及“信息增益阈值”——如果新一轮检索没有带来未见过的新事实立即终止。最后这一条尤其重要因为它把终止条件从“查了几次”升级为“查出了什么”避免了“轮次用完才停”的机械收敛。二、规划从“让模型多想一会儿”到可中断、可恢复的控制系统2.1 三个范式各自的失败模式当前 Agent 规划收敛到三个主导范式反应式ReAct、审慎式plan-and-execute和探索式tree-of-thought。它们的区别不在于“谁更聪明”而在于失败时会发生什么。ReAct 的失败模式是局部修正的极限它在 think-act-observe 的循环中处理异常但当错误的原因不在最近一步、而在若干步之前的错误前提时反应式修正无法回溯。Plan-and-execute 的失败模式是静态计划的脆性如果第 2 步失败第 3 到 10 步可能全部作废重新生成计划的代价又远高于初次生成。Tree-of-thought 的失败模式是搜索成本显式的前瞻和回溯在受控环境中有效但在工具调用代价高、状态不可逆的真实业务中探索本身可能就是不可承受的。一个被低估的事实是2025—2026 年大量标榜“规划能力”的 Agent实质上是 CoT 加 while 循环的套壳缺乏真正的任务拆解、状态管理和环境校正。区分“真规划”和“套壳规划”的试金石很简单当环境在中途发生变化时系统是继续沿着旧计划推进还是能够检测到偏差并触发重规划。2.2 Checkpointed Planning当前最务实的工程折中2025 年后期收敛出的最佳实践不是纯动态规划也不是纯静态规划而是检查点规划Agent 在完成每个主要子目标后被强制把进度提交到一个状态存储中从而在计划失败时具备恢复和回溯的能力。这个机制的关键设计选择是“提交什么”如果只提交“做到了哪一步”恢复时需要重新推导已完成步骤的中间结果如果提交完整的执行轨迹状态存储又会膨胀到不可管理。实践中更可行的粒度是提交产物和决策——已经生成的文档、已经确认的事实、已经排除的路径——而不是原始的推理 trace。配套需要解决的是循环的终止条件。仅靠 max turns 是不够的因为“达到轮次上限”只说明被截停不说明为什么没收敛。生产级系统区分至少四种终止语义MAX_TURNS预算耗尽、BUDGET_EXHAUSTEDtoken 或工具调用成本超限、STAGNATION状态摘要连续 N 轮不变即“在动但没有推进”、PARKED因审批超时或外部依赖挂起。STAGNATION 检测的价值在于它捕捉的是一种“看起来在工作、实际上在原地”的失败而这种失败在只限制轮次的系统中会一直消耗到预算烧尽。2.3 重规划为什么比重规划生成更贵规划生成是“从零开始”模型只需要给出一个合理的路径。重规划是“在废墟上重建”模型必须理解哪些已经完成了、哪些因为失败而失效、哪些不能撤销、新路径如何与已完成部分衔接而不推翻已有的有效成果。这解释了为什么实践中常见的做法是初次规划用小模型或低成本推理重规划用更强的模型但重规划的触发条件必须严格——只在“已确认的失败使得原计划不可能完成”时触发而不是每一步不顺利就推翻重来。增量化的重规划保留已验证的子目标只替换失效的分支是控制成本的关键。三、记忆三种“记住”是完全不同的问题3.1 短期、工作、长期混在一起设计必然做砸Agent 记忆最常见的工程错误是把所有“跨轮次需要保留的信息”塞进同一个向量库然后用检索解决一切。短期记忆是上下文窗口里的被动原始缓冲——最近几轮对话和工具返回它会随窗口推进被挤出处理方式就是截断或递归摘要摘要本身是有损的人名和数字往往熬不过几轮压缩。工作记忆是 Agent 主动维护的“当前状态白板” 这一步要做什么、已经做到哪里、中间结论是什么它在上下文里但它是被整理和改写的结构化状态而不是原始流水。长期记忆是跨会话的外部持久化事实偏好、约束、教训它不在上下文里需要时检索回填。三者最危险的混淆是把工作记忆写进长期记忆库。工作记忆的每条信息都有半衰期——上周的进度这周可能已经作废。三个月后检索回来一堆过期状态比没有记忆更糟因为它会以“有据可查”的形式污染当前决策。工作记忆的正确存储形态往往是“一个可整体覆盖更新的文件或记录”而不是“逐条追加的向量条目”。3.2 从短期到长期不是复制是编译短期记忆进入长期记忆不应该是把整段会话原样复制到向量库而应该是一套受控的记忆编译过程从原始经历中提取结构化事实、合并重复、消解冲突、并在写入时标注来源和置信度。Generative Agents 给出的经典范式是“观察 → 反思 → 检索”系统把经历存成记忆流定期触发反思将零散观察蒸馏成更高层的结论检索时再按需取用。遗忘同样需要机制不能靠“反正检索不到就不会被用到”的自觉。两种可落地的手段TTL 未命中清理超过时间阈值且从未被检索命中的条目定期清除和蒸馏压缩把数十条碎片记忆合并成几条结构化事实比如把二十条零散的部署记录合并成“部署环境”一节。遗忘不只是节省存储更是维持记忆信噪比的必要操作。3.3 检索式记忆的隐藏代价向量检索看起来是长期记忆的“标准答案”但它引入了一个容易被忽略的问题检索到的记忆是脱离原始语境的。一条“用户不喜欢冗长解释”的偏好记忆可能来自某次特定任务中的反馈被检索到之后却可能被不适当地泛化到所有场景。缓解手段包括在记忆条目上保留适用条件和来源上下文以及在注入时区分“事实性记忆”和“情境性记忆”——前者可以直接作为约束使用后者需要模型判断当前情境是否匹配。这也是为什么在一些单用户、单项目的场景中一个结构化 Markdown 文件整体注入 system prompt反而比向量检索更可靠它保留了记忆之间的结构和关系而不是把记忆打散成孤立的相似度匹配单元。四、多智能体协作协议解决“能不能通”治理解决“该听谁的”4.1 MCP 与 A2A 的分工不是可选项而是架构必需多智能体系统最常见的故障不是“Agent 不够聪明”而是协作边界不清工具参数没有统一格式代理之间传递了无法解析的自然语言执行代理重复提交订单一个代理失败后上游无法判断任务是否已经执行。MCP 和 A2A 分别解决两个正交方向的问题MCP 管“Agent 如何发现和调用能力”把工具从提示词中分离出来每个工具有独立的权限、超时和审计策略A2A 管“Agent 之间如何提交任务、查询状态和交换结果”核心是让 Agent 作为对等方通信而不是被当作工具调用。一个关键的设计原则是Agent 之间的协作接口不应该传递自然语言而应该传递结构化任务契约。一个可执行的任务消息至少包含任务标识、发起方、目标代理、输入数据、幂等键、截止时间和当前状态状态变化由服务端记录而不是由模型自行声称“已经完成”。这背后的工程直觉很直接模型对自身状态的陈述是不可信的审计来源。如果“任务完成了”这句话是模型说的而不是服务端状态机记录的那么整个协作链路就失去了可恢复性和可追责性。当前协议格局已经趋于稳定MCP 由 Anthropic 发起并转入 Agentic AI Foundation 治理A2A 由 Google 发起、2025 年底捐赠给 Linux 基金会2026 年两者出现融合草案形成“Agent 之间用 A2A 协调Agent 内部用 MCP 连接工具”的分层共识。4.2 冲突消解从“投票”到“可审计的仲裁”协议解决了消息能不能送达但没有解决多个 Agent 给出矛盾结论时该信谁。工程上可用的冲突消解机制大致分三档。最轻的是优先级仲裁为不同角色或不同来源设定明确的优先级冲突时高优先级覆盖低优先级代价是可能压制正确的少数意见。中间档是证据加权投票每个 Agent 的结论附带置信度和支撑证据按权重聚合权重可以来自历史准确率或当前证据的充分性。最重的是共享黑板 人工升级所有 Agent 向一个共享知识空间贡献发现、假设和方案冲突在黑板层面被检测无法自动达成共识时升级到人类。没有一种机制是普遍最优的。选择取决于错误的代价结构如果错误可以事后纠正且代价低加权投票的效率更高如果错误不可逆或涉及权限和资金黑板加人工升级是唯一负责任的选择。一个容易被忽略的点是仲裁机制本身必须是可审计的——不仅要记录“最终选了哪个结论”还要记录“哪些 Agent 提出了异议、异议的依据是什么、仲裁规则如何被应用”。这在多智能体系统中比单 Agent 的日志重要得多因为故障往往出在协作层而非单个 Agent 层。4.3 子 Agent 孵化递归分解的治理红线多智能体协作最危险的形态是递归孵化失控一个 Agent 把任务分解给子 Agent子 Agent 继续分解形成分叉炸弹式的 API 预算消耗。可落地的治理规则包括分解深度上限通常 3 层、粒度检查在孵化子 Agent 之前问“这个任务是否已经小到一次工具调用可以解决”如果是就停止分解、以及全局 Agent 计数控制器防止单个任务分支无限增殖。这些规则的价值不在于“防止极端情况”而在于它们强制设计者在系统上线前回答一个基本问题这个任务的分解结构长什么样、最坏情况下会花多少钱。五、统一视角四个机制共享同一个稀缺性把检索、规划、记忆和多智能体协作放在一起看会发现它们竞争的是同一组资源上下文窗口的 token、模型的推理步数、以及用户的等待时间。一次额外的检索占用上下文空间也排挤了本可以用于推理的注意力预算一步额外的规划消耗推理步数也推迟了首个可观察输出一条额外的记忆注入增加了信息也增加了噪声和冲突风险一轮额外的 Agent 间通信提高了协作可靠性也放大了端到端延迟。因此这四个方向的工程判断有一个共同的检验标准 “这个机制在什么条件下应该停止、应该退化为更简单的方式” 。自适应检索的成熟标志不是“总能查到”而是“知道什么时候不查也够用”规划的成熟标志不是“计划更复杂”而是“能在正确的时刻承认计划失效并以最小代价重建”记忆的成熟标志不是“记住更多”而是“知道什么该忘、什么该整体覆盖”多智能体协作的成熟标志不是“Agent 更多”而是“能用结构化契约和仲裁规则把多个不完全可靠的推理者组合成一个可运维的系统”。深挖底层的终点不是掌握更多组件而是理解每个组件在什么边界内值得存在。