企业官网建设流程全解析

1. 从“聊天问答”到“业务嵌入”：JNPF低代码AI的定位拆解

1.1 为什么大多数低代码平台的AI还停留在“玩具阶段”

我接触过不少低代码平台，也帮几家制造和零售企业做过数字化选型。一个很普遍的现象是：平台宣传页上写着“AI赋能”，点进去一看，无非是一个侧边栏对话框，能帮你写写SQL、解释一下报错信息，或者根据一句话生成一个简单的表单。用完的感觉就是——有它没它都行，它跟真正的业务系统是两张皮。

这个问题的根源在于，大部分低代码平台的AI能力是“外挂式”的。它没有跟表单引擎、流程引擎、权限体系、数据模型发生真正的耦合。你问它“上个月华东区退货率最高的三个SKU是什么”，它没法直接查你的业务数据库；你说“帮我发起一个采购申请”，它也没法调用你的流程引擎去创建实例。它本质上就是一个嵌在iframe里的通用聊天窗口，跟你的业务数据之间隔着一道墙。

JNPF低代码AI的思路不太一样。它强调的是“深度嵌入企业全业务流程”，这句话翻译成大白话就是：AI不是一个独立的聊天入口，而是渗透到表单填写、流程审批、数据查询、报表生成、代码生成这些具体环节里，成为业务操作的一部分。这个定位的差异，决定了后面所有技术选型和落地方式的走向。

1.2 核心关键词拆解：MCP、Skills、Agents到底在说什么

要理解JNPF这套AI能力的底层逻辑，得先把几个关键概念理清楚。这几个词在热搜里反复出现，但很多人其实是模糊的。

MCP，全称Model Context Protocol，是一个让AI模型跟外部工具、数据源进行标准化交互的协议。你可以把它理解成AI世界的“USB接口标准”——以前每个AI要调用外部工具，都得写一套专属的对接代码；有了MCP之后，只要工具端实现了MCP Server，AI端就能用统一的方式去调用它。JNPF低代码平台如果要把AI跟自己的表单、流程、数据模型打通，MCP就是那个关键的中间层。

Skills，在AI语境下，指的是预定义好的、可复用的能力单元。比如“查询库存”是一个Skill，“发起审批”是一个Skill，“生成月度报表”也是一个Skill。Skills的价值在于，它把复杂的业务操作封装成AI可以理解和调用的原子能力，AI不需要知道底层数据库怎么查、流程引擎怎么调，它只需要知道“有这个Skill可用”就行了。

Agents，则是把这些Skills编排起来，完成一个完整任务的智能体。比如用户说“帮我处理一下本周的采购异常”，Agent会自己去判断：先查采购订单状态（Skill A），再比对入库记录（Skill B），发现差异后发起异常处理流程（Skill C），最后通知相关责任人（Skill D）。这一连串动作，就是Agent在调度Skills。

JNPF低代码AI的落地实操，本质上就是在做一件事：把企业业务系统中的关键操作，封装成MCP协议下的Skills，然后让AI Agent能够根据自然语言指令，自动编排和执行这些Skills。

1.3 这套方案适合什么样的团队和场景

不是所有企业都适合一上来就搞这么重的AI嵌入。根据我的观察，以下几类场景ROI最高：

第一类是中大型企业的内部管理系统。这类系统流程复杂、表单众多、数据量大，但操作人员往往需要经过大量培训才能熟练使用。AI嵌入之后，新员工可以用自然语言完成大部分操作，培训成本直线下降。

第二类是业务规则频繁变动的场景。比如零售行业的促销规则、制造行业的工艺参数，经常需要调整。传统低代码平台虽然能改配置，但改完之后一线人员还是得重新学习。AI Agent可以根据最新的规则自动调整操作路径，减少人为失误。

第三类是需要跨系统协同的场景。很多企业的ERP、CRM、OA是割裂的，数据不通。通过MCP协议把各个系统的关键能力封装成Skills，AI Agent就能在一个对话里完成跨系统的操作，不用来回切换界面。

注意：如果你的业务系统还处于“能用就行”的阶段，数据质量差、流程不规范，建议先把基础打牢。AI嵌入的前提是业务流程本身已经数字化、标准化了，否则AI只会把混乱放大。

2. 核心架构解析：JNPF低代码AI是怎么把AI“焊”进业务流程的

2.1 整体架构分层：从界面到数据模型的完整链路

JNPF这套AI嵌入方案，从架构上可以分成四层。我画不了图，但可以用文字把每一层的职责和交互关系说清楚。

最底层是数据与模型层。这一层包含JNPF低代码平台本身的数据模型定义、数据库表结构、以及业务实体的元数据。AI要操作业务数据，首先得知道“有哪些实体”“实体之间什么关系”“每个字段什么含义”。JNPF的做法是把这些元数据通过MCP Server暴露出去，让AI能够动态获取。

第二层是能力封装层，也就是Skills层。这一层把具体的业务操作封装成标准化的Skill。比如“创建采购申请单”这个操作，底层可能涉及表单数据插入、流程实例创建、消息通知发送等多个步骤，但在Skills层，它就是一个名为create_purchase_request的原子能力，接收几个参数，返回执行结果。

第三层是Agent编排层。这一层负责理解用户的自然语言输入，判断意图，然后决定调用哪些Skills、以什么顺序调用、参数怎么填。JNPF的Agent编排支持两种模式：一种是基于规则的确定性编排，适合流程固定的场景；另一种是基于大模型推理的动态编排，适合需要灵活判断的场景。

最上层是交互层。这一层不只是聊天窗口，还包括表单内的AI辅助填写、流程审批页面的AI建议、报表页面的自然语言查询等。交互层的关键设计原则是“不打断用户现有操作习惯”——AI是嵌入到现有界面里的，而不是让用户跳到一个全新的聊天页面。

2.2 MCP Server的落地方式：自建还是复用

JNPF低代码平台要接入MCP协议，有两种路径。一种是平台官方提供MCP Server，把标准的数据操作和流程操作暴露出来；另一种是企业自己基于JNPF的开放API，开发定制化的MCP Server。

从我实际接触的案例来看，大部分企业走的是混合路线：通用能力（比如CRUD、流程发起、消息发送）用官方提供的MCP Server；行业特有的业务逻辑（比如制造业的BOM校验、零售业的库存锁定）自己开发MCP Server。

自建MCP Server的技术门槛其实不高。核心工作就是实现MCP协议定义的几个标准方法，把企业的业务API包装成MCP Tool。JNPF低代码平台本身提供了丰富的REST API，你只需要写一个适配层，把这些API的入参和出参映射到MCP Tool的schema上就行了。

实操心得：自建MCP Server时，建议把Tool的粒度控制得粗一些。比如“查询订单”这个Tool，不要拆成“按订单号查”“按客户查”“按日期查”三个，而是设计成一个Tool接收多个可选参数。粒度太细会导致Agent编排时选择困难，反而降低效率。

2.3 Skills的设计原则：原子性、幂等性、可组合性

Skills设计得好不好，直接决定了AI Agent能不能可靠地完成业务任务。我总结了三条核心原则。

原子性是指一个Skill只做一件事，做完之后状态是明确的。比如“扣减库存”是一个Skill，“生成出库单”是另一个Skill。不要把两个操作揉在一个Skill里，否则出错时很难定位问题。

幂等性是指同一个Skill用同样的参数调用多次，结果应该是一致的。这在业务场景里特别重要，因为AI Agent可能会因为网络超时等原因重试。如果“扣减库存”这个Skill不幂等，重试就会导致库存被扣两次。实现幂等性的常见做法是引入业务唯一键，每次调用时先检查这个键是否已经处理过。

可组合性是指Skills之间可以自由组合，形成更复杂的业务流程。比如“采购入库”这个复合操作，可以由“查询采购订单”“校验入库数量”“更新库存”“生成入库单”四个Skills组合而成。Agent编排层负责决定组合的顺序和条件分支。

下面这张表是我在实际项目中总结的Skills设计检查清单：

2.4 与低代码引擎的耦合点：表单、流程、报表、代码生成

JNPF低代码AI的嵌入点，主要集中在四个地方。

表单是最高频的嵌入点。传统表单需要用户逐个字段填写，AI嵌入后，用户可以用自然语言描述需求，AI自动填充表单字段。比如在采购申请表单里，用户输入“帮我申请采购100个A4纸，下周三之前到”，AI会自动解析出物料、数量、期望到货日期，填入对应字段。更高级的用法是，AI根据历史数据自动推荐供应商和采购单价。

流程是第二个嵌入点。在审批环节，AI可以根据当前审批节点的规则和历史审批记录，给出审批建议。比如“这个采购申请金额超过预算，建议驳回”或者“该供应商历史履约良好，建议通过”。审批人可以直接采纳AI建议，也可以修改。

报表是第三个嵌入点。传统报表需要用户选择维度、指标、筛选条件，AI嵌入后，用户直接问“上个月华东区销售额是多少”，AI自动生成查询并返回结果。更复杂的问题，比如“哪个产品线的毛利率下降最快”，AI也能通过多步查询和计算给出答案。

代码生成是第四个嵌入点。JNPF低代码平台本身支持自定义脚本和插件开发，AI可以根据自然语言描述生成代码片段。比如“写一个校验手机号格式的函数”，AI直接生成JavaScript代码，开发者确认后即可使用。

3. 实操落地：从零搭建一个AI嵌入的采购审批流程

3.1 环境准备与基础配置

假设我们要在一个已经用JNPF搭建好的采购管理系统中，嵌入AI能力，实现“自然语言发起采购申请”和“智能审批建议”两个功能。以下是完整的实操步骤。

首先确认JNPF平台的版本。AI嵌入功能需要JNPF 5.0及以上版本，因为MCP支持和Agent编排引擎是在这个版本引入的。登录管理后台，在“系统设置-高级功能”里确认“AI能力”和“MCP服务”两个开关已经打开。

然后配置大模型接入。JNPF支持多种大模型后端，包括本地部署的开源模型和云端API。在“AI配置”页面，填入模型服务的地址和密钥。如果企业有数据安全要求，建议使用本地部署的模型，通过内网地址接入。

注意：模型选择上，建议至少使用70B参数级别的模型，否则在意图理解和多步推理上会频繁出错。我试过用7B模型做Agent编排，简单指令还行，稍微复杂一点就开始胡言乱语。

接下来创建MCP Server。在JNPF的“集成中心”里，新建一个MCP Server，命名为purchase-mcp。这个Server会暴露采购相关的Skills。JNPF会自动生成一个基础的MCP Server框架，包含标准的协议处理方法，我们只需要在里面注册具体的Tool。

3.2 封装采购业务Skills

在purchase-mcpServer里，我们需要注册以下几个核心Skill：

第一个是query_material，根据物料名称或编码查询物料信息。输入参数是keyword（字符串），输出是物料列表，包含物料编码、名称、规格、当前库存、参考单价。

第二个是query_supplier，根据物料编码查询合格供应商列表。输入参数是material_code，输出是供应商列表，包含供应商编码、名称、历史履约评分、最近成交价。

第三个是create_purchase_request，创建采购申请单。输入参数包括material_code、quantity、expected_date、supplier_code、remark，输出是申请单号。

第四个是get_approval_suggestion，根据申请单号获取AI审批建议。输入参数是request_id，输出是建议类型（通过/驳回/转交）和建议理由。

每个Skill的实现，本质上就是调用JNPF的开放API。以create_purchase_request为例，核心代码逻辑如下：

// MCP Tool: create_purchase_request async function createPurchaseRequest(params) { // 1. 参数校验 if (!params.material_code || !params.quantity) { return { success: false, message: '物料编码和数量为必填项' }; } // 2. 查询物料信息，获取默认单价 const material = await jnpf.api.get('/material/detail', { code: params.material_code }); if (!material) { return { success: false, message: '物料不存在' }; } // 3. 计算总金额 const totalAmount = material.reference_price * params.quantity; // 4. 创建采购申请单 const request = await jnpf.api.post('/purchase/request', { material_code: params.material_code, material_name: material.name, quantity: params.quantity, unit_price: material.reference_price, total_amount: totalAmount, expected_date: params.expected_date, supplier_code: params.supplier_code, remark: params.remark, status: 'pending' }); // 5. 发起审批流程 await jnpf.flow.start('purchase_approval', { business_key: request.id, initiator: params.user_id }); return { success: true, request_id: request.id, request_no: request.no, message: `采购申请已创建，单号${request.no}，总金额${totalAmount}元` }; }

这段代码的关键点在于：它把“查物料”“算金额”“建单据”“启流程”四个步骤封装成了一个原子Skill。Agent调用时只需要提供物料编码和数量，其他细节由Skill内部处理。

3.3 Agent编排配置：让AI理解“帮我采购一批办公用品”

Skills注册好之后，下一步是配置Agent。在JNPF的“AI Agent管理”页面，新建一个Agent，命名为“采购助手”。

Agent的核心配置包括三部分：系统提示词、可用Skills列表、编排策略。

系统提示词决定了Agent的角色和行为边界。我通常这样写：

你是一个企业采购助手，负责帮助用户完成采购申请和审批相关操作。 你可以调用以下Skills：query_material、query_supplier、create_purchase_request、get_approval_suggestion。 当用户表达采购意图时，先确认物料和数量，再查询供应商，最后创建申请单。 如果用户提供的信息不完整，主动询问缺失的参数。 不要编造物料编码或供应商信息，所有数据必须来自Skill的返回结果。

可用Skills列表就是前面注册的那四个。编排策略选择“动态编排”，让大模型根据用户输入自主决定调用顺序。

配置完成后，在测试窗口输入“帮我采购100个A4纸，下周三之前到”。Agent的执行过程大致如下：

第一步，识别意图为“创建采购申请”，提取实体：物料名称“A4纸”、数量“100”、期望日期“下周三”。

第二步，调用query_material，参数keyword=“A4纸”，返回物料编码MAT001、参考单价25元。

第三步，调用query_supplier，参数material_code=“MAT001”，返回三家供应商，其中供应商SUP003履约评分最高。

第四步，调用create_purchase_request，参数material_code=“MAT001”、quantity=100、expected_date=“2025-01-15”、supplier_code=“SUP003”，返回申请单号PR20250108001。

第五步，Agent把结果整理成自然语言回复用户：“已为您创建采购申请，单号PR20250108001，物料A4纸100个，供应商选择履约评分最高的XX公司，预计下周三到货，总金额2500元。申请已提交审批，请等待处理。”

整个过程用户只需要说一句话，Agent自动完成了四步操作。这就是“深度嵌入业务流程”的实际效果。

3.4 审批环节的AI建议实现

采购申请创建后，会进入审批流程。传统审批需要审批人自己查看申请详情、比对预算、判断合理性。AI嵌入后，审批页面会直接显示AI建议。

实现方式是：在审批节点的“进入前事件”里，调用get_approval_suggestion这个Skill。Skill内部会做几件事：

第一，查询该物料的历史采购价格，判断本次单价是否偏高。如果高于历史均价10%以上，标记为“价格异常”。

第二，查询该供应商的历史履约记录，包括交货准时率、质量合格率。如果履约评分低于阈值，标记为“供应商风险”。

第三，查询当前部门的采购预算余额，判断本次申请是否超预算。如果超预算，标记为“预算不足”。

第四，综合以上三个维度的判断，生成建议类型和理由。如果全部正常，建议“通过”；如果有任一异常，建议“驳回”或“转交上级”。

审批人看到的界面是这样的：申请单详情上方有一个AI建议卡片，显示“建议通过”或“建议驳回”，下面列出具体的判断依据。审批人可以一键采纳建议，也可以忽略建议自行决策。

实操心得：AI建议的准确率取决于历史数据的质量。如果企业之前的采购数据记录不完整，AI的判断会经常出错。建议在启用AI建议之前，先花时间清洗历史数据，至少保证最近一年的采购记录是完整的。

4. 常见问题与排查技巧实录

4.1 Agent调用Skill失败的高频原因

在实际部署过程中，Agent调用Skill失败是最常见的问题。根据我的排查经验，原因主要集中在以下几类：

参数格式不匹配。Agent从用户输入中提取的参数，格式可能跟Skill定义的schema不一致。比如用户说“下周三”，Agent可能提取出“下周三”这个字符串，但Skill期望的是标准日期格式“2025-01-15”。解决方法是在Skill的输入schema里明确定义日期格式，并在Agent的系统提示词里强调“所有日期参数必须转换为YYYY-MM-DD格式”。

Skill返回结果过大。如果query_material返回了100条物料记录，Agent的上下文窗口可能被撑爆，导致后续推理失败。解决方法是在Skill内部做分页或限制返回条数，默认只返回最相关的5条。

权限校验失败。Agent调用Skill时使用的身份令牌，可能没有对应业务操作的权限。比如普通员工调用create_purchase_request，但该员工没有采购申请权限。解决方法是在Skill内部做权限校验，并返回明确的错误信息，Agent据此告知用户“您没有采购申请权限，请联系管理员”。

网络超时导致重复调用。前面提到过，Skill必须幂等。如果create_purchase_request不幂等，网络超时后Agent重试，就会创建两张申请单。解决方法是在Skill内部用业务唯一键做去重，比如用“用户ID+物料编码+数量+日期”作为唯一键，重复调用时直接返回已有单据。

下面这张表是我整理的常见错误码和排查方向：

4.2 大模型幻觉在业务场景中的表现与抑制

大模型幻觉在聊天场景里可能只是“胡说八道”，但在业务场景里可能导致真实的经济损失。我遇到过几个典型的幻觉案例：

一个是Agent编造了不存在的物料编码。用户说“采购一批打印纸”，Agent没有调用query_material去查，而是直接编了一个编码MAT999，然后调用create_purchase_request，结果创建了一张无效的申请单。

另一个是Agent在审批建议里编造了历史价格。它没有调用get_approval_suggestion，而是根据训练数据里的“常识”判断“A4纸单价25元合理”，但实际上该企业历史采购价一直是18元。

抑制幻觉的核心手段是强制工具调用。在Agent编排策略里，可以设置“对于涉及业务数据的操作，必须先调用对应的查询Skill，禁止直接生成答案”。JNPF的Agent配置里有一个“工具调用优先级”选项，把它设为“强制”后，Agent在回答业务问题前必须先调用Skill获取真实数据。

另一个手段是结果校验。在Skill返回结果后，Agent在生成最终回复前，做一次一致性校验。比如create_purchase_request返回了申请单号，Agent在回复里必须包含这个单号，不能自己编一个。JNPF的Agent引擎支持配置“回复模板”，强制Agent按照模板填充真实数据。

4.3 性能优化：如何让Agent响应控制在3秒以内

Agent的响应时间直接影响用户体验。如果用户说一句话要等10秒才有回复，再好的功能也没人用。根据我的调优经验，响应时间主要消耗在三个环节：模型推理、Skill调用、网络传输。

模型推理是大头。如果使用云端API，推理时间通常在1-3秒。优化手段包括：选择更快的模型（比如推理优化版本）、减少系统提示词的长度、限制上下文窗口大小。如果使用本地模型，推理时间取决于GPU性能，建议至少使用A10或同等级别的显卡。

Skill调用的优化重点是减少串行调用。比如create_purchase_request内部调用了“查物料”“查供应商”“建单据”“启流程”四个API，如果串行执行，总耗时可能超过2秒。优化方法是把能并行的调用并行化，比如“查物料”和“查供应商”可以同时进行。

网络传输的优化主要是减少数据量。Skill返回的结果不要包含大字段（比如图片base64、长文本描述），只返回Agent决策所需的最小数据集。

实操心得：我通常会在Agent配置里加一个“超时降级”策略。如果Agent在5秒内没有完成推理，就降级为简单的关键词匹配模式，直接返回预设的引导话术，比如“请提供物料编码和数量，我来帮您创建采购申请”。这样虽然功能弱化了，但至少不会让用户干等。

4.4 数据安全与权限隔离的注意事项

AI嵌入业务系统后，数据安全是一个绕不开的话题。Agent在调用Skill时，使用的是谁的权限？如果Agent用的是管理员权限，那普通员工就能通过AI越权操作。

JNPF的做法是权限透传。用户在发起对话时，系统会携带该用户的身份令牌。Agent调用Skill时，把这个令牌一起传给MCP Server。MCP Server在执行具体操作前，用这个令牌去校验用户是否有对应权限。

这个机制的关键在于，令牌不能是长期有效的。建议使用短期令牌，有效期控制在5分钟以内，过期后需要重新获取。同时，MCP Server要记录每一次Skill调用的详细日志，包括调用者、调用时间、参数、结果，便于事后审计。

另一个注意事项是敏感数据的脱敏。Agent在返回结果时，可能包含敏感信息，比如供应商的联系电话、银行账号。这些信息不应该直接展示给没有权限的用户。解决方法是在Skill返回结果前做脱敏处理，或者根据用户权限动态决定返回哪些字段。

5. 扩展方向：从采购审批到全业务流程覆盖

5.1 销售、库存、财务场景的Skills复用

采购审批跑通之后，这套模式可以快速复制到其他业务域。核心思路是一样的：把业务操作封装成Skills，配置对应的Agent，嵌入到现有界面里。

销售场景可以封装create_sales_order、query_customer_credit、check_inventory_availability等Skills。Agent可以帮销售人员在跟客户沟通时，实时查询库存和信用额度，快速生成报价单。

库存场景可以封装query_stock、adjust_stock、transfer_stock等Skills。仓库管理员用自然语言就能完成库存查询和调拨操作，不用在复杂的库存管理界面里点来点去。

财务场景可以封装query_invoice、create_payment、reconcile_account等Skills。财务人员可以用自然语言查询发票状态、发起付款申请、进行对账。

每个场景的Agent可以独立配置，也可以组合成一个“超级Agent”，根据用户意图自动路由到对应的Skills。JNPF的Agent编排引擎支持多Agent协作，一个主Agent负责意图识别和任务分发，多个子Agent负责具体业务域的操作。

5.2 与外部系统的MCP对接

企业内部往往不止JNPF一个系统。ERP、CRM、HRM可能来自不同厂商，数据格式和接口标准各不相同。MCP协议的价值在这里就体现出来了：只要外部系统提供了MCP Server，JNPF的Agent就能直接调用，不需要为每个系统写定制化的对接代码。

比如企业的ERP系统如果支持MCP，JNPF的采购Agent就可以直接调用ERP的query_inventorySkill，获取实时库存数据，而不需要先把ERP数据同步到JNPF的数据库里。这样既减少了数据同步的延迟，也降低了数据不一致的风险。

对于不支持MCP的外部系统，可以写一个适配层，把它的API包装成MCP Server。这个适配层的工作量不大，通常一两天就能完成一个系统的对接。

5.3 持续迭代：从规则驱动到数据驱动

初期上线的Agent，编排策略通常以规则为主。比如“用户说采购，就调用采购相关的Skills”。这种方式简单可靠，但灵活性有限。

随着使用数据的积累，可以逐步引入数据驱动的优化。比如分析用户的真实对话记录，发现哪些意图识别经常出错，哪些Skill调用经常失败，然后针对性地调整系统提示词和编排策略。

更高级的玩法是让Agent自己学习。JNPF的Agent引擎支持“反馈闭环”：用户可以对Agent的回复进行评价（满意/不满意），这些评价数据可以用来微调模型或优化编排规则。虽然目前这个功能还比较初级，但方向是对的。

我个人在实际操作中的体会是，AI嵌入业务流程这件事，技术不是最大的障碍，业务理解和数据治理才是。我见过太多团队一上来就追求“全自动”“零人工”，结果因为业务规则没梳理清楚、历史数据一团糟，最后AI给出的建议没人敢用。反而是那些从小场景切入、先把一个流程跑通、再逐步扩展的团队，落地效果最好。如果你正准备启动类似的项目，我的建议是：选一个业务规则清晰、数据质量较好的流程作为试点，比如采购申请或者费用报销，跑通之后再复制到其他场景。不要贪大求全，先让一线人员感受到AI带来的便利，后面的推广会顺利很多。