Agent 是什么:从一次工具调用到五层结构
这是”从概念到系统”专题的第一篇。在讨论记忆、编排、Harness 这些具体子系统之前,我们得先建立一个共识:Agent 到底是什么。这个词被用得太滥,十个人嘴里可能是十件事,所以有必要先钉死定义,再往下走。
一、Agent 不是聊天机器人
先给一个相对严格的定义:
Agent 不是聊天机器人,而是一个能够自主完成任务的软件系统。
拆开看两个关键词。
软件系统——它不是单个程序,而是由多个相互关联的组件组成的集合体
、配置、记忆存储、工具接口、日志。它作为一个整体运行,去解决一个复杂问题。这一点决定了造 Agent 本质上是系统工程,而不是”写一个更聪明的 prompt”。自主完成任务——这里有两层要求,很多号称”有 Agent 功能”的产品其实只做到了第一层:
- 无需人类实时干预”感知环境 → 制定决策 → 执行动作 → 观察反馈”。仅凭这一条,很多对 LLM 做封装的工作流插件都在无限逼近。
- 达成目标 Agent 的地方。尤其是 Coding Agent,经常出现”我想的和它做的完全不一样”——即便有文档约束也提升有限,因为很多时候它只是在猜你想干什么。
第二层要求解释了为什么本专题要花这么多篇幅去讲结构。你没法让模型”更懂你”,但你可以通过系统设计,把它的行为约束在正确的轨道上。
一个必要的心理准备:放弃”让 Agent 像人一样领悟”的幻想。LLM 更像一个压缩后的认知模拟器,而不是一个真正的”大脑”。人类的语言理解、逻辑推理、情绪判断分布在多个神经系统里,而 LLM 把这一切压进了 token 序列的概率分布。这也是为什么你的想法和它的执行会有偏差——token 能存储的信息太少了。所以我们的策略不是”训练它领悟”,而是”设计系统去弥补它领悟不到的部分”。
二、五层结构 Agent 的解剖图
一个完整的 Agent 系统,通常可以拆成五个核心层级。这五层是本专题后续所有章节的地图——每一章基本都是在深挖其中某一层。
| 层级 | 角色 | 负责什么 | 本专题对应 |
|---|---|---|---|
| 模型层 (LLM) | 认知中枢 | 理解意图、推理、生成决策 | 第 04 篇 |
| 记忆层 (Memory / Context) | 状态管理 | 短期上下文 + 长期跨会话记忆 | 第 05–07 篇 |
| 规划层 (Planner) | 任务分解 | 把大目标拆成可执行的子任务 | 第 08 篇 |
| 工具层 (Tool / Skill) | 手脚 | 通过 API 调用外部世界 | 第 03、12 篇 |
| 执行层 (Executor) | 落地 | 按规划调用工具、接收反馈、重试 | 第 07、10 篇 |
- 模型层是主要的认知中枢,负责理解自然语言意图、进行推理、生成决策。它是 Agent 的”大脑”,但如上所述,是一个有明显局限的大脑。
- 记忆层负责状态管理。包含短期记忆(当前任务的上下文)和长期记忆(历史交互、经验总结、向量数据库里的业务知识)。很多企业的 Agent 其实还停留在这一层——把知识塞进向量库就叫”有记忆了”。
- 规划层把复杂大目标拆解为子任务。常见技术路径是 ReAct(Reason + Act,思考+行动循环)和思维链(CoT)。现在主流用 ReAct,主要因为它稳定。
- 工具层是 Agent 的手脚。让它能搜网页、读写文件、运行代码、操作终端,或调度 Jira / Slack / GitHub 这类第三方系统。
- 执行层按规划层的步骤调用工具,接收环境反馈(Observation)。报错时根据反馈调整策略重试,直到完成。
需要提醒
认知框架,不是架构约束。真实系统里这些层往往交织在一起——比如模型层其实同时在做规划(决定下一步调什么工具),执行层的反馈又直接喂回模型层。把五层记在脑子里是为了在设计时知道”我现在在处理哪个关注点”,而不是要求你把代码切成五个模块。三、原子
五层结构是宏观地图。但如果要问”Agent 最小的、不可再分的动作单元是什么”,答案是一次工具调用(one tool call)。整个专题后面所有的复杂机制,都是在这个原子上叠加变化。
先厘清一个根本认知:模型不做事,它只写请求;你的代码才做事。
打个比方——一个厨师能读懂餐厅点单,但不会做菜。他写一张单子(“两个炒蛋,吐司不加黄油”)递给后厨,后厨执行,菜做好端回来,厨师装盘上桌。带工具的 LLM 就是这个厨师
”单子”是一个结构化的块,写明调用哪个工具、传什么参数。它自己什么都执行不了。你的应用才是后厨。这个分工一旦装进脑子,你会立刻写出更好的工具、更少的坏 Agent——因为你知道正确性的保证发生在你的代码里,而不是指望模型。
一次工具调用是一个四步往返:
sequenceDiagram
participant App as 你的应用
participant LLM as 模型
participant Tool as 工具函数
App->>LLM: 用户消息 + 工具定义(schema)
LLM-->>App: tool_use 块(一个请求,不是调用)
App->>Tool: execute(name, arguments)
Tool-->>App: 结果
App->>LLM: tool_result 消息(带同一个 id)
LLM-->>App: 最终回答
- 描述工具——每个工具有名字、描述、参数的 JSON Schema。
- 模型发出请求,响应里会有一个结构化块(Anthropic 叫
tool_use,OpenAI 叫tool_calls),带唯一id、工具名和参数。 - 你来执行,校验参数,运行,拿到结果。
- 把结果喂回去
tool_result消息,引用同一个id。模型现在有了答案,写出最终回复。
不管这个工具是查天气、查数据库,还是跑一条 shell 命令,协议完全一样。线上的数据格式不关心工具做什么——你才关心。
这个原子里藏着几个后面会反复出现的工程原则,值得现在就记住:
- Schema 就是契约。工具描述是模型使用这个工具的唯一指引。一个含糊的描述(“获取天气”)会让模型在错误的时机调用;一个精确的描述(“返回单个城市的当前天气,不要用于历史数据查询”)能大幅减少误用。
- Schema 和函数必须同步移动。最常见的静默失败是 schema 漂移
city改成location,但 schema 还写着city。模型忠实地发出,你的分发代码把它传给期望location的函数,运行时炸掉——而看了 schema 的模型完全不知道为什么。改一个,就要在同一个 commit 里改另一个。 - 错误是消息,不是异常。模型偶尔会发错参数,函数也可能运行失败(文件不存在、超时)。这些都不该让对话崩溃。正确做法
tool_result返回,别抛异常;函数运行失败也一样,返回一条模型能读懂的错误消息,而不是堆栈跟踪。模型很擅长从它能读懂的错误里恢复,但没法从杀死进程的错误里恢复。 - 大结果不要内联。一个返回 50KB 的 grep、一个读出 2MB 的文件,会撑爆上下文窗口、拖垮 prompt 缓存。生产做法,就给模型一个摘要 + 一个指针,把完整内容存到模型可以按需索取的地方。
四、AI 编程工具的演进,就是”给 LLM 更多行动能力”
把镜头拉远看时间线,能更清楚 Agent 在技术谱系里的位置。AI 编程工具的演进,可以简化成三个阶段:
- 网页对话 ChatGPT 引领,把需求或代码片段发给它,生成后手动复制粘贴回工程、手动编译调试。LLM 只能”说话”,不能”做事”。
- 插件工具 出道后瞬间爆发,代码自动补全、AI 自动识别工程并直接修改本地代码,无需手动复制粘贴。
- Agent 托管 Code、Codex 开创全托管模式——AI 不仅编码提交,还能自动测试、发布产物,配合自定义 Skill、MCP 无所不能。
这条线揭示了一个规律:AI 编程工具的演进方向,始终是”给 LLM 更多的行动能力”。从只能看当前文件,到能看整个项目;从只能生成建议,到能执行命令;从单步操作,到多步自主规划。
而”给 LLM 更多行动能力”这件事一旦认真做,就会催生一整套工程问题——工具怎么注册、参数怎么校验、权限怎么管控、错误怎么恢复、状态怎么保持、并发怎么调度。这些问题的系统性解法,就是本专题反复会提到的一个概念:Agent Harness(第 10 篇专门讲)。
小结
- Agent 是能自主完成任务的软件系统,不是聊天机器人。“自主”的难点不在”少干预”,而在”达成目标”。
- 造 Agent 是系统工程。放弃”让模型领悟”的幻想,转而用系统设计去约束它的行为。
- 宏观上,Agent 有五层结构、记忆、规划、工具、执行。这是本专题的地图。
- 微观上,Agent 的原子是一次工具调用,你的代码做事。Schema 是契约,错误是消息,大结果要外置。
- AI 编程工具的整条演进史,就是不断”给 LLM 更多行动能力”的历史,而这最终指向 Agent Harness。
下一篇,我们把这个”一次工具调用”的原子放进一个循环里——那就是 Agent 的心跳。而循环里最难的部分,不是怎么开始,而是怎么停下来。
本篇主要参考:
- 《回顾 Agent 的来时路以及它将何去何从》(Agent 定义与五层结构)
- Agentic System Course ch01 “One tool call”(一次工具调用的四步往返)
- Datawhale《Hello Generic Agent》(GA 的能力类与工具设计)
- 《御舆 Agent Harness》ch01(AI 编程工具演进时间线)
