32 篇博文 含有标签「人工智能」

先说个跟 agent 无关的场景。

你手底下有两种员工。一种，活派下去就没声了，到点交付，中间只找过你一次，因为碰上一件他拿不准、也确实不该由他拍的事。另一种，一天问你八遍：这个能不能改？那个现在做还是等等？我这么弄行不行？每一步都要你点头。说是管理，其实你是在陪他干活。

第二种员工，我们习惯说他"还不够成熟"。可带过团队的人都知道，这事往往不怪人。他手上没有一份说得清的授权范围，不知道哪些决定归自己、哪些必须请示；也没有一条明确的验收标准，不知道做到什么份上算完。这两样你不定下来，再能干的人也只能一直回头问你。

现在把这两种员工换成 agent。你会发现你手上那个，基本是第二种。

而且它比新人还麻烦一点。新人心里没底的时候，自己是知道没底的；agent 最弱的地方偏偏就是"发现自己不对"，这个后面有数据。所以指望它慢慢"成熟起来"更没戏，只能把话写到纸面上。

这篇想回答的就是那个问题：怎么才能不当这个保姆。 下面四件事：为什么你盯着也没用、它现在能自己跑的那部分到底靠什么、"什么时候来找你"该怎么定，以及你该看哪儿，还有那件怎么也交不出去的事。

过去写一个功能要一整天。现在，一句话丢给 agent，几分钟就有了。

这件事的第一层意思大家都感受到了：产出变便宜了。但它还有第二层，容易被兴奋盖过去——当你过去要花钱买的东西突然几乎免费，那笔钱不会凭空消失，它只是搬了个家，搬到另一样还稀缺的东西头上。

代码不再稀缺。那还有什么稀缺？是你决定做什么、在哪儿喊停、看见那个别人没看见的问题——是你的注意力。

这不是"人更重要了"这类安慰话，而是一笔很实在的账：当一种投入变得又便宜又充裕，值钱的部分就会顺着往上游挪，挪到那个还稀缺、又跟它互补的环节。AI 把单位产出批发到几乎不要钱；价值于是挪到了它的上游——注意力。

所以这篇的主张很短：便宜的是代码，贵的是注意力。 但我想把话说全。注意力更值钱，是因为它的杠杆变大了；而杠杆是双刃的——它按同一个倍数放大你对的判断，也放大你错的判断。更麻烦的是，一旦"注意力"成了那个要被考核的稀缺资源，它立刻会被做假。

接下来我想一步步说清楚：这笔账为什么成立、杠杆到底有多大（这里有一个必须坦白的空白）、它为什么反过来又成了新的瓶颈，以及它逼你付出的代价。

用过 AI 编程 agent 的人，大概都见过这一幕：agent 忙活了一阵，信心满满地汇报——“所有测试通过 ✅”。你打开页面一看，白屏；或者接口直接 404。所谓“通过”，有时候只是 agent 自己觉得通过了。

这正是当下 AI 辅助开发的尴尬之处：写代码已经不是瓶颈了，瓶颈是验收——在你不亲自盯着、不逐个功能点一遍的前提下，怎么确认 AI 交付的东西端到端真的能用？笔者在《AI 的最后一公里，不是智能，是基础设施》里论证过这个判断：智能已经够用了，缺的正是这一类基础设施。

目前常见的两种做法都不理想。一是 每次改动后人工验收：跟不上 agent 的产出速度，而且人眼恰恰看不见那类最要命的问题——系统自称一切正常，实际某条关键路径已经悄悄断了。二是写 端到端（e2e）测试：e2e 测试本质上是一段需要长期维护的程序——异步、等待、重试、flaky——agent 一重构底层实现它就断；更何况如今不少测试本身也是 AI 写的，运动员兼职裁判，这样的绿灯含金量可想而知。

笔者认为还有第三条路，于是我们做了 Duhem——一个开源的整体性验证（holistic verification）工具。这篇文章介绍它是什么，以及它最近在我们自己的产品上抓住的一个真实 bug：那个 bug 连容器自带的健康检查都骗过了，Duhem 却把它拦在了发布之前。

2021 年 4 月，笔者写过一篇《为什么现代软件工程离不开项目管理》；2022 年 9 月，写了《你的团队在正确实践敏捷吗》；同年 12 月，又写了《为什么需要在软件项目中考虑复杂度》。当时觉得这是三个不同的话题：一篇讲流程，一篇讲方法论，一篇讲架构。最近把它们翻出来重读，才发现它们其实在绕着同一个问题打转：人多了，为什么反而慢了？ 复杂度那篇的引言甚至直接写着："随着项目规模的增长，复杂度会以指数级的速度增加，如果不加以控制，最终会导致项目的失败。"

这些年带团队，这个问题也从纸面落到了身上。项目延期，第一反应是加人；人加进来了，进度反而更糟——新人要熟悉上下文，老人要停下来带新人，会议多了一倍，对齐的成本涨得比产出快。五十年前 Fred Brooks 在《人月神话》（The Mythical Man-Month，1975）里就把这个现象说透了："往一个已经延期的软件项目里加人，只会让它更晚交付。"这句话程序员都听过，也都点头。但严格说，它一直只是一句格言，算不上一条定律——没有哪家公司能拿自己的团队做对照实验，去验证它到底有多准。

有意思的是，最近这件事出现了转机，而带来转机的不是管理学，是 AI。2025 年底，MIT 和 Google Research 的研究者测了 180 种 agent 系统配置，结果活脱脱是《人月神话》的复刻：在必须一步接一步完成的任务上，每一种多 agent 方案都比单个 agent 更差，差 39% 到 70%；集群规模超过三四个 agent，加得越多越糟。人月神话诞生五十年，第一次有了对照实验——只不过被试不是人，是 agent。

这就是本文想讲的事：AI agent 团队正在精确复刻人类组织的老毛病；而更有意思的另一半是，它是历史上第一个能把这笔账完全算清楚的组织形态。

2025 年 3 月 11 日，Anders Hejlsberg 发表了一篇题为 A 10x Faster TypeScript 的公告：微软要把 TypeScript 编译器移植到 Go。

对大多数读者来说，这只是一条关于性能的新闻。对我来说，这条新闻却把我五年前写的三篇旧文串到了一起。2021 年，我在短短几个月里先后写过三篇彼此不相干的文章：一篇问 大红大紫的 Golang 真的是后端开发中的万能药吗，一篇论证 为什么 TypeScript 是开发大型前端项目的必备语言，还有一篇夸 C# 的开发体验——那篇文章里我顺带提过一句当时看来只算趣闻的事实：TypeScript 和 C# 出自同一人之手。五年后，三篇文章的主角在同一个仓库里会师：我称为"必备"的那门语言的编译器，用我当年审视过的那门语言重写，主导者正是 TS 与 C# 共同的创造者。我知道这几篇文章之间有联系，但没想到它们会以这种方式交汇。

这场会师的价值不止于怀旧，它暴露了这场争论底下悄悄发生的变化。2021 年，咱们争的是哪种语言对"人"更友好：谁的语法更干净，谁的学习曲线更平缓，谁的类型系统更不烦人。这场争论至今没有结束，但裁判换了。从那之后，AI 编程智能体（coding agent）成了生产代码最高频的作者之一，也是代码的第一读者。agent 不在乎 Go 的错误处理有多啰嗦，也不嫌 TypeScript 的类型标注有多累赘。它只关心两件事：一是 多快拿到反馈，二是 反馈能不能被信任。

这个观察就是本文的核心论点，我刻意用最保守的说法来陈述它：当 agent 加入你代码库的作者行列，技术选型会多出两个必须优先考虑的判据——agent 的反馈周期（一次"修改代码 → 获得可信反馈"要多久）和 验证信号密度（每一轮循环中，有多少对错能由机器直接裁决，不需要人）。这两个判据不会取代以人为本的旧判据，但会给它们重新排序。而在新的排序之下，2021 年那场语言之争的判决，有的被坐实，有的被推翻。

为了把话说周全，接下来我会先做一轮站内考古，看看 2021 年我们究竟在争什么；然后给两个新判据下精确定义；再检视 2025 到 2026 年的三组证据；随后让最强的反方论证单独占一节；最后给出一个小小的选型框架——你完全可以不同意它，但至少能清楚分歧出在哪里。

亚马逊云科技中国峰会，2026 年 6 月 23–24 日，上海。

2026 年 6 月，我在亚马逊云科技（AWS）上海峰会上做了一场分享，大概是全场"最不性感"的一场。一上来我先澄清了一句：我们的 Nova，不是 Amazon 那个 Nova。我幻灯片上的 Nova，是我在 HP 带队做的一个内部平台；全场其他人挂在嘴边的 Nova，才是亚马逊的前沿大模型。台下笑了。一个撞名的小玩笑，却也恰好划出了这篇文章要讲的那条线——接下来的时间里，我讲的是任何主论坛都懒得碰的东西：我们怎么把一套报表系统，从 Power BI 搬到了 Amazon Athena 加 Apache Iceberg 上。那是个三十分钟、300 级的进阶专题，排在六楼，离楼下的人群远远的。

会场楼层导览：专题演讲（包括我那场）在六楼，主论坛在五楼，展厅在楼下。

而一楼的展厅，卖的全是"性感"的另一面。宇树（Unitree）的人形机器人（humanoid robot）在灯光下伸手抓取；一只标价 ¥9,999 的灵巧手（dexterous hand），冲着镜头比了个耶；一块屏幕上，一群编程智能体（coding agent）全程没人插手，自己把软件交付了，另一块屏幕上，AI 把一段足球比赛录像拆成了战术和球员指标。聚光灯下，智能正学着感知、学着创造、学着在物理世界里行动。

楼下一楼的展厅：人潮都在这儿。

这个反差，就是这篇文章的论点。过去两百年，产出是跟着人头走的——想多干，就得多招人。AI 正在掐断这条线：产出开始靠基础设施（模型、算力、数据）撑着，而不再死死绑在人力上。这就是智力的工业化。和第一次工业革命一样，最后赢的不会是手握最炫机器的人，而是给这些机器铺好地基的人。我那场"无聊"的迁移就是个缩影：让报表变好用的，不是换了个更聪明的模型，而是把脚下的地基换了——刷新从 4–6 小时压到 1 小时；而原本只能盯着看的报表，如今成了谁都能用大白话直接发问的数据。

所以这篇文章，会从地基往上写。先看展厅里被围观的三道前沿——会感知、会创造、会行动的机器；再看撑着这三样的那一层，也就是我专程跑去上海讲的那件事：决定它们到底能长多高的数据底座（data foundation）。

2026 年的每一场 AI 发布会都是同样三张幻灯片开场：更大的模型、更快的芯片、更聪明的 Agent。真正缺失的是第四张——这些东西到底怎么送到用户面前。而这张缺失的幻灯片，恰好就是接下来十年价值最集中的地方。它不会靠又一轮模型微调产生，而会靠我们这个技术栈里最不性感的那一层：基础设施（Infrastructure，俗称 Infra）。

数据也支持这个判断。麻省理工学院（MIT）2025 年《State of AI in Business》报告显示，95% 的生成式 AI 试点无法进入生产。Gartner 的调研表明，只有 15% 的 IT 应用负责人在试点完全自主的 Agent，而整个 Agent 市场预计从 2025 年的 78 亿美元扩张到 2030 年的 526 亿美元。瓶颈不在智能。前沿模型 在 SWE-bench Verified 上已经聚集在 70–75% 区间。真正的瓶颈是从"一个能写代码的模型"到"一个能交付产品的组织"之间的所有环节——而这些环节，说到底都是 Infra。

把"暴论"说得直白一点：编程变得廉价，Infra 却在变得稀缺。AI 叙事习惯把 DevOps、CI/CD、容器、Kubernetes、云架构这些东西当作"已经解决的水管问题"，但它们即将成为把 AI 能力变成可交付产品的头号杠杆。理由很朴素：Agent 现在能写代码，但它自己跑不起一次构建，也扛不下一次部署，更没法独自决定一次回滚、开通一个区域。它需要一个底座替它做这些事——而这个底座，正是过去二十年 DevOps 攒下来的、经过无数次故障检验的、几乎零成本的遗产。

六大协议。六个自动化级别。十七款工具。十二项预测。一张交互式全景图将它们串联起来。

AI Agent 交互全景图是我构建的一个开源双语单页应用，旨在厘清 2026 年 AI Agent 如何与开发者、编辑器、工具以及彼此之间进行交互。本文将梳理其中引入的关键框架——以及构建过程中涌现的洞察。

SWE-bench 评分在短短 14 个月内提升了 50%——从 2024 年 10 月 Claude 3.5 Sonnet 的 49% 跃升至 2026 年 1 月 Claude 4.5 Opus 的 74.4%——你可能会认为 AI 智能体（AI Agents）已经征服了软件工程领域。然而，大规模部署这些智能体的企业却讲述着不同的故事。Triple Whale 的 CEO 描述了他们的生产环境实践："GPT-5.2 为我们解锁了一次彻底的架构转型。我们将一个脆弱的多智能体系统简化为单个配备 20 多种工具的超级智能体……这个超级智能体更快、更智能， 维护难度降低了 100 倍 。"

今年年初，我被 Claude Sonnet 3.7 的 AI 编程能力深深震撼。那时 "Vibe Coding" 这个词还没流行起来，但我做的正是这件事——让 AI 生成代码，我只负责引导对话。感觉像魔法一样神奇。直到问题开始浮现。

几周后，我注意到一些规律：代码冗余越来越多，实现方向偏离了最初的设想，AI 在不同会话之间丢失上下文导致返工不断增加。蜜月期结束了。我需要一套结构化的方法，但又不想引入那些拖慢开发速度的重型流程。