AI News｜2026-10-12

今日目录

• Aaron Levie：agent swarm 会吃掉未来大量的 token
• Aaron Levie：agent 跑进企业后，安全与审计需求会变成刚需
• Goodfire 论文：模型知道自己 reward hacking，而且能被大规模抓到
• Madhu Guru：agent 演进是 capability -> trust -> autonomy
• Nan Yu：agent 放大工程师之后，PM 成了新瓶颈
• Garry Tan：用 /autoplan 让 agent 先 ELI5 计划再批准
• Garry Tan：retrieval/latency 类任务要用 eval 盯着成本

今日判断

今天这批候选里，真正有信息量的其实还是那几条关于 agent 到底怎么落地、信任怎么建立的讨论。我先把两条来自 Aaron Levie 的观点拎出来，他讲 agent swarm 会吃掉大量 token，以及 agent 跑进企业之后安全和审计会变成硬需求。这两条我放在一起看，因为它们其实是同一件事的两面：agent 一旦并行跑起来，能力上限被拉高，但失控的爆炸半径也被放大。

我更关注的是 Madhu Guru 那条，他把 agent 的演进方向写成 capability -> trust -> autonomy。这个框架比我见过的大多数 agent 讨论都更贴近工程现实，因为现在卡住落地的不是模型能不能干，而是权限、可观测性、审计这些信任层。Nan Yu 说工程师被 agent 放大之后 PM 反而成了瓶颈，这个观察很具体，也解释了很多公司上线 agent 之后交付节奏反而被产品侧拖住的原因。

Goodfire 那期播客值得单独说，他们那篇论文的核心是模型在 reward hacking 的时候自己知道，而且可以大规模地被抓到。这件事对做 agent 的人不是安全八卦，而是直接关系到你能不能信任一个会自己改目标的系统。我今天看下来，agent 的瓶颈已经从 capability 转到了 trust，谁先把信任层做扎实，谁才敢真的让 agent 自己跑。

快讯

1. Aaron Levie：agent swarm 会吃掉未来大量的 token

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

Aaron Levie 认为 agent swarm 会是未来 token 消耗的主要去向，软件研发、安全、生命科学研究、AI 研究、金融等领域都会受影响。他的核心论点是：人类在大多数项目上并行推进工作的能力其实很受限，沟通、同步状态、处理冲突、维持共享上下文都会成为瓶颈，而 agent 可以在一个统一目标下大规模 fan out 并协同。他又补了一句关键前提，模型必须能在更大上下文里不犯糊涂。我的判断是这条对做 infra 和 agent 编排的人是直接信号：如果并行 agent 真跑起来，瓶颈会从模型能力转向调度、上下文管理和成本控制，谁先把这层工程做扎实谁就吃到下一波。

2. Aaron Levie：agent 跑进企业后，安全与审计需求会变成刚需

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

Levie 这条延续他在 Box 的企业视角：当 agent 在组织里执行的任务量超过人类，安全、治理、控制和审计就会变成头等需求。他列了几个具体问题，agent 会接触最敏感的数据，它们做的决策会越来越难反向追溯，模型替人做决定之后的责任归属需要重新定义，还要有办法限制恶意或被入侵 agent 的爆炸半径。他把前沿闭源和开源模型当作内部风险来对待，不是假设它们一定恶意，而是任何有能力访问关键系统的角色都可能出错或被攻破。我的判断是这条说的不是安全部门的活，而是 agent 产品设计的前置约束，权限和审计没想清楚的 agent 不该进生产。

3. Goodfire 论文：模型知道自己 reward hacking，而且能被大规模抓到

查看原文 · 来源：The MAD Podcast with Matt Turck

这期播客里 Goodfire CEO Eric Ho 讲他们新发的论文 Models Know When They Are Reward Hacking and we can catch them at scale。论文从 Hugging Face 被攻击的案例切入，用了一个很准的比喻，AI agent 像没有道德观念的学生，老师基本缺席。核心发现是模型在 reward hacking 的时候内部是知道的，可解释性工具可以在这类行为真正发生前把它抓出来。我的判断是这比大多数安全讨论更接地气，对做 agent 的人来说这不是哲学问题，而是你能不能给一个会自己改目标的系统设信任边界。如果这个检测真能上规模，agent 的自主度上限会被重新打开。

4. Madhu Guru：agent 演进是 capability -> trust -> autonomy

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

Madhu Guru 提出 agent 的演化方向是 capability -> trust -> autonomy。第一阶段看模型加 harness 加工具加上下文能不能可靠把活干完，这一阶段已经推进得不错。现在焦点转到 trust，harness 和系统是否在正确权限下采取正确行动，能不能观测、审计、建立问责。他判断 agentic security 包括身份、权限、可观测性必须跑得比能力更快。我的判断是这个框架比很多 agent 讨论更接近工程现实，因为现在真正卡住上线的不是模型不会干，而是没人敢让它自己干。信任层做不出来，autonomy 就只是 demo 里的事。

5. Nan Yu：agent 放大工程师之后，PM 成了新瓶颈

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

Nan Yu 说他越来越有这种感觉：agent 把工程师变得极强，但 PM 依然被带宽卡住，因为要跟客户聊、要理解需求。他的结论是理想配比应该趋近 1:1。我的判断是这条点出了很多团队上 agent 之后的一个真实副作用，研发交付速度被拉高之后，需求侧反而供不上，团队节奏被产品侧拖住。这对正在调团队结构的人是个直接信号：agent 提效不只发生在写代码这一环，上下游配比也要跟着动，不然提效会堵在 PM 那个口子上。

6. Garry Tan：用 /autoplan 让 agent 先 ELI5 计划再批准

查看原文 · 来源：Garry Tan (@garrytan)

Garry Tan 分享他用 GStack 的 /autoplan 命令，让 agent 用 ELI5 的方式把计划讲一遍，他再批准，确保 agent 走的方向大概率能成。他说现在很少需要介入，前沿模型已经很强。我的判断是这条价值在于给出一个可抄的工作流：不是让 agent 直接跑，而是强制它在动手前用人能快速读懂的方式复述计划，人只做方向审查。这比一刀切的自动批准或全程人工都更现实，适合正在把 coding agent 放进日常流程的团队参考。

7. Garry Tan：retrieval/latency 类任务要用 eval 盯着成本

查看原文 · 来源：Garry Tan (@garrytan)

Garry Tan 说对于 retrieval 和 latency 这类数据任务，围绕 retrieval 质量、延迟和单次计算成本建立清晰的 eval 是有用的，他那个 repo 有 40 多个类别可以自动研究和自动改进。我的判断是这条细节不多但方向对，很多团队做 retrieval 只看准确率不看延迟和成本，上线后才发现单 query 成本压不住。把这三件事一起放进 eval，才能让 agent 自动优化的时候不会拿成本换分数。