Agent Plan × DeepSeek Harness — Agent评估基准与可观测平台

hh950

262人浏览 · 2026-09-06 00:06:57

hh950 · 2026-09-06 00:06:57 发布

#Agent Plan × DeepSeek Harness — Agent评估基准与可观测平台

1. 引言：Agent系统"能跑但不知道跑得好不好"的困境

当一个基于大语言模型的Agent系统从原型走向生产环境，工程团队会很快撞上同一堵墙：系统"能跑起来"，但没有人能说清楚它"跑得有多好"。

这个困境的根源在于Agent系统的输出具有高度非确定性。传统的软件系统有明确的输入输出契约——给定输入A，预期输出B，断言通过即视为正确。而Agent系统的行为链路是一个动态的推理-决策-执行循环，同一个任务在不同运行中可能选择完全不同的工具调用序列、产生不同的中间推理路径，甚至得出形式不同但语义等价的最终答案。这使得"正确性"本身从二元判定退化为一个多维度连续光谱。

更复杂的是，Agent系统通常由多个组件协同构成：规划模块负责任务分解与子目标编排，工具调用模块负责与外部环境交互，记忆模块负责上下文管理，反思模块负责自我纠偏。任何一个组件的退化都可能在链路中被放大或掩盖，导致问题定位极其困难。开发者在日常迭代中反复面对的核心问题不是"系不系统工作"，而是：

这次Prompt修改让规划质量变好了还是变差了？
工具调用失败率上升是模型能力问题还是接口稳定性问题？
任务完成率从78%提升到82%，是真实改进还是噪声波动？
平均延迟从4.2秒涨到5.8秒，瓶颈卡在哪个环节？

Agent Plan × DeepSeek Harness（以下简称APH框架）正是为回答这些问题而构建的技术体系。其中，Agent Plan是一套标准化的Agent能力评估方法论，定义了评估维度、基准任务集和量化指标体系；DeepSeek Harness则是运行时可观测与实验管理平台，提供Trace采集、指标聚合、A/B实验和可视化仪表盘能力，并以DeepSeek系列模型作为自动化评估和异常检测的推理引擎。

两者的核心理念是：将Agent系统从"感觉还行"推进到"数据驱动迭代"，让每一次Prompt修改、模型升级、工具链调整都有可量化的评估依据。

2. Agent评估的核心维度体系

建立评估体系的第一步不是设计指标，而是定义维度。维度是指标的上位概念——它回答"我们在评估什么"，而指标回答"我们如何测量"。APH框架定义了五个核心评估维度，构成一个相互正交但彼此关联的评估空间。

规划质量（Planning Quality）：衡量Agent将复杂任务分解为可执行子步骤的能力。关注点包括：分解粒度是否合理（既不过粗导致无法执行，也不过细导致冗余开销）、子步骤之间的依赖关系是否正确、是否有遗漏关键步骤、是否产生了不必要的冗余步骤。规划质量直接决定了后续执行的效率上限。

执行效率（Execution Efficiency）：衡量Agent在任务执行过程中的资源利用效率。核心指标包括完成单任务所需的工具调用轮次、Token消耗总量、端到端延迟。执行效率回答的问题是"在达到同等结果质量的前提下，系统消耗了多少资源"。

工具调用准确率（Tool Invocation Accuracy）：衡量Agent选择和调用外部工具的精确程度。具体考察三个层面：是否选对了工具（工具选择准确性）、传入参数是否正确（参数构造准确性）、对工具返回结果的理解和处理是否正确（结果解析准确性）。这是Agent与外部世界交互质量的直接度量。

任务完成率（Task Completion Rate）：衡量Agent端到端完成用户指定任务的比例。这里的关键挑战在于"完成"的定义——APH框架采用分级判定：完全完成（结果完全满足预期）、部分完成（核心目标达成但存在缺陷或遗漏）、未完成（核心目标未达成或中途失败）。分级判定避免了简单的二元分类丢失中间态信息。

成本效益（Cost Effectiveness）：将结果质量与资源消耗进行联合度量。一个完成率90%但消耗50000 Token的系统，与一个完成率85%但消耗8000 Token的系统，哪个更好？成本效益维度通过质量-成本比率为这类决策提供量化依据。

这五个维度并非独立运作，而是构成了一个评估矩阵。在实际产品迭代中，不同阶段对不同维度的优先级不同：早期关注完成率和规划质量，中期关注工具准确率和执行效率，成熟期关注成本效益。APH框架支持维度权重的动态配置，使评估策略能够随产品阶段演进。

在行业实践中，不同成熟度阶段的Agent系统在各维度上呈现典型的基准区间。根据APH框架对数十个生产级Agent系统的观测数据，早期阶段系统的完成率通常在50%-65%区间，工具选择准确率在80%-88%，参数构造准确率往往低于75%——后者是最常见的短板。进入中期优化阶段后，完成率提升至70%-80%，工具准确率突破90%，但Token效率比往往不降反升，因为优化过程中增加了更多的检查和重试逻辑。成熟期系统在完成率稳定在80%以上后，成本效益成为核心战场，Token效率比需要从3000+优化到2000以下才具备商业可行性。这些基准区间为新团队提供了"我现在处于什么阶段"的参照系。

3. 评估基准框架设计

APH评估基准框架由四个核心子系统构成，形成从任务输入到评估报告的完整流水线。

基准任务集是评估的输入源。它不是一组随意的测试用例，而是一个经过精心设计、具备分类体系和难度分级的结构化任务集合。任务分类器根据Agent的预期应用场景对任务进行领域归类（如信息检索、数据分析、代码生成、多轮对话等），难度分级器根据任务所需的推理深度、工具调用次数、上下文依赖复杂度进行1-5星分级。数据集仓库负责版本管理和任务去重，确保每次评估运行使用一致的任务集，使结果具有可比性。

评估引擎是执行核心。任务调度器负责将基准任务分发到Agent运行时沙箱中执行，沙箱提供隔离的执行环境——包括模拟的工具接口、受控的网络访问和确定性种子——确保评估的可复现性。事件采集器以结构化方式记录Agent执行过程中的每一个关键事件：规划决策、工具调用请求、工具返回结果、中间推理文本、最终输出。环境模拟器是沙箱的关键组件，它替代了真实的工具后端，提供确定性的响应，消除外部服务波动对评估结果的干扰。

指标计算层将原始事件流转化为可量化的评估指标。原始指标采集负责从事件流中提取原子级数据点（如单次工具调用的延迟、单轮推理的Token数），聚合计算引擎将这些原子数据点按维度和粒度进行统计聚合，DeepSeek Judge则作为LLM-as-Judge组件，对无法用规则判定的开放式输出进行语义级评估。

报告生成将计算结果组织成可操作的评估报告。除了静态指标汇总，报告还包含跨版本趋势分析，帮助团队识别指标变化的方向和幅度。

4. 评测基准任务集构建

基准任务集的质量直接决定了评估结果的有效性。一个设计不当的任务集——比如全是简单单轮任务，或任务之间存在高度同质化——会导致评估结果对真实场景缺乏预测力。APH框架采用"分类-分级-标注"三步法构建任务集。

任务分类体系参照真实Agent应用场景划分为六类：

任务类别	描述	典型示例	核心评估维度
单轮信息检索	一次工具调用即可完成的信息查询	“查询北京今天的天气”	工具准确率、延迟
多步推理检索	需要多轮检索和推理链才能完成	“对比三个竞品的市场份额并给出分析”	规划质量、完成率
代码生成与执行	生成代码并在沙箱中运行验证	“写一个Python函数计算移动平均”	完成率、执行效率
多工具编排	需要协调多个不同工具完成复合任务	“从数据库取数、用统计工具分析、生成报告”	规划质量、工具准确率
纠错与恢复	在执行过程中遇到错误需要自我修正	工具返回异常时Agent的降级处理能力	规划质量、完成率
长上下文推理	需要在大量上下文中维持推理一致性	基于长文档的问答与总结	执行效率、完成率

难度分级采用多维评估矩阵，而非简单的单轴分级。每个任务从三个独立维度评估难度：推理深度（1-5星，衡量所需的推理链长度）、工具复杂度（1-5星，衡量所需工具调用的数量和参数复杂度）、上下文依赖度（1-5星，衡量任务对历史上下文的依赖程度）。一个标记为 [推理:3, 工具:4, 上下文:2] 的任务意味着它需要中等深度的推理、较高的工具编排复杂度，但对上下文记忆的依赖较低。这种多维标注使团队能够精确识别Agent能力短板——比如"推理深度4星以上任务完成率骤降"这一发现，比笼统的"困难任务完成率低"具有更强的行动指导性。

数据集标注为每个任务定义预期行为基准。对于有确定性答案的任务（如信息检索），标注标准答案；对于开放式任务（如报告生成），标注评估要点列表（rubric），供LLM-as-Judge逐点核对。标注还包含时间预算（预期完成该任务所需的合理时间上限）和成本预算（预期Token消耗上限），用于成本效益维度的评估。

任务集的维护采用版本化管理策略。每个版本的任务集附带元数据（创建日期、任务数量、类别分布、难度分布），评估报告必须引用任务集版本号以确保可复现性。当任务集更新时——新增任务、修改标注、调整难度——主版本号递增，历史评估结果不会失效，但跨版本比较时需注明版本差异。

5. 关键指标定义与计算方法

指标定义是评估体系的基石。模糊的指标定义会导致不同评估者对同一结果产生不同解读，使评估结果丧失可比性。APH框架对每个关键指标给出精确的数学定义、计算公式和目标基准值。

指标名称	定义	计算公式	目标值
规划合理度	规划步骤中合理步骤占总步骤的比例	$NvalidNtotal×100%\frac{N_{valid}}{N_{total}} \times 100\%$	≥ 85%
工具选择准确率	选择正确工具的调用次数占比	$Ncorrect_toolNtotal_calls×100%\frac{N_{correct\_tool}}{N_{total\_calls}} \times 100\%$	≥ 92%
参数构造准确率	工具参数完全正确的调用次数占比	$Ncorrect_paramNtotal_calls×100%\frac{N_{correct\_param}}{N_{total\_calls}} \times 100\%$	≥ 88%
任务完成率（完全）	完全达成任务目标的运行占比	$Nfull_completeNtotal_tasks×100%\frac{N_{full\_complete}}{N_{total\_tasks}} \times 100\%$	≥ 75%
任务完成率（含部分）	完全或部分达成目标的运行占比	$Nfull+NpartialNtotal×100%\frac{N_{full} + N_{partial}}{N_{total}} \times 100\%$	≥ 90%
平均端到端延迟	从任务输入到最终输出的平均耗时	$1N∑i=1Nte2e(i)\frac{1}{N}\sum_{i=1}^{N} t_{e2e}^{(i)}$	≤ 8s
P95延迟	95%分位的端到端延迟	$P_{95}(\{t_{e2e}^{(i)}\})$	≤ 15s
Token效率比	每完成一个有效子目标的平均Token消耗	$Ntotal_tokensNachieved_goals\frac{N_{total\_tokens}}{N_{achieved\_goals}}$	≤ 2000
成本-质量指数	完成率与归一化成本的比值	$CRCostCostbaseline\frac{CR}{\frac{Cost}{Cost_{baseline}}}$	≥ 1.2

其中几个关键指标的计算需要进一步说明。

规划合理度的判定采用人工标注与LLM-as-Judge混合策略。对于基准任务集，每个任务的预期规划步骤已预标注，评估时将Agent实际规划与预期规划进行对齐比对。对齐采用基于步骤语义相似度的动态规划算法，而非简单的字符串匹配：

def compute_planning_score(actual_steps, expected_steps, embedder):
    """
    计算规划合理度得分。
    actual_steps: Agent实际生成的规划步骤列表
    expected_steps: 预期规划步骤列表
    embedder: 语义嵌入模型，用于步骤语义对齐
    """
    # 将步骤向量化
    actual_emb = embedder.encode(actual_steps)
    expected_emb = embedder.encode(expected_steps)
    
    # 构建相似度矩阵
    sim_matrix = cosine_similarity(actual_emb, expected_emb)
    
    # 使用动态规划求最优对齐
    aligned_pairs, unmatched_actual, unmatched_expected = \
        optimal_alignment(sim_matrix, threshold=0.75)
    
    valid_count = len(aligned_pairs)
    # 未匹配的预期步骤视为遗漏，未匹配的实际步骤视为冗余
    redundancy_penalty = len(unmatched_actual) * 0.5
    missing_penalty = len(unmatched_expected) * 0.8
    
    score = (valid_count - redundancy_penalty - missing_penalty) / \
            max(len(expected_steps), len(actual_steps))
    return max(0.0, min(1.0, score))

上述对齐算法的核心是一个基于动态规划的最优匹配过程。设实际步骤序列长度为 $m$ ，预期步骤序列长度为 $n$ ，相似度矩阵 $\in \mathbb{R}^{m \times n}$ ，其中 $S_{i,j}$ 表示实际步骤 $i$ 与预期步骤 $j$ 的余弦相似度。对齐问题的目标是找到一个匹配 $\subseteq \{1,...,m\} \times \{1,...,n\}$ ，使得匹配对的总相似度最大化，同时满足每个步骤至多被匹配一次的约束。这等价于二部图最大权匹配问题，APH框架采用匈牙利算法在 $O(\max(m,n)^3)$ 时间内求解。相似度阈值 $θ=0.75\theta=0.75$ 的选取基于校准实验：在人工标注的500对步骤上，0.75的阈值在精确率和召回率之间取得了最佳F1值（0.82），低于此阈值会产生大量语义无关的误匹配，高于此阈值则遗漏过多语义等价但表述不同的步骤对。

任务完成率的分级判定是评估中最具挑战性的环节。对于有确定性答案的任务，完成率判定可以通过结果匹配实现。但对于开放式任务，需要LLM-as-Judge基于预标注的评估要点列表进行多维度评分。APH框架使用DeepSeek作为Judge模型，对每个要点进行"满足/部分满足/不满足"的三级判定，然后聚合为整体完成等级：

def judge_task_completion(agent_output, rubric_points, judge_model):
    """
    使用LLM-as-Judge判定任务完成等级。
    rubric_points: 预标注的评估要点列表
    """
    scores = []
    for point in rubric_points:
        prompt = construct_judge_prompt(agent_output, point)
        result = judge_model.evaluate(prompt)
        # result: {"score": 0|1|2, "reasoning": "..."}
        scores.append(result["score"])
    
    total = sum(scores)
    max_possible = len(rubric_points) * 2
    
    if total >= max_possible * 0.9:
        return "full_complete"
    elif total >= max_possible * 0.5:
        return "partial_complete"
    else:
        return "incomplete"

这个判定逻辑的关键设计在于：Judge模型的推理过程被完整记录，而非仅取最终判定结果。这使得当评估结果存在争议时，团队可以回溯Judge的推理链路，审查判定是否合理，必要时修正rubric标注。

Judge模型的校准采用Cohen’s Kappa系数衡量与人工标注的一致性。APH框架维护一个包含150个任务的校准集，其中每个任务的完成等级均由3位标注者独立判定后取多数投票确定。每当Judge模型的提示词或底层模型版本更新时，必须在校准集上重新运行，要求Kappa值不低于0.70方可上线。此外，APH框架还跟踪校准集上的逐要点一致率——即每个rubric要点上Judge判定与人工判定的一致比例，当某个要点的一致率持续低于60%时，触发该要点的标注审查，通常意味着rubric描述本身存在歧义，需要重新定义。

6. 运行时Trace与日志溯源

评估基准回答了"Agent跑得有多好"的问题，但无法回答"为什么跑成这样"。当任务完成率突然下降，或者某个特定类型的任务表现异常时，团队需要深入到单次执行的内部链路，定位问题根因。这就是运行时Trace与日志溯源的职责。

APH框架的Trace系统采用Span树模型组织执行轨迹。每一次Agent运行被建模为一棵Span树，根Span代表整个任务执行，子Span代表各个执行阶段——规划、工具调用、推理、反思等。每个Span携带标准化的元数据：开始时间、结束时间、持续时间、输入参数、输出结果、Token消耗、状态码。这种树形结构完整保留了执行的时序和因果关系。

采集层通过两种机制获取Trace数据。自动埋点在Agent框架的关键执行路径上插入Span创建和关闭逻辑，开发者无需手动编写Trace代码。拦截器机制则通过装饰器模式包装工具调用和LLM调用，自动捕获输入输出和性能数据。这种非侵入式设计确保Trace系统可以平滑接入现有Agent代码库：

import functools
import time
from trace_sdk import Span, tracer

def trace_tool_call(tool_name):
    """工具调用拦截器装饰器，自动采集Trace数据"""
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            with tracer.start_span(
                name=f"tool.{tool_name}",
                kind="tool_call",
                attributes={"tool.name": tool_name}
            ) as span:
                start = time.perf_counter()
                try:
                    result = func(*args, **kwargs)
                    span.set_attribute("tool.status", "success")
                    span.set_attribute("tool.result_size", len(str(result)))
                    return result
                except Exception as e:
                    span.set_attribute("tool.status", "error")
                    span.set_attribute("tool.error", str(e))
                    span.record_exception(e)
                    raise
                finally:
                    elapsed = time.perf_counter() - start
                    span.set_attribute("tool.duration_ms", elapsed * 1000)
        return wrapper
    return decorator

传输层采用异步队列解耦Trace采集和存储，避免Trace系统本身成为Agent执行的性能瓶颈。批量缓冲机制将高频Span数据聚合后批量写入存储，在吞吐量和延迟之间取得平衡。

存储层采用冷热分离策略。热存储（基于Redis）保存最近24小时的Trace数据，支持低延迟的实时查询和告警判定。冷存储（基于ClickHouse）保存全量历史Trace，支持复杂的聚合分析和趋势查询。索引服务对Trace的标签和属性建立倒排索引，支持按任务类型、工具名称、错误状态等维度快速检索。

在高流量生产环境中，全量Trace采集会带来不可忽视的存储和计算开销。APH框架支持三种采样策略以适应不同场景：头部采样（Head-based Sampling）在Span创建时即决定是否采集，基于固定采样率（如10%），优点是开销极低、实现简单，缺点是无法保证异常Trace的采集——失败的执行可能恰好未被采样。尾部采样（Tail-based Sampling）在Span树完成后根据执行结果决定是否保留，APH框架默认保留所有错误Trace、延迟超过P95的慢Trace以及随机采样的正常Trace，这种策略确保诊断价值高的Trace优先保留，但需要在内存中缓存完整Span树直到执行结束，对长耗时任务有内存压力。概率采样与强制保留混合策略对正常执行按1%-5%概率采样，对异常执行（错误状态、延迟超阈值、Token消耗超预算）强制保留，这是APH框架推荐的生产默认策略：

class TraceSampler:
    """Trace采样器：概率采样 + 异常强制保留"""
    def __init__(self, normal_rate=0.02, error_force_keep=True,
                 latency_threshold_ms=15000):
        self.normal_rate = normal_rate
        self.error_force_keep = error_force_keep
        self.latency_threshold = latency_threshold_ms

    def should_sample(self, span_tree):
        """在Span树完成后决定是否保留"""
        root = span_tree.root
        # 异常执行强制保留
        if self.error_force_keep and root.status == "error":
            return True
        # 慢Trace强制保留
        if root.duration_ms > self.latency_threshold:
            return True
        # 正常执行概率采样
        return random.random() < self.normal_rate

采样策略的选择本质上是在诊断覆盖率和系统开销之间做权衡。APH框架建议：评估基准运行时使用100%全量采集（任务集规模可控），生产环境使用混合采样策略，将异常Trace的保留率维持在接近100%，正常Trace的采样率根据存储容量动态调整。

分析层在存储之上提供实时计算能力。实时聚合器持续计算各维度的运行时指标（如过去5分钟的工具调用成功率）。延迟分析器对Span树进行时间线分解，计算各阶段的耗时占比。异常检测器基于统计模型（如移动平均+标准差阈值）检测指标的突增突降，当检测到异常时触发DeepSeek异常归因模块，由LLM分析相关Trace日志，生成可能的根因假设。

可视化层提供多种分析视图。Trace瀑布图以时间线方式展示单次执行的完整Span树，帮助开发者直观定位耗时瓶颈。调用拓扑图展示工具调用的关系网络，识别高频调用路径和异常调用模式。日志检索支持全文搜索和结构化过滤，使开发者能快速找到特定条件的执行记录。

7. 成本与延迟分析

在生产环境中，成本和延迟往往是比功能正确性更关键的运营约束。一个完成率95%但每次任务消耗50000 Token、耗时30秒的Agent系统，在大多数商业场景中不可接受。APH框架将成本和延迟分析提升到与功能评估同等重要的地位。

Token消耗统计是成本分析的基础。APH框架将Token消耗分解为四个组成部分：规划Token（用于任务分解和策略选择的推理消耗）、工具调用Token（构造工具调用请求和解析返回结果的消耗）、反思Token（自我评估和纠偏的消耗）、上下文维护Token（维护对话历史和记忆的消耗）。这种分解使团队能够精确识别Token消耗的主要来源：

class TokenBreakdown:
    """Token消耗四维分解"""
    def __init__(self):
        self.planning = 0       # 规划Token
        self.tool_usage = 0     # 工具调用Token
        self.reflection = 0     # 反思Token
        self.context_mgmt = 0   # 上下文维护Token

    @property
    def total(self):
        return (self.planning + self.tool_usage + 
                self.reflection + self.context_mgmt)

    def cost_estimate(self, input_rate, output_rate):
        """估算美元成本，区分输入/输出Token费率"""
        input_tokens = self._classify_io(mode="input")
        output_tokens = self._classify_io(mode="output")
        return (input_tokens * input_rate + 
                output_tokens * output_rate) / 1_000_000

    def efficiency_score(self, achieved_goals):
        """计算每达成一个子目标的Token效率"""
        if achieved_goals == 0:
            return float('inf')
        return self.total / achieved_goals

延迟分解将端到端延迟拆解为可归因的组成部分。在Agent系统中，端到端延迟不是单一因素决定的，而是由多个串行和并行阶段叠加而成。APH框架定义了标准化的延迟分解模型：

T_plan：规划阶段延迟，包括LLM推理生成规划方案的时间
T_tool：工具调用延迟，包括网络往返和工具执行时间
T_llm：LLM推理延迟，包括每次模型调用的等待时间
T_serial：串行等待延迟，由于步骤间依赖导致的无法并行化的等待时间
T_overhead：框架开销，包括Trace采集、状态管理等系统级耗时

总延迟 $Te2e=Tplan+∑(Ttool+Tllm)+Tserial+ToverheadT_{e2e} = T_{plan} + \sum(T_{tool} + T_{llm}) + T_{serial} + T_{overhead}$

瓶颈定位通过延迟分解数据自动识别性能瓶颈。APH框架实现了基于贡献度的瓶颈检测算法：当某个延迟组成部分贡献了超过总延迟40%的份额，或其P95延迟超过历史基线的2倍标准差时，系统自动标记为瓶颈并生成诊断报告。常见的瓶颈模式包括：上下文过长导致LLM推理延迟激增（通常指向记忆管理策略问题）、工具调用重试导致的串行延迟累积（通常指向工具稳定性问题）、规划粒度过细导致LLM调用次数过多（通常指向Prompt设计问题）。

延迟分析的一个关键洞察是：优化方向取决于瓶颈类型而非绝对延迟值。一个主要由T_tool贡献的延迟瓶颈，优化方向是提升工具响应速度或增加并行调用；而一个主要由T_llm贡献的延迟瓶颈，优化方向是压缩上下文长度或切换更快的模型变体。没有延迟分解，团队可能花费大量精力优化错误的方向。

从行业实践来看，不同复杂度的Agent任务在成本和延迟上呈现显著差异。根据APH框架的观测数据，单轮信息检索类任务的典型Token消耗在800-2000区间，P95延迟在3-6秒；多步推理检索类任务Token消耗在3000-8000区间，P95延迟在8-15秒；多工具编排类任务Token消耗可达8000-20000，P95延迟在15-30秒。这些基准区间为团队设定成本预算和延迟SLA提供了参考。值得注意的是，Token消耗与任务复杂度并非线性关系——当任务复杂度增加时，上下文累积和重试行为会导致Token消耗呈超线性增长，这也是为什么Token效率比在复杂任务上往往显著恶化的原因。

8. A/B实验框架设计

Agent系统的迭代天然适合A/B实验范式：修改Prompt、调整模型参数、更换工具实现——每一次变更都可以设计为一次受控实验。但Agent系统的A/B实验比传统Web服务的A/B测试复杂得多，因为输出不是简单的点击/转化事件，而是多维度的质量指标，且指标本身具有高方差特性。

APH框架的A/B实验设计围绕四个核心问题展开。

实验分组采用分层随机化策略。由于Agent表现受任务类型影响显著，简单的随机分组可能在某些任务类型上产生组间不均衡。APH框架先按任务类别和难度等级对基准任务集进行分层，然后在每层内随机分配到对照组和实验组，确保两组在任务构成上统计一致：

import random
from collections import defaultdict

def stratified_assignment(tasks, seed=42):
    """
    分层随机分组：按任务类别和难度分层后随机分配A/B组。
    确保两组在任务构成上统计一致。
    """
    random.seed(seed)
    strata = defaultdict(list)
    for task in tasks:
        # 分层键: (任务类别, 难度等级)
        key = (task.category, task.difficulty)
        strata[key].append(task)
    
    group_a, group_b = [], []
    for key, stratum_tasks in strata.items():
        random.shuffle(stratum_tasks)
        midpoint = len(stratum_tasks) // 2
        group_a.extend(stratum_tasks[:midpoint])
        group_b.extend(stratum_tasks[midpoint:])
    
    return group_a, group_b

流量分配在在线场景中控制实验组和对照组的任务比例。对于离线基准评估，流量分配退化为任务集分配；对于在线生产环境，APH框架支持基于用户ID哈希的确定性分桶，确保同一用户的请求始终路由到同一实验组，避免交叉污染。流量比例支持动态调整——实验初期使用5%流量验证无严重退化后，逐步放量到50%。

统计显著性检验是A/B实验结论有效性的保障。Agent质量指标的高方差特性使得简单的均值比较容易产生假阳性。APH框架采用以下统计方法：

对于比率型指标（如完成率、工具准确率），使用双比例Z检验。对于连续型指标（如延迟、Token消耗），先通过Shapiro-Wilk检验判断正态性，满足正态假设时使用Welch t检验（不假设等方差），不满足时使用Mann-Whitney U检验。所有检验统一要求显著性水平 $α=0.05\alpha = 0.05$ ，并报告效应量（Cohen’s d或相对提升百分比）和95%置信区间，避免仅凭p值做出决策。

最小样本量的计算基于统计功效分析。对于双比例Z检验（如完成率对比），假设对照组完成率为 $p_0$ 、预期提升为 $δ\delta$ 、显著性水平 $α=0.05\alpha=0.05$ 、统计功效 $1−β=0.81-\beta=0.8$ ，每组所需样本量为：

$\frac{(z_{\alpha/2}\sqrt{2\bar{p}(1-\bar{p})} + z_{\beta}\sqrt{p_0(1-p_0)+(p_0+\delta)(1-p_0-\delta)})^2}{\delta^2}$

其中 $pˉ=p0+δ/2\bar{p} = p_0 + \delta/2$ 。以完成率从61%提升到68%（ $δ=0.07\delta=0.07$ ）为例，计算得每组需要约280个任务。APH框架在实验设计阶段自动执行此计算，当基准任务集规模不足时提示团队扩充任务集或降低预期效应量。对于连续型指标，样本量计算基于效应量Cohen’s $d$ ： $(\mu_1 - \mu_0) / \sigma$ ，当 $d = 0.5$ （中等效应）时每组约需64个样本， $d = 0.2$ （小效应）时每组约需400个样本。

多重比较校正在同时评估多个指标时尤为重要。当一个实验同时考察完成率、延迟、Token消耗等多个指标时，每个指标独立进行假设检验会增加整体假阳性率。APH框架默认采用Benjamini-Hochberg方法控制错误发现率（FDR），在保持检验灵敏度的同时控制多重比较带来的统计风险。

一个常见的陷阱是过早停止实验。Agent指标的方差较大，实验初期可能出现实验组明显领先或落后的假象。APH框架基于序贯检验理论计算最小样本量，在达到最小样本量之前不输出显著性结论，避免"偷看-停止"带来的偏差。

9. 可观测仪表盘设计

仪表盘是APH框架面向工程团队和产品决策者的统一交互界面。它的设计原则是：让不同角色在同一个视图中各取所需——工程师关注技术细节指标，产品经理关注用户体验指标，管理层关注成本和趋势。

概览面板提供系统健康度的一览视图。核心元素包括：当日任务完成率（含趋势箭头）、P95延迟、日Token消耗总量和成本、活跃A/B实验数量、异常告警数量。概览面板的设计目标是3秒内回答"系统今天整体状态如何"。

质量看板聚焦Agent能力指标。以任务完成率的多维分解为核心——按任务类别、难度等级、时间维度展开，支持从宏观趋势下钻到具体任务类别。当某个类别的完成率出现异常波动时，面板自动标注异常点并链接到相关Trace，支持一键深潜定位。

性能看板展示延迟和吞吐指标。除了标准的延迟分位数图（P50/P90/P95/P99），性能看板还提供延迟分解瀑布图，将端到端延迟拆解为各组成部分，直观显示哪个阶段贡献了最多延迟。吞吐量视图展示每分钟处理的任务数和并发度，帮助运维团队进行容量规划。

成本看板追踪Token消耗和API调用成本。按四个Token分解维度（规划、工具、反思、上下文）展示消耗分布，支持按时间维度查看成本趋势。成本看板的关键特性是"成本异常预警"——当某类任务的单位成本超过历史基线时自动标注，提示团队审查是否有退化行为导致Token浪费。

实验看板是A/B实验的管控中心。展示每个活跃实验的状态（运行中/已结束/已暂停）、流量分配比例、各组关键指标的实时对比、统计显著性检验结果。实验结束后自动生成实验报告，包含效应量、置信区间和决策建议。

仪表盘的交互设计遵循"渐进式信息揭示"原则：概览层只展示聚合指标和异常标记，用户通过下钻操作逐步展开细节——从"今日完成率下降"到"哪类任务下降"到"具体哪几个任务失败"到"失败的Trace详情"。这种设计避免了信息过载，同时保留了完整的深潜路径。

10. DeepSeek在评估中的角色

DeepSeek在APH框架中不仅是被评估的Agent推理引擎，还承担了三个关键的"元评估"角色，这些角色利用DeepSeek的推理能力来增强评估体系本身的自动化程度和判断质量。

角色一：LLM-as-Judge。对于开放式任务输出，传统评估依赖人工标注，成本高且难以规模化。DeepSeek作为Judge模型，基于预标注的评估要点列表（rubric）对Agent输出进行多维度评分。APH框架针对Judge场景对DeepSeek进行了特定优化：

结构化输出约束：通过系统提示词约束Judge模型输出JSON格式的评估结果，包含每个rubric要点的评分、评分理由和整体判定，确保结果可程序化处理。
校准机制：使用一组人工标注的校准样本定期验证Judge模型的判定一致性。当Judge模型在校准样本上的判定与人工标注的一致率低于阈值时，触发校准告警。
位置偏差消除：对于对比型评估（如A/B实验中的两两比较），随机化输出顺序并取多次评估的多数投票，消除LLM Judge已知的位置偏好偏差。
冗长偏差（Verbosity Bias）：LLM Judge倾向于给更长的输出更高评分，即使内容质量相当。APH框架通过在rubric中显式加入"简洁性"评估维度来部分对冲此偏差，同时在Judge提示词中强调"评分基于内容质量而非长度"。
自我偏好偏差（Self-preference Bias）：当Judge模型与被评估Agent基于同一模型族时，Judge可能对风格相似的输出给出更高评分。APH框架通过交叉模型验证检测此偏差——使用GPT-4o和Claude作为交叉Judge，当不同Judge的评分排序出现显著不一致时（Spearman相关系数低于0.7），标记该批次评估存在模型偏好风险。
格式偏差（Format Bias）：结构化输出（如带标题、列表的格式）可能获得不公平的高分。APH框架在评估前对Agent输出进行格式归一化，去除纯格式差异对评分的影响。

校准流程的工程实现上，APH框架维护一个持续增长的"黄金标注集"——每次人工审查Judge判定时，将争议案例经多标注者复核后加入黄金集。黄金集的规模目标为500+案例，覆盖所有任务类别和难度等级，作为Judge模型版本升级时的回归测试基准。

角色二：自动评估流水线。DeepSeek负责将非结构化的Agent行为日志转化为结构化的评估数据。例如，Agent的规划输出是自然语言文本，需要DeepSeek将其解析为结构化的步骤列表，才能与预期规划进行对齐比对。同样，Agent的反思日志、错误信息等非结构化内容也需要通过DeepSeek的语义理解能力进行分类和标注。

角色三：异常检测与归因。当运行时监控检测到指标异常（如完成率突降、延迟激增）时，DeepSeek负责分析相关Trace日志，生成根因假设。这个过程不是简单的日志搜索，而是基于因果推理的分析：

async def anomaly_attribution(anomaly_event, trace_store, deepseek_client):
    """
    异常归因：使用DeepSeek分析异常Trace，生成根因假设。
    """
    # 1. 检索与异常相关的Trace样本
    related_traces = trace_store.query(
        time_range=anomaly_event.time_window,
        task_category=anomaly_event.affected_category,
        status="error"
    )
    
    # 2. 提取关键特征
    trace_summaries = [summarize_trace(t) for t in related_traces[:20]]
    
    # 3. 构造归因分析Prompt
    prompt = f"""
    以下Agent执行Trace出现了异常模式：
    异常类型: {anomaly_event.metric}
    异常幅度: {anomaly_event.deviation}
    相关Trace摘要: {trace_summaries}
    
    请分析可能的根因，按可能性排序输出假设列表，
    每个假设包含: 根因描述、支撑证据、建议验证方法。
    """
    
    # 4. DeepSeek生成归因假设
    hypotheses = await deepseek_client.analyze(prompt)
    
    return hypotheses

这种基于LLM的异常归因不是替代传统的基于规则的告警系统，而是作为其补充——规则系统负责快速检测已知模式的异常，DeepSeek负责对未知模式的异常进行深度分析和假设生成。

11. 实战案例：Agent产品迭代优化闭环

为了说明APH框架在实际产品迭代中的应用，以下是一个基于真实场景改编的案例。

背景：一个企业知识库问答Agent，基于DeepSeek模型构建，支持用户通过自然语言查询企业内部文档。上线后的初步数据显示用户满意度为72%，但团队无法确定瓶颈在哪里。

第一步：基线评估。团队使用APH基准任务集（知识库问答类，共200个任务，覆盖5个难度等级）对生产版本进行基线评估。评估结果暴露了明确的问题：

指标	基线值	目标值	差距
任务完成率（完全）	61%	75%	-14pp
工具选择准确率	89%	92%	-3pp
参数构造准确率	74%	88%	-14pp
P95延迟	22s	15s	+7s
Token效率比	3200	2000	+1200

参数构造准确率和Token效率比是两个最显著的短板。

第二步：Trace溯源定位。通过Trace瀑布图分析，团队发现参数构造准确率低的主要原因是：当用户查询包含多个实体时（如"对比A项目和B项目在Q3的预算执行情况"），Agent在构造检索工具参数时经常遗漏其中一个实体或时间范围。Token效率比高的原因是Agent在检索结果不理想时反复重试，每次重试都携带完整上下文，导致Token消耗快速累积。

第三步：A/B实验验证优化。团队设计了两个优化方案并通过A/B实验验证：

方案A（实验组1）：修改规划Prompt，增加"参数完整性检查"步骤，要求Agent在调用检索工具前显式列出查询涉及的所有实体和时间范围。
方案B（实验组2）：修改记忆管理策略，当检索重试超过2次时触发上下文压缩，移除不相关的历史轮次。

实验使用分层随机分组，每组100个任务。实验结果：

指标	对照组	方案A	方案B
参数构造准确率	74%	89% (+15pp)	75% (+1pp)
Token效率比	3200	3100 (-3%)	2100 (-34%)
P95延迟	22s	24s (+9%)	16s (-27%)
任务完成率	61%	68% (+7pp)	64% (+3pp)

统计检验显示方案A的参数准确率提升显著（p<0.01），但延迟有所增加；方案B的Token效率改善显著（p<0.01），且延迟大幅降低。两个方案分别解决了不同的问题维度。

对实验结果的深入分析揭示了更多工程洞察。方案A的参数准确率提升（+15pp）效应量Cohen’s $h = 0.32$ ，属于中小效应，但在200个任务的样本量下统计功效达到0.89，结论可靠。方案A的延迟增加（+9%）主要来自新增的"参数完整性检查"步骤引入的额外LLM调用，每任务平均增加1.2秒——这个代价在可接受范围内，因为参数准确率提升带来的完成率增益（+7pp）显著降低了用户重试率，从系统层面反而降低了总成本。

方案B的Token效率改善（-34%）效应量更大（Cohen’s $d = 0.71$ ，大效应），但完成率提升较小（+3pp）。深入分析Trace发现，上下文压缩策略在23%的任务中过度裁剪了相关信息，导致部分任务的完成质量下降——这解释了为什么Token效率大幅改善但完成率提升有限。团队据此对压缩策略进行了微调，将裁剪阈值从2次重试提高到3次，并增加"压缩后上下文完整性验证"步骤，在后续回归中这部分任务的完成质量恢复到了基线水平。

这个细节说明了一个重要的实践原则：单一指标的显著改善不一定意味着整体系统的改善，必须通过多维交叉验证才能确认优化的净效果。APH框架的多维度评估矩阵正是为此设计——任何优化方案的验收必须同时通过完成率、准确率、延迟和成本四个维度的检验，任何一个维度的退化超过阈值都会阻断合并。

第四步：组合优化与回归验证。团队将方案A和方案B的优化合并，在全量基准任务集上回归验证。组合后的结果：参数构造准确率提升至88%，Token效率比降至2300，P95延迟降至17s，任务完成率提升至73%。所有指标均通过统计显著性检验。

这个案例展示了APH框架的核心价值：将"感觉有问题"转化为"数据定位问题"，将"我觉得这样改更好"转化为"实验证明这样改更好"。整个迭代过程中，每一次决策都有数据支撑，每一次变更都有对照基准，避免了凭直觉优化带来的试错成本。

12. 挑战与未来方向

尽管APH框架为Agent评估提供了系统化的方法论和工程工具，但在实践中仍面临若干尚未完全解决的挑战。

评估的效度问题。基准任务集无论设计多么精心，都无法完全覆盖真实用户场景的多样性和长尾性。一个在基准任务集上表现优异的Agent，面对真实用户意想不到的输入模式时可能表现退化。这个问题没有银弹解法，APH框架通过定期从生产Trace中采样真实用户案例补充基准任务集来部分缓解，但基准与真实之间的鸿沟始终存在。

LLM-as-Judge的可靠性边界。使用DeepSeek作为Judge模型引入了"评估者偏差"问题——Judge模型自身的偏好和局限性会影响评估结果的客观性。特别是当被评估的Agent也基于DeepSeek时，Judge可能对与自身风格一致的输出给出更高评分。APH框架通过引入交叉模型评估（使用不同模型族作为Judge进行交叉验证）来检测这种偏差，但这增加了评估成本和复杂度。

多轮交互评估的复杂性。当前框架主要针对单任务、单轮或有限多轮的场景设计。对于需要长时间多轮交互的Agent应用（如持续对话的助理型Agent），如何定义和测量"交互质量"是一个开放问题。对话流畅度、上下文连贯性、个性化适应能力等维度难以用当前的指标体系充分覆盖。

未来方向上，APH框架的演进将聚焦三个方向。第一是自适应评估——根据Agent的应用场景自动生成和调整基准任务集，而非依赖静态预定义任务集，使评估更贴近真实场景。第二是实时评估闭环——将评估从离线批处理模式演进为在线实时模式，在生产流量上持续评估Agent表现，实现"部署即评估"的持续监控能力。第三是因果评估——从当前的关联性指标分析（指标A与指标B相关）走向因果性分析（修改A会导致B变化），通过因果推断方法帮助团队更精确地理解Agent行为的影响因素，而非仅仅观察相关性。

Agent系统的评估不是一个一次性的工程项目，而是一个持续演进的工程实践。随着Agent能力的增强和应用场景的扩展，评估体系本身也需要不断进化。Agent Plan × DeepSeek Harness的目标不是提供一个终极答案，而是建立一套可持续运行的评估基础设施，让团队在Agent能力快速迭代的过程中始终握有可靠的数据罗盘。