技能介绍

解决什么问题

当你把 CI/CD 和云资源管理搬到 Harness 上之后，一次典型的发布往往要在平台里来回点十几个页面：找到项目的 pipeline、触发一次 run、确认 service 的当前配置、核对某个 feature flag 的开关状态，再翻到 cost 页签看一眼这次部署花了多少钱。这些动作本身不复杂，但它们把人拴在 Harness UI 上，也让自动化流程在最关键的一环断了——脚本可以构建镜像，却拿不到 pipeline 的执行状态；CI 任务可以跑完测试，却无法顺手创建一条新的 environment。更麻烦的是权限：如果把整个组织的 Harness 账号密钥交给一个 agent，它的操作范围远超过它真正需要的。这个技能要解决的就是这件事：让 agent 在 MCP 工作流里对 Harness 的管道、服务、环境、feature flag 和成本数据做有边界的操作，而不是替代人做全套运维。

它如何工作

技能的核心是一个 Harness MCP Server。agent 通过 MCP 协议发起请求，由 server 把指令翻译成对 Harness 平台资源的调用。技能把资源面收得很窄，只覆盖 pipelines、services、environments、feature flags、cost data 以及相关的平台资源，不做平台内无关领域的透传。

工作方式上有几层限制值得写清楚：

传输层按环境切换：本地客户端走 stdio，远程或共享部署走 HTTP，容器化场景可以直接放进 Docker 或 Kubernetes。
认证方式取决于部署形态：本地自托管需要用户自己创建 Harness API key（在 My Profile → API Keys 里生成）；托管版则使用 Harness Platform OAuth，而不是 HARNESS_API_KEY，这意味着它天然挂在平台的授权体系下。
托管端点不是开了就能用：需要 Harness Support 按账号逐个启用和配置，之后这个 endpoint 才能被调用。

适用边界

先说它不做什么。它不负责 Harness 之外的云资源编排，也不会代替你设计 pipeline 的 YAML 结构；它定位在"让 agent 能读写 Harness 里已有的那几类资源"，前提是你的账号已经完成了前置配置。

另外要留意托管版和自托管版的差异：如果你打算在本地客户端里跑，需要自己管好 API key 的存放；如果你打算在团队共享的部署里用，要先确认 Harness Support 已经为这个账号打开了 OAuth 通路。在这两件事没落实之前，agent 拿到的只是协议层面的成功响应，而不是真正执行的操作。