一个账户诊断 Agent 给出了这样的判断：昨天掉量，主要是预算不足，建议加预算。
可查完账户后，预算并没有消耗完。错误已经确认，接下来改哪里？改提示词，让模型“分析得更严谨”？补几条测试，要求它先检查预算？还是修取数工具？
这些动作都说得通，也可能都没有碰到问题。Agent 或许查错了日期，或许工具返回了另一个账户的数据，也可能拿到了正确数据，却在总结时把相关性写成了原因。只留最终回答，几种失败就会混在一起。
这个场景是说明问题的假设例子。它对应一个实际的工程要求：回答之外，还要有执行证据。测试用来检查已知要求，观测用来保留真实运行中发生的事情；两者需要接在一起，才能检查某次修改到底解决了什么。
从一个错误，倒着找它的来处
先别急着加日志。把这次诊断拆成几段更容易检查的动作：识别账户和时间范围，查询投放数据，比较指标，生成解释。如果允许自动调预算，还得加上一次状态变更。
每段都可能出错，但错法不同。日期理解错，是输入解释的问题；查询失败，是工具或依赖的问题；把未消耗完的预算解释成不足，是推断的问题；说“调整完成”却没有改动，是执行状态的问题。把它们统称为“模型答错”，会把不同负责人的工作混在一张需求里。
第一次排查至少应该能读到四组证据：用户提出了什么要求，系统实际用了什么数据，关键步骤产出了什么，以及外部系统最后发生了什么。模型最后那句“已完成”，只能说明它输出了这句话，不能替代工具回执或状态回读。
这里不要求暴露模型的全部内部思考。很多模型不会提供内部推理链，返回的推理摘要也不等于完整心理过程。可依赖的是可获得的输入输出、工具参数、决策结果、错误、版本和外部状态。能记录的推理摘要可以帮助调查，但不能把不可获得的隐含思考当作埋点验收项。
记录齐了，仍然只是有了调查材料。发现“取数之后开始偏”是在缩小排查范围；要证明某个变量造成错误，还需要复现、对照实验或其他能排除替代解释的证据。trace 支持定位，不自动证明因果。
已知用例之外，还有哪些变化
传统软件也不是所有路径都能穷举。分布式依赖、并发、真实数据和用户行为，本来就会让测试覆盖不完整。LLM 应用把其中一些问题变得更突出，还增加了开放输出和动态工具选择。需要观测的理由，在这些具体变化里。
同一个任务，可以有多个合格答案
“解释这个账户为什么掉量”没有唯一的字符串答案。两份分析可以顺序不同、措辞不同，只要数据准确、覆盖关键因素、没有越界推断，都可能合格。
这并不意味着无法测试。日期区间、必要事实、输出格式、工具权限，都可以用确定性检查。开放解释可以用人工标准、模型评审或成对比较，但评审标准和评审者本身也要验证。
需要补上的，是测试结论的适用范围。一个版本在某组输入上得分较高，不代表所有真实场景都更好。保存线上场景、版本、输出和用户结果，才能知道测试集漏了哪些情况，也能把有价值的失败补回评测集。
路径会随输入和中间结果改变
Agent 可以先查数据，也可以先澄清；工具返回不全时，它可能重试、换工具或直接回答。用一个简化例子看组合数量：五步，每步三种选择，共有 243 种组合；十步则是 59,049 种。真实系统不一定允许所有组合，这两个数只是在说明路径空间增长的速度。
路径多，并不等于每条都必须单独写测试。权限限制、终止条件、参数校验等机制可以约束很多路径。但对一条已经发生的错误，团队仍需知道它实际选了哪条路，不能拿设计文档里的理想流程来代替。
一次任务还有可能结果碰巧正确，过程却有缺陷。例如查询返回了旧数据，最后恰好得到相同结论。这次不一定引发投诉，下一次却可能出错。只检查最终回答，会漏掉这种过程风险。
有些任务会改变外部状态
只生成一段建议和直接修改预算，验收证据不同。后者至少涉及目标对象、参数、请求结果和最终状态。响应超时尤其需要谨慎：超时说明没有在预期时间拿到响应，不能据此断定外部动作未发生。
状态证据应来自工具回执、事务记录或独立回读，而不是模型自述。这里的“独立”是证据路径独立，不一定要另建一套系统。让执行服务返回真实写入结果，再核对目标状态，通常比重复问模型“你确定做完了吗”有用。
测试仍然能验证这些要求。观测保存的是真实请求里它们是否被执行、哪里中断、是否重试。两者共同支撑副作用的核查。
上线之后，输入分布和依赖还会变
用户从询问单个账户改成批量诊断，上游字段口径调整，检索库换了一批文档，模型或提示词升级，都可能改变表现。相同的界面和功能名称，背后未必还是同一套条件。
因此，“通过评估”应当绑定版本、数据集和时间。观测记录保留这些信息，才有可能比较变更前后、区分新场景和旧场景，也才知道该重跑哪一组测试。
| 变化发生在哪里 | 已知要求怎样检查 | 真实运行要留下什么 |
|---|---|---|
| 开放输出 | 事实、格式、约束及质量标准 | 输入、输出、评审结果与场景 |
| 动态路径 | 工具权限、参数和终止条件 | 步骤关系、调用顺序和中间结果 |
| 外部状态 | 写入契约、失败及重试处理 | 真实回执、目标对象和状态回读 |
| 运行环境 | 版本回归和兼容性检查 | 模型、提示词、数据与依赖版本 |
一条 trace 要让人读懂一次执行
执行链路，通常称为 trace。它用一组关联记录描述一个工作单元发生了什么：有哪些步骤，步骤之间是什么关系，输入输出是什么，耗时与用量落在哪一步。Langfuse 的 tracing 文档以这一结构组织 LLM 应用的执行记录。
trace 不是“越多越好”的日志集合。它首先要有一个清楚的调查对象。对账户诊断，可以是一轮请求；对代码评审，可以是一项评审任务。跨多个服务时，相关记录还需要通过标识关联起来。
结构化日志本身也能携带关联标识和上下文，不能把所有日志都说成线性文本。trace 的价值在于把执行的层级、时间和关联组织起来，让人能沿着一次任务阅读，而不是只靠搜索散落的字符串。
层级要对应真实的编排关系
一次诊断里，检索、计算和总结可能属于同一轮编排；重试又属于某个工具动作。层级应当反映这种归属，而不是所有节点都挂在根上，也不是为了图看起来整齐而额外套层。
父子关系说明某个步骤属于哪个工作单元，时间信息说明先后、并行和等待。二者一起，才有助于判断上游结果怎样进入下游。仅凭一棵树不能证明全部数据依赖，但能让调查者找到需要继续核对的节点。
命名最好表示稳定的操作，如“查询账户指标”“生成诊断”。账户 ID、日期、模型版本放在属性里。否则同一个动作每次名字都变，聚合时就会变成很多只出现一次的条目。
这也不是说动态名称绝对禁止。有些系统有明确的展示需求，但分析应有另外一个稳定字段。修改稳定名称时，要检查历史查询、告警和评估器是否仍然匹配。
类型让人少翻无关步骤
模型生成、检索、工具执行、规则检查，承担不同功能。调查“哪次取数出了问题”时，类型可以直接缩小范围；计算模型成本时，也需要准确识别模型调用。
下面是常见的分类方式，具体工具的类型名称和支持范围可能不同。它们不是一套通用理论要求每个系统必须照搬的完整分类。
| 类型示例 | 记录的动作 | 有助于检查什么 |
|---|---|---|
| generation | 一次模型生成 | 模型、输入输出、token 与成本 |
| tool | 一次工具调用 | 工具选择、参数、返回与副作用 |
| retriever | 检索或查询 | 查了什么、返回了哪些数据 |
| agent / chain | 编排或步骤连接 | 任务分解、分支、终止与上下文传递 |
| span / event | 一段过程或瞬时事件 | 耗时、关键状态及补充业务信息 |
| embedding | 向量化调用 | 输入规模、用量和相关成本 |
| evaluator | 评估动作 | 评审标准、输入和判定结果 |
| guardrail | 约束检查 | 放行、拦截与原因 |
重点是分类能支持当前问题。同一类动作有稳定类型，比一开始列出十几种却没人维护更实用。兜底类型可以存在；若所有重要动作都落在兜底里，按类型调查的收益就很有限。
成本要记在发生的步骤，延迟要区分总时长和步骤时长
模型费用通常与模型和用量有关。每次调用分别记录这些信息，才能分清是调用太多、上下文太长，还是换了昂贵模型。整个任务的总成本可以从已记录的子项聚合，但不能把根节点汇总值和子节点费用再加一次。
延迟更容易误算。两个步骤并行，各耗时一秒，任务不一定耗时两秒；父节点耗时也包含它等待子步骤的时间。用户等待多久，要看工作单元的墙钟时间；寻找慢点，要看步骤和关键路径。不能把所有节点耗时相加，当成端到端延迟。
如果费用估算不覆盖全部依赖，或供应商账单与记录口径不同，应明确范围。精确到小数点后的数字，不代表账目已经完整。
每轮模型调用分别保留，但不要求无差别存全部内容
把一个多轮 Agent 压成一次“大模型调用”，会失去每轮上下文、工具返回后的决定和用量变化。排查为什么突然变贵、在哪里开始重复调用时，这些差别很关键。
另一方面，完整记录所有输入输出也可能包含个人信息、客户数据和凭证。是否保留原文、保存多久、谁能读，应由任务和风险决定。脱敏后的字段、结构、错误代码或受控摘要，有时已能支撑调查。
原始报文和面向评审者的摘要可以分层保存。列表里显示任务与结果，详细节点保存必要数据。摘要不能隐去异常，原始记录也不应成为所有人默认可见的内容。
边界切错，记录再完整也难比较
在客服场景里，一段会话可能包含多轮用户请求。按单轮执行建立 trace，再用 session 标识串起会话，既能评一轮回答，也能检查整个问题是否解决。会话何时结束未必预先知道，但这不意味着会话级记录技术上不可能；选择边界主要是为了让记录易于读取、比较和维护。
代码评审则不同。一次提交触发一次评审，读取多个文件、检查多个问题，这些动作通常应属于同一个评审工作单元。如果按每个文件单独切 trace，还需要一层任务关联，才能还原整次评审。
判断边界时，可以挑一条真实失败，试着只靠当前工作单元和明确关联的上下文回答：任务是什么，系统做了什么，失败在哪里。然后拿另一条同类任务比较。如果总要人工拼很多碎片，边界可能太小；如果一次记录长到没人能读，且不同请求的成本和结果混在一起，可能太大。
| 切分方式的问题 | 阅读时的症状 | 需要调整的方向 |
|---|---|---|
| 工作单元过碎 | 每条都完整，却无法还原一次任务 | 增加清楚的任务关联或调整根边界 |
| 工作单元过大 | 多轮请求混杂，失败和成本难归属 | 按可比较的执行单元切分 |
| 会话和用户混用 | 同一个用户的多次任务被当作一段交互 | 分开主体标识、会话标识和执行标识 |
| 跨服务关联丢失 | 入口有记录，工具结果找不到 | 维护可传播、可核对的关联标识 |
“自包含”也需要实际理解。一次执行依赖会话历史、检索资料或外部状态，不一定能把所有信息复制到一条记录里。更可行的要求是：必要上下文有受控引用，读者能找到它，版本和权限不会让调查半路断掉。
采集范围，是一次持续的取舍
优先保留模型调用、关键取数、工具参数与真实状态结果，因为这些直接影响质量、成本和外部动作。再问哪些内部记录有调查价值。网络请求、数据库查询并不天然都是噪音：如果它们解释超时、数据缺失或重试，就值得保留；与当前调查无关的细节可以按需启用。
高基数也要分用途。执行 ID、账户 ID 对精确检索和关联很重要；不适合无节制地拿来做时间序列标签。自由文本可以保存为受控内容，但不要默认作为名称或聚合维度。采集、查询、索引和展示的限制不一定相同。
采样则影响你能看见哪些请求。稳定、高频的任务可以用采样控制成本，失败、高风险动作和新能力可以提高保留优先级。具体方案要考虑数据规模、业务风险和存储能力，不宜写成所有系统通用的“不可采样”名单。
对统计来说，记录覆盖率和采样规则属于指标口径。只保留失败请求，可以帮助分析失败类别，却不能直接计算全量失败率；若要估计总体，需要知道总体和抽样概率，并选择适当的方法。随机采样也会漏掉低频失败，不能因为样本里没出现，就宣称线上不存在。
至于状态审计，可以采用不同于质量分析的保留策略。关键写入保留完整回执，同时对一般生成请求做采样，不必要求所有数据走同一条规则。
从“看得见”到能改变一次决定
有 trace 的团队，未必能回答哪个场景更差。还需要把环境、场景、版本、结果等属性放回业务语境，固定比较口径。这是从单次排障走向总体分析的一步。
趋势和信号又是另一层工作：成本什么时候变了，哪类失败突然增加，投诉涉及哪个版本。一次记录只能说明发生过什么；持续分析才可能发现变化，而且需要检查分母、采样和用户结构是否同时变了。
下面这张表是本文用于自查的工作分层，不是经过验证的行业成熟度标准，也不是要求所有团队严格逐级建设。
| 当前能力 | 可以回答的问题 | 下一处常见缺口 |
|---|---|---|
| 只有结果 | 这次输出了什么 | 中间步骤和外部状态 |
| 能读执行 | 这次用了哪些数据、工具和模型 | 业务属性、稳定类型与版本 |
| 能分组比较 | 哪类任务、哪个版本更差 | 持续趋势、异常与抽样检查 |
| 能发现变化 | 什么时候变了、哪里值得调查 | 失败分类、可重复评测与实验 |
| 结果能进入决策 | 哪次修改有效，是否需要回滚或继续验证 | 决策后的追踪与新问题发现 |
最后一行不要求一定阻断过发布。调整调查优先级、拒绝一个证据不足的优化方案、扩大验证范围，也是在根据结果改变行动。反过来，一个看板再齐全，如果从没人依据它做过不同决定，就需要重新检查指标与工作流程。
可以从最近一条真实失败开始验收：是否能在可接受的时间内找到完整执行；是否能把成本归到具体调用；是否能核对外部状态；是否能和同版本、同场景的正常请求比较；缺失的数据能否被明确指出。不要用“埋点已接入”代替这次阅读。
回到开头的预算诊断。最先要补的，可能只是日期解析、工具参数、查询结果和总结输入四个节点。把错误定位清楚后，再决定修工具、修规则、补测试，还是重新评审解释。观测建设是否值得，首先看这次调查能否少一点猜测。
来源与阅读范围
账户诊断和代码评审场景用于解释概念，不代表作者真实项目经历。
- Langfuse Academy：AI Engineering Loop：线上记录、发现、实验与评估之间的关系。
- Langfuse Academy：Tracing：工作单元、步骤、会话及用量记录。
- Langfuse：Observability Best Practices：类型、命名、模型调用与输入输出的组织。
后续文章分别讨论记录属性与口径、监控、用户质量信号、错误分析、实验及决策。本篇的工作分层与场景分析属于基于这些材料的工程解释，不冒充来源原文或统一标准。