ReAct 循环
ReAct（Reason + Act）是一种将推理与行动交替进行的 Agent 执行模式，由"思考 → 行动 → 观察 → 重复"组成。
- 思考（Reason）：模型基于当前上下文推理下一步该做什么，必要时将任务拆解为子任务。
- 行动（Act）：发起一次具体的工具调用，例如获取数据、运行代码或调用 API。
- 观察（Observe）：工具返回结果，结果被加入上下文供模型查看。
- 重复（Repeat）：模型读取更新后的上下文再次推理，循环持续到任务完成或达到步数上限。
其关键特征在于：模型能根据真实反馈调整计划，而非执行一段固定脚本。
单 Agent 与多 Agent
大语言模型的上下文窗口是有限的。当单个 Agent 承担全部工作时，上下文会迅速被占满，推理质量随之下降，且任一环节的失败可能拖垮整个任务。
多 Agent 架构将工作拆分给多个角色：每个 worker 拥有相对干净的上下文，失败被局部化，且部分子任务可以并行执行。其代价是引入了编排（orchestration）与通信的复杂度。
| 维度 | 单 Agent | 多 Agent |
|---|---|---|
| 上下文 | 所有任务共享一个上下文，容易被占满 | 每个 worker 上下文独立、更干净 |
| 故障 | 单点失败影响整体 | 失败被局部隔离 |
| 并行 | 难以并行 | 子任务可并行 |
| 复杂度 | 实现简单 | 需要编排与通信机制 |
Agent 间通信
多 Agent 之间传递结果通常有两种方式：
- 共享内存（Shared Memory）：各 Agent 读写同一份共享状态。实现简单，但在分布式环境下扩展性较差，且状态来源不易追踪。
- 消息传递（Message Passing）：worker 将结果显式返回给编排者。链路更清晰、更易追踪，也更适合分布式系统。
在需要可追踪性与跨节点扩展的场景中，消息传递通常更受青睐。
上下文与记忆管理
长工具输出
当工具返回的内容很长时，常见做法是将完整结果存储在上下文之外，仅在对话中保留一个引用标识（reference token），需要时再按引用取回。这样可在不丢失数据的前提下控制上下文体积。
记忆压缩（Compaction）
当上下文接近 token 上限时，可对较早的历史进行摘要，并丢弃重要性较低的观察记录。难点在于判断哪些信息可以安全丢弃——若移除了后续仍需要的内容，Agent 可能在没有报错的情况下静默失败。
技能发现（Skill Discovery）
与其在提示词中一次性加载全部工具，技能可以自行注册，由 Agent 在运行时按需查询所需能力。这能减少 token 浪费、保持上下文干净，机制上类似后端系统中的服务发现（service discovery）。
工具调用可靠性
提升工具调用可靠性的常见手段包括：
- 在执行前对模型输出进行校验，确认参数合法后再运行。
- 编写清晰的工具描述。模式（schema）若含糊，模型更容易猜错参数。
- 在提示词中提供少量示例（few-shot），帮助模型对齐预期的调用格式。
可观测性与调试
多 Agent 系统的失败排查依赖跨所有 Agent 的链路追踪，通常通过共享的追踪 ID（trace ID）串联。缺少追踪时，很难定位是哪个 worker、因何原因失败。因此可观测性需要从设计之初就内建，而非事后补充。
非确定性与评测
Agent 系统最大的工程挑战之一是非确定性：相同输入在不同运行中可能产生不同行为，因此无法用精确输出匹配来做测试。
更适用的做法是构建评测（evals），以任务完成度和失败模式等指标来衡量系统表现，而非逐字符比对输出。
参考与说明
- 本文整理的是 AI Agent 工程中广泛讨论的通用概念（ReAct、多 Agent、记忆管理、评测等）。
- 具体框架、API 与最佳实践会快速演进，实现时应以相关项目的最新官方文档为准。
- 本文不含任何特定项目、企业或个人的实现细节。