从去年年底开始我在内部推进了一个结合AI能力与低代码开发的平台项目代号某协作工场。核心目标很直接让业务人员用自然语言描述需求系统自动推荐并组装出可运行的工作流应用同时将重复性的虚拟工作比如自动分配任务、生成周报、催办审批交给AI代理去完成。整个平台的技术底座采用低代码模式配合一套组件化架构来承载AI的推理结果。这篇文章是我作为这个项目架构师的经验记录不会讲太多空泛的理论全部是从方案选型、架构拆解到实操落地的真实过程。这个内容适合正在做低代码平台、搞AI Agent落地、或者想把LLM能力融入企业业务系统的人参考。我假设读者有基本的后端或前端开发经验但不需要你是个AI专家——因为我在做这个项目的过程中最大的感受是难点根本不在算法而在如何设计一套稳定的、能被AI理解的组件体系。1. 项目背景与方案选型为什么我会用低代码来承接AI能力1.1 虚拟工作到底指什么很多人听到虚拟工作第一反应是远程办公但在这个项目里含义完全不同。我指的是那些原本需要人工在系统里反复点击、填写、判断、转交的数字化操作现在交给一个AI代理来执行。举个例子。我们内部有一个离职交接流程员工提交申请HR核对资产清单IT回收账号财务冻结权限最后部门主管确认。原来这个流程要走好几天因为每一步都依赖不同系统里的人工操作。在某协作工场平台上我把它建模成一组组件一个表单组件负责申请录入一个审批组件负责规则判断一个消息组件负责通知再加三个对接外部系统的接口组件。而AI代理在中枢位置学会了一件事——当表单触发提交事件后按顺序调用这些组件并在关键节点做决策比如资产未归还时暂停流程并通知HR。这个能力用传统开发方式也能做但问题在于业务部门的需求变化太快每周都有新的流程要加、旧的逻辑要改。如果全靠开发团队写代码根本接不住。所以我需要一个载体让流程的调整在配置层面完成同时又要保留足够的设计约束来保证AI不会乱来。低代码平台天然适合这个场景关键是——我必须自己设计出足够严谨的组件化架构而不是简单套一个开源的流程引擎。1.2 低代码与AI融合的选型考量项目启动前我调研过市面上的开源方案总结起来有三条路线方案路线代表思路核心优势主要问题自研引擎 组件库自己定义数据模型、流程模型、渲染器完全可控AI可深度定制工作量大需要长期投入集成开源低代码引擎基于现成的可视化搭建框架扩展快速启动生态成熟架构约束受限AI难以深度耦合纯AI生成代码让LLM直接写业务代码并执行最灵活看上去很美稳定性差难以收敛成平台资产我最终选择了第一条路自研一个轻量级引擎。原因有三个第一AI的输出天然具有不确定性我需要一个中间表示层来兜底。如果让LLM直接生成JavaScript代码然后执行一次生成的代码可能有细微的语法错误、上下文引用错误、或者是依赖缺失。但如果让AI输出一份JSON格式的工作流描述再交给平台引擎去解析执行那整个链路就安全得多——因为JSON是结构化数据引擎可以逐字段校验不合法就拒绝执行而不是让未知代码在运行环境里乱跑。第二组件化架构的核心在于收敛。平台通过预定义的组件把业务能力封装成标准单元AI只需要学会选择合适的组件并配置参数而不用理解每个组件内部的实现细节。这就像招了个实习生你只需要告诉他用公司标准的发文模板而不是教他排版规范。第三我需要明确的权限边界。AI代理执行虚拟工作时必须知道自己能调用哪些组件、不能调用哪些组件。组件注册表里本身就带权限标记AI的每一次选择都受到这套元数据的约束。选择自研的另一面是成本。我花了一个月时间设计领域语言和组件规范但我觉得这笔投入非常值——因为它决定了平台后续一年里AI接管虚拟工作的稳定性和可维护性。2. 平台整体架构与组件化设计核心2.1 分层架构与核心模块划分某协作工场的整体架构分为六层每一层的职责都很聚焦第一层是基础设施层负责数据库存储、消息队列、对象存储和外部系统连接。这一层直接复用公司已有的中间件底座没有额外造轮子。第二层是领域服务层把企业常见的业务能力抽象成服务接口。比如用户组织服务、任务服务、审批服务、消息服务、附件服务。组件在运行时要调用的就是这些领域服务的API。第三层是组件层这是一切的核心。每个组件代表一个可复用的业务能力单元有明确的输入输出定义。我后面会详细说组件模型的设计这里先不展开。第四层是编排引擎层负责加载工作流定义、维护执行状态、调度组件执行。引擎本身是无状态的设计执行状态全部持久化到数据库这样任何一个节点宕机都不会导致流程丢失。第五层是AI服务层包括意图识别模型、组件选择推荐模型、参数填充模块和虚拟工作代理。这一层是连接用户自然语言和平台组件世界的翻译器。第六层是应用表现层包括可视化设计器、运行态页面渲染器和管理控制台。业务人员平时接触到的就是这一层。简单说用户在前端用自然语言描述需求AI服务层把这句话翻译成结构化的工作流描述编排引擎拿到描述后按依赖顺序调用组件组件再通过领域服务完成真实业务动作。整个链路里最关键的约束是AI和用户看到的都是组件不是代码。2.2 组件模型设计属性、方法、事件与数据契约我在设计组件模型时参考了近十年前端框架的组件思想但做了三层关键改造让它适配低代码和AI推理这两个场景。第一层是组件描述元数据。每个组件都有一个统一的名字空间比如workflow.approval表示审批、一组声明式属性比如审批人、优先级、超时时间、一组可调用方法比如submit、approve、reject、一组向外抛出的事件比如onSubmitted、onApproved、onRejected以及一个数据契约。数据契约定义了这个组件消费什么数据结构、输出什么数据结构。这一步看着简单但我花了很多时间。难点在于属性类型的定义不能太宽松否则AI和人都没法保证填对参数。比如审批人这个属性我定义成用户ID数组而不是字符串并且在类型系统里做了引用关系解析——组件运行时能去用户服务里校验这些ID是真实存在的。第二层是组件执行策略。每个组件可以声明自己是同步执行还是异步执行是原子操作还是可补偿操作。这一点尤其重要因为虚拟工作里很多操作涉及外部系统比如调用财务接口发起付款审批失败后可能需要发补偿消息。如果没有这层声明AI编排出来的流程一旦中间出错整个链路就卡死或者脏数据横飞。我的做法是每个组件声明其补偿策略引擎在流程启动前自动生成一条逆向补偿链路。比如组A完成后组B失败引擎能根据补偿关系自动执行A的撤销操作。第三层是组件安全标签。组件可以被标记为需人工确认、敏感操作、只读或内部调用。AI代理在自动执行虚拟工作时遇到需人工确认的组件时必须暂停推送待办给负责人。这个设计是产品经理提出的后来在实际运行中被证明价值极大——因为没有这个约束AI很容易帮用户做出越权决定。组件注册表是全部组件元数据的管理中心每个新组件上线必须按规范注册。我要求所有组件通过单测框架自动生成一份调用示例文档这份文档同时被AI服务的提示词引擎利用。也就是说组件元数据本身就是AI的工具箱清单。这一点后面在AI集成章节会重点说明。2.3 编排引擎用JSON描述工作流编排引擎是整个平台的骨干通道。用户需要用一种方式描述先做A、再做B、如果C成立则做D而AI也需要输出同一个格式的内容。我定义了一套以JSON Schema为核心的编排描述语言称为流程描述结构Process Description StructurePDS。一份PDS包含四个主要部分info流程的元信息包括流程名、版本、所属业务域。start触发方式可以是表单提交、定时任务、消息监听或AI主动发起。steps步骤数组每个步骤引用一个组件id并传入该组件的属性参数。links步骤之间的依赖关系定义条件分支、并行汇聚或超时回退策略。self_steps 里每一步还有一个关键字段 role用来标记执行主体是sys.autoAI代理自动执行、sys.manual人工处理还是ai.suggestAI建议人工确认后再执行。这套标记让引擎在运行时有统一策略判断是否会话是否需要人工介入。设计PDS时我定了一条铁律引擎只解释和执行PDS不直接执行AI模型输出。所有AI生成的流程定义都必须先经过校验器校验PDS结构合法性、组件存在性、参数类型匹配以及权限白名单。校验不通过就返回给AI调整绝不进入执行队列。这个约束避免了无数次线上事故。引擎的状态存储我用了一张流程实例表记录当前执行到哪个步骤、每个步骤的执行状态、每个组件的输出缓存。因为所有状态都是可查询的所以我可以做一个时序回放功能出了问题后把整个流程实例从启动到当前节点的每一步变化还原出来排查效率极高。3. AI能力集成路径与虚拟工作场景落地3.1 自然语言到组件满足AI如何理解平台语义AI服务层的第一大任务是解析用户的自然语言描述并映射到平台组件。这并不只是把文本喂给大模型这么简单关键是怎么把组件当作工具供给模型使用。我的做法是为每个组件生成一份功能说明书包括功能描述、触发事件、属性表、使用限制。这些说明书一起组装进系统提示词System Prompt让模型在理解用户需求时同步参考组件能力。比如用户在对话框输入帮我市区每日10点的项目进度汇报汇总各个负责人提交的状态如果状态更新了就发通知给项目主管。AI先判断这是一段包含触发条件、资源和动作需求的复合意图。经过意图识别和实体抽取后系统拿到了关键要素定时任务每日10点、资源类型项目状态、动作汇总、通知。接下来语言文字解析器将这些要素映射到三个候选组件定时触发器、数据聚合组件、站内消息组件。然后组件选择引擎会计算匹配分推荐置信度最高的组件组合并自动生成PDS流程定义。但这里有个很现实的细节模型可能推荐出一个逻辑上正确、但参数配置不合理的方案。比如它给消息组件填了emit on update的参数导致每次状态有变化就发一条通知一天可能就是几十条。用户显然不想这样。所以我加入了一层阈值约束和规则后置处理。用户在组件参数里可以预览和调整AI生成的值同时我配置了规则引擎去拦截离谱的参数频率太高的通知会被自动合并成每日摘要。这套AI生成规则兜底的组合让落地体验比纯开放式的AI对话靠谱得多。3.2 虚拟工作代理的决策机制虚拟工作代理Virtual Work Agent是平台里最核心的运行时实体。它的工作逻辑是监听流程事件读取当前流程上下文对比组件元数据里的策略声明决策下一步动作。设计上我采用了有限状态机模型每个流程实例有一个当前状态代理只根据当前状态和事件表做状态迁移。这个模型写起来不复杂但保证了AI不会在一次对话轮次里做出跨多状态的不可控决策。代理的能力边界通过三个策略文件声明能力策略允许代理自动执行的组件类型列表。比如消息组件可以自动执行但涉及对外合同的组件必须人工确认。频率策略同一流程实例在单位时间内的自动执行次数上限防止死循环。数据访问策略代理在读取上下文数据时可访问的数据字段白名单避免把敏感字段无意间传给大模型。在具体实现上代理的决策过程我会补充解释一句为什么这样做并且以结构化日志的形式记录每个决策点的触发原因。比如用户看到的通知是系统已自动更新项目状态并通知负责人而日志里记录的是具体规则IDRULE_TASK_STATUS_CHANGED_NOTIFY。这对后续的人工排查和模型迭代都极有价值。3.3 三个典型的虚拟工作落地场景场景一智能审批分理。以前审批单进入系统后需要调度员人工判断分给哪个审批人。现在代理根据审批单类型、金额区间、历史经办人记录自动推荐分单名单然后推送给关系人确认。这个场景上线一周后分单效率提升了大约八成误分率控制在三个百分点以内。场景二周报自动生成与摘要。代理每周五读取各个任务完成情况调用文本生成组件生成初稿再通过规则补充基础数据工时、完成百分比最后推送草稿给员工员工只需要确认或修改。这个场景最关键的一步是数据供给——所有周报依赖的任务数据必须来自组件契约不能是零散字段。组件化的好处在这里体现得很明显因为每一项数据都有标准来源代理才能组合成结构化的文本。场景三异常事件联动处置。比如基础设施监控组件报服务响应时间超阈值代理读取了告警信息结合CMDB数据判断是否属于已知变更窗口如果不是就自动创建一条事件工单同时拉取最近一小时的变更记录供后续分析。整个过程是异步触发的人工可以通过工单系统随时接管。这三个场景覆盖了推荐分单、自动生成和主动处置三个不同类型。验证下来代理在规则明确、边界清晰的任务上表现稳定一旦任务本身定义模糊比如需要主观判断的文章润色效果就很不稳定。所以平台路线是把虚拟工作约束在确定性动作范围内让AI做决策让组件做执行而不是用AI替代人的主观判断。4. 实操过程从组件注册到智能编排的实现要点4.1 组件注册与元数据管理的实现组件注册是整个平台第一道流程我把它做成了一条标准化的管线。新组件的开发者只需要编写一个符合组件接口规范的类然后通过注册接口上传描述文件。描述文件是一个JSON文档包含以下核心字段id全局唯一标识采用命名空间加名称的方式例如 corp.crm.customer_sync。version语义化版本号引擎校验组件兼容性时会使用。inputs输入参数的JSON Schema定义包含必填项、数据类型、默认值。outputs输出结果的JSON Schema定义。events组件可能抛出的业务事件列表。policy执行策略和安全标签。aiDesc给AI模型看的自然语言说明尽量简洁准确。我强调一个细节aiDesc字段写得差会直接导致AI选错组件相同功能的组件如果aiDesc模糊模型就分不清楚差异。比如任务组件和待办组件看起来差不多但前者是通用任务的创建后者集成在审批流里面做待办通知。后来我要求每个字段的aiDesc必须包含使用场景和不适用场景两项描述。这个约束上线后AI推荐准确率提升了大约五个百分点。注册过程中系统会自动做Schema校验、权限申请校验、事件命名冲突检测。注册完成后会生成一份组件沙箱运行环境运行的冒烟测试报告确保组件在隔离环境里可被调用才会转正式状态。4.2 编排引擎与AI服务的接口约定编排引擎和AI服务之间通过任务队列异步通信而不是同步调用。原因是AI推理耗时不定如果同步等待整个流程实例都会被阻塞。所以我设计了编排任务表AI服务把生成的PDS写入任务编排引擎消费任务并推进流程。PDS生成的前置流程是组件检索。用户输入经过向量化后会在组件元数据仓库里做语义检索召回前十个候选组件。然后这些候选组件的详细说明和用户意图一起进入大模型做精排。这一步的双阶段召回设计大幅降低了单次请求的token消耗。实测数据显示在召回到精排的流程里平均每次请求大概能省四到五成的token费用。接口返回结构我固定为{ token_usage: ..., intent: create_scheduled_report, candidate_components: [...], pds: {...}, confidence: 0.92, requires_confirmation: true }其中confidence字段是重点。我设置了一个开关低于0.8的推荐结果不会直接进入执行队列而是先停在AI建议待确认状态等待人工编辑后再走。这个开关上线后团队内部的使用信任度提升很明显。4.3 流程实例执行与状态回放流程实例从一个事件触发开始表单提交、定时器或消息监听代理根据PDS定义创建实例记录。实例表设计成组合数据结构字段包括instance_id、pds_id、current_step_index、global_contextJSONB类型、step_executionsJSONB数组、status、exception_stack。每执行一个组件引擎会先做输入参数校验再调用组件方法把结果写入global_context然后更新current_step_index。如果组件响应超时引擎按policy里的超时处理策略执行重试、跳过、或进入异常分支。状态回放是我调试复杂跨组件流程的利器。实现上我维护了一个独立的事件溯源表任何对实例状态的变更都会追加一条记录。回放的时候只需要按时间顺序重放记录即可。有一次线上发现某个流程重复跑了三次排查时靠回放确认是一个外部系统重试机制导致的重复触发。没有回放功能这种问题大概率要查几天。这里有一个非常实用的提醒全局上下文global_context的大小必须控制。刚开始我没限制结果一次大文件批处理任务把几十MB的数据都塞进去了导致每次解析JSON都卡到怀疑人生。后来我增加了上下文数据字段裁剪机制组件输出必须声明哪些进入全局上下文哪些仅在本地消费。整体性能提升明显内存峰值降了一个量级。5. 上线踩坑实录与技术经验沉淀5.1 典型问题AI推荐流程与真实业务结构不匹配上线后遇到最多的一个问题AI生成的流程逻辑上是通的但匹配的实际业务对象是错的。举个例子用户说提醒我检查预算超支的项目。AI直接找到项目列表组件和财务计算组件生成流程是拉取项目数据、查找预算字段、判断超支、推送提醒。但实际公司业务里超支不是一个字段而是一个计算逻辑实际支出除以预算金额超过阈值才算超支。AI没有业务知识自然不知道这个规则。所以它生成一个看似合理但完全不适用的流程。这个问题后来通过业务知识注入解决。我在组件元数据之外增加了一个业务规则库以规则节点组件的形式存在。规则节点组件内部的逻辑由业务分析师配置组件对外只暴露输入输出。AI流程中可以引用规则组件但不会去猜测规则内部的实现。这相当于把企业的不确定逻辑藏到了组件的黑盒里AI只负责组装不负责发明。5.2 性能挑战虚拟工作代理与LLM的并发瓶颈刚开始推全量流程自动执行时遇到过AI服务超负荷的问题。因为我们采用异步队列模式高峰期消息队列里堆积上千条待解析请求部分流程涉及外部系统查询时需要等待较长时间。编排引擎又是串行处理的一个流程实例卡在网路调用上后续实例全部排队。这个问题的根因是组件的同步联调没有和编排引擎解耦。其实编排引擎本身是异步的可以并行执行不同实例的组件调用但我最初的实现里全局上下文读写用了单把数据库锁导致并行度被锁住了。优化方案很简单把上下文数据按实例拆分到独立存储键锁粒度从全局级别降到了实例级。改完后并发能力提升极其明显。LLM推理环节我采用了结果缓存策略针对高频固定的流程模式比如每日定时汇报在第一次解析完成后就把对应的PDS缓存起来后续不再走大模型。实测缓存命中率最高能到六成大幅节约成本。5.3 一个实用的调试工具流程沙箱回放与模拟器最后一个值是必须做的流程沙箱模拟器。平台目前所有流程实例在正式执行前投资者可在模拟器中运行一遍模拟器使用真实组件但数据源指向测试库。模拟器作用有三个第一验证AI生成的PDS是否全链条可执行避免运行时才发现组件方法不存在。 第二展示流程每一步的输入输出数据变化方便集成业务确认是否符合需求。 第三批量回归测试每次新升级组件版本或修改提示词我都会用预置的核心流程清单跑一遍模拟然后对比步骤数量和数据内容是否有差异。我们这里称它为全量回归流程畅通工程每次版本发布前必跑。在模拟器上面投入的这几天时间非常值。没有它后面每次修改提示词带来的效果回归都要靠人工生产验证风险截然不同。5.4 组件版本管理与AI提示词同步更新的机制组件迭代是常态。v1审批组件在运行半年后需要增加加签功能这直接影响AI对审批组件的描述理解。如果只更新组件代码而不同步更新aiDesc字段就可能出现AI仍然调用旧组件的推荐结果导致流程配置失效。我把组件描述文档的更新纳入发布流程强制要求组件变更涉及接口或功能时必须同时生成aiDesc的新版本。同时在AI服务侧维护一个组件描述版本-模型兼容列表如果组件描述版本过大会导致模型输入token膨胀。所以我采用了动态裁剪方案根据用户意图类型只加载相关业务域的组件描述而不是所有组件一次性塞进提示词。比如用户谈论财务流程就只加载财务域组件的描述。这套动态裁剪机制上线后提示词的平均长度压缩了约六成推理速度也有明显改善。这也是架构层面和算法层面双向配合的效果——单靠调大模型参数是解决不了这类系统级问题的。6. 经验沉淀与实际体会这个项目做下来我对AI驱动虚拟工作这件事有了很具体的认知。虚拟工作成立的前提是工作本身已经被拆解成一个一个可以复用、有明确接口的数字化动作。组件化架构在这个过程中不是可有可无配角反而是主角——它给AI一个有限的、可信的操作空间。没有组件化这层电网存在AI的自由度越大系统的不确定性就越可怕。先收敛边界再谈智能这个顺序不能颠倒。另外我自己的体会是低代码平台与AI的结合难点从来不是某个具体算法的调优而是工程系统之间的对齐。组件元数据的准确性、PDS结构的稳定性、规则兜底的完备性、模拟器回归的常态化每一项看起来都平淡无奇但合在一起才支撑起平台从演示可用走到生产可用。最后分享一个小经验如果你也在做类似项目请尽早设计AI决策日志体系。很多人忽略这个觉得日志只是排查问题用的。但对我来说决策日志是唯一能让我逆向理解模型为什么推荐错以及用户为什么不信任系统的依据。有了它整个系统才能持续演进不然你会永远停留在不断修试错的阶段。