Agent 的核心组件
一个实用的 Agent 可以拆成五个组件：大脑（LLM）、规划、工具、记忆、环境。质量短板往往不在"哪个组件不够先进"，而在组件之间的接口设计。
┌──────────────┐
目标 ────→ │ LLM 大脑 │ ←──── 记忆（短期上下文 + 长期存储）
│ （推理决策） │
└──────┬───────┘
│ 规划（任务分解 / 自我反思）
↓
┌──────────────┐
│ 工具集 │ ←── 工具描述（模型唯一能"看到"的信息）
└──────┬───────┘
↓
┌──────────────┐
观察 ←──── │ 环境 │
└──────────────┘
大脑：LLM
LLM 承担三类职责：理解目标与当前状态、决定下一步行动、综合观察产出结果。选型时真正影响 Agent 表现的是：
- 指令遵循与工具调用可靠性：能否稳定输出合法的函数调用 JSON，选错工具、编造参数的频率；
- 上下文长度与利用率：多轮循环会持续膨胀上下文；
- 推理深度：多跳任务中"想清楚再动手"的能力。
一个常见误区是弱模型 + 复杂 Agent 架构。循环推理会指数级放大模型的小错误（选错工具 → 观察污染 → 错上加错）。能力不足时，优先降低架构复杂度或升级模型，而不是加更多角色。
规划
规划是把目标翻译成行动序列的能力，在 Agent 中有两种形态：
事前规划：行动前先拆解任务（Plan-and-Execute），生成步骤清单再逐步执行。适合路径相对清晰的场景，缺点是计划赶不上变化。
反应式规划：不预先计划，每轮根据最新观察决定下一步（ReAct）。适合环境信息逐步揭示的场景，缺点是可能短视、绕路。
生产系统常做混合：先让 LLM 产出一个粗粒度计划作为引导，执行中允许按观察修订。规划能力也可通过提示词显式激发，让模型先输出计划再输出行动。
工具
工具是 Agent 的手脚，也是工程上最值得投入的组件。模型对工具的全部认知只来自工具描述，因此工具设计直接决定使用质量：
| 设计点 | 坏味道 | 好实践 |
|---|---|---|
| 命名 | handle_data | search_employee |
| 描述 | "处理数据" | "按姓名和部门检索员工信息，返回 JSON" |
| 参数 | 一个 options 字符串塞一切 | 少量强类型字段 + 必填约束 |
| 返回 | 抛异常、空字符串 | 结构化结果 + 可行动的错误信息 |
| 数量 | 一次挂 50 个工具 | 相关工具分组，按需加载 |
工具的深度实践（函数调用协议、错误设计、MCP）单独展开，见工具设计与函数调用。
记忆
LLM 的上下文窗口是工作记忆——容量有限且按 token 计费；跨会话的知识需要长期记忆——外部存储 + 检索。记忆组件解决三个问题：记什么（写入策略）、怎么找（检索策略）、如何淘汰（管理策略）。详见 Agent 记忆系统。
一个容易被忽视的中间层是任务状态：当前子目标、已完成步骤、待办清单。它通常不是靠上下文自然记忆，而是显式维护的结构化数据（如 LangGraph 的 State），循环每轮把它注入提示词，长任务才不会"失忆"或跑偏。
环境
环境是工具操作的对象世界：文件系统、数据库、Web、内部 API。工程上环境的核心问题是隔离与可观测：
- 高危操作（发邮件、删数据、付款）放在确认机制或沙箱之后；
- 每次工具调用记录输入输出，形成完整轨迹（trajectory），这是调试和评测的生命线；
- 环境尽量可回放，同一轨迹应能重跑复现问题。
组件间的接口
组件质量达标后，Agent 的差距体现在接口上：
- 大脑与工具：工具描述、错误信息、返回结构就是模型的"UI"，信息表达越清晰，决策越准；
- 大脑与记忆：写什么进上下文、以什么格式写，决定循环轮数增长后模型是否还能保持专注；
- 规划与状态：状态字段设计不好，反思和修订就无从谈起。
后续设计原则一文会看到：构建好的 Agent，大部分工作正是打磨这些接口，而不是堆砌组件。