距离真正能替你构建完整项目的编码代理登场，已经差不多一年了。之前也有像 Aider 和早期 Cursor 这样的前身，但它们更像助手，而不是代理。新一代产品很有诱惑力，我们很多人都花了大量空闲时间，去做那些自己一直想做却从没时间做的项目。

我觉得这没什么问题。用空闲时间做东西本来就很有趣，而且大多数时候你也确实不必太在意代码质量和可维护性。它还给了你一个学习新技术栈的途径，如果你想的话。

圣诞假期期间，Anthropic 和 OpenAI 都发了一些免费额度，好把人们勾进它们那台让人上瘾的老虎机。对很多人来说，这是他们第一次体验到 agentic coding 的魔力。圈子正在变得越来越大。

编码代理现在也被引入到了生产代码库中。12 个月过去，我们现在开始看到这一切“进步”带来的效果了。下面是我目前的看法。

一切都坏掉了

虽然这些都只是轶事，但软件确实让人感觉变成了一团脆弱的烂摊子，98% 的可用性正在变成常态，而不是例外，哪怕是大服务也一样。用户界面里还会冒出一些离谱得要命的 bug，你会觉得正常 QA 团队本该能抓住。我承认，这种情况在代理出现之前就已经存在很久了。但我们似乎在加速。

我们看不到公司的内部情况。但时不时总会有些东西漏到新闻记者那里。比如这次据说由 AI 导致的 AWS 故障。AWS 立刻“纠正”了这个说法。然后内部又跟进搞了个 90 天重置。

微软 CEO Satya Nadella 一直在讲，微软现在有多少代码是 AI 写的。虽然我们没有直接证据，但 Windows 正在一路下坠这件事，确实有种越来越明显的感觉。微软自己似乎也同意，依据就是这篇精彩的博客文章。

那些声称自己产品 100% 代码都由 AI 编写的公司，持续产出的都是你能想象到最糟糕的垃圾。我不点名，但动不动就几个 GB 的内存泄漏、UI 故障、坏掉的功能、崩溃：这可不是他们以为的质量印章。对于那种“让代理替你完成所有工作”的狂热幻梦来说，这也绝对不是什么好广告。

通过各种小道消息，你会越来越多地听到来自大小软件公司的说法：他们已经用 agentic coding 把自己逼进了死胡同。没有代码评审，把设计决策委托给代理，外加一堆根本没人要的功能。这样搞当然会出事。

我们不该如何使用代理，以及为什么

我们基本上已经放弃了所有纪律和自主性，转而沉迷于一种上瘾状态，在这种状态下，你的最高目标就是在最短时间内产出最多的代码。至于后果，去他妈的。

你正在构建一个编排层，好指挥一支自治代理军队。你安装了 Beads，完全没意识到它基本上就是个难以卸载的恶意软件。因为互联网是这么告诉你的。你就该这么工作，不然你就 ngmi。你在 ralphing the loop。看啊，Anthropic 用一个代理蜂群构建了一个 C 编译器。是有点坏，但下一代 LLM 肯定能修好。天哪，Cursor 用一整营代理造了个浏览器。对，当然，它其实并不好使，而且时不时还得靠人类去稍微转一下方向盘。但下一代 LLM 肯定能修好。拉钩保证！分布式、分而治之、自主性、黑暗工厂、软件会在未来 6 个月内被彻底解决。SaaS 已死，我奶奶刚让她的 Claw 给自己造了个 Shopify！

当然，再说一遍，这套东西可以用在你那个几乎没人用的 side project 上，包括你自己都不怎么用。嘿，也许这个世界上真有某些人，确实能把这套方式用到一个不是冒着热气的垃圾堆的软件产品上，而且这个产品还真有真实用户在愤怒地使用。

如果那个人就是你，那我向你致敬。但至少在我身边的同行圈子里，我还没看到任何证据表明这种狗屎玩意真的行。也许只是我们都太菜了。

错误层层叠加，没有学习、没有瓶颈、痛苦延后

代理的问题在于，它们会犯错。当然，人也会犯错。也许只是正确性错误。容易识别，也容易修。再加个回归测试，还能顺便加分。或者也可能是 linter 抓不到的代码异味。这里一个没用的方法，那里一个莫名其妙的类型，另一边还有重复代码。单独来看，这些都无伤大雅。人类也会犯这种小错误。

但铁皮罐头不是人。人会犯同样的错几次，但最终会学会不再犯。要么是因为有人开始对他大吼大叫，要么是因为他确实走在一条真实的学习路径上。

代理没有这种学习能力。至少开箱即用时没有。它会一遍又一遍地重复同样的错误。取决于训练数据，它还可能会发明出各种错误的光荣新插值。

你当然可以试着教你的代理。你可以在自己的 AGENTS.md 里告诉它别再犯那个错。你也可以调制出最复杂的记忆系统，让它去查以前的错误和最佳实践。对于某一类特定错误，这确实可能有效。但这也要求你真的观察到代理犯了这个错。

铁皮罐头和人类之间还有一个更重要的区别。人类是瓶颈。人类不可能在几个小时里喷出 2 万行代码。即便一个人会高频率地产生这些小错误，他一天能往代码库里引入的错误也就那么多。这些错误会以非常缓慢的速度累积。通常来说，如果这些小错误造成的痛苦变得太大了，那个讨厌痛苦的人类就会花些时间把它们修掉。或者那个人被开除了，换别人来修。所以痛苦会消失。

但如果你有一支经过编排的代理大军，就没有瓶颈，也没有人类痛苦。这些原本细小、无害的错误，突然会以一种不可持续的速度累积。你把自己移出了循环，所以你甚至都不知道这些无辜的小错误已经合体成了一个怪物级代码库。等你感到痛苦时，已经太晚了。

然后某一天，你回过头来想加一个新功能。但架构到了这个阶段，基本上已经主要由这些错误拼成了，它根本不允许你的代理大军以一种能正常工作的方式完成修改。或者你的用户已经在对你咆哮，因为最新版本里的某个东西坏了，还删掉了一些用户数据。

你意识到自己再也无法信任这个代码库了。更糟糕的是，你意识到那些由你的铁皮罐头写出来的海量单元测试、快照测试和 e2e 测试，同样也不值得信任。唯一还能可靠衡量“这玩意能不能用”的方式，只剩下手工测试产品。恭喜，你把自己搞死了（也把你的公司搞死了）。

习得性复杂度的贩卖者

你他妈完全不知道发生了什么，因为你把所有自主性都委托给了代理。你让它们自由奔跑，而它们就是复杂度的贩卖者。它们在训练数据和 RL 训练过程中见过无数糟糕的架构决策。你还让它们来为你的应用做架构。那结果会是什么？

结果就是海量复杂度，是一堆可怕的、教条式搬运来的“行业最佳实践”的混合体，而你在事态无法收拾之前根本没有把它约束住。但事情比这还更糟。

你的代理彼此看不到对方的运行过程，也看不到你的整个代码库，更看不到在它们开始修改之前，你或其他代理已经做出的所有决策。因此，代理的决策永远都只是局部的，而这正会导致上面说的那些小错误。大量重复代码，为了抽象而抽象的抽象。

这一切会层层累积，最终变成一个无法挽回的复杂烂摊子。和你在人类制造的企业代码库里看到的那种烂摊子一模一样。那些系统会走到那一步，是因为痛苦被分摊到了大量人头上。单个人承受的痛苦达不到“我必须修这个”的阈值。个体甚至可能没有手段去修。而组织本身的痛苦耐受度极高。但人类制造的企业代码库通常要花上好几年才会变成那样。组织会和复杂度一起缓慢演化，在一种扭曲的协同中学会如何应对它。

而有了代理和一个只有 2 个人的人类团队，你几周之内就能抵达那种复杂度。

Agentic search 的召回率很低

于是你现在希望代理能把这个烂摊子修好，重构它，让它变得整洁。但你的代理同样已经处理不了它了。因为代码库和复杂度都太大了，而它们看到的永远只是这个烂摊子的局部视角。

而且我说的不只是上下文窗口大小，或者长上下文注意力机制在看到一个 100 万行代码怪物时就会失灵。这些都是显而易见的技术限制。事情比这更阴险。

在代理尝试帮你修复这个烂摊子之前，它得先找到所有需要修改的代码，以及所有它可以复用的现有代码。我们把这叫作 agentic search。代理怎么做这件事，取决于它手头有什么工具。你可以给它一个 Bash 工具，让它用 ripgrep 在代码库里乱搜。你也可以给它某种可查询的代码库索引、LSP 服务器、向量数据库。到头来差别其实不大。代码库越大，召回率越低。召回率低就意味着，代理事实上找不全它做好工作所需要的全部代码。

这也是为什么那些代码异味式的小错误一开始就会出现。代理漏掉已有代码、重复造轮子、引入不一致。然后这些问题开花结果，绽放成一朵美丽的复杂度屎花。

我们该如何避免这一切？

我们该如何与代理协作（至少目前，我是这么想的）

编码代理就像海妖，用它们高速生成代码和棱角分明的智能把你引诱过去。它们常常能以惊人的速度、高质量地完成一个简单任务。而当你开始想：“哎呀，这玩意真棒。电脑，替我干活！”事情就开始崩坏了。

显然，把任务委托给代理本身并没有错。好的代理任务通常有几个共同属性：任务可以被限定范围，这样代理不需要理解整个系统；循环可以被闭合，也就是说，代理有办法评估自己的工作；输出不是关键任务，只是某个临时工具，或者某个没有任何人的生命或收入依赖其上的内部软件。又或者，你只是需要一只橡皮鸭来陪你推敲想法，本质上就是拿你的点子去碰撞互联网与合成训练数据压缩出来的智慧。如果其中任何一条适用，那你就找到了最适合代理的任务，前提是你这个人类仍然是最终的质量把关者。

Karpathy 那套用于加速应用启动时间的 auto-research？很好！前提是你明白，它吐出来的代码根本还没达到生产可用。Auto-research 之所以有效，是因为你给了它一个评估函数，让代理可以把自己的成果和某个指标进行衡量，比如启动时间或 loss。但这个评估函数只捕捉了一个非常狭窄的指标。任何没有被评估函数覆盖到的指标，代理都会愉快地忽略掉，比如代码质量、复杂度，甚至正确性，只要你的评估函数写得一团糟。

关键点在于：让代理去做那些无聊的事、那些不会教会你任何新东西的事，或者那些你原本没时间尝试的不同方案。然后由你来评估它拿出来的结果，把里面那些真正合理且正确的想法吸收过来，最后再完成实现。是的，当然，你也可以在最后一步继续用代理。

而我想建议的是，慢他妈下来，才是正确的路。给自己时间去思考你到底在构建什么，以及为什么要构建它。给自己一个机会去说，操，不，我们不需要这个。给自己设定限制，让铁皮罐头每天生成的代码量，不超过你真正有能力审查的范围。

任何定义你系统 gestalt 的东西，也就是架构、API 等等，都请手写。也许可以顺便用一下 tab completion，怀旧一下。或者和你的代理结对编程。待在代码里。因为单是“你不得不亲手把这个东西写出来”或者“看着它一步一步被搭起来”这个动作，就会引入一种摩擦，而这种摩擦能让你更好地理解自己到底想构建什么，以及系统“感觉”如何。这正是你的经验和品味发挥作用的地方，而当前最先进模型还远远无法取代这一点。慢他妈下来，并承受一些摩擦，正是让你学习和成长的方式。

最终结果会是：系统和代码库会继续保持可维护，至少能和代理出现之前那些老系统一样可维护。没错，那些系统本来也不完美。你的用户会感谢你，因为你的产品现在带来的是愉悦，而不是一坨糊脸的垃圾。你做出来的功能会更少，但会是对的那些。学会说“不”，本身就是一种能力。

你可以安心睡觉，因为你依然大致知道到底发生了什么，而且你仍然拥有自主性。你的理解能帮助你修复 agentic search 的召回率问题，从而让铁皮罐头产出的结果更好，也更少需要你大修大补。即便真的出事了，你也能亲自进去修。或者如果你的初始设计并不理想，你也会明白它为什么不理想，以及如何把它重构成更好的东西。有代理也好，没有代理也罢，根本无所谓。

这一切都需要纪律与自主性。

这一切都需要人类。

https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/