有人问："Agent 和普通大模型，到底有什么区别？"很多人的回答是：Agent 会调用工具、会规划任务、会自己执行。这个答案不能算错，但只说到了表面。

普通大模型更像一个知识丰富的顾问，你问一句，它回答一句。Agent 则更像一个能够持续工作的执行者，它会读取任务、判断下一步、调用工具、观察结果，再决定下一步做什么，直到任务完成或者触发停止条件。

OpenAI 对 Agent 的定义，也已经不再局限于一个模型，而是由模型、指令、工具、护栏、任务交接等要素共同组成的系统。所以，真正的 Agent 工程，研究的并不是"怎么写一个更长的 Prompt"。它研究的是：如何把一个输出具有不确定性的模型，装进一套可控制、可恢复、可观测的运行系统里。

一个完整的 Agent，大致可以抽象成下面这条链路：接收目标 → 读取上下文 → 判断下一步 → 调用工具 → 获取结果 → 更新状态 → 继续判断 → 完成或停止。看懂这条链路，下面 20 个概念就不难理解了。

一、Agent 的大脑是怎么转起来的？

1. Agent Loop：智能体循环

Agent Loop，可以理解为 Agent 的"工作循环"。普通聊天模型通常只执行一次：用户输入 → 模型生成答案。Agent 则会反复执行：模型判断 → 调用工具 → 获取结果 → 再次判断。

例如，你让 Agent 分析本月销售下降的原因，并生成一份汇报材料。它可能先读取销售数据，再查询客户流失情况，接着分析产品、区域和渠道差异，最后生成文档。每完成一步，结果都会重新交给模型，模型根据新信息，再决定下一步。

OpenAI Agents SDK 中的 Runner，负责管理模型轮次、工具调用、任务交接和会话状态，本质上就是在运行这套循环。因此，Agent 首先不是一个"回答器"，而是一台不断重复"判断—行动—观察"的状态机。

2. Instructions：运行指令

Instructions 通常翻译为系统指令，也就是我们常说的 System Prompt。但在 Agent 工程里，它不只是告诉模型"你是谁"，还要明确五件事：你要完成什么目标；你可以使用哪些工具；哪些事情不能做；什么时候需要询问用户；什么条件下算任务完成。

例如："你是一名经营分析 Agent，需要根据企业数据识别异常。涉及修改原始数据时必须先获得用户确认，最终输出需要包含结论、依据和建议。"这已经很像一份岗位说明书。

Instructions 写得不清楚，Agent 就容易出现两类问题：一类是不知道自己该做什么，遇到问题就停下来询问；另一类是权限感过强，未经确认就修改文件、发送消息或执行高风险操作。因此，Agent 指令的核心不是"写得多"，而是把职责、边界和完成标准写清楚。

3. Context Window：上下文窗口

上下文窗口，是模型一次能够看到的信息范围。里面可能包括：用户当前的任务、系统指令、历史对话、工具说明、文件内容、工具返回结果、Agent 已经完成的步骤。可以把上下文窗口理解成 Agent 面前的一张工作台。工作台越大，能同时摆放的材料越多。但工作台再大，也不应该把仓库里的所有东西全部搬上来。

因为上下文越长，通常意味着：推理成本更高、响应速度更慢、关键信息更容易被淹没、历史错误可能持续影响后续判断。而且，Agent 调用工具时产生的输入、输出以及部分推理内容，同样会占用上下文。所以，上下文工程的核心不是"塞得越多越好"，而是在正确的时间，把正确的信息放进来。

4. State：运行状态

State 指的是 Agent 在当前任务中，需要持续保存的结构化信息。比如一个采购分析 Agent 的 State 中，可能包含：当前任务目标、已查询的供应商、已获得的报价、缺失的数据、当前执行步骤、待用户确认的事项、已经产生的文件。

State 和聊天记录并不是一回事。聊天记录是一串自然语言消息，State 则更像一张实时更新的任务表。例如：当前阶段是供应商比价，已完成查询 A、B、C 三家报价，待完成核对交货周期，风险是供应商 B 缺少税费说明。有了 State，Agent 才知道自己走到了哪一步，哪些事情已经完成，哪些事情还没有完成。复杂 Agent 经常采用图结构或工作流引擎，本质上就是为了更清晰地管理 State 在不同节点之间的变化。

5. Memory：记忆

State 主要服务于当前任务，Memory 则可能跨任务、跨会话保留信息。例如，一个销售 Agent 可能记住：用户偏好的报告格式、某个客户所属的行业、企业内部的指标口径、上一次会议确定的行动项。

Agent 记忆通常可以分为两类：第一类是短期记忆，也就是当前会话和任务中的信息；第二类是长期记忆，即写入数据库、向量库或用户档案，未来执行任务时再检索出来。但记忆不是越多越好。如果 Agent 把每一句话都永久保存，旧信息、错误信息和无关信息就会不断积累。真正成熟的记忆机制，需要回答三个问题：什么值得记？什么时候读取？什么时候应该删除或更新？

二、Agent 是怎么使用工具的？

6. Tool：工具

Tool 是 Agent 可以调用的外部能力。例如：查询数据库、搜索网页、读取文件、执行代码、发送邮件、创建日程、操作浏览器、调用业务系统接口。

大模型本身并不会真正发送邮件，也不会直接修改 CRM。它只能表达："我现在需要调用'发送邮件'工具，收件人是某某，正文是某某。"真正的操作仍然由外部程序执行。官方工具文档也将工具描述为让 Agent 获取数据、运行代码、调用 API 和操作计算机的能力。所以，工具是 Agent 从"会说"走向"会做"的关键。没有工具的 Agent，能力再强，也只能停留在文本生成层面。

7. Function Calling：函数调用

Function Calling 是模型调用工具的一种标准方式。开发者先告诉模型：系统中有一个查询订单的函数，需要传入订单编号。模型判断需要使用这个函数后，不会直接编造查询结果，而是生成一段结构化参数，例如 {"order_id": "A20260710001"}。应用程序拿到参数，调用真实接口，再把接口结果交回模型。

因此，Function Calling 解决的是：模型如何清楚地表达"我要调用哪个工具，以及需要传什么参数"。它并不等于工具已经执行成功。模型负责做出调用决定，应用系统负责执行，权限系统负责判断能不能执行。这三层必须分开。

8. Structured Output：结构化输出

普通大模型擅长输出自然语言，但计算机系统更喜欢固定格式。如果模型一会儿输出 JSON，一会儿输出 Markdown，一会儿又在前面加一句解释，后面的程序就很难稳定解析。Structured Output 的作用，就是要求模型严格按照预先定义的字段和数据类型返回结果。

它常被用于：工具调用参数、数据抽取、分类结果、工作流节点输出、Agent 之间的数据传递。Function Calling 更关注"调用什么动作"，Structured Output 更关注"输出必须长什么样"。两者看起来相似，但解决的问题不同。

9. Observation：观察结果

工具执行完成后，会返回一个结果。这个结果在 Agent 运行机制中，经常被称为 Observation，也就是"观察"。例如，Agent 调用查询库存工具后，得到：华东仓库存 120 件，华南仓库存 0 件。模型读取这个结果后，才知道下一步应该调拨库存、提醒补货，还是继续查询在途订单。

因此，一次完整的工具调用至少包含三步：Action 决定调用工具、Execution 系统执行工具、Observation 把结果返回给模型。很多 Agent 失败，并不是模型不会调用工具，而是工具返回的信息太乱。例如返回几万行日志、整张数据库表，或者包含大量无关字段。因此，工具结果最好经过清洗和压缩，只保留模型做下一步判断真正需要的信息。

10. Routing：路由

Routing 指的是根据任务特点，把请求分配给合适的模型、工具或 Agent。例如：普通问答交给低成本模型，复杂分析交给推理模型，查数据交给数据 Agent，修改代码交给编程 Agent，涉及退款交给售后 Agent。

路由可以由固定规则完成：只要涉及退款，就进入退款流程。也可以由模型判断：根据用户意图，选择最适合的处理模块。通常，越高风险、越明确的场景，越适合使用固定规则；越开放、越难提前穷举的任务，越适合让模型参与判断。成熟的 Agent 系统不会让一个模型负责所有事情，而是根据任务难度、成本和风险进行分流。

三、复杂任务是怎么被组织起来的？

11. Planner-Executor：规划器与执行器

复杂任务往往不能直接开始做，需要先制定计划。于是，Agent 系统中出现了两个角色：Planner 负责想清楚做什么，Executor 负责把每一步执行完。例如，用户要求分析竞争对手并形成一份市场进入报告。Planner 可能先拆成：确定竞争对手范围、收集产品和价格信息、分析客户与渠道、比较竞争优势、形成进入建议，Executor 再逐项完成。

把规划和执行分开，有两个好处：第一，避免 Agent 一上来就盲目调用工具；第二，任务出现变化时，可以重新调整计划，而不必推翻所有结果。但计划也不能写得过细。如果 Agent 在执行前就试图规划几十步，前面任何一个假设发生变化，后面的计划都会失效。所以，更实用的方式是：先做粗计划，执行几步，再根据结果动态调整。

12. Reflection：反思

Reflection 常被翻译为反思、自检或复盘。它并不代表模型真的拥有自我意识，而是让模型在得到结果后，再执行一次检查。例如：是否回答了用户的全部问题？数据是否有来源？计算结果是否一致？工具是否调用错误？输出格式是否符合要求？

免费试用

在编程 Agent 中，Reflection 可能表现为运行测试、检查报错，再修改代码。在数据 Agent 中，可能表现为核对总数、明细和口径是否一致。适当的 Reflection 可以提高结果质量。但如果没有停止条件，Agent 也可能反复质疑、不断重写，陷入自我循环。因此，Reflection 需要设置预算，例如最多检查两轮，或者达到质量标准后立即停止。

13. Handoff：任务交接

免费试用

Handoff 指当前 Agent 把任务控制权交给另一个专业 Agent。例如，客服 Agent 识别到用户要求退款后，将任务交给退款 Agent。交接后，退款 Agent 负责后续流程，原来的客服 Agent 不再主导。OpenAI Agents SDK 中，Handoff 也被表示为一种可供模型选择的特殊工具，适合将任务转交给不同领域的专业 Agent。

Handoff 强调的是"换负责人"。这和普通工具调用不同。调用计算器后，原 Agent 仍然负责整个任务；Handoff 之后，另一个 Agent 接管任务并产生最终结果。

14. Sub-agent：子智能体

Sub-agent 是由主 Agent 调用的专业 Agent。例如，一个研究报告 Agent 下面可以有：搜索 Agent、数据分析 Agent、财务分析 Agent、写作 Agent、审核 Agent。主 Agent 把一个子任务交给子 Agent，子 Agent 完成后将结果返回，最终控制权仍然回到主 Agent。

这与 Handoff 的区别在于：Handoff 是把整个任务交出去，Sub-agent 是把其中一部分工作外包出去。主 Agent 更像项目经理，子 Agent 更像专业成员。

15. Parallel Execution：并行执行

当多个任务互不依赖时，可以同时执行。例如，分析一家公司的经营情况，可以并行完成：搜索行业信息、查询财务数据、收集竞争对手资料、整理管理层信息，最后再汇总结果。

这种模式通常被称为 Fan-out 和 Fan-in：Fan-out 把任务分发出去，Fan-in 把结果汇总回来。并行可以缩短任务时间，但会增加协调难度。如果多个 Agent 同时修改同一份文件、更新同一条数据，就可能发生冲突。因此，并行任务需要明确：输入是否独立、输出写到哪里、如何处理冲突、某个分支失败后是否影响其他分支。LangGraph 等工作流框架已经支持并行节点执行、状态持久化和中断恢复。

四、Agent 怎么连接外部世界？

16. MCP：模型上下文协议

MCP 全称 Model Context Protocol，模型上下文协议。它解决的问题是：不同 Agent 应用，怎么用一套统一方式连接外部工具和数据？过去，每接一个数据库、网盘、代码仓库或业务系统，开发者都要单独适配接口。MCP 试图提供一套统一标准。

一个 MCP Server 通常可以向 Agent 提供三类能力：Resources 可读取的数据和上下文、Tools 可以执行的操作、Prompts 预先配置的任务模板。MCP 官方将其比喻为 AI 应用的"USB-C 接口"：应用只要支持这套协议，就可以用相对统一的方式接入文件、数据库、搜索引擎和业务系统。简单理解：MCP 主要解决 Agent 如何连接工具和数据。

17. A2A：智能体之间的通信协议

A2A 全称 Agent2Agent Protocol。它解决的是另一个问题：两个来自不同系统、不同厂商的 Agent，怎么互相发现、通信和委托任务？例如，企业采购 Agent 需要联系供应商 Agent，查询报价和交付周期。它不需要知道供应商 Agent 内部用了什么模型、什么数据库、什么工作流，只需要按照统一协议发送任务和接收结果。A2A 规定了 Agent 如何描述自己的能力、如何发现对方、如何传递任务、如何返回状态和结果。

MCP 和 A2A 很容易混淆，可以用一句话区分：MCP 连接 Agent 与工具，A2A 连接 Agent 与 Agent。一个解决"怎么干活"，一个解决"怎么协作"。

五、Agent 怎么在真实环境中稳定运行？

18. Checkpoint 与 Durable Execution：检查点和持久化执行

Agent 任务可能持续几分钟、几小时，甚至等待用户几天后再继续。中间可能遇到：服务重启、网络中断、工具超时、用户暂未审批、某一步执行失败。如果每次失败都从头开始，成本高，也容易产生重复操作。

Checkpoint 就是在关键步骤保存当前状态。例如：任务已完成到第 4 步，数据已下载，分析结果已生成，等待负责人审批发送邮件。系统恢复后，可以从这里继续，而不用重新查询和分析。Durable Execution 则进一步保证任务即使跨越进程重启、长时间等待和多次重试，也能继续运行。OpenAI Agents SDK 和 LangGraph 都提供了持久化、暂停、恢复及长任务编排机制。

这里还要特别注意幂等性。假设发送邮件成功后系统突然断线，Agent 恢复时再次执行"发送邮件"，用户就会收到两封。所以，真实系统必须能够识别：这一步到底没执行，还是已经执行成功，只是结果没有被记录？

19. Human-in-the-loop 与 Guardrails：人工介入和运行护栏

Agent 自主执行，并不代表所有操作都应该自动完成。以下操作通常需要人工确认：删除数据、发送正式邮件、对外发布内容、转账或退款、修改生产环境、提交法律或财务文件。

Human-in-the-loop 就是在关键节点暂停 Agent，让人批准、拒绝或修改后再继续。OpenAI 的 HITL 机制允许工具声明是否需要审批；当敏感工具被调用时，运行会暂停，保存当前状态，等人工决策后再恢复。

Guardrails 则是更广泛的护栏机制。它可以检查：用户输入是否违规、工具参数是否危险、Agent 是否越权、输出是否泄露敏感信息、调用频率和金额是否超过限制。简单来说：Human-in-the-loop 负责让人在关键时刻接管，Guardrails 负责让 Agent 始终在边界内运行。

20. Tracing 与 Evals：运行追踪和评测

普通应用出错，可以查看代码日志。Agent 出错更麻烦，因为它可能经历了多轮模型判断、工具调用、任务交接和状态变化。所以，需要 Tracing 记录完整运行轨迹，包括：模型每轮输入与输出、调用了哪个工具、工具参数是什么、返回了什么结果、发生了哪次 Handoff、哪个护栏被触发、每一步用了多长时间和多少 Token。OpenAI Agents SDK 的 Tracing 会记录模型生成、工具调用、Handoff、Guardrails 等运行事件，用于开发调试和生产监控。

但看到过程还不够，还要判断 Agent 做得好不好。这就是 Evals。评测一个 Agent，不能只看最终答案，还要看执行轨迹。例如：是否选对了工具、是否调用了不必要的接口、是否重复执行、是否走了高成本路径、是否在应该询问用户时擅自决定、最终结果是否准确。当前 Agent 评测已经开始从"评答案"，转向同时评估最终结果、单个步骤和完整工具调用轨迹。没有 Tracing，很难定位问题；没有 Evals，很难知道修改 Prompt、模型或工具后，Agent 究竟变好了还是变差了。

把 20 个概念串起来，Agent 到底是怎么运行的？

假设用户提出一个任务：分析本月销售下降的原因，并生成汇报材料。

Agent 首先读取 Instructions，明确任务目标、权限和输出标准。然后加载 Context，获取用户问题、指标口径和必要的历史信息。系统创建 State，记录当前步骤和任务进度，并从 Memory 中读取用户偏好的报告格式。Planner 将任务拆成销售趋势、产品结构、区域表现和客户流失等分析步骤。Routing 判断哪些任务交给数据 Agent，哪些交给搜索 Agent。Agent 通过 MCP 连接数据库和文件系统，使用 Function Calling 生成查询参数。工具执行后返回 Observation，结果按照 Structured Output 写入 State。多个独立分析任务通过 Sub-agent 并行执行，主 Agent 负责汇总。如果需要将某项专业任务完全交给财务 Agent，则触发 Handoff。生成结果后，Reflection 模块检查数字、逻辑和格式。执行过程中，Checkpoint 持续保存状态；发生中断时，Durable Execution 从最近节点恢复。涉及发送邮件或发布报告时，Human-in-the-loop 要求负责人审批，Guardrails 检查权限和敏感信息。最后，Tracing 记录整条链路，Evals 判断任务结果和执行路径是否达标。

这才是一套完整的 Agent 运行机制。

写在最后

很多人学习 Agent，最容易陷入一个误区：只关注模型够不够聪明。但真正进入工程落地后，模型只是一部分。Agent 能否稳定完成任务，更取决于上下文怎么组织、状态怎么保存、工具怎么定义、任务怎么拆分、失败后怎么恢复，以及高风险操作怎么控制。

模型能力越强，能完成的任务越复杂；任务越复杂，对工程系统的要求也越高。所以，Agent 工程真正要解决的问题，可以浓缩成一句话：把模型的不确定性，装进一套尽可能确定的运行机制里。搞懂这 20 个概念，才算真正迈进 Agent 工程的大门。