Telemetry-driven development: How to gain confidence in your coding agents' behavior with gcx and Grafana MCP

你正准备点击PR的"合并"按钮，但你对这次合并的焦虑感却比以往更强烈。为什么？

你已经按照当今的标准正确完成了所有步骤：你使用Claude制定了计划，提供了GitHub问题和一些Slack线程的上下文信息。你对计划进行了几次迭代；Claude表示它掌握了"完整情况"。你感觉已经准备就绪，于是使用Claude Code来实现该计划。你运行了审查代理对diff进行检查，并解决了部分评论。你开始阅读diff，但内容很长。你试图构建一个关于这些更改及其如何与系统配合的思维模型。与Claude进行几次反馈和提问循环后，事情看起来……还行。于是你创建了PR。AI审查结果全部通过，你的同事给出了"LGTM - ship it"的反馈。

那么为什么你仍然感到不安？很可能是因为你无法像自己亲自编写代码那样完全理解代码diff。

在AI出现之前，我们在编写更改时会构建系统变化的思维模型，并依赖这些模型确保部署的代码行为符合预期。然而，当AI负责进行更改时，这种情况发生的频率正在降低。编码代理虽然提高了交付速度，但我们的理解速度却在落后。我们需要一种更好的方式来保持对更改的信心。

幸运的是，更多数据可以帮助我们在这种情况下做出更好的决策。虽然使用代理生成代码会让你在知识或信心上有所损失，但通过观察系统按照预期运行和表现，你可以获得补偿。良好的可观测性可以帮助你在整个软件生命周期（包括构建阶段）中实现这一点。

在本文中，我将向你展示如何通过使用我们的AI工具来增强对代码和代理的信心。

[为编码代理提供遥测数据访问权限](https://grafana.com/blog/telemetry-driven-development-how-to-gain-confidence-in-your-coding-agents-behavior-with-gcx-and-grafana-mcp/#give-your-coding-agent-access-to-your-telemetry)

首先，让我们让你了解我们提供的工具，帮助你适应这一新环境。

Grafana MCP服务器和Grafana Cloud CLI（gcx）都可以将你的代理连接到Grafana实例，并允许它们与遥测数据进行交互。

• Grafana MCP服务器，你可以自行运行或通过Grafana Cloud堆栈的托管MCP服务器使用，为一组常见用例提供定制化工具。

• gcx 是一个更灵活、定制化程度较低的工具，代理可以探索并使用它来构建自己的工作流。gcx可用于Grafana Cloud堆栈或自托管的OSS或企业实例。

这两款工具现已全面发布。

如果你使用的是 Claude Code，可以轻松地将 Grafana MCP 服务器安装为插件。我们还提供Grafana Assistant 插件，可提供与 Grafana Assistant 交互的指导。gcx 自带一组技能，你可以通过 gcx agent skills install 进行安装。这些技能可以教会你的代理高效地使用 gcx 完成一些常见工作流程。

[让代理理解系统现有行为](https://grafana.com/blog/telemetry-driven-development-how-to-gain-confidence-in-your-coding-agents-behavior-with-gcx-and-grafana-mcp/#let-your-agents-understand-your-systems-existing-behavior)

我们开发这些工具是为了应对与代理协作时遇到的挑战，因为当代理理解系统实际运行方式时，它们能提供更有价值的结果：例如真实的请求速率和大小、哪些代码路径繁忙而哪些不繁忙。这些数据可以防止代理过度优化使用频率较低的代码路径，或帮助其为负载测试生成更贴近实际的合成数据。

除了访问你的遥测数据，代理还可以使用你的SLO 定义、合成监控检查等，以获取更多关于你如何运营系统的上下文信息，从而规划最适合团队工作方式的变更。SLO 定义会向代理展示系统的关键指标，合成监控检查则会从外部调用者的视角展示期望的行为。

gcx 让人类和代理能够从终端查询其遥测数据

假设你正在为支付服务添加一个新提供商。假设你已经有了一个显示支付服务RED 指标的仪表板，并且可以看到现有提供商 Swipe 的 p95 请求延迟为两秒。你将告诉代理你期望 30% 的流量转移到这个新提供商，并且预期延迟保持不变。

你的代理可以从生产环境获取真实的遥测数据，将这些需求与实际情况结合，这可能会影响代理建议的实现方式，因为它知道需要处理哪些需求和限制。例如，它可以查找当前支付请求速率以估算新请求处理器的预期请求速率。在进行单元和集成测试时，它还会知道在模拟支付提供商时添加内置延迟。

结果将是一个在类似生产环境的环境中表现符合预期的逻辑，因为代理是根据真实数据进行引导，而不是基于其训练数据做出假设。

你知道吗？你可以在命令行上继续Grafana Assistant的对话。如果你想将对话中的上下文传递给你的编码代理，这会非常有用。在Assistant侧边栏或Assistant工作区中，点击三个点，然后点击‘"Hand off Conversation"，你将看到一个用于拉取对话记录的gcx命令。

[基于遥测数据的开发](https://grafana.com/blog/telemetry-driven-development-how-to-gain-confidence-in-your-coding-agents-behavior-with-gcx-and-grafana-mcp/#telemetry-driven-development)

除非你的系统是全新的，否则很可能已经在发出遥测数据，并且已经设置了一些仪表板或SLO来监控其健康状况。这些现有数据点可以成为代理规范的一部分，与你编写的规范和测试标准相辅相成。

如果你是可观测性领域的新手，或者不确定系统中需要哪些指标或遥测数据，或者添加这些功能的工作看起来令人望而生畏，请查看gcx附带的gcx-observability技能。该技能将引导你和你的代理对代码库进行仪器化，并向你展示其他可观测性功能的使用方法。使用gcx agent skills get gcx-observability查看该技能。

为了说明这一点，让我们继续以支付提供商为例，我们有一个显示RED指标的现有仪表板。你需要确保能够检测到新提供商的问题，因此你告诉代理更新仪表板以按提供商汇总指标。使用gcx或Grafana MCP服务器，你的代理可以读取和更新这些仪表板。它还可以将更新后的仪表板规范写入源代码控制或推回Grafana。它甚至可以检查仪表板中使用的查询，并找到代码库中需要更新遥测数据的位置。

在构建过程中充分利用遥测数据时，你的代理还需要不断迭代更改，直到观察到期望的行为。要查看这些指标中的数据，它需要从本地构建中导出遥测数据。这种设置任务通过AI会更容易：代理已经训练过许多开源可观测性产品，知道如何运行OpenTelemetry Collector并将这些数据发送到你的Grafana堆栈（参见我们的CTO Tom Wilkie的文章为什么开源是AI的作弊代码）。

如果你想使用完全本地的设置，告诉你的代理使用grafana/otel-lgtm Docker镜像来获得开箱即用的LGTM堆栈。你可以配置gcx与本地的Grafana实例进行交互。在我们的示例中，你可以使用gcx resources pull从生产环境拉取支付仪表板，并将其推送到本地Grafana实例。代理（在沿途阅读gcx文档的帮助下）还可以帮助调整一些数据源设置，使你拥有可以验证的仪表板和指标。

因此，你可以通过遥测数据获得一个全自动的反馈循环，编码代理可以利用这个反馈循环不断迭代改进，直到达到你期望的状态。

生成一些流量

从这里开始，你可能需要模拟一些支付流量来观察其行为。这是另一种过去耗时且困难的任务类型：在没有人工智能的情况下，你需要理解流量的形状，要么手动编写一些示例请求来覆盖你能想到的场景，要么使用模糊测试工具为流量增加多样性。然后你需要去学习k6编写测试脚本的语法，甚至还需要弄清楚如何在本地运行k6。这至少需要一整天的工作量。

现在借助人工智能，你可以让代理为你生成示例流量、编写测试脚本，甚至帮你在一个Docker容器中部署k6。它可以访问生产环境的遥测数据，了解哪种请求形状和频率对你最有帮助。然后你可以观察系统在负载下的表现。这使你更接近证明系统在真实条件下能够正常运行。

k6自带了一套代理技能包，你可以通过 k6 x agent init <target> 命令安装（例如 k6 x agent init claude-code，或使用 --all 安装所有支持的工具）。和这个工作流的其他部分一样，这些技能都依赖于你的遥测数据：它们可以教会你的代理从真实流量中编写新测试，判断失败运行是测试问题还是被测系统问题，并分析多次运行的趋势以提出修复方案或在生产环境出现问题前收紧阈值。

当你能够看到本地构建运行，并且看到系统在真实负载下表现和性能符合预期时，你会获得更多的信心。你可以更快地构建系统，同时仍然保持对流程的掌控。

改进循环

代理还可以为你建议改进方案。告诉代理将系统内存占用减少10%，它就可以查询性能分析数据，找到代码中的热点，然后创建一个解释其更改内容的PR草案。从那里，你可以使用你的k6脚本和遥测设置来验证更改是否有效。

Grafana Labs的Tempo团队已经在使用类似模式：他们有一个自定义的代理框架，会迭代地对具有显著负载的开发环境进行性能分析——通常是在其存储桶中有几个TB的数据。

对于每次分析，它会对开发环境执行一些查询以获取基准数据。然后它会检查部署的性能分析结果，寻找改进机会。如果发现改进点，它会实施更改、部署并重新运行相同查询与基准数据进行对比。凭借这些数据，团队可以决定是否提交更改。

不幸的是，遥测数据无法全面反映用户界面的情况。不过，我们已发布Agentic Testing（实验性功能），允许用户使用自然语言描述一组指令和验证规则，让代理针对公开的网络应用执行操作。这些测试有助于检测用户界面的回归问题，相比传统浏览器测试，它们更易于定义，也更能应对用户界面的变化。

重新掌控控制权

现在，您不再需要面对半理解的PR和代理生成的描述，而是可以拥有一个包含链接的PR，这些链接指向仪表板，展示本地构建在真实负载下按预期运行的情况。

以我们的示例为例，您可以展示在指标和日志中新增支付提供商标签的位置。如果将本地构建的遥测数据导出到Grafana，还可以添加一个链接，指向您新建的仪表板，显示在执行负载测试时新提供商的指标数据。这将向审查者证明，支付处理程序能够很好地处理30%的负载。

还有更多证据可以帮助您和PR审查者确信更改后的功能会按预期运行。这些额外的证据也能减轻审查者的认知负担。

_Grafana Assistant_ _是使用Grafana Cloud中指标、日志、追踪、仪表板等功能最简单的方式。我们提供永久免费的高级免费层级，并为所有使用场景提供相应方案。_ _立即免费注册_

Tags