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 需要：

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

八、一句话总结

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

claude-code-integration-insight.md 9.4 KB Link permanente Histórico Em bruto