给智能体一个自己的身份：权限、审批与审计

大多数企业的第一个智能体，是借着某个人的账号跑起来的。开发时图快，用的是项目负责人的凭据；上线后没人改，于是系统日志里所有自动操作都记在这个人名下。只要智能体停留在查询和汇总阶段，这件事看起来无伤大雅。等它开始写工单、改状态、触发通知，问题就一次性全部到齐。

出了错，责任算谁的。审计要求列出所有自动执行的动作，日志里却分不出人和机器。有人离职，账号一停，三个自动化任务同时挂掉。这些都不是假想，而是我们在多个项目里实际接手过的现场。

借用账号的三个代价

• 权限必然过大。员工账号的权限是按人的岗位配的，覆盖面远超某个智能体实际需要的范围。一个只负责汇总渠道数据的任务，往往顺带拿到了整个销售模块的写权限。
• 责任无法切分。当日志无法区分"张伟改的"和"张伟名下的机器人改的"，任何一次事故复盘都会退化成扯皮。业务部门因此拒绝让自动化触碰关键流程，这是完全理性的选择。
• 变更传导不了。人的权限随岗位调整，机器的权限应该随任务调整。绑在一起之后，任何一方的变动都会意外影响另一方。

能不能追溯到具体是谁做的，决定了自动化的边界能推到多远。AGENT IDENTITY

身份、权限、审批、审计

把这件事做对并不需要多复杂的设计，但四个部分缺一不可。

独立身份。每个智能体是通讯录里一个真实存在的主体，有名字、有归属部门、有负责人。它在群里发言、在工单里留痕，署的都是自己的名字。这一步看似只是显示层的改动，实际改变的是所有人对它的预期。

最小权限。权限按任务而不是按岗位来配：它能读哪几个知识库、能调哪几个工具、能写哪张表的哪些字段。范围越窄，越容易被批准上线，也越容易在出问题时定位。

敏感动作审批。把动作按影响面分级。查询和汇总可以全自动；对外发送、金额相关、状态不可逆的操作，必须停下来等一个人点确认。审批不是效率的敌人，它是让业务部门愿意放行的那个开关。

全量审计。每一次调用留下完整轨迹：谁触发、读了什么、调了什么工具、改了什么、结果如何。这份记录既是合规材料，也是后续优化的唯一可靠依据。

图 · AUDIT TRAIL

治理不是上线之后再补的东西

常见的顺序是先把效果做出来，等到要过安全评审时再回头补身份和审计。这条路我们走过，代价是几乎所有集成都要重做一遍——因为权限模型一变，工具调用方式、日志结构和错误处理全部跟着变。

更省力的顺序是反过来：在第一个场景就把身份和审计打通，哪怕这个场景本身只是只读的汇总。前期多花的时间不多，但后面每增加一个场景，边际成本都会低很多。这也是我们在政务、养老这类监管密集的行业里，能够比较快扩场景的主要原因。

结语

智能体进入核心业务的门槛，从来不在它能不能把活干完，而在组织能不能对它的每一次行动负责。给它一个自己的身份，划清它的权限，留下它的痕迹——做完这三件事，剩下的才是效率问题。