1. 先说结论

「Agent 开发」听起来很酷：让大模型自己规划、自己调工具、自己反思、自己循环，直到把任务做完。但在真实工程里，大多数业务场景并不适合一上来就走 Agent 路线。

更务实的做法通常是：先把任务拆成确定性的工作流（Workflow），只在真正需要动态决策的环节引入模型。Agent 是最后的手段，而不是默认的起点。

下面从几个维度说明为什么不推荐。

2. 不确定性被放大

普通 LLM 调用是「一次输入 → 一次输出」，不确定性只发生在一个点上，可以用温度、提示词、结构化输出、校验重试来控制。

而 Agent 是一个循环：每一步都要模型决定「下一步做什么」，任何一步的偏差都会进入下一轮，误差会累积和放大。

单次调用：输入 → 输出            （1 个不确定点）
Agent：  输入 → 决策 → 工具 → 观察 → 决策 → 工具 → ... → 输出
                ↑ 每一步都是一个不确定点，且相互耦合

结果就是：同一个输入，跑两次可能得到完全不同的路径和结果。对需要可复现、可审计的业务来说，这是硬伤。

3. 调试与可观测性极差

传统程序出错，你能拿到堆栈、断点、日志，定位到具体某一行。

Agent 出错时，你面对的是：

• 一段自然语言推理过程，看起来「很有道理」但结论是错的；
• 工具调用参数是模型临时生成的，可能格式对、语义错；
• 失败发生在第 7 轮，但根因在第 2 轮的一次误判；
• 同样的 prompt，昨天能跑通，今天跑不通。

要把它调好，你需要完整的 trace、每步的输入输出、token 消耗、工具返回，工程量远超写一个普通服务。没有成熟的观测体系，Agent 基本无法维护。

4. 成本与延迟不可控

Agent 的循环次数由模型决定，这意味着：

维度	普通调用	Agent
调用次数	1 次	不确定，可能 3 次也可能 30 次
延迟	秒级	秒级到分钟级，长尾严重
成本	可预估	波动大，容易失控
失败重试	简单	重试成本成倍增加

对 C 端产品来说，用户等 30 秒才出结果基本等于流失；对 B 端来说，账单不可预测也很难向业务方交代。

5. 错误处理与边界情况爆炸

Agent 要「自主」，就必须给它工具。工具一多，组合就爆炸：

• 工具调用顺序错了怎么办？
• 参数缺失或类型不对怎么办？
• 工具超时、返回空、返回脏数据怎么办？
• 模型陷入死循环、反复调用同一个工具怎么办？
• 中途需要人工确认，怎么中断和恢复？

这些在 Workflow 里都是显式分支，写清楚就行；在 Agent 里则要靠 prompt 和护栏去「祈祷」模型别犯。工程上，显式代码永远比隐式推理更可靠。

6. 权限与安全风险

Agent 能自主调用工具，就意味着它能自主执行副作用：写数据库、发消息、下单、删文件。

一旦模型判断失误或被提示词注入攻击，后果是真实且不可逆的。生产环境里，你不得不加大量审批、白名单、沙箱，而这些限制又会削弱 Agent 的「自主性」——最后往往退化成一个受限的 Workflow，那还不如一开始就写 Workflow。

7. 大多数任务其实不需要 Agent

回头看真实需求，绝大多数可以归为几类固定形态：

• 信息抽取 / 分类 / 改写：一次调用即可；
• 多步骤但步骤固定：用 Workflow 串起来，每步一个模型调用；
• 需要检索：RAG，检索是确定性的，生成是一次调用；
• 需要调用少量工具：Function Calling，模型选工具，但流程由代码控制。

真正需要「动态规划、路径不固定、步数不确定」的任务，其实很少。为了少数场景引入 Agent 的复杂度，性价比极低。

8. 什么时候才考虑 Agent

不是说 Agent 一无是处，而是它有明确的适用边界：

• 任务路径确实无法预先枚举，且失败代价可接受；
• 有完善的 trace、评测集和回滚机制；
• 工具副作用可控，或有人工确认环节；
• 有足够的预算和延迟容忍度。

即使满足，也建议从 Workflow 起步，逐步把某个环节替换成 Agent，而不是一上来就全自主。

9. 小结

不推荐走 Agent 开发，核心不是「Agent 不好」，而是：

它的复杂度、不确定性、成本和维护代价，与大多数业务的实际收益不匹配。

先用确定性的 Workflow 把问题解决，把模型放在它最擅长的地方——理解与生成，而不是让它去当调度器。等业务真的复杂到 Workflow 撑不住时，再考虑 Agent，那时你也有能力驾驭它。