最近在帮几个团队做 AI 应用落地时，我发现一个很有意思的现象：大家讨论最多的不是某个大模型有多强，而是如何把一个能聊天的 Demo，变成真正能在业务里跑起来的 AI 智能体。B 站上关于 Coze 教程的热度一直很高，从“扣子工作流怎么建”到“AI 智能体落地流程”，每天都有大量新问题出现。这篇文章会把零散的知识整理成一条主线，从 0 基础概念讲到企业级实战，全程以可复制的案例为主线，帮你真正掌握 Coze 智能体搭建、工作流编排和应用发布。
本文适合几类读者：想入门 AI 智能体的产品经理、运营同学、测试工程师，以及希望在项目中快速搭建智能体的后端开发。只要你愿意动手，按文章思路操作，半个小时内就能搭出一个能用的智能体。为了避免上来就看代码、看得一头雾水，我会先讲清楚 Coze、智能体、模型、Token、工作流这几个核心概念之间的关系，再带你拆解简历筛选、生成 PPT、软件测试工作台等真实场景。
1. 为什么零基础也能学会搭建 AI 智能体
1.1 零基础学习者最常见的三个卡点
很多同学学 Coze 学了一半就放弃，通常不是因为没有学习热情，而是被三个问题卡住了。
第一个问题是资料太散。B 站、公众号、技术社区里关于 Coze 的教程不少，有的是讲某个面板操作，有的是讲某个垂直场景，但很少有人把“从注册到发布”的完整链路串起来。收藏夹越来越满，真正动起手来还是不知道从哪里开始。
第二个问题是概念混乱。很多人分不清智能体、工作流、插件、知识库之间的关系，以为做一个“能聊天的机器人”就是智能体。结果做完以后发现，稍微复杂一点的业务需求根本接不住，回答不稳定，流程也写不清楚。
第三个问题是缺少工程化思维。新手往往用自然语言生成一个 Bot 就结束了，没有考虑输入输出格式、异常处理、知识库维护、发布渠道、成本控制这些问题。一旦放到真实业务里，就会频繁暴露不稳定、不可控、不可维护的痛点。
这篇文章要解决的，就是这三大类问题。
1.2 Coze 到底是什么，解决什么问题
Coze 的中文名是“扣子”，是字节跳动推出的 AI 智能体开发平台。它和传统编程开发的差别在于：用户可以通过自然语言对话或拖拽节点的方式，快速创建智能体，而不需要从零编写复杂的后端服务。
Coze 能做的事情可以概括为五个方面：
- 智能体搭建：设置人设、提示词、回复逻辑，生成一个面向特定任务的 Bot。
- 工作流编排：把复杂任务拆成多个节点，用流程控制逻辑串联起来，实现稳定、可复现的业务处理。
- 插件接入：调用平台自带插件或自定义 API，让智能体具备查询天气、访问数据库、调用企业系统等能力。
- 知识库管理：上传文档并进行向量化，让模型基于企业私有资料回答问题。
- 发布与集成：发布到飞书、微信公众号、微信客服等渠道，也可以生成 API 供自有系统调用。
对于企业来说，Coze 最大的价值是降低了 AI 应用的门槛。同样的智能体需求，如果用传统开发方式，需要处理模型接入、上下文管理、工具调用、部署运维等一系列问题；而 Coze 把这些能力做成了可视化的平台能力，业务同学也能直接参与搭建和迭代。
目前 Coze 有国内版和国际版之分，国内企业用户一般使用国内版即可满足需求。不同版本在功能范围、模型可选列表和发布渠道上可能存在差异，具体以你注册登录后的控制台为准。
1.3 智能体、模型、Token、工作流的关系
要理解 Coze，一定要先理清几个容易被混淆的概念。
大模型是智能体的“大脑”。它负责理解用户输入、生成回答、执行文本分析和内容创作。大模型本身只接收文本并输出文本，它并不知道怎么查数据库，也不知道企业内部的业务规则。
智能体是围绕一个或多个任务组织的“完整系统”。它包含人设提示词、模型参数、知识库、插件、工作流、记忆等能力。可以类比成企业里的一名员工，大模型是员工的大脑，插件是手里的工具，知识库是身后的资料室，工作流是公司的办事流程。
工作流是把任务拆解成固定步骤的“流程图”。当任务需要多个步骤、多个分支、多个工具配合时，直接用对话式 Bot 难以控制，需要靠工作流来保证执行顺序和逻辑稳定。简单场景可以直接用智能体，复杂场景必须上工作流。
Token 是模型处理文本的最小单位，可以简单理解成模型的“字数”。中文里 1 个 Token 大约对应 0.5 到 1 个字，具体取决于模型的分词规则。每次调用模型都会消耗 Token，这也直接决定了成本。
下面用一个表格快速对比：
| 概念 | 作用 | 生活中的类比 |
|---|---|---|
| 大模型 | 理解和生成文本 | 人的大脑 |
| 智能体 | 面向任务的完整 AI 系统 | 一个职员 |
| 工作流 | 编排固定业务流程 | 公司办事流程图 |
| 插件 | 调用外部能力 | 手里的工具 |
| 知识库 | 提供私有资料 | 资料室 |
| Token | 计费和上下文长度单位 | 字数 |
新手只要把这张表记住，后面学起来就会顺畅很多。
2. 平台注册与整体认识
2.1 注册与版本选择
在开始搭建之前，需要先注册一个 Coze 账号。
推荐使用 Chrome 或 Edge 浏览器操作。国内用户访问 coze.cn，如果只是学习或做个人项目，直接使用国内版即可。企业项目也建议优先考虑国内版的合规性。国际版功能更新节奏和国内版可能不同，两者不能混用账号和数据。
注册方式很简单，使用手机号或邮箱都能完成，也可以使用平台支持的第三方账号快捷登录。登录后建议先创建一个团队空间或者个人空间，把后续要做的智能体、工作流、知识库都放在同一个空间里，便于统一管理。
2.2 控制台功能地图
登录后第一次进入控制台，很多人会被左侧的菜单吓到。其实只要分清各个模块的职责，使用起来并不复杂。
| 模块 | 主要作用 | 什么时候用 |
|---|---|---|
| 智能体 | 创建和管理 Bot | 开始一个新项目时 |
| 工作流 | 编排复杂业务流程 | 任务需要多步骤、多分支时 |
| 知识库 | 管理上传文档 | 需要基于私有资料回答时 |
| 插件 | 接入外部工具和 API | 需要查询天气、调用业务系统时 |
| 数据库 | 存储结构化数据 | 需要动态读写数据时 |
| 触发器 | 定时或 Webhook 触发 | 需要自动化执行时 |
| 发布/集成 | 发布 Bot 到渠道或 API | 项目准备上线时 |
很多新手一上来就点进“智能体”开始对话，结果发现业务逻辑复杂以后根本管不住。我的建议是：先想清楚业务流程，再决定哪些功能用智能体直接承担，哪些功能必须用工作流编排。
2.3 一个智能体项目的组成结构
一个典型的 Coze 项目并不只有一个 Bot，而是包含多个组成部分。我习惯用下面的结构来规划项目空间：
你的工作空间/ ├── 知识库/ │ ├── 产品文档.xlsx │ └── 常见问题手册.docx ├── 插件/ │ └── 企业内部订单查询接口 ├── 数据库/ │ ├── 客户反馈表 │ └── 测试用例状态表 ├── 触发器/ │ └── 每日 09:00 定时生成日报 └── 智能体/ ├── 智能客服 Bot └── 数据分析 Bot这样组织的好处是：知识库可以复用，插件可以复用，数据库可以在多个 Bot 之间共享。项目规模越大，这种“先搭底座、再建 Bot”的思路越重要。很多人做失败，不是因为 Bot 做不出来，而是因为数据散落在各个对话里，没法沉淀成可复用的企业资产。
3. 智能体搭建的核心知识点
3.1 人设与提示词设计
智能体的人设和提示词决定了 Bot 的“性格”和“行为边界”。Coze 创建智能体时，通常有一个“人设与回复逻辑”输入框，这里的内容并不是随便写几句话就完事，而是需要按照业务目标设计结构。
我推荐使用“角色 + 任务 + 限制 + 输出格式”四段式结构。举一个最简单的例子：
# 角色 你是一名资深的 HR 面试官，负责帮助招聘团队初筛候选人简历。 # 任务 1. 阅读用户提供的简历文本，提取学历、工作年限、技能关键词。 2. 对照岗位要求评估匹配程度，并给出打分。 3. 输出结构化评估结果。 # 限制 - 不要臆造简历中不存在的信息。 - 如果简历信息不足，明确标注“信息不足”。 - 回答不要超过 300 字。 # 输出格式 请输出 JSON： { "score": 0-100, "recommendation": "强烈推荐/推荐/待定/不推荐", "reason": "一句话理由" }这样设计有三个好处：模型知道自己的身份，知道要完成哪些子任务，也知道用什么格式输出结果。相比只写“你是一个简历助手”，这种提示词在稳定性和可解析性上要好得多。
实际项目中，提示词不是一次写好的，而是需要反复测试和迭代。建议每轮测试只改一个变量，比如先调输出格式，再调任务拆分方式，避免一次改太多导致无法定位问题。
3.2 插件、知识库、数据库与长期记忆怎么选
Coze 提供了多种扩展能力，新手经常分不清什么时候该用插件、什么时候该用知识库、什么时候该用数据库。下面做一个区分：
| 能力 | 解决的问题 | 典型场景 |
|---|---|---|
| 插件 | 调用外部工具或 API | 查询天气、搜索新闻、调用订单接口 |
| 知识库 | 让模型基于私有文档回答 | 产品手册问答、制度查询、FAQ |
| 数据库 | 存储和读写结构化数据 | 记录客户反馈、维护用例状态 |
| 长期记忆 | 记住用户偏好和上下文 | 个性化推荐、多轮对话一致性 |
插件适合“动态获取外部信息”。模型本身没有联网能力，也没有访问企业内部系统的能力，插件是唯一的桥梁。企业使用插件时，最常做的是封装内部 API，让智能体能够查询订单、查询库存或提交工单。
知识库适合“静态知识问答”。把文档上传后，平台会对内容进行分段和向量化，用户提问时检索相关片段，再交给模型生成答案。这种技术通常被称为 RAG。知识库适合存放产品文档、规章制度、培训材料等相对稳定的内容。
数据库适合“动态业务数据”。如果数据需要频繁增删改查，比如客户反馈、测试用例状态、任务记录，那就应该存到数据库里。知识库不适合存储这种高频变化的动态数据。
长期记忆则用于跨会话保持上下文。比如用户上次提到了“优先关注支付成功率”，下次对话时智能体还能记得这个偏好。
3.3 模型选择与 Token 参数
创建智能体时，平台会提供多个模型可选。Coze 内置了多个大模型，包括字节自家的豆包系列，以及接入的第三方模型。实际可选模型会随平台更新变化，建议以创建时的模型列表为准。
不同模型的差异主要体现在中文理解、长文本处理、数学推理和输出格式遵循能力上。如果项目需要严格输出 JSON，尽量选择指令遵循能力强的模型；如果只是闲聊或简单问答，选轻量模型更划算。
与模型相关的一个重要参数是“最大 Token 数”。这个值决定模型单次生成回答的最大长度。设置太小，回答会被截断；设置太大，生成时间变长，成本也会上升。迭代提示词时，如果经常发现回答不完整，优先检查是不是 Token 上限设置过小。
需要注意，Token 成本和调用次数直接相关。同一个任务，如果用更短的提示词能完成，就不要写冗长的话；如果能用工作流里的固定逻辑替代模型生成，就不要让模型多跑一次。
4. 工作流从入门到实战
4.1 工作流的核心节点
工作流是 Coze 中用来编排复杂逻辑的核心能力。它把一件大任务拆成多个小步骤，每一步使用一个节点完成，节点之间通过字段引用传递数据。
常用的节点包括：
| 节点类型 | 作用 |
|---|---|
| 开始节点 | 定义工作流的输入参数 |
| 大模型节点 | 执行文本生成、提取、改写 |
| 条件判断节点 | 根据条件走向不同分支 |
| 代码节点 | 运行 Python/JavaScript 处理数据 |
| 插件节点 | 调用外部 API 或工具 |
| 知识库节点 | 检索知识库内容 |
| 数据库节点 | 查询或写入数据 |
| 结束节点 | 输出最终结果 |
下面用一个最简单的用户意图分流流程来演示：
开始 ↓ 大模型节点：解析用户输入 ↓ 条件判断：是否包含所需信息？ ├─ 是 → 插件节点：调用业务 API │ ↓ │ 结束节点：返回结果 └─ 否 → 结束节点：提示信息不足这个流程体现了工作流的核心思想：把“模型自由发挥”变成“流程严格控制”。模型只负责它擅长的理解和生成部分，流程的分支判断交给条件节点，外部数据获取交给插件节点，数据加工交给代码节点。这样即使模型偶尔输出不稳定，整体流程仍然可控。
4.2 在代码节点中处理结构化数据
工作流中经常需要处理结构化数据，例如把大模型输出的 JSON 字符串解析成字段，再根据规则计算业务指标。Coze 的代码节点支持 Python 和 JavaScript，入口参数名以平台实际模板为准。
下面以 Python 为例，展示如何计算候选人技能匹配度：
import json def main(input: str) -> dict: # input 是上游大模型节点输出的 JSON 字符串 data = json.loads(input) required_skills = data.get("required_skills", []) candidate_skills = data.get("candidate_skills", []) if not required_skills: return {"match_rate": 0, "level": "无法评估"} hit = [skill for skill in required_skills if skill in candidate_skills] rate = round(len(hit) / len(required_skills) * 100, 2) if rate >= 80: level = "强烈推荐" elif rate >= 60: level = "推荐" else: level = "待定" return {"match_rate": rate, "level": level}这里需要重点理解两个设计点：第一，输入输出尽量使用 JSON 结构，方便上下游节点引用；第二，代码节点要处理边界情况，比如技能列表为空，避免运行时异常。
在实际搭建时，代码节点通常不是第一个版本就写完整，而是先在“测试”面板里多传几组不同数据，确认输出结果符合预期后，再接入正式工作流。
4.3 工作流输入输出与变量引用
工作流中的节点之间通过变量引用传递数据，常见的引用形式是{{节点名.输出字段}}。如果你在下游节点参数里找不到某个字段，优先检查上游节点是否真的输出了该字段，或者字段名是否拼写一致。
设计工作流时，输入和输出要认真规划。开始节点的输入参数，决定了外部系统可以传入哪些数据；结束节点的输出结果，决定了调用方最终拿到什么数据。企业级场景下，建议统一使用 JSON 结构，方便对接飞书、API 或其他系统。
还要注意错误处理。很多工作流上线后出现问题，不是因为主流程不对，而是没考虑空值、缺失字段、外部接口超时等异常情况。建议在关键分支后面加默认值，或者用条件判断节点做兜底，避免上游字段为空时整个流程报错。
5. 企业级实战案例拆解
5.1 案例一：简历筛选工作流
简历筛选是人力资源场景里非常典型的需求，也是 Coze 工作流的最佳练习项目。
传统方式是 HR 人工阅读大量简历，效率低且标准难以统一。用 Coze 实现后，可以把解析、打分、推荐三个环节自动化，最终输出结构化结果，供招聘系统或 HR 直接使用。
工作流整体设计如下：
开始节点 输入：resume_text（简历文本）、job_requirement（岗位要求） ↓ 大模型节点 解析简历，提取学历、工作年限、技能、项目经验 ↓ 代码节点 计算技能匹配度，生成匹配率和推荐等级 ↓ 条件判断节点 是否满足最低学历或工作年限要求？ ├─ 是 → 结束节点：输出“推荐进入下一轮” └─ 否 → 结束节点：输出“待定/不推荐”大模型节点里的提示词可以这样写：
你是资深 HR 分析师。请从以下简历中提取： 基础信息、学历、工作年限、技能列表、项目经验。 然后评估与岗位要求的匹配程度。 请严格输出 JSON： { "name": "候选人姓名", "education": "学历", "experience_years": 数字, "skills": ["技能1", "技能2"], "score": 0-100, "recommendation": "强烈推荐/推荐/待定/不推荐", "reason": "一句话理由" } 简历内容：{{input}} 岗位要求：{{job_requirement}}为什么让大模型先输出 JSON，而不是直接让模型给结论？因为 JSON 格式方便后续代码节点继续处理，也方便对接企业人才库系统直接写入数据库。整个流程的关键，是通过“大模型负责理解、代码节点负责计算、条件判断负责决策”的方式，把不可控的模型输出变成了可控的业务规则。
5.2 案例二：一键生成 PPT 的智能体
内容生成类场景在 Coze 里的热度很高，一键生成 PPT 是其中的代表。
这个案例的思路可以分为三步：第一步，大模型根据用户输入的主题，生成 PPT 大纲；第二步，用代码节点把大纲转换成 Markdown 或其他格式；第三步，把内容交给 PPT 插件或用户自己导入办公软件。
大模型节点可以输出这样的结构化大纲：
{ "title": "Coze 智能体实战培训", "pages": [ { "title": "为什么需要 AI 智能体", "bullets": [ "传统对话机器人存在能力边界", "智能体可以调用工具和知识库", "Coze 降低了搭建门槛" ] }, { "title": "环境准备", "bullets": [ "注册平台账号", "创建团队空间", "了解核心模块" ] } ] }代码节点再把 JSON 转换成 Markdown 文本：
import json def main(input: str) -> dict: data = json.loads(input) lines = [f"# {data['title']}"] for page in data["pages"]: lines.append(f"\n## {page['title']}") for item in page["bullets"]: lines.append(f"- {item}") return {"markdown": "\n".join(lines)}这样用户拿到的是一个结构完整的内容大纲，可以直接复制到 PPT 工具中使用。如果平台内有 PPT 生成插件，也可以把大模型的输出继续传给插件节点，实现一键出片。是否需要接入插件，取决于你的实际场景和插件能力，不必为了“看起来高级”而强行增加链路。
5.3 案例三：软件测试工作台
软件测试也是企业里非常适合用智能体提效的领域。借助 Coze，可以搭建一个“软件测试工作台”，让测试人员用自然语言描述功能后，自动生成测试用例、测试数据和提醒。
工作流设计可以这样拆解：
- 用户在对话框中输入模块名称和功能描述，例如“登录功能核心用例”。
- 大模型节点调用平台模型，生成覆盖正常、异常、边界场景的测试用例。
- 代码节点解析用例列表，并转换成统一 JSON 格式。
- 数据库节点将用例状态写入测试用例表。
- 定时触发器每天执行一次，自动统计未关闭的用例数量并生成提醒。
测试用例生成节点的输出示例：
{ "module": "登录功能", "cases": [ { "title": "正确账号密码登录成功", "precondition": "已注册账号", "steps": ["访问登录页", "输入正确账号密码", "点击登录"], "expected": "跳转到首页" }, { "title": "密码错误提示", "precondition": "已注册账号", "steps": ["访问登录页", "输入错误密码", "点击登录"], "expected": "提示密码错误，不跳转" } ] }这类场景非常依赖企业自身的知识库。建议把历史 Bug 记录、测试规范、编码规范上传到知识库，让大模型在生成用例时参考企业内部标准。同时需要强调，自动生成的测试用例只能作为辅助，核心用例仍然需要测试专家评审后才能用于正式发版。生产环境中的数据操作，必须在测试环境充分验证并保留操作日志。
5.4 案例四：更多企业级场景矩阵
除了上面三个详细案例，Coze 还适合很多高频业务场景。下面列出一个 20 个场景的企业级案例矩阵，方便你找到适合自己的练手方向：
| 分类 | 场景 |
|---|---|
| 客服 | 智能客服机器人、工单自动分类 |
| 人力 | 简历筛选、面试预热助手、新人培训问答 |
| 行政 | 制度问答、会议室预订助手、活动运营助手 |
| 营销 | 营销文案生成、短视频口播脚本、活动策划助手 |
| 内容 | 一键生成 PPT、漫剧分镜脚本、文章改写 |
| 研发 | 测试用例生成、代码评审助手、技术文档问答 |
| 数据 | 报表解读、数据异常预警、周报日报生成 |
| 电商 | 商品评论分析、售后回复助手、品类推荐 |
每个场景的搭建思路都可以复用前面案例的方法：先用提示词定义人设和任务，再用工作流拆解步骤，最后按需接入知识库、插件、数据库和触发器。练手时不用追求一次做完 20 个，选择一个你业务中最痛的点开始，效果最明显。
6. 常见问题与排查思路
在实际使用 Coze 的过程中，会遇到不少报错或不符合预期的现象。下面整理了一份高频问题排查表：
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 工作流运行失败 | 上游节点字段引用错误、数据类型不匹配 | 检查节点输出字段名，统一 JSON 结构 |
| 智能体回答不稳定 | 人设提示词太泛、模型选择不合适 | 结构化提示词，逐项测试，调整模型 |
| 知识库检索不到内容 | 文档分段粒度过大、提问词与文档词汇差异大 | 优化文档分段，调整检索参数，增加同义词 |
| 插件调用报错 | 鉴权参数缺失、输入格式不符合要求 | 检查插件配置，按文档传参 |
| 回答被截断 | 最大 Token 数设置过小 | 调大 Token 上限，或压缩提示词 |
| 定时任务没有触发 | 时区配置错误、周期表达式不正确 | 确认北京时间时区，检查任务时间设置 |
| 发布到飞书或微信失败 | 权限不足、配置绑定错误 | 检查发布权限和应用配置 |
| 数据库写入失败 | 字段类型不一致、必填字段缺失 | 检查数据表结构，补充默认值 |
下面针对几个最容易踩坑的点做补充说明。
字段引用类型不匹配，是新手最常遇到的问题。比如大模型节点输出的是一个字符串，但代码节点期望输入的是 JSON 字符串，两者没有做好转换，就会出现解析失败。建议在代码节点中增加 try-except 或非空判断，保证上游异常时流程不会彻底中断。
知识库检索不到答案，不一定是平台问题，更多是文档质量的问题。如果上传的 PDF 或 Word 是图片扫描版，平台无法正常提取文字，检索效果会很差。建议优先上传可复制的文本型文档，并在上传前做好目录和分节。
定时任务没有触发，要特别注意时区。如果平台默认使用 UTC 时间，而你想要每天早上 9 点执行，需要配置为 UTC+8 对应的 1 点，或者查看平台是否支持直接设置北京时间。生产环境中的定时任务，上线前建议先手动触发一次，确认整个工作流能跑通。
7. 最佳实践与工程化建议
7.1 命名、版本与团队协作
随着智能体数量增多，命名规范会直接影响维护效率。建议采用“业务_动作_对象”的格式命名，例如“招聘_筛选_简历”“内容_生成_PPT大纲”。工作流中的节点名称也尽量用业务含义命名，避免叫“节点1”“节点2”。
版本管理同样重要。Coze 平台本身支持一定的版本记录能力，但在团队协作时，建议在团队空间里约定每次修改的备注内容，例如“新增技能匹配计算”“调整输出 JSON 字段”。这样一旦线上版本出现问题，可以快速定位改动点。
7.2 权限、密钥与数据合规
企业使用 Coze 时，最需要重视的是权限和密钥管理。不要把插件 API Key、内部接口 Token、应用密钥直接写在提示词里，也不要在测试对话中粘贴敏感信息。正确的做法是通过平台的密钥管理或环境变量能力存储，并设置最小访问权限。
知识库上传前，必须检查是否包含个人隐私、客户敏感数据或非公开商业信息。如果数据不能离开企业内网，需要优先评估私有化或专用网络方案，而不是直接把资料上传到公共平台。
数据写操作要格外谨慎。智能体涉及数据库写入、更新、删除时，建议增加二次确认节点，或者只授予只读权限，避免误操作污染线上数据。生产环境的任何变更，都应该遵循最小权限原则，并在测试空间先行验证。
7.3 测试、灰度与发布流程
智能体上线前，至少要经历四轮测试：单人测试、小范围用户测试、业务方验收测试、灰度发布。
单人测试阶段，重点验证主流程是否通顺，提示词是否稳定，工作流是否发生异常。小范围测试阶段，让 3 到 5 名目标用户试用，收集真实反馈。业务方验收测试时，业务负责人需要确认输出结果是否符合业务标准。最后再通过平台的发布能力做灰度，逐步放开到全员。
测试过程中，建议在关键工作流节点后增加临时输出或日志节点，记录每个环节的输入输出。这样即使出现异常，也能快速定位是模型问题、数据问题还是流程问题。
7.4 成本与性能优化
Coze 的计费核心是 Token 用量和节点调用量，优化成本的思路围绕“减少不必要的模型调用”展开。
能不用大模型的地方就不用。简单的分支判断用条件节点，固定文案用消息节点，批量数据处理用代码节点。只有需要理解语义、生成内容、抽取信息时，才使用大模型节点。
知识库检索也要控制范围。如果知识库文档数量很大，建议按照业务域拆分成多个知识库，并在工作流中通过输入参数指定检索范围，避免每次检索都扫描全量文档，既影响速度也增加成本。
8. 总结与下一步学习路线
到这里，我们基本上把 Coze 从概念到实战的完整链路梳理了一遍：先理解智能体、
