作者：卢向东，杭州萌嘉网络科技有限公司创始人。团队长期专注于企业 AI 落地与 AI 知识引擎实践，是国内较早探索 RAG 企业应用落地的团队之一。产品 TorchV 已成功服务浪潮信息、微众银行、物产中大、台州银行、适途汽车、中汇税务师事务所等客户。

企业AI落地不是让业务人员学习 AI 的工作方式，而是让 AI 能力进入业务人员熟悉的工作方式。

上周出差上海与一家会计师事务所交流AI在他们业务中的落地，过程中突然让我意识到了一个AI落地的问题：很多企业 AI 项目并不是卡在模型能力上，而是卡在“业务人员不知道该如何通过对话框完成一套复杂业务流程”。

一、企业AI落地中存在的鸿沟

当前很多AI原生应用默认采用对话式交互，也就是 CUI（命令行用户交互界面）。不管是Claude、ChatGPT、DeepSeek、Kimi等大模型，还是龙虾、Hermers等Agent，对话式交互适合问答、检索、生成、改写，但并不天然适合承载复杂业务流程。对于已经习惯了三十年 GUI （图形化用户交互界面）系统的企业用户来说，他们更熟悉的是列表、表单、状态、按钮、审批流、退回、挂起和复审，而不是把一整套业务流程压缩进一个聊天窗口里。

对于接触AI两年以上，甚至本身就有技术背景的人来说，目前主流Agent的对话形式已经越来越亲切了，但是对于大多数非技术出身的业务侧人员，他们很难在会话中把自己熟知的业务流程转译出来。比如对于工商审计业务，我们假设会有以下这些流程：

• 00-项目准备：创建审计项目，填写基本信息，选择需要收集的资料收集清单，审计底稿模板和审计报告模板等。

• 01-资料收集：根据要做的业务类型给客户准备资料的清单，然后收集资料并上传知识库进行解析和存储，这里的界面是需要看到收集的文件列表的，并自动识别上传的文件内容（如判定为房产证），与材料清单做对比，可让用户查看哪些资料已经完成，哪些还缺失。

• 02-资料比对：系统不仅要判断资料是否齐全，还要识别每份资料的类型，并抽取关键字段。例如房产证需要提取房产证号、权利人、坐落、规划用途、建筑面积等信息，再与业务要求进行比对。

• 03-生成底稿：如果前序工作未全部满足，可让人工介入，判断缺失的信息是否必须，或者直接由人工直接补充相应的信息。如果没有问题，那么开始按照该业务类型的资料准备方法生成底稿，即将前面提取的信息填入生成的底稿中，这个过程是将几十、上百份资料的有效信息转移到一份统一的底稿的过程。如果信息不满足当前业务，那么可以打回到01-资料收集，给出提示，补充必须的资料，再将补充内容走一遍。

• 04-生成报告：通过已经信息充分的底稿，以及该类业务的审核知识，在Agent和相应Skill的帮助下，生成该业务的审计报告。给出审计结论和决定，可以反向引用查找审计工作底稿（下文也可能简称“底稿”或“工作底稿”）。

• 05-复审记录：复审的过程会调用知识库中的内部复审方法知识库，复审的目的是检查和回应被审计单位的异议，以及检查审计质量。

如果要让一个非技术出身的业务侧人员把这些流程和步骤在问答式交互中轻松完成确实有些难，里面还包含了一些回退、协作、转发审批等工作。这时候有步骤流程的GUI界面就会凸显优势，如上面说的资料列表、资料提取出来的信息查看、比对结果、缺失提醒、可在线编辑的审计工作底稿、可编辑的审计报告等，在GUI界面上会看的更清晰，而且“下一步”、“退回”、“挂起”、“忽略”等按钮让用户感到亲切，具有很强的业务流程指引作用。

图：这类场景下，用户真正需要的不是一个万能聊天框，而是一个能够呈现业务状态、资料状态和任务流转状态的流程界面。

企业AI落地会遇到很多问题，我只是给大家撕开了冰山一角。但如果我们没有意识到这个问题的严重性的话，它可能会从一开始的客户接触到最后的交付都会一直给企业AI落地带来大麻烦。因为当前项目中的用户业务视角与服务商的AI技术视角存在巨大鸿沟，双方一直在不同频道对话。

在软件设计中，Facade 模式的核心思想是：用一个更简单、更符合使用者认知的外观层，屏蔽底层系统的复杂性。企业AI落地中也存在类似问题：底层有知识库、Agent、Skill、文档解析、任务编排、权限控制等复杂能力，但业务用户真正需要看到的，是“资料是否齐了”、“底稿是否生成了”、“报告哪里需要复审”这些业务动作。因此，企业AI落地也需要一个面向业务用户的Facade。

二、方案即交付—从需求沟通到业务应用雏形

在最近各种自媒体对FDE（FDE，即 Forward Deployed Engineer，通常指深入客户现场，把技术能力和客户业务场景结合起来完成落地交付的人）“膜拜”之前，我们已经在为国内的一些大型企业做了一年多的AI落地工作：从需求到方案，从部署、试运行、反馈和迭代。当然这种交付方式客户很喜欢，很土很接地气，所以我们自己把它称之为土味FDE工程。

土味FDE工程最大的问题是对人的要求太高，你要对客户业务有一定理解力，能和客户一起组织和编写AI建设方案，而且还需要和研发团队沟通，安排计划等。在试运行开始后要培训客户的实际使用者，让他们把系统使用起来。这里面最困难的其实是确认你说的和客户理解的是不是一回事，为此我们一般会根据客户的业务流程出一些简单的交互，比如早前使用v0，现在使用Claude Code/Codex去完成交互的生成。

现在，我们需要往前再走一步，在和客户把需求沟通清楚之后，把整理后的需求给到一个特定的Agent（比如AIS业务流程应用生成Agent，我们暂定叫AIS应用生成器），快速生成一个面向具体行业客户和具体业务场景，符合客户业务流程习惯的网页版应用系统。这不是传统意义上的 Demo，也不是一次性的原型图，而是把方案中的业务流程、材料清单、模板规范、任务状态和 AI 能力调用关系，提前转化为一个可体验、可讨论、可迭代的业务应用雏形。该系统不重复建设底层 AI 能力，而是通过 API 和原子命令调用 AIS知识引擎、WorkStation、Agent、Skill、知识加工、报告生成等能力，将复杂 AI作业封装成用户可理解、可操作、可复审的业务流程。

这样做有以下几个好处：

• 方案即交付：在与客户需求交流和方案编制阶段，通过AIS应用生成器根据客户具体业务流程和使用习惯生成交互界面。客户可看到交付之后将要接收的是一个怎么样的系统，提前参与整个过程，极大减轻后续的培训陪跑工作。当然，最重要的是让AI系统落地之后能被客户的使用者接纳并真正使用起来。
• 降低FDE难度：特别是在FDE的前半段，与客户沟通形成方案的阶段。有了这样AIS应用生成器，就可以快速生成一个可视化的应用Demo，而不需要销售/售前人员展开超强的描述能力让客户脑子里产生画面，其好处在于降低了FDE工程对于人员的要求。
• 行业沉淀，优化交付：AIS应用生成器不断生成各类业务流程界面，也为后续形成行业模板、业务流程模板、报告模板、Skill 模板打好基础。后续可通过配置快速生成不同场景的业务应用，降低行业交付成本。

三、AIS-Side应用服务—企业AI落地的Facade

好吧，其实我们现在还没有AIS应用生成器这个Agent。

但Vibe Coding时代你们知道的，在代码层面产出一个带有清晰业务流程交互界面的应用难度不大。真正难的是如何让客户感知整个交付物系统已经从“功能型平台”转化为“流程型业务系统”。而且不重复建设底层AI能力，而是通过API/原子命令等调用AIS的一系列成熟能力，如AIS-Core知识引擎、AIS-WorkStation（含Agent、Skill、报告生成等能力）、AIS-ETL知识加工，将复杂AI作业封装成用户可理解、可操作、可复核的业务流程。

在继续往下之前，我用最简单的篇幅先介绍一下AIS的现有架构：

图：AIS的整体架构，AIS-Core是知识引擎核心功能，AIS-WorkStation工作区是Agent执行的主要模块。

我认为AI落地的时候，整个系统应该采用“业务应用层 + 能力服务层 + AI 基础设施和执行层”的架构，这里我们带出来一个新的服务：AIS-Side应用服务（AIS的一个侧翼服务），其所在位置和作用如下图所示：

图：AIS-Side在整体架构中的位置，以及和AIS-Core、AIS-WorkStation的关系。

这里需要区分两个概念：AIS应用生成器更像是面向方案和交付阶段的生成工具，用来根据客户业务流程快速生成业务应用雏形；AIS-Side应用服务则是这些业务应用真正运行时依赖的中间层，负责流程配置、状态管理、任务编排、API 调用、权限和日志等能力。前者解决“如何快速生成”，后者解决“如何稳定运行”。

从设计模式角度看，AIS-Side就是企业AI落地中的Facade层。它不替代底层的AIS-Core、AIS-WorkStation、Agent和Skill，而是把这些复杂能力重新组织成业务用户能够理解的流程、页面、按钮、状态和结果。

我们代入工商审计的业务来看这张架构图，先看这三层各自的定位：

• 业务应用层负责面向用户呈现具体业务流程，包括资料收集、资料比对、底稿整理、报告生成、复审反馈等界面。

• 能力服务层由 AIS-Side应用服务承担，负责流程配置、状态管理、任务编排、接口调用、权限控制和结果聚合。

• AI基础设施和执行层由AIS-Core知识引擎和 AIS-WorkStation智能体工作区承担，负责文档解析、知识加工、信息抽取、Agent 执行、Skill 调用、报告生成和内容修订。

当用户在业务应用层开始作业时，系统内部会由AIS-Side应用服务承接请求，并根据业务流程配置调用AIS-Core知识引擎和AIS-WorkStation智能体工作区。AIS-Core知识引擎负责资料接入、解析、结构化、检索和证据链；AIS-WorkStation负责Agent执行（具体由内部的Sage-Agent执行）、Skill调用、底稿整理、报告生成和复审处理。最终，AIS-Side应用服务将任务状态和处理结果聚合后，以业务流程的方式返回给前端展示。

这种架构的最大优势就是：既可以不打折扣地发挥AI的能力，又可以让用户不脱离作业的业务逻辑工作。

以下是各个环节中用户视角和技术视角的对比（注：工商审计的六个环节仅用于本文，非正式业务流程。）

在真实场景中还有很多工作要做，比如版本管理、修订、归档和输出，以及流程、材料清单、底稿规范模板、报告标准模板等的管理，这里不一一展开。

四、技术实现

如果把上面的思路落到系统实现上，AIS-Side不需要做成一个庞大的新平台，而更适合做成一个轻量的业务应用服务层。它的职责不是重新建设知识库、Agent或报告生成能力，而是把已有AI能力组织进具体业务流程中。

从端到端角度，技术实现上来说可以分为五大模块，具体如下表格所示：

表：系统核心模块与职责说明

五、总结—让AI能力以业务系统的方式被使用

企业在AI落地项目中会碰到很多问题，这些问题可以分为技术问题和工程问题。

在OpenAI的GPT-3.5横空出三年多的现在，对很多企业AI项目来说，模型和技术能力当然仍然重要，但它们已经不再是唯一的瓶颈。真正决定项目能否被用起来的，往往是工程化落地能力：业务流程是否被理解，用户界面是否贴近作业习惯，AI能力是否被封装成可操作、可复核、可追踪的业务动作。

所以本文的主要目的是为了讨论一种在AI落地过程中的交流模式和配套行动，从需求阶段就开始解决业务视角和技术视角的鸿沟。关于这个主题的讨论今天先抛个砖，我们应该也会在接下来新的AI落地项目中和客户一起去尝试探索。