skillFAQ.md 34 KB

数字员工 Skill FAQ

本文档整理自项目迭代过程中的原始问题(原文保留)思考脉络最终落地方案,以及龙虾工作流 / 对话引擎的执行逻辑流程图
docs/skill.md(技术规格)和根目录 skill.md(完整技术手册)配套使用。
最后更新:2026-06-13


文档说明

文档 用途
skillFAQ.md(本文) 原文问题 + 决策 FAQ + 引擎/工作流流程图
docs/skill.md 节点规范、质量阈值、Phase2 运维、代码索引
skill.md 架构总览、模块清单、双端 UI、API 全表

阅读顺序建议:先看 §十五 流程图 建立整体图景 → 再看 §〇 原文问题 与对应章节 FAQ。


〇、原始问题原文记录(按主题)

以下为迭代过程中需求方提出的原话,未改写措辞(仅去掉 @ 引用与图片附件说明)。

0.1 租户 UI 与列表美化

分析 saasadminui 项目里面,看看还有哪些地方查询条件里面还有租户筛选的功能,这个有问题,本来都已经是租户了,这里不应该显示租户的查询,直接就是当前租户的

所有的 saasadminui 项目里面的列表页面的,查询条件,存在行与行之间间距过大,列与列之间没对齐,输入框或者下拉框列没对齐,按钮颜色没有统一,列表样式没有统计,整个项目重新排版,美化;还有很多查询条件的名称字眼之类的需要补齐,比如公司名需要改为公司名称;包括所有的表单也需要美化和优化排版

saas-adminui、saas-companyui 项目的所有列表页面的查询环节都左对齐

将搜索按钮和重置按钮和导入导出的按钮放一排,同时左对齐,要求所有的输入或下拉框长度一致,另外输入框的名称和输入或下拉框之间宽度留 5px

0.2 质量、Redis、延迟

数字员工,我不希望回复降低质量,需要怎么做,还有数据库操作这里需要优化不?相关的只是内容、知识库、上下文什么的是否都做了 redis 没?

按照上面的优化

0.3 AI 模型路由

是否将租户 saas-adminui 里面的 AI 配置统一到 adminui 多模型路由(text / tts / video / image)。各层职责:adminui(admin_ai_model + 场景)、AiSceneDispatcher(sceneCode)、租户 legacy(lobster_model_config)、外呼现状(llmAccountId → cc_llm_agent_account,尚未完全接 outbound_dialogue)。总后台新增外呼场景 outbound_dialogue(AI 外呼对话)及默认模型绑定; 分析一下这个是否可行?

文本 LLM 统一:做。优先收敛 lobster_model_config UI,修正 hint→scene 映射,租户只读 Admin 场景

0.4 质量评分维度

分析 AI 模型回复质量评分维度,是否和下面 10 条又不一样的?(一、合规性 … 十、内容边界管控,全文见对话记录)

改造优化

优化后 10 大评分维度(无重复 + 逻辑通顺)… 看看上面的调整优化是否和前面的对比那些没包含

创作类 scene 加权、KB 范围(已有部分)、KB 矛盾、编造倾向、冗余、分段(从 humanLikeliness 挪部分规则)

质量分≥120 这里的分数改为最新的维度,一个维度是 20 分,看看怎么调整;对应的分值大于等于总分值的 75% 的分值才能通过,大于总分值的 85% 的分值就可以作为知识库保存下来

0.5 Skill / GEPA / 规模化

根据本项目情况,本项目是一个聊天沟通的机器人 agent,根据各种场景实现聊天沟通的能力,分析:Skill 遗传进化 GEPA、自主 Skill 写入、确定性流水线 / 省 token 编排这几个怎么优化

上面的优化后本项目回事怎么样的一个状态

这个针对是单租户最大 5000w 用户的量级,上面这个是否能扛得住,如果没问题就执行优化

上面说的 skill.md 是啥?

将上面的针对数字员工这块的优化更新到 skill.md 里面

0.6 项目边界(三端混淆澄清)

你好还是很混乱,我说的是 adminui 是总后台,不是 saas-adminui,他不负责实际的业务… 数字员工你只需要关心 saas-adminui、saas-companyui 这两个项目…

数字员工:只看这两个租户端,两个租户端都要完整实现龙虾对应的模块,两边都同时实现,实现后后续不需要的直接通过菜单来控制

按照上面这个补齐,同时:上面在租户端的 sys_menu 实现和修复的所有的菜单,都需要再主库里面的 tenant_sys_menu 里面实现,再 company_menu 里面实现和修复的所有的菜单,在主库里面的 tenant_company_menu 里面也要实现

0.7 人工配置 vs 行业启动包

当前数字员工里面的规则和提示词什么、以及敏感词所有的当前数字员工栏目下,包括数字员工执行这个环节,有些边界、提示词、质量评分等,有哪些是需要人工去添加的?

怎么才能减少用户在使用龙虾过程中填写很多内容和资料,是否可以针对所有需要租户输入的,按照租户的行业,来为这些工作流、提示词等上面所有要人工添加的 ai 前期的内容

优化:硬编码行业规则(旅游/医美/教育/保险/通用);同时是否可以根据一些行业默认将上面的添加的作为示例,然后引导用户… 统一的行业启动包 + 一键 bootstrap + 前端向导

所有节点的提示词是否可以根据生产工作流的时候行业来自动做一些规划

按照上面说的优化,目标就是操作人员,只需要简单的填写就可以使用了,直接按照行业的场景和行业相关知识点,来快速建立和补全上面的 Prompt

0.8 工作流能力(多轮 / 千人千面 / 动态节点)

另外龙虾工作是否支持节点编辑,单节点是否支持多轮循环,是否有设置多轮循环的上限次数,是否做到千人千面,然后每一个客户进入到系统后,按照配置的工作流,后续执行过程中,是否根据客户的聊天沟通的维度实现自动的节点动态变化和流转?

那就按照这个来实施,同时要有开关,比如有些租户就希望用户只能按照固定的节点来,不允许流程和节点千人千面

如果不按照每人一条实例改,是否能实现千人千面?

是否可以两种兼容

目前企微用户那个用户走那个龙虾工作流是靠标签来判断的… 分析一下,目前是否是这样的?

0.9 会话层 vs 节点(聊天常态)

那会不会我正在跟客户聊天的过程,客户下单,按说聊天是一个节点,然后客户下单是另外一个节点,然后下单完后客户应该还要继续聊天,这种上面的是否支持,是否可以理解其实聊天是否应该是一个常态,不能作为一个一个的节点,如果把消息沟通作为节点,那就应该是主动给客户发消息的节点?

上面直说了成单,其实有很多节点都是不一单一只是节点,应该这些节点的执行前后都会有聊天,给一个更完整,全面的调整方案;既要解决上面的问题,包含主动给客户发送一些节点消息,又能让聊天一致包含在整个所有节点中执行的过程中

会话层在沟通交流的时候同时执行节点和回复用户消息都在语境里面,不能是一遍再执行节点,结果这边聊天和执行的节点又没关系,这个是否考虑进去了的

执行上面的,看看工作流生成和工作流执行这两个需要怎么调整

0.10 提示词统一管理

分析龙虾工作流,看看那些环节需要提示词,然后在系统菜单页面里面哪里有编辑这些提示词的地方

是否可以对上面的提示词做一个统一的管理和规划,工作流节点的提示词直接在工作流节点里面去管理,其他的是否可以统一做一个统一管理,然后按场景来区分

行业方案引导和工作流节点应该是结合起来,默认是直接通过行业方案引导写入各节点,然后可以编辑各节点的提示词,这样是否更合理

那就按照上面的来调整,同时优化提示词相关页面操作体验

将上面分析出来的全部做到数据库里面固化,然后每一个可以编辑… 上面每一个提示词都是一个固化的一条记录

初始化的时候是否将原来硬编码的内容作为值,初始化进去了

既然所有的提示词都统一管理了,那在每一个对应的提示词的地方是否是动态读取了,还是说只是提示词页面有生效,后端实际没生效?

是否这个页面可以不用 tab,直接将 rag_vector_llm、向量检索 LLM、对话引擎分别写入 key、名称、分类,去掉模型列… 作为初始化

分类里面英文全部改成中文

0.11 工作流生成与模型顺序

分析龙虾工作流,看看生成工作流的时候调用的大模型是否是总后台 adminui 里面的 AI 模型配置里面的场景配置,顺序是否按照图中的模型的顺序来调用的

工作流生成的时候模型里面的生成者和评分者不生效,应该说几个模型都是生成者,没有评分的环节,如果只有一个模型就用一个模型生成,如果有两个模型就用第一个模型来生成,第二个模型来优化补全,如果是三个模型就是第一个生成,后面两个来补全

但是有一个问题,上面的模型顺序不一定是按照豆包、通义千问、元宝来的,是按照场景配置哪里的有一个排序来的

检查目前的生成是不是填写生成工作流生成的相关信息后点击保存,然后保存后由后端定时任务去生成… 不要再前端页面去执行

改成我说的方式哈,同时在工作流模版里面增加一列,状态列… 生成中、生成完成、生成异常

从一个节点到另外一个节点现在是怎么触发的,有哪些触发规则,另外为什么生成的工作流只有 3 个节点

修复上面说的只生成了 3 个节点的问题,同时分析上面的单节点多轮循环聊天、a 节点到 b 节点流转的过程、节点通过动态判断进入动态的下一个不同的节点,这三个方面还有什么不足

0.12 消息渠道与 SOP

数字员工针对实际发送消息的消息发送接口和个微以及企微的实际发送调用发送消息的接口是否一致?(个微/企微 SOP 执行时给用户发消息 vs 龙虾执行时发消息)

分析一下龙虾执行的实际的代码,看看是否和项目说的不一致

对应的前端是否要对不同(例如企微、个微)的消息发送做绑定和区分之类的?

龙虾执行任务聊天沟通的时候,遇到客户发过来的内容有图片的时候可以调用能多模态的模型… 如果遇到的是文件或在视频号之类的,直接转人工

0.13 模块清单与差距

数字员工最重要的几个模块:工作流模版管理、工作流执行、提示词管理、敏感词管理、聊天内容管理、摘要管理、节点进化管理、用户标签画像、接口注册中心、销冠语料学习、向量知识库管理、渠道配置… 看看现在的 saas-adminui、saas-companyui 租户项目的数字员工部分是否包含这些

将上面几个问题最后分析的整理一下给一个完整的方案

按照分析的来做调整

adminui 项目是总后台… 数字员工只保留这几个菜单:工作流模板库、工作流执行任务、实例监控、敏感词库、会话摘要

0.14 测试与验证

现在是否可以模拟测试整个龙虾,从工作流生成到数字员工执行

启动前后端所有的服务… AI 生成 → 画布 → E2E/测试场景 → 引擎执行 → 历史/实例监控

模拟登录… 根据 fs_tenant_cs1.sys_menu / company_menu 里面的数字员工下面的菜单,来做验证… 同时以旅游行业验证工作流生成 → 测试工作流执行任务 → … 自进化、记忆功能、摘要生成、质量评分

上面说的是测试每一个前端的每一个页面… 挨个去测试每一个页面的各种操作,同时模拟添加删除编辑数据… 我看上面说的只是把三个端的菜单页面打开了,里面操作好像没有模拟

希望继续推进「真 UI 点按钮」级别:装 Playwright,对 mgnui + company 的龙虾 17+24 个菜单做 UI 级 CRUD… 修 mgnui 敏感词 company_id bug

继续上面的测试,我说的是所有的不是只有数字员工的页面,其他所有的菜单的 UI 级的都测试一遍


一、项目边界与角色划分

Q1:数字员工应该改哪些前端/后端?

【原文】

你好还是很混乱,我说的是 adminui 是总后台,不是 saas-adminui… 数字员工你只需要关心 saas-adminui、saas-companyui 这两个项目…
数字员工:只看这两个租户端,两个租户端都要完整实现龙虾对应的模块,两边都同时实现,实现后后续不需要的直接通过菜单来控制

最终方案

前端 后端 职责
总后台 adminui fs-saas-admin(8003) 仅保留:工作流模板库、执行任务、实例监控、会话摘要、敏感词库(主库)
租户管理端 saas-adminui / saas-mgnui fs-saas-admin(8004) 龙虾全模块(菜单裁剪)
销售公司端 saas-companyui fs-saas-company(8006) 与租户端对称,company_menu 控制

Q2:菜单改租户库后,主库模板要不要同步?

【原文】

按照上面这个补齐,同时:上面在租户端的 sys_menu… 都需要再主库里面的 tenant_sys_menu 里面实现… company_menu… 在主库里面的 tenant_company_menu 里面也要实现

最终方案sys_menutenant_sys_menucompany_menutenant_company_menu;Flyway + TenantUpgrade + 默认角色授权 SQL。


Q3:租户端列表里为什么还要「选租户」?

【原文】

分析 saasadminui 项目里面,看看还有哪些地方查询条件里面还有租户筛选的功能,这个有问题,本来都已经是租户了,这里不应该显示租户的查询,直接就是当前租户的

最终方案tenantScopeMixin + utils/tenantScope.jsapply-tenant-scope-ui.js 批量清理。adminui 运维页保留租户筛选。


二、质量、性能与 Redis

Q4:如何在不明显降质的前提下优化延迟?

【原文】

数字员工,我不希望回复降低质量,需要怎么做,还有数据库操作这里需要优化不? 相关的只是内容、知识库、上下文什么的是否都做了 redis 没?

最终方案lobster.latency.mode(fast/balanced/quality);LobsterContextCacheService;Replay 热环 + 异步学习;合规/敏感词始终执行。


Q5:质量评分维度怎么对齐?

【原文】

质量分≥120 这里的分数改为最新的维度,一个维度是 20 分… ≥75% 通过,≥85% 入库

最终方案:8 维 × 20 = 160;120 通过 / 136 入库;合规 severity≥2 可封顶。


三、AI 模型路由

Q6~Q7:模型统一与工作流生成调用顺序

【原文】

文本 LLM 统一:做。优先收敛 lobster_model_config UI…
工作流生成的时候… 几个模型都是生成者,没有评分的环节… 顺序是按照场景配置哪里的排序来的
点击保存,然后保存后由后端… 去生成… 状态列:生成中、生成完成、生成异常

最终方案:见 §十五.2 工作流生成流程图LobsterWorkflowGenerateAsyncService 异步执行;模型数 1/2/3+ 对应生成/补全链。


四、Skill / GEPA / 进化学习

Q8:Skill 遗传进化、自主写入、省 Token 流水线怎么优化?5000 万用户扛得住吗?

【原文】

根据本项目情况… 分析:Skill 遗传进化 GEPA、自主 Skill 写入、确定性流水线 / 省 token 编排这几个怎么优化
这个针对是单租户最大 5000w 用户的量级,上面这个是否能扛得住,如果没问题就执行优化

最终方案

机制 说明
GEPA 离线进化 replay ≥136 分 → skill_staged(source=GepaEvolution)
写入模式 lobster.skill.write-mode:staged / auto / disabled
异步学习 LobsterLearningAsyncService → 线程池或 RocketMQ
省 Token 3 摘要 + 1 全文节选(120/500 字)
规模化 Replay 热环 500 + 归档;Phase3 分库分表

Q9:skill.md 是什么?

【原文】

上面说的 skill.md 是啥?

:项目内数字员工产品/技术规格书(非 Cursor Agent Skill)。见 docs/skill.md


五、提示词体系

Q10~Q12:统一管理、行业引导、会话层配合

【原文】

是否可以对上面的提示词做一个统一的管理和规划…
将上面分析出来的全部做到数据库里面固化…
是否这个页面可以不用 tab… 去掉模型列…
前面针对所有的调用模型的地方(除工作流节点外的)做了统一一个地方提示词的管理,现在上面的调整后,现在的提示词该怎么做?

最终方案

类型 存储 管理入口
节点 Prompt lobster_prompt_config 画布 visual.vue
引擎级 Prompt lobster_system_prompt 提示词管理页 Key/名称/分类
行业规则 Catalog + bootstrap 行业启动包

LobsterEnginePromptCatalog 初始化硬编码默认值;运行时 SystemPromptService 动态读 DB。会话层 SideTask 完成后仍用同一套引擎 Prompt + Turn 语境合并。


六、工作流生成与执行

Q13~Q15:模块差距、多轮/千人千面、节点触发

【原文】

数字员工最重要的几个模块… 分析上面的看看差距?
一条绑定多个标签 ⚠️ 未做… 这个做一下
从一个节点到另外一个节点现在是怎么触发的… 为什么生成的工作流只有 3 个节点

最终方案:双端模块补齐;batch-bind 多标签;8 节点骨架;触发规则见 §15.8lobster.personalization.enabled 可关千人千面。


七、消息渠道与 SOP

Q16~Q17

【原文】

数字员工针对实际发送消息… 和个微以及企微的实际发送调用发送消息的接口是否一致?
遇到客户发过来的内容有图片… 文件或在视频号… 直接转人工

最终方案:见 §15.10;图片走 image_recognition;文件/视频号转人工。


八、记忆、摘要、自进化

Q18~Q19

【原文】

看看现在本项目数字员工的执行的环节是否具备记忆功能?
分析一下数字员工自动进化功能是否真实实现,能否完整验证跑通

最终方案:多轮 / 摘要 / 画像 / VariableStore / replay+Skill 分层;Phase2 smoke + E2E 验证。


九、与 OpenClaw / Hermes 对比

【原文】

分析 saasadminui、saasui 项目整个数字员工和 openclaw、Hermes 做能力对比

结论:本项目是私域 38 节点工作流 + 8 维质检 + GEPA;OpenClaw Lobster 是 CLI 流水线工具,同名不同物。


十、UI 规范(租户双端)

【原文】

所有的 saasadminui 项目里面的列表页面… 重新排版,美化… 公司名需要改为公司名称

最终方案list-page.scss;查询左对齐;控件等宽;批量 label 脚本。


十一、测试与验证

Q20

【原文】

上面说的是测试每一个前端的每一个页面… 模拟添加删除编辑数据… 只是把三个端的菜单页面打开了,里面操作好像没有模拟
希望继续推进「真 UI 点按钮」级别:装 Playwright…

最终方案

脚本 用途
scripts/e2e/all-menus-ui.spec.js 全菜单 UI 操作
scripts/e2e/lobster-ui.spec.js 龙虾 CRUD
scripts/portal-page-operations-e2e.mjs API 级 CRUD
scripts/lobster-travel-full-e2e.mjs 旅游全链路

测试账号:cs1 / admin / Admin@123456(8090);cs1 / 测试企业 / cq654321!!(8083)。


十五、数字员工逻辑流程图

以下流程图基于当前代码主路径:LobsterWorkflowGenerateAsyncServiceLobsterWorkflowExecutorImplLobsterEvolutionEngineImplLobsterInboundReplyOrchestratorLobsterTurnProcessor

15.1 总体架构(三端 + 核心模块)

flowchart TB
    subgraph UI["双端 UI"]
        MGN["saas-adminui / saas-mgnui"]
        CO["saas-companyui"]
        ADM["adminui 运维"]
    end

    subgraph API["后端 API"]
        FA["fs-saas-admin :8004"]
        FC["fs-saas-company :8006"]
    end

    subgraph Core["fs-service 龙虾核心"]
        EX["LobsterWorkflowExecutorImpl\n工作流执行"]
        EV["LobsterEvolutionEngineImpl\n12步进化对话"]
        TP["LobsterTurnProcessor\n会话层 Turn"]
        IO["LobsterInboundReplyOrchestrator\n入站统一入口"]
        GEN["MultiModelWorkflowGenerator\n工作流生成"]
        QA["QualityScoringService\n8维质检"]
        LE["TenantLearningEngine\n异步学习/Skill"]
    end

    subgraph Store["存储"]
        DB[(租户库 MySQL)]
        RD[(Redis 上下文缓存)]
        VDB[(Qdrant 向量库)]
    end

    subgraph Channel["消息渠道"]
        QW["企微 MessageChannel"]
        GW["个微 MessageChannel"]
        TEST["TestMessageChannel E2E"]
    end

    MGN --> FA
    CO --> FC
    ADM --> FA
    FA --> Core
    FC --> Core
    IO --> EX
    EX --> EV
    EX --> TP
    EV --> QA
    EV --> LE
    Core --> DB
    Core --> RD
    Core --> VDB
    EX --> Channel

15.2 工作流生成(异步任务)

对应类:CompanyWorkflowLobsterServiceImplLobsterWorkflowGenerateAsyncServiceMultiModelWorkflowGeneratorImpl

flowchart TD
    A[前端:填写行业/角色/公司/需求] --> B[点击保存]
    B --> C[写入 lobster_generate_record\nstatus=生成中 genStatus=0]
    C --> D[@Async executeGenerate]
    D --> E[读取 adminui 场景模型列表\n按 sort 排序]
    E --> F{模型数量}
    F -->|1 个| G[单模型生成 JSON]
    F -->|2 个| H[模型1 生成 → 模型2 优化补全]
    F -->|3+ 个| I[模型1 生成 → 模型2..N 依次补全]
    G --> J[按行业 LobsterIndustryCatalog\n补节点骨架与 node Prompt]
    H --> J
    I --> J
    J --> K[LobsterNodePromptPlanner\n按品牌变量补全各节点 Prompt]
    K --> L{成功?}
    L -->|是| M[写入 company_workflow_lobster\n+ nodes + conversationModel]
    M --> N[status=生成完成 genStatus=1]
    L -->|否| O[status=生成异常 genStatus=2\n支持重新生成]

15.3 工作流执行全链路(绑定 → 实例 → 对话)

flowchart TD
    subgraph Setup["配置阶段"]
        T1[工作流模板\nvisual.vue 画布] --> T2[标签-工作流绑定\nbatch-bind 多标签]
        T2 --> T3[execution-config\n千人千面开关/渠道]
    end

    subgraph Trigger["实例创建"]
        U1[客户打标 / 入站消息 / 定时触发] --> U2[创建 LobsterWorkflowInstance\n或复用已有 instanceId]
        U2 --> U3[LobsterTurnProcessor.initializeTurnContext\n加载 conversationModel]
    end

    subgraph Runtime["运行阶段"]
        M1[客户消息 inbound] --> M2[LobsterInboundReplyOrchestrator]
        M2 --> M3{有实例?}
        M3 -->|是| M4[executeNextNode\n唯一实例路径]
        M3 -->|否| M5[按策略 skip 或 Prompt 兜底]
        M4 --> M6[deliverMessage → MessageChannel\n企微/个微/Test]
    end

    Setup --> Trigger
    Trigger --> Runtime

15.4 入站消息编排(避免重复 AI 调用)

对应类:LobsterInboundReplyOrchestrator(企微 Hook A 路径 / 个微 B 路径均汇入)

flowchart TD
    IN[渠道入站: 文本/图片/文件] --> MT{消息类型}
    MT -->|图片| VIS[LobsterMediaMessageService\n多模态识图 image_recognition]
    MT -->|文件/视频号| HM[直接转人工]
    MT -->|文本| POL[LobsterExecutionPolicy\n解析实例与渠道]
    VIS --> POL
    POL --> INST{resolveInstance}
    INST -->|有 instanceId| EX[workflowExecutor.executeNextNode]
    INST -->|无| FB{allowPromptFallback?}
    EX --> REP[extractReply 提取回复]
    REP --> SEND{已发送?}
    SEND -->|executor 已 deliver| SKIP[Hook 不再重复发]
    SEND -->|有 reply| CH[MessageChannel.send]
    FB -->|是| PF[Prompt 兜底生成]
    FB -->|否| SK[skipped]

15.5 executeNextNode 内部路由(工作流执行器)

对应类:LobsterWorkflowExecutorImpl.executeNextNode

flowchart TD
    START[executeNextNode\ncompanyId, instanceId, customerReply] --> LOAD[加载 instance / nodes / currentNode]
    LOAD --> VAR[合并 VariableStore 变量\n初始化 collectedVariables]
    VAR --> CR{customerReply 非空?}

    CR -->|是| R1[记录 inbound 日志\nchatRecordSync]
    R1 --> R2[媒体分流: 识图 / 转人工]
    R2 --> R3[SemanticAnalyzer 语义分析]
    R3 --> R4[LobsterTurnProcessor.processInboundTurn\nGoal/Stage/SideTask → variables]

    CR -->|否| ACTIVE[主动推进: 无客户消息]
    R4 --> ROUTE{当前节点类型}
    ACTIVE --> ROUTE

    ROUTE -->|COLLECT_INFO 旧版| CI[handleCollectInfo]
    ROUTE -->|TRANSFER_HUMAN| TH[handleTransferHuman]
    ROUTE -->|max_rounds 未达上限\n非聊天节点| MR[重复节点消息停留]
    ROUTE -->|AI_PROCESS + MultiTurn| MT[MultiTurnDialogueManager\n未完成则 stayOnNode]
    ROUTE -->|交互型节点| EV[LobsterEvolutionEngine.evolve\n12步 AI 回复]
    ROUTE -->|HTTP/RAG/CODE 等| DN[DynamicNodeExecutor\n38 类型节点]

    EV --> NEXT{nextNodeCode / 条件边}
    MT -->|完成| NEXT
    DN --> NEXT
    CI --> NEXT
    TH --> END1[转人工结束/暂停]

    NEXT --> RES[resolveNextNodeIndex\nConditionEvaluator]
    RES --> SKIP{SideTask 意图节点\n且无 inbound?}
    SKIP -->|是| SKIPN[skipIntentSideTaskNode]
    SKIP -->|否| NN[进入下一节点\n或 completeInstance]
    NN --> DEL[deliverMessage 发送 outbound]
    DEL --> RET[返回 AjaxResult\n含 reply / stayOnNode / instanceId]

15.6 进化引擎对话逻辑(12 步 + 异步后置)

对应类:LobsterEvolutionEngineImpl.evolve单条客户消息的核心 AI 链路

flowchart TD
    S0[客户消息 + currentNodeCode] --> S1{MultiTurn 未完成?}
    S1 -->|是| MT[processDialogue 短路返回]
    S1 -->|否| S2[PipelinePlan\nlatency.mode 解析]

    S2 --> S3[ContextAssembler 9源上下文\n画像/多轮/KB/变量/合规/Skill…]
    S3 --> S3b[TurnProcessor.mergeTurnContext\nStage/Goals/SideTask 注入 Prompt]
    S3b --> S4{Pipeline: 变量 LLM?}
    S4 -->|是| S4a[summaryGenerator.extractConversationVariables]
    S4 -->|否| S5
    S4a --> S5[DynamicNodeAdjuster\n意图/情感/转人工/下一节点建议]

    S5 --> S5a{转人工?}
    S5a -->|是| HT[IdentityHiding 安全转人工话术\nnext=human_takeover]
    S5a -->|否| S6{Pipeline: 动态节点?}
    S6 -->|是| S6a[enrichWithDynamicNode 千人千面]
    S6 -->|否| S7

    S6a --> S7[PromptManager + IdentityHiding\nsystem + instruction + context]
    S7 --> S8[MultiModelRouter AI 生成]
    S8 --> S9{工具调用?}
    S9 -->|是| S9a[ToolCallFramework 执行\nSideTask recordToolOutcome\n带结果二次生成]
    S9 -->|否| S10
    S9a --> S10[QualityScoringService.scoreWithRetry\n8维 75% 通过 / 可重生成]

    S10 --> S11[ComplianceService 合规分级]
    S11 --> S12[SensitiveWordService 敏感词\n高风险→转人工]
    S12 --> S13[IdentityHiding.hideIdentity]
    S13 --> S14[更新 VariableStore / nextNodeCode]
    S14 --> S15[summaryGenerator.generateSummaryAsync]
    S15 --> OUT[返回 EvolutionResult.reply]

    OUT --> ASYNC[POST_PROCESS 异步线程池]
    ASYNC --> A1[learnCustomerHabit]
    ASYNC --> A2[writeDialogueState]
    ASYNC --> A3[profileEnrichment]
    ASYNC --> A4[recordEvolutionInteraction → Skill/replay]
    ASYNC --> A5[Redis contextCache 失效]

9 源上下文(ContextAssembler):用户画像、最近对话、多轮状态、知识库 RAG、实例变量、合规规则、事实记忆、断点续聊、学习策略(Skill 摘要)。


15.7 会话层:聊天常态 + SideTask(与节点同语境)

对应类:LobsterTurnProcessor + LobsterSideTaskExecutor

flowchart LR
    subgraph Conv["会话层 conversationModel"]
        ST[workflowStage 阶段]
        GL[goals 采集目标]
        SK[SideTask 定义\n成单/打标/支付…]
    end

    MSG[客户 inbound 消息] --> SEM[语义 intent]
    SEM --> TP[processInboundTurn]
    TP --> G[updateGoalsFromMessage]
    G --> STG[maybeAdvanceStage]
    STG --> SIDE[tryExecuteSideTasks\n匹配 triggerIntents]
    SIDE --> AO[写入 _actionOutcomes\nActionOutcome]
    AO --> HINT[syncStagePromptHint\n注入当前节点 Prompt 语境]
    HINT --> VAR[(instance variables)]
    VAR --> EV[LobsterEvolutionEngine\n同轮读取 mergeTurnContext]
    EV --> REPLY[AI 回复体现 SideTask 结果\n如刚完成下单/打标]

设计要点(回应原文「聊天与节点不能脱节」):

  • 被动回复:始终走会话层 + 进化引擎,携带 Stage/Goals/ActionOutcome。
  • 主动触达:定时/节点推进时 customerReply=null,执行节点模板消息。
  • 业务动作:SideTask 在 inbound 回合触发,结果写入变量后再生成回复。

15.8 节点流转触发规则

flowchart TD
    N[当前节点] --> T1{MultiTurn 完成?}
    T1 -->|否| STAY[stayOnNode 继续聊]
    T1 -->|是| T2{Evolution nextNodeCode?}
    T2 -->|有| JUMP[跳转到指定 nodeCode]
    T2 -->|无| T3{条件边 ConditionEvaluator\n eq/contains/regex/between…}
    T3 -->|满足| EDGE[沿边进入下一节点]
    T3 -->|否| T4{默认顺序 nextIndex+1}
    T4 --> T5{SideTask 意图节点\n且无 inbound}
    T5 -->|是| SKIP[skipIntentSideTaskNode]
    T5 -->|否| EXEC[执行下一节点业务\nCART/COUPON/GIFT/API…]
    JUMP --> EXEC
    EDGE --> EXEC
    EXEC --> T6{末节点?}
    T6 -->|是| DONE[completeInstance]
    T6 -->|否| WAIT[等待 inbound 或定时 trigger]

为何曾只生成 3 节点:行业规则与生成 Prompt 过短 → 已改为默认 8 节点骨架 + 行业 Catalog + 异步多模型补全。


15.9 质量评分与学习闭环(复制 / 进化逻辑)

flowchart TD
    REPLY[AI 最终回复] --> SC[8维评分 0-20\nrelevance/professionalism/…]
    SC --> P1{≥120 75%?}
    P1 -->|否| RG[重生成 最多1次\nquality 模式]
    P1 -->|是| OK[qualityPassed]
    RG --> P1
    OK --> CMP[合规 + 敏感词]
    CMP --> SEND[发送客户]
    SEND --> REC[recordEvolutionInteraction 异步]
    REC --> RPL{≥136 85%?}
    RPL -->|是| STG[skill_staged / replay_buffer]
    RPL -->|否| LOG[仅 event_log]
    STG --> APR{人工审核 approve?}
    APR -->|是| SKL[pattern_type=skill\n进入 ContextAssembler]
    SKL --> CTX[后续对话渐进披露\n3摘要+1全文]
    STG --> GEPA[夜间 GEPA 批处理\nLobsterGepaEvolutionService]
    GEPA --> STG

15.10 消息发送复用(龙虾 / 个微 SOP / 企微 SOP)

flowchart TD
    subgraph Entry["业务入口"]
        L[龙虾 executeNextNode / deliverMessage]
        SOPQW[企微 SOP 发送]
        SOPGW[个微 SOP Plan B wx_sop]
    end

    subgraph Adapter["渠道适配层"]
        MC[MessageChannel 接口]
        QWA[QwMessageChannelAdapter]
        GWA[GwMessageChannelAdapter]
    end

    subgraph SDK["底层 IM SDK / Hook"]
        QWH[企微 Hook API]
        GWH[个微客户端 API]
    end

    L --> MC
    SOPQW --> QWA
    SOPGW --> GWA
    MC --> QWA
    MC --> GWA
    QWA --> QWH
    GWA --> GWH

结论(回应原文):业务入口不同,发送适配器层统一MessageChannel;龙虾与 SOP 底层 SDK 一致、调用链不同


15.11 延迟档位对流水线的影响

flowchart LR
    MODE[lobster.latency.mode] --> FAST[fast\n关变量LLM/动态节点/Skill\n仅规则质检]
    MODE --> BAL[balanced 默认\n开Skill 评分链跳过重生成]
    MODE --> QUA[quality\n全开 + 重生成]
    BAL --> PLAN[LobsterEvolutionPipelinePlanResolver]
    QUA --> PLAN
    FAST --> PLAN
    PLAN --> EV[EvolutionEngine 各 Step 开关]

十六、核心代码索引(流程图对照)

流程 主类
工作流生成 LobsterWorkflowGenerateAsyncService, MultiModelWorkflowGeneratorImpl
工作流执行 LobsterWorkflowExecutorImpl
入站编排 LobsterInboundReplyOrchestrator, LobsterQwEvolutionBridge
会话 Turn LobsterTurnProcessor, LobsterSideTaskExecutor
进化对话 LobsterEvolutionEngineImpl
上下文 ContextAssemblerImpl, LobsterContextCacheService
质检 QualityScoringServiceImpl
学习 TenantLearningEngineImpl, LobsterGepaEvolutionService
节点类型 DynamicNodeExecutorImpl(38 类型)
提示词 SystemPromptService, LobsterEnginePromptCatalog

十七、已修复的典型问题(FAQ 速查)

现象 原因 修复
租户不存在: 338 admin 用 sales companyId 当 tenant LobsterAdminTenantSupport
敏感词 company_id null mgnui 未传 resolveSensitiveCompanyId()
collectedVariables NPE 多轮未初始化 Executor / MultiTurn 初始化
lobster_prompt_config 不存在 租户库缺表 migration + schema-fix 脚本
chat-manage 编译失败 缺 aiChatQuality 从 mgnui 拷贝
AI 生成 genStatus=0 异步 worker/LLM LobsterWorkflowGenerateAsyncService 消费
travel E2E 超时 同上 非前端 recordId 问题

十八、决策原则

  1. 双端对称:saas-adminui 与 saas-companyui 同时实现。
  2. 禁止桥接:缺接口在对应后端原生实现。
  3. DB 固化:Prompt/配置进库,硬编码仅 catalog 默认值。
  4. 质量门槛:75% 通过、85% 入库。
  5. 热路径异步:学习、摘要、GEPA 不阻塞回复。
  6. 会话与节点分离:聊天是常态层,节点是主动业务动作。
  7. 同语境:SideTask 结果写入 variables 后再 AI 回复。
  8. 可关千人千面lobster.personalization.enabled

十九、相关命令

cd d:\ylrz_saas_new\java
mvn install -pl fs-service,fs-saas-admin,fs-saas-company -am -DskipTests

cd d:\ylrz_saas_new\scripts
npm run test:e2e:all-menus

修订记录

日期 内容
2026-06-13 初版 FAQ
2026-06-13 增补 §〇 原文问题;§十五 工作流/对话/进化/发送 11 张流程图