43 lines
1.9 KiB
Markdown
43 lines
1.9 KiB
Markdown
---
|
||
title: "Trajectory Auditing"
|
||
created: 2026-06-05
|
||
updated: 2026-06-05
|
||
type: concept
|
||
tags: [agent-safety, trajectory, audit, evidence]
|
||
sources: [[liu-auditing-agent-harness-safety]]
|
||
---
|
||
|
||
# Trajectory Auditing
|
||
|
||
**轨迹审计**（Trajectory Auditing）是以 Agent 执行的全过程轨迹（而非最终输出）为证据单元进行安全审计的方法论。由 [[harnessaudit|HarnessAudit]] 框架系统性实现。
|
||
|
||
## 核心理念
|
||
|
||
> The execution trajectory as the unit of evidence.
|
||
|
||
传统的 [[agent-safety-evaluation|Agent 安全评测]] 以最终输出或终止状态为评分依据。轨迹审计的洞见是：**大多数安全违规发生在轨迹中途而非终止时**——只检查最终输出会系统性漏报。
|
||
|
||
## 证据收集
|
||
|
||
[[harnessaudit|HarnessAudit]] 通过三类 [[hidden-audit-channel|隐藏审计通道]] 收集证据：
|
||
|
||
1. **工具调用日志**：每次 tool_call 的名称、参数、结果
|
||
2. **资源访问日志**：每次对数据库/文件系统的读写操作及权限决策
|
||
3. **组件间通信日志**：每条 inter-agent 消息的发送方、接收方、内容
|
||
|
||
所有证据以 append-only JSONL 格式记录，允许离线重新审计而无需重新运行 Agent。
|
||
|
||
## 跨框架归一化
|
||
|
||
不同骨架（Claude Code、Codex、OpenClaw）暴露不同的原生事件格式。轨迹审计通过统一的 Action Schema 归一化：
|
||
- `tool_call`：工具名 + 序列化参数 + 返回结果
|
||
- `communication`：发送方角色 + 目标角色 + 消息内容
|
||
|
||
每条 action 携带运行 ID、时间戳、全局序号、Agent ID、角色、框架原生溯源信息。
|
||
|
||
## 与轨迹优化方法的区别
|
||
|
||
- [[interleaved-gui-tool-trajectory-scaling|轨迹缩放]] 关注如何利用更多轨迹提升能力
|
||
- [[bidirectional-trajectory-evaluation|双向轨迹评估]] 关注正反方向的一致性
|
||
- 轨迹审计关注的是**安全性**而非**能力**——"正确地违规"仍是违规
|