前言

过去一年，Agent 几乎成为大模型领域最热门的话题之一。

从 AutoGPT、LangChain Agent，到 Cursor、Claude Code、Codex、Manus，各种 Agent 产品和框架层出不穷。

但一个现实问题也越来越明显：

关于 Agent 的讨论很多，真正来自生产环境的经验却很少。

大多数文章都在介绍：

• 什么是 Agent

• 如何调用 Tool

• 如何接入 MCP

• 如何使用某个框架

而很少有人讨论：

• Agent 为什么会失败？

• Context 为什么会失控？

• Tool 为什么越来越多却越来越不好用？

• Memory 为什么看起来有价值却迟迟没有成熟方案？

这篇文章尝试从工程实践视角，总结当前 Agent 研发中最重要的一些经验与思考。

---

Agent 的本质：Context Engineering

如果只保留一个结论，那么应该是：

Agent 本质上是 Context Engineering（上下文工程）。

很多开发者容易把 Agent 理解成：

• Workflow

• Multi-Agent

• Tool Calling

• Memory

• RAG

但对于模型而言，这些最终都会被转换成上下文。

无论是：

• System Prompt

• Developer Prompt

• User Message

• Tool Schema

• Tool Result

• 图片

• 音频

• Memory

本质上都只是不同形式的 Context。

因此 Agent 能力的上限，很大程度上取决于：

• 给模型提供了什么信息

• 信息以什么顺序出现

• 什么被保留

• 什么被删除

• 什么被压缩

• 什么被动态注入

Agent 设计的核心问题，从来不是“功能堆得够不够多”，而是：

当前上下文是否真正帮助模型完成任务。

---

为什么不要迷信 Agent Framework

LangChain、LlamaIndex 等框架曾经承担过重要角色。

它们解决的问题是：

• Prompt 编排

• Tool 集成

• Agent Workflow

• 模型切换

但框架试图解决的一个核心问题——模型可替换性——在实践中并不成立。

原因很简单：

不同模型之间并不是等价的。

它们在以下方面差异巨大：

• 指令遵循能力

• Tool Calling 能力

• 长上下文表现

• Prompt 敏感度

• 推理风格

理论上的：

GPT → Claude → Gemini → Qwen

一键切换。

实际往往变成：

Prompt 重写
↓
Benchmark 重跑
↓
Tool 调整
↓
Few-shot 重构
↓
重新验证

因此框架适合：

• 快速验证

• Demo

• 原型开发

但生产环境最终仍然需要围绕具体模型做深度优化。

---

Benchmark 应该最先做，而不是最后做

很多团队会先开发功能。

等功能差不多了才开始评估。

但 Agent 恰恰相反。

Benchmark 应该是最早建立的基础设施。

原因在于：

模型每天都在变化。

你无法仅靠直觉判断：

• Prompt 是否变好了

• 模型升级是否退化了

• 成本优化是否影响成功率

如果没有 Benchmark：

所有优化都只是感觉。

真正合理的流程应该是：

确定任务
↓
建立数据集
↓
建立 Benchmark
↓
开始优化
↓
持续回归测试

Benchmark 不是研究工具。

而是 Agent 工程体系的一部分。

---

长 Context 会导致能力下降

很多人只关注：

Context 越长
=
成本越高

实际上更严重的问题是：

Context 越长
=
模型能力下降

常见表现包括：

• 注意力稀释

• 细节召回下降

• 跨段推理变差

• Tool 使用错误增加

因此：

能够放进去

≠

应该放进去

Agent 的设计目标不是塞满 Context Window。

而是在有限窗口中保留最有价值的信息。

---

Cache 命中率是生产系统的一等公民

很多 Agent 系统上线后最先遇到的问题不是正确率。

而是成本。

大型 Agent 的成本结构大致如下：

Prompt Tokens
+
Context Prefill
+
Tool Result
+
长会话历史

其中大量成本来自重复输入。

因此 Cache 命中率非常重要。

最典型的反模式：

把动态信息放进 System Prompt。

例如：

• 当前时间

• 文件列表

• 当前目录结构

• 动态 Tool 集

这些内容频繁变化。

会导致：

Prompt Cache Miss
↓
Prefill 重算
↓
延迟上升
↓
成本增加

更合理的做法是：

System Prompt 保持稳定。

动态内容按需注入。

---

查找过程本身也是上下文

这是 Coding Agent 中非常有意思的现象。

很多人认为：

RAG
=
找到答案
=
直接给模型

似乎效率最高。

但越来越多 Coding Agent 又重新拥抱：

• grep

• glob

• find

• shell

原因在于：

模型不仅需要答案。

还需要理解答案是怎么找到的。

例如：

grep Button src/

这个动作本身就暴露了：

• 文件结构

• 命名方式

• 模块关系

• 项目组织形式

这些信息会帮助模型建立代码库认知。

因此：

最短的信息路径

不一定是最优的认知路径。

---

上下文压缩一定会损失信息

很多 Agent 都会做：

Compact
Summary
Context Compression

这是必要的。

但必须意识到：

压缩不是无损的。

尤其 Coding Agent 中：

一个函数名丢失。

一个字段遗漏。

一个边界条件被省略。

都可能导致后续推理完全偏离。

更危险的是：

压缩后的内容会被模型视为新的事实。

于是错误会持续传播。

形成：

第一次压缩错误
↓
第二轮基于错误推理
↓
第三轮继续扩散
↓
最终任务失败

因此：

压缩能力本身也应该被 Benchmark。

---

Tool Design 本质上也是 Prompt Design

很多开发者设计 Tool 时站在人的角度思考：

search()
query()
lookup()

自己觉得很优雅。

但模型未必理解。

需要意识到：

Tool Schema 本身就是 Prompt。

包括：

• Tool Name

• Description

• Parameter Name

• Parameter Description

全部会进入上下文。

因此设计原则应该是：

命名统一

例如：

file_read
file_write
file_search

优于：

read
modify
finder

参数明确

不要让模型猜。

描述简洁

重点说明：

• 什么时候用

• 用来解决什么问题

而不是写 API 文档。

---

能 Tool Call 就不要自由输出

一个非常实用的经验：

如果任务最终需要结构化结果。

尽量使用 Tool Call。

例如标签分类：

不要：

输出标签：
A
B
C

然后自己写解析器。

而是：

{
  "label": "A"
}

直接作为 Tool 参数。

原因在于：

模型厂商会优先优化 Tool Calling。

其稳定性通常高于自由文本。

---

Tool 不要太多

MCP 的流行让很多系统开始疯狂接工具。

但 Tool 不是越多越好。

工具数量增加会带来：

• Context 膨胀

• Cache 下降

• Tool 选择困难

• 调用错误率增加

很多 Agent 的问题不是 Tool 太少。

而是 Tool 太多。

好的 Tool 集通常满足：

• 数量少

• 能力覆盖广

• 命名一致

• 语义清晰

---

Memory 远没有成熟

Memory 是 Agent 领域最容易被高估的能力之一。

它面临几个根本问题：

不知道记什么

模型无法稳定判断：

哪些是长期知识。

哪些只是临时信息。

会过期

尤其 Coding 场景：

代码一直在变。

Memory 很容易变脏。

检索困难

Memory 越多。

检索越困难。

容易形成认知锚定

固定 Memory 会影响当前推理。

让模型更倾向于重复旧模式。

因此当前阶段：

Memory 更像实验方向。

而不是成熟方案。

---

Bitter Lesson 对 Agent 的启示

很多今天流行的 Agent 技巧。

本质上都是：

弱模型时代的补偿机制。

例如：

• 复杂 Workflow

• Router

• 多 Agent Team

• 大量规则

• 特殊 Prompt

这些东西在模型较弱时非常有效。

但随着模型能力增强。

它们可能逐渐从帮助变成负担。

因此 Agent 架构应该遵循一个原则：

尽量简单。

保留：

Observation
↓
Thinking
↓
Action
↓
Observation

这样的核心循环。

而不要过度依赖复杂编排。

---

结语

Agent 领域仍然处于快速演化阶段。

今天有效的经验，明天未必仍然成立。

但有一些原则可能相对稳定：

• Context 比框架重要

• Benchmark 比感觉重要

• 简洁比复杂重要

• Tool Design 比 Tool 数量重要

• 模型能力比 Workflow 更重要

当模型持续进步时，真正能够长期存活的 Agent 系统，往往不是功能最多的那一个。

而是最理解模型本质的那一个。