智能体评测与评估体系调研：从共享底座到分层建设

版本：v1.1 更新日期：2026-11-15

摘要 #

结论。 A 选型（同一任务更换智能体或模型）与 B 迭代（agent、skill、prompt 版本对比并用轨迹定位问题）共享“任务集—执行轨迹—评分器—数据集与运行记录”的底层结构，平台层有明显工作流复用，但不构成可直接互换的同一套评测体系：决定成败的是数据总体、通过线、对照设计、统计单位与归因逻辑是否各自成立。四类评测应分层建设；选型成败在控制变量与统计设计，迭代成败在私有回归集与归因；轨迹是桥梁，但应结果优先、过程为辅。平台文档普遍覆盖开发期环节；线上评分与持续抽样的直接表述，本次来源中只见 AWS（持续抽样）与 Langfuse（线上自动评分）；MLflow 有生产监控章节但为 tracing 视角，Google 只提到从生产日志抽样（离线评估）；没有单一来源证明五环节（轨迹采集、评分器、数据集、评测运行、在线评测）端到端打通，统计等价更未获证明。

建议。 按“先结果后过程、先回归后能力、先私有后公开”推进：最小可行方案是一个版本化私有回归集、一个结果评分器、一条轨迹留存链路和一道 CI 门禁，先证明“没有退化”，再问“能否更强”。P0 即此四项；P1 为轨迹采集与适配层、judge 基线；人工校准若服务于 P0 的 judge 门禁，须随门禁同期上线，不延后至 P1（见 11.3）；P2 为在线采样、能力集与多 judge。凡承担选型或随机性门禁，统计置信须在该阶段即引入。

限制。 证据以厂商与项目自述为主，只能证明“声称具备”，不能证明准确率、成本或跨场景收益。未取得：目标 CLI（opencode、dsh、pi）适配证据、国内非厂商企业公开案例、独立第三方对“两类评测同平台”的量化收益对比、固定 harness 后模型差异归因的方法验证，以及部分工具许可与标准成熟度；均列为缺口，不以推断填补。

一、方法与证据口径 #

本报告以公开一手文档为主。主持人于 2026-11-15 实际打开页面并摘录原文；未运行平台或基准，也未保存页面快照。相对上一版（2026-11-13），有五处事实与证据口径需要更新或更正：DeepEval、Ragas 已取得直接来源；MLflow 的生产监控章节为 tracing 视角；OpenTelemetry 独立成仓属实但“迁出核心仓库”未见公告，降为待核；OpenAI 四环节串列属本文归纳；Google 的生产日志抽样属离线评估，不构成在线评测能力。

证据分四级：已核实（来源可读且摘录相符，只证明页面文字如此）、项目方主张（自述未独立验证）、判断（基于材料的推断）、未取得（本次未找到，不等于不存在）；另有页面表述（按项目方主张计）与部分核实。

二、两类场景与四类评测 #

2.1 四类评测的划分 #

划分标准是评测对象、决策用途、数据总体、接受阈值与统计单位，而非用了哪个工具。

迭代层含两条子线：能力评测探测上限、阈值宜宽，回归守住已承诺行为、接近全通过；共用版本对照方法，通过线不同（判断）。Anthropic 区分两类目标：能力问 “What can this agent do well?”，回归问 “Does the agent still handle all the tasks it used to?”（已核实，E01）。四类划分是本文按决策用途的综合（判断），不构成对任何厂商效果的独立验证。

2.2 A 与 B 的位置 #

A 主要是选型评测，比较完整智能体时还叠加 harness 维度；B 覆盖迭代层两条子线并接在线回流。共享底座的流向是：任务集→执行与轨迹采集→评分器→数据集与运行记录，由此分出选型、迭代回归与生产在线，在线抽样再把失败样本送回任务集。

底座共用不等于口径共用，四类评测在四处互不通用：数据总体（选型用代表业务分布的小规模私有集，回归用真实失败构造的版本化集合，在线用流量抽样）、通过线（选型看差异是否显著且值得切换，回归不许退化，能力评测允许大量失败）、对照设计（选型跨系统受控，回归同系统跨版本配对）、统计单位与归因（选型须处理 harness 与模型两因素及任务聚类，回归须固定评分器版本）（判断）。

2.3 “同平台”不等于“同体系” #

AWS 写明按需评估面向开发与 CI/CD、在线评估持续抽样线上轨迹，并称 “Because both modes use the same evaluators, what you test in CI/CD is what you monitor in production”（项目方主张，E04）。本报告将其概括为开发期与线上评估共用评估器（转述）。这证明产品能力与工作流复用，不能推出统计等价、阈值可迁移或跨场景可比；把“同一平台能跑两者”读成“同一套体系同时服务两者”，是本文要排除的主要概念滑坡。

三、选型评测：把 harness 与模型分开 #

3.1 两因素设计 #

选型至少做两组对照：同一模型跨 harness、同一 harness 跨模型。比较模型时固定 harness、工具集与权限、提示与上下文预算、沙箱镜像、温度与种子、超时与重试、网络条件，并记录模型与路由快照；比较完整智能体时保留各自配置，把差异记为“系统差异”，不归因到模型。Anthropic 的 “the harness and the model working together” 是直接依据（已核实，E01），但该文只支持两者不可分，固定项清单属方法判断。

3.2 重复试验与统计 #

单次测量不足以估计重复执行下的可靠性。τ-bench 以数据库终态判定成功并提出 pass^k；论文报告 gpt-4o 单次成功率不足 50%、零售 pass^8 不足 25%（已核实为论文特定实验，E14），数值不可外推，方法可借用（判断）：重复次数按最小可检测效应与统计功效确定；3 次仅为最低起点，关键选型通常需 5–8 次或更多。结果按任务配对，报告通过率、pass^k 或均值与 95% 置信区间，并用任务级聚类自助法估计。重复次数、最小业务差异与判定规则应在运行前固定，置信区间跨越门槛时转人工复核，不以追加运行凑显著性。有状态任务须在每次运行前恢复数据库、文件与外部服务基线，并核验遗留副作用；运行前恢复不能撤销已发出的消息，不可逆外部动作还须以工具权限、网络出口与服务替身加以约束。超时与崩溃应计入结果，不得择优重跑。

3.3 工具底座与证据缺口 #

Inspect 以 dataset、solver、scorer 三要素组织评测，可在沙箱运行 Claude Code、Codex CLI、Gemini CLI 等外部智能体，支持 Docker、Kubernetes、Modal（已核实，页面标注 2024-05 发布，E11）。OpenCompass 的 AgentCompass 解耦模型、基准、harness 与环境，支持 30 多个基准与 10 多个 harness，Apache-2.0（页面表述，E12）。二者可作控制变量的工程底座。

两个缺口必须写明：opencode、dsh、pi 无实际适配证据，不能就其可比性下结论；“固定 harness 后差异即模型差异”也无独立验证。前者待工程验证，后者待方法验证，都不应写成既成事实；本报告的选型结论都应读作“在该 harness 下”。

四、迭代回归：能力与回归两条线 #

4.1 目标与通过线 #

能力评测探测上限，阈值宜宽，题源可来自公开基准、合成题与专家设计；回归守住已承诺行为，接近全通过，题源主要来自真实失败、事故与工单。Anthropic 建议从 20–50 条取自真实失败的简单任务起步（“20-50 simple tasks drawn from real failures”，已核实，E01），但这是起点而非充分条件：样本是否覆盖高风险路径、评分器是否稳定，决定它能否当门禁。

4.2 CI 分级与版本对照 #

建议四层执行（判断）：PR 级 smoke 只跑高确定性、低耗时核心回归；夜间跑全量；发布前跑完整回归并出对比报告；上线后小流量 canary。CI 内部只分 smoke 与全量两级，发布前完整回归与上线 canary 另列。版本对比须同任务、同环境、同评分器版本；评分器变更时也要复核，否则分数变化无法归因。

4.3 私有集、回流与门禁定位 #

私有回归集应版本化，开发集与隐藏验收集分离，题目定期轮换并做污染探测，防止在评测集上调 prompt 或过拟合。skill、知识库与提示的变更也应作为版本变量纳入同一回归集，避免与执行框架变化混在一起。回流路径是：线上轨迹→筛选失败→脱敏复核→标注→进入回归集，并保留来源、版本与删除机制。门禁定位须分清：回归集适合作常规质量门禁，能力集适合发布说明与选型、不宜设为阻断线，新能力上线前的安全与能力验收另设专门门禁（判断）。

五、轨迹评测：结果优先，过程为辅 #

Anthropic 主张 “it's often better to grade what the agent produced, not the path it took”（已核实，E01），这与微软 Foundry 的步骤比对形成张力：后者分系统与过程两层，其中 Task Navigation Efficiency 以期望工具序列比对工具调用是否高效，匹配含精确、按序与任意序（已核实，E05）。二者不矛盾，差别在优先级（判断）。

• 确定性轨迹匹配：按消息与工具调用序列比对，LangChain 的 agentevals 包提供严格、无序、子集、超集模式，确定、可复现（已核实，E07；该页介绍的是开源包，速度快、成本低属判断）。适合合规、协议步骤与必须调用的工具，不适合多正解的开放任务，容易把有效路径判错。
• LLM judge：更灵活但更不确定，适合语义质量与开放式结果；须配 rubric、盲化候选身份、交换顺序，并以人工标注校准。
• 人工标注：建立金标准、处理歧义与争议样本，成本最高，应抽样使用。

步数、冗余调用、工具错误率、时延与 token 成本宜作诊断指标与预算约束；只有安全、合规以及契约或协议要求的工具调用才作硬性通过条件（判断）。安全硬条件须具体化：越权访问、数据泄露与被禁止的外部副作用一经确认即判失败，不由成功率或均分抵消，确认由确定性规则或人工复核作出。轨迹差异只产生根因假设，还须回放或消融验证。被测智能体与评分器应隔离权限，以降低轨迹对 judge 的提示注入风险；评分在脱敏派生副本上进行，受控原始证据留存备查，但隔离与过滤不能证明评分器不会被操纵。judge 校准样本应覆盖恶意工具输出、伪造评分指令与敏感信息诱导。

六、平台与工具生态 #

6.1 平台能力与 A/B 需求（治理为一级约束） #

评级为判断。治理不是与其他四项并列的第五类能力，而是横贯四类评测的一级约束（判断）。表中单列一行只为对照阅读。缺少版本、权限与成本约束，评测集会随版本漂移失去可比性。

6.2 商业平台：五个环节与逐家证据 #

本文把“轨迹采集、评分器、数据集、评测运行、在线评测”称为五个环节，这一归纳来自多家产品文档的共性（判断），不是任何厂商的原始分类。逐家看，可证实的环节不同。OpenAI 以轨迹、评分器、数据集与评测运行组织工作流：轨迹记录单次运行的模型与工具调用、护栏与交接，页面写明从单条轨迹走向可重复的数据集与评测；轨迹评分用于比较变更、发现回归（项目方主张，E02、E03；串列为本文归纳）。微软 Foundry 分系统与过程两层，部分评估器仍标 preview（已核实，E05）。Google Vertex AI 支持智能体专用指标、跨厂商头对头、重跑闭环与按提示动态生成的 pass/fail 量表（已核实，E06）。百炼支持智能体与工作流评测、自动评估器与人工标签，每任务最多 10 个评估器，轨迹示例标 ATIF-v1.8、单条不超过 1 MB（页面表述，E18）。

在线环节须逐家区分。AWS 明确持续抽样线上轨迹并面向 CI/CD（已核实，E04），页面虽提及构建与整理测试数据集，却未描述数据集管理能力或运行记录；Langfuse 明确自动评分线上轨迹并支持数据集、实验与并排比较，但无抽样字样（页面表述，E08）；MLflow 有生产监控章节但为 tracing 视角，未取得线上自动评分或抽样表述（页面表述，E10）；OpenAI、微软与百炼的本次来源未涉及在线环节；Google 页面提到可从生产日志抽样评估，属对已有日志的离线评估，未描述线上实时评分或持续监控，不能据此认定其具备在线评估能力。

共性在于复用轨迹、评分器、数据集与运行记录（判断）。差异属产品定位，不等于能力高低，也无独立效果数据可比。厂商自述不能证明跨平台可比性、评分器与人工的一致性、离线与在线的统计等价与投入产出比；绑定专有格式还会带来迁移锁定。没有单一来源同时证明五环节端到端打通。

6.3 工具生态的分类 #

本节含开源项目、商业产品与托管服务，许可与部署须逐项核对，表中只填已核对者，未核对者如实标注。

依据（页面表述或已核实的页面自述，均不证明效果）：SWE-bench 用真实 issue 与 Docker 复现，Verified 为 500 个工程师确认可解的问题（已核实，E13）；AgentBench 覆盖 8 类环境（已核实，E15）；Terminal-Bench 在沙箱终端评测，beta 约 100 任务（已核实，E16）；OpenAI Evals 为 MIT 框架与开源注册表，提供 Completion Function Protocol（已核实，E17）；DeepEval 提供工具正确性、完整轨迹评测、合成数据与 CI 集成（页面表述，E21）；Ragas 提供 RAG 指标与测试集生成（页面表述，E22）；LangSmith 定价页列免费层、按成员收费与企业方案，未称开源（已核实，E23）。Langfuse、Phoenix、MLflow 的定位与限制见表行，其许可与版本未逐一确认（E08、E09、E10）；DeepEval、Ragas 未运行验证。

6.4 国内实践 #

可核实三类：百炼提供评测集与轨迹评测（页面表述，E18）；OpenCompass/AgentCompass 提供开源评测平台（Apache-2.0，页面表述）；中国信通院 2026 年启动智能体安全系列评测，覆盖场景任务类安全、行业任务类安全、应用安全保障能力与应用安全成熟度四维度（已核实，E19），但未取得方法细则与结果。国内非厂商企业的公开建设案例未取得，报告不写“不存在”，只记为缺口。

七、标准与互操作 #

OpenTelemetry GenAI 语义约定仓库定义生成式 AI 的 spans、metrics 与 events，并覆盖 MCP 与厂商特定约定（部分核实，E20）。独立成仓属实，但“原页面已迁出核心仓库”未见公告，智能体与工具的命名及成熟状态也未见声明，均列为待核。它是最有潜力的跨平台采集底座（判断），前提是字段成熟度确认。ATIF-v1.8 只见于百炼的轨迹示例，不能认定公开标准，其 1 MB 限制是产品约束。对企业的含义：以 OTel 作采集与导出底座（判断），自建轨迹适配层，在受限存储保留原始 JSON 并设保留期限，删除要求覆盖派生的回归副本与导出副本，字段与 schema 版本化；不把私有格式硬编码为标准，不在成熟度未明时写死字段名。

八、质量陷阱与校准 #

重复试验的必要性有 τ-bench 方法支持，具体通过率不可外推（E14）。不校准 judge 就当发布门禁是企业常见的技术债（判断）；校准须按场景分别做。若 P0 的结果评分器是 judge，人工校准必须与门禁同时上线。

九、组织与工程 #

所有权三分：中央平台团队负责 harness、轨迹 schema、评分器框架与运行环境；领域团队负责业务任务、阈值与标注；安全与数据治理负责权限、敏感数据与回流审核；门禁由 release owner 签字。评测即代码：数据集与评分器纳入版本管理，配置与镜像记录版本与摘要；受控数据以受控存储中的版本引用纳入。

从 0 到 1 的最小配置约 2 名专职人员（评测负责人与平台工程师）加领域专家兼任（判断），视领域数量与标注量。先用最小配置（一个 harness、一个轨迹存储、人工复核）跑通闭环。生产抽样比例可按流量与成本取 1%–5%（判断），并按风险分级：写操作、权限变更与工具报错提高覆盖率；需按业务校准，不是行业标准。

十、趋势判断 #

判断是：已有平台在能力、回归与在线评测之间复用评估器与工作流，统计口径仍须分别验证。支持面是 AWS 写明两种模式共用评估器并持续抽样（E04），Langfuse 支持线上自动评分（E08），MLflow 有生产监控章节（E10，tracing 视角）；但没有单一来源证明五环节打通。该判断的边界与潜在反证有五项：只有第 1 项直接检验统计等价；第 3 项只影响回放条件与对照可行性，不改变判准：

1. 同一评分器与阈值在离线、在线及跨 harness 长期保持同等精确率与召回率，无需重校准；
2. 公开基准排名与私有选型排名高度相关；
3. 生产样本因权限或脱敏无法可靠回放，离线与在线被迫割裂；
4. 企业采购持续把可观测与评测分开招标；
5. judge 成本使在线全量评分不可行，只能抽样告警。

第 2–5 项分别涉及排名相关性、回放条件、采购行为与成本约束，均不能单独推翻工作流复用；这些观察缺独立量化证据，故“同一体系”仍属产品叙事而非已验证事实。

十一、企业建设路线 #

11.1 三阶段路线与季度校准 #

规划期：按四类评测明确用途、owner 与通过线；盘点任务、轨迹与数据；决定买或建；用 2–4 周小规模试点；先建回归集，不追排行榜。实施期：结果评测优先，从 20–50 条真实失败任务起步；选型做两因素对照与重复试验；接入 OTel 轨迹与适配层；judge 与人工做一致性校准；CI 内再分 smoke 与全量两级（见 4.2 节）。应用期：发布门禁、季度基准刷新、生产采样、事故转任务、成本与权限治理、失败回滚。季度校准与题目轮换是循环项，把失败样本送回实施期，避免评测集随版本漂移失效。

11.2 常见失败与禁止项 #

常见失败：把排行榜当选型结论、跨 harness 直接比模型、用未校准 judge 卡发布、用单次结果定选型、在评测集上调 prompt、把厂商自述当验收。禁止项：不做无版本管理的评测集、不做无对照的单版本对比、不把探索性能力分设为发布线（见 4.3 节）。

11.3 优先级与门禁顺序 #

P0 为私有回归集、结果评分器、轨迹留存（先按现有 harness 的原始记录留档）和一道 CI 门禁。P1 为 OTel 采集与适配层、judge 基线（若 P0 评分器为 judge，人工校准随门禁同期，不列入 P1）。P2 为在线采样、能力评测集与多 judge。凡承担选型或随机性门禁，统计置信须在该阶段即引入，不能推迟到 P2。先做能证明“没有退化”的部分，再做“能否更强”的部分。门禁硬约束：安全硬失败必须直接阻断发布，不由成功率或均分抵消；安全检查未完成或无法判定（超时、崩溃、轨迹缺失）即暂停放行，不静默通过，由 release owner 裁决并留痕；若 P0 的评分器是 judge，人工校准须同期完成。20–50 条起步集通常覆盖不到低频高损安全事件，安全验收仍靠专门门禁与执行时权限检查，生产抽样不能替代。违规与泄露检查宜用确定性规则前置，judge 用于语义质量与抽样复核（判断）。

十二、未决分歧与证据缺口 #

以下分歧未整体采纳为主干表述（个别仅部分采纳），缺证据的事项一并列明，供读者判断；它们不影响前文的建设顺序。

术语：一套基础设施，还是“同一体系”。 有意见认为 A 与 B 可称“同一体系”，前提是只共享底座、不共用口径。本报告未采用：“体系”兼指设施与口径两层，易被读成“口径可互换”。本报告的定义是“一套基础设施、四类口径”，分歧属命名而非实质；全文“同一套评测体系”均指口径层。

过程约束的边界。 有意见主张过程指标应一律作软约束，不得设为硬性阻断。本报告部分采纳：常规过程指标只作诊断与预算约束，仅安全、合规以及契约或协议要求的工具调用三类作硬条件（判断）；并保留该意见的警告：过度精确的轨迹匹配会惩罚有效的替代解法。

选型归因的有效性。 “固定 harness 后差异即模型差异”没有独立验证。本报告据此把选型结论限定在具体 harness 下，但该限定本身仍是未闭环的方法问题。

统计等价的边界。 同一评分器跨离线、在线与跨 harness 是否同等判准，没有证据。引用厂商“共用评估器”应停在“工作流复用”，不能延伸为阈值可迁移。

算力与复现成本。 有建议主张加入沙箱瞬时重建与上下文缓存基线，并以“确定性规则初筛→judge 抽检→人工复核”三级漏斗控制算力。粗粒度漏斗已体现在第八节的成本一行，细粒度策略与沙箱、缓存基线未验证，留待后续版本。

回流合规替代。 有意见主张只提取失败模式、以合成任务入集。本报告将其列为补充选项：合成可降低真实数据暴露，但不消除删除义务与敏感残留风险，也不能替代对原失败机制的验证。

证据缺口。 opencode、dsh、pi 的适配证据；跨 harness 的排序稳定性；国内非厂商企业公开案例；第三方对“两类评测同平台”的量化收益对比；Langfuse、Phoenix、MLflow 的许可与版本；OTel 智能体 span 的命名与成熟度；信通院安全评测的方法细则，以及行业媒体提及的“评估体系 2.0”官方原文。这些是下一阶段应补齐的实证，不是可略过的注脚。

十三、结论 #

两类场景应建在同一套评测基础设施上，但必须保留四套口径：平台层收敛值得利用，统计层等价不能假设。先建可复现的私有回归集与结果评分器，再补轨迹诊断与在线采样，是风险最低、也最易验证的路径；排行榜、单次结果与未校准的 judge 不足以支撑选型或发布决策。目标 CLI 适配证据、国内案例、归因方法验证与标准细节仍未取得，应作为下一阶段的实证任务，而非结论的前提。

附录 A：参考来源 #

正文中的 E 编号与下列条目一一对应。

1. E01 Anthropic Engineering, “Demystifying evals for AI agents”, 2026-01-09. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
2. E02 OpenAI API Docs, “Agent evals”, 页面未标注日期，2026-11-15 访问. https://developers.openai.com/api/docs/guides/agent-evals
3. E03 OpenAI API Docs, “Trace grading”, 页面未标注日期，2026-11-15 访问. https://developers.openai.com/api/docs/guides/trace-grading
4. E04 AWS Machine Learning Blog, “Build reliable AI agents with Amazon Bedrock AgentCore Evaluations”, 2026-03-31. https://aws.amazon.com/blogs/machine-learning/build-reliable-ai-agents-with-amazon-bedrock-agentcore-evaluations/
5. E05 Microsoft Learn, “Agent Evaluators for Generative AI - Microsoft Foundry”, ms.date 2026-09-30, updated 2026-10-08. https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators
6. E06 Google Cloud Vertex AI Docs, “Evaluation overview”, 页面未标注日期，2026-11-15 访问. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview
7. E07 LangChain Docs, “Evaluate agent trajectory”, 页面未标注日期，2026-11-15 访问. https://docs.langchain.com/langsmith/trajectory-evals
8. E08 Langfuse Docs, “Evaluation overview”, 页面未标注日期，2026-11-15 访问. https://langfuse.com/docs/evaluation/overview
9. E09 Arize Phoenix Docs, 页面未标注日期，2026-11-15 访问. https://arize.com/docs/phoenix
10. E10 MLflow Docs, “LLM and Agent Evaluation”, © 2025. https://mlflow.org/docs/latest/genai/eval-monitor/
11. E11 Inspect Docs, 页面标注 “Released May”（2024-05）. https://inspect.aisi.org.uk/ ；仓库 https://github.com/UKGovernmentBEIS/inspect_ai
12. E12 OpenCompass GitHub 仓库, “What's New” 2026-09-30. https://github.com/open-compass/opencompass
13. E13 SWE-bench GitHub 仓库, README 最新条目 2026-09-01. https://github.com/SWE-bench/SWE-bench
14. E14 τ-bench, arXiv:2406.12045, 2024-06-17. https://arxiv.org/abs/2406.12045
15. E15 AgentBench GitHub 仓库, ICLR 2024. https://github.com/THUDM/AgentBench
16. E16 Terminal-Bench GitHub 仓库, beta 期约 100 任务. https://github.com/laude-institute/terminal-bench
17. E17 OpenAI Evals GitHub 仓库, © 2026. https://github.com/openai/evals
18. E18 阿里云帮助中心（百炼），“评测任务”“添加轨迹评测数据”, 页面未给出具体更新日期，2026-11-15 访问. https://help.aliyun.com/zh/model-studio/agenteval-evaluation-task ；https://help.aliyun.com/zh/model-studio/agenteval-evaluation-set-trajectory-data
19. E19 中国信通院 AI Hub, 2026 年智能体安全系列评测. https://aihub.caict.ac.cn/docs/6YLKEY9XztYo
20. E20 OpenTelemetry GenAI Semantic Conventions GitHub 仓库, 2026-11-15 访问. https://github.com/open-telemetry/semantic-conventions-genai
21. E21 DeepEval GitHub 仓库（confident-ai/deepeval），2026-11-15 访问. https://github.com/confident-ai/deepeval
22. E22 Ragas GitHub 仓库（explodinggradients/ragas），2026-11-15 访问. https://github.com/explodinggradients/ragas
23. E23 LangChain Pricing, 2026-11-15 访问. https://www.langchain.com/pricing

附录 B：缩写 #

• agent：智能体，本文指模型与执行框架（harness）的组合。
• harness：执行框架，负责工具调用、上下文管理、沙箱与环境交互。
• CI/CD：持续集成与持续交付。
• LLM judge：以大语言模型作为评分器的评估方法。
• pass^k：同一任务重复 k 次全部成功的概率，用于衡量可靠性。
• P0/P1/P2：本报告的建设优先级；P0 为最小可行项，P1 为增强项，P2 为扩展项。
• release owner：发布责任人，负责门禁裁决与放行签字。
• OTel：OpenTelemetry，跨平台可观测数据规范。
• ATIF：阿里云百炼轨迹数据示例中出现的 schema 版本标识，本文不认定其为公开标准。