编者按:在生成式 AI 加速进入软件工程的当下,行业情绪正在从「能力惊叹」滑向「效率焦虑」。写得不够快、用得不够多、自动化不够彻底,似乎都会让人产生被淘汰的压力。但当编码 Agent 真正进入生产环境,一些更现实的问题开始浮现:错误被放大、复杂性失控、系统逐渐变得不可理解,效率的提升并没有等比例转化为质量的提升。
本文基于一线实践,对这轮「agentic coding」热潮进行了冷静反思。作者指出,Agent 并不会像人类一样在错误中学习,在缺乏瓶颈与反馈机制的情况下,小问题会被快速放大;而在复杂代码库中,其局部视角与有限召回能力,又进一步加剧了系统结构的混乱。这些问题的本质,并不在于技术本身,而在于人类在焦虑驱动下,将判断与控制过早交出。
因此,与其陷入「是否必须全面拥抱 AI」的焦虑,不如重新校准人与工具的关系:让 Agent 承担局部、可控的任务,而将系统设计、质量把关与关键决策牢牢掌握在自己手中。在这个过程中,「慢下来」反而成为一种能力,它意味着你仍然理解系统、能够做出取舍,也仍然保有对工作的掌控感。
在工具不断进化的时代,真正稀缺的,或许不是更快的生成能力,而是对复杂性的判断力,以及在效率与质量之间做出选择的定力。
以下为原文:
大约一年前,真正能够帮你「从头到尾做完整项目」的编码 Agent 开始出现。更早之前也有像 Aider、早期 Cursor 这样的工具,但它们更像助手,而不是「代理」。新一代工具极具吸引力,很多人也花了大量业余时间,把那些一直想做却没时间做的项目全做了一遍。
我觉得这本身没问题。用业余时间做东西本来就很快乐,而且大多数时候你也不太需要在意代码质量和可维护性。这也给了你一个学习新技术栈的路径。
圣诞假期期间,Anthropic 和 OpenAI 还发了一些「免费额度」,像老虎机一样把人吸进去。对很多人来说,这是第一次真正体验到「Agent 写代码」的魔法。参与的人越来越多了。
如今,编码 Agent 也开始进入生产代码库。12 个月过去,我们开始看到这场「进步」的后果了。下面是我目前的看法。
一切都坏掉了
虽然这些大多只是经验之谈,但现在的软件确实给人一种「随时会碎」的感觉。98% 的可用性,正在从例外变成常态,哪怕是大型服务也不例外。用户界面里充满了各种离谱的 bug,本该是 QA 团队一眼就能抓到的那种。
我承认,这种情况在 Agent 出现之前就已经存在。但现在,问题明显在加速。
我们看不到公司内部的真实情况,但偶尔会有一些信息泄露出来,比如那次传闻中「AI 导致的 AWS 宕机」。Amazon Web Services 随后第一时间「更正」了说法,但紧接着又在内部启动了一个 90 天的重整计划。
Satya Nadella(Microsoft CEO)最近也一直在强调,公司里有越来越多的代码是由 AI 写的。虽然没有直接证据,但确实有一种感觉:Windows 的质量在下滑。甚至从微软自己发布的一些博客来看,他们似乎也默认了这一点。
那些声称「产品 100% 代码由 AI 生成」的公司,几乎总是在输出你能想象到的最糟糕的产品。不是针对谁,但动辄以 GB 计的内存泄漏、UI 混乱、功能残缺、频繁崩溃......这些都绝不是他们以为的「质量背书」,更不是「让 Agent 替你干一切」的正面示范。
私下里,你会越来越多地听到,无论是大公司还是小团队,都在说一件事:他们已经被「Agent 写代码」逼进了死胡同。没有代码审查,把设计决策交给 Agent,再堆上一堆没人需要的功能——结局自然不会好。
我们为什么不该这样使用 Agent
我们几乎已经放弃了所有工程纪律和主观判断,转而陷入一种「上瘾式」的工作方式:目标只有一个——在最短时间内生成最多代码,至于后果如何,完全不在考虑之内。
你在搭一个编排层,去指挥一支自动化 Agent 军队。你装了 Beads,却完全不知道它本质上几乎就是个卸不掉的「恶意软件」。只是因为网上说「大家都这么做」。不这么干你就「要完蛋」(ngmi)。
你在不断「套娃式循环」里自我消耗。
看——Anthropic 用一群 Agent 做了个 C 编译器,虽然现在还有问题,但下一代模型肯定能修好,对吧?
再看——Cursor 用一大群 Agent 做了个浏览器,虽然现在基本不可用,还需要人时不时手动干预,但下一代模型肯定能搞定,对吧?
「分布式」「分而治之」「自治系统」「黑灯工厂」「六个月解决软件问题」「SaaS 已死,我奶奶刚用 Claw 搭了个 Shopify」......
这些叙事听起来很爽。
当然,这种方式对于你那种几乎没人用(包括你自己)的 side project,可能确实「还能跑」。也许,确实存在某个天才,能用这种方式做出一个不垃圾、真正被人使用的软件产品。如果你就是那个人,那我真心佩服。
但至少在我身边的开发者圈子里,我还没见过这种方法真的有效的案例。当然,也许只是我们都太菜了。
错误在无学习、无瓶颈、延迟爆发中不断叠加
Agent 的问题在于:它们会犯错。这本身没什么,人类也会犯错。可能只是一些正确性错误,容易识别、也容易修复,再补一个回归测试就更稳了。也可能是一些 linter 抓不住的代码味道:这里一个没用的方法、那里一个不合理的类型、还有重复代码之类。这些单独来看都无伤大雅,人类开发者同样会犯这种小错误。
但「机器」不是人。人类重复犯几次同样的错误后,通常会学会不再犯——要么是被人骂醒了,要么是在真正的学习过程中改掉了。
而 Agent 没有这种学习能力,至少默认是没有的。它会一遍又一遍重复同样的错误,甚至还可能基于训练数据「创造」出不同错误的奇妙组合。
你当然可以试图「训练」它:在 AGENTS.md 里写规则,让它别再犯这种错误;设计一套复杂的记忆系统,让它查询历史错误和最佳实践。这在某些特定类型的问题上确实有效。但前提是——你必须先观察到它犯了这个错误。
更关键的差别在于:人类是瓶颈,而 Agent 不是。
人类不可能在几个小时内吐出两万行代码。即使犯错频率不低,一天也只能引入有限数量的错误,这些错误的累积是缓慢的。通常,当「错误带来的痛苦」积累到一定程度,人类(出于本能厌恶痛苦)会停下来修一修。或者人被替换掉,由别人来修。总之,问题会被处理。
但当你用一整套编排好的 Agent「军队」时,就没有瓶颈,也没有「痛感」。这些原本微不足道的小错误,会以不可持续的速度叠加。你已经被移出了循环,甚至不知道这些看似无害的小问题,已经长成了一个庞然大物。等你真正感受到痛苦时,往往已经太晚了。
直到某一天,你想增加一个新功能,却发现当前的系统架构(本质上已经是错误的堆积)根本无法支持修改;或者用户开始疯狂投诉,因为最新一次发布出了问题,甚至丢了数据。
这时你才意识到:你已经无法信任这套代码了。
更糟的是,你让 Agent 生成的成千上万的单元测试、快照测试、端到端测试,同样不再可信。唯一还能判断「系统是否正常工作」的方式,只剩下手动测试。
恭喜,你把自己(以及公司)坑惨了。
复杂性的贩卖者
你已经完全不知道系统在发生什么了,因为你把控制权交给了 Agent。而 Agent,本质上是在「贩卖复杂性」。它们在训练数据中见过大量糟糕的架构决策,在强化学习过程中也不断强化这些模式。你让它来设计系统,结果可想而知。
你最终得到的是:一整套极其复杂的系统,混杂着各种「行业最佳实践」的拙劣模仿,而你在问题失控之前,并没有加以约束。
但问题还不止于此。你的 Agent 彼此之间并不共享执行过程,也看不到完整的代码库,更不了解你或其他 Agent 之前做出的决策。因此,它们的决策始终是「局部的」。
这就直接导致了前面提到的那些问题:大量重复代码、为抽象而抽象的结构、各种不一致。这些问题不断叠加,最终形成一个不可挽回的复杂系统。
这其实和人类写的企业级代码库很像。只是那种复杂性通常是多年累积的结果:痛苦被分散在大量人身上,每个人都没到「必须修」的临界点,组织本身的容忍度又很高,于是复杂性与组织一起「共生演化」。
但在人类 + Agent 的组合下,这个过程会被极大加速。两个人,加上一堆 Agent,几周就能达到这种复杂度。
Agentic 搜索的召回率很低
你可能会寄希望于 Agent 来「收拾残局」,帮你重构、优化、让系统变得干净。但问题是:它们已经做不到了。
因为代码库太大、复杂度太高,而它们始终只能看到局部。这不仅仅是上下文窗口不够大,或者长上下文机制在百万行代码面前失效这么简单。问题更隐蔽。
在 Agent 尝试修复系统之前,它必须先找到所有需要修改的代码,以及可以复用的已有实现。这一步,我们称为 agentic search(Agent 搜索)。
Agent 如何做这件事,取决于你给它的工具:可以是 Bash + ripgrep,可以是可查询的代码索引、LSP 服务、向量数据库......
但无论用什么工具,本质都一样:代码库越大,召回率越低。而召回率低意味着:Agent 无法找到所有相关代码,自然也无法做出正确修改。
这也是为什么一开始那些「代码味道」的小错误会出现,它没找到已有实现,于是重复造轮子,引入不一致。最终,这些问题会不断扩散、叠加,开出一朵极其复杂的「烂花」。
那我们该如何避免这一切?
我们应该如何与 Agent 协作(至少目前)
编码 Agent 就像海妖,用极快的代码生成速度和那种「断断续续但又时不时惊艳」的智能把你吸引进去。它们往往能以惊人的速度、高质量地完成一些简单任务。真正开始出问题,是你产生这样一种想法的时候——「这玩意太强了,电脑,替我干活吧!」
把任务交给 Agent 本身当然没有问题。好的 Agent 任务通常具备几个特征:范围可以被很好地限定,不需要理解整个系统;任务是闭环的,也就是说 Agent 可以自行评估结果;输出不是关键路径,只是一些临时工具或内部使用的软件,不会影响真实用户或收入;又或者你只是需要一个「橡皮鸭」来辅助思考——本质上是把你的想法拿去和互联网的压缩知识以及合成数据做一轮碰撞。
如果满足这些条件,那么这就是适合交给 Agent 的任务,前提是,你作为人类,仍然是最终的质量把关者。
比如,用 Andrej Karpathy 提出的 auto-research 方法来优化应用启动时间?很好。但前提是你清楚,它吐出来的代码绝对不具备生产可用性。auto-research 之所以有效,是因为你给了它一个评估函数,让它可以围绕某个指标(比如启动时间或 loss)进行优化。但这个评估函数只覆盖了一个非常狭窄的维度。Agent 会理直气壮地忽略所有不在评估函数里的指标,比如代码质量、系统复杂度,甚至在某些情况下连正确性都可以忽略——如果你的评估函数本身就有问题的话。
核心思路其实很简单:让 Agent 去做那些无聊的、不会让你学到新东西的事情,或者那些你本来没时间尝试的探索性工作。然后由你来评估结果,挑出真正合理、正确的部分,再完成最终实现。当然,最后这一步你也可以借助 Agent 完成。
但我更想强调的是:真的,该慢下来一点了。
给自己时间去思考,你到底在做什么、为什么要做。给自己一个说「不」的机会,「不,这个我们不需要。」给 Agent 设定一个明确的上限:每天允许它生成多少代码,这个量应该与你实际能够审查的能力相匹配。所有决定系统「整体形态」的部分,比如架构、API 等都应该亲自写。你可以用自动补全找点「手写代码的感觉」,也可以和 Agent 结对编程,但关键是:你必须在代码里。
因为,亲自写代码,或者看着它一步一步被构建出来,这种过程本身会带来一种「摩擦感」。正是这种摩擦,让你更清楚自己到底想做什么、系统是怎么运作的、整体「手感」如何。这正是经验与「品味」发挥作用的地方,而这恰恰是当前最先进的模型还无法替代的。慢下来,承受一点摩擦,恰恰是你学习和成长的方式。
最终,你得到的会是一个依然可维护的系统——至少不会比 Agent 出现之前更糟。是的,过去的系统也不完美。但你的用户会感谢你,因为你的产品是「好用的」,而不是一堆糊出来的垃圾。
你做的功能会更少,但更正确。学会说「不」,本身就是一种能力。你也可以安心睡觉,因为你至少还知道系统在发生什么,你仍然掌握主动权。正是这种理解,让你能够弥补 agentic search 的召回问题,让 Agent 的输出更可靠、需要更少修补。
当系统出问题时,你可以亲自下场修;当设计一开始就不合理时,你也能理解问题所在,并把它重构成更好的形态。至于有没有 Agent,其实没那么重要。
这一切,都需要纪律。这一切,都离不开人。
