Article

智能体增强 A2A

更新于：2026-07-20

第一章：A2A 基础概念

1.1 什么是 A2A（Agent-to-Agent）？

概念名称说明注意事项
A2A（Agent-to-Agent）指两个或多个基于大语言模型（LLM）构建的智能体（Agent）之间通过自然语言或结构化消息进行自主通信、协作与任务分解的交互范式。A2A 强调智能体具备目标理解、推理、工具使用和对话协调能力。A2A 不是简单的 API 调用链，而是具有语义理解、上下文感知和动态决策能力的多智能体系统；需避免将 A2A 简化为”函数调用嵌套”。
智能体（Agent）在 A2A 上下文中，指由 LLM 驱动、具备自主性（autonomy）、目标导向（goal-directed）和环境交互能力（如调用工具、读写记忆）的软件实体。单个 Agent 必须具备至少一种外部交互能力（如工具调用或记忆读写），否则仅为被动语言生成器，不构成真正智能体。
多智能体系统（MAS）由多个 Agent 组成的协作系统，通过消息传递实现任务分工、冲突解决或共识达成。A2A 是 MAS 在 LLM 时代的一种实现形式。并非所有多 Agent 场景都属于 A2A；只有当 Agent 之间存在双向、语义级通信时，才构成 A2A。

1.2 大语言模型作为智能体（LLM Agent）的基本能力

概念名称说明注意事项
推理能力（Reasoning）LLM Agent 能够对输入任务进行分解、规划步骤、评估选项并生成逻辑连贯的行动计划（如使用 ReAct、Chain-of-Thought）。推理质量高度依赖提示词设计和模型能力；小模型可能无法稳定执行复杂推理。
工具调用（Tool Use）Agent 可识别何时需要外部工具（如搜索、计算、数据库查询），并按规范调用（如 OpenAI Function Calling、LangChain Tools）。工具接口必须结构化（如 JSON Schema），且需严格校验输出格式，防止幻觉导致无效调用。
记忆管理（Memory）Agent 能存储和检索历史交互信息，包括短期上下文（对话历史）和长期知识（向量数据库、文件等）。长期记忆需配合嵌入与检索机制；过度依赖记忆可能导致上下文污染或信息过载。
自主决策（Autonomy）在无显式人类干预下，Agent 能根据目标动态选择行动路径、调用工具或与其他 Agent 协作。完全自主存在风险，实际系统常设置”人工审核点”或最大迭代次数限制。
角色扮演（Role-playing）Agent 可被赋予特定身份（如”研究员”、“程序员”、“审稿人”），其行为和语言风格随之调整。角色指令需明确且一致，否则易导致行为混乱或角色漂移。

1.3 A2A 与传统 API 调用、函数调用的区别

概念名称说明注意事项
A2A 通信基于语义消息的双向或多向交互，消息内容包含意图、上下文、中间结果，接收方需理解并生成响应。通信内容可为自然语言或半结构化格式（如 JSON + 文本）。A2A 通信不可预设固定流程；每次交互可能改变任务路径，需动态路由。
传统 API 调用客户端向服务端发送结构化请求（如 RESTful POST），服务端返回确定性结果，调用方无需”理解”响应语义。API 调用是单向、同步、确定性的；失败通常抛出错误码，不涉及协商或重试策略。
函数调用（Function Calling）LLM 根据用户指令生成函数调用参数，由外部系统执行后返回结果，再由 LLM 整合答案。本质是”LLM → 工具 → LLM”单轮闭环。函数调用是单 Agent 内部行为，不涉及多个 LLM 实例之间的协作；无法实现角色分工或辩论机制。
控制流 vs 语义流传统调用依赖预定义控制流（if-else、循环）；A2A 依赖语义流（intent → response → new intent）。将 A2A 强行套入传统工作流引擎（如 Airflow）会导致灵活性丧失；应使用图计算框架（如 LangGraph）建模。
错误处理机制A2A 中错误可通过协商、澄清、角色切换等方式恢复；传统调用通常直接失败或重试。A2A 的容错依赖于 Agent 的元认知能力（如”我无法完成，请换人”），需在 System Prompt 中显式设计。

第二章：A2A 通信协议与消息格式

2.1 消息结构设计（JSON Schema、自然语言模板等）

概念名称说明注意事项
结构化消息（Structured Message）采用 JSON 或类似格式封装通信内容，包含字段如 sender、recipient、content、intent、timestamp 等，便于程序解析与路由。字段命名应统一；避免过度嵌套导致解析复杂；建议使用 JSON Schema 校验。
JSON Schema 定义为消息格式提供标准化描述，例如定义 {"type": "object", "properties": {"role": {"type": "string"}, "content": {"type": "string"}}}，用于验证消息合法性。所有参与 Agent 必须遵循同一 Schema；版本变更需兼容或通知机制。
自然语言模板（Natural Language Template）使用预设句式（如”作为{role}，我建议…”）生成可读性强的消息，适用于调试或人机混合场景。模板需保留关键语义槽位（如任务ID、状态）；不可完全依赖自然语言，因 LLM 可能偏离模板。
混合消息格式同时包含结构化字段（如 tool_calls）和自由文本（如 explanation），兼顾机器处理与人类理解。自由文本部分不应承载关键逻辑；关键操作必须通过结构化字段表达。
消息唯一标识（Message ID）每条消息分配全局唯一 ID（如 UUID），用于追踪、去重、日志关联。在分布式系统中必须保证 ID 全局唯一；建议结合时间戳+节点ID生成。

2.2 通信协议标准（如 LangChain Message、OpenAI Function Calling 格式）

概念名称说明注意事项
LangChain Message 格式使用 HumanMessage、AIMessage、SystemMessage、FunctionMessage 等类表示对话轮次，支持 content、additional_kwargs 等字段。示例：{"role": "assistant", "content": "...", "tool_calls": [...]}。需配合 LangChain 的 ChatModel 使用；自定义 Agent 若不基于 LangChain 需手动对齐格式。
OpenAI Function Calling 格式在聊天完成响应中包含 tool_calls 数组，每个元素含 id、function.name、function.arguments；调用结果以 role: tool 消息返回。arguments 为 JSON 字符串，需 json.loads() 解析；函数名必须预先注册。
Anthropic Tool Use 格式使用 tool_use block 类型，在消息 content 中嵌入结构化工具调用指令，响应通过 tool_result block 返回。需启用 tools 参数并指定 schema；与 OpenAI 格式不兼容，迁移需转换层。
自定义 A2A 协议团队自定义消息协议，如包含 from_agent、to_agent、task_id、status、payload 等字段。必须文档化并强制所有 Agent 实现；建议提供序列化/反序列化工具函数。
协议互操作性不同框架（如 AutoGen 与 LangGraph）间通信需中间适配器转换消息格式。避免在生产系统中混用多种原生协议；推荐统一到一种标准（如 OpenAI 格式）作为内部总线。

2.3 上下文管理与对话历史传递

概念名称说明注意事项
对话上下文（Conversation Context）包含当前会话的所有历史消息列表，通常按时间顺序排列，作为 LLM 生成新响应的输入。上下文长度受模型 token 限制（如 128K）；需实施截断或摘要策略。
上下文窗口管理动态维护最近 N 条消息或按任务分段保留上下文，避免无关历史干扰当前决策。截断策略应保留关键系统消息和最新交互；避免切断工具调用-结果对。
任务级上下文隔离不同任务（如 task_id=101 vs task_id=102）使用独立上下文，防止信息交叉污染。需在消息中显式携带 task_id；Agent 内部应维护多任务上下文映射表。
上下文摘要（Context Summarization）当历史过长时，由专门 Agent 或 LLM 生成摘要（如”此前已完成数据收集，当前需分析”），替换原始消息。摘要可能丢失细节；关键步骤（如审批、错误）应保留原文。
全局记忆 vs 会话记忆全局记忆（如向量库）存储长期知识；会话记忆仅限当前任务对话历史。两者需区分使用。切勿将临时对话存入长期记忆；反之，长期知识应主动注入会话上下文。

第三章：单智能体构建基础

3.1 LLM Agent 的核心组件（推理引擎、工具调用、记忆模块）

概念名称说明注意事项
推理引擎（Reasoning Engine）负责任务理解、规划与决策的核心逻辑模块，通常由 LLM 配合提示模板（如 ReAct、Plan-and-Execute）实现。推理质量高度依赖 System Prompt 设计；应限制最大推理步数以防无限循环。
工具调用模块（Tool Invocation Module）解析 LLM 输出中的工具调用请求，执行外部函数（如搜索、计算、API），并将结果返回给 LLM。必须校验工具参数合法性；避免将未注册工具名传入执行器。
记忆模块（Memory Module）管理 Agent 的历史交互与知识，包括短期上下文（对话历史）和长期存储（向量数据库、文件等）。记忆读写需有明确触发机制；避免在每次调用时全量加载长期记忆。
输入解析器（Input Parser）将用户或其它 Agent 的消息解析为结构化输入（如任务目标、约束条件），供推理引擎使用。应支持多种输入格式（自然语言、JSON）；需处理模糊或冲突指令。
输出生成器（Output Formatter）将 LLM 的原始响应转换为标准消息格式（如符合 A2A 协议的 JSON），便于下游 Agent 解析。输出必须包含必要元信息（如 sender、intent）；自由文本不应承载关键操作指令。

3.2 工具集成（Tool Use / Function Calling）

方法名称语法用途代码示例注意事项
定义工具（Function Definition）使用 JSON Schema 描述函数名称、参数、描述，如 {"name": "search_web", "parameters": {"type": "object", "properties": {"query": {"type": "string"}}}}向 LLM 声明可用工具，使其能生成合规调用tools = [{"name": "get_weather", "description": "获取城市天气", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}]参数必须标记 required；描述应清晰说明用途与限制
工具注册（Tool Registration）在框架中注册工具函数及其元数据，如 LangChain 的 @tool 装饰器或 AutoGen 的 register_function使 Agent 能在运行时调用对应函数@tool def get_weather(city: str) -> str: return f"{city} 晴，25°C"函数返回值应为字符串或可序列化对象；避免副作用不可逆操作
工具调用解析（Tool Call Parsing）从 LLM 响应中提取 tool_calls 字段并解析参数将 LLM 的意图转化为实际函数调用for call in response.tool_calls: func = get_tool(call.function.name); args = json.loads(call.function.arguments); result = func(**args)必须处理 JSON 解析异常；参数类型需与函数签名匹配
工具结果封装（Tool Result Packaging）将工具执行结果封装为 role: tool 消息，回传给 LLM使 LLM 能基于结果继续推理messages.append({"role": "tool", "tool_call_id": call.id, "content": result})tool_call_id 必须与原调用一致；内容不可包含敏感信息
工具安全沙箱（Tool Sandbox）在隔离环境中执行工具（如限制网络访问、文件系统权限）防止恶意或错误工具调用导致系统风险使用 Docker 容器或 Python subprocess 限制执行环境生产环境必须启用；开发阶段可关闭但需标注风险

3.3 记忆与状态管理（短期记忆 vs 长期记忆）

概念名称说明注意事项
短期记忆（Short-term Memory）指当前对话或任务的上下文历史，通常以消息列表形式保存在内存中，作为 LLM 的输入上下文。受模型 token 限制（如 128K）；需定期清理或摘要；不应跨任务共享。
长期记忆（Long-term Memory）持久化存储的知识库，如向量数据库（Chroma、Pinecone）、文件或 SQL 表，用于跨会话检索历史经验。写入需嵌入（embedding）；读取需相似性检索；更新存在延迟。
记忆写入策略（Write Strategy）决定何时将信息存入长期记忆，如”仅存关键结论”、“每轮都存”或”由 Agent 主动决定”。频繁写入增加成本；应过滤噪声（如”好的”、“明白了”等无意义回复）。
记忆读取策略（Read Strategy）在生成响应前，根据当前任务查询相关长期记忆，并注入上下文。检索结果需排序并截断；避免引入无关或过时信息。
状态快照（State Snapshot）保存 Agent 当前状态（如任务进度、变量值、待办列表），用于恢复或调试。快照应可序列化（JSON/YAML）；敏感状态需脱敏；建议版本化管理。
记忆一致性（Memory Consistency）确保短期与长期记忆不冲突（如长期记忆说”已完成”，但短期上下文显示”进行中”）。可采用”短期优先”原则；或设计冲突检测与合并逻辑。

第四章：多智能体架构设计

4.1 多智能体拓扑结构（中心化、去中心化、混合式）

概念名称说明注意事项
中心化拓扑（Centralized Topology）所有 Agent 通过一个中央协调者（Orchestrator）通信，任务分配、消息路由、状态同步均由其控制。单点故障风险高；适合任务流程明确、需强管控的场景（如审批流）。
去中心化拓扑（Decentralized Topology）Agent 之间直接通信，无中央节点，通过广播、订阅或点对点方式交换信息。容错性强、扩展性好；但易出现消息风暴或状态不一致，需设计冲突解决机制。
混合式拓扑（Hybrid Topology）结合中心化与去中心化，例如按功能分组（小组内去中心化，组间由 Orchestrator 协调）。平衡控制力与灵活性；适用于复杂系统（如科研协作平台）。
星型结构（Star Architecture）所有 Worker Agent 仅与中心 Orchestrator 通信，彼此不可见。实现简单、调试方便；但 Orchestrator 成为性能瓶颈。
网状结构（Mesh Architecture）每个 Agent 可与其他任意 Agent 直接通信，形成全连接或部分连接图。通信效率高、响应快；但需复杂路由逻辑和身份管理。

4.2 角色定义与职责划分（Orchestrator、Worker、Reviewer 等）

角色名称职责说明注意事项
Orchestrator（协调者）负责任务分解、Agent 调度、消息路由、结果聚合与流程控制。通常不执行具体业务逻辑。必须具备全局视图；避免在 Orchestrator 中嵌入业务规则，应保持通用性。
Worker（执行者）执行具体子任务，如数据查询、代码生成、文本撰写等，依赖工具调用完成工作。应专注单一能力（如”Python 工程师”、“市场分析师”）；避免角色泛化导致性能下降。
Reviewer（评审者）对 Worker 的输出进行质量检查、事实核查或风格校验，并提出修改建议或批准通过。需配备评估标准（如 checklist）；可多级 Review（初审+终审）。
Moderator（主持人）在辩论或多观点场景中主持讨论，控制发言顺序、总结共识、防止偏题。需中立立场；应具备摘要与冲突调解能力。
Memory Agent（记忆代理）专职管理长期记忆的读写，响应其他 Agent 的检索请求，不参与任务逻辑。可提升系统一致性；避免每个 Agent 自行实现记忆逻辑导致冗余。
Fallback Agent（兜底代理）当主流程失败或超时，接管任务并尝试替代方案（如换模型、简化目标）。应预设降级策略；避免无限重试。

4.3 协作策略（协商、分工、投票、共识机制）

策略名称操作细节注意事项
任务分工（Task Partitioning）Orchestrator 将主任务拆解为子任务，分配给不同能力的 Worker Agent 并行执行。子任务需正交且可独立完成；依赖关系需显式声明（如”先 A 后 B”）。
协商机制（Negotiation）两个 Agent 就资源、时间、方案等进行多轮对话达成一致（如”你负责数据，我负责可视化”）。需设置最大协商轮次；应提供默认方案以防僵局。
投票机制（Voting）多个 Agent 对同一问题生成答案，由 Orchestrator 或独立 Voter Agent 统计多数意见作为最终结果。适用于事实性问题；对开放性问题效果有限；可加权投票（按角色权威性）。
共识机制（Consensus Building）Agent 通过迭代讨论逐步收敛到共同结论，常用于复杂决策（如论文评审、产品设计）。需记录每轮观点变化；可引入 Moderator 引导讨论方向。
流水线协作（Pipeline Collaboration）Agent 按固定顺序依次处理任务（A → B → C），前一 Agent 输出为后一 Agent 输入。适合线性流程；任一环节失败将阻断整个流水线，需异常跳转机制。
广播-响应（Broadcast-Response）一个 Agent 广播请求（如”谁会 Python？”），具备能力的 Agent 主动响应并承接任务。提升动态适配性；需防多个 Agent 同时响应导致重复执行。

第五章：A2A 协作流程实现

5.1 启动与初始化流程

步骤名称操作细节注意事项
系统配置加载读取 YAML/JSON 配置文件，包含 Agent 列表、角色定义、工具注册表、通信协议、记忆后端等。配置应支持环境变量覆盖；敏感信息（如 API Key）需通过安全方式注入。
Agent 实例化根据配置创建各 Agent 对象，绑定 LLM、工具集、记忆模块和 System Prompt。每个 Agent 应有唯一 ID 和角色标签；避免共享可变状态（如内存上下文）。
工具注册与验证将函数工具注册到每个 Agent 的工具调用模块，并校验参数 Schema 是否合规。工具名必须全局唯一；建议在启动时进行 dry-run 测试。
初始上下文构建为 Orchestrator 或主任务 Agent 注入初始任务描述、约束条件和目标输出格式。初始消息应符合 A2A 消息协议；避免模糊指令（如”做点什么”）。
通信通道初始化建立消息队列、事件总线或内存消息池，用于 Agent 间异步/同步通信。在分布式部署中需使用 Redis、Kafka 等中间件；单机可使用 Python Queue。

5.2 消息路由与分发机制

方法名称语法 / 机制用途代码示例注意事项
直接寻址路由消息包含 to_agent: "coder"，由消息总线直接投递给指定 Agent。点对点通信，适用于明确分工场景。message_bus.send(to="reviewer", content="请审核代码")目标 Agent 必须在线；需处理”收件人不存在”异常。
广播路由消息发送给所有 Agent，由接收方根据角色/能力决定是否处理。适用于能力发现或紧急通知。for agent in agents: if agent.can_handle(msg): agent.receive(msg)易造成冗余处理；建议配合”能力声明”机制过滤。
主题订阅路由Agent 订阅特定主题（如 "data_analysis"），消息按主题分发。解耦发送方与接收方，提升扩展性。agent.subscribe("weather_tasks"); message_bus.publish(topic="weather_tasks", msg=msg)需维护主题-订阅者映射表；避免主题爆炸。
动态路由（基于 LLM 决策）由 Orchestrator 调用 LLM 分析当前任务，动态决定下一跳 Agent。适用于非固定流程的复杂任务。next_agent = llm.predict(f"当前状态：{state}，谁该下一步？", choices=agent_names)需限制 LLM 输出为预定义 Agent 列表；防止幻觉导致无效路由。
消息队列优先级为消息设置优先级（如 high/normal/low），高优任务优先处理。保证关键任务响应速度。message_bus.enqueue(msg, priority="high")需配套优先级调度器；避免低优任务饥饿。

5.3 异常处理与重试策略

异常类型处理策略注意事项
工具调用失败（如 API 超时）自动重试（最多 N 次，指数退避），失败后通知 Fallback Agent 或降级处理。重试间隔应递增（如 1s, 2s, 4s）；幂等性工具才可安全重试。
LLM 生成无效工具调用捕获 JSON 解析错误或参数缺失，返回错误消息并要求 LLM 重新生成。应提供具体错误原因（如”缺少 city 参数”）；避免无限循环。
Agent 无响应（超时）设置消息处理超时（如 30 秒），超时后标记失败并触发备用流程。超时阈值应根据任务复杂度调整；记录超时日志用于分析。
消息格式不合规消息总线校验 Schema，拒绝非法消息并告警。应返回标准化错误码（如 INVALID_MESSAGE_FORMAT）；禁止静默丢弃。
死锁或循环依赖检测消息环路（如 A→B→A）或任务停滞（长时间无进展），强制终止并上报。可记录消息路径哈希；建议设置最大协作轮次（如 max_turns=10）。
重试上限与熔断单任务失败超过阈值后熔断，不再重试，转人工或记录失败。熔断后应提供诊断信息；避免系统资源耗尽。

5.4 终止条件与结果聚合

终止条件类型判定方式注意事项
显式完成信号某 Agent 发出 {"status": "completed", "result": ...} 消息。必须由具备权限的 Agent（如 Worker 或 Orchestrator）发出；需校验结果完整性。
最大轮次限制协作轮数达到预设上限（如 10 轮）自动终止。防止无限循环；应记录最终状态供分析。
所有子任务完成Orchestrator 检测所有分配的子任务均已返回成功状态。需维护任务-状态映射表；支持部分失败下的部分聚合。
共识达成多个 Reviewer 投票一致通过，或 Moderator 宣布讨论结束。共识阈值可配置（如 2/3 同意）；需记录反对意见。
用户中断接收到外部终止指令（如用户点击”停止”）。应优雅关闭，保存中间状态；不可强制 kill 进程。
聚合方法操作细节注意事项
结果拼接（Concatenation）将多个 Worker 的输出按顺序合并为最终报告。适用于流水线任务；需统一输出格式（如 Markdown 段落）。
投票聚合（Majority Vote）对多个答案取多数结果作为最终输出。仅适用于离散答案（如选择题、分类）；需处理平票。
加权融合（Weighted Fusion）根据 Agent 权威性（如专家角色）加权平均或选择最优结果。权重应在配置中定义；避免主观赋权偏差。
元 Agent 总结由专门 Summarizer Agent 阅读所有中间结果，生成连贯最终输出。提升可读性；但增加额外 LLM 调用成本。
结构化输出封装将结果按预定义 JSON Schema 封装，便于下游系统消费。Schema 应提前约定；必须校验字段完整性。

第六章：典型 A2A 应用场景

6.1 多角色辩论系统

概念/组件说明注意事项
辩论角色（Debater Roles）预设多个立场不同的 Agent（如”正方”、“反方”、“中立观察员”），各自持有论点与证据。角色指令需明确立场边界；避免角色在辩论中”倒戈”。
发言轮次控制由 Moderator Agent 按规则分配发言权（如轮流制、抢答制），防止抢占或沉默。应设置最大发言次数；支持打断机制（如提出关键质疑）。
论点生成与反驳每个 Debater 基于当前上下文生成新论点或针对对方论点进行逻辑反驳。需启用 Chain-of-Thought 提示以提升逻辑性；避免情绪化语言。
共识或结论输出辩论结束后，由 Moderator 或独立 Judge Agent 总结各方观点并给出平衡结论。结论应标注”未达成共识”若存在重大分歧；不可强行统一。
评估指标可衡量逻辑连贯性、论据质量、反驳有效性等，用于迭代优化 Prompt。建议结合人工评估；自动评估易受语言风格干扰。

6.2 分布式任务规划（如 AutoGen 中的 GroupChat）

概念/机制说明注意事项
GroupChat 管理器AutoGen 中的 GroupChatManager 负责协调多个 Agent 在群聊中自主发言、推进任务。所有参与 Agent 必须注册到同一 GroupChat 实例。
自主发言机制每个 Agent 根据当前对话判断”是否该我发言”，若认为相关则生成响应。需在 System Prompt 中强调”仅在必要时发言”；否则易导致话痨。
任务分解与接力主任务被隐式拆解，Agent 通过对话自然交接子任务（如”我查完数据，下一步谁分析？”）。依赖 LLM 的上下文理解能力；复杂任务建议显式分工。
终止检测当某 Agent 输出 TERMINATE 或满足预设完成条件时，GroupChat 停止。TERMINATE 必须作为独立消息；不可嵌入长文本中。
消息历史共享所有 Agent 共享同一对话历史，确保上下文一致。历史过长时需启用摘要或截断；避免 token 超限。

6.3 自主科研代理协作（如 MetaGPT）

角色/模块职责说明注意事项
产品经理（Product Manager）定义科研目标、输出需求文档（如”实现一个 Transformer 训练 pipeline”）。需具备领域知识；避免提出不切实际目标。
架构师（Architect）设计系统架构、模块划分、技术选型，并输出设计文档。应引用最新论文或最佳实践；避免过度工程。
工程师（Engineer）编写可运行代码、单元测试，并提交至虚拟代码库。代码需符合 PEP8 等规范；必须包含注释和错误处理。
审稿人（Reviewer）审查设计文档与代码，提出修改意见，直至通过。应使用 checklist（如”是否有内存泄漏？”）；支持多轮迭代。
项目经理（Project Manager）跟踪进度、协调阻塞、汇总成果，驱动项目闭环。需定期生成进度报告；可触发超时告警。
虚拟代码仓库模拟 Git 仓库，存储各轮次代码版本，供后续 Agent 读取。代码变更需带 commit message；支持 diff 对比。

6.4 客服多轮协同应答

协作流程操作细节注意事项
用户意图识别首接 Agent（Triage Agent）分析用户问题，分类为”账单”、“技术故障”、“退货”等。意图分类需高准确率；模糊问题应主动澄清。
动态路由至专家根据意图将对话转交给对应领域 Expert Agent（如”网络工程师”、“财务专员”）。转交时需附带上文摘要；避免用户重复描述问题。
多专家会诊复杂问题触发多个 Expert Agent 协同（如技术+法务），通过内部 A2A 讨论后统一回复。内部讨论不可暴露给用户；最终回复需风格一致。
上下文无缝传递用户历史交互（包括已尝试方案、身份信息）在 Agent 间安全共享。敏感信息（如身份证号）需脱敏或加密；遵守隐私法规。
服务闭环确认最终 Agent 主动询问”问题是否解决？“，并记录满意度或触发升级流程。必须提供”转人工”选项；不可强制结束对话。
会话日志归档全程对话存入 CRM 系统，用于质检、训练与审计。日志需结构化存储（含 Agent ID、时间戳、操作类型）；保留至少 6 个月。

第七章：评估与优化

7.1 A2A 系统评估指标（效率、准确性、鲁棒性、通信开销）

指标类别指标名称说明注意事项
效率任务完成时间（Task Completion Time）从任务启动到最终结果输出的总耗时。应排除人工干预时间；可分”端到端”与”纯 LLM 推理”两部分统计。
效率LLM 调用次数（LLM Invocation Count）完成单任务所调用 LLM 的总次数（含工具调用往返）。越少越好；高次数可能反映提示设计低效或流程冗余。
准确性任务成功率（Task Success Rate）在测试集上，系统输出符合预期目标的比例（人工或自动判定）。需明确定义”成功”标准；避免模糊通过。
准确性工具调用准确率（Tool Call Accuracy）工具参数正确且调用时机合理的比例。可通过单元测试验证工具输入输出是否匹配预期。
鲁棒性异常恢复率（Recovery Rate）系统在发生工具失败、超时等异常后仍能完成任务的比例。应模拟各类故障（如 API 返回 500）进行压力测试。
鲁棒性最大协作轮次稳定性在不同输入下，系统是否总能在预设轮次内终止。避免因提示偏差导致某些任务无限循环。
通信开销消息总量（Total Message Count）单任务执行过程中 Agent 间交换的消息总数。过高可能表示过度协商；可结合消息平均长度评估总 token 消耗。
通信开销上下文 token 占用每次 LLM 调用所携带的上下文 token 数量。应监控是否接近模型上限（如 128K）；影响成本与延迟。

7.2 提示工程优化（System Prompt 设计、角色指令精炼）

优化方法操作细节注意事项
角色指令显式化在 System Prompt 中明确 Agent 的身份、能力边界、禁止行为（如”你不能访问用户私人文件”）。避免模糊描述（如”你是一个助手”）；应具体到”你是 Python 代码审查专家”。
行为约束模板使用结构化指令模板，如：“你必须：1. 先分析问题；2. 若需工具则调用；3. 否则直接回答。“模板应简洁；过多规则会干扰 LLM 理解。
输出格式强制要求 LLM 以固定格式输出（如 JSON、XML），便于下游解析。必须配合 Schema 校验；可使用 response_format 参数（如 OpenAI）。
少样本示例（Few-shot）在 Prompt 中嵌入 1–3 个高质量输入-输出示例，引导 LLM 行为。示例需覆盖典型与边界情况；避免引入偏见或错误模式。
元提示（Meta-prompting）让 LLM 自我反思或优化其输出，如”请检查你的回答是否有事实错误”。增加推理步数；仅在关键任务中使用。
角色一致性强化在每轮对话中重复角色声明（如”作为审稿人…”），防止角色漂移。可通过消息前缀自动注入；避免手动维护。

7.3 通信压缩与缓存策略

策略名称操作细节注意事项
上下文摘要压缩当历史消息超过阈值时，调用专用 Summarizer Agent 生成摘要，替换原始消息。摘要应保留关键实体、决策点和工具调用结果；避免丢失任务状态。
消息去重对相同内容或语义高度相似的消息进行过滤，防止重复处理。可基于文本哈希或嵌入向量相似度（如 cosine > 0.95）判断。
工具结果缓存对幂等工具（如天气查询、知识检索）的结果按参数缓存，避免重复调用。缓存需设置 TTL（如 5 分钟）；敏感数据不可缓存。
向量缓存（Embedding Cache）对高频查询的嵌入结果缓存，加速长期记忆检索。嵌入模型版本变更时需清空缓存；避免语义漂移。
增量上下文传递仅传递自上次交互以来的新增状态，而非全量历史。需设计状态 diff 机制；适用于状态机类任务。
二进制序列化（高级）在内部通信中使用 Protobuf 或 MessagePack 替代 JSON，减少体积。仅适用于性能敏感场景；增加开发复杂度，一般 A2A 系统无需。

7.4 安全与隐私考量

风险类型防护措施注意事项
提示注入（Prompt Injection）对用户输入进行过滤或转义；限制 Agent 可执行的操作范围。不可信任任何外部输入；即使来自其他 Agent 也需校验。
敏感信息泄露在消息传递前自动识别并脱敏 PII（如手机号、身份证号）。使用正则或 NER 模型检测；脱敏后应保留占位符供调试。
工具滥用限制高危工具（如文件删除、网络请求）的调用权限，仅授权特定角色。所有工具调用应记录审计日志；生产环境禁用 shell 执行。
记忆污染长期记忆写入前需审核；不同用户/任务的记忆严格隔离。多租户系统必须实现 memory namespace 隔离。
拒绝服务（DoS）限制单任务最大 LLM 调用次数、消息数、执行时间。设置硬性上限（如 max_turns=15, timeout=120s）；触发即终止。
审计与追溯记录完整消息流、工具调用、Agent 决策路径，支持事后回溯。日志应包含 timestamp、agent_id、message_id、action_type；保留至少 180 天。

第八章：主流框架支持

8.1 Microsoft AutoGen

方法/组件名称语法 / 用法用途代码示例注意事项
ConversableAgentagent = ConversableAssistantAgent("coder", llm_config=llm_config)创建可对话的智能体，支持自动回复、工具调用、人类输入等模式user_proxy = UserProxyAgent("user", code_execution_config={"work_dir": "coding"})所有 Agent 必须注册到同一 GroupChat 或直接配对；默认启用代码执行需谨慎
GroupChatgroupchat = GroupChat(agents=[user_proxy, coder, reviewer], messages=[], max_round=10)实现多 Agent 群聊协作，自动轮询发言权manager = GroupChatManager(groupchat=groupchat, llm_config=llm_config)需指定 max_round 防止无限循环；Agent 的 System Prompt 决定是否主动发言
register_functionregister_function(get_weather, caller=coder, executor=user_proxy, description="获取天气")将 Python 函数注册为跨 Agent 可用的工具coder.initiate_chat(manager, message="查北京明天天气")工具调用由 caller 发起，executor 执行；executor 需具备执行权限
code_execution_config{"work_dir": "tmp", "use_docker": True}配置代码执行环境，支持 Docker 沙箱UserProxyAgent(..., code_execution_config={"use_docker": "python:3.10"})生产环境必须启用沙箱；避免在主进程执行任意代码
human_input_mode"ALWAYS" / "TERMINATE" / "NEVER"控制是否等待人工介入UserProxyAgent(..., human_input_mode="TERMINATE")”TERMINATE” 表示收到 TERMINATE 关键词后停止；适合自动化流程

8.2 LangGraph（LangChain 生态）

方法/组件名称语法 / 用法用途代码示例注意事项
StateGraphgraph = StateGraph(AgentState)定义基于状态机的多 Agent 协作图class AgentState(TypedDict): messages: Annotated[list, add_messages]状态类必须继承 TypedDict；使用 Annotated 支持消息累加
add_nodegraph.add_node("planner", plan_node)向图中添加节点（即 Agent 或函数）def plan_node(state): return {"messages": [AIMessage(content="Plan: ...")]}节点函数必须返回字典，更新全局状态
add_edge / add_conditional_edgesgraph.add_conditional_edges("planner", route_next, {"review": "reviewer", "end": END})定义静态或条件跳转边def route_next(state): return "review" if needs_review else "end"条件函数返回值必须匹配目标节点名；支持动态路由
compile()app = graph.compile()编译图为可执行应用result = app.invoke({"messages": [HumanMessage(content="Write a blog")]})编译后不可修改图结构；支持异步 .ainvoke()
checkpointerMemorySaver()启用状态持久化，支持中断恢复app = graph.compile(checkpointer=MemorySaver())分布式部署需替换为 RedisSaver 等；调试时可用内存存储

8.3 CrewAI

方法/组件名称语法 / 用法用途代码示例注意事项
Agentresearcher = Agent(role='Senior Researcher', goal='Find AI trends', backstory='...')定义具有角色、目标和背景的智能体tools=[search_tool], verbose=Truebackstory 影响行为风格；verbose 用于调试
Tasktask = Task(description='Analyze 2025 AI trends', agent=researcher)将任务分配给特定 Agentoutput_file='report.md'支持 expected_output 明确输出格式；可链式依赖
Crewcrew = Crew(agents=[researcher, writer], tasks=[task1, task2], process=Process.sequential)组装多 Agent 团队并定义协作流程result = crew.kickoff()process 支持 sequential（顺序）或 hierarchical（层级）
Process.hierarchicalCrew(..., process=Process.hierarchical, manager_llm=llm)启用管理层 Agent 自动协调任务需额外指定 manager_llm适合复杂任务；增加 LLM 调用成本
Tool 集成from crewai_tools import SerperDevTool; search_tool = SerperDevTool()使用内置或自定义工具Agent(..., tools=[search_tool])工具需符合 CrewAI 接口；支持 LangChain 工具适配

8.4 Semantic Kernel（Microsoft）

方法/组件名称语法 / 用法用途代码示例注意事项
Kernelkernel = sk.Kernel()创建核心运行时容器kernel.add_service(sk.OpenAIChatCompletionService("gpt-4", api_key))需先注册 AI 服务；支持 OpenAI、Azure、HuggingFace
Pluginkernel.import_plugin_from_directory("plugins", "WriterPlugin")从目录加载插件（含多个 functions）插件目录需含 config.json 和 Python 文件函数需用 @sk_function 装饰；参数通过 sk_function_context_parameter 声明
Function Invocationresult = await kernel.invoke(function, input="AI trends")调用单个语义函数支持链式调用：kernel.create_semantic_function(prompt)函数可组合为 pipeline；但原生不支持多 Agent 直接通信
Memorykernel.register_memory_store(memory_store=sk.VolatileMemoryStore())注册短期记忆存储长期记忆需集成 Azure Cognitive Search 或 QdrantSK 本身无内置多 Agent 架构；需自行构建 A2A 层
Plannerplanner = ActionPlanner(kernel); plan = await planner.create_plan(goal="Write report")自动生成函数调用计划返回可执行 plan 对象适用于单 Agent 复杂任务规划；非多 Agent 协作原生方案

8.5 自定义轻量级 A2A 实现

组件/方法实现要点用途最小代码示例注意事项
消息总线（Message Bus）使用 Python queue.Queue 或 asyncio.Queue 实现同步/异步消息传递Agent 间通信基础设施message_queue = Queue(); agent.send(msg); other.receive()单机可行；分布式需换为 Redis Pub/Sub
Agent 基类定义 name, receive(), decide(), send() 等接口统一 Agent 行为规范class BaseAgent: def receive(self, msg): self.messages.append(msg); self.act()所有具体 Agent 继承此类
简易 Orchestrator主循环轮询消息队列，分发给对应 Agent控制协作流程while not done: msg = queue.get(); agents[msg.to].receive(msg)需处理终止条件和超时
JSON 消息协议定义标准消息格式：{"from": str, "to": str, "content": str, "tool_calls": [...]}确保互操作性msg = {"from": "user", "to": "coder", "content": "print hello"}所有 Agent 必须遵守此格式
工具调用解析器从 LLM 输出中提取并执行工具实现 Tool Use 能力if "tool_calls" in response: for call in response.tool_calls: exec_tool(call)必须校验函数名白名单；禁止 eval()