Coze 实战：零代码搭建 AI 智能体工作流

一、什么是 Coze（扣子）？

Coze（国内版叫「扣子」）是字节跳动推出的 AI 智能体（Agent）搭建平台。它把大模型、知识库、插件与工作流可视化地拼装成一个可对话的 Bot，无需写代码就能上线。对于技术博客、企业官网这类「想把站点内容变成可对话服务」的场景，Coze 是门槛最低的方案之一。它的核心关键词就是：Coze、扣子、AI 智能体、工作流。

和常见的开源方案相比，Coze 的优势是「开箱即用」：模型、向量库、发布渠道都托管好了。如果你想完全私有化、数据不出内网，可以参考我们之前的《Dify+Ollama 搭建本地知识库》（查看）；而 Coze 更适合快速验证与轻量上线。

关于 RAG（检索增强生成）的原理与落地，建议先读《RAG 从零搭建实战》（查看），理解「切分—向量化—召回—生成」四步，再看 Coze 如何把这四步封装成界面操作。

二、5 分钟搭一个「技术博客答疑助手」

进入 Coze 工作台，新建 Bot，填写名称与简介后，重点在「人设与回复逻辑」里写清楚 Bot 的身份边界。下面是一段可直接用的提示词模板：

# 人设与回复逻辑（Persona）
你是「fsdata 小助手」，一个懂技术博客运维的 AI 客服。
- 只基于【知识库】中的站点文档回答问题，不编造。
- 回答结尾给出相关文章链接（如已配置卡片）。
- 用户问到部署/发布故障时，先给排查清单，再给命令。
- 语气：专业、简洁、可操作。

写好人设后，先不接知识库，用几句日常提问测试它是否会「胡说」。确认基线行为合理，再进入下一步喂数据——这样能区分「模型本身的问题」和「知识库没召回」的问题。

三、知识库：把站点文档喂给模型

Coze 的知识库本质上是把你的文档做切分、向量化后做语义召回。操作链路：上传 Markdown/PDF/网页 → 自动或手动分段 → 配置召回数量（top_k）→ 在 Bot 中挂载。技术博客常见的「某篇教程怎么写」「某个报错怎么解」，只要文档进了知识库，Bot 就能基于原文回答，而不是凭记忆编造。

切分粒度与召回数量怎么定

召回质量取决于切分粒度与段落完整性。长文建议按「小节」切，而不是按固定字数暴力切；代码块尽量保持完整，否则模型拿到的片段会断章取义。召回数量一般设 3–5 条即可，过多反而稀释答案。如果你熟悉向量检索的底层，可对照《Embeddings 向量嵌入实战》（查看）理解 Coze 在背后做的事。

四、工作流（Workflow）：用节点编排复杂逻辑

当「一问一答」不够用时，就要上工作流。Coze 的工作流由若干节点串联：开始 → 知识库检索 → 大模型 → 结束，中间还能插条件分支、代码节点、HTTP 请求。它和 LangChain Agent 的工具调用 思路一致，只是用图形界面表达。下面是一段工作流导出的 JSON 骨架：

节点编排示例

{
  "nodes": [
    {"type": "start", "data": {"desc": "用户输入技术问题"}},
    {"type": "knowledge", "data": {"dataset_id": "site-docs", "top_k": 3}},
    {"type": "llm", "data": {
        "model": "deepseek-v3",
        "prompt": "基于以下资料回答用户问题：\n{{knowledge}}}\n问题：{{input}}"
    }},
    {"type": "end", "data": {"desc": "返回答案"}}
  ]
}

工作流的价值在于「可控」：你可以强制「先查知识库、再让模型答」，而不是把问题直接丢给模型。这和从零手写 ReAct 智能体（《手写 AI Agent》）是同一套思想，只是 Coze 把它变成了拖拉拽。

五、插件与多模型：扩展 Bot 的能力边界

Coze 内置插件市场，可让 Bot 调用联网搜索、图像生成、代码执行等能力。模型方面支持多家大模型切换，可按任务选「快模型」做路由、「强模型」做最终回答。注意：插件调用会产生额外延迟与配额消耗，客服类场景应默认关闭非必要插件，只保留知识库与必要的搜索。

六、发布到多端

Coze 支持一键发布到豆包、飞书、微信公众号、Web 嵌入与开放 API。技术博客最实用的两种：① 官网嵌入「对话挂件」，让访客在文章页直接问；② 通过开放 API 把 Bot 接进自有系统，做工单或站内信。

七、用开放 API 把 Coze 接进自有系统

当 Bot 需要嵌入你自己的后端（例如把读者提问转成工单），就用 Coze 的开放 API 在服务器端调用。下面是一段 Python 调用示例，注意 API Key 必须放在服务端，绝不能进前端代码：

import requests, json

COZE_API_KEY = "pat_xxxxxxxxxxxxxxxxxxxx"
BOT_ID = "739xxxxxxxxxx"

def chat(message, user_id="fsdata-visitor"):
    url = "https://api.coze.cn/v3/chat"
    payload = {
        "bot_id": BOT_ID,
        "user_id": user_id,
        "stream": False,
        "auto_save_history": True,
        "additional_messages": [
            {"role": "user", "content": message, "content_type": "text"}
        ],
    }
    headers = {
        "Authorization": f"Bearer {COZE_API_KEY}",
        "Content-Type": "application/json",
    }
    r = requests.post(url, json=payload, headers=headers, timeout=60)
    data = r.json()
    # 取最近一条 bot 回复
    for m in reversed(data.get("data", {}).get("messages", [])):
        if m.get("role") == "assistant":
            return m.get("content", "")
    return ""

print(chat("fsdata.site 上关于 PostgreSQL 慢查询的文章在哪？"))

如果你的业务需要把 Bot 产生的对话事件同步到内部系统（如新消息自动建单），可以注册 Webhook 接收事件推送：

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

@app.route("/coze/webhook", methods=["POST"])
def on_event():
    evt = request.get_json(silent=True) or {}
    if evt.get("event_type") == "conversation.message.create":
        # 把新消息转发到自有工单系统
        requests.post("https://ops.internal/ticket", json=evt, timeout=10)
    return jsonify({"code": 0})

八、Coze vs Dify vs 自建：怎么选

一句话建议：先用 Coze 跑通「知识库 + 工作流 + 发布」闭环，验证需求真实存在；等量起来、对数据合规有要求时，再迁移到 Dify 或自建。不要一上来就投入自建，避免还没验证需求就背上运维债。

九、避坑清单

Coze（扣子）把「AI 智能体 + 工作流 + 知识库 + 多端发布」压缩成了一套零代码界面，是技术站点快速拥有对话能力的首选试验田。先用它把闭环跑通，再谈 deeper 的私有化与定制化，才是性价比最高的路线。