配置即代码：用 YAML/JSON 把企业工作流交给 Agent 跑

企业引入 Agent，决定系统能走多远的是控制流怎么写。控制流固化在代码里，业务每变一次就要改代码、走发布、跑回归；控制流抽到 YAML 或 JSON 里，部分流程变更可通过配置提交和评审完成；涉及接口、权限、数据结构或新能力时，仍可能需要开发与测试。两类方案在灵活性、治理成本和适用场景上存在差异。把节点、条件、状态与并发从代码层剥离，用可版本管理的文本描述流程，让引擎去解释执行，这是是企业级 Agent 落地中值得重点评估的能力之一，也是本文讨论的主线。

控制流是怎么一步步从代码里被剥出来的

最早的自动化是一段顺序执行的批处理程序，控制流和业务逻辑写在同一个文件里，改流程就是改代码。企业流程变复杂之后出现了独立的工作流引擎，用 XML 描述流程定义，引擎读取定义再执行，BPEL、BPMN 这类规范就来自那个阶段。这是"做什么"与"按什么顺序做"的第一次分离。

数据处理时代换成了有向无环图调度器，任务拆成节点，边表达依赖，调度器按拓扑序执行。这类图有个硬约束，不允许出现环。做 ETL 时这个约束合理，流程天然单向；放到大模型应用里就卡住了，Agent 常常需要「生成结果 → 校验 → 不通过 → 回到生成」，环是刚需。

承载这些定义的文本格式最终收敛到 YAML 和 JSON 两种。JSON 脱胎于脚本语言的对象字面量写法，语法极简，机器解析成本低。YAML 最初的名字是"另一种标记语言"，后来改名为"YAML 不是标记语言"，这次改名本身就说明了设计意图：摆脱标记语言的尖括号负担，用缩进表达层级，允许写注释，让人手工编写时不那么痛苦。两者均可描述常见层级化数据结构，转换时需注意注释、类型和特有语法等差异，差别只在人读还是机器读。

配置即代码里的"代码"二字，落点正在于此。流程定义一旦变成纯文本，就能进 Git，改动可以 diff，可以走评审，可以按环境拆成多份变体，也能回滚。流程从某个工程师脑子里的逻辑，变成了团队共有的资产。

LangGraph：把循环还给了编排

LangGraph 是从链式调用框架演进而来的。早期的大模型应用框架把流程组织成链（Chain），节点单向流动，本质就是一张有向无环图。链式结构做检索问答够用，做需要反复试错的 Agent 就不够，因为 Agent 要能调用工具、观察结果、决定重来一次。

LangGraph 把流程建模成允许带环的图，图上流动的是一份显式声明的状态对象。节点是处理单元，读状态、写状态；边决定下一跳，边可以写死，也可以由一个函数根据当前状态算出来。这套抽象带来三个直接后果。

状态显式流转。每个节点看到的都是同一份状态对象的当前快照，节点之间不必互相知道对方存在，耦合被压缩到状态结构这一层。

循环成为原生能力。条件边指回上游节点，重试与迭代就成立了，业务代码里不需要手写 while。

状态可落盘。图能在执行过程中把状态快照写进存储，这个组件叫 Checkpointer。

Checkpointer 与断点续跑

Checkpointer 的思路来自事务日志和游戏存档，在某个时刻把完整现场记下来，需要时原样恢复。落到编排引擎里，它在每个节点执行完写一份状态快照，快照用一个 thread_id 标识归属。

它解决两类问题。短任务靠它做失败恢复，在启用持久化、幂等、恢复和补偿策略的情况下，部分流程可从保存状态恢复，并减少部分重复执行。长任务靠它做跨时间续跑，一个需要人工审批或等待外部回调的流程可能挂上几天，进程早就重启过了，靠 thread_id 把状态读回来接着走。

取舍在快照粒度。每个节点都存，恢复点最细，代价是写入频繁，会拖慢执行；只挑关键节点存，速度快了，恢复点变粗，失败时要重跑一段。工程上常见的安排是在耗时长、收费高、有副作用的节点之前存一次。

配置化的四块积木

节点配置化。节点是预置的处理单元，配置里声明节点类型、参数、输入输出字段名。常见流程可通过节点组合完成，复杂场景可能需要新增节点或二次开发。起节点初始化流程上下文并识别输入文件类型，大模型节点承担推理与生成，条件节点做判断。外部接口节点对接第三方服务，数据提取节点把邮件、网页这类非结构化文本转成结构化字段，技能节点则调用独立封装的能力单元，比如代码审查、会议纪要这类可以单独复用的动作。

条件路由。条件节点读取状态里的某个字段，按规则返回分支名，边把分支名映射到下游节点。效果等价于代码里的 if/else，区别是在既有节点和字段映射范围内，可通过配置调整部分分支和数据流转。这里有个高频坑：字段命名没有规范时，流程传着传着就会出现同义不同名的字段，最后只能靠文档对齐。把状态结构本身也纳入版本管理，是流程数量上去之后必须补的功课。

并行执行。配置里把若干节点挂在同一个上游之后，引擎同时启动它们，全部完成后再汇聚。互相无依赖的分支适合这么排，比如向量检索和关键词检索同时进行。fan-out 之后的 fan-in 有个真实风险，两个分支写同一个状态字段会互相覆盖，配置里需要显式声明合并策略，追加到列表就比直接覆盖安全。

配置之上，绕不开的工程判断

流程编排得再顺，进入模型的是错的片段，输出也不会对。检索这一层的质量往往决定了整条工作流的天花板，而这里最容易被低估的是融合策略。

向量检索算的是语义相似度，余弦相似度的取值落在 -1 到 1 之间，量纲固定。关键词检索走的是 BM25 这类基于倒排索引的打分，分数没有上界，词频越高、文档越短，分数越大。把两路分数直接加权相加，量纲大的那一路会主导排序，融合也就名存实亡。可行的做法是先各自排序拿到名次，再用倒数排名融合（RRF）按名次合并，或者把两路候选集交给一个交叉编码器重排。

真正的成本在索引管线的维护。换一次 embedding 模型，全量向量要重算重灌，1024 维 float32 的向量每条约 4KB，一百万条就是 4GB 量级的数据搬运。召回率的回归评测也要固化成发布前的例行检查，比如固定看 recall@10，否则一次配置改动带来的退化，可能几周后才被业务侧发现。

报告生成是一条直线，配置描述起来很干净：

五个节点串起来，文件下载、文档解析、摘要、字段提取、邮件发送，该示例可在现有节点和接口已完成适配的前提下，通过配置实现。

智能客服这条链路多了一处并行和一处外挂查询：

vec 与 kw 并行，merge 做融合，kg 节点用 Cypher 去图数据库里取实体关系，给答案补上结构化的上下文。整条流程的对既有流程的部分调整可通过 YAML 完成；底层逻辑、接口或新能力变化可能仍需修改代码。

可编排才叫平台，写死只是工具

流程写死在代码里的系统，交付能力等于开发排期的速度。流程交给配置的 Agent 系统，交付能力等于业务人员读懂一份 YAML 的速度。两者的差距会在流程数量上体现出来：三五条流程时看不出区别，几十条流程并行演进时，前者的每一次业务变更都要占用开发资源，/配置化可减少部分变更的开发工作，但仍需根据风险完成测试、评审和发布。

前文讨论的这些能力，节点配置化、条件路由、状态传递、并行执行、Checkpointer 持久化，小艾可提供相关编排能力及预置节点，具体数量、模块范围和版本以交付清单为准。对符合既定节点规范的流程调整，通常无需改动执行引擎；具体视变更范围而定。