目前市场上有多个专门为 AI Agent 可观测性设计的平台。LangSmith 作为 LangChain 团队推出的平台,提供完整的追踪、实时监控和警报功能,并内置了 AI 助手 Polly 来分析追踪并提供性能洞察。对于使用 LangChain 构建的应用,只需几行代码就能获得完整的可见性。

在传统软件开发中,当你想理解一个应用的行为时,你会打开代码阅读。

当出现问题时,你会在代码中查找 bug。当需要优化性能时,你会分析代码。代码就是一切的真相来源。

但在 AI Agent 的世界里,这套方法论已经彻底失效了。

为什么代码不再能记录 Agent 的行为

在传统软件中,当你想了解用户提交表单时发生了什么,你只需打开 handleSubmit() 函数并阅读代码。决策逻辑就在那里：验证输入、检查身份验证、调用 API、处理错误。

这是确定性的——相同的输入、相同的代码路径、相同的输出。

但在 AI Agent 中,代码只是脚手架。

这是一个简化的 Agent 代码示例:

agent = Agent(
    model="gpt-4",
    tools=[search_tool, analysis_tool, visualization_tool],
    system_prompt="You are a helpful data analyst..."
)
result = agent.run(user_query)

你定义了组件:使用哪个模型、哪些工具、什么指令。但决策逻辑并不在你的代码中,代码只是编排了 LLM 的调用。

真正的决策——何时调用哪个工具、如何推理问题、何时停止、优先考虑什么——所有这些都在运行时发生在模型内部。

随着 LLM 在应用中驱动越来越多的功能(这在 Agent 中很常见),你仅通过查看代码就越来越难以了解应用实际会做什么。

你仍然可以调试编排代码——工具调用是否正常、解析是否正确。但你无法调试智能本身。Agent 是否做出了好的决策、是否有效推理——这些逻辑存在于模型中,而不是你的代码库中。

Trace(追踪)成为新的文档

那么实际的行为记录在哪里?答案是追踪(Trace)。

Trace 是 Agent 执行步骤的序列记录。它记录了应用的逻辑——每一步的推理、调用了哪些工具以及原因、结果和时间消耗。

这意味着,在传统软件世界中你对代码进行的操作,现在需要对 Trace 进行。

调试、测试、性能分析、监控——所有这些都从操作代码转向操作追踪记录。

在传统软件中,如果两次运行产生不同的输出,你会假设是不同的输入或不同的代码。在 AI Agent 中,相同的输入和相同的代码可能产生不同的输出。不同的工具调用、不同的推理链、不同的结果。

理解发生了什么的唯一方法是查看 Trace。

为什么任务 A 成功但任务 B 失败?比较追踪记录。你的提示词改进是否提升了推理能力?比较前后的追踪。为什么 Agent 一直犯同样的错误?查看追踪记录中的模式。

这如何改变 Agent 的构建方式

当逻辑的真相来源从代码转移到追踪时,其他一切都会随之改变。

所有你过去对代码进行的操作——调试、测试、优化、监控——现在都需要围绕追踪展开。让我们看看这在实践中意味着什么。

调试变成了追踪分析

当用户报告"Agent 失败了",你不会打开代码查找 bug,而是打开追踪记录,查看推理过程中哪里出了问题。

Agent 是否误解了任务?调用了错误的工具?陷入了循环?

"bug"不是代码中的逻辑错误,而是 Agent 实际行为中的推理错误。

举个例子:一个 Agent 在放弃前对同一个失败的 API 调用重试了五次。你的代码中有重试逻辑——这没问题。问题在于 Agent 没有从错误消息中学习。你只能在追踪中看到这一点:相同的工具调用、相同的参数、相同的失败,重复出现。

你无法在推理中设置断点

在传统软件中,当你找到 bug 时,你会在代码中设置断点。在 AI Agent 中,你无法在推理中设置断点。决策发生在模型内部。

但你可以使用追踪和 Playground 在逻辑中设置断点。

在特定时间点打开追踪——就在 Agent 做出错误决策之前。将那个确切的状态加载到 Playground 中。Playground 就像一个调试器,但针对的是推理而不是代码。

你可以看到:Agent 有什么上下文?记忆中有什么?哪些工具可用?提示词是什么样的?然后你进行迭代——调整提示词、改变上下文、尝试不同的方法——看 Agent 是否做出更好的决策。

测试变成了评估驱动

现在逻辑的真相来源在追踪中,你需要测试这些追踪。这意味着两件事:

首先,你需要一个管道将追踪添加到测试数据集。随着 Agent 的运行,你捕获追踪并将它们添加到可以进行评估的数据集中。

其次,你需要在生产环境中评估追踪。在传统软件中,你在部署前测试然后发布。在 AI 中,Agent 是非确定性的,因此你需要在生产中持续评估,以捕捉质量退化和漂移。

性能优化的方式改变

在传统软件中,你分析代码以找到热点循环并优化算法。在 AI Agent 中,你分析追踪以找到决策模式——不必要的工具调用、冗余的推理、低效的路径。瓶颈在于 Agent 的决策,而这些决策只存在于追踪中。

监控从正常运行时间转向质量

一个 Agent 可能"运行正常",没有错误,但表现糟糕——在错误的任务上成功、以 10 倍的成本低效地成功,或者给出正确但无用的答案。

你需要监控决策的质量,而不仅仅是系统健康——任务成功率、推理质量、工具使用效率。没有抽样和分析追踪,你无法监控质量。

协作转移到可观测性平台

在传统软件中,协作发生在 GitHub 上。你审查代码、在 PR 上留下评论、在 issue 中讨论实现。代码是每个人共同处理的工件。

在 AI Agent 中,逻辑不在代码中——而在追踪中。

因此协作也必须发生在追踪所在的地方。当然,你仍然使用 GitHub 处理编排代码。但当你调试为什么 Agent 做出了错误决策时,你需要分享一个追踪,在特定决策点上添加评论,讨论为什么它选择了这条路径。你的可观测性平台成为协作工具,而不仅仅是监控工具。

产品分析与调试合并

在传统软件中,产品分析与调试是分开的。Mixpanel 告诉你用户点击了什么,错误日志告诉你什么出了问题。它们是用于不同问题的不同工具。

在 AI Agent 中,这两者合并了。你无法在不理解 Agent 行为的情况下理解用户行为。当你在分析中看到"30% 的用户感到沮丧"时,你需要打开追踪来查看 Agent 做错了什么。当你看到"用户要求数据分析功能"时,你需要查看追踪来了解 Agent 已经选择了哪些工具以及什么有效。用户体验就是 Agent 的决策,这些决策记录在追踪中——因此产品分析必须建立在追踪之上。

完成这一转变

在传统软件中,代码是你的文档。在 AI Agent 中,追踪是你的文档。

这种转变很简单:当决策逻辑从代码库转移到模型时,你的真相来源就从代码转移到追踪。你过去对代码做的所有事情——调试、测试、优化、监控、协作——现在你对追踪做这些事情。

要实现这一点,你需要良好的可观测性。可以搜索、过滤和比较的结构化追踪。能够看到完整推理链的能力——调用了哪些工具、花费了多少时间、成本是多少。能够对历史数据运行评估以随时间监控质量的能力。

根据 2025 年的行业调研数据,89% 的组织已经为其 AI Agent 实施了某种形式的可观测性,62% 具有详细追踪功能。在已部署生产环境的组织中,这一比例更高:94% 已实施可观测性,71.5% 具有完整追踪能力。这说明了一个根本事实:如果没有对 Agent 如何推理和行动的可见性,团队就无法可靠地调试失败、优化性能或与利益相关者建立信任。

如果你在构建 Agent 而没有这些能力,你就是在盲目工作。重要的逻辑只存在于那些追踪中。

工具生态系统

目前市场上有多个专门为 AI Agent 可观测性设计的平台。LangSmith 作为 LangChain 团队推出的平台,提供完整的追踪、实时监控和警报功能,并内置了 AI 助手 Polly 来分析追踪并提供性能洞察。对于使用 LangChain 构建的应用,只需几行代码就能获得完整的可见性。

其他主流工具如 Langfuse、AgentOps、Braintrust 等也提供了各自的特色功能——从工作流级追踪到会话回放,从成本监控到多 Agent 交互可视化。

这些工具的共同点是:它们都认识到,在 AI Agent 时代,追踪不再是可选的调试工具,而是理解和改进系统的核心基础设施。

这场从代码到追踪的范式转变,正在重新定义我们构建、调试和优化 AI 应用的方式。拥抱这一转变的团队,将在 AI Agent 的竞赛中占据先机。