前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、应用类型

1、智能体（Agent）应用：

• 由提示词驱动，能够自主理解用户意图、制定决策，并调用知识库 MCP 服务等外部工具来完成任务。
• 适合构建开放式对话应用，如智能客服、知识问答、任务助理、旅行规划等场景。

2、工作流（Workflow）应用：

• 通过可视化节点编排，能够将多步骤复杂任务串联成稳定可控、可复现的执行链路。
• 适合实现固定流程自动化，如自动化报告生成、订单处理、多步骤审批流、数据标注等场景。

3、高代码应用：

• 面向专业开发者，支持基于 Python 代码构建和部署 AI 后端服务，一键部署上云并自动集成企业级运维能力。
• 适合部署私有算法、集成复杂系统、构建专业级 AI 后端服务等需要深度定制的场景。

4、应用对比

二、智能体应用

1、模型选择

为确保多步规划效果，推荐选用具备强工具调用能力的模型，如通义千问-Max系列模型。

1. 在模型选择器的下拉菜单中选择模型。单击更多模型可以选择其他模型。
2. 单击模型选择器右侧的参数配置器，支持修改的参数如下：
   • 最长回复长度：模型生成的长度限制，不包含提示词。
   • temperature：控制生成随机性和多样性，数值越高随机性越强。
   • enable_thinking：是否开启思考模式。开启思考模式有助于提升智能体的反思效果。不支持思考模式的模型无法配置 enable_thinking 参数。

2、规划

1）系统提示词

通过提示词设定智能体的角色、任务、执行步骤、限制等规则，指导智能体进行规划和生成回复

a、配置系统提示词

配置系统提示词为请你模仿《百年孤独》的风格来回答我的问题，以下是效果对比：

b、使用自定义变量（可选）

除了支持输入静态文本，系统提示词还允许嵌入自定义变量。

2）预解析文件

预解析文件功能用于控制上传文件的处理方式。

• 开启预解析：系统将使用预置解析器处理上传的文档、图像、视频、音频等文件，并返回解析后的文本内容给模型作为参考。

• 关闭预解析：系统不会主动解析文件。文件的 URL 会作为上下文信息传递给智能体，智能体可在后续步骤中决策是否调用工具，并将该URL 作为参数传入。

3、技能

1）知识库

知识库使智能体能够查询外部信息，并将检索到的内容作为生成答案的依据。在新版智能体中，知识库作为智能体的一项技能，作为工具由智能体自主规划调用。这种主动获取知识的方式，在处理私有知识或垂直领域问答时，能提升回答的准确率并有效减少内容幻觉。

2）MCP

在智能体中，外部工具均以 MCP 协议接入智能体，并纳入调度体系，。智能体能够在多步推理中，对 MCP 进行动态的、非固定顺序的调用，以解决更复杂的任务。此外，插件也支持一键转换为 MCP 服务。

3）应用组件

将已创建的智能体或工作流作为组件接入，为当前智能体提供更强大的能力

4、记忆

1）短期记忆

• 短期记忆：智能体支持短期记忆功能，即在多轮会话中为智能体提供上下文信息。
• 长期记忆：该功能计划在未来的迭代中支持。

2）携带上下文轮数

可以设置 0 到 30 轮的上下文（0 代表不传递多轮对话记录）；轮数越多，对话相关性越强，但输入长度也会相应增加。

5、回复-展示回答来源

回复支持展示回答来源。开启后，将以角标形式展示知识来源和源文件/源网页地址。该功能推荐与知识库和联网搜索 MCP 组合使用。

6、运行与结果分析

完成应用配置后，可在页面右侧的对话窗口中运行智能体。对于需要多步规划的复杂请求，新版智能体会以卡片流的形式，展示其决策过程和运行轨迹，该过程主要包含以下两种步骤：

1）思考 (Thinking)：

此步骤展示模型的推理逻辑，便于分析其决策路径并定位非预期行为的根源（仅当选用支持思考模式的模型时出现）。

2）工具调用：

此步骤记录了模型执行的具体工具调用入参及其返回的结果。通过配置 ReAct 最大轮次（取值范围 1-50），用于限制智能体在单次会话中可以调用工具的最大次数，当超出此限制后将会自动退出工具调用链路，并由智能体生成最终回复。

7、调用方式

适用于通过 API/SDK 调用当前应用，灵活集成到业务场景中。

1）API

以 API 的形式调用当前应用，需要传入应用 ID、API-KEY 等参数值，支持通过 DashScope SDK 调用。

2）SDK

使用百炼应用开发 SDK进行调用，支持复杂业务开发需求。

8）总结建议

• 多轮对话：务必在大模型节点启用 historyList 缓存，以保持上下文连贯。
• 多模态交互：若用户可能上传图片，确保在大模型提示词中引用 imageList。
• API 集成：优先使用自定义变量传参 + JSON 输出，保证接口规范性。
• 用户体验：面向终端用户的聊天场景，推荐文本输出 + 流式开启。

三、工作流应用

工作流应用将复杂的任务拆分成一系列有序执行的步骤，以降低系统复杂度。在阿里云百炼，通过工作流组合使用大模型、API 和函数计算等节点，可有效降低编码成本。本文介绍如何创建工作流。

1、应用介绍

工作流是一种将复杂任务拆分为一系列有序步骤的方法，旨在简化系统复杂度，提高工作效率。在现代软件开发和业务流程管理中，工作流应用变得尤为重要。通过在阿里云百炼平台上创建工作流应用，可以清晰地定义任务的执行顺序、责任分配以及各步骤之间的依赖关系，从而实现自动化和优化。

工作流应用有许多使用场景，如：

• 旅行规划：用户可通过工作流插件选择目的地等参数，自动生成旅行计划，包括航班、住宿、景点推荐等。
• 报告分析：针对复杂数据集，通过组合数据处理、分析和可视化插件，生成结构化和格式化的分析报告，满足不同业务需求。
• 客服支持：通过自动化工作流处理客户咨询，包括问题分类等，提高客服响应速度和准确性。
• 内容创作：实现文章、市场营销文案等内容的生成，用户只需输入主题和要求，系统自动生成符合要求的文稿。
• 教育培训：通过工作流设计个性化学习方案，包括学习进度跟踪、测评等，实现学生的自主学习。
• 医疗问诊：根据患者输入的症状，通过组合多种分析工具生成初步诊断或推荐相关检查，辅助医生进行进一步判断。

2、会话变量

会话变量作为全局变量，能够在当前工作流的全生命周期内记录参数信息，并可在各个节点中进行引用。

可在画布配置页面的右上角单击图标进行配置。

3、开始节点

开始节点是整个工作流的入口，用于接收用户输入并初始化会话上下文。系统预置了若干变量，便于后续节点调用。

1）预置变量

使用场景：这些变量可在支持“自定义缓存”的节点（如大模型节点、意图分类节点）中被引用，以实现上下文感知或跨模态理解。

2）自定义变量（可选配置）

在开始节点可额外定义结构化输入参数，用于接收外部传入的数据（如 API 调用时传参）。

案例说明：电商客服工作流

• 需求：用户通过 API 调用客服系统，同时传入用户 ID 和历史订单状态。

• 自定义变量配置：

  • userId（String）：用户唯一标识。
  • hasUnpaidOrder（Boolean）：是否有待支付订单。

• 使用方式：

  • 在后续的大模型节点中，提示词可写为：

    用户ID: ，当前有未支付订单: 。请根据此信息提供个性化回复。
    

4、结束节点

结束节点定义工作流的最终输出内容和格式，决定返回给用户或调用方的信息。

1） 输出模式：文本输出

• 适合返回非结构化自然语言内容。
• 支持直接输入固定文本，或引用工作流中任意节点的输出变量（如 、）。
• 支持流式输出（仅在此模式下生效）：
  • 开启：逐字返回大模型或应用组件的生成内容（提升用户体验）。
  • 关闭：等待全部生成完成后一次性返回。

2）输出模式：JSON 输出

• 适合需要结构化响应的场景（如 API 返回标准数据）。
• 可自定义字段名，并为每个字段赋值（支持变量引用或静态值）。

示例 JSON 输出配置：

{
  "reply": "",
  "userQuery": "",
  "timestamp": ""
}

3）流式输出

流式输出开关仅对文本模式生效。

开启时，可以逐字流式输出大模型节点、应用组件节点的内容。关闭时，回复内容将全部生成后一次性输出。

4）案例说明

a、案例说明：智能问答机器人

• 场景：用户提问“我的订单到哪了？”，系统需调用订单查询服务后生成自然语言回复。
• 工作流流程：
  1. 开始节点接收 query = "我的订单到哪了？"，并传入自定义变量 orderId = "ORD123456"。
  2. 调用“订单查询”应用组件，返回物流信息 { status: "运输中", location: "上海分拨中心" }。
  3. 大模型节点生成回复：“您的订单正在运输中，当前位于上海分拨中心。”
  4. 结束节点配置为文本输出，内容为 ``，并开启流式输出。
• 用户效果：文字逐字显示，体验更自然。

b、案例说明：API 返回结构化数据

• 场景：外部系统调用工作流获取用户画像分析结果。

• 结束节点配置为 JSON 输出：

  {
    "intent": "",
    "summary": "",
    "confidence": ,
    "processedAt": "2026-01-20T09:34:00Z"
  }
  

• 返回示例：

  {
    "intent": "投诉",
    "summary": "用户对配送延迟表示不满",
    "confidence": 0.92,
    "processedAt": "2026-01-20T09:34:00Z"
  }
  

5、大模型节点：工作流的“智慧大脑”

这是整个工作流的“智慧大脑”——能读懂语言、生成文字、分析图像，还能参与多轮对话。你可以用它写文案、做文本总结、甚至对图片内容做分析

1）功能特性

2）模式选择

a、单次处理模式

仅调用一次大模型，处理当前输入。适合 用户实时提问、单图分析、简单生成任务。

b、批处理配置

对一个列表变量中的多个项目依次或并发处理。适合 批量生成商品标题、批量审核评论、批量解析表单等。

批处理次数上限（1–100，默认100）：实际执行次数 = min(输入数组长度, 配置上限)。若无输入变量，则按配置值运行。

并行运行数量（1–10）

• 设为 1：串行执行（顺序处理，资源占用低）；
• 设为 >1：并发执行（速度快，但可能受 API 限流影响）。

案例：批量生成产品简介

• 自定义变量：productList = ["手机", "耳机", "充电宝"]

• 批处理变量：item

• 用户提示词：请为 写一段30字以内的营销文案。

• 并行数设为 3 → 三条文案几乎同时生成。

3）参数配置（通用）

4）提示词

a、系统提示词

• 定义模型角色与行为规范。
  • 示例：“你是一名资深营养师，请根据用户提供的饮食记录，给出健康建议，语言亲切、专业。”

b、用户提示词

• 用户和模型的交互内容，如要求、指令等
  • 示例：“请总结以下客户反馈：，并提取3个关键词。”
  • 技巧：结合 query、historyList、自定义变量，构建动态 Prompt。

5）记忆（上下文管理）

案例：多轮客服对话

• 在开始节点启用 historyList
• 大模型节点选择“自定义缓存”，上下文变量选 historyList
• 用户问：“我昨天订的货到哪了？” → 模型能结合前文订单信息作答。

6）输出变量

输出本节点处理结果的变量名，用于后续节点识别和处理本节点的结果。

输出变量
result String
文本输出

reasoningContent String
深度思考

7）失败重试

8）异常处理

• 关闭：使用系统默认错误处理（通常中断流程）

• 开启：可配置两种方式：

  • 默认值：返回预设文本（如“服务暂时不可用”） •
  • 异常分支：跳转至自定义处理流程（如记录日志、通知管理员）

9）总结建议

• 简单任务 → 单次模式 + 低温 + 短回复
• 批量处理 → 批次模式 + 合理设置并发数（避免超限）
• 复杂推理 → 选用深度思考模型 + 开启思考模式
• 图文理解 → 选用 VL/QVQ 模型 + 正确配置图片来源
• 多轮对话 → 启用 historyList + 自定义缓存
• 生产环境 → 配置重试 + 异常处理，提升鲁棒性

6、知识库

1）定义和作用

定义：用于实现检索增强生成（RAG），从指定知识库检索与输入相关的信息片段，并将这些片段作为上下文注入给下游的大模型节点。

作用：解决大模型知识陈旧、无法访问私有数据、容易产生“幻觉”（回答不准确）等问题。

2）输入（检索依据）

• content：需要检索的文本信息。
  • 引用：引用前置节点的输出变量或工作流内置变量。
  • 输入：直接输入文本
• imageList：需要检索的图片信息。可直接输入公网可访问的图片链接，可引用前置节点的输出变量或工作流内置变量。

3）知识库调用方式

• 必定调用：每一轮的输入都会进行知识库搜索，适用于高频知识问答场景。
• 智能调用： 根据输入判断是否进行知识库搜索，适用于灵活对话场景。此模式下，必须填写知识库描述和调用条件，以指导知识库的调用。同时，系统会根据问题意图和知识库描述的相关性，决定是否需要联网搜索作为补充。

4）知识库类型

配置应用需要检索的具体知识库，分为以下三类：

• 文档：使用应用数据的文档类数据构建。模型能够引用文本切片回答问题。
  • 数据来源：PDF、Word、TXT 等非结构化文本
  • 检索能力：按语义检索文本片段
  • 输出示例：”content”: “退货需在签收后7天内申请…”
• 表格：使用应用数据的表格类、数据库类数据构建。模型能够引用查询结果回答问题。
  • 数据来源：Excel、数据库表、CSV
  • 检索能力：支持类 SQL 查询（如“价格低于100的商品”）
  • 输出示例：”content”: {“question”: “商品A的价格？”, “answer”: “89元”}
• 图片：使用应用数据的图片类数据构建。模型能够检索图片并参考图片相关描述回答问题。
  • 数据来源：带标注的图片库（如商品图+描述）
  • 检索能力：图像相似性检索 + 元数据匹配
  • 输出示例：”content”: {“product_id”: “P1001”, “product_name”: “无线耳机”, “media_url”: “https://…/headphone.jpg”}

调试建议：点击“调试”按钮，输入测试query，查看召回结果是否相关，及时调整知识库切片策略或 embedding 模型。

5）知识库过滤（高级功能）

开启后，可通过下方的 设置判断 Prompt 定义过滤规则。系统将调用大模型，根据设定的判断 Prompt 对初步召回的结果进行二次筛选，提升最终输出的质量。此功能适用于对回答精准度有较高要求或需过滤无关信息的场景。

• 配置方式：提供一个“判断 Prompt”，
  • 例如：“以下信息是否直接回答了用户问题‘如何重置密码’？请仅保留相关片段。”
• 适用场景：

• 召回结果噪声较多（如相似但不相关）；

• 对回答精准度要求极高（如医疗、法律、金融领域）。

6）输出变量

定义用于存储本节点输出结果的变量名。该节点的输出是一个包含 result 对象的结构体，其具体结构如下

{
  "result": {
    "chunkList": [
      {
        "content": "原始片段内容（字符串或结构体）",
        "title": "文档标题（仅文档类型有）",
        "documentName": "知识库名称",
        "score": 0.92,
        "rewriteQuery": "系统改写后的查询（如适用）"
      }
    ],
    "rewriteQuery": "最终用于检索的 query"
  }
}

• chunkList：召回的知识库片段列表。无召回内容时为空。

  • content：召回知识库片段的原始内容。

    文档知识库：content为纯文本字符串，代表从原始文档中截取的文本片段。

    表格知识库：content为包含问答对的字符串，包含问题和答案等键。

    图片知识库：content为包含图片属性的字符串，包含product_id、product_name、media_url等键。

  • title：片段所属的文档标题。仅当知识库为文档类型时，此字段才会存在。

  • documentName：召回片段所在知识库的名称。

  • score：知识库片段的相似度得分，得分越高代表匹配度越高。

• rewriteQuery：改写后的用户 query。

  • 说明：即使没有显式配置大模型，系统在 RAG 节点内部仍可能自动调用轻量级模型（或规则引擎）来完成 query 改写、意图判断等任务——这是平台为提升检索效果而内置的“隐形智能”。

7、MCP 节点：接入外部能力的“万能插槽”**

• 定义：MCP（Model-Call Protocol）节点是工作流连接外部工具与服务的桥梁。通过该节点

• 说明：您可以一键调用阿里云预置或自定义开发的 MCP 服务工具（如天气查询、数据库读写、企业微信通知、OCR 识别等），将外部能力无缝嵌入自动化流程中。

• 理解：MCP 节点 = 工作流的“API 插件中心”，每个节点接入一个工具，扩展无限可能。

1）输入

• 说明：向所选 MCP 工具传递的参数。
• 特点：
  • 动态加载：选择具体 MCP 服务后，系统自动显示该工具所需的输入变量；
  • 变量来源灵活：支持直接填写值，或引用前置节点输出、工作流内置变量（如 、）。

• 配置示例：调用官方 Weather 服务

  • 在 MCP 节点中选择服务：Weather（天气）

  • 选择工具：get_weather

  • 系统自动加载所需输入字段：
    • location（城市名，必填）
    • unit（温度单位，可选）
  • 填写方式：
    • location = （引用自定义变量）
    • unit = "c"（固定值）

3）输出

• 说明：定义本节点执行结果的存储变量名（如 weatherResult）。
• 数据结构：由具体 MCP 工具决定，通常为 JSON 对象。
• 后续使用：可在大模型提示词、条件分支、结束节点中通过 `` 引用结果。

{
  "location": "杭州",
  "temperature": "18",
  "unit": "c",
  "description": "多云"
}

• 后续可引用：`` 获取温度值。

4）案例说明：智能出行助手（调用天气 + 大模型）

• 需求：用户问“明天出门要带伞吗？”，系统自动查天气并生成建议。

• 工作流设计：

  1. 开始节点接收 query = "明天出门要带伞吗？"，并传入 userCity = "上海"

  2. MCP 节点：

     • 服务：Weather
     • 工具：get_weather
     • 输入：location = , unit = "c"
     • 输出变量：currentWeather

  3. 大模型节点：

     • 提示词：

       用户所在城市：，当前天气：，温度：℃。
       请判断是否需要带伞，并给出简短出行建议。
       

• 效果：模型基于真实天气数据回答：“上海明天多云，无需带伞，适宜出行。”

5）使用建议

• 先测试再上线：在 MCP 服务详情页使用“调试”功能，验证参数与返回格式；
• 错误处理：建议为 MCP 节点配置 失败重试 或 异常分支，应对网络超时、服务不可用等情况；
• 组合使用：MCP 节点常与 大模型节点 配合——MCP 获取事实数据，大模型生成自然语言解释；
• 安全注意：自定义 MCP 服务需确保网络可达、认证安全，避免泄露敏感信息。

8、应用组件

1）定义

定义：组件调用节点允许你将已发布的智能体或工作流应用作为模块化组件引入当前工作流中，实现功能封装与复用。可以调用他人共享的组件，也可以调用自己发布的组件（如“客户意图识别器”“订单状态查询助手”等），从而避免重复开发，快速搭建复杂 AI 应用。

核心价值：把成熟的子流程“打包成黑盒”，像调用函数一样在新工作流中直接使用。

2）输入变量

• 作用：向被调用的组件传递所需数据。
• 配置方式：
  • 支持直接填写静态值；
  • 支持引用前置节点输出或工作流内置变量（如 、、``）。

• 注意：输入变量的名称和类型需与目标组件定义的入参一致（可在组件详情页查看）。

• 示例：若组件要求输入 customerQuery（String）和 priority（Number），则配置：

  • customerQuery =

  • priority = 1

3）记忆（上下文管理）

用于在多轮对话中维持被调用组件的上下文感知能力。

注意：若被调用组件本身支持多轮交互（如客服子智能体），建议启用 自定义缓存 + historyList，以保持语境连贯。

4） 流式输出

• 开启：若组件内部包含大模型生成内容，将逐字流式返回至用户界面（提升交互体验）。
  • 注意：仅当被调用组件的最终输出来源于大模型时，此开关才生效
• 关闭：等待组件完全执行完毕后，一次性输出全部结果。

5）输出变量

• 作用：定义本节点执行结果的存储变量名（如 intentResult）。
• 数据结构：由被调用组件的输出定义决定，通常为 JSON 对象。
• 后续使用：可在条件分支、大模型提示词、结束节点中通过 `` 引用。

6）案例：复用“意图分类组件”加速开发

• 背景：高精度的“用户意图识别”智能体，并发布为组件 UserIntentClassifier，输出字段包括 intent 和 confidence。
• 新工作流需求：构建一个电商客服机器人，需先识别用户是“查订单”“退换货”还是“投诉”。
• 配置：
  • 组件：UserIntentClassifier
  • 输入变量：text =
  • 输出变量：userIntent
• 后续逻辑：
  • 条件分支判断 ``：
    • 若为 "refund" → 跳转到“退换货处理子流程”；
    • 若为 "complaint" → 调用“投诉升级组件”。

7）使用建议

• 命名规范：组件输入/输出变量使用语义化英文名（如 orderStatus 而非 data1）；
• 版本管理：组件更新后，确认主工作流兼容性，必要时锁定组件版本；
• 调试技巧：在组件调用节点后添加“日志输出”节点，打印 `` 便于排查；
• 性能考量：避免在循环或批处理中高频调用复杂组件，防止延迟累积。

9、API：连接任意外部系统的“通用接口

1）定义

定义：HTTP 请求节点允许工作流通过标准 HTTP/HTTPS 协议（支持 POST、GET、PUT、PATCH、DELETE）调用自定义 API 服务，并将响应结果作为变量传递给后续节点。无论是企业内部系统、第三方 SaaS 平台，还是你自行部署的微服务，只要提供 RESTful 接口，即可无缝集成。

核心价值：打破数据孤岛，让工作流具备与任何系统对话的能力。

2）API 地址（URL）

• 作用：指定目标 API 的完整请求地址。
• 支持动态拼接：可直接输入 URL，或引用前置节点变量（如 /users/）。
• 示例：
  • 静态：https://api.example.com/v1/orders
  • 动态：https:///data?token=

3）请求方式（Method）

4）Header 设置

• 作用：传递认证、内容类型等元信息。
• 常用字段：
  • Authorization: Bearer
  • Content-Type: application/json
  • X-API-Key:
• 支持变量引用：密钥、Token 等敏感信息建议从前置节点（如认证节点）传入，避免硬编码。

5）Param 设置（查询参数）

• 作用：配置 URL 中的查询字符串（Query Parameters）。
• 格式：键值对形式，自动拼接到 URL 后。
• 示例：
  • 输入：limit = 10, status = active
  • 实际请求 URL：https://api.example.com/users?limit=10&status=active

6）Body 设置（请求体）

根据 API 要求选择合适类型：

JSON 示例（创建用户）：

{
  "name": "",
  "email": "",
  "role": "customer"
}

7）超时设置（秒）

• 作用：防止因网络或服务异常导致流程长时间挂起。
• 建议值：5–30 秒（根据 API 响应速度调整）。
• 超时行为：触发错误，进入重试或异常处理流程。

8） 失败时重试

9）异常处理

关闭后，若发生错误，本节点将按照系统预设的错误处理机制进行处理。

开启后，若发生错误，本节点将依据配置执行自定义的处理逻辑。

• 默认值：发生异常时输出 result中的内容。
• 异常分支：当发生异常时，执行异常分支。您需要为异常分支配置处理流程。

10）输出

• 作用：将 API 响应（包括状态码、Headers、Body）存储到指定变量（如 apiResponse）。

• 典型结构：

  {
    "statusCode": 200,
    "headers": { "content-type": "application/json" },
    "body": { "id": "123", "status": "success" }
  }
  

• 后续引用：、

11）案例说明：调用内部用户系统验证身份（GET）

• 需求：用户输入手机号，验证是否为企业员工。
• 配置：
  • URL：https://hr-api.company.com/v1/employees
  • Method：GET
  • Param：phone =
  • Header：Authorization: Bearer
  • 超时：10 秒
  • 输出变量：employeeInfo
• 后续逻辑：
  • 若 ` == 200` → 允许进入内部门户；
  • 否则 → 返回“非授权用户”。

12）使用建议

• 安全第一：敏感信息（Token、Key）勿硬编码，通过前置节点或环境变量注入；
• 幂等性：对 POST/PUT 操作，确保 API 支持重复请求不产生副作用；
• 调试技巧：先用 Postman 或 curl 测试 API，再填入工作流；
• 监控告警：关键 API 调用建议配置异常分支，实现故障自愈或通知。

10、插件节点：扩展工作流能力的“功能加速器”

1）定义

定义：插件节点用于在工作流中集成预构建的功能模块（即“插件”），以执行特定复杂任务，如实时搜索、数学计算、代码执行等。 阿里云百炼提供一系列官方插件（如夸克搜索、计算器、Python 代码解释器），也支持接入三方插件或您自行开发的自定义插件。

核心价值：无需从零开发，一键启用专业能力，让工作流“会算、会搜、会编程”。

2）输入

• 说明：向所选插件传递任务参数。
• 特点：
  • 动态加载：选择具体插件后，系统自动显示其所需的输入字段；
  • 变量灵活：支持直接填写值，或引用前置节点输出、内置变量（如 、）。
• 操作指引：
  1. 在插件节点中选择插件（如 “Calculator”）；
  2. 系统自动加载输入字段（如 expression）；
  3. 填写方式示例：expression = "( + ) * 0.9"

3）输出

• 作用：定义本节点执行结果的存储变量名（如 calcResult）。
• 数据结构：由插件决定，通常包含 result 字段。

• 后续引用：可在大模型提示词、条件分支等节点中使用 ``。

• 示例输出（Calculator 插件）：

  {
    "result": "89.1"
  }
  

4）失败时重试

5）异常处理

关闭后，若发生错误，本节点将按照系统预设的错误处理机制进行处理。

开启后，若发生错误，本节点将依据配置执行自定义的处理逻辑。

• 默认值：发生异常时输出result中的内容。
• 异常分支：当发生异常时，执行异常分支。您需要为异常分支配置处理流程。

6）案例说明：实时价格计算（调用 Calculator 插件）

• 需求：用户问“原价 100 元打 9 折再加 5 元运费多少钱？”

• 工作流设计：

  1. 大模型节点从 query 中提取表达式："100 * 0.9 + 5" → 输出 mathExpr

     你是一个数学表达式提取器。请将用户的问题转换为标准数学表达式，仅包含数字、运算符（+ - * / ( )）和小数点，不要包含任何中文、单位或解释。
          
     示例：
     输入：“100块打8折”
     输出：100 * 0.8
          
     输入：“原价299，打9折再减20”
     输出：299 * 0.9 - 20
     

  2. 插件节点：

     • 插件：Calculator
     • 输入：expression =
     • 输出变量：finalPrice

  3. 结束节点返回：最终价格为 元。

• 优势：避免大模型计算错误（如 100*0.9=80 的幻觉）。

[开始节点]
   ↓
[大模型节点: 提取表达式]
   - 系统提示词: 如上
   - 输出变量: mathExpr
   ↓
[插件节点: Calculator]
   - expression = 
   - 输出变量: finalPrice
   ↓
[结束节点: 文本输出]
   - 内容: 最终价格为  元。

7）使用建议

• 优先使用官方插件：经过安全与性能验证，稳定性高；
• 敏感操作慎用代码插件：如需执行脚本，确保输入已过滤、环境已隔离；
• 配合异常处理：插件依赖外部服务，务必配置重试或降级方案；
• 调试先行：在插件详情页使用“在线测试”功能，验证输入输出格式。

11、函数计算节点：调用自定义后端逻辑的“私有引擎”

1）定义

• 定义：授权阿里云函数计算服务，调用函数计算中自定义的服务。

• 核心价值：把复杂或敏感的逻辑封装在函数中，由工作流按需触发，实现“AI + 自定义计算”的深度融合。

2）输入

• 作用：向函数传递运行所需的数据。

• 支持形式：

  • 直接填写静态值（如 {"mode": "prod"}）；
  • 引用前置节点变量（如 、）。

• 数据格式：通常为 JSON 对象，具体结构需与函数代码约定一致。

• 示例：

  {
    "text": "",
    "userId": "",
    "timestamp": ""
  }
  

2）Region（地域）

• 作用：指定函数计算服务部署的阿里云地域。
• 可选项：杭州、北京、上海（以实际开通区域为准）。
• 要求：必须与您创建函数计算服务的地域完全一致。
• 建议：选择离用户或主业务最近的地域，降低网络延迟。

3） 服务配置

• 作用：选择要调用的具体函数计算服务及函数。
• 前提条件：
  • 您已通过 阿里云函数计算控制台 创建服务和函数；
  • 创建函数的阿里云账号必须与当前百炼平台账号相同，或属于同一主账号下的子账号（RAM 用户）。
• 安全机制：仅允许调用同账号下的函数，防止越权访问。

4）输出

• 作用：将函数返回的结果存储到指定变量（如 fcResult）。
• 数据结构：由您的函数代码决定，通常为 JSON。

• 后续引用：可在大模型提示词、条件分支等节点中使用 ``。

• 示例函数返回：

  {
    "processedText": "已脱敏的用户输入",
    "riskLevel": "low",
    "executionTimeMs": 128
  }
  

5）案例说明：敏感信息脱敏处理（合规场景）

• 需求：用户输入可能包含手机号、身份证号，需在进入大模型前自动脱敏。
• 解决方案：
  1. 在函数计算中部署一个 Python 函数，使用正则表达式识别并掩码敏感字段；
  2. 工作流设计：
     • 开始节点接收 query = "我的手机号是13812345678"
     • 函数计算节点：
       • Region：杭州
       • 服务：data-sanitizer
       • 函数：mask_pii
       • 输入：{"text": ""}
       • 输出变量：cleanedInput
     • 大模型节点使用 `` 生成回复
• 效果：大模型收到的是 "我的手机号是138****5678"，避免隐私泄露。

6）使用建议

• 函数设计原则：
  • 输入/输出结构清晰（建议定义 JSON Schema）；
  • 避免长时间运行（≤50 秒，留出 10 秒缓冲）；
  • 记录关键日志（便于在函数计算控制台排查）。
• 调试流程：
  1. 先在函数计算控制台 在线测试 函数；
  2. 确认返回格式正确；
  3. 再在百炼工作流中集成。
• 错误处理：
  • 函数应主动抛出标准错误（如 {"error": "invalid input"}）；
  • 工作流可配合 条件分支 判断 fcResult.error 是否存在。

12、脚本节点：轻量级数据处理的“格式化引擎”

1）定义

• 定义：脚本节点允许你在工作流中通过编写 JavaScript 或 Python 代码，对输入数据进行解析、转换、重组或格式化，输出结构化结果供后续节点使用。它适用于轻量、确定性、无外部依赖的数据处理任务，是连接不同节点之间的“逻辑胶水”。

• 核心价值：用几行代码完成数据清洗、字段提取、模板拼接等操作，无需调用外部服务。

2）输入

• 作用：向脚本传递原始数据。

• 支持形式：

  • 固定值（如 "2025-01-20"）；
  • 引用前置节点变量（如 ``）；
  • 引用会话变量（如 ``）。

• 在代码中访问方式：通过内置对象 params，例如：

  const text = params.inputText;
  const userId = params.userId;
  

3）代码

• 支持语言：JavaScript（默认）或 Python（部分平台支持）。
• 编写要求：
  • 必须定义一个名为 main 的函数；
  • 函数必须 return 一个字典/对象（key-value 结构）；
  • 返回内容将作为本节点的输出变量。

• 注意：脚本节点通常不支持网络请求、文件读写或第三方库（如 requests, pandas），仅限基础语言能力。

• JavaScript 示例：

  function main(params) {
    const rawDate = params.dateString; // "2025-01-20"
    const [year, month, day] = rawDate.split('-');
    return {
      formatted: `${year}年${month}月${day}日`,
      timestamp: new Date(rawDate).getTime()
    };
  }
  

• Python 示例（若平台支持）：

  def main(params):
      phone = params.phone_number
      # 简单脱敏：13812345678 → 138****5678
      masked = phone[:3] + '****' + phone[-4:]
      return {
          "masked_phone": masked,
          "is_valid": len(phone) == 11 and phone.isdigit()
      }
  

4）输出

• 生成方式：由 main 函数的 return 值自动构建。

• 示例：若脚本节点命名为 dateFormatter，且返回：

  { "formatted": "2025年01月20日", "timestamp": 1737302400000 }
  

  则后续节点可使用：

  • `` → "2025年01月20日"

  • `` → 1737302400000

5）案例说明：日期格式标准化（JavaScript）

• 需求：用户输入“2025/1/20”、“2025-01-20”等多种格式，统一转为“2025年01月20日”。

• 脚本节点配置：

  • 输入：dateString =

  • 代码：

    function main(params) {
      let d = params.dateString.replace(/\//g, '-');
      const date = new Date(d);
      if (isNaN(date)) return { error: "无效日期" };
      const y = date.getFullYear();
      const m = String(date.getMonth() + 1).padStart(2, '0');
      const day = String(date.getDate()).padStart(2, '0');
      return { formatted: `${y}年${m}月${day}日` };
    }
    

  • 输出变量：cleanDate

• 后续使用：您的预约日期是 。

6）使用建议

• 保持简单：脚本应 ≤30 行，复杂逻辑移至函数计算节点；
• 防御性编程：检查 params 是否存在、类型是否正确；
• 避免副作用：不要尝试修改全局状态或发起网络请求（通常会被拦截）；
• 命名清晰：返回字段名应语义明确（如 formattedDate 而非 result1）；
• 调试技巧：先在本地 IDE 测试逻辑，再粘贴到工作流。

13、条件判断：工作流的“智能决策中枢”

1）定义

• 定义：设置条件分支。当变量满足条件后，流程将选择相应的后续链路。支持且/或条件配置，多个条件是从上而下按顺序执行。

• 核心价值：让工作流具备“如果…就…”的逻辑判断能力，实现个性化、场景化的流程控制。

2） 条件分支

• 结构说明：

  • 每一行代表一个条件组；
  • 同一组内的多个条件必须同时成立（逻辑 AND）；
  • 只要任意一个条件组成立，就执行该组对应的分支（逻辑 OR）；
  • 系统从上到下依次匹配，命中即执行，不继续检查后续组。

• 条件表达式语法（常见示例）：

  • 支持的操作符通常包括：==、!=、>、<、>=、<=、&&（且）、||（或）、contains（包含）等（具体以平台为准）。

   > 90
   == "approved"
   != "guest" &&  >= 100
   contains "VIP"
  

3）其他

• 作用：当所有条件组均未命中时，执行此默认分支。
• 典型用途：
  • 处理异常或未知情况；
  • 提供兜底回复；
  • 记录未覆盖的用户意图。

4）案例说明：用户分层运营（电商场景）

• 需求：根据用户等级和订单金额，提供不同服务。

• 输入变量：

  • userLevel（值："普通" / "黄金" / "钻石"）
  • lastOrderAmount（数字，单位：元）

• 条件分支配置：

  | 条件组 | 条件表达式 | 对应分支 | | :—– | :—————————————————— | :————————— | | 第1组 | ` == “钻石” | → 跳转至“专属客服通道” | | 第2组 | == “黄金” && >= 500 | → 跳转至“优先处理队列” | | 第3组 | >= 1000` | → 跳转至“高价值客户关怀流程” | | 其他 | （无条件） | → 跳转至“标准服务流程” |

• 执行逻辑：

  • 钻石用户无论金额，优先进入 VIP 通道；
  • 黄金用户若最近订单 ≥500 元，享受优先服务；
  • 任何用户单笔 ≥1000 元，触发高价值关怀；
  • 其余走标准流程。

5）使用建议

• 顺序很重要：将最具体、优先级最高的条件放在上方；
• 避免重叠：确保条件组之间尽量互斥，防止逻辑混乱；
• 善用“其他”分支：作为安全网，捕获未预期情况；
• 变量预处理：复杂判断前，可用脚本节点标准化变量（如转小写、去空格）；
• 调试技巧：在条件分支前加日志节点，打印 `` 值便于验证。

14、意图分类：基于语义理解的“智能分发器”

1）定义

• 定义：利用大模型或专用意图分类模型，自动理解用户输入的语义意图，并从预设的多个意图类别中匹配最相关的一项（或多项），从而将工作流动态路由到对应的处理链路。它适用于自然语言场景下难以用规则判断的复杂意图识别任务。

• 核心价值：让工作流具备“听懂用户真正想做什么”的能力，替代繁琐的关键词匹配或正则规则。

2）输入变量

• 作用：提供待识别的用户原始输入。
• 支持形式：
  • 直接填写文本；
  • 引用前置节点变量（如 ``）；
  • 引用会话变量（如 ``）。
• 示例：inputText =

3）模型选择

建议：

• 初期用 Qwen-Plus 快速验证；
• 量产稳定后可训练 专用意图模型 替代。

4）意图分类

• 配置方式：为每个分支定义一个意图名称 + 描述。

• 描述要求：清晰、具体、带示例（越详细，匹配越准）。

• 示例配置：

  意图名称	意图描述
  订单查询	用户询问订单状态、物流信息、送达时间等。例如：“我的包裹到哪了？”、“订单 HT2025-001 什么时候能收到？”
  退换货	用户提出退货、换货、退款请求。例如：“衣服尺码不对，怎么换？”、“我要申请退款。”
  产品咨询	用户询问商品功能、参数、使用方法。例如：“这款手机支持快充吗？”、“说明书在哪里下载？”
  投诉建议	用户表达不满、投诉服务或提建议。例如：“客服态度太差了！”、“建议增加夜间配送。”

5）其他意图

• 作用：当模型认为所有预设意图都不匹配时，执行此默认分支。
• 典型用途：
  • 回复“我还不太理解您的需求”；
  • 转人工；
  • 记录未知意图用于后续优化。

6）意图模式

注意：多选模式下，后续通常需配合条件分支节点进一步处理。

7）思考模式

8）记忆（上下文管理）

用于在多轮对话中提升意图识别准确性：

注意：若用户说“那换货呢？”，模型需知道上一句是“我想退货”，此时必须启用自定义缓存。

9）提示词

• 作用：向模型提供额外约束或示例，引导分类行为。
• 典型内容：
  • “只从以下四个意图中选择，不要自行创造新意图。”
  • “如果用户同时提到‘退款’和‘投诉’，优先归类为‘投诉建议’。”
  • “忽略与购物无关的问题，如‘今天天气怎么样？’。”

10）输出

• 格式：返回一个对象，包含匹配的意图名称及原始输入。

• 引用方式：下游节点通过 `` 获取结果。

• 示例输出：

  {
    "intent": "订单查询",
    "input": "我的订单什么时候能到？"
  }
  

11）案例说明：电商客服自动分诊（单选 + 效果模式）

• 输入："昨天下的单，还没发货，急用！"
• 意图配置：
  • 订单查询：查物流、发货状态
  • 催单：表达焦急、要求加急
  • 投诉建议：指责服务慢
• 提示词增强：“若用户表达‘急用’‘还没发’‘催一下’，优先归为‘催单’而非‘订单查询’。”
• 结果：intent = "催单" → 跳转至“加急处理流程”

12）使用建议

• 意图描述要具体：避免“其他问题”这类模糊定义；
• 初期覆盖全面：先多设几个意图，后期合并低频项；
• 持续优化：定期分析“其他意图”日志，补充新意图；
• 与条件分支互补：
  • 意图路由：处理“用户想做什么”（语义层）；
  • 条件分支：处理“系统状态如何”（数据层）。

15、循环节点：批量处理任务的“自动化流水线”

1）定义

• 定义：循环节点是工作流中用于处理重复任务的组件。循环体作为子画布，包含固定的开始和结束节点。您可根据具体场景，自行添加不同节点到循环体中

• 核心价值：将“对每个订单发通知”“对每条评论做情感分析”等批量任务，自动化、标准化执行。

2）循环类型

• 使用数组循环：输入必须是数组（List） 类型数据，循环会按照数组的索引顺序执行，遍历数组中的每个元素。循环次数与数组长度有关。有多个数组时以最短长度为准，每次循环传入对应项。

• 指定循环次数：指定循环次数：按指定次数循环。循环次数上限为100次，大于100次可联系客服进行加白处理。

数组循环示例：输入 userIds = ["U1", "U2"]，messages = ["你好", "欢迎"]

• → 第1轮：userId="U1", message="你好"
• → 第2轮：userId="U2", message="欢迎"

3）中间变量

• 作用：在多次循环之间共享和传递状态。
• 典型用途：
  • 累计计数（如成功处理数量）；
  • 拼接结果（如汇总所有 API 返回）；
  • 控制提前退出（配合终止条件）。
• 修改方式：在循环体内使用 变量赋值节点 更新中间变量。

4）终止条件

• 机制：每次循环开始前检查该条件，若满足则立即退出，不再执行本次及后续循环。

• 配置方式：引用中间变量或循环输入变量，例如：

   >= 3
   == "completed"
  

• 未设置时：按循环类型自然结束（遍历完数组或达到指定次数）。

5）输出变量

• 格式：数组（List），长度 = 实际执行循环次数。
• 内容：每次循环体结束节点的输出，按顺序收集。

• 引用方式：下游节点通过 获取整个结果数组，或 获取第一项。

• 示例输出结构：

  [
    { "status": "sent", "to": "U1" },
    { "status": "failed", "to": "U2" }
  ]
  

6）案例说明：案例批量发送营销消息（数组循环 + 中间变量）

• 需求：向 50 个用户发送个性化短信。

• 输入：

  • userList = [{"id":"U1","name":"张三"},{"id":"U2","name":"李四"},...]

• 循环体设计：

  1. 开始节点（自动注入当前 user）

  2. 大模型节点：生成个性化文案

     为  生成一句欢迎语，不超过20字。
     

  3. MCP 节点：调用短信服务发送

     • 输入：phone=, msg=

  4. 变量赋值节点：

     • 若发送成功：successCount = + 1
     • 若失败：failList.append()

  5. 结束节点：返回 { "user": "", "status": "sent/failed" }

• 终止条件： > 5（失败超5次则停止）

• 最终输出：messageResults 数组，供后续统计使用。

7）使用建议

• 控制循环规模：单次循环体不宜过重（避免超时）；
• 初始化中间变量：在循环前用变量赋值节点设初值（如 count = 0）；
• 善用终止条件：避免无效循环（如已找到目标就退出）；
• 输出结构统一：确保每次循环结束节点返回相同字段，便于后续处理；
• 调试技巧：先用小数组（如2项）测试逻辑，再放大。

16、批处理：高并发处理任务的“并行加速器”

1）定义

• 定义：批量节点用于在工作流中高效并行处理一批数据项。它将输入的数组拆分为多个子任务，在同一次批处理轮次中并发执行（由“并行运行数量”控制），显著提升处理效率。其内部以子画布形式组织逻辑，包含固定的开始与结束节点，您可自由添加任意节点构建子流程。

• 核心价值：将“逐个串行处理100个订单”升级为“每批10个并行处理”，大幅缩短整体耗时。

2）批处理设置

• 批处理次数上限：整个批处理循环的最大执行次数。即使任务未处理完，也会在达到指定次数后终止。
• 并行运行数量：在每次循环中同时运行的任务数量。

3）批处理数组

• 要求：必须为 List（数组）类型。
• 支持形式：
  • 直接输入：["A", "B", "C"]
  • 引用变量：``
• 多数组对齐：
  • 可配置多个数组（如 userIds, messages）；
  • 系统按索引位置一一对应传入子流程；
  • 最终处理项数 = 最短数组长度 与 批处理容量上限 的较小值。

• 示例：

  • ids = ["U1", "U2", "U3"]

  • msgs = ["Hi", "Hello"]→ 实际处理 2 项：(U1, Hi) 和 (U2, Hello)

4）输出变量

• 格式：数组（List），顺序与输入一致。
• 内容：每个子任务结束节点的输出结果。
• 引用方式：
  • 整体：``
  • 单项：``

• 示例输出：

  [
    { "status": "success", "userId": "U1" },
    { "status": "failed", "userId": "U2" }
  ]
  

5）案例说明：批量发送个性化通知（高并发场景）

• 需求：向 1000 名用户发送定制化短信，要求尽快完成。
• 输入：
  • userList = [{"id":"U1","name":"张三","phone":"138..."}, ...]（1000 条）
• 批量节点配置：
  • 批处理次数上限：100
  • 并行运行数量：10 → 每轮并发 10 个，共需 100 轮（100×10=1000）
  • 批处理数组：users =
• 子画布流程：
  1. 开始节点（自动注入当前 user）
  2. 大模型节点：生成个性化文案（“张三，您的专属优惠来了！”）
  3. MCP 节点：调用短信网关发送
  4. 结束节点：返回 { "userId": "", "status": "sent" }
• 优势：相比串行处理（1000秒），并行后可能仅需 100 秒（假设单次1秒）。

6）使用建议

• 合理设置并行数：
  • 过高 → 触发 API 限流或资源争抢；
  • 过低 → 无法发挥并行优势。→ 建议从 5–10 开始测试。
• 确保子流程幂等：单个任务失败不应影响整体。
• 监控输出结构：统一结束节点返回格式，便于后续聚合分析。

17、流程输出：工作流中的“实时播报员”

• 定义：流程输出节点用于在工作流执行过程中任意位置，向用户即时输出一段内容，而非等待整个流程结束。它不终止流程，而是作为一种中间反馈机制，提升用户体验与系统可观测性。

• 核心价值：让用户“看得见进度”，让开发者“查得清状态”。

1）典型应用场景

2）输出内容

• 支持形式：支持输入固定内容或输入/引用前置节点的变量及会话变量。
• 内容类型：纯文本或简单 Markdown（取决于前端渲染能力）

3）案例说明：耗时操作前的用户安抚（防等待焦虑）

• 场景：调用外部天气 API查询多个城市，预计耗时 3–5 秒。
• 工作流设计：
  1. 开始节点接收 cities = ["北京", "上海", "广州"]
  2. 流程输出节点：
     • 输出内容："正在为您查询 个城市的天气，请稍候…"
     • 流式输出：关闭（静态提示）
  3. 应用组件节点：调用“天气分析智能体”
  4. 结束节点：返回详细天气报告
• 用户体验：用户立即看到“系统已响应”，避免反复点击或认为无反应。

18、变量处理：活转换与结构化输出的“格式工厂”

• 定义：用于文本内容的转换与处理，如抽取特定内容、格式转换等，支持模板模式。

• 核心价值：让杂乱数据“变整齐”，让自由文本“可编程”。

1）输出模式

• 文本输出：将输入内容转换为文本类型进行输出。在编辑框中直接输入待处理的内容，或通过插入变量的方式输入前置节点或会话变量的待处理内容。

  • 场景：生成自然语言回复、拼接提示词、构造日志消息

  • 用户 （ID: ）于  提交了订单。
    

• JSON 输出：将输入的变量以格式化 JSON 类型进行输出。

  • 场景：适配 MCP/HTTP 节点的结构化输入、调试中间结果

• 聚合分组：按照分组策略对分组内的值进行返回控制。可以返回每个分组中第一个或最后一个非空的值。

  • 场景：合并多轮对话中的关键信息、去重取有效值
  • 输入：一个包含多个对象的数组（通常来自多轮对话、批量处理或多次 API 调用结果）；
  • 分组依据：隐式按某个字段（如 sessionId、userId、intent）分组（具体由平台内部实现）；
  • 输出策略：
    • 取第一个非空值：适用于“首次有效即锁定”的场景；
    • 取最后一个非空值：适用于“以最新为准”的场景；
  • 目的：去重 + 提炼关键信息，避免冗余或冲突。

2）输出变量

• 作用：指定本节点处理结果的存储变量名（如 formattedResponse）。
• 引用方式：后续节点通过 `` 获取结果。
• 数据类型：
  • 文本模式 → 字符串（String）
  • JSON 模式 → 对象（Object）
  • 聚合分组 → 数组或对象（依分组策略而定）

3）案例说明

a、案例 1：大模型输出结构化（JSON 输出模式）

• 问题：大模型返回一段自由文本："订单状态：已发货，物流单号：SF123456789CN"
• 目标：提取为结构化 JSON 供后续调用物流 API。
• 解决方案：大模型节点的 Prompt 中强制要求其直接输出合法 JSON 字符串，配合（JSON 输出模式）进行解析。
  1. 大模型节点提示词要求返回 JSON 格式；
  2. 在文本处理节点使用 JSON 模式（假设输入已是合法 JSON 字符串）。
     • 仅当上游节点（如大模型）确实输出了合法 JSON 字符串时才有效。
• 输出变量：orderInfo
• 下游使用：``

b、案例 2：生成用户友好的通知（文本输出 + 模板）

• 输入变量：

  • userName = "张三"
  • deliveryDate = "2025-01-25"
  • product = "无线耳机"

• 文本处理节点配置：

  • 输出模式：文本输出

  • 内容：

    亲爱的 ，您购买的  预计将于  送达，请注意查收！
    

  • 输出变量：notificationMsg

• 效果：notificationMsg = "亲爱的 张三，您购买的 无线耳机 预计将于 2025-01-25 送达，请注意查收！"

c、案例 3：多轮意图信息聚合（聚合分组模式）

• 场景：用户在多轮对话中逐步提供信息：

  • 第1轮：“我要订机票” → 提取 intent = "flight_booking"
  • 第2轮：“去北京” → 提取 destination = "北京"
  • 第3轮：“下周二” → 提取 date = "2025-01-28"

• 聚合分组节点：

  • 按会话 ID 分组；
  • 返回每组中最后一个非空值；

• 输出：

  {
    "intent": "flight_booking",
    "destination": "北京",
    "date": "2025-01-28"
  }
  

• 用途：为最终订票流程提供完整参数。

19、变量赋值：循环中的“状态控制器”

• 定义：仅支持在循环节点中使用，可以将特定的值赋予循环体的中间变量，从而实现变量值的动态更新与传递，使工作流能够根据实时数据进行相应处理。

• 核心价值：让循环从“机械重复”升级为“智能迭代”。

1）设置变量

• 变量：需要赋值的参数，支持选择循环节点的中间变量或会话变量。
  • 循环中间变量（如 count, total, hasError）
  • 会话变量（如 ``）
• 设置值：可输入固定值或引用前置节点的变量。

2）案例说明：统计成功处理数量（计数器）

• 场景：批量处理订单，统计成功数。
• 循环中间变量初始化（循环节点外）：successCount = 0
• 循环体内流程：
  1. 调用订单处理 API → 输出 processResult
  2. 变量赋值节点：
     • 变量：successCount
     • 设置值：``
• 后续使用：循环结束后，`` 即为总成功数。

3）使用建议

• 初始化很重要：在循环开始前，用变量赋值节点或前置节点为中间变量设初值（如 count = 0, list = []）；
• 避免复杂逻辑：若需字符串拼接、数组操作等，建议先用脚本节点计算，再赋值；
• 命名清晰：中间变量名应体现用途（如 errorThresholdMet 而非 flag1）；
• 与终止条件联动：变量赋值常作为终止条件的“触发器”，两者需协同设计。

20、参数提取：从自由文本中“挖出”结构化数据的“智能解析器”

• 定义：参数提取节点利用大模型或专用抽取模型，从一段非结构化文本中自动识别并提取预定义的结构化字段（如日期、订单号、意图、实体等）。您只需声明所需参数的名称、类型和描述，模型即可在输入文本中定位、解析并返回标准格式的结果。

• 核心价值：将用户口语化表达（如“帮我查下昨天发的订单”）转化为机器可读的结构化数据（{ "action": "query", "date": "2025-01-19" }），打通自然语言与系统逻辑的鸿沟。

1）输入

• 作用：提供待提取的原始文本。
• 支持形式：
  • 直接填写静态文本；
  • 引用前置节点变量（如 ``）；
  • 引用会话变量（如 ``）。
• 示例："我想退掉订单 HT2025-001，原因是尺码太大了。"

2）模型选择

• 选项：通常包括 通义千问-Plus（Qwen-Plus）或 专用参数抽取小模型。
• 选型建议：
  • Qwen-Plus：适用于复杂、开放域、多意图场景，理解能力强；
  • 专用模型：适用于固定字段、高吞吐、低成本场景（需提前训练）。

3）提取参数

• 注意： 描述越具体，提取越准确。可加入正例/反例。

• 配置方式：为每个目标字段定义三要素：

  字段	说明	示例
  名称	输出变量的键名	orderId
  类型	期望的数据类型	string / number / date / boolean
  描述	告诉模型“这个字段长什么样”	“订单编号，格式为 HT + 8位数字/字母，如 HT2025-001”

• 示例配置：

  名称	类型	描述
  action	string	用户意图，只能是以下之一：[“查询”, “退货”, “换货”, “投诉”]
  orderId	string	订单编号，以 HT 开头，如 HT2025-001
  reason	string	退货或换货原因，简要描述
  urgent	boolean	是否加急，若出现“尽快”“急用”等词则为 true

4）提示词

• 作用：补充全局约束或示例，引导模型行为。
• 典型内容：
  • “只提取明确提到的信息，不要猜测。”
  • “如果未提及某字段，该字段留空（不返回或设为空字符串）。”
  • “示例输入：‘退单 HT123，太慢了！’ → 输出：{ action: ‘退货’, orderId: ‘HT123’, reason: ‘太慢了’, urgent: false }”

5）输出（Output）

• 格式：JSON 对象，键名为您定义的参数名称。
• 引用方式：下游节点通过 `` 获取值。

• 缺失处理：未提取到的字段可能为 null、空字符串或直接省略（依平台实现而定）。

• 示例输出：

  {
    "action": "退货",
    "orderId": "HT2025-001",
    "reason": "尺码太大",
    "urgent": false
  }
  

6）案例1：电商退换货工单自动填充

• 用户输入："我要换货，订单 HT2025-001，衣服小了一号，尽快处理！"

• 提取参数配置：

  • action: string, 可选值 [“退货”, “换货”]
  • orderId: string, 格式 HT+…
  • reason: string
  • urgent: boolean（含“尽快”“急”等词为 true）

• 模型输出：

  {
    "action": "换货",
    "orderId": "HT2025-001",
    "reason": "衣服小了一号",
    "urgent": true
  }
  

• 后续使用：直接传给 MCP 节点创建工单，无需人工录入。

21、智能体群组节点：复杂任务的“AI 项目指挥官”

• 定义：智能体群组节点用于将一个复杂、开放、多步骤的任务交由一组专业化子智能体协同完成。系统内置的决策模型会自动分析任务需求，动态规划执行流程，并智能调度最合适的子智能体参与处理——无需人工预设固定顺序。

• 核心价值：让 AI 自己“拆解问题 → 分配任务 → 协同执行”，适用于你只知道目标、但不清楚具体步骤的场景。

1）输入

• 作用：提供待处理的原始任务描述。
• 支持形式：
  • 固定文本（如 "帮我策划一场618大促活动"）；
  • 引用前置变量（如 ``）。
• 要求：任务应具备可分解性和多角色协作潜力。

2）模型选择

• 说明：选择用于任务规划与调度的决策大模型（如通义千问-Max 或 Qwen-Plus）。
• 选型建议：
  • Qwen-Max：适合高度复杂、需强推理能力的任务；
  • Qwen-Plus：平衡成本与能力，适用于大多数场景。

3）群组名称

• 作用：为当前智能体群组命名（如 “营销策划团队”），便于识别与管理。
• 注意：仅作标识，不影响执行逻辑。

4）智能体

• 要求：

  • 仅可添加已发布的智能体应用；
  • 每个子智能体必须填写功能描述（关键！）。

• 功能描述示例：

  • 决策模型依赖这些描述判断“谁该做什么”。描述越精准，调度越合理。

  子智能体	功能描述
  市场分析助手	擅长分析用户画像、竞品数据、市场趋势，输出结构化报告
  文案创作专家	能撰写广告语、社交媒体推文、活动详情页文案
  预算规划师	根据活动规模制定详细预算表，包含渠道投放分配
  视觉设计顾问	提供主视觉风格建议、色彩搭配、素材使用规范

5）输出变量

• 格式：结构化文本或 JSON（依任务而定），包含最终整合结果。
• 引用方式：后续节点通过 `` 获取完整输出。
• 内容特点：通常为多个子智能体协作后的融合成果，而非中间过程。

6）**案例说明 **

a、案例1：618 大促全案策划（典型复杂任务）

• 用户输入：请为我们的新品牌‘轻氧’策划一场618大促活动，目标是提升新客转化。
• 配置子智能体：
  1. 市场分析助手 → 描述：分析目标人群、竞品促销策略
  2. 文案创作专家 → 描述：撰写活动 Slogan、落地页文案
  3. 预算规划师 → 描述：制定 50 万总预算分配方案
  4. 视觉设计顾问 → 描述：提出主视觉风格（清新、活力）
• 执行过程（由决策模型自动规划）：
  1. 先调用市场分析助手获取用户画像；
  2. 基于分析结果，调度文案专家和视觉顾问并行产出；
  3. 最后由预算规划师整合所有需求，输出总方案。
• 输出：一份包含市场洞察、创意文案、视觉指南、预算表的完整策划案。

b、案例 2：个性化旅行规划

• 输入："为一对情侣规划3天2晚的杭州行程，预算5000元，喜欢小众景点和美食。"
• 子智能体：
  • 景点推荐官：挖掘非热门但高分景点（如茅家埠、小河直街）
  • 美食向导：推荐本地人常去的餐厅（非网红店）
  • 路线规划师：优化每日动线，减少交通时间
  • 预算管家：核算住宿、门票、餐饮总费用
• 输出：一份含每日行程、餐厅地址、费用明细、地图链接的 PDF 风格计划。

7）使用建议

• 子智能体要“专精”：每个智能体聚焦单一能力，避免功能重叠；
• 描述即“岗位说明书”：用动词明确其职责（如“分析…”“生成…”“验证…”）；
• 适合“目标明确但路径模糊”的任务：
  • 适合：“写一份融资BP”、“诊断系统性能瓶颈”
  • 不适合：“把这段文字翻译成英文”（单智能体即可）
• 配合其他节点：
  • 前置：用参数提取节点结构化用户需求；
  • 后续：用流程输出节点分段展示结果。

22、智能体创建：画布内的“专属AI助手”

• 定义：内嵌智能体节点允许您在工作流编排画布中即时创建一个轻量级、专用的智能体，仅用于当前流程。

• 说明：它具备完整的大模型能力，并可配置角色 Prompt、绑定知识库、调用插件，适用于需要临时定制化 AI 行为但又无需发布独立智能体应用的场景。

• 核心价值：无需离开画布，即可按需“召唤”一个专属 AI 助手，快速响应特定子任务。

1）输入

• 作用：提供该智能体需要处理的原始内容。
• 支持形式：
  • 固定文本（如 "请总结以下内容"）；
  • 引用前置节点变量（如 ``）；
  • 混合模式（如 "基于以下用户反馈生成回复："）。

2）智能体名称

• 作用：为当前内嵌智能体命名（如 “摘要生成器”、“客服应答助手”）。
• 用途：便于在画布中识别节点功能，不影响执行逻辑。

3）模型选择

• 选项：支持通义千问系列模型（如 Qwen-Max、Qwen-Plus、Qwen-Turbo）。
• 选型建议：
  • Qwen-Max：复杂推理、高精度任务；
  • Qwen-Plus：平衡性能与成本；
  • Qwen-Turbo：简单任务、高并发、低延迟。

4）Prompt

• 作用：用自然语言告诉模型“你是谁、要做什么”。
• 最佳实践：
  • 明确角色：你是一位资深电商客服
  • 限定输出格式：请用不超过50字的中文回复
  • 禁止行为：不要提及退款政策以外的内容
• 示例 Prompt：

  你是一位物流查询专员，仅根据提供的订单信息回答物流状态。
  如果信息不足，请回复：“请提供订单号以便查询。”
  不要猜测或编造物流信息。

5）知识库

• 作用：为智能体注入私有知识，提升回答准确性。
• 适用场景：
  • 回答公司产品 FAQ；
  • 引用内部文档（如退换货规则）；
  • 基于最新数据生成答案。
• 注意：知识库需提前创建并授权给当前工作流。

6）插件

• 能力扩展：允许智能体调用外部工具，突破纯文本生成限制。
• 支持类型：
  • 官方插件：如天气查询、计算器、数据库连接；
  • 自定义插件：企业自有 API 封装（如订单系统、CRM）。
• 调用方式：模型根据任务自动判断是否需要调用插件（需在 Prompt 中暗示或明确允许）。
  • 示例：Prompt 中写 “你可以调用‘订单查询’插件获取实时状态”，模型将在需要时自动触发。

7）输出变量（Output Variable）

• 格式：模型生成的文本或结构化结果（若插件返回 JSON）。
• 引用方式：后续节点通过 `` 获取结果。
• 典型用途：作为下一流程的输入、最终回复内容或条件判断依据。

8）案例1：结合插件查询实时订单状态

• 输入："订单 HT2025-001 的当前状态？"

• 配置：

  • 智能体名称：订单状态助手

  • Prompt：

    你可以调用“订单查询”插件获取信息。
    如果插件返回成功，请用自然语言告知用户物流进度；
    如果失败，请说“暂时无法查询，请稍后再试”。
    

  • 插件：启用已配置的 orderLookup 插件

• 执行过程：

  1. 模型解析输入，识别需查订单；
  2. 自动调用 orderLookup(orderId="HT2025-001")；
  3. 插件返回 { status: "已发货", courier: "顺丰", tracking: "SF123..." }；
  4. 模型生成回复："您的订单已由顺丰发出，单号 SF123..."

• 输出变量：``

9）使用建议

• 轻量优先：适合单次、专用任务，复杂长期服务建议发布独立智能体；

• Prompt 是关键：清晰的角色+约束=稳定输出；

• 插件需显式授权：确保工作流有权限调用目标插件；

• 与内嵌智能体 vs 智能体应用对比：

  维度	内嵌智能体	独立智能体应用
  发布范围	仅当前工作流	全平台可复用
  管理成本	低（随画布保存）	高（需版本管理）
  适用场景	临时、流程专属	通用、高频调用

• 注意事项

  风险	应对措施
  Prompt 模糊导致输出不稳定	加入格式示例和禁止项
  插件未正确配置	在测试阶段验证插件调用日志
  知识库未命中	检查文档切片质量与检索阈值

23、文档解析：从文件中“读懂”结构化信息的“AI 阅读器”

• 定义：文档解析节点用于自动提取上传文档中的文本内容与结构化信息，支持 PDF、Word、Excel、PPT 等常见格式。

• 说明：该节点利用智能解析引擎或大模型能力，将非结构化文档转化为可被后续流程使用的文本或表格数据，当前使用不计费。

• 核心价值：无需人工复制粘贴，一键从合同、简历、报表等文件中提取关键内容，打通“文件输入 → 自动化处理”链路。

1）文件类型

2）输入

• 要求：
  • 单文件大小 ≤ 100 MB；
  • 必须为上述支持的格式之一；
  • 通常通过用户上传或前置节点（如 HTTP 节点下载）提供。
• 引用方式：``（变量需为文件对象）

3）解析器选择

• 大模型文档解析：通过内置大模型实现解析，不支持修改提示词。解析效果较好，解析速度较快。
  • 利用大模型理解语义
  • 能识别段落逻辑、标题层级、关键字段
  • 效果最好，速度较快
• 电子文档解析：解析效果中等，解析速度最快。
  • 基于文档原生结构
  • 速度最快
  • 对排版依赖强，复杂 PDF 易错乱
• 文档智能解析：解析效果较好，解析速度较快。
  • 结合 OCR + 布局分析 + 语义理解
  • 对扫描件、图文混排文档支持较好
  • 效果与大模型解析接近
  • 场景：扫描版 PDF、带表格的报告、图文混合材料

4）输出说明

• 输出格式：

  • 非 Excel 文档：返回完整文本字符串（保留段落结构）；

  • Excel 文档：返回结构化 JSON，包含各 sheet 的表格数据，例如：

    {
      "Sheet1": [
        ["姓名", "部门", "工号"],
        ["张三", "技术部", "T1001"],
        ["李四", "市场部", "M2002"]
      ]
    }
    

• 输出变量：可自定义（如 parsedContent），供后续节点引用。

5）案例说明

a、案例 1：自动解析简历并提取候选人信息

• 输入：用户上传 PDF 简历（resume.pdf）
• 配置：
  • 文件类型：其他
  • 解析器：大模型文档解析（能识别“姓名”“工作经历”等语义区块）
• 输出：parsedContent = 完整简历文本
• 后续流程：
  1. 将 `` 传给 参数提取节点；
  2. 提取 name, phone, experience 等字段；
  3. 自动录入 HR 系统。
• 优势：避免手动录入，支持不同模板简历。

b、案例 2：批量导入用户数据（Excel 表格）

• 输入：users.xlsx（含 3 个 sheet）

• 配置：

  • 文件类型：Excel
  • 解析器：电子文档解析（速度快，表格结构清晰）

• 输出：

  {
    "员工名单": [["张三", "T1001"], ["李四", "T1002"]],
    "部门分配": [["技术部", 50], ["市场部", 30]]
  }
  

• 后续使用：

  • 用脚本节点遍历 员工名单 数组；
  • 调用用户创建 API 批量注册账号。

6）使用建议

• 优先用大模型解析：除非对速度极度敏感，否则它对语义理解更优；
• Excel 用专用模式：确保表格结构不丢失；
• 大文件注意超时：100MB 是上限，但复杂 PDF 解析可能耗时较长；

• 后续接结构化节点：解析只是第一步，通常需配合 参数提取 或 脚本节点 进一步处理。

• 注意事项

  限制	说明
  不支持多文件	一次只能解析一个文件，批量需配合循环/批量节点
  无提示词定制	大模型解析器的内部 Prompt 不可修改
  扫描件质量影响结果	图像模糊、倾斜会降低 OCR 准确率
  表格跨页可能断裂	复杂跨页表格建议用 Excel 原生格式

24、图片解析：从图像中“看见”结构化信息的“AI 视觉助手”

• 定义：图片解析节点利用多模态大模型或智能视觉引擎，自动识别并提取图片中的文字、版面结构、表格、关键字段等内容，输出为可被后续流程使用的文本或结构化数据。

• 说明：支持单图或图片列表输入，适用于证件识别、票据解析、界面截图理解等场景。

• 核心价值：让工作流具备“看图说话”能力，将静态图像转化为动态业务数据。

1）输入

• 支持格式：.png、.jpg、.jpeg、.bmp、.gif
• 文件限制：
  • 单文件 ≤ 20 MB
  • 支持 单文件 或 图片列表（如用户上传多张发票）
• 引用方式：或

2）解析器选择（Parser）

• 大模型文档解析：
  • 支持从图片中提取层级树和版面信息，支持输出 Markdown 格式。
  • 通过内置大模型实现解析，不支持修改提示词。该功能暂不计费。
  • 场景：若只需完整还原图文内容 → 选 大模型文档解析（免费、高效）；
• Qwen VL 解析：
  • 支持调用 qwen-vl-max 和 qwen-vl-plus 解析图片，
  • 需要自定义提示词。使用中将产生 qwen-vl-max 和 qwen-vl-plus 的调用费用。
  • 场景：若需定向提取特定信息 → 选 Qwen-VL + 自定义 Prompt（灵活、精准）。

3）输出说明

• 大模型文档解析：输出为 Markdown 字符串，例如：

  # 发票信息
  - 开票日期：2025-01-15
  - 金额：¥1,280.00
  - 销售方：XX科技有限公司
  

• Qwen-VL 解析：输出为 纯文本或 JSON（取决于提示词要求），例如：

  { "invoiceAmount": "1280.00", "date": "2025-01-15" }
  

• 输出变量：可自定义（如 parsedImage），供后续节点引用。

4）案例说明

a、案例 1：自动识别报销发票（精准字段提取）**

• 输入：用户上传一张增值税电子发票（invoice.jpg）

• 目标：提取 开票日期、金额、销售方名称

• 配置：

  • 解析器：✅ Qwen-VL 解析

  • 模型：qwen-vl-plus

  • 提示词：

    请从发票图片中提取以下字段，并以严格 JSON 格式返回：
    {
      "invoiceDate": "开票日期，格式 YYYY-MM-DD",
      "totalAmount": "价税合计金额，仅数字，不含符号",
      "sellerName": "销售方名称"
    }
    不要包含任何其他文字。
    

• 输出

  {
    "invoiceDate": "2025-01-15",
    "totalAmount": "1280.00",
    "sellerName": "杭州阿里云科技有限公司"
  }
  

• 后续：传给财务系统自动创建报销单。

b、案例 2：批量解析产品宣传图

• 输入：市场部上传 5 张新品海报（posters.zip 解压为列表）

• 目标：提取每张图的主标题、核心卖点

• 配置：

  • 解析器：大模型文档解析
  • 输入：``（图片列表）

• 输出：每张图对应一段 Markdown 文本，例如：

  ## 轻氧空气净化器 Pro
  - 99.97% 除菌率
  - 静音节能，低至 26dB
  - APP 智能控制
  

• 后续处理：

  • 用脚本节点遍历列表；
  • 提取 ## 后的标题和 - 列表项；
  • 自动生成商品详情页草稿。

5）使用建议

• 优先免费方案：若只需全文提取，用 大模型文档解析；
• 精准提取用 Qwen-VL：配合强约束 Prompt，确保输出可编程；
• 图片质量很重要：避免模糊、反光、遮挡；
• 列表处理技巧：配合 批量节点，对每张图独立解析；

• 敏感信息脱敏：如涉及身份证、银行卡，建议在解析后立即清除原始图。

• 注意事项

  风险	应对措施
  Qwen-VL 费用不可控	在测试阶段限制调用次数，上线后设置配额
  手写体识别不准	优先使用印刷体图片，或在 Prompt 中说明“仅识别清晰印刷文字”
  多图顺序错乱	确保输入列表顺序与业务逻辑一致（如身份证正→反）

三、FQA

1、智能体的提示词和 MCP 提示词

1）基本概念澄清

a、智能体的提示词

这是指赋予整个智能体角色、目标、行为准则、工具使用方式等高层指令的系统提示（system prompt）。它定义了：

• 智能体的身份（如“你是一个客服助手”）
• 核心任务（如“帮助用户查询订单状态”）
• 行为边界（如“不要编造信息”）
• 工具调用规则（如“当需要查询数据库时，调用 search_order 工具”）

b、MCP 提示词

MCP 是一种多步骤协同提示策略，常见于复杂任务分解场景。它通常包含：

• 主控提示（Master Prompt）：负责任务规划与调度
• 子任务提示（Sub-task Prompts）：针对每个子步骤的专用提示
• 协调机制：如何将子结果整合、迭代或验证

2）两者关系

3）如何配置更优

顶层（Agent Prompt）：清晰定义角色、能力边界、工具列表、输出格式。

# 角色
你是一个电商客服智能体，请严格遵守以下规则。

## 🛠️ 可用工具

### `search_order(order_id: str)`
- **功能**：查询12位订单号对应的订单详情（状态、商品、是否可退款）。
- **调用条件**：用户提供有效订单号，并明确要求查询。

### `get_user_path(user_id: str)`
- **功能**：获取用户基本信息（姓名、电话）。
- **调用条件**：仅在已通过订单验证身份后使用。

### `refund_request(order_id: str, reason: str)`
- **功能**：发起退款申请。
- **调用条件**：
  1. 用户明确请求退款；
  2. 订单已通过 `search_order` 验证且支持退款；
  3. 用户提供了具体退款原因。

## ⚠️ 通用规则
- **禁止猜测**：不得假设订单号、用户ID或退款原因。
- **信息缺失时**：必须明确询问用户，例如：“请提供12位订单号。”
- **每次只调用一个工具**，等待结果后再继续。

底层（MCP Steps）：针对每个子任务定制提示，聚焦单一目标。

[步骤1：意图识别] 判断用户是否在查询订单。如果是，提取订单号；否则返回"无关"。
[步骤2：信息验证] 检查订单号是否符合格式（12位数字）。若无效，要求用户重新提供

2、智能体拆分

1）什么时候应该进行智能体拆分

经验法则：

• 少于 3 个明确独立场景 → 用 单智能体 + MCP
• 超过 3 个高差异场景，或涉及敏感操作 → 考虑多智能体

1. 这个新功能是否与现有智能体的核心职责冲突？→ 是 → 考虑拆分。
2. 它是否需要完全不同的工具、知识库或安全策略？→ 是 → 应拆分。
3. 如果合并，提示词是否会变得极其复杂、难以维护？→ 是 → 拆分更清晰。
4. 用户是否感知到“角色混乱”？（比如客服突然开始写代码）→ 是 → 需要角色分离。
5. 能否用“MCP（多步骤提示）”在单个智能体内解决？→ 能 → 优先不拆分。

2）什么时候不该拆分？

• 重复建设：多个智能体使用相同知识库、相似 Prompt → 资源浪费

• 微任务拆分：如“提取姓名”“提取电话”各做一个智能体 → 维护爆炸
• 逻辑强耦合：多个智能体必须按固定顺序调用，无法独立工作 → 失去灵活性
• 调度复杂化：主流程需手动编排 10+ 个智能体 → 可读性差、调试困难

6）拥有“很多”智能体是好事吗

• 优点（当设计合理时）

  • 模块化强：易于单独测试、更新、替换。

  • 可扩展性好：新增功能只需加新智能体，不扰动现有逻辑。

  • 错误隔离：一个智能体出错不会导致整个系统崩溃。

  • 专业化程度高：每个智能体可微调专属模型或提示词。

• 缺点：

  • 过度拆分：简单任务也要多个智能体接力 → 延迟高、成本高、调试难
  • 协调复杂：需额外设计“调度器”或“主控Agent”，引入新故障点
  • 上下文割裂：智能体之间信息传递丢失，用户感觉“答非所问”
  • 资源浪费：每个智能体可能加载大模型，内存/CPU/Token 成本飙升
  • 一致性挑战：不同智能体对同一问题回答矛盾，损害用户体验

4）折中方案：混合架构

• 主控轻量，只做路由；
• 子智能体专注执行；
• 共享用户上下文（通过状态管理）；
• 既避免臃肿，又控制复杂度。

[用户] 
   ↓
[Router Agent] ← 判断意图（如“退款”、“查物流”、“投诉”）
   ↓
→ [Refund Agent]（专用退款流程）
→ [Logistics Agent]（只查物流）
→ [Complaint Agent]（走投诉通道）

3、知识库使用最佳实践