AI News｜2026-08-07

今日目录

• 用远程 KVM 让 coding agent 接管真实设备测试
• 给 agent 加一个可视化人工审阅层，解决最后 10% 文档修改
• Vercel 把 agent 算力配额直接拉到大规模并发
• 真正拖慢 AI 扩散的，是把实验室术语直接塞给用户
• 企业场景会吞掉绝大多数 token，但扩散速度取决于流程重构
• 多线程 agent 正在长出最早期的任务编排形态

今日判断

我今天更关注两类信号：一类是 builder 真的把 agent 接进现有工作流，哪怕方式很土；另一类是越来越多人承认，AI 产品的扩散瓶颈已经不是模型会不会做，而是入口、上下文和人工接管怎么设计。前者我看到有人直接给 coding agent 接上带视频的远程 KVM 去跑 iMessage 的真实端到端测试，这种做法不优雅，但很像接下来一批有效 AI 产品的真实样子：先把系统接进脏环境，再慢慢产品化。后者则很明确，blank prompt、模型选择、agent/memory/MCP 这些术语还在把大多数真实用户挡在门外，谁能把这些复杂度吞掉，谁才更接近规模化使用。

快讯

1. 用远程 KVM 让 coding agent 接管真实设备测试

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

Peter Steinberger 说，他给 Codex 接了一个带视频的远程 KVM，让它去自动化测试 OpenClaw 的 iMessage 集成，因为 iMessage 在 VM 里并不稳定，像已读回执这类功能还要求关闭 SIP。这个信息我会高看一眼，不是因为它酷，而是它很具体地说明了 agent 落地时真正的阻碍：不是写代码，而是怎么摸到真实环境、真实设备和那些跑不进沙盒的系统能力。我的判断是，接下来 builder 的差异会越来越多体现在这类环境打通能力上，谁能先把 agent 接进脏活累活的边角系统，谁就先吃到自动化红利。

2. 给 agent 加一个可视化人工审阅层，解决最后 10% 文档修改

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

Peter Yang 发布了一个 /human-review skill，可以让 Codex 或 Claude Code 打开可视化编辑器，直接修改 HTML 和 Markdown，支持排版、图片调整和像 Google Docs 一样给 AI 留评论，最后再把修改发回 agent 应用。他点的场景是 PRD、落地页和文档。我看下来，这类能力比再多一个更强模型更贴近真实团队，因为很多内容工作并不是生成完就结束，而是要在人和 agent 之间来回修。我的判断是，agent 产品接下来会普遍补上这种 review surface，不然最后那点需要人眼判断的细节，会一直把自动化卡死在半成品阶段。

3. Vercel 把 agent 算力配额直接拉到大规模并发

查看原文 · 来源：Guillermo Rauch (@rauchg)

Guillermo Rauch 提到，agent compute 可以提供 10,000 路并发和每分钟 5,000 CPU cores，而且这些配额还能继续上调。单看一句话不算完整发布说明，但我觉得这个数字很值得记，因为它意味着平台方已经不是按聊天窗口去想 agent，而是在按批量任务系统和后台 worker 去配资源。对做 agent workflow 的团队，这会直接影响产品边界：以前很多多任务编排、批处理、回填、索引更新要自己搭，现在可能能更多借平台层。我的判断是，agent 基础设施竞争会越来越像云计算，而不是像聊天产品。

4. 真正拖慢 AI 扩散的，是把实验室术语直接塞给用户

查看原文 · 来源：Madhu Guru (@realmadhuguru)

Madhu Guru 说，AI 扩散慢，不是用户不需要能力，而是产品一上来就让用户面对空白输入框，再逼他们理解 prompt、模型、agent、context window、MCP、memory、skills 这些术语。用户其实不在乎这些，他们只想把事情做完。我基本同意这个判断，而且今天看到的人机审阅层、真实设备测试，正好都在说明同一件事：builder 需要把复杂度往系统里吞，而不是甩给用户。我的判断是，未来 12 个月真正跑出来的 AI 产品，大概率不是把模型参数讲得更清楚，而是把用户该做的选择尽量删掉。

5. 企业场景会吞掉绝大多数 token，但扩散速度取决于流程重构

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

Aaron Levie 认为，世界上 99% 的 token 最终会消耗在企业场景里，比如写代码、生命科学研究、制造自动化、企业安全和反欺诈。更重要的是，他补了一句常被忽略的话：agent 扩散会很慢，因为组织必须先重构工作流，AI 才能真正嵌进去。我觉得这个判断对 builder 比较有用，因为它提醒大家不要只盯模型成本下降，而要盯集成、权限、审计、交接和人机协作这些脏问题。我的判断是，企业 AI 的天花板很高，但不是先靠 demo 拿下，而是先靠 workflow 改造啃下来。

6. 多线程 agent 正在长出最早期的任务编排形态

查看原文 · 来源：Swyx (@swyx)

Swyx 说，一个很原始但很接近短期 multi-agent 未来的做法，是开多个线程，让其中一个完成后再回 ping 另一个，于是自然形成一个带依赖关系的 kanban 或 waterfall graph，而且每个线程都保留自己的上下文和工作状态。这还不是成熟产品，更像高手手工搓工作流，但我觉得它有参考价值，因为很多 agent 编排现在都过度平台化，反而忽略了用户最先需要的只是可见的依赖关系和状态管理。我的判断是，下一波 coding agent 的差异不会只是会不会写代码，而是谁先把多线程任务图做成普通人能用的界面。