Agent 速成笔记 · 第 5 章 基于低代码平台的智能体搭建

Agent 速成笔记 · 第 5 章 基于低代码平台的智能体搭建

源：Datawhale《Hello-Agents》第 5 章 ｜ 定位：工程实现与平台选型 ｜ 一句话：把第 4 章手写的 ReAct / Plan-and-Solve / Reflection 循环，换成可视化节点编排，并搞清楚 Coze、Dify、FastGPT、n8n 各自能做什么、不能做什么。

0. 一章速览（30 秒）

  • 一句话：低代码平台把「API 调用、状态管理、并发控制」封装成节点，你只负责把节点连成数据流；模型能力决定智能体下限，工具与编排决定上限。
  • 本章解决什么问题：第 4 章证明了手写代码能做出智能体，但纯代码在原型验证与复杂业务维护上成本太高。本章回答：什么时候该换成平台、四个代表平台的关键机制分别是什么、怎么选。
  • 必须记住的 4 个点：
    • 低代码不取代代码，而是更高层次的抽象；两者互补，最终形态是「混合开发」。
    • 四平台差异的本质在第一等公民是什么：Coze 是插件与发布渠道，Dify 是全栈与运营（LLMOps），FastGPT 是知识库 RAG，n8n 是节点与「连接」。
    • 通用心智模型：输入 → 编排（路由/分支/循环）→ 工具与知识库 → 输出。四平台是同一套骨架，只是节点叫法不同。
    • 平台方案的四大局限：可观测性有天花板、版本管理弱、成本随调用量上升、平台锁定。

1. 平台化构建的兴起（对应 5.1）

1.1 为什么需要低代码平台：四个核心价值

  • 怎么运作 / 为什么：

    1. 降低技术门槛：非技术角色（产品经理、设计师、业务专家）也能参与设计与创造。
    2. 提升开发效率：原本需要数天编码的原型，可用数小时甚至数分钟完成。开发者把精力从底层工程实现，转向业务逻辑梳理与提示工程优化。
    3. 提供更优的可视化与可观测性：相对终端打印日志，你能看到数据在每个节点之间如何流动、哪个环节耗时最长、哪个工具调用失败。
    4. 标准化与最佳实践沉淀：平台内置预设的 ReAct 模板、优化的知识库检索引擎、标准化的工具接入规范。

    第 1 条是「让本来写不了代码的人能参与」，第 2 条是「让会写代码的人不必重复劳动」——两者对应完全不同的场景，选型讨论里常被混为一谈。第 4 条在长期项目中价值最高也最易被忽略：一旦换平台，沉淀基本归零，这正是平台锁定的成本来源。

1.2 四个代表性平台的定位（一句话区分）

平台 核心定位 第一等公民 典型适用人群
Coze 零代码 / 低代码 Agent 构建 插件生态 + 一键多平台发布 入门用户、产品经理、运营
Dify 开源的 LLM 应用开发与运营平台 全栈能力 + LLMOps 有技术背景的开发者、企业团队
FastGPT 开源的知识库问答与 Agent 构建工具 RAG 知识库链路 中小企业、客服/知识助手团队
n8n 通用的工作流自动化工具（非纯 LLM 平台） 节点与「连接」能力 需要深度业务集成的开发者

Coze 由字节跳动推出，主打零代码/低代码构建体验，内置极丰富的插件库，支持一键发布到抖音、飞书、微信公众号等主流平台，把分发流程一并简化。Dify 强调开源 + 从原型到生产部署的一站式，融合后端服务与模型运营理念。FastGPT 专注 RAG 场景极致优化，模型中立。n8n 本质是通用自动化工具，近年积极集成 AI 能力，强项是「连接」，但学习曲线相对陡峭。

2. 平台一：Coze —— 零代码入口与插件生态（对应 5.2）

2.1 概念对应关系

Coze 的抽象层与第 4 章的代码概念一一对应，这是理解它的最快方式：工作流是固定路径的编排（等价于页面级的 Workflow）；对话流面向多轮对话；插件等价于代码里的工具函数；知识库是 RAG 检索源；卡片是前端展示组件；提示词等价于 System Prompt；另配数据库、发布管理、模型管理与效果评测。

创建入口有两类应用：智能体（单智能体自主规划模式 / 单智能体对话流模式 / 多智能体模式）与应用（可搭建桌面网页端、小程序与 H5 界面）。资源库统一存放工作流、知识库、卡片、提示词库等资产；空间配置统一管理智能体、插件、工作流、发布渠道与模型。

记忆锚点：模型决定智能体的下限，资源库决定能力的上限。

2.2 构建流程要点：「每日 AI 简报」助手

该智能体从 36氪、虎嗅、it之家、infoQ、GitHub、arXiv 多源抓取当日 AI 头条、论文与开源项目动态，合成结构化简报。流程压缩为四步：

  1. 建工作流：在资源库中 +资源 → 工作流。
  2. 接入信息源插件：搜索 RSS（订阅媒体源）、GitHub（追踪开源项目）、arXiv（获取论文）三类插件，并做个性化配置——RSS 填各站订阅链接；GitHub 设置关键词查询数量与最新更新；arXiv 定义领域关键词与数量。
  3. 编排连接：把已配置的插件（rss_24Hbj、searchRepository、arxiv）作为数据输入节点，连接至后续逻辑处理模块（大模型模块）。
  4. 测试、调试与多渠道发布：预览运行，检查准确性与格式完整性；不达标则回退到提示词或插件配置环节调整（内容不够精炼就改概括要求，数据不准就查插件参数）。
  • 关键机制：变量注入。插件节点的输出被命名成变量，提示词用 {{articles}}、{{arxiv}}、{{GitHub}} 这类占位符引用。例如提示要求「从输入源 {{articles}} 等中筛选 AI 相关文章」「从 {{arxiv}} 中按 arxiv_title 和 arxiv_link 字段总结论文」「从 {{GitHub}} 中筛选最受瞩目的 5 个 AI 开源项目」。这就是可视化编排里「数据流」的落地形式：节点产出变量，提示词消费变量。

2.3 关键机制：System Prompt 与 User Prompt 的分工

  • System Prompt 定义长期行为准则与输出格式规范：日报开头标注「AI日报」、作者与日期；每条标题开头加独有 Emoji；排除一切与 AI/LLM/AIGC/大模型无关的信息与营销内容；每条目必须附原始链接并给出简短概况。
  • User Prompt 定义具体任务指令与数据来源：从 {{articles}} 等抽标题与链接组成「AI技术新闻」；从 {{arxiv}} 组「AI学术论文」；从 {{GitHub}} 取 5 个项目组「AI开源项目」；并规定总量：10 条新闻、5 篇论文、5 个开源项目。

为什么这样拆：格式与准则几乎不变，变的只是数据源与配比。改配比只动 User Prompt，改风格只动 System Prompt，互不干扰。

2.4 Coze 的能力边界

  • 优势：插件生态强大；可视化编排门槛低；提示词控制细腻且支持模板管理；多平台部署便捷，生态仍在接入新的手机与硬件厂商。
  • 局限：
    • 不支持 MCP（Model Context Protocol）——原文评价为「最致命」：插件市场再丰富，也缺少一个跨平台的开放标准。
    • 部分插件配置复杂度高：需要 API Key 或高级参数的插件要求技术背景；复杂工作流编排也需要一定 JS 或 Python 基础。
    • 无法导入标准编排文件：付费版可导出导入，但导出的是 zip 而非像 Dify / n8n 那样的 JSON，只能在 Coze 内闭环流转；变通做法是在编排界面全选复制、粘贴到空白工作流。

3. 平台二：Dify —— BaaS + LLMOps 的全栈平台（对应 5.3）

3.1 定位与架构

  • 是什么：Dify 是开源的大语言模型应用开发平台，融合后端即服务（BaaS）与 LLMOps 理念，覆盖从原型设计到生产部署的全流程。
  • 怎么运作：采用分层模块化架构——数据层、开发层、编排层、基础层，各层解耦以便扩展。这一架构决定了它的能力重心：编排层负责 Agent 工作流，数据层负责 RAG Pipeline、数据标注与微调，基础层负责模型接入。
  • 模型中立性：支持数百种开源或专有 LLM 集成（GPT、Deepseek、Llama 等），以及任何兼容 OpenAI API 的模型，通过统一接口调用推理能力。
  • 部署形态：本地部署（官方提供 Docker Compose 一键启动）与云端 SaaS 两种模式；前者适合对数据隐私有要求的企业内网。

3.2 生态与插件市场

Dify Marketplace 提供一站式插件管理与一键部署，类目五类：模型（Models）、工具（Tools）、智能体策略（Agent Strategies）、扩展（Extensions）、捆绑包（Bundles），插件总量已超过 8677 个。官方推荐插件包括 langgenius/google、langgenius/azure_openai、langgenius/notion、langgenius/duckduckgo。其远程调试能力可与主流 IDE 协作：开发者连到 Dify 的 SaaS 服务，同时把所有插件操作转发到本地环境测试。

3.3 关键机制：问题分类器与多智能体路由

案例「超级智能体个人助手」的核心设计是用问题分类器做智能路由：为每个子智能体定义核心功能与任务范围，把用户请求准确分发到对应模块。

为什么必要：不做路由，就必须让单一智能体同时持有全部工具与全部提示词约束，结果是上下文变长、工具选择范围变大、指令互相干扰、错误率上升。做路由后，每个子智能体的工具集与提示词被裁剪到最小必要范围，问题被局部化。

案例中实际出现的 Dify 节点类型：

节点类型 作用 案例中的用法
问题分类器 按意图路由请求 分发给五个子智能体
大语言模型节点 生成与整理 兜底问答、SQL 结果转自然语言
工具/插件节点 调用外部能力 即梦生图/生视频、数据库查询、BI 图表
循环节点 重复任务 轮询获取视频生成任务结果
条件判断节点 分支控制 与循环配合处理异步任务
表单输入节点 采集结构化输入 风险评估问卷
知识库检索 召回私有文档 回答概念性问题
MCP 调用 接入外部 MCP 服务 高德地图、饮食推荐、新闻资讯

3.4 构建流程要点

  1. 装插件 + 配 MCP：装核心插件（rookie-text2data、BI 图表、即梦插件），从魔搭社区 MCP 市场选 hosted 类型服务。以高德 MCP 为例，选 SSE 模式并连接配置，即可生成 MCP 配置 JSON。MCP 支持多种通信模式，但在 Dify 中使用 SSE 模式更加流畅稳定。
  2. 搭多智能体编排：五大模块——日常问答、文案润色、多模态生成、数据查询与可视化、MCP 工具集成；用问题分类器路由。
  3. 逐模块配提示词与工具：日常助手配大模型与时间工具作兜底；文案优化用「角色人设 / 背景 / 任务目标 / 限制提示 / 输出格式要求」五段式提示词（据 OpenAI 数据报告，超过 60% 的用户用 ChatGPT 做文本优化任务）；多模态用即梦插件配图片比例与模型（seedream 生图、seedance 生视频），用循环节点轮询视频任务；数据查询的关键是为大模型提供清晰的表结构和字段信息（给 DDL 语句，或表名与字段名对应关系），查完再由大模型节点转成自然语言；数据分析追加 generate_pie_chart、generate_column_chart、generate_line_chart，并要求至少生成 1 幅图表。
  4. 集成 MCP 到智能体：选支持 MCP 的智能体策略 → 选 ReAct 模式 → 配置 MCP 服务（删除 mcp-server 前缀，选 SSE 模式）→ 填提示词。

第 4 步的 ReAct 模式说明：平台没有发明新的智能体范式，它把第 4 章手写的 ReAct 循环包装成了一个下拉选项。

3.5 Dify 的能力边界

  • 优势：全栈式开发体验（RAG 管道、AI 工作流、模型管理合一）；低代码便利性与专业灵活性平衡；企业级安全与合规（AES-256 加密、RBAC 权限控制、审计日志）；工具集成丰富（9000+ 工具和 API 扩展）；开源社区活跃。
  • 局限：学习曲线较陡；性能瓶颈——高并发需额外优化，核心服务端由 Python 实现，与 C++、Golang、Rust 相比性能相对较差；多模态支持不足（以文本为主，图像、视频、HTML 有限）；企业版成本较高；API 兼容性问题——Dify 的 API 格式不兼容 OpenAI，可能限制与第三方系统集成。

4. 平台三：FastGPT —— 知识库问答的第一等公民（对应 5.4）

4.1 定位

FastGPT 是开源的、基于大语言模型的知识库问答平台与 Agent 构建工具，自我定位「企业级 AI 生产力引擎」。与 Coze 的零代码体验、Dify 的全栈能力形成对照：它把知识库问答当作第一等公民，围绕「数据导入 → 智能分块 → 向量检索 → 对话生成」完整链路深度优化。界面分对话门户、工作台、知识库、账号四大模块；Agent 细分为工作流、对话 Agent、对话 Agent V2(Beta) 三种类型。

4.2 关键机制：RAG 链路上的可调参数

  • 文件处理方式二选一：分块存储 或 问答对提取。
  • 分块条件：可设触发阈值，例如原文长度大于 1000 字符时触发分块。
  • 索引增强三项：标题加入索引、自动生成补充索引、图片自动索引。
  • 为什么「图片自动索引」重要：对图文混排文档（教材、研报），它让大模型回答时理解并引用文档中的视觉信息，而不是只看到文字。
  • 透明化调试：平台展示每个分块的文本预览与元数据（文件大小、原文长度、处理模式、图片索引状态）。这是知识库调优的前提——没有它，你只能靠试。

4.3 免费版配额（硬信息，选型时直接对照）

配额项 免费版额度
积分 100
知识库索引 600 条
团队成员 1 个
Agent 数量 10 个
知识库数量 3 个
对话记录保留 30 天
调用速率 30 QPM

另有单次可上传 5 个 50MB 文件的权限；支持导入 Word、Markdown、PDF 等常见格式。文件状态显示「已就绪」后即可在对话中被检索引用。

4.4 构建流程要点：「智能投顾助手」

  1. 配置 MCP 工具：两类服务——实时股票行情查询、金融数据与图表生成。从魔搭社区（ModelScope）取「可视化图表 MCP Server」（基于 TypeScript 开发、兼容 MCP 协议，可生成面积图、柱状图、饼图），从阿里云百炼取金融类 MCP。填写服务地址与认证信息，并为每个工具设置独立描述和调用参数——描述供智能体决策时理解用途。
  2. 设计工作流（Flow 模块）：拖拽节点、连接边线。意图识别节点按输入类型分流——金融概念咨询走知识库检索，股票查询走 MCP 调用，投资诊断进风险问卷收集；投资知识教育专员连知识库检索投资理论；风险评估分析师用表单输入节点采集年龄、投资经验、月收入水平、风险承受能力、投资目标，再交给大模型节点生成结构化策略报告；市场新闻情报专员按需调用 MCP；通用咨询专员处理寒暄。
  3. 配提示词与知识库：限制提示明确要求避免提供具体金融产品推荐（不点具体股票或基金名称），仅讨论一般性资产类别；不得做出任何保证收益的承诺或预测，强调投资有风险。同时上传投资学基础、财务报表分析、宏观经济指标解读等文档建库。
  4. 测试与效果校验：以「市盈率和市净率有什么区别」为例，智能体基于知识库给出定义、四维对比（计算基础、适用行业、反映信息、局限性）与应用建议。
  • 关键收益：降低幻觉。概念性问题由知识库检索出准确定义与对比分析，而不是完全依赖大模型的预训练知识，从而有效降低幻觉风险。工具调用侧的例子：查询「现在贵州茅台的股价信息」时自动调用 get_stock_quote_realtime，返回含开盘价、最高价、成交量、总市值等要点的结构化输出。

4.5 FastGPT 的能力边界

  • 优势：极致的知识库体验（上传、分块、索引增强、图片识别到检索召回，每环节可精细配置并有透明调试界面）；原生 MCP 支持（与 Coze 形成直接对照，工具扩展不受平台内置插件库限制）；模型中立（OpenAI、Claude、通义千问、DeepSeek 自由切换）；可视化 Flow 编排降低门槛。
  • 局限：模板生态相对薄弱（官方模板与预置工具有限，虽由 MCP 部分弥补，但非技术用户配置 MCP 仍有门槛）；免费版额度紧张（100 积分 + 30 QPM）；社区与文档仍在完善中，边缘问题可能需深入源码。

5. 平台四：n8n —— 节点即一切（对应 5.5）

5.1 核心概念：节点与工作流

理解 n8n 的前提：它的核心身份是通用工作流自动化平台，不是纯粹的 LLM 应用构建工具。在 n8n 里做智能体，实际是在设计一个更大的自动化流程，大语言模型只是其中一个（或多个）「处理节点」。

  • 节点（Node）：执行具体操作的最小单元。n8n 提供数百种预置节点，涵盖发送邮件、读写数据库、调用 API、处理文件等。分两类：
    • 触发节点（Trigger Node）：整个工作流的起点，例如「当收到一封新的 Gmail 邮件时」「每小时定时触发一次」「当接收到一个 Webhook 请求时」。一个工作流必须有且仅有一个触发节点。
    • 常规节点（Regular Node）：处理具体数据与逻辑，例如「读取 Google Sheets 表格」「调用 OpenAI 模型」「在数据库中插入一条记录」。
  • 工作流（Workflow）：多个节点连接而成的自动化流程图，定义数据从触发节点开始如何逐步传递与被处理。数据在节点之间以结构化的 JSON 格式传递，每个环节的输入输出都能被精确控制。

记忆锚点：n8n 的真正威力在「连接」。 它把企业内部 CRM、外部社交平台、你的数据库与大语言模型串成端到端流程。

5.2 关键机制：AI Agent 节点

这是 n8n 相对传统自动化的分水岭。传统自动化流程是线性的；AI Agent 节点则让流程能接收输入、进行「思考」、自主理解意图并在多个可用工具中决策选择。过去要把工具拆成多个子工作流手动路由，现在三类组件整合在一个统一界面中——Chat Model（大模型，Agent 的「思考核心」）、Memory（让 Agent 在同一会话线索的多轮往来中记住历史）、Tools（可挂载多个工具，Agent 自行决定调用哪个）。决策链可概括为：接收 → AI Agent（思考 → 决策 → 工具调用）→ 回复。

5.3 构建流程要点①：为 Agent 准备私有知识库

可视化 RAG 的最小可运行三段式：

  1. 定义知识源：用 Code 节点存放原始知识文本（JSON 格式，字段为 doc_id 与 content）。
  2. 文本向量化：用 Embeddings Google Gemini 节点，模型选 gemini-embedding-exp-03-07，接在 Code 节点之后，自动把上游文本转成向量。
  3. 存入向量存储：用 Simple Vector Store 节点，Operation Mode 设为 Insert Documents（写入模式），Memory Key 设为唯一名字（案例为 my-dailytime）。

完成后手动执行一次该流程。这个准备流程只需在更新知识时运行一次，不必随主流程反复执行。

5.4 构建流程要点②：Agent 主工作流

  1. 配触发器：新建工作流（案例命名 Agent: Customer Support），用 Gmail 节点作触发器，Event 设为 Message Received，配置邮箱账号。
  2. 配 AI Agent 节点：挂载 Chat Model（如 Google Gemini Chat Model）、Memory（Simple Memory，用于同一邮件线索下记住往来历史）、Tools（SerpAPI 提供上网搜索能力，Simple Vector Store 提供私有知识库查询能力）。
  3. 写提示词：主要填 User Message 与 System Message。案例把邮件正文与主题作为变量传入（{{ $json.snippet }}、{{ $json.Subject }}），并在 System Message 中写明角色目标、上下文、可用工具、执行步骤、规则限制。步骤写得很具体：分析问题 → 并行搜集信息（同时用 SerpAPI 搜答案、用向量库取工作时间）→ 草拟核心回复 → 对比当前时间与工作时间、按是否属非工作时间拼接状态前缀 → 以严格 JSON 格式输出。
  4. 配置工具的关键三参数：对 Simple Vector Store 工具，Operation Mode 设为 Retrieve Documents (As Tool for AI Agent)；Memory Key 必须与写入时完全相同；Embeddings 模型也必须完全相同。
  5. 发送回复：把 AI Agent 输出连到 Gmail 节点，Operation 设为 Send，用 n8n 表达式关联收件人（{{ $('Gmail').item.json.From }}）、主题（Re: {{ $('Gmail').item.json.Subject }}）与正文（{{ $json.output }}）。

案例还要求 Agent 以严格 JSON 契约输出，这是让下游节点能稳定取值的关键：

{
  "shouldReply": true,
  "subject": "Re: [原始邮件主题]",
  "body": "[拼接好的完整回复正文，所有换行必须使用 <br> 标签]"
}

这段约定的作用：把「自然语言回复」变成结构化字段，下游 Gmail Send 节点才能按字段名（而非靠字符串解析）取到主题与正文。

  • 为什么 Key 与嵌入模型必须一致：只有两者完全一致，Agent 才能用正确的「钥匙」和「语言」访问知识库。不一致时检索通常不报错，而是静默返回不相关结果，是最隐蔽的坑。
  • Memory 唯一标识技巧：用每个邮箱的线程名作唯一标识，Key 设为 {{ $('Gmail').item.json.threadId }}，使同一邮件的多轮往复共享一段记忆，不同邮件互不污染。

5.5 n8n 的能力边界

  • 优势：开发效率高（整条数据流在画布上一目了然）；功能强大且高度集成（内置节点库可连接 Gmail、Google Gemini 等数百种服务，AI Agent 节点把模型、记忆、工具高度整合，覆盖不到的场景可用 Code 节点写自定义代码）；支持私有化部署，敏感数据不出自有环境。
  • 局限：
    • 调试与错误处理相对繁琐：复杂工作流出数据格式错误时，需逐个节点检查输入输出，不如在代码中设断点直接。
    • 内置存储非持久：Simple Memory 与 Simple Vector Store 都基于内存，服务重启后对话历史与知识库全部丢失——生产环境必须替换为 Redis、Pinecone 等外部持久化数据库。
    • 版本控制与多人协作不如传统代码成熟：工作流可导出 JSON，但变更对比远不如 git diff 清晰，多人同时编辑易冲突。
    • 性能：能满足绝大多数企业自动化与中低频 Agent 任务；超高并发下节点调度会带来性能开销。

6. 四平台对比与选型判断

6.1 能力边界对比表

维度 Coze Dify FastGPT n8n
上手门槛 最低 中（需技术背景） 中低 较高
核心强项 插件 + 多平台发布 全栈 + 企业级 RAG 知识库 节点连接与自动化
MCP 支持 不支持 支持（SSE 模式） 原生支持 通过节点接入
私有化部署 无 支持（Docker Compose） 开源可自建 支持
主要短板 无 MCP、配置难迁移 学习曲线、Python 性能 模板生态弱、免费额度紧 内存态、版本管理弱

6.2 选型决策规则

  • 快速原型验证、非技术用户参与 → Coze。
  • 企业级应用、复杂业务逻辑、多模态生成 → Dify。
  • 基于私有知识库的问答系统、智能客服 → FastGPT。
  • 深度业务集成、通用自动化流程 → n8n。

补一条判断标准：任务的瓶颈在哪一环，就选在该环最强的平台。瓶颈是发布与传播选 Coze，是长期运营与多模态选 Dify，是文档问答准确率选 FastGPT，是打通已有系统选 n8n。

6.3 低代码 vs 代码框架：判断标准

判断维度 倾向用平台 倾向用代码
项目阶段 原型验证、需求未定型 需求稳定、需精细控制
逻辑复杂度 标准化流程、分支可枚举 特殊逻辑、非标准控制流
并发与性能 中低频任务 超高并发
数据合规 平台能满足时 敏感数据需完全自控
团队构成 非技术角色为主 有较强技术实力

最佳实践是「混合开发」：用低代码平台快速验证想法，用代码实现精细化控制；用平台处理标准化流程，用代码处理特殊逻辑。按不同阶段灵活切换，而不是二选一。

7. 平台方案的通用心智模型与典型局限

7.1 通用心智模型：输入 → 编排 → 工具/知识库 → 输出

四平台看起来差异巨大，拆开后是同一套骨架，只是节点叫法不同：

  • 输入层：Coze 插件节点，Dify 问题分类器 / 表单输入节点，FastGPT 意图识别节点，n8n 触发节点（Gmail 的 Message Received、Webhook、定时器）。
  • 编排层：Coze 工作流 / 对话流，Dify 问题分类器 + 条件判断 + 循环，FastGPT Flow 多分支，n8n 节点连线。
  • 工具与知识库层：Coze 插件 + 知识库，Dify 插件市场 + MCP + 知识库，FastGPT MCP 工具 + 知识库，n8n Tools（SerpAPI）+ Simple Vector Store。
  • 输出层：Coze 多渠道发布，Dify 应用 / API，FastGPT 对话界面 + 报告，n8n Gmail Send 或任意下游系统。

掌握这套骨架后，学新平台的成本会大幅下降——只需问四个问题：输入从哪来？怎么分流？能用哪些工具和知识？结果送到哪？其中编排层最需花心思，核心决策只有三个：是否需要路由、是否需要循环、是否需要条件分支。

7.2 平台方案的典型局限

  • 可观测性有天花板：节点级可视化能看出哪个环节耗时最长、哪个工具调用失败，但节点内部发生了什么你看不到——例如大模型节点内部的多轮工具调用轨迹，不如自己写日志细致。排查「模型为什么选了错的工具」时，平台反而不如代码。
  • 版本管理弱：n8n 最典型——工作流可导出 JSON，但变更对比远不如 git diff 清晰，多人编辑易冲突；Coze 更极端，导出的是 zip 而非标准 JSON。
  • 成本随调用量上升：平台按积分 / 额度 / 套餐计费（如 FastGPT 免费版 100 积分、30 QPM），频繁迭代下额度消耗很快；企业版定价可能超出小型团队预算。低代码节省的是开发成本，未必节省运行成本。
  • 平台锁定：提示词、编排、评测沉淀都绑在平台上。原文的判断一针见血——模型都可以接入，提示词、编排都可以复制，但工具插件的有无直接决定效果；真正被锁定的是工具链与配置格式。
  • 性能与并发瓶颈：Dify 核心服务端由 Python 实现，性能相对较弱；n8n 的节点调度在高并发下有额外开销。

8. 高频考点 & 易错点速查

  1. 低代码平台四项核心价值（降门槛、提效率、强可视化、标准化沉淀）。
  2. 四平台「第一等公民」对应关系：Coze 是插件，Dify 是分层全栈，FastGPT 是 RAG，n8n 是节点与连接。
  3. Coze 不支持 MCP；Dify 与 FastGPT 支持 MCP，且 Dify 中推荐用 SSE 模式。
  4. Dify 关键词：BaaS + LLMOps、四层架构（数据/开发/编排/基础层）、模型中立、Docker Compose 本地部署、AES-256 + RBAC + 审计日志、API 不兼容 OpenAI。
  5. 多智能体路由为什么必要：不做问题分类器，单一智能体要同时持有全部工具与约束，上下文变长、工具范围变大、指令互相干扰。
  6. FastGPT 的 RAG 可调参数：分块存储 vs 问答对提取、分块阈值（原文长度 > 1000 字符触发）、标题入索引 / 自动补充索引 / 图片自动索引。
  7. n8n 三条铁律：一个工作流有且仅有一个触发节点；节点间用 JSON 传递；AI Agent 节点整合 Chat Model + Memory + Tools。
  8. n8n 最隐蔽的坑：向量库写入与读取时，Memory Key 与 Embeddings 模型必须完全一致，否则不报错但静默返回错误结果。
  9. 内存态存储不可用于生产：Simple Memory / Simple Vector Store 重启即丢，必须换 Redis、Pinecone 等。
  10. 章末 7 道习题的考点映射：①四平台定位差异 + 三种开发模式适配场景；②Coze 改造（定时触发与推送、提示词优化、MCP 是什么）；③Dify 深入（路由优势、大表结构下的上下文优化、本地部署 vs 云端）；④n8n 深入（持久化替换、附件处理、复杂自动化设计）；⑤提示词跨平台对比（结构与平台特性的关联、输出长度硬约束是否合理）；⑥工具扩展（无现成工具时的方案、MCP vs RESTful API vs Tool Calling、自定义插件）；⑦平台选型实战（按技术可行性、开发效率、成本、可维护性、可扩展性、合规性论证）。
  11. 易混点：RAG ≠ 微调（FastGPT 走检索增强，Dify 同时提供数据标注与微调能力）；工作流 ≠ Agent（第 1 章的分水岭在平台里依然成立：AI Agent 节点是自主决策，工作流节点是写死路径）。

9. 与前后章节的衔接

本章的输入来自第 4 章：ReAct、Plan-and-Solve、Reflection 三种工作流，在平台上分别落成了「智能体策略 / ReAct 模式」「多节点串联」「反馈回环」的可视化配置。理解平台的关键，正是先知道它在替你封装哪一段代码。

本章的输出指向第 6 章及之后：平台把编排、工具接入、知识库检索、发布渠道标准化了，但也遮蔽了底层细节；下一章转向更底层的智能体框架，以在这层抽象之下拿到更可靠的控制力。

10. 课后练习

在线试卷：https://md-quiz-online.app.workbuddy.host/

posted @ 2026-09-28 14:50  测试小罡  阅读(13)  评论(0)    收藏  举报