ginobefun@hongming731 · 5月15日56

本周没有新模型发布，却是 Agent 工程化信息密度极高的一周。Anthropic 与 OpenAI 同步把 Claude Code、Codex 推出 IDE，Computer Use、Windows 沙箱、截图分辨率等落地细节一次讲透；另有 12 项 Agent 评估指标、Agent Skill 开放标准，以及国内 TiDB、腾讯云 Harness、AgentScope Java 三连发。想把 Agent 真正推进生产，这期内容值得阅读和收藏。

译本周科技领域聚焦Agent工程化落地。Anthropic与OpenAI分别将Claude Code和Codex集成至IDE，并详细披露了Computer Use、Windows沙箱等关键实施细节。行业同时推出了包含12项指标的Agent评估体系及开放的Agent Skill标准。国内TiDB、腾讯云Harness、AgentScope Java也相继发布相关产品，共同推动Agent技术进入实际生产环境。

🚨 AI News | TestingCatalog@testingcatalog · 5月15日54

ClickUp is reshaping its Brain platform UI based on which model you pick. > With Claude Opus 4.7, the interface reads "Tell Claude what to do next." > With Gemini 3.1 Pro, it becomes "Let's ask Gemini." > With GPT 5.5, it says, “Let's ask ChatGPT.” The confirmed models are Claude Opus 4.6, Claude Opus 4.7, GPT-5.4, GPT-5.5, and Gemini 3.1 Pro, all selectable from a single dropdown on both desktop and mobile.

译ClickUp正根据您选择的模型重塑其Brain平台界面。 > 选用Claude Opus 4.7时，界面显示“告诉Claude下一步做什么。” > 选用Gemini 3.1 Pro时，界面变为“我们来问问Gemini。” > 选用GPT 5.5时，界面显示“我们来问问ChatGPT。” 已确认的模型包括Claude Opus 4.6、Claude Opus 4.7、GPT-5.4、GPT-5.5和Gemini 3.1 Pro，在桌面端和移动端均可通过同一下拉菜单选择。

歸藏(guizang.ai)@op7418 · 5月15日71

刚才阿真提醒才发现， GPT 的 Codex 远程控制可以链接多个设备 只需要在你另一个设备的 Codex 上点击那个“设置 Codex 移动版就行”

译GPT的Codex功能现已支持通过手机ChatGPT进行远程控制。用户可将移动设备与桌面端Codex绑定，实现对话自动同步，并可直接从手机发送指令、审批权限及监控进度。设置需在Mac版Codex客户端启用“设置Codex移动版”，过程中建议使用Google Authenticator完成多重因素验证，而非短信。目前该功能仅支持Mac，Windows版本仍在开发中。

歸藏(guizang.ai)@op7418 · 5月15日37

Codepilot 新版预览，即将支持 Codex 作为 Agent 引擎

歸藏(guizang.ai)@op7418 · 5月15日69

也可以直接在 ChatGPT 里边用控制 claude code 或其他的软件。 让 codex 调用 computer use 控制就行。 这样的话，如果你是 codex 和 cloud code 的协作开发，就可以让就可以都在 ChatGPT 里边进行控制。 你如果你开的是自动审查权限的话，就不太好控制，开那个完整权限才行。 不然自动审查会拒绝他读取终端 claude code 里的内容

译Codex现已支持通过手机上的ChatGPT应用远程控制绑定的桌面设备。该功能可实现对话自动同步，并允许用户直接发送指令、审批权限及监控进度。设置需在桌面端Codex客户端内启动，并建议使用Google Authenticator完成多重因素验证。绑定后，手机ChatGPT应用将出现Codex侧边栏，用于访问和控制桌面端对话。目前该功能仅支持Mac版Codex，Windows版本仍在开发中。

ChatGPT@ChatGPTapp · 5月15日69

Touch grass and leave your laptop—Codex is now on your phone. Now in preview on the ChatGPT mobile app.

译放下电脑接触自然——Codex现已登陆手机。 现已在ChatGPT移动应用开启预览。

歸藏(guizang.ai)@op7418 · 5月15日56

Codex CLI 设置 Chatgpt 远程控制

歸藏(guizang.ai)@op7418 · 5月15日69

Codex 终于支持手机上的 ChatGPT 远程控制了！ 可以自动同步你绑定的 Codex 设备上的所有对话，而且可以直接发送指令、审批权限、监控进度。 我写一下设置的教程： 1. 点击桌面端 Codex 客户端左侧的“设置 Codex 移动版”，点击后系统会引导你开始设置。 2. 如果你的 ChatGPT 没有设置多重因素验证（MFA），系统会弹出网页要求你设置。这里推荐使用 Google Authenticator（谷歌身份验证器）App，不要用手机短信。 3. 系统会要求你使用手机 ChatGPT 客户端扫码。如果你直接打开手机端 App，它通常会弹出授权请求，直接点击允许即可，不扫码也是可以的。 4. 绑定完成后即可开始使用。你会在手机 ChatGPT 上看到一个 Codex 侧边栏，进去后能看到当前绑定的桌面端设备的所有 Codex 对话。你可以点击进入任意对话并发送命令让它执行。 注意：目前仅支持 Mac 版 Codex，Windows 版本还在开发中。 OpenAI 在封号上没有 Anthropic 那么激进和傻逼，所以你可以放心用。

译Codex现已支持通过手机上的ChatGPT应用进行远程控制，实现了跨设备对话同步与指令操作。用户需在桌面端Codex客户端内启动设置，并完成多重因素验证（推荐使用Google Authenticator）。绑定后，手机ChatGPT App将出现Codex侧边栏，可查看并控制已绑定桌面设备的所有对话，直接发送命令。目前该功能仅支持Mac版Codex，Windows版本仍在开发中。

向阳乔木@vista8 · 5月15日73

如何在ChatGPT 客户端用Codex？ 很多人发新闻，就不发教程！其实配置稍微有点麻烦。 1. 更新Codex 本地客户端。 左侧会出现“设置 Codex 移动版”的入口。 注意！！！ 必须用官方订阅账号，API模式看不到这个入口。 2. 点击设置入口。 进去要求扫码，一定用苹果或安卓源生相机扫码。 （ChatGPT没找到扫码按钮，微信好像不行） 3. 登录ChatGPT账号（哪怕你App已登录账号） 4. 授权后搞定。 后续可改是否让电脑保持唤醒状态。 客户端下载地址见评论

译在ChatGPT客户端中使用Codex需先更新本地客户端，左侧会出现“设置 Codex 移动版”入口，但必须使用官方订阅账号，API模式无法显示。点击入口后，需用苹果或安卓原生相机扫码，ChatGPT应用内无扫码功能且微信不适用。接着登录ChatGPT账号，即使App已登录也需重新验证。授权后即可完成配置，后续可调整电脑保持唤醒状态的设置。客户端下载地址见评论。

Eric@ericmitchellai · 5月15日64

An all-time crossover episode Go, do

译一个历史性的跨界事件 去吧，行动吧 [引用 @OpenAI]：你们一直要求这个... 现在预览中：ChatGPT移动应用中的Codex。 开始新工作、审查输出、指导执行并批准下一步，全部通过ChatGPT移动应用。Codex将继续在您的笔记本电脑、Mac mini或devbox上运行。

meng shao@shao__meng · 5月15日66

Codex 进入 ChatGPT mobile App，这回终于能开心的移动办公，随时随地指挥 Codex 工作了（Windows 端还未推出） https://openai.com/index/work-with-codex-from-anywhere/ 新版 ChatGPT mobile App 做了一个完整的 Codex 移动工作面： · 接入用户任意一台运行 Codex 的机器（笔记本、Mac mini、远程开发环境）； · 实时同步所有线程、审批、插件、项目上下文； · 实时回传截图、终端输出、diff、测试结果、审批请求； · 文件、凭证、权限、本地配置始终留在原机器上，不上云。 技术架构：安全中继层 Codex 通过一个安全中继层让可信机器跨设备可达，而不直接暴露到公网；同时把活跃会话状态在所有登录 ChatGPT 的设备间保持同步。 OpenAI 在产品形态上选择了"云端中继 + 本地执行"的混合模型——既保留本地开发环境的安全边界与凭证隔离，又通过云中继获得跨设备的实时同步体验。这是企业级 AI 编程工具一个相对成熟的架构取舍。 OpenAI 演示的四个使用场景 1. 排队买咖啡：启动 bug 调查，Codex 复现、跑测试，需要授权时手机批准 2. 通勤途中：收到 Codex 的方案分叉决策请求，手机上选择路径，任务继续推进 3. 会议间隙：让 Codex 跨 Slack/邮件/文档汇总客户问题，准备 brief 4. 散步、午餐：灵感即时投递到新线程或现有任务，回到工位前已有初步进展

译OpenAI 在 ChatGPT 移动应用中推出 Codex 预览功能，用户可远程连接运行 Codex 的本地机器（如笔记本或 Mac mini）。通过安全中继层架构，系统能实时同步工作线程、审批请求与项目上下文，并回传截图、终端输出等结果，而所有文件与凭证均保留在本地，不上传云端。用户可在移动中启动任务、审阅输出或决策分叉，实现“云端中继+本地执行”的混合办公模式。目前该功能暂未支持 Windows 端。

ginobefun@hongming731 · 5月15日52

#BestBlogs 早报 2026-05-15 欢迎阅读BestBlogs 的今日早报，推荐阅读 Anthropic 关于 Claude Code 在大型代码库里的官方实践指南、OpenAI 关于 GPT-Realtime-2 的实现细节和开发演示视频，以及少楠关于大模型时代效率溢出之后的思考。

译本期早报重点推荐了三项内容。Anthropic发布了Claude Code在大型代码库中的官方实践指南。OpenAI则公开了GPT-Realtime-2的实现细节并提供了开发演示视频。此外，少楠探讨了在大模型时代，当效率大幅提升（效率溢出）之后所带来的深层思考。

ginobefun@hongming731 · 5月15日60

http://x.com/i/article/2055063165621374976 # BestBlogs 早报 05.15 · Claude Code 最佳实践 / GPT-Realtime-2 · AI 工具到 AI 体系的跃迁 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-15 BestBlogs 新手注册和老用户领取 Pro 会员福利活动进行中，欢迎参与并定制自己的早报。 https://www.bestblogs.dev/pro EP57 · BestBlogs 每日早报 · 2026 年 5 月 15 日 今天这期早报的主线是：从工具到体系。Claude Code 官方公布了大型代码库最佳实践，Harness 的配置比模型分数更决定实际表现，新兴职能「Agent Manager」正在大型组织中落地。OpenAI 通过 Build Hour 深入解析 GPT-Realtime-2 的语音 Agent 架构，对话框正在跃升为自主「语音→行动」工作流。这期还有一个值得关注的真实困境：当 AI 把开发周期从月压到小时后，效率溢出带来的反而是协作方式的重构难题。 ## 导语 AI 编程工具进入大规模落地阶段后，一个关键认知正在浮现：模型能力只是起点，围绕模型搭建的整套工程体系才是决定上限的变量。 Anthropic 这次发布的大型代码库最佳实践指南，直接点破了一个常见误区——团队往往把精力集中在比较不同模型的 benchmark 分数，却忽视了 CLAUDE.md 配置、Hooks、Skills、MCP 等「Harness」层面的工程投入才是实际体验差距的真正来源。这不是一个理论观察，而是来自真实部署在百万行级 monorepo、数十个微服务 repo 上的经验总结。 语音交互领域同样如此。OpenAI 的 GPT-Realtime-2 带来了 GPT-5 级推理和 128k 上下文，但更值得关注的是它背后的架构演进：语音 Agent 已经从「聊天机器人」跨越到了「语音→行动」自主工作流，Sierra 实测延迟降低 30%–200%，这种量级的提升意味着企业语音服务的基础设施需要重新评估。会议场景、客服中心、实时翻译——这些场景的成本结构和体验边界都将随之改变。 flomo 联合创始人少楠的案例则提供了一个反直觉的视角：16 人团队 70%–80% 的代码由 AI 贡献，开发周期从「按月」压缩到「按小时」之后，真正的瓶颈不是工程效率，而是协作方式的重构。产品经理因为能直接验证想法反而提交的需求变少了，优秀的人变得更优秀，能力鸿沟反而在拉大。当效率不再是瓶颈，考验的是另一套能力：判断什么值得做，以及如何在没有传统约束的情况下保持组织协作的凝聚力。 三篇精讲从不同维度指向同一个问题：AI 带来的效率红利，最终会被组织结构和协作惯性消耗掉多少？ 今天速览还有明略科技吴明辉聊 AI 如何颠覆 SaaS、OpenAI 前 CTO Murati 对「永远在场」AI 的探索、阿里云 Skill Factory 的工程实践、OpenAI 13.1 万 GPU 网络的反直觉设计，以及 Codex 登陆 ChatGPT 移动端的最新动态。 ## 精讲一：Claude Code 在大型代码库中的运作方式：最佳实践与入门指南 | Claude Anthropic 官方这篇指南针对的是真实企业场景：百万行级 monorepo、跨越十余年的 legacy 系统、分布在数十个 repo 的微服务群。这类代码库的挑战不是规模本身，而是规模带来的上下文爆炸——如何让 Claude Code 在茫茫代码中准确定位、精准修改，而不是在 context window 里原地踏步。 Harness 和模型同等重要 指南最核心的观点可以用一句话概括：「影响 Claude Code 实际表现的，Harness 配置和模型能力同等重要。」这个论点打破了一种常见预设——很多团队在选型时把大量时间花在比较不同模型的 benchmark 分数上，实际上，两个使用相同模型但 Harness 配置差异显著的团队，体验可能判若云泥。 这里的 Harness 由五个扩展点构成，指南给出了清晰的优先级顺序： - CLAUDE.md 文件 — 每次会话自动加载的上下文文件，根目录放全局约定，子目录放局部规范。这是整套体系的基础，所有其他层都依赖它的质量。内容越聚焦、越准确，Claude 的定位速度越快。 - Hooks — 在 Claude 执行前后注入自定义逻辑，比如格式检查、lint 验证、自动提交、安全审查。它让 Claude 的行为与团队工程规范对齐，而不是每次依赖 prompt 提醒。 - Skills — 可复用的任务模板，把常见工作流封装成结构化指令。类似「为新增 API 端点生成测试用例」这类重复任务，Skills 比每次重写 prompt 更稳定。 - Plugins — 扩展 Claude Code 的底层能力边界，比如接入自定义的代码分析工具或内部知识库。 - MCP Servers — 连接外部工具和数据源，让 Claude 能访问数据库、调用 API、读取实时数据。这是 Claude Code 与企业既有工具链整合的关键接口。 指南特别强调这五个扩展点的顺序很重要：每一层都建立在前一层的基础上。在 CLAUDE.md 还不完善的情况下就去精心配置 MCP，效果会大打折扣。 LSP 与子智能体：两个容易被忽视的加速器 除了五大扩展点，指南还着重强调了两项附加能力： LSP（Language Server Protocol）集成实现符号级导航。传统的 grep 搜索在大型代码库中精度有限——它找到的是文本匹配，不是语义匹配。LSP 能让 Claude 精确跳转到函数定义、查找所有引用、理解类型层次，显著提升在陌生代码区域的探索效率。在 C、C++、Java 这类类型系统复杂的语言中，LSP 集成的收益尤为显著。 **子智能体（Subagents）**解耦探索与编辑。核心思想是：一个子智能体负责探索代码结构、收集上下文，另一个负责实际修改。这种分工避免了单个 Agent 在探索过程中把 context window 消耗殆尽——等到真正要写代码时，已经没有足够空间容纳准确完整的修改了。子智能体完成任务后只把最终结果返回给父 Agent，中间过程的 token 消耗不会传递。 为什么 RAG 在大型代码库中失效 指南对 RAG（检索增强生成）在代码场景局限性的分析值得特别关注。很多团队在引入 AI 编程工具时会考虑「把整个代码库向量化」的方案，Anthropic 明确指出了这条路在大型团队中的天花板。 问题核心是索引的时效性。向量索引需要预先构建，当工程团队在高速迭代时，索引的更新速度根本跟不上代码变更速度。Claude 检索到的可能是两周前已被重命名的函数、上个 sprint 已经删除的模块，而且检索结果本身不会告知你这个信息是否已经过期。在一个有几千名工程师并行提交的 monorepo 里，这个问题会被急剧放大。 Agentic 搜索（即 Claude 直接在 live 代码库中 grep、读文件、跟引用）规避了这个问题——没有索引需要维护，每个开发者的实例都在最新代码上工作。代价是需要足够的起始上下文，也就是说 CLAUDE.md 的质量直接决定 Claude 能否快速定位到正确的代码区域。指南建议：如果 Claude 需要在十亿行代码库里寻找一个模糊的模式，你会在工作开始之前就碰到 context window 限制。精确的起点比广泛的搜索更有价值。 「Agent Manager」这一新兴职能 在大型组织的落地案例中，指南观察到一个新角色正在涌现：Agent Manager。这个职能介于传统技术 Lead 和 AI 工程师之间，具体职责包括：维护 CLAUDE.md 的规范质量、审查和迭代 Hooks 配置、评估 Skills 的覆盖率和准确性、协调不同团队的 MCP 接入标准，以及管理多个 AI Agent 之间的协作边界。 这个职能的出现反映了一个现实：AI 工具的「基础设施」工作需要有人专门负责，否则很容易变成「每个人都在各自配置，没有人在系统性优化」的局面。指南特别提醒，每 3–6 个月应随模型迭代主动更新 Harness 配置——旧有的「规则」可能会约束新模型本已具备的能力，形成不必要的限制。随着 Claude 的能力持续演进，过度保守的 Hooks 和过时的 CLAUDE.md 有时候反而是性能瓶颈。 这篇指南对任何在团队中推广 Claude Code 的工程师或技术 Lead 都有直接参考价值。完整内容见 Claude Code 大型代码库最佳实践。 ## 精讲二：Build Hour 深解 GPT-Realtime-2：语音 Agent 如何从聊天迈向「语音→行动」 OpenAI 的这次 Build Hour 围绕 GPT-Realtime-2 展开，但内容远不止一个新模型发布——它实际上是在描绘语音 AI 应用架构的下一代形态。从「用语音问 AI 一个问题，AI 用语音回答」，到「用语音指挥 AI 执行一系列操作，AI 实时改变应用状态」，这是两个完全不同量级的产品体验 三款音频模型协同工作 OpenAI 这次推出的不是单一模型，而是面向不同场景的三款模型组合，每款都有明确的定位： - Real-time Translate：支持 70+ 语言输入、13 种语言输出，主打低延迟流式翻译。适合实时多语言会议、跨语言客服等场景，不需要最强的推理能力，但对延迟极度敏感。 - Real-time Whisper：延迟可调，最低可达 200ms，支持 80 种输入语言。这是对语音识别精度和速度的双重优化，适合需要快速响应但对下游推理要求不高的场景。 - GPT-Realtime-2：旗舰推理模型，带来 GPT-5 级推理能力，具备高质量工具调用性能，是真正实现「语音→行动」的核心模型。在 Big Bench Audio 上比前代提高了 15.2%。 这三款模型的组合设计思路值得关注：OpenAI 没有试图用一个模型覆盖所有场景，而是根据延迟需求、语言支持广度和推理深度做了明确分层，让开发者根据具体场景选择合适的「档位」。 三项关键技术提升 GPT-Realtime-2 相比前代有几项对开发者直接有用的改进： 首先是 128k 上下文窗口，是上一代的 4 倍。这意味着近一小时的完整对话可以保留在上下文中，不需要截断，长会话中的指令遵循也更稳定。对于需要记住复杂用户偏好、维护多轮任务状态的场景，这是实质性的提升而不是数字上的增量。 其次是前导语（Preambles）机制。当用户提问后，模型需要调用工具或进行多步推理时，可以先输出「让我查一下……」或「好的，我来看看……」这类过渡语，填补思考间隔。这个设计让语音对话的节奏更接近真实人际对话，避免了用户提问后遭遇令人不安的长时间沉默。 第三是逐轮 VAD 控制。VAD（Voice Activity Detection，语音活动检测）负责判断用户是否说完话、何时该模型开始回应。新版本允许开发者在特定对话轮次禁用 VAD，防止模型在输出关键内容（比如法律声明、合同条款、医疗建议）时被意外打断。这对企业合规场景来说是刚需。 Sierra 的企业实测数据 Build Hour 邀请了企业 AI 公司 Sierra 的工程师 Ken Murphy 和 Soham 分享实战经验。他们在企业客服场景下将 GPT-Realtime-2 与传统级联语音系统进行了系统对比。传统方案是「语音识别→文本处理→语音合成」三段式架构，每段都引入延迟，且各段的误差会叠加。 实测延迟降低幅度在 30% 到 200% 之间。区间跨度大的原因是不同业务场景的原始延迟基线差异很大，但即便是最保守的 30% 改善，对用户感知体验也已经是质的提升——语音交互对延迟的敏感度远超文本交互，因为人类对话中的节奏期望是内化的。 Sierra 同时强调了一个务实的观点：模型能力再强，生产环境中的稳健性仍然依赖「Agent Harness」——处理背景噪音、口音、中途打断、连接抖动等真实世界干扰的工程层。这与精讲一关于 Claude Code Harness 的核心论点形成了有趣的呼应：无论是编程助手还是语音助手，「Harness 和模型同等重要」这一判断都成立。 语音 Agent 的下一步 从这次 Build Hour 的演示来看，OpenAI 展示的电商场景（语音管理购物清单，按预算过滤商品，实时更新 UI 状态）和产品分析仪表盘（语音指令诊断移动端 bug，Agent 自主筛选复杂数据集）已经超出了「对话助手」的范畴，进入了真正的自主工作流领域。 用户说「帮我把购物车里超过 500 元的东西移出去」，Agent 不是返回一份建议清单，而是直接操作。这是「语音→文本→建议→用户确认→操作」到「语音→操作」的路径压缩。对于产品设计者来说，这意味着 UI 交互范式需要重新思考：哪些操作应该完全自主执行，哪些需要保留确认环节。 完整技术解析见 GPT-Realtime-2 Build Hour。 ## 精讲三：AI 让生产效率不再是瓶颈，然后呢？｜AI 跃迁者调研 02-flomo 少楠 如果说前两篇精讲是在讲「如何把 AI 工具用好」，少楠的这篇访谈则在追问一个更难回答的问题：当 AI 工具真的把效率拉满之后，真正的障碍是什么？ 少楠是 flomo 浮墨笔记和幕布的联合创始人，做了 11 年产品。这次访谈他分享了一个 16 人团队在 AI 让效率暴涨之后遇到的真实困境，以及 flomo 两个从「代码上下文里长出来」的新功能背后的设计过程。 转折点：命令行比 IDE 更适合产品经理 少楠从 GPT-3.5 时代就开始使用 AI，但长期卡在两个瓶颈：API 成本太高无法集成进产品，Cursor 的 IDE 界面对不写代码的产品经理来说过于复杂——「不小心关掉右边聊天窗口就找不到了，干脆放弃。」 真正的转折来自 Claude Code 的命令行界面。「没有复杂的 IDE，直接给口头指令。」他用它写了一个浏览器插件，能跑，额度从 20 美元充到了 200 美元。同期 DeepSeek V3 把 API 价格打下来，产品内终于也敢大规模用了。从今年开始，他们团队的 AI 渗透率才真正大幅提升：16 人团队，70%–80% 的代码由 AI 贡献，开发周期从「按月」缩短到「按小时」。 这个细节值得注意：对于不写代码的产品经理来说，「简洁的命令行界面」比「功能丰富的 IDE」更低的认知门槛，反而成了 AI 编程工具的入口优势。工具的易用性不是对所有人都意味着相同的东西。 一个反直觉的悖论：产品经理反而更少提需求了 少楠对所有产品经理提了一个新要求：提需求之前，必须先拿到代码库权限，在自己的分支上用代码把需求跑通，在真实数据库里拿到结果，再写 PRD 交给工程师上线。 这带来了一个意外效果。工程师效率提升了——把任务交出去，能开一堆 Agent 并行处理。但产品经理效率反而下降了——「你证伪自己想法的效率变高了，但最终交付产出的数量变低了。以前工程师烦死产品经理了，觉得需求太多；现在是产品经理不好意思提需求了。」 他举了一个典型案例：有用户说 flomo 应该做画板功能，可以拖拽连线。以前少楠直接 Pass，觉得需求太重不敢想。现在他吃晚饭前把想法丢给 AI，吃完饭回来一上手用，发现这是个伪需求——用户需要的是「看到笔记之间有联系」的感觉，而不是自己手动连线这个操作本身。以前只能靠逻辑推演，现在是亲自做出来之后发现不靠谱。验证速度提升了，最终交出去的需求质量也提升了——只是数量少了很多。 工程师那侧也在变化。Web 端做完一个功能，移动端工程师直接去代码库级别参考实现，不需要重新写 PRD，数据埋点有专门的 Skill 技能指令自动化完成。开发周期从「按周」计算变成了「按小时」计算。 AI 没有带来能力平权 少楠给自己团队打了 5 分（满分 10 分），理由直接：「速度上去了，但用户价值的挖掘没有同步提升。」他心目中的满分状态是从「上下游关系」变成「Peer 搭档关系」，像特战小组——四个人的小组能调动远程火炮，有非常清晰的职能分工，同时互相补位，而不是冗长的瀑布流。 更值得警惕的是他的一个核心判断：​「只有原来优秀的人，变得更优秀了。AI 没有带来能力平权，反而把鸿沟拉得更大。」 最会用 AI 的人往往最累，因为能力边界扩张后，优秀的人会自发承担更多。而不擅长使用 AI 的人，和擅长使用 AI 的人之间的效率差距不是在收窄，而是在急剧拉大。 协作方式的重构是最大的难点，不是工具本身。具体问题包括：谁来做 Code Review？怎么 debug 一段 AI 生成的代码？产品经理和工程师的协同边界到底变成什么样？职能边界在溶解——有的产品经理开始兼顾交互设计，有的设计师想直接 vibe coding 出效果，这些探索性的实验会抵消一部分执行效率。少楠自己也在和 vibe coding 的诱惑搏斗：「你的能力变强之后，天然地会想做更多的东西，跟抽烟一样，抽了一口就想抽第二口，两三个小时就没了。」 从代码上下文里「长出来」的功能 flomo 最近上线的两个 AI 功能很有意思——它们都不是从传统 PRD 流程来的，而是少楠在 Claude Code 里写着写着「碰出来的」： 认知地图：少楠想把 flomo 笔记的高维向量（1000 多维）压缩到二维平面看聚类效果。在和 AI 基于代码上下文讨论「这些小点点还能做什么」时，AI 提到了等高线。他一试，发现刚好契合脑子里「个人知识库是一张地图」的想象——等高线对应认知密度的起伏，还能以月为单位播放时间轴，看到自己哪个月在攀登哪个「认知山峰」。「想了很多年的一个东西，就这样上线了。」 AI 记忆：系统把用户所有 flomo 笔记按偏好、事实、事件三大类压缩提炼，生成一份「记忆文档」。把这份文档丢给 Claude 或 GPT，回答质量和个性化程度完全不同——因为 AI 知道你最近在关注什么、你的历史判断、你的角色。这是 flomo 最重要的大更新：长期主动记录积累的私有数据被彻底盘活了。目前只对 Max 会员开放，因为把用户所有笔记压缩两遍的算力成本「是非常惊人的」。 这两个功能的共同点是：它们不是从「用户访谈→需求文档→设计稿→开发」的传统流程来的，而是从「产品经理直接用 AI 工具探索代码实现」的过程中意外发现的。这本身就是少楠所说的「工作流变化」最具体的体现。 完整访谈见 flomo 少楠：AI 跃迁者调研 02。 ## 速览 当 AI「杀死」SaaS：多 Agent 网络与软件业转型 晚点聊 LateTalk 第 164 期邀请了明略科技创始人吴明辉，深度探讨 AI Agent 如何颠覆 SaaS 商业模式。核心论点是「闭源软件价值消失，从 Token 和模型上赚钱」。明略正在开源发布多 Agent 协同网络「章鱼」，通过集体学习机制实现指数级增长。吴明辉提出了「龙虾哲学」——用工程化的义务约束来代替无法约束大模型的道德框架。有 5 年前 AI 尝试失败经验的他，这次对 AI 转型的判断更为审慎和结构化。这期时长超过两小时，想深入了解 AI 对企业软件架构影响的同学值得完整听完。 OpenAI 前 CTO 带来的「永远在场」AI 原型 腾讯科技这篇论文解读深入分析了 Thinking Machines 发布的 Interaction Model。文章从传播学的三条件出发（共在性 Copresence、共时性 Contemporality、并发性 Simultaneity），诊断了当前 AI 交互系统的根本缺陷：AI 只在你主动输入时才「存在」，在你不说话时你的世界对它不存在。Thinking Machines 的方案是通过 200ms 微轮次心跳和统一多模态架构打破这一局限，实现真正「在场」的下一代交互。这篇文章与精讲二关于 GPT-Realtime-2 的内容形成有益互补，两篇放在一起读能更完整地理解「真正的实时 AI」意味着什么。 Skill Factory：三天搭一条技能生产流水线 阿里云开发者这篇实践分享介绍了基于测试驱动开发（TDD）理念构建的 Skill Factory。系统通过多路并行生成（同时调用 3 种不同策略的 Creator，相当于「买三张不同号码的彩票」）、自动化测试回归和生态适配，实现了标准化的技能生产流水线。多路并行的逻辑是：只要其中一路生成了高质量 Skill，整个任务就算成功，这极大提高了首次生成成功率。文章对正在规模化部署 AI Skill 生态的团队有直接参考价值，配合精讲一的 Harness 概念来读效果更好。 OpenAI 13.1 万 GPU 训练网络的反直觉设计 这篇 Towards Data Science 文章深入解析了 OpenAI 发布的 MRC（Multipath Reliable Connection）协议。这套协议颠覆了 30 年的网络惯例：禁用所有路由协议、主动接受丢包、将每次传输随机分散到数百条路径上。结果是在 13.1 万块 GPU 上实现了可预测的尾部延迟，以支持同步训练。文章最值得关注的发现是：MRC 实际上「消灭」了数据中心网络的整个第三层控制平面，没有 OSPF，没有 BGP，没有 IS-IS，交换机维护零动态转发状态。这在任何已公开的生产 AI 训练网络中都是前所未有的。对大规模分布式系统和网络架构感兴趣的工程师必读。 用 Evals 与五段式 Rubric 打造可靠 AI Agent 这个 AI Engineer 工作坊视频由 Arize AI 的 Laurie Voss 主讲，系统介绍了如何从「感觉对」走向「可测量」。核心框架是三层评估体系：代码 Evals（确定性检查，快速且便宜）、LLM-as-a-Judge（用更强模型评估语义质量，适合代码无法捕捉的质量维度）、人工评估（生成黄金数据集，是自动化评估器的「校准基准」）。五段式 Rubric 设计和 Meta-Evaluation（评估你的评估器本身是否靠谱）是两个关键实操技巧。想让 Agent 从实验阶段走向生产的团队必看。 只加两行代码，为什么要两天？ 腾讯云开发者这篇文章深入剖析业务系统复杂性的根本来源：功能间隐秘增加的耦合和不可避免的代码腐化。文章指出，随着系统功能增多，实现每个新功能不会越来越容易，而是越来越难——这与理想中「可复用性会降低边际成本」的预期完全相反。实际的 functionalities-cost 曲线是指数级上升的，不是线性的。文章对于理解 AI 辅助开发在复杂遗留系统中的真实效率边界很有帮助，和精讲三少楠案例中「协作方式的重构才是最大难点」的观点形成互补。 Codex 正式登陆 ChatGPT 移动应用 OpenAI 官方宣布，AI 编程智能体 Codex 现已在 ChatGPT 移动应用中开启预览。开发者可以通过手机启动新任务、审查输出结果、引导执行流程并批准后续步骤，而 Codex 会继续在笔记本或开发机上运行。这意味着开发者可以随时随地通过口袋设备管理正在进行中的编程任务，项目上下文和文件访问权限保持不变。这是一个典型的「分离关注点」的产品设计——执行仍在算力充足的设备上，监控和审批可以在移动端完成。 ## 扩展阅读 OpenAI Codex 负责人 Tibo Sio：Codex 如何进化为通用 Agent OpenAI Forum 的演讲视频，Codex 负责人 Tibo Sio 介绍 Codex 从云端开发者工具转型为本地运行的通用知识工作助手的路径：随着 GPT-5 的发布，Codex 将关注点从简单代码补全转向「长时任务」，即需要数小时乃至数天自主工作的复杂项目。视频中预告了面向长时任务的 Slash Goal 模式和安全护航的 Auto Review Agent。对关注 OpenAI Agent 产品演进方向的人值得看。配合速览中 Codex 登陆移动端的动态一起理解效果更好。 解锁连续批处理中的异步性 Hugging Face Blog 的 LLM 推理系列第二篇，讲解如何通过 CUDA 流和事件将 CPU 批次准备与 GPU 计算解耦，实现真正的并行执行，实测获得 22% 的推理加速。技术深度较高，适合需要优化 LLM 推理服务成本、尤其是在 H200 等高端 GPU 上跑生产推理的工程师。是对第一篇连续批处理文章的延伸，建议按顺序阅读。 GitHub Issues 导航性能现代化改造 GitHub 工程团队如何通过客户端缓存、预热（Preheating）和 Service Worker，将 Issues 页面导航延迟从「网络受限」变为「接近即时」。文章特别有价值的是方法论层面：先做流量分布测量（发现 57.6% 是 hard navigation），再针对主导路径优化，而不是只优化已经较快的 React soft navigation。HPC 百分位指标的改善数据具体详实。适合做前端性能优化或关注产品感知速度提升的工程师参考。 在 Zoox 加速 LLM 驱动的开发者生产力 Zoox AI 负责人分享通过构建企业 AI 平台 Cortex 系统化提升开发者效率的路径，涵盖安全 LLM 访问、RAG、智能体 API 和采纳率管理。从「新员工入职查文档靠猜」到「AI 无处不在，缺 AI 才感觉奇怪」的转变过程，有不少关于 AI 采纳率培育的实操细节。适合正在规划企业 AI 基础设施、需要参考大型工程团队实战案例的管理者和架构师。 ## 今日阅读路径 时间有限时，建议优先按以下顺序阅读： 第一优先：Claude Code 大型代码库最佳实践 如果你的团队正在推广或评估 Claude Code，这篇 Anthropic 官方指南有直接的实操价值。理解「Harness 和模型同等重要」这一核心论点，能避免在工具选型时只看 benchmark 分数而忽视工程配置的误区。五大扩展点的优先级顺序、LSP 集成的时机、子智能体的使用场景——这些都是容易踩坑的决策点。预计阅读时间 25–35 分钟。 第二优先：flomo 少楠：AI 跃迁者调研 02 这篇访谈提供的不是技术方案，而是一个真实团队在 AI 效率提升后遇到的组织挑战的第一手记录。「AI 没有带来能力平权，反而把鸿沟拉大」和「协作方式的重构是最大难点，不是工具」这两个判断，对任何在团队中推动 AI 落地的人都有很高参考价值。尤其推荐和 flomo 同量级的中小团队创始人和产品经理阅读。预计阅读时间 30–40 分钟。 第三优先：GPT-Realtime-2 Build Hour 如果你的产品涉及语音交互或实时通信，这个 Build Hour 值得完整看完。三款音频模型的定位差异、128k 上下文的实际意义、前导语机制和逐轮 VAD 控制的产品含义、Sierra 的企业实测数据——这些细节在正式文档中很难找到这么集中的呈现。预计视频时长 45–60 分钟，可以 1.5 倍速观看不影响理解。 BestBlogs 每日早报 · EP57 · 2026 年 5 月 15 日 · bestblogs.dev

译Anthropic发布Claude Code大型代码库实践指南，强调Harness配置（如CLAUDE.md、Hooks）与模型能力同等重要，是决定实际体验的关键，并指出RAG在高速迭代代码库中存在时效性局限。同时，OpenAI通过Build Hour解析GPT-Realtime-2，展示语音Agent正从聊天机器人演进为“语音→行动”的自主工作流。此外，当AI将开发周期从月压缩到小时，效率提升正引发协作方式与组织结构的重构难题。

Berryxia.AI@berryxia · 5月15日70

兄弟们，这个好啊！ Codex 移动手机版已经上线，可以直接在商店下载使用… iOS 已经用上了～ 安卓大家可以Google Play 看看有没有

ChatGPT@ChatGPTapp · 5月15日67

Codex in the ChatGPT app let your agents work for you from anywhere

译ChatGPT应用中的Codex 让你的智能体随处为你工作

小互@xiaohu · 5月15日67

Codex 手机版上线 但是并不是大家之前认为的独立App 而是内置在ChatGPT里面 在客户端选择codex，设置后，你就可以直接在 ChatGPT 手机 App 里远程控制。 你不在电脑前，也能查看 AI 正在写什么代码、跑什么任务、卡在哪一步，甚至直接批准它继续执行。 手机里可以： • 查看任务线程 • 看 diff 和测试结果 • 给 Agent 回复新指令 • 批准危险操作 • 切换模型 • 新建任务继续跑

译Codex手机版已正式推出，但并非独立的应用程序，而是直接集成在ChatGPT手机App内部。用户只需在客户端选择并设置Codex，即可通过手机远程控制AI编程任务。核心功能是让用户即使不在电脑前，也能实时监控AI的代码编写、任务执行进度与卡顿点，并可直接批准其继续运行。具体操作包括查看任务线程、检查代码差异与测试结果、向Agent发送新指令、批准危险操作、切换模型以及创建并运行新任务。

ginobefun@hongming731 · 5月15日53

Codex 现已集成到 ChatGPT 移动应用中。

Greg Brockman@gdb · 5月15日74

You can now use Codex, wherever you have it running, from the ChatGPT app. Huge step forward for universal usage of agents.

译现在，无论Codex在哪里运行，你都可以从ChatGPT应用中使用它。 对于代理的通用使用来说，这是一大步前进。

Sam Altman@sama · 5月15日66

Codex in the ChatGPT mobile app!

译ChatGPT手机应用中推出Codex功能！

Sam Altman@sama · 5月15日74

also all this:

译OpenAI宣布Codex推出两项新功能，旨在提升围绕代码的自动化与定制体验。一是“Hooks”，允许用户通过脚本在任务关键节点自定义Codex的工作流程，例如运行验证器、扫描提示中的敏感信息、记录对话至内部系统，或根据代码库和目录创建记忆与定制行为。二是“编程访问令牌”，为Business和Enterprise团队提供范围限定的凭证，可从ChatGPT工作区设置生成，适用于CI/CD管道、发布工作流和内部自动化任务。该令牌支持设置过期时间或即时撤销，并能将使用情况关联回对应工作区。

宝玉@dotey · 5月15日66

OpenAI 把 Codex 搬进了 ChatGPT 手机 App，今天在 iOS 和安卓上同步开启 preview，所有 ChatGPT 用户都能用，包括免费版和最低价的 Go 套餐。 手机端不是让你在手机上写代码。真正干活的 Codex 还是跑在你的笔记本、Mac mini 或者 devbox 上，手机只是一个远程窗口：地铁上能看 Codex 跑到哪一步、审一眼它改的 diff 和跑的测试结果、批准下一步操作，或者临时换个方向走。文件、凭证、权限都留在原来那台机器上，不上传到手机。 OpenAI 的解释是底层走了一层 secure relay 中继,让跑着 Codex 的机器能跨设备保持可达,又不直接暴露在公网上。你在哪台设备登录 ChatGPT，会话状态和上下文就跟到哪里。 为什么现在做。OpenAI 自己公布的数字是 Codex 每周活跃用户已经过 400 万。当 agent 越来越多地跑长任务，几十分钟甚至几小时的那种，人坐在电脑前盯着就很傻，你需要随手能看一眼、能拍板的能力。 一个明显限制：手机端目前只能连 macOS 上的 Codex，Windows 支持据说”很快”。 另一层意思是，OpenAI 没给 Codex 单独做手机 App，而是塞进 ChatGPT 主 App。这跟他们之前透露过的”超级 App”路线一致，把 ChatGPT、Codex、Atlas 浏览器整合成一个入口。桌面端是独立的 Codex App，手机端直接合并进 ChatGPT。 参照系是 Anthropic。Claude Code 从去年秋天起就支持手机远程查看和介入正在跑的任务，后面的 Cowork 配套移动端走的也是类似 dispatch 思路。Codex 这次把覆盖范围扩到了 devbox 和远程企业环境（支持 remote SSH 接入），算是追平加扩张。

译OpenAI在ChatGPT的iOS和安卓App中推出Codex预览功能，所有用户均可使用。该功能并非让手机直接运行代码，而是作为一个远程操作窗口，允许用户在外出时查看任务进度、审核代码差异与测试结果，并进行决策。实际计算任务仍在用户的笔记本电脑、Mac mini或devbox上执行，文件与凭证不会传输至手机。此举旨在满足Codex每周超400万活跃用户处理长任务时的远程监控需求。目前手机端仅支持连接macOS设备，Windows版本即将推出。该集成符合OpenAI将多项服务合并至单一入口的“超级App”战略。

OpenAI Developers@OpenAIDevs · 5月15日76

Codex is getting easier to automate and customize around your code. 🪝 Hooks customize the Codex loop with scripts that run at key points in a task: • Run validators before or after work • Scan prompts for secrets • Log conversations to internal systems • Create memories or customize behavior by repo or directory ⚙️ Programmatic access tokens provide scoped credentials for Business and Enterprise teams: • Create tokens from ChatGPT workspace settings • Use them in CI, release workflows, and internal automations • Set expirations or revoke access when needed • Keep usage tied back to the workspace

译Codex正变得更易于围绕用户代码实现自动化与定制。其核心更新包括“钩子”功能，允许在任务关键节点运行脚本，以进行工作验证、扫描密钥、记录对话或按仓库定制行为。同时，面向商业和企业团队推出“程序化访问令牌”，提供范围化凭证，可从ChatGPT工作区设置创建，用于CI/CD、发布流程和内部自动化，支持设置过期或撤销，并将使用情况关联回工作区。

Tibo@thsottiaux · 5月15日75

Codex everywhere

译Codex everywhere [引用 @OpenAIDevs]：离开你的笔记本电脑。在手机上继续用Codex进行构建。 Codex在你的电脑上持续工作，你的文件和项目上下文仍保持原样。 口袋大小的访问。完整的Codex工作状态。 https://x.com/OpenAI/status/2055016850849993072

Noam Brown@polynoamial · 5月15日68

It's now even easier to keep your agents running productively 24/7

译现在让你的智能体保持24/7高效运行变得更加容易 [引用 @OpenAI]：这是你们一直期待的功能... 现推出预览版：ChatGPT移动应用中的Codex。 从ChatGPT移动应用启动新任务、审查输出、引导执行并批准后续步骤。Codex将持续在你的笔记本电脑、Mac mini或开发机上运行。

🚨 AI News | TestingCatalog@testingcatalog · 5月15日64

OPENAI 🔥: A new Codex with Remote Control is now available inside the ChatGPT app for mobile in selected regions. > Codex is now in the ChatGPT mobile app so you can stay in the loop from anywhere while Codex gets work done across your laptops, devboxes, or remote environments. > Codex in the ChatGPT mobile app is rolling out in preview on iOS and Android across all plans, including Free and Go, in all supported regions. Support for connecting your phone to the Codex app on Windows is coming soon. The time has come 👀

译OpenAI在ChatGPT移动应用中推出了新版Codex的预览功能，支持远程控制。用户可通过iOS和Android设备，随时随地连接并管理其笔记本电脑、开发机或远程环境中的Codex工作进程。该预览版面向所有支持地区的用户开放，包括免费和付费计划。此外，即将提供手机与Windows版Codex应用的连接支持。

Chubby♨️@kimmonismus · 5月15日74

Aaaaaaand official: codex in the ChatGPT mobile app!! Love it Codex is goated. I love it.

译官宣：ChatGPT手机应用现已集成Codex！！太棒了 Codex真是强大。我太喜欢了。

OpenAI@OpenAI · 5月15日70

You've been asking for this one... Now in preview: Codex in the ChatGPT mobile app. Start new work, review outputs, steer execution, and approve next steps, all from the ChatGPT mobile app. Codex will keep running on your laptop, Mac mini, or devbox.

译你们一直期待的功能来了... 现已在预览版推出：ChatGPT移动应用中的Codex。 从ChatGPT移动应用启动新工作、查看输出、引导执行并批准后续步骤。Codex将持续在你的笔记本电脑、Mac mini或开发机上运行。

OpenAI Developers@OpenAIDevs · 5月15日75

Step away from your laptop. Keep building with Codex on your phone. Codex keeps working on your computer, with your files and project context still in place. Pocket-sized access. Full Codex working state. https://x.com/OpenAI/status/2055016850849993072

译OpenAI宣布在ChatGPT移动应用中预览集成Codex功能。开发者现可通过手机远程启动新工作、审查输出、指导执行并批准后续步骤，实现移动操控。与此同时，Codex进程将持续在用户的笔记本电脑、Mac mini或开发机上运行，保持完整的项目上下文和文件访问。这提供了对Codex工作状态的“口袋式”访问，允许开发者离开电脑后仍能继续推进开发工作。

ChatGPT@ChatGPTapp · 5月15日15

👀

译看

Chubby♨️@kimmonismus · 5月15日45

Looks like codex mobile is coming today!

译看起来 Codex Mobile 今天就要来了！

DogeDesigner@cb_doge · 5月15日61

NEWS: OpenAI hit with Class-Action Privacy Lawsuit for Sharing ChatGPT Data with Google and Meta. Sam Altman's OpenAI secretly embedded Meta’s Facebook Pixel and Google Analytics into ChatGPT, turning your most private conversations about health, finances, legal issues, and confidential company data into ad-targeting data sent straight to Meta and Google without consent. This violates federal wiretap laws. OpenAI enabled surveillance for profit.

译新闻：OpenAI因向谷歌和Meta共享ChatGPT数据而面临集体隐私诉讼。 Sam Altman的OpenAI秘密将Meta的Facebook Pixel和谷歌分析工具嵌入ChatGPT，将您关于健康、财务、法律问题和公司机密数据的最私密对话转化为广告定位数据，未经同意直接发送给Meta和谷歌。 这违反了联邦窃听法。OpenAI为牟利而启用监控功能。

Chubby♨️@kimmonismus · 5月15日55

GPT-5.5 has a certain magic about it. It solves one Erdős problem after another. this is what post-AGI research may actually feel like. Not one dramatic "AI solves math" moment, but dozens of parallel discoveries, anonymous contributors, formal proofs as trust infrastructure, and humans struggling to keep up cognitively.

译GPT-5.5 展现出持续解决 Erdős 问题的能力，这预示了后AGI研究的可能面貌：并非戏剧性的单一突破，而是大量并行发现、匿名贡献者参与、形式化证明作为信任基础设施，人类在认知上难以跟上。引用推文关键点显示，用户通过 ChatGPT-5.5-Pro 在解决第一个 Erdős 问题后不到两天，又快速攻克第二个问题，并利用形式化验证解决方案，体现了AI在数学研究中的高效应用。

Chubby♨️@kimmonismus · 5月14日22

Its thursday, friends. Lets if OpenAI was cooking. Looking for some amazing codex updates. Ngl, Codex is goat right now. Replaced Claude for me.

译周四了朋友们，来看看OpenAI有什么新进展。期待一些惊艳的Codex更新。 说实话，Codex现在是最强的。对我来说已经替代了Claude。

AYi@AYi_AInotes · 5月14日75

最近全网都在聊OpenAI的ChatGPT 5.5多厉害，Codex多好用之类的， 但没人注意到昨天刚爆的这个集体诉讼，这件事可能是真正炸穿底线的事。 南加州联邦法院昨天正式立案，原告代表所有美国ChatGPT用户起诉OpenAI。 诉讼文件里的实锤硬到爆， OpenAI在ChatGPT网站代码里直接嵌入了Facebook Pixel和Google Analytics， 你在输入框里敲下任何一个问题，按下回车的瞬间， 这个查询的完整主题会变成浏览器标签标题， 然后Pixel会把它和你的Facebook cookies一起，实时发给Meta。 那些cookies里包含c_user和fr字段，也就是你唯一的Facebook用户ID。 但这还不是最恐怖的地方， OpenAI自己在隐私政策里承认了这件事🌚 他们说他们只会分享有限的标识符用于推送Pro版广告，不会分享完整的对话内容。 诉讼方认为，查询主题本身就是最敏感的个人信息。 以前我们以为，免费AI的代价是你的数据用来训练模型，但其实模型只是诱饵，真正的产品， 是你每一次的好奇心， 和你完整的数字身份。 还有更讽刺的， 很多人用ChatGPT，就是不想被Google追踪自己搜了什么， 结果转头就把自己问的每一个问题，原封不动送给了Meta和Google🥹 #OpenAI #ChatGPT #隐私

译南加州联邦法院已受理针对OpenAI的集体诉讼，指控其在ChatGPT网站中嵌入Facebook Pixel等代码，侵犯用户隐私。当用户提交查询时，查询主题会作为浏览器标题与含Facebook唯一ID的cookies一并实时发送给Meta。OpenAI虽称仅分享“有限标识符”用于广告，但原告认为查询主题本身即高度敏感的个人信息。此案揭示免费AI服务的潜在代价：用户每一次查询及数字身份可能成为被交易的产品，与许多用户为逃避追踪而选择ChatGPT的初衷形成讽刺对比。

DogeDesigner@cb_doge · 5月14日14

Sam Altman watching his 𝕏 feed right now 😂

译Sam Altman 此刻正看着他的 𝕏 信息流 😂

meng shao@shao__meng · 5月14日50

OpenAI 给 Codex 在 Windows 造了一个沙箱，过程比想象中曲折 ... 来自 Codex 团队 David Wiesen 非常有深度的技术博客，推荐阅读！ https://openai.com/index/building-codex-windows-sandbox/ 问题的起点：Windows 上的 Codex 没有沙箱 Codex 运行在开发者本地（CLI / IDE 扩展 / App），默认以当前用户身份执行命令——既能读写文件、跑测试、操作 Git，也意味着潜在风险。 macOS 有 Seatbelt，Linux 有 seccomp/bubblewrap，Windows 原生缺乏这种"按进程做强约束"的能力。结果 Windows 用户只能在两个糟糕方案中二选一： · 每条命令都审批（甚至读操作），打断流畅性； · 开启 Full Access，放弃所有约束。 团队的目标，是把 Codex 在 macOS/Linux 已有的"默认安全"体验搬到 Windows：只能在工作区内写、默认无网络访问，且全程不需要用户介入。 现成 Windows 方案为什么都不够用？ · AppContainer：是为"功能边界清晰的应用"设计的；Codex 要驱动 shell、Git、Python、构建工具等任意二进制，形状不对 · Windows Sandbox：它是隔离的"另一个桌面"，无法直接作用于用户的真实仓库；且 Windows Home 版根本没有 · Mandatory Integrity Control：把工作区标成 Low，等于让所有 Low 进程都能写入，宿主信任模型被破坏，副作用太大 第一版原型：「免提权沙箱」（Unelevated Sandbox） 设计原则：不弹 UAC、不要求管理员。需要解决两件事：限制文件写入 + 限制网络。 1. 文件写入：靠 SID + Write-Restricted Token 真正落地 · 合成 SID：Windows 允许创建一个不绑定真实用户、却能出现在 ACL 中的身份。Codex 为此造了一个专属的 sandbox-write SID。 · Write-Restricted Token：一种特殊进程令牌，写操作要双重放行——token 的真实用户身份有权限； token 的"受限 SID 列表"中至少一个 SID 也被授权。 把 sandbox-write SID 通过 ACL 授予： · 当前工作目录 · config.toml 里配置的 writable_roots 并显式拒绝其写入 .git / .codex / .agents。 → 这是真正的 OS 级写边界。 2. 网络访问：只能"劝退"，无法强制 Windows Firewall 必须管理员权限，于是只能做环境层面的软封锁： HTTPS_PROXY / ALL_PROXY / GIT_HTTPS_PROXY = http://127.0.0.1:9 GIT_SSH_COMMAND = cmd /c exit 1 外加在 PATH 前塞 denybin，让假的 ssh/scp 先被解析到。 效果：拦得住行为良好的工具；但凡自己实现网络栈、绕过 PATH、或直接开 socket 的程序——一律失效。仅是 advisory，挡不住对抗性代码。 改版关键：为什么必须接受"需要提权" 要让 Windows Firewall 真正生效，必须按"身份"匹配规则。但： · 防火墙规则不能匹配 restricted token 中的合成 SID； · 按 codex.exe 路径匹配，覆盖不到它派生的 Git/Python 等子进程； · 按用户匹配又会误伤真实用户本人； · 按端口/地址匹配是错的策略——目标不是封 443，而是封这一棵受限进程树的所有出站流量。 唯一的出路：让沙箱命令以"另一个 Windows 用户"的身份运行。这就必须放弃"免提权"约束。 最终方案：「提权沙箱」（Elevated Sandbox） 1. 引入两个本地用户 Codex 在安装时创建： · CodexSandboxOffline —— 防火墙规则全封； · CodexSandboxOnline —— 不被防火墙规则覆盖。 子进程依旧跑在带 [Everyone, Logon, Synthetic] 受限 SID 列表的 write-restricted token 下，但 token 的主体（principal）换成了沙箱用户，而不是真实用户。 5.2 一次性 setup 步骤（需要管理员） · 创建合成 SID； · 创建在线 / 离线沙箱用户； · 凭据用 DPAPI 加密存储，沙箱用户自己读不到； · 为 CodexSandboxOffline 创建"封禁所有出站"的防火墙规则； · 给沙箱用户补 读 ACL——因为新用户默认读不到其他用户的 profile、C:\Users、C:\Program Files 等常用目录。这一步耗时，异步执行，不阻塞用户。 5.3 为什么需要 codex-command-runner.exe 直觉的流程是： codex.exe → LogonUserW → CreateRestrictedToken → CreateProcessAsUserW(child) 但在 CreateProcessAsUserW 这一步存在特权墙：以"真实用户"身份是无法可靠地把进程以另一个用户的受限 token 拉起来的。 解法是把流程切成两段： Part 1（在真实用户侧） · codex.exe 用 CreateProcessWithLogonW 把 codex-command-runner.exe 以沙箱用户身份拉起（此时还不是受限 token）。 Part 2（已经在沙箱用户侧） · runner 用 OpenProcessToken 拿到自己的 token； · GetTokenInformation 取出 logon SID； · CreateRestrictedToken 构造最终受限 token； · CreateProcessAsUserW 拉起真正的子进程。 5.4 最终四层架构 · codex.exe —— 普通非提权的 harness； · codex-windows-sandbox-setup.exe —— 一次性的提权安装； · codex-command-runner.exe —— 在沙箱用户内造受限 token 并起子进程； · child process —— 真正受约束的命令。 拆成独立二进制的好处：codex.exe 在其他平台不被 Windows 专属逻辑污染；UAC 边界只在必要时跨越；setup 的长耗时与主进程生命周期解耦。

译OpenAI 为在 Windows 上实现 Codex 的“默认安全”体验，从免提权沙箱演进到提权沙箱。Windows 缺乏原生进程级约束，初期方案通过合成 SID 和 Write-Restricted Token 限制文件写入，但网络封锁只能依赖环境变量软拦截，无法强制生效。团队最终放弃免提权约束，转向创建独立本地用户（在线与离线沙箱用户），需一次性管理员权限安装并配置防火墙规则。通过引入 codex-command-runner.exe 作为中介，解决跨用户创建受限令牌进程的权限难题，形成四层架构，在保障安全的同时最小化对主流程的侵入。

Yuchen Jin@Yuchenj_UW · 5月14日51

Google I/O is next week. Prediction: nobody lets Google have the stage alone. All of these models could drop next week: - GPT-5.6 - Mythos or Opus/Sonnet 4.8 - Gemini 3.5

译Google I/O 就在下周。 预测：没人会让谷歌独占舞台。 所有这些模型都可能在下周发布： - GPT-5.6 - Mythos 或 Opus/Sonnet 4.8 - Gemini 3.5

Tibo@thsottiaux · 5月14日34

They meant companies... 2000 companies. We're going to need to stand up a lot of compute 😅

译他们指的是企业...2000家企业。我们需要搭建大量计算资源😅

ginobefun@hongming731 · 5月14日59

在 Windows 上为 Codex 构建安全有效的沙箱 https://openai.com/index/building-codex-windows-sandbox 这篇来自 OpenAI 工程博客，记录了 Codex 团队为在 Windows 上实现真正的沙箱隔离所走的完整路径。写法很好：逐一说清楚每个被否掉的方案以及被否的原因，最后再解释自研方案的设计逻辑。整个记录的过程本身就值得学习。 起点是 2025 年 9 月加入 Codex 团队时面对的实际问题：Windows 用户要么批准几乎每一条命令（低效到让 Agent 失去意义），要么开启完全访问模式（安全风险无法接受）。Linux 有 seccomp，macOS 有 Seatbelt，这两个系统有成熟的内核级沙箱工具，Windows 没有对应能力。 团队评估了三个现成方案。AppContainer 是 Windows 内置的应用沙箱，有真实的操作系统级边界，但它是为权限需求明确且固定的应用设计的，Codex 需要驱动开放式的开发工作流（Shell、版本管理、包管理器……），AppContainer 根本没法灵活控制这类需求的写入权限。Windows Sandbox 是一个一次性轻量虚拟机，沙箱边界更强，但 Codex 需要直接访问用户的真实文件和环境，一个需要单独设置和主客通信的虚拟机桌面解决不了问题，而且 Windows Home 版本根本没有这个功能。MIC（强制完整性控制）用标签机制看起来优雅：把 Codex 设置为低完整性级别、把工作区标记为低完整性，让操作系统强制拒绝向外写入。问题是把工作区标记为低完整性会改变整台机器上所有低完整性进程的信任模型，影响范围太广，对用户真实的开发环境语义改变过大。 最终的自研方案核心是两层机制的组合。第一层是为 Codex 创建一个专属的 Windows SID（安全标识符），这个 SID 只属于 Codex 沙箱，外部没有任何普通进程拥有它。第二层是写受限令牌：任何写操作要通过，必须同时满足两个条件，普通用户身份有权限，且受限 SID 列表中也有相应授权。这个双重检查机制让操作系统在内核层面直接执行文件系统隔离，不需要管理员权限，也不依赖进程树里的任何软件层配合。 网络隔离是另一层：要做到真正的强制执行而不是依赖约定，需要防火墙规则，而 Windows 上的防火墙规则必须绑定到特定用户账户。最终方案是创建两个本地用户：一个在线账户、一个离线账户，沙箱内的 Codex 命令以离线账户身份运行，防火墙规则针对这个账户生效。 最终架构是四个独立二进制文件处理不同的信任边界，并不简单，工程博客也坦诚说了这一点。每一层复杂度的增加都是因为更简单的方案留下了真实的安全缺口。这套设计范式的参考价值超出 Codex 本身：所有需要在 Windows 上隔离文件系统的 Agent 系统（AI 编码工具、自动化测试框架、RPA 产品），都可以借鉴这个通过专属 SID 加写受限令牌实现隔离的思路。

译OpenAI团队为Codex在Windows上构建沙箱时，因系统缺乏原生内核级工具，评估并否决了AppContainer、Windows Sandbox和强制完整性控制（MIC）三个现成方案。最终自研方案结合专属Windows SID与写受限令牌，在内核层实现无需管理员权限的文件系统隔离；网络隔离则通过创建特定本地用户账户绑定防火墙规则来强制执行。该架构虽复杂，但为所有需在Windows上实现文件系统隔离的AI Agent系统提供了关键设计范式。

Greg Brockman@gdb · 5月14日42

great excitement from enterprises wanting to adopt codex

译企业对采用codex表现出极大热情 [引用 @OpenAIDevs]：3小时内2000名开发者联系。 让我们共同构建。