两篇文章的最终定位

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

内容 放在 A 文 放在 B 文
MCP / A2A / AG-UI 作为三类互操作协议，分别解释工具上下文、Agent 间协作、Agent 与 UI 同步 只讨论它们进入 runtime 后如何变成 tool、server、permission、trace
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 是三条接口方向；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 如何把长时间、流式、可中断的执行过程接到用户界面。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 --> Obs["Observability / Evaluation"]
    Tools --> Obs
    Remote --> Obs

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

方向 代表 类型 连接的两端 主要问题
Agent ↔ Tools/Data MCP 协议 Agent 应用和外部工具、数据源、工作流 工具发现、工具调用、上下文接入
Agent ↔ Agent A2A 协议 独立 Agent 服务之间 能力发现、任务委托、结果交换
Agent ↔ User/UI AG-UI 协议 用户界面和 Agent 后端 流式状态、交互事件、人工介入
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。

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 不应被问成“谁会赢”。它们站在不同方向上，好的系统通常会同时用到其中两条甚至三条。

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
长任务、恢复、状态机、人工介入 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
外部能力是工具或数据源 -> MCP
外部能力是自治 Agent 服务 -> A2A
外部交互对象是用户界面 -> AG-UI
内部问题是循环、状态、编排、恢复 -> Agent Runtime / Framework
上线后问题是质量、回归、成本、复盘 -> Observability / Evaluation

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

参考资料

版本快照：以上链接按 2026-06-13 官方文档检索。MCP 官方 specification 页当前指向 2025-11-25 latest；A2A、AG-UI、ADK、CrewAI、Pydantic AI、Mastra、Strands Agents 等文档仍在快速演进，正式引用前应重新确认对应版本。