TextIn xParse 上架 WorkBuddy 后智能文檔處理這件事的門檻被明顯拉低了一大截。以前處理 PDF、圖片里的表格和公式要么裝本地解析工具要么寫腳本調接口要么手動復制粘貼再排版。現在 WorkBuddy 里裝上 xParse 這個技能用一句話就能把“上傳文檔 → OCR 識別 → 版面解析 → 轉成 Markdown/HTML → 進知識庫”整條鏈路串完。這篇文章不講虛的直接拆解 TextIn xParse 在 WorkBuddy 里的定位、怎么把它配成可用技能、怎么用一句話觸發完整解析流程以及接入接口和批量任務時需要注意哪些問題。先看這個組合最值得關注的地方在哪里。TextIn xParse 是合合信息旗下的智能文檔解析模型主打 PDF、圖片、掃描件里的版面還原包括段落、表格、公式、頁眉頁腳、閱讀順序這些細節。WorkBuddy 則是一個 AI Agent 工作臺能裝各種 skill把大模型、工具、數據源串成自動化流程。兩者結合以后xParse 不再是孤立的解析工具而是變成一個可以“隨叫隨到”的文檔處理能力。不用關心顯存、不用關心顯卡驅動。官方是以云端 API 和平臺技能的形式提供所以不存在本地部署時的 CUDA、PyTorch、顯存占用這些硬門檻。你只需要有一個 WorkBuddy 賬號把 TextIn xParse 技能加進來然后給它一句話任務描述。本文會帶讀者完成這幾件事先理解 xParse 能解析什么、適合什么場景然后在 WorkBuddy 里配置好 TextIn xParse 技能接著用自然語言觸發幾次真實解析任務覆蓋 PDF 轉 Markdown、表格識別、公式抽取和批量處理再補充接口調用和批量任務的設計思路最后給出容易踩坑的地方和一套可復用的處理規范。1. 核心能力速覽能力項說明項目來源合合信息TextInxParse上架到 WorkBuddy 平臺項目類型智能文檔解析模型 AI Agent 技能主要功能圖片/PDF/掃描件 OCR、版面分析、表格還原、公式識別、閱讀順序還原、Markdown/HTML 導出硬性門檻無本地 GPU 要求云端 API 模式依賴 WorkBuddy 平臺賬號啟動方式WorkBuddy 內添加 TextIn xParse 技能通過對話觸發是否支持 API支持TextIn 提供文檔解析接口可以在 WorkBuddy 技能中封裝也可獨立調用是否支持批量任務支持接口可連續調用WorkBuddy 場景下可通過任務編排實現多文檔批處理適合場景知識庫導入、文檔問答、研報處理、論文解析、合同抽取、票據結構化使用邊界文檔內容受版權和隱私約束需確認有合法處理權限從能力速覽能看出來這個組合最核心的定位是把高質量的文檔結構化解析能力通過對話式 Agent 開放給非技術用戶。過去要寫 Python 腳本才能實現的 PDF 轉 Markdown現在在 WorkBuddy 里說一句“把這份 PDF 解析成 Markdown 表格齊全”即可完成。2. 適用場景與使用邊界2.1 適合誰用知識庫搭建者需要把大量 PDF、Word、圖片導入知識庫希望保留原文結構和表格。xParse 解析后的 Markdown 特別適合做向量化前的清洗能明顯提升檢索準確率。研究分析類用戶經常看論文、研報、財報需要把 PDF 里的公式、圖表、多欄排版還原成可編輯文本。通用 OCR 只出純文本xParse 這類版面解析模型能還原閱讀順序和層級關系。非技術運營人員不會寫代碼也不想學接口調用。WorkBuddy 的對話式交互讓文檔處理變成“發指令”而不是“寫腳本”。開發者的前置處理環節即使最終要寫代碼也可以先在 WorkBuddy 里用 xParse 驗證解析效果確定提示詞和輸出格式再進入接口批量階段。2.2 能解決什么問題這里把“通用 OCR”和“版面解析”分開看。普通 OCR 解決的是“圖片里有什么字”xParse 這類模型解決的是“這段文字是標題、表格還是公式它在頁面上的坐標和閱讀順序是什么”。后面這個能力才是文檔自動化處理真正需要的。比如一份帶有復雜表格的 PDF純文本 OCR 會把表格里的內容按行打散丟失列關系和層級xParse 能把整個表格結構還原成 Markdown 表格后續直接進數據庫或知識庫。WorkBuddy 最大的價值是把零散能力編排成流程。一個文檔解析技能只能解析單個文件但配上 WorkBuddy 的 skill 機制后用戶可以說“把 inputs 文件夾里所有 PDF 解析成 Markdown然后匯總成一個清單”這就是從工具到自動化流程的跨越。2.3 不適合什么場景對數據隱私要求極其嚴格、必須本地離線處理的場景不適合直接用云端 API。這類場景需要評估合合信息的企業私有化部署方案。手寫體密集、嚴重傾斜、低分辨率的歷史掃描件任何文檔解析模型都會遇到效果瓶頸。不能說“一個模型解決所有 OCR 問題”。需要極低延遲的實時解析場景。云端 API 有網絡開銷單次解析耗時通常在秒級到十秒級不適合毫秒級在線交互。2.4 合規提醒涉及合同、票據、身份證、人像照片、內部研發文檔時先確認自己有沒有合法處理權限。把文檔上傳到第三方模型解析本質上是一次數據外發需要遵守公司數據安全規范和個人信息保護要求。涉及版權材料時解析后如果重新發布或商用還需要確認授權范圍。3. 使用前準備使用 WorkBuddy TextIn xParse 前需要整理一份清單。3.1 WorkBuddy 賬號準備訪問 WorkBuddy 官網注冊賬號。從材料看WorkBuddy 有網頁版、Windows 版、Linux 版和麒麟版也就是說它在辦公電腦、服務器以及國產化環境里都有對應的客戶端。登錄后先看“技能Skill”市場或技能管理入口確認當前賬號是否已經開放 TextIn xParse。如果你需要使用 DeepSeek 等外部大模型能力可以提前準備模型 API KeyWorkBuddy 支持接入 DeepSeek這個在后面的技能編排里會用到。3.2 TextIn xParse 可用性確認確認 TextIn xParse 技能是否已經在 WorkBuddy 上架。如果還沒出現在技能市場可以直接到 TextIn 官網注冊賬號獲取 API Key 后手動配置自定義技能。TextIn 平臺本身提供文檔解析 API無論 WorkBuddy 里是否直接上架你都可以通過自定義 skill 的方式把 xParse 的能力接進來。3.3 測試文檔準備準備幾類典型文檔覆蓋不同解析難度文件類型特點測試目標純文字 PDF簡單排版、無復雜表格驗證基礎文本抽取和閱讀順序掃描版 PDF圖片掃描件含傾斜、陰影驗證 OCR 準確率含表格 PDF多列表格、表頭跨行驗證表格結構還原論文 PDF公式、多欄排版、頁眉頁腳驗證公式識別和版面還原高清圖片 JPG單據、名片、截圖驗證圖片輸入格式支持樣本文件不要太大。首次測試控制在單文件 10MB 以內頁面數控制在 20 頁以內方便快速觀察效果和排查問題。3.4 輸出目錄準備即使是在 WorkBuddy 對話式場景里也要養成目錄管理的習慣data/ ├── inputs/ # 待解析文檔 ├── outputs/ # 解析結果 │ ├── markdown/ │ ├── html/ │ └── json/ ├── logs/ # 批處理運行日志 └── archive/ # 已處理文檔歸檔這套目錄結構在后面接 API 和批量任務時會直接用上。4. 在 WorkBuddy 中啟用 TextIn xParse 技能4.1 方案一直接從技能市場添加如果你的 WorkBuddy 賬號已經開放 TextIn xParse打開 WorkBuddy進入技能市場。搜索“TextIn”或“xParse”。點擊添加確認授權。添加完成后新建一個對話或工作臺頁面在技能列表里啟用 TextIn xParse。啟用后在對話里輸入指令WorkBuddy 會調用 xParse 完成解析并把結果返回給后續流程。4.2 方案二用 TextIn API 配置自定義技能如果平臺內還未直接上架可以通過自定義 skill 的方式封裝。你需要注冊 TextIn 賬號創建應用獲取 API Key。在 WorkBuddy 里新建自定義技能/工作流添加“調用 HTTP API”節點。配置 TextIn 文檔解析接口的請求地址、請求頭、請求體。把文檔上傳節點和 API 調用節點連接起來。下面是這個自定義技能里 API 調用的通用配置模板實際請求地址和參數名需要以 TextIn 官方文檔為準# 偽代碼在 WorkBuddy 自定義技能中HTTP 請求節點配置示例 POST /api/v1/document/parse Host: TextIn API 地址 Authorization: Bearer 你的 API Key Content-Type: multipart/form-data{ file: 上傳的文件流, parse_mode: auto, output_format: markdown, ocr: true, table_recognition: true, formula_recognition: true }這里要強調一下這些參數只是常見解析請求的結構示例不代表 TextIn 的真實接口字段。接入前一定要打開 TextIn 官方接口文檔核對。做技術集成時最忌直接抄網上的示例參數接口版本更新后很容易踩坑。4.3 用一句話觸發完整流程在 WorkBuddy 對話窗口里輸入類似下面的自然語言指令請解析這份 PDF輸出 Markdown 格式保留表格結構把結果保存到 outputs/markdown/ 目錄。WorkBuddy 會解析這條指令自動識別文件、調用 xParse、導出結果。這就是“一句話完成智能文檔處理全流程”的實際體驗。如果你想讓指令更穩定后期可以把這類高頻命令寫成一個自定義指令模板后面單獨講。5. 功能測試與效果驗證技能配置完下一步就是驗證解析效果。下面給出四種核心測試任務和判斷標準。5.1 測試任務一PDF 轉 Markdown測試目的驗證基礎文檔解析、標題層級、段落順序和列表結構。輸入一份 5 頁左右的純文字 PDF。操作步驟在 WorkBuddy 對話中上傳 PDF。輸入指令用 TextIn xParse 解析這個 PDF輸出 Markdown保留標題層級。等待解析完成檢查輸出文件。預期結果一級標題、二級標題、正文段落層級正確。多欄排版的閱讀順序還原正確而不是“從左欄讀到右欄再從右欄讀回左欄”。輸出結果中不包含頁眉頁腳等裝飾性信息如果模型支持過濾。判斷是否成功對照原 PDF 的目錄結構看 Markdown 里的標題編號和正文順序是否一致。常見失敗原因原文本身是掃描件沒有 OCR 步驟導致抽取不到文字。文檔排版過于復雜閱讀順序被錯亂。大文件超時或超出頁數限制。5.2 測試任務二復雜表格還原測試目的驗證表格結構還原能力。輸入一份包含合并單元格、跨行表頭、多列表格的財務報表或庫存表 PDF。操作步驟上傳文件。輸入指令把 PDF 中的表格全部還原成 Markdown 表格不要丟列。檢查結果。預期結果原表格的列數、行數、表頭層級一一對應。單元格內換行、數字千分位、百分比符號保留。合并單元格在 Markdown 里以可接受的方式表達。判斷是否成功拿原 PDF 第 3 頁的復雜表格和 Markdown 輸出逐列比對重點看總列數和跨行表頭。常見失敗原因表格有線框斷裂模型識別成多個表格。表頭合并跨行時Markdown 生成邏輯丟失層級關系。5.3 測試任務三公式識別測試目的驗證論文場景的公式抽取能力。輸入一份帶有數學公式的論文 PDF。操作步驟上傳文件。輸入指令解析論文把公式轉成 LaTeX。檢查公式部分。預期結果行內公式和獨立公式都能被識別。公式轉成 LaTeX 后符號、上下標、分數結構可讀。判斷是否成功隨機抽 5 個公式用 LaTeX 渲染后和原公式對比結構是否一致。常見失敗原因公式字號過小或印刷質量差。復雜矩陣、多行公式識別不完整。5.4 測試任務四批量文檔解析測試目的驗證多文件場景下的任務編排能力。輸入一個文件夾包含 5 個不同格式的 PDF。操作步驟在 WorkBuddy 中創建一個批處理任務選擇 TextIn xParse 技能。輸入指令把 data/inputs/ 下所有 PDF 解析成 Markdown按原文件名保存到 outputs/markdown/。設置好輸入目錄、輸出目錄和錯誤處理方式啟動任務。查看運行日志確認每個文件都被處理。預期結果每個 PDF 生成一個對應的 Markdown 文件。如果某個文件失敗任務不中斷記錄到日志后繼續處理下一個。輸出文件與輸入文件一一對應。判斷是否成功檢查 outputs/markdown/ 下有 5 個 Markdown 文件且每個文件的解析內容與對應 PDF 一致。常見失敗原因文件名包含特殊字符導致保存路徑錯誤。單個文件超過接口大小限制。批量任務缺少失敗重試機制一個文件失敗導致整個流程卡住。6. 接口 API 與批量任務對話式調用適合體驗和交互驗證但真正的工程化場景還是要走 API。TextIn xParse 本身是 API 服務理解它的接口方式才能在 WorkBuddy 之外構建更靈活的自動化流程。6.1 接口啟動方式從產品形態看TextIn xParse 是云端 API 服務不需要自己部署服務進程。開發者只需要在 TextIn 平臺創建應用。獲取 API Key。按官方文檔調用文檔解析接口。6.2 Python 調用通用模板下面是調用文檔解析接口的通用模板目的是演示請求結構和異常處理思路實際接口路徑、請求頭、返回字段要替換為 TextIn 官方文檔中的真實值import requests import json API_URL https://TextIn API 域名/api/v1/document/parse API_KEY 你的 API Key def parse_document(file_path, output_formatmarkdown): headers { Authorization: fBearer {API_KEY} } # 實際接口字段以官方文檔為準這里僅展示結構 data { output_format: output_format, ocr: true, table_recognition: true } with open(file_path, rb) as f: files {file: (file_path.split(/)[-1], f)} response requests.post(API_URL, headersheaders, datadata, filesfiles, timeout120) if response.status_code 200: return response.json() else: raise Exception(f解析失敗: {response.status_code}, {response.text})if __name__ __main__: result parse_document(./data/inputs/sample.pdf) print(json.dumps(result, ensure_asciiFalse, indent2))6.3 markitdown 風格的補充思路如果你的工作流里已經用了微軟開源的 markitdown 這類文檔轉 Markdown 工具可以思考兩者怎么配合。markitdown 的優勢是免費、開源、支持多格式缺點是復雜版面解析能力有限表格和公式還原不如專門的版面解析模型。工程上的常用策略是普通 Office 文檔先走 markitdown速度快且免費。復雜 PDF、掃描件、論文走 xParse質量更高。# markitdown 安裝命令補充知識非本項目必需 pip install markitdown在 WorkBuddy 技能編排時也可以設計成先判斷文件類型PDF/圖片走 xParseOffice 文檔走 markitdown。這樣能把成本和效果做一個平衡。這里需要說明項目團隊實際上把兩個工具看作互補這也是當前文檔解析落地工程里比較成熟的思路。6.4 批量任務設計批量解析的核心不止是“循環調用接口”而是要做到可控、可觀測、可重試。批量處理最小設計import os import time import json from concurrent.futures import ThreadPoolExecutor, as_completed INPUT_DIR ./data/inputs OUTPUT_DIR ./data/outputs/markdown LOG_FILE ./data/logs/batch.log def process_one(file_name): file_path os.path.join(INPUT_DIR, file_name) # 這里調用上面實現的 parse_document 函數 # 實際業務中需要補充重試邏輯 result parse_document(file_path) output_path os.path.join(OUTPUT_DIR, file_name.replace(.pdf, .md)) with open(output_path, w, encodingutf-8) as f: f.write(result.get(markdown, )) return file_name, True def batch_run(): files [f for f in os.listdir(INPUT_DIR) if f.lower().endswith(.pdf)] with ThreadPoolExecutor(max_workers3) as executor: future_map {executor.submit(process_one, f): f for f in files} for future in as_completed(future_map): fname future_map[future] try: fname, ok future.result() with open(LOG_FILE, a, encodingutf-8) as log: log.write(f{time.strftime(%Y-%m-%d %H:%M:%S)} SUCCESS {fname}\n) except Exception as e: with open(LOG_FILE, a, encodingutf-8) as log: log.write(f{time.strftime(%Y-%m-%d %H:%M:%S)} FAILED {fname}: {str(e)}\n) if __name__ __main__: batch_run()批處理注意點并發數不要太高先設 3 到 5觀察接口響應時間和錯誤率。增加失敗重試失敗的文件單獨記錄二次重試。已經解析成功的文件跳過避免重復消耗額度。日志記錄包括時間、文件名、成功/失敗、錯誤信息、耗時。6.5 curl 調用示例如果你想在 shell 腳本或 CI 里集成可以這樣用# 以實際 API 文檔地址為準下面僅展示結構 curl -X POST https://TextIn API 域名/api/v1/document/parse \ -H Authorization: Bearer YOUR_API_KEY \ -F file./data/inputs/sample.pdf \ -F output_formatmarkdown \ -F ocrtrue響應中通常包含解析狀態和結果數據具體字段請查閱官方文檔。7. 性能與成本觀察7.1 如何判斷解析質量解析質量不能只看文字識別準不準還要看版面結構還原度。重點觀察這幾個維度閱讀順序多欄 PDF 的段落是否按邏輯連續排列。表格層級合并單元格、表頭、跨頁表格是否一致。公式結構LaTeX 是否可直接編譯。多余元素頁眉頁腳、頁碼、水印是否被過濾。7.2 影響解析時間的因素文件頁數頁數越多耗時越長響應時間通常近似線性增長。表格密度復雜表格會顯著增加版面分析耗時。是否 OCR掃描件比電子版 PDF 多一步 OCR 處理耗時成倍增加。是否啟用公式識別公式識別是全流程中最重的計算環節之一。7.3 成本控制建議先用小樣本測試效果再投入全量解析。批量任務設置每日額度上限防止腳本死循環產生巨額費用。對已經解析過的文件做冪等處理比如根據文件 MD5 判斷是否已經解析。在 WorkBuddy 里設定技能調用范圍和頻率限制。8. 常見問題與排查方法問題現象可能原因排查方式解決方案WorkBuddy 對話中沒有出現 xParse 技能賬號未開通權限或技能未上架檢查技能市場、賬號權限手動注冊 TextIn 并配置自定義技能文檔解析后全是空文本電子版 PDF 字體嵌入異常或掃描件 OCR 未開啟檢查源文件、確認 OCR 參數在參數中開啟 OCR使用更清晰的掃描件表格行列錯亂原表有線框斷裂、跨頁、復雜合并更換測試文檔看小規模表格是否正常調整預處理參數必要時拆分頁面處理公式識別失敗公式圖片太小、印刷模糊放大測試區域、提高掃描分辨率更換清晰版本或對圖片做預處理API 返回 401 錯誤API Key 錯誤或過期檢查請求頭中的 Authorization 字段重新生成 API KeyAPI 返回 413 錯誤文件過大查看接口大小限制壓縮 PDF、拆分頁面后處理批量任務中途卡住單個文件超時或接口限流查看運行日志、注意錯誤碼增加超時重試和限流退避解析結果中仍有頁眉頁腳版面分析模型未過濾檢查參數中是否有過濾選項在后續清洗步驟中正則剔除或調整解析模式WorkBuddy 技能調用報錯但無詳細日志工作流節點配置錯誤查看工作流運行的詳細日志檢查 HTTP 節點參數、權限和 API Key大文件超時默認超時設置過短檢查接口文檔超時上限提高客戶端超時時間或分段處理9. 最佳實踐與使用建議9.1 第一次使用時先小規模驗證不要一上來就解析幾百個文件。先挑 3 到 5 個不同類型的文檔測試確認解析效果符合預期再擴大規模。這個習慣能幫你省下大量 API 調用費。9.2 把常用指令固化成 WorkBuddy 自定義指令如果每天都要執行同樣的解析流程在 WorkBuddy 里把這些指令保存成自定義指令模板。比如【PDF 解析標準流程】 1. 將 PDF 上傳到 data/inputs/ 2. 用 TextIn xParse 解析輸出 Markdown 3. 保留表格和公式去掉頁眉頁腳 4. 保存到 outputs/markdown/以原文件名命名 5. 完成后輸出文件清單以后每天只需要一句話“執行 PDF 解析標準流程”。這也是 WorkBuddy 里自定義指令的典型用法。9.3 模型和格式配合使用復雜版面優先讓 xParse 處理普通文本直接用輕量工具。合理的流程是“文件類型判斷 → 選擇解析器 → 后處理清洗”。這個思路在 WorkBuddy 中可以用條件判斷節點實現也可以通過外部腳本實現。9.4 保留原始文件與解析結果的對應關系輸出文件命名時保留原始文件名最好再加一個映射文件記錄“原文件路徑 → 輸出文件路徑 → 解析時間 → 是否成功”。沒有這個映射批量解析完成后很難排查問題。9.5 批量任務必須加日志和失敗重試批處理跑 100 個文件出現 5 個失敗是正常現象。失敗原因可能是文件損壞、格式不支持、接口臨時限流。正確做法是失敗文件不中斷整個任務。將失敗原因記錄到日志。完成第一輪后對失敗文件做重試。重試仍失敗的單獨歸檔方便人工處理。9.6 注意隱私和授權對內部文檔、客戶合同、個人證件圖片做解析時先確認數據是否允許發送到第三方平臺。重要文件建議在解析前進行脫敏處理。涉及人臉、身份證號、銀行卡號等信息時不要隨意上傳。解析完成后如果結果被用于商用發布還要確認原文檔的版權授權。9.7 接口服務要限制訪問范圍如果自己用 Python 封裝了 xParse 接口服務不要直接暴露到公網。設置訪問 IP 白名單或請求鑒權避免接口被惡意刷量、產生高額費用。9.8 發布或商用前做效果復核自動解析的結果不能直接拿來發布。批量解析后抽檢 10% 到 20% 的文檔重點看表格和公式是否失真。內容發布場景下錯誤表格帶來的風險往往比漏掉一個字符更大。10. 總結與下一步TextIn xParse 上架 WorkBuddy 這件事把“文檔解析”這個專業能力變成了 Agent 世界里的一個普通技能。最值得立刻嘗試的是那個核心場景上傳一份帶復雜表格的 PDF說一句話得到結構完整的 Markdown。首先建議驗證的功能是PDF 轉 Markdown 的基礎流程和復雜表格還原。這兩個功能覆蓋了絕大多數知識庫和辦公文檔處理需求也是最能體現 xParse 相比傳統 OCR 價值的地方。最容易踩的坑是掃描版 PDF 沒開 OCR、表格太復雜導致行列錯亂、批量任務沒有失敗重試。這三件事只要提前注意大部分問題都可以避免。后續可以繼續擴展的方向有三個一是把 WorkBuddy 里的解析結果接入 DeepSeek 等大模型形成“解析 → 清洗 → 向量化 → 知識庫問答”的完整鏈路。WorkBuddy 本身支持接入 DeepSeekxParse 負責把文檔變成高質量文本大模型負責理解這個組合能讓本地文檔問答系統的準確率明顯提升。二是通過 MCP 的方式直接訪問數據庫。WorkBuddy 支持通過 MCP 接入數據庫解析出來的結構化表格可以直接寫入數據庫表省掉中間的人工搬運環節。比如把財報 PDF 里的三張表自動寫進數據庫后續就直接用 SQL 查詢了。三是結合 WorkBuddy 搭建個人的文檔自動化工作臺。除了 xParse還有很多 skill 可以組合。文檔解析只是入口后面接總結、翻譯、摘要、郵件發送就是完整的文檔處理流水線。從一套工作臺出發逐步加技能就能建起一個直接提高干活效率的日常系統。一句話總結TextIn xParse 負責把萬變文檔變成結構化數據WorkBuddy 負責把結構化數據變成自動化流程。兩件事合在一起文檔處理就是動動嘴的事了。