--- title: "Karpathy 最新访谈：从 Vibe Coding 到 Agentic Engineering" type: source tags: [mlops, wechat, llm, ai-agent, engineering] source: wechat source_url: "https://mp.weixi" ingested: 2026-05-16 fetcher: wechat-mp-rss sha256: 4120ab99814f9e5c23e8dad71e32d5bb517370346ae974ea99cb44ad5b8cc09e sha256: ca608e237f3af2e5107738fa4a93355bdf6ad14b83e30c4ce8daa677fc323f60 --- --- source: wechat source_url: https://mp.weixin.qq.com/s/HTFcXBzYUVHvwShu3Zp-EA ingested: 2026-05-16 feed_name: 架构师 wechat_mp_fakeid: MP_WXS_3006407565 source_published: 2026-05-01 --- # Karpathy 最新访谈：从 Vibe Coding 到 Agentic Engineering 架构师（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对了吗? 让我们一起看看你的软件工程成熟度 ]() 》时，我们把重点放在自愈闭环、测试、发布、灰度、回滚和线上信号，而没有去强调"代码有多少由 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 差这么远 ]() 》里聊过 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 ]() 、 [ 上下文管理 ]() 、 [ Subagents ]() 、 ` [ .claude ]() ` 文件夹和 [ 过程资产维护 ]() 。那些文章更多是在拆 Agent 自己怎么工作；放到 Karpathy 这条线里看，可能都是同一件事的不同切片，以后衡量工程文档好不好，可能不只看人读懂没有，也得看 Agent 能不能照着把事做对。 文档读不通的话，Agent 就只能在网页、控制台、终端里模仿人乱试；如果文档、工具、权限、反馈这些东西都能被它稳定地读取和调用，它才有机会成为工程系统里相对可控的一环。 这里也能和《 [ Agent Harness 上下文管理：聊天记录还是工作集？ ]() 》那篇接上。我们当时说上下文窗口更像 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 设计产品？ ]() 》里那条线挺接得上。事实记忆回答"环境是什么"，会话检索回答"以前发生过什么"，过程资产回答"这类事以后怎么做"。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. 1\. ** 前沿实验室在编程和数学之外，往哪些领域注入 RL 数据。 ** 哪里被注入，那里的能力可能就会突然冒出来。Karpathy 访谈里被问到"创业者怎么找一个还没被 RL 覆盖的可验证领域"时，明显有想说但忍住了，"我不想直接给出答案……抱歉，我不是有意在台上发含糊推文的"。一个不愿在台上发含糊推文的人主动回避，本身就挺有意思。 2. 2\. ** Agent-first 基础设施有没有开始收敛。 ** 部署、auth、payments、DNS、配置这些让 Karpathy 做 MenuGen 时最头疼的环节，会不会出现真正"一句话给 Agent 就能跑"的标准件。如果一直没有，自动化的路可能就还得走一段。 3. 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 自己设计、升级 Agents]() [OpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳]() [Claude Skills 入门：把“会用 AI”变成“可复制的工程能力”]() [一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks]() [Claude 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 屎山代码的终极方案]() > 版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢! ** 架构师 ** 我们都是架构师！