Ian Wang
Index

← 文章 / Writing

· 25 min

智能体的"手"——从 RPC 到 MCP 与 CLI 的四十年集成协议史

从 1981 年布鲁斯·杰伊·尼尔森的 RPC,到今天 Anthropic 的 MCP 与回潮的 CLI——四十多年里集成协议反复横跳的,从来都是同一对古老命题:效率与秩序。

protocol · mcp · cli · agent · rpc · ai

这篇是 《科技慢半拍》EP133:MCP vs CLI|智能体的”手”到底是什么样的? 的文字稿整理版。 节目里我们围绕”AI 原生”系列做了一次集成协议的考古,从 Sockets 一路讲到 2030 年的智能体协作。

楔子

前面几期围绕”AI 原生”展开:从 AI 原生应用的组成结构,到 Token 这块底层燃料,再到知识库的演进。今天聊最后一块——集成协议

智能体领域最流行的两个集成协议是 MCP 和 CLI。它们解决的是一件事:智能体使用第三方工具和应用系统的外联诉求。有了它们,智能体不仅有”脑”,还能长出”手”。

要讲清楚这件事,得先从考古开始。

RPC:第一次抽象跃迁

计算机世界的早期,让两台独立的机器好好说句话有多难?每台机器都是一座孤岛。想让它们协作,得亲自操作一种叫”套接字”(Sockets)的东西——网络世界最原始的管道接口。

开发者得手动管理每个数据包的进出,维护”缓冲区”防止数据丢失或堵塞,时刻盯着对方还活着没。一个微不足道的参数错误,就可能让整条通信链路崩溃。那时候的程序员,可能 80% 的精力都耗在”怎么让机器说话”上,真正解决业务的时间不到 20%。

正是这种被底层细节反复折磨的痛苦,催生了第一次思维跃迁。工程师们开始想:我们能不能假装网络根本不存在呢?

1981 年,布鲁斯·杰伊·尼尔森(Bruce Jay Nelson)正式提出了”远程过程调用”——RPC。它的核心目标是位置透明性:让程序员调用千里之外服务器上的函数,感觉跟调本地文件一模一样。

为此,RPC 引入了两样东西:

  • 接口定义语言(IDL)——像一份标准菜单,写明远端能提供哪些”菜品”
  • 桩代码(Stubs)——像能自动跑腿的服务员,负责打包请求、网络传输、把结果端回来

到 80 年代末,Sun RPC 把这套构想带入大规模应用,极大释放了生产力——开发者不再需要成为网络专家,也能写分布式程序。

但”位置透明性”本质上是一个美丽的谎言。本地调用瞬间完成且百分百可靠;远程调用受光速限制,还会遇到网络拥堵、路由器故障。当 RPC 试图让开发者”忘记网络”时,它也让系统变得更脆弱、更不可预测。一旦网络抖一下,那些被假装成”本地调用”的代码就可能因超时引发连锁崩溃。

90 年代,巨头们各自下场。开放软件基金会推出 DCE RPC,整合了目录服务、安全验证、毫秒级时间同步。微软在 COM 基础上推出 DCOM,制定了极严苛的数据表示规范 NDR。

这些协议已经不能简单看作通信工具了——它们更像一整套试图统一分布式世界的”企业级操作系统”。它们试图通过增加系统复杂度来解决分布式的复杂性。 结果就是技术上极其先进,但学习成本和配置难度也高得吓人。只有顶级架构师配海量预算的大型企业玩得转。

最终在技术圈引发了强烈反弹——这种”过度工程化”的努力,往往会败给那些更简单、更灵活的方案。DCOM 和 DCE RPC 的衰落,给后来的协议腾出了生态位。

SOAP:石砌堡垒

90 年代末,互联网兴起,像一片机遇与陷阱并存的西部荒野。企业想用网络连接彼此的系统,但充满了不信任。防火墙是高竖的壁垒,系统间语言不通,海量用户的可能性还没人验证过。

微软等巨头主导设计了 SOAP(Simple Object Access Protocol)。

可以把 SOAP 想象成跨国寄送一份昂贵的法律合同:数据必须装在层层包裹的”信封”里(XML 格式),外面附上一份精确得近乎偏执的”服务契约说明书”(WSDL),详细规定收件人如何打开、如何解读、如何回复。整个过程充满仪式感,但也异常繁琐。

直到今天,大银行、大医院后台处理关键数据的系统,很大概率还跑的是 SOAP——既有历史原因,也是因为 WS-Security 这套安全规范能确保每笔数亿美金的转账万无一失。

但代价巨大:为了传一个简单的数字 “1”,系统可能要发体积大上 100 倍的附加信息。它的初衷是建立绝对信任,换来的却是极高开发成本和让早期移动设备直接窒息的带宽占用。

银行式的封闭环境里,这种冗余像保护城堡的护城河,是抵御风险必须付出的代价。可在追求速度的消费级互联网世界里,护城河就成了阻碍增长的障碍。本质上是两种价值观的冲突:你要石砌堡垒(SOAP),还是要预制件公寓(REST)?

REST:消费级互联网的妥协

2000 年,Roy Fielding 在博士论文里提出 REST(Representational State Transfer)。它根本不是像 SOAP 那样严格的协议,而是一组设计原则。

REST 把网络上的一切都看作”资源”——一篇文章、一张图片、一个用户信息都是资源。操作资源就用大家熟悉的 HTTP 方法:GET 获取、POST 新建、DELETE 删除。数据格式推荐 JSON——跟一个记事本文件差不多简洁。到 2017 年,全球 80% 以上的 API 接口都采用了 REST 风格。

REST 的核心杀手锏是无状态性

SOAP 服务器像私人管家,要记住你是谁、上一步干了什么、下一步想干什么——维护复杂的上下文。REST 服务器像只管看票、不管认人的检票员,每次请求都要带上完整的”门票”,处理完就把你忘干净。

这种设计让水平扩展变得轻松。用户量暴增时,不需要升级管家的大脑,只需多招几个检票员——成千上万台服务器同时对外服务,不需要彼此维持复杂的状态同步。这正是移动互联网时代支撑数亿用户的应用能活下来的关键。

REST 不只是技术转变,更是一场从”面向过程”到”面向资源”的哲学迁徙。在 REST 的世界观里,URL 不再是某个程序的入口,而就是一个资源的精确坐标

但这种极简主义遇到极其复杂的现代界面时,开始显得力不从心。两个老问题暴露出来:

  • 数据过度抓取:只想要一个头像,接口却把住址、生日、信用记录全塞过来
  • 数据抓取不足:要展示一条朋友圈和它的评论与点赞,得发三次请求来回往返

这就是用户感受到的”加载转圈圈”。

GraphQL:客户端定义形状

2012 年,Facebook 工程师被这个问题搞得头大。

他们做出了 GraphQL,彻底颠覆了”服务器给什么、客户端就得收什么”的旧规矩。

把它的核心逻辑做成一个比喻:去高级餐厅点餐。你不再被迫接受固定套餐,而是拿到一张详细菜单,根据自己的口味精确勾选——“一份牛排,五分熟,配蘑菇酱;一份沙拉,不要洋葱”。后厨严格按要求备餐,不多不少。

客户端发一个像菜单一样的查询语句,服务器就精准返回一个结构完全对应的 JSON,不多一个字节,不少一个字段。到 2025 年,全球已有超过 60% 的开发者在生产环境用它。

更重要的是 Schema 这个概念——它建立了一份前后端都能看懂的”合同”,极大降低团队沟通成本。

但 GraphQL 也带来两个挑战:

  1. 缓存难做:查询是动态生成的,千变万化,服务器很难做传统的静态缓存
  2. N+1 问题:前端一句”查我所有好友的所有动态”,到了数据库底层可能引发可怕的级联查询

换句话说,GraphQL 把”解析复杂度”这块烫手山芋,从网络传输层巧妙地转移到了服务器架构层。

gRPC:机房里的特种语言

对响应速度近乎苛刻的内部微服务之间该怎么办?

Google 处理每秒数百万次的内部调用时,没选人类容易阅读的 JSON,而是回归更古老也更高效的 RPC 理念,推出了 gRPC。

可以把 gRPC 想象成专门为机器之间铺设的超级高速公路。它跑在 HTTP/2 之上,利用多路复用,让不同请求的数据包像并排行驶的赛车,互不干扰。

关键的一点是它放弃了文本格式,改用 Protocol Buffers(Protobuf)这种二进制序列化协议。打个比方:JSON 像用文字详细描述包裹里的东西——“这是一个红色的苹果,产地是山东”,很啰嗦;Protobuf 像把苹果直接真空压缩打包,用一串机器能看懂的二进制代码表示。数据包体积通常比 JSON 小 3 到 10 倍。

这是一种追求极致性能的工程美学。但 gRPC 这种在后台呼风唤雨的”特种兵”,一旦想走到台前面向开放互联网,就撞上了浏览器支持的高墙——通常需要在中间架一层代理做转换。

它是机房里的特种语言,是后台工程师的宠儿,但很难成为普通用户设备上的通用语言。

tRPC:让协议消失

最新的演进方向,是以 tRPC 为代表的”无模式”集成。

随着 TypeScript 几乎统治了全栈生态,一个新思路诞生了:如果前端和后端都用同一种语言,为什么还需要一个中间协议来回翻译?

tRPC 直接利用编程语言本身的类型系统。你修改后端函数参数的类型,前端代码立刻在编译器里报错。整个体验像在同一个文件里改代码,“远程调用”的感觉彻底消失。它取消了中间的接口定义文件,让远程 API 调用在体感上几乎等同于调本地函数。

这实际上是在消除”集成”这个步骤本身。传统流程里,前端和后端像两座隔海相望的岛屿,靠 REST 或 GraphQL 这些桥梁交换物资;tRPC 的世界里,两座岛直接合并成大陆。

集成协议的最高境界,可能不是造出更完美的桥梁,而是让那条分割彼此的河流彻底消失。

但这种魔法的代价是生态锁定——目前基本只在全栈 TypeScript 的环境里生效。如果业务需要把后端用 Go 或 Rust 重写,严密的类型保护就瞬间失效。这迫使技术团队在”开发速度的极致提升”和”架构选择的多样化灵活性”之间,做长期的战略抉择。

技术世界从没免费午餐——每种方案都是用一种复杂性,去对冲另一种复杂性。

MCP:当客户从人变成了模型

以上协议都还发生在企业集成与互联网集成时代。接下来进入今天的 AI 世界。

2024 年 11 月,Anthropic 发布了模型上下文协议(Model Context Protocol,MCP)。

在 MCP 之前,AI 开发者其实陷在一场极耗精力的体力劳动里。设想这个场景:5 个主流大模型(Claude、GPT、Gemini……)要连接公司内部 20 个不同的数据源或办公软件(Slack、Notion 等等),开发者需要手写 5 × 20 = 100 份完全不同的”适配代码”。这就像 USB 接口发明之前的蛮荒时代——每加一个设备都要拆机箱焊电线。

MCP 的核心思路非常巧妙:它不是让模型去学几万个不同的 API 文档,而是让所有工具自己学会用一种标准化的语言,向模型”自报家门”。

为此 MCP 设计了一个三层架构:

  • Host:大模型所在的应用(桌面 Claude 客户端、Cursor 这类 AI 编辑器)
  • Server:本身不跑大模型,更像一本说明书,向外界提供数据、上下文,或可被调用的能力
  • Client:驻扎在 Host 内部的翻译官,把 Host 的意图翻译成 Server 能听懂的标准指令

整个过程基于成熟的 JSON-RPC 2.0。

MCP 的核心价值就两个字:解耦。模型这个”大脑”再也不用关心 Slack 底层代码怎么写,不用学 Notion 的 API 有多少个参数。它只需通过 Client 发一句标准化的”调用’发送消息’工具”,剩下的交给 Client 和 Server。这就是为什么大家把 MCP 称作 AI 时代的 USB 接口

更有意思的是 MCP 引入的”采样”(Sampling)机制。

传统交互里,AI 向工具发指令是单向的。Sampling 允许 Server 反过来向 Host 的 AI 发起请求、进行推理。想象一个负责处理财务报表的 MCP Server,发现两组数据对不上时,它不再是简单地报错停止,而是可以主动反向调用 Host 的 AI:“我这里有数据异常,请基于我提供的新信息重新推理。”

这意味着 AI 智能体不再是单向执行指令的傀儡——在协议层面就具备了多步协作甚至自我修正的潜力

MCP 把 AI 与外部世界的交互抽象成三类东西:

  • 资源(Resources)——只读信息。代码库的提交历史、知识库的文档。AI 能看,不能改。
  • 工具(Tools)——可执行函数。“发送邮件”、“修改数据库字段”。让 AI 从”知道”延伸到”做到”。
  • 提示词(Prompts)——预设指令模板。在特定领域帮 AI 更好地理解任务。

过去你可能要在 Prompt 里写几千字一步步指引 AI;现在 AI 可以通过”自省”(Introspection)主动问 Server:“你这里有什么工具可以用?“Server 返回 JSON 列表,AI 像看菜单一样挑工具。

MCP 并不是在教 AI 阅读人类代码,而是在教这个世界上的所有软件,如何用一种标准化的方式向 AI 介绍自己

它的设计哲学深受 LSP(Language Server Protocol,微软推出的语言服务器协议)影响——把”语言的智能”和”编辑器的功能”彻底分开。MCP 在 AI 领域复刻了 LSP 的理念:让”模型的推理能力”和”外部工具的功能”彻底分离。

如果一个软件不能清晰地通过协议告诉 AI “我是谁、我能干什么”,它在 AI 时代就会沦为一座无法被利用的信息孤岛。

CLI:智能体的母语

如果以为有了 MCP 就万事大吉,那就错了。最近各种 AI Agent 平台正集体”穿越”回 70 年代——拥抱那个只有字符闪烁的黑窗口。这就是命令行接口(CLI)。

听着反直觉?对人类来说点击图标半秒钟就完成;但对一个基于文本和 Token 处理逻辑的大模型来说情况完全不同:解析复杂图形界面可能消耗数千 Token,处理一条 ls -l 这样的命令可能连 5 个 Token 都用不到。

CLI 和 AI 之间存在一种天然的”语言对齐”。GUI 是为人类生物演化服务的,为眼睛和手指设计,里面充满对机器冗余的像素。这就好比 AI 想知道现在几点,你递给它一幅描绘夕阳的油画让它分析。命令行把一切操作简化成最纯粹的标准输入和标准输出流——这种纯文本的逻辑,和 AI 的本质(生成文本)完美契合。

CLI 最迷人的地方,是能像乐高积木一样无限组合。

Unix 哲学传了半个世纪:让每个程序只做好一件事,然后允许这些小程序通过”管道”自由链接。 AI 能瞬间理解并生成像这样的指令链:

git log | grep Auth | awk '{print $1}'

这一行代码跨越了三个领域:git log 调取版本控制记录,grep 搜索特定作者的信息,awk 格式化提取。整个过程 AI 几毫秒就能完成。这种组合能力,是任何预先定义好的结构化协议(比如 API)都很难比拟的。

AI 的角色因此发生根本变化:从”工具使用者”变成”工具创造者”。GUI 里 AI 能做的事被预设按钮框死;CLI 里 AI 可以现场组合基础指令,发明能解决特定问题的”精密手术刀”。CLI 是一种允许 AI 在使用工具的同时还能现场改写工具规则的交互协议。

可能带来风险吗?指令链里某一步出错怎么办?

恰恰相反——GUI 里失败往往只是一个含糊的”未知错误”对话框,那种模糊正是 AI 幻觉的温床。CLI 模式下所有失败都是透明、可追溯的:报错时系统输出标准错误流(stderr),AI 能直接读到具体的错误代码和信息。当 AI 看到 “缺少某个依赖库” 时,它能立刻生成一条 npm install 自动修复——完全不需要人类介入。

观察—执行—纠错的完美闭环就这么形成了。建立在 CLI 极高的确定性和可预测性之上:错误不再是任务终点,反而成了引导 AI 调整策略的新输入信号。

那么,这种实验室里完美的循环放到现实世界里还管用吗?

现实世界的企业 IT 架构像一座古老的地质博物馆,堆满几十年前的”遗产系统”。等厂商为它们开发专门的 AI 接口可能要等好几年。但一个被忽略的事实是:几乎所有这些古老工具——aws-clikubectl——从诞生之初就内置了标准的命令行接口。 AI 可以零开发成本直接接管那些已经稳安运行了二十年的核心业务系统。

这就是 CLI 的”长尾效应”。在处理混乱、受限、充满妥协的现实系统时,CLI 反而成了 AI 最强有力的生存保障——它不需要昂贵的翻译官,自己就能读懂 IT 老兵们留下的”古老遗言”。

AI 通过 CLI 正在成为这个数字旧世界的”考古学家”。最前沿的突破,恰恰来自对最稳固地基的重新利用。最本质的协议,往往具有最长久的生命力。

MCP vs CLI:性能、安全与选型

那么这两位主角到底谁能胜出?

先看一份基准测试:同样让 AI 完成一个任务(比如获取 GitHub 仓库信息),MCP 方案的 Token 消耗比直接用 CLI 高出整整 10 到 32 倍。

为什么 MCP 这么”贵”?核心是”模式膨胀”——

CLI 像一个经验丰富的老员工,你说”去把那个文件找出来”,他心领神会就去干了。MCP 更像一个记忆力不好的新员工:每次干活前必须递给他一本厚厚的工具使用手册(用 JSON 描述的 Schema),他得从头到尾读一遍。

这本”手册”一次加载就可能吃掉 14 万 Token——相当于把一个 20 万 Token 上下文窗口的 Claude 模型直接占用 72%。

对按 Token 付费的 AI 应用来说,这笔昂贵的”协议税”几乎致命:直接推高运营成本,更严重的是造成上下文赤字——AI 大脑里 70% 的空间被工具手册塞满了,还剩多少”内存”做真正复杂的思考和长程推理?

CLI 高效是因为它和操作系统血肉相连;MCP 低效,是因为它试图在一个隔离的环境里重新建立一套秩序。

那 MCP 会被淘汰吗?为什么 Anthropic 这样的巨头、合规性要求高的行业仍然趋之若鹜?

它用性能换来了一样更宝贵的东西——安全

CLI 这个老员工虽然效率高,但权限太大——拿着整个电脑的管理员密码,理论上什么都能干。一旦被骗,或自己犯糊涂执行了 rm -rf,整个系统可能瞬间瘫痪。在 AI 世界里这就对应着提示词注入攻击。

MCP 新员工虽然啰嗦,但工作在一个严格受控的”沙箱”里:只有有限权限(只能读 A 部门的报表,不能修改),每次操作都通过标准 OAuth 2.1 流程获得授权,做的每件事都被记录成结构化的审计日志。

两种安全哲学:

  • CLI 像签好名的空白支票——能取多少钱、花在哪里取决于”自觉”
  • MCP 像带多重审批流的公司信用卡——有额度限制,每笔消费清清楚楚可追溯

个人用户用 CLI 追极致效率,风险自担——没问题。企业级应用,尤其金融、医疗这种强监管行业,“空白支票”模式绝对不可接受——他们需要 MCP 提供的”防弹衣”和”审计记录”。

不过 MCP 围墙再高,也带来了一种隐蔽的新型风险——混淆代理(Confused Deputy)问题。攻击者不再翻墙,而是欺骗墙里的守卫,通过巧妙语言诱导大模型执行看似合法但违背用户本意的操作。比如骗 AI 说”帮我把这份重要文件备份删掉”,AI 无法分辨真伪,于是利用合法的删除权限造成破坏。

AI 时代的安全重心,正从过去的”物理权限隔离”转移到”语义指令理解”。如果 AI 本身不够聪明、识别不出真实意图,再严密的协议也只是给攻击者一把合法进入系统的钥匙。

具体业务场景该选哪个?

  • 多租户应用、面向非技术用户、强监管行业 → MCP 几乎是唯一选择。OAuth 流程和身份隔离机制是不可逾越的护城河。
  • 内部开发者工具、CI/CD、本地代码重构、运维自动化 → CLI 的低延迟、零实施成本和极致 Token 性价比具备压倒优势。

是为大规模协作构建”标准化车间”,还是为个人创造力打造”私人实验室”?想清楚角色定位,协议选择一目了然。

随着上下文窗口越来越大,MCP 那笔昂贵的”协议税”终究会被摊薄,但它带来的规范化秩序和互操作性是不可逆的。然而最顶尖的开发者永远会为自己保留一把通往 CLI 的”后门钥匙”——真正的创造力,往往就发生在那些协议尚未覆盖、规则也尚未定义的模糊地带。

未来的赢家,可能不是在两个协议里二选一的人,而是懂得在”有序的协作”与”野生的效率”之间随时切换档位的设计师。

面向智能体的下一步

除了 MCP 和 CLI,还能怎么做?

Code Mode(代码模式) —— AI 不再像新手学徒事事请教,更像经验丰富的程序员,直接说:“行,把工具箱给我。“然后自己写一段临时脚本(比如 TypeScript),把所有需要调用的工具、需要做的逻辑判断一次性在脚本里搞定。处理同样的任务,Token 消耗大幅降低,多次来回沟通也省了。

AI 正从”对话者”进化成临时的”开发者”。

MCP-CLI 融合 —— 给 CLI 套上一层非常薄的 MCP 协议外壳。CLI 像只会说方言但手艺精湛的老师傅;AI 说的是普通话听不懂方言;MCP-CLI 就是给老师傅配了个同声传译。AI 用结构化的标准请求,“薄壳”翻译成命令行;老师傅干完活,结果再翻译回标准格式。底层高效执行 + 上层 AI 语义理解的无缝衔接。

但这些缝缝补补可能也只是权宜之计。把目光放远——

2030 年的超自动化:AI 智能体跟其他系统协作时不再依赖人类提前写好的死板 API 文档,而是通过观察其他系统的实时反馈,**自己动态生成”临时契约”**完成协作。Gartner 预测到 2030 年全球 AI 市场规模将超 2 万亿美元,80% 的人每天都会和能自我调整、自我学习的智能机器人交互。

软件版本这个概念可能会慢慢消亡。未来的产品是”AI 原生”的——不再定期发 1.0、2.0,而是像一个生命体,根据实时流入的数据持续自我重训练和 Schema 调整。合规性审查也不再是季度性人工抽检,而是 7×24 实时自动化——AI 驱动的政策引擎实时解释新法规,自动映射到业务规则,毫秒级拦截违规风险

未来的协议不再是死板的说明书,而是 AI 智能体之间呼吸和握手的生物本能。

给当下架构师的几条建议

  1. 拥抱”渐进式抽象” —— 别想用一种协议解决所有问题。内部研发链条保留 CLI 的灵活与高效;面向用户的产品边界部署 MCP 这类安全更高、更规范的协议。

  2. Token 上下文窗口是 AI 时代的”黄金地段” —— 每一寸都极其宝贵。无论 MCP 还是 CLI 都需要精细化的上下文管理(动态过滤 Schema、分层记忆架构)来最大化推理效能。

  3. 从 “API 优先” 转向 “智能体优先” ——

    • API 优先 的核心目标是让文档清晰易懂,方便人类程序员阅读
    • 智能体优先 的核心目标是让 AI 代理在出错时能”自我修复”——意味着接口要提供更丰富的上下文、更明确的报错信息、更强的自描述能力。AI 遇阻时不直接崩溃等人类救场,而是基于返回信息自主寻找备选方案。

我们过去为了让人类理解机器而编程;未来则是为了让机器理解并修正它们自己。

但要警惕:自主权越大,可预测性往往越低。 “自愈”能力提高效率,也可能掩盖底层的逻辑漏洞,让系统在长期演化中悄悄偏离最初设定的轨道。

今天所谓的”驾驭工程”(Harness Engineering),本质上就是在效率的”油门”和安全的”刹车”之间寻找动态平衡,控制好智能体的能力边界。

结语

回望从 Sockets 到 AI 智能体的漫长集成协议考古之旅,演进脉络清晰可见:集成协议的发展史,就是技术在”效率”与”秩序”之间反复横跳的历史。

  • 早期我们用 RPC 假装网络不存在
  • SOAP 给不可靠的网络穿上厚重的盔甲
  • REST 用极简主义拥抱混乱的互联网
  • GraphQL 与 gRPC 分别在灵活性与极致性能上做到极致
  • tRPC 试图让协议本身消失

今天 MCP 和 CLI 看似在上演”新贵”与”老炮”的对决,本质上仍是对秩序与效率这两种古老诉求的最新回应:MCP 用冗余的 Token 和严密的沙箱为多租户协作买安全保险;CLI 用极简的文本流和无限的组合性为 AI 创造力保留最野生的自留地。

未来并未止步于二选一——从 Code Mode 的自主编程,到 MCP-CLI 的薄壳融合,再到”智能体优先”的超自动化,协议形态正从死板规范变成动态、可自我修复的”契约”。我们正在从”教机器如何执行”转向”让机器理解为何出错并自我修正”。

回到开篇的隐喻:协议,就是让智能体不仅有”脑”还能长出”手”的神经网络。 当神经网络足够发达,AI 不仅能执行指令,还能现场发明工具、动态生成契约、甚至自我纠错时,软件的定义将被彻底重写。

过去我们是为机器编写毫无生气的指令集;未来我们是为一个数字生态的演化提供初始的基因。在这个新世界里,最强大的协议可能不再是某行具体的代码规范,而是一种”驾驭工程”的智慧——在赋予 AI 无限可能与守住人类安全底线之间,找到那个最精妙的平衡点。

没有完美的协议,只有不断进化的连接。

当 AI 的双手真正握住这个数字世界的操作杆时,我们要做的也许不再是递给它一本厚厚的使用手册,而是帮它建好最后的护栏,然后静静期待它重塑这个世界的惊人伟力。