企业把AI Agent接进业务系统以后很快会遇到一个很现实的问题这个Agent到底算谁算一个员工吗算一个系统账号吗算某个部门的助手吗还是算一个可以到处调用接口的自动化程序这个问题听起来像技术细节实际关系很大。因为Agent一旦能读取数据、修改字段、发起审批、调用接口它就不再只是一个聊天窗口。它已经进入企业业务执行链路了。上一篇我们讲了FDE怎么把AI Agent放进审批流里。审批流解决的是一个问题AI做事之前哪些动作要进流程哪些动作要人确认。但审批流还不够。在审批之前还有一层更基础的东西要先设计好权限。AI能看什么能改什么能触发什么能不能跨部门取数能不能读取敏感字段能不能替用户调用接口如果调用失败谁知道如果改错数据谁负责这些问题如果不提前说清楚企业后面一定会反复补课。FDE前沿部署工程师做Agent权限体系真正要解决的是把AI的每一个业务动作都放进可控边界里不能只停留在“给不给权限”这一步。图1Agent权限不能只做一个开关一、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自动发起付款审批权限设计就必须非常谨慎。图2Agent动作权限矩阵三、读权限要看数据范围不能只看表名很多系统做权限喜欢按表控制。客户表能不能看。合同表能不能看。订单表能不能看。这种方式只能解决很粗的问题。到了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做了什么、人确认了什么、系统改了什么。图3Agent权限、审批和日志要放在一条链路里八、FDE在织信里可以怎样落这套权限体系FDE用织信做企业Agent权限体系不应该一上来就写一堆提示词。更稳的顺序是先把业务系统里的权限骨架搭起来。第一步建业务对象。比如客户、合同、回款、项目、工单、设备、供应商、采购申请、审批记录。对象建清楚以后Agent读什么、写什么、触发什么才有落点。第二步定义角色。销售、销售主管、财务、采购、设备主管、项目经理、管理员不同角色对应不同数据范围和操作范围。第三步拆字段权限。普通字段、敏感字段、关键状态字段、金额字段、审批结果字段要分别处理。能读、能写、只读、脱敏、需审批后查看这些规则要提前配置。第四步配置动作权限。新增、编辑、提交、驳回、转交、关闭、作废、导出、同步、接口调用不同动作要有不同控制。第五步接审批流。高风险动作进入审批低风险动作走确认。涉及金额、权限、外部系统写回的动作要设置更严格的流程。第六步接Agent。Agent只能在平台允许的业务对象、字段、动作和流程边界里工作。它可以生成建议可以填草稿可以解释异常可以触发待确认动作但不能绕过平台权限。第七步做日志和复盘。每一次读取、生成、修改、确认、审批、接口调用都能查。后面根据日志再优化权限、流程和Agent能力。这套顺序看起来比直接接模型慢一点但更适合企业长期用。因为企业AI应用一旦进入真实业务后面一定会遇到审计、合规、责任、权限调整和流程优化。前面把底座搭稳后面迭代才不会乱。图4FDE设计Agent权限体系的实施路线九、权限设计清楚以后Agent才敢往执行层走企业做AI Agent早期可以从问答、总结、填单、生成草稿开始。这些场景风险相对低容易试起来。但只要企业希望Agent进入更深的业务执行层比如改数据、发审批、调接口、写回系统就必须先把权限体系说清楚。AI能看什么。AI能改什么。AI能触发什么。哪些动作要人确认。哪些动作要审批。哪些动作必须留痕。这些问题不解决Agent能力越强企业越不敢用。FDE的价值就在这里。它不是把一个模型接进系统就结束了。它要把企业业务对象、角色权限、字段规则、审批流程、接口边界、操作日志和Agent能力放在一起设计。织信AI智能开发平台也适合承接这类工作。因为Agent权限不是单独挂在模型旁边的一张配置表它要落在业务对象、表单字段、流程节点、数据范围、接口调用和审计记录里。这也是企业AI落地和个人AI工具最大的区别。个人工具只要好用就行。企业系统还要可控、可查、可改、可追责。FDE做Agent权限体系最终要交付的不是一套漂亮权限表。它要交付的是一种企业可以放心扩展AI能力的执行边界。边界清楚了Agent才敢往业务深处走。边界不清楚AI越能干风险越大。