Archon
欲穷千里目,更上一层楼。——王之涣
Archon:把“看心情写代码”的 AI,拎进一条确定性的流水线里
我见过太多 AI 写代码的瞬间:
它像个才华横溢但不太靠谱的“天才队友”——灵感来了能一口气写完一整套功能;灵感没来就跳过计划、忘了跑测试、PR 描述随缘、分支名随缘、甚至把你的模板当空气。
你让它修 bug,它可能直接动手改;
你让它写功能,它可能不做设计;
你让它跑测试,它可能说“应该没问题”;
你让它对齐流程,它可能反问“你要什么格式”。
于是,软件开发这种“靠流程把复杂度压平”的事,在 AI 时代又变回了“靠情绪和运气”。
Archon 看到这一幕,像一个冷静的工头站出来拍了拍桌子:
“别靠模型心情。把流程写出来。按流程跑。” (github.com)
Archon 是谁?
Archon 的一句自我介绍非常干脆:
The first open-source harness builder for AI coding. Make AI coding deterministic and repeatable. (github.com)
它把自己定位成:
- AI coding agents 的工作流引擎:把你的开发流程写成 YAML workflows——规划、实现、验证、代码审查、创�� PR——然后在任何项目里可靠执行。 (github.com)
- 它像 Dockerfile 对基础设施、GitHub Actions 对 CI/CD 那样——Archon 想成为 AI coding workflows 的“流程标准件”。 (github.com)
- 你也可以把它想象成 n8n,但节点不是营销自动化,而是“软件开发”本身。 (github.com)
Archon 不是要发明更会写代码的 AI。
Archon 要做的是:让 AI 只在该聪明的地方聪明,其余地方一律走你定义的轨道。
为什么需要 Archon?(它看不惯 AI 的“随缘”)
Archon 在 README 里把痛点说得很直白:
当你对 AI agent 说“修这个 bug”,接下来发生什么,取决于模型的心情:
可能跳过规划、可能忘了跑测试、可能 PR 描述不按模板写——每次运行都不一样。 (github.com)
Archon 的回应是:
把你的开发过程编码成工作流。
工作流定义阶段、验证关卡、产物;AI 在每一步提供智能,但结构是确定的,而且“属于你”。 (github.com)
你会得到一组非常工程化的收益点:
- Repeatable:同一工作流、同一顺序,每一次都是 plan → implement → validate → review → PR。 (github.com)
- Isolated:每次 run 都会创建自己的 git worktree,并行跑 5 个修复互不打架。 (github.com)
- Fire and forget:启动后你可以去忙别的,回来就是一个带 review comments 的 PR。 (github.com)
- Composable:把确定性节点(bash、测试、git 操作)和 AI 节点(规划、生成、审查)混起来,AI 只在它真能增值的地方出现。 (github.com)
- Portable:工作流放进
.archon/workflows/并提交到 repo,从 CLI、Web UI、Slack、Telegram、GitHub 都能一致执行。 (github.com)
如果把 AI 想象成一位“容易冲动的队友”,Archon 更像一个“流程经理”:
- 你可以让他自由发挥,但必须先过“规划”
- 你可以让他写代码,但必须过“验证”
- 你可以让他生成 PR,但必须先过“审查”和“人工审批闸门”
Archon 长什么样?(一份 YAML,把开发拆成可执行的 DAG)
README 直接给了一个例子:一个工作流会先 plan,然后 implement 循环直到完成,再跑测试、审查、人工批准,最后创建 PR。 (github.com)
1 | nodes: |
这份 YAML 的气质非常“像生产系统”:
- AI 不再是“整段对话里自由游走的幽灵”
- 它是一个节点:有输入、有输出、可循环、可被 gate
- bash / tests / git ops 这种确定性的动作,干脆让确定性的节点去做
- 人类审批也能被编码成一个“必须停下来等我”的闸门
于是 Archon 在旁边像个有经验的领班一样提醒你:
“你不用祈祷 AI 记得跑测试。流程里写死了,它就得跑。”
用起来是什么感觉?(像跟一个会自报进度的工程团队说话)
README 里给了一段“对话式运行画面”:
你说:“Use archon to add dark mode to the settings page”
Agent 说:我会跑 archon-idea-to-pr 工作流,然后开始:
- 创建隔离 worktree、分支命名
- 规划
- 实现(按任务拆分)
- 测试失败就迭代
- 测试通过
- 代码审查
- PR ready (github.com)
这就像你把一句需求扔进一条工厂流水线,流水线上每一站都有监控、有回传、有验收点。
它不承诺“每次都一次写对”。
它承诺“每次都按同样的方式把事情做完”。
Getting Started:两条路,五分钟“全套”,或三十秒“快装”
Archon 在入门上给了两种节奏:
Full Setup(5 分钟):克隆仓库 + 引导式安装向导
它会配置 credentials、平台集成,并把 Archon skill 复制到你的目标项目里。 (github.com)
Prerequisites 在 README 里点名了三样:Bun、Claude Code、GitHub CLI。 (github.com)
Bun:
1 | # macOS/Linux |
GitHub CLI:
1 | # macOS |
Claude Code:
1 | # macOS/Linux/WSL |
然后就是一套非常“像入职流程”的动作:
1 | git clone https://github.com/coleam00/Archon |
接着你对 Claude Code 说一句:“Set up Archon”
向导会带你把 CLI 安装、鉴权、平台选择、把 skill 复制到目标仓库……一条龙走完。 (github.com)
Quick Install(30 秒):只要 CLI,不要向导
如果你已经有 Claude Code 环境,只想要独立 CLI 二进制,README 给了快速安装:
macOS / Linux:
1 | curl -fsSL https://archon.diy/install | bash |
Windows(PowerShell):
1 | irm https://archon.diy/install.ps1 | iex |
Homebrew:
1 | brew install coleam00/archon/archon |
它还提醒:编译版二进制需要 CLAUDE_BIN_PATH,因为 quick-install 的二进制不打包 Claude Code。 (github.com)
1 | # macOS / Linux / WSL |
1 | # Windows (PowerShell) |
开始使用:像在项目里叫一个“流程管家”
完成 setup 之后,README 的建议是:进到你的项目目录,启动 Claude Code,然后直接用自然语言使唤它: (github.com)
1 | cd /path/to/your/project |
然后你可以说:
Use archon to fix issue #42What archon workflows do I have? When would I use each one?
而 Archon 的气质是:
它负责工作流选择、分支命名、worktree 隔离;项目第一次用会自动注册。 (github.com)
你不用跟它争论“你到底跑没跑测试”。
因为测试就是流程的一站,不跑不过闸门。
结尾:Archon 像什么?
Archon 更像一套“开发流程的操作系统层”。
你以前是在跟 AI 聊天:
聊天里混着计划、实现、测试、审查、PR、回滚、补充说明……全靠它记忆和自觉。
现在你是在运行工作流:
你把规则写进 YAML,把关卡写进 DAG,把人类审批写进 interactive gate,把确定性动作交给 bash,把 AI 只放在它该放的位置。
它不保证每次都一枪命中。
它保证每次都走同一条路,最后给你一个能验收、能 review、能合并的结果。 (github.com)
