AI Agent 注意力队列设计：多任务并行后如何管理阻塞、审批与通知

2501_94482926

329人浏览 · 2026-09-05 10:57:38

2501_94482926 · 2026-09-05 10:57:38 发布

一个人同时开了八个 Agent：有的找资料，有的写稿，有的做图，还有的处理报价和代码。

半小时后，八个窗口各有一个状态：已完成、正在重试、缺参数、要授权、等待确认覆盖文件。用户开始来回巡逻，工作没少，只是从亲自干活变成了管理通知。

GitHub 在 2026 年 9 月 4 日的 Copilot 周报中提到，VS Code 1.136 的 Chat sessions 可以用层级结构组织相关对话，并显示哪些需要用户关注。官方发布说明还写到：每个对话行显示自己的状态和待批准事项，需要输入与已收到回复的通知可分别配置。周报 · VS Code 1.136 发布说明

本文不评测这些功能，而是解决一个通用工程问题：多 Agent 并行之后，怎样只把真正需要人的少数问题送到面前？

多 Agent 工作状态需要先收拢，再交给人

1. 先分清任务、事件和注意力项

三者不应混成一张列表：

对象	回答的问题	示例
Task	还有什么工作没完成	生成并校验报价单
Event	系统发生过什么	第二次查价超时
AttentionItem	人现在最少需要做什么	确认税率或上传新依据

一个任务可以生成很多事件，但大部分事件不该打断人。健康运行中、按预期重试中、成功且暂时无需验收，都可以留在台账或日报。

只有系统无法继续安全推进，并且人能提供某个不可替代的资料、判断或权限时，才生成 attention item。

2. 用状态机限制打断入口

先不要用模型判断“要不要打扰用户”。先用确定性状态机固化进入条件：

QUEUED -> RUNNING -> SUCCEEDED
                 -> RETRY_WAIT -> RUNNING
                 -> BLOCKED_EXTERNAL -> RUNNING
                 -> BLOCKED_HUMAN -> RUNNING / CANCELLED
                 -> FAILED_FINAL

其中，仅 BLOCKED_HUMAN 会立即进入注意力队列。FAILED_FINAL 也不一定需要即时打断：如果它是非关键批处理中的单个失败，可以先进异常日报。

可以先定义一个最小模型：

type AttentionItem = {
  id: string;
  taskId: string;
  status: "open" | "resolved" | "expired";
  reason: "missing_input" | "approval" | "conflict" | "retry_exhausted";
  title: string;
  nextAction: string;
  safeWhileWaiting: "pause" | "save_draft" | "continue_read_only";
  risk: "low" | "medium" | "high";
  dueAt?: string;
  blockedTaskIds: string[];
  evidenceRefs: string[];
  sourceUrl: string;
  dedupeKey: string;
  revision: number;
  createdAt: string;
  updatedAt: string;
};

nextAction 不允许空值。“任务失败，请处理”不是可执行交付；“在 A/B 两个税率中选择，或上传新依据”才是。

3. 同一原因只让人处理一次

如果三篇文章、一张报价和一个客服答复都缺同一版产品参数，不应生成五个弹窗。

用“资源 + 原因 + 证据版本”建立去重键：

import { createHash } from "node:crypto";

function makeDedupeKey(input: {
  resourceId: string;
  reason: string;
  evidenceRevision: number;
}) {
  return createHash("sha256")
    .update(`${input.resourceId}:${input.reason}:${input.evidenceRevision}`)
    .digest("hex");
}

新阻塞与已开放项的 dedupeKey 相同时，更新 blockedTaskIds 和 updatedAt，不再发第二个通知。证据版本改变时必须生成新键，避免用旧答案解锁新问题。

4. 优先级用稳定规则，不用伪精确分数

“紧急度 87 分”很难解释。小团队先用字典序排序往往更稳定：

第一维：风险（资金/数据/合规/对外发送 > 普通质量偏好）
第二维：有效期（快过期 > 无硬时限）
第三维：阻塞宽度（多个下游 > 单任务）
第四维：已等待时间

例如，“即将向客户发送价格不一致的报价”应高于“一张尚未发布的配图风格待选”。不需要模型为两者打出小数点后的分数。

注意力项按风险、时效和阻塞范围进入工作台

5. 人点开后，要能回到事情发生的地方

VS Code 的发布说明特别提到，委派的对话会保留来源链接，用户可以回到发起它的准确会话。这类可追溯性对业务 Agent 同样重要。

一个 attention item 点开后应直接显示：

它来自哪个任务与子步骤；
用到了哪版输入、文件或政策；
Agent 已经尝试过什么；
当前可选动作与各自后果；
不处理时系统会保持什么安全状态。

“批准”按钮不能只回传 true。至少记录操作人、操作、时间和对应的 revision；恢复任务前再比对依赖版本，改变后要求重新处理。

6. 别让注意力队列自己爆仓

当开放项越积越多，系统不该继续创建更多低优先级 Agent 任务。可以配置简单的在制品上限：

attentionPolicy:
  maxOpen: 8
  highRiskAlwaysNotify: true
  pauseNewLowPriorityTasksWhenFull: true
  digest:
    completed: daily
    failedNonCritical: twice_daily