Coze工作原理与应用实例实践

写在前面

Coze 适合快速搭建面向具体任务的 AI Bot。它不是单纯的聊天界面，而是把人设提示词、插件、工作流、知识库、记忆和发布渠道整合在一起。对于个人或小团队来说，Coze 的价值在于降低 Agent 应用的工程门槛：不必从零写后端、工具调用、状态管理和知识库检索，就能先把一个可用的流程搭出来。

这篇文章主要整理 Coze 的工作原理和几个实际应用场景。案例不全部展开，只选择几个工程上有代表性的方向：新闻检索、意图识别工作流、产品知识库问答、抖音文案提取与二创、联网搜索。它们分别对应插件调用、分支流程、RAG 知识库、内容处理和外部搜索。

当然新版的coze也能实现仅靠提示词开发项目，适合完全不看代码和工作流的情况，不适合AI开发学习。

一、Agent 与 Copilot 的区别

理解 Coze 前，先区分 Copilot 和 Agent。

Copilot 更像辅助工具，需要用户持续输入和反馈。它的主要目标是提高用户完成任务的效率，例如代码补全、文档润色、数据分析建议。Agent 的自主性更强，它通常围绕一个目标运行，可以调用工具、执行流程、访问知识库，并根据中间结果继续处理。

Coze 更接近低代码 Agent 平台。它通过 Bot 编排层统一管理人设、技能、插件、工作流和知识库。实际开发中，不建议把所有逻辑都写进提示词，而应根据任务稳定性选择不同模块。

二、Coze 的核心模块

Coze Bot 可以拆成五个核心模块。

实际使用时，可以按任务复杂度选择实现方式。

简单问答只需要人设与知识库。需要访问外部数据时，加插件。流程稳定、步骤较多时，使用工作流。需要长期记住用户偏好时，再考虑记忆。这个顺序可以避免一开始就把系统搭得过重。

三、搭建第一个 AI 新闻 Bot

新闻 Bot 是最小可用案例。任务很明确：用户询问 AI 新闻时，Bot 调用新闻插件，筛选 AI 主题相关新闻，并按一定规则输出。

创建过程可以分成三步。

提示词重点不是写“每天推送 AI 新闻”这一句话，而是明确什么时候调用插件、筛选什么内容、如何排序输出。

## 技能

### 技能 1：新闻查找

1. 当用户询问最新新闻时，先调用 getToutiaoNews 搜索人工智能相关新闻。
2. 从搜索结果中筛选 AI 主题相关内容。
3. 选择最重要的 5 条新闻。
4. 按时间升序排序，输出标题、时间和简要说明。

这个案例说明一个基本原则：插件不会自动等价于能力。Bot 是否正确调用插件，取决于人设与技能说明是否写清楚。如果不写工具使用规则，模型可能直接凭已有知识回答，导致结果不新或者不准确。

四、插件：把外部 API 接进 Bot

插件用于把外部 API 接入 Coze。一个插件可以包含多个工具，每个工具对应一个独立 API 服务。比如天气插件可以包含“查询当前天气”和“查询未来天气”两个工具，但同一个插件下的工具通常使用相同域名。

下面这张图展示了插件与工具的关系。插件负责统一域名、认证和基础配置；工具负责具体 endpoint、输入参数、输出解析和调试发布。

创建自定义插件时，一般按下面的流程处理。

以接入 OpenAI 兼容接口为例，基础 URL 可以配置为：

https://dashscope.aliyuncs.com/compatible-mode/v1

请求 Header：

Authorization: Bearer $DASHSCOPE_API_KEY
Content-Type: application/json

工具路径：

/chat/completions

插件适合封装外部能力，但不适合承载复杂业务逻辑。复杂逻辑应放在工作流中，由工作流控制节点顺序、条件分支和变量传递。

五、工作流：把多步骤任务稳定下来

工作流由多个节点构成。每个节点负责一个明确动作，例如调用插件、调用大模型、做意图识别、聚合变量或输出中间状态。相比直接让 Bot 自己决定所有步骤，工作流更稳定，也更容易调试。

5.1 搜索新闻工作流

最简单的工作流是“开始 -> 新闻插件 -> 结束”。它适合把一个插件能力包装成稳定入口。

开始节点 user_input
-> getToutiaoNews 插件 q = user_input
-> 结束节点 output = getToutiaoNews.news

这个流程的优点是简单，缺点是只能处理一种明确意图。如果用户可能问天气、新闻或其他问题，就需要引入意图识别和分支。

5.2 weather_news：基于意图识别的分支工作流

weather_news 是更有代表性的案例。它把用户输入分成三类：天气查询、新闻查询、其他。天气查询需要先从自然语言中抽取城市和时间，再调用天气插件。新闻查询可以直接把输入传给新闻插件。其他问题走兜底回复。

工作流节点设计如下。

天气分支中的大模型节点不是为了回答问题，而是做参数抽取。提示词应要求它只输出 JSON。

{
  "city": "青岛市",
  "province": "山东省",
  "towns": "即墨区",
  "start_time": "2024-07-18",
  "end_time": "2024-07-20"
}

变量聚合节点是这个工作流的关键。它把多个分支中语义相同的结果合并到一个出口。规则可以理解为：返回第一个非空值；如果全部为空，则返回 null。这样结束节点只需要读取一个 output，不用关心实际执行了哪个分支。

下面是一个完整的工作流效果图，重点看意图识别后的三路分支和变量聚合节点。

这个案例说明，工作流适合解决“步骤明确但用户表达不稳定”的任务。意图识别负责路由，大模型负责参数结构化，插件负责外部数据，变量聚合负责统一出口。

六、知识库：搭建产品问答助手

知识库用于解决模型缺少私有知识的问题。RAG 的基本逻辑是先检索相关文档，再把检索结果交给大模型生成回答。Coze 的知识库把文档上传、分段、索引、召回和 Bot 绑定做成了平台能力。

这里用产品知识助手说明。目标是让 Bot 回答产品使用、远程办公配置、部门访问控制、VPN 节点选择以及大模型价格等问题。数据来源可以包括产品手册、Word 文档、Excel 表格和官网网页。

6.1 数据准备

知识库质量取决于数据准备。不能把所有材料直接上传后就结束，而应先按问题类型整理信息源。

对于长文档，切分方式很重要。以远程办公最佳实践文档为例，一个文档中可能包含多个 VPN 配置场景。如果自动切分把多个场景混在一起，召回结果就会不稳定。更好的方式是在每个场景前人工添加分段标识，例如 ###，并把分段长度控制在 2000 左右。

6.2 表格知识库

价格表、模型计费、参数配置这类数据更适合表格知识库。比如大模型定价表可以包含模型品牌、模型名称、输入价格、输出价格。

模型品牌    模型          input价格    output价格
通义千问    Qwen-Turbo    0.002       0.006
通义千问    Qwen-Plus     0.004       0.012
通义千问    Qwen-Max      0.04        0.12

表格上传后需要做索引设置，否则用户问“Qwen-Turbo 费用多少”时，系统可能无法准确定位到对应行。

6.3 Bot 人设与知识库绑定

产品助手的提示词应强调三个点：只回答产品相关问题、先理解问题再检索、基于知识库生成回答。

# 角色
你是产品问答小助手。你能够理解用户问题，并从知识库中检索相关信息，再生成准确、简洁的回复。

## 技能

### 技能 1：问题理解和检索
1. 理解用户问题，识别关键信息。
2. 根据关键信息检索知识库。

### 技能 2：回答生成
1. 基于检索到的信息生成回答。
2. 不确定时说明知识库中没有足够信息。

## 约束
- 仅回答与产品相关的问题。
- 尽量使用清晰简练的语言。
- 不要编造知识库中没有的信息。

知识库配置中，搜索策略建议优先使用混合搜索。产品问答既有语义问题，也有精确字段问题，混合搜索比单纯向量召回更稳。

下面是产品助手的两个测试问题：一个查表格价格，一个查文档流程。

这个案例的重点不是界面，而是知识库设计方法。文档类知识要关注切分，表格类知识要关注字段索引，Bot 提示词要约束回答边界。

七、LLM 联网搜索

联网搜索适合回答时效性强的问题，例如公司业绩、新闻事件、政策变化。直接让模型回答这类问题容易受到知识截止时间影响，因此需要搜索插件。

流程设计如下。

用户输入问题
-> 大模型提取关键词
-> Bing 搜索插件检索网页
-> 大模型总结搜索内容
-> 输出答案

关键词抽取节点的提示词可以很简单。

对用户的问题提取关键词，多个关键词用空格隔开，只输出关键词。

搜索结果总结节点则应要求模型基于搜索内容回答，不要补充没有来源的信息。

请基于输入的网页搜索结果进行总结，回答用户问题。
如果搜索结果不足以支撑结论，请明确说明。

下面是一个关于贵州茅台 2024 年销售业绩的搜索总结结果。

这个流程的优点是简单可控。缺点是搜索结果质量不稳定，可能包含重复网页、低质量摘要或过时信息。实际使用时可以增加网页筛选、来源去重、时间过滤和引用输出。

八、几个应用的选择条件

不同场景应选择不同的 Coze 能力，不需要所有功能都用上。

我的判断是，Coze 更适合快速验证 Agent 应用，而不是替代完整工程系统。适合先用 Coze 把业务流程跑通，验证需求、节点顺序、提示词和知识库组织方式。如果后续对性能、权限、安全、审计、日志、成本控制有更高要求，再考虑自建服务。

小结

Coze 的核心价值是把 Agent 应用拆成可配置模块。插件负责外部能力，工作流负责稳定步骤，知识库负责私有知识，记忆负责个性化状态，人设与回复逻辑负责约束模型行为。

实际搭建时，建议先从最小闭环开始：一个明确任务、一个 Bot、一两个插件或知识库。流程稳定后，再把复杂逻辑迁移到工作流中。对于多案例项目，不必把所有样例都做成完整系统，而应选择能代表关键机制的案例深入分析。这样后续迁移到自己的业务时，才能知道应该用插件、工作流、知识库，还是直接写提示词。