ORCH — AI 智能体编排器
一条命令行工具，让多个 AI 智能体在隔离的 git worktree 中并行开发同一代码库，全程无需人工值守。
SKILL.md 声明工作树隔离与强制审核门，状态本地存储在 .orchestry/，数据流披露较清楚；但默认 approval-policy 为 auto，且仓库测试显示 Grok/Antigravity 适配器以 bypassPermissions/--dangerously-skip-permissions 运行代理，自主模式与 org deploy 会自动生成并执行任务，缺少强制用户确认与回滚说明，故仅给中间分。
文档内部自洽、命令引用完整、含故障排查（orch doctor、stall timeout、锁保护），仓库含 CI 工作流与大量测试文件；但静态审查无法执行，1954 测试主要覆盖引擎而非技能文档中的 CLI 关键路径，失败反馈质量未经证实，受静态上限约束给 9。
frontmatter 触发词明确、目标/任务边界章节清晰、适配器范围声明良好；但无中文支持说明，核心功能依赖 Claude/Codex 等海外 CLI 与 API，对中国大陆网络可达性存在实质依赖风险，扣除相应分数。
结构分层好、有 LICENSE、版本化发布流程与 CHANGELOG 提取脚本、SECURITY.md；但技能文档本身无版本/变更记录、无 FAQ、示例含硬编码 agent ID（agt_T0uF5KP），维护责任仅笼统为社区，扣分。
CLI 参考与工作流示例详尽、可操作性强，声明价值清晰；但静态审查无法验证实际产出，README 含营销化示例输出（$4.20、48 小时 MVP）未经验证，比较优势证据有限，受静态上限约束给 6。
仓库内含可审计的测试代码（battle test、PTY e2e、adapter e2e）与 CI 配置，可部分交叉验证；但技能路径本身的关键命令未被这些测试直接覆盖，执行结果未独立复现，受静态上限约束给 4。
- 默认 auto 审批策略与适配器权限绕过标志意味着代理可能在无人确认下执行命令，建议用户使用 --approval-policy suggest/manual 并审查 org deploy 的后果
- 核心依赖海外 LLM CLI/API，中国大陆网络环境可能不可用，技能未提供中文支持
- 技能文档的 CLI 引用未经执行验证，实际命令行为可能与文档不符；发布者身份未经验证
这个 Skill 能做什么，适合哪些场景？
ORCH（npm 包 @oxgeneral/orch）是一个开源的 AI 智能体编排运行时，用于在终端中协调多个 LLM 智能体并行工作。它以命令行和 TUI 仪表盘为核心，将目标自动分解为任务、分配给不同适配器的智能体（Claude、Codex、Cursor、OpenCode、Pi、Grok、Antigravity 以及任意 shell 命令），并通过强制审查状态机保护主分支。所有状态以 YAML/JSON 文件存放在项目的 .orchestry/ 目录，无需数据库或云服务。它还提供 15 个预置智能体模板和 10 个预建团队模板，可一条命令部署完整部门，适合独立开发者用团队的速度出货。
初始化 .orchestry/ 项目状态目录；创建和管理智能体（指定适配器、模型、推理强度、审批策略、工作区模式）；添加任务并指定优先级、文件范围 glob、依赖和自动审查标准；将高层目标交给主管智能体自主分解为任务；通过 git worktree 隔离各智能体写入，按 todo → in_progress → review → done 状态机流转；支持智能体间消息、广播和共享上下文；提供 TUI 仪表盘、orch run --watch 持续编排、orch serve 无头守护进程（JSON 结构化日志，支持 pm2/systemd 和 --once CI/CD 模式）；自动重试失败任务并检测卡死（僵尸）进程。
- 独立创始人在睡觉前设定一个目标（如实现 OAuth2），让 CTO 智能体分解为任务、多个后端/QA/审查智能体并行完成，早上醒来审查拉取请求
- 希望用一条命令部署完整评审团队的团队负责人：orch org deploy pr-review-corp 自动审查每个 PR 的安全性、性能与风格
- 进行 JS 到 TS 大规模迁移或把测试覆盖率从 40% 提到 80% 的工程团队，用 migration-squad 或 test-factory 模板和迭代式目标驱动执行
- 非工程场景：用 content-agency、data-lab 或 sales-machine 模板编排写作、数据分析和销售外联流程，通过 shell 适配器接入任意 CLI 工具
- 需要在服务器上 7×24 运行智能体的运维人员，用 orch serve 守护进程配合 pm2/systemd 和 JSON 日志接入监控体系
- 在 CI/CD 流水线中以 orch serve --once 模式处理当前任务并按退出码报告成败
这个 Skill 有哪些优点和局限？
- 每个智能体在独立 git worktree 工作，主分支在你明确批准前不会被触碰，强制审查环节杜绝未经审核的代码合入
- 零基础设施：无数据库、无云端、无 Docker，全部状态为本地 .orchestry/ 下的 YAML/JSON 文件
- 8 种适配器（Claude、OpenCode、Codex、Pi、Cursor、Grok、Antigravity、Shell），shell 适配器可将任意 CLI 工具变成受管智能体
- 10 个预建团队模板一条命令部署完整部门，覆盖工程、内容、数据、销售等非工程流程
- 自动重试（指数退避）、卡死检测、崩溃后自动清理陈旧状态；orch serve 支持无头守护、JSON 日志和 CI/CD 一次性模式
- MIT 开源，1954 个测试通过，核心引擎与 CLI/TUI 分层可作为库导入
- 每个并发智能体约需 300 MB 内存，6 个智能体约 2 GB，低配机器扩展受限
- 成本取决于所调用的 AI API 用量，README 中的 $4.20 示例仅供参考，实际费用因任务复杂度而异
- 平台支持仅列出 macOS、Linux、WSL2，原生 Windows 不在支持之列
- 智能体质量和自主目标分解的效果高度依赖所选模型与角色提示词，源材料未提供独立基准测试
- SKILL.md 使用了 Claude Code 专属的 allowed-tools 前置字段，移植到其他 Agent Skills 客户端需修改
如何安装这个 Skill？
前提：macOS、Linux 或 WSL2，Node.js >= 20。安装：npm install -g @oxgeneral/orch。然后在项目目录运行 orch，会自动初始化并打开 TUI 仪表盘。资源需求：ORCH 本体约 120 MB，每个并发智能体进程约 300 MB 内存。故障排查用 orch doctor。说明：仓库未单独记录 Skill 文件的安装路径，Claude Code 用户安装后 /orch 技能据 README 称自动可用。
如何使用这个 Skill？
典型流程：1) orch init --name "项目名" 初始化；2) orch agent shop 挑选预置智能体，或 orch org deploy startup-mvp --goal "..." 一键部署团队；3) orch task add "修复登录崩溃" -d "描述" --scope "src/auth/**" -p 1 添加任务，或 orch goal add 让主管智能体自主分解；4) orch run --all --watch 启动编排，或 orch tui 交互式查看；5) 任务进入 review 后用 orch task approve/reject 处理；6) 编程解析输出时始终加 -- 标志。在 Claude Code 中直接输入 /orch deploy a team to refactor the auth module and add tests 即可用自然语言驱动。
这个 Skill 与同类方案有什么区别？
README 将 ORCH 与 Paperclip 对比：Paperclip 需要 PostgreSQL、Web 服务器和云端配置，ORCH 只需 npm install —— 同样面向零人公司愿景，但 ORCH 是终端优先、文件存储、零基础设施的 MIT 许可版本。