企业官网建设流程全解析

给低代码工作流编辑器接 AI 助手，让用户用自然语言搭工作流。从"一键生成工作流"起步，经历一次开发完当天就回退的版本，最终为 AI 助手单独设计了一个智能体。

核心工程直觉就一句：LLM 做语义，代码做结构。反幻觉不靠 prompt 兜底。

整套系统含工具集、多层反幻觉机制、限流/熔断/审计三件套，个人独立完成。本篇复盘三段进化，重点讲中间版本为什么被回退、以及各类反幻觉各自在防什么。

一、为什么要做

平台有一个可拖拽的工作流编辑器——画布上拖节点、连线、配参数，产出 DAG 结构的 JSON，发布后被下游智能体调度执行。编辑器包含十来种节点：大模型调用、API 接口、MCP 工具、条件分支、循环、并行、子流程、知识库、人工审批、代码执行。

手动设计工作流有几类实在的痛点：

1. 学习成本高。每种节点的配置字段、资源绑定规则都不一样——API 节点要配绑定码和 URL，MCP 节点要选服务器和工具名，子流程节点要指定目标流程 ID。新人得把文档完整读一遍才敢上手
2. 编排效率低。每个流程都要手动从零拖节点、填参数、连边。同一套"查数据 → LLM 总结 → 输出"的骨架，换一个场景就要重新搭一遍
3. 逻辑容易出错。分支节点的 true/false 出口、循环节点的循环体/循环结束语义、终止节点只能挂在特定出口上——这些拓扑规则全靠人记住，一不小心就连错
4. 修改成本高。流程成型后想微调——比如"把第二个节点从 API 调用换成 MCP 工具"——基本等于删了重建。没有自然语言驱动的增量修改路径

引入 AI 助手的动机就是冲着这四点去的：不熟悉的人用自然语言快速搭出能跑的流程，专业的人用 AI 加速编排、减少低级错误。

二、三段式进化

v0：一键生成（Pipeline，未使用智能体）

第一版的思路直截了当：“用户说需求 → AI 出流程图”。

用户点"AI 生成"按钮 → 填入需求描述 → LLM 两阶段（逻辑规划 → JSON 生成） → 校验（DAG 合法性、环路检测） → 自动布局（分层自动布局） → 返回完整流程图，灌入画布

核心组件后来全部复用了：两阶段生成服务、DAG 校验器（含自动修复）、分层布局器。

根本问题：一次性输出，不能改。用户拿到图之后想微调，只能手动拖节点，或者重新生成——重新生成意味着前面的全丢。而且 LLM 不感知真实资源目录，API 绑定 ID、MCP 工具名全靠编。

v1.0：多轮对话

需求很清楚：用户要能对话式修改——“把第二个节点换成 API 调用”、“在这个分支后面加一个 LLM 总结”。

第一反应是直接把 4 个设计工具（初始化 / 增量更新 / 校验 / 定稿）集成到业务智能体的工具列表里，Redis 存会话，用户在聊天页对话 → 智能体调工具 → 返回 JSON 预览。

开发完当天就回退了。三个问题：

1. 前端聊天组件职责过多炸。本来只渲染消息，现在要额外识别工作流 JSON、渲染预览、加复制按钮、处理工具结果特殊样式——一个组件扛四件事
2. Redis 会话过期。用户搭一半去开会，回来会话丢了，画布也丢了
3. 两套工具集互不兼容。业务查询工具和流程设计工具混在同一个智能体里——LLM 频繁选错工具，两类提示词互相干扰

教训一句话：别在 A 智能体的工具列表里硬塞 B 功能的工具。AI 助手需要自己的智能体。

v2.0：独立设计智能体

不是在业务聊天页里设计流程，是在流程编辑器里嵌入 AI。

┌──────────────────────────────────────────────┐ │ 流程编辑器页面 │ │ ┌──────────────┐ ┌──────────────────────┐ │ │ │ 画布 │ │ AI 助手面板 │ │ │ │ │ │ ┌────────────────┐ │ │ │ │ Start │ │ │ 用户: 帮我加一个 │ │ │ │ │ ↓ │ │ │ 查询订单的节点 │ │ │ │ │ API节点 │ │ │ │ │ │ │ │ ↓ │ │ │ AI: 调用工具 │ │ │ │ │ End │ │ │ → 画布已更新 │ │ │ │ │ │ │ └────────────────┘ │ │ │ └──────────────┘ └──────────────────────┘ │ └──────────────────────────────────────────────┘

三个关键设计决策：

无状态。不用 Redis。画布是唯一真相来源，前端每次请求带着完整画布数据，后端在内存中维护本次会话的临时状态，操作完返回更新后的画布。没有会话过期，没有并发冲突。

独立智能体。设计智能体与业务智能体完全分离——独立工具集、独立提示词模板（数据库存储，可热更新）、独立 API 端点。

服务端画布状态。不靠 LLM 回传大段 JSON——代码节点里的引号、换行会直接导致 JSON 解析失败。后端在单次 Agent 运行中维护画布状态，工具只返回变更摘要。

三、工具集设计

修改"让 LLM 一次输出完整 DAG"的思路，把设计操作拆成独占工具——AI 只能通过调用工具来改画布，不能凭空编造结构。按职责分三类：

四、多层反幻觉机制

出现幻觉不是"说错话"，是编造不存在的资源 ID、循环添加同一个节点、把终止节点挂在循环体里。每一类都对应一种真实出现过的 LLM 行为偏差。

1. 资源归属确认

LLM 可以访问平台全部资源目录，根据用户需求自行判断需要哪些资源。但判断结果不直接生效——添加节点时，LLM 识别到的资源会以弹窗形式展示给用户，默认选中，由用户二次确认和调整后才写入画布。

这套机制的关键不是拦截，是过一遍人的眼睛：LLM 做匹配推荐，人做最终决策。不同类型节点（API / MCP / 子流程）各自独立的资源列表和确认流程，用户不确认，节点不落地。

2. 禁止自造工具

标准 function calling 机制下，LLM 只能调用工具列表中注册的工具名。不做额外拦截——调不存在的工具名时框架直接拒绝，LLM 从 prompt 已有的工具清单中自纠正。

3. 防重复添加

相同标识或相同类型+名称的节点直接拒绝，返回提示引导改用更新操作。这是防止 LLM 循环幻觉——Agent 跑着跑着开始重复加同一个节点，画布越堆越多。

4. 分支与循环拓扑强校验

条件分支必须明确指定走 true 还是 false 出口。循环节点必须区分循环体和循环结束出口。终止节点不能挂在循环体内部。

这些在代码层硬校验，LLM 传错直接拒绝并给明确的错误信息。不靠 prompt 里写"请注意分支语义"——写了没用，LLM 还是会忘。

5. 宽松 JSON 解析

LLM 生成的 JSON 常含未转义换行、单引号、控制字符。策略是两层兜底：标准解析失败 → 降级到宽松模式（允许未转义字符、单引号、尾逗号等）→ 解析成功后归一化为规范 JSON。比"调一调 prompt 让它输出规范 JSON"稳定得多。

6. 代码节点兼容处理

代码执行节点未指定语言时默认补全脚本类型，防止回退到不兼容的执行器。同时把 LLM 生成 JSON 中的字面量换行符还原为真实换行——不然代码在节点里是一整行，没法执行。

7. 画布拓扑摘要回传

每次成功操作后返回拓扑序摘要，像Start → 查订单(API) → 总结(LLM) → End。目的是帮 LLM 保持对当前画布结构的感知——不加这个，LLM 在长对话里会"忘记"画布上已经有什么节点，开始重复添加或乱连。

8. 限流 + 熔断 + 审计

• 单次会话最大调用上限，超限后终止
• 三态熔断器：工具连续失败 N 次后自动跳过，冷却后探测恢复
• 全链路操作审计：记录每次工具调用的入参、出参、耗时

这组基础设施跟其他智能体共享同一套实现，不需要重复造轮子。

五、“AI 建议，用户决策”

AI 产品的主流叙事是"让 AI 替你完成"。在设计工作流这个场景里，我选了反方向。

工具选择双向确认。用户描述需求 → LLM 识别需要的工具 → 弹出对话框显示所有工具（不是只显示 LLM 识别到的）→ LLM 识别到的默认选中 → 用户二次确认和重选。

比"AI 直接调工具"多了用户一步操作，但这步是有意留的：新手有起点（默认选中帮他不迷路），熟练用户保留掌控感（可以改、可以拒绝）。

校验自动修复闭环。用户点"校验" → AI 列出问题 → 用户点"帮我修复" → AI 完成修复。AI 负责发现问题、执行修复，但启不启动修复的决定权在用户。

这一整套交互逻辑遵循同一个思想：AI 负责分析和生成，人保留最终决策权。

六、无状态设计：画布是唯一真相

v1.0 用 Redis 存设计会话，引入了过期、并发、恢复三个维度的复杂度。v2.0 把状态推到前端：

每次请求: 前端传 { message, 画布节点, 画布连线, 已选资源, 对话历史 } → 后端构建设计智能体 → Agent 调用工具修改画布状态 → 流式返回 文本 / 工具调用 / 工具结果 事件 → 工具结果中包含更新后的节点和连线 → 前端解析后更新画布

没有会话过期，没有并发冲突。用户手工拖拽节点和 AI 修改走同一条路径——画布始终在前端状态管理里维护，AI 只是往画布写数据的另一种方式。

代价是每次请求传完整画布。画布数据本身结构精简，常规规模的流程 JSON 体量很小，额外延迟基本感知不到。

七、总结

三段迭代，每次推翻的原因不是需求变了，是把 AI 放在哪选错了。独立按钮 → 一次性工具，用完即弃。塞进业务智能体 → 两套工具互斥，互相拖累。编辑器侧边栏 → 各归各位。

多层防错的教训就一条：落进代码层的才稳，留在 prompt 层的永远不稳。资源确认、拓扑校验、防重复——代码硬约束，一趟过。提示词里写"请注意分支语义"——LLM 每次都在忘，永远在跟遗忘曲线对抗。

这套独立智能体 + 多层代码约束的思路，适用于企业级低代码平台、AI Agent 编排系统、可视化流程引擎等同类场景。