流程副驾 · Process Copilot
把企业散落在文档、邮件、Excel、群聊里的业务流程，抽取成标准化、可上线的定义；再用运行数据反哺设计——设计、运行、分析、优化连成一个能自我改进的闭环。
1背景与问题
企业要把线下文档、邮件、Excel 里的业务流程沉淀成标准化线上流程，长期依赖人工逐条梳理——慢、易漏、口径不一。非结构化输入形态各异（Word、邮件、表格、聊天截图），抽取成本高；抽取结果还要能机器校验、能对齐企业既有的流程规范与合规红线。更根本的是，流程一旦上线，就缺乏"运行得好不好"的反馈：提效与堵点数据没有回流到设计侧，优化全凭经验。
需要说明的是，这是我个人从 0 独立构建的项目，不隶属任何公司。里面的痛点与场景，都提炼自我在国泰海通证券做流程数字化与效能看板产品期间一线遇到的真实问题。我想探索：如果用 AI-native 的方式把"设计 → 运行 → 分析 → 反哺"这套闭环重新做一遍，会是什么样——于是自己完整验证了出来。
2我的角色与贡献
个人项目，从 0 独立完成全部工作：问题定义 → 闭环架构 → LangGraph 抽取流水线 → 会话式修改 → 规则 RAG 合规校验 → 评测体系 → 效能分析 → 发起向导 / 运维 / 管理等参与者 agent → 前端产品的全栈实现。整套系统只有"抽取"和"业务校验"两处用到 LLM，其余全是确定性代码。
3系统全景：一个闭环
各模块不是并列的功能清单，是一个自我改进的环：设计 Agent 把多源材料抽成标准定义 → 薄运行时把流程跑起来、产出结构化事件 → 效能分析 Agent 从事件里算指标、识别堵点 → 优化建议反哺回设计侧重新设计。一套规则知识库（RAG）在设计、分析、副驾三处被复用为依据。
4各 Agent 详解
系统由五个各司其职的 agent 组成，外加一套抽取评测 harness 和一层共享的规则知识库。下面逐个讲清楚：目标用户、场景、功能架构、以及信息处理链路。
4.1流程设计 Agent
- 目标用户
- 流程 owner（来自各业务部门，对线上流程设计并不专业）。
- 场景
- 新流程落地——把制度文档、部门邮件、Excel、聊天截图等多源材料抽取生成初稿；流程重构——组织或合规变动带来的大改，重新输入材料再设计；日常微调——对话式增删环节 / 字段、调整属性，新增环节自动给合规提醒；发布——上架到发起页，或经翻译层发布到飞书以验证与真实引擎对接。
- 功能架构
- LangGraph 编排的 6 节点抽取管线（其中"抽取""业务校验"两个 LLM 节点，其余全确定性）+ 会话式修改内核（typed 编辑工具 + 编辑后校验 + diff / undo）。
- 信息处理链路
- 多源 source 摄取（含图片转录）→ 结构化抽取 LLM → 结构校验（schema / 字段引用 / 路径目标）→ 业务缺口校验 LLM → 落标准定义草稿；校验不过则回边重试抽取。
4.2流程发起向导 Agent
- 目标用户
- 普通员工——流程发起人。
- 场景
- 不知道该走哪个流程办事——描述诉求，agent 帮你定位流程，解决"用哪个流程"的困惑；咨询要准备什么信息材料、会经过哪些环节、大概要走多久；表单字段该怎么填。
- 功能架构
- 单轮问答 agent——诉求理解 + 流程库检索 + 基于流程定义的确定性路径预演。
- 信息处理链路
- 理解诉求 LLM → 匹配候选流程 → 读流程定义预演路径 / 材料 / 时长（确定性）→ 生成引导答复。
4.3流程运维 Agent
- 目标用户
- 流程发起人 / 审批人、流程管理员。
- 场景
- 审批人流程提不下去——路径设计没覆盖某种情况（设计时的遗漏），需要跳过环节或退回作为临时解。传统做法要联系流程客服 / 后台人工判断并到管理后台跳转；这里 agent 依据流程相关的制度规定，在允许范围内给出并执行最优解，符合制度即直接处置，不符合则升级人工、生成运维授权请求转流程 owner / 管理员复核后执行。改字段、改意见等诉求同此逻辑。
- 功能架构
- 确定性诊断器 + 运维规则 RAG + 分岔决策（符合制度 → 直接处置 / 超范围 → 升级授权）+ typed 动作构造 / 校验 / 应用 + 授权工单闭环。
- 信息处理链路
- 确定性诊断根因 → 检索适用运维规则 → 判断诉求是否在制度允许范围 LLM → 允许则构造动作 + 确定性校验 + 应用；超范围则生成运维授权工单转 owner 签字。
4.4流程效能分析 Agent
- 目标用户
- 各流程 owner（看自己负责流程的健康度）、流程全局管理员（看所有流程）。这一块正是我在券商做过的效能看板，这次让它长出了 AI 归因能力。
- 场景
- 看板指标需人工协助定义（全局管理员统一定大盘指标，owner 定自己流程关注的指标）；基于指标标准做堵点问答；手工触发诊断报告识别堵点；效能看板展示实时数据；识别到的问题反哺到流程管理界面作为待处理项。
- 功能架构
- 确定性指标引擎 + 阈值堵点检测 + LLM 归因 / 建议层 + 反哺写入器；指标口径分层可配。
- 信息处理链路
- 运行事件日志 → 确定性算指标 → 阈值判堵点 → 归因 + 建议 LLM → 反哺为待处理项写回流程管理。
4.5流程管理 Agent
- 目标用户
- 流程 owner（只看得到自己负责的流程）、流程系统管理员。
- 场景
- 流程全局页面 + 设计入口；效能分析与运维识别出的问题统一作为"待处理项"展示，进入设计页后可逐条让 agent 诊断、给优化建议并修复流程定义；流程上下架管理。
- 功能架构
- 反哺聚合 + 逐项诊断路由（复用设计 / 分析 agent 能力）+ 上下架 / 版本管理。
- 信息处理链路
- 汇集效能 / 运维反哺项 → 选中项路由到设计或诊断能力 → 生成修复建议 → 人工确认应用 → 上下架。
4.6设计评测 · 抽取 harness 调优（非用户 agent）
- 用途
- 部署时量化抽取 agent 的准确率，驱动 harness 迭代。评测带一定主观性，标准以具体场景和要求为准，可按接受程度调分。
- 数据
- AI + 人工审核提前确定 target 标准流程定义；raw source 由 AI 按 target 反向模拟生成（含各类模拟文档），人工审核后冻结。
- 评测方式
- 按表单 / 流程环节等大模块切分 → 字段级对 target 统计 TP/FP/TN/FN，算 P / R / F1 并按公式合并 → 字段下属性：确定性的代码判、有主观性的 LLM judge 判是否同义。
4.7制度规则 RAG · 共享知识层（非 agent）
- 用途
- 合规红线、流程规范、运维处置规则的统一知识库，被设计、效能分析、运维三处复用为依据，且不让 LLM 凭空编规则。
- 结构
- 原子规则 + 原文 chunk 双向可溯；两阶段混合检索，每条命中都带原文出处。
- 被谁用
- 设计时校验合规 · 效能分析时对照红线 · 运维处置时引用依据。检索命中与规则匹配是确定性的，LLM 只做语义层面的补召回与引用组织。
5工程哲学：确定性 vs LLM
整套系统只有一条心法：确定性的归确定性、LLM 的归 LLM——LLM 只在"理解意图 / 组织语言"处出现，能判对错的事绝不交给它猜。这既是"可落地、可评测"的技术兑现，也是让评测、校验、闭环得以成立的地基。
| 模块 | LLM 负责 | 确定性代码负责 |
|---|---|---|
| 设计抽取 | 读懂材料、抽成 typed 对象 | schema / 字段引用 / 路径目标校验 |
| 会话式改 | 解析意图成 typed 工具 | 应用变更 / diff / undo / 合规校验 |
| 效能分析 | 归因、写优化建议 | 算指标 / 判堵点阈值 |
| 参与者 agent（发起 / 运维） | 判断 / 解释诉求 | 诊断 / 动作构造 / 校验 / 应用 |
| 设计评测 | judge 判同义改写 | P / R / F1、确定性打分 |
| 飞书 OA 翻译 | —— | 纯确定性映射 |
6技术架构详解
这一节把"确定性 vs LLM"的心法落到实现：抽取管线怎么编排、结构化输出怎么保证不崩、数据模型长什么样、规则 RAG 怎么检索、评测怎么锚在确定性上。全部可对照 GitHub 代码。
6.1抽取管线：6 节点 LangGraph
把"乱 source → 标准 ProcessDefinition"做成一条 LangGraph 管线（app/workflows/process_v1.py），6 个节点里只有 2 个是 LLM，其余全确定性：
结构 / 业务校验判定需要修复时回边到抽取节点重跑（次数由 max_validation_retries 控制）；每个节点用 get_stream_writer() 发 SSE 进度事件，前端 6 步进度条订阅。图片类 source（聊天截图、表格图）由多模态 Claude 只转录不推断，理解留给下游节点。
6.2结构化输出与解析兜底
所有 LLM 节点走同一套结构化输出：model.with_structured_output(Schema, method="function_calling", include_raw=True)——用 Bedrock 的 tool-use 通道直接产 typed 对象，include_raw 保留原始文本供兜底。解析失败按强度分三档：repair 重试（拿报错拼 prompt 再问一次）、分批 + 单批重试（大数组拆批，单批失败不拖累其它批）、JSON fallback（切纯 JSON 提取）。模型不支持结构化输出时有降级守卫：该步置空、给"模型未就绪"降级答复，不崩不假装。全项目只有一个模型工厂（app/models/bedrock.py，Bedrock + Claude），所有 agent 共用、不各自 new 配置。
6.3ProcessDefinition 数据模型
抽取的锚点是一份 typed schema（data/schema/process_schema.py）：meta（流程基础信息）+ form_fields（表单字段：类型 / 权限 / 哪些环节可填）+ flow_nodes（环节：handler / 意见条件 / 提交路径）+ attachments / roles。同一份定义同时驱动表单渲染、运行时路由、待办生成和流程图。抽取时强约束一套规范化规则——字段名忠实用 source 业务短名不改写、起草固定 node_id=draft、退回统一 DRAFT、正常结束 END、不编造时限 / 附件 / 角色——再由 structural_validator 确定性校验 schema、字段-环节引用完整性、路径目标合法性。抽取本身不判对错，对不对交给校验和评测。
6.4规则 RAG：结构化预筛 + 向量召回
制度规则库做成双层可溯（app/rag/）：结构化原子规则（atomic rule）+ 原文 chunk，每条命中都带文档 / 章节 / 条款出处。检索两段式：先按流程做结构化规则预筛（确定性，rules_for_process），再做向量语义召回（Chroma + Bedrock embeddings）。语义召回带相关性距离阈值（默认 1.0，实测相关 < 0.7、无关 > 1.5）——全部超阈值就诚实返回空，绝不"没相关知识还硬凑几条"。同一套库被设计（合规校验）、效能分析（对照红线）、运维（引用处置依据）三处复用，LLM 只做语义补召回与引用组织，不凭空编规则。
6.5评测 harness：确定性锚点 + 语义裁判
评测锚在抽取节点的确定性产出上：把结果按表单字段 / 环节 / 路径 / 附件 / 元信息五类模块切分，字段级对金标准统计 TP / FP / TN / FN，算 P / R / F1 并按公式合并成模块分与总分。对确定性字面比对判为"差异"的属性，再叠一层 LLM 语义裁判复评"是不是同一个意思"——判同义的按抽对折算回准确率，但折算用确定性公式（attribute_accuracy = (total − (D − K)) / total），不是 LLM 直接给分。CLI 基线评测不叠语义层、保持纯确定性可复现；只有产品页评测模式才叠加。前面 §7 的 3 案例均分（94.0 / 94.8）就是这么算出来的。
6.6会话式修改与反哺闭环
日常微调走typed 编辑工具（add / remove / update，改名必须"删旧 + 增新"，保证每步都是合法结构操作）；LLM 只把自然语言意图解析成这些工具调用，应用 / diff / undo 全确定性。改动落库前有合规确认门：编辑前后各查一次确定性规则、取差集——只拦"这次编辑新引入的违规"，不算草稿本来就有的账。反哺闭环靠一座桥（app/agents/design_feedback.py）：效能分析产出的优化建议被逐条喂回流程设计 agent、解析成结构化编辑、确定性 apply 成 v2 草稿——"AI 诊断 → AI 改流程"复用已有 agent，没有新造轮子。
7闭环见效：量化结果
评测分两层、落到真实数字：离线设计评测——对 AI + 人工冻结的金标准做要素级 P/R/F1，3 个真实流程案例（请假 / 子公司重大事项 / 费用报销）平均 94.0 / 94.8 分；生产合规评测——无参照地检查规则检索召回与违规命中。系统目前覆盖请假、报销、印章、采购、子公司重大事项五个真实流程场景。反哺闭环已在案例上跑通：运维 / 效能识别出的堵点作为"待处理项"回流到设计侧、重新设计，形成"设计 → 运行 → 分析 → 反哺"的自我改进环。
注：2~3 分钟 demo 视频还在整理，公开后补充。
8结论与可迁移性
- 一套把 LLM 做成可落地、可评测 to-B 产品的方法论：确定性兜底 + 闭环反哺 + 评测驱动的 harness 调优——不是"接个大模型"，是把不确定性关进确定性的笼子里。
- 可迁移到任何"非结构化输入 → 结构化产物 → 上线 → 运行数据反哺"的企业场景：不止流程，合同、工单、报表审核同构。
- 引擎无关的可移植性：同一份标准定义经确定性翻译层可发布到真实 OA 引擎（已跑通飞书审批端到端真发、表单保真）。
