用Coze空间搭建旅行攻略Agent：从知识库到工作流的完整实践

你问“Coze空间能做旅行攻略吗”，其实是在问两件事：第一，Coze这个平台值不值得专门建一个空间；第二，旅行攻略这种既要做内容生成、又要接实时信息的任务，Agent能不能真正跑通。我的判断是：能，但前提是你要把“空间”当成应用工程来用，而不是当一个高级聊天框。

这个判断源于一个很常见的落差。很多人第一次接触Coze，都是在对话界面试了几个Prompt，觉得“不过如此”。但做旅行攻略不是问一两个问题就结束的。用户会带出4天行程、2人出行、预算4000、不想太累、想吃本地菜、酒店要离地铁近……这些信息散落在对话里，需要被抽取、检索、查实时天气和交通、再拼成一张结构化的行程表。用普通聊天窗口做这件事，很快就失控。把这些数据源、私有资料、自动化流程和对外的对话窗口统一放进一个空间里，才像是做一个应用。

这篇文章会拆开讲清楚五件事：第一，Coze空间到底解决了什么工程问题；第二，旅行攻略这个选题为什么适合用来建立空间；第三，从零搭建一个旅行攻略Bot的完整流程；第四，人设、知识库、插件、工作流这些配置长什么样、怎么配；第五，跑通之后怎么验证、怎么排查、怎么持续迭代。

1. 为什么用 Coze 空间做旅行攻略：三个真实痛点

先别急着打开控制台，想清楚为什么要用空间来做旅行攻略，否则很容易做成一个“看着能用、真用就废”的Demo。

1.1 传统旅行攻略的真实难点：信息过时、资料分散、需求不同

做自由行攻略，最累的不是“玩”，而是“查”。一篇游记可能是两年前写的，推荐的餐厅已经关门；每个平台都有信息，但景点、天气、交通、预算、签证、住宿这些内容分散在不同App里；同样是去成都，带爸妈和几个朋友去，路线和节奏完全不一样。你会发现，真正困难的是把不同维度的信息整合到同一条可执行的时间线上。

传统方式下，大多数人靠Excel和收藏夹硬扛。这种方案有几个硬伤：攻略一次性使用，信息不沉淀；每个人的偏好不同，复制别人攻略经常水土不服；就算把资料整理好了，也没法用对话的方式随时问“明天如果下雨，行程怎么调整”。

1.2 自己写代码接API太重，纯对话又不够用

如果自己写一个小程序来接地图API、天气API、搜索API，还要处理参数解析、错误重试、结果格式化，工作量远大于攻略本身。更不用提知识库检索、多轮对话记忆、多端发布这些工程能力。如果只依赖大模型的通用能力，它只能给出训练数据里的知识，没办法拿到今天的天气、实时交通、某个景区是否临时关闭这类信息。

Coze这类平台卡在中间：不需要你写完整工程代码，但它保留了工程化能力。空间就是这种能力的最小组织单元。它不是一个文件夹，而是一个带有独立知识库、插件、工作流和发布配置的“应用运行环境”。

1.3 小结论：空间解决的是“应用资源边界”问题

搜索“空间”这个关键词时，很多人看到的是C盘清理、编译器堆空间不足。这些话题和Coze空间八竿子打不着，但它们有一个共同点：任何系统都要管好资源边界。C盘要管好空间，程序要管好堆空间，Agent应用也要管好空间。如果不做隔离，插件、知识库、工作流全堆在一个Bot里，一旦项目多起来，你会发现改A项目会影响到B项目，知识库互相污染，API Key也分不清是哪个应用的。

空间的价值就在于这种边界。它让每个Bot有自己独立的知识库、独立的插件凭证、独立的发布版本。这个前提成立之后，像旅行攻略这样需要多资源协作的Agent，才真正值得开发。

2. Coze 空间的核心概念与适用场景

这一部分讲概念，但不会写成百科词条。我的目标是让你30秒内理解空间里有什么、为什么需要它。

2.1 什么是空间：把一个Agent当成“小工坊”来管理

你可以把Coze空间想象成一个独立运行的“小工坊”。工坊里有你从各处搜集来的资料（知识库），有工具箱（插件），有流水线（工作流），还有面向客户的柜台（智能体）。不同工坊之间是物理隔离的，不会把A项目的资料错塞到B项目里。

如果你的Coze账号里只有一两个测试Bot，可能感受不到空间的意义。但当你开始同时维护“旅行攻略助手”“小红书选题助手”“公司内部知识问答”三个应用时，空间就是阻止混乱的最后一道防线。它相当于传统软件项目里的“命名空间”或“工作区”。

2.2 空间内的核心资源：智能体、工作流、知识库、插件

在Coze空间中，通常会有几类核心资源，我这里用表格做一个归类，方便后面对照：

2.3 空间隔离带来的工程收益

空间不只是“归类”，它的本质是工程隔离。哪些收益最直接？

第一，知识库隔离。旅行攻略项目的资料不会跑到公司内部问答项目里去，避免RAG检索时张冠李戴。第二，插件凭证隔离。地图API Key、天气服务密钥这类敏感配置局限在单个空间，降低泄露扩散风险。第三，版本发布隔离。你可以在一个空间内反复改工作流、改人设、改知识库，发布前不影响线上版本。第四，协作权限隔离。团队成员可以按空间被赋予不同权限，谁负责旅行攻略，谁负责其他项目，边界清晰。

2.4 什么情况下应该用空间，而不是只建一个Bot

我的建议很简单：

• 如果你的应用需要私有知识库：用空间。
• 如果你的应用需要接实时插件，而不是纯模型回答：用空间。
• 如果你的应用需要多步骤工作流：用空间。
• 如果你需要发布到多个渠道并持续迭代：用空间。
• 如果你只是临时测试Prompt效果：单Bot就够，不需要空间。

旅行攻略恰好命中前四条，所以它是一个非常适合用空间来搭建的典型Agent场景。它也常被用来当作Coze入门项目，因为这个场景需求明确，又不会简单到只用Prompt就能糊弄过去。

3. 环境准备与前置条件

在进入正式搭建之前，先把环境准备好。这里我按“通用路径”写，不绑定某个具体版本或网络环境，你只需要跟着平台界面找到对应入口即可。

3.1 注册Coze/扣子账号

打开Coze官网或用对应平台的入口完成注册。注册时建议使用一个稳定的手机号或邮箱，因为后面发布到小程序或企业应用时，部分渠道会要求实名认证。

需要提醒的是，Coze有国内版和海外版，两者在模型选择、插件市场、发布渠道上会有差异。本文以通用能力为例，你按自己的注册版本选择即可。如果团队协作，尽量统一到同一个工作区体系下，避免项目分散。

3.2 搭建旅行攻略Bot前的准备工作清单

在正式创建空间前，建议先准备几样东西，它们会直接影响配置效率：

• 一个明确的示例需求，例如“带爸妈去京都玩5天，预算15000元，不想太累”。有具体例子，调试时才有验收标准。
• 一批旅行参考资料。包括景点介绍、餐厅推荐、交通建议、避坑笔记，最好整理成Markdown。
• 可用的API Key（可选）。如果平台内部插件已经能覆盖天气和地图，可以暂不申请；如果要更强的自定义能力，再去申请相应服务的Key。
• 一份输出模板。比如你希望Bot最后生成的攻略长什么样，建议先用Markdown写好样例。

3.3 创建空间的步骤

不同版本界面可能有细微差别，但主线是一致的：

1. 登录Coze控制台。
2. 在控制台找到“空间”入口，点击创建。
3. 填写空间名称，例如“旅行攻略助手”。
4. 填写空间描述，例如“用于管理旅行规划Bot、旅行知识库和相关插件的独立空间”。
5. 创建完成后进入空间，在空间内创建智能体或工作流。

创建空间本身很简单。真正要花心思的是后面的知识库整理和工作流设计，这两步决定了Bot最终是“看起来会聊天”还是“真的能用”。

3.4 确认权限模式

如果你是自己个人使用，创建空间后就能直接管理。如果是团队项目，建议在空间设置里做成员管理：把编辑权限给核心维护者，其他成员只给查看或使用权限。权限边界清晰，才能避免有人误改工作流配置导致线上Bot异常。

4. 核心流程拆解：从一个想法到可用的旅行攻略 Bot

这一节是全文最核心的部分。我会把搭建旅行攻略Bot的完整流程拆成7步，每一步都说明“做什么”“为什么需要”“做错会有什么问题”。

4.1 流程总览：七步走

4.2 步骤一：明确需求边界

做Agent之前，先想清楚你希望Bot在什么范围内回答问题。比如“旅行攻略助手”可不可以回答：“帮我查一下东京迪士尼下午三点的排队时间？”

如果不在需求边界内，Bot会硬答，或者给出误导性信息。建议先列出必须支持的能力和明确拒绝的能力。例如：

• 必须支持：规划多日行程、根据天气调整建议、按预算筛选餐厅和住宿、输出Markdown行程表。
• 可以支持：解读简单交通路线、提醒通用文化禁忌。
• 明确拒绝：代替用户预订酒店和机票、提供非公开的实时排队数据、承诺具体价格。

4.3 步骤二：创建空间

空间负责隔离资源。创建后的第一步，应该先把空间的四块基础资源初始化好：智能体占位、知识库目录、插件列表、工作流入口。哪怕暂时内容为空，也要先把目录结构搭出来。很多项目做到一半出问题，就是因为一开始没规划好空间，所有东西都塞在默认Bot里。

4.4 步骤三：定义智能体人设

在Coze的人设配置区域写System Prompt。这里有两个常见误区。

第一个误区是只写“你是一个旅行助手”。这个约束太弱，模型输出的格式、语气、边界都不可控。第二个误区是写一大堆相互矛盾的规则。比如前面说“每句话都要简短”，后面又说“要输出非常详细的行程表”，模型会无所适从。

比较稳的写法是：角色 + 能力范围 + 工作流程 + 输出格式 + 禁止事项。我会在第五节的完整示例里给出可直接参考的人设文本。

4.5 步骤四：准备知识库

知识库的价值是给模型补充“私有知识”，也就是那些不在训练数据里、或者经常变化的信息。旅行攻略场景里，典型的知识库内容包括：

• 某个城市的地铁Tips，比如“不要在早晚高峰拖大行李箱坐地铁”。
• 某个景点的门票预约规则，比如“故宫需要提前7天预约”。
• 团队里积累的餐厅避坑笔记。
• 不同预算档位的住宿建议。

知识库的文档不要一味求长。一个文件塞下整本旅行书，检索效果反而不如切成多个主题文件。按城市、区域、主题拆成小块，检索命中率会高很多。

4.6 步骤五：接入插件

旅行攻略需要实时数据，所以插件是这个项目里绕不开的环节。比较常用的插件类型有：

• 天气插件：查询目的地未来一周天气。
• 地图或出行插件：查询路线、交通方式、预计耗时。
• 搜索插件：查询最新开放时间、临时闭馆公告。
• 翻译插件：处理语言沟通场景。

接入插件时注意两点：一是确认插件返回的数据结构，知道哪个字段是温度、哪个字段是天气描述；二是控制权限，不要把个人API Key直接暴露在公开工作流里，尽量通过平台的密钥管理机制配置。

4.7 步骤六：搭建工作流

工作流是把“人工查资料、做表格”的过程自动化。为什么不能只靠模型？因为模型不擅长精确计算、不保证调用实时接口、也不稳定遵守流程。通过工作流，你可以固定住这些流程。

旅行规划工作流通常包含以下节点：

1. 接收用户输入。
2. 用LLM节点提取参数：目的地、天数、人数、预算。
3. 调用天气插件，获取目的地未来天气。
4. 调用搜索/地图插件，获取热门景点与交通路线。
5. 检索知识库，获取私有避坑笔记。
6. 用LLM节点汇总以上信息，生成Markdown攻略。
7. 输出给用户。

这个流程一旦建立，用户每次问“帮我规划旅行”，都走同一条路径，结果质量更稳定。就算某个节点出错，也能快速定位。

4.8 步骤七：调试、发布、迭代

工作流搭好之后，先在调试面板里跑通。建议准备几组固定测试用例，比如：

• “推荐一个适合3月份带老人去的城市，5天，预算6000。”
• “我一个人去重庆3天，住在解放碑附近，求行程。”
• “想去新疆玩7天，但不想自驾，怎么安排交通？”

每组测试都看三件事：答案是否自然、信息是否准确、格式是否符合预期。修改流程时，一次只改一个变量，不要同时改人设、知识库和工作流，否则很难判断是哪一步产生了效果。改完测试通过，再发布到目标渠道。

5. 完整示例：旅行攻略 Bot 的人设、知识库与工作流配置

这部分给可直接落地的示例。由于Coze平台的界面和配置项可能随版本变化，这里不追求字段级同步，重点刻画“配置的形态”和“背后的逻辑”。

5.1 人设提示词示例

下面这段文本可以用在Coze的人设/系统提示词输入框里。它不需要代码，但决定了模型以什么角色、什么顺序、什么格式来完成任务。

# 角色 你是一个专业的旅行规划助手，名字叫“小途”。你的任务是帮助用户生成可执行的自由行攻略。 # 能力范围 - 规划多日行程，输出按天和时段划分的时间表。 - 根据天气、预算、人数调整建议，例如雨天改成室内景点。 - 回答通用的交通、签证、货币、文化习俗问题。 - 结合知识库中的私有笔记，给出个性化建议。 # 工作流程 1. 先确认4个关键参数：目的地、天数、出行人数、预算。 2. 如果参数缺失，用提问引导用户补充，不要自己猜测。 3. 参数齐全后，调用工作流查询天气、热门景点和交通建议。 4. 检索知识库中的个人旅行笔记和避坑清单。 5. 最终生成结构化的Markdown攻略。 # 输出格式 必须输出以下四部分： 1. 行程概览：以 D1、D2、D3 为行的表格。 2. 每日详细安排：每个时段标注建议地点、交通方式、预计时长。 3. 预算明细：按交通、住宿、餐饮、门票、其他分类。 4. 避坑提示：结合知识库中的笔记给出提醒。 # 禁止事项 - 不编造不存在的景点、酒店或餐厅。 - 不承诺具体价格，只给参考区间。 - 不代替用户完成订票、订房、支付。 - 不回答与旅行规划无关的问题。

这段人设的要点是：把“怎么做”的流程写清楚，而不是只强调“你是一个助手”。特别是“参数缺失时先提问”这一条，能明显提高对话质量，避免用户只扔一句“帮我规划行程”，Bot就凭猜测输出一份不靠谱的攻略。

5.2 知识库文档模板示例

知识库需要准备什么？我建议先按主题拆文件。比如针对京都旅行，你可以准备一份类似下面的Markdown文件。

# 京都 5 日自由行参考资料 ## 通用信息 - 最佳季节：3-5月、10-11月 - 语言：日语为主，景点和餐厅的中文标识较少 - 货币：日元，建议提前换少量现金 ## 景点（按区域整理） ### 东山区 - 清水寺：需要爬坡，建议安排上午；傍晚人流量较大 - 二年坂三年坂：适合拍照，很多店铺10点后才开门 ### 岚山区 - 岚山竹林：清晨人少，适合拍照 - 天龙寺：与竹林相邻，可以安排同一天参观 ## 交通建议 - 京都公交车覆盖广，但高峰期拥挤 - 带老人出行建议优先选择出租车或包车，费用需计入预算 ## 餐饮避坑 - 热门怀石料理建议提前一个月预约 - 车站附近的“游客餐厅”性价比偏低 ## 预算参考 - 普通餐厅人均：2000-4000日元 - 便利店早餐人均：500-800日元

这样的文档不追求文学性，只追求“检索友好”。每个小块有明确的主题标签，模型在回答“带爸妈去京都”时，更容易检索到“交通建议”和“预算参考”这两块内容，而不是在一大篇游记里捞关键词。

5.3 工作流节点配置说明

工作流的设计逻辑比界面细节更重要。下面这张表对应一个常见的旅行规划工作流：

如果你习惯用JSON理解流程，可以看下面这个结构示意。它只是用来帮助理解，不是Coze官方导出格式：

{ "workflow_name": "旅行攻略生成器", "nodes": [ { "id": "1", "type": "input", "name": "接收用户需求" }, { "id": "2", "type": "llm", "name": "参数抽取" }, { "id": "3", "type": "plugin", "name": "查询天气" }, { "id": "4", "type": "plugin", "name": "搜索景点与交通" }, { "id": "5", "type": "knowledge_base", "name": "检索个人旅行笔记" }, { "id": "6", "type": "llm", "name": "生成Markdown攻略" }, { "id": "7", "type": "output", "name": "返回攻略" } ] }

真正配置时，你在工作流画布里按照这个顺序拖动节点、连线、填写参数即可。工作流和纯Prompt的核心差异是：固定节点顺序让过程可控，任何一个环节出错都能被单独定位。

5.4 输出模板示例：一份可阅读的行程攻略

工作流最终应该输出什么样的内容？我建议预先定义好输出模板。下面是一个对照示例。

# 京都 5 日自由行攻略（3人，预算15000元） ## 行程概览 | 日期 | 上午 | 下午 | 晚上 | 住宿区域 | | --- | --- | --- | --- | --- | | D1 | 抵达京都，入住酒店 | 鸭川散步 | 先斗町晚餐 | 京都站附近 | | D2 | 伏见稻荷大社 | 清水寺 | 祇园 | 东山区 | | D3 | 岚山竹林 | 天龙寺 | 京都站商圈 | 京都站附近 | | D4 | 金阁寺 | 二条城 | 自由活动 | 京都站附近 | | D5 | 购买伴手礼 | 返程 | — | — | ## 每日详细安排 ### D1 - 上午：根据航班时间，从关西机场搭乘Haruka列车至京都站。 - 下午：鸭川沿岸散步，从三条到四条有大量餐饮选择。 - 晚上：先斗町巷内用餐，建议提前在大众点评或Google Map看评分。 ## 预算明细 | 分类 | 预估金额 | 说明 | | --- | --- | --- | | 交通 | 3000元 | 含机场往返、市内交通 | | 住宿 | 9000元 | 3人住两间房，按5晚估算 | | 餐饮 | 3000元 | 人均每天200元左右 | | 门票 | 1000元 | 主要寺院与景点门票 | | 其他 | 1000元 | 购物、应急备用 | ## 避坑提示 - 伏见稻荷大社建议早上8点前到，晚于9点游客明显增多。 - 带老人出行时，清水寺前的地主神社台阶较多，注意休息。

这份模板有四个优点：快、结构化、可核对、可编辑。用户一眼能看出行程合不合理，也能直接在表里改动。旅行攻略Bot的“可用感”很大程度来自这种结构化输出，而不是一段笼统的文字描述。

6. 运行结果与效果验证

很多Coze新手犯同一个错误：搭好工作流后，随便问一句“帮我做攻略”，看到有输出就认为成功了。但真实可用的Agent需要按指标验收。

6.1 旅行攻略Bot的验收指标

建议从五个维度评估：

• 完整性：是否覆盖交通、住宿、餐饮、景点、预算和注意事项。
• 准确性：天气、开放时间、路线是否可查证，有没有明显编造。
• 时效性：天气和交通信息是否来自实时插件，而不是模型记忆。
• 格式一致性：多次运行后，输出是否都遵循同一套Markdown结构。
• 个性化：是否能根据人数、预算、出行节奏合理调整方案。

6.2 一组可执行的测试用例

你可以直接拿下面这组用例做验证：

6.3 查看日志与可观测性

如果某次输出不符合预期，第一时间看工作流日志。你需要在工作流运行记录中确认：

• 哪个节点执行失败？
• 插件节点返回了空数据还是错误信息？
• 知识库检索到了哪些文档？有没有匹配到错误内容？
• LLM汇总节点接收的上下文是否完整？

这一步非常像后端开发的日志排查。不要只盯着最终输出，要把每个节点的输入输出都当成排查线索。

7. 常见问题与排查思路

下面是搭建旅行攻略Bot时最高频的几类问题，按“现象、原因、排查方式、解决方案”整理成表：

实际调试中，80%的问题出在“信息没有被正确传递”。比如插件返回了天气，但工作流连线缺失，导致LLM节点根本看不到天气数据；知识库里明明有避坑笔记，但智能体没有启用知识库检索功能。排查时先沿着工作流节点从上到下走一遍，比反复改人设更有效。

8. 最佳实践与工程建议

跑通一个旅行攻略Bot只是开始。下面这些实践经验，能让你避免从“Demo可用”滑向“生产不可用”。

8.1 把“人设 + 输出模板”当作接口协议

旅行攻略Bot的本质是从非结构化用户输入，转换成结构化Markdown输出。人设中的工作流程和输出格式，本质上就是一种接口协议。建议单独维护一份“输出模板文档”，每次修改人设之前，先问自己：这次改动会不会改变输出结构？如果会，知识库样例、工作流节点、用户说明都要同步改。不要只改Prompt，不管下游消费方。

8.2 知识库要“小块、带标签、有日期”

RAG的效果非常依赖文档拆分方式。我的建议是：每个知识库文档围绕一个主题，控制在2000字以内；文件开头用标题写明主题；文档内部可以用“更新日期”标注信息时效。比如“京都市营地铁票价（更新于2025-06-01）”比“日本交通全攻略”在检索时的可用性高得多。过期信息宁可移除，也不要留在知识库里误导模型。

8.3 工作流里给每个节点留一份输入输出样例

如果你搭的工作流超过5个节点，建议为每个节点准备一个最小输入、最小输出样例，并写在工作流的备注里。例如参数抽取节点的输出可能是：

{ "destination": "成都", "days": 4, "people": 2, "budget": 4000 }

有了样例，后续排查时能更快判断是节点问题还是数据问题。团队协作时，这份样例就是最好的交接文档。

8.4 插件与API Key的安全管理

创建空间时，插件配置里难免涉及各种API Key。这里有几条安全底线：

• 不要把API Key写死在工作流的公开节点描述里。
• 尽量使用平台的密钥管理或环境变量能力保存敏感信息。
• 如果API Key有调用额度，先用最小权限或低额度Key做测试。
• 知识库中如果包含真实用户个人信息，必须先脱敏再上传。

地图、天气类服务的调用量不大，但也不要忽略配额监控。旅行攻略是季节性应用，节假日流量会显著上涨，提前在插件后台确认配额够用，能避免用户正需要时突然不可用。

8.5 发布与迭代策略：先小范围，再全量

每次修改人设、知识库或工作流后，不要直接覆盖线上版本。推荐顺序是：在空间内复制一个测试版本，用固定用例跑一遍，确认没有问题后，再正式发布。发布后观察一天日志，重点看用户输入中是否有工作流无法处理的边界场景。旅行攻略Bot经常遇到的边界场景包括：用户只给了目的地没给天数、预算单位不明确、天气接口不支持某个具体区域。通过日志持续补全这些边界，比一次性打磨Prompt更有效。

8.6 不要把Agent当成“信息幻觉消除器”

即使接入了插件和知识库，模型仍然有可能漏掉或错用信息。旅行攻略Bot应该做到“敢拒绝”：遇到无法确认的实时信息时，明确告诉用户“当前只能给参考范围，建议出发前再次确认”。这不是能力的缺陷，而是工程上更负责任的做法。

9. 总结与后续学习方向

用Coze空间做旅行攻略，真正训练的不是“让AI帮你写攻略”，而是让一个Agent自己处理私有知识、实时接口、流程编排和多端发布。空间是这种能力的最小容器，旅行攻略是一个完整的演练场。你在这套流程里掌握的方法——拆解需求、设计人设、整理知识库、编排工作流、配置验证、日志排查、版本发布——几乎可以原样迁移到其他垂直场景，比如企业知识问答、内容创作助手、售前客服工具。

如果你今天只做一件事：建一个空间，把你的旅行偏好笔记整理成Markdown丢进知识库，然后跑通一次行程生成。你会发现，真正让Agent变得可用的，不是模型多聪明，而是你愿意花多少心思去整理数据、设计流程和建立反馈机制。

下一步的学习方向，可以从三个角度深入：第一，把工作流做得更复杂，比如加入“根据天气自动替换室内行程”的条件分支；第二，尝试开发自定义插件，把你自己常用的数据源接入Coze；第三，学习一个空间内同时维护多个Bot的经验，让攻略助手、费用记录助手、旅行清单助手共用同一套知识库，形成真正的小型Agent群。