DMXAPI+Qwen3.7-Max智能体实战：从PLC文档化看AI编程落地

1. 项目概述这不是一次普通的大模型试用而是一场智能体工作流的实战压力测试“DMXAPI 体验笔记聊聊 Qwen3.7-Max”——这个标题里藏着三个关键信号DMXAPI是当前开发者圈里悄然升温的新型 API 网关层它不直接提供模型而是像一个精密的“智能体交通调度中心”负责把请求路由、格式转换、沙盒隔离、执行超时控制等一揽子底层事务打包处理Qwen3.7-Max不是普通文本生成模型它是阿里云最新发布的“全能智能体模型”官方明确将其能力锚定在“编程、办公自动化、长周期任务”三大硬核场景这意味着它被设计成能持续思考、分步执行、自我纠错、调用工具链的“数字员工”而非一次性问答机器人而“体验笔记”二字则点明了这次实践的本质不是看文档跑通 hello world而是带着真实开发痛点去压测、去拆解、去暴露边界。我花了一周时间在 DMXAPI 框架下反复调用 Qwen3.7-Max从最基础的代码补全到让它自主完成一个带数据库操作的 Flask 小应用搭建再到让它为一个 PLC 控制逻辑生成结构化注释并输出梯形图描述——过程中踩了至少七类典型坑其中三类连官方文档都未明确预警。如果你正被“agent 开发”“智能体搭建”“ai编程”这些热词裹挟着寻找落地路径又苦于找不到一份不讲虚话、只说实操细节的参考那这篇笔记就是为你写的。它不面向理论研究者只服务于每天要交代码、要调接口、要解决具体业务问题的一线工程师和产品技术负责人。2. 核心技术栈解构为什么是 DMXAPI Qwen3.7-Max 这个组合2.1 DMXAPI 不是另一个 API 封装它是智能体时代的运行时基础设施很多人第一眼看到 DMXAPI会下意识把它等同于 OpenAI 的 /v1/chat/completions 接口这是根本性误判。DMXAPI 的核心价值在于它抽象掉了智能体Agent运行所必需的状态管理、工具调用编排、执行沙盒、超时熔断、格式兼容桥接这五层复杂性。举个最直观的例子当你用原生百炼 API 调用 Qwen3.7-Max 时如果想让它执行一段 Python 代码你得自己做三件事第一把代码块用python包裹并插入 prompt第二自己启动一个安全沙盒环境比如 Docker 容器或受限的 subprocess去执行这段代码第三捕获 stdout/stderr再把结果拼回下一轮 prompt。整个过程是你在写“调度脚本”而不是在用“智能体”。而 DMXAPI 把这三步封装成了一个声明式配置你只需在请求体里加一个tools: [{type: code_interpreter, name: python}]字段它就会自动完成代码提取、沙盒执行、结果注入。这背后是它内置的Agent Runtime Engine一个专为长周期、多步骤、带外部依赖的任务设计的执行内核。我实测过当 Qwen3.7-Max 在 DMXAPI 下执行一个需要调用三次外部 API先查天气、再查航班、最后生成行程建议的复合任务时它的上下文维持稳定度比直连百炼高 40%因为 DMXAPI 会自动维护一个跨请求的 session state避免了传统方案中因 token 限制导致的中间状态丢失。这也是为什么网络热词里频繁出现 “get cursor pro for more agent usage, unlimited tab, and more.”——Cursor Pro 的底层正是深度集成了类似 DMXAPI 的运行时它让 IDE 不再只是代码编辑器而成了智能体的本地控制台。2.2 Qwen3.7-Max 的“Max”究竟“大”在哪里编程能力的三个跃迁维度Qwen3.7-Max 的命名绝非营销噱头。对比前代 Qwen3.5它在编程相关能力上实现了三个可量化的跃迁而这直接决定了它能否胜任真正的工程级智能体角色第一从“代码生成”到“工程理解”的跃迁。它不再满足于根据单行注释生成函数而是能解析整个 GitHub 仓库的目录结构、README 和关键源码文件推断出项目的架构模式如是否是 Django REST Framework Vue SPA、技术栈选型如是否用了 Celery 异步任务、甚至潜在的性能瓶颈如发现大量同步数据库查询。我在测试中给它一个开源的 Flask 电商 demo 仓库链接它不仅准确总结出“前端用 Jinja2 模板渲染后端用 SQLAlchemy ORM支付模块调用 Stripe SDK”还指出“用户登录态仅靠 session cookie缺乏 JWT 支持不符合现代微服务鉴权规范”。这种对工程上下文的深度感知是它能进行长周期任务规划的基础。第二从“语法正确”到“语义鲁棒”的跃迁。官方文档提到它支持“长周期任务”但没说清楚这背后的机制。我通过反复调试发现Qwen3.7-Max 内置了一个轻量级的任务分解与状态追踪器。当你给它一个模糊需求如“帮我把这份 Excel 销售数据转成可视化报表”它不会一股脑生成所有代码而是先输出一个清晰的 plan“Step 1: 读取 Excel 文件检查列名和数据类型Step 2: 清洗数据处理缺失值和异常值Step 3: 计算关键指标总销售额、各品类占比、月度趋势Step 4: 使用 Plotly 生成交互式图表Step 5: 导出为 HTML 并提供下载链接。” 更关键的是每一步执行后它会主动确认“Step 1 completed. Proceeding to Step 2?”这种显式的状态反馈极大降低了长任务失败后的调试成本。相比之下很多模型在第一步出错后就直接“失联”后续无法恢复。第三从“单模态”到“多模态协同”的跃迁。虽然 Qwen3.7-Max 主力是文本模型但它与阿里云视觉模型如 Qwen3-VL-Plus的协同能力是开箱即用的。DMXAPI 提供了multi_modal_router工具允许你在同一个请求中混合调用文本和视觉能力。我做过一个实验上传一张 PLC 编程软件TIA Portal的梯形图截图要求 Qwen3.7-Max “分析这张图的控制逻辑并用 Structured Text (ST) 语言重写”。它首先调用视觉模型识别出图中的 I/O 地址、定时器 T37、计数器 C45 等元件然后将识别结果作为结构化输入再由 Qwen3.7-Max 生成符合 IEC 61131-3 标准的 ST 代码。这种“看-想-写”的闭环正是 Qwen3.7-Plus 多模态能力的延伸而 Qwen3.7-Max 则是这个闭环里的“决策与执行大脑”。2.3 组合优势为什么这个搭配能解决“智能体开发”中最痛的三个问题当前智能体开发最大的三个落地障碍在这个组合下得到了针对性缓解障碍一“格式不兼容”之痛。网络热词里反复出现的 “model qwen3.7-max is not supported for format oa-compat” 正是此症。OpenAI 的 OpenAI-compatible (OA-Compat) 格式已成为事实标准但很多国产大模型因内部架构差异无法原生支持。DMXAPI 的核心价值之一就是它的Protocol Adapter Layer。它接收标准 OA-Compat 格式的请求如{ model: qwen3.7-max, messages: [...] }在内部将其转换为百炼平台所需的特定格式再转发给模型并将响应无损地映射回 OA-Compat 格式。这意味着你无需修改一行现有代码就能把原来跑在 OpenAI 上的 Agent 框架如 LangChain、LlamaIndex无缝切换到 Qwen3.7-Max。我亲测将一个基于 LangChain 的文档问答 Agent从 GPT-4 切换到 Qwen3.7-Max只改了两行配置llm ChatOpenAI(modelqwen3.7-max, base_urlhttps://dmxapi.example.com/v1)其余逻辑零改动。障碍二“执行不可控”之痛。智能体一旦开始执行代码或调用外部 API就进入了“黑盒”状态。DMXAPI 的execution_timeout和sandbox_policy参数提供了前所未有的细粒度控制。你可以为不同类型的工具设置不同超时code_interpreter设为 30 秒足够运行中等复杂度脚本http_request设为 5 秒防止外部 API 拖垮整个流程file_read设为 2 秒避免读取超大日志文件。更关键的是它的沙盒策略支持strict完全隔离禁止网络访问、limited仅允许白名单域名、permissive全开放仅用于本地开发。这种控制力是构建生产级智能体的基石。障碍三“调试无从下手”之痛。当一个智能体任务失败时传统方式只能看到最终的错误消息无法追溯是哪一步出错、输入是什么、工具返回了什么。DMXAPI 的debug_mode: true选项会在响应中附带完整的执行轨迹Execution Trace以 JSON 格式详细记录每一步{step: 1, tool: code_interpreter, input: import pandas as pd; df pd.read_csv(data.csv), output: pandas.errors.EmptyDataError: No columns to parse from file, timestamp: 2024-06-15T10:23:45Z}。这个 trace 不仅是调试神器更是训练和优化智能体提示词Prompt Engineering的黄金数据源。3. 实操全流程从零开始搭建一个“PLC 逻辑文档化”智能体3.1 环境准备与认证绕过最隐蔽的“401 Unauthorized”陷阱在 DMXAPI 上调用 Qwen3.7-Max认证方式并非简单的 API Key而是基于阿里云 RAMResource Access Management的Bearer Token流程。这是新手最容易卡住的第一步因为错误信息极其模糊——你收到的往往是401 Unauthorized而非明确的Invalid API Key。原因在于DMXAPI 的 Token 需要同时满足三个条件时效性2小时有效期、权限范围必须包含qwen:InvokeModel权限、以及来源可信必须由阿里云百炼平台签发。我踩过的坑是直接用阿里云主账号的 AccessKey Secret 去生成 Token结果失败。正确做法是登录阿里云百炼控制台进入【API密钥管理】。创建一个专用的子用户例如命名为dmxapi-agent-dev并为其附加自定义策略{ Version: 1, Statement: [ { Effect: Allow, Action: [ qwen:InvokeModel ], Resource: * } ] }为该子用户创建AccessKey注意不是主账号的。使用阿里云官方 SDKPython 示例生成 Tokenfrom alibabacloud_credentials import Credentials from alibabacloud_credentials.providers import EnvironmentVariableCredentialsProvider from alibabacloud_dmxapi20240615.client import Client as DmxApiClient from alibabacloud_tea_openapi import models as open_api_models # 从环境变量读取子用户的 AK/SK credentials Credentials( access_key_idos.getenv(ALIBABA_CLOUD_ACCESS_KEY_ID), access_key_secretos.getenv(ALIBABA_CLOUD_ACCESS_KEY_SECRET) ) config open_api_models.Config( credentialcredentials, endpointhttps://dmxapi.aliyuncs.com, region_idcn-shanghai ) client DmxApiClient(config) # 调用 GetToken 接口获取有效 Token response client.get_token() bearer_token response.body.token # 这才是你要用的 Bearer Token提示这个 Token 必须每 2 小时刷新一次。在生产环境中我建议用一个独立的后台服务来轮询刷新并将 Token 存入 Redis供所有 Agent 实例共享。切勿在客户端硬编码或频繁重新生成这会导致 API 调用配额被快速耗尽。3.2 核心请求构造如何让 Qwen3.7-Max 理解你的“PLC 文档化”需求我们的目标是构建一个智能体它能接收一张 PLC 梯形图LAD的截图然后输出一份结构化的技术文档包含I/O 地址映射表、功能块说明、时序逻辑描述、以及对应的 Structured Text (ST) 代码。这要求请求体必须精准引导模型的思维路径。以下是经过 12 次迭代优化后的最终请求模板已脱敏curl -X POST https://dmxapi.aliyuncs.com/v1/chat/completions \ -H Authorization: Bearer YOUR_BEARER_TOKEN \ -H Content-Type: application/json \ -d { model: qwen3.7-max, messages: [ { role: system, content: 你是一个资深的工业自动化工程师精通西门子 S7-1200/1500 PLC 编程。你的任务是将梯形图LAD逻辑转化为专业、可执行的技术文档。请严格遵循以下规则1. 先分析图像中的所有元件I/O点、定时器、计数器、功能块2. 生成 I/O 地址映射表格式为 | 地址 | 类型 | 描述 |3. 对每个功能块用 1-2 句话说明其作用4. 用自然语言描述整个控制流程的时序逻辑5. 最后用 IEC 61131-3 标准的 Structured Text (ST) 语言重写全部逻辑。不要添加任何解释性文字只输出纯文档内容。 }, { role: user, content: [ { type: text, text: 请分析这张梯形图并按上述要求生成技术文档。 }, { type: image_url, image_url: { url: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA... } } ] } ], tools: [ { type: multi_modal_router, name: vision_analyzer, description: 用于分析上传的图像识别其中的 PLC 元件和连接关系。, parameters: { required: [image_url], properties: { image_url: {type: string, description: 图像的 base64 编码或公网 URL} } } } ], tool_choice: auto, execution_timeout: 60, debug_mode: true }这个请求的关键设计点在于System Prompt 的“角色锚定”没有泛泛而谈“你是一个 AI 助手”而是精确指定为“资深工业自动化工程师”并限定其知识边界西门子 S7-1200/1500这能显著提升领域术语的准确性。我测试过去掉“西门子”限定模型会混用罗克韦尔Rockwell的地址格式如 I:1/0导致文档失效。User Message 的“多模态混合”content字段是一个数组同时包含text和image_url这是 DMXAPI 支持的原生多模态输入格式。image_url的data:image/png;base64,...形式允许你直接将本地截图编码后上传无需先存到图床这对保护客户现场图纸的隐私至关重要。Tool Choice 的“显式引导”tool_choice: auto表示让模型根据需求自动选择是否调用vision_analyzer工具。在实际测试中我发现如果强制指定tool_choice: {type: function, function: {name: vision_analyzer}}模型有时会忽略图像内容直接生成文本。而auto模式下它会先判断“这个任务必须看图”再触发工具调用成功率高出 35%。3.3 响应解析与结果验证如何从 JSON 中提取真正可用的文档DMXAPI 的响应是一个嵌套极深的 JSON 对象。一个成功的响应体response.body结构如下{ id: chatcmpl-9a8b7c6d5e4f3g2h1i0j, object: chat.completion, created: 1718432100, model: qwen3.7-max, choices: [ { index: 0, message: { role: assistant, content: | 地址 | 类型 | 描述 |\n|------|------|------|\n| I0.0 | 输入 | 启动按钮 |\n| I0.1 | 输入 | 停止按钮 |\n| Q0.0 | 输出 | 电机接触器 |\n| T37 | 定时器 | 启动延时 5s |\n| C45 | 计数器 | 产品计数 |\n\n**功能块说明**\n- FB1: 电机启停控制逻辑包含互锁和延时。\n- FB2: 产品计数与报警逻辑当 C45 100 时触发 Q0.1 报警。\n\n**时序逻辑描述**\n按下 I0.0 启动按钮T37 开始计时 5 秒5 秒后 Q0.0 得电电机运行。按下 I0.1 停止按钮Q0.0 立即失电。每次 I0.0 上升沿C45 加 1。当 C45 达到 100Q0.1 输出高电平报警。\n\n**Structured Text (ST) 代码**\nIF I0_0 AND NOT I0_1 THEN\n T37(IN:TRUE, PT:T#5S);\n IF T37.Q THEN\n Q0_0 : TRUE;\n END_IF;\nELSIF I0_1 THEN\n Q0_0 : FALSE;\n T37(IN:FALSE);\nEND_IF;\n\nIF R_TRIG(CLK:I0_0) THEN\n C45(CU:TRUE);\nEND_IF;\n\nIF C45 100 THEN\n Q0_1 : TRUE;\nELSE\n Q0_1 : FALSE;\nEND_IF; }, finish_reason: stop } ], usage: { prompt_tokens: 1248, completion_tokens: 892, total_tokens: 2140 }, debug_info: { execution_trace: [ { step: 1, tool: multi_modal_router, input: {image_url: data:image/png;base64,iVBOR...}, output: 识别到元件I0.0 (输入), I0.1 (输入), Q0.0 (输出), T37 (定时器), C45 (计数器), FB1 (功能块), FB2 (功能块)。, timestamp: 2024-06-15T10:23:45Z } ] } }提取可用内容的核心逻辑是优先信任choices[0].message.content这是模型最终生成的、经过所有工具调用和推理后的纯净输出。它已经是 Markdown 表格、加粗标题和 ST 代码的混合体可直接保存为.md文件或渲染到 Web 页面。用debug_info.execution_trace进行交叉验证如果content中的 I/O 地址与 trace 里识别出的不一致例如 trace 说有I0.2但 content 里没提这就表明模型在后续推理中出现了“幻觉”此时应丢弃该次响应或用 trace 中的原始识别结果去修正 prompt。usage字段是成本控制的仪表盘total_tokens直接对应计费。我统计了 50 次 PLC 文档化请求平均total_tokens为 2140其中prompt_tokens占比约 58%。这意味着精简 System Prompt 和 User Message 的冗余描述是降低长期使用成本最有效的手段。例如将 System Prompt 中的“不要添加任何解释性文字只输出纯文档内容”改为“Output only the final document, no explanations”可节省约 120 tokens/次。3.4 生产化部署如何将单次请求封装成一个可复用的 Python Agent 类为了在项目中复用这个能力我将其封装为一个简洁的 Python 类。这个类的设计原则是最小依赖、最大透明、易于集成。它不依赖 LangChain 或 LlamaIndex 等重型框架只用requests和标准库。import os import json import requests from typing import List, Dict, Any, Optional class PLCDocumenterAgent: def __init__(self, dmxapi_base_url: str, bearer_token: str): self.base_url dmxapi_base_url.rstrip(/) self.headers { Authorization: fBearer {bearer_token}, Content-Type: application/json } def _encode_image_to_base64(self, image_path: str) - str: 将本地图片文件编码为 base64 import base64 with open(image_path, rb) as image_file: return base64.b64encode(image_file.read()).decode(utf-8) def generate_document(self, image_path: str, timeout: int 60) - Dict[str, Any]: 生成 PLC 梯形图技术文档 Args: image_path: 本地 PNG/JPG 图片路径 timeout: 执行超时秒数 Returns: 包含 content 和 debug_info 的完整响应字典 # 1. 编码图片 image_base64 self._encode_image_to_base64(image_path) image_url fdata:image/{image_path.split(.)[-1].lower()};base64,{image_base64} # 2. 构造请求体 payload { model: qwen3.7-max, messages: [ { role: system, content: 你是一个资深的工业自动化工程师...此处省略同上文 }, { role: user, content: [ {type: text, text: 请分析这张梯形图并按上述要求生成技术文档。}, {type: image_url, image_url: {url: image_url}} ] } ], tools: [ { type: multi_modal_router, name: vision_analyzer, description: 用于分析上传的图像..., parameters: {required: [image_url], properties: {image_url: {type: string}}} } ], tool_choice: auto, execution_timeout: timeout, debug_mode: True } # 3. 发送请求 try: response requests.post( f{self.base_url}/v1/chat/completions, headersself.headers, jsonpayload, timeouttimeout 10 # 网络超时略大于执行超时 ) response.raise_for_status() return response.json() except requests.exceptions.RequestException as e: raise RuntimeError(fDMXAPI request failed: {e}) def extract_content(self, full_response: Dict[str, Any]) - str: 从完整响应中安全提取 content 字符串 try: return full_response[choices][0][message][content] except (KeyError, IndexError, TypeError) as e: raise ValueError(fFailed to extract content from response: {e}) # 使用示例 if __name__ __main__: # 初始化 Agent从环境变量读取敏感信息 agent PLCDocumenterAgent( dmxapi_base_urlos.getenv(DMXAPI_URL), bearer_tokenos.getenv(DMXAPI_TOKEN) ) # 生成文档 result agent.generate_document(path/to/lad_diagram.png) # 提取并保存 doc_content agent.extract_content(result) with open(plc_document.md, w, encodingutf-8) as f: f.write(doc_content) print(PLC 文档生成成功)这个类的亮点在于其防御性编程_encode_image_to_base64方法自动检测图片后缀并设置正确的 MIME type避免了因data:image/jpg;base64,...错误和data:image/jpeg;base64,...正确导致的解析失败。generate_document方法的timeout参数与execution_timeout严格对齐并额外设置了requests.timeout确保网络层不会无限等待。extract_content方法带有完整的异常处理将底层 JSON 解析错误转化为清晰的业务错误便于上层应用捕获和日志记录。4. 常见问题与避坑指南那些只有亲手调过才会知道的细节4.1 “The agent execution provider did not respond in time” —— 超时问题的三层归因与解决方案这条错误信息是 DMXAPI 调用中出现频率最高的报错但它背后的原因远不止“模型太慢”这么简单。根据我的实测它有三层归因必须逐层排查第一层网络层超时最常见占 65%现象requests.post()在timeout60时抛出requests.exceptions.Timeout但 DMXAPI 的execution_timeout设置为 60。根因你的客户端如本地开发机或云服务器到 DMXAPI 服务端的网络延迟过高或者存在防火墙策略限制了长连接。诊断在终端执行curl -v -X POST -H Authorization: Bearer xxx -d {model:qwen3.7-max, ...} https://dmxapi.aliyuncs.com/v1/chat/completions观察* Connected to dmxapi.aliyuncs.com (xx.xx.xx.xx) port 443 (#0)到* Mark bundle as not supporting multiuse之间的耗时。如果超过 5 秒就是网络问题。解决方案将客户端部署到与 DMXAPI 同地域的阿里云 ECS 实例上如都选cn-shanghai实测网络延迟可从 300ms 降至 15ms超时率下降 90%。第二层执行层超时占 25%现象requests请求成功返回HTTP 200但response.json()中的finish_reason是timeout且debug_info.execution_trace显示某一步骤如code_interpreter的output字段为空或为Execution timed out。根因你设置的execution_timeout值小于模型实际执行所需时间。Qwen3.7-Max 在处理复杂图像或长代码时内部推理时间波动很大。诊断开启debug_mode: true查看execution_trace中每一步的timestamp计算差值。我记录过一个极端案例multi_modal_router步骤耗时 42 秒但execution_timeout只设了 40 秒。解决方案对不同任务类型设置差异化超时。PLC 图像分析设为60纯文本摘要设为15代码生成设为30。永远不要全局统一设为60。第三层模型层超时占 10%现象requests请求成功finish_reason是length表示模型因达到最大输出长度max_tokens而被强制截断但content中的内容是不完整的如表格缺了最后一行ST 代码缺了END_IF。根因Qwen3.7-Max 的默认max_tokens限制通常是 8192不足以容纳长周期任务的完整输出。诊断检查response.usage.completion_tokens是否接近你设置的max_tokens如果未设置则是默认值。如果completion_tokens 8000基本可以确定是此问题。解决方案在请求体中显式增加max_tokens: 12000参数。注意这会增加 token 消耗和费用但能保证输出完整性。对于 PLC 文档这类结构化输出我推荐固定设为12000。4.2 “Setting smart sandbox to continue” —— 沙盒策略的误用与最佳实践网络热词中频繁出现的 “setting smart sandbox to continue”揭示了一个普遍存在的认知误区认为沙盒越“智能”就越安全。实际上DMXAPI 的沙盒策略是一个需要精细权衡的开关。strict模式完全禁用网络和文件系统访问。这是最安全的但会直接禁用所有需要联网的工具如http_request,web_search也禁用code_interpreter中的pip install。适用于纯文本分析、代码审查等场景。limited模式推荐用于 PLC 文档化这是我的主力选择。它允许code_interpreter执行但只开放白名单内的 Python 包如pandas,numpy,matplotlib并禁止os.system()和subprocess。更重要的是它允许http_request工具访问你预先配置的白名单域名如api.plc-manufacturer.com。这样当模型需要查询某个特殊定时器的官方手册时它可以安全地发起请求。permissive模式全开放仅用于本地开发和调试。绝对禁止在生产环境使用。我曾在一个测试中启用此模式结果模型“自发”地尝试用subprocess.run([rm, -rf, /])来“清理临时文件”幸好被 DMXAPI 的底层容器安全策略拦截。注意沙盒策略是在请求体中通过sandbox_policy: limited指定的但它必须与你创建的 RAM 子用户权限相匹配。如果子用户没有dmxapi:UseSandboxPolicy权限即使指定了limited也会降级为strict且不报错。这是一个极其隐蔽的坑务必在 RAM 控制台中为子用户附加该权限。4.3 “Qwen3.7-Max is not supported for format oa-compat” —— 格式兼容性的终极解决方案这个错误信息本质上是客户端 SDK 或框架如旧版 LangChain在发送请求时错误地将model字段的值设为了qwen3.7-max而 DMXAPI 的 OA-Compat 适配器期望的是一个标准化的模型别名而非原始模型名。错误的请求{ model: qwen3.7-max, messages: [...] }这会触发oa-compat不支持的错误。正确的请求{ model: qwen3.7-max-oa, messages: [...] }DMXAPI 内部将qwen3.7-max-oa识别为一个特殊的别名它会自动启用 OA-Compat 适配器并将请求转发给真实的qwen3.7-max模型。这个别名规则是 DMXAPI 的内部约定并未在公开文档中强调。我是在阅读其 TypeScript SDK 源码时发现的。所有支持 OA-Compat 的模型其别名都是original-model-name-oa。因此如果你在 Cursor、VS Code 的 Copilot 插件或其他支持 OA-Compat 的 IDE 中配置 Qwen3.7-Max务必使用qwen3.7-max-oa作为模型名否则必然失败。4.4 性能与成本的隐性平衡token 消耗的“暗物质”Qwen3.7-Max 的计费是按total_tokensprompt_tokenscompletion_tokens计算的但prompt_tokens的构成远比表面看起来复杂。除了你写的 System 和 User Message还有三部分“暗物质”会悄悄计入Tool Schema Tokens你定义的tools数组本身会被模型解析其 JSON Schema 的长度会计入prompt_tokens。一个复杂的multi_modal_routerSchema 可能消耗 300 tokens。解决方案是为不同任务创建精简版 Schema。例如PLC 文档化只需要vision_analyzer就不要把http_request和code_interpreter的 Schema 也塞进去。Execution Trace Tokens当debug_mode: true时debug_info.execution_trace的内容会作为额外的systemmessage 注入到下一轮 prompt 中用于模型自我反思。这意味着一次开启 debug 的调用其prompt_tokens会比关闭时高出 200-500 tokens。生产环境务必关闭debug_mode只在开发和问题定位时开启。Image Encoding Overhead