AI 工具生态中的五种”规划”
“规划”这个词被过度使用了。目前至少存在五种不同的方法，它们解决不同的问题：
前两种是设计时规划——它们在工作开始前生成规划，由人类（或模型本身）逐步执行。后三种引入了运行时规划——执行图由程序生成和调度，独立分支并行运行。区别在于谁执行：Claude Code Teams 生成自主智能体；FIM One DAG 在单个编排器内调度步骤。
这些方法不是竞争关系，而是互补层。Kiro 风格的规范可以定义构建什么，而 FIM One DAG 可以调度如何并发执行子任务。Claude Code 的规划模式确保人工同意该方法；FIM One 的 PlanAnalyzer 自动验证结果。
三层嵌套：全功能架构
Claude Code Teams 和 FIM One DAG 在全容量下都展现出三层嵌套架构：- 第 1 层 — 人工审核门：用户审查计划并在执行开始前批准。
- 第 2 层 — DAG 编排：批准的计划被分解为具有依赖边的任务。独立任务并行运行；下游任务等待其阻塞者解决。
- 第 3 层 — ReAct 内循环：每个任务由运行完整 ReAct 循环（感知 → 推理 → 行动 → 观察）的智能体执行，能够进行多步推理、工具使用和自主重试。
全功能运行时：FIM One vs Claude Code Teams
两者都是真正的智能体——核心循环相同：感知 → 推理 → 行动 → 反馈。区别在于它们如何在满负荷下编排并行工作。真实基准：v0.5 RAG 系统
Claude Code Teams 在单个会话中构建了 FIM One 的整个 v0.5 RAG 子系统：- 8 个阶段：嵌入 → 重排序器 → 加载器 → 分块 → 向量存储 → 检索 → 知识库后端 → 前端 + 文档
- 46 个测试通过，前端构建清晰
- 实际耗时：约 5 分钟
- 令牌成本：每个智能体任务约 100k 令牌 × 8+ 个任务 ≈ 800k+ 总令牌
- 依赖边：第 5 阶段依赖第 4 阶段 + 1b；第 6 阶段依赖第 5 阶段 + 2 + 3 — 一个真正的 DAG
汇聚而非竞争
“团队协作”和”管道调度”之间的界限正在模糊：- Claude Code Teams 的
blockedBy/blocks本质上是一个 DAG — 任务具有显式的依赖边，领导者在前置任务完成时分派新解锁的任务。这是拓扑调度加上额外步骤（消息）。 - FIM One 的 DAG 可以受益于智能体自主性 — 与其每个步骤进行单次 LLM 调用，不如让每个步骤运行完整的 ReAct 循环来更好地处理复杂的子任务。
结构化输出降级
DAG 管道中的所有结构化 LLM 调用点（规划器、分析器、工具选择）都使用统一的structured_llm_call() 实用程序，该程序实现了 3 级降级链：
每个基于文本的级别在降级到下一个级别之前使用重新格式化提示重试一次。结果是包含解析值、成功的提取级别和累积令牌使用情况的
StructuredCallResult。
这种设计意味着相同的提示可以可靠地跨 GPT-4（原生 FC）、Claude（JSON 模式）和本地模型（纯文本）工作，在一个位置而不是分散在四个调用点中具有一致的错误处理和重试逻辑。
三个执行层：控制谱
上述五种规划方法描述了整个景观。在 FIM One 内部，三个执行层提供了一个控制谱 — 从完全的人工控制到完全的 AI 自主：
设计原则：给用户恰好他们想要的控制程度。
- 需要证明每笔贷款批准都通过五个特定步骤？ → 工作流。
- 需要并行研究三个主题然后综合？ → DAG。
- 需要草稿和优化直到满意？ → 智能体。
- 不确定？ →
execution_mode: "auto"让 LLM 在运行时对查询进行分类并路由到 DAG 或 ReAct。
- Dify 仅提供工作流层（静态可视化 DAG）。
- LangGraph 仅提供代码级图 DSL（开发者定义的拓扑、动态路由 — 结构上等同于可视化工作流但需要 Python）。
- Manus 仅提供智能体层（自主执行、无用户定义的结构）。