14.2 标准化演进

本节阐述智能体系统的标准化方向,包括MCP的技术演进、NIST标准化倡议、框架间互操作性以及智能体协议栈的完整生态。

14.2.1 MCP 的演进路线图

MCP(Model Context Protocol)采用日期版本号(如 2025-11-25),持续迭代演进,代表了智能体框架的标准化方向。

MCP 当前版本:

核心特性

  • 工具定义的通用格式(JSON Schema)

  • 客户端-服务器通信模型

  • 支持 stdio(本地子进程)和 Streamable HTTP(远程服务)两种传输层

  • Tasks 原语支持异步长时操作与进度推送

  • 动态工具注册(通过 notifications/tools/list_changed 通知)

当前限制

  • 工具定义虽支持动态注册,但大多数实现仍以启动时静态注册为主

  • 缺乏正式的智能体间通信标准

  • 企业级特性(审计、SSO、网关)仍在规划中

:早期版本曾使用 SSE(Server-Sent Events)作为独立传输层,已在 2025-03-26 版本中废弃,统一为 Streamable HTTP。

MCP 下一代演进:

特性1:动态能力协商

MCP 下一代版本规划中的动态能力协商,将引入“MCP Server Cards”实现无需连接即可发现服务能力:

应用场景

特性2:增强的持久化会话与流式通信

当前 MCP 已通过 Streamable HTTP 和 Tasks 原语支持基础的流式通信。下一代版本将进一步增强持久化会话能力:

特性3:智能体间通信标准

实现如下:

应用例:多智能体协作

MCP 演进时间线: 根据官方 2026 路线图,MCP 下一个规范版本计划于 2026 年 6 月发布,重点方向包括传输层无状态扩展、企业级特性(审计/SSO/网关)、以及 Tasks 框架增强(重试/过期策略):

图 14-3:MCP 标准演进路线图

14.2.2 NIST AI智能体标准化

NIST 的 CAISI(Center for AI Standards and Innovation)于 2026 年 2 月 17 日正式发起 AI Agent 标准化倡议,聚焦三大战略支柱:行业标准制定与国际标准话语权、开源协议社区发展、以及智能体安全与身份研究。其目标是建立 跨行业的智能体系统标准

NIST标准化的关键领域

1. 功能分类与能力等级

分类如下:

2. 安全性基线

评估方案如下:

3. 性能基准的标准化

标准任务集合如下:

标准化的长期目标已经清晰,但当前生态中各个框架各自为政,形成了事实上的碎片化。实现框架间的互操作性是推进标准化的重要一步,需要在工具定义、权限模型和通信协议等多个层面进行统一。

14.2.3 框架间互操作性

现状:碎片化

情景如下:

MCP 演进 + NIST标准的未来

架构如下:

互操作性的代码示例

示例如下:

14.2.4 从技术标准到行业生态

标准化的涟漪效应

14.2.5 智能体协议栈的完整版图

MCP 解决了“智能体如何调用工具”的问题,但智能体生态的完整通信需求远不止于此。2026 年已形成清晰的四层协议栈:

协议
职责
发起方
状态

MCP

智能体 ↔ 工具/数据源

Anthropic → Linux 基金会 AAIF

生产就绪

A2A

智能体 ↔ 智能体

Google,2026 初达 v1.0

早期采用

AG-UI

智能体 → 前端 UI(事件流)

CopilotKit 开源

社区驱动

A2UI

智能体 → 声明式 UI(JSON 描述)

Google

提案阶段

2025 年 12 月,Anthropic、Block、OpenAI 共同成立了 Agentic AI Foundation(AAIF),归属 Linux 基金会。Google 贡献了 A2A 协议,Anthropic 贡献了 MCP 协议。这标志着智能体通信协议从各自为政走向统一治理。

对 Harness 工程师而言,这意味着:

  • MCP 仍是 Harness 层最核心的协议,负责工具调用和数据访问

  • A2A 将影响多智能体编排的实现方式:当前基于私有消息传递的编排(如第 8 章所述),未来可能迁移到标准化的 A2A 协议上

  • AG-UI/A2UI 影响前端集成:智能体的中间状态和结果如何呈现给用户,将有标准化的事件流格式

  • Harness 需要成为协议网关:在不同协议之间做翻译和路由,而非只支持单一协议

14.2.6 OpenAI Codex App Server:另一条标准化路径

虽然MCP已成为事实标准,但2026年OpenAI发布的Codex App Server提示了标准化的另一种可能——专为IDE工作流优化的协议设计。

为何拒绝MCP

OpenAI团队在评估MCP作为100万行代码生成项目的基础协议时,遇到了根本性的限制:

MCP的工具模型(tool-oriented) 设计优秀,但缺乏表达IDE工作流的能力:

  • MCP聚焦“调用工具获取结果”的请求-响应模式

  • IDE工作流需要:流式代码diff、多轮审批流程、持久会话管理、双向交互

  • MCP缺乏这些原语的标准化定义,导致每个IDE集成都要自行扩展

Codex App Server的设计

Codex App Server采用了 JSON-RPC双向通信 模型,定义了三个核心原语:

1. Items (原子I/O单位)

  • 具有生命周期的可执行单元

  • 支持流式推送(如代码diff的增量推送)

  • 支持元数据和关联的approval对象

2. Turns (用户交互组)

  • 单个用户操作对应的Items集合

  • 原子性提交或回滚

  • 支持多轮交互的会话聚合

3. Threads (持久会话)

  • 跨越多轮用户交互的durable session

  • 完整的消息历史和执行状态持久化

  • 支持长期的代理决策追踪

服务端请求

与MCP的单向工具调用不同,Codex App Server支持 agent暂停后请求用户批准

这在IDE交互、高风险操作、长期规划修正中至关重要。

战略意义

Codex App Server的存在表明:

  • MCP不是全能的:工具调用的标准化已足够,但丰富的IDE集成需要不同的协议

  • 标准化是渐进的:不同的协议面向不同的use case,最终会形成分层的协议栈

  • Harness工程师需要多协议思维:未来系统会同时使用MCP、A2A、Codex App Server等多种标准


本节总结:标准化(MCP 持续演进、NIST CAISI 倡议)将 Harness 工程从“野生西部”转变为“规范产业”。对工程师而言,意味着更少的碎片化、更强的可移植性、更高的行业认可度。对企业而言,意味着风险降低、成本优化、生态互联。

最后更新于