环境
- 版本：v5.0（Docker 部署，deviops-api:v5.0 镜像）；已核对最新 main 分支（2026-08-03 提交），问题依然存在
- 平台侧：x86_64 Linux，容器内 Go 1.25.2
- 目标机：鲲鹏 920（aarch64），UOS Server/Desktop，SSH 可达
问题描述
向 aarch64 架构的目标主机部署 Agent 探针后，探针无法启动，/var/log/agent.log 持续报错：
/bin/sh: 1: exec: /opt/agent/dodevops-agent: Exec format error
用 file 检查平台分发过去的二进制：
/opt/agent/dodevops-agent: ELF 64-bit LSB executable, x86-64 ... statically linked
即平台给 ARM64 机器编译并分发了 x86-64 探针。SSH 连接、命令执行均正常，仅探针二进制架构不匹配。
根因分析（已定位到代码）
-
api/api/monitor/service/agent.go 约 115-119 行，编译目标表 GOARCH 全部硬编码 amd64：
-
var buildTargets = map[string]BuildTarget{
-
"linux": {GOOS: "linux", GOARCH: "amd64", Suffix: ""},
-
"windows": {GOOS: "windows", GOARCH: "amd64", Suffix: ".exe"},
-
"darwin": {GOOS: "darwin", GOARCH: "amd64", Suffix: ""},
-
}
-
detectPlatform()（约 2119 行）只根据资产录入的 OS 字符串识别 GOOS，完全没有架构维度。
-
部署流程中已在目标机执行过 uname -a（约 1214 行，用于诊断），能拿到 aarch64，但该结果未参与编译参数决策——离支持 ARM 只差"把探测结果喂给 GOARCH"一步。
-
构建产物缓存目录（如 dodevops-agent-build-cache/）的 hash 未包含目标架构维度，未来多架构并存时可能互相覆盖。
期望行为
部署探针时自动识别目标机 CPU 架构，交叉编译出匹配的二进制（至少支持 linux/amd64 与 linux/arm64）。
修复建议
方案一（最小改动）：buildTargets 增加 linux-arm64 条目，部署界面增加目标架构选项。
方案二（推荐，自适应）：编译前在目标机执行 uname -m（或复用现有 uname -a 诊断输出）做架构映射：
func toGoArch(unameM string) string {
switch strings.ToLower(strings.TrimSpace(unameM)) {
case "x86_64", "amd64":
return "amd64"
case "aarch64", "arm64":
return "arm64"
case "i686", "i386":
return "386"
default:
return "amd64"
}
}
编译时 GOOS=linux GOARCH=<映射结果>，同时把架构纳入构建缓存 hash。
方案三（长期，供参考）：探针目前是"部署时现编译、心跳地址编译期烙死"，建议演进为官方预编译多架构二进制 + 运行时配置文件下发（/etc/dodevops/agent.yaml 或命令行参数）。好处：
- 彻底解决多架构问题（Go 交叉编译零额外依赖）
- 心跳地址变更不再需要重编译 + 全量重新部署
- 省去每次部署的现编译耗时
补充说明
国产化场景下鲲鹏/飞腾等 ARM 服务器越来越普遍，该问题会挡住所有 ARM 主机的监控纳管。我们已在生产环境复现（鲲鹏 920 节点），愿意配合测试修复补丁。
环境
问题描述
向 aarch64 架构的目标主机部署 Agent 探针后，探针无法启动，/var/log/agent.log 持续报错：
/bin/sh: 1: exec: /opt/agent/dodevops-agent: Exec format error
用 file 检查平台分发过去的二进制：
/opt/agent/dodevops-agent: ELF 64-bit LSB executable, x86-64 ... statically linked
即平台给 ARM64 机器编译并分发了 x86-64 探针。SSH 连接、命令执行均正常，仅探针二进制架构不匹配。
根因分析（已定位到代码）
api/api/monitor/service/agent.go 约 115-119 行，编译目标表 GOARCH 全部硬编码 amd64：
var buildTargets = map[string]BuildTarget{
}
detectPlatform()（约 2119 行）只根据资产录入的 OS 字符串识别 GOOS，完全没有架构维度。
部署流程中已在目标机执行过 uname -a（约 1214 行，用于诊断），能拿到 aarch64，但该结果未参与编译参数决策——离支持 ARM 只差"把探测结果喂给 GOARCH"一步。
构建产物缓存目录（如 dodevops-agent-build-cache/）的 hash 未包含目标架构维度，未来多架构并存时可能互相覆盖。
期望行为
部署探针时自动识别目标机 CPU 架构，交叉编译出匹配的二进制（至少支持 linux/amd64 与 linux/arm64）。
修复建议
方案一（最小改动）：buildTargets 增加 linux-arm64 条目，部署界面增加目标架构选项。
方案二（推荐，自适应）：编译前在目标机执行 uname -m（或复用现有 uname -a 诊断输出）做架构映射：
func toGoArch(unameM string) string {
switch strings.ToLower(strings.TrimSpace(unameM)) {
case "x86_64", "amd64":
return "amd64"
case "aarch64", "arm64":
return "arm64"
case "i686", "i386":
return "386"
default:
return "amd64"
}
}
编译时 GOOS=linux GOARCH=<映射结果>，同时把架构纳入构建缓存 hash。
方案三（长期，供参考）：探针目前是"部署时现编译、心跳地址编译期烙死"，建议演进为官方预编译多架构二进制 + 运行时配置文件下发（/etc/dodevops/agent.yaml 或命令行参数）。好处：
补充说明
国产化场景下鲲鹏/飞腾等 ARM 服务器越来越普遍，该问题会挡住所有 ARM 主机的监控纳管。我们已在生产环境复现（鲲鹏 920 节点），愿意配合测试修复补丁。