Agent swarm 会吃掉所有 token；PM 的瓶颈不是带宽吗

Aaron Levie：token 的未来在 agent swarm，所以需要 1000 倍算力

Aaron Levie 说，未来 token 的主要消耗场景是 agent swarms，会在软件开发、cyber、生命科学研究、AI research、金融等企业领域产生巨大影响。他认为 agent 可以围绕一个统一目标并行展开，在人手再多也受限于沟通、同步状态、处理冲突和共享上下文的项目上，采用跟人完全不同的方式协作。当模型能处理更大 context 而不混乱、又能通过共享基础设施彼此通信时，可以避开很多人会踩的坑。他据此判断，这不只会让任务跑得更快，还可能在医学、研究、防御网络攻击、科学和数学发现上带来质变，这也是为什么“we're going to need 1,000X more compute”。（来源：https://x.com/levie/status/2109079686286565378，2026-10-11）

open letters 的看法：这句话的产品含义不是“算力贵”，而是“并行度”从技术指标变成了组织指标。今天多数公司的瓶颈不在模型能不能拆任务，而在有没有一套共享状态让一堆 agent 不互相打架。谁先把“任务分发、共享上下文、冲突仲裁”做成产品原语，谁就拿走了那 1000 倍的一部分。

Madhu Guru：agent 竞争的下一阶段是从 capability 到 trust

Madhu Guru 说，agent 能力很快会以 RSI 节奏演进，而 agentic security（identity、permissions、observability）必须跑得比这个更快。他把 agent 领域的演化方向概括为 capability -> trust -> autonomy：第一阶段看模型加 harness 加工具加 context 能否可靠把活干完；能力已经走得挺远了，所以焦点转向 trust，，harness 或系统是否用正确权限采取正确行动、能否被观察、审计、建立问责。他说过去几年已经有不少严肃工作在解决这些问题，但挑战现在变得更重要、也更难。（来源：https://x.com/realmadhuguru/status/2108982858513776899，2026-10-10）

open letters 的看法：把“信任”当成一个阶段，而不是一个功能，这有用。它意味着采购逻辑会变：客户不再只问“你能做多难的事”，而是问“我能不能在出事之后把过程倒出来看”。对做 agent 产品的人，审计日志和权限模型该进 roadmap 的第一屏，而不是等企业客户来提需求。

Aaron Levie：AI 需要自己的 zero trust 时代，把模型当成 insider risk 来管

Aaron Levie 转发并评论了一篇关于企业长期管理 intelligence 的安全思路，他的观点是：当 agent 执行的任务远远多于人，安全、治理、控制和审计这件事会变得 paramount。他指出 agent 会接触你最有价值的数据、做出越来越难被 reverse engineer 的决策、需要明确模型替我们做决定时的 liability 和 accountability 机制，也需要办法把恶意或意外 agent 的 blast radius 控制住。他引用的一段话说，把前沿闭源和开放权重模型当成 insider risk 来对待是一种建立这套系统的办法，，不是因为它们一定恶意，而是任何有足够能力、又能接触重要系统的行动者都可能犯错或被攻破，所以封闭和控制的架构必须考虑到这一点。他补充说，AI 某种意义上需要经历安全行业当年的“zero trust”时代，而围绕 agent 行为、可用数据、出错控制的层层保护和可审计性，是目前企业端巨大的机会。（来源：https://x.com/levie/status/2108952226714865966，2026-10-10）

open letters 的看法：这条和上一条其实在说同一件事，但 Levie 给了一个更好用的类比：不是“相信模型”，而是“永不默认信任，每次验证”。落到产品上，agent 的权限不该是一个静态开关，而应该是随任务收窄、随结果放大的。哪个团队先把这套做成默认体验，企业采购的默认问题就会从“能不能用”变成“用谁的”。

Nan Yu：agent 让工程师变强，但 PM 还卡在客户带宽上，理想配比是 1:1

Nan Yu 说他自己也有这种感觉：agent 让工程师变得 extremely powerful，但 PM 普遍还是被他们必须跟客户沟通的带宽卡住。所以他给出的理想配比是 1:1。（来源：https://x.com/thenanyu/status/2108976262698115550，2026-10-10）

open letters 的看法：这条短，但方向感很强。如果工程师的杠杆变大了，而 PM 的客户接触面没变，那瓶颈就会转移，团队里会出现“做得多、听客户听得少”的失衡。1:1 不一定适合每个团队，但它是个好的自检问题：engineering 提效之后，你多出来的产能，有没有被真实客户输入重新校准过。

Agent 提效之后，瓶颈会从模型能力转移到三个更笨的地方：权限、审计、客户带宽

把今天的来源放在一起看，有一条挺清楚的线：大家都在说 agent 会变强，但没人敢跳过 trust 这一层直接谈 autonomy。Levie 说要把模型当 insider risk 来管，Madhu Guru 说演化方向是 capability -> trust -> autonomy，两个人用不同词说了同一件事，能力已经不是最稀缺的了。

这对产品经理的含义是，接下来一两年难的不是 prompt 写得更好，而是设计一套“默认不信任、每次可归因”的运行环境。identity、permissions、observability 这些词听起来像安全团队的活，但它们会直接变成产品体验的一部分：用户敢不敢把 agent 放出去，取决于出错时能不能一键倒回。

Nan Yu 那条是另一个方向的提醒。工程效率提上来之后，如果 PM 跟客户的接触时间没变，决策质量反而可能下降，因为团队跑得更快，但方向校准得更少。1:1 是个具体数字，不用照抄，但“提效之后有没有多出来的客户输入”这个问题，值得每个团队在下一个 planning 周期里认真问一次。

最后是一个略微反直觉的判断：短期内 agent 产品的竞争点可能不是谁更自主，而是谁更可解释、更好收回。因为企业客户掏钱的那一刻，买的不是能力上限，是失败下界。

以上是 open letters 的编辑判断，不是任何单一来源的原话。

用 Garry Tan 提的三类 eval（retrieval、latency、cost per compute）给自己的 agent 做一次体检

Garry Tan 说他给 GBrain 这类 retrieval 和 latency 数据任务设了围绕 retrieval、latency 和 cost per compute 的清晰 eval，他提到自己的 repo 有 40 多个类别，每个都能自动研究和自动改进（https://x.com/garrytan/status/2108954738540863498）。这套思路可以缩成一次下午就能跑的小体检，前提是你能拿到自己 agent 的调用日志或能自建一批测试用例。

你是我这个 agent 产品的 eval 设计师。请基于我提供的调用日志或让我补充的最小测试集，帮我设计一套最小可用的三类 eval：1）retrieval：给 10 到 20 个真实查询，每条标注“期望召回的片段/文档/字段”，输出 recall@k 和一个简短失败归因；2）latency：给 p50、p95、p99 三个分位，并指出延迟主要花在检索、模型调用还是后处理；3）cost per compute：按每次任务估算消耗的 token 和金额，并区分检索、推理、工具调用各自的占比。最后，把这三类合成一张一页的体检表，标出最该先改的一到两项，并说明每一项改动可能牵连到的其他指标。所有数字如果我没有提供，请明确标注为待填，不要替我假设。

这套 eval 需要你先有调用日志或愿意手写测试集，没有日志就只能得到一份模板而不是结论。retrieval 的标注涉及人工判断，别把模型自评当成 ground truth。这个 prompt 不承诺任何效果提升，只是帮你把“哪里慢、哪里贵、哪里漏”先摆到桌面上。

Garry Tan 用 auto-plan 但坚持自己批计划，只偶尔干预

Garry Tan 说他用 GStack /autoplan，让 agent 用 ELI5 的方式解释它给出的计划，并且他仍然会批准计划，确保它走的是他认为可能work的路径；但他很少需要干预，因为现在的前沿模型非常好。在另一条里他提到这套东西最好配合 experimental modes（包括 Captain 打开）使用，他用一个 thread 来协调和跑 merge PR queue、确认 CI work、只有 full CI 全绿才进 master。（来源：https://x.com/garrytan/status/2108954740013043789，2026-10-10；https://x.com/garrytan/status/2108954741065879945，2026-10-10）

判断方式：这是一个很好的“人在环里但不必事事插手”的样本。它的关键动作不是让 agent 自己跑，而是要求它先把计划讲清楚到 ELI5，人再批。你可以照这个形状设计自己的审批点：不批每一步执行，只批计划；但审批前强制 agent 用大白话复述它要干什么。这条没有承诺省了多少时间，重点在审批的颗粒度。