ACO — Agent 调度控制中枢

你有 5 个 Agent，谁来决定哪个干什么？

Agent 越来越多，协作越来越乱。任务派给了不该接的人，开发 Agent 自己审自己的代码，某个 Agent 卡死了半小时没人发现，主会话被一个耗时任务堵住、用户消息进不来。你盯着终端手动串联每一步，调度规则写在文档里，模型一长上下文就忘了。

ACO 把多 Agent 协作的调度治理收拢成一套代码级强制执行的框架。派发准入、角色约束、超时熔断、失败重派、自动推进、主会话保护、kill 后置影响扫描——全部可编程、可追溯、可观测。

装在 OpenClaw 上，init 完自动生效。

核心优势

派错了直接拦住 每个任务经 LLM 语义分类，只有对应角色的 Agent 才能接。PM 写需求，开发写代码，审计做审查。派错了不靠模型自觉，代码级阻断。

开发审计物理隔离 开发 Agent 写完代码，自动触发独立审计 Agent 复查。开发和审计永远是两个人，代码级强制，杜绝自己给自己打分。

卡死了秒级发现 Agent 超时自动熔断，5 分钟无输出即告警，僵尸进程自动回收。任务失败后自动升级梯队重派，不原样重试。

主会话永远畅通 耗时任务全部派给子 Agent，主会话只做秒级调度决策。主会话调长超时的 process 轮询、同步等待这些阻塞动作时，守卫会拦住并引导到异步路径。用户消息永远不会因为 Agent 忙碌而被丢弃。

语义豁免，不靠关键词表 用户说「我亲自处理」「别派了」「YES」「我盯着」，都是授权主会话亲自干。谁都不可能背一份「豁免关键词清单」。ACO 用 LLM 做语义意图判定，任意措辞都能识别，聕聊别的事不会被误放行。LLM 超时或出错一律不豁免（宁可误拦不能误放），不走关键词、正则、fallback 路径。

Kill 前看清手头什么在着 主会话 kill 一个子 Agent 之前，ACO 自动扫描该 Agent 运行期内写过哪些文件，生成一份影响报告：affectedFiles（受影响文件列表）、riskLevel（高/中/低，docs/、spec/ 路径命中自动提到 high）、recommendedAction（是否需要先 stash）。主会话拿到报告后才决定下一步，不会「闭着眼」git checkout 覆盖有价值的产出。aco audit kill-impact 随时查历史记录。

声明式任务链 定义「开发→审计→测试→发布」的推进链，上一步完成自动触发下一步。失败即时重派，不等同批任务回收。

假完成识别 Agent 说"完成了"但实际什么都没干——output_tokens 极低、没写文件、产出为空。ACO 不信嘴上说的，看实际产出。详见下方「实质成功校验」。

任务状态自动推送 任务完成、失败、超时，自动推送到飞书/Telegram/Slack。不用盯终端，手机上就能知道进展。

全链路可审计 每个派发决策带时间戳、规则 ID、拦截原因写入日志。出了问题秒级定位，不用翻聊天记录猜发生了什么。

快速开始

npm install -g @self-evolving-harness/aco
npx aco init

init 自动检测你的 OpenClaw 环境——发现现有 Agent 池、读取角色配置、检测已有的 IM 通知渠道。初始化完成后，ACO 作为 OpenClaw Gateway 插件自动运行：dispatch-guard 拦截违规派发，run-watchdog 监控超时熔断，无需手动操作。

前提：你的机器上跑着 OpenClaw Gateway。ACO 是 OpenClaw 的调度治理层，依赖 Gateway 提供 Agent 执行能力。

CLI 命令

aco init          # 初始化（检测 OpenClaw 环境 + 生成配置 + 注册插件）
aco dispatch      # 派发任务到 Agent
aco task          # 任务管理（查看/取消/重试）
aco board         # 任务看板（实时状态聚合视图）
aco pool          # Agent 池管理（查看/同步状态）
aco rule          # 调度规则管理（查看/启用/禁用）
aco chain         # 任务链管理
aco stats         # 资源利用率统计
aco audit         # 决策溯源查询
aco config        # 配置管理
aco notify        # 通知管理（渠道注册/测试/状态）
aco health        # 健康检查
aco doctor        # 健康检查别名

每个命令支持 --help 查看详细用法。

工作方式

ACO 的核心价值不是 CLI 工具箱，而是安装即生效的治理框架：

1. aco init 检测 OpenClaw 环境，生成配置文件（aco.config.json）
2. Gateway 加载 ACO 插件，自动激活以下治理能力：
   • dispatch-guard：每次任务派发前校验角色准入、梯队路由
   • run-watchdog：监控 Agent 执行超时、僵尸进程回收
   • audit-logger：记录所有派发决策到审计日志
   • chain-engine：推进链自动触发下一步
   • notify-transport：任务状态变化自动推送到 IM 渠道

你不需要手动执行命令——治理规则在 Agent 协作过程中自动强制执行。

实质成功校验

Agent 说"完成了"不等于真的完成了。ACO 不只看任务状态码，还看实际产出。

什么算假完成：

• output_tokens 极低（比如 < 3000）且没有写入任何文件
• 任务要求写文件但产出路径为空
• 回复内容是套话（"已完成""请查看"）但没有实质内容

ACO 怎么处理：

• 任务标记为 succeeded 后，自动检查产出指标
• 命中假完成规则的任务，状态降级为 failed-hollow，触发重派流程
• 重派时自动升级梯队或拆分任务粒度，不原样重试
• 假完成事件写入审计日志，可追溯哪些 Agent 频繁空跑

这个能力解决一个真实痛点：模型有时候会"礼貌性完成"——回复一段看起来合理的话，但实际什么都没干。靠人肉检查每个 completion 不现实，ACO 用规则自动兜底。

主会话异步纪律守卫

主会话（跟用户聊天那一口）一旦被耗时任务堵住，用户发出的新消息会被 Gateway 静默丢弃（已知缺陷）。ACO 把「主会话必须保持空闲」这条高优先约束从 prompt 约束下沉为插件层强制。

阻塞动作识别 + 拦截 主会话调长 timeout 的 process poll/wait/log/list 、等待子任务完成这些动作时，守卫从调用参数识别为「阻塞等待」并拦截，返回引导信息：拆任务、派子 Agent、采用 push-based completion 代替轮询。用户消息永远不会被耗时动作堵在门外。

LLM 语义豁免判定 用户说「我亲自处理」「不要派了」「YES」「我盯着」，都是语义上授权主会话本回合亲自执行。传统实现靠关键词表匹配，措辞不在表里就被误拦（用户被迫去背关键词清单，体验不可接受）。ACO 用 LLM 判定语义意图，任意措辞都能识别。LLM 超时、异常、disabled 一律不豁免（宁可误拦不能误放），不走关键词、正则、fallback 路径。

守卫降级自愈 守卫主逻辑异常连续命中后进入 degraded 状态，临时放行所有调用避免守卫本身成为故障点。恢复窗口到来后自动重试，运行正常则取消 degraded，拦截逻辑重新生效。不需要人工介入重启插件。

Kill 后置影响扫描 主会话 kill 一个子 Agent 之前，ACO 里接过 kill 调用：先读看板拿到该 Agent 的 startedAt，扫描运行期内被修改过的文件，生成一份报告：

• affectedFiles：受影响文件列表（只计 mtime 在运行期内的文件）
• riskLevel：high / medium / low。docs/、spec/、product-requirements.md 这类路径命中 → 自动提到 high
• recommendedAction：safe_to_kill / consider_stash_first / manual_review_required

主会话拿到报告后才决定下一步。「闭着眼」git checkout 覆盖有价值产出的事情不会再发生。aco audit kill-impact 随时查历史记录。

通知与 IM 推送

任务状态变化自动推送到你的 IM，不用盯终端。

支持的渠道： 飞书、Telegram、Discord、Slack、通用 Webhook

开箱即用： aco init 自动检测 OpenClaw 已配置的 IM 渠道并注册。如果你的 OpenClaw 已经配了飞书，init 完就能收到通知，零额外配置。

推什么：

• ✅ 任务完成：✅ [agent-id] task-label | 耗时 45s
• ❌ 任务失败：❌ [agent-id] task-label | 耗时 120s（失败原因）
• ⚠️ 超时熔断、僵尸回收、梯队升级等异常事件

不推什么（防刷屏）：

• 健康检查、心跳等系统内部事件默认排除
• 支持按 label 模式、优先级、Agent、任务来源自定义过滤规则

送达保障： 发送失败自动重试（3 次指数退避），连续失败标记渠道 degraded 并告警。aco notify status 查看各渠道送达率。

Agent 梯队体系

编码 Agent 按能力和成本分四级。T1 最强成本最高，T4 最轻量成本最低。任务失败时自动往更强的梯队升级重试：

| 梯队 | 定位 | 失败后 | |------|------|--------| | T4 | 轻量任务，成本最低 | 升级到 T3 | | T3 | 标准任务，中等能力 | 升级到 T2 | | T2 | 复杂任务，高能力 | 升级到 T1 | | T1 | 能力最强，成本最高 | 已是最高梯队，标记 failed-exhausted，告警人工介入 |

升级方向：T4 → T3 → T2 → T1。到了 T1 还失败，说明任务本身有问题，需要人工介入（拆分、改 prompt、或确认是否可行）。

非编码角色独立管理：架构师、PM、审计、UX、调研，各司其职，不参与梯队升级。

可控性分层模型

传统方案把调度规则写在 prompt 里，告诉模型"开发不能自审""超时要熔断"。问题是：上下文一长，模型就忘了。prompt 规则的遵从率大概 70-80%，每 5 次派发就可能有一次违规漏过去。

ACO 的做法——同一条规则部署在多个层级，高层忘了低层兜底，关键规则下沉到代码级强制执行。

| 层 | 名称 | 载体 | 可靠性 | ACO 做了什么 | |----|------|------|--------|-------------| | L0 | 平台层 | OS / systemd / cron | 最高 | 僵尸进程 cron 巡检回收，systemd 自动拉起 Gateway | | L1 | Gateway 核心 | OpenClaw 源码 | 极高 | 路由分发、认证鉴权（ACO 依赖宿主，不改这层） | | L2 | 插件层 | Gateway Plugin (JS) | 高 | dispatch-guard 角色准入阻断、run-watchdog 超时熔断 | | L3 | Hook 层 | 事件钩子 | 高 | 任务完成自动触发审计链、推进链回调 | | L4 | ACP Harness | Agent 专属配置 | 中高 | 外部 Agent 的角色约束、工具白名单 | | L5 | 配置层 | aco.config.json | 中 | 梯队定义、超时阈值、路由规则声明 | | L6 | Prompt 注入 | AGENTS.md / SOUL.md | 中低 | Agent 行为提醒（兜底，非唯一防线） |

层号越小越可靠、越难被模型绕过。L2 插件层是代码在跑，模型说什么都没用；L6 prompt 层靠模型自觉，长上下文一稀释就失效。

具体例子：「开发不能自审」这条规则怎么部署？

• L2（代码阻断）：dispatch-guard 插件检测到派发审计任务时，校验目标 Agent 是否与开发者相同——相同直接拒绝，返回错误码。模型根本没机会执行。
• L3（Hook 触发）：开发完成的 completion event 自动触发审计派发，目标 Agent 从审计池选取，流程上就不经过开发者。
• L6（Prompt 提醒）：AGENTS.md 写着"禁止开发者自审"，模型大概率会遵守，但偶尔会忘。

三层冗余的效果：即使 L6 被忽略（概率 20-30%），L2 仍然 100% 拦住。规则的实际执行率从 prompt-only 的 ~75% 提升到接近 100%。

使用场景

多 Agent 研发流水线 3 个以上 Agent 分工协作（开发→审计→测试→发布），需要统一调度、角色约束、故障自愈。ACO 管住谁干什么、什么时候干、失败了怎么办。

单人 + 多 Agent 做产品 你是产品操盘手，Agent 是执行团队。ACO 帮你管住派发纪律——任务不会派错人，卡死了自动处理，完成了自动通知你。

单 Agent 也有用 只有一个 Agent 也能获得超时保护、失败重试、状态通知和实质成功校验。随时扩展到多 Agent，调度规则无缝升级。

渐进式解锁

ACO 按 Agent 数量自动解锁功能：

• 1 个 Agent：超时保护、失败重试、状态通知、实质成功校验
• 2-5 个：角色约束、梯队路由、开发审计分离
• 5+ 个：并发控制、负载均衡、全链路审计、推进链编排

零配置启动，规模大了自动解锁更多治理能力。

编程接口

import { createScheduler } from '@self-evolving-harness/aco';

const scheduler = createScheduler({ configPath: './aco.config.json' });
await scheduler.dispatch({ label: 'code-review', prompt: '...' });

也可作为 Gateway 插件直接加载（推荐方式，init 后自动生效）。

文档

• 快速开始
• 配置参考
• 故障排查
• 产品需求规格
• 架构设计

License

MIT