Skip to content

WOVEN 为什么转向 MCP

我在琢磨:在 WOVEN x15 的 beta 期间拐个小弯,认真看一眼 MCP,再看看几种新的挂载方案。

要是你刚进来,捋一下:WOVEN 是我从 12 月起在搭的一套智能体系统。核心想法来自我自己的创作工作流——我想要的智能体,能随时间自我改进,能从经验里学东西。

对齐风险这摊事,一直有人争。我的感觉是:这是个发育问题和工效学问题,不是自上而下的控制问题。

从记忆到工具

x13 是第一个能跑的版本,记忆全接通了——但脆,而且对这活儿来说太单体了。不过它到现在还能用。

x14 加了工具层,把记忆系统整个重想了一遍。新设计用向量数据库,配一套图排序机制来给记忆排优先级。Google PageRank 的思路,我可能借了几笔——只是在这儿没有链接,用法就有点不一样。

把工具层做对,本身就是一道坎——尤其是长程智能体循环这里:你想支持多步工具调用,又不能掉进递归重复的陷阱,那坑祸害了一大堆别的系统。
x15 引入一个动态配置层,把 API 集成变简单了。

它本来跑得很好——直到我刚把它收拾利落……MCP 降临。

MCP 的取舍

起初我是抗拒的。MCP 给我的感觉,不像好工程。像潦草。

可我看得越多,越看见它的潜力。

眼下,x15 用的是 OpenAI 的工具框架。好处在于:支持面广,哪儿都可用。

我甚至自创了一套轻巧好用的 YAML 集成系统——可惜每个 endpoint 还是得单写一个。比全部手工接线领先好几条街……但离 MCP 那种无缝,还差得远。

取舍在哪?

MCP 要求对它管的每个 API 都保持常开的持久连接。断线、服务重启、CI/CD 流水线这些,会带来实打实的复杂度。但它把流式和动态应用设计,极大简化了。

说白了,你在造一个 API,拿它去管你手头的一堆 API——但只要零配置就能跑?那就是赢。

这会打乱我的日程——就是那条纯属自己瞎定、毫无根据的时间线。

我原打算下周起一个封闭 beta,收一轮反馈,然后开源发布。

如果我转向 MCP,把 x16 建出来——配这层替代工具层,再加五个新的服务集成——那就还得再拖三周。

就指望在我把它弄出来之前,别再有人把 AI 工具这摊事彻底重定义一遍。

求顺利。