从黑盒到可观测性：使用 MLflow 追踪 OpenClaw
OpenClaw 是一款开源的个人 AI 智能体，运行在您的本地机器上。您可以通过 WhatsApp、Telegram、Discord、Slack 或 20 多种即时通讯渠道与它交流，它可以代表您采取行动：整理电子邮件、管理 Notion 和 Things 3 中的任务、进行网页搜索、读取和写入本地文件，以及编排您构建的任何自定义技能。凭借 GitHub 上超过 68,000 颗星以及 ClawHub 上 5,400 多个社区构建的技能，它已迅速成为运行本地优先 AI 助手的最流行方式之一。
挑战在于，OpenClaw 的强大之处源于其自主性。它决定调用哪些工具、以何种顺序调用，以及是否为子任务生成子智能体。这使其功能强大，但也变得不透明。当智能体出色地处理请求时，您不知道原因；当它处理得很差时，您不知道哪里出了错。您在聊天中看到的仅仅是最终的回复消息。
本文展示了如何将 MLflow 追踪（MLflow Tracing）添加到 OpenClaw，从而使每一次智能体运行都成为一个完全可审查的执行时间轴。我们将介绍设置过程，说明追踪捕获的内容，并使用一个具体的示例展示追踪如何将模糊的怀疑转化为可操作的调试信息。
为什么追踪对个人智能体很重要
您可能认为追踪仅适用于具有服务等级协议 (SLA) 和正常运行时间要求的生产系统。但个人智能体也面临着同样问题的变体：您依赖智能体为您完成实际工作，当它出错时，您需要了解发生了什么以便修复它。
考虑一些没有追踪就很难调试的场景。您要求 OpenClaw 智能体总结本周的 AI 新闻并起草一份简报。总结很浅显，且遗漏了最重要的报道。是网页搜索工具返回的结果很差吗？模型在总结过程中忽略了相关结果吗？它是否达到了上下文窗口限制并默默丢弃了内容？您要求它根据您的日历重新安排会议，但它选择了错误的时间段。是日历工具返回了过时的数据吗？模型误解了您给出的约束条件吗？仅从聊天回复中，您无法获知这些信息。
追踪 捕获了每次智能体运行的完整执行路径：包含提示词和响应的每一次 LLM 调用、包含参数和结果的每一次工具调用、每一次子智能体生成及其嵌套的步骤，以及所有内容的令牌计数和耗时。该记录将调试从猜测变成了直接检查。您打开追踪记录，找到偏离预期的地方，现在您确切地知道要修复什么，无论是技能定义、工具配置还是您的提问方式。
除了调试单次运行外，追踪还成为系统性改进智能体的基础。当您能看到智能体如何处理任务时，就可以给它有针对性的反馈，优化它使用的技能，并验证您的更改是否有效。追踪正是实现这一反馈循环的关键。
您的数据保留在本地
MLflow 在此非常契合的原因之一是它与 OpenClaw 共享相同的本地优先理念。MLflow 是 100% 开源的，由 Linux 基金会管理，并完全支持自托管。当您在机器上运行 MLflow 服务器时，来自 OpenClaw 智能体的所有追踪数据都会保留在您的基础设施中，绝不会离开。没有任何遥测数据发送给第三方，也没有任何供应商能够访问您的提示词或工具输出。对于处理您的电子邮件、日历和文件的个人智能体来说，这一点至关重要。
通过 AI Gateway 管理 LLM 访问
OpenClaw 自行决定何时调用 LLM 以及调用哪些工具。这种自主性正是它的核心，但也意味着智能体可以在您不知情的情况下进行大量的 API 调用。如果您将 API 密钥放在环境变量中或分散在配置文件中，它们就会暴露给您机器上的每个进程。如果某个技能触发了重试循环，或者生成的每个子智能体都进行自己的模型调用，成本会迅速累积，且没有单一的地方可以控制它。
MLflow AI Gateway 位于 OpenClaw 和您的 LLM 提供商之间，可以解决这两个问题。您可以将 API 密钥存储在网关中，它们会被加密且绝不会暴露给客户端代码。网关还为您提供了一个统一的地方来设置所有提供商的全局预算限制，因此即使某个循环失控，也不会在您不知情的情况下产生高昂费用。对于一个自主决定何时及多久调用一次 LLM 的智能体来说，这种护栏是非常值得拥有的。
使用 OpenClaw 设置 MLflow 追踪
只需三个步骤即可开始。首先，安装 OpenClaw MLflow 插件。
openclaw plugins install @mlflow/mlflow-openclaw
然后启动一个本地 MLflow 服务器来接收追踪数据。
uvx mlflow server --port 5000
MLflow 支持多种部署选项，如 Docker、Kubernetes 以及像 Databricks 和 AWS SageMaker 这样的托管服务。更多详情请参阅 设置 MLflow 服务器。
接着使用内置的设置向导配置 MLflow 连接。
openclaw mlflow configure
向导会引导您交互式地设置追踪 URI 和实验 ID。如果您更喜欢手动设置，也可以使用环境变量。
export MLFLOW_TRACKING_URI=https://:5000
export MLFLOW_EXPERIMENT_ID=<your-experiment-id>
就是这样。像往常一样启动 OpenClaw 并正常使用。一旦启用集成，追踪就是自动的。每次智能体运行都会生成一个记录在您 MLflow 服务器中的追踪。无需修改您的技能、工具定义或智能体配置。
在浏览器中打开 https://:5000，随着 OpenClaw 智能体的运行，您将看到追踪记录出现。
追踪的样子
每次 OpenClaw 智能体运行都会产生一个分层的跨度（span）树。最顶部是根智能体跨度，代表从您的消息到达那一刻到智能体发送回复的那一刻的整个运行过程。嵌套在其中是智能体采取的各个步骤，按类型组织。
LLM 跨度 捕获每次模型调用，包括发送给模型的完整提示词、接收到的响应以及令牌计数（输入、输出、总计）。由于 OpenClaw 使用了 ReAct 循环，即模型进行推理、行动、观察并再次推理，因此单个用户请求可以生成多个 LLM 回合。每一回合都显示为自己的跨度，因此您可以逐步跟踪智能体的推理链。
工具跨度 记录每一次工具调用。您可以查看工具名称、模型选择传递的参数以及返回值或错误。当工具调用失败时，错误消息会直接捕获在跨度中，使其立即可见。这对于 OpenClaw 丰富的工具生态系统特别有用，因为单个请求可能会涉及网页搜索、文件 I/O、日历 API 和即时通讯渠道。
子智能体跨度 在 OpenClaw 生成子智能体来处理子任务时出现。每个子智能体在跨度树中都有自己的分支，内部嵌套着属于它自己的 LLM 和工具跨度。即使智能体将任务委托给其他智能体，这也能让您了解完整的执行过程。
每个跨度都带有元数据，包括时间戳、持续时间和使用统计信息。最终结果是智能体所做一切的完整、可审查的时间轴。
通过仪表盘监控趋势
一旦追踪数据开始流入 MLflow，操作仪表盘就会让您鸟瞰智能体的表现。您可以查看跨运行的错误率、调用最频繁的工具以及令牌消耗随时间的趋势。如果您更新技能后智能体故障率增加，或者由于新工具触发了更长的推理链导致令牌使用量激增，仪表盘会在您聊天中注意到之前就将这些信息呈现出来。可以将其视为个人智能体的健康检查：一个单一页面，告诉您运行是否顺畅，或者是否有需要关注的地方。您还可以启用 自动评估 来为每个传入的追踪评分，以便在智能体运行时自动标记有问题的行为。
从观察到改进
追踪对于调试很有用，但它们真正的价值在于关闭您与智能体之间的反馈回路。
当您查看追踪记录并注意到智能体表现好坏时，您可以在 MLflow 中将该反馈记录为追踪或会话（共享同一会话 ID 的一组追踪）上的结构化标注。在使用了错误工具的追踪上点个踩，在智能体错过先前消息上下文的会话上写个备注。随着时间的推移，这会建立起一个关于智能体做得对和做错什么的标签数据集。该数据集成为后续所有工作的基础：评估新技能版本、调整提示词以及了解您的智能体能可靠处理哪些类型的请求。
有趣的部分来了。您可以通过 MLflow CLI 和技能 让 OpenClaw 直接访问其自身的追踪和反馈。智能体可以读取其过去的运行记录，查看哪些收到了负面反馈，并利用这些信息来优化其自身的技能定义。您提供信号（对追踪的反馈），智能体负责将该信号转化为更好的行为。这就是追踪所实现的自我改进循环：观察、标注，并让智能体从自身的历史中学习。
接下来是什么
追踪是基础，而不是上限。一旦您具备了可见性和反馈习惯，自然的下一步就是 评估。为您最关心的质量维度定义评分器，并针对您收集的追踪运行它们。裁判会呈现出您手动可能未注意到的模式：也许您的智能体总是过于冗长，或者总是无法引用来源，又或者处理某类请求比处理另一类请求要好得多。MLflow 还支持 持续评估，它会在每个新追踪到达时自动进行评分，因此您根本无需手动运行评估。
这种发展是有意为之的：从可见性开始，增加人类反馈，然后自动化质量测量。每一步都建立在前一步的基础上，您可以根据自己的需要选择停止在哪一级。
如果这对您有用，请在 GitHub 上给我们加个星标：github.com/mlflow/mlflow⭐️