先把概念切一刀：Vibe Coding ≠ “用 AI 写代码”

Andrej Karpathy 2025 年 2 月 2 日那条原推的定义是：“完全沉浸在氛围里，拥抱指数级进步，忘记代码本身的存在……我 ‘Accept All’ 从不读 diff，报错信息直接贴回去，通常就好了。” 注意这里的关键动作是"不读代码、不审 diff、靠跑通与否反馈"——这才是原教旨 vibe coding。

字节跳动洪定坤后来提了个重要区分："用自然语言写代码"≠ vibe coding。前者是你用自然语言精确描述编码逻辑和方案，生成完仍然 review、仍然能随时接管；后者才是"点按钮、提需求、跟着感觉走"。讨论 agent 开发前先把这刀切了，否则后面全是鸡同鸭讲。

Agent 开发遇上 Vibe：放大了爽感，也放大了坑

Agent 项目（无论你是撸 LangGraph / Crew / 自研 loop）有几个天然属性：

• 脚手架高度模板化：agent loop、tool schema、retriever wrapper、vector store 对接——这些 AI 写得飞起，Cursor/Claude Code 一把梭。

• 非确定性内建：同一段 prompt，跑两次路径不同；“能跑"不等于"对”。

• 状态与上下文长：多跳推理 + 工具返回 + 中间态，上下文轻松破十万 token。

• 隐性成本点多：LLM 调用费用、tool 调用超时重试、agent 自循环卡死、eval 覆盖。

这几个属性和 vibe coding 的"不读代码、靠运行反馈"组合在一起，爽点和雷点都被放大：

🟢 放大了的爽点

原型阶段 vibe 出来一个多工具 agent，对个人开发者是小时级的事。以前你要读 LangChain 文档、对着 TypeScript 类型定义调 tool schema，现在"我要一个能搜网页+算价格的 ReAct agent，用 GPT-5，内存用 Redis"——三句 prompt 跑起来。Karpathy 说的 “see stuff, say stuff, run stuff” 在 agent 脚手架层是真的香。

🔴 放大了的坑

坑也比普通脚本深，原因三条：

1. "能跑"的欺骗性更强。普通脚本跑通 = 大概率逻辑对；agent 跑通 = 可能只是这次 LLM 没抽风。vibe 态度下你不会去写 eval、不会去测 tool 边界，上线后一周才炸。

2. 三阶段衰退曲线在 agent 项目里来得更快。Node.js 那场 1.9 万行 PR 争议里总结过：前期 AI 爆发、中期耦合上来人类成本追平、后期长上下文指令遵循断崖。Agent 项目因为本身上下文就长、状态就多，很多项目在 0.5→0.8 这段就提前进"崩溃期"——不是功能加不动，是 agent 开始"错的地方没改对，对的地方改错了"。

3. Debug 链路断裂。传统 bug 你读栈；agent bug 你得反过来追：“为什么 LLM 这轮选了 tool B 而不是 A？prompt 哪句歧义了？memory 里哪条历史带偏了？”——vibe 模式下你不读代码，连追都追不动，只能"随机改 prompt 直到它好像好了"，Karpathy 原推自嘲的那句 “ask for random changes until it goes away” 在 agent 场景是直接命门。

那 1.9 万行 PR 争议，对 agent 开发者意味着什么

2026 年初 Matteo Collina 用 Claude Code 搓出 Node.js 内置 VFS 的 1.9 万行 PR，Fedor Indutny 牵头请愿要求禁止 LLM 重写核心模块，Kyle Simpson、Andrew Kelley 实名签——这事表面是开源政治，底下戳中一个更通用的痛点：生成成本趋零，review 成本仍线性。按每行 2 分钟算，1.9 万行 = 90 个工作日。

放到 agent 开发里这个比值更夸张：agent 项目里"生成"的不只是代码，还有 prompt、tool 定义、eval case、路由规则——每样都可能由 AI 吐出来。如果团队全员 vibe、无人收口，reviewer 不是在审代码，是在替你的 token 买单。

怎么评价？给一个不那么骑墙的判断

Vibe coding 下的 AI agent 开发，我的判断是三句话：

Vibe coding 把 agent 从 0 到 0.5 压缩到小时级，但 agent 从 0.5 到 1 那段（可观测、eval、成本管控、tool 边界、回滚）比非 agent 项目更需要硬工程纪律，而不是更不需要。

拆成场景更清楚：

这个表里"面向用户的 agent"那一档是多数人实际在的位置——也是 vibe coding 最容易翻车的位置。Apple 那边对 AI 生成 App 的态度已经很明确："AI 写的"不是质量问题的免责声明，agent 上架同理。

真正剩下的东西

2026 年这场争论打到后面，真正浮出来的是一件事：AI 把"写 agent"门槛干到极低之后，agent 工程师的核心价值不再是"能不能让 LLM 吐出一段 loop"，而是"这段 agent 该不该进生产、该不该被长期维护、cost/latency/eval 能不能兜住"。

所以评价 vibe coding 下的 agent 开发，结论不是"爽还是坑"，而是：

• 原型段：vibe 万岁，不 vibe 才是浪费 AI。

• 生产段：agent 的非确定性决定了它比普通项目更不能"跟着感觉走"——tool schema 要审、eval 要覆盖、cost guard 要上、trace 要能反查。这一段恰恰是 2026 年多数"agent 创业项目"死掉的原因（能 demo 不能上线）。

• 护城河：知道什么时候 vibe、什么时候 engineer、哪段 prompt 必须锁版本、哪个 tool 边界必须人工测——这个判断力，模型换十代也不会贬值。