1. 从“删掉薄封装”说起MCP 不是突然消失而是被架构演进自然淘汰最近在几个技术群和开源项目 Issue 区里反复看到一句带着点唏嘘语气的提问“MCP 真的要退出历史舞台了吗”——不是问它有没有 bug也不是问它能不能用而是直接在问它的存在必要性。这句话背后藏着一个被很多人忽略的事实MCPModel Control Protocol从来就不是一个独立运行的“产品”而是一套特定历史阶段下为解决“模型能力暴露不统一”问题而生的临时性协议层封装。我最早接触 MCP 是在 2022 年底当时团队在做一套面向内部研发人员的 LLM 工具链。我们手上有三个模型服务一个是本地部署的 Llama-3-70B 推理 API一个是云厂商提供的 Claude 封装接口还有一个是自研的 RAG 检索增强服务。三者返回格式五花八门有的带response.choices[0].message.content有的直接返回纯文本流有的甚至把 metadata 和 content 混在一个 JSON 字段里。前端同学每次对接一个新模型就要重写一遍解析逻辑后端同学每次加一个新模型就要补一段 if-else 转换器。那会儿大家管这种“模型适配层”叫“薄封装”——轻量、临时、谁都能写但谁都不想维护。MCP 就是在这个背景下被提出来的。它本质上定义了一套最小公约数一个标准的 HTTP POST 接口路径/v1/chat/completions一套固定的请求体字段model,messages,stream一套可预期的响应结构含id,choices,usage。它不规定你模型怎么训、怎么部署、怎么调度只管“你对外长什么样”。这很像当年 RESTful API 刚兴起时大家约定用GET /users获取列表、POST /users创建用户——不是因为技术多先进而是因为“不统一协作成本就爆炸”。但问题来了当“薄封装”开始变厚当“协议”开始承担不该它承担的职责它就走到了生命周期的拐点。我亲眼见过两个典型转折点第一个是某大厂在 MCP 基础上硬塞进“工具调用”function calling字段结果不同模型对tools数组的解析逻辑千差万别MCP 的“最小公约数”瞬间崩塌第二个是团队引入 Agent 编排框架后发现 MCP 的单次请求-响应模型根本无法表达“思考-调用-观察-再思考”的循环链路硬套上去的结果是每个 Agent Step 都要包装一层 MCP 请求性能损耗翻倍错误追踪变成噩梦。所以“删掉薄封装”不是一句情绪化口号而是一个明确的技术决策信号当协议层开始阻碍而非促进上层架构演进时它的使命就结束了。这不是 MCP 设计得不好恰恰相反它完成得太过成功——成功到让所有人忘了它本该是个过渡方案。就像 TCP/IP 协议栈里的 ARP 协议没人说它“过时”但它只在局域网二层寻址这个特定场景里发光发热一旦你进入 Service Mesh 或 Serverless 场景ARP 就自动退居幕后由更上层的机制接管。提示判断一个协议是否该被替代关键看它是否还在“做减法”。MCP 最初做的是“减去模型差异”后来却被迫做“加法”——加流式控制、加工具描述、加 session 状态。一旦协议开始膨胀说明抽象层级错了。2. Agent 连接架构的三重跃迁从“协议对齐”到“语义连接”当团队决定“删掉 MCP”时真正要解决的从来不是“怎么发请求”而是“Agent 怎么可靠、可扩展、可调试地与外部能力协同”。这背后是一场静默却深刻的架构范式迁移从基于 HTTP API 的协议对齐转向基于能力契约的语义连接。这个转变不是一蹴而就的而是经历了三个清晰的阶段跃迁。2.1 第一阶段HTTP API 层的“胶水代码”时代2022–2023这是 MCP 最活跃的时期。典型架构是Agent Core如 LangChain 的 AgentExecutor → MCP Adapter将 Agent 的 Tool Call 转成 MCP 格式 → 外部服务模型 API / 数据库 / 第三方 SaaS。所有连接都通过标准 HTTP 完成看似干净实则暗藏三重脆弱性类型脆弱性MCP 规定messages是数组但没规定数组里每个message的role字段必须是user/assistant/system。某次上游模型服务升级把role: human改成role: user整个 Agent 流程因字符串匹配失败而卡死日志里只有一行KeyError: user。流控脆弱性MCP 的stream: true只保证响应是 SSE 流但不保证流内 chunk 的语义完整性。我们曾遇到一个模型服务在流式返回时把一个完整的 JSON 对象切成两半发送前半段在 chunk1后半段在 chunk2Agent 解析器直接崩溃因为json.loads()遇到不完整 JSON。错误语义脆弱性HTTP 状态码 429Too Many Requests和 503Service Unavailable在 MCP 里都被映射成统一的RateLimitError但前者是客户端该退避后者是服务端故障需熔断——Agent 却无法区分导致重试策略全乱套。这个阶段的“连接”本质是字节流层面的管道对接靠大量胶水代码Adapter强行弥合语义鸿沟。我统计过当时一个中等复杂度的 Agent 项目约 35% 的代码量花在各种 Adapter 的编写和维护上且几乎全是重复劳动。2.2 第二阶段CLI 工具链驱动的“进程间通信”2023–2024转折点来自一次意外团队需要接入一个只能通过命令行交互的遗留系统某定制化数据清洗工具。写 HTTP Adapter 成本太高干脆用 Python 的subprocess.run()直接调 CLI。结果发现CLI 的输入输出反而比 HTTP 更稳定——输入是确定的参数字符串输出是确定的 stdout/stderr错误码是确定的 exit code。更重要的是CLI 天然支持“状态隔离”每次调用都是全新进程不会像 HTTP 连接那样有长连接状态污染。于是我们开始系统性重构连接方式。核心思路是把所有外部能力抽象为“可执行命令”Agent 通过标准输入/输出与之通信。例如模型调用llm-inference --model llama3-70b --prompt 你好 --stream数据库查询db-query --dsn mysql://... --sql SELECT * FROM users文件处理pdf-extract --input report.pdf --output text这些 CLI 工具由各能力提供方自己维护遵循统一的输入输出契约如输入必须是 JSONL 格式输出必须是带status字段的 JSON。Agent Core 只需关注如何拼装命令、解析 stdout、处理 exit code。我们为此开发了一个轻量级 CLI Runner核心逻辑不到 200 行 Pythonimport subprocess import json from typing import Dict, Any def run_cli(cmd: str, input_data: Dict[str, Any]) - Dict[str, Any]: try: result subprocess.run( cmd.split(), inputjson.dumps(input_data).encode(), capture_outputTrue, timeout30 ) if result.returncode 0: return json.loads(result.stdout.decode()) else: return { status: error, code: result.returncode, message: result.stderr.decode() } except subprocess.TimeoutExpired: return {status: error, code: -1, message: timeout}这个阶段的连接从“网络协议”下沉到“操作系统进程”稳定性大幅提升。我们线上环境的 Agent 调用失败率从 HTTP 时代的 8.2% 降到 1.3%且 90% 的错误都能通过 exit code 精准归类。CLI 的另一个巨大优势是调试友好性任何问题运维同学只要在服务器上手动执行一遍相同命令就能复现无需抓包、无需模拟 HTTP Header。2.3 第三阶段基于能力契约的“语义连接”2024–至今CLI 解决了稳定性但带来了新问题启动进程开销大、无法共享内存、难以做细粒度权限控制。真正的破局点是把“连接”从“如何调用”升维到“调用什么”。我们不再问“这个模型 API 怎么发请求”而是问“这个能力能做什么、不能做什么、代价是什么”。我们定义了一套极简的能力契约Capability Contract每个外部服务必须提供一个capability.json文件内容类似{ id: llm-llama3-70b, name: Llama3-70B 推理服务, description: 支持流式响应的通用大语言模型, input_schema: { type: object, properties: { prompt: {type: string}, max_tokens: {type: integer, default: 512}, temperature: {type: number, default: 0.7} } }, output_schema: { type: object, properties: { response: {type: string}, usage: {type: object, properties: {prompt_tokens: {type: integer}}} } }, cost: {per_token: 0.000001, per_call: 0.001}, reliability: {uptime: 0.9995, p95_latency_ms: 1200} }Agent Core 在运行时先加载所有capability.json构建一个能力目录Capability Registry。当 Agent 决定调用某个能力时不是硬编码 URL 或命令而是向 Registry 查询“谁支持input_schema.prompt且cost.per_token 0.000002” Registry 返回匹配的能力 IDAgent 再根据该 ID 的元信息是 HTTPCLI还是 gRPC选择对应执行器。这个架构下“连接”变成了能力发现 执行路由。MCP 的消亡不是终点而是起点——它迫使我们把原本隐含在协议里的语义比如“这个接口能干啥”“它有多贵”“它稳不稳”显式化、结构化、可编程化。这才是 Agent 架构真正成熟的标志连接不再是技术细节而是业务策略的一部分。注意能力契约不是越复杂越好。我们刻意避免在capability.json中定义传输协议HTTP/gRPC/CLI因为那是执行器的事也避免定义认证方式API Key/OAuth因为那是安全网关的事。契约只回答三个问题它能做什么输入输出、代价多少成本、表现如何可靠性。3. “删掉薄封装”后的实操落地一个可复用的 Agent 连接架构模板光讲理念不够我直接给出我们在生产环境跑了一年多的 Agent 连接架构模板。它不是理论模型而是从真实踩坑中提炼出的、可直接抄作业的工程方案。整个架构分三层能力注册层、执行路由层、具体执行器层。下面逐层拆解重点讲清楚每个环节为什么这么设计、容易踩什么坑、我们是怎么绕过去的。3.1 能力注册层用 GitOps 管理capability.json拒绝运行时魔法很多团队一上来就想搞个“能力中心”微服务结果半年后发现这个服务成了新的单点故障而且更新一个能力描述要走 CI/CD 流水线慢得让人抓狂。我们的解法极其朴素把所有capability.json文件放在一个 Git 仓库里用 Git 作为能力注册中心。仓库结构很简单capabilities/ ├── llm/ │ ├── llama3-70b/ │ │ └── capability.json │ └── claude-sonnet/ │ └── capability.json ├── data/ │ └── mysql-prod/ │ └── capability.json └── tools/ └── pdf-extractor/ └── capability.json每个capability.json必须通过 CI 流水线校验JSON Schema 合法性用jsonschema库input_schema和output_schema必须是有效的 JSON Schema Draft-07cost.per_token和cost.per_call必须是正数reliability.uptime必须在 0.9–1.0 之间校验通过后CI 自动触发一个 GitHub Action将该文件同步到一个 S3 存储桶或 MinIO并更新一个index.json文件内容是所有能力的 ID 列表。Agent 启动时只做一件事从 S3 下载最新的index.json然后并发下载所有capability.json文件到本地缓存目录如/tmp/capabilities。整个过程不到 2 秒且完全离线可用——即使 S3 挂了Agent 也能用本地缓存继续工作。这个设计解决了三个致命问题变更可见性谁改了哪个能力的描述Git Log 一目了然再也不用问“这个字段什么时候加的”回滚简单性某次上线后发现llama3-70b的max_tokens默认值设错了git revert一行命令搞定不用改代码、不用发版。环境一致性开发、测试、生产环境用的capability.json完全一致因为它们都指向同一个 Git Commit Hash。实操心得我们给每个capability.json加了一个version字段如version: 2024.06.15-1格式是YYYY.MM.DD-序号。这样即使 Git Commit Hash 变了也能快速定位到某次变更的具体时间点。版本号由 CI 自动生成开发者无需关心。3.2 执行路由层基于策略的动态选择器让 Agent “懂权衡”有了能力列表下一步是“选谁”。传统做法是写死if model llama3 then use_http_adapter这又回到了胶水代码的老路。我们的方案是Agent 在调用前先向一个策略引擎提交“能力需求”引擎返回最优能力 ID 和执行方式。策略引擎的核心是一个可插拔的规则引擎。默认规则很简单功能匹配优先input_schema必须兼容当前请求的参数用jsonschema.validate校验成本最低优先在功能匹配的能力中选cost.per_token最小的那个可靠性兜底如果所有匹配能力的reliability.uptime 0.999则降级到备用能力如llm-fallback但规则可以随时扩展。比如某天市场部要求“所有面向客户的问答必须用 Claude哪怕贵 3 倍”我们只需加一条规则# rules/cost_vs_brand.py def apply_rule(capabilities, request): if request.get(audience) customer: return [c for c in capabilities if claude in c[id]] return capabilities策略引擎返回的不只是能力 ID还有execution_method字段值为http,cli, 或grpc。Agent Core 根据这个字段从执行器池中取出对应的执行器实例。执行器池是单例预先初始化好所有可能用到的执行器HTTP Session、CLI Runner、gRPC Channel避免每次调用都创建新连接。这里有个关键细节我们强制要求所有执行器实现统一的execute()接口class Executor(ABC): abstractmethod def execute(self, capability_id: str, input_data: dict) - dict: passHTTPExecutor 的实现是发请求CLIExecutor 的实现是subprocess.run()gRPCExecutor 的实现是调用 stub 方法。Agent Core 完全不知道底层怎么连只认这个接口。这让我们在某次压测中发现 HTTP 连接池瓶颈时能用一个下午就把所有llm-*能力的执行方式从http切成cli零代码修改只改了capability.json里的execution_method字段。3.3 具体执行器层CLI 执行器的深度优化实践CLI 执行器是我们用得最多、也最值得展开讲的。网上很多教程只说“用 subprocess 调 CLI”但生产环境远比这复杂。我们针对 CLI 执行做了四层加固第一层沙箱隔离绝不允许 CLI 工具直接访问宿主机文件系统。所有 CLI 工具都运行在firejail沙箱中firejail --quiet --noprofile --netnone \ --private/tmp/cli-workdir \ --whitelist/usr/bin/python3 \ --whitelist/app/tools/llm-inference \ /app/tools/llm-inference --prompt $INPUT--private创建独立临时目录--netnone禁用网络--whitelist只允许访问指定路径。这样即使某个 CLI 工具被注入恶意代码也无法读取/etc/passwd或发起外网请求。第二层输入输出标准化我们强制所有 CLI 工具遵循“JSONL 输入JSON 输出”规范输入Agent 将input_data序列化为 JSON 字符串通过 stdin 传入输出CLI 工具必须将结果序列化为 JSON 字符串写入 stdout错误信息写入 stderr我们提供了一个通用 CLI 模板Python开发者只需填空process_input()和generate_output()函数其余框架代码沙箱调用、超时控制、日志埋点全部内置。第三层资源限制用cgroups严格限制每个 CLI 进程CPU最多使用 1 个 vCPU 核心cpu.max 100000 100000内存最大 2GBmemory.max 2147483648时间硬超时 30 秒pids.max 10防止 fork 炸弹第四层可观测性注入每个 CLI 执行都会自动注入 OpenTelemetry 上下文。我们在 CLI 模板里预留了OTEL_TRACEPARENT环境变量入口Agent Core 在调用前设置好 traceparentCLI 工具启动后自动将 span 透传到其子进程如它调用的 Python 解释器。这样在 Jaeger 里你能看到一条完整的 TraceAgent.execute() → CLIExecutor.run() → llm-inference.main() → torch.cuda.memory_allocated()问题定位效率提升 5 倍。这套 CLI 执行器让我们在 2023 年双十一大促期间扛住了每秒 1200 次的 Agent 调用峰值平均延迟 840msP99 延迟 1.7s且零因 CLI 导致的线上事故。4. MCP 的遗产与启示为什么“协议消亡”反而是架构成熟的标志回看 MCP 的兴衰它留下的不是一堆废弃代码而是一套关于“如何设计抽象层”的深刻启示。很多工程师把 MCP 的退出简单理解为“HTTP API 不行了”这是典型的归因错误。真相是MCP 的消亡恰恰证明了它所服务的更高层架构Agent已经成熟到可以抛弃中间协议直面本质问题。我们可以用一个生活化类比来理解MCP 就像早期汽车上的“机械油门拉线”。在电喷发动机普及前油门踏板通过一根钢丝直接拉动节气门结构简单、响应直接。但随着发动机控制越来越复杂可变气门、缸内直喷、启停系统拉线的局限性暴露无遗——它无法实现“一脚油门ECU 智能分配动力”的精细控制。于是拉线被淘汰了取而代之的是“电子油门踏板 CAN 总线 ECU 控制单元”的架构。拉线没有“失败”它只是完成了历史使命把控制权交给了更上层的智能系统。MCP 亦如此。它的“失败”体现在三个维度而这三个维度恰恰是 Agent 架构走向成熟的路标4.1 维度一从“统一接口”到“统一语义”的跃迁MCP 统一的是接口形状URL、Method、Body 结构但 Agent 需要统一的是语义含义messages数组里每个对象的role字段到底代表“用户输入”、“模型回复”还是“工具调用结果”。当语义不统一时再标准的接口也是空中楼阁。我们团队曾为解决这个问题专门设计了一个“语义转换层”Semantic Transformer。它不改变 HTTP 请求而是在 Agent Core 和 MCP Adapter 之间插入一层输入原始 MCP 响应如{choices: [{message: {content: ...}]}]}输出标准化语义对象如{type: llm_response, content: ..., tool_calls: []}这个转换层用一套 YAML 规则配置例如# transformers/llama3.yaml input_path: $.choices[0].message.content output_path: $.content type: llm_response规则引擎我们用的是jsonpath-ng根据配置提取、转换、注入字段。这样Agent Core 永远只和语义对象打交道不管底层是 MCP、OpenAI API 还是自研 CLI。MCP 的消亡意味着我们不再需要这个转换层——因为所有能力提供方都直接输出语义对象而不是“假装自己是 MCP”。4.2 维度二从“请求-响应”到“能力生命周期”的管理HTTP API 天然是请求-响应模型但 Agent 的能力调用是生命周期模型准备Preparation→ 执行Execution→ 观察Observation→ 决策Decision。MCP 只覆盖了 Execution 这一环其他环节全靠 Agent Core 硬编码。我们现在的架构把能力生命周期显式化为一个状态机# 此处禁止 mermaid改用文字描述 # 状态Idle → Preparing → Ready → Executing → Observing → Done # 事件prepare() → execute() → observe() → decide()每个能力提供方除了实现execute()还必须实现prepare()如预热模型、建立数据库连接和observe()如解析 CLI 的 stderr 判断是否真失败。Agent Core 不再“调用 API”而是驱动这个状态机。例如当 Agent 决定调用数据库时它先发prepare()事件能力执行器可能预热连接池再发execute()执行 SQL最后发observe()能力执行器分析affected_rows和last_insert_id生成结构化观察结果供 Agent 决策。MCP 的消亡意味着我们终于可以把“能力”当作一个有状态、有行为的对象来管理而不是一个无状态的函数调用。4.3 维度三从“协议兼容”到“契约演化”的治理MCP 的最大痛点是“版本地狱”。MCP v1 和 v2 不兼容升级就得全量回归测试。而我们现在的能力契约capability.json天生支持渐进式演化向后兼容新增字段如cost.per_call不影响旧版 Agent 解析向前兼容旧版capability.json缺少reliability字段Agent 默认填充{ uptime: 0.99, p95_latency_ms: 2000 }语义版本控制capability.json的version字段采用 SemVer如version: 1.2.0Agent Core 可以声明只接受^1.0.0版本的能力我们甚至实现了“契约漂移检测”CI 流水线在合并capability.json前会对比 Git Diff如果发现input_schema的某个必填字段被移除就自动阻断 PR并提示“此变更破坏向后兼容性请 bump 主版本号”。这种治理能力是任何静态协议都无法提供的。MCP 的消亡不是协议的失败而是我们终于有能力用更灵活、更可持续的方式管理能力的演化。个人体会我在 2022 年写第一版 MCP Adapter 时以为自己在造轮子2023 年推 CLI 执行器时以为自己在换轮子直到 2024 年搭建起能力契约体系才明白自己其实在重新定义“车”的概念——轮子协议只是载体真正的价值在于如何让车Agent更智能、更可靠、更易维护。MCP 的退出不是终点而是我们终于看清了路的方向。 
长河君 · 2026/10/28 7:56:52 · 阅读 1.2k MCP淘汰背后：Agent架构从协议对齐到语义连接的演进
1. 从“删掉薄封装”说起MCP 不是突然消失而是被架构演进自然淘汰最近在几个技术群和开源项目 Issue 区里反复看到一句带着点唏嘘语气的提问“MCP 真的要退出历史舞台了吗”——不是问它有没有 bug也不是问它能不能用而是直接在问它的存在必要性。这句话背后藏着一个被很多人忽略的事实MCPModel Control Protocol从来就不是一个独立运行的“产品”而是一套特定历史阶段下为解决“模型能力暴露不统一”问题而生的临时性协议层封装。我最早接触 MCP 是在 2022 年底当时团队在做一套面向内部研发人员的 LLM 工具链。我们手上有三个模型服务一个是本地部署的 Llama-3-70B 推理 API一个是云厂商提供的 Claude 封装接口还有一个是自研的 RAG 检索增强服务。三者返回格式五花八门有的带response.choices[0].message.content有的直接返回纯文本流有的甚至把 metadata 和 content 混在一个 JSON 字段里。前端同学每次对接一个新模型就要重写一遍解析逻辑后端同学每次加一个新模型就要补一段 if-else 转换器。那会儿大家管这种“模型适配层”叫“薄封装”——轻量、临时、谁都能写但谁都不想维护。MCP 就是在这个背景下被提出来的。它本质上定义了一套最小公约数一个标准的 HTTP POST 接口路径/v1/chat/completions一套固定的请求体字段model,messages,stream一套可预期的响应结构含id,choices,usage。它不规定你模型怎么训、怎么部署、怎么调度只管“你对外长什么样”。这很像当年 RESTful API 刚兴起时大家约定用GET /users获取列表、POST /users创建用户——不是因为技术多先进而是因为“不统一协作成本就爆炸”。但问题来了当“薄封装”开始变厚当“协议”开始承担不该它承担的职责它就走到了生命周期的拐点。我亲眼见过两个典型转折点第一个是某大厂在 MCP 基础上硬塞进“工具调用”function calling字段结果不同模型对tools数组的解析逻辑千差万别MCP 的“最小公约数”瞬间崩塌第二个是团队引入 Agent 编排框架后发现 MCP 的单次请求-响应模型根本无法表达“思考-调用-观察-再思考”的循环链路硬套上去的结果是每个 Agent Step 都要包装一层 MCP 请求性能损耗翻倍错误追踪变成噩梦。所以“删掉薄封装”不是一句情绪化口号而是一个明确的技术决策信号当协议层开始阻碍而非促进上层架构演进时它的使命就结束了。这不是 MCP 设计得不好恰恰相反它完成得太过成功——成功到让所有人忘了它本该是个过渡方案。就像 TCP/IP 协议栈里的 ARP 协议没人说它“过时”但它只在局域网二层寻址这个特定场景里发光发热一旦你进入 Service Mesh 或 Serverless 场景ARP 就自动退居幕后由更上层的机制接管。提示判断一个协议是否该被替代关键看它是否还在“做减法”。MCP 最初做的是“减去模型差异”后来却被迫做“加法”——加流式控制、加工具描述、加 session 状态。一旦协议开始膨胀说明抽象层级错了。2. Agent 连接架构的三重跃迁从“协议对齐”到“语义连接”当团队决定“删掉 MCP”时真正要解决的从来不是“怎么发请求”而是“Agent 怎么可靠、可扩展、可调试地与外部能力协同”。这背后是一场静默却深刻的架构范式迁移从基于 HTTP API 的协议对齐转向基于能力契约的语义连接。这个转变不是一蹴而就的而是经历了三个清晰的阶段跃迁。2.1 第一阶段HTTP API 层的“胶水代码”时代2022–2023这是 MCP 最活跃的时期。典型架构是Agent Core如 LangChain 的 AgentExecutor → MCP Adapter将 Agent 的 Tool Call 转成 MCP 格式 → 外部服务模型 API / 数据库 / 第三方 SaaS。所有连接都通过标准 HTTP 完成看似干净实则暗藏三重脆弱性类型脆弱性MCP 规定messages是数组但没规定数组里每个message的role字段必须是user/assistant/system。某次上游模型服务升级把role: human改成role: user整个 Agent 流程因字符串匹配失败而卡死日志里只有一行KeyError: user。流控脆弱性MCP 的stream: true只保证响应是 SSE 流但不保证流内 chunk 的语义完整性。我们曾遇到一个模型服务在流式返回时把一个完整的 JSON 对象切成两半发送前半段在 chunk1后半段在 chunk2Agent 解析器直接崩溃因为json.loads()遇到不完整 JSON。错误语义脆弱性HTTP 状态码 429Too Many Requests和 503Service Unavailable在 MCP 里都被映射成统一的RateLimitError但前者是客户端该退避后者是服务端故障需熔断——Agent 却无法区分导致重试策略全乱套。这个阶段的“连接”本质是字节流层面的管道对接靠大量胶水代码Adapter强行弥合语义鸿沟。我统计过当时一个中等复杂度的 Agent 项目约 35% 的代码量花在各种 Adapter 的编写和维护上且几乎全是重复劳动。2.2 第二阶段CLI 工具链驱动的“进程间通信”2023–2024转折点来自一次意外团队需要接入一个只能通过命令行交互的遗留系统某定制化数据清洗工具。写 HTTP Adapter 成本太高干脆用 Python 的subprocess.run()直接调 CLI。结果发现CLI 的输入输出反而比 HTTP 更稳定——输入是确定的参数字符串输出是确定的 stdout/stderr错误码是确定的 exit code。更重要的是CLI 天然支持“状态隔离”每次调用都是全新进程不会像 HTTP 连接那样有长连接状态污染。于是我们开始系统性重构连接方式。核心思路是把所有外部能力抽象为“可执行命令”Agent 通过标准输入/输出与之通信。例如模型调用llm-inference --model llama3-70b --prompt 你好 --stream数据库查询db-query --dsn mysql://... --sql SELECT * FROM users文件处理pdf-extract --input report.pdf --output text这些 CLI 工具由各能力提供方自己维护遵循统一的输入输出契约如输入必须是 JSONL 格式输出必须是带status字段的 JSON。Agent Core 只需关注如何拼装命令、解析 stdout、处理 exit code。我们为此开发了一个轻量级 CLI Runner核心逻辑不到 200 行 Pythonimport subprocess import json from typing import Dict, Any def run_cli(cmd: str, input_data: Dict[str, Any]) - Dict[str, Any]: try: result subprocess.run( cmd.split(), inputjson.dumps(input_data).encode(), capture_outputTrue, timeout30 ) if result.returncode 0: return json.loads(result.stdout.decode()) else: return { status: error, code: result.returncode, message: result.stderr.decode() } except subprocess.TimeoutExpired: return {status: error, code: -1, message: timeout}这个阶段的连接从“网络协议”下沉到“操作系统进程”稳定性大幅提升。我们线上环境的 Agent 调用失败率从 HTTP 时代的 8.2% 降到 1.3%且 90% 的错误都能通过 exit code 精准归类。CLI 的另一个巨大优势是调试友好性任何问题运维同学只要在服务器上手动执行一遍相同命令就能复现无需抓包、无需模拟 HTTP Header。2.3 第三阶段基于能力契约的“语义连接”2024–至今CLI 解决了稳定性但带来了新问题启动进程开销大、无法共享内存、难以做细粒度权限控制。真正的破局点是把“连接”从“如何调用”升维到“调用什么”。我们不再问“这个模型 API 怎么发请求”而是问“这个能力能做什么、不能做什么、代价是什么”。我们定义了一套极简的能力契约Capability Contract每个外部服务必须提供一个capability.json文件内容类似{ id: llm-llama3-70b, name: Llama3-70B 推理服务, description: 支持流式响应的通用大语言模型, input_schema: { type: object, properties: { prompt: {type: string}, max_tokens: {type: integer, default: 512}, temperature: {type: number, default: 0.7} } }, output_schema: { type: object, properties: { response: {type: string}, usage: {type: object, properties: {prompt_tokens: {type: integer}}} } }, cost: {per_token: 0.000001, per_call: 0.001}, reliability: {uptime: 0.9995, p95_latency_ms: 1200} }Agent Core 在运行时先加载所有capability.json构建一个能力目录Capability Registry。当 Agent 决定调用某个能力时不是硬编码 URL 或命令而是向 Registry 查询“谁支持input_schema.prompt且cost.per_token 0.000002” Registry 返回匹配的能力 IDAgent 再根据该 ID 的元信息是 HTTPCLI还是 gRPC选择对应执行器。这个架构下“连接”变成了能力发现 执行路由。MCP 的消亡不是终点而是起点——它迫使我们把原本隐含在协议里的语义比如“这个接口能干啥”“它有多贵”“它稳不稳”显式化、结构化、可编程化。这才是 Agent 架构真正成熟的标志连接不再是技术细节而是业务策略的一部分。注意能力契约不是越复杂越好。我们刻意避免在capability.json中定义传输协议HTTP/gRPC/CLI因为那是执行器的事也避免定义认证方式API Key/OAuth因为那是安全网关的事。契约只回答三个问题它能做什么输入输出、代价多少成本、表现如何可靠性。3. “删掉薄封装”后的实操落地一个可复用的 Agent 连接架构模板光讲理念不够我直接给出我们在生产环境跑了一年多的 Agent 连接架构模板。它不是理论模型而是从真实踩坑中提炼出的、可直接抄作业的工程方案。整个架构分三层能力注册层、执行路由层、具体执行器层。下面逐层拆解重点讲清楚每个环节为什么这么设计、容易踩什么坑、我们是怎么绕过去的。3.1 能力注册层用 GitOps 管理capability.json拒绝运行时魔法很多团队一上来就想搞个“能力中心”微服务结果半年后发现这个服务成了新的单点故障而且更新一个能力描述要走 CI/CD 流水线慢得让人抓狂。我们的解法极其朴素把所有capability.json文件放在一个 Git 仓库里用 Git 作为能力注册中心。仓库结构很简单capabilities/ ├── llm/ │ ├── llama3-70b/ │ │ └── capability.json │ └── claude-sonnet/ │ └── capability.json ├── data/ │ └── mysql-prod/ │ └── capability.json └── tools/ └── pdf-extractor/ └── capability.json每个capability.json必须通过 CI 流水线校验JSON Schema 合法性用jsonschema库input_schema和output_schema必须是有效的 JSON Schema Draft-07cost.per_token和cost.per_call必须是正数reliability.uptime必须在 0.9–1.0 之间校验通过后CI 自动触发一个 GitHub Action将该文件同步到一个 S3 存储桶或 MinIO并更新一个index.json文件内容是所有能力的 ID 列表。Agent 启动时只做一件事从 S3 下载最新的index.json然后并发下载所有capability.json文件到本地缓存目录如/tmp/capabilities。整个过程不到 2 秒且完全离线可用——即使 S3 挂了Agent 也能用本地缓存继续工作。这个设计解决了三个致命问题变更可见性谁改了哪个能力的描述Git Log 一目了然再也不用问“这个字段什么时候加的”回滚简单性某次上线后发现llama3-70b的max_tokens默认值设错了git revert一行命令搞定不用改代码、不用发版。环境一致性开发、测试、生产环境用的capability.json完全一致因为它们都指向同一个 Git Commit Hash。实操心得我们给每个capability.json加了一个version字段如version: 2024.06.15-1格式是YYYY.MM.DD-序号。这样即使 Git Commit Hash 变了也能快速定位到某次变更的具体时间点。版本号由 CI 自动生成开发者无需关心。3.2 执行路由层基于策略的动态选择器让 Agent “懂权衡”有了能力列表下一步是“选谁”。传统做法是写死if model llama3 then use_http_adapter这又回到了胶水代码的老路。我们的方案是Agent 在调用前先向一个策略引擎提交“能力需求”引擎返回最优能力 ID 和执行方式。策略引擎的核心是一个可插拔的规则引擎。默认规则很简单功能匹配优先input_schema必须兼容当前请求的参数用jsonschema.validate校验成本最低优先在功能匹配的能力中选cost.per_token最小的那个可靠性兜底如果所有匹配能力的reliability.uptime 0.999则降级到备用能力如llm-fallback但规则可以随时扩展。比如某天市场部要求“所有面向客户的问答必须用 Claude哪怕贵 3 倍”我们只需加一条规则# rules/cost_vs_brand.py def apply_rule(capabilities, request): if request.get(audience) customer: return [c for c in capabilities if claude in c[id]] return capabilities策略引擎返回的不只是能力 ID还有execution_method字段值为http,cli, 或grpc。Agent Core 根据这个字段从执行器池中取出对应的执行器实例。执行器池是单例预先初始化好所有可能用到的执行器HTTP Session、CLI Runner、gRPC Channel避免每次调用都创建新连接。这里有个关键细节我们强制要求所有执行器实现统一的execute()接口class Executor(ABC): abstractmethod def execute(self, capability_id: str, input_data: dict) - dict: passHTTPExecutor 的实现是发请求CLIExecutor 的实现是subprocess.run()gRPCExecutor 的实现是调用 stub 方法。Agent Core 完全不知道底层怎么连只认这个接口。这让我们在某次压测中发现 HTTP 连接池瓶颈时能用一个下午就把所有llm-*能力的执行方式从http切成cli零代码修改只改了capability.json里的execution_method字段。3.3 具体执行器层CLI 执行器的深度优化实践CLI 执行器是我们用得最多、也最值得展开讲的。网上很多教程只说“用 subprocess 调 CLI”但生产环境远比这复杂。我们针对 CLI 执行做了四层加固第一层沙箱隔离绝不允许 CLI 工具直接访问宿主机文件系统。所有 CLI 工具都运行在firejail沙箱中firejail --quiet --noprofile --netnone \ --private/tmp/cli-workdir \ --whitelist/usr/bin/python3 \ --whitelist/app/tools/llm-inference \ /app/tools/llm-inference --prompt $INPUT--private创建独立临时目录--netnone禁用网络--whitelist只允许访问指定路径。这样即使某个 CLI 工具被注入恶意代码也无法读取/etc/passwd或发起外网请求。第二层输入输出标准化我们强制所有 CLI 工具遵循“JSONL 输入JSON 输出”规范输入Agent 将input_data序列化为 JSON 字符串通过 stdin 传入输出CLI 工具必须将结果序列化为 JSON 字符串写入 stdout错误信息写入 stderr我们提供了一个通用 CLI 模板Python开发者只需填空process_input()和generate_output()函数其余框架代码沙箱调用、超时控制、日志埋点全部内置。第三层资源限制用cgroups严格限制每个 CLI 进程CPU最多使用 1 个 vCPU 核心cpu.max 100000 100000内存最大 2GBmemory.max 2147483648时间硬超时 30 秒pids.max 10防止 fork 炸弹第四层可观测性注入每个 CLI 执行都会自动注入 OpenTelemetry 上下文。我们在 CLI 模板里预留了OTEL_TRACEPARENT环境变量入口Agent Core 在调用前设置好 traceparentCLI 工具启动后自动将 span 透传到其子进程如它调用的 Python 解释器。这样在 Jaeger 里你能看到一条完整的 TraceAgent.execute() → CLIExecutor.run() → llm-inference.main() → torch.cuda.memory_allocated()问题定位效率提升 5 倍。这套 CLI 执行器让我们在 2023 年双十一大促期间扛住了每秒 1200 次的 Agent 调用峰值平均延迟 840msP99 延迟 1.7s且零因 CLI 导致的线上事故。4. MCP 的遗产与启示为什么“协议消亡”反而是架构成熟的标志回看 MCP 的兴衰它留下的不是一堆废弃代码而是一套关于“如何设计抽象层”的深刻启示。很多工程师把 MCP 的退出简单理解为“HTTP API 不行了”这是典型的归因错误。真相是MCP 的消亡恰恰证明了它所服务的更高层架构Agent已经成熟到可以抛弃中间协议直面本质问题。我们可以用一个生活化类比来理解MCP 就像早期汽车上的“机械油门拉线”。在电喷发动机普及前油门踏板通过一根钢丝直接拉动节气门结构简单、响应直接。但随着发动机控制越来越复杂可变气门、缸内直喷、启停系统拉线的局限性暴露无遗——它无法实现“一脚油门ECU 智能分配动力”的精细控制。于是拉线被淘汰了取而代之的是“电子油门踏板 CAN 总线 ECU 控制单元”的架构。拉线没有“失败”它只是完成了历史使命把控制权交给了更上层的智能系统。MCP 亦如此。它的“失败”体现在三个维度而这三个维度恰恰是 Agent 架构走向成熟的路标4.1 维度一从“统一接口”到“统一语义”的跃迁MCP 统一的是接口形状URL、Method、Body 结构但 Agent 需要统一的是语义含义messages数组里每个对象的role字段到底代表“用户输入”、“模型回复”还是“工具调用结果”。当语义不统一时再标准的接口也是空中楼阁。我们团队曾为解决这个问题专门设计了一个“语义转换层”Semantic Transformer。它不改变 HTTP 请求而是在 Agent Core 和 MCP Adapter 之间插入一层输入原始 MCP 响应如{choices: [{message: {content: ...}]}]}输出标准化语义对象如{type: llm_response, content: ..., tool_calls: []}这个转换层用一套 YAML 规则配置例如# transformers/llama3.yaml input_path: $.choices[0].message.content output_path: $.content type: llm_response规则引擎我们用的是jsonpath-ng根据配置提取、转换、注入字段。这样Agent Core 永远只和语义对象打交道不管底层是 MCP、OpenAI API 还是自研 CLI。MCP 的消亡意味着我们不再需要这个转换层——因为所有能力提供方都直接输出语义对象而不是“假装自己是 MCP”。4.2 维度二从“请求-响应”到“能力生命周期”的管理HTTP API 天然是请求-响应模型但 Agent 的能力调用是生命周期模型准备Preparation→ 执行Execution→ 观察Observation→ 决策Decision。MCP 只覆盖了 Execution 这一环其他环节全靠 Agent Core 硬编码。我们现在的架构把能力生命周期显式化为一个状态机# 此处禁止 mermaid改用文字描述 # 状态Idle → Preparing → Ready → Executing → Observing → Done # 事件prepare() → execute() → observe() → decide()每个能力提供方除了实现execute()还必须实现prepare()如预热模型、建立数据库连接和observe()如解析 CLI 的 stderr 判断是否真失败。Agent Core 不再“调用 API”而是驱动这个状态机。例如当 Agent 决定调用数据库时它先发prepare()事件能力执行器可能预热连接池再发execute()执行 SQL最后发observe()能力执行器分析affected_rows和last_insert_id生成结构化观察结果供 Agent 决策。MCP 的消亡意味着我们终于可以把“能力”当作一个有状态、有行为的对象来管理而不是一个无状态的函数调用。4.3 维度三从“协议兼容”到“契约演化”的治理MCP 的最大痛点是“版本地狱”。MCP v1 和 v2 不兼容升级就得全量回归测试。而我们现在的能力契约capability.json天生支持渐进式演化向后兼容新增字段如cost.per_call不影响旧版 Agent 解析向前兼容旧版capability.json缺少reliability字段Agent 默认填充{ uptime: 0.99, p95_latency_ms: 2000 }语义版本控制capability.json的version字段采用 SemVer如version: 1.2.0Agent Core 可以声明只接受^1.0.0版本的能力我们甚至实现了“契约漂移检测”CI 流水线在合并capability.json前会对比 Git Diff如果发现input_schema的某个必填字段被移除就自动阻断 PR并提示“此变更破坏向后兼容性请 bump 主版本号”。这种治理能力是任何静态协议都无法提供的。MCP 的消亡不是协议的失败而是我们终于有能力用更灵活、更可持续的方式管理能力的演化。个人体会我在 2022 年写第一版 MCP Adapter 时以为自己在造轮子2023 年推 CLI 执行器时以为自己在换轮子直到 2024 年搭建起能力契约体系才明白自己其实在重新定义“车”的概念——轮子协议只是载体真正的价值在于如何让车Agent更智能、更可靠、更易维护。MCP 的退出不是终点而是我们终于看清了路的方向。