1. 为什么做这个项目把“多窗口地狱”收敛成一个统一工作台我这几年最深的感受是单点拆开看每个 AI 工具都不错但一旦要处理真实业务立刻变成多窗口地狱。左边开着浏览器版的对话编辑器右边挂着在线表格中间还要来回复制粘贴给某个智能体喂上下文底下再铺一排工作流的执行日志。东西越多上下文越碎最后谁在哪份文档上改了哪一列、哪条工作流跑的是哪版数据全靠人的记忆硬扛。做这个开源项目的出发点很直接我要一个桌面工作区把文档、表格、智能体、工作流四样东西收敛到同一个数据面上。文档不是附件表格不是导入的静态副本智能体不是孤立聊天框工作流也不是一次性脚本。它们共享同一套对象模型互相之间可以互相调用所有运行过程留在本机不上第三方云。这个项目适合谁参考呢一是每天跟大量业务文档和报表打交道的运营、财务、HR 这类角色二是想要本地化落地 AI 工作流的开发者和运维同学三是对开源解决方案有要求的团队不希望内部业务数据被在线服务反复读取。标题里的“开源”两个字意味着你拿回去之后能看得见完整实现能按自己的场景改而不是用了一个表里不一的黑盒。工作区的定位决定了它的边界它不是一个通用操作系统也不是又一个笔记 SaaS它更接近“面向文档和数据的个人 AI 工作站”。一句话概括目标你在一台电脑前完成从文档整理、表格计算、智能体协作到工作流编排的全部日常工作并且每一步都有日志、可重跑、可追溯。1.1 我在动手之前踩过的分散工具痛点很多人都经历过这个循环先是觉得 AI 对话很好用于是把问题一股脑丢进去接着积累的提示词多了开始想要复用后来发现回复要落到 Excel 里做二次加工又要人工复制粘贴再往后团队里同事协作各自有各自的 prompt完全没有版本和流程控制。痛点不是“缺一个更好的聊天框”而是缺一层能把文档、表格、智能体、工作流放在同一套上下文里的编排层。我踩得比较重的一个坑是用在线表格管理客户资料里面的联系人、合同ID、跟进状态都靠手动维护然后每个月月末跑一次汇总。为了生成一个可视化的月度摘要我要把表格导出成 CSV再写一次性脚本交给另一个 AI 客户端去分析分析完还得手动把结论贴回文档。整个链路全靠人肉粘合每次都要现想字段映射、格式转换和异常处理特别容易在其中一个环节漏改。这个项目就是想用工程手段取代这种“人肉胶水”。不是去发明花哨的新技术而是把成熟的解析、检索、编排、本地推理技术组合到一起让它们像流水线一样互相配合。1.2 什么样的工作区才是“桌面级”而不是“套壳”市面上的 AI 工作区并不少但很多只是网页端套了个壳打开本质还是聊天界面文档得先上传表格要先转格式智能体只能在给定面板里点选工作流和文档之间没有强关联。这类产品用完会发现数据还是散在各处能力边界完全由厂商画好。我理解中的桌面级工作区必须满足四条硬标准文档和表格在工作区内是一等公民可以被解析、索引、检索还能作为智能体工具的输入和输出智能体能感知工作区的资源被动检索和主动写入都得有权限边界工作流引擎能编排多步骤任务支持并行、重试、条件分支、人工审核闸门所有数据默认留在本机模型调用可以走本地推理也可以按需接入通用 API但中间数据和日志不出工作区。满足这些条件才能说它是一个工作区而不是一个聊天室加几个按钮。开源的实现还意味着每一项标准都能被审计而不是听厂商自己说“支持”。1.3 整体技术选型清单开源优先、本地优先这个项目的技术栈我用了一张清单来定原则只有一个能开源的优先不能开源的找替代坚决不把核心依赖押在某一家在线服务上。模块选型理由桌面壳Tauri 或 Electron二选一Tauri 更轻Electron 生态更成熟我的实践是 Tauri 为主保留 Electron 备选文档解析PyMuPDF Pandoc OpenpyxlPDF 文本保留版式Office 文档转 MarkdownExcel 读原生对象OCRTesseract PaddleOCR扫描版 PDF 和图片表格兜底向量存储LanceDB 或 sqlite-vec本地优先零运维适合个人工作区工作流引擎自研 DAG 引擎 可选 n8n 协议适配自研保证和文档模型的深度集成适配器兼容已有工作流模型接口Ollama 本地推理 OpenAI 兼容层默认走本地模型通过兼容层可以切换任意模型服务Agent 框架LangGraph 风格的状态图实现任务图清晰、断点续跑友好比纯 ReAct 循环更好掌控选这些组件不是因为他们彼此最热门而是因为他们能拼成一个线性可维护的本地闭环。我最在意的是整个链路里没有多余的网络跳转没有隐藏的在线注入没有重启就丢状态的情况。2. 工作区数据底座文档与表格如何被统一建模工作区要想管理好文档、表格、智能体、工作流首先得解决数据底座的统一问题。一个很常见的错误是文档按文件类型各自处理表格导成 CSV图片直接丢给视觉模型最后智能体和流程各自维护一套私有格式。这种做法的后果是跨流程数据复用难度陡增字段说法不统一。我采用的建模方式不复杂所有进入工作区的文件都被抽成一个统一数据对象包含元数据、正文内容、结构索引和来源引用四部分。对象字段含义说明metadata文件名、路径、文件类型、导入时间、哈希值用于追踪版本和权限content可读文本或高密度数据结构PDF/Word 转成段落Excel 转成带地址的单元格index向量索引 词法倒排索引支持语义检索和精确检索source原始文件路径和截断定位让每个 AI 生成的结果都能回溯到原始行或页这一步的意义在于不管是 PDF 里的合同还是 Excel 里的库存表只要进入工作区就被想象成一棵带地址的树。文档的叶子节点是段落和表格电子表格的叶子节点是单元格智能体和流程全部基于这套树结构操作而不是基于某个特定软件的文件格式。2.1 文档解析层PDF、Office、Markdown 入库的完整流程解析是工作区体验好不好的第一道关口。我自己一开始图省事直接调 Pandoc 把 docx 一次性转文本结果表格全乱、层级丢了后期检索质量很差。后来老老实实分类型处理PDF先用 PyMuPDF 提取文本层如果文本不为空按“页 段落”切分如果文本层稀少进入 OCR 分支。OCR 对扫描件不是可选项是必经之路而且语言包不能漏装比如中文简体、繁体、英文都要有。Word 文档用 Pandoc 转成 Markdown同时保留标题层级和大纲结构。转换后要做格式检查尤其注意目录、页眉页脚、批注这些 Pandoc 容易吞掉或乱放的部分。表格这一步最不能偷懒不要直接把 Excel 转成 CSV 或者 HTML。Openpyxl 能保留单元格地址、合并单元格、公式缓存值、批注和数据验证规则这些元信息到后面智能体读取时都有用。Markdown 和其他文本直接进入内容分析流程但因为格式简单会把代码块和长段落做特殊标记避免向量化时被截断。每一步解析都要产出同一个输出结构块列表。一个块是一个带类型和地址的节点比如“段落:翻页第3页第1段”或“单元格:销售明细B12”。工作流后续挂到这些块上就像给文档装上了坐标系统。2.2 表格模型用“单元格地址”而不是“扁平表格”管理 Excel 数据表格处理和文档处理最大的区别是表格有结构行和列本身携带信息而且经常有多层表头、合并单元格和公式。要是提前把它拍平成二维数组再用常规 RAG 去切块基本等于把坐标和上下文丢进碎纸机。我实现的表格模型保留了三个关键概念单元格地址形如销售明细C15这样的定位符让智能体和流程能精确读写特定的格子而不是靠“第三列第十五行”这种模糊表示。区域引用形如销售明细A1:F60这样的范围支持批量统计、筛选和透视操作兼容 Excel 里“区域”的自然语义。公式链把原本的公式缓存值和公式字符串都保存下来这样摘要生成时不仅看到数字还知道数字是怎么算出来的。比如“本月客单价”一栏直接给智能体一个总收入/订单数的上下文结果会比只看数值更准。这样做还有一个额外收益当工作流跑完之后AI 可以直接把计算结果填充到新的单元格区域同时保留一个“来源是 AI 生成”的标记。没人想要一份看起来像人写的、其实有错但无法定位的表。2.3 让文档和表格可被检索向量索引与精确索引的双通道任何 AI 工作区检索能力都会决定智能体回答的天花板。只靠向量检索的常见问题是数值型查询“上月销售额最高的客户ID是多少”效果奇差因为 embedding 对数字并不敏感。只靠关键词检索的常见问题是同义表达和意图改写几乎无解。所以我的方案是双通道。向量索引负责语义召回词法索引负责精确命中。查询时先解析用户请求类型如果明显是数值条件或指定字段名查询就直接走词法结构化过滤不经过向量。如果请求是“总结这份报告里关于风险的部分”才走向量语义召回。落到工程上向量部分我本地跑一个 embedding 模型用最小维度就够块级别检索精确部分用自定义倒排索引只索引文档索引里那些标记为“标题、表格头、单元格列名”的节点。这样既避免了在线嵌入服务把敏感文本传出去又将表格检索从“模糊找”升级成了“指哪打哪”。3. 智能体与工作流的运行时设计有了统一数据底座接下来的核心是把智能体和工作流放进同一个运行时空。这两者不是替代关系智能体擅长在开放语境下做判断和生成工作流擅长把确定性的步骤固化下来保证可重复。真实业务里它们得混着用。我给运行时的定位是一张状态图节点可以是普通计算节点、自动化步骤也可以是智能体节点。工作流负责沿着既定边执行智能体在需要理解和生成的节点被安排进入。流程跑完后每一步的输入输出、模型调用记录、人工审批动作全部写进运行日志。3.1 把智能体当“服务”而不是当“聊天框”很多人在工作区里加了智能体其实只是把普通的对话 UI 搬了过来。单独聊没问题但要在工作流里复用智能体就必须把它改造成服务接口。这里的核心是定义清楚输入、输出和工具权限。以“合同风险审查”这个智能体为例它的输入不是一句自由对话而是{文档ID, 区域范围, 审查重点}这样一个结构化参数。输出也不是聊天消息而是{发现的问题列表, 每项风险等级, 涉及条款定位}的结构化结果。这样工作流才能拿住结果去分支高风险走人工复审低风险自动归档。工具权限同样要收紧。智能体被允许调用哪些文档读取能力、哪些单元格写入能力必须按角色或任务目标做隔离。工作区可以提供一组工具描述给模型模型在推理过程中自主调用工具取上下文这比把整个文档塞进上下文窗口可靠得多token 开销也小。我实际验证过一个细节给智能体的工具描述写得越像“给多分类任务做 Few-shot 的 prompt”它调用工具的准确率越高。你必须在工具名里说明“返回区域的前三行示例”这样模型才知道该取几行才能判断下一跳动作。3.2 工作流编排并行、重试、人工闸门一个都不能少工作流引擎最常见的死法是只支持线性执行。任务一旦多了一个个排队跑慢又脆弱。我设计时把能力面打开成四个维度并行执行相互独立的节点可以并行跑典型场景是同一份季度表格要做不同维度的多维分析。此时我会按维度拆节点并行交给模型最后结果汇总。条件分支节点根据前一步的结构化输出去不同的下一跳。比如表格里“数值异常”的标记决定是否触发二次校验节点。重试与降级模型调用偶发失败要做指数退避重试连续失败就转入人工处理队列而不是让流程静默失败。人工闸门关键节点保留人审。比如自动生成的对外报告在最终签发前强制加人工确认智能体建议的批量数据更新默认只写草稿区经人确认后才落库。这四个能力是工作流可投入生产的底线缺一个都会在生产环境里爆雷。我在项目里优先把这套能力做成对任意节点透明的基础设施而不是让每个节点自己处理并发和容错。3.3 工作流里接智能体用工具调用把文档、表格变成上下文智能体和工作流深度融合的关键点在于“工具调用”的上下文管理。我的实现里智能体节点通过一套工具函数与工作区数据底座交互tools { retrieve_document_blocks: doc_store.query_blocks, read_cell_range: table_store.read_range, write_cell_range: table_store.write_range, run_sql_on_table: table_store.query_sql, }模型在请求处理时会自行规划先调用read_cell_range(销售明细, A1:F60)拿一小块预览再调用更精确的区域查询最后调用run_sql_on_table做聚合统计最后在一个新文档里生成分析报告。整个过程中工作流提供的是执行框架、限制的是授权范围模型提供的是理解和表达。这样我们实际上把智能体的“对话上下文”换成了“工作区上下文”。上下文不再是一次性粘贴进去的那几段话而是通过工具实时从工作区拉取的一段段结构化数据。基于这套调用机制员工可以让智能体“看一下最近两个季度的报表找出环比下降超过 5% 的品类整理成表格再让流程自动生成一封给主管的摘要邮件草稿”全程不用手工搬运。4. 桌面端落地从架构到开箱即用的工程细节前面的模型和运行时设计最终要落到一个真实可用的桌面应用里否则只停留在理论或命令行演示。这一部分涉及的工程细节很琐碎但直接决定项目能不能被普通同事上手使用。4.1 桌面外壳、本地模型与数据安全边界桌面壳我首选 Tauri因为它内存占用低启动快前端可以放心用 React 来做工作区界面。后端进程则用 Rust 写一个薄壳负责调用 Python 侧的解析、索引引擎避免纯 Python 部署带来的复杂依赖问题。本地模型优先是这类的安全边界。所有文档解析、向量索引、表格读写默认都在本机完成模型调用优先走 Ollama 等本地推理服务只有用户显式配置了外部 API 兼容端点时部分任务才会通过 API 执行。默认策略是不传输任何原文。这意味着哪怕工作区同时打开了几百 MB 的报表原始文件也不会因为一次智能体对话被整体发送到远程。配置项我也做了简化只需要在配置文件中指定本地模型服务地址、嵌入模型路径和默认工作目录三样东西剩下全部可以按默认值跑起来。model: llm_base_url: http://127.0.0.1:11434/v1 llm_model: qwen2.5:14b embedding_model: bge-m3 workspace: data_dir: ./data enable_network: false4.2 部署与启动的一些细节处理从仓库拉下代码之后最顺利的话三步能跑通安装 Rust 和前端依赖初始化 Python 虚拟环境执行npm run tauri dev。但实际上第一步就会遇到两个常见问题一是 C 构建工具链缺失导致 PyMuPDF、Pandas 这类带二进制依赖的包编译失败二是系统缺少中文语言包和 Tesseract 的 OCR 支持文件。这些问题解决起来不难但网上教程经常跳过容易让新人卡很久。部署完成后我会立刻做三件校验第一导入一份 20 万行的 CSV 和一份只有 3 页的扫描版 PDF分别确认表格解析和 OCR 能正常工作第二打开检索测试面板分别用语义关键词和精确字段名各查一次第三跑一个“文档摘要表格统计”的最小工作流确认智能体能依次调工具、最后写回结果。这三项全过工作区的基础才算真的稳定。4.3 我踩过的典型坑与对应的修复方式任何项目都会有坑这个项目隐性最深的是几类问题问题现象修复方式Excel 合并单元格错位智能体读到的数据错位统计结果明显偏大在解析阶段保留合并单元格映射按实际区域填写重复值PDF 扫描版无文本层向量索引全部为空检索返回空启用 OCR 分支并单独给 OCR 索引做标记超大表格一次性入上下文模型响应超时或 token 溢出强制所有表格读操作走区域分页默认每次最多 200 行本地模型上下文窗口不足多文档摘要越写越乱改用“摘要-再聚合”两段式先按文档小块生成中间摘要这些坑的共性是不是模型能力不够而是数据进模型之前就没有被整理好。把数据准备好比换更强的模型更有效。5. 一个可以直接抄走的工作流示例从“原始销售表”到“月度复盘文档”讲完底层的组件和细节来一个能直接照搬的完整示例最好理解。这个工作流的输入是一张原始销售明细表输出是一份包含业务发现和风险提示的月度复盘文档。5.1 搭建阶段把表格喂进工作区第一步是导入表格。将导出好的销售明细表比如 3 万行、字段包括订单日期、客户ID、品类、金额、销售人员放进数据目录工作区会在导入阶段自动解析为带单元格地址的表格对象同时建立列索引和示例值摘要。导入完成后我需要用一段 SQL 验证一下数据完整性检查 NULL 值和明显异常值。验证通过后把这个表格绑定到工作流上作为数据源。绑定动作背后实际做的是把表格对象的元数据和访问权限交给工作流后续节点可以读取但不能随意覆盖原表。5.2 工作流节点配置的逐项说明这个工作流建议配置 6 个节点节点类型说明1 数据读取普通节点读取表格前 N 行和月度聚合结果2 月度汇总计算节点按月份分组计算销售额、订单数、客单价3 品类分析智能体节点基于月度汇总结果判断品类变化和异常品类4 风险识别智能体节点用上一节点输出定位环比下降超阈值品类5 文档生成智能体节点汇总前四步结果按标准模板生成复盘文档6 人工闸门人工节点最终文档需人工确认后才能保存到工作区每一步都要设置好输入参数和输出字段。比如品类分析节点用一句针对性 prompt 来指导智能体“你只能基于输入的表格区域回答问题不要自行引入外部信息输出必须包含品类名称、环比变化率、可能原因三项如果数据不足明确写‘信息不足’而不是编造原因。”这样约束后自动生成的内容才具备作为业务草稿的质量底线。5.3 运行效果与验证方式运行工作流后观察日志会看到清晰的节点执行顺序数据读取后计算节点先完成聚合再并行触发品类分析和风险识别两个智能体节点最后文档生成把所有结果收拢。整个流程通常在几十秒内完成具体耗时取决于本地模型的推理速度。验证时我的做法是抽取同一个月的数据人工独立计算一遍月度汇总和流水线输出对比再抽查两个风险品类的分析结论检查是否与原始表格内数字相符。校验通过后这份自动生成的文档可以作为内部复盘的初稿再做人工润色。这套工作流真正解决了“人肉胶水”的痛点以前要导出 CSV、开脚本、喂给模型、手动粘贴现在一键触发全部步骤留在日志里随时可以重跑和审计。6. 选择开源组件时的一些经验判断因为入口是开源最后补一点我的真实体会。选开源组件不能只看 GitHub 星数尤其在一个要长期维护的桌面工作区里判断标准必须更加具体。6.1 我评估组件时真正看重的几项我一般看四件事License 兼容性项目要开源出来给别人用核心依赖的 License 必须一路顺下来尤其注意像某些 GPL 传染性强的库掺进来之后整个项目的分发约束会变。维护活跃度看最近半年有没有 commit、issue 响应速度、发版频率。一个半年没动的解析库在新格式面前基本等于失去维护。替换成本组件与核心数据模型的耦合度要低。拿向量存储来说如果业务代码里到处直接调用某个向量库的私有 API后续想换迁移成本太高我会在存储层做统一的读写接口让替换只在适配层发生。隐私边界组件默认行为是否会把数据发出去。这一点对本地优先工作区是硬指标凡是默认带遥测、自动更新的库都要谨慎评估。6.2 这个项目后续还能怎么扩展项目做到现在最让我满意的不是某个炫酷界面而是它形成了不容易散架的内核。后续想扩展的方向也很多一是把工作流节点做得更可视化让不写代码的业务同事也能拖拽配逻辑二是增加更细粒度的权限模型比如部门之间只能看到自己相关文档和表格三是把本地模型和云端模型做成流程内可切换的混合调度敏感步骤一定留本地非敏感步骤可以走更强模型提升质量。如果读者想基于这个思路做自己的开源工作区我给的具体建议是先把文档和表格的数据底座做好再上智能体和流程。很多人反过来先做聊天和流程结果数据不通最后一切功能都悬空。最后说一个自己在实际维护中的小体会永远给所有节点和智能体调用留日志并且让日志可以被重新回放。排查工作流问题时看不到过程比出错本身更可怕。能做到这一点这个开源桌面工作区就算有真正的生产力了。