GPT-6 Astra 操作 GUI 引发 AI 地基争论

从 GUI、CLI 与机器人争论，看 AI 时代的“移动地基”

--

这两天 AI 群里有一场很有意思的争论。

一边有人说，GPT-6 Astra 这样的模型已经开始直接操作 GUI：看屏幕、移动鼠标、点按钮、处理异常。过去大家认真设计的 CLI、MCP、API wrapper，似乎一下都显得没那么必要了。

另一边的人很快泼来冷水：

“能上手 GUI 是一回事，跑在哪是另一回事。我们的 Agent 全在没有桌面的服务器上运行，CLI 不是设计偏好，是唯一能起得来的入口。”

还有人问得更直接：

“机器人你能等它每一步想几分钟、花几刀吗？”

这些话表面上在争 GUI、CLI、MCP，争 Computer Use 到底是不是未来，争机器人是不是还需要 VLA。

但放在一起，会发现大家不安的是另一件事：

当底层模型越来越聪明，今天被认为不可缺少的一层工程，半年后会不会忽然变成多余？

过去几年，AI 工程师做了大量工作：写 prompt、搭 workflow、做 router、建 RAG、封装 API、设计 MCP、训练专用 policy、给模型加记忆、加 verifier、加状态机。

其中有些工作会沉淀为长期基础设施。

也有些工作，可能只是因为模型当时还不够聪明。

模型一旦跨过某个能力阈值，那些精心搭起来的结构，就像施工完成后还没来得及拆掉的脚手架：突然失去了承重意义。

这不是一个纯技术问题，这是一个关于技术品味、产品判断、创业下注，甚至职业选择的问题。

因为今天的 AI 世界，很像一块正在移动的地基。

你刚把房子盖好，地面已经抬升了一层。

一、GUI、CLI 与 MCP 的争论，三方其实都没有错

激进的一派说得很痛快：

脑子够用，就直接硬解。

在他们看来，GUI 本来就是人类已经为软件世界建好的通用环境。几十亿个应用、后台、ERP、旧系统、网页工具，原本都需要被重新包装成 API、CLI、MCP，Agent 才能使用。

现在，如果模型能够理解屏幕、规划动作、点击按钮、看见反馈、修正错误，那么中间那一层层“翻译工程”就可以被绕过去。

过去的路径是：

软件 → API → wrapper → tool → Agent

现在似乎有了另一种路径：

软件 GUI → Agent

这背后的直觉很强：人类已经造好了一个巨大的软件世界，为什么还要再为机器重建一遍？

于是有人说了一句很有代表性的话：

闭环本身就是接口。

模型只要拥有观察通道、行动通道和反馈通道，就可以在“看见—行动—看结果—再修正”的循环里自己解决问题。

这个观点很有冲击力，但工程现实派说的也没错。

GUI 是一种为人类视觉、鼠标和手眼协调设计的界面。从机器角度看，“点击右上角的小齿轮”，显然不如 settings.update() 高效、便宜和确定。

如果一个任务可以用一次 API 调用、一次 shell 命令完成，为什么要让模型反复截图、理解页面、移动鼠标、点击、再截图确认？

更重要的是，很多 Agent 根本不运行在桌面环境里。

它们运行在无界面的服务器、容器、沙箱、云端工作区中。它们要处理的是批量任务、代码仓库、日志、数据库、定时任务和长期工作流。此时 CLI 不是审美偏好，而是现实约束。

所以，GUI 能不能用，和 GUI 是不是应该成为默认选择，是两回事。

还有第三种立场，我认为更接近未来。

不是 GUI 打败 CLI。

不是 MCP 打败 GUI。

而是：模型不再必须通过一种固定接口才能触达世界。

未来的 Agent 很可能拥有一个“接口选择能力”：

它自己判断：

• 这一步需要看屏幕，因为状态只在页面上出现；
• 这一步需要 shell，因为命令最快、最稳；
• 这一步需要 API，因为成本最低、结构最清楚；
• 这一步需要结构化 state，因为不能只靠视觉猜；
• 这一步需要人类确认，因为动作不可逆。

真正可能被淘汰的，是“世界必须先被包装成某一种固定接口，模型才能使用”的默认前提。

这是一种很深的工程哲学变化。

过去是：

先把世界整理成模型能理解的样子，再让模型做事。

现在正在变成：

先把世界暴露给模型；只有它处理不好的部分，再加结构。

这并不意味着结构没用了。

它意味着，结构的位置变了。

二、AI 的特殊之处在于：地基不只是变快，而是在向上长

过去的技术也一直进步。

CPU 更快，内存更便宜，带宽更高，云计算更普及。

但这些进步大多是在做同一件事：让原来的任务变得更快、更便宜、更大规模。

AI 的变化不同。

模型能力提升，不只是“同一项任务成本下降”。

它会获得过去属于上层软件、上层流程、上层人的能力。

模型开始理解长文本，于是某些复杂的检索拼接工作变得不再必要。

模型开始具备更强的规划和工具调用能力，于是一些硬编码 workflow 显得笨重。

模型开始看懂界面、使用鼠标键盘，于是“所有软件都必须先提供机器 API”这个前提松动了。

模型开始具备语义理解、错误恢复和任务拆解能力，于是机器人领域里一部分原本必须靠专项训练解决的问题，开始被通用推理模型侵入。

这就是“移动地基”最特殊的地方。

底层不只是变快。

底层在持续获得上层曾经赖以存在的能力。

于是，抽象边界不断上移。

昨天你还觉得必须存在的一层，今天可能变成优化项；昨天你以为是长期基础设施的东西，明天可能只是一个过渡期产品。

技术圈里常说“共识的保质期只有半年”，听起来像玩笑。

放在这里，却很准确。

因为 AI 时代真正变化的不是功能列表，而是：

哪一层复杂度，仍然值得由人长期维护。

三、很多工程复杂度，本质上是一种“智能不足税”

1987 年，Fred Brooks 在《没有银弹》里提出过一个经典区分。

有些复杂度来自问题本身，无法被消除；有些复杂度来自我们选择的工具、方法与表达方式，因此可以被改进。

这套区分放到 AI 时代，仍然有用。

今天至少可以把复杂度分成三类。

第二类，我愿意给它起一个很直白的名字：

Intelligence Scarcity Tax，智能不足税。

模型还不够聪明时，人就必须用大量工程结构去补。

你要告诉它每一步怎么做。

你要把复杂任务拆成固定流程。

你要设计 router，决定什么任务交给什么模型。

你要把软件包装成工具，把工具包装成 schema，把 schema 包装成 prompt。

你要用规则和状态机，把模型可能犯的每一种错误提前堵住。

这些东西在当时往往是非常优秀、非常务实的工程。

问题只在于：它们解决的是世界的约束，还是当时模型的约束？

如果只是后者，那么模型能力一旦上来，它们就会迅速折旧。

很多人最容易犯的错，不是做了会过时的东西。

而是把暂时性的能力缺口，误认为长期存在的产业结构。

四、所谓“脚手架坍缩”，并不是某个技术死了

今天最容易看到的，就是一层层脚手架正在发生不同程度的坍缩。

但“坍缩”不等于“死亡”。更准确地说，一项技术通常有四种命运：

• 真正消失；
• 从必要条件变成优化项；
• 暂时被绕过，但仍然会回来；
• 因为模型变强，反而变得更重要。

1. Prompt：从“给模型编程”到“给模型交代环境”

2023 年到 2024 年，大家热衷于各种 magic prompt。

角色设定、步骤拆解、思维链、几十条注意事项、复杂 few-shot、禁止模型做这个、要求模型做那个。

当时模型能力有限，提示词确实承担了大量“行为补偿”工作。

但模型越来越强后，工程重心开始从 prompt engineering 转向 context engineering。

Prompt 仍然重要，只是它不再那么像“给模型写程序”。

它更像是在交代：

• 目标是什么；
• 你处在什么环境；
• 哪些信息可信；
• 哪些动作不能做；
• 什么时候应该停下；
• 什么结果才算完成。

过去很多复杂 prompt，是为了牵着模型的手走。

未来更重要的，是让模型知道自己在什么地方、可以做什么、不能做什么。

这就是脚手架的第一种坍缩。

它没有消失，只是从主结构退成了薄层。

2. RAG：不是死亡，而是职责收缩

RAG 也很像。

过去大家默认认为：只要是私有知识、企业知识库、长文档任务，就要做 chunk、embedding、vector database、top-k、rerank、citation。

随着 long context、模型检索能力和原生搜索能力提高，最简单的 RAG 管线不再天然是唯一答案。

但这不意味着 RAG 没有价值。

大规模知识库、精确事实检索、成本控制、实时更新、权限隔离、来源追溯，这些需求都不会因为模型更聪明而消失。

RAG 只是从“所有问题的默认解”，变成“在特定约束下更好的解”。

这是 AI 工程里一个值得反复记住的模式：

模型能力提升，通常不会立刻杀死一个层；它会先把这个层从必要条件降级成条件性优化。

3. GUI、CLI 与 MCP：不是接口消失，而是“必须先封装”消失

GUI 很可能会成为 Agent 的通用兜底能力。

因为现实世界里有太多系统没有 API，没有干净的 CLI，没有人为 Agent 准备的 MCP。

模型能看懂界面，意味着它能进入这些原本封闭的环境。

但 GUI 不会因此成为最优接口。

只要有结构化 API，只要有可靠 CLI，只要有明确权限边界，生产系统仍然会偏爱更快、更便宜、更可审计的通道。

所以未来的主角不是 GUI，也不是 CLI。

而是一个更成熟的 Agent：它会自己挑选接口。

一项这轮研究引用的实验也很说明问题：同一模型只更换 Agent scaffolding，token 消耗就可能出现极大差异；而 MCP 和 CLI 本身并没有简单的固定胜负关系。

这意味着，大家可能一直问错了问题。

不是：

哪种接口赢？

而是：

哪些结构真的在帮助模型，哪些结构只是在把模型绑住？

4. 机器人：通用智能会吃掉上层，专用控制还会留在底层

机器人是最容易看清边界的地方。

关于 VLA 的表述很激烈，带着“几十个 PhD 干了一年，全被通用模型一下打穿”的情绪。

这种讲法指向的问题确实存在。

更强的通用模型，正在展示出一种能力：不经过任务专门微调，也可以进行语义理解、任务拆解、错误恢复、工具选择，甚至尝试高层机器人控制。

这会迅速侵蚀一部分原本需要专用模型承担的工作。

但实验也同时显示，精细插入、动态控制、复杂双臂协同、力反馈、实时轨迹控制，仍然远不稳定。

所以更可能的未来是重新划分边界：

通用模型

语义理解 / 任务规划 / 异常恢复

高层策略

专用控制器

实时动作 / 力控 / 轨迹 / 安全

 机器人

通用 intelligence 可能迅速吃掉 System 2。

但 System 1 并不会因此自动消失。

模型越聪明，越需要我们知道：它究竟该负责到哪里。

五、真正发生的，是复杂度迁移

很多人看到模型能力提升，会自然得出一个结论：

模型变强，工程会越来越少。

这也不准确。

更接近现实的图景是：

模型变强→能力补偿工程减少→真实世界约束工程增加

过去的技术栈大致是：

模型能力不足

Prompt / Workflow / Router / Planner

RAG / Wrapper / 专用 Policy

现实世界

未来可能更接近：

模型

推理 / 规划 / 工具选择 / 错误恢复

更薄的接口层

状态 / 权限 / 身份 / 安全

评估 / 审计 / 成本 / 治理

现实世界

上面那一层会被压薄。

下面那一层反而会变厚。

原因很简单。

模型越聪明，它能运行得越久。

运行得越久，它能调用的工具越多。

工具越多，它能造成的影响越大。

影响越大，失败路径就越复杂。

系统问题，不会因为模型更聪明而消失。

恰恰相反，模型越强，问题越急迫。

所以，未来真正厚重的基础设施，很可能不是替模型补智力的那一层。

而是帮助人类管理模型能力的那一层。

State、permission、identity、sandbox、observability、evaluation、authorization、auditability。

听起来不如“Agent 会自己点鼠标”性感。

但它们更接近真实世界。

六、创业者最该问的

对于 AI 创业来说，这件事尤其残酷。

传统软件创业会问：

• 用户有没有需求？
• 市场够不够大？
• 产品体验是不是更好？
• 获客成本是否能承受？

AI 创业还多了一个问题：

等我们把产品做出来的时候，这个需求还存在吗？

假设有两家创业公司。

第一家公司的核心价值是：

“模型处理不了 200 页合同，所以我们帮它切 chunk、做向量检索、搭一套复杂的 prompt pipeline。”

第二家公司的核心价值是：

“企业里的合同、审批规则、历史决策、员工身份、系统权限、财务预算都散落在不同系统里。我们负责把这些东西变成可信的 context、权限与执行闭环。”

两家公司今天看起来都在做 AI 基础设施。

但它们面对的风险完全不同。

第一家公司解决的是：模型现在不会。

第二家公司解决的是：模型再聪明，也无法天然知道。

模型能力增强十倍后，第一种价值可能下降。

第二种价值反而可能上升。

因为模型越能行动，企业越需要确认它是谁、能看什么、能花多少钱、能替谁做决定。

这就是两类产品最重要的区别：

当然，一个一年后可能被模型吞掉的产品，今天依然可能是一门好生意。

只要它：

• 价值产生得足够快；
• 开发周期足够短；
• 投入可以调整；
• 能在窗口期内回本；
• 能沉淀用户、数据、渠道或工作流；
• 能在下一次能力跃迁时转向别的层。

真正危险的不是做一座桥。

真正危险的是把一座桥，当作一百年的地基来建设。

七、在移动地基上，如何判断该把赌注下在哪里

如果要把这篇文章压缩成一套实际可用的判断框架，我会建议面对每个 AI 机会时，连续问七个问题。

1. 它解决的是世界的复杂度，还是模型的复杂度？

权限、成本、物理约束、法规、组织流程、真实状态，这些通常更接近世界本身。

长 prompt、手工分解、过度 wrapper、模型不会某种操作，这些更可能是阶段性问题。

先分清这两类，很多误判会自动减少。

2. 如果明天模型聪明十倍、便宜十倍，它的价值会上升还是下降？

这是最简单、也最残酷的测试。

价值下降的，说明你可能依赖能力缺口。

价值上升的，说明你更可能在帮助模型进入真实世界。

3. 这层工程是不是“智能不足税”？

不要因为一个结构今天必要，就默认它明天也必要。

如果它存在的唯一理由是“模型目前做不到”，就应该把它看作高折旧资产。

它可以赚钱。

但不能被误认为永恒护城河。

4. Time-to-Value 是否短于 Time-to-Obsolescence？

一个能力补丁即使未来会被吃掉，只要三个月能上线、六个月能回本、一年后可以转型，也可能是好项目。

反过来，如果一个项目需要两年建设，而模型可能在半年内跨过能力边界，它就要被重新审视。

5. 投入是否可逆？

Prompt、workflow、薄软件层，往往可以快速重写。

重资产数据采集、长期专用训练、深度绑定某个模型能力缺口的组织结构，则更难掉头。

在高度不确定的环境中，可逆性本身就是价值。

6. 你有没有把下注放到稳定变量上？

模型能力变化很快。

但有些东西变化很慢：

• 用户真正要完成的工作；
• 信任；
• 分发；
• 私有数据；
• 组织流程；
• 权限；
• 身份；
• 状态；
• 反馈闭环；
• 成本；
• 物理世界；
• 人的激励。

越靠近这些变量，越不需要赌自己能准确预测下一代模型。

7. 新模型发布当天，你的产品会自动变得更好，还是突然失去意义？

这是最重要的一问。

最好的架构，不是抵抗模型升级。

而是模型升级当天，什么都不用改，产品自然变强。

这才是真正意义上的“骑在能力曲线上”。

八、技术正确和商业正确，从来不是一回事

这里还有一个很容易被忽略的地方。

如果你在 2024 年判断：

“未来的前沿模型一定会直接操作 GUI，所以现在的 GUI automation 产品终究会被吃掉。”

这个技术判断可能完全正确。

但如果另一个团队做了这件事，在两年里拿到了大量客户、赚到了真钱、积累了数据、建立了渠道，随后再转型，那么对方在商业上可能仍然是对的。

企业价值不是“永远不会被替代”。

企业价值更接近：

现金流 × 时间窗口 × 资本投入 × 可迁移资产

短周期不等于坏生意。

长期正确，也不必然等于当下的好生意。

因此，真正成熟的原则不是：什么都别做，等更强的模型出现。

而是：

今天要做能产生价值的事；架构上，要为能力曲线留出余地。

Build for today, architect for the slope ，为当下而建，为斜坡而设计。

今天赚钱。

明天不被昨天的自己拖住。

九、技术品味，开始有了时间维度

我们过去理解技术品味，常常是：

感知复杂-发现异常-再把复杂放对地方

但在移动地基上，还要多一层判断：

这份复杂度，应该在那里待多久？

有些复杂度是现实本身的形状，模型再聪明也绕不过去。

有些复杂度只是今天模型还不够聪明的痕迹。

有些复杂度，则会因为模型越来越能行动，而变得比过去更重要。

所以，AI 时代的技术品味，也许可以增加一点：

技术品味，是辨认哪些复杂度不会被智能吃掉的能力。

真正高水平的技术判断，不是更准确地猜 GPT-7 会做什么。

而是尽可能找到一个位置：

无论 GPT-7 最后会什么，你的下注仍然成立。

>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。

*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；

*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；

关注我，一起AIGC从0到1~