应用工程

Agent 输出来源追踪与引用设计

作者

Agent可观测性系统设计RAG

单轮问答场景下,“这个回答的依据是什么”相对好回答——直接看检索到的文档片段就够了,Claude Citations API 这类功能已经把这部分做得很成熟(参考 Claude Citations API 引用功能详解、Anthropic Citations 与 RAG 组合实战)。但多步骤 Agent 不一样——最终答案可能融合了三次工具调用、两轮子 Agent 委派、一次数据库查询的结果，用户问”这个结论是怎么来的”，你需要能给出完整链路，而不是一句”AI 生成的”。

本文讨论如何给多步骤 Agent 设计输出来源追踪机制。

一、为什么单纯的 Citations API 不够用

Citations API 解决的是”这段文字对应源文档的哪个片段”，前提是有明确的、静态的源文档。但 Agent 场景的复杂之处在于：

  • 来源是动态生成的：工具调用返回的 JSON、数据库查询结果、子 Agent 的中间结论,这些都不是预先存在的”文档”，没法直接套用文档引用的模式
  • 来源有层级：最终答案可能是”根据工具调用 A 的结果，结合工具调用 B 的结果，再经过一次推理得出”，是一条链而不是一个平铺的引用列表
  • 来源可能互相矛盾：多个工具调用返回的信息不一致时，Agent 做了取舍，这个取舍过程本身也需要被记录，否则用户没法判断最终结论的可信度

所以多步骤 Agent 需要的不是”引用”，而是完整的溯源链(provenance chain)。

二、数据模型：把每一步都变成可追溯的节点

核心思路是给 Agent 执行过程中的每个关键节点打上唯一 ID，并显式记录节点之间的依赖关系：

{
  "node_id": "step-003",
  "type": "tool_call",
  "tool": "search_database",
  "input": {...},
  "output": {...},
  "timestamp": "...",
  "depends_on": ["step-001", "step-002"]
}

最终答案生成时，每一句关键结论都应该能关联回具体的 node_id。这和 LLM 对话轨迹存储与查询设计实践 里讨论的轨迹存储有相通之处，但溯源链的重点不是”存下发生了什么”，而是”建立结论与依据之间的显式映射关系”。

实现上的关键判断：

  • 不要指望模型在生成最终答案时”自觉”标注来源——需要在 prompt 层面显式要求，或者用结构化输出强制模型在每个论断后附带 node_id 引用
  • 工具调用的输入输出必须完整记录，哪怕看起来冗余——排查问题时,恰恰是这些”看起来用不上”的中间数据最有价值
  • 子 Agent 委派的场景，子 Agent 自己的溯源链要能整体作为父 Agent 溯源链的一个节点嵌入，形成树状结构而不是断裂的两套记录

三、和可观测性系统的关系与边界

溯源追踪和 AI Agent 可观测性设计 有大量重叠，但目的不同：

维度可观测性溯源追踪
目标用户开发者排查问题最终用户/审计方验证结论可信度
数据粒度全量记录，越细越好聚焦”结论-依据”映射，不需要每个中间状态
展示形式日志、trace、面板用户可读的引用标注或溯源链展示
保留策略通常按调试窗口清理可能需要长期保留用于审计

实践中建议底层用同一套 trace 数据采集(复用可观测性基础设施)，但在此之上单独构建一层”溯源视图”，按需要生成给用户看的引用标注，而不是把原始 trace 直接暴露出去——原始 trace 对最终用户来说噪音太多。

四、需要溯源能力的典型场景

不是所有 Agent 都需要做到这个粒度，值得投入建设的场景通常是：

  1. 决策类应用：Agent 给出的结论会影响实际业务决策(比如风险评估、合规审查),用户需要能验证依据
  2. 多信息源聚合：答案融合了多个可能互相冲突的数据源，用户需要知道 Agent 是怎么取舍的
  3. 需要审计的行业场景：金融、医疗等对可追溯性有合规要求的领域，事后能否还原决策依据是硬性要求
  4. 调试高优先级：即便不面向最终用户展示，开发团队自己排查”Agent 为什么给出这个答案”时，溯源链能大幅缩短定位时间,这部分和 Agent 任务回放与确定性调试 结合使用效果最好

如果只是简单的单轮问答或内部效率工具,不涉及决策依据审计,完整的溯源链设计可能是过度工程——先判断场景是否真的需要,再决定投入程度。

五、常见坑

坑一：只记录”用了什么工具”，不记录”为什么选这个工具”。 事后排查时，最难还原的往往不是工具调用结果，而是 Agent 当时的决策上下文——记录时应该把触发工具调用的那段推理也保留下来。

坑二：溯源信息和最终答案生成脱节。 如果溯源链是生成完答案之后再”事后补全”的，很容易出现引用和实际依据对不上的情况。正确做法是让模型在生成答案的同时输出结构化引用，而不是分两步做。

坑三：把所有中间数据都暴露给用户。 用户要的是”这个结论可信吗、依据是什么”，不是完整的执行日志。溯源视图需要做筛选和摘要，直接甩原始数据反而降低可读性和信任感。

六、相关阅读

相关阅读