Quartz 4

🔍 搜索

DACS：动态注意力上下文域限（分布式 Agent 上下文扩展）

7 min read

DACS：动态注意力上下文域限（分布式 Agent 上下文扩展）

原文：DACS: Dynamic Attentional Context Scoping
发表：arXiv 2604.07911
翻译整理：2026-06-16

核心问题：上下文污染

在多 Agent 编排系统中，当 N 个并发 Agent 共享编排器的上下文窗口时，会发生上下文污染（Context Pollution）：

编排器上下文窗口
┌─────────────────────────────────┐
│ Agent A 的任务状态 ████████      │
│ Agent B 的部分输出 ████          │
│ Agent C 的待处理问题 ██          │
│ Agent A 的部分输出 ██████        │  ← 所有 Agent 的信息混在一起
│ Agent B 的任务状态 ████████      │
│ Agent C 的中间结果 ██████████    │
└─────────────────────────────────┘

问题后果：当编排器需要对 Agent A 做出决策时，Agent B 和 Agent C 的信息也在上下文中，干扰编排器的注意力分配，导致决策质量下降。

量化证据：污染有多严重

论文通过 200 次实验（4 个阶段，统计显著性 p < 0.0001）量化了污染影响：

平坦上下文（基线）vs DACS 准确率对比

Agent 数量 N平坦上下文准确率DACS 准确率提升幅度
N = 360.0%~77.2%+17.2 pp
N = 5未详述未详述+20.4 pp
N = 1021.0%~90.0%++69 pp

关键数字：N=10 时，不做上下文管理的编排器准确率跌至 21%，几乎等于随机决策。

错误 Agent 污染率

系统错误 Agent 污染率
平坦上下文（基线）28% - 57%
DACS0% - 14%

「错误 Agent 污染」指的是：编排器在处理 Agent A 时，受到 Agent B/C 信息的干扰，做出与 Agent A 无关或错误的决策。

DACS 解决方案：双模式架构

DACS 引入两种工作模式，根据当前需求动态切换：

模式 1：注册表模式（Registry Mode）

编排器上下文窗口
┌─────────────────────────────────┐
│ Agent A: [摘要，≤200 token]      │
│ Agent B: [摘要，≤200 token]      │
│ Agent C: [摘要，≤200 token]      │
└─────────────────────────────────┘
           总计：≤600 token

用途：编排器的日常状态维护。每个 Agent 只保留极简摘要（≤200 token），让编排器知道所有 Agent 的状态全貌，但不被细节淹没。

模式 2：聚焦模式（Focus Mode）

编排器上下文窗口（处理 Agent A 的请求时）
┌─────────────────────────────────┐
│ Agent A: [完整上下文 F(A)]       │  ← Agent A 的完整信息
│                                  │
│ Agent B: [摘要，≤200 token]      │  ← 其他 Agent 只有摘要
│ Agent C: [摘要，≤200 token]      │
└─────────────────────────────────┘

用途：当 Agent A 向编排器发出请求时，聚焦模式激活。此时 Agent A 的完整上下文进入编排器，而其他 Agent 仍保持摘要形式，上下文隔离得以实现。

核心公式：

聚焦处理 Agent i 时，上下文 = F(Agent_i) + R_{除 i 外所有 Agent 的摘要}

关键特性

1. Agent 触发，而非编排器触发

模式切换由子 Agent 主动发起请求触发，而非编排器轮询：

Agent A 完成子任务，需要编排器决策
  ↓
Agent A 发出「请求聚焦」信号
  ↓
编排器切换到聚焦模式，加载 Agent A 完整上下文
  ↓
编排器做出决策，返回给 Agent A
  ↓
编排器切换回注册表模式

优势：编排器不需要主动管理哪个 Agent「值得关注」，由 Agent 自己按需请求。

2. 不对称隔离

聚焦模式只对当前请求的 Agent 展开完整上下文，对其他 Agent 保持摘要。这是「不对称」的——不同 Agent 在同一时刻的上下文呈现深度不同。

3. 确定性操作

DACS 的隔离机制是确定性的（Deterministic），不依赖压缩算法或向量检索——只是简单地按模式切换上下文内容。这使其行为可预测、可调试。

与子 Agent 摘要压缩的关系

DACS 与 Anthropic 上下文工程文章中「子 Agent 返回 1,000-2,000 token 摘要」的建议互补而不冲突：

机制作用层级解决的问题
子 Agent 摘要压缩（Anthropic）子 Agent → 编排器的输出减少子 Agent 输出对编排器上下文的占用
DACS（本文）编排器内部的上下文管理防止多 Agent 并发时的上下文相互污染

两者结合：子 Agent 返回压缩摘要 + 编排器用 DACS 隔离不同 Agent 的上下文 = 多 Agent 系统的完整上下文管理方案。

实践建议

什么时候需要 DACS（或类似机制）

  • 编排器同时管理 3 个以上并发 Agent
  • Agent 之间的任务相对独立（不需要实时共享详细信息）
  • 系统准确率随 Agent 数量增加而明显下降

简化实现

即使不实现完整的 DACS，也可以用以下简化方案获得类似效果：

def build_orchestrator_context(agents, focus_agent_id):
    context = []
    for agent in agents:
        if agent.id == focus_agent_id:
            # 聚焦 Agent：加载完整上下文
            context.append(agent.full_context)
        else:
            # 其他 Agent：只加载摘要（≤200 token）
            context.append(agent.summary)  
    return context

核心思想：在需要时才展开完整信息，平时只维护摘要。

核心记忆点

多 Agent 系统的上下文管理不是「把所有 Agent 的信息都塞进来」， 而是「在需要关注哪个 Agent 时，只展开那个 Agent 的上下文」。

N=10 时平坦上下文准确率跌到 21% 这个数字，是设计多 Agent 系统时应该铭记的警示线。

Graph View