Agentic Engineering

Andrej Karpathy 在 2026 Sequoia AI Ascent 演讲中提出的概念，描述在 Vibe Coding 基础上维持专业软件质量标准的工程学科。

Vibe Coding vs. Agentic Engineering

维度	Vibe Coding	Agentic Engineering
目标	提升所有人能做的事情的底线（Floor）	维持专业软件的质量标准（Quality Bar）
对象	任何人（包括非技术人员）	专业软件工程师
核心问题	”如何让人人都能构建软件？"	"如何在用 agent 提速的同时不引入漏洞？“
责任	松散，结果就够	严格，对软件安全性和正确性负全责

Karpathy 的核心论点：Vibe Coding 是提升 floor，Agentic Engineering 是在保持 quality bar 的同时走得更快。两者都很重要，但属于不同维度。

Source: 2026-07-06-youtube-youtu-be-96jN2OCOfLs-si--p6--F-hghVosCS（来源未公开）

从聊天框到执行系统 (Unhobbling Claude)

给模型配备 bash 和代码执行工具后，模型能自主在环境中搜索并构建上下文，产生能力的非线性突变（spiky capability overhang），把传统的聊天框升级为了一个真正的执行系统。

1. 自主上下文构建

传统的代码辅助系统倾向于通过扩大上下文窗口（例如将整个代码库塞入 100M 上下文）来解决问题。而更先进的方案（如 Claude Code / Fable）是给模型提供“手和脚”——如 bash 工具和代码执行能力，让模型能够自主在运行环境中检索、搜索和构建所需的上下文。

2. 能力的非线性突变 (Spiky Capability Overhang)

当大模型获得了执行环境后，其能力会在某些特定方向上产生爆发式的非线性突变。

典型案例：询问普通聊天模型“哪些 Pokemon 的名字以 AW 结尾”时，尽管它在权重中存有所有 Pokemon 的知识，但由于词元切分 (Tokenization) 以及注意力机制的局限，它无法准确答出（实际上只有 Croconaw 和 Dewgong 等极少数）。但如果给 Claude Code / Fable 配备代码执行工具，它会直接写一段 Python 脚本在运行环境中拉取 Pokemon 列表并进行字符过滤，迅速且百分百准确地给出答案。
工程启示：智能体工程师需要善于发掘并利用这种因为工具赋能而释放出来的“非线性能力溢出”。

3. 多玩家与主动性 (Multiplayer & Proactive Agent)

随着 Claude Tag 等机制 of proactive agents 的引入，智能体不再局限于“人类发一个 Prompt，智能体动一下”的单向被动模式。智能体开始能够自我唤醒、主动运行，并在多个玩家（人类开发者与其他智能体）之间进行协同，这开启了多智能体主动协作的新浪潮。

4. System Prompt 的最新变化与演进趋势

大模型系统提示词（System Prompt）的设计原则随着模型能力的进化经历了三个阶段的演进：

旧模型阶段（如 Claude 3.5 Sonnet）：最佳实践是“较小的系统提示词、限制工具数量、添加大量的 few-shot 示例和规则约束”。
大模型成熟阶段：演变为“大型系统提示词、多工具”，试图用繁复冗长的规则和 detailed instruction 来控制模型行为。
新一代模型阶段（如 Fable 时代）：最佳实践转变为**“更小的系统提示词，提供 Context（上下文背景）而非 Constraints（刚性约束）”**。因为越聪明的模型越具有想象力和发散思维，如果塞满 rigid few-shot 或写满 “do-not-do-this”，反倒会极大地限制其推理与解决未知问题的能力。

Source: 2026-07-09-xiaohongshu-xhslink-com-o-5QgoCW5c1cG（来源未公开）

Jagged Intelligence（锯齿智能）与 Verifiability

LLM 的能力极度不均，呈现”锯齿形”分布，根源在于 Verifiability（可验证性）：

训练机制：前沿实验室通过强化学习（RL）训练 LLM，RL 环境必须有 reward 信号，而 reward 信号需要可验证的输出
能力峰值在可验证领域：数学、代码——有明确的对错判断，RL 可充分训练
能力粗糙在不可验证领域：空间常识、审美判断——RL 环境难以构建

典型锯齿案例：最先进的 Opus 4.7 能重构10万行代码库、发现零日漏洞，但被问”洗车店在50米外，走路还是开车？“会回答”走路”——因为这类问题不在 RL 训练回路中。

应用含义：

使用 agent 前，先判断所在任务属于哪类 verifiability 域
不在 RL 回路中的任务，需要用户保持更高程度的监督
如需提升特定领域能力，考虑构建该领域的 RL 环境并做 fine-tuning

Source: 2026-07-06-youtube-youtu-be-96jN2OCOfLs-si--p6--F-hghVosCS（来源未公开）

LLMs as Ghosts（非动物智能）

Karpathy 提出一个重要的认知框架：LLM 不是”动物”，而是”鬼魂”（Ghosts）——被统计数据召唤出来的实体：

没有内在动机（Intrinsic Motivation）
没有好奇心（Curiosity）
没有情感驱动——骂它或夸它不会改变其工作质量
由预训练数据的统计规律 + RL 强化的能力峰值共同塑造

实践意义：不要像对待助手一样对待 LLM，要像对待工具一样——理解其能力边界，而非期待其内在动机。

“你可以外包思考，但不能外包理解”

You can outsource your thinking but you can’t outsource your understanding.

这是 Karpathy 认为当前最深刻的洞察之一：

Agent 越来越能代替人完成思考（代码生成、文档撰写、方案规划）
但**理解（Understanding）**仍然是人类的瓶颈
理解是 directing agents 的前提——你必须知道在构建什么、为什么值得做、如何评判方向
随着 agent 做得越多，人类的理解能力反而变得越稀缺、越有价值

这与 learning-methods 中 Karpathy 的学习方法论一脉相承：深度学习、从零手写的目的就是建立真正的理解，而不只是会调用 API。

Agentic Engineer 的核心职责

当前 agent 仍然会犯的典型错误（如 MenuGen 中用邮件地址跨关联 Stripe 和 Google 账户）揭示了 Agentic Engineer 的工作重心：

Spec 与顶层设计：定义准确、详细的规格说明（Spec），让 agent 填充细节
品味与审美（Taste）：agent 生成的代码往往臃肿、有奇怪的抽象——人类审查美感和结构合理性
工程判断（Judgment）：理解底层（如张量的 view 与 storage 区别），虽然不记所有 API 细节
监督与验收：对 agent 输出保持恰当程度的 in-the-loop 监督