# Manus深度访谈：通用Agent产品的品味、定力与技术抉择

> **来源**：张小珺商业访谈录 × Manus首席科学家Peak **原文链接**：<https://mp.weixin.qq.com/s/AX6rz5LO1\\_dShqVZa9ecdA> **视频**：<https://www.bilibili.com/video/BV1knvYBDEjs/> **精简整理**：2026-01-26

***

## 📌 核心价值

Peak是我近期听到的最有深度的AI创业者分享。相比很多"模型即产品"的论调，他提供了一个**应用层视角的反叙事**：不训练模型、做通用而非垂直、坚持"纯血Agent"——每一个选择都有清晰的技术逻辑和商业考量。

***

## 一、创业历程与认知演化

### 1.1 手机浏览器创业的教训

**核心洞察**：浏览器市场不适合创业者以颠覆者姿态进入，更适合巨头锦上添花。

历史上只有两次大规模市场份额转变：

* 微软通过预装IE干掉Netscape
* Google在搜索引擎成为老大后推出Chrome

### 1.2 Magi搜索：The Bitter Lesson的真实案例

| 阶段 | 方法           | 结果              |
| -- | ------------ | --------------- |
| 早期 | 人工定义和维护知识图谱  | 成本高、不可扩展        |
| 中期 | NLP"小"模型自动抽取 | 需要持续维护、迭代周期2-3周 |
| 现在 | GPT等通用大模型    | 人类先验越来越少，效果反而更好 |

**关键教训**：同时做模型训练和产品迭代时，产品需要"等"模型，而模型层的创新日新月异，旧架构模型的优势会被快速抹平。

### 1.3 AI浏览器的失败复盘

Manus团队曾花数月开发AI浏览器，最终决定**不发布**。

**踩过的坑**：

| 问题     | 具体表现                              |
| ------ | --------------------------------- |
| 端侧模型幻想 | 3B模型在Apple Silicon上能跑，但与顶级模型差距太大  |
| 场景悖论   | 简单任务价值不大；长程任务需要"占用"电脑很久，用户体验奇怪    |
| 灵魂拷问   | Chrome + Monica插件做不到的是什么？想了很久发现没有 |

**勇敢的决定**：产品一旦发布就需要持续维护，损失更大的机会成本。

### 🔍 批判性观察

**这个"不发布"的决策非常值得学习**：

* 但前提是公司有Monica持续盈利，有足够的安全感做理性决策
* 大多数初创公司没有这个奢侈——容易陷入沉没成本谬误
* **反思**：DeepSeek、豆包的"豪气"背后都有其他业务现金流支撑，不要随便模仿

***

## 二、模型与应用的关系

### 2.1 "模型公司vs应用公司"的伪命题

**Peak的核心观点**：未来很快不会区分模型公司和应用公司。

| 模型厂商      | 应用举措                                |
| --------- | ----------------------------------- |
| OpenAI    | AI搜索、Deep Research、Codex、Atlas、Sora |
| Anthropic | Claude Code                         |
| Google    | NotebookLM、AI Studio                |

| 应用厂商   | 模型举措                        |
| ------ | --------------------------- |
| Cursor | 训练Composer-1模型（80%日常任务极快响应） |

**最佳路径**：先做产品达到PMF，再根据降成本、提速、稳定性等诉求，针对性训练模型。

### 2.2 为什么Manus不训练模型？

| 理由      | 具体说明                                      |
| ------- | ----------------------------------------- |
| 黑盒过程    | 模型训练的可理解性、可控性远不如in-context learning       |
| 迭代太快    | 花一个月训练，外界新模型可能发布好几个了                      |
| 产品变化更快  | Prompt、tool、context都在变，训练的模型可能过拟合旧的产品运作方式 |
| MLOps开销 | 低用量下无法实现推理成本优化                            |

**替代策略**：把优化"外包"给模型原厂——帮助构建evaluation、提feature proposal。

### 🔍 批判性观察

**"不训模型"决策的风险**：

1. **差异化天花板**：如果模型能力是核心壁垒，纯应用层的护城河有多深？
2. **Cursor的反例**：Composer-1证明了应用层训练模型可以找到差异化（80%任务极快响应）
3. **模型厂商的优势**：Claude Code、Codex的亏本套餐策略，应用厂商难以跟进
4. **长期看**：如果模型厂商持续补贴+垂直整合，纯应用层生存空间会被压缩

**但Peak的反驳也有道理**：Manus可以用所有模型，综合体验更好；应用层积累的用户轨迹数据是模型厂商缺乏的。

***

## 三、为什么做通用Agent？

### 3.1 技术层面的思考

**传统观点**：创业要找垂直领域切入，先PMF再拓展。

**Peak的反论**：

| 维度      | 通用Agent         | 垂直Agent        |
| ------- | --------------- | -------------- |
| 底层技术    | 通用大模型 + 图灵完备虚拟机 | 在通用底层上加约束      |
| 优化空间    | 原子能力增强可同步增强所有场景 | 只能一个场景一个场景单独优化 |
| 长尾需求    | 自然满足            | 需要不断扩展产品线      |
| Context | 跨任务流转、记忆共享      | 不同任务间隔离        |

**网络效应**：工具之间的组合效应——做Deep Research → 构建网页 → 分析流量 → 写PPT发给投资人。

### 3.2 用户视角的思考

**垂直Agent的困境**：

| 用户类型 | 问题                      |
| ---- | ----------------------- |
| 专业用户 | 长尾需求无法满足，需要切换多个工具       |
| 普通用户 | 低频场景（如旅行规划）使用频率低，难以形成付费 |

**剪辑软件的例子**：

* 给专业剪辑师做Agent → 对产出有极高要求，一个环节不好就是0分（乘法关系）
* 给有剪辑需求的非专业用户做Agent → 带来净增益（加法关系）

**核心结论**：Agent不要以替换人的思路做，要以提升人的思路做。

### 🔍 批判性观察

**"通用优于垂直"的论证是否充分？**

**支持点**：

* 技术架构的确更优雅，避免了重复建设
* 长尾需求的确是真实痛点
* Context共享的价值被低估

**质疑点**：

1. **PMF难度**：通用意味着什么都做，什么都做不精——产品如何定义核心价值主张？
2. **竞争壁垒**：ChatGPT、Gemini等都是通用的，Manus的差异化是什么？
3. **商业模式**：高价值任务的用户规模有多大？能否支撑公司发展？
4. **实际反例**：Cursor专注coding这个"垂直"场景，反而做得很好

**可能的调和**：Manus的"通用"实际上是"prosumer的通用"——比ChatGPT更强大，比专业工具更易用的中间地带。

***

## 四、"纯血Agent"理念

### 4.1 定义

**纯血Agent**：完成任务的所有过程和方式由智能本身决定，没有人为约束。

**对比**：Agentic Workflow = 以规则主导 ≠ Agent = 以智能主导

### 4.2 数据可视化的例子

| 方法          | 实现方式                       | 问题                      |
| ----------- | -------------------------- | ----------------------- |
| **传统方法**    | 写一大堆Prompt约束（坐标轴设置、标题不遮挡等） | 规则太多互相冲突、指令遵循变差、debug困难 |
| **纯血Agent** | 加入"看图"能力，让Agent自己检查和修复     | 解决的不是一个问题，而是一类问题        |

**核心原理**：从"打地鼠式堵漏洞"变成"让智能的泛化性帮你解决更多未发现的问题"。

### 4.3 The Bitter Lesson的应用

> 用通用的方法，投入更大的算力去解决问题，而不是加入更多的人为的知识。

**实践中的观察**：给Agent写非常细节和具体的Prompt、设计垂直工具/DSL、按人类组织形式设计多Agent架构——都会限制Agent的主动探索空间，导致效果不理想。

### 🔍 批判性观察

**"纯血Agent"的现实可行性**：

**支持点**：

* 理论上非常优雅，符合长期趋势
* 避免了规则工程的复杂度爆炸
* 泛化能力更强

**质疑点**：

1. **当前模型能力**：模型真的能自主发现所有问题吗？Peak自己也承认模型在agentic任务上表现不好
2. **可复现性**：Agentic Workflow的可复现性更好（Peak也承认这点）
3. **成本问题**：纯智能驱动意味着更多的推理Token消耗
4. **企业场景**：To B客户能接受"不确定性"吗？

**可能的平衡点**：核心流程用"纯血Agent"，关键检查点加入规则约束——类似自动驾驶的L2+而非L4。

***

## 五、Context Engineering实践

### 5.1 Token消耗特征

| 应用类型    | 输入:输出比          | 相对消耗   |
| ------- | --------------- | ------ |
| Chatbot | 3:1             | 1x     |
| Agent   | 100:1 \~ 1000:1 | 几十到上百倍 |

### 5.2 模型层的核心问题

| 问题                      | 具体表现                      |
| ----------------------- | ------------------------- |
| Chatbot alignment       | 模型倾向于一轮交互完成回答，不适合ReAct多步骤 |
| Context pressure        | 上下文变长后输出质量下降、提前结束概率增加     |
| 缺乏compression awareness | 模型不知道可以把信息offload到文件系统再取回 |

### 5.3 Peak的独特观点

> 200K以上的context不重要了，更重要的是让模型具备compression awareness。

**理想状态**：

* 模型能意识到context很长，主动offload信息到文件系统
* 在需要时触发compression，忘掉不需要的细节
* 但模型要知道信息是被压缩了，而非凭空消失

**当前workaround**：压缩总结后保留最近几轮工具调用，实现"平滑过渡"。

### 5.4 Reasoning模型的问题

**观察**：直接把竞赛编程的reasoning model用于agent场景，效果反而下降。

| 场景          | 思考内容                  |
| ----------- | --------------------- |
| 数学竞赛        | 复杂逻辑推演、公式推导           |
| Agent ReAct | 之前做了什么、观察到什么、下一步应该做什么 |

**实践方案**：ReAct主模型用non-thinking mode，给一个`think tool`或深度思考sub-agent处理真正复杂的问题。

### 🔍 批判性观察

**Context Engineering vs 模型训练的权衡**：

* Peak的观点偏向应用层优化（context engineering）
* 但模型厂商正在训练更适合Agent的模型
* **关键问题**：应用层的优化会被模型内化吗？（杨植麟认为会，Peak认为不会）

***

## 六、数据飞轮与Evaluation

### 6.1 Agent场景的数据优势

| 维度   | Chatbot     | Agent         |
| ---- | ----------- | ------------- |
| 用户反馈 | 重试、修改Prompt | 自然语言反馈、直接接管修改 |
| 数据价值 | 低           | 高（轨迹数据+修正信号）  |

### 6.2 Self-Evolving机制

| 层次  | 方法                           | 效果      |
| --- | ---------------------------- | ------- |
| 个体层 | User Memory挖掘和使用             | 个性化提升   |
| 群体层 | 总结通用failure pattern，变成系统原生能力 | 整体失败率降低 |

### 6.3 Evaluation团队配置

* 不到10人的evaluation团队负责系统搭建
* 产品团队有junior同学负责主观evaluation
* 总计10多人——**Vibe还是很重要的**

### 6.4 关注的核心指标

1. Coding能力
2. GUI理解能力（browser use）
3. 广义tool call能力（命令行、SDK/API）
4. 美学性
5. 错误自我意识和修正能力

### 🔍 批判性观察

**Evaluation驱动的产品方向**：

> "品味体现在公司内部的evaluation/benchmark上"

这与OpenAI研究员分享的"Lead花很多时间写eval"一致。**Evaluation定义了产品的方向**——这可能是最被低估的产品能力。

***

## 七、技术决策复盘

### 7.1 重要的下注

| 下注          | 具体内容                             | 结果 |
| ----------- | -------------------------------- | -- |
| 通用Agent能做出来 | 开创品类                             | ✅  |
| 不训练模型       | 相信模型能力提升，重心放在context engineering | ✅  |
| 面向prosumer  | 不做中国版Cursor                      | ✅  |

### 7.2 正确的保守决策

**对MCP的态度**：业界都很嗨，但Manus很保守。

| 问题             | 影响           |
| -------------- | ------------ |
| 污染action space | 工具太多影响模型选择质量 |
| 缓存命中率下降        | 成本上升         |

**替代方案**：MCP的code mode——在代码层面调用，而不是原生tool call层面。

### 7.3 后悔的决策

> 一开始有点太盲信小模型了，参数量还是重要的。

**AK的观点**：大模型很多参数在做事实性记忆，能否分离出去只保留"认知核心"？

**实际情况**：很难分离什么是知识、什么是泛化的认知能力。大参数量还是有用的。

***

## 八、Agent分类与设计

### 8.1 Peak对MultiAgent的批评

> 模型跟人一点都不像，不应该把Agent跟人的思维体系强行对齐。

**反对**：设计师、程序员、产品经理、测试工程师的分工——Agent是"全能"的，这种分法带来context传递问题。

**建议**：只能按输入输出角度分类。

### 8.2 实践中的Agent切分原则

从**Context管理**角度考虑：

| 场景     | 切分方式               | 原因              |
| ------ | ------------------ | --------------- |
| 搜索问答   | 搜索Agent + 回答Agent  | 避免网页信息挤占context |
| Coding | 代码阅读Agent + 主Agent | 精炼信息返回主流程       |

### 8.3 Manus的Agent架构

* 通用执行Agent（核心流程）
* Planner Agent（管理todo）
* Knowledge Management Agent（用户反馈知识挖掘）

***

## 九、商业与竞争

### 9.1 三类典型用户

1. 互联网/技术公司白领（非程序员）
2. Freelancer / Sole Proprietor
3. 金融和咨询行业（高价值任务）

### 9.2 与模型厂商的竞合

**Manus的防御点**：

* 可以用所有模型，综合体验更好
* 模型厂商做垂直整合，迭代速度不如Manus
* 用户轨迹和feedback数据留存在应用层

**与OpenAI的关系**：

> Manus会长期专注为高价值需求的用户提供最好的AI，而不是跟ChatGPT抢最广的底层用户群。

### 9.3 Cursor vs Claude Code

**Cursor的优势空间**：

* Claude Code只能用Claude模型
* Cursor可以引入Gemini 3（静态前端美学领先），做到更好的综合效果

### 9.4 为什么不做中国市场？

* 海外用户付费意愿更强
* 国内很难收到钱
* Agent的Token开销巨大，难以持续补贴

***

## 十、关键洞察总结

### 10.1 技术层面

| 洞察            | 说明                                        |
| ------------- | ----------------------------------------- |
| 模型与应用边界模糊     | 头部公司都在两边做                                 |
| Scaling Law未死 | 狭义的loss降低有效，广义的新能力涌现存疑                    |
| Context > 参数  | 200K以上context不重要，compression awareness更重要 |
| Reasoning需分场景 | 竞赛reasoning ≠ Agent reasoning             |

### 10.2 产品层面

| 洞察              | 说明                     |
| --------------- | ---------------------- |
| 品味 = Evaluation | 内部benchmark决定产品方向      |
| "不做什么"更重要       | AI时代产能放大，每增加一个功能都在稀释其他 |
| 通用 > 垂直（存疑）     | 技术架构优雅，但PMF和壁垒待验证      |
| 纯血Agent         | 长期正确，短期需要平衡            |

### 10.3 组织层面

| 洞察        | 说明                                    |
| --------- | ------------------------------------- |
| G-P-A决策框架 | Goal专制、Priority专制+民主、Alternatives充分民主 |
| 技术一票否决权   | 但技术服务于产品                              |
| 勇于不发布     | 需要有其他业务支撑安全感                          |

***

## 🔗 相关阅读

本库相关文章：

* `[2026-01-26] # 🗺️ 大模型应用技术演进全景：RAG、MCP、Agent的三条主线与批判性观察.md`
* `[2026-01-26] # 🛠️ Vibe Engineering 2026实践指南：Ed Huang的多Agent协同工作流与批判性观察.md`
* `[2025-01-01] # 🔌 MCP生态全景调研：协议、框架与实现全景图.md`

外部参考：

* [Building Effective AI Agents - Anthropic](https://www.anthropic.com/engineering/building-effective-agents)
* [Manus Blog](https://manus.im/blog)
* [LangChain × Manus Context Engineering分享](https://zhuanlan.zhihu.com/p/1952384444662022396)