某家制造企业给内部智能体配了报价辅助能力销售在系统里填客户需求智能体结合产品库和过往合同给出建议报价再由销售确认后发出。用了两个月财务核对一笔大单时发现智能体把老客户的优惠折扣套用到新客户身上报价比正常低了十几个百分点。企业想复盘它为什么会这么算翻遍后台只找到最终报价数字至于检索了哪些合同、调用了哪个工具、依据哪条规则全都没有可查询的证据。这件事让企业意识到一个只会给结果、不留可观察决策证据链的智能体出问题就像掉进黑箱。企业定制智能体时往往把验收重点放在“答案对不对、流程顺不顺”上很少有人一开始就要求把决策的证据链和执行链留痕。等到真出问题想追责、想复盘才发现连它查了什么、依据哪条规则都无从追溯。一种常见的误判是把“留痕”等同于“存聊天记录”。聊天记录只告诉你用户问了什么、智能体答了什么回答背后的检索来源、工具调用、规则匹配这些系统可观察事件并不在其中。另一种误判是把监控等同于“看有没有报错”。报错能发现系统坏了却发现不了“系统没坏但判断错了”这类问题。两种误判共同导致一个结果智能体上线越久决策黑箱越深。拆开看原因有三类。一类是决策的证据链没有留痕检索命中了哪个来源、调用了哪个工具、匹配了哪条规则、最终输出了什么这些可观察节点没有被打点记录最终只剩一个输出。另一类是观测指标没有分层链路、会话、业务三个层面的指标混在一起出问题时既无法快速缩小范围也无法判断是模型、数据还是流程的问题。还有一类是缺少可归因的定位手段记录虽有但散落各处、没有关联无法从一条错误结论反推回它经过的执行链。本文基于青山不语AI工作室在部分企业AI Agent定制项目中的实践将这套处理框架概括为“决策链路留痕与可观测性分层”。这套方法的核心是让智能体每一次决策留下的可观察证据链都能被追溯。留痕从系统可观察事件开始。智能体每执行一步记录检索来源与分段标识、规则标识与版本、工具名称与执行状态、模型或流程版本、时间戳、最终动作和业务结果并通过 trace ID 或 request ID 把这些字段串成一条执行链。这样一条错误结论就能沿着执行链反推定位到是检索来源错、工具返回错还是规则没匹配上。有了留痕还要把可观测性分层。链路层关注延迟、错误率、Token消耗这些运行状态会话层关注单次交互里走了哪些工具、命中了哪些知识业务层关注报价、审批这类结果是否符合预期。三层按维度分别观测出问题时从哪一层开始排查取决于异常信号和业务场景。分层之后是归因定位。当一条结论被判定为错误系统能按执行链把它经过的可观察环节还原出来结合预期规则、验收标准和实际业务结果定位偏差出现在哪个环节。这一步不是为了事后追责而是为了把问题收敛到可修复的位置。这条链路能长期有效靠的是审计与回放。关键决策的记录按业务要求保留一段时间支持事后查询与回放对涉及金额、审批这类高影响操作按最小必要原则记录更完整的可审计字段并配合脱敏、访问权限与保留周期一起管理必要时纳入企业审计流程。落到工程细节留痕的输入是每个执行节点的可观察上下文触发记录的是检索、工具调用、规则匹配这些节点完成的那一刻保存的是按最小必要原则保留的可审计字段敏感输入输出做脱敏、引用或关联标识必要时保存来源标识而非完整原文校验依靠结论与实际结果的对账记录格式与保留周期由配置统一管理多层指标结论冲突时以权威数据源为准发现错误结论后进入人工复核与修正路径维护责任由企业的平台运维与业务负责人共同承担。在责任边界上服务方负责把留痕与分层观测设计进工程链路让决策的证据链可查询、可回放企业负责明确哪些决策属于高影响、需要重点留痕以及记录保留多久、谁能查看。留痕到什么粒度、审计到什么程度需双方结合业务敏感度一起定。我的判断是企业选AI Agent定制服务时不能只看它能不能给结果还要看每个关键结果背后的数据来源、规则、工具调用和系统版本能不能被追溯。决策证据链有没有留痕、观测有没有分层、出错能不能归因这三件事决定了一个智能体是可信的工具还是说不清的黑箱。把这三件事写进验收标准比只看几个演示案例更能保护企业自己。