第五章基于低代码平台的智能体搭建 · 学习笔记（Coze / Dify / FastGPT / n8n）

学习材料 ：《Hello-Agents》第五章基于低代码平台的智能体搭建（docs/chapter5/第五章基于低代码平台的智能体搭建.md）

配套代码 ：本章无本地代码 （四个平台均为图形化配置），故本笔记的"实验"改为对平台提示词的云端实测

实验环境 ：腾讯云 Lighthouse（2C2G / 无 GPU）· Python 3.14

模型：主用 Moonshot kimi-k2.6 ；另按要求以云端自部署模型 复测（llama.cpp + Qwen3-1.7B-Q4_K_M ，http://localhost:8080/v1）

实测规模 ：把 Coze「每日AI简报」的 System/User 提示词搬到云端跑通 2 组对照（原始 / 追加"≥500字"硬约束）

关键词：低代码 · Coze · Dify · FastGPT · n8n · 插件生态 · MCP · RAG · System Prompt / User Prompt 分离 · 结构化提示词 · 混合开发
导读

第四章我们亲手造了一台引擎 （ReAct / Plan-and-Solve / Reflection）；这一章问一句很实际的话：如果我要的是"一辆能上路的车"，为什么还要先造引擎？

低代码平台把这台引擎藏进图形化节点里，注意力从"实现细节"转到"业务逻辑 + 提示词"。这一章我把四个平台的提示词搬到云端真跑 ，因此笔记里既有平台对比，也有实测出来的两处硬缺陷：模型会编造"当天日期"，以及"≥500 字"这类长度硬约束会引发格式漂移。

想快速选型 → 看 §2.0 总表 与 §2.6 选型

想看实测证据 → 看 §5 实验记录（含两处缺陷的原始输出）

自己在复习 → 用 §8 的自测清单 自问自答
说明：本章四个平台（Coze / Dify / FastGPT / n8n）都需要注册账号并在浏览器里操作，无法在无头服务器上执行 。因此本篇的"实测"是把平台的提示词搬到云端用同一批数据实跑，检验它的格式遵循与约束冲突------这本身就是提示词质量的实测。

本系列其他文章

上一章：第四章智能体经典范式构建 · 学习笔记（ReAct / Plan-and-Solve / Reflection 云端实测）
本章问题篇：第五章可能出现的问题：两类必错设计与生产不可用
全系列目录：hello-agent入门学习

一、知识地图

复制代码

第五章 基于低代码平台的智能体搭建
├── 5.1 平台化构建的兴起 ──────────────── 从"手写引擎"到"搭积木"
│   ├── 5.1.1 为何需要低代码平台 ──────── 降门槛 / 提效率 / 可视化 / 标准化
│   └── 5.1.2 平台选择概览 ────────────── Coze · Dify · FastGPT · n8n
├── 5.2 Coze ─────────────────────────── 零代码 + 插件生态
│   ├── 5.2.1 功能模块（工作流/对话流/插件/知识库/卡片/提示词/数据库）
│   ├── 5.2.2 案例：每日AI简报 ────────── RSS + GitHub + arXiv → 结构化简报
│   └── 5.2.3 优势与局限（不支持 MCP 是最致命的）
├── 5.3 Dify ─────────────────────────── 开源 + 企业级（BaaS + LLMOps）
│   ├── 5.3.1 介绍与生态（分层架构 · 模型中立 · 8000+ 插件）
│   └── 5.3.2 案例：超级智能体个人助手（问题分类器 + 多模块）
├── 5.4 FastGPT ──────────────────────── 开源 + 极致 RAG
│   └── 5.4.2 案例：智能投顾助手（知识库 + MCP）
├── 5.5 n8n ──────────────────────────── 工作流自动化 + AI 节点
│   └── 5.5.2~5.5.4 案例：智能邮件助手（私有知识库 + 主工作流）
└── 5.6 本章小结 ─────────────────────── 选型建议 + 混合开发

一句话主线 ：第四章我们亲手造了一台引擎 （ReAct/Plan-and-Solve/Reflection），第五章则问一句很实际的话------如果我要的是"一辆能上路的车"，为什么还要先造引擎？ 低代码平台把这台引擎"藏"进图形化的节点里，让注意力从"实现细节"转移到"业务逻辑 + 提示词"：

Coze = 最省事的"组装线"（插件多、发布广，但不支持 MCP）；

Dify = 最全面的"工厂"（开源、可私有化、插件最多）；

FastGPT = 最专的"知识库问答专机"（RAG 链路完整、支持 MCP）；

n8n = 最强的"管道工"（几百个节点，擅长把 AI 插进既有业务流程）。

它们不是竞品，而是四把不同形状的锤子。

读完这一章应该能做到一件事：拿到一个新需求，能先判断"该用平台还是该写代码"，再判断"该选哪个平台"------而不是默认打开 IDE 或默认打开 Coze。

二、核心概念

2.0 先立骨架：四平台总表（本章最该背下来的一张表）

平台	核心定位	最强的一手	致命/明显短板	最适合的人
Coze	字节出品，零代码智能体	插件生态 + 一键发布抖音/飞书/微信/豆包	不支持 MCP；高级插件要技术背景；导出是 zip 非 json	入门用户、产品/运营、个人创作者
Dify	开源 BaaS + LLMOps，企业级	分层可扩展、模型中立、Marketplace 8000+ 插件、可私有化	学习曲线陡；高并发有性能挑战	有技术背景的开发者、企业团队
FastGPT	开源，极致 RAG	数据导入→分块→向量化→检索全链路；原生支持 MCP	模板生态弱；免费额度有限	私有知识库问答、智能客服、中小企业
n8n	开源工作流自动化（AI 是其中一环）	"连接"能力：数百预置节点，打通 SaaS/DB/API	学习曲线陡；内置存储非持久（Simple Vector Store / Simple Memory）；版本控制不成熟	需要把 AI 深度嵌入业务流程的团队

🔑 章节里那句话的工程含义："低代码平台不是要取代代码，而是提供更高层次的抽象。" 它的边界恰好是**"标准化到什么程度"**------越是标准化、可复用的流程，越适合平台；越是长尾、特殊逻辑，越要落回代码。

2.1 为什么平台化会赢在一部分场景（四个价值）

降低技术门槛：把 API 调用、状态管理、并发控制封装成"节点"。
提升开发效率：原型阶段"数小时甚至数分钟"出结果。
可视化与可观测性 ：能看到数据在节点间怎么流 、哪一环最慢、哪个工具调用失败------这是终端 print 比不了的。
标准化与最佳实践沉淀 ：平台内置的 ReAct 模板、检索引擎、工具接入规范，本质上是在替团队沉淀约定。

💡 可迁移经验 ：第 3 条是低代码平台最容易被低估 的优势。第四章我们靠 print 调试 ReAct，如果换成平台，"哪一步 Observation 是空的"会直接画在图上------这会让我们更快发现"工具静默失败"那类问题。

2.2 Coze：把"出装"配齐就能上分

把 Coze 的资源库类比成游戏装备，是本章最传神的一段：

平台概念	类比	实际作用
工作流	关卡路线图	确定的执行路径
对话流	NPC 对话	多轮交互编排
插件	角色技能卡	外部能力（RSS / GitHub / arXiv...）
知识库	游戏百科全书	RAG 检索源
提示词	移动键	角色/任务/格式的指令
数据库	云存档	持久化状态

「每日AI简报」案例的关键动作是三步：加插件 → 配参数（RSS 链接、关键词） → 编排连接（插件 → 大模型）。

⚠️ 必须写进笔记的结论 ：Coze 案例里，"插件配置"本身就是提示词工程的一部分 。RSS 该订哪几个源、GitHub 搜什么关键词、arXiv 取几条------这些参数决定了喂给大模型的"事实原料"是什么。模型再强，也救不回一份烂原料。

2.3 Dify：企业级的关键是"模型中立 + 可私有化"

架构：数据层 / 开发层 / 编排层 / 基础层，分层解耦便于扩展。
模型中立：GPT / Deepseek / Llama / 任何兼容 OpenAI API 的模型都能接。
部署灵活：Docker Compose 一键本地部署，或官方 SaaS。
Marketplace：8000+ 插件，涵盖模型/工具/智能体策略/扩展/捆绑包。

「超级智能体个人助手」案例的价值在于它演示了"一个入口，多个子智能体" ：用问题分类器做智能路由，把请求分发给日常问答 / 文案优化 / 多模态生成 / 数据分析 / MCP 工具等模块。

🔑 点睛："问题分类器 + 子智能体"就是第四章那三种范式的平台化封装 ------分类器负责"规划（该找谁）"，子智能体负责"执行（怎么干）"。你在平台上拖出来的那张图，本质就是一张 Plan-and-Solve 的静态计划。

2.4 FastGPT：RAG 做深，比做广更难

它的差异化只有一句话："把知识库问答这一件事做到极致" ------从数据导入、自动分块、向量化到智能检索，全链路都给到位，并且原生支持 MCP（这恰好是 Coze 的短板）。

2.5 n8n：AI 只是管道里的一个"阀"

n8n 的定位最容易理解错：它不是一个 LLM 平台，而是一个工作流自动化工具，只是顺手把 AI 能力接进来了。 它的杀手锏是"连接"------把电商下单、邮件、库存、CRM 串成一条自动化链路，其中某一环嵌一个 LLM 节点。

⚠️ 必读的坑 ：n8n 内置的 Simple Vector Store / Simple Memory 基于内存，服务重启数据就丢 。案例里能用是"演示够用"，生产环境必须换成 Pinecone / Redis 之类的持久化存储。

2.6 平台里的提示词工程（本章最可迁移的部分）

四个平台都在做同一件事：把提示词拆成 System（长期准则）与 User（本次任务）两层。以 Coze 案例为例：

层	内容	回答的问题
System Prompt	角色（"资深科技媒体编辑"）+ 输出格式规范（标注/Emoji/链接/描述）	"你是谁、永远要守哪些规矩"
User Prompt	数据来源与字段映射（{``{articles}} / {``{arxiv}} ...）+ 模块划分	"这一次具体做什么、用什么数据"

Dify 与 FastGPT 的提示词则采用更标准的五段式 ：一、角色人设 / 二、背景 / 三、任务目标 / 四、限制提示 / 五、输出格式要求。

💡 可迁移经验 ："角色 + 任务 + 约束 + 输出格式"这四段，是跨平台通用的最小提示词骨架。 换平台不用换思维------这也是我能在服务器上用 kimi 复现 Coze 提示词的原因。

三、把第五章"接回"前四章

第五章的概念	在第几章"活"过来
Coze 的插件配置（RSS/关键词）	第四章（`ToolExecutor` 的工具描述------"喂什么工具"决定能力上限）
Dify 的问题分类器 + 子智能体	第四章（Plan-and-Solve 的 Planner：先决定"该走哪条路"）
FastGPT 的工作流编排	第四章（把 ReAct/Plan 的控制流"画"出来）
n8n 的节点连接	第四章（工具调用链的图形化）
知识库 / RAG	第三章（RAG 是幻觉的分层缓解手段之一）
提示词分层（System/User）	第一章（`AGENT_SYSTEM_PROMPT` 的四段式：角色/工具/格式/约束）
多智能体模式（Coze/Dify）	第六章（AutoGen / AgentScope 的正式多智能体协作）

四、"配置"精读（本章无代码，改读配置）

4.1 Coze「每日AI简报」的信息源配置

复制代码

RSS:   36氪 https://www.36kr.com/feed | 虎嗅 https://rss.huxiu.com/
       IT之家 http://www.ithome.com/rss/ | InfoQ https://feed.infoq.com/ai-ml-data-eng/
GitHub: q=AI, per_page=10, sort=updated
arXiv:  count=5, search_query=AI, sort_by=2

读法：这三组参数不是"设置项"，而是这份简报的"事实边界" ------简报里的每一条，都来自这三个源。源选错，后面全错。

4.2 Coze 的 System Prompt（逐条拆）

条款	作用	对应理论
角色：资深科技媒体编辑	定人设 → 定向输出风格	角色设定
开头标注"AI日报/日期/署名"	固定头部元信息	输出契约
每条目加 Emoji	可读性 / 区分条目	格式规范
排除无关与营销内容	信噪过滤（实测有效，见 §5.1）	约束
每条必须给原始链接	可追溯性（防幻觉的轻量手段）	约束
每条一句概况描述	强制"压缩"而非堆砌	输出质量

⚠️ 第 3 条"当天日期"是本案例最大的隐患 ：提示词要求输出"当天日期"，但并没有把日期作为变量传进去。大模型不知道今天是几号------实测它直接编了一个（见 §5.3）。

4.3 n8n 主工作流的提示词结构

# Prompt (User Message) + # 上下文信息 + # System Message（角色和目标 / 上下文信息 / 可用工具 / 执行步骤 / 规则和限制）------结构上与第四章 ReAct 的提示词几乎一一对应 （可用工具 ↔ 工具清单；执行步骤 ↔ 格式规约）。换了张皮，骨架没变。

五、实验记录（把平台提示词搬到云端实测）

口径声明 ：四个平台都是图形化 SaaS/自建服务，在无头服务器上无法注册账号、拖动节点 ------所以本节不冒充"搭好了平台" ，只做一件服务器真能做的事：把平台的提示词原样搬到 kimi 上跑，看它"守不守规矩"。这本身就是提示词质量的实测。

5.0 结论先行

检验项	实测	结论
营销内容过滤（"空调促销五折起"）	✅ 被剔除	信噪过滤有效
每条目 Emoji + 链接 + 描述	✅ 全部遵守	格式条款可执行
"当天日期"	❌ 输出 `2024年12月19日`（真实今天是 2026-09-21）	日期幻觉：没给数据，模型就编
追加"正文不少于500字"	⚠️ 字数达标（408 → 1362 字节），但格式漂移	硬长度约束有副作用

5.1 测试 1：原始提示词（LEN=408）

输出结构完全符合 System Prompt 要求：

复制代码

AI日报  by@learner  2024年12月19日        ← 日期是编的（见 5.3）
### 🤖 AI技术新闻
- 🚀 [我司发布新一代国产大模型推理芯片](https://example.com/36kr/chip) ------ 国产新一代...算力支撑。
### 📚 AI学术论文
- 📑 [Agentic Retrieval with Tool Feedback](...) ------ 提出基于工具反馈的智能体检索框架...
### 💻 AI开源项目
- 🔧 [hello-agents](https://github.com/datawhalechina/Hello-Agents) ------ Datawhale开源的Agent入门实践项目...

要点：输入里塞了一条广告（"夏季空调促销五折起"），模型把它过滤掉了 ------说明"排除营销内容"这条约束真的起作用，不是摆设。

5.2 测试 2：追加"正文不少于 500 字"硬约束（LEN=1362）

字数从 408 涨到 1362 （是原来的 3.3 倍），但代价是格式整体漂移：

项	测试 1（无长度约束）	测试 2（≥500字）
模块标题	`### 🤖 AI技术新闻`	`【AI技术新闻】`（不再是 Markdown 标题）
分隔	有 `---`	丢失
条目形态	一行"标题 + 链接 + 一句描述"	先来一段行业铺垫长文，再给条目
链接位置	行内	移到了段落末尾（"原始链接：..."）

⚠️ 必须写进笔记的结论 ："输出长度硬约束"和"输出格式规范"会互相打架。 模型为了凑字数，会把"结构化短句"改写成"散文式长段"，顺手就把标题层级、分隔线、链接位置都改了。如果你既要长又要格式稳，就必须把格式要求"再强调一遍"或改用结构化输出（JSON/字段）。

5.3 日期幻觉：一条提示词，一个必错项

System Prompt 写着"开头标注当天日期 "，但输入里没有任何日期变量。实测输出：

复制代码

AI日报  by@learner  2024年12月19日      ← 服务器真实日期是 2026-09-21

这不是模型"笨" ------按第三章的结论，模型只问"最可能是什么"，不问"对不对" 。"当前日期"对它来说就是训练数据里的一个高频值 。凡是"运行时的真实状态"，都必须由代码注入，不能指望模型知道。

🔑 这条是整章最值钱的实操教训 ：任何"实时/环境相关"的信息（日期、时间、价格、库存），都必须是变量注入，绝不能写进提示词让模型自己"想"。

5.4 复测：改用云端自部署模型（Qwen3-1.7B）

把同一套 Coze 提示词改由服务器自部署的 Qwen3-1.7B 生成：

项	kimi-k2.6	Qwen3-1.7B（自部署）
测试1 长度	408 字节	553 字节
测试1 日期	编成 `2024年12月19日`	编成 `2025年4月15日`
测试2 长度（追加"≥500字"）	1362 字节	1033 字节
测试2 日期	------	编成 `2025年6月15日`（与同一次运行里的测试1 都不一样）
广告过滤	✅ 剔除	✅ 剔除
格式漂移	标题层级 / 分隔线 / 链接位置全变	同样漂移，并额外长出 `标题： / 概况描述： / 内容：` 三段式字段，结尾还重复了一遍页眉

⭐ 两个跨模型都成立、因此更值得记的结论：

"当天日期"幻觉与模型规模无关 ------两个模型都编，而且同一次运行里两次调用编出了两个不同日期 （2025-04-15 / 2025-06-15）。这坐实了根因是"提示词依赖了模型不可能知道的信息"，不是模型不行。

"长度硬约束引发格式漂移"同样与模型无关 ------换了模型照样漂，且自部署模型还额外吐出了重复页眉。这是约束冲突的必然结果。

5.5 实验总表

#	实验	期望	实测	结论
0	提示词可迁移性	平台提示词能在通用模型上跑	结构完整复现	✅
1	信噪过滤	剔除广告	广告被剔除	✅
2	格式条款	遵守 Emoji/链接/描述	全部遵守	✅
3	日期正确性	标注当天日期	输出 2024-12-19（错）	❌ 日期幻觉
4	长度硬约束	正文≥500字	1362，但格式漂移	⚠️ 有副作用

六、踩坑与改进思考

6.1 缺陷清单（平台开发视角）

#	缺陷	证据/来源	影响
1	"当天日期"靠模型猜	实测输出 2024-12-19	每条简报都带一个错日期，最容易被用户发现
2	长度硬约束引发格式漂移	实测标题层级/分隔线/链接位置全变	下游若按固定格式解析，会直接崩
3	Coze 不支持 MCP	章节明述（`feature-mcp` 仍在 roadmap）	无法接入标准化工具协议，生态上限被锁
4	Coze 导出是 zip 非 json	章节明述	配置无法跨平台迁移/版本化
5	n8n 内置存储非持久	`Simple Vector Store` / `Simple Memory` 基于内存	服务重启即丢数据，不能上生产
6	平台锁定（vendor lock-in）	导出格式不通用	迁移成本高
7	免费额度限制	FastGPT 免费版额度有限；Coze/Dify 高并发有瓶颈	验证期够用，放量要付费或自建

6.2 修复方向

缺陷	修复
1	日期/时间用变量注入（{``{today}}），并在 System Prompt 里写明"不得自行推断日期"
2	若要长文 + 稳格式：把输出改成结构化字段（标题/链接/描述分字段），或对格式条款加"即使扩写也不得改动标题层级、分隔线与链接位置"的强约束
3	需要 MCP 能力的关键链路，改用 FastGPT / Dify（原生支持 MCP）
4	关键流程自建或用支持 json 导入导出的平台，把配置纳入 Git
5	n8n 生产环境替换为 Pinecone / Redis 等持久化后端
6	选型时把"配置可导出性 "当硬指标；核心逻辑尽量留在代码侧而非平台侧
7	用"混合开发"分摊：平台做标准流程，代码做长尾逻辑

6.3 我在方法上踩的坑

一开始想"在服务器上把 Coze 搭出来" ------很快意识到这不可行（需账号、需浏览器、需人工拖拽）。正确做法是承认边界，转做"提示词实测" ：把平台里唯一可迁移的资产 （提示词）拿到云端验证。"在云端执行"不等于"必须把整个平台搬上去"。
差点把"格式漂移"当成模型不听话 。其实它是两个目标（长 + 稳格式）冲突 的必然结果。看到模型"跑偏"，先问"我是不是给了它互相矛盾的指令"。

6.4 自我拷问（grill）

"低代码一定比写代码快吗？" ------只在"标准化流程"上成立 。本例中，"把提示词搬到云端跑"这件事，低代码平台反而比 20 行 Python 更慢。前提：需求能落到平台已有的节点上。
"提示词写详细就一定好？" ------不一定。"≥500字"这条越详细越糟 （引发漂移）。详细 ≠ 精确，精确指的是"约束之间不打架"。
"Coze 不支持 MCP 是致命伤吗？" ------取决于你要不要接标准化工具 。若你只用它的内置插件+发布能力，MCP 缺失无感；一旦要接企业内部系统，它就成了硬障碍。"致命"是有条件的判断，不是绝对结论。
"能不能既长又稳？" ------能，但前提是把"长度"和"结构"分开管 ：结构用字段/模板锁死，长度只放开"描述字段"的篇幅。这是设计问题，不是提示词玄学。

七、习题思路速记

习题 1 · 四平台定位与开发模式

定位差异：Coze 求易（零代码+发布）、Dify 求全（开源+企业级）、FastGPT 求深（RAG）、n8n 求连（自动化）。
三种开发模式适用场景：纯低代码 ------需求标准化、要快速验证、团队无工程能力；纯代码 ------精细控制、特殊逻辑、性能敏感；混合------最常见：平台做入口/编排/标准流程，代码做核心逻辑/特殊工具/数据处理。

习题 2 · Coze 简报扩展

定时推送：Coze 侧用"定时触发"工作流 + 飞书/微信机器人插件；若平台不支持定时，就退化为"外部 Cron 调它的 API"。
提示词优化 ：加"热点分析/趋势预测"模块时，必须要求模型引用具体来源 （否则趋势就是编的）；并把日期改为变量注入（对应 §5.3 实测教训）。
MCP 是什么为何重要 ：MCP（Model Context Protocol）是"工具接入的标准化协议 "------把"每个平台自己定义工具格式"变成"所有工具按同一协议暴露"。它重要在互操作性：工具一次开发、多平台复用。Coze 若支持 MCP，将能接入整个 MCP 生态的现成工具，生态上限被打开。

习题 3 · Dify 深入

分类器 + 子智能体的优势：降低单点复杂度、便于独立迭代、可按任务选模型。单一智能体处理全部任务会遇到：提示词臃肿、工具选择精度下降、一处改动影响全局。
50 表 × 20 字段的 DDL 过长：不要全塞 。方案：建"表级摘要 + 向量检索"，按用户问题先召回相关表 ，只注入被召回表的完整 DDL（即"Schema RAG"）。
本地部署 vs 云部署：本地=数据不出内网、可控、但要自己运维；云=省运维、弹性、但有数据出境与成本问题。强合规场景选本地，小团队选云。

习题 4 · n8n 深入

持久化改造：把 Simple Vector Store 换成 Pinecone/Qdrant，Simple Memory 换成 Redis/Postgres；配置要点是改节点类型 + 填连接信息 + 迁移已有数据。
附件理解：在邮件触发节点后加"附件分发"分支------PDF 走文档解析（MarkItDown/PyPDF）→ 切分 → 向量化入库；图片走 OCR/多模态模型。
电商下单自动化：Webhook(下单) → 并行 [发确认邮件 | 更新库存DB | 通知物流 | 写CRM] → 汇总 → 异常告警。关键是并行分支 + 失败重试 + 幂等（避免重复下单通知）。

习题 5 · 提示词对比（可对照 §5 实测）

结构差异与平台特性相关：Coze 偏"运营向、可读性 "（Emoji/署名/模块化）；Dify 偏"工程向、结构化 "（五段式）；n8n 偏"执行向、步骤化"（执行步骤 + 规则限制）。
"超过500字"是否合理：实测证明它有副作用 （408→1362 但格式漂移）。该限制长度 ：需固定篇幅的正式文案、下游有长度约束的场景；该放开 ：探索性生成、需要模型自行决定详略的场景。更好的做法：给"下限"（必须覆盖的要点）而不是"字数"。

习题 6 · 工具与插件扩展

平台都没有你要的工具时：自建服务 + 暴露为标准协议（优先 MCP），再用平台的"自定义工具/HTTP 节点"接进去。
MCP vs RESTful vs Tool Calling：RESTful 是"人写代码调接口"；Tool Calling 是"模型按各家私有格式调用"；MCP 是"统一的工具描述与调用协议 "，让工具像 USB 设备一样即插即用。称其"新标准"的原因是它把工具从"每家一套"变成"一套通用"。
Dify 自定义插件流程要点：创建插件工程 → 定义工具描述（schema）→ 实现逻辑 → 本地远程调试 → 打包发布到 Marketplace。

习题 7 · 平台选型（三个应用）

应用A（C 端写作小程序，快速验证，1 前端 + 1 PM） → Coze。理由：零代码、发布渠道现成、人力结构匹配（无后端）。
应用B（企业合同审核，数据不出私有环境，需深度集成 OA/文档系统） → Dify（私有化部署） 或 FastGPT + 自建。理由：合规要求排除 SaaS；需要与内部系统集成 → 倾向可自建、插件可扩展的平台。
应用C（研发效能工具，多流程自动化，团队技术强） → n8n（自建） + 代码。理由：核心价值是"连接"现有研发系统（Git/CI/Bug 跟踪），n8n 节点最全；技术强 → 长尾逻辑自己写。

八、本章小结

本章回顾

节	一句话
5.1	平台化的价值 = 降门槛 / 提效率 / 可视化 / 标准化，本质是"更高层次的抽象"
5.2	Coze 用插件 + 一键发布赢在易用，输在不支持 MCP、导出不可迁移
5.3	Dify 用开源 + 模型中立 + 私有化赢在可控与可扩展
5.4	FastGPT 把 RAG 全链路做深，是知识库问答的专机
5.5	n8n 的价值在"连接"，但内置存储非持久，生产要换后端
5.6	结论：平台与代码互补，"混合开发"才是最佳实践

核心"公式"

复制代码

智能体的能力 = 平台节点/插件（能力供给）
             × 提示词质量（能力调度）
             × 数据源质量（事实边界）

（三者相乘：任何一项接近 0，产物就接近 0------记住这不是加法。）

三句话记住本章

平台替你干了"实现细节"，但把"业务逻辑 + 提示词"还给了你------重心只是转移，没有消失。
插件/知识库配置决定了"事实边界"：源里没有的东西，模型只会编（实测：日期就是这样被编出来的）。
硬约束之间会打架 ：要"长"，就可能丢"格式稳"；要同时满足，就得把结构锁成字段，而不是写成期望。

与前后章的呼应

第五章	在哪一章"活"过来
提示词分层（System/User）	第一章（`AGENT_SYSTEM_PROMPT` 四段式）
问题分类器 + 子智能体	第四章（Plan-and-Solve 的 Planner）
知识库 / RAG	第三章（幻觉的分层缓解）
多智能体模式	第六章（AutoGen / AgentScope）

自测清单（能答上来说明真懂了）

低代码平台"降低门槛"之后，开发者真正的产出物变成了什么？（答：提示词 + 编排 + 数据源配置）
为什么"当天日期"必须变量注入，而不能写进提示词？（第三章：模型只问最可能，不问对不对）
实测中"≥500字"为什么会把 ### 标题 变成 【标题】？（两个目标冲突）
Coze 不支持 MCP 具体卡住了什么？（工具接入的标准化与互操作）
n8n 的 Simple Memory 为什么不能上生产？（内存存储，重启即失）
"混合开发"的分界线画在哪？（标准化 vs 长尾；平台做前者，代码做后者）
四平台里，哪个最适合"数据不能出门"的企业？（Dify 私有化 / 自建）

下一步

本章的四种方式都是**"把 Agent 拼出来"**。下一章往前再走一步：当角色从 1 个变成 4 个、5 个，谁先说话、什么时候插话、怎么不让对话跑偏 ------这就不是"搭一个智能体"，而是"编排一群智能体"。AutoGen、AgentScope、CAMEL、LangGraph 各自给出了不同的答案。

💡 最后留一个我印象最深的数字 ：同一套提示词、同一批数据，只加了一句"正文不少于500字"，输出就从 408 字节涨到 1362 字节，同时丢掉了 3 项格式约定 。约束不是越多越好，是越不矛盾越好。

第五章 基于低代码平台的智能体搭建 · 学习笔记（Coze / Dify / FastGPT / n8n）

一、知识地图

二、核心概念

2.0 先立骨架：四平台总表（本章最该背下来的一张表）

2.1 为什么平台化会赢在一部分场景（四个价值）

2.2 Coze：把"出装"配齐就能上分

2.3 Dify：企业级的关键是"模型中立 + 可私有化"

2.4 FastGPT：RAG 做深，比做广更难

2.5 n8n：AI 只是管道里的一个"阀"

2.6 平台里的提示词工程（本章最可迁移的部分）

三、把第五章"接回"前四章

四、"配置"精读（本章无代码，改读配置）

4.1 Coze「每日AI简报」的信息源配置

4.2 Coze 的 System Prompt（逐条拆）

4.3 n8n 主工作流的提示词结构

五、实验记录（把平台提示词搬到云端实测）

5.0 结论先行

5.1 测试 1：原始提示词（LEN=408）

5.2 测试 2：追加"正文不少于 500 字"硬约束（LEN=1362）

5.3 日期幻觉：一条提示词，一个必错项

5.4 复测：改用云端自部署模型（Qwen3-1.7B）

5.5 实验总表

六、踩坑与改进思考

6.1 缺陷清单（平台开发视角）

6.2 修复方向

6.3 我在方法上踩的坑

6.4 自我拷问（grill）

七、习题思路速记

八、本章小结

本章回顾

核心"公式"

三句话记住本章

与前后章的呼应

自测清单（能答上来说明真懂了）

下一步

第五章基于低代码平台的智能体搭建 · 学习笔记（Coze / Dify / FastGPT / n8n）