Extract Agent：从 PDF 到结构化数据的 AI 提取引擎

3 句话、2 分钟，把一份 PDF 简历变成结构化 JSON

---

先看效果

起点

手上有份简历 PDF：【高级Python开发工程师_北京】张三 3年.pdf，标准的招聘平台导出格式。

目标： 把它变成结构化 JSON，包含个人信息、教育背景、工作经历、项目经验、技能等。

第一步：一句话触发

在 AI Agent 中说一句：

使用简历：张三 3年.pdf — 提取结构化信息

Agent 自动完成认证、上传、Schema 设计、提取，约 30 秒返回首次结果：

{
  "personal_info": {
    "name": "张三",
    "phone": "186****1234",
    "email": "zhangsan@example.com"
  },
  "job_intention": {
    "expected_position": "高级Python开发工程师",
    "expected_city": "北京"
  },
  "education_experience": [
    {"school": "某海外名校", "major": "信息技术", "degree": "硕士"},
    {"school": "某211高校", "major": "数字媒体", "degree": "本科"}
  ],
  "work_experience": [
    {"company": "某大厂", "position": "高级Python开发工程师", "is_current": true},
    {"company": "某互联网公司", "position": "开发工程师"},
    {"company": "某银行软件开发中心", "position": "开发工程师"}
  ],
  "skills": ["Python", "Tornado", "Linux", "SQL", "图数据库", "机器学习", "Tensorflow", "Spark"]
}

基本信息、教育、工作、技能都覆盖了。

但仔细看有几个问题：

1. 工作描述偏笼统，缺少量化成果
2. 项目经历只提取了 1 个，工作中的项目没有被单独提炼
3. 技能列表是扁平的，没有分类

第二步：对话修正

说一句"还能补充一些其他信息？"

Agent 自动发起修正，要求补充量化成果、提炼项目、技能分类。

修正后关键变化：

工作描述从笼统变为量化——“优化查询提速 50%”、“降低成本 1/3”、"监视器覆盖 80% 服务"等数据被挖掘出来。

项目经历从 1 个扩展到 4 个，AI 从工作经历中额外提炼出 3 个项目。

技能从扁平数组重构为分类对象：

{
  "skills": {
    "programming_languages": ["Python", "SQL", "C++", "Java"],
    "frameworks": ["Tornado", "Tensorflow"],
    "databases": ["SQL数据库", "图数据库", "DynamoDB"],
    "big_data": ["MapReduce", "Spark"],
    "ml_algorithms": ["GBDT", "XGBoost", "CNN", "逻辑回归", "决策树"]
  }
}

小结

3 潮对话完成提取

潮次	用户说了什么	系统做了什么
1	“提取结构化信息”	认证→上传→Schema设计→提取
2	“还能补充一些其他信息?”	对话修正，深度挖掘量化数据
3	“返回原始JSON结构”	输出完整结构化 JSON

全程不到 2 分钟，不写一行解析代码。

---

这个效果背后，是一套多 Agent 协作系统在驱动

架构：监督-执行-业务三层分工

Extract Agent 不是一个单一模型在"猜"答案，而是三种 Agent 各司其职：

Agent	核心职责	系统定位
BusinessAgent	理解文档语义、生成提取规则	认知层
ExtractDevAgent	编写/修改提取代码、执行测试	执行层
Supervisor	评估结果、分析趋势、决策下一步	控制层

这种架构解决了单 Agent 模式的三个典型问题：

1. 注意力分散 — 单 Agent 既写代码又评估，容易顾此失彼
2. 局部最优陷阱 — 没有独立的监督视角，容易在细节里打转
3. 业务理解不足 — 缺少专门的业务认知层，提取什么字段、什么结构，全靠 prompt 里塞规则

---

与主流 Agent 方案有什么不同？

大家对 AI Agent 已经不陌生了。一边是 AutoGPT、MetaGPT、CrewAI、LangGraph 等多 Agent 框架，另一边是 Claude Code、OpenAI Codex、OpenCode 等 coding agent。

Extract Agent 和它们有什么本质区别？

1. 不是"通用对话"，而是"闭环工程"

大多数 Agent 框架的核心范式是：

LLM 思考 → 调用工具 → 观察结果 → 继续思考（ReAct 循环）

这种模式擅长开放式任务，但在文档提取这类需要精确、可重复、可量化的场景中，存在明显短板：

• 没有独立的质量评估环节，模型自己判断"够好了"就停了
• 没有业务认知前置，提取什么字段、什么结构，全靠 prompt 里塞规则
• 没有状态持久化，中途失败只能从头来

Extract Agent 的做法是把"认知 → 执行 → 评估"拆成三个独立角色，形成工程化闭环。

Supervisor 不参与执行，只做质量裁判——这不是 ReAct 循环能自然产生的结构。

2. 监督层独立于执行层

这是最关键的架构差异。在 CrewAI、MetaGPT 等框架中，Agent 之间是"协作"关系——角色平等，通过消息传递协调。

Extract Agent 的 Supervisor 是真正的控制层：

• 它不写代码、不调 API，只评估结果和做决策
• 它有独立的评估标准（覆盖率、准确率、完整度），不受执行层的"自我感觉良好"影响
• 它决定"继续修正"还是"归档结束"，执行层无权自行终止

这种"裁判与运动员分离"的设计，避免了单 Agent 或平等多 Agent 中常见的"自我满足"问题——模型觉得自己做得不错就停了，实际上漏了关键信息。

3. 业务认知前置，而非 prompt 堆砌

主流方案处理文档提取的典型做法：写一个长 prompt，把所有字段定义、格式要求、注意事项塞进去，然后祈祷模型一次搞定。

Extract Agent 把业务理解独立为 BusinessAgent：

先分析文档类型和结构，再生成 Schema 定义，最后才交给执行层。

这意味着：

• 提取规则是结构化的 Schema，不是散落在 prompt 里的自然语言描述
• Schema 可以多轮对话调整，而不是改 prompt 重跑
• 同类文档复用 Schema，不需要每次都"重新理解"

---

质量保障：在框架层，不在提示词层

很多 Agent 方案的质量控制靠 prompt 里加规则——“请仔细检查”、“确保完整”、“不要遗漏”。

这种方式本质上是在请求模型"自律"，效果不稳定。

Extract Agent 的质量保障通过 Hook 机制注入框架基础设施：

• 静态检查、超时控制、错误重试都是代码级的硬约束，不依赖模型的"自觉性"

这是工程思维和 prompt 思维的根本区别。

---

与 Coding Agent 的区别

不只是"会写代码的 AI"

Claude Code、OpenAI Codex、OpenCode 这类 coding agent 是另一个维度的对比。它们的核心能力是：

理解代码上下文 → 编写/修改代码 → 运行测试 → 迭代修复

本质上是一个强大的单 Agent + 工具调用模式。

用 coding agent 做文档提取，典型路径是：

让它写一段 Python 脚本调用 LLM API 解析 PDF，然后手动跑脚本看结果，不满意就让它改代码再跑。

这能工作，但有几个问题：

• 每次都在"重新发明轮子" — 每份文档都要写新的解析逻辑，没有 Schema 复用机制
• 质量靠人盯 — coding agent 写完代码就交差了，没有自动评估提取质量的环节
• 修正成本高 — 结果不对要改代码、重跑，而不是一句话对话修正
• 没有业务认知积累 — 上一份简历的提取经验不会自动迁移到下一份

Extract Agent 的定位不同：

它不是一个"帮你写提取代码的助手"，而是一个"端到端自动完成提取的系统"。

打个比方：

• coding agent 像是一个能力很强的实习生，你告诉他写什么他就写什么，但需要你来把控方向和质量
• Extract Agent 更像一个成熟的项目组——有人理解需求、有人写代码、有人做 code review，闭环运转

---

一句话总结差异

维度	Coding Agent	多 Agent 框架	Extract Agent
核心范式	单 Agent + 工具调用	ReAct 循环（思考→行动→观察）	认知→执行→评估 三层闭环
Agent 关系	单体，无分工	平等协作，消息传递	层级分工，监督独立
业务理解	用户口述 + prompt	prompt 内嵌规则	BusinessAgent 前置生成 Schema
质量控制	人工检查	prompt 规则 + 模型自律	Supervisor 独立评估 + Hook 硬约束
结果修正	改代码 → 重跑	Agent 自行重试	对话修正，同 batch 无限轮次
经验复用	无，每次重写	无	Schema + Session 复用
状态管理	依赖 IDE 会话	多数无持久化	每轮自动保存，断点续跑

---

不是说通用框架不好——它们解决的是不同问题。

Extract Agent 的创新在于： 针对"文档结构化提取"这个垂直场景，用工程化的三层架构替代通用的 ReAct 循环，把质量从"模型尽力而为"提升到"系统保障可控"。

---

核心运行流程

以上面的简历提取为例，三层 Agent 的协作过程：

用户: "提取简历结构化信息"
    ↓
BusinessAgent（认知层）→ 分析文档类型：招聘平台简历
                    → 生成业务规则：需要提取个人信息、教育、工作、项目、技能
                    → 输出 Schema 定义
    ↓
ExtractDevAgent（执行层）→ 基于 Schema 编写提取逻辑
                    → 调用提取 API，SSE 流式获取结果
                    → 返回首次提取结果
    ↓
Supervisor（控制层）→ 评估提取质量：覆盖率、准确率、完整度
                    → 发现问题：工作描述缺少量化、技能未分类
                    → 决策：触发修正轮次
    ↓
ExtractDevAgent（执行层，修正轮）→ 执行 chat_correct，补充量化数据
                    → 重构技能分类
                    → 返回修正后结果
    ↓
Supervisor（控制层）→ 再次评估：质量达标
                    → 决策：归档

关键点：用户只说了 3 句话，但系统内部跑了多轮"认知→执行→评估"循环。

这个闭环是自动的。

---

技术亮点

自然语言驱动的 Schema 设计

传统方案需要开发者手写 JSON Schema 或解析模板。

Extract Agent 的做法是：用户用自然语言描述"我要什么"，BusinessAgent 分析文档结构后自动生成 Schema。

支持多轮对话调整——“教育经历加个 GPA 字段”、“技能按类别分组”——直到 Schema 满意为止。

对话式迭代修正

提取结果不是"一锤子买卖"。

Supervisor 评估后如果发现质量不达标，会自动触发修正轮次。

用户也可以用自然语言反馈——“工作描述补充量化成果”、“技能按类别分组”——ExtractDevAgent 基于反馈重新提取，无需重新上传文档。

修正基于同一个 batch，支持无限轮次，直到满意归档。

Session 复用与批量提取

Schema 设计是一次性成本。设计好之后，同类文档直接复用 Session 批量提取——100 份简历只需设计 1 次 Schema，剩下 99 份直接跑。

工程级鲁棒性

系统具备生产级运行稳定性：

• 每轮自动保存状态，崩溃后可无损恢复
• API 重试采用指数退避策略
• 认证 token 过期自动刷新，运行中 401 自动重试
• SSE 流式接口无超时限制，支持长文档提取
• 自动清理未完成的工具调用

---

Hook 驱动的质量保障

质量控制不依赖提示词规则，而是通过 Hook 机制注入为框架基础设施能力：

• 自动静态检查（Ruff）
• 自动时间提醒与超时控制
• 自动错误反馈与重试

三层时间控制（常规提醒 → 倒计时提醒 → 强制终止）通过 Hook 注入，不污染 Agent 提示词。

---

如何使用 Extract Agent 以 Skill 的形式分发

安装后即可在 AI Agent（如 Claude Code）中直接使用。

安装

从内部 Skill Marketplace 一键安装：

# 添加 Marketplace（首次使用）
/plugin marketplace add <marketplace-git-url>

# 安装 Extract Agent Skill
/plugin install doc-extract-engine

安装完成后，无需额外配置。首次使用时系统自动完成注册、登录和凭证持久化。

使用方式

安装后有两种使用方式：

对话触发（推荐） — 直接用自然语言描述需求，AI 自动调用 Skill：

"用这份简历提取结构化信息"

"从这3份合同中提取甲乙方和金额"

"提取年报中的营收和净利润数据"

Skill 命令触发 — 通过 /doc-extract-engine 显式调用：

/doc-extract-engine 提取这份发票的开票信息

两种方式效果一致，对话触发更自然，命令触发更精确。

---

Skill 生态

Extract Agent 是 Skill Marketplace 中的一个能力模块。同一个 Marketplace 还提供其他文档处理能力：

Skill	能力	—
doc-extract-engine	PDF 结构化信息提取（本文介绍的）
insightdoc	PDF/图片文档解析，输出 Markdown、JSON、HTML
memect-data-api	上市公司公告数据查询与结构化提取

这些 Skill 可以组合使用——比如先用 insightdoc 将扫描件 OCR 为文本，再用 doc-extract-engine 提取结构化数据。

---

不只是简历

同样的系统，换一句提取指令就能处理完全不同的文档：

场景	提取指令示例	—
合同审查	“提取甲乙方、合同金额、期限、违约条款”
财报分析	“从年报中提取营收、净利润、资产负债率”
学术论文	“提取标题、作者、摘要、关键词、参考文献”
发票处理	“提取发票号、金额、日期、税率、开票方”
技术文档	“提取所有 API endpoint、参数和返回值”

核心逻辑不变：上传 → 自然语言描述需求 → AI 提取 → 对话修正 → 归档。

---

与传统方案的对比

维度	传统方案	Extract Agent	—
新文档适配	写新规则，数天	换一句指令，数秒
Schema 定义	手写 JSON Schema	自然语言对话生成
结果修正	改代码 → 重跑	对话修正 → 实时更新
批量处理	每种格式单独适配	Session 复用，一次建模批量跑
质量保障	人工 review	Supervisor 自动评估 + Hook 静态检查
经验积累	散落在代码注释里	系统归档，可追溯复用
故障恢复	从头重跑	状态持久化，断点续跑

---

本质

从架构角度看，Extract Agent 不是简单的"用 AI 读 PDF"，而是一个可监督的自动程序优化引擎。

它的核心思想：

1. 业务理解结构化 — BusinessAgent 将模糊的提取需求转化为明确的 Schema 定义
2. 执行过程可控 — ExtractDevAgent 在工具化沙箱中运行，文件编辑、Shell 执行、计划管理均可审计
3. 质量评估独立 — Supervisor 不参与执行，只负责评估和决策，避免"既当运动员又当裁判"

这套架构将原本由人工完成的"理解业务 → 编写代码 → 运行评估 → 调优修复"循环，转化为自动化闭环。

压缩人工开发时长，提高提取准确率，构建可恢复、可监督、可优化的自动开发系统。