做文旅 AI Agent 时，我开始怀疑：每个需求都需要 Agent 吗？

一开始接触“做一个文旅智能体”这种需求，很容易从模型、Prompt 和知识库出发：上传一批目的地资料，再让它像导游一样回答问题。

后来整理这段经历时，我更关心一个更靠前的问题：到底哪些任务真的需要 Agent 自主决策？

先把问题分成三类

文旅场景里的不同提问其实差别很大：

• 解释景点开放时间或介绍历史文化：更接近可检索的事实问答，需要明确来源与时效。
• 计算旅行预算、对比交通或酒店费用：更接近结构化数据查询和规则计算，不该由模型凭感觉给数字。
• 需要在不完整约束下连续询问偏好、选择路线、调用多种工具：才可能值得用 Workflow 或 Agent 执行多步任务。

慢慢地，我形成了一个判断：先限定任务，再补必要的数据和工具。不要把“能对话”本身当成业务验收。

Workflow 比 Agent 笨吗？

未必。一个步骤确定的流程——先获取意图，再检索资料，必要时调用价格数据，最后输出一个有来源的计划——完全可以使用编排好的 Workflow。它可观察、可重放，也更容易给每一步设失败边界。

当下一步高度依赖工具结果、不能预先写死时，才考虑允许模型进入受控的 Agent 决策循环。增加自主性需要一并增加停止条件、次数/成本预算、权限判断和失败处理，并不是免费升级。

Memory、知识库与运行时不要混成一层

当时做架构学习，我也经常把“聊天记录”“用户长期偏好”“工具执行状态”统称为记忆。后来我倾向于分开：

• 会话上下文：解释这一轮为什么问这个问题；
• 检索的知识：景点、交通、政策和其他来源材料；
• Workflow/Agent State：目前在哪个节点、工具是否已经执行；
• 跨任务偏好：用户常用的交通方式等，需要有有效期与更新机制。

这些东西的数据来源和可靠性不同。把它们混在一起，模型可能把一句过时回答当成业务事实，或者在重试时重复执行工具。

怎么知道它真的有用？

当时我主要在梳理任务边界和可验证的工作流程，而不是追求上线后的准确率指标。

我会把当时的经验抽象成一组验收问题：事实是否能追溯到来源？数值是否来自可信数据源？工具失败时会不会编造结果？能否在信息不足时提问？是否允许用户中断？如果这些问题无从验证，Prompt 再漂亮也不是完整工程闭环。

这次学习让我接受一个更朴素的顺序：先做稳定的普通应用；只有业务确实需要动态决策，再让模型接管有限步骤。