企业官网建设流程全解析

前阵子带完一个西南实践环境下的智能体项目，项目名就叫“智能体来了：在西南实践环境中学习扣子应用的智能体项目”。从立项到上线跑了差不多两个月，中间踩了不少坑，也攒了不少实打实的经验。这篇就当是给自己留个复盘，也希望能给正在做类似智能体项目的朋友一些参考。

先说背景。项目是某西南高校的信息中心发起的一个校企合作试点，目标是借助扣子（Coze）这类可视化智能体开发平台，把本地文旅场景里的咨询、推荐、投诉分流这些琐碎又重复的服务需求接住。我们当时做的就是多场景的智能体助手，核心诉求是：不用用户下载App、不用排队等人工、随时随地能用自然语言问问题、系统还能自动整理工单。听着不难，真正做起来才发现，智能体的边界、知识库的整理、工作流的编排、模型幻觉的控制，每一环都是磨出来的。

这篇文章不打算写成一个开发文档，更像是一个项目全过程的复盘。从智能体概念怎么理解，到为什么选扣子，再到工作流搭建、知识库清洗、模型调优、上线发布、问题排查，我会按我们实际操作的时间线来讲，包含大量可复现的细节和参数建议。适合谁看？想用低代码平台快速搭建智能体的产品同学、技术同学，以及正在学校或团队里带类似实践项目的负责人，读完应该能直接照着搭一套属于自己的智能体。

1. 智能体与扣子平台：先把概念搞透再动手

1.1 智能体不是聊天机器人，而是一个“能干活的小团队”

很多人在做智能体项目的时候容易把智能体和聊天机器人画等号，这是最大误区。聊天机器人是“你问一句，我回一句”，核心是语言生成。智能体的本质是“能完成任务的小团队”——它有一个大模型当大脑，加上规划能力、记忆能力、工具调用能力和知识库，最终指向的是“帮用户把事办成”。

举一个生活化的例子：传统聊天机器人像一个只会背话术的前台，你问什么它答什么，答不出来就装死。智能体更像一个有权限、有工具、有分工的办事专员——你说“我要去某景区玩两天，帮我规划一下”，它能拆解任务：先查景区开放时间和门票规则，再查附近住宿和交通，考虑你只有周末两天，再算好时间安排，最后用规范的表格格式输出一份完整行程。整个过程不是一段话生成的，是多步骤串起来的。

这里就引出了智能体的六要素模型：

• 大脑（大模型）：负责理解、推理、生成自然语言内容。
• 规划器：把复杂目标拆解成可执行的子任务，决定先做什么后做什么。
• 记忆：短期记忆保存当前对话上下文，长期记忆保存用户偏好和历史行为。
• 工具集：调用外部API、数据库、网页搜索、办公软件等能力。
• 知识库：存储私有、结构化的业务知识，是智能体回答专业问题的依据。
• 行动反馈：每个步骤执行后，根据结果调整下一步计划。

在实际项目中，功能越聚焦的智能体越稳定。比如“景区咨询助手”和“全域文旅助手”，前者只需要管好门票、交通、开放时间，后者要懂景点、酒店、餐饮、投诉、活动、天气……复杂度完全不一样。我们的项目早期就犯过“一个Bot想解决所有问题”的毛病，结果模型经常在不同意图之间摇摆，后来老老实实拆成了主助手加多个专项Bot。

1.2 为什么选扣子：三个让我没想到的细节

选扣子做智能体开发平台，是在对比了多个方案之后定的。当初考虑的主要是三点：

第一是搭建门槛足够低。团队里有几位同学完全没写过代码，靠可视化拖拽也能在去掉几层抽象之后搭起一个能跑的原型。传统开发方式做一个问答机器人，至少要准备后端服务、前端页面、数据库、Prompt工程调优，一套下来两三天起步。用扣子，从注册到第一个Bot跑通，半小时内就能完成。这不是夸张，是我们实测的速度。

第二是工作流和插件生态让“能干活”成为可能。智能体如果只依赖模型自由发挥，就没法保证业务准确性。扣子的工作流节点可以把“意图识别→知识库检索→信息规整→回答生成”用可视化的方式串起来，每个节点的输入输出清晰可控。这对于需要精确回答价格、时间、规则这类业务信息来说很重要。

第三是发布渠道覆盖了日常使用场景。扣子支持一键发布成网页、小程序、公众号、API接口等形式，我们在实践中把它嵌到了公众号菜单和网页弹窗里，对用户来说没有任何学习成本。

但我还是想强调：低代码不代表无脑。扣子省掉的是前后端开发的时间，却没有省掉业务梳理、知识清洗、Prompt调试、效果评估这些核心工作。这些才是决定智能体好不好用的关键。

2. 西南实践环境里的项目立项与场景选址

2.1 实践环境到底特殊在哪

项目标题里有一个“西南实践环境”，不是随便加的，它的确有特殊性，直接影响了不少设计和决策。

我们所在的西南某城市，互联网基础设施并不差，但数字化服务资源相对分散：景区有自己的公众号、酒店有携程入口、餐饮用美团、交通要看公交App。用户做一个决策往往要来回切换好几个平台。这就天然适合做一个“统一入口”的智能体。而西南地区文旅资源丰富，景区、古镇、民俗、自然风光都不缺，智能化诉求真实存在，不是拍脑子虚构出来的场景。

但西南实践环境也带来几个制约：

• 网络环境访问外部接口不稳定：部分景区点位在山区，移动网络信号一般，智能体在线调用云端的体验会有波动。所以我们在设计时尽量把高频知识都放进知识库，减少对实时接口的强依赖。
• 用户表达习惯带有地域特色：当地人习惯说方言味浓一点的短句，比如“门票好多钱”“今天开没开嘛”“咋个走”。这些口语化、带省略的表达，对模型的意图识别是个考验，必须准备方言测试集。
• 数据敏感性和权属问题：景区的票务数据、游客数据属于合作方，不能随意上传到公共大模型训练。所以知识库只放了脱敏后的公开规则，核心交易数据通过私有接口调用。

这也是我认为“西南实践环境”最大的价值：它逼着你直面真实场景里的约束条件，而不是在实验室里做Demo。

2.2 场景怎么选：从景区咨询到设备运维的取舍

立项讨论时，我们列了很多候选场景：景区咨询、酒店预订助手、投诉工单处理、政府政策问答、工业设备运维、校园服务问答……最后选了“文旅场景多需求聚合助手”。

理由是它最能体现智能体的综合能力：

• 高频、重复、规则明确（票价、活动时间、交通线路）；
• 也有一定复杂度（多日行程规划、推荐请求）；
• 还有线下联动的业务闭环（投诉要转人工、预约要留电话）。

第一版功能定义得非常收敛：

• 景区基础信息问答（开闭园时间、票价、优惠政策、交通方式、游玩路线）；
• 当日活动与天气提醒；
• 用户意向登记（预约信息记录到数据库）；
• 复杂问题引导转人工。

场景界定清楚后，后面的知识库清洗、工作流设计就有据可依了。这也是我想强调的一点：做智能体项目，别让技术驱动选场景，要让场景驱动选技术。

2.3 团队分工与需求梳理的真实流程

我们团队一共五个人，分工大概是：A同学负责整体架构和扣子平台搭建，某开发者负责提示词工程和效果调优，一位同学专攻知识库整理，另一位负责业务方对接和场景梳理，我主要做测试规范和问题记录。

需求梳理阶段最花时间。因为业务方并不懂智能体，他们提出的想法往往是“像人一样回答问题就行”。我们要做的就是和业务方一个个场景过，把“像人一样”翻译成可执行的规则。比如“智能体要会推荐”，那就要定义清楚：推荐根据什么推荐？基于距离、热度、天气，还是用户偏好？如果规则不明确，推荐结果就完全不可控。

这里分享一个实践心得：每次业务沟通必须有记录，并且要把结论同步成一张“需求-规则对照表”。某业务员说“节假日门票可能更改”，我们就拆成了两个功能点：一是知识库里维护节假日票务规则字段；二是工作流里加一个“当天是否为节假日”的判断节点。经过两周左右的梳理，我们最终沉淀下来约30条核心问答规则、12个高频意图、5类需要转人工的兜底场景。这个清单，其实是整个项目最值钱的产物。

3. 从零搭建扣子智能体：完整实操记录

3.1 创建Bot并把“人设”写进提示词

扣子平台的实操起点是创建Bot。登录平台后进入“工作台”，点击新建Bot，选择模型。我们当时对比过平台内多款模型，最终选了综合的中文理解与指令遵循能力较好的默认模型，因为它的意图识别和长文本提取比较稳，成本也划算。

创建完Bot，第一件事就是写人设和Prompt。这个环节直接决定智能体“像不像一个靠谱的文旅助手”。

我分享一下我们的Prompt结构，真正在项目中被验证有效的写法：

# 角色 你叫“小游”，是XX文旅智能服务助手，负责为游客提供XX地区景区信息咨询、行程建议和预约登记服务。 # 职责边界 1. 只回答与景区开放时间、门票价格、优惠政策、交通路线、游玩项目相关的问题。 2. 不回答天气以外的主观推荐，不编造不存在的景区设施。 3. 涉及价格、时间等具体数字时，只允许引用知识库内容，不得自行推断。 4. 用户表达不满或投诉时，先安抚，再引导转人工。 # 对话风格 - 语言亲切、简洁，口语化，适当使用本地常见说法。 - 答案尽量控制在100字以内，复杂信息用列表呈现。 # 输出规范 - 当用户咨询门票价格时，必须标注适用日期和人群。 - 当信息不确定时，明确回答“我这边暂时查不到”，并建议拨打人工热线。

这个结构的特点是：把身份、边界、风格、输出规范拆开了。我以前写Prompt就是一句话“你是一个导游”，结果模型回答时经常放飞自我。后来验证下来，角色之外加上“职责边界”和“输出规范”，能把幻觉率明显压下来。

测试阶段一定要在右侧对话窗口里跑一跑。我习惯准备一份测试问题集，至少包含正问、反问、省略问、方言问四类。比如：

• 正问：“景区几点开门？”
• 反问：“你们这门票怎么这么贵？”
• 省略问：“老人咋收费？”
• 方言问：“明天开放不咯？”

这些问题不需要覆盖太多条，但一定要有代表性。第一批测试跑完，你就会发现模型在省略句和口语化表达上最容易犯迷糊，这时候就需要去调Prompt或者加知识库内容。

3.2 用工作流把复杂任务串起来

早期我们尝试了让模型自由发挥式的回答，结果发现有两个致命问题：一是不稳定，同样的问题多问几次，答案格式、详略、甚至数字都可能变；二是不可控，模型偶尔会自己编出来一条不存在的“夜游专线”。后来决定引入工作流，把这套问答流程固化下来。

我们设计的主问答工作流如下：

1. 用户输入节点：接收用户的自然语言问题。
2. 意图识别节点：基于意图分类模型或LLM判断用户属于“门票咨询”“交通咨询”“活动咨询”“投诉/转人工”“其他”哪一类。
3. 知识库检索节点：根据意图和问题内容，在知识库中检索相关片段。
4. 信息规整节点：对检索结果做二次处理，提取关键字段，拼装成回答素材。
5. 回答生成节点：把素材交给大模型，结合人设生成最终回复。

工作流的编排界面是可视化拖拽的，节点之间可以连线，也可以配置条件分支。我们给“门票咨询”专门设了一条分支：先判断问题是否具体（比如有没有提到成人/学生），如果没有，则在生成回答时主动追问人群类型。

这一步最有用的一个技巧是：把知识库检索结果先做“缓存变量”，传给生成节点，而不是让生成节点直接检索。因为模型直接去检索时容易检索到不相关内容导致回答跑偏。通过流程固定，保证每次问答走的都是同一条可控路径。

3.3 知识库清洗与触发策略

知识库是整个智能体回答质量的基础。项目上线前我们花了三天专门做数据清洗，一开始真没意识到这个环节这么重要。

首先是数据来源的收集。合作方给了我们一堆资料：景区介绍PDF、票价表格Excel、官网FAQ、公众号历史文章。总量不算大，但格式五花八门。

然后就是清洗的四个步骤：

• 格式统一：所有PDF转成纯文本，Excel转成CSV，公众号文章复制成Markdown。注意PDF转文本经常有断行错乱，需要人工校对。
• 内容去重：同一景区的票务信息可能出现在三个地方，以官方最新文件为准，其余的删掉。
• 分块处理：扣子的知识库是基于向量检索的，上传文档会自动分块，但自动分块经常不智能。我们手动控制分块策略，大概是一个段落或一个子主题分一块，每块文字控制在300-500字左右，太少了没上下文，太多了检索不精准。
• 加标签：给每个知识块打上场景标签，比如“票务”“交通”“开放时间”“活动”，这样可以在工作流里按标签定向检索，减少噪音。

上传到扣子知识库后，还可以配置触发策略。我们当时选择了“检索增强生成”模式，也就是每次回答前先从知识库检索相关内容，再交给模型生成。触发阈值可以调，我们设置在相似度0.5以上才召回，0.3-0.5之间会给一个模糊提示，低于0.3就当作没有相关内容，回复“暂时查不到”。

这里有一个项目现场的教训：知识库检索不是“传上去就完事”。上线前必须逐条检查知识库里那些高频问题的召回结果是否准确。比如“学生票多少钱”，如果知识库里只有“学生票半价”，但没写清楚“凭学生证”和“不含索道”这些限定，模型就很容易答出有误导性的信息。

3.4 调试、测试与发布渠道配置

上线前最后一周，我们进入密集测试阶段。

测试分三层：

• 单Bot测试：在扣子控制台里直接对话，连续跑一遍核心问题集，记录达标率。
• 工作流联调：把工作流挂载到Bot上，再跑一遍问题集，确认每个节点是否正确执行。
• 真渠道测试：发布到公众号菜单和网页链接，用真手机点开实测。

真渠道测试发现的问题是最多也最真实的。比如公众号里的对话入口，用户习惯是发一条语音，或者输入比预想更短的内容，比如“门票好多钱”这种。而网页里的用户会更喜欢点击快捷问题按钮，所以我们在网页渠道配置了一些常见问题卡片，体验大幅提升。

发布这块，扣子的操作不复杂：选一个发布渠道，确认关联的Bot版本，点发布即可。但有几个细节必须注意：

• 版本管理：每次修改后要“发布新版本”，不要在旧版本上反复改，否则多个渠道可能跑不同的逻辑，排查问题时会非常痛苦。
• 权限配置：发布成API接口时，要配置访问密钥和调用限额，防止被外部恶意调用产生费用。
• 安全审查：发布到公众号等公网渠道前，必须过一遍内容合规审查，确保回答内容不含敏感信息。

实测下来，网页弹出式助手和公众号菜单接入效果最好，用户触达率高，部署也最快。API方式适合后续要对接第三方业务系统时使用。

4. 踩坑与排查：真实项目里最常见的6个问题

复盘整个项目，我们记录了大量问题。这里整理6类典型问题，每类附上现象、原因、排查思路和最终解法，做成一张速查表。

挑几个重点展开讲。

4.1 知识库命中率低，回答总是“自圆其说”

上线初期最大的痛点就是答非所问。用户问“从火车站怎么去景区”，知识库里明明有交通说明，模型却经常答成“建议打车”这样的泛泛内容。

排查思路是这样的：先看工作流里知识库检索节点的召回片段到底是什么。扣子里可以直接查看每次检索命中的知识块内容。结果发现，分块太大导致知识块里信息太杂，相似度被稀释了；另外，用户口语里“火车站”和知识库里的“高铁站”对不上。

解决方法是双管齐下：第一，把交通、门票、开放时间这些高价值知识重新分块，每块就是一个独立主题；第二，在知识库上传时新增同义词别名，比如“火车站=高铁站=动车站=客运站”，让检索匹配率明显上涨。经过调整，核心问题的答非所问率从约30%降到了不到8%。

4.2 工作流节点串行太多，卡在“正在思考”

有一次用户反馈说“等得太久，转人工算了”。我们排查后发现，某个工作流里串了5个模型生成节点，每个节点都要跑几十亿参数的模型，累加起来耗时超过10秒，很难受。

优化思路有两条：一是检查哪些节点可以并行执行，比如“查询天气”和“查询门票”互相不依赖，就放到并行分支里；二是把不需要大模型的简单判断从LLM节点换成普通逻辑节点，比如“判断问题中是否含‘学生’关键词”完全可以用正则或条件判断，不必让模型来干。

调整后，简单问答的端到端耗时控制在3秒以内，复杂推荐的耗时控制在6秒左右，用户满意度明显回升。

4.3 多轮对话记忆混乱怎么办

智能体项目里，多轮记忆是最容易忽略又最影响体验的一个点。我们会遇到这样的场景：用户前一分钟说“我们一共四个人，有两个小孩”，下一分钟问“你推荐路线长不长”，结果智能体推荐了一条需要长时间爬山的路线。

原因是模型对话上下文虽然包含了历史消息，但我们并没有把“用户带了小孩”这个关键信息提取出来变成结构化变量来使用。后来我们在工作流里加了“用户信息抽取节点”，在对话中只要识别到人数、年龄、偏好这类信息，就写入变量：

• visitor_count：人数
• has_child：是否有儿童
• interest_tags：兴趣标签

后续的推荐节点直接读取这些变量，再结合知识库过滤适合亲子游的路线。这个改动效果立竿见影，用户体感上“智能体真的记住了我说的话”。

4.4 发布到实际渠道后体验掉线的坑

网页版发布当晚，我们收到好几条反馈，说“手机浏览器打开了，但智能体不回复”。排查发现是手机上网页的WebSocket连接被运营商网络拦截了，超时后没有提示，看起来就像死了。

解决方式是在网页嵌入层加一个超时重连机制，同时给用户一个明显的“正在输入”的反馈状态。这里其实不完全是扣子的问题，而是前端接入的体验细节。扣子提供了网页嵌入的代码，但白屏、加载状态、异常兜底这些还是要自己去处理。

另外一个渠道坑是公众号。公众号菜单配置好之后，发现智能体收不到部分用户消息，原因是公众号平台要求服务器配置里填写的URL必须支持特定验证流程。这个属于业务方公众号平台配置的细节，跟扣子本身关系不大，但它提醒我们：发布渠道的联调最好由渠道管理员直接参与，别等上线了再发现问题。

4.5 访问安全与成本限额

智能体上线后，我们曾经在一天之内接到了大量请求，一看日志，全都是同一个IP在反复调用“生成一段XX景区的宣传文案”。好在扣子有调用限额配置，我们提前设了单用户单日上限，费用没有失控，但这给我们的教训是：对外发布的智能体必须做访问频率控制。

具体做法：API方式发布的，在请求头加上密钥校验，同时限制单IP单日调用次数；公众号方式发布的，按照用户OpenID做每日次数限制；网页方式发布的，在嵌入层做简单的前端埋点统计，发现异常流量及时在后台封禁。

4.6 业务规则变化后的知识库同步

项目运行到第三周，景区调整了夏令时开放时间。我们当时只在知识库里改了文档内容，结果智能体回答的还是旧时间。后来排查发现，扣子知识库更新后需要重新建索引，新建的索引才能被检索节点生效。

所以知识库的更新不是改个文件就完事，还要在后台确认“索引状态”完成。这里我们沉淀的一个习惯是：建立一份业务规则变更台账，每次业务方通知变动，马上更新知识库，并在当天跑一遍相关问答回归测试，确认没有旧数据残留。

5. 沉淀下来的几点个人体会

项目收尾之后，我一直在想智能体落地这件事，到底难在哪里。做了两个月，我的答案不是模型选的不好，不是平台功能不够，而是“业务规则的结构化表达”和“效果评估的闭环”这两件事，决定了智能体是锦上添花的Demo，还是真正能分担业务压力的工具。

扣子这类平台把开发门槛压得很低，但低门槛带来的错觉是“搭一个Bot就算完事”。实际上，一个能稳定运行、让用户信任的智能体，背后是大量知识清洗、Prompt调整、工作流约束和回归测试。它比较像拼乐高——零件的连接方式是固定的，但你要拼出什么结构、怎么保证结构牢固，才是真正花精力的地方。

在西南这种实践环境里我们还有一个体会：不要把智能体当成一个纯线上产品来做。它最好是“线上智能、线下服务”的结合点。用户通过智能体获取信息，复杂和有争议的需求再转给人工，这样既减轻了人工压力，也避免了很多智能体回答不当带来的风险。项目结束后我把这套“线上智能体+人工兜底”的模式整理成了文档，后来几个兄弟单位来找我们取经，也都是冲着这套落地经验来的。

如果你正在计划做自己的第一个智能体项目，我的建议是：先找一个边界清晰、知识高频重复、用户真实存在的小场景，把Prompt、知识库、工作流这三件事打磨透，再考虑扩大覆盖面。不要一上来就追求“全能助手”，从小而准开始，比大而全实用得多。