《Agent面试详解》系列：上篇：运行时与上下文 · 中篇：记忆、工具与并发 · 下篇：评测、安全与落地

上篇解决运行时和上下文，中篇解决记忆、工具与并发。系统现在能够持续执行、恢复和控制副作用，但还缺少判断“做得对不对”的能力。

Agent 的困难恰恰在这里：同一个任务可以走出不同轨迹，最终答案看起来正确，过程中却可能越权、浪费预算或依赖错误证据。下篇从 Trace 和测试开始，最后回到安全、产品方向和一道完整系统设计题。

没有 Trace，就调不好 Agent

普通服务的一次请求通常很短，Agent run 却可能跨越几十个模型轮次、工具调用、重试和人工审批。只记录最终答案，几乎无法定位问题。

每次 run 至少应该记录：

• 模型、版本、推理档位。
• Prompt、Tool Schema 和策略版本。
• 每一次状态迁移。
• 工具参数、结果摘要和原始结果引用。
• Token、延迟、缓存命中和费用。
• 错误分类、重试原因和退避时间。
• 人工审批的请求、参数和决定。
• 最终完成证据。

Trace、log 和 audit 不是同一个东西。Log 服务于排障，Trace 还原执行轨迹，Audit 证明谁在什么权限下改变了什么。审计记录不能被 Agent 自己修改。

一条可用的 trace 还要能串起模型调用、工具调用和业务状态。只有时间戳而没有 run_id、step_id、tool_call_id 与状态版本，日志再多也只是分散的碎片。

Agent 应该怎么测试

Agent 的灵活性越强，单次输出越不稳定，越不能只靠几个