AI工厂管家多人协作与知识库沉淀设计：审批留言、8D协作与L1学习样本的工程实践

AI 工厂管家 v6.79/v6.85 通过三个高价值场景把系统从"单人对话操作"升级为"多人协作平台"：审批留言让审批人与申请人在同一上下文往返、8D 报告聚合跨部门讨论并落库进知识库、知识库沉淀把会话问答经 L1 审批变成可检索资产，三场景均已实施并通过 741 项单测回归。本文基于《多人协作能力落地方案 v1.1》，详解三场景的表结构、代码改动与端到端验证数据，供制造业 LLM 系统的协作能力设计参考。

一、规格补充：从单人操作到多人协作

多人协作能力是规格书 v6.77 未规定的内容，本方案作为补充项把规格书同步到 v6.79。三个场景的定位如下表：审批留言是过程性数据（不进知识库），8D 协作是结构化质量资产（进知识库 category=质量报告），知识库沉淀本就是知识库能力（复用既有 L1 审批）。设计边界明确：不改 8 个 Agent 内核、不改意图识别、不改审批链推进逻辑、不引入多人会话模型，全部改动收敛在"新表 + 特定分支拦截 + 会话聚合"三处。

场景	内容	进知识库	依赖多人会话	状态
① 审批留言	审批人留言/补充意见，与申请人同上下文往返	否（过程性数据）	不依赖	已实施（v6.85）
② 8D 协作	8D 报告关联讨论会话、聚合成员与内容，生成后落库进知识库	是，category=质量报告	部分依赖	已实施（v6.79）
③ 知识库协作沉淀	录入从"最近一轮"升级为"会话近 N 轮聚合 + L1 审批后入库"	是（本就是知识库）	不依赖	已实施（v6.79）

二、场景①审批留言：意见与审批推进同上下文

审批留言的落点是新增的 workflow_comments 表（迁移 057），按实例与审批步骤索引，外键关联流程实例与用户表，保证留言可追溯到人、可定位到审批节点。

CREATE TABLE IF NOT EXISTS workflow_comments (
    comment_id  SERIAL PRIMARY KEY,
    instance_id INTEGER NOT NULL REFERENCES workflow_instances(instance_id),
    step        INTEGER DEFAULT 1,                      -- 留言所属审批步骤
    author_id   VARCHAR(32) REFERENCES users(user_id),  -- 留言人工号
    content     TEXT NOT NULL,                          -- 留言内容
    created_at  TIMESTAMP DEFAULT NOW()
);
CREATE INDEX IF NOT EXISTS idx_wf_comments_instance
    ON workflow_comments(instance_id, step);

代码改动共 3 处：workflow_enforcer（runtime 双副本）新增 add_comment/list_comments，并把 workflow_comments 加入查询表白名单防注入；coordinator 在 awaiting_approval 分支拦截留言；knowledge_assistant 渲染流程单据时附留言列表。关键工程细节是留言识别条件：首版只把"仅追问类意图"识别为留言，实测"请补充住宿发票和审批理由"因含"发票"触发 financial_query 被抢走路由，v6.85 修正为待审批阶段除 confirm/cancel 与查询动词开头外均视为留言。HTTP 端到端验证：发起报销（实例 32）→ 留言"请补充住宿发票和审批理由"（回复"已记录审批意见"）→ 再留言"已补充，请查收" →「同意」推进至第 2 步 →「显示实例32」渲染"💬 审批意见（2 条）"；4 条留言落库、外键关联正常、无孤儿记录。

三、场景②8D协作：讨论聚合与质量报告落库

8D 协作把质检 Agent 的 8D 报告生成从"模板填空"升级为"团队协作沉淀"：生成时从会话历史中抽取含质量关键词（缺陷/原因/根因/划痕/毛刺/尺寸/不良/异常等）的最近 3 条用户发言，聚合进 D2 问题描述与 D4 根因分析；D1 团队取协作成员前 6 人（单成员补默认角色）。报告生成后同时落库 quality_reports（迁移 058）与知识库 knowledge_documents（category=质量报告，source=8D）。

表	关键字段	设计要点	实测数据
workflow_comments（057）	comment_id / instance_id / step / author_id / content	按实例+步骤索引，FK 双关联	4 条留言落库，无孤儿记录
quality_reports（058）	report_id / session_id / product_code / content JSONB / members JSONB	content 存 D1-D8，members 存协作成员，双索引	8D-20260815175119（A-202）
knowledge_documents	category=质量报告 / source=8D	复用既有知识库向量化通道	doc_id=77 已向量化

这个场景踩过一个典型坑：首版入库用 get_knowledge_base() 单例（无 db 注入）导致 _persist_to_db 静默跳过、8D 报告未落知识库，v6.85 修正为显式注入 KnowledgeBase(db=...)，复验 doc_id=77 类型为质量报告。教训是：涉及持久化的组件必须显式注入数据库依赖，不能依赖隐式单例。

四、场景③知识库协作沉淀：会话聚合与L1审批

知识库沉淀把"用户单条录入"升级为"会话近 3 轮问答聚合 + L1 审批后入库"：聚合器从 session_history 抽取"用户提问 + 知识库外回答"的问答对，title 取问题、content 合并问答；聚合结果写入 training_data（intent=kb_entry、approved=False、metadata 记录 title/source/category/qa_count），复用既有 L1 审批通道，由 manager/admin 复核（approved=True）后经原通道入库——审批机制完全现成，零新增审批代码。端到端验证："精益生产是什么 → 5S 管理是什么意思 → 和知识库补充到录入"聚合 2 轮问答、提交 L1 会话学习样本 712（approved=False 待审）。知识库沉淀的价值在于把散落在对话里的隐性知识变成可检索的企业资产，且每一条入库都经过人工审批，防止 LLM 幻觉污染知识库。

图 1 AI 工厂管家多人协作三场景设计（v6.79 / v6.85 已实施）

五、迁移清单与风险评估

两项迁移（057 workflow_comments、058 quality_reports）均已应用；coordinator、workflow_enforcer 的 runtime 双副本同步到 agent-runtime-os v1.6.57 并更新 README/API_SPEC/回归清单，场景②③为业务侧改动无需版本号变更。单测回归 741 项通过（6 个历史遗留失败与本次改动无关）。三场景的风险与对策如下表，核心原则是"拦截点收窄、聚合加关键词过滤、检索可按需隔离"。

风险	场景	对策
留言输入被 pending 延续吞成字段	①审批留言	只在 awaiting_approval 阶段拦截，且非 confirm/cancel 才进留言
8D 缺陷信息全局可检索	②8D协作	知识库检索侧按 category/source 过滤（改 _retrieve 一处，可选增强）
聚合混入无关轮次	③知识库沉淀	关键词过滤（产品/缺陷/知识库外标记）

结语

AI 工厂管家多人协作的三场景设计证明，LLM 工作流系统的协作能力不必重构 Agent 内核：审批留言靠"待审批分支拦截 + 新表落库"即可实现，8D 协作靠"会话聚合 + 双库落库"沉淀质量资产，知识库沉淀靠"复用 L1 审批"把对话变成可审计知识。两条工程纪律值得复用：涉及持久化必须显式注入数据库依赖；拦截条件要按真实输入回归收紧，避免被业务词（如"发票"）抢走路由。三场景均已在真实服务器端到端验证并随 v6.79/v6.85 交付。

本文基于《多人协作能力落地方案 v1.1》（2026-08-15，对应 v6.79 / v6.85，审批留言 · 8D 协作 · 知识库沉淀三场景）整理优化。