ToolJet 抛弃自家多 Agent 系统

这篇帖子刚看完，有点意思。这哥们做 internal tools 的 ToolJet，之前花了 11 个月自己搞了一个多 Agent 系统，当时还挺受欢迎。结果去年下半年发现客户不买账了，纷纷转向 vibe-coding 方式。

他们自己也试着跟风，但觉得 vibe-coding 还是不适合自己的用户——既有小白用户，也有靠谱的开发者，他们信任 ToolJet 构建关键的内部工具。但如果交给 LLM 乱搞一堆看不懂的 codegen，然后背后变成一个只能听 prompt 的黑盒子，他们也不会满意。

更要命的是：他们每次新加功能，都得重新教自己的 Agent，一轮又一轮。而 Claude Code、Codex 这些工具每天都在进化。Grok Build 甚至从垃圾变成还行。

所以他们一怒之下，全部推翻，把整个平台通过 MCP 暴露出去，让 coding agent 直接来操作。

什么意思呢？

ToolJet 的应用结构还是一样，有页面、组件、查询、集成、事件、状态管理等抽象。但这些抽象的 config 不是靠他们的 Agent 生成，而是交给外部的 coding agent 来生成。比如说，你想要一个 table 绑定一个 query，一个 button 打开 modal，一个 form 更新记录——以前这些可能需要生成一堆 React 代码、状态管理逻辑、CSS 样式、API 接口。现在呢？模型只需要描述这些东西怎么连接就行了，根本不用生成代码。

这带来的好处还挺惊人：

• 生成内容少了很多：不用写 React、状态管理、CSS、API 了，只描述结构和连接。
• 支持 100+ 数据源：以前得为每个数据源配一个 Agent，现在统统可以通过 MCP 驱动。
• 用户可以用自己的 coding agent 账号：不用掏 ToolJet 的 API 钱。当然如果用户没有订阅，也可以用他们搭的小平台，按 API 计费。
• 兼容其他 MCP：比如从 Figma 拿设计稿，或迁移别处的应用。

他们的想法是：未来这个领域会分化。pro-code + prompt-first 的方式会有自己的支持者。但他们选择的是：把平台和抽象暴露出来给 coding agent 使用，同时保留可视化拖拽 builder，方便人在需要时手动调整。

MCP 服务的 repo 在 GitHub 上：tooljet-mcp

---