当实习生在入职第一天部署 Agent

实习生周一报到。周二下午，她已经接好了自己的第一个 Agent。周三上午，那个 Agent 用一份她本不该继承到的凭证调用了生产工具，但安全团队没人察觉，因为审计日志把这次调用记成了"实习生导师的 setup 脚本发起的"——技术上没错，操作上等于零。

这不是实习生不靠谱的故事，也不是导师粗心的故事。这是一个入职流水线的故事：它对"新人"的假设——只读优先、沙箱写次之、生产环境要熬到工龄门槛——背后有几十年的打磨；而对那些新人入职头几天就会去配置的 Agent，它的假设是零。给人用的 IAM 模型，已经不再是给"实际打到你系统上的东西"用的 IAM 模型，而大多数安全团队还没意识到这一点。

那条为"人"建的流水线

走一遍像样工程团队给新人第一天的清单。一台统一镜像的笔记本。一个仓库的提交权限，按团队划清边界。生产日志的只读访问，得过 VPN 加硬件密钥。一个 Slack 账号、邮箱、日历，再加一行目录条目，把工号映射到一个经过校准的角色权限集。这个角色本身是几个季度前在安全、工程领导和 IT 之间反复谈判出来的。里面每一项授权都有自己的故事。

这条流水线是一场漫长且代价高昂的"爆炸半径"讨论的产物。新人不能直推 main，不是因为他作为人不被信任；而是因为一个没经验的操作者打到生产环境上，错误的代价是不对称的。"先读、后沙箱写、最后熬过试用期才碰生产"的工龄梯度，是一条风险摊销曲线。它之所以存在，是因为多年前某个人看着新员工不小心 drop 掉了一张表，决定这类事故必须从设计层避开，而不是从事后道歉中收场。

现在再看，同一个实习生 2026 年的第一项任务是什么。她被要求用团队的 Agent 框架交付一个小功能。为此她需要：一个工具注册表条目，好让她的 Agent 被发现；一份合进团队 prompt monorepo 的 system-prompt PR；一个 eval set 的席位，让她 Agent 的输出能跑过团队回归套件；一份调用 staging API 的沙箱凭证；一个把推理费用归口到预算负责人头上的计费桶。而上面这些交接动作，每一个都躺在一份当初只为高级工程师写的 runbook 里——因为直到上个季度，做 Agent 工作的只有高级工程师。

实习生做了任何一个理性的人都会做的事。她在 Confluence 上翻到一位高级工程师的 setup 脚本，复制、运行，她的 Agent 就跑起来了。脚本只会照它知道的方式发凭证。它不知道她是实习生。它不知道它发出去的 staging 凭证，顺带还给了一个紧贴生产的队列读权限——因为六个月前某个人偷了懒。它也不知道，它创建的工具注册表条目按默认规则就是已批准状态——因为当初设计这道评审闸的时候，能创建条目的"人类"都是 tech lead。

为什么 Agent 的权限分配是另一个面

人类 IAM 模型默认：人就是行动的最小单元。给人授权、记录人做了什么、人走了就吊销。整个模型建立在一个稳定身份之上——一个你可以谈判、可以审计、最终也可以炒掉的身份。

Agent 把上面每一条都打破了。Agent 是人配置的，但它自己独立行动。它的权限不是配置它那个人的权限——而是另一份能力包，常常是配置者从别人那儿抄过来、没把整张清单看完就用上的。Agent 的动作有日志，可日志里写的是"Agent 干了"，不是"塑造了 prompt 的人"，不是"添加了工具的工程师"，也不是"批准了注册表条目的评审者"。当 Agent 闯了祸，找不到唯一可以追责的喉咙。

这正是传统安全评审没覆盖到的面。安全评审管人类 IAM。AI 团队管工具注册表。平台团队管凭证保险库。财务团队管计费。而它们的交集——那个让一个初级工程师把若干各自看着合规的部件，拼成一个有杀伤力的能力包的地方——没有归属。它是各部门之间的"缝"，而事故就长在缝里。

换个角度想：Agent 不是工程师"在用"的一件工具，而是工程师"招进来"的一个员工。而你的公司目前对你的实习生在第三天招进来的"员工"，连一套 HR 流程都没有。

按工龄分级的能力包

要落地的第一项规矩，直接借自人类入职手册。新人拿到的是先读后写、按角色和工龄校准的权限集。新 Agent——准确说，特定工龄的人能够配置出的 Agent——也需要类似的梯度。

具体来说，就是一份按角色配置的 Agent 能力包。实习生只能配置这样的 Agent：调用只读工具、查文档、起草 PR 等待人类评审、跑在完全沙箱化的 staging 环境里。中级工程师可以多配置一些 Agent：能写开发数据库、能用可追踪的凭证调内部服务、能不经双人评审就提交到 eval set。高级工程师可以配置能碰到准生产接口的 Agent，但前提是注册表条目里有具名的批准人。Staff 及以上才可以配置直接打到生产的 Agent，并且必须附带书面的爆炸半径分析和 kill 条件。

要问的问题不是"这个人能做什么"，而是"这个人配置出的 Agent 能做什么"。这是两个不同的问题，需要两份不同的答案。初级工程师是完全被信任去写代码的——前提是这份代码会经过人类评审，再上生产；但同一位初级工程师不应该被默认信任去配置一个"本身就是生产触点"的 Agent，因为代码评审的那道闸，目前在 prompt 和工具授权这一侧没有对应物。

默认姿态必须是 deny。工具注册表里每一条增量授权，都需要一个能用平白英语（或中文）说出爆炸半径的批准人。如果批准人都说不清这个工具被误用时会坏掉什么，那它就还不该进注册表。这是当年催生现代 code review 文化的同一条纪律——必须有人能讲清一项变更为什么是安全的——只是把它套用到了一类新的产物上。

一条能区分"作者"与"调用者"的审计链

要落地的第二项规矩是审计追踪里的"出处"。当实习生的 Agent 调起一个生产工具，那条日志至少要记下四件事：被借用权限的人类主体、prompt 作者、工具授权人、Agent 运行时。今天大多数可观测性栈最多记一两项，通常是运行时再加一个委托身份。其余的信息都丢在那条缝里了。

没有这"四方"记录，事故响应就是凭直觉考古。有了它，"这次动作谁负责"这个问题就有了真正的答案——而且不同部分的责任可以归到不同的人头上。Prompt 的作者可能是实习生。工具的授权人可能是那位被复制了 setup 脚本的高级工程师。批准生产访问的主体，可能是三周前没仔细看就签字通过那条注册表条目的某位 tech lead。每个人和这次失败的关系是不一样的，每个人也需要从中学到不一样的东西。

2026 年的数字已经把这件事讲得很大声。在高度自动化的组织里，非人类身份的数量已经是人类身份的 40 倍到 500 倍。多数组织承认，这些身份并没有被一致地纳入特权访问策略。多数安全事件已经牵涉到机器身份。审计追踪这件事不是理论问题——它就是一支团队今早正在做的真实工作：搞清楚一份"以为是沙箱化"的凭证为什么出现在了生产日志里。

架构上的领悟是：Agent 的身份必须是 IAM 系统里的一等主体，独立于配置它的人，也独立于它当前借用权限的那个人。把 Agent 当成人类身份外面的一层薄壳，正是当初造成审计链坍塌的根因。Agent 要在目录里有自己的一行，有自己经过密码学认证的凭证，有针对一份能力包谈判出来的权限集，也有不自动从创建者那里继承的生命周期。

新员工 AI 入职模块长什么样

在第一次 commit 之前需要落地的那一块，是一份关于 Agent 权限模型的入职模块，规格上要和安全培训里讲数据分级的那一块对等。今天大多数入职培训把 AI 当成公司在卖或在用的产品；几乎没有一份培训把它当成"新员工本人会在第一周内亲手配置"的能力。

这份模块至少要覆盖：工具注册表是什么，添加一条记录意味着什么；prompt 和能力的区别在哪里，为什么各自需要不同的评审；默认 deny 在实操中长什么样，如何申请增量授权；计费模型是什么，发布之前怎么估算花费；Agent 运行时审计链会显示什么，怎么读；Agent 失控时的 kill 条件是什么。上面这些没有一项比每个新人本就要坐着听完的数据处理培训更复杂。它只是新，而且还没有任何团队拿到过把它写出来的预算。

这里的政治面是真的。在第一个 Agent 出厂之前再加一道闸，看起来就是在拖团队的节奏。能反驳这一点的，是事故的缓慢累积——那份本不该泄漏的凭证、那个本不该被调起来的生产工具、那张本不该长到这个量级的推理账单，每一件单独看都说得过去，合起来却指向组织架构里少了一层。这份入职模块就是那个便宜、可复用的干预手段，让"少了一层"在每位新人入职第一天就被显式看见，而不是等到他们用代价昂贵的方式自己学到。

新员工的生产力开始来自他们配置的 Agent，而不是他们写的代码——从那一天起，给"人"的 IAM 模型就不再够用。提早意识到这件事的组织，会在第一条入职流水线旁边再修第二条，一条给人，一条给那个人将要创建的 Agent，对它们投以相当的认真。意识得晚的组织，会花掉一个季度回溯实习生在入职第一周里到底让自己的 Agent 做了什么，然后照样修出这条流水线——只不过是在事故之后。