上一篇说的问题，是AI调用错了字段，补货数量差了一个数量级。这类错误有一个特点：结果是错的，但你能发现——货到了仓库，数量对不上，问题暴露出来。
还有一类问题更难处理，不是结果错了，而是过程不透明。你不知道AI调了哪些接口，用哪个身份调的，中间做了什么判断，为什么走了这条路而不是那条路。结果看起来是对的，但你没有办法确认它为什么对，下次还会不会对。
这在消费级产品里不是大问题。你让ChatGPT帮你写一封邮件，它写完你觉得还行就用了，不需要知道它内部经过了几步推理。但企业系统不是这个逻辑。
企业系统为什么需要可审计
"事事要留痕"这句话在很多企业里被当成口头禅，背后的原因不只是管理习惯，而是实际的业务需要。一笔采购单被批了，三个月之后出了问题，需要追溯当时谁批的、基于什么数据批的、审批链路是什么。一个客户投诉说报价有问题，需要查当时系统给出这个报价的依据。一次库存盘点发现数据对不上，需要回溯每一笔出入库记录。这些场景里，"能追溯"不是锦上添花，是基本要求。很多行业有明确的合规要求，金融、医疗、制造业的质量管理，都有相关法规规定操作记录必须保存多久、能否被篡改。
现在把AI接进来，让AI去做这些操作，同样的要求还在：AI做了什么，必须有记录，记录必须完整，能够被查。但现有的大多数AI Agent方案，在这件事上几乎是空白的。
三个"不可控"
我自己做过一个实验，用一个主流的Agent框架接了公司内部的几个API，让它帮我完成一个涉及多步骤的数据处理任务。任务完成了，结果是对的。但当我试图回答"它具体做了什么"的时候，我能拿到的只有：框架自带的日志，记录了每次LLM调用的输入输出；以及API网关的访问日志，记录了哪些接口被调用了。这两份日志是分开的，没有关联。我知道模型输出了"调用接口A"的意图，也知道接口A被调用了，但这两件事在日志里是两条独立的记录，中间的执行过程不透明。如果中间出了问题，我需要手动把两份日志对上，还不一定对得准。
这是行为不可控：不知道AI实际执行了什么，执行的顺序是什么，中间做了哪些判断。
权限问题更直接。企业系统里的权限通常是基于角色的，不同的人能看到不同的数据、能做不同的操作。这个逻辑在人机交互的场景里运转得很好，因为用户登录之后系统知道这是谁，每个请求都带着身份信息。但Agent在调用接口的时候，它的"身份"是什么？很多实现方式是给Agent配一个服务账号，这个账号有固定的权限。问题是这个权限往往比实际需要的要宽——因为你不知道Agent会被用来完成什么任务，所以倾向于给宽一点，以免任务失败。结果是，一个普通员工触发了一个Agent任务，这个任务在执行过程中可能访问了这个员工本人根本没有权限访问的数据。
这是权限不可控：AI的实际执行权限和触发它的用户的权限是脱钩的。
第三个问题是流程不可控，也就是审计缺失。即使你有行为日志，也有权限控制，还差一件事：这些记录是否足够完整，足够可信，能够支撑事后的追溯？一条日志记录了"Agent调用了接口X，参数是Y，返回了Z"，但没有记录"这次调用是由哪个用户的哪个会话触发的，在整个任务链路中处于第几步，上下文是什么"。脱离了上下文的日志，在审计的时候很难用。更大的问题是，如果Agent有能力写文件、调接口、执行脚本，这些操作的日志分散在不同的地方，没有一个统一的审计链路。出了问题你能知道发生了什么，但可能需要花几个小时把各处的日志拼起来。
准确性和可管理性，指向同一个根因
把上一篇和这一篇放在一起看，会发现两类问题有一个共同的特征：AI在操作企业系统的时候，它的行为缺少约束。上一篇说的准确性问题，根源是AI不知道你的系统里每个概念的具体含义，只能靠猜，猜出来的结果有时候在业务上是错的。这一篇说的可管理性问题，根源是AI的执行过程没有被纳入企业已有的权限体系和审计体系，它的行为游离在管控之外。
两个问题的解法，在工程上也指向同一个方向：在AI和业务系统之间，需要一个中间层，这个中间层既能告诉AI"系统里有什么、每个东西是什么含义"，也能在AI执行操作的时候，把权限校验和审计记录接进来。这不是一个全新的概念。企业软件里早就有类似的东西，叫语义层（Semantic Layer）或者服务总线（ESB），做的事情是在系统和使用方之间建立一层翻译和控制。只是过去这一层是给人或者传统软件用的，现在需要让它也能服务于AI。
具体怎么建这一层，以及建完之后整个架构长什么样，从下一篇开始进入这个话题。
