别再被AI瞎跑了！Hanflow用一份YAML把智能体”焊死”在你的管控里

你有没有这种经历：让AI Agent去干个活，它跑着跑着就”自由发挥”了——步骤乱跳、调用乱来、最后给你一份根本不能用的东西。动态Agent很聪明，但太”野”；静态工作流很稳，但太”死”。

8月11日，一个叫 Hanflow（Harmony AI Nexus） 的开源项目火了。它基于 LangGraph 构建，用一份 YAML 把”静态流程、动态Agent、混合编排”全收编了，还把隐私路由、RAG、人机审批、全链路可观测当成”一等公民”。一句话：让智能体既能自己思考，又永远在你手心里。

第一章为什么你需要一个”高可控”的Agent框架

先泼盆冷水。现在市面上的AI编排，基本是两条死路：

纯动态Agent：聪明、灵活，但可控性差、容易幻觉，生产环境一上量就翻车。
纯静态工作流：稳、可复现，但像个提线木偶，开放性任务直接傻眼。

真实业务里，你要的常常是：”这条主干必须按SOP走，但某个分支让AI自己判断”。Hanflow 不让你二选一，它在同一套 YAML DSL 下同时支持三种形态，编译成 LangGraph StateGraph 执行，全程不用切模式。这就像混动汽车——能纯电、能纯油、也能混着跑。

第二章 Hanflow是什么：混动架构，一套DSL三种编排

Hanflow 的官方定位很巧：它是”融合型AI编排框架”，把工作流引擎的稳定和自主Agent的灵活揉在一起。核心卖点就一句——声明式 YAML 是系统唯一的真相来源。

同一份语法，能表达三种编排形态：

纯静态工作流：编译期校验的 DAG，确定性强，适合合规审计、SOP 标准化。
纯动态 Agent：Coordinator 协调多 Agent，按需规划，适合探索性研究。
混合编排：静态节点内嵌动态子图，递归组合，既有确定性骨架又有动态决策。

而且 DSL 原生支持 depends_on、condition、retry、按节点的错误处理策略。你写的不是”提示词”，是可以进 Git、可以代码评审的工程资产。

第三章一分钟看懂六层架构

别被”六层”吓到，记住三件事就行：

L1 交付层：CLI / Web Studio / Python SDK 三种入口，爱用哪个用哪个。
L2 编排层：YAML DSL 编译成 LangGraph StateGraph，13类原语节点管控制流、能力调用和状态。
L4 基础层：ModelRouter（含隐私路由）、MCPBus（统一工具访问）、多后端 RAG 检索。

最值得说的是 L5 持久化层：Checkpoint / Session / Artifact 三级存储，支持崩溃恢复和时间旅行回放。意思是——Agent跑到一半崩了，你能从断点续上，还能回看每一步它到底干了啥。这比”盲跑”靠谱一万倍。

Hanflow 六层架构示意：一套 YAML DSL 编译成 LangGraph StateGraph

第四章实操：写一份YAML，让静态流程里跑动态子图

光说不练假把式。一个混合编排的骨架长这样（示意）：

workflow:
  nodes:
    - id: fetch_docs
      type: Tool
      depends_on: []
    - id: analyze
      type: Agent          # 动态子图嵌在静态流程里
      prompt: 根据文档提炼3个核心风险点
      depends_on: [fetch_docs]
      retry: 2
    - id: approve
      type: HITL           # 人工确认门
      depends_on: [analyze]
    - id: report
      type: LLM
      depends_on: [approve]

看见没？fetch_docs 是死步骤，analyze 让 Agent 自己发挥，approve 卡一道人工确认，过了才生成报告。整条链路是确定性的，但中间那段是活的。这才是生产级 Agent 该有的样子。