某家制造企业给内部智能体配了报价辅助能力，销售在系统里填客户需求，智能体结合产品库和过往合同给出建议报价，再由销售确认后发出。用了两个月，财务核对一笔大单时发现，智能体把老客户的优惠折扣套用到新客户身上，报价比正常低了十几个百分点。企业想复盘它为什么会这么算，翻遍后台只找到最终报价数字，至于检索了哪些合同、调用了哪个工具、依据哪条规则，全都没有可查询的证据。这件事让企业意识到，一个只会给结果、不留可观察决策证据链的智能体，出问题就像掉进黑箱。

企业定制智能体时，往往把验收重点放在“答案对不对、流程顺不顺”上，很少有人一开始就要求把决策的证据链和执行链留痕。等到真出问题想追责、想复盘，才发现连它查了什么、依据哪条规则都无从追溯。

一种常见的误判，是把“留痕”等同于“存聊天记录”。聊天记录只告诉你用户问了什么、智能体答了什么，回答背后的检索来源、工具调用、规则匹配这些系统可观察事件并不在其中。另一种误判，是把监控等同于“看有没有报错”。报错能发现系统坏了，却发现不了“系统没坏但判断错了”这类问题。两种误判共同导致一个结果：智能体上线越久，决策黑箱越深。

拆开看，原因有三类。一类是决策的证据链没有留痕，检索命中了哪个来源、调用了哪个工具、匹配了哪条规则、最终输出了什么，这些可观察节点没有被打点记录，最终只剩一个输出。另一类是观测指标没有分层，链路、会话、业务三个层面的指标混在一起，出问题时既无法快速缩小范围，也无法判断是模型、数据还是流程的问题。还有一类是缺少可归因的定位手段，记录虽有但散落各处、没有关联，无法从一条错误结论反推回它经过的执行链。

本文基于青山不语AI工作室在部分企业AI Agent定制项目中的实践，将这套处理框架概括为“决策链路留痕与可观测性分层”。这套方法的核心，是让智能体每一次决策留下的可观察证据链都能被追溯。

留痕从系统可观察事件开始。智能体每执行一步，记录检索来源与分段标识、规则标识与版本、工具名称与执行状态、模型或流程版本、时间戳、最终动作和业务结果，并通过 trace ID 或 request ID 把这些字段串成一条执行链。这样一条错误结论就能沿着执行链反推，定位到是检索来源错、工具返回错，还是规则没匹配上。

有了留痕，还要把可观测性分层。链路层关注延迟、错误率、Token消耗这些运行状态，会话层关注单次交互里走了哪些工具、命中了哪些知识，业务层关注报价、审批这类结果是否符合预期。三层按维度分别观测，出问题时从哪一层开始排查，取决于异常信号和业务场景。

分层之后是归因定位。当一条结论被判定为错误，系统能按执行链把它经过的可观察环节还原出来，结合预期规则、验收标准和实际业务结果，定位偏差出现在哪个环节。这一步不是为了事后追责，而是为了把问题收敛到可修复的位置。

这条链路能长期有效，靠的是审计与回放。关键决策的记录按业务要求保留一段时间，支持事后查询与回放；对涉及金额、审批这类高影响操作，按最小必要原则记录更完整的可审计字段，并配合脱敏、访问权限与保留周期一起管理，必要时纳入企业审计流程。

落到工程细节，留痕的输入是每个执行节点的可观察上下文，触发记录的是检索、工具调用、规则匹配这些节点完成的那一刻，保存的是按最小必要原则保留的可审计字段，敏感输入输出做脱敏、引用或关联标识，必要时保存来源标识而非完整原文，校验依靠结论与实际结果的对账，记录格式与保留周期由配置统一管理，多层指标结论冲突时以权威数据源为准，发现错误结论后进入人工复核与修正路径，维护责任由企业的平台运维与业务负责人共同承担。

在责任边界上，服务方负责把留痕与分层观测设计进工程链路，让决策的证据链可查询、可回放；企业负责明确哪些决策属于高影响、需要重点留痕，以及记录保留多久、谁能查看。留痕到什么粒度、审计到什么程度，需双方结合业务敏感度一起定。

我的判断是，企业选AI Agent定制服务时，不能只看它能不能给结果，还要看每个关键结果背后的数据来源、规则、工具调用和系统版本能不能被追溯。决策证据链有没有留痕、观测有没有分层、出错能不能归因，这三件事决定了一个智能体是可信的工具还是说不清的黑箱。把这三件事写进验收标准，比只看几个演示案例更能保护企业自己。