一句话概括本文以 OpsPilot Zero 为案例系统拆解 AgentTeams 的部署配置、多 Agent 协同、Skill 复用、MCP 工具接入及 GOAI 参赛踩坑经验。前言为什么选择“运维故障处置”验证多 Agent 协作刚接触多 Agent 框架时我们很容易把注意力放在“创建了几个 Agent”“群聊是否足够热闹”上。但真正进入比赛场景后我更关注三个问题每个 Agent 是否有清晰、不可互相替代的职责Agent 的结论是否来自可核查的工具证据而不是模型自由发挥涉及真实系统变更时框架能否把自动执行和人工审批分开基于这三个问题我设计了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只是拥有不同的角色定义与协作 SkillManager 负责管理资源TeamLeader 负责团队内部的拆解、分派和汇总。这个边界对 OpsPilot Zero 很重要事故任务应该交给 TeamLeader而不是持续把所有业务问题发给 Manager。二、OpsPilot Zero 的总体设计OpsPilot Zero 采用“1 个 TeamLeader 4 个业务 Worker”的结构角色主要职责关键 Skill可调用工具OpsPilot TeamLeader拆解事故、串联调查、汇总最终报告Team 创建时生成不直接调用业务工具Alert Intake聚合客诉、初始告警和监控指标alert-fusion、impact-mappingmock_monitoring、mock_ticketRCA Analyst关联日志、Trace、配置、慢 SQL 与 Runbooklog-trace-rca、data-advisormock_logs、mock_traces、mock_config、mock_database、mock_runbookRemediation Planner生成修复、验证、回滚计划并进行风险分级remediation-plan、risk-guardmock_config、mock_database、mock_ticketRecovery Verifier执行低风险动作语义并验证恢复状态recovery-verify、data-advisormock_probe、mock_monitoring、mock_config、mock_database这里最关键的是形成一条完整证据链故障输入 → 告警归并 → 多源取证 → 根因假设 → 修复与回滚计划 → 风险闸门 → 恢复验证 → 事故报告如果让一个 Agent 从头做到尾它既负责提出根因又负责证明根因还负责宣布系统已经恢复很容易出现“自己证明自己正确”的问题。将调查、决策和验证拆开能够降低单一 Agent 过度自信带来的风险。三、两个故障案例如何驱动协作1. 数据库连接池耗尽第一个场景是db_pool_exhausteddb.pool.maxSize从50被改成8订单服务连接池被快速打满。理想的协作过程如下Alert Intake 读取告警、客诉和关键指标判断影响范围RCA Analyst 查询连接池超时日志、相关 Trace 和近期配置变更多条证据指向同一时间窗口后将配置变更提升为高置信根因Remediation Planner 生成回滚至上一稳定配置的 L1 低风险动作同时附带验证与失败回退条件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 或 WSL2bash (curl -fsSL https://raw.githubusercontent.com/agentscope-ai/AgentTeams/main/install/agentteams-install.sh)2. Windows PowerShell 7Set-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打开 Element Web 中对应的 Team 房间在消息中明确opspilot-zero-demo-leader先发送第一个事故等待完整报告再发送第二个事故避免两个场景的上下文和工具证据互相污染。不要把事故任务继续发给 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 工具网关而不是一开始就连接真实监控、数据库和工单系统原因有三点故障数据可重复便于稳定复现接口返回可控方便判断 Agent 是否真的调用了工具不涉及真实生产权限适合比赛展示和安全评审。Mock 层定义了mock_monitoring、mock_logs、mock_traces、mock_config、mock_database、mock_runbook、mock_ticket和mock_probe等工具。每个工具都应该返回结构化结果并保留scenario_id、时间戳、查询条件和证据来源避免 Agent 只拿到一段难以追踪的自然语言。第二阶段再迁移到真实 MCP Server 或 Higress MCP 代理。官方推荐的基本流程是在 Higress Console 配置 MCP Server通过 Higress API 注册 MCP Server为不同 Consumer 配置授权编写 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 工具调用测试。坑 2Manager、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 后续可以沿四条线继续完善将 HTTP Mock 工具网关替换为真实 MCP Server 或 Higress MCP 代理将内联 AgentSpec、Skill 和 Prompt 迁移到 Nacos AI Registry增加版本治理为每个事故保存工具调用轨迹、证据引用、风险决策和恢复验证结果增加权限矩阵、审批接口、任务生命周期、超时重试和幂等控制。当这些能力逐步补齐后OpsPilot Zero 才会从“可演示的多 Agent Demo”走向“可审计、可控制、可扩展的智能运维协作系统”。总结AgentTeams 为 OpsPilot Zero 提供的核心价值不只是创建多个 Worker而是用 Manager—Workers、TeamLeader、Matrix 房间、Skill 和网关工具治理把故障处理拆成一条人类可观察、可介入的协作链路。对于 GOAI 参赛项目我认为最值得展示的也不是 Agent 之间有多少轮对话而是它们是否完成了三次关键跨越从“凭模型回答”到“基于工具取证”从“单 Agent 包办”到“职责分离协作”从“自动执行一切”到“按风险分级控制执行”。参考资料AgentTeams 官方仓库AgentTeams Quickstart GuideAgentTeams ArchitectureAgentTeams Manager GuideAgentTeams Worker Guide