审计轨迹

在实践中

这个词来自会计：审计轨迹指的是从一张汇总报表上的某个数字，一路回溯到它背后原始凭证的那条纸面路径；而当年让它值得保留的那些性质，到了软件里一条都没变。条目只追加、从不修改，于是日后起争议时读到的还是当初那份记录。每条条目点名的是行动的主体本人，而不只是一个账号或一个进程，于是一个动作能被归到一个答得起话的人头上。最关键的是，这份记录由执行工作的系统写下，而不是由希望这件事被执行的那一方写——当事方自己写的日志是一段叙述，它的可信度与当事方的可信度完全相等。最后这条性质，直接决定了 AI Agent 究竟能不能被治理：如果记录「它做了什么」的那份记录是 Agent 自己写的，那么去问 Agent「有没有出问题」根本不构成一种控制。

ObjectStack 把这件事记录为 sys_audit_log——一个只追加的平台对象，而不是一个日志文件。它的每一个字段都是只读，API 只暴露 get 与 list，因此不存在经由表单或端点的写入路径；行是由内部钩子在动作执行的同时写下的。每一行带着动作、它触碰的对象与记录、执行的用户，以及变更前后的值，于是「那笔折扣是谁改的」得到的是一份 diff，而不只是一个时间戳。即便是一次并非以人的身份认证的写入，也照样可归属：服务主体会以 svc:名称 的形式落在 actor 列上，而不是留下一个空值。保留期是声明出来的、而非顺其自然：该对象在 ADR-0057 下被归入合规账本这一保留类别，热存 90 天，随后归档而非删除，归档副本保留七年。

有一条设计规则值得借走，无论你用不用这个平台：合规界面上绝不能出现一个自己并不填充的列。一个空单元格会被读成「已采集，且什么都没发生」，而不是「根本没采集」——这两种误读里，前者危险得多。所以没有写入方的审计动作、没有写入方的列，都是从账本里删掉，而不是留在那里冒充一次并不存在的采集。另一条规则是账本只有一本、不是两本：Agent 的动作与人的动作由同一个运行时记录在同一个地方，用同一套筛选、同一种 diff。这正是「审阅 AI 与审阅人是同一件事」得以成立的原因——而它成立的前提，是那一行由运行时来写，不是由 Agent 来写。