AREX Feed Article
OpenAI 官方开发者账号盘点 Agents API 本周已发货更新，回复区点名 Auto Review 与时间感知
太平洋时间 10 月 30 日下午 4 时 08 分（北京时间 10 月 31 日上午 7 时 08 分），OpenAI 面向开发者的官方 X 账号 发帖，以「Building with the Agents API? Here's what we shipped this week for you:」开场，宣布为正在使用 Agents API 构建的开发者汇总本周已发布的更新。首帖正文只有这一句开场白：没有条目列表，没有文档链接。据本文通过第三方 Twitter 数据接口抓取的快照，截至发稿前，该帖获得约 2.65 万次浏览、243 次点赞和 43 条回复。
具体条目出现在回复区。发帖后不久，开发者陆续点名命令执行前的 Auto Review（自动审查）、Agent 的时间感知（time awareness）与限时运行（timeboxing）、Webhook（Web 回调通知）与 tracing（调用追踪）改进，并围绕这些条目追问细节。帖文属 OpenAI 官方账号的单方发布口径；回复区点名的这份「清单」，目前还不见于官方帖文本身。
首帖只有一句开场白
@OpenAIDevs 的认证信息显示为 OpenAI Developers，带企业认证标识，简介写明「为使用 Codex 与 OpenAI Platform 构建的开发者提供官方更新」。账号创建于 2023 年 3 月，目前约 46.9 万粉丝，日常内容以平台更新、开发者案例和答疑回复为主；发稿时，这条「本周发货」汇总帖是该账号最新的一条帖子。
发帖两分多钟， 的回复已经点到 Auto Review；随后不到半小时，timebox、Webhooks、tracing 相继出现在回复里。在本文能检索到的帖文与回复中，@OpenAIDevs 没有再跟帖补充条目明细或文档链接。
Auto Review：把「命令能不能跑」交给另一个模型
围绕 Auto Review 的回复集中在其配置方式。 问它是默认开启还是需要主动选择加入； 想知道审查策略能按工具单独配置，还是对整个 agent 一套全局规则； 追问它是否会在执行前检查提示注入（prompt injection）。@OdysseyStack 的留言代表另一类情绪：「对那些每条命令都不看内容、直接点『是，别再问我』的人来说，auto review 是个好消息。」
有回复把这单条目和 Codex 产品线连了起来。 写道：「Codex 的 auto review 出现在 Agents API 里是正确方向。长在平台里的护栏，胜过每个人在自己 harness 里重写的护栏。」 则搬出 2025 年 Replit 的 agent 清空 SaaStr 生产数据库的事故作对比，称 auto review「早就该有了」。
OpenAI 的公开文档可以解释这套机制的形态。在 中，Auto-review 被定义为「用一个独立的审查者 agent 取代沙箱边界处的手动审批」：主 agent 在受限沙箱里工作，越界动作（申请提权的命令、被策略挡下的网络请求、可写目录之外的文件改动、需要审批的 MCP 工具调用）不再停下来等人，而是交给审查者 agent 判断，批准则继续执行，拒绝则被要求换一条「实质上更安全的路径」或停下询问用户。文档写明审查者设计上会拦的动作包括把密钥或凭证发往不可信目的地、探测会话凭证、大范围削弱安全设置，以及有不可逆风险的破坏性操作；同一轮工作里连续 3 次被拒、或最近 50 次审查中累计 10 次被拒，会触发熔断、中断当前轮次。该文档目前写在 Codex 桌面应用与 CLI 名下，并注明 Auto-review 只适用于交互式审批，审批策略设为 never 时没有可供审查的对象。
时间感知：追问集中在时钟口径与超时行为
时间感知条目下，回复区的追问落在了这套机制的具体口径上。 称「time awareness 是这里被低估的功能——真正的 timeboxing 能让 agent 实用得多」； 直接问「timebox 到点时，会不会取消正在运行的工具调用？」； 关心时钟口径：「模型看到的是墙上时钟，还是每次工具调用的已耗时间？对『把 CI 修复 timebox 在 10 分钟内』这种需求，差别很大。」
给出的是使用者经验：「『把 CI 修复 timebox 在 10 分钟内』是个好提示词，但模型之外也要留一道硬停——把运行包进你自己的墙钟超时里，触发就取消会话。time awareness 是提醒，不是急停开关。」
与 Auto Review 和 tracing 不同，本文未能在 OpenAI 公开文档中检索到与 Agents API 时间感知对应的说明页面。这个条目会以什么参数、什么粒度落地，目前只能等官方进一步披露。
Webhooks 与 tracing：文档里已有的两条线
的回复同时点了两个条目：「昨晚刚发了个快速测试框架。Webhooks 看起来挺稳。tracing 终于能抓到我之前漏掉的边缘情况。」其后还有人对 tracing 提出更高要求： 希望「对长的多步 agent 运行做更好的 tracing，agent 在第 14 步跑偏时，不用重放全程就能看清原因」； 说自己点开这条帖就是想确认「tracing 和状态处理有没有改进——最近调试嵌套的工具调用相当难受」。
这两样东西在 Agents API 文档中都有明确位置。官方把「流式输出，或用 Webhooks 在 agent 完成或需要输入时收到通知」写进标准工作流；则规定，一次 trace 记录一个轮次内的模型响应、工具调用和委托给子 agent 的工作，tracing 面板展示每一步的输入、输出、时长与状态，新会话默认开启，trace 在轮次结束后生成，可通过 GET /v1/agents/sessions/{session_id}/traces 端点以 OTLP JSON 格式导出，需要 api.traces.read 或 api.agents.read 权限。文档没有标注这些功能本周改了什么；「变好了」目前是回复区使用者的说法。
从公测到第 50 天：这条汇总帖的位置
按 OpenAI 官方 ，Agents API 于 2026 年 9 月 10 日以公开测试版发布：OpenAI 管理会话编排、上下文压缩与恢复，开发者拿到的是一个受管的 Codex harness，支持跨轮次的持久会话与进度流式输出，agent 可跑在 OpenAI 托管沙箱或自建、合作方沙箱中。9 月 29 日，changelog 记录了 computer use 加入 Agents API——agent 可以在 OpenAI 托管的浏览器里完成任务，网站访问审批与登录交由应用处理。
发布当天的还写明：Agents API 本身不收额外费用，按 agent 使用的 token 与工具计费；沙箱可在 OpenAI 托管、自建基础设施以及 Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel 等合作方之间选择；底层 Codex harness 开源，上下文自动压缩、工具搜索、程序化工具调用和多 agent 委托都是其组成部分。公告承诺「在公开测试期间，我们会基于反馈快速迭代，直至正式可用」。这条盘点帖出现在公测第 50 天。
changelog 还显示，Assistants API 已于 2026 年 8 月 26 日关停，官方迁移指引指向 Responses API 与 Conversations API。截至本文核查的 changelog 页面版本，10 月最新条目是 10 月 20 日的 12 小时 prompt caching；回复区点名的条目尚未逐项出现在该页面。
另一半回复：节奏太快与生产化追问
汇总帖也招来了对节奏本身的评论。 说：「每周都有人给我发货，我还在集成上一周的。」 认为「API 接口范围增长得比大多数团队把它接进真实工作流的速度还快。发货容易，难的是 agent 上生产之后的评估（eval）循环和成本控制」。中文开发者 写得更具体：「会用，但 Agents API 能否进生产，不看本周新增多少能力，得看权限边界、调用追踪和版本兼容。Demo 跑通很快，出错后能定位、能回滚才算可用。」 把问题压到安全上：「这些更新有没有改变 agent 对待不可信工具输出的方式？这才决定敢不敢把 agent 指向真实的东西。」
回复区里也混着与 Agents API 无关的诉求： 带着 #4oForAll 话题标签要求「把 4o 还回来」， 抗议 OpenAI「把整个 4 系全部下架」。
在本文能检索到的帖文与回复中，@OpenAIDevs 未就 Auto Review 是否默认开启、timebox 到点是否终止运行中的调用、时间感知采用哪种时钟口径等追问作出答复。回复区点名的条目何时逐项落进官方 changelog 与文档，是这批「已发货」声明的下一个可核对节点。