代理工程：构建你自己的软件宝可梦大军

一个人如何用自主 AI Agent 替代了一个 15 人的工程团队——以及这一路上的惨痛失败。

本文内容为休斯顿大学 CIVE 7397 课程客座讲座材料。

View Deck

我大学没学过计算机。我在北京读的是管理专业。不知怎么地，我最后去了耶鲁读计算机硕士，然后去了 Uber 开发服务 9000 万用户的系统，接着又去了 Brex 和 Airbnb，最终创办了自己的公司。

我告诉你这些是因为谁能开发软件的游戏规则正在被重写——而你的背景可能比你想象中更有优势。

第一幕：单打独斗的磨练

每天 150 行代码是天花板

每个工程师的起点都一样。空白的编辑器。闪烁的光标。一个写着“开发订阅计费系统”的任务。

一位资深工程师——有着十年经验的人——每天大约产出 100 到 150 行生产环境代码。剩下的时间都花在了会议、代码审查、调试和上下文切换上。这就是天花板。

“10x 工程师”是我们追逐的神话。但即使是 10x 工程师也依然只有一个人。生产力随人数线性增长。想交付得更快？那就招更多的人——而每招一个人都需要三到六个月的入职培训。

最糟糕的部分是什么？知识只存在于人们的脑子里。为什么那个系统要那样设计？去问 Chen。哦，Chen 离职了。祝你好运。

真正的瓶颈：大脑带宽

在 Uber，任何任务最难的部分从来不是写代码。而是调研阶段——弄清楚哪里需要改，以及改什么。

当代码库极其庞大、文档缺失，而前任负责人已经离职时，你会花费 80% 的时间来建立对他人的系统的心理模型。瓶颈始终是人——他们的可用性、他们的上下文窗口、他们的单点故障风险（Bus Factor）。而不是算力。也不是想法。

然后，有些东西出现在了工作室门口。

Copilot、Cursor 和“神奇糖果”效应

你发现了 Copilot。接着是 Cursor。然后是 Windsurf。按下 Tab 键，整个函数就凭空出现了。这就像是在经历了多年的手动练级后，有人递给了你一颗“神奇糖果”（Rare Candy）。

这种提升是真实存在的——我们现在有了实地研究：

• 微软和埃森哲对 4,000 名开发人员进行了一项随机试验：合并的 PR 增加了 26%。
• Cognition 的 Devin 完成文件迁移的速度比人类快 10 倍。
• 初级开发人员的生产力提高了 35%；资深开发人员提高了 8% 到 16%。

但即使有了这些提升，**天花板依然是你。**你砍柴的速度变快了，但你并没有建立起一家工厂。你依然是那个阅读规格说明、做决定、在凌晨两点调试代码的人。

神奇糖果强化的是你。它并没有给你一只宝可梦。而打破天花板的唯一方法，就是彻底把自己从生产线中抽离出来。

第二幕：收服你的第一只宝可梦

从敲代码到写规格说明（Specs）

就在这一刻，一切都改变了——而且它简单得令人难以置信。

你写一个规格说明。不是代码，而是规格说明（spec）。验收标准、约束条件、边界情况。你把它交给像 Claude Code 这样的自主 Agent。然后你走开。

Agent 读取你的代码库，规划方案，编写代码，运行测试，读取错误，修复错误，循环往复。等你回来时，一个 Pull Request 已经准备好了。你刚刚收服了你的第一只宝可梦。

这与 Cursor 或 Copilot 有着本质的区别。那些是电动工具——它们增强你的产出。而自主 Agent 是一个独立的劳动力。核心技能从提示词工程（Prompt Engineering）转向了上下文工程（Context Engineering）：设计你的宝可梦所运行的世界。

我坚持的工作流程

我总是从“计划模式”（Plan Mode）开始。Agent 分析代码库并提出方案。我审查方案，进行调整，然后说“执行”。

我有一条从不打破的原则：“你自己去调试。我只要结果。” Agent 必须自己 curl API、阅读日志，并编写测试来证明自己的工作。如果它无法自我验证，说明规格说明写得不够好。

为什么上下文工程优于提示词工程

你已经收服了第一只宝可梦。你该如何让它变强？

Anthropic 官方指南指出，Agent 的质量与其说取决于模型本身，不如说取决于其上下文的结构和管理方式。模型是引擎。而上下文——规格说明、代码库结构、反馈信号——则是技能书。你教给它什么，决定了它的战斗力。

三种输入至关重要：

• **规格说明（Specs）。**在 Agent 写下第一行代码之前，写出带有验收标准的清晰规格说明。模糊的规格说明会产生模糊的代码。精确的规格说明则会产生可运行的软件。
• **代码库。**结构化你的代码仓库，以便 Agent 能够导航——清晰的文件命名、整洁的模块边界、及时的文档更新。Agent 读取代码的方式与新员工入职第一天的方式完全一样。如果新员工会迷路，你的 Agent 也会迷路。
• **反馈信号。**测试、类型检查器、Lint 工具。如果没有反馈，你的宝可梦会自信地制造垃圾并告诉你一切正常。我们都遇到过那样的同事。

规模化缺陷：构建质检线

你的 Pokémon 编写了代码。代码编译通过。你感觉棒极了。

然后你运行了测试。一半失败了。代理幻觉出了一个不存在的 API 端点，使用了一个已弃用的库，并引入了一个微妙的竞态条件。

这是核心挑战： 没有质量控制的 Pokémon 会规模化地制造缺陷。你构建的最重要的东西不是生产系统 —— 而是质检线。

代理在一个紧密的循环中运作：编写 → 测试 → 失败 → 读取错误 → 修复 → 重复，直到每一项检查都变成绿色。神奇之处不在于第一次尝试就能得到完美的输出 —— 它永远做不到这一点。神奇之处在于反馈循环是在几秒钟内运行的，而不是几小时。

我在实践中的质检线：

• 后端： 代理使用 curl 请求真实的 API 并验证响应。
• 前端： Playwright MCP —— 代理打开真实的浏览器，导航 UI，点击按钮，并验证渲染的输出。
• 每一项任务： 代理将编写自己的测试作为交付物。

从代理中获得真正价值的团队并不是那些拥有最好模型的团队。而是那些拥有最严密质检线的团队。

从一只 Pokémon 到完整的阵容

一只 Pokémon 处理一个有边界的任务。真实的软件项目有许多移动部件。你需要一个阵容 —— 而为了让阵容协同工作，你需要共享的工具集和共享的剧本。

MCP（模型上下文协议） 就是道具包。任何 Pokémon 都可以伸手进去拿取任何工具、任何 API、任何数据源。它给了你的代理一双手。

CLAUDE.md 和自定义技能 是训练师手册。自定义斜杠命令 —— /today、/blog、/ci —— 编码了可重复的组合招式。CLAUDE.md 是每个代理在启动时都会阅读的规则手册：相同的上下文，相同的标准，不需要时刻盯着。

正如 Anthropic 所建议的：寻找尽可能简单的解决方案，只有在需要时才增加复杂性。

你的阵容已经集结完毕。一切都在运行。在白板上看起来很完美。然后，它崩溃了。

深渊：当一切崩溃时

已发布的静默失败

最危险的失败不是响亮的失败 —— 而是静默的失败。

我曾有一个编程代理所做的修改通过了所有现有测试，在代码审查中看起来很正确，并发布了。几天后，我发现它破坏了一个任何测试都没有覆盖的微妙不变量。没有错误日志。没有崩溃。只是错误的行为，花了几天时间才追溯到代理的提交记录。

那是噩梦般的场景：一个 Pokémon 产生了 通过了质检 的缺陷工作。你的质检线存在盲点，而代理会找到每一个盲点。

研究证实了这一点

这不仅仅是我的经验。一项 NeurIPS 2025 的研究分析了跨越七个多代理框架的 1,600 个执行追踪，发现：

• 各框架的 失败率在 41% 到 87% 之间。
• 识别出 14 种不同的失败模式。
• 协作崩溃 是排名第一的类别，占所有失败的 36.9% —— 代理在交接过程中丢失上下文、相互矛盾、原地打转。

为什么增加更多代理会让情况变得更糟

在遭遇挫折后的直觉是：“我需要更多代理。” 这种直觉是错误的。

Google DeepMind 和 MIT 对此进行了严格测试 —— 180 种配置、5 种架构、3 个模型家族：

• 中心化编排器在可并行任务上将性能提升了 80.9%。
• 但在串行工作中，所有 多代理设置都使 性能下降了 39–70%。
• 收益在 4 个代理时达到平台期。 超过这个数量，你就在支付没有回报的协作税。
• 无协作的代理会将错误放大 17.2 倍。即使有编排器，也会放大 4.4 倍。

教训是：不要增加 Pokémon 的数量。要增加 正确 的 Pokémon。

第三幕：更聪明地重建

在每次爆炸中幸存的四个原则

盲目的乐观已经消失。取而代之的是：来之不易的知识。

SWE-Bench 排行榜评估了 80 种独特的代理编程方法，发现没有单一架构能始终获胜。但有四个原则屹立不倒：

1. 质检重于生产。 你的团队之所以溃败，是因为未检查的错误产生了级联反应。修复方法不是更强大的 Pokémon —— 而是更好的质检关卡。
2. 上下文胜过模型。 代理失败不是因为模型弱。它们失败是因为缺乏上下文。更好的技能书每次都能击败更好的引擎。
3. 从一个开始。 收益在四个代理时达到平台期（根据 DeepMind/MIT）。从简单开始。只有在被迫时才增加代理。
4. 与 AI 共同学习。 不要只是分配任务 —— 让代理审计你的代码库，研究最佳实践，并更新 CLAUDE.md。每一次对话都会让下一次变得更好。

关于成本的一个实用说明：你不需要一大笔钱来开始。Claude.ai 免费层、GitHub Copilot 学生计划和 Cursor 免费层能让你走得很远。我通过 CLI 到 API 代理，在多个每月 200 美元的订阅上运行我的整个操作 —— 成本大约是直接调用 API 的 1/7 到 1/10。

一个人的道馆实际上是什么样子的

这不是比喻。这是我今天的真实配置：

• 10 个 Claude Code 代理 同时在 4 台 Mac 和 6 个屏幕上运行。
• 5 个代理作者 通过自动化的 yarn blog loop 24/7 全天候产出 SEO 内容。
• 1 个人 经营着一家在两年前可能需要 10–15 人的创业公司。

这是典型的一天是如何运作的：

• 早晨： 我运行 /today。一个代理审查我的 TODO.md，检查进度，并提出优先事项。
• 工作日： 我向 10 个编程代理派发任务，每个任务都有明确的边界规范。在它们工作时，我审查 PR 并做出架构决策。
• 后台： 五个代理作者持续运行 —— 写作、编辑、发布。我在休息期间进行审查。
• Bug 修复： GitHub Copilot 处理细小的、有边界的任务 —— 快速修复，增加测试覆盖率。
• 每六个月： 路线图和 OKR 规划 —— 这是不可还原的人类环节，但即使是这个环节，我也会与 Claude、Gemini 和 ChatGPT 一起进行，以达成决策共识。

练兵的六项原则

运行这套系统两年后，我总结了六条原则。每一条都源自惨痛的教训：

1. “你自己调试。” 智能体（agent）要会 curl API、搜索日志、编写测试。如果它不能自我验证，说明需求文档（spec）还需要改进。
2. Token 消耗 = 效率。 唯一的衡量指标是：我能同时让多少个智能体忙起来？闲置的智能体就是浪费的产能。
3. 无需监督即可工作。 最好的智能体不会等待分配任务。Cron 任务、无限任务循环。看到有活儿要干？直接去干。
4. 架构 = 失败的自由。 良好的架构可以控制爆炸半径（blast radius）。智能体可以进行实验，但不能破坏核心业务。
5. 可衡量、可改进、可组合。 如果你无法衡量一项能力，你就无法改进它。一切都应该是可测试且可组合的。
6. 万物皆可智能体。 不仅仅是代码——内容、视频、社交媒体、客户支持、日程管理。然后：为智能体构建工具，而不仅仅是为人类。

什么是道馆馆主

DORA 差距：个人收益，零组织提升

这是一个令人不安的事实。Google 关于软件交付的年度研究——DORA 2025 报告发现，虽然 80% 的个人开发者表示 AI 提高了生产力，但组织的交付指标却没有显示出任何改善。 AI 放大的是现有的质量。宝可梦（Pokémon）无法修正策略。

宝可梦处理的是琐碎的商品化工作：样板代码、测试、需求转代码、文档、定义明确的 bug。这些东西的成本正在迅速下降。

训练师（trainer）处理的是困难的部分：定义构建什么以及为什么构建。设计可测试的系统。编写值得转化的需求文档。在不确定性下做出架构决策。

四项不会被自动化的技能

• 上下文工程 (Context engineering) —— 设计你的宝可梦学习的技能书。
• 评估设计 (Evaluation design) —— 建立检查流水线。如果你无法评估输出，你就无法经营道馆。
• 系统思维 (Systems thinking) —— 理解缺陷在哪里级联。宝可梦做局部优化；训练师负责全局一致性。
• 产品品味 (Product taste) —— 当任何人都能构建任何东西时，问题就变成了什么才值得构建。

为什么非计算机科学（CS）背景的人拥有优势

拥有 CS 背景的人在面对智能体能力的边界时往往趋于保守。他们对什么是“难点”了解得太多，所以会自我审查。“智能体不可能处理分布式事务。”他们甚至从不尝试。

非 CS 背景的人则发挥想象力。他们会说“如果我直接让它这么做呢？”然后发现成功的几率远比专家预期的要高。他们不断突破边界，因为他们不知道边界在哪里。

那就是我。我不知道什么是“理应”困难的，所以我尝试了一切。这就是为什么我构建了一套比我有十年经验的人都没尝试过的系统。

范式转移：三大支柱

这篇文章中的一切都指向一个更大的目标——软件构建方式的根本性转变。

将 AI 作为“高级自动补全”使用，就像给蒸汽机装上电动机。你会获得多一点动力，但你仍受困于旧的架构。真正的革命是彻底拆除蒸汽机。

支柱 1：AI 优先设计。 停止询问“AI 如何帮助我的工作流？”开始询问“我可以消除哪些障碍，以便让 AI 独立完成工作？”这种心态区分了获得 2 倍收益的训练师和获得 100 倍收益的训练师。

支柱 2：闭环迭代。 将人类从执行环中移除。让 AI 在拥有完整环境访问权限的情况下自主迭代。将可靠的自主性从几分钟延长到几小时是价值万亿美金的问题——每一次提升都能让一个人所能构建的东西产生指数级的增长。

支柱 3：治理工程 (Harness engineering)。 人类定义边界。将架构解耦为最小组件。使用多智能体交叉验证。你不是在写代码——你是在设计保持系统诚信的治理框架。

你的第一个任务

你最初是一个孤军奋战的苦力——只有你和一个闪烁的光标。你得到了神奇糖果（Rare Candy），事情变得快了一些，但天花板依然是你自己。你捕捉了你的第一只宝可梦，学习了上下文工程，建立了检查线，组建了一支队伍——然后目睹了它的惨败。

然后你重建了它。更聪明。带着约束。带着辛辛苦苦换来的原则。

宝可梦会持续变强——每个季度都会有新的模型、新的协议、新的框架。但那个设计系统、决定构建什么、如何检查以及何时发布的人——那个人不会被自动化取代。

那个人可以是你。

今晚：挑选一个项目。写一页需求文档。把它交给 Claude Code。查看返回的结果。

你刚刚捕捉到了你的第一只宝可梦。