FDE怎么把审批流和AI Agent结合起来

企业做AI Agent，很快会碰到一个绕不开的问题：AI到底能不能替人发起审批？

比如采购部门想让AI自动整理采购申请。

业务人员只要说一句：帮我根据这批物料需求生成采购申请。

AI可以读取物料清单、供应商信息、历史采购价、预算科目，再生成一张申请单。看起来很顺。

但到了企业现场，问题马上来了。

这张申请单能不能直接提交？

预算够不够，谁来校验？

金额超过多少要部门负责人审批？

供应商如果不在合格名单里，能不能继续走？

AI生成的采购理由如果不准确，责任算谁的？

这些问题如果不提前设计清楚，AI Agent就会变成一个很危险的执行入口。它能帮人省掉填表时间，也可能把原来由制度控制的环节悄悄绕过去。

所以FDE前沿部署工程师在做企业AI应用时，不能只关心Agent能不能生成内容、调用接口、写回数据。

更关键的一步，是把AI Agent放进企业原来的审批流里。

图1：AI Agent进入审批流前，需要先经过规则、权限和人工确认

企业AI应用真正要解决的，不只是让AI会做事，还要让AI在该确认的地方停下来，在该审批的地方交给流程。

一、为什么Agent一旦能发审批，项目复杂度就变了？

很多企业刚开始做AI应用时，需求都比较轻。

帮我写一段客户跟进总结。

帮我整理会议纪要。

帮我从合同里抽取几个关键字段。

这些场景主要是内容生成和信息整理，风险相对可控。即使AI写得不够好，人看一眼改掉就行。

但只要Agent开始发审批，性质就变了。

审批不是一段文字，它是企业管理动作。

一张采购申请发出去，后面可能影响预算、库存、供应商、合同和付款。

一张费用报销提交出去，后面可能影响成本归集、财务审核和付款计划。

一张客户折扣申请进入流程，后面可能影响报价、利润和销售政策。

一张数据权限申请被通过，后面可能影响敏感字段的访问边界。

这些动作都带责任。

原来由员工填写、主管审核、财务复核、负责人确认的链路，不能因为接了AI，就变成“AI认为可以，所以系统自动通过”。

FDE在这里要先做一个判断：Agent在这个审批场景里到底扮演什么角色？

它可以是填单助手。

根据业务材料自动生成申请单，减少人工录入。

它可以是规则校验助手。

检查金额、预算、供应商、合同、附件是否符合企业规则。

它可以是审批意见助手。

帮助审批人整理风险点和建议，但最终决定仍由审批人做。

它也可以是流程触发助手。

当系统识别到特定条件时，自动发起某个审批流程。

这些角色看起来都叫Agent，实际边界完全不同。

如果FDE不把角色边界讲清楚，业务部门会以为AI能全自动处理，IT部门会担心权限失控，管理层也很难放心把流程交出去。

二、FDE要先拆清楚：哪些动作能自动，哪些动作要确认？

审批流和普通流程最大的区别，是它天然带有控制点。

FDE要做的第一件事，就是把这些控制点找出来。

我们拿采购申请来看。

业务人员说，希望AI根据物料需求自动生成采购申请。

这句话听起来简单，拆开以后至少有几类动作。

第一类是读取数据。

AI要读取物料需求、库存数量、供应商信息、历史采购价格、预算余额和项目计划。

读取动作本身也要受权限控制。普通采购员能不能看到所有供应商价格？项目成员能不能看到预算余额？不同部门的数据能不能互相读取？这些都要提前定。

第二类是生成内容。

AI可以生成采购申请标题、采购理由、物料明细、数量建议、供应商建议和预计金额。

这类动作可以提高效率，但生成结果不能默认等于事实。FDE要设计人工确认环节，让申请人能看到AI生成了什么，并且可以修改。

第三类是规则校验。

预算是否足够，供应商是否合规，价格是否异常，附件是否齐全，金额是否超过阈值。这类校验适合由系统规则先做一遍，再让AI把异常解释给人看。

第四类是提交审批。

这一步要特别谨慎。

如果只是低金额、低风险、规则明确的申请，可以考虑由用户确认后一键提交。

如果涉及大额采购、合同条款、供应商准入、敏感权限、财务付款，就不能让AI直接越过人工责任人。

第五类是写回结果。

审批通过以后，系统要更新申请状态、生成采购任务、同步预算占用或进入合同流程。审批驳回以后，也要记录驳回原因和下一步处理人。

这些动作不是一股脑交给模型完成。

FDE要把每个动作拆成清楚的边界：谁触发，谁确认，谁审批，谁负责，系统记录什么。

图2：FDE把审批场景拆成读取、生成、校验、提交和写回五类动作

Agent可以帮企业减少填写和整理工作，但带有责任、金额、权限和数据变更的动作，必须进入明确的审批控制。

三、审批流不能只靠提示词控制

有些项目早期会把审批规则写进提示词里。

比如告诉AI：金额超过5万元需要主管审批，供应商不在名单里不能提交，合同附件缺失要提醒用户。

这类提示词可以作为辅助说明，但不能当成企业审批控制的主机制。

原因很简单。

提示词可以指导模型输出，却不能真正锁住系统动作。

企业要控制的是系统层面的能力。

谁能看到预算字段。

谁能发起采购申请。

谁能提交到下一级。

金额超过多少自动走不同审批路径。

哪些异常必须阻断提交。

哪些接口调用必须记录。

这些都要落在平台、流程、权限和日志里。

FDE如果只把规则写进提示词，短期看起来很快，后面一定会补课。

业务规则一变，提示词要改。

组织架构一变，权限要改。

审批节点一变，流程要改。

监管要求一变，日志要补。

如果这些能力没有落在系统里，维护会越来越乱。

比较稳的做法，是让Agent负责理解材料、生成建议、解释异常；让平台负责权限判断、流程流转、字段校验、状态更新和操作留痕。

这也是织信这类低代码和AI智能开发平台适合承载审批场景的原因。

在织信里，FDE可以先把采购申请、供应商、预算、合同、审批记录这些对象建起来，再把字段、角色、流程节点和数据规则配置清楚。

Agent生成申请内容时，只能读取当前用户允许访问的数据。

用户确认申请内容以后，流程再根据金额、部门、供应商状态和预算情况进入不同审批路径。

审批人看到的不只是AI生成的一段话，还能看到相关字段、规则校验结果、历史记录和风险提示。

审批通过或驳回以后，平台负责更新状态、记录日志、通知相关人员。

这样做以后，AI没有脱离企业管理制度单独行动。它被放进了流程里，成为流程中的一个能力节点。

图3：提示词负责表达任务，平台负责执行边界和审批控制

四、织信里适合怎样承载“Agent加审批流”？

FDE用织信做这类场景，通常不会一开始就追求全自动。

更现实的路线，是先把“AI辅助填单、规则校验、人工确认、流程审批、结果写回”这一条链路跑通。

第一步，建业务对象。

采购申请是主对象，物料明细、供应商、预算科目、合同、审批记录可以作为关联对象。

对象建清楚以后，AI读什么、写什么、关联什么，才有落点。

第二步，设字段规则。

申请金额、采购类型、供应商状态、预算科目、项目编号、附件状态、紧急程度，这些字段要有明确类型和校验规则。

字段规则越清楚，AI生成内容时越不容易飘。

第三步，配角色权限。

申请人能新建申请，部门负责人能审批本部门申请，财务能看预算和付款相关字段，采购负责人能管理供应商信息。

如果某些字段涉及敏感信息，可以设置只读、脱敏或仅特定角色可见。

第四步，搭审批流程。

低金额采购可以走部门负责人审批。

高金额采购可以增加财务和总经理审批。

供应商异常时，可以先进入供应商准入复核。

预算不足时，可以阻断提交或进入预算调整流程。

第五步，接入Agent能力。

Agent可以根据物料需求和历史数据生成申请草稿，也可以对申请内容做风险检查，提醒缺附件、价格异常、预算不足、供应商状态异常等问题。

关键是，Agent生成完以后要让人确认。

它可以把申请单填好，但提交前要让申请人看到。

它可以给审批人整理建议，但审批按钮仍然属于审批人。

它可以触发提醒，但不能替代所有责任判断。

第六步，留痕和复盘。

每一次AI读取了哪些数据、生成了哪些内容、用户修改了什么、谁提交了审批、谁审批通过、接口有没有写回，都要能查。

企业后续要优化流程，也要靠这些记录。

比如哪些申请经常被驳回，哪些字段经常缺失，哪些部门审批时间过长，哪些AI建议被审批人频繁修改。

这些信息回到平台里，就能继续优化规则、表单、流程和Agent提示。

FDE做审批流，重点在于把AI能做的事、必须由人负责的事、需要系统记录的事分清楚。

五、一个审批场景可以怎样从轻到重逐步上线？

企业AI项目最怕一上来就想做全自动。

审批场景尤其如此。

FDE更适合把它拆成几个阶段。

第一阶段，只做AI辅助填单。

AI根据已有材料生成申请内容，人负责检查和提交。这个阶段风险最低，也最容易让业务部门感受到效率提升。

第二阶段，加入规则校验。

系统检查字段完整性、预算、金额、供应商状态、附件情况。AI负责把异常解释清楚，告诉用户哪里需要补充。

第三阶段，加入审批建议。

审批人进入页面后，可以看到AI整理的风险点、历史记录、相似申请和处理建议。审批人自己决定通过、驳回或转交。

第四阶段，加入条件触发。

当系统发现特定业务条件，比如库存低于安全值、客户折扣超过阈值、设备异常达到等级，可以自动生成待确认申请。用户确认后再进入审批。

第五阶段，部分低风险动作自动化。

对于金额小、规则明确、风险低、可随时追溯的动作，可以逐步提高自动化程度。即使这样，也要保留日志、撤回、异常告警和责任归属。

这种分阶段方式更适合中大型企业。

因为企业里的审批不是孤立功能，它连着组织权限、财务规则、合同制度、采购制度和风控要求。

AI能力越强，越要把边界做清楚。

如果一开始只追求自动化比例，后面很容易因为一次异常操作让整个项目停下来。

如果先把规则、流程、权限和追溯打好，自动化程度就可以跟着业务成熟度一点点提高。

图4：AI审批场景从辅助填单到低风险自动化的分阶段上线路径

六、FDE真正要交付的，是可控的企业AI执行链路

审批流只是一个切入口。

同样的方法，也适用于合同评审、客户折扣、费用报销、权限申请、工单派发、项目变更、数据修改等场景。

这些场景都有一个共同点：AI可以参与，但企业不能失去控制。

FDE要交付的，不是一段能把表单填满的AI提示词。

它要交付的是一条可控的执行链路。

这条链路里，业务对象清楚。

这条链路里，字段权限清楚。

这条链路里，Agent能读什么、能写什么、能触发什么动作都清楚。

这条链路里，该人工确认的地方有确认，该审批的地方有审批，该记录的地方有记录。

这样，企业才敢把AI从内容生成工具，逐步放进真实业务流程。

织信AI智能开发平台的价值，也在这里体现出来。

它让FDE能在一个平台里同时处理业务对象、表单页面、流程审批、角色权限、系统集成、数据日志和AI能力接入。

项目早期可以先轻量验证，后续再不断补规则、补流程、补权限、补自动化。

企业AI落地如果只看模型，很容易越做越虚。

如果从业务对象、审批流和执行边界开始做，AI才有机会成为企业系统里可管理、可追溯、可持续迭代的一部分。

第三篇讲到这里，重点其实很明确：

FDE把AI Agent接入审批流，目的很明确：让AI在企业原有管理规则里提高效率，不能让AI绕过审批。

审批流接好了，后面再谈权限控制、接口调用、数据写回和操作追溯，才不会变成空中楼阁。