1. 为什么要在 TIA Portal 场景里给 CLI 换 endpointTIA-Portal-CLI 是一个把西门子 TIA Portal 离线项目操作封装成命令行动词的开源工具它让 Claude Code、Codex、Cursor 这类编程智能体可以通过 shell 调用tia verb --json来读写 PLC 块、标签、硬件组态、PROFINET、WinCC HMI 等对象。它本身不内置大模型而是把 TIA Portal 端转换成智能体最擅长的形态调用 CLI、读取结构化 JSON、决定下一步。换句话说AI 编程工具负责推理TIA-Portal-CLI 负责执行边界。但真正落地时会遇到一个很现实的问题CLI 里配置的模型 endpoint 默认指向哪里如果你同时用 Claude Code 写上位机、用 Codex 写脚本、又用某个智能体操作 PLC 项目每个工具各自维护一套 Key 和 Base URL切换成本高额度也分散。把 endpoint 统一改到 TaoToken 的 API 通道就能用一套 Key 覆盖多个智能体日志和用量也集中在一处看。这篇面向的是已经在用或准备用 TIA-Portal-CLI 做 PLC AI 编程的工程师重点不是讲它有多少个动词而是把 endpoint 配置、连通性验证、401 排查这三件事讲透。适合谁手上有 TIA Portal V19–V21 离线项目、想在隔离测试项目里先跑通 AI 辅助编程、又不想把项目数据发到不可控通道的人。下面所有操作都在本地 Windows 会话里完成不涉及在线 PLC 写入。2. TaoToken 前置准备与 CLI 环境对齐在改 endpoint 之前先把两边的环境对齐否则后面报错很难判断是 CLI 的问题还是通道的问题。TaoToken 这边你需要准备三样东西Base URL、API Key、以及你要调用的 Model ID。Base URL 用https://taotoken.net/api注意这个地址不带任何查询参数直接作为 OpenAI 兼容风格的基础路径使用。API Key 在控制台的 API Keys 页面创建建议按用途分 Key比如给 TIA-Portal-CLI 单独建一个方便后面按 Key 排查 401。Model ID 取决于你实际要用的模型在模型对话页面能看到当前可用的模型标识把它原样填进配置即可。TIA-Portal-CLI 这边确认你已经能在本地跑通只读命令。先在装有 TIA Portal 的隔离机器上执行初始化检查这一步不碰项目、不写任何东西.\init.ps1 -Check -Json返回 JSON 里会告诉你 Openness 程序集是否注册、TIA Portal 版本是否在支持范围、当前会话是否有权限。如果这一步就失败先别急着改 endpoint那是环境问题。确认doctor、tree、snapshot这类只读动词能正常返回 JSON 之后再进入配置环节。这里有个容易忽略的点TIA-Portal-CLI 的模型调用和 TIA Portal 的 Openness 调用是两条独立的链路。Openness 走本地 COM/程序集模型走 HTTP。改 endpoint 只影响后者不会改变前者。所以你在排查时要把「CLI 能不能操作项目」和「CLI 能不能调通模型」分开看混在一起会绕远路。另外提醒一句TIA-Portal-CLI 明确不包含在线 PLC 操作、下载到设备、Multiuser 签入这些能力。它的设计边界就是离线项目加预运行加显式--apply。你换 endpoint 不会突破这个边界也不应该试图突破。把模型通道统一到 TaoToken只是让推理侧更可控执行侧的边界仍然由 CLI 自己守着。3. 可复制的 endpoint 配置片段这一节是全文最需要照抄的部分。不同智能体的配置文件路径和字段名不一样我按常见的三类给出可直接粘贴的片段。核心三件套永远是Base URL、API Key、Model ID。先说 Claude Code 这类走 Anthropic 风格配置的场景。它的 settings 文件通常放在用户目录下的.claude/settings.json把模型通道指向 TaoToken 的兼容入口{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: 你的ModelID } }如果你用的是 Codex 风格、读取auth.json的智能体配置写在~/.codex/auth.json字段名不同但语义一致{ OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-你的TaoTokenKey, OPENAI_MODEL: 你的ModelID }Cline 或类似走 MCP/扩展配置的工具通常在 settings 里有一段 provider 配置写成 TOML 或 JSON 都行关键是 base_url 和 model 对齐[provider] base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model 你的ModelID如果你在 TIA-Portal-CLI 自己的配置里指定模型通道找到它的配置文件通常在仓库根目录或用户配置目录README 会写明把 endpoint 字段改成同样的 Base URL。注意不要在这里加任何路径后缀/api就是完整的基础路径多写/v1之类反而可能 404。配置完成后建议用一条最小请求验证通道本身不经过 CLI直接打 HTTPcurl.exe https://taotoken.net/api/v1/models -H Authorization: Bearer sk-你的TaoTokenKey返回模型列表就说明 Key 和 Base URL 是对的。这一步能把「通道问题」和「CLI 问题」彻底分开。我试过在没做这步的情况下直接跑 CLI结果 401 排查了半小时最后发现是 Key 复制时带了空格。4. 连通性验证与成功结果判读配置写完之后验证要分三层做每层都有明确的成功标志不要跳步。第一层是纯 HTTP 连通性就是上一节的curl请求。成功返回是一个 JSON 数组里面每个元素有id字段那就是可用模型。如果返回 401说明 Key 有问题返回 404说明 Base URL 路径写错了返回超时说明网络层不通。这一层不涉及 TIA Portal纯粹验证 TaoToken 通道。第二层是 CLI 的模型调用。用一个只读动词触发一次模型推理比如让 CLI 对当前项目做一次 tree 概览并让模型给出解读tia tree --json | tia ask --json 总结这个项目的块结构具体动词名以你所用版本为准重点是观察返回的 JSON 里有没有模型输出字段。成功时你会看到结构化的choices或等价字段内容是对项目结构的自然语言描述。如果这里报reading choices相关的解析错误通常是返回体不是预期的 OpenAI 兼容格式检查 Base URL 是否被某个中间层改写。第三层是端到端。在隔离的一次性项目里跑一次预运行确认模型建议和 CLI 执行边界都正常tia verb --json注意这里故意不加--apply默认就是预运行返回的是「计划更改的内容」。成功标志是返回 JSON 里有明确的变更描述但项目文件没有被修改。你可以用snapshot前后对比确认。只有当你人工审阅过预运行结果、确认变更范围可接受才在测试项目里加--apply。三层都通过之后再跑一次相同命令观察是否变成无操作no-op以及审计日志是否可追踪。这个「重复执行变无操作」的特性是声明式协调的体现也是判断配置是否稳定的好方法。如果第二次执行仍然报告有变更说明有状态没被正确识别需要回头看配置或项目状态。5. 常见报错排查401、local proxy failed、reading choices这一节按真实报错来每个都给出定位路径。401 Unauthorized 是最常见的。先确认 Key 没有多余空格或换行用curl单独验证 Key 本身。如果curl通过但 CLI 报 401说明 CLI 读的配置文件不是你改的那个检查它实际加载的路径很多工具支持多级配置覆盖用户级、项目级、环境变量优先级不同。还有一种情况是 Key 被禁用或额度耗尽去控制台确认 Key 状态。local proxy failed通常出现在智能体试图通过本地代理转发请求时。这个报错和 TaoToken 无关是你本机代理配置的问题。检查环境变量里有没有残留的HTTP_PROXY、HTTPS_PROXY把它们清掉再试。TIA-Portal-CLI 在本地会话里运行不需要经过任何额外转发层直连https://taotoken.net/api即可。reading choices或类似的响应解析错误说明返回体结构不符合预期。常见原因是 Base URL 多写了路径比如写成了https://taotoken.net/api/v1而客户端又自己拼了一次/v1导致请求打到了不存在的路径返回的是错误页而不是模型响应。把 Base URL 严格写成https://taotoken.net/api让客户端自己处理版本路径。OAuth 相关报错一般出现在用 Anthropic 风格认证的工具上。如果你用的是 API Key 模式确认配置里没有同时存在 OAuth token 字段两者冲突时客户端可能优先走 OAuth 流程。把 OAuth 相关字段清掉只保留 API Key。排查顺序建议固定为先curl验证通道再确认 CLI 实际加载的配置文件最后看返回体结构。这三步能覆盖九成以上的报错。每次只改一个变量改完立刻验证不要一次改多处否则无法归因。6. 把通道固定下来然后回到工程本身配置跑通之后建议把 endpoint 配置纳入版本管理但 Key 不要明文提交。可以用环境变量注入配置文件里只留占位符。这样团队里每个人用自己的 Key通道地址统一排查问题时能快速区分是个人 Key 问题还是通道问题。长期做 PLC AI 编程的话可以考虑用 Coding Plan 把额度集中管理多个智能体共享一套通道用量和日志都在一处。模型对话页面适合临时验证某个模型对梯形图逻辑的理解能力接入文档则在你需要换工具或加新智能体时提供字段对照。最后回到 TIA-Portal-CLI 本身。换 endpoint 只是让推理侧更顺手它真正的价值在于那套执行边界默认预运行、显式--apply、不碰在线 PLC、本地部署。这些边界不会因为你换了模型通道而改变也不应该被绕过。在隔离测试项目里把预运行、人工审阅、应用、编译、审计这条链路走顺再谈用 AI 提效顺序不能反。编译成功不等于控制逻辑正确联锁、异常恢复、时序这些还是得靠人验证。把通道配好把边界守住剩下的才是工程判断。
