企业 Agent 权限映射：角色不是简单复制组织架构
企业 Agent 权限映射：角色不是简单复制组织架构
一、组织架构不等于权限模型
企业 Agent 落地时，权限是第一道门槛。很多系统直接把组织架构同步进来，部门、岗位、上级关系都有了，就以为权限解决了。实际不行。Agent 执行任务时需要访问文档、调用系统、提交审批、读取客户数据，权限粒度比组织架构更复杂。
角色不是简单复制组织架构。权限要围绕任务和数据设计。
某制造业客户部署 Agent 后，销售部门所有人都能"读取客户数据"。但合同细节只有客户经理能看，报价只有总监能批。组织架构说"同部门"，权限模型说"不同能力"。直接复制组织架构，Agent 会越权访问合同。
二、先拆资源和动作
flowchart TD A[用户角色] --> B[资源] A --> C[动作] B --> D[文档] B --> E[客户] B --> F[工单] C --> G[读取] C --> H[修改] C --> I[提交]Agent 权限至少要包含资源、动作、范围和条件。比如能读取销售文档，不代表能读取客户合同；能生成回复，不代表能自动发送。
permission_rule: resource: customer_contract action: read scope: owned_accounts condition: approval_required_for_export权限规则越具体，越能控制风险。
对比两种模型：组织架构映射说"销售部可以读客户"，资源动作映射说"销售部可以读自己负责的客户，不能导出"。前者一句话就给全部门开了大门，后者按资源、动作、范围三层收窄。粒度差一个数量级，风险差一个数量级。
三、Agent 要继承用户权限
Agent 不应该拥有超出用户的默认权限。用户不能访问的文档，Agent 也不能读；用户不能执行的操作，Agent 也不能代劳。
agent_permission: inherit_user_permissions: true allow_service_permissions: limited require_audit: true只有少数系统级任务可以使用服务权限，而且要审计。
四、敏感动作要二次确认
发送邮件、修改 CRM、创建合同、删除数据、发起付款，这些动作即使用户有权限，也应该在 Agent 执行前确认。
high_risk_actions: - send_external_email - update_customer_record - delete_data - submit_payment确认界面要显示动作、数据来源、影响范围和可回滚性。不能只让用户点一个"确认"。
最后，权限映射要持续同步。员工转岗、离职、项目权限变化后，Agent 的能力也要同步变化。
权限系统还要记录"为什么允许"。当 Agent 读取某份文档或提交某个动作时，审计日志里应该能看到依据：用户角色、资源范围、审批状态和策略版本。企业客户排查权限问题时，不会接受一句"系统判断可以"。
permission_audit: user_id: required agent_id: required policy_version: required decision_reason: required还要处理临时授权。企业常见场景是项目支援、客户交接、临时审批。临时权限必须有过期时间，到期自动撤销，否则 Agent 会长期保留过宽能力。
对于跨系统权限，不能只同步一次。CRM、文档库、工单系统、数据仓库的权限变化频率不同，Agent 网关需要定期校验，并在权限不确定时选择拒绝。
最后，权限错误的用户提示要清楚。告诉用户缺少哪个资源的哪类权限，以及应该找谁申请，比一句"无权限"更能推动任务完成。
实践中的关键洞察
从实际项目经验来看，上述方案的落地效果高度依赖于两个前提条件。第一，团队需要对核心指标达成共识，而不是各说各话。第二，监控和反馈机制必须自动化，手工检查在团队规模扩大后会迅速失效。创业团队最宝贵的资源是创始人的注意力，任何需要人工盯盘的流程本质上都在消耗这个有限资源。
回到根本问题：技术决策最终服务于商业目标。在资源受限的创业阶段，每一次架构选择、每一项工具选型、每一个流程设计，都应该可以追溯到它对用户价值、团队效率或公司生存概率的影响。那些无法回答"这个决定如何帮助我们活得更久或跑得更快"的技术投入，都值得重新审视优先级。
五、总结
企业 Agent 权限映射要围绕资源、动作、范围和条件设计，并默认继承用户权限。
角色不是简单复制组织架构。Agent 能做什么，必须比人类操作更清楚。
核心要点：权限拆成资源、动作、范围、条件四层。Agent 默认继承用户权限，不做加法。敏感动作必须二次确认，不能一键执行。权限变更要实时同步，过期自动回收。