# Auto-oncall 持续优化核心方案 > Status: Active design source of truth > Updated: 2026-07-15 > Scope: L1 Oncall tickets ## 1. 目标 在不降低客户体验的前提下，让 Auto-oncall 持续学习和改进，最终使至少 10% 的目标 ticket 可以端到端自动处理。 业务目标口径： ```text Autonomous Resolution Rate = 全自动处理成功的 ticket / 通过 L1 Oncaller Gate 的 initial tickets ``` 全自动处理成功至少满足： - Auto-oncall 完成客户所需的有效回复。 - 客户没有 raise 或要求纠正。 - L1 不需要再次发送实质回复。 质量北极星指标： ```text L1 AO Accept Rate = /ao accept / (/ao accept + /ao revise + /ao wrong) ``` `/ao human` 单独作为人工介入指标，不放入 Accept Rate 分母。 ## 2. 核心原则 - 先复用已有能力并形成稳定闭环，再建设新功能。 - 优化按真实 ticket 和真实反馈驱动，不靠主观讨论推动。 - Agent 负责持续观察、评测、归因、提出优化和验证效果。 - 人负责业务目标、安全边界、重大方向和流量晋级。 - 单个 bad case 不直接触发系统性语义或策略修改；持久化 `wrong|revise` 人工反馈会在 同一 optimizer Deployment 自动启动单 ticket 调查，人工 `/ticket` 可补跑旧 case。 只有该 case 独立证明 确定性工程契约违例时，才可进入 `docs/SINGLE_TICKET_OPTIMIZER.md` 定义的单点修复。 其他单 case 问题仍需重复信号或严重事件进入 Focus。 - 当前阶段用 Recent Evaluation 和现有确定性测试判断改善与退化。 - Customer-visible automation 必须逐级晋级，且可以立即暂停和回滚。 ## 3. 已有能力与复用方式 当前不从零建设新的优化平台，优先复用： - `/ao` 反馈：作为 L1 质量信号和北极星指标来源。 - 日报：作为每日指标、异常和新增 bad case 的观察入口。 - 周报：作为趋势、场景变化和重大方向的治理入口。 - AI 与后续 L1 回复对比：作为回答质量和缺口识别的参考。 - GitHub Focus Issue：作为唯一长期优化方向、验收标准和续跑 checkpoint 载体。 - Base：作为 ticket、场景和趋势的可视化投影。 - Dry-run / replay：作为修改前后验证和回归评测执行方式。 - `evaluate:recent`：读取唯一 Active Focus Issue，将同类 recent target/control cases 通过同一 dry-run 契约重跑，并按统一标准输出本次 finding；不另建选题来源。 - 现有测试与 staging：作为确定性契约和上线前验证手段。 这些能力目前主要是独立运行。近期重点是编排它们，而不是增加新的数据链路。 ## 4. 运行闭环 ```text Ticket 结果与 L1 反馈 -> 滚动指标更新 -> Daily 逐 ticket 分析（不创建 Issue、不做修复计划） -> 无 Active Focus 时聚类最近 Daily artifact 并运行 baseline gate -> GitHub Focus Issue 聚合一个长期方向 -> Baseline checkpoint -> Agent 候选改进与 candidate branch checkpoint -> Tests / Challenger checkpoint -> Draft PR -> Shadow 或 Canary 验证 -> 保留、扩大或回滚 -> 重新进入指标观察 ``` ### 4.1 快速闭环：小时级到每日 快速闭环负责发现问题和准备改进，不等待周会。 - 每 2 到 4 小时刷新滚动质量信号。 - 每天运行一次增量 Evaluation。 - Daily 只记录逐 ticket 事实和问题信号，不每天重新制定修复方向。 - 当前 Focus Issue 保持同一方向，Agent 每天从最后 checkpoint 继续；只有不存在 Active Focus 时才允许自动选择下一个窄方向。 - 低风险改进可以每天形成带评测证据的 Draft PR。 立即触发条件： - 出现 `/ao wrong`。 - 出现客户 raise 或明确纠正。 - Auto-oncall 引起 L1 实质性补充或纠正。 - 同类问题在滚动窗口内重复出现。 - Accept Rate、人工介入率或处理失败率显著恶化。 - 安全、越权、重复写入或错误操作风险立即暂停对应场景。 ### 4.2 慢速闭环：每周治理 每周不是开始优化，而是治理已经持续运行的优化闭环： - 复盘北极星指标和 10% 目标进度。 - 确认反复出现的主要根因和投入优先级。 - 决定是否扩大或收缩支持场景。 - 决定是否提升 Shadow、Canary 或自动回复流量。 - 审核重大 gate、工具、权限和业务策略调整。 - 清理无效、重复或长期没有收益的优化方向。 ## 5. Evaluation 机制 当前阶段只运行 Recent Evaluation。系统刚启动、case 数量较少，能力下降可以从最近真实 ticket 中直接观察，暂不建设固定 Regression Evaluation。 完整的当前执行逻辑、Focus/target/control 定义、baseline/challenger、candidate gate、状态与失败语义见 `docs/AUTO_ONCALL_EVALUATION.md`。本节只保留长期原则， 实现语义以该文档和 contract tests 为准。 ### Recent Evaluation - 使用最近真实 Auto-oncall ticket。 - 用于发现新问题、数据变化和场景漂移。 - 优先使用 Auto-oncall 输出、`/ao` 反馈和后续 L1 实质回复。 候选改进只有同时满足以下条件才可进入下一阶段： - 目标 bad case 或目标场景有明确改善。 - Recent Evaluation 没有发现明显退化。 - 没有违反确定性安全、权限、证据和写入契约。 - 结果不是只优化单个 case 的措辞。 当 case 数量、覆盖场景或自动修改频率明显增加后，再从 Recent Cases 中沉淀固定 Regression Evaluation。 ## 6. Bad Case 与优化优先级 Bad case 先归因，再决定是否修改： - 回答质量：结论错误、不完整或没有回答核心问题。 - Knowledge / Skill：缺少稳定的领域知识或诊断步骤。 - Tool / Data：没有取得、读取或正确使用已有证据。 - Context：输入缺失、附件失败或上下文选择错误。 - Gate / Policy：场景、风险或自动化边界判断错误。 - Evaluation：配对、指标或评判本身错误。 - Runtime：认证、超时、部署或外部依赖失败。 - Non-actionable：上下文变化、偏好差异或没有稳定证据。 优化优先级按照以下顺序决定： 1. 客户风险和错误回答。 2. 对 AO Accept Rate 影响最大的重复问题。 3. 阻碍 10% 覆盖目标的高频问题。 4. 可以通过低风险改动快速验证的问题。 5. 单次、低影响或无法验证的问题暂不修改。 ## 7. Agent 与人的职责 Agent 默认负责： - 持续追踪指标和异常。 - 聚类和去重 bad case。 - 做初步根因分析。 - 运行 Recent Evaluation。 - 准备低风险候选改进、测试和 Draft PR。 - 在没有 Active Focus 时，从最近 Daily artifact 中聚类重复问题，并在 baseline 门槛通过后创建下一个窄 Focus。 - 汇总上线后的指标变化并提出保留或回滚建议。 人保留： - 修改业务目标和指标口径。 - 改变安全、权限和客户可见边界。 - 选择新的大场景方向。 - 批准自动回复流量晋级。 - 批准生产发布和高风险改动。 目标是让人从日常辅助者变成策略审批者和异常处理者。 ## 8. 自动化晋级路径 ```text Internal Draft -> Shadow Evaluation -> Human-confirmed Customer Reply -> 1% Autonomous Canary -> 3% -> 5% -> 10% ``` 每次晋级必须满足： - AO Accept Rate 达到当前阶段要求。 - Feedback Coverage 足够支撑判断。 - 没有不可接受的 wrong、raise 或安全事件。 - L1 再次实质回复率处于可接受范围。 - Recent Evaluation finding 为 `criteria_met`。 - 已完成一个完整观察窗口。 任何严重事件都可以立即暂停对应场景，不影响其他稳定场景。 ## 9. 当前阶段 当前处于：**建立并运行持续优化机制，而不是扩大客户可见自动化。** 当前重点： 1. 用现有数据形成每日北极星指标追踪。 2. 建立每日 Recent Evaluation 节奏。 3. 用唯一 GitHub Focus Issue 跨天持续解决同一问题方向。 4. 让 Agent 对高优先级问题完成归因、验证和候选方案准备。 5. 连续观察闭环运行效果，再决定需要产品化哪些缺口。 当前执行入口： ```bash npm run evaluate:recent npm run optimize:recent:daily ``` 唯一 Active Focus 保存在一个带 machine-readable contract 的 GitHub Issue。仓库不保留 Active Focus manifest fallback。Issue 状态只表示生命周期：`active`、`awaiting_authorization`、`blocked`、`human_handoff`、`ready_to_close`、`closed`。 当前 Active Focus 只以 GitHub Focus Issue 为准；没有 Active Focus 时，staging Daily Recent Optimizer 自动尝试创建下一个 Focus。 每日自动迭代契约： - 日报只产出指标和逐 ticket 分析，不创建 GitHub Issue，也不生成修复计划； 无 Active Focus 时，selector 只读取 DB 中已经持久化的日报 artifact 和原始 `/ao wrong|revise` 信号。 - 自动选题必须形成至少 2 个同根因 target；control 为 0～2 个可选观察样本， 找不到时忽略。宽泛主题、单个 bad case、生产操作、产品修复、业务 gate 扩权 和客户可见自动化都不能成为自动 Focus。 - 自动修改只接受同一个最早断点、同一个实现 owner、单一 evidence-chain stage 且全部 为普通非 protected path 的简单通用问题。独立前置可以继续拆成 Dependency Focus， 不限制固定深度，但每层都必须由至少两个当前 target 的同一 earliest failure point 证明，并产生可由每案 replay artifact 验证的 runtime 状态前进或稳定失败归属。 如果 prerequisite 与 parent repair 使用相同的 current gap cases、stage 和重叠的精确 implementation target，它只是同一 owner 内完成父修复所需的诊断或观测步骤，不是独立 Dependency。普通单 stage owner 直接留在 parent repair；protected 或无法安全自动完成时 在 parent 上转 `human_handoff`，不得再创建只补失败分类或 trace 的 child Focus。 optimizer planning/validator/authorization 等流程自举依赖、protected implementation 或跨 stage 修复写入 `human_handoff`，保留 Issue 和有界证据给人工处理，不启动写 Agent；该 Issue 不再占用 Active Focus，下一选题时段可改进其他简单问题。 - 单个 target 独有的 earlier failure 不创建 Dependency Focus。现有只读 planning session 直接作为 manager：仅当源码证明一个精确、普通且非 protected owner 时，允许一次只改 该 stage/owner 的 inline unblock；不得同时修父问题或加入 case data、target 猜测、 fallback、凭据、部署和 optimizer 改动。无法安全直修或同 case/stage 尝试无效时，按 current base/status/failure codes 写 `case_blocker`。同 base/签名不再重试，也不把它算作 通过；至少剩余两个未阻塞 target 才继续当前 Focus，否则转人工。 - Dependency Focus 达到 `ready_to_close` 或 `closed` 后，直接父 Focus 恢复 Active 并 重新做 fresh baseline；dependency 达标不等于父 criterion 达标，也不会直接关闭父项。 - 连续三个完整 attempt 都没有 confirmed blocking improvement，且计划在至少三个不同 implementation target 间轮换时，也视为复杂度证据并转人工；这不会关闭 Issue 或把 未解决问题冒充为退休/优化完成。 - 候选 Focus 必须先在当前 `main` 运行 fresh baseline。target 执行不完整、blocking target 已达标或不确定时不创建 Issue；control 不稳定或执行失败不阻止创建。 - 创建成功后持久化 baseline 与 `case_refresh` 并结束当次任务；下一轮才进入候选修改。 - 每个日报 case 使用稳定 problem-signal source ref；历史 Focus 只消费其已经解决或 正在处理的具体 problem signal，不因同一 ticket 的另一个问题而整体去重。 - Focus Issue 是唯一 source of truth；它显式记录本轮 blocking criteria，`case_refresh`、baseline、candidate branch、tests、challenger、candidate gate、Draft PR 都以 comment checkpoint 持久化。 - Focus 创建时必须把所选 problem signal 已有的 optimization status、attempted action 和 evidence 保存为 selection context；后续 attempt 不得原样重复已证明无效或仍是 candidate 的动作。 - 每次任务先在当前 `main` 上重新读取 Jira 并运行 fresh baseline；历史 replay cutoff 保持不变，不能把后续人工回复泄漏给 Agent。 - 每次 baseline/challenger evaluation 后必须追加最新 `case_refresh`；下一轮候选分析优先读取最新的 bounded case results 和既有 attempt evidence。 - accepted、未完成 gate、或被人工转成 ready-for-review 的现有 PR 可以阻止重复创建 candidate；明确被 gate 判定为 needs-work 的 Draft PR 在下一轮先保存 evidence 并 关闭，再生成更高 attempt。任何现有 PR 都不能跳过当天的 fresh baseline 与 `case_refresh`。 - 只允许续跑与当前 base SHA 一致的 candidate。controller base 前进后，旧 baseline/challenger/candidate 仅作为历史 evidence，不自动重新 gate，也不作为当天结果。 - Evaluation finding 只有 `gaps_found`、`criteria_met`、`inconclusive`；发现 gap 是正常产出。只有命令、契约或 API 执行异常才使任务失败。 - Draft PR gate 只要求所有 target 的 blocking criteria 满足。非阻断 gap 和 baseline regression 必须写入 PR 作为 review evidence 与后续 Focus 输入，但不阻止 Draft PR 生成。 - daily task 只在没有 Active Focus 时按上述门槛自动选择下一个 Focus；不 merge、 不部署、不写 Jira，也不扩大客户可见自动化；每个终态结果只发送一条幂等 Feishu 摘要。 Customer-visible reply、生产权限和流量晋级不在当前阶段自动开启。 ## 10. 后续执行规则 后续所有持续优化工作都遵循本文件： 1. 开始前确认本文件中的目标、指标和当前阶段。 2. 新方向先更新“当前阶段”或记录明确决策，再修改实现。 3. 每次优化都要说明触发信号、目标场景、Evaluation 和预期指标影响。 4. 完成后记录实际指标变化、回归结果和保留/回滚结论。 5. 如果实际工作与本文件冲突，先修改并确认本文件，不直接扩大实现。 其他日期型 plan 是具体问题的历史或执行材料。本文件是长期持续优化的唯一主入口。