Perplexity发布Computer:AI就是计算机

发布时间:2026-02-26 19:19  浏览量:1

今天刷推看到Aravind Srinivas(Perplexity CEO)发了篇长文,宣布他们发布了一个叫"Computer"的产品。

他说了一句很有意思的话:

> AI就是计算机

很多人可能觉得这是营销噱头,但仔细看完后,我认为这是从第一性原理出发的正确判断。

三个关键洞察

1. 单模型无法做到最好

即使是最强的模型,也无法单独完成最好的工作。

Perplexity发现一个事实:随着模型越来越强大,它们在专业化。

- 有的模型擅长推理

- 有的模型擅长写代码

- 有的模型擅长创意写作

Claude最大的弱点,是它只能和Claude协作。

未来的AI系统,必然是多模型协作(orchestration)。

Perplexity这次在后台接了19个模型,根据任务自动路由到最合适的那个。这不是炫技,而是工程化落地的必然选择。

2. 计算机的历史,就是回归本质

400年前,"computer"这个词指的是天文学徒——那些手动计算彗星轨道的人。

后来演变为:

- 机械计算机

- 电子计算机

- 数字计算机

1974年GUI出现,再到智能手机,我们一直在进化。

但核心定义从未改变:computer = 能自主工作的机器*

问题在于,现在的GUI反而成了瓶颈。

我们花大量时间"盯着电脑工作",而不是让"电脑为我们工作"。Scroll、点击、拖拽,这些交互方式正在消耗我们。

AI的进步,正在让计算机回归它的本质。

3. Web是地球的存储系统

Perplexity做了一个很精准的判断:

Web的两大功能:

- WRITE:1990年代博客出现就解决了

- READ:一直靠搜索引擎,从未真正解决

搜索引擎能做索引、匹配,但无法做:

- 深度研究

- 综合分析

- 摘要总结

- 需要行动才能获取的知识

Perplexity用AI解决了READ问题。

当Web成为完整的读写系统,再加上Agent能导航任务,剩下的就是:

- 个性化存储(你的文件)

- 工具集成(你的工具)

这就是Computer产品要做的事情。

---

我的看法

底层逻辑:多模型协作是必然

原因很简单:

1. 单模型想做好所有事 → 不可能

2. 不同模型有不同天赋 → 像团队协作

3. Orchestrator是关键 → 决定用哪个模型

Perplexity的判断是对的。

工程化落地的挑战

但概念正确,不等于执行简单。Perplexity面临几个硬核问题:

1. 路由策略

- 如何准确判断哪个任务用哪个模型?

- 代码任务一定用代码模型吗?如果需要推理呢?

- 多少任务需要串行?多少可以并行?

2. 成本控制

- 19个模型,调用成本怎么控制?

- 用户愿意为多模型协作付多少钱?

- 如何平衡质量和成本?

3. 延迟优化

- 多模型调用,延迟怎么降到可接受?

- 用户能接受等待多久?

- 缓存策略怎么做?

这些都是工程问题,不是PPT能解决的。

Perplexity能做出来,说明他们确实在认真思考"什么是计算机"这个问题。

单模型 vs 多模型

| 维度 | 单模型(如Claude) | 多模型(如Perplexity) |

|------|||

| 优势 | 简单、一致性好 | 灵活、专业化 |

| 劣势 | 无法做到最好 | 复杂、成本高 |

| 适用 | 通用任务 | 复杂工作流 |

| 未来 | ? | ? |

我的判断:短期单模型够用,长期必然是多模型。

---

Perplexity在文章里用了一个很好的比喻:

单模型是独奏乐器,多模型是交响乐团。

指挥家不是某一件乐器,而是整个orchestration系统。

同样的:

- AI不是某一个模型

- AI = Computer

- 计算机 = Orchestration系统

2025年,平均每17天就有一个新frontier模型问世。每一个新模型,就像一个新音乐家走上舞台,加入这个交响乐团。

指挥家举起指挥棒。

计算机开始工作。

---

Perplexity的Computer产品,本质是:

1. 多模型协作- 19个模型后台路由

2. Web作为存储- 完整的读写系统

3. Agent orchestration- 自动任务分解和执行

这不是革命,这是计算机的进化。

Talk is cheap, show me the product.

你觉得多模型协作是未来吗?还是单模型就够用了?

欢迎在评论区讨论。