前阵子我给项目加了个“自动处理工单”的智能体，测试的时候跑得挺欢。一上线，第二天早上看日志，它凌晨三点把同一个工单处理了四遍。我查了半天，发现它完全不记得自己已经处理过这个工单——没有记忆，每次醒来都是全新的开始，像个喝断片的同事。

后来又加了个“搜索知识库”的工具，它倒好，遇到任何问题都先去搜一圈，明明用户问的是“今天星期几”，它也去搜，Token 烧得我肉疼。这就是规划没做好，不会判断什么时候该用什么。

踩了一圈坑之后我算明白了：智能体看起来花里胡哨，其实核心就三个模块——规划、记忆、工具调用。这三个搞清楚了，剩下的都是锦上添花。今天就一个一个拆开，用人话给你讲明白。

一、先给智能体画个像
很多人一听到“智能体”就想到钢铁侠的贾维斯，觉得得有多复杂。其实你把一个最简单的智能体拆开，它的工作流是这样的：

用户给个任务（比如“帮我查下昨天服务器报错的原因”）

智能体规划：先查日志，再分析错误堆栈，最后给结论，可能需要调工具

调工具：调日志查询 API，拿到结果

把结果存进记忆，万一用户追问还能想起来

根据记忆和工具返回的结果，生成最终回复

没了。就是这三板斧来回倒。市面上那些框架（LangGraph、CrewAI、AutoGen），都是在这三板斧外面套了层更优雅的壳。核心逻辑不变。

二、规划：智能体的“大脑”，决定了它聪不聪明
2.1 规划到底是什么
规划就是让模型在动手之前先“想一下”：这个任务要分几步？每步该干什么？需不需要调用工具？

没有规划的智能体，就是个只会接话的聊天机器人。有规划的智能体，才是能独立干活的“数字员工”。

2.2 最经典的规划模式：ReAct
现在最主流的规划策略叫 ReAct（Reasoning + Acting，推理+行动）。它的逻辑非常简单，就是一个循环：

Thought（思考）：我现在需要做什么？我有哪些工具可以用？

Action（行动）：调用某个工具，比如查日志

Observation（观察）：工具返回了什么结果？

重复：根据结果继续思考，直到完成任务

代码写出来就是个 while 循环：

python
while not task_finished:
thought = llm.think(context, tools)
if thought.need_tool:
result = call_tool(thought.tool_name, thought.params)
context.add(result)
else:
final_answer = thought.content
task_finished = True
这就是所谓的 Agent 循环，任何语言都能实现，不是什么黑科技。

2.3 更高级的规划：Plan-and-Solve、ReWOO
ReAct 虽然经典，但有个毛病：每一步都要调一次大模型，Token 消耗大。于是有了一些优化方案：

Plan-and-Solve：先让模型一次性生成完整计划，再按计划逐步执行，不需要每步都思考。

ReWOO：把“推理”和“工具调用”分离，先生成一个包含工具调用的执行图，然后批量调工具，最后再统一推理，大幅减少 LLM 调用次数。

我用 Plan-and-Solve 重构了那个工单处理智能体，Token 直接省了 40%。因为它不用在每一步都“思考人生”了。

2.4 踩坑：规划得太花哨反而坏事
我曾经给一个查天气的智能体配了 ReAct，用户问“南京明天多少度”，它思考了半分钟：要不要先查空气质量？要不要先确认用户说的是南京市还是南京区？要不要再查一下历史温度做对比？最后调了四次工具，输出了一个简单的天气回复。Token 烧了快一千。

这就是规划过度的典型。简单任务，直接调工具就行，别让 Agent 加戏。 所以后来我给 Agent 加了个判断：如果任务复杂度评分低于 3（满分 10），跳过规划直接调工具。效果立竿见影。

三、记忆：智能体的“海马体”，忘了就等于白干
3.1 记忆到底存什么
智能体的记忆分两种：

短期记忆：当前对话的上下文，比如用户刚才说了什么、上一步调了什么工具、返回了什么结果。一般直接放在 Prompt 的 messages 列表里。

长期记忆：跨会话的信息，比如用户的偏好、历史订单、之前解决过的问题。通常存向量库或数据库，需要时检索出来。

我那个重复处理工单的 Bug，就是只存了短期记忆，对话一结束全忘了。第二天同一个工单再来，它当新的处理。

3.2 短期记忆怎么管：滑动窗口 + 摘要
短期记忆不能无限堆。大模型的上下文窗口虽然越来越大，但塞太多东西，模型注意力会分散，而且 Token 烧得飞起。

我的管理策略就两条：

滑动窗口：只保留最近 10 轮对话，旧的扔掉。

关键信息摘要：当对话超过一定轮数，调一个小模型把之前的对话压缩成一段摘要，放进系统提示词。这样既保留了上下文，又省了 Token。

python
if len(messages) > 20:
summary = cheap_model.summarize(messages[:-10])
messages = [SystemMessage(summary)] + messages[-10:]
3.3 长期记忆怎么存：向量库 + 结构化数据
用户的偏好、历史记录这些，不能每次都塞 Prompt 里。我用的是：

向量库（如 pgvector 或 Milvus）：存用户画像、历史问题、知识文档，需要时语义检索。

关系型数据库：存结构化的用户数据，比如“用户 A 总是用 Python，讨厌 Java 示例”。

当用户提问时，先去向量库检索相关的历史信息，拼进 Prompt 里。这样 Agent 就有了“跨会话的记忆”，不会每次都是陌生人。

3.4 踩坑：记忆污染比失忆更可怕
有次我存用户偏好的时候，把一次错误的工具调用结果也存进去了。然后 Agent 每次都“记得”那个错误，反复在同一个地方翻车。记忆模块一定要有“遗忘机制”或者“校验机制”，记错了还不如不记。

四、工具调用：智能体的“手”，光有脑子没法干活
4.1 工具调用的本质
工具调用就是让大模型能调用外部函数。技术上用的是 Function Calling（OpenAI/DeepSeek 都支持），或者更高级的 MCP（Model Context Protocol）。

工作流程：

你定义好工具的名称、描述、参数 Schema

把工具列表发给大模型

大模型根据用户输入，决定要不要调工具、调哪个、传什么参数

你的程序执行工具，把结果返回给大模型

大模型基于工具结果生成最终回复

4.2 怎么给 Agent 选工具：不是越多越好
我曾经给 Agent 接了 20 个工具，什么查天气、查股票、查物流、翻译、写代码、搜网页……结果它在简单任务上也开始犹豫：“用户问天气，我要不要顺便查下当地的旅游攻略？要不要再翻译成英文？”

工具越多，模型的选择成本越高，越容易选错。我的原则是：一个 Agent 只做一类任务，只配相关工具。 通用 Agent 听着美好，实际上样样通样样松。

4.3 MCP：让工具调用更标准
今年最火的就是 MCP。以前你给不同模型写工具，得适配不同格式。现在用 MCP，写一次工具，所有支持 MCP 的模型都能调。

Java 里用 MCP Server 注册工具，我就把“查订单”“查日志”“发邮件”这些全包装成了 MCP 工具。Cursor 能调，Claude Desktop 能调，我自己的 Java 后端也能调。一套代码到处用，不用重复造轮子。

五、三者的协同：一个真实案例
上个月我做了一个“运维助手”智能体，需求是：“帮我看下最近一小时的错误日志，分析原因，严重的话发邮件告警。”

规划：Agent 判断这个任务分三步：查日志 → 分析 → 判断是否发邮件。

工具调用：

第一步调 query_logs(time_range=“1h”, level=“ERROR”)，返回 3 条错误日志；

第二条日志是个 NullPointerException，Agent 判断很严重。

记忆：Agent 把这条 NullPointerException 存进短期记忆，然后回想长期记忆里有没有类似问题——一检索，发现上周也出现过，是同一个接口。

再规划：发现是重复问题，Agent 决定不仅发邮件，还在邮件里附上上周的修复记录链接。

最终它调了 send_email 工具，邮件里写道：“过去一小时出现 3 次 NullPointerException，与上周同一位置，建议立即回滚或修复。历史记录见链接。”

这个流程里，规划让它知道分几步走，工具让它能实际干活，记忆让它有上下文、不重复犯错。缺了任何一环，效果都会打折。

六、给想手搓智能体的兄弟几个建议
先别上框架，手搓一个最简陋的 Agent。就一个 while 循环，让模型思考、调工具、再思考。等你跑通了，再去学 LangGraph 或 CrewAI，你会觉得豁然开朗。框架解决的是“规模化”的问题，不是“能不能”的问题。

规划不要过度设计。简单任务直接调工具，复杂任务才上 ReAct。给你的 Agent 加一个“任务复杂度判断”的步骤，能省很多 Token。

记忆越简单越可靠。一开始用滑动窗口 + 数据库就够了，别一上来就搞复杂的记忆图谱。等你发现现有方案撑不住了，再逐步加向量检索、知识图谱。

工具定义要精炼。每个工具的 description 要写得像给新同事看的“操作手册”，参数说明越清楚，模型调用的准确率越高。

七、最后说两句
智能体不是什么神秘的高科技，它就是 “大模型的推理能力 + 工程化的模块设计”。规划让它会思考，记忆让它有经验，工具让它能干活。你把这三块整明白了，剩下的就是不停地迭代和优化。

别被框架和论文吓倒，动手搓一个，搓完你就不怕面试官问“智能体原理”了。