
这半年里我连续碰到过两个 AI 自动化项目，表面上看都很适合做 Agent，最后做出来的路子却完全不同。也是在这两个项目里，我才真正把“Agent 和工作流的边界”想明白。

第一个项目是内部知识处理流程。输入是文档，输出是摘要、标签、结构化字段，再把结果入库。第二个项目是一个运维助手，目标是接收自然语言指令后去查资料、调用工具、生成处理建议。

最开始团队对这两个项目的直觉差不多：都上 Agent 吧，毕竟多步骤、会调用工具、看起来很智能。

后来回头看，第一个项目如果真按 Agent 做，八成会越做越乱；第二个项目如果只做死工作流，又会显得特别笨。这就是我现在越来越在意的判断点：不是任务里有没有模型，而是路径到底稳不稳。

## 第一个项目教会我的，是“很多流程根本不需要自主规划”

文档处理那个项目刚开始时，也有人提议让模型自动决定每一步怎么做。听上去很先进：先读文档，再判断要不要抽摘要、要不要分类、要不要纠错、最后决定怎么入库。

但我们真正把流程梳理完之后发现，这件事根本没那么开放。

它的真实链路其实很固定：

1. 读文档
2. 提取正文
3. 做字段清洗
4. 生成摘要和标签
5. 输出固定结构
6. 入库

这里面真正需要模型判断的，其实只有个别节点，比如分类和摘要；主流程完全是确定的。

我们后来没有做 Agent，而是把主干写成工作流，再在少数节点上接大模型。结果非常稳。日志清楚，失败能重跑，出了问题也知道卡在哪一步。

这次经历让我第一次明确地感觉到：多步骤不等于 Agent。一个任务就算有六七步，只要路径稳定，它本质上还是流程编排问题。

## 第二个项目让我看到，工作流也会有明显上限

运维助手那次就不一样了。

用户会问：

- “帮我看看这个服务为什么最近报警变多了”
- “对比一下昨天和今天的错误日志趋势”
- “如果我要排查支付回调失败，应该先看哪几个系统”

这种任务的特点是目标清楚，但路径不固定。不同问题，第一步就可能完全不同：

- 有的要先搜知识库
- 有的要先查监控
- 有的要先拉日志
- 有的还得根据前一步结果再决定下一步

我们最早也尝试过工作流化，结果非常别扭。因为你很难提前把所有路径都列出来。流程一旦写死，助手就会表现得像一个菜单系统：能做的事都在预设分支里，一旦用户问法稍微拐一点，就开始答非所问。

这时候 Agent 的价值才真正出来。不是因为它“更高级”，而是它确实更适合这种需要边走边判断的任务。

## 我现在判断 Agent 和工作流，基本看三件事

第一，看路径是不是稳定。

如果一个任务 80% 情况都走同样的步骤，那优先工作流。别为了“智能感”把稳定流程交给模型自由发挥。

第二，看失败成本高不高。

如果一步错了会影响订单、权限、资金、客户数据，那主干流程必须尽量写死。模型可以辅助判断，但不该掌握整个执行权。

第三，看任务是否要求探索未知信息。

如果模型需要先去搜、再比对、再决定下一步，甚至中途可能修正原计划，那才更像 Agent。

这三个问题我现在几乎每次都会问一遍，因为它们能很快帮我把“看起来都像 AI 自动化”的需求拆开。

## 很多团队会误把“多步工具调用”当成 Agent

这是我最近最常看到的一个偏差。

有些系统本质上只是：

1. 读输入
2. 调一个接口
3. 调另一个接口
4. 按模板输出结果

这当然是多步，但不等于 Agent。它没有动态规划，也没有真正的路径选择，只是流程比单步长了一点。

如果把这类流程也包装成 Agent，短期可能显得很先进，长期问题很多。因为一旦让模型自由控制原本可以确定的步骤，你就会开始面对一连串新问题：

- 工具参数为什么变了
- 为啥这次少走了一步
- 为什么昨天成功今天失败
- 失败后该从哪儿恢复

这些问题本来可以靠流程约束直接规避。

## Agent 真正难的地方，从来都不是“会不会想”，而是“出了事怎么兜”

这个认知也是我做第二个项目时被逼出来的。

在 Demo 环境里，Agent 往往看起来很聪明。它会拆任务，会总结，还会自己决定先调哪个工具。可一旦进入真实系统，你马上会碰到完全不同的问题：

- 工具返回半结构化垃圾怎么办
- 上一步失败后，状态存在谁那里
- 一个任务执行到一半中断，能不能恢复
- 模型选错工具时，系统能不能兜底

这些问题不是“提示词再写好一点”就能解决的，它们属于工程治理问题。

所以我现在看一个 Agent 系统，会特别关注这些东西：

- 工具是不是封得干净
- 每一步是否可观测
- 中间状态有没有地方落
- 失败后是否能人工接管

这些事情如果没做好，Agent 再能说，也只是一个容易失控的黑盒。

## 后来我越来越接受一种更务实的做法

很多项目其实不需要在“纯工作流”和“全自主 Agent”之间二选一。

更实用的方式通常是：

- 主干流程写死
- 把模型放在少数确实需要语义判断的位置
- 在开放型环节里再放开自主规划

比如文档项目就是工作流主导，分类和抽取节点交给模型。运维助手则是 Agent 主导，但工具权限、执行范围、输出格式仍然受系统约束。

这种做法没有那么“酷”，但很符合真实交付环境。它既不把模型压成死模板，也不把可控性一把丢掉。

## 写在最后

我现在对 Agent 和工作流的看法已经很简单了：稳定路径别装成智能，自由探索也别硬写成流程。

很多项目不是做不出 AI，而是选错了自动化层级。主干应该被写死的地方，就老老实实写死；真正需要模型判断和规划的地方，再给它空间。边界一旦分清，系统会比“全都交给模型”稳得多，也比“什么都手搓流程”灵活得多。


AI Agent 和工作流的边界：我是在两次自动化项目里把这个问题看清的


每隔一段时间，就会有人说 Prompt 工程不重要了。

理由也总是类似：

- 模型更强了
- 指令理解更好了
- 多模态更完整了
- 工具调用更成熟了

这些判断不算错，但如果因此得出“Prompt 随便写就行”，那通常会在业务落地时很快吃亏。

## Prompt 真正的价值，不是花哨，而是约束

一提到 Prompt 工程，想到的是：

- 角色扮演
- 语气模板
- 一长串提示词咒语

这些东西有时有用，但不是核心。

在真实业务里，Prompt 更重要的作用通常是三件事：

1. 定义任务边界
2. 约束输出格式
3. 降低不必要的自由发挥

大模型本质上非常擅长“补全一个看起来合理的答案”。如果你不给边界，它往往就会把“有帮助”理解成“多说一点也没关系”。

这在聊天场景可能还好，在业务系统里就不稳定了。

## 业务系统里的 Prompt，首先要解决“不要乱答”

比如一个工单分类系统，如果你的目标是输出固定标签，那么最重要的就不是“写得像资深分析师”，而是：

- 只输出枚举值
- 不要附加解释
- 信息不足时返回兜底项

例如：

```text
你需要判断用户问题所属类别。

可选类别只有：
- 退款
- 发货
- 售后
- 账户
- 其他

只返回一个类别名称，不要返回解释。
如果信息不足，返回“其他”。
```

这个 Prompt 的重点不是优雅，而是稳定。

## 输入结构比形容词更重要

不少 Prompt 效果不稳定，不是因为措辞不够“高级”，而是输入结构太乱。

例如下面两种写法：

```text
帮我总结这段内容。
```

和：

```text
任务：总结以下用户反馈
目标：提炼 3 条主要问题
输出要求：
1. 使用中文
2. 每条不超过 20 字
3. 不要复述原文

原始内容：
...
```

后者更稳定，不是因为字更多，而是因为结构更清楚。

在业务里，模型通常更怕“输入混乱”，而不是“提示词不够华丽”。

## 输出格式必须显式

如果结果要被后续程序消费，Prompt 里一定要明确输出格式。

例如：

- JSON
- Markdown 表格
- 固定字段列表
- 单标签结果

否则模型很容易：

- 多加说明文字
- 改字段名
- 改层级结构
- 在某些边缘输入下换一种表达

这些变化对人看问题不大，对程序来说却可能直接出错。

## 少承诺，多兜底

一个成熟 Prompt 的特征，不是“无论什么问题都答得像专家”，而是：

- 知道什么时候该回答
- 知道什么时候该拒答
- 知道什么时候该返回不确定

例如加入这样的约束：

- 如果缺少必要信息，明确说明信息不足
- 如果输入超出知识范围，直接返回兜底结果
- 不要猜测未提供的事实

这类约束看起来保守，但在业务里通常更值钱。

## Prompt 需要和系统设计一起看

Prompt 工程从来都不只是写一段文本。

在真实系统里，它通常要和下面这些东西一起设计：

- 上下文拼装
- 检索结果质量
- 工具调用协议
- 输出解析器
- 错误重试策略

如果上游上下文已经很差，Prompt 再精致也救不了。

反过来，如果上下文质量高、输入结构清晰、输出格式受控，Prompt 往往不需要特别花哨也能很稳定。

## 什么时候应该“少写 Prompt”

这点也很重要。

如果你发现一个 Prompt 越写越长，加入了大量例外条件、补丁规则和边缘说明，通常意味着问题不只是 Prompt 的问题，而是：

- 任务定义不清
- 类别设计有歧义
- 系统边界没划清
- 上下文输入不稳定

这时继续堆提示词，收益往往越来越低。

更有效的方式通常是回头改任务设计，而不是继续往 Prompt 里加 paragraph。

## 写在最后

到了 2025 年，Prompt 工程当然还重要，但重要的不是“提示词玄学”，而是约束设计。

如果你把 Prompt 当成系统边界的一部分，而不是一句自然语言指令，它的价值会非常稳定。真正好用的 Prompt，往往不是最花哨的，而是最清楚地告诉模型：

- 该做什么
- 不该做什么
- 输出必须长什么样


Prompt 工程在 2025 年还有价值吗：真正有用的不是技巧，而是约束


去年做一个 AI 写作辅助功能的时候，我们前后换了两次模型。第一次是因为结果不稳，第二次是因为延迟偏高。换完以后效果确实有变化，但那种“有时很好，有时很飘”的感觉一直没有消失。

最开始团队里很自然地把问题归到模型头上。毕竟结果是模型吐出来的，出问题先怀疑模型很正常。可后来排查得越多，我越觉得另一个东西更像根源：上下文。

那个功能的目标并不复杂，用户给一个主题，系统结合历史记录、模板偏好和参考资料，帮他起草一段内容。听上去很像是一个“选模型 + 写 prompt”的问题，实际做下来，最难控的反而是给模型喂什么。

## 我第一次意识到问题不在模型，是在一次线上回放里

那次用户问的是一个非常具体的问题，理论上系统应该直接围绕当前主题写。结果模型先引用了上一次会话里的偏好，又混进了一段不相干的参考资料，最后写出来的内容语气对、格式也对，但方向完全偏了。

如果只看最终结果，你会觉得是模型在胡说。可把整条输入链路拆开看，其实它只是很认真地在错误材料上做推断。

那一刻我才真正意识到：模型根本不“知道自己在哪个产品里”，它只知道当前这坨上下文长什么样。

你给它干净输入，它就大概率干净输出。

你给它混乱输入，它再强也很难一直稳。

## 上下文管理最容易出问题的地方，不是少，而是乱

最开始我们总怕模型信息不够，于是策略非常朴素：尽量多给。

历史对话带上。
用户偏好带上。
参考资料多拿几段。
系统规则写长一点。
模板说明也顺手塞进去。

表面上看很周全，实际效果却越来越不稳定。后面回头看，这种“尽量多给”的思路有两个明显问题。

第一，重要信息比例被稀释了。

用户当前真正的问题，可能只占整个上下文的一小截。模型当然能看到它，但也同样看到了很多次要甚至过期的信息。

第二，旧信息会持续污染新任务。

一旦历史里有过错误判断、过时意图或者已经无效的中间结论，它们就可能继续影响当前回答。你以为自己是在做“多轮记忆”，实际上是在把噪声不断续上去。

## 后来我们做的第一件事，不是换模型，而是拆信息层级

那次改完之后，我们不再把所有信息简单拼成长文本，而是先把上下文按层次拆开。

我现在做 AI 应用时，基本都会先把输入分成这几层：

1. 系统规则
2. 当前任务目标
3. 用户本轮输入
4. 历史记忆
5. 外部检索或工具结果

这几层最重要的价值，不是格式好看，而是你终于能问自己一句：这个信息到底为什么出现在这里？

比如：

- 系统规则是长期边界，不该混进具体任务噪声
- 当前任务目标应该比历史会话优先级更高
- 历史记忆只保留必要背景，不该变成聊天记录堆积
- 检索结果必须为当前问题服务，而不是“顺手都带上”

一旦这么拆，很多以前糊在一起的问题会立刻显形。

## 历史记忆不是越长越好，这一点我后来感受很深

做对话型 AI 功能时，最容易陷进去的就是“记忆越多越聪明”。

实际并不是这样。

我们后面专门抽了一批失败样本看，发现最容易出问题的往往不是信息太少，而是带着一堆不该留下来的历史过程：

- 上一轮试错里的错误结论
- 已经被用户否定的方向
- 某次临时偏好
- 中间工具返回的半成品数据

这些东西只要留在上下文里，模型就有可能继续把它们当真。

后来我们把历史记忆改成“只保留长期偏好和关键事实”，效果反而稳了很多。比如保留：

- 用户偏好中文输出
- 用户正在做 React 项目
- 当前会话在写技术博客

而不是把整段过程都背下去。

## 检索上下文也一样，重点不是多，而是贴题

RAG 场景下这个问题会更明显。

以前我们的做法是召回多一点，觉得总比漏掉好。结果经常出现一种情况：模型拿到了十段资料，里面只有两段真有用，剩下八段只是“看着也有点关系”。这些噪声不会直接报错，但会把注意力拉散。

后来我越来越认可一个更朴素的判断标准：

- 这段内容是不是和当前问题强相关
- 它能不能减少模型猜测

如果答案都是否定的，那它就不该进上下文。

这也是我现在看检索系统时最在意的地方。它不是负责“多给内容”，而是负责“别把不该给的内容也塞进去”。

## 工具调用结果如果不清洗，也是在制造噪声

另一个很容易被低估的点，是工具结果。

很多 Agent 类应用会把工具输出原样拼回模型，图省事，但这一步经常会埋雷。

例如一个搜索工具可能返回：

- 大量无关字段
- 多个候选结果
- 冗长元数据
- 不统一的格式

模型当然可以继续读，但这等于又把一轮筛选工作丢给它了。这样不只是浪费上下文窗口，更会让后续推理开始飘。

我们后来处理工具结果时，会先做一轮清洗：

- 只保留关键字段
- 统一格式
- 必要时做小摘要

这一步做完之后，模型输出明显稳了一截。不是因为它突然更聪明了，而是因为前面的输入终于更像人给它整理过的材料。

## 我现在看 AI 应用，越来越像在看一个信息编排系统

以前我会更多地把注意力放在模型本身：哪个版本更强，哪个延迟更低，哪个价格更合适。

现在还是会看这些，但我更先问的是：

- 当前任务到底需要哪些信息
- 这些信息谁先谁后
- 哪些该长期保留，哪些只对本轮有效
- 哪些内容可能污染后续回答

如果这些问题没想清楚，换再好的模型也很难彻底解决“有时很好，有时很怪”的波动。

## 写在最后

我现在越来越相信，AI 应用里真正难的，不是把模型接上，而是把上下文管住。

模型当然重要，但很多所谓“模型不稳定”的问题，最后都能追溯到输入组织得不够干净。谁能把对的内容、按对的层级、在对的时机交给模型，谁的系统通常就更稳。模型选型会变，上下文治理能力才是更长期的竞争力。


做 AI 应用时，为什么上下文管理比模型选型更容易决定成败


AI 应用最容易被高估的阶段，就是 Demo 阶段。

因为 Demo 天然会挑选：

- 最能体现效果的输入
- 最干净的上下文
- 最理想的执行路径

这当然能说明“系统有潜力”，但说明不了“系统已经稳定可用”。

真正要落地，一个更现实的问题是：这个系统在反复运行、面对不同输入、进入边缘场景后，还能不能保持可接受质量。

## 为什么演示效果不等于真实效果

原因很简单，真实业务里的输入不会像 Demo 一样配合你。

真实用户会：

- 描述不完整
- 问题跳跃
- 混用口语和专业词
- 给出错误信息
- 连问多个目标

如果评估数据过于理想，最终得到的不是能力判断，而是乐观幻觉。

## 有意义的评估至少要看三件事

### 1. 准确性

系统答得对不对、分类准不准、提取结果是否符合事实。

### 2. 稳定性

同类输入下输出是否波动过大，是否经常忽好忽坏。

### 3. 可复现性

你是否能解释为什么这次成功、下次失败，以及失败集中在哪些场景。

如果只有准确率，没有稳定性和可复现性，那系统仍然很难真正用于业务。

## 建评估集时，不要只挑“漂亮样本”

评估集最好至少包含三类数据：

- 常规样本
- 边缘样本
- 对抗样本

常规样本保证你知道系统在主流程里的表现。

边缘样本保证你知道它在复杂输入下的下限。

对抗样本则能帮助你发现：

- 容易误判的词
- 容易被带偏的提示
- 容易失败的工具调用路径

如果只评估“漂亮样本”，最后上线时通常会被现实教育。

## 评估指标要贴近任务本身

不少团队会问：AI 应用到底该用什么统一指标？

其实大部分时候没有统一答案，因为任务不同，指标就不同。

例如：

- 分类任务看准确率、召回率、误判类型
- 提取任务看字段正确率、漏提率、格式合法率
- 问答任务看事实一致性、引用命中率、拒答合理性
- Agent 任务看任务完成率、路径长度、失败恢复率

真正关键的是：指标能不能反映业务风险。

## 评估一定要带失败分析

很多报表会给出一个总体分数，比如 82%、87%、91%。

这对趋势判断有用，但不够指导优化。

更关键的是把失败分出来看：

- 是检索错了
- 是上下文污染了
- 是 Prompt 边界不清
- 是工具参数传错了
- 还是模型本身就难以处理

只有把失败原因拆开，你才知道下一步该优化哪里。

## 人工评估仍然有价值

虽然大家都想自动化评估，但在很多任务上，人工评审仍然非常重要。

尤其是这些场景：

- 输出质量很主观
- 结果不只是对错，而是好坏程度
- 需要结合业务背景判断

自动评估适合规模化监控，人工评估适合建立判断标准。两者最好结合，而不是互相替代。

## 一个更实用的目标：持续评估，而不是一次评估

AI 应用不是“测完一次就结束”的系统。

因为它依赖的很多变量都会变：

- 模型版本
- Prompt
- 检索内容
- 工具输出
- 用户输入分布

所以真正稳的做法是持续评估：

- 新版本上线前回归
- 核心样本集定期复跑
- 线上失败样本持续回灌

只有这样，你才知道系统是在进步，还是只是“碰巧这周看起来不错”。

## 写在最后

AI 应用评估最怕的不是分数低，而是评估方式本身无法反映真实能力。

如果你只看演示效果，很容易高估系统；如果你开始看稳定性、失败分布和可复现性，才算真正进入工程阶段。能不能落地，实际开发中不取决于最好的那次表现，而取决于最差的时候系统还能不能被信任。
