两篇文章的最终定位

这组文章按一条边界切开：A 文讲外部接口和生态分层，B 文讲内部控制面。A 文回答“Agent 如何和工具、数据、其他 Agent、用户界面、观测评估系统相连”；B 文回答“一个 coding agent 在本机如何循环、拦截、授权、扩展和复盘”。

内容 放在 A 文 放在 B 文
MCP / A2A / AG-UI 作为三类互操作协议，分别解释工具上下文、Agent 间协作、Agent 与 UI 同步 只讨论它们进入 runtime 后如何变成 tool、server、permission、trace
ANP / AGNTCY ACP / LMOS / Agora / AITP / agents.json 补全协议生态：去中心化网络、Agent 互联网基础设施、全栈平台、元协议、Agent 经济、Web 发现 不涉及
OpenAI Agents SDK、LangGraph、Google ADK、CrewAI、AutoGen/AG2、LlamaIndex、Semantic Kernel、Pydantic AI、Mastra、Strands Agents 作为 agent runtime / framework / platform 的生态层，说明它们和协议层的关系 只保留和 loop、hook、plugin、sandbox、trace 强相关的运行时判断
Observability / Evaluation / Trace 讲协议生态中的评估、观测、语义约定和跨框架工具 讲一次本机 coding agent 执行过程如何被 trace 复盘
Codex、Claude Code、OpenCode、OMC/OMX 只作为 runtime 层的例子点到为止 作为主体，拆解 hook、loop、插件、权限和编排层

先把地图画出来

Agent 生态里最容易混乱的地方，不是工具太多，而是不同名字站在不同层级上。MCP、A2A、AG-UI 是三条核心接口方向；ANP、AGNTCY ACP、LMOS、Agora、AITP、agents.json 分别从去中心化网络、Agent 互联网基础设施、全栈平台、元协议、Agent 经济、Web 发现等角度扩展协议版图；OpenAI Agents SDK、LangGraph、Google ADK、CrewAI、AutoGen、AG2、LlamaIndex、Semantic Kernel、Pydantic AI、Mastra、Strands Agents 是构建或运行 Agent 的 SDK、框架或 runtime；LangSmith、Phoenix、OpenTelemetry GenAI semantic conventions 属于观测和评估平面。

这些东西不能摊平成一个清单。MCP 解决 Agent 如何接工具和数据，A2A 解决 Agent 如何和另一个 Agent 互相发现、委托和交换结果，AG-UI 解决 Agent 如何把长时间、流式、可中断的执行过程接到用户界面。ANP 把 Agent 间通信推到去中心化的开放互联网，AGNTCY ACP 建设跨框架 Agent 互联网的基础设施层，LMOS 提供从 Agent 描述、发现到云原生编排的全栈平台协议，Agora 用 LLM 驱动运行时协议协商，AITP 在 Agent 通信里叠加支付和交易能力，agents.json 让网站像 robots.txt 一样对 Agent 可发现。Runtime 和框架负责 Agent 内部的循环、状态、工具调度、handoff、持久化、人工介入和部署。观测与评估负责回答运行后发生了什么、质量是否变好、改动有没有回归。

flowchart LR
    UI["User / UI"] <-- "AG-UI: event stream, shared state, interrupts" --> Runtime["Agent Runtime / Framework"]
    Runtime <-- "MCP: tools, resources, prompts" --> Tools["Tools / Data / Workflows"]
    Runtime <-- "A2A: discovery, task, message, artifact" --> Remote["Remote Agents"]
    Runtime <-- "ANP: DID identity, meta-protocol negotiation" --> Open["Open Internet Agents"]
    Runtime --> Obs["Observability / Evaluation"]
    Tools --> Obs
    Remote --> Obs

这个分层先把方向固定下来：

方向 代表 类型 连接的两端 主要问题
Agent ↔ Tools/Data MCP 协议 Agent 应用和外部工具、数据源、工作流 工具发现、工具调用、上下文接入
Agent ↔ Agent（受控环境） A2A 协议 独立 Agent 服务之间 能力发现、任务委托、结果交换
Agent ↔ Agent（开放网络） ANP 协议 跨组织、跨平台的去中心化 Agent 去中心化身份、信任建立、协议协商
Agent ↔ User/UI AG-UI 协议 用户界面和 Agent 后端 流式状态、交互事件、人工介入
Agent ↔ Web 服务 agents.json 规范草案 Agent 和网站/API 服务发现、能力声明、接口描述
Agent 内部运行 Agents SDK、LangGraph、ADK 等 SDK / 框架 / runtime 模型、工具、状态、流程控制 Agent 循环、编排、持久化、部署
运行质量 LangSmith、Phoenix、OTel GenAI 平台 / 标准 Trace、eval、prompt、dataset、experiment 可观测性、回归评估、质量改进

协议、SDK、框架、平台、产品不是一回事

协议是线上的契约。它定义消息格式、能力声明、错误处理、传输方式和交互边界。MCP、A2A、AG-UI 站在这个层级。协议本身不关心某个应用内部用不用 LangGraph，也不关心模型来自 OpenAI、Anthropic、Gemini 还是本地推理服务。

SDK 是某种语言里的开发包。MCP Python SDK、A2A JavaScript SDK、OpenAI Agents SDK 都是 SDK。SDK 可以实现协议，也可以封装一套运行时能力，但主要形态仍是给开发者调用的库。

框架和 runtime 负责 Agent 的内部执行。它们决定一个任务如何进入循环，工具如何被调用，状态如何保存，失败如何恢复，多个 Agent 如何交接。LangGraph 强调状态图和 durable execution；OpenAI Agents SDK 强调少量原语、工具、handoff、guardrail 和 tracing；Google ADK 把 agent 开发、运行、部署、评估放在同一套开发框架里。

平台和产品通常包含托管服务、控制台、权限、团队协作和运行数据。LangSmith 是观测、评估、prompt、部署平台；Phoenix 是 AI observability 与 evaluation 工作台；CrewAI Enterprise、Mastra Studio、Google Agent Runtime 也属于产品化或平台化方向。产品可以兼容协议，但产品不是协议。

一个工程判断可以先这样做：跨生态互通先看协议，应用内部结构先看 runtime，团队运维和质量闭环再看平台。

MCP：Agent 接工具和数据的协议

MCP 的官方定义很窄：它是连接 AI 应用和外部系统的开放协议，用来接数据源、工具和工作流。规范里把角色拆成 host、client、server：host 是 Claude Desktop、Claude Code、VS Code 这类 AI 应用；client 是 host 内部为某个 server 维护连接的组件；server 是暴露上下文和能力的程序。MCP 使用 JSON-RPC 2.0 消息，支持本地 stdio 传输和远程 Streamable HTTP 传输。

它解决的问题是典型的 N 乘 M 集成问题。没有协议时，每个 Agent 应用都要为每个数据库、SaaS、内部 API、文件系统、搜索服务写一套适配。MCP 把外部能力包装成可发现、可调用、可授权的 server。Agent 应用基于同一套 MCP client 能力接入不同 server。

MCP 的核心抽象有三类 server primitive：

抽象 含义 常见例子
Tools 可执行动作 查数据库、创建工单、调用内部 API、执行搜索
Resources 可读取上下文 文件、表结构、日志片段、知识库文档
Prompts 可复用交互模板 领域任务模板、few-shot 示例、工作流提示

规范还定义了 client 侧能力，例如 sampling、roots、elicitation 和 logging。这里有一个容易忽略的点：MCP 不是单向“Agent 调工具”。较新的规范已经允许 server 请求 host 侧模型采样，或者请求用户补充信息。但这些能力仍然围绕工具和上下文交换展开，不把 MCP 变成 Agent 编排框架。

适合 MCP 的场景有四类：

场景 MCP 的价值
内部系统工具化 把 CRM、工单、日志、数据库封装成标准工具
开发者工具 让 IDE、代码仓库、错误监控、CI 数据进入 Agent 上下文
企业知识接入 把分散在权限系统背后的数据以受控方式暴露
可组合工作流 把已有流程包装成 tool，而不是让 Agent 直接模拟 UI 操作

MCP 的边界同样要说清楚。第一，它不是 Agent-to-Agent 协议。一个远端 Agent 可以伪装成 MCP tool 暴露，但这样会丢掉 Agent 自身的任务状态、能力发现和 artifact 语义。第二，它不是安全系统本身。官方规范明确把用户同意、数据隐私、工具安全、LLM sampling 控制放在实现者责任里。第三，它不是 runtime。MCP server 只暴露能力，不负责决定 Agent 下一步该做什么。

工程模式可以简化成一个判断：听到“把某个外部能力接给 Agent 用”，优先想到 MCP；听到“让两个自治 Agent 协作”，不要把 MCP 当主协议。

A2A：Agent 服务之间的互操作协议

A2A 的问题空间和 MCP 不同。它关注的不是工具，而是 opaque agentic application 之间的互操作。A2A 官网把它定义为开放协议，用于不同框架、不同供应商构建的 Agent 之间通信和协作。官网还直接写明：A2A 不是 LangGraph、CrewAI、ADK 这类 agent development kit；不是 sub-agent 或 tool-call 协议；不是 MCP 的替代品。

A2A 的关键抽象是把 Agent 当成一个可发现、可调用、可返回结果的服务。

抽象 作用
Agent Card Agent 的能力、端点、认证、输入输出形式等元数据
Message Agent 之间交换的结构化消息
Task 一段可跟踪的委托执行过程
Artifact Task 产生的结构化结果或文件化产物
Status / Event 长任务的状态更新、流式进度和最终完成信号

A2A 的工程价值在于“保持内部不透明”。一个供应商可以用 ADK 写 Agent，另一个团队可以用 LangGraph 写 Agent，第三个系统可以是手写服务。只要外部暴露 A2A 约定的 Agent Card 和 task/message/artifact 语义，调用方不需要知道远端内部 memory、tool registry、prompt 或推理循环。

适合 A2A 的场景通常带有组织边界或服务边界：

场景 说明
跨团队专业 Agent 协作 订单 Agent 委托风控 Agent，风控 Agent 不暴露内部规则
跨供应商生态互通 一个平台上的 Agent 调用另一个平台提供的专用 Agent
长任务委托 调研、代码审查、数据分析这类任务需要状态、进度和 artifact
分布式 Agent 产品 不同服务各自维护身份、权限、日志和部署节奏

A2A 的边界也很重要。它不规定本地子 Agent 如何组织。本地 supervisor 该用状态图、group chat、handoff，还是队列驱动，仍由 runtime 决定。它不规定工具怎么调用，工具层仍然适合 MCP 或框架原生 tool calling。它不替业务定义任务质量，也不替企业完成身份、权限、审计和数据边界设计。

一个实用判断是：如果远端对象本质上能独立计划、执行、返回 artifact，并且应该保留内部实现不透明，就把它建模为 A2A Agent；如果远端对象只是一个函数、数据源或工作流入口，就把它建模为 MCP tool 或 resource。

A2A 的历史里有一条重要合流。IBM Research 在 2025 年 3 月为 BeeAI 平台发布了 Agent Communication Protocol（ACP），定位是 REST 原生、框架无关的 Agent 间通信协议。ACP 的核心设计包括 Agent Manifest 能力声明、MIME 类型多模态消息、SSE 流式传输、会话管理和 Agent 生命周期状态机。2025 年 8 月，ACP 在 Linux Foundation 治理下合入 A2A。BeeAI 随后迁移到 A2A 协议。ACP 的主要贡献——多模态消息格式、流式支持、企业 broker 模式和会话管理——已经被 A2A 规范吸收。选型时不需要在 A2A 和 IBM ACP 之间做选择，它们已经是同一条线。

AG-UI：Agent 后端和用户界面的事件协议

AG-UI 站在第三个方向：Agent ↔ User/UI。官方文档把它定义为开放、轻量、基于事件的协议，用来标准化 AI Agent 与面向用户的应用之间的连接。它关注 agent state、UI intent、用户交互如何在 model/agent runtime 和前端应用之间流动。

这层存在的原因很现实。传统 REST 或 GraphQL 默认是请求一次、返回一次，前端再渲染。Agent 应用不符合这个模型。一个 Agent 可能运行很久，过程中不断流式输出 token、调用工具、生成中间结果、等待用户批准、更新共享状态、触发前端动作，还可能被取消、恢复或重试。

AG-UI 把这些交互做成事件流。

抽象 作用
Events token、message、tool、state、interrupt、custom event 等运行事件
Messages 用户和 Agent 的对话消息
Shared State 前后端共享的结构化状态和增量更新
Interrupts 暂停、批准、编辑、重试、升级等 human-in-the-loop 控制
Frontend Tool Calls Agent 请求前端执行的受控动作
Generative UI Agent 产生可验证、可挂载的 UI 结构或组件意图

适合 AG-UI 的场景不是“聊天框”本身，而是用户需要参与 Agent 执行过程：

场景 AG-UI 的价值
长任务可视化 前端显示 Agent 的阶段、工具结果、进度和可取消状态
审批流 Agent 请求用户批准发邮件、建工单、改配置
协同编辑 用户和 Agent 同时修改同一个结构化对象
生成式 UI Agent 输出的不只是文字，还有表单、预览、图表、操作按钮
多模态交互 文本、文件、图片、音频、转写和注释进入同一事件模型

AG-UI 的边界是：它不负责工具接入，不替代 MCP；它不负责 Agent 服务之间的委托，不替代 A2A；它也不是完整前端框架。具体 UI 组件、权限校验、输入验证、危险动作确认，仍由应用层掌握。AG-UI 只是让 Agent 后端和用户界面用同一套事件语言说话。

三条协议不是替代关系

MCP、A2A、AG-UI 的关系可以用一个客服系统例子说明。

一个用户在前端提交“查一下订单为什么没到”。前端和主 Agent 之间走 AG-UI，界面实时显示查询进度、允许用户补充订单号、在需要退款时触发确认。主 Agent 通过 MCP 调订单库、物流 API、工单系统。发现问题可能涉及风控时，主 Agent 通过 A2A 把子任务委托给风控 Agent，风控 Agent 返回 artifact，例如风险结论、依据摘要和建议动作。

同一个请求里三条协议同时存在：

sequenceDiagram
    participant U as User Interface
    participant A as Support Agent Runtime
    participant M as MCP Servers
    participant R as Risk Agent
    participant O as Observability

    U->>A: AG-UI event: user message
    A->>M: MCP tools/list and tools/call
    M-->>A: order and logistics data
    A->>R: A2A task delegation
    R-->>A: artifact and status
    A-->>U: AG-UI state update and approval request
    A->>O: traces, eval signals, metrics

这张图也解释了边界：

问题 首选接口
Agent 要访问订单库 MCP
Agent 要委托远端风控 Agent A2A
前端要展示工具调用进度 AG-UI
主 Agent 如何决定下一步 Runtime / Framework
整个链路如何复盘质量 Observability / Evaluation

因此，MCP/A2A/AG-UI 不应被问成”谁会赢”。它们站在不同方向上，好的系统通常会同时用到其中两条甚至三条。

更多协议：从去中心化网络到 Agent 经济

MCP、A2A、AG-UI 覆盖了受控环境下的核心方向。但 Agent 生态正在向更多维度扩展：开放互联网上的身份和信任、跨框架基础设施、全栈平台、运行时协议协商、Agent 经济交易、Web 层面的服务发现。

ANP：面向开放互联网的去中心化 Agent 协议

MCP 和 A2A 都默认运行在受控环境里——企业内网、可信平台、已知身份。ANP（Agent Network Protocol）的出发点不同：当 Agent 需要在开放互联网上与陌生 Agent 交互，没有统一认证中心，没有预先注册的服务目录，怎么办。

ANP 的答案是三层架构：

层 职责
身份与加密层 基于 W3C DID（Decentralized Identifier）建立去中心化身份，did:wba 方法绑定 Agent 到域名，端到端加密通信
元协议协商层 Agent 之间协商使用哪种应用协议，而不是预先绑定某一种
应用协议层 实际的业务交互协议，由上一层协商确定

这个设计意味着 ANP 不和 A2A 竞争。A2A 适合平台内部或已知合作方之间的任务委托，ANP 适合跨组织、跨平台、无预设信任关系的场景。举例：一个旅行规划 Agent 需要在全网发现并对接不同航空公司、酒店、租车服务各自运营的 Agent，这些 Agent 之间没有统一注册中心，身份验证只能靠去中心化凭证。

ANP 目前仍在活跃开发中，2025 年 7 月发布，社区驱动。生态成熟度低于 MCP 和 A2A，生产部署需要评估 DID 基础设施的就绪程度。

AGNTCY 与 Agent Connect Protocol：Agent 互联网基础设施

AGNTCY（发音 agency）是 Cisco、LangChain、Galileo、LlamaIndex、Glean 等公司在 2025 年发起的开源联盟，目标是建设 Agent 互联网（Internet of Agents）的基础设施层。2025 年 7 月捐给 Linux Foundation，已有 60 多家企业参与，包括 Dell、Google、Oracle、Red Hat。

AGNTCY 的技术基础有两个支柱：

组件 作用
OASF（Open Agent Schema Framework） 标准化 Agent 描述格式，确保不同框架的 Agent 用统一方式声明能力
ACP（Agent Connect Protocol） OpenAPI REST 规范，定义一个 Agent 如何调用和配置另一个远程 Agent，包括认证、授权、错误处理

在 ACP 之上，AGNTCY 还定义了 AGP（Agent Gateway Protocol）作为路由层，基于 gRPC / HTTP/2 提供高性能消息传递，支持请求-响应、发布-订阅、流式等模式。整体 IoA 栈还包括 SLIM（Secure Low-latency Interactive Messaging）消息层、Agent Directory 目录服务和 Agent Identity 身份服务。

AGNTCY ACP 和 A2A 都解决 Agent 间互操作，区别在于层次定位：A2A 是协议规范本身，AGNTCY 是包含协议、网关、目录、身份、消息在内的完整基础设施栈。生产环境中两者可能共存，A2A 作为 Agent 间语义契约，AGNTCY 提供基础设施承载。

LangChain Agent Protocol：Agent 即服务的 REST 接口

LangChain 在 2024 年 11 月发布的 Agent Protocol 是另一种思路：不关心 Agent 之间如何发现和协商，只解决”把一个 Agent 部署为可调用的 REST 服务”。

协议围绕两个核心概念：Thread 持有对话上下文，Run 代表一次执行过程。客户端创建 Thread，启动 Run，异步检查进度，获取结果。LangGraph Platform 已经把 Agent Protocol 作为底层服务协议。

概念 作用
Thread 持久化对话上下文，支持多轮交互
Run 一次 Agent 执行，支持异步、流式输出
Async Subagent 远程 Agent Protocol 服务可作为异步子 Agent 被调用，跨 Run 保持状态

Agent Protocol 和 A2A 的区别在于：A2A 包含 Agent Card 能力发现、task 生命周期、artifact 语义和推送通知，面向的是跨供应商互操作；Agent Protocol 更接近 deployment API，面向的是同一团队或平台内部把 Agent 部署为服务。两者不互斥，一个 Agent 可以内部走 Agent Protocol 服务化，对外通过 A2A 暴露互操作接口。

LMOS：Eclipse 基金会的全栈 Agent 操作系统

Eclipse LMOS（Language Model Operating System）是 Eclipse Foundation 孵化的全栈 Agent 平台项目，最初由德国电信团队在 2023 年启动，用于支撑 Frag Magenta 数字助手在欧洲十个国家的部署。

LMOS 的协议层基于 W3C Web of Things（WoT）架构：

组件 作用
Agent Description Format 基于 JSON-LD 的标准化 Agent 和 Tool 描述，用 W3C DID 签名保证真实性
传输无关通信 不绑定 HTTP，支持 HTTP、MQTT、AMQP、P2P 等多种传输协议
Agent 发现 本地 mDNS 发现 + 联邦化分布式注册，支持 AT Protocol 等去中心化传播
分组管理 Agent 分组的创建、管理、信任关系维护

平台层基于 Kubernetes，包括 Agent Registry 注册中心、LMOS Runtime 动态路由、LMOS Router（支持 LLM、向量和混合三种路由方式）和 LMOS Operator。2025 年 10 月又发布了 Agent Definition Language（ADL），让领域专家用结构化语言定义 Agent 行为。

LMOS 和前面几个协议的区别在于它不只是通信协议，而是从描述、发现、路由、部署、编排到可观测性的全栈方案。这也意味着引入成本比单一协议高。适合需要在 Kubernetes 环境下规模化管理多 Agent 的企业场景。

Agora：牛津大学的元协议实验

前面所有协议都有一个隐含假设：通信协议在部署前就确定了。Agora 挑战这个假设。

Agora 由牛津大学工程科学系团队（Samuele Marro 等）在 2024 年 10 月提出，是一个元协议（zero-layer protocol）。核心思路是利用 LLM 的自然语言理解和代码生成能力，让 Agent 在运行时协商通信协议。

协商过程分三步：两个 Agent 初次交互时用自然语言对话；对话中提出 Protocol Document（PD），一份纯文本描述的协议规范；双方确认后用 PD 的 SHA1 哈希标识该协议，后续通信直接按 PD 执行，不再过 LLM。频繁通信的场景下，Agent 还会自动把 PD 编译成代码例程，进一步降低开销。

这个设计源于论文提出的 Agent 通信三难困境：通用性（支持多种消息格式）、效率（低计算和网络开销）和可移植性（低人工接入成本）三者不可同时最优。Agora 的策略是动态切换：罕见通信用自然语言保通用性，频繁通信用协商出的专用协议保效率，LLM 驱动协商保可移植性。

Agora 目前仍是学术概念验证，MIT 许可证。论文在 100 个 LLM Agent 的网络上验证了可扩展性，但没有开源框架实现。生产系统如果需要合规审计和确定性行为，让 Agent 自主协商通信规则的不确定性是一个实际障碍。Agora 的价值更多在于提供了一种思路：未来的 Agent 基础设施可能不是一组固定协议，而是一个能按需生成协议的元层。

AITP：面向 Agent 经济的交互与交易协议

Agent Interaction and Transaction Protocol（AITP）由 NEAR Foundation 在 2025 年 2 月以 RFC 形式发布。它要解决的问题是：Agent 之间不只是交换信息，还要完成经济交易——下单、支付、退款、竞价。

AITP 的核心抽象是 Thread（会话线程）和可扩展的 Capability Module：

模块 作用
AITP-01 支付能力：法币和加密货币
AITP-02 决策协商：多方竞价、谈判
AITP-03 数据查询：结构化数据交换
AITP-04/05 链上身份和钱包集成

一个典型场景是 Intent Resolution：用户的个人助理 Agent 向 Intent Agent 提交”需要一张飞迈阿密的机票”，Intent Agent 广播给多个 Solver Agent（航空公司 Agent），Solver Agent 竞价回复，Intent Agent 根据价格、信誉和匹配度选择最优方案，然后通过 AITP-01 完成支付。

AITP 和 A2A 的关系是互补的。A2A 关注任务委托和结果交换，不涉及支付和交易。AITP 在通信基础上叠加了经济层。AITP 兼容 OpenAI 对话格式，传输支持 HTTP、WebSocket 和 mailbox 中继。

需要注意的是，AITP 目前仍处于 RFC 草案阶段，生态集中在 NEAR AI Hub 周边。尽管协议设计标榜区块链无关，实际社区和集成仍以 NEAR 链为主。

agents.json：让网站对 Agent 可发现

agents.json 是一个社区草案，思路极其简单：网站在 /.well-known/agents.json 放一个 JSON 文件，声明该站点对 Agent 提供哪些接口、认证方式（OAuth2）、速率限制和使用策略。类似 robots.txt 告诉搜索引擎爬虫”哪些页面可抓取”，agents.json 告诉 Agent”哪些 API 可调用、怎么调用”。

字段 作用
端点列表 可用的 REST/GraphQL/WebSocket 接口
认证方式 OAuth2 等认证方法
速率限制 请求频率约束
使用策略 数据使用、隐私、许可条款
Agent 身份验证 调用方 Agent 的身份校验

agents.json 不是通信协议，是发现机制。它解决的是”Agent 怎么知道这个网站能干什么”，实际通信仍走 REST、GraphQL 或 WebSocket。目前还是草案阶段，没有正式组织背书，但部署成本几乎为零——放一个文件就行。

Runtime 和框架：Agent 内部怎么跑

协议定义外部接口，runtime 和框架定义内部生命体征。一个 Agent 至少要处理模型调用、工具注册、工具结果回填、短期上下文、长期记忆、失败重试、人工介入、多 Agent 交接、流式输出、审计追踪。不同框架的差异，不在于“能不能调 LLM”，而在于它把控制权交给谁。

项目 类型 核心抽象 适合场景 边界
OpenAI Agents SDK Python SDK / lightweight runtime Agent、Runner、Tools、Agents as tools、Handoffs、Guardrails、Sessions、Tracing、Sandbox agents Python 优先、希望用少量原语快速写出可追踪、多步骤、可 handoff 的 Agent 不是通用分布式协议；复杂状态机需要开发者设计或接其他 runtime
LangGraph 低层编排框架和 runtime StateGraph、node、edge、checkpoint、interrupt、streaming、time travel 长时间、可恢复、需要明确状态转移和人工介入的 Agent 抽象较低；prompt、业务架构和工具边界需要开发者建模
Google ADK 多语言 Agent 开发框架与 Agent Runtime LlmAgent、tools、sessions、memory、artifacts、graph workflows、multi-agent workflows、Agent Runtime、evaluation Google/Gemini/Cloud 生态，或者需要从开发、运行、部署、评估一体化推进 生态整合强，跨云或极简本地用法需要评估依赖边界
CrewAI 多 Agent 编排框架和平台 Agent、Task、Crew、Process、Flow、memory、knowledge、guardrails 角色分工清楚、业务流程可用“团队 + 任务”描述的自动化 角色与目标大量依赖自然语言约束；强一致控制流不如状态图直接
Microsoft AutoGen 多 Agent 应用框架 AgentChat、Core、Extensions、Studio、event-driven runtime 研究、多 Agent 对话、分布式或多语言 Agent 实验 名称和版本演进较多；从 0.2 到新版架构需要分清文档代际
AG2 多 Agent 框架 / AgentOS 取向 Conversable Agent、Group Chat、Swarm、tools、human collaboration 需要内置多 Agent conversation pattern 和人工协作的 Python 项目 与 Microsoft AutoGen 已经分叉，选型时必须明确文档和包名
LlamaIndex 数据增强 LLM 应用框架 data connectors、indexes、query engines、chat engines、agents、workflows RAG、文档理解、私有数据上的 Agent 和 workflow 它的强项是 context augmentation；纯控制流编排不是唯一重心
Semantic Kernel Microsoft 轻量开发 kit / middleware kernel、plugin、function、connector、prompt、existing API integration C#、Python、Java 企业代码库，把现有 API 暴露给模型调用 更像企业中间件和插件体系，不是专门的跨 Agent 互操作协议
Pydantic AI Python Agent 框架 Agent、dependency injection、typed output、tools/toolsets、MCP、A2A、AG-UI、evals、Pydantic Graph Python 类型系统重、重视结构化输出、验证、测试和可维护性的团队 类型安全不等于自动解决长任务编排；复杂 runtime 仍需配套设计
Mastra TypeScript Agent 应用框架 agents、memory、workflows、streaming、MCP、observability、evals、Studio 现代 TypeScript 栈、产品内嵌 Agent、前端后端同栈团队 主要服务 TS/JS 生态；跨语言 Agent 互通仍应靠协议层
Strands Agents Python / TypeScript Agent harness SDK Agent、tool、hooks、conversation manager、plugins、steering、trace attributes 需要端到端控制 agent harness、hook、guardrail、observability，尤其是 AWS 生态 SDK 不是协议；多组织互通仍要接 MCP、A2A 或其他外部接口

这个表不该被读成排行榜。更合理的读法是：

控制问题 更自然的选择
要精确控制状态转移和恢复 LangGraph、ADK Graph Workflows、Pydantic Graph
要少量原语快速落地 Python Agent OpenAI Agents SDK、Pydantic AI、Strands Agents
要业务角色和任务流 CrewAI、AG2、AutoGen AgentChat
要 RAG 和私有数据上下文 LlamaIndex
要企业代码库中间件和插件 Semantic Kernel
要 TypeScript 产品工程 Mastra
要托管部署和 Google Cloud 运行面 Google ADK + Agent Runtime

框架内部可以原生支持 MCP、A2A 或 AG-UI，但支持协议不等于框架本体就是协议。例如 OpenAI Agents SDK 支持 MCP server tool calling；ADK 文档列出 MCP、A2A、Agent Runtime、observability 和 evaluation；Pydantic AI 文档也把 MCP、AG-UI、A2A、Pydantic Evals 放进生态。但这些仍然是框架对外部接口的实现或集成。

Observability 和 Evaluation：横切面，不是另一个 Agent

Agent 系统上线后，最关键的问题从“能不能跑”变成“是否知道它怎么跑坏的”。普通服务看 request、latency、error、CPU 已经不够。Agent 还要看 prompt、model call、tool call、retrieval、handoff、state mutation、user interrupt、artifact、cost、token、judge score 和人工标注。

LangSmith、Phoenix 和 OpenTelemetry GenAI semantic conventions 分别站在不同层级：

项目 类型 解决的问题 边界
LangSmith 平台 / 产品 tracing、evaluation、prompt、dataset、experiment、deployment，支持跨框架 AI 应用 不是开放协议本身；深度体验和 LangChain/LangGraph 生态更近
Phoenix 开源 observability/evaluation 工作台 基于 trace 调试运行，做 eval、prompt 迭代、dataset 和 experiment 工具本身不替代埋点；质量指标仍要按业务定义
OpenTelemetry GenAI semantic conventions 标准 / 语义约定 给 GenAI、Agent、MCP、模型调用等 span、event、attribute 命名，便于跨工具互通 只定义遥测语义，不提供 UI、评估器或业务质量判断

Phoenix 官方文档明确写到它接收 OpenTelemetry OTLP traces，并基于 OpenInference instrumentation 支持常见框架、模型提供商和语言。OpenTelemetry 官方文档则把 Generative AI、Agent spans、MCP、OpenAI、Bedrock 等放进 semantic conventions 目录，并说明 GenAI conventions 已迁到单独仓库维护。这个走向说明：Agent observability 正在从“各家平台自定义 trace schema”往“标准语义 + 多平台消费”迁移。

一套可用的 Agent 质量闭环至少有四类信号：

信号 关注点
Trace 哪个模型、哪个工具、哪个 Agent、哪次 handoff、哪个 state update 导致结果
Metrics 延迟、token、成本、工具错误率、重试次数、人工介入率
Evaluation 正确性、忠实性、任务完成率、格式合规、风险动作误触发
Experiment 同一批 dataset 上比较 prompt、模型、工具描述、routing 策略

观测的边界也要克制。Trace 只能解释路径，不能保证路径正确；LLM-as-a-judge 可以降低人工成本，但不能替代业务金标准；指标变好不代表安全边界足够。Agent 质量是工程系统问题，observability 只是让问题可见。

一张工程选型速查表

听到需求关键词时，先映射到层级，再选具体项目：

需求关键词 所在层 候选
接内部 API、数据库、SaaS、文件系统 Agent ↔ Tools/Data MCP
远端 Agent 能力发现和任务委托 Agent ↔ Agent A2A
前端流式展示、审批、共享状态、生成式 UI Agent ↔ User/UI AG-UI
去中心化 Agent 发现、开放互联网身份 Agent ↔ Agent（去中心化） ANP
Agent 互联网基础设施、跨框架 Agent 调用 Agent ↔ Agent（基础设施） AGNTCY ACP
Agent 即服务 REST 部署 Agent 部署 LangChain Agent Protocol
全栈 Agent 平台、云原生编排 Agent 平台 LMOS
Agent 间运行时协议协商 元协议 Agora
Agent 交易和支付 Agent 经济 AITP
网站对 Agent 可发现 Agent ↔ Web agents.json
长任务、恢复、状态机、人工介入 Runtime / Framework LangGraph、ADK、Pydantic Graph
快速写 Python Agent loop Runtime / SDK OpenAI Agents SDK、Pydantic AI、Strands Agents
多角色、多任务业务自动化 Framework / Platform CrewAI、AG2、AutoGen
RAG、私有数据、文档理解 Framework LlamaIndex
TypeScript 产品应用 Framework Mastra
企业 C# / Java / Python 中间件 SDK / Middleware Semantic Kernel
Trace、eval、prompt、dataset、experiment Observability / Evaluation LangSmith、Phoenix
跨平台遥测字段标准化 Observability standard OpenTelemetry GenAI semantic conventions

更底层的判断公式是：

1
2
3
4
5
6
7
8
9
10
11
12
外部能力是工具或数据源 -> MCP
外部能力是自治 Agent 服务（受控环境） -> A2A
外部能力是开放互联网上的陌生 Agent -> ANP
外部交互对象是用户界面 -> AG-UI
需要跨框架 Agent 互联网基础设施 -> AGNTCY ACP
需要 Agent 即服务的 REST 部署 -> LangChain Agent Protocol
需要全栈 Agent 平台和云原生编排 -> LMOS
Agent 之间需要运行时协商协议 -> Agora
Agent 之间需要支付和交易 -> AITP
网站需要对 Agent 声明接口 -> agents.json
内部问题是循环、状态、编排、恢复 -> Agent Runtime / Framework
上线后问题是质量、回归、成本、复盘 -> Observability / Evaluation

这套公式比记工具名稳定。工具名会变，协议版本会变，框架会重构，产品会合并；方向不会轻易变。Agent 系统的边界只要还是”向工具取能力、向其他 Agent 委托、向开放网络建立信任、向用户交互、向 Web 声明接口、在 runtime 内执行、在观测平面复盘”，这张地图就能继续用。

参考资料

版本快照：以上链接按 2026-07-09 官方文档检索。MCP 官方 specification 页当前指向 2025-11-25 latest；A2A、AG-UI、ANP、AGNTCY ACP、LMOS、AITP、ADK、CrewAI、Pydantic AI、Mastra、Strands Agents 等文档仍在快速演进，正式引用前应重新确认对应版本。Agora 论文版本为 arXiv v1（2024-10）；agents.json 为社区草案，无正式版本号。