experiment-analyzer

合并拉取请求 #113，来自 tillwf/revert-judge-hill-climb-delegation 回退爬山委托及其留出集发布门禁

回退“将评判者爬山委托给 auto-experiment” 本次回退提交 6a89a7dddea112dd03d8d6db575f938f1ca11adb。

回退“以留出集而非拟合分数作为发布门禁” 本次回退提交 f0febd98342a2feae7bdd6d71ce9c9c7af431630。

合并拉取请求 #109，来自 tillwf/till.wohlfarth/auto-labelling-skill 添加 agent-observability-build-eval-from-annotations 技能

以留出集而非拟合分数作为发布门禁 在一个真实的 89 行队列上端到端运行了委托循环。第 1 次迭代在 |t| = 11.70 时将拟合 F1 从 0.255 提升到 0.485——这是本次运行中最确信的结果，轻松超过显著性阈值和 min_delta——但在留出集上得分为 0.000，没有捕获其三个正例中的任何一个。来自更早一次运行的对照评判者在相同行、通过相同测试框架上得分为 0.667，因此测试框架是可靠的，评判者只是过拟合了 7 个训练正例。 发布门禁说“永远不要超过常量类基线”，却没有指明划分，这会让那个评判者得以发布。现在它指明了留出集，并补充了本次运行也遇到的情况：新评判者比已部署的评估器更差，而写入是完全替换且没有版本历史，因此发布它会静默销毁一个更好的评估器。 Co-Authored-By: Claude Opus 5

将评判者爬山委托给 auto-experiment build-eval-from-annotations 和 auto-experiment 运行相同的循环——基线、统计错误、一次聚焦变更、重新评分、保留改进的部分——但作用于不同的对象，而 build-eval 是通过重述该循环而非复用它来实现的。它的副本是较弱的那个：`runs` 和 `min_delta` 从未从实测噪声中推导出来，花费之前没有成本估算，没有逐迭代报告，且统计是非正式的。PR #108 通过教 auto-experiment 读取标注队列，弥合了剩余的大部分差距，这几乎逐行重复了本技能的第 1 阶段。 因此 build-eval 现在只保留真正属于它自己的部分——评判者的用途、它可以看什么，以及发布获胜者——并将循环移交出去。SKILL.md 减少了约 200 行：后端规则、保留/丢弃策略、机制审计、停止条件和统计都移到它们的唯一来源，评分标准指向 auto-experiment 的 `_noise_policy` 和 `_mechanism_audit`，而不是保留一份会与循环所遵循的版本产生偏差的副本。 有两项变更使 auto-experiment 可以这样被驱动： - 调用方可以提供测试框架（`harness_provided_by`）。第 2 步根据 stdout 契约验证它，而不是生成一个，如果不合规就 STOP——静默替换为模板测试框架会测量到与调用方要求不同的东西。 - `mean` 是运行在配置指标下的分数；行平均值是默认值，而非定义。某个类上的 F1、macro-F1 和 kappa 是在整个运行的混淆矩阵上计算的，无法从行平均值恢复。 第二点不是技术细节。在一个真实的 55/7 语料上拟合评分器产生了一个候选，其准确率为 0.855，增加了 14 行，丢失了 3 行，并且是十一次迭代中唯一统计显著的变化——同时没有捕获七个已知错误中的任何一个。关于它的每个数字都是真实的，而评判者只是个橡皮图章。一个以行平均准确率爬山为门禁的循环正是朝这个方向爬，因此评分标准现在要求在任何用户选择的头条指标旁附上常量类下限。 `references/judge_harness_template.py` 就是该测试框架：它每一轮都重新读取正在优化的提示，在语料上运行评判者 `runs` 次，并输出约定的指标。已针对 89 行队列验证——3 次运行的均值为 0.564，标准差为 0.026，复现了旧多数投票路径测得的 0.545 留出集 F1，并最终给出了 `min_delta` 所需的运行间波动。 两个文件都明确说明了所放弃的东西：独立的完整重跑没有逐行多数，而 McNemar 需要配对行，因此两者都被移除，替换为均值 +/- 标准差和双样本 t 检验。对于这些数据，McNemar 是更强的检验。这是用统计功效换取在一个地方维护的循环，是真实的取舍。 build-eval 不再独立运行；SKILL.md 和 README 都这样说明，如果 auto-experiment 缺失，它会 STOP 而不是临时拼凑一个循环。 Co-Authored-By: Claude Opus 5

重命名为 build-eval-from-annotations，并使其适配真实队列 该技能曾针对一种队列形态验证：在 `type: trace` 内容上的单个布尔标签，带有评审者推理文本，位于一个有实时生产 span 的应用中。在第二个队列上运行它——89 行、三个必需的分类标签、`type: experiment_trace`、无推理文本、一个仅作为实验运行的应用——打破了这五个假设中的四个，这里的一切都来自让那次运行成功。 `auto-labelling` 描述的是机制而非交付物，因此该技能现在叫 `agent-observability-build-eval-from-annotations`，它说明了输入什么、输出什么。状态目录随之改变（`.build_eval_from_annotations/`）。旧的触发短语保留为别名。 判定契约：`reasoning` 和 `confidence` 现在是默认字段，在本地和已发布的评估器中都是如此。置信度是百分比——0-100 的整数，绝不是 0-1 的概率——被报告并针对正确性进行校准，绝不用于决策。`87.5` 会四舍五入；`0.9` 被标记为有歧义，而不是静默提升为 90；缺失或格式错误的置信度保留其标签，而不是使该次通过作废。 超越布尔 trace 标签的队列形态： - `experiment_trace` 内容需要解析器，而不是 span 遍历。记录了文档化的端点，包括其两种失败中哪一种意味着“内容已过期”——这种情况会在运行花费语料逐行发现它之前就结束运行。 - 分类值是列表，行可以是多选。比较现在是无序集合相等，因此 `["a","b"]` 和 `["b","a"]` 是一个答案，而不是一个同时分裂多数投票的分歧。部分得分可用（jaccard、相似度分组），但仅来自用户提供的分类体系。 - 每个队列多个标签：询问是拟合一个联合评判者还是每个标签一个，并用 `--label-field` 对联合判定评分。 - `f1_minority` 拒绝超过两个类的语料，而不是悄悄把最稀有的类设为正例。 真实标注变得更严格。数据集的 `expected_output` 不是它：在一个真实批次中，一行输出和 expected_output 完全相同，却被评审者在三个标签中的两个上判为失败。只有人类值才是真实标注，而先前模型对同一标签的预测在复现器运行中是泄漏。 运行器修复，全部由运行它发现： - `PAYLOAD_TEMPLATE.format()` 崩溃并报 `KeyError: '"label"'`——一个 JSON 示例给格式字符串添加了字面大括号。每次评判者运行都会在第一行就死掉。 - 未安装 `anthropic` SDK 时，运行器每轮通过 `claude -p` 生成一个 Node 进程；操作系统直接杀掉了两次迭代。现在当存在密钥时它优先使用标准库 HTTPS 调用，这也将一次迭代从 11 分钟缩短到 90 秒。 - 较新的模型直接拒绝 `temperature`，因此请求确定性并回退，同时记录该运行因此未固定。 循环默认值：10 次迭代，并在连续 3 次迭代比最佳更差后停止——以点估计衡量，因为在这些语料规模下显著性不可达，等待它意味着永不停止。保留但在噪声范围内的增益会重置计数器；未测量的迭代既不重置也不推进它。 最后，运行结束时打印评估器的名称和 Evaluations URL。`enabled: false` 是已禁用的评估器，不是 Datadog 草稿，该技能不再称其为草稿——写入是完全替换，因此重新发布后续迭代会覆盖较早的配置，且组织中没有历史记录。 Co-Authored-By: Claude Opus 5

注意评估器写入限制是分阶段推出，而非能力缺失 使用相同载荷的相同调用在 us5 生产组织上被接受，而在 datad0g.com 上被拒绝，因此“有版本、在 UI 中编辑”的拒绝是该站点在推出中的位置，而不是 API 缺少什么。Staging 领先运行，因此应预期该拒绝会扩散而非消失，UI 回退是早期而非死代码。 探测确定了这一点：在生产上创建了一个指向不存在 ml_app 的已禁用一次性评估器，读回，删除，并确认已消失。 Co-Authored-By: Claude Opus 5

处理拒绝通过 API 创建评估器的站点 针对 datad0g.com 运行第 8 阶段时遇到了该技能无法回答的一堵墙：`create_or_update_llmobs_evaluator` 返回 400 “custom evaluator is versioned and can only be edited from the LLM Observability UI”——对于一个尚不存在的名称，以及任何其他名称都是如此，因此那里根本无法通过 API 创建。用之前的文本，运行会以它现在承诺的交付物不可能实现而告终。 因此当这种情况发生时，该技能以另一种方式兑现承诺：验证没有部分内容落地，将完整配置写入 `.auto_labelling/evaluator_config.json`，准备好粘贴到 Evaluations -> New Evaluator，并报告“未创建评估器，因为此站点上 API 拒绝；这里是可用于 UI 的配置”。这是一个指明了阻碍的已交付回退，而不是一个悄悄消失的步骤。 该次运行还确立了两件事： - 写入时 `output_schema` 必须是裸 JSON Schema。`get_llmobs_evaluator` 返回的 `{name, schema, strict}` 包装会被拒绝为 `invalid BYOP output schema`，因此读取不能在不解包的情况下往返为写入。 - 评判者提供方必须来自组织实际能调用的东西。`integration_provider` 枚举并未覆盖真实评估器使用的每个提供方，而且组织可能持有一个已配置但损坏的集成——有一个从另一个评估器的错误字段内部返回 401。读取一个现有评估器，并将选择交给用户，而不是猜测一个组织无法触及的模型。 Co-Authored-By: Claude Opus 5

让评估器成为交付物，而非可选的最后一步 第 8 阶段曾是“发布，仅在明确同意时”，这让运行可以以磁盘上的报告和提示文件告终。没人能运行那个：拟合好的评判者只有在作为用户能打开、审查并启用的评估器存在后才有用。 因此现在每次运行都以创建它结束，问题也随之改变：名称和目标与用户确认，创建则不需要。它仍然总是以 `enabled: false` 写入——开启它仍是用户的选择，在 UI 中，以他们选择的任何采样率。 验证也随之改变。一次成功但未出现在 `list_llmobs_evals_by_ml_app` 中的写入尚未交付，因为该列表是 Evaluations 页面的支撑，所以检查是列表加读回，运行报告 URL 和要查找的 eval_name。还记录了运行该技能时发现的 trace 作用域 span 选择器模板语法（`{{spans[meta.span.kind:llm]...}}`），并将报告的头条指标固定为可部署分数而非拟合分数。 没有评估器而结束仍然是合理的——标签太少、评判者从未超过常量类基线、证据没有 eval_scope 能触及——但现在它被报告为一次失败的运行并指明阻碍，而不是一个悄悄未发生的步骤。 Co-Authored-By: Claude Opus 5

添加 agent-observability-auto-labelling 技能 通过测量而非检查，将 LLM 评判者评估器拟合到已存在于标注队列中的人类标签。 该循环镜像 agent-observability-auto-experiment，以评判者作为被优化的对象而非应用，以人类标签作为真实标注而非评分标准：读取队列，弄清被标注属性实际位于 trace 中的何处，起草一个评判者，用与用户约定的指标针对已标注行评分，读取其错误，改变一件事，重新评分，只保留改进的部分。将获胜者发布为已禁用的评估器草稿，绝不启用，也绝不将预测写回队列。 由针对一个真实 staging 队列的运行塑造（13 个已标注行、布尔标签、12-span trace）： - 第 2 阶段存在是因为被标注属性在已标注 trace 内根本无法判定——绑定的用户反馈是在会话更早的轮次中给出的。证据映射是运行对数据点是什么的契约，必须在任何评判之前针对标签验证。 - 拟合评判者与可发布评估器之间的差距是一等公民：托管提示模板在单个 trace 内解析 span 选择器，因此基于跨轮次证据拟合的评判者必须针对已部署评估器实际会看到的内容重新评分。在那次运行中：拟合 F1 为 1.000，可部署为 0.800。 - 保留决策使用点估计加机制审计；McNemar 只标注置信度。在 13 行时没有任何显著，因此以显著性为门禁意味着永不移动，而少数类召回检查是阻止评判者漂向多数类的东西。 references/judge_runner.py 每行运行评判者 N 次，采用严格的 JSON 契约；references/scoring.py 计算指标、混淆矩阵、Wilson CI、翻转率和 McNemar，仅用标准库。rubrics.md 保存不可弯曲的规则：标签是真实标注，禁止泄漏，无法解析的计入而非强制转换，发布受门禁。 Co-Authored-By: Claude Opus 5

合并拉取请求 #108，来自 tillwf/till.wohlfarth/auto-experiment-datadog-datasets auto-experiment：将评估语料存储在 Datadog Datasets 中，并从标注队列加载

添加 dd-orchestrator 技能（#111） * 添加 dd-orchestrator 技能 * 修复 dd-orchestrator 审查发现：分派门禁、遥测断路器、获取隔离、trace 框架 解决 PR 审查中提出的 8 个正确性/可靠性问题： - resolve.py：未解决的 CHOICE_POINT 现在即使存在部分计划也会设置 STOP_REASON=awaiting_choice，因此没有产品会在分派门禁处被静默丢弃（例如没有平台的 "rum,apm" 不再报告 STOP_REASON=none）。 - emit.py：遥测断路器现在能约束持续宕机的接收端。关键（resolve-core）事件仅在达到 3 次失败阈值之前绕过已打开的断路器，而终端 HTTP 失败（4xx/5xx/429）与传输失败触发相同的断路器——此前 503 会为每个事件无限重试 3 次，关键事件永不停止，为每个计划节点增加一次超时。 - fetch_skill.py：每次获取使用新的运行作用域临时目录，因此部分或较旧的获取不会留下陈旧文件被执行，并发获取也不会交错。 - resolve.py：--trace 不再打印重复的无框架 "SESSION ID:" 行，因此 trace 是单个机器可读块；SUGGESTED 增强（例如云连接器）现在显示在该块内。 - SKILL.md：移除无依据的 "[Subset: ...]" 批准选项（没有解析器遍历会重新规划依赖安全的子集）；记录 dd-account-setup 作为唯一的确认门禁预检例外；将云连接改写为可选建议（它在目录中任何地方都绝不是硬性要求）。

auto-experiment：从标注队列加载评估语料 该技能只能从原始 trace、数据集或本地文件构建语料，因此 LLM-Obs 中唯一已经持有人类判定的地方——标注队列——无法触及。那是平台拥有的最强真实标注，而评分标准在存在真实标注时已经偏好确定性指标而非 LLM 评判者。 添加 `annotation_queue_id` 作为数据源，位于优先级顺序中 `dataset_id` 和 trace 源之间：精选胜过原始，显式数据集胜过队列。队列的已标注交互成为语料，每个 `content_id` 通过现有 trace 路径展开以获取输入/输出，因此消息源和数据选择规则原样适用。生成的数据点像任何其他 trace 派生源一样写入语料数据集，交互 UUID 是评估集 id（`content_id` 不是——一个 trace 可以被排队两次）。 哪个标签意味着什么无法从任意用户定义的模式推断，因此 `annotation_label_map` 是一个新的必问录入字段，命名提供 `expected_output` 的标签以及一个可选过滤标签。因为名称看起来对就选一个标签会凭空捏造每个分数所依据的真实标注——这正是 `evaluators` 规则已经禁止的失败。 三个排除项与现有的“无可评分目标 span”规则一起记录，都出于相同原因（没有可评分的真实标注）：待处理交互、空的映射标签，以及评审者意见不一致的交互。分歧会被报告，绝不通过取最新来解决。 后端机制已针对 pup 1.8.0 和 us1 MCP 验证，差异足够大，值得单独一节：只有 mcp 在服务端过滤（`only_annotated`）并返回 `annotated_count`/`pending_count`，而 pup 的 `annotation-queues interactions list` 不接受过滤标志也不返回计数，因此 pup 运行在客户端过滤和计数，而不是为一次调用跳到 MCP。还记录了标签必须通过 `label_schema_id` 寻址（`name_when_saved` 会漂移），未设置的标签返回 `""`/`[]`，以及队列自身的 `project_id` 可能为空，因此不是运行项目的安全推导来源。 Co-Authored-By: Claude Opus 5 (1M context)

auto-experiment：将评估语料存储在 Datadog Datasets 中 语料及其 val/test 划分是提交到用户仓库中的本地文件（`data.jsonl`、`data.val.jsonl`、`data.test.jsonl`）。这使得 trace 派生的语料在临时分支之外无法复现，将数据集内容放入 git，并且没有任何东西阻止后续迭代重新划分每个较早分数所依据的行。 两个划分现在都是 Datadog LLM-Obs Datasets，每次运行创建一次，名称中带有单个 UTC 时间戳，并在 config.json 中按 id 引用以供后续每次迭代使用。`ml_app`/`trace_ids` 源获得自己的语料数据集，因此 trace 派生的运行之后可寻址；`dataset_id` 源是只读的，绝不写入。`local_dataset_path` 仍是例外：录入会询问是上传它还是保持离线，而 `local_file` 模式保留旧的 jsonl 路径（现在已 gitignore）。 测试框架没有 MCP 工具，也无法为每次评估通过支付重新下载，因此编排器将它想要评分的划分水合到一个未提交的 `.auto_experiment/cache/.jsonl`，并用新的 `AUTO_EXP_DATASET_ID` 将测试框架指向它。缓存缺失是硬错误，绝不是空评估集。`eval_results.jsonl` 仍是已提交的本地 jsonl——它是本次运行的测量值，不是语料数据，统计和机制审计将其与最佳提交进行 diff。 添加 `project_id` 作为录入字段，因为每个数据集写入在两个后端上都需要一个，并记录两条写入路径：mcp 上的 add_llmobs_dataset_records 预览/确认两步，以及 pup 的 `datasets create` / `datasets batch-update`，其 --file 正文必须经验性确认，而不是从表格猜测。 Co-Authored-By: Claude Opus 5 (1M context)

fix(dd-account-setup)：OAuth 回调端口、.env 密码清晰度、OAuth 后页面（#110） * fix(dd-account-setup)：OAuth 回调端口回退、更清晰的 .env 密码、干净的 OAuth 后页面 - 当 8080 被占用时自动选择一个空闲的环回回调端口（RFC 8252），将其贯穿授权 URL、状态文件和令牌交换 redirect_uri；优先 8080 以便常见路径不变。 - 在第 5 步凭据卡片和 C2/交接措辞中呈现生成的 Path C 密码（仅位置 + 后 4 位，绝不显示完整值）。 - 以 charset=utf-8 和仅 ASCII 正文提供 OAuth 后页面，使其不会渲染为乱码。 安全敏感逻辑（PKCE、state、令牌交换、密码生成）不变。 Co-Authored-By: Claude Opus 4.8 (1M context) * fix(dd-account-setup)：关闭 OAuth 回调端口竞态 + 限定生成密码显示范围 解决 datadog-labs/agent-skills#110 上的两个 Copilot 审查发现。 1) OAuth 回调端口竞态（authenticate.md，第 1 步）。端口在一个 python 进程中被选取（bind -> getsockname -> close），而监听器在第二个进程中绑定，因此端口在监听器绑定之前就被释放：另一个本地进程可能占用它（迫使使用粘贴回退，或在错误的进程中捕获重定向）。将两者合并为一个进程，它绑定一次，持有套接字，写入 ver/st/port，打开浏览器，然后在同一个持有的套接字上服务一个请求——授权 URL 现在总是命名实际正在监听的端口。（PKCE + 0600 状态文件已经使被拦截的 code 不可用；这消除了竞态本身。）无 python 或无空闲端口仍回退到 :8080 + 粘贴。 2) 陈旧的生成密码显示（SKILL.md 第 5 步；authenticate.md C3）。第 5 步卡片无条件 grep .env，因此后续 Path A/B 运行会浮现出较早注册遗留的 DD_SIGNUP_PASSWORD，而 `head -1` 在 C2 追加后返回最旧的条目。将显示门控在仅当本次运行创建账户时写入的运行作用域标记上（C3），并读取最新条目（tail -1）。也将 C3 自己的读取修正为 tail -1，以便重新运行时用新生成的密码注册，而不是陈旧的。（.env 是 C2 写入密码的唯一文件，因此这里读取 .env——而非 .env.local——是正确的。） 离线验证：对所有 12 个 shell 块运行 `bash -n`；监听器可编译，且实时运行时在 8080 空闲和 8080 占用（临时）两条路径上都绑定+服务单个套接字，URL 端口 == 服务端口 == 状态文件端口，捕获重定向并写入 0600 文件；标记门控仅在本次运行创建账户时显示最新密码，后续运行不显示任何内容。

添加云集成技能（AWS、Azure、GCP、OCI）（#101） * 添加 dd-aws-integration 技能 Co-Authored-By: Claude Opus 5 (1M context) * 添加 dd-azure-integration 技能 Co-Authored-By: Claude Opus 5 (1M context) * 添加 dd-gcp-integration 技能 Co-Authored-By: Claude Opus 5 (1M context) * 添加 dd-oci-integration 技能 Co-Authored-By: Claude Opus 5 (1M context) * 更正 UK1 受信任账户和 Terraform 密钥传递说明 UK1 是一个真实的 Datadog 站点，拥有自己的 AWS 受信任账户 117348461845（已对照 DataDog/cloudformation-template 中的 DdAccountIdBySite 验证）。将其并入 464622532012 行会为错误的账户写入 sts:AssumeRole 信任，因此 UK1 安装不会收集任何内容。 密钥在这里也从不通过 TF_VAR_* 传递，也没有任何东西被声明为 ephemeral：datadog provider 从环境读取 DD_API_KEY / DD_APP_KEY。留下陈旧说明可能促使模型发明模板所禁止的密钥变量。 * 更正 Terraform 密钥传递说明 密钥从不通过 TF_VAR_* 传递，也没有任何东西被声明为 ephemeral：datadog provider 从环境读取 DD_API_KEY / DD_APP_KEY。该条目下方的客户端密钥注意事项不变，仍然适用。 * 修复 google_projects 文件夹过滤器和密钥传递说明 data.google_projects 调用 Cloud Resource Manager v1，其过滤器在服务端运行，不共享发现期间使用的 gcloud --filter 语法：它没有 AND/OR/NOT 关键字，要求 parent.type 与 parent.id 并存，且没有 projectId 字段。因此旧过滤器会以无效过滤器错误失败或错误解析，所以基于文件夹的安装会在错误或空的项目集上启用 API，并静默收集不到任何内容。 sys-* 排除没有有效的 v1 形式，移到客户端进入 all_project_ids。 密钥也从不通过 TF_VAR_* 传递，也没有任何东西被声明为 ephemeral：datadog provider 从环境读取 DD_API_KEY / DD_APP_KEY。 * 遵循选定的 OCI 配置文件并固定模块修订版 凭据和 OCID 检查读取 OCI_CLI_PROFILE 并回退到 DEFAULT，因此在对话中命名配置文件还不够：检查检查的是与被安装身份不同的身份。第 1 阶段现在预先确定配置文件，oci CLI 调用显式传递它。 模块源也没有携带 ref，而 Terraform 的锁文件不锁定远程模块修订版，因此每次全新 init 都解析默认分支上的任何内容。此模块创建 IAM 用户、策略、API 密钥和 Vault 资源，因此固定它：datadog-integration-v1.1.17，它今天与 master 逐字节相同。 * 注明 OpenTofu 可作为 Terraform 的直接替代 四个云集成技能中的每个命令都写作 `terraform`，因此与只安装了 `tofu` 的用户一起工作的代理会在第一个预检检查处失败。添加第 0 阶段说明以检测二进制文件并全程替换。 provider 短形式源和 OCI 模块固定的 GitHub 源在两者下解析相同，因此无需其他更改。 Co-Authored-By: Claude Opus 5 (1M context) --------- Co-authored-by: Claude Opus 5 (1M context) Co-authored-by: Ryan MacLean

添加 dd-instrument-rum 技能（#106） ## 添加 `dd-instrument-rum` 技能 添加一个用 **Datadog Browser RUM** 为浏览器 Web 应用插桩的技能——检测框架并安全地添加（或补全）经典 RUM 设置而不破坏构建。仅插桩；它绝不添加 APM、Logs、LLM Observability、source-map 上传或无关产品。 ### 工作原理 1. **分析**——定位真实构建所发布的浏览器应用（感知 monorepo），然后检测框架、路由器、包管理器、打包器、入口点、TypeScript 以及任何现有 RUM 初始化。 2. **路由**——读取共享的 `rum-core` 参考以及恰好一个框架参考（React、Next.js App/Pages Router、Angular、Vue、Nuxt 或 Svelte/vanilla/SPA/iframe），逐字复制包名、导入和初始化选项，而不是凭记忆。 3. **插桩**——以一个固定版本安装 `@datadog/browser-rum` 和匹配的框架包，在最早的浏览器入口点恰好初始化 RUM 一次，并仅在那些表面已存在的地方接入路由器 + 框架错误集成。 4. **验证**——确认单一初始化路径，将包持久化到真实清单/锁文件，运行项目自己的构建，并报告简短的 JSON 结果——绝不声称它未观察到的遥测。 ### 它解决的问题 - 跨 React、Next.js、Angular、Vue、Nuxt、Svelte 和 vanilla 应用的“在我的前端添加/设置/插桩 Datadog RUM”。 - **修复**部分设置——补全缺失的插件/路由器/错误接线，同时将现有有效初始化的凭据和选项视为不可变（无重复初始化，无凭据覆盖）。 - 常见失败模式：在 render/hook 中初始化、混合 npm+CDN、SDK 版本不匹配，或将绿色安装误认为通过的构建。 ### 依赖 - **仅浏览器 SDK 包**——`@datadog/browser-rum` 加上相关的 `@datadog/browser-rum-*` 集成，用项目自己的包管理器安装。 - 可选地在存在时使用 `CreateRumApplication` 工具来配置 RUM 应用；否则回退到询问现有的 Application ID / Client Token / site。无 API 密钥——RUM 使用浏览器可见的标识符。

feat(agent-observability)：泛化实验引导（#103） * feat(agent-observability)：泛化实验引导 * refactor(agent-observability)：推迟 HTTP 适配器 * docs(agent-observability)：恢复 Python 引导参考 * refactor(agent-observability)：重命名实验引导技能 * refactor(experiments)：对齐适配器参考目录

合并拉取请求 #102，来自 sakibh/auto-experiment-cost-estimate auto-experiment：推导运行成本估算

auto-experiment：推导运行成本估算 在第 3 步录入回顾中添加成本估算，从真实调用次数和实测/估算的 token 用量推导（优先历史 trace，静态代码分析作为回退），而不是询问用户，用户很少知道单个案例的成本。明确与编排成本分开，并带有定价查询的反捏造规则。

合并拉取请求 #97，来自 sakibh/auto-experiment-explicit-domain-notes-prompt auto-experiment：显式询问 domain_notes，而不是在配置回顾中提及它

auto-experiment：显式询问 domain_notes，而不是在配置回顾中提及它 将邀请埋在全部参数回顾中意味着用户通常从未注意到它是一个实时提示，因此 domain_notes 默认保持为空。将其提升为独立的 AskUserQuestion，在回顾之前询问。 Co-Authored-By: Claude Sonnet 5

添加 dd-account-setup 技能（#96） * 从 DataDog/agentic-onboarding-evals 添加 dd-account-setup 技能 * dd-account-setup：处理 Copilot PR #96 审查 - 步骤 H（无头）：在缺失密钥检查之前从 .env/.env.local 加载 DD_*，因此凭据在 .env 中（未导出）的 CI 运行不再失败。 - 第 5 步：将“source .env”改写为通过解析加载（绝不 source），与代码一致并避免 source 密钥文件的陷阱。 - authenticate.md：将 Python 解释器版本/路径发送到 $DDLOG，打印干净的状态行（conventions.md）。 - get-api-key.md：将原始 HTTP/URL/curl 退出机制重定向到 $DDLOG；将“获取新密钥，而非复用你环境中的 DD_API_KEY”的透明度保留为单行干净文本。

合并拉取请求 #94，来自 ebrevan/replay-trace-intent-tagging replay-trace：在 telemetry.intent 中用技能名标记 MCP 工具调用

replay-trace：将意图标记折叠为单行（匹配 eval-bootstrap 风格） Co-Authored-By: Claude Opus 4.8

replay-trace：匹配当前意图标记约定（inv_id + :start） 内部约定已演进超越 #370：在每次 MCP 调用上以 skill:[] 为 telemetry.intent 加前缀，并仅在首次调用上使用 skill::start[]（标记调用开始；inv_id 将一次运行的所有调用分组）。使 replay-trace 与 eval-bootstrap/eval-pipeline/experiment-analyzer/session-classify/trace-rca 对齐。 Co-Authored-By: Claude Opus 4.8

replay-trace：在 telemetry.intent 中用技能名标记 MCP 工具调用 遵循 DataDog/llm-obs#370：为每个 datadog-llmo MCP 调用的 telemetry.intent 加上前缀 "skill:agent-observability-replay-trace — "，以便服务器可以通过精确前缀匹配将工具调用（进而技能调用）归属到本技能。仅适用于 MCP 路径；pup-CLI 调用不携带 intent。 Co-Authored-By: Claude Opus 4.8

从 DataDog/agentic-onboarding-evals 添加 dd-product-recommender 技能（#93） * 从 DataDog/agentic-onboarding-evals 添加 dd-product-recommender 技能 为代码库和/或既定目标推荐合适的 Datadog 产品（仅推荐——无设置/安装步骤）。 发布前已净化：移除内部销售/CRM 来源语言（已成交的“sold and won”、“deal figures”、“sales correlation”、“customer engagements”），并将映射重新归属到 Datadog 产品能力和常见技术模式。层级/置信度逻辑不变。 * 修复 dd-product-recommender 参考映射中的内部不一致 处理 PR #93 上的 Copilot 审查——三个真实矛盾： - 后端语言：“All eight”计数错误（九行）并过度声称 Rust/C/C++ 的基础地位；澄清七个 GA 语言是基础的，而 Rust/C/C++ 是情境性的（Preview/手动）。 - Product Analytics：被列在基础前端捆绑包中，但在目录中是利基/仅显式匹配；降级为情境性附加项。 - LLM Observability 主题置信度“emerging”与锚点表的“defining + well-established”矛盾，后者门控主导规则；设为 well-established 以便它能主导 LLM 推荐。

合并拉取请求 #92，来自 tillwf/till.wohlfarth/remove-auto-experiment-pycache chore(auto-experiment)：移除已提交的 __pycache__ 产物