Levie 说 AI 竞争转向 context，Steipete 把 Codex 设计问题丢给 Image Gen：7月4日精选 (2026)

今天最有用的一组推文指向同一件事：agent 的竞争已经不只是模型强不强，而是谁能把上下文、工具、运行环境和人的审核环节接得更顺。Levie 把它说成「context 之战」，Rauch 则把这个问题落到了 agent 自省、MicroVM 和 Sandbox 上。

先看 5 个信号

信号	这条推文说了什么	读者该留意什么
应用层争夺上下文	Aaron Levie 说，AI 竞争正在变成 context 竞争：agent 是否有效，取决于它有没有领域知识、上下文、工具，以及用户能不能审阅和接入工作流 1。	企业 AI 的护城河更像数据治理和流程接入，不只是套一层模型 API。
agent 需要复盘自己	Guillermo Rauch 说，agent 应该能回看过去运行记录，发现低效、错误和重复工具调用，再生成新 prompts 和 skills；他把这解释为 Eve 部署到 Vercel 时内置 observability 的原因 2。	agent 平台会从「执行任务」继续往「改进自己的执行方式」走。
Sandbox 变成更完整的运行环境	Rauch 还提到 Vercel Sandbox 现在可以运行 `docker` 和 `fuse`，并把 MicroVM 称为 Fluid compute 的基础 3。	coding agent 不只需要模型，还需要接近真实机器的隔离运行环境。
Image Gen 进入设计循环	Peter Steinberger 建议，如果觉得 Codex 不擅长设计，可以让它先用 image generation 重新想象设计，再实现出来 4。	设计不再只是让代码模型凭空写 CSS，而是多模态模型先给方向，coding agent 再落地。
「工具」越来越难卖	Zara Zhang 说，用户越来越不愿意买单纯工具，因为他们会觉得 coding agent 可以自己做；他们愿意付费的是「像雇到自己没有的专业能力」 5。	AI 产品的卖点会从功能清单转向专家型结果。

Levie：AI 应用层的价值，是把 context 管起来

Levie 这条长推是今天最完整的框架。他的核心判断是：agent 的效果来自三件事，领域知识、可访问的上下文和工具、以及用户能否把 agent 的产出接进原工作流。换句话说，agent 不只是「模型回答问题」，而是要知道公司内部材料在哪、权限怎么管、结果给谁看、下一步由谁接手 1。

Loading content card…

他把应用层的价值拆得很具体：组织关键知识、按权限把知识交给正确的人和 agent、持续改进上下文质量，再根据任务把工作路由给不同模型。这里的「模型路由」不是简单省钱。Levie 设想的分工是：前沿模型负责规划、编排和审阅，低成本模型承担中间的大量执行任务 1。

这也解释了他为什么继续强调 FDE，也就是 forward deployed engineer。它不是传统售前，而是把客户的具体业务问题做成端到端工作流的人。只卖模型调用的公司，很难碰到这层工作；真正麻烦、也更值钱的部分，是让 agent 进入一个公司真实的权限、内容和审核结构。

Rauch：agent 平台开始补「运行循环」

Rauch 的两条推文刚好补上 Levie 框架里的工程侧。他先谈 agentic self-improvement：agent 应该能检查过去的运行记录，找到低效、错误和重复工具调用，再产出新的 prompts 和 skills 2。

Loading content card…

这里的关键词是 observability。过去这个词主要属于后端服务，意思是能看见系统为什么慢、哪里报错、哪条链路出问题。放到 agent 上，它变成了另一件事：不只看结果成功或失败，还要看 agent 每一步为什么这么做、哪些工具调用是浪费、哪些失败可以被写回下一轮策略。

另一条关于 Sandbox 的推文更底层。Rauch 说 Vercel Sandbox 现在可以无约束运行 docker 和 fuse，并称 MicroVM 带来即时启动和不受限 runtime 3。如果 agent 要真正执行代码、跑依赖、挂载文件系统、访问临时环境，隔离运行时就不是后台配套，而是产品能力的一部分。

这两条放在一起看，Vercel 正在补的是 agent 的运行循环：执行、观察、复盘、修改策略，再回到执行。模型只是其中一层。

Codex 的设计问题，可能要交给 Image Gen

Steinberger 今天最高信号的一条不是长分析，而是一句具体操作：觉得 Codex 做设计差，可以试试「use imagegen to re-imagine this design and implement that」4。

Loading content card…

这句话背后的工作流变化很大。以前让 coding agent 做 UI，常见失败点是它只会在既有组件和 CSS 里小修小补，审美方向没有被重新打开。现在更可行的路径是：先让图像模型给出一个新的视觉目标，再让 coding agent 实现那个目标。设计方向和代码实现被拆成两个模型步骤。

Peter Yang 也给了类似线索。他预告一集访谈会讲 OpenAI 的 Codex PM 如何用 Codex 做产品工作，包括用 Image Gen 快速探索设计、从 Slack 触发 Codex 自动化、用一个 Codex thread 管理其他 thread 6。这不是纯工程师工具的叙事，而是 PM 把 Codex 当成产品工作台来调度。

swyx 的吐槽也落在同一条线上。他说「tools for thought」社区花了十年做漂亮 canvas demo，结果被低对比度、设计很差的 CLI 击败，因为 CLI 能替人做「commodity thinking」7。这句话不一定公平，但抓住了一个现实：当模型能直接处理大量琐碎思考，界面美感本身不再是决定性优势，能不能把任务跑完更重要。

Claude / Gemini / CodexBar：工具正在收束成工作台

cat wu 给了一个很实用的小技巧：可以让 Claude Code 搭配 computer use 来设置 Claude Tag，只要指向 Claude Tag 文档，它就能为团队连接 GitHub repo、data warehouse、Google Drive 和其他数据源 8。

Nikunj Kothari 则从另一侧讲平台收束。他说自己一直批评 Gemini 的产品体验，但 Gemini 仍是少数「一个 API key 基本都能做」的地方，列到的能力包括 Flash、Nano Banana、grounded search、Realtime audio，以及 video 方向的 Omni 9。

Steinberger 的 CodexBar 更新也值得放进跟踪项：这个 macOS 菜单栏工具现在支持 56 个 AI coding providers，用来追踪使用窗口、credits 和 reset 时间 10。这类工具看起来小，但它反映的是开发者已经同时用很多 coding provider，成本、限额和可用窗口本身变成了日常管理对象。

Dan Shipper 还指出一类 benchmark 误读：他认为某个比较里实际是同一个模型，但因为会更多 fallback 到 Opus 4.8，benchmark 测到的是 Fable 和 Opus 的混合结果 11。这提醒我们，模型表现越来越不像单一模型的裸测成绩，而是路由、fallback 和产品策略一起影响出来的结果。

Zara：如果 agent 能搭工具，用户为什么还要买工具

Zara 的判断很适合拿来收尾。她说用户越来越不愿意买「只是工具」的产品，因为如果只是工具，他们会觉得自己可以用 coding agent 搭出来；他们愿意付费的是「像雇到自己没有的专业能力」5。

Loading content card…

这句话对小团队尤其刺耳。过去一个 SaaS 可以靠功能完整、界面顺手、价格合适活下来。现在如果用户相信「我让 agent 写一个也差不多」，产品就必须证明自己提供的不是工具壳，而是一种判断力、流程经验或结果交付能力。

把今天这些推文连起来，结论并不复杂：模型能力在扩散，真正难做的是 context、运行环境、可观察性、工作流接入和专业结果。谁能把这些东西接成一条稳定的链路，谁才更像下一阶段的 AI 产品。

Levie 说 AI 竞争转向 context，Steipete 把 Codex 设计问题丢给 Image Gen：7月4日精选

先看 5 个信号

Levie：AI 应用层的价值，是把 context 管起来

Rauch：agent 平台开始补「运行循环」

Codex 的设计问题，可能要交给 Image Gen

Claude / Gemini / CodexBar：工具正在收束成工作台

Zara：如果 agent 能搭工具，用户为什么还要买工具

References

More from this channel

Related content