# Claude Code 视角：为什么混合架构是最优解

> **来源**: Claude Code 在深度了解 lambdagentpaas 架构后的自我分析。
> **核心结论**: Claude Code 最适合做"想"（规划/理解/判断），lambdagentpaas 最适合做"做"（执行/积累/保障）。两者结合优于任何一方单独使用。

---

## 一、Claude Code 子智能体方案的优势

Claude Code 的 subagent 系统是硬编码在运行时里的，不需要编译、配置文件或额外基础设施。直接在内存里 fork 子进程，给一段 prompt 和一组工具，跑完返回结果。

```
Claude Code 做法：
  用户: "重构这个模块"
  → 脑内规划 5 个步骤
  → 逐步调用 Read/Edit/Bash
  → 完成

不需要 YAML，不需要编译，不需要 PaaS。
```

对于**单次会话内的临时任务**，这是最优解——零配置、零部署、即用即走。

---

## 二、Claude Code 方案的三个致命缺陷

### 缺陷 1：知识不积累

每次会话结束，所有理解都丢失。下次用户问同样的代码库，从头读文件、从头理解。

**lambdagentpaas 的解决方案**：LLM Wiki 模式——知识编译一次，持续积累。Claude Code 每次都在重新发明轮子，wiki 只发明一次。

### 缺陷 2：子任务不可复用

Claude Code 为"重构认证模块"制定的计划，下次遇到类似任务时完全用不上。规划是一次性的，存在对话上下文里，会话结束就消失。

**lambdagentpaas 的解决方案**：Skill + Pattern 系统——`review_pattern(coder, reviewer)` 定义一次，所有项目复用。

### 缺陷 3：没有静态安全网

Claude Code 跑子任务时：
- 死循环只能等超时
- 花了太多 token 事后才知道
- 两个并行子任务写同一个文件靠运气

**lambdagentpaas 的解决方案**：
- 类型检查 (T-Compose) 在编译时发现组合错误
- 成本预测 (分级类型) 在执行前给出上界
- 并行安全 (store independence) 在编译时验证
- CEK 引擎在每步 Yield 点检查成本/循环

---

## 三、两套方案的能力对比

| 能力 | Claude Code | lambdagentpaas | 谁更适合 |
|------|------------|---------------|---------|
| 理解模糊需求 | 强 | 弱（需要明确配置） | **Claude Code** |
| 动态规划 | 强（实时调整） | 弱（预定义 Pattern） | **Claude Code** |
| 与用户实时对话 | 强 | 弱 | **Claude Code** |
| 强推理 | 强 (Opus/Sonnet) | 取决于本地模型 | **Claude Code** |
| 知识积累 | 无（会话级） | 强（wiki 持久化） | **lambdagentpaas** |
| 任务复用 | 无 | 强（Skill + Pattern） | **lambdagentpaas** |
| 静态安全检查 | 无 | 强（lint + type + cost） | **lambdagentpaas** |
| 执行成本 | 高（每步 API 调用） | 低（本地模型可 $0） | **lambdagentpaas** |
| 暂停/恢复 | 无 | 强（CEK 状态序列化） | **lambdagentpaas** |
| 可审计性 | 弱（黑箱推理） | 强（CEK trace + wiki 页面） | **lambdagentpaas** |
| 可浏览性 | 无 | 强（Markdown wiki + Obsidian） | **lambdagentpaas** |
| 并行执行 | 有（subagent 并行） | 有（AsyncPar + 汇合定理证明） | **lambdagentpaas** |
| 形式化保证 | 无 | 有（λA 类型安全 + 终止性定理） | **lambdagentpaas** |

---

## 四、混合架构：最优解

不是二选一，而是**Claude Code 做前端，lambdagentpaas 做后端**。

```
┌────────────────────────────────────────┐
│         Claude Code (前端/规划层)        │
│                                         │
│  擅长:                                   │
│  ✓ 理解用户自然语言需求                    │
│  ✓ 动态规划（根据上一步结果调整）           │
│  ✓ 与用户实时交互和确认                    │
│  ✓ 处理从未见过的新任务类型                 │
│  ✓ 判断何时用 Skill/Pattern，何时即兴发挥   │
│                                         │
│  不擅长:                                  │
│  ✗ 知识积累（会话结束就忘）                 │
│  ✗ 任务复用（每次重新规划）                 │
│  ✗ 成本控制（每步都花钱）                   │
│  ✗ 静态安全检查（只有试错）                 │
└──────────────┬─────────────────────────┘
               │ MCP 工具调用
               ▼
┌────────────────────────────────────────┐
│      lambdagentpaas (后端/执行层)        │
│                                         │
│  擅长:                                   │
│  ✓ 知识积累（LLM Wiki 持续编译）           │
│  ✓ 任务复用（Skill + Pattern 库）          │
│  ✓ 成本控制（分级类型 + CEK 熔断）          │
│  ✓ 静态安全（lint + T-Compose + store）    │
│  ✓ 本地执行（Ollama/Qwen $0）             │
│  ✓ 可审计（CEK trace + wiki 页面）         │
│                                         │
│  不擅长:                                  │
│  ✗ 理解模糊需求（需要明确配置）              │
│  ✗ 动态调整（预定义流程）                   │
│  ✗ 处理全新任务类型（需要先定义 Skill）       │
└────────────────────────────────────────┘
```

### 混合的具体工作方式

**场景 1: 新项目首次分析**

```
用户: "帮我了解这个代码仓库"

Claude Code (规划):
  1. 判断: 这是"理解新代码库"任务
  2. 检查 lambdagentpaas 是否有相关 wiki → 没有
  3. 决定: 先用 WikiIngest 建立知识库
  4. 调用 MCP: WikiIngest(path="/project/src")
     → lambdagentpaas 本地 LLM 阅读所有文件 → 写 wiki 页面 ($0)
  5. 调用 MCP: WikiQuery("项目整体架构是什么？")
     → lambdagentpaas 读 wiki 页面 → 回答 ($0)
  6. Claude Code 综合 wiki 回答，加上自己的理解，回复用户

Claude Code 花费: $0.03 (1 次规划)
lambdagentpaas 花费: $0 (本地 LLM)
总计: $0.03
如果纯 Claude Code: $0.50+ (读每个文件都要 API 调用)
```

**场景 2: 日常开发**

```
用户: "认证模块用的什么加密算法？"

Claude Code:
  1. 判断: 这是知识库已有的问题
  2. 调用 MCP: WikiQuery("认证加密算法")
     → lambdagentpaas 读 wiki/entities/jwt.md → 直接回答 ($0)
  3. Claude Code 转述给用户

花费: $0.01 (Claude Code 转述) + $0 (lambdagentpaas) = $0.01
```

**场景 3: 从未见过的新任务**

```
用户: "帮我把这个 Flask 项目改成 FastAPI"

Claude Code:
  1. 判断: 这是复杂重构任务，lambdagentpaas 没有现成 Skill
  2. 决定: 自己直接做（动态规划 + 即时执行）
  3. 读代码 → 规划步骤 → 逐文件修改 → 跑测试
  4. 完成后，通知 lambdagentpaas 更新 wiki:
     WikiIngest(path="/project/src")  # 重新编译知识

花费: $0.40 (Claude Code 执行) + $0 (wiki 更新)
下次类似任务: Claude Code 可以先看 wiki 里的重构记录
```

---

## 五、任务分类决策树

```
收到任务
  │
  ├── 是否有 lambdagentpaas wiki 覆盖？
  │     ├── 是 → WikiQuery 回答 (lambdagentpaas, $0)
  │     └── 否 → 继续判断
  │
  ├── 是否有现成 Skill/Pattern？
  │     ├── 是 → 组合 Skill + Pattern 执行 (lambdagentpaas, $0)
  │     └── 否 → 继续判断
  │
  ├── 是否是确定性重复任务？
  │     ├── 是 → Claude Code 规划 → 生成 Skill → lambdagentpaas 执行
  │     └── 否 → 继续判断
  │
  ├── 是否需要强推理？
  │     ├── 是 → Claude Code 直接做
  │     └── 否 → lambdagentpaas 本地模型做
  │
  └── 兜底 → Claude Code 直接做 → 完成后更新 wiki
```

---

## 六、成本对比

以一个中等规模项目（50 个文件）的日常开发为例：

| 操作 | 纯 Claude Code | 混合模式 | 节省 |
|------|---------------|---------|------|
| 首次理解代码库 | $1.50 (读 50 文件) | $0.03 (规划) + $0 (wiki 编译) | **97%** |
| 每次简单问答 | $0.03 | $0.01 + $0 | **67%** |
| 复杂分析 | $0.15 | $0.03 + $0 | **80%** |
| 100 次日常问答 | $3.00 | $1.00 + $0 | **67%** |
| 月度总计 (估算) | ~$50 | ~$5 | **90%** |

---

## 七、对 lambdagentpaas 的建议

要让这个混合架构真正落地，lambdagentpaas 需要：

1. **MCP Server 足够稳定** — Claude Code 调用 WikiIngest/WikiQuery 时不能卡住或崩溃
2. **首次使用零配置** — 一行 MCP 配置就能接入，不要求用户理解 λA 理论
3. **Wiki 路径自动管理** — 每个项目自动使用 `.lambdagent/wiki/` 目录
4. **降级优雅** — 本地 LLM 不可用时降级为纯文本索引（不崩溃）
5. **增量 Ingest 快** — 修改一个文件后重新 Ingest 应该只更新变化的部分

---

## 八、一句话总结

**Claude Code 是厨师（懂创意、能应变），lambdagentpaas 是厨房（有工具、有食谱、有库存）。** 最好的餐厅不是让厨师自己磨刀种菜，而是让厨师专注做菜，厨房负责一切后勤。混合架构就是这个道理——Claude Code 专注理解和规划，lambdagentpaas 专注执行和积累。