1. UI-TARS 本地代理失败到底卡在哪
UI-TARS 是一个把自然语言指令翻译成鼠标点击、键盘输入、截图识别的 GUI 代理模型，适合想让桌面自动化跑起来的开发者、测试同学和折腾 Agent 的玩家。它本身不绑定某一家模型服务，只要有一个兼容 OpenAI Chat Completions 的接口，就能把「看截图 → 想下一步 → 输出动作」这条链路跑通。问题也恰好出在这里：很多人第一次跑 UI-TARS 时，模型服务地址填的是本机某个转发端口，或者某个已经失效的本地代理，结果日志里直接甩出一句local proxy failed，界面卡在「正在思考」，截图上传了但没有任何动作返回。
我遇到这个报错时的现场是这样的：UI-TARS 桌面端已经装好，辅助功能权限也给了，模型配置里 Base URL 写的是http://127.0.0.1:8000/v1，那是之前用 vLLM 起本地服务留下的地址。但本地服务早关了，端口没人监听，于是 UI-TARS 在发起请求阶段就失败。另一种常见情况是，Base URL 指向某个本地代理进程，而那个进程的上游通道不稳定，表现为连接被重置、超时，或者返回一段 HTML 而不是 JSON。UI-TARS 拿不到合法的choices字段，就会在解析阶段抛错，日志里可能同时出现local proxy failed和reading 'choices'这类关键字。
这里要区分两类失败：一类是网络层根本没连上，报错偏向连接拒绝、超时、代理失败；另一类是连上了但返回体不是预期结构，报错偏向解析choices为空或 undefined。排查时先看报错发生在请求前还是请求后，能省很多时间。UI-TARS 的模型配置界面里，模型提供者、API Key、Base URL 是三个独立字段，任何一个填错都会让整条链路断掉。尤其是 Base URL，很多人习惯性带上/v1之外的路径，或者把 endpoint 和 Base URL 混为一谈，导致请求打到了错误的路由上。
把模型调用统一接到一个稳定的 API 通道，是解决这类问题的通用思路。TaoToken 提供的就是这样一个兼容 OpenAI 协议的入口，你不需要在本机维护转发进程，也不用担心本地端口被占用或进程退出。下面我会从配置到验证，完整走一遍把 UI-TARS 从local proxy failed改到可用通道的过程，配置片段可以直接复制。
2. TaoToken 接入前的准备与 Base URL 选择
TaoToken 是一个面向开发者的模型 API 聚合入口，兼容 OpenAI 的请求格式，适合需要统一管理 Key、统一 Base URL 的场景。对 UI-TARS 来说，你只需要关心三件事：Base URL 填什么、API Key 从哪来、Model ID 写哪个。这三件套配齐，UI-TARS 就能把请求发出去，剩下的截图编码、动作解析都由 UI-TARS 自己完成。
先说 Base URL。TaoToken 的 API 入口是https://taotoken.net/api，注意这里不要额外拼/v1之外的路径，也不要带查询参数。很多 OpenAI 兼容客户端会自动在 Base URL 后面补/v1/chat/completions，所以 Base URL 填到/api这一层即可。如果你在 UI-TARS 的配置里看到的是「endpoint」字段，那通常指的是完整请求地址，这时要填https://taotoken.net/api/v1/chat/completions；如果字段名是「Base URL」，就填https://taotoken.net/api。这两个概念混用是local proxy failed之外第二常见的坑。
再说 API Key。你需要先登录 TaoToken 的控制台，在 API Keys 页面创建一个新的 Key。创建时建议给 Key 起一个能识别用途的名字，比如ui-tars-desktop，方便后续排查是哪个客户端在调用。Key 只在创建时完整显示一次，复制后妥善保存。如果你还没有账号，可以从官网入口进入：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，注册后在控制台里完成 Key 的创建。
Model ID 这块要看你实际想调用哪个模型。UI-TARS 本身是 GUI 代理模型，但它依赖一个多模态大模型来理解截图和指令。你可以选择支持视觉输入的模型，把 Model ID 填成对应的名称。具体有哪些模型可用、各自的 Model ID 是什么，可以在模型对话页面里查看，或者查阅接入文档。文档里会列出当前支持的模型清单和调用示例，地址是 https://taotoken.net/api-keys 和 https://taotoken.net/doc ，前者管理 Key，后者看接入说明。
这里有个细节值得注意：UI-TARS 在请求里会带上frequency_penalty、max_tokens这些参数，还会把截图以 base64 形式塞进image_url。所以你要选的模型必须支持图像输入，否则请求会返回参数错误，而不是local proxy failed。选模型时优先确认它是否支持 vision，再看上下文长度是否够用，因为 UI-TARS 每步都会带一张截图，多步任务下 token 消耗不小。
配置前还有一步容易忽略：确认你的网络环境能正常访问taotoken.net。如果你之前用的是本地代理，先把它关掉，避免请求被旧代理拦截。UI-TARS 的配置界面里如果有「使用系统代理」之类的开关，也一并关掉，让请求直连。做完这些准备，就可以进入下一步，把配置片段写进 UI-TARS 了。
3. 可复制的 UI-TARS 模型配置片段
UI-TARS 桌面端的模型配置界面通常提供「模型提供者」「API Key」「Base URL」「Model ID」几个输入项。不同版本字段名略有差异，但核心就是这三件套。下面给出两种常见配置形态，你可以按自己界面里的字段名对号入座。
第一种是 JSON 形态，适合通过配置文件或环境变量注入的场景。把下面这段保存为ui-tars-model.json，放在 UI-TARS 能读取的配置目录下：
{ "provider": "openai-compatible", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的TaoTokenKey", "model": "你的视觉模型ModelID", "endpoint": "https://taotoken.net/api/v1/chat/completions", "timeout": 120000, "maxRetries": 2 }注意baseUrl和endpoint的区别：前者用于客户端自动拼接路径，后者是完整请求地址。如果你的 UI-TARS 只认其中一个字段，就按字段名填对应的值，不要两个都填成完整地址，否则会出现/api/v1/v1/chat/completions这种重复路径，请求会 404。
第二种是 TOML 形态，适合用命令行启动或写进项目配置的场景：
[model] provider = "openai-compatible" base_url = "https://taotoken.net/api" api_key = "sk-你的TaoTokenKey" model_id = "你的视觉模型ModelID" endpoint = "https://taotoken.net/api/v1/chat/completions" timeout_ms = 120000 max_retries = 2 [model.extra] frequency_penalty = 1 max_tokens = 128如果你用的是 Claude Code 这类工具做辅助开发，配置思路是一样的，Base URL、Key、Model ID 三件套缺一不可。Claude Code 的配置文件里通常有ANTHROPIC_BASE_URL或类似的字段，把它指向 TaoToken 的入口即可。具体字段名以你所用工具的文档为准，接入文档里有针对不同客户端的说明：https://taotoken.net/doc 。
配置写完后，回到 UI-TARS 界面，把「模型提供者」选成 OpenAI 兼容或自定义，API Key 粘贴刚才创建的 Key，Base URL 填https://taotoken.net/api，Model ID 填你选定的视觉模型。保存后不要急着跑复杂任务，先用一个最小请求验证通道是否打通。验证方法在下一节展开。
这里提醒一个高频错误：Key 复制时带了首尾空格，或者把sk-前缀漏掉。UI-TARS 不会帮你 trim，空格会导致 401。粘贴后建议在输入框里手动检查一遍首尾字符。另外，如果你在多个客户端共用同一个 Key，建议在控制台里按用途分别创建，方便后续按 Key 排查调用来源。
4. 从报错到请求成功的验证动作
配置保存后，先别急着让 UI-TARS 执行「打开浏览器搜索天气」这种多步任务。用一个最小化的单步请求验证通道，能快速判断问题出在配置还是模型能力上。最直接的方式是用 curl 发一个纯文本请求，确认 TaoToken 通道本身可用：
curl -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的TaoTokenKey" \ -H "Content-Type: application/json" \ -d '{ "model": "你的视觉模型ModelID", "messages": [ {"role": "user", "content": "回复两个字：通了"} ], "max_tokens": 16 }'如果返回体里有choices[0].message.content，说明 Key、Base URL、Model ID 三件套正确，通道打通。如果返回 401，检查 Key 是否有效、是否带空格；如果返回 404，检查路径是否重复拼接；如果返回模型不存在，检查 Model ID 是否拼写正确。
通道验证通过后，再回到 UI-TARS 做一次带截图的请求。你可以先用 UI-TARS 自带的测试功能，或者手动构造一个带image_url的请求。下面这段 Python 代码可以直接跑，用来验证视觉输入是否被正确接受：
import base64 from openai import OpenAI client = OpenAI( base_url="https://taotoken.net/api", api_key="sk-你的TaoTokenKey", ) with open("screenshot.png", "rb") as f: encoded = base64.b64encode(f.read()).decode("utf-8") resp = client.chat.completions.create( model="你的视觉模型ModelID", messages=[ { "role": "user", "content": [ {"type": "text", "text": "描述这张截图里最显眼的按钮"}, {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{encoded}"}}, ], } ], max_tokens=128, ) print(resp.choices[0].message.content)跑通这段代码，说明 TaoToken 通道能正确处理 UI-TARS 同款的图文混合请求。此时再回到 UI-TARS 界面，输入一个简单指令，比如「打开记事本」，观察日志里是否还有local proxy failed。正常情况下，你会看到 UI-TARS 输出Thought和Action两段内容，Action里包含click或hotkey等动作定义，说明模型已经能基于截图给出下一步操作。
如果 UI-TARS 仍然报错，但 curl 和 Python 都通了，那问题大概率在 UI-TARS 自身的配置读取上。检查它是否缓存了旧的 Base URL，或者是否在启动时读取了另一个配置文件。有些版本会把配置写在用户目录下的隐藏文件里，界面修改后没有覆盖旧值。找到实际生效的配置文件，把 Base URL 改成https://taotoken.net/api再重启。
验证成功后，你可以把max_tokens适当调大，因为 UI-TARS 输出的动作描述可能超过 128 token。同时保留frequency_penalty=1，减少重复动作。多步任务下建议开启重试，网络抖动时能自动恢复，不至于一步失败整个任务中断。
5. 常见报错对照与排查清单
local proxy failed这个报错本身信息量不大，它只是告诉你请求在到达模型之前就失败了。真正有用的线索在它前后的日志里。下面按真实遇到的报错逐条对照。
第一种：local proxy failed后面跟着ECONNREFUSED 127.0.0.1:xxxx。这说明 UI-TARS 还在往本地端口发请求，配置没有生效。去模型配置里确认 Base URL 是否已经改成https://taotoken.net/api，并检查是否有多个配置文件，界面改的那个不是实际读取的那个。关掉 UI-TARS 再重启，让它重新加载配置。
第二种：401 Unauthorized或invalid api key。Key 不对。检查是否复制完整、是否带了空格、是否在控制台里被禁用或删除。如果你在 TaoToken 控制台里重新生成过 Key，旧 Key 会失效，需要同步更新到 UI-TARS。控制台地址：https://taotoken.net/api-keys 。
第三种：404 Not Found或返回 HTML 页面。Base URL 和 endpoint 混用导致路径重复。确认 Base URL 填的是https://taotoken.net/api，endpoint 填的是https://taotoken.net/api/v1/chat/completions，两者不要同时填成完整地址。如果客户端自动补/v1，Base URL 就只填到/api。
第四种：Cannot read properties of undefined (reading 'choices')。请求发出去了，但返回体里没有choices字段。常见原因是模型不支持图像输入，或者请求体格式不对。先确认 Model ID 是支持 vision 的模型，再用上一节的 Python 脚本单独验证。如果脚本也报同样的错，把请求体打印出来，检查image_url的 base64 是否完整、是否带了data:image/png;base64,前缀。
第五种：OAuth相关报错。如果你用的是 Claude Code 或其他带 OAuth 流程的工具，报错可能指向 token 刷新失败。这类工具通常需要同时配置 Base URL 和 Key，不能只配其中一个。检查配置文件里ANTHROPIC_BASE_URL或对应字段是否指向 TaoToken 入口，Key 是否填在正确的位置。接入文档里有针对 OAuth 类客户端的说明：https://taotoken.net/doc 。
第六种：请求超时。UI-TARS 每步都带截图，请求体较大，网络慢时容易超时。把 timeout 调到 120000 毫秒以上，并开启重试。如果仍然频繁超时，检查截图分辨率是否过高，适当压缩后再发送。
排查时建议按「先通道、后客户端」的顺序：先用 curl 验证通道，再用 Python 验证图文请求，最后才怀疑 UI-TARS 配置。这样能避免在客户端里反复改配置却找不到根因。每次改完配置记得重启 UI-TARS，很多客户端不会热加载模型配置。
6. 稳定跑 UI-TARS 的后续建议
通道打通只是第一步，要让 UI-TARS 稳定跑多步任务，还有几个细节值得调整。首先是截图频率，UI-TARS 默认每步都截图，如果任务步骤多，token 消耗会很快。你可以在配置里适当降低截图质量，或者只在关键步骤截图，减少单次请求体积。其次是动作解析的容错，模型偶尔会输出不符合动作空间定义的文本，UI-TARS 解析失败时会中断任务。可以在外层加一层重试，把失败步骤重新发给模型，让它重新规划。
如果你打算长期用 UI-TARS 做桌面自动化，建议把模型调用统一走 TaoToken 的 Coding Plan，这样 Key 和通道集中管理，不用在每个客户端里单独维护。Coding Plan 的入口在 https://taotoken.net/coding-plan ，适合需要长期编码和 Agent 调用的场景。日常验证模型能力时，可以直接用模型对话页面快速试，地址是 https://taotoken.net/chat 。
最后说一个我踩过的坑：UI-TARS 的辅助功能权限在系统更新后有时会被重置，表现为截图正常但点击不生效。这时去系统设置的隐私与安全里重新勾选 UI-TARS 的无障碍权限即可。这个和模型通道无关，但容易被误判成模型返回了错误动作。排查时先确认权限，再看日志里的Action是否合理，能少走弯路。
