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

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

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

本文不评测这些功能，而是解决一个通用工程问题：多 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

阈值不是通用真理。先记录四类指标，再用自己团队的数据调整：

• 最长未处理时间；
• 每个有效决定带来的打断次数；
• 被合并的重复项占比；
• 人处理后因上下文不足导致的返工率。

不要以“通知点击率高”作为成功。红点越多，点击当然可能越多，人的时间却未必更省。

7. 工程边界与失败处理

1. 外部系统阻塞不等于人工阻塞：接口限流应进 RETRY_WAIT 或 BLOCKED_EXTERNAL，不要立刻问人。
2. 去重不能合并不同证据版本：否则一次回答会误解锁新任务。
3. 通知送达不等于已处理：开放项仍需有服务端状态，不能只依赖前端红点。
4. 超时不能默认批准：到期后执行 safeWhileWaiting，如保留草稿或暂停，而不是猜测答案。
5. 高风险动作不因求快而合并：付款、对外发送、覆盖资料等仍需独立的对象和证据。

8. 从一人公司开始的实施清单

1. 统一五个基础任务状态。
2. 仅 BLOCKED_HUMAN 生成即时队列项。
3. 强制填写 nextAction、safeWhileWaiting 和 sourceUrl。
4. 使用稳定去重键合并同根因打断。
5. 先按风险、有效期、阻塞宽度和等待时间排序。
6. 设在制品上限，队列满时暂停新的低优先级任务。
7. 每周清理误报和重复打断，将高频问题收回流程默认值或安全自动分支。

9. 岗位化协作的价值，是少打断人

这也是我们做 Tipkay 时关注的一个取舍。Tipkay 面向小微企业、一人公司和小团队提供按需 AI 员工。不同岗位的助手可以带着自己的经验、Skill、MCP 和流程接力工作，从生成继续做到素材、排版、文件和发布准备。

本文的注意力队列 schema 和调度方法是通用设计建议，不是对 Tipkay 已有某个界面或完整实现的宣称。真正的岗位协作不是屏幕上多几个 Agent 头像，而是大部分步骤能安静接力，只在必要时交回一个说得清的问题。

一个人的生意，也能有一支专业团队。而专业的一部分，是不让老板每五分钟巡逻一遍八个窗口。