2. AI Agent基础：定义、架构、类型与典型应用场景
在深入探讨AI Agent的性能评估与优化之前，必须先建立对Agent本体的清晰认知。性能评估的本质是度量“目标达成效率”与“资源消耗”之间的比值，而目标、策略、工具调用方式、记忆机制等恰恰是由Agent的架构与类型决定的。如果脱离架构谈指标，评估就会沦为对随机波动的描述。本章将系统梳理Agent的定义边界、核心架构范式（ReAct与Plan-and-Execute）、主流类型划分，并结合典型应用场景说明不同设计选择对性能评估维度（延迟、成功率、消耗、鲁棒性）的直接影响。
2.1 Agent的定义与核心构成
核心原理：AI Agent（智能体）并非简单的“大模型+API调用”，而是一个具备自主感知、决策规划、工具执行、记忆管理能力的闭环系统。与单轮对话机器人不同，Agent能够根据目标拆解任务，在多次推理中动态调整策略，并调用外部工具（数据库、搜索引擎、代码解释器、业务系统）来改变环境状态。从性能评估视角看，Agent的“智能”体现在三个可量化维度：决策质量（每一步选择的正确性）、执行效率（完成目标所需的步骤与数）、容错能力（面对错误反馈时的恢复策略）。
一个完整的Agent系统通常包含以下模块：
- 大语言模型（LLM）核心：负责自然语言理解、推理、生成。其上下文窗口大小直接影响Agent可处理的记忆量，进而影响长任务稳定性。
- 规划器（Planner）：将复杂目标分解为子任务，决定执行顺序。规划策略的优劣直接决定任务完成路径的长度。
- 工具调用层（Tool Use）：通过函数调用（Function Calling）或代码执行与外部世界交互。工具选择的准确性是评估重点。
- 记忆模块（Memory）：短期记忆（当前对话上下文）与长期记忆（向量数据库、知识库）。记忆的读写策略影响多轮任务的一致性。
- 反馈循环（Feedback Loop）：从环境或工具返回结果中提取信号，用于修正下一步动作。这是鲁棒性评估的关键。
2.2 主流架构范式：ReAct与Plan-and-Execute
判断方法：架构选择决定了Agent的“思考节奏”与“行动粒度”，直接影响性能指标。以下是两种主流范式的对比：
| 对比维度 | ReAct（推理+行动交替） | Plan-and-Execute（先规划后执行） |
|---|---|---|
| 工作方式 | Thought（思考）→ Action（行动）→ Observation（观察）循环 | 先生成完整计划（Plan），再逐步执行（Execute），执行中可微调 |
| 延迟特征 | 每步交替，延迟较高（多次LLM调用） | 规划阶段一次性消耗，执行阶段延迟相对可控 |
| 消耗 | 可能因反复试错产生大量推理 | 规划固定，但计划偏差可能导致返工 |
| 适用场景 | 需要动态探索的任务（如网页操作、故障排查） | 目标明确、步骤可预见的任务（如批量数据处理） |
| 鲁棒性 | 对突发错误反馈适应性强 | 对计划外情况处理较弱，需额外反射机制 |
操作流程：在实际工程中，选择架构时需评估任务的不确定性。若任务环境高度动态（如实时股票分析），ReAct的“边看边走”策略更优；若任务流程固定（如月度报表生成），Plan-and-Execute能显著降低开销。混合式架构（先规划，执行中遇到异常再切换ReAct模式）是当前工业界平衡效率与鲁棒性的常见做法。
2.3 Agent类型划分与评估侧重点
核心原理：根据自主程度、记忆能力和协作方式，Agent可分为多种类型。不同类型的评估指标权重差异显著：
- 单任务Agent：专注于特定领域（如SQL查询助手）。评估重点为工具调用准确率与单轮响应延迟。
- 多任务Agent：需在不同任务间切换。评估重点为任务切换开销与上下文污染率（前一个任务的信息是否干扰后一个任务）。
- 有状态Agent：维护跨会话记忆。评估重点为记忆召回准确率与长期一致性。
- 多Agent协作系统：多个Agent分工（如程序员Agent、测试Agent）。评估重点为通信开销、任务分配均衡度、整体完成时间。
案例拆解：以某电商平台的智能客服Agent为例，其采用ReAct架构，工具包括订单查询API、退换货API、知识库检索。初始现象：系统上线后平均响应延迟达4.2秒，超出业务线3秒的SLA要求。通过日志分析发现，Agent在处理“订单状态查询”时，经常先调用“用户身份验证”工具，再调用“订单列表”工具，最后才查询具体订单，共3次LLM推理+3次工具调用。优化方案：在规划器中加入“意图-工具映射”缓存，对高频简单意图（如查物流）直接绑定固定工具序列，跳过中间推理步骤。优化后，该场景延迟降至1.8秒，消耗减少40%。复盘经验：ReAct架构的灵活性带来了推理开销，对于确定性高的子任务，应通过“规则前置”或“快捷路径”降低不必要的推理。
2.4 典型应用场景与性能基准
判断方法：不同场景对Agent性能的约束截然不同，评估前必须先定义场景SLA。以下为三类典型场景的评估基准建议：
| 场景 | 核心指标 | 建议阈值 | 架构倾向 |
|---|---|---|---|
| 智能客服 | 首响延迟、问题解决率 | 首响<1.5s，解决率>85% | ReAct + 意图缓存 |
| 数据分析报告 | 任务完成率、/报告 | 完成率>90%，<50k | Plan-and-Execute |
| 代码生成与审查 | 代码运行通过率、误报率 | 通过率>80%，误报<10% | 多Agent协作 |
操作流程：建立场景基准时，应准备黄金数据集（包含输入、预期工具调用序列、预期输出）。评估时不仅比对最终结果，还需比对“过程轨迹”（即Agent的每一步动作），以识别规划冗余或工具误用。
总结复盘：Agent性能评估的起点是“架构理解”。只有明确Agent是ReAct还是Plan-and-Execute，是单Agent还是多Agent协作，才能设计出有针对性的评估方案。例如，对于ReAct架构，应重点分析“思考-行动”循环次数；对于Plan-and-Execute，应重点分析计划与实际的偏差率。后续章节将深入讲解如何构建这些评估指标体系与采集工具。