multi-agent-task-orchestrator

Multi-Agent Task Orchestrator 是一种经生产环境验证的多智能体协作模式，核心思路是：不让多个智能体各自独立工作而互相冲突，而是由单一编排者统一拆解任务、分派给专家、防止重复劳动，并在标记完成前验证结果。据资料描述，该模式经过 6 个月、10,000+ 任务的实战检验。

适用场景

拥有 3 个以上专用智能体、需要协作处理复杂任务时。
智能体之间出现重复或冲突工作时。
需要审计轨迹，记录谁在何时做了什么时。
智能体输出质量不稳定、需要验证门禁时。

工作方式

定义编排者身份：编排者必须明确自己「是什么」和「不是什么」，避免亲自干活而不去委派。资料给出的身份设定为：你是任务编排者，从不亲自做专业工作，只负责拆解任务、委派给正确的智能体、防止冲突、在标记完成前验证质量。NOT-block（不是什么）包括：不是代码编写者（交给代码智能体）、不是研究者（交给研究智能体）、不是测试者（交给测试智能体）。资料称这一模式在生产中可减少约 35% 的任务漂移。
构建任务注册表：在分配工作前，先检查是否已有人在做同一任务。资料提供了基于 sqlite3 与 difflib.SequenceMatcher 的 check_duplicate 函数代码，查询状态为 pending 或 in_progress 的任务描述，相似度达到阈值（默认 0.55）即视为重复。
路由任务给专家：使用关键词评分把任务匹配到最合适的智能体。资料给出了 AGENTS 字典，包含 code-architect、security-reviewer、researcher、doc-writer、test-engineer 及其对应关键词，以及 route_task 函数：统计各智能体关键词命中数，取最高者，若无命中则默认 code-architect。
执行质量门禁：资料强调「智能体输出是声明，测试输出才是证据」。智能体报告完成后需检查：文件是否真的被修改（git diff --stat）、测试是否通过（npm test / pytest）、是否引入密钥（grep API keys、tokens）、构建是否成功（npm run build）、是否只触碰了预期文件（范围检查）。全部通过后才可标记完成。
30 分钟心跳：每 30 分钟自问「过去 30 分钟我委派了什么」；若无则打开任务积压并分配下一任务；检查空闲智能体（被分配任务超过 30 分钟无消息）；重新唤醒空闲智能体或重新分配其任务。

示例

委派代码任务：[ORCHESTRATOR -> code-architect] TASK: Add rate limiting to /api/users；SCOPE: src/middleware/rate-limit.ts only；VERIFICATION: npm test -- --grep "rate-limit"；DEADLINE: 30 minutes。
处理重复：用户要求「Fix the login bug」，注册表检查发现任务 #47「Fix authentication bug」正由 security-reviewer 处理中，相似度 78%，决定跳过，告知用户已有任务并等待完成。

最佳实践

为每个智能体定义 NOT-blocks（必须拒绝做什么）。
用 SQLite 作为任务注册表（轻量，无需服务器）。
反重复相似度阈值设为 55%（更低会产生过多误报）。
要求基于证据的质量门禁，而非仅凭智能体声明。
每次委派记录：任务 ID、智能体、范围、截止时间、验证命令。

常见问题与对策

编排者开始自己干活而不委派：添加明确的 NOT-blocks 与角色边界。
两个智能体同时修改同一文件：任务注册表加文件级锁与队列系统。
智能体声称「完成」但实际没有改动：质量门禁在接受完成前检查 git diff。
任务堆积无进展：30 分钟心跳发现过期分配并重新分配。

技能介绍