编写 Send

Adapter 定义了 send 的契约：接收 TurnInput 和 AgentContext，返回 Turn。本教程从发送一条消息开始，逐步加入完整接入所需的能力。每一步只增加少量代码，已有部分以 // ……省略 标出。步骤末尾列出新增数据支持的断言。完成任一步后，都可以把对应断言写进评估用例，重跑 pnpm exec niceeval exp，再用 pnpm exec niceeval show 在终端查看结果，或用 pnpm exec niceeval view 在浏览器里检查多轮对话、用量、工具事件和待回答的请求。五个贯穿全文的原则：

连接用户前端正在使用的接口。 Adapter 调用相同端点并接收相同格式，不为评估用例新建接口，也不 import 应用内部代码直接调用函数。具体原因见接入你的 Agent。
把服务生命周期留在 Adapter 外。 先用项目自己的开发命令、部署脚本或 CI 启动并检查真实目标，再运行 Experiment。send 不 spawn 服务，评估用例也不安装、启动或替换被测系统。
按最小边界提供凭证。 目标进程和 Adapter 各自只读取自己需要的凭证，不把秘密写入源码、评估工作区、事件或最终回复。
只手写 transport。 URL、鉴权和请求体取决于应用。niceeval/adapter 提供从原始返回到标准事件流的转换器。ctx.session 提供会话续接与 HITL 暂停恢复所需的状态 API。
运行反馈走 ctx，不直接写终端。 长步骤用 ctx.progress(...)。需要在运行后回顾的退化或异常上下文用 ctx.diagnostic(...)。无法继续时抛错。不要从 Adapter 调用 console.log/error 或写 process.stdout/stderr。

确认应用接口形状

动手写 send 之前，先确认你的应用接口长什么样。NiceEval 不定义新的应用协议，内置转换器按下面几种常见的响应形状提供。认出你的接口属于哪一种，后面就能直接用对应的转换器，少写映射代码：

协议	定义方	说明	参考
Chat Completions	OpenAI。业界事实标准，几乎所有模型服务商都提供兼容端点	无状态一问一答：客户端每轮发完整 `messages` 列表，一个 JSON 回来	API 参考
Responses / Open Responses	OpenAI（Responses API）。Open Responses 是基于它的开放规范，OpenAI 发起、Hugging Face 等社区共建，用于多提供商互操作	有状态、面向 agent：请求带 `previous_response_id` 由服务端续接历史，`output` 数组承诺记录全过程	API 参考 · Open Responses 规范
AI SDK（Vercel）	Vercel。TypeScript 生态的事实标准	不是线上协议而是 SDK：`generateText` 返回完整结果，`useChat` 走它定义的 UI Message Stream 流协议	generateText 参考 · UI Message Stream 协议

以下步骤使用 Chat Completions 形接口。Responses 形接口和流式接口的替换实现分别在第二步和第四步给出。

第一步：发一条消息，拿到回复

先让评估用例能发一条消息、拿到一条回复。这是所有断言的起点。最小的 send 只做三件事：把 input.text 发给应用的接口，把回复放进一条 message 事件，报告本轮 status：

// agents/chat-app.ts
import { completeEvidenceCoverage, defineAgent } from "niceeval/adapter";

const BASE_URL = "http://localhost:8080";   // 要按 experiment 切换地址，改成工厂参数：见接入指南

export default defineAgent({
  name: "chat-app",
  evidenceCoverage: completeEvidenceCoverage,
  async send(input, ctx) {
    ctx.progress({ message: "等待 Chat API" });
    const res = await fetch(`${BASE_URL}/v1/chat/completions`, {  // ← 前端本来就在用的接口
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        messages: [{ role: "user", content: input.text }],
        model: ctx.model,                                         // ← experiment.model 经 ctx.model 到这里。应用接口不支持选模型就删掉这行
      }),
      signal: ctx.signal,                                         // ← 运行器的超时与取消
    }).then((r) => r.json());

    return {
      status: "completed",
      events: [{ type: "message", role: "assistant", text: res.choices[0].message.content }],
    };
  },
});

接口返回的响应能继续用、但缺了一部分信息时，用 ctx.diagnostic 留一条说明，不要把原始响应整个打印出来：

if (!res.requestId) {
  ctx.diagnostic({
    code: "missing-request-id",
    level: "warning",
    message: "响应没有 request id，无法与服务端日志关联",
  });
}

progress 只在运行时显示，不保存。diagnostic 会随这个 Attempt 的结果一起保存，运行结束后在 Attempt 详情里能看到。HTTP 连接失败或响应无法解析时直接抛错。这个 Attempt 会被判为 errored，错误阶段显示为 agent.run，用 pnpm exec niceeval show @<locator> 可以看到完整错误正文。 这一步支持：t.reply 的直接值检查（t.check(t.reply, includes(...)) 或 pattern(...)）、Judge 的全部对话材料，以及 Experiment 侧的模型对比。ctx.model 来自 Experiment 的 model。运行器原样传递，Adapter 只负责转发。接入等级见 Tier。它有两个明显的局限：每轮都是一场全新对话（第二次 t.send 接不上第一次），工具调用完全看不见。后面两步各解决一个。

第二步：接上之前的消息

第一步的 send 每轮都开一场新对话，评估用例的第二次 t.send 接不上第一次。要测多轮对话，send 得记住之前说过什么。运行器只保证一件事：同一条会话线上的每次 send 拿到同一个 ctx.session，新会话线（评估用例的第一轮，或 t.newSession() 之后）拿到一个全新的。 怎么续接取决于应用接口：

客户端每轮发完整历史（服务端不记状态，Chat Completions 形是典型）：用 createSessionSlot<TMsg[]>() 声明一份 Adapter 私有的会话状态，再用 ctx.session.get(...) / ctx.session.set(...) 存取历史消息。
服务端记历史（接口收一个会话 id，例如 Responses 形的 previous_response_id、各 SDK 的原生 session / thread）：用 ctx.session.id 读取，用 ctx.session.capture(id) 写回。

本教程的接口是前一种：

// agents/chat-app.ts
import { completeEvidenceCoverage, createSessionSlot, defineAgent } from "niceeval/adapter";

const BASE_URL = "http://localhost:8080";

interface Msg { role: "user" | "assistant"; content: string | null }
const historySlot = createSessionSlot<Msg[]>("chat-app/history");

export default defineAgent({
  name: "chat-app",
  evidenceCoverage: completeEvidenceCoverage,
  async send(input, ctx) {
    const history = ctx.session.get(historySlot) ?? []; // ← 新会话线上还没有历史
    const messages = [...history, { role: "user" as const, content: input.text }];

    const res = await fetch(`${BASE_URL}/v1/chat/completions`, {
      // ……method、headers、signal 同第一步，省略
      body: JSON.stringify({ messages, model: ctx.model }),        // ← 变化：发的是完整历史。model 同第一步转发
    }).then((r) => r.json());

    const reply = res.choices[0].message;
    ctx.session.set(historySlot, [...messages, reply]); // ← 写回。同一条线的下一轮 get() 自动带上

    return {
      status: "completed",
      events: [{ type: "message", role: "assistant", text: reply.content }],
    };
  },
});

这里不需要“第一轮”分支。新会话线上 ctx.session.get(historySlot) 返回 undefined，?? [] 把它变成空历史，第一轮自然就是空历史加一条新消息。也不需要在 defineAgent 上声明额外能力：用了 ctx.session，多轮就能续上；不用，每轮各是一场新对话。应用接口收会话 id 时，历史留在服务端，Adapter 只记住 id。send 里只改两处：

// send 里：
//   请求体带上一轮的 id …… previous_response_id: ctx.session.id   ← 新会话线自然是 undefined
//   返回里抓到 id 就写回 …… ctx.session.capture(res.id)           ← 下一轮续接靠它

capture 只在这条会话线还没记过 id 时生效。后端每轮重复回传 id，甚至因为分叉换了 id，都不会覆盖正在续接的会话。 这一步支持：多轮对话，以及 t.newSession() 的会话隔离。写一个两轮的评估用例，第二轮引用第一轮的内容。回复接不上时，先查请求里是否带上了历史或会话 id。

第三步：记录消费

答对了但多花十倍 token 的 Agent，不该和省着用的拿一样的分。要限制用量和费用，send 得把每轮的用量报上来。用量写在 Turn 的 usage 字段，和 events、status 并列。应用接口返回了用量就如实填上，运行器逐轮累加到会话线和这次运行。Chat Completions 形的返回自带 usage，照抄进来，send 的其余部分和第二步一样：

    // ……transport 与会话同第二步，省略
    return {
      status: "completed",
      events: [{ type: "message", role: "assistant", text: reply.content }],
      usage: {                                        // ← 变化：把接口回的用量如实报上
        inputTokens: res.usage.prompt_tokens,
        outputTokens: res.usage.completion_tokens,
      },
    };

Usage 还有几个可选字段：cacheReadTokens / cacheCreationTokens、推理 token 数 reasoningTokens、请求次数 requests，以及 costUSD。每个字段只在接口真实提供时填。接口不返回用量，就整个不填 usage，其它断言不受影响。 costUSD 只填 Provider 或应用真实返回的美元费用。不要把上游估算、模型价目表或本地算出来的数写进去。预算和 t.maxCost() 用的是另一个数：运行器根据 model、上报的 token 用量和价格表，自己算出 estimatedCostUSD。即使你填了 costUSD，这个估算也照常计算。价格表配置见 defineConfig 参考，预算用法见控制运行成本。价格表里找不到这个模型的价格时，运行器算不出估算，t.maxCost() 的结果是 unavailable，不会把缺失当成 0。你显式配置了零费率、算出 estimatedCostUSD: 0 时，0 是有效的估算，照常和上限比较。 这一步支持：t.maxTokens() / t.maxCost() 断言，以及 niceeval show --usage 和 niceeval view 里的用量。show 里用量为空时，先查接口响应里有没有用量字段、send 有没有把它放进返回值。

第四步：把工具解析成事件

要断言 Agent 调了哪些工具、按什么顺序调，send 得把工具调用报上来。应用的返回里不只有回复文本，Chat Completions 形返回的 tool_calls 就记着这轮调过什么工具。 Adapter 最重要的工作就是把接口的返回翻译成标准事件流：这轮发生的每件事一个对象，按真实顺序放进 Turn.events。每个对象是下面几种类型之一，字段的实际取值见 Adapter 页的一轮完整示例：

import type { CommandProjection } from "niceeval/adapter";

type StreamEvent =
  | { type: "message"; role: "assistant" | "user"; text: string }
  | { type: "operation.started"; operationId: string; operation:
      | { kind: "tool"; name: string; input: JsonValue;
          tool?: ToolName; command?: CommandProjection }
      | { kind: "subagent"; name: string; remoteUrl?: string } }
  | { type: "operation.finished"; operationId: string; kind: "tool";
      output?: JsonValue; status: "completed" | "failed" | "rejected" }
  | { type: "operation.finished"; operationId: string; kind: "subagent";
      output?: JsonValue; status: "completed" | "failed" }
  | { type: "skill.loaded"; skill: string; operationId?: string }
  | { type: "input.requested"; request: InputRequest }
  | { type: "thinking"; text: string }
  | { type: "compaction"; reason?: string }
  | { type: "error"; message: string };

翻译就是一张“返回字段 → 事件”的对照。手写出来是这样，send 的其余部分和第二步一样：

    // ……transport 与会话同第二步，usage 同第三步，省略
    const reply = res.choices[0].message;

    const events: StreamEvent[] = [];
    for (const call of reply.tool_calls ?? []) {
      events.push({
        type: "operation.started",
        operationId: call.id,
        operation: {
          kind: "tool",
          name: call.function.name,
          input: JSON.parse(call.function.arguments),
        },
      });
    }
    if (reply.content) events.push({ type: "message", role: "assistant", text: reply.content });

    return { events, status: "completed", usage };

这段循环通常不用你写。返回是标准形状时，官方转换器一行就能替代上面全部代码。events、status，连第三步手抄的 usage 都在它的返回值里，直接 return：

    // ……transport 与会话同第二步，省略
    return turnFromChatCompletion(res);            // ← 上面那段映射加第三步的 usage，官方版

接口是别的形状时，换成对应的转换器：

接口响应形状	内置实现	需要编写的代码
Chat Completions 形返回	`turnFromChatCompletion(res)`	无需手写映射
Responses 形返回	`turnFromResponses(res)`	无需手写映射
AI SDK `generateText` 的完整结果	`turnFromAiSdk(result)`	无需手写映射
流式：SDK 原生事件透传（一帧一个完整单元）	`createClaudeSdkEventStream()` / `createPiAgentEventStream()` / `createCodexThreadEventStream()`	无需手写映射
流式：AI SDK 的 UI Message Stream（`useChat` 协议）	`uiMessageStreamAgent()`	无需手写 `send` 或事件映射
流式：逐 token / 逐参数增量	协议方官方 reducer。没有才用 `deltaStream({ toOps })`	一张”帧类型 → 操作”映射表
只有最终答案	手写几条 events	一条 `message` 起步（第一步就是这个档）

内置转换器只看响应形状，不关心应用的业务协议。只有接口是增量流、协议方又没有现成 reducer 时，才需要自己写映射。映射只说明每一帧对应什么动作，拼接、配对和何时形成完整事件由 deltaStream 处理。你返回哪种事件，评估用例就能写哪类断言：

你返回的事件	能写的断言
`message`	`t.reply`、`t.check(turn.message, includes(...))` / `pattern(...)`、Judge 的对话材料
tool `operation.started` / `operation.finished`（靠 `operationId` 配对）	`turn.calledTool()` / `turn.toolOrder()` / `turn.maxToolCalls()` / `turn.noFailedActions()`…
`input.requested`（配合 status `"waiting"`）	`t.check(turn.status, equals("waiting"))`、`t.requireInputRequest()`、`t.respond()`（第五步）
`thinking` / `compaction` / `error`	报告与诊断；也可把原始 `events` 交给普通 `check(events, match)`

Chat Completions 响应不保证列出全过程。应用可能在服务端跑完工具循环，只返回最终答案。所以 turnFromChatCompletion 不声明事件完整：calledTool 这类“调用过”的断言可用，notCalledTool 这类“没调用过”的断言会提示证据不完整。Responses 协议要求 output 数组列出全过程，turnFromResponses 声明事件完整，“没调用过”的断言可信。这个差别来自两种接口本身的约定。 这一步支持：turn.calledTool()、turn.toolOrder()、turn.maxToolCalls()、turn.noFailedActions() 等工具断言。需要跨 Turn 排序时，把调用对象从 turn 换成 session。跑完用 pnpm exec niceeval show @<locator> --execution 看这个 Attempt 的工具调用。工具没出现时，先查接口返回里有没有工具字段、映射有没有漏掉它。

第五步：HITL

应用会中途停下来等人，例如等工具审批或等用户补充信息。要测这类流程，send 要在两种轮次里各做一件事：

等待的那一轮：返回 status: "waiting"，并为每个待回答的问题返回一条带稳定 id 的 input.requested 事件。t.check(turn.status, equals("waiting")) 和 t.requireInputRequest() 读的就是它，回答也靠这个 id 对上问题。
回答的那一轮：评估用例里的 t.respond(...) 到 Adapter 这边是又一次普通的 send，还在同一条会话线上，拿到同一份状态。回答随 input.responses 到达，每条带 requestId，以及 optionId 或 text（形态见不同回答的入参）。Adapter 先把回答交给应用，再接着取结果。被拒绝的工具调用，operation.finished 的 status 写 "rejected"，不写 "failed"。拒绝是人的决定，不是工具故障，noFailedActions() 不会把它算成失败。

等待时还没读完的东西，例如一条读到一半的 SSE 流，也存在 ctx.session 上。Adapter 用 createSessionSlot<Pending>() 声明一份私有状态，等待时 ctx.session.set(...) 存进去，回答轮开头 ctx.session.take(...) 取回。取出后它就被清掉，只能取一次。 HITL 几乎总发生在流式接口上，应用停在流的中间。所以这一步的示例换成一个用 SSE 透传原生事件的应用，它同时用上前面几步的全部内容（完整可跑版本见 tier1 示例）：

// agents/my-app.ts
import { completeEvidenceCoverage, createSessionSlot, defineAgent, sseJsonFrames, createPiAgentEventStream, driveFrameStream } from "niceeval/adapter";
import type { AgentContext, PiAgentStream, SseFrameCursor } from "niceeval/adapter";
import type { Turn, TurnInput } from "niceeval";

const BASE_URL = "http://localhost:5299";               // 应用自己的端口，eval 不代管进程

interface Pending { cursor: SseFrameCursor<Frame>; stream: PiAgentStream; callId: string }
const pendingSlot = createSessionSlot<Pending>("my-app/pending");

function readStream(cursor: SseFrameCursor<Frame>, ctx: AgentContext, stream: PiAgentStream): Promise<Turn> {
  return driveFrameStream(cursor, stream, ctx, (frame) => {
    if (frame.type === "session") {
      ctx.session.capture(frame.sessionId);             // ← 第二步：回传的 id 写回，下一轮续接
      return;
    }
    if (frame.type === "approval_request") {            // ← 本步：应用停下等审批，存下现场
      ctx.session.set(pendingSlot, { cursor, stream, callId: frame.toolCallId });
      return { pause: { id: frame.toolCallId, action: frame.toolName,
                        options: [{ id: "approve" }, { id: "deny" }] } };
      // driveFrameStream 收到 pause：补一条 input.requested、status 置 "waiting"、停止读流
    }
    if (frame.type === "server_error") return { fail: frame.message };
  });
}

export default defineAgent({
  name: "my-app",
  evidenceCoverage: completeEvidenceCoverage,
  async send(input: TurnInput, ctx: AgentContext): Promise<Turn> {
    const held = ctx.session.take(pendingSlot);
    if (held) {                                         // ← t.respond("approve")：普通 send，先交裁决
      const approved = input.responses?.[0]?.optionId === "approve";  // 多请求并停时按 requestId 对位
      if (!approved) held.stream.markRejected(held.callId);
      await fetch(`${BASE_URL}/api/chat/approve`, { method: "POST", signal: ctx.signal,
        body: JSON.stringify({ toolUseId: held.callId, approved }) });
      return readStream(held.cursor, ctx, held.stream); //    再接着读同一条流，不重发请求
    }

    const res = await fetch(`${BASE_URL}/api/chat`, {   // ← transport：唯一真正手写的一段
      method: "POST",
      body: JSON.stringify({
        message: input.text,                            // ← 第一步：发消息
        model: ctx.model,                               // ← 第一步：experiment.model 转发
        sessionId: ctx.session.id,                      // ← 第二步：第一次发自动不带，之后自动带
      }),
      signal: ctx.signal,
    });
    return readStream(sseJsonFrames<Frame>(res.body!), ctx, createPiAgentEventStream());  // ← 第四步：官方转换器零映射
  },
});

不需要 HITL 的接口，删掉和等待相关的三处（Pending、pendingSlot、开头的 take 分支），其余不变。等待、回答、继续执行的完整流程见 HITL。 这一步支持：t.check(turn.status, equals("waiting"))、t.requireInputRequest()、t.respond() / t.respondAll()。被拒绝的调用可以用 calledTool(toolMatch(..., { status: "rejected" })) 精确断言。t.requireInputRequest() 找不到请求时，先查等待的那一轮是否同时返回了 status: "waiting" 和 input.requested 事件。

第六步：接上 OTel trace

想在浏览器里看每一轮的模型调用和工具耗时，而应用已经有 OTel 埋点（标准 OTel HTTP 服务端埋点就够），就把它的 trace 接进来。接入分两部分：一部分在应用启动时配置，一次配好不再变；另一部分在 send 里，每轮都不同。 接收地址在应用启动时配置，不经过 send。 NiceEval 的 OTLP 接收地址每次运行都一样。在 niceeval.config.ts 里固定接收端口，应用启动时把 OTel exporter 指向这个地址，之后跑多少次评估用例都不用改：

// niceeval.config.ts
import { defineConfig } from "niceeval";

export default defineConfig({
  telemetry: { port: 4318 },   // 接收器固定监听 http://localhost:4318/v1/traces
});

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318/v1/traces node server.js

send 里传的是这一轮的 trace context，不是接收地址。 ctx.telemetry.headers 是运行器每轮新生成的 W3C traceparent 头。把它展开进请求头，应用这一轮产生的 span 就会挂到这一轮名下，并发跑多条评估用例也不会混。回到本教程的 chat-app，send 里只多一行：

    const res = await fetch(`${BASE_URL}/v1/chat/completions`, {
      // ……其余同第四步，省略
      headers: { "content-type": "application/json", ...ctx.telemetry?.headers },  // ← 只多这一行
    }).then((r) => r.json());

ctx.telemetry 只在配置了 OTel 接入时才有值。没配置时展开 undefined 也安全，这一行可以一直留着。不带这个头也能收到 span，但 NiceEval 只能按发送前后的时间判断 span 属于哪一轮，这个 Agent 的轮次会改成逐个执行。带上它，并发运行时 span 才能准确对上轮次。 这一步支持：niceeval view 中按轮显示的调用瀑布图，包括模型调用、工具执行、耗时和 token。断言仍然读取前几步返回的事件，span 只用于瀑布图。瀑布图为空或缺尾巴时怎么查，见 OTel 接入。

第七步：透传 experiment 的 flags（A/B 对比）

要比较两版 prompt 或两种策略，应用先把它们做成可以切换的配置。Experiment 声明 flags，运行器每轮通过 ctx.flags 原样交给 send。Adapter 不解释这些值，只随请求转发，由应用按参数切换：

      // ……send 其余部分同前，省略
      body: JSON.stringify({
        messages,
        model: ctx.model,        // ← 第一步就转发的 experiment.model。这里一起列出
        flags: ctx.flags,      // ← experiment.flags 原样透传。没配时是 {}
      }),

// experiments/concise.ts
import { defineExperiment } from "niceeval";
import chatApp from "../agents/chat-app.ts";

export default defineExperiment({
  agent: chatApp,
  model: "gpt-5.4",                      // ← 经 ctx.model 到 send
  flags: { promptVariant: "concise" },  // ← 每轮经 ctx.flags 到 send
});

两个 Experiment 文件各声明一份 flags，用 pnpm exec niceeval exp 分别跑同一批评估用例，就是一组 A/B 对比。这属于 Tier 3 接入，需要应用配合暴露开关，投入与回报见 Tier。flags 和 model、attempts 等其余字段见编写实验。 这一步支持：同一批评估用例在不同变体下的成绩对比。两边都跑完后，用 pnpm exec niceeval show --experiment <id> --experiment <id> 在终端对比，或用 pnpm exec niceeval view 在浏览器里看。两边成绩几乎一样时，先确认应用真的读了请求里的 flags。

对照：五个 t API 到 send 的形态

七步写完，再看评估用例里驱动对话的五个 API。它们到 Adapter 这边都是同一个 send 收到不同字段，不需要实现第二个方法：

评估用例 API	Adapter 调用	`send` 输入
`t.send(text)`	一次 `send`	`input.text`。`ctx.session` 是这条会话线的自有状态
`t.sendFile(path, text?)`	一次 `send`	同上，外加 `input.files`（base64 的 `InputFile[]`）。按应用接口的方式放进请求体，不支持多模态就忽略
`t.newSession()`	不直接触发 `send`	开第二条会话线。这条线上的第一次 `send` 拿到全空的状态，和整个评估用例的第一次 `send` 一样
`t.respond(...answers)`	一次普通的 `send`	`input.text` = 回答文本。`input.responses` 逐请求一条 `{ requestId, optionId }`（自由文本回答则是 `{ requestId, text }`）。还是同一条线、同一份状态
`t.respondAll(optionId)`	一次普通的 `send`	同上，每条待处理请求各一条回答。`optionId` 已在评估用例侧对每条请求校验过存在，写错直接抛，不会静默传给应用

开始使用

接入你的应用

写好评估用例

评估 Coding Agent

实验与对比

看结果与迭代

提速：并发与复用

基础设施与 CI

问题排查

确认应用接口形状

第一步：发一条消息，拿到回复

第二步：接上之前的消息

第三步：记录消费

第四步：把工具解析成事件

第五步：HITL

第六步：接上 OTel trace

第七步：透传 experiment 的 flags（A/B 对比）

对照：五个 t API 到 send 的形态

相关阅读

​确认应用接口形状

​第一步：发一条消息，拿到回复

​第二步：接上之前的消息

​第三步：记录消费

​第四步：把工具解析成事件

​第五步：HITL

​第六步：接上 OTel trace

​第七步：透传 experiment 的 flags（A/B 对比）

​对照：五个 t API 到 send 的形态

​相关阅读

确认应用接口形状

第一步：发一条消息，拿到回复

第二步：接上之前的消息

第三步：记录消费

第四步：把工具解析成事件

第五步：HITL

第六步：接上 OTel trace

第七步：透传 experiment 的 flags（A/B 对比）

对照：五个 t API 到 send 的形态

相关阅读