第五章《基于低代码平台的智能体搭建》习题答案｜逐章学习笔记

[jarvanstack]

本帖是我对《从零开始构建智能体》的逐章学习答案。基于教材仓库 main 分支提交 92e6891（2026-08-09 读取）。开放题为个人理解，欢迎指正。

原章链接：第五章 基于低代码平台的智能体搭建

平台能力变化很快。以下选型以教材版本为基线；真正实施前仍需用目标版本做 PoC、压测和安全评审。

1. 平台定位与开发模式

平台	核心定位	主要解决的痛点
Coze	面向产品和非专业开发者的快速 Bot 构建与多渠道发布	上手、插件接入、界面与发布速度
Dify	可私有化的企业级 LLM 应用平台	工作流编排、模型与知识库管理、插件、运维和团队协作
FastGPT	RAG/知识库问答优先	文档处理、分块、索引、检索调优和客服问答
n8n	通用业务自动化连接器，AI 是流程中的能力节点	SaaS/数据库/消息系统集成、触发器和长流程自动化

纯低代码适合需求标准、集成已有节点、快速验证的场景，例如两周内验证 AI 简报。纯代码适合高并发、特殊算法、精细权限、强审计或平台无法表达的控制流，例如金融审批核心。混合模式最常见：Dify/n8n 负责可视编排，代码服务承载内部检索、风控和业务 API；它兼顾速度与控制，但必须管理接口版本、部署和端到端观测。

2. Coze 每日简报扩展

自动推送流程为：定时触发器每天 08:00（明确时区）→ 多源采集 → 去重与可信度筛选 → 简报生成 → 质量检查 → 飞书机器人/公众号草稿 API → 失败重试和告警。若 Coze 版本缺少可靠调度或目标渠道，可由云函数、n8n 或系统 cron 调 Coze API。公众号通常应先生成草稿并人工确认，避免错误自动公开。

提示词建议使用结构化输入和输出：

你是 AI 行业编辑。仅根据 <sources> 中的材料生成今日简报。
要求：
1. 先去重，按“研究/产品/产业/治理”分类；
2. 每条包含：事实摘要、发生日期、来源链接、影响等级；
3. 将“已证实事实”“编辑分析”“趋势假设”分栏，趋势必须给出依据和不确定性；
4. 不足两家独立来源的重大结论标记“待验证”；
5. 总字数 800～1200 字，最后列出 3 个值得持续观察的信号。

MCP 是连接 AI 应用与外部系统的开放标准，采用客户端—服务器架构，并定义工具、资源、提示等可发现原语、生命周期和传输。它和某个具体 API 不同：同一个 MCP Server 可被多个兼容宿主发现并使用，降低重复适配成本。若 Coze 支持 MCP，便可接入内部数据库、文件系统和第三方服务，动态发现工具并复用社区 Server；同时也必须增加权限、认证、工具投毒和审计控制。参考 MCP 架构。

3. Dify 多智能体路由、数据库与部署

问题分类器能让每个子模块使用更短的提示、更小的工具集和独立评估标准，降低选择混淆，便于按任务选择不同模型和权限。单一全能 Agent 会面临上下文膨胀、工具冲突、提示互相干扰、成本高、故障域大和难以定位回归。分类器也可能误路由，因此应支持多标签、低置信度回退和通用兜底节点。

50×20 字段不应全部塞入提示。可建立 schema registry：为表、字段、业务术语、外键和示例查询生成元数据索引；先用意图和实体检索候选域/表，再通过关系图补充一跳关联，只把 top-k DDL 和权限范围交给 SQL 生成器。生成后执行 AST 白名单、只读权限、成本估计、EXPLAIN 和行数限制；失败时根据数据库错误局部修正。对稳定指标优先提供语义层/API，而不是让模型自由写 SQL。

维度	云端	本地/私有化
安全	运维由平台承担，但需评估数据出域、租户隔离和合同	数据边界可控，但补丁、密钥、备份和入侵响应由自己负责
成本	低前期成本、按量，流量大可能昂贵	硬件和团队前期成本高，稳定大流量可摊薄
性能	快速扩容，受网络和限额影响	可贴近数据源优化，容量规划更复杂
维护	升级省心，版本变化受供应商控制	能冻结版本和定制，升级迁移成本高

原型和非敏感应用适合云端；受监管、敏感数据或深度内网集成适合私有化；混合部署可把编排放云端、敏感工具留内网，但要严格控制传出的上下文。

4. n8n 持久化、附件与电商流程

向量存储可把 Simple Vector Store 换成 Pinecone/Redis/Qdrant 等节点：创建数据库与索引，配置凭据、索引/namespace 和 embedding 维度；导入分支负责加载、切块、嵌入和 upsert，问答分支以相同 embedding 检索。记忆可换成 Redis Chat Memory 或外部 SQL，session key 必须绑定用户/会话并设置 TTL。n8n 已提供多种持久化向量节点，具体字段以 n8n AI 节点文档 为准。

附件处理：邮件触发器下载二进制附件 → MIME/扩展名/大小和恶意软件校验 → PDF/OCR/图片视觉模型等专用解析器 → 文本分块 → 附件内提示注入隔离 → 与邮件正文一起分类 → 检索/生成草稿 → 敏感或低置信度转人工。原附件放对象存储，向量库只存租户、文件和页码锚点。

电商工作流：

flowchart LR
  A["订单 Webhook"] --> B["验签与幂等检查"]
  B --> C["读取订单"]
  C --> D{"并行分支"}
  D --> E["发送确认邮件"]
  D --> F["事务性扣减库存"]
  D --> G["创建物流单"]
  D --> H["CRM Upsert 客户"]
  E --> I["汇总结果"]
  F --> I
  G --> I
  H --> I
  I --> J{"全部成功?"}
  J -- 是 --> K["写入完成状态"]
  J -- 否 --> L["重试/补偿/人工告警"]

Loading

关键点是订单 ID 作为幂等键；库存使用数据库事务/原子更新；各外部系统保存调用状态；部分失败采用补偿而非整条盲目重放；密钥放凭据库；PII 最小化进入 LLM。

5. 三个平台的提示词与长度约束

Coze 简报提示偏角色、内容结构和渠道呈现；Dify 工作流提示更强调变量、分类路由和每个节点的输入输出契约；n8n 提示更像自动化节点说明，必须准确描述可用工具、业务动作和何时调用。差异与平台抽象相关：越接近显式流程，提示越应局部、结构化；越依赖单 Agent，提示越要完整描述目标和边界。

“超过 500 字”不是质量标准，可能鼓励重复和幻觉。营销稿有渠道要求时可限制区间；数据库抽取、客服回复、移动端摘要应使用严格上限或 schema；创意初稿可放宽，但仍应按受众、信息密度和结构评估。更好的写法是给出目标读者、必含信息和建议区间，并允许内容不足时短于下限。

6. 内部工具、MCP 与 Dify 插件

若商店没有内部工具，可优先用 OpenAPI/HTTP 节点封装受控网关；需要跨宿主复用时实现 MCP Server；逻辑复杂时开发平台插件；过渡阶段也可用 webhook 调内部微服务。无论哪种方式，都要做服务账号、最小权限、参数 schema、超时重试、幂等和审计。

REST 描述通用资源/HTTP 接口；Tool Calling 是模型输出“调用哪个函数及参数”的模型接口能力；MCP 则标准化宿主与外部服务之间的发现、能力协商、调用、资源/提示和传输。三者可以叠加：MCP 工具内部调用 REST，模型通过 Tool Calling 选择它。MCP 被称为“新标准”是因为它降低 M×N 适配，但不替代业务 API，也不自动带来安全。

Dify 自定义知识库插件的流程：安装脚手架 → 初始化 Tool 类型项目 → 定义 manifest、provider YAML、凭据和权限 → 为查询工具定义参数/输出 schema → 在执行代码中调用内部知识库 API，并实现分页、超时、错误映射和引用 → 本地调试 → 打包签名/安装 → 在 Workflow 中集成并做权限测试。官方流程见 Dify Tool Plugin。

7. 三个应用的选型

应用 A：Coze 起步，保留迁移接口。 团队小、预算有限、需快速验证，Coze 的 UI、插件和发布能力最匹配。核心写作模板和用户数据不要锁死在平台内部；用 API 保存版本与指标。验证 PMF 后再评估 Dify/代码化，以解决规模、可测试性和差异化功能。

应用 B：私有化 Dify + 自定义代码服务。 Dify 提供工作流、知识库、模型治理和私有化基础；合同解析、条款规则、权限、审计及 OA/DMS 适配由受控微服务承载。所有引用必须回到条款页码，高风险结论由律师确认。若客户合规极严，核心审批应纯代码，Dify 只做辅助界面。

应用 C：n8n + 代码服务，关键链路可逐步代码化。 研发工具本质是连接 Git、CI、Issue 和项目系统，n8n 适合事件触发和编排；代码审查、测试解析和权限策略用独立服务。强技术团队能维护自定义节点、可观测性与 GitOps；对高并发或严格事务链路，应转为消息队列和代码服务，不把 n8n 当唯一运行时。