手头有一份43页的数学建模竞赛论文，PDF格式，里面混着大段正文、十几个表格、一堆公式，还有几张贴在页面里的流程图和数据图。我想把它拆成结构化的东西：表格转成可读的文本或结构化数据，公式单独拎出来，图片按位置存下来。
手动做的话，一页一页翻、截图、抄公式，43页够干一下午。所以我打算试试自动化方案。
这次用到的两个东西：一个是蓝耘元生代平台上的 WorkBuddy，另一个是 TextIn 的 xParse 文档解析接口。前者负责调度和串联流程，后者负责实际的文档解析。下面把我实际跑的过程和结果写下来，包括哪些地方顺、哪些地方卡。
先说清楚这两个东西是什么
蓝耘元生代是蓝耘科技做的一个 AI 算力与应用平台，上面有模型服务、Agent 编排这类能力。WorkBuddy 是平台里的一个智能体/任务编排组件------需要说明的是，WorkBuddy 的具体产品定位和能力范围，我没有找到一份完整权威的公开文档，以下描述基于我在平台上实际操作时看到的功能，如果和官方定义有出入，以官方为准。
TextIn 是合合信息旗下的文档处理产品线，xParse 是其中的文档解析接口，主打把 PDF、图片类文档解析成结构化的 Markdown/JSON，保留版面、表格、公式、图片等信息。这一点相对明确，xParse 的公开定位就是"文档解析"，输出结构化结果。
我这次的核心思路很简单：WorkBuddy 做流程编排，xParse 做重活。因为解析43页论文这种任务，本身不需要多复杂的推理，需要的是一个稳定的解析引擎加一个能把结果整理好的流程。
环境准备和调用方式
TextIn xParse 是 HTTP 接口。要调用它，得先有 API 凭证。关于凭证的具体申请入口和当前配额策略，我这里不写死，因为各家平台的申请流程和免费额度会变，建议直接看 TextIn 官网的文档页确认。
调用大致分两步：先提交解析任务，拿到一个 task_id，再轮询查询结果。下面是请求体的结构，参数名我按记忆写的，具体字段名请以官方文档为准：
python
import requests
import time
# 这里的字段名和参数仅为示例结构，请对照 TextIn xParse 官方文档核对
def submit_parse(pdf_path, app_id, secret_code):
url = "https://api.textin.com/ai/service/v1/pdf_to_markdown"
headers = {
"x-ti-app-id": app_id,
"x-ti-secret-code": secret_code,
}
with open(pdf_path, "rb") as f:
files = {"file": f}
resp = requests.post(url, headers=headers, files=files, timeout=120)
return resp.json()有一点要提醒：43页的文档，接口处理时间不会太短。 我这次提交后不是秒回的，需要等。所以生产环境里一定要做成异步任务加轮询，而不是同步阻塞等结果。轮询逻辑大概是这样：
python
def poll_result(task_id, app_id, secret_code, interval=5, max_wait=600):
url = f"https://api.textin.com/ai/service/v1/parse_result/{task_id}"
headers = {
"x-ti-app-id": app_id,
"x-ti-secret-code": secret_code,
}
waited = 0
while waited < max_wait:
resp = requests.get(url, headers=headers, timeout=60)
data = resp.json()
# 状态字段名请以官方文档为准
if data.get("status") == "success":
return data
time.sleep(interval)
waited += interval
raise TimeoutError("解析超时")这段代码的重点不在语法，而在于别用同步阻塞去等一个大文档。我一开始图省事直接用同步请求，结果请求挂在那，体验很差。改成提交+轮询之后，流程就顺了。
WorkBuddy 在这里干了什么
很多人看到"Agent 编排"会以为要写一堆复杂的 prompt 和工具调用。但这次任务其实很朴素：提交文档 → 等结果 → 把返回的 Markdown 按结构切开 → 分类保存。
WorkBuddy 的作用是把这几步串起来，让我不用自己写一个完整的调度脚本，而是用平台上的编排能力把"调用 xParse 接口"和"处理返回结果"两个节点连起来。对于这种线性流程，它够用。
但这里有个我实际遇到的边界问题：如果解析结果需要在平台内部做进一步处理（比如把公式转成 LaTeX 后做二次校验），WorkBuddy 的编排能力能不能直接支持自定义 Python 处理节点，这一点我没有完整验证。 我目前的做法是把结果导出到本地，用 Python 脚本做后处理，没有完全依赖平台内部的处理链路。
所以我的建议是：把 WorkBuddy 当作流程粘合剂，把重活和复杂后处理放在自己能控制的代码里。 这样即使平台某一步的能力不满足，也不会卡死整个流程。
解析结果到底长什么样
这是最关键的部分。xParse 返回的是结构化的 Markdown 为主，表格、公式、图片分别有对应的表示方式。
表格 ：返回的 Markdown 里表格会以标准的 | 分隔形式出现。对于结构规整的表格，这个还原度是可以的。但如果表格里有合并单元格、跨行跨列，Markdown 的表格语法本身就表达不了，这时候会丢结构。我这份论文里有几个三线表是规整的，解析出来基本能用；有一个带合并单元格的对比表，结构就乱了。
公式 ：这是我最关心的。xParse 对公式的处理是输出 LaTeX。行内公式一般能识别出来，块级公式也能单独成段。但要提醒：公式识别不是100%准确的，尤其是复杂的多行公式、带大量上下标的公式，识别结果需要人工核对。 我这份论文里有个带分段函数的大公式，解析出来的 LaTeX 我对着原文改了几处才正确。这不是 xParse 独有的问题，公式识别本身就是难点。
图片 ：解析结果里图片会被单独提取出来，通常在 Markdown 里以图片引用或占位的形式出现，实际图片文件需要从返回结果里单独下载。我这份论文里的流程图和数据图都提出来了，但图片和正文的位置对应关系，需要自己根据 Markdown 里的顺序去还原，接口不会自动告诉你"这张图属于第几节"。
一个真实的后处理脚本
解析结果拿到手之后，直接看是一大坨 Markdown。我写了个脚本把它按结构切开：
python
import re
def split_markdown(md_text):
"""把解析结果按标题、表格、公式、图片初步分类"""
result = {
"tables": [],
"formulas": [],
"images": [],
"text": []
}
lines = md_text.split("\n")
buffer = []
for line in lines:
# 表格行：以 | 开头
if line.strip().startswith("|"):
buffer.append(line)
else:
if buffer:
result["tables"].append("\n".join(buffer))
buffer = []
# 块级公式：$$ ... $$
if line.strip().startswith("$$"):
result["formulas"].append(line.strip())
# 图片引用：
elif re.match(r"!\[.*?\]\(.*?\)", line.strip()):
result["images"].append(line.strip())
else:
result["text"].append(line)
if buffer:
result["tables"].append("\n".join(buffer))
return result这个脚本很糙，但够用。为什么这么写：因为解析结果的主体是文本流，表格和公式都是嵌在里面的，与其去猜接口返回的 JSON 结构，不如直接在 Markdown 文本层面做切分，稳定且不依赖接口细节。
跑完之后，我得到了十几个表格块、若干公式、几张图片引用，剩下的就是正文。这就达到了我最初的目标------把一份混排的论文拆成可分类处理的素材。
这套方案适合什么、不适合什么
跑完这一趟，我对这套组合的定位比较清楚了。列个表：
| 方案/特性 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| WorkBuddy + xParse | 流程编排省事，解析交给专业接口 | 复杂表格和公式仍需人工核对 | 批量处理结构相对规整的文档 |
| 纯本地 Python + 开源解析库 | 完全可控，无网络依赖 | 公式和表格解析效果通常不如专用接口 | 对数据隐私要求高、文档量不大的场景 |
| 纯人工整理 | 准确率最高 | 43页要花大量时间 | 文档量极小、精度要求极高 |
我的判断是：如果文档量大、结构相对规整、且能接受"解析后人工校对"这个环节，这套组合是划算的。 它把80%的机械劳动省掉了，剩下20%的校对是绕不开的。但如果你的文档里全是复杂公式和合并单元格表格，指望它全自动出结果，会失望。
几个我没验证清楚的点
写技术文章最怕把没验证的东西说成结论。这里明确列出我没搞清楚的：
- WorkBuddy 的完整能力边界。我没有找到权威的公开文档，它对自定义代码节点、异常重试、并发处理的支持程度，我没有完整测试。
- xParse 的准确率数据。我没有做大规模对比测试，只跑了一份文档，不能说"准确率95%"这种话。
- 大批量并发的表现。43页单文档我跑了，但同时提交几十份文档会怎样，配额、限流、失败重试策略，我没测。
- 公式识别的具体错误率。我只知道自己手改了几处，没有统计总数。
这些点如果谁有实测数据，欢迎补充。
最后说点实际的
这次实测下来，最大的收获不是"某个工具多强"，而是想清楚了一件事：文档解析这种任务，不要指望一个接口全自动搞定。 合理的做法是让工具做它擅长的（版面识别、表格提取、公式转 LaTeX），把不确定性留给后处理环节，用代码去做分类、校验、补全。
WorkBuddy 在这个流程里扮演的是"胶水"角色，把提交、等待、取结果串起来，省了我写调度逻辑的功夫。xParse 干的是实打实的解析活。两者配合，43页论文的结构化拆解能在可接受的时间内完成，但最终质量取决于你愿意花多少时间做校对。
如果你的场景和我类似------文档多、结构中等复杂、能接受人工过一遍------这套组合值得试。如果追求100%自动且零校对，那目前的文档解析技术还到不了那个程度，这一点要提前有预期。