1.1 获取令牌 · API

正式版 v2.0

获取 API 访问令牌(access_token)及刷新令牌(refresh_token),用于后续所有服务的鉴权。


接口规范

POST /ocr_login (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:使用用户凭证(apiid + password)获取 JWT 格式的访问令牌。该令牌需在后续 API 请求的 Authorization 头中携带,格式为 gjcool <access_token>

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段内容说明
无特殊设定-本接口无需认证头

📦 请求体参数 (multipart/form-data)

字段是否必选格式说明
apiidform-data 唯一用户标识,可从账户页面获取。
passwordform-data 密码(明文或加密,由 encrypt 决定)。
encryptform-data 0:明文(默认);1:加密(需申请公钥,加密步骤见说明)。
is_longform-data 0:短有效期(24小时,默认);1:长有效期(90天)。
🔐 密码加密步骤(encrypt=1)
1. 将密码明文字符串按 UTF-8 编码;
2. 使用申请到的 RSA 公钥对编码后的数据进行加密;
3. 将加密后的密文进行 Base64 编码,得到最终 password 字段值。

✅ 成功响应 (200 OK)

Content-Type: application/json
字段含义格式
access_tokenAPI 鉴权令牌JWT 字符串
refresh_token刷新令牌(有效期30天)JWT 字符串
{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "refresh_token": "eyJhbGciOiJIUzI1NiIs..."
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误信息"}
字段含义详细错误类型
msg 错误描述
  • "Bad request":apiid 或 password 校验错误
  • "User blocked":非正式授权用户或授权过期
  • "encrypt wrong":encrypt 参数值非法
  • "Decrypt failed":密文解密失败
  • "password wrong":其他密码相关错误

以上为常见错误类型,其他错误类型恕不赘述。

📎 cURL 调用示例

curl -X POST https://BASE_URL/ocr_login \
  -F "apiid=YOUR_API_ID" \
  -F "password=YOUR_PASSWORD" \
  -F "encrypt=0" \
  -F "is_long=0"

🔔 注意事项

  • 获取的 access_token 需在后续 API 请求的 Authorization: gjcool <token> 头中使用。
  • 令牌过期前,可使用 refresh_token 刷新(刷新接口另行提供)。
  • 长有效期令牌(90天)适用于长期运行的服务,但请妥善保管。

大模型工具集成说明

授权接口通常不直接作为大模型工具暴露,而是由 MCP Server 或 Skill 后端在调用其他 API 时自动完成令牌获取与刷新。开发者应实现令牌管理机制,确保工具调用时 Authorization 头有效。

若确需大模型代为获取令牌(如用户提供 apiid/password 场景),可定义如下工具(谨慎使用,避免泄露凭证):

{
  "name": "get_access_token",
  "description": "使用 apiid 和密码获取 API 访问令牌。仅当用户明确提供凭证时调用。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "apiid": {"type": "string"},
      "password": {"type": "string"},
      "is_long": {"type": "integer", "enum": [0,1], "default": 0}
    },
    "required": ["apiid", "password"]
  }
}
安全警告:避免将 apiid/password 硬编码在提示词或工具参数中;推荐使用环境变量或外部密钥管理。
古籍酷授权系统 · 遵循 JWT 标准 | 文档更新于 2026年5月

1.2 令牌刷新 · API

正式版 v2.0

使用 refresh_token 获取新的 access_token,延长会话有效期,避免频繁重新登录。


接口规范

POST /ocr_refresh (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:当 access_token 即将过期或已过期时,使用授权接口获得的 refresh_token 获取新的 access_token。刷新后原 access_token 立即失效,新的 access_token 有效期为 24 小时(短有效期)或延续原长有效期剩余时间(若原为长有效期)。

请求方法POSTContent-Typeapplication/x-www-form-urlencodedmultipart/form-data(无请求体参数)。

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <refresh_token> 认证方式:固定前缀 "gjcool" 与刷新令牌之间使用单个空格连接。refresh_token 从授权接口(/ocr_login)的响应中获取。

📦 请求体 (Body)

无特殊设定,无需传递任何参数。

✅ 成功响应 (200 OK)

Content-Type: application/json
字段含义格式
access_token新的访问令牌,有效期24小时(短有效期)或延长至长有效期的剩余天数。JWT 字符串
{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误信息"}
字段含义详细错误类型
msg 错误描述
  • "Token has expired":refresh_token 已过期(有效期30天),需重新登录。
  • "token wrong":refresh_token 格式错误或无效。
  • 其他认证错误(如 "no authorized""reach usage limit" 等,与登录接口相同)。

📎 cURL 调用示例

curl -X POST https://BASE_URL/ocr_refresh \
  -H "Authorization: gjcool YOUR_REFRESH_TOKEN"

🔔 注意事项

  • refresh_token 有效期:授权接口中返回的 refresh_token 有效期为 30 天。过期后需重新调用 /ocr_login 获取新的令牌对。
  • 刷新策略:建议在 access_token 过期前(例如第 23 小时)主动刷新,避免业务中断。服务端也会在 access_token 过期时返回 "Token has expired",此时客户端应使用 refresh_token 获取新令牌。
  • 令牌失效:每次刷新都会使当前的 access_token 立即失效。请勿在多线程中同时刷新。
  • 长有效期处理:若原 token 是通过 is_long=1 获取的,刷新后的新 access_token 有效期将延续原剩余天数,而非固定的24小时。

大模型工具集成说明

在 MCP 或 Skill 实现中,建议封装令牌自动刷新逻辑,而不是将刷新接口直接暴露为大模型工具。通常的做法是:

  • 在 MCP Server 内部维护 access_token 及其过期时间。
  • 每次调用需要鉴权的 API 之前,检查 token 是否将过期(如剩余时间小于 5 分钟),若是则自动调用刷新接口获取新 token。
  • 如果 refresh_token 也已过期,则返回明确的错误提示,引导用户重新登录。

若确实需要大模型代为刷新(例如在用户明确授权且提供 refresh_token 的场景),可定义如下工具(谨慎使用,避免泄露):

{
  "name": "refresh_access_token",
  "description": "使用 refresh_token 获取新的 access_token。仅当用户明确提供 refresh_token 且当前 access_token 已失效时调用。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "refresh_token": {
        "type": "string",
        "description": "从登录接口获取的 refresh_token"
      }
    },
    "required": ["refresh_token"]
  }
}
安全提醒:refresh_token 具有长期有效性(30天),务必妥善保管,避免在网络传输或日志中明文记录。MCP 实现中建议将其存储在加密的环境变量或安全存储区。
令牌刷新机制 · 基于 JWT | 文档更新于 2026年5月

2.1 古籍OCR · API

正式版 v2.0

面向中文古籍竖排文字的OCR识别,支持分行、双行夹注、多区域识别,返回单字级坐标、置信度、版面层次及结构化文本。


接口规范

POST /ocr_pro (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:识别中文古籍竖排文字图片,输出单字、文字列顺序及双行夹注信息。本接口专为传统版式优化,不支持数字、标点、字母(纯文字识别)。支持通过 area 参数指定一个或多个识别区域,适用于复杂版式(如双栏、多栏、嵌入图表等)。

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <access_token> 认证方式:固定前缀 "gjcool" 与访问令牌之间使用单个空格连接。令牌需从账户页面获取或通过授权接口申请。

📦 请求体参数 (multipart/form-data)

字段 是否必选 格式 说明
img form-data (file) 图片文件。支持的 MIME 类型:image/jpeg, image/png, image/tiff, image/webp, image/heic, image/heif, image/jp2, image/avif。体积不得超过 150MB
area form-data (string) 识别区域。字符串,格式为 "[[a1,b1,c1,d1],[a2,b2,c2,d2]]",其中 a1,b1,c1,d1 分别为矩形区域的左边界、上边界、右边界、下边界的像素值(整数)。多个区域用逗号分隔,最外层用 [] 包围。若设为 "[]" 或不设置,则默认对全图进行识别,适用于大多数简单版式。针对复杂版式(如多栏、插图分割),可设置此字段使引擎按顺序依次识别各区域。

✅ 成功响应 (200 OK)

Content-Type: application/json

返回字段较为丰富,以下按类别详细说明:

📄 基础元信息
字段含义格式
FileName图片的文件名(不含扩展名)string
ContentType图片的 MIME 类型string
Width图片宽度(像素)int
Height图片高度(像素)int
Size图片文件大小(字节)int
Area实际使用的识别区域(与请求参数相同或默认全图)string (JSON)
🔡 统计信息
字段含义格式
CharNumber识别出的总字数int
LineNumber总文字列数(竖排自然列数)int
📝 逐字详细结果(列表长度 = CharNumber)
字段含义格式
chars单字识别结果(每个元素为长度为1的字符串)List[str]
coors单字坐标 [x1, y1, x2, y2](整数像素)List[List[int]]
char_probs单字识别置信度(四位小数)List[float]
coor_probs单字坐标置信度(四位小数)List[float]
char_ids单字在全文中的序号(从0开始)List[int]
line_ids单字所在文字列的序号(从0开始)List[int]
layer版面层次信息。列表元素为整数列表,通常包含1-3个数字:
- 第一个数字:文字列序号(同 line_ids)
- 第二个数字:文字列内子区域序号(用于区分同一列内的不同区域)
- 第三个数字(可选):夹注位置(0=右侧,1=左侧)
List[List[int]]
option每个单字的非 top-1 候选字及其置信度。列表元素为字典,键为候选字(字符串),值为置信度(小数)List[dict]
📃 整合文本
字段含义格式
text按文字列分行的整合文本,列之间用 \n 分隔。双行夹注部分用 【】 包围,便于后续处理。string
{
  "FileName": "page001",
  "ContentType": "image/jpeg",
  "Width": 1500,
  "Height": 2000,
  "Size": 524288,
  "CharNumber": 68,
  "LineNumber": 4,
  "chars": ["學","而","時","習","之","不","亦","說","乎"],
  "coors": [[100,200,120,220], ...],
  "char_probs": [0.998, 0.997, ...],
  "text": "學而時習之\n不亦說乎\n【夾注內容】\n下一列文字"
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误码"}
错误类别错误码及说明
设置错误 "image size too large":图片体积超过150MB
"image format wrong":图片格式不支持
"img wrong":图片参数错误
"img read failed":图片读取失败
"heic/heif/avif failed":HEIC/HEIF/AVIF 格式解码失败
"area wrong":area 参数格式错误
"image height or width wrong":图片尺寸异常
执行错误 "OCR failed":OCR 推理失败,可稍后重试
认证错误 "user blocked":未获得正式授权
"token wrong":access_token 错误
"reach usage limit":使用量达到上限或授权过期
"request too frequent":请求频率过高
"reach traffic limit. wait *** hours":达到流量上限,需等待指定小时数

注:以上为常见错误类型,其他错误类型恕不赘述。建议在集成时根据 msg 字段做容错处理。

📎 cURL 调用示例

curl -X POST https://BASE_URL/ocr_pro \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "img=@ancient_page.jpg" \
  -F "area=[[0,0,800,1200],[900,0,1600,1200]]"

若不指定 area,则识别全图:

curl -X POST https://BASE_URL/ocr_pro \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "img=@ancient_page.jpg"

🔔 注意事项

  • 竖排专用:本接口专为竖排古籍设计,横排文字识别请使用现代OCR接口(/mod_pro)。
  • 字体支持:识别模型主要针对刻本、钞本常见字体(宋体、仿宋、楷体等)。部分生僻字、异体字可能存在漏识或误判,建议人工校对。
  • 夹注处理:双行夹注会被自动识别并用 【】text 字段中标出,同时 layer 字段提供夹注位置信息(左侧或右侧)。
  • 区域顺序:当指定多个 area 时,引擎将按数组顺序依次识别,返回的文本会按此顺序拼接。请务必按照从左到右、从上到下的阅读顺序设置区域。
  • 请求超时:较大图片或复杂版式可能需要较长时间,建议设置超时时间 120 秒。

大模型工具调用规范 (MCP / Skill 集成)

本 API 可作为大模型的视觉感知工具,使模型能够从古籍图片中提取结构化文字信息。大模型通过函数调用(Function Calling / Tool Use)触发 OCR 能力,将图像转换为文本后用于后续问答、翻译、标点等任务。

🛠️ 工具定义(Tool Schema)

推荐的工具元数据如下,可直接用于 MCP 服务或自定义 Skill 清单:

{
  "name": "ancient_chinese_ocr",
  "description": "识别古籍竖排文字图片,返回逐字结果、坐标和按列组织的文本。适用于刻本、钞本、拓片等。输出中的 text 字段为按文字列分行、夹注用【】标记的整合文本。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "image_base64": {
        "type": "string",
        "description": "图片的 Base64 编码(不含 data:image/... 前缀)"
      },
      "area": {
        "type": "string",
        "description": "可选,指定识别区域的 JSON 数组,例如 '[[0,0,500,800]]'。留空则识别全图。"
      }
    },
    "required": ["image_base64"]
  }
}
🤖 大模型调用指引(MCP / Skill 集成场景)
  • MCP Server 集成:在 MCP 服务端注册上述工具,接收 image_base64 参数后,解码为临时文件并按照 multipart/form-data 格式调用本 API。需自动填充 Authorization 头部(从环境变量或会话中获取 access_token)。
  • AI Skill 插件:Skill 描述文件中声明工具,平台运行时根据用户提供的图片(或截图)提取 base64,发起请求,并将响应中的 text 字段返回给大模型。如需进一步处理(如标点、翻译),可将 text 作为后续工具的输入。
  • 请求转换示例:模型生成的参数 {"image_base64": "iVBORw0KGgo..."} 将被 MCP Server 转换为 multipart 请求,响应中的 textchars 等字段可按需返回给模型。
📤 工具返回结果示例(给大模型的输出结构)
{
  "status": "success",
  "text": "學而時習之\n不亦說乎\n【夾注示例】",
  "char_count": 12,
  "line_count": 3,
  "full_response": {
    "chars": ["學","而","時","習","之","不","亦","說","乎","夾","注","例"],
    "coors": [[...], ...],
    "char_probs": [0.998, ...]
  }
}

大模型接收到该结构化结果后,可向用户展示识别出的文字,或基于 text 字段进行后续翻译、标点等操作。

⚙️ MCP 特定配置建议
  • 图片预处理:对于较大图片(>10MB),建议 MCP 先进行压缩或分块,或使用图片 URL 方式直传(若 API 支持)。
  • 异步/同步:OCR 任务可能耗时 5-30 秒,MCP 实现应支持异步回调或设置长超时(建议 120s)。
  • 错误映射:将 API 返回的错误码(如 OCR failed)转换为大模型可理解的提示,例如“图像文字识别失败,请检查图片清晰度”。
  • 区域参数安全area 字符串需经过验证,避免注入攻击(但 MCP 内部拼接请求时是安全的)。
📌 Skill 描述片段(YAML 格式参考)
skill:
  name: "ancient_ocr_tool"
  version: "1.0.0"
  description: "从古籍竖排图片中提取文字"
  tools:
    - name: "ancient_chinese_ocr"
      method: "POST"
      endpoint: "/ocr_pro"
      headers:
        Authorization: "gjcool "
      input_type: "multipart"
      parameters:
        - name: "img"
          type: "file"
          source: "base64"
          required: true
        - name: "area"
          type: "string"
          required: false
      output_mapping: "recognized_text = response.text"
大模型最佳实践:当用户提供古籍图片并要求阅读、翻译或提取信息时,应优先调用本工具而非依靠模型自身的视觉能力。模型的 OCR 精度有限,而专用引擎可获得更准确的文字识别结果。建议在系统提示词中说明该工具支持竖排和夹注识别,并鼓励用户提供清晰、高对比度的图片。
MCP 集成架构简图
大模型 → MCP Client → [工具调用请求] → MCP Server → 解码 base64 → HTTP 调用 OCR API → 返回识别文本 → 大模型生成回答
通过标准化工具描述,大模型可自主决定何时调用古籍 OCR 能力,实现智能化的古籍数字化工作流。

安全与配额
  • 每个 access_token 绑定账户用量配额,每日调用次数及总图片处理量以控制台显示为准。
  • 请求频率限制:默认 10 次/秒,超出返回 request too frequent
  • IP 白名单、referer 防盗链等高级安全策略可在账号设置中配置。
版本与支持
  • 当前 API 版本: v2.0 (模型升级:增强夹注识别、优化区域顺序稳定性)
  • 遇到兼容性问题或需要 MCP 快速接入示例,请联系技术支持或查阅开发者中心。
  • 变更日志:2026-05 增加 area 参数的多区域支持,增加 layer 版面信息,优化 HEIC 格式兼容性。
古籍 OCR 系统 · 竖排 / 夹注 / 区域识别 | 反馈 & 文档更新于 2026年5月

2.2 现代OCR · API

正式版 v2.0

识别现代横排文字(中英文、数字、标点、字母),返回行级文本、坐标、逐字置信度及候选字。适用于印刷体、手写体及自然场景文字。


接口规范

POST /ocr_mod (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:识别现代横排文字图片,支持中文、英文、数字、标点及字母。支持分行但不支持分段。返回行级文字、坐标、逐字置信度以及候选字信息。适用于现代书籍、文档、截图等横排文字场景。

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <access_token> 认证方式:固定前缀 "gjcool" 与访问令牌之间使用单个空格连接。令牌需从账户页面获取或通过授权接口申请。

📦 请求体参数 (multipart/form-data)

字段 是否必选 格式 说明
img form-data (file) 图片文件。支持的 MIME 类型:image/jpeg, image/png, image/tiff, image/webp, image/heic, image/heif, image/jp2, image/avif。体积不得超过 150MB

✅ 成功响应 (200 OK)

Content-Type: application/json

返回字段包含图片元信息、统计信息、行级详细结果及整合文本。以下按类别详细说明:

📄 基础元信息
字段含义格式
FileName图片的文件名(不含扩展名)string
ContentType图片的 MIME 类型string
Width图片宽度(像素)int
Height图片高度(像素)int
Size图片文件大小(字节)int
📊 统计信息
字段含义格式
CharNumber识别出的总字数int
LineNumber文字行数int
📝 行级详细结果(列表长度 = LineNumber)
字段含义格式
line_chars 每行文字的逐字识别结果 List[List[str]]。第一层列表为行,第二层为单字字符串列表。
line_coors 每行文字的边界坐标 List[List[int]]。每行坐标为 [x1, y1, x2, y2](左、上、右、下像素值)。
line_char_probs 每行文字的逐字识别置信度 List[List[float]]。与 line_chars 结构对应,置信度范围为 0-1,四位小数。
line_coor_probs 每行坐标的置信度 List[float]。每行一个置信度值,表示该行坐标的可靠程度。
line_option 每行文字的候选字信息(非 top-1) List[List[dict]]。第二层字典的键为候选字(字符串),值为该候选字的置信度(小数)。
📃 整合文本
字段含义格式
text 将识别结果按行合并的文本,行之间用 \n 分隔。 string
{
  "FileName": "modern_doc",
  "ContentType": "image/jpeg",
  "Width": 1200,
  "Height": 800,
  "Size": 204800,
  "CharNumber": 156,
  "LineNumber": 5,
  "line_chars": [
    ["古","籍","酷","是","一","款","专","业","工","具"],
    ["它","支","持","O","C","R","、","标","点","、","翻","译"]
  ],
  "line_coors": [[100,50,1100,80], [100,100,1100,130]],
  "line_char_probs": [[0.99,0.98,0.99,0.97,0.99,0.98,...], [...]],
  "line_coor_probs": [0.95, 0.96],
  "line_option": [[{"籍":0.01}, {"酷":0.01}], [...]],
  "text": "古籍酷是一款专业工具\n它支持OCR、标点、翻译"
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误码"}
错误类别错误码及说明
设置错误 "image size too large":图片体积超过150MB
"image format wrong":图片格式不支持
"img wrong":图片参数错误
"img read failed":图片读取失败
"heic/heif/avif failed":HEIC/HEIF/AVIF 格式解码失败
"image height or width wrong":图片尺寸异常
执行错误 "OCR failed":OCR 推理失败,可稍后重试
认证错误 "user blocked":未获得正式授权
"token wrong":access_token 错误
"reach usage limit":使用量达到上限或授权过期
"request too frequent":请求频率过高
"reach traffic limit. wait *** hours":达到流量上限,需等待指定小时数

注:以上为常见错误类型,其他错误类型恕不赘述。

📎 cURL 调用示例

curl -X POST https://BASE_URL/ocr_mod \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "img=@modern_document.jpg"

🔔 注意事项

  • 横排专用:本接口专为横排文字设计,竖排文字请使用古籍OCR接口(/ocr_pro)。
  • 语言支持:支持中英文混合、数字、常用标点符号及字母。对于生僻字或艺术字体,识别效果可能下降。
  • 行与段:本接口仅支持分行,不支持自动分段。如需分段,请在后处理中根据空行或缩进自行划分。
  • 候选字line_option 字段提供每个字的前若干候选,可用于人工校对或二次重打分。
  • 请求超时:较大图片或复杂排版可能需要较长时间,建议设置超时时间 60 秒。

大模型工具调用规范 (MCP / Skill 集成)

本 API 可作为大模型的视觉感知工具,使模型能够从现代横排文字图片中提取文本。大模型通过函数调用(Function Calling / Tool Use)触发 OCR 能力,将图像转换为文字后用于后续问答、摘要、翻译等任务。

🛠️ 工具定义(Tool Schema)

推荐的工具元数据如下,可直接用于 MCP 服务或自定义 Skill 清单:

{
  "name": "modern_ocr",
  "description": "识别现代横排文字图片(中英文、数字、标点),返回按行组织的文本及每行坐标。适用于印刷文档、截图、自然场景文字。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "image_base64": {
        "type": "string",
        "description": "图片的 Base64 编码(不含 data:image/... 前缀)"
      }
    },
    "required": ["image_base64"]
  }
}
🤖 大模型调用指引(MCP / Skill 集成场景)
  • MCP Server 集成:在 MCP 服务端注册上述工具,接收 image_base64 参数后,解码为临时文件并按照 multipart/form-data 格式调用本 API。需自动填充 Authorization 头部(从环境变量或会话中获取 access_token)。
  • AI Skill 插件:Skill 描述文件中声明工具,平台运行时根据用户提供的图片(或截图)提取 base64,发起请求,并将响应中的 text 字段返回给大模型。如需进一步处理(如标点、翻译),可将 text 作为后续工具的输入。
  • 请求转换示例:模型生成的参数 {"image_base64": "iVBORw0KGgo..."} 将被 MCP Server 转换为 multipart 请求,响应中的 text 和行级信息可按需返回给模型。
📤 工具返回结果示例(给大模型的输出结构)
{
  "status": "success",
  "text": "古籍酷是一款专业工具\n它支持OCR、标点、翻译",
  "line_count": 2,
  "char_count": 18,
  "full_response": {
    "line_chars": [["古","籍","酷","是","一","款","专","业","工","具"], ...],
    "line_coors": [[100,50,1100,80], ...],
    "line_char_probs": [[0.99,0.98,...], ...]
  }
}

大模型接收到该结构化结果后,可向用户展示识别出的文本,或基于 text 字段进行后续处理。

⚙️ MCP 特定配置建议
  • 图片预处理:对于较大图片(>10MB),建议 MCP 先进行压缩或分块,或使用图片 URL 方式直传(若 API 支持)。
  • 异步/同步:OCR 任务可能耗时 3-15 秒,MCP 实现应支持异步回调或设置长超时(建议 60s)。
  • 错误映射:将 API 返回的错误码(如 OCR failed)转换为大模型可理解的提示,例如“图像文字识别失败,请检查图片清晰度”。
  • 行合并策略:若大模型需要段落级输出,可在 MCP 中根据行坐标或空行进行后处理合并,再返回给模型。
📌 Skill 描述片段(YAML 格式参考)
skill:
  name: "modern_ocr_tool"
  version: "1.0.0"
  description: "从横排文字图片中提取文本"
  tools:
    - name: "modern_ocr"
      method: "POST"
      endpoint: "/ocr_mod"
      headers:
        Authorization: "gjcool "
      input_type: "multipart"
      parameters:
        - name: "img"
          type: "file"
          source: "base64"
          required: true
      output_mapping: "recognized_text = response.text"
大模型最佳实践:当用户提供图片并要求阅读、提取或处理其中的文字时,应优先调用本工具而非依靠模型自身的视觉能力。专用 OCR 引擎可获得更准确的文字识别结果,尤其是包含特殊符号、表格或混合排版时。建议在系统提示词中说明该工具支持中英文混合识别。
MCP 集成架构简图
大模型 → MCP Client → [工具调用请求] → MCP Server → 解码 base64 → HTTP 调用现代OCR API → 返回识别文本 → 大模型生成回答
通过标准化工具描述,大模型可自主决定何时调用现代OCR能力,实现智能化的文档处理工作流。

安全与配额
  • 每个 access_token 绑定账户用量配额,每日调用次数及总图片处理量以控制台显示为准。
  • 请求频率限制:默认 10 次/秒,超出返回 request too frequent
  • IP 白名单、referer 防盗链等高级安全策略可在账号设置中配置。
版本与支持
  • 当前 API 版本: v2.0 (模型升级:增强英文和数字识别精度,优化候选字输出)
  • 遇到兼容性问题或需要 MCP 快速接入示例,请联系技术支持或查阅开发者中心。
  • 变更日志:2026-05 增加 line_option 候选字字段,提升对模糊图片的容错能力。
现代OCR系统 · 横排 / 中英文 / 候选字 | 反馈 & 文档更新于 2026年5月

2.3 双层PDF · API

正式版 v2.0

将古籍图片与OCR文字数据合成为双层PDF(图像层+可选文字层),生成可搜索、可复制的数字文档。支持压缩控制,兼容多种OCR数据格式。


接口规范

POST /pdf (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:将原始图片和对应的OCR识别数据(JSON格式)合成为一个双层PDF文件。该PDF包含原始图像层(供视觉阅读)和可搜索/可复制的隐藏文字层,便于古籍数字化存档、全文检索和文本再利用。

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <access_token> 认证方式:固定前缀 "gjcool" 与访问令牌之间使用单个空格连接。令牌需从账户页面获取或通过授权接口申请。

📦 请求体参数 (multipart/form-data)

字段 是否必选 格式 说明
img form-data (file) 图片文件。支持的 MIME 类型:image/jpeg, image/png, image/tiff, image/webp, image/heic, image/heif, image/jp2体积不得超过 70MB(小于OCR接口的150MB限制)。
data form-data (file, JSON) OCR文本数据,JSON格式。支持两种输入格式:
- 格式一(古籍OCR输出):包含字段 'char_ids', 'line_ids', 'chars', 'coors'(即 /ocr_pro 接口的返回结构)。
- 格式二(标注平台导出):包含字段 'line_chars', 'line_coors'(即 gj.cool 标注平台的导出格式)。
引擎会自动检测格式并进行适配。
compression form-data (int) 图像压缩程度。整数,取值范围 0-5:
0:不压缩(保持原始图像质量)
1-5:压缩程度递增,数值越大压缩率越高,生成PDF文件体积越小,但图像质量相应下降。
若不设置,默认值为 0

✅ 成功响应 (200 OK)

Content-Type: application/pdf

响应体为 PDF 文件的二进制流。客户端应将其保存为 .pdf 文件或直接展示给用户。

%PDF-1.4
1 0 obj
<< /Type /Catalog ...
...
%%EOF

(实际响应为二进制数据,此处仅为示例)

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误码"}
错误类别错误码及说明
设置错误 "image size too large":图片体积超过70MB
"image format wrong":图片格式不支持
"img wrong":图片参数错误
"img read failed":图片读取失败
"heic/heif failed":HEIC/HEIF 格式解码失败(注意不支持AVIF)
"data wrong":JSON 数据格式错误或内容不完整
执行错误 "pdf failed":PDF 生成失败(可能由于文字坐标异常、字体嵌入失败等)
认证错误 "no authorized":未获得正式授权
"token wrong":access_token 错误
"reach usage limit":使用量达到上限或授权过期
"request too frequent":请求频率过高
"not in period of validity":token 不在有效期内
"wait for *** seconds":触发限流,需等待指定秒数后重试

注:以上为常见错误类型,其他错误类型恕不赘述。建议集成时对 pdf failed 进行重试(可能是临时资源问题)。

📎 cURL 调用示例

curl -X POST https://BASE_URL/pdf \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "img=@ancient_page.jpg" \
  -F "data=@ocr_result.json" \
  -F "compression=3" \
  --output output.pdf

📄 支持的 data JSON 格式示例

格式一(古籍OCR输出)

{
  "chars": ["學","而","時","習","之"],
  "coors": [[100,200,120,220], ...],
  "char_ids": [0,1,2,3,4],
  "line_ids": [0,0,0,0,0]
}

格式二(标注平台导出)

{
  "line_chars": [
    ["學","而","時","習","之"],
    ["不","亦","說","乎"]
  ],
  "line_coors": [
    [100,200,500,230],
    [100,250,400,280]
  ]
}

🔔 注意事项

  • 图片尺寸限制img 上限为 70MB,比纯OCR接口更严格,因为PDF生成需要消耗更多内存。请确保图片大小符合要求。
  • 数据格式兼容:系统会自动识别输入的数据格式。若使用古籍OCR接口(/ocr_pro)的输出,可直接将其返回的 JSON 作为 data 字段传入;若使用标注平台数据,需确保包含 line_charsline_coors
  • 压缩影响:较高的压缩级别(如 5)会显著降低图像质量,但对于文本可读性影响较小,适合注重文件体积的场景;档案级保存建议使用 compression=0
  • 文字层编码:PDF 中的文字层使用 UTF-8 编码,并嵌入相应字体,确保生僻字正确显示。
  • 请求超时:由于涉及图像处理、PDF 生成等计算密集型操作,建议设置超时时间 120 秒。

大模型工具调用规范 (MCP / Skill 集成)

本 API 通常作为后处理工具,在 OCR 识别之后调用,用于生成可检索、可存档的双层 PDF。大模型可以通过链式调用(先 OCR → 再生成 PDF)完成从图片到文档的完整工作流。

🛠️ 工具定义(Tool Schema)

推荐的工具元数据如下,可直接用于 MCP 服务或自定义 Skill 清单:

{
  "name": "create_searchable_pdf",
  "description": "将图片和OCR文字数据合成为双层PDF(图像层+可选文字层)。支持多种OCR数据格式,可控制图像压缩程度。适用于古籍数字化存档。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "image_base64": {
        "type": "string",
        "description": "原始图片的 Base64 编码(不含 data:image/... 前缀)"
      },
      "ocr_data": {
        "type": "object",
        "description": "OCR 识别结果,需符合 /ocr_pro 输出格式或标注平台导出格式"
      },
      "compression": {
        "type": "integer",
        "enum": [0, 1, 2, 3, 4, 5],
        "description": "图像压缩级别,0=不压缩,5=最大压缩。默认0。",
        "default": 0
      }
    },
    "required": ["image_base64", "ocr_data"]
  }
}
🤖 大模型调用指引(MCP / Skill 集成场景)
  • 链式调用:大模型应先调用 OCR 工具(ancient_ocrmodern_ocr)获取识别数据,然后将返回的完整 JSON 作为 ocr_data 参数传入本工具,实现从图片到 PDF 的一键转换。
  • MCP Server 集成:注册上述工具,接收 base64 图片和 JSON 数据后,解码图片并构造 multipart 请求。需自动填充 Authorization 头。建议将返回的 PDF 二进制流再进行 base64 编码返回给模型,或提供下载链接。
  • AI Skill 插件:Skill 可提供组合操作,例如用户上传图片后,自动依次调用 OCR 和 PDF 生成,最终返回 PDF 文件供用户下载。
📤 工具返回结果示例(给大模型的输出结构)
{
  "status": "success",
  "message": "PDF generated successfully",
  "pdf_base64": "JVBERi0xLjQKJeLjz9MK...",   // Base64 编码的 PDF 内容
  "file_size_bytes": 245760
}

大模型可以向用户提供下载链接或直接展示 PDF(若客户端支持)。

⚙️ MCP 特定配置建议
  • 大文件处理:由于生成的 PDF 可能较大(几十MB),MCP 返回 base64 时需注意上下文长度限制。可改为返回临时下载 URL,或要求模型异步处理。
  • 错误处理:如果 pdf failed,可提示用户检查 OCR 数据坐标是否超出图片范围,或降低压缩级别重试。
  • 格式兼容:在调用前,MCP 应验证 ocr_data 是否为已知格式(检查是否存在 line_charschars 字段),若不匹配则返回明确错误。
📌 Skill 描述片段(YAML 格式参考)
skill:
  name: "pdf_generator"
  version: "1.0.0"
  description: "将图片和OCR结果合成为可搜索PDF"
  tools:
    - name: "create_searchable_pdf"
      method: "POST"
      endpoint: "/pdf"
      headers:
        Authorization: "gjcool "
      parameters:
        - name: "img"
          type: "file"
          source: "base64"
          required: true
        - name: "data"
          type: "object"
          source: "json"
          required: true
        - name: "compression"
          type: "integer"
          required: false
      output_type: "application/pdf"
      output_conversion: "base64"
大模型最佳实践:本工具通常不单独暴露给用户,而是作为自动化工作流的一部分。建议创建“古籍数字化”复合 Skill:
1. 用户上传古籍图片 → 2. 大模型调用 ancient_ocr 识别文字 → 3. 大模型调用 create_searchable_pdf 生成 PDF → 4. 返回 PDF 供下载。
这样用户无需关心中间步骤,体验更流畅。
MCP 集成架构简图(链式调用)
大模型 → MCP Client → [工具1: OCR] → MCP Server → OCR API → 返回文字和坐标 → 大模型 → [工具2: PDF生成] → MCP Server → PDF API → 返回 PDF → 大模型提供下载
通过工具链,大模型能够自动完成“图片 → 文字 → 可检索 PDF”的完整古籍数字化流程。

安全与配额
  • 每个 access_token 绑定账户用量配额,按 PDF 生成次数计费(与图片处理次数可能独立)。
  • 请求频率限制:默认 5 次/分钟(因生成 PDF 较耗资源)。
  • 生成的 PDF 文件会暂存于服务器临时目录,响应结束后自动删除,不保留历史。
版本与支持
  • 当前 API 版本: v2.0 (增强文字层渲染精度,支持更多中文字体)
  • 若遇到 pdf failed 错误,请检查 OCR 数据中的坐标是否在图片尺寸范围内。
  • 变更日志:2026-05 增加 compression 参数,优化内存占用。
双层PDF生成系统 · 图像+文字层 | 文档更新于 2026年5月

3.1 自动标点 · API

正式版 v2.0

基于深度学习的古籍自动断句与标点添加服务,支持多段落批处理。


接口规范

POST /punct_pro (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:为未经标点的古籍文本自动添加现代汉语标点符号(句号、逗号、问号、叹号等),支持长文本与多段落结构,提升阅读与后续处理效率。

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <access_token> 认证方式:固定前缀 "gjcool" 与访问令牌之间使用单个空格连接。令牌需从账户中心获取。

📦 请求体参数 (multipart/form-data)

字段 是否必选 格式 说明
src form-data 字符串 (UTF-8)。原始古籍文本,总字数上限 100,000 字。多段落间请使用 \n\n(两个换行符)分隔。示例:"第一段内容。\n\n第二段古文献。"
keep_wrap form-data 是否保留原文中的换行符(\n)。整数:0(不保留,合并为连续文本)或 1(保留原有换行)。默认值为 0

✅ 成功响应 (200 OK)

Content-Type: application/json
字段含义格式/示例
text 自动标点后的文本列表 ["标点后的段落1。", "标点后的段落2!"]
列表长度与输入段落数量一致,每个元素为对应段落的标点结果。
{
  "text": [
    "夫仁义礼智,非由外铄我也,我固有之也。",
    "故天将降大任于斯人也,必先苦其心志,劳其筋骨。"
  ]
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误码"}
字段含义详细错误类型
msg 错误类别标识
  • 设置错误"text wrong" (文本内容无效/编码错误) ;"text too long" (超过100k字上限)
  • 执行错误"punct failed" (标点模型推理失败,可稍后重试)
  • 认证错误"no authorized" (未授权)、"token wrong" (access_token 无效)、"reach usage limit" (额度用尽或授权过期)、"request too frequent" (请求频率过高)、"not in period of validity" (token未在有效期内)、"wait for *** seconds" (触发限流,需等待指定秒数)

注:以上为典型错误码,具体实现可能包含扩展类型,请基于 msg 字段做容错处理。

📎 cURL 调用示例

curl -X POST https://BASE_URL/punct_pro \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "src=臣亮言:先帝创业未半而中道崩殂。\n\n今天下三分,益州疲弊。" \
  -F "keep_wrap=0"

🔔 注意事项

  • 请求超时建议设为 60s,文本长度较大时推理耗时相应增加。
  • 多段落严格使用两个换行符 \n\n 分割,单个换行仅当 keep_wrap=1 时保留为软换行。
  • access_token 有效期及用量限制请查阅控制台,推荐在请求头中携带 token 并定期刷新。

大模型工具调用规范 (MCP / Skill 集成)

本API完全兼容大模型生态的工具调用范式,可作为MCP (Model Context Protocol) 服务端工具或 AI Skill 插件使用。大模型通过函数调用(Function Calling / Tool Use)触发自动标点能力,将古籍文本处理无缝融入对话或智能体工作流。

🛠️ 工具定义(Tool Schema)

推荐的工具元数据如下,可直接用于 MCP 服务或自定义 Skill 清单:

{
  "name": "add_ancient_text_punctuation",
  "description": "为古籍原典文本添加现代标点符号(句号、逗号、感叹号等),支持多个自然段落,输入文本总长度不超过10万字。自动识别古文句读,提升可读性。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "src": {
        "type": "string",
        "description": "需要添加标点的古籍原文,支持多段落,段落之间必须使用两个换行符分隔(\\n\\n)。例如:'子曰:学而时习之\\n\\n有朋自远方来'。最大长度100000字符。"
      },
      "keep_wrap": {
        "type": "integer",
        "enum": [0, 1],
        "description": "是否保留原文中的换行符。0表示不保留(默认),1表示保留内部单换行符。一般场景推荐0以获得连贯标点输出。",
        "default": 0
      }
    },
    "required": ["src"]
  }
}
🤖 大模型调用指引(MCP / Skill 集成场景)
  • MCP Server 集成:在 MCP 服务端将该工具注册为 Tool 类型,并绑定到本 API 的 POST 端点。需在工具调用处理器中自动填充 Authorization 头部(从环境变量或安全上下文中获取 access_token)。
  • AI Skill 插件:Skill 描述文件中声明上述工具定义,平台运行时根据用户意图提取 src 参数,发起异步 HTTP 请求并解析 text 数组返回给大模型。
  • 请求转换示例:模型生成的参数 {"src": "吾十有五而志于学。三十而立。\n\n四十而不惑。", "keep_wrap": 0} 将被映射为 multipart/form-data 请求,响应中的 text 列表按段落顺序组装为自然语言结果。
📤 工具返回结果示例(给大模型的输出结构)
{
  "status": "success",
  "punctuated_paragraphs": [
    "吾十有五而志于学。三十而立。",
    "四十而不惑。"
  ],
  "paragraph_count": 2,
  "input_length": 28
}

大模型接收到该结构化结果后,可向用户展示为:“第一段:吾十有五而志于学。三十而立。\n第二段:四十而不惑。” 提升交互友好度。

⚙️ MCP 特定配置建议

实现 MCP 工具端点时,建议遵循以下模式:

  • 认证透传:从 MCP 会话元数据中读取 access_token,构造 Authorization: gjcool {token} 请求头。
  • 异步/同步:由于标点任务可能耗时数秒,MCP 实现应支持异步或设置合理超时(默认 60s)。
  • 错误映射:将 API 返回的错误码(如 text too long)转换为模型可理解的字符串,建议返回给大模型再处理,或直接提示用户减少文本长度。
  • 限流应对:收到 wait for * seconds 时可借助重试中间件或通知模型稍后再次尝试。
📌 Skill 描述片段(YAML 格式参考)
skill:
  name: "ancient_text_punctuator"
  version: "1.0.0"
  description: "自动为古籍添加标点,适用于文言文、史书、经典文献"
  tools:
    - name: "add_ancient_text_punctuation"
      method: "POST"
      endpoint: "/api/v1/text/punctuate"
      headers:
        Authorization: "Bearer "
      parameters:
        - name: "src"
          type: "string"
          required: true
        - name: "keep_wrap"
          type: "integer"
          required: false
      output_mapping: "punctuated_paragraphs = response.text"
大模型最佳实践:当用户提供古籍片段时,优先调用本工具而非直接让模型生成标点,可确保标点质量符合汉语言文献学规范,且避免生成幻觉。建议在系统提示词中为模型配备该工具,并明确多段落输入需用 \n\n 分隔。
MCP 集成架构简图
大模型 → MCP Client → [函数调用请求] → MCP Server (本工具) → HTTP API → 标点引擎 → 返回 punctuated_paragraphs → 大模型生成最终回答
通过标准化工具描述,大模型可自主决定何时调用标点能力,实现智能化古籍整理流程。

安全与配额
  • 每个 access_token 绑定账户用量配额,每日调用次数及总字符数限制以控制台显示为准。
  • IP 白名单、referer 防盗链等高级安全策略可在账号设置中配置。
  • 请求频率限制:默认 10 次/秒,超出返回 request too frequent
版本与支持
  • 当前 API 版本: v2.0 (模型升级:增加文件上传、保持换行参数)
  • 遇到兼容性问题或需要 MCP 快速接入示例,请联系技术支持或查阅开发者中心。
  • 变更日志:2026-05 新增工具定义规范,增强大模型调用友好性。
古籍智能标点系统 · 遵循 RESTful 设计 | 反馈 & 文档更新于 2026年5月

3.2 古文翻译 · API

正式版 v2.0

基于序列到序列深度学习的文言文→现代文翻译服务,支持整段通译或逐句对照输出。


接口规范

POST /wenbai (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:将古典汉语(文言文)自动翻译为现代汉语。支持两种输出模式:整段通译(适合快速阅读)与句对输出(原文–译文逐句对照,适合精读或教学)。

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <access_token> 认证方式:固定前缀 "gjcool" 与访问令牌之间使用单个空格连接。令牌需从账户中心获取。

📦 请求体参数 (multipart/form-data)

字段 是否必选 格式 说明
src form-data 字符串 (UTF-8)。需要翻译的古文原文,总字数上限 10,000 字。支持多段落,建议段落间使用 \n\n 分隔以获得最佳断句效果。
pairs form-data 输出模式控制:0(整段输出,返回字符串)或 1(句对输出,返回包含原文-译文对照的列表)。默认值为 0

✅ 成功响应 (200 OK)

Content-Type: application/json
字段含义格式/示例
text 翻译结果 pairs=0 时:字符串,整段译文。
pairs=1 时:字典列表,每个字典包含 "orig"(原文句段)与 "trans"(对应译文)。
示例见下方。
// pairs=0 响应示例
{
  "text": "孔子说:“学了又时常温习和练习,不是很愉快吗?有志同道合的人从远方来,不是很令人高兴的吗?”"
}

// pairs=1 响应示例
{
  "text": [
    {"orig": "学而时习之,不亦说乎?", "trans": "学了又时常温习和练习,不是很愉快吗?"},
    {"orig": "有朋自远方来,不亦乐乎?", "trans": "有志同道合的人从远方来,不是很令人高兴的吗?"}
  ]
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误码"}
字段含义详细错误类型
msg 错误类别标识
  • 设置错误"text wrong"(文本无效/编码错误);"text too long"(超过1万字上限)
  • 执行错误"wenbai failed"(翻译模型推理失败,可稍后重试)
  • 认证错误"no authorized""token wrong""reach usage limit""request too frequent""not in period of validity""wait for *** seconds"

注:以上为典型错误码,具体实现可能包含扩展类型,请基于 msg 字段做容错处理。

📎 cURL 调用示例

curl -X POST https://BASE_URL/wenbai \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "src=学而时习之,不亦说乎?\n\n有朋自远方来,不亦乐乎?" \
  -F "pairs=0"

🔔 注意事项

  • 单次请求原文上限 10,000 字,超过将返回 text too long
  • pairs=1 模式对原文的断句依赖模型自动切分,长文本可能生成较多句对,响应体体积相应增大。
  • 推荐使用 pairs=0 进行快速通读,使用 pairs=1 进行逐句研读或教学展示。
  • 请求超时建议设为 60s,翻译耗时与文本长度正相关。

大模型工具调用规范 (MCP / Skill 集成)

本 API 完全兼容大模型生态的工具调用范式,可作为 MCP (Model Context Protocol) 服务端工具或 AI Skill 插件使用。大模型通过函数调用(Function Calling / Tool Use)触发古文翻译能力,将文言文转换为现代汉语,辅助古籍阅读与内容理解。

🛠️ 工具定义(Tool Schema)

推荐的工具元数据如下,可直接用于 MCP 服务或自定义 Skill 清单:

{
  "name": "translate_ancient_chinese",
  "description": "将文言文/古籍文本翻译为现代汉语。支持两种模式:整段通译(返回字符串)或逐句对照翻译(返回原文-译文对列表)。最大输入长度10000字。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "src": {
        "type": "string",
        "description": "需要翻译的古文原文,多段落建议使用两个换行符(\\n\\n)分隔。最大长度10000字符。"
      },
      "pairs": {
        "type": "integer",
        "enum": [0, 1],
        "description": "输出模式:0-整段输出(返回完整译文字符串),1-句对输出(返回逐句原文-译文对照列表)。默认为0。",
        "default": 0
      }
    },
    "required": ["src"]
  }
}
🤖 大模型调用指引(MCP / Skill 集成场景)
  • MCP Server 集成:在 MCP 服务端将该工具注册为 Tool 类型,绑定到本 API 的 POST 端点。工具调用处理器中自动填充 Authorization 头部(从环境变量或安全上下文中获取 access_token)。
  • AI Skill 插件:Skill 描述文件中声明上述工具定义,平台运行时根据用户意图提取 src 和可选的 pairs 参数,发起 multipart/form-data 请求,并将响应中的 text 字段返回给大模型。
  • 请求转换示例:模型生成的参数 {"src": "吾十有五而志于学。三十而立。", "pairs": 1} 将被映射为请求,响应中的 text 列表包含逐句对照,模型可据此组织回答。
📤 工具返回结果示例(给大模型的输出结构)
// pairs=0 模式
{
  "status": "success",
  "translation_mode": "whole",
  "translated_text": "我十五岁立志于学习;三十岁能够自立..."
}

// pairs=1 模式
{
  "status": "success",
  "translation_mode": "pairwise",
  "segments": [
    {"original": "吾十有五而志于学。", "translation": "我十五岁立志于学习。"},
    {"original": "三十而立。", "translation": "三十岁能够自立。"}
  ],
  "segment_count": 2
}

大模型接收到结构化结果后,可向用户清晰展示:“整段译文:……” 或逐句对照表格,提升交互体验。

⚙️ MCP 特定配置建议
  • 认证透传:从 MCP 会话元数据中读取 access_token,构造 Authorization: gjcool {token} 请求头。
  • 异步处理:翻译任务可能耗时数秒,MCP 实现应支持异步或设置合理超时(推荐 60s)。
  • 错误映射:将 API 返回的错误码(如 text too longwenbai failed)转换为模型可理解的字符串,建议返回给大模型后由其向用户解释。
  • 限流应对:收到 wait for * seconds 时可实现指数退避重试,或通知模型稍后重试。
📌 Skill 描述片段(YAML 格式参考)
skill:
  name: "ancient_to_modern_translator"
  version: "1.0.0"
  description: "将文言文翻译为现代汉语,支持整段或逐句对照输出"
  tools:
    - name: "translate_ancient_chinese"
      method: "POST"
      endpoint: "/wenbai"
      headers:
        Authorization: "gjcool "
      parameters:
        - name: "src"
          type: "string"
          required: true
        - name: "pairs"
          type: "integer"
          required: false
          default: 0
      output_mapping: |
        if pairs == 0: translated_text = response.text
        else: segments = response.text  # list of {orig, trans}
大模型最佳实践:当用户提供文言文片段要求翻译时,优先调用本工具而非直接让模型生成译文,可确保翻译质量符合古籍语言规范,并避免现代汉语模型对古文的“幻觉”演绎。建议在系统提示词中显式声明该工具的存在,并告知模型根据用户需求选择合适的 pairs 模式。
MCP 集成架构简图
大模型 → MCP Client → [工具调用请求] → MCP Server (本工具) → HTTP API → 翻译引擎 → 返回结构化译文 → 大模型生成最终回答
通过标准化工具描述,大模型可自主决定何时调用古文翻译能力,实现智能化古籍内容理解与交互。

安全与配额
  • 每个 access_token 绑定账户用量配额,每日调用次数及总字符数限制以控制台显示为准。
  • 请求频率限制:默认 10 次/秒,超出返回 request too frequent
  • IP 白名单、referer 防盗链等高级安全策略可在账号设置中配置。
版本与支持
  • 当前 API 版本: v2.0 (模型升级:优化长文本翻译稳定性,新增 pairs 精细控制)
  • 遇到兼容性问题或需要 MCP 快速接入示例,请联系技术支持或查阅开发者中心。
  • 变更日志:2026-05 新增工具定义规范,增强大模型调用友好性;统一响应结构。
古籍智能翻译系统 · 遵循 RESTful 设计 | 反馈 & 文档更新于 2026年5月

3.3 文本对齐 · API

正式版 v2.0

基于深度语义匹配的双语句子对齐服务,支持文言文与现代文之间的混合对齐,适用于古籍与白话译本、不同版本对照等场景。


接口规范

POST /align (完整根 URL 请参照 账号设置 中的专属端点)

功能概述:将两段中文文本(A 和 B)自动进行句子级对齐。支持古文–古文、古文–现代文、现代文–古文、现代文–现代文四种语言对类型,并提供多种输出对齐形式(如短句–短句、句–句、截断等),满足不同粒度对照需求。

请求方法POSTContent-Typemultipart/form-data

📋 请求头 (Headers)

字段 内容/格式 说明
Authorization gjcool <access_token> 认证方式:固定前缀 "gjcool" 与访问令牌之间使用单个空格连接。令牌需从账户中心获取。

📦 请求体参数 (multipart/form-data)

字段 是否必选 格式 说明
a form-data 字符串 (UTF-8)。文本 A(通常为原文或参考文本),总字数上限 10,000 字。建议使用标点符号明确断句,以提升对齐精度。
b form-data 字符串 (UTF-8)。文本 B(通常为译文或对照文本),总字数上限 10,000 字。同样建议使用标点符号作好断句。
lang form-data 整数。语言对类型: 0(古-古)、1(古-现,默认)、2(现-古)、3(现-现)。默认值为 1
output form-data 整数。输出对齐形式: 0(短句-短句,默认)、1(短句-句)、2(句-短句)、3(句-句)、4(最短句)、5(截断)。 具体含义参见下方说明。

📌 output 参数详解

  • 短句:以逗号、分号等分隔的较小区间;:以句号、问号、叹号等分隔的完整句子。
  • 0 短句-短句:将双方均切分为短句后对齐。
  • 1 短句-句:A 按短句切分,B 按句子切分,再进行对齐。
  • 2 句-短句:A 按句子切分,B 按短句切分。
  • 3 句-句:双方均按完整句子对齐。
  • 4 最短句:自动选择切分粒度更细的一方进行对齐。
  • 5 截断:当双方长度差异过大时,截断较长文本以匹配较短文本。

✅ 成功响应 (200 OK)

Content-Type: application/json
字段含义格式/示例
text 对齐结果列表 列表,每个元素为长度为 2 的字符串列表:[句子A, 句子B]
示例:[["学而时习之,不亦说乎?", "学习并时常温习,不是很愉快吗?"]]
{
  "text": [
    ["学而时习之,不亦说乎?", "学习并时常温习,不是很愉快吗?"],
    ["有朋自远方来,不亦乐乎?", "有志同道合的人从远方来,不是很令人高兴的吗?"]
  ]
}

⚠️ 异常响应 (非2xx状态码)

Content-Type: application/json | 统一错误结构 {"msg": "错误码"}
字段含义详细错误类型
msg 错误类别标识
  • 设置错误"text wrong"(文本无效/编码错误);"text too long"(超过1万字上限)
  • 执行错误"align failed"(对齐推理失败,可稍后重试)
  • 认证错误"no authorized""token wrong""reach usage limit""request too frequent""not in period of validity""wait for *** seconds"

注:以上为典型错误码,具体实现可能包含扩展类型,请基于 msg 字段做容错处理。

📎 cURL 调用示例

curl -X POST https://BASE_URL/align \
  -H "Authorization: gjcool YOUR_ACCESS_TOKEN" \
  -F "a=学而时习之,不亦说乎?有朋自远方来,不亦乐乎?" \
  -F "b=学习并时常温习,不是很愉快吗?有志同道合的人从远方来,不是很令人高兴的吗?" \
  -F "lang=1" \
  -F "output=3"

🔔 注意事项

  • 文本 A 与文本 B 各自上限 10,000 字,若任一超出将返回 text too long
  • 建议输入文本已使用标点符号(句号、逗号等)明确断句,可获得更佳对齐效果。
  • output 参数控制对齐粒度,不同粒度适用于不同场景:逐词对照建议使用短句模式(0/1/2);段落级对照建议使用句模式(3)。
  • 请求超时建议设为 60s,对齐耗时与双方句子数量正相关。

大模型工具调用规范 (MCP / Skill 集成)

本 API 完全兼容大模型生态的工具调用范式,可作为 MCP (Model Context Protocol) 服务端工具或 AI Skill 插件使用。大模型通过函数调用(Function Calling / Tool Use)触发文本对齐能力,实现原文与译文的句子级对照,辅助古籍翻译校对、多版本比较等任务。

🛠️ 工具定义(Tool Schema)

推荐的工具元数据如下,可直接用于 MCP 服务或自定义 Skill 清单:

{
  "name": "align_chinese_texts",
  "description": "将两段中文文本(如古籍原文与现代译文)进行句子级对齐,输出一一对应的句子对。支持指定语言对类型和对齐粒度。最大输入每段10000字。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "a": {
        "type": "string",
        "description": "文本 A,通常是原文或参考文本。建议使用标点符号断句。最大10000字符。"
      },
      "b": {
        "type": "string",
        "description": "文本 B,通常为译文或对照文本。建议使用标点符号断句。最大10000字符。"
      },
      "lang": {
        "type": "integer",
        "enum": [0, 1, 2, 3],
        "description": "语言对类型:0-古对古,1-古对现(默认),2-现对古,3-现对现。影响内部语义匹配策略。",
        "default": 1
      },
      "output": {
        "type": "integer",
        "enum": [0, 1, 2, 3, 4, 5],
        "description": "输出对齐形式:0-短句对短句,1-短句对句,2-句对短句,3-句对句,4-最短句,5-截断。默认为0。",
        "default": 0
      }
    },
    "required": ["a", "b"]
  }
}
🤖 大模型调用指引(MCP / Skill 集成场景)
  • MCP Server 集成:在 MCP 服务端将该工具注册为 Tool 类型,绑定到本 API 的 POST 端点。工具调用处理器中自动填充 Authorization 头部(从环境变量或安全上下文中获取 access_token)。
  • AI Skill 插件:Skill 描述文件中声明上述工具定义,平台运行时根据用户意图提取 ab 以及可选的 langoutput 参数,发起 multipart/form-data 请求,并将响应中的 text 列表返回给大模型。
  • 请求转换示例:模型生成的参数 {"a": "学而时习之。", "b": "学习并时常温习。", "lang": 1, "output": 3} 将被映射为请求,响应中的 text 为对齐后的句对列表。
📤 工具返回结果示例(给大模型的输出结构)
{
  "status": "success",
  "aligned_pairs": [
    {"source": "学而时习之,不亦说乎?", "target": "学习并时常温习,不是很愉快吗?"},
    {"source": "有朋自远方来,不亦乐乎?", "target": "有志同道合的人从远方来,不是很令人高兴的吗?"}
  ],
  "pair_count": 2,
  "output_mode": "句-句"
}

大模型接收到结构化结果后,可向用户清晰展示对照表格,或进一步总结对齐质量。

⚙️ MCP 特定配置建议
  • 认证透传:从 MCP 会话元数据中读取 access_token,构造 Authorization: gjcool {token} 请求头。
  • 异步处理:对齐任务可能耗时数秒,MCP 实现应支持异步或设置合理超时(推荐 60s)。
  • 错误映射:将 API 返回的错误码(如 align failedtext too long)转换为模型可理解的字符串,建议返回给大模型由其向用户解释。
  • 限流应对:收到 wait for * seconds 时可实现指数退避重试,或通知模型稍后重试。
📌 Skill 描述片段(YAML 格式参考)
skill:
  name: "chinese_text_aligner"
  version: "1.0.0"
  description: "将两段中文文本进行句子级对齐,用于古籍与译本对照"
  tools:
    - name: "align_chinese_texts"
      method: "POST"
      endpoint: "/align"
      headers:
        Authorization: "gjcool "
      parameters:
        - name: "a"
          type: "string"
          required: true
        - name: "b"
          type: "string"
          required: true
        - name: "lang"
          type: "integer"
          required: false
          default: 1
        - name: "output"
          type: "integer"
          required: false
          default: 0
      output_mapping: "aligned_pairs = response.text"
大模型最佳实践:当用户需要对比文言文原文及其白话译文,或比较同一古籍的不同版本时,应优先调用本工具以获得精确的句子级对齐结果,避免由模型自行猜测对应关系。建议根据用户需求自动选择合适的 output 参数(如精读时使用 3-句对句,逐词研究时使用 0-短句对短句)。
MCP 集成架构简图
大模型 → MCP Client → [工具调用请求] → MCP Server (本工具) → HTTP API → 对齐引擎 → 返回句子对列表 → 大模型生成最终回答
通过标准化工具描述,大模型可自主决定何时调用文本对齐能力,实现智能化双语对照与版本比对。

安全与配额
  • 每个 access_token 绑定账户用量配额,每日调用次数及总字符数限制以控制台显示为准。
  • 请求频率限制:默认 10 次/秒,超出返回 request too frequent
  • IP 白名单、referer 防盗链等高级安全策略可在账号设置中配置。
版本与支持
  • 当前 API 版本: v2.0 (模型升级:优化古-现混合对齐准确率,增加 output 模式)
  • 遇到兼容性问题或需要 MCP 快速接入示例,请联系技术支持或查阅开发者中心。
  • 变更日志:2026-05 新增工具定义规范,增强大模型调用友好性;统一响应结构。