使用 MCP 与 A2A 设计多智能体 AI 系统——使用 A2A 实现多智能体系统

数据智能老司机
0 阅读56分钟

DevOps 实践通过打破组织孤岛、实现持续集成、持续部署与持续监控，彻底改变了软件开发与运维方式。然而，随着系统愈发复杂与分布式，传统 DevOps 方法在可扩展性上开始面临挑战。多智能体 AI 系统的出现，为 DevOps 团队转型提供了机会：引入自治的、专业化的 AI 智能体，与人类运维人员并肩工作，管理基础设施、发现问题并编排修复动作。

基于第 8 章介绍的 Agent-to-Agent（A2A）协议基础，本章将探讨如何用多智能体系统构建 AI 驱动的 DevOps 团队。我们将考察如何把传统 DevOps 职责拆解为专门的智能体角色，如何实现自治的监控与修复工作流，以及如何创建人机协作模式——在利用 AI 能力的同时保持运维控制权。我们将构建一个完整的多智能体 Kubernetes DevOps（MAKDO）系统，它能够自治管理 Kubernetes 集群，并且无缝融入现有的人类工作流。

本章涵盖以下关键主题：

  • 构建 AI 驱动的 DevOps 团队
  • 定义专门化智能体的角色与职责
  • 实现这些智能体
  • 用一个管理者（manager）智能体编排团队
  • 集成人类反馈与控制通道
  • MAKDO 实战——完整 demo 走读

技术要求

本章代码在此：
github.com/PacktPublis…

构建 AI 驱动的 DevOps 团队

多智能体 DevOps 系统代表着从“被动、手工运维”到“主动、自治基础设施管理”的范式转变。通过把职责分配给具备领域专长的专门智能体（例如监控、分析、修复或沟通），我们可以构建能够 7×24 小时运行、可扩展到管理上百个集群、并对运维问题给出一致且可复现响应的系统。关键在于：这些系统应当增强（augment）而不是替代人类专业能力，形成协作式工作流，发挥 AI 智能体与人类运维人员各自的优势。

我们将使用带 A2A 集成与 Model Context Protocol（MCP）工具的 AI-6 框架构建一个 MAKDO 系统，演示智能体专门化、编排与人类集成的可落地模式。你将掌握设计与实现智能体 AI 系统的方法，从而改变组织在基础设施管理上的实践方式。

为什么 DevOps 适合多智能体 AI？

DevOps 是多智能体 AI 系统的理想领域。它面对的是现代基础设施的“分布式混沌”：Kubernetes 集群、数据库与跨云网络，以及对不可避免故障需要快速、专业化响应的现实。

我见过很多团队被来自不同系统的大量告警淹没，长期处于高压状态，根本没有时间处理系统性问题。AI 智能体可以通过部署领域专家来改变这一点：一个盯 Kubernetes pods，另一个调优数据库查询，第三个嗅探网络问题。它们贴近现场并行做分诊（triage），让停机时间从分钟级降到毫秒级。

排障往往遵循一些我“踩坑学到”的模式，比如检查事件、日志与资源。但大规模分布式系统的暴露面极其巨大，人类很难在短时间内覆盖所有检查项。智能体可以瞬间执行标准操作流程（SOPs），并把“奇怪的案例”连同完整上下文一起升级（escalate）给人类，从而让站点可靠性工程师（SREs）把精力从救火转向架构优化。

DevOps 本来就依赖专门化分工（DBA、网络工程师、云专家、安全专家），所以智能体很容易“镜像”这种组织结构：安全智能体负责找漏洞，扩缩容智能体负责应对流量尖峰。人类 + AI 的团队协作让系统保持高质量、高性能与高安全性。AI 智能体处理例行任务，人类处理新型威胁与新问题；同时也让人类工程师有余力去建设更好的自动化与护栏，使 AI 智能体能可靠承担越来越多工作。

当然，要打造有效的 AI 驱动 DevOps 团队，必须仔细设计智能体角色、职责与交互模式。下面我们以 MAKDO 为实践样例，探讨如何设计与实现多智能体 DevOps 系统。MAKDO 体现了前几章讨论的原则，并展示它们如何应用到 DevOps 领域。

我们直接开始认识 MAKDO。

MAKDO —— 多智能体 Kubernetes DevOps 系统

MAKDO 展示了如何把传统 DevOps 角色转化为一个协同的多智能体 AI 系统。下面我们看它的架构与智能体设计。

系统架构

MAKDO 由四个专门智能体协同工作，在人类监督下实现 Kubernetes 集群的自治管理：

  • Coordinator agent（协调者） ：编排整体工作流，做高层决策，并协调其他智能体
  • Analyzer agent（分析者） ：专注于集群健康评估与问题识别，使用 k8s-ai 集成
  • Fixer agent（修复者） ：负责安全的集群修改与自动化修复
  • Slack agent（沟通者） ：管理与人类沟通与通知的工作流

这个架构反映了 DevOps 团队中职责的自然划分，同时支持自治运行与人类监督。

系统还可能持续演进，每个智能体也可以按需派生更多专门智能体。例如，可增加安全智能体监控漏洞，或增加 Kubernetes control plane 智能体处理控制平面特有问题。

协调者智能体——编排运维

协调者智能体是团队的 leader：编排问题响应并把任务委派给专门智能体。在 AI-6 的多智能体架构里，协调者可以把子智能体当作工具使用，而 LLM 会基于当前情境决定何时调用哪些子智能体。由于子智能体的输入就是它的 prompt，协调者必须具备很强的 prompt 工程能力。

MAKDO 使用一个配置文件：在父级协调者配置内以内联方式定义子智能体。这种分层配置模式意味着 AI-6 能从单个文件里自动发现并实例化所有智能体。下面是该文件的一个提炼后的伪版本，展示关键结构。完整文件见：
github.com/PacktPublis…

# Coordinator configuration (parent agent)
name: "MAKDO Coordinator"
default_model_id: "gpt-4o"
tools_dirs: [ "/path/to/ai-six/tools/memory" ]
system_prompt: |
  You are the MAKDO Coordinator orchestrating specialized agents.
  Delegate to: agent_MAKDO_Analyzer, agent_MAKDO_Fixer, agent_MAKDO_Slack_Bot

# Sub-agents embedded inline (AI-6 auto-instantiates these as AgentTools)
agents:
  # Analyzer sub-agent: Has A2A access to k8s-ai for diagnostics
  - name: "MAKDO_Analyzer"
    description: "Cluster health assessment agent"
    default_model_id: "gpt-4o"
    enable_memory: false
    a2a_servers:
      - name: "kind-makdo-test"
        url: "http://localhost:9999"
    system_prompt: |
      Analyze cluster health using k8s-ai A2A diagnostic skills.
      Report findings with full pod names, errors, and recommendations.

  # Fixer sub-agent: Has A2A access to k8s-ai for remediation
  - name: "MAKDO_Fixer"
    description: "Safe cluster modification agent"
    default_model_id: "gpt-4o"
    enable_memory: false
    a2a_servers:
      - name: "kind-makdo-test"
        url: "http://localhost:9999"
    system_prompt: |
      Execute safe remediation actions using k8s-ai A2A skills.
      Require approval for destructive operations (delete, scale down).

  # Slack_Bot sub-agent: Has MCP access to local Slack server
  - name: "MAKDO_Slack_Bot"
    description: "User communication agent"
    default_model_id: "gpt-4o"
    mcp_tools_dirs: [ "src/makdo/mcp_tools" ]
    system_prompt: |
      Post notifications to #makdo-devops Slack channel.
      Handle approval workflows for critical operations.

MAKDO 配置文件的关键特性如下：

  • 父级配置（Parent config） ：顶层定义 Coordinator 智能体，包含 name、model 与 system prompt。

  • 子智能体以内联方式定义（Inline sub-agents） ：三个子智能体都放在父配置的 agents: 下。

  • 按智能体定制工具访问（Per-agent tool access） ：

    • Analyzer：通过 a2a_servers 获得 k8s-ai 诊断能力
    • Fixer：通过 a2a_servers 获得 k8s-ai 修复能力
    • Slack_Bot：通过 mcp_tools_dirs 获得 Slack 通信能力

  • AI-6 的“魔法” ：加载这一个文件时，AI-6 会自动：

    • 创建四个智能体实例（一个协调者 + 三个子智能体）
    • 将子智能体封装为 AgentTool 实例
    • 让协调者能以 agent_MAKDO_Analyzer、agent_MAKDO_Fixer、agent_MAKDO_Slack_Bot 的形式调用它们

  • 详尽 system prompts：每个智能体都有完整说明，定义职责、报告格式与操作准则。

这一份 YAML 文件就定义了完整的多智能体系统。协调者可以按需调用子智能体编排复杂工作流，LLM 会基于情境决定该调用哪个智能体。

注意每个子智能体如何通过三种机制实现专门化：

  • 工具访问（Tool access） ：Analyzer 和 Fixer 拿到 A2A 工具，Slack_Bot 拿到 MCP 工具
  • 系统提示词（System prompts） ：用详细指令编码领域专长与操作流程
  • 报告格式（Report formats） ：用结构化输出模板保证报告一致、可执行

Analyzer 的 prompt 包含问题优先级与报告格式；Fixer 的 prompt 定义安全协议与审批要求；Slack_Bot 的 prompt 定义消息格式与命令处理。

这种基于 prompt 的专门化比“写代码实现”更灵活，原因包括：

  • 行为可调而无需改代码
  • 领域知识可读、可审计
  • 新能力可通过 prompt 工程加入
  • LLM 可推理处理边界情况

下面我们看这些智能体如何在 AI-6 多智能体架构中交互。

智能体交互模式（Agent interaction patterns）

MAKDO 展示了 AI-6 多智能体架构如何通过“工具式委派（tool-based delegation）”实现协同运维。理解这一模式是理解 MAKDO 如何协作的关键。

LLM 驱动的智能体协调（LLM-driven agent coordination）

在 AI-6 中，子智能体以工具形式暴露给父智能体。换个角度看，AI 系统对外交互仿佛只有一个智能体；“根智能体拥有子智能体”只是内部细节。驱动根智能体的 LLM 会在对话的每一轮决定：是需要调用某个工具，还是已有足够信息。至于它手头的工具里有些是“聪明工具”（本身就是 AI-6 智能体，或是通过 A2A 协议连接的外部 AI 系统），这对它并不重要。

并不存在一个 Coordinator 类去调用 Analyzer 或 Fixer 的方法——甚至根本没有这些类。协调逻辑用自然语言写在各智能体的 system prompt 里，由 LLM 的推理决定何时把哪个智能体当作工具调用。这是“后绑定逻辑（late-binding logic）”的例子。

AI-6 通过 AgentTool 类实现该机制：AgentTool 把子智能体封装为可调用工具。AgentTool 实现标准 Tool 接口：输入自然语言消息，输出子智能体完整响应。从父智能体视角看，调用子智能体与调用任何其他工具没有区别。关于 AgentTool 的实现细节，参见第 8 章。

当协调者需要分析集群时，LLM 会生成类似这样的工具调用：

{
  "name": "agent_MAKDO_Analyzer",
  "arguments": {
    "message": "Analyze the health of the kind-makdo-test cluster. Focus on pod failures and provide specific remediation recommendations."
  }
}

AgentTool 会封装整个子智能体交互：把消息发送给 Analyzer，等待它完整返回（包括 Analyzer 自己对 k8s-ai 的任何工具调用），并把最终结果返回给 Coordinator。

这种模式带来多项收益：

  • 自然委派（Natural delegation） ：LLM 像人类协调者一样，判断何时需要专家能力
  • 封装（Encapsulation） ：每个智能体自己管理对话历史与工具使用
  • 可组合（Composability） ：智能体可任意深度嵌套
  • 上下文保留（Context preservation） ：协调者无需追踪子智能体实现细节

AI-6 自带不少工具，但它不可能为每个 AI 系统提供一切。这没关系，因为 MAKDO 可以为 AI-6 扩展额外工具。

为 AI-6 扩展新工具（Extending AI-6 with new tools）

MAKDO 通过 Slack 与人类团队交互。AI-6 没有内置 Slack 工具（尽管它有 Slack 前端），但 AI-6 可以扩展：支持自有工具接口或 MCP 标准。因此我们实现一个自定义 MCP server，把 Slack 操作以工具形式暴露出来。

Slack_Bot 智能体使用一个基于 FastMCP 的自定义 MCP server 来处理所有 Slack 通信。该 server 位于：
github.com/PacktPublis…

Slack MCP server 基于官方 MCP Python SDK（github.com/modelcontex…）的 FastMCP 实现，关键特性如下：

  • 装饰器式工具注册（Decorator-based tools） ：@mcp.tool() 自动把函数注册为 MCP 工具
  • Token 管理（Token management） ：从环境变量或 .env 文件读取 AI6_BOT_TOKEN
  • 简单 HTTP 调用（Simple HTTP calls） ：用 requests 直接调用 Slack API
  • 错误处理（Error handling） ：返回 LLM 可理解的成功/失败消息
  • 频道规范化（Channel normalization） ：若缺少 # 前缀则自动补上

这比手写完整 JSON-RPC MCP server 简单得多。FastMCP 处理所有协议细节，让你专注工具本身的功能。

当 AI-6 加载这个 MCP server 后，Slack_Bot 智能体会自动获得 slack_post_message 与 slack_list_channels 两个可用工具。LLM 可以自然调用它们：

{
  "name": "slack_post_message",
  "arguments": {
    "channel": "makdo-devops",
    "text": "🚨 CRITICAL: 3 pods failing in kind-makdo-test cluster"
  }
}

接下来看看 AI-6 如何发现并分配这些新工具（包括 MAKDO 提供的 Slack_Bot 智能体）。

工具发现与分配（Tool discovery and assignment）

AI-6 会从多个来源自动发现工具，并基于配置把它们分配给不同智能体。tool_manager 模块（github.com/PacktPublis…）通过 get_tool_dict() 完成这件事：它把来自不同目录与 server 的工具汇总，然后按 enabled/disabled 列表过滤：

def get_tool_dict(
    tool_config: ToolConfig, agent_configs: list[Config] = None
) -> dict[str, Tool]:
    """Get a dictionary of all available tools from various sources."""
    tools: list[Tool] = []

    # 1. Discover AI-6 native tools from all directories
    for tools_dir in tool_config.tools_dirs:
        native_tools = _discover_native_tools(tools_dir)
        tools.extend(native_tools)

    # 2. Discover local MCP tools from all directories
    for mcp_tools_dir in tool_config.mcp_tools_dirs:
        local_mcp_tools = _discover_local_mcp_tools(mcp_tools_dir)
        tools.extend(local_mcp_tools)

    # 3. Get tools from A2A servers
    if tool_config.a2a_servers:
        a2a_tools = _get_a2a_tools(tool_config.a2a_servers)
        tools.extend(a2a_tools)

    # 4. Create agent tools if agent configs provided
    if agent_configs:
        agent_tools = _create_agent_tools(agent_configs)
        tools.extend(agent_tools)

    # 5. Filter tools based on enabled/disabled configuration
    tools = _filter_tools(tools, tool_config.enabled_tools, tool_config.disabled_tools)

    return {tool.name: tool for tool in tools}

下面是 MAKDO 中每个智能体最终拿到的工具构成：

  • Coordinator 智能体最终包含：

    • Memory tools
    • Agent tools：agent_MAKDO_Analyzer、agent_MAKDO_Fixer、agent_MAKDO_Slack_Bot

  • Analyzer 与 Fixer各自包含：

    • 来自 k8s-ai server 的 A2A tools（kind-makdo-test_* 一类用于 kubectl 操作的工具）
    • Memory tools

  • Slack_Bot包含：

    • 来自 src/makdo/mcp_tools/slack.py 的 MCP tools（slack_post_message、slack_list_channels）
    • Memory tools（继承/具备）

上下文共享与状态管理（Context sharing and state management）

在 AI-6 的多智能体架构中，智能体之间没有直接上下文共享。每个 AI-6 智能体都有自己的模型与上下文，只能通过工具调用与工具返回值与其他智能体通信。

常见上下文共享方式包括：

消息传递（Message passing）

当 Coordinator 调用子智能体时，会把相关上下文塞进 message。比如：

{
  "name": "agent_MAKDO_Fixer",
  "arguments": {
    "message": "Execute remediation for kind-makdo-test cluster. The Analyzer identified 3 failing pods due to image pull errors. Please attempt to restart the affected pods and verify they come up successfully."
  }
}
会话隔离（Session isolation）

每个智能体维护自己的 session 与对话历史。见：
github.com/PacktPublis…

self.session_manager = SessionManager(config.memory_dir)
self.session = self._create_new_session(config.memory_dir)
返回值（Return values）

子智能体返回完整响应，Coordinator 把它纳入自己的上下文：

Coordinator Session：

  • User: "Check cluster health"
  • Assistant: [calls agent_MAKDO_Analyzer tool]
  • Tool Result: "Analysis complete. Found 3 failing pods..."
  • Assistant: "Based on analysis, we have critical issues. Let me notify the team..."

这种基于 session 的方式保证上下文隔离，同时通过显式消息传递实现协调运维。每个智能体的对话历史彼此独立，避免上下文污染，也让智能体可以在不同上下文下被多次调用。

现在我们已经覆盖上下文共享与状态管理，接下来我们将深入 MAKDO 各个智能体的角色与职责。

为专门化智能体定义角色与职责（Defining roles and responsibilities for specialized agents）

前面展示的 coordinator.yaml 配置定义了 MAKDO 的四智能体架构。本节将剖析其设计动机：为什么选择这些角色边界、做了哪些权衡，以及该架构如何扩展。

从 DevOps 工作流到智能体架构（From DevOps workflows to agent architecture）

MAKDO 的智能体设计源自对典型 Kubernetes 事故响应（incident response）工作流的分析。传统的人工流程大致如下：

  • 告警触发（Alert triggers） ：运维人员收到通知
  • 诊断（Diagnosis） ：运维人员运行 kubectl 命令调查
  • 决策（Decision） ：运维人员判断应采取的修复措施
  • 修复（Remediation） ：运维人员谨慎应用变更
  • 沟通（Communication） ：运维人员在 Slack 更新团队进展
  • 验证（Verification） ：运维人员确认修复生效

这可以直接映射到 MAKDO 的智能体角色：

  • **发现与诊断（Detection and diagnosis）**由 Analyzer 智能体完成：它使用 k8s-ai 调查集群状态、对问题分类并给出修复建议
  • **修复执行（Remediation）**由 Fixer 智能体完成：它执行安全变更，并对破坏性操作要求审批
  • **沟通（Communication）**由 Slack_Bot 智能体完成：它发布更新并处理审批工作流
  • **协调（Coordination）**由 Coordinator 智能体完成：它编排工作流并做高层决策

这种映射保留了自然的工作流结构，同时把职责分配给专门化智能体。

为什么是四个智能体，而不是一个？（Why four agents instead of one?）

正如第 3 章的简单 k8s-ai 系统所示，一个智能体理论上也能完成上面所有工作（除了 Slack 沟通）。那么为什么 MAKDO 要拆成四个智能体？主要原因包括：

  • 工具隔离（Tool isolation） ：Analyzer 不应拥有对集群的写权限（它只做只读诊断）。通过把 Analyzer / Fixer 分开，并用工具配置进行权限隔离来强制实现：Analyzer 只需 get pods、get deployments 这类只读工具即可；Fixer 需要修改配置，因此才应获得 apply manifest 之类工具访问。
  • 提示词清晰（Prompt clarity） ：每个智能体拥有聚焦的 system prompt（约 50 行），而不是用一个巨大 prompt（约 200 行）试图覆盖所有内容。
  • 独立测试（Independent testing） ：可以把诊断准确性（Analyzer）与修复安全性（Fixer）分开测试。
  • 并行演进（Parallel evolution） ：可以提升诊断能力而不影响修复逻辑，降低“改动带来风险”的耦合。

下面我们更深入讨论 Analyzer 与 Fixer 的拆分。

为什么要分离 Analyzer 与 Fixer？（Why separate the analyzer and fixer?）

这是争议最大的设计点。两个智能体都使用同一套 k8s-ai A2A 工具，为什么不合并？主要有三点原因：

  1. 通过角色分离实现安全（Safety through role separation）
  • Analyzer 的 prompt：“绝不做变更，只做诊断。”未来甚至可以给 Analyzer 发放只读凭证，以形成强安全边界（而不是仅依赖 prompt）。
  • Fixer 的 prompt：“需要审批的操作：delete、scale down、restart……”形成清晰心智模型：分析是安全的，修复必须谨慎。
  1. 不同的失败模式（Different failure modes）
  • Analyzer 失败：可能给出不完整或错误诊断，但它不会改变集群状态，因此坏诊断不会直接影响生产。
  • Fixer 失败：可能执行错误修复并直接修改线上资源，护栏不足时会导致宕机或数据丢失。

分离智能体让你可以把“可靠性”与“行动权限”独立调参。例如：分诊阶段运行一个更快但精度略低的 Analyzer（90% recall），而对高风险 Fixer 施加 99.9% 准确性要求并强制人审/审批。

  1. 现实世界访问控制模式（Real-world access control patterns）
    很多组织会给 DevOps 团队生产环境只读权限，以避免开发/排障过程中误伤生产；只有 SRE 或 on-call 工程师在需要热修或紧急操作时才拥有写权限。MAKDO 的拆分正是对这种访问控制模式的镜像。

缺点是增加了协调开销，但为了安全与清晰度，这个代价是值得的。

为什么要分离 Slack_Bot？（Why separate Slack_Bot?）

Coordinator 当然也可以直接发 Slack。但当引入多种沟通渠道、审批工作流、格式规范等之后，沟通逻辑会迅速复杂化。把这部分抽到 Slack_Bot 里，可以让它独立演进并封装复杂性，而 Coordinator 专注于协调本身。

工具访问边界（Tool access boundaries）

每个智能体的工具配置只提供它完成职责所需的工具。这样智能体更容易聚焦角色，也降低误用工具的可能性（攻击面/可用工具面更小）：

# Coordinator: Pure orchestrator, no operational tools beyond sub-agents
tools_dirs: [ "/path/to/memory" ]  # Only memory for state tracking

# Analyzer/Fixer: Kubernetes access via A2A
a2a_servers: [ { "url": "http://localhost:9999" } ]  # Same tools, different prompts

# Slack_Bot: Communication tools via MCP
mcp_tools_dirs: [ "src/makdo/mcp_tools" ]  # Only Slack access

这种“配置驱动的权限模型”也意味着：要改变智能体能力，只需要改 YAML，而不需要改代码。

扩展架构（Extending the architecture）

MAKDO 的设计支持通过增加专门化智能体来扩展能力。这里我们讨论如何加入新能力，举一个添加安全扫描智能体的例子。

要加入漏洞扫描与安全策略执行，可以按如下步骤：

  1. 在 coordinator.yaml 中定义新智能体：
agents:
  - name: "MAKDO_Security_Scanner"
    description: "Security vulnerability and compliance scanning agent"
    a2a_servers:
      - name: "kind-makdo-test"
        url: "http://localhost:9999"
    system_prompt: |
      You are the MAKDO Security Scanner.

      Responsibilities:
      - Scan container images for known vulnerabilities
      - Check pod security contexts
      - Verify network policies are in place
      - Report security findings to Coordinator

      Use k8s-ai tools to inspect cluster resources.
      Report findings in severity-ranked format.

2. 更新 Coordinator 的 prompt，把新智能体加入可用智能体列表：

Available agents:
  - agent_MAKDO_Analyzer
  - agent_MAKDO_Fixer
  - agent_MAKDO_Slack_Bot
  - agent_MAKDO_Security_Scanner  # New

Workflow: After Analyzer identifies issues, also call Security_Scanner
  to check for security implications before Fixer proceeds.

注意：如果你认为安全扫描属于“集群分析”的子领域，也可以把 Security_Scanner 作为 Analyzer 的子智能体来挂载。

  1. 无需代码改动（No code changes needed） ：AI-6 会自动发现新智能体并把它暴露为工具。

关键设计模式（Key design patterns）

MAKDO 架构展示了多个可迁移到其他多智能体系统的模式：

  • 工作流驱动拆解（Workflow-driven decomposition） ：按工作流阶段映射智能体，而不是按技术栈切分
  • 通过配置实现权限（Permission through configuration） ：工具访问边界决定智能体能做什么
  • Prompts 即策略（Prompts as policy） ：把运维规则编码进 system prompts
  • 协议封装（Protocol encapsulation） ：AI-6 封装 A2A 与 MCP 协议细节，你无需直接处理
  • 面向扩展的设计（Extensibility by design） ：新增能力就是新增工具与智能体

下一节将进一步讨论：如何使用 AI-6 的配置系统创建并部署这些智能体的实现细节。

实现这些智能体（Implementing the agents）

在定义好智能体角色并清晰划分其职责之后，我们现在转向实现。MAKDO 采用配置驱动（configuration-driven） 的方法：整个多智能体系统通过 YAML 配置文件来定义，而不是通过自定义代码实现。这种方法利用了 AI-6 强大的智能体框架，能够自动实例化智能体、发现工具并建立通信通道。

配置驱动的智能体实现（Configuration-driven agent implementation）

传统多智能体系统通常需要大量自定义代码来初始化智能体、配置工具，并建立智能体之间的通信。MAKDO 选择了不同路径：整个系统都定义在一个协调者配置文件里，并以内联方式定义子智能体。

MAKDO 的架构使用一个主配置文件（coordinator.yaml），它定义了以下内容：

  • 协调者智能体（coordinator agent） ：顶层编排者，带 system prompt 与工具访问权限
  • 所有子智能体以内联方式定义（All sub-agents inline） ：Analyzer、Fixer 与 Slack_Bot 都在协调者配置里定义
  • 工具分配（Tool assignments） ：每个智能体的工具访问通过 tools_dirs、mcp_tools_dirs 与 a2a_servers 指定
  • 通信协议（Communication protocols） ：通过 AI-6 的 AgentTool 模式隐式提供

这种单文件方式带来几个优势：

  • 原子化部署（Atomic deployment） ：整个系统配置集中在一个地方
  • 层级清晰（Clear hierarchy） ：父子关系显式可见
  • 无配置同步问题（No file synchronization issues） ：不会出现多个配置文件彼此不同步的风险
  • 版本控制更简单（Easier version control） ：只需追踪一个文件的系统变更

MAKDO 的主入口实现了健康检查循环与会话管理。我们来看看关键组件。

关键实现组件

配置加载（Configuration loading）

AI-6 的 Config.from_file() 读取 coordinator.yaml，并自动创建全部智能体：

from ai_six.agent.agent import Agent
from ai_six.agent.config import Config

def create_coordinator_config() -> Config:
    """Create coordinator agent config with sub-agents."""
    return Config.from_file("src/makdo/agents/coordinator.yaml")

这一行就会加载 Coordinator 智能体，并把所有内联子智能体实例化为 agent tools。

健康检查循环（Health check loop）

Coordinator 智能体会持续运行，按固定间隔发送健康检查请求：

def start_coordinator(coordinator: Agent, config: Dict[str, Any]):
    """Start the coordinator with health check loop."""
    logger = logging.getLogger("makdo")

    # Get check interval from environment or config (default: 60s)
    check_interval = int(os.getenv("MAKDO_CHECK_INTERVAL",
                                   config.get("monitoring", {}).get("check_interval", 60)))

    logger.info(f"Starting health check loop (interval: {check_interval}s)")

    try:
        while True:
            try:
                # Request health check from coordinator
                logger.info("🔍 Initiating cluster health check...")

                prompt = (
                    "Perform a comprehensive health check across all registered clusters. "
                    "Use the Analyzer agent to identify any issues, then use the Slack Bot agent "
                    "to report findings to the #makdo-devops channel. "
                    "If critical issues are found, use the Fixer agent to attempt remediation."
                )

                response = coordinator.send_message(prompt)
                logger.info(f"✅ Health check completed: {response[:200]}...")

该循环发送一段自然语言 prompt 来描述期望工作流，LLM 会依据 prompt 编排子智能体。注意：MAKDO 在这里是自治运行的，并不像聊天界面那样有“人类控制的请求-响应”流程。不过，人类仍可通过 Slack 监控与介入。Coordinator 智能体的响应仅被记录日志用于审计。

会话管理（Session management）

每次健康检查后，MAKDO 会清空对话历史，防止上下文溢出：

# CRITICAL: Clear session history to prevent context overflow
# Keep only system message - each health check cycle is independent
if len(coordinator.session.messages) > 3:
    logger.info(
        f"Clearing old messages (
            {len(coordinator.session.messages)} messages)"
        )
    system_message = coordinator.session.messages[0]
        if coordinator.session.messages else None
    coordinator.session.messages.clear()
    if system_message:
        coordinator.session.messages.append(system_message)
    logger.info(
        f"Session reset to {len(coordinator.session.messages)} message")

except Exception as e:
logger.error(f"Error during health check cycle: {e}")

# Wait before next check
time.sleep(check_interval)

这避免上下文窗口被历史健康检查填满。每个循环都被视为独立。如果需要长期记忆，可以通过外部存储（如数据库）实现。

主入口（Main entry point）

main 函数把所有部分串起来：

def main():
    """Main entry point - note: synchronous, not async."""
    load_dotenv()
    config = load_config()
    setup_logging(config)

    logger = logging.getLogger("makdo")
    logger.info("Starting MAKDO - Multi-Agent Kubernetes DevOps System")

    # Create coordinator with inline sub-agents
    coordinator = Agent(create_coordinator_config())
    logger.info("Coordinator and sub-agents created successfully")

    # Start the coordinator (runs health check loop)
    start_coordinator(coordinator, config)


if __name__ == "__main__":
    exit(main())  # Note: synchronous call, not asyncio.run()

代码位于 src/makdo/main.py：
github.com/PacktPublis…

该实现的关键特性包括：

  • 同步架构（Synchronous architecture） ：用 time.sleep() 而非 asyncio，以避免与 MCP 工具发生 event loop 冲突
  • 会话管理（Session management） ：每次健康检查周期后清理旧消息，防止上下文溢出（128k token 限制）与消息顺序错误
  • 健康检查循环（Health check loop） ：按可配置间隔持续监控集群

也要注意这段代码里没有什么：

  • 没有对子智能体做手动实例化
  • 没有工具发现或注册逻辑
  • 没有智能体间通信的显式搭建
  • 没有 MCP 或 A2A client 的显式配置

这些全部由 AI-6 根据协调者配置文件自动完成。这就是 AI-6 框架的价值主张：它可靠、静默地为 MAKDO 处理复杂细节。

工具发现与分配（Tool discovery and assignment）

AI-6 的 tool manager 会从多个来源自动发现工具。对 MAKDO 来说，工具如何分配到各智能体如下：

Coordinator agent：

# Only memory tools - pure orchestrator
tools_dirs: [ "/Users/gigi/git/ai-six/py/ai_six/tools/memory" ]
mcp_tools_dirs: [ "/Users/gigi/git/ai-six/py/ai_six/mcp_tools" ]
memory_dir: "data/memory"

# NO a2a_servers - delegates to Analyzer/Fixer for k8s operations
# NO Slack tools - delegates to Slack_Bot for communications

Analyzer agent（inline）：

agents:
  - name: "MAKDO_Analyzer"
    description: "Cluster health assessment agent"
    default_model_id: "gpt-4o"
    # Has A2A access to k8s-ai server
    a2a_servers:
      - name: "kind-makdo-test"
        url: "http://localhost:9999"
        timeout: 30.0
        api_key: "test-key"

Fixer agent（inline）：

  - name: "MAKDO_Fixer"
    description: "Safe cluster modification agent"
    default_model_id: "gpt-4o"
    # Has A2A access to k8s-ai server
    a2a_servers:
      - name: "kind-makdo-test"
        url: "http://localhost:9999"
        timeout: 30.0
        api_key: "test-key"

Slack_Bot agent（inline）：

  - name: "MAKDO_Slack_Bot"
    description: "User communication agent"
    default_model_id: "gpt-4o"
    tools_dirs: [ ]
    # Has MCP access to local Slack tools
    mcp_tools_dirs: [ "src/makdo/mcp_tools" ]

智能体拥有各自的工具集合，但它们也拥有各自独立的上下文。这就是会话隔离原则。

会话隔离（Session isolation）

MAKDO 中每个智能体都维护自己隔离的会话（session）与消息历史。当 Coordinator 调用 agent_MAKDO_Analyzer 时，Analyzer 看不到 Coordinator 的对话历史；它从一个新上下文开始，只包含：

  • 自己的 system prompt
  • 来自 Coordinator 的 message
  • 自己的工具目录（tool catalog）

这种会话隔离有重要影响。优势包括：

  • 减少 token 使用（Reduced token usage） ：子智能体不会携带父会话的完整上下文
  • 聚焦处理（Focused processing） ：每个智能体只围绕自己的任务与相关上下文推理（工具调用与返回）
  • 并行执行潜力（Parallel execution potential） ：独立会话可并行运行，尤其对 A2A 智能体
  • 更干净的关注点分离（Cleaner separation of concerns） ：智能体不会在上下文之间意外泄露信息

权衡包括：

  • 需要显式传递上下文（Context passing required） ：父智能体必须在消息里显式带上相关上下文
  • 默认无共享记忆（No shared memory by default） ：智能体不会自动共享状态（尽管可用 memory tools 实现）
  • 消息更冗长（Increased message verbosity） ：父智能体可能需要在多次子调用中重复上下文

对 MAKDO 而言，这种隔离是有利的：当 Coordinator 让 Analyzer 评估集群健康时，Analyzer 不需要知道 Fixer 或 Slack_Bot 的历史对话，它只需专注当前集群评估请求。

配置优先于代码（Configuration over code）

配置驱动的方法意味着，你可以在不改 Python 代码的情况下彻底改变 MAKDO 行为：

  • 新增智能体：在 agents 列表里增加条目
  • 调整工具访问：修改任一智能体的 tools_dirs、mcp_tools_dirs、a2a_servers 或 agents
  • 调整智能体行为：更新 system prompts
  • 切换 LLM 模型：改 default_model_id
  • 连接不同远程 AI 系统：更新 A2A server URL

关键要点（Key takeaways）

MAKDO 的实现展示了构建多智能体系统的若干关键模式：

  • 配置驱动架构（Configuration drives architecture） ：用 YAML 定义系统结构，而非写代码
  • 框架自动化（Framework automation） ：让 AI-6 处理智能体实例化、工具发现与通信
  • 工具抽象（Tool abstraction） ：子智能体通过 AgentTool 类在父智能体眼中表现为工具
  • 会话隔离（Session isolation） ：每个智能体维护独立对话状态
  • 最小权限原则（Principle of least privilege） ：每个智能体只拥有其所需工具
  • 配置带来可扩展性（Extensibility through configuration） ：通过编辑 YAML 增加能力，而不是写代码

这种方式显著降低了构建与维护多智能体系统的复杂度：整个 MAKDO 实现不足 150 行 Python 代码，其中绝大多数是日志与错误处理。真正的实现重心在配置文件中，使系统易理解、易修改、易扩展。但同时也需要强工具链与 schema 校验来保障配置质量。

用管理者智能体编排团队（Orchestrating the team with a manager agent）

MAKDO 中的 Coordinator 智能体充当中央编排者：在保持对系统状态与运维优先级的感知的同时，管理跨多个专门智能体的工作流。与依赖显式工作流定义与状态机（state machines）的传统编排系统不同，MAKDO 的 Coordinator 依靠 LLM 推理，根据现场情况动态协调智能体活动。

Coordinator 的 system prompt 提供指导原则，但具体调用哪些智能体、按什么顺序调用，由 LLM 根据上下文决定。

动态工作流执行（Dynamic workflow execution）

传统工作流引擎通常要求预定义工作流，例如：

detect_issue → analyze_issue → fix_issue → notify_humans

而 MAKDO 的 Coordinator 则在 system prompt 中接收高层的英文指导，例如：

Your primary responsibilities:

  1. Monitor multiple Kubernetes clusters for health and issues
  2. Coordinate between the Analyzer, Fixer, and Slack agents
  3. Make decisions on task prioritization and escalation
  4. Maintain awareness of ongoing operations across all clusters

随后，LLM 会基于具体情境决定合适的智能体调用序列。下面看几个基于场景的例子。

场景 1：周期性健康检查请求（Scenario 1: Periodic health check request）

MAKDO：每分钟调用一次 coordinator，请它“Check the health of kind-makdo-test cluster”。

Coordinator：

  1. 调用 MAKDO_Analyzer 智能体，消息为 “Analyze kind-makdo-test cluster health”
  2. 接收详细报告
  3. 调用 MAKDO_Slack_Bot 智能体发布结果
场景 2：检测到严重问题（Scenario 2: Critical issue detected）

User： “Production cluster has failing pods”

Coordinator：

  1. 调用 agent_MAKDO_Analyzer 做详细诊断
  2. 根据 Analyzer 报告评估严重性
  3. 调用 agent_MAKDO_Fixer 做修复
  4. 调用 agent_MAKDO_Slack_Bot 通知团队分析与修复结果

Coordinator 会基于 Analyzer 的发现、问题严重性、以及 system prompt 中编码的运维策略来自适应调整工作流。如果需要人类审批，MAKDO 会先等待 Slack_Bot 从 Slack 收到批准，再调用 Fixer 智能体。

决策点与分支（Decision points and branching）

Coordinator 的 system prompt 包含决策指导，LLM 会按这些指导做分支选择：

Decision-making guidelines:

  • Always assess cluster health before making changes
  • Prioritize critical issues (pods failing, services down) over warnings
  • Require human approval for destructive operations (delete, scale down)
  • Coordinate operations to avoid conflicts between clusters
  • Escalate to humans when automated fixes fail or are uncertain
  • ALWAYS post full detailed results to Slack for human visibility

这些指导形成若干决策点，使 LLM 选择不同路径。下面是一些例子。

例 1：安全操作 vs 破坏性操作（Example 1: safe versus destructive operations）

Analyzer 报告：“3 pods stuck in CrashLoopBackOff, may need deletion.”

LLM 的推理包含：

  • 删除是破坏性操作（按 guidelines）
  • 需要人类审批（按 guidelines）
  • 应先通知人类（按 guidelines）

执行路径如下：

  1. agent_MAKDO_Slack_Bot： “Report analysis and request approval”
  2. 等待人类回应
  3. 若批准：agent_MAKDO_Fixer，执行 “delete pods”
  4. agent_MAKDO_Slack_Bot： “Report remediation results”
例 2：自动修复 vs 升级（Example 2: auto-remediation versus escalation）

Analyzer 报告：“2 pods need restart, low-risk operation.”

LLM 的推理如下：

  • restart 是安全操作（不在 destructive list 里）
  • 不需要审批（按 Fixer 的 safe operations list）
  • 可以直接执行（按 guidelines）

执行路径如下：

  1. agent_MAKDO_Fixer： “Restart the 2 identified pods”
  2. agent_MAKDO_Slack_Bot： “Report both analysis and remediation results”

这种动态决策比硬编码工作流更灵活，同时仍遵循运维策略。

处理复杂多步操作（Handling complex multi-step operations）

有些运维场景需要多轮智能体交互、状态跟踪与条件逻辑。MAKDO 的 Coordinator 通过对话上下文与 LLM 推理来处理这些。

多集群协调（Multi-cluster coordination）

管理多个集群时，Coordinator 必须对操作进行排序以避免冲突：

User： “Check health of all production clusters and fix any issues”

Coordinator 执行：

  1. 对每个集群（production-east、production-west、production-central）：
    a. agent_MAKDO_Analyzer： “Analyze [cluster] health”
    b. 评估是否需要修复
    c. 若需要：agent_MAKDO_Fixer： “Fix issues in [cluster]”
    d. agent_MAKDO_Slack_Bot： “Post results for [cluster]”
  2. 汇总所有集群结果
  3. agent_MAKDO_Slack_Bot： “Post summary of all cluster operations”

Coordinator 通过对话上下文保持“哪些集群已经处理过”的状态；LLM 通过消息历史隐式跟踪状态。如果这变得过于复杂，MAKDO 可以演进成：以一个 meta-coordinator 为根智能体，启动多个 coordinator 智能体，每个 coordinator 自带自己的 Analyzer、Fixer 与 Slack_Bot。

条件式修复（Conditional remediation）

某些修复依赖前一步操作结果：

场景：镜像拉取失败（image pull failures）可能需要不同修复策略。

Coordinator 逻辑：

  1. agent_MAKDO_Analyzer： “Diagnose image pull failure”
  2. 若 Analyzer 报告： “Image not found in registry”
    → agent_MAKDO_Slack_Bot： “Escalate - invalid image reference”
  3. 若 Analyzer 报告： “Registry authentication failed”
    → agent_MAKDO_Fixer： “Apply image pull secrets”
    → agent_MAKDO_Analyzer： “Verify pods now pulling successfully”
  4. 若 Analyzer 报告： “Registry temporarily unavailable”
    → 延时后安排重试
    → agent_MAKDO_Slack_Bot： “Notify team of temporary issue”

这类条件逻辑来自 LLM 对 Analyzer 报告的推理，而不是代码里的显式 if/else。

重试与验证循环（Retry and verification loops）

当操作失败时，Coordinator 可以实施重试逻辑：

Fixer 报告： “Failed to restart pod, still in error state”

Coordinator 推理：

  • 初次修复失败（按 Fixer 报告）
  • guidelines 要求“自动修复失败则升级”
  • 升级前应先验证当前状态

执行：

  1. agent_MAKDO_Analyzer： “Re-analyze the specific failing pod”
  2. 评估新的诊断信息
  3. 决策：尝试替代修复 或 升级给人类
  4. agent_MAKDO_Slack_Bot： “Report situation and decision”

重试能应对瞬态问题；但系统也可能遇到持久失败，因此需要具备处理它们的能力。

错误处理与恢复（Error handling and recovery）

MAKDO 的智能体可能遇到多种失败模式。Coordinator 的 system prompt 含有隐式的错误处理指导，LLM 会应用这些指导。

智能体通信失败（Agent communication failures）

如果对子智能体调用失败（timeout、exception 等），AgentTool 会返回错误消息，Coordinator 会在工具结果中接收：

Tool：agent_MAKDO_Analyzer
Error： “Timeout connecting to k8s-ai server”

Coordinator 响应（由 system prompt 引导）：

  1. 识别通信失败
  2. agent_MAKDO_Slack_Bot： “Alert - cannot reach cluster analysis service”
  3. 决策：重试 OR 升级 OR 使用缓存数据

LLM 解释错误，并基于上下文选择合适的恢复策略。

部分失败（Partial failures）

当部分操作成功、部分失败时，Coordinator 会跟踪“部分进展”：

Fixer 报告： “Restarted 5 of 7 failing pods. 2 pods remain in error state due to resource constraints.”

Coordinator 响应：

  1. 识别部分成功（5/7 完成）

  2. 分析剩余问题（资源约束）

  3. agent_MAKDO_Analyzer： “Check cluster resource availability”

  4. 基于分析决定下一步：

    • 扩容节点（若资源耗尽）
    • 调整 pod 资源请求（若过度预留）
    • 升级给人类（若达到容量上限）

  5. agent_MAKDO_Slack_Bot： “Report partial success and next steps”

最复杂的一类失败之一是级联失败。

级联失败（Cascading failures）

Coordinator 必须处理“修一个问题暴露/引发更多问题”的情况：

初始问题：3 pods failing
修复尝试后：5 pods now failing

Coordinator 推理：

  • 情况恶化（3 → 5）
  • 修复可能引入新问题
  • 应停止自动修复
  • 需要人类介入调查

执行：

  1. agent_MAKDO_Slack_Bot： “CRITICAL: Remediation caused additional failures. Halting automation.”
  2. agent_MAKDO_Analyzer： “Full cluster diagnostic to identify root cause”
  3. agent_MAKDO_Slack_Bot： “Post detailed diagnostic results”
  4. 等待人类指导后再继续

这种防御式策略避免自动化让情况进一步恶化。

状态管理与协调（State management and coordination）

MAKDO 的 Coordinator 通过对话上下文与 memory tools 维护运维状态，从而感知进行中的操作与历史上下文。

在单次健康检查周期内，Coordinator 的消息历史就是它的工作记忆。LLM 会利用这些上下文回答 Slack 中的追问，并在 Analyzer 与 Fixer 工作期间保持对进行中操作的认知。注意：在一次健康检查周期里，协调者可能多次调用 Analyzer 与 Fixer。

用 memory tools 维护长期状态（Memory tools for long-term state）

对于需要跨会话持久化的状态，MAKDO 使用 AI-6 的 memory tools：

# Coordinator configuration
tools_dirs: [ "/Users/gigi/git/ai-six/py/ai_six/tools/memory" ]
memory_dir: "data/memory"

Coordinator 可以保存与检索结构化信息：

# Save cluster state after operations
Tool: save_memory
Arguments:
  key: "production-east-last-check"
  value: {
    "timestamp": "2024-10-06T14:30:00Z",
    "status": "degraded",
    "issues": 3,
    "fixed": 2,
    "pending_approval": ["pod-delete-operation-047"]
  }

# Later retrieve state
Tool: retrieve_memory
Arguments:
  key: "production-east-last-check"
Result: [saved state object]

这样 Coordinator 就能跨会话与重启保持认知与状态延续。

避免重复操作（Avoiding duplicate operations）

Coordinator 可以用 memory 记录最近的操作，避免重复执行：

User： “Fix production-east issues”

Coordinator 查询 memory：
Tool：retrieve_memory
Arguments：key: "recent-operations"
Result： “production-east remediation completed 5 minutes ago”

Coordinator 响应：
“Production-east was just remediated 5 minutes ago. Let me verify current status instead.”

执行：
agent_MAKDO_Analyzer： “Quick health check of production-east”

不同编排模式（Proactive versus reactive orchestration）

MAKDO 的 Coordinator 既可以以**反应式（reactive）模式运行（响应请求），也可以以主动式（proactive）**模式运行（自治监控）。

反应式模式：用户发起操作（Reactive mode – user-initiated operations）

反应式模式下，Coordinator 响应明确的用户请求：

  • User： “Check cluster health”
    → Coordinator 分析并汇报
  • User： “Fix the failing pods”
    → Coordinator 修复并汇报
  • User： “What's the status of production-west?”
    → Coordinator 查询状态并回复

该模式让人类直接控制“何时发生操作、如何发生”。

主动式模式：自治监控（Proactive mode – autonomous monitoring）

主动式模式下，Coordinator 可以根据 schedule 或触发器主动发起操作。这也是 MAKDO 当前运行模式：

# Periodic scheduled check
Every minutes:
1. agent_MAKDO_Analyzer: "Health check all registered clusters"
2. If issues found:
   a. Categorize by severity (CRITICAL, WARNING, INFO)
   b. For CRITICAL: Immediate remediation workflow
   c. For WARNING: Schedule remediation, notify humans
   d. For INFO: Log and include in next summary report
3. agent_MAKDO_Slack_Bot: "Post status update if changes detected"

该模式更“高级”，但也更依赖信任，因为 Coordinator 在自治运行。

混合方式：事件驱动协调（Hybrid approach – event-driven coordination）

混合方式融合反应式与主动式模式：

正常运行：

  • 每 5 分钟主动监控
  • 对集群事件/告警做反应式响应
  • 对常规问题自动修复
  • 对重大事件发 Slack 通知

当检测到严重问题：

  • 立即通知人类
  • 重大操作前等待审批
  • 按需提供详细状态更新

大多数真实系统都会采用混合方式。接下来，我们把注意力转向一个关键点：如何把“人”真正纳入闭环（human-in-the-loop） 。

集成人类反馈与控制通道（Integrating human feedback and control channels）

尽管 AI 智能体可以自动化许多 DevOps 任务，但在人类监督方面仍然不可或缺——尤其是在战略决策、复杂排障以及保持运维控制权方面。MAKDO 将 Slack 作为其主要的人机交互界面，使其能够实现实时通知、状态更新与审批工作流。注意：由于所有通信都通过一个智能体进行封装，因此把 Slack 替换为电子邮件或任何具备 API 的通信工具都很容易，也可以同时并行使用多种通信机制。

人机界面挑战（The human-AI interface challenge）

在 DevOps 场景中实现有效的人机协作，需要精心的界面设计，在自动化效率与人类控制之间取得平衡。界面必须做到以下几点：

  • 提供可见性（Provide visibility） ：人类需要对智能体正在做什么具备完全透明度
  • 支持控制（Enable control） ：人类必须能批准、拒绝或修改智能体动作，并能暂停或取消进行中的操作
  • 尽量减少打扰（Minimize interruption） ：不要用日常例行通知淹没人类
  • 支持自然沟通（Support natural communication） ：使用熟悉的工具与沟通模式
  • 保持上下文（Maintain context） ：保留对话历史与运维上下文

MAKDO 通过一个专门的 Slack_Bot 智能体来满足这些需求。它充当 AI 系统与人类运维人员之间的通信桥梁。

Slack_Bot 智能体架构（The Slack_Bot agent architecture）

Slack_Bot 是一个专门的通信智能体，通过 MCP 工具访问 Slack。与使用 A2A 执行 Kubernetes 操作的 Analyzer 与 Fixer 不同，Slack_Bot 使用 MCP 与 Slack 的 API 交互。

根据前面展示的 coordinator.yaml，Slack_Bot 配置如下：

agents:
  - name: "MAKDO_Slack_Bot"
    description: "User communication and notification interface agent"
    default_model_id: "gpt-4o"
    tools_dirs: [ ]
    # Slack_Bot uses local MCP server for Slack communication
    mcp_tools_dirs: [ "src/makdo/mcp_tools" ]
    system_prompt: |
      You are the MAKDO Slack Bot, the primary interface between the MAKDO system and human users.

      Your primary responsibilities:
      1. Send alerts and notifications to the designated Slack channel (#makdo-devops)
      2. Parse and process user commands from Slack messages
      3. Provide status updates and operation summaries
      4. Format technical information for human-readable display
      5. Handle approval requests for critical operations

      Message types and formatting:
      🚨 CRITICAL: Immediate attention required
      ⚠  WARNING: Issue needs attention
      i  INFO: Status update or information
      ✅ SUCCESS: Operation completed successfully
      ❌ FAILED: Operation failed
      ⏳ PENDING: Operation in progress

关键配置项是 mcp_tools_dirs: ["src/makdo/mcp_tools"]，它告诉 AI-6 在该目录下发现 MCP servers。

用 FastMCP 构建自定义 MCP server（Building a custom MCP server with FastMCP）

MAKDO 使用一个基于 FastMCP 的自定义 MCP server 来做 Slack 集成（我们前面已经讨论过 FastMCP）。相比手写完整 MCP 协议，这种方式要简单得多。

FastMCP Slack server

Slack MCP server 的实现展示了 FastMCP 如何简化协议处理。我们看一下 src/makdo/mcp_tools/slack.py 的关键组件（源码：
github.com/PacktPublis… ）：

1) Server 初始化与 token 加载（Server initialization and token loading）

FastMCP 只需一行就能创建 MCP server；token 管理同时支持环境变量与 .env 文件：

import os
import requests
from pathlib import Path
from mcp.server.fastmcp import FastMCP

# Initialize FastMCP server
mcp = FastMCP("Slack Tools", "")

# Get bot token from environment or .env file
bot_token = os.getenv('AI6_BOT_TOKEN')

if not bot_token:
    # Navigate from .../makdo/src/makdo/mcp_tools/slack.py to .../makdo/.env
    makdo_root = \
        Path(__file__).resolve().parent.parent.parent.parent
    env_file = makdo_root / '.env'

    if env_file.exists():
        with open(env_file) as f:
            for line in f:
                if line.startswith('AI6_BOT_TOKEN='):
                    bot_token = line.split('=', 1)[1].strip()
                    break

这是 MAKDO 专用工具，因此把 MAKDO 特有配置（例如 .env 路径）写死在这里是可以接受的。

2) 发送消息工具（Posting messages tool）

@mcp.tool() 装饰器会自动把函数注册为 MCP 工具，FastMCP 负责所有协议细节：

@mcp.tool()
def slack_post_message(channel: str, text: str) -> str:
    """Post a message to a Slack channel"""

    # Normalize channel name (add # prefix if missing)
    if not channel.startswith('#'):
        channel = f'#{channel}'

    # Call Slack API directly with simple requests library
    url = 'https://slack.com/api/chat.postMessage'
    headers = {'Authorization': f'Bearer {bot_token}'}
    data = {'channel': channel, 'text': text}

    response = requests.post(
        url, headers=headers, json=data, timeout=10)
    result = response.json()

    # Return LLM-friendly success/error messages
    if result.get('ok'):
        return f"✅ Message posted to {channel}"
    else:
        return f"❌ Failed to post: {result.get('error', 'unknown_error')}"

注意：这里用 requests 直接 HTTP 调用 Slack API。它不同于 AI-6 的 Slack 前端（后者使用官方 Slack SDK 与 slack_bot 库）。对 MAKDO 来说，直接调用 API 更简单，也足够用，避免引入不必要依赖。

3) 列出频道工具（Listing channels tool）

第二个工具用于发现 channels，使用相同装饰器模式：

@mcp.tool()
def slack_list_channels() -> str:
    """List all channels in the workspace"""

    url = 'https://slack.com/api/conversations.list'
    headers = {'Authorization': f'Bearer {bot_token}'}

    response = requests.get(url, headers=headers, timeout=10)
    result = response.json()

    if result.get('ok'):
        channels = result.get('channels', [])
        return '\n'.join([f"#{ch['name']}" for ch in channels])
    else:
        return f"❌ Failed to list channels: {result.get('error')}"
4) Server 入口（Server entry point）

运行脚本即可启动 MCP server，使两个工具都可供 AI-6 使用：

if __name__ == '__main__':
    mcp.run()

从这个实现可以看出，FastMCP 通过以下设计选择与关键能力简化了 MCP server 创建：

  • 基于装饰器的注册（Decorator-based registration） ：@mcp.tool() 自动注册函数为 MCP 工具，无需手写 JSON-RPC 处理
  • 自动类型推断（Automatic type inference） ：从函数签名与 docstring 提取参数类型与描述
  • 协议处理（Protocol handling） ：自动处理 MCP 协议细节（初始化、工具列表、工具执行）

对比“手写 MCP”，你通常还需要：

  • JSON-RPC 消息解析
  • 协议版本协商
  • 工具 schema 生成
  • 请求/响应处理
  • 错误序列化

FastMCP 全部自动处理，让你专注工具功能本身。

Slack server 会从环境变量或 .env 读取 bot token：

bot_token = os.getenv('AI6_BOT_TOKEN')

if not bot_token:
    # Try loading from .env file
    env_file = makdo_root / '.env'
    if env_file.exists():
# Parse .env file for AI6_BOT_TOKEN

这样生产环境用环境变量更灵活，开发环境用 .env 也方便。

两个工具都会返回 LLM 可理解的友好错误信息：

if result.get('ok'):
    return f"✅ Message posted to {channel}"
else:
    error = result.get('error', 'unknown_error')
    return f"❌ Failed to post to {channel}: {error}"

Slack_Bot 收到这些响应后，就可以对失败进行推理并采取合适动作（重试、升级或改用备选通道）。

通信模式（Communication patterns）

Slack MCP 工具的目的，是让 Slack_Bot 通过 Slack 与用户沟通。但 MAKDO 内部包含多种不同的通信模式，用于在“让人知情”和“避免信息过载”之间取得平衡。

通知层级（Notification hierarchy）

Coordinator 的 system prompt 要求它始终把完整详细结果发到 Slack：

CRITICAL WORKFLOW FOR SLACK REPORTING:
当你从 Analyzer 或 Fixer 收到结果时，你必须：

  1. 使用 agent_MAKDO_Slack_Bot 发布完整详细结果
  2. 包含全部技术细节：pod 名称、错误信息、执行的动作
  3. 不要总结或过滤——直接发布完整输出

这保证人类对智能体操作具有完全可见性。实际流程如下：
Coordinator 收到用户请求
→ 调用 agent_MAKDO_Analyzer
→ 获取详细分析报告
→ 调用 agent_MAKDO_Slack_Bot 发布完整分析
→ 若需要修复：调用 agent_MAKDO_Fixer
→ 获取详细修复报告
→ 调用 agent_MAKDO_Slack_Bot 发布完整修复结果

每一次重要操作都会在 Slack 产生带完整上下文的通知。

消息格式（Message formatting）

Slack_Bot 的 system prompt 包含格式化指导：

Message formatting for Slack:

  • 使用 Slack markdown 强调（*bold*、_italic_、`code`）
  • 对 kubectl 命令与 YAML 使用代码块
  • 包含相关链接与上下文
  • 信息简洁但要有足够内容
  • 详细技术讨论使用 thread
  • 严重告警时 @ 相关人员（@channel、@here）

下面是一个格式化消息示例：

🚨 *CRITICAL ISSUES DETECTED*

*Cluster:* kind-makdo-test
*Timestamp:* 2025-10-06 14:30:00

*Issues Found:*

🔴 *CRITICAL:*
• Pod: `default/failing-app-1`
  Status: ImagePullBackOff
  Error: Failed to pull image "nonexistent:latest"
  Restarts: 5

• Pod: `default/failing-app-2`
  Status: CrashLoopBackOff
  Error: Container exited with code 1
  Restarts: 12

*Recommendations:*
1. Verify image name and registry accessibility
2. Check application logs for crash cause
3. Consider rolling back to previous version

*Next Steps:* Remediation agent dispatched

这种格式让技术信息可快速扫读，同时保留所有关键细节。

语境化消息（Contextual messaging）

Slack_Bot 会根据严重性与上下文调整消息。示例：

例行操作：

i Cluster health check completed
kind-makdo-test: All systems nominal
5 pods running, 0 issues detected

告警：

⚠ WARNING: Resource utilization high
Cluster: production-east
CPU: 85% (threshold: 80%)
Memory: 78%
Recommend scaling up nodes

严重问题：

🚨 @channel CRITICAL: Production cluster degraded
Cluster: production-west
5 pods failing in user-facing services
Impact: API response times increased 300%
MAKDO remediation in progress
Human approval required for pod restarts

LLM 会根据 Analyzer 的严重性评估，选择合适 emoji、紧急标记与通知对象。

受限操作的升级模式（Escalation pattern for restricted operations）

MAKDO 对需要人类审批的操作采用“安全优先（safety-first）”策略：不会自动执行潜在破坏性操作；Fixer 会识别这些操作、跳过执行，并通过详细 Slack 通知升级给人类。

Fixer 的 system prompt 定义了哪些操作需要审批：

Operations requiring approval:

  • delete（pods、deployments、services）
  • scale down 操作
  • deployment 配置变更（镜像更新等）

当 Fixer 遇到这类操作时，会遵循如下模式：

Fixer workflow:

  1. 分析需要的修复动作（例如 deployment 镜像变更）
  2. 对照“需审批列表”检查操作类型
  3. 跳过该操作（不执行）
  4. 将详细理由报告给 Coordinator
  5. Coordinator 通过 Slack_Bot 把完整报告发布到 Slack

下面是一个 Slack 通知示例：

**Remediation Report**

**Skipped Actions:**
- Pod: default/image-pull-fail-abc123
  Action: Skipped - ImagePullBackOff requires deployment fix
  Reason: Image "nonexistent:v1.0.0" does not exist in registry
  Recommendation: Update deployment with valid image
  ⚠ Requires human approval to change deployment configuration

**Next Steps:**
Humans can manually execute the fix if appropriate:
kubectl set image deployment/image-pull-fail app=valid-image:v1.0.0

该升级模式确保破坏性操作永远不会自动执行。人类能获得完整上下文做决策，并在合适时手动执行修复。

未来可以进一步增强：用 memory tools 追踪待审批操作，用 Slack 命令处理实现 accept/reject，从而让审批变成交互式流程；但当前设计优先安全，通过强制升级来保证控制权。当 MAKDO 获得足够信任后，也可以允许 Fixer 自动执行其中一部分操作。

替代通信通道（Alternative communication channels）

虽然 MAKDO 使用 Slack，但同样模式可迁移到其他平台：

  • Microsoft Teams：用 Microsoft Graph API 实现 Teams 版本 MCP server 替换 Slack MCP server
  • Email：用 SMTP/IMAP 构建 MCP server 进行异步通知
  • PagerDuty：接入事故管理与 on-call 升级
  • Datadog：响应告警、创建新告警、用上下文丰富告警
  • SMS：用 Twilio MCP server 发关键告警短信

整体架构保持不变：只需替换 MCP server 实现，同时保留“通信智能体”模式。agent 的 system prompt 需要按平台特性做调整，但核心通知原则不变。

安全与访问控制（Security and access control）

人机通信通道需要严格的安全设计。

认证（Authentication）

Slack MCP server 使用 Slack OAuth bot token 做认证：

headers = {
    'Authorization': f'Bearer {bot_token}',
    'Content-Type': 'application/json; charset=utf-8'
}

bot token 应具备所需权限，例如：

  • chat:write：向频道发消息
  • channels:read：列出频道
  • channels:history：读取频道消息（用于命令处理）

频道限制（Channel restrictions）

Slack_Bot 的 system prompt 将其限制在指定频道内：

Communication channels:

  • #makdo-devops：主频道，用于告警与状态更新
  • Direct messages：用于敏感信息或审批请求
  • Thread replies：用于详细讨论与跟进

这可防止 bot 把运维数据发到不合适的频道。

命令授权（Command authorization）

生产环境应加入授权检查：

@mcp.tool()
def slack_post_message(channel: str, text: str, user_id: str = None) -> str:
    """Post a message to a Slack channel"""

    # Check if user is authorized for this channel
    if user_id and not is_authorized(user_id, channel):
        return f"❌ User {user_id} not authorized for {channel}"

    # Proceed with posting...

这样只有授权用户才能请求或批准关键操作。

可观测性与审计轨迹（Observability and audit trail）

Slack 通信天然形成审计轨迹：

  • 消息历史（Message history） ：Slack 保留完整对话历史
  • 线程讨论（Threaded discussions） ：相关消息按 thread 组织，便于上下文对齐
  • Reactions：人类可用表情确认或对消息做反应
  • 搜索（Search） ：Slack 搜索可快速定位过去操作
  • 导出（Export） ：Slack 数据可导出用于合规与分析

这种内建可观测性是使用成熟通信平台作为人机交互界面的重要优势。

我们已经探索了 MAKDO 的架构、智能体交互与人类集成模式，现在可以在进入系统实战 demo 之前总结关键洞察：MAKDO 的人机协作以“专用通信智能体”为中心——它处理所有与人相关的交互，同时保持运维智能体聚焦于各自领域；并通过 MCP 协议（借助 FastMCP 的简化实现）把外部平台（如 Slack）纳入工具生态。

系统通过“始终发布完整操作细节，不做摘要/过滤”的策略保持完全透明，并支持双向沟通：既有智能体到人的通知，也有人到智能体的命令。对于需要审批的操作，MAKDO 采用安全优先的升级模式：Fixer 识别受限操作、跳过执行，并给人类提供足够上下文，以便在合适时进行人工干预。

安全方面包含平台认证、频道限制与命令校验；通信平台又提供天然审计轨迹（消息历史与搜索）。这些模式共同支持一种有效的人机协作：在人类保持控制权的前提下，充分利用 AI 自动化能力——我们将在接下来的完整演示中看到这一点。

MAKDO 实战——完整 Demo 走读（MAKDO in action – a complete demo walk-through）

下面通过一个完整的端到端演示来看看 MAKDO 如何工作。本次走读会展示从问题发现到修复的全流程，并且在每一步都会产生真实的 Slack 通知。

Demo 环境与准备（Demo setup）

本次演示使用一个测试脚本，脚本会在集群中制造真实故障，并驱动 MAKDO 走完整工作流。我们先看环境搭建要点。

测试环境细节如下：

  • 集群（Cluster） ：kind-makdo-test（本地 Kubernetes 集群）
  • k8s-ai server：运行在 http://localhost:9999
  • Slack 频道（Slack channel） ：#makdo-devops
  • Coordinator：内联 Analyzer、Fixer 与 Slack_Bot 子智能体

测试脚本位置：
github.com/PacktPublis…

该测试会制造两类故障：

  • CrashLoop Pod：一个反复崩溃、退出码为 1 的 pod
  • ImagePullBackOff deployment：一个 deployment 引用不存在的容器镜像

这两类问题都非常常见，MAKDO 必须能够检测与修复（或正确升级给人类）。

制造集群问题（Creating cluster problems）

测试一开始会创建真实的 Kubernetes 资源，使其进入失败状态：

def create_crashloop_pod(self) -> bool:
    logger.info("💥 Creating crashloop pod...")
    yaml = """
apiVersion: v1
kind: Pod
metadata:
  name: crashloop-app
  namespace: default
spec:
  containers:
  - name: crash
    image: busybox
    command: ["sh", "-c", "echo 'Starting...'; sleep 2; exit 1"]
  restartPolicy: Always
"""
    # Apply to cluster...
def create_failing_deployment(self) -> bool:
    logger.info("💥 Creating failing deployment...")
    yaml = """
apiVersion: apps/v1
kind: Deployment
metadata:
  name: image-pull-fail
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: bad-image
  template:
    metadata:
      labels:
        app: bad-image
    spec:
      containers:
      - name: app
        image: nonexistent-registry.io/fake/image:v1.0.0
        imagePullPolicy: Always
"""
    # Apply to cluster...

创建完成后，测试会等待 15 秒让问题显现（pods 进入 CrashLoopBackOff 与 ImagePullBackOff 状态）。

Step 1——Demo 开始通知（Step 1 – demo start notification）

MAKDO 会先向 Slack 发送一条启动消息，宣布 demo 开始：

def send_demo_start_message(self):
    message = """
🤖 **MAKDO End-to-End Demo**

This demo showcases MAKDO's complete autonomous DevOps workflow:

**Test Scenario:**
1. ✅ Create cluster problems (crashloop pod, failing deployment)
2. 🔍 Analyzer detects issues using k8s-ai
3. 📊 Report findings to Slack
4. 🔧 Fixer attempts remediation
5. ✅ Report results to Slack

**Environment:**
- Cluster: kind-makdo-test
- Channel: #makdo-devops
- Demo started at: 2024-10-06 14:30:00
"""

    response = self.coordinator.send_message(
        f"Post this message to #makdo-devops Slack channel:\n\n{message}",
        self.coordinator.default_model_id
    )

内部发生的事情如下：

  • Coordinator 智能体收到消息
  • LLM 识别这是一个“发 Slack 消息”的任务
  • 生成工具调用：agent_MAKDO_Slack_Bot（携带 message）
  • Slack_Bot 接收 message
  • Slack_Bot 调用 slack_post_message MCP 工具
  • FastMCP Slack server 把消息发到 #makdo-devops
  • FastMCP Slack server 返回成功确认

这展示了完整委派链路：
User → Coordinator → Slack_Bot → MCP Tool → Slack API

下图展示了 Slack 中的 demo 启动消息：

image.png

图 9.1：Demo start message
MAKDO 在 #makdo-devops 频道发布 demo 启动公告，概述测试场景与环境。

Step 2——分析阶段（Step 2 – analysis phase）

接下来 MAKDO 分析集群以检测问题：

def run_analysis_and_post(self):
    analysis_request = """
Please perform the following tasks in order:

1. Use the Analyzer agent to check the health of the kind-makdo-test cluster
   and get the COMPLETE detailed analysis report
2. Immediately forward THE COMPLETE ANALYZER OUTPUT to the Slack agent with this
   message: "Post this complete cluster analysis report to #makdo-devops:
   [PASTE FULL ANALYZER OUTPUT HERE]"

CRITICAL: Do NOT summarize. Do NOT filter. Post the ENTIRE analysis report
exactly as the Analyzer provided it.
"""

    response = self.coordinator.send_message(
        analysis_request,
        self.coordinator.default_model_id
    )

内部工作流如下：

  1. Coordinator 把任务委派给 Analyzer 子智能体：
    Tool：agent_MAKDO_Analyzer
    Arguments：
{
  "message": "Check the health of kind-makdo-test cluster"
}

2. Analyzer 子智能体执行以下动作（通过 k8s-ai A2A 工具）：

  • 调用 k8s-ai 的 kubernetes_resource_health skill
  • 从集群读取真实 pod 状态
  • 对失败 pods 调用 kubernetes_diagnose_issue skill
  • 汇总并生成详细诊断报告
  1. Analyzer 返回一份完整报告，包含多个部分：目标集群、分析时间、按严重级别排序的问题、健康资源、修复建议与摘要。例如：
**Cluster Analysis Report**
Cluster: kind-makdo-test
Timestamp: 2024-10-06 14:30:15

**Issues Found:**

🔴 CRITICAL Issues:
- Pod: default/crashloop-app
  Status: CrashLoopBackOff
  Reason: Container repeatedly crashing
  Error: Container exited with code 1
  Restarts: 5
  Last State: Terminated (Error)

- Pod: default/image-pull-fail-abc123
  Status: ImagePullBackOff
  Reason: Failed to pull image
  Error: image "nonexistent-registry.io/fake/image:v1.0.0" not found
  Restarts: 0

- Pod: default/image-pull-fail-def456
  Status: ImagePullBackOff
  Reason: Failed to pull image
  Error: image "nonexistent-registry.io/fake/image:v1.0.0" not found
  Restarts: 0

**Healthy Resources:**
- kube-system pods: All running normally
- Core services: Operational

**Recommendations:**
1. crashloop-app: Investigate container startup issue, check application logs
2. image-pull-fail deployment: Verify image exists or update deployment with valid image
3. Consider deleting failing pods to allow fresh restart attempts

**Summary:**
- Total pods checked: 15
- Critical issues: 3
- Warnings: 0
- Healthy: 12

由于 LLM 非确定性，具体格式可能不同，但会包含全部相关细节。

  1. Coordinator 需要通知人类时，会把 Analyzer 的完整报告交给 Slack_Bot：
    Tool：agent_MAKDO_Slack_Bot
    Arguments：
{
  "message": "Post this complete cluster analysis report to #makdo-devops:\n[ENTIRE ANALYZER OUTPUT]"
}

5. Slack_Bot 调用 MCP 工具：
Tool：slack_post_message
Arguments：

{
  "channel": "makdo-devops",
  "text": "[ENTIRE ANALYZER OUTPUT]"
}

最终，Slack_Bot 使用 slack_post_message 把报告发到 Slack。

该流程展示了完整分析链路：
Coordinator → Analyzer → k8s-ai（A2A）→ Analyzer → Coordinator → Slack_Bot → MCP → Slack

下面是 Slack 中分析报告的截图：

image.png

图 9.2：Analysis report
上图为完整集群分析报告，报告检测到三个严重问题：一个 crashloop pod 与两个 ImagePullBackOff pod。

Step 3——修复阶段（Step 3 – remediation phase）

识别问题后，MAKDO 尝试修复：

def run_fixer_and_post(self):
    fix_request = """
Please perform the following tasks in order:

1. Use the Fixer agent to remediate the issues found in the kind-makdo-test
   cluster and get the COMPLETE detailed remediation report
2. Immediately forward THE COMPLETE FIXER OUTPUT to the Slack agent with this
   message: "Post this complete remediation report to #makdo-devops:
   [PASTE FULL FIXER OUTPUT HERE]"

CRITICAL: Do NOT summarize. Do NOT filter. Post the ENTIRE remediation report
exactly as the Fixer provided it.
"""

    response = self.coordinator.send_message(
        fix_request,
        self.coordinator.default_model_id
    )

内部工作流如下：

  1. Coordinator 把任务委派给 Fixer 子智能体：
    Tool：agent_MAKDO_Fixer
    Arguments：
{
  "message": "Remediate the issues found in kind-makdo-test cluster"
}

2. Fixer 执行以下动作（通过 k8s-ai A2A 工具）：

  • 对 crashloop pod：尝试删除以触发干净重启
  • 对 image-pull-fail pods：识别镜像问题；可能建议人工介入
  • 通过 k8s-ai 的 kubectl 工具执行安全操作
  • 每个动作后进行验证
  1. Fixer 返回完整修复报告，例如：
**Remediation Report**
Cluster: kind-makdo-test

**Actions Taken:**

1. **Pod: default/crashloop-app**
   - Action: Deleted pod to allow clean restart
   - Command: `kubectl delete pod crashloop-app -n default`
   - Result: ✅ Success
   - Details: Pod deleted successfully
   - Before: CrashLoopBackOff (5 restarts)
   - After: Terminating

2. **Pod: default/image-pull-fail-abc123**
   - Action: Skipped - ImagePullBackOff requires deployment fix
   - Reason: Image does not exist in registry
   - Recommendation: Update deployment with valid image

3. **Pod: default/image-pull-fail-def456**
   - Action: Skipped - ImagePullBackOff requires deployment fix
   - Reason: Image does not exist in registry
   - Recommendation: Update deployment with valid image

**Skipped Actions:**
- image-pull-fail deployment: Requires human approval to change image

**Verification:**
- Pods now running: 12
- Pods still failing: 2 (image-pull-fail)
- Issues resolved: 1
- Issues requiring human attention: 1

**Summary:**
- Total actions attempted: 1
- Successful: 1
- Failed: 0
- Requires approval: 1 (deployment image update)

4. Coordinator 以与分析阶段相同的模式，把完整修复报告委派给 Slack_Bot 发布到 Slack。

该流程体现 MAKDO 的安全优先策略：它修复了 crashloop 这种低风险问题，同时正确识别 image-pull 问题需要人类介入（变更 deployment 镜像引用）。

下面是另一次运行的报告截图：在那次运行中，LLM 判断两个失败都需要人类介入（要记住：LLM 会基于情境做智能决策，因此不会总是采取完全相同动作）：

image.png

图 9.3：Complete remediation report

在 MAKDO 完成“发现问题→分析→修复→通知用户”的完整流程后，demo 会结束。在生产部署中，它会持续运行，持续监控新问题。

Step 4——Demo 完成（Step 4 – demo complete）

最后，MAKDO 发送完成消息：

def send_demo_complete_message(self):
    complete_message = """
🎉 **MAKDO Demo Complete!**

**Results:**
✅ Multi-agent coordination successful
✅ Analyzer detected cluster issues via k8s-ai
✅ Fixer attempted remediation
✅ Full autonomous DevOps workflow demonstrated

**Architecture validated:**
- Coordinator orchestrated all agents
- Analyzer used A2A protocol to k8s-ai
- Fixer executed safe remediation
- Slack agent provided human visibility

Demo completed at: 2024-10-06 14:30:50
"""

    response = self.coordinator.send_message(
        f"Post this completion message to #makdo-devops:\n\n{complete_message}",
        self.coordinator.default_model_id
    )

Slack 中完成消息截图如下：

image.png

图 9.4：Demo complete
这是最终 demo 完成消息，用于总结结果并验证所有智能体已成功协同完成“检测→修复→汇报”。

关键观察（Key observations）

该 demo 验证了 MAKDO 的若干关键特性，总结如下：

  • 完全自治（Complete autonomy） ：从单次用户请求出发，MAKDO 无需额外人类输入即可完成整个工作流。Analyzer 检查集群；Slack_Bot 把分析发布到 Slack；Fixer 尝试修复；Slack_Bot 再发布结果；Coordinator 通过 LLM 推理编排一切，而不是靠固定脚本。
  • 协议集成（Protocol integration） ：演示有效使用两大协议。A2A 让 Analyzer 与 Fixer 连接 k8s-ai server 执行 Kubernetes 操作、发现集群状态并执行动作；MCP 让 Slack_Bot 通过 FastMCP Slack server 把所有报告发到 #makdo-devops，保证完全可见性。
  • 安全控制（Safety controls） ：MAKDO 全程安全运行：修复低风险问题（如删除 crashloop pod）；高风险动作（如 deployment 变更）需要审批；修复后检查验证集群状态；所有步骤通过 Slack 透明汇报。
  • 人类可见性（Human visibility） ：每个关键操作都会产生 Slack 消息：开始公告；覆盖全部三个失败 pods 的完整分析报告；详细说明执行/跳过动作的修复报告；最后以完成总结收尾。

人类无需盯日志或面板，只通过 Slack 就能观察完整流程。MAKDO 展示了：配置驱动的多智能体系统可以在保持人类监督与运维安全的前提下，处理真实的 DevOps 工作流与生产级基础设施。

总结（Summary）

本章以 MAKDO 为综合示例，演示了如何构建生产级多智能体 AI 系统。我们展示了配置驱动架构：整个多智能体系统通过 YAML 文件定义，而非自定义代码，从而大幅简化实现并提供强大能力。MAKDO 的四个专门智能体——Coordinator、Analyzer、Fixer 与 Slack_Bot——通过 AI-6 的 AgentTool 模式协作：子智能体以“工具”的形式出现，接收自然语言消息并返回完整响应。系统无缝集成两大协议：A2A 用于通过 k8s-ai 执行 Kubernetes 操作；MCP 用于通过 Slack 实现人类沟通；每个智能体则通过精心设计的 system prompts 被专门化，编码了领域知识、运维策略与安全控制。

实现层面验证了多智能体关键模式：

  • LLM 驱动编排：Coordinator 通过推理动态确定工作流，而不是预定义状态机
  • 会话隔离：每个智能体维护独立对话历史
  • 工具分配即权限控制：最小权限原则
  • 安全优先修复：区分可自动执行与需人审/审批的操作

端到端 demo 展示了 MAKDO 自治检测问题、尝试安全修复，并通过 Slack 完全透明地通知人类。该声明式（declarative）方法支持快速迭代：新增智能体或修改行为只需改 YAML，无需编程。

MAKDO 能帮助你管理基础设施，但它自身也是一个复杂系统。部署后，你需要能够测试、调试并排查它自身的问题。下一章将讨论如何在生产环境中安全可靠地运行多智能体系统。

avatar
文章
阅读
粉丝