Trace 检查清单

运行 scripts/run-interview-demo-check.ps1 后，用这份清单检查 trace-response.json 和 interview-demo-summary.json。

1. Session

JSON path	检查点	面试讲点
`data.runId` / `data.run.runId`	是否等于 demo 响应中的 `runId`	`runId` 精确绑定这一次诊断运行
`data.run.sessionId`	是否等于本次 Chat 请求的唯一 sessionId	`sessionId` 保留多轮上下文，Trace 精确回放依赖 `runId`
`data.run.query`	是否包含支付超时问题	Trace 记录了原始用户意图
`data.run.answer`	是否包含最终诊断答案	最终答案没有脱离 Trace
`data.run.selfEvaluation`	是否包含 verifier 或 rule evaluation	答案经过质量门，不只是模型原始输出
`data.run.selfEvaluation.verifier_evaluation.gatekeeper_result.rule_set_version`	是否记录 Gatekeeper 规则版本	安全规则可审计、可回归
`data.run.selfEvaluation.verifier_evaluation.prompt_audit.version`	是否记录 Prompt 审计版本	Prompt 变更可解释、可回归
`data.run.selfEvaluation.verifier_evaluation.prompt_audit.prompts[*].version`	是否记录 planner / executor / verifier / composer 版本	便于定位 Prompt 变更影响
`data.run.feedback`	提交反馈后是否变为 `useful`	用户反馈挂在当前 diagnosis run 上

2. StateGraph 路由

JSON path	检查点	面试讲点
`data.run.orchestrationTrace.version`	是否存在当前 trace contract 版本	路由摘要可演进、可兼容
`data.run.orchestrationTrace.transitions[*]`	是否记录实际经过的 Node 和 route	Graph 条件边不是从日志推断
`data.run.orchestrationTrace.final_node`	最终是 Composer 还是 Fallback	正常输出与安全降级明确区分
`data.run.orchestrationTrace.termination_reason`	是否给出终止原因	每次 Run 都有可解释终点
`data.run.orchestrationTrace.degraded`	是否发生安全降级	fallback 是可审计行为
`data.run.orchestrationTrace.evidence_retry_count`	是否为 0 或 1	补证据循环有硬上限
`interview-demo-summary.json.finalNode` 等摘要字段	是否与 exact Trace 一致	summary 只消费 Run 路由真理源

orchestrationTrace 负责路由；selfEvaluation 负责证据和答案质量；AgentStep/ToolInvocation 负责详细执行与工具证据。三者不能互相替代。

3. Agent 步骤

JSON path	检查点	面试讲点
`data.steps[*].agentName`	是否有 Planner / Executor / Verifier 或等价步骤	流程被拆成可检查的 Agent 步骤
`data.steps[*].thought`	是否有高层步骤摘要	内部过程可审计，不只看最终文本
`data.steps[*].durationMs`	是否有步骤耗时	Trace 可用于耗时分析
`data.steps[*].tokenCount`	如可用，是否记录 token	Trace 可用于模型成本分析

4. 工具证据

JSON path	检查点	面试讲点
`data.toolInvocations[*].toolName`	是否包含 `lookup_knowledge`、`query_logs`、`query_metrics` 等证据工具	Agent 通过工具收集证据，而不是无依据猜测
`data.toolInvocations[*].inputParams`	是否能看到每个工具的入参	工具输入可审计、可调试
`data.toolInvocations[*].outputPreview`	是否有受控长度的证据预览	保留证据但不倾倒巨大 payload
`data.toolInvocations[*].success`	是否区分成功和失败	工具失败对 Verifier 和 reviewer 可见
`data.toolInvocations[*].retrievalDetails`	是否包含检索 metadata	检索质量可事后检查
`data.toolInvocations[*].retrievalDetails.evidence_refs`	是否包含 `raw_path + text`	Gatekeeper 可以用代码核对 Executor 引用
`data.toolInvocations[*].relevanceLevel`	是否有相关性等级	可解释检索结果强弱

5. Summary

JSON path	检查点	面试讲点
`data.summary.persistedStepCount`	step 行是否持久化	Trace 来自存储，不是响应内存
`data.summary.persistedToolCallCount`	tool 行是否持久化	工具证据在请求结束后仍可回放
`data.summary.hasVerifierEvaluation`	是否存在 Verifier 结果	最终答案经过质量门
`data.summary.hasFeedback`	提交反馈后是否为 true	人类反馈闭环完成

6. 好的结果长什么样

同一个 session id + run id
-> 最终答案
-> 持久化 agent steps
-> 持久化 evidence tool calls
-> verifier / self-evaluation
-> run.orchestrationTrace routing summary
-> feedback attached to the same run

4.6 KiB Raw Blame History