第五章 习题参考答案 By 安妮的心动录

[anneheartrecord]

第五章 习题参考答案

参考答案仅供参考。本章真正重要的是理解低代码平台和纯代码开发在“速度、控制力、集成深度、合规性”上的取舍，而不是简单给平台排座次。

1. 本章介绍了三个各具特色的低代码平台：Coze、Dify 和 n8n。请分析：

这三个平台在核心定位和设计理念上有什么区别？它们分别解决了智能体开发中的哪些痛点？
低代码平台与纯代码开发各有优劣，此外，也有部分功能用平台实现，部分功能用代码实现的"混合开发"模式。思考三种开发模式分别适合哪些场景？请举例说明。

三个平台的核心定位差异

平台	核心定位	主要优势	主要短板
Coze	面向快速搭建 AI 应用和 Bot 的平台	上手快，插件生态和交互配置友好	深度定制和私有化能力相对有限
Dify	面向 LLM/Agent 应用构建的开源平台	工作流、知识库、插件和私有部署兼顾	复杂场景下仍需要一定工程能力
n8n	通用工作流自动化平台，AI 只是其中一种能力	强连接能力，适合跨系统编排	对复杂 Agent 推理的原生表达不如专用平台

从第一性原理看：

• Coze 解决的是 快做出来，并且在多平台能够分享使用。
• Dify 解决的是 既快又可控。
• n8n 解决的是 把很多系统连起来自动跑。

三种开发模式分别适合哪些场景

1. 低代码平台优先：
   适合验证需求、快速上线、团队工程资源有限的项目。
   例子：营销小程序、简报助手、活动 Bot。

2. 纯代码开发优先：
   适合高定制、高性能、高合规、复杂基础设施集成场景。
   例子：金融风控审批、企业内部研发平台、复杂多智能体系统。

3. 混合开发：
   适合把稳定流程交给平台，把复杂能力交给代码服务。
   例子：Dify 负责对话和编排，内部 Python 服务负责调用公司专有 API。

结论：大多数企业级项目最终都会走向混合开发，因为纯平台和纯代码都很难兼顾速度与控制力。

2. 在5.2节的 Coze 案例中，我们构建了一个"每日AI简报"智能体。请基于此案例进行扩展思考：

提示：这是一道动手实践题，建议实际操作

当前的简报生成是被动触发的（用户主动询问）。如何改造这个智能体，使其能够每天早上8点自动生成简报并推送到指定的飞书群或微信公众号？
简报的质量高度依赖于提示词设计。请尝试优化5.2.2节中的提示词，使生成的简报更加专业、结构更清晰，或者增加"热点分析"、"趋势预测"等新功能。
Coze 当前不支持 MCP 协议被认为是一个重要局限（在习题的写作过程中，feature-mcp 虽然在 Coze Studio Q4 2025 Product Roadmap 中了，但是还尚未实现）。请简述，什么是 MCP 协议？它为什么重要？如果 Coze 未来支持 MCP，会带来哪些新的可能性？

如何改成每天早上 8 点自动推送

关键思路是把 被动问答 改成 定时触发工作流 。

可行做法：

1. 使用 Coze 的定时任务能力，或通过外部调度器在每天 8 点触发接口。
2. 固定调用“抓取资讯 -> 生成简报 -> 发送消息”的链路。
3. 将输出对接到飞书群机器人、企业微信机器人或微信公众号发布接口。

如果平台本身定时能力不足，可以用 n8n / cron / 云函数 做外部触发层。

如何优化简报提示词

优化目标不应只是写得更长，而应更像编辑部的完整流程。建议增加：

• 固定栏目结构：快讯、重点解读、趋势判断、值得关注公司/产品。
• 输出要求：事实和分析分离，避免把观点写成事实。
• 受众定位：面向管理者、工程师或普通用户时，摘要粒度不同。

例如增加要求：

• 每条新闻必须有一句为什么值得关注。
• 热点分析只允许做中短期趋势判断，不做无依据预测。

MCP 是什么，为什么重要，Coze 未来支持后会带来什么

MCP 本质上是把“外部工具能力、资源”以标准协议暴露给模型或智能体使用。

它重要的原因在于：

• 降低工具接入的重复开发成本。
• 让不同平台和工具提供者有共同接口。
• 让 Agent 从平台内置插件生态扩展到更开放的外部工具生态。

如果 Coze 未来支持 MCP，新的可能性包括：

• 更容易接入企业内部系统。
• 更容易复用别的平台或团队提供的 MCP 工具。
• 平台能力从插件市场进一步走向标准化工具网络。

3. 在5.3节的 Dify 案例中，我们构建了一个功能全面的"超级智能体个人助手"。请深入分析：

案例中使用了"问题分类器"进行智能路由，将不同类型的请求分发到不同的子智能体。这种多智能体架构有什么优势？如果不使用分类器，而是让一个单一的智能体处理所有任务，会遇到什么问题？
数据查询模块需要为大模型提供清晰的表结构信息。如果数据库有50张表、每张表有20个字段，直接将所有 DDL 语句放入提示词会导致上下文过长。请设计一个更智能的方案来解决这个问题。
Dify 支持本地部署和云端部署两种模式。请对比这两种模式在数据安全、成本、性能、维护难度等方面的差异，并说明各自适用的场景。

为什么要用分类器做智能路由

分类器的价值在于先缩小问题空间，再让合适的子智能体处理。

优势：

• 每个子智能体的职责更清晰。
• Prompt 更短，推理更聚焦。
• 可维护性和可调试性更强。

如果只有一个万能智能体，会出现：

• 上下文过长。
• 角色混乱，输出风格不稳定。
• 单个 Prompt 同时背负太多任务，准确率下降。

数据库有 50 张表时如何避免把全部 DDL 塞进 Prompt

推荐做法是元数据检索 + 分阶段生成 SQL：

1. 先维护表和字段的结构化索引。
2. 用户提问后，先检索最相关的 2-5 张表。
3. 只把这些表的 DDL 和示例查询给模型。
4. 必要时再二次检索补充字段说明和外键关系。

本质上是把数据库结构信息做成一个可检索的知识库，而不是一次性塞进上下文。

本地部署和云端部署的差异

维度	本地部署	云端部署
数据安全	更强	依赖服务商
初始成本	更高	更低
维护难度	更高	更低
性能可控性	更强	受云环境约束
上线速度	较慢	更快

适用建议：

• 对敏感数据、合规要求高的企业客户优先本地部署。
• 对验证期产品或资源少的小团队优先云端部署。

4. 在5.4节的 n8n 案例中，我们构建了一个"智能邮件助手"。请思考以下问题：

提示：这是一道动手实践题，建议实际操作

案例中使用的 Simple Vector Store 和 Simple Memory 都是基于内存的，服务重启后数据会丢失。请查阅 n8n 文档，尝试将其替换为持久化存储方案（如 Pinecone、Redis 等），并说明配置过程。
当前的邮件助手只能处理文本邮件。如果用户发送的邮件中包含附件（如 PDF 文档、图片），你会如何扩展这个工作流，使智能体能够理解附件内容并做出相应回复？
n8n 的核心优势在于"连接"能力。请设计一个更复杂的自动化场景：当客户在电商平台下单后，自动触发一系列操作（发送确认邮件、更新库存数据库、通知物流系统、在 CRM 中记录客户信息）。请画出工作流的节点连接图并说明关键配置。

如何替换为持久化存储

核心思路是用外部持久化服务替换内存型存储：

• 向量检索可接 Pinecone、Qdrant、Weaviate 等。
• 对话记忆可接 Redis、数据库或持久化 KV 存储。

配置步骤通常包括：

1. 创建对应服务实例。
2. 在 n8n 中配置 API 密钥和连接参数。
3. 替换当前内存节点为对应存储节点。
4. 验证重启后数据仍可读取。

如何处理 PDF 或图片附件

扩展流程：

1. 邮件到达后检测附件类型。
2. PDF 走文档解析链路，提取文本。
3. 图片走 OCR 或视觉模型识别链路。
4. 将附件内容与邮件正文合并进入后续理解节点。
5. 根据附件内容生成针对性回复。

关键点不是识别附件，而是把附件转为后续可推理的统一文本或结构化表示。

设计一个更复杂的电商自动化场景

订单创建后可自动触发：

1. 发送确认邮件。
2. 更新库存数据库。
3. 通知物流系统创建运单。
4. 在 CRM 中写入客户信息和订单事件。

这是 n8n 的典型强项，因为它本质上是跨系统编排引擎。

##提示词工程在低代码平台中同样至关重要。本章展示了多个平台的提示词设计案例。请分析：

对比5.2.2节（Coze）、5.3.2节（Dify）和5.4.4节（n8n）中的提示词设计，它们在结构、风格和侧重点上有什么不同？这些差异是否与平台特性相关？
在 Dify 的"文案优化模块"中，提示词要求输出"超过500字"。这种对输出长度的硬性要求是否合理？在什么情况下应该限制输出长度，什么情况下应该让模型自由发挥？

三个平台的提示词差异

• Coze 更偏向面向应用交互，提示词通常强调用户体验、输出风格和快速成品。
• Dify 更偏向工作流和模块化，提示词更强调任务边界、路由逻辑和知识注入。
• n8n 更偏向自动化节点，提示词常围绕某个节点的输入输出约束展开。

这些差异本质上和平台形态相关：一个越偏产品化交互，提示词越偏用户前台；越偏工作流，提示词越偏系统中台。

输出长度要不要硬性限制

超过 500 字这类要求只有在业务上真的需要最低信息量时才合理，比如公众号草稿、周报摘要。

不合理的情况：

• 本来一句话就能回答清楚的问题被迫写长。
• 为满足长度目标而灌水，损害信息密度。

更好的办法通常是限制结构和覆盖点，而不是死盯字符数。

6. 工具和插件是低代码平台的核心能力扩展方式。请思考：

Coze 拥有丰富的插件商店，Dify 拥有8000+的插件市场，n8n 拥有数百个预置节点。如果这三个平台都没有你需要的某个特定工具（如"连接公司内部系统的 API"），你会如何解决？
在5.3.2节中，我们使用了 MCP 协议集成了高德地图、饮食推荐等服务。请调研并说明：MCP 协议与传统的 RESTful API 以及 Tool Calling 有哪些区别？为什么说 MCP 是智能体工具调用的"新标准"？
假设你要为 Dify 开发一个自定义插件，使其能够调用你公司的内部知识库系统。请查阅 Dify 的插件开发文档，概述开发流程和关键技术点。

平台没有现成工具时怎么办

常见路线：

1. 封装公司内部 API，做成 HTTP 服务。
2. 若平台支持，开发自定义插件或节点。
3. 如果平台不适配，就把复杂能力放到外部代码服务里，由平台调用。

MCP、RESTful API、Tool Calling 的区别

可以这样理解：

• RESTful API 是通用系统通信格式，不专门为智能体设计。
• Tool Calling 是模型厂商侧给模型用工具的调用机制。
• MCP 更像是面向智能体时代的标准化工具接口层，把工具、资源、提示模板统一描述出来。

所以说 MCP 是新标准，是因为它试图在不同模型、平台、工具提供者之间建立统一契约。

Dify 自定义插件的开发流程概述

关键步骤通常包括：

1. 明确插件能力边界和输入输出 schema。
2. 编写插件后端逻辑。
3. 定义鉴权方式、错误处理和参数校验。
4. 在 Dify 中注册并测试。
5. 为插件写清晰描述，便于路由器或 Agent 正确使用。

7. 平台选型是智能体产品成功的关键决策之一。假设你是一家初创公司的技术负责人，公司计划开发以下三个AI应用，请为每个应用选择最合适的平台（Coze、Dify、n8n 或纯代码开发），并详细说明理由：

应用A：面向C端用户的"AI写作助手"小程序，需要快速上线验证市场需求，预算有限，团队中只有1名前端工程师和1名产品经理。

应用B：面向企业客户的"智能合同审核系统"，需要处理敏感的法律文档，要求数据不能离开客户的私有环境，需要与客户现有的OA系统、文档管理系统深度集成。

应用C：内部使用的"研发效能提升工具"，需要自动化处理代码审查、测试报告生成、Bug跟踪、项目进度同步等多个研发流程环节，团队有较强的技术实力。

对于每个应用，请从以下维度（包括但不限于）进行分析：

提示：平台能力是否满足需求，多快能上线，开发成本、运营成本，后续迭代的难度，未来功能扩展的空间

技术可行性
开发效率
成本控制
可维护性
可扩展性
数据安全与合规性

应用 A：面向 C 端的 AI 写作助手小程序

推荐：Coze 或类似快速搭建平台。

理由：

• 核心目标是快速验证需求。
• 团队人力有限，不适合重基础设施。
• 对私有化和深度流程编排要求不高。

应用 B：企业智能合同审核系统

推荐：Dify + 私有部署 + 外部代码服务，必要时部分纯代码。

理由：

• 需要强数据安全和深度系统集成。
• 需要知识库、审计、工作流和私有化能力。
• 合同审核属于高风险领域，必须保留工程可控性。

应用 C：内部研发效能提升工具

推荐：n8n + 纯代码服务 或更偏代码化的自建方案。

理由：

• 它本质上是多个研发系统的流程自动化和编排问题。
• 团队技术能力强，可以承接更复杂的代码扩展。
• 长期看，需要和 Git、CI、测试平台、缺陷系统深度耦合。

总结：

• 快速验证选 Coze。
• 企业合规应用选 Dify 私有化。
• 重系统连接和内部编排选 n8n 或代码主导方案。