企业AI Agent上线以后，项目组通常会先松一口气。

测试跑过了，权限配好了，审批能走了，日志也能查到。业务部门终于能用起来，老板也能在汇报里看到一个比较完整的AI应用场景。

但真正麻烦的地方，往往从这一天才开始。

一线员工用了几天，会发现有些字段不好填。审批人跑了一轮，会觉得某个节点太绕。财务看完报表，会说统计口径不对。管理员检查日志，又发现有些问题来自知识库旧资料，有些问题来自提示词表达不清，有些问题来自流程规则本来就没有说完整。

这时候，企业很容易走向两个极端。

• 一种是继续让Agent凑合用，出了问题人工补救，时间长了业务部门就不愿意用了。

• 另一种是看到问题就马上改，今天改提示词，明天改知识库，后天改流程，最后连项目组自己都说不清哪个版本是稳定的。

所以，FDE前沿部署工程师在企业AI项目中的工作，不能停在上线那一刻。

Agent上线只是起点，真正决定它能不能长期有价值的，是上线以后的持续迭代机制。

图1：企业AI Agent上线后的持续迭代闭环

一、先把“改什么”说清楚

很多企业做AI Agent，第一次迭代就容易乱。

业务部门说它不好用，技术人员问哪里不好用，业务又说不上来。最后只能根据几条反馈临时调整。今天把回答语气改得更热情一点，明天把提示词加长一点，后天又多塞几份制度文档进去。

这种改法很危险。

因为Agent的问题，来源并不只有模型回答。企业里的Agent通常会连接数据、表单、流程、权限、接口、知识库和日志。用户说一句“不准”，背后可能是完全不同的问题。

比如采购申请Agent回答错供应商付款条件，可能有几种原因：

• 知识库里的供应商合同版本过旧。

• Agent没有读到供应商主数据里的最新字段。

• 用户提问时缺少采购类型、合同编号或项目归属。

• 提示词没有要求它优先引用系统字段。

• 权限配置限制了它读取某些财务信息。

这些问题的处理方法完全不同。

知识库旧了，就要更新资料和索引。字段没读到，就要检查数据对象和接口。用户输入缺少条件，就要调整表单或提问入口。提示词约束不够，就要改专家设定。权限限制导致数据不完整，就要重新评估读数权限。

所以FDE做持续迭代，第一步先放慢一点。把反馈分清楚，再决定到底该改知识、改规则、改权限，还是改流程。

一个合格的Agent反馈，至少要说清楚几个信息：

• 发生在哪个业务场景。

• 涉及哪个数据对象或流程节点。

• 用户原始输入是什么。

• Agent实际输出是什么。

• 业务期望结果是什么。

• 问题属于知识、规则、数据、权限、接口、流程，还是用户体验。

只有这样，迭代才不会变成拍脑袋。

图2：FDE需要先把Agent问题按来源分类

二、知识库更新，不能当成资料堆叠

企业AI Agent经常依赖知识库。制度、流程说明、产品手册、合同模板、项目方案、FAQ、培训资料，都可能放进去。

很多团队一开始会觉得，知识库当然越多越好。资料越全，Agent回答得越准。

实际用起来未必如此。

知识库不是网盘。它不是把文件堆进去就完事。企业的制度文件有版本，流程文件有适用范围，合同模板有生效时间，项目资料还有客户、部门、角色的边界。资料放得越多，如果没有管理，Agent越容易在一堆相似内容里拿错依据。

比如费用报销制度，去年版本规定部门负责人审批即可，今年版本增加了财务复核。如果旧文件没有下线，Agent仍然可能引用旧规则。再比如销售合同模板，不同区域、不同行业、不同金额区间可能用不同条款，知识库如果只按文件名管理，业务人员很难判断Agent到底引用了哪一份。

所以FDE要帮助企业建立知识库更新规则。

一般来说，至少要管住四件事。

第一，资料来源。哪些文档可以进入知识库，谁负责上传，上传前是否需要业务负责人或法务、财务确认。

第二，版本状态。每份资料要区分有效、待更新、已废止。已废止资料不能继续作为Agent回答依据。

第三，适用范围。制度适用于哪个部门、业务线、区域、角色或客户类型，不能让一个场景的规则误用到另一个场景。

第四，引用记录。Agent回答或执行动作时，如果使用了某份知识资料，后续要能查到引用来源。

知识库迭代看起来是内容管理，实际牵连业务责任。资料错了，Agent回答错；资料旧了，流程可能走错；资料边界不清，权限和合规都会受影响。

FDE在这里的价值，是把知识资料从“文件堆”变成“可治理的业务依据”。

图3：知识库更新需要版本、范围和引用记录

三、提示词和专家设定，要像配置项一样管理

很多企业刚开始做Agent，会把提示词当成一段说明文字。

这段说明文字通常写得很长：你是一个专业的采购助手，你要认真、准确、合规地回答用户问题，必要时查询系统数据，并根据公司制度给出建议。

这种写法能不能用？能用一点。

但企业Agent越往业务深处走，提示词就越不能只靠感觉写。因为提示词里往往承载了角色边界、回答方式、工具调用顺序、异常处理方式和风险提示要求。

比如客户信用变更Agent，就不能只说“帮我判断客户风险”。它需要说明：

• 优先读取客户档案、历史订单、回款记录和售后投诉。

• 不能直接修改客户信用等级，只能生成变更建议。

• 金额超过一定范围的客户，必须提示销售经理复核。

• 如果关键字段缺失，要返回缺失项，不允许凭空补齐。

• 最终变更必须通过审批流完成，并写入操作日志。

这些内容已经不是普通文案，它更像Agent的业务配置。

FDE要做的，是把专家设定、提示词、工具说明、输出格式和风险约束纳入版本管理。每一次修改，都要记录修改原因、修改人、影响范围和验证结果。

否则项目后期一定会出现一个很头疼的问题：Agent现在为什么会这么回答？

没人知道。

上一版提示词是谁改的？为什么加了这条规则？有没有影响其他场景？上线前测过哪些用例？如果这些问题回答不上来，持续迭代就变成了持续失控。

所以企业要把提示词当成配置项管理。它可以被业务人员理解，也要能被技术人员追踪，还要能被管理员审核。

四、版本发布，必须有灰度和回滚

Agent和传统软件有一个很明显的区别：它的变化有时候很细。

改一个字段映射，改一个知识库版本，改一句提示词，改一个工具调用顺序，表面看只是小调整，实际可能影响很多输出结果。

这就要求企业不能把Agent迭代当成后台随手保存。

一个比较稳的做法，是把Agent迭代分成几个状态。

• 草稿版：FDE和业务负责人先调整配置、知识库、动作目录和提示词。

• 测试版：用历史问题、典型单据、异常场景做验证。

• 灰度版：先开放给少量部门或部分用户使用。

• 正式版：通过验证后再进入完整业务场景。

• 回滚版：如果新版本出现明显问题，可以恢复到上一个稳定版本。

这里的重点，不在于流程看起来多正规。真正要守住的，是企业AI进入真实业务前的安全边界。

比如一个采购Agent，新版本增加了自动生成采购申请草稿的能力。它在测试环境里表现不错，但到了真实业务中，可能会遇到供应商状态异常、预算不足、物料编码不一致、交期字段缺失等问题。

如果直接全量开放，问题会一下子扩散。

如果先灰度到一个部门，FDE就可以观察：生成的草稿有多少被采纳，多少被修改，修改集中在哪些字段，是否出现审批驳回，是否有人工接管记录。

这些数据回来以后，再决定是否扩大范围。

这就是企业AI迭代最朴素的原则：小步调整，先看结果，再扩大使用。

图4：Agent迭代应当经过测试、灰度、正式和回滚

五、迭代权限要收住，责任要落到角色上

企业系统里最怕的一件事，是大家都能提意见，最后没人负责。

Agent迭代也一样。业务部门可以反馈，运营人员可以整理，FDE可以分析，管理员可以配置，技术人员可以处理接口和数据问题，但每类动作都要有责任边界。

比如知识库更新，业务负责人应当确认资料是否有效。

比如字段和流程调整，FDE要判断是否影响数据对象、报表口径和审批规则。

比如权限范围变化，管理员和安全负责人要确认读写边界。

比如API调用逻辑调整，技术人员要验证参数、幂等、异常处理和日志记录。

如果所有人都可以直接改Agent，问题迟早会出现。

今天业务人员觉得回答太保守，就把约束删掉。明天运营人员觉得命中率不高，就把知识资料都加进去。后天技术人员为了测试方便，临时放宽了接口权限。再过一段时间，大家发现Agent变得很难控制，但已经说不清是哪一次改动造成的。

所以FDE要建立一套迭代责任表。

• 业务反馈由业务负责人确认优先级。

• 知识资料由资料责任人维护版本。

• 流程和字段由FDE评估影响范围。

• 权限和接口由管理员、技术人员审核。

• 上线发布由项目负责人确认。

• 异常回滚由运维或平台管理员执行。

这样做并不是为了增加流程负担。企业AI越接近真实业务，越需要把责任说清楚。

六、织信这类平台，适合承载Agent持续迭代

企业AI Agent持续迭代，听起来像AI问题，实际落地时更多是工程和管理问题。

因为每一次迭代，都可能牵连应用对象、字段、流程、权限、知识库、API、日志和看板。如果这些能力分散在很多系统里，FDE会很难形成闭环。

比如业务反馈在一个表里，知识库在另一个系统里，流程配置在审批平台里，API日志在技术平台里，效果指标又在BI报表里。问题一多，项目组就会不停切系统、对口径、找负责人。

织信AI智能开发平台的价值，就在于它可以作为企业AI应用建设和持续运营的承载层。

在这类平台里，业务对象、表单字段、流程节点、角色权限、数据报表、接口能力、知识资料和Agent能力可以围绕同一套业务应用组织起来。FDE做迭代时，不能只盯着某一段提示词，更要回到完整业务结构里看问题。

一个Agent回答不准，要看知识库和数据对象。

一个Agent动作执行失败，要看API参数、审批规则和异常日志。

一个Agent效果不好，要看业务动作记录、人工接管记录和指标看板。

一个Agent要扩展到新部门，要看角色权限、流程差异和使用反馈。

这就是低代码和AI结合以后比较务实的价值。它的作用不只在于更快做一个界面，也不只在于给模型多接几个工具。更重要的是，企业能得到一套可调整、可治理、可复盘的业务应用结构。

图5：织信可承载Agent从反馈到发布的持续迭代结构

七、FDE要把迭代变成长期机制

一个企业AI Agent能不能长期运行，最后看的是机制。

第一次上线，靠项目热情可以推起来。第二次优化，靠几个人加班也能顶住。可如果企业有十几个Agent、几十个业务场景、多个部门同时使用，临时处理就不够了。

FDE要帮助企业建立一套长期机制。

这套机制至少包括几个部分。

• 反馈入口：用户在哪里提交问题，如何描述问题，是否能关联单据、流程和会话记录。

• 问题分类：是知识问题、数据问题、权限问题、流程问题、接口问题，还是体验问题。

• 优先级判断：哪些问题影响生产业务，哪些问题只是体验优化，哪些问题需要立即回滚。

• 修改验证：每一次调整要用哪些场景测试，测试结果如何记录。

• 版本发布：什么时候进入灰度，什么时候全量开放，出现问题如何回退。

• 效果复盘：迭代以后，业务指标有没有改善，人工接管有没有减少，错误有没有下降。

这些内容看起来普通，但正是企业AI从演示走向生产的关键。

没有这套机制，Agent上线以后只会越来越乱。知识越来越多，规则越来越杂，权限越来越难管，问题越来越难查。

有了这套机制，Agent才有机会越用越稳。它不会因为几次错误就被业务放弃，也不会因为随意修改而失去控制。

结语

企业AI Agent上线以后，真正的考验才刚开始。

FDE要做的，不只是把第一版Agent搭出来，也要帮助企业建立一套持续迭代的方法。反馈怎么收，问题怎么分，知识库怎么更新，提示词怎么管理，版本怎么发布，出了问题怎么回滚，效果怎么复盘，这些都要进入日常运营。

这也是为什么FDE这个角色很重要。

它站在业务现场和工程平台之间，既要听懂业务人员说的“不好用”，也要能把这句话拆成可处理的问题清单；既要理解Agent能力，也要知道企业系统里的字段、流程、权限、接口和日志怎么配合。

AI进入企业以后，系统建设不会因为一次上线就结束。相反，越往后走，持续迭代越重要。

企业真正需要的，不能停留在一个偶尔能回答问题的Agent。更重要的是，形成一套能被管理、能被改进、能被追溯、能随着业务长期生长的AI应用体系。

这正是FDE和织信AI智能开发平台要共同解决的问题。