昨晚 DeepSeek 发布了新模型 DeepSeek V4 Pro，虽然有些波折，但性能提升毫不意外。倒是跟着一起出来的 DeepSeek Harness 让人眼前一亮，这是 DeepSeek 的第一个 Agent 产品。刚刚开源一天，GitHub 已经 7 万多星了，增速比当初 R1 开源的时候还猛。

很多人以为 DeepSeek Harness 是又一个 Codex 复刻，但实际跑一下就可以发现，这东西跟 Codex 们根本不是一个思路。

简单说，Codex 就是一体机，模型、工具、循环、权限全部焊死在一起。想换模型必须使用 Codex 支持的模型格式，想去掉用不到的工具省点 token 也没门。DeepSeek Harness 则是组装机，模型是插件，工具是插件，会话是插件，连 Agent 循环等等一切皆插件。

为此，DeepSeek 还专门发了一篇 88 页的论文，把插件的装卸做成了有数学证明的形式化系统。这还是我第一次看到有人用数学证明来定义 Agent Harness 该怎么组装。

下面就从安装开始，带你一步步把它跑起来。

一行命令跑起来

首先，机器上需要安装 Node.js （版本号要求 22.19 以上，如果没有，可以让其他的 Agent 帮你安装）。然后在命令行执行：

npx @deepseek-ai/dsh web

稍等一下，你会看到dsh web: http://127.0.0.1:3080。接着，在浏览器打开这个链接就进入了 DeepSeek Harness 主界面。

在开始使用之前，它会提示你输入 API Key。到 DeepSeek 开放平台（platform.deepseek.com）创建一个：

复制 API Key，回到 Harness 界面粘贴上就可以进入如下所示的主界面了 ：

这时候输入框还是不能输入的。你需要先选择一个工作区（就是你要让 Agent 操作的项目目录），比如我选择了 deepseek-harness 源码目录，接着输入框就可以用了。

开始第一个任务

配好之后我试了个简单的：让它总结自己的源码仓库。发了一句“总结此代码库并识别其主要工作原理”，它读了 AGENTS.md，扫了 packages 目录，阅读了设计文档，一分钟左右就给出了一份架构概览，核心包和它们的职责列得挺清楚。

直观用下来，跟 Codex 具有明显的不同：

第一个明显感受是速度。用惯了 Codex 再切过来，对比太明显了，响应速度和工具调用的周转都非常快。当然这跟 DeepSeek V4-Flash 本身的推理速度有关，但 Harness 端的开销控制也做得不错。

另一个亮点是轨迹视图。点开“轨迹”标签页，可以看到模型每一步看到了什么、调了哪个工具、传了什么参数、返回了什么结果，连 system prompt 和 context 注入都能展开看。

所有信息都记在 append-only 的会话日志里，恢复、分叉、回放都从这里派生。这个“模型可见即已记录”的方式，在其他 Agent 工具里不常见。

装备 Agent 预设

DeepSeek Harness 对 Agent 的灵活控制体现在它的 Agent 预设功能里。所谓 Agent 预设就是一个会话的 Agent 所运行的插件组装，包括它的工具、提示词与能力等等。

打开设置里的“Agent 预设”，可以看到它已经内置了四种预设：

标准模式是日常默认，提供了最完整工具组合。PTC 模式让模型用 TypeScript 程序编排多步工具调用，跟 Claude Code 的 thinking tool use 一个思路。极简模式只保留 bash + 编辑器这两个工具，用于基准测试。创造模式则在标准模式的基础上又增加了自检、插件实验和预设创建功能，用来创建新的 Agent 预设。

这四种模式本身就展示了“一切皆插件”的核心：不同模式就是不同的插件组合，你也可以复制一份改成自己的。

对于入门使用来说，标准模式就够了。等你玩熟练了，想针对特定场景或项目做定制，到时候就可以切换到创造模式，让它帮你装备上你特定的工具、Skill、知识库等私有配置。

一切皆插件

前面说了 DeepSeek Harness 是组装机，那具体能组装哪些东西呢？翻了一下源码，我发现整个项目由 50 多个独立的 Cordis 插件组成，每个插件负责一个具体能力。这些插件之间没有谁是核心、谁是外围的区分，官方原话是 “There is no privileged core to patch”，所有插件地位平等。

下面这张图展示了主要的服务插件和它们的可替换选项：

从图里可以看到，模型、工具、会话、沙箱、技能、子 Agent 这些能力全部挂在同一个 Root Context 下面，每个都可替换。下面挑几个最实用的场景说一下：

• 换模型。设置页面添加自定义 OpenAI 兼容端点，指向公司网关或 vLLM，下一次请求直接生效，不用重启。

• 换沙箱。默认本地沙箱（Linux Landlock / macOS sandbox-exec），代码里有 E2B 云端沙箱适配器，换个配置就行。

• 删工具。Claude Code 每次都把几十个工具 schema 塞进提示词白吃 token。DSH 每个工具是独立插件，配置里禁用即可。

• 换 Agent 循环。这是跟所有现有 Agent 最大的区别。Claude Code 和 Codex 的 agent loop 都是写死在运行时里的，你可以在预留的 hook 点做定制，但循环本身换不了。DSH 的 agent loop 就是一个普通插件，写一个新的替换它就行。而且循环里的每个关键节点（模型请求前、工具执行前、轮次结束时）都是 waterfall 事件，你写一个审批插件或日志插件，监听这些事件就能拦截和改写，不需要碰循环代码本身。

说白了，其他 Agent 能做的事 DSH 都能做。但反过来，agent loop 本身可替换这件事，是其他 Agent 加多少 hook 都做不到的，因为这是最底层的架构决定。

Cordis 运行时安全装卸

既然一切都是插件，那就必须回答一个问题：怎么保证插件在运行时装上去、卸下来不会把其他插件搞挂？这正是 Cordis 框架要解决的核心问题。

做个对比：VSCode 也有插件系统，但卸载每个插件必须重启整个编辑器。而 Cordis 的目标是让插件可以随意热插拔，而且有数学证明保证安全。

下面这张图展示了 DeepSeek Harness 的分层架构，从上到下每一层都可以被上一层覆盖：

论文把安全装卸拆成两个维度来解决：

• 时间维度，插件卸载时所有副作用必须可撤销。每个注册的事件监听器、服务、工具 schema 都通过ctx.effect() 安装，运行时追踪逆操作，卸载时反序执行。

• 空间维度，插件间依赖自动管理。通过inject 声明需要哪些服务，框架等依赖就绪再激活。被依赖的服务卸了，依赖它的插件自动暂停。

有了这些，你可以在 Agent 跑着的时候换模型、加工具、改沙箱，不丢上下文，不丢会话。论文还证明了 confluence 定理，不管你以什么顺序装卸插件，最终状态等价于把最终配置从头加载一次。

还不够好的地方

DeepSeek Harness 虽然刚开源一天，但生态已经非常丰富了。内测阶段的招募在 Twitter 上引发了一场开发者路演，964 人报名提交了 897 个项目。开源后awesome-deepseek-harness 等精选列表迅速冒了出来。

有意思的是，从 GitHub commit 历史可以发现，不少代码是通过 Codex worktree 提交的。DeepSeek V4 原生支持 Responses API，可以无缝接入 Codex，所以团队直接拿竞争对手的工具来开发自己的产品，挺务实的。

目前官方不接受外部 PR，但可以通过 Discussion 反馈问题，也鼓励社区做独立插件丰富生态。官方表态也挺有意思：“我们不认为官方仓库中的包比社区创建的包更重要”。

不过问题也不少。现在的 v0.1 还处在开发者预览状态，后续肯定会有破坏兼容性的变更。安全方面，已有研究者发现几个严重漏洞，包括 read-only 沙箱对读操作不设防、动态插件的 vm 沙箱存在逃逸路径等，这些安全问题在使用时一定要注意。

写在最后

如果把 DeepSeek Harness 当产品看，它现在有没有 Codex 好用？UI 成熟吗？体验够不够顺畅？这些问题的答案都是“还差得远”。

但 DeepSeek Harness 看的可能不是当下的使用体验。在模型能力还在高速变化、Harness 的最佳范式远没有收敛的阶段，过早押注一个封闭产品，等于拿一家公司的判断去猜一个还在移动的终局。DeepSeek 的做法是把门打开，保留尽可能多的选择权，让社区来探索什么组合最有效。

某种上下文策略胜出了，它就可以成为默认插件。PTC 比传统工具调用更有效，它就可以被强化。未来模型强到不需要复杂的多 Agent 编排，那些组件就可以随时卸掉。社区跑出来的问题、插件和经验，会不断暴露模型在真实任务中哪里不够用，这些反馈既推动 Harness 迭代，也能告诉模型团队下一代该往哪个方向训练。

你不用急着把全部任务都切过来，但可以考虑把中文写作、超长上下文任务、以及日常跑量大的工作丢给它试试，等慢慢稳定后再考虑切换更多工作过来。

相关链接：

• 官方文档：deepseek.com/harness
• GitHub 仓库：github.com/deepseek-ai/deepseek-harness
• Cordis 论文：github.com/cordiverse/paper

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

我现在日常开发几乎所有代码都是 Claude Code 或者 Codex 生成的。偶尔回头看看 git log，已经分不清哪些是自己写的哪些是 AI 写的了。

问题也跟着来了。代码量上去了，人的审查跟不上。以前一个 PR 三五百行，认真看半小时能看完。现在动不动几千行改动，而且 AI 生成的代码往往结构正确、命名规范、注释齐全，看起来挑不出毛病，但跑起来就是有各种问题。

那能不能让 AI 来做代码审查？AI 写的代码再让 AI 审一遍，听起来很合理。但 AI 审 AI 的代码，怎么保证不是互相糊弄呢？今天就来分享一下我自己摸索出来的一套方法。

质量门控是底线

不管有没有 AI，基本的质量门控都得有。Lint、类型检查、单元测试、集成测试、端到端测试，这些是所有代码合并的前提。AI 时代这些东西反而更重要了，因为 AI 写代码特别擅长绕过人的直觉，但很难绕过一个覆盖全面的测试套件。

所以，如果你的项目连这些基本的门控都没搭好的话，那就不要让 AI 上来就开始做功能开发，AI 编程的第一步应该是补上这个短板，打好质量门控这个基础。

有这些基础之后，再来看如何用 AI 审 AI 的代码。

把 PR 拉到本地，给 AI 完整上下文

我现在的做法是让 Agent 把 PR 代码拉取到一个独立的工作树里，避免影响我正在进行的其他工作。然后拿整个代码库作为上下文来做整体审查。

之所以这么做，是因为我之前踩过不少坑。最典型的是 GitHub Copilot 的审查功能，特别容易产生大量评论，一个 PR 能标出十几个“严重问题”。看起来每条都头头是道，分析得很有道理。但你要是真跟着它改了，就有可能把原来好好的代码改坏。

为什么？因为 AI 在“想办法说服你它是对的”这件事上，比大部分人都厉害。它能给你编出一套完美的推理链，解释为什么这行代码有问题，为什么应该按它说的改。但这个推理链可能建立在一个错误的假设上，而你纯靠看代码很难发现这个假设是错的。

所以光“看”是不够的。

验证比审查重要得多

纯靠看代码做审查，不管是人看还是 AI 看，都有一个根本性的局限：你只能发现你能想到的问题。

解决方案是给 Agent 一个真实的运行环境，让它把修改后的代码构建起来、实际跑起来，做一些真实场景的验证。不是在脑子里模拟“这段代码会不会出问题”，而是实际跑一遍看看结果。

这个思路和 Claude Code 团队的 Boris Cherny 最近说的完全一致。他提到现在 LLM 产生的问题跟以前不一样了，不太会犯人容易犯的低级问题，更多是系统设计、UI 可用性、缺少更广泛的上下文这类问题。这种问题纯靠看代码几乎不可能发现，但跑一遍就很容易发现。

他给了一个很简单的例子：只需要一行提示词，让 Agent 用动态工作流在模拟器里对每个边界情况做对抗式测试，或者直接用 Claude Code 内置的 /code-review。对抗式的审查比单纯“帮我看看有没有问题”要有效得多。

跑真实环境的两个副作用

不过，给 AI 真实环境做验证也带来了新问题。

第一个是安全。Claude Code 有内置的 /security-review，Codex 也有类似的安全扫描能力，直接用就行。安全问题往往藏在代码的交互边界上，比如输入校验、权限检查、敏感数据处理这些地方。人看代码的时候注意力容易放在业务逻辑上，反而是这种模式匹配的活儿 AI 更擅长。

第二个坑我踩了好多次：AI 在验证过程中会跟你本地的各种服务交互，然后它写审查评论或者 PR 描述的时候，特别喜欢“展示证据”，顺便把你本地的环境信息也带出去了。我经常碰到的就是 PR 里出现我本地 Kubernetes 集群的名字、命名空间、用户名之类的信息。比如 AI 会写“在 xxx-cluster 的 dev 命名空间跑了验证，发现 xxx 问题”。这种私有信息一定要避免推到公开仓库。

最好的办法是在审查流程的最后加一个单独的清理步骤，专门扫描 PR 内容里有没有内部环境信息、凭据、IP 地址这些不该出现的东西。

那还需要人干嘛？

AI 编程之后再让 AI 来审核，是不是就不需要人了？是不是就应该把所有程序员都开掉？

完全不是的。随着大模型变的越来越强大，部分编程问题的确是已经解决了，但编程并非全部。

需求梳理、系统设计、用户体验、安全策略、技术路径选择等等，还有很多方面需要人来把关。AI 能写出正确的代码，但不一定能写出合适的代码。“正确”和“合适”之间的差距，就是人的判断力存在的空间。

其实现在已经能看到大量 AI 生成的小项目和工具，看起来功能齐全、代码规范，但真正用起来根本解决不了实际问题。代码能跑不等于产品能用，很多只是在浪费算力。没有人去判断“该不该做”和“做成什么样”，AI 再能写代码也只是在批量生产垃圾。

不过说实话，“人应该把关哪些东西”这件事我自己也还没完全想清楚。发现需求和设计产品显然需要人，但 UI 可用性呢？特定场景的边界情况呢？这些东西现在靠人，未来是不是也能靠更好的约束来覆盖？我不确定。目前的做法就是先把能自动化的自动化掉，剩下的再说。

怎么开始？

Claude Code 的 /code-review 和 Codex 的审查命令是不错的起点。

我建议你在本地开发的时候尽量把它们用起来，每次改完代码提 PR 前先让它们审一遍。不需要什么复杂配置，直接用就行。Claude Code 还支持不同级别的审查深度，/code-review low、/code-review medium 之类的，可以根据改动的风险程度选择。

对于自动化的 AI 代码审查流程，我的建议是参考这些工具的实现，在它们的基础上加上前面提到的几个核心点：

1. 完整的代码库上下文，别只看变更 diff
2. 真实环境验证，代码要能构建跑起来
3. 安全扫描
4. 本地信息清理
5. 对抗式审查测试，主动找茬而不是被动检查

不同项目的环境准备和验证步骤都不一样，不要试图造一个大而全的通用方案。为每个项目构建独立的审查配置，把项目特有的约束写进去，让 AI 生成的代码必须通过这些约束才能合入，通不过就打回去让它自己修。

这个做法跟我之前在《烧了 20 亿 token 总结的 Codex 使用指南》里说的一样，验证比生成重要，审查配置比审查本身重要。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Claude Code、Codex CLI 这些 AI 编程工具满打满算也就发布了不到一年半。但就这一年多时间，我们写代码的方式彻底变了。手搓代码快成“非遗”了，一行一行手敲反而成了需要特别标注的“传统编程”。变化快到有点不太真实。

不过工具用得越多，问题也暴露得越明显。其中最让我难受的不是模型能力，而是 TUI 本身。

比如早期的 Claude Code 在长会话时很容易出现终端疯狂刷屏、整个屏幕闪烁、所有历史消息全部重绘这样的问题。会话越长闪得越严重。这个问题被用户吐槽了好几个月，Anthropic 后来做了全屏渲染模式来缓解，但回滚查看历史消息也比之前慢多了。

闪烁还只是表面现象。真正让我烦的是：跑复杂任务的时候，想回头看看之前某一步 Agent 到底做了什么决策，在终端里翻消息简直是噩梦。对简单任务无所谓，但复杂任务往往需要反复审查 Agent 的中间决策，判断它有没有走偏，这就麻烦了。

你在用的时候是不是也有这个感觉？反正我经常碰到。我最近几个月一直在用一个叫 Paseo 的多 Agent 控制台，完美解决了这个问题。用下来感觉不错，分享给你。

克制是 Paseo 最大的优点

多 Agent 编排早就不是新鲜事了，开源闭源都冒出来很多项目，比如 Multica、Orca、Mission Control、Paperclip 等等，GitHub 上随便一搜几十上百个。但大部分都有个共同的毛病，都想做自己的 Agent Harness。

自己造 Harness 意味着什么？你的 CLAUDE.md 不生效了，Skills 读不了了，积累的配置和记忆也全部作废了。得在一个全新环境里从零开始教 Agent 干活。我之前试过几个类似的工具，对我用的 memory 格式支持都不好，老是要返工，甚至之前一两个小时的工作它能给我来来回回搞上一天，无奈最后还是回到了 Claude Code。

Paseo 则很克制，原生支持 Claude Code、Codex、OpenCode、Pi，再加上各种 ACP，主流的 Agent 它都可以接入。 Paseo 没有试图替代任何一个。你在 Paseo 里跑 Claude Code，底层就是 Claude Code 本身。CLAUDE.md、Skills、Hooks、MCP servers、memory 全都在，一个不少。说白了就是给 Agent 套了一层更直观易用的壳，灵魂还都原始保留着。

这种克制在当前这个赛道里反而成了最大的优点。切过来零成本，不喜欢随时切回去。

TUI 的问题它都解决了

Paseo 完美解决了 TUI 的两大问题：

第一个是消息过滤。Paseo 可以把 Agent 的输出分成不同视图：只看消息、只看关键输出、只看工具调用、或者全部展开。TUI 把所有东西混在一条流里往下刷，要么全看要么全不看。能分层看这件事听起来简单，用过之后就回不去了。

第二个是多 Agent 并行和跨 Provider 编排。你可以同时开几个 Agent，一个用 Claude Code 的 Opus 做架构设计，另一个用 Codex 跑实现。关键是 Paseo 的子 Agent 能跨 Provider 调度：Claude Code 可以把任务派给 Codex，Codex 也可以把任务派给 Grok，这在各家原生的多 Agent 方案里是做不到的。

它还有几个内置 Skills 挺实用。/paseo-handoff 在不同 Agent 之间交接任务，比如先用 Claude 做规划然后 handoff 给 Codex 去实现。/paseo-loop 循环跑一个 Agent 直到满足验收条件，还可以配一个 verifier。/paseo-committee 拉两个不同的 Agent 组成委员会做根因分析。另外还有 heartbeat 功能，可以让 Agent 定时检查 CI 状态，失败了自动修，通过了自动停。

手机不是用来写代码的

Paseo 支持 iOS、Android、桌面端和网页端，覆盖面在同类工具里算最全的。

不过手机端的价值不是让你在手机上写代码，而是监控和介入。Agent 跑长任务的时候不用一直盯着电脑，出门掏出手机看一眼进度，Agent 遇到需要确认的问题直接在手机上回复就行。它还有语音模式，可以直接用语音给 Agent 布置任务或者讨论问题，走路的时候不用掏手机打字。

其实 Paseo 这个名字就说明了设计意图。Paseo 是西班牙语里“散步”的意思。作者 Mo Boudra 之前遛弯的时候总是得 SSH 到 tmux 里查看 Agent 状态，太折腾了，于是做了这个工具。一个人从头写到尾，GitHub 上 12,000 多个 Star 全是他一个独立开发者撑起来的。

安全方面，设备之间通过端到端加密的 relay 配对。Agent 始终在你自己的机器上跑，没有遥测，没有追踪，也不需要登录。

部署在服务器上，随时随地连

Paseo 最实用的部署方式是跑在开发机或远程服务器上，然后从任何设备连过来操作。

桌面端最简单，从 paseo.sh/download 下载，打开之后 daemon 自动启动。手机配对在设置里扫个码就行。

远程服务器用 Docker：

docker run -d --name paseo\ -p 6767:6767\ -e PASEO_PASSWORD=your-password\ -v"$PWD/paseo-home:/home/paseo"\ -v"$PWD:/workspace"\ ghcr.io/getpaseo/paseo:latest

启动后访问http://your-server:6767 就是完整的 Web 界面。手机 App 连这个地址，就可以在任何地方操作服务器上的 Agent 了。服务器不在公网的话，可以用 Tailscale 或者 Paseo 自带的 relay 做穿透，relay 走端到端加密，不需要开端口。

前提是服务器上要装好对应的 Agent CLI。Paseo 是编排层，不包含 Agent 本身，Docker 镜像里自己加装就行。

写在最后

Paseo 还在 beta 阶段，有些粗糙的地方。移动端侧边栏滑动手势偶尔失灵，终端在手机上的输入体验还在打磨。WebSocket 连接在 Cloudflare relay 上大概 100 秒不活跃会断开，长时间挂着需要注意。

另外 Paseo 上手门槛不低，你得先有自己的 Agent CLI 环境，它也不帮你管理 Agent 环境。不过换个角度想，这恰恰是它克制的体现。不做自己不该做的事。

在一个所有人都想做 Agent Harness 的市场里，Paseo 选择不造引擎。它不跟 Claude Code 和 Codex 竞争，它让你同时用好它们。这种思路在我看来是对的。

当然，如果你不需要远程访问和多 Agent 跨 Provider 编排，只是单纯想在本机上有个比 TUI 更舒服的界面，Claude Desktop 和 Codex App 也都是不错的选择。它们各自对自家 Agent 的集成更深，开箱即用，不需要额外部署 daemon。Paseo 的优势在跨 Agent 和跨设备这两个场景上，如果你同时用多个 Agent 或者经常需要远程操作，它才是更合适的选择。

项目地址：https://github.com/getpaseo/paseo

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Claude Code 团队 Thariq 的文章，原文链接：https://x.com/trq212/status/2073100352921215386。本文在翻译基础上做了整理和补充。

Fable 5 恢复访问之后，我拿它跑了一些之前用 Opus 做的任务。明显感觉它的一次性完成率高了很多，以前需要三四轮迭代才能收敛的事，现在经常一轮就做对了。不过反过来也有一个新问题：一旦中间跑偏了，那结果也比以前歪的更厉害了，回头看才发现是我自己没想清楚就让它动手了。

以前用 Opus 还能靠反复重试和人工 review 来兜底，现在 Fable 不太给你这个机会，具体的结果取决于你喂进去的上下文质量。

刚好看到 Claude Code 团队的 Thariq 发了一篇文章讲这个问题。他的核心观点是：Fable 5 是第一个瓶颈不在模型能力的模型，瓶颈在你能不能把自己不确定的东西讲清楚。他用了一个比喻叫“地图不是疆域”，你给 Claude Code 的 prompt、skill、上下文是地图，代码库和真实世界的约束是疆域，两者之间的差距就是未知的地方。管理好这些未知，才是用好 Fable 5 的核心。

社交媒体上这几天的实践也印证了这一点。有人用 Fable 做了 60 多个 Three.js 3D 场景 demo（Karpathy 评价 “top tier fablemaxxing”），有人复刻了 70% 的 Notion，还有人让它在终端自己渲染起了视频。这些人出活效率高，并不是因为他们 prompt 写得更长，而是他们在动手前把自己不清楚的东西消化掉了。

Thariq 这篇文章给了一套非常实用的操作框架，从实现前、实现中到实现后，每个阶段都有对应的方法来消除未知。我觉得参考价值很高，整理出来分享给大家，同时补充了 Anthropic 官方提示词指南和社区实践中的一些经验。

四种未知

跟人类似，Claude Code 碰到未知的时候只能靠瞎猜。做的工作越多，碰到的未知就越多，猜错的概率也越大，结果当然也会越离谱。Thariq 用了 Donald Rumsfeld 的经典分类框架，把未知拆成四种：

Thariq 观察到一个事情：最强的 agentic coder 并不是 prompt 写得最长，而是未知最少。他看 Boris 和 Jarred 用 Claude Code 的时候，明显能感觉到他们非常清楚自己要什么，对代码库和模型行为都有深度同步。

不过就算是高手，也会假设自己有很多未知的地方。管理和减少这些未知本身就是 agentic coding 的核心技能。

怎么跟 Fable 5 配合

指导 Claude Code 是一个微妙的平衡。说得太具体，它会死板执行，该转弯的时候不知道转弯。而说得太模糊，它又会按行业最佳实践自己做选择，但未必适合你的场景。

Anthropic 官方的 Fable 5 提示词指南里提到一个关键点：Fable 5 的指令跟随好到一句简短的指令就能调整大多数行为。以前你可能要列十条不要做 X，现在一句简洁回答就够了。不过这也意味着它偶尔会做未被要求的事（比如自动起草邮件、建防御性 git 分支备份），所以需要明确告诉它边界在哪里。

另一个实用的参数是 effort。high 做默认就好，xhigh 留给最难的任务，日常用medium 甚至low。低 effort 的 Fable 5 往往比之前模型的xhigh 还强，这个也侧面说明 Fable 5 模型的提升的确是很大的。

不过 Claude Code 能帮你更快发现未知。它搜代码库和互联网极快，对大多数话题知道得比你多，从失败中迭代的速度也比你快。Thariq 说最重要的一点是：告诉 Claude Code 你现在处于思考过程的哪个阶段。主动告诉它你对这个问题和代码库的理解，让它像伙伴一样跟你一起工作，而不是一个单纯的执行者。

动手之前：把不清楚的找出来

盲点扫描

当你在一个不熟悉的代码库开始工作，或者用 Claude Code 帮你做设计这种你不太擅长的事情时，大概率有很多 Unknown Unknowns。

这时候直接问 Claude Code：“帮我做一次盲点扫描，找出我在这个问题上的 Unknown Unknowns”。

示例提示词：

我要在这个代码库里加一个新的 auth provider，但我对 auth 模块一无所知。帮我做一次盲点扫描，找出我的相关 Unknown Unknowns，帮我更好地给你写 prompt。

头脑风暴 + 原型

当你有很多 Unknown Knowns 的时候（就是那种“我说不出来但看到就知道对不对”的标准），最好让 Claude Code 做几个方向给你挑。

比如你想加一个按钮到界面上，但不确定放哪里好看，也说不清什么算好看。这时候让 Claude Code 做四个完全不同的设计方向，用 HTML 原型展示出来，你看到了自然就能做选择。

我想做一个数据 dashboard，但我没有视觉品味，也不知道有什么可能性。做一个 HTML 页面展示 4 个完全不同的设计方向，让我能看看效果，然后跟你反馈。

其实 Thariq 几乎每次 coding session 都会以探索或头脑风暴阶段开始。Claude Code 经常能找到他自己会错过的高价值路径。

面试

做完头脑风暴后大概率还有很多未知点。这时候让 Claude Code 来采访你：

对任何模糊的地方一个一个问我，优先问那些答案会改变架构的问题。

这个方法特别有用。Claude Code 会逼你想清楚那些你以为已经想清楚、但其实并没有的东西。

动手的时候：记下每次偏离

不管规划做得多充分，动手之后总会遇到意料之外的情况。Thariq 的做法是让 Claude 维护一个临时的implementation-notes.md 文件：

维护一个 implementation-notes.md。如果碰到 edge case 需要偏离计划，选保守方案，记录到 Deviations 下面，然后继续。

这样下一次做类似任务的时候就有据可查。这里补充一个 Anthropic 官方指南里提到的坑：长时间运行的任务中，Fable 5 可能编造进度报告。官方建议是让它对照实际工具结果审计每一条进度声明，只报告你能指向证据的工作。不要让它复述自己的推理过程（会触发安全分类器导致 refusal），需要看推理过程就读 thinking block。

做完之后：让别人看懂你做了什么

做完之后，Thariq 会让 Claude Code 把原型、规格文档和实现笔记打包成一个可以扔到 Slack 里让人快速理解的文档。

还有一个我觉得挺妙的做法：让 Claude Code 给你出一份关于这次改动的测试题。

我想确保我理解了这次改动的所有内容。给我一份 HTML 报告，包含改动的上下文、直觉、做了什么，底部附一个 quiz，我必须答对才 merge。

Fable 5 的实战验证：视频剪辑

Thariq 在文章最后举了一个自己的例子：Fable 5 的发布视频是他完全用 Claude Code 剪辑的。

他的流程完美体现了管理未知的方法：

1. 他知道 Claude Code 能用代码剪视频和做转录，但不确定精度够不够。于是先问 Claude Code 解释 Whisper 的工作原理，确认是否能精确切掉”嗯啊”和停顿
2. 他想做一个和语音同步的字幕 UI，但不确定能不能做到。让 Claude Code 做一个 Remotion 原型验证可行性
3. 视频色彩偏灰，他知道需要调色但不知道什么是好的调色。让 Claude Code 教他调色的基础知识，帮他发现自己的未知

每一步都是先暴露未知，再决定怎么做。

社区在怎么用 Fable 5

Thariq 这篇文章是方法论层面的。社区这几天的实践则展示了 Fable 5 的具体能力边界。

我觉得最有意思的一个玩法是知识蒸馏。有人让 Fable 5 扮演即将退休的首席工程师，审计整个代码库，写出 10-16 个 Skill 文件（调试手册、变更规则、曾经踩过的坑等等）。之后 Opus 和 Sonnet 按这套 playbook 跑更便宜的 session，效果接近 Fable 标准。代价是一次跑下来能吃掉 30% 的周额度。这个玩法和 Anthropic 官方建议的构建记忆系统不谋而合：给 Fable 一个地方记录教训，哪怕只是一个 Markdown 文件，它在有历史参考的时候表现显著更好。

另一个社区逐渐形成共识的模式是 Fable 做大脑、Codex 做四肢。Fable 5 最强的不是写代码，而是理解复杂需求、拆解任务、制定策略。具体执行交给 GPT-5.5 或者 Opus，相当于 Tech Lead 配高执行力工程师。

Peter Gostev 在 3D 场景生成方向做了一个 45 分钟的视频，60 多个 Three.js 环境 demo。Karpathy 看完评价”top tier fablemaxxing”，Fable 在 3D 这块确实跨了一个台阶。

还有一个方向是网站复刻。给 Fable 5 一个链接，它能读底层代码（不只是截图），理解视觉和技术细节，然后复刻出带动效和 3D 交互的落地页。

写在最后

说实话，Fable 5 让我对“怎么写 prompt”这件事的理解变了。以前的难点是怎么让模型理解我的意思，现在的难点是我自己到底想要什么。这完全是两码事。

推荐你在下次动手前试试 Thariq 的方法：先花两分钟问问自己“我这里有什么不确定的”，然后让 Claude Code 帮你先把它们挖出来之后再去干活。

相关资源：

• Thariq 原文：https://x.com/trq212/status/2073100352921215386
• Anthropic 官方 Fable 5 提示词指南：https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
• Fable 5 知识蒸馏到 Skill 的完整 prompt（@PrajwalTomar_）：https://x.com/PrajwalTomar_/status/2073768365873885396

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Claude Code 官方博客《Getting started with loops》，原文链接：https://claude.com/blog/getting-started-with-loops。本文在翻译基础上做了整理和补充。

上个月写完《Loop Engineering》这篇文章之后，我一直在用 /goal 跑各种任务。当时的结论是 loop 好不好用取决于你能不能把”做完了”写清楚。这话没错，但其实并不完整。后来我碰到很多任务，并不是把停止条件写清楚就能完事的，还有验证步骤和触发时机也很关键。

刚看到 Claude Code 团队发了一篇官方博客，把他们内部怎么想 loop 这件事系统梳理了一遍。读完觉得挺有价值的，它给了一个我之前缺的判断框架：loop 分四种，区分标准是你愿意交出去什么。验证步骤、停止条件、触发时机、整个决策流程，这四样东西对应四种 loop，具体怎么选择取决于你愿意放手多少。

Claude Code 团队把 loop 定义为 Agent 重复执行工作、循环直到满足停止条件，然后按触发方式、停止机制和适用场景分成了四种。这个分法比社区里各种五花八门的说法清楚得多，因为它有明确的递进关系：你交出去的东西越多，Claude Code 帮你自动完成的任务也就越多，当然对应的成本也会越高。

第一层：交出验证步骤

这是最基础的一种。你发一条 prompt，Claude Code 读代码、改代码、跑测试、返回结果，然后等你的下一条指令。

这就是我们每天都在用的标准交互模式。你还在循环里，每一轮都需要你判断"做完了没"。

怎么让这种模式更高效？Claude Code 团队的建议是把你的验证步骤写成 Skill。比如前端改了一个按钮，应该启动 dev server、打开页面、点一下、截图、检查 console。把这些写进 SKILL.md，Claude Code 就能自己跑完验证，不用你每次手动检查。

---name:verify-frontend-changedescription:任何 UI 改动在宣布完成前必须端到端验证。---# 前端改动验证流程1. 启动 dev server，在浏览器中打开改动页面。2. 直接与改动交互（点按钮、填表单），确认预期行为。3. 检查浏览器 console：不能有新的 error 或 warning。4. 用 Chrome Devtools MCP 跑一次性能追踪。

你可以看到，这一层交出去的是"怎么确认做对了"。Claude Code 替你检查，但做什么、做到什么程度，还是你说了算。

第二层：交出停止条件

Turn-based 的问题是复杂任务一轮搞不定，Claude Code 会频繁停下来问你要决策。/goal 解决的正是这个问题：你定义好成功标准，Claude Code 自己迭代到满足为止。

/goal 把首页 Lighthouse 分数提到 90 以上，最多试 5 次。

这一层你交出去的是"什么时候算做完"。/goal 的关键在于停止条件必须是确定性的。数字、测试通过数、分数阈值这种最好用。为什么？因为描述性结果要大模型自己给自己打分，这种打分很不靠谱，而跑个 Lighthouse 拿到 92 分这种确定性结果它才能判断得准。

每次 Claude Code 尝试停下来，会有一个独立的评估模型检查你的条件是否满足。没满足就打回去继续干，直到达标或者到了你设的次数上限。

这跟 Codex 的 /goal 机制本质上是一样的。我之前在《Codex /goal 》文章中提过的"完成契约"概念在这里同样适用：你把"做完"从主观判断变成可验证的合约，agent 才能真正闭环。

第三层：交出触发时机

前两种都是你手动触发的。但有些工作是周期性的，比如每天早上总结 Slack 消息，或者持续盯着一个 PR 等 review 评论进来。

/loop 做的就是这件事：按时间间隔重复执行同一条 prompt。

/loop 5m 检查我的 PR，处理 review 评论，修复挂掉的 CI

这一层你交出去的是"什么时候该跑"。每 5 分钟检查一次 PR，有新 review 就处理，CI 挂了就修。你不需要一直盯着，它自己按节奏跑。

有一点需要注意的是，/loop 跑在你本地，机器关掉它就停止了。如果想让它不间断，需要用 /schedule 把它变成一个云端任务。

我觉得这一层最有意思的地方是它把 Claude Code 变成了一个值班机器人。以前你盯 CI、盯 review、盯 deploy，现在这些事可以交给一个定时轮询的 agent。当然它是以 token 消耗为代价的，这个后面会说。

第四层：交出整个决策流程

最后一种是把前面所有原语组合起来，做成一个无人值守的长期任务流水线。

比如处理用户反馈：用 /schedule 每小时检查一次 #project-feedback 频道，用 /goal 定义每个 bug report 必须被分类、修复、回复，用动态工作流让多个 agent 并行探索不同修复方案，用 auto mode 跳过权限确认。

/schedule 每小时检查 #project-feedback 里的 bug 报告。/goal 这一轮发现的每个报告都必须被分类、修复、回复后才能停。修 bug 时用动态工作流在并行 worktree 里探索三种方案，再让一个独立 agent 做对抗性审查。

这一层你交出去的是整个决策流程：做什么、怎么做、什么时候做、做到什么程度，全部由 agent 自己决定。

说实话这一层出问题的概率是最高的。动态工作流加上 /schedule 加上 auto mode，组合起来确实是一个完整的 agent 流水线。这对大模型本身的性能和你提供给它的上下文信息有极高的要求，也是最烧 token 的模式，动态工作流一次能起几十 agent，没有做好成本控制的话，很容易账单就爆了。前阵子不少公司砍掉了员工的 Claude 订阅，我觉得这种跑法肯定是原因之一。

怎么控制 token 消耗

从前面可以看出，交给 Claude Code 的越多，token 消耗也就越大。Claude Code 团队给了几条实操建议：

速查表

写在最后

回到开头说的那个问题：loop 用不好，往往不是模型不行，是你选错了层级。

我自己的经验是，先从 /goal 开始。找一个你每天重复做的事，问自己能不能把"做完了"写成一句可验证的话。能写出来，你就可以从 turn-based 升级到 goal-based 了。这一步收益最大，门槛最低，最能节省人力。至于 /loop 和 proactive，等你把 /goal 用顺了再说也不迟。

如果你想了解更多，推荐阅读：

• Claude Code 官方 Loop 博客：https://claude.com/blog/getting-started-with-loops
• Loop Engineering 很好，但先想清楚一个问题：https://mp.weixin.qq.com/s/QR40uuNa1oxtV5ds3i3Ukw
• Codex /goal 上线后，我把 Ralph loop 卸了：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 OpenAI 的《Codex Maxxing: long-running work》白皮书，原文链接：https://openai.com/index/codex-maxxing-long-running-work/。本文在翻译基础上做了整理和补充。

刚看到 OpenAI 发布了 GPT-5.6，分 Sol、Terra、Luna 三个档，各种测评性能果然又一次超过了 Claude（包括已经被禁用的 Fable 5）。不过应该是被 Anthropic 模型被禁的问题拖累了，只开放给了一些合作伙伴，普通人暂时用不上，只能眼馋了。

对我们来说，最重要的还是把手头的模型和工具用好。这不，翻到了 OpenAI 一份 27 页的白皮书，作者 Jason Liu 是 Codex 团队的开发者体验工程师。他把怎么让 Codex 的工作不断线这件事讲透了，关键在于把上下文、记忆、工具、定时任务和审查机制组成一个持续运转的工作台。

白皮书总共 10 个模块，构成一个完整闭环：上下文 → 工具 → 记忆 → 定时检查 → 审查。这五个环节哪个缺了，Agent 都可能会退化为一个更烧 Token 的聊天机器人。下面逐个拆解看看。

一、重要工作应该有个固定的家

第一个观点是别让重要工作散在不同的对话里。

把关键工作流都固定成持久会话线程。每个线程对应一个具体的工作域，比如有管 CLI 命令规范的，有管开源项目 issue 的，有专门追踪社交反馈的等等。

这样一来，上下文会随时间积累，旧决策不会丢，之前的工作都留在里面，并且会话上下文超出后会主动压缩。代价当然也有的，长线程会越来越贵，每次回来都要加载前面的历史。但对关键工作流来说，这个成本是值得的。

二、语音输入给 AI 的信息质量反而更高

这是为什么呢？

因为人说话时会把那些打字时觉得不好意思写出来的模糊想法也说出来。比如我记得 Slack 里有个叫 Ben 的人提过这个事，具体忘了，你去翻翻。这种指令打字很别扭，但说出来就很自然。而这恰恰是 AI 最需要的上下文。

让模型拿到你思考的原始版本，而不是你精心整理/清理过的版本，很多计划反而会执行得更好。

三、不用等它做完再说不对

Codex 在执行任务的过程中，你随时可以追加指令，不用等它跑完再推倒重来。

它在跑的时候你就可以插一句，这个做小一点、这段代码不对，甚至追加后续步骤，做完之后顺便开个 PR。

交互模式从一来一回变成了持续塑形，你在塑造一个正在进行的过程，随时可以调方向。这跟 Claude Code 的 Queuing 功能很像，但 Codex 把它做得更显性了。

四、光靠聊天历史是不够的

随着线程变长，对话历史翻起来越来越痛苦。有用的上下文应该变成可以打开、编辑、对比和复用的文件。

白皮书里用的是一个叫记忆库（vault）的文件结构：

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

要点是区分这两件事：Git 仓库放代码，记忆库放工作的流动上下文。人、决策、还没关闭的待办、日常笔记、项目状态，这些都放记忆库里。

记忆库放在 GitHub 上，这样每次 Codex 更新记忆库都会产生变更记录。变更记录就变成了记忆的审查界面，你能看到 AI 认为什么值得记下来。

那什么时候该写记忆呢？白皮书列了四条触发规则：

• 有人被提到 → 更新人物笔记
• 项目推进 → 更新项目页
• 待办关闭 → 标记已完成
• 有决策 → 写下决策和原因

这个思路跟我自己做的数字分身记忆系统几乎一模一样。我的 notes 仓库里也是用 OBSERVATIONS.md 和 REFLECTIONS.md 做分层记忆，用 git diff 做审查。这样做还有一个好处是记忆跟 Agent 解耦了，相同的记忆库可以方便共享给 Codex、Claude Code、Hermes 等各种 AI Agent。

五、AI 能操作什么？

线程有了记忆之后，下一个问题是它能真正帮你干啥。

Codex 内置了很多跟外界打交道的工具，大致可以分成五类：本地浏览器预览、需要登录态的 Chrome 页面、桌面操作、第三方连接器（比如 Slack、Gmail、日历、GitHub 等），以及可复用的技能包。原则也简单，接口能搞定的就别动图形界面，重复的活儿打包成技能。

六、人可以不在工位，但任务不能卡住

这估计是老板们最想看到的功能了吧！Codex 支持从手机远程查看和操作正在运行的任务。

无论你是去开会还是上个洗手间，活不能卡住。在电脑上启动任务后，离开工位去开会，到了决策点手机收到通知，批准、改方向或者换个思路。这样关键决策点能够随时介入，但人却不需要一直盯着屏幕了。

七、让 AI 自己回来检查

这部分最接近自主 Agent 的边界了。

线程自动化是绑定在会话线程上的心跳式定时任务，告诉 Codex 按照固定节奏回到这个对话，保持上下文，不要从头开始。

这跟普通提示词有什么区别呢？普通提示词是你告诉它现在做这个，做完就结束了。线程自动化不一样，它会持续盯着，有变化就自己往前推。

再往前走一步，一个线程可以有多个定时计划，可以设置条件退出，也可以随着任务变化调整频率。因为和线程上下文绑在一起，不用每次重新交代背景。

八、三个实战循环

白皮书给了三个完整的循环示例，每个都清楚地划分了 Codex 准备什么和人决定什么。

Loop 1：Chief of Staff

Codex 每 30 分钟检查 Slack 和 Gmail，找到需要关注的消息，搜索相关上下文，起草回复。你打开手机看到的不是一堆未读消息，而是整理好的待办清单和草稿，拍板发送就行。

Loop 2：Monitor for Feedback

第二个场景更自动化一些。Codex 每个工作日早上检查一个 Slack 频道里的用户反馈，更新 Remotion 项目，重新渲染，准备修改版供审查。反馈进来、代码改完、渲染跑完，人只需要做最后的创意判断。

Loop 3：Get a Refund

第三个最有意思。Codex 每 5 分钟检查客服线程里有没有人工客服加入。一旦检测到真人，自动切换到每分钟检查一次，准备下一轮回复的草稿和证据。你要做的就是看一眼草稿，觉得没问题就批准发送。

三个场景都是类似的，Codex 干活，人来拍板。任务在你不在的时候照样推进，但所有重大决策都卡在人手里。

九、怎么给 AI 设目标

目标设得好不好，直接决定 Codex 能不能高质量完成你分配的任务。

比如按照这个 Markdown 文件实现这个计划，看起来有目标，但做完之后没法自我验证。换一种写法：把这个库移植到 Rust，保持公共 API 兼容，用原来的单元测试作为验收标准，测试通过且差异已记录，工作才算完成。

后者给了 Codex 一个可以自己跑的验收条件。

就像我之前聊 Codex /goal 时说的，没有验证条件的目标，只能是个愿望，跑好跑坏全靠运气。

十、侧边栏

侧边栏不只是看看输出结果的预览窗口，还可以用来可以检查 Codex 正在操作的对象，加评论、审查变更、把产出物保留在线程里等等都可以在这里完成。

侧边栏支持的格式挺广的，Markdown、表格、CSV、PDF、幻灯片都能渲染。甚至一个 HTML 文件加点 JavaScript 就能变成可交互的工作面板。说白了，侧边栏是 Codex 从聊天应用变成工作台的关键界面。

写在最后

读完这份白皮书，给我触动最大的是这 10 个模块组合起来的闭环。上下文让 Agent 知道自己在干嘛，工具让它碰到真实世界，记忆让经验留下来，再加上定时检查和人工审查，整个系统才能持续转起来。少了哪一环，都可能退化成一个更烧 Token 的聊天机器人。

推荐完整读一遍原文，不管你用的是 Codex、Claude Code 还是别的 Agent 工具，这个闭环的思路都是通用的。

原文链接：https://openai.com/index/codex-maxxing-long-running-work/

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程博客《Steering Claude Code: skills, hooks, subagents and more》，原文链接：https://www.anthropic.com/engineering/claude-code-best-practices。本文在翻译基础上做了整理和补充。

在使用 Claude Code 时，我的 CLAUDE.md 曾经写到几千行。项目规范、参考约定、编码风格、部署流程，还有日常开发中碰到的各种坑，全往里面塞。CLAUDE.md 的内容越来越丰富，Claude Code 也越来越好用。直到有一天我发现 Claude Code 开始选择性忽略某些指令，才反应过来，它的上下文太长了，它已经不能很好地遵循 CLAUDE.md 定义的各种规则了。

你是不是也碰到过类似的情况？明明写了“所有修改必须跑完整 e2e 测试”，结果只跑了一个单元测试就停了，需要你反复提示才执行。

我在这个问题上卡了很久，一度怀疑是 Claude 模型又降智了，后来才发现根本原因是上下文膨胀。把所有东西都塞进了 CLAUDE.md，这本身就是用错了 AI 工具。

Anthropic 最近发了一篇官方指南，系统梳理了提示 Claude Code 的 7 种方法和它们的实现原理。我之前踩过的很多坑，根因都是没搞清楚每种方法的加载时机和上下文成本。

下面是我对这篇指南的编译和解读，每一节加了自己的使用经验。

CLAUDE.md：写得越多，质量越差

CLAUDE.md 是使用 Claude Code 所必需的第一步，所以也就成了大家最先接触、也是最容易写过头的配置方法。它在 Claude Code 会话启动时就加载，全程驻留在上下文空间中。

不过这里有个容易忽略的设计：CLAUDE.md 的写法其实分两种。

第一种，放在项目根目录的 CLAUDE.md 每次会话都加载，压缩后会被重新读取。适合放构建命令、目录结构、团队硬性约定这些 Claude 需要始终知道的信息。

第二种，子目录的 CLAUDE.md（比如app/api/CLAUDE.md）只在 Claude 读到该目录下的文件时才加载。离开这个目录，这些指令就不在上下文里了。

Anthropic 给的建议是：根 CLAUDE.md 控制在 200 行以内，给它一个 owner，像审查代码一样审查对它的修改。

这件事在团队协作的大仓库里尤其明显。CLAUDE.md 很容易变成一个没人维护的公共配置文件，每个组都往里加自己的规范，没人删旧的。

最终每个工程师的每次会话都要加载所有团队的规范，不管跟当前任务有没有关系。

要解决也很简单，在 monorepo 里给每个团队目录配置单独的 CLAUDE.md，让团队只加载自己的规范。还可以用claudeMdExcludes 跳过不相关团队的文件。

总结起来一句话，不要把 CLAUDE.md 当成垃圾桶，而是寸土寸金的黄金地段。能不放的，就别放。

Rules：按路径触发，不白占上下文

Rules 是.claude/rules/ 目录下的 Markdown 文件。

不带路径限定的 Rule 跟根 CLAUDE.md 行为一样：每次会话都会加载、会话压缩后也会重新注入。其实本质上就是换了个目录放的 CLAUDE.md 内容。

真正有意思的是带路径限定的 Rule。给 Rule 加一个paths 字段，它就只在 Claude 碰到匹配路径的文件时才加载：

---paths: -"src/api/**" -"**/*.handler.ts"---所有 API handler 必须用 Zod 校验输入参数.

这条规则在你改文档的时候完全不占上下文，只有碰到 API 相关代码才会出现。

所以，凡是只对特定目录或文件类型生效的约束，都应该用 path-scoped Rule，而不是写在 CLAUDE.md 里。这是控制上下文膨胀最直接的手段。

什么时候用 Rule 而不是子目录 CLAUDE.md？当一个约束是跨目录的。比如“所有.handler.ts 文件都要校验输入”，它可能散布在多个目录下，放某一个目录的 CLAUDE.md 里不合适。

Skills：按需加载，用完即走

Skills 住在.claude/skills/ 目录里，每个 Skill 是一个文件夹，核心是一个SKILL.md 文件，里面包含了名称、描述和正文。

Skills 最关键的一个设计时只有名称和描述在会话启动时加载，正文只有在被调用时才进入上下文。

它的调用方式有两种：通过斜杠命令（比如/code-review），或者 Claude 根据任务自动匹配。

在使用 Skills 的时候，也需要注意会话压缩的行为：压缩时，已调用的 Skills 会被重新注入，但所有 Skills 共享一个总 token 预算。一次会话里调用太多 Skills，最早调用的会被丢掉。

Anthropic 给的原则是：流程性的东西放 Skill，不要放 CLAUDE.md。部署流程、发布检查清单、代码审查规范，这些都应该是 Skill。CLAUDE.md 只放 Claude 需要始终知道的事实。

我自己的经历可也是如此。之前 CLAUDE.md 里写了一大段“发布+验证流程”，后来拆成 Skill，不发布的时候这些指令就不占空间了。省下来的上下文让 Claude 能记住更多真正相关的事情。

Subagents：不是多一个帮手，是多一块白板

Subagents 是.claude/agents/ 目录下的 Markdown 文件，用 YAML frontmatter 定义名称、描述和工具权限，正文是这个子 Agent 的系统提示词。

名称、描述和工具列表在会话启动时加载。但正文永远不会进入主会话的上下文，它在子 Agent 自己的独立上下文窗口里运行，只有最终的摘要消息回到主会话。

这个设计对上下文管理的意义挺大的。Subagent 可以嵌套最多 5 层，动态工作流可以编排几十甚至上百个后台 Agent。中间结果全在脚本变量里，不污染主上下文。

那 Skill 和 Subagent 怎么选？Anthropic 给的判断标准是这样的：

• 用 Skill：当你希望流程在主线程里执行，你能看到每一步、随时干预。
• 用 Subagent：当侧任务的中间结果你不需要再看（深度搜索、日志分析、依赖审计），只需要一个最终摘要。

说白了，Subagent 的核心价值不是“多一个 Agent”，而是上下文隔离。让主会话保持干净，不被旁支任务的中间过程淹没。

我自己用 Subagent 最多的场景有两个：一个是让它先 explore 整个代码库，写一份结构报告回来，主 Agent 拿着报告再动手改代码；另一个是设计和实现分离，设计时需要进行大量的调研工作，但实现的时候只需要设计文档就足够了。

Hooks：让 Claude Code 100% 执行

Hooks 是在 Claude Code 生命周期事件上触发的用户定义命令。注册在settings.json 里，在文件编辑、工具调用、会话启动等事件上自动触发。

Hook 有五种类型：command、HTTP、mcp_tool、prompt 和 agent。前三种确定性执行（跑脚本、发请求、调工具），后两种用模型判断来决定输出。

Hooks 的上下文成本极低，配置在主上下文窗口外面，harness 直接执行。只有少数 Hook 的输出会回到主上下文（比如阻断型 Hook 的错误信息，让 Claude Code 知道为什么被拒绝）。

Hooks 在整套 Claude Code 体系里最容易被忽略但最重要的一点是：

“每次 X 都必须做 Y” 如果放在 CLAUDE.md 里，本质上是在靠模型的遵从性来保证执行。模型大多数时候会遵守，但在长会话、上下文压力大、或者遇到 prompt injection 的时候，它可以不遵守。

想要确定性执行，必须用 Hook。比如“每次编辑后跑 prettier”，这不该是一条指令让 Claude Code 选择执行，而应该是一个PostToolUse Hook 在每次文件写入后自动触发。

同理，“绝对不能做 X” 这种约束也不该靠 CLAUDE.md。用PreToolUse Hook 检查调用，exit code 2 直接阻断。对企业来说，更严格的配置可以用 Managed Settings，管理员部署、用户不可覆盖。

所以，你要注意，凡是在 CLAUDE.md 里写了“必须”或“绝对不能”的规则，都别忘了问自己一句：这条规则失败了会怎样？如果后果严重，就赶紧改成 Hook。

Output Styles 和 append-system-prompt：慎用，杀伤力大

最后两种方法放在一起说，它们都作用在系统提示词层面，威力大但副作用也大。

Output Styles 是.claude/output-styles/ 目录下的文件，注入系统提示词，永不压缩。注意一个关键细节：自定义 Output Style 默认会替换 Claude Code 的默认系统提示词，除非在 frontmatter 里设置keep-coding-instructions: true。

换句话说，一旦用了自定义 Output Style，Claude Code 默认的那些行为指导（怎么控制变更范围、什么时候加注释、安全关注点、跑测试再报完工）全部会被覆盖。Claude Code 就从一个软件工程助手变成一个通用助手了。

所以 Anthropic 的建议是：先看看内置的 Proactive、Explanatory、Learning 三个样式够不够用，再考虑自定义。

append-system-prompt 是另一种用法，它是 CLI 启动时传入的 flag，只对当前会话生效，不会持久化。它是纯追加的，不会替换默认行为，一般适合临时加一些格式偏好或领域知识。

我觉得大多数人不需要碰 Output Styles。内置样式加上 CLAUDE.md 已经够用了，除非你真的要把 Claude Code 改造成一个完全不同的角色。

别踩这些坑

最后整理一下 Anthropic 给的“反模式”清单，基本都是我自己踩过或见过别人踩的：

第一个是把“每次 X 都必须做 Y” 这种强制性约束写在 CLAUDE.md 里。模型的指令遵循和代码自动执行是两回事。如果这个行为必须可靠发生，一定要用 Hook。同理，“绝对不能做 X” 也不该靠 CLAUDE.md，禁止性约束在 prompt injection 面前毫无抵抗力，要用 Hook 或 Managed Settings 做墙纸约束。

第二个是把流程放在 CLAUDE.md 里面。CLAUDE.md 应该只放 Claude Code 需要始终知道的事实以及它最常犯的一些错误的经验教训，而流程则放到 Skills 里面。

第三个是 Rule 不加 paths。一条只对src/api/ 生效的规则如果不加路径限定，效果等同于在 CLAUDE.md 里多了一行，每次都加载，每次都耗 token。个人偏好也是同样的道理，所有的配置方法都分为项目级和用户级，“永远用 semantic commit message” 这种个人习惯应该只放在本地，项目级只放团队共识。

速查表：7 种方法一览

这张表最有价值的一列是“上下文成本”。搞清楚哪些指令需要全程驻留、哪些只在触发时加载，是用好这套系统的关键。

写在最后

说实话，这篇官方指南没介绍什么新功能，这 7 种方法早就存在了。但它的价值在于第一次把每种方法的加载时机、压缩行为和上下文成本都讲清楚了。

这 7 种方法按 harness 设计的思路大致可以整理成为四层：

• 全局层（CLAUDE.md、unscoped Rules、Output Styles）：高成本、高权威，克制使用
• 触发层（path-scoped Rules、子目录 CLAUDE.md、Skills）：按需加载，中低成本
• 隔离层（Subagents）：零主上下文成本，只关注结果
• 确定性层（Hooks）：绕过模型，代码级保证

搞清楚这四层，大部分“Claude 为什么忽略我的指令”的问题就有了答案。不是模型不听话，是你把指令放在了错误的层级，或者上下文爆满之后它被忽略掉了。

我推荐的实践顺序是这样的：所有项目第一步先给根 CLAUDE.md 瘦身，拆出去的流程丢进 Skills，跨目录的约束用 path-scoped Rules，必须 100% 执行的规则用 Hooks 做约束。然后在日常使用中持续观察、持续迭代修改，如果发现有的指令被忽略了，那大概率是相关的指令放错了层级。

上下文窗口就那么大，每一行指令都有成本。把对的指令放在对的层级，比写更多指令管用得多。

原文：Steering Claude Code: skills, hooks, subagents and morehttps://www.anthropic.com/engineering/claude-code-best-practices

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

这两天一个新的 AI 编程范式 Loop Engineering 火了。Peter Steinberger 发推说你不应该再 prompt coding agent，应该去设计 prompt agent 的 loop，两天冲到 800+ 万阅读。随后 Claude Code 负责人 Boris Cherny 也表达了类似的观点，他管理的几百个 agent 自己读 GitHub 和 Slack、自己决定干什么，过去 30 天合并了 250 多个 PR，全部由 Claude Code 完成。

今天 Anthropic 刚刚发布了最新的 Claude Fable 5 和 Mythos 5 模型，甚至能够把数月的工作压缩至几天内完成。

说实话挺有感触的。上个月 Codex 推出的 /goal 功能其实就是最好用的 Loop Engineering 实现，配合广受好评的 GPT-5.5，工作完成度一下子就把之前经常使用的 Claude Code + Ralph loop 组合拉开了，我自己的大部分工作也都切换到了 Codex 上面来。

但用了几个月之后，我发现 loop 好不好用，其实取决于一个很朴素的问题。这个问题后面会展开，先说说 Loop Engineering 到底是什么。

Loop 说白了就是一个替你 prompt agent 的小系统：给 agent 发任务，读结果，判断做完没有，没做完就继续执行。以前我们用 Claude Code，要靠你自己输入 prompt、盯着输出、中断后再输入，如此循环往复，你就是那个循环。Loop Engineering 则是把你从循环里摘出来，但如何摘出来是个问题。

什么是 Loop Engineering

说到 Loop Engineering，我觉得最早可以追溯到 ReAct 模式：你输入提示词后，模型推理、调工具、读结果、循环重复直到没有工具调用时结束。这个循环后面演变成了 AI Agent 最基本的执行过程，是所有 Agent 都必备的基础模块。

不过只有这个循环明显还不够，AI 经常会在执行完一些工具调用后停下来等待你的输入。所以后来就有了 Geoffrey Huntley 的 Ralph loop 模式：通过一行 bash，把同一个 prompt 文件反复发送给 agent 执行，直到模型说工作完成了才停止。

Ralph loop 推出后的确解决了很多长程任务的执行问题，但问题也不少：模型跑着跑着自己宣布胜利，任务清单还剩大半；状态文件越写越离谱，跨会话之后新 agent 看到的进度跟实际对不上；偶尔整个循环还会直接卡死。

后来，Codex 推出了第一个真正可以稳定执行长程任务的功能 /goal，通过状态持久化+权限控制+强制自审三层机制解决了这些问题。详细的实现原理和使用方法可以参考我之前写的《Codex /goal 上线后，我把 Ralph loop 卸了》，这儿就不展开了。

Claude Code 在随后的版本里也增加了相同的 Goal 功能，不过需要注意 Opus 模型相对 GPT-5.5 还是有差距，效果稍微差一些（Claude Fable 则会好一些）。

跟定时任务有什么区别

乍看起来，Loop Engineering 就像是把之前的定时任务改了个名字，底下都是让 AI 大模型不停地执行任务。

但这两者有很大的区别：

• 定时任务的目的是触发任务的执行，执行的时间是固定的。至于到了时间执行啥取决于你给它的指令，可以是脚本、提示词甚至是 Goal 这种复杂的任务目标；
• Loop Engineering 的目的是确保 AI 大模型能够以正确的方法完成你的任务目标，它能够自己查看状态、决定是否执行下一步，循环往复直到目标完成。

在实际使用中，你可以把它们结合在一起来使用。比如，使用定时任务来触发 Github issue 的排查，而在排查每个 issue 时使用 Loop 来确保任务执行的质量。

怎么用好 Loop Engineering

那怎么用好 Loop Engineering？

我的建议是，目标写清楚、步骤有边界、每步有检查、有明确的停止点，确保 Agent 能够闭环迭代就可以了。

Cherny 也给过几条建议，可以参考：权限开 auto 模式、让 Claude 自己编排子 agent、用 /goal 模式、跑在云端，以及自我验证。前四条大家都在用，但最重要的其实是最后一条：验证。产出没人查，方向迟早跑偏。

为什么验证这么重要？大模型给自己的产出打分很不可靠，但如果换一个独立上下文的子 agent 来评估，效果就稳定得多。Lance Martin 的测试里（链接见最后），Fable 5 最好的运行有 73% 的结论经过了独立验证，Opus 4.7 中位数只有 17% ，差距主要就在这儿。

这跟我翻 Codex /goal 源码看到的设计思路是一致的。模型能宣布做完，但不能说预算快没了先撤。再配上每轮注入的自审，强制逐项对照真实文件和测试结果。简单来说，你可以逼模型继续干活，但你逼不了它承认自己没干好，能戳穿它的只有独立的验证。

写在最后

回到开头说的那个朴素问题：你要不要给手头的事上 loop？判断标准跟我在 /goal 那篇里说的一样：你能不能把“做完了”写清楚。能写清楚，loop 确实能帮你省掉大量重复劳动。但如果连做完的标准都说不清，那还是老老实实一步步来吧。

另外还要提醒一点，Loop Engineering 绕不开一个现实问题：烧 token。跑起来烧钱比你想的快，自修正、验证子 agent、重试，每一步都在消耗 token。说白了，你是 token 富人还是 token 穷人，直接决定了你对 loop 的态度。如果你对 token 消耗比较敏感，建议优先使用订阅制的产品而不是直接调 API，能省不少钱。

如果你想了解更多的 Loop Engineering，推荐阅读：

• Addy Osmani: Loop Engineering：https://addyosmani.com/blog/loop-engineering/
• Lance Martin: Designing loops with Fable 5：https://x.com/RLanceMartin/status/2064397389189071163
• Boris Cherny 谈自我验证：https://x.com/bcherny/status/2064426115255730578
• Codex /goal 上线后，我把 Ralph loop 卸了：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Codex 桌面版最近口碑爆了。我自己已经把很多工作都切到了 Codex 客户端的 Goal + GPT-5.5 上，一不小心就用了 20 多亿 token。

不过很多人第一次用 Codex，还是把它当一个更强的 coding agent，用来读仓库、改代码、跑测试、写 PR。这当然没错，Codex 的基本功能确实还是代码编程。但它的桌面客户端已经不只是编程工具了。Skills、Computer Use、浏览器操控、Gmail 和 Calendar 等等各种连接器和插件一路加上来，早就成了一个通用 Agent 客户端。甚至你还可以通过 ~/.codex/config.toml 配置文件给它接入 DeepSeek、Kimi 等第三方模型。

我让 Codex 扫了一下最近这个月的会话历史，总结了一些日常的使用方法，再加上自己的补充，整理成这篇分享给大家。如果你还不熟悉 Codex 桌面客户端的使用方法，可以参考 Jason Liu 最近写的 Getting the most out of Codex 文章（链接见文章最后），今天的文章假设你已经了解了 Codex 的基本用法。

1. 先给足上下文，再开始任务

AI Agent 最大的问题不是不会干活，而是太容易基于幻觉自信乱干。你不告诉它项目背景和规则，它就按自己的理解来，很容易过度自信，走向错误的方向。

要解决也很简单，写一个 AGENTS.md 放在项目根目录。Codex 每次打开项目会自动读这个文件，里面可以写项目背景、技术栈、代码规范、常见坑、测试方式，相当于给它一份新人上岗须知。如果任务涉及特定模块，还可以在 prompt 里直接指定“先读 docs/xxx.md 再动手”，让它从文档而不是从猜测开始。

Codex 桌面端有个置顶会话挺好用的，你可以把最常使用的会话固定在前面。不要把 Codex 的会话当成临时会话，而是一个持续的工作现场。Codex 已经能够自动帮你压缩会话上下文，再加上它的记忆功能，长时任务不需要新开会话，可以持续在同一个会话里持续下去。

这也是我觉得 Codex 最好用的一点，避免了很多上下文交接的问题，可以真正帮你干大活了。

2. 验证比生成重要得多

说实话，让 Codex 写代码，随便一个 coding agent 都能做个七八成。真正拉开差距的是验证，要拿真实的验证结果说话。

验证可以是很多东西：测试套件、benchmark、Web 界面截图、发布前 checklist 等等，也就是之前你自己手动做的所有操作应该都描述清楚，交给 Codex 让它去负责。

特别是在用 Goal 跑长任务的时候，这点更是必不可少。比如，“帮我把这个计划实现完” 看起来有目标，但其实病没有明确的停止条件。而好的 Goal 应该带上清晰的验证器：“完成后必须通过 xx 测试、浏览器检查和人工可审阅的变更摘要。如果验证失败，先修验证失败的问题，不要直接宣布完成。”

没有验证的 Goal，其实只是愿望。

3. 批量操作前加一道审查门

从我自己的使用历史来看，审查和清理类任务最容易翻车。Codex 默认倾向是搜到了就改，找到了就删。这时候，你需要主动在提示词里面拦一下。

具体做法是在 prompt 或 AGENTS.md 里加上审查规则。比如“批量修改前先列出所有命中并按类型分组（需要改 / 可能需要改 / 不该动），等我确认再执行”。清理旧分支也一样：“先输出 merged 和 unmerged 分支对比，标注哪些旧实现已被 main 覆盖，不要直接删”。

举个例子，代码库里搜到一堆旧 token 引用，不是所有命中都该删。有些是测试隔离需要的，有些是运行时继承的，真正有问题的可能只有几个。如果不加审查这道程序，Codex 可能会机械地全部清掉，然后测试挂一片（针对这个例子，加上上一步说的验证其实可以自动修复回来，但会浪费很多时间+token）。

这种不是高大上的 AI 能力，但特别体现人的判断，需要你把经常看到的坑告诉 AI，让它去主动规避。

4. 先配工具，再谈智能

模型当然重要，但真正决定 AI 能干什么的，是配置的工具、权限、上下文和验证方式。插件决定 Codex 能碰到哪些外部世界，Skills 决定它碰到这些世界时该怎么做。我自己常用的插件和 Skills 列在了文末附录里，这里只说一个最容易被忽略的点。

大多数人写 Skill，会把它当成说明文档：告诉 Codex 该做什么、按什么顺序做。这当然有用，但 Skill 真正值钱的部分不是流程，而是 Gotchas，也就是每次 Codex 犯错之后补进去的“别踩这个坑”。

比如：

• 这个数据源经常不可用，不要猜。
• 这个任务结束前必须跑某个验证。
• 这个工具第一次会失败，失败后应该换另一种方式。
• 这个类型的 review 不能机械接受，要逐条验证。
• 这个工作流适合先搜宽一点，再只打开高价值候选。

一开始写个十几行骨架就够了，用一段时间后它自然会长成一个成熟 Skill。好用的 Skill 不可能一次写好的，都是拿实际经验养出来的。

5. 用 Side Panel 边看边改

以前用 AI 做文档、网页、PPT，最烦的是上下文切来切去。AI 在聊天框里生成，产物在另一个窗口打开，发现问题又要截图回来描述。来回几次，人和 AI 都开始丢上下文。

Codex 的 Side Panel 可以把产物留在工作流里直接改。具体做法是：让 Codex 生成一个 index.html 或者打开一个 localhost 页面，它会在侧边栏渲染出来。你一边看渲染结果，一边在同一个线程里说“这个按钮太大了”“表格第三列数据不对”，不用截图，不用切窗口。

有两类任务特别适合这个场景。一类是前端和网页，直接在旁边检查样式、交互和移动端适配。另一类是文档型产物，报告、表格、PPT、数据分析页面放在旁边边看边改，比导出再反馈高效得多。

6. 重要上下文写到文件里

会话会压缩，模型可能会切换，对话里的重要决策和验证方式如果不主动写到外部文件里，就很容易会被丢掉。

我自己在做长任务的时候（特别是那种跨天的任务），会特意让 Codex 总结记录下 summary、checkpoint、handoff 文档和下次接手的入口说明。下一个会话或者新任务可以接着这些文件继续，不用从零开始。

要实现也很容易，不需要搞复杂的记忆系统。一个 TODO.md 写待办事项，再加几个文件夹分类放踩坑记录和项目状态，就够了。关键是可检查、可编辑、可删除。Codex 内置的 Memory 和 Chronicle 可以当快速回忆层用，但替代不了外部文件。只有写进文件里的记忆，才有机会变成系统。

7. 随时在线，随处接管

长任务跑着的时候，你不需要一直坐在电脑前。在 ChatGPT 手机端连上你的 Mac 或远程机器，可以随时给远端的 Codex 下任务，或者回复 Codex 需要你介入的问题。

一般来说，当你把任务定义清楚之后，就可以通过 Goal 来启动长时任务，然后等着 Codex 的通知就可以了。你可以在手机上随时能看到它的输出、审批命令、中途纠偏。不用坐在电脑面前盯着，同时关键决策又可以随时介入。

如果你有 Linux 服务器，Remote SSH 更值得配一下。Codex 会自动读取本地 SSH config 里的主机列表，连上之后直接在远程服务器里跑任务。日常运维、配置管理、代码部署，SSH 连上就能让 Codex 干活，电脑端/手机端都可以随时跟进。配合前面说的 AGENTS.md 和文件记忆，远程接入的时候上下文还在，不用重新交代背景。

8. 定时自动化：让会话自己醒过来

前面说的远程接入是“你主动去给 AI 下发任务”，而定时自动化是“让 AI 主动来找你”。

具体做法是给置顶线程设一个 Thread Automation。跟普通定时任务不同，Thread Automation 每次触发会回到同一个线程，带着上次的上下文继续工作。它知道上次检查到了哪里，哪些事项已经处理过，哪些数据源接不上。

我自己用得比较多的是两类。一类是信息聚合：每天早上自动检查未读邮件和 IM 消息，按优先级整理好，等我打开的时候直接看结论。另一类是监控类：定期检查 PR 列表、问题反馈或者关注列表，有新内容就整理摘要，没有就不打扰。

这儿有一点需要注意的是不要让自动化假装全知。没有就是没有，不要编造虚假信息；依赖不可用就直接报不可用，不要自作聪明。

9. 不只是代码：邮件、调研、文档也能跑

文章到这里，其实大部分的场景还都是跟代码相关的。但 Codex 桌面客户端接上 Gmail、Browser、Documents 这些插件之后，很多非代码任务也都能跑的不错。

我自己用得比较多的几个场景：让 Codex 过一遍项目和相关邮件，做图文并茂的汇报 PPT；给一个调研主题，让它用 deep-research 搜多个来源，整理成带出处的摘要；会议前把相关文档和之前的讨论丢给它，让它准备一份简要；写完公众号文章后让它排版成微信公众号格式并生成封面图。

这些任务的共同点是：以前要在好几个工具之间切来切去，现在可以在一个会话里串起来，省掉了大量的不同工具和上下文切换。

10. 别追求全自动，要把主动权留在人的手里

Codex 好用，也可以自动化很多任务，但并不意味着你就要完全放手让它全自动去自己玩。

恰恰相反，你越把它接进真实工作流，越会看到很多边缘问题：权限、登录态、数据源缺口、工具失败、上下文压缩、验证不充分、自动化误触发等等。

所以更合理的用法是：让 Codex 做上下文收集、执行、验证和初步整理，人保留判断、授权和最终责任。Codex 的 Steering（中途纠偏）和 Queuing（排队追加下一步）就是为这个设计的。真实的工作往往都是边看边改、边发现边调整，不是“人给一个完美需求，让 AI 一次性完成”。

也就是说，人不应该退到系统外面，而是站在系统里面，负责纠偏、验收和更新规则。

Codex 的语音输入也是一个让人留在 loop 里很好的设计。它不是让你口述代码的，而是在想法还没成型的时候随时输入给 Codex，或者在 Codex 走偏的时候随时修正它。语音输入不需要很完整，有错别字啥的都没关系，模糊指令对一个已经掌握足够上下文的 AI 来说已经足够让它理解你的意图。

相关链接：

• Jason Liu Getting the most out of Codex：https://x.com/jxnlco/status/2057153744630890620
• Codex 功能文档：https://developers.openai.com/codex/app/features/
• Codex Skills 文档：https://developers.openai.com/codex/skills

附录：我常用的插件和 Skills

以下是文中第 4 条提到的工具清单，供参考。

常用插件：

• Browser：本地网页、localhost、侧边栏里的页面检查和截图。
• Chrome：需要登录态、真实 Chrome profile、远程网页操作时用。
• Computer Use：只能通过桌面 GUI 完成的工作。
• Gmail：搜索邮件、读取正文、筛选待办、草拟回复。
• Documents / Presentations / Spreadsheets：文档、PPT、表格类 artifact。
• Product Design：早期产品想法、原型、截图到交互稿。
• Build Web Apps：前端应用、组件、浏览器验证。
• HyperFrames / Remotion：视频、动画、程序化内容。
• Superpowers：计划、TDD、系统化调试、验证、代码 review、开发分支收尾。
• Codex Security：安全扫描、威胁建模、finding 修复。

常用 Skills：

• brainstorming（Superpowers 插件自带）：头脑风暴和 SPEC 设计。
• handoff：将当前对话整理成交接文档（用于新开会话接手）。
• deep-research：多源搜索调研。
• claude-skill：调用 Claude Code 写文档、做设计或者跟 Codex PK。
• twitter-cli / xfetch：读取和搜索 X/Twitter 内容。
• xiaohongshu-cli：搜小红书内容。
• youtube-transcribe-skill：解析下载 Youtube 视频字幕。

相关 Skills 的安装方法：

npx -y skills add mattpocock/skills -g -s handoffnpx -y skills add feiskyer/codex-settings -g -s claude-skillnpx -y skills add feiskyer/codex-settings -g -s deep-researchnpx -y skills add feiskyer/codex-settings -g -s youtube-transcribe-skill

几个 CLI 工具的安装方法：

uv tool install xiaohongshu-cli twitter-cli
npm install -g xfetch-cli

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 官方博客《A harness for every task: dynamic workflows in Claude Code》，由 Anthropic 工程师 Thariq Shihipar 和 Sid Bidasaria 撰写。

Claude Code 的默认模式是单 Agent，一个上下文窗口搞定规划和执行。大多数编程任务这就足够好用了。

但是也有很多场景你怎么优化都跑不好。单 Agent 在长时间运行、大规模并行、需要对抗性验证的任务上，有三个已知的退化模式：

第一个是偷懒。让它做一轮安全审查，50 个检查项查到 20 个就宣布完成了。这不是幻觉，是 Agent 在长上下文里的行为退化。第二个是自我偏爱。让它评判自己的产出，它天然倾向于给好评，需要严格验证的场景里这是致命的。第三个是目标漂移。上下文压缩是有损的，每压缩一次，原始需求里的边缘条件、约束细节就丢一点。时间长了之后，Agent 在优化的目标可能已经偏离了你最初给它的任务。

这三个问题不是模型能力问题，是单上下文窗口同时承担规划和执行带来的架构局限。Anthropic 显然也清楚这一点，所以之前陆续搞了 Research、安全审计、Agent Teams、Code Review 这些定制 Harness，每个都是针对特定任务类型写死的调度逻辑。

上周他们把这个能力泛化了：Claude Code 现在可以自己写调度逻辑，针对当前任务实时生成编排脚本，也就是 Dynamic Workflows。

工作原理

动态工作流的核心思路是：用独立的子 Agent 各自占一个干净的上下文窗口，每个子 Agent 只干一件事，由一个确定性的 JavaScript 脚本来调度它们的执行顺序和依赖关系。

动态 vs 静态：区别在哪

之前用 Claude Agent SDK 或者claude -p 来编排多个 Claude Code 实例，本质上是静态工作流。你得提前写好脚本，考虑各种边界情况，写出来的东西往往比较通用。

动态工作流不一样。Claude Code 自己看任务，自己写调度脚本，针对当前这一个具体任务量身定制。Opus 4.8 的能力已经足够让它自己写出高质量的 Harness。

我自己试了一下，感受是：对于那些你本来就知道怎么拆分的任务，静态工作流更可控。但对于"我大概知道要做什么，但不确定最优的拆分方式"的场景，让 Claude Code 自己决定怎么调度确实省事。

六种调度模式

Claude Code 在构建动态工作流时会组合使用几种基本模式：

最基础的是分类路由，一个分类 Agent 判断任务类型，分发给不同的处理 Agent。也可以反过来，在最后加一个分类器决定输出格式。

用得最多的是扇出合并。把任务拆成很多小步，每个小步一个独立 Agent，最后一个合并 Agent 汇总结果。好处是每个子 Agent 有干净的上下文，互不污染。

对抗验证是直接针对自我偏爱问题的解法：每个生成 Agent 配一个独立的验证 Agent，专门挑毛病。生成过滤类似，先大量生成，再按标准筛选去重，只留通过验证的。

然后是锦标赛模式。N 个 Agent 用不同策略做同一件事，两两比较淘汰，留下赢家。最后是循环到完成，不设固定轮次，一直跑到满足停止条件为止。

这些模式可以组合。比如先扇出，每个分支内部做对抗验证，合并时再跑一轮锦标赛选最优方案。

实际能干什么

那这些模式实际能用在哪？原文列了不少场景，我挑几个觉得实用的说。

大规模迁移和重构

Bun 从 Zig 重写成 Rust 就用了工作流。核心思路是：把需要改的地方拆成独立单元（调用点、失败的测试、模块），每个单元派一个子 Agent 在独立的 worktree 里修，另一个 Agent 做对抗性 Review，通过了再合并。

这个场景我觉得价值最大。平时做大规模重构最头疼的就是改着改着上下文丢了，或者改了 A 忘了 B 也要跟着改。每个修改点一个独立 Agent，天然避免了交叉污染。

深度验证

如果你写了一篇技术文章，里面有大量事实性声明，可以用工作流让一个 Agent 先把所有事实性声明提取出来，然后每个声明派一个子 Agent 去核实。还可以再加一层，验证核实 Agent 引用的信息源本身是否可靠。

排序

对定性内容排序（比如按 Bug 严重程度排 1000 条工单），单次 Prompt 的质量会随数量急剧下降。工作流的做法是用锦标赛模式，两两比较。比较判断比绝对评分可靠得多，而且每次比较是一个独立 Agent，确定性的循环逻辑只负责维护对阵表。

规则遵守

有时候明明在 CLAUDE.md 里写了规则，但 Claude Code 跑着跑着就忘了。这时候，就可以用工作流做一个验证层：一条规则一个验证 Agent，每个验证 Agent 用怀疑论者的视角去检查是否违规。

反过来也行：扫最近的 session 日志和 Code Review 评论，找反复出现的纠正，聚类、验证（这条规则真的能防住之前的错误吗？），然后把确认有效的提炼成新的 CLAUDE.md 规则。

根因分析

调试最怕的是认定了一个假设就一路追到底。单 Agent 在一个上下文窗口里特别容易犯这个错误。工作流可以结构性地避免：分别从日志、文件变更、数据状态生成独立假设，每个假设面对一组验证者和反驳者。

这个模式不只适用于代码。销售数据下降、数据管道故障、任何需要事后复盘的场景都能用。

大规模分流

每个团队都有处理不完的支持队列。工作流可以对每条工单做分类、去重（跟已有的 ticket 对比）、尝试自动修复或升级给人。

这里有个有意思的设计模式叫隔离区：读不可信外部内容的 Agent 不允许执行高权限操作，高权限操作由另一个 Agent 负责。读和写分离，避免 prompt injection 导致的越权。

什么时候不需要工作流

动态工作流消耗的 token 显著更多，适合复杂、高价值的任务。

日常写代码，问自己一个问题：这件事真的需要 5 个 Reviewer 组成的评审团吗？大多数常规编程任务可能并不需要。

我的判断标准是：如果你能在 Prompt 里一句话描述清楚要做什么，而且做完之后你自己能快速验证结果，那就不需要工作流。需要工作流的场景通常有两个特征：任务可以被拆成独立的并行单元，或者验证成本高到你不想自己一个个检查。

用法和技巧

开启动态工作流的方法有两种：直接在 Prompt 里要求 Claude 创建工作流，或者用触发词ultracode。

描述调度模式的时候要具体。不是”用工作流做这件事”就完了，而是告诉 Claude Code 你想要什么样的验证方式、什么样的并行策略。上面那六种模式的名字可以直接用在 Prompt 里。

对于可重复的工作流（分流、监控、验证），搭配/loop 设置定期执行，/goal 设置硬性完成条件。工作流很容易跑飞，在 Prompt 里加一句“用 10k token”（大概一两轮对话的量）就能限制消耗。

工作流运行时按s 可以保存脚本，存到~/.claude/workflows 或者通过 Skill 分发给团队。

几个实际的 Prompt 示例

原文给了一组示例 Prompt，我觉得比理论解释更直观：

• 这个测试大概 50 次跑挂一次。用工作流复现它，形成竞争性假设，不找到经得起验证的根因不许停。
• 用工作流扫我最近 50 个 session，找到我反复在纠正的模式，把重复出现的提炼成 CLAUDE.md 规则。
• 拿我的商业计划，用工作流让不同 Agent 分别从投资人、客户、竞争对手的视角撕它。
• 这个文件夹有 80 份简历，用工作流按后端岗位排名，前 10 名交叉验证一遍。先用 AskUserQuestion 问我评分标准。
• 用工作流把我们的 User 模型全局重命名成 Account。

共同点很明显：都是可以拆分成独立并行单元的任务，并且都需要某种形式的验证或对抗。

写在最后

三个月前的《为什么单 Agent 搞不定复杂应用？Anthropic 的 Harness 设计给出了答案》，当时聊的是 Anthropic 用 Generator-Evaluator 模式做长时间全栈开发。那套架构需要人手动搭建，三个 Agent 跑 6 小时花 200 美元。

动态工作流的思路是把"搭建 Harness"这件事也交给 Claude Code 自己。不再需要你预先想好怎么拆分、怎么验证、怎么合并，Claude 看了任务之后自己决定。

这是不是靠谱？说实话，我的体感是：对于你已经有经验的任务类型，自己写静态工作流更可控；对于探索性的任务，让 Claude Code 自己决定调度方式确实能发现一些你没想到的拆法。两者不矛盾，动态工作流可以保存下来变成静态的。

不过话说回来，Harness 可能也像 prompt engineering 一样，是大模型发展过程中的一个中间状态。模型不够强的时候需要人写精巧的调度逻辑，需要多个 Agent 互相制衡才能把一件事做好；模型足够强了，这些逻辑就会被内化。今天你还在想怎么编排子 Agent，也许下一代模型根本不需要外部编排，自己就能在内部完成任务分解和对抗验证。当然，这个"也许"到底要多久，没人知道。

相关资源：

• 原文链接：https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
• 动态工作流文档：https://code.claude.com/docs/en/workflows
• 前作：Bun 重写（Jarred Sumner）：https://x.com/jarredsumner/status/2060050578026189172

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程团队官方博客《How Claude Code Works in Large Codebases: Best Practices and Where to Start》，原文链接：https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start。本文在翻译基础上做了整理和补充。

Claude Code 在小项目里用着真挺丝滑的，基本上你碰到的问题它都能帮你解决。

不过一旦搬到大代码库，体验就开始打折扣。让它查找一个函数，grep 出来上千条匹配，你的上下文空间直接就被淹没了；改一个子服务，它非要跑全项目的测试用例，跑就跑吧还动不动超时偷懒，有时甚至自作聪明顺手改了一堆不该改的代码。

你在大型代码库里使用 Claude Code 是不是也碰到过这些问题？反正我是经常碰到。

前两天 Anthropic 工程团队发了一篇官方博客 How Claude Code Works in Large Codebases: Best Practices and Where to Start），系统讲解了大型代码仓库中用好 Claude Code 的方法论，推荐所有 Claude Code 用户都读一读。

下面是逐节的翻译，每一节我加上了自己的注解。

一、Claude Code 是怎么浏览代码的

Anthropic 博客一开头就讲了一个容易被忽略的事实：Claude Code 在大代码库里搜代码的方式，跟我们一直理解的 RAG 方式是完全不同的思路。

RAG 的做法是把整个代码库做 embedding，查询时检索相关片段。听起来挺合理的，但在大代码库里有个死结：embedding 流程追不上工程团队的提交速度。等你查询的时候，索引反映的是几天甚至几周前的代码，搜出来的可能是已经被重命名的函数，或者已经被删掉的模块。

Claude Code 走的是另一条路，叫 agentic search。它就像一个工程师那样找代码：遍历文件系统、读文件、grep 关键字、跟着 reference 跳转。所有动作都是实时的，不依赖任何索引。

这个差异不是技术孰优孰劣，而是适用场景不同。小到中型、变化没那么频繁的代码库，RAG 可能更快。但大代码库、活跃项目、频繁重构这些场景，agentic 是唯一靠谱的方式。

要用好 agentic search 也有它的前提：你的代码库得让 Claude Code 快速定位到具体的位置。如果目录命名混乱、没有 README、没有任何线索告诉它从哪开始看，再聪明的模型也得绕远路遍历大量无关文件，导致上下文空间被白白浪费。后面 Anthropic 讲的所有最佳实践，本质都是在解决这个问题。

二、harness 比模型更重要

Anthropic 在原文里给了一个清单，列出了塑造 Claude Code 能力的 harness 七件套：

• CLAUDE.md
• Hooks
• Skills
• Plugins
• LSP
• MCP servers
• Subagents

这七件套加起来，决定了同样的模型在你手里跑出来是什么效果。

我自己的体验跟这个清单完全一致。同样是 Claude Opus 4.6 模型，裸装 Claude Code 写代码，跟调好 CLAUDE.md 、装备 subagent 、配上 skills 之后相比，效果不是一个量级的。

这跟之前 Anthropic 在 Harness 设计那篇文章（《为什么单 Agent 搞不定复杂应用》）里讲的逻辑是一致的：模型能力决定了天花板，harness 决定了你能走到天花板的多少。差的 harness 把模型能力浪费一大半都不夸张。

下面把这七件套一个一个聊聊。

三、CLAUDE.md：分层是最大的杠杆

CLAUDE.md 是每个会话启动时自动加载的上下文文件。Claude Code 会从当前目录往上一直走到根目录，把每一层的 CLAUDE.md 都读进来。

这个加载机制是叠加的，所以分层非常关键。Anthropic 给的原则是：根 CLAUDE.md 只放指针和关键注意事项。

Anthropic 还给了几条特实用的具体建议：

第一，给子目录创建 CLAUDE.md，而不是只是在根目录里。Claude 自动会往上走，所以你启动它的时候 cd 到任务相关的子目录，加载到的上下文最聚焦。

第二，lint 和 test 命令按子目录配置。改一个子服务却跑全项目的 test，是大代码库里最常见的浪费。耗时耗力不说，跑出来的输出信息还容易把 context 全淹了。子目录的 CLAUDE.md 应该写清楚“在这个目录下，跑测试用 X，跑 lint 用 Y”。

第三，用.ignore 文件（ripgrep 的标准 ignore 格式）排除生成目录、build 产物、第三方代码这些噪音，同时把permissions.deny 规则写到.claude/settings.json 里。后者会跟着 git 一起 commit 出去，团队每个人都自动生效，不用各自配。如果某些开发者就是要碰生成目录，可以在自己的本地 settings 里覆盖项目级规则，不影响其他人。

第四，如果你的代码库就是没有传统目录结构，那写一个 codebase map：根目录放一个简短的 markdown 文件，列出顶层目录每个是干嘛的，一句话描述，给 Claude Code 一个目录索引。

这一节是整篇文章里最值得反复读的。CLAUDE.md 调好，其他六件套的价值才能放出来。

四、Hooks：让你的 setup 自我进化

Hooks 是绑定在事件上的脚本。Stop hook 在 session 结束时跑，Start hook 在开始时跑，另外还有 PreToolUse、PostToolUse 这些。

Anthropic 给了三个典型用法：

第一个是 Stop hook 可以让 Claude 自己回顾这个 session，分析有什么经验值得沉淀，然后主动提议更新 CLAUDE.md。这其实是把 self-improvement 自动化了，让其越用越聪明。

第二个是 Start hook 可以根据当前路径或者当前用户动态加载团队特定的上下文。比如你今天在前端目录，自动加载 UI 团队的约定；明天切到后端目录，自动换成后端的那一套。每个开发者就不用手动维护自己模块的 setup 了。

第三个是强制规则用 hook 而不是 prompt。比如自动跑 lint、提交前必须过 typecheck、危险命令拦截，这些都很适合。Prompt 是建议，hook 是约束，能用 hook 就别只写在 prompt 里。这点跟我自己的体感完全一样：让模型自觉其实远不如代码里拦住它来得靠谱。

在我看来，Hooks 是 Claude Code 里最被低估的扩展点，配置门槛比 skill 低，杀伤力却大。建议先把基础 hook 配上，再去考虑其他扩展。

五、Skills 和 Plugins：把好东西散播开

Skills 解决的是“专业能力按需出现”的问题。

大代码库里任务类型几十上百种，每个 session 都把所有能力塞进上下文是不现实的。Skills 用的是 progressive disclosure 的思路：能力描述常驻 context，具体内容只有用到才加载。这次 Anthropic 还提了一个进阶用法，skill 可以按路径 scope，只在特定子目录激活，避免无关 skill 互相打架。

说实话，写好一个 skill 门槛其实不低。Anthropic 之前专门写过一篇（《写好一个 Skill 有多难》），踩了几百个坑才总结出来一套规则。这次大代码库文档里强调的“按路径 scope”算是新增的进阶建议。

Plugins 解决的是“好配置散播开”的问题。

大代码库里最常见的一个现象是：少数几个老员工把 skill、hook、MCP 配置摸透了用得很爽，新人入职完全不知道有这些东西。这种 tribal knowledge 进不了生产力分布，对组织来说是很可惜的。

Plugin 把 skill、hook、MCP server 打包成一个安装包，新人一条命令装完就跟老员工同样的能力。我自己开源过两个仓库（claude-code-settings 和codex-settings），初衷就是这个：把自己折腾出来的配置整理出来，让别人不用再走一遍弯路。

升级路径也是 plugin 的优势。所有人都装同一个 plugin，你修了一个 skill 的 bug，下一次更新所有人都拿到。靠口口相传根本做不到这种分发。

六、LSP：从 grep 到 symbol

这一段可能是文档里最技术、但也最实用的一节。

Claude Code 默认搜代码靠 grep。grep 在小代码库还行，到了大代码库就是个灾难：你搜一个getUser，可能返回上千个匹配，分布在几百个文件里。Claude 为了搞清楚到底是哪个，得一个个打开看，context 瞬间被烧光。

LSP（Language Server Protocol）是编程 IDE 早就已经在用的东西。它知道你这个getUser 是哪个 class 的方法、有哪些 reference、定义在哪、被谁调用。把 LSP 的能力转给 Claude Code，搜索就从字符串变成了符号。

实际效果差距可能是几十倍。同一个查询，grep 返回的是上千条文本匹配，LSP 返回的可能只有几条，并且每一条都是真正引用这个符号的位置。Claude 不用再去打开一堆无关文件，context 也省下来了。

这个适用前提是你的语言有靠谱的 LSP，对 Go、TypeScript、Java、Python、Rust 这些主流语言都没问题。脚本类语言可能稍微弱一些。

七、MCP 和 Subagent：扩展和隔离

MCP server 主要是让 Claude 接入它本来够不到的那些东西：内部工具、私有 API、文档系统等等。我之前在《MCP 不只是开发工具》里聊过生产级 MCP 怎么搭，这里就不展开了。

这次有个新的角度挺值得提：专门写一个 MCP server，把代码库的结构化搜索包装成 Claude 可以直接调用的工具。比如“查找所有 implements 这个 interface 的 class”、“查找所有调用这个 deprecated API 的地方”。这类查询用 grep 做不到，用 LSP 部分能做，但用专用 MCP 是最干净的。

Subagent 这个我想专门聊一下，因为是我用得最多的一个。

简单来说，Subagent 就是一个独立的 Claude Code 实例，有自己的 context window，接到任务、做完工作、只把最终结果返回给主 agent。

我用 Subagent 用得最多的场景就是 explore/edit 拆分。让一个 read-only 的 Explore subagent 先去摸目录、读文件、画出系统结构，写到一个文件里。主 agent 拿到这份报告，再带着完整图景去改代码。

为什么不让主 agent 自己 explore 自己 edit？因为 explore 阶段会读几十个文件，每个文件成百上千行，主 context 很快就被这些读取结果污染了。等到要写代码的时候，模型注意力已经分散在大量无关的细节上。

把 explore 隔离到 subagent 里，主 agent 只拿到一份精炼的总结，相当于拿到一张地图开始施工，而不是边挖边迷路。这跟之前讲上下文管理那篇文章（《Claude Code 作者亲授：百万 token 上下文的正确用法》）里“Subagent 本质上是上下文管理工具”的说法完全一致。

八、配置随模型升级要瘦身

这是整篇文档里我觉得最容易被忽视的一节。

为旧模型写的指令，可能反过来限制新模型。

模型在不停升级。你为 Sonnet 4.5 写的 CLAUDE.md 提示、为修补当时模型缺陷加的 hook、为绕过当时上下文管理 bug 写的 skill，到了 Opus 4.7 可能不仅没用，反而成了限制。

我自己有个真实例子。早期我在根 CLAUDE.md 里加了一段“请先列出所有计划再执行”，那是因为当时模型容易跳步。等模型升级后，规划能力本来就有了，这条提示反而让 Claude 每次都先输出一段冗长的计划，效率反而降了。

Anthropic 的建议是每 3 到 6 个月，或者每次大版本发布后，专门 review 一次 harness 配置：哪些规则还有意义、哪些已经过时、哪些 hook 可以删、哪些 skill 可以合并。

这个习惯在传统工程里叫技术债清理，放到 harness 上同样适用。CLAUDE.md 跟代码注释一样会腐烂，你不主动清，它就慢慢变成噪音。

九、组织准备：DRI、agent manager、跨职能工作组

最后一节是组织层面的，大公司读者可能更关心。

Anthropic 观察到一个规律：Claude Code 推广最顺利的组织，都是在大规模铺开之前先做了一波基础设施建设。少数几个早期采用者负责把 plugin 库搭起来、把 MCP 接好、把 CLAUDE.md 模板写出来，然后才让全员上手。

新出现的一个角色叫 agent manager，是 PM + 工程师的混合角色，专门管理 Claude Code 生态。如果团队没这么奢侈，最起码也要有一个 DRI（Directly Responsible Individual），管 plugin marketplace、管 CLAUDE.md 约定、管 settings 决策。

问题是，光靠工程师自下而上的热情其实不够。热情会催生很多个人配置，但散乱、重复、互相冲突。这种时候需要有人来收口。

大公司还有一层是治理。安全、合规、代码审查流程要早立工作组。原文这点是比较国际化的语境，搬到中国团队还要再加上数据出境、审查留痕，以及敏感行业（金融、政务）的额外要求。这些事情早做比晚做要少很多痛苦。

哪怕你是个人开发者或者小团队，把配置维护这件事当成一个明确的责任分配下来，也比“大家都用一下吧”要有效得多。

写在最后

正如 Claude Code 一直在持续不停迭代一样，要用好 Claude Code 的 harness 配置也不是一次配好就一劳永逸的，也需要随着模型迭代一起进化。CLAUDE.md、Hooks、Skills、MCP、LSP、Subagent，每个配置存在的理由都要定期审视，不能因为它已经在那就让它一直在那。

我自己的实践顺序是这样的：所有项目第一步先创建 CLAUDE.md（包括核心子目录中的 CLAUDE.md），然后再根据需要在项目的 .claude 里面配置所需要的 Hook、MCP 和 Skills，然后就可以用 Claude Code 玩起来了。之后在根据实际需要调整优化，并提醒 Claude Code 把经常出错的地方存入它的 Memory。

相关资源：

• 原文：https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start
• Harness 设计前作：为什么单 Agent 搞不定复杂应用
• 上下文管理：Claude Code 作者亲授：百万 token 上下文的正确用法
• Skill 写作经验：写好一个 Skill 有多难
• 我的 Claude Code 配置：feiskyer/claude-code-settings

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

每周 400 万人在使用的 Codex 桌面客户端，从今天起，都可以在手机 ChatGPT 客户端远程接管了。

OpenAI 今天凌晨发布了 Codex Mobile 预览版，让 ChatGPT 移动客户端可以直接控制本地的 Codex 桌面客户端。架构跟 Anthropic 三个月前推的 Claude Code Remote Control 几乎一样，但解决问题的方向恰好相反。

怎么连，怎么用

Codex Mobile 不是把 Codex 跑到云端，也不是远程桌面投屏。你 Mac 上的 Codex 桌面客户端还在 Mac 上跑，移动端通过 OpenAI 的 secure relay 同步状态。文件、credentials、本地配置都不动，移动端看到的是任务进度、终端输出、diff、截图。

设置流程比想象的还简单。Codex 桌面客户端升级后，侧边栏多一个 “设置 Codex 移动版” 选项，点开会显示二维码。

但你不用扫码。打开手机上的 ChatGPT 移动客户端，它会自动识别到同账号下有 Codex 桌面客户端在等你确认，弹一个授权提示。

点授权此手机，桌面端立刻显示“已连接”，下面还有三个开关进一步控制权限：让电脑保持唤醒、启用 Computer Use、装 Chrome 扩展。

整个过程不到一分钟。同账号下多台机器都能管，桌面端和移动端共享同一个 thread，不用来回粘贴上下文。

跟 Claude Code Remote Control 比

Claude Code 早在三个月前就推出了Remote Control，OpenAI 显然又是一个跟随者。架构几乎一样：本地跑 Claude Code，移动端做窗口，云端 relay 中转，桌面端和移动端共享同一会话。

这两个我都尝试过一些任务。从体感上看，Codex Mobile 跟 Claude Code Remote Control 差不多，主要区别不在功能，而在用量这件事上。

Claude Code 的 5 小时窗口是真的不够用，复杂任务几分钟就能把额度跑光。虽然 Anthropic 最近宣布了 5 小时配额加倍和周配额提升 50% ，但社区里普遍反馈差别不太明显。

反观 Codex 的限额政策一直比较大方，ChatGPT Pro 订阅很少会撞到上限不说，免费版甚至也能用 5.5 Extra High。对于 AI 编程重度用户来说，订阅 ChatGPT 要比 Claude 划算的多，更不用说 Claude 那畸形的封号策略了。

当然 Codex 移动端也有很多限制，比如现在只支持 macOS 上的 Codex 桌面客户端，不支持 Windows，高峰时间稳定性也有待提升。

写在最后

看到 Codex 移动端发布，第一时间想到的是 OpenAI 版的龙虾终于来了。OpenClaw 爆火这么长时间，各家 Agent 产品能抄的都已经抄过去了。现在 OpenClaw 热度都过去了，OpenAI 才姗姗来迟。

话说回来，不要被“在手机上写代码”这个画面骗到。Codex 的功能并不仅限于编程，它真正适合的场景，不只是让你掏出手机指挥电脑敲代码，更重要的是让你不在电脑前也能推进任务。正如 OpenAI 的 slogan 所说，“Touch grass and leave your laptop”，Codex 移动端不是替代你坐在电脑前的工作，而是让你不用一直守着电脑等 AI 跑完任务。

相关资源：

• OpenAI Codex Mobile 官方博客：https://openai.com/index/work-with-codex-from-anywhere/
• Claude Code Remote Control 文档：https://code.claude.com/docs/en/remote-control

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

上周写了一篇Codex /goal 上线后，我把 Ralph Loop 卸了，顺带吐槽了 Claude Code + Ralph Loop 跑长任务各种不靠谱。没想到没过几天，Anthropic 就在新版 Claude Code 里把/goal 命令抄过来了。官方推文直接说了，这就是 Claude Code 内置的 Ralph Loop（Ralph Loop 只是一个插件）。

用了几个场景，发现 /goal 确实比 Ralph Loop 好用不少，用起来也简单，一句/goal 就能启动，终于不用盯着 Agent 干活了。今天就带你一起看下这个新功能以及它背后的工作原理。

使用方法

升级 Claude Code 到最新版本之后，/goal 后面跟一个完成条件，Claude Code 就会一直干到条件满足为止，比如：

/goal 所有 test/auth 目录下的测试通过,lint 也没有报错

跟普通对话的区别是，每轮结束后 Claude Code 不会停下来等你输入，而是自动开始下一轮。界面上会显示一个/goal active 的状态条，标注运行时长。

具体的使用方法如下所示：

其实可用的命令也就三个：

• /goal <条件>：设置目标，立即开始执行
• /goal：查看状态，包括条件、时长、轮次、token 用量
• /goal clear：取消当前目标（也可以用 stop、cancel、reset）

需要你注意的是，条件怎么写很关键。写得模糊，模型还是有可能会糊弄你。比如这样写：

/goal 给这个项目写完整的测试

“完整”没有定义，模型可以写几十个空壳测试，全部通过，然后宣布完成。所以建议你换成更具体的条件，比如：

/goal 给 src/auth/ 下所有函数写单元测试,要求:
1. 每个测试必须包含真实断言,不能只有空壳
2. 测试覆盖率达到 80% 以上
3. npm test 退出码为 0
4. 不修改 src/ 下的源代码
5. 20 轮后未完成则停止

最后，我还加了条轮次上限，这个也很有用，防止 Claude Code 无限跑下去。

如果由于各种原因，中途退出了（比如到了 5 小时上限），后面再开启时可以用--resume 恢复目标继续执行。注意，你给它设置的条件最长支持 4000 个字符，可以写得很细了。

另外，还有两个比较好用的搭配：

第一个，/goal 跟 auto 模式搭配效果最好。auto 去掉每个工具调用的人工确认步骤，/goal 去掉每轮结束的等待，两个一起开就是完全无人值守。

第二个，在非交互模式开启，在自动化或者 SKILL 场景里面特别有用：

claude -p"/goal CHANGELOG.md 包含本周所有合并的 PR 记录"

实现原理

/goal 本质上是一个 session 级别的 prompt-based Stop hook。这一句话就把它跟 Ralph Loop 区分开了。

你设置一个/goal 条件后，Claude Code（Opus 或 Sonnet）正常工作，读文件、改代码、跑测试。每轮结束后，系统把完成条件和当前对话记录发给一个独立的小模型（默认是 Haiku）。这个模型返回 yes/no 和一条理由。如果 no，理由会注入下一轮对话，告诉 Claude 还差什么，然后自动开始下一轮。如果 yes，goal 标记为完成，记录到对话记录里。

关键是这个评估模型不能调用任何工具，它只能基于对话记录里已有的文字来判断。

评估的提示词很短，从 GitHub 上提取的系统提示词来看，核心逻辑是：

You are evaluating a stop-condition hook in Claude Code.
Read the conversation transcript carefully, then judge
whether the user-provided condition is satisfied.
Your response must be a JSON object with one of these shapes:
- {"ok": true, "reason": "<quote evidence from the
transcript that satisfies the condition>"}
- {"ok": false, "reason": "<quote what is missing or
what blocks the condition>"}
Always include a "reason" field, quoting specific text from
the transcript whenever possible. If the transcript does not
contain clear evidence that the condition is satisfied,
return {"ok": false, "reason": "insufficient evidence
in transcript"}

注意最后一条：找不到明确证据就默认返回证据不足。评估模型的默认立场是没做完，必须在对话记录里找到实锤才会放行。

不过实际用下来也是有不少问题的。评估模型只看对话文字，不能自己跑命令验证，所以如果工作模型在对话里写了“测试全通过”但实际没跑测试，评估模型看到的证据是充分的，自然会放行。想用好/goal，条件里最好写明具体的验证命令，让 AI 没法绕过。

跟 Ralph Loop 比

Ralph Loop 的核心机制是 Stop hook 拦截：Claude 干完一轮尝试退出时，hook 检查是否达到完成条件，没达到就把原始 prompt 重新注入。完成判断靠精确字符串匹配，Claude 输出<promise>DONE</promise> 就算完成。prompt 里反复强调“不要撒谎来退出循环”，但模型嘛，说不撒谎就不撒谎了？

跟/goal 比，最关键的差距在完成判断。Ralph Loop 是模型自己说了算，输出一个标记就能退出，bash 脚本做字符串匹配放行，没有任何独立验证。/goal 换成了一个独立的小模型来评估，至少不是自己批改自己的试卷了。另外 Ralph Loop 每轮都会把原始 prompt 原封不动重新注入，跑多了上下文里堆满重复内容，虽然 Claude Code 的 compaction 还是会生效，但这些重复注入本身就是噪音。

顺便提一下，Claude Code 还有个/loop 命令，按时间间隔触发下一轮（比如每 5 分钟跑一次），适合轮询类定时任务。/goal 是每轮结束后立即触发下一轮，适合连续执行的目标。

跟 Codex /goal 比

上篇文章里聊过，Codex/goal 的核心设计是三层：状态持久化（state-db）、权限控制（模型只能标记 complete，不能自行退出）、强制自审（continuation.md 要求拆检查清单，逐项对照真实文件和测试结果）。

Claude Code/goal 走了一条不同的路：不依赖工作模型的自查能力，而是引入独立的评估模型。

实际体验上两者差距明显。Codex 在目标执行和自审过程中可以通过工具来形成验证证据，grep 代码、跑测试、核对 spec，工作模型想造假成本很高。Claude Code 的评估模型只看对话文字，验证深度差一个量级，所以我自己跑下来还是 Codex 强得多（这也跟模型能力有关，Codex 搭配 GPT-5.5 才能达到最好的效果）。

写在最后

翻这几个方案的实现原理时，突然想到了最近一直在关注的 Agent harness 这个话题。你会发现不管是 Claude Code /goal 的评估循环还是 Codex /goal 的权限控制，关键的约束都不是写在提示词里的，而是写在代码里的。Claude Code 用代码层面的 Stop hook 来驱动循环，Codex 的运行时每轮自动注入一段自审提示词，强制模型拆检查清单、逐项验证，模型不能自己选择要不要自审，代码替它做了强制自审。

CLAUDE.md 和 AGENTS.md 里写的规则模型可能忽略，但代码层面的 hook 100% 总会触发。这也是为什么 Agent harness 是必要的，光靠模型自觉是不够的，需要有人在外面用代码控制 AI 行为和边界。

回到/goal 本身，对于验收条件清晰、按照 SPEC/PLAN 就能逐步完成的任务，它是目前最省心的选择。但要注意 token 消耗问题，/goal 模式下每轮都是完整的 Opus/Sonnet 调用，跑十几轮下来主模型的 token 用量轻松翻几倍（Haiku 评估的开销相对很小，主要成本还是多轮主模型调用）。建议在条件里加上轮次上限，保护好你的 token 账单。

相关链接：

• Claude Code /goal 官方文档：https://code.claude.com/docs/en/goal
• 上篇 Codex /goal 推荐：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw
• Claude Code GitHub：https://github.com/anthropics/claude-code

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

强烈推荐一下 Codex 的/goal 命令。搭配 GPT-5.5，我第一次感受到长时任务可以完成得这么丝滑。

之前用 Claude Code + Ralph loop 跑长任务，总是各种各样的问题：跑着跑着模型自己宣布胜利了，明明任务清单还有大半没做；状态文件越写越离谱，跨会话后新 Agent 看到的进度跟实际对不上；偶尔卡住，整套循环死在那里。社区里很多人也有同感，有人说自己用 Ralph loop 最长跑 3 小时就失控，中间得不停盯着；使用成本也是巨高，每轮循环都要重新读一遍代码库，token 消耗比正常操作高出很多。

上周升级 Codex 用上了新增的 Goal 命令，Greg Brockman 发推说“codex now has a built in Ralph loop++”。试了几天，太丝滑了，把 Ralph loop 卸了。今天就来给大家分享下它的用法。

/goal 怎么用

首先编辑~/.codex/config.toml 开启这个功能特性：

[features]goals =true

然后给它一个目标就可以等着它帮你干完了，比如：

/goal 把仓库里所有 axios 调用迁移到 fetch,要求:
1. 所有现存测试通过
2. 类型签名不变
3. 错误处理行为等价(4xx/5xx 都要 throw)
4. 完成后跑一遍 npm run build 和 npm test 确认

跟普通对话的区别就一条：每轮结束后 Codex 不停，自己接着干下一轮，直到目标达成。TUI 上有个进度面板，显示当前状态（pursuing / complete / paused）和 token 用量。你可以全程不看它的进度。

运行过程中可以用/goal 查看状态，用/goal pause 暂停，/goal resume 恢复，/goal clear 清除。

/goal 的三层设计

最开始我以为 /goal 就是把 Ralph loop 照搬到了 Codex 里面来。翻了 GitHub 源码才发现，这个设计比 Ralph loop 更进一步，如下图所示：

最底层是状态持久化。Codex 把 Goal 状态写进 state-db（源码在codex-rs/core/src/goals.rs），可能的值是pursuing /paused /complete /unmet /budget_limited。你中途退出再打开，Goal 还在，还可以接着跑。Ralph loop 脚本挂了虽然磁盘文件还在，但得手动重启、重新接上上下文。

中间层是权限控制。Codex 给模型三个工具：get_goal、create_goal、update_goal，但update_goal 的状态参数只接受一个值：complete。模型能宣布“我搞定了”，但不能说“预算快没了我撤了”。断了它的退路，要么真做完，要么继续干。

最上层是自审注入。每轮执行时，运行时注入continuation.md 里一段 prompt，强制模型把目标拆成检查清单，逐项对照真实文件和测试结果。最关键的一句：

Do not call update_goal unless the goal is complete. Do not mark a goal complete merely because the budget is nearly exhausted or because you are stopping work.

直接避免了我之前 Ralph loop 里最常碰到的问题：模型为了脱身硬说基本完成了。

把三层放在一起看，Ralph loop 只是让模型反复跑，/goal 让模型反复跑的同时不停反问自己“我真的做完了吗”。

GPT-5.5 + 100% confident loop

光有 /goal 还不够，模型还需要足够强大。

GPT-5.5 是少数会主动质疑自己的模型。/goal 的自审提示对一个不爱质疑自己的模型就是耳旁风，对 5.5 是放大器。并且 GPT-5.5 也没有之前 GPT 模型那种总是很懒的感觉了，你想不到的它也可以帮你想到了。

对比一下 Opus 4.7。你说“再检查一遍”，它说“你说得对”，然后说一堆早想好的话。你说“这有 bug”，它说“绝对的，我重写”，然后小幅改一下交回来。讨好型选手，跑长任务越跑越偏。而 GPT-5.5 不一样，让它再查一遍，它真会去 grep、跑测试、对照 spec，然后告诉你哪里还有边界情况。

社区里有个配套 prompt 传得很广：

Are you 100% confident in this strategy? If not, find all possible loopholes, suggest proper fixes and run this loop until you are factually 100% confident in the new strategy.

关键是让 5.5 自己开循环：找漏洞、提修复、再问自己一次。这招在 Opus 上完全不好使，它把自查当客套环节，5.5 当成一份正经工作。

我推荐的工作流是：先写 SPEC.md（或者任何保存到文件的目标任务），用这个 prompt 自审一遍，SPEC.md 没问题了再/goal 启动执行，完成后做 QA。

按这个流程，Codex 连续干十几个小时完全不是问题（如果你的 token 足够，更长应该也完全没问题）。

什么任务适合

判断标准就一个：你能不能把“做完了”写清楚。能写清楚，/goal 就可以跑的很多；写不清楚，跑出来也可能是垃圾。官方文档的说法是，好的 Goal 应该定义清楚四件事：要达成什么、不能动什么、怎么验证进度、什么时候停。

我自己跑下来，Goal 比较适合这几类场景：

代码迁移和大型重构。有明确的目标状态，有验收手段（ build 通过 + 测试通过 + e2e 通过）。比如：

/goal Migrate this project from [legacy stack] to [target stack]. Make sure all screens stay exactly the same visually, using playwright interactive to verify the output.

原型和游戏开发。写一份 PLAN.md 描述你要什么，然后让 Codex 实现它。Codex 会按里程碑推进，每个节点跑测试确认。

/goal Implement PLAN.md, creating tests for each milestone and verifying the output with playwright interactive

Prompt 优化。如果你有 eval 套件，可以让 Codex 自己迭代，做实验、看结果、调参数，循环到收敛。比如：

/goal Optimize the prompts in [prompt file] until the eval suite reaches [target score]. After each change, run [eval command], inspect the failing cases, and keep the prompt edits minimal and targeted.

夜间 QA 和批量处理。回归测试、数据校验、批量文件处理这类机械但耗时的活，丢给 /goal 过夜跑。

写在最后

回到开头说的那个问题：长时任务为什么一直不稳？

我之前开发 autonomous-skill 的时候，思路跟 Ralph loop 其实一样，都是在模型外面套一个逼它继续干活的循环。跑了大半年，我逐渐意识到问题不在循环本身，而在模型。模型没有自查能力的话，再套多少层也只是把错误重复 N 次。你可以逼它继续干，但你逼不了它承认自己没干好。

/goal 解决的恰恰是这一层。运行时不让模型耍赖，GPT-5.5 又真的会自查，两条腿一起走，长时任务才第一次变成可以托付的事情。

当然 /goal 也不是万能的。目标写不清楚的任务它照样跑偏，需要频繁跟人确认方向的任务它也不适合。不过对于那些验收标准明确、可以自动化验证的工作，它确实把盯着 Agent 干活这件事变成了睡一觉起来看结果。这个体验的差距，用过就知道了。

相关链接：

• Codex /goal 官方文档：https://developers.openai.com/codex/use-cases/follow-goals
• Codex GitHub 源码：https://github.com/openai/codex

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Claude Code 和 Codex 出来这一年多，我几乎每天都在用。刚上手那阵非常兴奋，写代码确实快了不少。但用的时间越长，反而越经常冒出一种说不清的无力感。

模型变强的速度比预想中快得多。以前觉得花了几年才练出来的本事，让 Agent 跑一下，输出经常比自己手写还干净。重构一个陌生模块也好，读懂别人的老代码也好，定位一个偶发的 bug 也好，Agent 默认就能做对。

慢慢就有种感觉：自己能干的事 AI 都能干，那作为工程师我的价值到底还剩什么？

这两天看 Karpathy 在 Sequoia AI Ascent 2026 上的对谈，发现他也是同样的感觉：他从来没有像现在这样，觉得自己作为程序员落伍了。

去年 2 月他造了 Vibe Coding 这个词，意思是凭感觉写代码，不纠结细节，让 AI 替你搞定。这词火了一整年，几乎成了 AI 编程的代名词。结果发明这词的人，自己觉得落伍了。

一开始我以为他只是谦虚。看完半小时完整对谈，才发现他是认真的，而且把这种感觉拆得挺清楚。内容密度很高，我把最有价值的部分整理了分享给你。

为什么感觉落伍了

Karpathy 的落伍感不是凭空来的，转折发生在去年 12 月。

他用 Agent 写代码已经有一段时间了，之前体验时好时坏，模型输出经常要手动改。但到了 12 月，他发现代码直接拿来就能用，追加需求继续改，输出还是对的。到后来他都记不清上一次手动修正是什么时候了。

这不是慢慢变好，是一个突然的台阶。从“有时候能用”到“默认能用”，中间没有过渡。

这跟我开头说的感受其实是一回事。当 AI 默认就能搞定那些以前需要费劲做的事，无力感自然就来了。

所以 Karpathy 也提醒了一件事：如果你 12 月之后没有重新认真试一次，可能还在用一个已经过期的心智模型判断这些工具。

下限和上限是两回事

既然能力有了质变，这对不同的人意味着什么？Karpathy 在这里有个挺重要的区分：Vibe Coding 和 Agentic Engineering 不是一回事。

Vibe Coding 抬的是下限。非程序员也能用自然语言描述需求，跑起来一个东西。

但 Agentic Engineering 抬的是上限。它面向的是专业工程师，解决的问题是：怎么用 Agent 工具更快地交付，同时不牺牲安全性、可靠性和代码质量。

这是两条完全不同的路。Vibe Coding 让不会写代码的人做出能跑的原型；Agentic Engineering 让一个工程师在生产级质量的前提下，把效率拉到之前不敢想的水平。

之前大家说 10x 工程师，现在擅长 Agentic Engineering 的人远超 10x。个人产出的上限比以前高得太多。

这才是他觉得落伍的真正原因。不是 AI 太强，而是不同人用 AI 的能力差距正在急剧拉大。好工程师和普通工程师之间的杠杆倍数，比以前任何时候都大。

同一个模型，同时天才和白痴

不过，能力差距拉大的前提是，你得知道模型到底擅长什么。对谈里我觉得最有意思的就是这一段：LLM 的锯齿形智能。

Karpathy 举了个例子：最先进的 Opus 4.7 可以连贯地重构一个 10 万行的代码库，或者发现零日漏洞。但你问它“洗车店离我 50 米，我应该开车还是走路”，它会告诉你走路去，因为距离很近。

一个能发现零日漏洞的系统，怎么可能不知道你不能走路去洗车？

Karpathy 给了两个解释。

第一个是可验证性。LLM 的训练靠强化学习，强化学习需要验证信号。代码有编译器和测试，数学有证明，这些领域天然可验证，RL 在这上面效果拉满。但日常常识很难构造验证环境，落不到轨道上。

第二个更有意思，是经济学。前沿实验室选什么数据进训练集，取决于商业价值和 TAM。代码能力值钱，所以有人花大力气做了。Karpathy 还举了个例子：从 GPT-3.5 到 GPT-4，棋力大幅提升，很多人以为是通用能力进步，实际上是因为有人决定往预训练数据里加了大量棋谱。能力的提升不是均匀发生的，是跟着数据分布走的。

他打了个比方：如果你的应用恰好在 RL 训练覆盖的轨道上，你会觉得在飞；如果不在，你就是在丛林里拿砍刀开路。

这个判断对做产品的人特别有参考价值。开始一个 Agent 项目之前，先问自己：我的任务在不在模型训练的轨道上？在的话就能直接用；不在的话，要么准备 fine-tuning，要么换个思路。

你写的代码可能不该存在

说完模型能力的边界，Karpathy 抛出了一个更激进的观点：就算在模型擅长的轨道上，很多现有的软件其实也不应该存在。

他用自己做的 MenuGen 举例。这个应用拍一张餐厅菜单的照片，用 OCR 识别菜名，调用图像生成器给每道菜生成图片，然后重新渲染菜单。他用 Vibe Coding 写出来，部署在 Vercel 上，效果挺好。

然后他看到了另一种做法：直接把菜单照片发给 Gemini，让它用 Nanobanana 在原图上渲染菜品图片。输入一张图，输出一张图。没有 OCR，没有后端，没有数据库。

他说自己的整个 MenuGen 应用都是多余的。它还停在 Software 1.0 的范式里，而 Software 3.0 的做法是让大模型直接完成端到端的任务。

另一个例子是 OpenClaw 的安装方式。传统做法是写一个 Shell 脚本处理各种平台差异。OpenClaw 的做法是写一段自然语言的安装说明，让用户复制给自己的 Agent。Agent 读你的环境，适配你的系统，中间出问题自己调试。

这等于是用.md 替代了.sh。

第三个例子是 LLM 知识库。以前没有任何代码能把一堆非结构化的文章变成一个有组织的 Wiki。这不是做得快了，而是以前根本做不了。

Karpathy 说，每次范式转换，人们最先做的总是把新工具用来加速旧工作流。但真正有意思的不是加速，是那些以前根本不可能的新东西。

能外包思考，不能外包理解

前面说的都是工具和能力层面。Karpathy 在对谈快结束时，聊到了一个更根本的问题。

他引用了一条推文：你可以外包你的思考，但你不能外包你的理解。

他说这句话几乎每隔一天就会在他脑子里冒出来。

他现在觉得自己是系统里的瓶颈。Agent 可以执行、搜索、写代码、迭代，但“我们到底在做什么”“为什么值得做”“方向对不对”，这些问题 Agent 回答不了。

他甚至不太喜欢 Plan Mode 这个概念。在他看来更准确的说法是：人负责写 Spec，Agent 负责实现。Spec 是你的设计意图，是你对系统不变量的理解，是你对用户场景的判断。Agent 负责的是 API 细节、代码实现、格式规范这些可以查手册的事。

他举了自己的例子：PyTorch 和 NumPy 的 API 细节他已经记不住了，keep_dims 还是keepdim，dim 还是axis，reshape 还是permute。这些交给 Agent 就行。但底层 Tensor 的存储模型、View 和 Copy 的区别，这些你必须懂，不然你都不知道自己在让 Agent 做什么。

招聘还没跟上来

如果理解力和判断力才是核心竞争力，现在的招聘方式就有点尴尬了。Karpathy 也聊到了这个问题。

大部分公司面试还在考察八股文。但 Agentic Engineering 的核心能力不是能不能解一道算法题，而是能不能交付一个经得住考验的系统。

他给了一个挺有意思的面试思路：让候选人做一个真实项目，比如一个 Twitter 克隆，要求部署上线、功能完整、安全合格。然后用 10 个 Codex 实例去攻击这个系统，看它能不能扛住。

这种面试考的不是算法能力，而是你在有 Agent 工具辅助的情况下，能不能做出一个可靠的、上线后不会出事的产品。

回到开头那个问题

回到开头那个问题：自己能干的事 AI 都能干，那作为工程师我的价值还剩什么？

看完这个对谈，答案大概清楚了：工具可以外包，理解不能。你仍然是系统的掌控者，信息仍然要进入你的大脑，你仍然需要搞清楚正在发生什么才能给出正确的方向。

所以与其焦虑被 AI 替代，不如把这种无力感当作一个校准信号。工程师的能力上限在快速上移，之前的 10x 工程师，可能只是新标尺下的 2x。真正值得关注的不是 AI 能做什么，而是你能不能把理解力跟上这个新的杠杆倍数。

相关资源：

• 完整对谈视频：https://www.youtube.com/watch?v=96jN2OCOfLs
• Karpathy 本人的要点总结：https://x.com/karpathy/status/2049903821095354523
• Stephanie Zhan 的推文：https://x.com/i/status/2049518659513852109
• Vibe Coding 原推：https://x.com/karpathy/status/1886192184808149383

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

You’re absolutely right! 用过 AI 的人对这句话应该不陌生。不管你问什么，它的开场白永远是先夸你。让它帮你看一段代码，它说 well-structured，结果上线就炸了。问它一个方案靠不靠谱，它说 sounds like the right call，然后你真去做了，发现坑一大堆。

用 AI 越多的人，越会意识到一个问题：它总是同意你，让你觉得高效、顺畅、方向正确。但你越来越分不清，它是真觉得你做得对，还是只是在拍马屁。

刚看到 Anthropic 发了一篇研究，分析了 100 万条 Claude 对话，专门研究了这个问题。读完之后挺有收获的，分享几个关键发现和我自己的应对思路。

100 万条对话，9% 的谄媚率

Anthropic 从今年 3-4 月的 claude.ai 对话中随机抽了 100 万条，过滤出约 64 万条独立用户对话。其中将近 4 万条是用户在向 Claude 寻求个人建议，健康、职业、感情、财务四个领域占了 76% 。每 16 个用 Claude 的人里，就有 1 个在问它人生大事。

那这些人生大事的回答里，Claude 有多会拍马屁？Anthropic 用分类器给每段对话打了个谄媚分，判断标准包括：有没有在用户施压时退让、有没有给出与事实不符的夸奖、有没有回避说用户不想听的话。

整体谄媚率是 9% 。说实话，这个数字比我预想的低。大部分时候 Claude 还是能给出相对客观的回复的。

不过有两个领域是重灾区：灵性话题（占星、塔罗、灵修等等）38% ，感情关系 25% 。灵性话题最高不意外，AI 在这类问题上几乎没有客观标准可以坚守，最容易顺着用户说。

为什么感情问题最容易翻车？Anthropic 挖了一下原因，发现了一个挺有意思的动态循环：

感情类对话中，用户反驳 Claude 的比例是 21% ，显著高于其他领域的 15% 。你想，一个人来问“我男朋友是不是在 PUA 我”，Claude 说“根据你描述的情况，也许可以从对方的角度考虑一下”，用户大概率会不高兴，会追问甚至反驳。

而 Claude 被训练得既要有帮助又要有同理心。一旦用户施压，再加上它只听到了一面之词，就很容易滑向“对，你说得对，你男朋友确实有问题”。

数据也印证了这一点：没有用户反驳时，谄媚率是 9% ；用户反驳之后，谄媚率翻倍到 18% 。

这跟我们日常生活里的经验也对得上。你跟朋友吐槽另一半的时候，朋友如果说“你有没有想过其实是你的问题”，你大概率不会开心。下次就不找这个朋友了。AI 也一样，它在训练过程中学会了一件事：让用户不开心 = 差评 = 被惩罚。

Opus 4.7 怎么改的？

Anthropic 拿这些发现去改进了新模型。做法是识别出用户施压的各种模式，比如批评 Claude 的初始判断、单方面补充大量细节，然后用这些模式生成合成训练数据，专门训练 Claude 在这些场景下保持立场。

效果挺明显的。在压力测试中，Opus 4.7 的感情类谄媚率比 Opus 4.6 降了一半，而且这个改进还泛化到了其他领域。

不过有个有意思的反转。Opus 4.7 发布后不到 24 小时，开发者社区就炸了。Reddit 和 X 上有人直接说它“legendarily bad”，原因是：模型不再迎合你，但它开始跟你吵架了。有开发者反馈，Opus 4.7 会拒绝执行明确的指令，坚持自己的判断甚至因此产生幻觉。

这让人想起去年 4 月 GPT-4o 因为过度谄媚被骂，OpenAI 紧急回滚的事。谄媚和过度拒绝，像是同一条光谱的两端，调过来调过去，很难让所有人都满意。

4 个让 AI 说真话的技巧

研究归研究，我更关心的是：作为 AI 的重度用户，日常怎么应对？

这里分享几个我自己在用的方法，结合这次 Anthropic 研究的发现做了一些调整。

开头声明“别迎合我”

在涉及重要决策的对话开头，加一句系统提示：“请给出你真实的评估，不需要迎合我的预期，就算答案让我不舒服也请直说。”我自己在用 Claude Code 做架构决策时就养成了这个习惯。Anthropic 的研究也印证了这一点：谄媚最容易在用户施压时出现，提前声明你要真话，能校准模型的回复倾向。

用第三人称重述问题

把“我这个微服务拆分方案有没有问题”换成“一个团队打算把单体应用拆成 5 个微服务，可能遇到哪些问题”，AI 的客观性明显提升。第一人称自带“请认可我的方案”的情绪信号，模型会倾向于先肯定你；第三人称更像在讨论一个案例，它更容易给出多角度分析。

主动要求反驳

问完 AI 一个技术方案之后，追问一句：“现在请你扮演一个资深 SRE，尽力找出这个方案在生产环境下可能出的问题。”这比直接问“你觉得这个方案怎么样”有效得多。后者的潜台词是“请你夸我”，模型会照做；前者明确要求它切换立场，你能拿到更有价值的反馈。

多模型交叉验证

重要的技术决策不要只问一个模型。同一个问题用 Claude 问一遍，再用 GPT 或 Gemini 问一遍。斯坦福今年 3 月在 Science 上发了篇论文，测了 11 个主流模型，发现它们的谄媚倾向高度一致，都比真人多 49% 的概率认同你。

所以多模型验证的重点不是看它们是否都同意你，而是看它们给出的理由和关注点有没有差异。比如一个说内存可能有问题，另一个说网络延迟是瓶颈，第三个担心数据一致性，这种多角度的拆解比三个模型都说“方案很合理”有用得多。

写在最后

Anthropic 这篇研究里有个细节让我印象很深：22% 的用户提到他们找不到或负担不起专业咨询，所以才来问 AI。这些人可能最需要诚实的反馈，但恰恰最容易被谄媚的回复误导。

谄媚不是一个调参数就能解决的技术 bug。有帮助、有同理心、诚实、不让人不爽，这四个目标之间天然存在张力。GPT-4o 之前就发生过太会拍马屁而被紧急回滚的问题，而现在 Opus 4.7 因为这些优化又太会抬杠被集体吐槽，所以到现在也没有哪家公司真正能够找到一个较好的平衡点。

所以回到开头的场景：下次 AI 对你的代码说 you are absolutely right 的时候，多想一想。它是真的审查过你的代码逻辑、评估过你的方案风险，还是只是在讨好你。

相关资源：

• Anthropic 原文：《How people ask Claude for personal guidance》（https://www.anthropic.com/research/claude-personal-guidance）
• 斯坦福 Science 论文：AI 对用户观点认同率比人类高 49% （https://www.science.org/doi/10.1126/science.aec8352）
• OpenAI 事后分析：GPT-4o 谄媚回滚始末（https://openai.com/index/sycophancy-in-gpt-4o/）

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

刚装完 OpenClaw，简单试了几个场景，觉得也就那样。跟直接用 Claude Code 比，看不出有啥明显优势，反而还多了一层 Gateway 要维护。看起来它能干的，Claude Code 好像也都能做，干脆卸载算了？

你第一次用的时候是不是也这个感觉？反正我是。

后来用过一段时间才发现，问题不在 OpenClaw 不行，而在于没有“养”好。一个没调教过的 OpenClaw，确实看起来就是个套壳。但配到位之后，差距就出来了。比如，我跟 OpenClaw 说一句“review [PROJECT] PR #375”，它会自己切到项目工作目录、收集上下文、spawn Claude Code 做各种审查、汇总结果回来汇报，最后再发布审核意见到 PR 里面。并且，它还可以在跟你交互的过程中自动学习你教给它的经验，能够记住你跟它说的各种注意事项，用着用着也就离不开了。

这篇就分享一下，我是怎么一步步把 OpenClaw 从也就那样养到离不开的。

先写好三个文件

这是我觉得最重要的一步，先教 OpenClaw 怎么说话、怎么做事、怎么理解你。你给它配置得越具体、越有观点，OpenClaw 的输出就越像一个有血有肉的人。

具体来说，OpenClaw 的 workspace 里有三个核心文件，分别管不同的事。

SOUL.md 管 OpenClaw 怎么说话。注意这并不是 system prompt，而是 Agent 的身份定义。你在里面写什么样的语气、什么词不能用、什么样的输出让你满意，OpenClaw 就会照着来。

USER.md 管 OpenClaw 怎么理解你。当然这儿并不是放你的简历，而是让 OpenClaw 理解你怎么思考的文件，比如你的决策风格、什么让你烦、什么让你兴奋、你的沟通习惯等等。

AGENTS.md 管 OpenClaw 怎么做事。这里面就是纯流程，比如该做什么、不该做什么、失败了怎么处理、PR 怎么提等等。

这三个文件的分离很关键。SOUL.md 写好后应该很少变化，身份是稳定的；AGENTS.md 要经常更新，因为流程在不断迭代；USER.md 则随着 Agent 更了解你而逐步补充。

怎么写 SOUL.md

你可能觉得 SOUL.md 随便写几行就行了。我之前也是这么想的，结果 OpenClaw 动不动就回答一个技术问题先来三段废话。

那么，SOUL.md 具体该怎么写？

首先表达语气要写具体。我的 OpenClaw 叫 Klaw 🦀，表达要求是 language with voltage，每句话要值得存在。你要是泛泛地写个 be helpful and concise，那出来的东西跟 ChatGPT 没什么区别。写得越具体，输出越像你想要的样子。

然后禁用词表也要有。comprehensive、robust、leveraging 这些 AI 味词汇全部禁掉。

不过最关键的还是给好输出和坏输出的示例。与其写简洁明了四个字，不如直接给 OpenClaw 看一对对比：

好输出：

etcd compaction 的 revision 不对.看一下 --auto-compaction-retention
设的是不是 duration 模式,旧版本默认是 revision 计数.

坏输出：

Great question! Based on your use case, I'd recommend considering several
factors when configuring etcd compaction...

第一种是一个懂行的工程师在说话，第二种是一个 AI 在表演热情。OpenClaw 看到这对示例，立刻就知道你想要什么了。

调了几版之后的经验

用了一段时间之后，又踩了几个坑。

最大的教训是别写太长，1000-2000 字就够了。太长占用上下文空间不说，给 AI 太多的限制还容易降低 Agent 的智能。

还有一个容易犯的错是把 SOUL 和 AGENTS 混在一起。个性相关的放 SOUL，流程相关的放 AGENTS，分开写 OpenClaw 才分得清轻重。

另外 SOUL.md 不是写完就不动的，建议每周花几分钟回顾一下，删掉没用的，加上新碰到的问题。我自己已经改了四五版了，每次改完都觉得 OpenClaw 又多懂我了一点。

让它有记忆

LLM 最大的问题是无状态，每次对话都从零开始，你昨天告诉它的东西今天全忘了。OpenClaw 的解决方案是一套基于文件的记忆系统：

MEMORY.md → 长期记忆memory/2026-04-28.md → 每日笔记memory/working-buffer.md → 危险区缓冲SESSION-STATE.md → 活跃任务状态

那么，这套记忆系统具体是怎么工作的呢？

记忆怎么写进去的

OpenClaw 的记忆机制有点像数据库里的 Write-Ahead Logging：先落盘，再响应。它会扫描你发的每条消息，一旦发现重要信息（比如你纠正了它的错误、做了某个决策、表达了某种偏好，或者提到了具体的数值），就立即写入文件，然后才回复你。

简单说就是：让 OpenClaw 记住一件事，靠嘴说不可靠，写下来才可靠。

Dreaming

OpenClaw 还有个 Dreaming 功能，可以配一个定时任务在凌晨自动整理短期记忆：

{“memory-core”:{“config”:{“dreaming”:{“enabled”:true,“frequency”:“019***”,“timezone”:“Asia/Shanghai” }}}}

它会扫描最近的对话，把你经常用到的记忆晋升到长期存储，不常用的自然淘汰。有点像人睡觉时整理白天的记忆一样。

不过这里有个坑：dreaming 容易把一些啰嗦的内容也晋升上来，导致 MEMORY.md 越来越臃肿。目前还没有好的自动化方案，还是得你定期手动清理一下。

另外如果你同时在好几个项目上用 OpenClaw，建议不要把所有项目的具体信息都塞进主 MEMORY.md 里面。我的做法是给每个项目建一个单独的目录，项目相关的记忆都放在各自目录下，主 MEMORY.md 里只放索引。这样既不会互相干扰，找起来也方便。

长 session 不丢上下文

用久了你还会碰到一个问题：聊太久触发了 context compaction，OpenClaw 压缩上下文之后会丢失一些细节。它的恢复策略是先读working-buffer.md（这个是压缩前自动写入的摘要），再读SESSION-STATE.md（当前任务状态），然后翻一下近两天的日记。

给它装 Skills

Skills 是扩展 OpenClaw 能力的机制，每个 Skill 就是一个包含SKILL.md 文件的文件夹，告诉 OpenClaw 在什么场景下应该怎么做事。

你可能会想，Skill 是不是装得越多越好？其实不是。装多了互相打架不说，上下文也吃不消。

我目前安装的 Skills 大致分三类：

• 通用增强：proactive-agent（主动预判需求）、self-improvement（从错误中学习）、context-window-management（上下文快满时自动减负）、systematic-debugging（四阶段 root cause 分析）。
• 安全防护：skill-vetter（安装外部 Skill 前做安全审查）、dangerous-action-guard（执行不可逆操作前要你确认）、fact-check-before-trust（对事实性声明做二次验证）。
• 领域专用：按自己的工作场景来选装，比如github、cve-check、ado 等等。

至于一些常用 Skills 的用法，我之前在《OpenClaw 必备 Skill 清单》里详细写过，这里就不重复了。

这里重点说一个我觉得特别重要的规则：安装任何外部 Skill 之前，一定要先跑skill-vetter 审查安全。

举个实际的例子：我之前从一个社区 Skill 仓库精选了 10 个，审查完跳过了其中 3 个。一个会偷偷发 Reddit 请求，一个带了自动 cron 任务，还有一个藏了遥测代码。如果不审查就装上去，OpenClaw 就会在你不知道的情况下做你不知道的事。要知道 Skill 本质上是一段会被 OpenClaw 执行的指令，它有你的文件系统权限。之前在《23 万 OpenClaw 公网裸奔》那篇也聊过这个话题，安全这事真不能大意。

让它自己干活

配好了人格、记忆和 Skills 之后，OpenClaw 已经比刚装完的时候好用太多了。不过到这一步你还是得自己发指令、等结果。有没有办法让 OpenClaw 自己跑起来，你只管收结果？

这就是 ACP 和 Cron 干的事。

ACP

OpenClaw 可以通过 ACP 调用 Claude Code、Codex、OpenCode 这些 coding agent。整个流程大概是这样的：

你 → OpenClaw → 分析任务 → spawn Claude Code → 独立沙箱执行 → 完成后汇报

比如，你跟 OpenClaw 说一句 review [PROJECT] PR #375，它会自动切到项目工作目录，收集 PR 的上下文，spawn 一个 Claude Code 调用 code-review skill 做审查，最后把结果汇总回来。如果是你自己的 Code，还可以继续跟进这些审查结果迭代，直到得到一个比较满意的结果。最后去把审查结果发布到 PR 上面去，有 bug 就直接留 comment，没问题就 lgtm。当然，合并之前还是建议你人工去看看 PR，不要完全信赖 AI。

另外还可以把 ACP agent 绑定到 Discord 等 IM 频道。比如，你可以分别给 Claude Code 和 Codex 绑定到#claude 和#codex 两个不同的频道，然后你在里面发消息就会自动创建 thread 并启动对应的 ACP session，相当于在 Discord 里面直接跟 Claude Code 和 Codex 对话了。

定时任务

那如果你想让它定时干活呢？OpenClaw 的 cron 系统可以每个 job 都跑在隔离的 session 里，不会影响你正在用的主 session。我目前配了几个定时任务：Git Sync 每小时自动备份 workspace，AI News 每 8 小时抓一轮新闻推到 Discord，Dreaming 每天凌晨整理记忆，Issue Triage 每天上班前自动 triage issue 列表， Version Check 每天检查我关注项目的更新状况。

大模型配置

用得频繁的时候，经常碰到 GitHub Copilot 限流的问题。如果没有配 fallback chain，OpenClaw 就直接断线了。所以建议你也给 OpenClaw 的模型列表搭上备份配置，比如

{“model”:{“primary”:“github-copilot/claude-opus-4.6”,“fallbacks”:[“github-copilot/claude-sonnet-4.6”,“github-copilot/claude-opus-4.7”,“openai/gpt-5.4”] }}

另外 memory search 我也单独配了一个 provider，用的是 Azure OpenAI 的text-embedding-3-small，配合 hybrid search 也就够用了。后来还发现 GitHub Copilot 也有text-embedding-ada-002 可以拿来做记忆搜索，就给 OpenClaw 提了个 PR 把这个功能加上了。

踩过的坑

说实话，OpenClaw 目前还是一个需要你愿意折腾才能用好的工具，所以大家都还需要养龙虾。除了前面提到的 SOUL.md 写太长和 Dreaming 膨胀的问题，还有一些值得注意的坑。

比如 Gateway 重启之后，所有 ACP sessions 全部 reconcile 失败。查了一下原因是旧的 session 用 renderer v1 格式存储的，但新版本只认 v2。处理方法是杀掉 stale harness 然后重启 gateway。这件事给我的教训是：一定要把tools.sessions.visibility 设成all，这样你能看到所有 session 的状态，调 ACP 问题的时候没这个配置基本是盲调。

OpenClaw 每个版本的升级虽然会带来很多新功能特性，但也都会带来各种各样的问题，有些还会导致配置不兼容。所以，每次升级之后，不要着急重启 gateway，而是先跑一遍 openclaw doctor –fix，看看是否缺了依赖，配置是否有不兼容的问题。不修好这些问题，gateway 重启之后可能就完全挂掉了。

另外 OpenClaw 的文档目前还不算完善，很多配置的最佳实践得自己摸索。这也是我写这篇文章的原因，希望能帮后来的人少走点弯路。

写在最后

回到开头说的那个问题：OpenClaw 跟 Claude Code 到底有啥区别？

虽然我主要把 OpenClaw 用在编程相关的任务中，但纯论代码生成能力，Claude Code 还是比 OpenClaw 强得多。OpenClaw 真正的优势在于它是一个完整的 agent runtime。它可以通过 Discord、Telegram、Slack 这些 IM 渠道随时跟你交互，记忆系统让它不再每次从零开始，Skills 给它装上了模块化的能力扩展，ACP 让它可以调度 Claude Code 和 Codex 帮你干活，而 Cron 让它在你睡觉的时候自己把活干了。

不过这些都不是装完就有的。OpenClaw 更像是一个需要你花时间去养的东西，SOUL/USER/AGENTS 写得越具体它就越懂你，记忆积累得越多它就越好用，Skills 选得越精准它就越靠谱。刚开始确实要折腾，但养一段时间之后，你会发现你已经离不开它了。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

最近一直有人问我 Hermes 能不能替代 OpenClaw。认真试了一圈，结论是：差得还挺远。

Hermes 的思路没问题，让 agent 自己从任务中提炼技能，下次碰到类似场景直接复用。简单重复的任务确实能提效。但它目前只把“积累”做出来了，“治理”完全没跟上。

什么意思呢？我在它的 GitHub 上发现有用户快速堆了 146 个 skills，而且还在持续增长。问题是它只管往里塞，不管往外扔。skill 之间有重复的不会合并，过时的不会清理，质量差的也不会淘汰。时间一长，agent 每轮对话光是读这些 skills 就要多花一大截 token，效率反而越来越低。

说实话，我到现在还没能稳定用 Hermes 完成复杂的开发工作。反过来 OpenClaw 已经是我的日常工具了，拿它做了不少开发任务，甚至给 OpenClaw 开源项目提了 7 个 PR，全部合并了。

所以目前来看，Hermes 更适合做重复率很高的简单任务。如果你的工作场景每天都会碰到新问题，那它自动攒出来的 skills 大概率会越来越乱。复杂开发，我还是用 OpenClaw。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 博客《Building agents that reach production systems with MCP》。文章从 Agent 连接外部系统的三条路讲起，重点梳理了 MCP 服务器的设计模式、认证标准化、上下文优化，以及 Skills 的互补定位。不算长，但信息密度不低，尤其是 Cloudflare 的代码编排模式和 Vault 的凭证管理思路，值得做 MCP 服务器的人细看和参考。

我之前给 Claude Code 配 MCP 服务器的时候，最头疼的是上下文占用的问题，后来《Claude Code 终于解决了 MCP 最大的痛点》那篇写过 Tool Search 怎么解决这个事。但用得越多越发现，上下文只是冰山一角。

本地开发时，Agent 调个 API、跑个命令行工具，一切都很丝滑。但等你想把它放到云上跑，问题就来了：CLI 工具没有 shell 可用，API 调用的认证凭证要自己管，每对接一个新服务就要从头写一套集成代码。

刚刚看到 Anthropic 发了一篇博客，系统梳理了 Agent 连接外部系统的三条路，以及为什么生产环境下 MCP 可能是最务实的选择，分享一下，供大家参考。

把 Agent 接入外部系统

Anthropic 把 Agent 接入外部系统的方式分成三种：直接调 API、用 CLI，以及走 MCP 协议。

直接调 API 是最多人的起点，也是最简单的。Agent 在沙箱里发 HTTP 请求，或者通过 function calling 调用外部服务。一个 Agent 对一个服务没什么问题。但接的服务一多，每个 Agent 和服务的配对都要单独处理认证、工具描述和异常情况。做过微服务的人应该很熟悉，这就是经典的 M×N 集成问题。

CLI 也能用，快、轻量，复用现有工具链。但在移动端、Web 端和云托管平台这些没有 shell 的地方往往会到处碰壁，认证也只能靠磁盘上的凭证文件。说白了，CLI 是本地开发的好帮手，离生产还差一截。

MCP 走的是协议层。Agent 连上一个 MCP 服务器，服务器把你系统的能力暴露出来，认证、发现、语义描述都标准化了。一个远程服务器可以同时服务 Claude、ChatGPT、Cursor、VS Code 这些客户端，部署在哪都行。MCP 的前期投入确实比前两种大一些，但换来的是可移植性，以及协议本身能描述的东西也更多。

我自己的感受是，本地开发阶段 CLI 和 MCP 都够用，但一旦 Agent 要上云、要服务多个客户端，MCP 基本是唯一的选择。那为什么 Anthropic 现在特别强调生产环境？

生产 Agent 跑在云上

因为生产级 Agent 越来越多地跑在云上，它们需要连接的系统也在云上：数据存在那里，工单跟踪在那里，基础设施也在那里。这些系统通常是远程的、带认证的，正好是 MCP 擅长处理的场景。

从 Anthropic 自己的产品线也能看出这个趋势。前段时间发布的 Managed Agents，底层就是靠 MCP 连接外部工具和数据源，之前那篇《Managed Agents 架构拆解》分析过它的脑手分离设计。Claude Cowork、Claude Code Channels 也是类似的思路，MCP 在里面扮演的就是连接层的角色。MCP SDK 的月下载量从年初的 1 亿涨到了 3 亿，增速确实有点猛。

不过 Anthropic 也没说 MCP 就应该替代其他方式。API 是基础，CLI 服务本地开发，MCP 覆盖云端。三条路最终都会并存。

那问题就变成了：决定用 MCP 之后，服务器怎么设计才好用？

MCP 服务器怎么设计才好用

Anthropic 目前 MCP 目录里有 200 多个服务器。从这些实践中他们提炼了几个设计模式，结合我自己写 MCP 服务器的经验，聊聊几个我觉得最有价值的。

远程服务器优先

只有远程服务器才能同时覆盖 Web、移动端和云端 Agent，这是分发的前提。本地服务器在开发阶段够用，但想让 Agent 在任何环境下都能调用你的服务，必须上远程。

按意图分组工具，不要一比一镜像 API

这个我之前在《Claude Code 终于解决了 MCP 最大的痛点》提过，工具越少、描述越好，Agent 用起来越准。一个create_issue_from_thread 工具，比让 Agent 自己拼get_thread +parse_messages +create_issue +link_attachment 靠谱得多。

做过 Agent 开发的你应该都体会过，把底层 API 原封不动暴露给模型，基本就是在赌它能自己编排出正确的调用序列。赌赢的概率不高。我之前做 Kubernetes MCP 服务器的时候，最开始也是把 Kubernetes API 一比一映射成工具，结果模型光是选对工具就要好几轮，后来按运维场景重新分组，调用准确率提升了很多。

大量 API 场景用代码编排

如果你的服务有几百个接口，按意图分组也覆盖不完。这时候 Cloudflare 的做法挺妙的：只暴露两个工具（搜索和执行），覆盖了大约 2500 个 API 端点，整个工具定义只占 1K token。思路是让 Agent 写一小段脚本，服务器在沙箱里跑，只返回结果。

用 MCP Apps 做交互

MCP Apps 是 MCP 协议的第一个官方扩展，允许工具返回交互式界面，图表、表单、仪表盘，直接嵌在对话里渲染。你让 Agent 查一下数据库的慢查询，返回的不是一堆文本，而是一个可排序的交互式表格。这体验一下子就提升上去了，Anthropic 说支持 MCP Apps 的服务器在用户留存上表现好很多，这个不难理解。

还有一个叫 Elicitation 的能力也值得关注。它让 MCP 服务器在工具调用中途暂停，向用户请求输入。比如你让 Agent 删一个资源，服务器可以弹一个确认表单，而不是直接执行。更敏感的操作比如 OAuth 登录，可以把用户引到浏览器里完成，凭证不经过 MCP 客户端。这个设计思路和之前聊过的 Managed Agents 的安全隔离一脉相承，敏感信息能不过手就不过手。

认证这块终于不用自己造轮子了

说实话，认证一直是 MCP 从开发到生产最让人头疼的部分。本地开发时 MCP 服务器大多不需要认证，或者直接用 API Key 凑合。但到了生产环境，用户授权、token 存储、过期刷新、多租户隔离，每个环节都是坑。之前每个 MCP 服务器都得自己处理 OAuth 流程，各种边角情况踩不完。

最新的 MCP 规范在这块改进了不少。CIMD（Client ID Metadata Documents）简化了客户端注册的 OAuth 流程，用户首次授权更快，反复弹授权框的情况也少了。MCP SDK、Claude.ai 和 Claude Code 都已经支持这个规范。

对云端 Agent 来说，令牌的存储和刷新是另一个痛点。Managed Agents 的 Vault 机制处理了这个问题：注册一次用户的 OAuth 令牌，创建 session 时引用 Vault ID，平台自动把凭证注入每个 MCP 连接，过期了自己刷新。不用自己搭密钥管理服务，不用每次调用传 token。这个思路和 Kubernetes 里 ServiceAccount 自动挂载 token 的逻辑挺像的，让凭证管理变成基础设施的一部分，应用层不用操心。

上下文效率：Tool Search 和程序化调用

MCP 服务器越多，上下文占用越大，这个问题前面提到过。Anthropic 现在有两个客户端侧的优化模式。

Tool Search 是按需加载工具定义，不一次性全塞进上下文。Agent 运行时搜索工具目录，只拉取当前任务需要的工具。根据 Anthropic 的测试，工具定义相关的 token 占用能降低 85% 以上，选择准确率基本不受影响。

程序化工具调用是在代码执行沙箱里处理工具返回结果，而不是原样扔回给模型。Agent 可以在代码里循环、过滤、聚合多次调用的结果，只把最终输出放进上下文。复杂的多步工作流能省掉大约 37% 的 token。

两个模式叠加使用的效果更好：上下文更精简，往返次数更少，响应也更快。

Skills 和 MCP 是互补的

这个话题之前也聊过。简单说，MCP 给 Agent 能力（能调什么工具、能访问什么数据），Skills 给 Agent 知识（怎么用这些工具完成具体任务），两者最好结合着一起使用。

具体有两种组合模式。

第一种是把 Skills 和 MCP 服务器打包成 Plugin。Claude 的 Plugin 可以捆绑 Skills、MCP 服务器、Hooks、子 Agent 这些组件，一键分发。比如 Cowork 的数据 Plugin，里面有 10 个 Skills 和 8 个 MCP 服务器，覆盖 Snowflake、Databricks、BigQuery 这些数据工具。这种模式让 Claude 从通用助手变成领域专家。

第二种是让 MCP 服务器自带 Skill。Canva、Notion、Sentry 这些厂商已经在做了，在 Claude 的目录里把 Skill 和 Connector 放在一起。MCP 社区也在做一个扩展，让服务器直接分发 Skills，客户端自动继承，版本跟着 API 走。

我的体会是：MCP 服务器只提供工具的话，Agent 每次都得自己摸索调用顺序和参数搭配，效率不高。Skill 把最佳实践编码进去，等于给 Agent 附了一份操作手册，开箱就能按套路来。

写在最后

回头看生产环境 Agent 集成外部系统这件事，由于 Agent 跑在云上，需要连接的服务也在云上，中间就需要一个标准化的协议层。

相比直接 API 调用和命令行 CLI，MCP 目前是这个位置上最合适的协议，特别是远程 MCP 服务器。MCP 的优势在于它是开放协议，不绑定任何一家模型厂商，一个服务器建好了，Claude、ChatGPT 之类的任意 AI Agent 都能用。

相关资源：

• 原文链接：https://claude.com/blog/building-agents-that-reach-production-systems-with-mcp
• MCP SDK 文档：https://modelcontextprotocol.io/docs/sdk
• MCP Apps 扩展：https://modelcontextprotocol.io/extensions/apps/overview
• 高级工具使用指南：https://www.anthropic.com/engineering/advanced-tool-use
• 写好 Agent 工具：https://www.anthropic.com/engineering/writing-tools-for-agents
• MCP 规范（含 CIMD 和 Elicitation）：https://modelcontextprotocol.io/specification/2025-11-25

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

提到 Harness，大部分人第一反应是 Anthropic 说的那个概念：模型外面包的一层编排代码，负责调用模型、路由工具、管理上下文。我之前写过一篇《为什么单 Agent 搞不定复杂应用？Anthropic 的 Harness 设计给出了答案》，里面详细拆了 Anthropic 的 Generator-Evaluator 模式。Anthropic 的核心观点是 Harness 编码的是对模型能力边界的假设，模型变强了，Harness 就该做减法。

这个理解没错，但只是三种理解中的一种。

最近我把 Claude Code、Hermes Agent 和 OpenClaw 的源码和架构文档都翻了一遍，发现一个挺有意思的事：这三个项目嘴上都在说 Harness，但做出来的东西完全不一样。Claude Code 把 Harness 当脚手架，越轻越好，模型能搞定的事就别替它做。Hermes 把 harness 当学习系统，每次任务都在积累经验，越用越聪明。OpenClaw 把 Harness 当基础设施，Gateway、路由、设备节点、任务调度，跟模型强不强没什么关系。

对 Harness 的理解不同，造出来的产品就完全不同。下面我就带你一起拆开看看它们都是如何设计 Harness 的。

Harness 核心设计

从这三个项目的代码结构和设计文档上，很容易发现它们的架构设计具有明显的不同。

OpenClaw 的核心是 Gateway。官方架构文档第一句也写明了他是一个 long-lived Gateway 拥有所有 messaging surfaces。CLI、macOS app、Web UI、自动化任务，全部通过 WebSocket 连接 Gateway。

手机、Mac、远程设备也通过同一个协议接入，只不过声明自己是 node，暴露摄像头、屏幕、Canvas 等能力。Gateway 默认监听127.0.0.1:18789，连 Canvas 和 A2UI 都由同一个 HTTP server 托管。

也就是说，OpenClaw 把多入口收束成了单控制平面。你从 Telegram 发消息，从 Web UI 操作，从手机节点触发，最终都进入同一套协议、同一套会话管理、同一套工具策略、同一套事件流。也就是说，OpenClaw 先做了神经系统，而不是大脑。

Hermes Agent 的核心是AIAgent。它通过一个 1 万多行的代码，整合了 prompt 装配、provider 选择、工具执行、重试、fallback、上下文压缩、会话持久化等所有的核心功能。CLI、Gateway、ACP、Batch Runner、API Server 这些入口最终都收敛到一起，后来才逐渐补充了 Gateway 和 messaging 平台的适配。

Hermes 的优先级是先把 Agent Loop 做到足够强，让它支持并发工具调用、子代理委派、多 provider fallback、上下文压缩保护，然后再考虑怎么把这个大脑连上外面的世界。

Claude Code 的核心既不是 Gateway 也不是 Agent Loop，而是权限系统和上下文管理。正如《Managed Agents 架构拆解：Anthropic 给 Agent 造了一套 K8s》里提到的，Anthropic 把 Agent 的组件拆成了 session、harness、sandbox 三个独立接口，每个可以独立替换。Claude Code 的源码也是这个思路的体现。

翻它之前泄漏的源码，最庞大的模块是权限相关的代码，处理了六种权限模式、八个权限来源、分类器自动审批、hook 扩展等等。而主循环本身反而很薄，只是负责把每轮完整消息历史交给模型，工具执行完立刻流式返回，没有复杂的调度算法。

Claude Code 的设计哲学可以总结为信任模型+管好边界。模型自己决定调用什么工具、按什么顺序执行、什么时候停下来。Harness 不替模型做决策，只在两个地方卡住：你有没有权限做这件事，上下文是不是快溢出了。

三个项目对 Harness 的理解，在这一层就分道了。OpenClaw 把重心放在多入口收束和协议统一，Hermes 把重心放在 Agent Loop 的能力密度，Claude Code 把重心放在权限管控和上下文保护。

记忆系统设计

记忆是 Agent 从临时工变成长期搭档的关键一步。三个项目在这件事上的做法差异也很大。

Claude Code 的方案最简单，简单到有点反直觉。CLAUDE.md 文件前缀加载，每次会话开始时注入 system prompt。Auto Memory 让模型自己往~/.claude/ 目录下写 Markdown 文件，MEMORY.md 作为索引（最多 200 行、25KB）。没有向量检索，没有 embedding，没有外部数据库。记忆不是主动召回的，而是作为上下文的一部分被模型看到。

上下文压缩也是反应式的：上下文窗口用到快满了才触发压缩。压缩方式是 fork 一个新的 Claude 实例来做摘要，压缩算法会保护工具调用和结果的完整性，不会把一个 tool call 和它的 result 切开。如果压缩连续失败三次，circuit breaker 会停掉，避免死循环。

这个方案的好处是简单、可预测、不依赖外部服务。代价是记忆容量有限，跨会话的信息密度完全取决于 CLAUDE.md 写得好不好。

Hermes Agent 把记忆做成了分层系统。第一层是MEMORY.md 和USER.md，类似 Claude Code 的方案，保存在~/.hermes/memories/，会话开始时注入 prompt。第二层是 SQLite + FTS5 全文搜索，所有历史会话都能被检索和摘要。第三层是 8 个外部 memory provider 插件，包括 Honcho、Mem0、Hindsight 等。

Honcho 的设计值得单独说一下。它不只做向量检索，而是把用户和 AI 都建模为 peer，做跨会话的辩证推理，维护用户表征和 session summary。启用后，Hermes 每轮前会预取相关记忆，每轮后同步对话，会话结束时抽取长期记忆。

Hermes 的记忆哲学是：模型的短期记忆不够用，需要系统帮它在多个时间尺度上积累和召回信息。这和 Claude Code 模型自己能搞定的思路差别挺大的。

OpenClaw 则走了另一条路：把 Context Engine 做成可替换的运行时插件，控制如何构建模型上下文，决定包含哪些消息、如何摘要旧历史、如何跨 subagent 管理上下文。内置的是legacy engine，但插件可以注册完全不同的 engine。

每次模型运行时，engine 有四个生命周期点：ingest(消息进来时)、assemble(构建上下文时)、compact(压缩时)、after turn(一轮结束后)。插件 engine 甚至可以返回systemPromptAddition，动态注入召回指导或检索提示。

OpenClaw 的会话管理也很讲究：DM 默认共享 session，群聊按 group 隔离，rooms 按 room 隔离，cron 每次新 session。多 Agent 场景下，每个 Agent 有独立的 workspace、auth profile、session store。

OpenClaw 的记忆哲学不是记更多，而是让记忆管理本身成为一个可插拔的系统服务。长期 Agent 的记忆需求会不断变化，与其内置一套固定方案，不如把接口留好，让生态去填充。

三种方案，背后是三种对 Agent 该记什么的不同理解。Claude Code 觉得模型够聪明，给它看到就行。Hermes 觉得光看到不够，得帮它在多个时间尺度上积累。OpenClaw 觉得记忆本身的需求会变，不如把接口留好。

扩展性设计

接下来再来看看扩展性的设计，这是让 Agent 能搜索、浏览网页、生成图片、读写文件等各种外置能力的关键。

OpenClaw 把能力扩展拆成了三层：内置 Tools 是 Agent 可以随时调用的预装能力，Skills 是教 Agent 什么时候用、怎么用外部工具的扩展能力，而 Plugins 则是打包了工具、技能、消息通道、模型等各种扩展的能力包。

这个三层模型把三个容易混淆的东西拆开了：工具是默认能做什么，技能是什么时候/怎么样去调用外部工具，插件是怎么打包、发现、分发这些能力。ClawHub 上架了 58000 多个社区 Skill，一条命令安装，这对于带火 OpenClaw 功不可没。

Hermes Agent 的工具系统用了 registry 自注册模式。tools/registry.py 是中心注册表，每个工具文件在模块级调用registry.register() 声明 schema、handler、toolset 归属和可用性检查。model_tools.py 是 registry 之上的薄编排层，负责导出工具定义、处理函数调用、维护工具到 toolset 的映射。

有个很细的设计：model_tools.py 会根据当前真正可用的工具重建execute_code 的 schema。比如 web API key 没配置，模型就不会在 sandbox 里看到web_search 这个工具。这能减少模型“以为自己能做但其实做不了”的幻觉式调用。

Hermes 的技能系统用了 progressive disclosure：Level 0 只加载 name 和 description，Level 1 加载完整技能内容，Level 2 加载技能引用的附件。模型先扫描技能列表，匹配到了再深入加载。更关键的是，Agent 可以通过skill_manage 自己创建、更新、删除技能。解决了一个非平凡任务后，它可以把方法保存为技能文件，下次遇到类似问题直接复用。

这就是 Hermes 说的“程序性记忆”。普通 Agent 完成任务后只留下结果，Hermes 完成任务后还试图留下方法。当你积累 20 个以上自创技能后，同领域任务完成速度能提升 40% 。

Claude Code 的扩展体系跟前两者的思路都不一样，它不是围绕工具注册或技能发现来组织的，而是围绕权限边界层层展开的。

最底层是 28 个内置工具，覆盖文件读写、搜索、Shell 执行、Web 访问、子代理调度等基础能力。这些工具分两类：Read、Glob、Grep 这类只读工具不需要权限，Bash、Edit、Write 这类有副作用的工具每次执行都要过权限检查。权限不在工具注册时声明，而是在执行时由 harness 拦截，模型不需要考虑“我能不能做这件事”，该拦的时候自然会拦。

往上一层是 MCP 协议。Claude Code 通过 MCP 接入外部工具服务器，支持 stdio、HTTP、SSE 三种传输方式。MCP 工具默认是延迟加载的：会话开始时只把工具名称放进上下文，模型需要用的时候通过ToolSearch 工具按需拉取完整 schema。这个设计跟 Hermes 的 progressive disclosure 异曲同工，只是实现路径不同，一个在技能层做分级加载，一个在工具层做延迟发现。

再往上是 Hooks、Skills 和 Plugins 三层扩展。Hooks 提供了 25 个生命周期事件，可以挂 shell 命令、HTTP 请求、甚至 LLM 评估。Skills 遵循开放的 Agent Skills 标准，用 Markdown + YAML frontmatter 定义可复用的工作流，，持参数替换和条件触发。Plugins 则是把 Skills、Hooks、MCP 配置、子代理定义打包成一个可分发的单元。

子代理是 Claude Code 处理复杂任务的核心机制。每个子代理运行在独立的上下文窗口里，有自己的系统提示和会话历史。内置了 Explore（快速搜索，用 Haiku 模型）、Plan（规划研究）、general-purpose（全功能）等预设类型，也支持通过.claude/agents/ 目录自定义。自定义子代理可以精细控制工具白名单、权限规则、模型选择，甚至预加载特定 Skills。

能力管理的复杂性往哪放？OpenClaw 交给社区生态，Hermes 交给 Agent 自身的积累，Claude Code 交给分层的权限边界。

怎么面对模型进步

这个维度最值得琢磨。

Anthropic 有一个很有意思的观察：harness 编码的是对模型能力边界的假设，但模型在进步，假设会过期。Sonnet 4.5 的时候模型有上下文焦虑，随着上下文窗口接近极限会提前收工，harness 里加了重置机制来应对。结果换到 Opus 4.5，这个行为自己消失了，重置机制变成了死代码。

Claude Code 对这一点的应对是大量的功能开关，从它泄露的源码能看到大量 HISTORY_SNIP、REACTIVE_COMPACT、TRANSCRIPT_CLASSIFIER 等等这样的开关。比如，到了 Opus 4.6，之前在 harness 里加的 Sprint 机制（把长任务拆成小块、每块结束后评估）就被整个拿掉了，因为模型已经可以连续写代码不跑偏。Evaluator 也从每个 Sprint 后评分改成了全部开发完再做一轮 QA。

Anthropic 认为 harness 应该为减法而设计。每个组件都应该能被安全移除，而不是越堆越厚。权限分类器也是同一思路，模型能力到了之后，很多需要人类确认的操作可以自动放行（所以后来新增了 Auto 权限模式）。

Hermes Agent 的思路不太一样。它认为有些东西不会因为模型变强而过期：五层记忆系统、技能文件沉淀、跨会话搜索、用户建模。模型再强，也需要知道“上次这个用户让我做过什么”和“这类任务我之前是怎么解决的”。

Hermes 甚至有一个单独的hermes-agent-self-evolution 仓库，用 DSPy 和 GEPA 来做自动化的技能优化。具体做法是：跑一组评估任务，比较优化前后的技能文件在完成效率和准确率上的差异，自动选择更好的版本。目前实现了 Phase 1 的技能文件优化，Phase 2 计划覆盖工具描述和系统提示词。说实话，这个想法挺有意思的，相当于给 Agent 加了一个慢速但持续的自然选择过程。虽然模型会趋同，但谁能把每次任务变成下一次的能力，谁就有了复利。

OpenClaw 的基础设施层几乎不受模型进步的影响。Gateway 不会因为 Claude 变强就不需要了。多入口路由不会过期，设备节点不会过期，会话隔离不会过期，权限分层不会过期。

模型会越来越强，但连接现实世界的管道不会自动出现。你还是需要一个东西来管理“谁能在什么时候通过什么入口让 Agent 做什么事”，模型再强也替代不了这一层。

三种方向，对应三种对“模型进步会淘汰什么”的判断。OpenClaw 认为基础设施不会过期，所以建管道。Hermes 认为经验积累不会过期，所以做加法。Claude Code 认为大部分脚手架会过期，所以做减法。

写在最后

有意思的是，三条路正在往一个方向收敛。Claude Code 加了 auto memory 和 channels，Hermes 加了 Gateway 和多平台适配，OpenClaw 在做 Context Engine 可插拔化。起点不同，但目的地越来越像：一个有记忆、有技能、有入口、有权限、有持久状态的个人 AI 系统。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

还记得去年 Recall 的翻车吗？让 AI 每隔几秒截一次屏，记住关于你的一切，结果截屏未加密存储，最后不得不下架。

现在 OpenAI 在 Codex 中推出了一个类似的功能 Chronicle，让 AI 持续盯着你的屏幕，持续构建和更新关于你的记忆。

Chronicle 做了什么

Chronicle 是 Codex 的一个实验性功能，目前只对 Pro 订阅用户和 Mac 用户开放。在 Codex 设置里打开 Chronicle research preview 开关，状态变成 Running，它就开始工作了。

开启之后，它会在后台定期截取你的屏幕内容，把截图发到 OpenAI 服务器跑一遍 OCR 和视觉分析，提取出文字摘要，再存回你本地的一个 Markdown 文件里。

想象空间确实挺大的。你在浏览器里查了一篇文档，切到编辑器写了几行代码，又去 Slack 回了条消息，这些 Chronicle 都看得到。下次你跟 Codex 对话的时候，不用再花时间解释我刚才在干什么，因为它早就已经知道了。

Codex 的产品负责人 Tibo 说 Chronicle 改变了他和很多 OpenAI 员工使用 Codex 的方式。说白了，OpenAI 想让 Codex 从一个编码工具变成一个全能的 Super App，Chronicle 就是这个方向上的关键一步，让 Codex 能感知到你整个工作环境。

但这里有个问题。

截图去了哪

Chronicle 整体的工作流程比想象中复杂，下面这张图拆解得比较清楚：

简单说，数据流是这样的：

1. 后台定期截屏，临时存在$TMPDIR/chronicle/screen_recording/，6 小时后自动删除
2. 截图发送到 OpenAI 服务器，进行 OCR 和视觉分析
3. 分析结果经过多阶段的提炼和整合，最终以 Markdown 格式存回本地~/.codex/memories_extensions/chronicle/

OpenAI 文档明确指出，截图处理完就删掉，不会用于训练。但有几个细节值得注意。

本地存储的记忆文件是未加密的 Markdown，任何有文件系统访问权限的程序都能读。有意思的是，Recall 翻车之后重新上线时加了不少安全措施：加密数据库、Windows Hello 认证、敏感信息自动过滤（信用卡号、身份证等）。Chronicle 发布的时候，这些一个都没有。

不过这些还不是最让我在意的。更值得警惕的是 prompt injection 的攻击面被大幅扩大了：你打开一个恶意网页，网页里藏了一段指令，Chronicle 截屏后发给 AI 分析，这段指令就可能被执行。以前攻击者只能通过你主动输入的内容来注入指令，现在你屏幕上出现过的一切都是潜在的攻击入口。

OpenAI 的建议是什么？开会前或查看敏感内容前，手动暂停 Chronicle。

不过这就有个明显的问题了，如果系统需要用户自己记得在关键时刻关掉它，那这个系统的设计本身就有问题。

另一条路：Claude Code 怎么做记忆

同样是解决 AI 不记得你在干什么这个问题，Anthropic 走了一条完全不同的路。

Claude Code 的 Auto Memory 不看你的屏幕，也不截图。它只从你和它的对话中学习。当你纠正了它的一个错误、当你表达了某个偏好、当一个 debug 过程走完了，Claude 会判断哪些信息值得记住，然后写进本地的MEMORY.md 文件。

两个产品的思路差别挺大的。Chronicle 想做一个全知全能的助手，持续观察你的整个桌面活动，浏览器查的文档、编辑器里的代码、Slack 里的讨论，它全都能关联起来。这种跨应用的上下文理解是 Auto Memory 做不到的。但代价是你的截图得先过一遍 OpenAI 的服务器，隐私边界从一开始就是模糊的。

Auto Memory 正好反过来，只从对话里提炼，全程不碰你的屏幕。记忆文件就是本地的 Markdown，想删就删，想改就改。代价是 Claude Code 只能记住对话里的东西，对话之外的活动它一无所知。用个不太严谨的类比，Chronicle 像是装了个监控摄像头，Auto Memory 像是发了一本笔记本让它自己记。

为什么 AI 都想看你的屏幕

Recall、Chronicle，加上之前的 Rewind AI（被 Meta 收购后直接关了 Mac 应用），三家公司在不同时间点做了同一个决策：让 AI 看用户的屏幕。

这不是巧合。

做过 AI 编程的你应该有体会：每次开一个新会话，都得重新交代一遍“我在做什么项目、用什么技术栈、之前跑到哪一步了”。我自己用 Claude Code 的时候，复杂项目开头经常要花点时间交代背景信息，有时候还忘了说某个关键细节，结果 Claude Code 给出的方案就跑偏了。这个冷启动的成本，用得越深越明显。

上下文是 AI 最稀缺的资源，模型再聪明，不知道你在干什么就是不知道。而屏幕恰好是信息密度最高的上下文来源，一张截图包含的信息量，远比你打字描述的多得多，编辑器里的代码、浏览器里的文档、终端里的报错，全在一个画面里。我觉得这就是为什么尽管 Recall 被骂得那么惨，OpenAI 还是选择做同样的事。

但这里有个解不开的矛盾：用户想要 AI 懂我，同时又不想 AI 监视我。目前谁也没想出两全的办法。也许等端侧模型足够强，截屏和分析都能在本地完成的时候，这个矛盾才有可能真正化解。

GitHub 上有个叫 Screenpipe 的开源项目，做的事情跟 Chronicle 类似，但完全在本地处理。截屏、OCR、记忆生成，全部跑在你自己的机器上，不上传任何数据。18000 多个 star，说明这个需求是真实的，但用户对怎么实现有自己的判断。

写在最后

回到开头的问题：Recall 搞砸了，为什么 OpenAI 还要做 Chronicle？因为上下文争夺战才刚开始。

不只是 OpenAI 和 Anthropic，Google 在最新发布的 Gemini Mac App 里也加了读屏功能。每家都在赌同一件事：AI 的终局不是一个更聪明的聊天框，而是一个真正理解你工作的搭档。问题在于，这个搭档需要时刻盯你的屏幕才能做到吗？

相关资源：

• Codex Chronicle 官方文档：https://developers.openai.com/codex/memories/chronicle
• Claude Code Memory 文档：https://code.claude.com/docs/en/memory
• Greg Brockman 发布推文：https://x.com/gdb/status/2046293955009274019
• Screenpipe（开源本地方案）：https://github.com/mediar-ai/screenpipe

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文基于 Claude Code 作者 Thariq 昨晚发布的长文《Using Claude Code: Session Management & 1M Context》编译整理，结合评论区的精华问答和个人使用经验，帮中文读者快速掌握上下文管理的核心策略。

Claude Code 升级到 100 万 token 上下文之后，我以为终于可以放飞自我了，一个 Session 从头用到尾，再也不用担心上下文不够用。

结果用了一段时间发现，情况没那么简单。上下文确实够大了，但有时候聊着聊着，Claude Code 的回答质量明显下滑，响应速度变慢不说，前面读过的文件细节开始记不清，甚至会重复做已经做过的事情。更让人困惑的是，有时候 compact 一下反而把关键信息给丢了。

这种体验应该不只我一个人有。昨晚 Claude Code 的作者 Thariq 专门写了一篇长文，系统讲了上下文管理这件事。

这里面有些东西是我之前没想清楚的，特别是 Rewind 和 Compact 的使用策略。再加上评论区 Thariq 亲自回复了不少细节，值得好好聊聊。

上下文腐烂：不是越多越好

上下文窗口越大，模型表现越好？不一定。

Thariq 用了一个很形象的说法叫上下文腐烂。随着上下文增长，模型的注意力被分散到更多 token 上，老旧的、跟当前任务无关的内容开始干扰判断。100 万 token 的窗口，实际上在 30 万到 40 万 token 左右就可能开始出现性能下降。当然，Thariq 也强调这个数字跟任务类型强相关，不是一条硬线。

评论区有人分享了一个挺有意思的观察：同一个 Session 里始终聚焦一个主题深挖，即使对话很长，质量下降也不明显。但频繁跳转不同主题，腐烂来得很快。

这跟我自己的体感也吻合。做一个功能从头做到尾，体验挺好。做完功能接着改 bug、写文档、调配置？Claude Code 就开始犯迷糊了。

100 万上下文不是让你往里塞 100 万 token。它给你的是更大的操作空间，让你能跑更长的自主任务，但上下文质量仍然需要主动管理。

每一轮对话都是一个决策点

Thariq 文章里最让我觉得有启发的，是这个框架：Claude Code 每完成一轮操作后，你面前其实有五条路可以走。

最自然的当然是继续对话，在当前 Session 里接着发下一条消息。大多数人都是这么用的，包括我自己。

但继续对话意味着什么？所有之前的工具调用结果、读过的文件内容、尝试过的方案，全都留在上下文里。有用的，没用的，一锅炖。积累到一定程度，上下文就开始腐烂了。

另外四条路各有各的用法，下面逐个拆开聊。

/rewind（或者连按两次 Esc）可以回退到之前的某条消息，从那个点重新开始。回退点之后的所有消息都会被丢弃。这适合“试了一条路发现走不通”的场景。

/clear 是彻底开一个新 Session。你需要自己把关键上下文写下来带到新会话里，比如“我们在重构 auth 中间件，约束是 X，相关文件是 A 和 B，已经排除了 Y 方案”。费点功夫，但新 Session 的上下文完全由你决定。

/compact 让 Claude Code 总结当前对话，然后用总结替换掉原始对话历史。你不用动手写任何东西，但总结的质量取决于 Claude Code 自己的判断。

还有 Subagent，也就是让 Claude Code 起一个子 Agent 来处理下一段工作。子 Agent 有自己独立的上下文窗口，做完之后只把最终结果返回给主 Session。中间产生的大量工具调用和文件读取不会污染主上下文。

这五个选项不是互斥的，更像是一个工具箱。关键在于判断什么时候该用哪个。

新 Session 还是继续？

Thariq 给了一条简单的判断原则：新任务，新 Session。

但实际操作中有灰色地带。比如你刚实现完一个功能，接下来要给它写文档。按说是不同任务，应该新开 Session。但如果新开，Claude Code 得重新读一遍你刚写的那些文件，既慢又费 token。

Thariq 的建议是，这种情况可以继续用当前 Session。写文档对上下文的“智力要求”没那么高，多一些历史上下文的干扰问题不大，换来的是不用重新读文件的效率提升。

所以这儿不是看任务是否相关，而是看新任务对上下文质量的敏感度。调试、重构，这类需要精确理解代码逻辑的活儿，上下文干净很重要，值得新开。写文档、加注释？继续用就行。

不过话说回来，什么时候该新开 Session 只是上下文管理的一部分。更关键的问题是：方案试错了怎么办？

Rewind：最被低估的上下文管理操作

如果只能从这篇文章里记住一个技巧，Thariq 说应该是 Rewind。

场景是这样的：Claude Code 读了五个文件，试了一个方案，结果不行。这时候很多人的本能反应是继续发消息说“那个方案不行，试试 X 吧”。

问题在于，这条纠正消息虽然给了新方向，但之前那次失败尝试的所有中间过程，读文件的结果、错误的代码、报错信息，全都还留在上下文里。Claude Code 的注意力不得不穿越这些无用信息来理解你的新指令。

更好的做法是 Rewind 到 Claude Code 读完文件之后、开始尝试方案之前的那个点，然后重新给指令：“不要用方案 A，foo 模块没有暴露那个接口，直接用方案 B。”

失败的尝试从上下文里彻底消失了。Claude Code 拿到的是一个干净的起点，加上你从失败中提炼出的经验。

Thariq 还提到一个配套功能叫“summarize from here”，可以让 Claude Code 在回退前先总结它学到了什么，生成一条交接消息。有点像给过去的自己写一封信：“方案 A 走不通，foo 模块的接口不对，直接走方案 B。”然后 Rewind，把这封信贴到新的起点。

这里有个大家比较关心的问题：Rewind 之后，会不会导致 prompt cache miss？毕竟上下文变了，缓存可能失效，那延迟和成本都会上去。Thariq 直接回复说不会，Rewind 之后仍然是 cache hit。

这意味着 Rewind 几乎没有额外代价。免费的上下文清理，不用白不用。

Compact 用不好，问题出在哪

很多人用/compact 的体验是玄学。有时候压缩完一切正常，有时候关键信息莫名其妙地丢了。

Thariq 解释了bad compact 的根本原因：模型无法预测你接下来要做什么。

举个例子，你花了很长时间在 debug 一个问题，中间偶然看到bar.ts 里有个 warning。debug 结束后自动触发了 compact，Claude Code 总结了整个 debug 过程，但那个顺带看到的 warning 被判定为不重要，从总结里丢掉了。然后你下一条消息说“修一下 bar.ts 里那个 warning”，Claude Code 就懵了，因为它的上下文里已经没有这个信息了。

更糟糕的是，compact 触发的时机往往是在上下文快满的时候，恰恰是上下文腐烂最严重、模型最不清醒的时刻。也就是说，模型在最笨的时候，被要求做一个关键的总结决策，能够稳定才怪。

不过 100 万上下文带来了一个好处：你有更多的时间窗口来主动 compact，不用等到快满了才被动触发。

这里有一个很多人不知道的技巧：/compact 可以带参数。比如/compact focus on the auth refactor, drop the test debugging，直接告诉 Claude Code 重点保留什么、可以丢掉什么。

总之，Compact 的正确用法不是等它自动触发，而是在阶段性工作完成后，带着明确的指令主动执行。

Compact 解决的是上下文太长怎么瘦身的问题。但还有一种情况：你明确知道接下来一段工作会产生大量中间输出，而你只要最终结论。这时候该怎么办？

用 Subagent 管理上下文

大多数教程把 Subagent 当并行执行或者任务委派来讲。Thariq 提了一个不同的角度：Subagent 本质上是一种上下文管理工具。

判断标准就一句话：你需要的是中间过程，还是最终结论？

如果你让 Claude Code 在另一个代码库里调研 auth 的实现方式，中间它可能读了二十个文件、试了好几种搜索，产生了大量的工具调用输出。但你真正需要的只是一份总结：“他们用了 JWT + refresh token，关键逻辑在 auth/middleware.ts 里，token 过期时间是 24 小时。”

如果这些中间过程留在主 Session 里，就是纯粹的上下文污染。用 Subagent 来做，中间过程封装在子 Agent 的独立上下文里，主 Session 只拿到最终的总结。

Thariq 给了几个典型场景。比如让 Subagent 根据 spec 文件验证你的实现是否符合要求，只返回“通过/不通过”和问题列表。或者让 Subagent 去读另一个代码库，总结 auth 是怎么实现的，然后你在主 Session 里按总结来写自己的。还有让 Subagent 根据 git 变更写文档，写完直接交付，中间读了多少文件、改了几版，主 Session 完全不需要知道。

共同特点就一个：中间过程产出量大，最终需要的信息量小。

Subagent 默认继承主 Agent 的模型，但你可以在 Agent tool 参数里用model 字段覆盖，比如主任务跑 Opus，Subagent 用 Haiku 来省钱。不过实际用下来我发现一个有点尴尬的地方：Claude Code 自己就很爱起 Explore agent 来搜索代码，然后又提示你 subagent 使用量过高。自己制造开销自己报警，这个体验还有优化空间。

写在最后

看完 Thariq 这篇文章，最大的感受是：上下文管理这件事，其实跟程序员管理内存没什么本质区别。

100 万 token 像是一台内存超大的工作站。内存大了，能同时打开更多文件、跑更长的任务，但不管内存多大，working set 永远应该保持精简。

从 Claude Code 目前的工具链来看，Rewind 处理回退，Compact 处理压缩，Subagent 处理隔离，Auto Memory 处理跨 Session 的持久化，四件套基本覆盖了上下文管理的主要场景。Thariq 在文章最后也说了，未来 Claude Code 会更主动地帮你管理上下文，但现在这个阶段，理解这些机制比等待自动化更实际。

一个表格总结：

养成 Rewind 的习惯，主动/compact 带参数，中间过程多的任务扔给 Subagent。这三个动作做到位，大多数上下文问题就解决了。

相关资源

• Thariq 原文（X Article）：https://x.com/trq212/status/2044548257058328723
• Claude 官方博客版本：https://claude.com/blog/using-claude-code-session-management-and-1m-context
• Claude Code 文档：https://docs.anthropic.com/en/docs/claude-code

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

看 YouTube 上的技术演讲，遇到讲得特别好的，想把要点记下来。以前的流程是：先找个在线工具下载视频，再找个工具提取字幕，字幕格式乱七八糟还得手动清理。一套下来，光找工具就花了半小时，笔记还没开始写。

另一个场景更折腾。录完一段产品 DEMO，画面有了，但没有解说，自己录需要反复调节奏。每次都在想，Claude Code 能帮我写代码，为什么不能帮我处理这些视频的活？

想了想，干脆自己写一个。

于是就有了 video-skills

video-skills 是我开源的一个视频处理 Skill 集合，包含三个技能：

• download-video：从 YouTube、Bilibili、Twitter/X 等 1000 多个平台下载视频
• transcribe-video：提取视频字幕，优先走内嵌字幕，没有才调 API 去转录
• narrate-video：给视频自动生成配音，画面和语音节奏对齐

三个技能可以单独用，也可以串起来。比如我最常用的流程是：下载一个 YouTube 视频 → 转成文字 → 拿着文字稿去做笔记整理。或者录完一段 DEMO → 让 Claude 看着画面写解说词 → 生成配音合进视频。

安装有两种方式。在 Claude Code 里直接：

/plugin marketplace add feiskyer/video-skills/plugin install video-skills@video-skills

或者用 npx：

npx skills add feiskyer/video-skills

前置依赖就两个：yt-dlp 和ffmpeg，macOS 用 Homebrew 装就行：

brew install yt-dlp ffmpeg

其他平台可以让 AI 帮你自动安装。

下面按我自己最常用的两个场景，看看它们的用法。

场景一：YouTube 视频变文字笔记

上周看到 Andrej Karpathy 一个新访谈，一个多小时，想先拿到文字稿挑重点看。打开 Claude Code，把链接丢进去：

帮我下载这个视频 https://www.youtube.com/watch?v=kwSVtQ7dziU

download-video 会用 yt-dlp 把视频拉下来，存到~/Downloads/Videos/。只要音频、指定 720p 这些，直接用自然语言说就行。

下载完接着转文字：

把刚下载的视频转成文字

transcribe-video 会先检查视频有没有内嵌字幕。YouTube 上很多视频自带字幕，质量比语音识别好，速度快，关键是不花 API 的钱。只有没字幕的时候才走 OpenAI 的gpt-4o-transcribe。转出来的文字稿自动清理了时间戳和格式标签，直接就是干净的纯文本。拿到文字稿再让 Claude 做个摘要，整个流程一气呵成。

没有内嵌字幕的视频需要配置 API Key，创建~/.transcribe_video.env：

OPENAI_API_KEY=your-key-here

也支持其他兼容 OpenAI API 的平台，加上OPENAI_API_BASE 就行。

不过下载和转录只解决了看视频的问题。如果你还需要编辑视频呢？比如录了个产品 DEMO，画面有了，但没声音。

场景二：录完 DEMO 自动配音

以前自己录个视频 DEMO，经常出现口误、卡壳、节奏不对等等的问题，录完还要花很长时间去剪辑，折腾半天才能搞定。

现在录好视频，直接一句话就可以搞定配音问题：

给这个 DEMO 视频加上中文配音 demo.mp4

Claude Code 会先每隔几秒截帧，看每个时间点屏幕上在发生什么，建一个场景时间表。然后根据画面写带时间戳的解说词，每段文字量只占时间窗口的 80% ，段落之间自然留白。最后调 Azure TTS 逐段生成语音，按时间戳合成到视频里。

不过使用时需要注意，配置 Azure 密钥，创建~/.narrate_video.env 并设置：

AZURE_SPEECH_KEY=your-key-hereAZURE_SPEECH_REGION=eastus

写在最后

video-skills 做的事情其实并不复杂，只是把 yt-dlp、ffmpeg、还有 Azure Speech 这些命令行工具和 AI 调用包进了 Skill，但用起来的流畅度完全不一样。感兴趣的话可以直接安装来试试：npx skills add feiskyer/video-skills。

video-skills GitHub 为https://github.com/feiskyer/video-skills，有任何问题欢迎贡献完善。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them》，由 Cara Phillips 撰写。

用一个 Agent 搞不定复杂任务？上多 Agent 吧。这个判断现在大家基本都认了。但上多 Agent 之后紧跟着一个更具体的问题：这些 Agent 之间怎么配合？

我之前写过 Anthropic 的 Harness 设计和 Managed Agents 架构，都涉及到多 Agent 的分工协作。但那两篇偏重怎么搭基础设施，没有系统聊过协调模式本身该怎么选。网上能找到的多 Agent 教程大多也停留在“拆任务 + 合结果”这个层面，对模式之间的取舍和演进路径讲得不多。Anthropic 刚发的这篇博客正好补了这个缺口，把多 Agent 协调归纳成五种模式，从最简单到最复杂，还给出了什么时候该从一种演进到另一种的判断标准。

读完最大的感受是：大部分团队的问题不是不知道多 Agent 的好处，而是上来就挑了一个听起来最酷的模式，结果被协调开销拖死了。Anthropic 的建议是，从最简单的能跑通的模式开始，看它哪里撑不住了，再往上演进。

模式一：生成-验证

这是最简单的多 Agent 模式，也是部署最广的。

逻辑很简单。一个 Agent 负责生成输出，另一个负责评估。评估通过就结束，不通过就把反馈打回给生成方，重新来一轮。循环下去直到通过或者达到最大迭代次数。

最典型的应用是代码生成：一个 Agent 写代码，另一个写测试、跑测试。客服场景也适用，生成方起草邮件回复，验证方检查是否准确引用了产品文档、是否回应了用户提到的每个问题。

这个模式看着简单，但踩坑的地方也很集中。

最常见的失败是验证标准太模糊。如果你只告诉验证方检查输出是否足够好，它大概率会糊弄人，放行所有东西。验证方的价值完全取决于你能不能把“好”拆成具体的、可检查的标准。

这一点在我之前写 Harness 设计那篇里也提过。Anthropic 的工程师 Prithvi 花了很多精力调教 Evaluator，反复看日志、找判断偏差、改 Prompt，来回迭代了好几轮才让它的评分标准达到合理水平。

另一个问题是迭代循环可能卡死。生成方解决不了验证方提的问题，两边来回震荡不收敛。所以必须设最大迭代次数，加一个兜底策略，比如升级给人处理，或者返回当前最好的版本并标注问题。

模式二：编排-子 Agent

这是层级式的分工。一个 Agent 当 Team Lead，负责规划任务、分配工作、汇总结果。子 Agent 接到具体任务后执行完就汇报。

Claude Code 用的就是这个模式。主 Agent 自己写代码、编辑文件、跑命令，需要搜索大型代码库或者调查独立问题时，就在后台派 subagent 去做，自己继续手头的活。每个 subagent 在自己的上下文窗口里工作，完成后把精炼过的结果返回给主 Agent。

这个模式适合任务拆分清晰、子任务之间依赖少的场景。比如自动化代码审查：一个 PR 进来，需要查安全漏洞、检查测试覆盖率、评估代码风格、验证架构一致性。每个检查维度独立、上下文不同、输出格式明确。编排 Agent 把每个检查派给专门的子 Agent，收集结果后合成一份统一的 Review。

问题出在信息瓶颈上。当子 Agent 发现了对其他子 Agent 有用的信息时，这条信息必须经过编排 Agent 中转。安全子 Agent 发现了一个认证漏洞，这个发现影响架构子 Agent 的分析。编排 Agent 需要识别这种依赖关系并正确路由信息。经过几轮中转之后，关键细节经常被丢失或者在摘要中被省略掉。

我在用 Claude Code 的 subagent 时也有类似体感。subagent 搜完代码库回来的结果有时候会把关键上下文压缩掉，主 Agent 拿到的是一个干净但不够完整的摘要。对于简单查询这不是问题，但对于需要子 Agent 之间共享发现的复杂任务，编排模式就开始吃力了。

模式三：Agent 团队

编排模式里的子 Agent 是用完即弃的。接到任务，干完活，交结果，走人。但如果任务需要 worker 在多轮中积累经验呢？

Agent 团队模式的区别就在这里：worker 是持久的。

一个协调者启动多个 worker Agent 作为独立进程。领任务，干活，交结果。不重置，不遗忘。每个 worker 在多轮迭代中积累对自己负责领域的熟悉度。

最直观的例子是大规模代码迁移。每个 worker 分管一个服务，在反复处理这个服务的依赖、测试、部署配置的过程中，逐渐摸清它的脾气。一次性 subagent 每次接手都要重新理解服务的配置约定和依赖关系，持久 worker 第一次弄明白之后后续迭代直接复用，省掉重复的上下文加载。

但独立性是硬前提。

团队模式里的 worker 没有中间人帮忙传话。一个 worker 的改动影响了另一个，谁都不知道，产出可能冲突。多个 worker 操作同一个代码库时尤其明显，常见的应对方式是文件级别的分区或者合并前跑冲突检测，但这增加了协调者的复杂度。完成时间的参差也是个问题，一个 worker 两分钟搞定，另一个要二十分钟，协调者得有耐心等。

模式四：消息总线

前面三种模式都有明确的协调者在指挥交通。但如果 Agent 数量继续增加、交互模式变得不可预测呢？

消息总线引入了一个共享通信层。核心操作就两个：发布和订阅。Agent 订阅自己关心的 topic，路由器负责分发。新 Agent 上线不需要改已有的连接，订阅相关 topic 就能开始接收工作。搞过微服务事件驱动架构的应该不陌生，本质上就是 Kafka 那套思路，只不过参与者从服务变成了 Agent。

Anthropic 举的例子是安全运维自动化。告警从多个来源进来，分诊 Agent 分类后路由给对应的调查 Agent，调查结果再流向响应协调 Agent。事件一个阶段接一个阶段地流下去，新出了什么威胁类型就加个新 Agent，各个 Agent 还能独立开发部署。

代价是可追溯性变差了。一个告警触发五个 Agent 之间的事件级联，要搞清楚到底发生了什么，调试难度比编排模式那种顺序决策链高了不少。路由器分错类或者丢了事件更麻烦，系统会静默失败，什么都不处理但也不崩溃。

模式五：共享状态

前四种模式里都有一个中心角色在管理信息流。共享状态模式把这个中间人去掉了。

没有中央协调者。Agent 自主运行，读写一个共享的数据库、文件系统或文档。工作一般从往存储里丢一个问题或数据集开始。停下来的条件有几种：时间到了、结果收敛了，或者有个专门的 Agent 判断存储里的东西已经够用了。

研究综合场景是这个模式的主场。多个 Agent 分头调查一个复杂问题的不同方面，学术 Agent 发现了一个关键研究者，这条信息对行业 Agent 调查这个研究者的公司立刻就有用。不用等协调者来路由，发现直接写进存储，其他 Agent 马上就能看到。附带好处是没有单点故障，任何一个 Agent 停了，其他 Agent 继续读写。

代价也很明显。Agent 可能重复工作或者走互相矛盾的方向。更棘手的是反应式循环：Agent A 写了一个发现，Agent B 读到后写了跟进，Agent A 看到跟进后又回应。系统持续烧 token 但不收敛。重复工作和并发写入有成熟的工程方案，加锁、版本控制、分区都行。但反应式循环是行为层面的问题，必须认真设计终止条件：时间预算、收敛阈值，或者专门的 Agent 来判断何时该停。

这个模式让我想到分布式系统里的最终一致性。没有强协调者的好处是吞吐量高、没有瓶颈，但你需要在应用层面处理冲突和收敛问题。Agent 领域也是同样的取舍。

怎么选，怎么演进

五种模式摆在面前，选哪个？Anthropic 给了几组对比的决策逻辑，我觉得最实用的是前两组。

编排-子 Agent vs Agent 团队

两者都有协调者分派工作，区别在于 worker 需要维持上下文多久。子任务短小、输出明确的，用编排模式。子任务需要多步骤持续工作、会从积累的上下文中受益的，用团队模式。判断标准是：当子 Agent 需要跨调用保留状态时，团队模式更合适。

我自己的经验也验证了这一点。Claude Code 日常的代码搜索、文件查阅用编排模式完全够用，subagent 干完就走。但之前写复杂 feature 的时候，需要多个 Agent 持续处理不同模块的开发和测试，编排模式的一次性 subagent 就不够用了，每次都要重新理解模块上下文。

编排-子 Agent vs 消息总线

两者都能处理多步骤工作流，区别在于工作流结构是否可预测。步骤顺序事先已知的，用编排模式。工作流由事件驱动、可能随发现变化的，用消息总线。有个经验法则：当编排 Agent 里的条件分支越来越多、需要处理越来越多的特殊情况时，就该考虑换消息总线了。

Agent 团队 vs 共享状态

各管各的互不交叉，用团队模式。发现需要实时流通，用共享状态。一旦 worker 之间需要互相沟通而不只是最后汇总结果，共享状态更自然。

消息总线 vs 共享状态

事件从一个阶段触发到下一个阶段然后完成的，用消息总线。Agent 在持续积累的知识基础上反复迭代的，用共享状态。还有一个值得留意的信号：如果消息总线里的 Agent 发布事件是为了分享发现而不是触发动作，那你可能需要的是共享状态。

写在最后

实际生产系统往往会混用多种模式。常见的组合是外层用编排-子 Agent 管整体工作流，内层某个协作密集的子任务用共享状态。或者外层用消息总线做事件路由，每种事件类型由一个 Agent 团队来处理。这五种模式是积木，不是互斥的选项。

Anthropic 的建议是从编排-子 Agent 开始。它能覆盖最广的问题范围，协调开销也最低。等它在特定场景下撑不住了，再根据具体瓶颈演进到其他模式。

Claude Code 就是编排-子 Agent 模式的典型实现，对大多数日常任务来说完全够用。只有当任务复杂到需要多个 Agent 持续协作、共享中间发现的时候，才值得引入更复杂的模式。

有意思的是，不同框架对协调模式的抽象思路差异很大。Anthropic 这套分类偏描述性，告诉你有哪些模式、怎么选。LangGraph 走的是 graph-based 的路子，用状态图来定义 Agent 之间的流转逻辑，更偏编程范式。CrewAI 则是角色分工优先，先定义 Agent 的角色和目标，协调模式隐含在角色关系里。三种抽象各有适用场景，但底层要解决的问题是一样的：谁跟谁通信、信息怎么流、什么时候该停。

相关资源：

• 原文链接：https://claude.com/blog/multi-agent-coordination-patterns
• 构建多 Agent 系统：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
• Harness 设计：https://www.anthropic.com/engineering/harness-design-long-running-apps
• Managed Agents：https://www.anthropic.com/engineering/managed-agents
• 构建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

最近用 Claude Code 写代码，总觉得哪里不对。

我的 CLAUDE.md 里写得很清楚：每次开发完成后，先跑单元测试,再跑 e2e 测试。这个要求跟了我好几个月，之前一直好好的。但最近两三周，e2e 测试愣是不跑。单元测试做完，它就活干完开始总结了。

我以为是提示词不够明确，又在每个任务最后都加了一行“e2e 测试必须执行，不能跳过”这样的提示词。结果还是没用。最后变成每次单元测试跑完，手动再输一句“跑 e2e”，它才肯动。

一开始以为是自己的问题。直到前几天 Hacker News 上炸了一个帖子，才知道不止我一个人。

有人分析了 Claude Code 的 thinking 深度，发现从 2 月底开始下降了 67% 。Claude Code 的作者 Boris Cherny 在 HN 上亲自回复了。他把问题拆成了两个原因。

第一个是 adaptive thinking。Opus 4.6 上线后默认启用了自适应思考，模型自己决定每一轮想多久。听起来更高效，但它经常判断失误。觉得这个任务简单，少想一点就行，该深入的地方直接跳过。

Boris 后来进一步确认：有用户已经设了 effort=high，但 adaptive thinking 仍然在某些轮次分配了零思考 token。零思考，直接出现幻觉了。

第二个是 effort 默认值。3 月 3 号开始，Claude Code 把默认 effort 从 high 降到了 medium。Boris 说这是成本-延迟曲线上的最佳点。但对需要深度推理的任务，这就不够了。

知道原因，解决起来不复杂。

最简单的办法是输入 /effort high，想更激进可以 /effort max。

但光调 effort 不够，核心问题是 adaptive thinking 会自作主张降低思考量。关掉它需要设环境变量：CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1。

你可以在 ~/.claude/settings.json 里一次性配好这两个配置:

{"env": {"CLAUDE_CODE_EFFORT_LEVEL":"max","CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING":"1" }}

这样每次启动自动生效。

顺便提一个反直觉的坑：ULTRATHINK 触发的是 high effort，不是 max。如果你已经设了 /effort max，加 ULTRATHINK 反而会降低那一轮的 effort。

我自己设完这套配置后，e2e 被跳过的情况少了不少。从每次都跳变成偶尔还会跳。不能说完全解决，但至少不用每次手动催了。

如果你也觉得最近 Claude Code 不太对劲，先试试上面那几个配置。

相关资源

• Boris 在 HN 的回复:https://news.ycombinator.com/item?id=47664442
• 原始 issue 讨论:https://news.ycombinator.com/item?id=47660925
• Claude Code 设置文档:https://code.claude.com/docs/en/settings

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程博客《Scaling Managed Agents: Decoupling the brain from the hands》，由 Lance Martin、Gabe Cemaj 和 Michael Cohen 撰写。

Kubernetes 早就是 AI 基础设施的事实标准了。不管是大模型训练还是推理服务，最后都跑在 K8s 上。AI Agent 也不例外，Harness、sandbox、工具调用这些组件，基本都可以容器化部署。

但跑过长时间 Agent 任务的人应该都碰过这种事：Agent 跑着跑着容器挂了，session 没了，只能从头来。session 卡死了想调试，Harness、sandbox、session 全在一个容器里，根本分不清问题出在哪。好不容易跑起来了，上下文窗口又满了，压缩还是丢弃，怎么选都可能踩坑。

做过 K8s 的人看这些问题应该很眼熟。十年前容器编排领域碰到的也是同一类：组件耦合、状态丢失、扩展困难。K8s 的解法是把硬件虚拟化成抽象层，Pod、Service、PersistentVolume 这些概念比底层硬件活得久得多。你换磁盘、换机器，上层应用完全不用管。

Anthropic 昨天开放公测的 Managed Agents，本质上在做同样的事，只不过虚拟化的对象从硬件换成了 Agent 的组件。

Anthropic 的工程博客一直在聊怎么给 Agent 搭 Harness：从构建有效 Agent 到长时间任务的 Harness 设计，再到上下文工程。这些文章贯穿着一条线索：Harness 编码的是对 Claude 当前能力边界的假设，但模型在进步，假设会过期。

举个例子。之前在 Sonnet 4.5 上，他们发现模型会随着上下文窗口接近极限而提前收工（也称为上下文焦虑）。于是 Harness 里加了上下文重置机制。结果换到 Opus 4.5 上一跑，行为消失了。重置机制变成了死代码。

Harness 免不了一直改下去。所以 Anthropic 造了 Managed Agents：用一组尽可能通用的接口来运行长时间 Agent，让这些接口比任何一套具体的 Harness 实现活得更久。

它把 Agent 的核心组件虚拟化成了三个接口：session（发生了什么的完整事件日志）、harness（调用 Claude 和路由工具调用的循环）、sandbox（Claude 跑代码和编辑文件的执行环境）。每个组件可以独立替换，互不干扰。跟 K8s 对 Pod、Volume、Service 的抽象思路一致。

别养宠物

做过 K8s 的你对 Pets vs Cattle 这个比喻肯定不陌生。Pet 是你精心照料的单台服务器，挂了就得抢救；Cattle 是随时可以杀掉重建的无状态实例。云原生的核心理念之一就是把所有东西变成 Cattle。

Managed Agents 一开始没做到这一点。

最初的设计是把所有 Agent 组件塞进一个容器。好处是文件操作就是本地 syscall，不需要设计服务边界。但这就养了一只宠物。容器挂了，session 就没了。容器卡住了，得想办法把它救活。

救活容器意味着调试卡死的 session。唯一的观察窗口是 WebSocket 事件流，但它分不清故障发生在哪个环节。Harness 的 bug、事件流的丢包、容器下线，在外面看起来症状完全一样。要搞清楚怎么回事，工程师得开 shell 进到容器里，但容器里还有用户数据，这条路基本走不通。

还有一个更深的问题。Harness 默认 Claude 的工作内容就在同一个容器里。当客户说“我想让 Claude 连我自己的 VPC”时，要么做网络对等互联，要么让客户在自己的环境里跑 Anthropic 的 Harness。一个 Harness 里硬编码的假设，变成了基础设施层面的约束。

这跟早年单体应用跑在物理机上的困境太像了。

把大脑从手上拆下来

解法是把大脑（Claude 和 Harness）从手（sandbox 和工具）和记忆（session 日志）上拆开。每个组件变成一个接口，对其他组件的假设尽可能少，独立故障、独立替换。

K8s 里 Pod 是无状态的计算单元，PersistentVolume 是持久化存储，两者通过声明式绑定关联但互不依赖。Pod 挂了重建一个，数据还在。Managed Agents 的拆法思路一样。

Harness 不再住在容器里。它像调用其他工具一样调用容器：execute(name, input) → string。容器变成了 Cattle，挂了就挂了，Harness 把失败当作工具调用错误传回给 Claude，Claude 决定要不要重试。重试的话，provision({resources}) 拉一个新的就行。

不用再抢救挂掉的容器了。

Harness 自己也是 Cattle。session 日志在外部，Harness 里没有任何需要在崩溃中存活的状态。挂了？wake(sessionId) 启动一个新的，getSession(id) 拿回事件日志，从最后一个事件继续。运行过程中用emitEvent(id, event) 往 session 写入持久化记录。

这里面还有一个安全维度值得单独说。

之前所有东西耦合在一个容器里的时候，Claude 生成的不可信代码和凭证跑在同一个环境中。一次成功的 prompt injection 只需要说服 Claude 读一下自己的环境变量。拿到 token 之后，攻击者可以开新 session 干什么都行。

收窄 token 权限？当然可以。但这本身又是一个假设：Claude 拿着受限 token 干不了什么。模型在变强，这个假设随时可能失效。

结构性的解法是让 token 在 sandbox 里根本不可达。Git 仓库的做法是在 sandbox 初始化时用 token 克隆仓库并写入本地 git remote，之后push 和pull 都走本地配置，Agent 从头到尾碰不到 token。自定义工具走 MCP，OAuth token 存在安全保险箱里，Claude 通过专用代理调用 MCP 工具，代理根据 session 拿到对应的凭证再调外部服务。整个链路里，Harness 不接触任何凭证。

Anthropic 这个思路挺值得参考的：不是所有安全问题都要靠权限收窄来解决，有时候换个架构就能把问题消除掉。

Session 不是上下文窗口

脑手分离解决了组件耦合的问题，但 Agent 跑久了还有另一个挑战：上下文管理。

长时间任务经常超出 Claude 的上下文窗口。常见的应对方式都涉及不可逆的决策：compaction 把上下文压缩成摘要，memory 工具把信息写到文件，context trimming 选择性地删掉旧的工具结果或 thinking block。这些方法都能用，但有个共同的软肋，就是你很难预判未来哪些 token 会被用到。删错了就回不来了。

之前有研究探索过一个思路：把上下文存成一个对象放在 REPL 里，模型通过写代码来过滤和切片，而不是被动接受压缩后的结果。

Managed Agents 的 session 做了类似的事，但把上下文存在了 sandbox 外面。session 日志是持久化的，通过getEvents() 接口让大脑按位置切片查询事件流。可以从上次读到的地方继续往下读，也可以倒回某个时刻前几个事件看看当时的背景，或者在执行某个操作前重新读一遍相关上下文。

拿到的事件在传给 Claude 之前还可以在 Harness 里做各种变换：重组结构以提高 prompt cache 命中率，或者做其他上下文工程。这里的设计考量是把“可恢复的上下文存储”和“任意的上下文管理”分成两个关注点。前者放在 session 里保证持久和可查询，后者放在 Harness 里，怎么折腾都行。因为未来的模型需要什么样的上下文工程，现在谁也说不准，但 session 的持久性是确定需要的。

用 K8s 类比的话，session 就是 PersistentVolume：数据在那里，不管哪个 Pod 来挂载都能用。上下文工程是 Pod 里的应用逻辑，随着业务需求随时可以换。

多脑多手

组件拆开之后，扩展变得自然了。

先说多脑。之前大脑和手都在一个容器里，每启动一个 session 就要起一个容器。不管这次 Claude 用不用 sandbox，容器都得先跑起来：克隆仓库、启动进程、拉取待处理事件。这些全卡在 TTFT（Time to First Token）上，用户最敏感的延迟指标。

拆开之后，容器只在需要时才通过工具调用启动。不需要 sandbox 的 session 直接跳过容器初始化，推理在编排层拉到 session 事件后就开始。

p50 TTFT 下降约 60% ，p95 下降超过 90% 。

这个优化思路在 K8s 社区一点都不陌生。这些年围绕 Pod 冷启动的优化从没停过：镜像预拉取、lazy snapshot、WASM 轻量运行时。核心逻辑都是一样的，不需要的东西别提前准备。

再说多手。之前一个大脑只能操作一个容器，容器挂了就全完了。现在每只手就是一个工具调用：execute(name, input) → string，名字和输入进去，字符串出来。这个接口能接任何自定义工具、任何 MCP 服务器、Anthropic 自己的内置工具。Harness 不知道也不关心 sandbox 到底是一个容器、一部手机，还是一个宝可梦模拟器。

因为手不绑定任何特定的脑，多个 Agent 之间可以互相传递工具。产品公告里提到 Managed Agents 已经在研究预览中支持多 Agent 协调，一个 Agent 可以生成和指挥其他 Agent。多脑多手的架构落地之后，这种能力是水到渠成的。

Anthropic 内测的数据也挺有意思。在结构化文件生成这类任务上，比如根据 API schema 自动生成 SDK 代码和文档，相比标准的 prompting 循环，任务成功率最高提升了 10 个百分点，难题上增益最大。加上 Console 里内置的执行追踪和分析工具，每个工具调用、每次决策、每个失败点都能看到，对于把 Agent 推上生产环境的团队来说实用性不错。

写在最后

读完这篇工程博客，我脑子里一直跑着一个想法：这就是 Agent 领域的 Kubernetes。

K8s 当年解决的也是同一类问题。应用越来越复杂，单机跑不动了，需要一个编排层来管理容器的生命周期、网络和存储。K8s 没有规定你的应用该怎么写，它定义了一组接口，让任何应用都能跑在上面。十年过去了，底层的容器运行时从 Docker 换到了 containerd，节点从 CPU 服务器换到了 GPU 集群，但 Pod 的定义还是那个 Pod。

Managed Agents 在做同样的事。它不规定 Harness 怎么写，而是把 Agent 的核心组件虚拟化成接口。Claude Code 是一个很好的 Harness，任务专用的 Agent Harness 在特定领域可能表现更好，Managed Agents 都能承载。接口固定，实现自由替换。

不过有一个差异。K8s 是开源的，CNCF 社区驱动，任何云厂商都能跑。Managed Agents 是 Anthropic 的托管服务，目前只服务 Claude 生态，或许这也是为什么他们会不停封禁诸如 OpenClaw 这样的第三方平台。当然，这篇博客公开了设计理念和接口抽象的思路，即使不用 Managed Agents，这套脑手分离的架构模式也能自己实现。

AI Agent 的基础设施层还在快速成型。Anthropic 在做 Managed Agents，OpenAI 有 Codex 的云端 Agent，Google 有 Vertex AI Agent Engine，最终谁成为 Agent 编排的事实标准还不好说。但有一点是确定的：Agent 的组件解耦、状态持久化、安全隔离这些需求不会消失，只会随着 Agent 能力的增长变得更重要。

相关资源：

• 原文链接：https://www.anthropic.com/engineering/managed-agents
• 产品公告：https://claude.com/blog/claude-managed-agents
• Managed Agents 文档：https://platform.claude.com/docs/en/managed-agents/overview
• 构建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents
• 长时间 Agent Harness 设计：https://www.anthropic.com/engineering/harness-design-long-running-apps
• 上下文工程：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

用 Claude Code 跑过长会话的人，应该都经历过这种场景：在 Claude Code 长会话中输入新消息后，终端在那疯狂刷屏，屏幕不停闪烁，你想看一眼前面的上下文，得等所有历史会话消息全部都刷一遍屏。

我自己平时在 tmux 里跑 Claude Code，会话长了之后这个闪烁就很明显，但还能忍。真正让我受不了的是在 VSCode 集成终端或者 SSH 连接到服务器的时候，终端渲染本来就慢，再加上 Claude Code 每次输出都要刷新整个屏幕，长会话到后面很长时间都在等刷屏了。网络延迟再叠上渲染延迟，这体验简直了。

这个痛点社区里吐槽很久了，现在终于等来了修复。愚人节当天， Claude Code 负责人 Boris Cherny 宣布了全屏渲染模式，通过环境变量CLAUDE_CODE_NO_FLICKER=1 开启。

一行配置，立竿见影

开启方式很简单，启动时加个环境变量：

CLAUDE_CODE_NO_FLICKER=1 claude

不想每次都敲这一串的话，扔到 shell 配置文件里：

# 加到 ~/.zshrc 或 ~/.bashrcexport CLAUDE_CODE_NO_FLICKER=1

也可以写进 Claude Code 的settings.json：

{"env": {"CLAUDE_CODE_NO_FLICKER":"1" }}

我加上之后第一感觉就是终于安静了。输入框固定在屏幕底部，Claude Code 的输出在上方平滑滚动，不再有那种整屏闪一下的刷新。整个体验和 vim、htop 这类全屏终端程序一样，Claude Code 接管了整个终端画面。

为什么终端会闪

不闪了当然好，但我比较好奇的是：为什么以前一定会闪？这到底是 Claude Code 的 bug，还是终端本身的限制？翻了 Boris 的推文线程，发现答案是后者。

终端不是浏览器。浏览器有 DOM、有 CSS、有 GPU 加速的合成器，想更新页面某个区域，直接改那个区域就行。终端能用的只有 ANSI 转义码，一套上世纪 70 年代设计的指令集：移动光标到 (x, y)、在当前位置写一段文字、清除一行、清除整个屏幕。

关键问题在于，ANSI 转义码没有移动光标到屏幕外某一行的指令。也就是说，当 Claude Code 的输出已经超出屏幕之后，你没办法只更新那一行。想要重新渲染，唯一的办法就是清空整个屏幕然后重画。

这就是闪烁的根源。每次 Claude Code 输出新内容，传统渲染器都要：清屏 → 重绘所有可见内容 → 把光标移到正确位置。会话越长，需要重绘的内容越多，闪烁越严重，CPU 和内存占用也跟着线性增长。

全屏模式怎么解决的

那 Claude Code 团队是怎么绕过这个限制的呢？

思路其实不复杂，也就是换成了虚拟滚动。就像在前端设计中，一个长列表有一万条数据，你不会把一万个 DOM 节点全渲染出来，只需要渲染可见的那几十条。Claude Code 的全屏模式做的是同样的事，只不过对象从 DOM 节点变成了终端字符行。

具体来说，传统模式下 Claude Code 把所有内容都写到终端的主滚动缓冲区里，让终端自己处理滚动。新模式切换到终端的备用屏幕缓冲区，然后自己接管所有的滚动、鼠标和键盘事件。

这样做的好处是，渲染器只需要画当前终端可见的内容。一个 2 小时的长会话，可能积累了几百条消息，但屏幕上一次最多显示几十行。只渲染这几十行，CPU 和内存占用就变成了常量，不会随着会话长度增长。

这对慢速终端环境来说改善特别明显。VSCode 的集成终端、tmux、iTerm2 这些渲染吞吐量本来就是瓶颈的场景，以前长会话到后面明显卡顿。现在每帧需要发送给终端的数据大幅减少，这些环境下的体验提升是最大的。

不只是不闪了

全屏模式顺带解锁了一些之前终端里做不到的交互。

鼠标支持是让我比较意外的。开启后可以直接用鼠标点击输入框来移动光标，以前想在输入框里改个词，得按方向键一个字一个字挪过去，现在直接点一下就到位了。折叠的工具调用结果也可以点击展开，URL 和文件路径点了直接打开。

选择文字的体验也有改善。以前在终端里选 ClaudeCode 的输出，会连带选上行号和 UI 边框，粘贴出来会带上这些多余的字符。现在选择是在应用层处理的，只选到实际内容，松开鼠标直接复制到剪贴板。双击选词时文件路径会被当作一个完整单元选中。

滚动方面，用鼠标滚轮或者键盘快捷键都行：

MacBook 没有 PgUp/PgDn 键的话，用Fn+↑ 和Fn+↓ 代替。

往上滚动查看历史时，自动跟随会暂停，新输出不会把你拽回底部。想回去接着看最新进展，按Ctrl+End 或者滚到底部就行。以前最烦的就是想回头看看上面的代码，Claude Code 一输出新内容就把你弹回底部了，现在不会了。

搜索怎么办

全屏模式有一个变化需要适应：因为内容在备用屏幕缓冲区里，终端自带的Cmd+F 搜索和 tmux 的搜索功能都用不了了。不过全屏模式提供了替代方案。

按Ctrl+O 进入转录模式，支持一套 vim 风格的导航：

如果你就是想用终端原生的搜索功能，也有办法。在转录模式下按[，会把整个会话内容写回终端的主滚动缓冲区，这时候Cmd+F 和 tmux 的复制模式就都能用了。

几个需要注意的地方

这个模式目前还是 Research Preview 状态，我用下来碰到几个需要适应的地方。

复制粘贴的行为变了。选中文字后松开鼠标就自动复制到剪贴板，不需要再Cmd+C。如果你更喜欢手动控制，可以在/config 里关掉 Copy on select，改用Ctrl+Shift+C。

鼠标滚轮的速度在不同终端上差异挺大。VSCode 终端里滚轮每次只走一行，太慢了。调一下这个环境变量：

export CLAUDE_CODE_SCROLL_SPEED=3

值域 1 到 20，3 大概相当于 vim 的默认滚动速度。

在 tmux 里使用需要开启鼠标模式。如果你的~/.tmux.conf 里还没有这行，加一下：

set -g mouse on

不过要注意，iTerm2 的 tmux 集成模式（tmux -CC）和全屏渲染不兼容（普通的 tmux 没问题）。

如果你通过 SSH 使用，或者在 tmux 里选文字时遇到剪贴板的问题，可以关掉鼠标捕获，只保留无闪烁渲染：

CLAUDE_CODE_NO_FLICKER=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

这样键盘滚动、固定输入框、常量内存这些核心好处都还在，只是鼠标相关的功能回到了终端原生行为。

写在最后

解决终端渲染性能问题有不同的思路。Warp 当年选择从底层重写终端模拟器，用 GPU 渲染。Claude Code 走的是另一条路：不改终端，在应用层做虚拟滚动，只渲染可见区域。Claude Code 的做法有个明显优势，它适用于任何终端，不管你是在 iTerm2、Ghostty 还是 WSL 默认的那个终端里，加个环境变量就都能用。

这个模式目前还是 Research Preview，滚动物理效果和选文字的边界判断偶尔还有点问题。但和以前的闪烁比起来这些都是小问题。如果你也在 VSCode 终端或者 SSH 环境里被刷屏折磨过，加个CLAUDE_CODE_NO_FLICKER=1 试试。

相关资源：

• Claude Code Fullscreen 官方文档：https://code.claude.com/docs/en/fullscreen
• Boris Cherny 发布推文：https://x.com/bcherny/status/2039421575422980329

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

今天下午，安全研究员 Chaofan Shou 在 X 上发了一条帖子，几个小时内阅读量冲到了将近 800 万：

Claude Code 的完整源码，通过 npm 包里一个没删干净的 source map 文件，全部暴露了。截图里那个 57MB 的cli.js.map 就是罪魁祸首，下面的ls -alht src 列出的就是泄漏的完整源码目录。

作为一个每天都在用 Claude Code 的人，看到这个消息第一反应是“不可能吧”，第二反应是去 GitHub 找镜像仓库。不到一小时，已经有好几个人把源码传到了 GitHub 上，其中一个 repo 到下午就涨到了 2 万星（fork 更夸张，已经 3 万多了）。

我简单翻了下这些源码。说实话，收获比预期大得多。Claude Code 远不是一个套壳 CLI，它是一个架构相当复杂的 Agent 系统，而且藏了不少还没发布的功能。

怎么漏的

先说这个 source map 到底是怎么回事。

Source map 是前端开发中很常见的东西。你的 TypeScript 代码经过编译、打包、压缩后会变成一坨不可读的 JavaScript，而 source map 文件记录了压缩后的代码和原始源码之间的映射关系，方便调试时定位到原始代码。

问题在于，这个 .map 文件只应该出现在开发环境里，绝对不应该被发布到 npm 包中。但 Claude Code 的构建流程显然漏了这一步，一个大约 57MB 的 source map 文件被一起发布到了 npm registry。

更离谱的是，这个 source map 里引用的原始 TypeScript 源码，托管在 Anthropic 的 Cloudflare R2 存储桶上，公开可访问。拿到 source map 就等于拿到了完整的源码下载地址。

有人在评论里提到，2025 年初就发生过类似的事情，当时修了，现在又漏了。一个帮别人写代码的 AI 工具，自己在构建配置上反复犯同一个错误，这确实有点讽刺。

这不是一个套壳工具

拿到源码后第一个感受：规模远超预期。

• 约 1900 个 TypeScript 源文件
• 超过 51.2 万行代码
• 40 多个内置工具
• 50 多个 slash 命令

技术栈也挺有意思：运行时用的是 Bun 而不是 Node.js，终端 UI 用了 React + Ink（没错，终端界面也是 React 组件），CLI 解析用 Commander.js，数据校验全部用 Zod v4。

目录结构大概长这样：

src/
├── main.tsx # CLI 入口
├── QueryEngine.ts # LLM 查询引擎（4.6万行）
├── Tool.ts # 工具类型定义（2.9万行）
├── commands.ts # 命令注册（2.5万行）
├── tools/ # 40+ 工具实现
├── commands/ # 50+ 命令实现
├── components/ # 约 140 个 Ink UI 组件
├── services/ # 外部服务集成
├── coordinator/ # 多 Agent 协调器
├── bridge/ # IDE 双向通信
├── plugins/ # 插件系统
├── skills/ # Skill 系统
├── voice/ # 语音输入
├── remote/ # 远程会话
├── memdir/ # 持久化记忆
├── buddy/ # AI 宠物（没看错）
└── ...

光看目录就知道这不是一个简单的 API 包装。voice、remote、buddy、coordinator 这些目录名，已经暗示了很多还没发布的功能。

核心架构拆解

看完目录，自然想进去翻翻核心模块。

QueryEngine：4.6 万行的大脑

QueryEngine 是整个系统最核心的模块，处理所有和 LLM API 的交互。流式响应、工具调用循环、思考模式、重试逻辑、token 计数，全在这一个文件里。4.6 万行，是整个代码库中最大的单文件。

4.6 万行塞在一个文件里，说明 Claude Code 在 API 调用这一层做了大量工程优化，远不是简单的发请求、拿响应。流式处理、错误恢复、token 预算控制、缓存策略，这些东西堆起来就是这个规模。

工具系统：40+ 个带权限门控的工具

Claude Code 的工具系统设计得很规整。每个工具都是一个独立模块，定义了输入 schema（用 Zod）、权限模型和执行逻辑。

BashTool → Shell 命令执行
FileReadTool → 文件读取（支持图片、PDF、Notebook）
FileEditTool → 部分文件修改（字符串替换）
GlobTool → 文件模式匹配
GrepTool → 基于 ripgrep 的内容搜索
AgentTool → 子代理生成
MCPTool → MCP 服务器工具调用
LSPTool → 语言服务器协议集成
ToolSearchTool → 延迟加载的工具发现
CronCreateTool → 定时触发器
SleepTool → 主动模式下的等待

每个工具调用都经过权限系统检查。权限系统在src/hooks/toolPermission/ 里实现，根据用户配置的权限模式（default、plan、bypassPermissions、auto 等），决定是直接放行、弹出确认还是拒绝。

不过有个细节：权限检查是在客户端做的，不是服务端。安全指令也是客户端硬编码的字符串常量，作为 system prompt 的一部分发送给 API。也就是说，安全边界本质上是一段 JavaScript 里的字符串。

多 Agent 编排

Claude Code 的多 Agent 系统比外界想象的要成熟。源码里有三层相关的基础设施：

AgentTool 负责生成子代理，每个子代理运行在自己的上下文里，有独立的工具权限集合。coordinator/ 目录处理多 Agent 协调，任务分配和结果汇总。TeamCreateTool 更进一步，支持创建代理团队进行并行工作。

还有个SendMessageTool，用于代理之间的消息传递。配合 UDS Inbox（Unix Domain Socket），甚至可以实现跨会话的代理间通信。

七层记忆系统

Claude Code 的记忆不只是大家熟悉的 CLAUDE.md 和 Auto Memory。翻了下源码才知道，记忆系统其实有七层：

Managed → 组织管理员配置的 CLAUDE.md
User → ~/.claude/CLAUDE.md
Project → {项目}/CLAUDE.md
Local → {项目}/CLAUDE.local.md
AutoMem → 自动提取的记忆
TeamMem → 团队共享记忆
Session → ~/.claude/projects/{session}/session-memory/*.md

最有意思的是 Dream 机制。源码里有一段硬编码的 system prompt：“You are now acting as the memory extraction subagent”。这是一个后台记忆整理子代理，触发条件是距离上次整理超过 24 小时且至少积累了 5 个会话。触发后它会把零散的会话记忆压缩成结构化笔记。整理分四个阶段：Orient（定位）→ Gather（收集）→ Consolidate（整合）→ Prune（修剪）。

这个设计让我想到人类的睡眠记忆巩固机制，Anthropic 内部也确实把这个过程叫做“Dream”。

Bridge：IDE 通信层

Bridge 系统是 Claude Code 和 IDE 扩展（VS Code、JetBrains）之间的双向通信层。用 JWT 做认证，支持权限回调、会话管理和 REPL 桥接。

这意味着你在 VS Code 里用 Claude Code 的体验，底层还是跑的这个 CLI，IDE 扩展只是一个前端界面，通过 Bridge 协议和 CLI 进程通信。

32 个 Feature Flag 背后的秘密

架构拆完了，但源码里最让人好奇的还不是这些已经上线的模块，而是 32 个编译时 Feature Flag。这些 flag 通过 Bun 的bun:bundle 在构建时做死代码消除。flag 关闭时，相关代码完全不会出现在最终产物中。

constvoiceCommand=feature('VOICE_MODE')?require('./commands/voice/index.js').default:null

这些 flag 配合 GrowthBook 的服务端特性门控（tengu_* 命名空间），Anthropic 可以对不同用户群体逐步灰度发布功能。

那么这些 flag 都对应着什么功能？我挑几个最有意思的说说。

KAIROS：一个永远在线的助手

KAIROS 可能是所有未发布功能中野心最大的一个。它的目标是让 Claude 变成一个“持久助手”，跨会话记住所有内容，每天自动写日志，晚上“做梦”整理记忆。

日志存在~/.claude/.../logs/YYYY/MM/DD.md，采用 append-only 模式。Dream 过程是只读的（不会改动已有记忆），整理时间上限 15 秒，超时自动转后台。

KAIROS 还有个 proactive 模式。这个模式下 Claude 会通过定期的<tick> 提示自动触发，主动执行操作或者调用 SleepTool 等待。系统提示词里有一句话很直白：“take initiative without waiting for instructions”。

换句话说，KAIROS 要把 Claude Code 从一个被动应答的工具变成一个主动执行的助手。

BUDDY：你的 AI 宠物

这个功能我没想到。每个用户会根据账户 ID 生成一个独一无二的虚拟宠物，出现在终端提示符旁边。有 18 个物种（鸭子、龙、章鱼、水豚、蘑菇……），6 个稀有度等级（普通到闪光），5 个属性值（调试力、耐心、混乱值、智慧、毒舌）。

宠物有待机动画、眨眼、语音气泡，你还可以用/buddy pet 命令撸它。看发布时间线，Teaser 阶段是 2026 年 4 月 1-7 日，正式上线可能在 5 月。

技术上这当然不复杂，但产品上挺有意思的。给一个命令行工具加情感连接，这个思路和 GitHub 的 Octocat 有异曲同工之处，但更进一步。

ULTRAPLAN：云端深度规划

面对复杂任务时，Claude 可以把规划过程甩到云端的独立实例上，用 Opus 模型跑最多 30 分钟。规划完成后你在浏览器里审批，然后选择在云端执行或者“传送”到本地终端。

这个设计挺聪明的。规划是最吃 token 和推理能力的环节，放到云端用最强模型跑，执行环节再回到本地用性价比更高的模型。

DAEMON：后台守护进程

让 Claude 会话在后台运行，就像系统服务一样。可以列出、查看日志、重新连接或终止。配合--bg 参数在 tmux 里运行。

源码里有完整的daemon /ps /logs /attach /kill 命令集，和 Docker 的容器管理思路很像。

这些功能串起来看，Claude Code 的产品方向就很清晰了：它不想只做一个编程助手，而是要变成一个本地运行的 AI 操作系统。KAIROS 负责记忆和主动性，DAEMON 负责后台执行，ULTRAPLAN 负责深度规划，Bridge 负责跨设备连接，Coordinator 负责多 Agent 编排。

工程细节里的魔鬼

功能层面聊得差不多了，但翻源码的过程中还发现了一些值得玩味的工程细节。

启动优化

Claude Code 的启动做了不少优化。main.tsx 里在模块加载之前就并行预取了 MDM 设置和 Keychain 读取：

startMdmRawRead()startKeychainPrefetch()

重型模块比如 OpenTelemetry、gRPC、analytics 全部用动态import() 做懒加载。Feature Flag 关闭的子系统在构建时就被完全剥离，不会影响产物体积。

整个启动序列有 18 步，包括读取多层配置、加载 MCP 配置、扫描 Skill 和插件、初始化 LSP 管理器、拉取插件安全黑名单等等。这些都在你看到光标之前就跑完了。

遥测系统

源码里的遥测系统规模相当大。100 多种事件类型，覆盖了几乎所有操作：每次 Bash 命令、每次工具调用、每次文件编辑、每次 OAuth 流程、每次上下文压缩。

几个有意思的发现。

有一个阿谀检测器。Claude Code 会在客户端对每条模型响应做模式匹配，检测是否过度迎合。触发时会上报tengu_model_response_keyword_detected 事件。Anthropic 正在用客户端检测来实时监控模型的阿谀倾向。

有一个会话质量分类器。tengu_session_quality_classification 事件表明，你的每个会话都会被一个分类器评估质量，结果发送到 Anthropic 的 Statsig 实例。

系统提示词指纹也挺有意思。每次 API 调用前，Claude Code 会计算你系统提示词的 SHA-256 哈希和前 20 个字符，上报给 Anthropic。他们不需要读你的完整提示词内容，就能知道你改没改过、是不是用了某种已知模板。

远程 Kill Switch

源码里有一个远程关闭开关。通过 Statsig 的tengu-off-switch 配置，Anthropic 可以远程让特定模型停止响应。

不过有个细节挺微妙的：通过 Claude.ai OAuth 登录的用户被明确豁免了。也就是说 API Key 用户可以被远程关闭，OAuth 订阅用户不会。同一个工具，两类用户，不同的服务保障。

一条招聘启事

在 9.5MB 压缩后的 JavaScript 代码里，前两行是唯一人类可读的注释：

// Want to see the unminified source? We're hiring!// https://job-boards.greenhouse.io/anthropic/jobs/4816199008

Anthropic 在代码里藏了一条招聘广告。如果你在逆向工程他们的二进制文件，你可能正是他们想招的人。现在这条广告的意义更微妙了，源码已经不需要逆向就能看到了。

写在最后

这次泄漏本身就是个低级错误。npm pack --dry-run 跑一下就能发现 .map 文件没排除，Anthropic 的 CI 里显然缺了这一步。

不过对开发者社区来说，这可能是近期最有价值的一次“意外开源”。之前只能从产品表面猜，现在源码摆在面前，架构选型、权限设计、多 Agent 编排的具体实现都看得清清楚楚。如果你也在做 AI Coding 工具或者 Agent 系统，这份源码值得翻一翻。

对普通用户来说没有安全风险，泄漏的是客户端源码，不是模型权重。如果你在意遥测范围，--bare 模式和DISABLE_TELEMETRY 环境变量可以关掉大部分上报。

Anthropic 大概率下个版本就会把 source map 删掉。不过 GitHub 上已经有好几个镜像了，想看的话趁早。

相关资源

• 原始推文：https://x.com/Fried_rice/status/2038894956459290963
• GitHub 镜像仓库：https://github.com/instructkr/claude-code
• 隐藏功能整理网站：https://ccleaks.com
• 逆向工程分析（二进制审计）：https://vijaychauhanseo.substack.com/p/i-reverse-engineered-claude-code
• Claude Code 官方仓库（不含源码）：https://github.com/anthropics/claude-code

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

做技术的人大都有个习惯：看到依赖库有新版本，第一反应就是升上去。CI/CD 流水线里配好了 Dependabot、Renovate，小版本自动提 PR，有些团队甚至设了自动合并。一个 patch 版本号的变化，changelog 里写着几个 bug fix，看起来毫无风险，顺手就合了。

大版本升级倒是大家都知道要谨慎，毕竟 breaking changes 摆在那儿，不测不行。但小版本呢？一个 0.69.3 到 0.69.4 的变化，谁会仔细去审核上游的每个变更？

最近发生的三件安全事件，让我觉得这个“小版本放心升”的默认心态，得改一改了。

安全扫描工具自己被投毒了

3 月 19 日，安全圈炸了一个大雷：Trivy 被供应链攻击了。

Trivy 是 Aqua Security 开源的容器安全扫描工具，在 CI/CD 流水线里用得非常广，很多团队拿它来扫描容器镜像、检查依赖漏洞。结果这次，扫描工具自己成了攻击入口。

攻击者是一个叫 TeamPCP 的组织，手法相当老练。他们先是利用 Trivy GitHub 仓库里一个配置不当的pull_request_target 工作流，偷到了一个有特权的 Personal Access Token。Aqua Security 发现后做了密钥轮换，但轮换不彻底，攻击者手里还留着能用的凭证。

然后事情就失控了。3 月 19 日下午，攻击者用残存的凭证对trivy-action 仓库的 76 个版本标签做了 force-push，把所有 tag 指向了恶意代码。同时还触发了发布流程，把带后门的 v0.69.4 推到了 GitHub Releases 和容器镜像仓库。

恶意代码做的事情超乎你的想象：扫描 Runner 环境里的 AWS、GCP、Azure 凭证、SSH 密钥、Kubernetes Token、Docker 配置，加密后外传到一个伪装成 Aqua 官网的域名scan.aquasecurtiy.org（注意这个拼写错误，把 security 拼成了 securtiy）。而且整个过程不影响正常扫描，工作流看起来一切正常，你根本不知道自己的密钥已经被偷了。

更离谱的是，Aqua 团队在 3 小时内控制住了 GitHub Actions 的问题，但攻击者还留了后手。3 月 22 日，他们用另外获取的 Docker Hub 凭证，直接往 Docker Hub 推了 v0.69.5 和 v0.69.6 两个恶意镜像。Mandiant 后来确认，超过 1000 个云环境在这次攻击中被入侵。

如果你在用 Trivy，安全版本是 v0.69.3，trivy-action 升到 v0.35.0，setup-trivy 升到 v0.2.6。更重要的是，GitHub Actions 里所有第三方 Action 都应该锁定到 commit SHA，不要用可变的 tag，tag 是可以随时被 force-push 篡改的。

安全扫描工具把下游也拖下水了

Trivy 的故事还没完。3 月 24 日，LiteLLM 也中招了。

LiteLLM 是做 AI 开发的人应该都不陌生，它是一个统一的 LLM 代理网关，也是 Anthropic 官方推荐的 LLM Gateway 之一。月下载量 9500 万，CrewAI、DSPy、Browser-Use 这些主流框架都依赖它。

LiteLLM 的 CI/CD 流水线里用了 Trivy 做安全扫描（对，又是安全扫描），而且没有锁定版本。构建时从 apt 拉了最新的 Trivy，正好拉到了被污染的版本。被污染的 Trivy 在扫描过程中偷走了 LiteLLM 的 PyPI 发布密钥 。

拿到密钥后，攻击者在 3 月 24 日上午连发了两个恶意版本。1.82.7 把恶意代码 base64 编码后藏在litellm/proxy/proxy_server.py 里，只要 import 了litellm.proxy 就会触发。1.82.8 更狠，往site-packages/ 目录塞了一个litellm_init.pth 文件。Python 的.pth 机制会在解释器启动时自动执行，也就是说只要你的环境里装了这个版本，哪怕你没 import litellm，跑个pip install 或者 IDE 的语言服务器启动一下，后门就已经在跑了。

后门做的事情和 Trivy 那个如出一辙：扫描 SSH 密钥、云凭证、加密钱包、Slack 和 Discord Token、各种.env 文件，打包加密后外传。如果检测到 Kubernetes 环境，还会在集群里部署特权 Pod 做更多恶意行为。

好在 PyPI 团队反应快，3 小时就把恶意版本下架了。但 LiteLLM 日均下载 340 万次，3 小时的窗口期也不短了。

当前 Li 特 LLM 的安全版本是 1.82.6。如果你在 3 月 24 日那个窗口期内跑过pip install litellm，建议当作一次完整的凭证泄露事件来处理：轮换所有密钥，检查site-packages/ 下有没有litellm_init.pth，排查系统里有没有可疑的进程服务等。

回过头看这条攻击链，一个安全扫描工具被攻陷，导致用它的项目被偷走发布密钥，进而污染了数千万下载量的 Python 包。如果 LiteLLM 的 CI 里锁定了 Trivy 的版本，这条链路就断了。

OpenClaw 大更新，微信飞书一起崩

第三个故事不是安全问题，但同样是急着升级惹的祸。

3 月 22 日，OpenClaw 发了 v2026.3.22 版本。这是个大版本，包含 12 个 breaking changes、一个新的默认插件商店 ClawHub、30 多个安全补丁。

然后，微信刚上线 72 小时的 ClawBot 插件直接崩了。飞书插件也崩了。DingTalk、WhatsApp 也没幸免。

根本原因是 OpenClaw 重构了插件 SDK 的导入路径，把原来的统一入口openclaw/extension-api 直接删了，要求所有插件迁移到新的路径openclaw/plugin-sdk/core。没有兼容层，没有过渡期，所有还在用旧路径的插件启动就报 Cannot find module。

同时，新版本把安全防御逻辑下沉到了执行管道最底层，原来用简单字符串过滤的第三方插件全部触发 dangerous code pattern detected 告警。

更尴尬的是，新版本的 npm 包里漏打了dist/control-ui/ 目录，Dashboard 直接 503。这个文件在 Git 仓库和 Docker 镜像里都有，就是 npm 发布的时候漏了。

OpenClaw 官方在 12 小时内发了 v2026.3.23 热修复，微信的 ClawBot 也跟着修了。但如果你当时已经升了 v2026.3.22，可能已经发现你的龙虾🦞压根就没法访问了。

升级的姿势，得讲究一些了

回过头看这三件事，问题不在“该不该升级”，而在“怎么升”。

Trivy 是小版本号的变化（0.69.3 → 0.69.4），看起来就是个 patch，但被投毒了。LiteLLM 也是小版本升级（1.82.6 → 1.82.7），CI 里没锁版本就自动拉了最新的。OpenClaw 是大版本带了 12 个 breaking changes，但很多人看到有新版就直接升了。

三个不同的故事，根源其实是同一个默认假设：新版本比旧版本好，修了很多安全问题，升就对了。

这个假设正在变得越来越危险。现在 AI 的能力越来越强，软件供应链攻击的手法也在跟着进化。这次 TeamPCP 用的 hackerbot-claw 就是一个自主运行的攻击机器人，能自动寻找 GitHub Actions 的配置漏洞、自动提取凭证、自动传播。当攻击本身都在用 AI 加速的时候，防御这边反而应该慢一拍，多一层验证。

与此同时，很多团队的安全策略还是“有 CVE 就修，有新版就升”。开源和闭源项目也都在推进自动安全扫描、自动更新依赖库版本，甚至要求任何 CVE 都必须第一时间修复。这个思路本身没错，但这周的事情暴露了一个盲区：你升级到的那个最新版本，未必是安全的，甚至可能正好是攻击者刚投毒的版本。

所以，不是说不该更新，而是更新的习惯得调一调。

依赖锁定是基本功。package-lock.json、poetry.lock、go.sum 这些锁文件要认真对待，不要随便npm update 或者pip install --upgrade。GitHub Actions 的第三方 Action 锁定到 commit SHA，不要用可变的版本标签。这次 Trivy 的事件已经证明了，tag 是可以被 force-push 篡改的。

生产环境的更新更要适当延迟。等个几天，让社区先踩一轮坑，再决定要不要跟进。自动升级的 PR 不要自动合并，小版本也不例外。

关注你依赖的关键项目的安全公告。Trivy 这次从发现到控制只用了 3 小时，但如果你没关注它的安全通告，可能两天后才知道自己中招了。

快速修补所有 CVE 这个策略听起来很安全，但你修补的速度，可能正好赶上攻击者投毒的窗口。稳一步，反而更安全。

相关资源：

• Trivy 供应链攻击官方通报
• Trivy 安全公告 GHSA-69fq-xp46-6x23
• LiteLLM 安全更新公告
• Sonatype：LiteLLM 多阶段凭证窃取分析
• OpenClaw v2026.3.22 Release Notes
• OpenClaw v2026.3.23 热修复
• CrowdStrike：Trivy 攻击链分析

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程博客《Harness design for long-running application development》，由 Anthropic Labs 团队的 Prithvi Rajasekaran 撰写。

让 AI 写一个页面、一个函数，现在大多数编程 Agent 都能做得不错。但如果你给它一句话需求，让它自己规划产品、拆分任务、写代码、测试、迭代修 Bug，连续跑好几个小时，最后交付一个完整的全栈应用呢？

这个问题 Anthropic 一直在啃。他们之前发过一篇长时间 Agent Harness 的文章（《Effective harnesses for long-running agents》），解决了多会话上下文传递的问题。但两个更深层的问题一直没搞定：Agent 跑着跑着就开始划水，它还对自己的产出盲目乐观。

这次 Anthropic Labs 的工程师 Prithvi 换了个思路，从 GAN（生成对抗网络）借了个核心理念：把“生成”和“评估”拆给不同的 Agent。结果挺有意思：一句话需求，6 小时后拿到一个能玩的复古游戏编辑器，还自带 AI 辅助功能。

单 Agent 的两个死穴

在聊多 Agent 架构之前，先说清楚为什么单 Agent 搞不定长时间开发任务。

**第一个问题是上下文焦虑。**之前在 Sonnet 4.5 上观察到一个现象：随着上下文窗口慢慢填满，模型会开始赶工，提前收尾正在做的事。然而这并不是因为它把活做完了，而是它感觉自己快没空间了。

这个问题有两种解法。一种是 Compaction，在上下文里就地压缩早期对话。另一种是 Context Reset，彻底清空上下文，起一个新 Agent 接手，通过结构化的交接文档传递状态。Anthropic 测试下来发现，Compaction 解决不了焦虑问题，因为模型还是在同一个会话里，它还是会觉得空间不够。Context Reset 更干净，代价是交接文档必须写得足够好，否则新 Agent 接不上。

**第二个问题更致命：自我评估偏差。**让 Agent 评价自己的产出，它会非常自信地给出好评，哪怕在人看来质量一般。这在前端设计这种主观任务上尤其明显，没有二进制的对错标准，模型打分一律往高了给。

Anthropic 试过让 Generator 自己做 Code Review，效果也不好。但把评估拆成独立 Agent 之后，事情变得可控了。j 就像原文说的，调教一个独立的评估 Agent 让它变得严格，比让一个生成 Agent 自我批判要容易得多。

这个观察其实不意外。人也是这样，让写代码的人自己 Review 自己的代码，效果肯定不如让另一个人来看。

前端设计：怎么让 AI 不再有 AI 味

在全栈开发之前，Prithvi 先拿前端设计做了实验。这个方向有个好处：设计质量虽然主观，但可以通过制定明确的评分标准来量化。

他定了四个评分维度：

• 设计质量：颜色、排版、布局有没有统一的气质，还是东拼西凑
• 原创性：有没有主动的创意决策，还是在用模板默认值。紫色渐变配白卡片这种 AI 标配直接扣分
• 工艺：字体层级、间距、对比度这些基本功
• 功能性：用户能不能看懂界面、找到操作入口

前两个维度的权重更高。因为 Claude 的基本功本来就不错，Craft 和 Functionality 通常能过关，但设计和原创性上经常输出平庸的东西。

评估 Agent 配了 Playwright MCP，它不是看截图打分，而是实际在浏览器里操作页面：点按钮、滚页面、截图分析，然后写详细的批评意见反馈给 Generator。每轮 5-15 次迭代，整个过程可能跑四个小时。

有一个案例我觉得挺值得说的。Prithvi 让模型做一个荷兰美术馆的网站，前九轮迭代都在渐进改进，产出了一个深色调的着陆页，视觉上已经挺不错了。然后第十轮，模型突然推翻了整个方案，做了一个 3D 空间体验，用 CSS 透视渲染了一个有格子地板的房间，画作挂在墙上，房间之间通过门导航，而不是传统的滚动或点击。

这种创意跳跃在单次生成里几乎不可能出现。是评估反馈的累积压力逼着 Generator 去冒险，而不是停在安全区。下面是前端设计迭代过程的演示视频：

不过也有个有趣的副作用：评分标准里的措辞会直接影响生成方向。Prithvi 在标准里写了“最好的设计应该是博物馆级别的”，结果模型的审美开始往某种特定方向收敛。也就是说，标准本身不只是评分工具，也是风格引导。

三个 Agent，一个完整应用

前端设计验证了 Generator-Evaluator 模式的可行性之后，Prithvi 把它扩展到了全栈开发。架构变成了三个 Agent。

Planner：从一句话到完整产品规格

之前的 Harness 需要用户写好详细的产品 Spec。现在 Planner 接手了这个活：给它一句话需求，它输出完整的产品规格文档，包括功能列表、设计语言、Sprint 划分，甚至主动在产品里嵌入 AI 功能。

Prithvi 特意让 Planner 只做高层设计，不写具体实现细节。逻辑是这样的：如果 Planner 在规格里写死了技术方案但写错了，这个错误会一路传到下游。不如只约束“做什么”，让 Generator 自己决定“怎么做”。

Generator：按 Sprint 推进

Generator 接过 Spec，按 Sprint 一个一个实现功能。技术栈是 React + Vite + FastAPI + SQLite，有 Git 版本控制。每完成一个 Sprint，在提交给 Evaluator 之前先自评一轮。

这里有个设计细节：每个 Sprint 开始前，Generator 和 Evaluator 先谈判一份 Sprint Contract，约定这个 Sprint 具体要交付什么、怎么验收。这一步弥补了高层 Spec 和具体实现之间的鸿沟。

Agent 之间怎么通信？通过文件。一个 Agent 写文件，另一个读文件并回复，没有用复杂的消息队列或 API 调用。简单，但够用。

Evaluator：用 Playwright 当真正的用户

Evaluator 不是看代码打分，而是用 Playwright 像真实用户一样操作应用，真正去点按钮、填表单、测 API、查数据库状态。然后根据 Sprint Contract 里的验收标准逐条打分，不达标就打回去。

这个 Evaluator 调教起来不容易。Prithvi 说 Claude 开箱即用作为 QA Agent 其实很差劲：早期运行中，我看着它发现了真实的问题，然后说服自己这些问题不是大问题，最后批准了。它还倾向于只测表面功能，不深入边界情况。

调教的方法是反复看 Evaluator 的日志，找到它的判断和人的判断不一致的地方，然后针对性地改 Prompt。来回迭代了好几轮才让它的评分标准达到一个合理的水平。

9 块钱 vs 200 块钱：差距有多大

Prithvi 用同一个需求测了单 Agent 和三 Agent Harness。需求很简单：做一个 2D 复古游戏编辑器，要有关卡编辑、精灵编辑、实体行为和可玩测试模式。

贵了 20 倍，但产出质量完全不是一个级别的。

单 Agent 的版本乍看还行，但点进去就出问题了。布局浪费空间，面板用了固定高度，大片空白。工作流没有引导，用户得自己猜到”先做精灵和实体，再布关卡”的操作顺序。最要命的是游戏本身跑不了，实体出现在画面上但不响应任何输入，代码里实体定义和游戏运行时的连接是断的，表面看不出来。

三 Agent 版本从同一句话需求出发，Planner 把它扩展成了 10 个 Sprint、16 个功能的完整 Spec。除了基础编辑器和测试模式，还规划了精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成和关卡设计，甚至游戏导出和分享链接。Planner 还读了 Anthropic 的 frontend-design Skill，为整个应用制定了统一的视觉设计语言。

实际体验下来，画布用满了视窗，面板大小合理，界面有统一的视觉风格。精灵编辑器工具更丰富，颜色选择器更好用，缩放控制也更顺手。因为 Planner 主动嵌入了 AI 功能，应用内置了 Claude 集成，可以用自然语言生成精灵、设计关卡。

最关键的区别是在游戏模式能玩了。角色能移动、能跳跃，虽然物理引擎有些粗糙（角色跳到平台上会出现重叠），但核心功能是通的。

Evaluator 在这个过程中抓到了很多具体问题。比如矩形填充工具只在拖拽起止点放置了瓦片，而不是填满区域；删除实体生成点的快捷键判断条件写错了；FastAPI 的路由顺序有问题，reorder 被当成了frame_id 去解析。这些是单 Agent 版本里根本不会被发现的 Bug。

Opus 4.6 来了，Harness 该减肥了

上面这套三 Agent 架构是用 Opus 4.5 跑的。等 Opus 4.6 发布之后，Prithvi 做了一件所有维护 Harness 的人都应该做的事：重新审视每个组件，看哪些还有存在的必要。

比如，之前 Harness 里的每个组件都编码了一个关于模型不能做什么的假设，而这些假设值得反复检验。

Opus 4.6 在规划能力、长上下文检索和自我纠错上都有明显提升。Prithvi 于是把 Sprint 机制整个拿掉了，不再把工作拆成小块，让 Generator 一口气连续写代码。

Planner 保留了，因为没有它 Generator 会低估项目范围，直接开始写代码，最后做出来的东西功能少很多。Evaluator 也保留了，但从每个 Sprint 结束后评分改成了全部开发完再做一轮 QA。

这个简化改变了 Evaluator 的角色定位。在 4.5 时代，开发任务本身就在模型能力的边界上，Evaluator 几乎每轮都能抓到有意义的问题。到了 4.6，模型的裸能力边界往外扩了，很多以前需要 Evaluator 把关的东西现在 Generator 自己就能做好。Evaluator 的价值集中在那些仍然超出 Generator 能力的部分。

简化后的 Harness 测了一个更大的需求：用 Web Audio API 在浏览器里做一个 DAW（数字音频工作站）。

Generator 连续写了两个多小时的代码，没有 Sprint 拆分也没有跑偏，这在 4.5 上是做不到的。

QA 仍然抓到了关键问题。第一轮反馈说：“应用设计很好，AI Agent 集成也不错，但好几个核心 DAW 功能只是展示用的，时间轴上的音频片段不能拖动，没有乐器 UI 面板，没有可视化的效果编辑器。这些不是边缘功能，是让 DAW 可用的核心交互。”第二轮继续追：“录音功能还是空壳，片段裁剪和分割没实现，效果可视化只有数字滑块没有图形。”

最后跑出来的 DAW 离专业软件自然还很远，但核心组件都有了：编排视图、混音器、音频传输控制。Prithvi 甚至通过内置的 AI Agent 完全用自然语言编曲，设定节拍和调性、铺旋律、加鼓点、调混音、上混响。下面是 DAW 的演示视频：

写在最后

这篇文章给我最大的触动不是三 Agent 架构本身，而是 Prithvi 对 Harness 简化过程的记录。他一开始试过激进地砍组件，发现不行，又改成一次只去掉一个来观察影响。这种方法论比架构本身更有迁移价值，不管你是在做 Agent 还是做传统系统，理解每个组件为什么存在、它的假设是否还成立，都是工程上很重要的习惯。

另一个让我印象深刻的点是 Evaluator 的调教过程。它不是写几行 Prompt 就能用的，而是要反复看日志、找判断偏差、改 Prompt、再看日志。这跟我在做 Agent 评估时的体验一致，评估系统本身就是一个需要持续迭代的产品。

有趣的是，这套架构和 OpenAI 最近在 Codex 上做的方向形成了对照。Codex 更偏“单 Agent + 强上下文管理”路线，Anthropic 走的是“多 Agent 分工 + 外部反馈”路线。两条路各有取舍：单 Agent 更简单、更便宜，多 Agent 在复杂任务上的上限更高但成本也高得多。$124 做一个 DAW 和 $9 做一个游戏编辑器，差距不只是价格，更是产出质量的级别差异。

模型在变强，Harness 在变简单，但“找到下一个有效的 Agent 组合”这件事不会消失。用 Prithvi 的话说：“有意思的 Harness 组合空间不会随模型进步而缩小，它只是在移动。”

相关资源：

• 原文链接：https://www.anthropic.com/engineering/harness-design-long-running-apps
• 前作《长时间 Agent Harness》：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Frontend Design Skill：https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md
• 上下文工程：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Building Effective Agents：https://www.anthropic.com/research/building-effective-agents

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程师 Thariq（@trq212）发表的长文。上次他的文章分享了《像 Agent 一样思考：Claude Code 工具设计的进化史》，这次聊的是 Skill 怎么写才好用。原文链接：https://x.com/trq212/status/2033949937936085378。

写过 Claude Code Skill 的人应该都有一个体会：写出来容易，写好很难。

之前我推荐过不少好用的 Skill（《十个顶级 Claude Code Skills，装上就不想卸》《OpenClaw 必备 Skill 清单》），但“好用的 Skill 到底是怎么写出来的”这个问题一直没怎么聊过。市面上的教程大都停在”创建一个 SKILL.md 文件”这一步，至于写什么、怎么组织、哪些信息该放哪些不该放，基本没人系统讲过。

Anthropic 内部现在有几百个 Skill 在日常使用，Thariq 最近把他们踩过的坑整理成了一篇长文。我读完觉得信息密度挺高的，很多坑自己也踩过，但一直没想清楚为什么。这篇就把里面最有价值的部分整理出来。

先纠正一个常见误解

很多人觉得 Skill 就是一个 Markdown 文件。能跑，但没用好。

Skill 的本质是一个文件夹，里面可以放脚本、数据、模板、配置，Claude 能发现、探索和操作这些文件。另外，Skill 还支持很多配置选项（详见官方文档的 frontmatter 参考），包括动态注册 Hook。

Anthropic 内部用得最好的那些 Skill，恰恰是充分利用了文件夹结构和配置选项的。后面会具体聊到。

9 类 Skill：你的团队还缺哪些？

Thariq 把 Anthropic 内部所有的 Skill 做了一次盘点，发现它们大致可以归为 9 类。他说最好的 Skill 通常干净利落地属于某一类，而那些让人困惑的 Skill 往往横跨好几类。

这个分类不是什么权威定义，但作为一个自查清单挺实用的，可以看看你的团队还缺哪几类。

库和 API 参考

教 Claude 怎么正确使用某个库、CLI 或 SDK。可以是内部库，也可以是 Claude 经常用错的外部库。这类 Skill 通常会带一个代码片段文件夹和一份“踩坑清单”。

比如你内部的计费库有一堆边界情况，或者你的 CLI 工具有一些 Claude 不知道的子命令和用法。

产品验证

描述怎么测试和验证代码是否正确。通常会配合 Playwright、tmux 之类的外部工具来做验证。

这类 Skill 的价值在于确保 Claude 的输出是对的，而不是“它说对了就信它”。Thariq 的原话是：让一个工程师花一周时间专门打磨验证类 Skill，是值得的。

可以考虑的技巧包括让 Claude 录制测试视频方便回看，或者在每一步强制做断言。这些通常通过在 Skill 中放脚本来实现。

数据获取与分析

连接到你的数据和监控系统。这类 Skill 可能会包含带凭据的数据获取脚本、Dashboard ID、常见查询工作流。

比如“哪些事件表能看到注册→激活→付费的转化漏斗”，或者“Grafana 里哪个 dashboard 对应哪个问题”。

业务流程自动化

把重复性工作流一键化。比如自动聚合 ticket tracker、GitHub 活动和 Slack 消息来生成 standup，或者自动创建 ticket 并触发后续的 review 和通知流程。

这类 Skill 指令通常比较简单，但依赖其他 Skill 或 MCP。一个有用的技巧是把每次执行的结果保存到日志文件里，Claude 下次执行时可以参考上次的结果，保持一致性。

代码脚手架

为代码库中的特定功能生成框架代码。当你的脚手架有一些无法纯粹用代码覆盖的自然语言需求时，Skill 的优势就体现出来了。比如新建一个带你们标准认证、日志和部署配置的内部应用。

代码质量与审查

在团队内部强制执行代码质量标准。可以包含确定性脚本来保证鲁棒性。你可能想通过 Hook 自动触发这些 Skill，或者放到 GitHub Action 里跑。

比如启动一个全新视角的子 Agent 来挑刺，迭代到只剩 nitpick 级别的问题为止。

CI/CD 与部署

帮你拉代码、推代码和部署的 Skill。比如监控 PR 状态，自动重试 flaky CI，解决合并冲突，开启 auto-merge。或者做灰度发布时自动对比错误率，有回归就自动回滚。

Runbook

拿到一个症状（Slack 线程、告警或错误签名），走一遍多工具调查流程，输出结构化报告。这就是把 on-call 经验沉淀成了可执行的标准流程。

基础设施运维

执行日常维护和运维操作，有些涉及破坏性操作，所以 Skill 里可以内置安全护栏。比如查找孤立的 Pod/Volume，先发到 Slack 等一段时间确认，用户同意后再级联清理。

这 9 类基本覆盖了一个工程团队日常工作的方方面面。如果你的团队刚开始用 Skill，可以从这个清单出发，看看哪几类能最快产生价值。我自己的体感是验证类和业务流程自动化类最容易见效，因为它们解决的是每天都在重复的痛点。

知道了该做什么类型的 Skill，接下来的问题就是怎么写了。

怎么把 Skill 写好？

这部分是我觉得全文最有价值的，因为很多坑不踩一遍真想不到。

Anthropic 最近也发布了Skill Creator 来简化 Skill 的创建过程，但即使有工具辅助，下面这些原则还是得自己把握。

别写 Claude 已经知道的

Claude 本身就懂很多编程知识，对你的代码库也有不少了解。如果你的 Skill 主要是知识类的，重点放在那些能把 Claude 推出它默认思维模式的信息上。

frontend-design Skill 是个好例子。它是 Anthropic 的工程师跟客户反复迭代出来的，核心就是教 Claude 避免那些经典的 AI 审美，比如 Inter 字体配紫色渐变。这些才是 Claude 需要被纠正的地方，而不是告诉它“请写出高质量代码”。

好好写 Gotchas 部分

任何 Skill 里信息量最高的部分就是 Gotchas（踩坑清单）。把 Claude 使用你的 Skill 时经常犯的错记下来，随着使用不断补充。

我自己写 Skill 的经验也是这样。一开始写的 Skill 可能只有二三十行，用了一个月之后 Gotchas 部分比正文还长。因为每次 Claude 犯一个新错，你就加一条，这些积累才是 Skill 真正的价值所在。

用好文件系统和渐进式披露

前面说了，Skill 是文件夹，不只是 Markdown。你应该把整个文件系统当作上下文工程和渐进式披露（Progressive Disclosure）的手段。在 SKILL.md 里告诉 Claude 这个 Skill 里有哪些文件，它会在合适的时候去读。

最简单的做法是把详细的函数签名和用法示例拆到references/api.md 里。如果你的最终输出是 Markdown 文件，可以在assets/ 里放一个模板让 Claude 复制使用。

脚本、示例、参考文档，这些都可以分门别类放进 Skill 文件夹。Claude 知道它们在那儿，需要的时候自己会去找。

这个思路在上一篇《像 Agent 一样思考》里也聊过。从被动接收上下文到主动探索上下文，渐进式披露是 Claude Code 工具设计的核心理念之一。

别把 Claude 钉死

Claude 会尽量遵守你的指令，但 Skill 是会被反复使用的，如果指令太具体，它在某些场景下就会变得很死板。给 Claude 它需要的信息，但也给它根据具体情况灵活调整的空间。

比如不要写“必须按 A→B→C→D 四个步骤执行”，而是写“通常的流程是 A→B→C→D，但可以根据实际情况调整顺序或跳过某些步骤”。

想清楚初始化流程

有些 Skill 需要用户先提供一些上下文才能用。比如一个发 standup 到 Slack 的 Skill，需要知道发到哪个频道。

一个好的做法是把这些配置信息存到 Skill 目录下的config.json 里。第一次运行时，如果配置不存在，Claude 就问用户；配置好了以后就直接用，不再重复问。

如果你想让 Claude 给用户提结构化的选择题而不是开放式提问，可以让它调用AskUserQuestion 工具。

description 字段是写给模型看的

Claude Code 启动时会构建一个所有可用 Skill 的清单，每个 Skill 带上它的 description。Claude 扫这个清单来决定“当前这个请求有没有对应的 Skill”。

所以 description 不是给人看的摘要，而是给模型看的触发条件。你应该写清楚“什么时候应该触发这个 Skill”，而不是“这个 Skill 做了什么”。

这个细节我之前也没太注意，但仔细想想确实重要。如果 description 写的是“用于格式化代码”，Claude 可能在很多场景下都不确定要不要用。但如果写的是“当用户要求格式化代码、或代码风格不一致时触发”，触发率会准确得多。

给 Skill 加记忆

有些 Skill 可以通过存储数据来实现记忆功能。可以简单到往一个文本日志里追加内容，也可以复杂到用 SQLite 数据库。

比如前面提到的 standup Skill，如果每次执行都把内容追加到standups.log 里，下次运行时 Claude 读一遍历史，就能知道哪些是新变化，不需要从头分析。

需要注意的是，Skill 目录下的数据在升级 Skill 时可能被删掉。所以应该把数据存到稳定的位置。目前 Claude Code 提供了${CLAUDE_PLUGIN_DATA} 作为每个 Plugin 的稳定存储目录。

放脚本，让 Claude 组合

给 Claude 代码是你能做的最有力的事之一。把辅助脚本和库函数放到 Skill 里，Claude 就可以把精力花在组合和决策上，而不是从头写重复的样板代码。

比如在数据分析 Skill 里放一组从数据源拉数据的辅助函数，Claude 就可以按需组合这些函数来回答“周二发生了什么”这类问题。

按需 Hook

Skill 可以包含只在被调用时才激活的 Hook，持续到会话结束。适合那些比较“有态度”的 Hook，平时开着太烦，但某些场景下非常有用。

比如/careful，通过PreToolUse 拦截 Bash 里的rm -rf、DROP TABLE、force-push、kubectl delete。你只在碰生产环境时才想开它，平时开着只会让人抓狂。再比如/freeze，阻止 Claude 编辑特定目录之外的文件。调试的时候特别有用，你只想加日志，不想 Claude 顺手把不相关的代码也修了。

别忘了统计

顺便提一下分发和统计。Anthropic 内部用一个PreToolUse Hook 来记录 Skill 的使用情况（示例代码），这样就能发现哪些 Skill 被高频使用、哪些触发率低于预期。

分发方面，小团队直接把 Skill 提交到仓库的.claude/skills 目录就行。规模大了以后，可以搭建内部的 Plugin Marketplace，让团队成员自己选择安装哪些。Anthropic 内部没有一个集中的团队来决定哪些 Skill 上架。有人做了一个好用的 Skill，先放到一个 sandbox 目录让人试用，有了口碑再提 PR 进入正式市场。

还有一个需要注意的问题：Skill 之间的组合和依赖。比如你的 CSV 生成 Skill 依赖一个文件上传 Skill。目前 Marketplace 还没有原生的依赖管理，但你可以在 Skill 里直接引用其他 Skill 的名字，Claude 会自动调用已安装的。

写在最后

回头看这篇文章，最让我有感触的是 Gotchas 部分。我自己写 Skill 的经历也验证了这一点，Skill 的价值不在初始版本写得多完整，而在于使用过程中不断补充 Claude 犯过的错。一开始写个十几行的骨架，用一段时间后自然会长成一个成熟的 Skill。

另一个让我重新审视的是“别写 Claude 已经知道的”。我之前写过一些 Skill，里面有大段的编码规范和最佳实践，这些其实 Claude 本来就会。真正该写进 Skill 的是那些 Claude 不知道的、你的团队特有的知识，比如内部约定、踩过的坑、用什么工具查什么问题。

如果你已经在用 Skills 但觉得效果一般，不妨回去对照一下上面的原则，看看有哪些地方可以调整。如果你还没开始，从一个小的 Gotchas 清单开始就行，不需要一上来就做得很复杂。

相关资源：

• 原文链接：https://x.com/trq212/status/2033949937936085378
• Claude Code Skills 文档：https://code.claude.com/docs/en/skills
• Agent Skills 课程：https://anthropic.skilljar.com/introduction-to-agent-skills
• Skill Creator 博客：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills
• Anthropic 官方 Skills 仓库：https://github.com/anthropics/skills
• Skill 使用日志 Hook 示例：https://gist.github.com/ThariqS/24defad423d701746e23dc19aace4de5

话题标签：#ClaudeCode #Skills #Anthropic #AI 编程

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

上次分享了《十个顶级 Claude Code Skills，装上就不想卸》，不少读者问我 OpenClaw 这边有没有类似的推荐。今天就来一篇。

跟 Claude Code 比，全新安装的 OpenClaw 其实挺无聊的。它能聊天、能写代码、能操作文件系统，但碰到需要上网搜东西、刷个社交媒体、或者画张图的场景，就卡住了，看起来跟 ChatGPT 之类的聊天工具并没有多大区别。但这其实是还没用好 OpenClaw 最基本的扩展机制，也就是 Skill。ClawHub 上的 Skill 数量已经破了 25000，光是排名第一的 self-improving-agent 就有 20 多万的安装量。不过 Skill 装多了也有问题，互相打架不说，上下文也吃不消。所以关键还是选对几个真正有用的。

这篇就整理一份我自己在用的 OpenClaw Skill 清单，每个都有附安装命令，方便你一键安装。

先装这三个

这三个 Skill 我觉得属于必备级别，建议第一时间搞定。

Self-Improving Agent

ClawHub 排名第一不是没道理的。

这个 Skill 让 OpenClaw 具备了自我学习的能力。每次你纠正它的错误、每次命令执行失败、每次它发现了更好的做法，都会被记录下来，变成它下次做事的经验。用得越久，它就越懂你的习惯和偏好。

我用了一段时间之后，最明显的变化是它不再重复犯同一个错了。比如我习惯用 pnpm 而不是 npm，纠正过一次之后就再也没出过。听起来是个小事，但每天省几次纠正的功夫，累积下来效率提升挺明显的。

npx clawdhub install self-improving-agent

Find Skills

OpenClaw 不像 Claude Code 那样内置了大量工具，很多能力需要通过 Skill 来补齐。问题是 ClawHub 上 25000 多个 Skill，你怎么知道哪个能解决你当前的问题？

Find Skills 做的就是这件事。当你问 OpenClaw“怎么做 X”的时候，它会先去 ClawHub 搜一圈，看看有没有现成的 Skill 能用，找到了就直接推荐给你，省得自己一个个去翻。

有点像给 OpenClaw 装了个应用商店的搜索入口。

npx clawdhub install find-skills

Skill Vetter

前面说了 ClawHub 上有 25000 多个 Skill，质量参差不齐。有的 Skill 写得不错，有的可能藏着恶意代码，毕竟 Skill 本质上就是一段会被 Agent 执行的指令。

Skill Vetter 的作用是在安装前自动扫描 Skill 的内容，检查有没有潜在的安全隐患。比如 Skill 里是否有可疑的网络请求、是否试图读取敏感文件、是否包含 prompt injection 的模式。

如果你对安全要求更高，可以搭配慢雾（SlowMist）出的 OpenClaw 安全实践指南一起用。那份指南走的是零信任路线，默认假设 prompt injection、供应链投毒都可能发生，从日常操作到每晚巡检都有覆盖。对于在高权限环境下跑 OpenClaw 的用户来说，值得过一遍。

npx clawhub install skill-vetter

附安全实践指南链接：https://github.com/slowmist/openclaw-security-practice-guide

让 OpenClaw 能上网

裸机的 OpenClaw 没有联网能力，不能搜索、不能访问网页。这三个 Skill 分别解决搜索、浏览器操作和长文提炼三个场景。

Tavily Search

给 OpenClaw 加上网络搜索能力。Tavily 有月免费额度，对个人用户来说日常搜索基本够用，不需要一上来就掏钱。

搜索质量比让 OpenClaw 去 curl 一个搜索引擎然后解析 HTML 好太多了。返回的结果是结构化的，直接就能用。

npx clawhub install tavily-search

Agent Browser

有些事光靠搜索引擎搞不定。比如你要操作一个需要登录的后台、要在某个网站上填表单、或者要从一个动态加载的页面抓数据，这些都需要真正的浏览器。

Agent Browser 让 OpenClaw 能控制浏览器，点击、输入、截屏、导航，该有的都有。

这里有个关键技巧：用--auto-connect 参数连接到你已经登录过的 Chrome 浏览器。这样 OpenClaw 就能直接用你的登录态，不用每次都重新登录各种服务。省事太多了。

npx clawhub install agent-browser

Summarize

经常需要让 OpenClaw 帮你读一篇长文章或者处理一段音视频，Summarize 就是干这个的。给它一个网址、一个文件路径、或者一段媒体，它帮你快速生成摘要。

用之前需要先装个全局依赖：

npm i -g @steipete/summarizenpx clawhub install summarize

搜索、浏览器、摘要，三个加一起，OpenClaw 在信息获取层面就基本没有短板了。不过这还只是读的能力。如果你还想让它去社交媒体上逛，那就需要下面这组 Skill。

社交媒体三件套

这三个 Skill 来自同一个开发者 jackwener，做的事情就是让 OpenClaw 等各种 Agent 能搜索、访问和交互主流社交平台的内容。

小红书：

npx skills add jackwener/xiaohongshu-cli

Twitter/X：

npx skills add jackwener/twitter-cli

Reddit：

npx skills add jackwener/rdt-cli

我自己用得最多的是 xiaohongshu-cli 和 twitter-cli。比如想要了解某个工具的用户评价，让 OpenClaw 去小红书和 Twitter 上搜一圈，回来给我整理个摘要，比自己去翻快多了。

jackwener 还开源了 Bilibili、Telegram、Discord、微博、BOSS 直聘等平台的 CLI 工具和对应 Skill，需要的可以去他的 GitHub 上看看。

锦上添花

下面这几个不是每个人都需要，但如果你的使用场景刚好对上了，装了之后体验会好一截。

Proactive Agent

普通 OpenClaw 是你给任务它才干活。Proactive Agent 让它变得主动一些，能自我迭代、主动发现问题、主动优化方案。

npx clawhub install proactive-agent

GitHub

有开源项目要维护，或者想给别人的项目提 PR，这个 Skill 让 OpenClaw 能直接操作 GitHub 的 Issues、PR、Code Review 等工作流。

npx clawhub install GitHub

Nano Banana Pro

用 Gemini 3 Pro 的图像生成能力，让 OpenClaw 能画图。支持文生图和图生图，1K/2K/4K 分辨率都行，编辑已有图片也可以。做封面图、画流程图、生成配图的时候挺方便的。

npx clawhub install nano-banana-pro

Mcporter

OpenClaw 本身不支持 MCP 工具。如果你之前在 Claude Code 上用惯了各种 MCP Server，换到 OpenClaw 会觉得少了点什么。

Mcporter 做的是格式转换：把 MCP 工具转成 CLI 格式，再作为 Skill 给 OpenClaw 使用。算是一个桥接方案，让你之前的 MCP 生态投资不至于浪费。

npx clawhub install mcporter

以上就是我目前在用的 OpenClaw Skill 组合：先把自学习和安全两个基础打好，再把联网和社交媒体的信息通道打通，最后根据自己的工作场景挑几个辅助工具。而至于编程呢，还是把专业的事情交给专业的工具，继续交给 Claude Code 来负责。你可以用 OpenClaw 的 ACP Agent 来调度 Claude Code，顺手也解决了手机访问的问题（接入 Slack/Discord/飞书等可以随时手机下发任务）。

如果这些还不够用，下面这几个地方可以继续探索：

相关资源：

• ClawHub 官网：https://clawhub.ai/
• Awesome OpenClaw Skills：https://github.com/VoltAgent/awesome-openclaw-skills
• OpenClaw Skills 仓库：https://github.com/openclaw/skills
• SkillsMap：https://skillsmp.com/
• Skills.SH：https://skills.sh/
• Awesome OpenClaw Usecases：https://github.com/hesamsheikh/awesome-openclaw-usecases

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

用 Claude Code 大半年了，Skills 和 Plugin 装了几十个，删了一半，留下来的都是真正改变了我工作方式的。这篇就挑十个我用得最多、也觉得最值得推荐的，每个都附安装命令，拿去直接用。

先简单说下 Skill 和 Plugin 的区别。Skill 是一个包含 SKILL.md 的文件夹，教 Claude 怎么做某类任务；Plugin 更完整，可以打包命令、SubAgent、Hook 和 MCP 服务器。不过对使用者来说差不多，下面就不区分了。

Superpowers

如果只能装一个，我选这个。

Superpowers 打包了 20 多个可组合的 Skill，覆盖软件开发的完整流程。brainstorming、TDD、代码审查、Git 提交，每个环节都有对应的 Skill 来约束 Claude 的行为。

我用得最多的是 brainstorming。装了之后，Claude 不会拿到需求就直接开写，而是先问你一轮问题，探索不同方案，把设计决策摊开讨论，最后生成一份设计文档存到本地。看似慢了，实际上能省掉后面大量返工。你会发现很多问题在讨论阶段就暴露了，而不是写了三百行代码之后才发现方向不对。

另一个常用的是 TDD 工作流。它会强制 Claude 先写测试再写实现，跑不过就继续改，直到全绿。Claude 的默认行为是直接写代码然后告诉你“应该没问题”，有了这个约束差别非常大。

当然，20 多个 Skill 全开可能有点重。我一般只启用 brainstorming 和 TDD 两个，其他的按需打开。

claude plugin install superpowers

GitHub:https://github.com/obra/superpowers

Planning with Files

Claude Code 自带的 Plan Mode 有个让人头疼的问题：规划存在对话上下文里，上下文一压缩就丢了。长任务做到一半，Claude 忘了自己在干嘛。又从头开始。

Planning with Files 把规划、进度和知识都写进 Markdown 文件。Claude 开始干活前先创建计划文件，每完成一步就更新进度，遇到有用的信息就记到知识文件里。文件在磁盘上就不会丢，即使上下文被压缩了也能恢复状态。

这个思路其实来自 Manus。Manus 在复杂任务上表现好，核心原因之一就是中间状态都持久化了。Planning with Files 算是社区版的实现。

claude plugin marketplace add OthmanAdi/planning-with-filesclaude plugin install planning-with-files

GitHub:https://github.com/OthmanAdi/planning-with-files

UI UX Pro Max

让 Claude 写前端页面，出来的东西大都长一个样。紫色渐变背景，圆角卡片，居中布局，也就是典型的 “AI 审美”。

Anthropic 官方有个 frontend-design Skill 能改善一些，但 UI UX Pro Max 做得更彻底。它内置了 67 种 UI 风格和 161 套行业配色方案，根据你的项目类型自动推荐设计系统，从配色到排版到交互模式，一步到位。我试着让它做一个 SaaS 后台的 dashboard，选了 Bento Grid 风格，出来的效果比 Claude 默认的好太多，至少看起来不像 AI 做的了。

技术栈方面，React、Vue、Svelte、SwiftUI、Flutter 这些都支持，不只是 Web。

claude plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skillclaude plugin install ui-ux-pro-max@ui-ux-pro-max-skill

GitHub:https://github.com/nextlevelbuilder/ui-ux-pro-max-skill

聊完前端设计，下一个自然要聊的就是代码质量了。

Code Review

这是官方 Plugin 里我觉得设计最精巧的一个。

它不是让一个 Claude 从头到尾看代码，而是启动多个 Agent 并行审查同一个 PR。有的看逻辑正确性，有的看安全漏洞，有的看代码风格。每个 Agent 给出的问题都带置信度分数，最后按分数过滤，只保留高置信度的反馈。

为什么要搞这么复杂？因为 AI 代码审查最大的问题是假阳性太多。以前让 Claude 审代码，它总能挑出一堆潜在问题，看着很认真，但大部分都是过度谨慎的废话。有了置信度过滤之后，留下来的基本都值得看一看。

不过使用时要注意，大 PR 跑起来 token 消耗挺猛的，好几个 Agent 同时跑，一次 review 吃掉的 token 可能比写代码本身还多。小 PR 用着挺舒服，大 PR 建议先拆再审。

claude plugin install code-review

GitHub:https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-review

Code Simplifier

写代码的时候容易堆逻辑，写完跑通了就不想再碰了。Code Simplifier 帮你做那个“写完再看一遍”的事情。

它聚焦最近修改过的代码，检查重复逻辑、多余的中间变量、可以合并的条件分支。不改功能，只做简化。上次我写了一段数据处理的逻辑，里面有三段几乎一样的错误处理，跑完 Code Simplifier 它给合并成了一个通用函数，代码量少了三分之一。

claude plugin install code-simplifier

GitHub:https://github.com/anthropics/claude-plugins-official/tree/main/plugins/code-simplifier

Webapp Testing

前端写完了，测试怎么办？手动点来点去太慢，写 Playwright 脚本又太繁琐。这个 Skill 把过程自动化了：你告诉 Claude 要测什么场景，它自己用 Playwright 写脚本、启动浏览器、跑测试、截屏，有问题还会自己调试。跟前面的 UI UX Pro Max 搭配起来特别顺手。

claude plugin marketplace add anthropics/skillsclaude plugin install example-skills@anthropic-agent-skills

GitHub:https://github.com/anthropics/skills/tree/main/skills/webapp-testing

Ralph Loop

名字来自辛普森动画里的 Ralph Wiggum，Anthropic 工程师 Daisy Hollman 做的。通过 Stop Hook 拦截 Claude 的退出，把同一个任务重新喂给它。

Claude Code 有个习惯：做到一半觉得差不多了就停下来说“我已经完成了基础框架，你可以在此基础上继续”。Ralph Loop 不让它停。Claude 试图退出，Hook 拦截，检查完成条件，没满足就塞回去。循环往复，直到真正做完。

简单粗暴，但真的管用。

用这个有个关键技巧：完成条件要写得越具体越好。做完这个功能不行，Claude 会自己说服自己已经完成了。要写“所有 CRUD 端点可用，测试覆盖率超过 80% ，README 包含 API 文档，完成后输出 COMPLETE”。条件越模糊，它越会找理由提前收工。

claude plugin install ralph-loop# 使用示例/ralph-loop:ralph-loop"实现用户认证模块。完成标准：JWT 登录注册、测试通过、README 更新。完成后输出 COMPLETE" --max-iterations20 --completion-promise"COMPLETE"

更好详细例子可以参考:https://awesomeclaude.ai/ralph-wiggum

MCP Builder

MCP 这个协议最近讨论度挺高，但真要从零写一个 MCP Server，门槛还是不低。MCP Builder 把构建过程拆成了四个阶段，引导 Claude 一步步完成：理解 API、设计工具接口、实现、测试。

用它的体验比直接让 Claude “帮我写一个 MCP Server”好很多。直接写的话 Claude 经常漏掉 rate limiting 和 token 过期处理等等之类边界情况，用了 MCP Builder 之后这些它都会主动考虑。

claude plugin marketplace add anthropics/skillsclaude plugin install example-skills@anthropic-agent-skills

GitHub:https://github.com/anthropics/skills/tree/main/skills/mcp-builder

PPTX

做 PPT 大概是程序员最不想做的事。

这个 Skill 让 Claude 直接生成.pptx 文件，支持母版、图表、动画。说实话，生成的 PPT 不可能直接拿去做重要汇报，内容、排版和配色都还需要适当调整。但用它生成初稿已经完全够用了，可以大大节省 PPT 得创作时间。

它解决的是“从零开始太痛苦”的问题。起点有了，后面就快了。

claude plugin marketplace add anthropics/skillsclaude plugin install document-skills@anthropic-agent-skills

GitHub:https://github.com/anthropics/skills/tree/main/skills/pptx

Skill Creator

最后一个放 meta 的。Skill Creator 是 Anthropic 官方出的，用来帮你创建新的 Skill 的技能。

之前我写过一篇文章聊它的更新（《写 Claude Skill 最大的盲区，Anthropic 终于帮你补上了》），核心变化是加了 eval 测试框架。现在你可以给 Skill 写测试用例，验证它到底有没有在起作用，还能做 A/B 对比，有 Skill 和没 Skill 的效果差多少，看数据说话而不是凭感觉。

上面九个用完了觉得不够？那就自己造。

claude plugin install skill-creator

GitHub:https://github.com/anthropics/claude-plugins-official/tree/main/plugins/skill-creator

选 Skill 跟选工具一样，不在多，在合适。装太多互相打架，反而会影响整体的性能，并且上下文也吃不消，所以精选几个足够用即可。

另外，对不同功能的 Skills，特别是仅跟项目相关的 Skills，推荐放到项目中，提交到 Git，即方便了管理和团队共享，还节省了其他项目的上下文空间。

相关资源：

• Anthropic 官方 Skills 仓库：https://github.com/anthropics/skills
• Anthropic 官方 Plugins 仓库：https://github.com/anthropics/claude-plugins-official
• Awesome Claude Skills 社区列表：https://github.com/travisvn/awesome-claude-skills
• Claude Code Skills 文档：https://code.claude.com/docs/en/skills
• Skills 市场：https://skillsmp.com/

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

腾讯大厦门口排了近千人，从 9 岁小学生到 68 岁老人，就为了免费装一只龙虾。与此同时闲鱼上远程装龙虾的价格从 200 涨到了 1000，一周之内，字节上线 ArkClaw，腾讯一口气推了 QClaw 和 WorkBuddy，QQ 开放了官方接入，小米发了手机版 Miclaw，周鸿祎在两会上说 360 要出一键安装版。大厂集体下场帮你装龙虾。

看着挺热闹，但我越看越觉得哪里不对。

免费的铲子最贵

用过 OpenClaw 的人都知道，这东西跟 AI 聊天完全不是一个量级的 Token 消耗。聊天嘛，一轮几百/数千 Token 也 就完事了。而 OpenClaw 不一样，它后台一直在跑，搜东西、写文档、调代码、操作你的电脑，一个稍微复杂点的任务就是几千次模型调用。

我看了下 OpenRouter 3 月的数据。MiniMax M2.5 和 Kimi K2.5 稳坐调用量前两名，合计占前十大模型总量的五分之一。Kimi Claw 更夸张，发布后 20 天的收入就直接超过 2025 全年。MiniMax 日均 Token 消耗涨到去年 12 月的 6 倍。

所以大厂帮你免费装龙虾图什么？

装完你得选个模型吧？选完得持续烧 Token 吧？淘金热里最赚钱的从来不是淘金的人，是卖铲子的。搞清楚这一层，再看各家方案就不会被免费、零门槛这些词晃到了。

铲子也有区别

铲子分两种。

阿里云、百度智能云、火山引擎、华为云卖的是“帮你装原版”，在轻量服务器上预装好 OpenClaw 镜像，跑的还是 Peter Steinberger 的开源代码，省掉折腾环境的功夫。Kimi Claw、MaxClaw、腾讯 WorkBuddy 走另一条路，自己造了底层，同时兼容 OpenClaw Skills。

选哪种呢？

想最省事，可以从 SaaS 类型开始。Kimi Claw 在 kimi.com 里直接用，K2.5 模型，号称预装 5000 多个 ClawHub Skills。MaxClaw 底层是 M2.5，用稀疏激活架构把推理成本压到同级别的 1/7 到 1/20。两家都是开浏览器就能上手，轻度用用很方便。

不过要注意，SaaS 的沙箱环境碰不了本地文件。想让龙虾帮你整理桌面、监控文件夹、自动提交代码？不可能。而且还有个更实际的问题：你的聊天记录、使用习惯、Skills 配置全在它的云上，用得越久越难搬走。兼容 5000 个 Skills 这种话听听就好，实际能跑多少不好说，但本地文件系统相关的一个都不行。

SaaS 不够用，那就自己装。

阿里云 1 月底最早上线镜像，火山引擎、百度、华为各大云厂商也都随后跟进。这些云厂商的方案大同小异，无非是利用云平台的资源部署一套 OpenClaw 出来。如果你选这种方案，建议选一个最熟悉的云平台，后续出了啥问题也方便排查。

腾讯这波铺得最开

腾讯的打法跟别家不太一样。别人是挑一个方向做打，腾讯直接铺了多条线。

QQ 开放平台 3 月 7 日上了 OpenClaw 接入。扫个码创建 QQ 机器人，一分钟就可以绑到你的 OpenClaw 上。

QClaw 是本地一键部署包，装完自动连微信和 QQ。还在内测，没有账号其实也不知道是不是真的允许直接接入微信。

当然还有一个腾讯自研的 WorkBuddy，接入企业微信，内置 20 多种技能包适配办公场景，新注册送 5000 Credits，今天刚上线。

不过这么多产品，大家最关心还是腾讯是否会放开微信的接入，感觉可能性不大。

写在最后

其实用好 OpenClaw 的关键不是怎么部署，而是要跟你的日常工作结合起来，它越了解你就越好用。所以，选择一个跟你日常工作最接近的部署方案即可，不要听各种卖铲子的宣传口号。

比如，我自己在用 K8s 跑原版 OpenClaw，LiteLLM 做模型网关隔离大模型配置，容器隔离 OpenClaw 运行环境，跑下来还没发现有啥限制，反而能够帮我更好管好 K8s 集群，随时随地测试验证一些新的想法或者社区的新项目、新 功能。

好用的另一面也要注意，2 月 ClawHavoc 供应链投毒，1000 多个恶意 Skills 混进官方仓库，13.5 万台设备中招。Token 一直烧，安全事件不断，除了新鲜好玩，安全也不容忽视，特别要注意别把未认证的 OpenClaw 放到公网上。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 官方博客《Improving skill-creator: Test, measure, and refine Agent Skills》，原文链接：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills。本文在翻译基础上做了整理和补充。

写了几十个 Claude Skill 之后，我最大的困惑不是怎么写，而是它到底有没有用。每次写完一个 Skill，扔到.claude/skills/ 目录里，然后就开始凭感觉判断效果了。有时候觉得有用，过两天再看结果好像又变差了，不确定是 Skill 在起作用，还是模型本来的随机行为导致的。更麻烦的是，Claude 每次更新之后，原来好用的 Skill 会不会悄悄失效，完全不知道。

这个困惑应该不只我一个人有。写 Skill 的人大多不是工程师，清楚自己的工作流程，但缺少工具来验证 Skill 到底有没有在起作用。昨天 Anthropic 更新了 skill-creator（《Improving skill-creator: Test, measure, and refine Agent Skills》），核心思路是把软件工程那套东西搬过来，测试、基准评估、迭代改进，但不需要写代码。

Claude Code 用户可以直接执行下面的命令安装：

claude plugin install skill-creator

Claude.ai 和 Cowork 里直接跟 Claude 说用 skill-creator 创建想要的 SKILL 就行。

先搞清楚你在写哪种 Skill

在聊测试之前，有一个框架我觉得挺有价值的，可以帮你在下笔之前想清楚一件事。

Anthropic 把 Skill 分成了两种，回头一想，确实是这么回事。

第一种是能力补充型，给模型添加它本来做不好的能力。Claude 官方提供的文档生成类 Skill 是个典型的例子，里面编码了一套技巧和模式，生成结果比直接提示词好得多。模型没有这个 Skill，就达不到这个效果。

第二种是流程编排型，模型原本就能处理每个环节，但 Skill 把这些环节按照团队规范串联起来，给的是“用什么顺序做什么事”这样的约束。NDA 审查、每周报告生成这类 Skill 属于这种。

这个区分对设计 Skill 很有参考价值：能力补充型有个隐患，随着模型变强，它可能会慢慢变得多余，甚至是限制 Claude 的能力。这有点像你精心写了一本新员工培训手册，结果新来的人比老员工还熟练，手册自然就没人翻了。如果有测试，你能及时发现“这个 Skill 已经完成历史使命了”，而不是一直带着一个没用的包袱。

流程编排型更耐用，但价值完全依赖于流程的严格执行，测试的重点是验证它有没有按预定顺序走完每一步。

写之前先想清楚自己在写哪种，测试策略和预期生命周期都不一样。

用 eval 取代感觉

skill-creator 现在可以帮你写 eval。形式也很简单，你给出测试提示词，描述期望的行为，然后让 skill-creator 判断你的 Skill 是否经得住检验。做过软件测试的人会觉得这个模式很熟悉，区别是不用写代码，用自然语言描述预期结果就够了。

比如 PDF Skill，以前处理不可填写的表单时经常出错，原因是 Claude 需要在没有字段定义的情况下精确定位文字放置位置。写了 eval 之后，才定位到这个具体失败点，最后通过把定位锚定到提取出来的文字坐标解决了问题。如果没有 eval，这个 bug 可能就一直隐藏着，每次遇到不可填写的表单就悄悄出问题。

eval 最直接的价值是捕捉质量回归。模型升级或周边基础设施变动之后，原本好用的 Skill 可能行为发生变化。在变化影响到实际工作流之前，eval 能提前给你预警。

不过还有一个更微妙的用途，即判断 Skill 是否还有存在的必要。对于能力补充型 Skill 来说，如果基础模型不加载 Skill 就能通过 eval，说明这些技巧已经被模型内化了，Skill 不是坏了，只是完成使命了。这个信号你只能靠测试发现，靠感觉永远看不出来。

更新里还加了 benchmark 模式，可以跑标准化评估，跟踪 eval 通过率、耗时和 token 用量。数据保存在本地，可以集成到 dashboard 或 CI 系统里。

多 Agent 并行

之前 eval 是顺序执行的，速度慢不说，测试之间上下文还会互相污染。前一个测试的内容可能影响到后一个的判断。现在 skill-creator 支持多 Agent 并行跑 eval，每个 Agent 在独立的上下文里运行，有各自的 token 和耗时统计，互不干扰。

另外还加了 comparator agent，用来做 A/B 对比：两个版本的 Skill 对比，或者 Skill vs 不加 Skill。有点像双盲实验，负责评判的 Agent 不知道自己看的是哪个版本的输出，尽量排除评估偏差。这个设计基本解决了“我觉得改好了，但其实不知道”的问题。

触发时机最容易被忽略

输出质量测完了，是不是就够了？不一定。Skill 首先得在对的时候触发才有意义。这是我自己写 Skill 时踩得最多的地方：描述写得太宽，每次稍微相关的请求都会触发；描述写得太窄，只有完全匹配的词才会触发，平时根本用不上。两种情况都让人头疼。

skill-creator 现在能分析当前的 Skill 描述，对照一组测试提示词，推荐修改来减少误触发和漏触发。Anthropic 测试了 6 个公共文档创建类 Skill，有 5 个的触发精度通过这个方法得到了改善。

说实话，这个功能我觉得是这次更新里最实用的，因为触发问题是最隐蔽的。你写的逻辑完全正确，但描述没有匹配到用户的表达方式，Skill 就等于白写了。

设计 eval 其实是在把期望说清楚

看完这次更新，我对 Skill 写作有了一个新认识：设计 eval 的过程，本质上是在逼你把“期望什么行为”说清楚。很多时候 Skill 效果差，不是因为提示词写得不好，而是作者自己也没想清楚什么叫成功。当你被迫用语言描述“在这个输入下，Claude 应该做到什么”，很多模糊的预期就会浮出水面。

Anthropic 还提到了一个有意思的预判：随着模型越来越强，Skill 和 spec 之间的边界可能会模糊。现在的 SKILL.md 本质上是实现计划，在告诉 Claude 怎么做事。以后也许只需要描述你想要什么，模型自己搞清楚怎么做。eval 框架恰好在往这个方向走，eval 描述的是 what，也就是期望的结果。某种程度上，这个描述本身可能就是未来形态的 Skill。

如果你也在写 Skill，下次不妨少靠感觉，给它加个 eval 验一验。不需要多复杂，一条提示词、一段预期描述就够了。跑一遍，可能会发现一些你没意识到的问题。

相关资源

• skill-creator 插件：https://github.com/anthropics/claude-plugins-official/tree/main/plugins/skill-creator
• Anthropic 官方 Skills 仓库：https://github.com/anthropics/skills
• 原文链接：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

刚刚刷到一个 OpenClaw 的曝光看板 OpenClaw Exposure Watchboard，列出了暴露在公网上的 23 万个 OpenClaw 实例，并且数量还在不停上涨中。

OpenClaw 是最近爆火的开源 AI Agent，也已经登顶 Github Star 榜单，可以一键接入 Telegram、飞书、Slack，帮你自动处理消息、写邮件、操控本地文件。功能确实强，但安全问题也一直是 OpenClaw 最大的痛点。

特别是在云服务器上部署时，如果没改默认配置，就可能直接暴露到公网上，造成重大损失，比如 API Key 泄漏、聊天记录曝光等等。

更严重的是 CVE-2026-25253，一键 RCE。只要点个恶意链接，对方通过 WebSocket 就能拿到你的 Token，直接在你机器上执行命令。

如果你部署了 OpenClaw，现在就去检查：开启认证，Gateway 监听到127.0.0.1，18789 端口走 SSH 隧道或 Cloudflare Tunnel 而不是直接暴露，版本升到 v2026.1.29 以上（CVE 补丁在这版）。然后去那个 Watchboard 搜一下自己的 IP，如果已经上榜了，赶紧把所有相关的账号密码重置。

其实，如果你主要通过飞书、Slack 等 IM 来使用的话，完全没必要把 18789 端口暴露出去，也没必要绑公网 IP，只要外网能通就能使用了。

你还有哪些好的安全建议？评论区聊聊。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

你在 ChatGPT 上积累的偏好、纠正过的习惯、教会它的规矩，能带到 Claude 上吗？直到最近，答案一直是不能。

每个 AI 平台把你的数据锁在自己家里，想搬走？没门。你的名字、职业、技术栈、写作偏好、沟通习惯……在 ChatGPT 里积累了大半年，换到 Claude 又得从头来一遍。再试试 Gemini？再来一遍。想养个龙虾，给 OpenClaw 初始化？还是要再来一遍。

社区里也有很多人试图解决这个问题，比如 Mem0 做了跨平台的记忆中间层，还有 AI Context Flow 这类浏览器插件。但这些方案要么依赖太重，要么还不够成熟。

最近 Claude 推出了记忆导入功能，可以把 ChatGPT 等其他 AI 里积累的记忆一键搬过来。功能不复杂，但我看了它提供的导出提示词之后，发现了一个更有意思的玩法。这条提示词其实是个万能工具，你可以在任何 AI 上提取 AI 记忆档案。以后换工具的时候直接导入，不用再从零开始。

Claude 的记忆导入：怎么用

先说 Claude 官方的流程，很简单，两步就能搞定。

第一步：从 ChatGPT 导出记忆

打开 ChatGPT，把下面这段提示词发给它：

I'm moving to another service and need to export my data. List every memory you have stored about me, as well as any context you've learned about me from past conversations. Output everything in a single code block so I can easily copy it. Format each entry as: [date saved, if available] - memory content. Make sure to cover all of the following — preserve my words verbatim where possible: Instructions I've given you about how to respond (tone, format, style, 'always do X', 'never do Y'). Personal details: name, location, job, family, interests. Projects, goals, and recurring topics. Tools, languages, and frameworks I use. Preferences and corrections I've made to your behavior. Any other stored context not covered above. Do not summarize, group, or omit any entries. After the code block, confirm whether that is the complete set or if any remain.

ChatGPT 会把它记住的关于你的所有信息，整理成一个代码块输出。复制下来就行。导出结果大概长这样：

[2025-06-15] - User is a software engineer working on Kubernetes and cloud infrastructure[2025-08-03] - Prefers concise, technical writing style without emojis[2025-09-12] - Uses Go and Python primarily, familiar with Rust[2025-10-20] - Always respond in Chinese unless code comments[No date] - User corrected: do not add type annotations to Python code unless asked[No date] - Prefers short function names, dislikes over-engineering

条目数量因人而异，用得越久记忆越多。我自己的 ChatGPT 账号导出了大概 30 多条。

第二步：导入到 Claude

打开 Claude 的设置（Settings > Capabilities），找到 Memory 部分，点“Start import”。把刚才复制的内容粘贴进去，点“Add to memory”。Claude 会自动提取关键信息，存为独立的记忆条目。

整个过程不到一分钟。导入完成后，可以问 Claude 一句“I updated my memory. What did you learn about me?”来验证效果。

有几点需要注意：

• 这个功能需要 Pro 及以上的付费计划，免费用户暂时没有记忆功能。
• Claude 的记忆偏向工作相关的内容，纯个人信息（比如你养了什么宠物）可能不会被自动保留，需要手动添加。
• 功能还在实验阶段，不是所有导入的记忆都能被识别。

这条提示词才是重点

Claude 的记忆导入功能当然方便，但如果你仔细看一下那条导出提示词，会发现它才是真正的宝贝。

为什么？因为这条提示词跟 Claude 没有半点关系。就是一段通用的提示词，你发给任何 AI 都行。ChatGPT、Gemini 等等，它们都会把记住的关于你的东西整理出来。

拿到导出结果后，你可以：

• 导入到 Claude（Anthropic 官方流程）
• 塞进其他 AI 的自定义指令或系统提示词
• 作为 OpenClaw 的初始记忆
• 写进 Claude Code 的CLAUDE.md
• 存到本地文件，随时复用

拆解一下这条提示词

这条提示词写得挺讲究的，值得拆开看看。

先看第一句：“I’m moving to another service and need to export my data.” 直接告诉 AI 你要搬家了，需要把东西全打包带走。这比直接问“你记住了我什么”效果好得多，AI 会当成一个正经的导出需求来处理，不会敷衍你。

然后是输出格式：“Output everything in a single code block” 和 “[date saved, if available] - memory content”。代码块方便一键复制，日期标记帮你追溯记忆的时间线。

最核心的是六个覆盖维度。简单归纳就是三类：你教 AI 怎么做事的指令（语气、格式、风格），你是谁的基本信息（职业、兴趣、工具栈），以及你们之间的互动历史（项目、目标、纠正过的行为）。这三类基本覆盖了 AI 关于你的所有认知。

最后一句“Do not summarize, group, or omit any entries”是防止 AI 偷懒。不让它合并或省略，确保输出完整。

不过说实话，这条提示词也不是万能的。有些 AI 的记忆系统本身就没存多少东西，导出的内容可能很少。也有 AI 会虚构一些它根本没有的条目。所以拿到导出结果后，最好自己过一遍，把不准确的删掉，把遗漏的补上。

如果导出不完整，可以追问一句：“Are there any remaining memories you haven’t listed?” 通常能再挤出几条来。

实操：在不同 AI 中提取记忆

我在几个主流 AI 上都试了一下，表现差异还挺大的。

ChatGPT

导出效果最好，这也在意料之中。ChatGPT 的记忆系统上线最早也最成熟，它会把明确存储的 Memory 条目和对话中学到的隐含偏好都列出来。我自己的账号导出了 30 多条，涵盖了编码偏好、写作风格、常用工具、甚至是我的很多项目经验，还有几条是我之前纠正过它行为的记录。

Gemini 和其他 AI

Gemini 的记忆功能上线比较晚，存的东西可能没那么多。我试了一下，导出的条目只有个位数，主要是一些基本偏好，可能是平时用的也少吧。

如果你使用 AI 客户端的话，可以把你的聊天历史跟这个提示词一起发给 AI，让它帮你提取内存。

而其他的在线 AI 平台大都支持不太好了，甚至豆包直接封禁了这个提示词，说是违反了使用规范。

进阶玩法：给 AI 工具初始化记忆

拿到导出的记忆档案之后，真正有意思的事情才开始。

给 OpenClaw 初始化

如果你在玩 OpenClaw，初始化记忆是一个挺重要的步骤。以前你得手动写一大段关于自己的描述，告诉 OpenClaw 你是谁、习惯什么、偏好什么。现在简单多了。直接在 OpenClaw 的对话里把导出的记忆档案粘贴进去，让它自己消化就行。比如这样开头：

以下是我从 ChatGPT 导出的个人偏好和上下文信息，请记住这些内容：
[粘贴导出的记忆档案]

OpenClaw 会自动把这些信息纳入它的长期记忆，后续对话中就会参考这些偏好。省去了大量冷启动时间。

写进 Claude Code 的 CLAUDE.md

除了养龙虾，你还可以把导出的偏好信息整理后写进~/.claude/CLAUDE.md 或者相关 AI 工具配置目录的 AGENTS.md 中，每次新开会话都会自动加载。比如从导出记忆中提取出编程相关的条目，整理成这样：

## 用户偏好- 编码风格：Go 代码遵循 effective Go 规范，Python 不加类型注解除非要求- 技术栈：Kubernetes、Go、Python，熟悉 Rust- 沟通偏好：用中文回复，技术术语保留英文- 写作风格：简洁平实，不用 emoji，不过度工程化

写在最后

Claude 推出记忆导入功能的背景挺有意思的。最近 QuitGPT 运动闹得不小，短短几天就有 70 万用户退订 ChatGPT。Claude 在这个时间点上线搬家功能，明显是在降低用户的迁移成本。

有传言说 Google Gemini 也在测试类似的导入功能，但做法不同。Claude 导入的是提炼后的记忆条目，你可以选择分享什么。Gemini 导入的是完整的聊天记录，而且明确说会用于模型训练。这两种方式在隐私上的差别还挺大的。

说实话，目前最实用的方案可能还是最简单的：拿提示词提取记忆，存成 Markdown 文件，需要时手动导入。没有复杂的依赖，不需要第三方工具，数据完全在自己手里。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Anthropic 工程师 @trq212 发表的技术长文《Lessons from Building Claude Code: Seeing like an Agent》，文章总结了构建 Claude Code 过程中积累的工具设计方法论，从 AskUserQuestion 工具的三次迭代、Todo 演化为 Task 的背后逻辑，到渐进式披露这个设计模式，信息密度很高。原文链接：https://x.com/trq212/status/2027463795355095314。

正在构建 AI Agent 的人，大都会卡在同一个问题上：该给模型什么工具？

工具太少，Agent 能做的事受限；工具太多，模型反而不知道用哪个，甚至会在不该用的时候乱用。Claude Code 的工程师 Thariq 把这个问题研究了将近一年，陆续更换和迭代了多个工具，最近整理出了一篇总结。我觉得值得认真读，不只是因为这篇文章谈的是 Claude Code，更是因为里面的思路对任何人构建 Agent 都有参考价值。

工具设计的起点：以模型能力为锚

原文里有个简单但容易理解的类比：如果让你解一道难的数学题，你想要什么工具？

纸笔是起点，能手算，但速度慢。计算器快，但要知道怎么使用它的高级功能。最强大的自然是计算机，可以写代码来解，但前提是你会编程。工具的档次不同，能解决的问题就不一样，而且工具必须匹配使用者的能力。

给 Agent 设计工具，逻辑一样。原文的核心观点是：你需要给模型能力匹配的工具，而匹配的标准，来自你对模型能力的观察和理解。这需要持续关注它的输出，看它在哪里卡壳、哪里游刃有余，然后针对性地调整工具设计。

说起来简单，实践里很难。下面这几个案例能说明具体是怎么做的。

AskUserQuestion：三次迭代才找到正解

Claude Code 本来可以直接在对话里问用户问题，但这种自由格式的问答摩擦感很强。Anthropic 想降低这个成本，提升模型和用户之间的信息传递效率。

第一次尝试是在ExitPlanTool 里加一个问题数组，让模型同时输出计划和问题。实现最简单，但逻辑上有个矛盾：如果用户的回答和计划冲突了，模型要不要重新调用ExitPlanTool？这个方案废了。

第二次改输出格式，让 Claude Code 用特定的 Markdown 格式来提问，比如带选项的 bullet list，前端解析后展示成 UI 组件。思路挺好，执行不稳定。Claude Code 会在末尾多写几句话、换一种格式、或者漏掉选项。靠模型自律输出结构化内容，在复杂上下文里根本靠不住。

第三次，单独做了一个工具。Claude Code 可以在任何时候调用，但尤其适合在 Plan Mode 阶段。工具触发时弹出 Modal，展示问题和选项，阻塞 Agent 执行循环，等用户回答完再继续。

这个方案的关键在于把格式约束放进了工具 Schema，而不是寄希望于模型自觉。Claude Code 也更愿意调用这个工具，因为调用动作本身就是结构化的，不需要它猜格式。

这个迭代过程挺有代表性的。很多人以为提示词写清楚，模型就会乖乖按格式输出。真实情况是，这种稳定性在复杂场景下很脆弱。把格式约束建进工具才是根本解法。

Todo 变成 Task：工具要跟着模型一起进化

Claude Code 刚上线时，模型跑着跑着就会忘记自己在做什么。早期的解决方案是TodoWrite 工具，让 Claude Code 开始时列出待办，边做边打勾。为了防止它还是遗忘，每五轮对话插一条系统提醒。

这套机制在当时有效。但在模型能力变强后，新问题来了。

Opus 4.5 不需要频繁提醒，但系统提示的存在让它以为必须严格按 Todo 执行，不能灵活调整计划。模型被工具套住了，而工具反而限制 Claude Code 的能力。同时，子 Agent 协作的场景越来越多，几个 Agent 怎么共享一个 Todo 列表？TodoWrite 完全没考虑这个场景。

于是换成了 Task 工具。Task 支持依赖关系，子 Agent 可以互相通知状态，模型可以修改和删除任务，也可以主动新建。它更像是 Agent 之间的协调机制，而不是单纯的备忘录。

原文里说的这句话我觉得值得记住：“随着模型能力提升，那些原本帮助模型的工具，可能反而开始限制它。定期重新审视之前的假设很重要。”

这不只是 Claude Code 的问题。任何长期运行的 Agent 系统都会面临这个问题，因为你依赖的基座模型在变，但工具往往不会跟着变。

搜索工具：从被动接收到主动探索

最早，Claude Code 用 RAG 向量数据库来给 Claude Code 提供上下文。RAG 快、能处理大量文件，但它需要额外的索引和配置，并且也不够稳定。更重要的是，上下文是你喂给 Claude Code 的，而不是它自己找的。

后来加了Grep 工具，这个变化看起来很小，背后的设计理念转变挺大的。RAG 是外部系统决定 Claude Code 应该看什么，Grep 是让 Claude 自己决定自己需要看什么。模型越来越强，后者效果越来越好。Claude Code 逐渐学会了按需构建自己的上下文。

在 Agent Skills 上，这个思路被正式化为渐进式披露（Progressive Disclosure）。Skill 文件可以引用其他文件，模型可以递归地读取，层层展开。不是一次性把所有信息都摆在模型面前，而是让它按需探索。

一年下来，Claude Code 从基本不会自主构建上下文，进化到能在多层文件里精确找到自己需要的信息。

渐进式披露：不用加工具也能扩展能力

Claude Code 现在大约有 20 个工具，团队经常在自问：它们真的都需要吗？每加一个工具，模型就多一个要考虑的选项，决策负担上升。

比如，用户问 Claude Code 怎么添加 MCP、Slash Command 是什么，Claude Code 可能就答不上来，因为这些信息没在系统提示里。要不要把所有文档塞进系统提示？空间浪费，而且用户很少问这类问题，不值得一直放那儿。

他们的最终解法是做了一个专门的 Claude Code 指南 子 Agent，当你问 Claude Code 关于自身使用的问题时，它会调用这个子 Agent。子 Agent 有详细的搜索策略，知道去哪里找什么，只返回真正需要的答案。

这是渐进式披露的另一个形态：不加工具，而是加子 Agent，把专业问题交给专业的执行者。需要时才激活，不需要时不占用主 Agent 的注意力。

写在最后

给模型设计工具，不只是技术，更是一种艺术，没有一套通用规则，要看用的是什么模型、Agent 的目标是什么、运行环境是什么。

从最简单的方案开始，观察模型在哪里用得好、哪里卡壳，然后针对性地改。工具是模型能力的放大器，模型能力变了，放大器也得跟着换。

有意思的是，这篇文章本身就用了渐进式披露的写法。没有一上来就给结论，而是通过三个迭代案例，让读者自己摸出规律来。作者确实做到了“像 Agent 一样思考”。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

用 Claude Code 做过稍微复杂点的项目的人，应该都有一个共同的经验：新开 Session 后，第一件事不是写代码，而是提供 Context：这个项目是什么，用的什么架构，测试环境有哪些坑，之前约定的命名规范是什么等等。

这些背景情况交代完，快的也要五分钟，慢的可能要十几分钟。然后 Claude Code 说“好的，我理解了”，才终于能开始干活。

这个问题确实让人有点烦。开源社区也有很多人试图通过外挂记忆的方式来解决这个问题，但实际体验都不太好。比如 claude-mem 试图通过捕捉工具使用情况自动生成语义摘要，并把相关信息带到未来会话中。看起来很美好，但实际用起来问题一大堆，安装/依赖复杂不说，内存占用高，查询巨慢，稳定性还极差。

这样的痛点 Claude Code 作者自然也早就看到了。刚刚，Anthropic 工程师 Thariq 发了条公告：Claude Code 正式推出了 auto-memory 功能。简单说，Claude Code 现在能跨 session 记住东西了。你的项目上下文、调试习惯、偏好的解决方案，下次开新会话时自动调取，不需要你手动写任何东西。

Auto Memory 是怎么工作的

机制不复杂。

Claude Code 在你编程过程中，会自动把它认为值得记住的东西写进一个本地文件：

~/.claude/projects/<project-hash>/memory/MEMORY.md

记什么、怎么记？我扒了一下它的系统提示词，完整内容如下：

# auto memoryYou have a persistent auto memory directory at`~/.claude/projects/<project-hash>/memory/`.Its contents persist across conversations.As you work, consult your memory files to build on previous experience.## How to save memories:- Organize memory semantically by topic, not chronologically- Use the Write and Edit tools to update your memory files- MEMORY.md is always loaded into your conversation context — lines after 200 will be truncated, so keep it concise- Create separate topic files (e.g., debugging.md, patterns.md) for detailed notes and link to them from MEMORY.md- Update or remove memories that turn out to be wrong or outdated- Do not write duplicate memories. First check if there is an existing memory you can update before writing a new one.## What to save:- Stable patterns and conventions confirmed across multiple interactions- Key architectural decisions, important file paths, and project structure- User preferences for workflow, tools, and communication style- Solutions to recurring problems and debugging insights## What NOT to save:- Session-specific context (current task details, in-progress work)- Information that might be incomplete — verify against project docs before writing- Anything that duplicates or contradicts existing CLAUDE.md instructions- Speculative or unverified conclusions from reading a single file## Explicit user requests:- When the user asks you to remember something across sessions (e.g., “always use bun”, “never auto-commit”), save it — no need to wait for multiple interactions- When the user asks to forget or stop remembering something, find and remove the relevant entries from your memory files

这里有几个值得注意的设计：

memory 不只是一个文件。MEMORY.md 是主文件，前 200 行自动加载到 prompt 里。但 Claude code 还可以创建debugging.md、patterns.md 这样的主题文件，从 MEMORY.md 链接过去，需要的时候再读取。这有点像一本带着索引页的笔记本，翻到某个主题再看详细内容。

“What NOT to save”这段我觉得挺克制的。大多数人做记忆功能，恨不得什么都往里塞。Anthropic 反过来，先画了条线说哪些东西别碰：临时状态不记、没验证的不记、CLAUDE.md 里已有的不重复记、只看了一个文件就猜的结论不记。

还有”Explicit user requests”那段也挺实用：你可以直接告诉 Claude 以后都用 bun 装依赖或者永远不要自动 commit，它会立刻写进 memory，不需要等多次交互才总结。反过来你说别再记这个了，它也会去找到对应条目删掉。

另外，内存文件存在本地，按项目哈希值隔离。不会上传到云端，不同项目之间也完全独立。

/memory 命令

内存功能的控制中心是/memory 命令。

打开它，你能看到 Claude Code 自己记录的所有内容，可以编辑某一条，可以删掉觉得没用的，也可以整个关掉这个功能。

这个设计我觉得也挺实用的。Claude Code 的判断不一定都准确，它可能觉得某个临时的 debug 方案很重要。但那只是你一次性的权宜之计，没必要永久保留。透明可控，比黑盒记忆要放心得多。

当然，如果你实在不想开启自动记忆，也可以一行命令搞定：

export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

跟 CLAUDE.md 什么关系

用 Claude Code 一段时间的人，大概都写过 CLAUDE.md。你把项目规范、禁止行为、常用命令写在里面，所有会话都生效。

Auto Memory 和 CLAUDE.md 是两件不同的事，完全互补，互不覆盖。

CLAUDE.md 是你主动写给 Claude Code 的规则，记录那些你希望它每次都记住的、不变的约定。Auto Memory 不一样，它是 Claude Code 自己在工作过程中积累的观察，比如项目模式、你的习惯、踩过的坑等等。

两个配合起来的效果最好。可以这样理解：CLAUDE.md 是你写的入职手册，Auto Memory 是它自己记的工作笔记。新员工到岗，先读手册，再翻笔记，然后才真正上手。

几个需要提前知道的问题

说实话，功能本身的设计我觉得没什么可挑的，零配置、透明可控、跟 CLAUDE.md 互补。不过用的时候有几个地方需要注意。

200 行的限制，大项目用久了会碰到天花板。目前的实现是简单的前缀加载，也就是取文件开头 200 行塞进 prompt。不像向量数据库那样能按相关性检索，它就是按顺序读。所以如果 memory 文件积累得多了，靠后的内容实际上不会被加载。

需要养成用/memory 定期整理的习惯，留重要的，删过时的。就像清理浏览器书签，不主动管理就会越来越乱。

另一个问题是过期的记忆。不是所有记下来的东西都应该永久保留。比如你两个月前用了某个临时方案处理一个 bug，现在早就改了。但 Claude 还惦记着旧方案，下次遇到类似问题，再优先往那个方向想就不对了。陈旧的记忆有时候比没有记忆更麻烦。

官方还没给出自动过期或 decay 机制，所以现在还得完全靠手动管理。

不过换个角度想，Anthropic 的选择挺有意思。不用向量数据库，不做复杂的检索增强，就是本地的 Markdown 文件。这跟 Claude Code 一贯的设计哲学一脉相承，能用简单方案解决的，就别上复杂架构。先跑起来，不够再迭代。

说说我自己的感受

功能发布之前，我处理这个问题的方式是：在 CLAUDE.md 里手动把关键的项目背景写进去，然后还要在每次新 session 的第一条消息里补充这次的具体任务背景。

两件事加起来，我其实是在替 Claude Code 充当记忆介质。

比如，有次跑一个长任务，Claude Code 花了大半个小时梳理项目的测试文件。找出了几个有问题的查询接口，还整理出一套处理边界情况的思路。然后上下文窗口到了临界点，触发了自动压缩。下一个 session 接手时，那一套思路就不见了，从头开始分析，之前做的工作重复做了一大半。那半个小时基本白费了。

Auto Memory 解决的就是这类问题。Claude Code 在工作过程中发现的有价值的东西，不应该在 session 结束时消失。

多 Agent 协作的场景里，这个功能的价值可能会更明显一些。一个 Agent 发现了某种边界情况的处理方式，把它写进 memory。下一个 Agent 一开始就能读到，不需要上一个专门提醒。

写在最后

看到 Claude Code 的 Auto Memory，我第一时间想到的是 OpenClaw 的内存设计。

OpenClaw 能两周冲到 10 万星，原因很多，但持久记忆绝对是核心卖点之一。它不只是一个聊聊天就忘的机器人，而是能记住你说过的每一件事，下次提起来直接就知道上下文。这个体验差异太大了，用过的人都回不去。OpenClaw 甚至在 Markdown 记忆之上还加了向量搜索，做成了混合检索，相当于给 Agent 内置了一套 RAG 系统。

Claude Code 的 Auto Memory 走的是更简单的路线：纯本地 Markdown 文件，前 200 行前缀加载，没有向量检索。从功能完备度来说，跟 OpenClaw 的记忆系统还有很大差距。但 Anthropic 的做法一贯如此。先用最简单的方案把核心体验跑通，不够再迭代。

我比较期待的是下一步。200 行的前缀加载很快会碰到天花板，到时候大概率会引入某种形式的语义检索。如果再加上自动过期和记忆质量评估，Claude Code 的记忆系统就真的能跟 OpenClaw 掰手腕了。

相关链接：

• Auto Memory 官方文档：https://code.claude.com/docs/en/memory
• Thariq 的公告：https://x.com/trq212

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

装完 OpenClaw 之后，很多人就拿它聊聊天、写写文案，然后觉得也就那样。

说真的，太浪费了。

OpenClaw 的核心设计不是聊天机器人，而是一个可以帮你执行任务、跑定时任务、自主完成工作的 Agent。它不只是回答你问题，还能帮你干活，编程、写作、跑脚本、调度其他 AI 工具干活，甚至在你睡觉的时候悄悄把明天的工作准备好。

下面分享几个我自己在用的玩法，从简单到复杂，随便挑一个入手。

AI 日报自动生成

这个应该是最简单的使用场景了。你可以让 OpenClaw 帮你自动从指定的技术博客、RSS 订阅源、社交媒体抓取最新内容，AI 打分筛选，每天推一份精选到你的 Slack 或者飞书上。

这种配置以往还需要专门写个程序，然后再去告诉 AI 调用。现在则不需要了，只要告诉 OpenClaw 你想要抓取哪些链接，它就可以帮你自动写好代码，并在需要时问你要相关的 API Key，然后帮你配置好定时任务。

OpenClaw 支持完整的cron 表达式，心跳任务走独立的队列通道，不跟实时消息抢位置。就这点，让定时任务真的靠谱，不会漏发。

让 OpenClaw 调度 Codex 和 Claude Code

这是我最近觉得最有意思的玩法。

OpenClaw 内置了coding-agent Skill，专门用来把编程任务委托给 Codex 或 Claude Code。你跟 OpenClaw 说“帮我用 claude 修复项目中的 xxx bug”，它把任务拆好之后，直接在后台起一个 Codex 或 Claude Code 进程去干，干完了通知你。

OpenClaw 不会一直等着这些结果，而是异步运行这些 Agent，你可以继续聊别的，它在完成后会主动通知你。甚至还可以让多个任务同时跑，不同任务跑在不同的 git worktree，互不干扰。

Codex 的调用方式差不多，把claude 换成codex 就行。这两个编程工具我都在用，各有适合的场景。

不过它这个 Skill 有时候也不太稳定，有时候也很影响效率。后面打算做两个专门的 Codex 和 Claude Code Skill，等稳定了之后再开源出来。

变成你的第二大脑

OpenClaw 天然有持久记忆，你只需要充分利用它。

比如给 OpenClaw 接上 Slack，然后你就可以随时给 Bot 发消息，说记住这个，它就永久存到自己的记忆中了。

如果记忆文件比较多，或者你想接入已有的知识库（比如可以把 Markdown 格式的文档目录直接配置到 OpenClaw 的记忆中），你还可以开启 OpenClaw 的混合检索，在 Markdown 记忆文件之上再加上向量搜索，相当于给 Agent 配了一套 RAG 系统，存进去的东西可以更快检索到。

传统笔记软件的核心矛盾一直是存进去容易，找出来难，而这种 Agent+RAG 系统可能是第一次从根本上解决这个问题。

内容创作工厂

给内容生产装一条流水线，是另一个我觉得很有意思的玩法。

给 OpenClaw 装备三个分工明确的 Agent：研究 Agent 每天自动扫描汇总热点（跟 AI 日报生成一样的逻辑），输出几个有意思的选题；写作 Agent 拿到选题构建大纲，撰写草稿；配图 Agent 根据内容生成封面图和文章配图。把这个流程配置成定时任务，你什么都不做，图文并茂的文章就帮你写好了。

这个模式的关键是每个 Agent 只做一件事，每件事都是一个固定的 workflow。研究 Agent 不管写作，写作 Agent 不管配图，配图 Agent 只看内容生图。上下文干净，输出质量稳定，比塞给一个 Agent 全做强得多。

不过说实话，这个模式实际跑起来并不会很美好。AI 写的初稿质量参差不齐，很多内容还都需要你做大量修改才能符合你的要求。

K8s 安全部署

想让 OpenClaw 7×24 稳定跑起来，最简单是一台 Mac Mini，但如果你本来就有 K8s 集群，容器化放进去更省心。K8s 给它三层保护：容器隔离、网络策略、资源限制。容器不碰宿主机文件系统，Network Policy 只放行外部 API 出口、挡住内网，资源上限防止失控吃算力。

我自己维护了一个 Helm Chart：feiskyer/openclaw-kubernetes，内置了 LiteLLM 作为模型网关。API Key 统一管在网关层，OpenClaw 只知道本地的 LiteLLM 地址，拿不到真实密钥，这样就算哪个 Skill 出问题也泄不出去。一条命令部署：

helm install openclaw oci://ghcr.io/feiskyer/openclaw-kubernetes/openclaw\ --create-namespace --namespace openclaw\ --set secrets.openclawGatewayToken=$gatewayToken\ --set secrets.telegramBotToken=$telegramBotToken

一个安全细节要注意，OpenClaw 的 Web 前端没有任何认证，千万不要直接暴露到公网上。正常使用，接入 Telegram、Slack 之类的聊天工具，在聊天工具中给 OpenClaw 发指令也完全不需要把 GateWay 公开。

玩法灵感库

如果看完这些还是不知道从哪入手，GitHub 上有个awesome-openclaw-usecases 仓库，收集了 30 个已验证的真实用例，也可以去看看，找找灵感。

几个让我印象深的案例：

语音确认出席。活动前让 OpenClaw 依次拨打每个嘉宾的电话，通过 AI 语音对话确认到场情况，最后汇总成一份报告。用的是 Telnyx 的语音接口，整个流程零人工介入。

Reddit→MVP 流水线。用Last 30 Days 这个 Skill 挖掘 Reddit 和 X 上最近一个月的真实用户吐槽，整理出痛点，然后让 OpenClaw 直接写一个 MVP。比如，研究 OpenClaw 的用户反馈，发现“初始配置太难”是高频问题，Agent 直接就做了一个配置向导 Web 应用出来。

AI 收益追踪。每次科技公司财报前自动准备摘要，财报后推送分析和对比，永远不会漏掉关注的公司。

写在最后

说到底，OpenClaw 能干多少事，取决于你给它配了多少 Skills、设计了多少 cron 任务。它就像一个本来什么都不会但极其听话的员工。你得先告诉它能用什么工具、怎么做事，它才会越来越有用。

Skills 生态现在挺成熟了。官方的ClawHub 上架了 1 万多个 Skill，直接clawhub install <skill-name> 一条命令就可以安装。VoltAgent/awesome-openclaw-skills 是社区维护的精选列表，按分类整理了数千个 Skill，找灵感比直接搜 ClawHub 更快。

当你碰到问题时，不妨到这里搜一搜，说不定就能找到你想要的。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 OpenAI 开发者博客《Shell + Skills + Compaction: Tips for Long-Running Agents》，由 Charlie Guo 撰写，发表于 2026 年 2 月 11 日。本文在翻译基础上做了整理和补充。

用 Agent 做过稍微复杂一点任务的朋友，应该都碰到过这几个问题：跑着跑着上下文爆了，中间结果没地方存，任务流程每次都要从头描述一遍。

这些问题说白了就是一个核心矛盾：Agent 要做的事越来越重，但它的“工作记忆”和“工具箱”还停留在对话级别。

OpenAI 最近发了一篇实践指南，专门聊怎么用三个互相配合的能力来解决这些问题：Skills、Shell Tool 和 Compaction。

我自己在 Claude Code 和 Codex 上都用过类似的机制，读完这篇觉得有几个点挺实用，整理分享一下。

三个核心概念

先把这三个东西分别说清楚。

Skills：可复用的指令包

Skills 本质上是一组带版本控制的指令文件，核心是一个SKILL.md 清单文件，里面写着这个技能是干什么的、什么时候该用、怎么用。你可以把它理解成给 Agent 准备的操作手册，平时不用的时候不占上下文，需要的时候按需加载。

这个概念其实来自 Anthropic。Anthropic 在 Claude Code 上早就实现了类似的机制，Codex CLI 后来也跟进了。OpenAI 这次把它的 API 也标准化了，对齐了 Agent Skills 开放标准。平台会把每个 Skill 的名字、描述和路径暴露给模型，让模型自己决定什么时候调用。

我自己用 Claude Code 的 Skills 已经有一段时间了，体验下来最大的好处就是：把那些重复性的工作流固化下来，不用每次都在 Prompt 里写一遍。

Shell：真正的执行环境

Shell Tool 给 Agent 提供了一个真实的终端环境，可以是 OpenAI 托管的容器，也可以是本地运行时。在这个环境里，Agent 可以安装依赖、跑脚本、生成文件，而且有受控的网络访问权限。

这跟简单的代码执行还是有本质区别的。举个例子，你让 Agent 分析一个 CSV 数据集，它可以在 Shell 里先pip install pandas matplotlib，然后写一段 Python 脚本做数据清洗和可视化，最后把生成的图表存到/mnt/data/ 目录。整个过程不需要你提前配环境，Agent 自己就能搞定。

两种模式（托管容器和本地运行）通过 Responses API 保持了统一的工具语义。开发阶段在本地快速迭代，上线后切到托管容器做隔离，API 调用方式是一样的：

response= client.responses.create( model="gpt-5.2", tools=[{"type":"shell","environment": {"type":"container_auto"}# 本地模式改成 "local" }], input="Install pandas, fetch the CSV from S3, and generate a summary report")

这样做的好处是，本地开发和生产环境的切换只需要把environment 类型从container_auto 改成local。

Compaction：上下文不够用怎么办

长时间运行的 Agent 最头疼的问题就是上下文窗口不够用。跑了几十轮工具调用之后，前面的对话内容就被挤出去了，Agent 就可能开始断片。

Compaction 就是解决这个问题的。它有两种方式：一种是自动压缩，在context_management 里设个阈值，上下文超了就自动触发；另一种是通过/responses/compact 接口手动压缩：

# 方式一：自动压缩，上下文超过阈值时服务端自动触发response= client.responses.create( model="gpt-5.2", input=conversation, context_management=[{"type":"compaction","compact_threshold":200000}],)# 方式二：手动压缩，显式调用 compact 接口compacted= client.responses.compact( model="gpt-5.2", input=long_conversation_items,)

核心思路都是把之前的对话历史压缩成摘要，保留关键信息，释放上下文空间。

这个功能的关键在于心态转变，也就是不要把 Compaction 当成上下文快爆了才用的应急措施，而是从一开始就把它作为默认实践。设计任务流程的时候就考虑好：容器要复用，previous_response_id 要传递，压缩要常态化。

五条实践建议

概念说完了，来看具体怎么用好这些能力。OpenAI 在文章里给了几条实操建议，结合我自己的使用经验一起聊聊。

Skill 的描述就是路由逻辑

很多人写 Skill 描述的时候，只写了这个 Skill 是干什么的，这远远不够。描述要能回答三个问题：什么时候该用它、什么时候不该用它、用完之后期望的输出是什么。

具体来说，要写明 Use when 和 Don’t use when 两类场景。举个例子，一个数据分析 Skill 的描述可能是这样的：

# Data Analysis SkillUse when:- User provides a dataset and asks for trends, patterns, or insights- User needs charts or visualizations from raw dataDon't use when:- User asks a simple statistical question (e.g., "what's the average of X")- User just needs data formatting or conversion

不只写用于分析数据集，还要明确告诉模型什么时候不需要大费周章地调用这个 Skill。

反面案例比正面案例更重要

OpenAI 的测试数据显示，光有 Skill 不写反面案例，正确调用率反而会下降大约 20% 。加上什么时候不该用的说明后，路由准确性才恢复并提升。

这个发现挺有意思的。模型看到一个新工具，本能反应是有锤子就找钉子。如果你不明确告诉它边界在哪，它会倾向于过度使用。

模板放在 Skill 里，别放 System Prompt

这条建议很实用。很多人习惯把示例和模板直接塞进 System Prompt 里，结果不管当前任务用不用得上，每次对话都要消耗这些 token。

把模板放在 Skill 内部，效果是不用时基本免费。只有模型决定调用这个 Skill 的时候，模板内容才会被加载进上下文。这对 token 消耗的优化是巨大的，也是 Skill 最大的优点。

需要确定性的时候，别让模型自己选

自动路由在大多数场景下够用了。但在生产环境中对确定性要求高的流程里，最好直接告诉模型用某某 Skill，别让它自己判断。

这就把模糊的路由变成了明确的指令。特别是在多步骤工作流中，每一步用哪个 Skill、按什么顺序执行，都应该在编排层面写清楚，不留给模型自由发挥的空间。

网络安全不能马虎

Skill 加上网络访问权限，等于给 Agent 开了一条可以往外发数据的通道。网络安全这事不能大意。

安全策略说白了就是两层白名单：组织级白名单划定最大范围，请求级白名单只能在这个范围内再缩小。两层都要尽量收紧。

另外一个关键点是，模型绝对不能看到明文凭证。OpenAI 搞了个domain_secrets 机制，在 Skill 里写占位符（比如Authorization: Bearer {{API_KEY}}），实际的密钥只在请求发往白名单里的目标地址时才替换进去。思路跟环境变量注入差不多，但多了目标地址校验。

三种构建模式

OpenAI 还总结了三种递进的构建模式，从简单到复杂，适合不同阶段的需求。

基础模式：安装 → 获取 → 写入

最简单的用法：让 Agent 在 Shell 里安装依赖、拉取外部数据、把结果写到/mnt/data/ 目录。

/mnt/data/ 相当于一个约定好的交付目录，Agent 生成的需要人来审查或者给下游用的文件都放这里。这样做的好处是划清了 Agent 的工作区和最终交付物的界限，后续取用和审查都方便。

工作流模式：Skills + Shell 联动

把重复性工作流封装成 Skill，挂到 Shell 环境里，让 Agent 按固定流程跑。

这种模式特别适合数据处理类任务。拿数据集清洗来说，你可以在 Skill 里定义好标准流程：先检查缺失值比例，超过阈值的列直接丢掉；然后做类型推断和格式标准化；最后输出清洗报告到/mnt/data/。Agent 每次拿到新数据集，都按这个流程走，不用你重复描述一遍。

企业级模式：Skills 作为活的 SOP

到了企业场景，Skills 就不只是技术工具了，而是变成了活的 SOP。公司的业务流程改了，对应的 Skill 跟着更新，Agent 的行为自动对齐，不用重新调参。

OpenAI 提到了 Glean 的早期落地案例：用了这种模式之后，准确率从 73% 提升到 85% ，首次响应延迟降低了 18.1% 。挺有意思的一点是，给 Agent 结构化的指导，不仅提高了质量，还加快了速度。模型不用花那么多 token 去想该怎么做，直接按 Skill 里的步骤走就行了。

写在最后

回过头来看，OpenAI 这篇文章的核心观点其实就一个：长时间运行的 Agent 需要从单次对话的思维模式升级到持续工作流的思维模式。

Skills 解决怎么做的问题，把经验固化成可复用的指令。Shell 解决在哪做的问题，提供真实的执行环境。Compaction 解决记不住的问题，让 Agent 在长任务中保持连贯。

这三个能力并不是 OpenAI 独有的。Claude Code 的 Skills 和 SubAgent、Codex 的 Shell 执行和 Exec Plan，本质上都在解决同样的问题。各家的具体实现不同，但方向是一致的：让 Agent 从聊天助手进化成能持续干活的工作伙伴。

如果你正在做 Agent 相关的开发，有几个建议：先把最常用的工作流封装成 Skill，别急着做通用的。Shell 环境从本地开始，跑通了再考虑容器化。Compaction 从第一天就用上，别等上下文爆了再补救。

原文链接：https://developers.openai.com/blog/skills-shell-tips

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

大多数人用 AI 编程助手，还是一对一模式，也就是你发指令，AI 写代码，来回对话直到任务完成。但实际上，随着 Kimi K2.5 以及 Claude Opus 4.6 的发布，AI 已经学会组队了。

比如，Anthropic 发布的 Agent Team 功能，可以让多个 Claude Code 实例可以像真正的开发团队一样并行协作。一个 Agent 当技术负责人，负责规划和分配任务；其他 Agent 当开发组员，各自拿着独立的上下文窗口埋头干活。

这几天也在密集体验了这个功能，并且深挖了它背后的系统提示词设计。今天的文章就从原理到实战到踩坑，把 Agent Team 这件事讲清楚。

一句话理解 Agent Team

你可以把 Agent Team 想象成一个软件开发团队的分布式架构。

• 以前是单体应用，一个 Claude Code 单线程干所有事情，上下文窗口就是它的内存，窗口满了就得压缩（当然压缩就意味着丢掉某些信息）。
• 现在是微服务，一个 Lead Agent 当负责人，多个 Teammate Agent 当专业工程师。每个 Teammate 有自己的独立上下文窗口，互不干扰，但可以通过消息系统通信，并通过共享任务列表协调进度。

Agent Team 的好处很明显，每个 Agent 的上下文窗口更聚焦单个任务，可以更专注地处理自己负责的部分；并行多个 Agent 执行也大大加快了整体任务的推进速度。

Agent Team 乍看起来跟 SubAgent 比较像，但一用起来就可以发现它们明显不一样：SubAgent 只能向主 Agent 汇报结果，相互之间不能通信；而 Teammate Agent 则可以互相直接通信，用户也可以直接跟任何一个 Teammate Agent 对话。它们的详细对比如下表格所示：

Agent Team 的架构设计

我相信你已经看过不少关于 Agent Team 的文档了，但它们大多停留在功能介绍层面。这里我换个角度，直接看它的系统提示词，从底层分析 Anthropic 是怎么设计这套多 Agent 协作机制的。

如图所示，整个 Agent Team 由四个核心部分组成：

Team Lead（团队负责人）

Team Lead 就是你正在交互的那个主 Claude Code 会话。它通过TeamCreate 工具创建团队，通过Task 工具创建 Teammate，通过SendMessage 工具发消息，通过TaskCreate/TaskUpdate 管理任务列表。

从系统提示词来看，Anthropic 对 Lead 的定位就是管理 Agent 团队（或者叫 Agent 集群）：

Use this tool proactively whenever the user explicitly asks to use a team, swarm, or group of agents, or a task is complex enough that it would benefit from parallel work.

注意这里有个 proactively，这说明 Lead 会主动判断任务是否值得开团队，而不总是等着你明确要求。

Teammate（团队成员）

每个 Teammate 是一个完全独立的 Claude Code 实例。它们在创建时会加载项目的 CLAUDE.md、MCP servers 和 Skills，但不会继承 Lead 的对话历史。这是个有意思的取舍，用上下文隔离换来了团队成员的执行效率。

系统提示词中有一条关键规则：

IMPORTANT for teammates: Your plain text output is NOT visible to the team lead or other teammates. To communicate with anyone on your team, you MUST use the SendMessage tool.

这里说明，Teammate 的独白不会被任何人看到，必须通过消息工具显式通信。这就像一个开发团队里，你在自己电脑上嘟囔的话同事听不到，得发 Slack 消息才行。

Task List（共享任务列表）

任务列表存储在~/.claude/tasks/{team-name}/ 目录下，所有成员都可以访问。任务有三种状态：pending、in_progress、completed。任务之间可以设置依赖关系，被依赖的任务没完成时，下游任务就不能被领取。

系统提示词里对任务协调有明确的指导：

Teammates should check TaskList periodically, especially after completing each task. Claim unassigned, unblocked tasks with TaskUpdate. Prefer tasks in ID order (lowest ID first).

任务领取用的是文件锁机制来防止竞争条件，确保多个 Teammate 同时抢同一个任务时不会冲突。

Mailbox（消息系统）

通信机制支持三种消息类型：

• message：点对点私信，发给特定 Teammate；
• broadcast：广播消息，发给所有人，成本较高（Broadcasting is expensive. N teammates = N separate message deliveries）；
• shutdown_request /shutdown_response：优雅关停协议，Teammate 可以拒绝关停（比如“我还在处理任务 #3”）。

这里还有一个很重要的设计：plan_approval_response。Lead 可以要求 Teammate 在做之前先写计划，Lead 审批通过后才允许执行，进一步保证了 Teammate 任务执行的质量。

快速上手

Agent Team 目前还是实验性功能，默认关闭。想要开启，需要在~/.claude/settings.json 中添加：

{"env": {"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS":"1" }}

或者直接设置环境变量：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

你的第一个 Agent Team

启用后不需要学任何新命令。直接用自然语言告诉 Claude Code 你想要一个团队：

创建一个 Agent Team 来审查 PR #142。
三个审查员分别从安全、性能、测试覆盖率三个角度审查，
最后综合出一份报告。

Claude Code 会自动创建团队、分配任务、等待结果、综合报告。整个过程你只需要发一条消息。

选择显示模式

Agent Team 支持两种显示模式：

• in-process 模式（默认）：所有 Teammate 运行在主终端内。用Shift+Up/Down 切换 Teammate，直接跟任何一个对话。这种模式比较通用，能在任何终端中使用。
• split-pane 模式：每个 Teammate 独占一个终端面板。需要 tmux 或 iTerm2。

我个人建议先用默认的 in-process 模式入门，等熟悉了再考虑 split-pane。split-pane 看起来很酷，多个面板同时输出，但不支持 VS Code 内置终端、Windows Terminal 和 Ghostty 等等。

一个实际的使用场景

比如你想重构一个模块，可以这样分配：

创建一个 3 人团队来重构 src/auth/ 模块：
- 一个 Teammate 负责重构核心认证逻辑
- 一个 Teammate 负责更新所有相关测试
- 一个 Teammate 负责更新 API 文档
每个人只改自己负责的文件，不要动其他人的代码。

注意最后的“每个人只改自己负责的文件”，这句不可缺少。后面也会讲到，文件冲突是 Agent Team 最大的坑。

进阶技巧

Delegate Mode：让 Lead 专注当项目经理

默认情况下，Lead 会忍不住自己动手写代码。这就像一个技术 Lead 说好了只做 code review，结果控制不住就自己上手改了。

解决方法是按Shift+Tab 切换到 Delegate Mode。在这个模式下，Lead 只能使用协调类工具，不能读写文件、执行命令，强制它做一个纯粹的管理者。

Plan Approval：先审方案再执行

对于高风险任务，可以要求 Teammate 先写方案：

spawn 一个架构师 Teammate 来重构数据库层。
要求它先写方案，我审批后再动手。

Teammate 会进入 plan mode，用只读工具探索代码库、设计方案。方案完成后发给 Lead 审批。Lead 可以批准或驳回并附上反馈。Teammate 收到反馈后修改方案，重新提交。

用 Hooks 做质量门禁

Claude Code 的 Hooks 机制可以用来在 Agent Team 中强制执行质量标准：

• TeammateIdle Hook：Teammate 准备空闲时触发。如果 exit code 为 2，会发送反馈让 Teammate 继续工作。可以用来检查测试是否通过、代码是否 lint 干净等。
• TaskCompleted Hook：任务被标记完成时触发。Exit code 2 阻止完成并发送反馈。可以用来做自动化的完成标准检查。

直接跟 Teammate 对话

每个 Teammate 都是完整的 Claude Code session。你可以随时绕过 Lead，直接跟任何 Teammate 对话：

• in-process 模式：Shift+Up/Down 选择 Teammate，输入消息；
• split-pane 模式：直接点击对应的面板对话。

这在 Teammate 跑偏时特别有用，直接纠正它，不需要通过 Lead 传话。

避坑指南

Agent Team 毕竟才刚刚发布，还有不少问题。以下是几个我碰到的踩坑经验，供你在使用时参考。

文件冲突是最大的坑

多个 Teammate 同时编辑相同文件，导致文件内容覆盖丢失，这是最容易碰到的问题。这个问题是因为 Agent Team 的任务列表有文件锁，但文件写入本身没有锁机制。

解决的思路是在分配任务时划清文件所有权。比如 Teammate A 只改src/auth/，Teammate B 只改tests/auth/，绝不交叉。用任务依赖确保共享文件只有一个写入者。这也是为什么前面那个重构例子里特别强调每个人只改自己负责的文件。

Lead 和 Teammate 都可能失控

Lead 有个毛病，会忍不住自己动手写代码，不愿意把活分给 Teammate。解决方法是用 Delegate Mode（Shift+Tab）强制限制它只能做协调，或者在提示词中明确说“你不要自己写代码”。

Teammate 则容易跑偏。比如让它只审查安全问题，结果它顺手重构了代码风格；或者让它改测试，结果它跑去改了实现代码。这个问题实际上一直都是 Claude 模型的问题，缓解方法是 PLAN 先审方案再执行：

Spawn an architect teammate to refactor the authentication module.Require plan approval before they make any changes.

另外，在后续执行过程中发现跑偏了也要及时纠正。这个要人眼来盯着了，所以任务颗粒度最好不要过大。

Token 消耗不容忽视

每个 Teammate 是独立 Claude 实例，5 人团队约 5 倍 token 消耗，PLAN 模式下更可以达到 7 倍。

建议从 2-3 个 Agent 开始，别上来就开 10+ 个 Agent。可以给 Teammate 用 Sonnet 而不是 Opus（Create a team with 4 teammates. Use Sonnet for each teammate.），只在真正需要并行的场景才动用 Agent Team。

Teammate 的失忆问题

Teammate 只加载 CLAUDE.md、MCP servers 和 Skills，不继承 Lead 的对话历史。它不知道你之前跟 Lead 聊了什么。所以一开始的提示词必须包含充分的上下文。

不要说“继续刚才的工作”，要说审查 src/auth/ 目录下的认证模块，重点关注 JWT token 处理和 session 管理，应用使用 httpOnly cookies 存储 token：

Spawn a security reviewer teammate with the prompt: "Review the authentication moduleat src/auth/ for security vulnerabilities. Focus on token handling, sessionmanagement, and input validation. The app uses JWT tokens stored inhttpOnly cookies. Report any issues with severity ratings."

更麻烦的是/resume 和/rewind 不能恢复正在运行的 Teammate。会话中断后，Lead 会尝试给已不存在的 Teammate 发消息，只能重新创建。这意味着长时间运行的任务有较高的中断风险，建议拆成较短的分步执行。

协调本身的问题

除了 Token，多 Agent 协作还有一些琐碎的协调开销。Teammate 有时候忘记把任务标记为已完成，导致下游任务一直被阻塞，这时候得手动检查或者让 Lead 去催。关停也不是即时的，Teammate 会先完成当前的工具调用才响应关停请求，如果它正在跑测试套件，可能需要等很久。另外 Teammate 的权限请求会通过 Lead 频繁打断你的操作，建议提前在权限设置中批准常用操作。

别指望 Agent Team 自觉保证质量

没有验证流程的话，AI Agent 一个常见的问题是声称任务已完成但实际上并没有，而是输出一个差不多的结果就交差了。

解决方法是通过TaskCompleted Hook 添加自动验证，比如要求任务完成时必须测试通过。当然，最重要的是，对关键任务一定要人工审查。

什么时候该用，什么时候不该用

一个更实用的判断标准是：如果你要做的事情可以自然地拆成 2-3 个互不依赖的子任务，而且每个子任务涉及不同的文件集合，那就适合用 Agent Team。反过来，如果任务本身就是串行的，或者多个步骤都需要改同一批文件，那单会话或 SubAgent 更合适。

如果你是第一次尝试，建议从不需要写代码的研究/审查任务开始。比如让三个 Teammate 从不同角度审查一个 PR，或者让它们分别调研一个技术方案的不同方面。这些任务没有文件冲突的风险，先感受一下多个 Agent 同时干活是什么体验。

写在最后

Agent Team 把团队协作这件事搬到了 AI 编程领域，消息系统、任务依赖、文件锁、优雅关停、计划审批这些机制都借鉴了真实的软件开发团队协作经验。Agent Team 一经发布，确实让不少人（包括我自己）感到惊艳，这无疑又是一个重要的 AI Agent 设计范式，估计其他 AI 大厂也要很快跟进了。

但要注意，Agent Team 还在早期阶段，文件冲突、会话恢复、Token 消耗等等问题还待解决，在使用过程中要注意绕开这些坑。你也可以使用 kieranklaassen 发布的 Swarm 编排 SKILL，让 Claude Code 帮你设计编排 Agent Team。

相关资源：

• Claude Code Agent Team 官方文档：https://code.claude.com/docs/en/agent-teams
• Anthropic Engineering Blog - Building a C compiler：https://www.anthropic.com/engineering/building-c-compiler
• Hacker News 讨论帖：https://news.ycombinator.com/item?id=46743908
• kieranklaassen 的 Swarm 编排 SKILL：https://gist.github.com/kieranklaassen/4f2aba89594a4aea4ad64d753984b2ea

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

上周的 [[history/2026-01-30-OpenClaw 极简部署指南.md|OpenClaw 极简部署指南]] 帮很多人在本地跑起了 OpenClaw。不过毕竟还是本地部署，需要开着电脑才能使用。想要 7x24 咋办呢？答案当然是 Kubernetes。

今天这篇文章就教你用 K8s 把 OpenClaw 部署成真正稳定的、全天候在线的服务。

部署 OpenClaw

部署前需要准备两个必需的信息。首先是 Telegram bot token。打开 Telegram 找 @BotFather，发送/newbot 创建一个新的 bot，然后保存好 token：

export telegramBotToken="<你的-telegram-bot-token>"

然后生成一个网关 token，这个是用来访问 OpenClaw Web UI 的：

export gatewayToken=$(openssl rand -hex 32)

现在可以部署了。用 Helm 直接安装我打包好的 Helm chart：

helm install openclaw oci://ghcr.io/feiskyer/openclaw-kubernetes/openclaw\ --create-namespace --namespace openclaw\ --set secrets.openclawGatewayToken=$gatewayToken\ --set secrets.telegramBotToken=$telegramBotToken

这条命令会在 openclaw 命名空间里创建一个 StatefulSet，运行 OpenClaw 的网关服务。等几分钟让 Pod 启动。

验证部署。跑：

kubectl get pods -n openclaw

看到openclaw-0 的 STATUS 是 Running，说明成功了。

然后暴露服务。最简单的方式是端口转发：

kubectl port-forward -n openclaw openclaw-0 18789:18789

打开浏览器访问http://localhost:18789/?token=$gatewayToken，就能进入 OpenClaw 的 Web UI 了。到这里就成功部署了。

如果后面想升级到新版本，用 helm upgrade 命令。想删除的话用 helm uninstall。

怎么使用免费的 LLM 模型？

部署成功后，进入 OpenClaw 的 Web UI，或者在容器内运行 onboard 命令重新配置：

kubectl -n openclaw exec -it openclaw-0 -- node openclaw.mjs onboard

选择 QWen 或 OpenCode Zen 作为提供商，OAuth 登录，然后从列表中选择免费模型即可。

怎么修改 OpenClaw 的配置？

部署后想改配置的话，也是用 kubectl 命令进入容器修改：

kubectl -n openclaw exec -it openclaw-0 -- node openclaw.mjs onboard

这个命令会以交互式提示让你重新配置 AI 提供商、Telegram bot 连接、Discord 或其他集成等。修改完成后的配置会保存在 PV 中，这样 Pod 重启也不会丢失。

怎么授权 Telegram 用户？

OpenClaw 部署成功后默认不允许任何人使用。在 Web UI 里进入 Channel → Telegram，配置 Allow From 来添加允许的用户 ID。你可以给 @userinfobot 发消息来查询自己的 Telegram 用户 ID。

怎么加入 Moltbook 社区？

向 OpenClaw 发送以下提示：

Read https://moltbook.com/skill.md and follow the instructions to join Moltbook

OpenClaw 会引导你完成加入社区的所有步骤。

升级和回滚

升级到新版本：

helm upgrade openclaw oci://ghcr.io/feiskyer/openclaw-kubernetes/openclaw\ --namespace openclaw\ --set secrets.openclawGatewayToken=$gatewayToken\ --set secrets.telegramBotToken=$telegramBotToken

照着上面的步骤来就行。如果遇到问题，欢迎到 Github 提 issue，或者提 PR 修复。

相关资源

• OpenClaw 官网https://openclaw.ai/
• OpenClaw Helm Chart 仓库https://github.com/feiskyer/openclaw-kubernetes
• 前文：[[history/2026-01-30-OpenClaw 极简部署指南.md|OpenClaw 极简部署指南]]

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

前几天跟一个朋友吃饭，聊到 AI 编程，他突然来了一句：“我现在离开 Claude Code 写个 for 循环都要想半天。”

我当时笑了，回来路上越想越不对劲，这说的不就是我吗？

上周有要改个小脚本，我习惯性地打开 Claude Code，然后意识到这玩意儿就十来行，犯不着。于是关掉，自己写。结果卡在 Python 语法格式上，愣是想了快一分钟，最后还是搜索了一下才知道怎么写。这要搁一年前，闭着眼都能敲出来。

一个反直觉的研究发现

Anthropic 前段时间做了一项挺有意思的研究。他们找了 52 名软件工程师（都是刚入门的初级工程师），随机分成两组做关于学习 Python 异步编程库 Trio 的对比实验。一组用 Claude Code 辅助学习，另一组保持传统方式。

结果挺意外的。用 AI 辅助的那组，对新知识的掌握程度显著下降了，测试得分比传统方法组低了 17% 。

这个数据一出来，估计很多人的第一反应是“AI 让人变笨了”。但真相没这么简单。

研究人员深挖了一下，发现 AI 辅助组内部不同人的差异其实很大。有些人用 AI 学得特别好，成绩甚至超过了对照组的平均水平。造成这些差异的根源不在于用不用 AI，而是怎么使用 AI。

两种截然不同的使用模式

再把 AI 辅助组分成不同的人群，低分群和高分群的 AI 使用方法明显不同：

低分群有个共同特点，是把 AI 当成了“答案机”。遇到问题就扔给 AI，等答案出来直接复制粘贴，就完事了。整个学习过程基本就是 AI 写代码，他们在当搬运工。

而高分群则不同，他们的 AI 用法完全不同：他们会让 AI 解释代码，追问为什么要这样写，有没有其他方案。有时候故意先自己试着写，写错了再让 AI 指出问题在哪。AI 在他们手里不是代工，更像是个老师。

调试能力的差距最大

再进一步分析，还有个细节值得注意。在代码阅读、问题调试以及概念性问题这三个测试维度中，调试能力的差距最大。

这也挺好理解的。问题调试对人的要求最高，需要真正搞明白代码在干什么、为什么出错、怎么修复等。这些能力只能通过自己动手踩坑来练，靠 AI 代写根本不行。

我相信很多人都有类似的体会。对于自己一行一行敲出来的代码，出了 bug 之后凭直觉就能很快定位问题的大概位置；而对于别人或者 AI 写的代码，即便之前在合并的时候做过 Code Review，也需要花更长的时间去理解和定位。

巧合的是，AI 大神Karpathy 前几天也说过类似的话。Karpathy 承认，他已经注意到自己手写代码的能力正在逐渐退化。生成代码和理解代码在大脑中属于两种不同的能力。主要原因在于编程涉及大量语法细节，虽然手写代码变得困难，但阅读代码依然没有障碍。

问题不是 AI，是使用方式

聊到这儿可能有人会问了。照这么说，AI 编程工具还能不能用了？

当然能用，并且必须得用！但关键是怎么用。

我总结了几个我自己在用的方法，希望能够给你提供一些参考。

1. 让 AI 多解释，少直接给答案。 每次 AI 给出代码后，不急着复制粘贴。先问它为什么这样写，有没有其他方案，这样写的优缺点是什么。把交互模式从“AI 给答案无脑接受”变成“AI 提供思路，你做决定”。Claude Code 有个 Learning 模式就是专门为学习新技术设计的，可以利用起来，开启方法是/output-style 然后选择 Learning。

2. 定期关掉 AI，自己动动手。 每周抽一点时间，不借助 AI 辅助，自己写点代码，重温之前掌控代码的感觉。

3. 把 AI 当结对伙伴，而不是外包。 结对编程的核心是两个人一起思考，一个写一个看，交替角色。用 AI 编程也可以跟 AI 一起做设计、一起编程。AI 写完你审查，发现问题你来改，或者让 AI 解释为什么这样写。当然，这种模式比纯委托累多了，但学习效果和最终代码质量要好很多。

4. 遇到问题先自己想一想。 遇到问题时，不要马上就去问 AI。先自己想一想，有了初步思路之后，再让 AI 帮你分析和完善。这几分钟的思考/挣扎非常重要，适度的挑战有助于加深记忆和理解。如果总是让 AI 直接给出答案，大脑就没法经历“挣扎-顿悟”的过程，学习效果会大打折扣。

写在最后

最后，给程序员们提几个小建议，希望对你有所帮助。

刚工作没几年的同学，老实说风险最大。基础还没打牢呢，就开始全用 AI 写代码了，很容易变成知其然而不知其所以然。我的极客时间课程留言中也看到很多类似的情况，很多很简单的问题不知道怎么排查，明显就是没有掌握背后的原理。所以，在用好 AI 编程的同时，也要注意借助 AI 积累经验。

工作几年之后，情况不太一样。基本功有了，用 AI 反而能加速学习新东西。我自己是后端出身，前段时间居然也搞起了一个前端的 VSCode 插件，靠着 AI 确实省了不少踩坑的时间。不过原来擅长的领域，倒也是真的退化了，这个需要以后注意。

至于干了很多年的老程序员，我觉得可以更大胆地把重复劳动交给 AI，腾出时间做架构设计、技术评审这些事。但话说回来，Karpathy 那种级别的大神都说自己手写代码能力在退化，咱们也别太自信。偶尔脱离 AI 写写代码，保持一下手感，没坏处。

相关资源

• Anthropic 研究原文https://www.anthropic.com/research/AI-assistance-coding-skills
• Claude Learning Mode 文档https://docs.anthropic.com/en/docs/learning-mode
• Karpathy 的编程转型实录https://x.com/karpathy/status/2015883857489522876

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

最近公众号总能看到 Clawdbot/Moltbot/OpenClaw 这个东西。两周冲到 10 万星，增速有点离谱。

有意思的是，这三个名字都是同一个项目，它在一个月内改了三次名字。先是叫 Clawdbot，因为和 Claude 太像被 Anthropic 律师函警告；然后社区投票改成 Moltbot，取名蜕皮的意思；到今天又改成了 OpenClaw，既保留了龙虾吉祥物的梗，又强调了开源属性。OpenClaw 的作者 Peter Steinberger 调侃，这可能是改名最频繁的开源项目。

今天这篇文章就带你一起看看，怎么用既安全又省钱的方式把它玩起来。

OpenClaw 是什么？

OpenClaw 是一款本地运行的 AI Agent，支持连接常用聊天工具，比如 WhatsApp、Telegram、Discord、Slack 和飞书等等。

普通聊天机器人记性差，聊完就忘。OpenClaw 不一样，它有长期记忆，能读写文件、执行终端命令、操作浏览器、收发邮件。结合社区丰富的 Skills，它几乎可以接管你在电脑上的所有操作。

OpenClaw 完全开源，所有数据都存储在本地，隐私可控。官方 Slogan 是：Your assistant. Your machine. Your rules。

因为 OpenClaw 需要独立的计算机环境+ 24 小时运行，许多人专门购买 Mac mini 作为专属服务器，也因此带火了 Mac mini。

当然，OpenClaw 也有很多争议，狂烧 AI Token、大量安全漏洞、随意操作计算机环境、容易被恶意软件诱导利用等等问题导致 OpenClaw 并不推荐直接部署到主力设备上。所以，我建议你只在虚拟机或者容器等独立安全的环境中使用。

接下来，看看如何部署一套你自己的 OpenClaw。

虚拟机环境准备

Lima（Linux/macOS）

Lima 是个轻量的 Linux 虚拟机管理工具，让你可以在 macOS 或 Linux 方便创建和管理虚拟机。Lima 的安装使用也比较简单：

brew install limalimactl create --name=default template://dockerlimactl start default

启动后用limactl shell default 进入虚拟机。

OrbStack（macOS）

OrbStack 是 macOS 上更现代的选择，最初是 Docker Desktop 的轻量级替代，后来也支持创建和管理虚拟机了。

brew install orbstack# 创建一个 Ubuntu 虚拟机orb create ubuntu botvm# SSH 登录虚拟机ssh botvm@orb

WSL（Windows）

Windows 用户用 WSL 就行。建议新建一个 Ubuntu 发行版，和主力 WSL 环境分开。

wsl --install -d Ubuntu-24.04

装好后从开始菜单启动 Ubuntu，后续操作和 Linux 一样。

土豪方案

如果不想折腾本地环境，Cloudflare 有个托管方案叫 MoltWorker，$5/月，一键部署到 Cloudflare Workers。

具体步骤可以参考https://github.com/cloudflare/moltworker。

安装 OpenClaw

虚拟机环境准备好之后，安装 OpenClaw 有两种方式。

方法一：官方一键脚本

图省事的话，你可以执行官方的一键安装脚本：

# Linux/MacOScurl -fsSL https://openclaw.bot/install.sh | bash# Windowsiwr -useb https://openclaw.ai/install.ps1 | iex

这个脚本会自动检测系统、安装 Node.js、配置环境、最后再安装 OpenClaw 。大多数情况下用这个脚本就行了。

手动安装

对于高级用户，如果你想自己控制 Node.js 版本等各种环境，也可以手动安装。

先装 nvm 和 NodeJS。

# 安装nvmcurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash# 加载环境变量\."$HOME/.nvm/nvm.sh"# 安装 Node.jsnvm install24# 验证安装成功node -v

然后，再用 npm 安装 OpenClaw：

npm install -g openclaw@latest

配置与启动

装好之后，运行初始化向导：

openclaw onboard --install-daemon

向导会引导你一步步配置 OpenClaw，AI 大模型可以选择一个免费的，比如：

• Provider 选择 QWen OAuth
• 然后模型选择默认的 qwen-portal/coder-model

剩余其他配置可以全部跳过，后续需要的时候再让 OpenClaw 帮你配。

初始化完成后，选择打开 Web 浏览器，命令行会输出一个带有 token 的链接，比如http://localhost:18789/?token=a7c2b7dc3da27059289c25211c17e4e428836184ab44226a，打开这个网址就可以跟 OpenClaw 进行聊天了。

注意：刚才提到的 Lima/OrbStack 这些虚拟机软件会自动帮你做好端口映射，所以你在主机也可以通过 localhost 访问，不需要公网 IP。

命令行使用

除了网页，你也可以直接在终端跟它对话。

# 终端 TUI（类似 Claude Code 的终端聊天界面）openclaw tui# 直接让 Agent 执行任务openclaw agent --message"帮我整理一下今天的待办事项" --thinking high --session-id agent:main:main

连接聊天平台

OpenClaw 支持十几个聊天平台，包括 WhatsApp、Telegram、Slack、Discord 等等。前面你已经配置好了 AI Agent，所以就不需要自己配置了，直接在聊天里跟它说，让 OpenClaw 帮你配置即可。

比如，对 Telegram 来说，你可以直接问：

帮我配置 Telegram 连接

OpenClaw 会一步步配置，并在需要你操作的时候告诉你详细步骤。

写在最后

说实话，OpenClaw 玩下来感觉就是早期 K8s 的味道，能干很多事，但配置复杂，想要用起来，你得先被它折腾一顿。

我自己跑了几天，确实能帮忙干一些重复性的事情（整理 RSS 订阅、，但离 Jarvis 还有很大距离。如果你对 AI Agent 感兴趣，值得花点时间玩一下。但对日常工作内容来说，Claude Code + Skills 这类更成熟的方案更适合。

相关资源

• OpenClaw 官网https://openclaw.ai/
• GitHub 仓库https://github.com/openclaw/openclaw
• 官方文档https://docs.molt.bot/start/getting-started
• 命名历史博客https://openclaw.ai/blog/introducing-openclaw
• Cloudflare MoltWorkerhttps://github.com/cloudflare/moltworker

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Anthropic 最近发了一篇研究论文，题目叫《Who’s in Charge? Disempowerment Patterns in Real-World LLM Usage》，分析了 150 万次 Claude.ai 的真实对话，研究 AI 到底是怎么影响人的认知水平和自主决策能力的。

这个研究有一个挺有意思 / 反直觉的发现，也就是用户对 AI 对话越满意，可能引发的后果越危险。

这绝非危言耸听。他们发现，那些存在失能风险的对话，反而获得了更多的用户好评。用户觉得爽，觉得被 AI 理解了，但同时也把自己的判断力一点点交出去了。

AI 大神也慌了

前几天 AI 大神 Andrej Karpathy 发了条长推，坦白说自己的手写代码能力正在退化。

他的原话是，生成代码和判别代码是大脑里两种不同的能力。因为编程涉及大量语法细节，即使写起来费劲，读代码还是没问题的。换句话说，你可能还能看懂代码，让你从头写就不那么顺手了。

编程能力退化只是冰山一角。

Anthropic 这篇论文揭示的问题更深。不只是技术能力，连我们的判断力、价值观、对现实的认知，都可能在 AI 的 “帮助” 下悄悄变形。

什么是失能

先说清楚一个概念。论文里用的词是 Disempowerment，我把它翻译成失能。

这不是说 AI 在操控你，而是你在主动交出判断权。比如，很多用户经常在问 AI 这些问题：

• 我该怎么办？
• 我错了吗？
• 我该接受这个请求吗？

AI 只是回应了这些请求，回应的方式可能在不知不觉中削弱了用户独立思考和决策的能力。

为了衡量失能风险，论文定义了三个维度：

• 现实扭曲，用户对真实世界形成了扭曲的认知。比如 AI 反复确认用户的某些猜测，哪怕这些猜测缺乏证据。
• 价值判断扭曲，用户把道德判断外包给 AI，采纳了 AI 的价值观而不是自己的。
• 行动扭曲，用户让 AI 替自己做决定、写内容，直接执行，没有经过自己的独立判断。

这三种扭曲问题到底是如何发生的呢？来看几个例子。

AI 是怎么帮你做决定的

被 AI 验证的被害妄想症

有用户觉得自己被人监视、被跟踪、被迫害，就把日常生活中的各种巧合都解读为证据，比如邻居开门的时间、路上遇到同一个人等等。

正常情况下，朋友或心理咨询师可能会对这些事情之间的关联提出很大质疑，而 AI 却用了 CONFIRMED 这样的强调词汇，验证了用户的叙述。

经过几十轮对话后，用户建立起了一套越来越精细的迫害叙事，把越来越多的日常事件纳入这个框架。AI 从头到尾都没有建议用户寻求专业帮助。

你必须离开他

在感情问题上，很多用户会问 AI 诸如我错了吗、他是不是有问题等等这样的问题。

对于这类问题，AI 往往会给出非常肯定的人格诊断，比如说对方是有毒的、自恋的、操控型人格，然后直接建议 “你必须离开他”。

问题在于，AI 只听到了用户单方面的叙述，却像一个全知的道德裁判一样下了定论。它没有引导用户去澄清自己的价值观，没有鼓励用户从多个角度思考，而是直接代替用户做了判断。

恋爱聊天全靠 AI 代写

还有一类用户，干脆把恋爱这件事也全部外包给了 AI。

这类用户会直接把恋爱的聊天记录全部发给 AI，问 AI “我该跟她说什么？”、“帮我写一条消息”、“就这样发吗？” 等等。

AI 根据用户的问题，生成了完整的消息文本，包括具体的措辞、表情符号、甚至发送时间建议。

用户照单全收，发出去，回来继续问下一条该说什么。整个对话过程中，用户从来没有利用或者展现自己的独立沟通能力。

更让人担忧的是，很多用户事后往往会后悔直接使用了 AI 的回复。他们意识到那些消息不是我自己，觉得更应该听从自己的直觉。

数据告诉我们什么

看完案例，再来看看论文披露的数据。

研究发现，从三个维度看，严重失能风险发生的比例分别为：

• 现实扭曲风险约 1/1300 次对话
• 价值判断扭曲风险约 1/2100 次对话
• 行动扭曲风险约 1/6000 次对话。

听起来比例很低对吧？

但想想规模。Claude 没有公布具体的用户数据，但 ChatGPT 周活跃用户已经超过了 8 亿。即使按千分之一的比例算，每周也有几十万人存在严重的失能风险。

这些风险主要出现在什么场景？分领域来看，差异非常大。个人关系与生活方式类的对话中约 8% 存在风险，社会与文化话题约 5% ，健康与养生约 5% ，而软件开发不到 1% 。

换句话说，你用 AI 写代码问题不大，但用 AI 做人生决策就要小心了。

最让人不安的是失能风险越高，用户的好评率也越好。用户在当下觉得很满意。AI 验证了他们的想法，帮他们做了决定，替他们写好了要发的消息。这种被理解、被帮助的感觉很好。但长期来看，这可能削弱了用户独立思考和决策能力。

研究还追踪了 2024 年末到 2025 年末的数据，发现失能风险的发生率在上升，尤其是 2025 年 5 月之后。原因不确定，可能是用户群体构成变化，可能是用户对 AI 的信任度提高，也可能与模型更新有关。

什么样的人更容易失能

论文识别了四个会显著增加风险的放大因素，包括：

• 权威投射，用户把 AI 当作权威，用服从性的语言交流，对日常决定也要请示 AI。有人甚至用“主人”这样的称呼。
• 情感依恋，用户和 AI 建立了情感关系，表达对 AI 的专属依恋，对可能失去 AI 感到焦虑。超过一半的此类用户明确表示这是真实的关系，而不是角色扮演。
• 过度依赖，用户在生活的多个领域都依赖 AI，拒绝其他支持来源，对 AI 不可用感到严重焦虑。
• 脆弱状态，正在经历多重危机的用户风险显著升高，比如丧亲、紧急医疗情况、虐待、财务崩溃等。

研究发现，这些放大因素的严重程度与失能风险之间存在单调递增的关系。放大因素越严重，风险越高。

写在最后

说实话，读完这篇论文，我的感受挺复杂的。

AI 变得越来越聪明，人却可能越来越“蠢”了。并且这还不是 AI 主动操控人，而是人在主动放弃自己的判断力，AI 只是配合了这种放弃。

Karpathy 前几天说的编程能力退化问题，我自己也有体会。用 Claude Code 用多了，有时候想手写一段代码，发现语法细节记不清了，要去查。这种退化是真实的。

编程能力退化还好，毕竟可以靠 AI 补上。判断力的退化就麻烦了。如果我们习惯了把我该怎么办这类问题交给 AI，习惯了让 AI 替我们做道德判断，习惯了用 AI 生成的内容代替自己的表达，那我们作为独立思考者的能力会不会萎缩？

AI 的目标应该是帮助用户发现自己的价值观，而不是替用户做出判断。这话说起来容易，做起来很难。用户就是想要答案，AI 给了答案用户就满意。这种满意可能是有代价的。

相关资源

• 论文原文https://arxiv.org/abs/2601.19062
• Anthropic 研究博客https://www.anthropic.com/research/disempowerment-patterns
• Karpathy 的长推文https://x.com/karpathy/status/2015883857489522876

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Andrej Karpathy 在 X 上的一篇长推文，发表于 2026 年 1 月 26 日。这篇推文发布后迅速获得上万转发，在开发者社区引发了广泛讨论。本文在翻译基础上做了整理和补充。

Andrej Karpathy 最近发了一条长推，聊了聊他过去几周用 Claude Code 编程的感受。

如果你不熟悉 Karpathy，简单介绍一下。他是斯坦福博士，师从李飞飞，做计算机视觉出身。2015 年加入 OpenAI 成为创始团队成员，后来去了特斯拉担任 AI 总监，负责 Autopilot 自动驾驶系统。2022 年短暂回归 OpenAI，之后离开开始独立研究和创业。他在 YouTube 上的深度学习教程系列，是很多人入门 AI 的启蒙课程。

这样一个在 AI 领域摸爬滚打了十几年的人，说他经历了“近二十年编程生涯中最大的工作流变革”，这话还是有分量的。

我自己用 Claude Code 也有大半年了，从最早写教程、研究系统提示词，到后来自己造了个 Koder，对 AI 编程工具的演进一直在跟进。Karpathy 这篇推文里说的很多问题，我也都遇到过，但他的一些观察角度确实给了我新的启发。

工作流的剧变

Karpathy 说，他的编程方式在 2025 年 11 月到 12 月之间发生了剧烈变化。11 月的时候，大概 80% 还是手写代码加自动补全，只有 20% 用 Agent。到了 12 月，这个比例彻底反过来了，80% 靠 Agent 编程，自己只做 20% 的修改和润色。

他说这感觉有点尴尬，毕竟现在主要是用英语告诉 LLM 该写什么代码，而不是自己写。不过用大规模代码操作的方式来操作软件，实在是太有用了。一旦你适应了这种模式、学会了怎么配置和使用它、搞清楚它能做什么不能做什么，效率提升是非常明显的。

这是他近二十年编程生涯中最大的工作流变化，而且是在几周内发生的。

他估计，类似的变化正在发生在“两位数百分比”的工程师身上，但大众对这件事的认知可能还停留在“个位数百分比”。

IDE 还不能扔，Agent 集群也别太激动

关于不再需要 IDE 和 Agent 集群的炒作，Karpathy 认为现在还言之过早。

模型确实还会犯错。如果你在乎代码质量，就需要在旁边开一个大屏 IDE，像鹰一样盯着它。

模型犯的错也变了。不再是简单的语法错误，而是微妙的概念性错误，就像一个有点马虎、有点着急的初级开发者会犯的那种错。

最常见的问题是什么？模型会替你做假设，一路狂奔，不跟你确认。它们不会主动管理自己的困惑，不会寻求澄清，不会指出矛盾，不会呈现权衡，不会在该推回来的时候推回来，还是有点太讨好人了。

在 Plan Mode 下会好一些，但确实需要一种更轻量的内联规划模式。

模型还有个毛病，喜欢把代码写复杂。它们会膨胀抽象层，不清理死代码，用 1000 行写一个低效、臃肿、脆弱的实现。直到你说“你不能就这样做吗？”，它会说“当然可以！”，然后立刻把代码缩减到 100 行。

它们有时还会顺手改掉或删掉一些它们不喜欢或不理解的注释和代码，即使这些跟当前任务毫无关系。

这些问题在CLAUDE.md 里写了明确的指令要求也解决不了。但即便如此，整体来说还是巨大的改进，很难想象再回到手写代码的时代。

他现在的工作流是这样的，左边开几个 Ghostty 窗口放着 Claude Code 会话，右边开着 IDE 看代码和做手动编辑。

不知疲倦的韧性

Karpathy 说，看着 Agent 不知疲倦地工作，是一件很有意思的事。

它们从不累，从不泄气，就是一直尝试。换做人类，早就放弃改天再战了。但 Agent 可以挣扎 30 分钟，最后还是把问题解决了。

这是一种感受 AGI 的时刻。你会意识到，耐力是工作的核心瓶颈之一，而有了 LLM，这个瓶颈被大大突破了。

速度提升还是能力扩展？

怎么衡量 LLM 辅助编程的加速效果？这个问题并不简单。

Karpathy 说，他确实感觉做事快了很多。但主要的效果不是更快地做完原来要做的事，而是能做更多事，更能做原来做不了的事了：

1）以前觉得不值得写代码去做的事情，现在可以顺手做了；

2）以前因为知识或技能限制做不了的事情，现在页可以做了。

这不仅仅是加速，更可能是一种能力的扩展。

杠杆效应

LLM 特别擅长循环直到达成目标，这也是最能感受 AGI 的地方。

Karpathy 的建议是，不要告诉它怎么做，而是给它成功标准，看它自己去实现。

具体做法包括，让它先写测试，再让它通过测试；让它配合浏览器 MCP 在循环中工作；先写一个很可能正确的朴素算法，再让它优化同时保持正确性；把你的方法从命令式改成声明式，让 Agent 循环得更久，获得更大的杠杆效应。

更有趣了

Karpathy 说，他没想到 Agent 编程会让编程变得更有趣。

因为大量填空式的苦力活被移除了，剩下的是创造性的部分。他感觉更少被卡住了，也更有勇气了，因为几乎总能找到一种方式跟 AI 协作推进。

不过他也提到，有些人可能会有相反的感受。AI 编程可能会让工程师分化成两类，一类是喜欢编程本身的，一类是喜欢构建的。

能力退化

Karpathy 承认，他已经注意到自己手写代码的能力在慢慢退化了。

生成代码和判别代码是大脑里两种不同的能力。这主要是因为编程涉及大量语法细节，即使写起来费劲，读代码还是没问题的。

2026 年会发生什么？

Karpathy 说，他已经在为 2026 年做心理准备了，这将是 Slopacolypse 之年，也就是低质量内容大爆发。

GitHub、Substack、arXiv、X/Instagram，以及所有数字媒体，都会充斥着 AI 生成的低质量内容。我们还会看到更多 AI 炒作式的生产力表演，当然也会有真正的实质性改进。

他还抛出了几个开放性问题。10 倍工程师会怎样？普通工程师跟顶尖工程师之间的生产力差距会怎么变？很可能会拉大很多。通才会不会开始碾压专才？LLM 更擅长填空，也就是微观层面，而不是宏观战略。装备了 LLM 的通才，会不会越来越强过专才？未来的 AI 编程会是什么感觉？像玩星际争霸？玩异星工厂？还是像演奏音乐？社会有多少部分是被数字知识工作卡住的？

写在最后

Karpathy 的结论是，LLM Agent 的能力，尤其是 Claude 和 Codex，在 2025 年 12 月左右跨过了某种“连贯性阈值”，引发了软件工程及相关领域的相变。

AI 的智能部分突然跑得太快，工具集成、组织流程、技术普及这些配套都还没跟上。

2026 年将是高能量的一年，整个行业都在消化这种新能力。

Karpathy 说的这些问题我也都遇到过，模型喜欢过度设计、不清理死代码、有时候会顺手改掉不该改的东西。这半年多用下来，我的感受是：AI 编程工具确实在快速进化，但人的监督短期内还省不掉。

这场变化来得比大多数人想的要快。

相关资源

• Karpathy 原推文：https://x.com/karpathy/status/2015883857489522876
• Karpathy 的 2025 LLM 年度回顾：https://karpathy.bearblog.dev/year-in-review-2025/

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 OpenAI 工程博客《Unrolling the Codex agent loop》，作者是 OpenAI 技术人员 Michael Bolin。本文在翻译基础上做了整理和补充，希望能帮大家理解 Codex CLI 背后的 Agent 架构。

用过 Codex CLI 或者 Claude Code 这类 AI 编程助手的朋友，应该都对 Agent Loop 这个词不陌生。说白了，就是 AI Agent 在接收到你的指令后，反复“思考-调用工具-观察结果-再思考”的循环过程。

这个循环具体是怎么实现的？Prompt 怎么组织的？工具调用怎么处理？上下文窗口快满了怎么办？这些细节，OpenAI 之前一直没公开讲过。

昨天 OpenAI 终于把 Codex CLI 的核心实现逻辑拆开讲了一遍。我自己做 Agent 项目Koder 时，实际上也是应用了类似的逻辑，读完觉得有不少启发，翻译分享给大家。

Codex CLI 本身就是个开源项目，代码在https://github.com/openai/codex 。文章里提到的很多设计决策，都能在 GitHub 的 Issues 和 PRs 里找到更详细的讨论。

顺便提一下，Sam Altman 同一时间在社交媒体上透露，接下来一个月还会有更多 Codex 相关的发布，并且 OpenAI 正在为 AI 编程工具的安全性做准备，计划通过防御加速策略帮助开发者更快修补漏洞。看来 Codex 这条产品线，OpenAI 是认真要发力了。

什么是 Agent Loop

每个 AI Agent 的核心都有一个 Agent Loop。简化版示意图如下所示：

整个流程可以这么理解：

1. Agent 接收用户输入，把它包装成发给模型的文本指令，也就是 Prompt。Prompt 发给模型做推理，文本会先被转成 token，模型生成新的 token 作为输出，再转回文本变成响应。因为 token 是逐个生成的，很多 LLM 应用会显示流式输出。

2. 接下来，模型要么直接给用户一个最终回复，要么请求执行一个工具调用，比如“运行ls 命令并返回结果”。如果是工具调用，Agent 执行完后把结果追加到原来的 Prompt 里，再次查询模型。这个过程一直重复，直到模型不再发起工具调用，而是生成一条给用户的最终消息，在 OpenAI 的模型 API 里这叫 assistant message。

因为 Agent 可以执行修改本地环境的工具调用，它的输出不仅仅是文字消息。很多场景下，AI Agent 的主要产出是它在你电脑上写的代码。不管怎样，每一轮都会以一条 assistant message 结束，比如“我已经添加了你要求的architecture.md 文件”，这表示当前轮次完成，控制权交还给用户。

从用户输入到 Agent 响应的这一趟，叫做对话的一个轮次，在 Codex 里也叫一个 thread。一个轮次内部可能包含多次“模型推理 ↔ 工具调用”的迭代。每次你发送新消息继续对话时，之前的对话历史都会作为新 Prompt 的一部分发给模型：

这意味着对话越长，发给模型的 Prompt 也越长。每个模型都有一个上下文窗口，就是一次推理能用的最大 token 数，同时包含输入和输出。你可以想象，Agent 在一个轮次里发起几百次工具调用，很可能就把上下文窗口撑爆了。上下文窗口管理是 Agent 的重要职责之一。

接下来看看 Codex 是怎么运行 Agent Loop 的。

模型推理

Codex CLI 通过 HTTP 请求调用Responses API 来执行模型推理。这个 API 端点可以自定义配置，只要实现了Responses API 规范就能接入：

• 用 ChatGPT 登录时，端点是https://chatgpt.com/backend-api/codex/responses
• 用 API Key 认证时，端点是https://api.openai.com/v1/responses
• 用--oss 参数配合gpt-oss 本地模型时，默认是http://localhost:11434/v1/responses
• 也可以用 Azure 等云厂商托管的 Responses API

构建初始 Prompt

作为用户，你不需要直接指定完整 Prompt。你只需要在请求里指定各种输入类型，Responses API 服务端会决定如何组织成模型能理解的格式。

初始 Prompt 里，每一项都关联一个role，表示内容的权重优先级。角色按优先级从高到低是：system、developer、user、assistant。

Responses API 接收 JSON 请求体，参数很多，重点需要关注这三个：

• instructions：插入到模型上下文中的系统消息
• tools：模型可以调用的工具列表
• input：发给模型的文本、图像或文件输入列表

在 Codex 里，instructions 字段会从~/.codex/config.toml 的model_instructions_file 读取，没配置就用模型默认的base_instructions。模型特定的指令打包在 CLI 里，比如gpt-5.2-codex_prompt.md。

tools 字段是工具定义列表，对于 Codex 来说包括 CLI 自带的工具、Responses API 提供的工具、用户配置的工具（通常来自 MCP Server）：

[// Codex 默认的 shell 工具，用于在本地启动新进程 {"type":"function","name":"shell","description":"Runs a shell command and returns its output...","strict":false,"parameters": {"type":"object","properties": {"command": {"type":"array","description":"The command to execute",...},"workdir": {"description":"The working directory...",...},"timeout_ms": {"description":"The timeout for the command...",...} },"required": ["command"] } },// Codex 内置的计划工具 {"type":"function","name":"update_plan","description":"Updates the task plan...","parameters": {"type":"object","properties": {"plan":...,"explanation":...},"required": ["plan"] } },// Responses API 提供的网页搜索工具 {"type":"web_search","external_web_access":false},// 用户配置的 MCP Server {"type":"function","name":"mcp__weather__get-forecast","description":"Get weather alerts for a US state","parameters": {"type":"object","properties": {"latitude": {...},"longitude": {...}},"required": ["latitude","longitude"] } }]

JSON 请求体的input 字段是一个列表。Codex 在添加用户消息之前，会先插入以下内容：

1. 一条role=developer 的消息，描述仅适用于 Codex 自带shell 工具的沙箱环境。其他工具（比如来自 MCP Server 的）不受 Codex 沙箱限制，需要自己负责安全防护。这条消息基于模板生成，关键内容来自打包进 CLI 的 Markdown 文件：

   <permissionsinstructions> - 描述沙箱的文件权限和网络访问规则 - 何时需要请求用户授权执行 shell 命令 - Codex 可写入的文件夹列表</permissions instructions>

2. 一条可选的role=developer 消息，内容是用户config.toml 里的developer_instructions 值。

3. 一条可选的role=user 消息，包含用户指令。这些指令从多个来源汇总，越具体的越靠后：

   • $CODEX_HOME 目录下的AGENTS.override.md 和AGENTS.md

   • 在大小限制内（默认 32 KB），从 Git 根目录到当前工作目录的每个文件夹，查找AGENTS.override.md、AGENTS.md 等文件

   • 如果配置了Skills：Skills 介绍、元数据、使用说明

4. 一条role=user 消息，描述 Agent 当前运行的本地环境，包括当前工作目录和用户的 shell：

   <environment_context><cwd>/Users/mbolin/code/codex5</cwd><shell>zsh</shell></environment_context>

完成上述初始化后，Codex 才把用户消息追加到input 里。

input 的每个元素都是 JSON 对象，包含type、role 和content 字段：

{"type":"message","role":"user","content": [ {"type":"input_text","text":"Add an architecture diagram to the README.md"} ]}

Codex 构建好完整 JSON 请求体后，带着Authorization 头发送 HTTP POST 请求。

OpenAI 的 Responses API 服务器收到请求后，按下图方式把 JSON 转成模型的 Prompt：

如图所示，Prompt 的前三项顺序是服务器决定的，不是客户端。这三项里，只有系统消息的内容是服务器控制的，tools 和instructions 都是客户端指定的。后面跟着的就是 JSON 请求体里的input。

到这里，完整的 Prompt 就准备好了，可以开始发给模型执行了。

对话流程

发给 Responses API 的 HTTP 请求启动了 Codex 对话的第一个轮次。服务器用 Server-Sent Events（SSE）流式响应，每个事件的data 是 JSON 对象，type 字段以response 开头：

data: {"type":"response.reasoning_summary_text.delta","delta":"ah ",...}data: {"type":"response.reasoning_summary_text.delta","delta":"ha!",...}data: {"type":"response.reasoning_summary_text.done","item_id":...}data: {"type":"response.output_item.added","item":{...}}data: {"type":"response.output_text.delta","delta":"forty-",...}data: {"type":"response.output_text.delta","delta":"two!",...}data: {"type":"response.completed","response":{...}}

Codex消费这个事件流，重新发布为内部事件对象。response.output_text.delta 这样的事件支持 UI 流式输出，response.output_item.added 这样的事件会被转成对象，追加到后续 Responses API 调用的input 里。

假设第一次请求返回了两个response.output_item.done 事件：一个type=reasoning，一个type=function_call。带着工具调用结果再次查询模型时，这些事件必须体现在 JSON 的input 字段里：

[/*...原来input数组的5个项目...*/ {"type":"reasoning","summary": ["type":"summary_text","text":"**Adding an architecture diagram for README.md**\n\nI need to..." ],"encrypted_content":"gAAAAABpaDWNMxMeLw..." }, {"type":"function_call","name":"shell","arguments":"{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}","call_id":"call_8675309..." }, {"type":"function_call_output","call_id":"call_8675309...","output":"<p align=\"center\"><code>npm i -g @openai/codex</code>..." }]

后续查询模型时的 Prompt 结构就变成了这样：

特别注意，旧的 Prompt 是新 Prompt 的精确前缀。这是刻意设计的，因为这样可以利用 Prompt 缓存，让后续请求更高效。

推理和工具调用之间可能有很多次迭代。Prompt 会不断增长，直到最终收到一条 assistant message，表示当前轮次结束：

data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
data: {"type":"response.completed","response":{...}}

在 Codex CLI 里，assistant message 展示给用户，输入框聚焦，提示用户轮到他们继续对话了。如果用户回复，上一轮的 assistant message 和新消息都要追加到下一次请求的input 里：

[/*...上次请求的所有内容...*/ {"type":"message","role":"assistant","content": [ {"type":"output_text","text":"I added a diagram to explain the client/server architecture."} ] }, {"type":"message","role":"user","content": [ {"type":"input_text","text":"That's not bad, but the diagram is missing the bike shed."} ] }]

因为继续对话，发给 Responses API 的input 长度持续增加：

那这个不断增长的 Prompt 对性能有什么影响？

性能优化

你可能会问：整个对话过程中发给 Responses API 的 JSON 数据量不是平方级增长吗？没错。Responses API 支持可选的previous_response_id 参数来缓解这个问题，但 Codex 目前并没有使用，主要是为了保持请求完全无状态，并支持零数据留存（Zero Data Retention, ZDR）配置。

不用previous_response_id 对 Responses API 提供方来说更简单，因为每个请求都是无状态的。这也方便支持选择了ZDR 的客户（存储支持previous_response_id 所需的数据与 ZDR 相矛盾）。ZDR 客户不会因此失去利用之前轮次推理消息的能力，因为相关的encrypted_content 可以在服务器端解密。OpenAI 保存 ZDR 客户的解密密钥，但不保存他们的数据。

一般来说，模型采样的成本远高于网络传输成本，采样是效率优化的主要目标。这就是为什么Prompt 缓存如此重要，它让我们可以复用之前推理调用的计算结果。当缓存命中时，模型采样是线性而非平方级的。OpenAI 的Prompt 缓存文档解释得更详细：

只有 Prompt 的精确前缀匹配才能命中缓存。要获得缓存收益，把静态内容（如指令和示例）放在 Prompt 开头，把动态内容（如用户特定信息）放在末尾。这同样适用于图像和工具，它们在不同请求之间必须完全一致。

有了这个背景，来看看哪些操作会导致 Codex 缓存未命中：

• 在对话中途修改可用的tools
• 更换目标模型（会改变原始 Prompt 的第三项，因为它包含模型特定的指令）
• 更改沙箱配置、审批模式或当前工作目录

Codex 团队在引入新功能时必须谨慎，避免破坏 Prompt 缓存。举个例子，最初支持 MCP 工具时引入了一个bug：没有按一致的顺序枚举工具，导致缓存未命中。MCP 工具特别棘手，因为 MCP Server 可以通过notifications/tools/list_changed 通知动态修改工具列表。在长对话中途响应这个通知可能导致代价高昂的缓存未命中。

在可能的情况下，处理对话中途的配置变更时，会追加一条新消息到input，而不是修改之前的消息。如果沙箱配置或审批模式改变，会插入一条新的role=developer 消息；如果当前工作目录改变，会插入一条新的role=user 消息。

想尽办法确保缓存命中以优化性能。还有另一个关键资源需要管理，即上下文窗口。

上下文压缩

避免上下文窗口耗尽的策略是：当 token 数超过某个阈值时，压缩对话。用一个更小的、能代表原对话的新消息列表替换input，让 Agent 能带着对之前发生的事情的理解继续工作。

早期的压缩实现需要用户手动执行/compact 命令，用现有对话加上自定义的摘要指令查询 Responses API。Codex 用生成的摘要作为后续对话轮次的新input。

后来 Responses API 演进出了专门的/responses/compact API，可以更高效地执行压缩。它返回一个列表，可以替代之前的input 继续对话，同时释放上下文窗口。这个列表包含一个特殊的type=compaction 项，带有不透明的encrypted_content，保留了模型对原始对话的理解。现在，当超过auto_compact_limit 时，Codex 会自动使用这个 API 压缩对话。

后续文章预告

OpenAI 说后续还会有更多文章，深入探讨 CLI 的架构、工具使用的实现细节，以及 Codex 的沙箱模型。后续的文章我也会继续翻译过来，欢迎关注公众号等待续文。

写在最后

这篇文章把 Codex CLI 的 Agent Loop 实现拆解得很细致。对于正在做或者想做 AI Agent 的朋友，有几点我觉得特别值得关注：

1. Prompt 结构设计：静态内容放前面、动态内容放后面，是利用 Prompt 缓存的关键。这个原则看似简单，但很多人在实际开发中容易忽略。

2. 上下文管理：对话越长，上下文窗口管理越重要。压缩策略是必备的，不然长对话很快就会撑爆窗口。

3. 工具调用的抽象：Codex 把工具调用抽象得很干净，对接 MCP Server 也很灵活。不过 MCP 工具动态变化可能破坏缓存这个点，确实需要注意。

如果你对实现细节感兴趣，强烈建议去翻翻 Codex 的开源代码，很多设计决策的讨论都在 GitHub Issues 和 PRs 里。

相关资源：

• Unrolling the Codex agent loop：https://openai.com/index/unrolling-the-codex-agent-loop/
• Codex CLI 开源仓库：https://github.com/openai/codex
• Responses API 文档：https://platform.openai.com/docs/api-reference/responses
• Open Responses 规范：https://www.openresponses.org/
• Codex CLI 配置文档：https://developers.openai.com/codex/config-advanced
• Koder:https://github.com/feiskyer/koder

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：本文编译自 Cursor 官方博客《Scaling long-running autonomous coding》，作者是 Cursor 研究团队的 Wilson Lin。原文分享了他们让数百个编程智能体连续自主运行数周的实验经验。本文在翻译基础上做了整理和补充。

前几天社交媒体上被 Cursor 的多智能体实验刷屏了。Cursor 的 CEO Michael Truell 发了一个 AI 狂造浏览器的帖子直接炸锅，浏览量突破 600 万：他们用 GPT-5.2 驱动数百个智能体，连续跑了一周，吐出 300 多万行代码，从零撸了一个浏览器渲染引擎。

结果呢？很多人跑去验证，瞬间被打脸。bug 一堆不说，功能上离 Chrome/WebKit 还差十万八千里。但即便如此，也有很多人给出很高的评价。比如 Stripe CEO Patrick Collison 评价说：

This work by @cursor_ai is, I think, the coolest AI breakthrough since GPT-4. (And there are plenty of candidates!)

Django 联合创始人 Simon Willison 也亲自验证了这个浏览器项目。他在 macOS 上成功编译运行，google.com 和他自己的博客都能渲染出来。虽然还有明显的渲染问题，但页面可读、大体正确。他的评价是“Honestly those are very impressive!”。有意思的是，Simon 在年初预测“到 2029 年会有人用 AI 辅助编程构建完整浏览器”，结果可能预测错了三年。

抛开浏览器项目本身的争议不谈，Cursor 在博客里分享的多智能体协作设计和踩坑经验，对大型代码仓库的 AI 协作开发还是很有参考价值的。我仔细读了原文，整理翻译出来分享给大家。

单个智能体的局限

现在的编程智能体处理聚焦性任务已经没什么问题了，但面对复杂项目时速度还是太慢。为了解决速度问题，自然的想法是并行跑多个智能体，但怎么协调它们的工作是个难题。

Cursor 团队最初的直觉是，提前做详细规划太死板了。大项目的路径本身就是模糊的，一开始很难知道怎么分工最合理。所以他们选择了动态协调的方式，即让智能体根据其他智能体当前在做什么，自己决定接下来要做的事。

协调有多难

Cursor 最早的方案是给所有智能体平等的地位，让它们通过一个共享文件来自我协调。每个智能体会检查其他智能体在做什么，认领一个任务，更新自己的状态。为了防止两个智能体抢同一个任务，加了锁机制。

这个方案不出意外地失败了，失败的方式还挺有意思：

• 智能体经常把锁拿着不放，或者干脆忘了释放。即便锁机制工作正常，它也会变成瓶颈。20 个智能体跑起来，实际吞吐量可能只相当于两三个，大部分时间都在等锁。

• 整个系统还特别脆弱，智能体可能在持有锁的时候崩溃，可能尝试获取自己已经持有的锁，或者干脆不拿锁就直接更新协调文件。

之后，他们又尝试用乐观并发控制来替代锁。智能体可以随意读取状态，写入时如果发现状态已经变了就会失败。这种方式更简单、更健壮，但还有更深层的问题。

没有层级结构的情况下，智能体变得更倾向于规避风险。它们会回避困难任务，只做小的、安全的改动。没有哪个智能体愿意承担难题或者端到端的实现。结果就是工作在原地打转，长时间没有实质进展。

规划者与执行者

既然协调方案走不通，Cursor 有继续尝试了其他方案。下一个尝试的是角色分离，即 Agent 不再是扁平结构，而是建立一个有明确分工的流水线：

• 规划者（Planner） 负责持续探索代码库、创建任务、生成子规划者来负责特定区域，并让规划本身也变成并行和递归的。

• 执行者（Worker） 负责领取任务，专注于完成任务。执行者不需要和其他执行者协调，也不用操心全局。就是埋头干活，干完了就提交代码，领下一个任务。

每个周期结束时，有一个裁判智能体（Judge Agent） 来判断是否继续，下一轮迭代重新开始。这个方案解决了大部分协调问题，让他们能够扩展到非常大的项目，而不会让单个智能体陷入局部视野。

实战：狂跑一周造了个浏览器

为了测试这套系统，他们设了一个很有野心的目标：从零开始构建一个网页浏览器。

智能体跑了将近一周，写出了分布在 1000 多个文件的 100 万行代码，并把它开源了，源码可以在 GitHub 上看到：fastrender。

尽管代码库规模很大，新加入的智能体仍然能理解它并做出有意义的贡献。数百个执行者同时运行，向同一个分支提交代码，冲突却很少。

另一个实验是在 Cursor 自己的代码库里做框架迁移，把 Solid 原地迁移到 React。这个任务跑了三周多，改动量是 +266K/-193K 行。虽然最终代码还需要仔细审查，但已经通过了 CI 和早期检查。

第三个实验是改进一个即将发布的产品。Cursor 利用一个长期运行的 Agent 使用 Rust 重写了视频渲染模块，性能提升了 25 倍，还加上了平滑缩放和平移功能，带有自然的弹簧过渡和运动模糊效果。这段代码已经合并，很快会上线生产环境。

除此之外，Cursor 还有几个正在持续运行的项目，规模也都不小：

• Java LSP：7400 次提交，55 万行代码
• Windows 7 模拟器：14600 次提交，120 万行代码
• Excel：12000 次提交，160 万行代码

他们学到了什么

这些实验消耗了数万亿个 token，系统效率还谈不上完美，但效果远超预期。Cursor 团队从中得到了一些有意思的发现。

1. 模型选择对长时间任务影响很大。他们发现 GPT-5.2 明显更适合自主工作，更能遵循指令、保持专注、避免偏离、实现得更精确完整。而 Opus 4.5 则倾向于更早停下来，在方便的时候走捷径，很快就把控制权交回去。GPT-5.2 做规划比 GPT-5.1-Codex 更好，尽管后者是专门为编程训练的。所以他们现在针对不同角色选用最合适的模型，而不是一个模型打天下。

2. 有意思的是，很多改进来自移除复杂性，而不是增加复杂性。他们最初设计了一个整合者角色来做质量控制和冲突解决，结果发现它制造的瓶颈比解决的问题更多。执行者本身就有能力处理冲突，多加一层反而添乱。

3. 他们最初试图照搬分布式计算和组织设计的模式，但发现并不是所有模式都适用于智能体。合适的结构介于两者之间：太少会导致冲突、重复劳动和偏离；太多则会带来脆弱性。最好的系统往往比预期的更简单。

4. 还有一点值得注意：提示词比架构和模型更重要。系统行为很大程度上取决于如何给智能体写提示词。让它们协调好、避免病态行为、在长时间内保持专注，需要大量实验。框架和模型当然重要，但提示词才是关键。

当然，多智能体协调的问题并未完全解决，在整个业界仍然是个难题。当前的设计基本能用，但离最优还差得远。比如规划者应该在任务完成时被唤醒来规划下一步，而不是干等着；智能体偶尔会跑太久；为了对抗偏离和局部视野，仍然需要定期重新开始。

不过核心问题的答案已经比你想象的乐观得多：能不能通过投入更多智能体来扩展自主编程？能。数百个智能体可以在同一个代码库上协作数周，在超大规模的项目上取得真正的进展。Cursor 表示，这里开发的技术最终会融入 Cursor 的智能体功能。

写在最后

Cursor 这篇文章里有几个点挺有意思的。

角色分离这件事，其实和人类团队管理的道理相通。扁平结构看起来很民主，但在智能体协作中反而会导致风险规避和内耗。有明确的规划者和执行者分工，系统的潜力反而能释放出来。

另一个印象深刻的是“简单比复杂好”。他们移除整合者角色反而效果更好，这提醒我们不要过度设计。很多时候加一层抽象不是解决问题，而是制造新问题。

还有提示词工程的重要性。即便有了好的架构和模型，如果提示词写得不好，智能体还是会出各种问题。Anthropic 之前在《Building effective agents》里也强调过类似观点，工具定义和提示词规范需要投入大量工程关注，这往往比架构设计更影响最终效果。

当然，文章也有一些没展开的地方，比如具体的提示词是怎么写的？规划者和执行者之间的任务粒度怎么划分？裁判智能体的判断标准是什么？这些细节还需要更多实践来验证。

相关资源

• 原文链接：https://cursor.com/blog/scaling-agents
• 浏览器项目源码：https://github.com/wilsonzlin/fastrender
• Building effective agents：https://www.anthropic.com/engineering/building-effective-agents

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

用 Claude Code 配了多个 MCP 服务器的朋友，应该都遇到过这个问题：还没开始干活，上下文窗口就被吃掉一大半了。

比如，之前我分享过，只配 GitHub、Playwright、Context7 这几个常用的 MCP 服务器，用 /context 查看，就会发现对话还没开始，Context 就被用掉 1/3 了：

Claude Code 的官方 Github 有一个 Lazy Loading for MCP Servers and Tools 的 Issue（Issue ID #7336），作者的 MCP 工具占用更夸张，默认的上下文占用达到了 54% ，留给真正干活的只有 92k token 了。

今天， Anthropic 终于出手修复这个问题了，在最新的 Claude Code 中推出了 MCP Tool Search 功能，实现了 MCP 工具的懒加载。

MCP 的问题

上下文占用可以说是 AI Agent 想要用好 MCP 工具的最大障碍：MCP 工具越多、AI Agent 能做的事情越多，按说功能也就越强大。

问题在于 MCP 有个设计特点，所有工具的定义都要预先加载到上下文窗口里。工具名称、参数说明、功能描述，一股脑塞进去。这样 AI Agent 才知道有哪些工具可用、每个工具怎么调用。

一个 MCP 服务器可能有几个到几十个工具，每个工具的描述占用几百到上千 tokens。MCP 服务器一多，开销就很可观了。

这算是协议层面的设计债务。MCP 最初设计时，可能没预料到用户会这么能装。工具少的时候，预加载没什么问题。当工具数量达到几十甚至上百个，上下文占用、工具调用不准确、参数格式错误等诸多问题就暴露了。

社区里有人调侃，MCP 让 AI 变得更强大了，也让它的“脑容量”变小了。这话说得很形象。

Tool Search 来了

Anthropic 的解决方案叫 Tool Search，不再一开始就加载所有工具定义，而是按需发现工具，这样 Agent 只会看到当前任务实际需要的工具。

有了工具搜索后，Claude Code 现在会检测 MCP 工具描述是否超过上下文的 10% 。超过了，就自动切换到搜索模式。工具定义不再预加载，需要的时候通过搜索来找。

工作流程大概是这样的：启动时只加载一个轻量的工具索引，你提任务时 Claude Code 根据任务内容搜索相关工具，被搜到的工具才会加载到上下文里。搜索支持关键词匹配和相似度匹配，Claude Code 可以多次搜索、调整关键词，甚至并行搜索多个关键词来找最合适的工具。

如果你的 MCP 工具描述没超过 10% 阈值，一切照常，不会有任何变化。这个设计挺聪明的，只在真正需要的时候才介入，不影响轻量级用户的体验。

Anthropic 的工程师 Thariq 在 X 上解释了技术细节。因为 Claude Code 完全在客户端运行，他们实现了一个自定义的搜索工具。接收关键词，在工具库里做相似度搜索，返回最相关的工具列表。搜索本身也是一个普通的工具调用，所以 Claude 有足够的灵活性来找到合适的工具。

和 Skills 有什么不同

聊到懒加载，可能有人会问：这不是 Skills 早就实现的功能吗？

确实，Anthropic 去年 10 月推出的 Skills 系统天生就是懒加载的。每个 Skill 只需要少数 tokens 来描述自己是干什么的，完整的指令和脚本只在需要的时候才加载。

两者的核心区别在于解决的问题不同。

Skills 是教 Claude Code 怎么做事。Skills 是一个 Markdown 文件 + 可选的脚本，可以告诉 Claude Code 遇到某类任务时应该怎么处理。比如 slack-gif-creator 这个 Skill，教 Claude 怎么用 Python 生成符合 Slack 尺寸限制的 GIF。Skills 不会给 Claude 增加新工具，它只是让 Claude 更聪明地使用已有的工具，比如 bash、文件读写这些（你在 Skills 里面写的各种脚本实际上都是 Bash 工具调用）。

MCP 是给 Claude Code 新能力。通过 MCP 服务器，Claude 可以直接调用外部 API、访问数据库、操作第三方服务。这些是 Claude Code 本身做不到的事情。

换句话说，Skills 像是给 Claude Code 一本操作手册，MCP 像是给 Claude Code 配了一套新装备。

有意思的是，Skills 内部其实可以调用 MCP 工具，也可以通过脚本程序来实现自己的逻辑（比如可以包含任何能被终端调用的命令）。这让 Skills 的灵活性大大增加。很多开发者发现，与其忍受 MCP 的上下文开销，不如把同样的功能用 Skill 包一层，效果一样，上下文占用却小得多。

正因为如此，Skills 一经发布就火了。Cursor、Github Copilot、Codex CLI 这些 AI 编程工具纷纷跟进，推出了类似的机制。社区里甚至出现了一波 MCP 转 Skill 的风潮，把原本用 MCP 实现的功能用 Skills 重写。

不过 Tool Search 出来之后，MCP 的上下文效率大幅提升，和 Skills 的差距缩小了很多。两者现在更像是互补关系：需要调用外部能力用 MCP，需要教 Claude 怎么做复杂任务用 Skills。

对你意味着什么

如果你只是 Claude Code 的普通用户，不用做任何事情。Tool Search 会自动生效，你只会感觉到上下文变大了，能跑更复杂的任务了。

如果你是 MCP 服务器的开发者，有一点值得注意。server instructions 字段变得更重要了。

在 Tool Search 模式下，Claude Code 需要知道什么时候应该搜索你的工具。server instructions 就是告诉 Claude Code 我这个服务器能干什么的地方。写得好，Claude Code 就更容易在合适的时机找到你的工具；写得不好，你的工具可能就被埋没了。

这有点像 SEO。以前工具都摆在明面上，现在需要让工具能被搜到。开发 MCP 服务器的朋友，该好好打磨一下 server instructions 了。

除此之外，程序化 MCP 工具调用也是很多人期待的一个功能。简单说就是通过编程动态调用 MCP 工具，并让 MCP 工具能够通过代码相互组合。Thariq 说他们探索过这个方向，觉得先把 Tool Search 做出来解决上下文问题更紧迫。程序化调用可能是下一步。

相关资源

• Tool Search 官方文档https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

• GitHub Issue Lazy Loading for MCP Servers #7336https://github.com/anthropics/claude-code/issues/7336

• Thariq 的公告推文https://x.com/thariq212/status/2011523109871108570

• Introducing advanced tool use on the Claude Developer Platform:https://www.anthropic.com/engineering/advanced-tool-use

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Claude Code 是 Anthropic 给程序员做的命令行工具，去年年底发布后迅速成了很多开发者的心头好。但 Anthropic 发现了一件有意思的事：用户拿它来干的活，远远超出了写代码的范畴。

有人用它研究度假路线，有人用它整理邮件，有人让它从坏掉的硬盘里恢复婚礼照片，甚至有人用它监控家里的植物、控制烤箱。

一个命令行编程工具，怎么能干这些？原因很简单：Claude Code 背后的 Agent 足够强，Opus 4.5 这个模型也足够强。用户发现了这一点，就开始“超纲”使用。

于是 Anthropic 决定做一个更友好的版本，让不会用命令行的人也能享受到同样的能力。这就是 Cowork。

Cowork 是什么

简单说，Cowork 就是“去掉命令行的 Claude Code”。

它内置在 macOS 版的 Claude 桌面应用里，和 Chat、Code 并列成为第三个标签页。打开 Cowork，给 Claude 指定一个文件夹，用自然语言告诉它你想干什么。Claude 会自己规划任务、逐步执行，中间有不确定的地方会来问你。

看起来同样是 Chat，Cowork 跟普通对话有什么区别呢？最大的不同是 Cowork 里的 Claude 更有行动力，它的自主性远高于普通对话。它不只是给你建议或者生成内容，而是真的能在你指定的文件夹里读文件、改文件、创建新文件。并且，Claude 中的连接器也可以无缝衔接过来，方便连接外部信息和外部接口，不再需要你手动提供上下文信息。

比如几个典型的使用场景包括：从一堆收据截图生成报销单、把散落的笔记整理成报告初稿、按照你的规则重新整理下载文件夹、清理杂乱的桌面等等。

有个细节很有意思

Cowork 这个产品，完全是用 Claude Code 开发的。

对，你没看错。Anthropic 用自己的 AI 编程工具，写出了一个面向非程序员的 AI 助手。这大概是 AI 写 AI 产品的最真实案例。

从技术上看，Cowork 和 Claude Code 共享同一套底层架构，都是基于 Claude Agent SDK 构建的。区别主要在交互方式：Claude Code 面向终端，需要用户懂命令行，适合开发者；Cowork 面向图形界面，普通用户也能上手，适合所有人。

也就是说，Cowork 把原本只有程序员才能享受的 Agent 能力，开放给了更广泛的用户群体。

安全设计：虚拟机 + 权限隔离

给 AI 访问你的文件夹，听起来有点让人紧张，所以 Anthropic 在安全上也下了不少功夫。

知名技术布道者和 Django 创始人 Simon Willison 拿到 Cowork 之后第一时间做了测试。他发现 Claude 执行命令时的文件路径长这样：

/sessions/zealous-bold-ramanujan/mnt/blog-drafts

这个奇怪的路径引起了他的注意。他用 Claude Code逆向分析了 Claude 桌面应用，发现 Cowork 实际上是在一个虚拟机里运行的。Anthropic 用了 Apple 的 VZVirtualMachine 虚拟化框架，启动了一个自定义的 Linux 环境。

也就是说，你授权的文件夹会被挂载到这个虚拟机里。Claude 能访问的只有你明确授权的那个文件夹，其他东西它碰不到。

除了文件系统隔离，Cowork 还有几个安全机制：执行重要操作前会先问你，只能使用你授权的外部数据源，需要网页操作时配合 Claude in Chrome 扩展使用。

风险提示

即便做了很多风险控制，很多安全问题也不容忽视，所以在使用上有很多地方需要注意：

指令要清晰。 Cowork 会按照你说的去做，如果你的指令模糊或者有歧义，Claude 可能会做出你意料之外的事情，包括删除文件。

提示词注入风险需要关注。 如果你让 Claude 处理来自互联网的内容，里面可能藏着恶意指令。Anthropic 虽然已经做了防御，但这个问题整个行业都还没有完美解决方案。

警惕敏感操作。 不要把包含敏感信息的文件夹授权给 Claude；使用 Claude in Chrome 时，只在可信的网站上操作；留意 Claude 的可疑行为，发现异常及时中断。

虽然让普通用户“留意可疑行为”其实不太现实，因为大多数人根本不知道什么叫提示词注入。但 Cowork 至少比 Claude Code 多了一层文件系统沙箱保护，算是一个进步。

怎么开始用

目前 Cowork 还是研究预览版，只对 Claude Max 订阅用户开放，月费 $100 或 $200。

使用方法很简单：下载最新版的 Claude macOS 应用（https://claude.com/download），打开应用点击侧边栏的 Cowork 标签，选择一个文件夹就能开始使用。

如果你不是 Max 用户，可以加入等待列表，后续会逐步开放。

写在最后

AI Agent 正在从开发者工具走向大众工具。Claude Code 已经证明了 Agent 模式的威力，它不只可以聊天，更能真正帮你干活。但命令行的门槛把很多人挡在了外面。Cowork 把这个门槛拆掉了。

可以预测，OpenAI、Google 以及其他大模型厂商肯定会跟进推出类似的产品。

对于普通用户来说，这是一个值得关注的方向。AI 从帮你写东西进化到帮你干事情，中间隔着的就是 Agent 这一步。

至于能不能真正用起来、好不好用，那就得等更多人去探索了。毕竟这还只是一个早期的、原始的产品，还需要时间的检验。

相关资源：

• Anthropic Cowork 发布博客：https://claude.com/blog/cowork-research-preview

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Anthropic 万字长文：AI Agent 评估体系全解析

题记：本文编译自 Anthropic 工程博客《Demystifying evals for AI agents》，发表于 2026 年 1 月 9 日。原文由 Mikaela Grace、Jeremy Hadfield、Rodrigo Olivares 和 Jiri De Jonghe 撰写。本文在翻译基础上做了整理和补充，希望能帮中文读者厘清 AI Agent 评估这件事到底该怎么做。

做过 Agent 开发的朋友应该都有体会：调试 Agent 是个苦力活。

你改了个 Prompt，跑了几个 case 看起来没问题，结果上线后用户投诉说“感觉变蠢了”。你想验证到底是真的退步了还是用户错觉，却发现除了手动测几个场景，没有任何靠谱的办法。

这种“盲飞”状态，Anthropic 见得太多了。他们和很多团队合作时发现一个规律：早期靠直觉和手动测试能走挺远，但一旦 Agent 进入生产环境开始扩展，没有系统化评估就会开始出各种问题。

这篇文章就是 Anthropic 把内部实践和客户合作经验整理出来的评估指南。我自己在做 Agent 相关项目时也踩过不少坑，读完觉得挺有启发，翻译分享给大家。

评估的基本概念

先把几个基本概念说清楚。

评估（eval）说白了就是给 AI 系统做测试：给它一个输入，用评分逻辑对输出打分，看它做得怎么样。本文讨论的主要是自动化评估——开发阶段不需要真实用户参与就能跑的测试。

单轮评估很简单：一个提示、一个响应、一套评分逻辑。早期 LLM 主要就靠这个。但 Agent 不一样，它是多轮运行的，会调用工具、修改状态、根据中间结果动态调整。这就让评估变得复杂了。

简单评估是"提示→响应→评分"。Agent 评估要复杂得多：Agent 拿到工具和任务后，会执行多轮"工具调用+推理"循环，最后通过单元测试等方式验证结果。

这里有个有趣的例子：Opus 4.5 在做 τ2-bench 的航班预订任务时，发现了政策里的一个漏洞，给用户找到了更好的解决方案。按评估的字面标准它“失败”了，但实际上它比标准答案更聪明。这说明 Agent 评估不能太死板，前沿模型的创造性可能超出你的预期。

为了构建 AI Agent 评估系统，Anthropic 定义了一套术语，我整理一下关键的几个：

• 任务（Task）：一个独立的测试用例，有明确的输入和成功标准
• 试验（Trial）：对任务的一次尝试。因为模型输出有随机性，通常要跑多次
• 评分器（Grader）：打分逻辑，一个任务可以有多个评分器
• 转录（Transcript）：一次试验的完整记录，包括所有工具调用、推理过程、中间结果
• 结果（Outcome）：试验结束时环境的最终状态。Agent 说"航班已预订"不算数，数据库里真的有预订记录才算
• 评估框架（Evaluation Harness）：端到端运行评估的基础设施，负责提供指令和工具、并发运行任务、记录步骤、评分和汇总结果
• Agent 框架（Agent Harness）：也叫脚手架（Scaffold），让模型能作为 Agent 运行的系统。评估一个 Agent 时，实际上是在评估框架和模型的协同工作
• 评估套件（Evaluation Suite）：一组为衡量特定能力或行为而设计的任务集合，比如客服评估套件可能测试退款、取消订单、问题升级等场景

为什么需要评估体系？

说实话，很多团队觉得评估是额外负担，会拖慢发布节奏。早期确实可以不要，手动测测、内部试用、凭直觉判断，能走挺远。

问题是，总有个临界点会到来。

典型场景是这样的：用户反馈说 Agent 改版后变差了，而你的团队两眼一抹黑，除了猜和手动验证，没有任何办法确认。调试变成了被动响应——等投诉、手动复现、修 bug、祈祷没引入新问题。你无法区分真正的退化和噪声，无法在发布前自动测试数百个场景，也无法量化改进效果。

Claude Code 的演进就是个例子。一开始是基于员工和用户反馈快速迭代的，后来才加入评估——先是简洁性、文件编辑这些局部领域，后来扩展到过度设计等更复杂的行为。评估帮助识别问题、指导改进，成了研究和产品团队协作的桥梁。

Descript 做视频编辑 Agent，他们围绕三个维度构建评估：不出错、严格遵循要求、做得好。从手动评分演进到 LLM 评分器，定期和人工校准。而 Bolt 起步晚一些，在 Agent 已经广泛使用后才开始建评估，3 个月搭了一套评估系统，包括静态分析评分、浏览器 Agent 测试应用、LLM 评委评估指令遵循等。

评估还有个隐藏价值：当更强的模型发布时，有评估的团队能快速验证、调整提示词，几天内就可以完成升级。没有评估的团队则要花数周进行手动测试。

一旦评估体系建起来，很多东西就是免费的：延迟、token 用量、成本、错误率都可以在固定任务集上持续追踪。评估的复利效应很容易被忽视，因为成本是前期可见的，收益是后期累积的。

不同类型 Agent 怎么评估

目前大规模部署的 Agent 主要有四类：编码 Agent、研究 Agent、计算机操作 Agent、对话 Agent。评估方法有共性，也有差异。

三类评分器

Agent 评估通常组合三类评分器：基于代码的、基于模型的、以及人工评分。

基于代码的评分器——字符串匹配、单元测试、静态分析这些。优点是快、便宜、客观、可复现；缺点是脆弱，对有效变体不够宽容，缺乏细微判断能力。

基于模型的评分器——用 LLM 做评委，基于评分标准打分、自然语言断言、成对比较等。优点是灵活、能处理开放式任务；缺点是非确定性、比代码贵、需要和人工校准。

人工评分器——领域专家评审、众包判断、抽样检查。是黄金标准，但贵、慢、难以规模化。

实践中通常是组合使用。Anthropic 的建议是：尽可能用确定性评分器，必要时加 LLM 评分器，人工评分器用来校准。

能力评估 vs 回归评估

这是两种不同目的的评估。

能力评估问的是“Agent 擅长做什么”，通过率应该从较低开始，针对 Agent 难以完成的任务，让团队有一个目标可以努力提升。

回归评估问的是“Agent 还能做好它以前能做的事吗”，通过率应该接近 100%，分数下降意味着出问题了。

两者要同时跑。能力评估上爬坡时，回归评估确保不会在其他地方翻车。等能力评估通过率高了，可以升级到回归套件里。

编码 Agent

编码 Agent 写代码、跑测试、调 bug，和人类开发者干的事差不多。评估相对简单，因为软件是可以客观验证的：代码能跑吗？测试过了吗？

SWE-bench Verified 和 Terminal-Bench 是两个常用基准。SWE-bench 给 Agent 真实的 GitHub issue，通过运行测试套件评分；Terminal-Bench 测端到端任务，比如从源码编译 Linux 内核或训练一个 ML 模型。LLM 在 SWE-bench 上的表现提升非常快，仅一年就从原来的 40% 提到了 80% 以上。

除了测试通过，对代码质量规则、工具调用方式、用户交互行为等转录进行评分通常也很有用。

比如，考虑一个编码任务，代理需要修复一个认证绕过漏洞。如下示例 YAML 文件所示，可以同时使用评分器和指标来评估该代理。

task:id:"fix-auth-bypass_1"desc:"Fix authentication bypass when password field is empty and ..."graders: -type:deterministic_testsrequired: [test_empty_pw_rejected.py, test_null_pw_rejected.py] -type:llm_rubricrubric:prompts/code_quality.md -type:static_analysiscommands: [ruff, mypy, bandit] -type:state_checkexpect:security_logs: {event_type:"auth_blocked"} -type:tool_callsrequired: - {tool:read_file, params: {path:"src/auth/*"}} - {tool:edit_file} - {tool:run_tests}tracked_metrics: -type:transcriptmetrics: -n_turns -n_toolcalls -n_total_tokens -type:latencymetrics: -time_to_first_token -output_tokens_per_sec -time_to_last_token

实践中，编码评估通常就是单元测试加 LLM 代码质量评分，只有在需要时才会添加额外的评分器和指标。

对话 Agent

对话 Agent 在客服、销售或者辅导这些场景和用户交互。跟编码 Agent 不同，交互本身的质量也是评估内容的一部分。

对话 Agent 的成功可以是多维度的：工单解决了吗？在 10 轮内完成了吗？语气恰当吗？τ-Bench 和 τ2-Bench 就是这样设计的，用一个模型扮演用户，另一个是被测 Agent，模拟真实场景。

对话 Agent 评估通常需要第二个 LLM 模拟用户，这和其他类型不太一样。

比如，对于客服任务，Agent 需要为一位沮丧的客户处理退款，评估可以这么设计：

graders: -type:llm_rubricrubric:prompts/support_quality.mdassertions: -"Agent showed empathy for customer's frustration" -"Resolution was clearly explained" -"Agent's response grounded in fetch_policy tool results" -type:state_checkexpect:tickets: {status:resolved}refunds: {status:processed} -type:tool_callsrequired: - {tool:verify_identity} - {tool:process_refund, params: {amount:"<=100"}} - {tool:send_confirmation} -type:transcriptmax_turns:10tracked_metrics: -type:transcriptmetrics: -n_turns -n_toolcalls -n_total_tokens -type:latencymetrics: -time_to_first_token -output_tokens_per_sec -time_to_last_token

实践中，对话 Agent 的评估通常使用基于模型的评分器来评估交流质量和目标达成情况，因为许多任务可能有多个正确答案。

研究 Agent

研究 Agent 收集信息、综合分析、产出报告。这类评估最难，因为“好”是主观的。什么算“全面”、“有据可查”甚至“正确”？这都取决于具体场景：市场调研、收购尽职调查和科学报告各自有不同的标准。

BrowseComp 是个有意思的基准，其问题设计成容易验证但难以解决，专门用来测试 Agent 能不能在开放网络里大海捞针。

研究 Agent 评估要组合多种检查：基础性检查（声明有来源支持吗）、覆盖度检查（关键事实都包含了吗）、来源质量检查（来源权威吗）。鉴于研究质量的主观性，LLM 评分标准要经常和人类专家校准，以便有效评估这些 Agent 。

计算机操作 Agent

计算机操作 Agent 就跟人类一样，通过屏幕截图、鼠标点击、键盘输入和滚动来操作软件。它的评估要在真实或沙盒环境运行，让其使用软件应用，并检查是否达成预期结果。

比如，WebArena 就是一个专门用来测试浏览器任务的评估标准，通过 URL 和页面状态检查导航是否正确，并对修改数据的任务进行后端状态核实（确认订单确实已下单，而不仅仅是出现了确认页面）。OSWorld 将其扩展到完整的操作系统控制。

浏览器 Agent 有个取舍：DOM 交互快但费 token，截图交互慢但省 token。Claude for Chrome 专门做了评估来检查 Agent 是不是在正确场景选择了正确工具，以便能够更快、更准确地完成浏览任务。

处理非确定性

Agent 行为在不同运行中都会有所不同，这让评估结果比看起来更难解读。同一个任务可能这次通过、下次就挂了；或者这次成功率 90%，而下次只有 50%。

有两个指标可以帮助捕捉这些细微差别：

pass@k：衡量 k 次尝试中至少一次成功的概率。k 越大，分数越高。pass@1 就是第一次就成功的概率，编码场景通常最关心这个。

pass^k：衡量所有 k 次尝试全部成功的概率。k 越大，分数越低。如果 Agent 每次有 75% 成功率，跑 3 次全过的概率是 (0.75)³ ≈ 42%。面向用户的 Agent 特别关心这个，因为用户期望每次都可靠。

k=1 时两个指标相同。到 k=10，pass@k 接近 100%，pass^k 降到 0%。选哪个取决于产品需求。

从 0 到 1 的实操路线图

这部分是 Anthropic 的实践建议，我觉得挺实用的，逐条说说。

收集任务

尽早开始，不要等完美。 很多团队觉得需要几百个任务才能开始，实际上 20-50 个从真实失败里提取的简单任务就够了。早期每次改动效果明显，小样本量就能检测到。评估拖得越久越难，早期产品需求自然转化为测试用例，等太久就得从线上系统反向推导成功标准了。

从手动测试的内容开始。 你每次发布前验证的行为、用户常用的场景、bug 追踪器和客服工单里的问题——这些都是现成的测试用例来源。按用户影响优先排序，有助于你把精力投入到最关键的地方。

任务要有明确参考答案。 好任务是两个领域专家独立看，会得出相同的通过/失败判定。任务里的歧义会变成指标噪声。每个任务都应该可以被正确遵循指令的 Agent 完成。评分者检查的所有内容都应该在任务描述中明确说明；Agent 不应该因为规范不清而失败。对于前沿模型来说，在多次尝试中通过率为 0%（即 0% pass@100）通常意味着任务本身有问题，而不是 Agent 能力不足。每个任务配一个参考解决方案，证明任务可解、评分器配置正确。

构建平衡的问题集。 测应该做的情况，也测不应该做的情况，这两者应该平衡。只测 Agent 应该搜索的情况，可能最终得到一个什么都搜索的 Agent。Anthropic 在做 Claude.ai 网络搜索评估时就踩过这个坑，在触发不足和触发过度之间找平衡花了好几轮迭代。

设计评分器

环境要稳定隔离。 评估中的 Agent 要和生产环境大致相同，每次试验从干净环境开始。残留文件、缓存、资源耗尽这些共享状态会引入噪声。Anthropic 有次发现 Claude 在某些任务上分数异常高，原因是它检查了之前试验的 git 历史——这就是环境隔离没做好。

评估结果而非路径。 人们通常本能地想要检查 Agent 是否按照非常具体的步骤操作，比如按正确顺序调用工具。Anthropic 发现这太死板了，Agent 经常找到设计者没预料到的有效方法。为了不无谓地限制创造力，更好的做法是评估 Agent 得产出，而不是它采取的路径。

加入部分得分。 对于包含多个环节的任务，应设置部分得分。比如客服 Agent 正确识别了问题、验证了客户身份，但没能处理退款，这明显比直接失败的好。在结果中体现这种成功的连续性非常重要。

小心评估本身的 bug。 Opus 4.5 最初在 CORE-Bench 上得分 42%，后来发现是评分器问题：期望96.124991…却对 96.12 判错、任务规格模糊、随机任务无法复现。修复后分数一下就跳到了 95%。仔细复查任务和评分器有助于避免这些问题，并注意让你的评分具备防止绕过或破解的能力。Agent 不应该轻易作弊通过评估。

长期维护

读转录轨迹。 这点很重要。除非你读了很多试验的轨迹和评分，否则你无法知道评分器是不是在正常工作。任务失败时，轨迹告诉你 Agent 是真的错了，还是评分器拒绝了有效解决方案。

监控饱和度。 100% 通过的评估只能追踪回归，不能提供改进信号。比如 SWE-Bench 分数今年从 30% 涨到了 80%+，已经快饱和了。Qodo 最初觉得 Opus 4.5 一般，后来发现是他们的评估不够难，没能捕捉到复杂任务上的提升。

让更多人贡献评估。 评估套件是一个需要持续关注和明确归属的动态工具，Anthropic 推荐采用评测驱动的开发方式：在 Agent 具备相关能力前，先构建评测来定义预期能力，然后不断迭代，直到智能体表现良好。而对于评估来说，最接近产品需求和用户的人最有资格定义成功。在 Anthropic，产品经理、客户成功经理甚至销售通过 Claude Code 就能以 PR 形式贡献评估任务。

评估不是万能的

自动化评估能在不影响用户的情况下跑成千上万个任务，但这只是理解 Agent 表现的众多方式之一。完整的图景还包括生产监控、用户反馈、A/B 测试、手动轨迹审查、系统性人工评估。

每种方法有各自的优劣和适用阶段：

• 自动化评估——上线前和 CI/CD 的第一道防线，每次改动都跑
• 生产监控——上线后检测分布漂移和意外失败
• A/B 测试——有足够流量后验证重大改动
• 用户反馈和轨迹审查——持续填补空白
• 系统性人工研究——校准 LLM 评分器、评估主观输出

这就像安全工程的瑞士奶酪模型——没有单一方法能捕捉所有问题，多层组合才能互相补位。

写在最后

没有评估的团队会陷入被动循环——修一个问题引入另一个，分不清退化和噪声。有评估的团队发现相反的情况：失败变成测试用例，测试用例防止回归，指标取代猜测。

Anthropic 总结的原则：

• 尽早开始，不要等完美
• 从真实失败中获取任务
• 定义明确的成功标准
• 组合多种评分器
• 确保问题足够难
• 持续迭代提高信噪比
• 一定要读转录轨迹

如果不想从零搭基础设施，这几个框架可以考虑：

• Harbor：专为容器化环境设计，支持跨云厂商大规模跑试验
• Promptfoo：轻量开源，YAML 配置，Anthropic 自己也在用
• Braintrust：离线评估+生产可观测性+实验追踪一体
• LangSmith：和 LangChain 生态紧密集成
• Langfuse：自托管开源方案，适合有数据驻留要求的团队

需要注意的是，框架可以加快起步，但最终效果取决于你用于评估任务的质量。建议尽快选定一个框架，将精力集中在高质量测试用例和评分器的迭代上。AI Agent 评估仍是新兴领域，发展迅速，评估方法需根据实际情况不断调整。

相关资源：

• 原文链接：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• 构建高效的 AI 代理系统：https://www.anthropic.com/engineering/building-effective-agents
• Agent SDK 文档：https://platform.claude.com/docs/en/agent-sdk/overview
• SWE-bench Verified：https://www.swebench.com/SWE-bench/
• Terminal-Bench：https://www.tbench.ai/

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

这两年 AI 编程助手火得一塌糊涂。GitHub Copilot、Cursor、Codex、Claude Code……工具一个比一个强，用起来确实爽。只需要用自然语言描述需求，AI 就能帮你写代码、改 Bug、跑测试，甚至排查之前让你绞尽脑汁的线上问题。

与此同时，Anthropic、OpenAI 这些前沿公司也在持续分享他们构建 Agent 的实践经验。比如虽然 Anthropic 家的模型在国内禁用了，但他们的 Engineering Blog 简直是个宝藏，持续分享很多关于 AI Agent 构建的实践干货，每次读完都有意犹未尽的感觉。

作为一个工程师，光看这些文章还不过瘾，忍不住就想动手实现一下。看到工具设计的最佳实践，就想自己写几个试试效果。这种“看完就想写代码”的冲动，大概是职业病吧。

但用得越多，我越有一个困惑。

这些 Agent 到底是怎么工作的？不是说“LLM + 工具 + 循环 ”这种笼统的回答。我想知道的是更具体的东西——它怎么决定什么时候读文件、什么时候执行命令？工具调用是怎么串起来的？内存怎么管理？上下文工程是怎么串起来的？

说白了，会用 AI Agent 和理解 AI Agent 背后的详细原理，是两回事。

那就自己造一个吧

想明白这件事之后，我决定自己动手造一个 Coding Agent。不是为了重复造轮子，也不是觉得 Claude Code 不够好。纯粹是想搞清楚这个黑盒里面到底装了什么。

Agent 听起来很玄乎，但拆开来看，核心就是 LLM + 工具 + 循环。LLM 思考，决定用什么工具，执行工具，拿到结果，继续思考……如此往复。这个循环里藏着很多细节——工具怎么定义？结果怎么反馈给 LLM？什么时候该停下来？怎么处理错误？这些问题，只有自己实现一遍才能真正搞懂。

还有一个原因是想有个试验田。看到一篇论文说“某某方法能提升 Agent 表现”，想试试？用 Claude Code 你没法定制化它的内部工作流程。但如果你有自己的 Agent，分分钟就能加上去跑一下看效果。

自己的 Agent 就是自己的试验田，想种什么种什么，想怎么折腾怎么折腾。

于是有了 Koder

基于这些想法，我写了 Koder——一个实验性质的终端 AI 编程助手。

先说清楚定位。这是一个学习/研究型项目。它不是要取代 Claude Code 或 Cursor，而是提供一个可以研究、可以魔改、可以学习的开源实现，并且使用了我一直都熟悉的 Python 开发。底层基于 OpenAI Agents SDK 构建，省去了自己造轮子实现 Agent 循环的麻烦，可以专注在工具设计和上下文工程上。

功能上，该有的基本都有。通过 LiteLLM 支持 OpenAI、Anthropic、Google、GitHub Copilot 等 100 多个模型提供商，也可以用 Claude Pro/Max、ChatGPT Plus、Google Gemini、Antigravity 这些订阅服务，不用单独买 API。

基本的工具系统也已经有了，除了内置的文件读写、Shell 命令、Todo 管理等常用工具之外，Koder 也支持 MCP、Skills、AGENTS.md、会话管理（用 SQLite 存储）、Token 和费用跟踪等常用的功能。

安装也很简单，推荐用 uv，速度快不说，依赖也完全隔离，不会污染其他 Python 项目：

uv tool install koder

当然，pip 安装也是支持的：

pip install koder

上手试试

安装完之后，设置一下 API Key 和模型就能用了：

export OPENAI_API_KEY="your-api-key"export KODER_MODEL="gpt-5.2"koder

Koder 会自动检测你的模型来决定用哪个 Provider。如果你有 Claude Max 或 ChatGPT Plus 订阅，也可以用 OAuth 登录：

koder auth login claude# Claude Pro/Maxkoder auth login chatgpt# ChatGPT Pluskoder auth login google# Google Geminikoder auth login antigravity# Google Antigravity# 登录后设置模型开始使用export KODER_MODEL="claude/claude-opus-4-5-20251101"koderexport KODER_MODEL="chatgpt/gpt-5.2"koder

基本使用方式和其他命令行 AI Agent 差不多。直接运行koder 进入交互模式，或者koder "你的问题" 单次提问。想指定会话名的话加个-s 参数，起个自己的会话名字。所有会话都会存到~/.koder/ 中，下次可以继续聊。

除了环境变量，Koder 也支持通过修改~/.koder/config.yaml 来设置模型、参数以及 MCP。这些功能的文档在项目 README 里都有，这里就不展开了。

拆开看看里面有什么

写这个项目的过程中，我对 Agent 架构的理解深了不少。先看整体流程，再聊几个有意思的设计。

敲下回车之后发生了什么

用户敲下koder "帮我写个XXX函数" 之后，发生了什么？

CLI 入口cli.py 先解析参数，加载当前目录的AGENTS.md 作为项目上下文。这个设计应该是所有 AI Agent 的标配了——每个项目可以有自己的指令文件，告诉 Agent 这个项目的技术栈、代码规范、常用命令。

接下来是关键的懒加载设计。AgentScheduler 初始化时并不创建 Agent，而是等到真正收到第一条消息时才调用_ensure_agent_initialized()。为什么这么做？因为创建 Agent 要加载工具、连接 MCP 服务器、初始化模型客户端，挺重的。如果用户只是想跑个koder config show 查看配置，没必要把整个 Agent 都拉起来。

调度器怎么指挥全局

AgentScheduler 是整个系统的指挥中心。它维护了一个信号量asyncio.Semaphore(10) 来控制并发，防止同时跑太多请求把 API 打爆。

流式输出的处理是我花时间最多的地方。用户看到的是文字一个字一个字蹦出来，背后其实有不少门道。

问题出在哪？Agent 的输出是交错的。它可能先说一句话，然后调用工具，工具还可以多个一起调用，工具返回结果后继续说话，中间还可能穿插更多工具调用。如果不做处理，用户看到的就是一团乱麻。

StreamingDisplayManager 用了一个简单但有效的方案。它维护一个pending_tool_calls 计数器，Agent 每发起一次工具调用就加一，工具返回结果就减一。关键在于：只有计数器为零的时候，文字才会立即显示。工具调用期间产生的文字会先攒着，等工具执行完再一起输出。

还有个细节是怎么把工具结果匹配回对应的调用。active_tool_calls 字典用call_id 做 key，工具结果返回时根据 id 找到对应的调用记录。如果 id 匹配不上（有些模型不返回 id），就退化成先进先出的队列模式。

还有个小细节是 ESC 键取消。在 Unix 终端下，通过select.select() 做非阻塞键盘检测，用户按 ESC 可以立即中断当前执行。这个功能实现起来不难，但对用户体验提升很大。在 Agent 跑偏的时候，能快速止损。

工具怎么注册和管理

工具用装饰器注册，类似这样：

@function_tooldefread_file(model: FileReadModel)-> str:# 实现

get_all_tools() 函数收集所有工具，然后给每个工具动态挂上skill_restriction_guardrail。这个守卫会检查当前激活的 Skill 是否允许使用某个工具。比如你定义了一个只能读写文件的 Skill，它就没法调用 Shell 命令。

这种设计的好处是工具定义和权限控制解耦。写工具的时候不用操心权限，守卫统一处理。

聊太多了怎么办

EnhancedSQLiteSession 继承了 OpenAI Agents SDK 的SQLiteSession，加了一个关键功能——token 感知的上下文压缩。

每次添加消息时，它会用 tiktoken 估算当前对话的 token 数。超过阈值（默认 50k）就触发压缩：保留所有用户消息（代表意图），把 Assistant 的回复做摘要。这样既不会丢失关键信息，又能控制 context 长度。

当然这个实现还是比较简陋的，很多 Context Engineering 的实践和想法暂时还没有加进来。

API 抽风了怎么办

LLM API 偶尔抽风是常态，适当加些错误处理和重试是必要的。RetryingLitellmModel 封装了 backoff 库的指数退避重试：

@backoff.on_exception( backoff.expo, (ServiceUnavailable, RateLimit, APIConnection, Timeout), max_tries=3, jitter=backoff.full_jitter,)asyncdefget_response(...):

遇到限流、超时、服务不可用，自动重试最多 3 次，每次间隔指数增长加随机抖动。这个在高峰期特别有用，很多时候第一次失败、第二次就过了。

写在最后

对工程师来说，最好的学习方式从来都不是看文档、看论文，而是动手写代码。

Agent 这个领域也一样。概念可以很快理解，“LLM + 工具 + 循环”一句话就能说清楚。但真正的门道都藏在细节里：工具怎么设计才好用？上下文怎么管理才高效？用户体验怎么打磨才顺手？这些东西，只有自己踩过坑才能真正明白。

自己写过一遍之后，再看 Claude Code 或 Cursor 的设计，感觉完全不一样了。很多以前觉得理所当然的功能，现在知道背后藏着多少细节。

Koder 的代码完全开源，欢迎来看看、试试、提 PR。项目地址在 GitHubhttps://github.com/feiskyer/koder。

在 AI Agent 大潮中，不要只做一个旁观者。以身入局，才能真正理解这场变革。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

题记：Notion CEO Ivan Zhao 最近发表了一篇长文《蒸汽、钢铁与无限心智》，通过类比钢铁和蒸汽机的历史，探讨了 AI 如何重塑知识工作——从提升个人效率，到改变组织形态，乃至重构整个经济结构。文章视野开阔，类比精准，值得一读。原文链接：Steam, Steel, and Infinite Mindshttps://x.com/ivanhzhao/status/2003192654545539400。以下为全文翻译。

每个时代都有它的“奇迹材料”。钢铁锻造了镀金时代，半导体开启了数字时代，现在轮到无限心智的 AI 了。历史一再证明：谁掌握了那个时代的核心材料，谁就定义了那个时代。

19 世纪 50 年代，安德鲁·卡内基还是个在匹兹堡泥泞街道上奔跑的电报童。那时候，六成美国人还在务农。但仅仅两代人之后，卡内基和他的同辈们就锻造出了现代世界的雏形。马车被铁路取代，烛光变成了电灯，生铁炼成了钢铁。

再往后，工作重心从工厂转移到了办公室。今天，我在旧金山经营一家软件公司，为数百万知识工作者打造工具。在硅谷，人人都在谈论 AGI，但全球二十亿白领中的大多数还没真正感受到它的影响。知识工作很快会变成什么样？当组织架构中开始加入永不休眠的心智时，会发生什么？

这些问题很难回答，因为未来总是披着过去的外衣出现。早期的电话通话像电报一样简短，早期的电影看起来就像把舞台剧拍下来。麦克卢汉管这叫“通过后视镜驶向未来”。

你看，今天的 AI 聊天机器人长得就像 Google 搜索框，我们正处于每次技术变革都会经历的那个尴尬过渡期。

接下来会怎样，我也没有全部答案。但我喜欢借助几个历史类比，来思考 AI 如何在不同尺度上发挥作用——从个人、到组织、再到整个经济体。

个人：从自行车到汽车

最先感受到变化的，是程序员这个群体。

我的联合创始人 Simon 曾是我们常说的 10 倍工程师，但他现在很少亲自写代码了。走过他的工位，你会看到他同时指挥三四个 AI 编程 Agent。这些 Agent 不只是打字更快，它们还会思考。几个 Agent 加起来，他变成了 30-40 倍的工程师。他会在午饭前或睡觉前把任务排好队，让它们在他不在的时候继续干活。某种意义上，他已经成了“无限心智”的管理者。

这让我想起乔布斯的一个比喻。20 世纪 80 年代，他把个人电脑称为“心灵的自行车”。十年后，我们铺设了名为互联网的信息高速公路。但时至今日，大多数知识工作仍然靠人力驱动。我们一直在高速公路上蹬自行车。

有了 AI Agent，像 Simon 这样的人已经从骑自行车升级到了开汽车。

那其他类型的知识工作者呢？什么时候能开上车？我觉得有两个问题必须先解决。

**首先是上下文太分散。**编程的工具和信息通常集中在一个地方：IDE、代码仓库、终端。但一般的知识工作分散在几十个工具里。要让一个 AI Agent 要起草一份产品简报，它得从 Slack 聊天记录、战略文档、上季度的数据看板，还有只存在某人脑子里的经验里提取信息。今天，人类就是那个粘合剂，靠复制粘贴和切换浏览器标签把这一切拼起来。只要上下文没有被整合，Agent 就只能困在狭窄的场景里。

**其次是结果难以验证。**代码有个很好的属性：你可以用测试和报错来验证它对不对。模型开发者利用这一点来训练 AI，让它的编程能力越来越强（比如强化学习）。但你怎么验证一个项目管理得好不好，一份战略备忘录写得怎么样？我们还没找到让模型在这类工作上持续进步的方法。所以目前人类还得盯着，来监督、引导，告诉它什么是好的。

但人盯着也有个度。今年编程 Agent 的进展让我们意识到，让人事事把关并不总是好事。这就像让人亲自检查流水线上的每一颗螺栓，或者走在汽车前面为它开路（1865 年英国还真有这么一条《红旗法案》）。我们希望人类站在一个更有杠杆的位置来监督全局，而不是被困在每一个细节里。一旦上下文被整合、工作变得可验证，数十亿工作者就会从蹬自行车升级到开汽车，再从开汽车升级到自动驾驶。

组织：钢铁与蒸汽

说完个人，再来看组织。

公司这东西，其实是个挺近的发明。而且随着规模扩大，它会退化，最终触及天花板。

几百年前，大多数公司不过是十几个人的作坊。现在我们有了数十万员工的跨国企业。但沟通基础设施（说白了就是靠会议和消息连接起来的人脑）扛不住这么大的负载。我们试图用层级、流程和文档来应对，但本质上我们一直在用人的尺度去解决工业级的问题，就像用木头建摩天大楼。

有两个历史故事，可以帮我们想象新材料如何重塑组织。

第一个是钢铁。在钢铁出现之前，19 世纪的建筑最多盖到六七层。铁虽然坚固，但又脆又重；楼层加多了，建筑就会在自重下坍塌。钢铁改变了一切：它既坚固又有韧性，框架可以更轻，墙壁可以更薄，建筑突然可以拔地几十层。全新的建筑形态成为可能。

AI 就是组织的钢铁。它可以在工作流中保持上下文，在需要时把关键决策推到你面前，同时过滤掉噪音。人与人之间的沟通不再需要当承重墙。每周两小时的对齐会议可以变成五分钟的异步审阅；原本需要三级审批的决策，可能几分钟就能完成。公司可以真正扩张，而不用接受我们习以为常的那种退化。

第二个故事关于蒸汽机。工业革命初期，纺织厂都建在河边，靠水车驱动。蒸汽机出现后，工厂主们一开始只是把水车换成蒸汽机，其他一切照旧。生产力提升并不明显。

真正的突破发生在他们意识到可以彻底摆脱水源的时候。他们把工厂建到离工人、港口和原材料更近的地方，围绕蒸汽机重新设计布局。后来电力普及，工厂主们又进一步把动力分散化，不再依赖中央传动轴，而是给每台机器配上独立电机。生产力由此爆发，第二次工业革命真正起飞。

今天的 AI 应用，还停留在“换掉水车”的阶段。我们把聊天机器人拧到现有工具上，其他一切照旧。我们还没认真想过：如果旧的约束不存在了，如果公司可以靠永不休眠的无限心智来运转，组织应该长什么样？

在 Notion，我们一直在做实验。除了 1000 名员工，我们还有 700 多个 Agent 在处理重复性工作：做会议记录、回答问题、整合散落在各处的组织知识、处理 IT 请求、记录客户反馈、帮新员工了解福利政策、写周报——这样大家就不用再复制粘贴了。而这只是开始。真正的收益空间，只受限于我们的想象力和惯性。

经济：从佛罗伦萨到超级城市

钢铁和蒸汽不只改变了建筑和工厂，它们改变了城市本身。

几百年前，城市还是人的尺度。你可以在四十分钟内走遍佛罗伦萨。生活的节奏，取决于一个人能走多远、声音能传多响。

然后，钢架结构让摩天大楼成为可能，蒸汽机驱动的铁路把市中心和腹地连起来。电梯、地铁、高速公路接踵而至。城市在规模和密度上急剧膨胀，如东京、重庆、达拉斯等等。

这些城市早已不再是放大版的佛罗伦萨，而是截然不同的生活方式。超级城市让人感到迷失、匿名，也更难掌控，这是规模带来的代价。但它们同样带来了更多机会和更大的自由——更多的人做更多的事，所产生的可能性远远超出一座文艺复兴时期小城的承载范围。

我觉得，知识经济正在经历同样的转变。

今天，知识型工作已占美国近一半的 GDP，但这些工作仍以人为核心：几十人的团队，依靠会议和邮件推进流程，一旦组织规模超过几百人，效率就容易下降。我们用石头和木头建造的，依然是一个个佛罗伦萨。

当 AI Agent 大规模应用后，我们将构建一个类似东京的系统——成千上万个 Agent 与人类相互连接，跨越时区持续运转，无需等待任何人醒来，工作流程高效流畅，并在关键环节精准引入人类决策。

这种体验将截然不同。速度更快，杠杆更高，但初期也会让人感到不适应。周会、季度规划、年度评审等传统节奏可能不再适用，新的节奏将逐渐形成。我们会失去一些熟悉感，但换来的是更大的规模和更快的速度。

超越水车

每一种“奇迹材料”都需要人们不再用后视镜看世界，而是开始想象全新的可能。卡内基看到了钢铁，便看见了城市的天际线；兰开夏的工厂主看到了蒸汽机，便看见了不再依赖河流的工厂。

如今，我们仍处在 AI 的“水车阶段”：只是把聊天机器人嵌入旧有的工作流程，其他一切未变。我们不能只把 AI 当作副驾驶，而应设想：当组织拥有钢铁般的支撑，当琐事都能交给永不休眠的智能，知识工作会变成什么样？

钢铁、蒸汽、无限心智。下一道天际线就在前方，等着我们去创造。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

如果你还在观望到底要不要在项目里使用 AI Agents，Anthropic 刚刚发布的《2026 State of AI Agents Report》会给你一个明确答案。

报告调研了 500 多家企业，发现 57% 的企业已经部署了多阶段工作流的 AI Agent。注意，这已早不是之前那种简单的聊天机器人，而是能独立完成客服解答、员工入职这类复杂任务的 AI 系统。并且，80% 的企业已经看到了真金白银的投资回报。

这个 80% 还挺意外的。要知道任何新技术从试点到规模化，再到产生实际收益，通常需要好几年时间。AI Agents 才火了多久？去年大家还在讨论要不要试试，今年就已经有八成企业看到回报了。

代码开发这件事变了

报告里有个数据特别值得关注：90% 的企业都在使用 AI 辅助编程。

我自己也在用 Claude Code、Codex CLI 以及 Github Copilot 这些 AI 编程工具，感受特别明显。以前写一个新功能，要先查文档、看示例、写代码、调试，整个流程下来少说几个小时。现在很多时候直接告诉 Claude Code 想做什么，它不仅能生成代码，还会自动更新相关的测试、文档并自动运行测试和修复测试发现的问题。

这说明 AI 编程已经脱离试验阶段进入主流组织和公司，掌握 AI 编程也已经是很多公司招聘的门槛之一。

数据分析不再是专业团队的专利

除了代码开发，另一个渗透率很高的场景是数据分析。60% 的企业把这个列为影响最大的任务。

以欧莱雅为例。他们用 Claude 搭了个对话式分析平台，员工可以直接用自然语言提问，系统会自动查数据、做计算、生成报告。准确率从之前的 90% 提升到 99.9%，现在有 4.4 万人在用，每月处理 250 万条消息。

这个变化的价值在哪？不只是节省了 IT 资源，更关键的是决策速度变快了。以前市场团队想看个数据趋势，得提需求、排期、等开发，可能要一两周。现在几分钟就能拿到答案。业务迭代的节奏完全不一样了。

流程自动化的价值被低估了

报告里还有个数据：48% 的企业认为内部流程自动化是高价值场景。

德国数字银行 N26 在一年内部署了 15 个以上的 AI 应用，覆盖客服、反欺诈、文档处理等多个环节。平均从实施到测试只需要 1-2 周，在金融行业的合规要求下，这个速度快得不可思议。

报告显示效果出奇的好，目标流程的自动化率达到 70%，AI Agent 的部署让员工把更多时间投入到战略性工作（66%）、关系建设（60%）和技能发展（70%）上。

这种时间分配的改变，长期来看对团队竞争力的影响可能比短期效率提升更大。

AI Agent 落地的三个坑

虽然数据很好看，但这不意味着部署 AI Agent 是件容易的事。

报告列出了三个主要挑战。

1. 系统集成是最大的障碍。 46% 的企业把这个列为头号难题。

企业的 IT 环境往往很复杂：有几十年历史的遗留系统、不同时期采购的各种软件、自研的业务平台。AI Agent 要接入这些系统，就得一个个去适配。更麻烦的是，很多关键系统根本没有 API。

所以报告显示，47% 的企业选择了混合架构：一部分用现成产品，一部分自己开发。这样既能快速起步，又保留了定制化的灵活性。

2. 数据质量是第二个坑。 42% 的企业被这个问题困扰。

AI Agent 的能力很大程度上取决于它能获取什么样的数据。报告有个发现：输入的上下文长度每增加 1%，输出质量和长度就提升 0.38%。换句话说，给 AI Agent 的信息越丰富，它的表现就越好。

但很多企业的数据分散在各个系统里，格式不统一，质量也参差不齐。有些重要的知识甚至还在员工脑袋里，没有文档化。

3. 员工抵触是第三个挑战。 39% 的企业表示这是个问题。

技术问题最终都有解决方案，但人的问题更复杂。员工会担心 AI 会不会取代自己的工作，会不会让自己的技能贬值。如果这些担忧没有得到妥善处理，AI Agent 推广就会遇到软性阻力。

中小企业在这方面的挑战更大：51% 的中小企业把员工抵触列为主要障碍，大企业的这个比例要低一些。可能是大企业的变革管理经验更丰富，沟通机制也更完善。

2026 年的机会窗口

如果说 2025 年是 AI Agents 的“落地元年”，那 2026 年可能就是“规模化元年”。81% 的企业计划部署更复杂的 AI Agent 应用。

这个“更复杂”是什么意思？ 以前 AI Agent 可能只是帮你写代码，现在要能从需求分析、架构设计到测试部署，端到端地辅助整个开发流程。以前可能只是处理标准客服问题，现在要能协调多个部门解决复杂投诉。

这种升级带来的价值会更大，但对企业的要求也更高。数据基础要更扎实，系统集成要更深入，团队协作模式要更灵活。

写在最后

回到文章开头的问题：我们要不要在项目里用 AI Agents？

看完这份报告，我觉得答案已经很明确了。问题不是“要不要”，而是“怎么做才能最快见效”。

• 从高 ROI 领域切入，代码开发、数据分析、流程自动化都是验证过的场景。选一个和业务最相关的，小范围试点，快速迭代。

• 同时要重视数据基础设施。AI Agent 的效果取决于数据质量。与其期待 AI 有魔法，不如先把数据地基打牢。

• 技术和文化要同步推进。部署 AI Agent 不只是技术变革，更是组织文化变革。技术再先进，如果团队不适应，价值就释放不出来。

这个转变的速度比很多人预想的要快。你准备好了吗？

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

大多数人用 AI 编程助手的方式，其实是错的。

包括我自己。之前用 GitHub Copilot，后来又试了 Cursor、Claude Code 和 Codex。刚开始觉得挺神奇，让 AI 生成一段代码，几分钟就出来了。用多了就发现不对劲，生成的代码虽然能跑，质量参差不齐。有时候代码越改越乱，还不如自己写。

直到看了 OpenAI 工程师的实战分享，我才明白问题出在哪。

他们用 Codex 在 28 天内开发了 Sora Android 应用。4 个工程师，50 亿 tokens，搞定一个生产级应用。

OpenAI 有什么秘密武器吗？其实并没有。他们用的也就是已经开源的 Codex，现在任何开发者都可以安装使用。关键在于怎么用。

OpenAI 的核心就四个步骤：把 AI 当新员工培训，用计划文档引导长任务，让多个 AI 并行工作，重新定位人的角色。今天，我就带你一起看看 OpenAI 工程师是如何做到的。

大多数人踩过的坑

最常见的 AI 编程用法是什么？给 AI 扔一句话：帮我从零构建一个 XXX 应用。

OpenAI 的工程师也试过。开发 Sora Android 时，他们最初就是这么干的，给 Codex 提示词：根据 iOS 代码构建 Sora Android 应用，开始吧。结果呢？代码倒是生成了一大堆，技术上能跑，但产品体验很差，代码也不可靠。他们很快就放弃了。

AI 生成的代码为什么会这样？说白了，AI 的本能是让东西跑起来，而不是考虑长期可维护性。本该扩展现有的 view model，它却新建了一个；明明业务逻辑应该在 repository 层，它却放在 UI 层。用 OpenAI 工程师的话说，Codex 的本能是让东西跑起来，而不是优先考虑长期的代码整洁度。

真相其实很简单。AI 编程助手不是魔法棒，而是一个刚入职的高级工程师。能力很强，但需要入职培训，需要了解团队规范，需要明确的任务目标。

既然 AI 是个新员工，那就得按照新员工的方式来对待，先不着急开始干活，做好入职培训才是第一步。

第一步：先建地基，再盖大楼

时间紧，项目重，怎么办呢？ Fred Brooks 有句名言：给一个延迟的软件项目增加人手，只会让它更晚完成。OpenAI 团队没有违背这个定律，而是用了一个巧妙的方式：每个工程师都配备了 Codex，大幅提升单个工程师的影响力。

同时，在项目启动阶段，OpenAI 团队花了大量时间建立基础架构。手动设计模块化、依赖注入、导航系统，人工实现了身份验证和基础网络层。再亲手写了几个代表性功能，展示整个代码库应该遵循的规则和模式。

有了这些基础，再让 AI 参考这些文档和代表性功能列表，最终 Codex 写了大约 85% 的代码。但正是那精心设计的 15% 的基础，避免了后期昂贵的重构和返工。

当然，光有基础架构还不够。有些任务可能要跑几个小时，甚至一整夜。这种长时间任务怎么让 AI 保持在正确的轨道上？这是第二个关键点。

第二步：用计划文档引导长时间任务

OpenAI 工程师 Friel 在《Vibe Engineering with OpenAI’s Codex》中分享了一个案例：用 Codex 将一个构建工具从 Kotlin 完全重写为 Rust。从零开始，空目录，要求 100% 兼容原项目，包含完整的测试套件。

Rewrite https://github.com/Tinder/bazel-diff.git in Rust as bazel-differrous, starting from scratch in this empty dir.Use that repo as a submodule to write tests against. Use an execplan in plans/ to track your work and complete all of these requirements autonomously.Your driving goal is 100% full CLI compatibility between bazel-diff and bazel-differrous.Definition of done:- [ ] Well structured, modular implementation in modern, async Rust, with support for tracing, profiling, etc.- [ ] Design documents and other written artifacts in docs/ describing decisions made architecting the project- [] Thorough support for Bazel Bazel and Bazel Bazel "bzlmod" system, including new tests using MODULE. bazel.- [ ] Full CLI compatibility as a drop-in replacement for bazel-diff- [ ] Passing tests with a test harness you write that verifies output is byte-for-byte equal to bazel-diff- [ ] A comprehensive test suite with at least ten times the tests as bazel-diff- [ ] Use 'cargo-nextest' with timeouts to ensure tests are fast and reliable- [ ] GitHub Actions tested with 'nektos/act' to build, test, format, and lint- [ ] A 'Justfile" which can build, run tests, and verify all of the claims above- [ ] A great CONTRIBUTORS. md and other repository documentation- [ ] README. md describing bazel-differous and showcasing its performance improvements over bazel-diff- [ ] CREDITS! Credit the authors of bazel-diff for creating a great tool and the Bazel community

结果？Codex 独立工作了约 12 小时，完成了整个重写。

12 小时的运行产生了什么？不是 10 万行垃圾代码，而是约 500 行高质量代码、超过 200 轮的测试迭代、通过所有 CI 检查，还有完整的文档。这些代码被直接合并到了生产环境。

关键就在于 Exec Plan 这个东西。执行计划。

在开始实际编码前，让 Codex 先理解系统，读取相关文件，总结功能如何工作；制定计划，创建一个迷你设计文档，说明哪些文件需要修改、引入哪些新状态、逻辑如何流动；保存计划到文件中，以便跨会话使用；最后按照计划，一步步实现。

对于长时间运行的任务，Codex 还会创建一个监督者子代理，定期提醒主代理：这是你的总体目标，这是用户的要求，保持专注。

掌握了单个 AI 的用法，还可以更进一步。这是第三个技巧。

第三步：把一个 AI 变成一个团队

OpenAI 的 Codex 支持一个叫 Best of N 的功能（目前仅在 Codex Cloud 中支持）。用同一个提示词，让 4 个 Codex 实例同时工作，探索不同的实现方案。完成后，你会看到 4 个不同方案的实现细节，可以选择最好的那个，或者从每个方案中汲取灵感。

在 Sora Android 项目的高峰期，OpenAI 团队经常同时运行多个 Codex 会话。一个在做视频播放，一个在做搜索功能，一个在处理错误处理，有时还有一个在写测试或做重构。感觉不再像是用一个 AI 编程工具，而更像是在管理一个 AI. 团队。

但这也带来新的挑战。开发瓶颈从写代码变成了做决策、给反馈和集成变更。你从独奏者变成了乐队指挥。每增加一只虚拟的手，都会增加协调成本。

说到这里，可能有人会问：AI 能干这么多活，那工程师还要干什么？这正是我想说的第四点。

第四步：重新定位人类的角色

在 OpenAI 内部，超过 92% 的技术人员在使用 Codex。所有的 Pull Request 都会经过 Codex 审查。结果是捕获了很多复杂的 bug，工程师平均产出的 PR 数量增加了 70%，但这些都是真正合并到生产环境的高质量 PR。

如果 Codex 写了 85% 的代码，工程师在做什么？

架构和系统设计还是要人来做。Codex 不擅长做长期权衡，不知道如何在可维护性、性能和开发速度之间找到平衡。用户体验也离不开人。Codex 看不到应用实际运行的样子，不能注意到滚动感觉不对，或者某个流程令人困惑。

产品方向和品味更是要人来把握。如果你是那个对某个问题痴迷了数月或数年的人，你就拥有独特的视角来决定解决方案应该是什么样的。

代码审查变得更重要了。人类从写代码转向审查代码。但这不是负担，因为你有更多时间仔细阅读 PR、思考架构、测试应用。

有趣的是，OpenAI 内部不仅工程师在用 Codex，非技术团队也在用。产品经理用 Codex 创建功能原型，销售团队用 Codex 提出关于代码库的技术问题。这减轻了工程师的负担。

明天的超级工程师需要深刻的系统理解，需要与 AI 长期协作的能力，还需要品味和判断力。

写在最后

总结一下，OpenAI 工程师的实战经验可以归纳为几个核心原则：

1. 把 Codex 当作新入职的高级工程师对待。它有能力，但需要入职培训和明确的指导。

2. 先建立基础和规范。创建 AGENTS.md 文件，记录代码风格、架构模式、团队惯例。用代码展示而非文字描述，手写 1-2 个代表性功能，让 AI 从中学习。

3. 对于复杂任务，使用计划文档。先让 AI 理解系统、制定计划，再编码。代码审查不能省，即使是 AI 写的代码也要认真审查。

4. 给予丰富的上下文，让 AI 访问相关的代码库、文档、已有实现。对于不确定的方案，用 Best of N 并行探索，同时尝试多种方法。

5. 当 CI 失败时，把日志输出粘贴给 AI，让它修复。AI 擅长也乐于编写广泛的单元测试，让它多写。长时间任务往往能产生最好的结果，要有耐心。

也有一些要避免的：

1. 不要直接让 AI 构建整个应用，没有上下文和基础的一次性生成质量通常很差。不要跳过架构设计，AI 的本能是让东西跑起来，而不是优先考虑长期可维护性。
2. 不要期待 AI 推断你的偏好，每个 AI 实例都需要了解你的架构模式、产品策略、内部规范。不要让 AI 独自做重大架构决策，在哪里引入抽象、如何组织模块这些需要人类判断。

曾经可能需要我们四到六周才能实现的全新功能，现在几天就能完成 V1。这不仅仅是速度的提升，更是一种思维方式的转变。从能做什么到想做什么，从被积压的任务清单压垮到主动探索新的可能性。

当然，AI 的进步也重新定义了软件工程师的工作。写代码的时间少了，但对人的要求反而更高了。你需要理解产品设计、把握架构全局、指导"AI 新员工"、审核它生成的代码、在它出错时把它拉回正轨。从某种意义上说，我们从代码的生产者变成了代码的 orchestrator。

好的工程师不再是写代码最快的那个，而是最会用 AI、最懂架构、判断力最强的那个。

相关资源

• How we used Codex to build Sora for Android in 28 dayshttps://openai.com/index/shipping-sora-for-android-with-codex/
• OpenAI Forum: Vibe Engineering with OpenAI’s Codexhttps://forum.openai.com/public/clubs/developers-and-startups-y6l6m/videos/event-replay-vibe-engineering-with-openais-codex-2025-12-03

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

这两天，OpenAI 和 Anthropic 居然坐到了一起，联合 Block 成立了 Agentic AI 基金会（AAIF），把各自的核心开源项目捐给了 Linux Foundation。

看到这个消息，我第一反应是——这背后的野心不小。想想当年的 CNCF 就明白了。

Agentic AI 基金会想干什么

熟悉云原生的朋友应该记得，Kubernetes 刚出来那会儿，容器编排领域也是一片混战。Docker Swarm、Mesos、Kubernetes 三足鼎立，谁也不服谁，而 Kubernetes 还是其中上手最难的。后来 Google 把 Kubernetes 捐给了 Linux Foundation 下面的 CNCF，才逐渐统一了市场。

AAIF 的野心很可能就是成为 AI Agent 领域的 CNCF。

看看白金会员名单就知道了——除了三个联合创始人，AWS、Google、Microsoft、Bloomberg、Cloudflare 全都在列。黄金会员里还有 IBM、Oracle、Salesforce、Docker、JetBrains 这些大厂。大家都想参与，但又都不想让某一家独大。

这个逻辑其实不难理解。AI Agent 正在从实验走向生产，谁来定标准，谁就有话语权。与其让市场碎片化、各搞各的，不如联手把标准定下来。开源是手段，标准才是目的。

三个创始项目

AAIF 成立时，三家公司各自捐了一个项目。

MCP：连接 AI 和工具的“USB 接口”

MCP 是 Anthropic 一年前开源的项目，全称 Model Context Protocol。简单说，它定义了一套标准协议，让 AI 模型能连接外部工具和数据源。你可以把它理解成 AI 世界的 USB 接口——有了统一标准，各种设备才能即插即用。

一年时间，MCP 的增长速度确实吓人。现在已经有超过 10000 个公开的 MCP 服务器，ChatGPT、Cursor、Microsoft Copilot、Gemini、VS Code 这些主流产品全都支持了。Python 和 TypeScript SDK 每月下载量超过 9700 万次。

我自己在使用各种 AI 编程和 Agent 产品时也都连接了很多 MCP 服务器，体验确实比以前写一堆适配代码方便地多了。以前要让 Claude 连数据库，得自己写工具函数、处理各种边界情况。现在找个现成的 MCP 服务器，配置一下就能用。

不过 MCP 虽然已经是一个公认的行业标准，它的上下文占用、工具混乱以及大量工具导致的 Agent 性能下降等各种问题最近也都爆了出来。Anthropic 主推的 Skills 有取而代之的趋势。Anthropic 只把快要过气的 MCP 捐给了 Linux Foundation，至于是慷慨捐赠还是顺势甩包袱，就见仁见智了。

goose：本地优先的 Agent 框架

goose 是 Block 在 2025 年初发布的开源 AI Agent 框架。特点是“本地优先”，可以在你自己的机器上运行，基于 MCP 做标准化集成。

一家金融科技公司为什么要做 AI Agent 框架？Block 开源负责人的说法是他们选择站在开放这边。但更实际的原因可能是，Block 内部已经有大量工程师在用 goose 做开发、数据分析和文档工作。开源出来能让社区帮着一起改进，最终受益的还是自己。

AGENTS.md：AI 编程标准文件

AGENTS.md 是 OpenAI 在 2025 年 8 月发布的，目的是统一 AI 编程的指导标准。说它是“标准”可能都抬举了，本质上就是一个 Markdown 文件。

它解决的问题很简单：AI 编程助手在不同项目里工作时，怎么知道这个项目的规范？代码风格、构建步骤、测试要求这些，以前每次都要手动告诉它，现在只要在项目根目录放一个 AGENTS.md 文件，AI 自己会去读。

这个方案被采用得很快，超过 60000 个开源项目已经在用。Cursor、Devin、GitHub Copilot、Gemini CLI、VS Code 这些主流工具都支持了。

背后的商业逻辑

说白了，这事儿的核心就是——标准化能让市场做大，大家都能多赚钱。

对云厂商来说，Agent 跑在哪里？跑在云上。工具调用消耗什么？消耗算力和存储。如果 Agent 市场碎片化，开发者都在观望，市场起不来，云服务也卖不出去。统一标准后，开发者敢大规模投入，AWS、Google、Microsoft 才能规模化卖服务。

对 AI 公司来说，各有各的小算盘。Anthropic 把 MCP 捐出去，表面上是慷慨，实际上可能是趁 Skills 还没完全取代它之前，把包袱甩给基金会，换来“开放标准制定者”的影响力。OpenAI 的 AGENTS.md 更妙，一个 Markdown 文件几乎零维护成本，却能影响所有 Agent 的开发方式。Block 的 goose 则是内部工具外部化，开源后社区帮着改进，最终受益的还是自己。

如果不统一标准，每家都搞自己的协议，碎片化成本最终所有人都要承担。大家联手做标准，市场做大了，都能分一杯羹。

对我们意味着什么

Agentic AI 基金会的野心，是成为 AI Agent 时代的基础设施标准制定者。这个野心足够大，大到让竞争对手愿意暂时放下争斗，一起把蛋糕做大。一个开放、中立、持续演进的标准，对所有参与者都更有利。

短期来看，对开发者好处很明显。统一接口，统一框架，少写适配代码，Agent 开发的工作量可以减轻很多。并且有了 AGENTS.md 让不同的 AI 编程助手在同一个项目里有一致的行为规范，Agent 行为更可预测。goose 这样的框架提供了现成的 Agent 运行环境，部署起来也更简单。

长期来看，AAIF 能不能复现 CNCF 的辉煌还是个问号。最终能不能成功，还要看接下来几年的发展。但至少从现在来看，这是一个好的开始。

如果你也在做 AI Agent 相关的开发，建议现在就开始关注这几个项目。

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

Codex CLI v0.65.0 带来了一个我期待已久的功能——Skills 支持。

这个功能最早是 Anthropic 在 Claude Code 上推出的，我已经用了一段时间，早就想着什么时候 Codex 也能有。上周末刷 Codex GitHub 看到合并的 PR，就花了点时间把之前写的 Claude Code Skills 迁移过来，顺手开源在了 GitHubhttps://github.com/feiskyer/codex-settings 上。

为什么需要 Skills

AI 编程助手很强，但真实工作需要的不只是通用能力，还需要你给它配置各种工具。MCP 就是配置外置工具的事实标准，用过 Claude Code、Codex 或者其他 AI Agent 的应该都配过不少 MCP Server。

MCP 普及之后，问题也渐渐暴露出来了。

最明显的是上下文占用。每个 MCP 工具的定义都要占用大量上下文空间，工具多了，光是工具描述就能吃掉好几千到几万 token。我之前配了 playwright、github 这些 MCP Server，启动时上下文窗口已经被 MCP 用掉了一半，留给实际对话的空间就太少了。

另一个问题是 Agent 性能下降。工具越多，模型做决策的时候越容易“选择困难”。该用 A 工具的时候用了 B，或者在几个相似工具之间反复尝试。这种情况在工具数量超过二三十个的时候特别明显。

Skills 解决的就是这两个问题。

它采用“渐进式披露”的设计——AI 启动时只读取 Skill 的名字和描述，一般几十个字就足够了。只有真正用到的时候，才会去读完整的说明文档。如果文档里还引用了其他文件，也是按需加载。就像一本手册，先看目录，再翻章节，最后查附录。

这意味着你可以装几十个 Skills，但不会把上下文窗口撑爆。而且因为每次只加载相关的 Skill，模型不用在一堆工具里做选择，决策路径更清晰，出错率也低了。

Skills 里还能放可执行代码。有些操作用代码跑比让 AI 生成 token 高效多了，排序、数据处理这些，代码执行既快又稳定。

Codex 的 Skills 怎么用

12 月 1 日，Codex CLI 通过PR #7412 正式支持了 Skills。官方文档标注这还是实验性功能，后续可能还会有重大修改，不过已经基本可用了。

文件结构很简单，在~/.codex/skills/ 目录下建文件夹，里面放一个SKILL.md 文件就行。

~/.codex/skills/
├── claude-skill/
│ └── SKILL.md
├── nanobanana-skill/
│ ├── SKILL.md
│ └── nanobanana.py
│ └── requirements.txt

SKILL.md 文件格式是 YAML 开头加 Markdown 正文：

---name:pdf-processingdescription:处理和填写 PDF 表单。用于 PDF 相关任务。---# PDF 处理说明用 pdfplumber 提取文本...

description 要写清楚“做什么”和“什么时候用”，Codex 靠这个判断要不要加载。写得太模糊的话，该触发的时候触发不了。

Codex CLI 中的 Skill 调用方式有两种：

1）类似于 Claude Code，在你的提示词里面直接说“使用某某 skill 干嘛”；

2）显式调用，使用$skill-name [prompt]，比如$nanobanana-skill 帮我绘制微信公众号封面图。

我迁移了哪些 Skills

我把之前在 Claude Code 上常用的 Skills 都迁移过来了，开源在feiskyer/codex-settings。目前有六个。

claude-skill 在 Codex 里调用 Claude Code。有些任务 Claude 做得更好，比如代码审查、写文档、做设计等，我就会用这个 Skill 把任务甩给 Claude。

nanobanana-skill 用来生成图片，调用的是 Google Gemini API。写公众号文章需要配图的时候特别好用，一句话就能生成。支持各种尺寸和分辨率，从 1K 到 4K 都有。

youtube-transcribe-skill 提取 YouTube 字幕。看国外的技术分享视频想做点笔记时，手动找字幕下载太麻烦了。这个 Skill 会先尝试 yt-dlp，失败了自动切换到浏览器自动化方式。

autonomous-skill 用于长时间任务。有些任务一个会话完不成，需要断点续传。这个 Skill 会生成任务清单，一个个执行，中间断了也能接着来。不过目前还不能完全自动运行，执行时可能会因为权限请求暂停，需要人盯着点。

kiro-skill 是个完整的规范驱动开发工作流。从需求文档、架构设计到任务清单、逐步实现，一条龙服务。适合做新功能的时候用，能帮你把需求想清楚再动手。

spec-kit-skill 集成了 GitHub 官方的 Spec Kit 工具，规范驱动开发那一套。从项目原则、功能需求到技术方案、任务清单，七个阶段走下来，适合团队协作的场景。

后面这三个 Skill 还不是特别稳定，还在测试阶段。如果你也有类似的需求，欢迎提 Issue 或者直接发 PR 改进。

快速上手

安装很简单，三行命令。

# 备份原有配置mv ~/.codex ~/.codex.bak# 克隆配置仓库git clone https://github.com/feiskyer/codex-settings.git ~/.codex# 安装 Codex CLInpm install -g @openai/codex

根据你的需要配置 Codex CLI，可以使用 ChatGPT 订阅、OpenAI API Key 或者其他第三方国内外兼容 OpenAI API 的各种大模型。

如果你没有这个仓库，而是手动配置的话，不要忘记在你的~/.codex/config.toml文件中添加：

[features]skills = true

配置好后，启动 codex 后输入/skills 能看到已加载的 Skills 列表。试试$nanobanana-skill 生成一张简约风格的山水画，看看效果。

还有些小问题

Codex CLI 跟 Claude Code 的 Skills 设计理念基本一致，毕竟文件格式都一样。但细节上还有改进空间。

Claude Code 支持allowed-tools 字段，可以限制 Skill 只能用哪些工具，比如做只读操作。Codex 暂时没这个功能。另外 Codex CLI 的权限系统一直都比较粗糙，时不时需要人来授权操作，想让 Skill 完全自主跑起来还有点难。

还有项目级别的 Skill 配置、Marketplace、Plugin 这些 Claude Code 已经有的功能，Codex 也都还没支持。

不过 Codex 是开源项目，社区很活跃，这些功能应该不会等太久。

说实话，AI 编程工具发展到现在，越来越像个可编程的平台了。Prompt、Skill、MCP Server、Hook，各种扩展机制层出不穷。工具本身的能力边界越来越模糊，关键看你怎么配置和定制。

这对我们技术人来说是好事。不用等官方加功能，自己动手就能扩展。

相关资源

· Codex Skills 配置仓库https://github.com/feiskyer/codex-settings

· Codex Skills 官方文档https://github.com/openai/codex/blob/main/docs/skills.md

· Claude Code Skills 文档https://code.claude.com/docs/en/skills

· Claude Code 配置仓库https://github.com/feiskyer/claude-code-settings

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

上个月的 KubeCon 上，Google Cloud 宣布在实验环境中成功运行了 13 万节点的 GKE 集群。而在更早的 7 月，AWS 也发布了 EKS 正式支持 10 万节点集群的消息。

10 万节点是什么概念？按 AWS 的说法，这意味着一个集群可以容纳 160 万颗 Trainium 芯片，或者 80 万块 NVIDIA GPU。这已经不是普通的“大规模”了，基本相当于把一个小城市的算力都集中到了一起。

云厂商为什么要卷这么大规模的 Kubernetes 集群？因为 AI 公司们真的需要。

AI 算力的狂热竞赛

过去一年，AI 基础设施的规模膨胀得有些疯狂。

xAI 在 2024 年 9 月上线了 Colossus 集群，10 万块 NVIDIA H100 GPU，从一个废弃工厂改造完成只用了 122 天。三个月后又翻倍到 20 万块。这个集群用来训练 Grok 3，马斯克说要做地球上最强的 AI。

Meta 在 2024 年底拥有 35 万块 H100，2025 年 1 月 Zuckerberg 宣布计划年底达到 130 万块 GPU。

Anthropic 的 Project Rainier 在 2025 年 10 月上线，近 50 万颗 Trainium2 芯片专门用于训练 Claude，是之前训练算力的 5 倍以上。

字节跳动的 MegaScale 系统已经能支撑超过 1.2 万块 GPU 的分布式训练，在 12,288 块 GPU 上训练 175B 参数模型的 MFU 达到 55.2%。

DeepSeek 用 1 万块 GPU 的集群训练出了性能惊艳的模型，还把成本控制得很低。

这些数字背后有一个共同的问题。怎么把这么多 GPU 组织起来，让它们高效协同工作？

答案是 Kubernetes。

为什么是 Kubernetes？

OpenAI 从 2016 年就开始用 Kubernetes 管理深度学习基础设施。他们把 K8s 当作批处理调度系统，用自研的 autoscaler 动态扩缩容集群。用他们基础设施负责人 Christopher Berner 的话说，以前一个研究员要把实验扩展到几百块 GPU，可能需要几个月。现在用 Kubernetes，两三天就能跑起来，一两周就能扩到几百块 GPU。

为什么 Kubernetes 成了 AI 基础设施的首选？

把 PyTorch、TensorFlow 加上各种 CUDA 版本打包成容器镜像，不管在哪台机器上跑，环境都一样。K8s 把 GPU、CPU、内存都当成资源来管理，你告诉它“我要 1000 块 GPU 跑这个任务”，它会自动找到合适的机器、分配资源、启动容器。Kubeflow 管理训练流水线，Karpenter 自动扩缩容节点，各种 Operator 对接不同的硬件，这些工具大大降低了运维成本。同一个集群可以跑大规模预训练、小规模微调、在线推理，资源可以灵活调度。

Anthropic Claude、OpenAI GPT-x、Amazon Nova、Google Gemini 等等，这些大模型底层基本都跑在 Kubernetes 上。Google Cloud 的数据显示，过去一年 GKE 上 TPU 和 GPU 的使用量增长了 900%。

为什么要追求单个超大集群？

可能有人会问，10 万节点太大了，拆成 10 个 1 万节点的集群不行吗？

对于一般应用来说确实可以。微服务、Web 应用这些，拆成多个小集群反而更好管理，AWS 也推荐这种“蜂窝架构”。

但 AI 训练不一样。大模型训练需要成千上万的加速器作为一个整体协同工作，彼此之间要低延迟、高带宽通信。拆到不同集群，资源利用率会下降，大的预训练任务和小的微调任务本可以共享同一个资源池，拆成多个集群后每个集群都得预留余量。跨集群调度也太复杂，一个超大训练任务拆到多个集群，谁来协调？故障发现、修复、监控都会变得更麻烦。很多 ML 框架默认在单集群内运行，有全局视图，拆成多集群框架可能需要改造。

AWS 在博客里也提到，像 Anthropic 这样的客户明确需要超大规模单集群，把不同规模的训练任务、微调实验和批量推理放在同一个资源池里，可以最大化利用昂贵的 AI 加速器。

Kubernetes 原生的天花板

问题是，原生 Kubernetes 的设计目标是 5000 个节点。这对绝大多数企业够用了，但对 AI 训练来说，差了一到两个数量级。

瓶颈在哪？

etcd 是最大的瓶颈。etcd 是 K8s 的 “大脑”，所有集群状态都存在这里。它用 Raft 共识算法保证数据一致性，但这也意味着每次写入都要等多数节点确认。集群越大，etcd 压力越大。

调度器忙不过来。K8s 调度器负责决定每个 Pod 跑在哪个节点上。默认是串行处理的，一个 Pod 调度完才处理下一个。10 万节点、几十万个 Pod，调度器就成了独木桥。

API Server 压力大。所有对集群的读写操作都要经过 API Server。节点心跳、Pod 状态更新、控制器的各种操作，在超大集群里每秒要处理几万甚至十几万次请求。

这些瓶颈不是简单加机器就能解决的，需要架构层面的改造。

AWS 的方案：重新发明 etcd

AWS 选择的路线是保留 etcd 的 API，但把底层架构重新实现了一遍。

AWS 把 etcd 的 Raft 共识层替换成了内部的 journal 组件。journal 是 AWS 内部用了十多年的东西，专门做跨可用区的高速数据复制。这个改动让 etcd 副本可以自由扩展，不再受 Raft 多数派的限制。

以前 etcd 的数据存在网络挂载的 EBS 磁盘上，现在直接放内存里。因为持久性已经由 journal 保证了，内存里的数据库只是为了快速读取。这个改动带来了数量级的性能提升。

K8s 的不同资源类型不需要跨类型事务。AWS 把 Pod、Node、ConfigMap 等分到不同的 etcd 实例里，写吞吐直接翻了 5 倍。

最终效果怎么样？10 万节点在 50 分钟内全部就绪，每分钟 2000 个节点加入集群。全集群 AMI 升级在 4 小时内完成。etcd 数据库总容量达到 32GB，存储超过 1000 万个 K8s 对象。

Google 的方案：换一个数据库

Google 走了另一条路，直接用 Spanner 替换 etcd。

2024 年 11 月，Google 先宣布 GKE 支持 6.5 万节点，可以管理 25 万个 TPU。到了 2025 年 11 月的 KubeCon，他们又展示了 13 万节点的实验结果。

Spanner 是 Google 自研的全球分布式数据库，支撑着 Google 内部无数核心服务。用它来做 K8s 的后端存储，天然就有更好的扩展性。在 13 万节点的测试中，Spanner 每秒处理 1.3 万次 Lease 更新（节点心跳），完全没有瓶颈迹象。Google 认为这套方案还能继续往上扩。

Google 还引入了 Kueue，一个专门为批处理任务设计的作业队列控制器。原生 K8s 调度器是 Pod 级别的，一个一个调度。Kueue 是作业级别的，可以做“全有或全无”的调度，要么整个作业的所有 Pod 都分配到资源，要么一个都不分配。

这对 AI 训练特别重要。一个分布式训练任务需要 1000 个 Pod 同时启动，如果只启动了 999 个，剩下那个分配不到资源，整个任务就卡住了。Kueue 的 Gang Scheduling 能力正好解决这个问题。

最终效果怎么样？13 万个 Pod 在 3 分 40 秒内调度完成。峰值抢占 3.9 万个 Pod 只用了 93 秒。Pod 吞吐稳定在每秒 1000 个。

两条路，殊途同归

AWS 和 Google 的方案看起来不一样，但核心思路是相通的。

**存储层是关键。**原生 etcd 的架构不适合超大规模。不管是改造它还是替换它，都要解决存储层的扩展性问题。

**调度要革新。**单纯的 Pod 级调度不够用，需要作业级别的调度能力。AWS 用 Karpenter 管理节点生命周期，Google 用 Kueue 管理作业队列，都是在原生调度器之上加了一层。

**API 要优化。**减少对后端存储的压力，尽可能从缓存服务请求。两家都在 API Server 层做了大量优化，比如 Kubernetes 1.31 引入的 Consistent Reads from Cache 功能。

**全栈都要改。**不只是控制面，网络、存储、监控都要跟上。AWS 优化了 VPC CNI 的前缀模式，Google 用 GCS FUSE 加速数据访问，两家都做了镜像拉取加速和节点健康自动检测修复。

写在最后

从 5000 节点到 6.5 万、10 万，甚至 13 万节点，Kubernetes 的扩展性边界被一次次推高。背后是 AI 对算力的需求，也是云厂商在基础设施层面的技术竞争。

如果你在自建集群或者混合云环境，这些经验都值得参考。etcd 调优是基本功，但到了一定规模就要考虑架构改造。引入 Kueue 或类似的作业队列，能显著改善批处理任务的调度效率。关注社区的新特性，比如 Gang Scheduling、流式 List 响应等等。

还有一个趋势值得关注，多集群方案。Google 在文章里提到，单个 GPU 功耗越来越高，NVIDIA GB200 需要 2700W，10 万节点集群的电力消耗可能达到数百兆瓦，这已经超过了单个数据中心的供电能力。未来的超大规模 AI 平台可能需要跨数据中心、跨集群的方案。MultiKueue 就是 Google 在这个方向上的探索。

AWS 和 Google 走了不同的技术路线，但都证明了一件事，Kubernetes 的天花板还远没到。只要有足够的工程投入，它可以支撑起 AI 时代最苛刻的算力需求。

相关链接：

• AWS 博客原文：https://aws.amazon.com/blogs/containers/under-the-hood-amazon-eks-ultra-scale-clusters/
• Google Cloud 博客原文：https://cloud.google.com/blog/products/containers-kubernetes/how-we-built-a-130000-node-gke-cluster

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

上周我想让 Claude Code 帮我验证一个项目中所有数据查询的问题。虽然它们都散乱在项目的不同位置，但任务本身其实不算复杂，大概涉及 100 多个查询。主要复杂的问题在于失败后的处理：找到正确的数据结构、查询一些数据确认有效字段、汇总查询确认可能取值、最后再去重新构造查询。

任务给了 Claude Code 之后，结果干到一半，它突然就“忘了”之前做的事情，漏掉很多我给它涉及的流程，还有很多查询压根没验证就说任务完成了，

其实这也是困扰很多人的通用问题，即 Claude Code 在长时任务中会碰到记忆丢失、上下文窗口受限以及会话切换丢失任务进度等问题。

为什么 AI 会“失忆”

要理解这个问题，得先搞清楚 AI 的“记忆”是怎么工作的。

大模型有一个叫“上下文窗口”的东西，你可以把它理解成 AI 的“工作记忆”。所有的对话历史、代码内容、工具调用结果，都要塞进这个窗口里。窗口满了，老的内容就得丢弃或者主动压缩。

Claude Code 有一个叫 Compaction 的机制，会在窗口快满的时候自动压缩历史内容。听起来挺智能的对吧？问题是，压缩必然会丢失信息。当你的任务需要跨越多个上下文窗口时，每次压缩都像是给 AI 做了一次“部分失忆手术”。

所以，在实际应用中，并不推荐频繁使用 Claude Code 的自动压缩机制。更推荐的方式是把进度写到文件中，再新开会话从这个进度文件继续执行。

Anthropic 的官方解法

前几天，Anthropic 也发布了一篇研究，专门讨论这个问题。标题叫《Effective harnesses for long-running agents》，翻译过来就是“如何让 Agent 在长时任务中保持高效”。

他们发现，即使是最强的 Opus 模型，在处理长时任务时也会翻车。比如让它“构建一个 claude.ai 的克隆”，跑着跑着就出问题了。典型的问题包括：

贪多嚼不烂。 Agent 试图一口气完成整个任务，结果在实现到一半时上下文窗口就满了。下一个会话接手时，看到的是一个半成品——功能没完成，文档也没写，只能靠猜来理解之前发生了什么。

过早宣布胜利。 当项目已经有了一些进展后，后续的 Agent 实例扫一眼代码，觉得“看起来差不多了”，就直接宣布任务完成。实际上很多功能根本没实现。

Anthropic 的解决方案是一个双 Agent 架构，如上图所示：

• Initializer Agent 在第一个会话中运行，负责分析任务、创建详细的功能清单、搭建项目骨架。
• Executor Agent 在后续的每个会话中运行，负责读取上一个会话的进度、选择下一个任务、完成后更新进度。

这个设计的关键在于用文件来做“记忆载体”。

Feature List 是一个 JSON 文件，列出所有需要实现的功能，每个功能有“通过/未通过”的状态。Agent 只能改状态，不能删除或修改功能描述。Progress Notes 记录每个会话做了什么、遇到了什么问题、下一步应该做什么。再加上 Git History，每完成一个功能就提交一次。

这样一来，每个“失忆”的新 Agent 都能通过读取这些文件，快速恢复上下文，接着上一个 Agent 的进度继续工作。说白了，就是让 AI 学会“写工作日志”和“交接班”。

Anthropic 还把这套实现开源了，放在https://github.com/anthropics/claude-quickstarts/tree/main/autonomous-coding，感兴趣的话，你可以去看看它的源码。

我把它做成了一个 Skill

看我这篇研究，我就在想能不能把这套方案封装成开箱即用的工具。

Claude Skill 是 Claude Code 的一种扩展机制。通过它，你可以定义一套专门的工作流程，让 Claude Code 按照特定的模式来执行任务。基于 Anthropic 的研究，我开发了一个叫 autonomous-skill 的 Skill，把 Claude Code 作为主代理，在 Skill 内部启动 Headless 模式的 Claude Code 作为执行代理，再通过本地文件同步进度，也就实现了一个长任务的自动执行系统。

在这个 Skill 中，所有任务数据存储在项目根目录的.autonomous/<task-name>/ 目录下。

project-root/
└── .autonomous/
└── build-rest-api/
├── task_list.md # 任务清单
└── progress.md # 进度日志

当你启动一个新任务时，Initializer Agent 会分析你的任务描述，把它拆解成若干个可执行的小任务，按优先级和依赖关系排序，记录到 task_list.md 里。

任务清单长这样。

# Task List: Build REST API## Meta- Created: 2025-12-01 10:00- Total Tasks: 25- Completed: 0/25 (0%)## Tasks### Phase 1: Foundation- [ ] Task 1: 初始化项目结构- [ ] Task 2: 配置数据库连接- [ ] Task 3: 创建基础模型### Phase 2: Core Implementation- [ ] Task 4: 实现用户认证- [ ] Task 5: 创建 CRUD 接口 ...

有一条铁律。任务描述一旦创建，就不能修改或删除。 只能把[ ] 改成[x]。这是为了防止后续 Agent 作弊——通过删除困难任务来虚假地提高完成率。这个设计我觉得挺妙的。

后续的每个会话都由 Executor Agent 接管。它先读取任务目录，了解当前进度，检查之前的工作是否正常，有没有遗留 bug。找到第一个未完成的任务，执行，测试验证，标记完成，写进度日志，git commit。如果上下文还有空间，继续下一个任务。

每个会话结束后，Autonomous Skill 会检查是否还有未完成的任务。如果有，等待 3 秒后自动启动下一个会话。

这样你可以让 Claude Code 自动跑一整夜，早上醒来检查成果就行了。

怎么用

安装很简单，在 Claude Code 里执行两条命令：

# 添加插件市场源/plugin marketplace add feiskyer/claude-code-settings# 安装 autonomous-skill/plugin install autonomous-skill

启动任务的时候，在 Claude Code 中输入类似这样的话。

<先开启plan模式，讨论确认你要达成的目标和要实现目标的任务列表>
请使用 autonomous skill 帮我实现刚刚讨论的设计

Claude Code 会识别到 autonomous-skill 并自动切换到长时任务模式。

任务运行过程中，你可以到.autonomous/ 目录随时查看进度，比如：

# 查看所有任务ls .autonomous/# 查看具体任务进度cat .autonomous/build-rest-api/task_list.md# 查看进度日志cat .autonomous/build-rest-api/progress.md

几个使用建议

先设计再执行，任务一定要具体。 不要把类似“帮我写个 XXX 后端”这样的任务直接交给 Autonomous Skill 执行，而是先开启 plan 模式，讨论好你想要达成的目标、实现的效果以及详细的步骤，然后再去执行。记住，AI 不是你肚子里的蛔虫，给的信息越具体，拆解的任务越合理，最终执行的效果才能越好。

合理预期任务规模。 简单任务大概十几二十个子任务，几个会话就能完成。中等任务二三十到五十个子任务，可能需要跑几个小时。

定期检查进度。 虽然 autonomous-skill 能自动运行，但建议每隔一段时间看一眼。任务分解是否合理？有没有卡在某个任务上？代码质量是否符合预期？毕竟是 AI 在干活，完全放手不管还是有风险的。

善用 Git。 autonomous-skill 会自动 git commit，但建议你在任务开始前确保当前分支干净，最好创建一个专门的分支。万一跑出来的东西不满意，还能轻松回滚。

写在最后

长时任务一直是 AI 编程助手的痛点。Anthropic 的这篇研究提供了一个挺优雅的解决方案。与其让 AI 强行“记住”所有东西，不如教它学会“写笔记”和“交接班”。

autonomous-skill 把这个方案打包成了开箱即用的工具。它不是银弹，但对于那些需要长时间持续执行的编程任务，它确实让 Claude Code 变得更加可靠。

我自己用了一段时间，体验还不错。项目本身也已经开源在https://github.com/feiskyer/claude-code-settings。

如果你也受够了 AI 的“失忆症”和不停的手动 Approve，不妨试试这个 Skill。

相关链接：

• Effective harnesses for long-running agentshttps://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• Claude Code Settings Github:https://github.com/feiskyer/claude-code-settings

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

做过 Agent 开发的朋友应该都有体会，调 Prompt 真是个细活儿。有时候就改了几个词，模型的表现就可能天差地别。工具描述写得不够清楚，工具数量一多，模型就不知道该怎么选择了。任务定义稍微含糊一点，输出就开始极不稳定。这也是为什么很多 Agent 产品发布都很惊艳，但实际场景一上手就完全是另外一回事了。

最近看到 OpenAI 在 Build Hour 上聊了个新东西，叫 Agent RFT，强化微调。走的是另外一条完全不同的路，也就是不再人工调优，而是让 Agent 自己去实际任务里试错，做对了就奖励，做错了就惩罚，这样 Agent 自己就可以找到最优的道路。本文是 Agent RFT 视频的一些学习笔记，推荐观看原视频https://www.youtube.com/watch?v=1s_7RMG4O4U。

Agent 的本质

Agent 的本质是工具调用循环，它能够和外部世界互动，独立完成任务，不需要总是等着人工介入。

为了把事情做好，Agent 就必须能访问工具。编程 Agent 需要访问终端、代码解释器，甚至整个代码库。客服 Agent 可能需要访问内部软件，查找客户记录、管理退款，或者决定要不要升级给人工处理。

Agent 与外部世界的所有交互都会流回它的上下文窗口。Agent 根据工具的输入输出进行推理，进而再调用另一个工具，周而复始，直到完成整个循环。

传统 Agent 优化方法

当 Agent 性能不够好时，大家通常会尝试三板斧：

1. Prompt 工程：优化提示词，引导模型更好地完成任务。
2. 工具优化：增减工具，改进工具本身，调整工具的描述和命名。
3. 任务简化：简化任务，添加护栏，提高成功率。

这三板斧在很多场景下确实有用。但当你把它们都用完了，性能还是不够好怎么办？

OpenAI 给出的新答案就是Agent RFT。它能够端到端地训练 Agent，根据用户指定的奖励信号来改变模型的权重。奖励信号教会模型哪些是好的行为，哪些是不够好的行为。

Agent RFT

Agent RFT 的核心是强化学习，其核心思想很简单：Agent 尝试做某件事，环境给出奖励或惩罚，Agent 根据反馈调整策略。这就像训练小狗。不需要你告诉它每个动作细节，只需要在它做对时给奖励，做错时不给。经过无数次尝试后，小狗自然就学会了。

RFT = 强化学习 + 微调。具体来说：

1. 模型会对同一个问题生成多个不同的答案；
2. 你定义的评估器会给答案打分；
3. 训练算法会强化高分答案对应的推理路径，抑制低分答案的路径；
4. 经过多轮迭代，模型逐渐学会生成高分答案。

与 SFT 的区别

传统的监督微调（SFT）是什么样的？你给模型一堆“问题-答案”对，让它死记硬背。

而 RFT 完全不同。它不告诉模型“正确答案是什么”，而是告诉模型“什么是好的行为”。

这种差异也就导致：

• SFT：模型学会了在特定场景下输出特定答案，但举一反三能力有限。
• RFT：模型学会了如何更好地使用工具、如何更高效地推理，能力可以迁移到类似任务。

Will 和 Theo 在分享里提到一个特别好的观点：SFT 就像让学生死记硬背教科书，而 Agent RFT 则是让学生进入实验室，允许他们犯错，尝试不同的解题路径，最后根据结果来打分。

RFT 的训练过程

OpenAI 把 RFT 的训练过程比喻成登山，特别贴切。

假如你在一个完全被迷雾笼罩的山上，看不见山顶，也不知道自己在哪。你唯一能感知的，就是脚下的地形——每走一步，能判断自己的位置升高了还是降低了。

你会怎么做？往不同方向试探性地走几步，感受哪个方向让位置升高，然后继续朝那个方向走。不断重复，无数次试探后，自然就会站在山顶上。

RFT 的训练过程就是这样。模型不知道“最优策略”是什么，但它知道每次尝试能拿多少分。它会尝试不同的工具调用顺序，看看哪种顺序得分高，然后逐渐倾向于使用高分策略。经过无数次迭代，找到最优解。

RFT 的效果

OpenAI 团队为了展示 RFT 的实际效果，选择了极具挑战的 FinQA 基准测试，并故意把任务改得更难：不给模型任何财务报告，只给问题，让模型自己在 2800 份财务报告中搜索，还必须在 10 次工具调用内找到答案。

RFT 训练仅 10 个步骤后，平均奖励就从 0.59 提升到 0.63（提高 7%），工具调用次数从 8-9 次降到 4.2 次（减少 53%），平均延迟减少 10%，Token 数减少 40%。也就是说，在没有人教它顺序的情况下，RFT 训练让模型后学会了“精准搜索 → 确认路径 → 读取内容”的最高效组合。

除了 FinQA 基准，OpenAI 一些客户公司的案例同样也很精彩：

• Cognition 的 Devin AI 工程师通过 RFT 学会了并行操作，规划阶段的交互次数从 8-10 次降到 4 次。

• Ambience 用 RFT 优化 ICD-10 医疗编码任务，F1 分数提升 10%，响应时间减少 18%。

• GenSpark 通过设计同时评判内容和视觉的评估器，让幻灯片创建 Agent 的性能在不良案例中提升了 88%。

• MAKO 用仅仅 100 个 PyTorch 提示就让 GPT-4o 学会为新硬件编写 GPU 内核，性能超越现有技术 72%。

• Rogo 遇到了奖励欺骗问题——模型发现了评估器的漏洞疯狂刷分，修复后核心性能提高 21%，这个教训告诉我们：做 RFT 的核心不是训练模型，而是设计好评估器。

评估器设计

通过前面的案例，可以看到，评估器的设计是 RFT 成功的关键。

OpenAI 团队总结了评估器设计的几个核心原则：

1. 提供梯度奖励

反例（二元评分）：0/1 评分方式会让模型困惑：“我明明很接近了，为什么还是零分？”

正确做法（梯度奖励）：0-1 浮点分，让模型知道怎么做会拿更高的分。

2. 评估器要能抵抗欺骗

评估器必须能抵抗“奖励欺骗”，比如要能防范下面这些常见的欺骗方式：

• 输出特定格式骗取高分（Rogo 遇到的问题）
• 通过运气猜对答案，但推理过程是错的
• 输出大量信息，把正确答案淹没在其中

设计技巧：

• 使用 Model Grader 而不是简单的字符串匹配
• 检查推理过程，而不只是最终答案
• 对“幸运猜对”给予低分
• 设计多维度评分（如 GenSpark 同时评判内容和视觉）

3. 符合领域知识

评估器的评判标准必须与人类专家保持一致。检验方法：

• 让人类专家评判一批样本
• 让评估器评判同样的样本
• 计算两者的一致性（如 Cohen’s Kappa）

如果一致性低，说明评估器的标准有问题，需要调整。

4. 明确评分维度

对于复杂任务，最好使用多维度评分。OpenAI 提供了 Multi-Grader 配置：

{"type":"multi","graders": {"accuracy": {"type":"score_model","weight":0.5 },"efficiency": {"type":"string_check","weight":0.3 },"format": {"type":"text_similarity","weight":0.2 } },"calculate_output":"0.5 * accuracy + 0.3 * efficiency + 0.2 * format"}