在 Coze 空间中制作旅行攻略本质上不是让 AI 生成几段旅游文案而是把智能体、工作流、知识库和插件组合成一套能根据目的地、天数、预算自动产出可执行行程的服务。很多人第一次打开扣子 Coze 平台看到工作空间、智能体、知识库、插件这些入口容易分不清先后顺序。这篇文章按一条完整的搭建路径来写先建空间再建智能体接着补知识库和工作流最后发布并验证。适合零基础用户也适合产品经理和开发者把“做一个旅行攻略助手”从想法落到可运行状态。1. 先想清楚“Coze 空间制作旅行攻略”到底在做什么1.1 空间、智能体、工作流的定位在 Coze 平台里“空间”不是聊天窗口而是资源管理单元。你可以把它理解为项目工作区里面可以放智能体、知识库、工作流、插件、变量、触发器等各种资源。个人学习时可以直接使用个人空间多人协作时建议创建团队空间把不同成员按角色分配权限避免互相覆盖配置。智能体是用户直接对话的入口它相当于“前台接待”负责理解用户意图、组织回答。但智能体本身不一定要自己完成所有事情它可以调用工作流、知识库和插件。工作流是“后厨流水线”把多个步骤编排成固定流程比如先解析参数再查知识库然后调天气插件最后用大模型生成攻略。知识库是“资料档案室”可以把城市攻略、景点说明、交通指南等文档上传进去让智能体基于私有资料回答而不是完全靠模型记忆。插件则是“外部供应商”用于接入实时天气、地图路线、景点门票等外部能力。一个旅行攻略智能体的完整形态通常不是单独依赖某一部分而是这些组件协同工作。1.2 旅行攻略智能体要处理哪些任务先拆解需求。用户说“我想去成都玩 3 天预算 3000喜欢美食和人文”这句话里包含目的地、天数、预算、兴趣但缺少出行人数、出发城市、交通方式、住宿偏好。一个好的攻略助手应该先识别已有信息再主动追问缺失信息最后生成结构化的行程。功能模块可以拆成几类功能模块实现方式输入示例输出示例目的地解析大模型 变量“厦门 4 天 3 晚”destination厦门days4偏好采集对话追问“喜欢海边和拍照”travel_style海边/摄影行程生成大模型 提示词模板目的地、天数、预算每日行程 Markdown知识检索知识库“鼓浪屿 门票”景点资料、票价信息实时查询天气/地图插件城市、日期天气预报、交通路线预算估算大模型 表格模板预算总额、人数住宿/餐饮/门票明细文档导出文档生成插件Markdown 文本Word 或 PDF 下载链接如果只做演示可以先用提示词让大模型输出攻略但一旦进入实际使用实时信息和私有资料就必须靠知识库和插件补齐。1.3 为什么不能只靠一段提示词很多初学者会把旅行攻略助手理解为“在智能体里写一句‘你是旅行专家’就行了”。这在小范围演示时能跑通但存在明显问题。模型内部知识有时间截止不知道某个景点当前是否开放也不知道当天天气。模型不会稳定地按表格输出偶尔会漏掉预算或行程。用户问的问题稍微偏离预设模型容易自由发挥。这些问题只能通过知识库、插件和工作流来约束。知识库负责固定事实插件负责实时数据工作流负责稳定流程提示词负责表达风格和输出格式四者缺一不可。2. 环境准备注册扣子账号并创建空间2.1 登录扣子平台在浏览器直接访问扣子 Coze 平台国内用户一般会进入 coze.cn 控制台具体以官网当前入口为准。首次使用需要注册账号通常支持手机号或邮箱按页面提示完成即可。注册后先进入控制台不要急着写提示词先把工作环境建立起来。这一步的检查点是能正常打开控制台能看到“创建空间”或“工作空间”入口。如果打不开页面先确认网络和浏览器版本。建议使用 Chrome 或 Edge 等现代浏览器避免旧内核浏览器出现编辑器按钮不显示的问题。2.2 创建空间并设置成员权限进入控制台后找到“空间”管理页面点击“创建空间”。空间名称建议写清楚用途例如“旅行攻略项目”。如果是一个人学习空间类型选个人空间即可如果是团队协作选择团队空间然后邀请成员并分配角色。空间权限通常包括所有者、编辑者、只读者三类。所有者可以管理所有资源和成员编辑者可以创建和修改智能体、工作流、知识库只读者只能查看。实际项目中建议按职责分配最小权限避免有人误改生产环境配置。空间创建完成后所有后续创建的智能体、知识库、工作流都放在这个空间里方便统一管理。2.3 创建旅行攻略智能体在空间内点击“创建智能体”输入名称“旅行攻略助手”填写简介例如“根据目的地、天数、预算自动生成可执行的旅行计划”。随后选择基础模型优先选择平台默认推荐的中文模型中文表达和指令遵循通常更稳定。创建完成后会进入智能体编辑器。编辑器界面通常包含三块区域左侧人设与回复逻辑用来写系统提示词。中间调试区也叫 Playground可以实时输入测试。右侧资源组件区用于添加上下文、插件、工作流、变量、触发器、知识库等。“如何进入 Coze 智能体的 Playground”这个问题实际上就是在编辑器右上角点击“调试”按钮。调试区是开发阶段最重要的验证入口所有提示词和工作流修改都要在这里跑一遍。2.4 环境就绪检查清单在开始写提示词之前花一分钟检查环境是否就绪检查项确认结果不满足时处理账号已登录控制台可访问重新登录空间已创建空间列表中有目标空间创建空间成员权限正常可编辑智能体联系空间所有者智能体已创建能进入编辑器创建智能体插件商店可访问能搜索到插件检查网络或平台状态知识库可上传能上传测试文档检查文件格式和权限这一步容易被忽略等到后面工作流调用失败时才回头检查权限会浪费很多时间。建议先跑通最小环境再开始扩展功能。3. 实现核心对话逻辑人设、提示词与结构化输出3.1 写清人设和回复逻辑进入智能体编辑器后第一件事是写“人设与回复逻辑”。这不是简单写一句“你是旅行专家”而是要明确角色、任务、输入缺失时的处理方式、输出格式和约束。下面是一个适合旅行攻略助手的提示词模板可以直接复制后按需修改# 角色 你是一位专业的旅行规划师熟悉国内主要旅游城市擅长根据用户预算、时间和兴趣定制行程。 # 任务 当用户提供目的地、天数、预算、兴趣等信息时输出一份结构化旅行攻略。 # 输入处理 1. 先梳理用户已经提供的信息目的地、天数、预算、出行人数、兴趣偏好。 2. 如果缺少必要信息先追问不要直接编造行程。 3. 如果用户说“随便”才使用默认推荐方案。 # 输出要求 1. 先输出攻略概览表格包含城市、天数、预算、核心主题。 2. 按天输出行程每天包含上午、下午、晚上三个时段。 3. 每天结束后列出当天餐饮推荐和交通建议。 4. 最后输出预算估算表包含住宿、餐饮、交通、门票、备用金。 5. 所有信息必须基于知识库或插件返回的资料不要编造景点开放时间。这里的关键点是“如果缺少必要信息先追问”。旅行攻略不像天气查询目的地和天数必须明确。如果模型在缺失关键信息时就开始输出用户只会得到一篇看似完整但无法落地的行程。3.2 用变量记录用户约束变量用来在对话过程中记住结构化信息。在智能体编辑器中可以声明变量例如 destination、days、budget、travel_style、food_preference。变量名类型示例值说明destination字符串成都目的地城市days整数3旅行天数budget整数3000总预算travel_style字符串美食、人文兴趣偏好food_preference字符串川菜饮食偏好traveler_count整数2出行人数在提示词中可引导模型解析这些信息并写入变量。例如当用户说“2 个人去成都”模型可以设置 traveler_count2。变量写得好后续工作流节点就能直接用这些值去检索知识库或查询天气不用重新解析一遍用户原话。3.3 设计结构化输出模板为了让输出稳定建议在提示词里直接给出一份 Markdown 模板。用户看到的攻略最好包含概览、每日行程、预算估算三部分## 旅行攻略概览 | 城市 | 天数 | 预算 | 主题 | | --- | --- | --- | --- | | 成都 | 3 天 | 3000 元 | 美食 / 人文 | ## 每日行程 ### Day 1 - 上午抵达成都入住春熙路附近酒店步行逛太古里。 - 下午参观成都博物馆了解蜀文化。 - 晚上在建设路小吃街吃本地小吃。 ## 预算估算 | 项目 | 金额 | 说明 | | --- | --- | --- | | 住宿 | 900 元 | 2 晚经济型酒店 | | 餐饮 | 1200 元 | 3 天本地餐饮 | | 门票 | 300 元 | 武侯祠、杜甫草堂 | | 交通 | 300 元 | 地铁和打车 | | 备用金 | 300 元 | 弹性支出 |使用 Markdown 表格有两个好处第一用户在网页应用或飞书中看到的排版更清晰第二后续如果需要把攻略导出为 WordMarkdown 表格可以较方便地转换格式。3.4 在调试区测试对话效果写完提示词后点击“调试”打开 Playground输入一句完整测试请求“我想去成都玩 3 天 2 晚预算 3000喜欢美食和人文2 个人一起。”预期结果是模型先输出概览表格再输出每天行程最后输出预算估算。检查模型是否追问了出发城市或交通方式是否把“2 个人”写进预算。如果模型直接输出一篇没有表格的短文说明提示词中的“输出要求”还不够强需要把“必须”换成明确指令并更新到“人设与回复逻辑”中。4. 用知识库和工作流把攻略从“聊天”变成“服务”4.1 导入城市攻略到知识库纯靠模型生成旅行攻略只能覆盖热门城市的通用内容。要让智能体回答得更准确比如某个景区几点开放、门票多少钱、附近有什么老店需要把整理好的资料放入知识库。在空间中点击“创建知识库”输入名称“城市旅行攻略库”上传文档。文档格式通常支持 txt、markdown、pdf、docx。建议按“城市_主题_更新时间”命名例如“成都_美食攻略_2025-01.md”。上传时要注意分段策略。长度适中的片段更容易被检索到建议 500 到 1000 字一段并在段落开头保留城市名和景点名。如果整份文档是几万字检索时容易切到无关内容导致模型引用错误。上传完成后在智能体编辑器右侧的“知识库”区域添加上该知识库。这样模型在回答时会把检索到的片段作为参考上下文而不是只依赖通用知识。4.2 接入天气和地图插件旅行攻略很依赖实时信息。一个景区可能因为天气临时关闭一条路线可能因为交通管制变化。在插件商店中搜索“天气”“地图”“景点”等关键词选择平台提供或已经授权的插件添加为智能体工具。添加插件后需要关注两件事。一是插件参数天气插件通常需要城市名和日期地图插件需要起点和终点参数不匹配会直接调用失败。二是插件授权部分插件需要申请 API Key 或在平台上完成授权配置这一步在生产环境尤其重要。上线前要逐一测试每个插件不能只看“已添加”状态。4.3 创建标准工作流工作流适用于“步骤固定、需要复用”的场景。旅行攻略生成流程可以编排成以下节点开始节点接收 destination、days、budget 等参数。知识库检索节点根据目的地检索城市攻略库。插件查询节点查询目的地天气和交通信息。大模型生成节点把检索结果和插件数据交给大模型生成结构化攻略。结束节点返回最终 Markdown 文本。下面是一份用于理解思路的 JSON 配置示意实际界面中通常通过拖拽配置不一定需要手写 JSON{ workflow_name: travel_plan_workflow, nodes: [ { id: start, type: start, params: [destination, days, budget] }, { id: kb_search, type: knowledge, knowledge_base: 城市旅行攻略库, query: {destination} 攻略 }, { id: weather_query, type: plugin, plugin_name: 天气查询, params: { city: {destination}, days: {days} } }, { id: generate, type: llm, prompt: 结合知识库内容和天气信息生成每日行程和预算表。, context: [kb_search, weather_query] }, { id: end, type: end, output: generate } ] }这里的核心逻辑是数据流动开始节点接收智能体传来的参数知识库检索输出一批文本片段插件输出结构化天气数据大模型节点把所有内容拼接成最终回答。每个节点都应有清晰的输入输出这样后续排查时才看得懂。4.4 将工作流接入智能体工作流创建完成后回到智能体编辑器在右侧“工具”区域添加工作流选择刚创建的 travel_plan_workflow。可以设置触发条件例如“当用户输入包含行程、攻略、规划等关键词时调用”。设置触发条件的目的是减少无效调用。如果用户只是在闲聊智能体不需要跑一次完整工作流只有明确要攻略时才触发。也可以让模型自动判断是否调用工作流但自动判断可能偶尔出现“该触发时没触发”的情况所以关键场景更建议使用关键词或意图标签。工作流接入后再次进入调试区测试。输入“帮我规划厦门 4 天 3 晚的行程预算 5000喜欢海边和拍照”观察是否触发了工作流并检查返回结果是否包含天气信息。如果只返回模型自由生成的文本说明工作流没有正确挂载或触发条件未命中。5. 发布、运行验证与日志排查5.1 发布为网页应用或 API调试通过后点击“发布”选择发布渠道。最简单的是发布为网页应用会生成一个链接用户可以直接在浏览器中打开对话。如果团队使用飞书或企业微信也可以发布到对应渠道。发布前需要填写应用头像、名称、简介和开场白。开场白建议写“告诉我你想去哪里、玩几天、预算多少我来帮你规划行程”可以引导用户提供有效信息。发布不等于“保存草稿”。每次修改智能体、提示词、工作流或知识库后都需要重新发布用户访问的版本才会更新。这一点最容易踩坑开发者在调试区测试没问题但用户反馈还是旧功能通常就是因为没有重新发布。5.2 完整测试一次游客咨询发布后用另一台设备或无痕窗口打开网页应用模拟真实用户输入。“帮我规划厦门 4 天 3 晚的行程预算 5000喜欢海边和拍照。”验证点包括验证项预期结果是否通过识别目的地输出“厦门”是 / 否识别天数输出“4 天 3 晚”是 / 否识别预算预算表总额接近 5000是 / 否调用知识库景点介绍与知识库资料一致是 / 否调用天气插件包含厦门未来几天天气是 / 否输出格式包含概览表格和每日行程是 / 否测试时不要只问一次。至少测试三种情况信息完整、信息缺失、包含模糊表达。信息缺失时智能体应该主动追问而不是直接生成随机行程。5.3 查看运行日志和版本管理当功能出现异常要优先看日志。在智能体的运行记录或日志面板中可以查看用户输入、模型输出、工作流调用记录、插件返回结果和错误信息。日志是定位问题的第一线索。示例日志片段2025-01-15 10:23:11 [INFO] User input: 厦门4天3晚行程 2025-01-15 10:23:12 [INFO] Call workflow: travel_plan_workflow 2025-01-15 10:23:13 [INFO] Knowledge search success, top1 score: 0.82 2025-01-15 10:23:14 [INFO] Weather plugin response: 26°C, 多云 2025-01-15 10:23:15 [ERROR] Plugin weather timeout, retry...看到“ERROR”节点基本可以确定问题出在插件调用或外部接口。如果日志里没有工作流调用记录说明智能体没有触发工作流要回到触发条件排查。版本管理方面发布前建议保留历史版本一旦新版本出现问题可以快速回滚。5.4 区分学习环境与生产环境个人调试和正式上线是完全不同的场景。调试时可以接受模型偶尔输出错误但生产环境需要更多保障。维度学习环境生产环境数据少量测试文档定期更新的攻略库权限个人可编辑按角色控制成员权限日志看对话记录日志审计、异常告警限流无要求控制调用频率避免资源耗尽回滚随意修改保留版本支持快速回滚安全几乎不关注过滤敏感信息避免提示词注入插件测试插件验证第三方 API 稳定性配置备用插件学习环境的目的是快速跑通闭环生产环境的目的是稳定、可维护、可回滚。不要把一个测试智能体直接当作正式服务提供给用户。6. 常见问题排查为什么攻略生成不正确6.1 智能体总是重复同一段内容现象无论用户问什么智能体都返回一段固定的“欢迎到成都旅游”之类的文案没有针对性。可能原因提示词中角色指令过于简单模型没有理解需要根据用户输入动态生成调试时上下文累积过长模型记住了之前的回答模型温度参数设置过高导致内容偏向随机。排查方式先清空测试会话重新输入“厦门 4 天 3 晚”。如果恢复正常说明是上下文污染如果仍然重复需要修改提示词明确要求“根据用户本次输入的目的地和天数生成内容”。6.2 知识库检索不到内容现象智能体回答内容没有参考上传的攻略文档仍然输出通用内容。可能原因知识库没有关联到智能体文档分段不合理检索命中低查询词和文档措辞不匹配。排查方式在知识库后台输入一个文档中一定会出现的词例如“鼓浪屿”看能否检索到。如果检索不到检查分段设置和文档格式。建议在分段中保留城市名、景点名等关键词并在提示词中引导模型使用知识库结果例如“只能用知识库中出现的景点信息”。常见坑是上传了一份带复杂表格的 PDF平台难以解析检索结果为空。遇到这种情况先把 PDF 内容转成纯文本或 Markdown再重新上传。6.3 工作流或插件调用失败现象用户输入后长时间等待最终返回“抱歉我暂时无法处理”或报错信息。可能原因插件服务不稳定参数格式不对外部接口限流工作流节点缺少必要参数。排查方式查看日志中的错误码。如果是插件超时可以尝试稍后重试或更换备用插件。如果报参数错误检查工作流开始节点是否接收了正确参数例如 destination 是否被解析成“厦门”而不是“目的地厦门”。[ERROR] PLUGIN_REQUEST_FAILED: weather query timeout看到这类日志优先检查天气插件是否还在有效期内以及城市名参数是否为空。长期方案是给工作流增加失败重试或在模型提示词中加入“如果插件不可用不编造天气”。6.4 发布后功能失效现象调试区测试正常但用户访问网页应用时功能不对。可能原因修改后没有重新发布发布渠道的版本和调试版本不一致网页应用缓存了旧代码。排查方式重新发布用无痕窗口访问查看运行日志中的会话 ID。如果日志显示用户根本没触发工作流说明发布版本里没有包含最新工作流配置。重新发布后再次测试。6.5 常见坑汇总坑点错误表现推荐做法提示词太自由输出没有结构时好时坏强制输出 Markdown 表格模板知识库整篇上传检索命中差引用错误分段 500-1000 字保留关键词插件未授权上线后 API 调用失败上线前逐一测试插件密钥写在提示词中存在敏感信息泄露风险使用环境变量或安全配置工作流没有日志排错只能靠猜为每个节点设置清晰变量名修改后不发布用户访问旧版本改完即发布保留版本记录在真实项目里最常见的问题不是模型能力不够而是工程配置没对齐。建议每改一个模块就发布一次并保留测试记录。7. 最佳实践与扩展方向从攻略助手到完整旅行服务7.1 提示词工程可复用清单给提示词做减法比做加法难。高质量的旅行攻略提示词应包含以下要素要素说明示例角色让模型进入专业身份资深旅行规划师任务明确输出什么输出结构化旅行攻略输入处理缺失信息怎么办先追问不编造输出结构固定模板概览表、每日行程、预算表约束避免什么不使用未验证的开放时间示例给一个最小范例厦门 4 天行程模板提示词不要写“你可以自由发挥”要用“必须按以下模板输出”。模型遵循“必须”比“可以”更稳定。7.2 知识库运营机制旅行攻略的时效性很强。景点门票、开放时间、交通路线都可能变化。知识库不是一次上传就结束需要定期更新。建议按城市建立更新节奏每月检查一次热门景点的开放时间更新文件后重新导入知识库并发布智能体。文件命名建议统一为“城市_主题_更新时间”例如“北京_景点门票_2025-01-20.md”。知识库里的文档做好版本管理这样才能判断该相信哪个片段。7.3 把攻略导出为 Word 文档很多用户不想只看网页而是想把攻略保存成 Word 文件发给同伴。在 Coze 插件市场中可以搜索“Markdown 转 Word”或“文档生成”类插件将大模型最终输出的 Markdown 文本作为输入插件会生成一个 Word 文件并返回下载链接。实现思路是在工作流的大模型生成节点之后增加一个文档转换节点。大模型节点输出 Markdown 文本文档转换节点接收该文本转换为 docx 文件。转换完成后结束节点不只返回文本还要返回文件下载地址。这样可以形成一个完整链路对话输入 - 行程生成 - 文档转换 - 下载输出。需要注意不同文档插件的参数格式可能不同落地前要阅读插件说明。生产环境还要考虑文件存储位置和下载链接有效期。7.4 扩展方向多智能体协作与平台选型当需求变复杂时可以把一个旅行攻略智能体拆成多个角色。城市推荐员负责推荐城市行程规划员负责排行程预算计算员负责核账美食推荐员负责餐饮。多个智能体之间通过工作流或触发条件联动而不是把所有人的逻辑写进一个超长提示词。这种拆分能让每条逻辑更清晰排查问题也更方便。团队在选型时如果看重快速发布和平台内置插件Coze 空间是一个不错的选择如果团队希望私有化部署或深度控制底层流程可以进一步了解 Dify 等开源平台。具体选型要看部署要求、团队技能和预算不能只看宣传。关键是先跑通最小闭环再决定是否迁移。最后给你一个实践建议不要一开始就追求功能齐全先完成一个能根据目的地和天数输出结构化行程的智能体再逐步接入知识库、天气插件、文档导出。每加一个模块就验证一次把日志和版本管理当作正式习惯才能让 Coze 空间里的旅行攻略从演示项目变成可长期使用的服务。