在 Agent Night 现场，我看到了 AI agent 进入企业的最后一块拼图

上周我去参加了 WorkOS 在旧金山 Regency Ballroom 举办的 Agent Night Live。说实话，这类活动我参加过不少，很多时候走进去，走出来，脑子里留下的东西并不多。

但这次不一样。坐在台下听完整场活动，我脑子里一直在转一个问题：我们把 AI agent 接入了越来越多的系统，给了它越来越大的权限，但这件事背后最危险的漏洞，我们好像一直没正面解决过。那天晚上，我看到了一个让我觉得终于有人认真想清楚这件事的答案。

从单人游戏到多人游戏 这个变化比你想的更深

WorkOS 的 CEO Michael Grinich 开场讲的第一件事，不是产品，不是融资，而是一个认知框架的转变。他说，一年前我们用 AI 的方式是单人模式，agent 在你旁边帮你干活，你问它，它回答你，像个 copilot。但现在完全不一样了，agent 在做研究、分析数据、协调项目、准备客户会议、处理运营工作，而且是跨整个组织在跑。不再是一个人旁边站着一个 AI，而是一整支团队都在跟 agent 协作。

他引用了 Notion 创始人 Ivan Zhao 的一句话："管理无数个大脑的感觉。" 我觉得这句话说得非常准。Spin up 几个 agent，把不同任务分发出去，像管理一个团队一样协调它们。听起来很美好，但 Michael 紧接着说了一句我觉得很清醒的话：这个比喻里真正重要的词不是"无数个大脑"，而是"管理"。我们现在都变成了 manager，而管理这件事，是很累的。你要定目标、给上下文、审核结果、纠正错误、教会它下次怎么做——这跟管人没什么两样，只不过管的是 agent。这也解释了为什么很多人现在感觉工作比以前更累了，不是因为活变多了，而是工作的性质变了，你从执行者变成了协调者。

他还提到了一个让我很有共鸣的观察：软件工程是目前 AI agent 影响最大的领域，没有之一。原因不是偶然，是结构性的。写代码这件事天然就是为 agent 设计的，有专属的运行环境，有共享的代码库做上下文，有测试、有文档、有版本控制、有终端做交互，反馈循环是完整的。换句话说，coding agent 一进来就有现成的轨道可以跑。但如果你把 agent 放进一个普通企业，那个"轨道"根本不存在。没有结构化的组织记忆，没有标准化的流程文档，没有清晰的权限边界，什么都是碎的。所以那天晚上很大一部分内容，其实是在讨论怎么给企业里的 agent 建这条轨道。

我们一直在逃避的那个问题

我自己用过不少 agent 工具，Claude Code、Cursor、各种 MCP 集成，用起来很爽，但有一件事我一直隐隐感到不安，却没有仔细想过：我到底给了这些 agent 什么权限？它能访问我的哪些数据？它出了问题，谁负责？

Michael 在台上说了一段话把这个问题说得很直接。他说大多数人在用 agent 的时候，要么走一个极端，每一步都要手动审批，agent 做任何事情之前都要问你一声——能不能执行这个命令？能不能改这个文件？你在旁边疯狂按确认键；要么走另一个极端，直接开 YOLO 模式，把所有权限全部授出去，然后祈祷它不要把你的数据库清空。他说他自己也经历过这个过程，一开始被问烦了就全部批准，然后心里一直有个声音在说，希望它不要删掉我的 home 文件夹。

这两个极端之间，有一个巨大的空白地带，没有人认真填过。这就是那晚 WorkOS 想解决的问题。

他们之前一直在做 agent 权限这件事的基础设施：Vault 做加密存储，Pipes 做 OAuth 连接管理，Relay 让 agent 能访问所有服务但永远看不到真实的 credential。这些是底层砖块。但砖块有了，上面那层权限逻辑还是缺失的。

Airlock 和 Intent-Based Access Control 这才是核心

那晚最让我眼前一亮的，是 WorkOS 正式发布了一个叫 Airlock 的东西，以及他们提出的一个新概念：Intent-Based Access Control，简称 IBAC。

先说背景。我们现在用来控制权限的系统，主要有两种。一种是基于角色的访问控制，RBAC，就是你是管理员你有这些权限，你是普通成员你有那些权限，按角色分配。简单直接，但粒度很粗，主要是按职位定义的，不是按具体任务。另一种是细粒度授权，FGA，可以精确到这个文档、那个 GitHub repo，谁能访问谁不能，权限树很细。但它是静态的。权限在部署的时候就定好了，不能动。

这两种系统都是给"确定性软件"设计的。写代码的时候你知道这段程序会访问哪些资源，所以可以把权限在编译时就锁定。但 agent 根本不是这种东西。你给 agent 一个指令，它会去做一堆你事先无法预测的操作，调用哪些 API、访问哪些数据，这些在你下指令的那一刻根本不知道。所以原来那套"最小权限原则"在 agent 面前是失效的，因为你压根不知道最小权限应该是什么。

Airlock 的思路完全反过来。它不从"角色"出发，也不从"资源"出发，而是从"意图"出发。你告诉 agent 要做什么，Airlock 从这个意图里推导出它应该有什么权限，然后在运行时动态评估每一个操作是否在这个意图范围之内。

具体来说，流程是这样的：你发出一个指令，比如"把最新的财务预测发邮件给 Joe"。这就是意图。Airlock 从这个意图里提取出行动定义，包括要用什么连接器、要做什么操作。然后在 agent 执行的过程中，每一个操作都要经过权限评估，结果有三种：允许，直接通过；拒绝，操作被阻断；或者需要人工审批，交给人来决定。

最厉害的地方是这个评估过程本身是有智能的，不是简单的规则匹配。举个例子，如果 agent 要给一个从来没发过邮件的邮件列表发邮件，系统会先去看你的收件箱历史，确认你是否发过这个列表，如果没有，就触发审批流程。这种判断是需要多步推理的，不是一条 if-else 能覆盖的。所以 Airlock 里面用的是一个小型 AI 来跑这些非确定性策略。

Michael 说了一句很有意思的话：AI agent 的权限问题，最终要靠更多 AI 来解决。我觉得这个说法是对的，不是回避，而是因为这个问题的本质是语义判断，是理解意图，而这正是 AI 擅长的地方。

现场 Demo 让我真正理解了这件事的价值

工程师 Aaron 在台上做了一个完整的 live demo，这是让我觉得最踏实的部分，因为这类活动经常只讲概念，一到真实操作就含糊过去。但那晚 Aaron 真的跑了完整流程，而且故意触发了几个失败场景。

他连接了 Gmail 和 Linear，然后设置了一套规则：agent 可以读邮件，可以发邮件，但只能发给单个收件人或少数几个人；如果要发给从来没发过的邮件列表，需要 IT 管理员审批；不能删邮件，但可以删草稿；邮件正文里不能包含 API key、财务数据、token 消耗、电话号码等敏感信息。

第一个场景正常走，发一封普通邮件通知 Linear 里的 Q3 计划，顺利通过。第二个场景，他让 agent 去读一个包含 token 消耗数据的 Linear issue，然后把摘要发给同事。结果 Airlock 直接拦截，原因是邮件正文包含财务数据，被阻断。第三个场景最精彩，他让 agent 给全体员工发邮件宣布第二天放假。因为他从来没给 staff@works.com 这个邮件列表发过邮件，触发了审批流程，Slack 上立刻弹出了一条审批请求，他在台上当场批准，邮件发出去了，全场鼓掌。

我坐在台下看着这个 demo，脑子里冒出一个想法：这才是 agent 在企业里真正能用的样子。不是无边界的自由，也不是事无巨细的手动确认，而是一套聪明的规则，在你不需要管的地方自动放行，在真正有风险的地方自动拦下来或者叫你来决定。

开源软件个性化 David 的演讲让我想了很久

快闪 demo 环节里，exe.dev 的创始人 David Crawshaw 讲了一个我觉得被整个行业低估的问题。他说，以前我们定制软件的方式是改配置文件，调字体大小，写一些 config。但现在这件事彻底变了，你可以直接让 agent 去修改你每天用的任何开源软件的源代码，然后设置一个夜间 cron job 自动拉最新版本、把你的改动 rebase 上去，保持同步。他说这个能力在六个月前根本不可靠，模型处理 merge conflict 的能力不够，现在可以了。

他说这件事在个人层面是好玩的，在团队层面是很有生产力的，但在产品层面是一个严峻的挑战：如果你的软件是闭源的，用户没法定制，而竞争对手的软件是开源的，用户可以改成完全适合自己工作流的样子，那用户凭什么选你？他举了个例子，他用的薪资软件功能很好，但界面很烂，他愿意付钱给薪资计算能力，但他希望界面部分能自己改。他说，第一个给他 API 访问权限的薪资软件，就是他要切换过去的那个。

我觉得这个观察对很多 SaaS 公司是一个很直接的警告。产品功能的垄断优势在减弱，因为 agent 降低了定制软件的门槛，用户的耐心在减少，他们越来越不愿意忍受"将就用着"。能不能开放接口，能不能让用户在你的能力上自由构建，可能会成为下一个竞争维度。

AI agent 能搞定 40% 到 60% 的工作了吗

圆桌环节是那晚信息密度最高的部分。三个嘉宾：Foundation Capital 的合伙人 Jaya Gupta、Lindy 的 CEO Flo Crivello，以及 Latent Space 播客的主理人 swyx，三个人在好几个问题上都有明显分歧，这让讨论很真实。

关于 AGI 是否已经到来这个问题，Flo 说得很直接，他说我们今年夏天会回头看，觉得这是 AGI 到来的那个时刻。他的论据是模型能力加上工具接入，已经可以支撑一个"AI 员工"真正替代一个远程同事。但 swyx 立刻反驳，说他一直在把一些很复杂的任务丢给最顶级的模型，好几天了还没解决。他举了个例子，他想让 AI 帮他复刻一个设计精良的网站，像素级还原，结果就是不行，差距很明显。他说如果你在处理真正困难的问题，你会发现模型还差得远。

这两个观点我都觉得是对的，只是在说不同层次的事。Flo 说的是"很多中等复杂度的任务，AI 现在完全可以接管"，swyx 说的是"最复杂的那类问题，AI 还做不到"。这两件事不矛盾。Jaya 在中间补了一句很务实的话：可能对大企业来说，模型太聪明了反而是个问题，有些场景需要的不是高智能，而是低成本高可靠的执行，把 Claude 3.7 用在一个简单的客服 ticket 上，是一种浪费。

关于当前最大的瓶颈，Flo 说了一句我很认同的话。他说现在我们有了 John von Neumann，但这个 John von Neumann 在你的办公室里基本上是没用的，因为他没有上下文，没有权限，没有融入你的工作系统。瓶颈不再是智能，而是接入——怎么让这个超级智能的东西真正融入你的工作流，理解你的业务，有权访问需要的数据，有能力执行需要的操作，而且做这些事情是安全的、可控的、可审计的。这正是那晚 Airlock 想解决的问题，也是整个活动围绕的核心议题。

记忆和技能 还没有人真正解决

关于 agent 记忆这个问题，swyx 说了一段我觉得很诚实的话。他说记忆现在还很差，大家都在说 ChatGPT 记忆改善了很多，但他没有明显感受到。他说真正需要的是一种持续学习的能力，agent 犯了错，下次不再犯，而且这件事得是可验证的。他自己的团队现在在试一个方向：让 agent 在接受反馈修改记忆之后，自动生成一个 eval 去验证这个改动是否真的提升了表现，然后自己跑一遍确认。他说这还只是原型，但他觉得这会是未来六个月里一个很重要的模式。

Jaya 聊到的 context graph 也很有意思。她说大多数公司，尤其是大公司，其实没有在认真捕捉组织知识。SF 这边的创业公司可能人人都在用 Granola 记会议，什么都录下来，但这完全不是大多数公司的现实。在很多行业，最有价值的上下文还锁在员工的脑子里，没有办法系统化地提取出来变成 agent 能用的信息。更麻烦的是，这件事涉及很深的政治问题——员工把自己的专有知识外化出去，是要冒风险的，这不只是技术问题，是组织问题。她说她见过不少公司推行技能文件，结果遭到反弹，有员工直接去删。

Flo 分享了一个他们在 Lindy 观察到的现象，我觉得挺有参考价值。他发现，让员工愿意主动创建技能文件的关键，是让这件事对员工自己有好处。他们的设计是：员工创建的技能文件，默认先帮助自己工作，然后自动同步到团队共享库里。激励对齐了，飞轮才能转。

一个 agent 还是多个 agent 这个问题没有标准答案

最后一个话题是关于 AI 团队架构的。到底该用一个通用的超级 agent，还是用一堆专门做某类任务的小 agent？

Flo 说 Lindy 在这个问题上摇摆了很久，从多 agent 转回了单一大 agent，现在又在往里面引入一些子 agent。他的核心判断是：人类组织之所以需要分工，是因为人有时间限制，有记忆限制，必须专业化。但 AI agent 没有这两个限制，所以简单地把人类的组织结构套到 agent 上，是一种思维惰性。agent 需要分工，不是因为和人一样受限，而是因为有时候封装权限、限制 blast radius、提高可复用性，这些工程上的原因。

swyx 则提到了一个观察：现在市面上不同产品对 agent 身份的理解是很不同的。有的产品把 agent 做成一个独立的实体，比如 Claude，要给它专属的 Gmail，以后可能还要给它手机号；有的产品更倾向于让多个专业 agent 各司其职；还有一些产品走的是"个人首席参谋"的路线，像一个了解你所有事情的私人助理。他说这些路线目前都还没有明确的赢家，仍然是野蛮生长的阶段。

关于未来四个月会发生什么，Flo 给了一个很具体的判断：他认为未来几个月里，每个公司当前业务里有 40% 到 60% 的工作，会是"agent 技术上可以完成的"，但最终有多少真的交给 agent 去做，取决于每个公司自己的判断和执行力。

我从这场活动带走的最重要的东西

走出 Regency Ballroom 之后，我脑子里反复在转的不是某个具体产品，而是一个结构性的判断：我们现在面对的最大问题不是 AI 够不够聪明，而是 AI 够不够安全、够不够可控、够不够融入真实的工作系统。

Airlock 和 IBAC 这件事让我觉得最有价值的地方，是它重新定义了权限这个概念。权限不应该是一个静态的名单，不应该是"你能做这个，你不能做那个"，而应该是一个动态的、基于意图的、能在运行时自我调整的系统。这件事本身不只是一个技术方案，它是一种关于 agent 和人类如何共事的哲学：不是全部信任，也不是全部管控，而是在真实使用的过程中，让权限跟着意图走，让监督跟着风险走。

过去一年我一直有一种感觉，大家在把 agent 接进越来越多的系统，但这件事背后有一个巨大的信任赤字还没被认真填上。权限问题被刻意或无意地忽略了，因为解决起来很麻烦，不如先往前冲。但这种忽略迟早会出问题，一次严重的数据泄露或者一次 agent 失控的操作，会让整个行业付出很大的代价。那晚看到 Airlock 的 demo，我有种如释重负的感觉，不是说这个产品已经完美地解决了所有问题，而是说终于有人把这件事当成一个需要认真设计的工程问题来对待了，而不是一个以后再说的事。

那场活动结束后地下室有个派对，据说还有一场秘密国际象棋锦标赛。但我那个晚上一直在想的，是 Flo 说的那句话：我们现在有了 John von Neumann，但他在我们的办公室里是没用的，因为他不知道发生了什么。让他真正有用，是接下来一两年最重要的工程问题。

文章来自于"深思圈"，作者 "深思圈"。