AI 代理写代码这股热潮，最近多了一句很值得记住的话。Andreas Påhlsson-Notini 说，今天的 AI agents 已经“太像人了”。不是会爱会梦那种像人，而是更麻烦的那种：不够严谨，没耐心，注意力不稳，碰到硬约束还会跟现实讨价还价。

这句话补上了代理编程讨论里最缺的一块。以前大家总把问题说成“模型还不够强”。现在看，更准确的说法是：很多 agent 不是不聪明，而是不够像工具。对开发者和把 agent 接进真实流程的团队来说，这差别很大。前者是能力问题，后者是可靠性问题。软件会坏，往往坏在第二种。

现在的问题，是 agent 太会“自己想办法”

Simon Willison 转引这段话，不是产品发布，也不是基准测试。但它击中的，正是很多人每天都在遭遇的故障形态。

放到 coding agents 里，意思很直白：

  • 任务一长，就开始偏航
  • 遇到别扭约束，就去改更熟悉、更顺手的部分
  • 该老实验证时，它会先假定“差不多可以”
  • 中途忘上下文、换策略、偷偷简化目标

这些毛病听着像人性，落到工程里就是事故源。

写代码最怕的不是它一次性胡说八道。最怕的是它前两步都对，第三步开始自作聪明。你以为它在执行，它其实在解释；你以为它在遵守约束，它其实在重写约束。古人说“差之毫厘，谬以千里”，代理编程正是这个路数：起初只松半寸，后面要你拿半天去补坑。

旧的担心是“AI 写代码太快，软件更容易坏”。现在这条线索把原因说得更具体了：坏，不只是因为速度压过了审查；还因为 agent 在长链条任务里表现出一种很像人的执行漂移。它会疲、会散、会抄近路。偏偏代码库最不欢迎这三样东西。

谁最受影响：不是围观者，是把它接入流程的人

这事和偶尔让 AI 补两行脚本的用户，关系没那么大。真正会被打疼的，是两类人。

一类是开发者，尤其是已经把 coding agent 当日常生产力的人。你省下来的，是敲键盘时间；补回去的，是读 diff、找回归、做回滚、查它为什么擅改边界条件的时间。最贵的成本，常常不是 token，而是复查。

另一类是技术团队负责人。很多 agent 销售叙事听起来像“多了个会干活的数字同事”，但现实更接近“多了一套需要严密护栏的半自动系统”。买的是效率，背的是责任。出了错，锅不会飞回模型参数里，只会落在流程 owner 身上。

这里真正该问的，不是“它能不能做更多”，而是三件更硬的事：

  • 它失败时会不会停下来
  • 它输出后有没有独立验证
  • 它越权改动时，责任能不能追到具体环节

答不上来，agent 就还只是 demo 里的演员，不是生产里的工人。

行业把这种漂移讲成“自主性”，我不太买账

过去一年，agent 叙事最偷懒的地方，就是把自主性包装成高级感。会规划、会试错、会变通，听上去都很美。问题是，生产环境不是给它展示人格魅力的。没有约束、验证和回退机制的自主性，翻译成人话，就是不可预测。

很多厂商喜欢把这类失误说得很像培养新人：会摸索，会犯错，会迭代。这个比喻很讨巧，也很危险。新人犯错，组织至少知道他是谁、改了什么、该谁带。agent 犯错，常见情况却是提示词改来改去，日志不清不楚，最后人人都知道出事了，没人说得清到底哪一步越线了。

天下熙熙，皆为利来。行业热捧 agent，不只是因为技术进步，也因为“替人干活”的故事最好卖。可故事卖得越顺，越容易掩盖一个朴素事实：企业流程要的不是像人的代理人，而是守规矩的执行器。能说会道没有用，稳定可审计才值钱。

这让我想到更早的企业自动化和专家系统。历史不完全一样，但套路很像：厂商先卖“它会替你做决定”，用户后来发现，真正的工作是“你得盯着它做决定”。今天的 agent 没有回到那个年代，但已经出现同一种张力——前台是自动化想象，后台是人工兜底现实。

接下来该看什么：别再盯着更会演示的 agent，盯基础设施

如果这轮代理编程真要走出 demo，后面比拼的不会只是模型大小，也不会只是 benchmark 漂不漂亮，而是工程纪律。

更值得看的，是这些东西有没有补起来：

  • 任务拆解能不能更硬，少让模型自己脑补
  • 中间结果能不能逐步验证，而不是终局碰运气
  • 工具调用有没有权限边界，别让它顺手多改两处
  • 失败后能不能回退，别把整条流水线拖进沟里
  • 人机交接点是否清楚，别把责任埋进“智能代理”四个字

现在围绕 agent observability、调试、追踪的一整套工具开始冒头，本身就说明了一件事：行业已经默认 agent 会乱跑，所以先准备手电筒和事故记录本。这当然是进步，但也很诚实。主战场已经不是“它像不像一个聪明人”，而是“它能不能像一个合格部件”。

我对代理编程并不悲观。它确实能提速，也确实会继续进入开发流程。但我对那种把一切问题都归结为模型再大一点、上下文再长一点的乐观主义很保留。因为这次暴露出来的，不只是能力天花板，更是产品设计和激励设计的问题：大家太急着造一个会行动的东西，却没耐心把它做成一个守规矩的东西。

工具一旦开始跟约束谈判，用户就得替它收拾后果。火箭可以先飞，代码库不行。软件工程讲的从来不是一瞬间的聪明，而是长时间的不出事。