MVC视觉三件套：系统如何在后AI时代重生

你打开一个网页，点了按钮，页面刷新了——这个过程里，计算机脑子里到底在想什么？

说出来你可能不信：它在想"谁来处理？谁来显示？谁来指挥？"这个三角争论，吵了五十年。

1979年，Trygve Reenskaug 在施乐帕克研究中心给这个争论画了个句号——他提出了 MVC 架构，把程序分成三个角色：Model（模型）、View（视图）、Controller（控制器）。当时没人想到，这个设计会成为贯穿五十年软件史的主线。

今天，从 Rails 到 React，从 J2EE 到 Spring MVC，这个三角结构依然活着，而且正在 AI 时代发生一场你可能没注意到的基因突变。

---

一、MVC 不是三部分，是三条命

很多人以为 MVC 就是"把代码分成三块"。错。它解决的是一个根本问题：让不同性质的东西不要搅在一起。

Model 是数据的脑子。它不关心数据长什么样、谁在看，只管存取和处理。你在数据库里新增一条记录，Model 负责这件事，干净利落。

View 是数据的这张脸。它只关心怎么把数据漂亮地展示出来。同一条用户列表，网页版和手机版可以完全不同，但 View 层只需要各自设计，不需要动 Model 一行代码。

Controller 是那个协调一切的中间人。它接收你的操作，判断该调用哪个 Model，等数据回来了，再决定该交给哪个 View。就像餐厅里的服务员——顾客说"我要点这个"，服务员去后厨下单，菜好了再端出来。

为什么这东西活了五十年？因为它解决的不是某个具体问题，而是软件复杂度最原始的根源：东西混在一起，改一处，动全身。

---

二、你每天都在用 MVC，只是不知道名字

举几个你肯定见过的例子。

Spring MVC（J2EE 的嫡系传人）： 你浏览器访问一个 URL，Tomcat 里的 DispatcherServlet 就是那个 Controller，它查 URL 找到对应的 Controller 方法，调用 Service 层（Model）处理业务，最后返回一个 JSP 页面（View）。这个模式支撑了中国几乎所有传统企业级系统——银行、政务、ERP，全都跑在这条线上。

Ruby on Rails： 当年让 MVC 概念普及到"普通创业者也能写网站"的功臣。Rails 约定大于配置：app/models 放模型，app/views 放页面，app/controllers 放控制器。你不需要读文档，按照目录结构猜都能猜对。

React（表面是 MVC 变异体）： 严格说 React 不完全遵循 MVC，因为前端没有天然的 Server 请求需要 Controller 截获。但 React 的组件里，数据逻辑（Model）、渲染（View）、事件处理（Controller）往往挤在一个文件里——所以很多人调侃 React 是 MTV（Model-Template-View）或者直接叫它"组件模式"。这不是批评，而是前端复杂度上升后的自然演进。

所以 MVC 死了吗？ 没死。它在每一条技术路线里换了一副面孔，但内核没变：分离关注点，降低耦合，让不同节奏的东西能够独立演化。

---

三、MVC 在 AI 时代遇到了新问题

MVC 设计之初，有个隐含假设：人操作计算机，计算机响应人。 请求是有限的、意图是明确的、输入是可控的。

AI 时代这个假设崩了。

当你的应用接入了大模型，对话不再是一条请求-响应链，而是一个持续的状态流。用户说"帮我写个报告"，这句话可能触发模型做 20 步推理、调用 5 次工具、生成 3 个版本的草稿——每一步都可能改变 Model 里的数据状态，每一次状态变化都可能需要刷新 View。

传统的 MVC 线性流程：用户请求 → Controller → Model → View → 响应，面对这种多轮并发、异步驱动的交互模式，开始力不从心。

OpenAI 的一位核心工程师 Ryan Lopopolo 在访谈里提过一个有趣的观点："传统 MVC 在 AI 时代需要重新定义，AI 原生版本应该是 Model-View-Claw。" Claw 就是 harness——那个"套住"模型、给它布置任务、收集结果的框架。

这不是在否定 MVC，而是在说：旧的三角色不够用了，需要扩展。

---

四、Model-View-Claw：MVC 的 AI 版本长什么样

传统 MVC 的 Controller 本质上是个"路由"——判断请求该去哪。但 AI 时代的 Claw（Harness）要做的事远不止路由。

它要管理上下文窗口。对话历史放进去了多少 tokens、哪些信息该保留、哪些该压缩——这件事 Controller 根本不管，但 Harness 得管。

它要处理工具调用循环。用户说"帮我分析这份财报"，模型可能需要：先调用文件读取工具，再调用数据分析工具，最后调用图表生成工具。这个串联逻辑不是 Controller 的职责范围，而是 Harness 的核心工作。

它还要做结果聚合与回填。模型每次工具调用都会返回结果，这些结果需要写回状态（Model），然后决定下一步推理还是直接生成回复（View）。整个过程是个循环，不是线性链。

换句话说：Controller 回答"做什么"，Harness 回答"怎么做、做到什么程度、做完之后怎么办"。

这个变化的本质是：模型从"被调用者"变成了"协作方"。传统架构里，Model 是被动的——Controller 调用它，它就工作。AI 架构里，Model（或者说 Agent）是主动的，它会反过来要求 Harness 提供什么上下文、调用什么工具、如何迭代。

---

五、MVC 五十年的启示：好架构是"不愿意死"的架构

回到 1979 年。Trygve Reenskaug 设计 MVC 时，目标是让 Smalltalk-80 的用户界面更容易开发。他没想到这个模式会跑赢所有"更先进"的架构方案，一直活到今天。

为什么？

因为 MVC 解决的不是某个具体场景的问题，而是软件复杂度最核心的矛盾：什么东西该变，什么东西不该一起变。 只要这个矛盾存在，MVC 的后代就不会消失。

从 J2EE 的 Servlet+JSP+Entity Bean，到 Rails 的 ActiveRecord+ERB+Controller，再到 React 的 State+Component+Hooks，以及 AI 时代的 Model+View+Harness——每代人都觉得自己在"重新定义架构"，但细看都是 MVC 在新土壤里的发芽。

所以对你有什么启发？

学一个新框架，别急着追新词汇。先问自己：它的 Model 在哪？ View 在哪？ Controller 或者等价的东西在哪？理解了这个三层关系，你就理解了这个框架一半的设计逻辑。

剩下的另一半，是它在这个三角关系上做了哪些权衡——因为每个时代，权衡的点都不一样。

---

MVC 五十岁了。它可能不是最好的架构，但它可能是最诚实的架构——它承认了一件事：软件世界里，分工是最古老也最有效的解药。