AI Agent 四根支柱拆解：LLM、工具、记忆、规划怎么协同原创-开发者社区

AI Agent 四根支柱拆解：LLM、工具、记忆、规划怎么协同
"让 AI 自动帮我干活"喊了两年，多数人搭出来的 Agent 仍然是：一次 API 调用，一次输出，然后卡住。原因多半不在模型不够强，而在架构缺了东西。

一个靠谱的 Agent 至少有四根支柱：LLM 负责想，工具负责做，记忆负责记，规划负责排。四根都在，Agent 才能从"问答机器"进化成"能闭环干活的下属"。这篇把这四根支柱拆开讲清楚，再给一段能跑的最小示例和一张失败清单，读完你能自己诊断 Agent 为什么不靠谱。

支柱一：LLM——推理底座与选型

LLM 是 Agent 的大脑，负责理解指令、生成推理、产出决策。没有 LLM，后面三根支柱都是空壳；但只有 LLM，Agent 就只是套了个壳的聊天窗口。

单次 LLM 调用和 Agent 循环的本质差别，在于"输出是否驱动后续动作"。聊天机器人把一段文本回给你就结束了；Agent 里，LLM 的每次输出都会被解析成结构化动作——调用哪个工具、用什么参数、下一步做什么——然后执行结果再喂回给模型，形成循环。这个差别，是理解 Agent 架构的钥匙。

选型上，我的经验是看三样：指令遵循能力，决定它能不能乖乖输出 JSON；上下文窗口，决定它能装下多少对话历史和工具返回；长文本下的稳定性，决定它在长任务里会不会犯迷糊。同一个任务，模型幻觉率高，整套 Agent 就跟着翻车。所以底座我宁可选贵一点的，也别选便宜爱编的——省下的钱，会在调试 Agent 的深夜里加倍花回去。

还有一个常被忽略的点：底座模型的输出风格要稳定。同一个函数，上一轮输出带引号的参数名，下一轮突然换成裸字符串，你的解析器就崩了。所以选型时我会额外跑一组"结构化输出稳定性"测试，让模型连续解析一百条工具调用，数一数格式漂移的次数。这个数字比评测榜单上的总分，更能预测 Agent 在实际运行里的可靠性。

支柱二：工具调用——Agent 的手脚

工具让 Agent 从"只能说话"变成"能做事"。查数据库、调 API、发请求、算个数字、读写文件，全靠工具层兑现。

主流实现是 Function Calling：把工具的能力描述成结构化定义——函数名、参数 schema、说明——随提示词一起发给模型。模型理解后，在自己的回复里"点单"：调哪个函数、传什么参数。代码里大致长这样：

tools = [ { "name": "query_order", "description": "查询订单状态", "parameters": { "type": "object", "properties": { "order_id": {"type": "string", "description": "订单号"} }, "required": ["order_id"], }, } ]

这段定义会进模型的上下文，模型据此生成调用意图，再由你的代码真正执行。这里有个关键认知：模型只负责"决定调什么"，不负责"执行成功"。真实世界里，工具会超时、会报错、会返回脏数据，Agent 层必须自己处理这些噪音。很多 Agent 翻车就翻在这一步——模型选对了工具，代码却拿返回结果直接拼进提示词，连格式校验都没有。

工具描述本身也是提示工程的一部分。description 写得含糊，模型就乱猜参数；参数 schema 少标了 required，模型就可能漏传必填项。我的经验是：每个工具的说明要写明"何时用、何时不用、返回什么、可能抛什么错"，四行字能省下大量调试时间。

支柱三：记忆——短期与长期的分工

没有记忆的 Agent，每次对话都像失忆患者，问一句忘一句。记忆要拆成两段看：短期和长期。

短期记忆就是当前对话的上下文窗口。历史消息、工具返回结果，全堆在这里。它的天花板很现实：窗口满了要裁剪，裁剪策略不对，Agent 会忘掉关键指令。不少 Agent"做到一半变蠢"，元凶就是历史被粗暴截断，最初的用户需求被挤出窗口。

长期记忆负责跨会话沉淀。常见做法是把重要事实向量化，存进向量数据库，下次对话先用相似度检索，把相关的旧记忆捞回来。也有人把高频事实直接写成 key-value 或配置文件，结构化的东西用结构化存，比什么都塞向量库更省事、也更不容易出错。

记忆的取舍没有银弹。我的判断是：短期记忆管好"本次任务"，长期记忆管好"用户的持久事实"，两者边界划清楚，Agent 的记忆就不会变成一团浆糊。最容易犯的错，是把长期记忆的检索结果一股脑塞进每次对话，上下文被旧信息占满，新指令反而没地方站。

记忆工程还有个容易踩的坑：写入太随意。不是所有对话内容都值得长期保存，把闲聊、临时计算、一次性查询统统塞进向量库，检索的时候全是噪音。我的做法是给记忆分级——直接结论进长期库，过程性内容只在短期窗口里活着，过期就丢。这一条看着不起眼，实际能把检索质量稳稳拉起来。

支柱四：规划——把大任务拆成小步骤

规划是 Agent 的"项目经理"，把一个大目标拆成可执行的小步骤，并在执行中动态调整。

最经典的框架是 ReAct：Reasoning 与 Acting 交替进行。模型先思考——这个任务需要什么，再行动——调用工具，观察结果，再思考下一步。循环往复，直到目标达成或确认失败。流程的骨架大致长这样：

while not done: thought = llm.reason(goal, memory, tool_results) action = llm.choose_tool(thought) result = execute(action) memory.append(action, result) done = llm.check_done(thought, result)

规划不是一次成型。真实任务里，工具返回和预期不符是常态，Agent 要能接受"计划赶不上变化"，在循环里不断修正。规划能力强的模型，能把长任务拆得细、走得稳；规划弱的模型，只会把任务压缩成一次笨拙的工具调用，然后失败。判断一个模型适不适合做 Agent，看它在多步任务里的"回头修正"能力，比看单轮问答分数更有参考价值。

协同起来：流程图、最小代码与失败清单
四根支柱不是四块孤立的积木，它们通过同一个循环串起来。整体协同关系可以画成这样：

用户目标 │ ▼ ┌──────────┐ 读取 ┌──────────┐ │ 记忆 │◄─────────│ LLM │ │(短期/长期)│─────────►│ (推理决策) │ └──────────┘ 写入 └──────────┘ │ 输出工具调用意图 ▼ ┌──────────┐ │ 工具执行 │ │ (Function) │ └──────────┘ │ 返回结果 ▼ 回到 LLM 继续循环，直至任务结束

一个最小可运行骨架（Python 风格，工具用伪函数代替）：

def run_agent(goal, memory): history = [{"role": "user", "content": goal}] + memory.get_context() while True: reply = llm.complete(history) # 支柱一：推理 action = parse_action(reply) # 支柱二：解析工具意图 if action["type"] == "finish": return action["answer"] result = call_tool(action) # 支柱二：执行工具 memory.save(action, result) # 支柱三：写入记忆 history.append({"role": "assistant", "content": reply}) history.append({"role": "tool", "content": result})

规划（支柱四）体现在循环的每一步里：模型每轮都要重新评估下一步，而不是一次到底。整段代码的核心逻辑就一句话——把 LLM 的输出变成可执行的动作，把执行结果再变回 LLM 的输入。

下面这张失败模式清单，Agent 不靠谱的根因，九成能在这里对上号：

结论

Agent 不是"调一个大模型就行"，而是四根支柱的协同工程：LLM 想，工具做，记忆记，规划排。哪一根缺位，Agent 都会以一种很笨的方式失败——而大多数失败，其实都写在上面那张表里。

从零搭 Agent 的正确顺序，我的建议是先工具、再记忆、后规划。理由很简单：没有工具，Agent 只能聊天，干不了活；记忆跟不上的话，它每次开工都像第一天上班。规划这步最抽象，放在收尾反而容易理解——它就是把前两样串起来的那根线。先把"手"接上，让 Agent 能开始干活，比一次上满四件套更容易看到成果。