Reflection (反思模式)基础定义: 一个线性三步流水线LLM 先生成、再批评、再改进自己的输出无需外部工具即可提升质量。核心思想: LLM 做 critic 比做 generator 更稳定。把生成拆成 “创作” 和 “评估” 两个 pass, 比单次尝试效果更好。核心工作流: ① LLM 生成初始草稿 → ② Critic LLM 审视草稿并输出批评意见 → ③ Refiner LLM 根据批评改进草稿 → ④ 输出最终优化结果。形式化描述:S {s₀} ∪ {(d, c, r) | d ∈ Drafts, c ∈ Critiques, r ∈ Refinements}δ : s₀ → draft → critique → refined → FF {refined} (单一终止状态)Γ {critique ≠ ∅, refined ≠ draft}终止性: 结构性终止 —— 三步走完即终止, 无循环。示意图Generator ---- Critic ---- Refiner ---- Final Output(LLM) (LLM) (LLM)draft critique refined扩展维度 分析要解决什么 LLM 输出质量不稳定, 需要自检自修闭环State S {draft, critique, refined}, 三个离散阶段拓扑 线性三步链: Generate → Critique → RefineRouter 静态: 始终沿 draft → critique → refined 单向流动失败模式 critique 泛泛而谈; refine 不收敛; 无外部信息注入导致自说自话何时升级 需要外部工具获取新信息时 → Tool Use; 需要多步交互时 → ReAct框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 线性链Routing 静态Guard 无 (最小实现)Mode live核心维度 State Topology核心洞察: LLM 作为 critic 比作为 generator 更稳定。把生成和评判分离, 是最小但最有效的质量闭环。4.2 Tool Use (工具调用模式)基础定义: LLM 可以调用外部工具API、数据库、计算器来获取训练数据之外的真实世界信息然后综合结果。核心思想: 突破不在于 “会函数调用”, 而在于文本控制流可以跨越到结构化世界再返回。真正的难点是序列化 / 反序列化不是 prompting。核心工作流: ① 用户发起请求 → ② LLM 决定是否需要调用工具及调用哪个 → ③ 执行工具调用并获取结构化结果 → ④ LLM 综合工具返回结果生成最终回答。形式化描述:S H × TC × TR (H对话历史, TCtool calls, TRtool results)δ : (h, ∅, ∅) → (h, tc, ∅) → (h, tc, tr) → F (每次工具调用)F {s | LLM 输出不含 tool_call}Γ {∀ tc ∈ TC, tc.tool_name ∈ RegisteredTools}终止性: 条件终止 —— 需 max_iterations 兜底, 防止 tool-call loop。示意图2 Tool Use扩展维度 分析要解决什么 LLM 知识有截止日期, 无法访问外部系统State S 拓扑 LLM ⇄ Tool 双向交互, 可多轮Router LLM 动态决定是否调用工具、调用哪个工具失败模式 tool hallucination (调用不存在的工具); 参数错误; tool 返回超长截断何时升级 需要在工具调用间加入推理时 → ReAct框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 星形 (LLM 为中心, tool 为叶子)Routing LLM 动态Guard tool schema 校验Mode live核心维度 ACI核心洞察: Tool Use 首次将 文本控制流 跨越到 结构化世界。tool_call 是 agent 的行动边界第一次突破语言.4.3 ReAct (推理-行动循环)基础定义: 一个迭代循环LLM 交替进行思考推理下一步做什么、行动调用工具、观察处理结果, 直到任务完成。核心思想: 从工具结果反馈到 LLM 的那条回边是整个 agent 架构中最重要的结构元素。这是 80% 任务的合理起点。核心工作流: ① LLM 推理当前状态并决定下一步行动 → ② 执行工具调用Action → ③ 接收工具返回的观测结果Observation → ④ 循环回到①直到 LLM 判断任务完成输出最终答案。形式化描述:S (T × A × O)^k × T (TThought, AAction, OObservation)δ : (…, t_i) → (…, t_i, a_i) → (…, t_i, a_i, o_i) → (…, t_{i1})F {s | t_k “Final Answer” ∨ k ≥ max_iterations}Γ {∀ a_i, a_i ∈ AvailableActions}终止性: 条件终止 —— 需 max_iterations 兜底 (工程上推荐默认值 20-50)。示意图3 ReAct扩展维度 分析要解决什么 复杂任务需要推理与行动的交替迭代State S {(thought, action, observation)^k}, k 为已执行轮次拓扑 循环: Thought → Action → Observation → Thought → …Router LLM 在每轮生成 thoughtaction, observation 由环境返回失败模式 循环不收敛; action 重复; thought 与 action 脱节何时升级 需要提前规划时 → Planning; 需要多角色时 → Multi-Agent框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 循环 (自环)Routing LLM 动态Guard action schema 校验Mode live核心维度 Topology (首个循环拓扑)核心洞察: ReAct 让 Agent 真正成形。Thought→Action→Observation 是最小但完整的感知-决策-行动闭环, 也是 80% 任务的合理起点。4.4 Planning (规划模式)基础定义: LLM 先生成一个显式的分步计划然后逐步执行每一步使控制流本身成为一等可检视对象。核心思想: Planning 新增的不是 “更聪明的思考”, 而是让控制流变得可视、可修改、可审计。plan 队列单调递减 — 这是终止性的保证。核心工作流: ① LLM 生成显式分步计划plan 队列 → ② 按序取出下一步并执行 → ③ 将中间结果存入状态 → ④ 重复②直到 plan 为空综合所有结果输出。形式化描述:S (P, i, R) 其中 P [step₁, step₂, …, stepₙ] 为计划队列i 为当前步骤索引, R 为已执行步骤结果δ : (P, i, R) → execute(stepᵢ) → (P, i1, R∪{resultᵢ})∨ replan → (P’, 0, R) (当 resultᵢ 偏离预期)F {s | i |P| ∨ |P| 0} (计划执行完毕)Γ {|P| 单调递减 (无 replan 时), ∀ step ∈ P, step.is_executable}终止性: 有界终止 —— 无 replan 时 plan 队列单调递减; 有 replan 时仍需 max_iterations。示意图4 Planning扩展维度 分析要解决什么 复杂多步任务的全局编排, 避免 ReAct 短视State S 拓扑 外层循环: Plan → Execute_Step → Update → Plan(replan?)Router LLM 生成 plan 队列, 每步后检查是否需 replan失败模式 plan 过于抽象无法执行; plan 偏差累积; 频繁 replan 震荡何时升级 需要验证每步结果时 → PEV; 需要多角色协作时 → Multi-Agent框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 带条件分支的循环Routing LLM 动态 计划偏移检测Guard step 可执行性检查Mode live核心维度 State (plan 作为一等公民)核心洞察: Planning 不是更聪明的思考, 而是 把控制流变成可检视对象。plan 是一个可以审计、可打断、可恢复的数据结构。2.5 PEV (计划-执行-验证)基础定义: 在 Planning 基础上增加验证步骤。每次执行后验证结果失败则重试或重新规划确保错误不会静默传播。核心思想: 执行不再是 “完成了一步”, 而是 “产生了一个待验证结果”。验证让失败变得显式而非默认传播。核心工作流: ① 生成执行计划 → ② 执行当前步骤 → ③ 验证执行结果通过则进入下一步失败则重试或重新规划 → ④ 全部步骤通过验证后综合输出最终结果。形式化描述:S (P, i, R, V) 其中 V {pass, fail, uncertain}δ : (P, i, R, ∅) → execute → (P, i, R∪{r}, ∅) → verify → (P, i, R, v)→ (vpass ? (P, i1, R, ∅) : (P, i, R, ∅)) – 重试或 replanF {s | i |P| ∧ ∀ v_j ∈ V_history, v_j pass}Γ {verifier ∉ executor (独立性要求), ∀ step, step.verified_before_proceed}终止性: 条件终止 —— 需要 max_retries max_iterations 双重兜底。示意图5 PEV (计划-执行-验证)扩展维度 分析要解决什么 执行步骤后结果无声传播错误State S 拓扑 Plan → Execute → Verify → (pass? next : retry/replan)Router 基于 verification_result 分支: pass → 下一步, fail → 重试或 replan失败模式 verifier 漏检; 过度验证导致效率低; verifier 与 executor 同源偏差何时升级 需要冗余而非单点验证时 → Ensemble; 需要预执行安全时 → Dry-Run框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology Plan→Execute→Verify 三元组循环Routing 验证驱动的条件分支Guard 输出守卫 (verification 作为独立闸门)Mode live核心维度 Guard (验证成为一等公民)核心洞察: PEV 的核心贡献是让 验证成为一等公民。S 新增 verification_result 字段, 错误不再静默传播, 每个 step 的输出必须签字画押。4.6 Multi-Agent (多智能体协作)基础定义: 多个具有不同角色人设 / 工具的 LLM Agent 按固定流水线排列每个处理自己的领域后将结果传给综合器。核心思想: 把单个 prompt 中的隐式角色切换变成显式独立节点。工程收益每个 agent 可单独调试、替换、评估、赋予不同工具。核心工作流: ① 任务分解为子领域 → ② 角色分配给各专家 Agent → ③ 按流水线协作前一个的输出是后一个的输入 → ④ 由 Synthesize Agent 汇总所有角色产出生成最终结果。形式化描述:S (Agent₁.output, Agent₂.output, …, Agentₙ.output) × SharedContextδ : (∅, ∅, …, ∅, ctx) → (a₁_out, ∅, …, ∅, ctx) → (a₁_out, a₂_out, …, ∅, ctx)→ … → (a₁_out, …, aₙ_out, ctx) → FF {s | ∀ i ∈ [1, n], Agentᵢ.output ≠ ∅}Γ {∀ i, Agentᵢ.output.schema ∈ expected_input_schema(Agentᵢ₊₁)}终止性: 结构性终止 —— 固定流水线走完即终止。示意图Agent A ---- Agent B ---- Agent C ---- Synthesizer ---- Output(Finance) (Tech) (Legal) (aggregate)role_A role_B role_C扩展维度 分析要解决什么 单 Agent 能力边界有限, 需要认知分工State S 拓扑 固定流水线: Agent₁ → Agent₂ → … → Agentₙ, 或有向无环图 (DAG)Router 静态: 按预设顺序传递, 每个 agent 的输出作为下一个 agent 的输入失败模式 agent 间接口不对齐; 上游错误级联放大; 角色职责重叠或遗漏何时升级 需要动态调度 agent 时 → Blackboard; 需要中心路由时 → Meta-Controller框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology DAG (流水线)Routing 静态 (预设顺序)Guard agent 间 schema 校验Mode live核心维度 Topology (多节点)核心洞察: Multi-Agent 的精髓不是让多个 LLM 聊天, 而是 把认知分工写进图里。每个 agent 可单独调试、替换、评估——这是从 craft 到 engineering 的关键一步。4.7 Blackboard (黑板架构)基础定义: 共享工作区黑板是系统中心。Controller LLM 读取黑板状态动态选择下一个要调用的 specialist agent。核心思想: 控制从 “预定义工作流” 转向 “共享状态 调度器”。黑板积累知识controller 根据已有内容决定还需要什么。核心工作流: ① Controller 读取黑板当前状态 → ② 动态选择最合适的 Specialist Agent → ③ Specialist 执行任务并将结果写回黑板 → ④ 循环回到①直到 Controller 判断信息充分输出 FINISH。形式化描述:S (BB, H) 其中 BB 为黑板字典, H 为调度历史δ : (BBₜ, H) → Controller.select(BBₜ) → specialistᵢ(BBₜ) → (BBₜ₊₁, H∪{i})∨ (BBₜ satisfies goal) → FF {s | goal_condition(BB) true ∨ |H| ≥ max_steps}Γ {∀ write to BB, write.key ∈ RegisteredKeys, BB 始终为合法状态}终止性: 条件终止 —— 需 goal_condition 或 max_steps 兜底。示意图7 Blackboard扩展维度 分析要解决什么 问题求解需要多个专家动态协作, 无法预设固定顺序State S 拓扑 星形: Controller 读写 Blackboard, 激活对应 SpecialistRouter Controller 基于 blackboard 快照动态选择 specialist (条件LLM)失败模式 blackboard 信息冲突; Controller 调度不稳; specialist 饥饿何时升级 需要大规模并行时 → Ensemble; 需要自我边界判断时 → Metacognitive框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 星形 (Blackboard 为中心)Routing 条件LLM 动态 (Controller 决策)Guard BB 写入校验Mode live核心维度 State (共享状态成为系统中心)核心洞察: Blackboard 的精髓是把 共享状态提升为系统中心。Controller 不只路由, 它在监控一个不断演化的信息集合。这是从消息传递到状态管理的范式转换。
0x04 17 种架构逐一分析
Reflection (反思模式)基础定义: 一个线性三步流水线LLM 先生成、再批评、再改进自己的输出无需外部工具即可提升质量。核心思想: LLM 做 critic 比做 generator 更稳定。把生成拆成 “创作” 和 “评估” 两个 pass, 比单次尝试效果更好。核心工作流: ① LLM 生成初始草稿 → ② Critic LLM 审视草稿并输出批评意见 → ③ Refiner LLM 根据批评改进草稿 → ④ 输出最终优化结果。形式化描述:S {s₀} ∪ {(d, c, r) | d ∈ Drafts, c ∈ Critiques, r ∈ Refinements}δ : s₀ → draft → critique → refined → FF {refined} (单一终止状态)Γ {critique ≠ ∅, refined ≠ draft}终止性: 结构性终止 —— 三步走完即终止, 无循环。示意图Generator ---- Critic ---- Refiner ---- Final Output(LLM) (LLM) (LLM)draft critique refined扩展维度 分析要解决什么 LLM 输出质量不稳定, 需要自检自修闭环State S {draft, critique, refined}, 三个离散阶段拓扑 线性三步链: Generate → Critique → RefineRouter 静态: 始终沿 draft → critique → refined 单向流动失败模式 critique 泛泛而谈; refine 不收敛; 无外部信息注入导致自说自话何时升级 需要外部工具获取新信息时 → Tool Use; 需要多步交互时 → ReAct框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 线性链Routing 静态Guard 无 (最小实现)Mode live核心维度 State Topology核心洞察: LLM 作为 critic 比作为 generator 更稳定。把生成和评判分离, 是最小但最有效的质量闭环。4.2 Tool Use (工具调用模式)基础定义: LLM 可以调用外部工具API、数据库、计算器来获取训练数据之外的真实世界信息然后综合结果。核心思想: 突破不在于 “会函数调用”, 而在于文本控制流可以跨越到结构化世界再返回。真正的难点是序列化 / 反序列化不是 prompting。核心工作流: ① 用户发起请求 → ② LLM 决定是否需要调用工具及调用哪个 → ③ 执行工具调用并获取结构化结果 → ④ LLM 综合工具返回结果生成最终回答。形式化描述:S H × TC × TR (H对话历史, TCtool calls, TRtool results)δ : (h, ∅, ∅) → (h, tc, ∅) → (h, tc, tr) → F (每次工具调用)F {s | LLM 输出不含 tool_call}Γ {∀ tc ∈ TC, tc.tool_name ∈ RegisteredTools}终止性: 条件终止 —— 需 max_iterations 兜底, 防止 tool-call loop。示意图2 Tool Use扩展维度 分析要解决什么 LLM 知识有截止日期, 无法访问外部系统State S 拓扑 LLM ⇄ Tool 双向交互, 可多轮Router LLM 动态决定是否调用工具、调用哪个工具失败模式 tool hallucination (调用不存在的工具); 参数错误; tool 返回超长截断何时升级 需要在工具调用间加入推理时 → ReAct框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 星形 (LLM 为中心, tool 为叶子)Routing LLM 动态Guard tool schema 校验Mode live核心维度 ACI核心洞察: Tool Use 首次将 文本控制流 跨越到 结构化世界。tool_call 是 agent 的行动边界第一次突破语言.4.3 ReAct (推理-行动循环)基础定义: 一个迭代循环LLM 交替进行思考推理下一步做什么、行动调用工具、观察处理结果, 直到任务完成。核心思想: 从工具结果反馈到 LLM 的那条回边是整个 agent 架构中最重要的结构元素。这是 80% 任务的合理起点。核心工作流: ① LLM 推理当前状态并决定下一步行动 → ② 执行工具调用Action → ③ 接收工具返回的观测结果Observation → ④ 循环回到①直到 LLM 判断任务完成输出最终答案。形式化描述:S (T × A × O)^k × T (TThought, AAction, OObservation)δ : (…, t_i) → (…, t_i, a_i) → (…, t_i, a_i, o_i) → (…, t_{i1})F {s | t_k “Final Answer” ∨ k ≥ max_iterations}Γ {∀ a_i, a_i ∈ AvailableActions}终止性: 条件终止 —— 需 max_iterations 兜底 (工程上推荐默认值 20-50)。示意图3 ReAct扩展维度 分析要解决什么 复杂任务需要推理与行动的交替迭代State S {(thought, action, observation)^k}, k 为已执行轮次拓扑 循环: Thought → Action → Observation → Thought → …Router LLM 在每轮生成 thoughtaction, observation 由环境返回失败模式 循环不收敛; action 重复; thought 与 action 脱节何时升级 需要提前规划时 → Planning; 需要多角色时 → Multi-Agent框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 循环 (自环)Routing LLM 动态Guard action schema 校验Mode live核心维度 Topology (首个循环拓扑)核心洞察: ReAct 让 Agent 真正成形。Thought→Action→Observation 是最小但完整的感知-决策-行动闭环, 也是 80% 任务的合理起点。4.4 Planning (规划模式)基础定义: LLM 先生成一个显式的分步计划然后逐步执行每一步使控制流本身成为一等可检视对象。核心思想: Planning 新增的不是 “更聪明的思考”, 而是让控制流变得可视、可修改、可审计。plan 队列单调递减 — 这是终止性的保证。核心工作流: ① LLM 生成显式分步计划plan 队列 → ② 按序取出下一步并执行 → ③ 将中间结果存入状态 → ④ 重复②直到 plan 为空综合所有结果输出。形式化描述:S (P, i, R) 其中 P [step₁, step₂, …, stepₙ] 为计划队列i 为当前步骤索引, R 为已执行步骤结果δ : (P, i, R) → execute(stepᵢ) → (P, i1, R∪{resultᵢ})∨ replan → (P’, 0, R) (当 resultᵢ 偏离预期)F {s | i |P| ∨ |P| 0} (计划执行完毕)Γ {|P| 单调递减 (无 replan 时), ∀ step ∈ P, step.is_executable}终止性: 有界终止 —— 无 replan 时 plan 队列单调递减; 有 replan 时仍需 max_iterations。示意图4 Planning扩展维度 分析要解决什么 复杂多步任务的全局编排, 避免 ReAct 短视State S 拓扑 外层循环: Plan → Execute_Step → Update → Plan(replan?)Router LLM 生成 plan 队列, 每步后检查是否需 replan失败模式 plan 过于抽象无法执行; plan 偏差累积; 频繁 replan 震荡何时升级 需要验证每步结果时 → PEV; 需要多角色协作时 → Multi-Agent框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 带条件分支的循环Routing LLM 动态 计划偏移检测Guard step 可执行性检查Mode live核心维度 State (plan 作为一等公民)核心洞察: Planning 不是更聪明的思考, 而是 把控制流变成可检视对象。plan 是一个可以审计、可打断、可恢复的数据结构。2.5 PEV (计划-执行-验证)基础定义: 在 Planning 基础上增加验证步骤。每次执行后验证结果失败则重试或重新规划确保错误不会静默传播。核心思想: 执行不再是 “完成了一步”, 而是 “产生了一个待验证结果”。验证让失败变得显式而非默认传播。核心工作流: ① 生成执行计划 → ② 执行当前步骤 → ③ 验证执行结果通过则进入下一步失败则重试或重新规划 → ④ 全部步骤通过验证后综合输出最终结果。形式化描述:S (P, i, R, V) 其中 V {pass, fail, uncertain}δ : (P, i, R, ∅) → execute → (P, i, R∪{r}, ∅) → verify → (P, i, R, v)→ (vpass ? (P, i1, R, ∅) : (P, i, R, ∅)) – 重试或 replanF {s | i |P| ∧ ∀ v_j ∈ V_history, v_j pass}Γ {verifier ∉ executor (独立性要求), ∀ step, step.verified_before_proceed}终止性: 条件终止 —— 需要 max_retries max_iterations 双重兜底。示意图5 PEV (计划-执行-验证)扩展维度 分析要解决什么 执行步骤后结果无声传播错误State S 拓扑 Plan → Execute → Verify → (pass? next : retry/replan)Router 基于 verification_result 分支: pass → 下一步, fail → 重试或 replan失败模式 verifier 漏检; 过度验证导致效率低; verifier 与 executor 同源偏差何时升级 需要冗余而非单点验证时 → Ensemble; 需要预执行安全时 → Dry-Run框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology Plan→Execute→Verify 三元组循环Routing 验证驱动的条件分支Guard 输出守卫 (verification 作为独立闸门)Mode live核心维度 Guard (验证成为一等公民)核心洞察: PEV 的核心贡献是让 验证成为一等公民。S 新增 verification_result 字段, 错误不再静默传播, 每个 step 的输出必须签字画押。4.6 Multi-Agent (多智能体协作)基础定义: 多个具有不同角色人设 / 工具的 LLM Agent 按固定流水线排列每个处理自己的领域后将结果传给综合器。核心思想: 把单个 prompt 中的隐式角色切换变成显式独立节点。工程收益每个 agent 可单独调试、替换、评估、赋予不同工具。核心工作流: ① 任务分解为子领域 → ② 角色分配给各专家 Agent → ③ 按流水线协作前一个的输出是后一个的输入 → ④ 由 Synthesize Agent 汇总所有角色产出生成最终结果。形式化描述:S (Agent₁.output, Agent₂.output, …, Agentₙ.output) × SharedContextδ : (∅, ∅, …, ∅, ctx) → (a₁_out, ∅, …, ∅, ctx) → (a₁_out, a₂_out, …, ∅, ctx)→ … → (a₁_out, …, aₙ_out, ctx) → FF {s | ∀ i ∈ [1, n], Agentᵢ.output ≠ ∅}Γ {∀ i, Agentᵢ.output.schema ∈ expected_input_schema(Agentᵢ₊₁)}终止性: 结构性终止 —— 固定流水线走完即终止。示意图Agent A ---- Agent B ---- Agent C ---- Synthesizer ---- Output(Finance) (Tech) (Legal) (aggregate)role_A role_B role_C扩展维度 分析要解决什么 单 Agent 能力边界有限, 需要认知分工State S 拓扑 固定流水线: Agent₁ → Agent₂ → … → Agentₙ, 或有向无环图 (DAG)Router 静态: 按预设顺序传递, 每个 agent 的输出作为下一个 agent 的输入失败模式 agent 间接口不对齐; 上游错误级联放大; 角色职责重叠或遗漏何时升级 需要动态调度 agent 时 → Blackboard; 需要中心路由时 → Meta-Controller框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology DAG (流水线)Routing 静态 (预设顺序)Guard agent 间 schema 校验Mode live核心维度 Topology (多节点)核心洞察: Multi-Agent 的精髓不是让多个 LLM 聊天, 而是 把认知分工写进图里。每个 agent 可单独调试、替换、评估——这是从 craft 到 engineering 的关键一步。4.7 Blackboard (黑板架构)基础定义: 共享工作区黑板是系统中心。Controller LLM 读取黑板状态动态选择下一个要调用的 specialist agent。核心思想: 控制从 “预定义工作流” 转向 “共享状态 调度器”。黑板积累知识controller 根据已有内容决定还需要什么。核心工作流: ① Controller 读取黑板当前状态 → ② 动态选择最合适的 Specialist Agent → ③ Specialist 执行任务并将结果写回黑板 → ④ 循环回到①直到 Controller 判断信息充分输出 FINISH。形式化描述:S (BB, H) 其中 BB 为黑板字典, H 为调度历史δ : (BBₜ, H) → Controller.select(BBₜ) → specialistᵢ(BBₜ) → (BBₜ₊₁, H∪{i})∨ (BBₜ satisfies goal) → FF {s | goal_condition(BB) true ∨ |H| ≥ max_steps}Γ {∀ write to BB, write.key ∈ RegisteredKeys, BB 始终为合法状态}终止性: 条件终止 —— 需 goal_condition 或 max_steps 兜底。示意图7 Blackboard扩展维度 分析要解决什么 问题求解需要多个专家动态协作, 无法预设固定顺序State S 拓扑 星形: Controller 读写 Blackboard, 激活对应 SpecialistRouter Controller 基于 blackboard 快照动态选择 specialist (条件LLM)失败模式 blackboard 信息冲突; Controller 调度不稳; specialist 饥饿何时升级 需要大规模并行时 → Ensemble; 需要自我边界判断时 → Metacognitive框架映射:我们来看看 本模式 如何映射到其它模式上。维度 取值Topology 星形 (Blackboard 为中心)Routing 条件LLM 动态 (Controller 决策)Guard BB 写入校验Mode live核心维度 State (共享状态成为系统中心)核心洞察: Blackboard 的精髓是把 共享状态提升为系统中心。Controller 不只路由, 它在监控一个不断演化的信息集合。这是从消息传递到状态管理的范式转换。
