Agent 的基本原理

厘清 LLM、RAG、Tool、Workflow 与 Agent，理解状态、计划、记忆、循环、停止条件、恢复和可观测性。

「产品经理的大模型基础」系列之七
上一篇：工具调用与 Workflow · 系列入口 · 下一篇：大模型产品的评估与设计

当大模型能够理解目标、调用工具并根据结果继续行动时，系统就开始接近 Agent。

Agent 这个词在不同产品和框架中定义并不完全一致。对产品经理来说，可以先使用一个实用定义：

Agent 是围绕一个目标运行，能够观察当前状态、决定下一步、调用工具、读取结果并持续循环，直到完成或停止的系统。

这篇文章重点介绍组成 Agent 的几个关键部分：目标、状态、计划、工具、记忆、循环和停止条件，也会说明 Agent 与 LLM、RAG、Workflow 和 Multi-Agent 的边界。

一、先分清几个经常混用的概念

概念	专业定义的重点	大白话理解
LLM	理解、生成并完成一定程度的推理	负责动脑和表达的模型
RAG	检索外部资料并增强生成	回答前先去资料库翻书
Tool	与外部系统交互的函数或接口	给模型一双能查、能做的手
Workflow	按预设步骤和分支进行编排	人先画好流程图，系统照着走
Agent	围绕目标，根据状态动态决定下一步	只规定目标，部分路径由系统边做边定
Multi-Agent	多个相对独立的执行单元分工协作	不止一个执行者，还要协调分工和交接

它们可以组合：一个 Agent 可以使用 RAG 和多个工具，也可以嵌在 Workflow 的某一个节点里。用了工具不等于就是 Agent；只要路径主要由人预先确定，它仍更接近 Workflow。

二、从一次回答到连续行动

普通模型调用通常是：输入一个问题，生成一个结果，然后结束。

Agent 处理的任务可能需要多个步骤。例如，用户要求“分析这个需求并创建合适的任务”：

读取需求材料。
判断缺少哪些信息。
查询相关产品文档。
生成任务草稿。
检查字段是否完整。
请求用户确认。
调用任务系统创建任务。

下一步可能取决于上一步结果。如果资料已经完整，就不必继续搜索；如果工具返回权限错误，就需要停止或请求授权。这种根据环境反馈动态选择下一步的能力，是 Agent 与固定 Workflow 的主要区别。

三、Agent 的基本循环

一个简化的 Agent 循环是：

接收目标
→ 观察当前状态和环境
→ 决定下一步
→ 调用工具或生成内容
→ 读取结果
→ 更新状态
→ 判断是否完成或需要停止
→ 继续下一轮

ReAct 是一种有代表性的研究思路，它把推理与行动交替起来：模型根据当前信息形成下一步判断，通过工具从外部环境获得新信息，再继续处理。

真实 Agent 不一定会把模型的内部推理过程展示给用户，但系统必须保存足够的执行轨迹（Trace）：调用了什么工具、使用了哪些参数、工具返回了什么、状态如何变化，以及最终为什么停止。这类能力通常称为 Observability（可观测性）。大白话说，不要求系统公开“脑内独白”，但必须留下能复盘行为的行车记录仪。

四、目标：Agent 到底要完成什么

Agent 首先需要一个明确目标。目标不能只是“尽量帮用户处理好”，而应包含可判断的完成条件。

例如，“研究竞品”过于宽泛。更明确的目标是：

找到三款满足指定条件的竞品。
从官方来源获取价格和核心能力。
对无法验证的信息明确标记。
生成结构统一的对比结果。

目标越模糊，Agent 越容易不断搜索、偏离主题或过早宣布完成。

五、状态：任务现在进行到哪里

状态是 Agent 在执行过程中需要持续保存的信息。它通常包括：

用户目标和约束。
已经完成的步骤。
工具调用及返回结果。
已确认的事实。
仍待解决的问题。
当前错误和重试次数。
剩余时间、步骤或成本预算。

状态最好以结构化方式保存，而不是只存在于长对话中。这样系统才能准确恢复任务，也便于界面展示进度和工程排错。

六、计划：提前规划还是边做边决定

有些 Agent 会先生成完整计划，再逐步执行；有些则每完成一步，只决定下一步；还有些采用混合方式：先形成粗略计划，再根据工具结果调整。

不同任务适合不同方式：

路径相对明确：完整计划更容易控制。
环境变化较多：逐步决定更灵活。
复杂长期任务：通常需要阶段计划与持续调整结合。

计划不是越详细越好。模型可能在尚未读取环境时制定出错误计划，因此需要允许根据真实结果修正。

七、工具：Agent 与外部世界的接口

没有工具的 Agent，通常只能在文本中分析和生成；有了工具，它可以搜索、读取文件、查询数据库、运行代码或操作业务系统。

工具的描述会影响模型是否正确使用它。一个好工具接口应具有：

清楚的名称和用途。
明确的参数结构。
可理解的返回结果。
具体的错误信息。
程序层的权限和参数校验。

工具数量过多、用途重叠或说明含糊，会增加模型选错工具的概率。

八、记忆：Agent 怎样跨步骤保留信息

Agent 中常见的“记忆”并不是单一模块。可以区分：

当前上下文：本次模型调用直接看到的信息。
会话历史：当前对话中发生过的内容。
任务状态：本次任务的事实、进度和结果。
长期记忆：跨会话保存的用户偏好、历史决策或经验。
外部知识库：可以检索的文档和资料。

长期记忆通常需要写入和读取策略。不是所有信息都值得保存，也不应该让模型在没有权限和用户知情的情况下记录敏感内容。

记忆还可能出错：保存了错误结论、过期信息或错误用户的数据，都会在后续任务中持续产生影响。因此，记忆需要来源、更新时间、权限和删除机制。

九、停止条件：什么时候结束循环

Agent 如果只被要求“继续直到做好”，可能不断调用工具、重复搜索或在错误中循环。

常见停止条件包括：

已满足明确完成标准。
达到最大步骤数。
超过时间或成本预算。
连续多次出现相同错误。
缺少只能由用户提供的信息。
下一步涉及需要人工确认的高风险动作。
环境返回无法继续的权限或资源限制。

停止并不一定意味着失败。能够在信息不足、权限不够或风险过高时暂停并说明原因，往往比继续猜测更可靠。

十、重试、循环与恢复：怎样避免 Agent 原地打转

Agent 常见失败不是立即报错，而是看起来一直在工作：重复搜索同一关键词、反复调用一个失败工具，或不断改写计划却没有新增事实。这属于无进展循环。

系统可以组合使用以下控制：

设置最大步骤、总耗时和总成本预算。
记录相同工具、参数和错误的连续出现次数。
比较每轮状态是否新增有效事实或完成项。
按错误类型重试，避免对权限和参数错误机械重试。
保存检查点，使任务能从失败步骤恢复，而不是全部重做。
达到阈值后停止，并把已有结果、失败原因和待确认问题交给人。

“最多运行 20 步”只是最后保险，更好的做法是同时判断有没有进展。例如连续三轮没有新增证据，即使还没到步骤上限，也应该换策略或停止。

十一、Agent 与 Workflow 怎样选择

可以用任务路径是否可预先确定来判断：

情况	更适合的方案
一次生成即可完成	单次模型调用
缺少知识或一个工具	增强模型调用
步骤固定、分支有限	Workflow
下一步取决于中间结果，路径难以穷举	Agent

Agent 提高了灵活性，也会增加成本、延迟、错误路径和评估难度。因此，不应把所有多步骤流程都称为 Agent，也不必为了使用 Agent 而放弃可预测的 Workflow。

十二、单 Agent 与多 Agent

一个 Agent 可以使用多个工具，也可以在内部完成多个角色。多 Agent 则让多个独立执行单元分工协作。

多 Agent 可能适合：

子任务能够真正并行。
需要独立复核或不同观点。
不同角色必须具有不同权限。
一个协调者需要动态分配不可预知的子任务。

它也会增加通信、状态同步、冲突处理和成本。很多“研究 Agent + 写作 Agent + 评审 Agent”的场景，使用一个清晰的 Workflow 也可能完成。

十三、Agent 产品中的人工参与

人工参与不代表 Agent 不够先进。对于高风险、信息不完整或需要价值判断的任务，人工确认本身就是正确架构。

常见人工节点包括：

补充缺失信息。
确认计划或范围。
审核关键结论。
预览写入参数。
批准发送、删除、支付和发布。
在连续失败后接管。

好的 Agent 会知道什么时候需要人，而不是把“自主”理解为完全不与人沟通。

本篇小结

Agent 可以理解为一个受目标驱动的循环系统：

它维护状态，根据当前信息制定或调整计划，通过工具与环境交互，使用记忆保留必要信息，记录可复盘的执行轨迹，并在完成、无进展、受阻或达到限制时停止。

下一篇将讨论怎样判断这类系统是否真正可用，包括正确率、任务完成率、人工接管率、成本、延迟，以及这些内容怎样进入 AI 产品 PRD。

上一篇：工具调用与 Workflow　下一篇：大模型产品的评估与设计