把大模型接进编辑器这个想法最早是我在看团队里新同事用 FreeRPA 搭流程时冒出来的。一个新来的实施顾问对着满屏的组件拖拽面板愣了半天不知道该从哪个组件开始也不知道参数该填什么最后只能一边翻文档一边试错一上午就搭了一个“打开网页→输入账号密码→点击登录”的流程。这个场景太熟悉了。RPA 工具发展这么多年核心逻辑一直是“人用鼠标去编排规则”但规则本身的门槛还在那里。我当时就在想如果编辑器能理解人话让 Agent 先把流程草稿搭出来用户只负责审批和微调体验会不会完全不一样。于是就有了 FreeRPA 的 AI 编排 Agent 这件事把大模型接进编辑器让自然语言直接变成可视化流程图。这篇文章就是来拆解这个能力是怎么实现的适合正在做 RPA 产品、低代码平台或者对 Agent 编排落地感兴趣的朋友参考。1. 为什么要把大模型接进编辑器1.1 传统 RPA 编辑器体验的三个真实痛点所有 RPA 工具的编辑器表面上解决的是“自动化流程可视化”的问题但实际用下来三个痛点一直都在。第一个痛点是组件太多认知负担太重。一套成熟的 RPA 工具有几百个组件按功能分几十个分类。浏览器操作、Excel 操作、数据库操作、文件系统、消息通知、OCR、AI 能力……用户要做的第一步不是“做自动化”而是“在几百个组件里找到自己要的那一个”。新手根本不知道实现某个功能应该用哪个组件二开人员和实施顾问也经常需要翻文档。第二个痛点是空画布恐惧。新建一个流程之后编辑器给你一块空白的画布左边是组件面板中间是流程设计区。对于有经验的人来说画布是生产力工具对于第一次用的人来说这块画布带来的不是自由度而是“从哪里开始”的压力。你会发现很多新用户会把大量时间花在“规划流程结构”上而不是“实现流程逻辑”。第三个痛点是参数配置繁琐。每个组件都有大量属性需要配置比如浏览器组件的 URL、等待时间、选择器Excel 组件的文件路径、Sheet 名、单元格范围。哪怕流程结构已经想清楚了把每个节点的参数填对也是一个耗时且容易出错的环节。选择器写得不对运行时报错排查起来非常痛苦。这三点叠加在一起导致 RPA 的“自动化”能力很强但“上手体验”一直不够好。传统的解决思路是加教程、加模板、加智能提示但这些都还是“让用户去适应工具”。把大模型接进编辑器之后思路反过来让工具去理解用户。1.2 AI 编排 Agent 要解决的核心问题大模型接进编辑器不是为了加一个“智能问答”的聊天框而是要直接参与流程编排本身。我在设计这个功能的时候给 AI 编排 Agent 定义了三个核心目标。第一听懂用户需求。用户用自然语言描述任务比如“每天早上十点定时打开销售系统读取前一天的订单数据汇总成报表发到部门群”Agent 要能理解这句话里包含的触发条件、操作对象、处理逻辑和输出动作。第二生成流程草稿。Agent 要把理解到的内容转换成一棵流程树对应编辑器里的组件节点和连线关系。这相当于让 Agent 先替用户完成 80% 的编排工作剩余 20% 是用户实际确认和参数微调。第三自动补全参数。生成流程节点的时候Agent 要能根据用户描述和系统上下文自动填充关键属性。比如用户说“打开销售系统的登录页面”Agent 应该在浏览器组件的 URL 属性里填好默认的登录地址而不是留给用户一个空表单。这三个目标做到之后AI 编排 Agent 在编辑器里的定位就清晰了它不是替代用户的规则引擎而是一个“懂业务的流程助手”。它帮你把脑子里模糊的想法变成画布上清晰的结构再由你决定是否执行、怎么调整。1.3 一个边界问题AI 不是来取代人工编排的这里我要强调一个设计上的边界。AI 编排 Agent 的核心价值是“降低编排门槛、提升编排效率”而不是让流程完全脱离人工控制。我见过不少产品在做类似功能时一上来就追求“全自动生成流程用户只管运行”结果生成的流程往往不可控复杂场景下错误频出用户反而更不信任这个功能。我们在 FreeRPA 里的定位是Agent 生成的是“流程草稿”它永远是可编辑的、可审批的结构化数据。草稿在画布上展示出来之后用户可以自由拖拽调整节点顺序修改参数甚至删除掉整个分支再重新生成。这样既保留了大模型的生成能力又把“最终决策权”交还给人。这个思路在后面实现 AI 编排的时候一直贯穿始终。2. 整体架构编辑器、编排层、执行层怎么配合2.1 架构总览四层模型接入大模型之后FreeRPA 的架构在原有“编辑器 执行引擎”的基础上增加了一个独立的 AI 编排服务。整体分四层。最上层是编辑器前端。编辑器负责可视化流程设计、画布渲染、组件属性面板、运行调试界面。它同时也是 AI 编排能力的主要交互入口用户在这里输入自然语言需求、查看 Agent 生成的流程草稿。第二层是 AI 编排服务。这层是 FreeRPA 新增加的负责接收编辑器传来的用户需求文本组装 Prompt调用大模型解析生成结果做结构化校验最后输出标准化的流程定义。这一层不参与流程的实际运行。第三层是执行引擎。执行引擎负责调度已经保存的流程编排运行节点传递数据处理异常。它只识别标准流程定义不关心这个流程是人拖出来的还是 Agent 生成的。最底层是模型接入层。接入层封装了对不同大模型 API 的调用支持云端模型和本地模型。这样设计的好处是整个编排服务不绑定某个具体的模型服务商。这样的分层让职责非常清晰编辑器负责体验编排服务负责“翻译”执行引擎负责“干活”模型接入层负责“连接”。任何一层替换、升级都不会影响其他层的功能。2.2 为什么中间要加一个 AI 编排服务而不是前端直连模型前期评估方案的时候也想过最简单的做法编辑器前端直接调用大模型 API把返回的 JSON 渲染成流程图。这样开发工作量最小。但仔细一盘算问题很多。第一个问题是安全。前端直连模型意味着 API Key 会暴露在浏览器端无论怎么混淆都能被提取。这对企业级 RPA 工具来说是不可接受的。第二个问题是上下文组装。生成一个可靠的流程草稿不能只靠一句用户需求还需要把当前项目的组件清单、已有流程结构、节点参数 Schema 都传给模型。这些信息的组装逻辑放在前端既臃肿又难维护。放在后端服务里可以统一管理 Prompt 模板和上下文的版本。第三个问题是校验逻辑。大模型输出的是文本不能假设它每次都输出合法的 JSON更不能假设它引用的组件名真的存在。后端服务可以加一层严格的校验和修正逻辑模型生成后先过一遍 JSON Schema、组件名校验、参数类型校验有问题就自动让模型重新生成而不是返回给用户一堆错误。第四个问题是模型切换的弹性。企业用户对数据安全的要求不同有的接受云端 API有的必须私有化部署。如果前端直连切换模型就得改前端代码。有了独立的模型接入层配置一个 base_url 和 model_name 就能切换。所以中间加这一层虽然增加了开发量但长期来看是必须的。这也是做 AI 应用的一个通用原则模型能力再强也不能让它在工程体系里裸奔必须用代码给它包一层“护栏”。2.3 模型无关设计一份 Prompt多种模型可用模型接入层设计成“模型无关”还有一个额外好处可以灵活适配不同的大模型。在 FreeRPA 的场景里不同的模型各有优劣。指令遵循能力强的模型生成 JSON 的稳定性高适合做流程草稿生成推理能力强的模型能把复杂的自然语言需求拆解得更合理适合处理包含大量条件分支的场景参数量小的本地模型部署简单隐私好但复杂流程生成能力有限适合简单场景。我们封装了统一的调用接口通过配置文件指定当前使用的模型类型和地址。OpenAI 兼容协议的直接填 base_url 和 api_keyOllama 本地模型填 Ollama 服务和模型名其他模型服务会转换成标准接口再接入。这样一来同一个 AI 编排服务既可以在云端用大参数模型处理复杂需求也可以在企业内网用小参数模型处理简单流程运行环境灵活得很。3. 最核心的部分编辑器里的 Agent 编排是怎么实现的3.1 流程图的数据模型先定标准再让模型去填要让大模型生成流程草稿最重要的一步不是写 Prompt而是先定义好流程图的数据结构。结构清晰了模型才能理解该输出什么。我们把 FreeRPA 的流程图抽象成两个基本元素节点Node和连线Edge。节点是流程中的一个操作步骤比如打开浏览器、填写输入框、点击按钮、读取 Excel、发送 HTTP 请求。每个节点包含唯一的 ID、组件类型、名称、位置坐标画布渲染用和属性对象。属性对象里是组件的具体配置比如 URL、等待时间、选择器等。连线表示节点之间的执行顺序和数据流包含源节点 ID、目标节点 ID以及可选的分支条件。比如条件判断节点产生的“是”分支和“否”分支就是在连线上标记不同的条件表达式。最终给到大模型的是一段标准 JSON模型的任务就是根据用户需求生成这样一段 JSON。为了避免模型胡编乱造我们会先把组件类型枚举、每种组件的必填参数和类型说明一起放进 Prompt并且明确要求它只能使用清单里有的组件。一个典型流程草稿的结构长这样{ nodes: [ { id: node_001, type: trigger_schedule, name: 定时触发, x: 80, y: 120, props: { cron: 0 0 10 * * * } }, { id: node_002, type: browser_open, name: 打开销售系统, x: 300, y: 120, props: { url: https://erp.example.com/login, wait_type: load } }, { id: node_003, type: browser_input, name: 输入用户名, x: 520, y: 120, props: { selector: #username, input_value: admin } } ], edges: [ { from: node_001, to: node_002 }, { from: node_002, to: node_003 } ] }数据模型最终落在编辑器画布上时每个 JSON 节点会渲染成一个拖拽卡片每条连线会被渲染成一个带箭头的线段。用户看到的是一张标准流程设计图完全感知不到背后 AI 生成的过程。3.2 组件清单注入让模型“只能”用真实存在的组件模型幻觉是 LLM 应用里最常见的问题。在 AI 编排场景里幻觉的典型表现是模型生成了一个看起来合理、但实际上 FreeRPA 里根本不存在的组件类型。比如一本正经地给出一个“发送企微群消息”的节点但实际产品里负责这件事的组件叫“发送钉钉工作通知”。为了解决这个我们在 Prompt 里注入了一套组件清单把当前版本 FreeRPA 支持的所有组件类型、名称、参数定义都带进去。清单是动态生成的不同用户、不同产品的组件版本不同注入的内容也不同。Prompt 里的组件清单给模型看后端的校验逻辑再用同一份清单做硬校验。模型生成结果之后解析出来的每个节点 type 都必须能在组件清单里找到否则就判断该节点无效。无效节点不是直接丢弃而是把错误信息回传给模型让它重新生成。这个“生成→校验→再生成”的过程就是后续要讲的编排循环。组件清单的注入还有个约束技巧如果组件总量太大全量塞进 Prompt 会消耗大量 token甚至可能撑爆上下文窗口。所以 FreeRPA 并不是每次都注入全部组件而是会根据用户需求文本做一次预筛选把最可能用到的几百个组件先筛出来再注入 Prompt。比如用户提到“定时”“每天”就优先选入定时触发组件提到“Excel”“表格”就优先选入 Excel 处理组件。这样既控制了 Prompt 长度又提高了生成准确率。3.3 自然语言到流程树的转换Prompt 设计实例这部分是整个功能最见真章的地方Prompt 的质量决定生成效果的上限。我把 FreeRPA 里实际用的 Prompt 模板简化一版分享出来供大家参考。完整版涉及内部组件清单这里只演示核心结构。你是 FreeRPA 的流程编排助手。你的任务是把用户描述的需求转换成一个自动化流程。 流程用 JSON 格式表示包含节点列表 nodes 和连线列表 edges。 组件类型只能从以下枚举中选择 - trigger_schedule定时触发 - browser_open打开浏览器页面 - browser_input向输入框填写内容 - browser_click点击页面元素 - excel_read读取 Excel 文件 - excel_write写入 Excel 文件 - http_request发送 HTTP 请求 - condition_judge条件判断 - message_send发送消息通知 每个节点的 props 必须包含对应组件的全部必填参数。例如 browser_input 必须提供 selector 和 input_valuetrigger_schedule 必须提供 cron。 请严格输出 JSON不要输出其他解释文字。 用户需求{用户输入的需求文本}这里面有几个关键设计。第一个是“组件类型只能从枚举中选择”的强约束。这一句话就能大幅降低组件幻觉概率因为模型在生成时会倾向于从给定的列表里挑选。第二个是“必须包含全部必填参数”的要求。把参数规则前置到 Prompt 里模型生成的节点才会完整后续用户微调的工作量才小。第三个是“严格输出 JSON不要输出其他解释文字”。少了这句话模型经常会输出一段说明再接 JSON或者 JSON 外面包一层 Markdown 代码块给解析增加额外麻烦。用户输入“每天早上十点定时打开销售系统读取前一天的订单数据汇总成报表发到部门群”时模型会根据这段 Prompt 生成对应的流程 JSON。后端解析之后画布上就会出现一条流程链定时触发→打开销售系统→读取订单数据→处理汇总→发送消息。3.4 编排循环生成、校验、修正、再校验大模型不可能一次生成就永远正确所以 AI 编排服务里实现了一个执行循环。这个循环是保证生成质量的关键所在。循环的第一步是生成。编辑器把用户需求文本发给 AI 编排服务编排服务组装 Prompt调用模型得到原始输出。第二步是解析与校验。对模型输出做 JSON 解析如果解析失败直接进入修正流程解析成功之后逐节点检查组件 type 是否合法、props 是否完整、必填参数是否缺失、参数类型是否正确。同时还要检查连线关系引用的节点 ID 必须真实存在不能出现悬空连接。第三步是修正。如果校验发现任何问题服务会把错误信息拼接成一条修正指令连同原始输出一起再次发给模型要求它“针对以下错误重新生成完整 JSON”。这个循环最多执行三次避免模型无限犯错、无限重试浪费时间和 token。第四步是把最终结果返回给编辑器。校验通过或三次修正后仍然失败的结果都会返回只不过通过了就直接展示没通过就附带一条提示信息告诉用户“AI 暂时无法生成可用流程建议手动编排”。这个循环在执行层面非常简单就是 for 循环加几次判断但实际效果非常显著。我实测下来在组件清单约束完整的情况下一套简单流程能一次生成成功的概率在七成左右经过一次修正之后能提到九成以上。3.5 编辑器侧的体验设计流式渲染与审批确认后端做得再完善前端体验跟不上也白搭。编辑器在接收 AI 编排结果的时候做了两个交互上的关键设计。第一个是流式输出。用户的直观理解是“AI 正在帮我搭流程”而不是等好几秒才看到结果。编辑器与编排服务之间用 SSEServer-Sent Events建立连接模型是一个 token 一个 token 生成文本的我们就把这些增量数据实时推给前端。前端收到后先在界面右侧显示生成日志比如“正在解析用户需求”“正在生成流程节点 1/5”“正在校验参数”。当完整 JSON 生成并校验通过后再把流程图一次性渲染到画布上。这一步虽然不是必须的但对用户耐心的影响确实很大。第二个是审批确认。流程图渲染到画布后默认不是已保存状态。用户需要逐个检查节点名称、参数配置可以直接在画布上修改或删除节点。确认无误后点击“保存为流程”才真正写入流程库允许被调度和执行。这就把 AI 生成的内容和用户决策的边界彻底分开了避免出现“模型全自动生成、用户毫无参与感、出问题只能背锅”的被动局面。4. 模型选型与接入配置4.1 云端 API 和本地模型怎么选接入大模型的时候第一个要拍板的事是用云端的 API 还是自己部署的本地模型。这两者在 FreeRPA 的实际场景里各有应用空间不能一刀切。云端 API 的优势非常明显模型能力强、指令遵循能力高、上下文窗口大生成的流程节点更准确、参数更完整。尤其是需要生成包含多条件分支的复杂流程时云端大模型的推理优势能直接体现出来。劣势也明确数据要经过模型服务商有的企业客户对业务数据外发有严格限制根本接受不了。本地模型的优势是数据不出内网满足合规要求而且调用成本低、可反复测试。劣势是中小参数模型在指令遵循和复杂推理上的能力差距明显容易出现组件选错、参数漏填、流程结构混乱等问题。用 7B 级别的模型生成一个包含五个节点的简单流程问题不大但要生成一个包含十几步操作、多个分支判断的完整流程稳定性就差很多。所以 FreeRPA 的默认策略是双轨并行SaaS 版本直接调用云端大模型获得最佳效果私有化部署版本提供一个模型适配层用户可以在 Ollama 上部署本地模型从内网模型服务接入。实际选哪个取决于业务数据敏感程度和复杂流程占比不是技术问题而是场景问题。4.2 本地部署的关键配置参考本地部署大模型这条路现在比两年前成熟太多了。我在测试环境里用 Ollama 跑模型过程非常简单几个命令就能把一个可用模型拉起来。Ollama 支持很多开源模型我在 FreeRPA 的本地部署场景里主要推荐 Qwen2.5 系列的 14B 和 32B 版本。14B 对硬件要求低一点32B 的效果更接近云端方案。这里给一份实测可用的配置参考模型Qwen2.5-32B-Instruct或者更轻量的 Qwen2.5-14B-Instruct部署方式Ollama安装后执行ollama run qwen2.5:32b即可内存建议32B 量化版本至少 32GB 内存14B 量化版本 16GB 即可Prompt 上下文建议开启至少 8k 的上下文窗口因为组件清单注入需要占不少空间在 Ollama 里模型的 temperature 参数可以通过OLLAMA_TEMPERATURE环境变量设置AI 编排场景建议保持在 0.2 以下。当生成 JSON 这种对确定性要求极高的内容时温度越高越容易产生格式错误和字段幻觉。如果模型输出频繁出现 JSON 解析失败优先检查是不是温度设高了。4.3 关键模型参数不仅调大模型还要调工程大模型接入后的效果关键不仅在模型本身的选型还要靠几个工程参数的配合。我把 FreeRPA 里最重要的几个参数拎出来讲一下。第一个是 temperature。生成代码、JSON 这种结构化内容时我建议设到 0 到 0.3 之间。温度调高会让输出更多样但对流程编排这种必须确定性正确的内容来说多样反而是灾难。第二个是 max_tokens。不要设太小也不要设到模型上限。模型生成一个流程 JSON简单流程可能几百 token 就够但一个包含十几个节点、参数多、注释多的大型流程可能轻松超过两千 token。如果 max_tokens 太小输出会被截断JSON 不完整解析必然失败。FreeRPA 里默认设的是 4000复杂项目环境会调到 8000。第三个是上下文长度。前面提到组件清单会先预筛选再注入但遇到用户需求本身描述很详细的情况上下文占用也会直线上升。本地部署模型时要确保开启足够的上下文窗口同时控制 Prompt 中组件清单的大小。5. 实测中的常见问题与排查实录5.1 常见问题速查表做这个功能前后踩了不少坑把遇到频率最高的问题整理成了一张速查表方便拿到现场直接用。问题现象根本原因解决办法模型输出解析失败不是合法 JSONtemperature 过高或 Prompt 没有强制 JSON 输出调低 temperature 到 0.2 以下Prompt 明确“严格输出 JSON”节点类型在产品里不存在组件清单未注入或注入不完整确保 Prompt 里有组件类型枚举后端加白名单校验节点缺少必填参数组件 Schema 未注入模型不知道参数要求在组件清单中加入每个节点的参数定义校验后自动修正连线引用了不存在的节点 ID模型生成节点后自行修了 ID后端做引用完整性校验修一次就解决流程过长导致 token 不足、输出被截断max_tokens 设置太小调大 max_tokens同时简化组件清单注入本地模型生成效果远差于云端模型参数量太小换更大参数模型或把复杂流程流转到云端模型用户需求包含“每天”“定时”但没生成触发节点模型没有识别隐含条件在 Prompt 中加入意图分析步骤把触发条件单独拆出来5.2 几个典型排查过程除了小问题还有些问题排查起来更隐蔽值得单独说说。第一个是组件层幻觉。这类问题不是模型乱编组件名而是把真正存在的组件用在了错误位置。比如用户说“把订单数据发送到群里”模型生成了“发送钉钉工作通知”但用户实际用的是企业微信产品里有一个更匹配的“发送企业微信消息”组件。这类问题校验完全拦不住因为组件名合法、参数完整。后来我们在 Prompt 里增加了一个额外的“组件选择理由”字段让模型在生成每个节点前先输出一个简短理由说明为什么选这个组件而不是其他相近组件。这个理由字段虽然最终会被丢弃但它强迫模型在做选择之前先自我审视有效降低了张冠李戴的概率。第二个是参数合理性校验。JSON 格式正确、组件名正确、参数类型正确不代表参数值合理。比如浏览器打开页面的 URL 写成了http://开头但公司内部系统要求https://。这类问题只靠 Schema 校验发现不了我们在后端把常用参数类型的枚举值、正则表达式加进了校验规则URL 格式、时间格式、数字范围都会先过一遍。这又给模型生成加了一道护栏。第三个是复杂需求的流程遗漏。用户一口气提了五件事模型生成流程时只实现了三件另外两件被忽略了。排查发现是用户输入过长模型在长文本理解时注意力分散。解决方法是先把用户需求做一个“意图拆分”把输入文本发给模型要求它先分成若干条单一操作指令再为每条指令生成对应节点。这一步本质上是把复杂任务分解成子任务生成效果稳定得多。后来我们把这一套“拆分——生成——合并”作为复杂流程的默认处理链路。5.3 降级策略模型挂了不能让产品跟着挂接入大模型之后产品就多了一个外部依赖服务不稳定、API 限流、网络超时都是常态所以必须设计降级策略。FreeRPA 的做法是在编排服务层做了三级降级。第一级同一模型供应商的 API 限流时自动切换到另一个供应商的兼容接口第二级云端模型全部不可用时切换到本地模型服务第三级所有模型都不可用时编辑器的 AI 编排入口自动隐藏用户回到手动拖拽的老路径。这样设计的目的很明确AI 编排是一个附加能力核心价值仍然在编辑器本身。模型服务故障时用户最多就是失去 AI 辅助但产品的主流程不能被拖垮。这一点我特别想分享给做 Agent 产品的同行在把大模型接进任何系统之前先想清楚它故障的时候你的产品怎么继续运转。6. 从“能用”到“好用”下一步的扩展方向AI 编排 Agent 做到现在这个程度基本实现了从“自然语言”到“流程图草稿”的闭环。但说实话这只是把大模型接进编辑器的第一步。我在实际使用中明显感觉到停留在“单轮问答生成流程”这个层面是不够的还有几件事值得继续深入。第一件事是多轮交互。用户第一次生成的流程往往不够完善需要在后续对话里继续补充需求“把汇总结果再加上同比环比”“发消息的时候顺便一下负责人”“如果系统登录失败就发告警通知”。现在这些需求要用户手动改流程才能实现。下一步计划支持完整的对话式流程编辑用户在一个会话里反复修改、逐段调整Agent 在原有流程草稿上做增量更新而不是每次推倒重来。第二件事是项目经验的沉淀。每个 RPA 项目沉淀下来的流程模板是宝贵资产。我们正在尝试把已有的历史流程作为少样本示例注入 Prompt让 Agent 学会当前团队的做法和习惯。比如团队习惯在浏览器操作前统一加一个“检查网络连通性”的前置节点模型以前不知道但参考了历史流程的 Prompt 注入之后生成的草稿就会自然带上这个习惯。第三件事是让 Agent 能理解“流程为什么不工作”。现在的模型只参与了流程生成没参与运行后的报错排查。未来想在执行引擎反馈错误时自动把错误信息和当前流程上下文发给模型让模型给出修改建议甚至直接生成补丁。这相当于把 AI 编排从“设计阶段”延伸到了“运行维护阶段”。我个人在开发和落地这个功能过程中最大的体会是接大模型这件事本身不难难的是把模型能力嵌进一个成熟的工程体系里让它不破坏原有系统的确定性。流程编排本质上是一个容错率很低的事情一个节点选错、一个参数填错跑起来就是连锁故障。所以 AI 编排 Agent 的核心不应该是“让模型自由发挥”而是用工程手段给模型的输出套上层层约束——组件白名单、参数 Schema、引用校验、修正循环、人工审批。模型负责天马行空地理解需求工程负责脚踏实地地兜住边界。如果你也在做类似的产品建议先从一个高频、低频次、容错率高的场景切入比如“定时报表推送”这种流程结构固定、参数清晰的需求验证 AI 编排的可用性再逐步扩大到更复杂的场景。这一步走稳了大模型和 RPA 的结合带来的价值会远超预期。