AI Agent 入门：从概念到实现

AI Agent（智能体）是 2024-2026 年 AI 领域最引人注目的范式转变。要理解它，我们先看看 AI 系统的演进路径：

第一代：问答系统——你问它答，被动响应。ChatGPT 刚发布时就是这种模式：用户输入一段文字，模型生成回复，然后等待下一次输入。这种交互模式下，模型完全没有"主动性"。

第二代：工具增强——模型可以调用外部工具（搜索引擎、代码执行器、API），但仍需要用户明确指定。用户说"帮我搜索 XX"，模型执行搜索并返回结果。

第三代：AI Agent——模型不仅能够使用工具，还能自主规划、分解复杂任务、在多步执行中保持上下文、根据执行结果动态调整策略。Agent 的核心特征是"主动性"和"自主性"。

举个例子：如果你让一个 Agent "帮我订一张下周北京到上海的机票"，它会自动：理解你的偏好→搜索航班→比较价格和时刻→检查你的日历→执行预订→发送确认。整个过程不需要你逐步指导。

Agent 不是单一技术，而是一种架构模式——它将大语言模型（LLM）作为"大脑"，围绕它构建感知、规划、记忆和执行的完整系统。这篇文章将深入拆解每一个组件。

一个完整的 AI Agent 系统通常包含感知、规划、记忆、执行四个核心组件，这个架构框架由 Stanford 的"Agent4Science"论文和多个开源框架（LangChain、AutoGen、CrewAI）共同确立。

感知模块（Perception）：负责理解用户的意图和环境状态。在大多数 Agent 系统中，LLM 本身就是感知模块——它接收自然语言输入，理解其中的目标、约束和上下文。但感知不止于理解文字，还包括：从结构化数据中提取信息（如读取数据库）、从非结构化内容中识别模式（如分析文档）、以及感知外部环境状态（如检查网页内容）。

规划模块（Planning）：这是 Agent 的"智慧"所在。规划分为两个层次：任务分解（Task Decomposition）——将复杂目标拆解为可执行的子任务序列；策略选择（Strategy Selection）——根据当前状态选择最优的执行路径。规划的核心挑战是：LLM 一次性生成的计划往往不完美，需要在执行中动态调整（Re-planning）。

记忆模块（Memory）：Agent 需要"记住"信息才能做出连贯的决策。记忆分为三种：短期记忆——当前对话上下文和正在执行的任务状态；长期记忆——通过向量数据库存储的历史经验和知识；工作记忆——当前步骤的中间结果和变量。

执行模块（Action/Tool Use）：将规划转化为实际行动。Agent 通过工具调用（Function Calling）来与外部世界交互：调用 API、执行代码、读写文件、操作浏览器等。执行模块的关键设计是：工具描述必须清晰、执行结果必须反馈给规划模块形成闭环。

# 一个极简 Agent 框架的实现
from typing import List, Dict, Callable
import json

class SimpleAgent:
    """极简 AI Agent：感知→规划→执行→观察的循环"""
    
    def __init__(self, llm, tools: Dict[str, Callable]):
        self.llm = llm
        self.tools = tools
        self.memory = []
        self.max_steps = 10
    
    def plan(self, goal: str, history: List[Dict]) -> Dict:
        """规划模块：让 LLM 决定下一步行动"""
        tools_desc = json.dumps(
            {name: fn.__doc__ for name, fn in self.tools.items()},
            ensure_ascii=False, indent=2
        )
        history_str = json.dumps(history[-5:], ensure_ascii=False, indent=2)
        prompt = f"""你是一个 AI Agent。当前目标是：{goal}

可用工具：
{tools_desc}

最近执行历史：
{history_str}

请决定下一步行动。返回 JSON 格式：
{{"tool": "工具名", "input": "输入参数"}}
如果目标已完成，返回 {{"done": true, "result": "最终结果"}}"""
        response = self.llm(prompt)
        return json.loads(response)
    
    def execute(self, tool_name: str, tool_input: str) -> str:
        if tool_name not in self.tools:
            return f"错误：工具不存在"
        try:
            return str(self.tools[tool_name](tool_input))
        except Exception as e:
            return f"执行错误：{str(e)}"
    
    def run(self, goal: str) -> str:
        print(f"开始执行目标：{goal}")
        for step in range(self.max_steps):
            plan = self.plan(goal, self.memory)
            if plan.get("done"):
                return plan.get("result", "任务完成")
            tool_name = plan.get("tool", "")
            tool_input = plan.get("input", "")
            print(f"  步骤 {step+1}: {tool_name}({tool_input[:50]}...)")
            obs = self.execute(tool_name, tool_input)
            self.memory.append({"step": step + 1, "plan": plan, "observation": obs[:500]})
        return "达到最大步数，任务未完成"

# 定义工具
def search_web(query: str) -> str:
    """搜索网络获取信息"""
    return f"搜索结果：关于'{query}'的相关信息..."

def calculate(expression: str) -> str:
    """计算数学表达式"""
    return str(eval(expression))

规划是 Agent 智能的核心体现。LLM 本身是一个"下一个 token 预测器"，它没有内在的目标导向。Agent 框架通过设计特定的 prompt 结构和执行流程，让 LLM 展现出"思考"和"规划"的能力。

ReAct 模式（Reasoning + Acting）：这是最经典的 Agent 规划范式。 核心思想是让 LLM 在每一步都先"思考"（Thought），再"行动"（Action），然后"观察"（Observation），如此循环。ReAct 的优势在于：思考过程被显式记录下来，便于调试和理解；每一步的观察结果直接反馈给下一步的思考，形成动态调整。

思维树（Tree of Thoughts, ToT）：当任务特别复杂时，单线的 ReAct 可能不够。ToT 让 Agent 在关键决策点生成多个可能的"思路分支"，评估每个分支的可行性，选择最有希望的路径继续。这类似于人类在面对复杂问题时会考虑多种解决方案。

反射（Reflection）：高级 Agent 不仅执行任务，还会在执行后"反思"：哪些步骤做得好？哪些可以改进？这种元认知能力让 Agent 能够自我优化。 典型的实现方式是让 LLM 对执行历史进行总结和评估，生成改进建议。

# ReAct 模式的完整实现
REACT_PROMPT = """你是一个 AI 助手，通过"思考-行动-观察"循环来解决复杂问题。

可用工具：
{tools}

格式：
Thought: <你的思考>
Action: <工具名>
Action Input: <工具输入>
Observation: <工具返回结果>
...（重复以上步骤）
Thought: 我已经有了足够的信息。
Final Answer: <最终答案>

问题：{question}

开始：
"""

class ReActAgent:
    def __init__(self, llm, tools):
        self.llm = llm
        self.tools = tools
        self.max_iterations = 8
    
    def _parse_response(self, text: str) -> dict:
        result = {"thought": "", "action": None, "action_input": None, "final_answer": None}
        for line in text.strip().split("
"):
            if line.startswith("Thought:"):
                result["thought"] = line[len("Thought:"):].strip()
            elif line.startswith("Action:"):
                result["action"] = line[len("Action:"):].strip()
            elif line.startswith("Action Input:"):
                result["action_input"] = line[len("Action Input:"):].strip()
            elif line.startswith("Final Answer:"):
                result["final_answer"] = line[len("Final Answer:"):].strip()
        return result
    
    def run(self, question: str) -> str:
        tools_desc = "
".join(f"- {name}: {fn.__doc__}" for name, fn in self.tools.items())
        prompt = REACT_PROMPT.format(tools=tools_desc, question=question)
        for i in range(self.max_iterations):
            response = self.llm(prompt)
            parsed = self._parse_response(response)
            print(f"  Thought: {parsed['thought']}")
            if parsed["final_answer"]:
                return parsed["final_answer"]
            if parsed["action"] and parsed["action_input"]:
                tool = self.tools.get(parsed["action"])
                if tool:
                    obs = tool(parsed["action_input"])
                    print(f"  Action: {parsed['action']}('{parsed['action_input'][:30]}...')")
                    print(f"  Observation: {obs[:100]}...")
                    prompt += response + f"
Observation: {obs}
"
                else:
                    prompt += response + "
Observation: 工具不存在
"
            else:
                prompt += response + "
"
        return "达到最大迭代次数"

如果没有记忆，Agent 就只是一个无状态的函数——每次调用都从零开始。记忆系统赋予 Agent 连续性和学习能力。

短期记忆（Short-term Memory）：就是当前对话的上下文窗口。LLM 的上下文长度有限（例如 128K tokens），这意味着 Agent 不能无限地记住所有历史。常见的策略是：滑动窗口（保留最近 N 条消息）、摘要压缩（将旧对话压缩为摘要）、关键信息提取（只保留与当前任务相关的信息）。

长期记忆（Long-term Memory）：通过外部存储实现。最常用的是向量数据库：将历史交互、知识点、经验转化为向量嵌入（Embedding），在需要时通过语义相似度检索。这使得 Agent 可以"记住"大量信息，而不受上下文窗口限制。

情景记忆（Episodic Memory）vs 语义记忆（Semantic Memory）：借鉴认知心理学的分类，情景记忆存储"发生了什么"（具体事件），语义记忆存储"知道什么"（抽象知识）。Agent 系统也可以做类似的区分：将具体交互记录存储在情景记忆中，将从中提取的通用知识存储在语义记忆中。

# 基于向量相似度的 Agent 记忆系统
import numpy as np
from typing import List, Dict

class VectorMemory:
    def __init__(self, embed_fn, top_k: int = 5):
        self.embed_fn = embed_fn
        self.memories: List[Dict] = []
        self.top_k = top_k
    
    def add(self, text: str, metadata: Dict = None):
        embedding = self.embed_fn(text)
        self.memories.append({
            "text": text, "embedding": embedding,
            "metadata": metadata or {},
        })
    
    def retrieve(self, query: str) -> List[Dict]:
        query_vec = self.embed_fn(query)
        sims = []
        for mem in self.memories:
            sim = float(np.dot(query_vec, mem["embedding"]) / 
                       (np.linalg.norm(query_vec) * np.linalg.norm(mem["embedding"]) + 1e-8))
            sims.append((sim, mem))
        sims.sort(key=lambda x: x[0], reverse=True)
        return [{"text": m["text"], "score": round(s, 3), "metadata": m["metadata"]}
                for s, m in sims[:self.top_k]]

# 使用示例
def dummy_embed(text: str) -> np.ndarray:
    h = hash(text) ％ 10000
    return np.random.RandomState(h).rand(128)

memory = VectorMemory(embed_fn=dummy_embed, top_k=3)
memory.add("用户喜欢用 Python 写数据分析代码", {"type": "preference"})
memory.add("项目使用 FastAPI 作为后端框架", {"type": "project"})
memory.add("上次讨论了 Transformer 架构", {"type": "history"})
results = memory.retrieve("用户的编程偏好是什么？")
for r in results:
    print(f"  [{r['score']}] {r['text']}")

工具调用是 Agent 与外部世界交互的唯一方式。 没有工具，Agent 就只是一个会说话的模型——它无法获取实时信息、无法执行计算、无法影响外部环境。

Function Calling 的工作原理：现代 LLM（如 GPT-4、Claude、Qwen）都支持函数调用能力。开发者提供一组函数描述（名称、参数、用途），LLM 在需要时返回一个结构化的函数调用请求。系统执行这个函数，将结果返回给 LLM，LLM 再基于结果继续推理。

工具设计的黄金法则：①描述清晰——每个工具的名称和描述必须让 LLM 能准确理解其用途；② 参数明确——参数的类型和含义要精确描述；③ 错误处理——工具失败时返回有意义的错误信息，帮助 LLM 决定重试还是换方案；④最小权限 ——工具只授予完成任务所需的最小权限，避免安全风险。

Agent 的"工具箱"：常见的 Agent 工具包括：搜索引擎（获取实时信息）、代码执行器（运行 Python/JavaScript 代码）、文件操作（读写本地文件）、数据库查询（访问结构化数据）、API 调用（与第三方服务交互）、浏览器自动化（操作网页）。

# 完整的工具定义与调用框架
import json
from typing import Any, Dict, List, Callable

class ToolRegistry:
    def __init__(self):
        self._tools: Dict[str, dict] = {}
    
    def register(self, name: str, description: str, param_names: List[str], func: Callable):
        self._tools[name] = {"name": name, "description": description, "param_names": param_names, "func": func}
    
    def get_tools_description(self) -> List[Dict]:
        return [{"name": t["name"], "description": t["description"]} for t in self._tools.values()]
    
    def call_tool(self, name: str, args: Dict) -> Any:
        tool = self._tools.get(name)
        if not tool:
            raise ValueError(f"未知工具: {name}")
        return tool["func"](**{k: v for k, v in args.items() if k in tool["param_names"]})

def search_tool(query: str, num_results: int = 5) -> str:
    """搜索网络获取信息"""
    import urllib.request
    url = f"https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch={query}&format=json&srlimit={num_results}"
    try:
        with urllib.request.urlopen(url, timeout=5) as resp:
            data = json.loads(resp.read())
        results = data.get("query", {}).get("search", [])
        if not results:
            return f"未找到关于'{query}'的结果"
        return "
".join(f"- {r['title']}: {r['snippet'][:100]}..." for r in results[:num_results])
    except Exception as e:
        return f"搜索失败: {e}"

def calculator_tool(expression: str) -> str:
    """安全计算数学表达式"""
    allowed = set("0123456789+-*/.() ")
    if not all(c in allowed for c in expression):
        return "错误：表达式包含不允许的字符"
    try:
        return str(eval(expression))
    except Exception as e:
        return f"计算错误: {e}"

registry = ToolRegistry()
registry.register("search", "搜索网络获取实时信息", ["query", "num_results"], search_tool)
registry.register("calculator", "计算数学表达式", ["expression"], calculator_tool)
print(json.dumps(registry.get_tools_description(), indent=2, ensure_ascii=False))

2024-2026 年间，涌现了大量 Agent 框架。理解它们的差异，能帮助你在实际项目中做出正确的选择。

LangChain/LangGraph：最流行的 Agent 框架，提供了完整的工具链。LangChain 擅长"链式"的线性流程，而 LangGraph 支持更复杂的图结构（循环、分支）。适合需要快速原型的场景。但抽象层次较高，调试可能困难。

AutoGen（Microsoft）：多 Agent 协作框架的标杆。 支持多个 Agent 之间通过对话协作完成任务，内置了用户参与模式（Human-in-the-loop）。适合需要复杂团队协作的场景。

CrewAI：轻量级的多 Agent 框架，API 设计优雅，学习曲线低。适合小型项目和快速实验。

AI Agent 已经在多个领域展现出巨大的实用价值。

软件开发：Agent 可以作为"AI 编程助手"，不仅能补全代码，还能理解整个代码库的架构、编写测试、修复 Bug、审查代码。典型工具包括 Devin（AI 软件工程师）、GitHub Copilot Workspace 等。Agent 在开发中的核心价值不是"替代程序员"，而是"放大程序员的生产力"——让一个程序员能做以前需要两三个人才能完成的工作。

数据分析：Agent 可以自动完成"数据探索→清洗→分析→可视化→报告"的完整流程。用户上传数据集，Agent 自动识别数据类型、生成描述性统计、发现异常值、构建可视化图表、撰写分析结论。

客户服务：新一代客服 Agent 不再只是关键词匹配的聊天机器人，而是能真正理解客户问题、查询订单状态、处理退款、升级复杂问题 的智能助手。

截至 2026 年，AI Agent 已经从概念验证阶段 进入了规模化部署阶段。 理解企业级 Agent 与个人使用的 Agent 之间的差异，对于推动 Agent 在组织中的落地至关重要。企业采纳率里程碑：2026 年 5 月，Anthropic 的企业 AI 采纳率达到34.4％，首次超过 OpenAI（32.1％），这标志着Claude Code 和 Anthropic 的企业 Agent 策略正在取得显著成效。PwC 宣布在 3 万名员工中部署 Claude，涵盖审计、咨询、税务等多个业务线，是目前全球最大的企业级 Agent 部署案例之一。企业级 Agent 与个人 Agent 的核心差异：企业级 Agent 必须满足安全合规（数据不出境、权限控制、审计日志）、可观测性（能看到 Agent 做了什么、为什么这么做）、集成能力（与现有 ERP、CRM、OA 系统对接）、治理机制（Agent 决策可审核、可回滚）。而个人 Agent 通常只需要关注功能实现。企业部署的三层架构：编排层（Orchestration Layer）负责任务分发、流程控制、异常处理，常用 LangGraph、CrewAI 等框架。代理层（Agent Layer）由多个专业化 Agent 组成，每个 Agent 负责特定领域（如数据分析 Agent、文档处理 Agent、客户沟通 Agent）。工具层（Tool Layer）提供企业内部的 API、数据库、知识库等能力。三层架构的优势是 解耦——当某个 Agent 需要升级时，不影响其他层。Anthropic 的企业 Agent 策略：Anthropic 通过Claude Code（AI 编程 Agent）和 Constitutional AI（安全对齐机制）建立了企业信任。Claude Code 的核心优势是：能够在开发者本地环境中运行、支持完整的代码库上下文理解、具备自动测试生成和修复能力。这些能力让企业能够在不改变现有开发流程的前提下引入 AI。成功部署的关键要素：明确的使用场景（不要试图用一个 Agent 解决所有问题）、充分的测试（在沙盒环境中验证 Agent 行为）、渐进式推广（先在内部小范围试用，再逐步扩大）、用户培训（让员工理解 Agent 的能力和边界）、持续监控和反馈（收集使用数据，持续优化 Agent 行为）。

2026 年 6 月，AI Agent 生态迎来了互操作性标准化的关键拐点。Google 主导的 A2A（Agent-to-Agent）协议正式发布 1.0 版本并进入生产级落地阶段，与 Anthropic 的 MCP（Model Context Protocol）和新兴的 ACP（Agent Communication Protocol）共同构成了多 Agent 协作的完整协议栈。这三大协议的协同正在重新定义 Agent 系统的架构范式——从「单 Agent 孤岛」走向「Agent 互联网」。

A2A 协议的核心设计与落地进展

Google 在 2026 年 6 月 3 日（Cloud Next '26 后续发布）正式推出 A2A 1.0 规范。A2A 协议的核心目标是：让不同厂商、不同框架构建的 Agent 能够像人类团队一样协作完成任务。 协议的设计基于四个关键原则：

第一，Agent Card（智能体名片）机制。每个 Agent 在注册时发布一个标准化的「Agent Card」，声明自己的能力描述、支持的任务类型、输入输出格式、安全认证方式和 SLA 承诺。其他 Agent 通过读取 Agent Card 来发现和理解潜在的协作伙伴——这类似于人类职场中的「自我介绍」，但完全机器可读。Agent Card 使用 JSON-LD 格式，支持语义描述，使得 Agent 能力的匹配不再依赖硬编码的接口定义。

第二，基于 JSON-RPC 2.0 的通信协议。A2A 选择了成熟的 JSON-RPC 2.0 作为通信基础，而非发明新的协议格式。这一决策大幅降低了企业采用的技术门槛——现有的 RPC 基础设施（如 gRPC-JSON 桥接、消息队列）可以直接复用。通信支持同步请求-响应和异步任务两种模式：简单的查询类任务使用同步模式，长时间运行的复杂任务使用异步模式并通过 Webhook 回调通知结果。

第三，任务生命周期管理。A2A 定义了标准的任务状态机：submitted → working → input-required → completed / failed / canceled。每个状态转换都带有标准化的事件通知，使得编排层能够精确追踪多 Agent 协作的进度。特别值得注意的是「input-required」状态——当一个 Agent 需要额外信息才能继续时，它可以暂停任务并向编排层请求输入，而不是简单地失败。

第四，安全与身份验证。A2A 1.0 集成了 OAuth 2.1 和 mTLS 双重认证，确保 Agent 之间的通信既验证身份又加密传输。这与本文第 14 章讨论的「Agent 身份认证基础设施」形成了直接呼应——Uber 在 2026 年 5 月解决的 Agent 身份认证问题，为 A2A 协议的身份层提供了实践基础。

MCP、A2A、ACP 三协议协同

截至 2026 年 6 月，三大协议形成了清晰的分工与协同关系：

MCP（Model Context Protocol） 解决的是 Agent 与工具之间的连接问题。它定义了 Agent 如何发现、调用和管理工具（如数据库查询、API 调用、文件操作），是 Agent 的「手」——让 Agent 能够操作外部世界。MCP 2.0 在 2026 年 5 月发布的 Tunnel 模式和自托管沙箱，已经使其成为 Agent 工具生态的事实标准。

A2A（Agent-to-Agent Protocol） 解决的是 Agent 与 Agent 之间的通信问题。它定义了 Agent 如何发现彼此、协商任务、交换结果，是 Agent 的「嘴和耳」——让 Agent 能够与同伴交流。A2A 的核心价值在于打破了 Agent 框架之间的壁垒：一个用 LangChain 构建的 Agent 可以与一个用 CrewAI 构建的 Agent 直接对话协作，而不需要中间的适配层。

ACP（Agent Communication Protocol） 是一个更新兴的协议，专注于 Agent 通信的上下文管理。它定义了对话上下文的传递、共享和隔离机制，确保多 Agent 协作时信息不会丢失或混淆。ACP 的核心创新是「上下文令牌（Context Token）」机制——每次 Agent 间通信都携带一个轻量级的上下文令牌，包含任务背景、已完成的步骤、关键约束等信息，接收方 Agent 无需重新解析完整的对话历史就能理解当前状态。

三大协议的协同关系可以概括为：MCP 管工具、A2A 管通信、ACP 管上下文。 在一个典型的多 Agent 协作场景中，Agent A 通过 A2A 协议发现并联系 Agent B，通过 ACP 传递任务上下文，Agent B 通过 MCP 调用工具执行任务，最后通过 A2A 将结果返回给 Agent A。这个过程中，ACP 确保上下文在整个链路中保持一致。

多 Agent 协作的新范式

A2A 协议的落地催生了三种新的多 Agent 协作范式：

范式一：动态 Agent 组队（Dynamic Agent Teaming）。 传统的多 Agent 系统是静态编排的——开发者预先定义好哪些 Agent 参与协作、按什么顺序执行。A2A 使得动态组队成为可能：一个编排 Agent 在运行时根据任务需求，通过查询 Agent Card 目录动态发现最合适的 Agent 来组队。例如，一个「市场分析」任务可能需要一个「数据收集 Agent」、一个「统计分析 Agent」和一个「报告撰写 Agent」——编排 Agent 可以根据数据源的地理位置、统计方法的复杂度和报告的目标语言，从全球的 Agent 注册表中选择最优组合。

范式二：Agent 即服务（Agent-as-a-Service, AaaS）。 A2A 协议使得 Agent 能力可以像 API 一样被发布和消费。企业可以将内部的专业 Agent（如「合规审查 Agent」「财务分析 Agent」「法务合同 Agent」）注册到企业 Agent 目录中，其他部门或团队可以通过 A2A 协议直接调用这些 Agent 的能力，而不需要重新构建。这催生了企业内部和跨企业的 Agent 服务市场。

范式三：协商式任务分解（Negotiated Task Decomposition）。 与传统的自上而下的任务分解不同，A2A 支持 Agent 之间的协商式分解。当一个复杂任务到达编排 Agent 时，编排 Agent 不是单方面拆解任务并分配给其他 Agent，而是发布任务需求，让潜在的协作 Agent 自主「竞标」——每个 Agent 根据 Agent Card 中声明的能力，评估自己能否完成子任务、需要多少时间、需要什么额外输入。编排 Agent 根据竞标结果选择最优的任务分配方案。这种模式特别适合子任务之间有复杂依赖关系的场景。

与记忆工程（agent-075）和工具调用工程（agent-076）的交叉

A2A 协议的落地对记忆工程和工具调用工程产生了深远影响，形成了显著的技术交叉。

与记忆工程（agent-075）的交叉： 在多 Agent 协作场景中，记忆管理面临全新的挑战。第一，共享记忆池（Shared Memory Pool） 成为必需——协作的多个 Agent 需要读写共享的上下文信息，但同时又需要隔离各自的私有记忆。A2A 协议的任务上下文（Task Context）机制为共享记忆提供了标准化的传递格式，而 ACP 的上下文令牌则确保了共享记忆在 Agent 间传递时的一致性。第二，Agent 能力记忆（Agent Capability Memory） 变得重要——编排 Agent 需要记住哪些协作 Agent 擅长什么、历史表现如何、在什么场景下表现最好。这种「协作经验记忆」直接影响未来组队的质量。第三，跨 Agent 记忆追溯：当多个 Agent 协作完成一个复杂任务后，如何将整个协作过程中的关键决策和经验教训沉淀为可检索的长期记忆，是记忆工程面临的新课题。这与本文第 4 章讨论的「情景记忆 vs 语义记忆」的分类直接相关——协作过程中的具体交互记录属于情景记忆，而从中提取的「Agent A 在处理 X 类任务时表现优于 Agent B」则属于语义记忆。

与工具调用工程（agent-076）的交叉： A2A 协议重新定义了工具调用的边界。第一，远程工具调用（Remote Tool Invocation）：Agent A 可以通过 A2A 协议请求 Agent B 使用其专有工具来完成特定操作——这意味着工具不再需要直接暴露给调用方 Agent，而是通过中间 Agent 封装。这解决了本文第 5 章讨论的「工具最小权限原则」在跨组织场景下的实施难题。第二，工具能力聚合（Tool Capability Aggregation）：一个 Agent 可以通过 A2A 将多个其他 Agent 的工具能力聚合为一个「虚拟工具集」，对外呈现统一的 MCP 接口。这大幅降低了编排层的复杂度——编排 Agent 只需要对接一个聚合 Agent，而不需要分别连接每个工具 Agent。第三，工具调用链的跨 Agent 传递：在 A2A 协作中，一个工具调用的结果可能需要触发另一个 Agent 的工具调用——形成跨 Agent 的工具调用链。ACP 的上下文令牌确保了调用链中每一步的输入输出都能被正确传递和追溯。

行业落地数据与生态格局

截至 2026 年 6 月中旬，A2A 协议的落地情况如下：

平台支持方面：Anthropic 的 Claude Agent Platform、OpenAI 的 GPT Agents、Google 的 Gemini Agent Platform 三大主流平台均已宣布支持 A2A 1.0。Microsoft Agent 365 在 2026 年 6 月的更新中也集成了 A2A 网关。这意味着全球主要的 Agent 平台已经实现了互操作性。

企业采用方面：根据 Gartner 2026 年 6 月的快速调查（样本量 300 家企业），42％ 的受访企业表示已在至少一个生产场景中使用 A2A 协议进行多 Agent 协作，另有 31％ 表示正在评估或试点中。金融和医疗行业的采用率最高，分别达到 58％ 和 51％——这些行业对标准化和合规性的需求推动了快速采用。

开发者生态方面：A2A 协议的开源参考实现（github.com/google/a2a-protocol）在发布两周内获得了 1.2 万 GitHub Star。LangChain、CrewAI、AutoGen 三大框架均发布了 A2A 适配器，开发者可以在现有框架中无缝启用 A2A 能力。

标准组织方面：W3C 已成立 Agent Interoperability Working Group，基于 A2A、MCP、ACP 的实践制定正式的 Web 标准。预计首个 W3C Working Draft 将在 2026 年 Q4 发布。

Gartner 预测，到 2027 年底，80％ 的新建 Agent 系统将基于 A2A/MCP/ACP 互操作标准构建，不支持互操作标准的遗留 Agent 系统将面临被边缘化的风险。这一预测与本文第 6 章讨论的「Agent 框架选择」直接相关——框架的互操作性支持正在成为选型的首要考量因素。

2026 年 6 月，DeepSeek 启动大规模招聘，Agent Harness 团队规模扩大一倍，所有部门都在强调 Harness Engineering 能力。几乎同时，Anthropic 承认 Claude Code 出现「实质性质量下降」——但模型本身没有变差，问题出在编排层。这揭示了一个行业共识：模型能力到产品能力之间存在巨大的鸿沟，而 Harness 层是跨越这个鸿沟的关键。

Harness 层的本质：在模型能力与用户需求之间，构建一个可靠、高效、可观测的中间层。它决定了四个关键维度：

可靠性（Reliability）：模型偶尔犯错时，产品能否自动修复？Harness 层需要实现优雅降级（Graceful Degradation）策略——当系统无法完美完成任务时，尽可能提供有价值的部分结果，而不是直接失败。三种降级模式：部分成功（返回已成功的步骤，告知失败原因）、降级执行（自动切换到轻量模型）、人工接管（置信度低于阈值时请求用户确认）。

效率（Efficiency）：同样的任务，消耗多少 Token 和时间？Harness 层需要实现智能路由（根据任务复杂度选择模型）、语义缓存（对相似问题复用历史回答）、提示词优化（压缩不必要的 Token 消耗）。据 CNBC 报道，2026 年企业 AI 支出出现明显转向：从 Token 最大化转向效率优先。亚马逊、Uber、Salesforce 等公司全面推行 Token 预算管理，限制高端模型调用频次。

可观测性（Observability）：出错时能否快速定位是模型问题还是工程问题？Harness 层需要实现执行轨迹追踪（Tracing）、性能指标采集（Metrics）、异常日志聚合（Logging）。分层监控是关键：模型层监控输出质量（通过采样评估），工程层监控 API 调用、延迟、错误，业务层监控用户满意度、任务完成率。

成本可控（Cost Control）：能否在质量和成本之间找到平衡点？据高盛预测，到 2030 年全球 AI 令牌消耗将升至当前的 24 倍，那些没有建立成本优化体系的企业将面临严峻的财务压力。Sail Research 在 2026 年 6 月完成 8000 万美元融资，专攻长时 Agent 推理基础设施，核心投资逻辑是：Agent 工作流的令牌消耗是普通聊天的 50-500 倍，如果不做成本优化，大多数企业的 AI 预算将在几个月内耗尽。

实战案例：Anthropic 的教训。Claude Code 质量事故中，三个 Harness 层变更叠加导致系统性故障：降低推理默认值、清理空闲会话缓存、添加系统提示词。问题不在于每个变更本身，而在于缺乏灰度发布和快速回滚机制。如果每个变更都经过小流量验证，问题可以在影响 100 个用户时发现，而不是 10000 个用户。据 AWS Well-Architected Framework，AI 系统的 MTTR（平均恢复时间）应该小于 1 小时。Claude Code 事故的 MTTR 超过 2 个月，是典型的可靠性工程失败。

Harness 工程的未来趋势：

趋势一：Harness 平台化。2026 年下半年，Harness 平台将大量出现：Anthropic Managed Agents 内置编排引擎，开发者只需定义任务和安全护栏；OpenAI Assistants API 提供完整的 Agent 生命周期管理；LangGraph Cloud 提供托管的 Agent 运行环境，自动扩缩容。据 Anthropic 公告，使用 Managed Agents 的企业从原型到上线的周期从数月缩短到数天。

趋势二：可靠性工程标准化。当前 Harness 层的可靠性工程缺乏统一标准。2027 年，我们将看到行业标准的形成：AI Agent 的可用性、延迟、准确率 SLA 定义，模型故障、工程故障、数据故障的明确分类，标准化的降级、回滚、重试恢复策略。据 AWS Well-Architected 团队，他们正在制定 AI 系统的 Well-Architected Framework，预计 2026 年 Q4 发布。

趋势三：Harness 工程专业化。当前 Harness 工程师大多是全栈背景，但 AI Agent 的特殊性要求专门的知识体系。2027 年，Harness 工程将成为独立的专业方向：专业技能包括模型行为理解、可靠性工程、成本优化；类似 AWS Solutions Architect 的专业认证出现；专门的会议、博客、开源项目形成社区生态。

给不同规模团队的建议：初创团队（5-10 人）优先使用托管平台（如 Anthropic Managed Agents），将有限的工程资源集中在核心业务逻辑上。中型团队（10-50 人）基于开源框架构建自有 Harness 层，投资可靠性和可观测性。大型企业（50 人以上）自建完整的 Harness 平台，输出最佳实践，推动行业标准。