做过多 Agent 系统的同学多少都有过这种经历各模块单测都正常一放进系统里就互相踩脚——A 写完的数据被 B 覆盖C 等的中间状态永远没人产生D 和 E 同时读到一个旧数据然后给出相反结论。我最早做知识库问答机器人的时候意图识别、实体抽取、答案生成三个 Agent 协同工作简单用消息队列串接结果一遇到复杂问题就乱成一锅粥。后来把架构改成黑板模式Blackboard很多冲突问题从根上消失了。共享黑板模式不是新东西80 年代的人工智能领域就把它用在语音识别、专家系统里。它的核心思想特别朴素所有 Agent 不直接通信而是往一块公共“黑板”上写内容、读内容由统一的控制机制决定谁在什么时候写。就像几个侦探在白板上贴便签有人写“发现脚印”有人写“嫌疑人体型偏胖”有人补一条“脚印尺码与入口痕迹吻合”每个人都能看到别人写了什么但谁也不会抢黑板的同一块区域乱涂。今天我们要聊的就是这套模式怎么做落地怎么解决多 Agent 并发协作的冲突问题。1. 为什么多 Agent 协作这么难先聊聊黑板模式到底解决了什么问题1.1 多 Agent 协作的痛点通信、状态、控制三座大山先说通信。如果让 Agent 之间直接发消息最直观的做法是 P2P 通信A 告诉 BB 告诉 C。但只要 Agent 数量超过 3 个连线就会爆炸——4 个 Agent 要维护 6 条连接10 个 Agent 就是 45 条。而且每条消息都得约定协议、处理去向一旦某个 Agent 挂掉消息丢没丢都不知道。再说状态。多 Agent 协作的中间结果放哪一般有两种土办法放在某个全局变量里或者放在各自的内存里。放全局变量意味着并发写直接裸奔不加锁就乱套放各自内存意味着信息孤岛别人根本拿不到。我见过不少团队用数据库表当“全局变量”结果每条状态都要加事务、加版本号代码里到处是SELECT ... FOR UPDATE系统一上线全是死锁日志。最后是控制。谁该在什么时机做什么事如果全靠 Agent 自己判断很容易出现重复劳动三个 Agent 同时看到一条新数据全都去做英文翻译等于同一个任务跑了三遍。或者出现互相等待A 等着 B 的结果B 等着 C 的结果C 又等 A——典型的循环依赖。黑板模式把这三个问题一并处理了通信靠黑板解耦状态集中到黑板的槽位控制交给调度器。Agent 之间完全没有直接引用只是黑板的订阅者和发布者。这样一来新增一个 Agent 不需要改其他 Agent 的代码只要告诉它“黑板上有哪类数据你可以看、哪类数据你可以写”就行。1.2 黑板模式三件套黑板、知识源、控制机制黑板模式有三个核心组成部分理解它们就理解了整个架构。黑板Blackboard这是所有 Agent 共享的数据空间。它的结构不是一张简单的二维表更像一棵按领域划分的树。比如诊断高铁故障的系统黑板顶层是“问题描述”下面分成“机械故障”“电气故障”“环境因素”三个节点每个节点再往下挂“传感器异常”“噪音特征”等具体条目。每个节点都有自己的状态待处理、处理中、已完成、存在冲突。黑板不仅要存数据还要存“元信息”——谁写的、什么版本、置信度多少、时间戳是多少。知识源Knowledge SourceKS每个 Agent 就是一个知识源它只关心黑板上的某几类变化。比如一个负责“英文文献翻译”的 Agent只会在黑板上出现task类型且status new的数据时被触发。知识源不会主动去问“有没有我能做的事”而是由控制机制来叫它。有些黑板实现会把知识源写成一个类注册条件与动作看起来就像事件处理器。控制机制Control Mechanism这是黑板的“大脑”负责两件事一是监控黑板变化决定下一步触发哪个知识源二是处理执行顺序、优先级、并发布锁。它像一个会议室主持人不是自己解决问题而是知道谁擅长什么在合适的时间把合适的人叫起来干活。我常用一个生活化类比黑板是团队共享的 Excel 文档知识源是不同岗位的同事控制机制就是项目经理。同事不会直接在共享文档上乱改而是等项目经理分配任务改完后在文档里标注“评审中”另一个同事看到状态变化再去接手。项目经理根据当前文档内容决定下一步让谁动谁都不直接抢同一格输入。2. 黑板模式设计细节并发访问时冲突来自哪里2.1 三类冲突写写、读写、逻辑结论冲突把黑板设计成共享存储后第一感觉是“方便了”但多 Agent 并发执行时冲突会分三种形态出现处理不好照样翻车。写写冲突两个 Agent 同时打算往黑板的同一个节点里写入不同值。比如一个运维排障系统里日志分析 Agent 认为“磁盘故障概率 0.7”硬件监控 Agent 同时写入“磁盘故障概率 0.2”最后黑板上留哪个如果不做控制后写的覆盖先写的但谁后谁前完全不可控最终结果取决于操作系统线程调度的运气。这不是理论问题我在灰度测试时真的遇到过两个 Agent 写到同一个槽位导致最终答案一会儿是方案 A 一会儿是方案 B。读写冲突一个 Agent 正在读某个节点并基于它做长期计算另一个 Agent 这时候把节点内容改了。读操作可能读到半新半旧的数据。比如决策 Agent 先读了“温度 95 度”然后散热 Agent 把温度改成“75 度”决策 Agent 基于旧数据输出“紧急停机”。如果黑板读取是多字段快照还可能出现字段间不一致。逻辑结论冲突两个 Agent 分别得出互斥的结论但都写到了不同节点里。比如“服务可用性 Agent”认为系统可以继续压测“容量评估 Agent”认为系统即将雪崩。这不算严格的写冲突但最终决策人人或其他 Agent不知道该信哪个。这三种冲突是黑板设计时必须预判的。很多初学者把黑板理解成一个Map各个 Agent 往里put类似只加了并发锁的 HashMap。写写冲突用锁能挡住但读写冲突和逻辑冲突必须靠领域层面的状态机来治理。2.2 解决冲突的四个常用策略锁、隔离、版本、仲裁根据我从几个落地项目里总结的经验解决冲突的顺序应该是先想办法避免再想办法检测最后才处理已发生的冲突。常用策略有四个。策略一粗粒度锁 细粒度锁。全局大锁最简单一次只允许一个知识源操作黑板但这样 Agent 就退化成串行执行根本谈不上“并发”。一般我会用读写锁多个 Agent 可以并发读同一个节点但写之前必须拿到写锁。更细的做法是节点级锁、分支级锁。类似数据库的行锁与表锁锁粒度越小并发越高但死锁风险也越大。我建议先给每个叶子节点一把独立的condition锁在读改写操作时按固定顺序申请锁避免循环等待。策略二分区隔离。把黑板按领域拆成互相独立的区不同 Agent 通常只写属于自己的区。比如工单分类系统中意图识别 Agent 只写analysis/classification节点实体提取 Agent 只写analysis/entities节点。它们各自井水不犯河水根本不会写写冲突。这个策略要求我们在设计黑板节点时就和领域专家对好“谁负责什么”属于最便宜的并发策略。策略三版本号与乐观锁。每个黑板节点维护一个版本号或时间戳。Agent 读取时拿到(value, version)写入时提交(value, new_version, old_version)。控制机制比较old_version是否等于当前版本如果相等就更新并递增版本号不相等则拒绝写入让 Agent 重新读最新值后再计算。这个策略适合“读多写少且冲突不频繁”的场景我用 Redis 实现分布式黑板时特别顺手一条 WATCH 命令加上事务就能搞定。策略四仲裁与共识。应对逻辑结论冲突靠锁和版本解决不了。我可以做每个 Agent 写入时带上confidence置信度黑板节点允许同时存在多个候选值由仲裁 Agent 根据置信度和规则选最高者。还可以给不同 Agent 分配不同优先级在节点冲突时高优先级 Agent 的写入会覆盖低优先级同时保留“被覆盖”的历史记录方便追踪。实际项目中我不会只用一种。通常组合拳是分区隔离避免大部分写写冲突 乐观锁防止少部分越界写 优先级仲裁处理结论分歧。下文实战部分我会把这套组合放到一个可运行的例子里。3. 实战用 Python 实现一个支持并发协作的共享黑板3.1 场景设定工单分类与方案推荐系统4 个 Agent为了让代码有代入感我设计一个常见场景智能客服工单分类与解决方案推荐。系统收到一条用户报障工单例如“我的电脑开机蓝屏每次都在登录的时候卡死”黑板上需要产出用户意图报障、故障现象蓝屏、开机、登录卡死、可能的解决方案重置系统、查驱动、内存检测、最终回复文本。参与协作的 4 个 AgentAgent写入节点关注节点执行内容意图识别 Agentanalysis/intenttask/raw_text状态变化判断工单是报障、咨询还是投诉实体提取 Agentanalysis/entitiestask/raw_text状态变化提取设备类型、错误代码、关键动作方案匹配 Agentsolution/recommendationsanalysis/intent、analysis/entities都完成根据意图和实体匹配知识库方案回复生成 Agentresult/replysolution/recommendations完成把方案整理成可读的回复文本这里每个 Agent 关心的输入输出都很明确黑板节点用字典嵌套数据结构表示。我在本机用多线程模拟并发执行每个 Agent 跑在一个线程里。你会看到即使不采用真正的线程安全队列只要控制机制设计得好Agent 之间也不会互相覆盖。3.2 代码实现黑板核心类、知识源注册、调度循环我写了一个精简版黑板实现没有引入第三方框架只用了 Python 标准库。核心是Blackboard类维护数据字典、节点状态字典、版本号字典以及一把全局threading.RLock。为什么用 RLock因为同一线程内的知识源可能递归调用黑板写入操作可重入锁能避免自己锁死自己。import threading from dataclasses import dataclass, field from typing import Any, Callable, Dict, List dataclass class Node: value: Any None status: str init # init, ready, processing, done, conflict version: int 0 # 生产者agent标识便于追踪 producer: str class Blackboard: def __init__(self): self.nodes: Dict[str, Node] {} self.lock threading.RLock() self.listeners: List[Callable[[str], bool]] [] def read(self, path: str): with self.lock: node self.nodes.get(path) if node is None: return None, None, None return node.value, node.status, node.version def write(self, path: str, value: Any, producer: str, expect_version: int None): with self.lock: node self.nodes.setdefault(path, Node()) # 乐观锁调用方必须携带预期版本号防止覆盖他人修改 if expect_version is not None and node.version ! expect_version: raise VersionConflict(path, node.version, expect_version) node.value value node.version 1 node.producer producer # 写入即置为ready表示已有新结论产生 node.status ready return node.version def mark_processing(self, path: str): with self.lock: if path in self.nodes: self.nodes[path].status processing def mark_done(self, path: str): with self.lock: if path in self.nodes: self.nodes[path].status done知识源的定义我提成一个KnowledgeSource类每个实例包含nameAgent 名称、interested_paths它关注哪些节点、condition什么时候触发、execute执行动作。控制机制调度循环每次从就绪队列里挑一个满足条件的知识源来跑。dataclass class KnowledgeSource: name: str interested_paths: List[str] condition: Callable[[Blackboard], bool] execute: Callable[[Blackboard], None]调度循环的核心逻辑是每次遍历知识源列表找出condition(blackboard)为 True 且尚未执行过或还没执行完的知识源如果多个满足条件按优先级排序这里我省略优先级字段直接用注册顺序。然后逐个执行。def run_scheduler(bb: Blackboard, kss: List[KnowledgeSource], max_rounds: int 20): for _ in range(max_rounds): executed_any False for ks in kss: try: if ks.condition(bb): ks.execute(bb) executed_any True except VersionConflict: # 乐观锁冲突本轮跳过让其他知识源先写 print(f[scheduler] {ks.name} 版本冲突跳过重试) if not executed_any: break这个max_rounds是保险丝防止知识源条件永远满足导致死循环。实际系统里我会写成“达到稳定状态或超过最大轮数就退出”。下面定义四个 Agent 的condition和execute函数。意图识别 Agent 的触发条件是task/raw_text节点状态为ready且analysis/intent还没产生实体提取同理。方案匹配 Agent 的触发条件是analysis/intent和analysis/entities状态都为done方案节点还没产生。回复生成 Agent 触发条件是方案节点为done。def intent_condition(bb: Blackboard) - bool: raw_text bb.read(task/raw_text) intent bb.read(analysis/intent) if raw_text[1] ready and intent[1] ! ready: return True return False def intent_action(bb: Blackboard): text, _, _ bb.read(task/raw_text) if 蓝屏 in text or 卡死 in text: intent 报障 elif 怎么 in text: intent 咨询 else: intent 投诉 bb.write(analysis/intent, intent, producerintent_agent, expect_versionNone)注意这里我传入expect_versionNone表示“不强制版本一致”原因在于这个写动作只会发生一次且写入前已确认该节点不存在。真正的并发风险在后面。实体提取 Agent 更简单它从原始文本中提取设备、错误词。def entity_action(bb: Blackboard): text, _, _ bb.read(task/raw_text) entities {} keywords [蓝屏, 开机, 登录, 卡死, 蓝屏代码, 驱动] for kw in keywords: if kw in text: entities[kw] True bb.write(analysis/entities, entities, producerentity_agent, expect_versionNone)方案匹配 Agent 触发后先读取意图和实体再从内置知识库找对应方案。这里模拟多个方案。def solution_condition(bb: Blackboard) - bool: intent bb.read(analysis/intent) entities bb.read(analysis/entities) solution bb.read(solution/recommendations) if intent[1] ready and entities[1] ready and solution[1] ! ready: return True return False def solution_action(bb: Blackboard): intent bb.read(analysis/intent)[0] entities bb.read(analysis/entities)[0] if intent 报障 and entities.get(蓝屏): recommendations [检查近期的驱动或系统更新, 运行内存诊断工具, 进入安全模式禁用问题驱动] else: recommendations [建议重启设备, 查看知识库详情] bb.write(solution/recommendations, recommendations, producersolution_agent, expect_versionNone)最后回复生成 Agent 读取方案把列表变成一段话def reply_action(bb: Blackboard): recs bb.read(solution/recommendations)[0] reply 根据您描述的情况建议你依次尝试\n \n.join(f- {r} for r in recs) bb.write(result/reply, reply, producerreply_agent, expect_versionNone)初始化黑板写入原始工单然后跑调度器bb Blackboard() bb.write(task/raw_text, 我的电脑开机蓝屏每次都在登录的时候卡死, produceruser, expect_versionNone) kss [ KnowledgeSource(intent_agent, [task/raw_text], intent_condition, intent_action), KnowledgeSource(entity_agent, [task/raw_text], entity_action, entity_action), KnowledgeSource(solution_agent, [analysis/intent, analysis/entities], solution_condition, solution_action), KnowledgeSource(reply_agent, [solution/recommendations], reply_condition, reply_action), ] run_scheduler(bb, kss) print(bb.read(result/reply)[0])这里我没有真正开多线程而是用了调度循环逐步触发。它的好处是逻辑可控非常容易调试坏处是“并发度”不够同一时刻只有一个知识源在跑。如果想真正并发执行可以把多个知识源放到线程池里但这时候就必须依赖乐观锁和节点状态格挡。下面的例子我会带出更真实的并发写法。3.3 如何用乐观锁和区域隔离避免冲突我先把上述系统改成真正的多线程并发。思路很简单把调度器一次性启动所有满足条件的知识源让它们各自在线程里跑每个知识源执行前标记“正在处理”执行完标记完成。因为每个 Agent 写的是不同路径所以大部分情况下相安无事。真正需要担心的写写冲突发生在这种场景两个知识源恰好都要写analysis/entities。比如实体提取 Agent 和纠错 Agent 都从原文抽实体都想更新实体表。我在设计时把实体表从“最终实体集”改成“候选实体集”两个 Agent 分别各写一个子节点比如analysis/entities/intent和analysis/entities/correction再由“实体融合 Agent”合并成一个最终实体集。这就是区域隔离的实践。如果实在无法隔离就用乐观锁。write方法里的expect_version参数就是为此准备的。知识源先读目标节点的version做计算写的时候把读到的版本号带上来。如果写入时发现当前版本号已经变了说明其他 Agent 抢先改了就抛出VersionConflict。在上面的调度器里我捕获了它并跳过本轮下一轮调度会再次检查条件重新读取最新数据计算任务。实际线上我见过的所有并发冲突几乎都属于“本来可以隔离却硬要共享同一个格子”的设计失误。所以我的习惯是设计黑板节点时先画一张矩阵表横轴是 Agent纵轴是节点标注每个 Agent 对该节点是「只读」「只写」「读改写」凡是出现两个及以上的“读改写”格子就要重点标注用乐观锁或串行化保护。我在前文表里已经把每个 Agent 的读写节点列出来了你可以照着做。还有一个细节状态字段不要混入业务数据。很多同学把“这个节点处理完了吗”直接用一个值是否为空判断这会导致方案匹配 Agent 反复触发。我建议独立维护status类似工作流里的init/ready/processing/done。ready表示有新内容等待消费done表示已被消费完成processing表示正在被某 Agent 处理避免重复消费。4. 扩展把黑板搬到分布式环境Redis/ Lua / 分布式锁实操要点4.1 为什么单机黑板不够多进程/多容器部署单机上用 Python 多线程实现黑板适合学习和小规模调用。真实系统里会有多 Agent 跑在不同的 Python 进程里甚至部署成多个容器它们之间连内存都不共享。这时候单机的threading.RLock完全没用必须把黑板节点放到外部存储让所有进程都能访问。选型时有几个常见方向Redis Hash最常用天然支持HSET/HGET配合WATCH多路事务能做乐观锁。etcd / ZooKeeper强一致性更适合需要选主和元数据管理的场景但部署成本高性能也不如纯内存。SQL 数据库 行级锁适合熟悉关系型数据库的团队用SELECT ... FOR UPDATE实现写锁但会成为瓶颈。LiteDB / SQLite 文件共享只适合极小规模。我推荐先从 Redis 开始。原因有三个第一Redis 的 Hash 结构正好对应黑板的“节点路径 - 当前值”模型第二WATCH、MULTI、EXEC提供了数据库事务级别的乐观锁写代码成本低第三Redis 本身是单线程事件循环EVAL执行的 Lua 脚本是原子操作能保证复杂检查-写入流程不被并发打断。4.2 Redis 实现黑板的核心命令与 Lua 脚本示例把上面的 Python 黑板移植到 Redis节点路径可以直接作为 Hash 的 key。比如board:task/raw_text - {value: ..., status: ready, version: 3, producer: user}我用一张 Hash 存一个节点的所有属性。实际操作中我会按节点路径拆成多个 key比如board:task/raw_text、board:analysis/intent而不是把所有节点塞进一个超大 Hash。这样方便设置过期时间也避免单个 key 成为热点。Redis 乐观锁最简单的写法是用WATCHimport redis r redis.Redis.from_url(redis://localhost:6379/0) def redis_optimistic_write(path, producer, new_value, compute_func): while True: pipe r.pipeline() try: pipe.watch(path) data pipe.hgetall(path) version int(data.get(bversion, 0)) status data.get(bstatus, b) # 模拟读取旧数据进行计算 new_value compute_func(data) pipe.multi() pipe.hset(path, mapping{ value: new_value, version: version 1, producer: producer, status: ready, }) pipe.execute() return except redis.WatchError: continue这段代码在管道里先WATCH节点路径然后HGETALL读当前版本执行计算函数再开事务写入。如果有其他 Agent 在WATCH之后修改了这个 keyexecute时会抛WatchError我们重试读取最新数据直到成功。这就是“乐观锁 重试”比SETNX简单直接。如果涉及到多节点的一致性操作比如把“方案匹配中”改成“方案完成”同时把“回复节点”置为 ready单条 Redis 命令覆盖不来就得写 Lua 脚本。Redis 执行 Lua 脚本是原子的脚本外面没有其他命令能插进来。比如-- KEYS[1] 方案节点, KEYS[2] 回复节点 local v1 redis.call(HGET, KEYS[1], version) local cur_status redis.call(HGET, KEYS[1], status) if cur_status ~ done then redis.call(HSET, KEYS[1], status, done, version, v1 1) redis.call(HSET, KEYS[2], status, ready, value, reply_text) end return v1使用 Lua 要注意脚本内的所有 key 都通过KEYS传入不要把用户输入直接拼进脚本防止注入。还有 Redis 集群环境下Lua 脚本里涉及的多个 key 必须落在同一个槽位所以设计分布式黑板时要尽量让相关节点共享同一哈希标签比如board:{ticket123}:intent、board:{ticket123}:solution这样同一个工单的相关操作可以原子执行。4.3 分布式锁的注意事项死锁、超时、可重入如果你觉得乐观锁重试次数太多或者某些流程确实需要“先独占处理再释放”可以使用分布式锁。常见做法是SET lock_key lock_value NX PX 30000只有键不存在时才能设置成功同时设置 30 秒自动过期。锁名可以设计成节点路径加操作类型如lock:analysis/entities:merge。但我踩过的坑也不少先说三个最重要的第一锁超时不能设太短。一个 Agent 拿到锁后处理业务的平均耗时是 2 秒你把过期时间设成 1 秒另一 Agent 在 1.5 秒时拿锁成功前一个 Agent 才处理完准备释放锁一释放就把别人的锁删了。解决方式删除前校验value是否是自己写入的唯一标识比如 UUID。我习惯把锁的值设为agent_id random_token释放时用 Lua 脚本 “GET 比对 DEL” 保证原子性。第二锁必须可重入。同一个 Agent 可能在处理流程里递归调用黑板写入如果它不是同一个线程重入锁会死锁或重复申请。分布式锁通常没有重入能力我一般避免在一个锁内调用会申请同一把锁的代码如果实在需要重入就在本地维护一个计数器。第三优先使用事前隔离而不是事后锁。我再次强调锁是最后的兜底手段。用锁把“方案计算”和“意图修正”串行化虽然解决冲突但响应时间线性上升。我在高并发场景下宁可花更多时间设计节点分区也不愿意把所有热点都压在锁上。5. 排查与避坑我在实战中遇到的典型问题5.1 问题一Agent 反复处理同一条数据重复消费我在单机调度器里踩到过一个很隐蔽的坑solution_condition判断solution/recommendations节点不存在时触发但条件判断和实际写入之间隔了一次调度器循环另一个知识源可能已经把节点写好了第一个知识源没意识到继续执行结果覆盖了别人的结论。这个问题的本质是“检查-执行”不是原子的。解决办法条件判断里不只看“节点不存在”而是锁定目标状态。我把每个知识源的执行逻辑包成原子操作在执行开始时调用mark_processing(path)执行完再mark_done(path)。调度循环里使用if status ! done and not processing来防重入。如果写进 Redis就把状态检查放进 Lua 脚本保证原子性。另一个重复消费的典型场景是消息队列与黑板混用外部消息推入黑板多个 Agent 同时取走任务任务状态没更新前它们会重复消费。我后来统一用黑板自带的status字段管理生命周期不再依赖队列 ACK。5.2 问题二优先级高的 Agent 永远抢不到资源饥饿黑板模式里控制机制通常会优先触发“能产生关键中间结果”的知识源。但我在一个自研翻译系统中遇到一个术语校验 Agent 每次都在最后阶段触发由于它执行较慢系统总在等待它。这时来了一个“紧急摘要”任务但控制机制还是一直等术语校验完成才进入下一轮导致高优先级任务被低优先级任务阻塞了。饥饿问题的本质是调度策略太死板。我用两种方式缓解第一为知识源设置max_retry如果某知识源连续多轮被跳过说明它可能卡住调度器将其降级第二在调度循环里加入时间片每执行一个长任务后强制让出优先检查是否有高优先级任务就绪。简单说就是给调度器做一次“优先级的优先级”——先判断任务紧急度再判断知识源优先级而不是死板按注册顺序。5.3 问题三锁超时导致的脑裂和脏读分布式环境里最常见的故障就是锁超时导致两个 Agent 同时认为自己持有锁。之前我们提到锁删除前要校验唯一标识但如果 Agent 处理时间超过锁过期时间即使第二个 Agent 成功拿到锁第一个 Agent 也会在稍后释放锁时误删第二个 Agent 的锁。此时两个 Agent 可能都在执行同一步操作产生相同结果走重复逻辑还好产生不同结果就是脏读。解决办法只能从设计层面预防把锁过期时间设为“正常耗时上限的 5 倍”同时给处理流程增加“心跳续期”。如果 Redis 客户端支持看门狗线程就更好——每隔一段时间自动延长锁过期时间直到流程结束。但是续期也有风险Agent 假死后锁永远不释放最终还是要靠最大过期时间兜底。我实际项目中很少用分布式锁基本都靠乐观锁加 Lua 脚本因为乐观锁天然没有“锁释放”问题。5.4 常见问题速查表症状可能原因解决措施两个 Agent 写同一节点结果互相覆盖写写冲突分区隔离 乐观锁一个 Agent 读到旧状态接着执行读写不一致读取时携带版本号写入前比较版本同一 Agent 执行多次状态未及时更新增加 processing 状态 原子更新高优先级 Agent 长期不被调度调度策略死板引入紧急度时间片任务级优先级分布式锁被误删锁过期或释放无校验锁值带唯一 token删除用 Lua 校验两个 Agent 结论矛盾逻辑冲突增加置信度仲裁 Agent 决断调度循环永不退出条件一直满足设置 max_rounds 保险丝6. 什么时候该用黑板模式什么时候别用经验谈6.1 黑板模式适合什么场景经过几个项目实践我总结黑板模式特别适合“问题空间大、没有固定执行流程、多专家各自贡献局部知识”的场景。典型包括复杂故障诊断多个监控 Agent 各自从日志、指标、配置里发现异常把“可能的根因”写到黑板由一个推理 Agent 汇总。自然语言理解流水线分词、词性标注、命名实体识别、语义角色标注各部分互不依赖但都产生中间结果供最终理解使用。知识库问答与推荐多路召回结果放到黑板再由排序 Agent 综合打分召回源之间完全解耦。软件架构中的“编排者”模式当系统里有很多微服务需要协作完成一个请求黑板本身就像一个共享上下文每个微服务只负责修改上下文的一部分。这类问题的共同点是任务可以划分为相对独立的子任务子任务之间的交互是数据依赖而非调用依赖而且中间结果可以被多个角色复用。6.2 黑板模式不适合什么场景如果是纯粹的单线流水线比如“请求 A - 处理 B - 处理 C”黑板模式会把简单问题复杂化——不仅要定义节点还要设计调度器、状态机纯属画蛇添足。如果子任务之间有强顺序依赖黑板模式的“松耦合”反而是劣势因为调度器为了控制先后顺序要写很多额外条件。如果性能要求极高且单次请求延迟敏感黑板模式的多轮调度开销可能比直接调用更大需要谨慎评估。此外如果 Agent 数量少2~3 个且协作关系固定直接函数调用或者消息队列就够了。黑板模式的收益体现在“动态组合”上系统里 Agent 经常增减或者同一类问题存在多种处理路径这时黑板的解耦价值才体现出来。6.3 和 Actor 模式、管道模式对比选型我自己同时用过 Actor 模式和黑板模式这里给你一个选型参考对比维度黑板模式Actor 模式管道模式通信方式共享数据 调度控制异步消息传递数据流经固定管道数据共享显式集中无共享各Actor私有数据在阶段间流转适合场景多专家协作、结果可复用高并发、状态隔离线性流程、批处理冲突处理锁/版本/仲裁天然避免共享冲突阶段间无冲突控制复杂度需要调度器/仲裁需要消息路由简单直接失败恢复可从黑板重建中间状态消息可能丢失需重发管道中断需重试我自己的选型口诀是如果各 Agent 需要看到彼此的全部输入输出选黑板如果只需要向固定对象发消息且高度并发选 Actor如果任务有明确的阶段顺序选管道。回到文首的问题多 Agent 并发协作而不冲突关键在于不把“并发”想成“同时写同一个格子”而是想成“各自专注自己的领域在共享上下文里贡献结果”。黑板模式给了我们一套清晰规则把它用熟以后你会发现所谓冲突不过是没有划分好边界、没有版本记录、没有仲裁机制。我在实际项目中最受益的一点是当系统出现问题时直接盯着黑板节点状态很快就能定位到是哪个 Agent 写坏了数据、哪个 Agent 没有更新状态。这种可观测性是其他并发模型很难给的。最后分享一个小技巧不管用什么语言先把黑板节点的 JSON Schema 定义出来再写知识源。有了 Schema你才知道哪些节点可以从逻辑上合并、哪些必须拆分并发冲突也会减少很多。黑板模式不是银弹但它确实是我用过的多 Agent 协作里最接近“门清”的方案。