MAK4I这个协议，像极了芯片里的总线标准之争

我注意到一个有意思的细节，MAK4I这个开源项目的仓库里写着「Phase 0 — Foundation」。做芯片的人看到这种状态标注，第一反应是这东西离能用还差着十万八千里。Phase 0意味着连骨架都没搭起来，顶多是纸上画了个架构图。但偏偏是这种阶段的项目，反而值得多看两眼。

先捋一下背景。MCP（Model Context Protocol）现在已经被当成AI界的USB-C口在推，OpenAI的Responses API在收编它，Google的Cloud文档也把它定义为标准化方案，连Claude、Cursor这些工具都原生支持了。看起来模型跟外部数据之间的互联问题，MCP快通吃了。但MAK4I想做的事情跟MCP不是一回事。MCP解决的是「模型怎么拿数据」，MAK4I解决的是「模型造出来的东西怎么被别的模型直接复用」。

这就有意思了。

做SoC的人都清楚，总线协议的战争从来不是技术之争，是生态位之争。当年AMBA总线为什么能统一江湖，不是因为ARM的协议写得比其他家漂亮，是因为ARM把IP授权跟总线绑定，你用了我的核，就得用我的总线。MCP现在走的也是这条路，OpenAI和Anthropic都在推，背后的算盘是：你接了我的协议，你就进了我的生态。

MAK4I想做的恰恰是绕开这个绑定。

它的思路是定义一种通用格式，让AI系统之间可以交换「产物」这个词我用得有点泛，大概意思是Agent跑完一轮任务后的输出物，包括中间结果、上下文状态、工具调用记录这些东西，打包成一个标准化的artifact，别的AI系统拿到就能接着用，不需要重新跑一遍。

短期看，这事的落地难度大得离谱。

我这边测下来，不同平台的artifact格式差异非常大。Claude的Artifacts是一个带版本的必要数据包，OpenAI的Code Interpreter产物是一坨文件系统，Vercel那个开源模板里接的又是各路API key的环境变量配置。要让这些都归一到一个格式底下，等于让所有大厂把自己生态里的产出物格式开源出来，这个利益冲突比MCP当年面对的大得多。MCP好歹是「连接」层面的标准化，连接是双赢的，主流的玩家都有动力参与。复用就不一样了，如果我的Agent能直接消费你的Agent的产物，那我为什么还要付钱给你的Agent呢。

还有一个更现实的问题，artifact的语义完整性。芯片里有IP核复用的成熟做法，RTL代码、验证环境、时序约束打包成IP包，整个业界有统一的标准。但AI的产物比这复杂一个量级。一个Agent在对齐了用户偏好、调用了特定工具、跑了半天的数据之后生成的结论，里面嵌了太多隐性的上下文。把这个东西打包传给另一个Agent，对方没有那些上下文，很容易产生错误解读。这个在技术上比MCP的「数据连接」难做很多，不是一个格式规范能解决的。

长期看，如果复用协议真能立住，倒是能催生一个更大的变化。现在AI开发有个很傻的现状，大家都在重复造轮子。每个Agent都自带一套技能、一份记忆、一堆prompt模板，换个平台全部作废。就像DIP封装时代，每颗芯片引脚定义全靠自己定，外设想连上去得重新设计接口。后来有了标准总线和标准封装，外设才变成即插即用。

我觉得可以把这两个协议放在一个表里看：

MCP的问题在于，它标准化的只是「数据怎么接进来」，不碰「结果怎么传出去」。MAK4I想补的正是后面这块。

不过我这边测下来，对这种Phase 0项目，我判断的标准从来不是PPT讲得多好，而是两个问题：第一个，有没有一个非用不可的场景；第二个，有没有一个强力玩家愿意扛旗推动。MAK4I现在的场景说实话还比较虚无缥缈，跨平台复用AI产物，这个问题真实存在，但现在大多数人的痛点还没痛到愿意为它掏钱改架构的程度。扛旗的Talvik也是家小公司，这个体量能不能把协议推到产业界形成正反馈，存疑。

协议这东西，造出来只是第一步。能活下来的从来不是技术上最好的，是生态里最省事的。MAK4I现在连协议都还算不上，顶多是一份写在GitHub里的愿望清单。不过回头想想，USB-C也一样，它刚出来的时候，谁也没想到能统一那么多接口。

---

本文编译自 Hacker News，原文：GitHub - talvikai/mak4i-protocol: Open protocol for reusable AI artifacts, knowledge continuity, and check-before-create workflows across AI tools. · GitHub
版权归原作者所有，本文为基于公开报道的编译与独立分析。