AI 时代的软件应该是怎么样的？

最近我一直在想一个问题：

AI 到底会把软件变成什么样？

一开始我想到的是 GUI 。

过去几十年，软件的发展看起来一直在降低使用门槛：

机器码太难，于是有汇编；
汇编太难，于是有高级语言；
编程太难，于是有 GUI ；
后来又有低代码、零代码。

但后来我发现，这条线如果只理解成“抽象层不断上移”，其实还不够准确。

因为复杂性从来没有消失。

低代码把：

if / else + 函数 + 状态机

换成了：

节点 + 连线 + Workflow

业务一复杂，最后依然会变成一张巨大的蜘蛛网。

所以过去的软件革命，本质上更多是在做：

重新表达复杂性，让人更容易处理它。

但 AI 有一点不一样。

以前的软件告诉你：

我给你一个更容易操作的工具，你来告诉我每一步怎么做。

AI 开始变成：

你告诉我目标，剩下的步骤我来拆。

过去真正的 Planner 和 Orchestrator ，其实一直是人。

比如我想订一次出差：

Goal
 ↓
人拆任务
 ↓
查日历
 ↓
查高铁
 ↓
查酒店
 ↓
查地图
 ↓
比价格
 ↓
下单

今天我们说“用户在使用软件”。

但从系统视角看，用户自己其实就是那个 Agent 。

而未来更可能是：

Goal
 ↓
Agent Runtime
 ↓
Plan
 ↓
Tool / Capability Selection
 ↓
Execution
 ↓
Evaluation
 ↓
Replan

人开始停留在 Goal 层。

这意味着软件架构本身也会变化。

---

1. Agent 很像一个动态 BFF

我觉得程序员比较容易理解的类比是 BFF 。

传统架构：

Frontend
   ↓
BFF
   ↓
Service A
Service B
Service C

BFF 负责把多个后端服务组合成前端需要的数据和流程。

但问题是：

传统 BFF 的 orchestration 是程序员提前写死的。

比如订单详情页：

getOrder()
getUser()
getLogistics()
getCoupon()
assembleOrderDetail()

页面在开发阶段就已经决定了要调用什么。

Agent 出现以后，这层有可能变成动态的：

User Goal
    ↓
Agent
    ↓
Dynamic Planning
    ↓
Capability Discovery
    ↓
A → D → F
       ↓
   根据结果
       ↓
      再调 G

所以它不只是 Backend for Frontend 。

更像：

Backend for Goal 。

或者更准确一点：

Goal-driven Runtime 。

未来的软件公司可能不再只提供完整 App ，而是提供一组可组合的 Capability：

search_product()
compare_product()
create_order()
pay()
refund()

地图提供：

search_place()
route()
navigation()
traffic()

酒店提供：

search_room()
book()
cancel()

然后用户侧 Agent 根据 Goal 动态组合这些能力。

从这个角度看：

微服务把能力从单体应用里拆出来，Agent 再根据用户目标，把这些能力动态组合回去。

我觉得这可能会是 AI Native 软件一个很重要的架构变化。

---

2. 但只有 Capability 还远远不够

一开始我以为未来软件只需要：

Agent + API

后来看到一篇关于 Embodied Agent Harness 的论文，我突然意识到：

真正缺的可能不是 Tool ，而是 Harness 。

为什么 Coding Agent 这两年发展得这么快？

因为软件开发这个领域，天然已经有一套极其适合 Agent 的环境：

State       → Repo / Filesystem
Observation → grep / search / AST
Action      → shell / editor / compiler
Feedback    → stdout / stderr
Evaluation  → test / lint / benchmark
Rollback    → git diff / revert
History     → commit / log

换句话说：

程序员过去几十年，为自己搭软件开发基础设施的时候，无意中已经给 Coding Agent 搭好了 Harness 。

Agent 可以：

读代码
 ↓
改代码
 ↓
编译
 ↓
失败
 ↓
读 stderr
 ↓
继续修改
 ↓
跑 test

这是一个天然闭环。

---

3. 其他领域其实都缺这样一层

比如电商。

今天淘宝给人的环境已经非常成熟：

商品页
搜索
筛选
购物车
订单
售后

但这些都是 Human Interface 。

一个 Agent 真正需要的不是商品详情页，而是：

State
├── Product
├── SKU
├── Inventory
├── Price
├── Delivery Time
├── User Preference
└── Refund Policy

Actions
├── search()
├── compare()
├── create_order()
├── pay()
└── refund()

Evaluation
├── 是否满足预算？
├── 是否有库存？
├── 是否能按时送达？
└── 是否真正下单成功？

这才是一个 Commerce Agent 能稳定工作的环境。

所以我现在会区分两个概念：

API 只是 Capability 。

Harness 才是 Agent 的运行环境。

一个完整 Harness 至少应该包含：

State / World Model
Observation
Capability / Action
Constraint / Permission
State Transition
Evaluation
Failure Feedback
Recovery

完整 loop 大概是：

               Domain Harness

          ┌────── State ──────┐
          │                   │
       Observe             Context
          │                   │
          ▼                   │
        Agent ←───────────────┘
          │
         Plan
          │
          ▼
      Capability
          │
          ▼
      Environment
          │
          ▼
       Evaluation
          │
     ┌────┴────┐
 Success     Failure
                │
                ▼
             Replan

这就比“给 Agent 接几个 API”要完整得多。

---

4. 我现在越来越觉得：AI Native 开发的核心工作之一，是建设 Domain Harness

如果这个判断成立，那么不同领域未来都可能需要自己的 Harness：

Coding
→ Coding Harness

Robotics
→ Physical Harness

Autonomous Driving
→ Simulation / Driving Harness

Commerce
→ Commerce Harness

Delivery
→ Delivery Harness

Education
→ Learning Harness

Enterprise
→ Enterprise Harness

每个 Harness 真正要解决的其实都是同样几个问题：

1. 这个世界里有哪些 Entity 和 State ？
2. Agent 怎么观察这些状态？
3. Agent 可以执行哪些 Action ？
4. Action 的 precondition 是什么？
5. Action 执行后应该发生什么 state transition ？
6. 怎么判断执行成功？
7. 失败时能拿到什么 diagnostic ？
8. 如何 retry / replan / rollback ？
9. 哪些动作必须 Human-in-the-loop ？
10. 整个过程如何被 trace 和 evaluate ？

如果这些东西没有解决，模型再强，也只能像一个“会说话但没有操作系统的聪明人”。

---

5. 这也解释了为什么 Computer Use 可能只是过渡层

现在很多 Agent 在做的事情是：

Agent
 ↓
看屏幕
 ↓
识别按钮
 ↓
点击 GUI
 ↓
猜测状态有没有变化

这其实是在让 AI 模拟人。

某种意义上等价于：

不给 Coding Agent shell 、git 、compiler 和 test ，只给它一张 IDE 截图，然后让它拿鼠标写代码。

当然能做。

但很难成为最优架构。

所以我更愿意把 Computer Use 看成一种：

Legacy Compatibility Layer 。

也就是 AI 用 Human Interface 去兼容旧的软件世界。

真正 AI Native 的系统应该是：

Agent
 ↓
Harness
 ↓
Structured State
 ↓
Typed Capabilities
 ↓
Evaluation
 ↓
Underlying System

前者是：

AI 适配旧软件。

后者才是：

软件开始为 AI 重新设计。

---

6. 所以软件可能从 App-centric 走向 Agent-centric + Capability-centric

传统软件往往把很多东西绑在一个 App 里：

UI
Workflow
User Context
Capability
Data

未来这些东西可能逐渐解耦：

Agent       → Goal / Context / Planning
Harness     → Runtime / State / Evaluation
Provider    → Capability
UI          → Visualization / Human-in-the-loop
Backend     → Data / Transaction

这时候 UI 不会消失。

但它可能不再是整个系统的控制中心。

尤其是数据分析、设计、自动驾驶仿真这种领域，GUI 依然非常重要。

只是它的角色会从：

Control Interface

更多变成：

Understanding / Verification Interface 。

Agent 执行。

人通过 UI 查看、理解、确认、修正。

---

7. AI 真正改变的，可能是“复杂性由谁承担”

所以回到最开始的问题。

过去的软件一直在：

让人用更好的抽象去处理复杂性。

而 Agent 开始做另一件事：

替人理解、组织和执行复杂性。

复杂性当然没有消失。

甚至系统内部可能更复杂了。

但复杂性开始从：

Human Cognitive Load

迁移到：

Agent Runtime + Harness

这可能才是 AI 和之前 GUI 、低代码最大的不同。

如果要用一句话总结：

GUI 是把复杂世界翻译成人可以操作的形式； Harness 是把复杂世界翻译成 Agent 可以观察、操作、验证和恢复的形式。

过去几十年，软件行业主要在建设 Human Interface 。

我越来越觉得，未来很长一段时间里，一个很重要的新工程方向会是：

建设 Agent Interface 和 Domain Harness 。

而真正有价值的 AI Native 软件，可能不是“一个大模型 + 一个聊天框”。

而是：

Model
+
Agent Runtime
+
Domain Harness
+
Capabilities
+
Evaluation
+
Human Interface

模型可以不断替换。

真正决定这个系统能不能在一个行业里可靠工作的，很可能是模型外面的这一整层。