一条 trace 要有什么
会话标识、用户与租户、输入来源与哈希、提示词模板版本、模型与版本、检索命中的文档编号与版本、工具调用参数与返回、输出、人工确认记录、最终去向。字段够用即可，关键是能还原当时的决策过程，而不是只留结果，字段要能支撑抽查。
来源标记比全文更重要
外部文档、用户输入与工具返回要打上来源标签，保留摘要与哈希即可，全文可另存并限权。没有来源标签，事后无法判断模型是被文档带偏还是自己编的，这两种情况的处置完全不同，否则归属判断会失真。
检测信号
异常工具调用频率、非白名单出站域名、超长或高熵输入、编码混淆、跨会话重复探测、同一文档被反复检索。信号要接告警与工单，只存不进流程等于没有监控，值班的人根本不会看到。信号还要分级，否则真正的异常会被噪音淹没。
复盘与应用例库
把每次尝试，无论成功与否，整理成用例，标注入口、手法与影响，进入季度回归。用例库是这套体系里唯一会随攻击演进而增值的资产，也是换人之后经验能留下来的地方，用例要定期淘汰过期的，值得单独列一条。
边界：日志也是数据
trace 里既有个人信息也有业务原文，存下来就等于复制了一份敏感数据。保存时长要按用途区分，能留摘要就不留全文，读取权限收紧到少数岗位。为了排查方便而全量长期保存，往往让审计系统自己变成最值得攻击的目标。
适用与不适用
适合谁
- 已上线 Agent 或 RAG 应用的企业，有真实会话，有真实需求
- 需要通过安全审计或客户尽调的团队，材料要能查
- 负责 AI 事件响应的安全运营人员，需熟悉日志
不适合谁
- 仍处于离线原型阶段、无真实会话的项目
- 不愿调整日志字段、只想补一份报告的团队
典型场景
某保险公司在客户尽调中被要求演示一次注入事件的还原过程。团队从会话编号查到上传文档、检索命中的三份条款、两次工具调用与一次人工拒绝，十分钟内出了时间线。尽调方随后只补充要求了保留期说明，未再追问。
可执行步骤
- 定义 trace 必填字段，覆盖输入来源、检索、工具调用与人工确认，列入下季度计划。
- 给外部内容打来源标签，保存摘要与哈希，全文另存并限制读取权限，按场景分类归档。
- 把异常调用、外联与混淆输入接入告警与工单，明确分级与处置时限，同步给部门负责人。
- 建立注入用例库，逐条记录入口、手法、影响与修复状态，每季补充新样例，并标注来源。
- 每季度随机抽十条会话做还原演练，测量耗时并登记发现的断点，记录在案。
- 对 trace 里的个人信息做脱敏与限权，按用途分别设定保留期，并纳入项目台账。
常见坑
- 只记用户输入与模型输出，中间的检索与工具调用全丢，出事时还原不出来，取证只能靠回忆，责任也说不清。
- 日志分散在各应用的目录里，格式与时间口径不一，跨系统根本串不起来，也拼不出时间线，检查时非常被动。
- 为排查方便把全文长期留存又不限权，审计系统自己成了新的泄露源，风险比原始数据更集中，责任难界定。
- 检出异常却不进工单，没人跟进闭环，同一种手法可以反复成功，趋势也看不出来，改进也提不出，下一次还会中招。
自检与验收清单
- trace 字段是否覆盖来源、检索、工具与确认，含工具参数
- 外部内容是否带来源标签并可追溯到文件，能打开原文
- 异常信号是否接入告警与工单并有时限，责任到人
- 是否有可回归的注入用例库并持续更新，含未成功的
- trace 中的个人信息是否脱敏并设保留期，定期清理并留痕
常见问题
日志要留多久？
按适用法规、合同与内部制度确定，不同类别可以不同。关键是能说明依据，并在到期时真正销毁。全部按最长年限保存，成本和风险都会上升，也违背最小必要，保留期要写进制度。
云厂商的 trace 能直接用吗？
可以作为基础，但通常缺业务侧的审批、来源标签与人工确认。建议在自己的网关层补齐这几项，再与云侧 trace 用会话编号关联，形成一条能互相印证的链，先对齐会话编号，建议提前对齐。
演练会不会影响生产？
用影子流量或测试租户做，避免真实用户受影响。若必须用生产环境，选低峰时段、限定范围并准备回滚，事前通知相关方，事后检查是否留下副作用，演练方案要预先评审，要预留出时间。