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”实现无需连接即可发现服务能力：

# MCP 下一代 - 动态能力协商
@dataclass
class CapabilityQuery:
    """智能体查询可用能力"""
    agent_id: str
    required_capabilities: List[str]  # ["read_file", "write_file"]
    optional_capabilities: List[str]
    resource_constraints: dict        # {"memory_mb": 512, "timeout_sec": 30}

@dataclass
class CapabilityOffer:
    """服务提供的能力"""
    capabilities: List[ToolDefinition]
    cost: dict                        # {"latency_ms": 100, "cost_usd": 0.001}
    constraints: dict                 # {"rate_limit": 100_per_hour}

async def negotiate_capabilities(query: CapabilityQuery) -> CapabilityOffer:
    """动态协商能力

    LLM不再依赖启动时加载的工具列表,而是在运行时查询可用能力
    """
    pass

应用场景：

# 示例：智能体需要处理PDF,检查是否有能力
query = CapabilityQuery(
    agent_id="data-analyzer",
    required_capabilities=["read_pdf", "extract_text"],
    optional_capabilities=["ocr_scan"],
    resource_constraints={"memory_mb": 256}
)

# MCP 服务返回可用的实现
capabilities = await mcp_server.negotiate(query)

if "read_pdf" in capabilities:
    # 使用该能力
    pdf_content = await agent.call_tool("read_pdf", file_path="doc.pdf")
else:
    # 降级方案：上传到云服务
    await agent.call_tool("upload_to_cloud", file_path="doc.pdf")

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

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

# MCP 下一代 - 增强持久化会话
class StreamingMCPSession:
    """支持流式通信的持久化会话"""

    async def open_stream(self, agent_id: str) -> Stream:
        """打开持久化流"""
        # 保持连接开放,支持实时推送(而不仅是请求-响应)
        pass

    async def push_event(self, event: Event):
        """服务器主动推送事件到智能体"""
        # 例：外部事件到达,直接推送给Agent
        # 当前MCP通过SSE支持服务端推送,但缺乏完整的事件订阅机制
        pass

    async def bidirectional_tool_call(self):
        """工具可以回调Agent"""
        # 当前：智能体 -> 工具(单向为主)
        # 下一代：工具 -> 智能体(完整的反向调用支持)
        # 应用：工具需要智能体决策时
        pass

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

实现如下：

# MCP 下一代 - 智能体间通信
@dataclass
class AgentMessage:
    from_agent: str
    to_agent: str
    message_type: str              # "request", "response", "event"
    content: dict
    correlation_id: str            # 追踪相关消息

class MCP2AgentCommunication:
    """MCP 下一代支持的智能体间通信"""

    async def send_message(self, msg: AgentMessage) -> None:
        """智能体A发送消息给智能体B"""
        # MCP 下一代定义了标准的消息路由
        pass

    async def broadcast_event(self, event: dict, target_group: str) -> None:
        """广播事件到智能体组"""
        # 类似发布-订阅
        pass

    async def request_capability(self,
                                requesting_agent: str,
                                capability: str,
                                params: dict) -> Any:
        """跨智能体能力请求"""
        # 智能体A要求智能体B执行某个能力
        pass

应用例：多智能体协作

async def collaborative_data_analysis():
    """多智能体协作分析(MCP下一代版本支持)"""

    # 智能体A(爬虫)向智能体B(分析员)发送数据
    message = AgentMessage(
        from_agent="scraper_agent",
        to_agent="analyst_agent",
        message_type="request",
        content={"data": scraped_data, "analysis_type": "statistical"}
    )

    await mcp_server.send_message(message)

    # 智能体B接收并处理
    result = await analyst_agent.process_request(message)

    # 智能体B响应智能体A
    response = AgentMessage(
        from_agent="analyst_agent",
        to_agent="scraper_agent",
        message_type="response",
        content=result
    )

    await mcp_server.send_message(response)

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. 功能分类与能力等级

分类如下：

Level 1: 基础工具调用
  - 单步工具调用
  - 简单参数
  - 示例：单个文件操作、查询API

Level 2: 多步推理
  - 多步工具链
  - 错误恢复
  - 示例：复杂数据分析、问题求解

Level 3: 自适应规划
  - 动态工具选择
  - 目标分解
  - 示例：长期项目规划、复杂系统设计

Level 4: 多智能体协调
  - 智能体间通信
  - 分布式执行
  - 示例：组织协作、跨域问题解决

Level 5: 持久自主系统
  - 长期记忆
  - 自主学习
  - 示例：智能体操作系统、完全自驱助手

2. 安全性基线

评估方案如下：

class NISTSecurityBaseline:
    """NIST定义的智能体安全基线"""

    @staticmethod
    def evaluate_system(agent_system) -> SecurityReport:
        """评估系统的安全合规性"""

        report = SecurityReport()

        # Category 1: 工具调用安全
        report.tool_safety = {
            "dangerous_command_detection": True,      # 12.3
            "path_validation": True,                  # 12.4
            "parameter_validation": True,
            "rate_limiting": True,
        }

        # Category 2: 隐私保护
        report.privacy = {
            "data_minimization": check_data_minimization(agent_system),
            "encryption_at_rest": check_encryption(agent_system),
            "access_control": check_access_control(agent_system),
            "audit_logging": check_logging(agent_system),
        }

        # Category 3: 可靠性
        report.reliability = {
            "failure_handling": check_error_handling(agent_system),
            "recovery_capability": check_recovery(agent_system),
            "health_monitoring": check_monitoring(agent_system),
            "graceful_degradation": check_degradation(agent_system),
        }

        # Category 4: 可解释性
        report.interpretability = {
            "decision_traceability": check_traceability(agent_system),
            "reasoning_transparency": check_transparency(agent_system),
            "human_oversight": check_oversight(agent_system),
        }

        # 合规评分
        report.compliance_score = compute_score(report)

        return report

3. 性能基准的标准化

标准任务集合如下：

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

14.2.3 框架间互操作性

现状：碎片化

情景如下：

MCP 演进 + NIST标准的未来

架构如下：

互操作性的代码示例

示例如下：

# MCP + NIST 标准下的互操作性
from mcp import MCPClient, CapabilityQuery

class FrameworkAgnosticAgent:
    """框架无关的智能体(未来)"""

    def __init__(self):
        self.mcp_client = MCPClient()

    async def use_tool(self, tool_name: str, **kwargs):
        """使用任何通过MCP暴露的工具,无论来自哪个框架"""

        # 1. 查询工具能力
        tool_spec = await self.mcp_client.query_tool(tool_name)

        # 2. 验证NIST安全基线
        assert tool_spec.is_nist_compliant()

        # 3. 调用工具(框架无关)
        result = await self.mcp_client.call_tool(
            tool_name=tool_name,
            args=kwargs,
            timeout=tool_spec.recommended_timeout
        )

        return result

    async def migrate_to_new_framework(self, new_framework_name: str):
        """迁移到新框架

        由于使用了标准化工具和通信,迁移成本大幅降低
        """

        # 1. 导出当前智能体的定义(MCP标准格式)
        agent_definition = await self.export_mcp_definition()

        # 2. 在新框架中导入
        new_agent = await new_framework.import_agent(agent_definition)

        # 3. 由于工具定义标准化,不需要重新绑定工具
        return new_agent

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暂停后请求用户批准：

{
  "method": "request_approval",
  "params": {
    "turn_id": "turn_123",
    "action": "apply_changes",
    "changes": {...},
    "rationale": "..."
  }
}

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

战略意义

Codex App Server的存在表明：

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

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

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

---

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