FDE怎么设计Agent权限体系？AI能看什么、改什么、触发什么，必须提前说清楚

企业把AI Agent接进业务系统以后，很快会遇到一个很现实的问题：这个Agent到底算谁？

算一个员工吗？

算一个系统账号吗？

算某个部门的助手吗？

还是算一个可以到处调用接口的自动化程序？

这个问题听起来像技术细节，实际关系很大。因为Agent一旦能读取数据、修改字段、发起审批、调用接口，它就不再只是一个聊天窗口。

它已经进入企业业务执行链路了。

上一篇我们讲了FDE怎么把AI Agent放进审批流里。审批流解决的是一个问题：AI做事之前，哪些动作要进流程，哪些动作要人确认。

但审批流还不够。

在审批之前，还有一层更基础的东西要先设计好：权限。

AI能看什么？能改什么？能触发什么？能不能跨部门取数？能不能读取敏感字段？能不能替用户调用接口？如果调用失败，谁知道？如果改错数据，谁负责？

这些问题如果不提前说清楚，企业后面一定会反复补课。

FDE前沿部署工程师做Agent权限体系，真正要解决的是把AI的每一个业务动作都放进可控边界里，不能只停留在“给不给权限”这一步。

图1：Agent权限不能只做一个开关

一、Agent权限不能直接等同于员工权限

很多企业一开始会有一个很自然的想法：Agent是员工用的，那就继承员工权限。

销售使用Agent，就让Agent拥有这个销售的权限。

采购使用Agent，就让Agent拥有采购员的权限。

财务使用Agent，就让Agent拥有财务人员的权限。

这个思路有一定道理，但不能直接照搬。

原因很简单，人和Agent的操作方式不一样。

人看一条数据，通常是一次一次点开看。Agent可能一次读取几十条、几百条相关记录。

人修改一个字段，通常知道自己在改哪一条。Agent可能根据上下文批量生成、批量更新、批量触发。

人发起审批，会对自己提交的内容有明确责任。Agent生成内容以后，如果没有确认环节，责任边界很容易模糊。

所以，FDE不能只问：这个用户有没有权限？

还要继续问：Agent用这个权限做什么？读取多少？写入哪里？触发什么流程？是否需要用户确认？是否需要单独留痕？

举个很常见的场景。

销售经理让Agent分析本月重点客户进展。销售经理本人可以查看本区域客户数据，这没问题。但Agent在分析时，能不能读取客户合同金额？能不能读取回款异常？能不能读取利润率？能不能把分析结果自动写进客户跟进记录？

这几件事不是同一个权限。

读取客户列表是一回事，读取合同金额是另一回事，读取利润率又是更敏感的一回事。把分析结果写回系统，更是一个数据变更动作。

如果全部用“销售经理有权限，所以Agent也有权限”来处理，权限会变得很粗。

企业AI落地最怕的就是这种粗糙。

看起来省事，后面出了问题，很难追。

二、FDE要先把Agent动作分成五类

设计Agent权限之前，FDE要先把Agent会做的动作拆清楚。

不要一上来就讨论模型、提示词、接口参数。先把动作分层。

第一类是读取。

Agent要看哪些业务对象，客户、合同、订单、设备、工单、预算、人员、库存、项目，分别能看到哪些范围。

第二类是生成。

Agent可以生成申请单、审批意见、跟进总结、风险提示、字段建议、报表解读。这类动作通常不直接改变系统数据，但会影响用户判断。

第三类是修改。

Agent能不能改客户状态、更新合同字段、补充工单处理结果、调整项目进度、修改预算占用。只要涉及写回，就要提高控制等级。

第四类是触发。

Agent能不能发起审批、派发任务、发送通知、创建工单、提交接口调用。触发动作经常会让业务链路继续往下走，不能当成普通文本生成。

第五类是调用。

Agent能不能调用ERP、OA、CRM、MES、财务系统、数据仓库和第三方服务。接口调用背后可能是读数据，也可能是改数据，还可能触发外部系统动作。

这五类动作要分开看。

因为它们的风险等级不同。

让Agent读取公开产品资料，风险很低。

让Agent读取客户合同和回款数据，风险就高很多。

让Agent修改合同状态，风险继续上升。

让Agent自动发起付款审批，权限设计就必须非常谨慎。

图2：Agent动作权限矩阵

三、读权限要看数据范围，不能只看表名

很多系统做权限，喜欢按表控制。

客户表能不能看。

合同表能不能看。

订单表能不能看。

这种方式只能解决很粗的问题。到了Agent这里，还要继续往下拆。

Agent读取数据，至少要看三件事。

第一，能读哪些对象。

比如客户、合同、回款、工单、设备、项目、供应商。

第二，能读哪些记录。

销售只能读自己的客户，区域经理能读本区域客户，总部能读全部客户。采购只能读自己负责的供应商，采购负责人能读更多范围。

第三，能读哪些字段。

同一条合同记录里，合同名称、客户名称、签约时间可以开放给更多角色，但合同金额、付款账号、利润率、折扣底线、法务意见，可能要做字段级控制。

FDE在设计Agent读权限时，不能只说“允许读取合同表”。

更稳的表达应该是：允许当前用户身份下的Agent读取其业务范围内合同记录，可读取合同名称、客户、状态、签约时间等字段；涉及金额、付款、利润率等字段时，根据角色、流程状态或脱敏规则控制。

这句话看起来啰嗦，但企业权限就该啰嗦一点。

权限写得越粗，后面越难管。

如果企业后续要做客户经营分析、合同风险分析、供应商绩效分析、设备异常分析，这些场景都会用到大量数据。FDE提前把数据范围和字段边界拆清楚，后面的Agent能力才不会越做越虚。

四、写权限要看字段，不要让Agent随便改业务状态

读权限解决的是“AI能看什么”。

写权限解决的是“AI能改什么”。

这一步更敏感。

很多企业对AI写回系统很兴奋。比如让Agent自动更新客户跟进记录，自动补充工单处理结论，自动生成项目周报，自动修改任务状态。

这些场景确实有价值。

但FDE要先把写权限拆细。

哪些字段可以让Agent直接写？

哪些字段只能生成草稿，等人确认后写？

哪些字段只能由系统规则写？

哪些字段永远不能由Agent写？

比如客户跟进记录，可以允许Agent根据会议纪要生成草稿，经销售确认后写入系统。

客户阶段从“意向”改成“成交”，就不能随便让Agent自动改。这个状态背后可能关联合同、回款、业绩和预测。

再比如设备维修工单，Agent可以根据维修记录生成处理摘要，也可以提醒备件消耗异常。但工单关闭、维修结果确认、责任判定，这些动作最好保留人工确认或流程审批。

字段级写权限非常关键。

因为企业系统里很多风险都出在关键字段变化上，不一定是新增了一条记录。

付款状态被改了。

合同状态被改了。

客户等级被改了。

库存数量被改了。

权限等级被改了。

这些字段一旦变化，后面可能连着财务、交付、库存、审批和考核。

FDE要让Agent写回能力先从低风险字段开始，比如摘要、备注、建议、草稿、标签、风险提示。涉及金额、状态、权限、审批结果、外部系统写回的字段，要进入更严格的确认和日志。

Agent可以帮人少填很多内容，但不能把关键业务状态悄悄改掉。

五、触发权限要和审批流绑定

Agent最容易出问题的地方，不一定是写字段。

很多时候是触发动作。

比如自动发起采购申请，自动派发工单，自动发送客户通知，自动提交数据权限申请，自动创建项目任务，自动调用接口同步数据。

这些动作一旦触发，业务链路就往下走了。

所以触发权限不能只看按钮能不能点。

FDE要设计三层控制。

第一层，能不能触发。

这个Agent是否允许发起采购申请、创建工单、发送通知、调用接口。

第二层，触发前要不要确认。

低风险通知可以一键确认，高风险审批必须让用户看到内容、范围、影响对象和下一步流程。

第三层，触发后要不要进入审批。

比如金额超过阈值，进入更高级审批；涉及敏感数据，进入数据负责人审批；涉及外部系统写回，进入技术或业务管理员确认。

这就是第3篇讲到的审批流。

第4篇往前补的是：Agent有没有资格触发这件事。

审批流管的是动作发生以后怎么流转，权限体系管的是动作发生之前能不能发生。

两者要连在一起。

如果Agent能随便触发流程，审批流会被大量无效申请淹没。

如果Agent不能触发任何流程，AI就只能停留在建议层，很难进入业务执行。

FDE要做的是把触发动作分级。

提醒类、草稿类、待确认类、审批类、自动执行类，每一类对应不同权限、确认和留痕要求。

六、接口权限要单独管，不能只看页面权限

企业Agent落地以后，接口权限会越来越重要。

因为Agent真正进入业务现场，往往不是只在页面里帮人写字。它要读ERP里的订单，查CRM里的客户，调OA里的流程，取MES里的设备数据，再把结果写回某个业务系统。

这里有一个容易被忽略的问题：页面权限和接口权限不是一回事。

用户在页面上能看到一条数据，不代表Agent就可以用接口批量读取相关数据。

用户能在页面上手动提交一条申请，也不代表Agent可以绕过页面校验直接调用提交接口。

FDE在设计接口权限时，要把接口当成独立资源管理。

哪些接口允许Agent调用？

调用时使用谁的身份？

参数范围怎么限制？

调用频率怎么限制？

返回字段怎么脱敏？

失败以后怎么重试？

调用记录在哪里看？

如果接口会改数据，是否需要审批或确认？

这些都要提前设计。

否则项目一开始可能跑得很快，后面安全和运维会非常紧张。尤其是当Agent可以连续调用多个接口时，一次错误判断可能会变成一串错误动作。

在织信这类平台里，FDE可以把业务对象、接口调用、审批流程和操作日志放在同一个业务链路里看。Agent不该拿一个万能接口密钥到处跑，它应该在平台配置好的业务边界里执行。

这样更符合企业现场的工作方式。

七、日志不是最后补的，是权限体系的一部分

很多项目会把日志当成最后补的功能。

先让Agent跑起来，再考虑记录。

这个顺序不太稳。

因为Agent做的事情越多，越需要解释它做过什么。

它读了哪些数据？

生成了哪些内容？

用户改了哪些地方？

它提交了什么审批？

它调用了哪个接口？

接口返回了什么结果？

哪一步失败了？

谁确认的？

谁审批的？

如果这些记录没有留下，出了问题以后很难复盘。

企业对AI的信任不是靠口号建立的，是靠一次次可追溯的执行记录建立的。

FDE在设计Agent权限体系时，要把日志和权限放在一起设计。

读数据要有记录。

写字段要有记录。

触发流程要有记录。

调用接口要有记录。

用户确认和审批要有记录。

尤其是涉及敏感数据、关键字段、外部接口和自动执行动作时，日志不能只写一句“操作成功”。它要能说明谁发起、Agent做了什么、人确认了什么、系统改了什么。

图3：Agent权限、审批和日志要放在一条链路里

八、FDE在织信里可以怎样落这套权限体系？

FDE用织信做企业Agent权限体系，不应该一上来就写一堆提示词。

更稳的顺序，是先把业务系统里的权限骨架搭起来。

第一步，建业务对象。

比如客户、合同、回款、项目、工单、设备、供应商、采购申请、审批记录。

对象建清楚以后，Agent读什么、写什么、触发什么才有落点。

第二步，定义角色。

销售、销售主管、财务、采购、设备主管、项目经理、管理员，不同角色对应不同数据范围和操作范围。

第三步，拆字段权限。

普通字段、敏感字段、关键状态字段、金额字段、审批结果字段，要分别处理。能读、能写、只读、脱敏、需审批后查看，这些规则要提前配置。

第四步，配置动作权限。

新增、编辑、提交、驳回、转交、关闭、作废、导出、同步、接口调用，不同动作要有不同控制。

第五步，接审批流。

高风险动作进入审批，低风险动作走确认。涉及金额、权限、外部系统写回的动作，要设置更严格的流程。

第六步，接Agent。

Agent只能在平台允许的业务对象、字段、动作和流程边界里工作。它可以生成建议，可以填草稿，可以解释异常，可以触发待确认动作，但不能绕过平台权限。

第七步，做日志和复盘。

每一次读取、生成、修改、确认、审批、接口调用都能查。后面根据日志再优化权限、流程和Agent能力。

这套顺序看起来比直接接模型慢一点，但更适合企业长期用。

因为企业AI应用一旦进入真实业务，后面一定会遇到审计、合规、责任、权限调整和流程优化。

前面把底座搭稳，后面迭代才不会乱。

图4：FDE设计Agent权限体系的实施路线

九、权限设计清楚以后，Agent才敢往执行层走

企业做AI Agent，早期可以从问答、总结、填单、生成草稿开始。

这些场景风险相对低，容易试起来。

但只要企业希望Agent进入更深的业务执行层，比如改数据、发审批、调接口、写回系统，就必须先把权限体系说清楚。

AI能看什么。

AI能改什么。

AI能触发什么。

哪些动作要人确认。

哪些动作要审批。

哪些动作必须留痕。

这些问题不解决，Agent能力越强，企业越不敢用。

FDE的价值就在这里。

它不是把一个模型接进系统就结束了。它要把企业业务对象、角色权限、字段规则、审批流程、接口边界、操作日志和Agent能力放在一起设计。

织信AI智能开发平台也适合承接这类工作。因为Agent权限不是单独挂在模型旁边的一张配置表，它要落在业务对象、表单字段、流程节点、数据范围、接口调用和审计记录里。

这也是企业AI落地和个人AI工具最大的区别。

个人工具只要好用就行。企业系统还要可控、可查、可改、可追责。

FDE做Agent权限体系，最终要交付的不是一套漂亮权限表。

它要交付的是一种企业可以放心扩展AI能力的执行边界。

边界清楚了，Agent才敢往业务深处走。

边界不清楚，AI越能干，风险越大。