在软件领域，代码为应用程序提供说明。在AI领域，是轨迹。

TL;DR

• 在传统软件中，你通过阅读代码来理解应用程序的功能 - 决策逻辑存在于你的代码库中
• 在人工智能代理中，代码只是框架 - 实际的决策发生在运行时的模型中
• 由于此，应用程序功能的真实来源从代码转移到跟踪 - 跟踪记录代理实际做了什么以及为什么做
• 这改变了我们调试、测试、优化、监控、协作和理解产品使用的方式
• 如果你在没有良好可观察性的情况下构建代理，你将缺乏了解系统实际做什么的真实来源

---

在传统软件中，当出现问题时，你会阅读代码。当你想了解某个功能的工作原理时，你会阅读代码。当你想提高性能时，你会分析代码。代码是真实来源。

在人工智能代理中，这种方法不再有效。

为什么代码不能记录代理行为

在传统软件中，如果你想了解当用户提交表单时会发生什么，你会打开 handleSubmit() 函数并阅读代码。决策逻辑就在那里：验证输入、检查身份验证、调用 API、处理错误。它是确定性的 - 相同的输入，相同的代码路径，相同的输出。

在人工智能代理中，代码只是框架。

以下是代理代码的简化版本：

agent = Agent(
    model="gpt-4",
    tools=[search_tool, analysis_tool, visualization_tool],
    system_prompt="您是一个有帮助的数据分析师..."
)
result = agent.run(user_query)

你已经定义了组件：哪个模型、哪些工具、什么指令。但决策逻辑不在你的代码中。它只是协调了 LLM 调用。

实际的决策 - 何时调用哪个工具、如何推理问题、何时停止、什么优先级 - 都发生在运行时的模型中。

💡
当 LLM 驱动更多应用程序（如代理）时，你通过查看代码就能看到应用程序实际会做什么的可见性越来越低。

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

跟踪作为新的文档

那么，实际行为存在哪里？在跟踪中。

跟踪是代理采取的步骤序列。它记录了应用程序的逻辑 - 每一步的推理、调用了哪些工具以及为什么调用、结果和时间。

💡
这意味着你在软件世界中对代码执行的操作，现在在代理世界中对跟踪执行。

调试、测试、分析、监控 - 所有这些都从操作代码转移到操作跟踪。

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

唯一了解发生了什么的方法是查看跟踪。任务 A 成功但任务 B 失败的原因是什么？比较跟踪。提示更改是否改善了推理？比较更改前后的跟踪。代理为什么一直犯同样的错误？查看跟踪中的模式。

这如何改变构建代理

当逻辑的真实来源从代码转移到跟踪时，其他一切都随之改变。所有你以前对代码执行的操作 - 调试、测试、优化、监控 - 现在都需要围绕跟踪。让我们看看这在实践中意味着什么。

调试变为跟踪分析

当用户报告“代理失败”时，你不打开代码并寻找 bug。你打开跟踪并寻找推理出错的位置。代理是否误解了任务？调用了错误的工具？陷入了循环？

“bug”不是代码中的逻辑错误。它是代理实际做了什么的推理错误。

示例：代理在放弃之前重试同一个失败的 API 调用五次。你的代码有重试逻辑 - 这是有效的。bug 是代理没有从错误消息中学习。你只在跟踪中看到这一点：同一个工具调用、相同的参数、相同的失败、重复。

你不能在推理中设置断点

在传统软件中，当你找到 bug 时，你在代码中设置断点。

在人工智能代理中，你不能在推理中设置断点。决策发生在模型内部。

但你可以使用跟踪 + playground 在逻辑中设置断点。打开跟踪中的特定时间点 - 代理做出错误决策之前。将该确切状态加载到 playground 中。playground 就像调试器，但用于推理而不是代码。

你可以看到：代理有哪些上下文？内存中有什么？哪些工具可用？提示看起来是什么？然后你迭代 - 调整提示、更改上下文、尝试不同的方法 - 并查看代理是否做出更好的决策。

测试变为评估驱动

现在逻辑的真实来源在跟踪中，你需要测试这些跟踪。这意味着两件事：

首先：你需要一个管道将跟踪添加到你的测试数据集中。随着代理的运行，你捕获跟踪并将它们添加到可以评估的数据集中。

其次：你需要在生产中评估跟踪。在传统软件中，你在部署之前测试并发布。在人工智能中，代理是非确定性的，因此你需要在生产中持续评估以捕获质量下降和漂移。

性能优化发生变化

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

监控从正常运行转移到质量

代理可以“正常运行”且没有错误，但仍然表现糟糕 - 成功完成错误的任务、以 10 倍的成本低效地成功完成任务，或提供正确但无用的答案。

你需要监控决策的质量，而不仅仅是系统健康 - 任务成功率、推理质量、工具使用效率。你不能在没有采样和分析跟踪的情况下监控质量。

协作转移到可观察性平台

在传统软件中，协作发生在 GitHub 中。你审查代码、在 PR 上留言、在问题中讨论实现。代码是每个人都在处理的工件。

在人工智能代理中，逻辑不在代码中 - 它在跟踪中。因此，协作必须发生在跟踪也存在的地方。当然，你仍然使用 GitHub 来处理编排代码。但是，当你调试代理做出错误决策的原因时，你需要共享跟踪、在特定决策点添加注释、讨论为什么选择了这条路径。你的可观察性平台成为协作工具，而不仅仅是监控工具。

产品分析与调试合并

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

在人工智能代理中，这些合并了。你不能在不了解代理行为的情况下了解用户行为。当你在分析中看到“30% 的用户感到沮丧”时，你需要打开跟踪来查看代理做错了什么。当你看到“用户正在请求数据分析功能”时，你需要查看跟踪来查看代理已经选择了哪些工具以及什么是有效的。用户体验是代理的决策，而这些决策记录在跟踪中 - 因此，产品分析必须建立在跟踪之上。

进行转变

在传统软件中，代码是你的文档。在人工智能代理中，跟踪是你的文档。

转变很简单：当决策逻辑从你的代码库转移到模型时，你的真实来源从代码转移到跟踪。

💡
你以前对代码执行的所有操作 - 调试、测试、优化、监控、协作 - 现在都需要对跟踪执行。

要使其生效，你需要良好的可观察性。结构化跟踪可以搜索、过滤和比较。查看完整推理链的能力 - 调用了哪些工具、花费了多长时间、花费了多少成本。运行历史数据评估以随时间监控质量的能力。

如果你正在构建代理且没有这些，你就像在黑暗中工作。重要的逻辑只存在于这些跟踪中。