返回 ResolveAI 项目总览 · 交互图：人工批准基线 · 生命周期
客服 Agent 的评测系统很容易积累大量失败记录，困难却不在于“有没有日志”，而在于：哪些失败属于同一个问题？谁有权把这个判断变成后续优化的比较基线？新失败出现时，系统是在提醒人，还是在悄悄改写策略？
ResolveAI 在这个问题上采用了一条保守的路径：运行记录先形成可复核的证据包，确定性规则先做初始聚类，AI 只能提出拆分候选；只有人工确认才能写入版本化的失败模式基线。此后的漂移检查读取基线并追加评估记录，但没有写入 Policy、Workflow、Tool、Prompt 或场景版本的权限。
真实产品页面：Release Center 把变更影响、校验和人工审批放在同一治理控制面。截图证明页面形态，不单独证明本地数据中已经存在一条批准后的模式基线。
为什么做这个项目
这个项目并不是从“做一个更像人的客服机器人”开始的。它来自我参与企业智能客服场景方案验证之后，对一类反复出现的问题进行脱敏、重新建模和独立复现：模型能给出一段看起来合理的回答，并不代表客户的问题已经解决；接口调用成功，也不代表选对了业务对象；一次修复在原 Case 上通过，更不代表它可以安全地推广到其他场景。
因此，我把实践目标从“展示模型会聊天”改成了“展示团队怎样运营一个会犯错的 Agent”。项目需要把客户目标、业务对象、Policy、Workflow、Tool、人工协同、业务结果和评测证据连接起来，允许运营人员回答：系统当时看到了什么、提出了什么、实际执行了什么、首次在哪里偏离，以及修复为什么有资格进入下一轮验证。
这是一个使用独立实现与脱敏场景的个人实践项目，未使用公司代码、客户数据或内部架构。当前在本地验证，尚无真实企业采用。
它与另外两个实践项目的联系
在我的项目组合里，ResolveAI、TraceWise 和 TeachFlow 不是互相调用的三个模块，也不是三条都要商业化的产品线。它们面对不同的权威事实和失败风险：
- TraceWise 处理知识、关系、证据与推演，关心模型提出的图变更是否有来源、能否审阅；
- ResolveAI 处理客服运行质量与业务结果，关心模型建议是否被 Guard、Tool、Workflow 和 Outcome 证据约束；
- TeachFlow 处理教学内容与学习证据，关心课程修订、学生作答和学情结论能否回到不可变事实。
三者共同验证的是同一条方法：把不确定模型放在 Proposal 或结构化生成层，把权限、提交、版本、证据和评测留给确定性系统与人。它们之间的联系是设计原则和验收方法，而不是把一个项目的代码、客户结果或生产成熟度借给另一个项目。
本文的人审失败模式基线正是这条共同原则在客服质量场景中的具体实现：AI 可以发现关系和提出候选，但不能自己把候选升级为组织事实。
几次讨论怎样改变了设计
这条边界不是一开始就完整存在的。开发过程中几次最重要的讨论，都在追问同一件事：什么东西看起来成功，却不能被当成事实？
第一，确定性 Demo 能不能出现在正式产品数据里？早期实现为了稳定演示复用了场景模板，但一次 Provider 失败后，降级 Run 仍显示了模板中的 Tool Decision，制造了“模型失败、页面却像成功”的假象。最终，测试轨迹和产品轨迹继续使用同一 Trace 合同，但 fixture 不再写入产品 RunStore；无效 Decision 明确保存为 null，页面也必须展示缺失，而不是用 fallback 补成成功。
第二，Guard 放行或 Tool 返回成功，能不能算客户问题解决？讨论后的答案是否定的。Guard 只授予执行权限，Tool 状态只证明一次技术观察；系统还必须分别验证实际执行、业务 Outcome 和禁止行为。这样同一条 Run 可以同时保留“接口成功”和“业务失败”，不会让 HTTP 200 抬高 Resolution Rate。
第三，同一个坏 Case 跑十次，能不能让 AI 自动修改 Prompt？重复十次只能证明它可复现，不能证明它具有跨 Case 普遍性。于是证据被分成跨 Case、同 Case 重复和单点三类；AI 只能返回 match / split / abstain 或后续受限候选，不能直接写配置。当前这篇文章讨论的人工批准基线，就是在这次取舍上继续向前：即使模型已经拆分成功，组织仍需要一条独立的人类批准记录，才能把候选变成后续比较的基线。
自动生成建议之后，还要解决三项问题：隔离演示数据、按业务结果判定成功，以及分开提出修改和验证修改所用的数据。
同一首次偏离，不等于同一根因
如果两个 Run 都在 handoff_decision 首次偏离，最直接的做法是把它们算作同一种失败。但这只说明它们在相同位置暴露问题，不代表根因相同：一个可能缺少账户事实，另一个可能在证据充分时仍选择了错误动作。
因此，ResolveAI 没有让模型直接“自由归类”。系统先过滤通过、注入故障和已判定为误报的记录，再用租户、场景、首次偏离、期望结果和实际动作生成确定性签名。这个签名回答的是“哪些记录值得放在一起检查”，而不是“这些记录已经被证明是同一种根因”。
这一区分很重要。确定性聚类让输入可重放，AI 审阅则负责指出一个初始簇是否应该拆开；两者都没有获得批准权。
先把运行事实变成可复核证据包
模式分析的最小输入不是一段总结，而是从已评测 Run 构造的证据包。每条记录包含：
- Run 与业务案例标识；
- 当时使用的场景配置修订号；
- 是否可重放、最终 verdict 和首次偏离；
- 失败检查项、诊断依据与证据哈希。
RunStore 以追加方式保存评测运行和调查记录；模式层再从这些记录投影出证据包。这样，后续判断可以回到具体 Run、具体检查项和当时的配置，而不是只剩一句“模型可能不稳定”。
证据哈希还承担了一个治理职责：人工确认之前，系统会重新构造当前证据包并比较哈希。如果在 AI 审阅之后又出现了新证据，旧审阅会被判定为过期，不能继续批准。人批准的是眼前这组证据，而不是一个已经失去上下文的模型结论。
AI 给候选，不给基线
AI 审阅返回的不是任意标签列表，而是受约束的拆分建议。解析层要求：
- 所有引用都必须指向本次证据包中的 Run；
- 每个拆分组必须覆盖完整、组间不得重叠；
- 跨案例归并必须有对应证据；
- 证据不足时可以明确弃权，但不能用猜测补齐分组。
这使模型输出更接近一份“待审提案”。即使建议通过结构校验，页面上仍然显示为只读候选；它不会因为置信度较高或校验通过就自动进入基线。
人工确认是一次带来源的版本写入
当操作人确认拆分理由后，系统才创建 PatternGroupSet。这条记录不仅保存分组结果，还保存基线版本、来源 Review、来源证据包哈希、被取代版本、基线 Run 集合，以及批准理由、批准人和批准时间。
创建过程同时检查四个条件：确实存在拆分建议、候选与当前确定性簇匹配、证据包没有过期、所有 Run 被完整且唯一地覆盖。相同 Review 的重复提交保持幂等；新的人工批准则递增版本，并指向被取代的旧版本。
机制图：AI 可以提出分组并检查后续证据，只有人工批准动作会产生或升级持久化基线；漂移检查只追加 Assessment。
这条边界回答了一个常被忽略的问题：所谓“人工在环”，不是页面上多一个确认按钮，而是批准动作拥有独立、可审计的持久化语义。没有这次写入，AI 建议就始终只是建议。
漂移检查为什么不会改写策略
基线建立后，系统用两层口径处理后续失败证据。
第一层是触发口径：候选计数会排除基线中的 Run，也排除最近一次评估已经覆盖的 Run，只有出现尚未评估的新证据才值得再次调用漂移检查。
第二层是比较口径：真正送入评估的快照保留基线之外的累计失败记录，并为整个快照计算哈希。换句话说，新证据负责触发，非基线证据台账负责提供完整比较上下文。这避免每次只看一个孤立新样本，却也意味着评估结果必须绑定基线版本和快照哈希，不能脱离当时输入解释。
漂移模型的系统约束明确要求只读：它只能判断现有分组是否稳定、出现了值得人工关注的漂移，或证据不足需要弃权；它不能提议、批准、应用或编辑任何 Policy、Workflow、Tool、Prompt、场景配置和评测资产。解析层还要求每个快照 Run 被恰好分配或引用一次，组 ID 必须来自当前人工基线，稳定、漂移和弃权的字段必须相互一致。
无论调用失败、返回无效输出还是成功，系统记录的是 provider attempt；只有合法成功的 attempt 才能形成 PatternDriftAssessment。Assessment 保存基线版本、快照哈希、状态、分配结果、漂移信号和模型尝试信息。它与策略配置之间没有写路径。
所以，“检测到漂移”在产品语义上等于“形成一条需要人审阅的新证据”，不等于“系统已经优化了 Agent”。这层克制牺牲了一部分自动化速度，却换来了更清晰的责任边界。
新模式如何进入下一版
只读漂移并不意味着系统永远不能学习新模式。它只是把“发现”与“升级基线”拆成两件事。
当漂移评估提出新模式假设后，候选还要满足可重放、评测有效等资格条件，并需要来自不同业务案例的重复证据。AI 可以再次生成扩展审阅，但升级仍需人工填写批准人和理由。批准后才创建下一版分组集合，旧版本通过 supersedes 关系保留在证据链中。
因此生命周期不是“模型输出 → 自动改写”，而是：
- 新失败触发只读比较；
- Assessment 暴露稳定、漂移或弃权结论；
- 合格证据形成新的扩展候选；
- 人工再次批准，才产生
vN+1。
我刻意没有做的三件事
第一，没有把“检测到漂移”直接连接到 Prompt 或 Workflow 保存接口。分析层和配置控制面保持分离，后续变更仍需走各自的验证与发布流程。
第二，没有把模型输出格式正确等同于判断正确。结构校验只能证明输出满足协议，不能证明分组在真实业务中更有效。没有受控对照评测，就不能宣称模型效果得到改善。
第三，没有用本地纵向切片推导生产结论。当前证据能说明代码路径、持久化合同、页面边界和聚焦测试可以工作，但不能说明真实企业流量下的商业提升、生产容量、权限体系完备性或长期漂移质量。
当前证据状态与边界
这套机制在当前工作树中通过了模式基线、服务接口和 Release Center 的聚焦验证：3 个测试文件、120 个测试用例通过；生命周期图也经过结构校验和多视口明暗主题检查。
当前本地数据快照只有校准记录，没有已持久化的 pattern_group_set 或 pattern_drift_assessment。人工批准基线与只读漂移链路有机制测试，但该实例尚未形成一次真实人工批准记录。
此外，企业 IdP、细粒度 RBAC、真实流量平台、生产容量和长期效果评测仍在这篇文章的证据边界之外。真实页面截图来自隔离数据副本，只证明可见的产品控制面，不包含客户或账户数据。
结语
失败模式治理最关键的不是让 AI 更快地下结论，而是让每个结论拥有合适的权限和证据状态。
ResolveAI 的实现把四件事分开了：运行事实负责提供证据，确定性规则负责给出可重放的初始簇，AI 负责提出和检查候选，人负责批准版本化基线。后续漂移只追加评估，不自动改写生产策略。
审核新失败模式时，可以检查来源 Run、所比较的基线版本和批准记录。分组建议与已批准基线分别保存，便于复核误分组，以及后续判断模式是否发生漂移。