你看过那个 demo。一个工程师坐在那里，向 AI agent 描述需求，几分钟后一个完整功能就出来了。CI 通过，测试绿色，看起来什么都能自动化。于是有人开始算：如果一个人靠 agent 能做五个人的活，那十个人的团队是不是两个人就够了？
这个推理的每一步都合理，但结论是错的。
错不在"agent 能加速开发"——这确实是真的。错在把 demo 里看到的表现当成了生产环境的基准。Demo 和生产之间的关系不是"做了 90%，再做 10%"，而是水和蒸汽的关系：不是把温度做得更用力，而是发生了状态变化。
Demo 骗人的方式不是隐藏Bug，而是消除失败条件
一个典型的 agent demo 在什么环境下运行？一个人操作，这个人懂系统；问题范围已经被人工约束过；没有历史包袱，没有各种奇怪的用户环境；不用操心每次调用的 token 成本；没有 SLA，没有长程一致性要求。
这些不是"简化"——是消除了生产环境里导致失败的根本条件。Demo 不是在隐藏 bug，它是在一个 bug 不容易产生的地方运行。
Dan Breunig 用一个精准的区分描述了这个问题：personal software 和 capital-P Products。他用 Claude Code 很快做了一个 RSS 发现的浏览器插件 FeedPass，功能完整，运行良好。但他明确说："所有那些我没做的事情——那些才是把个人软件变成 Products 的东西。我们还没说到营销、支持和更多……产品开发和支持的最后 10% 才是痛苦所在。"
"最后 10%"这个说法本身就是误导。那不是 10% 更多工作，是一个完全不同类别的工作。
翻车的不是运气，是结构
如果你觉得"这不就是所有新技术都会有的初期问题"，仔细看这些案例。它们不是随机失败。它们失败的方式可以归为三类，而这三类恰好对应了 demo 环境提供的三个保护条件——当这些条件在上线时被逐个撤掉，系统就以可预测的方式崩溃。
保护条件一撤掉：谁来接住错误的答案
Demo 环境里，输出被人接住了。操作 demo 的人是专家，他扫一眼就知道 agent 哪里说错了，顺手纠正。这个过程自然到甚至不被注意到。但生产意味着输出直接到达不会纠错的人手上——这时候 LLM 的一个特性就变得致命：它的自信度和正确度完全无关。一个错误答案和一个正确答案读起来一模一样，语气同样笃定、格式同样专业、引用同样看起来真实。
2024 年，加拿大航空的客服 chatbot 编造了一个丧亲票价政策。一位顾客因亲人去世联系加航，chatbot 告诉他可以申请退款，还详细说明了流程。这个退款政策完全不存在。顾客拿这个承诺去兑现时，加航试图撇清——说 chatbot 是"独立的法律实体"，公司不应为其承担责任。法院不买这个账，判决加航需对 chatbot 的幻觉负责。
这个案例揭示了什么？在 demo 里，这个 chatbot 通过了所有展示——它看起来知识丰富、语气得体、对答如流。没有人会在 demo 时问一个编造的政策来测试它。而一旦上线，面对真实的、不知道答案应该是什么的用户，自信的幻觉变成了法律负债。demo 里，错误被专家拦截在终端；生产里，错误直接变成了行动。
同样的事发生在 2023 年的 Mata v. Avianca 案件中。纽约律师 Peter LoDuca 用 ChatGPT 准备法庭文件，ChatGPT 生成了多个判例引用——包括案件名、法院、日期、判决摘要，完美得像法律数据库的输出。他把这些写进了法庭文件提交给法官。问题是：这些案件全部不存在。法官检索不到任何一个引用。当被质问时，LoDuca 承认他"没有验证 ChatGPT 提供的来源"。他被罚款，案件声誉受损。注意这个结构：律师本应是验证者，但他也没认出幻觉——因为 fake citations 看起来和真的没有任何区别。
Google AI Overview 把这个模式推到了极致。2024 年上线后，它建议用户吃石头、往披萨酱加胶水、说奥巴马是穆斯林。每一个荒谬输出都来源于 LLM 生成权威文本时不经任何事实核查的机制。Demo 里处理正常查询效果很好；到了 Google 的体量，每天几十亿次查询，每一个可能的输入都变成了一次对抗性测试——而你无法预判哪些输入会触发荒谬输出。
这三个案例的共同点不是"AI 会犯错"——所有系统都会犯错。共同点是：AI 犯错的方式——高度自信的编造——恰好是人类最难察觉的错误类型。 一个不确定的答案你会去验证；一个语气笃定、格式完美的错误答案，你会直接用。Demo 环境有专家在每一步拦截这种错误；生产环境把它直接送到了信任它的人面前。
保护条件二撤掉：错的代价有多高
Demo 环境里，错误的代价很低。Agent 给了一个不太好的方案？重跑。生成的代码有 bug？修了就是。成本是一次按键。但生产环境把 agent 的输出放进了一个代价结构完全不同的世界里——在医疗和法律领域，一个错误答案的代价可以是不可逆的。
IBM Watson Health 是这个模式最具警示性的案例。IBM 在 Watson 上花了数十亿美元，承诺用 AI 革命化癌症治疗。在受控的临床演示中，Watson 确实能生成治疗方案——看起来合理，跟教科书吻合，演示效果很好。但 2018 年，Internal Medicine 的调查揭露了生产使用的真实情况：Watson 经常推荐危险的方案。不是"不太优"——是直接违反患者的具体病情禁忌。一位出血风险极高的患者被推荐使用增加出血风险的药物。一位严重患者被推荐了在患者身体状况下明确禁忌的方案。
为什么会这样？Watson 的训练方式是从专家医生的推荐方案中学习。但它学到的是"在这个诊断下，通常开什么药"，而不是"当这个诊断和这个禁忌同时出现时，该怎么办"。人类肿瘤医生的推理是约束满足——在所有不违反患者已知条件的方案中，选最好的。Watson 做的是模式匹配——看到这个诊断，给出最常见的方案。两件事在简单案例里产出一样，在复杂案例（恰好是现实世界大多数案例）里产出完全不同。
纪念斯隆-凯特琳癌症中心的医生报告说，他们纠正 Watson 花的时间比它节省的时间还多。IBM 最终以巨亏出售了 Watson Health。
DoNotPay 的故事则展示了领域准入的假象。这个"AI 律师"在 demo 里能生成看起来合理的法律论点，帮你打停车罚单、写申诉信。演示效果惊艳——一个不用请律师就能自动化法律流程的工具！但它实际上因无证执业被监管处罚。问题不是它写的法律论点完全不对——在简单案件中，它写的往往是不错的。问题在于：法律推理真正的难度不是写论点，而是知道什么时候你写的东西其实不对。这正是法律教育的核心——数年的专业训练，目标不是怎么写辩词，而是怎么判断辩词的有效性边界。非律师用户恰恰无法做出这种判断，所以他们也是最容易被"听起来对但其实不对"的输出伤害的人。
这两个案例的核心不是"AI 不够好"。核心是：在某些领域，错误的代价结构让"90% 正确"从"还不错"变成了"不可接受"。 Demo 里，10% 的错误意味着再跑一次；在医疗和法律领域，10% 的错误意味着不可逆的后果。保护条件二撤掉时，同样的可靠性水平从"够用"变成了"危险"——可靠性本身没有变化，是代价结构变了。
保护条件三撤掉：跑得时间一长会怎样
Demo 天然是短的。你展示三五分钟的效果，agent 表现好，掌声，结束。但生产环境要求 agent 长时间运行、处理多步骤任务——而 agent 的表现随运行时间延长而系统性退化。这不是偶发故障，是类似于热力学熵增的基本属性：每多做一步，累积的微小偏差就多一层，不加外部纠正的话，系统会越来越偏。
AutoGPT 和 BabyAGI 是 2023 年最火的自主 agent 框架。Demo 堪称完美：你给一个目标——"帮我研究竞争格局并写一份报告"——agent 自己分解任务、搜索网络、整理信息、生成文档。前三到五步看起来像真正的自主智能。然后它开始出现目标漂移：本来在研究 A 公司，突然觉得需要先了解一下整个行业，然后行业又连到宏观经济，然后宏观经济又连到货币政策……每一步都"合理"，但离最初的目标越来越远。更多情况下，它直接进入循环：反复搜索同一个查询，反复总结同一段文本，反复生成同一个失败的计划然后重试。
这不是 AutoGPT 的特殊 bug。Devin——2024 年被宣传为"第一个 AI 软件工程师"的产品——在更长的时间尺度上展示了同样的退化。它的 demo 能力惊人：给它一个真实的 GitHub issue，它自己读代码、理解上下文、找到问题、写修复、跑测试。但 SWE-bench（真实世界软件工程任务基准测试）的数据不撒谎：初始完成率 13.86%——86% 的任务失败了。经过大量工程优化后提升到 23%，仍然四分之三失败。
为什么 demo 和 benchmark 差距这么大？因为 demo 选择的是已知能跑通的任务，运行时间短，上下文干净。Benchmark 把它扔进真实世界：代码库庞大、约束复杂、需要多步推理保持一致。每多一步推理，之前的上下文就有被压缩或遗忘的风险，之前的一个小偏差就可能被放大。Demo 展示的是 agent 在短程干净环境中的上界；benchmark 测的是长程 messy 环境中的实际水平。两者之间的差距不是量上的，是质的。
更日常的版本你可能亲身经历过：用 Claude 或 Cursor 写代码，前几个文件很好，越写到后面，它开始忘记之前的约定、前后矛盾、甚至"修"了一个东西却破坏了两个。每次修改在局部看都是合理的，但整体越来越不一致。Dan Breunig 用"温彻斯特神秘屋"来比喻这种状态：一个房子，每个房间单独看都没问题，但整体是一个越建越怪的迷宫——每个修改都是局部合理的，全局却越来越离谱。
为什么是这三个模式
回头看，这三个模式不是随便归纳出来的——它们分别对应了 demo 环境提供的三个保护条件：
| 保护条件 | Demo 里 | 生产里 | 崩溃模式 |
|---|---|---|---|
| 谁接收输出 | 专家实时纠错 | 非专家直接行动 | 权威性幻觉——自信的错误被当真 |
| 错误的代价 | 低（重跑即可） | 高（不可逆后果） | 越界危险——同样 90% 正确率从"够用"变"致命" |
| 运行时长 | 短（三五步） | 长（几百步） | 长程退化——偏差随时间累积 |
三个保护条件。在 demo 里全部满足，在生产里全部不满足。这不是随机的——它们是 demo 环境的结构性特征，不是你可以一个个修掉的 bug。你说"我多测试一下"解决的是模式一，但模式二和模式三照样崩。你说"我上护栏"解决的是模式二，但模式三的退化护栏也拦不住。这三个保护条件是同时撤掉的，而现有的工程手段只能逐个补，且每一个的补法都是一类全新基础设施。
这就是为什么 demo-production gap 是相变而不是鸿沟：不是因为差距大，而是因为跨越它需要的不是更多的同类工作，而是四类在 demo 语境里根本不存在的基础设施。
可靠性的非线性诅咒：90% 和 99% 的距离
这些案例指向一个核心数学现实：可靠性扩展是非线性的。
Demo 里 90% 的成功率看起来完美——因为你展示的就是那 90%。但在生产环境中，10% 的失败率在规模下是灾难性的。一个 agent 10 个任务成功 9 个听起来不错，直到它每天处理一万个任务、每天失败一千个。
从 90% 到 99% 比 0% 到 90% 难得多，从 99% 到 99.9% 又比那更难。多步 agent 让这更残酷：如果每步 95% 可靠，10 步链只有 60% 的成功率，20 步链是 36%。生产工作流经常涉及这个长度的链，也就是说单步可靠性必须极高才能让整个链路可用。数学没有商量余地。
而且 LLM agent 有一个传统软件没有的属性：非确定性。同一输入可能产生不同输出。你不能通过测试逼近可靠性，因为测试不能保证下次运行结果一样。这让 agent 的 demo-production gap 与之前所有技术转型有了质的区别——移动互联网的 gap 是碎片化和兼容性，云迁移的 gap 是架构重构，但这些都可以通过更多工程投入逐步解决。非确定性不能。
"一个人替代一个团队"——放大，不是替代
Simon Willison 说了一句大实话："我在写代码这件事上获得了 2 到 5 倍的生产力提升。但这大概只占我工作的 10%，所以我整体效率并不是 2 到 5 倍。"
Agent 加速的是工作的生产阶段。验证、判断、领域专业知识——这些不减少。Willison 把 LLM 比作"一个奇怪的实习生"：读了所有文档，同时是个狂热的阴谋论者，经常提出荒谬的想法，并且极度自信。"你不会让实习生未经审查就推到生产环境。"一个人监督很多实习生，仍然是瓶颈。
Dan Breunig 独立得出了同样的结论："我知道很多团队在把 agent 写的代码推入产品。但他们测试、支持、审查，以及更多。"团队还在，只是用了 agent。"一个人替代一个团队"的说法把生产加速度和总工作量混为一谈了。
更关键的是，agent 放大的是已有的专业能力，而不是替代它。资深工程师 + agent 明显优于初级工程师 + agent。Agent 没有拉平差距，而是扩大了它。Demo 的欺骗性部分来自操作 demo 的人几乎总是专家——他们的判断力在实时纠正 agent 的小错误，让一切看起来丝滑顺畅。普通用户没有这种纠错能力。
还有一个被低估的成本：验证负担不随生产加速等比例下降。审查 agent 生成的代码可能比审查人写的更难，因为你缺乏作者的意图信号。人类的代码审查受益于隐式沟通——命名选择、注释位置、结构决策都传达了作者为什么做特定选择。Agent 生成的代码缺少这种意图信号。Willison 自己的经历最能说明问题：Claude 写了一段 SQLite 代码，幻觉了一个 API 调用。Willison 向 GitHub Actions 提了 bug，后来才意识到 agent 搞错了。一个专家都被暂时蒙蔽了——非专家根本无法发觉。
相变而非线性：你需要的是另一类基础设施
所以这条"鸿沟"到底是什么？不是多做 10% 的工作。是从一个状态到另一个状态的质变。Demo 质量的 agent 输出变成生产质量，需要四类在 demo 中根本不存在的基础设施：
规格基础设施：AGENTS.md 文件、spec-driven development、context engineering。在 demo 里，专家操作者本人就是规格——他知道该做什么、不该做什么。在生产环境中，规格必须被显式编码。Breunig 分析过 Claude Code 的 system prompt——它有几十个条件性组件。这就是生产级 agent 规格的样子。
验证基础设施：Evals、回归测试、监控、LLM-as-judge 管道。在 demo 里，专家实时判断。在生产中，评估必须自动化、持续运行。Willison 说得直接："prompt engineering 最难的部分是评估。"
护栏基础设施：降级系统、人工介入检查点、升级路径、成本限制。在 demo 里，出问题了人直接干预。在生产中，故障以规模和速度发生，护栏必须预先配置。
维护基础设施：Prompt 版本管理、模型迁移规划、模型更新时的回归检测。在 demo 里你觉得不对就改个 prompt 重跑。在生产中，prompt 变更可能破坏已有行为，模型更新可能悄悄降低表现。
这些在 demo 里全部不存在。在生产中全部是必须的。这就是为什么这条 gap 不是线性的——它需要的是一种在 demo 语境里没有对应物的工作。
历史不会重复，但会押韵
这个模式并不新鲜。互联网泡沫（1997-2001）、移动互联网（2008-2013）、云迁移（2010-2018）——每一次都遵循同一轨迹：
- Demo 消除了固有复杂性
- 早期采纳者（专家）获得 10x 价值，普通用户差得远
- 生产 gap 需要 3-7 年关闭，不是承诺的 6-12 个月
- Hype 期间建的基础设施反而是持久价值
- 具体的过度承诺（全自动 agent、一人团队、代码免费）在时间线上总是错的，但方向最终是对的
互联网泡沫里，大量资金投入初创公司，大部分失败了。但光纤网络、数据中心、LAMP 技术栈留下来了——它们支撑了后来的 Google、Amazon、Netflix。Agent 领域也一样：基础模型、API、eval 框架、context engineering 实践会是持久价值。"全自动 agent 替代整个工作流"的承诺可能是泡沫。
但有一个关键差异：非确定性。传统软件是确定的——同一输入始终同一输出。移动端的问题是碎片化，云的问题是架构迁移，但都可以通过更多工程投入逐步解决。LLM agent 的不确定性让整个 gap 有了质的不同。你不能靠测试达到可靠，因为系统本身就不保证可复现。
所以，一个人能不能替代一个团队？
能，但不是现在，也不是以人们想象的方式。
Agent 让小团队做以前需要大团队做的事，这已经发生了。但主要是通过加速生产阶段——把代码写出来更快了。验证、维护、边界情况处理、产品化这些工作没有消失，只是从一个人转移到了另一个人（往往是同一个人），而且还更难了。
真正的变化不会是"一个人做十个人的事"。更可能是"五个人做以前二十个人的事，但每个人要做更多种类的判断工作"。工作没有消失，而是从生产转移到了验证和判断。
Demo 是真实的——agent 确实能做出惊人的东西。生产 gap 也是真实的——从做出东西到可靠地、持续地、大规模地做出正确的东西，中间是一条相变，不是一条鸿沟。意识到这两件事同时为真，比相信任何一边都更有用。
参考文献
- Breunig, D. (2026). Two Beliefs About Coding Agents. . 提出 personal software vs capital-P Products 区分；"最后 10%是不同类别的工作"论述的出处.
- Breunig, D. (2026). The Cathedral, the Bazaar, and the Winchester Mystery House. . "温彻斯特神秘屋"比喻——局部合理修改如何导致全局离谱；agent 长程退化的可视化.
- Breunig, D. (2026). How Claude Code Builds a System Prompt. . 解剖 Claude Code system prompt 的几十个条件性组件；展示了生产级规格基础设施的实际复杂度.
- Breunig, D. (2026). The Rise of Spec Driven Development. . Spec 作为 agent 可靠性基础设施的论述；spec-driven development 的工程实践.
- Breunig, D. (2026). 10 Lessons for Agentic Coding. . 从实践角度总结 agentic coding 经验教训；"团队还在，只是用了 agent"的观察.
- Breunig, D. (2024). What Remains if the AI Bubble Bursts. . 与互联网泡沫的系统性类比；"基础设施是持久价值，具体承诺是泡沫"的模式归纳.
- Willison, S. (2024). Software Misadventures Podcast 采访. . "2-5x on the 10% of my job that is typing code"; "weird intern"比喻；验证作为核心瓶颈的论述.
- Willison, S. (2024). Not Digital God. . 专家用户 vs 普通用户的体验差异；agent 放大而非替代专业能力的观察.
- Weng, L. (2024). Hallucination in Large Language Models. . LLM 幻觉机制的技术分析；解释了为什么自信的错误是结构性特征而非偶然 bug.
- Anthropic Research. Building Effective Agents. . 从工程角度论述 composability 和 human-in-the-loop；间接论证了 fully autonomous agents 的 demo-production gap 是结构性的.
- Moffatt v. Air Canada (2024). British Columbia Civil Resolution Tribunal. AI chatbot 幻觉导致法律责任的标志性案件；公司需为 chatbot 编造的退票政策负责.
- Mata v. Avianca, 22-cv-01461 (S.D.N.Y. 2023). 纽约律师使用 ChatGPT 生成法庭文件，引用的判例全部不存在；律师被处罚. 报道见 Reuters (2023-06-22), Ars Technica (2023-05-27).
- Ross, C. & Swetlitz, I. (2018). IBM's Watson supercomputer recommended 'unsafe and incorrect' cancer treatments. Stat News. Watson Health 的深度调查；推荐违反患者禁忌的危险方案；医生纠正 Watson 花的时间比它节省的还多.
- DoNotPay AI Lawyer (2023). 因无证执业面临监管审查. 报道见 The Verge (2023-03), Reuters. 法律领域中"听起来对但其实不对"的输出如何伤害最缺乏判断力的用户.
- AutoGPT / BabyAGI (2023). 自主 agent 框架在长程运行中进入循环和目标漂移的社区共识性失败模式. 大量用户报告见于 GitHub issues 及社交平台.
- Cognition AI. Devin SWE-bench performance data (2024-2025). 初始完成率 13.86%，后提升至约 23%；持续更新的排行榜见 swebench.com.
- Google AI Overview incidents (2024). AI 生成搜索摘要输出荒谬建议（吃石头、加胶水等）. NYT, Washington Post, The Verge 等均有持续报道.