三步让 Claude 后台 Agent 快 3-5 倍且更省钱

我们在 Kubernetes 上一个有 36 个 Go 微服务的应用里，向两个 Claude Managed Agents 注入了回归故障。两个 Agent 获得相同的页面、相同的集群、相同的 Grafana 访问权限，以及相同的源代码。其中一个还接入了 Causely 的 MCP server。两个 Agent 每次都产出了正确的修复方案。但有因果上下文的 Agent 工具调用次数减少了 3.6 倍到 7 倍，完成速度快了 3.6 倍到 5.7 倍，成本降低了 3.5 倍到 5 倍。

在我之前关于 Claude Managed Agents 的文章中，我讨论了如何让 Agent 访问生产环境，以及什么应该触发它。如果你还没有读过那些文章，这里是最相关的部分帮你跟上。Anthropic 于今年八月发布的《AI-Native SDLC Playbook》提供了跨六个阶段应用 AI 的最佳实践。这个六阶段框架对任何在企业软件领域工作的人来说都应该很熟悉。第六阶段——维护——正是后台 Agent 发挥关键作用的地方。在本文中，我们衡量了运行在这一阶段的 Agent 的有效性，以及为其提供因果上下文的影响。

测试一个关键差异

为了理解因果上下文的影响，我们基于 Anthropic 共享的框架和仓库示例搭建了两个相同的 Claude Managed Agents。两个 Agent 都可以通过 k8s MCP 查询 Kubernetes 集群中正在运行的服务。两个都接入了 Grafana MCP，包括应用指标、链路追踪和日志。两个也都有权访问 GitHub 分支上的应用源代码——回归故障就引入在那里；下文会详细说明。其中一个还接入了 Causely 以及它所提供的因果上下文，这些上下文基于流向 Grafana 的相同追踪、指标和日志。

我们对两个 Agent 进行了三个不同故障场景的测试，并用相同的起点提示它们（例如"服务 x 正在降级"）。在每个场景中，我们命名的服务距离实际引入故障的地方有两到三跳。这是为了模拟我们在大规模环境中常见的情况：值班工程师手动宣布发生事故，但在调查开始时无法确定具体是哪个服务出了问题。或者在那些告警自动触发调查的环境里——触发告警的只是多个阈值超出范围的服务之一。

故障场景及与提示中命名服务的距离

对于每个场景，我们通过审查 Agent 提出的 PR、工具调用次数、耗时和成本来衡量修复的正确性。

另一个区别是，有 Causely 访问权限的 Agent 被指示首先调用 get_issues，范围限定在应用运行的命名空间。这类似于用 Issue 触发 Agent，这也是我们之前认为远比用超出阈值的违规触发更有效的方式。

典型的回归作为故障

为了让这些场景更贴近现实，我们在应用代码或基础设施配置中引入了基于代码的回归，而不是依赖故障注入方法论。这个应用本身是一个电商应用，由 36 个 Go 微服务组成，运行在单个 Kubernetes 命名空间中，使用 Kafka、Redis 和 Postgres 做持久化。前端扇出到多个服务，负载生成器持续运行以模拟八种不同的用户流程。仓库（包括应用源代码和场景设置）可以在这里找到。

以下是三个回归故障场景：

1. Billing Service Timeout

Billing 服务的 HTTP 出站客户端经过重构以改善现有连接的使用。重构意外移除了连接请求超时。现在，当 payment-adapter 服务变慢时，来自 billing 服务的请求会挂起而不是快速失败，结账延迟开始攀升。

2. Recommendation Service Memory Limits

对 YAML 文件的无意修改将 request memory 设为 8 Mi，limits 设为 10 Mi，而该服务通常运行在约 10 到 13 Mi。Pod 开始遇到 OOMKilled 重启；多个服务（例如 search、ranking）错误率升高，search 延迟攀升因为 ranking 在等待 search。

3. Pricing Service Excessive Calls

对 pricing 服务代码的修改现在对购物车中的每个行项调用一次 discount 服务，而不是每个购物车调用一次。随着购物车规模增长，discount 和 cart 服务的延迟都会增加，试图完成交易的用户前端延迟增加。

每个回归都引入在一个包含其他无关更改的分支中，因此简单回滚最新代码更改不是一个有效的修复方案。

Searching vs. starting with a diagnosis

有了因果上下文，Agent 采取了不同的方法。它不是每次从头重新发现系统，而是从一个答案开始，专注于确认其有效性并修复底层的代码回归。这可以通过审查会话追踪看到。Claude Managed Agents 平台提供了这种可见性。你可以看到 Agent 进行的每次调用、每次调用的耗时、遇到错误的位置，以及消耗了多少输入或输出 token。

审查 Baseline Agent——没有因果上下文的那个——我们可以看到以下模式。Agent 首先通过列出命名空间中的 Pod、检查最近的 k8s 事件，以及拉取命名服务的日志来定向环境。然后深入代码库了解布局并重建服务依赖图。现在它开始对依赖链中的每个服务进行广泛的试错遥测查询，使用数十个 PromQL 查询。它本质上是猜测哪些服务和信号重要，然后追求这些猜测。与此同时，它有一个并行任务在检查 firing alerts、自动扩缩容配置和其他基础设施信号。一旦有了疑似服务，它专注于 git 日志以了解最近的提交，并形成关于需要什么精确的应用或基础设施代码更改的假设。最后，它确认当前实时指标支持这个假设，应用编辑，提交并推送。

另一方面，有因果上下文的 Agent 首先问："出了什么问题？"第一次调用几乎总是 get_issues。这返回了涉及到的实体。Agent 现在调查这个线索，用原始证据证实 Causely 的诊断。然后它专注于与标记实体相关的特定文件，而不是审查整个仓库并重建依赖图。从那里，它遵循类似的模式：审查这部分代码库的 git 历史，然后遵循与 baseline Agent 相同的收尾序列——修复、提交和推送。

两个 Agent 都正确，但一个有 5 倍的工作量

在我们测试的所有场景中，两个 Agent 都识别出了正确的根本原因并提出了有效修复的 PR。没有一个责怪初始提示中命名的服务（例如故障场景 2 中的 search）。区别在于速度和成本。没有因果上下文的 Agent 更慢，进行了更多工具调用，消耗了更多 token。

一次运行对比：baseline 与有 Causely 的 Agent

该表展示了每个场景的一次运行。Managed Agent 会话在工具调用、时间和总成本上因运行而异。差距的大小比具体数值更有信息量。5 倍的成本差异（故障场景二）或 7 倍的工具调用差异（故障场景一）不会通过额外运行收窄到 1 倍。

没有因果上下文，Agent 每次运行都重建系统图，进行更多工具调用，燃烧 token 来重建 Causely 已经以其语义暴露的内容。

Ready to try this with your agent?

我们已经将场景和评估工具在 Causely 开源仓库中提供。Agent 的设置和评估方法可以在 Claude Managed Agents 下的 background agents 仓库中找到，应用（包括代码回归故障）可以在 Regression Lab 仓库中找到。