低代码AI实战：用MCP协议与Skills机制将AI嵌入业务流程节点

1. 为什么“聊天问答”只是低代码AI的冰山一角

很多团队第一次接触低代码平台里的AI能力，基本都停留在“对话框里问一句、它答一句”的阶段。表单怎么建、流程怎么配、报表怎么拉，还是靠人手一步步点。结果就是AI像个外挂的客服，跟真正的业务系统是两张皮。我去年帮一家做供应链的客户做内部系统升级时，他们的技术负责人跟我说得很直白：“我们试过好几个带AI的低代码工具，最后都变成给员工配了个聊天窗口，业务该多慢还是多慢。”

这句话点到了要害。低代码平台的价值本来是把“业务逻辑”从代码里解放出来，让懂业务的人能直接搭系统；AI的价值则是把“判断和生成”从人脑里解放出来，让系统能自己处理模糊信息。这两件事如果只在对话框里碰一下，等于两个能力都没发挥出来。真正有价值的做法，是让AI深度嵌入到业务流程的每一个节点里——表单填写时自动补全、流程审批时自动预判、数据录入时自动校验、报表生成时自动归因。

JNPF这套低代码平台我前前后后用了两年多，从最早的纯表单流程版本，到后来接入AI能力，再到最近这版把MCP协议和Skills机制打通，变化非常明显。它现在能做到的事情，已经远远超出“聊天问答”的范畴。举个最直观的例子：以前做一个采购申请流程，员工要手动填供应商、物料、数量、预算科目，填错了到审批节点才被打回来；现在AI可以在员工刚输入物料名称的时候，就根据历史采购记录和当前库存自动带出推荐供应商、参考单价、预算余额，甚至在提交前就提示“这个供应商上次交货延期了三天，要不要换一家”。

这篇文章我想聊的就是这套东西怎么落地。不是讲概念，是讲我实际搭过的流程、踩过的坑、调过的参数。适合两类人看：一类是正在选型低代码平台、想知道AI到底能嵌到多深的技术负责人；另一类是用过JNPF但只停留在表单流程层面、想把AI用起来的实施人员。我会从整体设计思路讲到具体配置，再到问题排查，尽量把每个环节的“为什么”说清楚。

2. 整体设计思路：AI不是插件，是流程里的一个“岗位”

2.1 从“外挂对话框”到“流程节点”的认知转变

大部分低代码平台接入AI的方式，是在界面右上角放一个悬浮按钮，点开是个聊天窗口。这种设计的问题在于，AI和业务数据之间隔着一层“人”。员工要把业务数据复制粘贴到对话框里，AI给出建议后，员工再手动填回表单。这个过程中，AI没有直接读写业务数据的能力，它只是一个更聪明的搜索引擎。

JNPF这版的做法不一样。它把AI能力封装成了流程引擎可以调用的“节点”。什么意思呢？就是在你画流程图的时候，除了传统的“审批节点”“条件节点”“抄送节点”，还多了一类“AI处理节点”。这个节点可以读取上游节点传过来的数据，调用大模型或者本地Skills进行处理，然后把结果写回流程变量，供下游节点使用。

这个设计思路的转变很关键。AI不再是一个需要人主动去“问”的东西，而是流程走到某个环节时自动触发的“岗位”。就像公司里有个专门负责审核发票的财务，流程走到报销环节，单据自动流转到他桌上，他处理完再往下传。AI节点扮演的就是这个角色，只不过它处理的是那些规则明确但需要判断力的任务。

2.2 MCP协议在中间扮演了什么角色

这里要解释一下MCP。MCP全称是Model Context Protocol，是一个让AI模型和外部工具、数据源之间建立标准化连接的协议。你可以把它理解成“AI世界的USB接口”——不管对面是数据库、文件系统、还是某个业务系统的API，只要按MCP规范封装好，AI就能直接调用。

在JNPF的架构里，MCP主要解决两个问题。第一是数据接入的标准化。企业的业务数据散落在ERP、CRM、OA、甚至Excel文件里，以前要让AI用上这些数据，得一个个写适配代码。现在只要把这些数据源封装成MCP Server，AI节点就能通过统一的方式读取。第二是工具调用的标准化。比如AI需要查库存、算价格、发通知，这些操作以前要写死在代码里，现在可以封装成MCP Tool，AI根据上下文自己决定调哪个。

我实际用下来，MCP最大的好处是“解耦”。业务系统的开发人员不需要懂AI，他们只需要把业务能力按MCP规范暴露出来；AI这边的调优人员也不需要懂业务系统的内部实现，只需要知道有哪些MCP Tool可用。两边可以并行开发，最后在流程里汇合。

2.3 Skills机制让AI学会“公司内部的做事方式”

Skills这个词最近很热，但很多人理解得比较窄，以为就是给AI写一段提示词。在JNPF的语境里，Skills是一套可复用、可组合的“能力包”。一个Skill包含三部分：触发条件、处理逻辑、输出格式。

举个例子，我帮客户做了一个“供应商风险评估”的Skill。触发条件是流程走到采购审批节点且金额超过5万；处理逻辑是调用MCP Tool查询该供应商的历史交货准时率、质量退货率、当前合作状态，然后让大模型综合这些数据给出风险等级；输出格式是固定的JSON，包含risk_level、reason、suggestion三个字段。这个Skill做好之后，任何采购流程都可以挂载它，不需要重复开发。

Skills机制的价值在于“沉淀”。企业里有很多隐性的判断规则，比如“这个客户虽然信用分低但合作五年了可以放宽账期”“这个物料虽然库存够但下个月要涨价建议多采”。这些规则以前只存在于老员工的脑子里，现在可以通过Skills固化下来，让AI在流程里自动执行。

3. 核心细节解析：AI节点到底怎么配

3.1 AI节点的输入输出定义

配置一个AI节点，第一步是定义它吃什么、吐什么。JNPF的AI节点配置界面里，输入部分可以选择“流程变量”“表单字段”“固定值”三种来源。我的经验是尽量用流程变量，因为表单字段会随着表单改版而失效，固定值只适合做常量配置。

输出部分需要定义Schema。这里有个坑：很多人图省事，让AI直接输出一段自然语言，然后下游节点用字符串截取的方式去解析。这种做法在演示的时候没问题，一上生产就崩。因为大模型的输出有随机性，今天说“风险较高”，明天说“存在一定风险”，字符串匹配根本扛不住。

正确的做法是强制AI输出结构化数据。在JNPF里可以通过两种方式实现：一是在提示词里明确要求JSON格式并给出示例；二是使用平台内置的“结构化输出”开关，它会自动约束模型的输出格式。我一般两个都用，提示词里写清楚，同时打开结构化输出做兜底。

{ "risk_level": "high", "risk_score": 78, "reasons": ["近三个月交货准时率低于80%", "存在两笔未结质量扣款"], "suggestion": "建议要求供应商提供履约保证金或更换备选供应商" }

上面这个结构是我做供应商评估时用的。risk_level只有high、medium、low三个枚举值，这样下游的条件节点可以直接用等值判断，不需要做模糊匹配。

3.2 提示词工程的实操要点

提示词这东西，网上的教程大多在讲“角色设定”“思维链”这些通用技巧。但在企业流程场景里，提示词的核心目标不是让AI“回答得好”，而是让AI“输出得稳”。稳定比聪明重要得多。

我总结下来，企业场景的提示词要包含四个部分：角色约束、数据注入、判断规则、输出格式。角色约束是告诉AI“你是谁、你的职责边界在哪”；数据注入是把流程变量里的业务数据填进去；判断规则是把公司的制度翻译成AI能理解的逻辑；输出格式就是上面说的Schema。

举个实际的例子。我们做费用报销的AI审核节点时，提示词是这样写的：

你是公司财务共享中心的费用审核专员。你的职责是根据公司报销制度审核员工提交的费用申请。你只能基于以下提供的数据和规则做判断，不得引入外部知识。

待审核数据：报销人部门为{{dept}}，费用类型为{{expense_type}}，金额为{{amount}}元，发生日期为{{date}}，事由为{{reason}}。

审核规则：1. 差旅费单笔超过5000元需附审批单；2. 业务招待费需注明招待对象和人数；3. 发生日期超过90天的费用不予报销；4. 同一事由重复报销的标记为异常。

请输出JSON格式的审核结果，包含pass（布尔值）、reject_reason（字符串，pass为true时为空）、risk_flag（字符串，可选值为none、duplicate、over_limit、expired）。

这段提示词里没有“请仔细思考”“你是一个专业的”这类废话。每句话都有明确的功能。数据注入用双花括号占位，JNPF在运行时会自动替换成实际的流程变量值。

3.3 流程变量的传递与作用域

AI节点处理完的数据要写回流程变量，供下游节点使用。这里有个作用域的问题容易被忽略。JNPF的流程变量分三种作用域：全局变量、流程实例变量、节点局部变量。

全局变量在整个流程定义里都能访问，适合放一些配置项，比如“公司差旅标准”“审批金额阈值”。流程实例变量跟具体的流程实例绑定，每个实例的值可以不同，适合放表单数据、AI处理结果。节点局部变量只在当前节点内有效，出了这个节点就销毁，适合放一些临时计算值。

我踩过的坑是：一开始把所有AI输出都写成全局变量，结果多个流程实例并发的时候数据互相覆盖。后来改成流程实例变量就正常了。判断标准很简单：如果这个数据是“这个流程走到这里时产生的”，就用流程实例变量；如果是“所有流程都一样的配置”，才用全局变量。

3.4 Skills的注册与版本管理

Skills在JNPF里是以独立模块存在的，可以跨流程复用。注册一个Skill需要填名称、描述、输入参数、输出参数、处理逻辑。处理逻辑可以是一段提示词，也可以是一个MCP Tool调用链。

版本管理这块我要特别提醒。Skills一旦被多个流程引用，修改的时候就要非常小心。我的做法是：任何Skill的修改都新建一个版本，而不是直接改原版本。新版本先在一个测试流程里验证，确认没问题后再把生产流程的引用指向新版本。JNPF支持Skill的多版本共存，引用的时候指定版本号就行。

这个做法看起来麻烦，但能避免“改了一个Skill，十个流程同时出问题”的灾难。我见过一个团队因为直接改了公共Skill的提示词，导致所有采购流程的审批意见格式全乱了，排查了一整天才定位到原因。

4. 实操过程：从零搭一个带AI的采购审批流程

4.1 流程建模与节点规划

先画流程图。一个典型的采购审批流程包含这些节点：发起申请、AI预审、部门审批、AI风险评估、财务审批、采购执行、完成。其中AI预审和AI风险评估是两个AI节点，其他是人工节点或系统节点。

为什么要在部门审批之前加一个AI预审？因为人工审批的时间很宝贵，应该花在真正需要判断的事情上。AI预审负责处理那些规则明确的部分：预算科目对不对、金额有没有超限、必填项有没有漏。这些检查AI几秒钟就能做完，人工做可能要几分钟，而且容易漏。

AI风险评估放在财务审批之前，是因为财务最关心的是“这笔采购会不会出问题”。AI把供应商的历史表现、当前合作状态、市场行情这些数据综合起来给一个风险评级，财务看到评级后再决定要不要深入看细节。这样财务的审批效率能提升很多。

4.2 AI预审节点的详细配置

预审节点的输入需要这些流程变量：申请部门、采购类别、预算科目、申请金额、物料清单、期望到货日期。输出需要这些变量：precheck_pass、precheck_issues、corrected_budget。

提示词的核心逻辑是三条规则：第一，预算科目必须与采购类别匹配，比如“办公用品”不能走“设备采购”的预算；第二，申请金额不能超过该预算科目当前可用余额；第三，期望到货日期不能早于当前日期加采购周期。

这里有个细节：预算余额需要通过MCP Tool实时查询，不能写死在提示词里。我在JNPF里配置了一个MCP Server，对接的是客户的预算系统，暴露了一个query_budget_balance的方法。AI节点在运行时先调用这个方法拿到余额，再把余额和申请金额一起送给大模型判断。

# MCP Tool调用的伪代码示意 budget_info = mcp_client.call( server="budget-system", tool="query_budget_balance", params={"dept": dept_code, "subject": budget_subject} ) # budget_info 返回 {"available": 125000, "used": 75000, "total": 200000}

拿到余额后，提示词里这样写：“该预算科目当前可用余额为{{budget_info.available}}元，本次申请金额为{{amount}}元。如果申请金额大于可用余额，precheck_pass为false，precheck_issues中说明超出金额。”

4.3 风险评估节点的Skills挂载

风险评估节点不直接写提示词，而是挂载一个已经注册好的Skill。这个Skill叫“supplier_risk_assessment”，输入是供应商ID、采购金额、物料类别，输出是风险评级和建议。

Skill内部的处理逻辑分三步。第一步，调用MCP Tool查询供应商的历史数据，包括近12个月的交货准时率、质量退货率、合同履约情况。第二步，把这些数据和采购金额、物料类别一起送给大模型，让模型按预设的评分卡打分。第三步，把打分结果映射成风险等级，并生成一段给审批人看的建议。

评分卡的逻辑是这样的：交货准时率权重40%，低于90%开始扣分；质量退货率权重30%，高于2%开始扣分；合同履约权重20%，有违约记录直接扣20分；采购金额权重10%，金额越大风险容忍度越低。总分100分，80分以上为低风险，60到80为中风险，60以下为高风险。

这个评分卡不是拍脑袋定的，是跟客户的采购总监一起梳理出来的。他说他们内部判断供应商风险主要就看这几个维度，只是以前靠经验，现在把它量化了。这个梳理过程很重要，AI节点的判断逻辑必须跟业务方的实际决策逻辑对齐，否则AI说低风险、业务方觉得高风险，流程就卡住了。

4.4 人工审批节点的AI辅助展示

AI节点处理完的结果，要在人工审批节点展示给审批人看。JNPF支持在审批页面配置自定义展示组件。我把AI预审的问题列表和风险评估的评级做成了一个卡片，放在审批页面的顶部。

卡片的设计有讲究。预审问题用红色标签展示，每条问题后面跟一个“查看详情”的链接，点开能看到具体的规则依据。风险评估用颜色区分，低风险绿色、中风险黄色、高风险红色，旁边附上AI给出的建议。审批人如果不同意AI的判断，可以在卡片下方填写反对意见，这个意见会作为流程变量记录下来，用于后续优化Skill。

这个“反对意见记录”的机制很关键。AI的判断不可能100%准确，但每一次人工推翻AI的判断，都是一次宝贵的反馈。我定期把这些反对意见导出来分析，看看是提示词写得不够清楚，还是评分卡的权重需要调整。迭代几轮之后，AI判断的准确率会明显提升。

4.5 流程变量的完整传递链路

把整个流程的变量传递串起来看：发起节点产生form_data（包含部门、类别、金额、物料清单等）；AI预审节点读取form_data，调用MCP查预算，输出precheck_result；部门审批节点展示precheck_result，审批人确认后产生dept_approval；AI风险评估节点读取form_data和dept_approval，挂载Skill，输出risk_assessment；财务审批节点展示risk_assessment，审批人确认后产生finance_approval；采购执行节点读取所有前面的变量，生成采购订单。

每个节点的输出变量都要在流程定义里显式声明，不能隐式传递。JNPF的流程设计器里有个“变量映射”的界面，把上游节点的输出映射到下游节点的输入。这个映射关系要仔细检查，我遇到过因为变量名拼写不一致导致下游节点读不到数据的情况，排查起来很费时间。

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

5.1 AI节点超时或返回空值

这是最常见的问题。表现是流程走到AI节点卡住，或者AI节点直接跳过、下游节点拿不到数据。原因通常有三个：一是大模型接口响应慢，超过了流程引擎的超时设置；二是提示词太长，超出了模型的上下文窗口；三是MCP Tool调用失败，导致AI节点拿不到必要的输入数据。

排查顺序是这样的：先看流程日志里AI节点的执行记录，确认是超时还是报错。如果是超时，把流程引擎的超时时间从默认的30秒调到60秒，同时检查提示词是不是塞了太多无关内容。如果是MCP Tool调用失败，去MCP Server的日志里看具体的错误信息，常见的是认证过期或者参数格式不对。

我自己的经验是给AI节点加一个“降级策略”。在节点配置里可以设置“AI处理失败时”的行为：可以选择“跳过并继续”“转人工处理”“终止流程”。对于预审这种非关键节点，我一般设成“跳过并继续”，同时发一条通知给流程发起人，让他知道AI预审没跑成功。对于风险评估这种关键节点，设成“转人工处理”，让审批人多花点时间自己判断。

5.2 AI输出格式不符合预期

明明提示词里写了要输出JSON，AI偏偏给你返回一段带Markdown代码块的文本，或者JSON里多了一些没定义的字段。这个问题在早期版本里很常见，后来JNPF加了结构化输出约束之后好多了，但偶尔还是会出现。

我的处理办法是加一层“输出清洗”。在AI节点和下游节点之间，插一个“脚本节点”，用一段简单的JavaScript把AI的输出规范化。比如去掉Markdown的代码块标记、把字符串类型的数字转成数值类型、给缺失的字段填默认值。

// 输出清洗脚本示例 let raw = context.getVariable('ai_raw_output'); // 去掉可能的Markdown代码块标记 raw = raw.replace(/```json/g, '').replace(/```/g, '').trim(); let parsed; try { parsed = JSON.parse(raw); } catch (e) { // 解析失败时返回一个安全的默认值 parsed = { risk_level: 'medium', risk_score: 50, reasons: ['AI输出解析失败，请人工复核'], suggestion: '建议人工审核' }; } // 确保必要字段存在 parsed.risk_level = parsed.risk_level || 'medium'; parsed.risk_score = Number(parsed.risk_score) || 50; context.setVariable('risk_result', parsed);

这段脚本看起来简单，但能挡掉80%的格式问题。剩下的20%是模型本身的理解偏差，需要通过优化提示词来解决。

5.3 Skills修改后流程行为异常

前面提过版本管理的重要性，这里展开说排查方法。如果发现某个流程的AI行为突然变了，第一步是确认它引用的Skill版本有没有被改动。JNPF的流程日志里会记录每次AI节点执行时引用的Skill版本号，对比一下变更前后的版本号就能定位。

如果确实是Skill改动导致的，最快的恢复方式是把流程的Skill引用回滚到上一个版本。然后在测试环境里复现问题，确认是新版本的哪个改动引起的。我一般会在Skill的变更说明里写清楚“改了什么、为什么改、影响范围”，这样回滚的时候心里有数。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是提示词里用了“尽量”“最好”这类模糊词。比如写“尽量在3天内完成审批”，AI的理解是“3天左右都行”，结果有时候输出“建议5天内完成”。后来全部改成“必须在3天内完成”或者“如果超过3天则标记为超时”，输出就稳定了。

第二个坑是MCP Tool的返回数据格式不统一。有的Tool返回的是JSON对象，有的返回的是JSON字符串，有的甚至返回的是XML。AI节点拿到不同格式的数据，处理逻辑就要写很多分支判断。后来我定了一个规范：所有MCP Tool的返回必须是JSON对象，字符串类型的值必须用双引号包裹。统一之后省了很多事。

第三个坑是忽略了AI节点的并发限制。大模型接口通常有QPS限制，如果同时有大量流程实例走到AI节点，会触发限流。JNPF的流程引擎支持配置AI节点的并发数，我一般设成5到10，根据实际的大模型配额来调。设太高会触发限流，设太低会影响流程吞吐量。

6. 这套方案还能怎么扩展

6.1 从审批流程扩展到数据录入场景

AI节点不一定非要用在审批流程里。数据录入场景其实更适合AI介入。比如员工在表单里填写客户信息，AI可以实时校验手机号格式、自动补全行政区划、根据公司名称查询工商信息。这些操作以前要么靠前端正则校验，要么靠后端接口，现在可以统一用AI节点来处理。

我最近在做一个合同录入的场景。员工上传合同PDF，AI节点调用OCR的MCP Tool提取关键字段，然后用大模型判断合同类型、识别甲乙方、提取金额和期限，最后自动填充到表单里。员工只需要核对一下，不用手动敲几十个字段。这个场景的难点在于OCR的准确率，但即使OCR有少量错误，也比完全手动录入快得多。

6.2 从单点AI扩展到多Agent协作

现在每个AI节点是独立工作的，预审节点不管风险评估的事，风险评估节点也不关心预审结果。但在实际业务里，这些判断是有关联的。预审发现预算不够，风险评估就应该把“预算风险”纳入考量。

JNPF的流程引擎支持节点之间的变量传递，所以实现多Agent协作在技术上没有障碍。关键是在设计阶段就要想清楚：哪些判断应该放在一个节点里做，哪些应该拆成多个节点。我的原则是“一个节点一个职责”。预审就只管合规性检查，风险评估就只管供应商风险，两个节点的输出在人工审批节点汇总展示。这样每个节点的提示词可以写得很聚焦，维护起来也容易。

6.3 从人工配置扩展到自动优化

现在Skills的提示词和评分卡权重都是人工调的。未来可以做一个反馈闭环：把人工审批时推翻AI判断的记录收集起来，定期分析哪些场景下AI判断不准，然后自动调整提示词或权重。这个方向技术上可行，但需要积累足够多的反馈数据。我目前的建议是先把反馈记录机制建起来，数据攒够了再考虑自动优化。

6.4 一个实际扩展案例：AI辅助专利检索

有个做研发的客户，他们内部有个专利检索的流程。以前是研发人员自己写检索式，去专利数据库里查，查完人工筛选。现在他们用JNPF搭了一个流程：研发人员输入技术方案描述，AI节点调用专利数据库的MCP Tool做语义检索，返回相关专利列表，然后AI对每篇专利做相关性打分和摘要，最后生成一份检索报告。

这个场景里AI的价值不是“替代人做判断”，而是“把人从重复劳动里解放出来”。检索式怎么写、哪些专利相关、摘要怎么提炼，这些以前要花半天时间，现在AI几分钟就能出一版初稿，研发人员只需要在初稿上做增删改。效率提升非常明显。

7. 我个人的几点实操体会

第一，AI节点的提示词要当代码来管理。不要随手写在配置界面里就不管了，要像管理代码一样管理提示词：有版本号、有变更记录、有测试用例。我现在的做法是把提示词存在一个独立的文件里，通过JNPF的API导入，这样可以用Git做版本控制。

第二，不要追求AI判断100%准确。在业务流程里，AI的角色是“辅助”而不是“替代”。把AI的定位定成“帮审批人省掉80%的重复劳动”，而不是“帮审批人做决定”，心态会好很多，落地阻力也小很多。

第三，先从非关键流程开始试。不要一上来就把核心的财务审批流程交给AI。先找一个边缘的、出错了影响不大的流程，比如内部培训申请的审批，跑通了再往核心流程推广。这样即使出问题，也有时间和空间去调整。

第四，MCP Tool的粒度要适中。太粗了AI不好用，比如一个Tool叫“处理采购”，AI不知道具体要传什么参数；太细了调用次数太多，比如查供应商信息拆成查名称、查地址、查联系人三个Tool，AI要调三次。我的经验是一个Tool对应一个完整的业务动作，比如“查询供应商完整档案”就是一个合适的粒度。

第五，定期回顾AI节点的执行日志。我每个月会花半天时间，把上个月所有AI节点的执行记录导出来看一遍。重点看两类：一类是AI判断和人工判断不一致的，分析原因；另一类是AI节点报错或超时的，看看有没有共性。这个习惯帮我发现了好几个隐藏的配置问题。

这套东西说到底，核心不是技术有多复杂，而是思路要转变。低代码平台把“搭系统”的门槛降下来了，AI把“做判断”的门槛降下来了，两个降下来之后，真正稀缺的是“把业务逻辑翻译成AI能理解的规则”的能力。这个能力目前还得靠人，靠对业务的理解和对AI边界的认知。我见过太多团队卡在这一步，工具都有了，就是不知道怎么把业务规则拆成AI能执行的步骤。希望这篇东西能给正在这个阶段摸索的人一点参考。