最近“Agent”很火，很多团队的默认动作变成了：

只要做大模型应用，就先上 Agent。

但工程上最常见的现实是：
Agent 并没有让项目更快落地，反而带来了成本上涨、延迟变差、错误更难定位、安全面变大、评测更难做。

这篇文章不讲“Agent 框架选型”，只回答一个更现实的问题：

什么时候你不该用 Agent？
以及：不用 Agent，你该用什么替代方案？

---

0）TL;DR（先给结论）

• Agent 的价值：在“路径不确定、需要多步规划、要动态选择工具”的任务上，才可能带来收益。
• Agent 的代价：引入循环、记忆、工具执行、回退与安全控制后，复杂度指数级上升。
• 最常见误区：把“可用工作流解决的问题”硬上 Agent，结果变成“工程债 + 线上事故”。
• 建议路线：先用工作流/工具调用/检索增强做出可上线版本，再评估是否需要 Agent。

---

1）先把概念对齐：Agent 不是“更聪明的 Chat”

工程视角下，Agent 往往意味着：

• 有一个循环（loop）：思考 → 决定 → 调用工具 → 观察结果 → 再思考
• 有一组工具（tools）：搜索、DB、HTTP、工单、执行脚本……
• 有一套停止条件（stop conditions）：最大步数、预算上限、任务完成判定
• 有一套安全边界：白名单、权限、审计、脱敏、幂等、回退

也就是说：Agent 不只是“模型”，它是一套“可执行系统”。
所以它的复杂度和风险，天然高于 Chat/RAG/单次工具调用。

---

2）你不该用 Agent 的 10 个典型场景（禁用清单）

下面这些场景，Agent 往往收益为 0，复杂度却会显著上升：

1. 需求路径确定：流程固定、步骤可枚举（例如报表生成、表单填充、固定审批）
2. 任务可拆成 2–5 步工作流：用编排就够了（if/else + 工具调用）
3. 高风险写操作：下单/扣款/改库/发通知（Agent 重试放大副作用）
4. 强合规与可审计要求：需要严格可解释、可追溯（Agent 的“自发探索”难审计）
5. 延迟强约束：P95 必须很低（Agent 多轮与工具链会抬高尾延迟）
6. 预算强约束：token 必须可控（Agent 循环天然容易超预算）
7. 输入输出格式严格：JSON/表格/固定字段（优先结构化输出闭环，而不是 Agent）
8. 数据/工具权限复杂：多租户、多角色、多数据域（Agent 的权限面扩大很快）
9. 评测体系不成熟：没有离线回归集/线上指标（Agent 很难迭代，只能靠感觉）
10. 你其实只需要检索：问题的核心是“找到正确证据并回答”（优先做 RAG 链路与评测）

一句话总结：如果你现在连“单次调用 + 可观测 + 可回滚”都做不好，先别上 Agent。

---

3）一个决策树：到底要不要 Agent？

你可以用这 6 个问题快速收敛：

1. 任务路径是否不确定，必须“边做边决定下一步”？
2. 是否需要动态选择多个工具（不是固定的 1 个工具）？
3. 是否需要多步推理才能到达结果（>3 步）？
4. 是否能接受更高的延迟与成本？
5. 是否已具备权限/审计/幂等/回退等安全基础设施？
6. 是否有评测体系（离线回归 + 在线监控）？

如果 1–3 都是“否”，基本不用 Agent；
如果 1–3 是“是”，但 4–6 不具备，也不建议上（先补工程基础）。

---

4）不用 Agent，你应该用什么？（替代方案对照表）

你的真实需求	更合适的方案	为什么
固定流程、可枚举步骤	工作流编排（if/else + 工具调用）	可控、可测试、可审计
需要外部数据支撑回答	RAG（检索增强）	先解决“证据是否召回/引用正确”
需要调用 1 个确定工具	单次工具调用	复杂度低，易观测
需要稳定结构化输出	结构化输出闭环（Schema+校验+修复重试）	直接提升稳定性
需要多模型比对/路由	接入层统一 + 路由策略	先把工程摩擦降到最低

经验：多数“Agent 需求”，其实是“工作流 + RAG + 工具调用”的组合。

---

5）如果你非要做 Agent：先把“停止条件”写清楚（最小骨架）

Agent 最容易失控的点是：没有明确停止条件。
下面是一个“最小可控循环”的骨架（示意）：

from dataclasses import dataclass
from typing import Any, Dict, List, Optional
import time


@dataclass
class Budget:
    max_steps: int = 6
    max_seconds: float = 8.0
    max_total_tokens: int = 8000


def call_llm(messages: List[Dict[str, str]]) -> Dict[str, Any]:
    """
    返回示例：
    {"action":"tool","tool_name":"search","tool_args":{"q":"..."}} 或 {"action":"final","content":"..."}
    """
    return {"action": "final", "content": "stub"}


def run_tool(tool_name: str, tool_args: Dict[str, Any]) -> Dict[str, Any]:
    # TODO: 工具白名单/权限/超时/幂等/审计
    return {"ok": True, "data": {}}


def agent(user_query: str, budget: Budget) -> str:
    t0 = time.time()
    messages = [{"role": "user", "content": user_query}]

    for step in range(budget.max_steps):
        if time.time() - t0 > budget.max_seconds:
            return "超时，已降级返回（可提示用户稍后重试/转人工）。"

        decision = call_llm(messages)
        if decision.get("action") == "final":
            return decision.get("content", "")

        # 工具调用
        tool_name = decision["tool_name"]
        tool_args = decision.get("tool_args", {})
        tool_result = run_tool(tool_name, tool_args)

        messages.append({"role": "assistant", "content": str(decision)})
        messages.append({"role": "tool", "content": str(tool_result)})

    return "达到最大步数，已降级返回（可提示用户缩小问题范围）。"

你会发现：哪怕是“最小骨架”，也已经包含了超时、最大步数、工具执行与降级。
如果你对这些都没准备好，先不要上 Agent。

---

6）上线前 Checklist（建议打印）

• 明确“为什么一定要 Agent”（而不是工作流/RAG/单次工具调用）
• 停止条件：max_steps/max_seconds/budget 上限
• 工具治理：白名单、权限、超时、幂等、审计、字段投影/脱敏
• 回退策略：失败回退到更稳方案/模板/人工
• 评测：离线回归集 + 在线指标（错误率/延迟/token/工具成功率）
• 可观测：每一步决策、工具调用、回退次数都可追踪

---

7）资源区：评测/路由 Agent 时，先把接入层统一

你评估 Agent 往往需要对比不同模型、不同提示词、不同工具策略。
工程上更省事的做法是统一成 OpenAI 兼容调用方式（很多时候只改 base_url 与 api_key），便于快速做对比评测与路由试验。例如，使用支持 OpenAI 协议的大模型聚合平台（如 147API），可一键切换不同厂商模型，无需重写调用逻辑，加速 Agent 策略迭代。