在调用 OpenAI 兼容接口时，reasoning_effort 是一个关键参数，目前已得到 Ollama 0.21 及以上版本的支持，可选的赋值包括 "none"、"low"、"medium"、"high"。

要彻底关闭模型的“思考模式”，只需在 payload 中显式设置 "reasoning_effort": "none"。一个完整的请求体示例如下：

{
    "reasoning_effort": "none",
    "top_p": 0.8,
    "min_p": 0.1,
    "frequency_penalty": 1,
    "stream": false,
    "max_tokens": 4096,
    "top_k": 20,
    "temperature": 0.7,
    "messages": [
        {
            "role": "user",
            "content": "…"
        },
        {
            "role": "system",
            "content": "你是一个有5年多临床经验的中级医师…"
        }
    ],
    "model": "qwen3.6:35b"
}

在 Postman 中进行实际验证时，可以看到服务端正确接受了这一参数，且不再返回多余的思考过程。

在此之前，曾尝试使用 "enable_thinking": false 来控制思考模式，但该选项并未生效。改用 reasoning_effort 后，行为才符合预期。

当思考模式未被正确关闭时，接口返回内容中会夹杂大量无用的推理片段，不仅影响可读性，还会显著拖慢响应速度，如下图所示：

需要注意的是，不同的 OpenAI 兼容实现在处理思考模式时行为仍可能存在差异，因此在项目集成前，建议通过自动化测试对接口能力进行系统性验证。可以借助 Claude Code 等工具，快速构建覆盖多场景的 API 测试流程。

此前测试中还发现了一些值得关注的问题，供排查时参考：

七十九个文件，记录着 OpenBrep 在摸索中走过的弯路。

01 七十九个文件，有多少真正在做工

OpenBrep 最初基于 Streamlit 构建。每一次按钮交互、编译触发、预览刷新，都挂载在 ui/app.py 这一个文件上。项目幼年时，Streamlit 足够直接、够快。然而随着功能增多，ui/ 目录膨胀至 79 个文件：视图、状态、预览、聊天、工程文件解析、知识加载……诸多逻辑杂糅在一起，难以测试，更难复用。从 v0.8 起，React 工作台被设为默认入口，Streamlit 沦为了遗留物。保留它，意味着每次启动都要加载这一大包，每次修改配置都得考虑它，每次 lint 都要刻意绕过。

清理审计开始了。79 个文件中，有 3 个值得特别注意：它们没有 Streamlit 依赖，却被工作台服务层悄悄引用——view_models.py 负责将 LLM 输出拆分到对应的 GDL 脚本路径；three_preview.py 把三维网格转换为 Three.js 可用的 JSON 载荷；local_file_dialog.py 调用 macOS 的 osascript 弹出文件选择对话框。这三个承载了领域逻辑，本就不该活在 UI 层。剩下的 76 个文件，在执行 git rm 时只用了不到五秒。

02 把三个文件挪到该去的地方

迁移远非简单的复制粘贴。classify_code_blocks() 被安置进 openbrep/workbench/view_models.py，随后逐一找到引用它的服务文件，将旧的 import 路径更新。preview_3d_to_three_payload() 则落进 openbrep/workbench/three_preview.py。local_file_dialog 被移至项目根目录下的 openbrep/，因为它作为运行时工具，不属于 workbench 层。每修改一处 import，就跑一轮测试。126 个测试用例，最终全部通过。这本身就说明了关键：只要领域逻辑与 UI 层彻底分离，迁移只是地址变更，不是重写。

pyproject.toml 的细节：删除 ui/ 后，hatch 构建时抛出 FileNotFoundError，原来 force-include 中仍残留着 “ui” = “ui”。构建系统比你更记得你删掉了什么。Streamlit 相关的依赖——streamlit、streamlit-ace、plotly——也从 dev 和 ui 组中同步移除。

OpenModel 平台推出了 DeepSeek V4 Flash 的限时免费活动，输入输出费用全部归零。更重要的一点，平台已经完整接入了 OpenAI、Anthropic 与 Gemini 三套 API 协议，只需修改一行 base_url，就能将现有工具直接切换过来，注册新用户还能顺手领取 1 美元体验金。

$0 V4-Flash 活动价
40+ 模型同享折扣
$1 新用户注册赠送

2026年6月，OpenModel 发布限时活动：DeepSeek V4 Flash 全面免费，无论输入还是输出均不收费。这并不是 DeepSeek 官方直连的计费模式，而是由 OpenModel 作为第三方网关提供的补贴价格。同时，平台将目录内其余 40 余款模型调整到 2 至 8 折，新注册用户再额外赠送 1 美元额度，等于先赠送一整套 GPT 级别能力，让你试用过后再决定是否继续付费。

认识 OpenModel：聚合多家大模型接口的网关

OpenModel 是一个模型路由网关，它把 OpenAI、Anthropic、DeepSeek、Google 等厂商的接口聚合到同一套 API 格式之下。你只需一行 base_url 就能切换模型，不必再去各个平台单独注册、单独创建密钥。这次活动直接将 DeepSeek 最新的 V4-Flash（支持 1M 上下文、MoE 架构）列为免费档，对于想低成本跑 Agent、批量测试 prompt 或搭建个人原型的开发者而言，这是当前成本最低的上手入口。

步骤一：注册账号并获取 API Key

访问 openmodel.ai 完成注册，新用户会立即获赠 1 美元 API 额度。活动期间 DeepSeek V4-Flash 本身为零成本，这 1 美元可用来试玩其他打折模型。在控制台页面创建 API Key 后，同样保存到密码管理器或 .env 文件，切勿硬编码在代码里。

最近，QClaw 应用内新增了语音输入功能，给日常使用带来了更多便利。该功能同时支持通过按钮和快捷键两种方式触发，操作起来直观又顺手。

在输入框的旁边，你可以看到一个话筒形状的图标。只需点击这个图标，就能立刻开始语音输入，整个过程流畅无打断。

需要特别说明的是，这项能力仅限于 QClaw 应用内部使用，它并不会像输入法那样对系统或其他应用产生干扰。换句话说，它并非一个全系统的语音输入方案，而是纯粹在应用层面提供的辅助输入手段。

实际使用下来的感受

经过亲身试用，最直观的体会是：QClaw 的语音识别与豆包之间还存在一些明显的差异。它会根据你说话时的停顿，非常忠实地添加大量的顿号、逗号，导致输出的文本显得磕磕绊绊，给人一种讲话结巴的错觉。很多时候，你不得不回过头来手动调整，把这些多余的标点一一删除，才能让句子顺畅。

相比之下，豆包输入法则更侧重于对整句的通顺度进行优化。它会主动处理停顿，让句子读起来更自然、更连贯，从而大大减少了后期修正的麻烦。这种体验上的落差，也是当前 QClaw 语音功能最需要追赶的地方。

一个没有视觉感知的纯文本模型，在网页设计评测中碾压了所有具备“视觉”能力的竞品。这听起来不可思议，却真实发生了。

01

一个开源模型，冲上了设计评测榜首

6 月 19 日，评估平台 Design Arena 放出了最新报告。GLM 5.2 在单轮网页设计（非智能体模式）排行榜上位列第一，将 Claude Fable 5、Opus 4.6、Opus 4.7 等明星模型尽数甩开。Fable 5 此前长期霸占 Design Arena 胜率头名，数月未遇敌手。GLM 5.2 是第一个终结这一格局的模型。

GLM 5.2 由 Z.ai 推出，参数量 7440 亿，采用 MIT 开源协议。最令人意外的是它根本没有视觉能力——却要在“看”的细分领域里击败各路“视觉”高手。更惊人的是价格：每百万 token 输入仅 $1.40、输出 $4.40，仅为 Fable 5 的八分之一（Fable 5 为 $10/$50）。

Design Arena 评测报告指出：“它是 MIT 协议开源模型。尤为难得的是，Z.ai 用与 GLM-5.1 完全相同的 7440 亿参数规模，在不具备视觉能力的条件下实现了这一成绩，而其最接近的竞争对手，参数规模据推测足有 6.7 倍之多。”

02

它写出的网页，天然更讨喜

Design Arena 团队对大量案例逐项分析后，归纳出 GLM 5.2 三个关键行为特征。

第一，它掌握了一套优雅的模板体系。 团队将 GLM 5.2 与 Fable 5 各自生成的 1000 个网页截图进行聚类，发现 GLM 5.2 存在明显的模板化倾向——不同提示词下输出结构高度一致。但这套模板的设计质量远超其他模型的惯用套路：没有早期 AI 生成那种紫色渐变、过度装饰的拙劣风格，代之以用户更青睐的成熟布局。

当团队拿到一个全新的大语言模型时，开发者的第一反应往往是：“这模型响应有点慢啊。”究竟慢不慢，测一下就知道了。

基础接口测试方法

查看可用模型列表

curl -s "https://localhost/v1/models" \
  -H "Authorization: Bearer <API_KEY>" | python3 -m json.tool

基础对话连通性测试（max_tokens=10）

curl -s "https://localhost/v1/chat/completions" \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "GLM-5.1",
    "messages": [{"role": "user", "content": "Say hello"}],
    "max_tokens": 10
  }' | python3 -m json.tool

max_tokens 合法上限测试（32768）

curl -s "https://localhost/v1/chat/completions" \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "GLM-5.1",
    "messages": [{"role": "user", "content": "Say hello"}],
    "max_tokens": 32768
  }' | python3 -m json.tool

max_tokens 超限测试（262144，预期报错）

当选择第三方模型接入 Claude Code 或 Codex 这类编程工具时，如果不进行严格的预先测试，很可能会直接遇到连接失败、工具无法识别模型的情况。

原因在于这些编程工具对模型的 API 接口格式有非常明确的硬性要求，目前主要涉及以下几类 API 规范：

以 Codex 的支持情况为例，早期格式采用 Chat Completions，后期则演变为 Responses。上图展示的后两种格式都属于 OpenAI 的 API 风格。

OpenAI 目前有两种主流的文本生成 API 端点：

• /chat/completions
• /responses

/chat/completions 与 /responses 的核心区别，在于定位不同。/responses 是 /chat/completions 的全面演进版，专门为构建 Agent 类应用而设计，提供了更丰富的状态管理与工具调用支持。

Responses API 在 2025 年 3 月伴随着 GPT‑4.1 的发布正式推出。Chat Completions 接口仍然得到官方维护，OpenAI 建议新项目直接使用 Responses，老项目可以逐步迁移，但这种迁移并非强制，也没有设定截止日期。

当前 Codex v0.141.0 只承认 /responses 格式，这就导致那些仅提供 /chat/completions 格式的第三方模型完全无法被 Codex 接入。

在配置 Codex 的 API 时，必须指向一个兼容 /responses 格式的端点。

通过在 CC switch 中接入火山引擎的模型，我们可以实际测试 Codex 是否能正常运转。

方舟CodingPlan的GLM系列模型现已从GLM-5.1升级至GLM-5.2版本，全新模型原生支持Hermes Agent、Claude Code、OpenCode、OpenClaw等主流编程工具与Agent的直接调用。与此同时，GLM-5.1模型将于6月22日正式下线，请用户及时完成切换。

我们刚刚收到平台下发的升级通知，具体内容如图：

登录后台控制台，可以清晰看到模型列表已更新，GLM-5.1标注为即将下线状态，GLM-5.2已可供选择。

完成升级仅需在模型选项中一键切换即可。

在项目的配置文件中，需要将模型ID指定为 glm-5.2。同时，平台也开放了一系列其他模型ID以方便选配：

glm-5.2
minimax-m2.7
kimi-k2.6
deepseek-v4-pro
deepseek-v4-flash
minimax-m3

为适配不同开发习惯，平台提供了两套兼容协议的接入地址：

• 兼容Anthropic接口协议的工具地址：https://ark.cn-beijing.volces.com/api/coding
• 兼容OpenAI接口协议的工具地址：https://ark.cn-beijing.volces.com/api/coding/v3

通过上述地址即可在主流编程Agent中无缝调用GLM-5.2模型。

开启火山引擎的 Coding Plan Lite 套餐后，若全天使用 GLM‑5.1 模型进行编程，大约半天的连续任务便会消耗掉总配额的 5%。实测中同时启动了双 Agent 并行工作，并通过 --dangerously-skip-permissions 参数减少交互弹窗，以便让自动化流程更顺畅。

在此模式下完成了两个项目：一个是可保存扫描结果的 Web 版扫描器，另一个是仿 Nginx Stream 的 HTTP 负载均衡器，能够自动检测连接状态并进行故障切换。

查询用量的入口位于火山引擎控制台：

https://console.volcengine.com/ark/region:ark+cn-beijing/openManagement?LLM=%7B%7D&advancedActiveKey=subscribe

切换模型时，首先在控制台选择 GLM‑5.1，随后在环境变量中修改对应的模型名称。当前支持的模型列表如下：

glm-5.1
ark-code-latest
doubao-seed-2.0-code
doubao-seed-2.0-pro
doubao-seed-2.0-lite
doubao-seed-code
minimax-m2.7
minimax-m3
deepseek-v4-flash
deepseek-v4-pro
kimi-k2.6

GLM‑5.1 的价格较高，建议仅在处理复杂任务时调用；日常编码可以优先使用 ark-code-latest，该模型配额充足，性价比更高。根据连续多日的使用统计，Lite 版在仅运行 GLM‑5.1 的情况下，每天大约 4 小时的使用量能够支撑约 20 天；如果同时开启多个 Agent，消耗速度会明显加快，实际使用天数会更短。

目前 Lite 版有 9.9 元的优惠活动，通过单独注册账号即可购买。Pro 版的可用量是 Lite 版的 5 倍，多人团队更推荐选择 Pro 套餐，按需尝试一个月观察效果。

对于大多数用户而言，腾讯旗下的 QClaw、WorkBuddy、Marvis 等产品提供的免费额度已足够应对日常开发；只有在使用 Claude Code 或 Codex 等重度 AI 编程工具时，才真正需要考虑 Coding Plan 的付费方案。

免费的堡垒机也能用，为什么要花钱买？

六年前，单位曾采购过一台启明品牌的低端堡垒机，但功能不全、操作体验也差，硬件一出问题就直接停用了。从那以后我们一直使用开源堡垒机，主要依赖它的免费功能。

免费功能在日常工作中其实够用，但随着等保相关的安全设备陆续老化损坏，不可能全换成开源方案。WAF 用的雷池，堡垒机则继续选择 JumpServer。过去的安全设备大多是软硬一体机，硬件坏了就得整套更换。

这次我们采购了 JumpServer 软件版堡垒机，采用双机部署架构，一主一备。数据库和缓存组件也都独立部署。而开源版本是把所有容器集中在一台机器上，属于单机模式；付费后可以平滑升级为双机或物理机集群部署。

堡垒机与钉钉做了对接，工程师不用再记忆密码，直接扫码就能登录。

更进一步，工程师也不用记服务器的密码，堡垒机负责统一管理服务器密码。通过设定密码策略，每三个月就能自动更换一次密码。

最高境界，就是大家都彻底忘记密码，全部实现免密登录。

堡垒机还对接了 NAS 存储，用于保存操作录像。这样一来存储容量几乎无限，可以长时间保留录像。

搭建堡垒机的核心目的是实现权限回收：不允许工程师直接访问服务器，而是由防火墙设置访问策略，只放行堡垒机的 IP。只有做到这一步，堡垒机的价值才能真正体现。如果工程师能够直接访问服务器，很多操作就说不清楚，也就没有操作记录可查。

录像功能和自动改密功能是堡垒机的核心。开源版本的录像功能是免费的，而自动改密功能属于收费特性。

其他高级功能我们还在逐步尝试，比如 URL 管理、数据库管理以及网页密码代填等。

https://jumpserver.org/features.html

JumpServer 硬件一体机的模式是花费 30 万买断，此外还有按年的订阅模式以及人工服务可选。

JumpServer 安装手册：

https://docs.jumpserver.org/zh/v4/installation/setup_linux_standalone/offline_install/

全文完。