我用 OpenClaw 加 飞书做 AI 自动化：最后卡死在权限继承
近期在整合OpenClaw与飞书CLI进行企业自动化测试时，一个典型权限问题逐步显现，它揭示了AI Agent进入企业系统后身份体系的根本性挑战。
原本整个流程看似顺畅：Agent基于自然语言自动创建飞书文档、整理内容、生成表格并写入数据，体验接近数字员工。从技术角度，大模型、工具调用、Workflow及API集成均已无障碍。
然而进入实际使用阶段后，问题很快暴露。
Agent创建的飞书文档，其Owner并非当前用户，而是机器人本身。后续尝试转移文档给真实用户时，系统要求重新登录并完成身份确认与权限授权。这意味着，尽管AI已能自动创建资源，但企业系统并不认可Agent天然继承用户身份。
表面看这只是飞书权限校验，实际却暴露了当前AI Agent行业的核心困境：AI Agent进入企业系统后，传统身份体系正在失效。
如今讨论AI Agent时，关注点仍集中在模型能力，如推理、多轮对话、Tool Calling、Workflow编排、RAG、MCP等。但真实企业环境的核心问题并非模型智能程度，而是AI究竟以什么身份运行。
这个问题看似简单，却将直接影响未来企业AI的整体运行架构。
过去二十年，企业软件权限模型极为稳定。IAM、RBAC、LDAP、SSO及各类审批流与权限体系，其默认前提仅包含两类身份：Human Identity與Service Identity。前者对应员工账号，后者对应程序与系统服务。整个企业IT系统均围绕这两类身份构建，人类账号负责业务操作，服务账号负责程序调用。Kubernetes ServiceAccount、数据库账号、云平台RAM用户及GitHub Token，本质上皆属静态服务身份。
但AI Agent出现后，这一模型首次动摇。Agent不完全属于传统Service Account，它不再是执行固定逻辑的程序，而是能自主决策、动态调用工具、持续维护上下文、自动执行Workflow的运行实体，在某种意义上接近自治执行主体。
这导致传统权限体系出现根本性冲突。以OpenClaw与飞书场景为例，机器人创建文档后，文档所有权天然归属于Bot Identity而非Human Identity。随即产生问题：文档后续如何管理？权限如何继承？组织关系如何绑定？员工离职后如何迁移？审计链路如何追踪？知识库归档如何处理？这些在传统自动化系统中并不明显，因为传统程序仅为辅助工具而非行动主体。Agent则不同，它已直接参与企业运行流程。
一旦Agent开始真正参与生产系统，企业必须重新回答一个长期被忽视的问题：AI能否代表用户行动？这个问题极其危险。若Agent被允许继承用户权限，它理论上能够：
- 代表用户创建资源。
- 代表用户审批流程。
- 代表用户调用API。
- 代表用户访问数据库。
- 代表用户执行生产环境操作。
- 代表用户完成跨系统自动化协同。
从效率看，这极为诱人，意味着大量重复性工作可真正自动化。但从企业治理看，这相当于首次允许非人类主体进入核心权限体系。真正的复杂性不在技术，而在组织控制权。企业权限系统本质并非技术组件，而是组织管理体系的一部分。权限核心意义从来不是能否访问API，而是谁对行为负责。
过去系统操作主体是人，责任链路天然清晰：审批者、数据库修改者、发布执行者、文档创建者均可追溯至具体员工。Agent出现后，责任主体开始模糊。若AI Agent自动执行错误操作，责任归属何方？属于模型？属于Prompt编写者？属于Agent开发团队？还是被代理的用户？这将成为未来企业AI最大的治理难题之一。
许多企业推进AI自动化时，第一反应是给Agent分配Service Account，希望通过固定权限解决问题。但很快会发现传统Service Account模型无法适应Agent系统，原因在于Service Account核心前提是行为可预测，而Agent核心特点恰是行为动态化。传统程序调用API时行为路径固定，Agent则根据上下文动态决策：今天可能仅读取日志，明天就批量修改文档，后天自动触发发布流程。传统RBAC的角色绑定权限模型在此动态行为面前迅速失效，企业陷入尴尬状态：权限过小则Agent无法工作，权限过大则安全风险失控。
这也解释了为何许多AI Agent Demo看似惊艳，进入企业生产环境后却卡死在权限系统。Demo世界默认无组织边界，而企业世界最重要的恰是边界。
事实上，许多企业已逐渐意识到，AI自动化的真正难点并非模型调用工具，而是如何治理模型调用工具。尤其在MCP、Agent Workflow、多Agent协同兴起后，系统复杂度将进一步放大。未来企业内部可能同时运行数十甚至上百个Agent，包括运维、安全、DBA、客服、ITSM、研发等各类Agent。这些Agent不断访问系统、调用API、生成资源、修改状态，一旦缺乏统一身份治理体系，企业系统将迅速失控。
真正危险的并非AI说错话，而是AI做错事。许多人将Prompt Injection理解为模型安全问题，本质上它却是权限问题。攻击者真正意图不是利用模型回答本身，而是模型背后的高权限工具链路，例如诱导Agent调用数据库、读取敏感信息、触发内部API、执行危险Workflow。这些问题一旦进入生产环境，风险等级远超传统Web漏洞，因为过去攻击者需突破系统边界，而未来许多Agent本身就拥有合法权限。
这意味着未来企业权限体系必将发生重大变化。过去权限系统核心是Identity-Based Access Control，未来将转向Runtime-Based Governance。系统不再仅判断你是谁，而是持续判断：
- 你为何执行此操作。
- 当前上下文是否合理。
- 当前风险等级是否允许。
- 此行为是否符合历史模式。
- 当前Workflow是否合法。
- 是否需要二次确认。
- 是否应触发审计。
这标志着权限系统正在Runtime化。未来企业真正重要的已不仅是IAM，而是Agent Runtime Governance。
这将进一步推动DevOps、安全治理、ITSM与AI系统融合。过去DevOps更多关注CI/CD与自动化交付，未来很可能需要承担Agent Runtime管理能力，包括：
- Agent身份治理。
- Context隔离。
- Tool权限控制。
- Runtime审计。
- Agent Trace。
- Workflow风险控制。
- Token成本治理。
- 多Agent协同调度。
从产业演进角度看，这预示着未来企业一定会出现新的基础设施层：AI Runtime Control Plane。随着Agent数量增长，企业最终需要统一控制层来管理整个Agent运行生态。
许多人仍认为AI Agent核心竞争力是模型能力，但未来几年行业将逐渐意识到：真正决定AI能否进入企业核心系统的不是模型，而是治理。模型仅是入口，真正困难的是如何让AI安全地成为企业组织的一部分。
综上所述，AI Agent能否安全融入企业核心系统，最终取决于对身份、权限与运行时行为的全新治理架构，而非模型本身的强弱。