当你的AI代码助手开始「集体失忆」，这个22k Star的开源项目给了一记响亮耳光

故事是这样的。

上个月我让Claude Code帮我重构一个React组件，聊了四十多轮，它突然问我「你用的是哪个框架？」我当时就愣住了， dude，我们聊了快一个小时了你问我是哪个框架？？？

这不是个例。你如果经常用AI写代码，一定遇到过类似的场景。AI助手有时候就像一个记忆力只有7秒的金鱼，前面说过的话后面全忘光。更离谱的是，你今天让它加个暗黑模式写得很漂亮，明天同样的需求，代码结构完全不同，像换了一个人写的。

坦率的讲，这个问题困扰我很久了。AI太自由了，自由到不可控。

直到最近我在GitHub上刷到一个项目，叫Archon。22.5k Star，MIT协议，作者Cole Medin几乎每天都在更新。我花了两天时间研究它的源码和文档，然后又花了一天时间在自己项目上跑了几轮测试。

说真的，我被震撼到了。

这玩意不是在帮你写代码，而是在教AI如何像一个有十年经验的高级工程师一样，系统性地、有条理地写代码。它解决的核心问题不是「AI能不能写代码」，而是「AI写代码的过程能不能被管控」。

说到这个，需要先聊一下AI编码工具目前最大的痛点。

当前市面上99%的AI编码工具，从Cursor到Claude Code到Windsurf，说到底都是「对话式编程」。你跟AI说一句话，它回你一段代码。这个模式的问题是什么呢？是上下文。AI的上下文窗口是有限的，当任务变复杂，对话变长，AI就会开始丢东西。它可能忘了你前面说的某个约束条件，可能忘了跑测试，可能写出一个完全忽略你项目模板的PR描述。

每次运行的结果都不一样。这不是bug，这是大语言模型的天然特性，概率模型嘛，每次推理都是独立的采样过程。

但在工程实践中，这种「不确定性」是致命的。你想象一下，一个工程师今天写的代码和明天写的完全不同风格，而且他自己还不记得昨天写了什么。你敢让他上线吗？

Archon的做法特别有意思。它没有试图让AI变得更聪明，而是给AI套上了一层「流程约束」。

你可以把Archon理解成一个工作流引擎。就像Dockerfile把基础设施变成了可重复的配置文件，GitHub Actions把CI/CD变成了可编排的流水线，Archon把AI编码的整个流程变成了可以用YAML定义的工作流。

规划，实现，测试，审查，提PR。每一步都是一个节点，节点之间有明确的依赖关系，构成一个有向无环图。AI在每个节点上发挥智能，但整个结构是确定性的，是你定义的，是你拥有的。

同样一个任务跑10次，10次的流程高度一致。这就是Archon最核心的价值。

我自己第一次看到这个设计的时候，脑子里冒出的第一个念头是，这不就是给AI请了一个项目经理吗？

后来仔细想想，比项目经理更狠。项目经理还会忘事，YAML不会。

这块需要注意一下Archon的节点设计，我觉得是整个项目最精妙的部分。它把节点分成了四类。

AI节点，让Claude去做规划、写代码、做审查，发挥AI最擅长的推理和生成能力。确定性节点，跑Bash测试、Git操作、代码lint，这些不需要AI参与，该是什么结果就是什么结果。循环节点，测试失败了？自动迭代修复，直到通过为止。条件分支，是个Bug就走修复流程，是个新功能就走规划流程。

这四类节点组合在一起，就能搭出几乎任何开发流程。而且整个流程是声明式的，写在YAML里，提交到Git，整个团队共享同一套流程。

我有时候觉得，软件工程这么多年，最核心的追求其实就一个字，确定性。

从最早的瀑布模型到敏捷开发，从手工部署到CI/CD，从裸机到容器化，每一次技术跃迁的本质都是在把「不确定的东西」变成「确定的东西」。现在AI编码引入了一种全新的不确定性，不是人写代码风格不统一，而是AI本身的行为不可预测。Archon做的事情，就是在这层新的不确定性上，再建一层确定性的基础设施。

这让我想起了一本很老的书，人月神话。Brooks在1975年就说过，软件工程中最难的不是写代码，而是管理复杂度。50年过去了，工具从汇编变成了AI，但这个核心命题一点没变。

顺着上面的再聊聊Archon的几个工程细节，每一个都让我觉得这个团队是真的想清楚了再做。

第一个是Worktree隔离。每个工作流运行都在独立的Git worktree里，所以你可以同时跑5个修复任务，互相完全不干扰。这个设计太实用了。我之前用Claude Code的时候，经常是改着改着A功能的代码，突然想起B功能也要改，然后切过去改B，改完回来发现A的上下文已经被B的对话冲掉了。Archon直接把这个物理隔离了。

第二个是上下文控制。YAML里有个配置叫context: fresh，每轮迭代都用全新的上下文，避免前面累积的长对话污染当前的AI推理。这个看似简单的配置，其实解决了一个非常实际的工程问题。大模型的上下文窗口是有限的，而且越长的上下文，模型的注意力越分散，这是学术界早就验证过的事情。Archon的策略是主动管理上下文的生命周期，而不是一股脑把所有对话历史都塞进去。

第三个是Human-in-the-Loop。内置了两种人机协作模式，一种是approval门禁，跑完一个阶段暂停等你审批。另一种是interactive loop，你可以在循环中反复给反馈，直到你满意为止。这保证了人始终在流程中拥有最终决策权，AI不会脱缰。

第四个是多平台支持。同一套工作流可以在CLI、Web UI、Slack、Telegram、Discord、GitHub Webhook上复用。所以你完全可以在命令行里启动了一个工作流，然后出门用手机在Telegram上就能看到进度。或者你的团队在Slack里直接触发工作流，整个流程透明可见。

聊到这里，可能有小伙伴纳闷，这玩意跟Cursor、跟Claude Code到底啥关系？它是个替代品吗？

不是。它是编排层。

你可以这样理解，Claude Code是一个很强的执行者，Cursor是一个很好的交互式编程环境，而Archon是一个流程引擎。它把Claude Code、Codex这些编码能力拉进一个可编排的流程里。AI只负责在需要智能的环节发力，其余的结构性工作由确定性节点来完成。

这就像一个交响乐团，Claude Code是首席小提琴手，而Archon是指挥。

Archon开箱就内置了17个工作流，覆盖了从通用问答、Issue修复、功能开发到PR审查的几乎所有场景。其中让我最兴奋的是archon-idea-to-pr，从一个功能想法直接到PR，中间经过规划、实现、验证、5个并行审查Agent、自动修复。你说一句话，剩下的全自动化。

还有archon-fix-github-issue，自动分类Issue类型，调查问题原因，实现修复，跑测试验证，创建PR，做代码审查，如果有问题还能自己修。整个流程完全自动化。

当然它也不是完美的。坦率的讲，Archon目前对Claude生态的依赖比较重，虽然也支持Codex和其他模型，但核心还是围绕Claude Code构建的。另外YAML配置对非技术背景的人有一定门槛。Web UI还在打磨阶段，偶尔流畅度不如商业产品。复杂架构和大规模重构场景，AI还是有可能卡住。

但我自己的感受是，这些都不是致命问题。致命问题从来都是「方向对不对」，而不是「第一步走得够不够完美」。Archon找到了正确的方向，并且已经在路上跑得很远了。

说到安装，其实非常简单。如果你已经有Claude Code，30秒就能装好。

# macOS / Linuxcurl -fsSL https://archon.diy/install | bash# Windows PowerShellirm https://archon.diy/install.ps1 | iex# Homebrewbrew install coleam00/archon/archon

装完之后在你的项目目录里打开Claude Code，说一句「Use archon to fix issue #42」就能跑起来了。

我其实一直在想一个问题。AI编码这个领域，到底是在往哪个方向走？

过去两年我们看到了太多AI编码工具的诞生和迭代，每一个都宣称自己更聪明、更快、更懂你。但Archon给我最大的启发是，AI编码的下一站可能不是更聪明的模型，而是更可控的流程。

模型会越来越强，这是确定的。但模型越强，它需要被管理的需求就越大。一个超级聪明的AI如果没有流程约束，就像一个天才程序员完全不听PM的安排，想到哪做到哪，效率可能还不如一个按部就班的普通工程师。

Archon的GitHub页面上有一句话让我印象很深，「Make AI coding deterministic and repeatable」。让AI编码变得确定性和可重复。这句话听起来很朴素，但我觉得它指向了一个真正重要的问题。

当AI的能力边界不断扩展的时候，我们最需要的可能不是让它变得更强，而是让它的强大变得可控。

就像核能。发现核裂变是科学家的事情，建造核电站是工程师的事情。前者是释放能量，后者是管理能量。AI编码领域现在最缺的不是「裂变发现者」，而是「电站建造者」。

Archon就是这样一个电站建造者。

如果你是一个独立开发者，或者一个小团队的技术负责人，或者你就是单纯对AI编码的未来感到好奇，我觉得Archon值得你花时间去了解一下。不是为了跟风追热点，而是为了亲手触摸一下AI编码的下一个范式可能长什么样。

项目地址放在这里了，https://github.com/coleam00/Archon ，官网是 archon.diy ，MIT协议完全开源。

大时代啊，朋友们。

AI在改变写代码的方式，而Archon在改变我们管理AI写代码的方式。这两件事叠加在一起，就是软件工程的未来。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

/ 作者：mojianpo/ 投稿或爆料，请联系邮箱：406223802@qq.com