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

一个人同时开了八个 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也不一定需要即时打断如果它是非关键批处理中的单个失败可以先进异常日报。可以先定义一个最小模型typeAttentionItem{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}fromnode:crypto;functionmakeDedupeKey(input:{resourceId:string;reason:string;evidenceRevision:number;}){returncreateHash(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:8highRiskAlwaysNotify:truepauseNewLowPriorityTasksWhenFull:truedigest:completed:dailyfailedNonCritical:twice_daily阈值不是通用真理。先记录四类指标再用自己团队的数据调整最长未处理时间每个有效决定带来的打断次数被合并的重复项占比人处理后因上下文不足导致的返工率。不要以“通知点击率高”作为成功。红点越多点击当然可能越多人的时间却未必更省。7. 工程边界与失败处理外部系统阻塞不等于人工阻塞接口限流应进RETRY_WAIT或BLOCKED_EXTERNAL不要立刻问人。去重不能合并不同证据版本否则一次回答会误解锁新任务。通知送达不等于已处理开放项仍需有服务端状态不能只依赖前端红点。超时不能默认批准到期后执行safeWhileWaiting如保留草稿或暂停而不是猜测答案。高风险动作不因求快而合并付款、对外发送、覆盖资料等仍需独立的对象和证据。8. 从一人公司开始的实施清单统一五个基础任务状态。仅BLOCKED_HUMAN生成即时队列项。强制填写nextAction、safeWhileWaiting和sourceUrl。使用稳定去重键合并同根因打断。先按风险、有效期、阻塞宽度和等待时间排序。设在制品上限队列满时暂停新的低优先级任务。每周清理误报和重复打断将高频问题收回流程默认值或安全自动分支。9. 岗位化协作的价值是少打断人这也是我们做 Tipkay 时关注的一个取舍。Tipkay 面向小微企业、一人公司和小团队提供按需 AI 员工。不同岗位的助手可以带着自己的经验、Skill、MCP 和流程接力工作从生成继续做到素材、排版、文件和发布准备。本文的注意力队列 schema 和调度方法是通用设计建议不是对 Tipkay 已有某个界面或完整实现的宣称。真正的岗位协作不是屏幕上多几个 Agent 头像而是大部分步骤能安静接力只在必要时交回一个说得清的问题。一个人的生意也能有一支专业团队。而专业的一部分是不让老板每五分钟巡逻一遍八个窗口。