解读LLM Agent:总体框架、经典论文与实践

以下是修改后的版本，按你的要求来：

你现在的Agent，可能第一个坑都没爬过去

先讲个真事儿。

这周我停更了大模型RL的连载——不是偷懒，是被拉去救一个Agent项目。本来以为嘛，照着成熟架子改改，两天就能糊弄过去。结果呢？差点把团队干翻车了。好，现在把踩过的坑全写出来，省得你跟我走一样的路。

你想想，如果下一次你老板拍着你肩膀说“帮我看下这个Agent项目”，你心里总得有个底吧？

01. Agent这东西，真不是你想象的那样

先把这个最核心的问题说清楚。

什么是工具？

你只要让语言模型能从外部拿到知识，或者能执行操作，那个接口就是工具。搜索引擎、代码执行器、天气API、数据库……甚至另一个模型。说白了，只要不是LLM自己脑子里存的东西，都算工具。

那为什么要工具？你看看——LLM的知识凝固在训练数据里，今年发生的事它完全不知道，代码写完了不会自己跑，算个数学题都能胡说八道。整合个搜索、数据库、知识库，至少回答用户问题的时候能靠谱点，对吧？RAG（检索增强生成）就是最常见的一种——把文本搜索当外挂，每次回答前查一下，多少能减少一点幻觉。

但是！ 工具这东西，用不好比不用更惨。

我刚做RAG那会儿，天真地以为加个向量库就完事儿了。结果呢？分块大小、embedding模型选择、相似度阈值、重排序……每一步都在给你制造“惊喜”。你拆小了，语义不完整；拆大了，噪音一堆。选错了一个阈值，全世界都跑偏。

说到Agent的经典框架，Lilian Weng那篇博客已经把话说透了：Agent = LLM + 规划 + 记忆 + 工具，但四者之间是乘法关系——缺一块，效果归零。

说起来你可能不信，实操下来最容易翻车的地方，根本不是模型多强，而是记忆和工具描述——这两个最不起眼的玩意儿。

记忆分短期和长期。短期就看上下文窗口嘛，但窗口再大也有限，长了模型自己都迷路。长期记忆得靠外部载体，存成向量或文件，需要的时候再检索回来。

后来我发现了Manus项目的做法——直接把文件系统当作终极上下文。什么意思？你访问了一个网页，保留URL，内容先踢出去，后续需要了再重新请求。生成了报告，保留文件路径，内容也暂时卸载，需要时用cat或tail读回来。这叫“可逆压缩”——信息没丢，只是暂时从脑子里拿出去。

我试了一周告诉你——这做法太他妈实用了！尤其是长任务，效果立竿见影。

它还有一个特别聪明的细节：鼓励Agent主动把中间结果写成文件。比如查了个复杂数据，保存到/tmp/query_result.json，上下文里只留一句“结果已写到某路径”。后续需要了，head一下看看前几行就行。你想想，这不跟正常人一样工作吗？不是把所有东西都塞进脑子里，而是写下来、存好、需要了再翻。又笨重又聪明，但就是管用。

记忆的研究也在往前推。那篇A-Mem的论文读得我眼前一亮——它把记忆系统直接做成了Agent，不只是存向量。每条记忆是富信息卡片，包含原始内容、关键词、标签、上下文描述。新笔记进来后，系统先用余弦相似度找到Top-K个候选，再交给LLM判断哪些笔记之间有“意义关联”（因果关系、概念层级、跨领域类比）。然后反过来更新旧笔记的上下文。这意味着什么？你的旧记忆会跟着新信息一起演化。 结果在LoCoMo数据集上，A-Mem的F1和准确率都明显高于基线，多跳推理表现尤其突出。

但你想想，这又引入一个LLM调用——成本压得住吗？我在实际产品里还不敢上这个，但监控起来肯定让你头疼。

02. 别被那些新词骗了，范式的真相是这样的

从2023到2026，Agent技术形态已经经历了四个阶段。注意，不是平滑过渡，是跳台阶的。你跳错一个，前面就是坑。

第一阶段：被动式ReAct Agent（2023年）

那年是LLM元年，Agent概念刚有。代表项目：AutoGPT、AutoGen、MetaGPT。核心逻辑就是“推理→观察→回复”的短链路。你告诉它“查天气”，它“想”一下，调API，看到结果，回答你。就这一步。超过三步的任务就开始跑偏。

我实际试过AutoGPT——感觉就是一只勉强会按按钮的猴子。一句话没说清楚它就乱套。你对它说“帮我订个周末出差的酒店”，它会先搜天气，然后查餐馆，最后问你要不要机票。你说气人不气人。

第二阶段：Plan-and-Execute 与 Reflection

任务太长了怎么办？先规划再执行。把大任务拆成小步骤，一步一步来。Reflection加了一层自我批评，每一轮执行完，让Agent回顾一下刚才做得怎么样，哪里需要修正。好处是长任务不容易迷路，代价是token消耗猛增。

我做测试的时候，一个三步就能完成的任务，加了Reflection之后token量翻了3倍。你说值不值？值，但烧钱。

第三阶段：Multi-Agent 与 Workflow

任务天然可以拆成多个角色，那就让不同Agent扮演专家：一个写代码，一个测试，一个管数据库。听起来很美好对不对？

但你猜怎么着？通信成本和调试成本会让你崩溃。

我搭过一个两个Agent的对话系统，A让B查数据，B查完了A没收到，或者A自己又查了一遍。没有全局同步，很快就乱成一锅粥。最后我不得不在日志里手动追踪它们的对话，差点想写个“Agent调解员”。

Workflow（AI工作流）走的是另一条路：预先画好执行路径，节点上放LLM。执行路径固定，可观测，出问题好排查。代价是前期设计成本高，要能提前把所有步骤确定。

对比一下：ReAct灵活但调试难，Token烧得快；Workflow稳但对需求拆解要求高，改起来费劲。我的判断很简单：先写路径，能写出来就用Workflow，写不出来再上Agent。 就这一句话，你拿着用，比追什么新框架都有用。

第四阶段：Agentic Workflows + 文件系统即上下文（2025-2026）

Manus、Claude Code这些新架子，直接把文件系统当作永久上下文。它们放弃了RAG那种“推理前检索”的思路，改成了“just-in-time”检索——让LLM自己决定什么时候搜索、怎么搜。

为什么会这样？因为RAG的组件太多了：分块策略、embedding模型、索引结构、相似度计算……任何一环出问题都影响结果。与其费这么大劲，不如让模型自己写grep命令搜索代码库。

我试了Claude Code的search命令——确实比很多手工搭建的RAG快准狠！但前提是模型本身得够强。能力一般的LLM连search命令都写不对，你让它自己搜，它能把grep写成grep -r然后卡死。

有一段历史我专门读了一下——经典符号架构（SOAR、ACT-R、BDI）。说实话，跟现在LLM Agent有代沟。那些架构依赖预编码的知识库和推理规则，现在是靠数据统计出推理能力。好有一比：一个是工程师亲手拧螺丝，一个是机器人学会了看图纸自己拧。

强行把BDI的概念套到现在的Agent上，反而遮蔽了统计模型背后的真实行为——你分析半天“意图模型”，不如看看它在训练数据里见过多少个类似的问题。

03. 实操里最容易忽视的，偏偏是最要命的

上下文怎么管——90%的人第一步就错了

上面说了Manus的“可逆压缩”，我们项目里直接拿来用了。具体做法其实很简单：

• 网页内容保留URL，内容先移除
• 文件处理保留路径，内容用`cat`按需加载
• 日志输出只留路径或摘要

关键是什么？要保证信息真的“可逆”——URL还能访问，路径没变。否则就是真丢数据，到时候你翻日志都找不到问题在哪。

还有一个更深的取舍问题：“推理前检索”和“just-in-time”到底用哪个？

我们现在的项目依赖一个内部代码库。早期搭了RAG管道，结果半年里断断续续出问题。不是embedding模型换了，就是索引结构崩了。最后我一咬牙，改成Agent自己执行搜索命令。代价是得写清楚搜索工具的调用描述，而且模型必须能理解目录结构。

切换之后，代码仓库的上下文质量确实好了不少。但也有新问题——模型有时候搜索命令写错了语法，或者搜出来的东西太多不会过滤。不过相比之前RAG莫名其妙失效来说，这两个问题至少能排查。

别以为自己是在做研究，先让它跑起来再说。

工具描述——最容易省时间的地方，坑最大

说到这儿，我要说最重要的一件事。

MCP（Model Context Protocol）解决了接入方式，JSON Schema解决了格式定义。但是，模型到底调不调这个工具、参数怎么填，最后都靠description里那几句话。

你想想，你写个工具描述“获取天气”，模型根本不知道支持什么城市、返回什么字段。它怎么调？不调算你运气好，调了还给你个错误结果。

我见过一个典型案例：有个人写“获取天气”，模型对着它问“你想查哪个城市的天气？”。你看，模型自己都不知道该填什么参数。

后来我改成：

description: "查询指定城市的实时天气数据。参数city是城市名，如'北京'。返回包含temperature（摄氏）、humidity、wind_speed。如果城市不存在，返回error。"

调用率立刻提升3倍。

你在这个地方省力气，后面调试两倍还回来。我见过有人说“description写几句就行”，结果模型一周都不调用一次工具，项目组以为是框架问题，查了三天，最后发现是没写清楚支持什么城市。

结尾：让Agent跑起来之前，先别想着万能

你问我这趟踩坑最大的收获是什么？

Agent项目跑起来不稳定，99%不是模型不够好。 规划、记忆、工具、描述——随便哪个出问题都可能崩。记忆跟不上，长任务就会失忆；上下文管不好，模型容易跑偏；工具描述不清楚，模型要么不调用要么调错。

选型也一样，特别容易跳坑。你先问自己一句：执行路径能写清楚吗？能，就Workflow；不能，再用Agent。就这一个判断，省下的时间足够你看完两篇论文加一杯咖啡。

至于未来，我觉得工具调用和记忆管理会是核心竞争力。纯靠模型内部推理来干长任务不现实，文件系统那种可逆压缩思路会越来越多。RAG不会消失，但不再会是唯一答案。

至于那些试图将经典符号架构生搬硬套到LLM Agent上的做法——多半会碰壁。因为这不是一次改良，是一次范式跃迁。

好了，我自己的下一步，是把手上的项目从Multi-Agent拆回Workflow加局部ReAct的组合。稳定优先，效率其次。等跑通了再考虑更复杂的架构。

至少先把路径写纸上，再说别的。

别老想着造个贾维斯，先让它学会不把钥匙忘在家里。