第 8 章：Agent Flow vs 低代码编排——两条路线的融合
我遇到了什么问题
第 1 章讲了工作流引擎——用户拖拽画布，定义流程图，机器按图执行。这是"低代码编排"路线。
第 5 章讲了 Agent 系统——用户说自然语言，Agent 自己决定下一步做什么。这是"Agent 自主决策"路线。
这两条路线看起来是矛盾的：
- 工作流：确定性——每一步都是预先定义的
- Agent：不确定性——每一步都是 LLM 实时决策的
在我的项目里，这两条路线同时存在。用户既可以在画布上拖拽工作流，也可以在对话框里用自然语言让 Agent 做事。
问题就来了：这两条路线怎么融合？
我做了什么决策
决策 1：两条路线不是"二选一"
一开始我以为只能选一条：要么全用工作流（确定性），要么全用 Agent（自主性）。
但实际场景告诉我，两者都有存在的价值：
| 场景 | 适合的方式 | 原因 |
|---|---|---|
| 每天 8 点拉数据生成报表 | 工作流 | 流程确定，不需要 AI 决策 |
| "帮我总结一下最近的订单" | Agent | 需要理解用户意图 |
| 订单金额 > 1000 走人工审核 | 工作流 | 业务规则确定 |
| "帮我写一封回复邮件" | Agent | 需要生成内容 |
确定性场景用工作流，不确定性场景用 Agent。 这不是"二选一"，是"各取所长"。
决策 2：Agent 可以"生成"工作流
更有趣的融合方式：Agent 不只是"替代"工作流，它可以生成工作流。
这就是 AiAgent.Integration 模块做的事——用户用自然语言描述需求，Agent 自动生成一个完整的工作流定义。
6 步 AI 编排流水线：
Step 1：需求解析 → 理解用户要做什么
↓
Step 2：控制骨架 → 选择工作流结构（线性/分支/循环）
↓
Step 3：节点选型 → 从已有节点库中选择合适的节点
↓
Step 4：参数填充 → 配置每个节点的参数和引用关系
↓
Step 5：Canvas 构建 → 生成画布 JSON 定义
↓
Step 6：注册执行 → 注册到工作流引擎，可以运行每一步都是一个 SubAgent，有自己的系统提示词和工具集。编排层（WorkflowPlannerService）负责串联这 6 步。
csharp
public interface IWorkflowPlannerService
{
// 启动新会话，执行 Step 1（需求解析）
Task<WorkflowPlanningSession> StartPlanningAsync(string requirement);
// 用户确认当前步骤 → 前进到下一步
Task<WorkflowPlanningSession> ConfirmStepAsync(PlanningStep step, ...);
// 用户想调整当前步骤 → 记录反馈，重新生成
Task<WorkflowPlanningSession> AdjustStepAsync(PlanningStep step, ..., string feedback);
// 用户想回退到之前某步 → 级联清除下游，重新执行
Task<WorkflowPlanningSession> RollbackToStepAsync(PlanningStep targetStep, ...);
}注意三种交互模式：
- 确认：用户说"可以"→ 前进到下一步
- 调整：用户说"节点选型不对，应该用 HTTP 节点"→ 带反馈重新生成
- 回退：用户说"回到需求解析那步"→ 级联清除下游，重新执行
这就是"Agent 生成工作流"的完整链路。
决策 3：工作流可以"调用" Agent
反过来，工作流节点也可以调用 Agent。
第 2 章讲过 LLM 节点——工作流中的一个节点，调用大模型 API。这个节点本质上就是一个"微型 Agent"——接收输入，调用 LLM，返回输出。
工作流：
触发器 → SQL查询节点 → LLM节点（总结数据）→ 邮件发送节点
↑
这就是一个"微型 Agent"更进一步，工作流可以调用完整的 Agent 系统——带记忆、带 Skill、带工具的完整 Agent。
工作流：
触发器 → 数据收集节点 → Agent节点（自主分析）→ 结果输出节点
↑
完整的 Agent，有自己的记忆和工具决策 4：Integration 层的定位
AiAgent.Integration 是连接两条路线的"桥梁"：
用户输入（自然语言）
│
▼
AiAgent.Integration ──── 1) 解析意图（LLM 驱动）
│ 2) 编排流水线（Planner → Creator → Checker）
│ 3) 调用现有模块接口（CLI / Workflow）
▼
现有 Modules（不感知 Agent）关键设计原则：
- Integration 是薄胶水层——不持有业务数据，不写领域逻辑
- 单向依赖——Integration → 业务模块，业务模块不感知 Integration
- 不改业务模块——通过
InternalsVisibleTo直接访问内部接口，业务模块零改动
AiAgent.Integration/
├── Module/
│ ├── CLI/ ← CLI 模块集成
│ │ └── CLINodeQueryService.cs
│ └── Workflow/ ← Workflow 模块集成
│ ├── WorkflowDefinitionQueryService.cs
│ ├── WorkflowValidationService.cs
│ └── WorkflowManagementService.cs
├── Agents/ ← Planner/Creator/Checker Agent
├── Tools/ ← Agent 使用的工具
└── Documents/
├── 创建工作流/ ← 6 步流水线设计文档
├── MAF框架/ ← MAF 框架研究笔记
└── harness设计/ ← Harness 设计文档代码里长成了什么样
两种模式的对比
模式 A：低代码编排
人 → 画布拖拽 → 工作流定义（JSON）→ 工作流引擎 → 执行结果
特点：确定性、可预测、可调试
适合：流程明确的业务自动化
模式 B：Agent 自主决策
人 → 自然语言 → Agent（LLM 决策）→ 工具调用 → 返回结果
特点：灵活性、适应性、不可预测
适合：需要理解和判断的开放场景
模式 C：Agent 生成工作流（融合）
人 → 自然语言 → Agent → 工作流定义（JSON）→ 工作流引擎 → 执行结果
特点：灵活性 + 确定性
适合：用户知道要做什么，但不知道怎么画流程图6 步流水线的产物
每一步的产物都是可检查、可调整的：
Step 1 产物：需求解析结果（结构化 JSON）
→ 用户确认："对，我就是要做这个"
Step 2 产物：控制骨架（线性/分支/循环的选择）
→ 用户调整："不要用线性，用分支，金额大于1000走审核"
Step 3 产物：节点选型列表
→ 用户确认："这些节点选得对"
Step 4 产物：参数配置（每个节点的输入输出映射）
→ 用户调整："HTTP 节点的 URL 应该是 https://api.example.com"
Step 5 产物：Canvas JSON（完整的工作流画布定义）
→ 用户确认："看起来没问题"
Step 6 产物：注册到工作流引擎（可以运行了）业界怎么做的
LangGraph 的答案是"图即 Agent"——不需要区分工作流和 Agent，因为一切都是图。Agent 的决策是图中的一个节点，工作流的步骤也是图中的一个节点。好处是统一，坏处是"确定性"和"自主性"的边界模糊了。
Coze/Dify 的答案是"工作流 + LLM 节点"——工作流是主体，LLM 只是其中一个节点。Agent 不具备自主决策能力，只能在工作流的框架内"被调用"。好处是简单，坏处是 Agent 的能力被限制了。
微软 MAF 的答案是"Agent 内嵌工作流"——Agent 可以调用工作流引擎作为工具。工作流是 Agent 的"手"，不是 Agent 的"笼子"。
我的答案是"双向融合"——Agent 可以生成工作流，工作流可以调用 Agent。不是谁包含谁，是互相调用。
关键认知
这一章的关键认知：
未来不是"工作流 or Agent"，是"Agent 生成工作流，工作流编排 Agent"。
两条路线不是对立的，是互补的：
- 工作流提供确定性——流程可预测、可调试、可审计
- Agent 提供灵活性——能理解意图、能生成内容、能自主决策
融合的方式有两种：
- Agent 生成工作流：用户用自然语言描述需求，Agent 自动生成可执行的工作流
- 工作流调用 Agent：工作流中的某个节点是完整的 Agent，具备自主决策能力
两种方式在我的项目里都已经实现了。这就是"两条路线融合"的实际含义。