低代码平台这几年铺得很快但大多数团队用下来的感受都差不多表单拖拽、流程画布确实省了前端工作量可一旦业务里出现需要判断需要生成需要理解语义的环节还是得回头写代码或者干脆把请求甩给一个外挂的对话窗口让用户自己复制粘贴。JNPF 这套低代码底座加上 AI 能力之后我最初也以为只是多了个聊天入口真正把它接进一条完整的业务链路跑通之后才发现价值根本不在能对话而在于 AI 变成了流程里的一个可编排节点——它能读表单数据、能调接口、能回写字段、能被条件分支拦住。这篇就把我从环境准备到全流程落地踩过的路完整讲一遍包括哪些环节必须用智能体、哪些用普通节点就够、MCP 到底解决了什么问题以及实测中那些文档里不会写的坑。1. 先搞清楚 JNPF 里 AI 到底以什么形态存在1.1 不是外挂对话框而是流程节点与数据源很多人第一次接触 JNPF 的 AI 能力习惯性去找一个AI 助手按钮点开发现是个聊天框于是得出结论哦就是个套壳问答。这个判断会让你后面完全走偏。在 JNPF 的体系里AI 能力实际以三种形态存在理解这三者是后续所有实操的前提。第一种是表单内的 AI 字段。你可以在表单设计器里给某个字段绑定 AI 生成逻辑用户填完前面的字段这个字段自动根据上下文生成内容。比如报销单里填了事由和金额AI 字段自动生成一段符合公司规范的说明文字。它不需要用户主动触发对话是静默执行的。第二种是流程中的 AI 节点。在流程画布上AI 节点和审批节点、条件节点是平级的。流程走到这里AI 拿到上游传过来的数据执行一次推理或调用把结果写进流程变量后面的条件分支再根据这个结果决定往哪走。这是深度嵌入最关键的一环。第三种才是智能体对话入口。它适合开放式交互场景比如制度咨询、辅助填报但它不是主力主力是前两种。提示如果你拿到 JNPF 后第一反应是找聊天框建议先去看流程设计器左侧的节点面板那里才是 AI 真正干活的地方。1.2 为什么节点化比对话框化重要举个具体场景你就明白了。假设要做一套合同风险初筛流程。对话框方案是这样的法务人员把合同内容复制出来粘贴到 AI 聊天窗口问这份合同有什么风险AI 给一段回答法务再自己判断要不要走审批。整个过程 AI 是个旁观者数据要人工搬运结果要人工判断流程系统完全不知情。节点化方案则是合同上传后进入流程AI 节点自动读取合同文本按预设的提示词做风险识别输出一个结构化结果比如风险等级、风险条款列表写回流程变量。紧接着一个条件节点判断风险等级为高直接流转到法务主管审批为中低流转到业务负责人确认即可。全程没有人工搬运AI 的判断直接驱动了流程走向。这两者的差别不是效率高一点低一点而是AI 是否成为了业务规则的一部分。前者 AI 是工具后者 AI 是流程的一个决策器官。JNPF 的 AI 能力真正的落地价值全在后者。1.3 智能体、MCP、大模型三者的分工热词里反复出现智能体、MCP、大模型很多人分不清。用一句话概括它们在这个体系里的角色大模型是大脑负责理解和生成但它不知道你公司的数据也碰不到你的系统。智能体是带着任务的大脑它把大模型和具体的提示词、工具、知识库绑在一起形成一个能完成特定任务的单元。MCP是手和脚它是一套让智能体能安全调用外部工具和数据的协议标准。在 JNPF 里落地时你的编排逻辑通常是流程节点触发 → 调用某个智能体 → 智能体通过 MCP 去查数据库或调接口 → 大模型基于返回结果推理 → 结果回写流程。三者缺一不可但普通业务人员只需要关心智能体这一层MCP 的配置通常由技术同学一次性搞定。2. 环境准备阶段最容易翻车的几个点2.1 模型接入别一上来就追求最强模型我见过不少团队项目还没跑通就先纠结用哪个大模型非要上参数最大的那个。实测下来这是典型的用力过猛。模型选型应该按任务类型分任务类型推荐模型档位理由字段内容生成、文本润色轻量模型响应快、成本低质量足够意图识别、分类判断轻量到中档这类任务对模型要求不高提示词写清楚就行复杂推理、多条件风险判断中高档需要较强的逻辑能力长文档理解、合同审查支持长上下文的模型上下文窗口不够会直接截断关键点是同一个流程里可以混用不同档位的模型。JNPF 的智能体配置允许你为每个智能体单独指定模型所以别用一个模型打天下。字段生成用轻量的风险判断用强的成本能降一大截。2.2 提示词不是写作文是写规格说明新手写提示词最大的问题是把它当作文写一堆请你认真仔细地分析。模型不吃这套。有效的提示词应该像一份规格说明包含四要素角色与边界你是谁你只做什么不做什么。输入说明你会收到什么数据字段含义是什么。输出格式必须输出什么结构用什么分隔。判断标准什么情况算高风险什么算低风险给出明确阈值。举个实际用的风险判断提示词片段你是合同风险初筛助手。你将收到一份合同正文。 请只输出 JSON不要输出任何解释文字。 格式{riskLevel: 高/中/低, reasons: [原因1, 原因2]} 判断标准 - 出现无限连带责任字样判为高 - 付款周期超过 90 天判为中 - 其余情况判为低输出格式强制成 JSON 这一点极其重要因为后面流程节点要解析这个结果。如果模型自由发挥输出一段话你的解析逻辑就崩了。2.3 MCP 连接配置一次配好处处复用MCP 的配置是技术门槛最高的一环但也是最值得投入的。它的核心作用是让智能体能调用外部能力比如查数据库、调内部接口、读文件。配置时要注意几个细节连接凭证不要硬编码在提示词里走平台的凭证管理否则换环境就废。每个 MCP 工具的能力边界要写清楚模型是根据工具描述来决定调不调的描述含糊它就会乱调或者不调。先单独测通再接入流程MCP 工具在流程里出问题很难排查一定要在智能体调试面板里先跑通。注意MCP 工具的描述文字会直接影响模型的调用决策描述里要明确什么时候该用我而不是只写我能做什么。3. 把 AI 接进业务流程的完整编排思路3.1 从业务动作倒推而不是从 AI 能力正推这是我最想强调的一条经验。很多团队做 AI 落地失败是因为他们的思路是我们有 AI 了看看能用在哪儿于是到处塞 AI结果每个点都不痛不痒。正确的思路是反过来先列出业务流程里那些需要判断、需要生成、需要理解非结构化信息的环节再看哪些能用 AI 解决。我通常会让业务方列一张表业务环节当前怎么处理是否适合 AI报销事由填写人工手写格式乱适合字段生成合同风险初筛法务人工看适合风险判断工单分类派发人工选分类适合意图识别金额计算公式计算不适合用公式节点审批签字人工决策不适合AI 不能替代责任这张表一列AI 该用在哪、不该用在哪就清楚了。能用规则和公式解决的绝不要用 AI因为 AI 有不确定性规则没有。3.2 一个完整的合同审查流程拆解我把前面提到的合同审查流程完整拆一遍你能看到 AI 节点是怎么和普通节点配合的。流程起点是合同上传。上传后第一个节点是文档解析节点普通节点把 PDF 或 Word 转成纯文本。这一步不能用 AI因为解析是确定性的活用专门的解析组件更稳。第二个节点是AI 风险判断节点。它接收解析后的文本调用前面配好的风险判断智能体输出 JSON 结果。这里要注意设置超时和重试模型偶尔会慢或者失败。第三个节点是结果解析节点普通节点。把 AI 输出的 JSON 解析成流程变量比如 riskLevel 和 reasons。为什么要单独一个节点因为 AI 节点的输出是文本直接拿去做条件判断容易出问题中间加一层解析更可靠。第四个节点是条件分支。根据 riskLevel 走不同路径。高风险走法务主管中风险走法务专员低风险走业务负责人。第五个节点是通知节点把 AI 给出的风险原因附在通知里让审批人知道 AI 为什么这么判。整个链路里AI 只出现在第二个节点但它决定了后面所有分支的走向。这就是深度嵌入的真实样子——AI 不抢戏但它在关键决策点上。3.3 智能体之间的协作什么时候需要多个智能体一个流程里往往不止一个 AI 环节。比如合同审查之后可能还要生成一份审查报告。这时候你有两个选择用一个智能体干两件事或者拆成两个智能体。我的经验是任务性质不同就拆开。风险判断是分类任务报告生成是生成任务两者的提示词、模型档位、输出格式都不一样硬塞进一个智能体只会让提示词变得又长又乱效果还差。拆成两个智能体各自专注维护起来也清晰。拆开之后流程里就是两个 AI 节点串联第一个输出风险结果第二个接收风险结果加上原文生成报告。它们通过流程变量传递数据不需要智能体之间直接通信这样耦合度最低。4. 实测中那些文档不会告诉你的坑4.1 模型输出不稳定JSON 解析失败的三种情况前面强调输出 JSON但实测中 JSON 解析失败是最高频的问题。我总结了三类原因和对策第一类是模型加了多余的话。比如输出好的以下是结果{...}。对策是在提示词里明确不要输出任何解释文字并且在解析节点里做容错用正则先提取花括号内容再解析。第二类是字段值里带了引号或换行。比如风险原因里写了甲方违约直接把 JSON 结构破坏了。对策是要求模型对字符串值做转义或者在解析前做预处理。第三类是模型输出了不存在的字段。比如你要 riskLevel它给你 risk_level。对策是在解析节点里做字段映射和默认值兜底别让一个字段名不一致就整条流程挂掉。提示解析节点一定要有兜底逻辑。AI 输出异常时流程应该走人工复核分支而不是直接报错中断。4.2 上下文长度长文档处理的截断陷阱合同、报告这类长文档很容易超过模型的上下文窗口。超了之后模型要么报错要么悄悄截断你拿到的是不完整分析但流程照常往下走这就很危险。对策有三层一是分段处理把长文档按章节切开每段单独分析最后汇总二是先摘要再分析用一次调用生成摘要再基于摘要做判断三是在流程里加长度校验节点超过阈值就走分段逻辑。我一般用分段加汇总的方案虽然多花一次调用但结果最可靠。分段时注意按语义边界切别在句子中间切否则模型理解会出问题。4.3 成本失控一个没加缓存的流程烧掉的钱这个坑我踩得最狠。有个流程每次触发都要调一次 AI而流程在测试阶段被反复触发一天下来调用量惊人。后来加了缓存才控制住。缓存的思路很简单相同输入不重复调用。把输入内容做哈希命中缓存就直接返回上次结果。对于合同审查这种场景同一份合同被多次审查的概率不低缓存命中率很可观。另外要设置调用频率上限和单次流程的 AI 调用次数上限防止死循环或者异常触发导致的成本爆炸。这些在 JNPF 的流程配置里都能设别嫌麻烦。4.4 权限与数据边界AI 能看的数据要划清楚AI 节点能读流程数据但不是什么数据都该让它读。比如合同里可能有敏感信息你把它传给外部模型就存在数据出域的风险。我的做法是在 AI 节点前加一个数据脱敏节点把身份证号、银行账号这类字段替换掉再传给模型。如果业务对数据边界要求极高就改用私有化部署的模型数据不出内网。这一点在落地初期容易被忽略但一旦出问题就是大问题建议在流程设计阶段就把它作为固定环节。5. 从单点试跑到全流程铺开的推进节奏5.1 第一个流程别选最复杂的很多团队想一步到位第一个流程就挑最核心最复杂的业务结果各种问题集中爆发项目直接卡死。我的建议是第一个流程选边界清晰、判断标准明确、出错影响可控的场景。比如工单自动分类就比合同审查更适合作为第一个流程。分类任务的判断标准相对客观输出就是几个类别解析简单就算分错了人工改一下就行不会造成实质损失。跑通之后再逐步上风险判断这类高价值但高难度的场景。5.2 建立 AI 输出的评估机制AI 不是百分百准的所以你必须知道它到底准不准。我的做法是抽样人工复核加准确率统计。流程跑一段时间后随机抽一批 AI 的判断结果和人工判断对比算出准确率。如果准确率不达标先别急着换模型八成是提示词的问题。把判断错误的案例拿出来分析看模型是在哪个判断标准上理解偏了针对性改提示词往往比换模型有效得多。评估要持续做因为业务在变模型的行为也可能随版本更新变化。建议每月做一次抽样评估把准确率作为流程健康度的一个指标。5.3 让业务人员参与提示词迭代这一点反直觉但很重要。提示词本质上是业务规则的表达而最懂业务规则的是业务人员不是技术。技术同学能写出格式正确的提示词但判断标准写得准不准得业务人员来把关。我的做法是让业务人员用自然语言描述判断标准技术同学负责把它翻译成结构化的提示词然后一起测试、一起改。这样迭代出来的提示词准确率明显比技术闭门造车高。6. 关于智能体与 MCP 的几个常见误解6.1 智能体不是越复杂越好有人觉得智能体要配一堆工具、挂一堆知识库才显得高级。实测恰恰相反工具越多模型越容易乱调。一个智能体最好只解决一类任务工具控制在必要的几个。需要多种能力时拆成多个智能体用流程串起来比堆在一个智能体里清晰得多。6.2 MCP 不是必须的MCP 解决的是智能体调用外部能力的问题。如果你的 AI 节点只需要基于流程内已有的数据做推理根本不需要 MCP。别为了用而用先问自己这个智能体需要访问流程之外的数据或系统吗不需要就别配 MCP。6.3 大模型不是越新越好新模型发布时很多人第一时间切换。但新模型的行为可能和旧模型有差异你调好的提示词可能就不灵了。生产环境的模型切换要谨慎先在小范围测试确认效果稳定再全量切。稳定比先进重要。7. 我个人的几条实操心得跑完几个流程之后有几条经验是我觉得最值钱的分享出来。第一AI 节点的位置比 AI 的能力更重要。同样一个风险判断智能体放在流程开头和放在关键决策点价值完全不同。花时间想清楚 AI 该在流程的哪个位置介入比纠结用哪个模型收益大得多。第二给 AI 的输出留人工兜底的口子。再准的 AI 也有出错的时候流程设计上一定要有AI 判断存疑时转人工的路径。这不是对 AI 不信任而是对业务负责。第三把 AI 当流程里的一个普通节点来对待。它和审批节点、条件节点没有本质区别都是接收输入、处理、输出。用这种心态去编排你会发现整个流程反而更清晰不会因为这是 AI就特殊对待。第四先跑通再优化。别在第一个流程上追求完美先把链路跑通拿到真实数据再根据数据去优化提示词、调整模型、加缓存。空想优化方向不如跑一遍看真实问题在哪。最后再补一个小技巧调试 AI 节点时把每次的输入和输出都记下来存成一个日志表。出问题时翻日志比重新跑一遍流程快得多而且能看出模型行为的变化趋势。这个习惯帮我省了大量排查时间。