AI 智能体如何通过 MCP 搭建可用的内部应用：一次分步拆解

AI 智能体可以在不写一行界面代码的情况下，把一套内部业务应用搭起来：它不是去生成一个 React 项目，而是一步一步调用平台已有的操作——创建页面、组件、查询和数据绑定——并在每一步之后校验结果。下面这次实操中，智能体仅凭一份文字需求，就搭出了一个三页的产品召回管理系统：10 张数据表、109 条初始数据、28 个查询和 109 个组件。

搭建 AI 应用的两种思路

一种思路是让智能体写更多代码：生成组件、数据请求逻辑，以及把它们连起来的胶水代码。当产物本身就是一份代码仓库时，这种做法很有效。代价是：每个生成出来的应用都会变成又一份需要有人理解、有人维护的代码库。内部工具会让这个取舍格外明显——数量多，各有各的负责人和生命周期，而维护它们的人往往更懂业务流程，而不是前端框架。

另一种思路是给智能体现在就有的抽象。它不再每次重新生成应用骨架，而是直接操作一个已经存在的平台：创建页面、添加组件、配置查询、读取内置数据库、连接事件、调整布局。模型依然决定要建什么，但不必把每一个决定都表达成代码。

智能体是怎么把系统搭起来的

任务以自然语言需求书的形式给出。这次的需求书约 1400 字，描述的是一家制造企业的产品召回系统：带关键指标的总体看板、跟踪单次召回从发现到关闭的详情页，以及汇总全部召回的处理动作日志。核心指令很朴素：把应用搭出来，保证各页面数据一致，并在进入下一步之前校验每个阶段。

随后智能体是按阶段推进的，而不是一口气写完。先是计划与数据模型，然后是第一页；一次单独的追加补上了第二页，之后又用一轮很短的迭代做出第三页。关键细节是：任何阶段在被应用之前，它的规格说明都要先通过校验，只有校验通过才拿到写入许可。

按可校验的阶段来搭建

循环是这样的：规划一个阶段、校验、修掉校验错误、应用、确认结果。校验拦下了几个真实问题：某个数据库列用了 SQL 保留字；某个绑定在组件挂载之前就引用了它；某个动作指向了组件的错误属性。这些问题都在阶段落地之前被拒绝。

重点不在于应用就此毫无错误，而在于：一次坏改动会被当作"对应用的非法操作"直接拒绝，而不是先变成一大段坏掉的代码、之后再回头调试。

为什么 token 消耗逐阶段下降

搭建过程中，一个粗略的预算计数器给出了很说明问题的曲线。第一轮大头——规划、数据模型和第一页——大约用了 19 万 token：智能体要读平台文档、弄清组件契约、确立应用结构。第二页及其改动约 8.4 万，后面第三页那一轮约 5.1 万。

原因很简单：后续工作复用了已经做出的决定。新页面不必从零搭——数据模型已经存在，组件类型已知，整体结构就在上下文里。这不仅降低成本，也降低风险：改动始终留在同一个应用模型内，而不是散落到几十个生成出来的文件里。

搭建完成后，应用依然是普通的

成品不会变成黑箱。智能体创建的表仍然是平台里普通的表：可以在可视化编辑器里选中、移动、改样式和属性。自动生成的查询能在查询编辑器里打开——图形模式下能看到数据源、表、操作和筛选，习惯 SQL 的人就用文本模式。

对内部工具来说，这一点比听上去更重要。维护工作常常会落到更懂业务流程、而不是更懂搭建工具的那个人身上。如果应用在 AI 收工后依然能用常规方式编辑，它就能比它的创造者活得更久。

这对团队意味着什么

主要结论：生成软件越来越便宜，让它保持可维护才是更难的问题。因此值得事先想清楚，在你的场景里什么更重要：第一次搭起来的速度，还是半年后改起来有多轻松。而当 AI 的界面是搭在已有平台之上、而不是一份全新的代码仓库之上时，维护门槛会明显更低。

你可以用一段描述在 「代码」板块 搭出自己的项目，并继续在上面迭代。

素材来源：dev.to 上的 ToolJet MCP 拆解。