|
|
@@ -991,6 +991,66 @@ Description参数即AI Agent调用该工具时，对该工具的描述定义，
|
|
|
|
|
|
下一章，我们将进一步探讨更加底层的智能体框架，帮助读者构建更加可靠、有趣的应用。
|
|
|
|
|
|
+
|
|
|
+## 习题
|
|
|
+
|
|
|
+1. 本章介绍了三个各具特色的低代码平台：`Coze`、`Dify` 和 `n8n`。请分析：
|
|
|
+
|
|
|
+ - 这三个平台在核心定位和设计理念上有什么区别？它们分别解决了智能体开发中的哪些痛点？
|
|
|
+ - 低代码平台与纯代码开发各有优劣，此外，也有部分功能用平台实现，部分功能用代码实现的"混合开发"模式。思考三种开发模式分别适合哪些场景？请举例说明。
|
|
|
+
|
|
|
+2. 在5.2节的 `Coze` 案例中，我们构建了一个"每日AI简报"智能体。请基于此案例进行扩展思考：
|
|
|
+
|
|
|
+ > <strong>提示</strong>：这是一道动手实践题，建议实际操作
|
|
|
+
|
|
|
+ - 当前的简报生成是被动触发的（用户主动询问）。如何改造这个智能体，使其能够每天早上8点自动生成简报并推送到指定的飞书群或微信公众号？
|
|
|
+ - 简报的质量高度依赖于提示词设计。请尝试优化5.2.2节中的提示词，使生成的简报更加专业、结构更清晰，或者增加"热点分析"、"趋势预测"等新功能。
|
|
|
+ - `Coze` 当前不支持 `MCP` 协议被认为是一个重要局限（在习题的写作过程中，`feature-mcp` 虽然在 [`Coze Studio Q4 2025 Product Roadmap`](https://github.com/coze-dev/coze-studio/issues/2218) 中了，但是还尚未实现）。请简述，什么是 `MCP` 协议？它为什么重要？如果 `Coze` 未来支持 `MCP`，会带来哪些新的可能性？
|
|
|
+
|
|
|
+3. 在5.3节的 `Dify` 案例中，我们构建了一个功能全面的"超级智能体个人助手"。请深入分析：
|
|
|
+
|
|
|
+ - 案例中使用了"问题分类器"进行智能路由，将不同类型的请求分发到不同的子智能体。这种多智能体架构有什么优势？如果不使用分类器，而是让一个单一的智能体处理所有任务，会遇到什么问题？
|
|
|
+ - 数据查询模块需要为大模型提供清晰的表结构信息。如果数据库有50张表、每张表有20个字段，直接将所有 `DDL` 语句放入提示词会导致上下文过长。请设计一个更智能的方案来解决这个问题。
|
|
|
+ - `Dify` 支持本地部署和云端部署两种模式。请对比这两种模式在数据安全、成本、性能、维护难度等方面的差异，并说明各自适用的场景。
|
|
|
+
|
|
|
+4. 在5.4节的 `n8n` 案例中，我们构建了一个"智能邮件助手"。请思考以下问题：
|
|
|
+
|
|
|
+ > <strong>提示</strong>：这是一道动手实践题，建议实际操作
|
|
|
+
|
|
|
+ - 案例中使用的 `Simple Vector Store` 和 `Simple Memory` 都是基于内存的，服务重启后数据会丢失。请查阅 `n8n` 文档，尝试将其替换为持久化存储方案（如 `Pinecone`、`Redis` 等），并说明配置过程。
|
|
|
+ - 当前的邮件助手只能处理文本邮件。如果用户发送的邮件中包含附件（如 `PDF` 文档、图片），你会如何扩展这个工作流，使智能体能够理解附件内容并做出相应回复？
|
|
|
+ - `n8n` 的核心优势在于"连接"能力。请设计一个更复杂的自动化场景：当客户在电商平台下单后，自动触发一系列操作（发送确认邮件、更新库存数据库、通知物流系统、在 `CRM` 中记录客户信息）。请画出工作流的节点连接图并说明关键配置。
|
|
|
+
|
|
|
+5. 提示词工程在低代码平台中同样至关重要。本章展示了多个平台的提示词设计案例。请分析：
|
|
|
+
|
|
|
+ - 对比5.2.2节（`Coze`）、5.3.2节（`Dify`）和5.4.4节（`n8n`）中的提示词设计，它们在结构、风格和侧重点上有什么不同？这些差异是否与平台特性相关？
|
|
|
+ - 在 `Dify` 的"文案优化模块"中，提示词要求输出"超过500字"。这种对输出长度的硬性要求是否合理？在什么情况下应该限制输出长度，什么情况下应该让模型自由发挥？
|
|
|
+
|
|
|
+6. 工具和插件是低代码平台的核心能力扩展方式。请思考：
|
|
|
+
|
|
|
+ - `Coze` 拥有丰富的插件商店，`Dify` 拥有8000+的插件市场，`n8n` 拥有数百个预置节点。如果这三个平台都没有你需要的某个特定工具（如"连接公司内部系统的 `API`"），你会如何解决？
|
|
|
+ - 在5.3.2节中，我们使用了 `MCP` 协议集成了高德地图、饮食推荐等服务。请调研并说明：`MCP` 协议与传统的 `RESTful API` 以及 `Tool Calling` 有哪些区别？为什么说 `MCP` 是智能体工具调用的"新标准"？
|
|
|
+ - 假设你要为 `Dify` 开发一个自定义插件，使其能够调用你公司的内部知识库系统。请查阅 `Dify` 的插件开发文档，概述开发流程和关键技术点。
|
|
|
+
|
|
|
+7. 平台选型是智能体产品成功的关键决策之一。假设你是一家初创公司的技术负责人，公司计划开发以下三个AI应用，请为每个应用选择最合适的平台（`Coze`、`Dify`、`n8n` 或纯代码开发），并详细说明理由：
|
|
|
+
|
|
|
+ <strong>应用A</strong>：面向C端用户的"AI写作助手"小程序，需要快速上线验证市场需求，预算有限，团队中只有1名前端工程师和1名产品经理。
|
|
|
+
|
|
|
+ <strong>应用B</strong>：面向企业客户的"智能合同审核系统"，需要处理敏感的法律文档，要求数据不能离开客户的私有环境，需要与客户现有的OA系统、文档管理系统深度集成。
|
|
|
+
|
|
|
+ <strong>应用C</strong>：内部使用的"研发效能提升工具"，需要自动化处理代码审查、测试报告生成、Bug跟踪、项目进度同步等多个研发流程环节，团队有较强的技术实力。
|
|
|
+
|
|
|
+ 对于每个应用，请从以下维度（包括但不限于）进行分析：
|
|
|
+
|
|
|
+ > <strong>提示</strong>：平台能力是否满足需求，多快能上线，开发成本、运营成本，后续迭代的难度，未来功能扩展的空间
|
|
|
+
|
|
|
+ - 技术可行性
|
|
|
+ - 开发效率
|
|
|
+ - 成本控制
|
|
|
+ - 可维护性
|
|
|
+ - 可扩展性
|
|
|
+ - 数据安全与合规性
|
|
|
+
|
|
|
## 参考文献
|
|
|
|
|
|
[1] Coze - 新一代 AI 应用开发平台. https://www.coze.cn/
|
Tsumugii24