OpenAI 的 Agents SDK 最近做了一次重要升级，增加了两个关键功能：内置沙箱执行环境和模型原生执行框架（Harness）。这次更新的目标，是帮助开发者更容易地创建安全可靠、能长时间稳定运行的 Agent。 以前开发者使用 OpenAI 的模型来搭建 Agent 时，模型本身的能力虽然够强，但实际运行环境却需要自己搭建。比如文件读写、代码执行、依赖安装、状态保存等基础功能都需要开发者手动处理，费时费力。 现在，SDK 自带沙箱执行环境，Agent 可以在这个统一受控的环境里读写文件、运行代码命令、自动安装依赖，还能保存状态。开发者再也不用从头开始搭建底层环境。 这个沙箱环境支持很多常见的云厂商，包括 Cloudflare、Vercel、Modal、E2B、Daytona 等，也允许开发者接入自己的解决方案。 此外，SDK 还提供了一个名叫 Manifest 的统一配置层，可以挂载本地文件或云存储空间，比如 S3、Google Cloud Storage 和 Azure Blob。从本地开发调试到正式生产上线，开发者只需一套配置就能搞定。 另一个亮点是 SDK 采用了模型原生的 Harness 架构，这种设计将 Agent 的状态保存和计算执行分离开来。这样一来，即便运行 Agent 的容器意外崩溃，也能快速恢复状态，继续执行任务，无需从头开始。此外，这种状态外置的做法也能有效保护敏感数据和凭证，避免因提示注入等安全漏洞导致数据泄露。 除了以上这些功能，SDK 还内置了 MCP 工具调用、Skills 渐进式能力暴露、AGENTS.md 自定义指令、Shell 工具命令执行、Apply Patch 文件编辑工具和灵活的记忆系统。这些以前需要开发者自己用 LangChain 等通用框架组合或手写的功能，现在全部内置在 SDK 中，由 OpenAI 针对自家模型专门优化。Oscar Health 的工程师反馈称，使用新的 SDK 才真正实现了临床记录处理工作流在生产环境中的稳定运行，远超此前尝试过的方案。 放眼行业，类似的生态竞争越来越激烈：Anthropic 推出了 Claude Code，Google 提供了 Agent Development Kit（ADK），现在 OpenAI 也将自家的 SDK 从轻量级框架升级为带沙箱、带状态管理的完整开发平台。对于开发者来说，选择哪个平台生态可能会比单纯选模型本身更关键。 当前 SDK 支持 Python，TypeScript 支持也正在开发中。所有 OpenAI API 用户均可直接使用，计费方式维持不变，仍然按照 Token 和工具调用标准收费。

大部分人写的 AGENTS.md 都在说「别碰这个」「别改那个」。 Vercel 工程师的版本思路相反——它告诉 AI 怎么思考软件工程。效果？省掉 80% 的无效 token 消耗。 完整模板，直接放到项目根目录： # AGENTS.md 不要维护向后兼容性。废弃的代码路径直接删，不留兼容层和回退方案。 在满足当前需求的前提下，用最简单的方式实现。别加没必要的抽象和配置项。 渐进式构建。先做出能端到端跑通的最小版本，再在稳定的基础上加功能。 组件模块化。不同职责之间划清边界。 优先用成熟、维护良好的库。不要重新发明轮子，除非有明确理由。 加新依赖之前，先看看已有依赖能不能干这件事。先读文档，别凭感觉下判断。 架构决策要能服务长期。别写那种你知道迟早要重写的临时方案。 设计之前，先研究成熟产品怎么解决同类问题。用被验证过的模式，别从零另搞一套。 这不是限制。这是工程直觉。 给 AI agent 一个导航系统，不是一条狗链。

有没有人感兴趣一款整合你所有 agents md 文件的可搜索记忆库？我设想的是它能够自动整理本地电脑所有 workspace 的 md 文件，自动处理相关文件的多模态向量化，并支持部署到任意云服务以支持意图创作的自动化。

这个是我用 GLM 5.2 最惊艳的地方，那就是 AGENTS.md 里面的约束会真的生效。Kimi K 2.7 代码在多次循环后还阔以，但是无论是 K 2.7，还是 GPT 5.5，抑或是 M3，都会在长上下文中丢失这些约束。 我这个 Task 从 20:00 执行到现在，花了三个半小时，依旧能注意约束修正代码。

Codex 真正省时间，不是某一次帮你做得特别快。 而是同一件事第二次出现时，不必再从头教。 可以按这个顺序沉淀： 经常重复的项目规则，写进 AGENTS.md； 固定步骤和固定格式，做成 Skill； 需要连接外部服务，再考虑 Plugin 或 MCP； 流程已经稳定、结果容易验收，再交给定时任务。 别一上来就追求全自动。 先手动跑通一次，再连续稳定几次，最后才自动化。

我一直觉得 Codex 最近烧 Token 烧得不太对。 把本地 session 拆开一看，还真找到一个坑：最近版本新增的 JS tool，在执行异步任务时默认高频等待。任务明明还没跑完，模型却被一遍遍叫醒，Token 就这么白白烧掉了。 官方修复前，可以在全局 AGENTS.md 追加：👇 For long-running asynchronous work: - Empty `write_stdin` polls MUST use `yield_time_ms >= 180000`; prefer `300000` when intermediate output is not needed. - `functions.wait` MUST use `yield_time_ms >= 180000`. - `functions.exec` MUST set its outer `@exec yield_time_ms` at least 30000 ms longer than the longest nested tool wait, so the outer code cell does not yield first. - Do not apply the long wait to non-empty `write_stdin` calls that send interactive input. - These tools return early when the process or cell completes. Do not wake the model merely to report that work is still running. 新会话直接生效，老会话 compact 一次后生效。 我这边加完重新统计，Token 消耗少了大约 25%。 大家也可以让自己的 Codex 分析本地 session 验一遍。欢 迎使劲转发，把事情闹大。官方 issue backlog 堆成山，这种问题不闹大，多半连看都懒得看。

突然发现有朋友不知道Claude Code / Codex常用的上下文命令背后的机制，简单介绍一下。 Claude Code 和 Codex 里所有跟上下文相关的命令，本质上都在操作三层存储： 第一层：上下文窗口 模型此刻眼前能看到的内容。它是易失的、有限的(目前的模型最大1M），也是唯一影响模型下一步行为的东西。 第二层：会话记录 每轮对话都会落盘成文件，Claude Code 存在 ~/.claude/projects/ 下的 JSONL，Codex 存在 ~/.codex/sessions/，它不会影响模型行为，但一直都在磁盘上，有点像 git 的历史记录，除非你手动删掉，不然是会一直存在的。 第三层：常驻记忆 CLAUDE.md / AGENTS.md / memory 目录这类每次开新会话都会自动注入的内容，也是唯一跨session存活的上下文。 理解了这三层机制之后，每个上下文命令在干什么就一目了然： 1️⃣ /clear：只清上下文，不动会话记录。 清空的是模型眼前的窗口，会话记录还在盘上。所以 /clear 之后用 claude --resume（选历史会话）或 --continue（接最近一次）能整个找回来。 如果对话太多找不到了，也可以直接把关键对话给到cc\codex，让它直接定位到对应磁盘文件把上下文加载回来。 本质上它是一种软删除，数据想捞的话随时都能捞回来。 通常使用场景是对话的上下文已经比较多，又要在session中开启一个新任务的时候。 2️⃣ /compact：上下文的有损压缩。 让模型把历史上下文写成一份摘要、用摘要顶替原有的全量上下文继续干活。会节省一部分 token，同时也会丢掉一部分细节，压缩之后模型忘记某个中间结论很正常，因为那个结论可能真的没写进摘要。 这里之前也写推文介绍过claude和codex的compact理念是完全不一样的，codex更倾向于全量保存用户的prompt，只精简tool_result相关内容；claude则是两块都会精简。 使用场景是本次session的context已经很多了，但还需要这段上下文继续任务，重要的上下文内容已经被稀释，模型注意不到 3️⃣ /new：全新会话 通过命令新建一个session，开新会话 = 新的上下文窗口 + 新的会话记录文件，旧上下文不会跟过来，能跟过来的只有跨session的常驻记忆。所以跨会话交接工作，靠的从来不是 /new，是你有没有把状态写进第三层或写进代码库。 4️⃣ subagent / Task：临时开一个子agent 子 agent 拿自己独立的上下文窗口干活，干完只把结论回填给主会话，这是能消耗大量上下文却不污染主窗口的机制——所以大扫描、大检索类工作丢给子 agent，主窗口只留结论。

升级 Codex 后，复杂图片编辑总是报网络传输错误？ 这可能不是图片的问题，而是新版原生生图链路不稳定。 目前有个临时绕过方案： 安装旧版 ImageGen CLI，把它封装成全局 Skill，后续编辑复杂图片时，不再调用 Codex 官方生图技能，而是改走旧版 image-agent。 把下面这段话直接复制给 Codex：👇 安装一个兼容的旧版本 ImageGen CLI，并将其封装成全局 Skill，尽可能复刻官方原生生图技能的调用方式。 在全局 AGENTS.md 中写明：以后涉及图片生成、复杂图片编辑或重绘任务时，优先调用这个 Skill，替代官方原生生图技能。 注意检查旧版 CLI 的登录令牌和配置目录，避免与 Codex App 当前使用的账号、令牌或环境变量发生冲突。 旧版生图链路使用其支持的模型版本运行。Codex 的文字分析和提示词整理仍可继续使用 GPT-5.6，但实际生图交给旧版 image-agent 完成。 完成后进行一次复杂图片编辑测试，并确认：Skill 能被正常发现、图片能够成功生成、失败时有明确报错，同时不影响 Codex App 原有功能。 这不是修复官方问题，而是先绕开故障链路。 至少在官方修好之前，不用每次跑十几分钟，最后只得到一句「网络传输错误」。

Redis 创造者 Salvatore Sanfilippo（antirez）最近写了一篇文章。他说在 AI 时代，人的控制重点应该从逐行代码上移，转向软件思想、整体设计、测试和产品愿景。新人还是应该亲手实现小系统来建立理解。 我最近把 Codex、Claude、Cursor 的多条业务线分别做成独立文件夹入口，共享 AGENTS.md、registry 和 HANDOFF。Claude 最近反复漂移，让我确认根因不是模型不强，而是边界、状态、验收和写回没锁住。这是我自己用下来踩到的坑。 我还是会让 AI 仔细看代码，尤其是涉及资金、生产、安全和关键路径的地方还是要下钻。真正升级是默认先审思想、边界、验收和证据，再按风险看代码。