Codex App作为目前最为强大的 AI Agent产品之一

说真的，前几天有个朋友问我，你有没有觉得现在的AI工具都挺鸡肋的，问啥都能聊两句，但真让它干点活就抓瞎了。

我懂他意思。

ChatGPT也好、Claude也好，用起来确实是方便，但你有没有发现，它们永远只能「告诉你怎么做」，而不会「替你去做」。让你写个文案，它能给你扔出来，但帮你把文案存到本地、命名好、再发到对应的平台？不好意思，这得你自己来。

怎么说呢，这种割裂感其实挺难受的。就好像你雇了个参谋，能力很强，但永远只动嘴不动手。

直到我开始用 Codex App。

坦白讲，最开始我没当回事，不就是个桌面应用吗，能有多神？但用了一段时间之后，我必须得说——这玩意是真的不一样。

怎么说呢，它不是来回答你问题的，它是来帮你把事情办成的。

这篇文章，我不打算写成说明书给你念功能列表。我想用最直白的大白话跟你聊聊，Codex App 到底是什么、能做什么、以及怎么用好它。

看完之后，你对AI Agent这件事的认知，可能会有一个质的飞跃。

一、Codex App 是什么？

先说个背景。Codex App 是 OpenAI 推出的 AI Agent 桌面应用。注意，不是网页版，不是浏览器插件，是一个真真切切装在你电脑里的桌面程序。

这里有个特别关键的认知转换。

过去的AI，比如ChatGPT，它本质上是一个「问答机器」。你问，它答，答案停留在聊天框里，你得自己拿走、自己执行。AI扮演的角色，是顾问。

但 Codex App 不一样。它是一个能「坐在你电脑前帮你干活」的员工。你给它一个目标，它自己拆解、自己执行、自己交付结果——中间几乎不需要你插手。

比如，你跟它说「帮我看看这个项目里哪些代码可以优化」，它会直接打开你的文件夹，读取代码文件，分析，生成改进建议，甚至直接帮你改掉。全程不需要你手动上传文件，不需要你复制粘贴，它就像一个真实的人类员工一样在操作你的电脑。

这种感觉，我跟你说，第一次体验的时候还是挺震撼的。

它具体能做到的事情，我大概列一下：

深度读写本地文件。 它可以直接查看、修改、整理你电脑里的文件夹与项目目录。绑定了项目之后，它知道你项目里有什么文件，结构是怎样的，可以直接读写。

联网搜索实时信息。 它有内置的全功能浏览器，不需要切出应用，就能在 App 内部搜索、浏览、汇总网页信息。

像人一样操控软件。 它拥有视觉感知能力，能实时识别复杂的软件界面，操作电脑上的各类 App。

生成多维工作成果。 自动生成文档、图片、网页、代码等各类结果，并支持实时预览。

无缝连接外部工具。 通过插件直接连接你的 Gmail 邮箱、Notion 笔记、Google Drive 网盘等应用。

后台自动化。 设置好定时任务后，可以在电脑后台自动帮你执行重复性工作。

你看，一个能做这么多事情的东西，它叫Agent，中文翻译过来就是「代理」或者「智能体」。简单理解，就是一个被AI驱动、可以自主行动的数字员工。

二、它和 ChatGPT 到底有什么区别？

其实这个问题可以用一句话回答——

ChatGPT住在云端，Codex住在你的电脑里。ChatGPT给你答案，Codex帮你办事。

但光说这句话可能还不够清晰，我展开讲讲。

第一个区别：本地化。

ChatGPT是云端应用，你想让它处理文件，必须手动上传，下载结果也得自己来。但Codex直接就在你本地运行，可以直接读写本地文件，不存在上传下载这个步骤。

打个比方，ChatGPT像是租了个服务器，你得把文件上传到那个服务器上去处理。Codex呢，就是在你家开了个办公室，所有事情就地解决。

第二个区别：执行能力。

这是最核心的区别。

ChatGPT能给你一个完美的方案，但方案的执行必须由你来完成。Codex不一样，它能直接把事情办了——写代码、保存代码、部署上线，全部自主完成，你只需要告诉它你想要什么。

所以我更愿意这么理解：ChatGPT是你最好的军师，而Codex是你最拼命的员工。军师给你出主意，员工帮你干活。

那有人可能会说，员工干活出错了怎么办？这个确实是需要考虑的问题，所以后面我会讲到它的权限控制系统，这是一个很聪明的设计。

三、先别急，在开始之前——安装这件事

安装其实非常简单，没啥坑，但我还是简单说两句，省得有人卡在第一步。

打开Codex官网（ https://developers.openai.com/codex/app ）进行下载，它支持 Mac 和 Windows，根据自己的电脑选对应的安装包就行。

登录账号这里，用你的 ChatGPT 账号直接登录就行。免费版有少量额度，但坦率的讲，如果你真的想认真用起来，建议还是以 Plus 会员为起步——免费额度大概几次对话就用完了，不够玩的。

四、核心功能解析——界面和布局

进入 Codex App 之后，你看到的主界面大概长这样，主要分为两个区域：左侧导航栏和中间工作区。

[ ]

先说左侧导航栏，这里是你和 Codex 交互的核心入口。

顶部栏是两个重要功能：Plugins 和 Automations。Plugins（插件）里包括 plugin 和 skill，主要用于扩展 Codex 的能力边界。Automations（自动化）用于设置定时任务。

中间对话区分为两个部分：项目区域和普通对话区域。简单说，项目对应本地的一个文件夹，适合有明确目标的任务；普通对话不绑定文件夹，适合零散的问答和临时需求。

底部设置用于全局基础配置，这个后面会细说。

中间的工作区就是你跟 Codex 聊天的主战场了，所有任务都从这里发起。

五、核心功能解析——项目和对话

这里必须得说清楚一件事，因为很多人刚开始用的时候会困惑。

Codex 有两种开启会话的方式：项目和普通对话，它们本质上是不同的。

项目：绑定本地文件夹的会话。

当你创建一个项目的时候，你需要指定一个本地文件夹作为这个项目的「工作目录」。之后 Codex 在这个项目里产生的所有对话，都可以直接读写这个文件夹里的文件。

所以，项目更适合有明确目标的任务。比如你要开发一个网站，你建一个项目，绑定你的项目文件夹，Codex 就能直接帮你读写代码文件、改配置、跑测试——你告诉它你想做什么，剩下的它来。

开启方式很简单，点击左侧栏 projects 旁边的「+」图标，支持新建文件夹和选择现有文件夹两种方式。

[ ]

这里有个使用习惯的建议，来自于我自己的踩坑经验。

保持会话结构清晰非常重要，具体来说主要是两点：

• 本地文件夹清晰，不同文件夹对应不同主题。
• 同个项目下一个会话只推进一个方向。比如你要开发一个网站，不同的功能模块建议各开一个会话，不要混在一起。执行效果更好，也方便后期回溯查看。

你想想看，如果你一个会话里又是首页功能又是支付模块又是后台管理，聊到后面自己都分不清哪些改动对应哪个需求了，那叫一个乱。

普通对话：不绑定本地文件夹。

普通对话适合那些不需要操作文件的临时需求，比如查个资料、问个问题、让 Codex 帮你写一段文案之类的。没有文件夹绑定的负担，随用随开，用完即抛。

六、核心功能解析——Plugins 和 Skills

这是 Codex 扩展能力的关键功能。

点击左侧栏的 Plugins，你会看到两个概念：Plugins 和 Skills。

Plugins 是给 Codex 接外部工具的安装包。

简单理解，就是让 Codex 能够操控其他应用的接口。它本质上是一套工具连接器，让 Codex 有了「操作其他 App」的能力。

举例来说：

• Gmail 插件：让 Codex 可以读取和管理你的邮件。
• Google Drive 插件：让 Codex 可以读取和编辑你的 Docs、Sheets、Slides。
• Vercel 插件：让 Codex 可以直接将你的项目部署上线。

[ ]

当你安装了对应的插件之后，你就可以在对话里直接让 Codex 去操作这些服务了，比如「帮我把最近的邮件按重要程度排个序」「把这个项目部署到 Vercel 上」，它真的会去执行，不需要你手动操作。

Skills 是可复用的任务指令。

如果说 Plugins 是帮 Codex 装上了手和脚，那 Skills 就是教它遇到某类任务时该怎么做。它是可复用的指令模板，Codex 学会之后，遇到类似任务就能自动调用。

比如内置的 Image Gen skill，就是让 Codex 直接具备生成或编辑图片的能力。你不需要每次都详细描述图片生成流程，告诉它「帮我生成一张图」就够了，它知道该怎么做。

[ ]

七、核心功能解析——自动化

这个功能我觉得是被很多人低估了的。

自动化让 Codex 按照你设定的时间在后台自动执行任务。它特别适合那些需要定期执行的重复性工作——比如每天早上的邮箱汇总、定时信息监控、股票日报生成，这些事情你以前得每天手动去做，现在设置一次就行了。

设置方式巨简单，你甚至不需要去翻什么文档或者教程，直接用自然语言跟 Codex 说就行。

比如你可以跟它说：

新建一个自动化，每天早上 9 点查看我的 Gmail 邮箱，把重要邮件总结到目前的聊天会话里。

它就会自己把这件事记下来，到点自动执行。你人不在电脑前也没事，它在后台跑，跑完了通知你。

[ ]

这个功能对于做自媒体、做运营的人来说其实特别实用。比如你可以设置一个自动化，每天下午 5 点自动抓取你关注的几百个热点新闻，汇总成一份简报发给你。每天省下来二三十分钟是有的。

八、核心功能解析——聊天区的那些功能按钮

Codex 在对话输入这块做了很多细节设计，很多人第一次用的时候可能直接忽略了，这里我帮你们过一遍最重要的几个。

1. Plan Mode：先想清楚再动手

这个功能简单说，就是让 Codex 先给你制定一个详细的执行方案，等你确认之后再去执行。

适合任务较复杂的情况下开启。比如一个任务涉及多个文件的改动，或者你需求本身还没完全想清楚，从零开发某个功能的时候——先开个 Plan Mode 让 Codex 给你画个路线图，确认没问题了再让它动手，避免走弯路。

[ ]

怎么用呢？开启之后，Codex 会先输出它的执行计划，列出每一步要做什么，然后等你点确认，才会真正开始执行。这个交互设计其实挺聪明的，它解决了一个根本矛盾——AI 自动执行效率高，但风险也高；人审核确认安全，但频繁打断又影响效率。Plan Mode 就在两者之间找了个平衡。

2. 权限模式：决定它能走多远

每次发起对话前，在输入框左下角可以选择权限级别，共三档。我一个个说：

Default 默认模式： 仅限当前工作区，Codex 如果需要越界（比如访问网络或工作区外的文件），会暂停并询问你确认。

Auto-review： 边界与默认模式相同，但越界请求由 AI 自动审查决策，不需要你手动确认，不打断工作流。这个模式我日常用得最多。

Full access： 移除所有边界限制，Codex 可以访问任意文件和网络，直接执行，不做任何中断。

[ ]

日常使用的话，我推荐选 Auto-review。怎么说呢，安全相对可控，也不会频繁被打断影响进度。如果你刚开始用，心里没底，用 Default 也没问题，就是可能会多一些确认弹窗。

3. 模型和推理程度选择

Codex 支持不同模型和推理程度的选择，这个大家应该比较熟悉了。

推荐的用法是：日常任务用 GPT 5.5 Medium，复杂任务用 GPT 5.5 Extra High。这个不用多解释，复杂任务需要更深度推理的时候就调高，简单任务没必要浪费额度。

[ ]

4. 输入框快捷符号

这个是很多人会忽略但非常好用的功能。在对话输入框里，有三个符号可以快速触发不同功能：

「@」符号： 支持选择调用已安装的插件，或者引用具体文件作为上下文。输入 @ 会弹出一个列表，直接选就行，不需要你记住插件的名字。

[ ]

「/」符号： 唤出命令菜单，可执行内置命令。你已经安装的 Skills 也会出现在这个列表里。相当于一个快捷启动器。

[ ]

「$」符号： 显式调用某个 Skill。比如输入 $imagegen 就可以直接触发图片生成功能。这是最直接的方式。

[ ]

这三个符号用熟练了之后，交互效率会高很多。尤其是 @ 和 /，我基本每次对话都会用。

九、推荐设置——正式使用前必做的配置

好了，前面都在讲功能和概念，接下来是实战部分。

我建议你在正式开始使用之前，把下面这4个基础设置配好，配好之后用起来才会顺。

点击左下角的设置图标进入配置页面。

第一，权限设置里勾选 Auto-review 和 Full access。

这个主要是为了方便你在不同对话里随时调整权限模式。提前勾选好，后面切换起来不用再回来改设置。

[ ]

第二，开启「防止电脑在 Codex 运行时睡眠」选项。

这个太重要了。如果你用的是笔记本电脑，或者电脑设置了息屏休眠，当 Codex 正在执行一个需要一定时间的任务时，如果电脑突然睡眠了，任务就会被中断。

开启这个选项之后，Codex 运行期间你的电脑会保持唤醒状态，不会因为超时而打断任务。

[ ]

第三，配置全局指令（Agents.md）。

在个性化设置的自定义指令里，你可以写一段你希望 Codex 长期遵守的背景信息和规则。相当于给它一个「永久记忆」，让它每次对话的时候都知道你是谁、你有什么偏好、你应该怎么工作。

建议的内容包括：

• 你的身份与偏好： 比如你的日常工作角色、常用的软件工具。
• 输出内容的格式要求： 比如「回答一律使用中文」「文风保持简洁克制」。
• 行事准则： 比如「避免过度设计，只做必要改动」。

[ ]

这个东西配置好之后，你的 Codex 会变得特别懂你。用得越久，它对你的理解就越深，后面越来越顺手。

第四，开启记忆功能。

在个性化设置里找到记忆功能开关，开启它。开启之后 Codex 会自动从对话中学习你的偏好，在使用过程中变得越来越懂你。

[ ]

这个功能某种程度上有点像你在训练一个专属的AI助手。给它时间让它了解你，它会用得越来越顺手。

十、超级实用技巧推荐

好了，基础部分说完了，下面是一些真正能让你效率翻倍的技巧。

技巧一：学会用好 Plan Mode

我前面已经提过 Plan Mode，但这里还是要再说一遍，因为它真的太重要了。

任务越复杂，越值得先开 Plan Mode 确认方案再执行。具体来说，这些场景特别适合：

• 任务涉及多个文件的改动
• 需求本身还没想清楚
• 从零开发某个功能或 Skill

[ ]

你想想看，如果你让 Codex 直接开干，干到一半发现方向跑偏了，你还得让它停下来、调整、再重新开始——这其实比一开始就用 Plan Mode 花的时间更多。

Plan Mode 的本质是一个「决策缓冲」，它帮你省下的不是几分钟，而是一次方向性错误的返工时间。

技巧二：多任务并行执行

Codex 支持同时开启多个任务，甚至可以跨项目并行推进。每个对话的状态都会在侧边栏实时显示，任务完成后会出现蓝点提示。

[ ]

这个怎么用呢？比如你同时在跑一个网站开发项目和一个数据分析项目，你可以开两个窗口各自跑，中间不需要等待，它们各自独立执行。

甚至同一个项目里，你也可以同时开多个会话分别处理不同的功能模块——前面我说建议一个会话只推进一个方向，但没说只能开一个会话啊，多个会话同时跑，效率自然就上去了。

技巧三：4个宝藏命令

Codex 内置了几个特别有意思的命令，用好它们体验会完全不一样。

/side——侧边对话。

在项目级会话的主线程正在运行时，开启一个临时的侧边对话，用于快速提问或确认某个细节。不需要中断主线程的进度，随时开随时关。

[ ]

比如主线程正在帮你开发一个功能模块，突然你想确认一下之前某个函数的逻辑细节，直接开一个 /side 问一句就行，问完关掉，主线程继续跑，两不耽误。

/pet——桌面宠物。

这个是我最喜欢的功能之一。在电脑屏幕上开启一个桌面宠物，它会实时显示当前任务的执行状态，让你在做其他事情的同时也能随时掌握 Codex 的进展。

[ ]

怎么说呢，这个功能虽然听起来有点可爱得过分了，但用起来是真的方便。尤其是你在 Codex 跑一个长任务的时候，你不需要一直盯着对话窗口，宠物会告诉你进度。

/status——状态查询。

在会话里随时查询你的上下文使用情况和额度消耗情况。帮你搞清楚当前会话消耗了多少、还剩多少，不至于跑到一半发现额度用完了。

[ ]

/goal——目标驱动。

设定一个明确的目标，让 Codex 自己朝着目标不断努力。这是最强大的命令之一，它本质上把 Codex 从一个「听话的工具」变成了一个「有自主判断能力的代理」。

一个好的 /goal 提示词应该包含这些要素：

/goal 达成 **<你希望 Codex="" 最终完成的目标="">**，并通过 **<具体可验证的证据>** 来确认结果有效，同时保持 **<必须遵守的限制条件>** 不被破坏。只能使用 **<允许使用的输入、工具、文件范围或操作边界>**。在每一轮迭代之间，Codex 需要根据 **<如何判断下一步最优行动>** 来选择下一步。如果遇到阻塞，或者已经没有有效路径可以继续尝试，Codex 必须停止，并报告 **<已经尝试过的方法、已获得的证据、当前阻塞点，以及还需要什么信息或权限才能继续推进>**。

你看，这套框架其实就是一套完整的 Agent 运行逻辑。给它目标，给它边界，给它判断标准，然后放手让它干。

技巧四：Steer 插入机制

这个技巧解决了一个很实际的痛点：Codex 正在执行任务的时候，你突然想加个指令或者微调一下需求，怎么办？

普通做法是等它跑完再说，但如果有即时需求呢？输入新指令后点击 Steer（或者 Mac 快捷键 Cmd + Enter），指令会立即插入当前任务的上下文，而无需中断正在进行的工作。

[ ]

这个特别适合运行途中发现需要微调的场景。比如 Codex 正在帮你整理一个文档，你突然想加一个章节，直接 Steer 插入，它就会把这个需求合并到当前的执行计划里，灵活调整，而不是从头开始。

写在最后

好了，基础部分到这里就差不多了。

怎么说呢，Codex App 这东西，你说它是工具，我觉得不太准确。它更像是你电脑里的一个超级员工——能读文件、能上网、能操控软件、能自动干活。

它不是一个在云端飘着的聊天机器人，而是一个真真切切坐在你电脑前帮你工作的数字助手。

这篇文章的目的是帮你建立对 Codex 的基本认知，把界面、功能、设置、技巧这些框架性的东西梳理清楚。看完之后你应该能顺利上手用它了。

但说实话，这只是开始。

Agent 这个方向的东西，入门靠的是教程，深入靠的是自己用。不同的使用场景、工作流程、需求组合，每个人的玩法都不一样。

这篇文章是一个起点。

我自己用了这段时间下来最大的感受是——AI Agent 这件事真的在从「玩具」变成「工具」了。以前我们说AI能做什么，好像都是在说AI的「智力」部分，但现在Codex展示的是AI的「行动力」——它不只帮你想，它还帮你做。

这个转变，我觉得是接下来几年里最值得关注的事情之一。

好了，以上就是今天的分享。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

/ 作者：卡兹克 / 投稿或爆料，请联系邮箱：wzglyay@virxact.com

Karpathy 去 Anthropic 这件事，我现在更愿意把它看成一个人回到现场，而不是一次普通跳槽。

如果只从公司关系看，这当然很有戏剧性。

OpenAI founding team 成员，Tesla Autopilot 早期负责人，去了 OpenAI 现在最难缠的竞争对手。这个叙事框架太容易接受了，接受完发现什么都没想。你脑子里多了一个「啊这」，但它没有给你任何新的坐标。

怎么说呢，这其实是科技媒体最擅长的一种讲法。把人事变动翻译成「谁挖了谁」，把技术领袖的流动简化成「谁赢了谁」。它不一定是错的，但它一定太浅了。浅到把一个本来很有层次的事件，拍扁成一张新闻卡片。

所以我今天想认真聊聊这件事，不聊新闻，聊背后的那个判断。

Karpathy 过去几年其实一直站在两个身份之间。

一个身份是 frontier researcher。他知道最前沿的大模型训练长什么样，知道系统工程、数据管道和组织到底是怎么回事。这些东西不是看书能看会的，得在那里面泡过，犯过错，复现过别人的实验，才能真正理解边在哪。

另一个身份是 public educator。他非常在意怎么把复杂的东西讲清楚，怎么让更多人真正理解模型，而不是只会复述几个新名词。他那条著名的「软件 3.0」那条线，从 code 变成 context，人通过 prompt、tools、memory、instructions 去编程一个 LLM——这整套框架，不是写论文能写出来的，是他从实战里抽出来，然后用一种任何人能看懂的方式讲出来的。

两个身份都很好。但坦率的讲，这两个身份之间有张力。

当老师讲久了，会离训练场越来越远。这不是说讲课会让人变蠢，恰恰相反，讲课需要你把东西想得非常清楚才能输出。但训练场需要的那种「感知」，是在实验室里泡出来的——数据灌进去跑崩了你知道是哪里出了问题，实验结果出来你能闻出味道不对。这些东西很难通过讲课传递，因为它本身就很难描述。

AI 这一轮变化又太快了。

2024 年大家还在争论模型能力边界，GPT-4 之后谁追上了谁。2025 年开始集中讨论 agent，能不能自动化、多自主、怎么规划。2026 年，一个更核心的问题已经冒出来了：模型能不能参与训练下一个模型？

这个问题听起来有点绕，但其实很直接。以前训练模型靠人，靠数据，靠 GPU，靠算法工程师的经验。现在大家开始想，如果把模型放进去，让它帮研究员读实验日志、整理数据、提假设、跑 ablation——它能不能把研究流程本身加速？

站在外面当然能观察。网上每天都有新的论文解读、新出来的 benchmark 排名、各家公司的发布动态。看多了你会有一种错觉，觉得自己跟上了。但很难知道哪些变化是真拐点，哪些只是 demo 很漂亮，哪些是工程上已经跑通了但还没发出来的。

Karpathy 肯定比我更清楚这个距离感有多大。

所以他官宣里最关键的我觉得不是「加入 Anthropic」这几个字，而是那句「get back to R&D」。

这句话很平。太平了，平到如果不是认真想一下，很容易就滑过去了。

他不是去拿一个新 title 的。Karpathy 这个量级的人，不缺 title。他也不是去给 Claude 做一层漂亮外壳的，Anthropic 不缺做产品的工程师。

他是在回到一个只有在场内才能看清楚的位置。

这个说法我很喜欢。它把一次人事变动还原成了一个人对自己状态的诚实判断。几年在外面讲课、做项目、写内容，他一定非常清楚自己离训练场有多远。不是说远了就不好，但当你意识到自己已经够远的时候，回到现场的冲动就变得很具体了。

Anthropic 给他的，也不是一个普通研究岗。

公开信息里最重要的细节是这个：他进入 pre-training team，并组一个小团队，用 Claude 加速 pre-training research。

这句话稍微停一下。进去做 pre-training 本身就已经很有意味了。pre-training 就是预训练，模型最底层的能力在这里被塑造。这个方向不是消费级产品，不是评测榜单，不是某个 killer app，它的核心是在回答一个问题：下一代模型能不能更好。

然后有意思的来了——他要做的不是 Claude 的功能，不是让 Claude 长得更像某个应用场景，而是用 Claude 加速 pre-training research。换句话说，他去做的不是 Claude for people，而是 Claude for Claude。

这个表述听起来像一个梗。但它其实是 frontier lab 下一阶段竞争的核心问题。

GPU 当然重要，数据当然重要，算法当然重要，infra 当然重要。但当所有大公司都在堆这些东西的时候——当你有足够的 H100、有足够多的数据、有一套基本合理的算法——另一个差异会变得越来越关键：

谁能更快把一个模糊 hypothesis 变成可跑实验。

谁能更快读懂训练日志里的异常信号。

谁能更快找到失败实验之间的共同模式。

谁能更快把研究员的判断沉淀成下一轮实验的参数。

这些事情过去靠什么？靠研究员本人，靠资深工程师，靠内部工具，靠年复一年的经验积累。现在的问题变成：Claude 能不能参与进去？

注意，这里说的不是让 Claude 写几段脚本、生成一些代码、做个总结报告就完了。它说的是让 Claude 成为一个研究流程里的工作单元：整理实验日志，追踪数据变化，读取训练 pipeline，读懂 eval 结果，提出 ablation 假设，把不同实验之间的关系串起来。

这不是在说 AI 替代研究员。这是一个增强逻辑：一个研究员加一个能理解研究语境的 Claude，产出高于一个研究员单独工作。

如果这条路径跑通了——我是说如果，真的跑通了，不是 demo 跑通了——Anthropic 得到的就不是一个更会写代码的 Claude，而是一个更会参与 Claude 诞生过程的 Claude。

这才是 Karpathy 适合去的地方。

你想想看，这件事反过来还帮我们理解了 Karpathy 过去几年一直在讲的那套话。

Software 3.0：软件正在从 code 变成 context，人通过 prompt、tools、memory、instructions 去编程一个 LLM。这套框架他讲了挺久，很多做 AI 应用的人都在引用。

但把这套话放回 pre-training，就会更有意思。

如果 Software 3.0 的意思是「人通过 context 编程模型」，那么未来训练模型的过程本身，是不是也会变成 Software 3.0 的一部分？

研究员提供的 hypothesis 是 context。实验结果是 context。数据清洗的标准是 context。失败的教训是 context。如果模型能读懂这些 context，并把它们组织成下一轮实验的基础——那人和模型共同训练模型这件事，就不是一个遥远的概念，而是一个正在发生的转换。

Karpathy 过去几年一直在把这件事讲给别人听。现在他有机会把自己讲的东西做成现实。

这也解释了 Anthropic 这家公司接下来可能会怎么走。

它不一定是最会讲消费级叙事的公司。OpenAI 更像在把 ChatGPT 推成默认入口，每个月都有新功能，让普通用户感受到 AI 的存在。Google 更像在押 multimodal output 和生成式 UI，做的是让 AI 的输出更好看、更即时、更有感官冲击力。

Anthropic 的长期气质不是这个方向。它更像另一条线：让模型稳定进入人的工作上下文，理解工具边界，按 spec 工作，留下可追踪的结果。

你想想 Claude Code，想想 Artifacts，想想 MCP，想想项目指令，想想 sub agents。

这些东西单看都是功能。Claude Code 是一个代码工具，Artifacts 是一个展示格式，MCP 是一个协议，项目指令是一个配置方式，sub agents 是一个组织结构。你可以把它们一个一个单独拿出来说，没什么了不起的。

但连起来看，它们其实是在回答同一个问题：怎样让一个模型真正成为工作系统的一部分？

不是聊天框里的玩具，而是能在你的上下文里理解你的需求、调用你的工具、按你的标准输出、留下你能追溯的结果。

这和 Karpathy 的世界观能接上。他一直在讲 AI 怎么从「被问问题的工具」变成「参与工作的伙伴」。Anthropic 这几年做的产品，底层逻辑其实就在往这个方向走。Claude Code 不是一个炫技的项目，它代表的是一种判断：模型的价值不只是回答问题，而是在工作流程里持续存在。

还有一条线我觉得也值得拉出来说说。

Karpathy 5 月 12 日发的那条推文，关于 HTML output 的那条。他当时在说的是：人更喜欢用 audio 输入，但 AI 更适合用 vision 输出。输出会从 raw text 到 markdown，到 HTML，再往 video 和 interactive simulation 走。

表面看是在讲输出格式。但我更愿意把它理解成在讲 interface——人和 AI 之间的接口正在变化。

以前我们把 AI 当聊天框，text 输入 text 输出就够了。后来我们把 AI 当工具，markdown、代码、表格开始重要。再往后，如果 AI 要进入真实工作环境，它必须同时理解输入端的 context，和输出端的可交互表达。

所以那条推文和这次加入 Anthropic 能连起来看。前者是在说 interface 的演进，后者是一个人去了最执着于 context 和 agent workflow 的公司。

这个联系不是我想多了。Karpathy 发的每一条动态其实都在透露他对 AI 发展的判断，他加入 Anthropic 是最近最大的一次判断落地。

我不想把这件事讲成「Anthropic 赢了」这种简单结论。

这个结论的问题是它会让人把注意力放在竞争格局上，而不是放在真正重要的问题上。「谁赢了」是一个静态的叙事，赢了之后呢？输了之后呢？没有然后。

更准确的说法是：Karpathy 的加入让 Anthropic 的一个长期判断变得更清楚了。

什么判断？

下一阶段模型竞争，不只是哪个模型回答更聪明——那个问题在 2026 年已经不是一个能拉开差距的问题了——而是谁能把模型放进更高质量的研究和工作循环里。

谁的模型更能参与 research loop，谁的模型更能理解工作 context，谁的模型更能作为一个工作单元而不是一个问答机器存在。这些东西才是接下来真正有差异的地方。

Anthropic 过去几年在方向上押得比较准。Claude Code 出来的时候，很多人还在讨论 long context 有多少 token 上限，Anthropic 已经把它做成一个能让模型持续追踪项目状态的产品了。MCP 刚出来的时候，很多人还不太理解这个协议的价值，现在看看 Claude Code 能调用多少工具，你就知道当年那个判断是对的。

Karpathy 去 Anthropic，让这个方向上又多了一个重量级的人。

那具体能带来什么？

我自己的判断是有三层。

第一层是把 pre-training research 里大量细碎但关键的工作系统化。

frontier research 里的进展很少出现在发布会上。它在数据清洗的细节里，在实验复现的过程中，在训练日志的分析里，在 eval 设计的选择里，在异常排查的路径里，在 baseline 对比的精度里。

这些东西教科书不会写，论文不会细说，但它决定了一个 lab 的真实水平。一个能稳定参与这些环节的 Claude，对 Anthropic 的价值会比一个只会写 demo 的 Claude 大得多。这件事做成了，Anthropic 的内部研发效率会比竞争对手高一个档次——不是高在算法创新上，而是高在研究循环的速度上。

第二层是把「研究员的判断」写成模型能读懂的 context。

这是 Karpathy 最擅长的事情之一。他能把复杂系统拆开，能把 tacit knowledge——那种「我知道，但我讲不清楚」的知识——变成别人能理解的结构。

他过去几年讲课、写文章、做项目，一直在做这件事。现在他要做的可能不是把这些东西讲给学生听，而是把它们整理成 Claude 能理解、能追踪、能复用的研究环境。

研究员在实验过程中做的判断，哪些维度重要，哪些数据异常，哪次实验的方向值得 follow up——这些东西过去靠人记在脑子里，或者记在笔记本里。现在如果能变成 Claude 能读懂的 context，并在后续实验中自动被调用，这个知识管理的效率会是指数级的。

第三层是这件事会反过来影响 Claude 的产品气质。

这个判断我觉得是最有意思的，但也是最难在短期内看到的。

一个模型如果长期被用于 spec、实验、debug、eval、research memory，它最后大概率会更擅长类似的工作：听懂复杂约束，保留长上下文，处理多步任务，解释中间判断，和人一起做不确定的问题。

这不会立刻体现在某个发布会上。不会某天 Claude 发公告说「我现在更擅长研究协助了」。它更可能先体现在 Anthropic 内部的研究效率上，然后慢慢渗透到 Claude Code、Artifacts、长上下文、MCP 和企业工作流里。

也就是说，Karpathy 去 Anthropic 之后，最值得看的不是他会不会马上发论文——那个太显性了，不重要——而是 6 到 18 个月后，Claude 会不会更像一个能参与复杂项目的研究同事：更能读懂项目，更能追踪上下文，更能提出实验，更能解释失败，也更能把人的模糊意图变成可验证的工作。

这是我对这件事最期待的部分。

把话说回到开头。

我为什么要把这件事定义为「一个人回到现场」？

因为它本质上不是一个争夺战，而是一个判断。Karpathy 一定做过计算，在 OpenAI 继续做 external researcher 是舒服的，title 好听，影响力大，不用面对 pre-training 里那些让人头皮发麻的工程细节。但他还是回去了。回到那个只有场内才能看清楚的位置。

这种判断不是靠信息优势做出来的，是靠对自己状态的诚实做出来的。

这个区分对创业者来说也是有意义的。

你每天看 AI 行业的信息，看哪家发布了新模型，看哪家拿到了新融资，看哪个方向被资本追着跑。这些信息重要，但它没法给你判断。判断需要的是你知道自己在哪个位置，你离什么最近，你想参与哪个游戏。

Karpathy 的选择给我们的参照不是「去 Anthropic 更好」，而是「想清楚自己在哪里很重要」。

最后说几句落到实处的。

Karpathy 去 Anthropic 这件事落到自己身上也很直接：

未来的产品，不只是给人用，也会给 agent 用。

未来的文档，不只是给人读，也会给 agent 读。

未来的工作流，不只是让人点击，也要让 agent 能理解、调用、验证和恢复。

这三句话看起来很朴素，但如果你认真想过，就会知道它们的重量。你的 API 设计、你的数据结构、你的 prompt 策略、你的错误处理方式——所有这些东西，在未来都会有一个额外的使用方：AI agent。

它不只是给你用的，它也是给 agent 用的。

这件事提醒我的不是「谁赢谁输」，而是我们可能正在进入一个阶段：

最重要的软件，不再只是写出来的 code，而是能被模型读懂、执行、纠错和继承的 context。

Karpathy 选择回到训练场，可能就是因为这件事只有在场内才能真正看清楚。而我们这些在场外的人，能做的就是把自己正在做的事情，想象成也在被一个模型读取和使用——然后问自己，它读得懂吗？它能执行吗？它出错了我能纠错吗？

这个问题，值得每个在做 AI 应用的人认真想想。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

游泳池边的笔记本

三亚的国庆，海风黏腻，游泳池里的水还带着一点消毒水的味道。

一个年轻父亲把笔记本放在躺椅边上，游出去，划几圈，回来歇一口气，打开屏幕敲几行字。再游，再回来。

女儿在不远处玩沙。他没有把这当成什么英雄叙事，只是觉得度假总得干点什么，不如把那个跑了快一年的脚本整理成一个正式的工具。

那个工具后来叫 Mole。

它发布半年后，超过七成的用户来自海外。

而这，只是这位开发者在十三年间做成的第六件事。

六款工具，六次「自己先用烦了」的产物

这个人叫 tw93，GitHub ID 是 tw93，本职是前端工程师，有正职，有家庭，还有个小小的女儿。

如果按照互联网的标准叙事模板，他大概会被归类为「副业大佬」或者「独立开发者标杆」。但他本人可能不太认同这种分类。他只是有个习惯：碰到了一个让自己难受的问题，顺手把它解掉。

第一个产品叫妙言，起因是找不到一款顺手的 Markdown 编辑器。他讨厌 Electron 那种重框架，就决定自己学 Swift 写一个。写完之后，Swift 学会了，Apple 底层渲染性能的门道也摸清了。妙言到今年已经快六年。

Pake 的故事更像一个意外。他每年会分享一次自己电脑上装的好用工具，某一年他喜欢用微信读书但没有桌面端，就用 UI 框架顺手打包了一个，发出去以后大家发现他分享的软件里有三分之一是自己写的。有人问微信读书那个怎么打包的，他就开源了代码。没想到在国外比国内火——老外喜欢把网页打包成 Mac 客户端，但 Electron 太重，Pake 刚好填上了这个空缺。

潮流周刊更早。七八年前他开始带团队，发现技术氛围不够，于是立了个 flag：每天早上看开源工具和技术资讯，整理成内部周刊。后来有人离职，问能不能在外面看，他就把周刊放到了 GitHub 的 README 里。又过了半年，国庆在老家，花了两天做了个网站，发了出去。

Mole 的前身是本地跑了快一年的 Shell 脚本，快一千行，专门清理程序员电脑上的垃圾缓存。每年买很多正版清理软件，但觉得太重。游泳池边的那次度假，他把脚本整理成了第一个正式版本。

Kaku 是 fork 了一个终端工具改的。他最早用一款极轻量的终端，配得很好看，但 AI 时代来了以后必须多窗口，那款工具不支持。找来找去，只有一个项目能改，就自己动手了。

Kami 则是他做投资时顺手做的。他七八年前开始投资美股，本地写了一套多 agent 的投资分析系统，但 AI 生成的报告太丑，就按自己的审美调了一版。发到推特上，发现大家发的报告也不够好看，开源了。

他还顺带在做一套自己的字体，完成了三分之一，因为常用的那款字体是商业字体，开源产品能用，但商务合作就麻烦了。

你注意到一个规律没有：这六款工具，没有一款是从「我要做个产品」开始的。它们全都长在一句话上——我遇到了一个问题，我先把它解掉。

Waza 更晚一些。起因是把将近一年、五六个 G 的 Claude 对话记录沉淀成工程技能库。他用 AI 分析了所有对话，按项目维度、时间维度拆解，提炼出最佳实践。这个习惯后来变成了他的日常工作：每周花一小时，让 AI 分析过去一周的踩坑记录，然后更新 Waza。

有意思的是 Waza 的结构。70% 是代码，只有 30% 是 Markdown 文档。他的逻辑是：MD 只是告诉 AI 怎么干活，代码是让 AI 能基于它去扩展。他不喜欢那种把 AI 手脚拴住的框架，觉得太重，而且会拖模型能力的后腿。他更愿意把 AI 当朋友，而不是下属。

Claude 4.6、4.7 出来以后，模型能力越来越强，你越约束它，其实是在拖它的后腿。他这么说。

Waza 里有八个 Skill，覆盖的不只是写代码，还有怎么推进项目、怎么做技术方案、怎么写让读者看得懂的文档、怎么画设计稿。在他看来，一个工程师只有三成时间在写代码，其余的能力同样重要。

Waza 知道自己的迭代方式，所以他只需要定期喂给它新的踩坑记录，它会自己更新。现在 Waza 也支持了 Codex，因为他自己开始用 Codex 了，所以它也去分析 Codex 的对话记录。他本地还有一个基于 Waza 的私人 agent，专门帮他处理开源项目的 issue 和 PR。这个 agent 知道他对 Mole 的调性要求，知道哪些功能坚决不能合，哪些 PR 写得有问题但可以改好，哪些直接不合适。他把自己从最耗时间的事情里解放出来，专注于写新功能。

Mole 为什么七成用户在海外

Mole 发布后，海外用户占比超过七成。原因不是他做了什么海外推广，而是几个更底层的因素叠加在一起。

第一，老外其实更节俭。欧美用户会把一台 Mac 用很多年，用久了会很卡。用 Mole 清了 60G、100G 的垃圾，他们非常激动，会疯狂去推广。tw93说，老外说话夸张，会直接说「我要给你跪下，你是个天才」。

第二，更懂程序员的清理工具。传统清理软件不关心程序员的各种开发工具的缓存，比如 CleanMyMac 出于安全考虑，不会去动那些深层的开发缓存。但 Mole 是程序员写给程序员的，知道哪些东西可以清，哪些开了白名单不能碰。

第三，开源本身就是最好的产品迭代机制。Mole 有 300 个 PR，100 个贡献者，全是海外用户。每个人的电脑环境不同，国家不同，技术工种不同，这些贡献让 Mole 能清理的东西越来越多，这是任何公司产品都做不到的。

当然也踩过坑。第一版发布时，因为 tw93 自己的环境偏前端，没有数据库相关配置，结果把一个用户 JetBrains 数据库工具里存在 cache 目录的账号密码全清掉了。那个用户很生气，他也很抱歉。这件事让他意识到，很多客户端产品的文件路径规范极其混乱，普通用户不关注，但清理工具必须关注。Mole 后来给 JetBrains 全系产品开了白名单，也因为这个教训越做越严谨。

还有一个细节能说明 Mole 的热度。他当时把两张图片放到了 Vercel 的 CDN 上加速，不到一周，Vercel 发来紧急通知说他欠了 80 美元。他以为不可能，去查了一下，发现就是那两张图片，用了 80T 的流量，就几分钟时间。他立刻意识到，这个 README 有大量的人在访问。

第一款付费产品，每十秒收一笔钱

Mole 推出桌面端时，tw93 周一晚上十点发布，因为白天在上班。

发出去之后，手机大概每十秒响一次支付通知，后来连 iPhone 都开始发烫。睡觉前，他不得不把 Google 的通知全部关掉，不然睡不着。

定价 9 美元终身买断。很多人说他卖太便宜了。当然也有喷子说，你不就把 CLI 包了一下吗？他觉得无所谓。他本来就不是靠这个赚钱的。

他最开心的是，有人用了以后愿意主动打赏。免费的东西，有人愿意付钱，说明做的东西是有意义的。手机弹出微信通知「谁谁谁又给你打赏了」，他说那种感觉真的会很开心。

支付对接用的是 Dodo Payment，一家印度小哥创立、注册地在美国的支付平台。他之前试过 Stripe，走到最后一步，对方要香港身份证，卡死了。Lemon Squeezy 也要求提供公司信息，个人用不了。后来在推特上看到有人推荐 Dodo，花了一个下午接好，发布了。

不过支付平台会收 16%、17% 的税。后来 Dodo 的 CEO 办公室的人主动在推特上找到他，把他拉进了专属服务群，还给了一些费用减免。

关于收款，他有一个实操建议：超过 1 万美元，立刻会有很多人来找你核查，非常麻烦。尽量把钱放在香港卡或新加坡卡，不要直接汇回国内。他自己就因为这个折腾了几次，最后把钱退回去重新想办法，不过他夸了招商银行的服务人员会为客户着想。

为什么他的东西好看

很多人用完 tw93 的工具，第一反应是：怎么这么好看？

他给了几个原因。

大学时保研后有大量空闲时间，把图书馆里所有前端和设计相关的书都看完了。设计思维、极简主义、日本设计原理，那个阶段打下的审美底子，后来工作了才慢慢显现出来。

入职后，他最喜欢跟设计师玩，经常一起讨论设计细节，受他们审美影响很深。后来负责整个部门的 ToB 产品，发现用文档跟人对齐方案，大家理解都不一样。最后发现最有效的办法是直接画一张高保真 Sketch 稿，发群里拉个会，大家立刻就 get 了。为了不让一件事反复讨论，他逼着自己学会了画稿。

还有一个更底层的原因：他是强迫症。他说自己刚入职时，QA 同学测不出他写的页面有 bug，他的代码可以免提测直接上线。这个习惯一直延续到做开源产品。做到 75 分没 bug 不够，他要做到 95 分。不是为了炫技，是因为他受不了丑的东西，也不想让用户反复来问他。

他最近还在看元至清的中国古画，以及日本设计原理方面的书。他说很多古画看不懂意境，但看画家怎么画马、怎么构图，还是能 get 到一些东西。

关于长期主义，他说的最实在的一句话

「长期主义能帮你更好地偷懒。」

他在一家公司工作了 11 年没换过。

他买特斯拉股票是在 100 多美元，买英伟达股票是在 80 多美元，买了以后从来不卖，一年只操作两三次。他说他很讨厌做判断，因为一旦有多个选项就会很纠结，那几天都会很难受。所以他尽量在需要做判断之前，就把很多事情提前决定好，这样就不用反复纠结了。

长期主义在他这里不是口号，是一种减少决策消耗的生活方式。

他的 GitHub 只有 6 个 pin 位，全占满了，不会再开新坑。他认为，同时做 100 个产品，100 个都做不好。把现有的几个维护好，复利会越来越强。Mole 发布半年，已经迭代了将近 40 个版本，用的人越来越多，知道这个产品的人越来越多，这才是真正的积累。

他还提到一个反直觉的观察：妙言在真正公布之前，已经迭代了半年多，用户量一直很少。一推出去，数据直接从平线拉起来。酒香也怕巷子深，你还是得在适当的时候把门面讲清楚。

给非技术人用 vibe coding 的建议

他说，非技术人做产品，最大的风险不是写不出代码，而是不懂通识，半年后代码跑不动了，自己也不知道出了什么问题。

他举了个例子：AI 能把一个产品做到 80% 很容易，但从 80% 到 100%，可能要花 80% 的时间。很多人不懂这一点，觉得前端也就这么回事，后端也就这么回事，我什么都不会，app 就写出来了。但这个 app 想从你能用到 100 个人能用，中间有大量你发现不了的 bug，因为你不具备找 bug 的能力。

他推荐了几本书：《人月神话》理解为什么软件项目不能靠堆人解决，AI 时代同样适用；《启示录》理解怎么做产品取舍、怎么定义最小闭环、怎么规划里程碑；《左耳听风》理解一个资深工程师是怎么看问题的；《Linux/Unix 设计思想》一本很薄的书，讲原子能力、管道、系统设计的底层逻辑，他说大学看完以后有种功力大增的感觉。

他的核心观点是：你不需要会写 React，但你要知道什么时候该用 React、什么时候只需要一个静态服务器。这种判断力，才是 vibe coding 时代真正的护城河。

最值得收藏的一个观点

他说，在 AI 时代，真正的壁垒不是你做出了什么工具，而是你和 AI 的聊天上下文。

别人可以把你的产品蒸馏走，但没办法蒸馏你踩过的坑、你的判断逻辑、你和 AI 反复打磨出来的那些失败路径。

他特别强调：记录失败比记录成功更重要。成功的东西大家只看结果，失败的路径才能告诉你下次怎么绕开。就像线上系统挂了，你一定会去查挂在哪里，但系统跑得好的时候，没人会去研究它为什么好。

关于记忆系统的设计，他有一个很有意思的框架：按照人类记忆的方式来设计。大语言模型本来就是基于人类语言训练的，所以记忆系统也应该像人一样，有项目上下文记忆（当前在做什么）、短期记忆（最近遇到的卡点）、长期记忆（历史积累）。

他不太推荐直接给 AI 灌知识库，因为知识会过期，灌进去的人可能自己也不知道哪些已经过时了。把你和 AI 的所有对话记录保护好，把 AI 帮你干成和干失败的记录都保存下来。这些东西，才是别人学不走的东西。

出海商业化的几个实操细节

如果你打算做出海产品，他的经验是：

个人身份对接商业资源，天然处于劣势。建议注册一家美国小公司，费用不高，每年记得报税就好。有了美国公司主体，App Store 账号、支付平台、云服务商，都以公司名义对接，中国个人身份的限制就绕开了，税率也会低一些。

支付平台不要自建，也不要用那些知名大平台。Stripe 对中国个人限制很多，走到最后一步会卡死。他推荐 Dodo Payment，印度小哥做的，注册地在美国，响应速度快，能处理全球支付和各国税务合规，包括欧盟要求的 14 天无理由退款政策。

售后系统不要过早做。前期专注把主产品做好，用户量还不大的时候，手工回邮件、手工点退款就够了。很多程序员喜欢把所有东西都自动化，但这个阶段的精力应该全放在产品本身。

十三年的缝隙

这场对话里，tw93 反复说的一件事是：他的所有产品，都是先解自己的问题，然后发现有人跟他有同样的问题，才开源出去的。

这个逻辑听起来简单，但能坚持 13 年、做出 6 个有人用的工具，背后是他对「不做什么」的极度克制，对「做好一件事」的极度专注。

你把时间摊开看，就会发现这十三年的重量：一款工具的开发周期可能是几个长假，几个早起，几个游泳池边的午后。它们散落在一个人从青年到中年的缝隙里，没有声响，没有叙事，只有代码写完、摁下回车的那一刻。

他把长期主义解释为一种偷懒的方式，其实是这个道理：你把所有决定都提前做好，剩下的就是重复，是积累，是复利。而不是反复在十字路口消耗自己。

妙言迭代了半年才推出去，推出去之前数据一直很平。潮流周刊做了三年才有人注意到。每一个看似一夜爆红的产品，底下都压着漫长的沉默期。没有人看见的那部分，才是真正的时间成本。

如果你现在也在想做点什么，他的建议是：先找到那个让你自己最难受的问题，把它解掉。

这句话听起来像正确的废话。但你仔细想想就会发现，大多数人做不到，不是因为懒，而是因为他们的问题不够具体，不够痛。痛了才会动手，才会迭代，才会推到 GitHub 上，等一个陌生人发来一句「我要给你跪下」。

游泳池边的笔记本还在。下一款工具，大概已经在某个假期的潜水间歇里，敲出了第一行代码。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你读到这里。下次见。

原文媒体

一个好的 Agent 需要什么

你有没有遇到过这种情况。

花了三周调 prompt，调工具定义，调 few-shot 示例，终于把 Agent 跑通了。

演示的时候领导眼前一亮，问了一个灵魂问题：这个能上生产吗？

你心里一沉。

因为你知道，现在这套东西跑在本地，跑在笔记本上，一旦部署到生产环境，面对用户并发、进程崩溃、模型抽风、长时间运行、中途需要人工介入这些状况，基本上撑不住。

这不是你一个人会遇到的问题。

这是整个 AI 行业在 2024-2025 年集体面对的问题。大家都发现，构建一个能跑的 Agent 和构建一个能上生产的 Agent，是两件截然不同的事情。

LangChain 刚发了一篇挺长的 guide，讲的就是这件事。坦率的讲，这是我看过最系统的一次梳理，把「开发态的 Agent」和「生产态的 Agent」之间到底差了什么，讲得很清楚。

我觉得有必要认真聊聊这个话题。

首先，区分两件事

guide 里提了一个我认为非常关键的概念：harness 和 runtime 的区分。

怎么理解呢？

Harness 是你围绕模型构建的那一层，目的是让 Agent 在特定领域里能成功。包括 prompt、工具定义、技能描述，以及支撑模型和工具调用循环的一切。这部分你天天在调，改 prompt、加 few-shot、调 temperature，这些都属于 harness 的范畴。

Runtime 是 harness 下面的那一层，是让 Agent 真正能在生产环境里跑起来的东西。持久化执行、内存管理、多租户隔离、人机交互、监控告警，这些基础设施你在开发的时候根本不会想到，但上线之后每一件都会来敲门。

一个好的 harness 给 Agent 正确的 prompt、工具和技能。

一个好的 runtime 让 Agent 在生产环境里可靠地运行，不会因为进程挂了、版本发布了、用户说「等一下让我确认一下」就崩掉。

这两个东西，缺一不可。

但行业里大多数讨论都在聊 harness——怎么写 prompt、怎么定义工具、怎么做 few-shot，冷不丁冒出一个「RAG 技巧」。Runtime 这部分讲的人少，因为涉及的东西太基础设施了，不好发 demo。

今天我决定好好讲一讲。

Durable execution：一切的基石

先说 durable execution，持久化执行。

这个东西为什么重要？因为 Agent 跑的是一个循环：模型接收 prompt、推理决策、调用工具、观察结果、然后重复。这个循环可能持续几分钟，也可能持续几小时。

不像普通的 web 请求，几百毫秒就返回了，Agent 的执行周期完全不可控。一个研究型 Agent 可能花二十分钟收集资料、整理分析、生成报告；一个辅助决策的 Agent 可能在关键节点停下来，等人工确认某个操作要不要执行。

在这个时间尺度里，进程会挂，服务器会发布，网络会抖动，任何一个环节出问题都不应该让之前的工作全部白费。

你感受最深的大概是两个场景。

第一，长时间运行需要扛住基础设施故障。

假设你的研究 Agent 正在搜集资料，已经完成了十轮工具调用，消耗了大量 token，突然进程崩了。

如果没有任何持久化机制，Agent 只能从头开始，用户的等待时间翻倍，你浪费的 token 费用也翻倍。

你真正想要的是：从上一个完成的步骤恢复，所有状态都保留，不需要重来。

第二，Agent 需要能够真正停下来等。

有时候 Agent 暂停是为了等待人工批准一个操作，比如发送一封重要邮件、执行一笔转账。这个等待可能是三十秒，也可能是三天。

把 worker 进程或者客户端连接绑死在这个窗口里是不现实的。Agent 需要真正释放资源，把 worker 进程让出来，然后等用户回复的时候再精确地从停下的地方恢复。

这两个需求，用同一个机制解决：checkpoint，持久化检查点。

具体怎么做的呢？

Agent 运行在一个托管的任务队列上，每个 super-step 的图执行都会往持久化层写一个 checkpoint。默认是 PostgreSQL，通过 thread_id 作为游标来关联整个运行过程。

进程崩溃了？没问题。run 的 lease 被释放，另一个 worker 会从最新的 checkpoint 恢复。Agent 在等人工输入？没问题。进程释放资源，run 进入休眠状态，一直等到被 resume 为止。

这是整个 runtime 能力的基石。

因为执行可以跨进程边界暂停和恢复，Agent 才能无限期等待人工输入，才能在后台运行，才能在发布中途继续执行，才能同时处理多个并发请求而不破坏状态。

没有 durable execution，其他所有能力都是建立在沙滩上的。

Memory：两种记忆，两种机制

Agent 需要两种不同类型的记忆，这个区分非常重要。

短时记忆是 Agent 在单个对话里积累的东西。消息往来、工具调用、中间状态，在一个 run 里逐步构建。这部分存在 thread 的 checkpoint 里，通过 thread_id 关联，一旦对话结束（概念上）就消失了。

下一条消息来了，如果还是同一个 thread，Agent 能看到之前所有的上下文。这就是短时记忆。

长时记忆是 Agent 跨越对话携带的东西。可能是跨对话学会的用户偏好、项目规范、最佳实践，或者是一个知识库，随着每次查询不断增强。

这些不属于任何一个 thread，它是用户级别或者组织级别的上下文，应该贯穿 Agent 的每一次对话。

checkpoint 做不到这件事，因为 checkpoint 状态的作用域是单个 thread。

长时记忆需要另一个机制。Agent Server 内置了一个 store，这是一个 key-value 接口，记忆按照命名空间元组组织，比如 (user_id, "memories")。存储是跨 thread 持久化的，你在一次对话里写入，下一次对话就能读到。

默认用 PostgreSQL 作为后端，支持语义搜索——通过 embedding 配置让 Agent 可以按照语义检索记忆，而不仅仅是精确匹配。命名空间结构很灵活，你可以按用户、按助手、按组织，或者任意你数据模型需要的组合来组织。

为什么这件事重要？

因为积累数月的记忆是整个系统产出的最有价值的数据之一。它应该存在你能控制的标准格式里，存在你自己的 PostgreSQL 实例里，而不是一个封闭黑箱里。

这样做的好处是，你可以随时迁移到其他模型，可以分析这些数据，可以在 Agent 之外构建其他功能。如果你的记忆被锁在某个封闭系统里，这些可能性都没了。

多租户：三个问题，三层机制

一旦你的 Agent 服务超过一个用户，一系列在单人模式下不存在的问题就冒出来了。

guide 里把这三个问题拆得很清楚，Agent Server 对每个问题都有对应的原语处理。

第一个问题：隔离不同用户的数据。

用户 A 的 run 应该只能访问用户 A 的 thread，只能读取用户 A 的记忆。Custom authentication 作为中间件运行在每个请求上，你的 @auth.authenticate handler 验证传入的凭证，返回用户身份和权限，附加到 run 上下文。Authorization handlers 再用 @auth.on.threads、@auth.on.assistants.create 这些装饰器来控制谁能看什么、改什么，方式是在创建资源时打上所有权元数据标签，读取时返回过滤字典。

Handlers 从最具体到最不具体匹配，所以你可以先从一个全局 handler 开始，随着系统复杂度增长再添加资源特定的 handlers。

第二个问题：让 Agent 能够代表用户操作。

Agent 经常需要用用户的凭证调用第三方服务——读他们的日历，发他们的 Slack，发他们 repo 里的 PR。Agent Auth 处理这个流程的 OAuth 流程和 token 存储，用户认证一次，Agent 在后续的 run 里就能用这个用户的身份操作，不用你自己管理 token 刷新。

第三个问题：控制谁可以操作系统本身。

这是独立于终端用户访问的权限问题。你的团队里谁可以部署 Agent、配置 Agent、查看 trace、更改认证策略？RBAC 处理这个操作员级别的访问控制。

三层组合在一起：终端用户通过你的 auth handler 认证，Agent 通过 Agent Auth 调用第三方服务，你的团队在 RBAC 策略下操作系统。

Human-in-the-loop：让人介入循环

Agent 的执行循环大多数时候需要不间断运行，因为价值就来自这里。但有时候你确实需要一个人在关键决策点介入。

两种典型场景：

场景一，审核 Agent 提议的工具调用。

在 Agent 执行一个重大操作之前——发邮件、转账、删文件——你想让一个人看到它准备做什么，决定怎么回应。比如邮件场景：Agent 起草了一条消息，在发送前暂停。你可以直接批准原样发出，可以修改主题或正文后再发出，也可以拒绝并给出具体修改意见，让 Agent 修订后重试。

场景二，Agent 遇到无法自己解决的决策点。

有时候 Agent 到达一个它无法处理的决策点，不是因为缺少工具，而是因为正确答案取决于人的判断或偏好。与其瞎猜，Agent 可以直接把问题抛出来：「我找到了三个匹配这个模式的配置文件，应该修改哪一个？」「这个应该部署到 staging 还是 production？」你的回答成为 interrupt 的返回值，Agent 从停下的地方继续。

Agent Server 用两个原语处理这个：interrupt() 暂停执行并向调用方暴露一个 payload；Command(resume=...) 用人工响应继续执行。

底层发生了什么？interrupt() 触发 runtime 的 checkpointer 把完整图状态写入持久化存储，通过 thread_id 作为游标关联。进程释放资源，无限期等待。当 Command(resume=...) 到达——可能是几分钟后，可能是几小时后——resume 的值成为 interrupt() 调用的返回值，执行从精确的断点恢复。

因为 resume 接受任意 JSON 可序列化值，响应不仅限于 approve/reject。审核者可以返回修改后的草稿，人类可以提供缺失的上下文，下游系统可以注入计算结果。当并行分支各自调用 interrupt() 时，所有待处理的 interrupts 可以一起暴露，批量 resume，或者按顺序一个一个恢复。

这个能力让审批门控、草稿审查循环、输入验证，以及任何需要人类在中途判断的工作流成为可能。

实时交互：两个问题

人机交互还有另一个维度，除了可以暂停等待人的场景，还有 Agent 在积极工作而用户在线的场景——实时会话。

这类问题有两个。

第一个，流式输出。

如果 Agent 花三十秒产生一个响应，用户只能盯着加载动画，不知道是还在处理、卡住了还是即将失败。用户也无法在完整响应完成前开始阅读，流式解决了这两个问题：部分输出随着 Agent 产生它们实时流向客户端，用户看到响应在眼前逐步呈现。

流式 API 支持多种粒度模式：每个图步骤后的完整状态快照、仅状态更新、按 token 的 LLM 输出，或自定义应用事件。也可以组合使用。Run streaming 作用域是单个 run；thread streaming 打开一个长连接，从 thread 上的每个 run 发送事件，当后续消息、后台 run 或 HITL resume 都在同一个 thread 上触发活动时很有用。

Thread streaming 支持通过 Last-Event-ID header 重连：客户端重连时带上它接收的最后一个事件的 ID，服务器从那里重放，无缝衔接。

第二个，双消息问题。

用户在 Agent 还在处理前一条消息时发了第二条。聊天 UI 里这种事经常发生，有人发了问题，觉得说得不够清楚，在 Agent 还没回完的时候就发了第二条修正。

Runtime 对这种情况有四种策略：

• enqueue（默认）：新输入等待当前 run 完成，然后按顺序处理。
• reject：拒绝任何新输入直到当前 run 完成。
• interrupt：停止当前 run，保留进度，从那个状态处理新输入。当第二条消息是在第一条基础上追加的时候很有用。
• rollback：停止当前 run，回滚所有进度，包括原始输入，把新消息作为全新 run 处理。当第二条消息替换了第一条的时候很有用。

interrupt 给出最流畅的聊天体验，但要求你的图能干净地处理部分工具调用（interrupt 时发起的工具调用可能没有完成，需要在 resume 时清理）。enqueue 是最安全的默认值，不会出现状态损坏，但用户需要等待。

Guardrails：让策略在代码里，不是 prompt 里

不是所有生产需求都能表达为「让循环持久运行」，有些需要直接塑造循环本身：拦截模型输入、过滤工具输出、对昂贵操作施加限制。

这些策略应该写在代码里，不应该放在 prompt 里。它们需要每次都执行，而不是模型碰巧想起来的时候才执行。

两个具体场景：

场景一，在模型看到之前清除敏感数据。

客服 Agent 处理包含 PII 的用户消息——姓名、邮箱、账号。合规要求这些在记录日志之前就被清除。这个清除必须发生在每次模型调用之前，确定性地执行。

场景二，限制昂贵操作。

可以调用付费外部 API 的 Agent 需要对每次 run 的调用次数设置硬上限，因为一个陷入困惑的模型会高高兴兴调用五十次，在你午饭前烧光你的预算。

这两件事都通过 middleware 处理。Middleware 在定义的钩子（before_model、wrap_model_call、wrap_tool_call、after_model）上包裹 Agent 循环，所以策略在每个相关步骤周围确定性地执行。

LangChain 提供了开箱即用的 middleware：PIIRedactionMiddleware、ModelRetryMiddleware、ModelFallbackMiddleware、ToolCallLimitMiddleware、SummarizationMiddleware、HumanInTheLoopMiddleware、OpenAIModerationMiddleware，你也可以写自定义 middleware 实现应用特定策略。

Middleware 是开源的，但它真正发挥价值是在运行时内部执行时。当 middleware 在 runtime 里运行时，这些策略成为 runtime 支持的每种交互模式的一部分——流式传输、人机交互暂停和恢复、重试、后台 run、长寿命 thread。在实践中，这意味着你的防护栏和仪表化不是「尽力而为」——它们一致地包裹每次模型调用和每次工具调用，在每一个你期望的精确时刻执行，不管 Agent 在做什么。

可观测性：看不到就不能改

你不知道 Agent 在生产环境里会做什么，直到你真的跑起来。

和传统应用不同，传统应用你可以从代码推导出行为，Agent 的执行路径取决于模型在运行时的选择：调用什么工具、传递什么参数、怎么解读结果、什么时候放弃换一个方案。出了问题，你不能重新读一遍函数定义就找到原因，你需要看到到底发生了什么。

一个工单说「Agent 一直问同一个问题」。

没有 trace，你只能从用户描述里猜。有了 trace，你看到完整执行树：用户消息、模型计划响应、调用的工具、返回的结果、下一个生成的消息、陷入的循环。你能筛选高成本的 run 找到消耗大量 token 的案例，筛选错误的 run 找到失败的案例，筛选用户的 run 看到特定客户经历了什么。你能发现跨数千个 run 的模式，这些是任何单个 trace 都无法揭示的。

每个 LangSmith Deployment 自动接入 tracing 项目，开箱即得完整执行树——模型调用、工具调用、子 Agent run、middleware 钩子——带可按用户、时间窗口、成本、延迟、错误状态、反馈或自定义标签查询的结构化元数据。

Trace 是改进循环的基础。Polly 是 LangChain 的 AI 助手，分析 trace 并提炼洞察——常见失败模式、慢工具调用、重复模式——所以你不用手动阅读数千条。Online Evals 自动对生产 trace 运行 LLM-as-judge 或自定义评分器，所以回归问题能被实时捕获。

他们用这个循环把 Deep Agents 在 Terminal Bench 2.0 上提升了 13.7 分，方法仅仅是改变 harness——这个案例完整证明了为什么 Agent 改进循环从 trace 开始。

Time travel：回到过去

可观测性告诉你发生了什么。Time travel 让你问：如果某件事走向不同方向，会发生什么？

驱动场景是调试一个跑偏了的 run。你的 Agent 在 20 步 run 的第 5 步做了一个糟糕决策：调用了错误的工具、误读了工具结果、应该继续的时候问了澄清问题。你想理解为什么，想尝试其他方案而不从头跑整个流程。更一般地说，任何时候 Agent 的路径依赖于特定检查点的状态，你都想要回滚到那个检查点、改状态、让剩余 run 沿不同方向展开的能力。

因为每个 super-step 都会写 checkpoint，run 历史的每个点都已经是一个快照，你可以返回。Time travel 让这个能力显式化：从 thread 历史里选一个 checkpoint，任意修改其状态，然后从那里 resume。被修改的 checkpoint 分叉了 thread 的历史，原来的保持完整，新路径作为自己的分支向前运行。LLM 调用、工具调用、interrupts 都在回放时重新触发，所以分叉走的是真实 Agent 循环，而不是一个存根。

这解锁了一些很难用其他方式构建的模式：调试为什么 Agent 选了工具 A 而不是 B，对比两个 prompt 在相同上游上下文下的表现，从走偏的 run 恢复到上一个良好状态，或者探索许多分叉的反事实来理解模型行为。

代码执行：沙箱里的通用 Agent

只能调用你预先接好的工具的 Agent 局限性很大，受限于你能想到的场景。能跑任意代码的 Agent 是通用目的的：安装依赖、克隆仓库、执行测试、运行数据分析、生成文档、渲染图表。

这是「带函数调用的聊天机器人」和「真正能做成事的 Agent」之间的差距。

任意代码执行需要隔离。如果 Agent 在你的宿主机上跑 rm -rf /，你有大麻烦。如果它读取你的环境变量，API key 就被泄露了。你需要 Agent 执行环境和你在乎的一切之间有一个边界，而且需要在 Agent 写出第一个命令之前就建立好这个边界。

在 Deep Agents 里，隔离通过 sandbox backends 实现。配置一个实现 SandboxBackendProtocol 的后端，Agent 自动获得一个 execute 工具来在沙箱里运行 shell 命令，配合标准文件系统工具使用。没有 sandbox 后端，execute 工具对 Agent 根本不可见。支持 Daytona、Modal、Runloop 和 LangSmith Sandboxes，切换提供商只需改一个配置。

LangSmith Sandboxes 值得单独提一下，因为它与 runtime 的其他部分集成得很好。Templates 用声明方式定义容器镜像、资源限制和 volumes。Warm pools 预启动沙箱并自动补充，消除了交互 Agent 的冷启动延迟。Auth proxy 解决了一个每个团队最终都会遇到的问题：Agent 需要调用有认证的 API，但在沙箱里放凭证是安全风险。Proxy 作为 sidecar 运行，拦截出站请求，自动从 workspace secrets 注入凭证——沙箱代码调用 api.openai.com 时不带任何 header，proxy 在请求出去时加上正确的 Authorization header。密钥永不进入沙箱，Agent 也拿不到它看不到的东西。

一条安全建议值得重复：沙箱保护你的宿主机，不保护沙箱本身。攻击者如果控制了 Agent 的输入（通过被爬网页面的 prompt injection、恶意邮件、下毒的 tool result），可以指示 Agent 在沙箱内运行命令。沙箱把攻击者拦在你的机器之外，但沙箱内部的东西——包括直接放在里面的凭证——都可能被攻陷。Auth proxy 就是为这个而生的。

集成：Agent 不是孤岛

Agent 在能够接入人和组织已经在用的系统时最有用。一个编码 Agent 能访问 GitHub、Linear 和你的 CI 系统时会更强。一个研究 Agent 的输出能进入你的发布流程时更有用。一个内部 Agent 成为平台，当其他 Agent 可以把它作为构建模块来调用时。如果每个集成都是手写的适配器，你的 Agent 就保持孤立。「Agent」和「其他一切」之间的边界变成一堵墙。

开放协议解决的是这个问题——让 Agent 和外部系统互相发现和通信，不需要任何一方知道对方的实现细节。Agent Server 自动提供三个集成面。

MCP（Model Context Protocol） 是连接 Agent 与工具和数据源的开放标准。每个 LangSmith Deployment 自动暴露一个 MCP endpoint，让你的 Agent 可被任何 MCP 兼容客户端发现——Claude Desktop、IDE、其他 Agent、自定义应用——无需你写适配代码。反过来，你的 Agent 也可以调用任何 MCP server（Linear、GitHub、Notion 以及数百个其他）来访问用户已有的工具和数据。

A2A（Agent-to-Agent） 是 Agent 间通信的对应标准，每个部署也自动暴露 A2A endpoint。这让跨部署的多 Agent 架构变得可管理：一个部署里的编排 Agent 可以用双方都理解的协议发现并调用另一个部署里的工作 Agent，不需要手写 HTTP 契约。

Webhooks 处理出站情况：你的 Agent 完成了 run，你想触发下游的事，不需要轮询。在创建 run 时传入 webhook URL，服务器在完成时向那个 URL POST run payload。这就是如何把 Agent run 链入现有工作流的方式——研究 run 完成触发发布管道，每日总结完成通知 Slack，合规检查完成写入审计日志。

Cron：主动工作，不需要人触发

我们到目前为止讨论的 Agent 都是响应式的：用户发消息，Agent 回应。但很多有价值的 Agent 工作是主动的——它按计划发生，不需要人触发。

两种模式特别有意思：

第一种，夜间计算。

在空闲时段做有用工作的 Agent，让用户从累积的思考中获益，而不是等待即时延迟。研究 Agent 每晚运行，追踪你领域的新论文。准备 Agent 在你开始新一天之前审查明天的日历并起草简报。分类 Agent 分类过夜的支持工单，让你的团队走进一个按优先级排列好的队列。工作在没人等待的时候发生，等用户出现时输出已经准备好了。

第二种，健康和监控循环。

定期检查某件事并在发现问题时报错或升级的 Agent。每十五分钟审查告警的值班 Agent，监控你的 staging 环境回归情况的 Agent，按周期巡查违规的合规 Agent。这些需要和面向用户的 run 一样的持久性、tracing 和认证保证，只是没有用户在等它们。

Agent Server 内置了 cron jobs，所以调度的 run 和其他任何 run 一样获得相同的持久性、tracing 和认证保证——不需要维护单独的调度器，不需要搭建第二套可观测性体系。你传入一个标准 cron 表达式（UTC）和输入，服务器按计划触发 run。

两种口味适配不同模式：

• 有状态 cron 把调度绑定到特定 thread_id，所以每次触发的 run 都追加到同一个对话。这适合能看到自己历史的 Agent——每天研究 Agent 在昨天的发现基础上构建，或者监控 Agent 记得它已经标记过什么。
• 无状态 cron 为每次执行启动一个全新 thread，适合不需要 run 之间连续性的批处理式工作。通过 on_run_completed 控制 thread 清理："delete"（默认）在 run 完成后删除 thread，"keep" 保留它供以后通过 client.runs.search 检索。

每个 cron run 都出现在 tracing 里，尊重 auth handlers 和 middleware，并在失败时支持 resume——凌晨三点遇到短暂模型故障的 cron 不会静默失败，会像其他 run 一样重试。一个运营注意事项：用完 cron 记得删掉。在你删除之前它们会一直运行（并计费）。

open harness：不被锁住

agent infra 领域有一个越来越明显的趋势：转向托管方案往往伴随着构建者选择权的减少——被锁在单一模型提供商、被锁进一个封闭 harness、或者 harness 功能被藏在 API 后面（比如服务端压缩生成加密摘要，你没法在一个生态系统之外使用）。

实际后果是：团队失去了对自己 Agent 实际如何运作的可见性，也失去了在它不符合预期时改变它的能力。

关于 vendor lock-in 有一点值得注意：deepagents deploy 的设计目标就是避免它。Harness 是 MIT 许可、完全开源的，Agent 指令使用 AGENTS.md（一个开放标准），Agent 通过开放协议暴露——MCP、A2A、Agent Protocol。没有模型或沙箱锁入，harness 的任何部分都不是黑箱。

此外，Deep Agents 允许你检查、自定义和扩展 Agent 行为的每一层，包括通过 LangChain middleware 配置速率限制、重试逻辑、模型 fallback、PII 检测和文件权限。

Memory 用可插拔后端的虚拟文件系统给 Agent 既有临时工作空间又有持久化跨对话存储。Deep Agents 支持按用户或按助手（或两者）范围的记忆。

沙箱提供商（LangSmith Sandboxes、Daytona、Modal、Runloop，或自定义）是一个配置值。当沙箱存在时，harness 自动添加一个 execute 工具。Sandbox 生命周期（图工厂处理的 thread-scoped 与 assistant-scoped）通过图工厂处理。沙箱内的凭证通过 sandbox auth proxy 管理，所以 API key 从不出现在沙箱代码或日志里。

Skills 和指令从你的 skills/ 目录和 AGENTS.md 自动检测。MCP servers 从 mcp.json 加载。name 字段是唯一必需的配置值；其他都有合理的默认值。

结果是部署可以随时间演进——新 skills、新工具、新记忆策略——不需要全面重写。

说在最后

构建 Agent 是一个深度迭代的循环。

Trace 暴露生产中实际发生的事。在线评估在回归扩大之前捕获它们。记忆让 Agent 随着时间变得更强大。基础设施不仅仅是在支撑在线 Agent——它是让它变得更好的基础。

这篇 guide 覆盖的这些能力——持久化执行、内存、多租户、防护栏、人机交互、可观测性、沙箱代码执行、调度 run，以及更多——是生产 Agent 无法运行就不能缺的基础设施要求。deepagents deploy 把这些都打包好，让团队不需要从头组装，并且在整个过程中保持技术栈开放、可配置、属于你。

坦率的讲，看完 LangChain 这篇 guide，我最大的感受是：行业终于开始认真对待「从 demo 到生产」这中间的距离了。

之前大家都在晒 prompt 效果、晒 benchmark 分数，但真正上了量、上了生产环境，遇到的那些乱七八糟的问题——进程挂了怎么恢复、用户并发怎么办、敏感数据怎么脱敏、长时间运行的 Agent 怎么监控——这些东西很少被系统性地讨论。

LangChain 这次把 runtime 这层基础设施讲得很清楚，我觉得对于正在做 Agent 相关项目的团队来说，是值得认真读一遍的材料。不是说一定要用他们的方案，但至少能让你知道，一个真正能跑在生产里的 Agent，底下需要支撑哪些东西。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

原文媒体







你让 Claude Code 写功能、补测试、格式化文件，最后顺手提交

你让 Claude Code 写功能、补测试、格式化文件，最后顺手提交。

它功能写了，测试也补了大半，格式化跑了两个文件，但偏偏漏了一个。

然后它很自然地告诉你：「搞完了。」

你一看：没提交，格式也没完全对齐。

但这些问题，其实不该靠你事后检查。在 Claude Code 里，它们都可以配置成自动流程。

这就是 Hook 存在的理由。

Hook 是什么

Claude Code hooks 是在 Claude 生命周期的固定节点自动执行的 shell 命令。

不需要你给 Claude 下任何指令，Hook 就已经跑完了。

Claude 可能不跑格式化工具。挂在 PostToolUse 上的 Hook 会在每次文件编辑后跑 Prettier。

Claude 可能忘了通知你。挂在 Notification 上的 Hook 每次 Claude 需要你介入时都会弹窗。

Hook 把行为从 Claude 的判断里抽出来，放到你的项目规则里。代码质量、通知、安全检查。这些最要紧的事应该放在 Hook 里，不是 prompt 里。

GitButler 的指南：从三个开始。PostToolUse 自动格式化、PreToolUse 拦截危险命令、Notification 桌面通知，覆盖最广，上手最容易。

先看这 5 个生命周期事件

Claude Code 有 20 多个生命周期事件，SessionStart 到 SessionEnd。不用全记。下面 5 个是实际工作中真会用的：

PostToolUse，Claude 用完工具后触发。自动格式化、跑 linter、记变更日志。

PreToolUse，Claude 调工具之前触发，可以拦截。保护敏感文件（.env、package-lock.json）、阻止危险命令、在 Claude 写任何东西之前卡一刀。

Notification，Claude 需要你关注时触发。弹桌面通知，你不用盯着终端，该干嘛干嘛。

Stop，Claude 回复结束时触发。跑测试、跑 CI、自动提交——Claude 说「搞完了」之后自动执行。

SessionStart，会话启动或恢复时触发。压缩（compaction）之后重新灌上下文，或者加载环境相关的提醒。

剩下事件（SubagentStart、WorktreeCreate、InstructionsLoaded 等）给更复杂的流程。先从上面 5 个上手。

三种值得用的 Hook type

除了标准的 shell 命令 Hook（"type": "command"），还有三种：

Prompt Hook（"type": "prompt"）把 Hook 的输入丢给 Claude 模型（默认用 Haiku）做判断，返回是/否。适合需要模型理解的场景，比如在 Claude 停止前检查是不是所有任务都完成了：

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check if all tasks are complete. If not, respond with {\"ok\": false, \"reason\": \"what remains to be done\"}."
          }
        ]
      }
    ]
  }
}

比写正则强。模型能理解语义，判断更准确。

Agent Hook（"type": "agent"）起一个子代理，能读文件、搜代码、跑工具，最多 50 轮。适合需要对照实际代码状态做判断的情况——比如 Claude 停之前确认测试确实过了。

HTTP Hook（"type": "http"）把事件数据 POST 到 URL，不跑 shell。适合团队审计日志、共享通知服务、webhook 集成。

多数场景 "type": "command" 够用。

怎么配 Hook

Hook 配置放在三个位置之一：

• ~/.claude/settings.json 所有项目
• .claude/settings.json 当前项目（提交到仓库，团队共享）
• .claude/settings.local.json 当前项目，不提交

结构都一样：

{
  "hooks": {
    "EventName": [
      {
        "matcher": "ToolName|OtherTool",
        "hooks": [
          {
            "type": "command",
            "command": "your shell command here"
          }
        ]
      }
    ]
  }
}

Matcher 是正则，过滤触发条件。在 PostToolUse 和 PreToolUse 里匹配工具名称："Edit|Write" 在文件编辑后触发，"Bash" 在 shell 命令后触发，"mcp__github_.*" 在任意 GitHub MCP 工具调用后触发。

最简单的方式是用 /hooks 交互菜单。在 Claude Code 里敲 /hooks，选事件、设 matcher、填命令，不用手写 JSON。加了就生效。

立即能配好的 5 个 Hook

1. Claude 需要你时弹通知

别盯终端了。每次 Claude 等你输入——权限确认、空闲等待、任何需要你介入的时刻——自动弹：

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

放 ~/.claude/settings.json。这个要全局生效。

2. Claude 碰过的文件自动格式化

每次 Edit 或 Write 之后跑 Prettier。Claude 逐文件改代码导致的格式不一致，一劳永逸：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

需要 jq 做 JSON 解析，macOS 上安装：

brew install jq

放项目的 .claude/settings.json 并提交。这是团队规范。

3. 不让 Claude 碰受保护文件

拦住 .env、package-lock.json、.git/。被拦后 Claude 会收到反馈说明原因：

#!/bin/bash
# .claude/hooks/protect-files.sh

INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

PROTECTED_PATTERNS=(".env" "package-lock.json" ".git/")

for pattern in "${PROTECTED_PATTERNS[@]}"; do
  if [[ "$FILE_PATH" == *"$pattern"* ]]; then
    echo "Blocked: $FILE_PATH matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

chmod +x .claude/hooks/protect-files.sh，然后注册：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

4. 压缩后把上下文填回去

上下文窗口满了，Claude 会压缩对话总结。有时候重要细节被丢掉了。这个 Hook 在每次压缩后触发，提醒 Claude 最核心的事：

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Reminder: use Bun, not npm. Run bun test before committing. Current sprint: auth refactor.'"
          }
        ]
      }
    ]
  }
}

echo 换成动态命令也行：git log --oneline -5 看最近提交，或 cat .claude/sprint-context.md 加载独立上下文文件。

5. Git 提交强制规范

Claude 有时候按自己喜好写 commit message——type 前缀不对、用了句子大小写、末尾拖个句号。这个 Hook 在提交落地前拦一道：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Look at tool_input.command. If it does NOT start with 'git commit', return {\"ok\": true}. If it is a git commit command, extract the commit message and check only the FIRST LINE (subject line) — ignore any body lines after the first newline. Check: (1) format is 'type: Capitalized description' where type is one of feat/fix/refactor/docs/chore/perf/revert, (2) description starts with a capital letter, (3) no trailing period, (4) no 'Co-Authored-By' trailer anywhere in the command. Return {\"ok\": false, \"reason\": \"[specific issue. Corrected subject line: type: Description]\"} if any check fails. Return {\"ok\": true} if all pass."
          }
        ]
      }
    ]
  }
}

这是 Prompt Hook——不写 shell 脚本，不写正则，让 Haiku 模型读命令、对照你的规范判断，直接返回结果。

放 ~/.claude/settings.json，所有项目生效。

退出码怎么用

Hook 脚本通过三个通道和 Claude Code 通信：

Stdout 会被加入 Claude 的上下文中，适用于 SessionStart、UserPromptSubmit 这些 hooks。

Stderr 当你以退出码 2 退出时，会显示给 Claude。

Exit code 决定接下来发生什么：

• 0 → 继续执行
• 2 → 阻止当前动作，stderr 中的消息会作为反馈传给 Claude
• 其他退出码 → 继续执行，stderr 会被记录下来，可以通过 Ctrl+O 查看

PreToolUse Hook 真正的威力就靠这个退出码体系。你的脚本读到 Claude 即将执行的操作，对照规则判断，要么放行，要么返回具体原因。

三步上手

第一步：全局加通知 Hook

打开 ~/.claude/settings.json，贴上面 macOS 通知的配置。最实用、零风险，纯附加行为，不拦截任何东西。让 Claude 做一件会触发权限确认的事，看看弹没弹。

第二步：当前项目加 Prettier 格式化

在项目根目录打开 .claude/settings.json（没有就新建），加 PostToolUse 格式化 Hook。没装 jq 先装。让 Claude 改个文件，确认自动格式化了。

第三步：打开 /hooks 翻一翻交互菜单

列出全部事件和说明。想想你的工作流里还有哪些可以自动化。Stop 事件（Claude 完成后跑测试）和 PreToolUse（拦截特定模式）是下一个选择。

没有 Hook 时，你可能需要结束后追问和检查：格式化做了吗？测试跑了吗？代码提交了吗？

配置 Hook 之后，这些问题解决。格式化一定会执行，测试一定会运行，通知一定会弹出。它们不再依赖 Claude 是否记得、是否理解、是否照做，而是变成项目环境本身的默认行为。

不要把关键流程寄托在 prompt 约束上。应通过环境机制强制执行关键动作，确保它们在每次运行中稳定执行。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

OpenAI内部怎么用Codex？一份真实使用报告

Codex这玩意，可能很多人还在观望，觉得是不是又是个噱头大于实用的PPT产品。

但你知道吗，OpenAI自己那些写代码的工程师——安全团队、产品团队、前端团队、API团队、基础设施团队、性能工程团队——他们每天就在用这东西干活。

最近他们访谈了一批工程师，也调了内部使用数据，搞了一份挺实在的总结。我看完之后最大的感受是：

这东西不是玩具，是真的在改变开发节奏。

先说一个数据点（虽然原文没给具体数字，但描述了覆盖范围）

几乎每个技术团队都在用，从入职上手到紧急故障排查，从重构大型代码库到交付新功能，渗透得相当深了。

那么具体在干什么呢，他们总结了七个场景。

代码理解

这个是最基础的用法。

刚接手一个不熟悉的代码库，Codex能快速帮你定位核心逻辑，梳理模块之间的关系，追踪数据在系统里的流转过程。

它甚至能识别出架构模式，或者文档缺失的部分——这些东西以前你得专门花时间整理，现在问一句就行。

事件响应的时候尤其有用。

故障状态怎么传播的，组件之间怎么交互的，这些平时得翻好几个文件才能搞清楚的东西，Codex直接给你呈现出来。

有个检索系统的性能工程师说了一句话，我觉得挺真实：

每当修复一个漏洞，我都会用询问模式，检查代码库中是否还存在同类问题。

你想想看，这场景多常见。修了一个，心里犯嘀咕——其他地方还有没有类似的？以前得grep半天，现在直接问。

还有个API平台的值站工程师：

值班的时候我直接粘贴堆栈跟踪，问Codex身份验证流程的位置，它就跳到对应文件了，不用我自己一点点找。

基础设施服务的DevOps工程师说得更直接：

跨Terraform和Python仓库的功能定位问题，Codex比grep效率高太多了。

几个示例提示词参考：

• 此仓库中的身份验证逻辑是在哪里实现的？
• 梳理请求在本服务中，从入口到响应的完整流转流程。
• 哪些模块与[插入模块名称]存在交互，异常故障又是如何处理？

重构与迁移

这个场景在我看来是最体现Codex价值的。

当你要在几十个文件里做同样的修改——比如更新API、改变模式实现方式、迁移到新依赖项——传统做法是逐个文件手动改，或者写一堆正则替换，但有些结构性的改动正则根本搞不定。

Codex能统一处理这些，而且它能识别那些查找替换工具无法捕捉的依赖关系。

还有个高频用法是代码清理：拆大模块、替换旧模式、提升可测试性。

ChatGPT网页版的后端工程师说了一件事：

Codex把所有的旧版getUserById()替换成了新的服务模式，还创建了PR。原本需要几个小时的工作，现在只要几分钟。

这里有个细节，他说的不是「帮我写代码」，而是「帮我做了本来要花几小时的活」。

ChatGPT Enterprise的产品工程师也分享了类似的思路：

发布前我让Codex扫描所有旧代码范式的实例，用Markdown汇总影响范围，再提交包含修复方案的PR。

不是让它直接改，而是先让它做分析，再让人来审核。这种人机协作的模式挺健康的。

几个示例提示词：

• 按业务职责拆分当前文件为独立模块，并为各模块生成对应测试。
• 将所有基于回调的数据库访问转换为async/await。

性能优化

Codex能分析运行缓慢、内存密集型的代码路径——低效循环、冗余操作、高开销查询——然后给出优化建议。

有个点值得注意：他们用它来减少长期技术债，主动预防回归问题。

也就是说，不只是「这段代码跑得慢我来修一下」，而是「哪些高风险模式还在用，哪些已经弃用的方法还在被调用」，Codex能帮你识别出来，主动清理，而不是等到出问题再救火。

三个示例提示词：

• 优化此循环以提高内存效率，并说明你的版本更快的原因。
• 找出此请求处理程序中的重复高开销操作，并给出可使用缓存的优化建议。
• 建议在此函数中更高效地批量查询数据库的方法。

提升测试覆盖率

这个场景特别有意思。

测试覆盖率不足或者完全没有测试的代码库，是很多团队的痛。Codex可以根据函数签名和周边逻辑生成单元测试或集成测试，而且它特别擅长识别边界条件——空输入、最大长度、不常见但合法的状态。

这些边界情况在初始开发时最容易忽略，Codex能帮你补上。

ChatGPT桌面版的支付与账单团队工程师说了一句话，我看完笑了：

夜间让Codex处理覆盖率偏低的代码模块，第二天醒来就能拿到可直接运行的单元测试PR。

这画面太真实了。

睡前丢任务，醒来收成果。不是说他不干活，而是这些机械性的补测工作不用再占用他的时间了。

三个示例提示词：

• 为此函数编写单元测试，覆盖边界场景与失败路径。
• 为该排序工具生成基于属性的测试。
• 扩充测试文件，以补充空输入与无效状态等缺失场景。

提升开发速度

这个场景分两部分看。

前期启动的时候，用Codex搭样板代码框架——生成文件夹、模块、API存根，快速产出可运行代码，不用手动逐一配置关联。这意味着什么呢？当你拿到一个需求的时候，框架层面的东西不用从零堆，直接让AI给你生出来，你再往上填业务逻辑。

后期收尾的时候，它处理那些「细小但关键」的活——分类排查漏洞、补齐开发缺口、生成发布脚本、遥测钩子、配置文件。这些东西不复杂但琐碎，很容易在deadline前成为卡点。

还有个用法我觉得挺聪明的：把产品需求反馈直接转成初始代码。

工程师会粘贴用户需求或规格说明，让Codex生成代码初稿，然后自己再完善优化。这相当于多了一个「第一版不用你写」的助理。

ChatGPT Enterprise的内部工具工程师说了一句话，信息量很大：

我一整天都在开会，依旧合并了4个PR，全靠Codex在后台自动处理工作。

注意这个比例。一整天开会，还能合并4个PR。不是说他摸鱼，是Codex在帮他做那些本该占用开发时间的事。

三个示例提示词：

• 为POST /events搭建新的API路由，并添加基础验证和日志记录。
• 使用此模板[插入你的遥测代码示例]生成一个遥测钩子，用于跟踪新引导流程的成功/失败状态。
• 根据此规范创建一个存根实现：[插入规范或产品反馈]。

保持专注高效

这个场景解决的是日程零散、频繁被打断的问题。

工程师的日常往往不是「一整块时间写代码」，而是会议、值班、临时插进来的需求，各种打断。Codex能帮你在这种环境下维持稳定产出。

具体能做什么呢？记录未完成的工作，把笔记转成可运行的原型，拆解出可以之后再继续处理的探索性任务。这样你被打断之后，不需要从头回忆，直接接上。

有个ChatGPT API的后端基础设施工程师说得很实在：

遇到随手小修复需求时，我直接下发Codex任务，无需手动切换分支，空闲时审核它生成的PR即可。

这句话里有两层意思。第一层是「不用切换分支」，意味着上下文切换成本被降低了。第二层是「空闲时审核」，意味着他的时间没有被碎片化，小修小补的事让Codex先跑着，他集中处理重要的事。

探索与创意构思

Codex不是只能做执行层面的事，它也适合开放性工作。

比如你想探索替代方案，可以问它「如果系统采用事件驱动而不是请求/响应模式，它会如何运作」。这相当于有了一个可以随时讨论的设计助手。

它还能帮你验证设计决策——给多个思路让Codex分析，看看取舍在哪里，拓宽选择面。

还有一个很实用的场景：排查关联漏洞。针对已知问题，Codex能识别代码中其他相似写法，防止「只修了一个但其他地方还有同样问题」的回归。

ChatGPT桌面版的检索系统产品工程师说了一个典型场景：

Codex帮助我解决了冷启动问题——我粘贴规格说明和文档，它生成代码框架，或者指出我遗漏的地方。

这里的核心是「冷启动」。当你面对一个陌生领域不知道从哪下手的时候，Codex能给你一个初始结构，不是最终答案，但是能让你动起来。

三个示例提示词：

• 如果系统采用事件驱动而不是请求/响应模式，它会如何运作？
• 找出所有手动构建SQL字符串而非使用我们的查询构建器的模块。
• 将代码改写为更标准的函数式风格，避免数据变更与副作用。

最佳实践

光有场景不够，他们还总结了一些使用习惯，能帮你把Codex用得更好。

从「询问模式」开始。

对于大规模改动，先在询问模式下获取实施方案，确认方向没问题了再切换到代码模式执行。这种两步式流程能让输出更贴合实际，减少做无用功。

还有一个参考标准：Codex最适合范围清晰的任务，这类任务一般耗时约一小时、或者需要写几百行代码。随着模型能力提升，它能承接的体量会越来越大。

持续优化开发环境。

配置启动脚本、环境变量、网络访问权限，能显著降低Codex的出错概率。遇到构建错误的时候，留意是不是可以通过调整配置来修复。这个过程需要迭代，但从长期看回报很可观。

像写GitHub Issue一样组织提示。

按照你在PR或Issue里描述变更的方式来写，Codex的回复效果更好。必要的时候附上文件路径、组件名称、代码差异、文档片段。「参照[module X]模块的方式实现该功能」这种句式能显著优化生成效果。

用任务队列做简易清单。

随时新建任务，记录零散想法、未完成的工作、临时小修复。不需要强求一次性生成完整PR，Codex可以作为工作暂存区，方便恢复专注后继续处理。

维护AGENTS.md文件提供持续上下文。

这个文件包含代码本身无法让Codex自行推断的内容——命名规范、业务逻辑、特殊规则、依赖关系。它能帮助Codex在不同提示下保持高效运行，不用每次都从头解释背景。

使用”Best of N”提升输出效果。

对于复杂任务，一次性生成多份结果，便于快速比对，择优选用。或者整合不同版本的优势部分，形成更完善的方案。

写在最后

这份报告最让我有感触的，不是某一个具体场景有多厉害，而是「渗透程度」。

从代码理解到重构迁移，从性能优化到测试覆盖，从开发加速到保持专注，再到探索构思——几乎覆盖了一个工程师日常工作的全链路。

而且这些不是「理论上的可能」，是OpenAI内部真实在用的，有工程师的具体反馈，有明确的效率提升案例。

他们说Codex目前还处于研究预览阶段，但从实际效果来看，已经在切实改变他们的研发模式了。加快开发节奏、编写更优质代码、承接以前难以排期的工作——这些都不是空话。

Codex最核心的价值，我理解是两层。

第一层是把「机械性、重复性」的工作自动化，让工程师把精力放在真正需要判断力和创造力的事情上。

第二层是在「上下文切换」这件事上提供了缓冲，让时间碎片化不再那么致命。

这两层都指向同一个结论：AI编程工具已经过了「能不能用」的阶段，进入「怎么用好」的阶段了。

就看你愿不愿意认真对待这件事了。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

OpenAI正在为 Agents SDK 引入全新功能，旨在为开发者提供一套标准化且易上手的底层架构

在人工智能快速渗透各行各业的当下，构建一个真正实用的AI智能体，仅有一流的大模型远远不够。开发者们迫切需要一套完备的基础设施，来支撑智能体执行文件审查、运行指令、编写代码以及跨步骤的长效协作。然而现实情况是，从原型开发迈向生产环境的道路上，开发者们往往面临各种艰难的权衡：模型无关框架虽然灵活，却无法充分释放前沿模型的性能潜力；模型厂商提供的SDK虽然契合度更高，但对运行框架内部的可见性往往不足；而托管型智能体API虽简化了部署，却限制了智能体的运行环境及对敏感数据的访问权限。

今天，OpenAI正式推出了Agents SDK的全新升级，旨在为开发者提供一套专为OpenAI模型量身打造的标准化底层架构。这套架构包含模型原生运行框架（model-native harness）和原生沙箱执行环境两大核心模块，前者支持智能体在计算机上跨文件、跨工具作业，后者则确保各类任务运行的安全性。换句话说，开发者现在可以更加专注于构建智能体的业务逻辑，而将繁琐的核心架构维护工作交给SDK来处理。

为什么智能体需要更好的基础设施

理解这次升级的意义，首先需要看清当前智能体开发面临的核心困境。

在实际生产环境中，一个有价值的智能体往往需要同时处理多种复杂任务：读取和分析文档、执行系统命令、编写和运行代码、与外部工具进行交互——这些操作横跨多个系统，需要在长周期任务中保持状态的连贯性。传统的开发方式存在明显的局限性：开放框架虽然给了开发者最大的自由度，却难以针对特定模型进行性能优化；厂商提供的SDK虽然与模型契合，但运行框架黑盒化导致调试困难；托管服务虽然开箱即用，却在安全性和灵活性上大打折扣。

这种种权衡反映出一个根本问题：智能体需要一个既能得到模型深度优化、又能提供足够可见性和控制力的运行框架。OpenAI此次发布的Agents SDK，正是为了解决这一痛点。

更强劲的智能体循环运行框架

升级后的Agents SDK运行框架为处理文档、文件和系统的智能体提供了显著增强的能力。该框架目前已集成可配置记忆模块、沙箱感知编排功能、类Codex的文件系统工具，以及针对前沿智能体系统常用原语（primitive）的标准化集成。

具体而言，这些原语包括：

• 工具使用：通过MCP（Model Context Protocol）实现与外部工具的标准化连接
• 技能（Skill）：通过Agents Skills实现渐进式功能披露
• 自定义指令：通过AGENTS.md文件定义智能体行为规范
• 代码执行：通过Shell工具运行系统命令
• 文件编辑：通过Apply Patch工具进行批量文件修改

这套框架的核心理念是让执行方式与前沿模型的最佳性能模式对齐，从而帮助开发者进一步释放模型潜力。这种设计使智能体能更贴合模型的“自然运行模式”，在执行复杂任务时——尤其是那些需要跨多种工具系统协作的工作或长周期任务——表现出更卓越的可靠性与性能。

同时，Agents SDK在设计之初就充分考虑了多样性和灵活性的需求。它为开发者提供了一个既能开箱即用、又具备高度定制空间的运行框架，支持开发者根据自身技术栈轻松配置工具调用、记忆模块及沙箱环境。

原生沙箱执行环境

升级后的Agents SDK现已原生支持沙箱执行，这意味着智能体可以在受控的计算机环境中运行，并配备任务所需的全部文件、工具及依赖项。

对于许多实用的智能体而言，一个能够安全读写文件、安装依赖、运行代码及调用工具的工作空间至关重要。原生沙箱支持为开发者直接提供了这一执行层，无需再费力自行搭建。开发者既可以接入自有的沙箱环境，也能直接使用SDK支持的第三方平台，包括Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop以及Vercel等主流服务商。

为了确保环境在不同服务商之间具备可移植性，SDK还引入了Manifest抽象层来定义智能体的工作空间。开发者可以挂载本地文件、定义输出目录，并从AWS S3、Google Cloud Storage、Azure Blob Storage及Cloudflare R2等云存储服务商处导入数据。这套方案为开发者提供了一种标准化的方式，助力智能体从本地原型平滑过渡到生产部署。

运行框架与算力的解耦

在设计智能体系统时，安全性和可扩展性是必须预先考虑的核心问题。OpenAI此次架构升级的一个重要设计理念，是将运行框架与算力环境解耦，从而实现多重安全保障。

首先是安全性保障。通过这种解耦设计，可以有效确保凭据等敏感信息不会泄露至执行模型生成代码的环境中，有效防范提示注入（prompt-injection）和数据外泄（exfiltration）的潜在风险。

其次是持久性保障。由于智能体的状态已被外部化，即使沙箱容器发生宕机，也不会导致整个任务运行失败。凭借内置的快照（snapshotting）与重构（rehydration）机制，Agents SDK可以在原环境失效或过期时，在全新的容器中精准恢复智能体状态，并从最后一个检查点继续运行。

最后是可扩展性保障。在执行任务时，智能体可以灵活调用一个或多个沙箱，仅在必要时激活环境，将子智能体（sub-agent）路由至隔离环境中，并通过跨容器的并行作业来显著提升执行效率。

代码示例：构建一个数据分析师智能体

为了帮助开发者更直观地理解新SDK的使用方式，以下是一个完整的示例代码，演示了如何构建一个数据分析智能体：

# pip install "openai-agents>=0.14.0"

import asyncio
import tempfile
from pathlib import Path

from agents import Runner
from agents.run import RunConfig
from agents.sandbox import Manifest, SandboxAgent, SandboxRunConfig
from agents.sandbox.entries import LocalDir
from agents.sandbox.sandboxes import UnixLocalSandboxClient

async def main() -> None:
    with tempfile.TemporaryDirectory() as tmp:
        dataroom = Path(tmp) / "dataroom"
        dataroom.mkdir()
        (dataroom / "metrics.md").write_text(
            """# Annual metrics

| Year | Revenue | Operating income | Operating cash flow |
| --- | ---: | ---: | ---: |
| FY2025 | $124.3M | $18.6M | $24.1M |
| FY2024 | $98.7M | $12.4M | $17.9M |
""",
            encoding="utf-8",
        )

        agent = SandboxAgent(
            name="Dataroom Analyst",
            model="gpt-5.4",
            instructions="Answer using only files in data/. Cite source filenames.",
            default_manifest=Manifest(entries={"data": LocalDir(src=dataroom)}),
        )

        result = await Runner.run(
            agent,
            "Compare FY2025 revenue, operating income, and operating cash flow with FY2024.",
            run_config=RunConfig(
                sandbox=SandboxRunConfig(client=UnixLocalSandboxClient()),
            ),
        )
        print(result.final_output)

if __name__ == "__main__":
    asyncio.run(main())

这个示例展示了一个典型的数据分析场景：开发者首先创建受控的工作空间并写入数据文件，然后初始化一个沙箱智能体并为其分配必要的工具和数据目录，最后通过自然语言指令让智能体完成数据分析任务。整个过程体现了Agents SDK的核心设计理念——提供标准化、模块化的基础设施，同时保持足够的灵活性。

来自合作伙伴的验证

新SDK的能力已经得到了多家合作伙伴的实际验证。在法律领域，Oscar Health和LexisNexis等机构正在进行深度测试。在金融领域，FurtherAI和Thomson Reuters正在探索其在复杂文档处理中的应用。协作领域则有Zoom和Tomoro AI等合作伙伴。

Harvey应用研究负责人Niko Grupen分享了他的使用体验：

“GPT-5.4为处理大量文档的法律工作树立了新标杆。在BigLaw Bench评估中，它获得了91%的评分。与其他模型相比，GPT-5.4目前在构建复杂的交易分析、保持长篇合同准确性，以及提供法律从业者所需的高精度细节方面表现更佳。”

这一评价表明，当优秀的模型与完善的运行框架相结合时，智能体能够在专业领域展现出真正的实用价值。

定价与可用性

目前，Agents SDK的这些全新功能现已面向所有API用户开放。定价方案沿用标准API计费模式，根据Token使用量及工具调用次数进行结算。

未来展望

在Agents SDK的持续迭代中，OpenAI将不断拓宽其应用边界，助力开发者以更轻量化的基础设施，将性能更强的智能体投入生产，同时始终保障开发者所需的灵活性与掌控力。

目前，全新的运行框架与沙箱功能已率先在Python版本中上线，TypeScript支持也已列入发布计划。此外，包括代码模式和子智能体在内的更多智能体功能也将逐步引入这两个语言版本。

展望未来，OpenAI希望进一步推动智能体生态的深度融合：通过支持更多的沙箱服务商、提供更丰富的集成方案，以及探索更多元化的接入方式，让开发者能够将SDK无缝嵌入其现有的工具链与系统之中。

核心要点总结：

• 模型原生运行框架：专为OpenAI模型优化，支持跨文件、跨工具作业，集成MCP、技能、AGENTS.md等标准化原语
• 原生沙箱执行环境：提供受控工作空间，支持多平台部署，通过Manifest抽象层实现环境可移植性
• 架构解耦设计：确保安全性、持久性与可扩展性，支持快照恢复和跨容器并行作业
• 可用性：现已面向所有API用户开放，Python版已上线，TypeScript版开发中

原文媒体

Codex 从零基础到精通

曾经，让一个完全不懂代码的人独立完成一个网站、一款 APP、一款小程序——这是天方夜谭。

但现在，AI 编程工具已经把这个不可能变成了可能。

我叫二师兄，是一个计算机小白。过去一年，我陆陆续续用过了 Cursor、Trae、Claude Code，以及本文的主角——Codex。说实话，作为一个连代码都没写过几行的人，我从没想过自己能做出那些「只有程序员才能完成的东西」。

但 AI 工具让我做到了。

止步于 demo 阶段也好，走了无数弯路也罢，这些工具给我带来的正反馈是真实的。更重要的是，在这个过程中，我积累了一些新手小白接触 AI 编程的经验。

今天这篇教程，就是想把我的经验系统地整理出来。如果你也是零基础，但想用 AI 编程工具做出自己的产品，这篇内容或许适合你。

一、为什么是 Codex？

过去半年，我一直深度使用 OpenClaw 和 Codex。最大的感受是：AI 编程工具已经不再是纯粹的编程工具，而是一个能够真正替你做事情的得力助手——或者说，一个大脑外挂。

它可以帮你写代码、调试、解释逻辑、优化架构。你不需要懂每一行代码在做什么，只需要说清楚你想要什么。

但问题也出在这里。

很多时候它会帮你搞砸事情，不是因为它不够聪明，而是因为你没有说清楚需求——或者，你根本没有能力说清楚需求。

这才是新手最核心的问题。

二、新手最容易踩的三个坑

根据我的观察，零基础用户在使用 AI 编程工具时，最容易遇到以下三种困境：

1. 需求描述不清，导致无限返工

你想做一个网站或 APP，但对自己想要什么只有一个模糊的感觉。技术栈说不清，功能要求也描述不清楚。

结果就是：AI 输出了一堆代码，你看不懂，又提不出修改意见，于是反复来回，最终什么都没做成。

2. 遇到报错，无法准确描述问题

代码跑不通，报错了。你想求助 AI，但只能截图或者复制粘贴错误信息，无法用专业术语描述问题。

于是 AI 给出的解决方案要么不准确，要么你需要花大量时间反复沟通才能接近正确答案。

3. 产品需求沟通不足，永远停留在 demo 级别

你想实现某个业务流程，但和 AI 对产品需求的沟通不够深入。结果产出了一个看起来还不错、但完全无法投入使用的「半成品」。

这三个坑，我全部踩过。所以我把经验总结成教程，希望能帮你少走弯路。

三、这篇教程能给你什么？

本教程专注于指导如何正确使用 Codex这款 AI 编程工具，不探讨任何登录境外服务的渠道与技术。

教程中涉及的 PPT 图片由 Codex 和 OpenClaw 使用 GPT-Image 2.0 生成。某些案例目前尚未配图，后续会逐步更新。

教程的全部内容均为公开免费资源。未经允许，拒绝任何形式的转载和售卖。

如果你在阅读过程中有任何疑问，或者发现内容有误，欢迎通过评论批注告诉我，我会及时回复和纠正。

四、关于我自己

我不是程序员，也不是产品经理。

我只是一个对技术充满好奇的普通人。过去一年，我把无数个「灵机一动」转化成了可见的形态——虽然大多停留在 demo 阶段，但这些尝试让我深刻体会到：AI 编程工具的价值，不是让程序员更高效，而是让非程序员也能创造。

这也是我写这篇教程的初衷——把失败中摸索到的经验记录下来，帮助更多和我一样的普通人。

五、学习建议

如果你刚刚开始接触 Codex，以下几点经验或许对你有帮助：

• 从小处着手：不要一上来就想做一个完整的 APP，先从一个简单的页面、一个基础的功能开始。
• 学会提问：把你想做的事情尽可能描述清楚，包括背景、目标、约束条件。AI 的输出质量很大程度上取决于你的输入质量。
• 保留记录：把你和 AI 的对话保存下来，当作你的「错题本」。下次遇到类似问题，效率会高很多。
• 接受不完美：AI 输出的代码不可能一次性完美，学会迭代和调整才是关键。

如果你觉得这篇教程有帮助，请点赞并转发给身边有需要的朋友。

有任何问题，欢迎在评论区告诉我。

我们下期见。

教程全部内容为公开免费资源，未经允许禁止转载和售卖。

如何用好Codex

很多人在用AI编程助手的时候，其实只发挥了它两成功力。

怎么讲？就是那种「写代码、检查、提PR」的固定套路，来了走走了来，每次都像第一次见面。这也不能怪大家，因为AI助手刚出来那会儿，确实就是这么用的。

但你有没有想过一个问题——你在电脑上干的那些事，有几样是跟代码完全没关系的？

打开终端敲命令，是代码。 浏览网页，是代码。 发Slack消息，是代码。 导出一份文档，是代码。 响应一个事件触发自动化，还是代码。

你发现没有，所谓「写代码」这件事，其实只是冰山露出水面的那一角。Codex真正的能力，藏在水面下面那些你可能从来没让它碰过的领域。

这篇文章，不讲怎么让它帮你写函数。我们聊点更野的——怎么把这玩意儿变成一个真正能帮你扛活的「全能打工人」。

持久对话流，才是真正的资产

先说一个大多数人踩过的坑：每次打开对话，恨不得从盘古开天地讲起。「我的代码库在xxx，架构是yyy，技术栈是zzz，我们团队五个人……」

讲完这些，人已经累了。

Codex现在支持一种叫「持久对话流」的东西，你可以理解成给它装了一个长期记忆。聊天记录不再是一次性的，对话流会记住你们之前做过的决定、你个人的偏好、项目当前卡在哪一步。

怎么用？置顶它。

Command-1到Command-9，按下去直接穿越回某个专属对话流继续干活。一个「幕僚长」对话流处理日常杂务，一个专门盯产品发布，一个负责审查文档，一个盯着外部数据。

它们不是那种聊完即焚的对话框，而是持久的工作空间。随着时间推移，Codex可以随时回来，它记得你之前定的方向，记得谁负责哪个模块，记得上次卡在哪个接口文档没写完。

这听起来好像没什么，但用过之后你会发现——以前那种每次从零开始的痛苦，突然就没了。

语音输入这个功能，被严重低估了

Codex内置了语音输入。坦率的讲，这个功能我用到现在，最大的感受是：它能捕捉到你脑子里最原始的那个念头。

不是你想好怎么表达的那个，是那个你还没组织好语言的、有点模糊的、乱七八糟的想法。

比如：

我记得有个叫Ben的人在Slack上提过这事儿。 细节我忘了。 你去帮我找找看。

说真的，你让一个人类同事帮你干这事，你得打多少字？但对于一个会自己搜索、收集上下文然后汇报给你的AI来说，这几句话够了。

有时候脑子里有个大概方向但还没成型，对着它碎碎念两三分钟，把思绪一股脑倒出来，效果出奇的好。那些犹豫的语气、强调的重点、没讲完的灵光一现，往往比一份精炼的总结更有价值。

录音转写也是这个道理。一份未经修饰的会议记录，比一份短总结有用得多。

任务干预和排队，这是两码事但都救命

当你把语音输入和对运行中任务的直接控制结合起来的时候，威力才真正显现。

先说「任务干预」。

就是字面意思：AI正在跑任务，你中途打断它，给它一个新方向。这玩意在什么场景下最好用？你发现它跑偏了，得在它撞南墙之前拉回来。

比如，你在让它审查一个网站，一边在侧边栏指指点点一边直接开口打断：

把这个调小一点。 这两个元素之间的间距不太对劲。 这句文案写错了。

Codex会接收这些指令，在当前任务里直接响应。不需要等它跑完，不需要开一个新的对话，不需要解释上下文。

然后是「任务排队」，这个不太一样。

排队不会打断正在进行的任务，而是把新任务放在队伍后面。你可以这么说：

等这活干完了，把预览链接发到Slack给审核人看看。

简单讲，「干预」是改变它眼下正在做的事，「排队」是安排它接下来要做的事。前者是踩刹车，后者是挂挡。

两种能力叠加，你就获得了一种人机合一的掌控感——不是那种「点了发送然后不知道它会干嘛」的失控状态，而是始终知道它在干什么、随时可以接管方向盘。

它的手能伸到哪？

持久对话流解决了记忆问题，接下来一个问题就是：它能碰到什么？

Codex的触角现在可以向外延伸好几层。

@browser是内置浏览器，适合在侧边栏审查网页、做标注。

@chrome可以获取你Chrome浏览器的登录状态，处理那些需要账号登录信息的浏览器内工作流。

@computer专门搞定那些只能通过桌面图形界面完成的任务——就是那种必须得在桌面上点来点去的活儿。

三个工具各有各的地盘：browser适合做网页审查和预览；chrome适合需要你账号登录状态的自动化浏览器操作；computer是最后的兜底方案，桌面GUI的事儿都找它。

然后是MCP服务器和各类连接器。这个是Codex能力延伸的关键一步。

Slack集成、各种MCP工具连接器之所以重要，是因为很多关键任务在变成代码之前，最初往往只是一条聊天消息、一封邮件，或者一个日程安排。当Codex能接入这些工具的时候，它就不再只是一个「写代码的」，而是一个真正能帮你处理日常工作的角色。

还有技能（Skills）。当某个工作流被验证好用之后，你可以把它固化成技能，下次Codex直接跑通，不需要从头教它一遍。这个对重复性高的任务特别有价值。

你不在电脑前的时候，它还在干活

这是我觉得最有意思的一个能力：随时随地与Codex协同。

一个任务可以在你装满文件、权限和本地环境的Mac上启动，然后当你离开工位、用手机查看时，它依然在默默推进。

场景是这样的：你让Codex在电脑上跑一个耗时的任务，自己去喝咖啡。在外面的时候它有问题问你，你直接手机回复、批准它的下一步行动，或者在回座位前就给它指派新的方向。本地环境安安静静地跑着，人却可以自由移动。

这打破了「必须坐在电脑前才能干活」这个传统限制。

自动化：让它自己跑，别盯着了

自动化功能让Codex可以按照你设定的时间表自动干活。这里有两种模式：

定时自动化适合每天从零开始的例行任务——生成日报、跑代码库检查。但如果需要在一个带有历史记忆的对话中继续推进，那就用对话流自动化。

对话流自动化像一种定时唤醒的「心跳」机制。它会按照设定的时间表，定期回到同一个Codex对话流里继续工作。

把对话流置顶是很好用，但说到底它还是等你回去找它。而对话流自动化可以每隔几分钟或几小时自己去查岗，一直跑到满足某个条件为止。

举一个具体的例子，你的「幕僚长」对话流可以每30分钟跑一次：

每30分钟，去查一下我的Slack和Gmail里有没有需要处理但还没回的消息。 帮我排个优先级。 如果有人向我提问，尽可能深入查资料，然后帮我起草一份回复，但不要直接发送。

等你回到电脑前，最耗时耗力的「收集背景资料」的工作已经做完了。你只需要做最后拍板发出去的决定。

对话流自动化也特别适合处理反馈循环。它可以默默盯着代码合并请求、Google文档或者Slack里的评论，趁你不在的时候自动推进后续的修改工作。

想象一个动画制作的场景：审核人在Slack发了一条视频意见。对话流自动化定时检查讨论进度，一旦有修改意见进来，自动渲染一版新的，然后在原贴里艾特审核人并发上新视频链接。如果某个软件的集成接口没法自动完成最终上传，它甚至能调动电脑桌面自动化，通过图形界面把最后一步走完。

整个闭环跨了三个系统——接收反馈的Slack、负责渲染的代码库、负责最终上传的桌面自动化工具。

目标设定：画一条终点线

当一个任务有一个清晰的终点线、Codex可以不断朝着那个终点努力的时候，目标的威力就彻底爆发了。

一个糟糕的目标是这样定的：「把这个Markdown文件里的计划实现一下。」

就这一句话。没有标准，没有终点，没有信号。

那什么是一个好的目标？它必须有一个可以被衡量的成功标准。

比如，一位工程师想把一个内部工具从Python迁移到Rust，他可以建好新目录，设定好目标，然后画一条明确的终点线：

直到所有单元测试全部通过，这个新版本的开发才算完成。

目标设定本质上是把「持续执行」和「验证器」结合在一起。你来定义想要的结果和何时停止的条件，然后给Codex一个信号，让它知道有没有离终点更近。

好用的验证器包括：一套完整的测试用例、一项基准性能测试、一个能稳定复现的Bug、一个验证矩阵，以及一个必须始终跑通的端到端工作流。

有野心当然重要，但没有验证机制的野心，就只是在许愿而已。

侧边栏——不用切来切去了

侧边栏这个功能很多人忽略了，但它其实非常好用。

它让生成的工作成果始终和对话窗口并排在一起。你再也不用把文件导出来，然后在不同软件之间痛苦地切来切去。生成的成果可能是代码，也可能是幻灯片、PDF文件、网页、表格，或者任何其他东西。

它特别擅长处理四种工作：检查生成的文件、标注需要修改的地方、操作网页界面、审查代码或文件的变更。

而且应用内浏览器让Codex可以直接检查渲染好的网页，控制它，甚至直接响应你在网页上做的标注。对网页或文件的评论全部留在这个工作闭环里，不用像以前那样拆成一个个单独的交接任务。

网页既变成了它的输出结果，也变成了你可以操控的控制面板。Codex可以建好一个页面，在侧边栏打开它，自己检查它，修Bug，然后原地不断迭代优化同一个东西。

下面这些场景配合侧边栏尤其好用：

用单个index.html做轻量级静态展示。跑Storybook审查UI组件。用Remotion Studio做代码生成的动画。在浏览器里放映的幻灯片演示。用于数据分析流的数据应用。

一个简简单单的index.html文件就能变成一个交互式小应用，服务器都不用搭。而且对话流自动化还能随着时间推移悄悄更新这些静态文件，等你回来时总能看到最新进展。

共享记忆：让上下文真正持久

当长时间运行的对话流能够打破单次聊天的界限，把记忆共享出去时，它们的作用会发生质的飞跃。

一个相对稳妥的做法是把这些持久对话流「锚定」在一个Obsidian知识库里。说白了就是建一个存放纯文本文件的文件夹。它简单直白，方便你随时查看、修改、移动，而且能保存很久。团队可以把这个文件夹放在任何喜欢的云盘里——Git、Dropbox、Google Drive都行。

你的知识库可能长这样：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

在最外层目录下放一个AGENTS.md文件。这里定义Codex的运行规则：当它了解到关于人员、项目、决策和待办事项的新情况时，应该如何更新这个知识库。

别死板地照抄某一种知识库结构。你需要做的是「教」你的AI智能体：那些持久的上下文该放在哪，哪些需要保留，以及什么时候不要瞎折腾去改文件。

一份实用的AGENTS.md里可以这么写：

把vault当作你长期的工作记忆区。 尽量把笔记整理得有条理，别搞得到处都是碎片记录。 准确地把待办事项、人员、项目、每日总结和草稿分类放好。 把做过的决定、遇到的卡点、负责人、日期和有用的链接好好保存下来。 如果没有实质性的新进展，不要随意修改知识库里的文件。

代码库是用来存代码的。而这个知识库，是用来存不断滚动的上下文的——牵涉到哪些人、改了什么、卡在哪里、接下来谁跟进，以及那些如果在两次聊天中间断掉就会彻底消失的细节。

重要的上下文绝不应该仅仅锁死在某一次聊天的文字记录里。把它们写下来，放在下一个对话流能够立刻接手的地方。

Codex自己也提供了官方的记忆功能——在设置>个性化>记忆里。它们像是系统自带的本地记事本，用来记住你的个人偏好、常用的工作流和经常踩的坑。不过这个功能是用来辅助你清晰写下来的上下文的，而不是取代它。Chronicle记忆组件也是同样的思路，帮Codex从你最近屏幕上发生的事情中提取并构建记忆。

写到最后我想说一件事。

Codex从诞生到现在，给很多人的印象还是一个「写代码的」。这个标签当然没错，它写代码确实很强。但如果你只让它干这一件事，就像买了一辆越野车然后只在柏油路上开。

现在围绕代码的那些周边工作——MCP服务器、网页界面、电脑桌面控制、对话流自动化、侧边栏直接审查文件——全都可以在同一套系统里搞定。

「任务干预」可以在中途打断它的动作；「任务排队」可以帮它安排好下一步；「对话流自动化」能让你人不在场时系统依然运转；「目标设定」给它画了一条清晰的终点线，让它知道要一直往哪里冲。

今天的Codex已经可以扛起一个完整的工作流：从听取指令、执行任务，到最终文件的审查和迭代。哪怕这些工作远远超出了代码库的范畴，它依然游刃有余。

剩下的，就是看你愿意把多少活儿交给它了。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

最近半年一直在关注 Palantir 的 FDE 模式

2026年5月4日，OpenAI和Anthropic在同一天各自宣布了一件大事。OpenAI联合TPG等19家机构成立了Deployment Company，砸了40亿美元，专门往企业里派工程师帮他们把AI塞进核心业务流程。同一天，Anthropic宣布跟Blackstone、Goldman Sachs、Hellman & Friedman合作，投入15亿美元成立企业服务实体，把Claude部署到中型企业的日常运营中。几天之后，Google Cloud CEO Thomas Kurian亲自发LinkedIn招聘帖，宣布要招数百名FDE。

三家巨头同时下注同一个事情，这在科技行业并不常见。但比这更值得玩味的，是他们在争夺的那个词——FDE，Forward Deployed Engineer，前线部署工程师——在行业里引发的争议。

有人说这是Palantir的看家本领，支撑它从神秘小公司走到千亿市值的秘密武器。也有人说这不过是个硅谷味的造词，本质上就是换了包装的咨询师。还有人说现在大量公司只是在把Solutions Engineer改个title叫FDE，实际上什么都没变。

三种说法听起来都有道理。但这不意味着FDE是个见仁见智的概念——恰恰相反，这说明市面上讨论的压根不是同一个东西。

给FDE一个清晰的定义

过去半年，我把市面上关于FDE的研究整理了一遍。Bob McGrew（Palantir FDE从0到1的亲历者，后任OpenAI VP Research）在YC的访谈，a16z、Sequoia、Flybridge等VC的分析，Palantir官方博客里FDSE的工作日常，Gartner和Everest Group等机构的报告——加起来有6万字。整理完之后，我的结论是：市场对FDE的讨论之所以混乱，是因为至少有两种完全不同的叙事被混在了一起。

先把定义说清楚。

FDE是嵌入客户环境的工程师，背靠一个平台级产品，通过在现场解决客户的真实问题来发现产品应该长什么样。他的工作产物不属于单一客户，而是回流到平台，成为可服务更多客户的产品能力。

这个定义里有四个要素，少了任何一个，它就变成别的东西：

第一，有平台。 没有平台级产品，就没有FDE。这是前提。产品管理领域的教父级人物Marty Cagan说过：“真正让Palantir如此高效、如此有价值的原因，是他们以platform product company的方式来解决这个问题。”没有平台，FDE的工作就是一次性的。

第二，嵌入客户环境。 Forward Deployed，字面意思就是部署到前线。不是远程支持，不是售后回访，是在客户的工作环境里，从内部理解问题。

第三，目的是产品发现，不是实施。 FDE去客户现场不是把一个已知方案装上去，而是去发现“产品应该长什么样”。产品的形态还没有定型，只有在现场解决真实问题的过程中才能被发现。

第四，产物回流平台。 FDE在客户现场做出来的东西，不只是留给这个客户的交付物，而是要回流到平台，成为可服务更多客户的产品能力。

用这四个要素做尺子，很多事情就清楚了。去掉平台，你是咨询师。不嵌入客户，你是传统产品团队。只做实施不做发现，你是系统集成商。产物不回流，你是外包。

试金石：怎么判断真假FDE

FDE这个概念之所以争议这么大，一个重要原因是它的名字被大量滥用。McKinsey在招”Principal Forward Deployment Engineer”，EY在英国推出了FDE岗位，Accenture跟Microsoft、ServiceNow合作搞”Forward Deployed Engineering Program”。这些公司有自己的平台产品吗？没有。他们在做的事情是帮客户用别人的工具做AI转型，产物属于客户，不会回流到任何平台。每个项目从头来，线性增长。

这就是咨询。或者更准确地说，是三种传统角色穿上了新衣服：

咨询型：帮客户规划“你应该用AI做什么”，组合市场上的工具出方案。产出是方案和建议。

实施型：帮客户把某个AI产品部署上线、配好、跑通。产出是一个配置好的系统。

SE换标签型：Pragmatic Engineer的Gergely Orosz观察到，大量公司只是把现有的Solutions Engineer或Solutions Architect改了个头衔叫FDE，工作内容没有任何变化。

三种都不是FDE。因为产物都不回流到任何平台。

那怎么判断一个人到底是FDE还是咨询师？

我有一个暴论：看这个人的成本在公司内部是算产品研发的，还是算项目交付的。 如果是后者，不管你title写的是什么，你就是在做咨询。

VC Thomas Otter说过一句类似的话：“If the FDE is billable, they are working for the project, not the product.” FDE一旦按项目计费，他就是在为项目工作，不是为产品工作。

还有一个更直觉的检验：你的第10个客户跟第1个客户花的精力一样多吗？ 如果是，你就是在做咨询。FDE模式下，每一次客户部署都应该让平台变得更强，下一次部署的effort应该更少。这是一个飞轮，不是一条直线。

a16z合伙人Marc Andrusko的判断很直接：如果你只复制了嵌入式工程师的部分，却没有底下的平台在支撑，最终你不是“某领域的Palantir”，你只是“某领域的Accenture，换了个更好看的前端界面”。

市场数据也在支持这个判断。Paraform的分析显示，FDE岗位在2025年1-9月增长了800%，但合格候选人池只增长了约50%。59%的FDE招聘公司还处于Seed到Series A阶段——这些公司连产品都没完全定型，更需要FDE去前线探索，但也很容易把FDE用成咨询。

FDE是怎么运作的

说FDE是一种方法论而不是一个孤立的岗位，是因为它需要一整套协作方式来支撑。Palantir内部有三个核心角色，共同构成了这套体系：

Echo（回声团队）是嵌入式分析师。 他们来自客户所在的领域：前陆军军官、医疗行业老兵、金融合规专家。但Bob McGrew说了一个关键条件：他们必须是“叛逆者”。他们理解这个行业现在是怎么运作的，但同时认为现状不够好。如果一个Echo觉得“这个行业挺好的”，他永远找不到那个让新软件必须存在的3x-10x的改变机会。

Delta（三角洲团队）是前线工程师，也就是狭义上的FDE。 他们的核心能力是快速做原型。Flybridge与Palantir现任FDE Brian Keohane的讨论得出一个关键结论：“错误的Delta画像是匠人”。追求完美抽象、想写能维护十二年的代码，那不是这个角色的任务。Palantir内部一位FDE负责人Katherine用了另一个说法：“我们更像是一个艺术家社群”。每个FDE的核心能力不同，但共同点是高用户同理心、对商业战略的理解力和创造性解题能力。你要的不是完美代码，而是一个能在客户现场用粗糙但管用的方案快速交付结果的人。

Dev（平台工程师）是留在总部的人。 他们负责开发和维护Palantir的平台产品。他们不去客户现场，但他们的工作直接决定了FDE在前线有多少产品杠杆可用。Palantir官方博客对这两种工程师有一个很简洁的总结：Dev的视角是“一个能力，多个客户”；Delta的视角是“一个客户，多种能力”。

三个角色的关系是：Echo在客户现场找到正确的问题，Delta快速构建解决方案，Dev把前线验证过的方案抽象为平台能力，让下一个Delta去下一个客户时有更强的武器。这是一个完整的循环，不是三个独立的岗位。

那么FDE在客户现场每天具体干什么活？Palantir的一位FDSE在官方博客里列过他的典型技术问题：

• 怎么构建、扩展和维护一个TB级的数据管道，给关键任务的运营工作流提供数据？
• 怎么根据客户独特的合规要求，配置平台的数据访问权限和工作流控制？
• 怎么为一个非技术背景的客户设计一个可视化工作流，让他们能跟高噪声数据交互？怎么把这个功能泛化，让其他FDE和客户也能受益？
• 生产环境出了故障，怎么排查根因、部署修复、监控稳定性？

注意最后两个问题里反复出现的一个词：“泛化”。这就是FDE和普通实施工程师的区别。实施工程师解决完问题就完了，FDE解决完问题之后还要想：“这个方案能不能变成平台的一部分，让下一个人不用重来？”

什么样的人适合做FDE？从上面的描述你大概能感觉到，FDE需要的不是一般的工程师画像。Flybridge的Daniel跟Palantir现任FDE Brian Keohane讨论后，总结了一个相当一致的人才画像：

• 极强的ownership和韧性。他们像founder一样对结果负责，把客户的工作流当自己的产品，不惜一切让生产系统跑起来。
• 偏好行动而非分析。先交付一个粗糙但管用的“碎石路”方案，快速创造价值，而不是分析到死。
• 对模糊性感到自在。客户说不清需求，环境混乱，真正的问题藏在表面之下。FDE在这种环境里如鱼得水。
• 技术+沟通双能力。能写生产级代码，也能给CFO讲架构决策。这个组合极其稀缺。

简单说：像founder，不像craftsman。

这也是为什么Palantir出了那么多startup founder：Kalshi的Tarek Mansour、Hex的Glen Takahashi、Sourcegraph的Quinn Slack、Anduril的Matt Grimm、Fern的Deep Singhvi，都是前FDE。

飞轮：从碎石路到铺好的路

FDE在客户现场做出来的东西，在Palantir内部叫“碎石路”（gravel road）。粗糙、直接、只为这一个客户解决这一个问题。这完全合理，也是FDE应该做的事情。

但碎石路不能直接搬进产品。产品团队的工作是把碎石路变成“铺好的路”（paved road），一条不只经过这一个客户、还能经过后面一堆客户的路。

这就是飞轮：

• FDE在客户A的现场发现了一个需求，做了一个碎石路方案
• 带回总部，产品团队问：“这个问题的通用版本是什么？”
• 拉来客户B、C的FDE一起讨论，确保通用版本对他们也管用
• 产品团队构建通用能力，纳入平台
• 下一个FDE去客户D的时候，可以直接用这个能力，不用从头来

Palantir最著名的产品能力Ontology就是这么来的。最开始，每个客户都有自己的数据库：人、资金、船只各一张表。部署到第二个客户的时候，表结构就对不上了。产品团队把它抽象成了”objects + properties + links”的通用模型，让FDE按客户自行定义具体的对象类型。这个抽象化的过程，就是碎石路变成铺好的路。

这个飞轮里有一个容易被忽略的点：产品团队的用户不只是最终客户，还有FDE本身。 产品要给FDE提供杠杆，让他们能用更少的effort交付更多的价值。如果产品做得对，FDE应该会主动选择用产品的通用能力，而不是自己hack一个一次性方案。如果FDE不愿意用你的产品，大概率是产品做错了。Thomas Otter甚至预判：“明年最酷的岗位将是platform product manager”。

飞轮能不能转，关键不在FDE，而在平台产品团队。

当然，这个飞轮的效率不是文章暗示的那么理想。即使是Palantir，professional services收入占比多年来也没有显著下降。飞轮在转，但转得不快。对大多数公司来说，飞轮从启动到产生可见效果需要1-3年，这段时间里你看起来就是一家咨询公司。能不能坚持下去，取决于你对“过渡态”的信念和资本的耐心。

为什么AI时代天然适合FDE

FDE这个模式是Palantir在2010年发明的，为什么到了2026年突然所有AI公司都在做？

答案不是“因为Palantir成功了所以大家抄”。如果只是抄，前面说了，绝大多数会抄成咨询。

答案是：AI这个品类本身的特性，让FDE成为了一种结构性需要。

传统SaaS替换的是已有产品。你做一个更好的CRM来替代Salesforce，市场长什么样，大家都知道。你可以坐在办公室里研究竞品，做出一个更好的版本，然后卖出去。

AI agent不是。Bob McGrew说得很直接：“构建AI agent”这件事本身可能包含很多完全不同的东西，我们现在还不知道那些东西是什么。五年后回头看，可能“AI agent”这个词根本不存在了。

这意味着AI产品天然有一个价值发现的瓶颈。能力可能很强，但如果没人找到killer use case，能力就是空转的。

在个人用户场景下，这个瓶颈可以靠自然传播解决：有人发现了一个用法，发到社交媒体，其他人跟进。但在企业场景下不行。企业有合规要求、有遗留系统、有组织惯性，不会有人在Twitter上发帖说“我发现我们银行的反洗钱流程可以用Claude压缩90%”。你需要有人去现场帮他们发现。

这个人就是FDE。他的角色不只是“去客户现场搞清楚需求”，而是主动制造golden case。

Stripe的Forward Deployed AI Accelerator（FDA）是最好的企业端案例。Stripe发现自己的marketer已经在自发地用AI做出了一些东西：自己搭数据看板，创建能把多天流程压缩的agent。FDA团队的工作不是从零开始教人用AI，而是把这些已经被发现的golden case系统化地推广到整个营销组织。他们的成功标准是“你永久改变了多少个工作流”。

价值是marketer自己先发现的，FDA是去系统化推广已被验证的用法。这跟传统的“产品团队设计功能然后推给用户”完全是反过来的。

Anthropic+FIS的合作也是同一个逻辑。就在这个月（2026年5月），Anthropic把FDE直接嵌入了FIS，合作开发反洗钱AI Agent，目标是把调查时间从数小时压缩到数分钟。模型能力（Claude）是现成的，金融合规知识在FIS那边，但把两者结合起来、在受监管环境中跑通，需要有人坐在中间。FIS的Ferris说了一句很直接的话：“You’re not going to innovate around us.”

能力远超采用，FDE填的就是这个gap。

a16z合伙人Joe Schmidt的类比很到位：企业买AI就像你奶奶拿到一台iPhone，她想用，但需要你帮她设置好。在platform shift期间，implementation-heavy的模式不是缺陷，而是特征。Salesforce IPO前烧掉了5200万美元才产生2200万美元收入。但正因为它把复杂实施做到位了，现在市值2540亿美元。

Joe Schmidt还说了一个更深层的判断：软件不再是辅助工人的工具，软件本身就是工人。 但软件要成为合格的“工人”，需要FDE帮企业重新设计岗位职能和流程。Alex Rampell把这个拉到了市场规模的层面：企业软件市场年支出3000亿美元，但白领劳动力市场是数万亿美元。FDE做的事情不是在3000亿的市场里分蛋糕，而是在撬动万亿级的新市场。

窗口期与终局

最后说一个不那么乐观的判断。

Sequoia合伙人Julien Bek提出了一个Intelligence vs Judgement的框架。写代码是intelligence（可编码、可规则化的认知工作），决定下一步做什么是judgement（需要经验和品味的决策）。AI正在快速接管intelligence型的工作，但judgement目前还需要人类。

FDE目前做的大量工作属于judgement：判断客户真正需要什么、决定怎么设计工作流、在模糊的环境里定义问题。但Julien Bek的关键判断是：“Today’s judgement will become tomorrow’s intelligence.” 今天需要judgement的事，随着AI系统积累足够多的数据，最终也会变成intelligence。

这个窗口会收缩。

FDE不是一个永恒的角色。它是一个窗口期的角色。但窗口期内的卡位，决定了谁拥有工作流的定义权。

Gartner分析师Alex Coqueiro预测，到2028年，70%的企业将被迫放弃由FDE主导的AI项目。原因是高成本和内部能力不足。他给了一个判断标准：“如果FDE在连续部署中的投入保持不变，这就是一个信号：这段合作产生的是依赖，而非能力。”

这个标准跟我们前面说的试金石是一回事：第10个客户跟第1个客户花的精力一样多吗？如果是，飞轮没在转，你做的是咨询。

70%被放弃，也意味着30%活下来了。活下来的那些，会是真正用FDE方法论建起了平台飞轮的公司。它们在窗口期内卡住了位，拥有了工作流的定义权。

Sequoia的Julien Bek给出了一个终局判断：

“The next $1T company will be a software company masquerading as a services firm.”

下一个万亿美元公司，将是一家伪装成服务公司的软件公司。

这句话精确地描述了FDE模式的终局形态：从外面看，它在做服务（嵌入客户、解决问题、交付结果）；从里面看，它在做产品（每一次服务都让平台更强）。当平台足够强大、用户可以自己跑起来的那一天，FDE作为角色会消失。但FDE作为方法论留下了一个东西：一个被无数次客户部署打磨过的、真正好用的平台。

写在最后

过去半年对FDE的研究让我有一个很深的感触：市场上的讨论之所以混乱，不是因为FDE是个模糊的概念，而是因为太多人把不同的东西装进了同一个词里。

FDE的定义是清晰的：有平台、嵌入客户、产品发现、产物回流。 满足这四条的，不管你叫它什么名字，都在做FDE。不满足的，不管你title写什么，都不是。

那些说“FDE不过是consulting”的人，没说错。他们看到的就是那种。问题不在于他们的判断，在于他们把所有叫FDE的东西都当成了同一种东西。

Marc Andrusko说过一句话，值得所有想学Palantir的公司记住：

“Palantir should be seen as an inspiration, rather than a rule or playbook.”

Palantir是启发，不是可以照抄的手册。它的FDE方法论可以学，但它同时做到的四件事——嵌入式工程、集成平台、高接触GTM、按结果定价——不需要你全盘复制。把四层混在一起当作一个东西来模仿，就是大部分startup踩坑的原因。

如果你正在考虑是不是要用FDE，或者是不是要加入一家FDE公司，我的建议是：先问自己五个问题。

第一，给我看你的平台边界在哪里。共享产品止于何处？定制从哪里开始？

第二，走一遍部署时间线。从签约到生产环境要多少engineer-months？

第三，第三年的利润率是什么样的？成熟客户的FDE投入是否在下降？

第四，如果明年签50个客户，什么会先崩？

第五，你如何决定不做定制？拒绝客户需求的能力，是产品公司和服务公司的分水岭。

这五个问题比任何定义都更实用。如果答不上来，大概率不是在做FDE。

FDE是个好东西。但好东西最怕被滥用。当一个策略变得足够性感、足以被奉为“标准打法”时，总是危险的信号。

做FDE，先做平台。或者至少，做FDE之前，先想清楚你的平台在哪里。