11 篇博文 含有标签「软件工程」

先说个跟 agent 无关的场景。

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

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

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

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

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

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

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

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

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

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

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

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 年的每一场 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 倍 。"

引言：从理论走向实践​

在本系列的第一部分中，我们打下了计算限制的概念基础：基本限制与工程限制的区别、四层计算层次结构、形式化复杂性测量，以及智力-可计算性悖论。我们探讨了为何一些看似简单的问题（如停机问题）在数学上无解，而看似需要复杂智力的问题（如机器翻译）却是可判定的。

第二部分，我们从抽象理论走向实际应用。 本文探讨这些基本限制如何体现在日常工程决策中，考察历史如何揭示：理解约束反而能释放创新，并将计算限制与关于逻辑、数学和意识的深刻哲学问题联系起来。最后，我们会提供一个实用框架，帮你立即分类问题并做出更好的工程决策。

引言：代码的宇宙速度限制​

1905年，阿尔伯特·爱因斯坦（Albert Einstein）证明了一个革命性的结论：没有任何东西能够超越光速。这不是更好的技术可以克服的工程限制，而是时空本身的基本属性，编码在现实的结构中。三十年后的1936年，艾伦·图灵（Alan Turing）为计算证明了一个同样深刻的结果：没有任何算法能够确定一个任意程序是否会停机（称为停机问题（Halting Problem））。与爱因斯坦的光速屏障一样，这不是当前计算机或编程语言的限制。这是一个数学确定性，无论我们的机器变得多么强大，或者我们的算法变得多么聪明，它都将永远为真。

现代软件工程在这些基本限制的阴影下运作，尽管大多数工程师将它们体验为令人沮丧的工具限制，而不是数学确定性。你可能经历过这样的情况：静态分析工具错过了明显的错误，测试框架尽管有100%的覆盖率却无法保证正确性，AI助手生成的代码需要仔细的人工审查。当营销材料承诺"完整的自动化验证"或"有保证的错误检测"时，你可能会感觉有些不对劲——这些声明听起来太好了，不像是真的。

确实如此。你遇到的限制不是等待更好工具的临时工程挑战，而是基本数学不可能性的表现，就像光速或绝对零度一样不可改变。 理解这些限制从约束转变为竞争优势：知道什么是不可能的，可以让你将精力集中在可实现的事情上，就像物理学家利用相对论实现了GPS卫星和粒子物理学，而不是浪费资源试图超越光速。

如果你是一名开发人员，曾经想知道为什么尽管经过数十年的工具开发，某些问题仍然存在，或者如果你是一名技术领导者，正在评估关于革命性测试或验证技术的声明，这篇文章提供了关键的背景。理解计算限制不是失败主义，而是工程成熟的基础。 最好的工程师不会忽视这些边界；他们深入理解这些边界，并在其中出色地工作。

这段旅程探讨了计算限制如何反映物理定律，为什么"困难"问题与"不可能"问题有根本性的不同，以及这些知识如何赋能更好的工程决策。我们将从舒适的物理类比穿越到抽象的计算理论，然后回到你明天就可以应用的实用框架。在这个过程中，你会发现为什么了解游戏规则会让你在游戏中更有效，以及为什么计算历史上的每一次突破性创新都不是通过忽视限制，而是通过深入理解限制而出现的。

引言：复杂功能开发的挑战​

每个开发者都知道那种盯着复杂需求而不知从何开始的感觉。现代软件开发越来越多地涉及构建整合多个服务、处理不同数据格式、协调各种 API 的系统。在初始规格中看似简单的东西，往往会演变成复杂的相互依赖组件网络，每个组件都有自己的约束和边界条件。

这种复杂性在几个常见的开发挑战中显现出来，无论团队的经验水平或技术栈如何，都会面临这些挑战。项目经常因为需求在实现过程中的演变而遭受范围蔓延。开发者花费大量时间向 AI 助手或团队成员解释上下文，经常重复相同的架构约束。技术债务在开发者因压力做出仓促决定时累积，导致系统变得越来越难以维护和扩展。