手把手拆解旅行搭子Pro：基于Astron的Agent工作流实战

1. 前言：为什么需要 Agent 工作流？

刚接触 Agent 时，我们大多都是从 Prompt 提示词驱动的Agent开始的，就像下面这样

写一个很长的 Prompt，约定好 LLM 大模型要遵循的角色，指定其拥有那些本领，限制大模型的问答范围，给定输出格式和问答案例。 然后不断往里面加规则、加约束、加示例。

在真正开始做 Agent 应用之前，我一直有一个误区： 是不是 Prompt 写好一点，就够了？

但在做「旅行搭子 Pro」这个 Agent 时，很快就发现不对劲。

当我创建了一个提示词驱动的旅行规划智能体。要求智能体针对用户的输入给出行程规划。

设想着旅行搭子能够明确的理解用户的意图，给出完善的用户满意的行程规划。

但用户的输入往往是这样的：

• "我心情不好，想找个周末出去玩"
• "带娃，有没有轻松点的路线？这几天天气好不好？"
• "预算不多，但不想太累"

这些信息：

• 不完整
• 不标准
• 而且经常需要多轮确认

如果没有一个明确的工作流，Agent 的行为会非常不可控。用户的意图没有被理解，有时候甚至回答的内容和用户的输入完全不相干。

而 Astron Agent 支持创建工作流驱动的智能体，此处基于星辰Agent平台/Astron Agent平台来实现这个旅行搭子。

2. 提示词Agent与工作流Agent

Astron Agent支持提示词驱动的对话式智能体、工作流驱动的复杂任务智能体、面对多模态场景的虚拟数字人

2.1 提示词驱动的智能体

提示词智能体，所有逻辑都写在一个 Prompt 里。

判断、执行、兜底混在一起，强依赖模型"自己理解"，适用于简单的问答场景。

遇到用户信息不完整，需要多轮确认，需要调用工具，需要区分"能不能执行"，我们就需要跟着业务场景不断维护 Prompt，然后慢慢变成一个不可维护的黑盒，就像垃圾代码，改也改不动了。

我在旅行搭子早期版本中，几乎每天都在改 Prompt，但效果提升却越来越小。

2.2 工作流驱动智能体

切换到工作流智能体的思路，不要求在一个 LLM 大模型节点下解决用户的问题

而是由编排的工作流，通过识别用户意图来决策下一步该怎么做

可以是引导用户多轮对话，继续挖掘用户真实意图

可以是调用工具或者MCP服务去做景点推荐，天气查询，交通规划等动作。

在工作流模式下 Prompt 只负责判断，识别用户的意图，判断下一步动作，然后由决策节点做不同的节点流转，整个流程由工作流编排控制。

工作流任意节点（环节）的异常、错误都可以被兜底，统一处理。Agent 将更加健康的运作，可扩展性更强。

---

3. 旅行搭子Agent工作流设计理念

graph TD %% 定义样式 classDef llmNode fill:#f9f,stroke:#333,stroke-width:2px; classDef logicNode fill:#e1f5fe,stroke:#01579b,stroke-width:2px; classDef parallelNode fill:#fff9c4,stroke:#fbc02d,stroke-width:2px; User([用户输入]) --> IntentAgent["【意图解析 Agent（轻量 LLM）】"] IntentAgent --> TripObject["【结构化旅行意图对象 TripIntent】"] TripObject --> Router["【规则路由 & 并行调度层（非 LLM）】"] %% 并行层 subgraph ParallelExecution [并行执行层] direction LR Attraction["景点 Agent"] Weather["天气 Agent"] Hotel["住宿 Agent"] Transport["交通 Agent"] end Router --> Attraction Router --> Weather Router --> Hotel Router --> Transport %% 整合层 Attraction --> Aggregator["【行程整合 Agent（LLM，仅一次）】"] Weather --> Aggregator Hotel --> Aggregator Transport --> Aggregator Aggregator --> Output([生成最终行程方案]) %% 应用样式 class IntentAgent,Aggregator llmNode; class Router logicNode; class Attraction,Weather,Hotel,Transport parallelNode;

3.1 工作流规则

工作流应遵循以下规则，这一点在旅行搭子这种多轮、多条件场景里非常重要。

1. 模型只做判断，不做检索
2. 模型只做不确定性决策，不做确定性分发
3. 流程先行，先定义 Agent 的行为路径
4. 节点职责单一，每个节点只解决一个问题
5. 控制逻辑外置，判断和分支不塞进 Prompt

3.2 工作流结构设计

• 意图解析层 用"意图解析 Agent"替换复杂的"智能决策"节点，职责极其单一，只负责结构化，不做决策 采用轻量级 Agent。它的核心职责是"实体提取"，将模糊的自然语言转化为计算机可读的 $J\; S\; O\; N\; JSON$JSON 结构。
• 非 LLM 调度层 用"规则引擎 / DAG"替代 LLM 决策，无token成本且规则稳定可控 这是提升性能的关键。通过硬代码或规则引擎（如分支器节点）分发任务，避免了 LLM 在复杂逻辑判断上的开销和不稳定性。
• 并行执行查询型Agent 所有查询型 Agent 必须是「无状态 + 无推理」的，轻量级 Agent 提高节点处理速度，降低 LLM 推理成本 将垂直领域的任务拆分，各个 Agent 只负责自己的垂直领域（景点、天气等），大幅降低了 Token 消耗和响应延迟。
• 最终整合 用一次"高质量整合 Agent"，替代 N 次决策 仅在最后一步调用一次"重型"LLM，将碎片化的结构数据（景点列表 + 天气预报 + 酒店方案）润色并组织成具有人性的建议。

---

4. 星辰 Agent 平台工作流实战（旅行搭子）

下面进入重点：旅行搭子 Agent 的真实工作流拆解。

---

4.1 整体工作流设计思路

按照上述工作流规则搭建了对应的工作流，然后又搭建了个简版的工作流，此处介绍下简版工作流。

graph TD %% 定义样式 classDef startEnd fill:#f5f5f5,stroke:#333,stroke-width:2px; classDef safety fill:#ffebee,stroke:#c62828,stroke-width:2px; classDef agent fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px; classDef fallback fill:#fff3e0,stroke:#ef6c00,stroke-width:2px; Start([开始]) --> Audit["安全合规审核"] Audit --> Decision{"安全合规决策"} %% 分支逻辑 Decision -- "通过 (Pass)" --> SmartAgent["智能决策 Agent"] Decision -- "未通过 / 不匹配" --> FallbackLLM["兜底大模型 (Fallback LLM)"] %% 汇合结束 SmartAgent --> End([结束]) FallbackLLM --> End %% 应用样式 class Start,End startEnd; class Audit,Decision safety; class SmartAgent agent; class FallbackLLM fallback;

简版工作流中加入了1个安全合规检测，做一下风控兜底，针对涉黄涉政涉暴可返回拒绝服务的文案，或者引导到旅行的话题中来。

此处使用了智能决策节点，该节点主要依据用户选择的策略进行工具智能调度，同时根据输入的提示词，调用选定的大模型，对提示词作出回答。

Agent策略为ReACT（Reasoning + Acting）策略，用于指导大模型完成复杂任务的结构化思考和决策过程。支持Agent在思考和行动交替进行，而不是一次性输出答案

智能决策节点，支持配置对话轮数，允许携带历史对话，加强短期记忆。

支持自定义MCP服务和官方MCP、插件等。

允许配置大模型最大推理轮次一般建议大于等于工具数量。

4.2 ReACT 的工作机制

graph TD %% 定义样式 classDef userNode fill:#f5f5f5,stroke:#333,stroke-width:2px; classDef llmNode fill:#e1f5fe,stroke:#01579b,stroke-width:2px; classDef actionNode fill:#fff9c4,stroke:#fbc02d,stroke-width:2px; classDef resultNode fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px; User([用户输入]) --> Reason["LLM 推理 (Reasoning)"] %% 核心循环圈 subgraph ReActLoop [ReAct 循环] Reason --> Act["LLM 选择动作 (Acting)"] Act --> Execute["执行动作 (API/Agent/工具)"] Execute --> Observation["将动作结果反馈 (Observation)"] Observation --> Reason end %% 退出条件 Reason -- "达成目标" --> Finish([输出最终答案]) %% 应用样式 class User,Finish userNode; class Reason,Act llmNode; class Execute actionNode; class Observation resultNode;

ReACT 工作机制核心特点

• 交替循环 LLM 不是一次性输出答案，而是"思考 → 执行 → 反馈 → 再思考"
• 高可扩展性 可以接入多个外部工具，如搜索、数据库、计算器、业务 Agent。
• 推理可解释 因为每一步推理都是显式生成的，所以容易调试。

4.3 ReACT 与常规 Agent 工作流对比

特性	普通 Agent	ReACT Agent
动作顺序	单次推理输出，或串行固定调用	循环推理 + 动作决策
外部工具调用	需要外部规划好顺序	LLM 决定何时调用工具
可解释性	隐式黑盒	每一步推理可追踪
灵活性	受限于预设流程	高，可动态调整动作顺序
性能	快（少次 LLM 调用）	可能慢（多轮推理 + API调用）

4.4 工作流核心节点详解

进入星辰平台或Astron Agent，点击创建，选择创建自定义工作流

进入画布，可以看到左侧为画布节点，包括大模型、决策、知识库、分支、智能决策、工作流等。

① 开始节点：统一入口，而不是业务逻辑

• 输入：AGENT_USER_INPUT
• 只做一件事：承接用户原始输入

---

② 安全合规审核 + 决策节点（真实项目必备）

这一组节点在 Demo 里经常被忽略，但在真实产品中非常重要。

作用拆解：

• MCP 合规节点：

  • 检测涉政 / 暴恐 / 色情等

• 决策节点：

  • 根据 isError 决定后续路径

设计思路：

合规问题，直接在工作流层拦截 不要交给大模型"自觉"

---

③ 智能决策大模型（旅行搭子的核心大脑）

这是整个工作流的核心节点。

它的职责不是"写攻略"，而是：

• 判断用户意图是否明确
• 决定是否调用地图 / 天气 / 地铁工具
• 组织多轮对话节奏

这里我用了 ReACT + MCP Tools，而不是单纯生成文本。

一个很重要的经验：

真正复杂的 Agent，一定是"会用工具的"， 而不是"写得很长的"。

智能决策节点配置 （1）选择大模型 一般推荐最近发布的新模型，综合能力强和推理速度快 （2）选择携带历史对话轮数 增强 Agent 的短期记忆 （3）Agent策略选择ReACT，选择 工具、插件或MCP 服务（天气、地图等） 指导大模型规划思考链，调用外部工具来输出符合用户预期的内容 （4）系统提示词 指定智能体的角色、职责、技巧、边界、输出规范 （5）最大推理轮次 一般推荐大于等于工具或MCP服务数即可。

旅行搭子的核心Agent提示词如下

## 角色
你的名字是旅行搭子!
你的名字是旅行搭子!
你的名字是旅行搭子!
一个由讯飞平台搭建的旅行规划助手，专注于帮助用户规划他们的旅行路线、预订住宿和交通，以及提供目的地的旅游信息和建议。
## 技能
1. 制定个性化旅行计划：
- 根据用户的偏好、预算和时间限制，设计详细的旅行路线和日程安排。
- 考虑用户的兴趣爱好，推荐适合的活动和景点。
- 提供关于当地文化、风俗习惯和必尝美食的信息。
2. 预订服务：
- 协助用户预订机票、酒店和其他交通工具。
- 比较不同供应商的价格和服务，帮助用户找到性价比最高的选项。
- 提供预订确认信息和管理用户的预订记录。
3. 提供实时旅行建议：
- 根据天气变化、节假日或其他突发事件，及时调整旅行计划。
- 在旅途中为用户提供实时支持，解答任何关于行程的问题。
- 分享实用的旅行小贴士和应急联系方式。
## 规则：
-请仔细分析用户的【输入信息】，尤其是用户的信息可能不是很全面模糊的时候，你应该尽量推测用户的情况，并且根据技能要求进行输出结果。
- 去AI味引导用户多轮对话，建议3-5次对话。理解用户意图后输出旅行规划。
## 限制
- 只讨论与旅行规划相关的内容，拒绝回答与旅行规划无关的话题。
- 所有的输出内容必须按照给定的格式进行组织，不能偏离框架要求。
- 提供的旅行建议应基于公开可获取的信息，不涉及个人隐私或敏感数据。

---

④ 兜底大模型节点：不要高估主 Agent 的覆盖率

现实情况是：

• 用户会乱问
• 会偏题
• 会突然换话题

兜底节点的存在意义只有一个：

"别让用户无响应。"

哪怕只是一个基础回答，也比流程中断要好。

---

⑤ 结束节点：结构化输出，而不是随便 return

结束节点里，我保留了三个输出：

• output：最终给用户的结果
• finalText：兜底输出
• thinking：Agent 的推理内容（调试用）

这个设计对后期：

• 调试
• 监控
• 行为分析

非常有帮助。

---

4.5 Astron Agent 工作流高级配置

• 高级设置 工作流编排页面，高级配置支持设置智能体的对话开场白。 设置开场白预留问题，增加用户交互体验，新用户一般会选择预留问题来观察智能体的问答质量。 开启下一步问题建议，会在一次对话后，带出几个推荐问题。
• 调试 点击调试，可以在编排工作流的界面，验证工作流的工作情况，Agent的问答质量是否符合预期等
• 发布 支持发布到星辰智能体广场，被其他用户搜索、访问、使用。

4.6 旅行搭子工作流的几个设计模式

这是我在这个项目里反复验证过的几个模式。

---

模式一：先判断，再执行

• 不清楚 → 追问
• 不合规 → 拦截
• 不匹配 → 兜底

模式二：控制逻辑永远不写进 Prompt

• 判断写在「决策节点」
• Prompt 只关注"怎么回答"

模式三：核心能力节点 ≤ 1 个

旅行搭子里：

• 一个智能决策 Agent
• 其他都是辅助节点

---

4.7 工作流优化经验（踩坑总结）

如果你也准备搭类似的 Agent，这几条建议很实用：

• 一个节点做超过一件事，一定会后悔
• 工作流超过 7 个节点，就该考虑拆层
• 不要指望模型"自己判断要不要问用户"
• 中间状态一定要结构化，不要自然语言

---

5. 旅行搭子 Pro 运行效果图

旅行搭子欢迎语页面 智能决策节点思考链，调用MCP服务查询目的地天气、景点推荐界面 工作流 Agent 多轮沟通后输出行程规划界面

用户意图识别，非旅行规划问题兜底助手界面

6. 如何基于 Astron 创建自己的 Agent 工作流

如果你想从 0 开始复刻一套类似的工作流，我的建议流程是：

1. 先画流程图，不要写 Prompt
2. 明确： 哪些是判断 哪些是执行
3. 每个节点回答一个问题： 如果这个节点出错，会发生什么？
4. 最后才去优化 Prompt 表达

你会发现，工作流一旦清晰，Prompt 反而不难写。

Powered By niaonao