本章导读

核心问题：Multi-Agent 系统中哪些上下文应该共享，哪些必须隔离。

关键词：Global Context、Role Context、Private Scratchpad、Shared Workspace、Artifact Store

学习产出：定义 CI 分析中 finding、evidence、confidence 的共享协议。

1. 本章要解决什么问题

上一章讨论了 Multi-Agent 的整体架构。

这一章聚焦一个更具体、更容易出错的问题：

多个 Agent 之间如何共享上下文？

很多 Multi-Agent 系统的第一版实现很粗糙：

把所有 Agent 的对话历史拼到一起
让主 Agent 读取全部内容
最后生成总结

这种方式很快会失败。

原因是：

上下文爆炸；
子 Agent 的错误假设污染主 Agent；
细节太多，主 Agent 抓不住重点；
多个 Agent 的结论互相冲突；
权限边界被打破；
无法追踪哪个结论来自哪里。

Multi-Agent Context Sharing 的目标不是“共享所有内容”，而是：

在多个 Agent 之间共享经过结构化、压缩、验证和授权的信息。

本章核心观点是：

Multi-Agent 系统中，共享的不是完整上下文，而是任务状态、证据、摘要、产物和可追溯结论。

2. Multi-Agent 中上下文的层次

可以把多 Agent 上下文分为五层。

2.1 Global Context

全局上下文对所有 Agent 可见。

例如：

用户目标；
安全规则；
输出要求；
总预算；
任务截止条件。

Global Context 应尽量短。

2.2 Role Context

角色上下文只对特定角色可见。

例如：

SecurityAgent 的安全检查清单；
TestAgent 的测试覆盖规则；
PerformanceAgent 的性能风险标准；
Synthesizer 的汇总格式。

Role Context 可以来自 Skill。

2.3 Private Context

每个 Agent 的私有上下文。

包括：

局部搜索过程；
临时假设；
未验证线索；
草稿推理；
角色内部计划。

Private Context 默认不共享。

2.4 Shared Workspace

共享工作区保存结构化产物。

例如：

子任务计划；
已验证事实；
证据引用；
子 Agent 结论；
冲突列表；
最终报告草稿。

Shared Workspace 不是聊天记录，而是协作产物库。

2.5 Artifact Store

Artifact 是可引用产物：

报告；
代码补丁；
图表；
日志摘要；
检索结果文件；
测试结果。

大型产物不应直接进入上下文，而应通过引用访问。

3. 共享什么，不共享什么

3.1 应该共享

适合共享：

用户目标
任务拆分
角色职责
已验证事实
证据引用
阶段性结论
最终产物
冲突和不确定性
下一步请求

3.2 不应该共享

不适合共享：

完整对话历史
未验证假设
模型内部草稿
大段原始日志
无关搜索结果
其他用户或项目数据
敏感内容
低置信度推断

3.3 有条件共享

需要处理后共享：

高敏感数据：脱敏后共享；
长日志：压缩后共享；
代码片段：只共享相关片段；
冲突观点：带来源和置信度共享；
私有探索：提炼为 finding 后共享。

4. AgentMessage 协议

Agent 之间不应通过自由文本随意传递信息。

建议定义消息协议。

消息类型：

TASK_ASSIGNMENT
QUESTION
FINDING
EVIDENCE
ARTIFACT
REVIEW
CONFLICT
REQUEST_MORE_INFO
FINAL_RESULT

每条消息应包含：

sender；
receiver；
type；
content；
references；
confidence；
scope；
createdAt。

5. Result Aggregation

Synthesizer 或 Coordinator 汇总结果时，需要处理：

5.1 去重

多个 Agent 可能发现同一事实。

重复发现可以提高置信度，但不应重复输出。

5.2 冲突

例如：

Agent A：推荐采用框架 X。
Agent B：不推荐，因为安全风险高。

不能简单平均。

应输出：

冲突点
双方证据
置信度
需要进一步验证的问题
最终权衡

5.3 证据追踪

最终结论必须能追溯到来源。

例如：

结论：迁移成本较高。
证据：Researcher C 分析了 5 个模块，发现 3 个模块依赖同步执行模型。
引用：artifact://research/java-integration.md

5.4 置信度

每个 finding 应有置信度。

置信度可以来自：

来源权威性；
多 Agent 一致性；
工具验证结果；
是否有原始证据；
是否经过 Reviewer 质疑。

6. 架构图 / 流程图

图 19-1 Multi-Agent Context Sharing 这张图展示 Global Context、Role Context、Private Scratchpad、Shared Workspace 与 Artifact Store 的关系。 Mermaid 源文件

图 19-2 Context Sharing 分层 Mermaid 源文件

6.2 AgentMessage 流转

图 19-3 AgentMessage 流转 Mermaid 源文件

6.3 冲突处理

图 19-4 冲突处理 Mermaid 源文件

7. Java / Spring Boot 落地方案

7.1 AgentMessage

public record AgentMessage(
    String messageId,
    String taskId,
    String senderAgentId,
    String receiverAgentId,
    AgentMessageType type,
    String content,
    List<String> references,
    double confidence,
    ContextScope scope,
    Instant createdAt
) {}

7.2 AgentMessageType

public enum AgentMessageType {
    TASK_ASSIGNMENT,
    QUESTION,
    FINDING,
    EVIDENCE,
    ARTIFACT,
    REVIEW,
    CONFLICT,
    REQUEST_MORE_INFO,
    FINAL_RESULT
}

7.3 SharedWorkspace

public record SharedWorkspace(
    String workspaceId,
    String taskId,
    List<AgentMessage> messages,
    List<Finding> findings,
    List<ArtifactRef> artifacts,
    List<ConflictRecord> conflicts
) {}

7.4 Finding

public record Finding(
    String id,
    String agentId,
    String statement,
    List<String> evidenceRefs,
    double confidence,
    FindingStatus status
) {}

状态：

public enum FindingStatus {
    PROPOSED,
    VERIFIED,
    DISPUTED,
    REJECTED,
    ACCEPTED
}

7.5 ResultAggregator

public interface ResultAggregator {
    AggregatedResult aggregate(SharedWorkspace workspace, AggregationPolicy policy);
}

7.6 ContextSharingPolicy

public interface ContextSharingPolicy {
    boolean canPublish(AgentIdentity agent, ContextChunk chunk, SharedWorkspace workspace);
    ContextChunk transformForSharing(ContextChunk chunk);
}

8. 企业案例：多 Agent PR Review

输入：Pull Request Diff。

共享上下文：

PR 标题
PR 描述
Diff 摘要
项目规则
输出格式

私有上下文：

SecurityAgent 的安全检查过程；
TestAgent 的测试覆盖分析；
PerformanceAgent 的性能假设；
ArchitectureAgent 的设计评估草稿。

共享产物：

{
  "finding": "The new endpoint lacks authorization check.",
  "evidence": ["UserController.java:88"],
  "confidence": 0.92,
  "agent": "SecurityAgent"
}

最终汇总：

Blocker:
- 缺少权限校验。证据：UserController.java:88。来源：SecurityAgent。

Suggestion:
- 新增 service 层测试覆盖未登录场景。来源：TestAgent。

9. 常见误区

9.1 共享完整上下文

这会导致上下文爆炸和污染。

9.2 没有消息类型

自由文本通信难以聚合和审计。

9.3 结论没有证据

没有 evidence 的 finding 不应进入最终答案。

9.4 冲突不处理

多个 Agent 结论冲突时，应标记不确定性或请求 Reviewer。

9.5 私有上下文泄露

Private Scratchpad 默认不共享。

10. 贯穿案例：CI 失败分析 Agent

在 Multi-Agent CI 分析中，共享上下文必须结构化。

不应该把 LogAnalysisAgent、CodeAnalysisAgent 和 TestAnalysisAgent 的完整对话都交给 Coordinator。

应该共享 finding：

{
  "agent": "LogAnalysisAgent",
  "finding": "The failed test is OrderServiceTest.shouldApprovePendingReviewOrder.",
  "evidence": ["ci://build/4312/log#L882-L940"],
  "confidence": 0.95
}

{
  "agent": "CodeAnalysisAgent",
  "finding": "OrderStatus added PENDING_REVIEW but OrderStateMachine.allowedTransitions was not updated.",
  "evidence": ["git://repo/order-service/pr/882/diff", "OrderStateMachine.java:88"],
  "confidence": 0.9
}

Coordinator 只需要读取这些结构化结果、证据引用和置信度。

这能避免上下文爆炸，同时保证最终报告可追溯。

11. 本章小结

本章讨论 Multi-Agent Context Sharing。

核心结论：

多 Agent 系统不应共享完整上下文，而应共享结构化产物。
上下文应分为 Global、Role、Private、Shared Workspace 和 Artifact Store。
Agent 之间应通过类型化消息通信。
共享结果必须包含证据、置信度和来源。
Result Aggregator 需要处理去重、冲突和不确定性。

一句话总结：

Multi-Agent 协作的关键，不是让所有 Agent 知道一切，而是让每个 Agent 只共享经过整理、可验证、可追踪的成果。

12. 实践任务

任务 1：设计 AgentMessage

实现 AgentMessage、AgentMessageType 和 SharedWorkspace。

任务 2：设计 PR Review 共享协议

定义 SecurityAgent、TestAgent、PerformanceAgent 的输出格式。

任务 3：冲突处理

模拟两个 Agent 对同一技术方案给出相反建议，设计 Aggregator 输出。

任务 4：Artifact 引用

设计 ArtifactStore，让 Agent 共享大文件引用而不是把全文放进上下文。