harness 补视觉能力，TaoToken 管 DeepSeek 的文本消耗

1. 复现：当 DeepSeek agent 说「看不了图」

DeepSeek agent 报I can't view images，多数不是模型坏了，而是 harness 没把视觉能力注册成工具。先到 TaoToken 官网 拿 Key，Base URL 填https://taotoken.net/api。

你写了一个 coding agent，底层用 DeepSeek 这类纯文本模型。产品经理发来一张design.png，说「照着这个把登录页写出来」。你把图片路径塞进上下文，agent 回复：「我无法查看图片，请用文字描述。」测试同学甩来一张报错长截图，agent 说：「请把错误日志复制成文本。」你想让 agent 自己打开网页、定位按钮、点一下，它连屏幕都「看不见」。

这不是 DeepSeek 的问题，也不是 prompt 写得不够好。纯文本模型没有视觉输入通道，你给它一个本地文件路径，它无法把路径变成像素，更无法从像素里读出文字、布局和元素坐标。

过去只有两条路：

1. 换多模态模型，把图片直接扔给模型；
2. 放弃「让 agent 看图」，改成人工把截图里的内容描述成文字，再喂给 agent。

第一条路成本高。强多模态模型往往比纯文本模型贵，私有化部署时显存占用、推理卡数量都是硬约束。第二条路把自动化打回了半自动：人成了 agent 的眼睛，每次截图都要人工翻译一遍。

还有第三条路：把「看图」拆成工具，挂到 harness 上。模型仍然是 DeepSeek，负责文本推理；harness 负责在需要的时候调用 OCR、UI 还原、GUI 定位等工具，把图片翻译成模型能读的文本，再把文本送回模型。TaoToken 管的就是这段文本推理的 Token 消耗——工具调用本身不烧 token，真正烧 token 的是 DeepSeek agent 读文本、做推理、生成代码和命令的那部分。

这就是本文要落地的事情：在智能体运行时里补视觉能力，同时把模型供应商切到 TaoToken，产出可复现的 harness 工具声明、调用链和用量记录。

2. 把视觉能力做成 harness 工具：声明、路由、调用链

思路一句话：不要让模型「长出眼睛」，让运行时「递上眼镜」。

harness 里要做三件事：

• 注册一组视觉工具，每个工具干一件结构化的事：长截图 OCR、UI 还原、屏幕元素定位、图片问答、像素对比、前景提取；
• 给每个工具写清楚 description，让模型知道「什么时候调我」；
• 在调用链里记录 tool call 和模型用量，区分「工具执行」和「文本推理」。

先看工具声明。下面是一个通用的 YAML 结构，命令入口按 agent-vision-toolkit 的实际安装路径替换，这里只展示声明方式：

tools: - name: vision_ocr description: 对本地图片或长截图做 OCR，返回纯文本。当用户提到报错截图、日志截图、聊天记录截图时优先调用。 command: vision-cli ocr --image "{{image_path}}" --lang zh+en parameters: image_path: string lang: string - name: vision_ui2code description: 输入设计图或界面截图路径，返回 UI 结构描述与前端代码草稿。当用户说“照着这张图写页面”时调用。 command: vision-cli ui2code --image "{{image_path}}" --framework react parameters: image_path: string framework: string - name: vision_locate description: 截取当前屏幕并定位目标元素，返回元素坐标、文本和可点击区域。用于 GUI 自动化。 command: vision-cli locate --target "{{target_text}}" parameters: target_text: string - name: vision_ask description: 对图片做问答，返回文字描述。适合“这张图里有什么”“两张图差异在哪”这类问题。 command: vision-cli ask --image "{{image_path}}" --question "{{question}}" parameters: image_path: string question: string

关键点在description。模型不会无缘无故调用工具，它需要知道触发条件。description 里要写「当用户提到报错截图时优先调用」「当用户说照着这张图写页面时调用」。这就是 skill 路由层要解决的问题：不是让模型自己「看懂」图片，而是让它学会判断「现在该 OCR 还是该 UI 还原」。

接着看调用链。一个最小的 Python 伪代码：

def run_agent_turn(image_path, user_goal): tool_name = decide_vision_tool(user_goal, image_path) tool_result = call_tool(tool_name, {"image_path": image_path}) messages = [ { "role": "system", "content": "你是 coding agent。视觉工具已经返回文本结果，请基于文本继续推理。" }, { "role": "user", "content": f"目标：{user_goal}\n视觉工具输出：{tool_result}" } ] return llm_chat(messages)

调用链可以拆成四段：

1. 用户输入目标 + 图片路径；
2. harness 根据目标选择视觉工具；
3. 工具执行，返回结构化文本；
4. DeepSeek agent 读取文本，生成代码、命令或下一步动作。

这里有一个容易混淆的点：图片问答、OCR、UI 还原工具本身可能也调用模型，但那是工具内部的视觉模型消耗。如果你用的是纯文本模型加外部视觉 CLI，那么 TaoToken 这边的消耗主要发生在第 4 步——DeepSeek agent 的文本推理。你要在用量记录里把这两类消耗分开，否则会以为「一调用工具就烧了很多 token」。

3. TaoToken 接入三件套：Claude Code / Codex / CC Switch

视觉工具挂好之后，下一步是把 agent 的模型供应商切到 TaoToken。先去 TaoToken 官网 注册并拿到 Key，然后在工具配置里把 Base URL 填成：

https://taotoken.net/api

下面分 Claude Code、Codex、CC Switch 三种情况写。注意：Claude Code 用ANTHROPIC_*，Codex 用config.toml，不要把ANTHROPIC_*套到 Codex 上。

3.1 Claude Code：settings.json

Claude Code 支持在~/.claude/settings.json或项目级.claude/settings.json里配置环境变量。示例：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "deepseek-chat" } }

如果你的 Claude Code 版本对模型名有额外要求，把ANTHROPIC_MODEL换成 TaoToken 控制台里实际可用的模型标识。保存后重启 Claude Code，让它重新读取配置。

验证方式：在 Claude Code 里执行一个纯文本任务，例如让它解释一段代码。如果请求正常返回，说明 Base URL 和 Key 已经生效。接着再让它调用视觉工具，观察 harness 日志里 tool call 和模型请求是否分开记录。

3.2 Codex：config.toml

Codex 使用~/.codex/config.toml。示例：

model = "deepseek-chat" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY"

然后在 shell 里导出 Key：

export TAOTOKEN_API_KEY=YOUR_API_KEY

如果你用的是 Windows PowerShell：

$env:TAOTOKEN_API_KEY="YOUR_API_KEY"

这里再次强调：Codex 不要写ANTHROPIC_BASE_URL或ANTHROPIC_AUTH_TOKEN，它不认这套变量。Codex 的供应商配置在config.toml里，Key 通过env_key指定的环境变量读取。

3.3 CC Switch：供应商、Key、模型三件套

CC Switch 这类工具的核心是帮你在多个供应商配置之间切换。它通常需要三件套：

• 供应商名称；
• Base URL；
• API Key；
• 模型名。

一个通用配置示例：

{ "name": "taotoken-deepseek", "baseUrl": "https://taotoken.net/api", "apiKey": "YOUR_API_KEY", "model": "deepseek-chat" }

不同版本的 CC Switch 字段名可能不同，有的叫base_url，有的叫baseUrl，有的把模型放在models数组里。以你本地界面的字段为准，值不变：Base URL 用https://taotoken.net/api，Key 用YOUR_API_KEY，模型名用 TaoToken 控制台里实际可用的标识。

切完之后，建议做一次最小验证：先让 agent 做一次纯文本对话，确认供应商切换成功；再让它调用一次vision_ocr，确认视觉工具链路没有被供应商切换影响。

4. 调用链与用量记录：确认消耗的是 DeepSeek 文本推理

很多人接完供应商就完了，结果月底看用量发现对不上。问题通常出在没区分三类消耗：

1. 视觉工具内部调用视觉模型的消耗；
2. DeepSeek agent 文本推理的消耗；
3. harness 自身重试、摘要、路由产生的额外文本消耗。

TaoToken 这边主要管第 2 类和第 3 类。你要在 harness 里记录每次 tool call 和每次模型请求，最好能对应到同一个任务 ID。

一个可复现的日志结构：

{ "task_id": "ui-restore-20260907-001", "image_path": "/data/screenshots/login-design.png", "tool_call": { "name": "vision_ui2code", "started_at": "2026-09-07T10:00:01Z", "finished_at": "2026-09-07T10:00:06Z", "result_chars": 1840 }, "llm_call": { "provider": "taotoken", "base_url": "https://taotoken.net/api", "model": "deepseek-chat", "started_at": "2026-09-07T10:00:06Z", "finished_at": "2026-09-07T10:00:12Z", "prompt_tokens": 2310, "completion_tokens": 860 } }

这样你就能回答几个关键问题：

• 这次任务到底有没有调用视觉工具？
• 视觉工具返回了多少文本？
• 这些文本进入 DeepSeek 后产生了多少 prompt token？
• 最终生成代码用了多少 completion token？

如果你在 TaoToken 控制台的 API Keys 页面看到用量，也可以和本地日志做交叉核对。进入 API Keys 页面 可以查看 Key 和用量记录。注意：工具执行本身不一定会体现在文本模型用量里，只有最终发给 DeepSeek 的文本推理会计入。

还有一个实践建议：给视觉工具返回的文本加长度上限。长截图 OCR 可能返回几千字，直接塞进上下文会让 prompt token 暴涨。可以在 harness 里做一层摘要或分段：

def compress_ocr_text(raw_text, max_chars=3000): if len(raw_text) <= max_chars: return raw_text return raw_text[:max_chars] + "\n\n[后文已截断，可要求继续分段提取]"

这不是必须的，但在成本敏感场景里很有效。你不需要为了「看图」换更贵的模型，只需要控制喂给模型的文本量。

5. 排障：OCR 返回空、路径转义、工具没被选中

视觉能力挂载之后，最常见的不是模型问题，而是 harness 配置问题。下面按现象给排查路径。

5.1 OCR 返回空字符串

先确认图片本身有文字。用本地命令检查图片尺寸和格式：

file /data/screenshots/error.png python -c "from PIL import Image; im=Image.open('/data/screenshots/error.png'); print(im.size, im.mode)"

如果图片是超长截图，OCR 工具可能没有自动分段。可以在工具声明里把长图切成多段，或者在 harness 里先切图再调用。不要直接把 20000 像素高的图塞给单次 OCR。

5.2 路径含空格或中文

不要用 shell 字符串拼接命令：

# 不推荐 vision-cli ocr --image $IMAGE_PATH

改成参数列表或显式引号：

vision-cli ocr --image "/data/screenshots/login design.png" --lang zh+en

在 Python 里用subprocess.run([...], shell=False)，避免路径里的空格、引号、中文被 shell 解释。

5.3 工具没被模型选中

如果模型面对报错截图仍然回答「请粘贴文字」，检查两点：

• 工具 description 是否写清楚了触发条件；
• skill 路由是否把「截图」「报错」「设计图」等关键词映射到了对应工具。

一个简单的路由规则示例：

def decide_vision_tool(user_goal, image_path): goal = user_goal.lower() if "报错" in goal or "日志" in goal or "error" in goal: return "vision_ocr" if "设计图" in goal or "照着" in goal or "ui" in goal: return "vision_ui2code" if "点击" in goal or "定位" in goal or "按钮" in goal: return "vision_locate" return "vision_ask"

路由可以先规则化，再逐步交给模型决策。不要一上来就指望模型每次都选对。

5.4 401 / 403 / 模型不存在

检查顺序：

1. Key 是否复制完整，有没有多余空格；
2. Base URL 是否写成https://taotoken.net/api；
3. 模型名是否和控制台一致；
4. Claude Code 是否用了ANTHROPIC_*，Codex 是否用了config.toml。

如果 Claude Code 报鉴权失败，优先看settings.json的env层级是否写对；如果 Codex 报供应商错误，优先看config.toml里model_provider是否指向taotoken。

6. 边界：结构化看图够用，审美推理换多模态

必须说清楚：这套方案不是万能的。

视觉工具做的是「把图片翻译成结构化文本」。OCR 提取文字、UI 还原输出布局描述、元素定位返回坐标和文本。模型读到的仍然是文本，不是像素级视觉特征。所以：

• 它适合：报错截图转文字、长截图 OCR、设计图还原前端结构、GUI 自动化定位、截图信息提取；
• 它不适合：判断 logo 配色好不好看、复杂图像审美、需要真正视觉推理的任务。

判断标准很简单：如果你的看图需求是「结构化的」，工具够用；如果是「审美/推理」的，老老实实用原生多模态模型。

这个边界也决定了成本策略。你不需要为每一个能力短板都换更大的模型。视觉缺失，加视觉工具；搜索缺失，加搜索工具；计算缺失，加计算器工具。模型负责文本推理，harness 负责补短板。TaoToken 管的是模型那部分文本消耗，工具执行按你自己的本地环境或工具侧计费。

对做企业 AI 落地的人来说，这个思路值钱的地方在于：它把「换模型」变成了「加工具」。私有化部署里，显存和卡数往往是硬约束，能继续用纯文本模型，同时通过工具获得结构化视觉能力，部署复杂度和成本都会低很多。

7. 落地清单与 CTA

最后给一份可以照着做的落地清单。

第一步：拿 Key，确认 Base URL

访问 TaoToken 官网 注册并创建 API Key。Base URL 填https://taotoken.net/api，Key 占位符用YOUR_API_KEY。

第二步：按工具写配置

• Claude Code：settings.json里写ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL；
• Codex：config.toml里写model_provider、base_url、env_key；
• CC Switch：供应商、Key、模型三件套，值统一用 TaoToken 的 Base URL 和你的 Key。

第三步：注册视觉工具

在 harness 里声明vision_ocr、vision_ui2code、vision_locate、vision_ask。description 写清触发条件，命令入口按实际安装路径替换。

第四步：记录调用链

每次任务记录 task_id、tool_call、llm_call、prompt_tokens、completion_tokens。区分工具消耗和文本推理消耗。

第五步：做一次端到端验证

拿一张报错长截图，让 agent 走完「识别图片 → 调用 OCR → 读文本 → 给出修复建议」全流程。再拿一张设计图，让它走「UI 还原 → 生成前端代码」流程。最后在 TaoToken 控制台核对用量。

如果你还没决定用哪种方式接入，可以先从对话测起：

• 模型对话：https://taotoken.net/models/detail/chat?utm_source=taotoken_aicg_blog_end&utm_content=harness_chat
• Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=harness_plan
• API Keys：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=harness_keys
• Claude Code 文档：https://taotoken.net/doc/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=harness_claudecode

DeepSeek 看不了图，不一定要换模型。把视觉能力做成 harness 里的工具，让 DeepSeek 继续负责它擅长的文本推理，TaoToken 管住这部分 Token 消耗，这条路对成本敏感的团队更现实。