Technical Learning Document · English Research / Chinese Synthesis

多 Agent 架构融合：Supervisor × State Graph × Shared State 的微内核设计

围绕六类基础协作范式，重点研究主从协调、图编排 / 状态机、共享黑板三者的融合，以及“确定性图结构”与“概率性 LLM 规划”之间如何划分控制权。面向搜索、研究、资料汇聚等信息源任务给出可实现的微内核方案。

SupervisorState MachineBlackboardMicrokernelAdaptive WorkflowInformation Retrieval

研究资料：英文论文、官方框架文档与工程复盘；检索与综合时间：2026-10-07。

结论先行：把“自主性”放进受约束的控制面

一句话结论：更稳的融合形态不是让 Graph 和 LLM 同时争夺“下一步由谁决定”，而是让 Graph 定义不变量、生命周期与安全边界，让 概率性 Planner 在边界内选择路径、生成子任务，并以 Graph Patch 的形式申请结构变化，让 Blackboard 成为可审计的事实与证据平面。

对信息源任务，这种分工特别自然：搜索路径无法完全预定义，所以需要 Agent 自主探索；但引用完整性、预算、去重、来源可信度、重试上限、终止条件又必须是确定性的。Anthropic 的生产级 Research 系统采用 orchestrator-worker：主 Agent 规划并并行生成子 Agent 搜索不同方向，再汇总结果；其内部评估中，多 Agent 配置相对单 Agent 提升明显，但性能方差很大一部分也由 token 消耗、工具调用数量和模型选择解释。这提示我们：多 Agent 的价值首先来自可控地扩大搜索预算与并行覆盖，而不是“Agent 数量本身”。^[R1]

与此同时，2025 年的 MAST 研究在多个框架和任务上归纳出 14 类多 Agent 失败模式，集中在系统设计、Agent 间失配以及验证 / 终止问题上，说明仅靠增加角色和对话轮次并不会自动得到可靠协作。^[R2]

Kernel owns

机制与不变量

事件路由、状态提交、并发控制、权限、预算、检查点、可观测性、终止硬条件。

Planner owns

策略与探索

任务拆分、Worker 选择、查询改写、是否需要第二轮搜索、候选 Graph Patch。

Blackboard owns

证据与共享事实

Claim、Evidence、Artifact、Provenance、冲突标记、任务状态；不承载隐式控制流。

六种基础架构：不要按“框架名称”，要按“控制权位置”理解

模式	控制权在哪里	共享状态	适合任务	关键风险
1. Supervisor / Coordinator	中心 Agent 动态决定分解与委派	通常集中在 Supervisor 上下文或外部 State	研究、跨工具复合任务、专家路由	中心瓶颈、上下文膨胀、单点决策错误
2. Graph / StateFlow	显式节点、边与状态转移规则	一等公民	长流程、可审计、高确定性业务	图僵化；复杂循环 / 动态宽度表达成本高
3. Sequential Pipeline	固定顺序	以前序输出作为后序输入	标准化生产线	级联误差、局部错误被放大
4. Blackboard / Shared State	Agent 监听环境并自主动作	核心机制	异步并行、长期任务、多个独立消费者	竞争写入、陈旧读、索引与一致性成本
5. Debate / Consensus	多方对话 + 裁判 / 投票	对话记录或论点集合	高风险推理、交叉审查	震荡、同质化、成本和收敛问题
6. Dynamic Handoff / Swarm	当前 Agent 决定下一位 owner	通常沿对话上下文传递	客服分流、轻量专家切换	环路、上下文污染、多步依赖难表达

代表实现也在发生变化。LangGraph 仍提供 stateful graph、checkpoint/store 等图式运行时能力；但其独立 langgraph-supervisor Python 仓库已在 2026-09-20 归档，官方现在更推荐直接用“Agent as tools / handoff tools”实现 Supervisor，以获得更细的上下文控制。^[R3]^[R4]

OpenAI Agents SDK 的 handoff 也体现了模式 6 的核心：handoff 在模型侧表现为工具调用，由当前 Agent 把控制权转交给明确的目标 Agent；同时 SDK 允许过滤传给下一个 Agent 的历史，并动态启用 / 禁用 handoff。^[R5]

为什么 1 / 2 / 4 正在融合：三个层次解决的是不同问题

从近两年的框架演进看，Supervisor、Graph、Shared State 并不是互斥范式，而是在逐渐形成三层职责：

Control Plane — 目标、预算、策略、重规划

Supervisor / Planner — 概率性决策

Workflow / State Graph — 可执行控制流与验证

Blackboard / Event Log — 事实、证据、运行状态、持久化

CrewAI 当前文档直接把这类融合写进产品抽象：Crews 强调自主协作，Flows 提供结构化、事件驱动、带状态的确定性执行，并明确描述为“在需要的位置注入 pockets of agency”。^[R6] AutoGen v0.4 的底层则采用 actor model 与异步事件消息，以解耦消息传递与 Agent 处理逻辑；其 GraphFlow 在 AgentChat 层提供有向图、条件分支、并行和循环。^[R7]^[R8] LlamaIndex Workflows 也以 event-driven、async-first、stateful 的工作流为基础，并支持 fan-out / fan-in、动态事件与检查点。^[R9]

因此，工业上的真实问题已经从“选 Supervisor 还是 Graph”变成：哪些决策必须由确定性 runtime 做，哪些决策可以委托给概率模型，状态在哪个一致性域里提交，以及模型何时有资格修改工作流本身。

研究侧也在把 workflow 当作优化对象

GPTSwarm 把 LLM Agent 系统统一成计算图，并优化节点 Prompt 与边连接；AFlow 把 agentic workflow 生成建模成代码表示工作流上的搜索问题，用 Monte Carlo Tree Search 根据执行反馈迭代改写拓扑；EvoAgentX 则把 workflow generation、execution、evaluation 与 evolutionary optimization 集成到一个平台里。^[R10]^[R11]^[R12]

2024

StateFlow / GPTSwarm

一边把复杂任务显式状态机化，一边把 Agent 协作整体表示成可优化计算图。^[R13]^[R10]

2025

AFlow / MAST / EvoAgentX / AutoGen v0.4

工作流自动搜索、失败分类、拓扑进化、事件驱动 actor runtime 同时成熟。^[R11]^[R2]^[R12]^[R7]

2026

Adaptive topology / topology-aware optimization

Adaptive Graph Pruning 根据任务动态选择 Agent 数量与通信边；MASPOB 则显式研究固定拓扑下 prompt 间的 topology-induced coupling；HeGFlow 进一步把 Agent、Tool 与执行拓扑共同建模成异构图优化。^[R14]^[R15]^[R16]

核心矛盾：图结构与概率性模型为什么会发生规划冲突

这个冲突不是“Graph 不智能、LLM 不可靠”这么简单，而是两种控制模型在同一个时间点争夺同一类权限。

冲突维度	Graph / State Machine 偏好	LLM Planner 偏好	典型故障
下一步决策权	由边、guard、状态转移决定	根据上下文即时选 action	模型选择了图中不可达动作；或图把模型困在低价值路径
状态表示	结构化、离散、可验证	自然语言、隐变量、概率分布	“模型认为已完成”但 State 并未满足 invariant
规划时间尺度	设计 / 编译阶段较稳定	每一步均可重新规划	拓扑频繁抖动，难以复现和缓存
失败恢复	预设 retry / fallback edge	尝试新策略或新工具	死循环、无界探索、重复调用
并发	fan-out / join 关系显式	动态决定创建多少 Worker	任务重复、join 条件不确定、孤儿任务
优化目标	跨任务分布的整体稳定性	当前实例的局部最优	Planner 为单次收益破坏长期可维护结构
终止	满足形式化条件即可结束	根据语义“觉得够了”	过早终止或无止境补充资料

关键洞察：把“选择路径”和“修改图”分成两种能力

弱权限：Planner 在当前图允许的候选动作中做概率选择，这是运行时 routing。

强权限：Planner 想新增节点、删除依赖、改变 join 或 retry 逻辑时，只能产生 GraphPatchProposal，由确定性验证器检查类型、无环约束 / 有界环、权限、预算、不变量与回滚点后再提交。

这使得“动态”不等于“无结构”。AFlow、GPTSwarm、EvoAgentX 等工作的共同方向正是让工作流拓扑可被搜索和优化，但生产 runtime 仍需要把候选结构编译为可验证的执行对象。^[R11]^[R12]

受约束概率控制模型：Graph 是约束集，LLM 是策略分布

可以把混合系统抽象成一个“受约束策略执行器”。设当前运行状态为 s，LLM Planner 给出动作分布 πθ(a | s)，图与策略层给出允许动作集合 A_G(s)。执行器不直接接受任意模型动作，而是先做 mask：

π̃θ(a | s) ∝ πθ(a | s) · 𝟙[a ∈ A_G(s)]

如果模型希望执行 A_G(s) 之外的动作，它必须提升为结构变更请求，而不是绕过 runtime。这样把“概率性”限制在策略层，把“合法性”留给机制层。

Fast loop

执行环

读取 State + Blackboard snapshot。
Graph 计算当前可行动作集合。
Planner 只在候选集中选择。
Worker 执行，产生事件与证据。
Reducer 原子提交新状态。

Slow loop

结构学习环

收集失败轨迹与成本。
生成 Graph Patch / prompt patch。
离线或沙箱评估。
通过 schema / invariant / policy checks。
灰度发布新 graph version。

推荐原则：不要让一次任务内的 Planner 同时拥有“业务推理权 + 控制流定义权 + 状态写入权”。至少拆掉其中一个；微内核里最好只保留 Planner 的“提案权”。

2026 年的研究也开始明确暴露“拓扑耦合”问题。MASPOB 指出，上游 Agent 的 prompt 改动会改变下游输入分布，因此多 Agent 优化不能把各角色当作独立组件；这从训练侧再次说明 graph topology 本身就是系统行为的一部分。^[R15]

面向信息源任务的微内核参考架构

如果你的目标是做一个“小而硬”的 Agent 微内核，建议内核只承载必须全局一致的能力；把模型、搜索器、解析器、RAG、写作器甚至 Supervisor 都做成插件。

Control

Supervisor / Planner Plugin任务分解、Worker 选择、查询策略、Graph Patch 提案

Workflow

Graph Compiler / Runtime节点、边、guard、join、retry、fallback、termination

↓ typed commands / events ↓

Microkernel

Scheduler + Event Bus优先级、队列、租约、取消、背压

Microkernel

State Reducer + Checkpoint单写路径、版本化、恢复

Microkernel

Capability / Policy工具权限、预算、并发配额、审计

↕ immutable event log / versioned snapshots ↕

Shared Plane

BlackboardClaims / Evidence / Artifacts / Provenance / Conflicts

Workers

Search · Fetch · Extract · Verify · Synthesize短生命周期、能力隔离、结果写回黑板

Ops

Trace · Metrics · Evalspan、成本、失败模式、graph version

内核应该保留什么

必须在 Kernel	原因	不建议放 Kernel
Event Bus / Scheduler	决定谁能在何时执行，属于全局机制	具体搜索策略
State Reducer / Versioning	避免多个 Agent 直接写核心 State	Prompt 模板
Capability Registry	工具可见性、权限、版本需要统一	具体模型 Provider 逻辑
Budget / Cancellation	必须能硬终止概率性循环	领域知识
Checkpoint / Recovery	长任务必须可恢复、可重放	业务 Agent 角色
Trace / Audit Hooks	跨 Agent 排障必须关联统一 run / task / span	报告排版

“微内核 + 插件”的方向在研究与开源系统中已有明确例子：Agent-Kernel 将 Agent、Environment、Action、Controller、System 等核心职责与场景插件解耦，强调运行时动态增删 Agent、验证和代码复用。^[R17] 这类设计思想很适合作为你的 runtime 边界参考，但信息源任务需要把“环境模拟”替换为“证据 / 来源 / 工具调用”的一致性模型。

关于“卡兹克开源系统”的对应关系

如果你指的是 KKKKhazix/khazix-skills，那么公开仓库本身更接近 Skill / capability layer：它由可被不同 Agent 运行时加载的结构化指令集组成，而不是一个承担调度、状态提交与 IPC 的 kernel。对微内核设计而言，它更适合作为“Worker 能力包格式”的参考，而不是内核本身。^[R18]

State / Blackboard：控制状态与知识状态必须分离

共享黑板最容易犯的错误，是把所有东西都塞进一个 JSON：控制流、聊天消息、搜索结果、最终事实、临时 scratchpad 混在一起。建议至少分成四个逻辑域：

RunState — 控制域

phase、当前 graph version、ready/running/blocked task、预算、deadline、termination flags。

EvidenceStore — 证据域

来源 URI、抓取时间、片段、内容 hash、可信度、claim 关联、引用状态。

ArtifactStore — 产物域

中间摘要、表格、代码、报告 section、可复用文档对象；按 content-addressed ID 保存。

PlannerMemory — 策略域

已尝试路线、失败原因、query coverage、未解决 gap；允许被丢弃 / 压缩，但不能充当事实源。

一个可落地的最小 schema

RunState {
  run_id, graph_version, state_version,
  goal, phase,
  tasks: Map<TaskId, TaskState>,
  budget: {tokens, tool_calls, wall_time, spawn_limit},
  open_gaps: [GapId],
  termination: {status, reason}
}

TaskState {
  task_id, parent_id, capability,
  status: READY | LEASED | RUNNING | BLOCKED | DONE | FAILED,
  deps: [TaskId], lease_owner, lease_expiry,
  input_refs: [ArtifactId], output_refs: [ArtifactId],
  attempts, max_attempts
}

Evidence {
  evidence_id, source_uri, retrieved_at,
  content_hash, excerpt, source_type,
  claim_ids: [ClaimId], confidence, freshness
}

Claim {
  claim_id, normalized_text,
  support: [EvidenceId], contradict: [EvidenceId],
  status: UNVERIFIED | SUPPORTED | CONTESTED | REJECTED
}

状态规则：Worker 不直接修改 RunState。Worker 只发事件或写 append-only artifact；只有 Reducer 能把事件折叠成新的 State version。这样共享黑板就不会退化成“所有 Agent 都能随手改的全局变量”。

信息源任务执行流：固定骨架 + 动态搜索槽位

对于调研、资讯、资料检索、竞品分析等任务，不建议把整个流程做成完全自治 ReAct。更好的结构是保留一个稳定骨架，把真正需要探索的部分做成策略槽位。

Research Run
Intake & Constraints — 确定性
Query Plan — 概率性 Planner
1 Source Discovery — 动态 fan-out
2 Fetch / Parse — 确定性工具执行
3 Evidence Normalize — 确定性 schema
Coverage / Contradiction Check — 混合
1 Gap exists → Planner 生成第二轮任务
2 No gap → 进入综合
Synthesis — 概率性生成
Citation / Claim Audit — 确定性 + verifier
Termination — Kernel 判定

为什么这种任务特别适合 Supervisor + 并行 Worker

Anthropic 的工程复盘给出了直接证据：研究任务天然开放，事先难以知道应该搜索多少步；其 lead agent 会先分析查询，再生成多个并行 subagent 覆盖不同方向，最后综合。^[R1] 但这里的关键并不是把所有步骤都交给 lead agent，而是让它只负责搜索空间的分配，将抓取、解析、去重、引用审计等工作收回确定性层。

任务展开示例

UserGoal
  ↓
Supervisor.propose([
  SearchTask("primary papers"),
  SearchTask("official framework docs"),
  SearchTask("production postmortems")
])
  ↓ Kernel validates budget + capability
Parallel Workers
  ↓ write Evidence + Artifact refs
CoverageReducer
  ├─ gaps > threshold → Supervisor.propose(next wave)
  └─ gaps <= threshold → SynthesisTask
  ↓
CitationAudit → TerminationGuard → Final

并发、一致性与恢复：Blackboard 模式真正难的地方

共享状态的优势是解耦和并发，但它会把“Agent 协作问题”转换成经典分布式系统问题。建议直接借用成熟机制，而不要用 Prompt 约定替代并发控制。

问题	推荐机制	设计要点
两个 Worker 抢同一任务	Lease + compare-and-swap	READY→LEASED 必须携带 state_version；租约超时可回收
重复工具调用	Idempotency key	hash(run, task, tool, normalized_args) 作为幂等键
写入覆盖	Append-only events + reducer	Worker 发事实事件，不直接 patch 全局 state
陈旧读	Snapshot version	Planner 输出必须标注基于哪个 state_version；提交时检测 drift
搜索结果重复	Content hash + canonical URI	来源级、页面级、片段级分别去重
证据冲突	Claim-Evidence bipartite relation	允许“冲突共存”，不要 last-write-wins
崩溃恢复	Checkpoint + event replay	恢复时重新计算 lease，避免幽灵 RUNNING
并行分支 join	显式 barrier / quorum	区分 ALL、ANY、N-of-M、deadline join

AutoGen v0.4 的 actor / event-driven 设计和 LlamaIndex Workflows 的 async event / fan-out-fan-in 都说明：当并发成为一等需求时，消息与状态生命周期必须从 Agent Prompt 中抽离出来，成为 runtime 能直接观察和控制的对象。^[R7]^[R19]

终止、重规划与防循环：不要把“我觉得完成了”当终止协议

多 Agent 系统最危险的循环通常不是代码里的 while True，而是语义循环：Supervisor 不断认为“还可以再查一点”，Worker 不断返回相似结果。MAST 把 verification / termination 单独列为主要失败类别之一。^[R2]

L0 · Hard Budget

token、tool call、wall time、spawn count 到上限必须结束或降级。

L1 · Graph Completion

所有 mandatory node 达到 terminal state，且无未满足依赖。

L2 · Evidence Sufficiency

核心 claim 达到最小支持数、关键来源类型覆盖、引用审计通过。

L3 · Marginal Utility

连续若干轮新增证据 / 新 claim / uncertainty reduction 低于阈值则停止探索。

重规划触发不要只看“失败”

更有效的触发信号包括：来源覆盖不足、相互矛盾的证据未解决、关键字段为空、工具连续错误、Worker 返回高度重复结果、当前路径的边际信息增益下降、剩余预算不足以完成原计划。Planner 的任务是提出 replan proposal，Kernel 决定是否批准。

if hard_budget_exhausted(state):
    return TERMINATE("budget")

if mandatory_nodes_done(state) and evidence_gate_passed(state):
    return TERMINATE("sufficient_evidence")

if marginal_gain(state.last_k_rounds) < epsilon:
    return TERMINATE("diminishing_returns")

if replan_signal(state):
    proposal = planner.propose_patch(snapshot=state.version)
    return validator.review(proposal)

实现路线：先做“能被证明正确的内核”，再加自治

如果你现在正在做微内核实验，我建议不要一开始就做“动态生成任意图”。先从一条可测、可回放的执行路径起步，然后逐层放开控制权。

Phase 0

单 Agent + typed tools

先建立统一 ToolResult、Error、ArtifactRef、Evidence schema；把模型调用外的行为都做成确定性函数。

Phase 1

Event-sourced microkernel

实现 task queue、lease、reducer、checkpoint、budget、trace。此时不用多 Agent，也能验证恢复与幂等。

Phase 2

Static graph + parallel workers

实现固定 research skeleton 与 fan-out/fan-in；Supervisor 只能生成任务参数，不能改拓扑。

Phase 3

Policy slots

在少量 decision node 允许 Planner 从枚举动作中选择，例如“再搜索 / 去验证 / 进入综合”。

Phase 4

Validated Graph Patch

允许 Planner 新增 bounded subgraph，但必须经 schema、budget、cycle、capability 与 termination validator。

Phase 5

Offline topology optimization

基于历史 traces 做 AFlow / GPTSwarm / AGP 式拓扑搜索，再通过离线 eval 与灰度发布，不让在线单次任务直接永久改 runtime。

第一组最值得做的消融实验

Variant	控制方式	你要回答的问题
A · Single ReAct	单 Agent 全自治	最低复杂度 baseline 到底能做到多少？
B · Static Graph	固定流程，无 Supervisor	确定性骨架带来的稳定性 / 成本收益？
C · Supervisor + Workers	中心动态分解	并行覆盖能否显著提升 recall？
D · Graph + Supervisor	图约束 + policy slots	能否保留 C 的覆盖，同时降低循环与失败？
E · Graph + Supervisor + Blackboard	完整 1/2/4 融合	状态持久化、并行和恢复是否值得复杂度？
F · E + Graph Patch	受控动态拓扑	动态结构是否真的增加成功率，还是只增加 token / graph churn？

评估指标：不要只看最终 Answer Score

混合架构的目标是“在相同预算下更可靠地探索”，因此至少需要覆盖结果质量、控制质量、状态质量和成本四个维度。

Outcome

任务质量

Task success / exactness
Evidence recall / precision
Claim citation coverage
Contradiction detection rate
Unsupported claim rate

Control

规划与图

Replan success rate
Invalid action rejection rate
Graph churn（单 run 拓扑变更数）
Loop / dead-end rate
Supervisor routing entropy

State

一致性与恢复

Duplicate task rate
Lease conflict / stale write rate
Checkpoint recovery success
Evidence dedup ratio
Orphan task count

Efficiency

成本与延迟

Tokens / successful run
Tool calls / successful run
Critical-path latency
Parallel efficiency
Marginal evidence gain / 1k tokens

尤其建议新增一个指标：marginal evidence gain / 1k tokens。对信息源任务，它比“Agent 数量”更能判断并行扩张是否值得，也更贴近 Anthropic 对 research agent 性能与 token 使用关系的观察。^[R1]

最终设计判断

如果把这套思路压缩成一句工程原则：用图维护“必须成立的世界”，用概率模型探索“可能更好的路径”，用黑板记录“已经发生并可被证明的事实”。 三者职责清楚以后，所谓融合并不会让系统更混乱，反而会把概率性集中到真正需要不确定性的地方。

英文研究来源与继续阅读

以下均为英文原始论文、官方文档或一手工程文章。正文中的判断分为两类：带 [R#] 的内容由对应来源支持；“受约束概率控制模型”“Graph Patch 审批”“四域 State 划分”等属于基于这些工作做出的工程综合与设计建议。

[R1] Anthropic Engineering — How we built our multi-agent research system
https://www.anthropic.com/engineering/multi-agent-research-system
[R2] Cemri et al. — Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025)
https://arxiv.org/abs/2503.13657
[R3] LangGraph Python Reference
https://reference.langchain.com/python/langgraph/overview
[R4] LangGraph Supervisor reference / archived repository note
https://reference.langchain.com/python/langgraph-supervisor
https://github.com/langchain-ai/langgraph-supervisor-py
[R5] OpenAI Agents SDK — Handoffs
https://openai.github.io/openai-agents-python/handoffs/
[R6] CrewAI Documentation — Agents / Crews / Flows concepts
https://docs.crewai.com/core-concepts/Agents
[R7] Microsoft Research — AutoGen v0.4: event-driven actor architecture
Microsoft Research article
[R8] AutoGen Documentation — GraphFlow (Workflows)
https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/graph-flow.html
[R9] LlamaIndex — High-Level Concepts / Workflows
https://developers.llamaindex.ai/python/framework/getting_started/concepts/
[R10] Zhuge et al. — GPTSwarm: Language Agents as Optimizable Graphs (ICML 2024)
https://proceedings.mlr.press/v235/zhuge24a.html
[R11] Zhang et al. — AFlow: Automating Agentic Workflow Generation (ICLR 2025)
ICLR 2025 paper page
[R12] Wang et al. — EvoAgentX: An Automated Framework for Evolving Agentic Workflows (EMNLP 2025 Demo)
https://aclanthology.org/2025.emnlp-demos.47/
[R13] Wu et al. — StateFlow: Enhancing LLM Task-Solving through State-Driven Workflows
https://arxiv.org/abs/2403.11322
[R14] Li et al. — Adaptive Graph Pruning for Multi-Agent Communication (published online 2026)
https://journals.sagepub.com/doi/10.3233/FAIA251326
[R15] Hong et al. — MASPOB: Bandit-Based Prompt Optimization for Multi-Agent Systems with Graph Neural Networks (ICML 2026)
https://proceedings.mlr.press/v306/hong26l.html
[R16] Guan et al. — Optimizing multi-agent workflows via heterogeneous graph learning (online 2026; journal issue 2027)
ScienceDirect article page
[R17] Mao et al. — Agent-Kernel: A MicroKernel Multi-Agent System Framework for Adaptive Social Simulation Powered by LLMs
https://arxiv.org/abs/2512.01610
[R18] KKKKhazix — Khazix Skills
https://github.com/KKKKhazix/khazix-skills
[R19] LlamaIndex Workflows — Concurrent execution of workflows
https://developers.llamaindex.ai/python/llamaagents/workflows/concurrent_execution/

结论先行：把“自主性”放进受约束的控制面

机制与不变量

策略与探索

证据与共享事实

六种基础架构：不要按“框架名称”，要按“控制权位置”理解

为什么 1 / 2 / 4 正在融合：三个层次解决的是不同问题

研究侧也在把 workflow 当作优化对象

核心矛盾：图结构与概率性模型为什么会发生规划冲突

关键洞察：把“选择路径”和“修改图”分成两种能力

受约束概率控制模型：Graph 是约束集，LLM 是策略分布

执行环

结构学习环

面向信息源任务的微内核参考架构

内核应该保留什么

State / Blackboard：控制状态与知识状态必须分离

RunState — 控制域

EvidenceStore — 证据域

ArtifactStore — 产物域

PlannerMemory — 策略域

一个可落地的最小 schema

信息源任务执行流：固定骨架 + 动态搜索槽位

为什么这种任务特别适合 Supervisor + 并行 Worker

任务展开示例

并发、一致性与恢复：Blackboard 模式真正难的地方

终止、重规划与防循环：不要把“我觉得完成了”当终止协议

推荐四级终止条件

L0 · Hard Budget

L1 · Graph Completion

L2 · Evidence Sufficiency

L3 · Marginal Utility

重规划触发不要只看“失败”

实现路线：先做“能被证明正确的内核”，再加自治

第一组最值得做的消融实验

评估指标：不要只看最终 Answer Score

任务质量

规划与图

一致性与恢复

成本与延迟

最终设计判断

英文研究来源与继续阅读