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