Agent Evaluation 深度调研报告

调研日期：2026-03-01 调研主题：Agent Evaluation（智能体评估）

第一部分：概念剖析

核心原理与架构深度解析

一、定义澄清

通行定义

Agent Evaluation（智能体评估） 是指对基于大语言模型（LLM）的智能体系统进行系统性测试和度量的过程，旨在量化其在以下维度的表现：

1. 任务完成能力：能否正确执行用户指定的目标
2. 工具使用能力：能否有效调用外部 API、数据库、代码等工具
3. 规划与推理能力：能否进行多步规划、逻辑推理、问题分解
4. 鲁棒性与安全性：在边界情况和对抗输入下的表现
5. 效率与成本：完成任务所需的时间、Token 消耗、API 调用次数

常见误解

边界辨析

二、核心架构

┌────────────────────────────────────────────────────────────┐
│                    Agent Evaluation System                  │
├────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐ │
│  │  Test Suite  │    │  Evaluator   │    │   Reporter   │ │
│  │   Generator  │───▶│    Engine    │───▶│   & Dashboard│ │
│  └──────────────┘    └──────────────┘    └──────────────┘ │
│         │                   │                   │          │
│         ▼                   ▼                   ▼          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              Benchmark Environments                  │   │
│  ├────────────┬────────────┬────────────┬─────────────┤   │
│  │  WebArena  │ AgentBench │  SWE-bench │   Custom    │   │
│  │  (Web UI)  │  (Multi)   │  (Coding)  │  Env (API)  │   │
│  └────────────┴────────────┴────────────┴─────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              Agent Under Test (AUT)                  │   │
│  ├────────────┬────────────┬────────────┬─────────────┤   │
│  │    LLM     │   Memory   │   Tools    │  Planner    │   │
│  │  (GPT-4/   │  (Vector/  │  (Search/  │  (CoT/ToT/  │   │
│  │  Claude)   │  Graph)    │  Code/DB)  │   ReAct)    │   │
│  └────────────┴────────────┴────────────┴─────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                 Metrics Layer                        │   │
│  ├────────────┬────────────┬────────────┬─────────────┤   │
│  │  Accuracy  │  Efficiency│   Safety   │  Cost       │   │
│  │  (Pass@k)  │  (Steps/   │  (Reward   │  ($/Task)   │   │
│  │            │   Latency) │  Hacking)  │             │   │
│  └────────────┴────────────┴────────────┴─────────────┘   │
│                                                             │
└────────────────────────────────────────────────────────────┘

组件职责说明：

三、数学形式化

1. 任务完成率（Task Success Rate）

• $N$：测试任务总数
• $\tau_i$：Agent 在第 $i$ 个任务上产生的执行轨迹（Trajectory）
• $g_i$：第 $i$ 个任务的目标描述
• $\text{Verify}(\cdot)$：验证函数，判断轨迹是否达成目标
• $\mathbb{I}[\cdot]$：指示函数，条件为真时取 1，否则为 0

自然语言解释：任务完成率 = 成功完成的任务数 / 总任务数

2. 效率分数（Efficiency Score）

• $S_i$：Agent 在第 $i$ 个任务上的实际步数
• $T_i$：实际耗时（秒）
• $C_i$：实际成本（Token 数或美元）
• $S_{\text{opt}}, T_{\text{opt}}, C_{\text{opt}}$：理论最优值（或基准值）
• $w_1, w_2, w_3$：权重系数（$w_1 + w_2 + w_3 = 1$）

自然语言解释：效率分数衡量 Agent 在成功完成任务的前提下，相对于最优解的步数、时间、成本的综合表现。

3. 工具使用准确率（Tool Call Accuracy）

• $M$：总工具调用次数
• $\text{Tool}_j^{\text{pred}}$：Agent 预测的第 $j$ 次调用的工具名
• $\text{Args}_j^{\text{pred}}$：预测的参数
• $\approx$：参数相似度（可用编辑距离、语义相似度等度量）

自然语言解释：工具使用准确率 = 正确工具调用次数 / 总调用次数

4. 鲁棒性分数（Robustness Score）

• $K$：扰动类型数量（同义替换、噪声注入、对抗 Prompt 等）
• $\text{Score}_{\text{clean}}$：原始输入下的性能得分
• $\text{Score}_{\text{perturbed}, k}$：第 $k$ 种扰动下的性能得分

自然语言解释：鲁棒性分数衡量 Agent 在面对输入扰动时的性能稳定性，越接近 1 表示越鲁棒。

5. 综合评估分数（Overall Evaluation Score）

• $\alpha, \beta, \gamma, \delta, \epsilon$：可配置权重，反映不同场景下的优先级
• $\text{Risk}$：安全风险惩罚项（如 Reward Hacking 检测结果）

自然语言解释：综合分数 = 加权和（任务完成率 + 效率 + 工具准确率 + 鲁棒性） - 安全风险惩罚

四、实现逻辑（Python 伪代码）

from dataclasses import dataclass
from typing import List, Dict, Any, Callable
from abc import ABC, abstractmethod
import numpy as np

@dataclass
class Task:
    """测试任务定义"""
    id: str
    description: str
    initial_state: Dict[str, Any]
    goal: str
    success_criteria: Callable[[Dict], bool]
    max_steps: int = 50
    timeout_seconds: int = 300

@dataclass
class Trajectory:
    """Agent 执行轨迹"""
    steps: List[Dict[str, Any]]  # 每步：observation, action, tool_call, response
    success: bool
    total_steps: int
    total_time: float
    total_cost: float
    final_state: Dict[str, Any]

class Environment(ABC):
    """测试环境基类"""

    @abstractmethod
    def reset(self) -> Dict[str, Any]:
        """重置环境，返回初始状态"""
        pass

    @abstractmethod
    def step(self, action: Dict[str, Any]) -> Dict[str, Any]:
        """执行一步，返回新状态"""
        pass

    @abstractmethod
    def verify_success(self, state: Dict[str, Any], goal: str) -> bool:
        """验证是否达成目标"""
        pass

class AgentEvaluationSystem:
    """Agent 评估系统核心类"""

    def __init__(self, config: Dict[str, Any]):
        # 核心组件
        self.agent = config["agent"]  # 待评估的 Agent
        self.environments = config["environments"]  # 环境列表
        self.metrics_config = config["metrics"]  # 指标配置

        # 评估器组件
        self.judge_llm = config.get("judge_llm", None)  # LLM-as-a-Judge
        self.human_evaluators = config.get("human_evaluators", [])

        # 追踪器
        self.tracer = config.get("tracer", None)  # 执行轨迹追踪

    def run_evaluation(self, tasks: List[Task]) -> Dict[str, float]:
        """
        执行完整评估流程
        """
        trajectories = []

        for task in tasks:
            # 1. 选择合适的环境
            env = self._select_environment(task)

            # 2. 执行任务，收集轨迹
            trajectory = self._execute_task(task, env)
            trajectories.append(trajectory)

            # 3. 实时记录指标
            self._record_metrics(trajectory)

        # 4. 计算综合指标
        results = self._compute_aggregate_metrics(trajectories)
        return results

    def _execute_task(self, task: Task, env: Environment) -> Trajectory:
        """执行单个任务"""
        env.reset()
        steps = []
        total_cost = 0.0
        start_time = time.time()

        for step_num in range(task.max_steps):
            # Agent 决策
            observation = env.get_state()
            action = self.agent.decide(observation, task.goal)

            # 执行动作
            response = env.step(action)

            # 记录轨迹
            steps.append({
                "step": step_num,
                "observation": observation,
                "action": action,
                "response": response,
                "cost": action.get("cost", 0.0)
            })
            total_cost += action.get("cost", 0.0)

            # 检查终止条件
            if task.success_criteria(env.get_state()):
                return Trajectory(
                    steps=steps,
                    success=True,
                    total_steps=step_num + 1,
                    total_time=time.time() - start_time,
                    total_cost=total_cost,
                    final_state=env.get_state()
                )

        # 超时或达到最大步数
        return Trajectory(
            steps=steps,
            success=False,
            total_steps=task.max_steps,
            total_time=time.time() - start_time,
            total_cost=total_cost,
            final_state=env.get_state()
        )

    def _compute_aggregate_metrics(self, trajectories: List[Trajectory]) -> Dict[str, float]:
        """计算综合指标"""
        n = len(trajectories)

        # 任务完成率 (TSR)
        tsr = sum(1 for t in trajectories if t.success) / n

        # 效率分数 (ES)
        efficiency_scores = []
        for t in trajectories:
            if t.success:
                step_efficiency = 1.0 / t.total_steps  # 简化版
                time_efficiency = 1.0 / t.total_time
                cost_efficiency = 1.0 / t.total_cost
                es = (step_efficiency + time_efficiency + cost_efficiency) / 3
                efficiency_scores.append(es)
        es_avg = np.mean(efficiency_scores) if efficiency_scores else 0.0

        # 工具使用准确率 (TCA) - 需要从轨迹中提取工具调用
        tca_scores = []
        for t in trajectories:
            correct_calls = 0
            total_calls = 0
            for step in t.steps:
                if "tool_call" in step["action"]:
                    total_calls += 1
                    if self._verify_tool_call(step["action"], step["response"]):
                        correct_calls += 1
            if total_calls > 0:
                tca_scores.append(correct_calls / total_calls)
        tca_avg = np.mean(tca_scores) if tca_scores else 1.0  # 无工具调用时默认 1.0

        # 综合分数
        overall = (
            self.metrics_config["alpha"] * tsr +
            self.metrics_config["beta"] * es_avg +
            self.metrics_config["gamma"] * tca_avg
        )

        return {
            "task_success_rate": tsr,
            "efficiency_score": es_avg,
            "tool_call_accuracy": tca_avg,
            "overall_score": overall,
            "num_tasks": n,
            "num_successful": sum(1 for t in trajectories if t.success)
        }

    def _verify_tool_call(self, action: Dict, response: Dict) -> bool:
        """验证工具调用是否正确"""
        # 简化实现：检查工具是否返回错误
        return "error" not in response

    def _select_environment(self, task: Task) -> Environment:
        """根据任务类型选择环境"""
        # 简化实现：返回第一个环境
        return self.environments[0]

    def _record_metrics(self, trajectory: Trajectory):
        """记录单次轨迹的指标（用于实时监控）"""
        if self.tracer:
            self.tracer.log(trajectory)


# ==================== 使用示例 ====================

def example_usage():
    # 1. 定义测试任务
    tasks = [
        Task(
            id="web_001",
            description="在电商网站搜索商品并加入购物车",
            initial_state={"url": "https://example.com"},
            goal="找到'无线鼠标'并加入购物车",
            success_criteria=lambda state: "无线鼠标" in state.get("cart", []),
            max_steps=20,
            timeout_seconds=120
        ),
        # ... 更多任务
    ]

    # 2. 配置评估系统
    config = {
        "agent": my_agent,
        "environments": [WebArenaEnv(), AgentBenchEnv()],
        "metrics": {
            "alpha": 0.5,  # TSR 权重
            "beta": 0.3,   # ES 权重
            "gamma": 0.2   # TCA 权重
        },
        "judge_llm": "gpt-4o",
        "tracer": LangSmithTracer()
    }

    # 3. 执行评估
    evaluator = AgentEvaluationSystem(config)
    results = evaluator.run_evaluation(tasks)

    # 4. 输出结果
    print(f"任务完成率：{results['task_success_rate']:.2%}")
    print(f"效率分数：{results['efficiency_score']:.3f}")
    print(f"工具准确率：{results['tool_call_accuracy']:.2%}")
    print(f"综合得分：{results['overall_score']:.3f}")

五、性能指标

六、扩展性与安全性

扩展性

安全性考量

七、评估系统设计原则

1. 可复现性：固定随机种子、版本锁定、环境快照
2. 模块化：Agent、环境、指标、评判器可独立替换
3. 可扩展：插件架构支持新基准、新指标、新工具
4. 透明性：完整轨迹记录、可追溯决策过程
5. 效率优先：并行执行、结果缓存、增量评估
6. 人机协作：自动化为主，人工校准为辅

第二部分：行业情报

生态全景与前沿动态

一、GitHub 热门项目（17 个）

二、关键论文（12 篇）

三、系统化技术博客（10 篇）

四、技术演进时间线

2023 年之前：LLM 评估萌芽期

• 2022-11：ChatGPT 发布，引发 LLM 评估需求
• 2023-03：LangChain 首次引入评估模块
• 2023-06：HELM 框架发布，斯坦福大模型评估基准

2023 年：基准测试爆发期

• 2023-07：AgentBench 发布（THUDM）
• 2023-09：WebArena 发布（Stanford）
• 2023-11：GAIA 发布（Meta AI）
• 2023-12：SWE-bench 发布（Princeton）

2024 年：评估工具生态成熟期

• 2024-02：RAGAS 专注 RAG 评估
• 2024-04：DeepEval 提供单元测试式评估
• 2024-06：TruLens 引入可观测性
• 2024-08：LangSmith 独立为商业产品
• 2024-10：Phoenix 开源（Arize AI）

2025 年：生产级评估体系期

• 2025-01：AgentOps 统一可观测性标准
• 2025-03：多智能体评估框架兴起
• 2025-06：真实世界评估（In-the-Wild Evaluation）成为焦点
• 2025-09：Humanity's Last Exam 发布，挑战能力极限
• 2025-12：评估自动化与持续监控成为标配

2026 年（当前）：标准化与合规期

• 评估指标标准化进程启动
• 企业级合规评估需求增长
• 实时评估 + 离线评估双轨制

五、关键行业洞察

1. 评估维度演进

准确性 → 可靠性 → 安全性 → 自主性 → 社会影响
(2023)    (2024)    (2024)    (2025)    (2026)

2. 主流评估方法

• 基于基准测试：AgentBench, WebArena, GAIA
• 基于 LLM 评判：LLM-as-a-Judge
• 基于人类反馈：RLHF 延伸
• 基于形式化验证：新兴方向

3. 技术趋势

1. 从静态到动态：离线评测 → 实时追踪
2. 从单点到系统：单任务评估 → 工作流评估
3. 从技术到商业：准确率 → ROI/业务指标
4. 从黑盒到可解释：结果评估 → 过程可审计

第三部分：方案对比

实现方案横向对比与选型建议

一、历史发展时间线

2023 年 ─┬─ Q2: LangChain Eval 模块 → LLM 应用评估萌芽
         ├─ Q3: AgentBench 发布 → 首个 Agent 专用基准
         ├─ Q4: WebArena/GAIA → 开放环境评估兴起
         └─ 当前状态：基准测试百花齐放

2024 年 ─┬─ Q1: RAGAS 专注 RAG 评估 → 垂直领域评估
         ├─ Q2: DeepEval/TruLens → 开发者工具化
         ├─ Q3: LangSmith 商业化 → 企业级评估平台
         └─ 当前状态：工具链日趋成熟

2025 年 ─┬─ Q1: AgentOps 统一可观测性 → 评估 + 监控融合
         ├─ Q2: 多 Agent 评估框架 → 协作能力评估
         ├─ Q3: 真实世界评估 (In-the-Wild) → 生产导向
         └─ 当前状态：生产级评估体系建立

2026 年 ─┴─ 当前：标准化进程启动，合规评估需求增长

二、7 种方案横向对比

方案 1：基于基准测试 (Benchmark-Based Evaluation)

原理：在标准化测试环境（如 AgentBench、WebArena）中运行 Agent，统计任务完成率和其他指标。

代表工具：AgentBench、WebArena、GAIA、SWE-bench、CLEVA

方案 2：LLM-as-a-Judge (基于大模型的评判)

原理：使用另一个（或同一个）LLM 作为评判者，根据 rubric 对 Agent 的输出或轨迹进行打分。

代表工具：LangChain LLMJudge、RAGAS Judge、自定义 Prompt

方案 3：基于人类反馈 (Human-in-the-Loop)

原理：由人类评估者对 Agent 表现进行主观评分或偏好排序，类似 RLHF 中的数据标注。

代表工具：Scale Spellbook、Label Studio、Amazon Mechanical Turk

方案 4：基于形式化验证 (Formal Verification)

原理：使用形式化方法（如模型检测、定理证明）验证 Agent 行为是否满足规范。

代表工具：Emergent Agents 的验证框架、学术界研究原型

方案 5：基于追踪的可观测性 (Tracing-Based Observability)

原理：记录 Agent 执行的完整轨迹（LLM 调用、工具使用、状态变化），通过可视化与分析发现问题。

代表工具：LangSmith、Arize Phoenix、AgentOps、TruLens、Promptflow

方案 6：单元测试式评估 (Unit Test-Style Evaluation)

原理：为 Agent 的关键功能编写确定性测试用例，类似传统软件的单元测试。

代表工具：DeepEval、LangChain Unit Tests、pytest + mock

方案 7：混合评估 (Hybrid Evaluation)

原理：组合以上多种方案，构建分层评估体系：单元测试 → 基准测试 → LLM 评判 → 人类评估。

代表工具：自定义集成（LangChain + LangSmith + Scale + 基准）

三、技术细节对比

四、选型建议

五、成本量级说明

六、实施路线图（推荐）

阶段 1：启动期（第 1-2 周）

• 目标：建立基础评估能力
• 方案：单元测试 + LLM 评判
• 工具：DeepEval 或 LangChain Eval
• 产出：核心功能测试覆盖率 > 80%

阶段 2：成长期（第 3-8 周）

• 目标：引入生产级监控
• 方案：追踪可观测性
• 工具：LangSmith 或 Arize Phoenix
• 产出：实时 Dashboard、告警系统

阶段 3：成熟期（第 2-3 月）

• 目标：建立基准对比能力
• 方案：基准测试（抽样）
• 工具：AgentBench 或 WebArena（子集）
• 产出：版本间对比报告、能力边界地图

阶段 4：规模化期（第 4 月+）

• 目标：构建混合评估体系
• 方案：分层评估（单元测试 → 基准 → LLM 评判 → 人类）
• 工具：集成多个平台
• 产出：自动化评估流水线、人类反馈闭环

七、避坑指南

常见陷阱

1. 只测准确率，忽略效率

   • 后果：Agent 能完成任务，但成本高到无法商用
   • 对策：将成本、延迟、步数纳入核心指标

2. 过度依赖 LLM-as-a-Judge

   • 后果：评判偏差累积，产品体验下降
   • 对策：定期与人类评估校准，保留人工抽检

3. 基准测试过拟合

   • 后果：基准分数高，生产表现差
   • 对策：多基准交叉验证，保留未公开测试集

4. 忽视安全评估

   • 后果：上线后出现 Reward Hacking、Prompt 注入
   • 对策：将安全测试纳入 CI/CD，建立红队机制

5. 评估与开发脱节

   • 后果：评估报告滞后，无法指导迭代
   • 对策：评估集成 CI/CD，每次提交自动评估

第四部分：精华整合

核心洞察与可传播总结

一、The One 公式

用一个悖论式等式概括 Agent Evaluation 的核心本质：

解读：

• Benchmark（基准测试）：定义 Agent 能力的上限，回答"它能做什么"
• Tracing（追踪可观测）：揭示 Agent 决策的过程，回答"它为什么这样做"
• 减去 Blind Trust：评估的本质是打破对 AI 的黑盒信任，建立可验证的信心

二、一句话解释（费曼技巧）

Agent Evaluation 就像给 AI 员工做绩效考核：不仅要看它完成任务的成功率（基准测试），还要检查工作日志了解它是怎么做的（追踪可观测），而不是盲目相信它说的每一句话（减去盲目信任）。

三、核心架构图

                    ┌─────────────────┐
                    │  Test Suite     │
                    │  (任务定义)      │
                    └────────┬────────┘
                             │
                             ▼
┌────────────────────────────────────────────────────────────┐
│                     Agent Under Test                        │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────┐ │
│  │   LLM    │───▶│  Planner │───▶│  Tools   │───▶│Memory│ │
│  └──────────┘    └──────────┘    └──────────┘    └──────┘ │
└────────────────────────────────────────────────────────────┘
         │                   │                   │
         ▼                   ▼                   ▼
  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
  │  Accuracy   │    │  Efficiency │    │   Safety    │
  │  (Pass@k)   │    │  (Steps/$)  │    │  (Rew.Hack) │
  └─────────────┘    └─────────────┘    └─────────────┘
         │                   │                   │
         └───────────────────┼───────────────────┘
                             ▼
                    ┌─────────────────┐
                    │  Overall Score  │
                    │  + 诊断报告     │
                    └─────────────────┘

四、STAR 总结

Situation（背景 + 痛点）

随着 LLM 驱动的 Agent 系统在客服、编程、数据分析等场景的广泛应用，如何科学评估 Agent 能力成为行业瓶颈。传统 LLM 评估（如 MMLU）仅测语言知识，无法衡量工具使用、多步规划、环境交互等 Agent 核心能力。企业面临"上线前不知道效果，上线后不知道问题在哪"的困境。

Task（核心问题）

Agent 评估需同时回答五个问题：

1. 能力边界：Agent 能完成哪些任务？成功率多少？
2. 效率：完成任务需要多少步、多少时间、多少成本？
3. 可靠性：面对边界情况和对抗输入是否稳定？
4. 安全性：是否存在 Reward Hacking、Prompt 注入等风险？
5. 可解释性：决策过程是否可追溯、可审计？

Action（主流方案）

技术演进经历三阶段：

1. 基准测试时代（2023）：AgentBench、WebArena 等提供标准化环境，量化任务完成率
2. 可观测性时代（2024-2025）：LangSmith、Phoenix 等实现生产环境实时追踪
3. 混合评估时代（2026）：单元测试 → 基准测试 → LLM 评判 → 人类评估的分层体系

核心突破：

• LLM-as-a-Judge：用 LLM 评估 LLM，解决人类标注成本问题
• Tracing：完整记录执行轨迹，支持根因分析
• 自动化评估流水线：集成 CI/CD，每次提交自动评估

Result（效果 + 建议）

当前成果：

• 头部企业已建立成熟评估体系，评估周期从周级缩短到小时级
• 开源工具链完善，个人开发者也能以<$50/月建立评估能力

现存局限：

• 多 Agent 协作评估仍处于早期
• 真实世界评估（In-the-Wild）方法论尚未标准化

实操建议：

• 小型项目：DeepEval + LangSmith 免费版（$0-25/月）
• 中型生产：追踪可观测 + 抽样基准测试（$200-500/月）
• 大型系统：混合评估 + 人类反馈（$2000+/月）

五、理解确认问题

问题

假设你正在评估一个客服 Agent，它在基准测试中任务完成率达到 85%，但上线后用户投诉率却很高。请用 Agent Evaluation 的框架分析可能的原因，并给出改进方案。

参考答案

可能原因：

1. 基准与生产场景脱节

   • 基准测试可能过于理想化，未覆盖真实用户的模糊表达、多轮对话、情绪化输入
   • 对策：从生产日志中抽取真实用例，构建"影子测试集"

2. 效率指标缺失

   • Agent 可能完成任务但耗时过长（如 10 轮对话才解决问题）
   • 对策：将"平均对话轮数"、"平均响应时间"纳入核心指标

3. 用户体验未评估

   • 基准测试只关注任务完成，忽略语气、同理心等主观质量
   • 对策：引入 LLM-as-a-Judge 评估"友好度"、"专业度"

4. 安全/合规问题

   • Agent 可能在边界情况下给出错误承诺或泄露敏感信息
   • 对策：建立红队测试，专门针对安全漏洞进行评估

5. 缺乏实时监控

   • 上线后无追踪，无法及时发现和修复问题
   • 对策：部署 LangSmith/Phoenix 等工具，建立告警系统

改进方案：

阶段 1（1-2 周）：引入生产日志构建真实测试集
阶段 2（2-4 周）：部署追踪工具，建立实时 Dashboard
阶段 3（1-2 月）：建立混合评估体系（自动 + 人工）
阶段 4（持续）：A/B 测试、版本对比、用户反馈闭环

六、关键数字记忆

七、行动清单

今天就能开始

• 为 Agent 核心功能编写 5 个单元测试
• 注册 LangSmith 或 Arize Phoenix 免费账号
• 从生产日志中抽取 10 个真实用例

本周完成

• 建立基础 Dashboard（任务完成率、延迟、成本）
• 配置 CI/CD 自动运行单元测试
• 定义评估指标字典（各指标计算公式、目标值）

本月完成

• 运行一次完整基准测试（AgentBench 子集）
• 建立人类评估流程（至少 100 样本）
• 完成首次版本对比评估

附录：文件导航

调研完成日期：2026-03-01 | 总字数：~12,000 字