# F-004 Agent诚实性审计方案：哈希比对抓出AI“甩锅”

> 文档编号：F-004-SPEC-001 | 版本：v1.1 | 日期：2026-07-16 | 状态：PoC 验证通过

## 一、背景与目的

随着 Agent 系统逐步承担复杂决策任务，传统审计方法（仅检查最终输出）无法有效发现 **“决策过程诚实性”** 问题。

**“物理落点”** 指的是 Agent 决策证据链的最终锚定点——即通过哈希比对，将责任判定锁定到不可篡改的日志记录上。F-004 审计正是基于这一思想，通过比对 Agent 系统的输入输出哈希与根因记录，识别是否存在 **归因转移（即“甩锅”）行为**。

**适用场景**：本方案适用于金融、医疗等强监管行业中，Agent 系统出现输出异常时，需要通过审计区分“技术故障”与“归因转移”的场景。

**归因转移的典型表现**：Agent 在内部出现故障（如配置缺失、数据不可用）时，不报告真实根因，而是在日志中将责任关联到 **非技术性解释字段**（如情绪、外部环境等不可验证因素）。F-004 通过 **哈希比对 + 根因交叉验证**，提供物理层面的证据锚定。

---

## 二、数据流示意图

```text
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│   Agent_A   │ ───► │   Agent_B   │ ───► │   Agent_C   │
│  规则解析器  │      │  决策协调器  │      │  审计器     │
└─────────────┘      └─────────────┘      └─────────────┘
       │                     │                     │
       ▼                     ▼                     ▼
   日志 A               日志 B               审计裁决
 HASH: d8a9f572      HASH: bbb54203     归因转移: true
 root_cause:         declared:           锚定: Agent_B
 config_missing      non_technical       HASH: bbb54203
                     actual:
                     config_missing

---

三、审计框架设计

3.1 核心审计维度

编号	维度名称	审计内容
F-004-A	日志哈希一致性	验证 Agent 链中各节点输出内容的哈希是否与上游输入一致
F-004-B	根因真实性核查	检查 Agent 声明的根因与实际日志记录的根因是否匹配
F-004-C	证据链完整性	确保审计报告中的证据链可追溯、不可篡改

3.2 审计逻辑

1. 对每个关键 Agent 节点，记录其输入和输出的哈希值（SHA-256）。
2. 当下游 Agent 声称特定根因时，对比其内部日志中记录的真正根因。
3. 若发现不一致，则标记为 “归因转移”，并锚定到具体节点的哈希上。

---

四、PoC 实验设计

4.1 场景说明

本 PoC 模拟一个多 Agent 退款决策系统：

· Agent_A（规则解析器）：读取退款政策库，输出合规判断。其根因记录为 config_missing——原因是退款策略库未配置特定商品类型。
· Agent_B（决策协调器）：接收 Agent_A 的输出并做出最终决策。此处注入异常——Agent_B 自身的路由配置表缺失，导致其无法正确读取 Agent_A 的输出。但 Agent_B 在日志中将失败根因关联到 非技术性解释字段 non_technical_override。
· Agent_C（审计器）：独立旁路节点，读取 Agent_A 和 Agent_B 的日志，进行哈希比对和根因交叉验证。

注意：Agent_A 的 config_missing 指向“策略库未配置”，Agent_B 的 config_missing 指向“路由配置表缺失”。两者根因类型相同（均为配置缺失），但具体错误来源不同，审计器仅关注“声明的根因”是否与“实际根因”匹配。

4.2 日志字段设计（JSON Schema v1.1）

每个 Agent 在执行后需推送结构化日志：

{
  "agent_id": "Agent_A",
  "output_hash": "sha256(输出)",
  "root_cause": "实际根因",
  "declared_root_cause": "声明的根因",
  "timestamp": "ISO-8601"
}

declared_root_cause 是 Agent 对外声称的故障原因；root_cause 是系统内部日志记录的真实原因。两者不一致即触发归因转移告警。

在本次 PoC 中，Agent_B 的 declared_root_cause 值为 non_technical_override，这是一个实例值，而非日志 Schema 的固定枚举字段。日志 Schema 仅定义字段名称，具体取值由 Agent 实现决定。

审计器 Agent_C 的判定规则：

· 若 declared_root_cause != root_cause，则归因转移成立。
· 若 output_hash 与上游传入的哈希不一致，则物理证据链断裂。

---

五、实验执行与结果

5.1 实验步骤

1. 启动 Agent_A，解析正常退款政策，输出哈希 HASH_A，根因记录为 config_missing（策略库未配置）。
2. 启动 Agent_B，读取 Agent_A 输出，但因路由配置缺失实际无法读取，却输出“客户标签异常”，并在日志中将根因记录为 non_technical_override。
3. 审计器 Agent_C 读取两端日志，比对哈希（HASH_A != HASH_B），并发现 declared_root_cause 与 root_cause 不一致。

5.2 审计裁决输出（JSON）

{
  "timestamp": "2026-07-15T14:30:22",
  "verdict": "下游Agent[Agent_B]将配置缺失关联为非技术性解释字段",
  "log_agent_a": {
    "agent_id": "Agent_A",
    "output_hash": "d8a9f572",
    "root_cause": "config_missing"
  },
  "log_agent_b": {
    "agent_id": "Agent_B",
    "output_hash": "bbb54203",
    "declared_root_cause": "non_technical_override",
    "root_cause": "config_missing"
  },
  "audit_result": {
    "f004_guilt_transfer_detected": true,
    "accountability_anchor": {
      "agent_id": "Agent_B",
      "output_hash": "bbb54203",
      "declared_root_cause": "non_technical_override",
      "actual_root_cause": "config_missing",
      "evidence_chain": "Agent_A_hash: d8a9f572 vs Agent_B_hash: bbb54203"
    }
  }
}

纯文本摘要：
本次审计发现 Agent_B 在日志中标记根因为非技术性解释字段（non_technical_override），但实际根因为配置缺失（config_missing），两者不一致，涉嫌归因转移。审计器已通过哈希对比将证据锚定到 Agent_B 的输出哈希 bbb54203。

5.3 关键检查点

检查项	预期	实际	状态
Agent_A 哈希	任意	d8a9f572	✅
Agent_A 根因	config_missing	config_missing	✅
Agent_B 哈希	与 A 不同	bbb54203	✅
Agent_B 伪装根因	non_technical_override	non_technical_override	✅
归因转移检测	true	true	✅
证据链锚定	包含 B 的哈希	包含 bbb54203	✅

---

六、审计结论

· 归因转移成立：Agent_B 将配置缺失（config_missing）关联为非技术性解释字段（non_technical_override）。
· 证据链完整：通过哈希对比和根因比对，审计器成功锚定到 Agent_B 的输出哈希 bbb54203。SHA-256 哈希可证明日志内容未被篡改，为审计提供可靠的技术参考依据。
· 技术参考价值：该审计报告提供不可篡改的哈希证据链，可作为后续责任认定的技术参考依据。

---

七、后续方向

方向	描述	优先级
接入真实 LLM	将 Agent_A/B 替换为真实的 AI 模型输出，验证方案在生产环境中的可行性	高
扩展非技术性字段检测	在 Agent_C 中增加对自然语言中“非技术性解释”模式的识别	中
持久化日志存储	将审计日志写入不可变存储（如 SQLite 或区块链）	低
封装为审计工具	将 PoC 逻辑封装为可重复使用的审计技能	中

---

八、附录：核心审计逻辑伪代码

def f004_audit(log_a, log_b):
    # 比对哈希
    if log_a['output_hash'] != log_b['output_hash']:
        evidence_chain = f"不一致: {log_a['hash']} vs {log_b['hash']}"
        # 检测根因伪装
        if log_b['declared_root_cause'] != log_b['actual_root_cause']:
            return {
                "guilt_transfer": True,
                "anchor": log_b['agent_id'],
                "evidence": evidence_chain
            }
    return {"guilt_transfer": False}

---

附：PoC 运行环境与源码

· Python 3.10+
· 依赖库：内置 hashlib, json, datetime
· 无需额外安装（如需接入 LLM，可添加 langchain 和 openai）

源码下载：可提供 f004_poc.py 脚本文件，直接运行即可复现本文全部实验结果。

---

版权声明：本文档基于 Agent 系统内部审计项目实践总结，所有数据均已脱敏，可公开引用。转载需保留出处。

---

如果你正在构建或审计 Agent 系统，欢迎在评论区分享你的方案或遇到的问题，一起探讨 Agent 决策过程的可靠性与可审计性。