New Relic 将变更追踪接入 GitHub Copilot

New Relic 宣布为 GitHub Copilot 推出一组集成，把持续遥测数据直接引入开发者从编码到部署的工作流。开发者无需登录仪表盘或离开 GitHub，即可查看编码智能体的使用情况，并把 AI 与人工生成的代码部署同实时应用性能关联起来。

其中，New Relic Change Tracking for GitHub Copilot 已进入公开预览；面向 GitHub MCP Server 的 Autopilot 集成和面向 GitHub Copilot 的 Preflight 已正式可用。New Relic 称，这组集成旨在让可观测性在开发决策发生时提供上下文，把更快的编码转化为可靠的软件交付。

集成内容与可用状态

Autopilot 集成建立在开放的 Model Context Protocol（MCP）标准之上，把 New Relic 的 Autopilot SRE 智能体与 GitHub MCP Server 连接起来。Autopilot 在分诊告警、定位根因和给出修复建议时，可以调用企业的代码库上下文。

Preflight 则是一项开源能力，关注编码过程本身。开发者可以在本地集成开发环境和命令行界面中查看实时的模型效率、延迟与 token 消耗，并据此优化成本、设置主动告警，以及评估不同大语言模型给出的建议准确度。

为何要追踪部署变更

New Relic 引用其 2026 年 AI 编码状况调查说明问题所在：94% 的负责人在代码评审阶段认为 AI 生成的代码质量更高，但 78% 的负责人表示部署后事故有所增加。评审环节的判断与上线后的实际表现之间存在落差。

来源指出，仅靠部署前审查代码并不能反映全貌。如果缺少对新部署代码如何影响下游服务的即时、情境化可见性，性能异常出现时，工程团队容易陷入反复排查的循环。

变更追踪的思路是把生产遥测直接接入开发者的部署工作流，以减少人工分诊、加快评审周期，让工程师把精力留在手头工作上。

变更追踪如何运作

按照来源的描述，该功能会持续对照实时性能数据执行检查，形式包括合并前的基线比对、部署后的金丝雀门禁，以及部署后的回归检测，目的是让合并进主干的代码达到可上线的状态。

一旦发现回归，集成会自动把问题转入 GitHub Issues 并交给 Copilot 处理修复，同时将更新发送到 Slack。这样，问题从被发现到进入修复流程的路径被压缩在开发者已有的工具之内。

高管表态与产品思路

New Relic 人工智能负责人 Camden Swita 表示，随着 AI 加速开发，工程师和智能体需要对软件在生产环境中的表现有共同理解。他提到，传统可观测性把关键数据锁在封闭的 SaaS 仪表盘里，而无头（headless）的 New Relic 把可信的运营智能直接带入软件构建与交付所用的工具和工作流。

Swita 称，新的 GitHub 集成把这一策略付诸实践，帮助团队理解任何一次部署的生产影响。他表示，公司的愿景是让可观测性在开发决策发生时提供信息，为工程师和 AI 智能体提供把更快编码转化为可靠交付所需的上下文。

从产品布局看，Change Tracking 覆盖部署环节，Autopilot 延伸至事件响应，Preflight 则前移到编码过程，三者共同构成从编码到部署的可见性链条。

要点

• Change Tracking for GitHub Copilot 已进入公开预览
• Autopilot 与 Preflight 两项集成已正式可用
• 开发者无需离开 GitHub 即可使用 New Relic
• New Relic 调查称 78% 受访者称部署后事故更多