Agent 开发中心总览：模型、工具、记忆、RAG、编排、评测与部署

过去两年里，LLM 应用从"聊天机器人"迅速演进到"Agent 系统"。两者的关键区别不在于是否使用大模型，而在于：模型输出是否真正参与了工作流控制。普通聊天应用主要生成文本；Agent 则会在目标约束下进行规划、调用工具、读取外部知识，维护状态，并在多步任务中持续修正行动。OpenAI 对 Agents SDK 的定义也强调了这一点：Agent 是能够规划、调用工具、在专家之间协作并保持足够状态以完成多步工作的应用。

这篇文章是「Agent 开发中心」系列的第一篇。它不试图一次讲完所有细节，而是建立一个工程化视角下的全局框架：一个可用的 Agent 系统，至少由模型接入、工具调用、记忆系统、RAG 检索、任务编排、评测观测和部署安全七个部分组成。后续文章会分别深入每个模块。

一、什么是 Agent？#

在工程语境中，可以把 Agent 理解为：

一个由大模型驱动、能够根据目标选择行动，并通过工具、记忆和外部环境完成多步任务的软件系统。

这个定义里有四个关键词。

第一是目标。 Agent 不是简单回答一句话，而是围绕用户目标完成任务。例如"帮我分析这批论文并生成阅读路线"，不是一次文本生成，而是需要检索、筛选、总结、排序、引用和输出。

第二是行动。 Agent 必须能够调用外部工具，例如搜索、数据库、文件系统、代码执行器、浏览器、API、工作流系统等。ReAct 论文的核心思想正是让模型交替生成推理轨迹和行动：推理用于更新计划、跟踪状态和处理异常，行动用于连接外部环境并获得新的观察结果。

第三是状态。 多步任务不能只依赖单轮 prompt。Agent 需要维护当前任务进度、工具返回结果、历史决策、用户偏好、失败记录和中间产物。MemGPT 将这一问题类比为操作系统中的层级内存管理，提出通过不同 memory tiers 管理有限上下文窗口之外的信息。

第四是闭环。 Agent 不是"生成一个计划就结束"，而是持续执行：观察、推理、行动、反馈、修正，直到任务完成或触发停止条件。AgentBench 也正是基于这种交互式、多轮、开放式环境来评估 LLM-as-Agent 的推理和决策能力。

二、Agent 与 Workflow 的区别#

很多系统看起来像 Agent，但本质上只是 Workflow。两者的区别在于：流程控制权在哪里。

Workflow 的流程通常由开发者预先定义：

输入问题 → 检索知识库 → 调用模型总结 → 返回答案

这类系统可以非常可靠，也适合生产环境。它的优点是可控、可测、成本稳定；缺点是灵活性有限。

Agent 的流程则更动态：

输入目标 → 模型判断是否需要检索
  → 如果检索不足，改写 query
  → 如果需要计算，调用计算工具
  → 如果答案不确定，继续查证
  → 生成最终回答

也就是说，Agent 不是完全按照固定流程执行，而是由模型在一定边界内决定下一步动作。Hugging Face 的 smolagents 文档把 Agent 描述为"LLM 输出控制工作流"的程序，并强调 agency 不是二元概念，而是一个连续谱：模型对工作流控制得越多，系统的 agentic 程度越高。

所以，在工程上不要盲目追求"全 Agent 化"。可重复、确定性强的任务应该优先使用 Workflow；步骤不确定、需要探索、需要工具选择和异常处理的任务，才适合引入 Agent。

三、Agent 的核心架构#

一个实用 Agent 系统可以抽象为以下结构：

用户目标
  ↓
任务入口 / Orchestrator
  ↓
模型接入层
  ↓
规划与决策
  ↓
工具调用层 ←→ 外部 API / 数据源 / 文件 / 浏览器 / 代码执行器
  ↓
记忆系统 ←→ 短期状态 / 长期记忆 / 任务日志
  ↓
RAG 检索 ←→ 向量库 / 文档库 / 结构化知识
  ↓
评测与观测 ←→ Trace / Metrics / Logs / 成本 / 失败归因
  ↓
结果输出 / 人类确认 / 部署运维

这个架构的关键不是"模型有多强"，而是各层之间是否有明确边界。模型负责推理和选择，工具负责执行，记忆负责状态，RAG 负责外部知识，编排层负责流程控制，观测系统负责解释发生了什么。

四、模型接入层：不要把模型调用写死#

模型接入层是 Agent 系统的底座。早期项目常见写法是直接在业务代码里调用某个模型接口：

业务逻辑 → 调用模型 → 返回结果

这在 Demo 阶段没问题，但一旦进入生产，就会遇到问题：

• 如何切换不同模型？
• 如何处理超时、重试、限流？
• 如何记录 token、成本、延迟？
• 如何处理长上下文？
• 如何为不同任务选择不同模型？
• 如何在模型失败时 fallback？

因此，模型接入层至少应该抽象出以下能力：

ModelClient       — 模型调用封装
ModelRouter       — 多模型路由
PromptTemplate    — Prompt 模板管理
ContextBuilder    — 上下文构建
CostTracker       — 成本记录
RetryPolicy       — 重试策略
FallbackPolicy    — 降级策略

OpenAI Agents SDK 的文档建议：当应用需要自己负责编排、工具执行、审批和状态时，应使用 Agents SDK 这类 Agent 运行时抽象，而不是只使用直接模型请求。

从更开放的生态看，MCP 试图解决另一个关键问题：模型应用如何以标准化方式连接外部工具和数据源。Anthropic 将 MCP 定义为一个开放标准，用于在 AI 应用与数据源/工具之间建立安全的双向连接。这意味着未来 Agent 的"模型接入"不仅是模型 API 封装，还会进一步扩展到工具、上下文和数据源协议化。

五、工具调用：Agent 走向真实世界的接口#

没有工具调用，Agent 只是一个会思考的语言模型；有了工具调用，Agent 才能真正影响外部世界。

工具可以是：

搜索引擎       数据库查询       文件读写
代码执行       浏览器操作       邮件发送
日历管理       支付/订单 API   内部业务系统 API

ReAct 证明了推理与行动交替的价值：推理轨迹帮助模型跟踪计划、处理异常；行动让模型与外部知识库或环境交互，从而减少纯语言推理中的幻觉和错误传播。

Toolformer 则从训练角度研究模型如何学会使用工具：它让模型学习何时调用 API、传什么参数、如何把工具结果纳入后续预测，并且只需要少量示例就能构造自监督训练数据。

Gorilla 进一步聚焦 API 调用准确性。它指出，LLM 在工具调用中的核心困难是生成正确参数和避免错误 API hallucination；论文提出 APIBench，并展示了结合检索器后，模型可以适应 API 文档变化并降低工具使用幻觉。

因此，工程上设计工具时要遵循几个原则：

1. 工具描述必须清晰，不要依赖模型猜测。
2. 参数 schema 必须严格，能用枚举就不要用自由文本。
3. 工具权限必须最小化，禁止把高风险能力直接暴露给模型。
4. 工具返回值要结构化，避免大段无格式文本。
5. 工具调用必须有超时、重试、审计和人工确认机制。

一个成熟 Agent 系统的工具层，不只是 function calling，而是一个具备 schema、权限、沙箱、日志、重试和审计能力的执行层。

六、记忆系统：解决上下文窗口之外的问题#

Agent 的记忆系统不是简单把聊天历史塞进 prompt。上下文窗口再大，也无法无限保存所有任务历史、用户偏好、文件内容和中间结果。

记忆系统通常可以分为四类：

短期记忆：当前任务上下文、工具结果、临时状态。
长期记忆：用户偏好、历史经验、长期知识。
情景记忆：某次任务中的关键事件、失败与修正。
技能记忆：可复用的工具使用模式、代码片段、任务模板。

MemGPT 的核心贡献是把 LLM 应用中的上下文管理类比为操作系统的虚拟内存：通过不同层级的 memory tiers，在有限上下文窗口内提供近似扩展上下文的能力。它的实验场景包括长文档分析和多轮长期对话，这正是普通 LLM 上下文容易失效的场景。

Generative Agents 则展示了另一种记忆架构：观察、记忆、反思和规划结合，用来模拟可信的人类行为。该方向说明，记忆不仅是存储历史，还要参与反思、抽象和计划生成。

在工程上，记忆系统不能无脑写入向量库。更合理的做法是分层：

事件日志：记录发生了什么。
摘要记忆：压缩长历史。
向量记忆：支持语义召回。
结构化记忆：保存偏好、配置、事实。
任务状态：记录当前任务进度。

记忆越强，风险也越大。生产系统必须考虑记忆污染、隐私、过期策略、用户可删除性和引用可追溯性。

七、RAG：Agent 的外部知识系统#

RAG 是 Agent 系统中最常见的知识增强方式。原始 RAG 论文提出将参数化记忆和非参数化记忆结合：模型参数保存通用能力，外部检索索引提供可更新、可追溯的知识。

RAG 的基本流程是：

用户问题 → Query 改写 → 文档召回 → 重排序 → 上下文压缩 → 生成答案 → 引用来源

但在 Agent 系统里，RAG 不应该只是固定前置步骤。更合理的是 Agentic RAG：

模型判断是否需要检索
  → 判断应该检索什么
  → 检索后评估证据是否足够
  → 不足则改写 query 或换数据源
  → 最终生成带证据的答案

RAG Survey 将 RAG 的演进分为 Naive RAG、Advanced RAG 和 Modular RAG，并系统分析了 retrieval、generation、augmentation 三个核心环节。

从工程角度看，RAG 的关键难点不在"接一个向量库"，而在以下问题：

1. 文档如何切分？
2. Query 如何改写？
3. 召回结果如何重排？
4. 上下文如何压缩？
5. 答案如何引用来源？
6. 如何评估 faithfulness？
7. 如何处理无答案场景？

如果没有评测，RAG 很容易成为"看起来很复杂、但不知道是否有效"的系统。

八、任务编排：从 Agent Loop 到状态机#

Agent 执行多步任务时，必须有编排层。简单 Agent 可以使用 ReAct Loop：

Observe → Think → Act → Observe → ... → Final Answer

但真实业务通常需要更严格的结构。例如：

Research Agent → Draft Agent → Review Agent → Citation Checker → Final Writer

或者：

计划生成 → 人类确认 → 工具执行 → 异常重试 → 结果校验 → 发布

这类系统更适合用状态机、DAG 或图来描述。LangGraph 的定位就是为长运行、有状态的 Agent 和工作流提供低层级编排基础设施。其官方文档强调，它不抽象 prompt 或架构，而是提供支撑长运行、有状态 workflow/agent 的基础能力。

在工程上，任务编排需要回答几个问题：

谁决定下一步？
什么时候停止？
失败是否重试？
是否需要人工确认？
状态如何持久化？
工具结果是否可回放？
每一步如何观测？

没有编排层，Agent 很容易变成"while 循环里不断调用模型"的不可控系统。

九、评测：Agent 不能只看最后回答#

传统 LLM 评测常关注单轮问答正确率，但 Agent 评测更复杂，因为 Agent 会调用工具、产生中间状态、与环境交互，还可能在最后答案正确但过程错误，或者过程合理但最后失败。

AgentBench 明确指出，随着 LLM 越来越多地面向真实任务，需要在交互式环境中评估其作为 Agent 的推理和决策能力。它构建了多个环境，用于评估多轮开放式生成场景下的 LLM-as-Agent。

一个实用 Agent 评测体系至少要包括：

任务成功率
工具调用准确率
平均步骤数
失败类型分布
平均延迟
平均成本
人工介入次数
安全违规次数
答案引用正确率
可复现性

对于 RAG Agent，还要评估：召回率、上下文相关性、答案忠实度、引用准确性、无答案识别能力。

对于工具 Agent，还要评估：工具选择是否正确、参数是否正确、是否重复调用、是否越权调用、失败后是否能恢复。

没有评测的 Agent 系统，本质上只是 Demo。

十、观测：让 Agent 的失败可解释#

Agent 系统最大的生产问题之一是：失败往往不是一个点，而是一条链。

例如用户只看到"答案不对"，但真正原因可能是：

Query 改写错误 → 检索召回错误 → 重排序失败 → 工具参数错误 → 模型误判工具结果 → 上下文超长被截断 → 安全策略阻断 → 下游 API 超时

所以 Agent 必须内建可观测性。

OpenTelemetry 是厂商中立的开源观测框架，用于生成、采集和导出 traces、metrics 和 logs。OpenAI Agents SDK 也提供内置 tracing，能够记录模型调用、工具调用、handoff、guardrails 和自定义 span，帮助调试和监控 Agent 工作流。

一个 Agent Run 至少应该记录：

trace_id
user_id / session_id
task_id
model calls
prompt tokens / completion tokens
tool calls
tool arguments
tool outputs
retrieved documents
rerank scores
latency
cost
errors
final status

有了 trace，才能回答三个生产问题：

1. 为什么失败？
2. 钱花在哪里？
3. 哪一步最慢？

十一、部署与安全：Agent 的能力越强，边界越重要#

Agent 的风险来自它能行动。一个只会回答问题的模型，最多产生错误内容；一个能调用工具的 Agent，可能误删文件、误发邮件、误调用支付接口、泄露隐私数据或执行危险命令。

因此，生产 Agent 必须遵循最小权限原则：

1. 工具按任务授权，不要暴露全量工具。
2. 高风险工具必须人工确认。
3. 文件、网络、代码执行必须沙箱化。
4. 所有工具调用必须审计。
5. 外部输入必须防 prompt injection。
6. 密钥只能在服务端安全存储，不能进入前端或上下文。
7. Agent 不能直接访问不必要的用户隐私数据。

MCP 的出现说明工具和数据源连接正在协议化，但协议化并不等于自动安全。真正落地时，权限、沙箱、白名单、日志和人工确认仍然需要应用自己设计。

十二、一个可落地的 Agent 开发路线#

不建议一开始就做"全自动超级 Agent"。更合理的路线是分阶段演进。

第一阶段：Workflow 优先#

先把确定性流程写清楚：输入 → 检索 → 生成 → 校验 → 输出。重点是稳定，不追求自治。

第二阶段：引入工具调用#

让模型在受控范围内调用工具：搜索、数据库查询、文件读取、计算器、内部 API。工具必须有 schema、权限和日志。

第三阶段：加入记忆与状态#

为多轮任务引入：任务状态、短期上下文、长期偏好、事件日志、摘要记忆。

第四阶段：升级为 Agentic RAG#

让模型决定：是否检索、检索什么、证据是否足够、是否需要二次检索。

第五阶段：完善评测与观测#

建立：任务集、测试环境、Trace、成本统计、失败分类、回归评测。

第六阶段：生产化部署#

增加：权限控制、人工审批、限流、重试、沙箱、审计日志、报警。

十三、结语#

Agent 的核心不是"让模型自己做一切"，而是把模型放进一个有边界、有工具、有记忆、有评测、有观测的工程系统里。

Agent = LLM 推理能力 + 工具执行能力 + 状态记忆能力 + 知识检索能力 + 编排控制能力 + 评测观测能力。

ReAct 解决了推理与行动如何结合的问题；Toolformer 和 Gorilla 推进了工具调用能力；MemGPT 讨论了长期上下文和记忆管理；RAG 解决了外部知识接入；LangGraph、Agents SDK 和 MCP 则代表了工程编排与工具协议化方向；AgentBench 和 OpenTelemetry 相关工具则提醒我们，Agent 最终必须可评测、可观测、可运维。

这也是「Agent 开发中心」后续文章要展开的主线：不是追逐概念，而是从模型接入、工具调用、记忆系统、RAG、编排、评测、观测和部署安全出发，构建真正可落地的 Agent 工程体系。

参考资料#