用 AgentCore 串起云效到 ECS 的发布流程

AgentCore 通过云效 MCP 调用 Codeup、Flow 和 Packages，将 Go 服务部署到测试 ECS。发布流程包括测试、构建、制品上传、主机部署和接口检查。

准备 Go 服务和测试 ECS

示例使用 Linux AMD64 ECS，应用监听 18081，提供 /healthz 与 /hello。Codeup 仓库中准备 go.mod、main.go、main_test.go 和 deploy.sh。已有业务服务可以替换这个示例，但端口、构建路径与探活接口要同时调整。

接入所需资源：

服务连接存在，并不代表具备制品仓库的上传权限。第一次接入时，要用一次真实上传验证；遇到 has no permission to UPLOAD，先检查仓库授权。

Agent 也只能调用已经接入的工具。当前 MCP 没有提供仓库创建能力时，应先在控制台创建，或补充受限的创建工具，不能把“准备创建”写成“已经完成”。

在 AgentCore 绑定模型、凭据和 MCP

云效中心站的 MCP 地址是 https://openapi-rdc.aliyuncs.com/ai/mcp；Region 站使用组织专属域名下的 /ai/mcp。

在 AgentCore 目标 Workspace 中，依次准备模型连接、托管凭据和 MCP。进入 Agent 配置，把当前可用的模型与云效 MCP 绑定到同一个 Agent。

只加载发布需要的工具集，例如：

code-management,organization-management,pipeline-management,packages-management

在 MCP 配置中选择 Streamable HTTP，填写实际组织的服务地址，并使用托管凭据绑定认证 Header。逻辑配置如下，凭据占位符由平台配置替换，不能直接把名称当作令牌发送：

{
  "url": "https://your-org.devops.aliyuncs.com/ai/mcp?toolsets=code-management,organization-management,pipeline-management,packages-management",
  "headers": {
    "Authorization": "Bearer <运行时注入的云效PAT>"
  }
}

认证优先使用请求头。PAT 保存在 AgentCore 托管凭据中，由运行时绑定到 MCP；提示词、仓库和发布报告里只保留凭据名称。不要把令牌放进 URL 查询参数。

接入后先做工具发现，再验证仓库、分支和流水线查询。工具名称及参数以当前服务实际返回的列表为准。

在云效准备制品库、主机组和流水线

先在云效确认 Codeup、Packages、ECS 三种服务连接。创建 GENERIC 制品仓库；将测试 ECS 加入主机组，安装并确认 Runner 在线。主机组引用的服务连接字段可能要求 Numeric ID，不能把 UUID 直接填入。

流水线至少包含四个任务：Go 测试、Go 构建、ArtifactUpload、VMDeploy。上传与部署引用同一份制品版本；需要平台下载制品时，启用对应的下载配置。

一次发布至少要确定仓库、分支、环境和 Commit SHA。仓库 ID、服务连接 ID、主机组 ID 可以查询获取，不必反复手填，也不应长期沿用聊天记录中的旧值。

发布顺序：

1. 查询分支 HEAD，记录本次发布的 Commit SHA。
2. 检查代码、制品、主机组和 Runner 是否可用。
3. 读取当前流水线，只修改本次需要的配置。
4. 检查同一提交是否已有等待或运行中的任务，避免重复触发。
5. 跟踪测试、构建、上传、部署，再到主机验证结果。

测试环境可以允许受限的配置修正。生产发布、主分支修改和合并请求合入，需要另设授权与审批。

配置 Agent 发布规则

发布请求：

发布指定仓库的测试分支到测试 ECS。
执行前查询分支 HEAD、服务连接、制品仓库、主机组和 Runner。
读取当前流水线后再修改；已有同一提交的运行任务时复用。
依次验证 Test、Build、ArtifactUpload、VMDeploy、systemd 和健康接口。
权限或测试失败时停止，报告失败步骤及实际日志。
不修改主分支，不合并 MR，不执行生产部署。

上面的规则应写入 Agent 的固定配置；日常请求只需指定仓库、分支和环境。

更新流水线前，先保存当前配置和版本信息。生成修改后，再次读取并比较；发现其他人已经修改，就停止写入并重新检查差异。写入后回读，确认目标分支、服务连接和部署目标没有变化。

前后比较 SHA256 可以发现一部分并发修改，但它不是原子锁，比较与写入之间仍可能发生竞争。多人或多个 Agent 共用流水线时，应限制单一写入方，或使用接口支持的版本条件更新。

构建与部署

构建机与目标 ECS 的 glibc 版本不同时，可能报 GLIBC_2.32 not found。对于不依赖 CGO 的 Go 服务，可以按目标架构构建：

go test -count=1 ./...
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .

ARM 主机应调整 GOARCH。如果依赖 C 库，则需要匹配目标系统的构建环境，不能直接套用关闭 CGO 的做法。

主机部署脚本需要完成安装二进制、加载 systemd 和探活。以下是 systemd 单元的最小配置，假设部署脚本已创建 example-app 用户，应用使用 PORT 环境变量读取监听端口：

[Unit]
Description=Example Go service
After=network-online.target

[Service]
User=example-app
WorkingDirectory=/opt/example-app
Environment=PORT=18081
ExecStart=/opt/example-app/app
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

制品中的 deploy.sh 依次安装文件并重启服务。安装位置、用户与文件名需和上面的单元保持一致：

set -eu
install -d -m 0755 /opt/example-app
install -m 0755 ./app /opt/example-app/app
install -m 0644 ./example-app.service /etc/systemd/system/example-app.service
systemctl daemon-reload
systemctl enable example-app
systemctl restart example-app

制品版本绑定 Commit SHA，同时保存校验值。下载后既要验证文件校验值，也要确认内容确实是制品；返回 200 的登录页或错误页，同样会导致部署失败。

验证流水线和主机状态

流水线结束后还要检查服务：

systemctl is-active example-app
journalctl -u example-app -n 100 --no-pager
curl -fsS http://127.0.0.1:18081/healthz
curl -fsS http://127.0.0.1:18081/hello

这里的服务名和端口是示例，应与部署脚本保持一致。发布报告至少记录 Commit、Run ID、制品版本、部署目标和健康检查结果。测试通过、制品上传成功、部署完成、进程运行正常且接口响应符合预期，才能判定这次发布成功。

权限不足、业务测试失败时应停下来保留日志。反复重试或扩大权限，通常只会掩盖原来的问题。

参考

• AgentCore SDK 概述
• 云效 MCP 工具使用说明