代码不再是真相：AI Agent 时代从 Code 到 Traces 的范式转移
LangChain约 7 分钟导读：AI 时代的“代码”与“真相”
本文探讨了在 AI Agent 开发中一个至关重要的范式转变：“真相来源”从代码（Code）转移到了轨迹（Traces）。
在传统软件开发中，代码是逻辑的载体，是确定性的；而在 AI Agent 中，代码只是脚手架，真正的决策逻辑由大模型在运行时动态生成，具有非确定性。文章详细阐述了这一变化如何重塑了调试、测试、性能优化及团队协作的方式，并强调了建立基于轨迹的“可观测性”对于构建高质量 Agent 的必要性。
太长不看（TL;DR）
在传统软件中，你通过阅读代码来理解应用的功能，决策逻辑存在于你的代码库中。 在 AI 智能体（AI Agents）中，代码只是脚手架，实际的决策发生在运行时的模型中。 正因如此，应用功能的“真相来源（Source of Truth）”从代码转移到了轨迹（Traces），轨迹记录了你的智能体实际上做了什么以及为什么这么做。 这一变化改变了我们调试、测试、优化、监控、协作以及理解产品使用情况的方式。 如果你在构建 AI 智能体时没有良好的可观测性，你就失去了了解系统实际行为的真相来源。
在传统软件中，当出现问题时，你会阅读代码。当你想要理解某个功能如何工作时，你会阅读代码。当你想要提升性能时，你会分析代码。代码就是真相来源。在 AI 智能体中，这不再奏效了。
为什么代码无法记录智能体行为
在传统软件中，如果你想了解用户提交表单时发生了什么，你会打开 handleSubmit() 并阅读该函数。决策逻辑就在那里：验证输入、检查权限、调用 API、处理错误。它是确定性的，相同的输入，走相同的代码路径，得到相同的输出。
在 AI 智能体中，代码只是脚手架。 以下是智能体代码的简化版本：
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 驱动你应用的部分越来越多（正如智能体中发生的那样），仅通过查看代码来了解应用实际行为的可见性就越来越低。
你仍然可以调试你的编排代码，工具调用是否正常、解析是否正确。但你无法调试“智能”。智能体是否做出了好的决策、推理是否有效，这些逻辑存在于模型中，而不是你的代码库中。
轨迹作为新的文档
那么实际的行为存在于哪里呢？在轨迹（Traces）中。 轨迹是智能体采取的一系列步骤。它记录了你应用的逻辑，每一步的推理、调用了哪些工具以及原因、结果和时间消耗。
💡这意味着在软件世界中你对代码进行的操作，现在你在智能体世界中要对轨迹进行。
调试、测试、性能分析、监控，所有这些都从针对代码的操作转变为针对轨迹的操作。
在传统软件中，如果两次运行产生不同的输出，你会假设是输入不同或代码不同。在 AI 智能体中，相同的输入和相同的代码可能会产生不同的输出。不同的工具调用、不同的推理链、不同的结果。 理解发生了什么的唯一方法是查看轨迹。为什么任务 A 成功了但任务 B 失败了？比较轨迹。你的提示词（Prompt）修改是否改善了推理？比较修改前后的轨迹。为什么智能体总是犯同样的错误？在轨迹中寻找模式。
这如何改变构建智能体的方式
当逻辑的真相来源从代码转移到轨迹时，其他一切也随之改变。你过去对代码进行的所有操作，调试、测试、优化、监控，现在都需要围绕轨迹进行。让我们看看这在实践中意味着什么。
调试变成轨迹分析
当用户报告“智能体失败了”时，你不会打开代码寻找 bug。你会打开轨迹，查看推理哪里出了问题。智能体是否误解了任务？调用了错误的工具？陷入了死循环？ “Bug”不再是你代码中的逻辑错误。它是智能体实际行为中的推理错误。
例子：一个智能体在放弃之前不断重试同一个失败的 API 调用五次。你的代码有重试逻辑，这工作正常。Bug 在于智能体没有从错误信息中学习。你只能在轨迹中看到这一点：相同的工具调用、相同的参数、相同的失败，不断重复。
你无法在推理中设置断点
在传统软件中，当你发现一个 bug，你会在代码中设置断点。 在 AI 智能体中，你无法在推理中设置断点。决策发生在模型内部。 但你可以利用轨迹 + Playground 在逻辑中设置断点。打开某个时间点的轨迹，就在智能体做出错误决策之前。将那个确切的状态加载到 Playground 中。Playground 就像是一个调试器，但它是针对推理而不是代码的。 你可以看到：智能体拥有什么上下文？它的记忆里有什么？哪些工具可用？提示词是什么样子的？然后你进行迭代，调整提示词、更改上下文、尝试不同的方法，看看智能体是否会做出更好的决策。
测试变成评估驱动（Eval-Driven）
既然逻辑的真相来源在于轨迹，你需要测试这些轨迹。这意味着两件事： 第一：你需要一个管道将轨迹添加到你的测试数据集中。随着智能体的运行，你捕获轨迹并将它们添加到一个可以进行评估（Eval）的数据集中。 第二：你需要在生产环境中评估轨迹。在传统软件中，你在部署前测试然后发布。在 AI 中，智能体是非确定性的，所以你需要持续在生产环境中进行评估，以捕捉质量下降和漂移。
性能优化发生变化
在传统软件中，你分析代码以查找热点循环并优化算法。在 AI 智能体中，你分析轨迹以查找决策模式，不必要的工具调用、冗余的推理、低效的路径。瓶颈在于智能体的决策，而这些只存在于轨迹中。
监控从“在线时间”转向“质量”
一个智能体可能“在线”且 0 错误，但表现极其糟糕，在错误的任务上成功、以 10 倍的成本低效地成功、或者给出正确但无用的答案。 你需要监控决策的质量，而不仅仅是系统健康状况，任务成功率、推理质量、工具使用效率。如果不采样和分析轨迹，你就无法监控质量。
协作转移到可观测性平台
在传统软件中，协作发生在 GitHub 上。你审查代码、在 PR 上留言、在 Issue 中讨论实现。代码是大家工作的对象。 在 AI 智能体中，逻辑不在代码中，它在轨迹中。所以协作也必须发生在轨迹所在的地方。当然，你仍然使用 GitHub 管理编排代码。但当你调试智能体为什么做出错误决策时，你需要分享一个轨迹，在特定的决策点添加评论，讨论为什么它选择了这条路径。你的可观测性平台变成了协作工具，而不仅仅是监控工具。
产品分析与调试融合
在传统软件中，产品分析与调试是分开的。Mixpanel 告诉你用户点击了什么。你的错误日志告诉你什么坏了。它们是针对不同问题的不同工具。 在 AI 智能体中，这两者融合了。如果不理解智能体的行为，你就无法理解用户的行为。当你在分析中看到“30% 的用户感到沮丧”时，你需要打开轨迹看看智能体做错了什么。当看到“用户要求数据分析功能”时，你需要查看轨迹，看看智能体已经选择了哪些工具以及哪些是有效的。用户体验就是智能体的决策，而这些决策记录在轨迹中，所以产品分析必须建立在轨迹之上。
做出转变
在传统软件中，代码是你的文档。在 AI 智能体中，轨迹是你的文档。
这个转变很简单：当决策逻辑从你的代码库移动到模型时，你的真相来源也从代码移动到了轨迹。
💡过去你用代码做的一切，调试、测试、优化、监控、协作，现在你都要用轨迹来做。
为了实现这一点，你需要良好的可观测性。结构化的轨迹，你可以搜索、过滤和比较。能够看到完整的推理链，调用了哪些工具、花了多长时间、成本多少。能够对历史数据运行评估以监控随时间变化的质量。
如果你在构建智能体却没有这些，那你就是在盲人摸象。真正重要的逻辑只存在于那些轨迹之中。
总结与解读
本文揭示了 AI 开发的核心范式转移：从“代码即逻辑”到“轨迹即真相”。在 Agent 时代，代码退化为脚手架，真正的智能决策由模型运行时生成。因此，传统的调试、测试与监控手段失效，开发者必须转向以“轨迹（Trace）”为中心的可观测性体系。只有通过分析推理链条，才能真正洞察并优化 Agent 的不确定性行为。这不仅是工具的更新，更是开发思维的重构：不掌握轨迹，就是盲人摸象。
原文：https://x.com/LangChain/status/2025366346973007956