营业执照识别OCR

解决什么问题

把一张营业执照图片变成结构化字段，看起来简单，做起来常见的坑不少：扫描件反光、拍照角度倾斜、表格版式不统一，OCR 出来的文字和字段对不上。更麻烦的是上游流程——拿到 base64 不知道往哪个参数塞，拿到 URL 以为要自己写 HTTP 客户端。这个技能把「调 OCR API」这件事收敛成一次工具调用：你只管给图，字段抽取由后端完成。

核心能力与工作流程

技能路由三种输入方式，覆盖实际开发里最常遇到的三种图片来源：

• scripts.tools.ocr_biz_license：传图片链接（dataUrl），适合图已经在某个可访问的 URL 上。
• scripts.tools.ocr_biz_license_for_data_base64：传 base64 编码（dataBase64），适合图在内存或前端传上来的场景。
• scripts.tools.ocr_biz_license_for_data_file：传本地文件路径，适合服务端已有落盘文件。

三种工具输出的字段一致，都能拿到统一社会信用代码、名称、法定代表人、注册资本、成立日期、经营范围、登记机关和住所地址这八项。

角色分工上，大模型只做路由层：检查密钥、按用户意图挑工具、抽取参数，最后把 result["raw"] 整理展示。真正的 OCR 请求由代码发起，不要把 HTTP 逻辑混进对话里。

参数不全时用 AskUserQuestion 追问，比如用户只说了「识别一下这张执照」却没给图。

适用边界与注意点

API 密钥是硬前提。 首次使用若 .env 中没有 XBY_APIKEY，必须先问用户拿到密钥，调用 scripts.config.set_api_key(key) 持久化后再继续。缺密钥时禁止自行搜索或编造数据——这是设计上的红线，宁可停下来问，也不要猜一个代码糊过去。

输入形式上，三种工具互斥使用，按你手上的数据形态选，不要给 URL 场景传文件路径。返回结构固定：raw 是 API 原始 JSON（整理后直接展示），success 表示成功与否，message 是状态消息，失败时优先看 message 定位原因。