很多人拿到一个需求，第一反应是「调个大模型就行」，结果发现它只会给建议、不会真的去查、去改、去跑第二遍。也有人反过来，明明只是要一段文案，却硬套一个多步 Agent，把简单活做复杂还更容易出错。这篇不聊架构名词，就用几个能对照的例子，把「问一次答一次」和「自己拆步骤、调工具、看结果再决定下一步」这两种行为摆在一起看，最后给一张判断清单，帮你决定这个活该交给谁。
很多人拿到一个需求，第一反应是「调个大模型就行」。等跑起来才发现，它只会给你建议，不会真的去查、去改、再跑第二遍。也有人反过来，明明只要一段文案，却硬搭一个多步 Agent，简单活做复杂，还更容易错。这里不去聊架构名词，就把「问一次答一次」和「自己拆步骤、调工具、看结果再决定下一步」这两种行为摊在一起看。
判断的关键不是谁更强，而是你这个任务里有没有「中间动作」，以及动作之后要不要再判断一次。下面用三个能对照的场景说清楚，最后给一张清单，帮你定这活该交给谁。
例子一：问一件「需要先查再答」的事
- 大模型的行为
- 把问题当成一次生成，答不上来就编一个像样的答案，它没有「我不知道，先去查」这一步
- Agent 的行为
- 先想清楚要查什么，发起检索或读文件，看到返回结果后要么继续查、要么得出结论再回答
- 差异的落点
- 不是谁更聪明，而是有没有「中间动作」和「拿到动作结果后再判断一次」的循环
- 不适用的情况
- 答案本来就在训练数据里、或者你只是要它改写润色，这个循环纯属浪费时间和调用次数
一个常见对照：让两者回答「我们内部文档里这个流程怎么走」。大模型没读过你的文档，它只能按常见做法给你一段听起来合理的描述；Agent 会先去读那份文档，读不到还会告诉你路径不对。差别在中间多了一步「读」。
例子二：让它「把这份表格整理好发出去」
这是最能看出区别的一类活。大模型只能输出一段文本或一段代码，它不会真的动你的文件、不会真的发出去，最后一步还是你手动复制粘贴。Agent 会去读文件、按规则清洗、调用写文件或发消息的接口，再把执行结果回报给你。
- 执行权在哪：给不给它工具、给不给它写权限，决定了它是「顾问」还是「干活的」
- 能不能闭环：真干活需要「读—改—写—回报」四步都在它手里，少一步你就得补手工
- 出错是否可查：Agent 应把每步的输入输出留痕，否则出了问题你根本不知道错在哪一步
风险提示也在这里。给了写权限就要给它兜底，比如先写到临时文件、让人确认一步再落地，别一上来就给生产环境的写权限。判断标准很简单：这个动作错了能不能撤回？不能撤回的，就别让它自动执行。
例子三：中间出错时两者的反应
| 环节 | 大模型直调 | Agent |
|---|---|---|
| 第一步就错 | 不知道，后面全跟着错 | 能看到结果异常，触发换做法或重试 |
| 返回为空 | 照样往下编 | 可以判定为失败，改查询条件再试 |
| 格式不对 | 输出一段漂亮但没法用的东西 | 可校验后重排，或退回上一步 |
| 你要做的 | 重问一遍，重新组织输入 | 设好上限，看它绕圈就人工接管 |
这也是 Agent 最容易翻车的地方：没有重试上限和终止条件，它会一直绕圈，把额度烧掉还给你一个半成品。所以可执行动作是给它设三条硬规则：最大步数、单步超时、以及「连续两次同一错误就停下报给人」。
- 先定上限在配置里写死最大步数，到点就停，不要靠模型自己觉得「差不多了」
- 加错误熔断同一类报错连续出现两次，立刻终止并输出中间状态，让人接手
- 留执行日志把这轮跑了几步、每步调了什么、返回什么记下来，失败率才有得算
怎么判断你这个活该用哪一边
- 要单次产出、结果能一眼验对（写文案、翻译、解释概念、改一段代码）——大模型直调就够
- 任务需要外部信息、需要多步、需要动别的系统、步骤之间要按结果分岔——才考虑 Agent
- 中间标准：把任务拆开数一下「需要跟外部打交道的次数」，超过一两次，直调的体验就开始变差
- 成本与稳定性：Agent 的调用次数不可控，先小范围试跑，记录平均步数和失败率，再决定要不要上生产
价格和额度这类动态信息不要凭印象，具体口径到站内换算工具和官方价目页核对当时的数字，不同中转站的计价方式也会差不少。
几个容易搞混的地方
- 接了函数调用
- 不等于 Agent，能调工具只是能力，会不会自己决定调哪个、调几次才是分界
- 多轮对话
- 也不等于 Agent，聊天记录长只是上下文长，不代表它在执行循环
- Agent 比大模型贵
- 不准确，它是模型加一套执行框架，框架部分的工程量和排查成本往往比模型本身更高
- 想更准就上 Agent
- 不对，先考虑提示词和检索，这两样便宜且好排查，想系统看几种手段的分界，站内有专门对照文章
最后提醒一个不适用场景：如果任务本身没有明确的完成标准，比如「帮我看看这个方向行不行」，那多用 Agent 也只是多绕几圈。这类开放式问题，先让人和模型聊几轮，比直接上执行框架划算。
下一步如果你正在选型，先去站内工具目录挑一个能小范围试跑的入口，用它记录平均步数和失败率；再对照中转站的可用性检测结果看稳定性，两边数字对上了再上生产。→常见问题
同一个模型，套上 Agent 框架就会变聪明吗？
不会更聪明，只是多了「可以动手」和「可以看结果再改」的能力。原本模型不会的事还是不会，它只是多了查资料、跑代码这些外部手段。反过来说，如果任务本身不需要外部动作，套框架只会增加调用次数、延迟和出错环节，效果可能还不如直接问一次。
我怎么知道自己的需求到底要不要上 Agent？
抓一个判断点：做完这件事，中间需不需要跟外部世界打几次交道。零次或一次，直调大模型就够；需要查资料、读文件、跑代码、调接口，而且后一步怎么做要看前一步的结果，那就值得上 Agent。拿不准就先按最笨的方式手动跑一遍，数一下中间有几个动作。
Agent 跑偏了、一直循环怎么办？
先加硬约束再看效果：限定最大步数、单步超时、同一错误连续出现两次就停下来报给人。同时把每步的输入输出记下来，翻日志看它是从第几步开始偏的——多数循环是因为工具返回格式和它预期的不一样，或者没有明确的「做完」判断条件。这些约束要在上线前就设好，别等烧完额度再补。
