在真实 QA 部署上测试 MOI 智能体的任务完成质量、效率和稳定性。
Agent journeys QA 每六小时运行一次，也支持手动运行。PR 和合入 main 不触发真实 QA；PR 只运行 Offline tests，验证执行框架、浏览器场景与验收器，不读取 QA 凭据。定时与手动入口需要工作流先合入 main；真实 QA 使用 GitHub qa environment 的 MOI_BASE_URL 与 MOI_PAT secrets。浏览器 case 还需要 MOI_UI_BASE_URL、MOI_UI_AUTH_ORIGIN、MOI_UI_ACCOUNT 和 MOI_UI_PASSWORD，并在登录前核对账号中心域名。
配置入口是 suites.json：
| 工作区 | 副名 | 当前内容 | 最大并发 |
|---|---|---|---|
| journey-1 | Complex Long-Horizon Tasks | 18 个文档与办公任务 | 9 |
| journey-2 | Basic Functional End-to-End Tasks | 131 个智能体功能用例 | 3 |
| journey-3 | Knowledge Base Tasks | 57 个知识库 Q&A 用例 | 3 |
| journey-4 | — | 空 | 3 |
| journey-5 | — | 空 | 3 |
GitHub 手动运行的工作区下拉选项和运行分组显示为 journey-1 (Complex Long-Horizon Tasks)、journey-2 (Basic Functional End-to-End Tasks)；命令行仍可使用 journey-1、journey-2 工作区 ID。
五组可以同时运行；按当前并发配置，全部配置 case 后最多 21 个 case 同时调用 QA。空组显示 empty，不产生虚假通过结果，也不计入成功率分母。每个 case 单独使用一个标准 ubuntu-latest runner，失败不会取消同组其他任务。全局 concurrency group 防止整批运行相互重叠；后续批次排队等待，最多保留 100 个等待中的运行。连续提交过多可能造成积压并推迟定时回归。
Journey-1 每个 case 的 QA 总预算为 3600 秒，Journey-2 为 300 秒，覆盖一个 case 的全部对话轮次；如确有特殊长耗时用例，可在该 case 中显式设置 timeout_seconds。主任务超时记为 timeout，未能开始任务或取证出错会另记框架错误；语义评分阶段超时或结果无效记为验收器错误。超时后会取消已知未结束任务、补采事件并归档会话；清理和最终取证不占 QA 预算。工作流为执行步骤按 QA 预算额外留出 4 分钟用于取证和清理，材料准备及上传另计。主任务耗时与语义评分耗时分开统计。长任务统一使用正式的 message/stream SSE 协议，先取得 task ID 并实时落盘；随后核对持久化任务和事件。业务请求和模型任务不自动重试，保留第一次失败证据。
题集与参考复核记录见 journey-3-qa-review.md。57 个 case 分为 SAP 29、Cedar 18、MOI 7、MatrixOne 3；包含连续追问、独立新会话及重复题对照，共 61 次被测请求，其中 58 次回答需要评估，其余用于建立业务上下文。
使用 journey-3 现有的四个专用智能体及其绑定知识库，不创建或修改智能体、知识库、索引和源资料。每个 case 创建独立会话；连续追问仅在本 case 内保留上下文。任务完成后采集事件、产物并归档测试会话。
报告按两个维度组织：
- 效率：任务耗时、工具调用及轮次、完整调用参数和结果、重复调用/重复模式、连续检索没有新片段的次数。独立评估会判断是否明显绕路、发散或不收敛，结论必须引用真实调用 ID；正常分页、必要的大表处理和有理由的重试不能仅因重复就判为浪费。
- 正确性：实际最终回答、参考要点满足率、已审查主张的检索依据支持率，以及引用来源是否存在、是否属于指定知识库、是否可读取、引用内容是否支持结论。未采集到检索上下文时，主张支持率记为无法评价；不会按 100% 处理。
只把问题发送给被测智能体。参考答案和资料片段用于独立的 MOMO 评估会话；评估使用同一配置模型，模型身份与原始判词保存在证据中。评分模型通过答案段落 ID 和证据 ID 提供依据，由代码核对身份并回填实际原文；绕路判断必须能对应真实工具调用；无效判词按评估器错误记录，不重试或补判。允许语义等价，标识符、数值、单位及适用范围应准确。
参考资料以源 ID、文件 ID、完整索引内容哈希和 ETag 固定。评估时核对参考来源快照；缺失信息题还核对整个绑定知识库的源快照，资料变动后停止语义计分并报告参考漂移。引用检查读取的证据仅保存来源身份、ETag 和实际引用分段，不复制整个知识库。原始输入中 1 份未能完整读取的文档未用作必需参考，详见复核记录。
Journey-3 被测任务沿用 1 小时超时；来源核验和模型评分各有独立预算：各最多 180 秒，多会话对照各最多 300 秒；两阶段与清理均不计入被测任务耗时。GitHub 绿色仍表示测试框架完成；知识库效率和正确性问题记录在单 case、汇总 Markdown/JSON 和 CSV 中，不作为 Journey-2 的功能发布门禁。
本地可将同一题显式指向另一个已绑定知识库的智能体，用于多库对照；未传参数时继续使用题集原来的单库智能体。指定智能体的实际绑定必须与参数完全一致，引用只允许落在这些库中，缺失信息题会校验全部绑定库的资料快照。有效执行配置保存在 case 的 execution-config.json 中：
python3 -m journey.knowledge_case J3-01 --agent-id '<agent-id>' --bound-corpora sap cedar moi matrixone评分器输入通过显式证据别名共享完全相同的正文，并去掉传输元数据，保留原文、来源身份、文件名和页码。同一会话的前序问答及经过相同来源核验的前序 CLI 读取回执作为上下文，其他会话不混入。原生 CLI 的服务端引用回执与独立读取的来源快照共同证明已选择的读取证据；这不代表采集了全部检索候选。CLI 发现/读取计数只采信完整的服务端控制器反馈，缺失时记为未知。引用内容是否支持回答，独立于检索事件是否完整。评分输入最多 60,000 字符，放不下的证据按完整单元省略并公开列明，对应维度记为未评分；完整原文继续保存在证据中。已确认的未通过项与未评分维度独立统计，两者可以同时存在。评分 JSON 可使用一个完整的 JSON 代码块，其他说明文字或无效结构仍报告评分错误。
修正评分器后，可以在新的空目录中添加 --evaluate-existing /absolute/path/to/results/J3-01 重新评估已有回答（目标参数必须与原执行一致）。它只调用独立评分会话，不重发被测任务；原结果保存在 evaluation-history/，报告保留重评记录与原任务耗时。
只运行部分题目时，用 python3 -m journey.report aggregate --workspace journey-3 --cases J3-01 J3-35 --root published-results --out bundle 明确汇总范围。所选题目的结果缺失仍计为错误，未选题目不计入分母。
SSE 与普通 JSON 接口均采用 32 MB 接收上限；按 UTF-8 字节限制单条事件，支持大表产生的多 MB 检索产物，不截断内容。
tasks/get 和任务事件集合接口没有服务端页大小参数，单次证据响应预算为 1 GB；下载超过 1 MB 后使用私有临时文件，超限显式报错。其他业务 JSON 接口仍采用 32 MB 上限。
每个 case 分别报告测试框架、智能体请求、交付和质量：
- 测试框架：准备、执行、验收和取证是否正常完成。框架正常则 job 显示绿色，即使智能体失败、超时、未交付或质量检查未通过；框架、验收器或取证异常才显示红色。缺失的 case 结果会明确计为框架错误。
- 智能体和交付：分别记录各轮请求是否正常结束、预期会话的交付是否齐全。所有请求结束且交付完成，才计为任务正常结束并交付；未交付、超时和无法确认单独统计。请求返回
completed不代表交付正确。 - 交付质量：列出检查通过数、全部未通过项和原因；无法验收时显示原因。检查数量是诊断信息，并非经过校准的统一质量分数。
- 效率和工具：记录端到端任务耗时、每轮 task/trace、可识别的工具轮次、调用结果和错误参数。工具调用成功率是明确成功数除以明确成功与失败数；跳过及结果不明确的调用不计入分母，不能当作工具业务正确率。用例主动触发的工具错误仍计入实际统计，但会在错误明细和汇总中标记为预期。评审会话的工具调用不混入智能体统计，其工具错误单独列出。
无法连接 QA、鉴权失败而未能启动任务，或无法取得交付与事件时，会标记测试执行或取证错误；缺少证据的结果显示为无法确认。一些上游检查器只返回未通过的规则、不提供具体原因，报告会明确标出，需要结合原始产物复核。
单 case 的 Case result and failure details 步骤和总报告分别展示上述维度。测试框架执行完成后，其他 case 和结果上传继续运行；总报告只在框架错误时使工作流失败，不用一个通过率掩盖智能体异常或质量问题。
汇总中的“确认正常结束并交付比例”以本批配置的非取消类 case 为分母，无法确认的 case 也在分母内；主动取消场景单独统计。Journey-2 功能通过率以全部必跑功能 case 为分母，包含阻塞、执行错误和缺失结果；质量检查结果单独展示。
Journey-2 另有功能验收：通过、不通过、前置条件不足和执行错误。功能不通过但测试和取证正常时，case job 仍为绿色；是否满足发布要求需要查看功能验收。coverage_status 明确记录功能覆盖尚未完成，总报告会提示当前结果不能作为发布门禁；只有完成并核对目标版本的能力清单后才能改变该状态。
手动运行 Agent journeys QA 时可以选择单个工作区；默认选择 all。定时运行始终执行全部已配置工作区，报告只统计本次选择范围。
每个 Journey-2 case 记录运行前后的 QA MOI 后端版本与构建 commit；单 case 期间版本变化时标记 blocked。总报告会标出不同 case 是否观测到了不同的 MOI 构建，版本缺失时也不会假定一致。该记录只覆盖 MOI 后端，不代表 Astra、模型服务、数据库迁移或功能开关也已核验。
判据校准尚未完成。 J1-02、J1-07、J1-10、J1-13 和 J1-15 已发现部分上游检查与任务或材料不一致；应结合具体判词和原始产物复核。J1-14 对 Word 和邮件的部分自然语言一致性只能做有限检查；J1-17 的物料名称精确匹配可能误判同义写法。J1-18 的上游 C08 要求引用具体旗舰系列，但这一要求未在任务和会议纪要中明确，需要单独复核。检查结果不能直接当作智能体能力得分。
| 编号 | 任务 | 主要检查 |
|---|---|---|
| J1-01 | 合同接受全部修订 | 插入/删除语义、旧条款清除、可编辑 DOCX |
| J1-02 | 长报告排版 | 字体、段落、层级编号、图表题注 |
| J1-03 | PDF 台账录入 Word | 记录准确、表格与行高、原模板内容 |
| J1-04 | PDF 与 Excel 人员差异 | 删除 ID、字段变更、新旧值和类型 |
| J1-05 | 论文匿名化 | 作者/机构/身份标识清除，正文和自引保留 |
| J1-06 | 异构子表汇总 | 混凝土体积、总重及明细重量 |
| J1-07 | LBO 财务模型修复 | 业务公式关系、实际重算、非目标单元格保护 |
| J1-08 | PDF/Excel 人口收入联表 | 原生透视表、源数据、分组和聚合 |
| J1-09 | 库存补货预测 | 销售窗口、交期、安全库存和补货日期 |
| J1-10 | 流程图重建 PPT | 原生可编辑节点与连线、指定文本修改 |
| J1-11 | PPT 内嵌 Excel 汇率修改 | 正反汇率、原公式与其他内容保护 |
| J1-12 | Excel 数据追加到 PPT | 原生表格、折线图和内嵌数据一致 |
| J1-13 | 按 Word 要求修订 PPT | 页面布局、图片、字体和动画 |
| J1-14 | 发票应付控制包 | 授权证据、金额/日期、跨文件一致、离线草稿 |
| J1-15 | 配送税率跨文件更新 | 原生公式、配置明细、处理器变更回放 |
| J1-16 | 百份混合文件归档 | 100 篇 PDF + PPTX/DOCX 的内容分类和逐文件哈希 |
| J1-17 | 两项目采购修订与合并 | 三个独立会话、八项立即采购、延期和备选、真实产物溯源 |
| J1-18 | 品牌研究到联名方案 | 三个独立会话、研究/规则/方案、语义约束和真实产物溯源 |
18 个 case 共包含 22 个上游任务实例。每个目录的 case.json 记录固定来源、输入 URL/SHA256、对话、交付清单、判据和检查器来源。153 份输入已在初始配置时实际下载核验；材料和上游检查器运行时从固定来源获取并再次校验 SHA256，不提交大体积二进制材料或上游完整代码。J1-16 输入约 231 MiB；下载源不可用或字节变化会明确报准备错误。
前 16 个上游单任务改为“先核对与计划 → 用户确认执行 → 用户要求回读复核”的 MOI 多轮版本；原始请求保存在 instruction.txt。最后两个保留三任务链，任务间开新会话，通过上传前序真实产物显式传递材料，最终 source_lineage.json 必须与前序产物哈希一致。这是 MOI 回归改编，不宣称运行原 benchmark 的官方完整协议或产出可与其排行榜直接比较的分数。
验收保留上游逐条评分依据，并逐项报告业务检查。J1-02 的标题从原始报告读取，校验第一页位置及标题和摘要格式，其他格式仍沿用上游检查；J1-03 从实际 PDF 推导并核对每笔交易与余额，检查模板原有记录和 Word 表格；如果交付物包含期初余额行，也会核对其日期和金额；J1-06 按各子表的标签寻找实际数值并重算工作簿；J1-12 检查新表格、折线图及其嵌入工作簿是否覆盖输入的全部年份和指标；J1-14 核对四张发票的来源、决定和草稿，对可识别的 Word 表格检查跨文件一致性，并通过修改工作簿副本中的金额、阈值、阻断名单和到期日验证公式联动。这些 case 的上游原始判词也保留在 upstream_result.reference_upstream_result，但不作为适配检查的最终判定。J1-14 上游检查器可能因工作表布局提前退出，这种情况会在参考结果中标记，最终判定由适配检查给出。无法识别的表格布局会报验收器错误，不会当作通过。J1-08 将源 PDF 中明确包含的地区纳入有效值，并单独记录不适用的透视表检查；J1-09 对不需要补货的产品接受空白或 N/A 日期，仍逐项核对需要补货的日期，上游原判词和适配后的检查均保留。其他 OfficeVal 和 SkillsBench 检查使用固定版本的上游检查器。EvoCowork 检查全部业务单位和扣分；LBO 在验收副本中显式配置迭代计算，验证原始数据和变更驱动下的业务公式关系。Office 交付物先独立解析，再由 LibreOffice 实际打开并导出 PDF，渲染证据一并保存；验收容器使用 init 回收转换进程的子进程；转换工具崩溃或没有产出时标记验收器错误，不据此推断智能体失败。自动结构/渲染检查仍有视觉审美覆盖边界。外部链接仅检测可识别的危险目标，不判断远程网站本身是否安全。
π-Bench 额外使用同一模型在独立 Momo 会话中逐条语义评分，按 A2A 投影约定读取末尾的最终答复，过程文本继续完整留档，并要求通过项提供实际交付文件内的原文证据。语义评分仍可能有模型误判，完整判据、答卷、判词与评分会话 trace 都保留，便于复核。
验证在无网络、无 QA 凭据、只读输入/交付物、受 CPU/内存/进程限制的 Docker 内执行。J1-15 会执行智能体生成的处理器做回放；该代码不能在有 QA 凭据的宿主 runner 上执行。每次工作流只构建一次验收镜像，以 1 天有效的 judge-image-<run_id>-attempt-<n> artifact 分发给各 case；各 runner 校验镜像的哈希和代码版本后独立运行容器。镜像不包含 QA 凭据或 case 数据。
J2-01 在独立浏览器会话中登录 QA，使用 Momo 生成候选卡片，检查卡片和确认按钮，点击创建，读取新智能体，等 Momo 输出结束后进入其会话，并在流式回复结束后验证最终内容。两轮任务分别保存 QA 的 trace 和事件。测试完成后归档本次创建的会话及智能体；创建未确认时只清理能够验证身份的候选。模型生成仍存在随机性，测试会记录具体失败阶段，不能将单次失败直接归因于前端。
浏览器不保存登录态、完整页面、截图、Cookie、网络请求头或 Playwright trace 到公开 artifact；browser.jsonl 仅保存验收步骤和取证所需身份，HTTP 日志仅记录状态和耗时，不记录可能包含其他智能体配置或工作区成员信息的请求、响应正文。账号及密码只通过 qa environment 注入浏览器执行步骤。
J2-02 上传仓库中的合成图片，检查最终答复是否包含图片中的编号；运行前核验图片的 SHA-256，提示词和文件名不包含答案。J2-03 在同一独立会话中记录随机口令、追问、更新并再次追问，检查新旧口令；每轮各有 task、trace 和事件。两个用例使用真实 Agent API，无需浏览器账号，按最终答复中的关键事实判断，不要求整段措辞一致。输入图片被会话引用后，QA 的文件删除接口会拒绝删除；图片随归档会话保留在 QA，公开仓库保留合成原图。
J2-04 让 Momo 提出唯一名称的智能体候选，确认未提前发布；使用错误摘要请求取消，检查服务拒绝且候选未改变；再用正确摘要取消，回读取消状态并确认没有已发布智能体。失败时只清理能核对身份的本次候选。
J2-05 要求 Momo 联网搜索：检查真实搜索调用、返回的来源，以及答复是否引用了实际搜索结果或打开该结果后得到的地址；不固定搜索排名或整段措辞。搜索配额、授权等明确前置条件不足时标为 blocked；搜索结果被截断到无法核实来源时也标为 blocked。即使最终验收通过，过程中观察到的工具错误仍列在报告中。
J2-06 上传合成 CSV 表格，检查计算结果；被会话引用的输入文件会随归档会话保留在 QA。J2-07 要求智能体交付包含随机内容的文本文件，实际下载本轮任务的文件并检查内容；报告分别记录是否交付以及内容是否正确。
J2-08 通过追加对话修改尚未发布的候选，验证对象与其他配置保留、旧候选不可提交、新候选可发布。J2-09 验证创建时绑定 XLSX Skill 的精确资源引用和发布版本，再让新智能体实际调用该 Skill，下载工作簿并读取首张表的 A1。
仅在本次候选和成功发布记录的身份一致时归档智能体；如果无法确认对象归属，保留对象并在报告中标记清理未完成。
J2-10 上传两张合成图片，在同一会话中分别追问第二张和第一张的编号，检查识别结果和图片之间的区分。J2-11 检查不同会话的上下文隔离。J2-12 创建绑定联网工具的智能体，回读发布版本并验证它实际调用指定工具检索和引用来源。J2-13 要求执行指定的只读 SQL，核对实际执行记录、查询结果和最终答复；只答对数字但没有执行 SQL 不算通过。J2-14 在任务开始后请求取消，检查请求和最终状态；若任务在可观察的取消之前已经完成，标记 blocked。按请求取消在报告中单独统计，不当作异常结束或文件交付。
J2-15 创建并发布绑定 XLSX Skill 的智能体后追加修改描述，检查修订仍指向原对象、确认前无新发布版本，确认后读回新版本与指定描述，并检查原提示和技能等未修改的配置。J2-16 修改已发布智能体的资源绑定，检查移除 XLSX Skill、添加联网工具，以及其他配置保持不变。
J2-17 在任务完成后从指定事件序号重新订阅，核对续读的序号、原始内容和最终状态；这是已完成任务的事件回放，不代表已覆盖运行中断线恢复。
J2-18 和 J2-19 分别创建绑定 DOCX 和 PPTX Skill 的智能体，核对实际技能调用并下载 Word 或 PowerPoint 文件，检查文档正文或幻灯片文本中的指定标记；这不是对文件版式的完整验收。
J2-20 要求智能体使用网页打开工具访问固定版本的公开测试材料，验证指定 URL、工具返回内容和最终答复；明确的服务不可用或额度、授权问题标记为 blocked。
J2-21 要求智能体在沙箱中使用 Python 计算随机字符串的 SHA-256，将实际工具输出和最终回复与测试端独立计算的结果对照；无法确认执行内容时标记 blocked。
J2-22 要求智能体使用 PDF Skill 读取合成的两页 PDF，核对 Skill 调用和第二页的编号。
J2-23 在任务处于运行中时主动断开事件流，再通过同一 task ID 和游标续读，核对事件顺序、持久化事件和最终答复；不会重新发送请求。
J2-24 和 J2-25 使用相同内容的两份销售明细，分别验证不同名与同名附件能否在同一轮被独立上传并读取；检查文件 ID 和两份数据的合计。
J2-26 对本次会话执行重命名、置顶、归档和恢复，分别回读详情与列表，再在恢复后的同一会话中追问原有代号。J2-27 检查两轮消息的任务归属、内容、角色筛选和分页，并验证非法状态更新被拒绝且不会修改会话。J2-28 在取消运行中的任务后，验证同一会话能完成新的请求；来不及观察取消的情况仍标为 blocked。
J2-29 检查 JSON 答复能否解析，以及字段的值和类型。J2-30 创建同时绑定 XLSX 和 DOCX Skill 的智能体，检查候选与发布版本的两个绑定，再分别验证真实 Skill 调用和下载文件内容。J2-31 上传合成 JPEG 小票，检查智能体读取两个金额后的合计。J2-32 检查 Python 报错后继续调用；J2-33 检查工具自身返回非零状态后继续调用，两者都验证真实调用顺序和结果。J2-34 下载并核对本次任务的成果后删除，验证详情、解析和列表不再返回该成果。
J2-35 检查空消息被拒绝且不创建任务，之后同一会话仍可继续。J2-36 按产品的重新生成请求重跑上一轮，检查新旧任务、trace、运行快照和答复。J2-37 对本次答复提交反馈，核对无效目标拒绝、反馈回读与幂等性；本次测试反馈作为 QA 数据保留。
J2-38 在任务完成后请求取消，检查任务和原答复没有被覆盖，再继续原会话。J2-39 修改已发布智能体的指令，核对其余配置及新版本，再实际对话验证新指令生效。
J2-40 用仓库中的合成材料建立本次专用知识库，验证智能体绑定、实际检索和最终引用；会话及智能体归档后删除该知识库。入库未就绪时报告 blocked，并保留准备证据；任务状态未确认时保留智能体，任务、智能体或候选状态未确认时保留知识库及上传，报告框架错误。
J2-41 将合成 CSV 导入本次专用知识库的表，先独立核对实际行数和合计，再验证智能体的 SQL 查询、答复与引用。测试后按身份校验清理知识库及临时上传文件；无法核实查询证据时记为 blocked。
J2-42 检查知识库没有电话号码时，智能体检索并引用材料，JSON 字段明确表示缺失；暂不自动判断说明文字是否有矛盾。
J2-43/J2-44 使用每次独立创建的普通工作区数据库和合成数据，分别检查真实 SQL 查询，以及字段不存在时的错误反馈和同一会话后续查询。任务结束后核对资源身份及引用，再删除本次表和数据库；任务状态未确认时保留数据库。准备不可用记为 blocked，清理不确定记为框架错误。
J2-45/J2-46 测试对话临时选择单个、多个知识库，核对实际检索、简单答复和引用。J2-47 在真实页面选择两个知识库，检查发送范围、答复、来源展示、引用打开及后端检索引用。每个 case 使用并清理自己的合成知识库；任务状态未确认时保留资源并报告框架错误。
J2-48/J2-49 检查会话内切换知识库，以及在页面取消选择后消息确实不再携带被移除的知识库。J2-50 创建并发布绑定 A 的智能体，再改绑 B，核对候选、发布配置、实际检索与引用。
J2-51 检查负面反馈的评语、标签、评价筛选和重复提交。J2-52 检查工作区智能体列表、重复 ID 拒绝、禁用、恢复、未变配置及恢复后实际对话；J2-53 验证已取消候选不能发布。
J2-54 同轮读取图片和 CSV；J2-55/J2-56/J2-60 分别读取 DOCX 章节、XLSX 工作表、PPTX 幻灯片。J2-57 下载并解析生成的 PDF；J2-58 分别下载核对同轮交付的两个文本文件；J2-59 读取 ZIP 中指定目录的同名文件。
J2-61/J2-62 检查真实 A2UI 图表、表格事件、展示面关联、根布局可达性和数据。结构化答复按其事件验收，不要求存在普通文本答复；这里不验证页面视觉效果或交互按钮。
J2-63～J2-66 使用每次独立创建的自定义 Skill：检查内容修改、版本回退与冲突、启停、ZIP 包预检/导入/文件回读、重复绑定、失败批次原子性和删除保护，最后在已发布智能体的真实对话中验证使用。资源 ID 与显示名称不同；验收按实际 Skill ID 和工具调用结果定位，不要求模型复述固定解释文字。会话结束后归档本次智能体、解绑并删除本次 Skill；未确认的状态保留并报告清理错误。
J2-67 检查中性反馈及按本次答复隔离的统计与幂等性，避免并发用例互相影响统计。J2-68 在同一会话的不同轮次写入、读取沙箱文件，以独立计算的哈希核对实际工具输出，并检查第二轮没有重新写入。
J2-69 从真实 A2UI 问题中读取组件、选项值和答案路径，发送页面使用的提交消息，再验证后续任务更新原问题的结果；这里验证后端交互协议，不模拟浏览器点击。J2-70 单独验证页面手动创建智能体时包含 Skill 绑定的请求，以及发布后实际使用，和不带绑定覆盖的候选发布路径分开报告。
J2-71～J2-73 创建本次专用 HTTP 工具，验证修改、启停、发布绑定、重复绑定、无效绑定批次和删除保护，再要求智能体真实调用。J2-72 先得到 404，再调用另一个正常工具；报告保留并标记预期 HTTP 错误。工具只读取本仓库固定提交的公开合成资源，测试后只解绑、删除本次工具。
J2-74/J2-75 通过真实 A2UI 事件提交多选和文本答案，核对后续任务更新原组件。J2-76 检查不同智能体的会话列表与详情范围。J2-77 验证归档后历史保留、成果暂不可访问，恢复后原成果可重新下载且字节不变。J2-78 检查无效 ZIP、缺少 SKILL.md 的包在预检和导入时被拒绝，再正常导入并实际使用。实测与测试修订见工具与交互补充记录。
J2-79～J2-82 验证消息角色/ID、附件元数据、知识库选择的错误被明确拒绝且不创建任务；随后继续原会话。J2-82 只删除本次建立的知识库，再检查旧选择失效。J2-83/J2-84 真正发送不带文本的 CSV/图片消息，验证上一轮要求仍有效。J2-85/J2-86 在错误候选/工具定义被拒绝后，继续正常发布并实际对话/调用。首轮 QA 为 6 pass、2 fail：错误附件元数据和错误知识库选择返回 500，保留失败，详见输入边界实测。
J2-87～J2-102 继续覆盖损坏文件、附件引用、运行时成果大小限制、HTTP 工具参数、沙箱超时、SQL 语法、表单提交、候选并发/名称冲突、智能体包和归档恢复、引用打开、20 个内置 Skill 绑定后的加载、分页与过滤。J2-103～J2-105 分别实际调用 Bocha、Tavily、Brave；J2-106～J2-110 提供专用 Channel 的真实发送及回执/回读测试，缺配置明确 blocked，配置方式见单向 Channel 测试。
此前计划的 32 条均已实现并执行 QA 检查；完整结果及失败分析见本轮实测。功能边界和待核定能力见覆盖清单及逐项实施清单。当前仍为 coverage_status: incomplete，注册数量不等于已经验证 100% 功能。
公开仓库的原始事件可能包含智能体访问到的其他工作区文件或数据库信息；凭据扫描不能识别所有业务数据。运行用例的工作区应只包含允许公开的测试数据。
点开某个 cases (J1-XX) 或 cases (J2-XX) job，展开 Case result and failure details 步骤，可查看该 case 的结果、原因、耗时和逐轮 trace ID；同一份摘要也出现在运行的 Summary 中。若 runner 在生成报告前被终止或该步骤未执行，需查看出错步骤和总报告中的缺失结果。进入 Actions 本次运行底部的 Artifacts，下载 journey-run-<run_id>-attempt-<n>。每个 case 完成后也会上传 case-<case-id>-attempt-<n>，其中包含 case-summary.md 和详细证据，长任务尚未全部结束时可以下载已完成的证据。重跑时选择 Re-run all jobs；汇总只接收本次 attempt 的结果，防止旧结果覆盖新失败。证据包 保留 1 天；如需更久，在两个证据上传步骤中同步修改 retention-days。
统一包包含：
summary.json # 全批及每组的任务、交付、质量、耗时和错误统计
summary.csv # 每个 case 的状态、耗时、会话/trace ID 和工具错误
summary.md # 与 GitHub Summary 一致的报告
cases/J1-XX/
case-summary.md # 单个 case 的结果、原因、耗时和逐轮 trace ID
result.json # 框架/任务/交付/质量状态、逐轮 ID、耗时、工具统计及错误参数
publication.json # 公开包完整性；隔离文件的路径、哈希与原因
preparation.json # 输入与 oracle 的来源及哈希，或准备失败原因
dialogue.jsonl # 实际用户输入和附件引用
http.jsonl # 脱敏后的产品请求/响应和耗时
events.jsonl # 按 task ID + seq 记录公开任务事件
stream.jsonl # SSE 实时帧，先记录 task ID 再等待长任务
resubscribe.jsonl # J2-17 按事件序号续读时观察到的帧
tasks/<task_id>/
runtime.json # 最终运行时详情与 trace ID
a2a.json # 最后一次持久化 A2A 任务结果
artifacts/<conversation_id>/
inventory.json # 实际发布产物清单、文件 ID 和哈希
<artifact_id>-v<version>/ # 下载的产物
sessions/<session_id>/
reply.json # π-Bench 的规范最终答复，独立于过程文本
outputs/ # 解包后的实际交付文件
verification/ # 逐项判词、验证器日志和渲染 PDF
semantic-verdicts.json # π-Bench 独立语义评分
采集 QA 产品公开事件 API 返回的全部事件，包括可用的 thinking/推理片段、文本增量、工具调用、工具结果、生命周期和产物事件。服务端私有 rollout 不在公开 API 范围；某个模型没有输出 thinking 时不会伪造。公开事件序号可以因私有事件而有间隔，按 API 游标读取，不能以序号连续性判断遗漏。每轮结束和取消后再读取持久化事件；结果中明确记录 capture_complete。
工具统计按 task ID 和 call ID 合并调用与结果，避免将同一调用的传输错误和结果重复计数。失败调用包含工具名、参数、错误和事件序号；命令退出码、结构化错误以及 CLI 明确打印的错误均有记录。命令返回成功但输出包含错误时标为结果不明确，不伪称成功。缺少 call ID 的工具事件无法准确去重，单独计数、不计入调用次数；工具轮次按可关联的模型轮次统计，无法关联的调用单独列出；事件缺失时统计标为不完整。完整原文仍在 events.jsonl。
每轮展示 MOI 会话 ID、task ID 和 trace ID。QA 的公开事件接口会脱敏 Astra 运行时 session ID：接口提供可用值时记录，否则明确显示脱敏或未获取，不把 MOI 会话 ID 冒充 Astra session ID。
每个结果记录工作流 commit 和包含模型、超时配置的 case 规格 SHA-256。修改题目或验收器后的结果应按对应版本比较，不能用新判据倒推旧任务是否完成。
不把凭据放进提示词或材料，HTTP 认证头不写日志。文本记录脱敏；上传前扫描文件原始字节，并递归检查 ZIP/Office 内容。发现已知凭据、损坏或无法完整检查的 ZIP、分卷及符号链接会被隔离；publication.json 记录路径、哈希和原因，汇总报告显示隔离数量。扫描不能保证识别其他二进制文件中压缩或编码的敏感信息。原始任务判定保持不变，未隔离的 trace、事件和结果继续上传；受认证保护的 QA 文件引用仍在 inventory.json 中，可回 QA 诊断。公开仓库的 artifact 也应视为公开数据：本套只使用公开 benchmark 材料，请勿接入客户私有文件。会话归档后仍保留在 QA，输入文件和产物也保留供诊断；周期运行会占用 QA 存储，后续需根据保留策略清理这些专用工作区。
离线执行框架测试只依赖 Python 3.10+ 标准库：
python3 -m unittest discover -s tests -v
python3 -m journey.catalog plan journey-1
npm ci --ignore-scripts
npx playwright install chromium
npm run test:browserOffice 验收器的可编辑文件正反例在无网络 Docker 中运行，离线 CI 会自动执行。也可在构建验收镜像后执行：
docker run --rm --init --network=none --read-only --cap-drop=ALL --security-opt=no-new-privileges --memory=3g --cpus=2 --pids-limit=256 --tmpfs /tmp:rw,size=1g,mode=1777 --mount "type=bind,src=$PWD/tests_judge,dst=/tests_judge,readonly" --entrypoint python moi-journey-judge -m unittest discover -s /tests_judge -v完整任务需要 Docker 和 QA 凭据，从仓库外的私有来源注入 MOI_BASE_URL 与 MOI_PAT：
python3 -m journey.catalog prepare J1-01
# 从仓库根目录构建并执行
docker build -t moi-journey-judge -f judge/Dockerfile .
python3 -m journey.run_case J1-01
python3 -m journey.validate J1-01
python3 -m journey.report case J1-01
python3 -m journey.publish原 python3 -m journey.hello 冒烟入口及其测试仍保留，模型变量为 MOI_MODEL。
单独验证浏览器 case 时，从私有来源注入上述 QA API 和 UI secrets，再执行：
python3 -m journey.browser_case J2-01
python3 -m journey.report case J2-01
python3 -m journey.publish单独验证 API 功能 case 时，只需注入 MOI_BASE_URL 和 MOI_PAT：
python3 -m pip install -r requirements-functional.txt
python3 -m journey.catalog prepare J2-02
python3 -m journey.functional_case J2-02
python3 -m journey.report case J2-02
python3 -m journey.publishJ2-111 使用真实自定义业务 Skill 包，在同一个新智能体、同一会话内完成 10 个阶段、19 轮连续业务追问，并统一清理；当前共 112 条用例。该复杂场景总限时 15 分钟、单轮 5 分钟。详见业务 Skill 场景与验收。
J2-112 验证 Momo 通过自然语言创建绑定上传业务 Skill 的候选，确认发布后由新智能体实际检查员工数据源；员工来源、临时目录、Skill 和智能体绑定按本次资源身份清理。