流水线飞轮

当流水线故障时，你需要的不是更多日志

当前流水线系统在故障发生时，往往只能打印错误信息或进行简单重试，无法自动牵引到修复方案。修复过程依赖人工介入，响应时间长，且不同流水线的故障知识无法共享和复用。更严重的是，缺乏统一机制来评估流水线的健康度，难以判断是模型问题、参数配置错误还是基础设施故障。

核心能力与关键步骤

故障牵引修复流程：从错误文本中提取特征，匹配内部教训库给出修复建议。例如，当出现 401/403 错误时，自动建议检查 provider 配置或更换 API Key。

流水线飞轮接入标准：任意流水线只需两步即可接入——注册流水线后运行飞轮。飞轮自动记录运行次数、修复次数、错误特征和匹配的教训，形成结构化 Trace。

满意度评估与自动重试：内置 evaluate_and_retry() 函数，以 satisfaction_threshold=0.7 为阈值，最多重试 max_retries=2 次。失败时记录到飞轮并标记待人工处理，避免无限循环。

知识体系闭环：通过三环飞轮（内环正向反馈、中环 trust 校准、外环质量校准）持续沉淀知识。错误 Pattern 自动分类为 vendor_error（如 401/403/404/rate limit/timeout）、user_error（如参数/格式问题）或 harness_defect（其他未匹配错误）。

健康度评估：五维健康分（成功率 40%、延迟 20%、Token 用量 10%、错误分布 15%、Pattern 覆盖率 15%）帮助快速定位瓶颈。建议使用滚动时间窗口（默认 1 天），避免历史批量故障永久压低健康分。

适用边界与注意点

• Trace 表独立存储：高写入的 trace 表需独立数据库文件，避免与主事实库争抢写锁导致 database is locked。
• 飞轮写入失败降级：trace 写入失败时仅降级提示，不回滚主任务结果，可保留 JSONL 文件作为二次 fallback。
• 自动修复安全白名单：自动 apply 仅对命中 model.default/provider/config.yaml/prompt/cron/retry/timeout/fallback 关键词的补丁生效，未命中的仅生成 diff 不自动 apply。
• 延迟统计过滤：统计延迟时必须过滤 latency_ms=0 和数量级异常值（>24h），否则均分会失真。
• 最小侵入原则：接入只需在 cron prompt 中加 1-2 行调用，不改用户配置，所有事件写入持久存储可查询审计。