AI智能体开发实战：用扣子平台从零搭建企业级应用

去年我开始认真做AI智能体方向的东西，前前后后用本地代码写了几个原型，能跑，但离“能用、敢上线”还有很大距离。后来接触了扣子这个AI智能体开发平台，很多长期让我头疼的事算是找到了解法。这篇文章不聊概念，就讲讲扣子这个平台给我的实际感受、我摸索出来的搭建流程、真实项目中踩过的坑，以及几个我自己觉得值得注意的判断。内容主要面向产品经理、运营、学生，以及想快速验证AI应用想法的开发者——你不一定要会写代码，但一定得有想解决的问题。

1. 扣子到底解决了什么问题：从“写代码做AI应用”到“设计AI智能体”

1.1 自己搭AI应用的六件麻烦事

先说我的真实经历。早先做一个问答机器人，光是把大模型接口调通就花了不少时间：申请API Key、选择模型、调温度参数、处理流式输出，每一步都是体力活。接口调通之后，更麻烦的是会话管理——多轮对话里，用户上一句问的问题，下一句可能会说“那再详细讲讲”，你得把历史上下文拼接好再发给模型，稍不注意就串台。

第三件麻烦事是工具调用。用户问“今天天气怎么样”的时候，模型本身并不知道天气数据，你得让它先识别出这是一个查询天气的意图，再决定调用哪个接口。这种“函数调用”的逻辑虽然现在很多模型原生支持，但自己写一遍还是要处理参数解析、接口错误、超时重试。第四件是部署，一个小应用而已，但你要考虑域名、服务器并发、安全策略。第五件是写前端聊天页面，如果做得丑，用户根本不愿意用。第六件是运维，日志、监控、修Bug。

这些事情单拎出来都不难，但全部堆在一起就很消磨耐心。我一开始也觉得“做一个AI应用嘛，核心是把模型用起来”，真正做完才发现，模型只是其中很小一部分，80%的时间都花在了工程和细节上。扣子解决的核心问题，就是把那80%的重复劳动接走。

1.2 扣子的核心能力：把复杂留给自己，把简单交给用户

第一次打开扣子的时候，最大的感觉是“该有的东西都已经有了”。聊天窗口、模型配置、插件市场、知识库、工作流编排，这些工具都被整合在一个在线编辑器里。创建一个智能体，不需要本地写代码，直接在网页上配置就行。模型调用被封装了，会话管理被封装了，甚至连发布渠道都帮你接好了，你只需要把精力放在“这个智能体到底要怎么说话、怎么办事”上。

但要说清楚的是，扣子不是一个简单的对话机器人玩具。它真正厉害的地方，是让非工程师也能接触到AI应用的工程化思维。比如知识库，你上传几篇文档，平台会自动切片、做向量化、配置检索，用户提问时就能召回相关内容。以前这件事要自己搭向量数据库、写Embedding流程，现在几分钟就能搞定。再比如工作流，你可以在可视化画布上拖拽节点，把“接用户输入、查知识库、调用模型生成回复、再判断是否需要人工介入”这些步骤串成一条流水线。

这套东西解决的不只是效率问题，更重要的是降低了实验成本。过去你想试一个想法，至少要写两三天代码才敢说“验证一下”；现在你花一个下午搭个原型，放到真实用户面前测试，数据会告诉你这个方向对不对。就算方向错了，损失也很小。

1.3 到底适合谁来用

我觉得四类人最适合用扣子：

• 运营同学：活动答疑机器人、私域客服入口、用户常见问题自动回复，这些场景对精度要求不算高，但胜在需求明确、更新频繁，用扣子搭最快。
• 产品经理：需要快速验证一个AI功能有没有价值。比如你想知道“用户会不会接受一个AI选品助手”，与其写PRD让研发排期，不如自己先搭一个Demo扔到用户群里试。
• 学生和AI爱好者：扣子把复杂的技术细节藏了起来，让你能专注学习“提示词设计”“知识库结构”“流程编排”这些真正上层的东西，门槛比直接啃框架低很多。
• 程序员：别觉得可视化平台是给小白用的就轻视它。内部知识库问答、工单自动分类、运维告警摘要，这些内部工具用扣子搭，比从零开发快得多。

当然，扣子不适合所有场景。如果你的应用需要完全自定义的前端界面、需要极致的推理控制、需要接入私有化部署的模型，那还是得写代码。但那是少数情况，对大多数团队来说，先用扣子跑起来，比什么都重要。

2. 第一次用扣子搭建智能体：我建议你这样走完整流程

2.1 先不要动手做，先做需求拆解

我第一次用扣子的时候犯过一个错：打开编辑器就开始配置，结果搭出来的智能体就像一个没有方向的万事通，问什么都能答，但答什么都不够好。后来我总结出一个经验，搭建智能体之前，必须先做需求拆解。

拆解的时候问自己三个问题。第一个，这个智能体给谁用？如果是给内部同事用，语气可以轻松一点；如果是给外部客户用，就要注意礼貌和专业度。第二个，它要解决什么问题，边界在哪里？比如一个活动客服智能体，只需要回答活动时间、参与方式、奖品设置、发货时间这些问题，跟活动无关的内容，它完全可以直接说“这个问题我无法回答，请转人工”。第三个，怎么算“答得好”？是回复速度快，还是准确率高，还是语气亲切？不同目标决定了你要花多少精力在提示词上，要配置哪些知识内容。

我见过某运营同学做一个活动答疑智能体，一开始只给了智能体一句“你是一个活动助手”，结果用户问“你们公司主营业务是什么”它也能长篇大论编一套。后来把边界写到提示词里，加上“只回答跟本次周年庆活动相关的问题”，效果立刻好了很多。这就是需求拆解的价值——它帮你看清楚，智能体不需要全能，只需要在某个明确范围内做到优秀。

2.2 创建智能体：名称、描述、人设提示词

需求拆解完之后就可以动手了。登录扣子平台后，点击“创建智能体”，第一个要填的是名称和功能描述。这里很多人会随手填，但我建议认真想想。名称决定了用户的第一印象，功能描述则会作为智能体的基础设定写入系统提示词，直接影响后续所有回复。名称最好体现用途，比如“活动小助手”比“小扣”更明确；功能描述要写清楚它是谁、为谁服务、能做什么。

接下来是核心步骤：写人设提示词。我习惯的模板是四段式：角色、背景、任务、限制。角色解决“你是谁”的问题，比如“你是一个活动客服智能体，服务于某公司周年庆活动”。背景是给模型提供上下文，比如“活动时间、奖品规则、常见问题”。任务是定义它的行为，比如“回答用户关于活动的提问，语气热情但不啰嗦，每句话不超过80字”。限制是设定边界，比如“只能根据知识库内容回答，知识库没有的内容要引导用户转人工，不要编造答案”。

这个模板看起来简单，但实际写好需要反复打磨。我的建议是，第一版先写一个大概，然后在测试对话里发现问题，再逐句修改。提示词不是一次成型的，它更像是你在给一个新人做入职培训，讲清楚规则之后，还要让他在真实场景里多碰几次壁才能理解。

2.3 选择模型、添加插件和知识库

提示词写完，接下来要配置模型的“大脑”。扣子里可以选择不同的模型，这一步不是越贵越好，而是看你的场景。如果智能体要做复杂的推理、要处理长文本、要精准理解用户的潜台词，那就选推理能力更强的模型；如果只是做简单的FAQ问答，追求响应速度，那选一个轻量、便宜的模型就够了。同一个智能体里不同的节点也可以使用不同模型，工作流里我会单独说。

然后是插件。插件是给智能体开的“外部能力接口”。最常见的几类：网页搜索插件，让智能体能查到实时信息；图片生成插件，让它能画图；还有天气、计算、新闻等垂直能力插件。添加插件的原则是“按需添加”，你让智能体做客服，就不需要给它接图片生成插件，插件越多，模型在识别该用哪个的时候就越容易出错。

知识库是重头戏。你要把智能体需要的背景资料上传进去，比如活动规则文档、产品说明书、常见问题清单。上传之后，平台会自动做文本切片和向量化，用户提问的时候，系统会从知识库里检索相关内容，再让模型基于这些内容生成回答。这一步极大地减少了模型胡说八道的情况。但知识库不是把文档丢进去就完事，文件格式、切片大小、检索方式都会影响效果，这个我放在第四章详细讲。

2.4 预览测试：用真实问题轰炸你的智能体

配置完毕，先别急着发布，先在预览窗口里做一轮测试。测试的关键不是问几个常规问题就算完，而是要把你能想到的边界情况都问一遍。比如，用户闲聊和业务无关的问题，它会不会跑偏？用户用很长的句子提问，它能不能抓住核心？用户重复问同一个问题，它会不会不耐烦？用户输入了错别字，它能不能理解？

我自己测的时候，一定会准备一份“刁钻问题清单”，里面包括：知识库里有明确答案的问题、知识库里没有但很相似的问题、完全无关的问题、带情绪的问题。通过这批问题，你很快就能看到智能体的性格和边界是否清晰。如果在测试阶段就发现了答非所问，不要急着调模型，大概率是提示词没写清楚或者知识库没配到位。每改一次提示词，就把整个清单重跑一遍，确认没有改坏别的地方。这一步非常枯燥，但非常有必要。

3. 工作流编排：让智能体从“话痨”变成“办事员”

3.1 为什么只用提示词不够

如果你只想做一个聊天机器人，那提示词加知识库就够了。但真实场景里，很多需求根本不是“聊天”能解决的。举一个例子，一个工单分类智能体，需要把用户的反馈自动分成“咨询”“故障”“建议”三类，然后走不同的处理逻辑：故障要生成紧急工单，建议要走产品评审流程，咨询要直接回复答案。这种带明确分支和操作的动作，你如果只靠提示词让模型去判断，它的输出格式时好时坏，没法稳定接到后续系统里。

这时候就需要工作流。工作流的本质是把智能体的行为从“自由发挥”变成“流程编排”。你在画布上定义每一步要做什么，节点之间怎么流转，哪些地方用大模型，哪些地方用代码，哪些地方走固定逻辑。大模型只负责它擅长的那部分，比如理解用户意图、生成自然语言回复；而查询、判断、数据变换，交给专门的节点来完成。

我个人的理解是：提示词决定了智能体“怎么说”，工作流决定了它“怎么做”。两者结合，才能让智能体变成真正能办事的执行者，而不是嘴皮子很溜的聊天机器。

3.2 常见节点类型和使用场景

扣子的工作流画布上有几种常见节点，各有各的用途。我把它们的“使用场景”和“我的理解”整理一下：

这里的核心思路是：能“写死”的逻辑，不要交给大模型。比如判断一个工单是不是“紧急”，你可以写一个规则，包含“系统崩溃”“无法登录”这些关键词；也可以让模型去理解。规则的好处是稳定、快、不花额外费用，模型的优势是泛化能力强，能理解“我网页打不开”也是登录问题。实际项目里我通常会混合用：先用模型做语义理解，再用规则做硬性过滤和分流。

3.3 一个具体例子：工单自动分类工作流

我搭过的一个典型工作流，解决的是“工单自动分类”问题。用户提交一段问题文本，工作流要判断它属于“咨询”“故障”还是“建议”，并输出对应的处理建议。

流程是这样的：第一步，用户问题从“开始节点”进入，作为输入参数。第二步，接到“大模型节点”，让模型判断类型，同时要求它输出一个JSON格式的结果，里面包含“分类”和“简要原因”。为什么要让模型输出JSON？因为后续节点需要结构化数据，才不会在解析时出问题。第三步，走到“条件判断节点”，如果分类是“故障”，走紧急处理分支；如果分类是“咨询”，走到知识库检索节点，查找常见问题答案；如果是“建议”，则走记录节点，把内容整理后存入指定表格。最后所有分支汇入“结束节点”，把结果返回。

这个流程看起来简单，但实际上解决了几个单靠提示词很难保证的事：第一，输入输出格式稳定，因为代码节点会做严格解析；第二，分支逻辑可控，紧急工单不会被模型临时起意给漏掉；第三，每一个节点都能单独测试，哪个环节出了问题，一眼就能定位。这也是我强烈推荐“用工作流处理业务逻辑”的原因——它把AI应用从黑盒变成了白盒。

3.4 工作流的调试技巧

搭工作流最忌讳一口气全搭完再去测。我的习惯是：先跑通一条主链路，再加分支。比如上面那个工单分类，我先不管“建议”分支，只接“咨询”和“故障”，跑通了再补第三个分支。每加一个节点，就点一次运行，看中间输出是否符合预期。工作流画布上每个节点都能看到输入和输出，这一步是最有价值的调试方式。

还有一个小技巧：在用真实知识库之前，先用固定的测试文本作为输入。比如知识库检索节点，你可以直接给一段已知答案的文本，看看它能不能检索到正确的片段。如果这一步都过不了，那不是工作流的问题，是知识库本身没配好。总之，把“模型生成”和“流程逻辑”分开调试，会省下很多时间。

4. 实测过程中踩过的坑：提示词、知识库与模型选择的教训

4.1 提示词写太宽，智能体答非所问

我第一次搭智能体时，人设提示词写得非常宽松：“你是一个AI助手，为用户提供帮助。”结果就是它什么都能聊，什么都聊不深，知识库里的准确内容它反而不用。后来我意识到，模型是会“顺着提示词走”的——你说它是个全能助手，它就真把自己当全能选手，什么信息都敢编。

解决方法是把提示词写窄。不要只给一个身份，要给它明确的指令范围和回复格式要求。我会加一句“如果用户的问题不在你的知识库范围内，请回复‘这个问题我暂时无法回答，建议转人工处理’，不要猜测答案”。这句话看起来简单，效果立竿见影。另外，我还会在提示词里加一两个示例，教模型“标准回答长什么样”。模型对具体例子的理解能力，比对抽象规则的理解能力要强得多。

4.2 知识库召回效果差，明明有答案却答不出来

知识库最常见的问题是：资料里明明有答案，但用户问题换了一种问法，智能体就搜不到。这里要理解一下检索原理：文档上传后会切片成段落，再转成向量，用户提问时系统会把问题向量化和切片向量做相似度匹配。如果你上传的文档是整页整页的PDF，切片可能把一个段落切碎了；或者你的检索策略只用了向量检索，而用户的问法和文档里的原句差异太大，那确实召不回来。

我的处理办法有三步。第一，上传前先把文档整理干净，去掉页眉页脚、去掉无关图表，让每个文档围绕一个主题。第二，调整切片大小，文档内容越结构化，切片可以越小；内容越松散，切片要适当大一些，保证语义完整。第三，设置检索策略时，如果文档里有明确术语，可以用“全文检索+向量检索”混合模式，命中率会明显提升。测试的时候，多换几种问法去搜同一个答案，比如“活动什么时候开始”“开始时间是几点”“周年庆从哪一天算起”，看看知识库能不能稳定召回。

4.3 模型幻觉与知识库内容冲突

刚才提到模型会编造，这个问题的严重程度比大家想象的高。有一次我搭一个产品说明书智能体，知识库里没有任何关于“售后保修期”的内容，用户问“保修期是多长”，模型居然回答“保修期一年”。原因很典型：大模型脑子里有一些“通用常识”，它觉得很多产品保修期就是一年，于是就拿常识来填空了。可实际上，那个产品的保修期是三年，根本没有写进知识库。

要解决这个问题，除了在提示词里强约束“必须依据知识库回答”之外，还可以在工作流里加一道“判断节点”：知识库检索结束后，如果检索结果为空或者相似度很低，就不要让模型自由发挥，而是走兜底话术：“这个问题我还没找到准确答案，让我记录一下，稍后回复您。”这比让模型硬答要好得多。记住，AI智能体不是用来展示模型有多聪明的，它存在的价值是把正确的信息稳定传递给用户。

4.4 工作流调试慢，学会拆开定位问题

有段时间我觉得工作流调试太慢，改一个节点要等整个流程跑完才知道结果。后来发现是我自己的方法错了。工作流应该像调试代码一样“局部优先”。我现在的习惯是：开始节点固定传入一段测试数据，然后单独点击某个节点看它的输入输出。如果知识库节点返回结果不理想，就直接复制它的检索条件去知识库后台测，不要反复跑整个流程，那样既慢又难定位。

还有一个排查方向：节点之间的参数传递。大模型节点输出的是文本，但条件判断节点可能要求字符串或数字，这里经常出现“看起来有结果，但分支没走对”的情况。所以每连一条线，都要检查上游节点的输出格式是否和下游节点的输入要求一致。大多数工作流跑不通，不是模型不行，而是节点之间的数据格式没对上。

4.5 模型选型不是越大越聪明

很多人习惯性选“最强模型”来做所有事情，费用高、速度慢，还不一定需要那么强的推理。我自己的建议是：在同一个工作流里可以混合用模型。比如意图识别这种简单任务，用轻量模型就够了，速度快成本低；生成最终回复、需要组织语言的时候，再用更强的模型。扣子里不同节点可以选择不同模型，这个特性非常实用。

举个例子，工单分类工作流的“分类节点”，我用轻量模型就能做出准确率很高的分类；而“回复生成节点”，我会用更强一点的模型，因为用户会直接看到这段文字，措辞和态度很重要。这样一招下来，整体成本能省不少，体验还更好。

5. 发布后的运营思路：智能体不是做完就结束了

5.1 发布渠道的取舍

智能体做完之后要发布到用户能接触到的地方。扣子的发布渠道比较丰富，我这里只说选型思路，不局限于某个具体平台。如果你只是内部验证，发布成网页版分享链接就够了，方便、快；如果你的智能体要做群聊里的自动回复，那就接入IM机器人，用户在日常聊天工具里就能直接使用，不需要跳到新的页面；如果是面向C端用户的小型应用，可以考虑发布到小程序或者标准API接口，让外部系统接入调用。

我的建议是：发布渠道不要贪多，先选定一个用户密度最高的渠道。某运营同学的活动助手，首发就只做了群聊机器人，因为活动参与者本来就在粉丝群里，把智能体放到群里，用户触达零门槛。反观另一个项目组，一开始就把智能体发布到网页、小程序等好几个渠道，结果每个渠道的数据都很散，后期迭代都没法聚焦。

5.2 数据指标怎么看

发布之后，最怕的就是“发布了就不管了”。我看到很多人做AI智能体的流程是：搭好、发布、截图发朋友圈，然后就没有然后了。如果你打算认真做这件事，至少要盯着几个数据指标。第一个是对话总量和用户量，看有没有人真的在用。第二个是意图命中率，也就是用户的问题，智能体能不能正确理解并归类。第三个是知识库命中率，反映资料覆盖率够不够，很多回答不出来或者答得不对的问题，根源是知识库里没有对应内容。第四个是人工转接率，如果这个比例一直很高，说明智能体的解决能力还不够。

这些数据在后台都能看到日志。我自己的做法是，每周花一个小时翻最近一周的未解决问题，把高频问题整理出来，补充进知识库。这就是一个持续优化的循环：发现问题、补充知识、测试验证、发布更新。很多智能体上线一个月之后“变聪明了”，核心不是模型升级了，往往是运营的人把知识库喂得更饱了。

5.3 持续迭代的实操清单

最后分享一份我日常迭代智能体时固定会做的清单：

• 每周导出对话日志，筛选“用户追问超过两轮”的记录，这些都是卡点信号。
• 把知识库更新纳入流程，产品规则变了，第一时间更新文档，再重新上传到知识库。
• 提示词微调时记录版本，每次改完都跑一遍回归测试清单，防止把老问题改回来。
• 给智能体增加“人工兜底”入口，自动回复解决不了时，明确告诉用户如何找到真人，这比一直硬撑要体面得多。
• 观察用户反馈里的“情绪词”，如果频繁出现“听不懂”“不是这个意思”，说明语义理解需要加强，优先检查检索策略和模型选择。

有一次我就是靠着看日志发现，大量用户会问“在哪里看物流”，但知识库里的原文档只写了“物流信息查询方式”，表达不一致导致检索一直没命中。后来我把这段文档重写了一遍，覆盖了“在哪看物流”“查快递”“订单到哪了”等常见说法，问题率立刻降了一大截。这种“从用户实际问法反推知识库内容”的思路，比凭空想象用户会问什么要靠谱得多。

我个人做了快一年智能体之后最大的体会是：扣子不会替你想清楚产品逻辑，它只是把繁琐的工程化步骤替你打理好，让你把精力放回“用户到底需要什么”这件事上。一个智能体的天花板，通常不取决于它用了多强的模型，而取决于你对自己业务场景的理解有多深。如果你还没动手试过，我的建议是别贪多，先拿一个小场景走通全流程，哪怕只是给一个小团队内部用。跑完一遍，你对“AI智能体到底是什么、能做什么、上限在哪里”的理解，会比只看教程深刻得多。