随着代理开始执行涉及多次 LLM 调用、工具交互和内部推理步骤的复杂序列时,弄清代理为何做出特定决策或过程在哪里出现问题变得越来越困难。代理并非一个输入输出明确的简单函数;它是一个在问题空间中运作的动态系统。如果无法了解其内部状态和决策过程,调试和提升代理性能可能会像凭空猜测。追踪和分析代理执行的技术和工具,特别是 LangSmith,可用于更清晰地理解代理行为。对更细致信息的需要假设有一个代理,其功能是研究一个主题、查询数据库获取相关统计数据并生成一份报告。如果最终报告不准确或不完整,可能的原因有很多:LLM 是否误解了初始请求?代理是否选择了错误的工具(例如,选择了网页搜索而不是数据库查询)?传递给工具的参数是否不正确?工具本身是否返回了错误或意外数据?LLM 是否未能正确整合工具输出的信息?代理是否陷入循环,重复尝试相同的失败操作?简单的日志记录可能捕捉到工具的输入和输出,但它通常会遗漏 LLM 执行的重要中间“思考”或推理步骤,特别是在 ReAct(推理与行动)等架构中。为了有效诊断问题并优化行为,我们需要代理执行路径的详细、逐步的记录。运用 LangSmith 进行执行追踪LangSmith 专门设计用于应对 LangChain 生态系统中的这一挑战。当其集成到您的应用程序中时(详见第五章),它会自动捕获 LangChain 组件的详细追踪记录,包括代理及其组成部分。LangSmith 中典型的代理执行追踪会提供一个层次化的运行视图,并记录了:代理调用: 代理开始处理请求时的顶层入口点。LLM 调用: 代理每次咨询 LLM 进行推理(例如,决定下一步行动)时。这包括发送的准确提示、使用的模型参数以及收到的原始响应。行动步骤: 代理决定使用特定工具。工具输入: 代理提供给所选工具的参数。工具执行: 调用工具的底层函数。工具输出(观察): 工具返回的结果,并反馈给代理。中间思考: 对于 ReAct 等代理类型,LLM 的明确推理步骤(“Thought:”、“Action:”、“Observation:”)会被记录。这种结构化、时间性的视图让您能够可视化地重放代理的“思考过程”。digraph G { rankdir=LR; node [shape=box, style=rounded, fontname="sans-serif", fontsize=10, margin=0.15]; edge [fontname="sans-serif", fontsize=9]; subgraph cluster_agent { label = "代理执行"; style=filled; color="#e9ecef"; // gray Start [label="用户输入\n'研究 LLM 成本'"]; LLM1 [label="LLM 调用 1\n提示: ...\n思考: 需要最新的成本数据。\n行动: 网页搜索\n行动输入: 'LLM API 定价 2024'"]; Tool1 [label="工具调用:\n网页搜索(...)"]; Obs1 [label="观察:\n'OpenAI: $X/token...\nAnthropic: $Y/token...'"]; LLM2 [label="LLM 调用 2\n提示: ...观察1...\n思考: 已找到成本。需要比较。\n行动: 最终答案\n行动输入: 'OpenAI 成本 $X, Anthropic 成本 $Y'"]; End [label="最终答案"]; Start -> LLM1 [label=" 输入 "]; LLM1 -> Tool1 [label=" 行动 "]; Tool1 -> Obs1 [label=" 输出 "]; Obs1 -> LLM2 [label=" 观察 "]; LLM2 -> End [label=" 最终答案 "]; } }一个代理执行流程的简化图示,包含一次 LLM 调用、一次工具执行以及一次最终的 LLM 调用以综合答案。LangSmith 会记录每个步骤的详细输入和输出。从追踪记录中解读代理行为分析这些追踪记录对于理解代理行为很重要:跟踪推理: 对于 ReAct 等代理,查阅 LLM 生成的“Thought”部分。它们是否逻辑地连接了当前目标、可用工具以及前一步的观察结果?所选的 Action 与 Thought 是否相符?验证工具使用: 检查 Action Input。代理是否为工具正确格式化了输入?它是否从其记忆或之前的步骤中提取了正确的信息作为输入?审查观察结果: 查看 Observation(工具输出)。返回的信息是否符合代理的预期?如果工具出错,追踪记录将显示异常,有助于准确定位故障。跟踪状态: 观察信息(或信息缺失)如何在步骤间传递。代理是否正确地将来自观察的新数据纳入后续推理步骤?使用追踪记录解决常见的代理问题执行追踪对于调试非常有价值:工具选择不当: 如果代理持续选择 web_search,而特定数据库查询工具更合适,追踪记录会显示这种模式。您可能需要调整代理的提示、工具描述或代理的核心架构。工具执行错误: 如果工具调用失败,追踪记录会显示导致错误的具体输入以及抛出的异常。这可以将问题归结为代理提供了错误的输入,或是工具本身的错误。解析错误: 代理通常需要解析 LLM 的输出来确定下一步行动或提取最终答案。追踪记录会捕获解析前的原始 LLM 输出,从而方便查看 LLM 是否生成了解析器无法处理的格式错误文本。代理循环或效率低下: 通过审查行动序列,您可以发现代理未能取得进展的重复循环。这可能表明逻辑有缺陷、工具设计不佳,或步骤间传递的信息不足。虚构的工具输入: 有时,LLM 可能会为工具生成语法上有效但事实上不正确的输入(例如,数据库查找中不存在的用户 ID)。追踪记录通过显示有问题的 Action Input 使这一点变得明显。性能与成本分析追踪有助于分析效率:延迟瓶颈: LangSmith 自动记录每个步骤(LLM 调用、工具执行)的持续时间。您可以迅速识别代理执行中哪些部分耗时最长。工具调用的慢速外部 API 在追踪计时中会很明显。Token 消耗: 追踪记录中的每次 LLM 调用都与 token 计数(提示 token 和完成 token)关联。通过汇总一次典型执行中的这些数据,您可以估算运营成本并确定哪些步骤特别消耗 token。也许使用更短的提示或不同的模型能以更低的成本达到相同的结果。利用分析来优化代理追踪不仅用于修复错误;它是一个持续改进的工具。定期审查来自真实或模拟交互的追踪记录:是否存在常见的低效推理模式?工具描述能否更清晰,以更好地引导 LLM?代理是否总是需要多个步骤来完成本可以简化的任务?追踪分析的结果直接影响提示工程、工具设计,甚至可能影响代理架构或底层 LLM 的选择,从而实现更有效和可靠的代理。总之,代理执行追踪——主要由 LangSmith 等工具提供便利——将代理从一个不透明的黑盒转变为一个透明的过程。这种可见性并非奢侈品,而是调试复杂交互、优化性能和成本以及在生产环境中建立对代理决策能力信任的必要条件。