1. 為什么做這個項目把“多窗口地獄”收斂成一個統(tǒng)一工作臺我這幾年最深的感受是單點拆開看每個 AI 工具都不錯但一旦要處理真實業(yè)務立刻變成多窗口地獄。左邊開著瀏覽器版的對話編輯器右邊掛著在線表格中間還要來回復制粘貼給某個智能體喂上下文底下再鋪一排工作流的執(zhí)行日志。東西越多上下文越碎最后誰在哪份文檔上改了哪一列、哪條工作流跑的是哪版數據全靠人的記憶硬扛。做這個開源項目的出發(fā)點很直接我要一個桌面工作區(qū)把文檔、表格、智能體、工作流四樣東西收斂到同一個數據面上。文檔不是附件表格不是導入的靜態(tài)副本智能體不是孤立聊天框工作流也不是一次性腳本。它們共享同一套對象模型互相之間可以互相調用所有運行過程留在本機不上第三方云。這個項目適合誰參考呢一是每天跟大量業(yè)務文檔和報表打交道的運營、財務、HR 這類角色二是想要本地化落地 AI 工作流的開發(fā)者和運維同學三是對開源解決方案有要求的團隊不希望內部業(yè)務數據被在線服務反復讀取。標題里的“開源”兩個字意味著你拿回去之后能看得見完整實現能按自己的場景改而不是用了一個表里不一的黑盒。工作區(qū)的定位決定了它的邊界它不是一個通用操作系統(tǒng)也不是又一個筆記 SaaS它更接近“面向文檔和數據的個人 AI 工作站”。一句話概括目標你在一臺電腦前完成從文檔整理、表格計算、智能體協(xié)作到工作流編排的全部日常工作并且每一步都有日志、可重跑、可追溯。1.1 我在動手之前踩過的分散工具痛點很多人都經歷過這個循環(huán)先是覺得 AI 對話很好用于是把問題一股腦丟進去接著積累的提示詞多了開始想要復用后來發(fā)現回復要落到 Excel 里做二次加工又要人工復制粘貼再往后團隊里同事協(xié)作各自有各自的 prompt完全沒有版本和流程控制。痛點不是“缺一個更好的聊天框”而是缺一層能把文檔、表格、智能體、工作流放在同一套上下文里的編排層。我踩得比較重的一個坑是用在線表格管理客戶資料里面的聯(lián)系人、合同ID、跟進狀態(tài)都靠手動維護然后每個月月末跑一次匯總。為了生成一個可視化的月度摘要我要把表格導出成 CSV再寫一次性腳本交給另一個 AI 客戶端去分析分析完還得手動把結論貼回文檔。整個鏈路全靠人肉粘合每次都要現想字段映射、格式轉換和異常處理特別容易在其中一個環(huán)節(jié)漏改。這個項目就是想用工程手段取代這種“人肉膠水”。不是去發(fā)明花哨的新技術而是把成熟的解析、檢索、編排、本地推理技術組合到一起讓它們像流水線一樣互相配合。1.2 什么樣的工作區(qū)才是“桌面級”而不是“套殼”市面上的 AI 工作區(qū)并不少但很多只是網頁端套了個殼打開本質還是聊天界面文檔得先上傳表格要先轉格式智能體只能在給定面板里點選工作流和文檔之間沒有強關聯(lián)。這類產品用完會發(fā)現數據還是散在各處能力邊界完全由廠商畫好。我理解中的桌面級工作區(qū)必須滿足四條硬標準文檔和表格在工作區(qū)內是一等公民可以被解析、索引、檢索還能作為智能體工具的輸入和輸出智能體能感知工作區(qū)的資源被動檢索和主動寫入都得有權限邊界工作流引擎能編排多步驟任務支持并行、重試、條件分支、人工審核閘門所有數據默認留在本機模型調用可以走本地推理也可以按需接入通用 API但中間數據和日志不出工作區(qū)。滿足這些條件才能說它是一個工作區(qū)而不是一個聊天室加幾個按鈕。開源的實現還意味著每一項標準都能被審計而不是聽廠商自己說“支持”。1.3 整體技術選型清單開源優(yōu)先、本地優(yōu)先這個項目的技術棧我用了一張清單來定原則只有一個能開源的優(yōu)先不能開源的找替代堅決不把核心依賴押在某一家在線服務上。模塊選型理由桌面殼Tauri 或 Electron二選一Tauri 更輕Electron 生態(tài)更成熟我的實踐是 Tauri 為主保留 Electron 備選文檔解析PyMuPDF Pandoc OpenpyxlPDF 文本保留版式Office 文檔轉 MarkdownExcel 讀原生對象OCRTesseract PaddleOCR掃描版 PDF 和圖片表格兜底向量存儲LanceDB 或 sqlite-vec本地優(yōu)先零運維適合個人工作區(qū)工作流引擎自研 DAG 引擎 可選 n8n 協(xié)議適配自研保證和文檔模型的深度集成適配器兼容已有工作流模型接口Ollama 本地推理 OpenAI 兼容層默認走本地模型通過兼容層可以切換任意模型服務Agent 框架LangGraph 風格的狀態(tài)圖實現任務圖清晰、斷點續(xù)跑友好比純 ReAct 循環(huán)更好掌控選這些組件不是因為他們彼此最熱門而是因為他們能拼成一個線性可維護的本地閉環(huán)。我最在意的是整個鏈路里沒有多余的網絡跳轉沒有隱藏的在線注入沒有重啟就丟狀態(tài)的情況。2. 工作區(qū)數據底座文檔與表格如何被統(tǒng)一建模工作區(qū)要想管理好文檔、表格、智能體、工作流首先得解決數據底座的統(tǒng)一問題。一個很常見的錯誤是文檔按文件類型各自處理表格導成 CSV圖片直接丟給視覺模型最后智能體和流程各自維護一套私有格式。這種做法的后果是跨流程數據復用難度陡增字段說法不統(tǒng)一。我采用的建模方式不復雜所有進入工作區(qū)的文件都被抽成一個統(tǒng)一數據對象包含元數據、正文內容、結構索引和來源引用四部分。對象字段含義說明metadata文件名、路徑、文件類型、導入時間、哈希值用于追蹤版本和權限content可讀文本或高密度數據結構PDF/Word 轉成段落Excel 轉成帶地址的單元格index向量索引 詞法倒排索引支持語義檢索和精確檢索source原始文件路徑和截斷定位讓每個 AI 生成的結果都能回溯到原始行或頁這一步的意義在于不管是 PDF 里的合同還是 Excel 里的庫存表只要進入工作區(qū)就被想象成一棵帶地址的樹。文檔的葉子節(jié)點是段落和表格電子表格的葉子節(jié)點是單元格智能體和流程全部基于這套樹結構操作而不是基于某個特定軟件的文件格式。2.1 文檔解析層PDF、Office、Markdown 入庫的完整流程解析是工作區(qū)體驗好不好的第一道關口。我自己一開始圖省事直接調 Pandoc 把 docx 一次性轉文本結果表格全亂、層級丟了后期檢索質量很差。后來老老實實分類型處理PDF先用 PyMuPDF 提取文本層如果文本不為空按“頁 段落”切分如果文本層稀少進入 OCR 分支。OCR 對掃描件不是可選項是必經之路而且語言包不能漏裝比如中文簡體、繁體、英文都要有。Word 文檔用 Pandoc 轉成 Markdown同時保留標題層級和大綱結構。轉換后要做格式檢查尤其注意目錄、頁眉頁腳、批注這些 Pandoc 容易吞掉或亂放的部分。表格這一步最不能偷懶不要直接把 Excel 轉成 CSV 或者 HTML。Openpyxl 能保留單元格地址、合并單元格、公式緩存值、批注和數據驗證規(guī)則這些元信息到后面智能體讀取時都有用。Markdown 和其他文本直接進入內容分析流程但因為格式簡單會把代碼塊和長段落做特殊標記避免向量化時被截斷。每一步解析都要產出同一個輸出結構塊列表。一個塊是一個帶類型和地址的節(jié)點比如“段落:翻頁第3頁第1段”或“單元格:銷售明細B12”。工作流后續(xù)掛到這些塊上就像給文檔裝上了坐標系統(tǒng)。2.2 表格模型用“單元格地址”而不是“扁平表格”管理 Excel 數據表格處理和文檔處理最大的區(qū)別是表格有結構行和列本身攜帶信息而且經常有多層表頭、合并單元格和公式。要是提前把它拍平成二維數組再用常規(guī) RAG 去切塊基本等于把坐標和上下文丟進碎紙機。我實現的表格模型保留了三個關鍵概念單元格地址形如銷售明細C15這樣的定位符讓智能體和流程能精確讀寫特定的格子而不是靠“第三列第十五行”這種模糊表示。區(qū)域引用形如銷售明細A1:F60這樣的范圍支持批量統(tǒng)計、篩選和透視操作兼容 Excel 里“區(qū)域”的自然語義。公式鏈把原本的公式緩存值和公式字符串都保存下來這樣摘要生成時不僅看到數字還知道數字是怎么算出來的。比如“本月客單價”一欄直接給智能體一個總收入/訂單數的上下文結果會比只看數值更準。這樣做還有一個額外收益當工作流跑完之后AI 可以直接把計算結果填充到新的單元格區(qū)域同時保留一個“來源是 AI 生成”的標記。沒人想要一份看起來像人寫的、其實有錯但無法定位的表。2.3 讓文檔和表格可被檢索向量索引與精確索引的雙通道任何 AI 工作區(qū)檢索能力都會決定智能體回答的天花板。只靠向量檢索的常見問題是數值型查詢“上月銷售額最高的客戶ID是多少”效果奇差因為 embedding 對數字并不敏感。只靠關鍵詞檢索的常見問題是同義表達和意圖改寫幾乎無解。所以我的方案是雙通道。向量索引負責語義召回詞法索引負責精確命中。查詢時先解析用戶請求類型如果明顯是數值條件或指定字段名查詢就直接走詞法結構化過濾不經過向量。如果請求是“總結這份報告里關于風險的部分”才走向量語義召回。落到工程上向量部分我本地跑一個 embedding 模型用最小維度就夠塊級別檢索精確部分用自定義倒排索引只索引文檔索引里那些標記為“標題、表格頭、單元格列名”的節(jié)點。這樣既避免了在線嵌入服務把敏感文本傳出去又將表格檢索從“模糊找”升級成了“指哪打哪”。3. 智能體與工作流的運行時設計有了統(tǒng)一數據底座接下來的核心是把智能體和工作流放進同一個運行時空。這兩者不是替代關系智能體擅長在開放語境下做判斷和生成工作流擅長把確定性的步驟固化下來保證可重復。真實業(yè)務里它們得混著用。我給運行時的定位是一張狀態(tài)圖節(jié)點可以是普通計算節(jié)點、自動化步驟也可以是智能體節(jié)點。工作流負責沿著既定邊執(zhí)行智能體在需要理解和生成的節(jié)點被安排進入。流程跑完后每一步的輸入輸出、模型調用記錄、人工審批動作全部寫進運行日志。3.1 把智能體當“服務”而不是當“聊天框”很多人在工作區(qū)里加了智能體其實只是把普通的對話 UI 搬了過來。單獨聊沒問題但要在工作流里復用智能體就必須把它改造成服務接口。這里的核心是定義清楚輸入、輸出和工具權限。以“合同風險審查”這個智能體為例它的輸入不是一句自由對話而是{文檔ID, 區(qū)域范圍, 審查重點}這樣一個結構化參數。輸出也不是聊天消息而是{發(fā)現的問題列表, 每項風險等級, 涉及條款定位}的結構化結果。這樣工作流才能拿住結果去分支高風險走人工復審低風險自動歸檔。工具權限同樣要收緊。智能體被允許調用哪些文檔讀取能力、哪些單元格寫入能力必須按角色或任務目標做隔離。工作區(qū)可以提供一組工具描述給模型模型在推理過程中自主調用工具取上下文這比把整個文檔塞進上下文窗口可靠得多token 開銷也小。我實際驗證過一個細節(jié)給智能體的工具描述寫得越像“給多分類任務做 Few-shot 的 prompt”它調用工具的準確率越高。你必須在工具名里說明“返回區(qū)域的前三行示例”這樣模型才知道該取幾行才能判斷下一跳動作。3.2 工作流編排并行、重試、人工閘門一個都不能少工作流引擎最常見的死法是只支持線性執(zhí)行。任務一旦多了一個個排隊跑慢又脆弱。我設計時把能力面打開成四個維度并行執(zhí)行相互獨立的節(jié)點可以并行跑典型場景是同一份季度表格要做不同維度的多維分析。此時我會按維度拆節(jié)點并行交給模型最后結果匯總。條件分支節(jié)點根據前一步的結構化輸出去不同的下一跳。比如表格里“數值異?！钡臉擞洓Q定是否觸發(fā)二次校驗節(jié)點。重試與降級模型調用偶發(fā)失敗要做指數退避重試連續(xù)失敗就轉入人工處理隊列而不是讓流程靜默失敗。人工閘門關鍵節(jié)點保留人審。比如自動生成的對外報告在最終簽發(fā)前強制加人工確認智能體建議的批量數據更新默認只寫草稿區(qū)經人確認后才落庫。這四個能力是工作流可投入生產的底線缺一個都會在生產環(huán)境里爆雷。我在項目里優(yōu)先把這套能力做成對任意節(jié)點透明的基礎設施而不是讓每個節(jié)點自己處理并發(fā)和容錯。3.3 工作流里接智能體用工具調用把文檔、表格變成上下文智能體和工作流深度融合的關鍵點在于“工具調用”的上下文管理。我的實現里智能體節(jié)點通過一套工具函數與工作區(qū)數據底座交互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, }模型在請求處理時會自行規(guī)劃先調用read_cell_range(銷售明細, A1:F60)拿一小塊預覽再調用更精確的區(qū)域查詢最后調用run_sql_on_table做聚合統(tǒng)計最后在一個新文檔里生成分析報告。整個過程中工作流提供的是執(zhí)行框架、限制的是授權范圍模型提供的是理解和表達。這樣我們實際上把智能體的“對話上下文”換成了“工作區(qū)上下文”。上下文不再是一次性粘貼進去的那幾段話而是通過工具實時從工作區(qū)拉取的一段段結構化數據?；谶@套調用機制員工可以讓智能體“看一下最近兩個季度的報表找出環(huán)比下降超過 5% 的品類整理成表格再讓流程自動生成一封給主管的摘要郵件草稿”全程不用手工搬運。4. 桌面端落地從架構到開箱即用的工程細節(jié)前面的模型和運行時設計最終要落到一個真實可用的桌面應用里否則只停留在理論或命令行演示。這一部分涉及的工程細節(jié)很瑣碎但直接決定項目能不能被普通同事上手使用。4.1 桌面外殼、本地模型與數據安全邊界桌面殼我首選 Tauri因為它內存占用低啟動快前端可以放心用 React 來做工作區(qū)界面。后端進程則用 Rust 寫一個薄殼負責調用 Python 側的解析、索引引擎避免純 Python 部署帶來的復雜依賴問題。本地模型優(yōu)先是這類的安全邊界。所有文檔解析、向量索引、表格讀寫默認都在本機完成模型調用優(yōu)先走 Ollama 等本地推理服務只有用戶顯式配置了外部 API 兼容端點時部分任務才會通過 API 執(zhí)行。默認策略是不傳輸任何原文。這意味著哪怕工作區(qū)同時打開了幾百 MB 的報表原始文件也不會因為一次智能體對話被整體發(fā)送到遠程。配置項我也做了簡化只需要在配置文件中指定本地模型服務地址、嵌入模型路徑和默認工作目錄三樣東西剩下全部可以按默認值跑起來。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 部署與啟動的一些細節(jié)處理從倉庫拉下代碼之后最順利的話三步能跑通安裝 Rust 和前端依賴初始化 Python 虛擬環(huán)境執(zhí)行npm run tauri dev。但實際上第一步就會遇到兩個常見問題一是 C 構建工具鏈缺失導致 PyMuPDF、Pandas 這類帶二進制依賴的包編譯失敗二是系統(tǒng)缺少中文語言包和 Tesseract 的 OCR 支持文件。這些問題解決起來不難但網上教程經常跳過容易讓新人卡很久。部署完成后我會立刻做三件校驗第一導入一份 20 萬行的 CSV 和一份只有 3 頁的掃描版 PDF分別確認表格解析和 OCR 能正常工作第二打開檢索測試面板分別用語義關鍵詞和精確字段名各查一次第三跑一個“文檔摘要表格統(tǒng)計”的最小工作流確認智能體能依次調工具、最后寫回結果。這三項全過工作區(qū)的基礎才算真的穩(wěn)定。4.3 我踩過的典型坑與對應的修復方式任何項目都會有坑這個項目隱性最深的是幾類問題問題現象修復方式Excel 合并單元格錯位智能體讀到的數據錯位統(tǒng)計結果明顯偏大在解析階段保留合并單元格映射按實際區(qū)域填寫重復值PDF 掃描版無文本層向量索引全部為空檢索返回空啟用 OCR 分支并單獨給 OCR 索引做標記超大表格一次性入上下文模型響應超時或 token 溢出強制所有表格讀操作走區(qū)域分頁默認每次最多 200 行本地模型上下文窗口不足多文檔摘要越寫越亂改用“摘要-再聚合”兩段式先按文檔小塊生成中間摘要這些坑的共性是不是模型能力不夠而是數據進模型之前就沒有被整理好。把數據準備好比換更強的模型更有效。5. 一個可以直接抄走的工作流示例從“原始銷售表”到“月度復盤文檔”講完底層的組件和細節(jié)來一個能直接照搬的完整示例最好理解。這個工作流的輸入是一張原始銷售明細表輸出是一份包含業(yè)務發(fā)現和風險提示的月度復盤文檔。5.1 搭建階段把表格喂進工作區(qū)第一步是導入表格。將導出好的銷售明細表比如 3 萬行、字段包括訂單日期、客戶ID、品類、金額、銷售人員放進數據目錄工作區(qū)會在導入階段自動解析為帶單元格地址的表格對象同時建立列索引和示例值摘要。導入完成后我需要用一段 SQL 驗證一下數據完整性檢查 NULL 值和明顯異常值。驗證通過后把這個表格綁定到工作流上作為數據源。綁定動作背后實際做的是把表格對象的元數據和訪問權限交給工作流后續(xù)節(jié)點可以讀取但不能隨意覆蓋原表。5.2 工作流節(jié)點配置的逐項說明這個工作流建議配置 6 個節(jié)點節(jié)點類型說明1 數據讀取普通節(jié)點讀取表格前 N 行和月度聚合結果2 月度匯總計算節(jié)點按月份分組計算銷售額、訂單數、客單價3 品類分析智能體節(jié)點基于月度匯總結果判斷品類變化和異常品類4 風險識別智能體節(jié)點用上一節(jié)點輸出定位環(huán)比下降超閾值品類5 文檔生成智能體節(jié)點匯總前四步結果按標準模板生成復盤文檔6 人工閘門人工節(jié)點最終文檔需人工確認后才能保存到工作區(qū)每一步都要設置好輸入參數和輸出字段。比如品類分析節(jié)點用一句針對性 prompt 來指導智能體“你只能基于輸入的表格區(qū)域回答問題不要自行引入外部信息輸出必須包含品類名稱、環(huán)比變化率、可能原因三項如果數據不足明確寫‘信息不足’而不是編造原因?！边@樣約束后自動生成的內容才具備作為業(yè)務草稿的質量底線。5.3 運行效果與驗證方式運行工作流后觀察日志會看到清晰的節(jié)點執(zhí)行順序數據讀取后計算節(jié)點先完成聚合再并行觸發(fā)品類分析和風險識別兩個智能體節(jié)點最后文檔生成把所有結果收攏。整個流程通常在幾十秒內完成具體耗時取決于本地模型的推理速度。驗證時我的做法是抽取同一個月的數據人工獨立計算一遍月度匯總和流水線輸出對比再抽查兩個風險品類的分析結論檢查是否與原始表格內數字相符。校驗通過后這份自動生成的文檔可以作為內部復盤的初稿再做人工潤色。這套工作流真正解決了“人肉膠水”的痛點以前要導出 CSV、開腳本、喂給模型、手動粘貼現在一鍵觸發(fā)全部步驟留在日志里隨時可以重跑和審計。6. 選擇開源組件時的一些經驗判斷因為入口是開源最后補一點我的真實體會。選開源組件不能只看 GitHub 星數尤其在一個要長期維護的桌面工作區(qū)里判斷標準必須更加具體。6.1 我評估組件時真正看重的幾項我一般看四件事License 兼容性項目要開源出來給別人用核心依賴的 License 必須一路順下來尤其注意像某些 GPL 傳染性強的庫摻進來之后整個項目的分發(fā)約束會變。維護活躍度看最近半年有沒有 commit、issue 響應速度、發(fā)版頻率。一個半年沒動的解析庫在新格式面前基本等于失去維護。替換成本組件與核心數據模型的耦合度要低。拿向量存儲來說如果業(yè)務代碼里到處直接調用某個向量庫的私有 API后續(xù)想換遷移成本太高我會在存儲層做統(tǒng)一的讀寫接口讓替換只在適配層發(fā)生。隱私邊界組件默認行為是否會把數據發(fā)出去。這一點對本地優(yōu)先工作區(qū)是硬指標凡是默認帶遙測、自動更新的庫都要謹慎評估。6.2 這個項目后續(xù)還能怎么擴展項目做到現在最讓我滿意的不是某個炫酷界面而是它形成了不容易散架的內核。后續(xù)想擴展的方向也很多一是把工作流節(jié)點做得更可視化讓不寫代碼的業(yè)務同事也能拖拽配邏輯二是增加更細粒度的權限模型比如部門之間只能看到自己相關文檔和表格三是把本地模型和云端模型做成流程內可切換的混合調度敏感步驟一定留本地非敏感步驟可以走更強模型提升質量。如果讀者想基于這個思路做自己的開源工作區(qū)我給的具體建議是先把文檔和表格的數據底座做好再上智能體和流程。很多人反過來先做聊天和流程結果數據不通最后一切功能都懸空。最后說一個自己在實際維護中的小體會永遠給所有節(jié)點和智能體調用留日志并且讓日志可以被重新回放。排查工作流問題時看不到過程比出錯本身更可怕。能做到這一點這個開源桌面工作區(qū)就算有真正的生產力了。