简介：当应用从“一问一答”的大模型对话，走向能调用工具、修改环境状态的AI Agent，沿用静态打分的评估方法会迅速失真。本文系统对比LLM评估与Agent评估在评估对象、环境依赖、评分方法、指标体系、可重复性与成本结构上的核心差异，并给出典型场景选型建议与迁移注意事项，帮助技术团队搭建与Agent复杂度相匹配的评估体系。
近期，某头部AI研究机构发布了一篇关于Agent评估的万字工程长文，系统阐述了系统化评估AI Agents的工程方法，在开发者社区引发了广泛讨论。这类文章之所以受关注，是因为它戳中了当下工程团队的共同痛点：模型应用正在从“对话”进化为“执行”，而评估体系却没有跟上。
早期的大模型评估非常简单，可以概括为一个三段式流程：
这套方法在问答、摘要、翻译、改写等纯文本场景中运转良好。但Agent不是在做填空题。Agent是一个在环境中“活着”的实体，它执行的是任务循环：调用工具、观察结果、修正计划、修改环境状态。评估对象从“一次输出”变成“一段轨迹”，评估逻辑自然要推倒重建。
因此，本文聚焦一个具体对比：LLM评估（面向模型输入输出的静态评估）与AI Agent评估（面向任务执行过程的动态评估）到底有什么区别，团队应如何在两者之间配置评估资源。
LLM评估的对象是模型的输入输出映射。给定一个静态题库（prompt集合），运行模型得到回复，再用评分器（规则匹配、参考答案比对，或由另一个模型辅助打分）判定质量，最终汇总出准确率、通过率等指标。它隐含三个假设：
Agent评估的对象是一个系统：模型、工具、环境状态、规划与记忆模块组成的动态闭环。评估时需要先搭建（或快照）一个可运行环境，向Agent下达任务目标，由Agent自主执行多步操作，评估者最终从三个层面判定：
业界普遍做法是把Agent评估进一步拆为两个层次：组件级评估（评估单个模块，例如工具选择器在给定状态下的输出质量）与端到端评估（评估整个系统在完整任务上的表现）。组件级评估在形式上更接近LLM评估，端到端评估则是Agent独有的形态。
尽管形态差异巨大，两者仍共享一组工程底座：
理解这些相同点很有价值：团队从LLM评估迁移到Agent评估时，不必从零开始，可以复用已有的数据管理、评分器与报告框架，主要新增的是“环境”与“轨迹”两块能力。
这是所有差异的根源。LLM评估衡量“一次生成的质量”；Agent评估衡量“一段行为序列的质量”。同一个任务，Agent每次执行的路径都可能不同——先查再改、先改再验证、中途失败重试——最终结果可能都对，但成本与风险差异巨大。因此Agent评估必须同时覆盖“结果正确”与“过程合理”，而LLM评估天然只需要前者。
LLM评估只需要一个推理接口和一份题库；Agent评估必须维护可运行的环境：工具是否可用、外部依赖是否稳定、初始状态是否一致。环境引入了两类新问题：
LLM评估的判分集中在“回复文本”这一个点上；Agent评估的判分是分层的：终态断言、轨迹审查、过程指标三者缺一不可。两者的示意性伪代码对比：
# LLM评估：单点判分for sample in dataset: # 静态题库answer = llm.generate(sample.prompt)verdict = grader(answer, sample.reference)record(verdict)report(accuracy)
# Agent评估：多层断言for task in task_suite:env = sandbox.reset(task.initial_state) # 环境初始化/快照trajectory = agent.run(task.goal, env) # 多步自主执行checks = [assert_env_state(env, task.expected_state), # 终态断言review_trajectory(trajectory, policy_rules), # 轨迹审查measure_cost(trajectory) # 步数/成本指标]record(task.id, checks)report(task_success_rate, avg_steps, avg_cost, violation_rate)
实践中一个常见教训是：只看终态会让“碰巧撞对”的低质量轨迹蒙混过关；只看轨迹又会让“过程优雅但结果错误”的执行被高估。两层必须同时存在，且终态断言应尽量用程序化检查实现，可靠性与可维护性都高于文本比对。
LLM评估的典型指标是准确率、格式合规率、人工评分分布；Agent评估的核心指标则是一组向量：
单看任何一项都会误导决策：成功率高但成本失控的Agent，在生产环境可能完全不可用。
LLM评估在固定解码参数下波动可控，跑两次分数接近；Agent评估的方差被三个因素放大：模型采样随机性、环境异步性（工具响应顺序不确定），以及长轨迹上的误差累积——早期一步的分支选择会让后续路径完全分叉。工程上通常需要：多次采样并报告分布、固定环境快照、严格锁定模型与工具版本，并对指标报告区间而非单点值。
一次LLM评估的成本约等于题库token总量；一次端到端Agent评估的成本是“任务数×平均轨迹长度×每步token”，再叠加环境搭建与外部调用成本，通常高出一到两个数量级。基础设施层面，Agent评估额外需要：沙箱环境管理、轨迹存储与回放、环境快照版本化、失败样本的可视化审查工具。若团队已在百度智能云等云平台构建大模型应用，可评估将运行的算力、日志与监控类通用能力挂接到既有平台上，降低自建运维成本，但需同时确认数据是否允许进入云上环境。
LLM评估失败时，问题基本出在“模型能力或prompt表达”上；Agent评估失败时，可能出在任务理解、规划、工具选择、参数生成、结果观察理解、状态维护、错误恢复等任意环节。因此Agent评估体系必须配套轨迹分析能力，否则只知道“失败了”，不知道“败在哪一环”，改进无从下手。
| 对比维度 | LLM评估 | AI Agent评估 |
|---|---|---|
| 评估对象 | 模型的输入输出映射 | 模型+工具+环境状态组成的动态系统 |
| 输入输出关系 | 近似确定，输出可控 | 同一任务可产生多条不同执行轨迹 |
| 环境依赖 | 弱，只需推理接口与题库 | 强，需沙箱、工具、状态快照与隔离 |
| 判分方式 | 参考答案比对、规则/模型打分 | 终态断言+轨迹审查+过程指标 |
| 核心指标 | 准确率、格式合规、人工分 | 任务成功率、步数、成本、违规率 |
| 可重复性 | 较高 | 较低，需多次采样与版本锁定 |
| 基础设施 | 脚本+数据集+报告 | 沙箱管理、轨迹存储回放、快照版本化 |
| 成本量级 | 低（题库token总量） | 高，通常高一至两个数量级 |
| 失败定位 | prompt或模型能力 | 规划/工具选择/参数/观察/状态多环节 |
| 典型用途 | 组件级评估、文本应用验收 | 端到端验收、发布门禁、回归检测 |
场景一：纯文本能力应用（问答、摘要、文案、分类抽取）。评估主体是模型输出质量，LLM评估体系完全够用，重点投入题库质量与评分器校准。
场景二：工作流自动化Agent（数据处理、运维操作、跨系统任务执行）。环境交互是能力核心，必须建立端到端Agent评估：任务套件+沙箱+终态断言；同时对关键组件（如工具选择）保留组件级评估，用于快速定位回归来源。
场景三：混合形态应用（带少量工具调用的对话产品）。采用“LLM评估为主+少量端到端冒烟任务”的组合策略：低成本评估覆盖主体能力，少量端到端任务守住关键流程。
场景四：高风险Agent（涉及资金、权限变更、数据写操作）。在标准Agent评估之上强制增加策略违规检测与人工审查环节，并将过程指标的优先级提到与结果指标同级甚至更高。
基于以上差异，可以给出几条条件化判断：
从LLM评估迁移到Agent评估体系，需要提前规划：
回到最初的问题：LLM评估与Agent评估的区别，本质上不是“评估技术”的区别，而是“评估对象”的区别，前者评估一个函数的输出，后者评估一个系统在环境中的行为。对象变了，环境依赖、评分方法、指标体系、基础设施与成本结构就要跟着变。
决策思路可以收敛为三句话：产品是否依赖环境交互，决定了要不要建设Agent评估；团队的工程与运维能力，决定了自建还是依托平台化方案；业务对成本与安全的敏感度，决定了指标权重与发布门禁的设定。评估体系不是越重越好，而是与被评估对象的真实复杂度匹配才好，在纯文本场景里堆Agent评估是浪费，在多步任务场景里只跑静态打分是危险，在两者之间找到自己产品的位置，才是工程上的最优解。