GenSpark vs Manus 架构深度分析
一、GenSpark — Mixture-of-Agents（MoA）
核心理念： 不信任单一模型，用"集团军"作战。
架构层
用户输入↓
[路由层] — 任务分析 + 模型选择↓
[Mixture-of-Agents 引擎]├── GPT-4 / GPT-4 Turbo (OpenAI)├── Claude 3 Opus / 3.5 Sonnet (Anthropic)├── Gemini Pro / Ultra (Google)├── Llama 3 (Meta)└── 其他专用模型... (共 9→30+ 个)↓
[工具层] — 80+ 工具├── Web Crawler / 搜索引擎├── Code Interpreter├── 图片/视频生成├── 语音合成├── Slides / Sheets / Docs 生成└── Phone Agent（真的能打电话）↓
[聚合层] — 多模型结果融合 + 事实校验↓
输出（Sparkpage / 文件 / 媒体）技术特点
| 维度 | 细节 |
|---|---|
| 模型路由 | 按任务复杂度、速度、精度需求，智能分发到最合适的模型 |
| 多模型协作 | 不是投票，是流水线——一个模型做初稿，另一个做事实核查，第三个做润色 |
| 工具集成 | 80+ 自有工具，不依赖外部 API，全部自研封装 |
| 数据集 | 10+ 自有策展数据集，用于事实校验和搜索增强 |
| 输出形态 | "Sparkpage"——结构化可视化页面，不是纯文本 |
设计哲学
GenSpark 的赌注是**"没有一个模型是万能的"**。它本质上是一个 AI 编排平台，自己不做模型，专注做"调度+工具+融合"。类似于不自己养兵，但擅长排兵布阵。
二、Manus — Context Engineering（上下文工程）
核心理念： 模型够强了，关键是怎么喂上下文。
架构层
用户输入↓
[Context Engine] — 构建最优上下文├── System Prompt（精心设计的指令）├── 历史压缩（todo-list 而非全文）├── 工具结果摘要└── 文件系统状态↓
[状态机] — 上下文感知的工具选择├── State A: 只暴露搜索/浏览工具├── State B: 只暴露代码/文件工具└── State C: 只暴露输出/交付工具↓
[沙箱 VM] — 每个任务独立虚拟机├── 浏览器（可视化操作网页）├── Shell（执行代码）└── 文件系统（持久化中间结果）↓
[KV-Cache 优化层] ← #1 指标├── System prompt 前缀固定 → 100% cache hit├── 历史只追加不修改 → 保持 prefix 一致└── 工具结果放末尾，不插中间↓
模型推理（frontier model，如 Claude）↓
Action → Observation → 追加到 Context → 循环核心技术细节
1. KV-Cache 命中率 = 第一指标
这是 Manus 最独到的洞察。KV-Cache 是 LLM 推理时的"记忆缓存"——如果你每次请求的前缀不变，模型可以跳过那部分的计算，直接复用缓存。
请求1: [System Prompt][History 1-5][New Action]
请求2: [System Prompt][History 1-5][Action 6][New Action]↑ 前缀完全一致，cache hit!Manus 的所有架构决策都围绕这个：
- 永远只追加，不修改历史
- System prompt 固定在最前面
- 工具结果摘要放末尾
- 目标：cache hit rate > 90%，直接降低 50%+ 的推理成本和延迟
2. 文件系统 = 终极上下文
Manus 不把所有信息塞进 prompt（context window 有限），而是用文件系统当"外部记忆"：
把中间结果写文件 → 下一步只告诉模型"文件在 /tmp/analysis.md"
→ 模型需要时再 cat 读取
→ context 保持精简这比 RAG（检索增强生成）更优雅——文件系统天然支持增删改查，模型已经"会用"它。
3. 状态机控制工具可见性
不是把 80 个工具全丢给模型（那样模型会选错），而是根据任务阶段动态暴露：
研究阶段 → 只能用 search, browse, read
编码阶段 → 只能用 shell, write_file, run
交付阶段 → 只能用 create_artifact, send用 system prompt 里的指令实现，不需要修改 logits，简单但有效。
4. 不做 fine-tuning
Manus 选择完全依赖 frontier model 的 in-context learning 能力，好处是：
- 换模型零成本（Claude → GPT → Gemini，随时切）
- 迭代速度极快（改 prompt 即改行为，不用重训）
- 但代价是对 context engineering 要求极高
三、核心对比
| 维度 | GenSpark | Manus |
|---|---|---|
| 核心理念 | 多模型协作，没有万能模型 | 单模型+极致上下文，模型已够强 |
| 模型策略 | 30+ 模型路由 | Frontier model（Claude/GPT），不 fine-tune |
| #1 指标 | 任务完成质量 | KV-Cache 命中率 |
| 工具数量 | 80+ 自研 | 精简，按状态机动态暴露 |
| 执行环境 | 云端服务集群 | 每任务独立 VM 沙箱 |
| 记忆方式 | 多数据集 + 搜索增强 | 文件系统当外部记忆 |
| 成本控制 | 靠模型路由（简单任务用小模型） | 靠 KV-Cache（复用计算） |
| 可解释性 | 低（多模型融合是黑盒） | 高（所有中间步骤可见、可审计） |
| 迭代速度 | 慢（要调路由+每个模型的 prompt） | 快（改一个 system prompt 就行） |
| 被收购 | 独立运营 | 2025/12 被 Meta 收购 |
四、我的判断
GenSpark 适合"结果导向"的场景——你不关心过程，只要最终产出好。它像一个全能秘书团队，每个人有专长，组合出击。但黑盒程度高，出错了很难 debug。
Manus 适合"过程可控"的场景——你需要理解 agent 在做什么、为什么这样做。它的架构更优雅、更工程化，KV-Cache 优化思路对整个行业都有启发。被 Meta 收购后可能会深度整合到 Llama 生态。
从架构品味来说，Manus 更有技术深度。GenSpark 更像是工程集成的胜利——把市面上最好的模型和工具拼在一起，靠"力大飞砖"取胜。Manus 则是在一个看似简单的框架里做到了极致优化，更接近"少即是多"的哲学。