openJiuwen智能体平台完成投保工作流全链路调测

本文使用最新的v0.1.3版本openJiuwen作为开源Agent平台，致力于提供灵活、强大且易用的AI Agent开发与运行能力。基于该平台，开发者可快速构建处理各类简单或复杂任务的AI Agent，实现多Agent协同交互，高效开发生产级可靠AI Agent；并助力企业与个人快速搭建AI Agent系统或平台，推动商用级Agentic AI技术广泛应用与落地。面向消费者和企业场景，openJ

2301_77888392

41人浏览 · 2026-03-04 12:16:33

2301_77888392 · 2026-03-04 12:16:33 发布

一、为什么需要智能体？

传统AI模型（比如早期的问答系统）像一个“静态百科全书”——你问，它答；不问，它不动。而智能体不一样，它具备：

‌目标驱动‌：能自己拆解任务、规划步骤，比如“订机票+订酒店+发邮件通知同事”这一连串动作，它能自动完成。
‌环境感知‌：能获取上下文信息，比如时间、位置、用户习惯，甚至外部API数据，来调整行为。
‌持续行动‌：不是一问一答，而是可以多轮交互、试错、反馈、调整策略，直到达成目标。
‌记忆与学习‌：能记住历史交互，优化后续决策，越用越懂你。

智能体（Agent）存在的根本原因，是为了让人工智能系统更主动、更灵活地应对复杂、动态的现实任务。随着人工智能的不断发展，大语言模型技术日益成熟。AI应用已经从最初专注于语音识别等简单任务的应用，演进到能够进行自主推理决策，完成复杂任务的Agent。基于大语言模型的AI Agent，具备自主性、目标导向性和交互性，能够在复杂多变的环境中感知信息、推理决策并执行任务。在各个行业场景中，AI Agent都展示出巨大的应用潜力，广泛应用于客户支持、销售拓展、医疗诊断和金融分析等场景。

今天给大家带来一个openJiuwen作为开源Agent平台，致力于提供灵活、强大且易用的AI Agent开发与运行能力。本文章主要开发一个智能投保系统，帮助客户自助验证是否有投保的资格提供智能的检索，介绍如何使用 openJiuwen 开源平台，快速搭建并部署一个具备智能投保业务识别与验证能力的AI智能体（Agent）。

我们将以构建一个“智能投保咨询助手”智能体为例，完整演示从模型搭建配置、工作流（Workflow）编排到智能体集成与测试的全过程。openJiuwen 通过可视化的界面，极大地降低了复杂AI应用逻辑的开发门槛，是构建智慧咨询助手、智能客服、多业务协同问答机器人的强大工具。

二、什么是openJiuwen?

本文使用最新的v0.1.3版本

openJiuwen作为开源Agent平台，致力于提供灵活、强大且易用的AI Agent开发与运行能力。基于该平台，开发者可快速构建处理各类简单或复杂任务的AI Agent，实现多Agent协同交互，高效开发生产级可靠AI Agent；并助力企业与个人快速搭建AI Agent系统或平台，推动商用级Agentic AI技术广泛应用与落地。

在这里插入图片描述

面向消费者和企业场景，openJiuwen提供了快速搭建AI Agent应用的能力，助力个人和企业提升开发效率、执行准确率和系统性能。

2.1 面向企业的应用场景

企业可利用openJiuwen的工作流引擎和多Agent协同能力，快速搭建、部署并高效执行各类Workflow Agent，实现复杂任务的自主规划、分解与执行，显著降低技术落地成本，助力企业加速智能体商业化落地。

金融行业：通过多Agent协同能力，实现多级意图跳转、智能化的任务分配和动态的Agent调度，助力金融机构构建出具有高精度、低时延、高可靠性和强安全性的一体化服务能力。
医疗健康：支持自定义开发医疗智能体，高效生成病历摘要、进行影像资料的初步筛查，并提供诊疗建议。深度整合专业医学知识和上下文信息，为医生提供精准、全面的辅助决策支持，有效提升诊断效率与准确率。

2.2 openJiuwen平台的关键优势包括：

全场景适配：面向ToB与ToC的全场景设计，满足企业和个人在不同应用场景下的需求。
灵活的开发方式：提供零代码、低代码和使用SDK等多种开发方式，帮助用户根据需求和技术背景自由选择开发方式。
高效精准的任务执行：确保AI Agent在执行任务时的高效性与精准性，优化任务处理流程，提升工作效率。
多Agent协同能力：支持Multi-Agent的协同工作，能够处理复杂的业务流程和跨领域任务，提升整体效率。
稳定的生产环境支持：提供商用级稳定性与高可用性，确保在大规模生产环境中的可靠运行，助力企业和个人快速实现商用级Agentic AI技术的落地应用。

在这里插入图片描述

三、开发工作流：

openJiuwen工作流通过可视化编排帮助用户快速构建和管理流程型Agent，实现业务流程自动化。平台支持零代码用户通过拖拽式界面完成流程搭建，同时为低代码用户提供代码执行、插件调用和条件分支等功能，满足复杂场景需求。广泛应用于目标任务包含多个复杂步骤、对输出结果成功率和准确率有严格要求的复杂业务场景，助力企业实现数字化转型与智能化升级。

【构建投保资格验证工作流】：

工作流是openJiuwen比较重要组成部分，它将多个处理节点通过逻辑连接起来，形成一个完整的处理通道，将构建一个通过输入用户名和身份证ID号码和是否有疾病，来自动关联大模型搜索疾病是否可以投保，通过插件调用POST请求是否可以投保进行智能应答的工作流。

首先我们在"智能体开发"的菜单中，先要点击一下"创建智能体"按钮：

在这里插入图片描述

接下来需要填写一些相关的信息，比如：

智能投保咨询助手
通过对用户信息分析是否能够满足投保的需求

在这里插入图片描述

添加完成后，会到一个智能的可视化操作的页面中，我们先将模型进行添加，这里是使用DeepSeek-V3的模型，因为在投保校验里面的流程很多，所以，一般会使用到工作流用来定制化一些流程性的操作，这里可以在"工作流"中添加"创建新工作流"的模块：

在这里插入图片描述

3.1 openJiuwen工作流介绍：

工作流有多个组件构成，组件是构成工作流的基本单元，如大模型组件、插件组件、代码组件等。创建工作流时，工作流默认包含了开始和结束组件。开发者可基于该工作流，添加更多的组件，实现业务流程的编排。每个组件需要配置不同的参数，如输入和输出参数配置、组件配置等。

使用工作流的步骤如下：

构建工作流。
配置组件：配置在工作流中添加的组件，并将它们按业务顺序链接。
调试运行工作流。
调试成功后，可以发布工作流，也可以将工作流导出。

本章将详细介绍如何在工作流编辑器中创建、配置和连接工作流组件，帮助用户快速构建结构清晰、逻辑正确的工作流流程。

openJiuwen 工作流提供了一个功能丰富的可视化流程设计器，支持直观的拖拽操作与智能连线配置：用户可轻松将各类组件拖放到画布上进行自由布局，系统会自动检测连接的有效性以确保流程逻辑正确；同时支持实时预览执行效果、自定义调整组件位置、画布缩放与平移，并提供撤销/重做功能以便灵活修改，还支持复制粘贴，便于高效复用已有组件和流程结构。

这里可以看到系统自带是有一些工作流了，那么如何来定制化一些属于自己的工作流呢？首先在「工作流编排」页面中，您将看到一个工作流列表。单击页面右上角的「创建工作流」按钮，开始新建一个工作流。

在这里插入图片描述

我们在下面工作流的基本信息输入相关的信息：

工作流名称：一个具有描述性的名称，仅支持字母、数字、下划线，且只能以字母开头（ insuranceVerification）
工作流描述：一段简要的描述，说明该工作流的主要功能和应用场景（投保全流程验证工作流）

在这里插入图片描述

3.2 工作流添加节点：

添加组件：用户可以通过拖拽的方式，将所需的组件从组件库中添加到画布上。每个组件代表一个特定的功能节点，例如工作流、输入输出、业务逻辑等。

【开始节点】

作用：是openJiuwen工作流的唯一入口，接收用户输入的内容。例如：“我想进行投保，需要什么样的信息呢？”。
配置：定义输入变量名，如 query。
开始节点在投保检查场景中扮演着智能保险顾问系统的"第一道门"角色。当用户发起投保咨询时，这个节点需要具备精准的语义理解能力，能够识别用户是想了解投保流程、查询保险产品、还是进行资格预审。例如当用户询问"我有高血压还能买重疾险吗？"时，开始节点不仅要捕获这个健康相关的投保咨询，还要初步判断这属于疾病核保范畴。

完成信息填写后，单击「创建工作流」按钮，系统将自动生成一个唯一的工作流ID，并自动跳转至工作流的编辑界面。此时，用户可以开始构建具体的工作流逻辑。

【思考方案】：
因为在提问的时候，肯定涉及到收集用户的名称、身份证ID号码、既往得到哪些疾病(有些疾病是不适合投保的)，所以，我们选择的第一个节点就是"输入"节点，可以用于在工作流执行过程中暂停并等待用户输入。

确保关键信息的准确获取：在保险投保等场景中，需要收集用户的关键身份信息（如姓名、身份证号）和健康状况（如既往疾病史），例如判断是否适合投保。
实现流程的交互与控制：允许系统在特定步骤暂停，等待用户的响应或输入。这使得流程可以根据用户的实际回答动态调整后续的处理逻辑，例如，如果用户报告了某些特定疾病史，系统可以据此触发额外的审核或拒绝流程，增强了流程的灵活性和可控性。

在这里插入图片描述

添加完成后，我们可以在输出这里，添加3个字段：

username：表示用户的姓名，是string类型，而且是必填选项
idnumber：表示用户的身份证ID号码，是string类型，而且是必填选项
disease：表示用户是否存在疾病，是string类型，这里是非必填选项，有些人也可以不填写

在这里插入图片描述

3.3 全流程Debug调制一下节点作业的效果呢？

上面添加了一个节点，作为强迫症的我，直接就想来看看实际的效果，别假把式，光学不练假把式，接下来我们将所有的节点进行串联成一个闭环的回路，在最下面点击"试运行"。

在这里插入图片描述

在工作流编辑界面中，单击「试运行」按钮，进入测试运行模式。该模式下，系统将模拟工作流的执行环境，但不会对真实数据或外部系统产生影响，这里会有一个右边的弹框出来，从第一个节点"开始"运行，然后点击"运行"就到了下一个节点的操作。

在这里插入图片描述

接下来就到了"输入"的节点了，这里我们看到在输入的过程中，“输入"节点已经阻塞了，需要等待输入完后才能进行执行，这里我们输入一些信息后，就可以点击"继续执行”：

在这里插入图片描述

最后，这个工作流调试就完成了，我们可以看到在每个节点的下面都有一些输入参数、输出结果，这样就可以全方位友好的进行各个节点的数据流调试与分板，哪里的预期没有达到理想的效果，就可以继续改进。

在这里插入图片描述

输入测试数据：在弹出的测试配置界面中，填写工作流所需的输入参数。这些参数可以是模拟数据，也可以是真实场景中的示例数据，确认输入无误后，单击「运行」按钮，系统将按照工作流定义的逻辑开始执行。执行过程中，用户可以实时查看每个节点的执行状态和数据流转情况。

3.4 添加选择器节点进行分支判断：

选择器组件用于连接多个下游分支，通过设定条件来控制工作流的执行路径。只有满足设定条件的对应分支才会被执行，等同于程序开发中的if-else条件判断节点。该组件可帮助开发者构建复杂的分支逻辑，适用于需要根据不同条件执行不同流程的场景。

条件判断基于工作流执行时的上下文数据，确保引用的变量可用。
当多个条件同时满足时，只有第一个满足条件的分支才会被执行。
建议为选择器组件配置默认分支，以处理所有条件都不满足的情况。

在这里插入图片描述

在添加"选择器"节点后，我们可以将disease疾病字段判断为不为空时，需要把这个疾病拿到大模型中去搜索一下，是否在医保范围内。

在这里插入图片描述

大模型组件是 openJiuwen 提供的核心功能模块，用于接入大型语言模型（LLM），通过用户输入和定制化提示词，灵活生成符合特定角色、语气或格式要求的高质量自然语言响应，适用于创意写作、信息提炼等多种文本处理场景，并支持对生成参数进行精细调节以优化输出效果。

接下来，我们可以添加一个大模型的节点，这样，将input值改为疾病的字段，再给出一个比较基础的系统提示词：

帮我分析一下这个疾病在不在医保的范围内，最后返回的数据一定是要固定的格式
{
  result: 布尔值
}

在这里插入图片描述

再通过AI可以友好的生成更好的提示词：

## 人设
医保政策分析师  
具备医保政策解读和疾病分类的专业知识，能够准确判断疾病是否在医保范围内。

## 任务描述
分析用户提供的疾病名称，判断该疾病是否在当前医保目录范围内，并返回固定格式的结果。  
目标是为用户提供准确的医保覆盖信息，帮助其了解医疗费用报销可能性。

## 约束条件
1. 仅分析中国大陆现行医保政策（{{年份}}版）
2. 疾病名称需为标准医学术语（ICD-10编码优先）
3. 必须按照<输出格式>返回JSON格式结果
4. 若疾病名称存在歧义，需按最接近的医保目录条目判断
5. 按照<执行步骤>逐步验证

## 执行步骤
1. 接收用户输入的疾病名称/ICD-10编码
2. 标准化处理疾病名称（去除修饰词、统一术语）
3. 查询国家医保药品目录（{{版本号}}）
4. 核对疾病诊断相关分组(DRG)标准
5. 匹配医保三大目录（药品/诊疗项目/服务设施）
6. 生成最终判断结果

## 输出格式
```json
{
  "result": {{布尔值}}
}
```

参数	说明
输入	用于向提示词中注入动态内容的变量集合。每个输入参数需指定参数名和对应的变量值，变量值可以是固定值，也可以引用上游组件的输出结果。系统提示词和用户提示词均可通过变量引用语法使用这些参数，从而实现内容的动态调整。
模型选择	指定执行任务所使用的大语言模型。模型的能力直接影响组件的输出质量，应根据具体应用场景（如文本生成、摘要、推理等）选择最合适的模型。
系统提示词	用于定义模型在对话中的角色定位、行为准则和回复风格。支持使用变量引用语法动态插入输入参数的内容，以增强提示的灵活性和上下文适应性。
用户提示词	表示当前轮次用户向模型发出的具体指令或问题。该字段支持引用输入参数中的变量，使提示内容能够根据运行时数据动态变化，提升交互的针对性和准确性。
输出	设置输出的参数名和描述。清晰的参数名称和描述有助于模型准确返回匹配的内容。当存在多个输出参数时，建议使用有意义的参数名并添加详细的描述信息。

角色定位设定了“医保政策分析师”这一角色：

这个角色专注于医保政策解读的专业角色，意味着输出必须基于现行制度，而非临床判断。
优势在于：能有效规避医疗建议风险，聚焦于“是否可报销”这一具体问题，符合合规要求。
潜在挑战是：现实中医保政策具有地域差异（如省级目录调整）、动态更新（每年调整），这里在真正方案的实施上建议加上知识库。

执行步骤与数据链闭环：

设计的流程从输入到输出形成了完整的逻辑闭环：

接收输入
术语标准化‌（关键！避免“感冒”“着凉了”这类口语化表达干扰判断)
查目录‌（核心依据）
核DRG‌（住院费用相关，体现专业深度）
匹配三大目录‌（药品、诊疗、服务设施，全面覆盖报销场景）
输出结果

输出格式（固定JSON结构）

要求输出为：

{"result": true}

这种强约束格式非常适合下游系统自动解析，比如用于触发后续的投保通过/拒保流程、费用估算模块等。

布尔值的设计简洁高效，适合做条件判断。

3.5 如何进行单个节点的测试？

我们可以点击每个节点上面的右侧三角形图标，可以进入本个节点的测试：

在这里插入图片描述

那么，我们可以通过输入"肺癌"运行后，可以看到肺癌肯定是不能进行投保的。

在这里插入图片描述

1. 利用平台内置的“单节点调试”功能，实现快速验证：

主流智能体开发平台（如openJiuwen）通常为关键节点提供独立调试入口。你、可以在节点详情页右上角找到“调试”按钮，点击后进入独立测试窗口。
在此界面中，你可以：

填写该节点所需的必填输入参数
模拟API参数或上下文变量
实时查看该节点的输出结果
这种方式让你无需运行整个工作流，就能快速验证逻辑正确性，特别适合高频迭代的场景。

2. 关注输入输出的结构化与边界情况处理：

调试不只是“能不能跑通”，更要思考“是否健壮”。需要主动测试以下情况：

输入为空、null、格式错误时，节点是否有合理响应？
输出是否严格符合下游期望的JSON结构？例如{“result”: true}中的布尔值不能是字符串
建议在调试时准备多组测试数据：正常值、边界值、异常值，确保节点具备足够的容错能力。

3.6 工作流中如何添加一个数据库请求的插件：

因为在我们的业务设计中，是需要检查一些人的投保资格的，有些人可能是不符合一些投保的资格的，所以，一般是需要通过一个接口请求来验证是否符合要求，如下为系统中存在的校验接口，为一个POST请求的接口，传入一些参数：

name：用户的名字
id：用户的身份证ID

那么我们可以先通过postman的接口来验证一下，可以看到以下是请求成功了，并且给我们返回了一些数据，结果中的result字段表示是否有投保的资格。

特殊说明：以下使用的李忢为随便输入的信息，自己测试时，可以使用自己的用户信息

{
    "code": 0,
    "message": {
        "name": "李忢",
        "id": "312938423121321321321",
        "result": true   // 表示是否有投保的资格
    }
}

在这里插入图片描述

接下来我们在"插件管理"中，新建一个插件用来进行POST请求：

在这里插入图片描述

在"工具设置"中，我们添加一个新的代码工具，使用的环境是Node.js的，为了方便我们通过代码来实现请求POST接口返回是否符合投保资格。

在这里插入图片描述

接下来添加2个输入的参数，分别为name与id，表示用户的名称与用户的身份证ID号码，并且2个参数都是需要必选：

在这里插入图片描述

并且设置一下输出的参数，是一个result的对象，返回的类型数据结构是：

{
  result: {
    "code": 0,
    "message": {
      "name": "李忢",
      "id": "312938423121321321321",
      "result": false
    }
  }
}

在这里插入图片描述

接下来就是实现请求的代码业务逻辑，这里是请求服务器API接口的核心业务代码：

function tokenize(cmd) {
  const s = String(cmd || "")
    .replace(/\\\s*\r?\n/g, " ")
    .trim();
  const out = [];
  let buf = "";
  let quote = null;
  let esc = false;
  for (let i = 0; i < s.length; i++) {
    const ch = s[i];
    if (esc) {
      buf += ch;
      esc = false;
      continue;
    }
    if (quote === null && ch === "\\") {
      esc = true;
      continue;
    }
    if (quote !== null) {
      if (ch === quote) {
        quote = null;
        continue;
      }
      buf += ch;
      continue;
    }
    if (ch === "'" || ch === "\"") {
      quote = ch;
      continue;
    }
    if (/\s/.test(ch)) {
      if (buf.length) out.push(buf);
      buf = "";
      continue;
    }
    buf += ch;
  }
  if (buf.length) out.push(buf);
  return out;
}

function parseCurl(cmd) {
  const tokens = tokenize(cmd);
  const t = tokens[0] === "curl" ? tokens.slice(1) : tokens.slice();

  let url = null;
  let method = null;
  const headers = {};
  const dataParts = [];

  const clean = (s) => String(s || "").trim().replace(/^`+|`+$/g, "");
  const appendHeader = (k, v) => {
    const key = String(k || "").trim();
    const val = String(v || "").trim();
    if (!key) return;
    if (headers[key]) headers[key] = `${headers[key]}; ${val}`;
    else headers[key] = val;
  };

  const takeNext = (i) => {
    if (i + 1 >= t.length) throw new Error("curl 参数缺少值");
    return t[i + 1];
  };

  for (let i = 0; i < t.length; i++) {
    const a = t[i];
    if (a === "\\") continue;
    if (a === "-X" || a === "--request") {
      method = String(takeNext(i)).toUpperCase();
      i++;
      continue;
    }
    if (a === "-H" || a === "--header") {
      const hv = clean(takeNext(i));
      i++;
      const idx = hv.indexOf(":");
      if (idx > 0) {
        const k = hv.slice(0, idx).trim();
        const v = hv.slice(idx + 1).trim();
        appendHeader(k, v);
      }
      continue;
    }
    if (a === "-b" || a === "--cookie") {
      const cookie = clean(takeNext(i));
      i++;
      appendHeader("Cookie", cookie);
      continue;
    }
    if (a === "-d" || a === "--data" || a === "--data-raw" || a === "--data-binary" || a === "--data-ascii") {
      const dv = clean(takeNext(i));
      i++;
      dataParts.push(dv);
      continue;
    }
    if (a === "--url") {
      url = clean(takeNext(i));
      i++;
      continue;
    }
    const aa = clean(a);
    if (aa.startsWith("http://") || aa.startsWith("https://")) {
      url = aa;
      continue;
    }
  }

  if (!method) method = dataParts.length ? "POST" : "GET";
  const body = dataParts.length ? dataParts.join("&") : null;

  const headersJson = JSON.stringify(headers, null, 2);
  const urlLiteral = JSON.stringify(url || "");
  const methodLiteral = JSON.stringify(method);

  let fetchCode = "";
  fetchCode += `const url = ${urlLiteral};\n`;
  fetchCode += `const options = {\n`;
  fetchCode += `  method: ${methodLiteral},\n`;
  if (Object.keys(headers).length) {
    fetchCode += `  headers: ${headersJson.replace(/\n/g, "\n  ")},\n`;
  }
  if (body !== null) {
    fetchCode += `  body: ${JSON.stringify(body)},\n`;
  }
  fetchCode += `};\n\n`;
  fetchCode += `fetch(url, options)\n`;
  fetchCode += `  .then((res) => res.text())\n`;
  fetchCode += `  .then((text) => console.log(text))\n`;
  fetchCode += `  .catch((err) => console.error(err));\n`;

  return {
    url,
    method,
    headers,
    body,
    fetch: fetchCode,
  };
}

function main(args) {
  /**
   * 主要处理函数
   */
  const params = (args && args.params) || {};
  const curl = params.name || params.command || "";
  if (!curl) {
    return {
      result: {
        "code": 0,
        "message": null
      }
    };
  }

  const parsed = parseCurl(String(curl));
  return {
    result: {
      "code": 0,
      "message": parsed
    }
  };
}

module.exports = { main };

if (require.main === module) {
  const cmd = process.argv.slice(2).join(" ").trim();
  const input = cmd || "curl http://xxxx.tech:3000/checkId";
  console.log(main({ params: { curl: input } }));
}

接下来最后就是插件的测试，我们可以通过输入用户名参数与身份证ID号码，点击"执行测试"后，可以看到我们的插件执行成功了，返回了结果：

{
  "result": {
    "code": 0,
    "message": {
      "name": "李忢",
      "id": "312938423121321321321",
      "result": false
    }
  }
}

在这里插入图片描述

测试成功后，我们就可以直接添加一个"插件"的节点：

在这里插入图片描述

将入参数的用户名与用户身份证ID进行节点的绑定：

在这里插入图片描述
整个流程围绕「将外部投保资格校验接口封装为工作流可调用的插件」展开，核心是把独立的API能力融入智能体工作流，具体分为6个核心阶段：

1. 接口预验证

背景：业务需要校验用户投保资格，依赖外部POST接口（入参：name/身份证id，出参：result字段标识是否符合资格）。
操作：先通过Postman工具调用该POST接口，传入测试参数（如name=李忢+测试身份证ID），验证接口能否正常响应、返回包含result字段的有效数据，确保接口本身可用后再进行集成。

2. 插件初始化：新建插件载体

操作：在系统的「插件管理」模块中，新建一个专门用于「投保资格校验」的插件，作为封装接口调用能力的载体。

3. 工具基础配置：确定运行环境

操作：进入插件的「工具设置」，选择Node.js作为运行环境，为后续编写接口请求的业务逻辑提供执行环境。

4. 参数标准化：定义输入输出规则

这一步是插件能和工作流其他节点联动的核心，需明确「插件要接收什么、返回什么」：

输入参数：添加2个必填参数（name：用户姓名、id：用户身份证ID），确保调用插件时能获取校验所需的核心信息；
输出参数：定义固定结构的result对象作为输出，规范返回格式（包含code、message，message里需回传传入的name/id，以及核心的result字段标识投保资格）。

5. 核心逻辑封装：实现接口调用

操作：在插件中编写业务代码（核心是实现调用外部投保资格校验API的逻辑），让插件具备「接收输入参数→发起POST请求→获取接口返回结果→按预设格式封装输出」的能力。

6. 插件验证：确保功能可用

操作：在插件界面输入测试用的name和id参数，点击「执行测试」，验证插件能否成功调用接口、返回符合预设格式的结果（重点检查result字段是否正确），确认插件功能正常。

7. 最终集成：

操作：测试通过的插件可作为独立节点添加到智能体工作流中，与其他节点（如用户信息输入节点、后续业务处理节点）联动，实现「获取用户信息→调用插件校验投保资格→根据校验结果执行后续逻辑」的完整业务闭环。

总结：

1. 核心目标：将外部投保资格校验的POST接口封装为工作流可调用的插件，扩展智能体的业务校验能力；
1. 关键步骤：先验证接口有效性→创建插件并配置运行环境→定义输入输出参数→封装接口调用逻辑→测试插件→集成到工作流；

3.7 如何进行多个节点的返回值聚合输出：

代码组件是工作流设计中的自定义数据处理组件，专为工作流开发者设计，用于在需要对工作流数据进行个性化处理的场景下，满足数据转换、逻辑计算、格式整理等自定义数据处理需求。它通过支持运行自定义的 Python 或 JavaScript 代码，对上游组件传入的输入参数进行个性化处理，并返回处理后的结果供下游组件调用，从而灵活拓展工作流的数据处理能力。

单击在画布上出现的代码组件即可开始配置代码组件，选择输入参数，设置为上游组件的参数，选择代码类型，目前支持 Python 和 JavaScript。

在这里插入图片描述

function main(args) {
  const LLM_input = args.params.input1;
  const POST_data = args.params.input2;
  let result = '恭喜您，可以投保';
  if (LLM_input && LLM_input.includes('true')) {
    result = '非常抱歉，由于' + args.params.input3 + '不能投保'
  }
  if (POST_data && POST_data.code == 0) {
    if (POST_data.message.result) {
      result = '对不起，投保校验不合法'
    }å
  }
  return {
    result
  };
}

在这里插入图片描述

这样的话，就可以把多个节点的返回值聚合在一起，通过逻辑处理给出统一的返回值。

在智能体工作流中，通过「代码组件」聚合多个上游节点的返回值、经自定义逻辑处理后输出统一结果的完整业务流程，聚焦业务逻辑而非代码实现。

完整业务流程梳理：整个流程核心是“聚合多节点数据→按业务规则处理→输出统一结果”，具体分为5个核心阶段：

1. 业务背景：

场景：工作流中多个上游节点（如LLM大模型节点、投保资格校验POST接口节点）会产生不同维度的返回值，业务需要将这些分散的结果整合，并根据预设规则判断，最终输出一个统一、易懂的结论（如“可投保/不可投保”）。
目标：解决多节点返回值分散、格式不统一的问题，通过自定义逻辑输出符合业务预期的标准化结果。

2. 组件部署：添加代码组件作为聚合节点

操作：在工作流画布中添加「代码组件」，将其作为专门处理“多节点数据聚合+逻辑判断”的核心节点，放置在所有需要聚合的上游节点之后、下游输出节点之前。

3. 参数关联：绑定上游节点的返回值

操作：配置代码组件的输入参数，将每个参数与对应上游节点的返回值一一绑定（比如：input1绑定LLM节点的返回值、input2绑定POST接口节点的返回值、input3绑定补充说明类节点的返回值），确保代码组件能获取到所有需要聚合处理的数据源。

4. 环境与逻辑配置：定义聚合规则

第一步：选择代码运行环境（Python或JavaScript），适配开发者的技术习惯；
第二步：基于业务规则定义聚合逻辑（无需关注代码语法，核心是逻辑规则）：
- 先设定默认结果（如“恭喜您，可以投保”）；
- 依次判断各上游节点的返回值：若LLM节点返回值包含特定标识（如“true”），则返回“因XX原因不能投保”；若POST接口节点返回值符合校验不通过条件（如result=false），则返回“投保校验不合法”；
- 最终输出唯一的统一结果。

5. 结果输出与验证：联动下游并测试

操作：将代码组件的输出结果关联到工作流的结束节点（或下游业务节点），确保统一结果能被后续流程调用；
验证：运行工作流并传入测试数据，检查代码组件是否能正确聚合所有上游节点的返回值、按预设逻辑输出符合预期的统一结论。

四、调试的结果：

在调试的过程中发现，有一个报错一直过不去：

错误 203029: 选择器组件[condition_boWnn]: [选择器] 分支条件值不能为空js错误 203029: 选择器组件[condition_boWnn]: [选择器] 分支条件值不能为空

在这里插入图片描述

发现不能使用为空进行判断，临时修改判断只要有"病"字就走LLM大模型判断。

4.1 无疾病但是投保校验通过：

用户无疾病（disease 字段不含 “病” 字）且投保校验接口返回 “通过 / 合法” 场景下的完整执行逻辑、流程路径和最终输出结果。

前提定义（无疾病 + 投保校验通过）

无疾病：input_KYCwF 节点的 disease 字段内容不含 “病” 字（如为空、“健康”、“无异常” 等）；
投保校验通过：plugin_qwGxY 节点调用 POST 接口后，返回的 data.result.message.result 为 false（结合代码逻辑，该值为 true 时代表校验不合法，反之则合法），且接口请求成功（error_code=0）。

start_AxbRc（开始）→ input_KYCwF（输入）→ condition_boWnn（选择器）→ plugin_qwGxY（投保插件）→ code_Z9IWu（代码聚合）→ end_AxbRc（结束）

核心执行路径：开始→输入→选择器（无病分支）→投保插件→代码聚合→结束，全程不触发大模型节点；
逻辑核心：选择器的 “含病” 判断决定是否走医保分析分支，投保插件的校验结果决定是否覆盖默认成功提示；
最终结果：因无疾病且投保校验通过，代码节点保留初始值，结束节点输出 “恭喜您，可以投保”。

4.2 无疾病但是投保校验不通过：

用户无疾病（disease 字段不含 “病” 字）但投保校验接口返回 “不通过 / 不合法” 场景下的完整执行逻辑、流程路径和最终输出结果。

无疾病：input_KYCwF 节点的 disease 字段内容不含 “病” 字（如为空、“健康”、“无异常” 等）；

投保校验不通过：plugin_qwGxY 节点调用 POST 接口后，返回数据满足两个条件：

接口请求成功（error_code=0）；
核心校验字段 data.result.message.result = true（代码逻辑中该值为true代表校验不合法）。

start_AxbRc（开始）→ input_KYCwF（输入）→ condition_boWnn（选择器）→ plugin_qwGxY（投保插件）→ code_Z9IWu（代码聚合）→ end_AxbRc（结束）

核心执行路径：无疾病场景下，流程仅走 “输入信息→投保校验→结果聚合”，完全跳过医保政策分析大模型；
核心判断逻辑：投保校验的最终结果由接口返回的 message.result 决定（true= 不通过，false= 通过）；
最终输出结果：因投保校验不通过，工作流最终返回 “对不起，投保校验不合法”。

4.3 有疾病且不在投保范围内：

用户有疾病（disease字段含 “病” 字）且该疾病不在投保范围内场景下的完整执行逻辑、节点交互和最终输出结果。

有疾病：input_KYCwF（输入节点）的 disease 字段内容包含 “病” 字（如 “糖尿病”“高血压病”“心脏病” 等）；

疾病不在投保范围内：llm_HJmO6（大模型节点）分析该疾病后，返回的 output 字段包含 {“result”:true}（大模型提示词约定：result=true 代表疾病不在医保 / 投保范围内）。

start_AxbRc（开始）→ input_KYCwF（输入）→ condition_boWnn（选择器）→ llm_HJmO6（大模型）→ code_Z9IWu（代码聚合）→ end_AxbRc（结束）

核心路径：有疾病场景下，流程仅走 “输入信息→大模型疾病判定→结果聚合”，完全跳过投保资格校验插件；
关键判断：最终结果由大模型返回的 result 布尔值决定（true= 疾病不在投保范围，false= 在范围内）；
最终结果：因疾病不在投保范围内，工作流向用户输出 “非常抱歉，由于 [具体疾病] 不能投保”。

上面几种情况测试成功后，我们可以将这个工作流添加到智能体中，通过输入用户的信息，就能返回是否可以投保。

在这里插入图片描述

五、常见问题与解决方案：

工作流插件在使用过程中可能遇到多种问题，以下是常见问题及其解决方案的系统性梳理，工作流插件配置避坑指南，帮助系统规避常见配置错误：

问题现象	原因分析	解决方案
插件代码里面在往下翻时空白		滑动太快导致DOM节点加载慢
插件返回false时会显未undefined	处理逻辑上需要增加判断	可以返回字符串类型的false和true
代码中不能写fetch函数,会报错	未进行配置远程url	可以使用插件代码来完成
输入节点无法使用文件	未配置与部署minio	需要配置与部署minio

六、深度思考与建议：

6.1 插件开发的核心模式：

结合openJiuwen平台智能投保插件的开发实践，云侧插件的本质是将外部REST API映射为平台内部可编排的工具，是连接AI智能体与外部业务系统（如投保校验接口）的核心桥梁，其核心价值在于打破AI传统思考的局限，让智能体具备落地实际业务的能力。这一模式的核心优势的具体体现的如下：

标准化：无论底层外部API的请求方式（如POST、GET）、参数格式、返回结构如何复杂，插件层都会统一输入输出规则，将接口能力封装为平台可识别的节点。比如投保资格校验插件，通过插件封装后，统一定义了name、id两个必填输入参数和固定结构的result输出参数，让插件可无缝嵌入工作流，大幅简化了工作流开发难度，无需开发者关注接口底层实现细节。
复用性：同一个插件工具可被多个工作流、多个智能体共享，形成标准化的能力组件。例如本次开发的投保资格校验插件，不仅可用于“智能投保咨询助手”的工作流，还可复用至农业保险、车辆保险等其他需要身份校验、资格审核的智能体工作流中，无需重复开发接口调用逻辑，减少冗余工作量，加速AI应用落地。
可观测性：插件的测试、日志、监控均在openJiuwen平台内形成闭环，便于开发者调试与问题定位。在投保插件开发过程中，可通过平台内置的“单节点调试”功能，直接输入测试参数验证插件调用接口的有效性，实时查看返回结果；若出现接口调用失败、参数异常等问题，可通过平台日志快速定位问题根源，相较于独立开发接口调用模块，大幅降低了调试成本，提升了开发效率。

6.2 工作流编排的更多可能性：

本次智能投保工作流的开发，仅实现了“输入节点+选择器分支+单插件/大模型节点+聚合节点”的简单串联模式，结合openJiuwen平台的编排能力与插件扩展特性，工作流编排可挖掘更多可能性，适配更复杂的业务场景，具体可从以下三方面拓展：

链式调用：打破单一插件的独立调用模式，实现多插件、多工具的链式联动，让工作流具备更复杂的业务处理能力。例如，在投保资格校验流程中，可先通过“IP定位插件”获取用户所在城市，再调用“区域医保政策插件”查询该城市的医保目录差异，接着结合本次开发的“投保资格校验插件”完成身份与健康双重校验，最后调用“邮件通知插件”将校验结果发送给用户，形成“定位→查政策→校验→通知”的完整链式流程，提升业务闭环能力。
分支判断优化：基于现有选择器节点的基础，细化分支判断逻辑，适配更多元的业务场景。本次投保工作流仅通过“disease字段是否含‘病’字”进行分支判断，可进一步优化为多条件分支：例如根据疾病类型（重大疾病/普通疾病）、用户年龄、投保险种等多维度设置判断条件，不同条件对应不同的校验流程（如重大疾病需额外调用专项校验插件，未成年人投保需关联监护人信息校验），让工作流更具灵活性与针对性。
循环处理：利用平台的循环节点，实现批量任务的自动化处理，提升工作效率。在投保业务场景中，若需批量校验多名用户的投保资格，无需手动重复执行工作流，可通过循环节点批量读取用户信息（如从数据库插件中获取批量用户数据），依次将用户姓名、身份证号、疾病史传入工作流，自动完成批量校验，并将所有用户的校验结果聚合输出，大幅减少人工操作成本，适配企业批量业务处理需求。

七、总结：

智能体相较于传统AI模型具有革命性优势，它不再是被动的问答工具，而是具备主动决策能力的智能实体。传统AI像静态百科全书，用户提问才回应，而智能体能够自主拆解复杂任务，比如同时处理订机票、订酒店、发送邮件通知等连贯性工作，通过环境感知能力获取时间、位置、用户习惯等上下文信息来调整行为策略，支持多轮交互、试错反馈和策略调整，最终实现目标达成。
这种智能化的转变使得AI应用从简单的语音识别等基础任务，进化到能够自主推理决策、完成复杂任务的Agent系统。openJiuwen开源平台正是基于这一理念，我们通过openJiuwen开源平台完成了一个智能投保系统开发流程，通过可视化界面大幅降低AI应用开发门槛，让开发者能够快速构建具备智能投保业务识别与验证能力的AI智能体，通过工作流编排实现用户信息收集与投保资格验证的完整流程自动化。