这两年，大家都在聊 Agent。
如果不了解它的实现原理，很多人很容易把 Agent 理解成“更聪明一点的大模型”。这种理解作为直觉不算错，而从技术实现上看，更准确的说法是：Agent 不是模型本身，而是一套围绕模型组织起来、能持续推进任务的运行机制。
当然，模型本身依旧很重要，它负责理解问题、做出判断，并决定下一步可能该怎么走。
但任务如何持续推进、工具调用如何发生、结果如何被记录、下一轮又如何接着继续，这些并不是模型自己凭空完成的，而是由模型之外的状态、工具和运行时共同组织起来的。
这篇文章主要想讲清三件事：
- Agent 和大模型到底是什么关系
- 工具调用在真实系统里到底是谁发起、谁执行、谁接结果
System Prompt、AGENTS.md、Skill、Tool这些东西究竟分别是什么
1、Agent 是 LLM 吗？
很多人第一次接触 Agent，最容易犯的错误，就是把它直接等同于模型。
如果你把 Agent 当成一个会自己做事的模型，后面很多东西就会越看越乱。
比如：为什么模型能说“去查一下文件”，但真正读文件的是外部系统？为什么工具跑完之后，结果还要回到系统里，再进入下一轮判断？为什么同一个模型，接上不同的规则、工具和状态管理，表现会差这么多？
要回答这些问题，最核心的一点是：模型只是推理核心，不是整个 Agent。
更准确地说，Agent 是一套围绕模型组织起来的运行机制。用户给出任务后，系统会先根据当前目标和已有状态组织本轮上下文，再把这些信息交给模型判断下一步。如果模型认为需要调用工具，就发出 tool call 请求。真正执行工具的是外部运行时或平台能力，执行结果再写回状态或会话记录，随后系统重组下一轮上下文，继续推进任务。
flowchart TB
U["用户任务"]
A["Agent Controller
状态管理 / 决策控制 / 下一步编排"]
C["State / Context
当前目标 / 历史 / 中间结果"]
M["LLM
理解、推理、判断下一步"]
F["最终回答"]
subgraph E["执行环境"]
TC["Tool Call Request"]
R["Runtime / Orchestrator
执行调用、管理回传"]
T["Tools
Read / Edit / Search / Shell"]
O["Tool Result / Observation"]
end
U --> A
A <--> C
A -->|带着上下文调用| M
M -->|需要工具时发出请求| TC
TC --> R --> T
T --> R --> O
O -->|写回状态 / 上下文| C
M -->|形成阶段性结论| A
A -->|输出结果| F
Function calling 可以看作 Tool Use / Tools 体系中的一种具体形式，底层工作机制是一样的：模型发出工具调用意图，外部系统执行，再把结果回传给模型继续下一轮。OpenAI 关于 function calling 的文档就是这套流程。Anthropic 的 tool use 机制也类似，只是它进一步区分了 client tools 和 server tools。
所以可以把它理解成：模型更像“大脑”，而 Agent 是“大脑 + 外部记忆 + 控制循环 + 执行回路”组成的整套系统。
2、Agent 核心机制：状态和控制循环 + 工具
如果顺着上一节继续往下看，一个很自然的问题就是：为什么模型接上工具之后，不一定就能叫 Agent？
因为工具只是其中一环，它负责把动作落到外部世界。
真正让 Agent 跑起来的，通常不只是工具，而是三样东西一起配合：状态、控制循环、工具。
状态负责记住任务做到哪了，控制循环负责决定下一步怎么走，工具负责真正动手。
尤其在多步任务、长流程、可恢复执行这些场景里，这三者往往缺一不可。
flowchart TB
A["工具只是其中一环
它负责把动作落到外部世界"] --> B["Agent 真正能跑起来
靠的是三部分协同"]
B --> C["状态
记住做到哪了"]
B --> D["控制循环
决定下一步怎么走"]
B --> E["工具
真正执行外部动作"]
C:::state
D:::loop
E:::tool
B:::core
A:::desc
2.1、状态
从软件系统视角看，大模型更像一个不自带持久任务状态的推理单元。它每一轮都是读取当前被提供的上下文，然后生成下一步结果。真正的任务状态、流程进度和历史记录，通常不保存在模型内部，而是由 Agent 运行时或外部状态系统维护。
到下一轮再调用模型时，系统不一定会把所有历史原样重塞一遍，而是更常见地从状态里挑出和当前决策最相关的那部分，重新组装成上下文交给模型。
flowchart TB
U([用户目标 / 当前任务]) --> A
subgraph AR[Agent 运行时]
direction TB
A[状态记录
工作台记录]
B[上下文组装
挑出当前最相关的一页]
C[任务进度 / 已确认结论 / 中间结果]
A --> B
C --> A
end
B --> M[大模型
无状态推理单元]
M --> D{下一步要做什么？}
D -->|直接回答| R[输出当前结论]
D -->|调用工具| T[工具 / 检索 / 文件读取]
T --> X[工具返回结果]
X --> A
R --> A
A -. 不把全部历史原样重塞 .-> B
N[没有状态会怎样？
查完就忘、判断重复、流程难以持续推进]
N:::warn
M -. 仅靠上下文窗口难以稳定推进长任务 .-> N
所以，状态更像 Agent 的“工作台记录”，而上下文则是每次真正投喂给大模型模型的东西。
纯聊天式做法，本质上是把短期状态粗糙地堆在消息历史里；而有状态的 Agent，会把任务相关状态结构化地保存在外部，再按当前步骤需要选择性地组织上下文。
2.2、控制循环
控制循环听起来有点抽象，其实可以把它理解成 Agent 的工作推进器：
系统先读取当前目标和已有状态，让模型判断下一步该做什么；
如果需要外部信息或动作，就发起工具调用；
拿到结果之后，再结合最新状态判断是继续检索、切换动作，还是直接产出结果；
然后进入下一轮，直到任务完成。
在这个流程中，关键不在于“会不会调工具”，而在于它每一轮都会根据当前状态重新决定下一步。
从工程实现上看，这也是 Agent 和普通聊天式交互的一个关键差异：前者围绕目标持续推进，后者更多是一问一答。
flowchart TB
A[(状态)] --> B[控制循环]
B --> C[模型决策]
C --> D{下一步}
D -->|调用工具| E[工具]
E --> A
D -->|直接产出| F[结果]
F --> A
所以，Agent 真正的骨架，不只是“模型 + 工具”，而是状态负责记住任务做到哪了，控制循环负责决定下一步怎么走，工具负责把动作落到外部世界。
模型当然依旧是很重要的，没有模型，就根本不会有Agent，但它更像循环里的决策核心，而不是 Agent 的全部。
2.3、工具
工具本身并不神秘，它们只是 Agent 接触外部世界的接口。
真正决定这些能力能不能在多步任务里被持续、正确地使用的，不只是工具本身，而是状态管理和控制循环。
像 LangGraph 这类框架，重点就在于如何让状态在执行中持续演化、如何让流程可恢复、可中断、可继续；而 AutoGen 这类框架，也明确支持多轮工具调用迭代。
所以从运行原理上看，工具更像最后那只手：状态负责记住做到哪了，控制循环负责决定下一步怎么走，工具负责把动作真正落到外部世界。
flowchart TB
G([用户目标 / 任务]) --> S
G --> L
subgraph CORE[Agent 核心机制]
direction TB
S[(状态
记住做到哪了)]
L[控制循环
决定下一步怎么走]
M[模型决策
判断 / 规划 / 选择动作]
D{是否需要外部动作?}
S --> L
L --> M
M --> D
end
D -->|需要| T[工具层
读文件 / 搜内容 / 改代码 / 跑命令]
D -->|不需要| O[直接产出结果]
T --> R[工具返回 / 新观察]
R --> U[写回状态]
O --> U
U --> S
S -. 驱动下一轮判断 .-> L
N[一句话概括
没有状态，记不住事
没有循环，推不动任务
没有工具，伸不出手]
N:::note
CORE --- N
3、规则、技能、工具都是什么？
上面两节我们已经看到，Agent 不是模型本身。它能跑起来，靠的是状态、控制循环和工具。
但继续往下看，很快又会遇到另一组容易混在一起的概念：System Prompt、AGENTS.md、Skill、Tool。
它们看起来都像“给模型的说明”，但职责其实并不一样。
有的负责定义高优先级规则，有的负责沉淀仓库经验和协作约束，有的负责封装可复用流程，有的负责真正调用外部能力。
真正把这些东西组织起来、让它们在一次次执行中接上状态、接上工具、接上结果回流的，是 Agent 的运行时和编排层。
所以，也不能简单的把他们混谈为提示词，因为各自的职责还是不一样的。接下来我们就把它们放回各自该在的位置来说说。
在下图中，System Prompt、AGENTS.md、Skill、Tool 不是同一种东西。
flowchart TD
U["用户任务"]
subgraph I["规则层"]
SP["System Prompt
定义全局角色、目标、安全边界"]
AG["AGENTS.md
定义项目约束、目录规则、仓库约定"]
end
subgraph K["能力包层"]
SK["Skill
定义某类任务的标准流程"]
SR["Skill 附带资源
SKILL.md / scripts / references / assets"]
end
subgraph D["决策层"]
X["State / Context Assembly
上下文组装 / 状态更新"]
A2["Agent Controller
组织上下文、控制流程"]
M2["LLM
基于上下文推理并决定是否调用工具"]
end
subgraph C["执行层"]
TC2["Tool Call Request"]
TL["Tools
Read / Edit / Search / Shell"]
RT["Runtime / Orchestrator
执行调用并回传结果"]
RS["Tool Result / Observation"]
end
OUT["最终回答 / 最终修改"]
U --> X
SP --> X
AG --> X
SK --> X
SR -.作为 Skill 资源.-> SK
X --> A2
A2 --> M2
M2 -->|可直接形成结果| OUT
M2 -->|需要工具时发起| TC2
TC2 --> RT
RT --> TL
TL --> RT --> RS
RS --> X
M2 --> A2
System Prompt 更准确地说，是系统级或开发者级的高优先级指令，用来规定模型从一开始就该遵守什么行为、语气和边界。
AGENTS.md 更像项目现场的本地规则。在 Codex 里，它会按目录层级被发现和加载，离当前工作目录越近的规则优先级越高。目录约定、哪些文件不要乱改、测试命令怎么跑、仓库里的特殊做法，通常适合放在这里。
Skill 不是单独一段提示词，而更像一套可复用的经验包。它通常以 SKILL.md 为入口，必要时还可以带脚本、参考资料和模板，用来固化某类任务的常见做法。
Tool 则是真正负责动手的能力接口。它负责读外部数据、调用服务、执行代码，或者把动作落到外部世界。
所以可以把它们理解成这样：高层规则负责约束行为，本地规则负责贴近项目现场，技能负责沉淀方法，模型负责判断，工具负责执行，而运行时负责把这一切串成一条真正能跑起来的链路。
这也是为什么同一个模型，换一套规则、换一组技能、换一种运行时组织方式，最后表现可能完全不是一回事。
4、那么多Agent框架究竟如何掌握？
如果把 OpenAI、Anthropic 这类模型平台，以及 LangGraph、AutoGen 这类 agent 框架放在一起看，会发现它们虽然分层不同，但底层逻辑其实有很多相似之处。
OpenAI 和 Anthropic 更偏模型平台、工具协议和平台级 agent 能力这一层。它们重点定义的是：模型如何表达工具调用意图，工具如何接入，结果如何回流，以及平台如何提供内建工具、上下文管理和 agent 能力。
LangGraph 更偏流程编排和运行时这一层。它关心的是状态怎么保存、节点怎么流转、执行怎么中断和恢复、长流程怎么保持可控。
AutoGen 更偏事件驱动的多 agent 框架这一层。它强调的是 agent 之间如何通过消息协作，如何形成连续推进的系统，以及多轮工具调用和多 agent 交互如何被组织起来。
OpenAI Agents SDK 则进一步把不同来源的能力显式区分成 hosted tools、function tools、agents as tools 和 MCP servers。
看起来大家讲法很多，但如果只抓住最核心的一条线，其实都绕不开同一件事：
模型负责局部决策，运行时负责组织状态与流程，工具负责连接外部世界，结果再回到系统里推进下一步。
flowchart TB
A[上下文 / 状态]
B[模型判断]
C[工具调用]
D[运行时执行]
E[Observation 回写]
A --> B
B -->|需要工具| C
C --> D
D --> E
E --> A
B -->|无需工具| F[直接输出结果]
- 先根据当前目标和状态组织本轮上下文
- 再让模型判断下一步
- 需要时发出工具请求
- 由应用运行时或平台侧执行工具
- 执行结果写回状态，并重组下一轮上下文
- 再继续下一轮
这套机制不管换哪家平台或框架，基本都成立。差别主要在于：哪家把这套机制封装得更深，哪家给你的控制权更多，哪家更适合长流程和状态恢复，哪家更适合代码、命令和开发型任务。
5、说在最后
如果要一句话概括 Agent，可以这么理解：Agent 不是一个更会聊天的大模型，而是一套让模型能持续推进任务的运行机制。
模型负责判断，工具负责执行，运行时负责把流程串起来，状态负责记住任务做到哪了；规则负责约束行为并提供上下文，技能负责沉淀可复用做法。
当你从这个视角去看，很多概念就会一下子变清楚：
- 为什么 function calling 不等于模型自动执行
- 为什么 Skill 不等于 Tool
- 为什么有些框架更强调状态和流程，有些更强调工具协议和接入方式
- 为什么 coding agent 特别依赖项目规则、能力包和可复用工作流
