第 19 周 · Day 6：低代码与代码的边界——什么时候用平台，什么时候自己写

对应手册任务：学习「低代码 vs 代码边界：Dify/Coze 能力边界、何时必须自建」，动手用 Coze 搭一个与昨天同类的客服 Bot，输出「平台选型决策树」（数据私有性 / 定制复杂度 / 维护成本三维评估）。本篇只解决一个问题：一个 Agent 需求摆到面前，你能不能在一分钟内说清它该放云端平台、自托管开源项目，还是自己拿代码写，并且给出站得住的理由。

今日目标

1. 半小时内在 Coze 上搭出与昨天 Dify 同款的客服 Bot：同款提示词、同款文档、同款问题，把「平台差异」变成唯一变量
2. 记住平台「到顶」的三个信号：多 Agent 状态机、人机协同、评估体系，看到任何一个就知道低代码不够用了
3. 画出一棵可打印的选型决策树：三个问题节点、是/否分支、三片叶子（云端 Coze / 自托管 Dify / 自建 LangGraph），并说清现实项目的正解是三者混合

概念讲解：为什么「用平台还是写代码」是个工程问题

一个 Agent 需求来了，你面前有三条路：云端平台（Coze）、自托管开源（Dify）、自己写（LangGraph）。多数人怎么选？哪个火用哪个，哪个顺手用哪个，哪个昨天用过今天接着用。这不叫选型，叫惯性。

本周从攻防走到生态，收在今天的这个问题上。昨天你在 Dify 上搭了客服 Bot（见 Day 5），今天换 Coze 再搭一遍同款。同款的意义是控制变量：提示词不变、文档不变、问题不变，变量只剩平台本身。搭完你会发现一件更有意思的事：这两个平台根本不在一个赛道上，谈不上谁取代谁。

	Dify	Coze（扣子）
出身	开源项目	字节跳动的 SaaS 产品
主流用法	自己部署，数据在自己服务器	注册即用，不用碰部署
数据去向	不出你的域	知识库与对话在平台云端
最后一公里	拿到 API 和嵌入代码，集成自己写	点发布，直达飞书、微信客服等渠道
生态位	私有化的应用工厂	云端的 Bot 工厂加分发渠道

两家都在往对方地盘试探：Dify 有云端版，Coze 后来也开源了 Studio，但重心和主流用法仍如上表。

所以「Dify 还是 Coze」是个伪问题。真问题是三个：你的数据能不能出域？你的逻辑有多复杂？谁来长期维护？三个问题答完，结论自己会浮出来。把它们组织成一棵决策树，就是今天的产出。

核心知识

1. Coze 半小时上手：同款客服 Bot 的路径

Coze 国内版叫「扣子」，字节的 Bot 开发平台，SaaS 形态，打开网页就能用。四个核心概念，昨天你在 Dify 里全见过近亲：人设与回复逻辑（Bot 是谁、怎么说话，本质是提示词）、插件（给模型接外部能力，商店里现成一堆）、工作流（把多步逻辑串成流程图）、知识库（上传文档做检索问答）。概念同构，迁移成本接近零。

真正的差别在最后一公里。Dify 搭完，拿到的是 API 和一段嵌入代码，怎么接进产品是你的事；Coze 搭完点发布，Bot 直接出现在用户已经在的地方，飞书、微信客服、豆包。一个面向开发者集成，一个面向渠道分发。

30 分钟的路径，五步（具体入口和按钮以官方界面为准，路径本身不会变）：

1. 注册进入平台，新建一个 Bot
2. 把昨天调好的客服提示词原样贴进人设
3. 把昨天那份客服文档传进知识库，挂到 Bot 上
4. 在预览窗口把昨天问过的问题再问一遍，缺什么补什么
5. 发布：有飞书或微信客服场景就发一个渠道，没有就先跳过

第一次搭会觉得快得不太真实。这种快本身就是知识点：昨天你在 Dify 里配置的东西，今天在 Coze 里还是配置；而你前 18 周手写过的那些，提示词管理、RAG 检索、工具编排，在平台上全变成了配置项。平台的价值是把代码变成配置，平台的边界也藏在这句话里：配置覆盖得了的，它管；覆盖不了的，你得回代码。

2. 能力边界：平台「到顶」的三个信号

第一个信号：多 Agent 状态机。平台工作流擅长一条流程跑到底，起点到终点走一遍。复杂的 Agent 业务往往是状态机：循环、回退、按中间状态决定下一跳，A 节点跑完可能又回到 A。你前面几周用 LangGraph 写的那种带环的图，拖进低代码画布就开始别扭，节点越拖越多，画布成了一碗面。

第二个信号：人机协同（HITL）。审批、确认、人工修正再继续——Agent 跑到一半停下来，把控制权交给真人，人点完按钮接着跑。预览窗口能演示单轮对话，但「暂停等一个真人」这种语义，超出了拖拽编排的表达范围。

第三个信号：评估体系。改了一版提示词，效果是好了还是差了？平台的调试面板只回答「这一条回答好不好」，不回答「300 条测试集整体掉没掉点」。没有评估的迭代是玄学，玄学项目活不过第二次线上事故。你在评估那几周搭的测试集和打分流水线，平台给不了。

三个信号出现一个，就该认真考虑代码；出现两个以上，别犹豫。

另有一个维度不是「能力到顶」，是「资格不过线」：数据私有性。客户数据能不能出域，是合规问题不是技术问题，SaaS 做得再好也接不了「数据不许出门」这单生意。它不参与比较，直接砍选项。

3. 三维评估与那棵决策树

三个维度按否决力从强到弱排。

第一维，数据私有性，一票否决。问一句：客户数据能存到第三方云平台吗？不能，云端 SaaS 全部出局，只剩自托管 Dify 和纯自建。这一问最锋利，先问它，选项直接砍半。

第二维，定制复杂度。标准问答、固定流程，平台绰绰有余；撞上第 2 节那三个信号，平台到顶。判断标准不是需求文档有多少页，是逻辑里有没有状态机、有没有人工介入、要不要回归评估。

第三维，维护成本。没有工程师团队，就别碰自托管和自建。不是搭不起来，是没人养：升级、监控、模型网关、知识库重建，全是持续的活。Bot 是资产，资产要保养，保养要人。

三问连起来，就是这棵树：

Q1 客户数据能出域吗？（数据私有性）
├─ 不能 → Q2 逻辑是标准问答/固定流程吗？（定制复杂度）
│          ├─ 是 → 【自托管 Dify】数据不出门，标准能力开箱即用
│          └─ 否 → 【自建 LangGraph】复杂到平台装不下，只能自己写
└─ 能 → Q3 逻辑复杂吗？（状态机 / HITL / 评估）
           ├─ 是 → 【自建 LangGraph】平台到顶，代码是唯一出路
           └─ 否 → Q4 有工程师团队长期维护吗？（维护成本）
                    ├─ 没有 → 【云端 Coze】零运维，发布直达用户渠道
                    └─ 有 → 【自托管 Dify】嵌自家产品选它；
                             要直达飞书/微信客服，回头选 Coze

三片叶子各管一段：云 Coze 管快和分发，自托管 Dify 管私有和可控，自建 LangGraph 管复杂和深水区。

4. 混合架构：现实里的正解

真在公司里走一遍这棵树，你会发现结论不是一个，是一组：官网 FAQ 客服落在 Coze 叶子上，内部知识库问答落在自托管 Dify 叶子上，核心业务 Agent 落在自建叶子上。成熟企业从来都是混着用，前台要快的上平台，核心要深的自己写。

混着用最怕混成两套孤岛：平台一份知识库，自建一份知识库，同一个问题两个口径。正解是用 MCP（或普通 API）把两个世界连起来：自建的核心 Agent 通过 MCP 暴露成标准工具，平台上的前台 Bot 像调普通插件一样调它。能力留在自己手里，分发交给平台，数据单向流动，而不是复制两份。

这也是你这 22 周的定位。回头看 第 1 周还在写泛型，走到今天，你的技能栈恰好落在「能自建的那一档」。平台每年都在吃掉更简单的活，听着像坏消息，其实是好消息：简单的活越容易被平台拿走，看得懂边界、下得了深水区的人就越稀缺。平台淘汰的是只会拖拽的搭建者，淘汰不了知道什么时候不该拖拽的人。

动手任务：30 分钟同款 Bot，加一棵决策树

手册任务：用 Coze 搭一个与昨天同类的客服 Bot，输出平台选型决策树。拆成 6 步，全程约 30 分钟。

第 1 步：进平台建 Bot。 注册登录国内版，新建一个 Bot，名字带上场景，比如「week19 客服」。先把四个核心概念的入口认一遍，不急着配。（5 分钟）

第 2 步：贴提示词。 把昨天在 Dify 里调好的客服提示词原样贴进人设。这一步的体会是：提示词是跨平台资产，平台会换，资产跟你走。（5 分钟）

第 3 步：挂知识库。 昨天那份客服文档原样上传，挂到 Bot 上。同一段文档在不同平台的分段和检索策略未必相同，这是第 4 步对照的伏笔。（5 到 10 分钟）

第 4 步：预览对照。 把昨天问过的问题原样再问一遍，把结果分三类：两边都好、Dify 好这个差、两边都差。第三类最有价值，说明问题出在你的提示词或文档上，跟平台无关，修一次两边同时受益。（10 分钟）

第 5 步：发布（可选）。 有真实渠道就发一个，体验最后一公里的快；没有就跳过，不影响产出。（5 分钟）

第 6 步：画你自己的树。 把第 3 节那棵决策树抄下来，或按你手边的场景改一版。然后拿一个真实需求（公司官网客服？个人知识库助手？）从 Q1 走到叶子，写下结论和路径。这棵树就是当日产出，建议打印出来贴工位，下次有人问「我们该用什么平台」，指着它讲。

对照才有体感

同款提示词、同款文档、同款问题，在两个平台各跑一遍，你对「能力边界」的体感会超过读十篇对比评测。三十分钟买一个工程直觉，划算。

常见踩坑

坑 1：用热度选型。 今天谁融资多就用谁，明年它改收费策略甚至关停，迁移成本全压在你身上。选型的输入应该是你自己的三个维度，不是产品的 star 数和新闻稿。

坑 2：把「平台不支持」当成「需求不合理」。 业务方要人工审批环节，平台工作流做不了，于是一步步砍需求，最后上线的是「平台做得出来的东西」，不是「业务需要的东西」。需求被工具反向塑造，这是低代码最隐蔽的坑，而且砍的过程往往无声无息。

坑 3：低估自托管的维护成本。 自托管 Dify 不是部署完就一劳永逸：版本要跟着升，模型网关要配，向量库要喂，监控告警要搭。没团队还坚持自托管，半年后它会变成没人敢动的祖传服务。第三维问的不是你能不能搭起来，是有没有人养。

坑 4：数据出域只算了模型，没算平台。 有人反复确认「模型是不是私有部署」，却忘了 SaaS 平台的知识库、对话日志、用户信息都存在平台侧。合规要算整条数据链路，推理那一环只是其中一段。

坑 5：混合架构混成两套孤岛。 平台上了、自建也做了，两边各存一份知识库、各答一套口径，用户在渠道里和产品里得到两个版本的答案。正解是 MCP 或 API 打通：自建能力暴露成平台可调的工具，而不是把同样的东西做两遍。

自测问题

先自己答，再展开对照。答不上来的，回对应小节看一遍。

1. 三个评估维度为什么按「数据私有性、定制复杂度、维护成本」这个顺序问？

参考答案

按否决力排序。数据私有性是合规问题，一票否决，先问它能砍掉一半选项；定制复杂度决定平台到没到顶；维护成本否决的是自托管和自建，不影响云端平台。越靠前的维度，答错的代价越大。

2. 为什么说 Dify 和 Coze 不构成「二选一」？

参考答案

生态位不同。Dify 重心是开源私有化：部署在自己服务器，数据不出域，产出是 API，面向开发者集成。Coze 重心是云端 SaaS：零部署，发布直达飞书、微信客服等 C 端渠道，面向快速分发。真正的比较发生在「你的需求落在哪个生态位」，不是「哪个产品更强」。

3. 出现哪三个信号，说明必须自建？

参考答案

多 Agent 状态机（循环、回退、按状态分支）；人机协同 HITL（中途暂停等真人操作再继续）；成体系的评估回归（测试集整体打分，不是单条看效果）。出现一个就该考虑代码，出现两个以上别犹豫。

4. 混合架构里 MCP 扮演什么角色？

参考答案

连接两界的接口层。自建的核心 Agent 通过 MCP 暴露成标准工具，平台上的前台 Bot 像调普通插件一样调它。效果是：深度能力留在自己手里，渠道分发交给平台，数据单向流动，避免两套孤岛。

5. 自托管 Dify 解决了哪个维度，没解决哪个？

参考答案

解决了数据私有性，数据全程不出域。部分解决维护成本，比纯自建省事，但升级、监控、网关仍是持续投入。基本不解决定制复杂度：撞上状态机、HITL、评估这三个信号时，自托管和云端一样到顶，深水区还得回代码。

延伸阅读

• Coze 官网（扣子），今天半小时的主场，帮助中心里有插件、工作流、知识库的官方定义和发布渠道清单
• Dify GitHub 仓库，开源私有化这条路线的代表作，README 第一屏就能看出它和 SaaS 产品的定位差异
• Model Context Protocol，混合架构的连接层，重点看「怎么把一个自建服务暴露成标准工具」

今天的产出是那棵决策树，加上你用它走了一遍的真实场景结论。留好，往后每接一个新需求，先拿出来走一遍，走多了，选型会从一道问答题变成一个反射。