给模型调用约定一套稳定字段：提供方、请求模型、输入词、输出词。一条完整树通常有四类节点：编排、检索、模型、工具。模型节点留下输入输出摘要和用量，检索节点留下召回结果，工具节点留下外部调用。形状和普通分布式链路一样，差别只是属性里多了模型和用量。

这套数据有一层传统排障用不到的用途：当评估输入。一次回答差，顺着树看召回是否合理、上下文是否被截断、模型输出有没有被工具结果覆盖。把链路、评分和提示词版本放在一起，质量比较才有同一把尺。传统链路排完障就归档；模型链路会变成改提示词和换模型的日常材料。

把评估分数写成模型节点上的属性，查询时按分数过滤，低分样本直接跳进细节。评估循环的输入是链路，输出又写回链路，才形成闭环。成本治理按三个切面：哪些功能吃掉大部分词、要不要降级模型、波动是否跟某次发布有关。三个切面都依赖节点上的模型和用量字段，没有它们就只剩账单总额。

输入输出可能含证件号和对话原文，默认脱敏或只留摘要。用量口径必须和计费侧对齐，否则治理数字和账单对不上。生态里的追踪评估平台多数兼容同一套导出协议，可以进统一采集管道，不必每个项目自建一套字段。敏感路径不要把全文当可缓存的遥测存下去。

落地清单

• 模型节点至少带提供方、模型名、输入词、输出词；检索节点带召回来源。
• 评分作为属性挂在对应节点，低分过滤后能一跳看到当次检索和提示词版本。
• 导出前脱敏。全文进遥测等于把对话备份到观测后端。
• 按功能、按模型、按天看词消耗，发布日对照曲线，比只看月账单更能定位浪费。

观测如果只证明「调用成功了」，模型应用仍然不可改进。分数和用量写回同一条树上，迭代才有对象。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源