6 improvements that make Grafana Assistant better at helping your workflows

当您要求 Grafana Assistant 创建仪表板或调查告警时，这意味着有工作需要完成。要有效完成这些工作，您需要获取正确的数据、可检查的更改以及由证据支持的结论。同时，您也希望 Assistant 能避免错误并快速响应。

过去六个月，我们的团队努力改进了实现这些成果的关键要素。我们改变了代理查找上下文、发现能力、编辑仪表板和从错误中恢复的方式。同时，我们建立了更有效的方法来判断改进措施是否真正带来帮助。

这些项目紧密相关。更准确的评估能揭示代理的薄弱环节。这些发现会指导其工具和上下文的改进。生产环境的遥测数据会告诉我们这些改进是否有效，以及下一步需要关注的方向。

我们一直在工程博客 Unprompted 上记录这项工作，深入探讨这些努力背后的决策和实现细节。今天，我想分享这些改进如何为我们的用户带来更好的成果。

仪表板构建：更快、更美观、更少错误

到 2026 年中，仪表板模式占 Assistant 交互的 27%。用户也明确指出了需要改进的具体方向：某些操作速度较慢、消耗过多令牌或修改了不应更改的内容。

团队首先通过 Agent Observability 建立基准，并构建可复现的测试。在大约 10 周时间内，报告的 仪表板错误率从 2.47% 降至 0.65%。单个操作的 95 分位数延迟从 63 秒降至 28.8 秒，而每请求成本下降了 18%。

如 Dominik Broj 在其仪表板文章中所述，这些成果来自反复进行的特定改进。工程师在生产环境中发现故障，将其复现为评估场景，修复根本问题，并在部署后验证结果。仪表板测试用例库从 78 个场景扩展到近 200 个。

了解更多： 阅读 Dominik 的博文 "我们改进 Grafana Assistant 仪表板模式的历程"

他人构建代理循环，我们构建评估循环以实现最佳成果

这一过程的影响不仅限于仪表板。它为我们提供了一种方法，将个别报告转化为可测试的改进措施，无论系统如何变化都可以再次验证。

AI代理即使基础工作存在错误，也能生成令人信服的回应。面板可能成功渲染但显示错误的聚合结果。调查可能在缺乏足够证据的情况下识别出看似合理的诱因。仅评估最终答案会忽略决定任务成败的诸多因素。

在关于为Assistant构建评估循环的博客文章中，Yasir Ekinci解释了我们如何将期望行为与实现它的提示和代码分离。场景定义了现实任务和成功标准。评分器会检查查询、工具调用、保存的状态和结论。重复运行可以暴露不一致行为，而对比分析则能跟踪质量与成本和延迟的关联。

这种分离为我们提供了实验空间。我们可以在保持相同预期的前提下更改提示、工具或模型。代码代理还能帮助检查失败原因并提出修改方案，这些方案会重新经过评估循环进行验证和人工审核。

了解更多： 阅读Yasir的博客文章，《为Grafana Assistant构建评估循环》

[gcx：教本地代理如何设计面向代理的CLI](https://grafana.com/blog/six-improvements-that-make-grafana-assistant-better-at-helping-your-workflows/#gcx-teaching-your-local-agent-how-to-designing-a-cli-built-f)

Ward Bekker在描述设计gcx时也提到了这一原则。观察代理使用我们的CLI时，反复出现失败案例：猜测标志参数、重复执行失败命令、请求远超需求的输出。

随着gcx（我们专为代理设计的CLI）的推出，这些问题得到解决。该工具使接口更加信息丰富。命令会描述自身功能，错误会说明恢复方法。代理可以在将结果纳入上下文前检查可用字段并过滤结果。过去需要独立手册的知识，现在越来越多地直接集成到工具本身，从而与实现保持同步。

从根本上说，gcx提出一个实际问题：界面应该向代理提供哪些信息，才能让它正确采取下一步行动？

[降低上下文负担](https://grafana.com/blog/six-improvements-that-make-grafana-assistant-better-at-helping-your-workflows/#lowering-the-context-burden)

随着能力数量的增长，这个问题变得愈发重要。在关于渐进式工具发现的博客中，Cyril Tovena描述了Assistant如何在需要时发现详细的工具指令。与其提前加载所有模式，它会从紧凑的入口点开始，仅检索相关手册。

根据文章中对完整注册工具表面的测量，初始工具定义的预估令牌数从约54,500减少到504，这特定上下文开销减少了99.1%；实际会话节省取决于可用和使用的功能。

更广泛的好处是Assistant可以增加功能而无需每次对话都携带所有指令，你的使用成本也会降低：系统提示中的令牌更少，前期开销更小。我们仍然会衡量完整工作流：更小的提示只有在发现过程不引入过多步骤或延迟时才有帮助。

了解更多：阅读 Ward 的博文 "CLIs in the age of agents: how we designed gcx" 和 Cyril 的博文 "Progressive tool discovery: battling tool overload in AI agents"

查找信息不需要困难

你的仪表板、告警和事件历史中包含了系统运行方式的知识。要使这些知识易于获取，仅仅将文档放入搜索索引是不够的。

Ioanna Armouti 关于改进 Assistant 搜索功能的故事描述了其检索系统背后的设计决策。对于仪表板，嵌入原始面板 JSON 会突出渲染细节。通过文件夹、仪表板名称、行位置、描述和查询来表示面板，使其目的更加清晰。事件摘要需要与嘈杂的活动流进行区分处理。在检索结果时需要检查权限，因为索引后访问权限可能会发生变化。

这里与工具发现和仪表板编辑存在关联：三者都通过控制进入代理上下文的信息量，使相关信息更易获取。只有当代理能够找到并使用正确的信息部分时，更多信息才有价值。

调查团队在测试真实事件时直接观察到了这一点。

了解更多：阅读 Ioanna 的博文 "Search, but deeper: how Grafana Assistant finds the right context"

通过调查实现更快更精准的根本原因分析

今年早些时候我们意识到，基于合成遥测的成功测试并不充分。真实事件带来了不完整的数据、相互竞争的解释和干扰信号。

在他的文章中，William Dumont 描述了我们如何借鉴竞技编程领域的概念，通过比较代理变体在解决事件中的表现，从而暴露具体问题。

一个代理过度依赖告警名称进行推断；获取实际告警定义为其提供了更好的起点。另一个代理因指令中描述了错误的查询语言而避免使用有用工具；过滤检索到的背景信息减少了无关上下文。

在一周的迭代过程中，内部困难事件套件的得分从 52% 提升至 69%。该得分衡量了在基准案例中的表现。持久价值在于能够识别出为何一个调查在某个场景下成功而另一个失败，并持续测试承认证据不足的困难行为。最终，这项持续进行的工作转化为更可靠的建议，从而建立更好的信任关系并带来更好的结果。

了解更多：阅读 William 的博文 "Enter the arena: evaluating and improving Grafana Assistant Investigations against real incidents"

[规模评估无需昂贵](https://grafana.com/blog/six-improvements-that-make-grafana-assistant-better-at-helping-your-workflows/#evaluations-at-scale-dont-need-to-be-expensive)

随着代理开始执行更长的工作序列，我们最初的生产评估器由于过度关注响应文本，越来越频繁地漏掉失败情况。Yasir Ekinci 和 Sven Großmann 描述了重建过程：向评估器展示代理更多工作内容，让它能够识别部分完成情况，并将其判断与更强大的参考评审员进行对比。

随后他们测试了专为结构化决策设计的 Jev 模型。该模型显著更快且成本更低，但与最强生成判断模型的一致性要低得多。我们保留了更强的判断模型作为主要质量评分标准，并将 Jev 作为可选提供方引入，配套提供追踪-分类模板。该模型在不同任务中的适用性仍需要代表性验证。

这是实验的重要组成部分：理解新方法的适用场景，包括在哪些方面应保留现有有效方案。

这些项目也解释了 Grafana Assistant 与 Agent Observability 之间的关系。构建和运营 Assistant 给出了关于代理行为的复杂实际问题。Agent Observability 通过追踪、评估和比较帮助我们解答这些问题，并将这些能力提供给正在构建自身代理的客户。

了解更多：阅读 Sven 和 Yasir 的博文，《Judge Jev：类型决策模型能否评估你的代理？》

[重新定义工作方式以更快交付更优质产品](https://grafana.com/blog/six-improvements-that-make-grafana-assistant-better-at-helping-your-workflows/#redefining-how-we-work-so-we-can-deliver-better-products-qui)

在我关于 Grafana Labs 如何构建 AI 的文章中，我将我们的方法描述为基于客户问题的小而有意义的迭代。我们从客户问题出发并尝试解决它们。在这个过程中，有些方法奏效（这就是你可以阅读的博文！），有些方法没有奏效——这也没关系。我们希望快速推进，这意味着我们赋予每个人在任何方向快速实验的权力。

了解更多：阅读我的博文，《Grafana Labs 如何构建 AI：小步骤累积成真正有用的 AI》

在 2026 年 ObservabilityCon 本周，我们将更进一步，突出展示我们持续努力交付的 AI 能力，帮助你更高效地工作。请务必注册线下活动或观看我们的主题演讲直播。