Personal Project · Open Source
PayTrace
把支付转化异常归因，从「可能是渠道问题」变成可复核的证据链。
证据驱动的支付转化异常归因与诊断 Agent：确定性损失拆解定位「哪里损失、损失多少」，受 Hook 链治理的诊断 Agent 在证据契约约束下回答「为什么」。全程模拟数据与可配置故障注入，不接入真实支付渠道，不使用真实用户隐私数据。
业务问题与个人职责
业务问题：支付完成率下降时，看板只能说明「下降了」，日志只能解释单次请求，而错误码、优惠变更和配置发布可能同时出现——相关不等于因果。我独立完成从事件模型、确定性损失账本到诊断 Agent 与评测体系的设计和实现。
系统链路
- 支付事件
- 统一漏斗
- 损失拆解
- Incident 冻结
- 只读调查
- 证据登记
- 多根因诊断
- 人工处置
工程重点
- Deterministic Core
- 九阶段漏斗与购买意图关联由确定性代码计算，损失数值可精确复算——模型不参与事实计算。
- Governed Investigation
- 工具调用走 Before/After Hook 链：参数与 Incident 范围校验失败即阻断，大结果外置为 Artifact，上下文只留摘要与引用。
- Evidence Contract
- 每条结论必须绑定证据 ID，结论分 SUPPORTED / PARTIAL / UNKNOWN 三级——UNKNOWN 是防止模型硬凑答案的合法输出，不是失败。
可验证证据
- Data
- 全量模拟数据 + 故障注入 · 无真实渠道与隐私数据
- Eval
- 双轨评测 · 结果评测 + 轨迹评测
- Stability
- 按 pass^k 连续可靠性口径，而非 pass@k
- GT Leak
- Ground Truth 隔离 · 评测器主动检查泄漏
Python · FastAPI · PostgreSQL · Redis · MCP · 显式 FSM · 故障注入 · pytest
设计取舍
-
确定性代码算事实，模型只负责组织调查
- 为什么
- 损失数值必须精确可复算，而根因假设需要在不确定信息中逐步收敛——这两件事的最优解不一样。
- 代价
- 每个指标、每次拆解都要显式建模并测试，没法靠模型「顺便」算出来；数据契约一变，改动全落在代码侧。
-
诊断过程受 Hook 链治理，而不是让 Agent 自由探索
- 为什么
- 越权调用、上下文膨胀、过程失忆是 Agent 的固有问题，靠 Prompt 提醒解决不了。
- 代价
- 读侧降级、写侧阻断的语义要为每个工具单独定义，工具接入成本明显高于直接暴露一个查询接口。
-
把 UNKNOWN 作为合法结论输出
- 为什么
- 证据不足时生成一个看起来完整的答案，比承认不知道危险得多。
- 代价
- 报告里会明确出现「没有结论」的情况，必须有人工复核接管；评测也要专门检查 UNKNOWN 是否正确触发，而不是被模型跳过。
-
全量模拟数据 + 可配置故障注入，不接入真实支付渠道
- 为什么
- 真实支付数据涉及隐私与合规风险；而带 Ground Truth 的故障注入才能做稳定演示、自动评测和版本回归。
- 代价
- 无法证明真实商户环境下的业务收益，模拟分布也不等同于任何一家真实支付平台——这条边界必须在项目里显式声明，不能含糊过去。
系统不负责清单
刻意划出的非目标。写下来的边界才是能守住的边界。
- 不执行支付、不保存卡信息与支付凭据
- 不自动修改渠道、路由、风控或优惠配置——高风险动作留给人工
- 不接入真实支付渠道，不使用真实用户隐私数据
- 不把「预算内未发现」说成「没有问题」
- 不输出未绑定证据的归因结论
- 不把相关性解释为因果关系
开放问题
目前还没有答案的部分。欢迎就其中任何一条追问。
- 故障注入的分布由人工设计，覆盖不到真实生产中尚未被记录过的失败形态
- 结果评测与轨迹评测的权重如何组合，还没有稳定的校准方法
- 从生产 Trace 回流真实 Bad Case 是规划中的方向，当前评测集仍以注入场景为主
- 模拟数据能证明诊断能力与版本间的相对改进，不能证明线上收益——这条结论本身就是项目的诚实边界