Agent 的概念、原理和构建模式

前置阅读：从LLM到Agent Skill 用一条因果链介绍了"Agent 为什么会出现"。
这篇文档把镜头拉近，专门讲 Agent 本身：它是什么、怎么跑起来、主流有哪几种构建模式、以及它的工程边界在哪里。

一、概念：什么才算一个 Agent

一句话定义

Agent = LLM（大脑） + Tool（手脚） + Loop（自主循环）。

三者缺一不可：

• 没有 LLM，它就不会"思考"；
• 没有 Tool，它只会"嘴炮"；
• 没有 Loop，它顶多叫"一次性工具调用"，还称不上 Agent。

和 Chatbot 的区别

维度	Chatbot	Agent
交互	一问一答	多轮自主执行
工具	很少或没有	大量工具调用
目标	回答问题	完成任务
控制流	用户驱动（你不说它不做）	模型驱动（它自己决定下一步）
结束条件	用户结束对话	任务达成 / 判定失败 / 超预算

最本质的差别在"控制流归谁"。一旦模型可以自己决定"下一步做什么"，Agent 形态就成立了。

Agent 典型产品

像 Claude Code、Codex、Gemini CLI、Cursor、Devin、各种"深度研究"功能，都是 Agent。它们背后的模型可能不同，但构建模式基本跑不出下面几种。

二、原理：Agent 是怎么跑起来的

核心循环

不管外表多花哨，Agent 的底层几乎都是同一个循环：

┌──────────────────────────────────────────┐
│ 1. 观察当前状态（Context、工具结果、用户输入）│
│ 2. 思考下一步（LLM 推理）                   │
│ 3. 选择动作（调用某个 Tool / 回复用户）      │
│ 4. 执行动作，得到新观察                     │
│ 5. 回到第 1 步，直到任务完成或触发停止条件    │
└──────────────────────────────────────────┘

这就是所谓的 Agent Loop。它对应着学术圈的 ReAct 范式，也对应工程上常说的"think → act → observe"。

每一轮内部发生了什么

从工程视角，一轮迭代其实是这样一次 API 调用：

1. 输入打包：把 System Prompt + 历史消息 + 可用工具列表 + 最新观察，一起发给模型。
2. 模型输出：要么输出一段自然语言（给用户看），要么输出一个结构化的"工具调用"（Function Calling / Tool Use）。
3. 宿主执行：如果是工具调用，宿主程序真去执行（注意——模型不执行工具，它只开单子）。
4. 结果回灌：把工具结果作为新的 observation 拼回消息列表。
5. 判断是否停止：是就 return，不是就进入下一轮。

停下来的几种理由

Agent 跑路很容易，真正难的是让它合适地停下来。常见停止条件：

• 模型自己说"我做完了"。
• 触达最大轮数（max turns）。
• 触达 token / 金钱预算。
• 触达时间超时。
• 人类中断（按 Esc、发 /stop）。
• 判定失败（工具连续报错、结果验证不通过）。

把这些停止条件做好，本质上是 Harness 的活。

三、构建模式：主流玩法就两大类

如上图所总结，当前 Agent 产品的构建模式，99% 可以归进 ReAct 和 Plan-and-Execute 两大派。

模式一：ReAct（边想边做）

思路：每走一步都让模型重新想一遍"下一步做什么"，非常灵活，但也非常"走哪算哪"。

Thought → Action → Observation → Thought → Action → Observation → ...

特点：

• 反应快、适应性强：上一步结果出来就立刻据此调整。
• 不需要提前规划：用户的需求可以是模糊的。
• 代表产品：Claude Code、Cursor Agent、大多数"聊天式"Agent。

缺点：

• 容易"走偏"——走着走着忘了最初目标。
• 长任务里每一轮都要把整个历史塞进去，token 消耗高。
• 没有全局视野，不擅长需要预规划的复杂任务。

模式二：Plan-and-Execute（先规划后执行）

思路：第一步先让模型出一份完整计划（通常是一个带步骤的 todo list），后续每一步只是去执行计划里的某一条，执行过程中再根据情况调整计划。

Plan: [1. xxx, 2. xxx, 3. xxx] → Execute(1) → Execute(2) → [Replan?] → Execute(3) → ...

特点：

• 目标稳定：计划白纸黑字写着，不容易走丢。
• 适合长任务：每一步的 Context 可以只关注"当前这一步"，省 token。
• 便于观测和接管：计划本身就是一张可读可改的"任务清单"。
• 代表产品：Devin、各种"深度研究"、大多数 autonomous agent。

缺点：

• 启动成本高：没想清楚就规划，容易把错误从头错到尾。
• 灵活性差：真实世界常常"计划赶不上变化"，需要 Replan（重规划） 机制。

实际产品里常常是"混合模式"

工程上很少是纯粹的一种：

• Claude Code 以 ReAct 为主，但在处理复杂任务时会主动写一份 todo list（带有 Plan-and-Execute 的影子）。
• Devin 以 Plan-and-Execute 为主，但在执行每一小步时又回到 ReAct 的细粒度循环。

可以把它们理解为同一条光谱上的两端：

ReAct ←────────────────────────→ Plan-and-Execute
 灵活                                  稳定
 短任务                                长任务
 聊天形态                              自动化形态

四、更复杂的结构：从单 Agent 到多 Agent

当任务复杂到一个 Agent 处理不过来时，自然会演进到 多 Agent 协作：

• Orchestrator + Sub-Agents：主 Agent 拆任务 → 分发给多个子 Agent 并行处理 → 汇总。
• Role-based：比如"程序员 Agent + 评审 Agent + 测试 Agent"互相把关。
• Swarm / Hand-off：一个 Agent 做不下去就把 Context 交接给另一个更合适的 Agent。

多 Agent 的核心好处是：每个 Agent 的上下文更短、职责更单一、不易走神。
代价是：协调成本、通信成本、调度复杂度全面上升。

所以业界一个常识是：能单 Agent 解决的，别上多 Agent。

五、构建一个 Agent 需要哪些工程组件

真正把一个 Agent 落地到产品，远不止"写个 while 循环调模型"。至少需要：

• 模型接口层：包装不同厂商的 API，处理流式输出、Function Calling 格式差异。
• 工具系统：工具注册、参数校验、权限控制、超时 / 重试 / 幂等。
• Context 管理：历史裁剪、压缩、关键信息钉住不丢。
• 记忆系统：短期（会话内）、中期（项目级，如 AGENTS.md）、长期（跨会话）。
• 调度与终止：轮数上限、预算控制、人类中断、自动重规划。
• 可观测性：日志、trace、评测（eval）、回放调试。
• 安全机制：工具白名单、危险操作确认、凭证隔离。
• Skill / 子 Agent 机制：按需加载领域能力，见 Agent Skill 从使用到原理。

这些"模型之外"的东西，合起来就是 Harness。

六、小结

一条线回顾：

1. 概念：Agent = LLM + Tool + Loop，核心差别是"控制流归模型"。
2. 原理：通过"观察 → 思考 → 动作 → 观察"的循环，在多轮调用里自主推进任务。
3. 构建模式：主流就两种——ReAct（边想边做）和 Plan-and-Execute（先规划后执行），实际产品往往混用。
4. 扩展：任务复杂到一定程度会演化成多 Agent 协作，但越简单越好。
5. 工程：让 Agent 真的稳定跑起来，靠的是模型之外的一整套 Harness。

理解这四层（概念 → 原理 → 模式 → 工程），再看 Claude Code、Cursor、Devin 这些产品的设计，你基本能从架构图就猜出它们属于哪种模式、在 Harness 层下过哪些功夫。