先记住这个答案
共享黑板让多个 Agent 读取和更新一份公共任务状态，适合共同事实、阶段进度和可复用产物的持续协调；消息传递把任务、事件或结果明确发给接收方，适合责任交接和异步解耦。前者需要处理版本、写入归属和冲突，后者需要处理投递、重复、顺序和确认。工程中常把可靠状态存储作为当前事实来源，用消息触发工作并携带任务标识与版本引用。不能因为消息已经发出就假定状态落地，也不能因为黑板里出现一行任务就假定有人负责执行。
- 黑板表达共享事实，消息表达交接或事件
- 共享写入与消息投递各有需要落实的可靠性规则
- 混合设计应明确哪一份数据是权威状态
共同阅读和明确交接解决不同问题
研究任务里，多个 Agent 都需要查阅已确认资料、未解决问题和最终报告版本，这些信息放入共享状态较容易形成一致视图。若每次都把完整资料广播给所有成员，消息体会越来越大，还可能出现不同成员拿着不同旧版本继续工作。
但只在黑板里写“需要检查引用”也不够，谁领取、何时开始、超时后谁接管仍然没有答案。显式任务消息可以携带接收者与期限，接收方确认后承担执行责任。黑板偏向当前事实，消息偏向发生了什么或请求谁行动。
两种方式都会遇到重复和过期信息
共享黑板中的旧读可能导致覆盖，因此需要版本检查或明确的单写者规则。消息也可能重复、延迟或乱序，接收方不能把每次投递都当作新的业务任务。稳定身份和输入版本在两种设计里都很有用，但发挥作用的边界不同。
例如完成消息晚于取消消息到达，系统应该根据任务当前状态判断是否接纳产物，而不是按最后收到的消息无条件改写状态。使用至少一次投递的队列时尤其要让重复处理可被识别；队列本身不替业务定义哪些结果可以重复应用。
混合设计需要解决状态与消息的一致发布
一种常见设计是在状态库保存任务与产物，消息只传递任务标识、预期版本和事件类型。接收方收到后读取权威记录，验证当前仍需执行。这样消息保持简洁，原始证据也不必在每次交接时复制。
但写状态成功、发消息失败会产生无人处理的任务，先发消息后写状态也可能让消费者读取不到记录。可采用事务发件箱等机制把待发送事件和状态在同一事务中记录，再由发布器投递；消费者仍需幂等，不能把这一设计说成自动获得端到端恰好一次。
容易答错的地方
- 共享黑板意味着所有 Agent 随时修改任何字段
- 这会放大冲突并让责任模糊，应划分字段或产物归属，给最终状态设置明确提交规则，并保留提交者与输入版本以便追查覆盖原因。
- 用了消息队列就不用持久化任务状态
- 消息能够传递工作，但恢复、查询和验收仍可能需要稳定状态；是否持久化应由故障恢复要求决定，不能只看通信方式。
面试官还会怎么问？
小规模进程内 Agent 是否需要上消息中间件？
未必，函数调用或内存队列可能已经足够。只有跨进程隔离、独立扩缩容、可靠投递等需求出现时，才需要承担更复杂的基础设施成本。
消息应该放完整产物还是引用？
小而稳定的结果可直接携带，大产物更适合版本化引用；引用必须对接收方可访问且能校验，不能只给发送方机器上的临时路径。
事件日志能直接当共享黑板吗？
可以从日志构建当前视图，但需要明确事件顺序、去重与投影更新规则；读者通常使用投影状态，而不是每次重新解释全部历史消息。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。