编排器只包装已有 CLI，不自己实现 Agent

更新于 2026-07-31

**AO 这类 Agent 编排器不实现 Agent，它只「包装」本机已装好的 CLI（claude-code / codex / opencode …）：模型、订阅、技能都是那个 CLI 自己的。** 一次委派的完整链路：

1. 接单：桌面按钮 / ao spawn / POST /api/v1/sessions 都打到同一个 daemon API，请求只有四样：项目、名字、harness、prompt。

  1. 隔离：分配会话 ID，在仓库外建独立 worktree + 专属分支（如 ao/<name>/root），worker 碰不到主目录，也碰不到其他 worker。
  2. 启动：在 tmux 会话里拉起对应 CLI，cwd 设为该 worktree —— 所以能 tmux ls / capture-pane 观察它。
  3. 下发：注入系统提示（编排器的规矩）+ 任务 prompt，之后不干预它的思考过程。
  4. 监控：只观察不控制 —— 运行时探测器（进程还活着吗、终端在滚动吗）推导 working / idle / dead；SCM 探测器定期问 GitHub（PR / CI / review）。
  5. 收货：PR 即交付；正常开发任务在 PR 合并后可自动终结会话（terminateOnPrMerge）。

一句话：委派 = 开一块隔离工地（worktree）+ 雇一个你已有的工人（CLI harness in tmux）+ 塞任务书（prompt）+ 用摄像头盯进度（探测器→看板），验收标准是 PR。

主控（orchestrator）会话与 worker 的差别只在系统提示：主控被教「拆任务、用 ao 派活」，worker 被教「干活、提 PR」。

实操补充

  • 文档型 skill（如 using-ao）教的是 ao CLI 用法；只装了桌面版、没有 CLI 时，把 CLI 语义翻译成 daemon HTTP API 调用即可。
  • 大 monorepo 里文件监听可能爆句柄（EMFILE），先 ulimit -n 提高上限再重启会话。

相关

  • 多Agent协作控制面
  • Agent编排层薄自建优先于重型框架
  • 远程Agent控制要定义执行协议与状态模型
  • Agent harness 要隔离复现可收尾