coding-agent（编码代理Skill）：用一条 bash 命令驱动 Codex、Claude Code 等编码代理，把 AI 编程变成可编排的后台任务
- 一个技能统一四个代理：coding-agent 让 Codex CLI、Claude Code、OpenCode、Pi Coding Agent 全部通过同一个 bash 入口调用，不用为每个工具记一套不同的用法。
- 关键开关只有一个：
pty:true。编码代理是交互式终端程序，不加伪终端就会出现输出错乱、颜色丢失甚至进程挂起。 - 三种使用形态：一次性任务用
exec，长任务用background:true加process工具监控，批量任务用 git worktree 并行开多个代理。 - 适合"编排型"使用者：不追求自己手写补丁，而是把编码代理当作可调度、可监控、可终止的后台进程来统一管理。
- 上手门槛集中在环境侧：本机必须已安装至少一个受支持的编码代理 CLI，技能本身不负责替你装代理。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
这个技能的中文名是「编码代理Skill」，英文名是 coding-agent，技能 ID 为 13596。它的定位非常直白：把市面上几个主流编码代理（Codex CLI、Claude Code、OpenCode、Pi Coding Agent）统一封装成一个可以用 bash 命令程序化控制的执行单元。
它解决什么问题？
日常用 AI 写代码时，痛点往往不在模型本身，而在"调度"环节：每个代理的调用参数不一样、交互式 CLI 在自动化环境里容易挂起、长任务跑起来后看不见进度、想同时修 5 个 issue 只能一个个排队等。coding-agent 把这些琐碎问题收敛成一套统一的调用约定——用 bash 的 command 参数下发任务，用 pty 保证终端正常，用 background 加 process 工具做会话监控，用 workdir 限定上下文范围。
一键安装的思路与步骤
- 确认安装前提：技能元数据中的
requires.anyBins明确要求环境中至少存在claude、codex、opencode、pi这四个可执行文件之一。也就是说，先要在本机安装好至少一个编码代理 CLI（各代理的安装方式请以其官方说明为准）。 - 装好技能本体：在支持该技能的环境中找到技能安装入口，检索「coding-agent」或技能 ID 13596 后一键安装；具体入口、命令与是否需要授权，以官方说明为准。
- 确认 PTY 能力可用：该技能的核心依赖是 bash 工具的
pty参数与 process 工具的会话管理能力，安装后应能调用到这两组能力。 - 验证是否生效：在一个临时 git 仓库里跑一次最小任务，例如用 Codex 执行一句简单提示，能正常返回结果即代表链路打通；如果输出乱码或卡住，优先检查是否漏了
pty:true。
该技能的主要功能和特点
- 四大编码代理统一入口：Codex CLI、Claude Code、OpenCode、Pi Coding Agent 都通过 bash 调用，切换成本极低，用户点名用哪个就用哪个。
- 强制 PTY 模式：技能反复强调
pty:true，这是它与"裸调命令行"最大的差别——编码代理本质是交互式终端应用，没有伪终端就会输出损坏或挂起。 - 前台 / 后台双模式：短任务前台跑完即走；长任务用
background:true启动并拿到sessionId，随时查看进度而不打断执行。 - 完整的会话控制面：process 工具提供
list（列出会话）、poll（是否仍在运行）、log（读取输出，支持偏移和条数限制）、write（写原始数据到 stdin）、submit（输入并回车）、send-keys（发送按键或十六进制字节）、paste（粘贴文本）、kill（终止会话）八种操作。 - 上下文收窄机制：
workdir让代理只在指定目录内工作，避免它到处乱读无关文件；技能里还特别提醒不要在主实例目录中启动代理。 - 并行编排能力：配合 git worktree 可以同时开多个代理修不同 issue，最后各自推分支、开 PR、清理 worktree，形成流水线。
- 进度与完成通知机制：技能给出了明确的通知规范——启动时发一条短消息，之后只在里程碑、提问、报错、完成这四类事件时更新；长任务还可以在提示末尾附加唤醒命令，让代理一完成就立刻触发通知，而不用等下一轮心跳。
和"自己写脚本调 CLI"相比，它的优势在于把这些容易踩坑的细节（PTY、git 仓库依赖、后台会话管理、终止策略）固化成了一套可复用的规则。
如何使用该技能？
第 1 步：明确任务类型，选对运行模式
一次性问答用前台执行；需要几分钟以上的构建、重构、审查，用后台加监控。
第 2 步：一次性任务的标准写法
Codex 要求必须处在受信任的 git 目录内，所以草稿任务可以先建一个临时仓库：
SCRATCH=$(mktemp -d) && cd $SCRATCH && git init && codex exec "你的提示"
在真实项目里则指定工作目录并开 PTY：
bash pty:true workdir:~/Projects/myproject command:"codex exec '为 API 调用添加错误处理'"
第 3 步：长任务用后台模式
bash pty:true workdir:~/project background:true command:"codex exec --full-auto '构建贪吃蛇游戏'"
命令会返回 sessionId，之后用 process action:log sessionId:XXX 看输出、process action:poll sessionId:XXX 判断是否结束、process action:submit sessionId:XXX data:"yes" 回答代理的提问、必要时 process action:kill sessionId:XXX 终止。
第 4 步：按代理切换调用方式
- Claude Code：
bash pty:true workdir:~/project command:"claude '你的任务'" - OpenCode：
bash pty:true workdir:~/project command:"opencode run '你的任务'" - Pi：先
npm install -g @mariozechner/pi-coding-agent，再bash pty:true command:"pi -p '总结 src/'"；也支持--provider/--model指定不同服务商与模型。
第 5 步：批量任务用 worktree 并行
先 git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*' 拉取所有 PR 引用，然后为每个 PR 各起一个后台代理执行审查，全部用 pty:true，最后用 process action:list 统一查看，审查结论通过 GitHub CLI 回写到对应 PR。
第 6 步：验收输出
前台任务直接看返回文本；后台任务读 log 输出，确认改动内容和落地位置，再决定是否合并或清理。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装 / 使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| coding-agent（本技能） | 编码代理的统一编排层 | 四大代理统一入口、PTY 强制、后台会话管理、并行 worktree | 需已装任一代理 CLI；记住 pty:true 即可上手 |
长任务托管、批量 PR 审查、多 issue 并行修复 | 优势是统一与可控；不足是依赖外部代理，本身不产出模型能力 |
| 直接使用 Codex CLI | 单一命令行编码代理 | exec 一次性执行、--full-auto、--yolo、review |
需自行安装并配置，必须处在 git 仓库内 | 单点任务、代码审查 | 优势是最直接；不足是长任务缺少统一监控与多代理切换 |
| 直接使用 Claude Code | 交互式终端编码代理 | 自然语言下发任务、目录级上下文 | 需自行安装并登录 | 会话式重构、探索式开发 | 优势是交互体验好；不足是自动化与并行需要自己搭脚手架 |
| IDE 内置智能体（如编辑器插件） | 图形化 AI 编程 | 行内补全、选区改写、对话式修改 | 装插件即可，门槛最低 | 日常小步修改、边写边改 | 优势是零学习成本；不足是难做后台长任务与批量流水线 |
该技能的典型应用场景与实际体验情况
场景一：独立开发者的长任务托管
痛点是想让代理"把整个功能做完"，但不敢关掉终端。用 background:true 加 workdir 启动后，开发者可以去处理别的事，回来用 process action:log 一读就知道进度。实际体验是：只要记得加 pty:true，整个流程非常顺；一旦漏掉，最典型的现象就是输出残缺或进程像"卡死"一样不动。
场景二：开源维护者批量审查 PR
痛点是一个个切分支、跑审查、写评论极其耗时。做法是为每个 PR 克隆到临时目录或建 worktree，各起一个 Codex 后台会话执行 diff 审查，再统一收集结论回写。实际体验上，瓶颈往往从"等审查"变成了"看结论"；需要注意的是必须克隆到临时文件夹，绝不能在主项目目录里切分支审查。
场景三：团队并行处理多个 issue
痛点是小问题堆积但串行处理太慢。做法是用 git worktree add -b fix/issue-NN 为每个 issue 建独立工作区，各起一个带 --yolo 的后台代理完成修改、提交、推送，再统一开 PR 并清理 worktree。实际体验是吞吐量提升明显，但需要额外留意代理的提问——用 poll 发现它在等确认时，及时 submit 回一句，否则会白等。
场景四：在隔离环境中做实验性尝试
痛点是不想让代理在正式工程里乱动。做法是用 mktemp -d && git init 建临时仓库，跑一次性提示做验证。实际体验是安全性好、清理方便；同时 elevated 参数可以决定是跑在沙箱还是主机上，需按权限策略谨慎选择。
该技能能为用户带来的价值
第一，把"会用四个工具"变成"会用一套方法"。 之前每换一个编码代理就要重学一遍参数和交互习惯，现在调用结构基本一致，只换命令名。
第二，把不可控的交互式程序变成可编排的后台任务。 PTY、后台会话、日志轮询、按键输入、强制终止这一整套能力，意味着编码代理第一次可以像普通进程一样被调度——这才是自动化流水线的前提。
第三，并行带来可量化的吞吐提升。 单个 PR 审查可能需要若干分钟，但十个 PR 并行跑时，总耗时接近"最慢的那一个"而不是"十个之和"。对于 issue 堆积的项目，这种从串行到并行的转变收益最直接。
第四，降低了踩坑成本。 诸如"Codex 必须在 git 仓库内运行"“不要在主实例目录启动代理”"不要在项目目录里切分支做审查"这类经验，被固化成了技能规则，新用户不必用踩坑的方式重新学一遍。
长期价值在于形成可复用的协作范式：任务下发 → 后台执行 → 监控反馈 → 完成通知 → 结果回写。当代理完成时通过唤醒命令即时通知，等待时间从"下一轮心跳"压缩到"几秒钟"，这种人机协作节奏的改善，是日常使用中最容易被感知的部分。
常见问题 FAQ
Q1：这个技能怎么安装？
需要两步：第一步确认环境中已有 claude、codex、opencode、pi 中至少一个可执行文件（各代理安装方式以其官方说明为准）；第二步在技能入口检索「coding-agent」或技能 ID 后安装。安装完成后建议先跑一次最小任务验证链路，具体入口与授权方式以官方说明为准。
Q2：为什么一直强调 pty:true？不加会怎样？
因为 Codex、Claude Code、Pi 本质都是交互式终端应用。不加 PTY，轻则输出损坏、丢失颜色，重则代理直接挂起，你还以为是模型慢。技能里把这一条列为第一规则：运行编码代理时始终使用 pty:true。
Q3：收费吗？ 技能本身是调用封装层，不额外引入模型费用；实际的调用成本取决于你所使用的编码代理及其背后的模型服务计费方式，请以对应服务的官方说明为准。
Q4：适合谁用？ 适合已经把 AI 编码代理纳入日常流程、并希望进一步做"编排"的开发者与团队：需要长任务托管、批量 PR 审查、多 issue 并行修复的人收益最大。如果只是偶尔做几行代码补全，用编辑器内置智能体更省事。
Q5：和直接用 Codex CLI 或 Claude Code 有什么区别？ 直接用是"单点工具"，本技能是"调度层"。它不改变代理本身的能力，但补齐了统一入口、PTY 保障、后台会话管理、并行编排与进度通知这几块。竞品选择上：追求最简就用单一 CLI，追求图形化就用 IDE 插件，追求批量与自动化就选本技能。