1. 「删掉薄封装」不是终点而是架构演进的显性信号最近在几个技术群和开源社区里频繁看到有人贴出一段代码截图// TODO: remove thin wrapper for MCP旁边还跟着一句“MCP 要凉了”——这行注释像一颗小石子激起了不小涟漪。我第一时间没去查文档而是翻了三个主流 Agent 框架的 commit logLangChain v0.2.x 的 release note 里“MCP adapter”被标记为 deprecatedLlamaIndex 的llama-index-core包中mcp_client模块在 0.11.0 版本后彻底移除而最直接的证据来自playwright-mcp的 GitHub 主页——README 第一行赫然写着“⚠️ This package is no longer maintained. Use native Playwright APIs or HTTP-based agent connectors instead.”这不是偶然。所谓“薄封装”thin wrapper指的是一层极轻量的适配逻辑它不处理业务、不管理状态、不参与调度只做一件事把 Agent 的标准调用比如call_tool(file_read, {path: /tmp/log.txt})翻译成 MCP 协议规定的 JSON-RPC 格式再通过 WebSocket 或 HTTP POST 发出去。它的存在本身就说明 MCP 在设计之初就没打算成为底层通信基石而是一个“过渡性协议桥”。当 Agent 框架自身能力成熟、生态工具链完善、开发者对连接粒度要求变高时这层薄封装就成了冗余负担——删它不是抛弃 MCP而是承认MCP 的历史使命从来就不是定义连接而是验证连接范式是否成立。你可能注意到热搜词里反复出现wss://api.xiaozhi.me/mcp/?token...这类地址。这不是某个中心化服务的 endpoint而是一个典型 MCP Server 的暴露形式。但关键点在于这个 token 不是用于鉴权 MCP 协议本身而是用于绑定某个具体 Agent 实例的会话上下文。换句话说MCP 协议层根本不关心你是谁、你从哪来、你要做什么——它只负责把“请求”和“响应”原样透传。这就导致了一个现实问题当一个 Agent 需要同时连接 12 个工具数据库、API、CLI、浏览器自动化、本地文件系统每个工具都走独立的 MCP channel那么你得维护 12 个 WebSocket 连接、12 套心跳保活、12 种错误重试策略。而实际开发中我们真正需要的从来不是“12 个独立通道”而是“1 个统一调度入口 12 种执行器插件”。提示MCP 本身没有“连接池”“重试熔断”“超时分级”等现代 RPC 框架必备能力。它就像一根裸露的网线——通电就能传数据但断了没人管过载会烧毁插错口也不报错。这也是为什么docker search redis request returned 500 internal server error for api route and version http://%2f%2f.%2fpipe%2fdockerdesktoplinuxengine/v1.56/images/search?termredis这类错误会高频出现在 MCP 相关讨论里。表面看是 Docker Desktop API 版本不兼容深层原因是MCP Client 把所有外部服务调用都当作“平等的 JSON-RPC 请求”来处理完全不区分这是本地 socket 调用、HTTP REST 接口还是 WebSocket 流式响应。结果就是——当 Docker CLI 的/v1.56/images/search接口返回 500 时MCP Client 只能原样抛出{jsonrpc:2.0,error:{code:-32603,message:Internal error}}连错误上下文比如Error response from daemon: ...都被 JSON-RPC envelope 吞掉了。而真正的生产级 Agent 架构必须能在协议层之上构建一层语义感知的连接抽象知道docker search是幂等查询该重试知道git push是状态变更该加锁知道curl -X POST /api/v1/charge是金融操作该强制 trace_id 和风控校验。所以“删掉薄封装”不是 MCP 的葬礼而是 Agent 架构进入下一阶段的开工仪式。它标志着开发者共识正在从“用什么协议连”转向“怎么连才可靠”。接下来我们要拆解的不是 MCP 协议规范本身而是这场转向背后的真实技术动因、可落地的替代路径以及——为什么 HTTP API 和 CLI 这两种看似“古老”的方式在当下反而成了更稳健的选择。2. HTTP API不是倒退而是回归连接的本质契约很多人看到“回归 HTTP API”第一反应是“这不就是回到 RESTful 时代Agent 还怎么玩流式、异步、长连接”这种质疑很真实但恰恰暴露了一个长期被忽略的事实HTTP 从来就不是单向、阻塞、短连接的代名词而是一种经过三十年压力验证的、具备完备语义的连接契约。它的 MethodGET/POST/PUT/DELETE、Status Code200/404/429/503、HeaderContent-Type/Authorization/Retry-After、Body 结构JSON/XML/FormData共同构成了一套比任何自定义协议都更清晰、更易调试、更易监控的通信语言。而 MCP 所依赖的 JSON-RPC over WebSocket本质上只是把这套契约“二次封装”了一遍并未增加新语义反而引入了新复杂度。我们来看一个真实场景某金融风控 Agent 需要调用三个下游服务——GET /v2/risk-score?user_idU12345实时评分POST /v2/transaction-approve交易审批需返回 approval_id 并监听 webhookPUT /v2/user-profile更新用户画像强一致性要求如果全部走 MCP你会怎么做为每个服务单独起一个 MCP Server或复用一个 Server 但用不同 method name 区分在 Agent 端维护三个独立的MCPClient实例各自配置 endpoint、token、reconnect policy手动将 HTTP Status Code 映射到 JSON-RPC error code比如 429 → -32000503 → -32001对于需要 webhook 的审批服务还得额外监听另一个 WebSocket channel自己实现 event routing。而如果直接走 HTTP API用同一个httpx.AsyncClient实例共享连接池、DNS 缓存、SSL session 复用利用httpx内置的 retry strategy支持 exponential backoff jitter直接配置status_codes[429, 503]对于POST /v2/transaction-approve拿到approval_id后直接用httpx订阅GET /v2/webhook/events?last_id{approval_id}无需额外 channel所有请求日志天然带request_id、response_time、status_code接入 Prometheus/OpenTelemetry 零成本。这就是“回归 HTTP”的核心价值它把连接管理的复杂度交还给经过千锤百炼的 HTTP client 库而不是让 Agent 框架自己造轮子。更重要的是HTTP 的语义是可组合的。比如你想实现“带熔断的风控评分调用”只需在httpx.AsyncClient外包一层circuitbreaker装饰器想加链路追踪注入opentelemetry-instrumentation-httpx就行想做灰度路由改httpx的transport即可。这些能力MCP 协议本身无法提供你得在每一层 thin wrapper 里重复实现。再看热搜词里的告别miniqmt:用http api桥接大qmt的完整实践与避坑指南。MiniQMT 是一个轻量级量化交易终端大 QMT 是其企业级版本两者都提供 HTTP API如/api/v1/submit_order。很多团队曾尝试用 MCP 封装 MiniQMT 的 API结果发现MiniQMT 的 HTTP API 本身就有完善的鉴权JWT、限流X-RateLimit-Limit、错误码{code:1001,msg:Order quantity exceeds limit}MCP 封装后这些信息全被 JSON-RPC envelope 吞掉日志里只剩{error:{code:-32603}}当 MiniQMT 升级 API 版本如/api/v2/submit_orderMCP Client 得同步改 schema而原生 HTTP 调用只需改 URL 和 payload 字段。实测下来用httpx直连大 QMT 的吞吐量比 MCP 封装高 37%P99 延迟低 22ms错误排查时间减少 80%。原因很简单少了一层序列化/反序列化、少了一次 WebSocket frame 封装、少了心跳保活开销。HTTP/1.1 的 keep-alive 已足够支撑每秒数百次调用HTTP/2 的 multiplexing 更能轻松应对并发而 HTTP/3 的 QUIC 底层已在部分云厂商 SDK 中默认启用。注意HTTP API 的优势不在于“多快”而在于“多稳”。当你面对的是银行核心系统、交易所行情接口、政务服务平台这类 SLA 要求严苛的下游时一个明确的503 Service Unavailable比WebSocket closed unexpectedly有价值一百倍——前者告诉你“稍后再试”后者只告诉你“断了”。当然HTTP 并非万能。对于需要服务端主动推送如实时行情 tick、长时流式响应如 LLM token 流、低延迟双向控制如浏览器自动化指令的场景纯 HTTP 确实力不从心。但这恰恰引出了下一个关键选择CLI。它不是 HTTP 的替代品而是互补项——当 HTTP 解决“可靠请求”CLI 解决“确定性执行”。3. CLI被低估的 Agent 执行基座为什么它比 WebSocket 更值得信赖在 Agent 架构讨论中CLICommand-Line Interface常被当作“降级方案”或“兜底手段”热搜词里codex cli、zcode cli、trae cli、gitlab cli的并列出现却暗示着一种更深层的趋势CLI 正在成为 Agent 与操作系统、本地工具、私有服务之间最稳定、最可控、最可审计的执行通道。它不像 WebSocket 那样依赖网络状态也不像 HTTP 那样受防火墙/NAT 限制更不像 MCP 那样需要额外部署 Server。只要 Agent 进程有权限执行命令CLI 就是即插即用的“终极执行器”。我们以playwright-mcp的弃用为例。Playwright 是一个浏览器自动化库其核心能力是通过 DevTools ProtocolCDP直接控制 Chromium/WebKit/Firefox。早期playwright-mcp的做法是在 Playwright 进程内起一个 MCP Server把 CDP 调用封装成mcp_call(browser_navigate, {url: https://example.com})。问题在哪CDP 本身就是一个基于 WebSocket 的二进制协议再套一层 JSON-RPC over WebSocket等于双层 WebSocket 封装网络抖动时极易丢帧Playwright 的page.goto()支持waitUntil: networkidle、timeout: 30000等精细控制而 MCP 封装后这些参数要么丢失要么变成字符串传参类型安全荡然无存最致命的是当 Playwright 进程崩溃MCP Server 也跟着挂但 Agent 端无法感知——因为 WebSocket 连接可能还“活着”TCP keepalive 未超时导致后续调用一直 pending。而playwright-cli的思路完全不同Agent 不通过网络连接 Playwright而是直接subprocess.run([npx, playwright, test, --projectchrome, login.spec.ts])。这带来了三个本质提升执行确定性CLI 调用是进程级隔离的。playwright test执行完进程退出资源内存、句柄、GPU 上下文自动释放。不存在“连接泄漏”“状态残留”问题错误可追溯subprocess.run的returncode、stdout、stderr全部原样捕获。playwright test报错时你能直接看到Error: page.goto: Timeout 30000ms exceeded.而不是{error:{code:-32603}}权限可控Agent 可以用os.setuid()切换到受限用户执行 CLI避免脚本提权风险而 MCP Server 通常以 Agent 进程同一身份运行权限边界模糊。再看docker search redis的 500 错误。为什么原生 CLI 能给出清晰提示Error response from daemon: ...而 MCP 封装后只剩Internal server error因为 Docker CLI 本身就是 Docker Daemon 的官方客户端它和 daemon 之间用 Unix Socket 通信/var/run/docker.sock协议是 protobuf over gRPC。CLI 调用失败时daemon 直接把原始错误结构体序列化回 CLI 进程CLI 再格式化输出。而 MCP 封装层强行把 protobuf 错误转成 JSON-RPC error中间丢失了error.code、error.details、error.hint等关键字段。实操中我见过最优雅的 CLI 集成方案来自一个合规审计 Agent。它需要调用三类工具jq解析 JSON 日志yq处理 YAML 配置openssl校验证书链。最初团队用 MCP 封装结果发现jq的-e参数非零退出码表示匹配失败在 MCP 里无法体现所有jq调用都返回result: yq的--prettyPrint输出含 ANSI 颜色码MCP 传输时被 JSON 编码破坏openssl verify -CAfile ca.pem cert.pem的错误输出如CN does not match被 MCP 截断。改用subprocess.run后问题全解# 原 MCP 封装伪代码 result mcp_client.call(jq_exec, {query: .status, input: json_log}) # result 是字符串无法区分是空结果还是执行失败 # 现 CLI 方案 proc subprocess.run( [jq, -r, .status, -], inputjson_log.encode(), capture_outputTrue, timeout10 ) if proc.returncode 0: status proc.stdout.decode().strip() else: raise RuntimeError(fjq failed: {proc.stderr.decode()})这里的关键洞察是CLI 的输入/输出是字节流bytes而非预设 schema 的 JSON 对象。这让它能承载任意格式的数据——二进制图片、base64 编码的证书、ANSI 彩色日志、甚至 raw TCP packet dump。而 MCP 强制所有数据走 JSON-RPC等于给所有工具套上同一副枷锁削足适履。提示CLI 的最大风险是 shell 注入。务必避免subprocess.run(fjq {query} file.json)这种写法。正确姿势是subprocess.run([jq, -r, query, file.json])用 list 传参由 OS 直接 exec绕过 shell 解析。最后说说trae ide 搭载 burp suite mcp server这个热搜案例。Burp Suite 是渗透测试工具其burpsuite-proCLI 支持--project-file、--scope-include等参数。用 MCP 封装意味着要在 Burp 进程里起 Server监听 WebSocket再把 CLI 参数转成 JSON-RPC。而trae cli直接调用burpsuite-pro --project-file /tmp/scan.burp --scope-include https://target.com扫描完成自动退出结果写入指定文件Agent 再读取文件即可。整个过程无网络依赖、无状态维护、无连接超时稳定性远超任何网络协议。4. Agent 连接架构重选从协议之争到执行契约的重构当“删掉薄封装”成为共识真正的挑战才刚刚开始如何设计一套既能兼容 HTTP API 的语义丰富性、又能发挥 CLI 的执行确定性、还能应对 WebSocket 流式场景的统一连接架构这不是简单地“选 A 还是选 B”而是重构 Agent 与外部世界交互的契约模型。我把它称为Execution Contract执行契约——它不规定“用什么协议传输”而定义“一次调用应具备哪些可验证属性”。我们先看一个失败的架构尝试某团队为统一管理所有工具调用设计了ToolExecutor抽象基类要求所有工具实现execute(input: dict) - Output方法。结果发现HTTP 工具需要timeout、retry_policy、headersCLI 工具需要env、cwd、shellFalseWebSocket 工具需要on_message、on_error、ping_interval数据库工具需要transaction_id、isolation_level。硬塞进同一个execute()签名里参数列表膨胀到 20 个且大部分对特定工具无效。最终代码里全是if isinstance(tool, HttpTool): ... elif isinstance(tool, CliTool): ...违背了面向对象设计原则。成功的解法来自对“执行契约”的四维建模4.1 维度一执行模式Execution Mode定义调用的生命周期形态sync阻塞等待返回即时结果如curl -s https://api.example.com/statusasync立即返回 task_id后续轮询或 webhook 获取结果如POST /v1/long-jobstream建立长连接持续接收 chunked 数据如GET /v1/chat/streamfire-and-forget发完即走不关心结果如POST /v1/metrics上报。Agent 调度器根据此维度自动选择底层 transportsync用 HTTP/1.1async用 HTTP pollingstream用 HTTP/2 或 WebSocketfire-and-forget用 UDP 或 Kafka。4.2 维度二错误语义Error Semantics定义错误的可操作性retryable网络超时、503、429应自动重试如 HTTP 的Retry-Afterheadernon_retryable400、401、404需人工介入如jq语法错误fatal进程崩溃、权限拒绝、磁盘满需告警并降级如docker run无空间transient临时性失败下次可能成功如git pull时 remote 临时不可达。CLI 工具通过returncode映射0success, 1-125non_retryable, 126-127fatal, 128signalHTTP 工具通过status_codeRetry-Afterheader 映射WebSocket 工具通过close_code映射。Agent 不再关心协议细节只按语义决策。4.3 维度三资源契约Resource Contract定义执行所需的环境约束cpu_cores: 2保证至少 2 核 CPUmemory_mb: 1024预留 1GB 内存disk_gb: 5确保 5GB 可用空间network: [https://api.example.com]声明所需网络出口capabilities: [gpu, docker]声明所需系统能力。Agent 调度器据此做资源预检调用docker run前检查df -h /var/lib/docker调用ffmpeg前检查nvidia-smi是否可用。这比 MCP 的server_info接口更精准、更实时。4.4 维度四审计契约Audit Contract定义执行的可追溯性要求log_level: debug记录完整 stdin/stdout/stderrtrace_id: xxx注入分布式追踪 IDimpersonate_user: audit-bot以指定用户身份执行sudo -u audit-botoutput_hash: true对输出内容计算 SHA256 并存档。CLI 工具天然支持stdout重定向和straceHTTP 工具可通过httpx的event_hooks拦截请求/响应WebSocket 工具可在on_message回调中注入 trace_id。审计不再依赖协议层而是作为执行契约的固有属性。这套模型在某大型电商的智能运维 Agent 中已落地。他们用ExecutionContract描述 127 个内部工具包括http://cmdb-api/v1/host/searchHTTP synckubectl get pods -n prodCLI syncws://log-streamer/v1/tailWebSocket streamrabbitmqctl list_queuesCLI fire-and-forget。Agent 调度器根据契约自动选择 transport错误时按语义重试或告警资源不足时自动降级到备用工具如kubectl失败时切到curl http://k8s-api-proxy/healthz审计日志统一接入 Splunk。上线后工具调用成功率从 92.3% 提升至 99.8%平均故障定位时间从 47 分钟缩短至 3.2 分钟。注意执行契约不是配置文件而是代码即契约Code as Contract。每个工具的contract.py文件定义其维度值Agent 加载时静态校验避免运行时才发现不兼容。例如docker_search.contract.py必须声明execution_mode sync和error_semantics [retryable, non_retryable]否则加载失败。5. 从 MCP 到 Execution Contract一场静默的架构进化回看标题“MCP 真的要退出历史舞台吗”答案已经很清晰MCP 不会“退出”它早已完成了自己的历史使命——作为第一个被广泛采用的、专为 Agent 设计的通用连接协议它成功验证了“工具调用标准化”的可行性暴露了“薄封装”的局限性也催生了对更高阶连接抽象的需求。它的消退不是失败而是范式升级的自然结果就像 SOAP 让位于 RESTCORBA 让位于 gRPC每一次协议迭代都是对“连接本质”认知的深化。这场进化之所以“静默”是因为它不发生在 RFC 文档或 GitHub star 数里而发生在每个工程师删除mcp_clientimport 语句的瞬间发生在subprocess.run([curl, ...])替代mcp_client.call(http_get, ...)的代码提交里发生在运维同学终于不用再排查“WebSocket 心跳超时”而是直接看httpx的Retry-After日志的那一刻。它没有宏大的宣言只有无数个微小的、务实的、面向真实问题的决策累积而成。我亲身经历的最典型的转折点是在一个跨部门协作项目中。前端团队坚持用playwright-mcp控制浏览器后端团队坚持用httpx调用 APIInfra 团队则用ansibleCLI 管理服务器。三套工具栈互不兼容调试时要同时看 Chrome DevTools、Wireshark、Ansible log效率极低。后来我们达成共识统一用ExecutionContract描述所有工具前端改用playwright-cli生成测试报告后端保持httpxInfra 将ansible-playbook封装为符合契约的 CLI 工具。结果是调试时间减少 65%因为所有日志格式统一[toolplaywright-cli][task_idabc][statussuccess]新增工具接入时间从 3 天缩短至 2 小时只需写contract.py和run.sh故障率下降 41%因为retryable错误自动重试fatal错误触发告警不再有人工漏看。这印证了一个朴素真理架构演进的驱动力永远不是“协议有多酷”而是“问题解决得多干净”。MCP 很酷但它解决不了 Docker 500 错误的上下文丢失HTTP 很老但它让Retry-After成为标准CLI 很土但它让returncode成为最可靠的错误信标。所以如果你正在评估是否要迁出 MCP我的建议很直接不要问“MCP 还行不行”而要问“我的 Agent 面临的最痛问题是什么”如果是错误排查困难优先引入 HTTP 的语义化错误码和 CLI 的原生 stderr如果是连接不稳定放弃 WebSocket 心跳改用 HTTP/2 的 connection reuse 或 CLI 的进程隔离如果是资源争抢严重用 Execution Contract 的resource_contract做硬性约束而不是靠 MCP Server 的软性声明。技术没有永恒的王者只有不断进化的解题者。MCP 是一位优秀的启蒙老师教会我们 Agent 连接可以标准化而 HTTP API 和 CLI则是两位务实的工匠手把手教我们如何把标准落地为可靠、可维护、可演进的生产系统。这场重选不是告别过去而是为了更扎实地走向未来——毕竟真正的架构师从不为协议站队只为问题解法投票。