AgentTeams 实战复盘：用 OpsPilot Zero 搭建可审计的多 Agent 运维团队

一句话概括：本文以 OpsPilot Zero 为案例，系统拆解 AgentTeams 的部署配置、多 Agent 协同、Skill 复用、MCP 工具接入及 GOAI 参赛踩坑经验。

前言：为什么选择“运维故障处置”验证多 Agent 协作

刚接触多 Agent 框架时，我们很容易把注意力放在“创建了几个 Agent”“群聊是否足够热闹”上。但真正进入比赛场景后，我更关注三个问题：

1. 每个 Agent 是否有清晰、不可互相替代的职责？

2. Agent 的结论是否来自可核查的工具证据，而不是模型自由发挥？

3. 涉及真实系统变更时，框架能否把自动执行和人工审批分开？

基于这三个问题，我设计了OpsPilot Zero：一个面向 GOAI 初赛的 AgentTeams 最小 Demo。用户只输入故障现象和少量初始告警，多个业务 Agent 再主动查询监控、日志、Trace、配置、慢 SQL、Runbook 等信息，最后形成根因分析、修复方案和恢复验证报告。

一、AgentTeams 到底解决什么问题

AgentTeams 是一个开源的协作式多智能体运行平台。它采用 Manager—Workers 架构，通过 Matrix 房间承载人与 Agent、Agent 与 Agent 之间的协作过程，让任务分派、进度汇报和人工介入出现在同一条可审计时间线上。

它和“在一个 Python 进程中实例化多个 Agent”的方案有明显区别：AgentTeams 主要负责多个 Agent 运行时的创建、治理、通信和协作，本身并不要求所有 Worker 使用同一种 Agent Runtime。官方资料中已经支持 QwenPaw、OpenClaw、Hermes 等不同运行时协作。

从 OpsPilot Zero 的角度看，这种设计有三点价值：

• 过程可见：不是只得到一个最终答案，而是能看到 TeamLeader 如何分派任务、各 Worker 如何返回证据；

• 职责隔离：告警聚合、根因分析、修复规划、恢复验证由不同 Worker 负责；

• 工具与密钥治理：外部服务可以通过 Higress AI Gateway 和 MCP Server 统一暴露，Worker 不必直接持有真实服务密钥。

官方架构文档还强调，TeamLeader 本质上也是一个 Worker，只是拥有不同的角色定义与协作 Skill；Manager 负责管理资源，TeamLeader 负责团队内部的拆解、分派和汇总。这个边界对 OpsPilot Zero 很重要：事故任务应该交给 TeamLeader，而不是持续把所有业务问题发给 Manager。

二、OpsPilot Zero 的总体设计

OpsPilot Zero 采用“1 个 TeamLeader + 4 个业务 Worker”的结构：

角色	主要职责	关键 Skill	可调用工具
OpsPilot TeamLeader	拆解事故、串联调查、汇总最终报告	Team 创建时生成	不直接调用业务工具
Alert Intake	聚合客诉、初始告警和监控指标	alert-fusion、impact-mapping	mock_monitoring、mock_ticket
RCA Analyst	关联日志、Trace、配置、慢 SQL 与 Runbook	log-trace-rca、data-advisor	mock_logs、mock_traces、mock_config、mock_database、mock_runbook
Remediation Planner	生成修复、验证、回滚计划并进行风险分级	remediation-plan、risk-guard	mock_config、mock_database、mock_ticket
Recovery Verifier	执行低风险动作语义并验证恢复状态	recovery-verify、data-advisor	mock_probe、mock_monitoring、mock_config、mock_database

这里最关键的是形成一条完整证据链：

故障输入 → 告警归并 → 多源取证 → 根因假设 → 修复与回滚计划 → 风险闸门 → 恢复验证 → 事故报告

如果让一个 Agent 从头做到尾，它既负责提出根因，又负责证明根因，还负责宣布系统已经恢复，很容易出现“自己证明自己正确”的问题。将调查、决策和验证拆开，能够降低单一 Agent 过度自信带来的风险。

三、两个故障案例如何驱动协作

1. 数据库连接池耗尽

第一个场景是db_pool_exhausted：db.pool.maxSize从50被改成8，订单服务连接池被快速打满。

理想的协作过程如下：

1. Alert Intake 读取告警、客诉和关键指标，判断影响范围；

2. RCA Analyst 查询连接池超时日志、相关 Trace 和近期配置变更；

3. 多条证据指向同一时间窗口后，将配置变更提升为高置信根因；

4. Remediation Planner 生成回滚至上一稳定配置的 L1 低风险动作，同时附带验证与失败回退条件；

5. Recovery Verifier 查询探针、错误率、延迟和连接池指标，判断是否真正恢复。

这里不能只凭“maxSize 变小了”直接下结论。配置时间、异常时间、日志模式和 Trace 结果必须能够互相印证。

2. 慢 SQL 导致性能退化

第二个场景是slow_sql_degradation：订单历史查询扫描行数过多，拖慢服务响应。

这个案例用于验证“缓解动作”和“长期修复”能否分开：

• 读缓存属于可快速降低影响面的缓解方案；

• 创建索引会改变数据库结构，应标记为 L3 高风险审批项；

• 在审批通过前，Agent 只能输出执行计划、SQL 建议、验证指标和回滚方式，不能把“建议建索引”写成“已经建索引”。

这也是 OpsPilot Zero 的安全底线：低风险动作可以进入自动化执行语义，高风险动作只生成审批计划。

四、AgentTeams 安装与部署配置

AgentTeams 当前官方快速安装要求 Docker 正常运行，并准备一个大模型 API Key。阿里云百炼/Qwen 是快速安装的默认选择，也可以在手动安装中填写 OpenAI 兼容服务的 Base URL、API Key 和模型 ID。

1. Linux、macOS 或 WSL2

bash <(curl -fsSL https://raw.githubusercontent.com/agentscope-ai/AgentTeams/main/install/agentteams-install.sh)

2. Windows PowerShell 7+

Set-ExecutionPolicy Bypass -Scope Process -Force $wc = New-Object Net.WebClient $wc.Encoding = [Text.Encoding]::UTF8 iex $wc.DownloadString('https://raw.githubusercontent.com/agentscope-ai/AgentTeams/main/install/agentteams-install.ps1')

安装器会引导填写模型供应商、API Key、管理员账号、端口和持久化配置。安装完成后，应先确认 Manager、控制器、Matrix/Element Web、存储与网关等组件处于健康状态，再开始创建 Worker。

项目 README 中仍保留了早期 HiClaw 安装地址，以及qwenpow、copow、QwenPaw并列的历史写法。AgentTeams 仍在快速迭代，正式复现时应以当前官方仓库的安装脚本和版本文档为准，不要混用不同时期的命令、镜像名与运行时名称。

3. 先启动 OpsPilot Zero 的 Mock 工具网关

在 Demo 目录执行：

python3 tools/mock_tool_server.py --host 0.0.0.0 --port 18089

然后不要在 Worker 内写死localhost:18089。AgentTeams 的 Manager 和 Worker 运行在容器中，容器内的localhost指向容器自身，而不是宿主机。

可以先查询 Manager 所在 Docker 网络的网关地址：

docker inspect -f '{{range .NetworkSettings.Networks}}{{println .Gateway}}{{end}}' hiclaw-manager

再从容器中验证连通性：

docker exec -it hiclaw-manager curl http://<GATEWAY_IP>:18089/health

如果容器名不是hiclaw-manager，先通过docker ps确认实际名称。只有健康检查成功，才把http://<GATEWAY_IP>:18089写入 Worker 的工具配置。

五、多 Agent 协同设计：Manager 与 TeamLeader 不要混用

在 OpsPilot Zero 中，Manager 首先串行创建 4 个业务 Worker，再创建 Team，并生成独立 TeamLeaderopspilot-zero-demo-leader。

为什么建议串行创建？因为创建 Worker 往往同时涉及 Matrix 账号、房间、运行时容器、网关 Consumer 和配置同步。对于比赛 Demo，串行执行更容易定位失败环节，也能避免模型在并行创建时重复提交资源请求。

创建完成后，业务任务的正确入口是 Team 房间中的 TeamLeader：

1. 打开 Element Web 中对应的 Team 房间；

2. 在消息中明确@opspilot-zero-demo-leader；

3. 先发送第一个事故，等待完整报告；

4. 再发送第二个事故，避免两个场景的上下文和工具证据互相污染。

不要把事故任务继续发给 Manager。Manager 的职责是“创建和治理团队”，TeamLeader 的职责才是“组织团队完成业务任务”。如果两个层级都在调度业务 Worker，容易出现重复派发、重复回复或职责穿透。

六、Skill 如何封装，才能真正复用

我对 Skill 的理解是把稳定的任务方法固化为可加载、可版本化、可评审的能力单元。

以risk-guard为例，一个合格的 Skill 至少应包含：

• 适用条件：什么时候必须调用风险分级；

• 输入契约：动作对象、影响范围、证据、回滚能力；

• 决策规则：L1/L2/L3 如何判定；

• 输出格式：风险等级、理由、前置条件、验证指标、回滚步骤；

• 禁止事项：未审批的高风险动作不得声称已经执行。

Skill 应围绕职责边界拆分，而不是围绕某一次具体故障写死。例如：

• log-trace-rca负责跨日志与 Trace 建立时间关联；

• data-advisor负责分析 SQL 或数据访问问题；

• recovery-verify负责定义“恢复”的判定标准；

• risk-guard负责决定动作能自动执行还是进入审批。

这样，同一个data-advisor可以被 RCA Analyst 和 Recovery Verifier 复用，但两者调用它的目标不同：前者为了定位根因，后者为了确认修复没有引入新的数据层异常。

根据 AgentTeams 当前的 Manager Guide，后续还可以把 Prompt、Skill 和 AgentSpec 迁移到 Nacos AI Registry 或 AgentTeams Skill Registry，通过版本和标签动态加载。比赛初期先使用仓库内的SKILL.md便于评审，方案稳定后再做注册中心化，是更稳妥的演进路径。

七、从 HTTP Mock 到 MCP：工具接入的两阶段策略

OpsPilot Zero 第一阶段使用 HTTP Mock 工具网关，而不是一开始就连接真实监控、数据库和工单系统，原因有三点：

1. 故障数据可重复，便于稳定复现；

2. 接口返回可控，方便判断 Agent 是否真的调用了工具；

3. 不涉及真实生产权限，适合比赛展示和安全评审。

Mock 层定义了mock_monitoring、mock_logs、mock_traces、mock_config、mock_database、mock_runbook、mock_ticket和mock_probe等工具。每个工具都应该返回结构化结果，并保留scenario_id、时间戳、查询条件和证据来源，避免 Agent 只拿到一段难以追踪的自然语言。

第二阶段再迁移到真实 MCP Server 或 Higress MCP 代理。官方推荐的基本流程是：

1. 在 Higress Console 配置 MCP Server；

2. 通过 Higress API 注册 MCP Server；

3. 为不同 Consumer 配置授权；

4. 编写 Skill，告诉 Worker 有哪些工具、参数怎么填、返回结果如何解释。

这里有一个很容易忽略的点：接入 MCP 不等于 Agent 就会正确使用 MCP。工具 Schema 解决的是“怎么调用”，Skill 解决的是“什么时候调用、调用后如何判断”。二者缺一不可。

例如，mock_database即使未来替换成真实数据库 MCP，也不应该向所有 Worker 开放写权限。RCA Analyst 可以拥有只读查询能力；Remediation Planner 只能生成变更计划；真正的高风险 DDL 仍需审批后由受控执行端完成。

八、部署与协作中的踩坑记录

坑 1：容器内访问宿主机时使用 localhost

这是最常见的网络问题。Mock Server 明明在宿主机的18089端口正常运行，但 Worker 调用一直失败，原因通常是容器中的127.0.0.1并不是宿主机。

解决思路不是反复修改 Prompt，而是先完成三段式排查：宿主机健康检查、容器到网关地址的连通测试、Worker 工具调用测试。

坑 2：Manager、TeamLeader 和 Worker 的任务边界模糊

如果事故既发给 Manager，又发给 TeamLeader，可能出现重复建队、重复派发或多个 Agent 同时争抢总结权。实践中应固定单一入口：资源管理发给 Manager，团队业务任务发给 TeamLeader。

坑 3：只写“调用某工具”，没有写证据判定标准

Agent 能调用日志工具，不代表它会做可靠 RCA。Skill 中应明确：时间窗口如何对齐、至少需要几类独立证据、冲突证据如何处理、证据不足时如何降级置信度。

坑 4：把建议动作写成已执行动作

多 Agent 汇总时很容易发生语态漂移：Worker 说“建议创建索引”，TeamLeader 最后却总结成“已创建索引”。因此输出协议中必须区分observed、inferred、proposed、executed和verified状态。

坑 5：缺少任务终止约束，Agent 互相回复“收到”

AgentTeams 社区曾记录 TeamLeader 与 Worker 在最终答复后形成 acknowledgement mirror loop：双方不断回复“收到”“任务完成”，造成额外模型调用和聊天记录污染。短期可在角色规则中禁止无信息量的完成确认；更稳妥的方向是在协议层引入明确的任务生命周期和终止状态。参见社区问题讨论：Team Room ack mirror loop。

坑 6：框架更新快，旧名称与新命令混杂

HiClaw 已更名为 AgentTeams，安装脚本、镜像、运行时名称和配置结构也在持续变化。复现时应锁定版本，README、安装命令、镜像标签和 Skill 配置必须来自同一版本，不能只复制一段旧教程里的命令。

九、参赛复盘：从“能对话”走向“能协作、能取证、可控执行”

这次方案设计给我最大的启发是，多 Agent 项目的重点从来不是让更多模型同时说话，而是建立稳定的协作协议。

第一，Agent 数量服从流程需要。OpsPilot Zero 选择 4 个业务 Worker，是因为告警接入、根因调查、修复规划和恢复验证天然存在职责分离，而不是为了展示更大的 Agent 数字。

第二，所有结论都要回到工具证据。没有日志、Trace、配置和指标支撑的根因，只能叫假设；没有修复后探针和监控支撑的“恢复”，也只能叫预期。

第三，风险控制必须进入系统设计。高风险操作不是在文章结尾补一句“需要注意安全”，而是从 Tool 权限、Skill 规则、状态字段和审批流程四个层面共同限制。

第四，Mock 不是“假项目”，而是可重复验证的工程手段。在初赛阶段，先用稳定场景验证协作链路，再逐步替换为真实 MCP 和数据源，比一开始接入复杂生产系统更容易定位问题。

第五，如实描述比夸大结果更重要。当前已经完成的是 Demo 架构与运行方案设计；只有在保存完整 Team 房间记录、工具调用轨迹和两次事故报告后，才能进一步写“端到端运行通过”“恢复验证成功”以及具体耗时指标。

十、后续演进方向

OpsPilot Zero 后续可以沿四条线继续完善：

1. 将 HTTP Mock 工具网关替换为真实 MCP Server 或 Higress MCP 代理；

2. 将内联 AgentSpec、Skill 和 Prompt 迁移到 Nacos AI Registry，增加版本治理；

3. 为每个事故保存工具调用轨迹、证据引用、风险决策和恢复验证结果；

4. 增加权限矩阵、审批接口、任务生命周期、超时重试和幂等控制。

当这些能力逐步补齐后，OpsPilot Zero 才会从“可演示的多 Agent Demo”走向“可审计、可控制、可扩展的智能运维协作系统”。

总结

AgentTeams 为 OpsPilot Zero 提供的核心价值，不只是创建多个 Worker，而是用 Manager—Workers、TeamLeader、Matrix 房间、Skill 和网关工具治理，把故障处理拆成一条人类可观察、可介入的协作链路。

对于 GOAI 参赛项目，我认为最值得展示的也不是 Agent 之间有多少轮对话，而是它们是否完成了三次关键跨越：从“凭模型回答”到“基于工具取证”，从“单 Agent 包办”到“职责分离协作”，从“自动执行一切”到“按风险分级控制执行”。

参考资料

• AgentTeams 官方仓库

• AgentTeams Quickstart Guide

• AgentTeams Architecture

• AgentTeams Manager Guide

• AgentTeams Worker Guide