最近在折腾 deepseek harness 的时候我发现一个很有意思的问题模型能看懂我贴过去的几十行报错日志但当屏幕上弹出一个复制不了文字的异常窗口时我却只能手动截图再把图片拖进聊天框然后复制一份描述发给模型。整个过程既打断思路又容易丢失关键细节。更麻烦的是当 DeepSeek 被接进 harness 这类偏向自动执行的 AI 编码工具后模型只会处理文本和工具调用它根本看不到你屏幕上正在显示的画面。说白了大多数 AI 编程助手存在一个天然的“视觉盲区”它能读代码、读终端、读你上传的文件但看不到你当前屏幕上正在发生的事情。前端照着设计稿写页面、调试 GUI 弹出提示、分析某个按钮的布局问题……这些场景里模型缺的并不是推理能力而是一条“屏幕信息进入上下文”的通道。这篇文章要讲的就是我自己给 deepseek harness 写的一个识屏插件一键截取当前屏幕自动提取屏幕上的文字和结构信息再以文本或图片附件的方式注入模型上下文让 DeepSeek 在干活的时候“看得见”你正在看的画面。我会从痛点场景、核心概念、插件设计、完整代码、运行验证、常见问题排查以及后续怎么和 harness 类工具集成这几个角度展开。如果你正在用 DeepSeek 做编码代理或者想给自己的 Agent 工具增加“视觉输入”能力这篇文章应该能帮到你。1. 这篇文章真正要解决的问题先看三个非常常见的开发场景。场景一调试 GUI 程序时弹窗报错但复制不了文字。很多桌面程序的错误对话框并不允许选择文本你只能截图、放大、再手动把关键字敲进 Prompt。遇到英文错误还能勉强拼一下遇到中文乱码或超长路径手打基本不可能准确。场景二前端照着设计稿还原页面。你拿着设计师给的 UI 图想让 DeepSeek 帮你生成布局代码。你总不能把设计稿“用文字描述”成“左上角是一个 56 像素高的导航栏背景色大概是 #F5F5F5右边有一个按钮……”这个描述过程不仅费时而且必然失真。模型拿到的是你转述过一遍的信息不是原始信息。场景三调试画布、图表、渲染类问题。图表显示异常、Canvas 绘制错位、CSS 布局在某个宽度下崩掉这类问题的关键信息大量存在于“视觉”上。文本日志只能告诉你结果很难告诉你画面到底哪里不对。传统处理方式其实就一句话人充当模型和屏幕之间的“翻译官”。你得先看屏幕再用文字描述给自己看最后把这段描述塞给模型。这个过程中最消耗人的不是技术而是转述成本——从像素到文字再从文字到模型可理解的叙述信息每一步都在衰减。所以识屏插件的核心价值不是让模型“看见”所有东西。更准确地说它是把视觉信息转换成模型可以高效处理的内容格式并把这部分内容自动注入上下文。真正降低的是人与 AI 之间信息转述的摩擦。判断一下适用读者如果你只是偶尔用网页版聊天助手问问题那这篇文章的方法对你来说偏工程化如果你正在搭建基于 DeepSeek 的编码代理、本地 Agent 工具链或者经常处理“屏幕上有但文本里没有”的信息那这个插件思路可以直接抄作业。接下来我们先把 deepseek harness 和普通聊天程序的差异讲清楚否则后面识屏数据“注入到哪里”会很难理解。2. deepseek harness 的核心概念与适用场景2.1 harness 和 Agent 到底有什么区别很多同学看到 “deepseek harness” 会默认它是一个聊天客户端和网页版差不多只是能在本地跑。这个理解偏差挺大的。传统聊天框的工作模式是用户提问 → 模型回答 → 用户再提问。模型从头到尾只能“说话”不能动手。而 harness 类工具的核心是给模型一个可以自己调用工具、读写文件、执行命令、维护多步骤任务状态的运行环境。你可以把网页聊天模型想象成一个只能动嘴的顾问而 harness 里的模型是一个有工位、有电脑、有工具权限的实习生。这里经常有人混淆两个概念概念通俗含义关键区别Agent能自主决策、调用工具的 AI 系统是一个抽象概念强调“目标导向”和“自主性”HarnessAgent 的工程化运行框架通常包含工具注册、上下文管理、任务状态、权限控制强调“把这些能力稳定编排起来”打个比方Agent 是“实习生”这个角色Harness 是“实习生的工位和公司规范”。实习生再聪明如果工位上没有工具、没有网络、没有操作规范他也干不了活。Harness 解决的就是这层工程化问题怎么让模型安全地调用工具怎么管理上下文长度怎么在任务中断后恢复。那 deepseek harness 是什么它本质上是“用 Harness 工程方式集成 DeepSeek 模型”的一类工具或项目。社区里有时叫它 deepseek harness有时又叫 codex harness原因就是这类工具的代码框架往往沿袭同一套思路只是把模型后端换成 DeepSeek。它能够让你用 DeepSeek 的 API 以 Agent 的方式完成自动编码任务而不仅仅是在终端里聊聊天。2.2 它和“DeepSeek 桌面版”是两回事从网络搜索来看不少人在搜“deepseek harness 官网”“deepseek harness 桌面版”好像它是一个固定产品。这里需要提醒一句在开源社区里“deepseek harness”更多描述的是“一类工具”而不是某一个官方客户端的名称。你在 GitHub 或技术社区看到的具体项目可能仓库名、安装方式、命令都不同。真正值得关注的是这个项目是否提供了 harness 工程所需要的工具调用、上下文管理、多轮执行能力而不是纠结它叫什么名字。这类工具的典型能力包括在终端对话中让模型读取项目文件、执行 Shell 命令、调用外部 API、维护多轮任务计划。实际体验做完后我的判断是它的难点不在“把 API 调通”而在“如何稳定地编排上下文”。一旦任务步骤变多模型要自己决定下一步调什么工具上下文里的信息怎么组织就变得非常重要。而识屏插件的本质恰恰是给这个上下文增加一种“视觉来源”。2.3 为什么值得折腾如果你只写简单脚本让模型生成一段代码网页版完全够用。但当你希望模型完成的是一个跨文件、多步骤的工程任务时就需要 harness 类工具帮它管理工作目录、执行环境和上下文。DeepSeek 的 API 成本相对可控再加上国内访问顺畅所以用 DeepSeek 作为 harness 的模型后端是很多开发者会选择的一条低成本路径。理解了这些接下来我们就可以进入正题给这套系统加上“眼睛”。识屏插件要做的事情并不复杂但设计上有几个坑需要提前说清楚。3. 识屏插件的设计思路从截图到上下文3.1 完整的信息链路一个识屏插件并不是简单做一次屏幕截图就完事。它需要完成整条链路屏幕像素 → 截图 → 图像预处理 → 内容提取 → 上下文注入 → 模型分析这条链路里最重要的两个设计决策是用什么方式把屏幕内容变成模型能理解的信息以及这些信息注入到上下文的哪个位置。3.2 模式选择OCR 文本模式 vs 多模态图片模式屏幕信息进入模型上下文有两条路模式做法优点缺点OCR 文本模式截图后用 OCR 引擎提取文字把文字作为普通文本放进 Prompt兼容所有文本模型token 消耗低信息稳定只能提取文字无法理解布局、颜色、图形多模态图片模式直接把 base64 编码的截图作为图片附件传给模型模型能看到完整视觉信息布局理解更准确需要模型支持图像输入token 消耗和成本更高部分 API 模型可能不支持实际项目中更推荐的做法是“文本模式优先多模态模式作为增强”。原因很简单OCR 模式的门槛最低任何支持文本的模型都能处理多模态模式则要看你的接入方式是否支持图片输入。DeepSeek 官方 API 的可用模型和视觉能力以官方文档为准不要假设所有模型都能直接传图。如果接的是本地多模态模型或者某个 OpenAI 兼容网关image 模式才有意义。3.3 关键设计决策整个插件有四个关键决策点这也是最容易踩坑的地方截图范围。全屏截图最简单但会引入大量无关信息更实用的是支持“当前窗口”或“选区截图”。第一版可以只做全屏但代码结构上一定要预留参数位置。图像压缩。屏幕截图分辨率往往很高直接把原图塞给多模态模型会浪费 token。建议缩放长边到 1024~1536 像素JPEG 压缩到 80~85 质量视觉信息损失不大token 却少很多。OCR 后处理。OCR 出来的原始文本往往没有结构比如“确定 取消”两个按钮挤在一行。如果要做布局分析可以输出带坐标的文本块或者在文本中保留换行和缩进。第一版宁可多做一步清洗也不要直接拿原始 OCR 结果去问模型。上下文注入位置。识屏结果一般不适合塞进 system prompt更适合作为最新一条 user 消息或者作为工具调用的返回值。因为它是“当前任务的信息”不是“模型的固定规则”。一句话总结设计思路插件的作用不是让模型直接“看屏幕”而是把屏幕信息整理成模型最容易消化的格式再放进它正在处理的任务上下文。下面的代码实现会围绕这条链路展开。4. 环境准备与基础配置4.1 运行环境本文示例使用 Python 3.9操作系统以 Windows / macOS / Linux 通用为主。涉及屏幕上取词的方案Windows 下用PIL.ImageGrab也能做但跨平台推荐mss不仅速度快而且对多显示器的支持更好。4.2 依赖安装建议先建一个独立目录再创建虚拟环境mkdir screen-plugin cd screen-plugin python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate创建requirements.txtmss9.0.0 Pillow10.0.0 openai1.30.0 python-dotenv1.0.0 paddleocr2.6.0 paddlepaddle2.5.0如果你不想安装 PaddleOCR 这样较大的依赖也可以把 OCR 引擎换成 Tesseract或在文本模式下先不做 OCR直接截屏后人工填 Prompt。上面这两条安装命令只是示例实际版本请以你本机环境和官方依赖说明为准。安装命令pip install -r requirements.txtPaddleOCR 安装包较大首次下载可能需要几分钟。如果只是验证链路建议先把paddleocr、paddlepaddle两行注释掉先跑通“截图 API 调用”再决定要不要加 OCR。4.3 DeepSeek API Key 配置访问 DeepSeek 开放平台创建 API Key。然后在本目录创建.env文件DEEPSEEK_API_KEYsk-你的key DEEPSEEK_BASE_URLhttps://api.deepseek.com DEEPSEEK_MODELdeepseek-chat注意DEEPSEEK_MODEL具体填什么要以你在平台能开通的模型为准示例中deepseek-chat只是常见的命名方式。不要把 key 写进代码或提交到 Git。4.4 项目目录结构后面代码会按下面的结构组织screen-plugin/ ├── requirements.txt ├── .env ├── config.py ├── screen_capture.py ├── ocr_engine.py ├── deepseek_client.py └── clip_assistant.pyclip_assistant.py是主入口负责把截图、OCR、模型调用串起来。5. 完整示例代码实现5.1 配置文件config.py这个文件负责读取环境变量并提供统一的配置对象。这样其它模块不用到处读取.env。# 文件路径screen-plugin/config.py import os from dotenv import load_dotenv load_dotenv() class Config: api_key: str os.getenv(DEEPSEEK_API_KEY, ) base_url: str os.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com) model: str os.getenv(DEEPSEEK_MODEL, deepseek-chat) # 截图默认保存目录 work_dir: str os.getenv(SCREEN_WORK_DIR, ./data) classmethod def ensure_work_dir(cls) - None: os.makedirs(cls.work_dir, exist_okTrue)这里的work_dir用来存放截图和 OCR 中间结果方便出错时排查。生产环境建议用绝对路径而不是相对路径。5.2 截图模块screen_capture.py截图用mss它比PIL.ImageGrab更稳定也支持多显示器。截图后直接用 Pillow 做缩放压缩保存成 JPEG。# 文件路径screen-plugin/screen_capture.py import time from pathlib import Path import mss from PIL import Image def capture_screen(save_dir: str, max_width: int 1440, quality: int 85) - Path: 截取当前主屏幕并压缩保存为 JPEG。 参数: save_dir: 保存目录 max_width: 图片最大宽度超过则等比缩放 quality: JPEG 压缩质量 返回: Path: 保存后的图片路径 Path(save_dir).mkdir(parentsTrue, exist_okTrue) timestamp time.strftime(%Y%m%d_%H%M%S) save_path Path(save_dir) / fscreen_{timestamp}.jpg with mss.mss() as sct: # monitor1 表示主显示器如果要多屏截图可以改成 dict(left.., top.., width.., height..) sct.shot(monitor1, outputstr(save_path)) # 压缩处理 img Image.open(save_path) if img.width max_width: scale max_width / img.width new_height int(img.height * scale) img img.resize((max_width, new_height), Image.LANCZOS) img.convert(RGB).save(save_path, JPEG, qualityquality) return save_path这段代码有几个值得注意的点sct.shot会把截图直接写文件Pillow 打开后再压缩能显著减小文件体积返回的是路径对象后面 OCR 和多模态模式都要用到这个路径。5.3 OCR 模块ocr_engine.pyOCR 引擎我优先用 PaddleOCR它对中文支持较好识别准确率也不错。不同版本提供的 API 可能有细微差异这里给出的是常见用法实际请以你安装的版本为准。# 文件路径screen-plugin/ocr_engine.py from pathlib import Path import numpy as np from PIL import Image # 延迟初始化避免没有安装 PaddleOCR 时导入报错 _ocr_engine None def get_ocr_engine(lang: str ch): global _ocr_engine if _ocr_engine is None: try: from paddleocr import PaddleOCR except ImportError as exc: raise RuntimeError( 未安装 PaddleOCR请先执行: pip install paddleocr paddlepaddle ) from exc _ocr_engine PaddleOCR(use_angle_clsTrue, langlang, show_logFalse) return _ocr_engine def extract_text(image_path: Path, lang: str ch) - str: 抽取图片中的文字并尽量保留行列结构。 engine get_ocr_engine(lang) result engine.ocr(str(image_path), clsTrue) lines [] # result 结构: [ [ [box, (text, score)], ... ], ... ] for page in result: if not page: continue for item in page: box, (text, score) item if score 0.5: continue lines.append(text) # 简单去重并保留顺序 seen set() cleaned [] for line in lines: if line and line not in seen: seen.add(line) cleaned.append(line) return \n.join(cleaned) def image_to_base64(image_path: Path) - str: 把图片转成 base64供多模态模式使用。 import base64 with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8)image_to_base64是多模态模式需要的函数。我把 OCR 和 base64 放在同一个模块里是为了让主入口的调用路径更清晰。注意代码中result的解析方式依赖 PaddleOCR 的返回结构如果你用 Tesseract需要改成对应的解析逻辑。5.4 模型调用模块deepseek_client.py这个模块负责把 OCR 文本或 base64 图片发送给 DeepSeek API。使用 OpenAI SDK 兼容方式因为 DeepSeek 的 API 风格是 OpenAI compatible。# 文件路径screen-plugin/deepseek_client.py from pathlib import Path from openai import OpenAI from config import Config def build_messages(mode: str, screenshot_path: Path, ocr_text: str, prompt: str): if mode image: from ocr_engine import image_to_base64 b64_image image_to_base64(screenshot_path) return [ { role: user, content: [ {type: text, text: prompt}, { type: image_url, image_url: {url: fdata:image/jpeg;base64,{b64_image}}, }, ], } ] # text 模式把 OCR 文本作为上下文 content f{prompt}\n\n屏幕截图中的文字内容如下\n{ocr_text} return [{role: user, content: content}] def ask_deepseek(mode: str, screenshot_path: Path, ocr_text: str, prompt: str) - str: client OpenAI( api_keyConfig.api_key, base_urlConfig.base_url, ) messages build_messages(mode, screenshot_path, ocr_text, prompt) response client.chat.completions.create( modelConfig.model, messagesmessages, temperature0.2, ) return response.choices[0].message.content这里要特别说明多模态模式下图片会以data:image/jpeg;base64,...的形式作为消息内容发送。如果你的模型不支持图片输入这个请求会报错。所以主程序默认使用 text 模式更稳妥。5.5 主入口clip_assistant.py主入口脚本把各模块串起来支持命令行参数。先定义参数再调用截图、OCR、模型分析。# 文件路径screen-plugin/clip_assistant.py import argparse from pathlib import Path from config import Config from screen_capture import capture_screen from ocr_engine import extract_text from deepseek_client import ask_deepseek def main(): parser argparse.ArgumentParser(description识屏助手把屏幕内容变成模型上下文) parser.add_argument(--mode, choices[text, image], defaulttext, helptextOCR文本模式, image多模态图片模式) parser.add_argument(--lang, defaultch, helpOCR语言如 ch 表示中文en 表示英文) parser.add_argument(--prompt, default请分析这张屏幕截图说明屏幕上发生了什么并给出建议。, help发送给模型的分析指令) parser.add_argument(--no-ocr, actionstore_true, help跳过 OCR只截图不提取文字便于调试) args parser.parse_args() Config.ensure_work_dir() # 1. 截图 screenshot_path capture_screen(Config.work_dir) print(f[1] 截图已保存: {screenshot_path}) # 2. 提取屏幕文字 ocr_text if args.mode text and not args.no_ocr: print([2] OCR 识别中...) ocr_text extract_text(screenshot_path, langargs.lang) print(f[2] OCR 结果 ({len(ocr_text)} 字符)) elif args.mode image: print([2] 多模态模式直接使用截图原图) else: print([2] 已跳过 OCR) # 3. 调用模型 print(f[3] 调用 DeepSeek 模型: {Config.model}) answer ask_deepseek(args.mode, screenshot_path, ocr_text, args.prompt) print(\n 模型分析结果 \n) print(answer) if __name__ __main__: main()这个主入口把整个流程分成三步截图、提取文字、调用模型。每一步都有打印信息便于定位问题。如果你只是想先验证 API 是否通可以先跑--mode text --no-ocr这样不会经过 OCR直接发送一个空文本给模型。6. 运行结果与效果验证6.1 运行命令先激活虚拟环境然后执行python clip_assistant.py --mode text --prompt 帮我看看屏幕上这个报错窗口是什么问题如果 PaddleOCR 安装成功你会看到类似下面的输出[1] 截图已保存: ./data/screen_20250218_153012.jpg [2] OCR 识别中... [2] OCR 结果 (342 字符) [3] 调用 DeepSeek 模型: deepseek-chat 模型分析结果 从屏幕上报错窗口的内容看这是一个 Python 异常信息 KeyError: config_file ...6.2 如何判断插件成功判断成功的标准有三个截图成功data目录出现screen_*.jpg文件且打开后内容是你当前屏幕。OCR 成功终端输出的 OCR 字符数大于 0并且能从里面看到报错窗口中出现过的关键词。模型调用成功终端返回模型分析结果而不是报 401 或 400 错误。如果第 2 步失败优先检查 OCR 输出内容是否为空如果为空说明截图区域里没有文字或者 PaddleOCR 的解析逻辑和你的版本不兼容。如果第 3 步失败优先检查 API Key 和模型名称这两个是调用失败的常见原因。6.3 失败时的第一排查方向一定要记住排查顺序先看截图文件再看 OCR 文本最后看 API 报错。因为这条链路上上游错误会直接导致下游没有输出。如果你发现模型返回的内容和屏幕无关不要怀疑模型先去看 OCR 文本是不是本身就是乱的。截图是否正常、OCR 是否准确是整个插件的根基。7. 常见问题与排查方法整理一下使用过程中比较常见的几类问题。问题现象可能原因排查方式解决方案截图保存为黑屏macOS 未授权屏幕录制权限检查系统设置中的隐私与安全性在“系统设置 - 隐私与安全性 - 屏幕录制”中勾选终端或 Python 进程OCR 识别结果为空截图区域中没有文字或 OCR 阈值过高查看截图文件确认内容提高截图分辨率或调低score 0.5的过滤阈值API 返回 401API Key 未正确配置检查.env是否加载打印Config.api_key前几位重新生成 API Key确认环境变量没有拼写错误API 返回 400reasoning_content相关错误部分思考模式模型要求将reasoning_content原样回传查看 API 返回详情确认模型是否要求回传思考内容关闭 thinking 模式或在消息构造时按平台要求回传reasoning_content字段安装依赖时卡在pnpm dsh web等步骤对应 harness 项目依赖安装未完成或网络问题查看终端日志确认卡在哪一步根据具体项目 README 重试依赖安装必要时配置镜像源cc switch local proxy failed类错误本地代理或网关在转发请求时模型配置不正确查看客户端日志中的provider和model参数确认 DeepSeek provider 配置、模型名称和消息格式与平台要求一致模型返回内容很空Prompt 不明确或 OCR 文本太少尝试直接给模型一段更详细的指令把--prompt写得更具体比如“请列出红色字体的错误信息”关于reasoning_content和local proxy这两个问题社区反馈通常和“思考模式”的上下文回传有关。更稳妥的判断是如果你在 harness 或本地代理里用的是支持思考模式的模型并且开启了 thinking 模式那么请求时模型返回的reasoning_content可能需要在下一次请求中原样带回去否则上游会返回 400。解决方案不是自己硬拼消息格式而是检查你使用的 harness 项目有没有针对 DeepSeek 思考模式的参数开关。8. 如何把识屏插件接入 deepseek harness上面的脚本可以独立使用但它更大的价值是作为 harness 工具链的一部分。接入方式可以根据你使用的 harness 项目能力分三种。8.1 方式一手动注入最简单的办法先运行clip_assistant.py把模型输出的分析结果或 OCR 文本复制出来再粘贴到 harness 的对话中。这种方式适合临时使用缺点是仍然需要人工中转没有发挥自动化价值。8.2 方式二作为本地 HTTP 服务更工程化的做法是把识屏能力封装成 HTTP 接口任何 harness 都可以通过curl或代码调用。下面是一个用 Flask 实现的最小服务示例# 文件路径screen-plugin/screen_server.py from flask import Flask, request, jsonify from config import Config from screen_capture import capture_screen from ocr_engine import extract_text app Flask(__name__) app.route(/screen-text, methods[POST]) def screen_text(): Config.ensure_work_dir() data request.get_json(forceTrue) or {} lang data.get(lang, ch) screenshot_path capture_screen(Config.work_dir) text extract_text(screenshot_path, langlang) return jsonify({ screenshot: str(screenshot_path), text: text, chars: len(text), }) if __name__ __main__: app.run(host127.0.0.1, port8765)启动服务pip install flask python screen_server.py然后任意 harness 项目里都可以通过如下方式获取屏幕文本curl -X POST http://127.0.0.1:8765/screen-text \ -H Content-Type: application/json \ -d {lang: ch}这种方式的优势是识屏能力和 harness 解耦harness 只负责在需要时调用这个本地接口不需要关心截图和 OCR 的实现细节。注意服务只监听127.0.0.1不要暴露到公网。8.3 方式三封装为自定义工具如果你的 harness 项目支持注册自定义工具或者支持 MCP 这类工具协议可以把上面的/screen-text逻辑封装成“识屏工具”。具体注册方式因项目而异这里不展开写死。你要关注的核心点是工具注册时把截图路径和 OCR 文本作为工具的返回结果让它自然进入模型下一轮上下文。这样模型就具备了“按需看屏幕”的能力而不是每次截图都调用一次。9. 最佳实践与工程建议9.1 控制 token 成本和响应速度识屏插件很容易让上下文爆炸。一张 4K 截图如果不压缩直接转 base64 会给多模态模型带来很大的 token 开销。建议默认把截图长边压缩到 1024 到 1440 像素JPEG 质量控制在 80 到 85 之间。OCR 文本模式也要控制输出长度如果屏幕上是大段代码OCR 会产生非常多的文本可以按行数截断或者只保留和当前 Prompt 相关的部分。9.2 给 OCR 结果加“结构”而不是纯文本如果你需要用识屏结果做布局分析建议让 OCR 输出带坐标的信息。原始 PaddleOCR 返回结果里其实包含每个文本块的坐标你可以把坐标按“从上到下、从左到右”排序输出时加上相对位置描述比如“顶部居中有文字 XXX右下角有按钮 XXX”。模型拿到结构化文本后对布局的理解能力会明显好于一行行堆栈的裸文本。9.3 注意隐私和敏感信息屏幕截图可能包含账号、密码、聊天记录、内部系统信息。把截图发送给模型 API 之前要想清楚这些数据是否允许离开本机。如果项目对数据安全要求较高建议只使用 OCR 文本模式并且对 OCR 输出做进一步过滤。另外本地 HTTP 服务务必只绑定127.0.0.1避免局域网内其它机器也能请求你的屏幕内容。9.4 日志和缓存每次截图都重新 OCR 是浪费的。如果用户连续两次请求间隔很短屏幕内容可能几乎没有变化可以根据截图文件的创建时间和内容哈希决定是否复用上一次的 OCR 结果。同时把 OCR 原文、截图路径、API 调用耗时写入日志这样排查问题时不用重新复现现场。9.5 权限最小化如果你的识屏插件最终要交给 harness 自动调用一定要设置明确的使用边界。例如只在用户主动触发时才截图不要让模型在未授权的情况下随意调用识屏工具。在 harness 的工具描述里写清楚“这个工具会读取当前屏幕内容请谨慎调用”模型就会在合适的时机才使用它。10. 总结与后续学习方向写到这里整个识屏插件的核心逻辑已经完整了。它不复杂但解决了一个非常实际的问题把屏幕视觉信息转换成模型可以消费的上下文格式。不管是 OCR 文本模式还是多模态图片模式这条链路的通用性都很强你完全可以把它迁移到任何文本模型上。如果你要动手实践我的建议是从最小链路开始先配置好 DeepSeek API跑通--mode text --no-ocr确认 API 调用没有问题然后再加上 OCR验证屏幕上的中文、英文能不能被准确提取最后再考虑多模态模式、HTTP 服务和 harness 工具注册。千万不要一上来就接多模态那样出了问题很难分辨是截图、OCR、API 还是消息格式的错误。下一步值得深入的方向有两个一是多模态模型的支持能力如果 DeepSeek 平台开放了视觉理解模型image 模式可以真正发挥布局理解的价值二是把识屏工具封装成 MCP 工具让更多支持 MCP 的 Agent 工具链直接复用。识屏插件本质上是在给 AI 代理补上“眼睛”这个需求只会越来越普遍。建议你先跑通一个最小示例再一步步扩展收藏这篇文章作为配置参考实际项目里遇到问题也能少走弯路。