企业官网建设流程全解析

多 Agent 协作的另一种形态，黑板模式的适用场景与四个坑

多 Agent 协作那篇讲的是中心调度的形态，每个 Agent 领一块职责，调度器按顺序派活。还有一类协作思路在论文和框架里反复出现，叫黑板模式（Blackboard），模块之间不直接互相调用，而是围绕一份共享状态干活，谁有能推进的地方谁就上。

三块积木

黑板模式的组成不复杂。第一块是黑板，保存任务目标、已收集的证据、中间结论和悬而未决的问题。第二块是知识源，每个模块擅长一类工作，读黑板，判断自己当前能不能推进，能就干活，把新结果写回去。知识源不一定是大模型，检索引擎、规则脚本、甚至一个需要人工确认的节点都能算。第三块是控制器，决定下一步让谁动、能不能并行、什么时候收工。

有个细节容易被忽略，黑板最好是有结构的数据，而不是一段越写越长的自然语言。所有东西揉进文本，信息互相覆盖，后面的模块没法判断哪条结论还可信。

和固定工作流差在哪

固定工作流是条流水线，读任务、分析原因、改代码、跑测试、出结果，顺序写死。流程稳定的业务用它更省心，但也带来一个问题，中间结果如果推翻前面的判断，就得回退或者写一堆分支。

黑板模式的调用链不固定，流程体现在调度策略里。日志分析发现数据库超时，控制器看到这条线索，决定下一步去查连接池配置还是查网络，随后再把新证据写回黑板。下一步做什么，由当前状态决定。

什么时候值得用

模块没几个、流程又稳定的任务，直接写死链条更简单可靠。黑板模式的价值场景是，三五个异构模块围绕同一个问题反复贡献信息，而下一步动作依赖中间结果。排障、情报汇总、需要多轮验证的复杂分析，都在这个范围里。

四个坑

并发写是第一个。两个模块同时读到旧状态，各自算完再提交，后写的可能覆盖先写的。字段级更新、版本号校验、或者把更新做成追加事件，都能解，选哪种看并发规模。

状态膨胀是第二个。历史全留着，黑板越来越长，模型读到一堆无关内容，既费钱又干扰判断。任务状态、证据索引、明细日志分开放，模块默认只读当前任务需要的，要看细节按引用去查。

结论冲突是第三个。两个模块给出矛盾判断，比如一个说是数据库配置问题，另一个说是网络故障。黑板要保留每条结论的来源和依据，由控制器或验证模块仲裁。涉及高风险操作，不能只听某一家的一面之词。

调度打转是第四个。A 写回触发 B，B 写回又触发 A，任务原地踏步还烧钱。触发条件、迭代预算、重复结果检测、明确的终止条件，这几样一个都不能省，调度策略本身就是黑板模式的核心设计，别留到最后才补。

小步验证的路子

不必上来就搭平台。内存里一个结构化对象当黑板，两个模块当知识源，一个大循环当控制器，日志记下每次调度的原因和状态变化。先让两个模块并发写同一个字段，看会不会互相覆盖。再让它们给出矛盾结论，测仲裁逻辑。最后故意让它们互相触发，测能不能停下。每个坑都有对应的复现实验，踩过一遍再上生产，心里才有底。

结合系列

多 Agent 协作篇的重心是职责怎么分，黑板模式把调度依据换成了当前状态能推进什么。执行循环篇的终止条件和重试上限，在这里变成调度器的迭代预算。工具设计篇的纪律照样适用，模块往黑板上写的东西得是结构化证据，一段自由发挥的文字会污染共享状态。