什么是 Agent？

什么是 Agent？深入理解智能体的五个核心组成

大语言模型可以回答问题、编写代码、分析资料。但如果你希望它根据一个目标持续工作，主动获取信息、调用工具、记住进度，并在失败后调整方案，就需要把模型组织成一个能够自主执行任务的系统。

在大模型应用的语境下，Agent（智能体）是一套以 LLM 为"大脑"，围绕目标自主选择行动，并依据执行反馈持续推进任务的系统。

Agent ≈ LLM + 规划能力 + 工具调用 + 记忆 + 执行反馈循环

这条公式可以作为理解现代 LLM Agent 的主线：LLM 负责理解和决策，规划负责拆解目标，工具负责执行动作，记忆负责保持连续性，反馈循环负责根据实际结果修正下一步。

这里的"自主"，指系统在给定目标、权限和资源范围内，自行选择并推进部分执行步骤；并不意味着拥有意识，也不意味着可以无限制行动。本文讨论的是 LLM Agent，更广义的智能体还包括机器人、游戏智能体等。

公式中的"≈"表示一种功能模型，而非严格定义或五个独立模块的清单。规划可以体现为逐步决策，记忆可以只是当前任务的执行历史；独立规划器和跨会话长期记忆都不是必要条件。

本文面向希望理解 Agent 原理的开发者，重点讨论这五项能力的职责、实现机制和局限，并用同一个故障排查案例说明它们如何协作。

一、为什么 LLM 本身还不等于 Agent？

假设你提出一个需求：

帮我分析订单接口为什么变慢，找到证据并给出修复建议。

仅用于问答的 LLM 应用可能回答："检查日志、数据库慢查询、线程池和最近的发布。"它生成了排查建议，但没有实际完成排查。

Agent 则可以执行一系列动作：

1. 查询监控，确认延迟从什么时候开始上升。
2. 查看日志，判断异常集中在哪些请求。
3. 查询数据库慢 SQL，找到可能的耗时来源。
4. 对照最近发布的代码，提出根因假设。
5. 获取更多证据，验证或推翻假设。
6. 输出结论、依据和修复建议。

普通问答主要围绕一次输入生成输出；Agent 则围绕目标反复执行决策和行动。

基础问答应用：输入 → 模型 → 回答

Agent：目标 → 规划 → 行动 → 观察结果 → 调整 → 继续或结束

工具调用本身也不足以说明一个系统具有自主决策能力。如果程序始终按照"检索资料 → 总结资料"的固定顺序运行，它主要是一条工作流。Agent 的突出特点是能够根据反馈动态选择后续步骤。二者可以结合使用。

二、五个核心组成如何协作？

组成	核心职责	可以怎样理解
LLM	理解目标、分析信息、选择行动	大脑
规划能力	拆解任务、安排步骤、调整路径	任务推进方案
工具调用	获取外部信息、执行实际操作	与环境交互的接口
记忆	保存上下文、进度、事实和经验	持续工作的依据
执行反馈循环	检查结果、修正判断、决定是否继续	连接各部分的闭环

"大脑"等比喻只是帮助理解。工程上，模型通常生成行动请求，由程序执行工具；记忆保存在上下文、文件或数据库中；循环则由运行程序组织。

图中的规划是逻辑职责，并不意味着每一轮都必须额外调用一次规划模型。执行结果需要明确返回下一轮决策，才能形成闭环。

三、LLM：智能体的大脑

1. 它负责什么？

LLM 是 Agent 的理解与决策核心，主要承担四项工作：

• 理解目标：把用户表达转成明确的任务意图。
• 理解信息：解释文档、代码、日志和工具结果。
• 分析问题：提出假设、比较方案、识别缺失证据。
• 选择行动：决定下一步调用什么工具、使用哪些参数，或者是否结束。

例如，工具返回"接口错误率正常，但数据库调用耗时升高"，模型可以据此决定优先检查慢查询。

2. 工作原理

常见的自回归语言模型，根据输入上下文逐步生成 token：

P(y | x) = ∏ᵢ₌₁ⁿ P(yᵢ | x, y₍＜ᵢ₎)

其中，x 是当前上下文，y 是输出序列，y₍＜ᵢ₎ 表示已生成的 token。这个公式描述生成方式，不能单独解释规划能力的来源，也不能保证输出正确。模型的任务处理能力取决于预训练、后训练及推理时的上下文与计算。

在 Agent 中，一轮决策通常经历三步：

1. 程序组织目标、工具说明、执行历史和相关知识，形成输入上下文。
2. 模型利用这些信息生成下一步行动、完成请求或待澄清问题。
3. 程序解析结果，决定如何执行，再把结果交回模型。

为了更清楚地描述这一过程，可以写成：

aₜ ∼ πθ(a | g, cₜ)

这里，g 是目标，cₜ 是第 t 轮可见的上下文，aₜ 是候选行动，πθ 表示由模型参数和生成配置决定的条件分布。这是对决策过程的抽象，并不要求系统使用强化学习，也不要求每轮随机采样。

在 Agent 中，输出可以是自然语言，也可以是结构化行动：

{
  "type": "tool_call",
  "tool": "query_slow_queries",
  "arguments": {
    "service": "order-service",
    "time_range": "last_1h"
  }
}

以上 JSON 是用于说明调用语义的简化示例，不对应某一家模型 API 的响应格式。系统还需要校验这个候选决策，再执行相应操作。

3. 特点与局限

LLM 擅长处理自然语言、不完整信息和难以穷举的情境，因此能够为执行过程提供灵活性。但它的输出具有不确定性：格式正确不代表决策正确，表达自信不代表证据充分。

它可能误判因果关系、选错工具或生成错误参数。模型权重中的知识也不能直接反映当前系统状态，因此需要借助工具获取实时信息。

**LLM 负责提出判断，工具提供外部观察，验证机制检查这些观察是否足以支持判断。**工具也可能返回错误、过期或不完整的数据，因此不能把所有工具输出都当作可靠事实。

四、规划能力：把目标拆成可以执行的任务

1. 它负责什么？

规划把"我要达到什么结果"转化为"接下来应该做哪些事情"。

例如，"定位接口延迟原因"可以拆成：

确认异常时间和范围
    ↓
分析耗时集中在哪一层
    ↓
提出根因候选
    ↓
收集证据验证候选
    ↓
输出结论和建议

好的规划不仅列出步骤，还应说明每一步需要什么输入、产生什么结果，以及依赖哪些前置条件。对于耗时较长的任务，还应明确每个阶段的完成标准。

例如，"检查慢 SQL"过于宽泛；"查询异常时间段内累计耗时最高的 SQL，比较其执行次数与单次耗时"就能直接指导工具选择和参数生成。

2. 工作原理

规划通常由 LLM 根据目标、当前状态和可用工具生成。程序可以将计划保存为任务列表或依赖图，再逐步推进。

常见方式有三种：

方式	原理	特点
先规划再执行	先生成整体计划，再推进各步骤	路径清晰，但需要处理计划过时的问题
逐步规划	每次根据当前信息决定下一步	灵活，但需要防止偏离整体目标
分层规划	先拆阶段，再为当前阶段生成具体动作	适合复杂任务，但增加状态管理成本

这些方式可以组合。例如先生成粗粒度计划，再根据执行结果动态细化下一步。

3. 为什么需要重规划？

现实执行经常出现计划外情况：查询失败、证据不足、假设被推翻、资源不可用。

初始假设：线程池耗尽
    ↓
查询发现线程池正常
    ↓
降低该假设优先级
    ↓
转向检查数据库耗时

规划的价值在于指导行动并随着证据更新。一个始终坚持最初计划的系统，可能会在错误方向上持续消耗资源。

4. 特点与局限

规划提升复杂任务的可管理性，但计划本身也可能有错误。拆得过细，并且为每个步骤单独调用模型时，会增加延迟和成本；拆得过粗又难以执行。

简单任务可以直接行动，无需独立规划器。复杂任务则应持续保留原始目标、已完成事项和未解决问题，避免"步骤执行了很多，目标却没有推进"。

五、工具调用：把模型决策变成实际行动

1. 它负责什么？

工具让 Agent 能够连接外部环境，例如：

• 查询网页、文档和知识库。
• 读取文件、日志和数据库。
• 执行代码和测试。
• 操作浏览器或业务 API。
• 在授权范围内修改文件或业务数据。

没有这些接口，模型通常只能根据输入生成回答，无法独立获取新证据或改变外部状态。

2. 工作原理

Function Calling 的典型过程是：

提供工具名称、用途和参数定义
    ↓
LLM 选择工具并生成参数
    ↓
程序校验格式、权限和执行条件
    ↓
调用实际函数或 API
    ↓
将结果返回 LLM

模型生成工具调用请求，宿主程序负责执行。

例如，模型生成：

{
  "type": "tool_call",
  "tool": "search_logs",
  "arguments": {
    "service": "order-service",
    "keyword": "timeout",
    "limit": 20
  }
}

运行程序将该请求映射到具体日志服务，获得结果后再交给模型分析。

工具接口通常用 Schema 定义输入类型、必填字段和合法范围。结构约束可以减少格式错误，但无法保证服务名真实存在、查询范围合理或业务权限满足要求；这些仍需要程序和后端系统检查。

返回结果应包含执行状态、数据和必要的来源信息。例如，"查询成功且无匹配项"和"查询失败"必须有不同状态，避免模型把执行错误当成业务结论。

3. 为什么工具设计会影响执行可靠性？

工具是模型理解外部能力的入口。如果名称含糊、参数语义不清或错误结果不可区分，模型就难以做出正确选择。

例如，"没有日志"可能意味着查询成功但没有匹配项，也可能意味着查询超时。工具返回结构应区分这两种情况。

清晰的用途说明、参数定义和结果结构，有助于 Agent 选择并正确使用工具。

4. 特点与局限

工具扩展了模型能力，但也把外部系统的故障和副作用带入执行过程。

读取监控与创建订单需要不同的处理方式。尤其是写入操作，必须考虑权限、幂等性和重试：创建订单请求超时，可能只是响应丢失，直接重试可能导致重复订单。

MCP（Model Context Protocol，模型上下文协议）用于标准化 AI 应用连接外部工具和资源的方式；Function Calling 则用于表达模型提出的工具调用请求。二者可以协作，但属于不同层次：前者处理连接与能力暴露，后者处理模型与应用之间的调用表达。MCP 本身不承担 Agent 的规划和决策职责。

六、记忆：让智能体能够持续工作

1. 为什么需要记忆？

任务执行需要连续性。Agent 必须知道用户要求是什么、已经做过什么、哪些假设被排除，以及下一步还缺什么。

如果每一步都丢失历史，它就可能重复查询、忘记限制，甚至推翻已被验证的结论。

2. 记忆有哪些类型？

类型	保存内容	常见实现
短期记忆	当前对话、最近结果、正在使用的资料	模型上下文
任务记忆	计划、进度、证据位置、待办事项	文件、数据库、检查点
长期记忆	用户偏好、项目约定、已确认的历史经验	数据库、搜索索引、向量检索

这是按用途划分的记忆模型，并非统一分类标准。"任务记忆"与工程系统中的任务状态有所重叠，具体实现可以共享存储。

上下文窗口是模型本轮可见的信息集合，外部记忆则可以远大于窗口。它们通过检索和上下文构建连接起来：存在数据库里的信息，如果没有被加载，就不能直接影响本轮推理。

3. 工作原理

长期记忆通常遵循以下过程：

筛选值得保存的信息
    ↓
记录来源、时间和适用范围
    ↓
持久化存储
    ↓
相关任务到来时检索
    ↓
加入当前上下文
    ↓
更新或删除过期信息

向量检索的一种常见做法，是将文本编码为向量，通过相似度召回候选记录，再经过筛选或重排序，将相关片段交给模型使用。但语义相似不等于事实正确，还需要检查权限、时效和来源。

记忆被存储下来之后，仍需在相关时刻被读取，才能影响当前决策。

4. 上下文过长怎么办？

执行过程会不断累积工具结果和历史信息。系统可以压缩旧记录、保留结构化笔记，并按需加载详细证据。

例如，保留"线程池正常，证据位于某监控查询结果"，而不必每轮都重复输入全部监控数据。关键原始证据仍应保存在外部，方便复查。压缩时应优先保留目标、限制、已确认事实、证据引用和未完成事项；摘要可能丢失细节，所以关键结论仍需能够追溯到原始资料。

5. 特点与局限

记忆提升连续性，也可能传播错误。需要区分：

假设：延迟可能与索引有关。
事实：执行计划显示该查询采用全表扫描。

未经验证的推测不能被保存为确定事实。此外，普通记忆写入不会直接改变模型权重，它通过后续检索和上下文影响行为，与训练或微调不同。

对于跨用户或跨项目的长期记忆，还需要限定访问范围并维护时效，防止信息串用或旧结论被误用于新环境。

七、执行反馈循环：让智能体根据现实修正行动

1. 它负责什么？

执行反馈循环把前面四部分连接起来：LLM 根据目标和记忆规划行动，工具返回执行结果，系统检查结果并更新状态，再进入下一轮决策。

可以概括为：

决策 → 行动 → 观察 → 更新 → 再决策

反馈决定了系统能否从"按计划执行"走向"根据实际情况推进目标"。

2. 工作原理

以故障排查为例：

判断：需要检查数据库慢查询
    ↓
行动：调用慢查询工具
    ↓
观察：某条 SQL 耗时明显升高
    ↓
更新：将该 SQL 列为根因候选
    ↓
下一步：查询执行计划和代码变更

ReAct 提出将推理与行动交错进行，通过外部行动获取信息，再利用新信息更新判断。这是理解此类反馈机制的一种代表性思路，并非所有 Agent 必须采用的固定格式。

3. 反馈与验证有什么区别？

工具结果是一种反馈，但结果到达不代表任务成功。

文件写入成功
≠ 代码能够编译
≠ 测试通过
≠ 原问题已经解决

因此，反馈循环还要检查行动是否产生预期效果。代码任务可以运行测试，业务任务可以查询实际记录，分析任务可以核对原始证据。

让模型自我检查可能有帮助，但不能替代独立的执行证据。

还应区分推理时的纠错与模型训练：Agent 根据反馈调整计划，通常只是改变下一轮上下文和行动；这不意味着模型权重已经更新，也不意味着它自动获得了跨任务的永久能力。

4. 什么时候结束循环？

常见结束或暂停条件包括：

• 已达到任务完成标准。
• 必要信息缺失，需要用户补充。
• 下一步需要额外权限。
• 达到时间、成本或调用次数上限。
• 多次尝试没有取得新进展。

好的 Agent 既要知道如何继续，也要知道何时停止。不能只因模型说"完成了"，就认定任务实际完成。

5. 特点与局限

反馈循环使 Agent 可以纠错，但如果目标不清、记忆错误或验证薄弱，它也可能陷入反复重试、偏离目标或错误自证。

因此，需要用明确的成功条件、外部证据和资源预算约束循环。

八、一个完整案例：五部分如何共同完成任务？

以下是一个假设性案例，用于说明机制，数据并非来自实际生产排查。

目标：定位订单查询接口 P95 延迟上升的原因，提供证据和修复建议。P95 表示请求耗时分布的第 95 百分位。

范围与边界：允许读取监控、日志和代码；允许在隔离测试环境验证；不修改生产环境。

完成标准：明确主要原因及其证据，说明未排除因素，并给出可以验证的修复方案。

第一步：理解目标并规划

LLM 将任务拆成"确认异常范围 → 定位耗时层 → 检查 SQL 和代码变更 → 对照验证"，并将计划保存为任务状态。

第二步：调用工具获取观察

监控显示接口 P95 从约 200 毫秒上升到约 900 毫秒。链路追踪表明数据库调用是主要耗时段，慢查询记录进一步指向一条订单列表 SQL。

Agent 因此优先检查这条 SQL，而不再对所有子系统平均分配排查时间。

第三步：记录证据并调整假设

Agent 保存异常时间、SQL 标识、观测结果和证据引用。代码差异显示，一次发布为查询增加了对索引列的函数处理。

这形成一个候选解释：查询条件变化可能影响索引使用。但此时还只是待验证的假设。

第四步：用反馈验证机制

Agent 检查执行计划，并在相同数据、参数和可比测试条件下，对比变更前后的查询。测试显示新查询采用顺序扫描，移除新增的函数处理后，计划改为索引访问，耗时也明显下降。

**顺序扫描本身不等于索引失效，更不能单独证明根因。**小表、低选择性条件或大量数据读取都可能使顺序扫描成为合理选择。此处的判断依赖代码差异、执行计划和对照结果共同支持。

第五步：交付结论并结束

Agent 输出：

• 主要原因：该测试条件下，新增的函数处理改变了索引使用条件，导致查询耗时增加。
• 证据：相关代码差异、执行计划和对照测试结果。
• 修复建议：调整查询条件，并用测试覆盖边界情况和结果一致性。
• 验证边界：测试环境中的结果支持该解释，生产修复后的效果仍需上线后监控确认。

这个过程体现了完整协作：LLM 提出判断，规划安排取证路径，工具获取观察，记忆保存进度，反馈循环持续修正并验证判断。

九、用一个最小执行循环理解 Agent

以下伪代码展示五个组成之间的关系：

state = create_task(goal, completion_criteria)
memory = load_task_memory(state.id)
budget = create_budget(max_rounds=20, timeout_seconds=300)

while state.status == "running":
    if budget.exhausted():
        state.stop("budget_exhausted")
        break

    # 记忆：构建本轮可见的目标、状态与历史
    context = build_context(goal, state, memory)

    # 每轮计入预算，包括决策、失败和验证未通过的轮次
    budget.begin_round()
    decision = model.decide(context)

    if decision.type == "tool_call":
        # 工具：校验并执行；错误也应转成明确的观察结果
        validate_arguments(decision)
        enforce_permissions(decision)
        observation = execute_tool_with_timeout(decision)
        state.record(observation)

    elif decision.type == "finish":
        # 模型提出完成请求，由验证逻辑检查
        verdict = verify_result(completion_criteria, state, decision)
        if verdict.passed:
            state.complete(decision.answer)
        else:
            state.record(verdict)

    elif decision.type == "request_input":
        state.pause(decision.question)

    else:
        state.stop("unsupported_decision")

    # 保存进度，为下一轮或任务恢复提供依据
    memory.save(state)

save_checkpoint(state)
report = build_task_report(state)

这是解释性伪代码，不依赖具体 SDK。verify_result 应按任务选择测试、数据核对或人工审核等验证方式；execute_tool_with_timeout 应区分成功、明确失败和"结果未知"。实际系统还需要完整的异常处理、资源用量统计和操作审计，尤其不能对结果未知的写入动作盲目重试。

从实现上看，Agent 可以只是一个围绕模型调用组织起来的程序循环。能力来自循环中各部分是否有效协作，而不取决于框架是否复杂。

十、从核心原理走向工程落地

五个核心组成解释了 Agent 如何工作，生产系统还需要让这套机制可靠运行：

• 运行时：组织模型调用、工具执行、任务暂停和恢复。
• 权限控制：在执行层限制动作，不能只依赖提示词。
• 可观测性：记录工具轨迹、状态变化、成本和停止原因。
• 评估：检查任务是否完成、结论是否正确，以及失败后能否恢复。

评估应关注环境中的实际结果，而不只看最终回复是否流畅。

多 Agent 则是在这套机制之上增加分工与协作，适合可以独立拆分的复杂任务。它不是单个 Agent 的必备组成，也不自动提高正确性。

结语

在本文讨论的范围内，Agent 是一套以 LLM 为大脑、以目标为导向的自主执行系统。

Agent ≈ LLM + 规划能力 + 工具调用 + 记忆 + 执行反馈循环

LLM 提供理解与决策，规划把目标变成步骤，工具把决策变成行动，记忆保持任务连续，反馈循环让下一步建立在真实结果之上。

理解这五部分及其协作关系，就能从系统层面判断一个 Agent 为什么有效、为什么失败，以及应该在哪个环节改进。

参考资料

以下资料用于核对概念和实现机制。本文的"五个组成"是教学组织方式，并非对某一资料中的统一架构标准的转述。

1. Anthropic：Building Effective Agents------工作流与 Agent 的区分。
2. Yao 等：ReAct: Synergizing Reasoning and Acting in Language Models------推理与行动交替的研究。
3. Anthropic：Writing Effective Tools for AI Agents------工具接口设计。
4. Anthropic：Effective Context Engineering for AI Agents------上下文管理与长任务记忆。
5. MCP：What Is the Model Context Protocol?------协议定位。
6. Anthropic：Demystifying Evals for AI Agents------任务结果与执行过程的评估。