大语言模型最初主要以对话式交互的形态被广泛使用：用户输入问题，模型基于上下文生成回答。在这一模式下，模型擅长完成信息解释、文本总结、代码生成、问题分析等任务，本质上仍然是一个以“生成答案”为核心的系统。

但在真实业务场景中，很多任务并不止于生成一段文本。它们往往需要模型围绕一个目标，连续完成资料检索、文档阅读、接口调用、代码修改、测试执行、结果分析和错误修正等多个步骤。也就是说，系统需要的不只是语言生成能力，还需要任务分解、外部工具使用、状态维护和基于反馈持续调整的能力。这就是 Agent 要解决的问题。

Agent 不是一个单独的模型，也不是某个固定 Prompt，而是一类以大语言模型为核心的任务执行系统。它通过任务规划、工具调用、记忆机制、状态管理和反馈循环，让模型能够围绕目标持续推进任务。

换句话说，Agent 的意义在于：将 LLM 从“对话生成系统”扩展为“任务执行系统”。

Agent 是什么

从系统形态看，Agent 不是一次性问答，而是围绕目标持续执行的闭环系统。它接收的不只是一个问题，而是一个任务目标；输出的也不只是一次回答，而是执行一组动作后的结果。

  • 普通 LLM 应用更接近“问答模式”：用户问题 -> 模型回答；
  • 而 Agent 更接近“执行模式”：用户目标 -> 理解任务 -> 制定计划 -> 调用工具 -> 观察结果 -> 更新状态 -> 继续执行 -> 交付结果。

两者的关键区别在于：普通 LLM 主要生成答案，Agent 则允许模型在系统约束下连接外部环境，并根据反馈持续推进任务。

普通 LLM 应用于 Agent 应用对比

从系统视角看，Agent 通常由几类能力组成：

  1. LLM：理解任务、生成计划、选择动作、总结结果；
  2. Tools：连接外部系统，例如搜索、数据库、浏览器、代码执行器、业务 API；
  3. Memory / State：保存上下文、任务进展、中间结果和历史信息；
  4. Controller：管理执行流程，决定下一步、重试或终止；
  5. Guardrails：控制权限、安全、成本和风险。

所以，Agent 不是“一个会自动做事的模型”，而是一套系统组合：LLM + 工具 + 记忆 / 状态 + 控制循环 + 安全边界。判断一个系统是否具备 Agent 形态，可以看三点：

  1. 是否围绕目标持续执行，而不是只回答一次；
  2. 是否能够调用外部工具，并接收环境反馈；
  3. 是否维护任务状态，并根据结果调整下一步。

因此，Agent 的核心不是让模型完全自主，而是让模型在可控系统中，把语言理解能力转化为任务执行能力。

Agent 如何工作

Agent 的工作方式可以抽象成一个闭环：Plan -> Act -> Observe -> Reflect。这个闭环的含义是：模型先根据目标形成计划，然后选择动作并调用工具；工具执行后返回结果，模型再根据结果判断任务是否推进、是否需要修正，或者是否应该结束。可以拆成四个阶段：

  1. Plan：理解用户目标，拆解任务，决定下一步要做什么；
  2. Act：选择合适的工具，并生成工具调用参数；
  3. Observe：接收工具执行结果，例如搜索结果、日志、代码运行结果、接口返回值；
  4. Reflect：基于结果判断是否成功，是否需要重试、调整计划或进入下一步。

Agent 执行流程

这个循环是 Agent 和普通 LLM 应用的关键区别。普通 LLM 往往是在已有上下文里生成一次回答；Agent 则会在执行过程中不断获得新信息，并把这些信息作为下一步决策的依据。

  • 例如用户给出一个目标：帮我分析这个项目最近一次构建失败的原因，并给出修复建议。

一个 Agent 可能会按下面的方式执行：

  1. 读取最近一次构建日志；
  2. 定位失败阶段和错误信息；
  3. 搜索相关代码和配置；
  4. 分析错误堆栈与最近改动；
  5. 必要时运行局部测试；
  6. 根据结果修正判断；
  7. 汇总失败原因和修复建议。

这背后不是一次生成，而是多轮“推理 + 工具调用 + 结果反馈”的过程。

Agent 执行流程

在实际系统中，Agent 的工作方式通常有几种常见模式：

模式 核心思路 适合场景
ReAct 推理和行动交替进行，边想边做 搜索、排障、探索型任务
Plan-and-Execute 先生成整体计划，再逐步执行 流程较清晰的长任务
Reflection 执行后检查结果，再决定是否修正 代码修改、报告生成、结果校验
Workflow Agent 流程相对固定，模型只负责关键判断 企业生产系统、低风险自动化

需要注意的是，生产环境里很少会让 Agent 完全自由行动。更常见的方式是：流程有边界，工具有权限，执行有终止条件，关键动作需要校验或人工确认。所以，Agent 的工作流程可以总结为：

  • 目标不是一次性回答，而是持续推进任务；
  • 动作不是凭空生成，而是通过工具连接外部环境；
  • 结果不是直接相信，而是根据反馈不断修正。

Agent 的核心能力：从模型调用到可控执行

Agent 能不能真正可用，不只取决于模型本身的能力，更取决于系统是否把“规划、执行、记忆、校验、控制”这些能力组织好。可以把 Agent 看成一个围绕 LLM 构建的任务执行系统，如下图所示：

Agent 执行闭环

Agent 通过规划、执行、反馈和校验形成闭环，当任务完成则交付结果，遇到高风险场景则转人工确认或终止。

工具调用：连接外部世界

工具调用是 Agent 从“生成文本”走向“执行任务”的关键。模型本身不能直接访问数据库、浏览器、代码仓库或业务系统，它需要通过工具接口间接连接外部环境。一个工具通常需要明确描述：

配置项 作用
工具名称 告诉模型这个工具能做什么
工具描述 说明适用场景，帮助模型选择工具
输入参数 schema 约束参数类型、字段和必填项
输出格式 让模型理解工具返回结果
权限范围 限制工具能访问哪些资源
失败处理 定义超时、错误、空结果如何返回
确认机制 高风险操作是否需要用户确认

例如一个文档检索工具可以定义成：

1
2
3
4
5
6
7
8
9
{
  "name": "search_docs",
  "description": "在企业知识库中检索相关文档",
  "parameters": {
    "query": "string",
    "top_k": "number",
    "source": "wiki | code | ticket"
  }
}

模型生成的不是最终动作，而是一个工具调用请求：

1
2
3
4
5
6
7
8
{
  "tool": "search_docs",
  "input": {
    "query": "退款失败 ERR-7782 原因",
    "top_k": 5,
    "source": "wiki"
  }
}

真正的执行由系统完成。这样做的好处是：模型负责判断“该调用什么”，系统负责保证“能不能调用、怎么调用、是否安全”。工具调用的技术重点包括：

  1. 参数校验：防止模型生成非法字段或错误类型；
  2. 权限控制：不同用户只能调用自己有权限的工具和数据；
  3. 错误返回：工具失败时返回结构化错误，而不是只抛异常；
  4. 幂等设计：重复调用不会造成不可控副作用；
  5. 审计日志：记录谁在什么任务里调用了什么工具。

记忆与状态：让任务连续推进

Agent 需要知道自己正在做什么、已经做了什么、下一步还要做什么。这里的“记忆”不只是聊天历史，而是任务执行过程中的状态管理。可以拆成几类：

类型 作用
短期上下文 当前对话、最近工具结果、当前任务约束
工作记忆 当前计划、已完成步骤、待执行步骤、中间结论
长期记忆 用户偏好、历史任务结果、项目背景
外部记忆 RAG、数据库、文件系统、知识库
执行轨迹 每一步工具调用、输入输出、错误和重试记录

如果没有状态管理，Agent 很容易出现问题：重复执行同一步、忘记原始目标、忽略工具结果、前后结论不一致，或者长任务中断后无法恢复。因此，生产级 Agent 往往会维护一个显式的任务状态对象，例如：

1
2
3
4
5
6
7
8
9
10
11
{
  "goal": "分析构建失败原因",
  "plan": ["读取日志", "定位错误", "检查代码", "给出修复建议"],
  "completed_steps": ["读取日志", "定位错误"],
  "current_step": "检查代码",
  "observations": [
    "构建失败发生在 test 阶段",
    "错误来自 payment 模块的空指针异常"
  ],
  "next_action": "搜索最近 payment 模块变更"
}

这类状态对象可以让 Agent 不完全依赖上下文窗口，而是用结构化方式保存任务进展。

规划与控制：让模型会拆任务，但不失控

Agent 需要具备任务规划能力。面对复杂目标时，模型不能只生成一个最终答案，而要把目标拆成多个可执行步骤。常见规划方式有两类：

方式 特点 适合场景
显式规划 先生成完整计划，再逐步执行 报告生成、数据分析、代码迁移
动态规划 每一步根据观察结果决定下一步 故障排查、网页操作、资料调研

但规划能力必须和控制机制配合使用。否则 Agent 很容易无限搜索、重复尝试，或者把一个简单任务拆得过于复杂。常见控制参数包括：

  1. 最大执行轮数；
  2. 最大工具调用次数；
  3. 最大 token 成本；
  4. 是否允许写操作；
  5. 是否允许访问外部网络；
  6. 是否需要人工确认；
  7. 失败后是否重试；
  8. 什么条件下终止任务。

所以，Agent 的规划不是“让模型自由发挥”，而是让模型在明确边界内做决策。

反馈与校验：让结果可以被验证

Agent 每执行一步，都会得到一个观察结果。但工具返回结果不一定代表任务成功，模型生成的结论也不一定可靠。因此 Agent 需要校验机制。校验可以分为几层：

校验层次 例子
工具结果校验 API 是否返回成功，字段是否完整
任务结果校验 测试是否通过，文件是否生成，数据是否匹配
事实一致性校验 回答是否有证据支持，引用是否准确
规则校验 是否违反权限、格式、安全策略
人工确认 高风险动作前让用户确认

例如代码修复类 Agent，不应该在修改代码后直接输出“已修复”，而应该继续运行测试：

1
2
修改代码 -> 运行测试 -> 测试通过 -> 输出修复说明
修改代码 -> 运行测试 -> 测试失败 -> 重新分析错误

这也是 Agent 和普通生成式应用的重要区别：Agent 的结果最好能被环境反馈验证，而不是只依赖模型自我判断。

安全边界：让 Agent 可控

Agent 越能行动，风险也越高。一个能调用工具的模型，如果没有边界，可能会访问不该访问的数据，执行不该执行的操作，或者在错误判断下持续重试。因此，Agent 系统必须有安全边界：

  1. 读操作和写操作分离；
  2. 高风险操作需要人工确认；
  3. 工具按用户权限动态开放；
  4. 敏感数据进入模型前脱敏；
  5. 所有工具调用都记录日志；
  6. 失败和异常要能回滚或终止；
  7. 不允许模型绕过系统直接执行危险动作。

简单说，Agent 的核心能力可以总结为：

能力 解决的问题
工具调用 让模型连接外部系统
记忆与状态 让任务可以连续推进
规划与控制 让复杂任务可以拆解执行
反馈与校验 让结果可以被验证
安全边界 让 Agent 在可控范围内行动

Agent 真正的难点，不是让模型“想到下一步”，而是让每一步都能被执行、被记录、被验证、被约束。只有这些能力组合起来，Agent 才能从一个演示系统走向真实业务系统。

Agent 落地难在哪里

上一节讲的是 Agent 需要具备哪些核心能力：工具调用、状态管理、规划控制、结果校验和安全边界。这些能力从架构上看并不复杂，但在真实生产环境里，它们很容易失效。

原因在于，Agent 面对的不是一次静态输入，而是一条动态执行链路。每一步都可能引入新的不确定性：模型可能理解错目标，工具可能返回异常，状态可能没有正确更新，前一步错误可能影响后续判断，高风险操作还可能对真实系统造成影响。所以，Agent 落地的难点，不是“有没有这些模块”，而是这些模块能否在真实任务中稳定协同。

普通 LLM 应用的失败，通常只是“回答错了”；Agent 的失败可能会变成“执行错了”。一旦 Agent 连接了数据库、代码仓库、浏览器、业务 API 或自动化工具，错误就不再停留在文本层面，而可能影响真实系统。所以 Agent 落地的核心挑战，可以概括为三句话：

  1. 模型输出具有不确定性，但任务执行需要稳定性；
  2. 工具调用可能带来副作用，但业务系统需要可控性；
  3. 多步骤链路会累积错误，但最终结果需要可验证性。

Agent 落地挑战

Agent 落地不是单点模型问题，而是模型、工具、状态、安全和评估共同构成的系统问题。可以从几个典型问题来总结下：

问题 本质 典型表现 解决方向
目标不清晰 输入缺少任务边界 Agent 自行猜测目标，执行方向偏离 任务澄清、结构化任务描述、验收标准
规划不稳定 LLM 输出具有不确定性 同一任务多次执行路径不同，步骤遗漏 模板化 Workflow、阶段性计划、关键步骤确认
工具调用错误 模型可能选错工具或填错参数 参数格式错误、重复调用、忽略工具失败 Tool schema、参数校验、错误码、重试策略
长链路错误累积 多步任务中错误会传播 前一步判断错，后续全部基于错误结果执行 分阶段校验、checkpoint、Verifier
状态丢失 任务进展没有结构化记录 重复执行、忘记约束、无法恢复 状态机、任务日志、事件流、工作记忆
结果不可验证 模型输出缺少外部证据 看似完成，实际没有依据或测试失败 测试、引用、规则校验、人工审核
安全风险 工具连接真实系统 删除数据、越权访问、误发消息 权限隔离、沙箱、人工确认、审计日志
成本不可控 多轮调用放大 token 和工具成本 执行慢、费用高、循环调用 最大轮数、预算控制、缓存、模型路由

这里最关键的是：Agent 系统不能只依赖模型自觉正确。生产系统必须把任务执行过程拆开，在关键节点加入约束和校验。一个更可靠的 Agent 架构，通常会采用“受控执行”的方式：

Agent 分阶段落地

因此，Agent 落地时更推荐从低风险场景开始，而不是一上来就做完全自主系统：

  1. 先做只读型 Agent：例如文档检索、日志分析、代码阅读、数据分析建议；
  2. 再做建议型 Agent：模型给出操作建议，但由人确认后执行；
  3. 然后做半自动 Workflow：固定流程由系统控制，模型只负责局部判断；
  4. 最后再做可控自主执行：在明确权限、预算、终止条件和回滚机制下，让 Agent 执行多步任务。

可以把自主程度分成几个阶段：

图 7：Agent 落地通常从只读问答逐步走向可控自主执行。

图 7：Agent 落地通常从只读问答逐步走向可控自主执行。

所以，生产级 Agent 的重点不是“让模型尽可能自由”，而是建立一套可控机制：

  1. 目标要明确；
  2. 工具要有边界；
  3. 状态要可追踪；
  4. 关键步骤要可验证；
  5. 高风险动作要可确认；
  6. 失败过程要可恢复；
  7. 整个执行链路要可观测。

一句话总结：Agent 落地的难点，不是让模型多走几步，而是让每一步都能被约束、被记录、被验证，并在出错时能够停止、回退或交给人处理。

未来演进与总结

Agent 是 LLM 从“生成内容”走向“完成任务”的关键形态。未来 Agent 大概率会沿着几个方向继续演进：

  1. 工具调用更标准化：模型能更稳定地理解工具 schema、生成参数、处理错误。
  2. Computer Use 更成熟：模型不仅调用 API，还能操作浏览器、桌面软件和复杂界面。
  3. 记忆系统更完善：短期上下文、长期记忆、RAG、任务轨迹会逐渐融合。
  4. 多 Agent 协作：不同 Agent 分工处理规划、检索、代码、审查和执行。
  5. 安全与评估更重要：Agent 越能行动，越需要权限、审计、回滚和人工确认。

简单总结：Agent 不是让大模型变成一个“完全自主的人”，而是把 LLM 放进一个有工具、有记忆、有状态、有反馈、有边界的系统里，让它能够围绕目标持续完成任务。如果说 RAG 解决的是“大模型如何连接外部知识”，那么 Agent 解决的就是：大模型如何连接外部世界，并把知识转化为行动。