AI News｜2026-08-03

今日目录

• Nan Yu 提出给 GitHub Issue 直接挂预算，按 spec 驱动云端 coding agent
• Nan Yu 补充了 issue-agent 闭环：agent 在评论区挂上下文，人类补信息后继续跑
• Karpathy 用 1M token 和两小时预算，让 Opus 生成可运行的 three.js 叙事场景
• Anthropic 工程团队公开谈 Claude 在产品内的 containment
• Peter Steinberger 让 agent 通过摄像头调试 ESP32 项目，真实世界测试开始进工作流
• Peter Steinberger 让 agent 直接改本机显示设置，桌面自动化正在越过演示阶段
• Peter Yang 公开点出 OpenAI 插件链路 bug，暴露 AI 工作流接入层仍不稳定
• Aaron Levie 讨论能力分化：通用 AI 变缓，深专业工作流开始垂直起飞

今日判断

我今天更关注两类信号：一类是 agent 真开始碰真实环境，不再只停在聊天框里；另一类是 builder 开始讨论怎样把这些能力接进现有协作系统，而不是继续靠人肉盯着一堆半成品 PR。前者体现在给 agent 摄像头、系统安装权限、长上下文和长时运行预算，后者体现在 issue、评论、上下文回传、费用归属这些具体机制。看下来，AI 产品正在从会回答问题，变成会占用资源、会消耗预算、也会干扰工作流的执行体。

我也注意到一个更现实的分化：消费者侧的体验改进越来越像感受问题，比如回复风格、人格、长短；而专业工作流里的改进越来越像系统问题，比如谁来付 token 成本、怎样控制 agent 写出的代码、怎样隔离模型在产品里的权限边界。Karpathy 那条 1M token 跑两小时写 three.js 的例子，本质不是一个酷炫 demo，而是说明长时推理和代码生成已经便宜到可以试很多过去不会有人手写的东西。与此同时，Anthropic 写 containment，也说明大家已经默认模型会深入产品内部，问题从能不能用，变成怎么关在合适的笼子里。

我的判断是，接下来一线 builder 的差异不会先出现在谁喊得更大声，而是出现在谁把 agent 的执行边界、反馈回路和成本结构设计得更像工程系统。能把 issue 变成可执行 spec、把长上下文变成可复用资产、把权限和 containment 做细的团队，会比单纯追更强模型的团队走得更稳。

快讯

1. Nan Yu 提出给 GitHub Issue 直接挂预算，按 spec 驱动云端 coding agent

查看原文 · 来源：Nan Yu (@thenanyu)

Nan Yu 提了一个很具体的设想：用户在开源仓库开 issue 时顺带 pledge token 预算，维护者接受后，GitHub 把 issue 原文直接交给云端 coding agent，费用由提需求的人承担。它重要，不是因为一句 no more slop PR，而是它把今天最乱的 agent 协作问题拆成了几个可产品化的环节：spec 写在哪、谁批准执行、上下文如何原样传递、失败成本由谁承担。我看下来，这比单纯说让 agent 写代码更接近真实工作流，因为开源社区真正缺的不是模型能力，而是预算、责任和 review 机制的对齐。

2. Nan Yu 补充了 issue-agent 闭环：agent 在评论区挂上下文，人类补信息后继续跑

查看原文 · 来源：Nan Yu (@thenanyu)

Nan Yu 后续补了一条更关键的流程细节：agent 不是闷头干活，而是在 issue 里留言，把当前上下文附上；人类回复补充信息、解除阻塞后，agent 继续工作。这个机制比口号更重要，因为它回答了 agent 进入团队协作后最实际的问题：卡住时怎么办、上下文丢不丢、讨论记录留不留痕。我今天更看重这条，而不是抽象地谈 autonomous coding，因为真正能落地的 agent workflow，往往不是一次跑完，而是像 CI 和 code review 一样，天然支持中断、追问和恢复。

3. Karpathy 用 1M token 和两小时预算，让 Opus 生成可运行的 three.js 叙事场景

查看原文 · 来源：Andrej Karpathy (@karpathy)

Karpathy 做了一个很说明问题的测试：给 Opus 一个《指环王》开头段落、1M token 预算和大约两小时，让它输出 three.js 渲染代码。结果是 5500 行代码，虽然有点粗糙，但确实把文本转成了可运行的程序化场景。我看重的不是作品本身，而是这个实验把模型评测从一句 prompt 小把戏，推向长时任务执行。以前很多定制化小工具，人不会写，因为不值；现在模型能用接近零边际耐心去写。这对 builder 的含义很直接：以后值得做的，不只是更好的 chat，而是那些过去没人愿意投入人力的小型专用软件。

4. Anthropic 工程团队公开谈 Claude 在产品内的 containment

查看原文 · 来源：Anthropic Engineering

Anthropic Engineering 发布了关于怎样在不同产品里 containment Claude 的工程文章。即便候选里只给了标题，我仍然认为这条该进今天的公开稿，因为它触到一个越来越现实的问题：模型不再只是 API 返回文本，而是在产品里拿到更多上下文、工具和执行机会。这样一来，containment 就不是抽象安全口号，而是产品架构的一部分。我今天的判断是，未来 agent 产品的分水岭会越来越像传统基础设施：谁能把权限、沙箱、审计和故障隔离做细，谁才能放心把更强的模型接进真实工作流。

5. Peter Steinberger 让 agent 通过摄像头调试 ESP32 项目，真实世界测试开始进工作流

查看原文 · 来源：Peter Steinberger (@steipete)

Peter Steinberger 说他在做一个基于 ESP32 的 claw node，于是给 agent 开了摄像头权限，让它做端到端测试；结果 agent 不停喊 HI ESP 来调语音唤醒。这条不在于趣味，而在于它说明 agent 已经不满足于 IDE 里改代码，而是开始碰摄像头、语音、硬件状态这些真实世界接口。我看下来，这对 builder 很重要，因为很多 AI 产品下一阶段的壁垒不是 prompt，而是怎么把观察、执行、反馈接成闭环。能进真实环境，就意味着权限管理、误触发和测试成本都会马上变成产品问题。

6. Peter Steinberger 让 agent 直接改本机显示设置，桌面自动化正在越过演示阶段

查看原文 · 来源：Peter Steinberger (@steipete)

Peter Steinberger 说自己忍受 Gmail 亮瞎眼很多年，最后直接让 agent 帮他装好解决方案。这类内容看似很小，但我觉得比很多宏大愿景更有价值，因为它说明一部分高信任用户已经开始把系统级小任务交给 agent 去做，不只是让它回答怎么做。这里真正重要的是执行权限：安装什么、改了哪里、出了错怎么回滚。我的判断是，桌面自动化 agent 要想走出 demo，接下来拼的不是再多几个会话功能，而是把可恢复性、可审计性和最小权限做出来。

7. Peter Yang 公开点出 OpenAI 插件链路 bug，暴露 AI 工作流接入层仍不稳定

查看原文 · 来源：Peter Yang (@petergyang)

Peter Yang 公开请求 OpenAI 看一下插件 bug，因为他想把 /no-ai-slop skill 作为 plugin 发布时，这个问题已经开始影响用户体验。信息不长，但它有价值的地方在于：很多人都在谈 agent 生态、插件生态，可真正卡住 builder 的常常不是模型本身，而是接入层的稳定性、审核机制和调试体验。我今天会把这条放进来，是因为它提醒一线团队别只盯着模型效果，分发链路一旦不稳，再好的能力也很难形成可用产品。

8. Aaron Levie 讨论能力分化：通用 AI 变缓，深专业工作流开始垂直起飞

查看原文 · 来源：Aaron Levie (@levie)

Aaron Levie 的判断是，AI 在个人生活和日常效率上的提升，会和数学、科学、法律、编程这些深专业领域明显分化。前者很多需求很快会被满足，后者几乎没有天花板，但它们需要更深地嵌进数据和工作流。我看这条不是当观点消费，而是把它当今天几条一手信号的解释框架：长时推理、agent 执行、containment、插件 bug，本质都发生在专业工作流一侧。我的判断是，接下来最值得做的 AI 产品，不是再卷一个通用入口，而是把模型能力塞进一个足够深、足够痛的垂直操作链里。