从Vibe Coding到Agent Engineering:究竟发生了什么变化
TeamDay· 12 min read· 2026/03/23
Vibe CodingAgent EngineeringAI智能体Andrej KarpathyClaude Code智能体架构软件工程

从Vibe Coding到Agent Engineering:究竟发生了什么变化

从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团队的核心。开始构建你的智能体团队

Turn the best models into shipped work

Teamday installs AI employees with the right model, harness, MCP servers, workspace files, review path, and recurring mission. Stop comparing tools in isolation and put them to work.