Awesome Copilot Partners 插件：GitHub 合作伙伴定制 Agent 全景指南

本篇技术指南聚焦 Awesome Copilot 仓库中由 GitHub 合作伙伴（Partners） 贡献的定制 Agent 集合插件（plugins/partners/README.md），系统梳理其安装方式、Agent 清单与各自核心能力，并结合仓库内真实 Agent 定义文件与插件元数据，深入剖析 Amplitude 实验、Dynatrace 可观测性、Terraform 基础设施、JFrog 安全、LaunchDarkly 特性开关、MongoDB 性能分析等代表性 Agent 的实现原理与使用方式。读完本文，你将掌握如何一键安装该插件、理解每个合作伙伴 Agent 的应用场景与底层 MCP 集成机制，并能在自己的仓库中直接启用这些开箱即用的能力。

插件概览：什么是 Partners 插件

Partners 插件是 Awesome Copilot 社区仓库中一个专门收录 GitHub 官方合作伙伴（GitHub partners）所创建的自定义 Agent 的插件。其官方定义非常简洁：

Custom agents that have been created by GitHub partners

插件元数据定义在 plugins/partners/plugin.json 中，从中可以读出关键信息：

• 插件名称：partners
• 版本：1.0.0
• 作者：Awesome Copilot Community
• 许可证：MIT
• 关键词：devops、security、database、cloud、infrastructure、observability、feature-flags、cicd、migration、performance
• 扩展声明：通过 com.github.awesome-copilot 扩展点挂载 20 个 Agent 定义

从关键词分布可以看出，该插件覆盖了 DevOps、安全、数据库、云基础设施、可观测性、特性开关、CI/CD、迁移与性能优化等主流工程领域，是仓库中覆盖面最广、厂商生态最丰富的 Agent 插件之一。

安装方式

与其他 Awesome Copilot 插件一致，Partners 插件通过 GitHub Copilot CLI 安装：

# Using Copilot CLI
copilot plugin install partners@awesome-copilot

安装后，Copilot 会读取插件清单并注册其中声明的全部 Agent。底层机制可以参见 eng/materialize-plugins.mjs 与 eng/validate-plugins.mjs 等工程脚本——仓库通过插件物化与校验流程，确保 plugin.json 中声明的 agents 条目与实际的 Agent 定义文件一一对应。

Agent 清单与场景速览

原文档以表格形式给出了每个合作伙伴 Agent 的名称与简介。下表完整保留该清单，并结合仓库内各 Agent 定义文件补充其底层技术要点：

Agent	核心能力概述	仓库内对应定义文件
amplitude-experiment-implementation	使用 Amplitude 的 MCP 工具在 Amplitude 内部署新实验，实现变体测试能力与产品功能的灰度发布	agents/amplitude-experiment-implementation.agent.md
apify-integration-expert	将 Apify Actors 集成进代码库的专家，覆盖 Actor 选择、工作流设计、JavaScript/TypeScript 与 Python 实现、测试与生产级部署	agents/apify-integration-expert.agent.md
arm-migration	Arm 云迁移助手，扫描仓库中的架构假设、可移植性问题、容器基础镜像与依赖不兼容，推荐 Arm 优化改动，驱动多架构容器构建并验证性能	agents/arm-migration.agent.md
diffblue-cover	使用 Diffblue Cover 为 Java 应用编写单元测试的专家	agents/diffblue-cover.agent.md
droid	提供 Droid CLI 的安装指引、使用示例与自动化模式，重点覆盖 droid exec 在 CI/CD 与非交互自动化中的应用	agents/droid.agent.md
dynatrace-expert	将 Dynatrace 可观测性与安全能力集成进 GitHub 工作流，自主分析 traces、logs 与 Dynatrace findings，用于事件调查、部署验证、错误分类、性能回归检测、发布验证与漏洞管理	agents/dynatrace-expert.agent.md
elasticsearch-observability	基于实时 Elastic 数据调试代码（O11y）、优化向量检索（RAG）并修复安全威胁的 AI 助手	agents/elasticsearch-observability.agent.md
jfrog-sec	自动化安全修复的应用安全 Agent，使用 JFrog 安全情报校验包与版本合规性、建议漏洞修复方案	agents/jfrog-sec.agent.md
launchdarkly-flag-cleanup	使用 LaunchDarkly MCP 服务器安全自动化特性开关清理工作流：判定移除就绪性、识别正确的 forward value、创建保持生产行为的 PR	agents/launchdarkly-flag-cleanup.agent.md
lingodotdev-i18n	以系统化、清单驱动的方式在 Web 应用中实施国际化（i18n）的专家	agents/lingodotdev-i18n.agent.md
monday-bug-fixer	从 Monday.com 平台数据中丰富任务上下文（相关条目、文档、评论、epics、需求），产出生产级修复与完整 PR	agents/monday-bug-fixer.agent.md
mongodb-performance-advisor	分析 MongoDB 数据库性能，提供查询与索引优化洞察与可执行建议	agents/mongodb-performance-advisor.agent.md
neo4j-docker-client-generator	从 GitHub issue 生成高质量 Python Neo4j 客户端库的 AI Agent	agents/neo4j-docker-client-generator.agent.md
neon-migration-specialist	使用 Neon 分支工作流实现零停机 Postgres 迁移：在隔离数据库分支中测试 schema 变更、充分验证后应用到生产，支持 Prisma、Drizzle 等 ORM	agents/neon-migration-specialist.agent.md
neon-optimization-analyzer	使用 Neon 分支工作流自动识别并修复慢 Postgres 查询：分析执行计划、在隔离分支测试优化、给出前后性能指标与代码修复	agents/neon-optimization-analyzer.agent.md
octopus-deploy-release-notes-mcp	为 Octopus Deploy 中的发布生成 release notes，通过 MCP 服务器访问 Octopus Deploy API	agents/octopus-deploy-release-notes-mcp.agent.md
stackhawk-security-onboarding	自动为仓库配置 StackHawk 安全测试：生成配置与 GitHub Actions 工作流	agents/stackhawk-security-onboarding.agent.md
terraform	Terraform 基础设施专家，具备自动化 HCP Terraform 工作流，通过 Terraform MCP 服务器实现 registry 集成、workspace 管理与 run 编排	agents/terraform.agent.md
pagerduty-incident-responder	通过分析事件上下文、识别近期代码变更并经由 GitHub PR 建议修复，响应 PagerDuty 事件	agents/pagerduty-incident-responder.agent.md
comet-opik	统一的 Comet Opik Agent：基于最新 Opik MCP 服务器完成 LLM 应用插桩、prompt/project 管理、prompt 审计与 traces/metrics 调查	agents/comet-opik.agent.md

结合 plugins/partners/plugin.json 中的 extensions.com.github.awesome-copilot.agents 数组，可以确认上述 20 个 Agent 均被插件正式挂载注册，安装后即可在 Copilot 中直接按名称调用。

代表 Agent 深度解析

下面选取几个覆盖不同领域、且仓库内定义文件信息量充足的 Agent，展开源码级分析，帮助读者理解合作伙伴 Agent 的设计范式。

Amplitude 实验实现 Agent：功能实验化落地

agents/amplitude-experiment-implementation.agent.md 定义了一个围绕 Amplitude MCP 工具构建的实验实施 Agent，其工作流程分五步：

1. 收集需求并制定计划：从 GitHub issue 中提取功能需求、埋点（instrumentation）需求与实验需求；若无 issue 编号则询问用户并暂停；随后分析现有代码库中 Amplitude Experiment 的使用范式，制定"实现功能 → 创建实验 → 用变体包裹功能"的计划。
2. 按计划实现功能：遵循仓库最佳实践与既有范式。
3. 使用 Amplitude MCP 创建实验：遵循工具说明与 schema，调用 create_experiment 工具，并根据 issue 需求确定创建时的配置项。
4. 用新实验包裹新功能：复用应用内既有的 Amplitude Experiment 特性开关/实验范式，确保 treatment 变体展示的是新功能版本而非 control。
5. 输出总结：汇总实现内容，并给出所创建实验的 URL。

该 Agent 的典型价值在于把"需求 issue → 埋点设计 → 实验创建 → 代码包裹 → 交付汇报"这一产品工程链路交给 Agent 自动闭环，特别适合对流量实验有强需求的增长与产品团队。

Dynatrace 专家 Agent：六类可观测性与安全用例

agents/dynatrace-expert.agent.md 是一个 854 行的大体量 Agent，其 frontmatter 声明了 MCP 服务器配置：

mcp-servers:
  dynatrace:
    type: 'http'
    url: 'https://pia1134d.dev.apps.dynatracelabs.com/platform-reserved/mcp-gateway/v0.1/servers/dynatrace-mcp/mcp'
    headers: {"Authorization": "Bearer $COPILOT_MCP_DT_API_TOKEN"}
    tools: ["*"]

该 Agent 通过 HTTP 类型的 MCP 网关接入 Dynatrace，并以环境变量 COPILOT_MCP_DT_API_TOKEN 注入鉴权令牌。其能力被划分为 6 大用例：

• 可观测性 5 例：事件响应与根因分析（RCA）、部署影响分析、生产错误分类、性能回归检测、发布验证与健康检查；
• 安全 1 例：安全漏洞响应与合规监控。

Agent 内置了上下文感知路由：用户问题涉及 Problems/Failures/Errors 时路由到事件响应工作流，涉及 Deployment/Release 时路由到部署影响或发布验证工作流，涉及 Security/Vulnerabilities/CVE 时路由到安全漏洞工作流，依此类推。

其核心操作原则包括：

• 异常分析为强制项：必须展开 span.events 分析服务失败；
• 仅使用最新扫描数据：安全 findings 必须来自 latest scan；
• 业务影响优先：评估受影响用户、错误率与可用性；
• 多源交叉验证：跨 logs、spans、metrics、events 交叉引用；
• 服务命名一致：统一使用 entityName(dt.entity.service)。

文档中给出了可直接复用的 DQL（Dynatrace Query Language）查询模板，例如强制异常发现的模式：

// MANDATORY Exception Discovery
fetch spans, from:now() - 4h
|| filter request.is_failed == true and isNotNull(span.events)
|| expand span.events
|| filter span.events[span_event.name] == "exception"
|| summarize exception_count = count(), by: {
    service_name = entityName(dt.entity.service),
    exception_message = span.events[exception.message]
}

这类查询模板使 Agent 能够在仓库环境中直接对 Dynatrace 数据发起调查，最终将 RCA 结论与文件位置写回仓库，实现"数据调查—定位代码—精准修复"的闭环。

Terraform Agent：HCP Terraform 自动化编排

agents/terraform.agent.md 声明了本地 Docker 型 MCP 服务器：

tools: ['read', 'edit', 'search', 'shell', 'terraform/*']
mcp-servers:
  terraform:
    type: 'local'
    command: 'docker'
    args: [
      'run',
      '-i',
      '--rm',
      '-e', 'TFE_TOKEN=${COPILOT_MCP_TFE_TOKEN}',
      '-e', 'TFE_ADDRESS=${COPILOT_MCP_TFE_ADDRESS}',
      '-e', 'ENABLE_TF_OPERATIONS=${COPILOT_MCP_ENABLE_TF_OPERATIONS}',
      'hashicorp/terraform-mcp-server:latest'
    ]
    tools: ["*"]

它通过 hashicorp/terraform-mcp-server:latest 容器接入 HCP Terraform，三个环境变量分别提供组织令牌、服务地址与是否启用 Terraform 操作开关。其工作流核心能力包括：

1. Registry Intelligence：查询公有/私有 Terraform registry，获取最新版本、兼容性与最佳实践；
2. 代码生成：使用经批准的模块与 provider 生成合规 Terraform 配置；
3. 模块测试：使用 Terraform Test 为模块编写测试用例；
4. 工作流自动化：程序化管理 HCP Terraform workspaces、runs 与变量；
5. 安全与合规：确保配置遵循安全最佳实践与组织策略。

生成代码前有一系列强制规则：版本解析优先调用 get_latest_provider_version / get_latest_module_version 确认最新版本并在注释中记录；Registry 搜索顺序为私有 registry（如有 token）优先，公有 registry 兜底，再通过 get_provider_capabilities 理解 provider 能力；后端配置要求根模块始终包含 HCP Terraform cloud 后端：

terraform {
  cloud {
    organization = "<HCP_TERRAFORM_ORG>"  # Replace with your organization name
    workspaces {
      name = "<GITHUB_REPO_NAME>"  # Replace with actual repo name
    }
  }
}

此外每个模块必须包含规定的最小文件结构（即使为空），确保输出的 IaC 开箱即用、可审计、可合规校验。

JFrog 安全 Agent：策略合规优先的漏洞修复

agents/jfrog-sec.agent.md 定义了一个 DevSecOps 安全专家 Agent，其约束非常鲜明：必须只使用 JFrog MCP 工具进行安全分析、策略检查与修复建议，禁止使用外部源、包管理器命令（如 npm audit）或其他安全扫描器（如 CodeQL、Copilot code review、GitHub Advisory Database）。

其强制工作流分三步：

1. 校验策略（Validate Policy）：任何变更前，使用 JFrog MCP 工具（如 jfrog/curation-check）判定依赖升级版本是否满足组织的 Curation Policy；
2. 应用修复（Apply Fix）：依赖升级采用策略合规版本；随后使用 jfrog/remediation-guide 获取 CVE 针对性指引，修改应用源码增强对漏洞的韧性（如增加输入校验）；
3. 最终总结（Final Summary）：输出必须详述使用 JFrog MCP 工具执行的具体安全检查，明确 Curation Policy 检查结果与已采取的修复步骤。

该 Agent 的价值在于把"安全修复"从盲目升版本升级为"策略合规 + 源码韧性 + 结果可审计"的工程化流程，特别适合有严格供应链策略治理诉求的企业。

LaunchDarkly 特性开关清理 Agent：安全删除死开关

agents/launchdarkly-flag-cleanup.agent.md 通过本地 npx 启动 LaunchDarkly MCP 服务器：

mcp-servers:
  launchdarkly:
    type: 'local'
    tools: ['*']
    "command": "npx"
    "args": [
      "-y",
      "--package",
      "@launchdarkly/mcp-server",
      "--",
      "mcp",
      "start",
      "--api-key",
      "$LD_ACCESS_TOKEN"
    ]

Agent 的四大核心原则为：安全第一（始终保留当前生产行为）、以 LaunchDarkly 为唯一事实源（用 MCP 工具判定状态而非仅看代码）、清晰沟通（在 PR 描述中解释安全评估推理）、遵循团队约定。

其旗标移除流程极具实操参考价值：

• Step 1：用 get-environments 获取项目所有环境，识别哪些是 critical（通常为 production、staging 或用户指定）；
• Step 2：用 get-feature-flag 拉取全环境的旗标配置，提取 variations、各 critical 环境的 on、fallthrough.variation、offVariation、rules、targets、archived、deprecated 等字段；
• Step 3：判定 forward value——若所有 critical 环境 ON/OFF 状态一致且无规则/定向，则取一致的 fallthrough.variation 或 offVariation；若 critical 环境间状态不一致，则判定 NOT SAFE TO REMOVE；
• Step 4：创建 PR，用 forward value 替换旗标调用并更新陈旧默认值，全程保持生产行为不变。

MongoDB 性能顾问 Agent：只读分析驱动的优化闭环

agents/mongodb-performance-advisor.agent.md 强调 readonly 模式：Agent 只允许使用 MCP 工具分析，绝不修改数据库。其分析流程为：

1. 代码库数据库分析：搜索 MongoDB 相关操作，用 list-databases、db-stats、mongodb-logs 收集上下文，其中 mongodb-logs 的 type: "global" 用于发现慢查询与警告，type: "startupWarnings" 用于识别配置问题；
2. 性能分析：优先运行 atlas-get-performance-advisor 获取索引与查询建议（需要 Atlas M10 及以上集群凭据），失败则跳过；用 collection-schema 识别高基数（high-cardinality）字段，用 collection-indexes 识别未使用、冗余或低效索引；
3. 查询与聚合审查：对每个查询/管道用 explain 获取基线指标，修改后重跑 explain 对比，记录执行时间与 docs examined 的改善，提及副作用与 trade-offs，并用 count/find 验证查询结果不变；
4. 交付报告：输出 findings 摘要、每条查询的原始 vs 优化版本与指标对比、索引与查询设计建议、持续监控的下一步计划。

Agent 还内置了重要约束：不编造索引创建的统计收益（因为 readonly 无法实测）、索引建议保持保守并始终说明 trade-offs、所有建议必须基于真实数据而非理论。

Arm 迁移 Agent：x86 → Arm 架构迁移助手

agents/arm-migration.agent.md 通过 Docker 运行 armlimited/arm-mcp:latest 提供 MCP 工具（skopeo、check_image、knowledge_base_search、migrate_ease_scan、mcp、sysreport_instructions），将当前工作目录映射到容器的 /workspace。

其迁移步骤非常工程化：

• 检查所有 Dockerfile，用 check_image/skopeo 验证镜像 Arm 兼容性，必要时更换基础镜像；
• 逐项检查 Dockerfile 安装的包与 requirements.txt 中的每行依赖的 Arm 兼容性，不兼容则替换为兼容版本；
• 对代码库运行 migrate_ease_scan（按代码语言选择对应扫描器）并应用建议变更；
• 可选：在 Arm runner 上重新构建项目修复编译错误；运行基准/集成测试并报告耗时改善。

文档还特意标注了两个经典陷阱：不要混淆软件版本与语言 wrapper 包版本（如检查 Python Redis 客户端应查包名 redis 而非 Redis 自身版本）；NEON lane 索引必须是编译期常量而非变量——这些都是真实迁移项目中的高频踩坑点。

插件元数据与仓库校验机制

plugins/partners/plugin.json 遵循 https://agent-plugins.org/schemas/1.0.0/plugin.schema.json schema，其扩展点声明方式与仓库中其他插件（如 plugins/aws-cloud-development/plugin.json 等）保持一致。仓库的工程层通过 eng/validate-plugins.mjs 及对应测试 eng/validate-plugins.test.mjs、eng/materialize-plugins.mjs 与 eng/materialize-plugins.test.mjs 对插件声明进行校验与物化，确保：

• 插件 schema 合法、名称唯一；
• 声明的 agents 条目能解析到实际存在的 Agent 定义文件；
• 物料化后的插件内容与源文件保持一致。

这也解释了为什么合作伙伴 Agent 的定义文件（*.agent.md）位于仓库根目录的 agents/ 目录，而插件目录 plugins/partners 中仅保留 README.md 与 plugin.json——物化流程会将声明解析并生成可供 Copilot 直接消费的最终形态。

适用场景与上手建议

Partners 插件适合以下典型场景：

• 厂商工具链深度集成：团队已使用 Dynatrace、Elastic、JFrog、LaunchDarkly、Neon、MongoDB Atlas 等平台时，可直接获得对应平台的专家级 Agent，无需自研集成逻辑；
• 安全与合规自动化：jfrog-sec 的策略合规修复、stackhawk-security-onboarding 的自动化安全测试配置，可显著降低 DevSecOps 落地成本；
• 数据库与基础设施运维：mongodb-performance-advisor、neon-migration-specialist、neon-optimization-analyzer、terraform 覆盖了从查询优化到 IaC 编排的完整链路；
• 可观测性与事件响应：dynatrace-expert、pagerduty-incident-responder、elasticsearch-observability 将监控告警与仓库内代码修复打通。

上手路径非常简单：安装插件后按名称调用对应 Agent 即可。多数 Agent 依赖 MCP 服务器与对应平台凭据（如 COPILOT_MCP_DT_API_TOKEN、LD_ACCESS_TOKEN、TFE_TOKEN、COPILOT_MCP_TFE_ADDRESS、COPILOT_MCP_ENABLE_TF_OPERATIONS 等环境变量），首次使用前请按各 Agent 定义文件中的 frontmatter 配置好对应环境变量与 MCP 服务器，即可获得完整的自动化能力。

许可证与归属

Partners 插件采用 MIT 许可证发布，属于 Awesome Copilot 社区驱动的 GitHub Copilot 扩展集合的一部分。所有 Agent 的版权归各自贡献的 GitHub 合作伙伴所有，社区负责聚合、校验与维护。