图工程（2026）与 FIM One
业界讨论中常见一种转变——从循环工程（单个智能体反复思考和行动）转向图工程（将多节点拓扑作为显式工程对象）。这个标签很新，但实践由来已久。LangGraph 风格的系统和多智能体组织已经使用图多年了。对 FIM One 而言，重要的是人们所说的是哪种图，以及它如何映射到我们的三个执行层。图表工程通常意味着什么
该框架的共识：图表不替代循环。图表设计流程之间的关系；每个智能体节点仍可能运行完整的循环。
“图表”在实践中含义重载。三种用法混在一起：
本页面讨论前两种（编排）。
不是”换了个名字的 Dify Workflow”
Dify 风格的可视化工作流和图工程共享血缘关系（显式拓扑），但它们不是同一个产品。
简短形式：经典工作流是确定性（或半确定性）管道，偶尔有 LLM 步骤。图工程是多节点系统拓扑，其中关键位置仍然可以是自主智能体。
FIM One上的行业地图如何定位
FIM One已经跨越整个控制谱；聊天”规划器模式”只是其中一个切片。图形工程 vs FIM One DAG（聊天规划器）
同一家族（显式多步拓扑）。不同物种。
含义： 围绕图形工程的行业热度验证了保留图形/调度引擎的必要性。它不要求聊天默认强制用户为每个回合选择”规划器”。大多数任务仍然需要强大的循环；图形在并行分支、固定合规路径和多角色编排上发挥作用。
FIM One 可以学习的内容（赋能 ReAct、DAG、Workflow）
具体收获，而非口号。按影响力排序。
“做图”时要避免的反模式：
- 使用依赖图模拟人工状态机（多步”等待答案”但无等待原语）。
- 将 ReAct
update_plan（检查清单记忆）与图工程（调度拓扑）混为一谈。 - 将图热作为第二个聊天个性而非引擎组合（外层循环，需要时内层调度）。
- 将 FIM One DAG 步骤描述为”浅层 LLM 调用”：这低估了引擎并误导产品决策。
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 与 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 步骤已经是完整的 ReAct 智能体 — 第 3 层不是愿景。每个步骤都运行带有工具和多迭代循环的
agent.run()；与顶层 ReAct 聊天轮次的差异是有意的（无每步计划板、无聊天级ask_user_question等待、由model_hint/ 通用默认值选择模型）。
结构化输出降级
DAG管道中所有结构化LLM调用位置（Planner、Analyzer、Tool Selection）都使用统一的structured_llm_call()工具，该工具实现了3级降级链：
每个基于文本的级别在降级到下一级之前会使用重新格式化提示重试一次。结果是一个
StructuredCallResult，包含解析的值、成功的提取级别以及累积的token使用情况。
这种设计意味着同一个提示可以跨GPT-4（native FC）、Claude（JSON mode）和本地模型（纯文本）可靠地工作，在一个位置而不是分散在四个调用位置中实现一致的错误处理和重试逻辑。
三个执行层：控制谱
上述五种规划方法描述了整个格局。在FIM One内部，三个执行层提供了一个控制谱，从完全的人工控制到完全的AI自主。相对于图工程：Workflow是设计时图产品；DAGPlanner是运行时任务图；ReAct是循环工程（带可选的计划板内存，不是调度图）。
设计原则：给用户恰好他们想要的控制量。
- 需要证明每笔贷款审批都通过五个特定步骤？→ Workflow。
- 需要并行研究三个主题然后综合？→ DAG。
- 需要在运行中草拟、优化或提出结构化问题？→ ReAct。
- 不确定？→
execution_mode: "auto"在运行时对查询进行分类并路由到DAG或ReAct（当目标主要是澄清或短期探索时优先选择ReAct）。
- Dify强调Workflow层（静态或半静态可视化图）。
- LangGraph强调代码级控制流图DSL（开发者定义的拓扑、动态路由、检查点）。在结构上与可视化工作流相关，以软件形式表达。
- Manus级智能体强调Agent/循环层（自主执行、用户定义的结构很少）。
相关文档
- ReAct Engine — 循环、工具、计划板、澄清问题
- DAG Engine — 规划器、执行器、分析器、重新规划
- Competitive Landscape — Dify / Manus / Coze 定位