互操作为何重要：M×N 问题

深入解析 · 协议与互操作

互操作为何重要：M×N 集成问题。

智能体（agent）的价值取决于它能触达的系统。本文剖析手工把 M 个智能体连接到 N 个工具与数据源所带来的组合爆炸成本，并解释为什么真正的结构性解法是一个协议层——而非更多胶水代码——这也是整个生态在 2024–2025 年间收敛到的方向。

STEP 1

智能体 = 模型 + 它能触达的一切。

语言模型本身是一个封闭函数：文本进、文本出。当它能够调用工具、读取外部资源、并对自身并不包含的系统采取行动时——一个数据库、一个工单 API、一个文件系统、另一个智能体——它才成为智能体。模型的推理是最容易复用的部分；一次 API 调用就能把 Claude 换成 GPT 或某个开源模型。真正困难的是集成面：智能体能调用的每个工具、能读取的每个数据源、能委派的每个下游服务。

这个集成面不会在智能体之间免费迁移。如果你为客服智能体与 CRM 之间构建了一套深度集成，这些工作对你的数据分析智能体连接同一个 CRM 毫无帮助。每个智能体都要重新实现连接处理、认证、模式（schema）描述、错误语义和结果整形。模型是可替换的；管道不是。

本文是协议系列其余部分的概念脚手架。后续文章会具体讨论工具调用模式、模型上下文协议（MCP）以及智能体间通信。先读本文，理解这些协议为何存在。

STEP 2

组合爆炸：M 个智能体 × N 个集成。

设想一个组织拥有 M 个不同的智能体（客服、销售分析、代码评审、运维手册）以及它们各自可能需要的 N 个系统（CRM、数据仓库、Git 托管、可观测性栈、内部 wiki）。在朴素做法下，每个智能体都独立地与它需要的每个系统集成。集成数量随乘积 M × N 增长，而非和 M + N。

4 个智能体和 6 个系统，意味着潜在多达 24 套定制集成，每套都有自己的认证流程、自己手写的工具描述、自己脆弱的响应解析。再加第 5 个智能体，你就欠下多达 6 套。某个系统升级 API，你就得重新测试每个用过它的智能体。这正是编辑器工具领域催生语言服务器协议（LSP）的同一个陷阱：一旦有了共享协议，M 个编辑器乘以 N 种语言就坍缩为 M + N。

# Naive coupling: every agent owns every integration
support_agent     -> crm_client_v1, warehouse_client, wiki_scraper
analytics_agent   -> crm_client_v2, warehouse_client, dashboards_api
codereview_agent  -> git_client, ci_client, wiki_scraper
ops_agent         -> observability_client, git_client, runbook_store
# 4 agents, ~10 reimplemented clients, drifting versions (crm v1 vs v2)

成本不仅是初次构建，还有漂移：客服智能体的 CRM 客户端与分析智能体的 CRM 客户端逐渐分化，编码了不同的假设，以不同方式失败。没有一个统一的地方去修 bug、加能力或审计某个智能体被允许做什么。

STEP 3

协议把 M×N 变成 M+N。

结构性解法是一层间接：一个双方都讲的共享协议。每个系统被包装一次，成为讲协议的服务器。每个智能体实现一次协议客户端。这样任何合规的智能体都能触达任何合规的系统，二者之间无需定制代码。集成数随 M + N 增长：包装每个系统的 N 个服务器，教会每个智能体协议的 M 个客户端。

Before:  agent_i  ──bespoke──>  system_j        cost ≈ M × N
After:   agent_i  ──client──>  PROTOCOL  ──server──>  system_j
                                                      cost ≈ M + N

这正是模型上下文协议（由 Anthropic 于 2024 年底推出）在智能体-工具/资源边上的押注，也是诸如 Google 的 Agent2Agent（2025 年发布）等智能体间协议在智能体-智能体边上的押注。二者都用一个经过协商的、带版本的接口取代点对点胶水。协议并不会让集成逻辑消失——它把逻辑搬到每个系统一处可复用的地方，并标准化能力如何被描述、调用与流式回传。

三个特性让这层间接物有所值：

复用。为某个智能体写的服务器对每个合规智能体都有效——包括服务器构建时还不存在的智能体。
可发现性。智能体可以在运行时问服务器你能做什么？，而不是在构建时硬编码能力。能力发现在本系列后文有专文。
统一语义。一套错误模型、一套流式模型、一套认证方案——于是智能体的循环无需为每个集成分支。

STEP 4

协议解决不了什么。

间接不是免费的，协议也不是魔法。三个诚实的告诫为本系列其余部分定调：

语义仍会泄漏。协议标准化的是信封——工具如何被描述、调用与返回——而非工具的含义。两个 CRM 服务器都可以合规，却暴露差异巨大的工具词汇。传输与模式层的互操作并不保证任务层的互操作。

信任边界是移动，不是消失。把系统包装为服务器，意味着智能体现在能通过统一通道驱动该系统。这种统一性本身就是安全面：被连接的服务器可以返回影响模型的内容（提示注入向量），被攻陷的服务器是"被混淆的代理（confused deputy）"风险。本系列只做概念交叉链接；协议安全、权限范围与信任的专门论述见"安全、对齐与智能体安全"深入探讨系列。

"它讲这个协议"是关于形状的陈述，不是关于安全的。永远不要把协议合规当作授权。能力范围、最小权限与内容来源溯源是独立且强制的关注点，由安全系列覆盖。

版本管理是永久的。一旦 M 个客户端与 N 个服务器共享一个接口，该接口就必须在没有"统一切换日"的情况下演进。成熟协议从第一天起就内建版本协商与能力标志，正是为了让这张 M+N 图能够增量升级，而非一次性全量升级。

贯穿本系列的主线

后续每篇文章都是对"如何把协议层落到实处"某个子问题的回答：工具如何用 JSON Schema 自描述（工具调用标准），智能体-资源边如何组织（MCP 架构），智能体如何委派给其他智能体（A2A 通信），有类型的输入输出如何校验（结构化工具 I/O），客户端如何得知服务器提供什么（能力发现），以及这一切如何被组装成一个集成干净的智能体（构建可互操作的智能体）。统一主张就是本文这一句：优先选择协议，而非 M × N 套手写桥接。