1. 为什么要在终端里把四个能力串起来GitHub Copilot CLI 最容易被低估的地方是它已经不只是问一句答一句的终端助手。/fleet能把一个复杂请求拆成多个可并行的子任务交给 subagentsAutopilot 能让它在本地终端里连续执行到任务结束Hooks 能在工具调用前后插入校验和审计/delegate则把任务甩给 GitHub 上的 cloud agent 去开分支、提 draft PR。单独用任何一个都不难难的是让它们在同一条工作流里各司其职谁负责拆、谁负责跑、谁负责拦、谁负责托管。这篇就按能直接复制跑通的标准来写。我会给出settings.json和config.toml的骨架、Hooks 脚本片段以及每一步的验证动作。同时把模型通道统一到 TaoToken 的 Key/API 上这样/fleet拆出来的多个 subagent、Autopilot 的连续调用、/delegate的远端任务都走同一个入口额度、日志、切换模型都好管。适合已经在用 Copilot CLI、但还没把多智能体链路跑顺的开发者也适合想先看清楚边界再决定要不要上 Autopilot 的团队。核心检索词先摆出来GitHub Copilot CLI 的/fleet负责并行编排Autopilot 负责本地持续执行Hooks 负责安全边界/delegate负责远端 PR 托管。四者配合的关键不是功能叠加而是先 Plan 收范围再决定本地跑、并行跑还是远端跑。2. 前置TaoToken 统一 Key 与 CLI 环境2.1 为什么先接统一 KeyCopilot CLI 的/fleet会按子任务数量发起多次模型交互Autopilot 会连续调用/delegate在远端也会消耗额度。如果每个环节用不同的 Key排查到底哪一步烧了额度会很痛苦。把模型通道统一到 TaoToken好处是一个 Key 覆盖对话、编码、Agent 场景切换模型只改配置不改代码出问题看一处日志。TaoToken 官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 这个不加 UTM。先注册拿到 Key后面配置里会用到。2.2 环境准备清单在动手前确认这几样Node.js 18、Git 已配置用户信息、jq已安装Hooks 脚本要用它解析 JSON、以及一个可写的项目目录。jq在 macOS 上brew install jqUbuntu 上apt install jqWindows 建议在 WSL 里操作避免 shell 脚本路径问题。注意Hooks 脚本依赖 bash 和 jq如果你在纯 PowerShell 环境建议先切到 WSL 或 Git Bash否则preToolUse的拦截逻辑不会按预期生效。2.3 目录结构先定好我习惯在项目根目录建这样一套结构后面所有配置都往里放your-project/ ├── .github/ │ └── hooks/ │ ├── policy.json │ ├── scripts/ │ │ ├── block-dangerous-command.sh │ │ └── restrict-edit-path.sh │ └── logs/ │ └── audit.jsonl ├── .copilot/ │ ├── settings.json │ └── config.toml └── src/ tests/ docs/.github/hooks/放 Hooks 策略和脚本.copilot/放 CLI 的 settings 和模型通道配置。分开是为了让 Hooks 能跟着仓库走、被团队共享而 Key 相关配置留在本地或 CI 的 secret 里。3. 可复制配置settings.json 与 config.toml 骨架3.1 settings.json把 Autopilot 和 Hooks 的开关写死.copilot/settings.json用来固定 Autopilot 的连续执行上限、Hooks 的启用状态以及默认的模型通道。下面这份可以直接改{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, defaultModel: claude-sonnet-4-20250514 }, autopilot: { enabled: true, maxContinues: 10, requirePlanFirst: true }, hooks: { enabled: true, policyFile: .github/hooks/policy.json }, fleet: { maxSubagents: 4, isolateByDirectory: true } }几个参数值得解释。apiKeyEnv指向环境变量而不是明文写 Key这样提交到仓库也不会泄露。maxContinues是 Autopilot 的连续执行上限设 10 意味着最多自动跑 10 轮就停下来等你确认防止无人看管时死循环。requirePlanFirst强制先出计划再执行这是后面/fleet和 Autopilot 配合的基础。isolateByDirectory让/fleet拆出的 subagent 尽量按目录隔离减少并行改同一文件的冲突。3.2 config.toml模型通道与超时.copilot/config.toml管的是更底层的连接参数[provider] name taotoken base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY timeout_sec 120 max_retries 3 [models] default claude-sonnet-4-20250514 fast claude-haiku-4-20250514 code claude-sonnet-4-20250514 [delegate] remote true draft_pr true branch_prefix copilot/delegate- [logging] level info audit_file .github/hooks/logs/audit.jsonltimeout_sec设 120 是因为/fleet的 subagent 和 Autopilot 的长任务单次调用可能较久太短会频繁超时重试。max_retries给 3 次容错。[delegate]段里draft_pr true保证远端任务只开 draft PR不会直接合并留给你 review 的空间。3.3 设置环境变量Key 通过环境变量注入别写进配置文件export TAOTOKEN_API_KEY你的_TaoToken_KeyWindows WSL 或 Git Bash 同样用export。如果要在 CI 里跑把 Key 放进仓库 secret再在 workflow 里映射成TAOTOKEN_API_KEY。4. Hooks 脚本危险命令拦截与路径限制4.1 policy.json 注册 preToolUse.github/hooks/policy.json决定哪些节点触发脚本。先只挂preToolUse这是拦截危险操作最有效的时机{ version: 1, hooks: { preToolUse: [ { type: command, bash: .github/hooks/scripts/block-dangerous-command.sh, cwd: ., timeoutSec: 10 }, { type: command, bash: .github/hooks/scripts/restrict-edit-path.sh, cwd: ., timeoutSec: 10 } ] } }两个脚本按顺序执行第一个拦危险命令第二个限制可编辑路径。timeoutSec给 10 秒脚本本身只做字符串匹配和日志写入不会超时。4.2 危险命令拦截脚本.github/hooks/scripts/block-dangerous-command.sh#!/bin/bash set -euo pipefail INPUT$(cat) TOOL_NAME$(echo $INPUT | jq -r .toolName // .tool_name // empty) TOOL_ARGS$(echo $INPUT | jq -c .toolArgs // .tool_input // {}) mkdir -p .github/hooks/logs echo $(date -Iseconds) tool$TOOL_NAME args$TOOL_ARGS .github/hooks/logs/audit.jsonl if echo $TOOL_ARGS | grep -qE rm -rf /|mkfs|dd if|curl .*\| bash|wget .*\| sh|DROP TABLE|terraform destroy|kubectl delete; then echo {permissionDecision:deny,permissionDecisionReason:Blocked by repository security policy} exit 0 fi echo {permissionDecision:allow} exit 0脚本先无条件把每次工具调用写进audit.jsonl这是审计的基础。然后匹配一组高危模式整盘删除、格式化、管道执行远程脚本、删表、销毁基础设施、删 K8s 资源。命中就返回deny并给出原因Copilot 会停止该工具调用。没命中返回allow。记得加执行权限chmod x .github/hooks/scripts/block-dangerous-command.sh4.3 路径限制脚本.github/hooks/scripts/restrict-edit-path.sh#!/bin/bash set -euo pipefail INPUT$(cat) TOOL_NAME$(echo $INPUT | jq -r .toolName // .tool_name // empty) TOOL_ARGS$(echo $INPUT | jq -c .toolArgs // .tool_input // {}) PATH_ARG$(echo $TOOL_ARGS | jq -r .path // .filePath // empty) if [[ $TOOL_NAME ~ edit|create|write ]] [[ -n $PATH_ARG ]]; then if [[ ! $PATH_ARG ~ ^(src/|tests/|test/|docs/) ]]; then echo {permissionDecision:deny,permissionDecisionReason:Only src/, tests/, test/, and docs/ can be edited} exit 0 fi fi echo {permissionDecision:allow} exit 0这个脚本只放行src/、tests/、test/、docs/下的写操作。Autopilot 想改部署脚本、CI 配置、数据库迁移文件时会被拦下。团队刚上 Hooks 时这三类危险命令、敏感目录、审计日志就够用了别一上来做太复杂的规则。5. 验证让 /fleet、Autopilot、Hooks、/delegate 协同跑通5.1 第一步验证 Hooks 真的在拦先单独测 Hooks别急着上/fleet。在项目里跑一条会被拦的命令copilot -p 运行 rm -rf /tmp/test-cleanup 清理临时目录如果 Hooks 生效Copilot 会收到deny不会真的执行。同时检查审计日志tail -n 5 .github/hooks/logs/audit.jsonl应该能看到刚才那次工具调用的记录。再测路径限制copilot -p 把 deploy/production.yaml 里的副本数改成 5预期被拦因为deploy/不在白名单里。这两条过了说明 Hooks 边界是活的。5.2 第二步验证 /fleet 的并行拆分用一个能明确拆分的任务测/fleetcopilot -p /fleet 为当前项目补充测试 1. 为 src/auth 下的认证逻辑补单元测试只修改 src/auth 和 tests/auth 2. 为 src/billing 下的订阅逻辑补单元测试只修改 src/billing 和 tests/billing 3. 为 src/api/orders 下的订单接口补集成测试只修改 src/api/orders 和 tests/orders 4. 三部分完成后统一运行测试并汇总失败项观察点有三个Copilot 是否把任务拆成了三个独立子任务、每个 subagent 是否只动自己目录、最后是否汇总了测试结果。如果它把三个任务串成一条线跑说明任务描述里的依赖关系不够清晰或者maxSubagents设得太小。提示/fleet拆得越多模型调用次数越多额度消耗也越大。复杂任务能省时间但不一定省额度。文件冲突也要提前防让 subagent 按目录隔离是最省事的做法。5.3 第三步验证 Autopilot 的连续执行先让 Copilot 出计划再进 Autopilotcopilot -p 先进入 Plan mode分析当前失败测试和相关代码。只关注 src/auth 和 tests/auth。不要修改代码。输出修复计划包含要改的文件、原因和验证命令。确认计划合理后copilot --autopilot --max-autopilot-continues 10 -p 按照刚才的计划进入 autopilot 执行。只修改计划中列出的文件。完成后运行 npm test -- tests/auth。--max-autopilot-continues 10和 settings.json 里的maxContinues是双重保险。跑的时候盯一下它是否只改了计划里的文件、是否在改到deploy/时被 Hooks 拦下、是否在 10 轮内收敛。如果它开始改计划外的文件说明计划约束没写死回去把只修改计划中列出的文件再强调一遍。5.4 第四步验证 /delegate 的远端托管/delegate适合能变成 PR 的任务copilot -p /delegate 为订单导出功能补充集成测试只覆盖 CSV 和 PDF 两种导出路径完成后打开 draft PR也可以用前缀简写。执行后 Copilot 会要求把未暂存改动作为 checkpoint 提交到新分支然后 cloud agent 在远端开 draft PR 并后台工作。验证动作拿到 PR 链接后检查分支前缀是否是copilot/delegate-、PR 是否是 draft 状态、agent session 链接能否打开。这三样都对说明远端链路通了。注意这里入口是/delegate不是/compile。别写错命令否则任务不会交给 cloud agent。5.5 四者协同的完整链路把上面四步串成一条命令流就是推荐的组合方式# 1. 先 Plan 收范围 copilot -p 进入 Plan mode分析需要补测试的模块输出计划不要改代码。 # 2. 计划含多个互不依赖模块时用 /fleet 并行 copilot -p /fleet 按刚才的计划把互不依赖的模块分配给 subagents 并行补测试。 # 3. 进入 Autopilot 连续执行Hooks 全程拦截 copilot --autopilot --max-autopilot-continues 10 -p 按计划执行只改计划内文件完成后统一跑测试。 # 4. 适合 PR 审查的部分交给远端 copilot -p /delegate 把订单导出测试的改动整理成 draft PR这条链路里Plan 负责收敛/fleet负责并行Autopilot 负责持续Hooks 负责边界/delegate负责托管。每一环都有明确的验证动作出问题能定位到具体哪一步。6. 本篇常见错排查6.1 Hooks 不生效最常见的原因是脚本没有执行权限或者policy.json路径写错。先确认ls -l .github/hooks/scripts/如果权限位没有x补上chmod x。再确认settings.json里hooks.policyFile指向的路径和实际文件一致。还有一个坑是jq没装脚本第一行jq就报错Hooks 静默失败。跑jq --version确认。6.2 /fleet 拆不动或拆得太碎拆不动通常是任务描述里没有明确的交付物边界。把优化整个项目改成为 src/auth 补单元测试、为 src/billing 补单元测试这种按目录和产出划分的写法。拆得太碎则是maxSubagents设太大或者任务本身有强依赖却被强行并行。有依赖关系的任务比如先改 schema 再改模型用普通 Plan 加 Autopilot 更稳别硬塞给/fleet。6.3 Autopilot 跑飞或提前停跑飞一般是--yolo权限给太大又没 Hooks 兜底。先配 Hooks 再开 Autopilot顺序别反。提前停则可能是maxContinues设太小或者单次调用超时。把timeout_sec调到 120 以上maxContinues按任务复杂度给 10 到 20。6.4 /delegate 没开 PR检查config.toml里[delegate]段的remote true和draft_pr true是否都在。另外/delegate要求先把未暂存改动提交到新分支如果工作区有冲突或没提交任务会卡在 checkpoint 这一步。先git status确认工作区干净。6.5 模型通道报 401 或超时401 基本是TAOTOKEN_API_KEY没设或设错。用echo $TAOTOKEN_API_KEY确认环境变量在当前 shell 里可见。超时则检查base_url是否写成了https://taotoken.net/api注意结尾没有多余斜杠以及网络能否正常访问。如果/fleet的多个 subagent 同时请求导致偶发超时把max_retries提到 3 以上。7. 接入与后续按场景选对入口排障和接入相关的问题优先看 API Keys 和接入文档把 Key、base_url、环境变量这三样对齐大部分 401 和超时都能解决API Keys 管理入口 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。想先验证模型通道是否通、对比不同模型在/fleet子任务上的表现用模型对话入口最快https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。如果你打算长期用 Copilot CLI 跑编码和 Agent 任务尤其是/fleet并行加 Autopilot 连续执行这种高频调用场景Coding Plan 比按次调用更划算额度也更可控https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。Claude Code 和 Anthropic 相关通道的配置参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。我自己的经验是别一上来就把四个能力全开。先用 Hooks 把边界立住再单独跑通/fleet然后加 Autopilot最后才上/delegate。每加一个能力都回头确认前一个的验证动作还能过。这样链路是稳的出问题也知道该看哪一段日志。