原文https://mp.weixin.qq.com/s/_XE1U9_XsmWjA8eSiZw64A一、转变不是工具替换是工作模型的替换很多人理解用 Agent 工作的方式是这样的以前我用 IDE 写代码现在我用 Cursor 或者 Claude 写代码工具换了工作方式没变。Karpathy 的经验告诉我们这个理解是错的。他在 2025 年描述自己工作状态转变的时候说的不是我换了一个更好的编辑器。他说的是他整个工作模型变了——他思考一个任务时的第一个问题从我怎么实现这个变成了我怎么让 Agent 可靠地完成这个。这两个问题需要完全不同的技能。第一个问题需要的是编程能力、算法知识、对框架的熟悉度。第二个问题需要的是任务分解能力、上下文设计能力、对 Agent 失败模式的判断、对结果的评估能力。后者不是前者的升级版是一套不同的技能。Karpathy 的转变之所以值得研究不是因为他变懒了是因为他在这个转变里形成了一套可以被描述的工作方法。这篇文章试图把这套方法还原成普通工程师可以操作的步骤。二、先丢掉三个旧习惯转变首先不是建立新习惯而是识别并丢掉三个在 Agent 工作模式里会造成麻烦的旧习惯。旧习惯一拿到任务就开始写或者让 Agent 开始写传统编程的工作流是理解需求 → 开始写代码 → 遇到问题再回头调整。这个流程在 Agent 工作模式里是有代价的Agent 一旦开始执行它会基于初始的理解一路往前走。如果初始理解有偏差Agent 不会自己停下来重新想它会在错误的方向上越走越远用你一路花出去的 Token 和时间给你一个需要从头来过的结果。Karpathy 的替代习惯在 Agent 开始执行之前先把任务想清楚。不是想我怎么实现是想Agent 做这件事最关键的判断点在哪里在那个点上它可能需要哪些信息。旧习惯二出了问题就改 PromptAgent 给出了一个不对的结果第一反应是我的 Prompt 哪里没写好然后反复调整 Prompt期待找到那个魔法公式。正如上一篇讲的Prompt 是表层上下文是根本。反复调 Prompt 而不检查上下文是在用错误的工具解决问题——有时候碰巧有效但不可靠也不可复现。Karpathy 的替代习惯Agent 出错第一步不是改 Prompt是问它在出错的那个步骤上下文里有什么缺少什么。找到信息缺口解决信息问题而不是解决 Prompt 措辞问题。旧习惯三相信 Agent 的输出除非明显出错代码运行不报错、格式看起来对、内容读起来通顺——所以就直接用了。这个习惯在传统代码里勉强说得过去代码运行正确通常意味着逻辑正确但在 Agent 输出里是危险的。Agent 非常擅长生成看起来对的东西——格式正确、语气合适、逻辑流畅但内容在关键细节上是错的。这种错误不报警不抛异常安静地存在于输出里等着你或者你的用户踩到它。Karpathy 的替代习惯建立验证流程。不是除非明显出错就相信是在关键节点主动验证。验证不是把所有输出都读一遍是设计检查点哪些步骤的输出是高风险的哪些是低风险的对高风险的步骤用什么方式验证。三、建立四个新判断丢掉旧习惯之后需要建立四个在 Agent 工作模式里最关键的新判断能力。判断一这个任务适合交给 Agent 吗不是所有任务都适合 Agent。Karpathy 自己的经验是他会在把任务交给 Agent 之前先做一个快速判断适合 Agent 的任务特征步骤清晰可以分解每一步有明确的完成标准结果可以验证你知道对是什么样子即使出错代价是可控的可以回滚可以重做不会造成不可逆的影响任务重复度高你以前做过类似的知道坑在哪里不适合 Agent 的任务特征需要大量隐性判断很难显式描述什么是好的结果出错代价高一旦 Agent 做错修复成本远超重做成本高度依赖当前状态和实时信息而这些信息你没有办法系统性地放进上下文任务的边界不清楚你自己也不确定最终要什么这个判断不需要精确但需要成为一个反射动作。拿到任务第一步先做这个评估。判断二任务的关键节点在哪里一个复杂任务里不是所有步骤同等重要。有些步骤出错Agent 可以自己恢复有些步骤出错整个任务就跑偏了。Karpathy 的做法是在任务开始前识别出 2-3 个关键节点——那些如果判断错误会导致后续所有步骤都错的地方。然后在这些节点上要么提前在上下文里提供更充分的信息要么设置人工确认点Agent 执行到这里先暂停等你确认再继续。判断三验证点应该设在哪里不是输出来了之后全部检查是在任务执行过程中在哪些点上插入验证。对于一个十步的 Agent 任务如果你在第十步才看结果发现第三步就跑偏了你浪费了七步的 Token 和时间还得从头来过。更有效的方式在第三步之后设一个检查点确认 Agent 的理解和你的预期是对的然后再继续。这个检查点不需要很多——通常一个复杂任务里有 2-3 个就够了。关键是把它设在如果这里错了后面全白做的位置上。判断四这个输出我需要验证什么不是把所有输出都精读一遍是知道在这个输出里什么地方最可能出错我需要重点检查什么。对于代码输出不只看代码能不能跑还要看逻辑是否覆盖了边缘情况是否处理了错误是否和你的系统其他部分兼容。对于文本输出不只看格式和语气还要核对关键数据和判断特别是那些 Agent 只能从上下文里推断而不是直接拿到的信息。对于决策输出Agent 给出了一个建议或者方案检查它的推理链不只是结论还要看它是怎么得出这个结论的推理链里有没有你知道是错的前提。四、一个具体的工作流把上面的判断整合成一个可以操作的工作流。这不是 Karpathy 公开说过的某个固定流程——是基于他描述的工作方式整合出来的一个实践框架。Step 0任务评估2 分钟└── 这个任务适合 Agent 吗└── 如果适合关键节点在哪里Step 1上下文准备5-15 分钟取决于任务复杂度└── Agent 做出正确判断最少需要知道什么└── 目前的上下文里有多少└── 缺少的部分怎么补充└── 我的指令里有没有潜在矛盾Step 2设置检查点1 分钟└── 在哪 2-3 个步骤上需要人工确认└── 在这些步骤上我期待看到什么样的中间结果Step 3让 Agent 执行└── 在检查点上暂停确认方向└── 确认后继续Step 4验证输出└── 这个输出里什么地方最可能出错└── 针对性地检查这些地方└── 不是精读是有重点地核查Step 5记录失败模式长期积累└── 这次 Agent 在哪里出了问题└── 是信息缺口、信息过载、还是指令矛盾└── 下次同类任务上下文怎么改Step 5 是最容易被跳过、但长期价值最大的一步。Karpathy 有一个习惯他会记录 Agent 出错的模式而不只是修复单次的错误。因为同一类任务里Agent 的失败模式往往是重复的——如果你理解了失败的原因你可以在上下文设计层面修复它让同类任务的成功率系统性地提升。五、关于什么时候该自己动手这是最容易被忽略、但 Karpathy 讲得最清楚的一点编排 Agent 不是把所有事情都交出去。他自己的工作方式里有一些事情他始终自己做定义问题任务的真正目标是什么成功的标准是什么。这是 Agent 无法替代你做的——因为它不知道你的上下文、你的约束、你的优先级。最终判断特别是那些涉及方向性选择的决策。Agent 可以给你选项和分析但选哪个通常应该是你来做。异常处理当 Agent 遇到它显然处理不了的情况或者它的输出你有明确的直觉感觉不对但说不清楚哪里不对——这时候不要强行让 Agent 继续换成自己处理或者重新设计任务。这三件事不是因为 Agent 能力不够才自己做是因为这三件事本来就是判断者的工作不是执行者的工作。而你在 Agent 工作模式里扮演的角色是判断者。六、第一周怎么开始如果你现在想开始这个转变不需要一次性改变所有工作习惯。Karpathy 自己的转变也是渐进的。一个相对稳妥的第一周方案第一天用 Agent 做一件你以前自己做的重复性任务不是最重要的任务是你做过很多次、知道对是什么样子的任务。这样你能快速判断 Agent 的输出是否可信。第二天有意识地在任务开始前准备上下文不是想我的 Prompt 怎么写是想Agent 需要知道什么才能做对这件事。把缺少的信息主动补充进去。第三天在一个任务里设置一个检查点让 Agent 执行到某个中间步骤停下来你确认方向对了再继续。感受一下这个暂停确认的节奏。第四天认真做一次验证不是扫一眼是针对最可能出错的地方做有重点的核查。记录下你发现了什么。第五天回顾这一周Agent 在哪里出了问题是信息缺口信息过载还是指令矛盾下周同类任务你会改什么五天之后你不会完成转变但你会对编排 Agent 和写代码有什么不同有一个具身的感受——这个感受比读任何文章都更有价值。