挑战
大规模处理业务文档充满了痛点：
- 数据孤岛 — 关键信息分散在数十个电子表格、PDF和Word文档中，无法进行跨文档查询
- 手动交叉引用 — 将供应商价格表（Excel）与合同条款（PDF）和发票历史（CSV）进行比较需要数小时的手动查找
- 公式局限性 — 复杂的分析问题无法仅通过电子表格公式解决
- 上下文窗口限制 — 大型电子表格（50,000+行）超出了LLM的上下文窗口，导致简单方法失效
- 无编辑功能 — 现有AI工具可以分析文档，但无法将更改写回源文件
- 多步骤推理 — 需要跨文档进行顺序分析的问题需要编排的多步骤工作流
我们的解决方案
我们构建了一个多智能体AI文档智能平台，该平台利用向量数据库支持大型文档的检索，针对不同文档类型设计了专业智能体，具备用于跨文档推理的编排器，以及用于电子表格编辑的回写功能。
架构
- 编排器：协调跨专业智能体的多步骤工作流的AI编排智能体
- 电子表格智能体：处理Excel/CSV/Google Sheets分析、公式生成和单元格编辑
- 文档智能体：处理PDF/Word文档阅读、提取和摘要
- 交叉引用智能体：执行跨文档类型的连接、比较和核对
- 向量数据库：使用Milvus进行文档块和电子表格行的语义索引
- LLM层：采用多模型方法并支持函数调用
- 后端：使用Python/FastAPI进行文档处理和智能体编排
- 前端：使用React仪表板，支持文件上传、聊天界面和实时电子表格预览
- 存储：S3用于存储原始文件，PostgreSQL用于元数据和任务跟踪
多智能体架构
智能体角色
1. 编排智能体中央协调器，负责接收用户查询，将其分解为子任务，并委派给专业智能体。它分析用户意图，创建执行计划，管理智能体之间的数据流，聚合结果，并处理错误恢复。
2. 电子表格智能体专门用于表格数据操作，包括模式理解、自然语言到查询的转换、聚合和过滤、公式生成、单元格编辑和列填充、图表建议以及数据验证/异常检测。
3. 文档智能体专门用于非结构化和半结构化文档，包括OCR和布局感知文本提取、章节识别、从合同中提取键值对、摘要、语义条款搜索以及从PDF/Word docs中提取表格。
4. 交叉引用智能体专门用于多文档推理，包括跨文档实体匹配、数据核对和差异识别、时间线分析、冲突数据的依赖关系解决以及跨文档类型的SQL式连接操作。
向量数据库层
为何文档需要向量数据库
大型文档和电子表格无法完全放入单个LLM上下文窗口。向量数据库支持对数百万行和文档块进行语义搜索，每次查询只检索相关部分，通过嵌入相似性实现跨文档实体链接，以及无需每次查询都重新处理的持久化索引。
索引策略
电子表格索引：每行通过连接关键列值转换为自然语言表示，然后进行嵌入并存储，同时包含指向原始文件、工作表和行索引的引用，以支持回写操作。
文档索引：文档以布局感知的方式进行提取，分块为具有重叠的语义段，进行嵌入，并存储对源文件、章节和页码的引用。
跨文档实体索引：一个独立的索引链接跨文档的实体（供应商、产品、人员、发票号码），从而使交叉引用查询能够快速找到某个实体的所有提及，无论其源文件如何。
检索流程
当用户提出跨文档问题时，编排器会识别需要哪些文档和智能体，执行向量搜索以查找所有来源的相关数据，委派给专业智能体进行处理，并将结果聚合为一致的响应。
编排引擎
查询分解
编排器将复杂查询分解为多步骤执行计划。例如，像“查找延迟交货的供应商，检查合同罚款条款，并计算可索赔的罚款”这样的问题将被分解为以下顺序步骤：通过电子表格智能体查询交货数据，通过文档智能体搜索合同，并通过交叉引用智能体连接结果。
智能体通信
- 智能体通过带有类型化载荷的结构化消息进行通信
- 编排器维护包含中间结果的执行上下文
- 失败的步骤会触发重试或回退策略
- 如果某些步骤完成而其他步骤失败，则返回部分结果
电子表格编辑与回写
编辑能力
该平台支持单元格更新、列填充、行插入、条件格式设置、新工作表创建和公式注入——所有这些都由AI智能体提出并经用户批准后应用。
回写流程
- 智能体确定编辑操作（哪些单元格，什么值）
- 向用户显示带有差异高亮（旧值与新值）的编辑预览
- 用户批准或修改建议的更改
- 后端使用针对每种格式的相应库将更改应用于文件
- 修改后的文件保存为新版本，并附带编辑审计跟踪
- 更新更改行的向量索引
版本控制
- 每次编辑都会创建一个新的文件版本（原始文件保留）
- 差异日志准确显示更改了什么、何时以及为何更改
- 一键回滚到任何以前的版本
- 编辑归因：哪个智能体或用户进行了每次更改
新文档处理流程
文件上传流程
- 用户上传文件（拖放或API）
- 检测文件类型并路由到相应的处理器
- 电子表格：解析、推断模式、行嵌入并索引
- PDFs：OCR（如果扫描）→ 布局提取 → 分块 → 嵌入 → 索引
- Word Docs：文本提取 → 章节解析 → 分块 → 嵌入 → 索引
- 实体提取：NER识别所有文档中的人物、组织、日期、金额
- 跨文档链接：实体索引会随着新的提及进行更新
- 文件元数据存储在PostgreSQL中，嵌入存储在向量DB中，原始文件存储在S3中
支持的格式
该平台支持Excel、CSV和Google Sheets（具有完整回写功能）、本机和扫描PDF（只读），以及Word docs和Google Docs（具有有限回写功能）。
主要功能
- 多智能体架构 — 针对电子表格、文档和交叉引用提供专业智能体
- AI编排器 — 将复杂查询分解为多步骤执行计划
- 跨文档引用 — 跨文件类型的实体链接和数据核对
- 向量驱动的检索 — 语义搜索处理超出LLM上下文限制的数据集
- 电子表格回写 — AI在用户批准下编辑单元格、填充列和注入公式
- 大数据集支持 — 50,000+行的电子表格可通过向量搜索进行索引和查询
- 版本控制 — 每次编辑都进行版本控制，并带有差异日志和回滚功能
- 自然语言查询 — 用简单的英语提出复杂的分析问题
- 多格式支持 — Excel、CSV、Google Sheets、PDF、Word、Google Docs
- 编辑预览 — 任何更改应用前的差异高亮预览
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
常见问题
MicrocosmWorks 设计了一个多智能体架构，其中专业智能体处理文档分析的不同方面，例如用于电子表格的表格提取智能体、用于叙述性文档的文本摘要智能体，以及一个识别跨多个文件数据点之间关系的交叉引用智能体。这种分工产生比单个整体式 LLM 调用更准确的结果，因为每个智能体在一个聚焦的上下文窗口内操作，并应用领域特定的提示策略。
是的，MicrocosmWorks 构建了一个电子表格解析引擎，该引擎能够解析公式依赖关系、展开数据透视表摘要，并在将结构化数据传递给分析代理之前追踪跨工作表引用。系统将复杂的 Excel 构造转换为扁平化的数据表示形式，供 LLMs 进行有效推理，并保留工作表之间的关系上下文，以便 AI 能够回答诸如“哪个部门超出了其 Q3 预算”这类需要跨多个选项卡连接数据的问题。
MicrocosmWorks实施了一个实体链接管道，该管道从所有上传的文档中提取命名实体、数字标识符和日期引用，然后构建一个知识图谱，连接文件间相关的提及。当用户提出问题时，交叉引用代理会遍历这个图谱，从多个源文档中提取相关数据，从而提供能够综合信息的答案，这种综合信息的方式若由人工分析师完成，将需要数小时的手动交叉核对。
MicrocosmWorks 设计此系统旨在处理每个分析会话最多 500 个文件的文档批次，其中，电子表格单个文件大小上限为 100MB，PDF 文件为 50MB。大型文档会自动分块，并在多个代理实例之间并行处理；编排器通过聚合代理输出，将其整合为统一的知识表示，从而保持对整个文档集的连贯视图。
MicrocosmWorks 以每小时30-50美元的费率开发多智能体文档分析平台，一个生产就绪系统通常需要3-5个月的开发周期，包括文档解析、智能体编排、交叉引用检测和用户查询界面。生产环境下的每次查询成本取决于文档量和 LLM token 使用量，但多智能体架构实际上通过仅将相关上下文路由到每个智能体，而不是将整个文档集塞入单个提示中，从而降低了 LLM 成本。