上线前对照清单

生产 Agent 的 trace 与审计对照清单

10 项可逐条核验的检查：run_id 贯穿、每步模型与版本记录、事后完整还原、防篡改、敏感字段治理与 per-tool 指标。用于判断出事后能否回答「它为什么这么做」。

← 对照清单

生产 Agent 出问题时，第一个要回答的不是「模型准不准」，而是「它为什么这么做」。回答不了这个问题，事故复盘、客户追问和审计要求都会卡住。trace 与审计层的目标只有一个：几周之后，仍然能从留存数据完整还原任何一次具体决策。

下面的清单按「有 / 部分 / 没有」逐条自查。每项都给出缺失时的生产后果、可执行的验证方法和补齐的第一步。严重度是通常情形下的判断，实际定级要结合系统与业务场景。

1.每次工具调用都记录参数与结果，并通过 run_id 关联到同一次运行

缺失时通常为 P1 · rubric 4.1

缺失时的生产后果: 没有 run_id 贯穿，日志只是一堆孤立的调用记录。排障时无法回答「这次错误的上下文里，前面几步各拿到了什么」。
怎么验证: 随机取一次生产运行，用 run_id 一次性查出该次运行的全部工具调用、参数和结果，中间没有断链。
补齐第一步: 在工具执行入口统一注入 run_id，并落结构化日志。

2.每一步都记录 provider、模型名和版本

缺失时通常为 P1 · rubric 4.2

缺失时的生产后果: 模型供应商的静默升级会带来行为漂移。日志里没有版本，就无法回答「这批错误是从哪个版本开始的」，也没法安全回退。
怎么验证: 抽查 trace，确认每次模型调用记录了 provider、模型名和版本或快照标识；切换到备用模型时记录随之变化。
补齐第一步: 把模型标识从运行时配置读出，写入每一步 trace。

3.几周之后，仍能仅凭日志完整还原一次具体决策

缺失时通常为 P1 · rubric 4.3

缺失时的生产后果: 客户或审计追问「当时它为什么这么做」时，只有最终回答、没有中间链路，等于没有答案。这在纠纷和合规场景里是硬伤。
怎么验证: 挑一次几周前的真实决策，仅凭留存数据重建全过程：输入、提示词版本、工具中间结果、最终动作，缺哪一环补哪一环。
补齐第一步: 先补齐最常缺的两环：提示词版本和工具中间结果的留存。

4.trace 为追加写或防篡改，普通业务账号不能删除或改写

缺失时通常为 P1 · rubric 4.4

缺失时的生产后果: 可以被随手改写的审计日志，在纠纷和合规场景里没有证明力；真实的故障时间线也可能在「清理数据」时被无意破坏。
怎么验证: 确认 trace 存储为追加写（或带哈希链、对象存储不可变策略）；用普通业务账号尝试删除一条记录，应当被拒绝并留下审计。
补齐第一步: 把 trace 的写权限收紧为仅追加，删除类管理操作单独审批和审计。

5.敏感字段在写入 trace 前有治理（脱敏、保留期），不是原样全量落盘

缺失时通常为 P1 · rubric 4.5

缺失时的生产后果: 把手机号、证件号、密钥原样写进 trace，审计层本身会变成系统里很大的泄露面，也会和个人信息保留期要求直接冲突。
怎么验证: 在输入里放一个可识别的测试敏感字段，检查落盘后的 trace 是否已脱敏或按策略处理；确认保留期与删除策略有书面文档。
补齐第一步: 先列出敏感字段清单，在写 trace 之前统一经过脱敏中间件。

6.按工具采集运营指标：成功率、延迟、错误码分布

缺失时通常为 P1 · rubric 4.6

缺失时的生产后果: 没有分工具的指标，只能看到「Agent 整体变慢了、错多了」，定位不到是哪个下游在退化，扩容和修复都无从下手。
怎么验证: 打开监控面板，确认能按单个工具查询成功率、P95 延迟和错误码分布，并能看到最近的趋势变化。
补齐第一步: 在工具执行器统一埋点，先出成功率和延迟两条曲线。

7.错误码有分级，重试链路在 trace 中逐次可见

缺失时通常为 P2

缺失时的生产后果: 重试对上层「透明」，意味着排障时看不到抖动：一次成功的背后可能是三次失败，下游容量和调用成本都被低估。
怎么验证: 找一次发生过重试的调用，确认 trace 里能看到每次尝试的错误码和最终结果，而不是只有最后一次成功。
补齐第一步: 把重试循环里的每次尝试都作为子记录写入 trace。

8.人工确认、修改和接管的动作进入同一条审计链

缺失时通常为 P1

缺失时的生产后果: 人工改动如果不进 trace，事后无法区分「Agent 做的」和「人改的」，责任边界说不清，偏差统计也会失真。
怎么验证: 找一条经人工修改后执行的任务，确认 trace 同时记录了 Agent 原始建议、人工最终动作和操作人。
补齐第一步: 让审批和接管界面的操作也发送带同一 run_id 的审计事件。

9.trace 有明确保留期和可用的检索性能，几周后的记录仍查得动

缺失时通常为 P2

缺失时的生产后果: 事故复盘和审计请求常常发生在几周之后。trace 只留几天，或查询要全表扫描，审计层就只在形式上存在。
怎么验证: 用一个月前的 run_id 实际查询一次，确认数据仍在、能在可接受的时间内返回。保留期通常以 90 天为起点，视合规要求而定。
补齐第一步: 写明保留期，并为 run_id 建立索引或独立存储。

10.每次运行记录提示词与策略版本，行为变化可以归因到具体变更

缺失时通常为 P2

缺失时的生产后果: 提示词改动和代码改动一样会改变系统行为。不记版本，复盘时无法把一批新错误归因到某次变更，回退也只能靠猜。
怎么验证: 抽查 trace，确认能看到当次运行使用的提示词或策略版本号，并能对应到版本库里的具体提交。
补齐第一步: 给提示词文件加版本号，并随每步 trace 一起记录。

先看全部支柱

这份清单只覆盖一个专题。站上的免费上线前检查按场景分流后覆盖全部支柱——数据可信与接地、工具调用、评测回归、可观测审计、安全动作与幂等、成本路由——先定位薄弱支柱，再回来逐项对照。

运行免费上线前自检

自查与付费审查的边界

清单和自检都是自报对照：结论基于你自己的判断，不做证据核验。生产就绪审查与路线图会进入系统本身——逐项核验证据、按支柱加权评分、给出 P0/P1/P2 判级和修复路线图。适合准备放权写操作、或需要一个可辩护结论的团队。

邮件 hello@ideapop.cn，附上自查结果和最不放心的一两项即可。