1. 项目概述当文档处理遇上多智能体协同最近在做一个企业级的文档自动化项目客户扔过来一堆合同、报告、发票要求自动提取关键信息、分类归档、甚至做合规性检查。一开始我们按传统路子走搞了个大模型微调的单体应用结果发现效果很“脆”——面对格式千奇百怪的文档要么识别率忽高忽低要么遇到复杂表格和手写体就直接“摆烂”。更头疼的是业务规则一变整个流程就得推倒重来成本高得吓人。就在我们焦头烂额的时候团队里有人提了个思路为什么不把文档处理拆成一个个小任务让不同的“专家”智能体各司其职再找个“总指挥”来协调呢这个想法正好撞上了当前AI领域的一个热点多智能体系统Multi-Agent System, MAS。于是我们开始探索将多智能体协作的框架引入文档处理流程并设计了一个名为MADPMulti-Agent Document Pipeline的可持续处理框架。它的核心思想很简单把复杂的文档处理任务分解、分配给一群具备不同能力的智能体去协同完成并且在关键决策点引入人类专家的判断Human-in-the-Loop形成一个既能自动化高效运行又能保证最终结果准确可靠的“人机协同”流水线。这个框架特别适合谁呢如果你正在处理大量非结构化文档如法律合同、医疗记录、财务报告对准确性和可解释性要求极高同时又希望流程能灵活适应业务变化那么MADP的思路或许能给你带来一些启发。它不是一个开箱即用的产品而是一套设计方法论和实现模式你可以基于现有的LLM大语言模型和智能体开发框架来搭建自己的解决方案。2. MADP核心架构与设计哲学2.1 为什么是“多智能体”而非“单体模型”在深入架构之前必须先回答这个问题。传统的文档处理无论是用规则引擎、传统OCR NLP还是微调一个全能型大模型本质上都是“单体架构”。它试图用一个模型或一套规则解决所有问题这带来了几个固有瓶颈“木桶效应”严重模型的整体性能受限于其最薄弱的环节。比如一个在文本提取上表现优秀的模型可能在表格理解上很差导致整个流程卡壳。更新与维护成本高业务逻辑或文档格式一变就需要重新训练或调整整个模型牵一发而动全身。可解释性差一个“黑箱”模型做出了错误判断你很难定位问题究竟出在哪个处理阶段。资源利用不经济有些简单任务如语言识别根本不需要动用百亿参数的大模型用轻量级模型足矣单体架构却往往“杀鸡用牛刀”。多智能体架构的核心优势就在于“解耦”和“专精”。我们可以为文档处理流程中的每一个子任务设计或调用一个最合适的智能体Agent。比如文档解析智能体专门负责将PDF、图片等转换成结构化的文本和布局信息它可能集成了最新的OCR技术和文档布局分析模型。信息抽取智能体专门从文本中抽取实体如人名、公司名、金额、日期它可能是一个微调的NER命名实体识别模型。逻辑验证智能体专门检查抽取的信息是否符合业务规则如“合同金额是否大于零”、“签署日期是否在生效日期之前”它可能是一套规则引擎或一个小型分类模型。汇总与报告智能体负责将各个智能体的结果整合成最终的报告或数据库记录。每个智能体相对独立可以单独优化、升级甚至替换。整个系统的鲁棒性Robustness不再依赖于单个模型的完美而是取决于智能体之间的协作机制是否健壮。2.2 引入“人在回路”的必要性与设计模式自动化程度再高也无法100%替代人类在复杂场景下的判断力、常识和领域知识。尤其是在法律、金融、医疗等高风险领域一个自动化错误可能导致严重后果。因此“人在回路”Human-in-the-Loop, HITL不是对自动化的妥协而是对其可靠性和可信度的必要增强。在MADP中HITL不是简单地在最后加一个人工审核环节而是被深度集成到流程的关键决策点上。我们设计了三种主要的HITL介入模式不确定性触发式介入每个智能体在处理时都会输出一个“置信度”分数。当多个智能体对同一信息的判断冲突或某个智能体的置信度低于预设阈值时系统自动将该任务“挂起”并推送至人工审核队列。例如信息抽取智能体识别出一个“金额”为“一百万元”但逻辑验证智能体根据上下文怀疑应该是“十万元”两者冲突触发人工复核。关键节点强制介入对于流程中定义的高风险环节无论智能体置信度多高都强制要求人工确认。例如在合同处理中“最终签署方”的确认、涉及重大金额的条款可以设置为强制人工审核点。主动学习式介入系统会记录人工纠正的案例并将其作为高质量的训练数据用于定期迭代优化相关的智能体。这使得系统能够从人类的反馈中持续学习越用越“聪明”。这种设计确保了自动化流程在“边界情况”下能安全、可靠地运行同时也为系统提供了持续的优化燃料。2.3 管道编排与智能体通信机制如何让这群各有所长的智能体有序、高效地协作是MADP架构设计的重中之重。我们借鉴了微服务架构中的“编排Orchestration”思想设计了一个中心化的管道协调器Pipeline Orchestrator。这个协调器不负责具体的文档处理它的核心职责是流程定义以可配置的方式定义文档处理的步骤序列、每个步骤对应的智能体、步骤之间的依赖关系以及HITL的触发条件。任务调度与路由接收原始文档将其转化为一个“处理任务”然后根据流程定义将任务及其上下文Context分发给相应的智能体。它需要管理任务状态处理智能体的成功、失败或超时。上下文管理维护一个全局的“任务上下文”记录每个智能体的处理结果、中间状态和置信度。这个上下文随着任务在管道中流动供后续智能体参考。HITL网关负责与人工审核界面集成当需要人工介入时将任务上下文、冲突信息、待决策点清晰地呈现给审核人员并将人工决策结果反馈回流程。智能体之间的通信我们采用了基于标准化消息格式如JSON Schema的异步消息传递。每个智能体被设计为“无状态”的服务它从协调器接收输入消息处理完成后将输出消息包含结果、置信度、状态码返回给协调器。这种松耦合的设计使得智能体可以独立部署、伸缩和更新。实操心得协调器的技术选型协调器是整个系统的大脑其稳定性和性能至关重要。我们评估了几种方案自研基于消息队列如RabbitMQ, Kafka的调度器灵活性最高但开发复杂度也高需要处理大量的状态管理和错误恢复逻辑。使用工作流引擎如Apache Airflow, Camunda它们天然适合描述有向无环图DAG形式的工作流内置了重试、监控、依赖管理等功能。对于MADP这种管道式流程Airflow是一个强有力的候选。你可以将每个智能体定义为一个“Operator”流程定义就是DAG。利用现有的智能体框架如LangChain, LlamaIndex的智能体模块这些框架提供了高阶的智能体编排工具。如果你的智能体核心都是基于LLM的使用这些框架可以快速搭建原型。但在生产环境中可能需要对其任务调度和状态持久化能力进行增强。 我们最终选择了Airflow作为核心协调器因为它成熟、稳定、可视化好且与我们的运维体系集成度高。对于LLM智能体我们将其封装为标准的Airflow Operator。3. 智能体角色定义与关键技术实现3.1 核心智能体角色库一个典型的MADP系统可能包含以下类型的智能体。你可以根据实际文档处理需求进行裁剪和组合。智能体角色核心职责关键技术/模型输出示例文档加载与解析智能体支持多种格式PDF, Word, 图片扫描件提取原始文本、字体、位置、版面结构等信息。PyMuPDF, pdfplumber, Tesseract OCR, LayoutLM, Donut结构化文本块、页面图像、表格坐标、OCR置信度文档分类与路由智能体判断文档类型如发票、合同、简历并决定后续处理流程。轻量级文本分类模型如BERT微调、基于规则的关键词匹配文档类型标签、建议的下一环节智能体ID信息抽取智能体从文本中抽取预定义的实体和关系。NER模型spaCy, BERT-CRF、关系抽取模型、LLMPrompt工程JSON格式的实体列表{“实体”: “金额”, “值”: “10000”, “位置”: “页1行5”}表格理解智能体专门处理复杂表格识别表头、行列关系提取结构化数据。Table Transformer, Tabula, Camelot, GPT-4V多模态二维数组或键值对形式的表格数据逻辑验证与合规智能体基于业务规则校验抽取信息的逻辑一致性、完整性、合规性。规则引擎Drools、逻辑编程、小型判别模型验证结果通过/失败、失败原因、触发的规则ID摘要与问答智能体生成文档摘要或回答关于文档内容的特定问题。文本摘要模型BART, T5、检索增强生成RAG文档摘要、问题答案附带原文引用格式重构与输出智能体将处理后的信息重新组装成目标格式如数据库记录、JSON报告、新格式文档。模板引擎Jinja2、报告生成库最终输出文件JSON, CSV, 新的PDF等3.2 基于LLM的智能体实现模式当前大语言模型LLM是构建智能体的强大基石。根据智能体角色的不同我们采用不同的LLM集成模式工具调用型智能体这是最常用的模式。智能体的核心是一个LLM如GPT-4, Claude它被赋予一个明确的“系统提示词”System Prompt描述其角色和能力。同时它为LLM装备了“工具”Tools例如调用一个外部OCR API、查询一个数据库、或执行一段Python代码进行数据计算。LLM根据用户请求或上游智能体的输出自主决定调用哪个工具、传入什么参数。LangChain的AgentExecutor或微软的AutoGen框架非常适合构建此类智能体。示例信息抽取智能体。系统提示词定义其为“合同信息提取专家”。工具包括parse_document(text)用于基础解析search_clause(keyword)用于查找特定条款extract_entity(pattern)用于正则匹配。LLM会分析合同文本决定如何组合使用这些工具来完成任务。专有模型微调型智能体对于任务非常固定、且对精度和速度要求极高的场景可以针对特定任务微调一个较小的、专用的LLM如Llama 3, Qwen的7B/13B版本。例如专门用于识别“发票类型”的分类智能体。这种智能体推理速度快成本低且行为更可控。多模态智能体对于需要理解文档视觉布局、印章、手写体的场景需要多模态大模型如GPT-4V, Gemini Pro Vision的支持。这类智能体可以直接接收文档图像作为输入结合视觉和文本信息进行理解。表格理解智能体和复杂版式解析智能体通常属于此类。注意事项LLM智能体的稳定性LLM的“幻觉”和输出不稳定性是多智能体系统的主要风险源。必须为每个LLM智能体设计严格的输出格式化Output Parsing和验证层。强制LLM以指定的JSON Schema输出并在输出后立即用一套轻量级规则或验证模型检查其基本有效性如字段是否齐全、格式是否正确。无效输出应触发重试或直接上报HITL。3.3 性能考量与“延迟-感知”的服务策略当多个LLM智能体串联时累积延迟可能成为瓶颈。这里就需要引入网络热词中提到的“latency- and performance-aware”思想。我们不能简单地把所有智能体串行执行。并行与异步执行分析智能体间的依赖关系。无依赖的智能体可以并行执行。例如“文档分类智能体”和“文档解析智能体”可以同时开始工作一个分析文件名和元数据一个解析内容。协调器需要管理这种并行流程。智能体路由与条件执行并非所有文档都需要走完所有智能体。根据文档分类或早期处理结果动态决定后续流程。例如如果分类为“简单通知”可能跳过“表格理解”和“逻辑验证”环节。模型粒度与缓存为不同复杂度的子任务选择合适的模型粒度。简单的任务使用轻量、快速的模型或甚至规则复杂的分析才动用重型LLM。对频繁出现的、结果稳定的中间结果如公司名称标准化建立缓存。异构LLM负载均衡如同网络热词“chimera”奇美拉意指混合体和“heterogeneous LLMs”所暗示的一个生产级MADP系统可能会混合使用多种LLM提供商OpenAI, Anthropic, 本地部署模型和不同规模的模型。协调器需要具备简单的负载均衡和降级策略。例如主要使用GPT-4进行复杂推理但当其API延迟过高或配额用尽时自动降级到Claude Haiku或本地Qwen模型以保证管道整体SLA。4. 构建MADP的实操步骤与核心配置4.1 环境与工具链搭建假设我们选择Python作为主要开发语言以下是一个基础的工具栈协调与编排Apache Airflow推荐用于生产或 Prefect。用于开发原型也可以直接用LangGraph或LlamaIndex的智能体工作流。智能体开发框架LangChain / LangGraph 或 Microsoft AutoGen。它们提供了构建LLM智能体的高级抽象。核心LLM服务OpenAI API, Anthropic API或本地部署的Ollama运行Llama, Qwen等、vLLM用于高性能推理。文档处理基础库pypdf,pdfplumber,pytesseract,pdf2image 以及layoutparser等。向量数据库与RAGChroma, Weaviate, Qdrant。用于构建智能体的长期记忆或知识检索能力。消息队列/任务队列RedisCelery后端、RabbitMQ。如果Airflow使用CeleryExecutor则Redis是必须的。前端HITL界面Streamlit快速原型、Gradio或React/Django开发完整的审核平台。部署与监控Docker, Kubernetes, Prometheus, Grafana。4.2 分步实现一个合同处理管道让我们以一个“销售合同关键信息提取与验证”的管道为例拆解实现步骤。步骤1定义管道DAG以Airflow为例在Airflow中我们创建一个DAG文件contract_processing_pipeline.py。from airflow import DAG from airflow.operators.python import PythonOperator from datetime import datetime # 假设我们已经实现了各个智能体的调用函数 from agents import parse_document_agent, classify_document_agent, extract_info_agent, validate_logic_agent, human_review_operator, generate_report_agent default_args { owner: madp_team, retries: 1, } with DAG( dag_idcontract_madp_pipeline, default_argsdefault_args, descriptionA Multi-Agent Pipeline for Contract Processing, start_datedatetime(2024, 1, 1), schedule_intervalNone, # 由外部触发 catchupFalse, ) as dag: # 任务1文档解析 task_parse PythonOperator( task_idparse_document, python_callableparse_document_agent, op_kwargs{file_path: {{ dag_run.conf[file_path] }}}, # 从触发参数中获取 ) # 任务2文档分类可与任务1并行 task_classify PythonOperator( task_idclassify_document, python_callableclassify_document_agent, op_kwargs{file_path: {{ dag_run.conf[file_path] }}}, ) # 任务3信息抽取依赖解析结果 task_extract PythonOperator( task_idextract_entities, python_callableextract_info_agent, op_kwargs{parsed_data: {{ ti.xcom_pull(task_idsparse_document) }}}, # 从parse任务拉取结果 ) # 任务4逻辑验证依赖抽取结果和分类结果 task_validate PythonOperator( task_idvalidate_logic, python_callablevalidate_logic_agent, op_kwargs{ extracted_entities: {{ ti.xcom_pull(task_idsextract_entities) }}, doc_type: {{ ti.xcom_pull(task_idsclassify_document) }} }, trigger_ruleall_done, # 即使上游有失败也执行以便记录错误 ) # 任务5人工审核条件执行依赖验证结果 task_human_review PythonOperator( task_idhuman_review, python_callablehuman_review_operator, op_kwargs{validation_result: {{ ti.xcom_pull(task_idsvalidate_logic) }}}, ) # 设置触发条件当验证结果中need_human_review为True时执行 task_validate task_human_review # 注意在真实场景中需要自定义Operator来实现条件触发Airflow本身有BranchPythonOperator等 # 任务6生成报告依赖验证或人工审核的最终结果 task_report PythonOperator( task_idgenerate_final_report, python_callablegenerate_report_agent, op_kwargs{final_data: {{ ti.xcom_pull(task_idsvalidate_logic) }}}, # 简化逻辑实际需合并人工审核结果 ) # 定义任务依赖 [task_parse, task_classify] task_extract task_validate task_validate task_report # human_review 任务在特定条件下执行并可能更新数据流这里简化了依赖关系。步骤2实现一个智能体以信息抽取智能体为例使用LangChain构建一个工具调用型智能体。import os from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.tools import tool from pydantic import BaseModel, Field from typing import List, Optional # 1. 定义智能体可用的工具 tool def search_for_clause(text: str, clause_keyword: str) - str: 在合同文本中搜索包含特定关键词的条款。 # 实现简单的文本搜索逻辑 lines text.split(\n) results [line for line in lines if clause_keyword.lower() in line.lower()] return \n.join(results) if results else f未找到包含 {clause_keyword} 的条款。 tool def extract_using_regex(text: str, pattern: str) - str: 使用正则表达式从文本中提取信息。 import re matches re.findall(pattern, text) return , .join(matches) if matches else 未匹配到模式。 # 2. 定义智能体的输出格式Pydantic模型 class ExtractedContractInfo(BaseModel): contract_id: Optional[str] Field(description合同编号) party_a: Optional[str] Field(description甲方名称) party_b: Optional[str] Field(description乙方名称) total_amount: Optional[str] Field(description合同总金额) signing_date: Optional[str] Field(description签署日期) confidence: float Field(description本次信息抽取的整体置信度0-1之间) # 3. 构建智能体 llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0) # 使用低temperature保证稳定性 tools [search_for_clause, extract_using_regex] prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的合同信息抽取助手。你的目标是从用户提供的合同文本中精准地提取出合同编号、甲方乙方、总金额、签署日期等关键信息。 你可以使用工具来帮助你定位和提取信息。 请严格按照要求的JSON格式输出结果并给出一个整体置信度。如果你对某个字段不确定可以留空并降低整体置信度。), MessagesPlaceholder(variable_namechat_history, optionalTrue), (human, 合同文本{input_text}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) agent create_openai_tools_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 4. 封装为Airflow任务可调用的函数 def extract_info_agent(parsed_data: dict) - dict: Airflow任务调用的函数。 parsed_data: 来自文档解析智能体的输出包含text等字段。 input_text parsed_data.get(text, ) if not input_text: return {error: 无有效文本输入, confidence: 0.0} try: # 调用智能体执行 result agent_executor.invoke({ input_text: input_text, chat_history: [] # 本例中无历史 }) output result[output] # 这里需要将LLM的自然语言输出解析成ExtractedContractInfo格式。 # 更佳实践是使用LangChain的OutputParser或LLM的JSON Mode。 # 假设我们通过Prompt工程让LLM直接返回了JSON字符串。 import json extracted_info json.loads(output) # 简化处理实际需更健壮的解析 extracted_info[agent] extract_info_agent_v1 return extracted_info except Exception as e: # 记录日志并返回错误触发下游或HITL print(f信息抽取智能体失败: {e}) return {error: str(e), confidence: 0.0, agent: extract_info_agent_v1}步骤3实现HITL集成HITL界面需要展示任务上下文、智能体结果、冲突点并允许人工输入修正结果。一个简单的Streamlit应用示例如下# hitl_dashboard.py import streamlit as st import requests # 从后端API获取待审核任务列表 def fetch_pending_tasks(): # 调用协调器暴露的API response requests.get(http://orchestrator-api/tasks/pending) return response.json() # 获取特定任务的详情 def fetch_task_detail(task_id): response requests.get(fhttp://orchestrator-api/tasks/{task_id}/context) return response.json() # 提交人工审核结果 def submit_review(task_id, corrected_data, reviewer_notes): payload { task_id: task_id, action: approve_with_correction, # 或 reject, approve corrected_data: corrected_data, notes: reviewer_notes } response requests.post(http://orchestrator-api/tasks/review, jsonpayload) return response.ok # Streamlit UI st.title(MADP 人工审核中心) tasks fetch_pending_tasks() selected_task_id st.selectbox(选择待审核任务, [t[id] for t in tasks]) if selected_task_id: task_detail fetch_task_detail(selected_task_id) st.subheader(f任务详情 - {selected_task_id}) st.json(task_detail) # 展示完整的任务上下文 st.subheader(智能体结果与冲突) # 解析并高亮显示冲突信息例如来自validate_logic_agent的警告 conflicts task_detail.get(validation_results, {}).get(conflicts, []) for conflict in conflicts: st.warning(f冲突: {conflict}) st.subheader(人工修正) # 根据任务类型生成可编辑的表单。例如对于合同信息 corrected_contract_id st.text_input(合同编号, valuetask_detail.get(extracted, {}).get(contract_id, )) corrected_amount st.text_input(合同金额, valuetask_detail.get(extracted, {}).get(total_amount, )) reviewer_notes st.text_area(审核备注) if st.button(提交审核): corrected_data { contract_id: corrected_contract_id, total_amount: corrected_amount, # ... 其他字段 } if submit_review(selected_task_id, corrected_data, reviewer_notes): st.success(审核结果提交成功) else: st.error(提交失败请重试。)5. 常见问题、排查技巧与优化方向5.1 实施过程中的典型问题与解决方案问题现象可能原因排查步骤与解决方案管道整体延迟过高1. 智能体串行依赖过多。2. 某个智能体尤其是LLM调用响应慢。3. 网络或API延迟。1.分析DAG使用Airflow的甘特图等工具找出关键路径和耗时最长的任务。2.并行化将无依赖的任务改为并行执行。3.优化慢速智能体考虑缓存、使用更轻量模型、或优化Prompt减少token消耗。4.设置超时与重试为每个智能体任务配置合理的超时时间并设置重试策略。智能体输出格式不稳定LLM的“幻觉”或Prompt指令不清晰导致输出JSON格式错误或字段缺失。1.强化输出约束使用LLM的JSON Mode如果支持或采用更严格的Output Parser如PydanticOutputParser。2.设计验证层在智能体输出后立即添加一个轻量级验证步骤检查必填字段和基本格式格式错误则触发重试或直接失败。3.改进Prompt在Prompt中提供更清晰的输出示例Few-shot。HITL环节成为瓶颈审核任务堆积人工处理速度跟不上自动化生成速度。1.优化触发策略提高自动通过的置信度阈值只将真正不确定的案例送审。2.任务优先级根据业务规则为审核任务设置优先级如金额大的合同优先。3.部分自动化在审核界面提供“建议选项”让人工做选择题而非填空题加快处理速度。4.主动学习将人工纠正的案例快速反馈到训练集定期重新训练相关智能体减少未来同类错误。系统扩展性差智能体都是重量级LLM成本高且无法水平扩展。1.异构架构采用“大模型小模型”混合策略。关键复杂推理用大模型简单分类、匹配用小模型或规则。2.智能体池化将无状态的智能体部署为多个实例通过负载均衡器分发任务。3.异步处理使用消息队列如RabbitMQ解耦智能体协调器发布任务智能体监听队列并消费实现自然伸缩。5.2 性能与成本优化实战技巧LLM API调用优化批处理Batching对于大量小的、独立的文本片段如多个合同条款可以将它们组合成一个批处理请求发送给LLM API通常比多次单独调用更便宜、更快。流式响应Streaming对于生成摘要或长文本的智能体使用流式响应可以改善用户体验让后续环节不必等待全部生成完毕即可开始处理。缓存层为LLM智能体引入缓存如Redis。对相同的输入Prompt直接返回缓存的结果。这在处理大量格式雷同的文档如同一模板的发票时效果极佳。管道流程优化提前退出Early Exit在管道前端设置“质量检查点”。如果文档解析质量极差如OCR置信度过低可以直接标记为失败并送入HITL避免浪费后续智能体的计算资源。动态管道根据文档分类结果动态组装不同的处理管道。例如“普通通知”走简易管道“采购合同”走完整管道。监控与可观测性为每个智能体调用记录详细的日志输入、输出、耗时、token使用量、置信度、API成本。在协调器层面监控整个管道的SLA服务等级协议如端到端处理时间、成功率、HITL触发率。设置告警当某个智能体的失败率突增、平均延迟超标或HITL队列积压时及时通知运维人员。5.3 未来演进方向MADP框架本身是开放的可以随着技术发展不断演进智能体间的强化学习协作这正是网络热词“actor-attention-critic for multi-agent reinforcement learning”所指向的前沿方向。我们可以为智能体设计奖励函数如处理速度、结果准确性让它们通过强化学习自主优化协作策略而不仅仅是遵循预设的固定流程。例如让“分类智能体”学会在置信度不高时主动调用“解析智能体”获取更多布局信息再做判断。更复杂的智能体生态引入具有长期记忆和规划能力的智能体使其能够处理跨文档的复杂任务例如对比多份历史合同中的条款变化。低代码/无代码配置开发图形化界面让业务专家可以通过拖拽的方式配置新的文档处理管道定义智能体角色和规则降低技术门槛。构建MADP系统是一个持续迭代的过程。从一个小而精的管道开始解决一个具体的业务痛点然后逐步增加智能体、优化流程、集成HITL。其核心价值在于提供了一种可持续、可进化、人机共融的复杂文档处理范式将人类的领域智慧与AI的自动化效率紧密结合最终实现112的效果。 多智能体协同文档处理：构建可持续的MADP框架
1. 项目概述当文档处理遇上多智能体协同最近在做一个企业级的文档自动化项目客户扔过来一堆合同、报告、发票要求自动提取关键信息、分类归档、甚至做合规性检查。一开始我们按传统路子走搞了个大模型微调的单体应用结果发现效果很“脆”——面对格式千奇百怪的文档要么识别率忽高忽低要么遇到复杂表格和手写体就直接“摆烂”。更头疼的是业务规则一变整个流程就得推倒重来成本高得吓人。就在我们焦头烂额的时候团队里有人提了个思路为什么不把文档处理拆成一个个小任务让不同的“专家”智能体各司其职再找个“总指挥”来协调呢这个想法正好撞上了当前AI领域的一个热点多智能体系统Multi-Agent System, MAS。于是我们开始探索将多智能体协作的框架引入文档处理流程并设计了一个名为MADPMulti-Agent Document Pipeline的可持续处理框架。它的核心思想很简单把复杂的文档处理任务分解、分配给一群具备不同能力的智能体去协同完成并且在关键决策点引入人类专家的判断Human-in-the-Loop形成一个既能自动化高效运行又能保证最终结果准确可靠的“人机协同”流水线。这个框架特别适合谁呢如果你正在处理大量非结构化文档如法律合同、医疗记录、财务报告对准确性和可解释性要求极高同时又希望流程能灵活适应业务变化那么MADP的思路或许能给你带来一些启发。它不是一个开箱即用的产品而是一套设计方法论和实现模式你可以基于现有的LLM大语言模型和智能体开发框架来搭建自己的解决方案。2. MADP核心架构与设计哲学2.1 为什么是“多智能体”而非“单体模型”在深入架构之前必须先回答这个问题。传统的文档处理无论是用规则引擎、传统OCR NLP还是微调一个全能型大模型本质上都是“单体架构”。它试图用一个模型或一套规则解决所有问题这带来了几个固有瓶颈“木桶效应”严重模型的整体性能受限于其最薄弱的环节。比如一个在文本提取上表现优秀的模型可能在表格理解上很差导致整个流程卡壳。更新与维护成本高业务逻辑或文档格式一变就需要重新训练或调整整个模型牵一发而动全身。可解释性差一个“黑箱”模型做出了错误判断你很难定位问题究竟出在哪个处理阶段。资源利用不经济有些简单任务如语言识别根本不需要动用百亿参数的大模型用轻量级模型足矣单体架构却往往“杀鸡用牛刀”。多智能体架构的核心优势就在于“解耦”和“专精”。我们可以为文档处理流程中的每一个子任务设计或调用一个最合适的智能体Agent。比如文档解析智能体专门负责将PDF、图片等转换成结构化的文本和布局信息它可能集成了最新的OCR技术和文档布局分析模型。信息抽取智能体专门从文本中抽取实体如人名、公司名、金额、日期它可能是一个微调的NER命名实体识别模型。逻辑验证智能体专门检查抽取的信息是否符合业务规则如“合同金额是否大于零”、“签署日期是否在生效日期之前”它可能是一套规则引擎或一个小型分类模型。汇总与报告智能体负责将各个智能体的结果整合成最终的报告或数据库记录。每个智能体相对独立可以单独优化、升级甚至替换。整个系统的鲁棒性Robustness不再依赖于单个模型的完美而是取决于智能体之间的协作机制是否健壮。2.2 引入“人在回路”的必要性与设计模式自动化程度再高也无法100%替代人类在复杂场景下的判断力、常识和领域知识。尤其是在法律、金融、医疗等高风险领域一个自动化错误可能导致严重后果。因此“人在回路”Human-in-the-Loop, HITL不是对自动化的妥协而是对其可靠性和可信度的必要增强。在MADP中HITL不是简单地在最后加一个人工审核环节而是被深度集成到流程的关键决策点上。我们设计了三种主要的HITL介入模式不确定性触发式介入每个智能体在处理时都会输出一个“置信度”分数。当多个智能体对同一信息的判断冲突或某个智能体的置信度低于预设阈值时系统自动将该任务“挂起”并推送至人工审核队列。例如信息抽取智能体识别出一个“金额”为“一百万元”但逻辑验证智能体根据上下文怀疑应该是“十万元”两者冲突触发人工复核。关键节点强制介入对于流程中定义的高风险环节无论智能体置信度多高都强制要求人工确认。例如在合同处理中“最终签署方”的确认、涉及重大金额的条款可以设置为强制人工审核点。主动学习式介入系统会记录人工纠正的案例并将其作为高质量的训练数据用于定期迭代优化相关的智能体。这使得系统能够从人类的反馈中持续学习越用越“聪明”。这种设计确保了自动化流程在“边界情况”下能安全、可靠地运行同时也为系统提供了持续的优化燃料。2.3 管道编排与智能体通信机制如何让这群各有所长的智能体有序、高效地协作是MADP架构设计的重中之重。我们借鉴了微服务架构中的“编排Orchestration”思想设计了一个中心化的管道协调器Pipeline Orchestrator。这个协调器不负责具体的文档处理它的核心职责是流程定义以可配置的方式定义文档处理的步骤序列、每个步骤对应的智能体、步骤之间的依赖关系以及HITL的触发条件。任务调度与路由接收原始文档将其转化为一个“处理任务”然后根据流程定义将任务及其上下文Context分发给相应的智能体。它需要管理任务状态处理智能体的成功、失败或超时。上下文管理维护一个全局的“任务上下文”记录每个智能体的处理结果、中间状态和置信度。这个上下文随着任务在管道中流动供后续智能体参考。HITL网关负责与人工审核界面集成当需要人工介入时将任务上下文、冲突信息、待决策点清晰地呈现给审核人员并将人工决策结果反馈回流程。智能体之间的通信我们采用了基于标准化消息格式如JSON Schema的异步消息传递。每个智能体被设计为“无状态”的服务它从协调器接收输入消息处理完成后将输出消息包含结果、置信度、状态码返回给协调器。这种松耦合的设计使得智能体可以独立部署、伸缩和更新。实操心得协调器的技术选型协调器是整个系统的大脑其稳定性和性能至关重要。我们评估了几种方案自研基于消息队列如RabbitMQ, Kafka的调度器灵活性最高但开发复杂度也高需要处理大量的状态管理和错误恢复逻辑。使用工作流引擎如Apache Airflow, Camunda它们天然适合描述有向无环图DAG形式的工作流内置了重试、监控、依赖管理等功能。对于MADP这种管道式流程Airflow是一个强有力的候选。你可以将每个智能体定义为一个“Operator”流程定义就是DAG。利用现有的智能体框架如LangChain, LlamaIndex的智能体模块这些框架提供了高阶的智能体编排工具。如果你的智能体核心都是基于LLM的使用这些框架可以快速搭建原型。但在生产环境中可能需要对其任务调度和状态持久化能力进行增强。 我们最终选择了Airflow作为核心协调器因为它成熟、稳定、可视化好且与我们的运维体系集成度高。对于LLM智能体我们将其封装为标准的Airflow Operator。3. 智能体角色定义与关键技术实现3.1 核心智能体角色库一个典型的MADP系统可能包含以下类型的智能体。你可以根据实际文档处理需求进行裁剪和组合。智能体角色核心职责关键技术/模型输出示例文档加载与解析智能体支持多种格式PDF, Word, 图片扫描件提取原始文本、字体、位置、版面结构等信息。PyMuPDF, pdfplumber, Tesseract OCR, LayoutLM, Donut结构化文本块、页面图像、表格坐标、OCR置信度文档分类与路由智能体判断文档类型如发票、合同、简历并决定后续处理流程。轻量级文本分类模型如BERT微调、基于规则的关键词匹配文档类型标签、建议的下一环节智能体ID信息抽取智能体从文本中抽取预定义的实体和关系。NER模型spaCy, BERT-CRF、关系抽取模型、LLMPrompt工程JSON格式的实体列表{“实体”: “金额”, “值”: “10000”, “位置”: “页1行5”}表格理解智能体专门处理复杂表格识别表头、行列关系提取结构化数据。Table Transformer, Tabula, Camelot, GPT-4V多模态二维数组或键值对形式的表格数据逻辑验证与合规智能体基于业务规则校验抽取信息的逻辑一致性、完整性、合规性。规则引擎Drools、逻辑编程、小型判别模型验证结果通过/失败、失败原因、触发的规则ID摘要与问答智能体生成文档摘要或回答关于文档内容的特定问题。文本摘要模型BART, T5、检索增强生成RAG文档摘要、问题答案附带原文引用格式重构与输出智能体将处理后的信息重新组装成目标格式如数据库记录、JSON报告、新格式文档。模板引擎Jinja2、报告生成库最终输出文件JSON, CSV, 新的PDF等3.2 基于LLM的智能体实现模式当前大语言模型LLM是构建智能体的强大基石。根据智能体角色的不同我们采用不同的LLM集成模式工具调用型智能体这是最常用的模式。智能体的核心是一个LLM如GPT-4, Claude它被赋予一个明确的“系统提示词”System Prompt描述其角色和能力。同时它为LLM装备了“工具”Tools例如调用一个外部OCR API、查询一个数据库、或执行一段Python代码进行数据计算。LLM根据用户请求或上游智能体的输出自主决定调用哪个工具、传入什么参数。LangChain的AgentExecutor或微软的AutoGen框架非常适合构建此类智能体。示例信息抽取智能体。系统提示词定义其为“合同信息提取专家”。工具包括parse_document(text)用于基础解析search_clause(keyword)用于查找特定条款extract_entity(pattern)用于正则匹配。LLM会分析合同文本决定如何组合使用这些工具来完成任务。专有模型微调型智能体对于任务非常固定、且对精度和速度要求极高的场景可以针对特定任务微调一个较小的、专用的LLM如Llama 3, Qwen的7B/13B版本。例如专门用于识别“发票类型”的分类智能体。这种智能体推理速度快成本低且行为更可控。多模态智能体对于需要理解文档视觉布局、印章、手写体的场景需要多模态大模型如GPT-4V, Gemini Pro Vision的支持。这类智能体可以直接接收文档图像作为输入结合视觉和文本信息进行理解。表格理解智能体和复杂版式解析智能体通常属于此类。注意事项LLM智能体的稳定性LLM的“幻觉”和输出不稳定性是多智能体系统的主要风险源。必须为每个LLM智能体设计严格的输出格式化Output Parsing和验证层。强制LLM以指定的JSON Schema输出并在输出后立即用一套轻量级规则或验证模型检查其基本有效性如字段是否齐全、格式是否正确。无效输出应触发重试或直接上报HITL。3.3 性能考量与“延迟-感知”的服务策略当多个LLM智能体串联时累积延迟可能成为瓶颈。这里就需要引入网络热词中提到的“latency- and performance-aware”思想。我们不能简单地把所有智能体串行执行。并行与异步执行分析智能体间的依赖关系。无依赖的智能体可以并行执行。例如“文档分类智能体”和“文档解析智能体”可以同时开始工作一个分析文件名和元数据一个解析内容。协调器需要管理这种并行流程。智能体路由与条件执行并非所有文档都需要走完所有智能体。根据文档分类或早期处理结果动态决定后续流程。例如如果分类为“简单通知”可能跳过“表格理解”和“逻辑验证”环节。模型粒度与缓存为不同复杂度的子任务选择合适的模型粒度。简单的任务使用轻量、快速的模型或甚至规则复杂的分析才动用重型LLM。对频繁出现的、结果稳定的中间结果如公司名称标准化建立缓存。异构LLM负载均衡如同网络热词“chimera”奇美拉意指混合体和“heterogeneous LLMs”所暗示的一个生产级MADP系统可能会混合使用多种LLM提供商OpenAI, Anthropic, 本地部署模型和不同规模的模型。协调器需要具备简单的负载均衡和降级策略。例如主要使用GPT-4进行复杂推理但当其API延迟过高或配额用尽时自动降级到Claude Haiku或本地Qwen模型以保证管道整体SLA。4. 构建MADP的实操步骤与核心配置4.1 环境与工具链搭建假设我们选择Python作为主要开发语言以下是一个基础的工具栈协调与编排Apache Airflow推荐用于生产或 Prefect。用于开发原型也可以直接用LangGraph或LlamaIndex的智能体工作流。智能体开发框架LangChain / LangGraph 或 Microsoft AutoGen。它们提供了构建LLM智能体的高级抽象。核心LLM服务OpenAI API, Anthropic API或本地部署的Ollama运行Llama, Qwen等、vLLM用于高性能推理。文档处理基础库pypdf,pdfplumber,pytesseract,pdf2image 以及layoutparser等。向量数据库与RAGChroma, Weaviate, Qdrant。用于构建智能体的长期记忆或知识检索能力。消息队列/任务队列RedisCelery后端、RabbitMQ。如果Airflow使用CeleryExecutor则Redis是必须的。前端HITL界面Streamlit快速原型、Gradio或React/Django开发完整的审核平台。部署与监控Docker, Kubernetes, Prometheus, Grafana。4.2 分步实现一个合同处理管道让我们以一个“销售合同关键信息提取与验证”的管道为例拆解实现步骤。步骤1定义管道DAG以Airflow为例在Airflow中我们创建一个DAG文件contract_processing_pipeline.py。from airflow import DAG from airflow.operators.python import PythonOperator from datetime import datetime # 假设我们已经实现了各个智能体的调用函数 from agents import parse_document_agent, classify_document_agent, extract_info_agent, validate_logic_agent, human_review_operator, generate_report_agent default_args { owner: madp_team, retries: 1, } with DAG( dag_idcontract_madp_pipeline, default_argsdefault_args, descriptionA Multi-Agent Pipeline for Contract Processing, start_datedatetime(2024, 1, 1), schedule_intervalNone, # 由外部触发 catchupFalse, ) as dag: # 任务1文档解析 task_parse PythonOperator( task_idparse_document, python_callableparse_document_agent, op_kwargs{file_path: {{ dag_run.conf[file_path] }}}, # 从触发参数中获取 ) # 任务2文档分类可与任务1并行 task_classify PythonOperator( task_idclassify_document, python_callableclassify_document_agent, op_kwargs{file_path: {{ dag_run.conf[file_path] }}}, ) # 任务3信息抽取依赖解析结果 task_extract PythonOperator( task_idextract_entities, python_callableextract_info_agent, op_kwargs{parsed_data: {{ ti.xcom_pull(task_idsparse_document) }}}, # 从parse任务拉取结果 ) # 任务4逻辑验证依赖抽取结果和分类结果 task_validate PythonOperator( task_idvalidate_logic, python_callablevalidate_logic_agent, op_kwargs{ extracted_entities: {{ ti.xcom_pull(task_idsextract_entities) }}, doc_type: {{ ti.xcom_pull(task_idsclassify_document) }} }, trigger_ruleall_done, # 即使上游有失败也执行以便记录错误 ) # 任务5人工审核条件执行依赖验证结果 task_human_review PythonOperator( task_idhuman_review, python_callablehuman_review_operator, op_kwargs{validation_result: {{ ti.xcom_pull(task_idsvalidate_logic) }}}, ) # 设置触发条件当验证结果中need_human_review为True时执行 task_validate task_human_review # 注意在真实场景中需要自定义Operator来实现条件触发Airflow本身有BranchPythonOperator等 # 任务6生成报告依赖验证或人工审核的最终结果 task_report PythonOperator( task_idgenerate_final_report, python_callablegenerate_report_agent, op_kwargs{final_data: {{ ti.xcom_pull(task_idsvalidate_logic) }}}, # 简化逻辑实际需合并人工审核结果 ) # 定义任务依赖 [task_parse, task_classify] task_extract task_validate task_validate task_report # human_review 任务在特定条件下执行并可能更新数据流这里简化了依赖关系。步骤2实现一个智能体以信息抽取智能体为例使用LangChain构建一个工具调用型智能体。import os from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.tools import tool from pydantic import BaseModel, Field from typing import List, Optional # 1. 定义智能体可用的工具 tool def search_for_clause(text: str, clause_keyword: str) - str: 在合同文本中搜索包含特定关键词的条款。 # 实现简单的文本搜索逻辑 lines text.split(\n) results [line for line in lines if clause_keyword.lower() in line.lower()] return \n.join(results) if results else f未找到包含 {clause_keyword} 的条款。 tool def extract_using_regex(text: str, pattern: str) - str: 使用正则表达式从文本中提取信息。 import re matches re.findall(pattern, text) return , .join(matches) if matches else 未匹配到模式。 # 2. 定义智能体的输出格式Pydantic模型 class ExtractedContractInfo(BaseModel): contract_id: Optional[str] Field(description合同编号) party_a: Optional[str] Field(description甲方名称) party_b: Optional[str] Field(description乙方名称) total_amount: Optional[str] Field(description合同总金额) signing_date: Optional[str] Field(description签署日期) confidence: float Field(description本次信息抽取的整体置信度0-1之间) # 3. 构建智能体 llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0) # 使用低temperature保证稳定性 tools [search_for_clause, extract_using_regex] prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的合同信息抽取助手。你的目标是从用户提供的合同文本中精准地提取出合同编号、甲方乙方、总金额、签署日期等关键信息。 你可以使用工具来帮助你定位和提取信息。 请严格按照要求的JSON格式输出结果并给出一个整体置信度。如果你对某个字段不确定可以留空并降低整体置信度。), MessagesPlaceholder(variable_namechat_history, optionalTrue), (human, 合同文本{input_text}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) agent create_openai_tools_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 4. 封装为Airflow任务可调用的函数 def extract_info_agent(parsed_data: dict) - dict: Airflow任务调用的函数。 parsed_data: 来自文档解析智能体的输出包含text等字段。 input_text parsed_data.get(text, ) if not input_text: return {error: 无有效文本输入, confidence: 0.0} try: # 调用智能体执行 result agent_executor.invoke({ input_text: input_text, chat_history: [] # 本例中无历史 }) output result[output] # 这里需要将LLM的自然语言输出解析成ExtractedContractInfo格式。 # 更佳实践是使用LangChain的OutputParser或LLM的JSON Mode。 # 假设我们通过Prompt工程让LLM直接返回了JSON字符串。 import json extracted_info json.loads(output) # 简化处理实际需更健壮的解析 extracted_info[agent] extract_info_agent_v1 return extracted_info except Exception as e: # 记录日志并返回错误触发下游或HITL print(f信息抽取智能体失败: {e}) return {error: str(e), confidence: 0.0, agent: extract_info_agent_v1}步骤3实现HITL集成HITL界面需要展示任务上下文、智能体结果、冲突点并允许人工输入修正结果。一个简单的Streamlit应用示例如下# hitl_dashboard.py import streamlit as st import requests # 从后端API获取待审核任务列表 def fetch_pending_tasks(): # 调用协调器暴露的API response requests.get(http://orchestrator-api/tasks/pending) return response.json() # 获取特定任务的详情 def fetch_task_detail(task_id): response requests.get(fhttp://orchestrator-api/tasks/{task_id}/context) return response.json() # 提交人工审核结果 def submit_review(task_id, corrected_data, reviewer_notes): payload { task_id: task_id, action: approve_with_correction, # 或 reject, approve corrected_data: corrected_data, notes: reviewer_notes } response requests.post(http://orchestrator-api/tasks/review, jsonpayload) return response.ok # Streamlit UI st.title(MADP 人工审核中心) tasks fetch_pending_tasks() selected_task_id st.selectbox(选择待审核任务, [t[id] for t in tasks]) if selected_task_id: task_detail fetch_task_detail(selected_task_id) st.subheader(f任务详情 - {selected_task_id}) st.json(task_detail) # 展示完整的任务上下文 st.subheader(智能体结果与冲突) # 解析并高亮显示冲突信息例如来自validate_logic_agent的警告 conflicts task_detail.get(validation_results, {}).get(conflicts, []) for conflict in conflicts: st.warning(f冲突: {conflict}) st.subheader(人工修正) # 根据任务类型生成可编辑的表单。例如对于合同信息 corrected_contract_id st.text_input(合同编号, valuetask_detail.get(extracted, {}).get(contract_id, )) corrected_amount st.text_input(合同金额, valuetask_detail.get(extracted, {}).get(total_amount, )) reviewer_notes st.text_area(审核备注) if st.button(提交审核): corrected_data { contract_id: corrected_contract_id, total_amount: corrected_amount, # ... 其他字段 } if submit_review(selected_task_id, corrected_data, reviewer_notes): st.success(审核结果提交成功) else: st.error(提交失败请重试。)5. 常见问题、排查技巧与优化方向5.1 实施过程中的典型问题与解决方案问题现象可能原因排查步骤与解决方案管道整体延迟过高1. 智能体串行依赖过多。2. 某个智能体尤其是LLM调用响应慢。3. 网络或API延迟。1.分析DAG使用Airflow的甘特图等工具找出关键路径和耗时最长的任务。2.并行化将无依赖的任务改为并行执行。3.优化慢速智能体考虑缓存、使用更轻量模型、或优化Prompt减少token消耗。4.设置超时与重试为每个智能体任务配置合理的超时时间并设置重试策略。智能体输出格式不稳定LLM的“幻觉”或Prompt指令不清晰导致输出JSON格式错误或字段缺失。1.强化输出约束使用LLM的JSON Mode如果支持或采用更严格的Output Parser如PydanticOutputParser。2.设计验证层在智能体输出后立即添加一个轻量级验证步骤检查必填字段和基本格式格式错误则触发重试或直接失败。3.改进Prompt在Prompt中提供更清晰的输出示例Few-shot。HITL环节成为瓶颈审核任务堆积人工处理速度跟不上自动化生成速度。1.优化触发策略提高自动通过的置信度阈值只将真正不确定的案例送审。2.任务优先级根据业务规则为审核任务设置优先级如金额大的合同优先。3.部分自动化在审核界面提供“建议选项”让人工做选择题而非填空题加快处理速度。4.主动学习将人工纠正的案例快速反馈到训练集定期重新训练相关智能体减少未来同类错误。系统扩展性差智能体都是重量级LLM成本高且无法水平扩展。1.异构架构采用“大模型小模型”混合策略。关键复杂推理用大模型简单分类、匹配用小模型或规则。2.智能体池化将无状态的智能体部署为多个实例通过负载均衡器分发任务。3.异步处理使用消息队列如RabbitMQ解耦智能体协调器发布任务智能体监听队列并消费实现自然伸缩。5.2 性能与成本优化实战技巧LLM API调用优化批处理Batching对于大量小的、独立的文本片段如多个合同条款可以将它们组合成一个批处理请求发送给LLM API通常比多次单独调用更便宜、更快。流式响应Streaming对于生成摘要或长文本的智能体使用流式响应可以改善用户体验让后续环节不必等待全部生成完毕即可开始处理。缓存层为LLM智能体引入缓存如Redis。对相同的输入Prompt直接返回缓存的结果。这在处理大量格式雷同的文档如同一模板的发票时效果极佳。管道流程优化提前退出Early Exit在管道前端设置“质量检查点”。如果文档解析质量极差如OCR置信度过低可以直接标记为失败并送入HITL避免浪费后续智能体的计算资源。动态管道根据文档分类结果动态组装不同的处理管道。例如“普通通知”走简易管道“采购合同”走完整管道。监控与可观测性为每个智能体调用记录详细的日志输入、输出、耗时、token使用量、置信度、API成本。在协调器层面监控整个管道的SLA服务等级协议如端到端处理时间、成功率、HITL触发率。设置告警当某个智能体的失败率突增、平均延迟超标或HITL队列积压时及时通知运维人员。5.3 未来演进方向MADP框架本身是开放的可以随着技术发展不断演进智能体间的强化学习协作这正是网络热词“actor-attention-critic for multi-agent reinforcement learning”所指向的前沿方向。我们可以为智能体设计奖励函数如处理速度、结果准确性让它们通过强化学习自主优化协作策略而不仅仅是遵循预设的固定流程。例如让“分类智能体”学会在置信度不高时主动调用“解析智能体”获取更多布局信息再做判断。更复杂的智能体生态引入具有长期记忆和规划能力的智能体使其能够处理跨文档的复杂任务例如对比多份历史合同中的条款变化。低代码/无代码配置开发图形化界面让业务专家可以通过拖拽的方式配置新的文档处理管道定义智能体角色和规则降低技术门槛。构建MADP系统是一个持续迭代的过程。从一个小而精的管道开始解决一个具体的业务痛点然后逐步增加智能体、优化流程、集成HITL。其核心价值在于提供了一种可持续、可进化、人机共融的复杂文档处理范式将人类的领域智慧与AI的自动化效率紧密结合最终实现112的效果。