扣子（Coze）

如果说 LangGraph 代表了「工程师手写代码构建 Agent」的路线，扣子（Coze）代表的是另一条路：把 Agent 的搭建过程做成可视化产品，让不会写代码的运营、产品、教师、自媒体人也能在半小时内攒出一个能用的智能体。它是目前国内用户量最大的低代码 Agent 平台，也是观察「Agent 产品化」最好的样本之一。

这一页的目标不是教你点按钮（官方教程已经足够多），而是站在工程师视角回答三个问题：扣子到底是什么架构、它把哪些 Agent 工程问题藏进了产品里、以及你的团队应该在什么时候用它、什么时候绕开它。

一、定位：字节的低代码 Agent 平台全家桶

扣子是字节跳动推出的 AI 应用开发平台，核心叙事是「拖拽 + 配置」搭建 Agent，然后一键发布到各个渠道。需要先理清它的产品矩阵，因为「扣子」这个词在不同语境下指的是不同的东西：

产品	定位	形态
扣子开发平台（coze.cn / coze.com）	低代码 Agent/应用搭建平台，本页的主角	SaaS，国内版与国际版
扣子空间（Coze Space）	面向终端用户的通用 Agent（类 Manus），2025 年 4 月内测	SaaS
扣子罗盘（Coze Loop）	Agent 评测、观测、调优平台	SaaS + 开源
Eino	Go 语言的 LLM 应用编排框架（CloudWeGo 系）	开源框架
coze-studio / coze-loop（开源版）	上述两个产品的开源发行	Apache 2.0，可私有化部署

时间线大致是：2023 年 11 月先在海外上线 coze.com，2024 年 2 月国内版 coze.cn 上线（接豆包大模型），2025 年 4 月推出扣子空间对标通用 Agent，2025 年 7 月 26 日开源 Coze Studio 与 Coze Loop，2026 年 6 月 1 日发布扣子 3.0，转向多人 + 多 Agent 协作。

值得注意的一点：国内版和国际版几乎是两套产品。国内版默认接豆包/DeepSeek 等国内模型、发布到豆包/飞书/微信生态；国际版接 GPT、Gemini 等模型，发布到 Discord、Telegram 等渠道。两边账号、插件生态、模板市场不互通，选型时别搞混。

为什么字节要做扣子

对字节来说，扣子是豆包大模型的「出货管道」——平台上每个 Bot 的每次对话都在消耗火山引擎的模型调用。这解释了它早期近乎免费的策略，也解释了 2026 年全面转向订阅套餐 + 积分计费的商业化动作。平台的定价逻辑从来都和底层模型的成本结构绑在一起，评估成本时要意识到这一点（参见成本与优化）。

二、核心能力拆解

Bot 编排：单 Agent 与多 Agent 两种模式

扣子的基本单元是「智能体」（Bot）。创建一个 Bot 时要做的核心决策是选编排模式：

• 单 Agent（LLM 模式）：一个人设 prompt（「人设与回复逻辑」）+ 挂技能（插件、工作流、知识库），模型自主决定何时调用什么。这是最常用的模式。
• 单 Agent（工作流模式）：Bot 的回复严格由一条工作流决定，模型只在节点内部起作用。适合客服话术、合规问答这类不允许自由发挥的场景。
• 多 Agent 模式：一个「主持人」Agent 负责意图识别和任务分发，把请求路由给多个专职子 Agent 协作完成，子 Agent 各自有独立的人设、技能和记忆。本质上是把多 Agent 架构里的 supervisor 模式做成了产品功能，2026 年的扣子 3.0 进一步把「一人 + 多 Agent / 多人 + 多 Agent」的项目协作做成了主线能力。

人设 prompt 区域支持变量、技能描述注入，平台会自动把可用插件/工作流的描述拼装进 system prompt——这是典型的 Prompt Engineering 产品化：用户看到的是「人设与回复逻辑」文本框，底层是一套 prompt 模板拼装流水线。

插件生态

插件是扣子的工具层，对应 工具与 MCP 里的 function calling。三种来源：

1. 官方插件：字节维护的数百个工具（搜索、地图、图像生成、飞书多维表格、头条新闻等），开箱即用；
2. 自定义插件：给一个 OpenAPI 描述（或直接填 URL + 鉴权），平台把任意 HTTP API 包成工具；
3. 工作流即插件：任何工作流都可以作为工具被 Bot 调用，也可以发布为 MCP 服务供扣子空间或外部 Agent 使用。

插件市场的生态逻辑类似 GPTs 的 Actions，但执行体验好得多——因为字节自己同时控制模型（豆包的 function calling 能力）和平台（参数抽取、错误重试），全链路可以自己优化。

工作流：扣子的真正护城河

如果只用「人设 + 插件」，扣子只是个好看的 ChatGPT 套壳。工作流（workflow）才是它的核心资产：一个可视化 DAG 编排器，节点类型包括 LLM、代码（JavaScript/Python）、插件、知识库检索、条件分支、循环、消息、数据库、意图识别等，支持流式输出和批量运行。

工程视角看，扣子工作流 ≈ 低代码版的 Agent Loop 外骨骼：把「什么时候调模型、什么时候调工具、数据怎么流转」从模型的自主决策里拿出来，变成确定性编排。这也是为什么复杂业务几乎都收敛到「工作流模式」——可控性比自主性值钱。

用户输入
   │
   ▼
┌──────────────┐   意图识别节点
│  意图识别     │────────┐
└──────────────┘        │
   │                    ▼
   ▼              ┌───────────┐
┌──────────┐      │ 闲聊 LLM  │
│ 条件分支  │      └───────────┘
└──────────┘
   │ 业务意图
   ▼
┌──────────────┐    ┌──────────────┐    ┌─────────────┐
│ 知识库检索节点 │ →  │ LLM 节点      │ →  │ 代码节点     │ → 输出
│ (RAG)        │    │ (答案生成)    │    │ (格式化/校验)│
└──────────────┘    └──────────────┘    └─────────────┘
        ▲
        │ 失败兜底
┌──────────────┐
│ 转人工/固定话术│
└──────────────┘

2025 年 4 月起，工作流可以一键发布为 MCP 扩展，被扣子空间或其他支持 MCP 的客户端直接调用——这让「扣子工作流」从平台内部资产变成了对外服务能力。

知识库与记忆

知识库是平台内置的 RAG：支持文本（PDF/Word/网页/飞书文档/Notion 等）和表格两种类型，自动分段（也支持自定义分段规则）、向量化、混合检索，可以选择召回策略和 top-k。对非技术用户这是杀手级功能；对工程师要清楚它的边界——分段策略和检索参数可调但不可编程，复杂的多路召回、rerank 微调做不到，有这类需求就该自建 RAG 管线。

记忆方面提供变量（用户画像 KV）、长期记忆（对话中抽取的事实）和数据库（结构化表格，可让 Bot 读写），对应记忆系统里的短期/长期/结构化三层，但都是平台托管的黑盒实现。

发布渠道

一键发布是扣子的另一个核心卖点。国内版支持发布到：豆包 App、飞书（机器人/多维表格）、微信公众号、微信客服、抖音企业号、掘金，以及 Web SDK / API（Chat SDK + OpenAPI）；国际版对应 Discord、Telegram、Messenger、LINE 等。渠道适配层（消息格式、鉴权、会话管理）全部由平台托管，这正是低代码平台对自建方案最大的效率优势所在。

商店、模板与扣子空间

平台之上还有一层「生态位」设计，经常被技术视角忽略：

• Bot 商店与模板：用户可以把做好的 Bot、工作流、插件发布到商店供他人复制（fork 式复用），官方用模板 + 案例降低冷启动门槛。2026 年技能商店升级至数百个官方行业技能（法律、金融、电商、教育等），并支持把个人 SOP 封装成自定义技能。
• 扣子空间（Coze Space）：2025 年 4 月内测的通用 Agent 产品，定位对标 Manus——任务自动化、专家 Agent 生态、MCP 扩展集成（首批集成飞书多维表格、高德地图、语音合成等 60+ MCP 扩展）。它和开发平台的关系是「消费端/生产端」：开发者用扣子开发平台做工作流和插件，发布为 MCP 服务后成为扣子空间的能力供给。这是字节对标「Agent 操作系统」的入口卡位。
• 扣子 3.0（2026 年 6 月）：主线是协作化——多人 + 多 Agent 的项目空间、直接接入 Claude Code / Codex CLI / OpenClaw 等本地第三方 Agent、云端 Agent 与云设备（云手机/云电脑）。平台叙事从「搭 Bot 的工具」彻底转向「Agent 协作工作台」。

对学习者而言，这条演进线本身就是一堂产品课：低代码 Bot 平台 → 工作流引擎 → MCP 能力供给方 → 多 Agent 协作平台，四年走完，每一步都踩在行业范式切换的节点上（对照演进简史看会很清晰）。

三、技术架构推断

商业版扣子的完整架构没有公开，但开源版 coze-studio 的后端与商业版同源（官方表述为「核心引擎完全开放」），结合官方文档可以给出相当可靠的推断：

┌─────────────────────────────────────────────────────────┐
│  前端：React + TypeScript                                  │
│  ├─ FlowGram 工作流画布引擎（字节开源）                     │
│  └─ Bot 编排 / 知识库管理 / 调试台                          │
├─────────────────────────────────────────────────────────┤
│  后端：Golang 微服务（Hertz HTTP 框架），DDD 分层           │
│  ├─ Agent 编排服务：prompt 拼装 + 技能注入                  │
│  ├─ Workflow 引擎：DAG 编译与执行（Eino 运行时）            │
│  ├─ Plugin Runtime：HTTP 调用沙箱 + 鉴权管理               │
│  ├─ Knowledge 服务：文档解析 / 分段 / 向量化 / 检索          │
│  ├─ Code Runner：JS/Python 代码节点沙箱                    │
│  └─ 渠道适配层：豆包 / 飞书 / 微信 / API ...                │
├─────────────────────────────────────────────────────────┤
│  模型层：豆包系列（默认）/ DeepSeek / Kimi / 自定义模型 API   │
│  （国际版：GPT / Gemini 等）                                │
└─────────────────────────────────────────────────────────┘

几个值得学习的工程决策：

• 编排逻辑下沉到 Go 运行时。开源版官方致谢里明确写了：Agent 与 workflow 的运行时引擎、模型抽象、知识库索引检索来自 Eino 框架。也就是说扣子的 Agent Loop 不是 Python 脚本，而是编译型语言写的 DAG 执行器——这对高并发 SaaS 是合理选择，也解释了为什么它的工作流执行延迟体感不错。
• prompt 编排流水线。用户填的「人设与回复逻辑」只是原料，真正发给模型的是平台拼装的 system prompt：人设 + 技能描述（插件/工作流的 name + description + 参数 schema）+ 记忆注入 + 知识库召回片段 + 渠道特定约束。这和手写 Agent 时的 Context Engineering 是同一件事，只是被产品化了。
• 插件 runtime 的抽象。官方插件和自定义插件走同一套 OpenAPI 描述 + 鉴权 + 调用沙箱，把「工具」统一成可注册的 HTTP 服务。这套抽象后来被 MCP 生态部分收编（工作流可发布为 MCP 服务）。
• 前端画布独立成引擎。FlowGram 是字节单独开源的工作流画布引擎，说明他们把「可视化编排」当成通用基础设施而非产品细节——这个判断后来被证明是对的，同类平台（Dify、n8n、Flowise）的画布体验都在向它看齐。

读开源版是理解商业版最快的路

coze-studio 的后端代码（Go）就是商业版核心引擎的镜像。想知道「知识库检索默认 top-k 是多少」「prompt 到底怎么拼」「workflow 节点超时的兜底逻辑」，直接读源码比翻文档快。这对面试「分析一个成熟 Agent 平台」类题目也是现成素材（参见求职知识地图）。

四、开源动向：coze-studio 与 coze-loop

2025 年 7 月 26 日，字节将扣子的两个核心项目开源到 GitHub（coze-dev 组织下），采用 Apache 2.0 协议——可自由商用、可修改、无需开源衍生代码，没有附加条款。这在国产大厂的 Agent 平台里是最宽松的授权姿态（对比 Dify 的自定义附加条款协议，商用限制更少）。

• Coze Studio（github.com/coze-dev/coze-studio）：开发平台的开源版，包含 Agent 编排、工作流、插件、知识库、数据库、OpenAPI/Chat SDK。后端 Go + 微服务 + DDD，前端 React + TS。部署门槛刻意压得很低：2 核 4G + Docker Compose 即可起服务。
• Coze Loop（扣子罗盘开源版）：Agent 的评测与运维平台——prompt 版本管理与评估、自动化测试、trace 观测、生命周期调优。对应可观测性和评估体系两章讲的工程问题，是开源版里容易被忽视但企业落地最有价值的部分。
• 加上更早开源的 Eino 编排框架（2025 年上半年），扣子的四大核心产品开源了三个，剩下未开源的主要是扣子空间（通用 Agent 产品）。

社区热度：开源两天破 6k star，三天 9.5k，2025 年 8 月上旬媒体报道已达 19k+，此后持续增长（精确现值引用前请到 GitHub 核实）。

开源版与商业版的差距要清醒认识：开源版是「引擎」，商业版是「生态」。插件市场里的大部分官方插件、渠道发布能力（豆包/飞书/微信）、商业级模型配额、客服与合规能力都不在开源版里；官方文档也明确说部分功能（如音色定制）仅限商业版。官方 README 还专门警告：开源版若部署到公网，需自行评估账号注册、代码节点沙箱、SSRF、API 越权等安全风险。结论：私有化试点、二开学习、内网工具——可以用开源版；要对外服务 C 端用户，大概率还是得回商业版或者自己补齐周边。

打算私有化部署或二开的团队，几个实践要点：

1. 模型必须自己接。开源版不内置任何可用模型，部署后第一件事是在管理后台配置模型服务（OpenAI 兼容协议或火山引擎），否则连调试都进不去；知识库还要单独配 embedding 模型。
2. 官方插件不白给。插件商店里的官方插件涉及第三方服务的鉴权 key，开源版需要自行配置；没有 key 的插件装上也跑不通。
3. 把它当框架读，别当产品用。DDD 分层 + 微服务 + Eino 运行时的代码组织，是学习「生产级 Agent 平台怎么分层」的难得样本；但作为开箱即用的产品，它的打磨度和生态完整度都不如 Dify 社区版，选型时别被 star 数带偏。
4. 上生产前过一遍安全清单：官方自己点名的风险面（开放注册、代码节点沙箱逃逸、SSRF、API 越权）一个都不能漏，相关防护思路见安全。

五、商业化与定价

扣子的商业化在 2024-2026 年走完了「免费获客 → 按量计费 → 订阅套餐」三步：

1. 2024 年：基础版免费 + 专业版按量计费（智能体调用 0.002 元/次，模型 token 另计），专业版用户每日赠送 500 资源点。
2. 2025 年 2 月：资源包体系合并为「扣子资源点」，抵扣规则统一。
3. 2026 年：资源点改名「积分」，全面转向订阅制；旧「专业版」于 2026 年 5 月 30 日下线。团队版 2026 年 6 月 22 日上线，企业版随扣子 3.0 于 2026 年 7 月调价。

截至 2026 年 8 月的订阅档位（来自官方文档，引用价格前建议再核对一次官网）：

版本	档位	价格（月）	月积分
个人版	免费版	0	—
个人版	进阶版	39.9 元	3 万
个人版	高阶版	99 元	9.9 万
个人版	旗舰版	199 元	19.9 万
个人版	尊享版	999 元	99.9 万
团队版	高阶/旗舰/尊享	198 / 398 / 1998 元起	19.8 万 / 39.8 万 / 199.8 万起
企业版	标准/旗舰	980 / 8980 元起	34.5 万 / 207 万起

关键规则：个人版与团队版积分耗尽即不可用；企业版积分耗尽后转为扣现金余额（包年包月 + 按量混合计费）。高阶版以上才解锁云端 Agent、项目协作、自定义模型接入；SSO、VPC 私网连接、自定义内容安全策略等企业级能力只在企业旗舰版。

给工程团队的成本提醒

积分制把「模型调用、视频生成、云设备、插件调用」全部折算成一个池子，好处是账单简单，坏处是成本归因模糊。如果你的应用有稳定的模型调用量，务必拿自己业务的 token 消耗估算一遍「积分单价 vs 直接调火山引擎 API 的单价」——高频调用场景下平台溢价可能很可观，这时候「扣子做前端 + 自建 Agent 后端」的混合架构往往更划算（参见成本与优化）。

六、与 Dify / n8n 的定位差异

这三个工具经常被放在一起比较，但它们的目标用户和架构假设其实差异很大：

维度	扣子（Coze）	Dify	n8n
本质	托管 SaaS 优先的 Agent 平台	开源优先的 LLM 应用平台	通用工作流自动化工具（后加入 AI 节点）
目标用户	非技术人员 + 业务团队	开发者 + 技术型团队	有自动化需求的运营/工程
核心抽象	Bot + 技能 + 渠道发布	App（聊天/工作流/Agent）	节点 + 触发器 + 连接
模型策略	豆包优先，生态绑定深	模型中立，接什么都行	模型只是众多节点之一
渠道生态	豆包/飞书/微信/抖音一键发布	弱（主要靠 API/Web）	400+ SaaS 连接器
私有化	coze-studio（功能有裁剪）	完整开源，可商用（有附加条款）	完整开源（fair-code 协议）
开源协议	Apache 2.0	Dify 自定义许可证	Sustainable Use License
非 AI 自动化	弱	弱	极强（本来就是干这个的）

经验性的选型结论：

• 要快速验证一个 AI 应用的 PMF、目标用户在国内渠道（微信/飞书/豆包）、团队里没有全职工程师——选扣子，没有对手。
• 要私有化、模型中立、长期可控，且团队有工程能力——选 Dify，它的开源完整度和社区生态仍然是同类里最好的。扣子开源版发布后在追，但「引擎开源、生态闭源」的格局短期不会变。
• 需求里 AI 只是流程的一环（比如「收到邮件 → 提取附件 → LLM 总结 → 写进 CRM → 发 Slack」），选 n8n，硬用扣子/Dify 是拿错的锤子敲钉子。

详细的框架与平台对比见选型总览。

七、适合谁：非技术用户的天堂，工程团队的边界

扣子的真实价值曲线大致是这样：

• 0 → 1 验证期：无敌。运营同学一下午搭出带知识库和插件的客服 Bot 发布到飞书，这个速度自建方案做不到。
• 1 → 10 放量期：开始出现裂缝。调试困难（prompt 黑盒拼装，评估手段有限）、版本管理弱（工作流没有真正的 Git 式协作）、成本随调用量线性上涨。
• 10 → 100 规模化期：大多数工程团队会选择把核心链路迁到自建（LangGraph/Eino/自研），扣子退回到「渠道发布层 + 运营工具」的位置，或者被 coze-studio 私有化 + 二开替代。

所以对工程师的职业建议很直接：会用扣子是加分项，只会扣子是减分项。招聘方真正要的是理解扣子产品化掉的那些东西——prompt 编排、RAG 管线、工具调用、多 Agent 路由——在代码层面怎么实现（参见动手搭建一个 Agent）。扣子是最好的「Agent 概念教具」：用它快速建立直觉，然后沉下去读 coze-studio 源码、自己写一遍，这才是完整的学习路径。

反过来说，有两类场景扣子比自建方案更专业，不建议重复造轮子：一是多渠道分发（微信生态的接入合规成本很高，平台帮你扛了）；二是内容安全——面向国内 C 端用户的对话产品，合规过滤是刚需，企业版的内容安全策略比自己接审核 API 省心得多。

一条务实的上手路径

如果你是工程师，建议按这个顺序接触扣子，每一步都有明确的学习产出：

1. 花两小时在 coze.cn 搭一个 Bot：人设 + 一个官方插件 + 一个知识库，发布到飞书。目标是建立「平台把什么产品化了」的直觉。
2. 用工作流模式改造它：把自由对话改成「意图识别 → 检索 → 生成 → 校验」的确定性流程，体会自主性与可控性的权衡——这是 Agent 设计原则里最核心的一课。
3. 本地部署 coze-studio 开源版（2 核 4G + Docker Compose 即可），对照官方架构文档读 Go 后端源码，重点看 workflow 引擎和 prompt 拼装两处。
4. 给它接 Coze Loop，跑一组评测集，把 trace 看一遍——把可观测性从概念变成手感。
5. 做一次成本推演：拿你 Bot 的真实调用量，分别按「扣子积分」和「自建 + 火山引擎 API 直调」算一笔账，理解平台的溢价在哪里、值不值。

走完这五步，你对「一个生产级 Agent 平台需要哪些组件」会有完整的肌肉记忆，这比看十篇架构文章管用。

参考资料

• coze-dev/coze-studio · GitHub —— 开源版官方仓库，含架构说明、部署指南与开源/商业版差异
• 什么是 Coze Loop · GitHub Wiki —— 扣子罗盘开源版的官方定位与功能说明
• 扣子订阅套餐 · 官方文档 —— 2026 年个人版/团队版/企业版档位、价格与权益明细
• 扣子订阅套餐升级公告 · 官方文档 —— 专业版 2026 年 5 月下线、资源点改积分的时间线
• 扣子官宣开源，负责人独家披露 · InfoQ —— 2025 年 7 月开源决策背景与 star 增长数据
• 大厂 AI Agent 角逐，字节携扣子空间进击 · 财联社 —— 扣子空间 2025 年 4 月内测与 MCP 扩展生态的报道
• 2026 学扣子 Coze 看这篇就够了 · 博客园 —— 2026 年视角的平台功能盘点，含技能商店与视频 Agent 现状
• AI 日报：扣子 Coze 3.0 上线 —— 2026 年 6 月 3.0 多 Agent 协作与第三方 Agent 接入的发布信息（媒体报道，引用前建议核对官方公告）