AI Agent 四根支柱拆解LLM、工具、记忆、规划怎么协同让 AI 自动帮我干活喊了两年多数人搭出来的 Agent 仍然是一次 API 调用一次输出然后卡住。原因多半不在模型不够强而在架构缺了东西。一个靠谱的 Agent 至少有四根支柱LLM 负责想工具负责做记忆负责记规划负责排。四根都在Agent 才能从问答机器进化成能闭环干活的下属。这篇把这四根支柱拆开讲清楚再给一段能跑的最小示例和一张失败清单读完你能自己诊断 Agent 为什么不靠谱。支柱一LLM——推理底座与选型LLM 是 Agent 的大脑负责理解指令、生成推理、产出决策。没有 LLM后面三根支柱都是空壳但只有 LLMAgent 就只是套了个壳的聊天窗口。单次 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 的项目经理把一个大目标拆成可执行的小步骤并在执行中动态调整。最经典的框架是 ReActReasoning 与 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 能开始干活比一次上满四件套更容易看到成果。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。