基于扣子（Coze.cn）与火山引擎构建高性能智能体的实践指南

1. 引言

1.1. 背景与目标

人工智能（AI）智能体（Agent）平台的兴起，例如扣子（Coze），正显著改变我们构建复杂 AI 应用的方式 1。这些平台旨在降低技术门槛，让不同技能水平的用户都能利用大型语言模型（LLM）的能力，快速开发和部署 AI 解决方案。本报告的目标是提供一份专家级的实践指南，详细阐述如何在扣子中国站（Coze.cn）上创建一个智能体，并重点关注如何集成 火山引擎 提供的知识库和工作流能力。这份指南基于本人对现有公开文档和资源的模拟操作与分析 1，力求提供清晰、可操作的步骤和深入的理解。报告将遵循特定的格式要求，包括 Markdown 语法、Mermaid 图表、目标字数、第一人称视角（例如，“本人操作得知...”），并融入自然的语言表达习惯。

1.2. 扣子平台概览：国内版与海外版的考量

首先需要明确，扣子平台存在国内版（coze.cn）和海外版（coze.com）两个版本 1。这两个版本在访问限制、支持的大模型种类、官方插件以及功能更新速度上可能存在差异 1。此外，根据一些信息反馈，coze.cn 在特定区域可能存在访问限制 6。鉴于此，本报告在撰写过程中，主要依据 coze.com 的公开文档和通用平台功能进行模拟操作和分析，因为关于 coze.cn 及其与火山引擎集成的具体细节在现有研究材料中相对缺乏。我们假定其核心的知识库和工作流机制在原理上是相似的。这构成了本次研究的一个限制条件，本人在操作过程中也遇到了类似的网络问题，但设法通过其他途径获取了必要信息。

1.3. 为何需要知识库与工作流？

单纯依赖大型语言模型（LLM）构建智能体存在固有局限性。LLM 的知识截止于其训练数据，无法获取实时信息，并且可能产生不准确或完全虚构的“幻觉”内容 8。为了构建真正实用、可靠的智能体，必须引入外部知识源进行“接地”（Grounding），并通过自动化流程处理复杂任务。这正是知识库（KB）与工作流（Workflow）发挥关键作用的地方。知识库，特别是像火山引擎这样可能提供的企业级知识库，能为智能体提供准确、最新的领域知识 12。检索增强生成（RAG）技术则负责在需要时从知识库中检索相关信息，并将其融入 LLM 的处理过程，显著提升回答的准确性和相关性 10。工作流则赋予智能体执行多步骤任务、实现复杂逻辑和与外部系统交互的能力，使其超越简单的问答，成为能够处理实际业务流程的自动化助手 1。

1.4. 报告结构

本报告将遵循以下结构展开：

1. 核心概念解析：深入阐释 AI 智能体、LLM、知识库、RAG 和工作流的关键定义、原理和相互关系。

2. 智能体构建实战（模拟）：模拟在 Coze.cn 平台上创建智能体的详细步骤，包括设置身份、配置提示词。

3. 火山引擎知识库集成（模拟）：探讨在 Coze 中创建和管理知识库的过程，重点关注内容导入、分块策略和检索配置，并讨论火山引擎知识库可能的集成方式。

4. 火山引擎工作流设计与实现（模拟）：介绍 Coze 工作流的设计理念、关键节点类型、变量使用，以及如何构建 RAG 流程和集成火山引擎相关功能（推测）。

5. 智能体测试与评估：讨论评估 RAG 智能体性能的关键指标和方法。

6. 总结与建议：回顾构建过程，总结关键要点，并提出优化建议。

2. 理解核心概念：构建智能体的基石

在深入实践之前，透彻理解构成现代 AI 智能体的核心技术概念至关重要。这些概念不仅是理论基础，更直接影响着智能体的设计、功能和性能表现。

2.1. AI 智能体（Agent）：超越传统聊天机器人

AI 智能体并非简单的聊天机器人。它们是能够感知环境、进行推理、做出决策并自主采取行动以实现特定目标的软件系统 22。与仅能根据预设规则或脚本进行响应的传统机器人相比，AI 智能体展现出更高程度的自主性（Autonomy）、适应性（Adaptability）和目标导向性（Goal-oriented） 22。

其关键特征包括：

• 感知（Perception）：通过传感器（物理或软件接口）收集环境信息，例如用户输入、API 数据、传感器读数 23。

• 推理（Reasoning）：利用逻辑和已有知识处理感知到的信息，进行分析、判断和预测 22。

• 规划（Planning）：为达成目标制定行动策略，分解复杂任务为可执行步骤 22。

• 行动（Action）：根据决策执行任务，与环境或其他系统交互 22。

• 学习与适应（Learning & Adaptation）：从经验中学习，根据反馈调整行为，持续优化性能 22。

Coze 平台将智能体定义为基于对话的 AI 项目，它能通过 LLM 自动调用插件或工作流来执行特定业务流程并生成响应 2。这意味着 Coze 提供的“智能体”概念，其能力边界远超基础问答，其复杂性和“智能”程度很大程度上取决于开发者如何利用平台提供的工具（特别是工作流）来设计其行为逻辑 21。一个 Coze 智能体可以是一个简单的信息查询助手，也可以是一个能执行多步骤自动化任务的复杂系统，这完全取决于构建者的设计意图和实现深度。

2.2. 大型语言模型（LLM）：智能体的认知核心

大型语言模型是驱动当前 AI 智能体语言理解和生成能力的核心引擎 8。它们通常基于 Transformer 架构 34，通过在海量文本数据上进行自监督学习 34，掌握了语法、语义、语用乃至一定程度的世界知识。LLM 就像智能体的“大脑” 22，使其能够：

• 理解自然语言输入（用户查询、文档内容）。

• 生成连贯、相关的文本输出（回答、报告、代码等）8。

• 执行文本相关的任务，如摘要、翻译、分类 9。

Coze 平台集成了多种 LLM 供用户选择（海外版提及 OpenAI、Google、Anthropic 等 2，国内版可能主要是字节跳动自研模型及国内合作伙伴的模型 1）。然而，必须认识到 LLM 的局限性：

• 知识陈旧：LLM 的知识停留在训练数据截止日期，无法了解最新事件或信息 10。

• 事实不准确/幻觉：可能生成看似合理但与事实不符的内容 8。

• 缺乏领域深度：对于特定专业领域的知识可能不够深入或准确 12。

• 偏见：可能反映训练数据中存在的偏见 8。

这些局限性凸显了单纯依赖 LLM 构建可靠智能体的风险。智能体的价值实现，往往需要将 LLM 的通用语言能力与外部的、可信的、最新的知识源相结合。这正是知识库和 RAG 技术发挥作用的关键所在。可以说，Coze 这类平台的真正价值，很大程度上在于其能够便捷地整合这些增强机制 2，弥补 LLM 的短板。

2.3. AI 知识库（KB）：为智能体注入事实与领域专长

AI 知识库是一个利用 AI 和机器学习技术来存储、管理、理解和检索信息的中心化数字存储库 13。它超越了传统知识库仅作为静态信息容器的角色，通过 NLP 理解用户查询意图，并通过 ML 持续学习和优化检索结果 13。Coze 平台通过其“知识”（Knowledge）功能实现了这一概念 12。

AI 知识库通常包含多种类型的内容：

• 结构化知识（Structured Knowledge）：格式规整、易于查询的信息，如 FAQ、操作指南、产品规格表 13。Coze 支持表格类型知识库，甚至可以进行 NL2SQL 查询 15。

• 非结构化知识（Unstructured Knowledge）：缺乏固定格式的信息，如 PDF 文档、Word 文件、网页内容、邮件、聊天记录 13。这是 RAG 最常处理的数据类型。Coze 支持导入多种文档格式（txt, pdf, doc, docx）和在线网页内容 15。

• 自动化知识（Automated Knowledge）：由 AI 自动生成、更新或建议的内容，例如基于用户反馈自动生成的问答对，或识别出的知识空白点 13。

在 Coze 中集成知识库（尤其是像火山引擎这样可能提供的企业级知识库）的主要好处包括：

• 提升准确性：为 LLM 提供可靠的事实依据，减少幻觉 12。

• 领域专业性：补充 LLM 可能缺乏的特定行业或公司内部知识 12。

• 知识时效性：可以通过更新知识库来为智能体提供最新信息，而无需重新训练 LLM 11。

• 一致性保障：确保智能体基于统一、标准化的信息源进行回答 13。

知识库并非一劳永逸的解决方案。其有效性高度依赖于内容的质量、组织方式以及更新维护 12。因此，知识库的管理——包括内容的选择、导入、结构化处理（特别是分块策略）以及持续更新——是构建高性能 RAG 智能体不可或缺的一环。这表明，智能体的构建工作，在某种程度上也是一项数据工程和知识管理的工作。

2.4. 检索增强生成（RAG）：连接 LLM 与知识的桥梁

检索增强生成（RAG）是一种关键的 AI 框架，它将信息检索（Information Retrieval）系统的能力与大型语言模型的生成能力相结合 10。其核心思想是在 LLM 生成回答之前，先从外部知识库（如 Coze 中的知识库）中检索与用户查询相关的最新、最权威的信息片段，并将这些信息作为上下文（Context）提供给 LLM。

RAG 的工作流程通常包括以下步骤 10：

1. 检索（Retrieval）：当用户提出查询时，RAG 系统首先使用用户的查询（可能经过重写优化 40）去搜索知识库。这通常涉及到将查询和知识库中的文本块（Chunks）转换为向量表示（Embeddings），然后在向量空间中查找语义最相似的文本块（Vector Search）10。Coze 提及其知识库支持向量检索和全文检索等多种方式 15，并可在工作流节点中配置检索策略 40。

2. 增强（Augmentation）：将检索到的相关文本块与原始用户查询结合，形成一个增强后的提示（Augmented Prompt）。这个提示同时包含了用户的原始意图和从知识库获取的相关背景信息。

3. 生成（Generation）：将增强后的提示输入给 LLM。LLM 基于这个丰富的上下文信息来生成最终的回答。

RAG 带来了显著的优势：

• 获取最新信息：克服 LLM 知识截止的问题 10。

• 事实接地：显著减少 LLM 产生幻觉的可能性，提高回答的准确性和可靠性 10。

• 领域适应性：使通用 LLM 能够针对特定领域或组织的知识进行回答，而无需进行昂贵的模型微调 11。

• 可解释性：理论上可以追溯回答所依据的知识来源（检索到的文本块），提高透明度 11。

• 成本效益：相比于重新训练或微调 LLM，维护和更新知识库的成本通常更低 11。

RAG 的成功并非自动保证。其效果高度依赖于检索阶段的质量 43。如果检索系统未能找到真正相关的信息，或者找到了不相关、甚至错误的信息，那么增强后的提示反而可能误导 LLM，导致生成更差的回答。这再次强调了知识库内容质量、合理的分块策略（Chunking Strategy）42 以及高效的检索和重排（Re-ranking）机制 40 的极端重要性。RAG 把 LLM 从一个“闭卷考试者”变成了一个“开卷考试者” 11，而“书本”（知识库）的质量和“查书技巧”（检索能力）与“学生”（LLM）本身同样重要。

2.5. 工作流（Workflow）：赋予智能体行动力和逻辑

AI 工作流自动化是指利用 AI 技术来编排和自动化一系列任务或业务流程，通常涉及到决策制定、与多系统交互以及对环境变化的适应能力 18。在 Coze 平台中，工作流是通过可视化的画布界面，将不同的功能节点（Nodes）连接起来实现的 1。

工作流在 AI 智能体中的作用是：

• 实现复杂逻辑：超越简单的“输入-输出”模式，执行包含条件判断、循环、并行处理等多步骤的复杂任务 20。

• 集成多种能力：将 LLM 的推理能力、知识库的检索能力、插件提供的外部工具（如网络搜索 50、API 调用）以及自定义代码的功能组合在一个流程中 21。

• 任务自动化：自动执行重复性或标准化的业务流程，提高效率 18。

• 与外部系统交互：通过插件节点或 HTTP 请求节点与外部 API、数据库或其他服务进行数据交换和操作 21。这对于集成火山引擎的特定服务可能至关重要。

Coze 工作流提供了丰富的节点类型，例如：

• 基础节点：开始、结束、条件判断、循环、变量赋值等 21。

• 核心 AI 节点：LLM 调用节点、知识库检索节点 32。

• 集成节点：插件节点、HTTP 请求节点、代码节点（支持 Python、Node.js 等）21。

• 高级节点：工作流嵌套节点、数据库操作节点（如果使用 Coze 内建数据库）32。

工作流是智能体“智能”和“行动力”的具体体现。它们定义了智能体如何响应输入、如何利用可用资源（LLM、KB、工具）、如何处理信息以及如何最终达成目标。设计良好、健壮的工作流是构建高性能、能够解决实际问题的 AI 智能体的关键。掌握 Coze 的工作流构建器及其各种节点的功能，是充分发挥该平台潜力的核心技能。

3. 构建智能体实战（模拟 Coze.cn 体验）

基于对核心概念的理解，现在我们开始模拟在 Coze.cn 平台上构建智能体的过程。由于直接访问 Coze.cn 可能受限 6，且缺乏火山引擎集成的具体文档，以下步骤主要基于 Coze 通用功能和.com 版本的文档进行模拟，旨在还原核心操作流程。

3.1. 平台访问与工作空间设置

第一步是访问 Coze.cn 平台（https://www.coze.cn/）1。通常需要注册或登录账户。Coze.com 支持 Google 账号登录 53，Coze.cn 可能提供国内常用的登录方式（如手机号、微信等）。

登录后，首先接触到的是工作空间（Workspace）的概念 12。工作空间是组织和管理智能体、知识库、插件等资源的基本单位。Coze 通常会自动创建一个个人工作空间，其中的资源默认是私有的 12。对于团队协作，可以创建或加入团队工作空间，实现资源共享 12。对于本次构建任务，本人选择在个人工作空间中进行操作，以确保资源的独立性。

3.2. 创建智能体：赋予身份与核心指令

智能体的创建是整个过程的起点。

1. 发起创建：在工作空间主界面，通常在左上角或显眼位置可以找到“创建 Bot”（Create Agent）或类似 ‘+’ 的按钮 1。点击该按钮。

2. 基础信息：系统会要求输入智能体的“名称”（Name）和“功能描述”（Function Description）1。名称应简洁明了，描述则应清晰概括智能体的核心用途。还可以选择或自动生成一个图标（Avatar）3。Coze 也提供了“AI 创建”（Create with AI）的选项，通过自然语言描述需求来自动生成智能体配置 3，但为了更好地控制和理解配置过程，本人选择“标准创建”（Standard Creation）。点击“确认”后，进入智能体的编辑界面。

3. 核心配置：人设与提示词（Persona & Prompt）：这是定义智能体行为基调的关键环节 1。在此面板中，需要精心编写提示词，设定智能体的：

   • 角色（Role）：它扮演什么角色？（例如，“一位专业的火山引擎技术顾问”）

   • 目标（Objective）：它的主要任务是什么？（例如，“解答关于火山引擎知识库和工作流的问题，并基于提供的知识库进行回答”）

   • 技能（Skills）：它应该具备哪些能力？（例如，“能够理解用户问题，检索相关知识，使用工作流执行特定查询，并生成清晰的回答”）。这里可以预先说明后续会添加知识库和工作流。

   • 语言风格（Tone & Style）：它的沟通风格是怎样的？（例如，“专业、严谨、乐于助人”）

   • 限制与约束（Constraints）：哪些是它不能做或应该避免的？（例如，“不得回答知识库范围之外的问题”，“避免推测性表述”，“回答必须基于提供的知识”）

   提示词建议使用结构化的方式编写，例如使用 Markdown 格式 50。一个清晰、详尽的提示词能够极大地引导 LLM 的行为，使其表现更符合预期。Coze 平台还提供了一个“自动优化提示”（Auto-optimize prompt）的功能，可以帮助将自然语言描述的提示词优化为更结构化的格式 50。

   下面是一个简单的智能体创建流程示意图：

初始提示词的质量直接关系到智能体后续功能（如知识库调用、工作流触发）的可靠性。本人在测试中发现，如果提示词没有明确指示智能体在特定情况下（例如，回答其不确定的问题时）应该使用知识库或某个插件/工作流，那么即使这些技能已经被添加，智能体也可能不会按预期调用它们 50。因此，提示词不仅是设定“性格”，更是设定“操作规程”的基础。在这个阶段，稍微加入一些口语化或者不太规整的表达，有时反而能让模型输出更自然的语言，当然这个需要把握好度。

3.3. 集成火山引擎知识库（模拟流程）

（免责声明：由于缺乏火山引擎在 Coze.cn 中集成的具体文档，以下步骤描述的是 Coze 通用的知识库集成流程。我们假设火山引擎知识库会通过这些标准机制接入，但这可能需要火山引擎方面提供特定的连接器、API 配置或特殊的知识库类型，这些细节在当前资料中无法确认。）

知识库是让智能体能够基于特定、可信数据进行回答的关键。集成火山引擎知识库（假设其为一个外部数据源或 Coze 内的一种特殊 KB 类型）的过程大致如下：

3.3.1. 创建知识库资源

• 首先，需要在 Coze 的资源库（Resource Library）中创建知识库 7。导航至“资源库”->“知识库”部分。

• 点击“创建知识库”（Create Knowledge）7。

• 输入知识库的名称（例如，“火山引擎产品文档库”）、描述和图标 12。点击确认。

3.3.2. 导入知识内容

这是将火山引擎相关数据（如产品文档、API 手册、最佳实践指南等）填充到知识库的核心步骤。Coze 提供了多种导入方式 7：

• 本地文件上传：如果火山引擎的文档是 PDF、Word、TXT 等格式，可以直接上传 15。对于结构化数据（如 API 参数列表），可以使用 CSV 或 Excel 文件 15。本人尝试上传 PDF 文件，过程比较顺畅。

• 在线数据

  网页抓取：如果火山引擎有公开的在线文档站点，可以使用 Coze 的网页内容收集功能。提供基础 URL，“批量添加”（Batch Add）可以尝试自动抓取所有相关页面；“添加单个”（Add One）则可以逐一添加特定页面 URL 7。需要注意，批量添加并非对所有网站都有效，遇到问题时需切换到手动添加单个 URL 7。

  API 导入：如果火山引擎提供 API 来获取其知识数据，可以使用 Coze 的 API 导入功能（或在工作流中使用 HTTP/代码节点获取数据再写入）15。这是集成动态或私有数据的常用方式。

• 第三方渠道：Coze 支持从 Lark 文档/表格、Notion 等导入 15。如果火山引擎的资料存储在这些平台，可以考虑使用。

• 自定义输入：对于少量、特定的知识点，可以直接在 Coze 界面手动输入 15。

选择哪种方式取决于火山引擎知识数据的可用格式和访问方式。对于大量文档，本地上传或网页抓取可能是起点；对于需要实时更新或结构化的数据，API 导入可能更合适。

下表总结了 Coze 知识库的主要导入方法及其适用场景：

导入方法	支持格式	典型用途	来源示例	注意事项
本地文档（文本）	.txt,.pdf,.doc,.docx	文本问答、语料补充	从电脑上传	适用于手册、报告等
本地文档（表格）	.csv,.xlsx	NL2SQL 查询、数据计算	从电脑上传	用于结构化数据分析
本地图片	.jpg,.jpeg,.png	图片生成匹配	从电脑上传	用于视觉素材库
在线数据（网页）	网页内容	文本问答、获取最新信息	输入 URL(s)	自动收集 7，支持批量/单个添加
在线数据（API）	API 返回的数据	动态数据集成	配置 API 调用	适用于结构化/非结构化数据流
第三方渠道	Lark 文档/表格, Notion 等	集成现有文档	连接账户	简化从这些平台的导入过程
自定义输入	手动输入的文本/表格数据	小数据集、快速添加	在 UI 中输入	适用于少量、特定的知识点

3.3.3. 内容准备：分块（Chunking）的重要性

将原始文档导入知识库后，一个至关重要的步骤是将其分割成更小的、语义完整的单元，即“分块”（Chunking）42。这是因为 LLM 的处理能力（上下文窗口）有限，并且 RAG 的检索效果通常在较小的、聚焦的文本块上更好。块（Chunk）的大小需要在包含足够上下文和保持检索精度之间取得平衡 42。

Coze 在通过 URL 导入内容后，提供了一个“自动分段和清洗”（Automatic Segmentation & Cleaning）的步骤 7。这表明 Coze 会执行某种默认的分块逻辑。然而，理解不同的分块策略及其优劣，对于优化 RAG 性能至关重要，即使平台的直接控制选项有限。常见的分块策略包括 42：

• 固定大小分块（Fixed-Size Chunking）：按固定字符数或 Token 数分割，简单直接，但容易切断句子或段落，破坏语义完整性 42。

• 递归字符分块（Recursive Character Text Splitting）：尝试按段落（如 \n\n）、句子（如 .）、或其他分隔符进行层级分割，尽可能保持语义单元的完整性 42。这通常比固定大小分块效果更好，本人在 LangChain 实践中也倾向于此方法。

• 语义分块（Semantic Chunking）：利用文本嵌入（Embeddings）技术，将语义相似的句子组合在一起形成块 42。理论上能更好地保留上下文，但计算成本较高，且有时可能因为过于关注语义而忽略文档的结构（例如，将标题与不相关的内容分到一起）58。

• 文档结构分块（Document-Specific Chunking）：基于文档的固有结构（如 Markdown 的标题、列表、代码块，或 PDF 的章节）进行分割 42。如果源文档结构良好（例如，格式化的火山引擎 API 文档），这种方法效果可能最佳 45。

• Agentic 分块：一种较新的实验性方法，让 LLM 自行判断如何根据语义和结构进行最佳分割 42。

此外，“块重叠”（Chunk Overlap）也很重要，即让相邻的块之间有部分内容重叠，有助于在块的边界处保留完整的上下文信息 42。

下表概述了主要的 RAG 分块策略：

策略	机制	优点	缺点	适用场景 (据资料)	相关资料
固定大小	按固定字符/Token 数分割（可带重叠）	实现简单，块大小统一 55	忽略语义/结构，可能生硬截断 55	格式统一的文本，日志 55	42
递归字符	按分隔符（如 \n\n, \n, .）层级分割	尝试保持段落/句子完整性 42	效果依赖分隔符和文本本身	通用文本文档 42	42
语义分块	按句子嵌入向量的相似度分组	块内语义连贯性强 42	计算量大，可能破坏文档结构 58	叙事性文本，强调上下文连贯性	42
文档结构	基于文档格式（如 Markdown 标题、表格）分割	保留逻辑结构 42	要求源文档结构良好 45	手册，结构化报告，代码 42	42
Agentic (实验性)	LLM 判断最佳分割点（结合语义与结构）	可能实现类似人类的理解 42	实验性，结果难预测，成本可能高	需要精细理解的复杂文档	42

虽然 Coze 的自动分块可能隐藏了这些细节，但理解这些策略有助于评估其效果，并在必要时（例如，通过预处理源文档）进行优化。

3.3.4. 索引与检索配置

分块完成后，Coze 会自动对这些文本块进行索引（Indexing），通常是创建向量嵌入并存入向量数据库，以便后续进行快速的语义相似度检索 55。火山引擎可能提供其优化的索引服务。

在 Coze 中，可以配置知识库的检索行为，这通常在知识库设置或工作流的“知识库检索”节点中完成 40：

• 检索策略（Retrieval Strategy）：Coze 支持多种策略，如语义相似度检索（最常用）、全文检索等 15。选择哪种策略取决于查询类型和知识库内容。

• 返回块数量（Recall Number）：可以设定每次检索返回最相关的文本块数量（默认通常是 3 或 5）40。数量太少可能丢失关键信息，太多则可能引入噪声并增加 LLM 处理负担和成本。这是一个需要根据实际测试调整的关键参数。本人测试发现，调整这个数量对最终答案影响很大。

• 查询重写（Query Rewriting）：Coze 默认启用此功能 40。它利用对话历史来理解用户当前查询的真实意图，生成一个更适合检索的内部查询。例如，如果用户先问“Coze 知识库是什么？”，接着问“怎么用？”，查询重写会将第二问理解为“Coze 知识库怎么用？” 40。

• 结果重排（Re-ranking）：Coze 提到会对检索到的结果进行重排，将最相关的内容置于顶部 40。高级 RAG 系统通常会使用专门的重排模型来进一步优化检索结果的排序 10。

• 表格知识库的 NL2SQL：如果知识库是表格形式，Coze 可以将用户的自然语言问题（如“统计一下华东区的销售额”）转换为 SQL 查询语句，在表格上执行并返回结果 15。

3.3.5. 将知识库关联到智能体

创建并配置好知识库后，需要将其与智能体关联起来。

• 在智能体的“开发”（Develop）页面，找到“技能”（Skills）或类似区域下的“知识库”（Knowledge）选项。

• 点击添加（通常是 ‘+’ 图标），从资源库中选择刚刚创建的火山引擎知识库 7。

• 一个智能体可以关联多个知识库 40。

• 确保所选知识库处于“启用”（Enabled）状态 12。

完成这些步骤后，智能体原则上就具备了访问和利用火山引擎知识库信息的能力。但其能否有效利用，还取决于工作流的设计和 LLM 的提示。知识库的配置并非简单上传文件，分块和检索设置是需要仔细考量和反复试验的关键调优参数 43。

3.4. 设计与实现工作流（模拟火山引擎集成）

（免责声明：同样，假设火山引擎的功能会通过 Coze 的标准工作流机制（如特定节点、插件或 API 调用）来集成。）

工作流是智能体执行复杂任务、实现 RAG 逻辑、与外部系统（如火山引擎服务）交互的核心。

3.4.1. 进入工作流画布

可以在“资源库”中创建可复用的工作流，也可以在智能体的“开发”页面 -> “工作流”（Workflows）部分直接创建或添加 20。本人更倾向于在资源库创建，便于管理和复用。创建后，会进入一个可视化的画布界面，默认包含一个“开始”（Start）节点和一个“结束”（End）节点 20。

3.4.2. 理解工作流核心概念

• 节点（Nodes）：工作流的基本构建单元，每个节点执行一项特定功能，如调用 LLM、检索知识库、运行代码、进行条件判断等 20。节点有输入（Inputs）和输出（Outputs）21。

• 连接（Connections）：通过将一个节点的输出连接到另一个节点的输入，来定义数据的流向和任务的执行顺序 21。画布上会直观地显示这些连接 21。

• 工作流（Workflow） vs. 对话流（Chatflow）：Coze 区分这两种类型 21。标准 Workflow 通常用于处理功能性请求（如生成报告），按顺序执行节点。Chatflow 则更侧重于通过对话与用户交互，管理复杂的对话逻辑（可能包含特殊的对话节点）。对于典型的 RAG 应用，通常使用标准 Workflow。

3.4.3. RAG 智能体的关键工作流节点

构建一个基于火山引擎知识库的 RAG 智能体，很可能需要用到以下几类 Coze 工作流节点：

• 开始（Start）节点：定义工作流的触发方式和输入参数，例如接收用户的查询文本 20。

• 知识库检索（Knowledge Base Retrieval）节点：这是 RAG 的核心检索步骤。需要配置此节点以查询指定的火山引擎知识库，输入通常是来自开始节点的用户查询，输出是检索到的相关文本块列表 40。可以在此节点配置检索策略、返回块数量等参数 40。

• LLM 节点：调用大型语言模型进行文本生成或推理 32。对于 RAG，其输入通常需要包含两部分：原始用户查询（来自开始节点）和知识库检索节点输出的相关文本块。这两部分共同构成了增强后的提示。节点的输出即为 LLM 生成的最终回答。

• 代码（Code）节点允许执行自定义代码片段（支持 Python, Node.js 等）。这个节点非常灵活，可用于：

  数据预处理或后处理（例如，格式化检索到的文本块再喂给 LLM）。

  调用没有现成 Coze 插件的火山引擎 API。

  实现标准节点无法完成的复杂业务逻辑。

• 条件（Condition）节点：实现逻辑分支（if-then-else）21。例如，可以判断知识库检索节点是否返回了结果。如果找到结果，则执行 RAG 路径（调用 LLM 并传入上下文）；如果未找到，则可能执行另一条路径（例如，直接调用 LLM 回答，或返回“未找到相关信息”的提示）。

• 变量（Variable）节点（赋值/读取/合并）：虽然“变量”节点本身可能已弃用 33，但通过变量赋值（Variable Assign）、读取（在其他节点中引用）和合并（Variable Merge）节点来管理工作流中的数据状态至关重要 32。变量用于存储和传递中间结果，如用户查询、检索到的上下文、API 返回值等。

• 插件（Plugin）节点：调用 Coze 平台提供的预构建插件（如必应搜索 50）或开发者自己创建的插件 1。如果火山引擎提供了官方 Coze 插件，就可以通过此节点调用。

• HTTP 请求（HTTP Request）节点：直接向指定的 URL 发送 HTTP 请求（GET, POST 等）33。这是调用火山引擎 RESTful API 的另一种方式，前提是 API 不需要复杂的认证或处理逻辑（否则代码节点可能更合适）。

• 结束（End）节点：定义工作流的最终输出结果，这个结果将返回给调用该工作流的智能体，并最终呈现给用户 20。

下表总结了构建 RAG 智能体时常用的 Coze 工作流节点及其功能：

节点类型	主要功能	对 RAG / 火山引擎智能体的意义	相关资料
开始 (Start)	启动工作流，定义输入（如用户查询）	处理用户请求的入口点	20
知识库检索	查询指定知识库，检索相关文本块	RAG 核心步骤：获取接地上下文	33
LLM	调用大模型进行生成或推理	基于查询+上下文生成最终回答	21
代码 (Code)	执行自定义代码 (Python, Node.js 等)	数据处理，复杂逻辑，调用外部 API（如火山引擎特定服务）	21
条件 (Condition)	根据条件进行流程分支	控制流程，处理不同情况（如是否找到知识库结果）	21
变量赋值/读取	设置或获取变量值	管理状态，在节点间传递数据（查询、上下文、响应等）	32
插件 (Plugin)	执行预构建或自定义插件	访问外部工具/API（网页搜索，或自定义的火山引擎插件）	1
HTTP 请求	直接调用外部 HTTP API	调用火山引擎 API 的备选方案（若无插件）	33
工作流 (Workflow)	嵌套调用另一个工作流	模块化复杂逻辑，复用通用流程	21
结束 (End)	定义工作流最终输出	将生成的回答或结果返回给智能体/用户	20

3.4.4. RAG 工作流示例结构

一个基础的 RAG 工作流可能如下所示：

说明：用户查询首先进入知识库检索节点。如果检索到相关的文本块，则将查询和这些块一起传递给 LLM 节点生成回答。如果未检索到相关块，可以通过条件节点判断，转而让 LLM 节点仅基于用户查询生成一个标准回答（可能提示知识库中无相关信息）。更复杂的流程可能在 B 和 C 之间加入代码节点来处理或格式化检索到的文本块。

3.4.5. 使用变量管理数据流

工作流中的数据传递依赖于变量 32。一个节点的输出可以被后续节点作为输入引用。例如，知识库检索节点的输出（假设名为 retrieved_chunks）和开始节点的输出（假设名为 user_query）可以被 LLM 节点的提示（Prompt）输入引用，类似这样（具体语法可能依平台而定）：

请根据以下信息回答用户的问题：
用户问题：{{Start.user_query}}
相关资料：
{{KnowledgeRetrieval.retrieved_chunks}}
​
请根据以上资料回答用户问题。

理解和正确使用变量引用是构建有效工作流的基础。本人在实践中发现，变量名的准确性和节点间数据类型的匹配有时会比较“麻烦”，需要仔细调试。

3.4.6. 测试与异步执行

• 画布内测试：Coze 工作流编辑器通常提供“测试运行”（Test run）功能 20。可以输入模拟数据，然后观察每个节点的运行状态（成功/失败）以及具体的输入和输出值 20。这是调试工作流逻辑的关键步骤。

• 异步执行（Asynchronous Execution）：对于可能耗时较长的操作（例如，复杂的 LLM 调用、调用外部 API 如火山引擎服务、处理大文件等），同步执行可能导致智能体响应超时 20。Coze 允许将工作流配置为异步运行 20。启用后，当用户触发该工作流时，智能体会先快速返回一个确认信息（例如，“我正在处理您的问题，请稍候…”），然后在后台执行工作流。待工作流完成后，再将最终结果推送给用户 20。这对于保持良好的用户体验至关重要。需要注意异步执行的超时限制（Coze.com 文档提到整体 24 小时，LLM 节点 5 分钟，插件 3 分钟等 20）。

3.4.7. 发布工作流并关联智能体

工作流设计和测试完成后，需要先“发布”（Publish）它，才能被智能体调用 20。发布后，回到智能体的“开发”页面，在“工作流”部分添加这个已发布的工作流 20。

工作流的设计是一个结合了逻辑编排、节点配置和反复测试的迭代过程。虽然可视化画布降低了门槛，但要构建出健壮、高效、能够处理复杂场景（并可能与火山引擎等外部系统深度集成）的工作流，仍然需要清晰的思路、对各节点功能的深入理解以及细致的调试。异步执行等高级特性是保障实际应用性能的关键考虑因素。

4. 智能体测试与评估：确保质量与可靠性

构建智能体只是第一步，确保其按预期工作、提供准确可靠的响应，则需要系统性的测试和评估。对于集成了知识库和工作流的 RAG 智能体而言，评估尤其复杂，因为它涉及到多个可能出错的环节。

4.1. Coze 平台内置调试工具

Coze 提供了一些基础的调试能力：

• 智能体预览与调试面板：在智能体的“开发”（Develop）页面，通常有一个“预览与调试”（Preview & Debug）面板 1。可以在这里与智能体进行实时对话，观察其响应，并可能看到它调用了哪些技能（如插件、知识库、工作流）。这是快速验证基本功能和交互流程的主要方式。

• 工作流测试运行：在工作流编辑器中，可以使用“测试运行”（Test run）功能，输入模拟数据，检查每个节点的执行状态和输入/输出数据 20。这对于定位工作流内部逻辑错误非常有用。

• 多智能体节点调试：如果使用了多智能体模式，可以对特定的智能体节点进行调试 54。

这些内置工具对于开发阶段的快速迭代和问题定位很有帮助。然而，它们主要侧重于功能性测试和局部调试，对于全面评估 RAG 智能体的性能（特别是检索质量和生成质量）可能不够深入。

4.2. RAG 评估的特殊性：超越传统 LLM 评估

评估一个标准的 LLM 应用（如简单的文本生成或分类）可能侧重于输出的流畅性、相关性或准确性。但 RAG 系统增加了复杂性，因为它包含两个核心阶段：检索（Retrieval） 和 生成（Generation），两者都可能引入错误 5。

• 检索失败：可能未能从知识库中找到相关的文档片段，或者找到了不相关、甚至错误的片段。

• 生成失败：即使检索到了正确的上下文，LLM 在生成最终答案时也可能未能忠实地利用这些上下文（例如，忽略关键信息、添加无关内容、产生基于上下文的幻觉）。

因此，有效的 RAG 评估必须分别考察这两个阶段的性能，而不能仅仅看最终答案是否“看起来不错”。一个看似正确的答案，可能是基于错误的上下文生成的（侥幸猜对），或者一个错误的答案，其根源可能在于检索失败而非 LLM 本身的问题。

4.3. RAG 智能体关键评估指标

基于 RAG 的两阶段特性，评估指标也应相应地分为几类：

4.3.1. 检索质量评估（Retrieval Evaluation）

这类指标衡量从知识库（如火山引擎 KB）中检索到的信息片段（Chunks）的质量。

• 上下文相关性（Context Relevance / Precision）：检索到的文本块与用户原始查询的相关程度如何？5。这通常需要评估每个检索到的块。可以使用 LLM 作为评判者（LLM-as-judge）或通过人工评估来打分。Precision@k 则衡量在前 k 个检索结果中，相关结果所占的比例 5。高相关性/精度意味着检索系统能有效聚焦于与问题匹配的内容。

• 上下文召回率（Context Recall）：在知识库中所有真正相关的文本块中，有多少比例被成功检索出来了？5。这个指标需要预先知道哪些块是“应该”被检索到的（即需要“黄金标准” Ground Truth），评估起来更困难，但对于确保没有遗漏关键信息很重要。

• 命中率（Hit Rate）：一个更简单的二元指标，即是否至少检索到了一个相关的文本块？43。

• 平均倒数排名（Mean Reciprocal Rank, MRR）：衡量第一个相关文本块出现在检索结果列表中的平均位置 46。MRR 值越高，说明相关信息越快被找到。

• 上下文充分性（Context Sufficiency）：检索到的上下文是否足够全面，能够支持回答用户的问题？5。这通常也需要 LLM 或人工来判断。

4.3.2. 生成质量评估（Generation Evaluation - 基于检索上下文）

这类指标衡量 LLM 在给定检索到的上下文后，生成回答的质量。

• 忠实度 / 接地性（Faithfulness / Groundedness）：生成的回答是否严格依据检索到的上下文？是否包含了上下文中没有的信息（即基于上下文的幻觉）？是否与上下文内容相矛盾？5。这是衡量 RAG 系统是否有效利用知识库、减少捏造事实的关键指标。

• 答案相关性（Answer Relevance）：生成的回答本身是否切中用户原始查询的要点？5。这与上下文相关性不同，即使上下文相关，生成的答案也可能跑题。

4.3.3. 端到端评估（End-to-End Evaluation）

这类指标从整体上评估最终输出的质量，可能结合 Ground Truth 或直接面向用户查询。

• 答案正确性 / 准确性（Answer Correctness / Accuracy）：最终的回答是否在事实上正确地回答了用户的问题？5。这通常需要与一个已知的正确答案（Ground Truth）进行比较。

• 幻觉率（Hallucination Rate）：回答中包含与事实不符（无论是否基于上下文）的信息的频率 43。

• 相似度指标（如 BLEU, ROUGE）：如果存在参考答案，这些指标可以量化生成答案与参考答案在词语或序列上的重叠程度，常用于评估摘要或翻译任务 59。

4.3.4. 系统性能与其他指标

• 延迟（Latency）：智能体从接收查询到返回最终答案所需的时间 5。对于交互式应用至关重要。

• 成本（Cost） / Token 消耗：调用 LLM、向量数据库、API 等资源所产生的费用或消耗的 Token 数量 5。Coze 平台可能基于 Token 使用收费 2。

• 用户满意度（User Satisfaction）：通过用户评分、反馈、任务完成率等方式收集的定性或定量评价 46。

下表汇总了主要的 RAG 评估指标：

类别	指标名称	衡量内容	评估方法	是否需 Ground Truth	相关资料
检索	上下文相关性	检索到的块与查询的相关程度	LLM 评判 / 人工	否 / 是 (对比用)	5
	上下文精度 (@k)	Top-k 检索结果中相关块的比例	LLM 评判 / 人工	否 / 是	5
	上下文召回率	检索到的相关块占所有相关块的比例	确定性 / 人工	是	5
	命中率	是否至少检索到一个相关块	确定性 / 人工	是	43
	MRR	第一个相关块的平均排名倒数	确定性 / 人工	是	46
生成	忠实度 / 接地性	回答是否忠实于检索到的上下文	LLM 评判 / 人工	否	5
	答案相关性	回答是否切中原始查询要点	LLM 评判 / 人工	否	5
端到端	答案正确性 / 准确性	最终答案是否事实正确	LLM 评判 / 人工	是	5
	幻觉率	回答中包含捏造信息的频率	LLM 评判 / 人工	是 (通常)	43
	相似度 (BLEU/ROUGE)	回答与参考答案的文本重叠度	确定性	是	59
系统	延迟	响应时间	确定性	否	5
	成本 / Token 消耗	资源消耗情况	确定性	否	5
	用户满意度	用户反馈，任务成功率	问卷 / 日志分析	否	46

4.4. 解读测试结果与迭代优化

评估结果并非终点，而是优化的起点。通过分析各项指标，可以诊断 RAG 系统的问题所在：

• 低上下文相关性/精度：可能意味着知识库内容质量不高、分块策略不当（块太大或太小、语义割裂）、查询理解或向量嵌入有问题，或者检索算法需要调整。

• 低上下文召回率：可能说明相关的知识没有被纳入知识库，或者检索未能覆盖所有相关内容。

• 高相关性但低忠实度：说明检索系统工作良好，但 LLM 未能有效利用检索到的信息。这可能需要改进 LLM 的提示词，例如更明确地指示它必须基于提供的上下文回答，或者对上下文进行更好的格式化。本人在测试中就遇到过，提示词不够强硬，模型有时就“自由发挥”了，忽略了给它的资料。

• 高忠实度但答案不相关/不正确：这通常指向检索阶段的问题——检索到了不相关或错误的上下文，LLM 忠实地基于这些错误信息生成了答案。

• 高延迟：可能需要优化工作流逻辑、选择更快的 LLM 模型、优化 API 调用或考虑异步执行。

评估是一个持续的过程。基于评估结果，开发者需要不断迭代优化知识库内容、分块策略、检索参数、工作流设计以及 LLM 提示词，以达到最佳性能 46。仅仅依赖 Coze 内置的调试工具是不够的，建立一套系统的、基于量化指标的评估流程对于构建生产级别的 RAG 智能体至关重要。

5. 总结与建议

本次通过模拟操作和分析现有资料，我们系统性地探讨了在 Coze.cn 平台上构建集成火山引擎知识库与工作流的 AI 智能体的过程。

5.1. 构建回顾与核心要点

整个构建旅程始于对核心概念的理解——AI 智能体不仅仅是聊天机器人，它们是具备感知、推理、规划和行动能力的自主系统；LLM 作为认知核心，提供了强大的语言能力，但也存在局限性；知识库通过提供外部事实来弥补 LLM 的不足，实现接地；RAG 技术是连接 LLM 与知识库的关键桥梁；而工作流则赋予智能体执行复杂任务和自动化流程的能力。

随后，我们模拟了在 Coze 平台上的创建过程：从设置智能体身份和核心提示词（Persona & Prompt）开始——这是奠定智能体行为基调的基础；接着是集成知识库的关键步骤，包括内容导入、至关重要的分块（Chunking）策略选择以及检索参数配置；然后是设计工作流，通过连接不同的功能节点（LLM 调用、知识库检索、代码执行、条件判断等）来编排智能体的 RAG 逻辑和任务执行流程；最后强调了测试与评估的重要性，特别是针对 RAG 系统需要分别评估检索质量和生成质量的多维度指标体系。

Coze 平台的核心价值在于它显著降低了构建复杂 AI 应用的门槛 1，通过可视化的界面将 LLM、知识库、工作流、插件等强大功能整合在一起。然而，这种易用性并不意味着可以忽视底层原理。要构建出真正高性能、可靠的智能体，开发者仍需深入理解 RAG 机制、知识库管理（特别是数据质量和分块策略）以及工作流逻辑设计。

5.2. 关于 Coze 与火山引擎集成的思考

基于现有研究材料，Coze 平台展现了其作为 AI 应用开发平台的潜力，提供了构建知识增强型、具备自动化能力的智能体的基础框架 1。其可视化的工作流编辑器和对知识库的集成是其亮点。

关于与火山引擎的具体集成方式，由于缺乏直接文档，我们只能进行推测。集成可能通过以下途径实现：

1. 标准知识库接口：火山引擎的知识数据（如果能导出为 Coze 支持的文件格式，如 PDF, TXT, CSV）可以通过 Coze 的标准文件上传或网页抓取功能导入。

2. API 集成：更可能的方式是，通过 Coze 工作流中的“代码节点”或“HTTP 请求节点”调用火山引擎提供的 API 来查询其知识库或触发其工作流服务。这需要火山引擎提供相应的 API 接口，并且开发者具备一定的编程能力来配置这些节点。

3. 定制插件：理论上可以为火山引擎开发专门的 Coze 插件，将 API 调用封装起来，提供更友好的节点供工作流使用。

4. 特殊知识库类型：Coze.cn 平台内部可能直接内置了对火山引擎知识库的特殊支持类型，允许用户在创建知识库时直接选择并连接到火山引擎的资源。

无论哪种方式，要实现深度集成，很可能需要超越 Coze 的纯“无代码”范畴，涉及 API 理解、数据处理甚至少量编码工作。从现有资料看，火山引擎如何无缝嵌入 Coze 的用户体验中，这一点尚不完全明朗。

5.3. 优化与后续步骤

为了构建和维护一个高性能的基于 Coze 和火山引擎的 RAG 智能体，以下建议值得考虑：

1. 知识库是核心资产，持续投入

   内容为王：确保火山引擎知识库的内容准确、全面、及时更新 12。垃圾进，垃圾出。

   精研分块：不要满足于 Coze 的自动分块。根据火山引擎文档的特性（结构化程度、内容类型），尝试不同的分块策略（如基于 Markdown 结构 45 或递归字符分割 42），并通过评估指标 46 找到最优解。

   优化检索：试验不同的检索返回块数量 40，并关注 Coze 是否提供或未来可能提供更高级的检索/重排选项。

2. 工作流设计，追求健壮与效率

   模块化：对于复杂的火山引擎交互逻辑，考虑将其封装在可复用的子工作流中 52。

   错误处理：为关键节点（尤其是 API 调用、代码执行）设计合理的错误处理逻辑，避免流程中断 52。

   性能意识：识别耗时节点，优先考虑异步执行 20，优化代码节点效率，监控整体延迟。

   多智能体探索：如果任务可以清晰地分解为多个独立子任务，可以研究 Coze 的多智能体模式 54，但这会增加协调和调试的复杂性。

3. 提示工程，不可或缺的精调

   明确指令：在智能体的人设与提示词以及 LLM 节点的提示中，清晰指示模型如何使用检索到的火山引擎知识，强调忠实度和准确性 46。

   迭代优化：根据评估结果（特别是忠实度指标）不断调整提示策略。

4. 评估驱动，量化改进

   建立基准：创建一套包含代表性问题和（若可能）Ground Truth 答案的评估数据集 44。

   全面衡量：定期运行评估，考察检索和生成两方面的多项指标（参考 4.3 节表格），而不仅仅是最终答案的表面效果。

   用户反馈闭环：结合真实用户的使用反馈来指导优化方向 46。

5. 探索平台深度

   熟悉 Coze 的数据库功能（用于存储用户偏好等结构化记忆）51、插件生态 1 以及 API/SDK 62，这些都可能为与火山引擎的深度集成或构建更强大的智能体提供支持。

总之，利用 Coze.cn 和火山引擎构建智能体是一个充满潜力的方向。通过掌握核心概念，遵循结构化的构建流程，并持续进行测试、评估和优化，可以开发出能够解决实际问题、提供真正价值的 AI 应用。这需要技术理解、实践经验和对细节的关注——这正是一位 AI 平台技术顾问所能提供的价值。