Go Agent 接入 AgentLoop：从调用链到回归评估

Go Agent 在 ECS 上运行，通过 OTLP 向 AgentLoop 上报模型、工具和执行步骤。以 ACK 故障诊断为例，接入链路追踪、回归样本和自定义评估器。构建与部署命令均在示例工程中执行。

确认工程和运行环境

在示例工程根目录执行命令，相关文件如下：

环境准备 Go 1.24 系列、curl、jq、Python 3，并确保能访问模型与 OTLP 端点。

go version
go env GOOS GOARCH
curl --version
jq --version
go mod tidy
make verify VERSION=local-check

make verify 用于先检查本地确定性场景。它通过后，再配置真实模型，避免把工程问题与外部认证问题混在一起。

示例提供 /healthz、/readyz、/version 和 /v1/chat。健康接口可访问，只说明进程能够响应；还需要单独验证模型认证、工具执行和观测上报。

原示例使用 Go 1.24 系列和 agentloop 构建标签。依赖版本应随项目锁定，不要在日常构建中长期使用 latest。

模型地址、API Key 与 OTLP 上报地址分别配置。模型请求返回 401 时，先核对模型服务与 Key 是否对应；经过 AI 网关时，还要检查消费者鉴权。不要用修改 OTLP 配置来处理模型认证问题。

配置模型与 OTLP

复制工程内的模板，并限制配置文件权限：

cp .env.manual-otlp.example .env
chmod 600 .env

需要填写的核心项目如下。模型 Key 与观测认证分别从各自控制台获取：

MOCK_LLM=false
LLM_PROVIDER=dashscope
LLM_MODEL=qwen-plus
LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
DASHSCOPE_API_KEY=<你的模型Key>
OTEL_SERVICE_NAME=app-go-demo
OTEL_CMS_WORKSPACE=<目标工作空间>
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=<控制台生成的完整地址>
OTEL_EXPORTER_OTLP_HEADERS=<控制台生成的认证配置>
OTEL_TRACES_SAMPLER=parentbased_always_on

先构建并前台运行，确认没有依赖或配置错误，再安装为 systemd 服务：

./scripts/linux-ecs/11-build-manual-otlp.sh
./scripts/linux-ecs/12-run-manual-otlp.sh

另开一个终端：

curl -fsS http://127.0.0.1:8081/healthz | jq .
curl -fsS http://127.0.0.1:8081/readyz | jq .

前台检查通过后停止该进程，再执行工程的 08-install-systemd.sh，用 systemctl is-active agentloop-go-demo 与 journalctl -u agentloop-go-demo 检查后台进程，避免两个进程争用端口。

用一条真实请求验收

沿用示例接口，在本机发起请求：

curl -fsS http://127.0.0.1:8081/v1/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "session_id": "ack-check-001",
    "user_id": "demo-user",
    "scenario": "normal",
    "message": "检查 payment-api 的 OOMKilled，结论以工具结果为准。"
  }'

响应中的 session_id 应与请求一致，trace_id 应能用于检索。对于明确需要查数的正常场景，tool_executions 应包含实际工具结果。单凭回答写出了诊断过程，不能证明工具执行过。

tool_count=0 也不能一概判错：普通问答可以不调用工具。这里要结合任务要求判断。

查询执行链路

进入目标工作空间的 AI Agent 可观测 → 链路追踪，按返回的 Trace ID 或 Session ID 查询。先缩短到本次请求发生的时间范围。

埋点分为 ENTRY、AGENT、STEP、LLM、TOOL。STEP 用于表示一轮决策，LLM 与 TOOL 记录对应调用。各层必须沿用同一请求上下文，不能每次调用都重新创建根 Trace。

检查时重点看：

• service.name 和 gen_ai.session.id 是否正确。
• 用户输入、模型输出与工具结果是否放在各自字段中。
• LLM Span 是否记录实际 Token，工具 Span 是否包含参数、结果、错误和耗时。
• 工具失败是否标记为错误，回答是否说明数据缺失。
• Prompt、Skill 的版本和命中信息能否追溯。

上报时只保留诊断所需的输入输出，凭据和敏感业务字段应先脱敏。进程退出前也要完成 SDK 的刷新与关闭，避免短任务结束时丢失尾部 Span。

生成正常与异常回归样本

原工程的回归脚本会为每类场景生成独立 Session：

./scripts/linux-ecs/14-generate-real-regression.sh

每类样本要检查的行为如下：

回归场景按业务调整。工具数量不能单独衡量质量，还需检查重复调用和任务完成情况。

配置评估器的输入字段

工具诊断任务应评估任务完成度、证据支持、工具使用和变更边界。只有实际包含检索文档的任务，才适合使用对应的 RAG 评估器。

自定义评估器可以映射输入、输出、执行轨迹和工具上下文，再返回 score 与 explanation。

不要把输入输出映射为 Token 数，也不要把 output 误配到 trace.input。

成功 + 0 分 表示评估已完成且判定不合格；未知 + null 通常需要检查任务状态、字段映射或输出解析，不能直接当成零分。

数据集与版本对比

只有 question、answer 的 QA 数据集，适合检查表达、事实和输出格式。若要评价工具参数、调用顺序及失败处理，数据集还需要保留相应轨迹与工具结果。

数据处理流水线负责提取、去重和采样。它不会自动改变正在运行的 Agent，也不等于已经加载了新的 Prompt 或 Skill。

比较 Prompt 两个版本时，固定模型、参数和样本；输入只放问题，避免把旧答案泄漏给模型。先用少量代表性样本检查流程，再扩大到覆盖正常与异常场景的回归集，同时比较质量、Token 和耗时。生产版本切换后保留旧版本，便于发现退化时回退。

参考

• AgentLoop 链路追踪
• LoongSuite Go