你的智能体调用了一个数据库工具。查询返回了8000个Token的原始JSON——嵌套对象、null字段、分页元数据，以及每一行都带有时间戳。智能体只需要其中三个字段。你刚刚为7900个噪音Token付了费，并把它们全部注入上下文，让它们与真正的任务争夺注意力。
这就是工具输出注入问题，也是智能体设计中最被低估的架构决策。大多数团队都是在付出代价后才意识到这一点：演示运行顺畅，生产逐渐退化，却没人能解释为什么模型开始对之前能自信回答的问题开始含糊其辞。
智能体调用文件写入工具，工具因权限错误而失败。智能体记录此事，转而采用其他方案。任务运行足够长时间后，运行时触发上下文压缩，生成摘要："智能体一直在尝试写入输出文件。"被丢弃的内容：权限错误曾经发生过，以及为什么最初的方案被放弃。三百个 token 之后，智能体再次尝试同样的写入操作。
这种模式——姑且称之为压缩陷阱——是生产智能体系统中最顽固的可靠性故障之一。这不是模型 bug，而是压缩机制的工作方式与智能体在长时会话中保持连贯性所需之间的架构失配。
当一个用户的 80 轮支持对话突然开始与其 60 轮前的建议相矛盾时，团队最初将其归咎于 Bug。其实并没有 Bug，只是模型“迷失”了。在所有主流的前沿模型中，多轮对话在相同任务上的表现平均比单轮交互下降了 39%。大多数团队从未衡量过这一点。他们假设上下文窗口的效力大致等同于其 Token 限制所暗示的程度，并据此构建产品。
这种假设在无声无息中出现了错误。长会话不仅仅是变得更慢或更昂贵 —— 它们变得不可靠，而这种不可靠性在用户感到沮丧之前几乎无法被察觉。
这是一个静默发生的失败模式：你要求编程智能体更新身份验证服务的令牌刷新端点。智能体生成了看起来很干净的代码——自信、注释详尽且类型安全。然而，它调用了一个三层目录之上的共享库中，在三个月前就被重命名的函数签名。由于 Mock 仍然使用旧的签名，该端点的测试通过了。直到代码进入预发布环境并拉取真实的库时，错误才浮出水面。
这在抽象意义上并不是“幻觉”。模型知道那个方法——它存在于训练数据中的某个地方，或曾在上下文中简短出现过。问题在于架构：智能体从未获得过它所调用的接口的当前版本。
你的智能体完成了十二步工作流中的第三步，并自信地报告目标 API 返回了 200 状态。实际上并没有 —— 这个结果来自第一步，仍然停留在上下文窗口中。到第九步时，智能体已经基于一个从未真实存在过的事实进行了四次下游调用。工作流“成功”结束。没有记录任何错误。
这就是上下文污染（context poisoning）：它不是一种安全攻击，而是一种可靠性故障模式，即智能体自身积累的上下文变成了错误信息的来源。随着智能体运行时间变长、交互工具增多、管理状态增加，这种故障的发生概率会急剧上升。而且，与崩溃或异常不同，上下文污染对标准监控来说是不可见的。
在AI工程领域，有一种持久的信念：一个平庸的LLM应用和一个优秀的LLM应用之间的差距，归结于提示词的精心打磨。团队雇佣"提示工程师"，对措辞进行数十次A/B测试，花好几周纠结"你必须"是否比"请确保"表现更好。与此同时，检索管道输入的是垃圾上下文，没有输出验证，错误处理策略是"希望模型能搞定"。
数据讲述了一个不同的故事。典型LLM应用的前五小时提示词工作带来大约35%的提升。接下来的二十小时带来5%。再接下来的四十小时？大约1%。那些早期认识到这条曲线并将精力重新导向系统设计的团队，始终优于那些持续打磨提示词的团队。
你的 agent 在开发环境中运行完美。它能推理多步任务，自信地调用工具，生成精美的输出。然后你设置了每次请求 $0.50 的成本上限，它就崩溃了。不是优雅地降级——而是灾难性的崩溃。它在推理过程中截断自己的思考，忘记三步前的工具结果，并基于被静默丢失的上下文自信地给出错误答案。
这就是丰裕设计的 agent 和生产受限 agent 之间的差距。大多数 agent 架构都是在无限 token 预算下原型化的——长系统提示词、冗长的工具 schema、完整的文档检索、未压缩的对话历史。当你引入硬上限（成本上限、上下文限制、延迟要求）时，这些 agent 不会优雅地降级。它们以难以检测且调试成本高昂的方式崩溃。
METR 针对 246 个任务的研究发现，使用 AI 编程工具的有经验开发者比不借助辅助的开发者慢了 19%。与此同时，各厂商宣称提速 24%——营销数字与实测数据之间存在 43 个百分点的差距。瓶颈不在于模型智能，而在于上下文：智能体能看到什么，以及看不到什么。
上下文窗口才是 AI 编程智能体真正的 IDE。模型、温度参数、系统提示词——这些都远不如智能体从你 1 万个文件的代码库中检索到的那 20 个文件重要。把这 20 个文件选对，一个中等水平的模型也能生成正确且高度契合项目的代码。选错了，地球上能力最强的模型也只会产出貌似合理的废话，调试起来比自己从头写还费时间。
一个人如何用自主 AI Agent 替代了一个 15 人的工程团队——以及这一路上的惨痛失败。
本文内容为休斯顿大学 CIVE 7397 课程客座讲座材料。衷心感谢 张汝达教授 的邀请，以及 吕海 分享的诸多想法，正是这些启发塑造了本次讲座。
我大学没学过计算机。我在北京读的是管理专业。不知怎么地，我最后去了耶鲁读计算机硕士，然后去了 Uber 开发服务 9000 万用户的系统，接着又去了 Brex 和 Airbnb，最终创办了自己的公司。
我告诉你这些是因为谁能开发软件的游戏规则正在被重写——而你的背景可能比你想象中更有优势。
每个工程师的起点都一样。空白的编辑器。闪烁的光标。一个写着“开发订阅计费系统”的任务。
一位资深工程师——有着十年经验的人——每天大约产出 100 到 150 行生产环境代码。剩下的时间都花在了会议、代码审查、调试和上下文切换上。这就是天花板。
“10x 工程师”是我们追逐的神话。但即使是 10x 工程师也依然只有一个人。生产力随人数线性增长。想交付得更快？那就招更多的人——而每招一个人都需要三到六个月的入职培训。
最糟糕的部分是什么？知识只存在于人们的脑子里。为什么那个系统要那样设计？去问 Chen。哦，Chen 离职了。祝你好运。
在 Uber，任何任务最难的部分从来不是写代码。而是调研阶段——弄清楚哪里需要改，以及改什么。
当代码库极其庞大、文档缺失，而前任负责人已经离职时，你会花费 80% 的时间来建立对他人的系统的心理模型。瓶颈始终是人——他们的可用性、他们的上下文窗口、他们的单点故障风险（Bus Factor）。而不是算力。也不是想法。
然后，有些东西出现在了工作室门口。
你发现了 Copilot。接着是 Cursor。然后是 Windsurf。按下 Tab 键，整个函数就凭空出现了。这就像是在经历了多年的手动练级后，有人递给了你一颗“神奇糖果”（Rare Candy）。
这种提升是真实存在的——我们现在有了实地研究：
但即使有了这些提升，**天花板依然是你。**你砍柴的速度变快了，但你并没有建立起一家工厂。你依然是那个阅读规格说明、做决定、在凌晨两点调试代码的人。
神奇糖果强化的是你。它并没有给 你一只宝可梦。而打破天花板的唯一方法，就是彻底把自己从生产线中抽离出来。
就在这一刻，一切都改变了——而且它简单得令人难以置信。
你写一个规格说明。不是代码，而是规格说明（spec）。验收标准、约束条件、边界情况。你把它交给像 Claude Code 这样的自主 Agent。然后你走开。
Agent 读取你的代码库，规划方案，编写代码，运行测试，读取错误，修复错误，循环往复。等你回来时，一个 Pull Request 已经准备好了。你刚刚收服了你的第一只宝可梦。
这与 Cursor 或 Copilot 有着本质的区别。那些是电动工具——它们增强你的产出。而自主 Agent 是一个独立的劳动力。核心技能从提示词工程（Prompt Engineering）转向了上下文工程（Context Engineering）：设计你的宝可梦所运行的世界。
我总是从“计划模式”（Plan Mode）开始。Agent 分析代码库并提出方案。我审查方案，进行调整，然后说“执行”。
我有一条从不打破的原则：“你自己去调试。我只要结果。” Agent 必须自己 curl API、阅读日志，并编写测试来证明自己的工作。如果它无法自我验证，说明规格说明写得不够好。
你已经收服了第一只宝可梦。你该如何让它变强？
Anthropic 官方指南指出，Agent 的质量与其说取决于模型本身，不如说取决于其上下文的结构和管理方式。模型是引擎。而上下文——规格说明、代码库结构、反馈信号——则是技能书。你教给它什么，决定了它的战斗力。
三种输入至关重要：
你的 Pokémon 编写了代码。代码编译通过。你感觉棒极了。
然后你运行了测试。一半失败了。代理幻觉出了一个不存在的 API 端点，使用了一个已弃用的库，并引入了一个微妙的竞态条件。
这是核心挑战： 没有质量控制的 Pokémon 会规模化地制造缺陷。你构建的最重要的东西不是生产系统 —— 而是质检线。
代理在一个紧密的循环中运作：编写 → 测试 → 失败 → 读取错误 → 修复 → 重复，直到每一项检查都变成绿色。神奇之处不在于第一次尝试就能得到完美的输出 —— 它永远做不到这一点。神奇之处在于反馈循环是在几秒钟内运行的，而不是几小时。
我在实践中的质检线：
从代理中获得真正价值的团队并不是那些拥有最好模型的团队。而是那些拥有最严密质检线的团队。
一只 Pokémon 处理一个有边界的任务。真实的软件项目有许多移动部件。你需要一个阵容 —— 而为了让阵容协同工作，你需要共享的工具集和共享的剧本。
MCP（模型上下文协议） 就是道具包。任何 Pokémon 都可以伸手进去拿取任何工具、任何 API、任何数据源。它给了你的代理一双手。
CLAUDE.md 和自定义技能 是训练师手册。自定义斜杠命令 —— /today、/blog、/ci —— 编码了可重复的组合招式。CLAUDE.md 是每个代理在启动时都会阅读的规则手册：相同的上下文，相同的标准，不需要时刻盯着。
正如 Anthropic 所建议的：寻找尽可能简单的解决方案，只有在需要时才增加复杂性。
你的阵容已经集结完毕。一切都在运行。在白板上看起来很完美。然后，它崩溃了。
最危险的失败不是响亮的失败 —— 而是静默的失败。
我曾有一个编程代理所做的修改通过了所有现有测试，在代码审查中看起来很正确，并发布了。几天后，我发现它破坏了一个任何测试都没有覆盖的微妙不变量。没有错误日志。没有崩溃。只是错误的行为，花了几天时间才追溯到代理的提交记录。
那是噩梦般的场景：一个 Pokémon 产生了 通过了质检 的缺陷工作。你的质检线存在盲点，而代理会找到每一个盲点。
这不仅仅是我的经验。一项 NeurIPS 2025 的研究分析了跨越七个多代理框架的 1,600 个执行追踪，发现：
在遭遇挫折后的直觉是：“我需要更多代理。” 这种直觉是错误的。
Google DeepMind 和 MIT 对此进行了严格测试 —— 180 种配置、5 种架构、3 个模型家族：
教训是：不要增加 Pokémon 的数量。要增加 正确 的 Pokémon。
盲目的乐观已经消失。取而代之的是：来之不易的知识。
SWE-Bench 排行榜评估了 80 种独特的代理编程方法，发现没有单一架构能始终获胜。但有四个原则屹立不倒：
关于成本的一个实用说明：你不需要一大笔钱来开始。Claude.ai 免费层、GitHub Copilot 学生计划和 Cursor 免费层能让你走得很远。我通过 CLI 到 API 代理，在多个每月 200 美元的订阅上运行我的整个操作 —— 成本大约是直接调用 API 的 1/7 到 1/10。
这不是比喻。这是我今天的真实配置：
yarn blog loop 24/7 全天候产出 SEO 内容。这是典型的一天是如何运作的：
/today。一个代理审查我的 TODO.md，检查进度，并提出优先事项。运行这套系统两年后，我总结了六条原则。每一条都源自惨痛的教训：
这是一个令人不安的事实。Google 关于软件交付的年度研究——DORA 2025 报告发现，虽然 80% 的个人开发者表示 AI 提高了生产力，但组织的交付指标却没有显示出任何改善。 AI 放大的是现有的质量。宝可梦（Pok émon）无法修正策略。
宝可梦处理的是琐碎的商品化工作：样板代码、测试、需求转代码、文档、定义明确的 bug。这些东西的成本正在迅速下降。
训练师（trainer）处理的是困难的部分：定义构建什么以及为什么构建。设计可测试的系统。编写值得转化的需求文档。在不确定性下做出架构决策。
拥有 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。当底层模型提升，你的封装层自动继承收益。
构建薄层，靠近前沿。避免把你锁死在昨天能力上的框架。
问：智能体行业竞争极其激烈，怎么脱颖而出？
不要在智能体本身上竞争——在你能带来的独特优势上竞争。
我看到三种有效模式：
研究者和学者：你的优势是声誉和学术公信力。构建能放大你研究影响力的智能体——让你以 10 倍速度发表、综合和协作的工具。智能体放大的是一个花了多年建立起来的品牌。
领域专家：你了解通用模型所不了解的行业知识。用智能体分析患者流程的外科医生，自动化采购决策的供应链专家——智能体是放大器，领域知识是护城河。在你的垂直领域比任何人解决得都好。
KOL 产品：如果你已经拥有大量忠实受众——比如 Cuely 依靠高流量公众关注度构建的 GTM 策略——分发渠道就是护城河。智能体产品成为你已建立信任的漏斗。公开构建，向已经关注你的受众交付。
智能体是商品。你带来的独特资产，才是防御壁垒。
你最初是一个孤军奋战的苦力——只有你和一个闪烁的光标。你得到了神奇糖果（Rare Candy），事情变得快了一些，但天花板依然是你自己。你捕捉了你的第一只宝可梦，学习了上下文工程，建立了检查线，组建了一支队伍——然后目睹了它的惨败。
然后你重建了它。更聪明。带着约束。带着辛辛苦苦换来的原则。
宝可梦会持续变强——每个季度都会有新的模型、新的协议、新的框架。但那个设计系统、决定构建什么、如何检查以及何时发布的人——那个人不会被自动化取代。
那个人可以是你。
今晚：挑选一个项目。写一页需求文档。把它交给 Claude Code。查看返回的结果。
你刚刚捕捉到了你的第一只宝可梦。
当 100 万 Token 的上下文窗口发布时，许多团队认为这相当于拿到了可以停止思考上下文设计的“许可”。逻辑很直观：如果模型能看到一切，那就把一切都给它。丢进整个文档。传递完整的对话历史。将每一个工具输出都转发给下一个 Agent 调用。让模型自己去处理。
这就是“上下文堆砌 (Context Stuffing)”反模式。它会产生一种典型的故障模式：系统在早期演示中运行良好，但在生产环境中会遇到可靠性瓶颈，无论如何调整提示词都无法修复。在原本应该很简单的问题上，准确率反而下降。回答变得模棱两可、含糊其辞。Agent 开始在互不相关的文档之间产生幻觉性的关联。模型“看到”了所有正确的信息 —— 它只是找不到。
Manus 团队在不到一年的时间里重建了四次他们的智能体（agent）框架。这并非因为模型发生了变化 —— 底层 LLM 在稳步提升。他们之所以重建，是因为不断发现了更好的方式来塑造进入上下文窗口（context window）的内容。
他们将这一过程称为“随机研究生下降”（Stochastic Graduate Descent）：手动的架构搜索、提示词微调和经验性猜想。这是对构建生产级智能体真实面貌的坦率描述。在经历了数百万次真实用户会话后，他们总结出了六种具体的技术，这些技术决定了一个长周期智能体（long-horizon agent）是会取得成功，还是会陷入混乱。
核心洞察说起来简单，内化却很难：“上下文工程（Context engineering）是一门微妙的艺术与科学，即用恰到好处的信息填充上下文窗口，以支持下一步操作。”一个典型的 Manus 任务运行约 50 次工具调用，输入与输出的 token 比例高达 100:1。在这样的规模下，你在上下文中放入了什么 —— 以及你是如何放入的 —— 决定了一切。
在扩展 AI Agent 时，大多数团队都会遇到一个违背直觉的失败模式：Agent 的工具集越强大，它的表现就越差。你为了处理更多场景而增加工具，准确率却下降了。你增加了更优秀的工具，它却变得更慢，并开始选错工具。你加入了编排逻辑来管理工具选择，结果你在原始的复杂性之上又重建了一层复杂性，而整个系统几乎无法运行。
增加工具的本能是错误的。生产环境中 Agent 的性能提升往往源于“删减”。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
