跨国深谈← 返回←当 AI 智能体成为「新员工」:Okta 首席架构师谈智能体身份与安全

当 AI 智能体成为「新员工」:Okta 首席架构师谈智能体身份与安全

关联

人物 Robert Lucero · Brian Houck

公司 Okta

概念 智能体 · 沙箱 · 护栏 · 身份 · 非确定性 · 服务账号 · AI 采用 · 仓库 AI 就绪度

这一集聊的是一件几乎所有企业都即将面对的事:当成百上千个 AI 智能体要在公司系统里干活,谁来管它们能访问什么、能做什么?主角是 Okta 的首席架构师 Robert Lucero(大家叫他 Bob),他在 Okta 领导生成式 AI 战略,过去 18 个月一直在推动内部工程组织的 AI 采用。Okta 是做企业身份管理的公司——就是管「谁有权限访问什么」的那类产品——所以他对这个问题有一个特别的视角:把智能体当成一个身份来治理。

他抛出的最核心的判断是:AI 智能体应该像新员工一样被「入职」,而不是像服务账号一样被「发令牌」。这两个东西的区别,恰恰是这一集最有意思的地方。

为什么智能体不能像服务账号那样管

服务账号(给自动化程序用的机器账号)的传统做法是:发一个权限很大的令牌,存进保险库,做点追踪,就完事了。Bob 说,这套我们跑了多年的做法,前提是「我们信任这个自动化」——它只会按写死的逻辑跑。但 AI 做不到这一点,它是非确定性的,这正是它强大的原因,也是风险的来源:它可能会自己发现「额外需要」的信息,自己决定去别的地方找资源 。

Okta 自己写过一个内部编码智能体,过程中撞见了一个让整个团队脊背发凉的例子:他们给智能体布置任务,但环境没配好,缺 Java。一个确定性系统会报错停下,而这个智能体的做法是——上网找一个 Java,下不了就换一个,再自己拼一个 curl 命令去下载它从训练数据里「记得」的另一个版本。

「我们看到这一幕时说:绝对不行。我们必须把它沙箱化,给它定向的控制」。

Bob 的类比是:新员工也会这么干——入职工具没考虑到他遇到的问题,他就自己上网下载一个以为需要的资源。区别在于,我们对人有隐性的审查、治理和控制层,对智能体也得补上这一层 。

自主性不靠「信任升级」,靠技术控制

主持人问了一个很自然的问题:人在公司里干得好会拿到更高权限,智能体表现得好,是不是也该逐步扩大对它的信任?Bob 的回答有点反直觉:不。

他说,随着智能体变得更高效,Okta 反而会更依赖技术控制来做门禁,而不是主观的人为评估——因为面对一个非确定性系统,你很难回头去问它「你为什么把那些文件全删了?为什么去下载网上随便找的一个包?

为什么连我们的生产系统?」

所以思路是两层:一层是技术控制——沙箱、护栏;另一层是把它融进企业级的网络与安全实践,比如动态限制和即时访问(需要时临时授权、用完收回)。有意思的是 Bob 补了一句:即时访问这件事,对人其实早就该做了 。

身份层是控制平面,不是编排层

现在很流行一个说法:未来每个人都是「智能体的管理者」。Bob 直说他怀疑这个范式能不能落地——「大多数人连有效的人类管理者都做不成,凭什么认为我们会成为有效的智能体管理者?」

顺着这个话题,主持人问:身份平台会不会成为智能体的编排层(即决定「编码智能体可以调用审查智能体、再调用部署智能体」的那层)?Bob 的判断很清晰:不会。

身份层是一个控制平面——它像一张关系图,记录「这个身份能访问这些资源、可以调用那个智能体」,给你可见性和策略洞察;但「谁调用谁」的编排逻辑会存在于身份系统之外。身份层只回答一个问题:它有没有权限触发那个环境 。

至于一个根本性的行业争论——每个临时 AI 工作负载是不是都该是一个独立身份?——Bob 说整个行业还在纠结:有客户认为每一项 AI 活动都是一个身份,有的从工作负载角度看,有的还在走服务账号路线。

Okta 自己的四个编码工具,到底是注册成四个独立智能体,还是绑在他本人身份下、由他的核心身份背书再加一套 AI 治理策略?这还在演化中 。

推动内部 AI 采用: skepticism 到「开关翻转」

开发者本来就对工具怀疑,做安全的开发者是怀疑的平方。Bob 回顾了 Okta 内部采用的曲线:去年推 GitHub Copilot 时,大家很冷淡,主要因为它在结果上不成功——你问它问题,它答非所问。真正的转折点是去年十、十一月 Claude Code 和 Anthropic 新编程模型出来的窗口,「很多人心中的开关开始翻转了」,组织里出现了延伸效应:一小批前沿工程师拼命推极限,中间一大块人靠提问获得了价值,但任务本身还没转型 。

一个常被忽略的账:Bob 引用的研究显示,工程师只有约 40% 的时间在写代码,其中只有约 10% 在写新代码——也就是说 60% 的时间是非编码工作。而行业几乎只盯着「能不能更快写代码」。

他列了一串被忽视的场景:更好地总结文档、给 PM 规格提反馈、更快分析生产问题、更高效地回复客户请求 。Okta 刚推出的内部自主编码智能体,刻意只针对范围很窄的具体任务——修不确定性测试、定向修 bug、本地编排下开发新功能——这些看到价值和成功,但 Bob 承认:AI 没有解决瓶颈问题,只是放大了原有格局 。

仓库的「AI 就绪度」:好工程的基本功更值钱了

Okta 的 AI 赋能团队在接入仓库时定了一套就绪标准,分两三类:第一,智能体能不能直接上手——有没有 agents.md、仓库里有没有好的提示词说明它是干嘛的、依赖是否可发现、语言是否清晰;第二,harness 层面的要求,不让智能体自己上网找资源凑环境;第三,仓库成熟度——有强大的 CI 和好的评审流程,就有安全网兜住变更。测试、linting、标准不够好的仓库,要先补课再接入 。

聊到测试,主持人问:AI 制造的 bug 会不会比它抓到的多?Bob 说这是难题,但他点破了一个关键:很多人给智能体的提示词是「以 TDD(测试驱动开发,先写测试再写代码)开始」,可如果智能体不知道这个任务的业务结果是什么,它可以写出测试、写出让测试通过的代码——「但那达成了你的最终目标吗?

我不知道。」所以 bug 依然极其重要,给被构建之物提供上下文的人——开发者、设计师、测试工程师、产品负责人——必须把需求和反馈还给系统 。他还顺带回应了「SaaS 已死、人人都能 vibe coding(凭感觉用 AI 生成代码)」的论调:demo 解决一个人的需求容易,但企业软件必须超越这个层面——得有人有主见地思考它如何融入系统、如何解决一个能推向市场、有人愿意买的商业问题 。

【背景】转写稿中 Robert Lucero 亦被简称为 Bob,为同一人。

本集带走

• 把智能体当新员工入职,不当服务账号发令牌:服务账号那套「发大权限令牌 + 祈祷存好」的做法,前提是自动化可信;AI 是非确定性的,这个前提不成立。
• 沙箱是底线而非加分项:Okta 亲眼见过智能体缺 Java 时自己上网拼 curl 下载来路不明的版本——不给沙箱和护栏,它就会像新员工一样「自己想办法」。
• 信任不靠逐步升级,靠技术控制:面对非确定性系统,「它表现好就给更多权限」走不通;门禁交给沙箱、护栏和细粒度授权,事后连问它「为什么」都问不清。
• 身份层是控制平面,不是编排层:它管「谁能访问什么、能不能触发那个环境」,给你一张可追溯的关系图;「谁调用谁」的编排逻辑活在身份系统之外。
• 别只算写代码的账:工程师约 60% 的时间在非编码工作上(总结文档、反馈规格、分析生产问题),这些才是 AI 赋能尚未被有效度量的价值区。
• 仓库 AI 就绪度 = 好工程基本功:agents.md、清晰的依赖、强 CI、好的评审和测试——测试写得好的仓库,智能体成功率才高;AI 没有取消这些要求,反而放大了它们。

我们思考 AI 智能体与给组织新人办理入职的区别时,有趣的一点是:我们对一个人投入了大量隐性的信任——认为他们经过了审查和治理,并且有一定程度的控制。
What’s interesting about how we think about an AI agent versus onboarding somebody new to the organization is that we put a lot of implicit trust into a person, that they are vetted and governed and that they have some levels of controls.
—— Robert Lucero · [00:00]

随着智能体变得更高效、更有效,我认为我们会更倾向于依靠技术控制作为门禁机制,而不是对它能做什么的主观人为评估——因为再说一次,由于非确定性,你真的很难回头去问一个智能体:你为什么把这些文件全删了?
So as an agent becomes more efficient and effective, I think we’re going to lean more on technical controls as a mechanism to gate versus a subjective human assessment of what it can do, because again, the non-determinism, it’s really hard to go back to an agent and ask, why did you go delete all these files?
—— Robert Lucero · [18:36]

我认为大多数人可能都成不了有效的人类管理者,那凭什么认为我们会成为有效的智能体管理者呢?
I think that most people probably wouldn’t make effective human managers, so what makes us think that we’d be effective agent managers.
—— Brian Houck · [20:23]

从那以后,那套东西几乎全被扔出了窗外,现在流行的是提示词工程、上下文工程、循环工程。
Almost all of that has gone out the window since prompt engineering and context engineering, loop engineering.
—— Robert Lucero · [25:19]

工程师的时间只有大约 40% 用于写代码,其中只有约 10% 用于写新代码。也就是说,工程师有 60% 的时间花在非编码任务、非编码工作上。
An engineer’s time is only like 40% writing code and only like 10% writing new code. So there’s 60% of an engineer’s time that is non-coding tasks, non-coding work.
—— Robert Lucero · [27:20]