这周，Box CEO Aaron Levie 在 X 上发了一组判断，核心意思很直接：「Agent 群组（agent swarms）将成为未来许多企业工作流的核心部分。」他给出的理由也很朴素：agent swarm 能把一个可以拆解成多个子任务的问题，用算力同时并行处理，而不是像人类团队那样按部就班地排队干。在他列出的受益场景里，网络安全被排在最前面——「网络安全会是最大的受益者之一」，原因是攻击路径的排查，本质上就是一个要把大量可能的漏洞场景串联起来验证的工作，特别适合用不知疲倦、可以并行跑的 Agent 去做。
token 消耗量，会成为安全预算的新度量单位
Levie 判断里最具体的一句话是：网络安全领域的 Agent 群组，「将成为大型企业里最大的 token 消耗场景之一，因为需要被持续保护的 IT 系统、软件、物理基础设施和数据范围实在太广」。这句话值得拆开看：它意味着安全团队未来要为 Agent 的运行成本编预算，而不只是为安全工具的订阅费编预算。过去安全工作的瓶颈是人手——一个团队能同时追踪多少条攻击链，取决于有多少分析师。Agent swarm 把这个瓶颈换成了算力和 token 预算，理论上可以同时追踪的攻击面从「分析师数量」变成了「你愿意花多少钱跑并行任务」，这是一次性质上的转变，不是效率上的小幅提升。Levie 更早前判断过，五年之内，企业里 90% 的 token 消耗将由「无人类直接触发」的 Agent 活动产生，这意味着企业安全体系需要防御的，将主要是机器发起、而不是人类发起的行为。
Agent swarm 真正打破的，不是防火墙，而是一个假设
Levie 在和 a16z 的 Martin Casado 对谈时提出过一个更尖锐的说法：企业现有的系统权限设计，建立在一个假设之上——「绝大多数人几乎总是做正确的事，蓄意滥用权限是极其罕见的个例」。这个假设支撑了企业过去几十年的访问控制逻辑：给每个员工该有的权限，剩下的交给信任和偶尔的审计。但 Agent swarm 并不会让「蓄意滥用」变得更常见，它改变的是另一个变量——原来系统从未真正防御过的那个变量，也就是错误发生的速度和规模。一个人类员工一天能犯的错误数量，天然受限于他一天能做多少次操作；而一个 Agent swarm 可以在几分钟内，把同一类操作并行执行几千次。系统的权限模型没有变，但犯错的吞吐量变了几个数量级，这才是真正的风险敞口，而不是某个具体 Agent 写得够不够好。
「企业系统的访问控制，建立在『人类不会大规模同时犯错』这个假设上。Agent swarm 不会让蓄意滥用更常见，它移除的是这个系统从未真正防御过的那个变量：错误发生的速度上限。」——改述自 Aaron Levie 与 Martin Casado 的对谈
a16z 播客对谈
安全和生产力，从来是同一个权限问题的两面
Levie 还点出了一个经常被回避的矛盾：安全和生产力增益在 AI 时代是互相绑定的，而不是两件可以分开优化的事。给 Agent 足够的信息访问权限，它才能真正提升生产力；但访问权限给得越宽，一旦它判断失误或者被滥用，影响范围就越大，真正把一切都锁死，AI 带来的生产力提升也就无从谈起。这不是一道可以靠「更严格的审批流程」单方面解决的题，因为审批流程本身也要跟上 Agent 的执行速度——如果每一步都要人工审批，Agent 并行处理的优势就被审批环节重新拖回了人类速度。真正可持续的解法，更可能是把权限颗粒度做细（Agent 只能看到它该看到的那一小块数据），把日志做实（每个动作都能追溯到具体是哪个 Agent、基于什么指令做的），而不是简单地在「给不给权限」这道二选一的开关上做文章。
这套逻辑，小团队现在就用得上，不用等到「群组」规模
大部分中小团队眼下还不会同时跑成百上千个 Agent，但 Levie 指出的这个权限问题，在只有三五个 Agent 的时候就已经存在了：一个能读工单系统的客服 Agent，一个能调发票接口的财务 Agent，分开看都合理，一旦权限设计得不够细，出问题的时候同样说不清是哪个环节的锅。与其等到规模变大之后才去补治理，不如从一开始就把每个分身的权限边界和操作记录当成基本配置，而不是事后补丁。这也是为什么像 KarmaBox 这样的分身平台，会把「每个分身的记忆和权限各自独立、所有调用都留痕」做成底层设计，而不是等用户自己去管几十个散落的 API Key——规模还没到「群组」那一步时把地基打好，比规模上来之后再推翻重做，成本要低得多。
