10 个关键问题 Q&A
-
Q：多 Agent 用共享内存，两个 Agent 同时修改同一字段谁算数？ A：底层靠 CAS / 版本乐观锁防止脏写；业务不能直接取后写入的值，要做冲突仲裁。 -
Q：共享状态和 Agent 上下文有什么区别？ A：共享状态是结构化数据；上下文是模型推理时看到的 prompt 信息，需要按需裁剪。 -
Q：共享黑板模式优缺点？ A：简单异步；缺点是缺乏规范容易混乱，Agent 耦合强，适合小规模固定任务。 -
Q：消息总线模式适用场景？ A：Agent 数量多、协作关系复杂，需要解耦，按需订阅事件。 -
Q：集中编排者模式核心价值？ A：统一管控上下文，按需裁剪，方便调试、增加约束，LangGraph/CrewAI 常用。 -
Q：结构化交接是什么？ A：任务转交时传递标准化摘要，包含目标、事实、不确定项、下一步，只传最小信息。 -
Q：RAG 式共享记忆库的短板？ A：协作质量高度依赖检索精度，检索错误会让 Agent 读取过时、错误信息。 -
Q：冲突仲裁哪种方案生产更推荐？ A：核心场景用编排 Agent 仲裁；普通场景用置信度加权；优先追加日志而非原地覆盖。 -
Q：多 Agent 上下文共享最容易踩什么坑？ A：全量信息广播，token 爆炸、噪声大；不处理过期状态；冲突规则缺失，无法排查。 -
Q：多 Agent 系统落地优先选哪种模式起步？ A：优先结构化交接，跑通最小信息流转，再演进到黑板 / 消息总线等方案。
附录：多 Agent 共享内存，两个 Agent 同时修改同一个字段，谁的算数？
面试官核心考察点：不是让你说锁，而是区分「数据状态并发」vs「Agent 上下文认知冲突」两层问题；很多候选人只答数据库锁，会丢分。
先拆解面试官这个追问的两层含义
第一层：底层存储并发（工程层：共享内存 / Redis / 黑板）
多个 Agent 进程 / 协程同时写同一个共享字段，存储层面的竞态条件
-
裸写共享内存：无保护，结果是未定义，最后写入的直接覆盖前面的值（写覆盖），会丢更新。 -
解决方案： -
乐观锁：版本号 version。每次写带上版本号，版本匹配才允许更新；版本不匹配，直接拒绝本次写入，Agent 重试。 -
悲观锁：写前加锁，同一时刻只有一个 Agent 修改。 -
CAS（Compare And Swap）：无锁原子操作，适合内存 / Redis，先比较当前值，相等才替换。
但是！只讲到锁，回答是不完整的。这只是解决存储数据冲突，没有解决 Agent 业务层面的冲突。
第二层：业务语义冲突（多 Agent 核心难点，面试官真正想听的）
两个 Agent 不是简单改一个数字，而是基于各自的上下文推理，得出了对同一个事实的不同结论。 比如：Agent A 调研客户预算是 100w；Agent B 调研得到客户预算是 200w。两者同时写黑板里customer_budget字段。 就算你用 CAS 保证只有一个写入成功，被覆盖掉的那个结论，它背后的推理依据直接丢了。 这才是多 Agent 和普通多线程最大区别：普通多线程操作的是纯数据；Agent 写的是带有推理、证据、置信度的认知结论。
✅ 所以答案一句话： 存储层用并发原语（CAS / 版本锁）防止数据脏写；业务层不能简单 “谁先写 / 谁后写算数”，必须引入冲突仲裁策略，而不是粗暴覆盖。
冲突仲裁有几种工程可用策略（面试可以直接讲）
- 时序仲裁（最简单，不推荐复杂业务）
带时间戳，最新时间戳的结论生效。缺点：真理不一定是后得出的，晚写的 Agent 可能拿到更差的信息，直接覆盖正确结论。 - 置信度 / 权重仲裁（生产常用）
每条写入黑板的记录，除字段值外，附带：来源 Agent、置信分数、证据片段。冲突时，置信度高的结论生效，低置信保留归档，不直接丢弃。
例子：数据采集 Agent 置信度高，创意推演 Agent 置信度低，冲突采信采集 Agent。
- 编排者仲裁（Orchestrator 集中裁决）
子 Agent 不允许直接覆盖核心状态。发生冲突时，停止自动覆盖，把两个矛盾结论 + 各自证据，提交给调度 / 编排 Agent 做判断，由编排者决定采信哪一个，或者发起新一轮信息核验。CrewAI Manager、LangGraph 主控节点常用这个思路。 - 不覆盖，追加记录（黑板最佳实践）
黑板不采用原地覆盖。同一个 key 不存单一值，而是存一条变更日志。每次更新新增一条记录，带上版本、来源、证据。 Agent 读取时，不是读最新单条，而是根据规则聚合、筛选视图。
好处：不会丢失任何推理过程，可回放、可审计；缺点是读取逻辑变复杂，需要视图层做聚合。
回到你最初的回答：“用共享内存做上下文共享”，面试官为什么停顿？
面试官停顿，是因为他预判了你大概率混淆两件事：
- 共享状态（共享内存 / 黑板：结构化数据、变量）
- Agent 上下文（对话历史、推理链路、模型看到的 prompt）
共享内存适合存放结构化状态，不适合直接作为 Agent 的完整上下文。 直接把共享内存全量喂给每个 Agent：token 爆炸、噪声巨大；Agent 看到相同状态，但模型各自有独立推理窗口，依然会产生认知偏差。 共享内存解决的是状态持久化与可见性，解决不了上下文裁剪、认知冲突、信息失真。
面试标准回答版本（可以直接背）
如果两个 Agent 同时修改共享内存里同一个字段，要分两层处理。
第一是底层并发竞态问题：裸共享内存会出现写覆盖，我们不会直接原地写。会引入版本号做乐观锁或者 CAS 原子更新，保证同一时刻只有一个写操作落地，避免脏写。但这只是解决存储层面的问题。
第二是业务语义冲突，这才是多 Agent 的核心。两个 Agent 写入不同结论，本质是基于各自上下文得到矛盾认知，不能简单以最后写入的为准。 我们的方案是黑板不原地覆盖，每次写入携带版本、来源 Agent、置信度和证据，追加变更记录。读取时构建视图。发生冲突时，有几种策略：简单场景用置信度仲裁；关键业务交给编排 Agent，把双方证据汇总，让编排层做裁决，甚至触发重新核验。
另外补充一点：共享内存更多用来存结构化状态，而不是完整上下文。每个 Agent 的 prompt 上下文，是编排层按需从共享状态、历史变更里裁剪组装出来的，不会把全量共享内存塞给 Agent，控制 token 和噪声。
加分追问延伸（面试官继续深挖时可以讲）
-
那过期状态怎么处理？
加 TTL、版本、时间戳，Agent 读取时校验新鲜度；如果状态已过期，Agent 不能直接使用，需要主动刷新。
-
共享黑板模式的短板是什么？
Agent 数量一多，schema 难维护，容易产生大量无效状态；Agent 容易过度依赖黑板，产生紧耦合；冲突规则散落在各个 Agent，不好治理，所以复杂系统会往编排者或者结构化交接演进。
-
和消息总线模式对比，什么时候放弃共享黑板？
任务依赖复杂、Agent 数量多、需要强解耦，就用事件总线；任务流程固定、Agent 少，黑板更轻量。
极简一句话总结（面试收尾）
多 Agent 上下文共享模式底层靠 CAS / 版本锁防止脏写；业务上不粗暴覆盖，保留证据，通过置信度或者编排 Agent 仲裁，并且区分「共享结构化状态」和「Agent 推理上下文」，二者不能等同。