调优闭环落地设计：从轨迹到受控发布

一句话：运行闭环让一次任务跑完、跑对、留证；调优闭环要回答的是"下一版能不能更好，并且能证明变好来自这次改动"——它的产物不是更多日志，而是一条可追溯的数据链：Trace → Trajectory → Dataset → Evaluator → Experiment → Patch → Release。

本篇对应白皮书第 17–24 章（模型调优、Agent 调优总览、轨迹数据、运行时数据处理、黄金数据集、BadCase、受控自进化、边缘运行时），是 24-白皮书对标与落地推演认定的第二类结构性缺口。平台 14 篇已经有黄金集、评分器与四级发布门禁，22 篇已经有任务终态、等待原因与完成证据；缺的是把两者接起来的数据生产层、归因层与实验层。没有这三层，"BadCase 回流"只能靠人翻日志。

为什么需要

平台已经有四种事实：任务账本里的状态与终态、OTel 里的 Trace、对象存储里的产物与回执、网关里的 Token 与成本。它们足以回答"这次发生了什么"，但不足以回答"下一版该改什么、改完是否真的更好"。

三个具体断点：

采样断点：只抽失败样本会让评测集越来越偏。正常任务里的高成本、长尾、慢失败不会被看见，下一版可能修好了 BadCase，却悄悄弄坏了大多数正常路径。
归因断点：看到低分直接改 Prompt，是代价最高的一类误判。问题可能出在环境（下游超时）、Harness（上下文缺事实、工具描述误导、没有停止条件）、Verifier（判完成的标准错了），最后才是模型能力。
验证断点：用参与调优的同一批题验证改动，等于自己给自己出卷。没有独立验证集、没有固定 Baseline、没有灰度与回滚，"效果提升"无法证明，也无法在出事时退回。

白皮书给的顺序很硬：先排除能独立复现的执行环境故障，再检查 Harness 是否提供了充分信息与可靠控制，最后才判断是不是模型能力缺口。 调优闭环的工程价值，就是让这条顺序变成数据结构和流程，而不是评审会上的一句提醒。

平台的现实约束决定了它不能照搬"训练平台"：

平台不拥有模型训练集群，也不应该把训练塞进运行路径；它要提供的是可导出的训练样本 + 可复现的评估环境 + 可审计的发布单元；
大多数问题不是模型能力问题，而是上下文、工具契约、状态管理或验证器问题；先改 Harness 的投入产出比远高于先训模型；
调优必须以 Agent Release 为单位，而不是以 Prompt 或模型为单位；否则改了一项、回归了另一项，无法归因。

核心机制

一、三个对象：Trace、Session、Trajectory 不能混用

对象	是什么	回答什么	平台权威
Trace	由追踪上下文关联的一组调用	这一次执行为什么走这条分支	OTel（14）
Session	应用关联的一段连续交互，可含多条 Trace	用户补充、跨轮上下文如何演化	会话存储（12）+ 任务账本
Trajectory	整理后的步骤序列：用户与 Agent 行动、工具交换、结果、指标	行为过程是否合理、能否加工成样本	调优数据层（本篇）

三条纪律：

SessionID 不证明记录属于同一任务。同一会话里可能有多个任务，同一任务也可能跨会话；任务归属以 task_id 为准，不以时间接近或文字相似推断。
Trajectory 不是原始日志的别名。它要提取行为主干、折叠重复携带的历史、把工具请求与返回配对；真实发生的重试仍有分析价值，不能当噪声删掉。
失败、缺失返回、未取得业务结果要分别标记。三者混成一个 failed，后续采样与归因都会失真。

二、轨迹采集：先定"一行代表什么"，再定字段

采集前必须先做一个业务决定：数据集的一行代表什么——一次任务一行、一段连续多轮一行、还是每条并行 Agent 路径各一行。这个选择决定后续的分组、采样、评分与可读性，不能等到 Pipeline 写完再补。

推荐默认：一次 Task Run 一行。理由是与平台任务账本、预算、证据、终态的粒度一致；多轮会话作为列内轨迹保留，并行子 Agent 作为子轨迹关联。

采集点与必带字段

采集点	采什么	必带关联
模型调用	请求摘要、响应摘要、Token、时延、finish_reason	`task_id`、`task_run_id`、`agent_release`、`model_version`、`prompt_version`
工具调用	工具名、参数摘要、结果摘要、错误类别、耗时、是否重试	`tool_call_id`、`mcp_server_version`、`skill_version`
状态迁移	从哪个阶段到哪个阶段、原因、等待类型	`version`、`lease_epoch`
审批与人工	审批对象、决策、耗时、批准范围	`approval_id`、`decided_by`
预算	维度、预留、实际、是否耗尽	`budget_dimension`
验证与交付	Verifier 结论、证据引用、渠道回执	`evidence_id`、`artifact_id`
业务结果	业务系统确认的 Outcome	`outcome_source`（不能由模型自述替代）

三条脱敏与保留规则

凭证禁止入库：API Key、Bot Token、STS Token、Cookie 一律不采集；工具参数中的密文按字段名与正则双重识别后剔除。
内容按等级采集：默认只采摘要与哈希；高敏任务只采结构化字段；需要原文时按任务授权、限时保留、单独加密。
采样分层：错误、高风险、超预算、人工接管全采；正常请求按比例采；采样率变更要记录版本，否则历史数据的代表性无法解释。

最小 schema

调优数据放独立 schema（示例 opt），原始 Trace 仍在 OTel/对象存储，这里只存整理后的可分析对象。

sql

CREATE SCHEMA IF NOT EXISTS opt;

-- 轨迹：一次 Task Run 的整理结果
CREATE TABLE opt.trajectory (
  trajectory_id     text PRIMARY KEY,
  tenant_id         text NOT NULL,
  task_id           text NOT NULL,
  task_run_id       text NOT NULL,
  session_id        text,
  agent_key         text NOT NULL,
  agent_release     text NOT NULL,          -- 完整 Release 标识
  model_version     text,
  prompt_version    text,
  context_policy_version text,
  memory_policy_version  text,
  skill_versions    jsonb NOT NULL DEFAULT '[]',
  knowledge_versions jsonb NOT NULL DEFAULT '[]',
  tool_versions     jsonb NOT NULL DEFAULT '[]',
  runtime_spec_hash text,                    -- Runtime/Sandbox/网络/保留策略的摘要
  eval_baseline_ref text,                    -- 该 Release 对应的评测基线
  input_ref         text NOT NULL,           -- 脱敏后的输入
  output_ref        text,
  step_count        int NOT NULL DEFAULT 0,
  input_tokens      bigint,
  output_tokens     bigint,
  cost_minor        bigint,
  duration_ms       bigint,
  outcome           text CHECK (outcome IN
                      ('root_complete','accepted','submitted','failed','cancelled','expired','unknown')),
  outcome_source    text,                    -- business_system / verifier / human
  failure_class     text,                    -- 见归因分类
  trace_id          text NOT NULL,
  collected_at      timestamptz NOT NULL DEFAULT now(),
  UNIQUE (tenant_id, task_run_id)
);

CREATE INDEX ix_trajectory_agent ON opt.trajectory (tenant_id, agent_key, collected_at DESC);
CREATE INDEX ix_trajectory_outcome ON opt.trajectory (tenant_id, outcome, failure_class);

-- 步骤：按发生顺序，保留行动与观察的配对
CREATE TABLE opt.trajectory_step (
  trajectory_id   text NOT NULL REFERENCES opt.trajectory(trajectory_id),
  step_no         int NOT NULL,
  step_type       text NOT NULL CHECK (step_type IN
                    ('user','model','tool','state','approval','wait','verify','deliver')),
  actor           text NOT NULL,
  summary         jsonb NOT NULL,            -- 摘要，不放完整正文
  payload_ref     text,                      -- 需要原文时指向对象存储
  logical_time    bigint,
  duration_ms     bigint,
  error_class     text,
  PRIMARY KEY (trajectory_id, step_no)
);

-- 工具调用：请求与结果必须能配对
CREATE TABLE opt.trajectory_tool_call (
  trajectory_id   text NOT NULL,
  tool_call_id    text NOT NULL,
  tool_name       text NOT NULL,
  server_ref      text,
  request_digest  text NOT NULL,
  response_digest text,
  side_effect     text CHECK (side_effect IN ('none','read','write','external')),
  attempt         int NOT NULL DEFAULT 1,
  status          text NOT NULL CHECK (status IN ('ok','error','timeout','unknown')),
  duration_ms     bigint,
  PRIMARY KEY (trajectory_id, tool_call_id, attempt)
);

outcome_source 不是装饰：模型说"已完成"、工具返回 200、业务系统确认退款成功，是三件不同的事。没有来源标记，后续会把"任务结束"误当成"业务达成"。

三、Pipeline：数据生产层，不是评估器

Pipeline 把一套整理方法保存为可重复执行的数据任务，按范围或周期产出候选样本。它的边界要写死：

不能凭空补出业务事实：缺失的订单状态不能由 LLM 猜；
不能替代人工确认：生成标注只用于筛选与复核，正式评分交给可校准的评估器；
不能替代候选执行：数据集只描述问题与判据，不产生"这一版更好"的结论。

模块与执行顺序

类别	模块	用途
投影	字段投影、字段扩展	从 Trace/事件里取业务字段
过滤	条件过滤	按时间、租户、Agent、结果筛候选
组装	实例构建	按 `task_id` 把 Span、消息、工具结果组装成一行
去重	精确/近似/语义去重	防止同一问题刷屏
采样	随机、分组、分层	控制成本与代表性
加工	LLM 调用、Agent 调用、向量、聚类	分类、摘要、候选标注
统计	文本统计	定位过长输入、异常工具返回
调度	单次、周期、历史重跑	日常生产与回溯

执行顺序按成本从低到高：先字段筛选，再采样，最后做模型处理。如果采样依赖模型生成的类别，就先分类再抽样；否则会为大量最终不会入集的样本付模型费。

最小 schema

sql

CREATE TABLE opt.pipeline (
  pipeline_id     text PRIMARY KEY,
  tenant_id       text NOT NULL,
  name            text NOT NULL,
  granularity     text NOT NULL CHECK (granularity IN ('task_run','session','agent_path')),
  owner           text NOT NULL,
  UNIQUE (tenant_id, name)
);

CREATE TABLE opt.pipeline_version (
  pipeline_id     text NOT NULL,
  version         text NOT NULL,
  spec            jsonb NOT NULL,            -- 模块 DAG、字段映射、输出 schema
  spec_sha256     text NOT NULL,
  status          text NOT NULL CHECK (status IN ('draft','reviewing','online','offline')),
  PRIMARY KEY (pipeline_id, version)
);

CREATE TABLE opt.pipeline_run (
  pipeline_run_id text PRIMARY KEY,
  pipeline_id     text NOT NULL,
  pipeline_version text NOT NULL,
  window_start    timestamptz NOT NULL,
  window_end      timestamptz NOT NULL,
  status          text NOT NULL CHECK (status IN ('running','completed','partial','failed')),
  input_count     bigint,
  output_count    bigint,
  dropped_count   bigint,
  drop_reasons    jsonb,
  dataset_id      text,
  dataset_version text,
  started_at      timestamptz NOT NULL DEFAULT now(),
  ended_at        timestamptz
);

partial 必须是一等状态：部分分片失败时，已产出的样本可以入候选集，但必须记录 dropped_count 与原因；不能把"这次只跑出 3 条"当成"线上只有 3 个问题"。

四、黄金数据集：题目 + 判据，版本 + 独立性

黄金数据集不是"一批好答案"，而是一组经过业务确认的任务，既有题目，也有判断任务是否完成的依据。对知识问答是参考答案与必须覆盖的要点；对操作任务是业务应达到的状态；对代码任务是测试要求与验收条件。"黄金"指题目与标准可信，不指 Agent 答对过。

字段与版本

sql

CREATE TABLE opt.dataset (
  dataset_id      text PRIMARY KEY,
  tenant_id       text NOT NULL,
  name            text NOT NULL,
  purpose         text NOT NULL CHECK (purpose IN ('golden','candidate','regression','training','validation')),
  owner           text NOT NULL,
  UNIQUE (tenant_id, name)
);

CREATE TABLE opt.dataset_version (
  dataset_id      text NOT NULL,
  version         text NOT NULL,
  status          text NOT NULL CHECK (status IN ('draft','frozen','retired')),
  item_count      int NOT NULL DEFAULT 0,
  content_sha256  text NOT NULL,
  frozen_at       timestamptz,
  created_by      text NOT NULL,
  notes           text,
  PRIMARY KEY (dataset_id, version)
);

CREATE TABLE opt.dataset_item (
  dataset_id      text NOT NULL,
  version         text NOT NULL,
  item_id         text NOT NULL,
  input           jsonb NOT NULL,            -- 用户原始问题（必要时补前提）
  expected_output jsonb,                     -- 业务认可答案或应完成结果
  rubric          jsonb NOT NULL,            -- 必须覆盖什么、怎样判分、哪些错误不可接受
  scenario        text,                      -- 功能介绍/操作指导/异常处理
  initial_state   jsonb,                     -- 操作任务的起始条件
  split           text NOT NULL CHECK (split IN ('tune','validation','holdout')),
  source_ref      text,                      -- trajectory_id / doc version / manual
  contamination   text NOT NULL DEFAULT 'unknown' CHECK (contamination IN ('clean','suspected','contaminated','unknown')),
  PRIMARY KEY (dataset_id, version, item_id)
);

四类用途必须分开存放，不能用一个 dataset 加布尔字段糊过去：

用途	谁写	谁读	规则
candidate	Pipeline 日常产出	人工复核	可随时追加，不代表可信
golden	业务确认	评估、实验	版本冻结后才可用于比较
validation	独立挑选	采用前验证	不参与调优，不反复查看
training	数据导出	训练系统	与验证集做 8-gram 去污染

独立性是硬规则：参与改写 Prompt、生成 Skill 或提炼经验的题，必须与最后独立检查效果的题分开。一旦反复查看某些题并据此修改 Agent，它们就已经参与调优，不能再当验证集。验证集用一次就消耗一次，长期反复使用会形成间接过拟合。

覆盖按五类建立，不按数量堆：

高频问题；
已发生过的问题（事故、BadCase）；
业务边界与高风险要求（退款、权限、删除、外发）；
原本表现正常的题（用于发现退化）；
表述变化与多轮问题。

用场景列找空缺，优先补空缺，而不是增加近似题。操作任务必须写明起始条件（如"订单满足退款条件"）；重做从约定初始状态出发，专测恢复时再设失败检查点。

操作任务与知识任务的区别

维度	知识问答	操作任务
expected	参考答案 + 必须覆盖要点	业务应达到的状态（订单状态、退款单号、交付回执）
判据	覆盖、准确、有据	环境终态、副作用、回执
起始条件	通常不需要	必须声明，且可重复构造
验证方式	规则 + Judge + 人工	查真实状态，不看模型自述

五、评估器：三类可组合，但不能简单平均

类型	适合	不适合	平台落点
Code 规则	JSON 格式、必填字段、状态码、金额一致性	开放性表达	确定性断言，优先使用
LLM 评估	切题、遗漏必要信息、解释是否支持结论	需要环境终态的操作任务	需给齐参考材料与评分细则
Agent 评估	多步骤任务、工具结果与最终回复一致性	高成本、高频	结合轨迹，可挂载 Skill

一个任务可以挂多个评估器，但不能把多个评估器的分数简单平均就当业务质量。正确做法是分层：硬性规则先判（不通过直接失败），再做质量评分，最后人工复核高风险样本。

评估器本身需要校准：

试评三条：至少一条已知好回答、一条已知坏回答、一条信息不完整样本；
检查扣分依据：是否真的出现在回答里、是否引用了正确工具结果、缺证据时是否说明无法判断；
记录一致性：Judge 与人工判断的一致率、漂移；高风险结论必须人工兜底；
版本绑定：评估器名称、版本、提示词、模型、阈值随发布冻结，改评估器要像改代码一样评审。

sql

CREATE TABLE opt.evaluator (
  evaluator_id    text PRIMARY KEY,
  tenant_id       text NOT NULL,
  name            text NOT NULL,
  kind            text NOT NULL CHECK (kind IN ('code','llm','agent','human')),
  owner           text NOT NULL
);

CREATE TABLE opt.evaluator_version (
  evaluator_id    text NOT NULL,
  version         text NOT NULL,
  spec            jsonb NOT NULL,            -- 判据、模型、阈值、输出 schema
  calibration     jsonb,                     -- 与人工一致率、样本量、日期
  status          text NOT NULL CHECK (status IN ('draft','online','offline')),
  PRIMARY KEY (evaluator_id, version)
);

CREATE TABLE opt.eval_run (
  eval_run_id     text PRIMARY KEY,
  dataset_id      text NOT NULL,
  dataset_version text NOT NULL,
  evaluator_id    text NOT NULL,
  evaluator_version text NOT NULL,
  agent_release   text NOT NULL,
  status          text NOT NULL CHECK (status IN ('running','completed','partial','failed')),
  metrics         jsonb,
  created_at      timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE opt.eval_item_result (
  eval_run_id     text NOT NULL,
  item_id         text NOT NULL,
  verdict         text NOT NULL CHECK (verdict IN ('pass','partial','fail','undeterminable')),
  score           numeric,
  reason          text NOT NULL,
  evidence_refs   jsonb NOT NULL,
  PRIMARY KEY (eval_run_id, item_id)
);

undeterminable 必须保留。证据不足时硬评，会把"材料缺失"变成"Agent 错误"，后续归因全错。

六、BadCase 归因：先环境，再 Harness，最后模型

判读顺序

现象	先检查	不要做什么
缺少运行/结果分析步骤	回答完整性与轨迹	直接判 Prompt 不好
解释与回答不符	评估器与字段映射	直接改 Prompt
声称完成但工具失败	任务执行与工具结果	把工具故障算成模型幻觉
执行异常或材料缺失	运行环境与采集	把采集问题做成 BadCase

归因分类与 Patch 对应

归因	证据形态	首选 Patch	不应做什么
environment	绕过模型直接调用仍复现；下游超时/错误码	修环境契约、超时、重试、隔离	改 Prompt
context	决策所需事实不在上下文；Manifest 缺来源	补 Context Policy、检索、字段映射	换模型
state	恢复后丢失计划/预算/已确认事实	修 Checkpoint、状态字段、恢复顺序	重试任务
tool schema	参数误用、描述误导、返回不可解析	改 Tool Schema、示例、错误分类	加提示词约束
permission	越权拒绝、审批缺失、凭证过期	修策略、委托、短时凭证	放宽为 always_allow
loop/plan	无进展、重复探索、无停止条件	改循环控制、停止条件、计划模式	加大预算
verifier	把"完成语"当完成；判据错	改 Verifier、完成证据、验收标准	改模型
model	信息、动作接口、反馈充分且环境正常，错误跨任务稳定出现	换模型、路由、微调	用系统补丁掩盖

顺序不能反。把本应由上下文、工具协议或运行控制解决的问题当成模型不行，是代价最高的一类误判：花了训练成本，问题还在，而且更难归因。

七、实验：四格对照 + 五道门禁

四格对照

要区分"模型变好"与"Harness 变好"，至少需要四组：

组	模型	Harness
A 基线	原模型	原 Harness
B	原模型	候选 Harness
C	候选模型	原 Harness
D	候选模型	候选 Harness

只跑 D 与 A，无法判断收益来自哪一项。实际执行时不必每次跑满四格，但归因结论必须来自能分离变量的对照。

固定配置

实验前冻结四类配置，否则结果不可比：

模型：基座/检查点、训练方法、数据版本、超参、对话模板、Tokenizer、推理参数；
Harness：System Prompt、Skill、裁剪与记忆策略、工具 Schema、路由、并行、重试上限、停止条件、权限、人工介入；
执行环境：服务版本、Sandbox 镜像、数据快照、依赖、资源规格、读写范围；
评测：任务集、环境种子、预算、验证器、重复次数、指标口径、阈值。

五道门禁

门禁	通过条件	不能用什么替代
接口兼容	Action Schema、事件格式、工具契约不破坏现有调用方	平均分
目标收益	锁定测试集上有最小改善幅度与置信区间	单题提升
能力回归	原本正常场景非劣效，关键维度不退化	总分持平
运行预算	单位成功任务成本、超时率、重试率、P95 时延达标	单次 token 单价
安全硬门禁	越权、数据外带、高风险动作穿透为零	其他指标抵消

阈值必须在看候选结果之前确定。 看完结果再定阈值，等于给结论找理由。

单位成功任务成本 = 统计期全部执行成本 ÷ 成功任务数，失败与重试的成本计入分子。只报单次调用单价，会漏掉"便宜模型因重试多而更贵"的情况。

灰度与回滚

text

影子（只观察/旁路重放） → 低风险灰度 → 分阶段扩量（只读先于写） → 稳定替换

涉及状态变更的任务，影子阶段必须在 Sandbox 或副本重放，不能拿生产数据试；
回滚对象是完整 Release，不是单个字段。Release 至少锁六要素：①模型/参数/推理预算/路由；②Harness 代码、配置、循环、中间件与终止条件；③Prompt、Context Policy、Memory Policy、Skill、Knowledge 版本；④Tool/MCP/Agent 能力清单、权限与凭据；⑤Runtime/Sandbox、资源、网络与数据保留；⑥评测数据集、Evaluator、基线、阈值与已知风险。六要素中任何一项变化，都产生新的 Release。
回滚不能撤销已完成的写操作，只能补偿；这一点必须在发布前说清。

八、受控自进化：只生成候选，不自动改生产

平台允许的自动化边界是：系统整理失败模式、挖掘经验、生成候选 Patch、自动跑检查与实验；人决定采用范围。 不允许在线自我修改 Prompt、工具权限或生产配置。

五类现象 → 五类资产

现象	资产	说明
相似故障反复重新探索	经验库	"遇到什么情况，可以怎样处理"
漏前置检查/测试/结果确认	Skill	把方法固化成可加载步骤
反复写相近查询	SQL 模板	参数化、附字段含义、时区、空结果解释
重复写解析/分页/汇总脚本	Script/工具	补依赖、错误提示、调用示例
固定流程仍需人盯	Workflow	把确认、执行、核对、报告串起来

经验库接入要看实际调用记录，不接受"Agent 说参考了历史经验"。四个失败分类：未发起查询（Skill 未启用/触发说明不清/权限不足）、查询失败（地址/空间/凭证）、查询成功但为空（库内容/表达/过滤）、命中未采用（未进上下文/前提不适用）。

采用四确认

目标问题是否改善（同一批 BadCase）；
原有任务是否退化（独立验证集）；
额外代价是否可接受（成本、时延、维护）；
目标 Agent 是否实际使用了被验证内容（Trace 里能看到调用/加载）。

四条缺一条，都不能算"已采用"。只暂停挖掘不会停止旧经验继续影响任务；下架要同时处理召回开关、缓存与正在运行的会话。

九、模型调优的接入边界

平台不建设训练平台，但要为训练提供三样东西，否则模型调优无法安全发生：

可导出的样本：Trajectory → SFT/RL 格式，带完整版本与可见性信息；
可复现的评估环境：固定任务集、种子、工具版本、预算与验证器；
可审计的发布单元：模型 + Harness + 环境 + 评测基线一起冻结。

三条训练数据硬规则：

信息可见性：目标动作只能依赖该决策时刻已经可见的信息；后续轮次才补充的条件不能提前进入早期输入；
损失掩码：系统指令、工具定义、工具结果、环境观察作为输入不计损失；经验证的工具调用、澄清、修正、最终答复计算损失；解释恢复场景的错误步骤保留上下文但屏蔽损失；
未核验步骤不入训：无法确认的步骤先补核验，补不了就移出训练集。未验证的教师轨迹直接入训，是"用错误教错误"。

模型侧上线仍走同一套门禁：先建立可比较版本，再做系统适配、准入门禁、灰度替换与持续迭代。推理框架侧还有一条容易被忽略的硬要求：接入层必须把用户输入与工具返回中与对话模板特殊标记相同的字符串当普通文本处理，否则可被伪造角色或注入指令。

十、边缘运行时：按需，不是默认

边缘优化只在多区域、跨洋延迟显著、且正确性风险可控时才有意义。四个判断维度：延迟不对称、成本不透明、安全前置、内容适配。原则只有一条：边缘能处理的（缓存命中、安全拦截、就近路由）不回源；涉及事实权威、身份权限、写副作用、数据驻留、恢复语义的操作必须回 Region。

如果要做，三条硬约束：

Agent Release 准入基线必须同时包含 Region 内指标与边缘指标；全球 P95 或缓存命中率不达标，Region 内仿真全过也不能发布；
语义缓存只用于公开、幂等、低风险请求，缓存键必须含租户、权限域、地区、模型、Prompt、知识版本；命中不能绕过数据隔离；
版本钉扎 + 激活协议：边缘与 Region 不允许长期并存两个版本；Skill 发布要触发边缘缓存刷新。

平台侧的成熟度按 L1–L4 分级：L1 无边缘优化；L2 加速与安全、独立看板；L3 边缘指标纳入发布准入；L4 边缘数据驱动自进化。成熟度不是越高越好：单区域业务、严格数据驻留、高正确性风险场景，不适用边缘优化。

十一、六链路 × 数据产出映射（G4）

六链路按证据质量分级采集，弱证据不污染强数据集：

链路	数据产出	证据质量	采集策略	飞轮用途
1 纯 Chat	对话轨迹	消息级（弱）	采样 + 脱敏，不入黄金集	prompt 优化、路由调优
2 Chat+工具	轨迹 + 工具调用	消息级 + 工具证据	工具证据可复核，准入门槛：工具结果可重放	工具选择优化
3 技能包	轨迹 + 工作区 + 产物	工作区级（强）	全采入集；产物引用走 O3	Skill 优化、脚本质量
4 个人助手	轨迹 + 画像 + 长任务	强（长上下文）	全采 + 画像蒸馏（§十二）	记忆/画像、个性化
5 多Agent同机	主/子轨迹 + 委派	强（委派结构）	子轨迹关联主轨迹	编排/委派优化
6 多Agent跨端	A2A 消息 + 账本	协议级（强）	消息幂等重放可复核	协作协议优化

三条分级规则：

准入分级：链路 1/2 产出默认不进黄金数据集（弱证据）；进集须过"工具结果可重放"验证（O3 引用有效）；
采集分级：错误/高风险/人工接管全采（§二已有），链路 3–6 正常全采，链路 1/2 正常按比例采样；
不污染：Dataset 去重/污染检查（O5）追加"链路证据质量"标签，弱证据样本不得与强证据样本混入同一题目集。

验收判据：采集按链路证据质量分级；链路 1/2 弱证据不污染强数据集（47 篇 G4）。

十二、用户画像蒸馏（G3）

记忆偏好蒸馏（越用越顺手）与数据飞轮共骨架：采集 → 蒸馏 → 验证 → 入库 → 应用 → 评估 → 回流。

三通道提取：

通道	来源	权威性	处理
显式	用户声明（"记住…"）	权威	直接入库，`source=user`
隐式	LLM 从轨迹推断	派生	标置信度 + `source_trajectory_id` 证据，`source=inferred`
行为统计	高频模式统计	候选	达阈值才转隐式

冲突与回滚：新记忆与旧画像冲突 → 标记待确认，不覆盖（显式 > 隐式）；画像版本化（不裸 KV 覆盖），可删除可回滚；隐式推断必须带证据引用（原子规则 6/8）。

召回与注入：按需检索 → Context Compiler 信任分层注入（Memory 放低信任层）→ token 预算控制（47 篇 §2.3）；记忆是"建议"不是"事实"，注入标注来源与置信度。

流水线：轨迹 → 候选提取（三通道）→ 去重/冲突检测 → 置信度标注 → 写入（画像版本 + 向量记忆）→ 评估（命中率/有用性反馈）→ 运行时召回。

验收判据：显式 > 隐式；冲突待确认；可删除可回滚；召回带 token 预算与信任分层（47 篇 G3）。

原生对齐（§6.5.6/6.5.7 复核）：agentscope-service 原生 builder_memory_store（owner_id 隔离）+ builder_memory/builder_memory_version（记忆 + 版本链）支撑画像的"按人隔离 + 版本化回滚"，builder_memory.head_version 提供乐观并发控制；三通道蒸馏流程（显式>隐式>行为统计）、冲突待确认、召回注入（token 预算 + 信任分层） 为平台层补充。

与现有组件的合缝

调优闭环不新建运行时，它接在现有事实源上。每条接缝要有唯一权威与失败语义：

#	接缝	交界字段	权威	失败语义
O1	OTel → 轨迹层	`trace_id`、`task_id`、`task_run_id`、span 引用	OTel	采集缺失 → 标 `partial`，不补零
O2	任务账本 → 轨迹层	终态、等待、预算、证据引用	`rt.agent_task`	账本不可用 → 轨迹标记 `unknown`
O3	产物服务 → 轨迹层	`artifact_id`、`sha256`、回执	产物服务	引用失效 → 样本不可入黄金集
O4	轨迹层 → Pipeline	`trajectory_id`、粒度、字段映射	轨迹层	映射失败 → 该批 `partial`
O5	Pipeline → Dataset	`dataset_id/version`、`item_id`、split	Dataset	去重/污染检查失败 → 拒绝入集
O6	Dataset → Evaluator	题目、rubric、expected、证据引用	Dataset	版本未冻结 → 不准比较
O7	Evaluator → 实验	评估器版本、校准记录、逐题结果	Evaluator	校准过期 → 结论标"不可比"
O8	实验 → Release	候选 Release、五道门禁结果、置信区间	治理门禁	阈值未预注册 → 不准入
O9	Release → Nacos/Service	Agent/Prompt/Skill/模型版本、Lock Manifest	Registry	解析失败 → 回退上一组已验证组合
O10	Release → Simulation	场景版本、Manifest、评估规格	仿真台（25）	仿真未跑 → 高风险变更不准入

三条边界重复强调：

任务事实不在轨迹层：轨迹是派生物，可重算；任务状态以 rt.agent_task 为准；
评估结论不在轨迹层：Trajectory 只描述行为，verdict 属于 Evaluation；
发布权威不在实验层：实验给证据，门禁给授权。

装配顺序

调优闭环作为第八个切片（S8），依赖 S4 任务、S6 证据治理、S7 仿真台，可与业务迭代并行。

步	动作	依赖	验收
1	建 `opt` schema 与轨迹三表	PostgreSQL + 对象存储	一次 Task Run 能落成一行轨迹
2	从 OTel/任务账本/产物服务回填	14/22/18	轨迹能还原步骤、工具配对、终态与证据
3	实现 Pipeline 最小四模块（投影/过滤/组装/采样）	数据层	能按时间窗产出候选集，partial 可解释
4	建 Dataset 版本与冻结机制	PostgreSQL	历史版本只读，比较期不再追加
5	接三类评估器与试评校准	14/模型网关	三条试评样本结果符合人工预期
6	建 BadCase 归因与 Patch 候选	轨迹层	每个 BadCase 能归到一类并给出首选 Patch
7	建实验四格与五道门禁	评估器	阈值先注册，结果不可事后改口径
8	接 Nacos 发布 Pipeline 与 Release 冻结	08/19	候选 Release 可灰度、可一键回滚
9	接仿真台做上线前验证	25	高风险变更必须带仿真证据包

最小上手

先只做"一条轨迹 → 一道题 → 一次对照"，不建全链路：

text

1. 从最近 100 条任务里导出 10 条轨迹，人工确认"一行代表一次 Task Run"；
2. 写一条 Pipeline：过滤失败与人工接管 → 组装轨迹 → 采样 10 条；
3. 人工把其中 3 条写成黄金题，rubric 写明"必须做到什么、什么错误不可接受"；
4. 用规则评估器跑一遍，再人工核对每条扣分依据是否真的出现在回答里；
5. 固定原版本为 Baseline，只改一项（例如补一个工具描述）；
6. 同一批题跑新旧两版，先看退化题，再看改善题；
7. 把结论与原始轨迹一起归档，确认"改动 → 现象 → 证据"能对上。

最小验收：同一批题两次评估结果可复现；低分题能定位到具体步骤；改动只涉及一个变量；退化能被发现；结论能追到 Release 版本。

生产动作

先定粒度再建 Pipeline：一行代表什么，写进 Pipeline 版本说明；
采样分层：失败、高风险、超预算全采，正常流量按比例；采样率版本化；
黄金集冻结：比较期间只读；调优题与验证题物理分开；
评估器校准：每月抽查与人工一致率，漂移超阈值先修评估器；
归因顺序：环境 → Harness → 模型；跨过前两步直接改 Prompt 的变更不予评审；
阈值预注册：门禁阈值在看结果前写入实验记录；
Release 冻结：按六要素（模型、Harness、上下文与知识、能力与权限、运行时、评测基线）一起版本化，保存解析后的 Lock Manifest；
采用四确认：改善、不退化、代价可接受、实际生效，缺一不可；
边缘按需：没有多区域与明确延迟收益，不做边缘优化。

边界

调优不是训练：平台提供样本、环境与发布单元，不把训练集群塞进运行路径；
数据多不等于有效：样本数量、经验入库、候选生成都是过程产物；有效变更进入运行后，新任务结果才提供下一轮反馈；
黄金集不是真实分布：它永远滞后于线上，必须持续回流，否则会过拟合；
Judge 不是裁判：评分器会漂移，高风险结论必须人工复核或规则兜底；
自进化不是自修改：系统只能生成候选，采用范围由人决定；
回滚不是撤销：已发生的写操作只能补偿，不能回滚；
边缘不是默认：单区域、强驻留、高正确性风险场景，不做边缘优化才是正确选择。

讲清楚

调优闭环不是"再做一个评测平台"，而是把生产事实变成可复现的改进：Trace 还原一次执行，Trajectory 把它整理成可分析的行为序列，Pipeline 生产候选样本，黄金集给出题目与判据，Evaluator 判优劣，Experiment 分离变量，Release 冻结组合，门禁决定能不能上。
三个断点必须堵住：只抽失败样本会让评测集偏移；看到低分就改 Prompt 会掩盖真正的环境或 Harness 问题；用参与调优的题验证改动等于自己给自己出卷。
归因顺序是硬规则：先排除能独立复现的环境故障，再检查上下文、工具与运行控制，最后才判断模型能力。Patch 必须与归因对应：缺事实补上下文，工具误用改 Schema，无进展改循环，完成误判改 Verifier，只有跨任务稳定出现的错误才考虑换模型或训练。
采用一项改动要看四件事：目标问题改善、原有任务不退化、代价可接受、目标 Agent 实际使用了它。四条缺一条，都只是"跑过一次实验"，不是"完成了一次调优"。

适用：AI-Agent-Handbook 第 17–24 章 / OTel GenAI / PostgreSQL / 对象存储 / Nacos 发布 Pipeline / AgentScope Java 2.x | 初稿 2026-10

调优闭环落地设计：从轨迹到受控发布 ​

为什么需要 ​

核心机制 ​

一、三个对象：Trace、Session、Trajectory 不能混用 ​

二、轨迹采集：先定"一行代表什么"，再定字段 ​

采集点与必带字段 ​

三条脱敏与保留规则 ​

最小 schema ​

三、Pipeline：数据生产层，不是评估器 ​

模块与执行顺序 ​

最小 schema ​

四、黄金数据集：题目 + 判据，版本 + 独立性 ​

字段与版本 ​

操作任务与知识任务的区别 ​

五、评估器：三类可组合，但不能简单平均 ​

六、BadCase 归因：先环境，再 Harness，最后模型 ​

判读顺序 ​

归因分类与 Patch 对应 ​

七、实验：四格对照 + 五道门禁 ​

四格对照 ​

固定配置 ​

五道门禁 ​

灰度与回滚 ​

八、受控自进化：只生成候选，不自动改生产 ​

五类现象 → 五类资产 ​

采用四确认 ​

九、模型调优的接入边界 ​

十、边缘运行时：按需，不是默认 ​

十一、六链路 × 数据产出映射（G4） ​

十二、用户画像蒸馏（G3） ​

与现有组件的合缝 ​

装配顺序 ​

最小上手 ​

生产动作 ​

边界 ​

讲清楚 ​

调优闭环落地设计：从轨迹到受控发布

为什么需要

核心机制

一、三个对象：Trace、Session、Trajectory 不能混用

二、轨迹采集：先定"一行代表什么"，再定字段

采集点与必带字段

三条脱敏与保留规则

最小 schema

三、Pipeline：数据生产层，不是评估器

模块与执行顺序

最小 schema

四、黄金数据集：题目 + 判据，版本 + 独立性

字段与版本

操作任务与知识任务的区别

五、评估器：三类可组合，但不能简单平均

六、BadCase 归因：先环境，再 Harness，最后模型

判读顺序

归因分类与 Patch 对应

七、实验：四格对照 + 五道门禁

四格对照

固定配置

五道门禁

灰度与回滚

八、受控自进化：只生成候选，不自动改生产

五类现象 → 五类资产

采用四确认

九、模型调优的接入边界

十、边缘运行时：按需，不是默认

十一、六链路 × 数据产出映射（G4）

十二、用户画像蒸馏（G3）

与现有组件的合缝

装配顺序

最小上手

生产动作

边界

讲清楚