从Vibe Coding到Agent Engineering：究竟发生了什么变化
2025年2月，Andrej Karpathy发了一条定义了一个时代的推文：“There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
十三个月后，在No Priors播客上，他亲手为这个词退休。
“I went from 80/20 of writing code myself versus delegating to agents to like 2/98. I don’t think I’ve typed a line of code since December.”
发明”Vibe Coding”的人，如今称它为过时之物。他的新术语：Agentic Engineering。不是因为AI生成代码的能力变差了——而是因为生成代码从来都不是难点所在。
Karpathy究竟说了什么
No Priors的这期访谈值得完整观看，但有三个转变尤为突出：
1. 比例彻底翻转。 Karpathy从自己写80%的代码降到只写2%。其余的由智能体负责。瓶颈从打字速度转移到了编排能力——如何高效指挥多个并行工作的智能体。
2. “代码甚至已经不是正确的动词了。” 软件开发变成了宏观行动的编排。你不再编写函数；你委托功能。你不再逐行调试；你在架构层面做审查。Peter Steinberger同时运行着数十个智能体，每个负责跨多个代码库的20分钟任务。
3. AutoResearch将人类完全移出循环。 Karpathy为nanoGPT构建了一个自主研究循环，彻夜运行以优化超参数。尽管他亲手调优了多年，智能体仍然找到了他遗漏的改进点——value embeddings上被遗忘的weight decay、调整不足的Adam betas。他的结论：“To get the most out of the tools, you have to remove yourself as the bottleneck.”
贯穿其中的主线：价值从执行转向了判断。Vibe Coding关注执行——提示、生成、上线。Agentic Engineering关注判断——架构、验证、编排。
下一阶段的工程手册
同一周，Tw93——Pake、Mole的创作者，高产的开源工程师——发布了”You Don’t Know AI Agents”，一份深入的技术指南，涵盖了如何在生产环境中真正让智能体变得可靠。Karpathy提供视野，Tw93提供工程手册。
他的核心论点：harness比模型更重要。
“Using a more expensive model doesn’t always yield the massive improvements you’d expect. Instead, the quality of your harness and validation tests has a far greater impact on success rates.”
这不是理论。OpenAI自己的工程团队证明了这一点：三位工程师在五个月内写了一百万行代码——是传统速度的十倍。关键不是更好的模型，而是在约束、验证和智能体基础设施上做出了正确的工程决策。
区分Vibe Coding与Agent Engineering的五个原则
1. Context Engineering，而非Prompt Engineering
Transformer的注意力复杂度为O(n²)。上下文越长，关键信号越容易被稀释。最常见的失败模式不是”模型做不到”——而是Context Rot：无关内容不断积累，直到智能体的决策质量明显下降。
解决方案是分层的上下文管理：
- 永久层：身份标识、规范、硬约束。简短、稳定、始终加载。
- 按需层：技能和领域知识。描述符常驻；完整内容仅在触发时加载。
- 运行时注入：时间戳、用户偏好、动态状态。每轮追加。
- 记忆层：跨会话经验。仅在相关时读取，不塞进每个提示词。
关键洞察：不要将确定性逻辑放入上下文。任何可以用代码规则、linter或hook表达的内容，都应由外部系统处理。模型应该思考，而不是读规则手册。
2. 遵循ACI原则的工具设计
大多数工具失败不是因为模型选错了工具——而是因为工具是为工程师设计的，而不是为智能体设计的。Agent-Computer Interface（ACI）框架改变了设计视角：
| 方面 | 糟糕的工具设计 | 良好的工具设计 |
|---|---|---|
| 粒度 | 映射到API端点 | 映射到智能体目标 |
| 返回值 | 完整的原始数据 | 与下一个决策相关的字段 |
| 错误 | 通用字符串 | 带有修复建议的结构化信息 |
| 描述 | 它做什么 | 何时使用，何时不应使用 |
一个实际例子：与其提供get_post + update_content + update_title作为独立工具，不如提供update_yuque_post，在一次调用中表达完整操作。在工具描述中加入反例，可将准确率从53%提升至85%。
调试智能体时，先检查工具定义。大多数工具选择错误源于描述不准确，而非模型能力不足。
3. 作为基础设施的记忆，而非事后补丁
智能体缺乏原生的时间连续性。会话结束时，上下文即消失。四种记忆类型解决不同的问题：
- 工作记忆（上下文窗口）：当前任务状态。主动管理。
- 程序记忆（技能）：如何做事。按需加载。
- 情节记忆（会话日志）：发生了什么。持久化，可检索。
- 语义记忆（MEMORY.md）：稳定的事实。启动时注入。
关键设计决策：记忆整合必须是可逆的。压缩长对话时，不要删除原始消息——存档它们。移动指针，不要销毁数据。如果整合产生了糟糕的摘要，智能体仍可以回退到原始历史记录。
4. 优化之前先评估
智能体评估从根本上比传统测试更难。输入空间是无限的，LLM对提示措辞敏感，同一任务在不同运行中可能产生不同结果。
两个指标，两个目的：
- Pass@k：k次中至少一次正确。测试能力边界。开发期间使用。
- Pass^k：k次全部正确。测试可靠性。部署前使用。
最危险的反模式：在评估基础设施有问题时调整智能体。如果评分有缺陷，你是在对着扭曲的信号做优化。当性能下降时，先检查基础设施——导致崩溃的资源限制、有bug的评分器、或与现实脱节的测试用例——再修改智能体。
5. 多智能体协调需要协议
运行多个智能体不是关于并行性的——而是关于隔离和协调的。子智能体只应返回摘要；它们的搜索、试错和调试过程留在各自的上下文中。主智能体的上下文只接收结论。
顺序很重要：先定义协议，再建立隔离，然后再谈协作。没有结构化通信（JSONL消息队列、任务图、工作区隔离），错误会在智能体之间放大。智能体A偏离轨道，智能体B强化了偏差，智能体C叠加在上面，三者都以高置信度收敛到错误结论。
一张表看清演进
| 阶段 | 开发者角色 | 代码质量 | 验证方式 | 规模 |
|---|---|---|---|---|
| 手动编码 | 编写者 | 高（自己的代码） | 自己测试 | 一个人 |
| Vibe Coding | 提示者 | 参差不齐 | 自己检查 | 一个智能体 |
| Agentic Coding | 架构师 | 结构化 | 智能体自测 | 多个智能体 |
| Agent Engineering | 编排者 | Harness支撑 | 自动化评估 | 智能体团队 |
每个阶段都没有替代上一个——而是将其包含在内。你依然需要品味，依然需要架构思维，依然需要理解代码。但执行层在不断远离你的指尖。
这在实践中意味着什么
Karpathy构建了一个名为”Dobby the House Elf”的家居自动化智能体——三条提示扫描了他的本地网络，对智能设备API进行了逆向工程，并用WhatsApp命令替换了六个独立的应用程序。“Dobby, sleepy time”关掉一切。
他对软件的结论：“These apps shouldn’t even exist. Shouldn’t it just be APIs and agents are the glue of intelligence that tool-calls all the parts?”
这就是轨迹所在。软件正在从你操作的产品转变为代替你操作产品的智能体。界面从GUI坍缩为自然语言。复杂性不会消失——它转移到了harness、工具、评估、以及让智能体可靠运行的记忆系统之中。
Vibe Coding让我们习惯了AI写代码这个想法。Agent Engineering则是关于构建让AI写出的代码值得信赖、可维护、自主运行的基础设施。
Vibes是第一步。工程，是此后的一切。
TeamDay在云端运行自主AI智能体——SEO、内容、社交媒体、数据分析等。Karpathy和Tw93所描述的Agent Engineering原则，正是驱动我们AI团队的核心。开始构建你的智能体团队。