Agent 究竟在做什么以及应该做什么？

写在开头

本文并不是为了否认 Agent 的价值，更不是为了推翻 Agent 工程的存在与意义。

本文的逻辑路径未必完全正确，举出的事例与结论也必然带有笔者狭隘的知识边界所产生的负面影响。欢迎指出。

本文的目标，是在 Agent 大火的当下，给被寄予厚望的 Agent 泼点冷水，希望其被相对更加理性克制的看待。

本文基于两个共识：1. 模型的幻觉不可避免，2. 不存在完美的上下文压缩/信息检索策略，且失败的压缩/检索会加剧幻觉。如果这两个共识不能得到读者的认可，则本文没有被阅读的必要。

问题的起点

让我们从最主流的 ReAct 架构开始说起。我们假定读者对这个看起来美妙的架构有一定了解，因此不再介绍这个架构。

笔者认为，ReAct 架构下，上下文随着 Agent Loop 增长而增加是不可避免的，而上下文窗口有限也是目前无法解决的客观事实，因此，ReAct 架构在复杂任务下必然存在如下的循环：

上下文线性增长
    -> 触发压缩/摘要记忆
    -> 不存在无损压缩或者完美检索策略
    -> 检索失败/有损压缩导致幻觉加重
    -> 错误大量涌现需要更多 loop 修正
        -> 上下文进一步增长

显然，这是个负反馈循环，而且是当前 Agent 无可回避的结构性问题。

当前的主流解法

据笔者所知，当下的 Agent 对这个问题存在以下一些主流解法：

方案一：上下文架构重设计

分层记忆架构

┌─────────────────────────────────┐
│  Working Memory（当前窗口）       │  ← 只保留最近 N 步 + 任务目标
├─────────────────────────────────┤
│  Episodic Memory（情节记忆）      │  ← 结构化存储历史 Action/Result
├─────────────────────────────────┤
│  Semantic Memory（语义记忆）      │  ← 向量检索的知识库
├─────────────────────────────────┤
│  Procedural Memory（程序记忆）    │  ← 固化的工具调用模板/技能
└─────────────────────────────────┘

核心思路：将 ReAct 的线性上下文拆解为多层存储，Working Memory 保持精简，按需从下层检索。

Sliding Window + 强制截断

只保留最近 K 步的完整 Thought/Action/Observation
更早的步骤压缩为结构化摘要（JSON 格式，保留关键字段而非自然语言）
结构化摘要比自然语言摘要信息密度更高、幻觉更少

方案二：改进压缩与记忆策略

结构化压缩而非自然语言摘要

// 差：自然语言摘要（易幻觉）
"之前搜索了一些关于用户问题的信息，找到了一些结果"

// 好：结构化压缩（精确）
{
  "step": 3,
  "action": "search",
  "query": "用户ID 12345 的订单状态",
  "result_summary": "找到3条订单，最新订单号 ORD-789，状态：待发货",
  "key_facts": ["ORD-789", "待发货", "2024-01-15"]
}

分级记忆重要性

对每个 Observation 打重要性分数，低分内容优先被压缩
任务目标、关键约束、已确认的事实 → 永远保留在 Working Memory
中间推理过程 → 可压缩

混合检索策略

BM25 + 向量检索混合，提升关键词精确匹配能力
对数值、ID、代码等精确信息使用精确匹配而非语义检索
检索时加入时序权重，最近的记忆优先级更高

方案三：Loop 控制与错误恢复机制

主动错误检测

每 N 步执行一次"元认知检查"：
- 当前进展是否符合预期？
- 是否在原地打转（检测重复 Action）？
- 是否需要重新规划？

回溯机制（Backtracking）

维护检查点（Checkpoint），当检测到推理偏离时回滚到上一个可信状态
类似编译器的错误恢复，而不是在错误基础上继续堆叠

硬性 Loop 上限 + 降级策略

设置最大 loop 次数，超出后触发降级（返回部分结果 + 说明原因）
避免无限循环消耗资源，同时给用户明确的反馈

方案四：架构层面的替代与增强

Plan-and-Execute 架构

Planner（一次性生成完整计划）
    ↓
Executor（按计划执行，上下文相互隔离）
    ↓
Summarizer（汇总结果）

每个 Executor 子任务有独立的小上下文，不共享全局历史
大幅减少单个上下文的长度

Multi-Agent 分治

将复杂任务分解给多个专门的子 Agent
每个子 Agent 上下文独立，Orchestrator 只接收结构化结果,类似微服务架构，隔离复杂度

引入外部状态管理

将任务状态外置到结构化数据库（而非塞在上下文里）
Agent 通过工具调用读写状态，上下文只包含”当前步骤的局部信息”

问题真的被解决吗？

方案一、二：记忆管理与结构化压缩

这两个方案毫无疑问都存在致命缺陷：既然完美的压缩与检索均不存在，那么能否用”有缺陷的方案”来修复”此方案缺陷所导致的问题”？

当前检索能力无法做到完美召回，尤其在 Agent 记忆场景下：

指代消解失败（Step 7 里的 “它” 指向 Step 2 里的某个对象，embedding 完全无法捕捉）
时序依赖断裂（Step5 的结论依赖 Step3 的前提，分块后关联丢失）
语义相近但事实相反的内容无法区分（”方案A不可行” 和 “方案A可行” 的 embedding 距离极近，极易混淆）

当然，我们可以声称通过足够好的误差评估与控制来解决，就像 TCP/IP 协议也存在丢包误差，但这不妨碍它构建了可靠的互联网。

但必须指出，这里有一些不同之处，TCP/IP 的误差是可精确建模的：

丢包是二值事件（丢 or 没丢），可被检测
重传的成功概率与原始传输独立（信道噪声不相关）
误差不会改变数据的语义

而 Agent 的误差不具备这些性质：

压缩/检索的信息损失是连续的、语义层面的，无法被精确检测
重试往往在相同的错误上下文中进行，误差不独立
一次语义错误会改变后续推理的前提，产生语义漂移

因此，压缩/检索带来的误差，并不一定能被精确评估、控制。

原始问题：检索召回不足 → 幻觉 → loop 激增
方案一/二：引入更多检索来管理记忆
              ↓
         检索本身仍然带有无法评估的误差
              ↓
         误差难以控制、收敛
              ↓
         问题并未消失，只是换了个位置

结论：这是循环论证，问题没有被解决，只是换了个位置。

方案三：最大Loop限制 + 回溯机制

致命缺陷：这是一个止损机制，不是求解机制，只能做到尽可能避免错误腐烂，但并不意味着能够获得正确结果。

单次请求模型产生幻觉的概率总是不为零，那么，Agent产生幻觉的概率P(hallucination)与请求次数T存在如下极度简化后的关系：

P(hallucination) = 1-P(单次请求失败)^T

显然其单调递增，这意味着：重试成功的概率不是在收敛，而是在发散

更残酷的推论：当循环次数超过有效推理阈值后，每次回溯重试的起点本身就已经处于幻觉高发状态。成功概率不随重试次数收敛，而是随循环次数增长而单调下降！。

方案四：多Agent架构

致命缺陷一：拆解本身是循环论证

1
2
3

要拆得好 → 需要理解全局任务
理解全局 → 需要长上下文
长上下文 → 正是你试图解决的问题

致命缺陷二：上下文压力只是被推迟一层

1 2	`父Agent上下文 = Σ(所有子Agent的摘要输出) 子Agent数量足够多 → 父Agent同样超限`

致命缺陷三：任何环节异常都可能导致无法识别的雪崩

子Agent B 产生了一个"看起来正确的错误输出"
         ↓
父Agent 无法识别（没有 ground truth）
         ↓
父Agent 基于错误输出继续规划
         ↓
子Agent D、E、F 基于错误规划执行
         ↓
所有下游结果都被污染
         ↓
最终输出错误，但整个过程没有任何报错

多 Agent 架构类似于微服务，但微服务的雪崩至少大概率会让系统崩溃，你知道出了问题。而在当前模型的倾向下，多 Agent 的雪崩极有可能会让系统安静地给你一个错误答案，你甚至可能永远不知道。

根本矛盾

所有方案的失败指向同一个根本性矛盾：

LLM 是局部的、概率性的、上下文有界的推理单元，
大部分(当然并非全部)复杂任务，要求全局的、确定性的、上下文无界的推理能力。

这个矛盾无法通过任何工程 patch 消除，只能被转移或规避。

Agent 工程的本质

笔者将 Agent 工程的核心工作分为两类：

A类工作（用于弥补模型能力的孱弱）：
    记忆管理、幻觉修复、上下文压缩、复杂prompt工程、多Agent交叉验证……
    → 本质：补偿模型能力不足
    → 命运：模型能力提升后系统性归零

B类工作（用于补充模型设计目标外的能力）：
    工具调用、并行执行、实时感知-决策-执行循环、跨系统协调……
    → 本质：匹配问题本身的结构性需求
    → 命运：模型再强也必然存在

从 Claude Code 泄露的源码，包括笔者所了解到的一些其他 Agent 的实现来看，有许多 Agent 都把大部分精力放到 A 类工作中，不断地给模型擦屁股。

这实际上意味着：当前大量的 Agent 框架公司、论文、工程实践，都在押注同一个事情：

“模型能力提升的速度，慢于我们构建补偿层的速度”。

然而，如果我们认为前述的讨论是正确的，那么

如果模型能力不够强，Agent 绝无可能完全擦干净模型的屁股，这是不可解的结构性矛盾；
而如果模型能力足够强，那就无需这大部分的 Agent 层工作。

因此，赌注标的本身不存在，这不是赌输了，而是在赌一个虚假的东西。

当前 Agent 工程商业价值的来源

尽管当前 Agent 产品确实在某些场景产生了商业收入，但其本质是：

把模型不可靠性的成本，从产品方转移给了能够承受它的用户。

代码补全错了用户可以改，文档生成错了用户可以审，工具执行错了用户可以拒绝。这不是解决了问题，而是转移了成本。在风险可承受的场景里，”比没有强”就足以产生收入——但这与”解决了问题”是完全不同的两件事。

当然，这并不代表 Agent 完全没有价值，因为依然存在许多场景，可以接受这种成本转移。但我们更不能回避一个事实：

成本转移真实存在，Agent 并不必然带来提效，量化评估是极具必要但客观被忽视的。

如何正确的寻找有价值的场景与路径，需要更加理性与克制的探索。

最终结论

笔者认为，当前 Agent 领域存在巨大的资源错配：

把过多工程投入花在”让不可靠看起来可靠”上，而不是花在”理解和定义可靠性边界”上。前者随模型迭代归零，后者永远有效。

被低估的长期投入方向

基于以上分析，至少有下列工作在模型能力持续提升的世界里依然有效，且重要性被大幅低估：

定义和测量失败边界：理解模型在哪里失败、为什么失败。这个知识不随模型迭代作废，反而会指导下一代模型的训练方向。
建设可观测性能力：让 Agent 的执行过程可被检查、可被审计、可被追溯。这不是锦上添花，而是将 Agent 从”黑箱自动化”变为”可信自动化”的必要条件。
构建 Agent 基础设施：工具生态、执行环境、安全边界。模型再强，也需要通过某种接口作用于真实世界。
寻找人机协作的真实边界：不是让模型做它做不到的事，而是找到”当前模型能力”与”真实任务需求”之间真正匹配的交叉点——在这个交叉点内构建产品，而不是用工程手段假装交叉点不存在。