I8：案例场景和测评构建

Easy Data x AI 课程 · 产业应用篇 · 第 8 节

本节定位

本节从多 Agent 群聊、长期陪伴、车载交互和工作交接等场景出发，介绍如何选择测评集、设计对照实验、保留运行证据并分析失败案例。承接 I6 的接入实践和 I7 的实现解读，重点验证上下文管理是否改善了具体任务的结果。

用户不会在每次对话里重新交代自己的习惯，一群人也不会在每位 Agent 加入时重讲已经讨论过的决定。上下文让服务能够接续下去。不过，记得多也会带来问题：昨天的安排可能已经取消，一个人的偏好未必适用于同车的其他人。判断上下文是否有用，要看它怎样影响这一次回答或行动。

《上下文工程概述》讨论了怎样组织上下文，《PowerContext 的设计与实现》解释了记忆如何形成、检索和交接。本节从应用场景出发，介绍测评集的选择，再看 PowerContext 如何组织第三方案例、保留运行证据和分析结果。完成练习后，你应能给出一份有明确任务范围、对照条件和失败记录的测评报告。

一、从具体场景看上下文问题

多 Agent 群聊：大家最后决定了什么

设想一个安排周末出行的群聊。几位用户和负责行程、交通的 Agent 一起讨论：最初有人提议徒步，后来大家改去滨河博物馆，并确认周六九点半在东门集合。交通 Agent 中途加入，收到的请求只有一句“按刚才定的方案安排接送”。

它需要知道哪条消息是建议、哪条是共同确认的决定，还要分清是谁说的。把所有消息压成“周末去徒步或博物馆”的摘要，会丢掉讨论的结果。行程 Agent 的推测也不应在几次转述后变成用户已经确认的安排。

为这类协作准备上下文时，可以保留带发言人和时间的消息，单独整理当前决定与待确认事项。每位 Agent 根据职责和可见范围取得材料，群内共享决定，私聊里的个人信息仍按原有范围使用。中途换 Agent、有人补充条件，工作都应能继续。在 PowerContext 中，可以用 Topic Memory 整理持续讨论中的决定与待确认事项，并保留 Source 引用，供后加入的 Agent 了解进展、核对依据。

测评可以重放“提出方案、修改方案、确认、另一位 Agent 接手”的过程，再检查接送安排是否采用了最新地点和时间。还可以加入一个只提出建议、始终没有确认的版本，观察 Agent 会不会擅自把建议当成决定。两种结果一起看，能分辨它是否理解了讨论的进展。

长期陪伴：记得过去，也听得进今天的话

用户前几天聊到正在准备面试，今天又说“结果出来了”。陪伴型助手如果能接上这段经历，用户就不用重新解释“什么结果”。但如果历史里没有提到面试的公司或结果，助手也不该补出一段两人从未聊过的细节。

偏好同样会变。用户平时喜欢简短回复，今天却明确说“想多聊一会儿”，这次对话就应跟随当前意愿。一次疲惫时说的“今天不想聊天”，也不适合永久写成“不喜欢交流”。长期背景和当下状态的有效时间不同。

这一场景适合按时间组织连续对话，保留用户明确说过的经历和偏好，让当前请求参与上下文选择。PowerContext 的 Memory 可以保存具体经历和偏好，Profile 则整理相对稳定的用户背景，两者随信息变化更新，为后续对话提供参考。测评时既可以问“上次谈到什么”，也可以用省略背景的新消息，看助手能否接上话题。话题衔接、偏好更新和虚构经历可以分别标注；语气是否自然、回应是否让人感到被打扰，还需要人工阅读或用户反馈。

车载交互：同一辆车，每次出行的条件不同

车主通常上车就听音乐，这次却说“孩子睡着了，先安静一会儿”。助手需要把当前要求放在习惯之前。下一次独自出行时，上次的临时要求又不应一直生效。若同一辆车由不同的人使用，个人偏好还要对应到正确的人。

车载上下文还包含本次行程中的状态。目的地发生变化、乘客加入、驾驶员打断一句播报，都会改变接下来的回应。仅凭长期对话中的“常去哪里”，不足以判断用户此刻说的“继续”指哪项操作。应用可以将 PowerContext 中的 Profile 纳入本次 PreparedContext，再结合实时行程状态，让 Agent 同时了解用户的长期习惯和当前要求。

构建这类测评时，可以把输入表示为带时间、说话人和行程标识的事件，在模拟环境中检查回复与操作记录。例如，分别重放“平时听音乐”“本次要求安静”“下一次出行”几个阶段，核对当前要求是否得到执行、临时状态是否正确结束。还要记录从事件到回应的延迟。对话答得合适与操作及时生效，是两项不同的结果。

工作交接：减少重复解释，保留可继续的进展

售后 Agent 已经核实了订单和故障，转给另一位 Agent 或人工客服时，用户通常不愿再回答一遍相同的问题。接手者需要拿到已核实的信息，也要看清哪些只是推测、哪些处理步骤还没有完成。以前验证过的排查方法可以继续使用，旧工单的故障结论却要在本次重新核实。在 PowerContext 中，Handoff 用于交代已验证的进展和下一步，经过审核的 Experience 则保留可复用的排查方法，分别支持本次接手和后续任务。测评可以检查重复询问的次数，以及后续处理是否沿用了已确认的进展。

研发协作也有同样的问题。前一位 Agent 找到了故障原因，接手者应能据此继续修改和验证。代码任务可以用补丁与测试结果评价交接效果，客服任务则需要核对处理记录和用户实际诉求。它们共享一套“接续工作”的思路，成功标准各有不同。

这些例子分别涉及群体决定、个人经历、短期状态和工作进展。测评设计需要保留各自的时间关系与参与者关系，再检查最终行为是否符合当时的条件。

二、把场景变成可测的问题

以群聊为例，可以提出一个具体假设：“新加入的 Agent 得到当前确认的出行方案后，会更少地沿用旧地点。”随后把完整讨论、接手时的请求和预期安排写成一个任务。先确定判断规则，再调整检索和提示词，比较结果才有依据。

要确定的内容	群聊协作中的例子
测什么任务	为已经确定的周末活动安排接送
能看到哪些信息	接手前的群消息、发言人和确认记录
应该完成什么	使用最终确认的地点和集合时间，未确认时先询问
怎样判定	核对接送方案、是否误用旧决定，以及是否暴露不可见的私聊内容
与什么比较	同一段讨论和同一个请求，分别提供原始历史或整理后的上下文

比较两种策略时，固定任务、模型、提示词、工具权限和执行预算，只改变所研究的上下文处理方式。历史由测评输入明确提供，每次运行使用独立环境。调参样本与最终报告样本按用户、群组或项目划分，避免同一段历史同时进入两组。

测试集中还需要相近却结论不同的样本：地点改了与没有改、用户明确确认与尚未确认、同一乘客与换了乘客。它们能帮助判断系统是否真的使用了上下文。陪伴对话可以允许多种合适回答，评分规则写清必须遵守的事实和当前意愿，无需强求一句固定措辞。

分析时沿着实际过程检查，最后落到任务结果：

History -> Capture -> Memory -> Retrieval -> Agent action -> Task result
             |           |          |             |              |
          complete?   faithful?   relevant?      used?         correct?

前面几项帮助定位失败，最后一项回答业务目标是否完成。链路检查与结果评价都值得保留，但要分别报告。

三、让测评对应预期的应用场景

记忆是上下文工程的一项基础能力。长期陪伴、群聊协作和工作交接，都需要保留过去的信息，并在合适的时候找回来。在此基础上，还要看 Agent 能否把历史信息用于当前请求，以及在长时间执行任务时持续利用它。PowerContext 选择测评集，也沿着这些实际需求展开。

场景中的需求	采用的测评集	主要观察什么
从长期交互中找回事实和关系	LoCoMo	记忆提取、证据召回与回答质量
当前请求没有重述旧条件，仍需考虑历史中的约束	LoCoMo Plus	历史线索能否影响当前回答
Coding Agent 在多步探索和修改中完成研发任务	SWE-bench Pro	上下文是否帮助长程执行并改善最终任务结果

LoCoMo：建立基础记忆能力的评估起点

LoCoMo 提供公开的长对话记忆任务，可以作为比较记忆能力的共同起点。PowerContext 采用它，首先是为了检查系统能否从跨会话历史中提取信息、找回相关证据，再据此回答问题。这些能力也是前面各类应用继续工作的基础。

仓库中的 benchmark/locomo 覆盖历史导入、记忆提取、检索、回答和评分。当前实现对类别 1 至 4 的 1,540 道问题计分，检索证据按会话核对。原始标注可以精确到某一轮对话，因此阅读结果时要区分会话命中与更细的证据定位。记忆评测先回答这部分基础能力怎样，再由场景任务检查它是否转化为实际效果。

LoCoMo Plus：进一步要求记忆参与当前判断

用户说过自己周三晚上有课，后来请助手安排讨论时，未必会再次提醒这个条件。LoCoMo Plus 在事实回忆之外，增加了这类对历史线索的应用要求：当前请求与先前线索之间可能没有直接的词面联系，系统仍需考虑用户的状态、目标或价值取向。这使它对记忆的使用提出了更高要求，也更接近陪伴和连续交互中的部分问题。

PowerContext 的 benchmark/locomo_plus 提供 memory、memory-source、query-only、full-context 等实验分组，用来观察不同上下文供给方式的影响。oracle-cue 则直接提供标准答案所对应的线索，用于诊断回答能力。它的结果应单独解读。

LoCoMo Plus 使用的数据版本、历史构建与评分口径都需要记录。其事实数据也与另一套 LoCoMo 文件有差别，因此两套分数各自解释，不能直接相减得出能力提升。具体实现与样本范围见 PowerContext 测评目录。

SWE-bench Pro：观察长程研发任务中的效果

研发和 Coding Agent 协作是 PowerContext 关注的一类应用。一个仓库问题可能需要多次查找调用关系、尝试修改、运行测试，再根据失败结果继续推进。过程拉长后，Agent 需要保留已验证的发现，及时修正过时的判断，并在后续决策中使用相关上下文。

SWE-bench Pro 提供仓库问题与补丁验证任务，适合用来观察这种长程执行。PowerContext 引入它，是希望进一步回答：上下文管理能否帮助 Agent 完成更多实际研发任务。运行入口位于 evaluation，支持开启与关闭 PowerContext 的配对实验，使用固定任务集和官方 evaluator 检验补丁。评估服务说明

这几项测评覆盖了基础记忆、历史约束应用和长程研发执行。群聊中的角色归属与决定状态、车载交互中的临时状态和响应时序，还需要相应的场景样本。随着目标场景增加，测评集也应继续扩展。

四、Harbor E2E：面向第三方案例的扩展路径

前面介绍的 LoCoMo、LoCoMo Plus 和 SWE-bench Pro 分别使用各自的测评实现，运行不依赖 Harbor。PowerContext 另外在 e2e/bub 中提供了一条基于 Harbor 的 E2E 路径，用来承载经过适配的第三方案例，检查执行过程中的记忆行为，并为继续扩展案例提供基础。

这条路径考虑的是新增案例的接入成本。不同任务有各自的依赖、启动方式和验证程序，逐套维护环境管理与结果收集脚本容易产生重复工作。接入 Harbor E2E 后，各任务仍保留所需依赖与验证程序，环境创建、任务运行和清理则可以复用。这里的共用机制限于接入该 E2E 入口的案例；已有的独立基准测评继续按各自的流程运行。

以下实现说明依据 PowerContext 提交 d0f669d5541bc7b391e840c7c6a951631b2a32ee。

Harbor 运行任务，PowerContext 补充上下文观测

在这条 E2E 路径中，Harbor 负责组织任务说明、运行环境和验证程序，并调用 Agent 执行任务。PowerContext 在执行过程前后增加任务选择、独立的 Scope、记忆采集与召回检查，最后保存运行证据和报告。历史是否采集成功、记忆是否形成、Agent 得到了什么上下文，都能随任务一起记录，供失败分析使用。

例如，Agent 未能完成一个终端任务时，原生验证程序会记录任务失败。上下文观测则可以帮助判断它有没有留下前面探索过的事实，后续查询是否找回了这些事实。两份结果放在同一次运行记录里，才便于追查它们之间的关系。

Adapted E2E cases -> Task manifest -> Harbor -> Agent -> PowerContext
                                        |                   |
                                  Native verifier     Context evidence
                                        |                   |
                                    Task score       Memory evaluation
                                        \___________________/
                                               Run report

当前执行适配使用 Bub，通过 ACP 与 Harbor 连接。任务清单声明案例来源、执行预算和记忆预期，模型配置由对应的运行组件提供。这样增加一条案例时，可以沿用环境管理和报告流程，把主要工作放在输入与评价规则上。E2E 实现说明

这条 E2E 路径已经接入了什么

一部分 LoCoMo 数据被整理成本地 Harbor 任务，保留原始样本身份和来源指纹，用来检查跨会话的记忆行为。这些派生样例与 benchmark/locomo 复用了数据来源，但任务组织和评价目的不同：前者提供 E2E 回归反馈，后者执行独立的 LoCoMo 问答测评。

Terminal-Bench 2.0 的 db-wal-recovery 则通过数据集名称、版本和任务 ID 接入。Harbor 继续使用原任务的环境与验证程序，PowerContext 额外记录执行中的信息采集、记忆生成和召回情况。它展示了怎样把已有第三方任务接入共同流程，同时保留原生验证。

两者共用执行记录和 Memory 评价方式，记忆验收结果与原生任务得分分别报告。一次运行可能通过记忆检查，却没有完成原任务；也可能任务完成了，记忆链路仍存在缺口。

新案例怎样复用这条路径

将新案例接入 Harbor E2E 时，首先处理样本如何映射为任务、依赖如何准备，以及原始评分怎样保留，其余环境管理与结果收集继续复用。为这条路径更换 Agent，需要补充执行适配，让它留下可供评价的输入、输出和上下文证据。增加评价规则，则应尽量复用已经保存的观测，避免为了重算一个指标而重新运行整段任务。

这种分工让已接入的案例可以随产品持续维护。修复一次跨会话召回故障后，可以把失败输入保留为回归任务；以后即使内部实现改变，仍然检查用户能观察到的行为。后续是否把某个基准中的案例适配到这里，取决于需要验证的行为。它可以与该基准原有的测评实现并行存在。

五、构建和迁移测评集的共通方法

无论使用独立的基准实现，还是把案例适配到 Harbor E2E，都需要先确定用途：是复现原测评集的结果，还是选取部分案例检查产品行为。前者需要保持原有输入与评分协议，后者可以构造较小的回归集合，但要写明选择和改写了什么。

固定案例来源，保留原任务的含义

第三方样本经过适配后，仍应能找到原题。数据版本、样本 ID、选择规则和任务校验值共同说明“这次究竟跑了什么”。这些信息固定下来，后续代码或模型变化带来的差异才有比较依据。

原始材料	迁移时保留的内容
对话与事件记录	发言人、时间、可见范围和先后顺序
问题或任务说明	Agent 当时真正收到的请求
标准答案、证据标注或参考补丁	交给评分器使用的参考材料
环境与验证程序	任务的依赖、初始状态和成功标准
数据来源与样本身份	固定版本、稳定 ID 和选择规则

对于对话测评，只导入标准答案所指向的几段历史，会提前替系统完成证据选择；删去中间的偏好变更，也会改变任务难度。应保留任务要求的历史范围，将答案和评分材料留在验证侧。代码任务同样需要保持初始仓库、依赖与测试的一致性。更改资源限制或评分规则时，在报告中说明结果适用的条件。

以 Harbor E2E 为例，可以对照阅读 locomo-support-group 和 terminal-bench-db-wal-recovery 两份清单：前者如何关联原始对话，后者如何引用注册数据集，它们又分别增加了哪些记忆检查。这里 LoCoMo 派生样例的 provenance.revision 使用原始文件的 SHA-256；Harbor 任务另有自己的校验值，用于检查执行内容是否与清单一致。

记录任务结果与上下文证据

迁移后的任务应同时留下原生结果和上下文证据。原生验证程序回答任务是否完成；Memory、准备给 Agent 的上下文和执行轨迹用于解释这个结果。群聊中决定是否被误用、陪伴回复是否符合当前意愿，需要相应的场景评价，无法直接换成一个通用的片段命中率。

各次运行还需使用明确的初始状态。独立任务隔离工作区和记忆，同一任务内需要延续的历史则显式提供。群聊样本按角色提供可见材料，车载事件按时间逐步进入输入。评分器可以读取完整事件表，Agent 在某个时刻只能获得此前发生的信息。

Harbor E2E 的开发环境会挂载源码，构建正式比较时还要核对答案文件是否对 Agent 可见。环境隔离、输入范围和评分口径都要在迁移后重新确认，才能解释分数为何变化。

观察一条已有的 Harbor E2E 案例

按 E2E 说明准备 Linux Docker、Compose 与 uv 环境后，可以从仓库根目录选择一条已有案例：

make harness-compose-acceptance ARGS='--id locomo-support-group'

这条样例通过直接工具调用检查记忆链路，无需配置生成或嵌入模型。默认输出位于 .powercontext-e2e/bub/sqlite/acceptance/locomo-support-group/。阅读 report.md 后，可以用 replay.json 核对输入与观测，用 eval-report.json 查看判定依据，原生执行记录保留在 harbor-jobs/ 中。

在该 E2E 入口中换成模型驱动的长任务，需要按任务说明配置模型和执行预算。组织自己的案例集时，可以先选少量有代表性的任务验证接入，再逐步加入曾经失败的业务样本。报告保留所用入口和样本范围，便于区分 E2E 检查与完整基准测评。

查看该 E2E 案例的链路指标

Harbor E2E 的评价器在 eval-report.json 中记录以下链路指标，它们帮助解释这条 E2E 路径中的记忆行为。

指标	能说明什么	仍需检查什么
capture_coverage	适用事件中被采集的比例	采集内容是否保留了必要细节
groundedness	具有非空来源引用，且引用都指向本次采集记录的新记忆比例	记忆是否忠实表达原意
probe_coverage	满足预期片段的正向探针比例	回答是否正确、是否处理了否定和更新
in_run_contexts	运行时准备出的非空上下文次数	Agent 是否使用了它
原生任务得分	任务验证程序对产物的判断	验证程序是否覆盖了业务要求

例如，当前实现中，没有配置正向预期片段时，probe_coverage 按约定记为 1，阅读分数时还要核对探针内容。groundedness 检查的是来源关联，记忆对原意的表达仍需单独评价。

对这次 E2E 保存的证据，还可以离线重新执行 Memory 评分：

REPLAY=.powercontext-e2e/bub/sqlite/acceptance/locomo-support-group/replay.json \
POWERCONTEXT_E2E_OUTPUT=.powercontext-e2e/course/rescore \
  make harness-rescore

它使用 replay.json 内保存的任务清单。只修改外部 YAML，不会改变旧记录中的评分条件；修改检索策略后，也需要重新运行任务才能观察新的召回。

六、运行对照并分析结果

从 LoCoMo Plus 做一次小型比较

这里使用 benchmark/locomo_plus 的独立测评脚本，比较 query-only 与 memory 两个实验分组。前者只给问题，后者经过历史采集、记忆提取和检索后回答。它们比较的是完整记忆策略的影响，不能单独归因于某一种检索算法。

下面的命令从上述固定版本的 PowerContext 仓库根目录执行。先用 uv sync --locked 准备项目环境，再检查自带的十条样本；这一步不调用模型：

uv run python -m benchmark.locomo_plus run \
  --dataset-file benchmark/locomo_plus/dataset/locomo_plus_smoke10.json \
  --limit 10 --dry-run

这个小集合保留每个入选样本的完整历史，只减少题目数量。确认输入后，将 benchmark/locomo_plus/.env.example 复制到同目录的 .env，配置生成和嵌入模型，并显式选择评分模型。两组使用相同样本和模型配置，分别保存结果：

export COURSE_JUDGE_MODEL='openai:YOUR_JUDGE_MODEL'

for arm in query-only memory; do
  uv run python -m benchmark.locomo_plus run \
    --dataset-file benchmark/locomo_plus/dataset/locomo_plus_smoke10.json \
    --env-file benchmark/locomo_plus/.env \
    --judge-model "$COURSE_JUDGE_MODEL" \
    --limit 10 \
    --arm "$arm" \
    --run-id "course-$arm"
done

这一步会产生真实的模型调用。十条样本适合检查流程和逐题分析，不能据此推断整个测评集的准确率。确认流程后，可增加样本，或加入 memory-source、full-context 分组。完整历史与检索上下文的输入开销不同，应连同质量一起记录。

读取各运行目录中的 summary.md 和 observations.jsonl，先按样本 ID 配对，再看答案和当时提供的上下文。挑出两组回答明显不同的题目，核对评分依据。对于陪伴对话，还可以请评阅者在不知道实验分组的情况下阅读回答，分别评价事实衔接与回应是否合宜，保留意见不一致的样本。

分析结果时，还要回到任务本身。交通 Agent 找到了博物馆，却采用了旧的集合时间，说明地点命中不足以代表安排正确。车载助手找回了车主的音乐偏好，却忽略本次安静要求，就要检查临时状态是否进入输入，以及 Agent 如何处理二者的关系。

逐题分析时，从原始材料查到召回内容，再查实际回答或操作。关键细节在中间消失，可以回到提取与筛选环节；证据完整却被误用，就看 Agent 的处理过程。行为符合要求而得分不对，则需要复核评分规则。

报告改善，也报告退步与运行故障

两组总分相减会掩盖任务变化。报告中应同时列出两组都成功、仅实验组成功、仅对照组成功、两组都失败的数量。净增成功数等于新增成功数减去新增失败数，新增成功和新增失败都值得单独查看。

报告还需保留计划任务数、完成数、错误数和跳过数，分别计算完成样本的回答质量与全部计划任务的成功比例。环境启动失败和模型答错要分开记录，前者用于排查运行问题，后者用于分析任务质量。模型运行存在随机性，重复实验时保留每次结果，分析不确定性时注意同一用户或群组下样本的相关性。

延迟和成本也要说明边界：是否包含历史导入、提取、嵌入、召回、回答与评分。未取得用量或价格时应记为未知。一次导入、多次查询的应用，可以分别报告首次准备成本与后续查询成本。

从已保存的回答重新生成报告

LoCoMo Plus 的 replay 按已经保存的回答与评分重新生成汇总，不会请求新的评分模型：

uv run python -m benchmark.locomo_plus replay \
  --run-directory benchmark/locomo_plus/results/course-memory

这一步适合复核汇总结果。若要改变检索策略、重新回答或请求新的模型评分，则需要相应的实验过程，并使用能区分的新运行记录。

七、课程练习：提交一份可复查的报告

选择一个与你关心的场景相关的案例，明确使用该基准已有的测评实现，还是将它适配到 Harbor E2E。整理所需输入、环境和评价规则，说明哪些内容可以沿用、哪些需要适配，以及结果能够回答什么问题。结合一份实际运行记录，检查这些约定是否得到保留。

报告应包含所用测评入口、任务假设、数据来源与版本、样本选择规则、运行配置、逐题结果和成本范围。进行对照实验时，分别列出两组配置。附上一条成功案例、一条失败案例的证据路径，说明下一轮准备改变什么，以及预期影响哪个指标。若只完成了直接工具样例，应将结论限定为链路验收；若完成了模型对照，则根据实际入选任务讨论回答或任务结果。