基于扣子平台从零构建购物决策智能体：从意图识别到工作流编排

1. 先搞清楚“买个der啊”这类智能体到底能干什么

如果你在找“扣子”或者“智能体”相关的教程，大概率是想自己动手做一个能帮你处理具体事务的AI助手。比如，这个标题里的“买个der啊”，听起来像是一个帮你做购物决策或者比价的工具。但别急着去研究代码，第一步得先弄明白，用“扣子”这类平台开发智能体，和你自己写代码、调用API到底有什么区别。

简单说，像“扣子”这样的智能体开发平台，核心价值是降低门槛和提高效率。它把AI能力（比如大语言模型的理解和生成）、外部工具（比如搜索、数据库查询）和逻辑流程（比如判断、循环）打包成了可视化的“积木”。你不用从零开始处理API密钥、管理对话状态、设计复杂的提示词工程，而是通过拖拽和配置，就能组合出一个能跑起来的AI应用。

所以，“买个der啊”这个想法，在扣子上实现，你可能需要关注这几个模块：

1. 用户意图识别：用户说“我想买手机”和“2000块以内哪个手机最划算”，需要触发不同的流程。
2. 信息获取：是连接电商平台的API实时比价，还是基于一个内置的商品知识库给出建议？
3. 决策与输出：是直接推荐一款，还是列出Top 3并说明理由？输出格式是纯文本，还是带链接、图片的富媒体卡片？

这决定了你开发的不是一个“聊天机器人”，而是一个有明确任务边界、能执行特定工作流的智能体。对于开发者或者业务人员，最值得关注的不是它“能用AI聊天”，而是它能否稳定、准确地完成你设定的那个“闭环任务”。

2. 上手前必须弄清的运行环境与核心概念

在扣子这类平台上开发，本地环境压力小，但“环境”变成了对平台能力、账号权限和资源限制的理解。动手之前，建议先厘清下面几点，这能避免你做到一半发现根本路不通。

2.1 平台账号与资源限制

几乎所有这类平台都有免费额度，但限制各不相同。你需要重点关注：

• 调用次数/Token限制：免费版通常每月有额度，超出后需要付费或无法使用。开发测试时就要有意识估算单次对话的消耗。
• 工作流复杂度：平台可能限制单个工作流的节点数量、分支深度或执行时长。复杂的“买个der啊”智能体，如果包含多轮比价、历史查询，可能会触顶。
• 外部连接能力：你的智能体是否需要访问外部API（比如获取实时价格）？免费版可能不允许或限制此类连接。这就是一个关键的“环境”瓶颈。
• 发布与共享：你做好的智能体是仅自己可用，还是能发布给特定人，或公开到市场？这关系到你的开发目标。

2.2 智能体的核心构成模块

理解平台的“积木”是什么，比直接上手拖拽更重要。通常包含：

注意：不要一开始就追求大而全。先从“基于固定知识库的推荐”做起，验证核心流程跑通，再考虑接入动态API，这样排查问题更简单。

2.3 数据与隐私考量

这是开发智能体，尤其是涉及用户输入和外部数据时，必须提前想清楚的“环境”问题。

• 用户输入：平台是否会记录用于模型训练？你的智能体是否会处理敏感信息（虽然“买什么”通常不敏感）？
• 知识库数据：你上传的文档内容是否涉及版权或机密？
• API密钥：如果需要连接外部服务，你的API密钥是保存在平台（通常加密），还是需要用户自己提供？前者方便但你有管理责任，后者安全但用户体验复杂。

对于“买个der啊”这种工具类智能体，通常问题不大，但养成这个意识很重要。

3. 从零搭建“买个der啊”智能体的实操步骤

现在我们假设一个简化场景：开发一个基于固定知识库的手机推荐智能体。它不联网，只根据你提供的知识来回答。

3.1 第一步：定义清晰的能力边界与对话流程

在打开平台之前，先用文字或流程图厘清逻辑。这是避免开发过程混乱的关键。

1. 用户触发：用户可能问“推荐手机”、“5000元手机怎么选”、“我要玩《原神》”。
2. 意图识别：智能体需要识别用户的核心需求：预算和主要用途（游戏、拍照、续航、综合）。
3. 信息查询：根据识别出的参数，去知识库中查找匹配的手机型号和理由。
4. 组织回复：格式化输出，例如：“根据你的需求（预算XX，主要XX），推荐以下几款：1. 型号A，理由... 2. 型号B，理由...”。
5. 结束或追问：询问用户是否还需要其他方面的比较。

把这个流程写在纸上，它就是后续搭建工作流的蓝图。

3.2 第二步：准备与上传知识库

知识库的质量直接决定智能体的效果。不要直接扔一个杂乱无章的网页内容进去。

1. 整理数据：创建一个结构清晰的文档。例如，用Markdown或纯文本，每款手机占一段，包含固定字段：

   ## 红米 Note 13 Pro+ - 价格区间：2000-2500元 - 主要优势：拍照（2亿像素主摄）、屏幕（1.5K曲面屏）、续航（5000mAh+120W快充） - 适合人群：注重拍照和屏幕体验，对性能要求不是极致的用户。 - 不适合：重度大型游戏玩家。 ## 一加 Ace 3 - 价格区间：2500-3000元 - 主要优势：性能（骁龙8 Gen 2）、质感（金属中框）、续航（5500mAh） - 适合人群：追求综合性能、质感和续航的性价比用户。 - 不适合：对超长焦镜头有刚需的用户。

2. 上传与分段：在平台的知识库模块上传文档。关注“分段策略”。太长的段落可能影响检索精度，太短可能丢失上下文。通常选择按“标题”或“自然段”分割即可。上传后，平台会将其向量化存储。
3. 测试检索：在知识库界面，尝试用“2500元 游戏 手机”这样的关键词搜索，看返回的片段是否准确。这是验证知识库处理效果的第一步。

3.3 第三步：在工作流中编排核心逻辑

这是最核心的一步。我们按照3.1的蓝图来搭建。

1. 开始节点：接收用户问题。
2. LLM节点（意图解析）：连接大模型，编写提示词（System Prompt），让它从用户问题中提取结构化信息。
   • 提示词示例：

     你是一个手机需求分析助手。请从用户的提问中提取以下信息： 1. 预算范围（例如：2000元以内、3000-4000元、不限预算等）。如果用户未明确提及，输出“未提及”。 2. 主要用途（例如：玩游戏、拍照、长续航、日常使用、商务办公等）。如果用户未明确提及，输出“未提及”。 请将结果以纯JSON格式输出，格式如下： {"budget": "提取的预算信息", "usage": "提取的用途信息"}

3. 知识库节点：将上一步LLM解析出的usage（用途）字段作为查询词，去知识库中搜索相关手机信息。例如，用户说“玩游戏”，就搜索包含“游戏”、“性能”、“GPU”等关键词的片段。
   • 关键配置：设置“返回条数”（如3-5条），以及“引用模式”（是否在最终回复里注明来源）。
4. 判断节点：检查budget（预算）字段。如果是“未提及”，则可能走一个分支，让LLM直接总结知识库返回的结果；如果有具体预算，则需要进入下一步的“过滤”逻辑。
5. 代码节点或LLM节点（过滤与排序）：这是难点。平台可能没有直接的“数据过滤”节点。你需要：
   • 方案A（利用LLM）：将知识库返回的所有文本和用户的预算信息，一起交给另一个LLM节点，提示它：“请从以下手机信息中，筛选出符合[用户预算]范围的型号，并整理成推荐列表。”
   • 方案B（如有变量处理能力）：如果平台支持变量和简单逻辑，可以尝试用代码节点（如果提供）进行字符串匹配和过滤。但通常方案A更通用。
6. LLM节点（生成最终回复）：将过滤后的结果，交给最后一个LLM节点，让它生成一段友好、清晰的推荐语。
   • 提示词示例：

     你是一个专业的手机推荐助手。请根据以下筛选出的手机信息，为用户生成一份推荐回复。 用户需求：预算[budget]，主要用途[usage]。 手机信息：[此处接入上一步过滤后的知识库内容] 请以清晰、有条理的方式列出推荐型号，并简要说明每个型号为何匹配用户需求。语气亲切自然。

7. 结束节点：输出最终回复。

实测建议：不要一次性搭建完整工作流。先搭到第3步（知识库检索），测试能否正确返回内容。然后再加第4、5步的预算判断和过滤。分阶段测试，问题定位更快。

3.4 第四步：配置角色与调试

1. 角色设定：在智能体的基础设置中，填写名称（买个der啊）、描述和开场白。开场白很重要，它能引导用户提供有效信息。例如：“你好，我是你的购物小帮手‘买个der啊’。请告诉我你的预算和想用手机主要做什么（比如打游戏、拍照、刷剧），我来帮你挑挑看~”
2. 调试：使用平台的“预览”或“调试”功能。
   • 输入：“2000块左右，主要想拍照好一点。”
   • 观察：逐步查看每个节点的输入输出。意图解析节点是否输出了正确的JSON？知识库节点返回了哪些片段？过滤逻辑是否生效？最终回复是否合理？
   • 调整：如果结果不对，回头检查提示词是否清晰、知识库分割是否合理、查询词是否准确。

4. 让智能体更“智能”的关键技巧与避坑点

一个能跑起来的智能体和一个好用的智能体之间，差的就是这些细节。

4.1 提示词工程：别让模型“猜”

很多新手把用户原话直接丢给知识库，效果很差。因为知识库检索是基于语义相似度，用户说“打游戏不卡”，而你的知识库写的是“高性能GPU”、“帧率稳定”，两者可能匹配不上。

• 技巧：用第一个LLM节点做“查询词改写”。提示词可以是：“请将用户的手机需求，改写成3-5个可能出现在手机评测文档中的关键词，用逗号分隔。例如：‘打游戏不卡’ -> ‘游戏性能， GPU， 帧率， 散热’。” 然后将这个改写后的关键词串，送给知识库节点。这样召回率会高很多。

4.2 处理“未提及”和“不知道”

用户不会总是按你的剧本来。

• 预算未提及：在工作流中判断，如果budget是“未提及”，可以引导LLM在最终回复中加上一句：“另外，如果你能告诉我大致的预算范围，我可以给你更精准的推荐哦。”
• 知识库没有答案：在知识库节点后判断，如果返回的文本片段为空或相关性极低，可以走一个分支，让智能体诚实回答：“抱歉，我目前的知识库还没有覆盖到这类需求，我会持续学习的！” 而不是强行编造一个答案。

4.3 工作流的可维护性

• 使用变量：将“预算”、“用途”等提取出的信息存入变量，在各个节点间传递，而不是写死在提示词里。
• 命名清晰：给每个工作流节点起一个一看就懂的名字，如“01_解析用户意图”、“02_查询知识库”、“03_判断预算范围”，三个月后你还能看懂。
• 版本管理：如果平台支持，在重大修改前保存一个版本。复杂的流程改乱了，可以快速回退。

4.4 性能与成本意识

• 减少不必要的LLM调用：在上述流程中，我们用了至少2次LLM调用（解析意图、生成回复），甚至3次（如果过滤也用LLM）。每次调用都消耗Token和算力。思考是否必须？例如，简单的预算判断（是否包含“元”、“块”等字）或许可以用更简单的规则节点（如果平台提供）先处理一层。
• 知识库优化：知识库文档不是越大越好。无关信息多，会增加检索噪声和成本。确保上传的内容精炼、相关。

5. 从Demo到可用：进阶思路与排查清单

当你的基础版“买个der啊”能跑通后，可以考虑这些进阶方向，这也是智能体开发从玩具到工具的关键。

5.1 接入实时数据（API调用）

让智能体从“查阅手册”变成“查询系统”。这需要用到平台的“插件”或“API连接器”功能。

1. 找到数据源：可以是公司内部的价格查询接口，也可以是公开的（需确认合规性）。这里强调，必须使用合法合规的公开数据接口。
2. 配置连接器：在平台中配置该API的请求地址、方法、Headers和参数。通常需要将用户输入的参数（如手机型号）映射到API的查询参数上。
3. 解析返回结果：API返回的通常是JSON或XML，需要用一个LLM节点或代码节点来解析，提取出价格、库存等信息，再组织成回复。
4. 错误处理：在工作流中增加对API调用超时、返回错误码的判断分支，给用户友好的提示，而不是一串代码报错。

5.2 实现多轮对话与记忆

当前的智能体是“单次问答”。真正的对话需要记忆上下文。

• 平台能力：查看平台是否支持“会话记忆”或“长期记忆”功能。通常可以设置记忆保留的轮数或方式。
• 手动实现思路：在工作流开始时，读取历史对话（如果平台提供访问接口），将最重要的信息（如已确定的预算、用途）作为变量或上下文，注入到本次的提示词中。这比完全依赖平台的记忆黑盒更可控。

5.3 发布与集成

• 发布为公开Bot：在平台内发布，获得一个可分享的链接或二维码。
• 集成到第三方：查看平台是否提供API或Webhook。这样你可以把你开发的智能体能力，嵌入到你自己的网站、应用或聊天工具（如企业微信、钉钉）中。这才是智能体价值最大化的方式。

5.4 遇到问题时的排查顺序

当你测试智能体，发现它答非所问、报错或无响应时，按这个顺序查：

1. 看输入：用户的问题是否太模糊或超出了你设定的边界？用一句非常清晰的话测试，比如“请推荐3000元左右的拍照手机”。
2. 看工作流执行日志：这是最重要的调试工具。平台一般会记录每个节点的输入输出。逐步检查：
   • 意图解析节点：输出的JSON格式对吗？budget和usage字段提取对了吗？
   • 知识库节点：查询词是什么？返回了几条内容？这些内容相关吗？
   • LLM生成节点：它收到的上下文信息完整吗？是否包含了过滤后的结果？
3. 看知识库：用测试的查询词，直接去知识库管理界面搜索，看结果是否理想。如果不理想，考虑优化文档内容或调整分段/检索策略。
4. 看提示词：你的提示词指令是否清晰无歧义？是否要求了明确的输出格式？用简单的英文或更直接的指令试试。
5. 看平台状态：是否是平台服务暂时不稳定？免费额度是否用尽？

开发这类智能体的过程，更像是在训练一个“数字员工”。你需要清晰地定义它的职责（工作流），给它提供培训材料（知识库），并教会它如何与人沟通（提示词）。一开始不用追求完美，从一个极小但能闭环的流程开始，跑通它，然后像调试程序一样，根据“员工”的实际表现，一步步优化它的每一个工作环节。