写代码的 agent 终于能看懂线上崩溃了：groundcover 上线 agent-to-agent 可观测性，MCP 直通生产遥测

导语：agent 写完代码之后的事，第一次有了产品化的答案

2026 年 10 月 14 日，可观测性厂商 groundcover 通过 Business Wire 发布了一项多终端上线公告：它的可观测智能从此延伸到三个地方——自家的 Agent Mode、外部 AI 编程 agent（通过 MCP 协议直连）、以及 Slack。这次发布的标题很直接：《groundcover Launches Agent-to-Agent Observability Across Agent Mode, IDEs and Slack》（groundcover 跨 Agent Mode、IDE 与 Slack 上线 agent-to-agent 可观测性）。

为什么这条新闻值得讲？先说一个所有 vibe coder 都体验过的断层：AI 编程 agent 今天已经能读代码库、审 PR、推理"软件应该是什么样子"，但一旦代码上了生产、半夜报错了，agent 就失明了——它不知道线上到底发生了什么。排查线上崩溃依然是人的活儿：登录 Grafana、翻日志、拼 trace、查 Kubernetes 事件，把这些碎片证据摆在面前，agent 才能继续帮忙。而这一步"把生产证据喂给 agent"，在此之前并没有被做成产品。

groundcover 这次做的就是把断层填上。它本身是一家成立于 2021 年的全栈可观测性公司，投资方包括 One Peak、Morgan Stanley Expansion Capital、Zeev Ventures 等，主打 BYOC（bring-your-own-cloud，遥测数据留在客户自己的云里）+ eBPF 无侵入采集。这次发布的核心就是一句话：让外部的 coding agent——Claude、Cursor、Kiro、Codex——要么直接查 groundcover 的生产遥测，要么把调查任务转交给 groundcover 自家的可观测性 agent。CEO Shahar Azulay 在新闻稿里说得更直白：coding agent 能告诉你"代码应该发生什么"，但没有生产证据，它们说不清"线上已经发生了什么"——这次发布的目标，是让 agent 不必成为可观测性专家，也能拿到那份证据。

三个终端：Agent Mode、IDE 外部 agent、Slack

这次发布覆盖三个入口，分别对应工程师已经在干活的三个地方：

1. Agent Mode：自家的原生调查环境

Agent Mode 是 groundcover 自己的环境，用来调查生产问题、生成仪表盘和 monitor、实时引导调查过程。简单说，它是为"查线上"这件事专门做的 agent 工作台。这次发布把它明确列为三个终端之一，说明 groundcover 不是只做一个给外部 agent 用的数据接口，而是在自家地盘里也保留了一个完整的人机协作调查界面。

2. IDE 与外部 agent：经 MCP 直通生产上下文

这是新闻里最实在的部分。Kiro、Cursor、Claude、Codex 这四类外部 AI 编程 agent，现在可以通过 groundcover 的 MCP 工具直接查询它的生产遥测，包括日志、trace、指标、Kubernetes 事件、live entities、monitors 及相关元数据。注意这个名单：Claude（Anthropic）、Cursor（独立 IDE）、Kiro（AWS 出品的 agent IDE）、Codex（OpenAI）——覆盖了主流 coding agent 的全部流派。MCP 在这里扮演的角色很经典：它是 agent 与外部数据之间的标准插头，而 groundcover 把自己做成了一个"生产遥测的 MCP 服务器"。

3. Slack：把 agent 塞进故障讨论线程

@groundcover 可以被邀请加入一次故障讨论线程，以对话内容为上下文，同时拉通 Linear、GitHub 等已经接好的工程系统。这个场景设计得很懂工程团队的真实习惯：故障发生时，大家不是在某个调查界面里集合，而是在 Slack 线程里一边贴日志一边吵。agent 直接进入这个线程、用对话当上下文，省掉了"把上下文复制粘贴给 agent"那一步。

三个终端背后是同一套底座：BYOC 架构让遥测留在客户自己的云里；单个 eBPF sensor 采集应用与基础设施行为，不需要团队给每个服务逐一加插桩；按节点计费，并且高保真数据留存不额外收费。新闻稿里特意把计费这条摆出来，逻辑是：agent 做准确调查需要高保真证据，而传统的按数据量计费会让团队舍不得保留数据——按节点计费等于把"保留证据"这个动作变便宜了。

两种协作模式：自己查 vs 转交出去

新闻稿里最值得细看的是它给外部 agent 设计的两种工作方式，因为这实际上是两种不同的"agent 协作协议"：

• 直接访问（Direct access）。当 agent 已经知道自己需要什么证据时，直接调用 groundcover 的 MCP 工具去查：日志、trace、指标、Kubernetes 事件、live entities、monitors 及相关元数据。这是"我知道要找什么，你把数据给我"的模式，agent 自己负责拼证据、下结论。
• 委派调查（Delegated investigation）。当 agent 只知道有问题、但不知道从哪下手时，它可以把任务转交给 groundcover Agent——通过异步的 Agent Tasks。groundcover 返回一个 job ID，调查在后台继续，而调用方的 agent 不被阻塞，继续干自己的活。最后回传的是完整的调查成果，比如一份根因分析报告或者一个仪表盘草稿。

图 1：两种协作模式对照。左：MCP 直查——agent 知道要找什么，直接调工具取证据；右：委派调查——agent 只知道有问题，把开放式调查转交给 groundcover 的可观测性 agent，拿 job ID 后继续干活，最后收成果。来源：groundcover 2026-10-14 新闻稿。

注意委派模式的几个设计细节：第一，它是异步的，job ID 机制意味着调用方 agent 不需要挂起等待——这对 agent 的 token 消耗和工作流连续性都很关键；第二，它处理的是"开放式"任务，新闻稿点名的三个例子是根因分析、仪表盘生成、monitor 生成，都是需要多轮推理和领域知识、而不是一次查询能解决的事；第三，回传的是"成果"而不是原始数据，agent 拿到的是已经消化过的结论。

数据流转：从 eBPF 到修复建议

把整条链路画出来，数据的旅程是这样的：单个 eBPF sensor 在客户云里无侵入地采集应用与基础设施行为 → 沉淀为六类生产证据（日志、指标、trace、Kubernetes 事件、live entities、monitors 及相关元数据），且因为 BYOC 架构，这些数据不出客户云 → 上层的 agent 层提供两种访问方式（MCP 工具直调、Agent Tasks 异步委派） → 最终触达三个终端（Agent Mode、IDE 里的外部 agent、Slack 线程），产出根因分析、仪表盘草稿和修复线索。

图 2：遥测 → agent → 修复的数据流转。关键点：BYOC 让数据不出客户云；按节点计费让高保真留存不贵；agent 层同时支持 MCP 直调与异步委派两种接入。来源：groundcover 2026-10-14 新闻稿。

这张图里最有信息量的是左半部分。传统可观测性方案里，"agent 能查线上"往往意味着要把生产数据导到第三方平台；而 groundcover 的 BYOC 架构让数据留在客户自己的云，agent 的查询是"到数据所在的地方去问"。对安全敏感的团队，这是能不能用的分水岭——2026 年可观测性的新闻里，这是少见的把"数据主权"写进 agent 功能发布里的例子。

判断一：agent 工作流的"运维闭环"开始被产品化了

过去一年，coding agent 的能力边界一直在"写代码"这个环节里卷：更好的补全、更强的重构、更长上下文的 PR 评审。但软件的生命周期里，写代码只占一半，另一半是运维——线上出问题、定位、修复、验证。agent 在前半段已经很强，在后半段几乎缺席，原因不是模型不够聪明，而是它没有生产数据的访问权。

groundcover 这次发布是第一次有厂商把"运维闭环"做成完整产品：不是一个 demo 集成，而是覆盖 agent Mode、IDE、Slack 三个真实工作场景，支持直查和委派两种模式，底座还有 BYOC 和计费的配合。这个完整度说明，它不是在蹭 MCP 的热点，而是在回答一个具体的问题：当 agent 写出的代码上线崩了，工作流应该是什么样子？

为什么我说"闭环"这个词成立？因为委派调查模式的终点是"根因分析 / 仪表盘草稿"——agent 拿到这些成果之后，下一步自然就是改代码、提 PR，而这正是 coding agent 最擅长的事。于是链路就闭上了：写代码 → 上线 → 崩 → agent 自己查证据 → agent 自己修 → 再上线。以前这条链路在"崩"之后就断了，需要人把证据搬运过去；现在搬运这一步也被产品化了。对 vibe coder 来说，这意味着"一人 + agent"的工作流第一次有了覆盖生产运维的完整形态：你不再需要一个运维团队来替 agent 擦屁股。

这个判断的另一面是：它也抬高了对 agent 本身的要求。直查模式假设 agent"知道自己需要什么证据"——这要求 agent 具备一定的可观测性常识，比如知道该用 trace 而不是日志来定位延迟问题。新闻稿里 CEO 说"agent 不必成为可观测性专家"，但这话只对了一半：委派模式下确实不必，直查模式下它至少得知道问什么问题。这也是为什么 groundcover 同时保留两种模式——它把"专家型"和"甩手型"两种 agent 都照顾到了。

判断二：agent-to-agent 委派是 multi-agent 协作的新范式

委派调查模式最值得琢磨的不是"查线上"这个功能，而是它的协作形态：一个 agent 把任务异步转交给另一个专门的 agent，拿 job ID 继续干活，最后收成果。这是一种 agent-to-agent 的分工协议。

过去的 multi-agent 方案大多是"同一个大脑指挥多个手"：一个主 agent 拆任务、子 agent 执行、结果汇总回来。但 groundcover 的模式是跨厂商、跨系统的：调用方可以是 Claude、Cursor、Kiro、Codex 中的任何一个，被调用方是 groundcover 的可观测性 agent，两者之间通过标准化的 Agent Tasks + job ID 异步通信。这更像微服务之间的调用关系，而不是一个大脑的左右手。

这个范式的意义在于可组合性。如果每个垂直领域都有一个像 groundcover Agent 这样的"专家 agent"——安全扫描有安全 agent、性能分析有性能 agent——那么 coding agent 就可以变成一个调度者：自己写代码，遇到不懂的领域就委派出去。这比"训练一个全能 agent"现实得多，也比"人肉在多个 agent 之间复制粘贴"优雅得多。groundcover 这次是把可观测性这个垂直领域先占了下来，新闻稿标题里的 "agent-to-agent observability" 就是在给这个范式命名。

当然，范式成立的前提是标准化。job ID + 异步回传只是 groundcover 自家的实现，如果每个厂商都搞一套私有的委派协议，组合性就无从谈起。MCP 解决的是"数据访问"的标准化，委派协议的标准化还没有影子。这是这个范式接下来要回答的问题：A2A（agent-to-agent）通信到底该长什么样？groundcover 这次发布可以看作是为这个问题交出的第一份产品答卷。

和站内内容的互链：infra 军备赛的又一块拼图

如果你一直在跟 VibeFix 的资讯，会发现这条新闻不是孤立的。站内之前发过 Anthropic 的 Scion——那是模型厂商在"agent 基础设施"上的布局；也发过 Moyai 等 infra 方向的项目。这次 groundcover 的发布是同一条战线的另一段：Scion 回答的是"agent 运行在哪、怎么调度"，groundcover 回答的是"agent 怎么看懂生产"。

另外，站内的指南频道里有两篇可观测性相关的指南（agent-observability-practice、vibe-project-observability-guide），讲的都是"怎么给你的 vibe 项目加上可观测性"的通用方法。这篇资讯和它们是互补关系：指南教你"为什么和怎么做"，这篇新闻告诉你"现在有厂商把这件事做成了 agent 原生的产品"。如果你正在用那两篇指南给自己的项目加监控，groundcover 的发布就是下一步的参考答案——监控数据的消费者不再只是人，还可以是 agent。

三个还没被回答的问题

新闻稿把故事讲得很完整，但有几个关键问题它没有回答，值得在用之前想清楚：

第一，查询的权限边界在哪？agent 能查生产日志和 trace 是好事，但生产日志里经常有用户数据、密钥、PII。新闻稿没有提 agent 查询时的权限模型：是继承调用者的权限？还是有一个独立的 agent 身份？在 Slack 线程里 @groundcover 回答问题时，它会不会把不该看的人能看到的数据贴出来？BYOC 解决了"数据不出云"，但没有解决"数据在云里给谁看"。这是企业落地的第一个门槛。

第二，委派调查的质量和成本怎么衡量？异步委派听起来很美好，但根因分析这种开放式任务，agent 的幻觉风险比写代码更高——它可能自信地给出一个错误的根因。新闻稿没有提准确率、没有提幻觉的兜底机制，也没有提委派一次调查的成本（token 消耗、耗时 SLA）。在生产故障这种分秒必争的场景里，一个"后台慢慢挖"的调查如果挖错了方向，代价是故障时间被拉长。

第三，MCP 直查会不会变成新的 token 黑洞？生产遥测的数据量是巨大的，一次"查一下报错日志"如果返回了几十万行日志，agent 的上下文窗口和账单都会爆炸。新闻稿说高保真留存不额外收费，指的是 groundcover 的存储计费，不是 agent 的 token 计费。真正决定这个功能好不好用的，是 MCP 工具返回结果的"证据密度"——groundcover 有没有做查询结果的摘要、采样、相关性排序。这一点新闻稿里没有展开，但它是直查模式的生死线。

收尾：从"写代码的 agent"到"管系统的 agent"

这次发布的完整信息已经上线，感兴趣可以去看 groundcover 的官方新闻稿（Business Wire，2026-10-14）或者它的 agent-mode 产品页。发布是即时可用的（available now），不是期货。

最后说回 vibe coder 的视角。过去我们谈论 AI 编程，谈的都是"写"的部分：提示词怎么写、agent 选哪个、代码质量怎么保证。但软件真正难的部分从来不是写出来，而是养大——上线、运维、修 bug、看监控。groundcover 这次发布第一次让"养"的部分也有了 agent 的位置：写代码的 agent 和看生产的 agent 开始能协作了。

这条路还很长：权限、幻觉、token 成本，三个问题一个都没解决。但方向是对的——agent 的工作流正在从"写完就走"变成"负责到底"。下一次你的 agent 半夜把你叫醒，说的可能不再是"我写完了"，而是"线上崩了，我已经查到根因，修复 PR 在这儿"。那一天，才是 vibe coding 真正成熟的标志。