AI代理审计日志要记什么：从提示词到工具结果都要能回放

Written by

普通API出问题，通常看请求、响应、状态码就能定位一大半。AI Agent不一样。一次用户请求可能包含多轮模型推理、多个工具调用、几次重试、一次回退和若干中间结果。

如果没有审计日志，问题发生后就很难回答：模型为什么这么做？调用了哪个工具？参数是谁生成的？结果有没有被改写？这也是AI中转站必须补上的能力。

先记录请求身份

审计的第一步是知道“谁发起了请求”。至少要记录：

这些信息不是为了多收集数据，而是为了出问题时能做归因。没有身份，后面的模型和工具日志都很难解释。

Agent请求经常会经过模型路由。审计日志里不只要写“用了哪个模型”，还要写为什么用了它。

例如：

这样才能判断一次异常结果是模型能力问题、路由策略问题，还是预算策略导致的降级。

提示词审计最容易踩坑。一方面，没有提示词就无法复盘；另一方面，提示词里可能包含用户隐私、业务数据和密钥片段。

更稳的做法是保存脱敏后的提示词、模板版本、变量摘要和哈希值。需要深度排障时，再按权限查看原始内容。不要把所有原始提示词无差别写进普通日志。

Agent真正的风险通常出现在工具调用上。审计日志至少要记录：

如果工具涉及写操作，还应记录审批状态、执行人和资源ID。这样才能在问题发生后还原动作链。

审计日志不是越多越好，而是要能回放。一次完整链路最好能按时间线展开：用户请求、模型响应、工具调用、工具结果、下一轮模型、最终输出。

有了这条时间线，排障人员不用猜模型“可能想了什么”，而是能看见它在每一步拿到了什么信息、做了什么动作。

如果Agent应用各自记录日志，字段和口径很容易不同。统一AI中转站则可以在请求入口处标准化审计格式，把模型调用、工具调用、成本和延迟放进同一条链路。

https://top-api.cc 这类统一入口适合做这件事：它不只负责转发请求，也能帮助团队沉淀可追踪的调用链，为排障、安全复盘和成本分析提供依据。

AI代理审计日志不是合规装饰，而是生产系统的黑匣子。身份、模型、提示词、工具、参数和结果都能回放，团队才敢让Agent承担更复杂的任务。