CodeMachine-CLI
AI编码Agent工作流编排器,让Claude Code/Cursor/Codex按你的流程自动协作
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
AI编码Agent工作流编排器,让Claude Code/Cursor/Codex按你的流程自动协作
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
你有没有过这种感觉:每次打开 Cursor、Claude Code 或者 Codex,准备开工时心里都有一个「标准流程」,却总是重复说同样的话? 「先看看这个 bug 的上下文」「帮我写几个测试用例」「这一块逻辑太乱了,重构一下」「提交前再检查一遍」——这些流程你已经在脑子里跑了无数遍,却还得一遍一遍手动指挥 AI 工具。
CodeMachine 做的事情,就是把这种「脑子里的工作流」提取出来,变成可以保存、复用的配置文件。你定义一次,它帮你自动执行。
CodeMachine 出生于 2024 年底,是一个 TypeScript 编写的 Node.js CLI 工具,核心目标是编排多个 AI 编码代理(AI Coding Agent),让它们按照预定义的流程协同工作。它的定位介于「单一 AI 工具」和「完整 CI/CD 系统」之间——不是替代 Claude Code 或 Codex,而是给这些工具加上工作流的粘合剂。
项目的发起人 moazbuilds 在 GitHub 上持续活跃维护,仓库已有超过 240 个 Fork、8 个 open issues,说明社区参与度不错。Apache-2.0 许可证也意味着商业使用无顾虑。
从技术上说,CodeMachine 通过headless 脚本模式调用这些 AI 编码引擎——它像一位「导演」,启动 Claude Code/Codex/Cursor 的 CLI 进程,传递正确的参数和 Flag,然后通过自己的基础设施(context 传递、事件驱动、状态机)来控制 Agent 的行为。
CodeMachine 的源码结构非常清晰,体现了良好的工程设计:
src/agents/ — Agent 角色定义
chat/ — 处理 Agent 对话交互coordinator/ — 协调多个 Agent 之间的任务分发execution/ — 执行引擎monitoring/ — 运行时监控和日志runner/ — Agent 运行时的生命周期管理session/ — 会话状态管理src/workflows/ — 工作流引擎(最核心的部分)
context/ — 跨 Agent 上下文传递controller/ — 工作流控制器directives/ — 指令解析events/ — 事件总线indexing/ — 代码索引(语义搜索)mode/ — 工作流模式(交互式/全自动)onboarding/ — 新用户引导recovery/ — 异常恢复机制signals/ — 信号处理(优雅退出)state/ — 状态持久化step/ — 步骤定义和执行templates/ — 预设工作流模板run.ts — 主入口preflight.ts — 预检(环境检查)mcp.ts — MCP(Model Context Protocol)集成这种模块化设计的优势是灵活组合:你可以在交互式(完全由你控制每一步)和全自动(定义后完全不管)之间任意切换,中间还有无数种「半自动」状态——这也是文档中所说的「orchestration patterns」。
config/ — 配置层
agent-characters.json — Agent 角色设定(支持 emoji 表情和个性化短语,增添趣味性)main.agents.js — 主要 Agent 行为定义modules.js、placeholders.js — 路径和模块配置这是 CodeMachine 最让人惊喜的地方。安装只需一条命令:
npm i -g codemachine
依赖环境只需要 Node.js >= 20.10.0 或 Bun >= 1.3.3,不需要 Docker,不需要 GPU,不需要配置任何 API Key(因为它调用的 Claude Code、Codex 本身已经自带认证)。
有意思的是,package.json 中还定义了五个平台原生二进制作为可选依赖(Linux x64/arm64、macOS ARM/x64、Windows),这是通过 scripts/build.ts 构建的 Bun 交叉编译产物。这意味着开发者可以直接下载对应平台的二进制文件,无需安装 Node.js 环境——对 DevOps 场景非常友好。
代码库中还有一个 docker/observability/ 目录,说明作者有在实验 Docker 环境下的可观测性集成(如日志聚合、指标收集),但目前并没有提供可直接使用的 Dockerfile 或 docker-compose。这意味着如果你想在 Docker 环境中运行,需要自己包装——这是目前快速部署的最大限制。
场景一:日常 Code Review 自动化
你定义一个工作流:「先用 AI 检查代码风格 → 再用另一个 Agent 查安全漏洞 → 最后自动生成 PR 描述」。定义好后,每次提 PR 前跑一遍,不用再手动操作三个工具。
场景二:新项目脚手架
对于重复性高的项目初始化工作(建仓库、配 CI、写 README),定义一个脚手架工作流,AI Agent 会按照你的标准流程自动完成,不需要每次都从头配置。
场景三:Bug 修复 SOP
「理解 bug → 复现 → 定位根因 → 修复 → 写测试 → 验证」,把这个流程固化成 CodeMachine 工作流,AI 会严格按照步骤执行,减少遗漏。
1. 强依赖外部 AI 工具的可用性
CodeMachine 本身不包含大语言模型,它的存在前提是 Claude Code、Codex 或 Cursor 的 CLI 可用。如果这些工具本身有 bug、版本升级或 API 变更,CodeMachine 的行为也会受到影响。这是一个「元工具」的固有风险。
2. 工作流配置有一定学习成本
虽然 CLI 本身安装简单,但真正发挥价值需要编写 YAML/JSON 工作流配置文件。对于没有 AI 工作流概念的用户,初期需要一定的学习投入。
3. 无 Web UI
对于习惯图形化界面的团队,纯 CLI 的方式可能不够直观。没有可视化的工作流编辑器,也没有实时状态面板。
4. 观测性有限
虽然有 docker/observability 的实验性目录,但核心仓库中并没有内置的日志聚合或指标收集功能。运行时的状态对用户来说相对「黑箱」,尤其是运行长时间工作流时,难以追踪中间状态。
2024-2025 年,AI Agent 赛道非常热,各种「自主 Agent」「多 Agent 协作」概念满天飞。但大多数方案要么过于学术(需要自己搭 LangChain/Semantic Kernel),要么过于庞大(需要整套基础设施)。
CodeMachine 的务实之处在于:它不重新造轮子,而是专注于连接层。它假设 Claude Code、Codex、Cursor 这些轮子已经足够好,它只负责把它们串起来。这种「站在巨人肩膀上」的思路降低了用户的切换成本,也为未来接入更多 AI 编码工具留下了扩展空间。
从增长数据看,2,490 stars 在 AI 开发工具类目中属于中等偏上水平,但考虑到它 2024 年底才起步,增长势头值得关注。
# 安装
npm i -g codemachine
# 或者用 Bun
bun add -g codemachine
# 查看帮助
codemachine --help
# 初始化工作流
codemachine init
作者也提供了 YouTube 演示视频 和详细文档(docs.codemachine.co),建议观看后再决定是否深度使用。