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

虽然单智能体系统已经能完成非常惊艳的任务，但许多真实世界问题需要多个具备不同专长的智能体协同工作才能解决。本章聚焦于设计多智能体 AI 系统，使其能够协作解决任何单一智能体都难以胜任的复杂问题。

多智能体系统代表了智能体 AI 架构的下一个前沿。与其依赖一个智能体处理问题的所有方面，我们可以构建由多个专业化智能体组成的团队：每个智能体都有自己的专长、工具与职责。我们将探讨多智能体编排（orchestration）模式、智能体拆解（decomposition）策略、针对不同智能体角色的系统提示词（system prompt）设计、工具分配框架、多智能体环境下的上下文工程（context engineering），以及冲突解决机制（conflict resolution mechanisms）。我们还将通过为 AI-6 增加显式智能体支持，并集成 Agent-to-Agent（A2A）协议，把这些概念落到实处。

本章将覆盖以下关键主题：

• 什么是多智能体编排，它为什么重要？
• A2A 协议简介
• 设计协作式智能体工作流
• 多智能体系统中的冲突解决与角色分配

技术要求

要跟着实践，请参考 README 中的说明：
github.com/PacktPublis… 。

什么是多智能体编排？为什么重要？

到目前为止，本书大量讨论了“智能体工具调用循环（agentic tool-calling loop）”，并强调所有思考都由 LLM 完成。AI-6 引擎非常擅长支持这类智能体工作流，但“这些智能体到底是什么？”本节我们将用熟悉的方式精确定义 AI agent 的含义，扩展 AI-6 以显式支持智能体，讨论为什么多智能体系统重要，并探索如何有效编排多个智能体。

什么是 AI 智能体？

AI 智能体是 AI 系统中的一个组件：它把一些目标与知识编码在系统提示词（system prompt）里；它能访问一组工具以实现这些目标；它还拥有一个 LLM client，用来推理世界、推理目标以及推理如何使用工具。智能体通过接收用户消息（这里的“用户”可以是宿主 AI 系统，也可以是另一个智能体）与返回响应来与外界交互。智能体维护自己的内部状态（例如对话历史、工具使用历史等），并且只把最终响应返回给用户。

每个智能体都是一个自包含组件，并隐藏其内部状态——这一点意味着我们可以构建多智能体系统，而不会把单个 LLM 的上下文窗口塞爆。子智能体可以运行自己的 agentic loop，消耗大量 tokens，但不会污染父智能体的上下文。如果你觉得 AI 智能体听起来很像 AI-6 引擎，那你没错。下面我们看看如何扩展 AI-6，使其更显式地支持智能体。

为 AI-6 增加显式智能体

AI-6 引擎可以按如下方式“原样”构建多智能体系统：
1）定义一个 AI-6 agent 工具（agent tool）。
2）创建一个父级 AI-6 engine 实例，并把其他 AI-6 agent 作为工具提供给它。
3）父级 AI-6 engine 可以把其他 AI-6 agent 当作工具调用，以委派工作。

这当然可行，但仍有一些小缺口需要补上：

• 目前 AI-6 engine 没有 system prompt。这意味着每次调用 AI-6 agent tool 时，调用方都必须额外提供 system prompt（除了真实 user message 之外）。
• 定义与配置不同 AI-6 agent 并不轻松。
• AI-6 有全局工具配置，但智能体应该拥有自己的工具子集。

我们通过以下变更来解决这些问题：

• 将 Engine 重命名为 Agent（只是术语调整，不是功能改变）。
• 在 agent 配置中加入 system prompt。
• 在 agent 配置中加入 enabled_tools 与 disabled_tools 字段。
• 新增一个 AgentTool，用于封装一个 AI-6 Agent 实例。

除 “Engine → Agent” 的重命名主要是术语统一之外，其余改动都是“增量式”的：我们不会移除或修改现有能力与工作流。

将 Engine 重命名为 Agent

整个 backend.engine 包现在改名为 backend.agent。engine.py 改为 agent.py。Engine 类改为 Agent。代码与文档中所有 Engine 引用都替换为 Agent。

没什么特别的，本质就是一次全局 find-and-replace。

给 Agent 配置加入 system prompt

这个改动也很简单。在 backend/agent/config.py 的 Config 类中新增字段：

system_prompt: Optional[str] = None

注意它是可选的，因此保持向后兼容：依旧可以像以前一样在没有特定目标或知识的情况下与 LLM 交互。

给 Agent 配置加入 enabled_tools 与 disabled_tools

同样很简单。在 backend/agent/config.py 的 Config 类中新增字段：

enabled_tools: Optional[List[str]] = None
disabled_tools: Optional[List[str]] = None

语义是：

• 如果提供 enabled_tools，则只有这些工具可用；
• 如果提供 disabled_tools，则除了这些工具之外其余工具都可用；
• 如果两个都不提供，则所有工具都可用；
• 同时提供两个字段是错误。

这同样是向后兼容的，并为“每个智能体能用哪些工具”提供了完全控制。

新增 AgentTool：封装一个 AI-6 Agent 实例

这是最有意思的改动：新增一种工具类型，用来封装一个 Agent 实例。但 Agent 实例本身并没有新增“启动子智能体”的专用代码：LLM 会把可用的子智能体列表当作可用工具的一部分接收，然后它可以通过工具调用决定启动某个子智能体。每个子智能体的工具集合里也可能包含 Agent 工具，这意味着 LLM 与子智能体交互时，又可以决定再启动更下一层子智能体，如此递归。于是，我们可以得到一个任意深度的智能体树协同解决问题。

AgentTool 定义在 backend/object_model/agent_tool.py。拆解如下。

imports 反映了该工具依赖并交互的实体：

from typing import Callable, Optional
from backend.object_model import Tool, Parameter
from backend.agent.agent import Agent
from backend.agent.config import Config

AgentTool 继承 Tool 基类。构造函数接收一个 agent_config（包含创建 Agent 所需的全部信息）。它先创建 Agent 实例，并把 _on_tool_call_func 回调初始化为 None。agent 已经按配置带有 system prompt 以及 enabled/disabled 工具集合：

class AgentTool(Tool):
    """Tool that wraps an Agent and allows sending messages to it."""

    def __init__(self, agent_config: Config):
        """Initialize the AgentTool with a Config."""
        self.agent = Agent(agent_config)
        self._on_tool_call_func: Optional[
            Callable[[str, dict, str], None]] = None

接着定义该工具的参数：只有一个名为 message 的参数，用于发送给该 agent。然后调用 Tool 基类构造函数，传入 name、description、parameters 与 required（message 必填）：

# Create tool definition
parameters = [
    Parameter(
        name='message',
        type='string',
        description='The message to send to the agent'
    )
]

super().__init__(
    name=f"agent_{agent_config.name}",
    description=f"Send a message to the {agent_config.name} agent. {agent_config.description}",
    parameters=parameters,
    required={'message'}
)

set_tool_call_callback() 会在 agent 初始化时被调用，用于设置一个回调函数：当子智能体发生工具调用时，会触发该回调。该可选回调由宿主 AI 系统提供，使宿主能拦截并处理任意 agent 的工具调用：

    def set_tool_call_callback(
        self, callback: Optional[Callable[[str, dict, str], None]]
    ):

"""Set the callback function for tool calls made by this agent."""
        self._on_tool_call_func = callback

最后 run() 方法把 message 发送给 agent。agent 可能启动自己的 agentic loop，并最终返回响应：

    def run(self, message: str, **kwargs) -> str:

"""
Send a message to the agent and return the response.

Args:
    message: The message to send to the agent
    **kwargs: Additional arguments (ignored)
 
Returns:
    The agent's response
"""
        return self.agent.send_message(
            message, self.agent.default_model_id,
            on_tool_call_func=self._on_tool_call_func)

归根结底，从 AI-6 agentic loop 的视角看：子智能体就是可以被调用的工具，用于委派工作。LLM 会基于子智能体的描述来决定何时、如何调用它，就像决定调用任何其他工具一样。AgentTool 内部封装的是 AI-6 Agent 实例——对 LLM 来说无关紧要。

到这里，我们已经理解 AI-6 如何支持多智能体系统。现在是讨论“为什么多智能体如此重要”的好时机。

我们为什么需要多智能体系统？

理论上，一个足够强的单智能体可以处理任何任务。但随着任务复杂度上升，这种方式很快会碰到多项限制。

上下文窗口限制

LLM 的上下文窗口有限，只能在某一时刻考虑有限信息。对于需要大量背景知识、多步骤推理或大规模数据集的复杂任务，单智能体可能无法把所有必要信息塞进上下文窗口。当上下文变得过大时，模型性能会下降，尤其当上下文充满了对后续步骤大多无关的细节。

专业化挑战

不同任务需要不同领域能力。单智能体可能无法掌握所有必要技能，而带有巨大 system prompt 的“超智能体（uber-agent）”会让当下模型变得困惑。就像人类组织依赖专家分工一样，AI 系统也能从“专门化智能体”中获益：让每个智能体在自己的领域深耕（参见 www.moltbook.com 以理解 AI agent 如何模仿人类交互模式并据此自组织）。复杂任务可能需要上百个工具，单智能体会被工具数量淹没，导致糟糕的工具选择或幻觉能力（hallucination of capabilities）。

模型选择约束

不同任务适合不同模型。绑定单一模型的智能体无法在任务各环节都做到最优：有些任务需要 GPT-5 这类大模型的强推理能力，另一些则可以由更小、更快的模型完成。单体系统迫使你要么为简单任务“过度付费”，要么在复杂任务上表现不足。

多智能体系统通过让不同智能体聚焦任务的不同方面来解决这些限制：每个智能体拥有自己的 system prompt、工具集合与模型，在各自的上下文窗口内运行，并贡献其专长与工具能力，从而组合成整体解决方案。

认知负载分摊

多智能体系统把认知负载分摊到多个专门化智能体上，类似人类团队把复杂问题拆解并分派给领域专家。研究显示，顺序式多智能体处理相较单智能体方案能显著提升准确率，因为专门化智能体能在各自领域保持更聚焦的注意力。

容错与韧性

多智能体系统通过将职责分散在多个智能体之间，天然具备容错优势：当某个组件失败时，系统可以通过重试（不同参数）、路由到替代智能体等恢复策略继续运行。关键智能体可以冗余部署，从而在出现问题时实现无缝切换（failover）。

可测试性与可调试性

模块化结构使得定向测试、更好的可观测性与调试能力成为可能。每个智能体都可以像单元测试一样被隔离测试；智能体之间通信又提供了极强的可观测性。细粒度性能剖析允许独立监控每个智能体的资源消耗、执行时间与 token 使用。

如何编排多个智能体

既然我们理解了 AI agent 是什么以及多智能体的价值，那么就来探索多智能体如何有效协作的编排策略。智能体编排指对多个智能体的协调、通信与管理，以实现共同目标。你选择的编排方式会显著影响系统性能、可靠性与复杂度。

顺序编排（Sequential orchestration）

顺序编排是最简单、最直觉的模式：智能体按预定义顺序工作，每个智能体把输出传给链条中的下一个。这种线性工作流像传统流水线：每一阶段处理上一阶段的输出。流程预定义且可预测，但每个智能体仍可运行自己的内部 agentic loop 并按需调用工具。

顺序编排适合具有自然线性推进的任务，例如内容生产流程（调研→大纲→初稿→审阅→发布）、数据处理流水线，或任何每一步都逻辑依赖前一步完成的流程。

编排者（orchestrator）维护一个按顺序排列的智能体列表，迭代调用每个智能体，并携带前序结果累积输入。每个智能体的输出会成为下一个智能体的输入的一部分（见图 8.1）：

图 8.1：顺序编排

优点：

• 易理解、易实现
• 执行顺序可预测
• 易调试、易追踪问题
• 很多真实工作流天然契合

缺点：

• 顺序瓶颈：某个智能体失败会导致整个流程停滞
• 无并行机会
• 长链条可能很慢
• 结构僵硬，难以适应需求变化

顺序编排胜在简单与可预测，但当速度与容错成为重点时，线性结构会成为瓶颈。这时并行编排就能发挥优势：多个智能体同时工作，利用并发处理能力。

并行编排（Parallel orchestration）

并行编排指多个智能体同时运行：要么在同一输入上各自独立分析，要么在不同问题侧面并行处理，然后再合并结果。该模式最大化吞吐，并能为同一问题提供多样视角。并行编排有两种常见风格：
1）每个智能体独立处理相同输入并输出结果；编排者再聚合/综合这些输出，甚至可以用 LLM judge 打分选优。
2）编排者把输入拆成彼此独立的子任务并行运行，分配给不同智能体；智能体并行产出后，编排者再合并结果。

并行编排适合需要多路独立分析的任务，例如从不同角度做情感分析、多来源数据收集、竞品研究，或希望通过“共识”验证结果。

编排者会同时向多个智能体派发相同或相关任务，然后收集并综合它们的回答。这通常需要更复杂的结果聚合逻辑（见图 8.2）：

图 8.2：并行编排

优点：

• 最大化吞吐与速度
• 提供多视角
• 天然容错（某个智能体失败，其他仍可继续）
• 可引入共识机制提高可靠性

缺点：

• 需要结果综合逻辑
• 可能发生资源争用
• 可能产生冲突结果需要解决
• 错误处理更复杂

并行编排擅长最大化吞吐，但随着并发智能体数量上升，管理与结果综合可能变得难以驾驭。对于能自然拆解为可管理子任务、并且委派路径清晰的任务，分层编排能提供并行方式缺少的结构与清晰度。

分层编排（Hierarchical orchestration）

分层编排把智能体组织成树状结构：高层智能体协调并管理低层智能体，类似组织架构里“管理者委派给专家”。

该方式适合能自然拆解为子任务的复杂任务，如项目管理、研究协调，或任何需要多层抽象与委派的场景。

顶层协调智能体把复杂任务拆解并委派给专业智能体；这些专业智能体还可以继续委派给更细分的子专家，形成责任层级（见图 8.3）：

图 8.3：分层编排

优点：

• 自然任务拆解
• 责任边界清晰
• 架构可扩展
• 符合人类组织模式

缺点：

• 层级间通信开销
• 高层可能成为单点故障
• 任务拆解逻辑复杂
• 协调开销可能引入延迟

分层编排适合清晰可拆解的问题，但依赖预先定义的任务拆分，在动态、快速变化环境下可能吃力。当系统需要实时响应不可预测事件与条件变化时，事件驱动编排能提供分层方式难以匹敌的响应性。

事件驱动编排（Event-driven orchestration）

事件驱动编排让智能体对系统事件或状态变化作出反应，从而形成更动态、更敏捷的工作流。智能体订阅事件，并在满足条件或触发器发生时执行动作。

该模式适合响应式系统、监控场景、实时处理，或任何需要智能体响应变化而不是按预设流程推进的情况。

智能体注册对某些事件/条件的兴趣；当事件发生时，相关智能体被通知并采取行动。这需要事件系统或消息队列基础设施：

图 8.4：事件驱动编排

优点：

• 对变化高度敏感、响应快
• 智能体交互解耦
• 天然支持异步处理
• 随系统复杂度扩展性好

缺点：

• 异步特性导致调试困难
• 需要健壮事件基础设施
• 可能出现竞态条件（race conditions）
• 执行流更难预测

事件驱动编排的响应性很强，但其反应式特征意味着智能体仍运行在预定义角色与响应之内。对于真正复杂、开放式问题——需要让“解题方式”本身从智能体交互中涌现——协作式编排允许智能体通过动态协商与集体求解超越各自限制。

协作式编排（Collaborative orchestration）

协作式编排使智能体能够动态协商、通信与协调，以集体方式解决问题。该模式允许涌现行为（emergent behaviors）与自适应求解路径。

它适用于解法不预先确定的复杂开放问题，例如创意项目、复杂研究任务、或需要谈判与达成共识的场景。

智能体可以主动彼此沟通、提出方案、协商路径，并动态形成工作小组。这需要更复杂的通信协议与协调机制：

图 8.5：协作式编排

优点：

• 高度自适应、灵活
• 能应对意外情况
• 利用集体智能
• 允许涌现式解决方案

缺点：

• 实现与调试复杂
• 可能出现无限循环或死锁
• 结果难预测
• 需要更复杂的协调协议

协作式编排提供了最强的灵活性与适应性，但其复杂度对许多实际应用来说可能过高。现实中，大多数成功的多智能体系统并不会依赖单一编排模式，而是结合多种模式的优势，构建贴合自身需求的稳健高效方案。

混合编排（Hybrid orchestration）

真实系统往往从多种编排模式的组合中获益。例如：主流程用顺序编排，而在特定验证环节用并行编排；或采用分层协调，并在异常处理上引入事件驱动响应：

图 8.6：混合编排

我们已经介绍了多种编排策略。接下来看看如何决定某个场景下哪种策略最合适。

设计考量

选择编排策略时，重点考虑以下因素：

• 任务复杂度（Task complexity） ：简单线性任务偏向顺序编排；复杂多面问题可能需要分层或协作式编排
• 性能要求（Performance requirements） ：如果速度关键，并行编排有帮助；若一致性更重要，顺序处理可能更合适
• 资源约束（Resource constraints） ：考虑每种方式的计算与内存开销，尤其是并行与分层模式
• 容错需求（Fault tolerance needs） ：事件驱动与并行通常比顺序更具容错性
• 调试与维护（Debugging and maintenance） ：顺序编排最易调试；协作式编排最难

成功的多智能体编排关键在于：让编排模式匹配你的具体用例需求，并准备好随着需求演进进行调整。当然，你也要把每种方式的缺点以及它们叠加后的影响考虑进去，并尽可能缓解。例如：

• 顺序编排：增加重试机制与超时避免瓶颈
• 并行编排：增加 judge agent 解决冲突
• 分层编排：对关键智能体增加冗余
• 事件驱动编排：增加日志与 tracing 提升可观测性
• 协作式编排：限制智能体交互次数避免无限循环

现在我们已经对多智能体编排模式有了扎实理解，接下来我们将探索：智能体如何使用 A2A 协议进行高效通信。

A2A 协议简介

编排模式定义了智能体之间的高层协调策略，但要构建有效的多智能体系统，还需要健壮的通信机制，使智能体能够交换信息、协调活动，并实现无缝协作。A2A 协议（a2a-protocol.org/latest/）为 AI 智能体跨不同系统通信与协作提供了标准化框架，带来的能力也超出了 MCP 的设计目标。

A2A 协议围绕若干核心参与者与概念构建，以支持更复杂的智能体交互。在其基础层面，有三个关键参与者：发起请求的 user（人类或 AI 智能体）、代表用户进行通信的 A2A client（客户端智能体），以及处理消息与任务并返回结果的 A2A server（远程智能体）。这形成了一个结构化但灵活的通信模型，既能支持简单交互，也能支持复杂的多轮协作。

A2A 协议的核心组件

A2A 协议由几个基础要素组成，这些要素协同工作以实现高级的智能体交互：

• Agent card：描述智能体能力的 JSON 元数据，支持自动发现与能力匹配
• Task：带唯一标识符的有状态工作单元，用于追踪长时间运行的操作与多轮交互
• Message：客户端与智能体之间的单次通信轮次，支持丰富内容交换
• Part：内容容器，可承载不同类型数据（文本、文件或数据），实现与模态无关（modality-independent）的通信
• Artifact：任务执行期间产生的可交付输出（如 PDF 或图片），为智能体交互提供“可落地”的产物

下面是我在本地运行的 k8s-ai A2A server 的 agent card：

% http -b GET http://localhost:9999/.well-known/agent-card.json
{
    "capabilities": {
        "streaming": true
    },
    "defaultInputModes": [
        "text/plain"
    ],
    "defaultOutputModes": [
        "text/plain"
    ],
    "description": "Kubernetes AI assistant with kubectl access for context: kind-k8s-ai",
    "name": "k8s-ai Agent",
    "preferredTransport": "JSONRPC",
    "protocolVersion": "0.3.0",
    "security": [
        {
            "BearerAuth": []
        }
    ],
    "securitySchemes": {
        "BearerAuth": {
            "scheme": "bearer",
            "type": "http"
        }
    },
    "skills": [
        {
            "description": "Execute kubectl commands and provide Kubernetes cluster insights, troubleshooting, and management",
            "examples": [
                "show me all pods",
                "what is the status of the cluster?",
                "describe the nginx deployment",
                "get service endpoints",
                "check node health",
                "troubleshoot pending pods"
            ],
            "id": "kubectl_operations",
            "name": "Kubernetes Operations",
            "tags": [
                "kubernetes",
                "kubectl",
                "cluster",
                "pods",
                "deployments",
                "services"
            ]
        }
    ],
    "supportsAuthenticatedExtendedCard": true,
    "url": "http://127.0.0.1:9999/",
    "version": "1.0.0"
}

理解了 A2A 协议的核心组件后，我们来讨论它的通信机制。

A2A 通信机制

A2A 协议支持多种交互模式，以适配不同用例：

• 请求/响应（轮询）（Request/response (polling)） ：用于简单消息交互的传统同步通信
• SSE 流式（Streaming with SSE） ：用于持续任务与实时更新的实时通信
• 推送通知（Push notifications） ：用于事件驱动工作流的异步通知

A2A 基于 HTTP(S) 作为传输，并使用 JSON-RPC 2.0 作为 payload 格式，因此基础熟悉但能力强大。与传统协议不同，A2A 是专门为“需要跨长时协作过程维持可追踪的有状态交互”的自治智能体而设计的。

为 AI-6 增加 A2A 支持

目前，AI-6 通过一个 A2A tool 来提供 A2A 支持：该工具可以用来调用实现了 A2A 协议的远程智能体。从概念上看，它与 MCPTool 和 AgentTool 类似：把与外部系统的复杂交互封装在一个简单的工具接口背后。

将 A2A client 能力集成到 AI-6

AI-6 中的 A2A 集成采用分层架构，同时提供“基于工具的同步访问”和“基于消息的异步通信能力”。整个集成由四个主要组件组成，它们协同工作以实现无缝的 agent-to-agent 通信。我们不会深入每个组件的细节（它们相当复杂），但会概览其职责与在整体架构中的位置；你可以通过源码链接进一步阅读。

• A2A client（github.com/PacktPublis…）：基础组件，负责与远程 A2A agent 的直接通信。它通过拉取 agent card 做智能体发现，建立认证连接，并提供实时通信所需的流式消息能力。
• A2A manager（github.com/PacktPublis…）：单例协调器，管理全部 A2A 基础设施的生命周期。它处理初始化、维护 client registry、协调 message pump 做异步操作，并确保资源正确清理。集中式管理能避免资源泄漏，并在系统范围内提供一致的状态管理。
• A2A message pump（github.com/PacktPublis…）：后台运行，处理长对话与任务管理。它维护持久状态、追踪活跃任务，并提供将流式响应与 AI-6 消息注入系统集成所需的异步基础设施。
• A2A executor（github.com/PacktPublis…）：提供清晰的抽象层，负责桥接同步工具执行与异步 A2A 操作的复杂性。它封装了事件循环检测、线程安全执行管理等逻辑，并为 A2A skill 执行提供一个简单的同步接口。
• 配置集成（github.com/PacktPublis…）：确保 A2A server 能与其他工具一起在 agent 配置中声明，从而通过声明式配置文件完成远程 agent 连接的配置。

这套架构让 AI-6 agent 能在保持熟悉的“工具调用接口”的同时，与远程 A2A agent 无缝交互，等价于把同步工具执行与异步智能体通信模式桥接到一起。

下图展示了 A2A 在 AI-6 内部的通信流：

图 8.7：A2A 通信流概览

我们不会深入每个组件的内部细节（它们确实复杂，且需要对 A2A 协议与 Python async 编程有较深理解）。不过，我们会聚焦在 AI-6 中使用 A2A 最关键的部分：A2ATool 类。

A2ATool 类

A2ATool（github.com/PacktPublis…）继承 Tool 基类，并为 A2A agent 提供一个干净、简单的接口。imports 反映了该工具依赖并交互的实体：AgentSkill 包含 skill 的 name 与 description，用于生成工具定义；AI-6 对象模型里的 Tool 与 Parameter 用于定义工具接口；A2AManager 提供对 executor 的访问，而 executor 承担了所有复杂的 A2A 协调：

from a2a.types import AgentSkill
from backend.object_model.tool import Tool, Parameter
from backend.a2a_client.a2a_manager import A2AManager

构造函数接收 server_name 字符串与一个 AgentSkill 对象。每个 A2A server 可以有多个 skills。AI-6 的 A2A 支持会为每个 server 的每个 skill 创建一个独立工具：

class A2ATool(Tool):
    """Tool that communicates with A2A (Agent-to-Agent) servers using async-to-sync pattern."""

    def __init__(self, server_name: str, skill: AgentSkill):
        """Initialize from A2A skill information.

        Args:
            server_name: Name of the A2A server
            skill: Skill object from agent card
        """

A2A skills 不接收结构化参数：skill 的输入是自然语言消息，输出也通常是自然语言消息（当然 A2A server 还可能产出 artifacts）。此外，你可能希望通过同一 skill 与多个 A2A task 交互，因此工具定义了两个标准参数：输入文本 message，以及可选的已有 task_id：

         self.server_config = server_config
        self.skill_name = skill.name
     
        # A2A skills are conversational - create standard parameters
        parameters = [
            Parameter(
                name='message',
                type='string',
                description=f'Natural language request for the `{skill.name}` skill'
            ),
            Parameter(
                name='task_id',
                type='string',
                description='Optional: ID of existing task to send message to'
            )
        ]
     
        required = {'message'}  # message parameter is required, task_id is optional
     
        super().__init__(
            name=f"{server_name}_{skill.name}",
            description=skill.description,
            parameters=parameters,
            required=required
        )
     
        self.server_name = server_name
        self.skill_name = skill.name

run() 方法因为有 A2AExecutor 抽象而非常简单：所有复杂的 async-to-sync 桥接逻辑都由 executor 处理：

     def run(self, **kwargs) -> str:
        """Execute the A2A skill using the A2AExecutor."""
        task_id = kwargs.get('task_id')
        message = kwargs.get('message', '')
     
        executor = A2AManager.get_executor()
        if not executor:
            return "Error: A2A not initialized. Please configure A2A integration."
     
         return executor.execute_skill(
            self.server_name,
            self.skill_name,
            message,
            task_id
        )

这种清晰的关注点分离让 A2ATool 易理解、易测试、易维护，同时把复杂的异步协调逻辑集中在 A2AExecutor 组件中。

配置与设置

在 AI-6 中设置 A2A 集成只需要极少配置。A2A server 会与其他工具一起在 agent 配置中声明：

# config.yaml
a2a_servers:
  - name: "k8s-ai"
    url: "http://localhost:9999"
    timeout: 30.0

tool manager（github.com/PacktPublis…）会在启动时自动发现 A2A agent：拉取 agent card，并为每个 skill 创建 A2ATool 实例。无需手动注册工具。

A2A 工具发现流程

下面的序列展示 A2A server 如何在 AI-6 中变成可用工具：

图 8.8：A2A 工具发现流程概览

该发现流程会在 AI-6 agent 初始化期间自动发生：Tool Manager 读取 A2A server 配置，通过 A2A Manager 确保每个 client 存在，然后从每个远程 server 拉取 agent card。随后处理 agent card 的 skills 数组，为每个 server 的每个 skill 创建一个独立的 A2ATool 实例。对前面展示的 k8s-ai server 来说，这将创建一个名为 k8s-ai_kubectl_operations 的工具，AI-6 agent 可以用自然语言请求调用它来与 Kubernetes 交互。

一旦被发现，A2A skills 就变成普通的 AI-6 工具，agent 可以通过标准工具调用机制调用它们，从而无缝桥接本地与远程智能体能力。

现在我们已经深入介绍了 A2A 协议，接下来我们切换话题，讨论如何设计协作式智能体工作流。

设计协作式智能体工作流

在本章前面，我们讨论了不同的智能体编排（orchestration）范式。现在，我们来探讨如何为多智能体系统设计有效的工作流。设计协作式智能体工作流，涉及把复杂任务拆解为可管理的子任务、为每个智能体分配合适角色，并建立清晰的通信协议。我们先回答一个最基础的问题：如何把复杂任务划分为由多个智能体组成的流水线？

智能体拆解策略

多智能体系统设计中最关键的决策之一，就是如何把复杂任务拆解成可管理的智能体角色。有效拆解需要识别自然边界：在这些边界上，不同类型的专长、工具或职责可以被清晰分离。下面是关键策略与实用示例。

按领域专长拆解（Decomposition by domain expertise）

最直觉的方法，是按专业知识领域来划分智能体，类似人类团队按专长领域组织。

下面是一个软件开发流水线示例：

图 8.9：软件开发流水线

该工作流把软件开发流程拆分为三个专门的 AI 智能体——需求（requirements）、开发（development）与测试（testing）——每个智能体都有量身定制的 system prompt 与工具。需求智能体分析用户需求并产出规格说明，然后交给开发智能体实现干净代码，再流转给测试智能体用全面测试套件验证。这个模块化链路模仿了人类“专家孤岛”的分工方式，实现高效、领域聚焦的自动化。

按流程阶段拆解（Decomposition by workflow stage）

围绕流程的顺序阶段组织智能体，每个智能体负责整体工作流的某一个阶段。

下面是一个内容生产流水线示例：

图 8.10：内容生产流水线

该内容生产流水线顺序使用五个专门 AI 智能体：Research 负责收集资料，Planning 负责结构化大纲，Writing 负责生成草稿，Editing 负责质量打磨，Publishing 负责发布并接入分析。每个智能体使用领域特定工具，把更“精炼”的输出交接给下一环，端到端自动化效果类似人类编辑团队。模块化设计保证每个阶段都有聚焦的专业能力。

按能力模式拆解（Decomposition by capability pattern）

按基础能力而不是领域知识来组织智能体，从而得到更可复用、更灵活的架构。这些看起来可能更像“工具”而不是完整智能体，但每种能力都具备足够细腻与复杂性，值得用专门智能体承载。

下面是一个数据分析系统示例：

图 8.11：一个数据分析系统

Collector 智能体从多源摄取数据，Processor 智能体做转换与清洗，Visualizer 智能体生成图表或告警等输出（见图 8.11）。通过聚焦基础能力而非领域，流水线可以在无需专门再训练的情况下灵活处理不同工作负载。每个智能体顺序链式交付输出，实现端到端自动化。

这些拆解策略与本章前面讨论的编排模式是对齐的：流程阶段拆解与顺序编排天然契合；领域专长拆解自然支持分层编排；并行编排则能实现校验与共识机制。

拆解决策框架

决定如何拆分复杂任务时，可以问自己这些问题：

• 自然边界（Natural boundaries） ：任务天然会在哪些阶段或领域断开？
• 工具聚类（Tool clustering） ：哪些工具天然会聚在一起服务某类子任务？
• 上下文需求（Context requirements） ：需要哪些不同类型的上下文或专长？
• 并行机会（Parallelization opportunities） ：哪些子任务可以并发执行？
• 错误隔离（Error isolation） ：你希望把失败限制在哪些边界内，避免级联效应？

下面是另一个“市场研究报告”的决策过程示例：

图 8.12：制作市场研究报告

该示例展示：通过围绕三个设计问题（自然任务边界、工具分组、所需上下文），把一个“制作市场研究报告”的复杂任务拆解为四个专门智能体。每个问题都会进一步细化采集、分析、写作与设计智能体的角色，明确它们做什么、用什么工具、需要什么专长。最终形成一个四智能体流水线，交接清晰、重叠最小，更易扩展与复用。

既然我们已经讲完如何用多个智能体“分而治之”，下面把注意力转到每个智能体的 system prompt 设计。

System prompt 设计模式

在多智能体系统中，system prompt 极其关键：它定义了每个智能体的“人格”、专长、约束与协作模式。我们将看一些针对不同智能体类型的成熟模板与模式。

先从专家型智能体开始。

专家型智能体模板（The specialist agent template）

下面是一个通用模板，用于创建角色与职责清晰的专家智能体。注意：这里不指定 tools，因为 tools 会在调用智能体时单独提供：

You are a [DOMAIN] specialist agent in a multi-agent system.

EXPERTISE:

• Your primary domain is [SPECIFIC_EXPERTISE]
• You excel at [KEY_CAPABILITIES]
• You have deep knowledge of [KNOWLEDGE_AREAS]

RESPONSIBILITIES:

• [PRIMARY_RESPONSIBILITY_1]
• [PRIMARY_RESPONSIBILITY_2]
• [PRIMARY_RESPONSIBILITY_3]

COMMUNICATION STYLE:

• Be precise and technical when discussing [DOMAIN] topics
• Always explain your reasoning and cite sources when possible
• Ask clarifying questions if requirements are ambiguous
• Collaborate respectfully with other agents

CONSTRAINTS:

• Only work within your area of expertise
• Escalate out-of-scope requests to appropriate agents
• Always validate inputs before processing
• Maintain focus on [SPECIFIC_FOCUS_AREA]

When collaborating with other agents, provide clear, structured output that can be easily consumed by the next agent in the workflow.

下面是一个数据分析专家的例子：

You are a Data Analysis specialist agent in a multi-agent system.

EXPERTISE:

• Your primary domain is quantitative data analysis and statistical modeling
• You excel at finding patterns, trends, and insights in complex datasets
• You have deep knowledge of statistics, machine learning, and data visualization

RESPONSIBILITIES:

• Process and clean raw data from various sources
• Perform statistical analysis and identify significant patterns
• Create data models and predictive analyses
• Generate actionable insights and recommendations

COMMUNICATION STYLE:

• Be precise and cite statistical significance when making claims
• Always explain your methodology and assumptions
• Ask for clarification on analysis objectives and success metrics
• Present findings with appropriate confidence intervals

CONSTRAINTS:

• Only analyze data that has been properly validated
• Escalate data quality issues to the Data Collection agent
• Focus on statistical rigor over speed
• Maintain objectivity and avoid confirmation bias

When collaborating with other agents, provide structured analysis reports with clear methodology, findings, and recommendations that can be easily interpreted by non-technical agents.

专家智能体是“干活的专家”。但还需要有人（也是一个智能体）去协调这些专家，这就需要不同的 prompt。

协调型智能体模板（The coordinator agent template）

协调智能体的 prompt 聚焦于协调与编排：整体决策过程、委派原则、冲突解决等，并且通常包含需要协调的智能体列表：

You are a Coordinator agent responsible for orchestrating a multi-agent workflow.

ROLE:

• Decompose complex requests into subtasks for specialist agents
• Coordinate communication and handoffs between agents
• Synthesize results from multiple agents into coherent outputs
• Monitor progress and handle exceptions

DECISION-MAKING PROCESS:

1. Analyze the incoming request for scope and requirements
2. Identify which specialist agents are needed
3. Create a workflow plan with clear handoffs
4. Monitor execution and adjust as needed
5. Integrate specialist outputs into final deliverable

DELEGATION PRINCIPLES:

• Match tasks to agent expertise and available tools
• Provide clear, specific instructions to each agent
• Define success criteria and quality standards
• Set appropriate timeouts and escalation paths

CONFLICT RESOLUTION:

• When agents provide contradictory information, gather additional context
• Escalate unresolvable conflicts to human oversight
• Make decisions based on agent confidence levels and expertise match
• Document resolution rationale for future reference

QUALITY ASSURANCE:

• Validate that each subtask has been completed satisfactorily
• Ensure consistency across agent outputs
• Perform final integration and formatting
• Conduct overall quality review before delivery

AVAILABLE AGENTS:
[LIST_OF_SPECIALIST_AGENTS_AND_CAPABILITIES]

Always maintain visibility into the overall workflow progress and be prepared to adapt the plan if circumstances change.

下面是一个例子：协调智能体管理一个安全分析智能体（专家）与一个 test runner 智能体（校验器），生成高质量报告：

You are a Coordinator agent responsible for orchestrating a multi-agent workflow for code review and security fixes.
ROLE:
• Decompose complex code review requests into subtasks for specialist agents
• Coordinate communication and handoffs between agents
• Synthesize results from multiple agents into coherent outputs
• Monitor progress and handle exceptions
DECISION-MAKING PROCESS:

1. Analyze the incoming code review request for scope and requirements
2. Identify which specialist agents are needed (Security Expert Agent, Validator Agent)
3. Create a workflow plan: Security Expert → Validator → Integration
4. Monitor execution and adjust as needed
5. Integrate specialist outputs into final deliverable
   DELEGATION PRINCIPLES:
   • Match tasks to agent expertise: Security Expert for vulnerability analysis/fixes, Validator for testing/validation
   • Provide clear, specific instructions to each agent with code snippets and criteria
   • Define success criteria: fixes must pass all tests, no new vulnerabilities introduced
   • Set appropriate timeouts and escalation paths
   CONFLICT RESOLUTION:
   • When agents provide contradictory fixes/results, gather additional context or re-run analysis
   • Escalate unresolvable conflicts to human oversight
   • Make decisions based on agent confidence levels and test coverage
   • Document resolution rationale for future reference
   QUALITY ASSURANCE:
   • Validate that security analysis is comprehensive and fixes are implemented
   • Ensure tests cover 100% of identified issues with no regressions
   • Perform final integration and formatting into a review report
   • Conduct overall quality review before delivery
   AVAILABLE AGENTS:
   • Security Expert Agent: Analyzes code for vulnerabilities (SQL injection, XSS, etc.), suggests secure fixes, provides reasoning with OWASP references
   • Validator Agent: Runs unit/integration tests, validates fixes, confirms no performance/security regressions, generates test reports

在质量保障部分，指导是“验证每个子任务”。这通常由另一个智能体完成。下面看验证型智能体模板。

验证型智能体模板（The validator agent template）

智能体系统的强度与可靠性来自强护栏（guardrails）。将一个专门的验证智能体纳入工作流，会显著提升结果质量。下面是一套很扎实的 prompt：

You are a Validator agent focused on quality assurance and verification.

PURPOSE:

• Review outputs from other agents for accuracy and completeness
• Verify that requirements have been met
• Identify potential issues or improvements
• Ensure consistency with project standards

VALIDATION CRITERIA:

• Accuracy: Are facts correct and sources reliable?
• Completeness: Have all requirements been addressed?
• Quality: Does the output meet professional standards?
• Consistency: Is the output coherent and well-structured?

REVIEW PROCESS:

1. Compare output against original requirements
2. Fact-check claims and verify sources
3. Assess quality and professional standards
4. Check for logical consistency and flow
5. Provide specific, actionable feedback

FEEDBACK FRAMEWORK:

• APPROVED: Output meets all criteria and standards
• CONDITIONAL: Minor issues that can be addressed with specific changes
• REJECTED: Significant problems requiring substantial rework

When providing feedback, always:

• Be specific about what needs improvement
• Suggest concrete solutions when possible
• Acknowledge what was done well
• Maintain professional and constructive tone

ESCALATION CRITERIA:

• Fundamental disagreement with the producing agent
• Repeated quality issues from the same agent
• Requirements that cannot be validated with available information
• Critical errors that could impact system integrity

下面是一个面向代码质量与安全的 validator 智能体例子：

You are a Validator agent focused on quality assurance and verification for code reviews and security fixes.
PURPOSE:

• Review outputs from other agents for accuracy and completeness
• Verify that security fixes meet coding standards and eliminate vulnerabilities
• Identify potential issues, regressions, or improvements in fixed code
• Ensure consistency with security best practices and project standards
  VALIDATION CRITERIA:
• Accuracy: Do fixes correctly address identified vulnerabilities (e.g., OWASP Top 10)?
• Completeness: Are all suggested issues fixed with full test coverage?
• Quality: Does the code follow PEP8, security standards, and performance norms?
• Consistency: Is the fixed code maintainable, documented, and regression-free?
  REVIEW PROCESS:
• Compare fixed code against original vulnerabilities and requirements
• Run unit/integration tests and static analysis (e.g., Bandit, pylint)
• Verify no new vulnerabilities introduced via security scanners
• Assess code quality, documentation, and edge case handling
• Provide specific, actionable feedback with test results
  FEEDBACK FRAMEWORK:
• APPROVED: Fixes pass all tests, no regressions, security clean
• CONDITIONAL: Minor issues (e.g., style violations) with specific changes needed
• REJECTED: Vulnerabilities persist, tests fail, or new risks introduced

When providing feedback, always:

• Be specific about test failures or scan results
• Suggest concrete code improvements or additional tests
• Acknowledge secure patterns implemented well
• Maintain professional and constructive tone
  ESCALATION CRITERIA:
• Fundamental security flaws remain after fixes
• Test failures indicating regressions
• Disagreement with Security Expert on vulnerability severity
• Critical errors like buffer overflows or injection risks

领域化 prompt 示例

下面是一个研究型智能体例子：

You are a Research specialist focused on gathering comprehensive, accurate information.

RESEARCH METHODOLOGY:

• Start with authoritative primary sources
• Cross-reference findings across multiple sources
• Prioritize recent information unless historical context is needed
• Document source credibility and potential biases

INFORMATION QUALITY:

• Fact accuracy is your highest priority
• Clearly distinguish between facts, opinions, and speculation
• Note confidence levels for uncertain information
• Flag contradictory sources and explain discrepancies

DELIVERABLE FORMAT:

• Structured research reports with clear sections
• Source citations with links and publication dates
• Executive summary for quick consumption by other agents
• Raw data appendix when relevant

再看一个沟通型智能体例子：

You are a Communication specialist focused on clear, effective messaging.

WRITING PRINCIPLES:

• Adapt tone and style to the target audience
• Use clear, concise language without jargon
• Structure information logically with smooth transitions
• Ensure key messages are prominent and memorable

AUDIENCE ADAPTATION:

• Technical audiences: Include detailed methodology and data
• Executive audiences: Focus on insights and recommendations
• General audiences: Use analogies and avoid technical terms
• International audiences: Consider cultural communication norms

QUALITY STANDARDS:

• Grammar and spelling must be flawless
• Facts must be accurately represented
• Tone must be appropriate and professional
• Structure must support easy comprehension

工具分配决策框架

决定每个智能体能访问哪些工具，对系统效果与安全至关重要。糟糕的工具分配会导致能力缺口、安全漏洞与智能体困惑。下面是一个系统化框架，基于几条核心分配原则做决策：

最小权限原则（Principle of least privilege）

每个智能体只能访问其角色所必需的工具。这样能降低安全风险，也能降低认知负担——智能体不用在每次请求中反复排除一堆永远用不到的工具：

# Good - Focused tool assignment
research_agent:
  tools: [ web_search, document_reader, citation_manager ]

writing_agent:
  tools: [ document_editor, grammar_checker, style_guide ]

# Bad - Over-privileged assignment
research_agent:
  tools: [ web_search, document_reader, citation_manager,
           document_editor, grammar_checker, code_compiler,
           database_admin, system_monitor, shell, python_interpreter ]

工具-任务对齐（Tool-task alignment）

工具应直接支持智能体的主要职责与工作流。

避免危险重叠（Avoid dangerous overlaps）

当多个智能体需要相似能力时，要谨慎评估是否共享同一工具，或提供受限的专用版本。

系统化评分框架

可以用下面的框架系统分配工具：

Criteria	Weight	Questions to ask
Core necessity	40%	Is this tool essential for the agent’s primary function?
Security impact	25%	What’s the risk if this tool is misused or compromised?
Capability overlap	20%	Do other agents already have this capability?
Learning complexity	10%	How difficult is it for the agent to use this tool effectively?
Resource impact	5%	What are the computational/cost implications?

表 8.1：工具分配决策标准

评分体系示例：

• Essential / High Risk / High Overlap / High Complexity / High Cost = 按对应维度打分
• 用加权总分做决策

常见工具分配模式

顺序流水线模式（Sequential pipeline pattern）

data_collector:
  tools: [ web_scraper, api_client, file_reader ]
  handoff_format: "structured_data"

data_processor:
  tools: [ pandas, numpy, data_cleaner, validator ]
  handoff_format: "processed_dataset"

data_visualizer:
  tools: [ matplotlib, plotly, report_generator ]
  handoff_format: "final_report"

# Note: No tool overlap - clean separation of concerns

共享基础设施模式（Shared infrastructure pattern）

# Shared tools accessed by multiple agents
shared_tools:
  database_connection:
    access_level: "read_only"
    available_to: [ research_agent, analysis_agent, report_agent ]

  file_storage:
    access_level: "read_write"
    available_to: [ all_agents ]

# Agent-specific tools
research_agent:
  exclusive_tools: [ web_search, survey_tool ]

analysis_agent:
  exclusive_tools: [ statistical_processor, ml_model ]

分层权限模式（Hierarchical permission pattern）

coordinator_agent:
  tools: [ agent_manager, workflow_controller, system_monitor ]
  permissions: [ "delegate_tasks", "override_decisions" ]

specialist_agents:
  tools: [ domain_specific_tools ]
  permissions: [ "execute_tasks", "report_results" ]

validator_agent:
  tools: [ quality_checker, compliance_scanner ]
  permissions: [ "approve_outputs", "reject_work" ]

以上我们对多智能体系统的工具分配策略与决策框架做了较完整的梳理。但还有一个关键点同样重要：每个智能体能拿到什么上下文（context） 。

多智能体系统的上下文工程（Context engineering for multi-agent systems）

在把任务拆解为多个智能体、为它们设计 prompts、并分配合适工具之后，最后一个关键拼图是上下文工程（context engineering） ——决定每个智能体接收哪些信息，才能做出有效决策。由于 LLM 是无状态的，只会处理每次请求中提供的上下文，因此，精心的上下文管理决定了多智能体系统究竟是一个连贯协同的整体，还是一堆困惑、互相隔离的智能体集合。

多智能体系统中的上下文工程涉及三个关键维度：包含哪些信息、如何结构化以获得最佳理解、以及何时在智能体之间共享上下文。与单智能体系统不同，单智能体你可以简单地提供所有相关信息；而多智能体系统需要策略性的上下文分发（distribution），在保持每个智能体专注的同时，又能实现有效协作。

多智能体系统中的上下文类型（Types of context in multi-agent systems）

根据智能体的角色与交互方式，智能体可能需要不同类型的上下文：

1) 智能体特定上下文（Agent-specific context）

每个智能体都需要与其角色和当前任务匹配的上下文：

Research Agent Context：

• 当前研究目标与成功标准
• 之前收集的信息与来源
• 研究方法约束
• 质量标准与事实核查要求

Analysis Agent Context：

• 数据集描述与验证状态
• 分析目标与期望交付物
• 统计要求与置信水平
• 便于对比的既往分析结果

2) 共享上下文（Shared context）

多个智能体都需要的、用于保持一致性的信息：

Shared Project Context：

• 项目总体目标与时间线
• 关键干系人与需求
• 质量标准与约束
• 当前项目状态与里程碑

Shared Domain Knowledge：

• 行业术语与定义
• 相关法规与合规要求
• 历史背景与上下文信息
• 标准操作流程（SOP）

3) 交接上下文（Handoff context）

在顺序工作流中从一个智能体传给下一个智能体的信息：

Research → Analysis Handoff：

• 研究发现与来源可信度
• 数据质量评估
• 识别出的模式或异常
• 对分析方法的建议

Analysis → Reporting Handoff：

• 关键结论与统计显著性
• 使用的方法论与假设
• 置信度与不确定性范围
• 可执行洞察与建议

我们不仅要考虑提供什么上下文，还要考虑如何结构化这些上下文，才能做到清晰与高效。

上下文管理策略（Context management strategies）

多智能体系统中管理上下文有多种策略，用于在“完整性”和“简洁性”之间取得平衡：

1) 上下文分层（Context layering）

按相关性与更新频率把上下文分层组织：

context_layers:
  permanent:
    - agent role and expertise
    - core operational constraints
    - quality standards and procedures

  project:
    - current project goals and timeline
    - stakeholder requirements
    - success criteria and metrics

  session:
    - current task objectives
    - relevant previous work
    - immediate constraints and priorities

  dynamic:
    - real-time updates from other agents
    - changing requirements or conditions
    - error states and recovery instructions

要记住：多数 LLM provider 会基于前缀（prefix）缓存上下文。这意味着永久且稳定的上下文部分必须放在最前面，并且理想情况下永远不要改动或重新组织——即使必须做压缩（compaction）也一样。

2) 上下文作用域（Context scoping）

为每个智能体明确它需要知道什么、不需要知道什么的边界：

# Example context scoping for different agent types

coordinator_context = {
    "scope": "full_project_visibility",
    "includes": [
        "all_agent_status_and_progress",
        "project_timeline_and_milestones",
        "resource_allocation_and_constraints",
        "stakeholder_communication_history"
    ]
}

specialist_context = {
    "scope": "domain_focused",
    "includes": [
        "specific_task_requirements",
        "relevant_domain_knowledge",
        "quality_standards_for_domain",
        "handoff_requirements_and_format"
    ],
    "excludes": [
        "other_agents_internal_processes",
        "project_management_details",
        "unrelated_domain_information"
    ]
}

3) 上下文同步（Context synchronization）

当多个智能体并行运行，或智能体需要响应动态系统时，必须在智能体之间或与现实世界之间做上下文同步，确保在需要一致性时大家拿到的是一致信息：

Synchronization Triggers：

• 关键里程碑完成
• 需求变更或更新
• 需要协同处理的错误条件
• 影响多个智能体的质量问题

Synchronization Methods：

• 向所有相关智能体广播更新
• 版本控制的共享上下文文档
• 事件驱动的上下文刷新机制
• 定期一致性检查与对账（reconciliation）

在一个多智能体系统中同时使用多个触发器与同步方式非常合理且常见。比如：研究智能体未必需要在执行当前任务时就知道项目时间线变化，直到它完成任务并交接给下一个智能体；但如果变化是关键且影响研究范围，协调智能体可能就需要立刻广播更新。

上下文窗口管理（Context window management）

多智能体系统必须谨慎管理上下文窗口使用，才能维持性能：

1) 上下文优先级（Context prioritization）

按重要性与新鲜度对上下文元素排序，帮助 LLM 决定优先关注哪些部分、赋予更大权重：

context_priority_framework = {
    "critical": [
        "current_task_objective",
        "immediate_constraints",
        "error_conditions"
    ],
    "high": [
        "agent_role_definition",
        "quality_standards",
        "handoff_requirements"
    ],
    "medium": [
        "project_background",
        "previous_similar_tasks",
        "domain_knowledge"
    ],
    "low": [
        "historical_context",
        "optional_optimizations",
        "reference_materials"
    ]
}

2) 上下文压缩技术（Context compression techniques）

在长对话里消息超过上下文窗口时，系统需要决定如何压缩上下文以继续运行。关键技术包括：

Summarization：

• 将冗长的历史对话压缩为关键决策
• 从研究发现中提取要点
• 将复杂分析提炼为可执行洞察

Selective Inclusion：

• 只保留与当前任务相关的上下文
• 过滤过期或已被替代的信息
• 聚焦会影响决策的信息

Reference Systems：

• 把详细信息外置存储
• 上下文里只放摘要与引用
• 仅在需要时再检索完整细节

3) 上下文刷新模式（Context refresh patterns）

成熟的智能体系统可以在“用户消息、工具调用、响应”之外更新上下文。下面是一些有用模式：

refresh_strategies:
  continuous:
    description: "Real-time context updates"
    use_cases: [ "monitoring_agents", "reactive_systems" ]
    overhead: "high"

  periodic:
    description: "Scheduled context synchronization"
    use_cases: [ "batch_processing", "stable_workflows" ]
    overhead: "medium"

  event_driven:
    description: "Context updates on significant events"
    use_cases: [ "milestone_based_projects", "exception_handling" ]
    overhead: "low"

  on_demand:
    description: "Context loaded when specifically requested"
    use_cases: [ "specialized_analysis", "deep_research" ]
    overhead: "minimal"

这些上下文管理技术适用于每个智能体自身的上下文。但在多智能体系统中，智能体也可以、也应该选择性地把上下文共享给其他智能体。

智能体之间的上下文共享（Inter-agent context sharing）

下面用一些带图示的常见模式，说明协作工作流中智能体如何共享上下文。要注意：智能体通常不会共享全部上下文，而只共享协作所需的相关部分。很多时候，它们共享的内容甚至并不属于自身上下文，而是专门为“对方更好消费”而生成的结构化产物：

1) 直接上下文传递（Direct context passing）

智能体直接给其他智能体发消息，并把上下文作为消息的一部分传过去。这是最简单的共享形式，适用于顺序工作流：一个智能体的输出就是下一个智能体的输入。

图 8.13：直接上下文传递

2) 集中式上下文存储（Centralized context store）

智能体不直接交互，而是读写一个共享的上下文仓库。这种共享形式非常适合并行编排：多个智能体独立工作，但需要访问共同信息。

图 8.14：集中式上下文存储

3) 分层上下文分发（Hierarchical context distribution）

在分层编排中，由协调智能体负责向专家智能体分发上下文。所有智能体向协调者汇报，由协调者决定把总体上下文的哪些部分分享给哪个智能体。

图 8.15：分层上下文分发

以上就是多智能体系统上下文工程的大量信息。下面我们让 AI-6 和 A2A 真跑一圈，看看这些概念如何串起来落地。

让 AI-6 与 A2A 跑起来（Taking AI-6 and A2A for a ride）

我们用一个简单多智能体系统演示这些概念：由一个 AI-6 协调智能体（coordinator agent）和一个 A2A 专家智能体（specialist agent）组成。AI-6 框架的 A2A 集成会把本章讨论的模式串起来。

config_async.yaml（github.com/PacktPublis…）展示了配置多智能体系统有多简单：

# Basic agent configuration
default_model_id: gpt-4o
tools_dirs:
  - ${HOME}/git/ai-six/py/backend/tools

# A2A server integration - this creates the multi-agent system
a2a_servers:
  - name: kind-k8s-ai
    url: http://localhost:9999
    timeout: 30.0

# System prompt that implements the Coordinator pattern
system_prompt: |
  You are an AI assistant with advanced A2A (Agent-to-Agent) communication capabilities.

  You can:
  1. Start long-running A2A tasks that run asynchronously
  2. Receive real-time updates from A2A agents via SystemMessages
  3. Send messages to active A2A tasks
  4. Monitor multiple concurrent A2A operations
  5. Manage A2A task lifecycle (list, status, cancel)

该配置创建了一个分层的多智能体系统，包含：

• 一个 AI-6 智能体作为协调者/编排者
• 一个 k8s-ai 智能体作为领域专家（以 A2A server 形式在 localhost:9999 单独运行）

由于 k8s-ai 被注册为 A2A server，AI-6 tool manager 会自动发现其 skills 并创建对应的 A2ATool 实例，无需手动注册工具或单独提供 agent prompt。

这个 system prompt 刻意保持通用：它只是 A2A 集成端到端测试的一部分，并不意在完成任何具体真实目标。

我们运行端到端测试，观察多智能体系统实际工作：

% python -m examples.a2a-test.test_a2a_e2e
🧪 COMPREHENSIVE A2A E2E TEST
==================================================

📋 Phase 1: Service Dependencies
🔧 Checking Ollama service...
✅ Ollama already running
🔧 Checking k8s-ai A2A server...
✅ k8s-ai server already running
🤖 Setting up AI-6 Agent with async A2A...
[09/14/25 18:56:46] INFO     Processing request of type ListToolsRequest
                                                                                                                                                                                                                                         server.py:624
✅ Agent ready with 1 A2A tools and 4 task tools

📋 Phase 2: Core Async A2A Functionality

🚀 Testing Immediate Response Pattern...
✅ Immediate response in 0.00s, task ID: kind-k8s-ai_Kubernetes Operations_1757901406

📨 Testing Background Processing & SystemMessage Injection...
   Initial message count: 1
   Waiting for background SystemMessages...
     Waiting... (1/15)
     Waiting... (2/15)
     Waiting... (3/15)
     Waiting... (4/15)
     Waiting... (5/15)
✅ Received 1 A2A SystemMessages (1 success, 0 errors)
     SystemMessage(content='A2A Task Update [kind-k8s-ai_Kubernetes Operations_1757901406]: [A2A Update] ...

⚡ Testing Multi-tasking Capabilities...
✅ Multi-tasking working: 2 concurrent tasks active

📋 Phase 3: Task Management

🛠️  Testing Task Management Tools...
✅ Task status tool working
✅ Send message to task working

🧩 Testing Task Cancellation & Cleanup...
✅ Cancelled task: kind-k8s-ai_Kubernetes Operations_1757901406
✅ Cancelled task: kind-k8s-ai_Kubernetes Operations_1757901412
✅ Successfully cancelled/completed 2 tasks

==================================================
🎉 COMPREHENSIVE E2E TEST PASSED!
==================================================
⏱  Test duration: 10.4 seconds
📈 Tasks processed: 2
🔥 Async A2A Bridge: FULLY FUNCTIONAL

✅ Key Features Validated:
   • Immediate response pattern (no blocking)
   • Background task processing
   • SystemMessage injection for real-time updates
   • Multi-tasking (concurrent A2A operations)
   • Task lifecycle management
   • Proper error handling (no ignored errors)

🧩 Cleaning up test resources...

很好。端到端测试通过，并验证了我们在 A2A 集成中实现的关键多智能体模式。下面拆解我们刚刚看到的内容。

多智能体模式落地展示（Multi-agent patterns in action）

端到端测试（github.com/PacktPublis…）展示了多个框架层面的模式：

• 领域专长拆解（Domain expertise decomposition） （来自“智能体拆解策略”章节）：

  # General coordinator handles task orchestration
  result = tool.run(message="List all pods in the cluster with their status")
  
  # Specialist agent (k8s-ai) handles kubectl operations and cluster analysis
  # This demonstrates clear separation of concerns
  

• 协调者 system prompt 模式（Coordinator system prompt pattern） ：system prompt 明确把智能体定义为“不阻塞地管理异步操作”的任务协调者，从而实现协调者模板。

• 上下文工程（Context engineering） ：

  • Task context：每个 A2A 操作都有唯一 task ID，用于有状态追踪
  • Domain context：k8s-ai 维护集群上下文（kind-kind）
  • Session context：AI-6 管理多个并发会话

• 按能力分配工具（Tool assignment by capability） ：系统基于能力自动分配工具：

  • kind-k8s-ai_kubectl_skills：Kubernetes 操作
  • a2a_list_tasks, a2a_cancel_task：任务协调
  • 原生 AI-6 工具：通用推理与对话

• 并行编排（Parallel orchestration） ：两项任务同时运行，协调智能体收集结果供后续处理：

  # Start multiple tasks concurrently - no blocking
  task1 = agent.run_tool(
      "kind-k8s-ai_kubectl_skills", message="List all pods")
  task2 = agent.run_tool(
      "kind-k8s-ai_kubectl_skills", message="Get all services")
  
  # Both tasks run in parallel, coordinator manages their state
  list_result = agent.run_tool('a2a_list_tasks')  # Shows "Active A2A Tasks (2)"
  

这个例子验证了本章关键原则：

• 清晰的智能体拆解：通用推理（AI-6） vs 领域专长（k8s-ai）
• 恰当的工具分配：安全边界得到维护，能力与角色匹配
• 有效的上下文管理：task ID 让跨智能体边界的有状态协作成为可能
• 可扩展的编排：异步模式避免阻塞，从而实现真正并行
• system prompt 工程：协调者角色被清晰定义并具备具体能力

最终系统的效果是：通用智能体可以无缝协调领域专家，通过协作式专业分工达成复杂目标，而不是试图让一个智能体“什么都懂”。

这种设计可扩展：你可以继续加入数据库操作、文件系统管理或任何其他领域的智能体，同时保持相同的协作与协调模式。

不过，多智能体系统还有更多值得探索的内容。

多智能体系统中的冲突解决与角色分配（Conflict resolution and role assignment in multi-agent systems）

随着多智能体系统复杂度不断增长，智能体的角色与职责可能发生重叠，从而引发冲突——这会降低系统性能，甚至导致行为不一致。本节将探讨常见冲突场景与经验证的解决策略。首先，我们来看常见冲突场景：

• 资源竞争（Resource competition） ：多个智能体同时尝试访问同一资源，会产生竞态条件（race conditions）。例如，数据库智能体与审计智能体同时更新同一条记录，就可能出现数据损坏。数据库事务可能失败，文件可能被竞争进程锁住，共享内存资源也可能被破坏。这类冲突在高吞吐系统中尤其棘手，因为多个智能体会并发运行。
• 能力重叠（Overlapping capabilities） ：拥有相似技能的智能体可能重复劳动，或给出相互矛盾的建议。例如，数据库专家与数据分析专家都可能回答“销售趋势”的问题——两者使用不同方法，可能返回不一致结果。这种冗余既浪费计算资源，也会让用户困惑：同一个请求却得到多个潜在互相冲突的答复。
• 层级权威冲突（Hierarchical authority conflicts） ：当指挥链不清晰时，多个处于同一层级的智能体试图管理同一资源或同一组下级智能体，就会产生冲突指令。例如，管理者智能体与监督者智能体同时给同一个执行智能体分配不同任务，会导致优先级混乱，并可能使执行智能体执行相互矛盾的操作。

下面我们聚焦解决策略：

解决策略（Resolution strategies）

• 明确角色边界（Explicit role boundaries） ：最有效的冲突预防方式，是用能力矩阵（capability matrices）定义清晰且不重叠的职责边界。每个智能体都应显式定义其专业领域、可执行的具体操作，以及对资源访问的优先级等级。这需要更谨慎的系统设计，但能消除“到底该谁来处理这类请求”的歧义。

  当每个领域都映射到唯一智能体时，任务路由会非常直接。如果多个智能体都可能处理某个任务，系统就应该有预先定义的规则：基于当前负载、专业水平或其他客观标准，选择最合适的智能体。

• 基于优先级的解决（Priority-based resolution） ：当无法通过角色分离彻底避免冲突时，就要建立清晰的优先级层级。安全类智能体通常应拥有最高优先级，其次是合规类智能体，然后是业务逻辑类智能体，而自动化类智能体优先级最低。这样可确保安全与监管合规等关键关注点，永远压过效率优化。

  优先级系统应透明且一致，所有智能体都应理解这一层级结构。一旦发生冲突，由最高优先级智能体自动胜出，从而消除协商开销并确保结果可预测。

• 协调协议（Coordination protocols） ：通过结构化通信机制防止冲突。基于 token 的协调机制使用“独占访问 token”：智能体在访问共享资源前必须先获取 token，同一时间只有一个智能体能持有 token，从而避免并发访问冲突。

  基于共识的决策机制要求多个智能体在执行重大系统变更前投票表决。这对部署决策、配置变更或影响全系统的操作尤其有用。只有当达到阈值比例的智能体同意后，动作才会继续执行。

• 动态角色分配（Dynamic role assignment） ：根据当前上下文与负载分布动态调整智能体角色。系统应持续监控智能体性能与容量，当某些智能体过载或利用不足时，重新分配职责。动态负载平衡能防止瓶颈，并确保整个智能体网络的资源利用最优。

  负载均衡在分配新任务时，会同时考虑智能体能力与当前工作量：某个智能体在某领域很强，但如果它正忙于大量任务，那么一个“没那么专精但空闲”的智能体可能反而是更好选择。

冲突解决很重要，但理想情况下我们应尽可能在源头预防冲突。下面看看为达成这一目标的最佳实践。

冲突预防最佳实践（Best practices for conflict prevention）

掌握了上述冲突解决策略后，下面是一些用于预防多智能体系统冲突的最佳实践。

设计阶段冲突分析（Design-time conflict analysis）

在系统设计阶段分析能力重叠，提前识别潜在冲突点。构建能力矩阵，展示哪些智能体能处理哪些类型任务，然后找出可能引发冲突的重叠区域。若多个优先级相近的智能体之间存在高度重叠，就意味着该区域需要更谨慎的协调协议。

这种分析应产出明确文档：记录智能体边界与交互协议，帮助开发者理解不同智能体应该如何协作，而不是彼此竞争。

运行时冲突检测（Runtime conflict detection）

监控系统中的活跃操作，及时发现冲突。追踪哪些智能体正在访问哪些资源；当多个智能体试图修改同一数据或执行相互竞争的操作时，标记潜在冲突。早期检测能让系统优雅处理冲突，而不是在最后演变为系统故障。

冲突检测应在后台持续运行，在不显著影响性能的情况下保持对系统状态的感知。自动化告警还能提示管理员：若某类冲突模式频繁出现，可能意味着存在设计问题需要修正。

清晰的升级路径（Clear escalation paths）

为无法自动解决的冲突定义结构化升级（escalation）流程：技术冲突可以升级到技术负责人智能体，业务冲突升级到业务管理智能体，资源冲突升级到专用协调者。无法解决的冲突最终应升级到人类监督者。

升级路径应包含超时与自动回退（fallback）机制，避免当更高层智能体不可用时系统陷入停摆。升级层级应有良好文档，并定期做压力测试，确保在高压场景下依然可用。

有效的冲突解决能保证多智能体系统在扩展时依旧可靠、可预测：既保留专业化带来的收益，又避免无序行为导致的混乱。良好的架构设计能在冲突发生前预防大多数问题，使冲突解决策略成为“安全网”，而不是主要机制。

总结（Summary）

本章我们探索了设计高效多智能体 AI 系统的基本原则与实践方法：涵盖智能体拆解策略、编排模式、system prompt 设计、工具分配框架、上下文工程与冲突解决。关键洞察是：有效的多智能体系统更依赖清晰的架构设计，而不是复杂的冲突解决机制；只要智能体边界定义明确、能力矩阵清晰、上下文管理得当，多数冲突在发生前就能被预防。

我们通过 AI-6 + A2A 的集成演示了这些概念：简单配置即可创建一个分层多智能体系统，实现清晰的角色分离、实时通信与稳健的任务协调。端到端测试验证了关键模式，包括即时响应处理、后台处理、多任务并发能力与正确的冲突规避。对于需要通用推理与深度专业能力并存的企业场景而言，“分层 + 领域专家”的模式尤其有效。

这些基础为下一章铺路：我们将构建一个更全面的多智能体系统，把 AI-6、MCP 与 A2A 协议融合成一个生产级解决方案，完整展示本章涉及的所有模式与原则。