什么时候你真的需要一个 Agent：三个判断问题、替代方案与成本可靠性权衡

文档信息：本文由 AI 生成初稿；生成模型 = deepseek-chat；知识截止 = 2026-09-11；文档抓取时间 = 2026-09-10T16:40:29.316Z；建议复核周期 = 季度。

TL;DR

判断要不要 Agent，先问三个问题：任务是否多步、是否需要调用外部工具、是否需要运行时自主决策；三者同时成立才值得考虑 Agent。
只满足一两个条件时，脚本、规则引擎或单次 LLM 调用往往更便宜、更可靠、更好调试。
Agent 的代价不只是 token 费用，还有延迟放大、失败模式变多、可观测性与评测成本上升。
选型顺序建议从最简方案往上加：确定性代码 → 单次 LLM 调用 → 固定工作流（workflow）→ Agent，够用即停。
本文框架无关：不绑定任何 SDK，讨论的是任务结构与工程权衡。

前置知识

有基本编程经验，能读懂伪代码与简单的 JavaScript / Python 片段。
了解什么是 LLM 调用（把 prompt 发给模型、拿回文本），不要求用过任何 Agent 框架。
不需要：不需要读过 Agent 框架源码，不需要了解向量数据库、RAG 或 MCP 细节，本文不涉及具体实现。

零基础？先读小白故事线《小白故事线》，再回到本文做选型判断。

正文

为什么“要不要用 Agent”是个真问题

Agent 这个词在工程语境里常被当成默认答案：只要任务和 LLM 沾边，就顺手搭一个 Agent。但 Agent 不是一种能力开关，而是一种架构选择——它把控制流从你的代码里，部分交给了模型在运行时决定。

这个转移有明确的收益，也有明确的代价。收益是：当任务的步骤数、工具组合、分支条件无法在写代码时穷举，Agent 的运行时决策能覆盖你没想到的路径。代价是：你放弃了确定性——同样的输入可能走不同的路径，失败可能发生在任意一步，成本和延迟变成分布而不是常数。

所以“要不要 Agent”本质是一个任务结构问题：先看清任务长什么样，再决定把多少控制权交给模型。下面三个问题就是用来做这个判断的。

问题一：任务是不是多步的，且步数事先不确定？

第一步看任务能不能拆成有依赖关系的多个步骤，以及这些步骤的数量和顺序是否在写代码时就能确定。

如果步骤固定、顺序固定，比如“读取 CSV → 清洗 → 写入数据库”，这是流水线（pipeline），用普通代码或工作流引擎表达最清楚。
如果步骤数量随输入变化，比如“根据用户问题决定要查几次资料、查完再决定要不要继续查”，这就是动态步数，是 Agent 的典型信号。
中间地带：步骤固定但每步内容需要模型生成，比如“总结 → 翻译 → 润色”，这仍然是固定工作流，只是每步内部用了 LLM。

关键区别不在于“用没用模型”，而在于控制流由谁决定。控制流写在代码里，就是工作流；控制流由模型在运行时逐轮决定，才是 Agent。前者可预测、可测试；后者灵活但难穷举。

一个粗略的判据：如果你能画出一张带分支但节点有限的流程图，并且这张图对所有输入都成立，那你大概率不需要 Agent。

问题二：任务是否需要调用外部工具或真实世界接口？

第二步看任务是否必须与外部系统交互：查数据库、调 API、读写文件、发请求、操作浏览器。

需要工具本身不构成用 Agent 的理由。很多场景下，工具调用是确定性的：先调 A 拿 ID，再用 ID 调 B，顺序固定，参数映射固定。这种“工具编排”用代码写出来更可靠，也更容易做重试和超时控制。

Agent 真正带来增量的是工具选择的动态性：面对同一个请求，模型需要判断该调哪个工具、传什么参数、拿到结果后是否还要再调。例如一个客服助手，可能先查订单、再查物流、再决定是否发起退款——调哪个、调几次取决于中间结果。

反过来，如果工具集合很小、调用顺序固定、参数能从输入直接推导，那么一个显式的函数调用链就够了。工具调用的官方机制（如 Function Calling）本身并不要求你搭 Agent，它只是让模型能输出结构化参数；是否把多轮工具调用交给模型循环决定，才是 Agent 与非 Agent 的分界。

问题三：任务是否需要运行时自主决策？

第三步，也是最能区分“工作流”和“Agent”的一步：任务在执行过程中，是否需要模型自己判断下一步做什么、什么时候停。

需要自主决策的典型特征：

停止条件不确定：不知道要循环几次才能得到满意结果，比如“反复检索直到找到足够证据”。
分支依赖中间结果：下一步动作取决于上一步返回的内容，且分支无法提前枚举。
需要自我纠错：第一次尝试失败后，要能根据错误信息换一种策略重试。

如果这三点都不成立——流程固定、分支可枚举、失败可由代码处理——那么把控制权交给模型只会增加不确定性，不会增加能力。此时用规则引擎或显式状态机，行为可预测、可单元测试、出问题能定位到行号。

三个问题合起来看：多步且步数不定 + 需要动态选择工具 + 需要运行时决策，三者同时成立，Agent 才是划算的。只命中一个或两个，先考虑下面的替代方案。

更简单的替代方案：从下往上选

选型的原则是从最简单、最确定的方案开始，只在它明确不够用时才往上加一层。常见阶梯如下。

1. 纯确定性代码 / 脚本。 规则明确、输入输出可枚举时，直接写代码。零模型成本、零幻觉、可测试。能用 if-else 和正则解决的，不要引入 LLM。

2. 规则引擎 / 状态机。 分支多但可枚举时，用状态机或规则表表达。比脚本更易维护，行为仍然完全确定。

3. 单次 LLM 调用。 任务是“一次输入 → 一次输出”的转换时，一次调用即可：分类、抽取、摘要、改写、生成结构化 JSON。没有循环、没有工具、没有多轮，成本和延迟都是常数，失败模式单一，最容易做评测。

// 单次 LLM 调用：一次输入、一次结构化输出，无循环无工具
const res = await llm.chat({
  messages: [
    { role: "system", content: "把用户文本分类为 refund / shipping / other，只输出 JSON。" },
    { role: "user", content: userText },
  ],
  response_format: { type: "json_object" },
});
const label = JSON.parse(res.choices[0].message.content).label;

4. 固定工作流（workflow）。 步骤固定但每步需要模型时，把 LLM 调用串成代码里的流水线：抽取 → 校验 → 生成 → 审核。控制流仍在你手里，只是节点内用了模型。Anthropic 在《Building effective agents》里把这类称为 workflow，并建议优先于 Agent 使用。

5. Agent。 只有当前四层都明确无法覆盖任务的动态性时，才上 Agent：让模型在循环里自己选工具、自己决定何时停止。

这个阶梯不是“越往上越高级”，而是“越往上越贵、越难控”。停在够用的那一层，是工程判断力，不是保守。

成本与可靠性权衡

Agent 的账不能只算 token。把几类成本摊开看：

直接成本：多轮调用意味着 token 消耗随步数增长，且每轮都要带上历史上下文，成本可能比单次调用高一个数量级。截至 2026-09-11，各家 API 的计费与缓存策略不同，具体单价以官方定价页为准。
延迟：单次调用是一个往返；Agent 是 N 个串行往返，端到端延迟被放大 N 倍，且 N 不确定。对交互式场景，这常常是比费用更硬的约束。
可靠性：每一步都有失败概率，多步串联后整体成功率是各步的乘积。一个 95% 可靠的步骤，串 10 步后整体只剩约 60%。Agent 的步数由模型决定，意味着最坏情况的失败率难以预先界定。
可观测性与评测：工作流的每个节点可以单独打点、单独测试；Agent 的路径是运行时生成的，你需要轨迹（trace）级别的日志和评测集才能回答“它为什么这么做”。这套基础设施本身就是成本。
安全面：能自主调用工具的循环，也意味着错误调用会被自动放大——误删、误发、越权访问都可能在无人确认的情况下发生。OWASP 的 LLM 应用风险清单里，过度代理（Excessive Agency）就是专门针对这类问题的条目。

因此一个实用的取舍是：先用工作流拿到可预测的基线，只有当动态性带来的收益明确超过上述成本时，再引入 Agent。如果确实要上，也建议从受限版本开始——限制可用工具集、限制最大步数、对高风险动作加人工确认，把不确定性关进可控的笼子里。

一个可落地的判断流程

把前面的内容压成一张决策清单，动手前逐条过一遍：

能用确定性代码或规则解决吗？能 → 停，别用 LLM。
是“一次输入一次输出”吗？是 → 单次 LLM 调用。
步骤固定、只是每步需要模型吗？是 → 固定工作流。
步数随输入变化、需要动态选工具、需要运行时决定何时停吗？三者都“是” → 考虑 Agent。
决定上 Agent 后：能否限制工具集、步数上限、高风险动作加确认？先把边界定好再写循环。

这套流程不依赖任何框架。无论你之后用哪家的 SDK，任务结构的判断都是一样的——框架只是把循环、工具调用和上下文管理打包，不改变“这个任务到底该不该用 Agent”的答案。