AI News｜2026-10-22

今日目录

• Peter Steinberger：用第二个 agent 做 smart goal，比 subagent 更好用
• Codex/Work 对登录用户永久缓存，API 支持 12 小时缓存
• Guillermo Rauch：把 durability 基础设施开放到所有 harness
• Aaron Levie：agent 的新形态是面向具体任务的 autonomous system
• Swyx 吐槽 Opus 写东西时被随机词触发拦截，prod 比 god 更重要
• Aditya Agarwal：Inference scaling 到 subagent、swarm 像 CPU 多核史

今日判断

我今天更关注的是 Agent 工程化里那些琐碎但决定能不能真正上生产的问题。Peter Steinberger 那个把 planning 交给 Astra、coding 交给另一个模型、再让第二个 agent 专门去 challenge 目标的流程，比单纯堆 subagent 有意思，因为他把 review 从同一个 agent 看文本文件，变成了另一个 agent 来挑刺，这其实是在用软件工程里的 code review 心智改造 agent workflow。另一个方向是 Thibault 说的 codex 缓存，对登录用户跨会话永久缓存、保证命中，这直接影响的是长会话 agent 的成本结构和恢复体验，缓存策略开始变成 coding tool 的核心竞争力。Guillermo 把 durability 抽象出来复用到不同 harness 上，也是在承认 Claude Code、Codex 这类工具目前不是为嵌入设计的，效率和可移植性要另外补。我看下来，这一波 builder 做的不是更炫的 agent，而是让 agent 跑得稳、回得来、成本可控的基础层，这才是真实工作流里最卡人的地方。

快讯

1. Peter Steinberger：用第二个 agent 做 smart goal，比 subagent 更好用

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

Peter Steinberger 描述了自己的 coding workflow：Astra 负责规划，Sol 6.1 负责写代码，让 Astra 通过 codex cli 在 worktree 里干活，比依赖 subagent 效果好很多。他还加了一个第二 agent 来监督 Aster 的工作、挑战它的目标，而不是让同一个 agent 自己 review 文本文件，并为此写了 OC-plugin 的 smart goal 功能。为什么重要：这提供了一个可复用的 agent 协作模式——planner 和执行者分离，独立 reviewer 强制挑刺，接近人类团队的 code review。我的判断是，这种角色拆分加独立挑战的设计，比单纯增加 subagent 数量更能提升长任务成功率，也更容易沉淀成团队可复制的 harness 配置。

2. Codex/Work 对登录用户永久缓存，API 支持 12 小时缓存

查看原文 · 来源：Thibault Sottiaux (@thsottiaux)

Thibault Sottiaux 宣布 API 现在可以缓存 12 小时；而登录用户在 Codex 和 Work 里，缓存在对话之间永久保留，隔几小时回来继续旧对话不会被惩罚，并且保证命中缓存。为什么重要：长会话 agent 的成本大头经常在重复 prefill，缓存策略直接决定多轮、断点续作和后台任务的可行性。我的判断是，这把缓存从后台优化变成了产品竞争力：谁能让用户放心地让 agent 长时间跑、随时回来，谁就能吃到更复杂的工作流。对 builder 的信号是，设计 agent 时应该把缓存命中率当作一个可观测的工程指标，而不是只盯着 token 单价。

3. Guillermo Rauch：把 durability 基础设施开放到所有 harness

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

Guillermo Rauch 说会像之前 aisdk 一样，把支撑 eve 和 Workflows 的 durability 基础设施扩展成运行时无关的开放方案，覆盖 Pi、OpenCode 等 harness，支持本地、Vercel 或自建。他顺带指出 Claude Code 和 Codex 也能被做成 durable 和可观测，但这两个工具目前不是为嵌入设计的，效率、可移植性更差，还多一层 sandbox 要求。为什么重要：durability 和可观测性正是 agent 从 demo 走向生产的关键缺口。我的判断是，把 harness 的持久化能力抽出来做成通用层，会让不同 coding agent 之间的差异更多落在模型和交互，而不是各自重复造基础设施。

4. Aaron Levie：agent 的新形态是面向具体任务的 autonomous system

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

Aaron Levie 认为 AI 正在形成一种可预期的形态：专门针对特定任务或领域的 autonomous system，而不是 LLM wrapper。他的核心论据是模型在 tool use 和 computer use 上的能力提升，让 agent 能拿到更细粒度的外部数据系统和软件访问权，从而像人一样执行工作流；在没有现成软件的地方，agent 还能直接操作计算机。为什么重要：这给出了企业侧 agent 的产品边界判断，重点不是聊天，而是接管可被信任的职能工作流。我的判断是，企业 builder 的机会在那些有明确流程、有可审计回报、但还没被软件覆盖的环节，agent 的价值取决于它能拿到多细的权限和多少上下文。

5. Swyx 吐槽 Opus 写东西时被随机词触发拦截，prod 比 god 更重要

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

Swyx 说 Opus 写作能力很好，但 prompt 里出现随机的一些词就会触发问题，他原话是 give me prod, not god，意思是宁要稳定可预测的生产模型，不要随时可能拒绝的神级模型，因为他在搭一个 AI media org，这类拦截在关键路径上没法接受。为什么重要：这是模型安全/对齐策略直接变成产品可用性问题的现场案例，尤其对内容生成和 agent 自动化的 builder。我的判断是，模型选择不能只看 benchmark，还要看拒绝率和不可预测性；关键路径上应该做多模型 fallback，把安全触发当作一种必须设计进系统的错误类型。

6. Aditya Agarwal：Inference scaling 到 subagent、swarm 像 CPU 多核史

查看原文 · 来源：Aditya Agarwal (@adityaag)

Aditya Agarwal 把 inference time scaling、subagent、agent swarm 的演进类比成 CPU 线程、多核 CPU、多节点分布式系统，说历史在押韵。为什么重要：这个框架提醒 builder，agent 编排遇到的问题很可能已经有成熟解法，比如调度、隔离、失败重试、可观测性，不必从零发明。我的判断是，接下来 agent infra 的竞争会越来越像分布式系统竞争，谁先把线程/进程/任务队列那套工程经验迁移过来，谁就能更快把 swarm 从酷炫 demo 做成可靠系统。