别再手切终端管 Agent 了！1 个 Skill 监督多个主流 CLI，默认每 15 秒读屏（建议收藏）🚀

先放个结论：装上 Taskforce 这一个 Skill，你就能用一句自然语言启动 opencode、codex、claude、codebuddy 等多个主流 coding CLI，让它们串行或并行干活，Skill 自动帮你监督 ------默认每 15 秒读取一次终端，检测到屏幕变化、产物事件或 send 后的确认时返回给 Chief 审查。安全、项目范围内的权限请求可以直接处理；跑偏时向原 TUI 发纠偏信息，不必重启当前会话；Worker 退出后则可 relaunch，并保留工作区文件、旧 run 证据和恢复指令。

先说明它的适用边界：Taskforce 解决的是多个独立 coding CLI 之间的协作和监督问题，不是所有多 Agent 任务都需要它。 如果一个 CLI 已经支持 subagent，而且设计、实现、测试和审查都能在同一个 CLI 会话及其子 Agent 体系内完成，直接使用 subagent 通常更简单，也没必要额外安装 Taskforce。只有当你确实需要 codex、Claude Code、OpenCode、codebuddy 等不同 CLI 共同完成任务时，跨终端监督、权限处理和上下游接力才会成为问题。

这个 Skill 不是拍脑袋想出来的，是日常多 CLI 协作中真被跨终端切换、权限等待和手工接力折磨够了，想找个办法自动化才沉淀出来的。

拿一个典型的多 CLI 场景来说明。假设要重构一个复杂的老项目，你希望主动组合不同 CLI 的模型、工具和使用体验，而不是只在一个 CLI 内分派 subagent。例如让一个 CLI 负责方案设计，另一个负责实现，再让第三个使用不同模型和工具链独立审查。

比如可以先用 codex 输出重构方案和计划文档，再让 Claude Code 按方案实现，最后由 opencode 审查代码和测试。角色并不固定，重点是让所有 CLI 在同一个项目工作区中，通过设计文档、代码、测试和进度文件逐步接力。

但这个过程有一个让人崩溃的问题：需要不断切换不同 CLI，工作非常重复。把 codex 的方案文档粘贴给 Claude Code，Claude Code 编完再把结果交给 opencode 审查，审查意见又要反馈给实现节点修改......反复循环，手动搬运上下文，比写代码还累。

我就想：能不能让这些 CLI 按依赖关系自动接力，通过共享工作区读取上游留下的设计、代码和进度文件，我只需要在关键节点做判断？于是把这套监督逻辑抽成了一个通用 Skill，就是 Taskforce。

先看一个串行协作的示例效果：下图是多个 coding CLI 串行协作（codex 设计 → claude 实现 → opencode 审查）的监督过程示意，Chief 在每个 tick 独立决策，对安全且项目范围内的权限请求直接处理，跑偏时当场纠正，验证后才标记完成。

上图：codex 做方案设计 → claude 做代码实现 → opencode 做代码审查，Chief 全程读屏 + 实时决策。红框区域是 Chief 的关键干预点（权限批准 / 方向纠偏 / 完成验证）。

---

一、当你需要多个 CLI 协作时，是不是也遇到这些问题？

下面这些问题都有一个共同前提：任务需要多个独立 CLI 协作，而不是一个 CLI 带几个 subagent 就能完成。 在这个前提下，看看你是否也遇到过：

• 🤯 多个终端窗口跑 codex、claude、opencode，Alt+Tab 切到头晕，不知道哪个在等你；
• ⏳ 摸鱼回来发现 Agent 卡在权限菜单等了 20 分钟，一行代码没写；
• 🔄 Agent 跑偏了，只能 Ctrl+C 重启，前面写的全没了；
• 🤷 Agent 说"写完了"，一跑测试3 个 bug 2 个没实现，根本没验证；
• 😩 想串行协作（设计→实现→审查），得手工盯着上一个完没完再启动下一个。

如果你确实需要多 CLI 协作，并且中了 2 条以上，那这篇文章就是写给你的。反过来，如果单个 CLI 的 subagent 已经能满足任务需求，继续使用它即可，Taskforce 并不会让这种场景天然变得更好。

Taskforce 就是补上这一层：它跑在 cmux 之上，装成你现有 coding CLI 里的一个 Skill，负责组织"启动、读屏、决策、验证"四件事。cmux 提供原生终端和可见分屏，Taskforce 负责持续监督------默认每 15 秒重新读取运行中的终端；某次读取一旦检测到变化，就立即返回给 Chief，而不会继续等待。Worker 在两次读取之间独立运行。

opencode、codex、claude、codebuddy 这些主流 CLI，Taskforce 都提供了适配。它直接启动你现有的 CLI，通常不需要迁移原有模型配置、项目指令或 Skills；具体行为仍以对应 CLI 的启动方式和权限配置为准。

---

二、Taskforce 到底是什么？

一句话：一个跑在外层的监督循环（supervisor loop），负责启动、读屏、决策、验证，让多个独立 coding CLI 按依赖关系把活干完。

它有四个核心动作，记住这四个就够了：

动作	含义	什么时候用
continue	不输入，继续观察	Agent 在正常思考/写码/跑测试
send	发一个按键或一段纠偏文字	权限菜单要批、或 Agent 跑偏了
relaunch	旧进程退出后重新拉起	Worker CLI 真的崩了/退出了
complete	核对目标和实现后才完成	代码和测试都验证通过

⚠️ 重点：Thinking 时间长、屏幕没变化、文件还没出现，这些都不是 relaunch 的理由。 Taskforce 永远不会为了重启去杀一个还活着的 Worker------这正是它和"重试型 Agent"最大的区别。

工作原理图

下面这张图是它的核心架构，我直接从源码里梳理出来的：

上图：多个 Worker CLI 的真实终端经 cmux surface 采集器汇聚到 Chief，Chief 对每个节点独立决策（continue / send / relaunch / complete），决策写入 .taskforce/state/ 供下一轮消费。

一次 tick 的内部流程 是这样的（supervisorTick 是源码里的函数名，知道有这回事就行，不用追读源码）。注意：tick 只负责采集和写出 observation，Chief 的决策发生在两个 tick 之间------宿主 Agent 读取 observation、做出决策、写入 decision 文件，下一个 tick 再消费它：

消费上一轮 Chief 决策
    ↓
检查工作流是否已完成
    ↓
检测产物事件（result.json / questions.json / cli_exit 等）
    ↓
启动 pending / relaunch 的节点
    ↓
读取每个 running 节点的 cmux surface（真实终端 80 行）
    ↓
计算 screen_hash，拼接任务契约（goal/boundaries）
    ↓
写出 latest_observation_batch.json
    ↓ （tick 结束，返回 observation）
宿主中的 Chief 逐节点决策 → 写 latest_decision_batch.json
    ↓
回到顶部，下一轮 tick 消费它

这套循环默认以 15 秒为读屏间隔（--poll-seconds 15）：每次短 tick 都会读取运行中的 surface；如果形成了需要审查的 observation，就立即返回给 Chief，空闲时才继续等待下一轮。Worker 在两次检查之间独立运行。运行时本身只负责采集、分发和状态约束，具体的 continue / send / relaunch / complete 由宿主中的 Chief 逐节点判断。

---

三、什么时候才需要它？一张表说清

先判断自己的任务属于哪一种：

• 单 CLI + subagent：任务可以在同一个 CLI 的上下文、权限体系和 Agent 调度能力内完成，优先使用原生 subagent。
• 多个独立 CLI 协作：需要组合不同 CLI、模型、配置或工具链，并让它们串行或并行接力，这才是 Taskforce 的目标场景。

下面对比的是第二种情况，也就是"手工管理多个独立 CLI"和"用 Taskforce 监督多个独立 CLI"：

维度	手工管理多个 CLI	用 Taskforce
启动方式	手动开多个终端，逐个贴 prompt	一句自然语言描述串行/并行关系
观察频率	靠你 Alt+Tab 去瞄一眼	默认每 15 秒读屏，检测到变化后立即返回
权限菜单	卡住了你才发现，干等	Chief 检查命令、范围和风险后处理
跑偏纠正	重启，丢上下文	向同一个 TUI发纠偏文字，不重启
完成判断	Agent 说完成就完成？天真	核对 goal、代码、测试、validation 才算
CLI 退出	任务中断，手动重来	检测到退出才 relaunch，保留旧 run 记录
多 CLI 协作	手工接力	codex 设计→claude 实现→opencode 审查自动串

最打动我的一点 ：它不要求你迁移到一套新的 Agent 平台。Taskforce 直接调用现有 CLI，在外层增加"启动 + 读屏 + 决策 + 验证"这四件事。原有配置通常可以继续使用，但最终行为仍受对应 CLI 和项目权限设置影响。

---

四、5 分钟上手：从安装到跑通

4.1 环境准备

• 任意支持 Agent Skills 的 CLI（Codex / Claude Code / OpenCode / codebuddy）
• cmux 并开启 Automation socket access
• PATH 里至少一个 worker CLI：opencode、codex、claude 或 codebuddy
• Node.js 18+ 和一个 Git 项目

运行 Taskforce 的 CLI 和被监督的 Worker CLI，可以是同一个，也可以不同。比如你用 Claude Code 装 Taskforce，让它去监督 opencode，完全没问题。

4.2 一行安装

# --global 全局安装；去掉 --global 则装到当前项目
npx skills add lhanyun/taskforce \
  --skill taskforce --agent codex --global

用别的环境就把 codex 换成 cursor、opencode 或 claude-code。安装成功后终端会打印 Skill 装到的目标路径：

Installed the complete Taskforce skill to ~/.codex/skills/taskforce
Next: reload your agent host and invoke Taskforce in a project.
First use will run doctor, role CLI/model confirmation, cmux checks, and preflight.

上面的代码块：安装成功后的终端输出。最后一行说明------首次在项目里调用 Taskforce 时，会自动跑环境检查（doctor）、cmux 校验和 preflight，不用你手动初始化。

4.3 直接使用

装完 reload 一下 agent host，就可以在任意 Git 项目里直接用了------不需要手动跑 setup 。第一次调用 Taskforce 时，Skill 会自动创建 .taskforce/ 目录树、校验 Git 仓库 + cmux socket + PATH CLI 三项环境就绪。如果环境有问题，它会直接报错告诉你怎么修（比如 cmux 没开 Automation、没装 worker CLI），不会静默继续。

4.4 启动你的第一个工作流

串行流（最经典的"设计→实现→审查"）：

使用 Taskforce。启动 codex 编写实时聊天系统的架构设计文档；
完成后启动 claude 按照设计文档实现代码；完成后启动 opencode 审查代码和测试，
修正发现的问题。持续监督整个工作流。

并行流（前后端齐头并进）：

使用 Taskforce。同时启动 codex 实现后端接口、opencode 实现前端页面；
两边完成后启动 claude 做整体审查。持续监督整个工作流。

注意：你不需要手写 workflow JSON、profiles 或轮询脚本 。你在描述里可以带 CLI、任务、顺序、完成条件，甚至精确的 model ID；宿主 Agent 会据此创建 .taskforce/tasks/ 下的任务契约和 .taskforce/workflows/ 下的工作流节点。

---

五、运行示例：一个坦克大战游戏是怎么被盯出来的

装好、启动之后，我们用一个示例来说明它的运行逻辑。下面拿 README 里的示例，走一遍完整的监督过程。你重点看 Chief 在每个 tick 的判断逻辑------这才是 Taskforce 的灵魂。

场景：让 opencode 开发一个坦克大战游戏（地图 + 敌人 AI + 计分），完成后让 codex 审查代码和测试。

下图聚焦 opencode 开发节点的 4 个关键 tick（TICK 1/4/8/12），对应编码、权限菜单、目标偏离、验证完成四种状态------这四个 tick 覆盖了 Chief 在单个节点生命周期内最常见的决策（continue / send / complete）；relaunch 只在 Worker 进程真正退出后才会用到，这个示例里没有触发，codex 审查节点走的是同一套循环，不再展开：

上图：opencode 在 4 个 tick 中的不同状态。红框标注 Chief 的四个关键决策点------TICK 1 continue（不催）、TICK 4 send key:enter（批准写入）、TICK 8 send input（纠偏回单机版）、TICK 12 complete（验证后完成）。

对应到决策表：

Tick	Chief 观察到什么	决策	为什么
1	opencode 写 Tank.ts，3/5 测试过	continue	正常推进，别催
4	权限菜单，请求写 Tank.ts	send key:enter	项目范围内的写入，安全，直接批
8	开始写 Network.ts，偏离单机目标	send input	跑偏了，发具体纠偏，不重启
12	全部测试通过，实现匹配目标	complete	核对 goal+实现+测试，真正完成

这里有三个细节，是 Taskforce 区别于"重试型 Agent"的关键：

1. TICK 1 不催 ：Agent 在思考、在写码、测试没全过------这都是正常工作，continue 是默认动作。很多新手会忍不住发"加油""快点"，Taskforce 的协议明确禁止这种无意义催促。
2. TICK 4 直接批 ：权限菜单不是"失败"，而是"观察事实"。图中安全的项目内写入选项已经处于当前高亮，因此 Chief 可以发送 enter 批准。若目标选项没有高亮，则必须一次只发送一个方向键，重新读屏确认后再发送 enter。涉及凭据、系统级权限、危险或不可逆操作时，仍应交给用户决定。
3. TICK 8 不重启 ：Agent 跑偏了，最常见的错误做法是 Ctrl+C 重来。Taskforce 的做法是向同一个 TUI 发纠偏文字，Agent 带着已有上下文继续干，前面写的 Tank.ts 一行都不丢。

---

六、源码拆解：Taskforce 如何借助 cmux API 实现

cmux 提供 CLI 命令 和 **Unix socket（JSON-RPC）**两类编程控制接口。以创建工作区为例，CLI 是 cmux workspace create，对应的 socket method 是 workspace.create。完整 API 文档见 cmux.com/zh-CN/docs/...。

Taskforce 选用 CLI 接口 （Node.js spawnSync 调 cmux 二进制），原因有三：一是每次调用自包含，不用维护 socket 连接生命周期；二是 cmux 会自动解析 socket 路径和环境变量；三是和 Worker CLI 的启动方式天然兼容（都是 shell 命令）。

下面把 Taskforce 的核心动作逐一拆解，每个都对应到源码里实际调用的 cmux 命令。

6.1 启动 Worker：开工作区 + 环境变量自动捕获 surface

启动一个 Worker 节点，本质是"在 cmux 里开一个新工作区，让它跑指定 CLI"。看 prepare_terminal_launch.mjs：

// prepare_terminal_launch.mjs --- terminalCommand()
return [cmuxPath, 'workspace', 'create',
  '--name', `${nodeId}: ${taskStem}`,
  '--cwd', String(project),
  '--command', String(launcherPath)];

这条命令对应 cmux 的工作区创建能力（socket method 为 workspace.create），一次做了三件事：开一个标题为 节点ID: 任务名 的工作区、把工作目录设成项目根、让工作区启动时自动执行 launcher 脚本。

关键细节：surface ID 怎么拿到？ cmux 在工作区内启动的进程会自动注入两个环境变量（API 文档"检测 cmux"一节）：

环境变量	含义
CMUX_WORKSPACE_ID	当前工作区 ID
CMUX_SURFACE_ID	当前 surface（分屏面板）ID

launcher 脚本先跑 agent_runner.mjs --prepare，它在 cmux 环境内直接读这两个变量写进节点状态------不需要额外查询：

// agent_runner.mjs --- writeNodeState()
cmux_workspace: process.env.CMUX_WORKSPACE_ID || '',
cmux_surface:   process.env.CMUX_SURFACE_ID || '',

这个设计很妙：surface ID 是 cmux "主动告诉"运行其内的进程的，而不是 Taskforce 去"问"cmux。后续所有读屏、发指令都靠这个 ID 定位。

6.2 读屏观察：read-screen 采集真实终端尾部

默认每 15 秒一轮的"读屏"，调的是 cmux 的 surface 读取命令。源码里会先试 read-screen，失败再回退到 capture-pane。每个短 tick 都会读取运行中的 surface；检测到变化、事件或 send 后的待确认状态时，会形成 observation 并返回：

// surface_collector.mjs --- readCmuxScreen()
const attempts = [
  [cmuxPath, 'read-screen', '--surface', surface, '--scrollback', '--lines', String(80)],
  [cmuxPath, 'capture-pane', '--surface', surface, '--scrollback', '--lines', String(80)],
];

• --surface <id>：指定读哪个面板
• --scrollback：带上滚动历史
• --lines 80：只取尾部 80 行（Chief 只需要看"最近发生了什么"）

读回来的纯文本会计算 SHA-256 hash，并和上次持久化的 hash 比对：变化时更新 last_screen_change_at；没有变化时，也可能因为周期复审、节点事件或 send 后确认而再次交给 Chief 判断。运行时不会仅凭"没变化"自动认定为卡住，也不会代替 Chief 自动选择 continue。

这就是为什么 Taskforce 能"定时读真实终端"------它读的不是日志文件、不是 stdout 管道，而是 cmux surface 里渲染出来的真实屏幕内容，TUI 的菜单、高亮、进度条全都原样拿到。

6.3 send 干预：send 发文字、send-key 发按键

send 是最核心的干预动作，底层对应 cmux 的两个输入 API：

Chief 决策	cmux CLI	socket method	用途
发纠偏文字	cmux send --surface <id> -- <text>	surface.send_text	自然语言纠偏
发 TUI 按键	cmux send-key --surface <id> -- <key>	surface.send_key	回答权限菜单
提交文字	cmux send-key --surface <id> -- enter	surface.send_key	input 后补回车

看 intervention_dispatcher.mjs 的核心实现：

// intervention_dispatcher.mjs --- sendCmuxInput()
if (key) {
  // 按键：cmux send-key --surface <id> -- <key>
  return runCmux(cmux, ['send-key', '--surface', surface, '--', key], 'send_key_failed');
}
// 文字：cmux send --surface <id> -- <input>
const sent = runCmux(cmux, ['send', '--surface', surface, '--', input], 'send_failed');
if (submit) {
  // 文字需补一个 enter 提交
  runCmux(cmux, ['send-key', '--surface', surface, '--', 'enter'], 'submit_failed');
}

Taskforce 的 send key 只接受 9 个官方键：enter/tab/escape/backspace/delete/up/down/left/right（源码里的 CMUX_KEYS 就是这 9 个）。菜单数字默认只是标签 ，不是文本快捷键------应使用方向键导航、读屏确认高亮，再发送 enter；只有当当前 TUI 明确标注数字快捷键时才可按其说明操作。

send 的安全阀：expected_screen_hash 校验。 发送前会重新读屏比对 hash，防止"Chief 看到 A 菜单决定选第 2 项，但决策到达时 Agent 已跳到 B 菜单"------迟到答案不会选错菜单：

// 发送前重新读屏，hash 对不上就拒绝发送（stale_screen）
const current = readCmuxScreen(cmux_surface);
if (actualHash !== expected_screen_hash) {
  return { ok: false, status: 'stale_screen', ... };
}

⚠️ input_delivered 只代表 cmux 把文字送进了终端，不代表 TUI 真执行了。Chief 必须在下一个 tick 看屏幕确认。这就是协议里反复强调的"verify the next screen"。

6.4 relaunch 与取消：进程退出才重启，Ctrl-C 优雅取消

relaunch 的克制 ：relaunch 不靠 cmux 杀进程，而是"等 Worker 自己退出后，重新走 6.1 的 workspace create 拉一个新的"。源码里 relaunch 的前置条件会检查 PID 是否已退出------Thinking 长、屏幕没变、文件没出现，全不是 relaunch 理由。旧 run 目录和 surface 记录会作为恢复证据保留，新 Worker 还会收到 relaunch reason 和 Chief instruction，并被要求先检查当前工作区。

需要注意：relaunch 会启动一个新的 CLI 进程，不会恢复旧 CLI 的完整对话上下文。它接续的是现有项目文件、原任务契约和简短的恢复说明；只有向仍在运行的原 TUI 发送纠偏时，当前会话上下文才会原样保留。

取消一个节点 ：给 surface 发 Ctrl-C（\x03），让 Worker 优雅退出而不是被强杀------这里复用的就是 6.3 的 cmux send API，Ctrl-C 本质是一段控制字符的文本输入：

// workflow_registry.mjs --- stopSurface()
spawnSync(cmux, ['send', '--surface', surface, '--', '\x03'],
  { encoding: 'utf8', timeout: 5000 });

6.5 健康检查：ping 确认 cmux 在线

启动前，Taskforce 用 cmux 的 ping （socket: system.ping）确认 cmux 活着、socket 可达：

// doctor.mjs --- discoverCmux()
const ping = runSubprocess([found, 'ping']);
if (!ping.ok) {
  return { classification: 'cmux_not_accessible', ... };
}

健康检查会先执行 cmux -v，再通过 ping 检查 Automation socket。Taskforce 会区分 cmux 未安装、socket 不可访问，以及疑似被沙箱拦截等情况，并给出对应的 Automation 或沙箱排查建议，而不是笼统报错。这里的版本检查只针对 cmux；setup 不会执行 Worker CLI 的版本查询或模型列表命令。

6.6 决策 JSON：完整可复制的两种 send 用法

最后附上源码里的真实决策格式（来自 programmatic-control.md），你可以照着改：

用法 1：回答权限菜单（发按键）

{
  "batch_id": "obs-abc123",
  "workflow_id": "build-ui",
  "decisions": [
    {
      "node_id": "auth",
      "action": "send",
      "reason": "项目目录内的写入，安全，批准",
      "expected_screen_hash": "a1b2c3...",
      "key": "enter"
    }
  ]
}

按键不需要 submit 字段------submit 只在发 input 文字时才出现。

用法 2：纠偏 Agent 方向（发文字）

{
  "batch_id": "obs-abc123",
  "workflow_id": "build-ui",
  "decisions": [
    {
      "node_id": "ui",
      "action": "send",
      "reason": "偏离目标，要求保留现有 API",
      "expected_screen_hash": "a1b2c3...",
      "input": "保留现有 API，不要重写接口",
      "submit": true
    }
  ]
}

区别：按键用 key，不带 submit；文字用 input + "submit": true。

写到 .taskforce/state/workflows/<workflow-id>/latest_decision_batch.json，下一个 tick 会拿 batch_id 消费它，消费完写入 last_consumed_batch.json 防止重放。

---

七、证据体系：每次干预都有据可查

Taskforce 不只是"跑起来"，它还会把关键状态和有副作用的决策落盘，方便事后复盘。普通、重复的 continue 不会累计写入审计日志，避免生成大量低价值记录。

工作流级别的证据：

.taskforce/state/workflows/<workflow-id>/
  latest_observation_batch.json   # 最新一批观察
  last_consumed_batch.json        # 已消费的 batch（防重放）
  decisions.jsonl                 # send / relaunch / complete 的审计日志
  interventions.jsonl             # 所有 send 干预记录
  recoveries.jsonl                # relaunch 及被拒绝的 relaunch 记录

节点级别的证据：

.taskforce/runs/<workflow-id>/<node-id>/<attempt-id>/
  launch.json        # 启动配置（agent_runner 写入）
  agent.pid          # 进程 PID（tui_exec.sh 写入）
  prompt.txt         # 发给 Worker 的初始 prompt（agent_runner 写入）
  command.json       # 实际执行的命令（agent_runner 写入）
  tui_exec.sh        # TUI 启动脚本（agent_runner 写入）
  result.json        # Worker 声明的结果（Worker CLI 自己写）
  validation.json    # 验证证据（Worker CLI 自己写）
  interventions.jsonl  # 这个节点的干预历史

💡 建议用法：跑完一个复杂工作流后，先翻 decisions.jsonl 查看 Chief 执行过哪些 send / relaunch / complete，再翻 interventions.jsonl 确认输入内容和 cmux 的传输结果。输入是否真的改变了 TUI，需要结合下一批 observation 中的 send_effect（screen_changed / screen_unchanged）判断。

实操时，用编辑器打开 decisions.jsonl，你能看到关键决策的时间戳、node_id、action、reason，以及 send 或 relaunch 的执行结果。重点看 action（send / relaunch / complete）和 reason 两个字段。下面省略了部分 batch 和执行结果字段，只展示核心结构：

{"at":"2026-08-08T12:25:58Z","workflow_id":"build-ui","decisions":[{"node_id":"auth","action":"send","reason":"项目目录内的写入，安全，批准","key":"enter","expected_screen_hash":"c9b59de3..."}]}
{"at":"2026-08-08T12:29:28Z","workflow_id":"build-ui","decisions":[{"node_id":"ui","action":"complete","reason":"核对 goal+代码+测试+validation 全部通过，真正完成"}]}

上面的代码块：decisions.jsonl 的内容示例。普通 continue 不写入该文件；它仍会更新节点的 last_action，供后续周期复审使用。

---

写在最后

用过一段时间多 CLI 协作后，我最大的感触是：当多个独立 CLI 同时参与一个任务时，真正的难点不只是"怎么让 Agent 干活"，还有"哪个 CLI 在等输入、是否跑偏、上下游何时接力、什么时候才算真正完成"。

市面上很多方案把这三件事甩给 LLM 的"判断力"，结果就是------Agent 一卡就重启，一跑偏就重来，一说完成就信。上下文丢了，时间废了，人也麻了。

Taskforce 的做法很朴素但很扎实：定时读取真实终端，能用 send 纠的就不重启，能验证的才标完成。 它把"克制"写进了运行时约束------不为 relaunch 杀活进程、不把 Worker 的完成声明直接当成完成证据，也不要求你迁移到新的 Agent 控制平台。

监督不是控制，而是"在正确的时刻做最小的干预"。对跨 CLI 协作来说，这比不断切终端和重启 Worker 更重要。

如果单个 CLI 和它的 subagent 已经够用，就继续用最简单的方案；如果你确实需要多个主流 CLI 共同完成任务，又受够了手动切终端和反复接力，再装 Taskforce 试试。

---

如果这篇对你有帮助，别忘了 点赞 + 收藏 ❤️。 源码拆解和决策 JSON 我都贴在上面了，建议收藏起来实操时对照着看。有任何问题评论区见，我会一一回复。

项目地址：github.com/lhanyun/tas... 一行安装：npx skills add lhanyun/taskforce --skill taskforce --agent codex --global 完整协议文档：skills/taskforce/references/chief-protocol.md