从 ChatBot 到 Agent：理解 Agent Loop

普通 ChatBot 通常是一问一答：用户提出问题，模型生成回复，一轮交互就结束了。

Agent 的工作方式更像一个持续执行的循环。它先理解目标，再决定是否需要调用工具，根据工具结果继续判断，直到完成任务或需要用户介入。

Agent Loop 的基本过程

一个比较典型的 Agent Loop 可以抽象成下面几步：

接收任务
   ↓
理解目标并制定下一步计划
   ↓
调用工具
   ↓
读取工具结果
   ↓
判断是否完成
   ├─ 未完成：继续循环
   └─ 已完成：输出结果

模型本身不一定需要知道所有事情，但它需要在每一轮根据当前上下文决定下一步做什么。工具调用结果会成为下一轮判断的一部分。

ReAct 是 Agent 中很常见的一种思路，可以概括为 Reasoning、Action、Observation：

问题：查找某个项目最近的发布记录
分析：需要访问发布记录接口
行动：调用 getReleases
观察：得到最近的版本和发布时间
分析：信息已经足够
输出：整理后的发布记录

这种循环的价值在于，Agent 不需要一次性规划所有步骤，可以根据中间结果调整后续行动。

Agent 的执行路径由模型动态决定，和传统程序固定的代码路径不一样。任务变长后，常见的问题包括：

因此，一个能运行的 Agent 和一个能稳定运行的 Agent 之间，差别往往不在模型，而在流程控制和边界设计。

Hooks 可以理解为 Agent 生命周期中的检查点。例如任务开始前加载记忆，调用工具前检查权限，工具失败后记录错误，任务完成后保存重要经验。

Memory 则用于保存任务状态和可复用信息。短期记忆服务于当前任务，长期记忆保存跨会话的偏好、规则和经验。

beforeTask  → 初始化状态、加载记忆
beforeTool  → 校验参数、检查权限
afterTool   → 记录结果、处理错误
afterTask   → 保存经验、清理任务状态

Agent Loop 并不是越自由越好。需要让它在清晰的任务边界、工具权限和完成条件内运行，才能真正用于复杂工作。

Workflow 通常是预先定义好的流程，步骤和分支相对确定；Agent 则可以根据模型判断动态选择下一步。

如果一个任务的步骤稳定、验收条件明确，Workflow 往往更容易维护。如果任务需要探索、检索和根据结果调整路径，Agent 会更有价值。很多实际系统会把两者结合起来：固定部分用 Workflow 控制，不确定部分交给 Agent。

我对 Agent 的理解是：它不是“会聊天的程序”，而是一个带有循环、工具、状态和终止条件的任务执行系统。