AI 时代的软件应该是怎么样的？
最近我一直在想一个问题：
**AI 到底会把软件变成什么样？**
一开始我想到的是 GUI 。
过去几十年，软件的发展看起来一直在降低使用门槛：
机器码太难，于是有汇编；
汇编太难，于是有高级语言；
编程太难，于是有 GUI ；
后来又有低代码、零代码。
但后来我发现，这条线如果只理解成“抽象层不断上移”，其实还不够准确。
因为复杂性从来没有消失。
低代码把：
```text
if / else + 函数 + 状态机
```
换成了：
```text
节点 + 连线 + Workflow
```
业务一复杂，最后依然会变成一张巨大的蜘蛛网。
所以过去的软件革命，本质上更多是在做：
**重新表达复杂性，让人更容易处理它。**
但 AI 有一点不一样。
以前的软件告诉你：
> 我给你一个更容易操作的工具，你来告诉我每一步怎么做。
AI 开始变成：
> 你告诉我目标，剩下的步骤我来拆。
过去真正的 Planner 和 Orchestrator ，其实一直是人。
比如我想订一次出差：
```text
Goal
↓
人拆任务
↓
查日历
↓
查高铁
↓
查酒店
↓
查地图
↓
比价格
↓
下单
```
今天我们说“用户在使用软件”。
但从系统视角看，用户自己其实就是那个 Agent 。
而未来更可能是：
```text
Goal
↓
Agent Runtime
↓
Plan
↓
Tool / Capability Selection
↓
Execution
↓
Evaluation
↓
Replan
```
人开始停留在 Goal 层。
这意味着软件架构本身也会变化。
---
## 1. Agent 很像一个动态 BFF
我觉得程序员比较容易理解的类比是 BFF 。
传统架构：
```text
Frontend
↓
BFF
↓
Service A
Service B
Service C
```
BFF 负责把多个后端服务组合成前端需要的数据和流程。
但问题是：
**传统 BFF 的 orchestration 是程序员提前写死的。**
比如订单详情页：
```text
getOrder()
getUser()
getLogistics()
getCoupon()
assembleOrderDetail()
```
页面在开发阶段就已经决定了要调用什么。
Agent 出现以后，这层有可能变成动态的：
```text
User Goal
↓
Agent
↓
Dynamic Planning
↓
Capability Discovery
↓
A → D → F
↓
根据结果
↓
再调 G
```
所以它不只是 Backend for Frontend 。
更像：
**Backend for Goal 。**
或者更准确一点：
**Goal-driven Runtime 。**
未来的软件公司可能不再只提供完整 App ，而是提供一组可组合的 Capability：
```text
search_product()
compare_product()
create_order()
pay()
refund()
```
地图提供：
```text
search_place()
route()
navigation()
traffic()
```
酒店提供：
```text
search_room()
book()
cancel()
```
然后用户侧 Agent 根据 Goal 动态组合这些能力。
从这个角度看：
> **微服务把能力从单体应用里拆出来，Agent 再根据用户目标，把这些能力动态组合回去。**
我觉得这可能会是 AI Native 软件一个很重要的架构变化。
---
## 2. 但只有 Capability 还远远不够
一开始我以为未来软件只需要：
```text
Agent + API
```
后来看到一篇关于 Embodied Agent Harness 的论文，我突然意识到：
**真正缺的可能不是 Tool ，而是 Harness 。**
为什么 Coding Agent 这两年发展得这么快？
因为软件开发这个领域，天然已经有一套极其适合 Agent 的环境：
```text
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 可以：
```text
读代码
↓
改代码
↓
编译
↓
失败
↓
读 stderr
↓
继续修改
↓
跑 test
```
这是一个天然闭环。
---
## 3. 其他领域其实都缺这样一层
比如电商。
今天淘宝给人的环境已经非常成熟：
```text
商品页
搜索
筛选
购物车
订单
售后
```
但这些都是 Human Interface 。
一个 Agent 真正需要的不是商品详情页，而是：
```text
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 至少应该包含：
```text
State / World Model
Observation
Capability / Action
Constraint / Permission
State Transition
Evaluation
Failure Feedback
Recovery
```
完整 loop 大概是：
```text
Domain Harness
┌────── State ──────┐
│ │
Observe Context
│ │
▼ │
Agent ←───────────────┘
│
Plan
│
▼
Capability
│
▼
Environment
│
▼
Evaluation
│
┌────┴────┐
Success Failure
│
▼
Replan
```
这就比“给 Agent 接几个 API”要完整得多。
---
## 4. 我现在越来越觉得：AI Native 开发的核心工作之一，是建设 Domain Harness
如果这个判断成立，那么不同领域未来都可能需要自己的 Harness：
```text
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 在做的事情是：
```text
Agent
↓
看屏幕
↓
识别按钮
↓
点击 GUI
↓
猜测状态有没有变化
```
这其实是在让 AI 模拟人。
某种意义上等价于：
> 不给 Coding Agent shell 、git 、compiler 和 test ，只给它一张 IDE 截图，然后让它拿鼠标写代码。
当然能做。
但很难成为最优架构。
所以我更愿意把 Computer Use 看成一种：
**Legacy Compatibility Layer 。**
也就是 AI 用 Human Interface 去兼容旧的软件世界。
真正 AI Native 的系统应该是：
```text
Agent
↓
Harness
↓
Structured State
↓
Typed Capabilities
↓
Evaluation
↓
Underlying System
```
前者是：
**AI 适配旧软件。**
后者才是：
**软件开始为 AI 重新设计。**
---
## 6. 所以软件可能从 App-centric 走向 Agent-centric + Capability-centric
传统软件往往把很多东西绑在一个 App 里：
```text
UI
Workflow
User Context
Capability
Data
```
未来这些东西可能逐渐解耦：
```text
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 开始做另一件事：
**替人理解、组织和执行复杂性。**
复杂性当然没有消失。
甚至系统内部可能更复杂了。
但复杂性开始从：
```text
Human Cognitive Load
```
迁移到：
```text
Agent Runtime + Harness
```
这可能才是 AI 和之前 GUI 、低代码最大的不同。
如果要用一句话总结：
> **GUI 是把复杂世界翻译成人可以操作的形式； Harness 是把复杂世界翻译成 Agent 可以观察、操作、验证和恢复的形式。**
过去几十年，软件行业主要在建设 Human Interface 。
我越来越觉得，未来很长一段时间里，一个很重要的新工程方向会是：
**建设 Agent Interface 和 Domain Harness 。**
而真正有价值的 AI Native 软件，可能不是“一个大模型 + 一个聊天框”。
而是：
```text
Model
+
Agent Runtime
+
Domain Harness
+
Capabilities
+
Evaluation
+
Human Interface
```
模型可以不断替换。
真正决定这个系统能不能在一个行业里可靠工作的，很可能是模型外面的这一整层。
---
原文链接：[点击查看](https://www.v2ex.com/t/1234321)
**AI 到底会把软件变成什么样？**
一开始我想到的是 GUI 。
过去几十年，软件的发展看起来一直在降低使用门槛：
机器码太难，于是有汇编；
汇编太难，于是有高级语言；
编程太难，于是有 GUI ；
后来又有低代码、零代码。
但后来我发现，这条线如果只理解成“抽象层不断上移”，其实还不够准确。
因为复杂性从来没有消失。
低代码把：
```text
if / else + 函数 + 状态机
```
换成了：
```text
节点 + 连线 + Workflow
```
业务一复杂，最后依然会变成一张巨大的蜘蛛网。
所以过去的软件革命，本质上更多是在做：
**重新表达复杂性，让人更容易处理它。**
但 AI 有一点不一样。
以前的软件告诉你：
> 我给你一个更容易操作的工具，你来告诉我每一步怎么做。
AI 开始变成：
> 你告诉我目标，剩下的步骤我来拆。
过去真正的 Planner 和 Orchestrator ，其实一直是人。
比如我想订一次出差：
```text
Goal
↓
人拆任务
↓
查日历
↓
查高铁
↓
查酒店
↓
查地图
↓
比价格
↓
下单
```
今天我们说“用户在使用软件”。
但从系统视角看，用户自己其实就是那个 Agent 。
而未来更可能是：
```text
Goal
↓
Agent Runtime
↓
Plan
↓
Tool / Capability Selection
↓
Execution
↓
Evaluation
↓
Replan
```
人开始停留在 Goal 层。
这意味着软件架构本身也会变化。
---
## 1. Agent 很像一个动态 BFF
我觉得程序员比较容易理解的类比是 BFF 。
传统架构：
```text
Frontend
↓
BFF
↓
Service A
Service B
Service C
```
BFF 负责把多个后端服务组合成前端需要的数据和流程。
但问题是：
**传统 BFF 的 orchestration 是程序员提前写死的。**
比如订单详情页：
```text
getOrder()
getUser()
getLogistics()
getCoupon()
assembleOrderDetail()
```
页面在开发阶段就已经决定了要调用什么。
Agent 出现以后，这层有可能变成动态的：
```text
User Goal
↓
Agent
↓
Dynamic Planning
↓
Capability Discovery
↓
A → D → F
↓
根据结果
↓
再调 G
```
所以它不只是 Backend for Frontend 。
更像：
**Backend for Goal 。**
或者更准确一点：
**Goal-driven Runtime 。**
未来的软件公司可能不再只提供完整 App ，而是提供一组可组合的 Capability：
```text
search_product()
compare_product()
create_order()
pay()
refund()
```
地图提供：
```text
search_place()
route()
navigation()
traffic()
```
酒店提供：
```text
search_room()
book()
cancel()
```
然后用户侧 Agent 根据 Goal 动态组合这些能力。
从这个角度看：
> **微服务把能力从单体应用里拆出来，Agent 再根据用户目标，把这些能力动态组合回去。**
我觉得这可能会是 AI Native 软件一个很重要的架构变化。
---
## 2. 但只有 Capability 还远远不够
一开始我以为未来软件只需要：
```text
Agent + API
```
后来看到一篇关于 Embodied Agent Harness 的论文，我突然意识到：
**真正缺的可能不是 Tool ，而是 Harness 。**
为什么 Coding Agent 这两年发展得这么快？
因为软件开发这个领域，天然已经有一套极其适合 Agent 的环境：
```text
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 可以：
```text
读代码
↓
改代码
↓
编译
↓
失败
↓
读 stderr
↓
继续修改
↓
跑 test
```
这是一个天然闭环。
---
## 3. 其他领域其实都缺这样一层
比如电商。
今天淘宝给人的环境已经非常成熟：
```text
商品页
搜索
筛选
购物车
订单
售后
```
但这些都是 Human Interface 。
一个 Agent 真正需要的不是商品详情页，而是：
```text
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 至少应该包含：
```text
State / World Model
Observation
Capability / Action
Constraint / Permission
State Transition
Evaluation
Failure Feedback
Recovery
```
完整 loop 大概是：
```text
Domain Harness
┌────── State ──────┐
│ │
Observe Context
│ │
▼ │
Agent ←───────────────┘
│
Plan
│
▼
Capability
│
▼
Environment
│
▼
Evaluation
│
┌────┴────┐
Success Failure
│
▼
Replan
```
这就比“给 Agent 接几个 API”要完整得多。
---
## 4. 我现在越来越觉得：AI Native 开发的核心工作之一，是建设 Domain Harness
如果这个判断成立，那么不同领域未来都可能需要自己的 Harness：
```text
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 在做的事情是：
```text
Agent
↓
看屏幕
↓
识别按钮
↓
点击 GUI
↓
猜测状态有没有变化
```
这其实是在让 AI 模拟人。
某种意义上等价于：
> 不给 Coding Agent shell 、git 、compiler 和 test ，只给它一张 IDE 截图，然后让它拿鼠标写代码。
当然能做。
但很难成为最优架构。
所以我更愿意把 Computer Use 看成一种：
**Legacy Compatibility Layer 。**
也就是 AI 用 Human Interface 去兼容旧的软件世界。
真正 AI Native 的系统应该是：
```text
Agent
↓
Harness
↓
Structured State
↓
Typed Capabilities
↓
Evaluation
↓
Underlying System
```
前者是：
**AI 适配旧软件。**
后者才是：
**软件开始为 AI 重新设计。**
---
## 6. 所以软件可能从 App-centric 走向 Agent-centric + Capability-centric
传统软件往往把很多东西绑在一个 App 里：
```text
UI
Workflow
User Context
Capability
Data
```
未来这些东西可能逐渐解耦：
```text
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 开始做另一件事：
**替人理解、组织和执行复杂性。**
复杂性当然没有消失。
甚至系统内部可能更复杂了。
但复杂性开始从：
```text
Human Cognitive Load
```
迁移到：
```text
Agent Runtime + Harness
```
这可能才是 AI 和之前 GUI 、低代码最大的不同。
如果要用一句话总结：
> **GUI 是把复杂世界翻译成人可以操作的形式； Harness 是把复杂世界翻译成 Agent 可以观察、操作、验证和恢复的形式。**
过去几十年，软件行业主要在建设 Human Interface 。
我越来越觉得，未来很长一段时间里，一个很重要的新工程方向会是：
**建设 Agent Interface 和 Domain Harness 。**
而真正有价值的 AI Native 软件，可能不是“一个大模型 + 一个聊天框”。
而是：
```text
Model
+
Agent Runtime
+
Domain Harness
+
Capabilities
+
Evaluation
+
Human Interface
```
模型可以不断替换。
真正决定这个系统能不能在一个行业里可靠工作的，很可能是模型外面的这一整层。
---
原文链接：[点击查看](https://www.v2ex.com/t/1234321)
评论
暂无评论。