2026/02/28
生产级智能体部署的三层证据链
作者: 瀚铄智擎工程团队
本文面向生产级智能体项目的建设、交付与运维团队，目标是把“系统可运行”升级为“系统可证明”。所谓可证明，是指任何一次关键输出都能回答四个问题：谁触发、依据是什么、系统状态如何、责任链如何闭合。
1. 问题定义
在生产环境中，智能体的争议通常不在模型本身，而在证据链缺失。常见表现如下：
- 仅保留最终回答，缺失中间执行轨迹。
- 知识引用无定位信息，无法快速复核。
- 运行指标与业务结果脱节，无法解释故障原因。
- 审批和策略变更记录分散，责任难以界定。
三层证据链的目标是把“任务事实、系统事实、治理事实”统一到同一条可检索主链上，保障上线验收、审计抽检和故障复盘均有客观依据。
2. 三层证据链模型
三层模型采用“分层采集、统一索引、按需回放”的组织方式。
| 层级 | 证据对象 | 核心回答问题 | 典型记录 |
|---|---|---|---|
| 任务执行层 | 单任务生命周期 | 做了什么、引用了什么、输出如何生成 | 输入摘要、工具调用链、证据引用、结果码 |
| 系统运行层 | 服务与资源状态 | 当时系统是否在可控状态 | 版本快照、时延、吞吐、失败率、回滚事件 |
| 治理审计层 | 制度与责任链 | 谁批准、谁变更、谁签署 | 权限审批、策略版本、验收签署、例外放行 |
三层通过统一主键关联：request_id、task_id、trace_id。其中 request_id 用于跨系统检索，task_id 用于任务级回放，trace_id 用于系统链路追踪。
3. 第一层：任务执行证据
3.1 最小字段清单
| 字段 | 含义 | 采集时机 | 是否必填 |
|---|---|---|---|
| request_id | 请求唯一标识 | 接入网关 | 是 |
| task_id | 任务唯一标识 | 调度创建 | 是 |
| operator_id | 操作主体 | 提交任务 | 是 |
| prompt_digest | 输入摘要哈希 | 调度前 | 是 |
| tool_trace | 工具链记录 | 执行中 | 是 |
| evidence_refs | 证据定位集合 | 输出前 | 是 |
| output_digest | 输出摘要哈希 | 输出后 | 是 |
| result_code | 成功/失败/回滚 | 结束时 | 是 |
| ended_at | 完成时间 | 结束时 | 是 |
3.2 工具调用记录规范
工具链记录至少应包含：工具名、参数摘要、返回码、耗时、重试次数、补偿动作。
{
"tool": "knowledge_retrieval",
"status": "ok",
"latency_ms": 184,
"retry": 0,
"args_digest": "9df0b8f1",
"response_code": "200"
}
3.3 证据引用规范
证据引用不应只有“来源名称”，还应包含“定位信息 + 版本信息 + 可信度”。
{
"source": "policy_repo",
"locator": "node_id=policy_208;chapter=4.2",
"version": "v2026.01",
"confidence": 0.94
}
4. 第二层：系统运行证据
系统运行证据用于解释“任务结果是否受系统异常影响”。建议分钟级采集快照，关键指标如下。
| 指标 | 口径定义 | 目标示例 | 说明 |
|---|---|---|---|
| 端到端 P95 时延 | 提交到结果返回的 95 分位耗时 | ≤ 2.5s | 按业务高峰统计 |
| 工具调用成功率 | 成功调用次数/总调用次数 | ≥ 99.0% | 包含重试后成功 |
| 回滚成功率 | 回滚成功次数/回滚触发次数 | ≥ 99.5% | 需保留回滚证据 |
| 调度成功率 | 成功完成任务/总任务 | ≥ 98.5% | 按日统计 |
| 审计链完整率 | 三层证据完整任务占比 | = 100% | 不达标即阻断发布 |
每次生产发布必须固化以下快照：
- 版本号与变更单号。
- 生效窗口与执行人。
- 回滚版本与触发阈值。
- 关键参数变更明细（并发、超时、限流、路由权重）。
5. 第三层：治理审计证据
治理层用于确认“流程是否合规、责任是否闭合”。
| 治理事项 | 证据内容 | 保留周期 |
|---|---|---|
| 权限变更 | 申请单、审批链、执行记录 | 不少于 12 个月 |
| 策略发布 | 版本差异、审批人、回退记录 | 不少于 12 个月 |
| 验收签署 | 测试报告、门禁结果、签署页 | 不少于 24 个月 |
| 例外放行 | 放行原因、期限、责任人 | 全量长期留存 |
建议采用 RACI 矩阵定义责任边界：
| 事项 | R 负责 | A 审核 | C 协同 |
|---|---|---|---|
| 生产发布 | 平台工程师 | 项目负责人 | 安全审计 |
| 策略调整 | 规则工程师 | 合规负责人 | 业务负责人 |
| 例外放行 | 业务主管 | 合规负责人 | 运维值班 |
| 验收签署 | 项目经理 | 甲方代表 | 测试/运维 |
6. 统一关联与一键复盘
6.1 主链设计
主链推荐为：request_id -> task_id -> trace_id -> audit_id。
request_id：跨系统检索入口。task_id：任务级证据主索引。trace_id：系统运行证据定位键。audit_id：治理事件与审批链索引。
6.2 复盘流程
function replay(request_id):
task = load_task_evidence(request_id)
runtime = load_runtime_snapshot(task.trace_id)
governance = load_governance_events(request_id)
if missing(task) or missing(runtime) or missing(governance):
return "证据链不完整，触发审计告警"
return {
"input": task.prompt_digest,
"tool_chain": task.tool_trace,
"evidence": task.evidence_refs,
"system_state": runtime.metrics,
"governance": governance
}
7. 验收口径
上线验收应采用“门禁 + 抽检 + 演练”三段式。
7.1 门禁条件
- 关键任务路径通过率 = 100%。
- 审计链完整率 = 100%。
- 高风险缺陷数 = 0。
- 回滚演练成功率 = 100%。
7.2 抽检要求
| 抽检对象 | 数量建议 | 验收标准 |
|---|---|---|
| 常规成功任务 | ≥ 30 条 | 三层证据完整可回放 |
| 失败任务 | ≥ 10 条 | 有失败原因与补偿记录 |
| 例外放行任务 | 全量 | 有审批链与有效期 |
7.3 演练要求
- 单节点故障切换演练。
- 策略误发回滚演练。
- 审计追溯查询演练。
- 任务失败补偿演练。
8. 上线前 Checklist
- 三层字段清单冻结并评审通过。
- 三层日志已实现主键关联。
- 任意任务可在 3 分钟内完成证据回放。
- 发布、回滚、例外放行均有标准审批模板。
- 审计抽检脚本可自动输出缺失项报告。
- 运维与合规团队完成联合演练。
9. 结语
生产级智能体的核心竞争力不只是生成能力，而是“结果有依据、过程可追踪、责任可闭环”。三层证据链是将智能体系统从试点能力升级为生产能力的关键基础设施。