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

一个人如何用自主 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)。 人类定义边界。将架构解耦为最小组件。使用多智能体交叉验证。你不是在写代码——你是在设计保持系统诚信的治理框架。

课后问答

这些是讲座结束后，学生和从业者提出的真实问题。

问：你的实际机器配置是什么样的？需要高性能服务器吗？

完全不需要。我在 Mac 上本地运行 Claude Code——它通过 API 与 Anthropic 的云端通信，重计算都在云端完成。为了隔离和沙箱化（防止智能体意外影响主环境），我也会在 Cloudflare 沙箱中运行 Claude Code。本地机器用于交互式工作，沙箱环境用于任何需要控制爆炸半径的任务。

问：你说用 Claude Code 处理一切数字工作，真的是所有事吗？

是的。代码、博客文章、社交内容、邮件草稿、数据分析、日程规划、客服模板。只要是有明确输出标准的数字工作，我都会先尝试用智能体处理。在手动做任何事情之前，我会问自己："我能用一段话写出这个任务的规格说明吗？"如果能——先试试智能体。

问：你怎么让智能体 24/7 不间断运行，又不需要时刻盯着？

无限循环：一个 bash 循环调用 Claude 斜杠命令，检查退出条件，然后重新运行。工作流的每个阶段都有自己的技能——/brainstorm（头脑风暴）、/research（调研）、/write（写作）、/polish（润色）、/validate（验证）、/publish（发布）。当每个技能都足够稳定且能自我验证时，就可以串联起来。链条上每一环都可靠，整条链就能持续运转。这就是五个写作智能体能够全天候产出内容的原理。

关键洞察：你运行的不是一个漫长的智能体会话，而是许多短小的、可组合的、可检查的步骤。步骤越短，失败半径越小。

问：长时间运行的智能体难道不会超时或跑偏吗？

确实会，这正是为什么我要并行运行多个智能体。任何一个智能体在复杂任务上可能需要 20 到 40 分钟，或者撞上上下文限制，或者在意外错误上卡住。并行运行意味着一个卡住不会阻塞全局。我把智能体当成队列里的异步 worker，而不是同步函数调用。

问：你如何区分处理常规任务和复杂任务？

常规任务用斜杠命令。/ci、/blog、/today、/commit——这些命令一次性编码了完整的上下文、工具和验收标准。调用时零边际思考成本。技能即规格说明。

复杂或全新的任务由我亲自指挥：写规格说明、审查方案、批准思路，然后让智能体执行。我只负责构建什么以及为什么——而不是怎么构建。

问：每个月实际花多少钱？

一个人全职运行 10 个以上智能体，每月不超过 1,000 美元。我使用订阅制访问（Claude Max 及类似档位），而非按 token 付费的原始 API——成本大约是后者的 1/7 到 1/10。相比之下，一名初级工程师每月全成本 8,000 到 12,000 美元。经济账根本不在一个量级。

问：什么时候用 API，什么时候用聊天/智能体产品？

API 用于定义明确、高频率、程序化的任务：翻译流水线、结构化数据提取、我能完全控制调用的内容转换。可预测、可审计、可组合。

聊天/智能体（Claude.ai、Claude Code）用于复杂、开放性的任务：架构决策、调试新问题、需要判断力的写作。智能体需要在模糊中导航、读取上下文、调用工具——这才是编排层真正发挥价值的地方。

经验法则：如果我能把完整提示词写成模板且没有意外，用 API。如果任务需要智能体自己判断下一步做什么，用智能体产品。

问：多迭代几次结果一定更好吗？

不一定——很多人在这里踩坑。更多轮次不自动等于更好的输出。关键是每一轮都有清晰、不同的目标：起草 → 事实核查 → 语气 → 结构 → 终稿。没有方向的"再来一遍"循环往往会回归平均水平。每个阶段有明确验收标准的定向、可检查的步骤——这才是质量复利的来源。

目标是每个阶段投入常规精力，而非马拉松式会话。可靠、可检查、可重复，胜过野心勃勃却难以预测。

问：应该在什么基础上构建智能体？一切变化这么快，怎么选？

是的，一切都在变化——而这正是策略所在。我的假设：市场上的模型和智能体每个季度都在变强。你构建在更强基础之上的一切，会免费跟着变强。

这意味着：不要押注于那些抽象远离前沿的工作流编排引擎（n8n、LangChain）。它们在设计上就落后于最新技术。相反，在前沿智能体之上构建技能和封装层：Claude Code、Gemini CLI、OpenCode。当底层模型提升，你的封装层自动继承收益。

构建薄层，靠近前沿。避免把你锁死在昨天能力上的框架。

问：智能体行业竞争极其激烈，怎么脱颖而出？

不要在智能体本身上竞争——在你能带来的独特优势上竞争。

我看到三种有效模式：

1. 研究者和学者：你的优势是声誉和学术公信力。构建能放大你研究影响力的智能体——让你以 10 倍速度发表、综合和协作的工具。智能体放大的是一个花了多年建立起来的品牌。

2. 领域专家：你了解通用模型所不了解的行业知识。用智能体分析患者流程的外科医生，自动化采购决策的供应链专家——智能体是放大器，领域知识是护城河。在你的垂直领域比任何人解决得都好。

3. KOL 产品：如果你已经拥有大量忠实受众——比如 Cuely 依靠高流量公众关注度构建的 GTM 策略——分发渠道就是护城河。智能体产品成为你已建立信任的漏斗。公开构建，向已经关注你的受众交付。

智能体是商品。你带来的独特资产，才是防御壁垒。

你的第一个任务

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

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

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

那个人可以是你。

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

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