一、AI 说“已经修改成功”，为什么还不够？

很多 AI 助手的演示都会停在一句话：

已经帮你修改完成。

如果 AI 只是在总结文档，这句话不会带来太大问题。

但如果它正在操作商城、CRM、ERP、OA 或 SaaS 后台，这句话背后可能对应完全不同的真实状态：

• Agent 只是生成了回答，根本没有调用工具；
• 工具请求已经发出，但网络连接中途断开；
• 中枢已经受理，任务仍在排队；
• 操作进入审批，尚未真正执行；
• 业务接口返回 HTTP 200，但业务状态其实是失败；
• 写操作已经成功，客户端却因为超时没有收到结果；
• Agent 又重试了一次，产生了两次重复写入；
• 修改发生在错误租户、错误门店或错误业务对象上。

因此，当 Agent 开始形成真实业务后果时，我们需要区分两种完全不同的东西：

自然语言回答：Agent 告诉用户发生了什么
执行证据：系统能够证明实际发生了什么

前者用于沟通，后者用于确认、排错、追责和恢复。

企业真正需要回答的，不只是“AI 最后说了什么”，而是：

1. 谁发起了这次操作？
2. Agent 当时代表哪个用户、租户或门店？
3. 为什么这个身份能看到并调用这项能力？
4. 实际调用了哪个工具？
5. 参数对应的是哪个业务对象？
6. 是否经过审批？
7. 业务系统最终接受还是拒绝？
8. 如果结果未知，应该查询原操作还是重新提交？

这就是 Agent 执行审计要解决的问题。

二、聊天记录不等于执行轨迹

很多系统已经保存了完整对话，于是很容易产生一个误解：

既然用户和 AI 的消息都在，为什么还需要单独的执行轨迹？

因为聊天记录和执行轨迹的职责不同。

聊天记录回答“双方说了什么”

它通常包括：

• 用户提出的目标；
• AI 给出的解释；
• 用户追加的限制条件；
• AI 最终返回的可见结果。

这些内容适合恢复上下文，也适合让用户回看一段会话。

执行轨迹回答“系统实际做了什么”

它应该包括：

• 一轮任务何时开始；
• 使用了哪个 Agent Client、工作区和路由；
• 何时搜索或加载了业务能力；
• 调用了哪个工具；
• 工具调用处于等待、审批、执行、成功还是失败；
• 业务系统返回了什么状态；
• 是否发生重试或恢复；
• 一轮任务何时结束。

两者之间可能一致，也可能不一致。

例如用户说：

把张三的员工备注改成“负责华东区渠道”。

聊天记录只能证明用户提出过这个要求，以及 AI 可能回答了“已修改”。

执行轨迹则需要证明：Agent 调用了员工查询工具，确认目标员工后调用员工资料修改工具；中枢进行了身份、路由和审批检查；业务系统最终返回修改成功；必要时又查询了一次最新资料进行确认。

如果没有这条链路，企业只能相信模型自己的叙述。

三、一条可审计的 Agent 任务，至少要分成五层

不要把所有内容都塞进一张“AI 日志表”。更合理的方式，是按职责拆成五层。

层次	主要记录	回答的问题
会话 Conversation	用户消息、AI 可见回复、公开上下文	用户想做什么，AI 告诉了用户什么
Agent Run	一轮本地或云端 Agent 运行	哪个客户端在何时处理了哪一轮任务
工具调用 Invocation / Job	工具、状态、幂等标识、耗时、结果边界	Agent 实际调用了什么，执行到哪一步
审批 Approval	审批对象、参数快照、审批人、决定和有效状态	哪一次具体操作经过了谁的批准
业务审计 Business Audit	业务对象、变更前后、操作者和领域结果	业务数据最终发生了什么变化

这五层不能互相替代。

中枢看到“工具执行成功”，不等于业务系统可以省略自己的员工变更日志；业务系统记录了员工字段变更，也不等于它知道这次变更来自哪一轮 Agent 会话。

只有用稳定标识把它们串起来，排查时才能从一句用户消息追到真实业务结果。

四、为什么必须有稳定的 run_id、job_id 和 invocation_id？

一条 Agent 任务往往不止调用一个工具。

例如：

用户要求修改员工备注
  -> 搜索员工
  -> 查询员工详情
  -> 修改员工资料
  -> 再次查询确认
  -> 生成最终回答

如果所有步骤都只靠自然语言时间戳关联，系统很难判断它们是否属于同一轮任务。

因此，通常需要几类不同标识：

• thread_id 或 conversation id：标识一段持续会话；
• run_id：标识 Agent 处理的一轮用户请求；
• invocation_id：标识一次逻辑工具调用；
• job_id：标识中枢受理并执行的任务；
• approval_id：标识针对某次具体参数快照的审批记录；
• 业务侧 request id / audit id：标识领域系统中的最终操作。

它们不是为了让日志看起来更复杂，而是为了处理三个生产环境中必然出现的问题。

1. 一个会话包含多轮任务

用户可能先查询员工，几分钟后又要求修改资料。两轮对话属于同一会话，但不能共用同一个运行状态。

2. 一轮任务包含多个工具调用

查询和修改必须分别记录，否则无法判断到底在哪一步失败。

3. 同一次写操作可能经历等待、审批和恢复

当操作等待审批时，审批完成后应该恢复原来的 invocation_id，而不是创建一次新的写操作。

这也是为什么“超时以后再点一次”在 Agent 场景中非常危险：第二次提交可能不是查询，而是又创建了一次副作用。

五、本地 Agent 负责思考以后，为什么中枢仍然有意义？

本地 Agent 的价值，是在用户设备上完成理解、规划、工具选择和多步编排。

但本地编排并不意味着每台电脑都各自维护一套身份、权限、审批和日志。

更合理的结构是：

本地 Agent
  - 理解用户目标
  - 决定调用顺序
  - 根据工具结果继续规划
  - 生成最终可见回答

治理中枢
  - 绑定业务身份与工作区
  - 裁剪当前可见能力
  - 重验 Session、路由和治理规则
  - 执行审批、幂等和结果恢复
  - 汇总安全执行轨迹

业务系统
  - 校验实时用户和租户权限
  - 校验业务对象当前状态
  - 执行领域规则
  - 保留最终业务审计

本地 Agent 可以决定“先查员工，再修改备注”。

但它不能自己决定：

• 当前用户是否仍然属于这个租户；
• 当前账号是否还有员工编辑权限；
• 目标员工是否属于当前门店；
• 这项操作是否需要审批；
• 相同写入是否已经成功执行过；
• 业务系统是否最终接受了修改。

所以，中枢的意义不是把思考重新搬回云端，而是保留一条模型无法自行改写的执行边界。

六、审计是不是应该上传模型的完整思维链？

不应该。

企业需要的是行动证据，不是把本地 Agent 的所有内部推理复制到服务器。

一条合理的 Agent 执行轨迹可以记录：

• 本轮由本地 Agent 负责规划；
• 当前使用的客户端、路由和工作区；
• 调用了哪些工具；
• 参数包含哪些字段；
• 是否进入审批；
• 工具状态、耗时和业务结果摘要；
• 最终回答是否已提交；
• 可公开的 Token 和工具调用用量。

但普通会话审计不应该记录：

• 模型隐藏思维链；
• Access Token、Refresh Token 和 Cookie；
• Tool Provider Secret 或模型 API Key；
• 工具参数中的完整敏感值；
• 业务接口的完整响应正文；
• 用户未授权上传的本地文件；
• 为了“以后可能有用”而无限保存的全部上下文。

以 BailingHub Agent Client v1 的公开实现为例，运行轨迹明确标记：

planner = local_agent
execution = bailinghub_governed
hidden_reasoning_sync = false
tool_payloads = summary_only

会话视图中的工具参数只投影字段名、字节数和治理结果，不直接显示原始参数值。完整载荷即便因为故障排查需要保留，也应该只出现在权限更严格的单任务审计面，并遵循单独的脱敏和保留策略。

这是一条很重要的边界：

可审计，不等于无差别收集；可追查，也不等于把秘密暴露给所有后台用户。

七、哪些信息适合进入执行轨迹？

可以把轨迹字段分成四组。

1. 运行身份

• Agent Client 应用标识；
• 工作区和路由；
• Agent Session 的非秘密摘要；
• 会话与本轮运行标识；
• 本地运行时与模型名称的可选公开信息。

这里不保存业务账号密码，也不把 access token 当作身份展示。

2. 治理决定

• 当前工具是否在授权范围；
• route 是否允许直接调用；
• ACC 能力声明是否要求审批；
• 是否发生额外强制审批；
• Session 是否仍然有效；
• 是否因为权限、租户或状态变化而失败关闭。

3. 工具执行

• 工具 operationId 或稳定名称；
• 调用标识和任务标识；
• 参数字段名而非默认展示参数值；
• 任务状态；
• 请求和响应大小；
• 耗时、重试次数和最终结果摘要。

4. 交付结果

• 本轮状态是完成、失败还是等待；
• AI 最终向用户提交的可见内容；
• 本轮工具调用数量；
• 可公开的 Token 使用量；
• 最终完成时间。

这些信息已经足以回答大多数运维和审计问题，同时不会要求上传隐藏推理。

八、审批记录为什么必须绑定具体参数？

如果审批记录只写：

同意执行“修改员工资料”

那么审批完成后，Agent 可能换成另一个员工、另一个门店或另一个字段值。

这种审批几乎没有审计意义。

真正有效的审批应该绑定：

• 工具身份；
• 目标业务对象；
• 关键参数快照或其不可变摘要；
• 发起身份和租户；
• 审批人；
• 审批决定；
• 有效时间与恢复条件。

审批完成后，中枢恢复的也应该是原来的调用，而不是让 Agent 重新生成一组参数再提交。

如果参数发生变化，就应该视为新的操作，重新进行校验或审批。

因此，执行轨迹不仅要显示“审批通过”，还要能回答：

审批通过的是哪一次调用、哪一个对象和哪一组参数？

九、工具返回 HTTP 200，为什么还不能直接记为成功？

很多业务系统采用统一 HTTP 响应：无论业务成功还是失败，HTTP 状态都可能是 200。

例如：

{
  "code": 4031,
  "message": "当前门店无权修改该员工"
}

如果 Agent 只看 HTTP 状态，就可能把业务拒绝误写成修改成功。

因此，执行轨迹至少需要区分：

• 网络请求是否成功送达；
• Tool Provider 是否正确处理；
• 工具任务是否完成；
• 业务系统返回的领域状态；
• 最终业务对象是否真的发生变化。

对于关键写操作，最稳妥的验证方式往往是：

1. 提交写操作；
2. 保存原 invocation_id 和 job_id；
3. 等待或查询同一任务终态；
4. 必要时调用只读能力重新读取目标对象；
5. 最终回答基于可验证结果，而不是基于“请求已经发出”。

十、一次员工资料修改，完整轨迹应该是什么样？

假设用户在本地 Agent 中输入：

找到张三，把他的显示备注改成“负责华东区渠道”。

一条合理的轨迹可以是：

10:00:00  本地智能体开始处理
           run_id = run-123
           planner = local_agent

10:00:02  搜索当前授权范围内的“员工查询”能力
           返回 2 个可用工具

10:00:03  调用 employee.search
           invocation_id = inv-001
           job_id = job-001
           状态 = completed

10:00:04  调用 employee.get
           invocation_id = inv-002
           job_id = job-002
           状态 = completed

10:00:06  调用 employee.update_profile
           invocation_id = inv-003
           job_id = job-003
           参数字段 = [employee_id, display_note]
           审批 = 当前能力声明不要求审批

10:00:07  业务系统重新校验当前用户、门店和目标员工
           业务状态 = success

10:00:08  再次查询 employee.get
           确认显示备注已更新

10:00:09  本地智能体提交最终回复
           状态 = completed

普通会话页面不需要显示员工 ID 和备注原文，但应该能够看到调用顺序、参数字段、工具状态、审批状态和业务结果。

如果需要调查具体对象，则由具备更高权限的审计人员进入单任务审计页或业务系统审计页查看受控明细。

十一、超时和结果未知，是最容易造成重复写入的地方

假设 Agent 调用“创建退款申请”后等待 30 秒超时。

这时存在三种可能：

1. 请求根本没有到达业务系统；
2. 请求已经到达，但业务仍在处理；
3. 业务已经成功，只是响应没有返回客户端。

如果 Agent 看到超时就重新提交，很可能创建两次退款。

因此，轨迹与协议需要共同保证：

• 第一次提交拥有稳定 request id / invocation id；
• 中枢能够查询原 job 的状态；
• 审批后恢复原 invocation；
• 结果未知时优先续查，不重新创建副作用；
• 业务系统用幂等键拒绝重复写入；
• 最终回答明确区分“已完成”“处理中”和“结果未知”。

审计轨迹在这里不仅用于事后追责，也直接参与正确恢复。

十二、中枢审计不能替代业务系统自己的审计

这是容易被忽略的一点。

BailingHub 一类治理中枢可以证明：

• 哪个 Agent Client 发起了哪一轮任务；
• 当前路由暴露了什么能力；
• 哪个工具被调用；
• 是否触发审批；
• 工具任务返回了什么受控结果。

但只有业务系统自己知道：

• 员工资料在数据库中具体怎样变化；
• 订单当时处于什么业务状态；
• 库存扣减涉及哪些批次；
• 退款是否进入财务账务；
• 哪些领域规则导致最终拒绝。

所以，真正完整的企业审计是两边协作：

中枢审计：记录 Agent 如何到达业务动作
业务审计：记录业务动作最终造成什么领域变化

两边通过稳定的调用标识或业务审计 ID 关联，而不是互相取代。

十三、已有商城、CRM 或 SaaS，最小应该补哪些东西？

不必一开始建设一个庞大的“AI 审计平台”。可以先完成以下最小闭环。

中枢侧

• 为每一轮 Agent 请求生成稳定 run_id；
• 为每个工具调用生成或接受稳定 invocation_id；
• 保存工具状态、审批状态和脱敏结果摘要；
• 会话视图只显示安全字段；
• 支持从 run 追到工具任务，从工具任务追到审批。

业务侧

• 从可信 Session 获取用户、租户和角色；
• 每次执行重新校验业务权限；
• 写操作接受幂等键；
• 返回明确的领域状态；
• 在业务审计中保存外部 invocation id 或关联 ID。

本地 Agent 或客户端侧

• 不把“请求已发送”写成“业务已完成”；
• 保存并复用同一次调用标识；
• 审批后恢复原调用；
• 结果未知时查询原任务；
• 最终只上传用户可见回答和安全用量，不上传隐藏思维链。

十四、第一次验收执行轨迹，可以用什么场景？

不要一开始就用删除账号、实际退款或财务入账测试。

推荐选择一个低风险、可回滚的写操作，例如：

• 修改员工显示备注；
• 更新客户普通标签；
• 创建内部工单；
• 修改商品内部说明；
• 新建一条未提交草稿。

然后验证以下十项：

1. 没有业务授权时看不到工具；
2. 用户消息和 Agent 最终回复进入同一会话；
3. 一轮请求生成唯一 run；
4. 多个工具调用都能关联到该 run；
5. 会话轨迹不显示 Token、Cookie 和参数原值；
6. 不需要审批的工具不会被客户端擅自加审；
7. 必须审批的工具不能被客户端绕过；
8. 审批后恢复原 invocation，不创建第二次写操作；
9. 业务权限被撤销后，即使 Agent Session 尚未过期也会被业务系统拒绝；
10. 最终可以从 Agent 回答追到工具结果，再追到业务系统审计。

这十项通过以后，再考虑更高风险的库存调整、账号停用、退款和财务动作。

十五、BailingHub 在这条链路中记录什么？

BailingHub v0.5.0 已公开的 Agent Client v1，把本地 Agent 的运行和受治理工具调用接入既有会话、Job、审批和审计体系。

一轮本地 Agent 运行可以保留：

• run_id、会话和客户端应用；
• route、运行状态、模型和 runtime 的可选公开信息；
• 输入、缓存输入、输出和工具调用等安全用量；
• 本地 Agent 开始处理和提交最终回复的事件；
• 中枢治理事件；
• 每个工具 Job 的状态、审批状态、耗时和业务结果摘要；
• warning、error 和是否存在部分轨迹。

同时明确不接收、不落库 hidden reasoning。

这使本地 Agent 和业务后台嵌入聊天可以复用同一套业务能力与治理事实源，而不必把本地 Agent 变成一个只负责转发消息的聊天客户端，也不必把所有业务秘密复制到用户电脑。

但这仍然只是开源产品能力与维护者验收事实，不代表任何 Agent 宿主的官方背书，也不能把一次试用写成外部采用或生产合规认证。

常见问题

1. 保存完整聊天记录，就能满足 AI 操作审计吗？

不能。聊天记录只能证明用户和 AI 说了什么，还需要独立记录工具调用、审批、任务状态和业务结果。

2. Agent 执行轨迹需要保存完整 Prompt 吗？

通常不需要。审计重点是身份、能力、治理决定、工具状态和业务结果。完整 Prompt 可能包含敏感上下文，是否保存应由单独的数据策略决定。

3. 本地 Agent 不上传思维链，还能审计吗？

可以。企业需要审计的是实际行动，而不是模型内部每一步推理。记录工具调用顺序、状态、审批和结果已经可以还原行动链。

4. 工具参数完全不记录，会不会无法排错？

普通会话轨迹可以只显示参数字段名和大小；授权更严格的单任务审计面可以按策略保存脱敏参数或不可变摘要。两种视图不应混为一层。

5. 为什么 Agent 最终回复和业务结果都要保存？

因为需要判断 Agent 是否把真实结果正确告诉了用户。例如业务系统拒绝修改，但 Agent 却回答“成功”，这本身就是需要发现的问题。

6. 工具调用成功后，还需要业务系统审计吗？

需要。中枢证明调用链和治理过程，业务系统证明领域对象最终发生的变化。

7. 审批通过后可以重新调用一次工具吗？

不应该。应恢复原来的 invocation；重新调用可能改变参数或造成重复写入。

8. 一个 Agent Run 可以调用多个工具吗？

可以。run 表示一轮用户任务，每个工具调用应有自己的 invocation / job，并统一关联到该 run。

9. 执行轨迹等于合规认证吗？

不等于。它提供技术上的可追查基础，具体保存期限、访问控制、数据驻留和合规要求仍需企业结合自身制度与适用法规设计。

结语：不要让模型自己证明模型做过什么

当 AI 只负责回答问题时，一段对话往往已经足够。

当 AI 开始修改员工、创建工单、更新库存、提交退款或操作企业后台时，系统必须拥有独立于模型叙述的执行证据。

一条可信链路至少应该做到：

1. 用户目标进入会话总账；
2. 每轮 Agent 运行拥有稳定标识；
3. 每个工具调用拥有可恢复、可幂等的调用标识；
4. 审批绑定具体工具和参数快照；
5. 中枢记录脱敏的治理与执行轨迹；
6. 业务系统保留最终领域审计；
7. Agent 的最终回答能够和真实业务结果相互校验。

本地运行解决的是 Agent 在哪里思考。

执行审计解决的是：当它真正行动以后，企业如何知道发生了什么。

而这正是 AI 从“会聊天”进入商城、CRM、ERP 和 SaaS 后台时，不能缺少的一层基础设施。

---

项目与延伸阅读：

• BailingHub GitHub
• BailingHub 官网
• Agent Client Runtime v1 接口说明
• Agent Client v1 接入指南
• BailingHub v0.5.0 Release
• 提交一条真实 API 接入评估