问数平台怎样迁移：同条件PoC、单路交付与可验证回滚

迁移应以可回滚的业务切片推进：先让旧系统也使用统一授权与查询服务，再用新流程执行相同任务，最后依据真实结果扩大范围。先换框架再补权限和真值，会把架构演示误当成产品验收。

先统一边界，再替换运行时。 先选一个指标/业务流程作为迁移切片；不一口气重写全部 Skills 和脚本。

阶段	具体工作	进入下一阶段的证据	回滚方式
P0 盘点与基线	核实真实启动目录、版本、所有取数入口、账号和日志；冻结语义/数据/模型条件	能够定位每次请求的真实身份、查询和结果；缺权限真值则先补	保留现有部署和配置快照
P1 统一业务职责	建立唯一查询服务；接真实 ACL；隔离服务凭据；Hermes 仅调用窄业务接口	普通用户所有可达取数路径受同一授权；拒绝、撤权、旁路题通过	服务和适配器版本可退；不重新开放未受管路径
P2 新编排 PoC	一个 Agent＋显式节点；保留现有 SQL 契约；接同一查询服务	相同环境配对评测，数值、权限、隔离和故障恢复达到门槛	切回已加固的 Hermes 编排入口
P3 灰度	按测试账号/业务范围路由；单一路线交付；限制并发和成本	真实企微接入、附件、审计和恢复通过；SLO 由团队定义并验证	路由回旧入口；已发消息与查询副作用另核对
P4 扩展	按覆盖和故障证据迁移其他能力；整理模块；停用旧执行路径	迁移清单、回归及旧凭据/权限撤除完成	保留受控回滚窗口与必要历史证据

影子比较宜先用固定数据回放。若双跑真实查询，要计算数据平台负载，并且只能有一条交付路径，避免发送两份结果。回滚也必须保留新的授权约束。

PoC优先复用已经审核、具备独立真值的查询与相关权限、渠道题。 针对新恢复机制补必要反例并去重，记录新增覆盖。示例数量只表达覆盖设计，不是统计显著性要求，也不自动产生新的Golden。

迁移门槛：

1. 测试矩阵内无越权数据或附件泄露；这不等于已证明所有输入绝对安全。
2. 查询与分析结果满足独立契约；无法验证的结果明确报告，不能编造。
3. 断联、重复消息、崩溃恢复、撤权、取消有实际证据；生产存储配置经过验证。
4. 新旧接口和模型适配经过测试；锁版本、审计关联、监控与回滚可操作。
5. 真实企微、真实隔离数据平台与已校准 Judge 的适用验收完成。

agent-eval-harness 保持运行时中立：适配新 Target，复用 Case、Oracle、数据分区与证据规则。不要为新业务编排在 Harness Core 内加第二套 LLM 运行时。LLM-as-judge 辅助评回答，不能裁定数据权限；Laya 仍是可选观察工具；SkillOpt 在真实基线和独立回归就绪后再评估。

G.1 不把迁移写成一次全量重写

先抽稳定业务契约与统一查询出口，再替换一个真实业务切片。指标资产、数据连接和既有语义规则能复用时先复用；业务正确性、权限与执行器没有就绪时，不先用全新 SDK 演示掩盖缺口。现有系统能力受限后仍可短期服务，迁移流程与旧流程各自有清晰负责人。

每个切片记录模型、SDK、提示词、业务代码、语义资产、权限策略和数据版本。基础服务迁移和编排迁移分开发布；不同时替换口径、模型、权限源和数据平台，再用一次对比声称某个框架改善了结果。

先建立兼容契约与读回证据，灰度时限制人群及负载。结果存储和检查点格式改变时需制定迁移/旧格式读取方式；回滚不是只把程序版本退回，还要确认恢复中的任务、查询和消息能正确继续或安全结束。

G.2 架构收益怎么量化验证

希望获得的收益	需要收集的实际数据	验收方式	结论限制
减少深度定制	上游补丁数量/范围、内部调用依赖、业务修改位置	同一个新指标或接口变更，在两条路线记录改动和回归范围	不预设工时节省比例，业务复杂度必须可比
更容易测试	测试替身入口、组件启动依赖、失败复现步骤和取证完整性	同一拒绝、非法SQL、超时题能够确定性重放并独立观察	测试方便不等于业务结果正确
权限更可控	所有数据出口、策略版本、旁路与撤权反例结果	角色矩阵、可达路径审阅、查询/缓存/附件证据核对	只能对已测范围下结论
运行更可预测	阶段时延、失败分布、模型/查询次数、取消与恢复结果	同模型/数据下配对运行，加真实故障和代表性负载	不凭小样本平均时延推断生产稳定性
发布维护更清晰	依赖锁定、配置变更、回滚步骤、兼容记录	演练升级与回滚，读取真实任务和交付状态	没有演练就保持未验收

门槛由业务、安全、数据和运维共同确定；样本数量按覆盖缺口增长。不会把“换成专业框架”直接当作验收通过，也不把减少依赖数量自动当作维护成本降低。

回滚验证要覆盖已经在途的任务

切换期间可能存在旧运行时已提交但未完成的查询。新应用接管后，需要确定由谁继续等待、谁负责交付、旧任务是否还能重试。若只回滚入口配置，没有处理在途状态，就可能出现重复文件或无人领取的结果。概念验证应安排切换时暂停一个合成任务，再观察恢复与交付。

回滚也不能回退业务权限。权限已经撤销的用户，即使切回旧应用版本，也应遵守当前授权；新的语义资产是否向后兼容，需要单独说明。应用发布版本、数据版本和权限版本是不同维度，回滚其中一个不能自动恢复其他两个。

选型记录最好区分必须项和偏好项。可信身份不可被模型改写、授权不可绕过属于必须项；图式界面、调试体验或团队熟悉度属于偏好项。先验证必须项，再比较维护成本与体验，能避免一个展示漂亮的候选抢先占据结论。若必须项缺少实际证据，记录待验证即可，不用给出带小数点的综合排名。

配对运行先检查是否可比

比较信息	为什么必须保持或显式声明	不一致时
Case及参考版本	防止新路线仅测容易题或改答案	不可直接比较正确率
模型与语义	区分编排收益和模型/口径变化	拆成单独实验
身份与权限	同题不同范围本来可能不同值	先确认等价授权
快照或水位	隔离业务数据变化	列不可比，不给候选记错或记优
Oracle及Judge	固定裁判与评分标准	重新校准并形成新比较
trial与故障步骤	控制随机波动及恢复难度	补齐重复或报告覆盖不足

以下为教学比较器，只验证配对集合和逐题结果。真实发布还要检查冻结资产、授权与环境证据、必需Judge、预算及人工审核，不能把该函数当作框架完整发布门禁。

def paired(before, after, required_repeats):
    if before.keys() != after.keys():
        raise ValueError("different case sets")
    transitions = {}
    for case in before:
        left, right = before[case], after[case]
        if len(left) != required_repeats or len(right) != required_repeats:
            raise ValueError("incomplete repeat coverage")
        if any(type(v) is not bool for v in left + right):
            raise ValueError("unresolved verdict")
        transitions[case] = (sum(left), sum(right))
    return transitions

assert paired({"c1": [True, True]}, {"c1": [True, False]}, 2) == {"c1": (2, 1)}
for bad in [{"c2": [True, True]}, {"c1": [True]}, {"c1": [True, None]}]:
    try:
        paired({"c1": [True, True]}, bad, 2)
    except ValueError:
        pass
    else:
        raise AssertionError("incomparable experiment accepted")

灰度只允许一条真实交付路径

影子验证首先采用固定数据回放。如果必须双跑真实查询，需要限定读取范围、数据平台负载和预算，两个运行标识各自保留，但只有选定路线能够向用户交付。查询只读不代表双跑无成本，重复生成附件和触发通知同样需要控制。

故障实验应覆盖切换瞬间仍在运行的任务。暂停一个旧任务，切换路由，再完成原查询，观察由谁整理结果、谁发送、谁取消和谁清理。只回退入口配置，而没有处理已提交查询或已发生发送，会导致重复交付或无人领取结果。

回滚不能恢复已经撤销的数据权限。应用版本、语义资产、数据版本和授权版本是不同维度，回滚其中一个不能自动回滚其他三个。状态存储格式不兼容时，先定义旧格式读取、迁移或安全终止；不能只退二进制后宣称服务恢复。

架构收益要用实际变更任务测量

减少上游补丁、独立测试可复现、授权出口可控、业务API稳定、故障能够恢复，是可观察的收益目标。给旧新路线安排同一个指标变更、同一个权限规则和同一个SDK升级，记录涉及模块、接口兼容、必须回归范围与排障步骤，而不是预设迁移收益比例。

运行指标按任务类型给分布：正确率、确认泄露事件、首字与实际交付时延、查询和模型调用次数、真实计费、重复业务交付、取消与恢复结果。所有失败尝试的成本应保留，不能只统计成功任务的调用；延迟不能仅给平均值，代表性负载和尾部等待也需展示。

阶段完成门同时包括业务线、框架工程线与测试条件线。业务线核对权限与结果；工程线核对协议、证据和历史兼容；条件线核对语义、水位、参考和Oracle校准。某条线缺条件时记录缺口，不把另一条线通过包装成全部验收。

最终保留基线、候选、允许变更、逐题差异、真实故障记录、路由切换和回滚读回。PoC指有限范围技术验证，灰度指限制主体与业务范围逐步启用；二者都不意味着已经证明全部输入安全。只有在批准矩阵内有充分证据，才讨论扩大业务覆盖。

迁移完成不等于停止维护旧证据

旧运行记录仍用于解释线上问题与回滚，不能在停用旧入口时一并删除。撤除旧凭据、旧可达工具与定时执行路径需要单独核对；仅把用户流量切到新入口，旧后台任务可能仍持有权限或继续发送报告。

迁移清单应按能力而非文件数统计。每个业务指标、身份角色、数据出口、缓存与附件类型说明旧新覆盖和未迁移原因。允许暂不迁移某项功能，但不能把它从原任务分母里删掉后宣称平台全面完成。

词汇或指标	含义	验证记录
灰度	限定主体、能力或流量逐步启用	路由及实际服务版本可读回
影子运行	对照执行而不承担用户交付	负载受控，禁止双重外部副作用
回滚	将服务切回已批准实现并处理在途状态	查询、消息、存储与权限分别核对
迁移覆盖	达到新路线验收的能力单元／计划能力单元	未迁移与部分完成独立列出
严重事件	越权、跨用户交付等不可平均抵消的失败	原始事实、影响范围及处置
SLO	业务服务目标	由代表性运行与故障证据验证

最终决策可以是扩大新路线、保持过渡，或暂缓迁移。能接受这些结果，PoC才是在检验假设，而不是为预先选定的框架寻找漂亮分数。所有结论都限定在实际覆盖范围内，未验证的生产容量和恢复能力继续保留为工作项。

切换和回滚的证据应连成同一条线

flowchart LR
 A[冻结旧路线基线] --> B[统一授权与查询出口]
 B --> C[旧入口接同一服务]
 C --> D[新工作流有限PoC]
 D --> E[同条件配对与故障验证]
 E --> F[单路交付灰度]
 F --> G[按证据扩展能力]
 F -.-> R[处理在途任务并回滚]
 R --> C

以下为迁移审核包示意，不是自动发布配置。批准动作不由模型代填，阶段状态也不能代替真实读回。

切片: 一个批准指标及其查询交付
基线: 旧入口已加固且可回查的运行
候选: 新工作流与同一授权查询服务
必须证据:
  - 配对结果与严重事件
  - 实际渠道与在途恢复
  - 单路交付和重复消息
  - 状态兼容与回滚读回
未通过处理: 保留旧路线与失败证据

经验感想

先统一强制授权，再逐个业务切片替换编排。迁移收益通过相同任务和实际变更验证，回滚要处理在途状态与已经发生的副作用，同时保留当前授权约束。

推荐标签

#智能问数 #Agent评测 #测试工程 #技术设计