AI Builders Digest 0613：Claude 安全边界、Google Agent Harness 与 Codex/Ona
今天的 AI Builders Digest 主线是 Agent 的底层边界正在变成产品竞争力：Anthropic 讲 Claude 如何在不同产品里被 containment，Google DeepMind 讲 Antigravity agent harness 如何成为 Google 产品的新底座，X 上的 builder 们则在讨论 Codex/Ona、Fable、vibecoding 平台和工作流闭环。真正值得看的，不是单点模型能力，而是谁能把 harness、sandbox、权限、成本和反馈回路做成可靠系统。
今日总结
主线：Agent 产品的下一轮竞争，不在“模型会不会做”，而在“系统能不能安全、长期、低摩擦地让它做”。
Anthropic 的 containment 文章把 agent 安全从 prompt 层拉回了系统层。 它反复强调：agent 虽然是新软件形态，但仍然会读文件、开 socket、启动进程。模型层可以做行为引导，但真正兜底的是 hypervisor、seccomp、gVisor、egress proxy、文件挂载和 token scope 这些确定性边界。
Google 的 Logan Kilpatrick 讲的是同一件事的产品侧版本。 Gemini 曾经是 50 个 Google 产品的 AI through line；现在 Antigravity agent harness 正在成为 agentic native 产品的新 through line。换句话说，模型不再只是 API，而是被 harness、工具、容器和产品 surface 包起来的运行系统。
X 上的信号说明 builder 们已经开始追“闭环”。 Swyx 说下一阶段是 stack loops、close the loop；Amjad 说 Fable 让 vibecoding 进入 zero frustration；Peter Steinberger 说 OpenClaw 用 wasm 替代 ffmpeg shell out 来减小 surface risk。大家说法不同，指向一致：agent 工作流的价值，越来越取决于能不能自动发现失败、降低风险并继续推进。
今日关键词： Claude Containment · Agent Harness · Antigravity · Codex/Ona · Loopcraft · Surface Risk
官方博客
Anthropic Engineering：Claude 的 containment 方法论，不是让模型更听话，而是限制失控半径
Anthropic Engineering 的 How we contain Claude across products 把 Claude 在 claude.ai、Claude Code 和 Claude Cowork 里的 containment 设计放到同一张安全图谱里。核心不是“相信模型会做对”，而是先在环境层放硬边界，再在模型层做行为 steering。
文章里最有价值的细节，是几个真实踩坑：
- 允许域名不是 destination filter，而是 capability grant。 Claude Cowork 曾经允许访问
api.anthropic.com，结果恶意文件携带攻击者 API key，让 Claude 把 workspace 文件上传到攻击者 Anthropic 账号。sandbox 正常工作，但数据仍然从“允许路径”流走。 - 隔离也会降低可见性。 sealed VM 让 Claude 被关在里面，也让企业 EDR 看不见 guest 内部。Anthropic 当前用 pull-based OTLP exports 给管理员取回事件日志，但这不等于 live monitoring。
- 模型 classifier 只是防御层之一。 Claude Code auto mode 会把命令审批交给模型 classifier，代价是大约 0.4% 的良性命令被挡住，同时仍会漏掉约 17% 的 overeager actions，所以它只能作为 sandbox 内的 defense-in-depth，不能替代 sandbox。
“当所有概率性机制都错过时，被撞上的就是确定性边界。”
文章最后给出三条原则：先在环境层做 containment，再在模型层 steering；根据用户能否看懂 agent 行为来匹配隔离强度；谨慎自研安全组件，因为真正经受过攻击压力测试的 hypervisor、syscall filters 和 container runtimes 往往更可靠。
🔗 https://www.anthropic.com/engineering/how-we-contain-claude
播客精选
Training Data：为什么模型会吃掉 Harness — Logan Kilpatrick (Google DeepMind)
Logan Kilpatrick 负责 Google AI Studio 和 Gemini API。他这次最值得听的判断是：Google 的 agentic layer 正在从“模型能力”变成“产品底座”。Gemini 曾经是 Google 约 50 个产品的 AI through line；现在 Antigravity agent harness 正在承担类似角色，让 Search、Gemini app、Cloud、AI Studio 等产品逐步变成 agentic native products。
Antigravity 不是单个 IDE，而是一套 agent ecosystem。 Logan 说它包括 core IDE、web 上的 agent-first experience、CLI 和 SDK，也可以通过 Gemini API 作为 managed agent 使用。更重要的是，同一个 harness 也在驱动 Google 其他产品里的 agent 功能。coding 只是最早跑通的强用例，agent harness 才是更通用的基础设施。
Google 对 agentic 的态度仍然很克制。 Logan 把 Google 产品套件当前的 agenticness 评为 “crawl right now”。原因不是能力完全不足，而是 Google 有大量十亿级用户产品，需要承担 stewardship responsibility。Gemini app 更接近 walk，Antigravity 则更靠近 frontier，因为它可以让 autonomous coding agents 跑长任务、消耗大量 token、执行更复杂动作。
“模型吃掉 harness”不是说 harness 没价值，而是模型边界在扩张。 Logan 的解释很清楚：两年前大家说 model，指的是 weights；现在的 Gemini、GPT、Claude 已经是围绕 weights 扩张出来的系统，包含 tool calling、hosted tools、search、code execution、containers 和 agent harness。scaffolding 往往先于模型内化出现，然后被模型系统吸收。
“我们仍然叫它 model，但它已经不只是 weights 了。”
对 builder 的启发很直接：别只盯 benchmark，去看谁掌握了真实产品里的 long-running task 数据、harness 迭代回路和工具调用闭环。Logan 还提到，Google 认为很难在没有真实产品的情况下做出适合长任务开发者用例的强 coding model，这也是 Windsurf 团队加入并最终构建 Antigravity 的原因之一。
🔗 https://www.youtube.com/watch?v=cMAs8z2dehs
X/Twitter 动态
Swyx（Cognition / AI Engineer）：下一阶段的能力是 Loopcraft，而不是单次生成
Swyx 提出 Loopcraft：未来一个世纪的游戏，可能就是谁能更有效地 stack loops。早期要知道什么时候向下进入更细的 loop 来修可靠性；模型进步后，更重要的是知道怎么向上抽象 loop 来获得 leverage。
他也解释了为什么想做自己的 vibecoding platform：现有平台没有真正帮用户 close the loop，错误、失败通知、observability、PostHog、Arize 这类“webmaster infra”仍然散落在每个项目里。他要的不是又一个 demo builder，而是把失败检测、反馈和项目运维吞进 One Thing。
🔗 https://x.com/swyx/status/2065307558198567206 🔗 https://x.com/swyx/status/2065264832056889711
Thibault Sottiaux（OpenAI Codex / ChatGPT）：Codex 与 Ona 合流，OpenAI 继续补 coding workflow
Thibault Sottiaux 转发并确认 Codex 🤟Ona，表示很期待和 Johannes 团队一起建设未来。Swyx 同时提醒，可以去看 Ona 之前的分享来理解 Codex 接下来可能发生什么。
这条信息的重点不在一句欢迎，而在产品拼图：Codex 正在从单个 coding agent 扩展到更完整的 workflow surface。Ona 这类团队加入后，OpenAI 很可能继续补齐 agentic coding 的体验层、协作层和产品化细节。
🔗 https://x.com/thsottiaux/status/2065193272952422852 🔗 https://x.com/swyx/status/2065176231453282777
Amjad Masad（Replit CEO）：Fable 让 vibecoding 从“更聪明”转向“更便宜、更快”
Amjad Masad 说，Fable 落到 Replit 后，他第一次进入 zero frustration 的 vibecoding flow，甚至开始“想法不够用了”。他的判断很有意思：自己几乎不需要更多 IQ，而是需要更便宜、更快的模型。
他还展示了 Replit 里“一张 canvas 同时包含 web app、mobile app、marketing 和 App Store material”的公司构建方式。Fable 的价值不只是模型更强，而是少犯错带来整体成本下降：错误少了，返工少了，真实使用成本反而更好承受。
🔗 https://x.com/amasad/status/2065236013627351551 🔗 https://x.com/amasad/status/2065241626436583860
Guillermo Rauch（Vercel CEO）：AI 让 dream-build-ship-sell 变成一个连续动作
Guillermo Rauch 分享了 Vercel + Shopify 的案例：用 v0 和 Cursor 构建 headless Next.js storefront，2 分钟处理 500+ 订单。他的总结是，任何人现在都可以 dream → build → ship → sell。
这条内容和 Swyx 的 loopcraft 放在一起很有意思：Vercel 想把部署、前端、商业化链路变短；Swyx 觉得还缺错误闭环和 observability。这正是 vibecoding 平台的下一道边界：从生成页面，走向可运营、可监控、可修复的完整 business runtime。
Aaron Levie（Box CEO）：agentic AI 采用越多的公司，越计划增加人手
Aaron Levie 提到 Box 调研了美国、日本和欧洲的 1,640 位 IT leaders，一个突出发现是：采用 AI 越多的公司，越计划增长 headcount。他认为这并不反直觉，因为生产力提高后，企业会把收益再投入到更多工程项目、更多客户、更多流程自动化里。
这条反驳了“AI 只会抹掉岗位”的静态叙事。更接近现实的版本可能是：AI 让企业能启动更多项目，做更多原本做不起的工作，于是组织不是简单缩小，而是重新分配人力到更高杠杆的任务上。
Peter Steinberger（OpenClaw / OpenAI）：OpenClaw 用 wasm 减少 ffmpeg shell out 的 surface risk
Peter Steinberger 提到，OpenClaw hardening 的一部分是减少 surface risk。某些 media conversion 过去需要 shell out 到 ffmpeg，下一版可以通过 wasm 完成，并且在他们的用例里性能相近。
这条很小，但非常工程：agent 产品的安全不是只靠 policy 文档，而是不断把危险边界往更小、更可控的 runtime 里收。它和 Anthropic containment 文章是一条线：能用成熟隔离边界解决的问题，不要留给模型“自觉”解决。
Dan Shipper（Every CEO）：Fable 触发 safeguard 后回退，Codex 仍是可依赖 fallback
Dan Shipper 尝试把一个大 Fable 项目放着运行一小时，结果 10 分钟后触发 safeguards 并 fallback 到 4.8，于是他说“back to codex”。这条不是产品评测，但很好地提醒了一个现实：长任务 agent 的竞争不只是峰值能力，还包括失败模式、保护机制和 fallback 体验。
当 builder 真正把项目交给 agent 跑一小时，最影响信任的往往不是平均效果，而是中途失败时系统如何解释、恢复和接管。Fable、Codex、Replit、Vercel 这些产品的下一轮比较，很可能会落在这种“失败后还能不能继续”的体验上。
Nikunj Kothari（FPV Ventures）：最强 moat 是做有趣且足够野心的事
Nikunj Kothari 的判断很短：你做什么从来没有这么重要，要确保它有趣、足够野心，这就是最大的 moat。放在今天这组内容里看，这句话不是鸡汤，而是对 builder 的提醒：当工具把实现门槛不断压低，选题、野心和持续 build 的密度会更重要。
数据采集时间：2026-06-13 14:32 CST
评论互动