Personal Agent评测指南：任务下限比能力上限更重要

一、评测概述：为什么这类系统难评

Personal Agent（个人助理型智能体）指的是面向个人生活与服务场景的智能体系统：用户用一句自然语言提出带有真实后果的请求——订一张票、记一段病史、续一份订阅、办一次报销——系统需要自主完成意图理解、信息检索、路径规划、工具调用与结果确认。

过去一年，智能体（Agent）方向进展最扎实的领域是写代码。原因并不在于代码任务本身更”高级”，而在于代码自带判卷标准：测试过没过、编译成不成，环境会直接给出反馈。这种稳定的反馈信号使强化学习可以持续把能力往上训。

生活服务类场景没有这样的标准。订错一张票、记混一条病史、把两个用户的偏好张冠李戴，系统不会报错，接口也可能返回”成功”，用户不会投诉，只会悄悄流失。这也是过去一年若干通用智能体产品先爆火、随后热度冷却的主要症结：问题大多出在任务完成率上，而不是单点演示效果上。用户会因为一次惊艳的演示下载产品，留下来却要依靠十次稳定的交付。

因此，评测对象不是”模型聪不聪明”，而是一个 Personal Agent 系统在真实需求分布下能否稳定把事办成。它至少包含三层：

层级	内容	评测关注点
模型层	意图理解、规划、单步决策	需求对齐、路径合理性、回溯能力
工程外壳层	上下文组织、个人记忆、技能模块、工具编排、推理链路	信息完整度、调用成功率、升级后的资产沉淀
生态层	可调用的真实服务与接口	覆盖度、授权、执行稳定性

适合读者：AI 应用开发者、Agent 平台架构师、算法工程师、测试与质量负责人、技术管理者与企业技术选型团队。

二、评测目标：先确定要回答的问题

评测的第一原则是避免”指标堆一堆、结论用不上”。对 Personal Agent，建议先锁定四个核心问题：

1. 能力覆盖是否完整：典型任务链路上需要的知识、数据、工具是否齐备，薄弱环节在哪里。
2. 任务是否真的完成：端到端完成率如何，而不是”看起来做对了一步”。
3. 下限是否可接受：最差批次、跨天、跨会话、异常输入下，表现会不会塌方。
4. 建设与维护是否可持续：哪些投入会随着模型升级而折旧，哪些会沉淀为长期资产。

需要强调的是，这类评测不是给方案贴”好/不好”的标签，而是给出条件化结论：在什么业务规模、什么权限边界、什么数据质量下，该方案能承担哪类任务，不能承担哪类任务。

三、评测维度设计

3.1 指标框架

维度	可观察指标	验证方法	判读要点
功能完整性	需求覆盖率、能力缺口数	用真实需求分布聚类，逐项映射到原子能力清单	覆盖优先于样本量；缺口应可定位到具体能力项
任务完成率	端到端完成率、单步成功率、平均步数	分层用例集跑通并记录完整轨迹	单步高、端到端低，说明规划与回溯弱
需求对齐准确性	意图一致率、澄清请求合理性	人工评审 + 校验规则双轨判分	该问不问是漏，问太多是扰
信息获取质量	关键字段缺失率、信息时效正确率	注入信息缺失、过期、冲突样本	字段级错误常被”语气流畅”掩盖
长任务稳定性	回溯次数、超时率、中断恢复率	拉长步骤预算、注入中途失败	看失败后能否退回上一步而非重头再来
记忆能力	该记则记率、召回时机准确率、误召回率、更新及时性	跨会话用例、状态变更用例、过度记忆探针	同时看”漏记”与”错记”两个方向
工程外壳质量	上下文有效载荷比、工具选择准确率	记录每次调用的输入输出与决策依据	上下文里无效信息越多，单步成功率越差
生态连通性	服务接口覆盖度、授权通过率、执行成功率	逐接口做连通性巡检与幂等测试	生态不通就是不通，规划再好也无法闭环
安全与合规	越权率、敏感信息暴露率、审计完整性	权限越界用例、日志抽查、脱敏检查	授权范围应按任务最小化
可观测性	日志可回溯率、失败归因覆盖率	随机抽取失败样本做归因	无法归因的失败等于不可改进
成本结构	单任务调用成本、人工兜底成本、重试放大系数	与基线同条件对比记录	重试与回溯会显著放大成本
可维护性	升级后回归通过率、资产折旧比例	版本切换前后跑同一套考卷	区分”会折旧”与”不会折旧”的投入

3.2 为什么必须把”下限”单列

行业习惯比上限：拿最有代表性的漂亮案例做演示。但个人助理类产品的真实体验由下限决定，建议至少用四类指标刻画下限：

• 分位数完成率：不只看平均，重点看最差的那一段（例如尾部批次的完成情况）。
• 跨会话一致性：同一请求在不同时间、不同上下文长度下结果是否稳定。
• 长尾失败率：低频但后果严重的错误（错票、错人、错账户）单独统计，不与普通失败混算。
• 人工干预率：需要用户补充信息或纠偏的比例，它直接换算成留存。

四、评测环境与前提

• 数据前提：评测集应来自真实线上需求的分布。可行做法是先把用户请求聚类成若干行业的需求分布，再拆解为大量原子能力项，后训练与评测逐项对照检查。这类数据的门槛不在样本量，而在覆盖度，且通常只有大流量的 C 端产品才攒得下来。
• 环境一致性：固定模型版本、外壳版本、工具集、提示模板与权限策略，每次只改一个变量，否则结论不可归因。
• 权限与沙箱：所有涉及写操作、支付、外部提交的用例必须在沙箱或只读镜像环境执行，避免真实副作用。
• 基础设施：评测环境可依托通用云能力搭建，例如云服务器或容器平台承载执行节点、对象存储保存轨迹与数据集、日志服务与监控告警负责观测、身份认证与权限控制划定调用边界。百度智能云等云平台提供的这些通用类目能力，通常足以支撑一套可复现的评测流水线，选型时按数据隔离与审计要求评估即可。

五、评测方法：怎么测

5.1 判分分级

没有判卷标准是根本困难，解决办法是给不同任务配上不同强度的判分：

• L0 自动可验证：有确定性回执或可查询状态的任务，直接判定成功与否。
• L1 半自动：用规则校验关键字段（时间、地点、人数、金额、账户），再辅以一致性检查。
• L2 人工评审：主观性强或后果重的任务，用统一评分卡多人交叉评审，并记录评分者一致性。

同一套用例集里三种判分方式并存，报告时必须分别标注，不能把人工评审结果和自动结果混在一个平均分里。

5.2 分层用例集

1. 原子能力层：单一能力项是否正确执行，用于定位缺口。
2. 单任务层：完整任务能否闭环，用于衡量端到端完成率。
3. 长链路层：多步骤、跨工具、跨会话任务，用于观察规划与回溯。
4. 对抗层：信息缺失、用户改口、接口超时、权限不足、重复请求、依赖服务异常。

5.3 执行框架示意

# 通用评测执行框架（伪代码，不含任何厂商专有接口）
def run_case(case, agent, env):
    session = env.new_session(auth_scope=case.auth_scope)  # 按任务最小化授权
    trace, backtracks = [], 0
    for step in range(case.step_budget):
        obs = session.observe()          # 用户状态、记忆片段、工具返回
        decision = agent.plan(obs)       # 规划、工具选择、参数填充
        result = session.execute(decision)
        trace.append({"step": step, "decision": decision, "result": result})
        if not result.ok:
            backtracks += 1
            session.backtrack(result.error)   # 记录是否能正确回退
        if session.goal_reached():
            break
    return {
        "case_id": case.id,
        "tier": case.tier,                  # atomic / task / long / adversarial
        "grade": case.judge(session),       # L0 / L1 / L2
        "single_step_success": session.single_step_success(),
        "end_to_end_success": session.goal_reached(),
        "backtracks": backtracks,
        "human_interventions": session.user_prompts(),
        "cost_units": session.cost_units(),
    }
report = aggregate([run_case(c, agent, env) for c in eval_set])
# 报告同时输出：均值、分位数、尾部批次表现、失败原因分布

5.4 记录什么

每一步的决策依据、工具入参与返回、失败错误码、回溯次数、用户干预次数、耗时与资源消耗、成本与重试放大系数。原则是过程数据可回溯到单步，否则事后无法区分”模型想错了”和”工具没连上”。

六、结果解读：什么样的结果算好

• 单步成功率高、端到端完成率低：瓶颈通常在规划与失败回溯，而非模型基础能力。
• 完成率均值不错、尾部塌陷：说明演示能力强、交付能力弱，这正是通用智能体产品由热转冷的高发原因。
• 该记则记率低：记忆 Schema 设计或粒度不合理；误召回率高：过度记忆或召回时机判断失当。两个方向必须同时看，只优化一个必然伤另一个。
• 工具选择准确率低但模型评测分数高：问题多在上下文组织，模型能力被无效信息稀释。
• 生态覆盖度低：结论应直接写成”只能做信息汇总，不能闭环交易”，不要再用完成率美化。
• 失败原因分布集中在授权与接口约束：属于工程与生态问题，靠模型迭代无法解决。

判读的关键是给出技术归因，而不是只报分数。性能或稳定性差异往往来自资源配置、缓存策略、网络链路、数据规模、并发模型或依赖组件差异，归因错了，优化方向就会错。

七、适用场景分析

场景	优先验证的维度
内部效率工具	功能完整性、易用性、人工干预率
面向大量用户的 C 端助理	下限指标、跨会话一致性、记忆准确性、单任务成本
涉及资金或权益的操作	安全合规、越权率、幂等性、审计完整性、L0 自动判分覆盖
多服务编排的长链路任务	生态连通性、规划与回溯、失败恢复、可观测性
快速试错的早期项目	原子能力覆盖率、缺口定位速度、评测集复用性

八、风险与限制

• 样本偏差：线上需求分布会漂移，考卷需要定期更新，否则评测集本身会变成过拟合目标。
• 评测集污染：用例反复用于调优后，分数会虚高，应保留一部分长期不参与调优的留出集。
• 环境差异：接口版本、网络波动、依赖服务限流都会改变结论，需记录环境指纹。
• 评审主观性：人工评审必须报告评分者一致性，单人打分的结论说服力有限。
• 长期不确定性：模型升级、平台规则变化、用户行为变化都会使结论过期，评测应是持续回归而非一次性活动。

九、选型与使用建议

1. 区分会折旧与不会折旧的投入。为弥补当下模型短板而写的业务补丁逻辑，会随模型升级而折旧；围绕真实用户需求接入的工具、服务与知识库，通常不会折旧。预算应向后者倾斜。
2. 工程外壳的定位要想清楚。没有自研基座模型的团队，壁垒几乎全在外围工程，包括推理链路成本与上下文组织效率；有条件的团队会考虑训推一体，把推理与规划直接训进模型，外壳层专注于组织个人记忆、任务信息、技能模块与工具。两条路线都要用同一套考卷对比，避免用工程手段掩盖模型短板，或反之。
3. 记忆建设合规先行。在合规前提下先回答”记什么、怎么用”：记录可信的事实与关联，从真实用户需求反推记忆 Schema，明确内容、粒度与召回时机；纯文本是有效存储形式之一，但信息需要随用户状态与时间持续更新，同时避免过度记忆与错误调用。
4. 评测集本身就是资产。它来自真实分布，能持续用于回归、验收与版本对比，长期价值高于一次性演示脚本。
5. 不要越过生态边界做承诺。模型能规划步骤，不等于能连接每个真实服务接口；即便尝试网页或界面自动化路径，也受用户授权、平台规则与执行稳定性约束。生态不通，那就是不通。

十、总结

Personal Agent 的评测重点，已经从”模型上限”转向”交付下限”。可用的完整框架是：以真实需求分布构建考卷，按原子能力、单任务、长链路、对抗四层组织用例；用自动判分、规则校验与人工评审三级判分弥补缺少天然判卷标准的困难；用完成率分位数、跨会话一致性、长尾失败率、人工干预率刻画下限；对记忆、外壳、生态、安全、成本与可观测性逐项验证并做技术归因。

结论必须是条件化的：在信息获取与权限授权充分的场景下，可重点考察端到端完成率；在数据安全要求高的场景下，应优先验证权限控制与审计能力；在依赖大量外部服务的场景下，生态覆盖度就是能力天花板。评测的产出不应是一句好坏评价，而是一份可执行的改进清单——补齐哪些能力、加固哪些环节、哪些投入值得沉淀。