智能体（Agents）能一次性做出真正有趣游戏，在适当护栏下可在复杂代码库执行惊人迁移甚至新语言重写。但真实软件工作仍由人类工程师主导，智能体自行构建系统在实践中表现不佳。许多工程组织在2026年上半年将大量工作交由智能体大军，结果只有可疑代码而没出现惊人软件，token 投资回报不明。我们正处炒作周期的失望之谷，摸索数月前未奏效的乌托邦愿景。

agent 已经能一次性做出真正好玩的游戏。在合适的护栏下，它们能在复杂代码库中执行令人惊叹的迁移，甚至用新语言重写。但几乎所有“真实”软件工作仍由人类工程师驾驶。我们如何才能让更大一部分工作自动替我们完成，而不需要我们的关注？

看来 agent 理应能自己构建整个软件系统。为什么实践中这么拉胯？我们需要什么新原语才能让它运转起来？这能走多远？

tokenmaxxing 之后是什么？

今年上半年，很多工程团队把尽可能多的工作丢给 agent 大军和对抗循环。结果相当令人失望：堆成山的可疑代码，却没有出现惊人软件的海啸。这些 token 的投资回报率顶多算含糊不清。

用炒作周期的话说，我们正处在失望低谷。我们在琢磨如何兑现几个月前那种尚未在现实中落地的乌托邦愿景。

接下来呢？在以往每一次采用周期里，答案都是：摸清最佳实践，搞清楚这个新锤子适合钉哪种钉子、而我们之前又是怎么用它砸螺丝的，然后创造出在我们上手之前没意识到的必要积木。

我们可以用一个诊断问题来帮助抵达那里：当软件基本自动驾驶时，工程师会做什么？

常见答案是：搭循环！以前写代码，后来写提示词，现在我们设置 agent 循环并且狂写 /goal。

我认为这是错的。眼下搭一个能产出净正向代码改动且不烧钱的可靠软件循环非常费力，但主要是因为工具链没准备好。等我们有了正确的组件，这些循环会变得易搭、可信且划算。这不是我们的时间该去的地方。

相反，最有价值的工程工作是有好点子。重要点子仍来自软件工厂之外。事实上，这台整个机器的目的就是最小化我们不得不去想的、那些非高收益的事情。

• 杀手级功能仍能成就公司。 Cursor Tab、Descript 的转录编辑、OpenRouter 在通用计费接口后抽象推理供应商，这些都是成就公司的点子。除了创造力，好点子需要问题亲密度和领域专长，工程师得为这个过程做贡献。（如果“品味”曾真的是差异点，现在不是了，但好点子是。）
• 杀手级架构仍高杠杆。 正确的简化日后能省下海量复杂度，体现为更少 bug 和更易产品迭代。一点先见之明能让高价值功能日后变得垂手可得。理顺更正确的数据模型、在合适位置加个队列、或为更好的产品测试方式搭脚手架，都很有价值。

哪些部分应该自动驾驶？

在“有好点子”之外，我们应该试着把代码库工作挪给 GPU。比如，agent 能处理这些整体关切吗？

• 检测和修复大多数 bug。 用户通过 SSO 登录时新功能不正常；批量删除不像单个删除那样更新页面顶部的行计数器。agent 应该替我们发现并修复这些。大多数 bug 往往有显而易见的预期语义——我们不需要人类工程师来裁定软件该怎么运作，甚至可能连文档或规范都不需要。
• 调试生产错误。 错误出现时，agent 应该把它和最近的提交、流量变化、基础设施差异或意外状况关联起来，并且通常替我们打上补丁。后端基本不该再抛 500 了。浏览器控制台日志基本该没有错误。
• 优化 agent。 我们到底该写多少 agent 提示词？Braintrust、Raindrop、Arize 或 Langfuse 能否隔离常见的 agent 病理、提议更新、回测并发布？
• 前端一致性。 任何应用的视觉语言应内部连贯。应用应使用一致的字体、颜色、图标和间距。设计系统应自举并自我强制，由人类做确认性决策。
• 应用打磨。 应用应按用户预期方式表现。Ctrl+点击应在新标签打开链接。禁用按钮应有原因说明。刷新应保留表单字段。UI 应在移动端合理渲染。UI 应能被屏幕阅读器导航。这类基本体验期望有几十种。
• 增长优化。 迭代表单转化、优化 onboarding、大量产出营销页。有些领域很好理解，比如电商网站会想要弃购邮件、“当前 N 个用户在看！”小组件、低价旁的划线锚定价等；agent 应替我们跑这些手册。这并不是说增长死了——它比以往更活！但工作将看起来更像阴谋和奇袭，而非优化 CTA。增长团队设目标，agent 不仅针对代码、还针对现实迭代，把改动摆在用户面前并学习，我们则聚焦更高层点子。

例子还能列下去。GitHub Copilot 给了我们代码行的自动补全，agent 将给我们整个产品的自动补全。

缺失的原语

若要让这奏效，开发栈需要些新原语。这些都会成为入场筹码：

• agent 可懂的开发环境。 压倒性多数的 bug 来自 agent 看不见的地方 。如果你的应用有 agent 无法端到端演练的第三方集成，那些集成就会有 bug。如果你的仓库没有好的 agent 浏览器设置，整个前端就是 agent 盲飞的灰色地带。以此类推。
• 全局记忆。 agent 犯很多蠢错其实没事。不该的是它们总犯同样的错。如果你得告诉一个 agent 审计日志表是只追加、绝不原地更新，这 OK；但如果你得随后告诉每个碰那块的 agent，你就回到了低级工作的循环里。无论我们造出什么记忆系统，都需要跨工具链工作——代码审查 bot 得知道你两周前给在那块写代码的 agent 发的纠正。当你骂一个 SRE bot 做了不安全的生产操作时，它得明白为什么，然后每个未来的 agent 都得意识到这纠正。全局记忆主要是等工具改进的问题。要么我们搞个开放标准，要么用提供日常驱动 agent、审查员及所需一切的整合套件，或者两者皆有。
• 代码库腐烂预防。 agent 是否留下了死代码？该有一种做法的地方是否有五种？类型系统直观吗？数据模型与我们想交付的产品对齐吗？得有东西处理这一切，否则代码库会开始螺旋下坠。

我们仍需要上一代多数原语，比如 APM（但主要由读日志的 agent 查询，而非富组件 UI）、CI（但有更好的合并队列）和 A/B 测试（但可由 agent 操作）。

如何构建 agent 可懂的开发栈？

工程团队眼下需要做大量工作，创建真正好的云开发环境，让 agent 在代码可能出 bug 之前，就能以所需的一切方式演练它。此刻 dev agent 的限制因素是它们运作的环境，而非模型和框架本身。

换句话说：如果环境足够好，agent 足以做多得多的工作；但它们在看不见的地方制造 bug：agent 没有系统方法复现的竞态条件，以及因无知于数据形态而导致的慢查询。它们还会出于防御任何可设想模糊性的欲望、在不知哪些风险真实的情况下，造出海量不必要的防御性代码。

agent 有盲点就会犯错，这限制信任，意味着工作需更严审查，进而限制我们能交接的量。

所以工程团队当下最重要的投资，是让开发环境对 agent 极其友好。但这目前是个无底洞般的苦差和一次性活儿，还没法量化做得怎样。修复这些开发环境缺口需要好点子和专注工程。带代表性测试数据的本地开发环境是个移动靶。让写好测试变容易的正确新抽象很难想出。这工作很有挑战！

这也因代码库而异，且仍是门少有人能干好的艺术。这是为何许多软件工厂如此令人失望。我们需要好得多的方式来做这类投资。

这意味着，帮团队让工具链为 agent 就绪有巨大杠杆。工程团队怎知低垂果实是什么？他们该如何排优先级让工厂更好转？他们怎知自己干得好不好？如果我们能把这变成科学而非艺术，帮团队取得方法论进步，工厂就会开始嗡嗡转。

以下是我们对前路的最佳猜测：

1. 挖掘代码库找 bug。极其擅长挑出要紧的 bug。
2. 修 bug。追踪那些让验证修复正确、或让验证 bug 是否真实存在变难的缺口。
3. 用修这些 bug 的痕迹，来排定让代码库更适 agent 的工作优先级。

换句话说：Detail 的秘密计划是创造一个能自举自身工作的产品，然后用那工作帮工程团队知道该投什么资、以及投得效果如何。

如果我们能为任何代码库自举出有用工作的语料——此例中即 eng 团队想修的 bug——我们就能用它来确定让任何代码库更适 agent 的高 ROI 方法。我们能基准化一个仓库有多 agent 就绪。工程师可以死磕开发环境中要紧的缺口，直到几乎所有低级 bug 能自主处理，然后工程师就能聚焦真正高价值的工作：想出好功能点子、并搞清楚能简化实现的抽象。

这就是我们抵达“生产力高原”的方式，也是最佳工程团队未来半年将运作的方式。不是 tokenmaxxing，当然也不是禁 AI，而是用类似这样的过程去爬 agent 就绪度，逐步交接越来越多工作。

我们今天发布这其中的一块，但随我们奔向这愿景，你会看到这些理念继续在我们的产品中成形。

这不新

技术通过把低级关切交给替我们管理它们的系统而进步。

2010 年代我们把软件移到云上，现在我们不必想它物理上跑在哪、甚至不必想每个服务跑在哪个虚拟实例上。更小、更聚焦的工程团队现在就能建出成功软件产品。我们活在逻辑层，平台管其余。但我们经历过起初很乱的类似转型，且不得不沿途摸清许多缺失原语。

以前搭 CI/CD 是数月项目，但现在有了正确原语和成熟工具，除非你在迁银行主机之类，否则就是一下午的活。类似转型将发生在“循环”上。

讨论整体偏谨慎甚至怀疑：多数人并不否认 agent 能跑通代码，而是质疑「自我驱动代码库」的瓶颈并不在 harness 或模型能力，而在于反馈信号、需求定义、环境约束和问责归属；少数已在生产中使用 agent 的人则强调角色转变已经是既成事实。

认为真正的瓶颈是反馈回路，而不是 harness

• 代码库只能自我驱动到它「知道自己有没有开出车道」的程度：测试要因为正确的原因失败、要有错误预算、要能察觉某次改动是让东西变慢而不是变坏，否则所谓自我驱动就退化成「能编译就合并」。（较多人）
• 由此引出的关键问题不是技术而是策略：信号变红时，系统该回滚、重试，还是停下来问人——目前没有谁给出好默认值。（较多人） > 缺的不是 harness，而是代码库判断自己是否还开在路上的能力。（@zraiq）

认为难点在需求规格：真正难的是「去哪」，不是「怎么开」

• 与自动驾驶的类比被反复提起：点 A 到点 B 容易指定，但 agent 几乎能开到任何地方，于是全部问题都落回「指定目标」；更快的模型只会让它更高效地把你开到不想去的地方。（较多人）
• 还有 agent 根本开不到的情形（比如让它发明 AGI），它既无法判断自己到不了，人也不知道它到不了；最终仍要由连接现实的人做决定并承担责任，因此未必有人真的想要自我驱动的代码库。（较多人）
• 另一版本是：现在的位置类似自动驾驶——常见路况够用甚至强于多数人，但遇到新情况或需要系统级一致模型时就不行。（较多人） > 它可以把代码库开到任何地方，所以整个问题变成了「怎么指定要开去哪里」。（@ModernMech）

认为受限的环境与框架比自由度更重要

• 在 Windows 上根本谈不上自我驱动：没有明确的 UI 框架、设计模式和能保底的方案，换作 Plan 9 可能更容易成功。（少数人）
• 出路是「去掉选择」：做那种默认可用、选项有限的框架，而不是把无限自由度丢给 agent。（少数人）

担心全局记忆把 agent 拖进 cargo-cult 循环

• 实际运行中会出现这种膨胀：agent 先跑一个巨大的依赖检查命令把本地 JVM 跑爆，于记录下变通办法，几轮之后就开始写整段关于本地开发环境内存配置的测试与验证文字，而这些和目标几乎无关。（较多人）
• 小错误和代码库里无关的注释会滚成消耗大量时间和 token 的大问题；大厂可能因为「无限猴子打字机」的规模效应察觉不到，个体用户却很痛。（较多人）
• 更直接的质疑：代码为什么需要全局记忆，注释不就是放「记忆」最合适的地方吗？（少数人） > 小错误和无关注释会滚成雪球，吃掉大量时间和 token。（@writeslowly）

主张把人类已有的工程流程搬到 AI 上

• 生命科学和航空里的 CAPA（纠正与预防措施）流程可以直接借用：出错后要追根因，并且修正的是「让错误得以发生的流程」，再把修正并入 SOP 并重新培训。（较多人）
• 关键争议是这步要不要全自动：CAPA 由 agent 全权处理，还是必须有人工审批。（较多人）
• 更系统的设想是把质量指标定义、分析和报告做成「工程保障」模块，因为每个项目的成功与质量定义都不同。（少数人）
• 有观点认为最佳核心模式是加一层「工程经理 agent」：它先用工程实践判断全局，挡在人类前面处理所有 coding agent 的呼叫，只在真正阻塞时升级给人类，平时把下层信息整理成报告。（较多人）
• 但这又带来新问题：这些本来交给新人来建立代码库心智模型的活被自动化后，上下文怎么传递给仍需执行「非自我驱动」动作的人类？（少数人）

对「一键生成好玩游戏」这类宣传的集体嘲讽

• 文章开头这句被反复点名：有人追问到底有哪些例子，说各次模型发布看到的都是同一款单关卡卡丁车，谈不上好玩。（较多人）
• 有人直接说看到这句就不读了，还有人一连串大笑表示「又来了」。（较多人）
• 顺带的观感问题：整篇读起来像下一支糟糕的厂商广告。（少数人）
• 更实质的要求是拿出证据：首页该有个简单的 bug 处置统计（已修／无法复现／不予修复），而随机抽查文章首页那个例子，Pull Request 最后是作者道歉称自己没做尽职调查并关闭。（较多人） > 抽到的那个例子，PR 结尾是作者道歉说自己没做尽职调查，然后关掉了。（@wrs）

已经在用 agent 交付真实项目的人

• 有人称自己用 agent 写生产软件已经有一段时间，并直接贴出项目。（少数人）
• 有人把 AI 集成进应用，源码嵌进二进制，被质疑数字时应用可以自辩、发现真 bug 就告知用户并开单，下一步是让它自己修自己。（少数人）
• 「生态驱动开发」的实践：不直接让模型写游戏，而是先让它做一个带仪表盘、记忆和规格文件的工具，用来记录规格、向人提问并保存选择，从而减少上下文占用、并行起更多 agent、让人也能跟进进度；代价是每次模型更新都要重新摸索调优方式。（少数人）
• 角色焦虑与释然并存：是不是注定越来越像产品设计者、越来越少像软件工程师——有人不再碰代码，反而终于把一直想做的想法做出来并发布了，意识到代码从来只是手段。（较多人）
• 也有冷嘲：这是在问「怎么让自己更可替代」。（少数人） > 我以前执着于架构和逐行优化，现在完全不碰代码，却真的在做并发布东西了。（@rafaelvasco）

认为 AI 生成代码留下的债正在到期

• 有人看到大量「规模化」工作（其实就是清理）都花在过去两三年产出的 AI 垃圾上。（较多人）
• 另有一种不耐烦：做东西比写博客便宜之后，希望「写博客讲自己在做」的文体消失，宁可看成品。（少数人）

有价值的补充

• CAPA 在低容错行业的具体形态：严重故障后要归档进 SOP、重新培训、审计时需出示 CAPA 证据、SOP 版本和培训记录——大多数工程团队没有这种纪律，但正是它的对照意义。（@CharlieDigital）
• 记忆该放哪里的冷知识式反问：代码注释本来就是为人发明的「记忆」，未必需要额外的全局记忆层。（@vb-8448）
• 分层 harness 的预测：随着自我驱动代码库成为目标，会出现第二层面向应用的 harness，与面向 agent 的 harness 正交，用来表达为某个具体应用涌现出的「软件工厂」。（@rrook）
• 环境决定论的旁证：Windows 缺乏能保底的 UI 框架与设计模式，反过来说 Plan 9 那类约束更强的环境可能更适配自我驱动。（@sroerick）
• 自我修改应用的两条并行路线：一是把人类移出网络防御的 OODA 循环，Servlet 库这类东西会变成带契约的、可自改的流体；二是 UX 自我修改，用户用文本框描述改动，工程重心转向建模「不可协商的部分」并提供原语，还要处理广告如何在这种情况下仍被送达。（@aerodexis）