为什么需要讨论这个问题
2026 年，Agent 已经从概念验证走向生产。但在一线落地中，一个反复出现的问题是：团队把本该用 if-else 解决的事情交给了 LLM Agent，结果得到的是更高的延迟、更难调试的系统、以及无法预测的成本。
Agent 的核心价值在于处理开放域、模糊输入、需要多步推理的任务。如果你的问题是封闭的、确定性的、可穷举的，引入 Agent 就是在用大炮打蚊子。
决策框架：5 个维度判断是否需要 Agent
在决定是否引入 Agent 前，用这个框架快速评估：
| 维度 | 适合 Agent | 适合传统工程 |
|---|---|---|
| 输入确定性 | 自然语言、模糊意图 | 结构化参数、枚举值 |
| 分支复杂度 | 组合爆炸、无法穷举 | 有限分支、可用规则覆盖 |
| 容错要求 | 允许 80-95% 准确率 | 要求 100% 正确（金融、医疗） |
| 延迟敏感度 | 可接受 2-10s 响应 | 要求 <200ms |
| 可解释性 | 过程可追溯即可 | 需要确定性审计链 |
经验法则：如果 5 个维度中有 3 个以上落在”适合传统工程”列，就不该用 Agent。
6 个不该用 Agent 的典型场景
场景 1：确定性的数据转换
# ❌ 用 Agent：把 CSV 日期格式从 MM/DD/YYYY 转成 ISO
# "请帮我把这个日期转换格式" → LLM 调用 → 解析 → 输出
# 成本：~0.002$/次，延迟 800ms，偶尔格式错误
# ✅ 传统方案：3 行代码，确定性，零成本
from datetime import datetime
def convert_date(date_str: str) -> str:
return datetime.strptime(date_str, "%m/%d/%Y").strftime("%Y-%m-%d")判断依据：输入格式固定、转换规则明确、零容错空间。
场景 2：有限状态机可覆盖的工作流
订单状态流转（待支付 → 已支付 → 已发货 → 已完成 → 退款中）这类有限状态的业务逻辑，用 Agent 处理是典型的过度设计：
# ❌ Agent 方案：LLM 判断"当前状态能不能流转到目标状态"
# 问题：hallucination 可能让非法状态转换通过
# ✅ 状态机方案：穷举合法转换，编译期保证正确性
VALID_TRANSITIONS = {
"pending": ["paid", "cancelled"],
"paid": ["shipped", "refunding"],
"shipped": ["completed", "refunding"],
"completed": ["refunding"],
"refunding": ["refunded"],
}
def can_transition(current: str, target: str) -> bool:
return target in VALID_TRANSITIONS.get(current, [])场景 3：高频低价值的模板填充
发送通知邮件、生成固定格式报表、填充合同模板——这些任务的”智能”部分接近于零。每次调用 LLM 去”生成”一封格式固定的邮件，本质上是在为确定性任务支付不确定性的代价。
// ❌ Agent："请帮用户生成一封发货通知邮件"
// 成本：0.003$/封 × 10000 封/天 = 30$/天，还有格式出错风险
// ✅ 模板引擎：Mustache / Jinja2，零边际成本
const template = `尊敬的 {{name}}，您的订单 {{orderId}} 已发货，
快递单号：{{trackingNo}}，预计 {{eta}} 送达。`;场景 4：需要硬实时保证的路径
交易撮合、实时风控决策（<10ms）、高频 API 网关路由——这些场景对延迟的要求决定了 LLM 不可能参与热路径。即使是最快的模型推理也需要 200ms+。
场景 5：合规性要求确定性审计的环节
银行交易记录、医疗处方校验、税务计算——这些场景需要 每一步决策都可追溯到明确的规则。Agent 的”思考过程”不能替代合规审计链。
场景 6：团队没有 LLM 运维能力
Agent 投产后需要持续的 prompt 调优、模型版本管理、成本监控、异常处理。如果团队没有这些能力储备，Agent 上线后会迅速变成一个黑盒——出了问题没人能修。
混合架构：Agent 只负责”模糊地带”
最佳实践不是二选一，而是让 Agent 只处理确定性工程无法覆盖的部分：
用户输入（自然语言）
│
▼
┌─────────────┐
│ 意图识别 │ ← Agent（模糊 → 结构化）
└─────────────┘
│
▼ 结构化指令
┌─────────────┐
│ 业务逻辑 │ ← 传统代码（确定性执行）
└─────────────┘
│
▼
┌─────────────┐
│ 结果包装 │ ← 模板 or Agent（看是否需要个性化表达）
└─────────────┘这个模式的核心思想：Agent 做翻译（自然语言 → 结构化指令），传统代码做执行。这样你得到了 Agent 的灵活性，又保留了确定性系统的可靠性。
# 实战示例：Agent 识别意图，传统代码执行
async def handle_user_request(user_input: str):
# Agent 负责：理解模糊输入
intent = await llm_classify(user_input)
# intent = {"action": "refund", "order_id": "ORD-123", "reason": "quality"}
# 确定性代码负责：执行业务逻辑
if intent["action"] == "refund":
result = refund_service.process(
order_id=intent["order_id"],
reason=intent["reason"]
)
# 校验、状态机、数据库操作——全是确定性的
return result选型 Checklist
在项目启动时，用这个清单过一遍每个功能模块：
- 输入是自然语言还是结构化数据？
- 业务规则能否在 50 个 if-else 内穷举？
- 错误结果的代价是什么？（用户体验差 vs 资金损失）
- 延迟预算是多少？
- 团队是否有 LLM 运维能力（prompt 调优、成本监控、AB 测试）？
- 这个功能的调用频率和单次成本算出的月账单可接受吗？
总结
Agent 是工程师工具箱里的一把锤子——一把非常昂贵、偶尔走火的锤子。用对地方它威力巨大，用错地方它只会增加系统的不确定性和运维负担。
三条底线原则：
- 确定性优先：能用规则解决的，不要用概率解决
- Agent 做翻译，代码做执行：把 Agent 限制在”理解”层，不让它参与”执行”层
- 算账：每个 Agent 调用都有成本，乘以调用频率后看月账单是否合理
把 Agent 用在刀刃上，才是真正的 AI 工程化。