---
title: "Karpathy 最新访谈：从 Vibe Coding 到 Agentic Engineering"
source_url: https://mp.weixin.qq.com/s/HTFcXBzYUVHvwShu3Zp-EA
tags: [wechat, article, claude, openai, gpt, agent, harness, openclaw]
source_type: wechat
provenance_state: extracted
sha256: 7c35784a8ae492ce1296ac39366a727d5b5a4e90b8e7eb8b6366bb51b1bcfc98
---
---
架构师（JiaGouX）
我们都是架构师！
架构未来，你来不来？
#
从氛围编程到智能体工程
这两天把 Karpathy 在红杉 AI Ascent 2026 的访谈反复看了几遍，又顺手翻了一圈 2026 年 X 上关于 Vibe Coding 和 Agentic Engineering 的讨论。一些零散的想法，想跟大家聊聊。
老实说，看完访谈我一个直接的感受是：
这件事好像不太能只放在“AI 写代码更快了”这个框里理解了。
Vibe Coding 当然挺重要。它把软件创造的门槛拉得很低，以前不值得排期的小工具、临时页面、个人脚本、内部小系统，现在一个下午就能跑起来，这是真切的变化。
但 Karpathy 这次想说的，似乎已经不止这件事。
真正让人多想一会儿的是另一层：当 Agent 不再只是补全代码，而开始读上下文、改文件、调工具、跑测试、配服务、处理部署时，它其实已经走进了软件工程的链路里。
Vibe Coding 解决的是“更快做出来”这件事；再往后一步，更快之后，还能不能可靠地交付，是另一类问题了。
我们先不急于翻译访谈，有兴趣可以直接看视频。主要还是想看看跟我们架构师、技术管理人员的关系。
访谈只是个由头，我想顺着它聊聊另一件事：
Agent 真的进入研发流程之后，作为做架构、做技术管理的人，可能要重新想一想哪些东西。
这个问题跟前一阵聊过的几条线挺接得上的：AI-First 的门槛为什么最后落到软件工程，Agent Harness 为什么决定同一个模型能跑多远，上下文为什么不该再当聊天记录，过程资产为什么会比更长记忆更重要。
回头看，那几篇文章像是在讲不同产品、不同实现，放到 Karpathy 这次访谈里，反倒像是在指同一件事：
Agent 时代稀缺的，可能不是一次生成代码的能力，而是让 Agent 在真实工程里能持续、可控、可验证地工作的那套系统。
##
太长不看版
- • Vibe Coding 不是过时玩具，它把软件创造的下限拉低了，原型、探索、个人工具、低风险场景里都挺好用。
- • Agentic Engineering 面对的是另一类问题：上下文、权限、工具、验证、审计、回滚，这些围绕真实交付的事。
- • 2026 年的讨论慢慢出现一个隐隐的共识，AI 生成代码只是第一步，更难的是把 Agent 放进可控的工程系统里。
- • Software 3.0 的重点，可能不在“Prompt 替代代码”，而在上下文、文档、工具、测试和运行环境，都开始变成需要被设计的对象。
- • 可验证性大概会决定 Agent 自动化能走多远。没有验证体系托底的话，Agentic Engineering 顶多算更高级的 Vibe Coding。
- • 做架构、做技术的人，重心可能要从模块、接口往上挪一层，去想 Agent 能在什么样的环境里安全地工作。
我们先看看总揽图：从 Software 1.0、2.0 到 3.0，变化不只在开发者怎么写代码，也在软件系统到底围绕什么来设计。
从氛围编程到智能体工程的整体框架
##
2026 年，这个词为什么又变了
先把时间线捋一下。
2025 年 2 月，Karpathy 在 X 上提出 Vibe Coding。那条推文会火，并不靠定义严密，更像是刚好说中了很多人的体感：LLM 已经强到可以让人“说需求、看结果、继续调整”，甚至暂时忘记代码本身。
到了 2026 年 2 月，一周年时，他又在 X 上回看这个词，并开始更偏好另一个说法：
Agentic Engineering。
这不只是一个改名。
如果说 Vibe Coding 命名的是一种个人体验，Agentic Engineering 命名的就是一套专业工作方式。
这个变化很快被工程圈接住。Google 的 Addy Osmani 在 2026 年 2 月写了一篇《Agentic Engineering》，把两者区分得很清楚：Vibe Coding 可以用于原型、MVP、个人脚本和探索，但专业软件开发不能停在“接受 AI 输出、不读 diff、报错再 prompt”的循环里。更成熟的做法是：先写规格，拆任务，交给 Agent 实现，再像 review 人类 PR 一样 review 它的输出，最后用测试和 CI 把结果压住。
同一时间，还有一个更有意思的信号：2026 年 2 月发布的 GLM-5 论文，标题就叫《from Vibe Coding to Agentic Engineering》。这说明“从 vibe 到 engineering”已经从推特上的命名争论，进入了模型训练、长上下文、异步强化学习、真实软件工程任务这些更底层的问题。
再往旁边看，Linus Torvalds 对 Vibe Coding 的态度也很有参考价值。他并没有把 AI 辅助编程一棍子打死，反而把它看成类似编译器一样的工具。但他对关键系统里的使用边界非常谨慎。这个态度我觉得很工程：小项目、学习、探索可以大胆用；真正重要的系统，质量门槛不能因为 AI 加入而降低。
几条线连起来看，体感大概是：Vibe Coding 更像软件创造方式的变化，Agentic Engineering 更像软件工程责任边界的变化。前者让更多人能做东西，后者关心这些东西能不能进入真实系统。
之前整理《
[
你的AI-First对了吗? 让我们一起看看你的软件工程成熟度
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409030&idx=1&sn=e435a8b1fca46cea3e5514f0541d3a17&scene=21#wechat_redirect)
》时，我们把重点放在自愈闭环、测试、发布、灰度、回滚和线上信号，而没有去强调"代码有多少由 AI 写"。那篇讲的是一个团队怎么围绕 AI 重新串研发链路，Karpathy 这次访谈聊的，像是同一件事的另一个角度。
所以 Agentic Engineering 看起来不像什么"新概念"，更像是过去一年 AI Coding 经验慢慢沉下来之后，凑巧有了一个更像工程的名字。
我们可以从这个访谈里，看到三个提醒：跨越中间层，遵守工程纪律，别把理解力外包出去。后面逐个展开。
拥抱 3.0 时代的三个提醒
##
Karpathy 说“落后了”，其实是在说任务粒度变大了
在访谈里，Karpathy 提到 2025 年 12 月是一个明显的转折点。
此前他已经用了很久 Agentic Coding 工具。早期体验和很多工程师差不多：工具能帮忙，能生成代码块，但经常需要人修补、改错、拉回方向。
到了 2025 年底，他感觉模型输出开始稳定得多。模型不再只会补一个函数，已经能接住更大的一段工作。他不断把任务交出去，模型生成的代码块越来越完整，他也越来越少亲自纠正。
这句话本身不太重要，重要的是它背后那件事，AI 能接住的任务边界，肉眼可见地变大了。
过去 AI 接的多是局部任务：写一个函数、补一个测试、修一个报错、改一个页面、生成一段脚本。
现在它开始接一段流程：读项目上下文、理解任务目标、改多个文件、调命令、跑测试、根据失败继续修、最后给一个可 review 的结果。
这两种状态对工程系统的意义其实是不一样的。前者还是个开发工具，后者已经走到工程系统内部了。
到这一步，"工具是不是更聪明"反而变成次要问题。它进来之后，哪些边界要重新想一想，可能更值得聊。
##
顺便说说 Vibe Coding 的位置
把 Vibe Coding 直接说成"玩具"，多少有点冤枉它。
它确实释放了很多生产力，也让一批以前根本不写代码的人第一次能把想法变成软件。对个人工具、一次性脚本、内部小页面、低风险原型来说，这个变化是真切的。
以前很多需求不是做不出来，是不值得做，一个小工具排研发排期不值当，自己写又太费时间。Vibe Coding 大概就是把这个成本打下来了，顺便激活了一长串长尾需求。
但它的边界也是肉眼可见的：能跑不等于可靠，功能完成不等于设计正确，原型效率不等于生产质量。
Addy Osmani 那篇文章里有句话挺扎实的，很多团队把周末原型和专业工程都叫 Vibe Coding，结果把两个完全不同的东西混在了一起。
说穿了，Vibe Coding 让一个想法更快出现，但它不天然附带架构、测试、安全、可维护性和责任边界这些事。个人工具坏了自己修，没什么大事；一旦进了影响用户、资金、权限、数据、合规的真实业务系统，"AI 生成得快不快"就不是第一位的指标了。
这也是我更愿意把两者分开看的原因：Vibe Coding 抬高下限，Agentic Engineering 守住专业软件的上限。
AI 编程的两条路径：抬高下限与守住上限
##
那 Agentic Engineering 到底在聊什么
Karpathy 在访谈里给了一个挺好的分界：Vibe Coding 抬高的是所有人做软件的下限，Agentic Engineering 要守的是专业软件的质量门槛。
往工程系统这一层翻译一下，大致可以这么看，Agentic Engineering 像是一套围绕 Agent 执行工程任务的工作方式。它要回答的问题挺具体：
- • Agent 能看到哪些上下文，哪些不能给它看；
- • 它可以调用哪些工具、命令、API 和数据库；
- • 哪些文件可以改，哪些文件只能读；
- • 哪些动作需要人审批；
- • 哪些结果必须通过测试、编译、静态扫描和安全检查；
- • 执行环境怎么隔离；
- • 失败之后怎么回滚；
- • 整个过程怎么审计、追责、算成本。
这一串问题放在一起看，能感觉到，很多团队真正缺的，可能不是"再来一个更聪明的 Agent"，而是一层把这些问题串起来的控制面。之前文章里我们叫它 Agent Control Plane，大概可以分这么几个方面：
控制面
主要问题
Context Control
Agent 能看到什么，不能看到什么
Spec Control
任务目标、约束和验收标准如何表达
Tool Control
Agent 可以调用哪些工具，调用参数如何约束
Permission Control
哪些动作允许，哪些动作需要审批
Runtime Control
执行环境如何隔离、限额、恢复
Verification Control
结果如何通过测试、编译、规则和评估器验证
Audit Control
Agent 做了什么、为什么做、造成什么影响
Cost Control
Token、模型调用、工具调用和重试成本如何控制
Agentic Engineering 不是要让 Agent 获得无限自由，更像是给它划出一片可控的自由度。表面上像是在选"用哪个 AI 编程工具"，往里面多走一步，其实是在重新想研发体系的控制面要怎么搭。
之前我们在《
[
Agent Harness 综述：同一个模型，为什么做出来的 Agent 差这么远
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409084&idx=1&sn=b8db9f9925f5dba578cfc7044981f25a&scene=21#wechat_redirect)
》里聊过 Harness，模型外面那套"怎么跑、怎么停、怎么纠偏"的系统。控制面大概就是把 Harness 往企业研发体系再多推一步：这些能力在团队、仓库、权限、上线链路和审计体系里怎么真正落下来。
把 Agentic Engineering 当成一个全新名词，反而容易绕远。它更像是给一组老问题换了个新坐标，上下文怎么组织、任务怎么拆、权限怎么收、工具怎么暴露、结果怎么验证、失败怎么恢复、经验怎么沉淀。这些问题过去也都在，只是 Agent 把它们推到了台前。
##
Software 3.0：上下文好像也成了架构对象
Karpathy 重新谈到了他那套 Software 1.0、2.0、3.0。
Software 1.0 是传统软件：人写显式规则，机器按代码执行。Software 2.0 是神经网络时代：人设计数据、目标和训练过程，模型权重也变成了软件的一部分。Software 3.0 是大语言模型时代：LLM 更像一个新的信息处理解释器，人通过提示词、上下文、文件、工具和环境来影响它的行为。
不少地方把 Software 3.0 直接理解成"以后写 Prompt 就行了"。
这个理解可能稍微浅了一点。
从工程系统这一层往里看，可能更接近的描述是：上下文、文档、工具、记忆、权限、测试、部署环境，正在一起变成需要被设计的"软件材料"。
阶段
核心材料
关注点
Software 1.0
代码
模块、接口、依赖、运行时
Software 2.0
数据与模型权重
数据集、训练过程、模型评估
Software 3.0
上下文、工具、记忆、权限、验证
Agent 工作环境、可执行上下文、任务闭环
这张图更直观一点：软件 3.0 不是把代码编辑器换成聊天框，而是把提示词、上下文和 Agent 工作环境一起放进了架构讨论。
软件的进化：1.0、2.0 到 3.0
过去做
架构
主要在想系统模块之间的关系；现在好像还要再想一层：Agent 和系统之间的关系。比如它能读哪些文档、改哪些文件、调哪些 API、执行哪些命令，输出怎么验证、错误怎么隔离、行为怎么追踪。
也是因为这个，单纯给 IDE 加一个聊天框总觉得不太够。Prompt 更多还是入口，真正决定 Agent 能不能稳定工作的，往往是它工作环境的上下文、工具、权限、运行时和验证。
Karpathy 还把这条线往更远处推了一步：如果神经网络越来越像主进程，传统 CPU、API 和确定性代码就会更像协处理器。这个判断现在还偏远，但它有助于提醒我们：Agentic Engineering 不是代码层加速，而是在重新安排计算系统里谁主导、谁辅助。
硬件层面的映射：计算架构的终极反转
##
文档可能在从"给人看"慢慢变成"给 Agent 执行"
Karpathy 在访谈里提了个 OpenClaw 安装的小例子，挺能说明问题。
传统安装方式一般是 shell script。脚本要提前穷举各种环境差异，不同平台、不同依赖、不同权限、不同路径。目标环境越复杂，脚本越容易膨胀成一坨很难维护的条件分支。
Agentic 方式可以是另一种形态：一段给 Agent 的说明，目标是什么，约束是什么，要检查什么，失败了怎么处理。Agent 根据本机环境观察、执行、调试、回报结果。
这里最有意思的，是文档角色的那点微妙变化。
过去 README、API 文档、Runbook、部署手册基本都是给人看的。往后，大概率要同时满足三件事：人能理解、Agent 能执行、系统能验证执行结果。
过去的工程资产
Agentic 时代的工程资产
README 给人读
README 也要能被 Agent 正确使用
API 文档给开发者查
API 文档给 Agent 规划调用
运维手册给 SRE 看
Runbook 可以被 Agent 执行和修复
Shell Script 固化流程
Instruction 描述目标、约束和边界
CI/CD 执行固定流水线
Agent 参与动态排障、修复和验证
这也是我最近越来越关注"过程资产"的原因。
之前我们陆陆续续梳理过
[
Agent Harness
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409084&idx=1&sn=b8db9f9925f5dba578cfc7044981f25a&scene=21#wechat_redirect)
、
[
上下文管理
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409162&idx=1&sn=62556a10e227bcb8d977a4f3e0006c8b&scene=21#wechat_redirect)
、
[
Subagents
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409171&idx=1&sn=f1205a72f8219032770c1144307d1efa&scene=21#wechat_redirect)
、
[
.claude
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409124&idx=1&sn=180416118fbed11d4def779ed4485070&scene=21#wechat_redirect)
文件夹和
[
过程资产维护
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409178&idx=1&sn=6ab1bf7946b83e32b5e660b0db411982&scene=21#wechat_redirect)
。那些文章更多是在拆 Agent 自己怎么工作；放到 Karpathy 这条线里看，可能都是同一件事的不同切片，以后衡量工程文档好不好，可能不只看人读懂没有，也得看 Agent 能不能照着把事做对。
文档读不通的话，Agent 就只能在网页、控制台、终端里模仿人乱试；如果文档、工具、权限、反馈这些东西都能被它稳定地读取和调用，它才有机会成为工程系统里相对可控的一环。
这里也能和《
[
Agent Harness 上下文管理：聊天记录还是工作集？
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409162&idx=1&sn=62556a10e227bcb8d977a4f3e0006c8b&scene=21#wechat_redirect)
》那篇接上。我们当时说上下文窗口更像 Agent 运行时的工作集，而不是一段无限增长的聊天记录。现在再看，Agentic Engineering 大概就是把这个判断放大到整个研发体系，仓库、文档、日志、测试、Runbook、审批记录，慢慢从"人偶尔查一下"的资料，变成 Agent 能按需进入、按规则使用、按结果回写的工作集。
这条线和 MenuGen 的例子正好连在一起：当模型越来越能直接处理原始输入，很多“把中间步骤串起来”的应用层就会变得危险。
破除旧思维：被淘汰的中间应用层
##
MenuGen 的小提醒：有些中间层可能会被模型吞掉
Karpathy 还讲了 MenuGen。
App 的想法很直观：在餐厅拍菜单，应用识别菜名，为每道菜生成大概的图，再把菜单重新渲染出来。按传统思路，它会拆成上传图片、OCR、抽菜名、调图像生成、重新排版、前端展示、部署上线一长串步骤。
Karpathy 用 Vibe Coding 把它做出来了。
但后来他自己发现，Software 3.0 的版本可能根本不需要这个 App，把菜单照片直接扔给多模态模型，让模型把菜品图叠加回原菜单上，模型可以直接返回一张修改后的图片。
我觉得这是访谈里最值得停下来想一会儿的一段。它对做产品和做架构都是一个挺现实的提醒，当模型可以直接处理原始输入并生成目标输出时，应用中间层有可能就这么被吞掉。
系统形态
风险
只包装模型能力
容易被模型升级吞掉
只把 Prompt 做成页面
缺少架构壁垒
只做输入输出格式转换
容易被模型原生能力替代
深入业务流程
有一定壁垒
掌握权限、数据、状态、审计
壁垒更强
承担复杂系统协同和验证
更接近基础设施
所以做架构的时候，可能不只是问"这个功能能不能做"，还要顺手问一句：它会不会只是模型能力暂时不到位时的中间层？
坦白说，这个判断在很多具体产品上并不好下。模型能力的边界一直在动，今天必须外置的一层，几个月后可能就被模型自己吞了。但方向上还是慢慢清晰：业务状态、权限模型、数据闭环、验证体系、审计链路和复杂协同，比"把模型能力包装成界面"难被一次模型升级直接抹平。
##
可验证性可能决定 Agent 能走多远
Karpathy 在访谈里反复在讲可验证性，我觉得这一点挺关键的。
他的原话大致是：传统计算机容易自动化你能写进代码的东西，这一代 LLM 更容易自动化你能验证的东西。代码、数学、测试、编译、结构化任务之所以进展快，可能不只是因为模型整体变聪明了，更因为这些领域容易构造反馈，代码能不能编译，测试能不能通过，漏洞能不能复现，格式是否满足约束，这些都可以变成模型的奖励信号。
也是因为这个，我觉得 GLM-5 论文挺有信号意义。它没有停在模型参数上，而是把长上下文、异步强化学习、真实软件工程任务放在同一个框架里讨论。背后的方向比较清楚：模型在从"生成答案"慢慢走向"在长链路里执行、反馈、修正"。
落到团队里，一个朴素的次序大概是，先看哪些事情能被验证，再决定哪些事情交给 Agent。粗略可以这么分一下：
等级
任务特征
Agent 适用程度
L1
输出可静态校验
高
L2
可编译、可测试
高
L3
可通过集成测试验证
较高
L4
涉及业务规则与状态变更
需要审批和审计
L5
涉及资金、身份、权限、数据删除
必须强管控
L6
涉及组织判断、法律责任、战略选择
人必须主导
这张表不是要保守地把 Agent 关起来，反而是为了让自动化能走得更远，
把验证体系搭起来，Agent 就有机会从"帮我写一段代码"，进入"帮我完成一段工程任务"。反过来，如果验证这一层始终缺位，那种状态其实更接近"高级一点的 Vibe Coding"。
##
锯齿状智能：还是得留点护栏
Karpathy 用"锯齿状智能"形容 LLM 那种不均匀的能力。访谈里有一个画面感很强的例子：他问最先进的模型，
要去 50 米外的洗车店洗车，是开车还是走路？
模型说走路，因为 50 米很近。问题在于，他要洗的是车，车必须到洗车店。
一个最先进的模型可以重构 10 万行代码、找到零日漏洞，却告诉我应该走路去洗 50 米外的车。
参差不齐的智能：为什么 AI 能写底层代码，却不会去洗车
这事不太能简单归结为"聪不聪明"。更接近的说法可能是：大模型的能力不是一条平滑曲线，而是由训练数据、奖励函数和验证环境塑造出来的一片地形，某些区域高得吓人，某些区域又突然塌下去。
他还顺手提了一个我以前没太注意的细节：从 GPT-3.5 到 GPT-4，国际象棋能力大幅提升，看起来像"模型整体变聪明了"，实际上是因为有人在 OpenAI 决定把大量国际象棋数据加进了预训练。
数据进了分布，能力就跟着上去了。一个看起来"能力进化"的故事，到这里变成了"实验室在做产品决策"的故事。
如果这个判断成立，对落地的人其实有点提醒意义：
不太能假设下一代模型会自动覆盖你关心的领域。
如果业务场景刚好落在前沿实验室 RL 训练覆盖的回路里，那挺好；落在外面的话，要么自己构造可验证环境去微调，要么就接受 Agent 在那个领域只是个不太稳定的实习生。
也是因为这个，把 Agent 当成"稳定的资深工程师"来用，多少有点危险。它更像一个能力很强、执行很快、但边界并不总是可靠的执行体。
Simon Willison 在 2025 年提过一个挺好用的安全框架：当 Agent 同时具备访问私有数据、接触不可信内容、对外通信这三种能力时，风险会陡然上升。Agent 真正的危险，往往不只是"写错代码"，更危险的是它读到了不可信输入、又拿到了真实权限、还能把结果发出去这种组合。
所以护栏这件事，可能不是补丁，更像默认配置：
风险
可能的护栏
幻觉执行
工具调用前校验
错误修改代码
分支隔离和代码审查
误删数据
沙箱和只读默认权限
错误部署
灰度、回滚、审批
错误关联身份和资金
稳定 ID 与领域模型约束
Prompt Injection
私有数据、不可信输入、外部通信分离
成本失控
Token 限额、调用预算、模型路由
行为不可追溯
全量日志和审计链
Karpathy 自己也讲了个挺典型的支付例子。用户用 Google 账号登录，但买 credits 时用的是 Stripe。Google 和 Stripe 都有邮箱字段。Agent 在实现逻辑时，就用 Stripe 邮箱去匹配 Google 邮箱，把 credits 挂到用户身上。
代码能跑，局部测试也可能过。但系统语义是错的，邮箱本来就不该当稳定用户身份，用户完全可能一个邮箱登录、另一个邮箱付款，资金、credits、订单这些得挂在系统内部的稳定 user ID 上，不能挂在一个外部邮箱字符串上。
这类错误最让人头疼的地方，是它属于业务语义错误，语法上往往看不出来。Agent 最危险的错误，可能不在代码语法，而在它把身份、权限、状态、责任这些关系理解偏了，而这恰好是做架构、做技术的人比较敏感的地方。
##
顺手聊聊"幽灵"这个比喻
Karpathy 在访谈里花了不少篇幅讲他自己写过的一篇文章，主题是
animals vs ghosts
。结论挺有意思，我们不是在造动物，而是在召唤幽灵。
这个说法听起来有点玄，他想表达的其实并不玄。
动物智能来自进化、身体、环境互动、内在动机、好奇心、乐趣、持续学习。它们在世界中行动，被后果塑造，会在生命过程中不断适应。LLM 不是这样。它来自大规模预训练，叠加 RL、偏好数据、工具调用这些后训练过程，更像是由人类文档、统计模式和奖励函数塑造出的"模拟实体"。
如果你对它大吼，它不会因此工作得更好或更差，也没有任何影响。
读到这里，能顺手抽出几个比较朴素的提醒：
- • 笼统地问"AI 聪不聪明"意义不大，更值得问它在哪些分布里强、哪些奖励信号塑造了它、在哪些任务上可能掉到断崖里。
- • 把 Agent 当"有动机的员工"也容易出问题，它没有惧怕、没有自尊，不会因为你催它就更努力，也不会因为你鼓励它就更可靠。
- • 也很难把它当成稳定的"资深工程师"，毕竟能力分布是锯齿状的，今天某个高峰可能来自最近一次数据决策，下个版本可能又是另一张地形图。
把 Agent 看成幽灵而不是同事，
前面那些控制面的设计反而会显得自然一些，上下文、权限、工具、验证、审计这些机制不是因为 Agent"不够好"才补的，而是它本来就不是一个可以直接套用人类管理直觉的对象。
##
人的位置：可能不是消失，更像是慢慢上移
Karpathy 在访谈末尾引了一句话：
你可以外包思考，但不能外包理解。
这句话挺容易被写成鸡汤的，但放到 Agentic Engineering 里其实蛮具体。
API 参数、样板代码、局部重构、测试补全，这些细节正在变便宜。Karpathy 自己举了一个挺接地气的例子：他已经不再去记 PyTorch、NumPy、pandas 之间那些细碎的 API 差异，比如是
keepdims
还是
keepdim
、
dim
还是
axis
、
reshape
/
permute
/
transpose
各自怎么用。这些都可以扔给 Agent。
但我仍然必须理解 tensor 是什么，view 和 storage 的关系是什么，什么时候只是同一块内存的视图，什么时候会真的复制数据。
你可以将思考外包，但不能外包理解
我觉得这就是"细节可以外包、理解不能外包"的具体形态。
API 名字忘了无所谓，但概念结构丢了，就很难判断 Agent 写出来的东西是真的高效，还是只是看起来在跑。
他还顺手吐槽过 Agent 写出来的代码常常让他"有点心脏病发作的感觉"，能跑，但臃肿、复制粘贴、抽象别扭、结构脆弱。做 MicroGPT 时他不断让模型"再简化一点"，模型就是做不到，像"拔牙"一样。
它能跑，但真的很恶心。
代码能跑和代码好从来不是一回事。Agent 暂时还没被很好地训练到"极简、克制、优雅"的奖励信号上，这个口子目前只能由人守一会儿。再加上"系统为什么这样设计、身份怎么建模、权限怎么收敛、状态怎么流转、失败怎么恢复、哪些动作不能自动化"这些问题，也都还在人这一侧。
过去高级工程师和初级工程师的差异，挺大一部分体现在实现能力上，能不能写更复杂的代码、记住更多 API、排查更隐蔽的问题。在 Agentic Engineering 里，这种差异多少会上移。
过去重要
现在可能更重要
熟悉 API 细节
理解底层机制
手写业务代码
定义业务语义
写脚本自动化
设计 Agent 执行边界
完成功能
设计验收标准
修 bug
建立验证体系
控制模块依赖
控制 Agent 权限和上下文
管理代码质量
管理系统后果
这不是说实现能力不重要，反过来，越懂实现，越能判断 Agent 写出的东西靠不靠谱。只是人的主要价值，可能会更多落在规格、边界、验证、取舍和理解这几件事上。
最后的瓶颈：人类的品味与判断力
也是因为这个，2026 年我看到很多推文在反复强调"维护""测试""Skill""可执行规范"。比如有人把代码维护经验写成 Claude Code Skill，让 Agent 自己跑文档清理、测试补充、大文件拆分、重复代码提取、手写轮子替换。例子不算大，但方向上挺对，把资深工程师的经验，从口头提醒变成 Agent 可以执行的流程资产。
这和《
[
如何为 Agent 设计产品？
](https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=2650409144&idx=1&sn=0d15111cf536be0d6aa1946d5a225ae9&scene=21#wechat_redirect)
》里那条线挺接得上。事实记忆回答"环境是什么"，会话检索回答"以前发生过什么"，过程资产回答"这类事以后怎么做"。Agentic Engineering 真正想沉淀的，可能更多是第三层。
如果一个团队只让 Agent 记住更多聊天记录，长期看可能不太够；把稳定的排障路径、发布检查、PR review 清单、数据迁移步骤、安全红线写成可执行资产，下次同类任务来的时候，Agent 就不是在猜一个资深工程师会怎么想，而是在沿着团队已经走过的路径走。
新型工程师的日常：从搬砖者到包工头
##
顺带一提：AI-native 工程师的面试可能也得换
访谈里有个问题挺现实：
如果同时观察两个使用 AI coding 工具的人，一个普通、一个真正 AI-native，区别会在哪？
Karpathy 先说了句很朴素的话，AI-native 工程师会认真投资自己的工作流。就像过去会花时间配 Vim、VS Code、命令行、快捷键一样，现在也要花时间把 Cursor、Claude Code 调成真正适合自己的样子。
但他更想吐槽的其实是招聘流程。
很多公司的面试还停留在"现场写一道算法 puzzle"那一套，测出来的是"能不能在白板上手写一个 trie"，跟一个人在 Agentic Engineering 里能不能干活基本两码事。他给出的替代方案是这样：
面试本该是这样的：甩给候选人一个极大的项目，比如做个给 Agent 用的 Twitter 仿盘，要求做得绝对安全。然后，我挂上 10 个 Cursor 当作"红队"，放开手脚去攻击你做出来的这个网站。
招聘标准的重构：放弃算法题，拥抱实战攻防
这套评估方式真正想看的，不是手写算法，而是候选人能不能把模糊目标变成清晰规格、指挥多个 Agent 完成大规模实现、识别安全和架构风险、设置测试与验证、在模型生成的大量代码里保住质量判断、让最终系统经得起外部 Agent 的攻击。
读到这里能感觉到：当代码越来越多由 Agent 生成，"能不能保住系统"就慢慢变成了一个工程师的核心能力。这正是过去做架构的人比较熟悉的事，定义边界、设置验证、推演攻防、规划回滚。
换句话说，
Agentic Engineering 时代里"高级工程师"和"架构师"之间那条线，可能会比以前更模糊一些。
##
顺一个方向：Agent Native Infrastructure
访谈里 Karpathy 还讲了一个挺现实的痛点：今天大部分基础设施还是给人设计的。
控制台、菜单、设置页、API key、DNS 配置、环境变量、部署后台、账单页面，全部默认有一个人坐在屏幕前读、点、复制、粘贴。Agent 时代大概率需要的是另一套东西。
Agent Native Infrastructure 大概可以这么理解：让 Agent 可以理解、调用、验证、恢复和审计真实系统的那一层基础设施，而不是让它模拟人去点网页。粗略可以拆成几个方向：
基础设施方向
解决的问题
Agent-readable Docs
文档从说明材料变成执行材料
Tool Registry
Agent 知道有哪些工具可用，如何调用
Permission Gateway
控制 Agent 能做什么，不能做什么
Execution Sandbox
隔离 Agent 的执行环境和影响范围
Verification Pipeline
用测试、规则、评估器验证结果
Audit and Cost Ledger
记录 Agent 做了什么、花了多少、造成什么影响
下一代研发基础设施可能不会停在"给 IDE 加一个聊天框"这一层，更值得做的是把文档、工具、权限、运行时、测试和审计重新组织成 Agent 能够工作的环境。也是因为这个，我现在越来越倾向于把 Agentic Engineering 看成一个工程体系问题，而不只是单点工具问题。
当一个 Agent 可以打开项目、理解任务、改代码、跑测试、提交 PR、处理反馈、修复部署问题时，它接触到的已经是一条完整的研发链路。链路里任何一个环节没有边界，模型那点不稳定，就会被放大成工程事故。
##
写在最后
我自己现在对 Agentic Engineering 的态度，可能比半年前更谨慎一点，同时也更乐观一点。
谨慎的是，Agent 还会犯不少低级错误，会生成臃肿代码，会把业务语义理解偏，会把邮箱当用户 ID，会在不该自信的时候自信。乐观的是，这些问题并不代表 Agent 没法进入工程系统，更像是在提醒我们：得把它放进合适的工程系统里。
从 Vibe Coding 到 Agentic Engineering，变化可能不只发生在工具和写代码方式上。
再往深处看一点，我现在更倾向于这么理解，软件工程的控制对象正在悄悄变化：过去主要控制的是代码、模块、接口、服务、数据流和部署流程；今天可能还得加上 Agent 的上下文、权限、工具调用、执行环境、验证机制和行为后果。
对个人开发者来说，Vibe Coding 已经挺有价值了，它让很多想法可以更快变成软件。但对一个团队、一个研发体系来说，
事情可能刚刚开始
，Agent 进入真实工程之后，最好被放在一个可验证、可隔离、可回滚、可审计的系统里。给 AI 加几条使用规范，大概率解决不了这个层面的问题。
所以我自己的小结大概是：Vibe Coding 是开始，再往后要慢慢补上的，是 Agentic Engineering。把今年聊过的这几篇文章串起来看，我的判断也会更朴素一点：AI Coding 的上半场，大家在看模型能不能写代码；下半场，差距会越来越落到模型外面的那套系统，Harness、上下文、过程资产、权限、验证、发布、审计。模型会继续变强，但越强的模型，可能越需要清楚的工程边界。
这件事听起来没有"一个人顶一个团队"那么刺激，但我个人觉得它更接近真实的软件工程。
最后顺便记一下我自己未来 6-12 个月想盯的三个信号：
- 1.
前沿实验室在编程和数学之外，往哪些领域注入 RL 数据。
哪里被注入，那里的能力可能就会突然冒出来。Karpathy 访谈里被问到"创业者怎么找一个还没被 RL 覆盖的可验证领域"时，明显有想说但忍住了，"我不想直接给出答案……抱歉，我不是有意在台上发含糊推文的"。一个不愿在台上发含糊推文的人主动回避，本身就挺有意思。
- 2.
Agent-first 基础设施有没有开始收敛。
部署、auth、payments、DNS、配置这些让 Karpathy 做 MenuGen 时最头疼的环节，会不会出现真正"一句话给 Agent 就能跑"的标准件。如果一直没有，自动化的路可能就还得走一段。
- 3.
下一代模型有没有把审美和代码质量纳入 RL 目标。
如果 Agent 写的代码不再让人"心脏病发作"，那人在"品味"这一层守的口子就会变窄；反之，人在审美和抽象简化上的位置可能还会再多撑一阵。
这三件事大概决定了 Agentic Engineering 的边界会以多快的速度往外推。具体怎么走，我也没有把握，先聊到这里，欢迎大家在评论里一起拍
##
参考资料
- • Andrej Karpathy 在 Sequoia AI Ascent 2026 的访谈视频：https://www.youtube.com/watch?v=96jN2OCOfLs
- • Andrej Karpathy 关于 Vibe Coding 的原始 X 推文：https://x.com/karpathy/status/1886192184808149383
- • Andrej Karpathy 关于 Agentic Engineering 的一周年回看 X 推文：https://x.com/karpathy/status/2019137879310836075
- • Addy Osmani，《Agentic Engineering》：https://addyosmani.com/blog/agentic-engineering/
- • GLM-5: from Vibe Coding to Agentic Engineering：https://arxiv.org/abs/2602.15763
- • Simon Willison，《The lethal trifecta for AI agents》：https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
**
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
**
**
·END·
**
```
相关阅读：刚刚，Claude Code“代码泄露”背后：如何重新看 Agent Harness大家都在讲 Harness，但它到底该怎么理解模型越来越强，为什么大家却开始重写 Harness如何让单个 Agent 做长任务不失真：Anthropic 给出了一套更工程化的答案Claude Code高手的 8 个 Claude Code 实战习惯别从 README 开始：一个架构师会怎样翻 Codex 仓库Spec 不是代码的替代品，它是 AI Coding 的上下文管理层如何让 Agents 自己设计、升级 AgentsOpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳Claude Skills 入门：把“会用 AI”变成“可复制的工程能力”一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、HooksClaude Code 最佳实践：把上下文变成生产力（团队可落地版）把 AI 当成新同事：Agent Coding 的上下文与验证体系一周写百万行的背后：Cursor长时间运行 Agent 的工程方法论2026年生活重启指南我真不敢相信，AI 先加速的是工程师。扒一扒 Claude Cowork 系统提示词：Anthropic 如何打造数字同事Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品Anthropic官方万字长文：AI Agent评估的系统化方法论银弹还是枷锁？Claude Agent SDK 的架构真相Claude Code创始人亲授13条使用技巧Claude Code 内部工具开源 code-simplifier：终结 AI 屎山代码的终极方案
```
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
**
架构师
**
我们都是架构师！