Agent 不是越聪明越好，而是越克制越好

一、前言

当简单问题遇上"智能" Agent

在我们的智能房产推荐系统中，遇到了一个让人哭笑不得的问题。

用户问题：「帮我查一下朝阳区 3 居室的平均房价」

这是一个非常简单的查询需求，理论上一条 SQL 就能搞定：

SELECT AVG(price) FROM houses 
WHERE district = '朝阳区' AND bedrooms = 3;

但我们的 Agent 做了什么？

1. 步骤 1：拆解问题 —— “用户想要统计信息，需要聚合查询”
2. 步骤 2：规划执行路径 —— “先查 Schema，再构建查询，最后验证结果”
3. 步骤 3：查询数据库 Schema —— 获取表结构和字段信息
4. 步骤 4：反思规划 —— “是否需要考虑时间范围？是否需要过滤异常值？”
5. 步骤 5：调用查询工具 —— 执行 SQL
6. 步骤 6：结果校验 —— “结果是否合理？是否需要二次确认？”
7. 步骤 7：格式化输出 —— 生成用户友好的回答
8. 步骤 8：总结反思 —— “本次查询是否完整？”

最终结果：

• Token 消耗：从 200 涨到 600+（3 倍）
• 响应时间：从 1.2 秒涨到 3.5 秒（翻倍）
• API 成本：单次查询成本增加 280%
• 准确率：并没有提升，反而因为步骤过多增加了失败风险

问题来了：为什么一个简单问题，Agent 要"用力过猛"？

这不是个例。在我们的生产环境中，超过 60% 的简单查询都被过度复杂化了。更讽刺的是，这些"智能规划"并没有带来价值，反而成了系统的负担。

---

二、什么是"认知过拟合"？

一个原创概念

我把这种现象定义为 “认知过拟合”（Cognitive Overfitting）：

认知过拟合 = 模型在简单任务上使用了过度复杂的推理结构，导致资源浪费和系统不稳定，而准确率并未提升。

这和数据工程中的"过度设计"非常相似：

类比：机器学习中的过拟合

• 预测房价，只有 100 条训练数据
• 却用了：深度神经网络 + 50 层隐藏层 + 复杂的特征工程
• 结果：训练集准确率 99%，测试集准确率 60%，还不如线性回归稳定

核心观点：

Agent 的问题不是能力不足，而是能力过剩。

就像给一个小学生配备了博士生的思维工具，结果是：

• 简单问题被复杂化
• 执行效率下降
• 出错概率增加
• 成本不可控

---

三、为什么会出现"过度思考"？

这是文章的核心分析部分。认知过拟合不是偶然现象，而是多重因素共同作用的结果。

1️⃣ 模型天性：讨好型推理

LLM 有一个天生的倾向：展示推理过程以显得"聪明"。

但这是个陷阱。

模型的默认行为：

• 多解释 —— “让我详细说明一下…”
• 多步骤 —— “首先…然后…接着…最后…”
• 多展开 —— “我们需要考虑以下几个方面…”
• 多反思 —— “让我再检查一下…”

为什么会这样？

因为 LLM 的训练目标是：生成看起来合理的过程，而不是 最短可执行路径。

在训练数据中，那些详细展开、逐步推理的回答往往被标注为"高质量"。模型学到的是：

• 复杂 = 专业
• 详细 = 可靠
• 多步骤 = 严谨

但这是错的。

在工程场景中，我们需要的是：

• 简洁 = 高效
• 直接 = 可控
• 最短路径 = 最稳定

一个残酷的事实：

大多数人被 Chain of Thought 误导了。
CoT 适合复杂推理，但被滥用到了所有场景。

2️⃣ Prompt 诱导：无意中打开了"慢路径"

很多工程师在设计 Prompt 时，会无意中强化这种倾向：

典型的诱导性 Prompt：

请详细分析用户问题
逐步思考并规划执行步骤
拆解任务并说明理由
在执行前进行充分的反思

这些指令等于在强行打开 LLM 的"慢路径"（System 2 思维）。

问题在于：不是所有问题都需要慢路径。

就像开车：

• 高速公路 → 快速直达（简单查询）
• 山路十八弯 → 小心驾驶（复杂推理）

但我们的 Prompt 设计，让 Agent 在高速公路上也开启了"山路模式"。

3️⃣ Agent 架构：默认"全智能"

很多 Agent 系统的架构设计是：

任何问题 → 统一规划流程 → ReAct 循环 → 工具调用 → 反思验证

我要说一个不受欢迎的观点：

80% 的 Agent 架构设计是伪需求。

问题：

• 不区分简单 vs 复杂
• 没有"复杂度分级"
• 所有问题都走同一套流程

这就像：

• 不管是买瓶水还是买房子
• 都要走同样的决策流程
• 都要开会、调研、论证、审批

更直白地说：

ReAct 在生产环境里不应该是默认解。
它应该是复杂问题的备选方案。

结果：简单问题被拖慢，复杂问题也没做好。

4️⃣ 缺少收敛约束：Agent 不知道何时停止

典型的 Agent 系统缺少以下约束：

❌ 没有限制最大步骤数

• Agent 可以无限规划、反思、调用工具
• 没有"到此为止"的机制

❌ 没有终止判断

• 什么时候算"完成"？
• 什么时候该"停止优化"？
• 标准不清晰

❌ 没有成本上限

• Token 可以无限消耗
• 时间可以无限延长
• 没有预算控制

结果：Agent 陷入"永动机"模式，不知道什么时候该停。

---

四、工程后果：它到底伤害了什么?

认知过拟合不是理论问题，而是实实在在的工程灾难。

1️⃣ 成本失控

Token 成本飙升：

• 简单查询：200 tokens → 600 tokens（3x）
• 复杂推理：1000 tokens → 3000+ tokens（3x+）
• 多轮对话：成本呈指数级增长

多轮规划叠加：

规划 (200 tokens) 
  → 工具调用 (150 tokens) 
  → 反思 (180 tokens) 
  → 再规划 (200 tokens) 
  → 再调用 (150 tokens)
  → 最终输出 (120 tokens)
= 1000 tokens（本可以 200 tokens 搞定）

在我们的系统中，认知过拟合导致每月 API 成本增加了 40%。

2️⃣ 延迟上升

典型的延迟链路：

规划 (0.8s) 
  → 工具调用 (0.5s) 
  → 反思 (0.7s) 
  → 再规划 (0.8s) 
  → 再调用 (0.5s)
= 3.3s（本可以 1.2s 完成）

用户体验变差：

• 简单问题等待时间过长
• 用户失去耐心
• 系统显得"笨重"

3️⃣ 不可预测性增强

这是最隐蔽但最致命的问题。

一个关键洞察：

复杂度 = 失败概率的放大器

为什么？

假设每个步骤的成功率是 95%：

• 1 步流程：成功率 = 95%
• 3 步流程：成功率 = 95%³ = 85.7%
• 8 步流程：成功率 = 95%⁸ = 66.3%

路径越长：

• 失败点越多
• 不稳定性越高
• Debug 难度越大

在生产环境中，我们发现：

• 简单查询（1-2 步）：成功率 96%
• 复杂规划（6-8 步）：成功率 68%

更糟糕的是：失败原因难以定位，因为步骤太多了。

---

五、解决方案：如何控制 Agent 的"认知复杂度"？

这是文章最有价值的部分。以下是四种经过实战验证的方法。

方法一：复杂度分级（快路径 vs 慢路径）

核心思想：不要让所有问题都走智能。

一个明确的立场：

多数 Agent 设计的第一个错误，就是假设所有问题都需要"智能"。

类似数据库查询优化：

• 简单查询 → 直接执行（快路径）
• 复杂查询 → 查询优化器（慢路径）

在 Agent 中的实现：

def route_query(user_query):
    complexity = estimate_complexity(user_query)
    
    if complexity == "SIMPLE":
        # 快路径：直接调用 Skill
        # 不需要 Agent，不需要规划
        return direct_skill_call(user_query)
    
    elif complexity == "MEDIUM":
        # 中路径：简化规划（最多 3 步）
        return simplified_agent(user_query, max_steps=3)
    
    else:  # COMPLEX
        # 慢路径：完整 Agent 规划
        # 只有这里才用 ReAct
        return full_agent(user_query)

复杂度判断标准：

• 关键词匹配（“查询”、“统计” → 简单）
• 意图分类（单一意图 → 简单，多意图 → 复杂）
• 历史数据（类似问题的平均步骤数）

实际效果：

• 70% 的查询走快路径
• 平均响应时间降低 60%
• 成本降低 55%

关键洞察：

"智能"往往掩盖工程问题。
很多时候，你需要的不是更聪明的 Agent，而是更好的路由。

方法二：限制规划深度

核心思想：让系统"克制"。

对照：不成熟 Agent vs 成熟 Agent

维度	不成熟 Agent	成熟 Agent
规划策略	每个问题都规划	只对复杂问题规划
反思机制	无限制反思	明确终止条件（最多 1 次）
成本控制	无预算	成本可控（Token/时间上限）
步骤限制	无限制	最多 3-5 步
工具调用	可重复调用	禁止重复调用同一工具
失败处理	不断重试	快速失败，返回部分结果
可观测性	黑盒	完整日志，可追溯

具体约束：

class ConstrainedAgent:
    def __init__(self):
        self.max_steps = 3  # 最多 3 步
        self.max_tool_calls = 2  # 最多调用 2 次工具
        self.max_reflections = 1  # 最多反思 1 次
        
    def execute(self, query):
        steps = 0
        while not self.is_complete() and steps < self.max_steps:
            action = self.plan_next_action()
            result = self.execute_action(action)
            steps += 1
            
            if steps >= self.max_steps:
                return self.force_conclusion(result)

禁止的行为：

• ❌ 重复调用同一个工具
• ❌ 反思超过一次
• ❌ 规划超过 3 层

为什么有效？

因为它强制 Agent 做出选择：

• 不能"什么都想做"
• 必须"抓住重点"
• 学会"适可而止"

方法三：显式成本预算

核心思想：用成本约束行为。

这在企业场景非常现实。

实现方式：

class BudgetedAgent:
    def __init__(self, max_tokens=500, max_time=2.0):
        self.max_tokens = max_tokens
        self.max_time = max_time
        self.used_tokens = 0
        self.start_time = time.time()
        
    def can_continue(self):
        if self.used_tokens >= self.max_tokens:
            return False
        if time.time() - self.start_time >= self.max_time:
            return False
        return True
        
    def execute_step(self, action):
        if not self.can_continue():
            return self.emergency_conclusion()
        
        result = self.call_llm(action)
        self.used_tokens += result.token_count
        return result

预算设置：

• 简单查询：500 tokens, 2 秒
• 中等复杂：1000 tokens, 5 秒
• 复杂推理：2000 tokens, 10 秒

超限处理：

• 直接终止
• 返回当前最佳结果
• 记录日志供后续优化

实际效果：

• 成本可控
• 延迟可预测
• 强制 Agent 优先处理核心任务

方法四：Eval 驱动的能力削减

核心思想：不是不断叠加能力，而是删除无效复杂度。

这和数据工程的"删字段、删中间层"非常像。

方法：

1️⃣ 统计每个步骤的价值

# 对比实验
results_with_reflection = run_agent(enable_reflection=True)
results_without_reflection = run_agent(enable_reflection=False)

# 计算价值
value_of_reflection = (
    results_with_reflection.accuracy 
    - results_without_reflection.accuracy
) / results_with_reflection.cost

2️⃣ 删除低价值步骤

我们的发现：

• Schema 查询：价值高（保留）
• 第一次反思：价值中等（保留）
• 第二次反思：价值接近 0（删除）
• 结果校验：价值低（删除）

3️⃣ 持续优化

# 每周运行 Eval
weekly_eval = {
    "step_1_planning": {"accuracy_gain": 0.05, "cost": 100},
    "step_2_tool_call": {"accuracy_gain": 0.15, "cost": 50},
    "step_3_reflection": {"accuracy_gain": 0.02, "cost": 80},
    "step_4_verification": {"accuracy_gain": 0.01, "cost": 60},
}

# 计算 ROI
for step, metrics in weekly_eval.items():
    roi = metrics["accuracy_gain"] / metrics["cost"]
    if roi < threshold:
        disable_step(step)

实际效果：

• 删除了 40% 的"智能"步骤
• 准确率下降不到 2%
• 成本降低 35%
• 系统更稳定

---

六、能力不是越多越好

一个反直觉的真相

在 LLM 工程领域，我们常常陷入一个误区：

更多能力 = 更好的系统

但实际上：

LLM 工程不是能力叠加游戏，而是复杂度控制游戏。

为什么？

因为在生产环境中，真正重要的不是：

• ❌ 能做多少事
• ❌ 有多聪明
• ❌ 推理有多深

而是：

• ✅ 成本可控
• ✅ 延迟可预测
• ✅ 行为可解释
• ✅ 失败可恢复

成熟系统的标志

不成熟的系统：

• 功能列表很长
• 什么都想做
• 不断叠加能力
• 追求"完美"

成熟的系统：

• 功能清单很短
• 知道什么不做
• 主动削减复杂度
• 追求"恰到好处"

一句话总结：

真正成熟的系统，不是最聪明的，而是最克制的。

一个值得被引用的观点

Agent 的价值，不在于多思考，而在于恰到好处地思考。

就像一个优秀的工程师：

• 不是写最多代码的人
• 而是用最少代码解决问题的人

就像一个优秀的架构：

• 不是用最多技术的架构
• 而是用最合适技术的架构

Agent 也是如此：

• 不是规划最多步骤的 Agent
• 而是用最少步骤达成目标的 Agent

---

七、总结：从"智能"到"克制"

核心要点回顾

1. 工程现象：简单问题被过度复杂化，导致成本、延迟、不稳定性三重打击

2. 问题定义：认知过拟合 = 模型在简单任务上使用过度复杂的推理结构

3. 根本原因：

   • 模型的讨好型推理天性
   • Prompt 的诱导性设计
   • Agent 架构缺乏复杂度分级
   • 缺少收敛约束机制

4. 解决方案：

   • 复杂度分级（快路径 vs 慢路径）
   • 限制规划深度
   • 显式成本预算
   • Eval 驱动的能力削减

5. 核心观点：克制是高级工程能力

我的立场

在写这篇文章时，我想表达几个明确的观点：

1. 大多数人被 CoT 误导了

• Chain of Thought 是好技术
• 但它被滥用了
• 不是所有问题都需要"逐步思考"

2. 80% 的 Agent 设计是过度设计

• 不是说 Agent 不好
• 而是说大多数场景不需要那么"智能"
• 简单问题用简单方法

3. ReAct 不应该是默认解

• ReAct 适合复杂推理
• 但在生产环境，它应该是备选方案
• 不是主流方案

4. "智能"往往掩盖工程问题

• 很多时候，问题不是模型不够聪明
• 而是系统设计有问题
• 不要用"智能"来逃避工程责任

给 LLM 工程师的建议

如果你正在构建 Agent 系统，请记住：

1. 不要追求"全能"：区分简单和复杂任务
2. 设置明确约束：步骤数、Token 数、时间限制
3. 持续测量价值：每个"智能"步骤都要证明自己的价值
4. 学会做减法：删除比添加更重要

最后一句话

在 LLM 工程的世界里，真正的高手不是那些让 Agent 做更多事的人，而是那些让 Agent 做更少但更对的事的人。

克制，是一种更高级的智能。

而大多数人，还在追求"更聪明"，而不是"更克制"。