我用 OpenClaw + 飞书做 AI 自动化,最后卡死在权限继承

最近在测试 OpenClaw 结合飞书 CLI 做企业自动化时，我遇到了一个非常典型的问题。

原本整个流程看起来已经非常顺畅。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，包括运维 Agent、安全 Agent、DBA Agent、客服 Agent、ITSM Agent、研发 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 安全地成为企业组织的一部分。