当AI agent花一小时反复打开同一封邮件却只生成一份简陋清单时，我们不得不重新审视这类工具的实用性。本文深度拆解agent工作流的核心痛点——从不可预测的成本消耗到错误累积效应，揭秘ReAct、Plan+Execute等模式在实际场景中的真实表现，为产品经理提供关键决策框架。

前阵子我让 agent 帮我整理一周邮件，本来想看看现在的工具到底能不能用。跑了快一个小时，API 账单跳了几刀，最后输出的是一份我两分钟自己就能写完的清单。中间它还反复打开了同一封邮件 4 次。

那次之后我对 agent 工作流的判断标准变了一点。

跟普通 prompt 的区别在哪

最直观的区别：普通 prompt 是一次性的——你问，它答，结束。agent 不是，它会自己决定下一步做什么，什么时候停。

这一点听起来小，影响很大。一次性 prompt 你能预测成本和时延;agent 你不能。它可能 3 步搞定，也可能跑 30 步还在原地打转。你写 prompt 的时候大概知道模型这一轮要做什么——agent 跑的时候，模型每一步都在自己判断”下一步做什么”。

中间这个”自主判断”的过程，就是 agent 工作流的核心，也是所有麻烦的来源。

几种常见模式

我自己跑过和读过的几种，各自的取舍：

• ReAct(reason + act 循环)：模型先想一下接下来做什么，然后执行一个 tool，看到结果再想下一步。最朴素也最常见。问题是容易在简单任务上绕远——本来一步能做完的，它非要 reason 一下。
• Plan + Execute：先让模型出一个计划(几步，每步做什么)，然后按计划执行。好处是可预测，坏处是计划一旦定死，中间发现新信息也不太会回头改。
• Reflection：跑完一遍，让模型自己 review 一下结果，觉得不行就重跑。能提质量，但成本翻倍。
• Multi-agent：几个 agent 各管一摊，互相传消息。听着很美，实际跑起来调试地狱。一个 agent 出错，你得追三四层调用链才知道在哪儿崩的。

我目前的默认选择是 ReAct，任务复杂到一定程度才上 Plan + Execute。Multi-agent 我只在能清晰拆出独立责任的场景才用——比如一个 agent 写代码、一个 agent 跑测试、一个 agent 看 log。能力之间有明确接缝才好拆。

真正难的是什么

模型 tool calling 已经很稳，这部分不是难点。

难的是另外几件：

• 停不下来。模型在简单任务上跑得很欢，在没头绪的任务上也跑得很欢——它很少会说”我搞不定”。你得在外面套一层最大步数、最大 token 数、超时机制。
• 错误累积。一个 agent 跑 10 步，每步 95% 准确率，整体就只有 60%。链路越长，这个问题越明显。所以能短就短，能并行就并行，不要让模型连续做十几件依赖关系强的事。
• 上下文爆炸。每一步的 tool 输出都堆进上下文里。20 步之后上下文里塞满了中间结果，模型开始忽略早期信息，或者出现奇怪的 hallucination。需要主动裁剪：每一步结束后，把无关的 tool 输出折叠掉，只留摘要。
• 调试困难。普通 prompt 出错你看一遍输入输出就知道。agent 出错你得回放整个轨迹，看它在第几步走偏的、为什么走偏。我现在的习惯是每个 tool call 前后都打 log，出问题先看完整 trace 再下结论。

什么任务真的适合 agent

复杂任务不见得就适合用 agent。我现在的经验是：

适合的——

• 步数不固定，中间需要根据结果判断下一步
• 单步可验证(写代码 + 跑测试这种，每一步有客观反馈)
• 失败成本低，可以重跑

不适合的——

• 步数固定的流程(直接写脚本)
• 需要严格审计的(agent 的不确定性会变成事故)
• 单步要花很久才能验证对错(错误会一路传到底)

很多人把”复杂”等于”应该用 agent”。其实复杂任务里相当一部分是流程明确的，这种东西用 workflow 把步骤写死比让 agent 自己规划稳定得多。LLM 在里面只负责该用判断的那几步。

这事的判断成本不在框架选择，在你愿不愿意花时间把单步先调稳。