过去企业使用ChatGPT，治理其实相对简单。

员工提出一个问题，模型给出回答。如果后面发现内容有问题，还可以回到聊天记录里看：用户当时问了什么，AI又回答了什么。

但当Codex和Agent开始进入真实工作流以后，这套方法正在变得不够用。

因为Agent现在承担的任务，已经越来越不像“聊天”。

它可能读取Repository、修改文件、执行Shell、调用Plugin、运行测试、创建PR，甚至在Scheduled Job或CI流程中持续运行。

这时候企业真正需要知道的，已经不只是：

AI说了什么？

而是：

哪个Agent，在什么时间，以什么身份和权限，调用了什么工具，最终改变了什么？

这也是为什么随着Agent能力越来越强，企业AI正在出现一个新的基础设施需求：

AI Audit Log。

---

一、从Conversation到Action，企业AI的审计对象已经变了

如果AI只负责总结会议、润色文案或者解释代码，保存Conversation基本能够覆盖大部分问题。

但真实Agent任务可能是这样的：

接到一个Bug → 阅读Repository → 搜索相关文件 → 修改代码 → 执行测试 → 根据失败结果再次修改 → 调用GitHub → 创建Pull Request。

最后Chat里可能只剩下一句话：

“任务已经完成，测试通过并创建PR。”

对于普通用户，这句话可能已经足够。

但对于企业来说，它远远不够。

因为真正需要追溯的是：Agent到底修改了哪些文件？为什么选择这个方案？运行了哪些命令？有没有访问与任务无关的资源？第一次测试为什么失败？第二次又修改了什么？最终PR对应的是哪一轮代码？

过去的Conversation Log记录的是：

AI表达了什么。

Agent时代真正需要记录的则是：

AI执行了什么。

这两者是完全不同的治理对象。

所以企业AI审计正在从“对话留痕”逐渐进入“行为留痕”。

---

二、“AI做错了”不是一个真正可审计的结论

现在讨论AI风险时，经常会听到一句话：

AI做错了怎么办？

但真正进入企业环境以后，“AI做错了”其实是一个过于模糊的描述。

假设一个Codex Agent把错误代码提交到了Repository。

问题可能来自很多层。

可能是模型判断本身错误，也可能是Agent读取了已经过期的Context；可能是Branch选错了，也可能是Plugin返回了旧数据；还可能是权限给得太大，本来只需要读文件的Agent却获得了写入能力。

甚至还有一种情况：

代码本身没有问题，但CI已经失败，Agent仍然把任务标记成Done。

所以一次Agent事故真正需要调查的，通常不是一个单点，而是一整条执行链。

至少要回答：

谁执行的、为什么执行、用了什么工具、访问了什么资源、做了什么动作、结果如何、有没有经过验证。

这也是Agent Audit与普通日志最大的区别。

传统系统记录：

Job成功还是失败。

而Agent系统还需要知道：

它是怎么走到这个结果的。

因为Agent内部存在大量动态决策。

它可能根据第一次Tool Result改变计划，根据测试结果重新修改代码，再根据Reviewer意见进入下一轮执行。

如果这些过程全部被压缩成：

Success

企业其实很难理解真正发生了什么。

---

三、Agent越自主，Audit反而越重要

如果每一个重要动作都需要人在旁边点一次“确认”，Human本身就是一层天然监督。

早期Agent工作流更像：

Agent提出方案 → 人确认 → Agent执行 → 人再检查。

但真正能够产生效率提升的Agent，不可能永远保持这种模式。

随着Agent开始承担更长的任务、Scheduled Job、CI工作流和后台Automation，企业真正希望得到的往往是：

Human定义目标和边界，Agent负责执行，人只在异常或关键节点介入。

这意味着Human Touch会逐渐减少。

但人盯得越少，企业越需要另外一种能力回答：

Agent刚才到底干了什么？

所以会形成一个很明显的关系：

Agent Autonomy越高，Auditability要求越高。

这也是为什么Service Account、RBAC、Audit Log这些能力应该放在一起看。

Service Account解决的是：

到底是谁在执行。

RBAC解决的是：

这个Agent能做什么。

Audit Log解决的是：

它实际上做了什么。

而Verification解决的是：

它做得对不对。

当这四层组合起来以后，企业Agent才真正形成一套完整治理链。

---

四、真正的Agent Audit，至少要回答六个问题

未来一条比较完整的Agent执行记录，我认为至少要包含六类信息。

第一是 Identity。

过去可能只需要知道员工是谁，未来还要区分Human Account、Service Account和具体Agent Workflow。

因为“张三使用Codex”和“finance-agent-prod在凌晨2点自动执行任务”显然不是同一种行为。

第二是 Trigger。

一个任务究竟是员工主动发起的，还是Scheduled Job、CI Event或者其他Agent触发的？

Trigger不同，责任链和风险级别也不同。

第三是 Tool。

Agent使用了Shell、Git、Plugin、MCP、Browser还是External API？

Agent能力越来越强以后，Tool本身就是重要的行为边界。

第四是 Resource。

Agent究竟访问了哪个Repository、文件、数据库或者Workspace？

仅仅记录“调用了GitHub”没有太大意义，真正需要知道它操作的是哪个具体资源。

第五是 Action。

是Read、Write、Delete、Commit、Push，还是创建PR？

这一层决定了Agent真正对企业系统产生了什么影响。

最后是 Result + Verification。

动作有没有成功？测试有没有通过？是否被Approval拦截？后续有没有Rollback？最终结果是不是已经经过验证？

所以完整Agent Audit更接近：

Identity → Trigger → Tool → Resource → Action → Result → Verification

这已经不是简单的Chat History，而是一条真正的Execution Trace。

---

五、AI Audit最终不会只是合规部门的工具

很多人看到“审计日志”，第一反应是安全、合规、出了问题以后查责任。

但我认为Agent Audit长期价值远不止这些。

因为一旦企业能够看到大量Agent真实执行数据，就可以开始分析：

为什么某个Agent完成同样任务平均需要15次Tool Call，而另一个只需要6次？

为什么某个Workflow经常触发Human Approval？

为什么某个Agent总是在第一次测试失败以后大范围修改代码？

为什么某类任务的Retry特别高？

为什么Agent频繁访问本来与当前任务无关的Plugin？

这些信息已经不只是Compliance Data。

它们同时也是：

Agent Engineering Data。

以后企业可能会利用这些日志优化权限、Workflow、成本和Agent设计。

比如某个Agent长期只使用Repository Read权限，却一直拥有Write权限，那么可以缩小权限。

某个Workflow每次都会经历相同的三次失败重试，就应该重新设计Execution Flow。

某个Agent完成任务的成本和Tool Calls明显高于其他Agent，就可以进一步优化模型、Reasoning或者Context。

所以Audit最终很可能会和Agent Evaluation、AI FinOps、Security以及Observability逐渐结合。

---

六、企业未来需要的可能是一套Agent Observability

传统软件系统已经非常熟悉三个词：

Metrics、Logs、Traces。

Agent进入Production以后，很可能也会形成类似结构。

Metrics回答：

任务完成率多少？失败率多少？平均成本多少？需要多少次人工介入？

Logs回答：

谁在什么时间做了什么？

Traces则把一次复杂Agent任务完整串起来：

目标是什么 → 调用了什么工具 → 得到什么结果 → 为什么改变计划 → 最终执行了什么 → 怎么验证。

当这三层结合以后，企业才能真正理解：

一个Agent为什么最终产生这个结果？

所以未来所谓AgentOps，很可能不会只是“监控模型是否在线”。

它会同时包含Identity、Permission、Runtime、Tooling、Cost、Audit、Evaluation和Security。

从这个角度看，现在企业开始补Audit Log，并不是一个很边缘的管理功能。

它实际上是在补Agent进入生产系统以后必须存在的：

Observability Layer。

---

七、企业AI治理正在从“管回答”走向“管行为”

把最近这些企业Agent能力放在一起看，会发现一条很清楚的逻辑。

过去企业部署AI，最关心的是：

模型能不能回答得更准确。

后来开始关心：

员工可以访问什么模型、能不能连接企业数据、哪些工具可以使用。

而当Agent真正开始执行任务以后，新的问题变成：

哪个Agent在运行？它拥有什么权限？它实际做了什么？最终结果有没有验证？

企业AI治理的重点开始从Model Governance继续向Agent Governance延伸。

可以把它概括成四层：

Identity：Agent是谁。
Policy：Agent能做什么。
Audit：Agent做了什么。
Verification：Agent做得对不对。

只有这四层逐渐完整，企业才可能真正把越来越重要的工作交给Agent。

否则Agent能力越强，反而意味着企业承担的黑盒风险越大。

---

最后

AI只负责回答问题的时候，保存Conversation可能已经足够。

但当Codex和Agent开始执行Shell、修改Repository、调用Plugin、运行Scheduled Job，并逐渐进入真实企业系统以后，真正需要被记录的已经从：

AI说了什么

变成：

AI做了什么。

所以未来企业真正需要的，很可能不是一份更完整的Chat History，而是一条完整的Agent Execution Trace。

从Identity开始，到Permission、Trigger、Tool、Action、Result，再到最终Verification。

这套能力真正解决的是：

当Agent越来越自主以后，企业还能不能看得见它、解释它、追溯它，并在出问题时准确知道问题到底发生在哪一层。

所以Agent进入企业生产环境真正的门槛，可能从来都不只是模型够不够聪明。

还包括另一个越来越重要的能力：

Auditability。

当企业能够回答“哪个Agent、为什么执行、用了什么权限、做了什么、结果是否经过验证”，AI才真正从一个聪明的黑盒，变成一个可以被治理的企业执行系统。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道已放置下方。