Agent 的四块积木：模型、工具、循环、记忆

从一个具体的小任务说起

假设你想给朋友的博客做一个“摘要助手”：每天自动抓取最新文章、生成摘要、发到指定的地方。先别想 Agent，想想如果让你用普通程序实现，会怎么写？

一种写法是把步骤写死：抓取 → 截断到合适长度 → 调用一次模型生成摘要 → 发送。每一步做什么、出错怎么办，都在代码里定好。只要需求稳定，这其实是非常好的方案，值得认真维护。

另一种写法是只描述目标：把“把最新文章摘要好发给我”这句话交给模型，同时给它三样工具——抓取网页、生成摘要、发送消息。至于先抓哪篇、摘要多长、某篇抓不下来是跳过还是告警，由模型在运行时看着情况决定。

两者的差别不在“用没用大模型”，而在于决策点放在哪里。 前一种，决策（顺序、分支、容错）写死在代码里；后一种，代码只提供能力与边界，把“下一步做什么”交给模型在运行时决定。我们通常把后一种程序叫 Agent。

四块积木分别是什么

模型是大脑。 它是一段接收文字或图像、输出文字的推理器，负责“下一步做什么”这类判断。一个容易忽略的事实是：模型本身不执行任何操作，也不联网，它只输出意图——例如“我建议调用摘要工具，参数是这篇的地址”。意图要不要执行、执行结果如何，都由外围代码接管。正因为模型只是一块可替换的积木，好的 Agent 设计都会把模型与工具、记忆解耦，让你日后换更强的模型时不至于重写整个程序。

工具是手脚。 把一项能力暴露给模型的标准做法叫“工具描述”：一段普通函数 + 一句人话说明它干什么 + 参数说明，整体注册给模型。模型不直接运行你的函数，它只是请求调用；你的代码在收到请求后校验参数、真正执行，再把结果作为文本回传给模型。各家叫法不同——OpenAI 叫 function calling，Anthropic 叫 tool use——但模式是同一种。为了让不同厂商的工具接口能互通，MCP 这样的开放协议正在把“工具的长相”规范化。对你而言，理解到“工具 = 一段有描述、有参数约定的可调用单元”就已经够用。

循环是节奏器。 这是 Agent 与一次性问答最本质的区别：模型不是回答完就结束，而是进入一个可能反复多轮的循环，直到任务完成或你设的终止条件被触发。这个循环小得惊人：

1. 把任务与当前已知信息交给模型
2. 模型输出：要么直接回答，要么是“调用某个工具 + 参数”
3. 若是工具调用：执行工具 → 把结果写回上下文 → 回到第 1 步
4. 直到模型认为可以收尾，或达到你预设的最大步数

注意“自主”不等于“无限”。恰恰相反，好的 Agent 依赖清晰的终止条件：最多迭代几步、允许调用哪些工具、每步要不要人工确认，这些护栏都是你写的。研究与实践把这种“思考 → 行动 → 观察”的循环称为 ReAct，出处见文末。

记忆是笔记本。 模型每次能“看到”的上下文是有限的（受上下文窗口约束），而一次任务可能产生几十步中间结果。于是记忆分两种：工作记忆把对话历史和工具返回结果整理后放回上下文，让模型“记得”刚才发生了什么；长期记忆把任务结束甚至跨会话后仍想保留的信息写进文件、数据库或向量检索，需要时再取回。把记忆理解为“管理该放进上下文的信息”，比把它理解成某种具体的数据库更有用——用什么存储，是之后才要做的决定。

最小可运行理解：不贴代码地验证一遍

你现在就可以在电脑上验证这种感觉，而不必等后面的课程。方法是：任选一个官方 SDK，跑通它文档里那个“带一个工具的 hello world”，过程中只观察三件事——模型输出的工具调用请求长什么样、你的函数结果是如何回到模型手里的、循环是由谁来控制的。看到这三处，四块积木就连成一体了；至于 API 的其余部分，先忽略也无妨。本课程后续的文章会带你在命令行从零跑起这样的最小示例，届时我们再谈具体代码。

边界与常见误区

• 不是所有任务都需要 Agent。 步骤确定、可预期的任务，用脚本或工作流更省、更快、更可测。Agent 的价值在“你没法预先把所有分支写死”的任务里：开放式输入、需要临场应变、依赖多步工具组合。
• 别把 Agent 当成“更聪明的对话”。 引入自主循环的代价是实打实的：延迟上升、token 成本上升、出错面变大。从最小循环起步，缺什么再加什么，比一上来就搭一个全知全能的大纲更划算。
• 工具是失控风险的主要来源。 模型只是“建议”调用，真正执行前请你校验参数、限制权限、记录审计。安全边界是代码的责任，不是模型的承诺。
• 别被“无限上下文”的宣传带偏。 窗口再大也有界；学会把该带进上下文的信息整理好，往往比买更大的窗口更有效、更便宜。