长上下文 Agent 化：Karpathy 百万 Token 委托实验启示

上周末 Andrej Karpathy 发的一个 demo 一直萦绕在我脑海中。他给 Opus 5 提供了百万 token 的上下文和《指环王》的第一段文字，要求用 Three.js 对场景进行程序化 3D 渲染。模型独自工作了约两个小时，写了 5500 行代码，自行协调了多边形放置、相机路径和动画。总成本约 10 美元。结果比描述起来更快——直接看视频就知道了。

大多数反应把它解读为「画一只鹈鹕 SVG」基准测试的又一步。但我看来有更大的变化。变化的不是模型的美术能力，而是——委托的最小单位。

委托的最小单位变了

此前我们交付给 Agent 的工作都是按 prompt 大小来切块的。一个函数、一个 bug、一个文件。再大的任务就自行分解。理由很简单：小上下文窗口下，长任务的前期内容会滑出视野，连贯性也随之丧失。

百万 token 的上下文消除了这个前提。模型在两小时会话中编写和尝试的所有内容都保持在视野之内。当操作台足够大时，没有理由再按切片交付工作。委托从任务级别上升到了会话级别。

这就是函数调用和工作会话的区别。前者需要我们分解和监督，后者只需交付材料和意图，然后接收结果。Karpathy 的全部贡献就是选择了一段文字，然后两小时后看输出。

Builder 的工作重心转移了

当执行成本是 10 美元和两小时，执行就不再是瓶颈。剩下两件事值得关注。

输入端：简报。 上下文里放什么。Karpathy 的输入是一段文字，但选择它本身就是设计行为。转化到我们的工作，就是决定把哪些规格文档、品牌指南、参考资料或代码库完整放进去——以及什么排除在外。

输出端：判断。 用什么标准来验收结果？逐行审查 5500 行代码不符合会话级委托的做法。相反，你在运行前就定义好「完成」的标准，然后用这个标准来评判输出。

长期以来，分解任务并监督过程是高级技能。它的价值正在下降；而选择材料和设定标准正在上升。这是个令人不适的转变，但方向看起来很清晰。

这能走多远

公正地看，这个 demo 没有证明三件事：没有维护、没有正确性约束、没有用户。粗糙的渲染影响的是体验，不伤害任何人。

所以判断标准只有一条：输出是用于观看，还是用于操作？模型、原型、探索和 demo 可以出错。从规格文档一步到位生成 demo 可能已经更快了。运行的软件——错误会触达用户、明天还需要维护——仍然是另一回事。这个 demo 没有表明两小时自主运行的输出可以直接用于生产。

与其赞叹，不如设计一个实验。挑选你所在领域的某件事，符合同样模式：完整材料输入，半天自主完成。

• 输入完整的产品规格和品牌指南，要求一次性生成 demo
• 输入整个代码库，要求一份迁移草案
• 输入所有文档，要求一份新手指南

两个条件就足够了：输出所在的地方容许出错，以及提前设定成本上限。十到二十美元就能告诉你——委托的最小单位是否也在你的工作中发生了改变。