跳转至

从氛围编程到智能体工程

Ch04.070 从氛围编程到智能体工程

📊 Level ⭐⭐ | 18.8KB | entities/karpathy-vibe-coding-agentic-engineering.md

从氛围编程到智能体工程

→ 原文存档

本文对应 Karpathy 在 Sequoia AI Ascent 2026 访谈的二阶解读（来源：架构师 JiaGouX）。核心命题是：从 Vibe Coding 到 Agentic Engineering，不只是术语更替，而是软件工程控制对象在悄悄位移 — 过去主要控制代码、模块、接口、服务、数据流，今天可能还要加上 Agent 的上下文、权限、工具调用、执行环境、验证机制和行为后果。

摘要

Karpathy 在 2026 年 2 月用「Agentic Engineering」一周年回看 Vibe Coding 之后，工程社区迅速把这一表述接住。Google 的 Addy Osmani 在 2026 年 2 月发表同名文章，把 Vibe Coding 限定在原型与个人脚本，把专业软件开发的边界任务交给 Agentic Engineering；同月发布的 GLM-5 论文直接把标题写成《from Vibe Coding to Agentic Engineering》，意味着该概念已经下沉到长上下文、异步强化学习与真实软件工程任务的训练层面。本文系统梳理这次术语切换背后的工程含义：任务粒度变大、控制面（Control Plane）外移、可验证性决定自动化深度、人在体系中的位置从「搬砖者」上移到「包工头」。

核心要点

1. 术语切换背后是任务粒度的位移

2025 年 12 月是一个明显的转折点。在此之前，AI 辅助编程主要接住局部任务：写一个函数、补一个测试、修一个报错、改一个页面。从年底开始，模型开始稳定接住「流程级」任务：读项目上下文 → 理解目标 → 改多文件 → 调命令 → 跑测试 → 根据失败继续修复 → 给出一个可 review 的结果。

这种变化对工程系统的意义不是「工具更聪明」，而是 Agent 开始走到工程系统内部。团队真正缺的往往不是「再来一个更聪明的 Agent」，而是一层把这些边界串起来的控制面。

2. 控制面六层：把 Harness 落到研发体系

Karpathy 访谈里点出的 Agent Control Plane 大致包含六层。把它当成企业级研发系统的设计参考，比单点工具视角更稳：

控制面 主要问题
Context Control Agent 能看到什么，不能看到什么
Spec Control 任务目标、约束和验收标准如何表达
Tool Control 可以调用哪些工具，参数如何约束
Permission Control 哪些动作允许，哪些需要审批
Runtime Control 执行环境如何隔离、限额、恢复
Verification Control 结果如何通过测试、编译、规则和评估器验证
Audit Control Agent 做了什么、为什么做、造成什么影响
Cost Control Token、模型调用、工具调用和重试成本如何控制

简言之：Agentic Engineering 不是给 Agent 无限自由，而是给它划出一片可控的自由度。

3. Software 3.0：上下文成为架构对象

Karpathy 重提的 Software 1.0 → 2.0 → 3.0 在工程系统视角下最关键的含义是：上下文、文档、工具、记忆、权限、测试、部署环境正在一起变成需要被设计的「软件材料」。

阶段 核心材料 关注点
Software 1.0 代码 模块、接口、依赖、运行时
Software 2.0 数据与模型权重 数据集、训练过程、模型评估
Software 3.0 上下文、工具、记忆、权限、验证 Agent 工作环境、可执行上下文、任务闭环

过去做架构主要想模块之间的关系；现在还要再想一层：Agent 与系统之间的关系。这条线最终会引出一个比较远的判断 — 如果神经网络越来越像主进程，传统 CPU、API 和确定性代码就会更像协处理器。

4. 文档从「给人看」变成「给 Agent 执行」

访谈里 Karpathy 举了 OpenClaw 安装的例子：传统 shell script 在异构环境里膨胀成难维护的条件分支；Agentic 方式可以是「给 Agent 的说明」，由 Agent 自行观察、调试、回报。

这条线索改变了文档的工程属性：

过去的工程资产 Agentic 时代的工程资产
README 给人读 README 也要能被 Agent 正确使用
API 文档给开发者查 API 文档给 Agent 规划调用
运维手册给 SRE 看 Runbook 可以被 Agent 执行和修复
Shell Script 固化流程 Instruction 描述目标、约束和边界
CI/CD 执行固定流水线 Agent 参与动态排障、修复和验证

如果文档、工具、权限、反馈能被 Agent 稳定读取和调用，它才有条件成为工程系统里相对可控的一环。

5. 可验证性决定 Agent 能走多远

Karpathy 在访谈中反复强调可验证性：这一代 LLM 更容易自动化你能验证的东西。代码、数学、测试、编译、结构化任务之所以进展快，不只因为模型变聪明，更因为这些领域容易构造反馈（编译、测试、漏洞复现、格式约束都能变成奖励信号）。

团队落地时一个朴素的次序是先看哪些事情能被验证，再决定哪些事情交给 Agent：

等级 任务特征 Agent 适用程度
L1 输出可静态校验 高
L2 可编译、可测试 高
L3 可通过集成测试验证 较高
L4 涉及业务规则与状态变更 需要审批和审计
L5 涉及资金、身份、权限、数据删除 必须强管控
L6 涉及组织判断、法律责任、战略选择 人必须主导

把验证体系搭起来，Agent 才有条件从「帮我写一段代码」走向「帮我完成一段工程任务」。

6. 锯齿状智能与护栏默认化

Karpathy 用「锯齿状智能」形容 LLM 的能力地形：一个最先进的模型可以重构 10 万行代码、找到零日漏洞，却建议你走路去 50 米外的洗车店，因为它忘了「要洗的是车」。

同时他从 GPT-3.5 到 GPT-4 的国际象棋能力提升，指出背后的实际原因是 OpenAI 把大量国际象棋数据加进了预训练 — 一个看似「能力进化」的故事，到这里变成了「实验室在做产品决策」的故事。

对落地团队的提醒是：不能假设下一代模型会自动覆盖你关心的领域。如果业务场景刚好落在前沿实验室 RL 训练覆盖的回路里，那挺好；落在外面的话，要么自己构造可验证环境去微调，要么就接受 Agent 在那个领域只是个不太稳定的实习生。

Simon Willison 提过的安全框架值得并入默认护栏：Agent 同时具备访问私有数据、接触不可信内容、对外通信三种能力时，风险会陡然上升。具体护栏可以这么配：

风险 可能的护栏
幻觉执行 工具调用前校验
错误修改代码 分支隔离和代码审查
误删数据 沙箱和只读默认权限
错误部署 灰度、回滚、审批
错误关联身份和资金 稳定 ID 与领域模型约束
Prompt Injection 私有数据、不可信输入、外部通信分离
成本失控 Token 限额、调用预算、模型路由
行为不可追溯 全量日志和审计链

Karpathy 还讲了一个很典型的支付案例：用 Google 账号登录、用 Stripe 买 credits，Agent 用 Stripe 邮箱匹配 Google 邮箱挂载 credits。代码能跑、局部测试也可能过，但语义错了 — 邮箱本来就不该当稳定用户身份。这类业务语义错误最危险，因为语法上往往看不出来。

7. 人的位置上移：从搬砖者到包工头

Karpathy 反复强调的一句话是：「你可以外包思考，但不能外包理解。」

他给出了一个很具体的对照：

过去重要 现在可能更重要
熟悉 API 细节 理解底层机制
手写业务代码 定义业务语义
写脚本自动化 设计 Agent 执行边界
完成功能 设计验收标准
修 bug 建立验证体系
控制模块依赖 控制 Agent 权限和上下文
管理代码质量 管理系统后果

人的主要价值，更多落在规格、边界、验证、取舍和理解这几件事上。

8. 面试标准需要重构

Karpathy 直接吐槽了「现场写一道算法 puzzle」的招聘方式 — 它测的是能不能在白板上手写一个 trie，跟一个人在 Agentic Engineering 里能不能干活基本两码事。

他提出的替代方案是：甩给候选人一个超大的真实项目（比如给 Agent 用的 Twitter 仿盘，要求绝对安全），挂 10 个 Cursor 当「红队」放开攻击。真正考察的是候选人能不能：把模糊目标变成清晰规格、指挥多个 Agent 完成大规模实现、识别安全和架构风险、设置测试与验证、在模型生成的大量代码里保住质量判断。

深度分析

这次术语切换不是改名，是控制对象在悄悄位移

把 Vibe Coding → Agentic Engineering 拆开看，「Vibe Coding 命名的是一种个人体验，Agentic Engineering 命名的就是一套专业工作方式」。

这个差异的本质是「开发工具 vs 工程系统」。当 Agent 还在补函数、修报错、生成脚本时，它的位置接近于一个能力更强的开发辅助；一旦它开始读项目、改文件、调命令、跑测试、配服务、处理部署时，它已经走进软件工程的链路。这时「工具是不是更聪明」变成次要问题，更重要的是它进来之后，哪些边界要重新想。

控制对象在悄悄变化的几个具体表现：

  1. 质量门槛从「能跑」移到「可验证」。原型/MVP 里「能跑」就够，专业软件里「能跑 + 可验证 + 可回滚 + 可审计」才合格。这就是 Karpathy 反复讲可验证性的原因。

  2. 上下文从「聊天记录」移到「工作集」。Agent 上下文窗口更像运行时工作集，而不是无限增长的聊天记录。放到工程体系层面，仓库、文档、日志、测试、Runbook、审批记录，都会从「人偶尔查一下」的资料，变成 Agent 能按需进入、按规则使用、按结果回写的工作集。

  3. 失败处理从「重新 prompt」移到「系统级恢复」。当 Agent 长时间运行时，「错了一次就重新开始」无法接受；「失败 → 分析 → 重试或回滚 → 重新进入稳定状态」必须由 Harness 提供。

  4. 人的角色从「实现者」上移到「边界定义者」。架构师的价值本来就在定义边界；今天 Agent 的普及把这条线拉得更细 — 不仅定义模块之间的接口，还要定义 Agent 能看到什么、能调用什么、必须如何验收、错了怎么恢复。

「幽灵」比喻的工程含义

Karpathy 花了不少篇幅讲他自己写的「animals vs ghosts」 — LLM 不是动物，是幽灵。动物智能来自进化、身体、环境互动、内在动机；LLM 来自大规模预训练叠加 RL 与偏好数据，更像是被人类文档、统计模式和奖励函数塑造出的「模拟实体」。

这个比喻的工程含义是：不能假设 Agent 会因为被骂了而表现更好，也不能假设它会因为鼓励而更可靠 — 它没有动机、没有自尊、没有持续学习。把护栏当成默认配置，而不是补丁，更接近现实。

中间层应用的风险

MenuGen 案例是个特别值得停下来想的信号：把餐厅菜单拍给多模态模型，模型可以直接返回一张修改后的图片，根本不需要传统的「OCR → 抽菜名 → 调图像生成 → 重新排版」链路。

对做架构和做产品的提醒：

系统形态 风险
只包装模型能力 容易被模型升级吞掉
只把 Prompt 做成页面 缺少架构壁垒
只做输入输出格式转换 容易被模型原生能力替代
深入业务流程 有一定壁垒
掌握权限、数据、状态、审计 壁垒更强
承担复杂系统协同和验证 更接近基础设施

方向上越来越清楚：业务状态、权限模型、数据闭环、验证体系、审计链路、复杂协同，比「把模型能力包装成界面」难被一次模型升级直接抹平。

Agent Native Infrastructure 的方向

Karpathy 把今天大部分基础设施的痛点指得很直白 — 控制台、菜单、设置页、API key、DNS 配置、环境变量、部署后台、账单页面，全部默认有一个人坐在屏幕前读、点、复制、粘贴。

Agent Native Infrastructure 大致包含几个方向：

基础设施方向 解决的问题
Agent-readable Docs 文档从说明材料变成执行材料
Tool Registry Agent 知道有哪些工具可用，如何调用
Permission Gateway 控制 Agent 能做什么，不能做什么
Execution Sandbox 隔离 Agent 的执行环境和影响范围
Verification Pipeline 用测试、规则、评估器验证结果
Audit and Cost Ledger 记录 Agent 做了什么、花了多少、造成什么影响

把文档、工具、权限、运行时、测试和审计重新组织成 Agent 能够工作的环境 — 这件事可能比单点工具升级更值得做。

未来 6-12 个月值得盯的三个信号

Karpathy 访谈末尾给出了三个值得跟踪的信号：

  1. 前沿实验室在编程和数学之外，往哪些领域注入 RL 数据。哪里被注入，那里的能力可能就会突然冒出来。Karpathy 访谈里被问到「创业者怎么找一个还没被 RL 覆盖的可验证领域」时明显想答但忍住了 — 这个回避本身说明这事的现实价值很大。

  2. Agent-first 基础设施有没有开始收敛。部署、auth、payments、DNS、配置这些环节，会不会出现真正「一句话给 Agent 就能跑」的标准件。如果没有，自动化的路可能还得走一段。

  3. 下一代模型有没有把审美和代码质量纳入 RL 目标。如果 Agent 写的代码不再让人「心脏病发作」，人在「品味」这一层守的口子就会变窄；反之，审美和抽象简化上的位置可能还会再撑一阵。

实践启示

  1. 从 L1 任务开始放量。先选输出可静态校验、可编译可测试的任务交给 Agent，把验证体系搭起来，再往 L3-L4 推进。L5-L6 任务保持人主导。

  2. 把控制面六层当成产品需求而不是技术细节。Context / Spec / Tool / Permission / Runtime / Verification / Audit / Cost，每一层都要明确「谁负责」，否则 Agent 一旦跑长链路，单点失控会被链路放大成工程事故。

  3. 优先重写文档而不是先写脚本。让 README、API 文档、Runbook 同时满足「人能理解、Agent 能执行、系统能验证」三件事，这是把 Agent 纳入工程体系的最低成本入口。

  4. 把人从搬砖者转成包工头。具体动作：把资深工程师的经验写成可执行规则和 Skill、让 PR review 从「看代码」上移到「看系统后果」、把架构约束写进 CI 而不只是写在 Wiki 里。

  5. 把 Agent 当成需要护栏的执行体，而不是需要鼓励的同事。默认配置包括：工具调用前校验、沙箱与只读默认权限、灰度与回滚、Token 与调用预算、全量日志审计链。

  6. 招聘标准需要重构。把模糊目标 → 清晰规格、指挥多 Agent 完成大规模实现、识别安全与架构风险、设置测试与验证、在模型生成的大量代码里保住质量判断这几条作为考察重点。

相关实体