Action Log
Action Log 把动作提交本身沉淀为可分析对象。每一次 Agent 改变企业状态的提交，都会成为一条可查询、可回放、可聚合的记录——它既是合规审计的底座，也是组织演化的数据来源。
在 AIDC 框架里，"做过什么"与"现在是什么状态"同等重要。Action Log 不是普通的系统日志，而是 Ontology 的第一等对象：ActionLog 本身就是 MVP 七个对象类型之一。动作被提交的那一刻，它就从一次副作用变成了一份组织资产。
什么是 Action Log
Agent 改变企业关键状态的唯一合法路径是提交 Action Type，不允许绕过审计直接修改底层数据。Action Log 就是这条路径的另一端：每一次 Action 提交都自动写入一条结构化记录，记录这个动作由谁发起、在什么上下文下发生、调用了什么工具、改变了什么文件。
与传统日志的区别在于三点：
- 它是对象，不是文本流 — 每条记录是 Ontology 中的一个
ActionLog对象，可以被 Link Type 关联到目标对象、发起 Agent 与所属部门，可以被查询语言聚合分析，而不是只能 grep 的文本。 - 它绑定完整因果链 — 记录的不只是结果，还有产生这个结果的输入：Agent 版本、上下文包版本、工具调用摘要。任何一条记录都能回答"当时它看到了什么、为什么这么做"。
- 它默认全覆盖 — 所有 Action 提交都写入 Action Log，没有旁路。审计覆盖率不是事后补救的指标，而是架构保证的属性。
每条记录绑定什么
一条 Action Log 记录至少绑定以下字段，构成一次状态变更的完整因果链：
| 字段 | 内容 | 回答的问题 |
|---|---|---|
actor | 发起者身份：Agent、员工或服务账号，及其所属部门 | 谁发起了这次变更 |
agent_version | 执行该动作的 Agent 版本（prompt、工具集与策略的版本快照） | 是哪一版能力做出的判断 |
context_package_id | 本次任务使用的上下文包版本，由 Context Gateway 生成 | 它当时看到了什么 |
task_id | 触发本次动作的任务标识，串联同一任务下的多次提交 | 这次变更属于哪个任务 |
action_id / action_type | 动作实例与对应的 Action Type（如 UpdateDecision）及目标对象 | 发生了什么类型的变更、作用于谁 |
tool_summary | 工具调用摘要：调用了哪些 API、脚本、模型，关键参数与返回概要 | 它是怎么做到的 |
file_diff | 本次执行对部门文件系统产生的变更摘要 | 文件层面改了什么 |
ontology_version | 提交时绑定的 Ontology 语义版本 | 在哪一版语义下解释这条记录 |
timestamp / result | 提交时间与执行结果（成功、失败、被拒绝、待审批） | 何时发生、结局如何 |
其中 task_id → context_package_id → action_id → file_diff → tool_summary 这条链路是 MVP 审计链的最小要求：每次 Agent 执行都必须完整记录这五项，缺一项就意味着这次执行不可复盘。
审计场景
Action Log 服务三类典型审计场景，分别面向运营、治理与演化：
复盘Replay & Review按 task_id 拉出一个任务的全部提交，按时间回放：Agent 先看到了什么上下文、做了哪些工具调用、提交了哪些动作、文件如何变化。由于每条记录绑定上下文包版本，复盘可以用评估器回放当时的输入，验证"换一版 Agent 会不会做得更好"——这是改进上下文路由质量的标准方法。
责任界定Accountability当一个错误决策或错误变更被发现时，沿 Action Log 可以精确界定责任层：是发起者越权（权限策略问题），是上下文包缺失关键信息（Gateway 路由问题），是 Agent 版本的判断缺陷（能力问题），还是 Action Type 校验不足（合约问题）。责任界定的对象是系统环节，而不是笼统的"AI 出错了"。
演化诊断Evolution Diagnosis聚合分析 Action Log 中的失败记录、被拒绝的提交与人工接管点，可以定位系统性缺口：某类任务总是缺少同一种上下文（Ontology 关系缺失）、某个 Action 总是被权限拒绝（权限过窄）、某个工具调用反复失败（工具缺失）。这些诊断直接输入演化闭环，见下文。
一条跨部门任务的审计链：Marketing Agent 提交 CreateWorkItem 创建 lead 跟进工单，Strategy Agent 通过 ShareContext 读取允许共享的 lead 摘要，最终提交 UpdateDecision 给出 go/no-go 结论。三条 Action Log 记录通过同一个 task_id 串联，复盘时可以完整还原"这个决策基于哪份摘要、由哪一版 Agent、在哪个语义版本下做出"。
只记录可复盘摘要
审计系统最常见的失败方式有两种：记得太少导致不可复盘，记得太多导致审计本身成为最大的敏感数据集中点。Action Log 的设计原则是取两者之间的工程平衡：
ActionLog 只记录可复盘摘要，不保存全部敏感上下文。记录的是上下文包的版本标识与构成清单，而不是上下文正文；是工具调用的参数与返回摘要，而不是完整载荷；是文件变更的 diff 摘要，而不是文件全文。复盘时按版本标识从源头重建上下文，而不是从日志里读出敏感内容。
这条原则带来三个直接后果：
- 审计可读 — 每条记录是人能在一屏内读完的摘要，而不是数兆字节的原始转储。审计不可读，等于没有审计。
- 权限不被旁路 — 如果日志保存了完整上下文，那么"读日志"就成了绕过 权限模型 读取敏感数据的后门。只存摘要与版本指针，重建上下文仍需经过原有的权限裁决。
- 成本与留存可控 — 摘要级记录可以长期留存以满足合规要求，而源数据按各自的生命周期策略管理，二者解耦。
可靠性：审计链不允许有缺口
审计链的价值取决于它的连续性。AIDC 在 可靠性模型 中为 Action Log 设计了两层保障：
| 机制 | 行为 |
|---|---|
| Local Audit Buffer | 每个 Agent Cell 内置本地审计缓冲：即使中央日志短暂不可用，本地审计链也不中断，恢复后补发 |
| 事件总线重试 | Action Log 写入走事件总线，支持重试、死信队列与幂等消费，避免重复或丢失记录 |
| 降级策略 | 中央 Context Gateway 短暂不可用时，Cell 仅处理低风险本地任务、高风险动作暂停——保证"无法审计的高风险动作不会发生" |
反哺演化闭环
Action Log 不只是向后看的审计工具，更是向前看的演化燃料。Evolution Loop 的七个阶段中，前两个阶段直接消费 Action Log：
- Observation — 从 Action Log 聚合任务成功率、失败原因、上下文缺口与人工接管点。没有 Action Log，观察阶段只能依赖主观汇报。
- Diagnosis — 沿记录的因果链判断问题归属：工具缺失、权限过窄、Ontology 关系缺失、提示策略不佳，还是流程设计问题。每条记录绑定的
agent_version与context_package_id让诊断可以精确到环节。 - Proposal → Approval → Deployment → Measurement — 改进提案灰度发布后，新旧版本的 Action Log 记录成为对比指标的数据源：同类任务在新版 Agent 下成功率是否提升、人工接管是否减少。
- Ontology Update — 确认有效的改进最终沉淀为 Object、Link、Action、Interface 的语义更新，下一轮 Action Log 在新语义版本下继续累积。
这构成一个完整回路：动作产生记录，记录驱动诊断，诊断改进系统，改进后的系统产生更好的动作。组织的每一次执行都让下一次执行更可靠——这正是"公司即计算机"叙事里，Action Log 作为系统调用追踪层的意义。
Action Log 驱动演化，但不能驱动自动演化的越界：高权限 IAM 策略、密钥管理、跨部门敏感数据共享规则与生产环境破坏性动作，即使诊断指向它们，变更也必须保留人工批准或强策略审批。
相关阅读
- Action Types — Action Log 记录的上游：受控的状态变更通道
- Interfaces —
Auditable接口声明了对象接入审计链的标准形状 - Evolution Loop — Action Log 反哺的治理闭环全貌
- 可靠性模型 — 本地审计缓冲与降级策略的完整设计