想玩一些联机恐游，但是价格普遍都到八九十了，有点贵…学习版似乎又没办法联机，有办法通过特殊手段进行联机吗？有风险吗？ 3 个帖子 - 3 位参与者 阅读完整话题
开通账号的plus后，我在cpa上通过oauth登陆，cpa这边认证成功了，为什么这里还是现实free，额度是空呢。 3 个帖子 - 3 位参与者 阅读完整话题
各位佬，上个月填调查申请的gpt5的权限和额度现在还没通过，是再不开门，没法用了吗 2 个帖子 - 2 位参与者 阅读完整话题
使用hermes agent 通过MCP的方法将二者连接。 原理大概是这样 Notion ↔ [Notion 官方 MCP] ↔ Hermes Agent ↔ [FNS MCP / SSE] ↔ Obsidian ↑ ↑ hermes与FNS自部署在 VPS 都使用了什么 1.hermes agent 无需多言，类似于小龙虾openclaw这种 2.notion mcp 官方的，使用OA认证挂载后 Agent 能读 / 写 / 创建 / 搜索 Notion 页面 为什么不用 api的形式？ 因为闲鱼上卖的都是那种商业试用版，hermes 本身内置了 Notion API 适配，但因为访客账号无法在 workspace 里创建 internal integration、拿不到 integration token，所以只能走官方 MCP 的 OAuth 路径。 3. Fast Note Sync (FNS)：Obsidian 插件，把本地 Vault 同步到服务器，同时暂开 SSE 协议的 MCP 服务，Agent 走这个接口读写 Vault，这个插件是L站一位佬友制作的，十分的好用。 为什么要这样做 主要还是看重他notion的AI功能。现在的notion的ai可以去闲鱼，一个月才5块钱，可以基本上无限使用opus4.7这种模型，而且对笔记的优化相当好，这个是obsidian比不了的，但是notion这个始终是云端，而且我觉得分类做的不太好，慢慢就会变成垃圾场那种。 我看过不少人同时用notion和obsidian一起用，但每次都得手动整理，**手动搬的本质是「哪天懒了，整个系统就废了」**现在已经出现了这种例如小龙虾与hermes，利用一下。 使用hermes连接笔记软件有一个好处，你根本不用打开笔记软件，与hermes聊天，聊到一个东西，直接和他说记录到笔记中，他就会帮你整理记录。或者说你在notion中记录，在obsidian中，他都可以帮你找出来，而不用打开软件去操作。 我的notion与obsidian设置 noiton 🗂️ Hermes 知识流转中心 ├─ 📥 待归档 ← 我把要归档的东西什在这里 ├─ ✅ 已归档 ← Hermes 搬完后自动移过来 ├─ 📋 Hermes 操作日志 ← Hermes 每次干活都写一行 └─ 📖 Hermes 使用说明 ← 写给 Hermes 看的手册（关键！） obsidian Vault/ ├─ 00-Inbox/ ← Hermes 搬来的全进这里 ├─ 10-信息/ ├─ 20-配置/ └─ 30-数学/ ← 这些是我手动分类的永久位置 三条铁律 绝不做双向同步，单向： Notion → Obsidian 。搬到 Obsidian 后相当于快照，想改就在 Obsidian 里新写一份，不改已归档的。 Agent 不碰正文，ermes 只做三件事： 读取 · 搬运，加一下标签或者双链。 操作日志必须有。 踩过的坑 1.假如你是在像我一样在VPS中部署的hermes，notion的mcp OA跳转主要注意 VPS 是 headless 环境，Notion MCP 的 OAuth 回调地址默认是 http://127.0.0.1 : ，本地浏览器访问不到服务器的 loopback。解决办法是用 SSH 本地端口转发，然后在本地浏览器点授权链接，回调会落到本地端口再转回服务器完成认证。 2.hermes暂不支持SSE的mcp配置，需要补充上为 Hermes 补上 SSE MCP 支持。 1 个帖子 - 1 位参与者 阅读完整话题
排查了好久，很烦，每次测试ssh tunnel都是通的，一连接就报错 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 文枢（Docentra）基于 React + Vite + Electron + Zustand 构建，提供本地优先的桌面表格体验，并集成 AI 助手、Excel 导入导出、公式计算、筛选排序、查找替换等能力。 简单来说，就是可自定义api的excel表格编辑器，不支持工具调用的api也可以通过本软件的“工具注入”功能让模型可进行使用，目前已支持openai、anthropic、ollama接口 项目地址： GitHub - Kiowx/docentra: 文枢，一个智能多功能一体化工作台，可通过ai对话进行修改表格，同时提供可视化表格界面 · GitHub 下载地址： Releases · Kiowx/docentra · GitHub 3 个帖子 - 2 位参与者 阅读完整话题
这个话题我想我之前已经提过,目的大体就是通过做题强制要求阅读一些”规则”,例如老生常谈的 “帖子被删质问管理” “不活跃论坛账号是否被清理” 最近新发生的 “凑字数”,“抽奖贴无关的发言” “AICG内容未截图” “AFF链接” 社区不为任何富可敌国的服务质量提供保障 此举只是认为,论坛中应该有相当一部分佬也许没有仔细阅读过规则,认为依据自己(新佬)的“常识”(此处的常识非贬义)而言,自己触犯不到论坛的违规,但事实是L站的部分规则与新佬的“常识”相悖,例如“被举报不是找管理而是发帖询问” 因此只是简单提议提议能否添加一个答题机制,可参考“类脑”内的答题Bot,这点我相信依据L站内的Bot应该可以做到(应该有一个bot是教你怎么进行基础操作后给你一个徽章的),Bot的意义并非升高门槛,只是让佬们能够实实在在的阅读规则以避免犯错 规则拍上去,做选择题这样子的,全对再放入Lv1/Lv2这样子的 10 个帖子 - 10 位参与者 阅读完整话题
我发邀请之后朋友申请通过了，4.11发来的邮件，结果在垃圾箱里 她今天上邮箱看了一下点击链接说失效了，或者说账户可能已经激活，但是登录不上，这种情况是只能重新申请了嘛 6 个帖子 - 3 位参与者 阅读完整话题
昨天，在群里小伙伴的提醒下，我了解到通过反代 Codex 也可以进行图片的生成和编辑了。随即我进行了一番实验，使用 GPT-Image-1.5 成功生成了如下图片： 技术原理：工具调用（Tool Calling） 与 Gemini 使用专用图片模型（如 NanoBanana 系列）的逻辑不同，在 Codex 中，生图功能是通过 调用工具 实现的，并不依赖特定的模型名称。 基于这一特性，我们可以利用 CLIProxyAPI 的 模型别名 配合 Payload 重写 功能，自定义一套专属的“文生图模型”。下面我分享一下自己的配置思路和使用方法，希望能起到抛砖引玉的作用。 PS：下文前提是已经安装配置好 CLIProxyAPI 并添加了 Codex 的 OAuth 凭证。 1. 配置文件修改 在 CLIProxyAPI 的配置文件中添加以下内容。这里我们将 gpt-5.4-mini 映射为不同分辨率的生图模型，并通过 Payload 强制开启 image_generation 工具。 oauth-model-alias: codex: - name: gpt-5.4-mini alias: gpt-image-1024x1024 fork: true - name: gpt-5.4-mini alias: gpt-image-1024x1536 fork: true - name: gpt-5.4-mini alias: gpt-image-1536x1024 fork: true payload: override-raw: - models: - name: gpt-image-1024x1024 protocol: codex params: tools: '[{"type":"image_generation", "size": "1024x1024", "quality": "high", "background": "auto"}]' tool_choice: '{"type": "image_generation"}' - models: - name: gpt-image-1024x1536 protocol: codex params: tools: '[{"type":"image_generation", "size": "1024x1536", "quality": "high", "background": "auto"}]' tool_choice: '{"type": "image_generation"}' - models: - name: gpt-image-1536x1024 protocol: codex params: tools: '[{"type":"image_generation", "size": "1536x1024", "quality": "high", "background": "auto"}]' tool_choice: '{"type": "image_generation"}' 添加完成后，我们就可以直接调用 gpt-image-1024x1024 、 gpt-image-1024x1536 和 gpt-image-1536x1024 这三个自定义模型了。 2. 快速调用脚本 (PowerShell) 由于目前我还未找到好用的生图客户端，我编写了一个简单的 Windows PowerShell 脚本供大家参考。 使用方法： 修改脚本前四行的 apiUrl 、 apiKey 等参数。 将完整脚本粘贴至 PowerShell 窗口运行。 等待约数十秒，即可在当前运行路径下看到生成的图片。 $apiUrl = "https://你的CLIProxyAPI地址/v1/responses" $apiKey = "你的CLIProxyAPI的apikey" $model = "gpt-image-1536x1024" $text = "画一张赛博朋克的香港，要有汉字" $bodyObject = @{ model = $model instructions = "You are a helpful assistant." input = @( @{ type = "message" role = "user" content = @( @{ type = "input_text" text = $text } ) } ) parallel_tool_calls = $true reasoning = @{ effort = "high" summary = "auto" } stream = $true store = $false include = @( "reasoning.encrypted_content" ) } $body = $bodyObject | ConvertTo-Json -Depth 100 -Compress $outBase = "generated" $utf8NoBom = New-Object System.Text.UTF8Encoding($false) $tempBodyFile = Join-Path $env:TEMP ("response-body-" + [guid]::NewGuid().ToString("N") + ".json") [System.IO.File]::WriteAllText($tempBodyFile, $body, $utf8NoBom) try { curl.exe --silent --show-error --no-buffer ` -X POST $apiUrl ` -H "Content-Type: application/json" ` -H "Authorization: Bearer $apiKey" ` --data-binary ("@" + $tempBodyFile) | ForEach-Object -Begin { $eventType = $null $dataLines = [System.Collections.Generic.List[string]]::new() function Save-Bytes { param([string]$Path, [string]$Base64) [System.IO.File]::WriteAllBytes($Path, [Convert]::FromBase64String($Base64)) Write-Host "Saved $Path" } function Save-ImageGenerationCallResult { param([object]$ImageCall) if (-not $ImageCall) { return } if ($ImageCall.type -ne "image_generation_call") { return } if (-not $ImageCall.result) { return } $ext = if ($ImageCall.output_format) { [string]$ImageCall.output_format } else { "png" } $path = Join-Path (Get-Location) "$outBase.$ext" Save-Bytes -Path $path -Base64 ([string]$ImageCall.result) } function ConvertFrom-JsonCompat { param([string]$Json) if ($PSVersionTable.PSVersion.Major -ge 6) { return $Json | ConvertFrom-Json -Depth 100 } return $Json | ConvertFrom-Json } function Flush-SseEvent { param([string]$Type, [System.Collections.Generic.List[string]]$DataLines) if (-not $Type -or $DataLines.Count -eq 0) { return } $json = ($DataLines -join "`n").Trim() if (-not $json -or $json -eq "[DONE]") { return } try { $obj = ConvertFrom-JsonCompat -Json $json } catch { return } switch ($Type) { "response.output_item.done" { Save-ImageGenerationCallResult -ImageCall $obj.item } "response.completed" { $imageCall = @( $obj.response.output | Where-Object { $_.type -eq "image_generation_call" -and $_.result } ) | Select-Object -First 1 Save-ImageGenerationCallResult -ImageCall $imageCall } } } } -Process { $line = [string]$_ if ($line.StartsWith("event:")) { if ($eventType -or $dataLines.Count -gt 0) { Flush-SseEvent -Type $eventType -DataLines $dataLines $dataLines = [System.Collections.Generic.List[string]]::new() } $eventType = $line.Substring(6).Trim() return } if ($line.StartsWith("data:")) { $dataLines.Add($line.Substring(5).TrimStart()) return } if ([string]::IsNullOrWhiteSpace($line)) { Flush-SseEvent -Type $eventType -DataLines $dataLines $eventType = $null $dataLines = [System.Collections.Generic.List[string]]::new() } } -End { Flush-SseEvent -Type $eventType -DataLines $dataLines } } finally { if (Test-Path -LiteralPath $tempBodyFile) { Remove-Item -LiteralPath $tempBodyFile -Force } } 相关资源 如需了解更详细的参数调整可以参考 OpenAI 官方文档 5 个帖子 - 4 位参与者 阅读完整话题
佬们，最近想通过 google pay 渠道走 claude 订阅。但是在 google play store 找不到 claude 应用，我已经切换到美区了，为什么会这样呢？（google 账号也是美区的） 2 个帖子 - 2 位参与者 阅读完整话题
RT，你的邮箱未被管理员启用，无法重置密码 是个单词，但和本站没啥强关联。 13 个帖子 - 9 位参与者 阅读完整话题
newapi通过codex（openai oauth）添加渠道，然后选择5.3-codex，但是不能用，只能选择5.4才能用，这是为啥？ 2 个帖子 - 1 位参与者 阅读完整话题
来l站50天整了（算上刚通过的那天应该是51天！）终于也是满足升级条件了！ （不知道为什么总感觉三级之后才算正式加入l站大家庭hhh 这么多天真的学到了很多东西，希望l站越来越好，学AI上L站！ 23 个帖子 - 15 位参与者 阅读完整话题
Claude Design 入口在 http://claude.ai/design ，使用现有订阅额度，超出部分可以开启额外用量。企业版默认关闭，需要管理员手动开启。 anthropic.com Introducing Claude Design by Anthropic Labs Today, we’re launching Claude Design, a new Anthropic Labs product that lets you collaborate with Claude to create polished visual work like designs, prototypes, slides, one-pagers, and more. 2 个帖子 - 2 位参与者 阅读完整话题
网页版 App Store 之前可以通过修改网址中的 /cn/ 为其它地区代码，如 /us/ 达到浏览美区商店内容，现在大陆 IP 尝试访问外区商店会被 302 重定向回国区的 Today 页面。 2 个帖子 - 2 位参与者 阅读完整话题
Firefox Nightly 版加入了对 Web Serial API 的支持，而六年前 Mozilla 以不安全为由反对支持该 API。Web Serial API 允许浏览器与通过串行端口通信的设备交互，此类设备包括 3D 打印机，微控制器如 Arduino 和 ESP32，智能家居面板如 ESPHome，以及通过 USB 或蓝牙模拟串行端口的设备通信。Google Chrome 自 2021 年起加入了对 Web Serial API 的支持，基于 Chromium 的浏览器如 Edge、Opera 和 Vivaldi 也都支持该 API。Mozilla 杰出工程师 Martin Thomso 在 2020 年表示，对于如此强大的功能，无法为用户提供充分的保护，即使用户同意。串行端口是物理连接赋予高度信任的时代的遗物，许多设备允许通过该接口连接的设备在没有任何身份验证的情况下获得管理权限，这一权限甚至超过了 root。两年后 Mozilla 被要求重新考虑其立场，Firefox CTO Bobby Holley 表示 Mozilla 愿意采用和 WebMIDI 相同的附加组件守门机制（add-on-gating mechanism）支持 WebSerial API。Mozilla 目前仍然反对 WebUSB 和 WebHID，而苹果 WebKit 团队仍然对 WebSerial、WebUSB 和 WebHID 持反对态度。
笔者一直想通过手机控制电脑，从而将自己的工作空间解放，实现床上、地铁上、咖啡厅肆意办公，前段时间了解到happy coder，并在今天成功使用。但是遇到一个问题，在手机端的对话结束后会显示 并且对话被锁住无法继续。但是在电脑上实际使用该语句则会要求加上 --fork-session(报错如下 Error: --session-id can only be used with --continue or --resume if --fork-session is also specified.） 但是加上后，虽然会重新回到这个对话，但是是本地模式，手机端的happy会话还是无法连接。想问问各位佬友有没有解决办法，球球。 3 个帖子 - 2 位参与者 阅读完整话题
AnyRouter Claude Code 验证机制分析 本文档记录了通过逐步删减请求字段、实际发送请求测试，得出的 AnyRouter 对 Claude Code 请求的验证机制。 测试日期：2026-03-16 起，持续追加 测试方法：以完整的 Claude CLI 请求为基准，逐个移除字段并观察响应状态码（200 = 通过，500 = 拒绝） 重要提醒：验证机制具有时变性与灰度特征 AnyRouter 的验证逻辑经过多次反复调整， 任何结论都不应被视为长期稳定 ： 请求头校验可能被启用或取消（如 anthropic-beta 从"可选"变为"必需"） 白名单策略可能被启用或撤销（如 session_id 白名单上线又下线） user_id 格式曾整体变更（扁平字符串 → JSON 字符串） 同一时段内不同 Key 行为可能差异巨大（被封禁/限流的 Key 返回 520/503，正常 Key 返回 200） 不同模型的上游可用性独立变化（旧模型下线、新模型灰度上线） 部分校验存在 灰度/后端负载 相关的不稳定行为 使用建议 ： 代理实现应默认携带"完整最小必需集"（见后文），而非依赖某次测试得出的"可省略"结论 遇到非预期错误码时，优先换 Key / 换模型 / 换时间重试，再排查请求体 本文档中旧结论凡被推翻的，均以「已失效 / 已变更」标注并保留，用于回溯演变轨迹 一、验证结论总览 AnyRouter 的验证 只检查请求体 ，不检查请求头。核心验证点仅有两个： system 数组中必须包含精确的 Claude Code system prompt metadata.user_id 必须符合特定格式 2026-04 更新 ：以上结论为早期测试结果。当前 AnyRouter 同时校验请求头 ， 缺少必需的 anthropic-beta 头（尤其是 context-1m-2025-08-07 标志）会直接返回 400。 详见下方「请求头新增校验」章节。 最小可通过请求 = 标准 Anthropic 请求 + system[0].text = "You are Claude Code, Anthropic's official CLI for Claude." + metadata.user_id = "user_{64位hex}_account__session_{UUID格式}" 补充：请求头新增校验（2026-04-11 确认） 400 错误：“1m 上下文已经全量可用，请启用 1m 上下文后重试” 错误现象 ： {"error":"1m 上下文已经全量可用，请启用 1m 上下文后重试","type":"error"} 所有模型、所有 Key 均返回 HTTP 400，与请求体内容无关。 根本原因 ： anthropic-beta 请求头中缺少 context-1m-2025-08-07 标志。AnyRouter 现在会检查此 beta flag 来确认客户端已启用 1M 上下文窗口。 解决方案 ： 在请求头中添加 anthropic-beta ，至少包含 context-1m-2025-08-07 ： anthropic-beta: context-1m-2025-08-07 Claude Code CLI 2.1.92 实际发送的完整 anthropic-beta 值（共 9 个 flag）： claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advanced-tool-use-2025-11-20,effort-2025-11-24,fast-mode-2026-02-01 各 flag 含义： Flag 用途 claude-code-20250219 Claude Code 专属标识 context-1m-2025-08-07 启用 1M 上下文窗口（ AnyRouter 必须校验项 ） interleaved-thinking-2025-05-14 交错思考模式 redact-thinking-2026-02-12 思考内容脱敏 context-management-2025-06-27 上下文管理 prompt-caching-scope-2026-01-05 提示缓存作用域 advanced-tool-use-2025-11-20 高级工具使用 effort-2025-11-24 输出努力程度控制 fast-mode-2026-02-01 快速模式 经逐项省略测试确认， anthropic-beta 是 唯一 必需的非标准头，其余头（ User-Agent 、 x-app 、 X-Stainless-* 、 anthropic-version 等）均可省略。完整测试结果见下方第二章。 测试对比 ： anthropic-beta 中包含 context-1m-2025-08-07 状态码 否 400（上述错误） 是 200 或 503（验证通过） 二、请求头测试详情 注意 ：以下为 2026-03-16 的旧测试结果，当时 AnyRouter 不校验请求头。 2026-04-11 重新测试发现 anthropic-beta 已变为 必需 头，详见下方更新。 旧测试结果（2026-03-16，已过时） （点击了解更多详细信息） 请求头结论（2026-04-11 更新） AnyRouter 现在校验 anthropic-beta 请求头。 缺少此头或其中不含 context-1m-2025-08-07 会返回 400。 逐项省略测试方法：以完整请求头为基准，每次仅移除一个字段，发送请求并记录响应状态码（自动重试 520）。每个字段测试 2 次有效结果。 移除的请求头 结果 结论 Accept 200, 200 可省略 User-Agent 200, 200 可省略 X-Claude-Code-Session-Id 520, 200 可省略 X-Stainless-Arch 200, 200 可省略 X-Stainless-Lang 200, 200 可省略 X-Stainless-OS 200, 200 可省略 X-Stainless-Package-Version 200, 200 可省略 X-Stainless-Retry-Count 200, 200 可省略 X-Stainless-Runtime 200, 200 可省略 X-Stainless-Runtime-Version 200, 200 可省略 X-Stainless-Timeout 200, 200 可省略 anthropic-beta 400, 400 必需 anthropic-dangerous-direct-browser-access 200, 200 可省略 anthropic-version 200, 200 可省略 x-app 200, 200 可省略 最小请求头： Content-Type: application/json Authorization: Bearer sk-xxx anthropic-beta: context-1m-2025-08-07 以下请求头全部为冗余，可安全移除： accept anthropic-version anthropic-beta anthropic-dangerous-direct-browser-access user-agent x-app x-stainless-arch x-stainless-helper-method x-stainless-lang x-stainless-os x-stainless-package-version x-stainless-retry-count x-stainless-runtime x-stainless-runtime-version x-stainless-timeout accept-encoding 三、URL 参数测试 # 变更 状态码 结论 9 移除 ?beta=true 200 可移除 URL 结论 直接使用 /v1/messages 即可，无需 ?beta=true 查询参数。 四、请求体 — system 字段测试 # 变更 状态码 结论 13 完全移除 system 500 必需 12 只保留一个 system 块（Claude Code prompt） 500 失败（因同时无 metadata） 15 一个 system 块 + 有 metadata 200 一个块就够 14 两个 system 块，无 cache_control 200 cache_control 不需要 18 第一个 system 文本改为 "You are a helpful assistant." 500 文本必须精确匹配 25 第一个 system 文本去掉末尾句号 500 句号不可省略 19 第二个 system 块文本改为 "anything" 500 若有第二块，必须为 "null" system 字段结论 必须 包含至少一个 system 块 第一个块的 text 必须 精确匹配 以下字符串（一字不差，含末尾句号）： You are Claude Code, Anthropic's official CLI for Claude. 第二个 "null" 块 可省略 （一个块即可通过） 如果保留第二个块，其 text 必须为 "null" ，不能是其他值 cache_control 字段完全不需要 最小 system： "system": [ {"type": "text", "text": "You are Claude Code, Anthropic's official CLI for Claude."} ] 五、请求体 — metadata 字段测试 # 变更 状态码 结论 10 完全移除 metadata 500 必需 26 metadata 为空对象 {} 500 必须包含 user_id 17 user_id = "test" 500 格式不对 20 user_id = "user_abc123" 500 长度不够 22 user_id = "user_{64位hex}" （无 session 后缀） 500 缺少 session 部分 21 user_id = 完整格式，不同哈希值 200 值任意，只校验格式 23 user_id = 全零占位值 200 全零也能通过 metadata 字段结论 metadata 对象 必须存在 metadata.user_id 必须存在 且符合以下格式： user_{64位十六进制字符}_account__session_{UUID格式} 不校验具体值 ，只校验格式（正则匹配） 全零占位值完全可用： "metadata": { "user_id": "user_0000000000000000000000000000000000000000000000000000000000000000_account__session_00000000-0000-0000-0000-000000000000" } user_id 格式拆解 user_ ← 固定前缀 "user_" 82a10c807646e5141d2ffcbf5c6d439ee4cfd99d1903617b7b69e3a5c03b1dbf ← 64 位 hex（SHA-256 哈希） _account__session_ ← 固定中缀 "_account__session_" 74673a26-ea49-47f4-a8ed-27f9248f231f ← UUID v4 格式 (8-4-4-4-12) 推测的验证正则： ^user_[0-9a-f]{64}_account__session_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$ 六、请求体 — 其他字段测试 字段 测试结果 说明 messages 必需 Anthropic API 标准要求 max_tokens 必需 Anthropic API 标准要求 model 必需 Anthropic API 标准要求 messages 中的 "null" 文本块 可移除 简单字符串 content 即可 cache_control （system 和 messages 上的） 可移除 不参与验证 thinking 可选 只影响是否启用思考链 七、最终最小请求模板 curl https://anyrouter.top/v1/messages \ -H "Content-Type: application/json" \ -H "x-api-key: sk-xxx" \ -d '{ "model": "claude-opus-4-6", "messages": [ {"role": "user", "content": "Hello"} ], "system": [ {"type": "text", "text": "You are Claude Code, Anthropic'\''s official CLI for Claude."} ], "metadata": { "user_id": "user_0000000000000000000000000000000000000000000000000000000000000000_account__session_00000000-0000-0000-0000-000000000000" }, "max_tokens": 1024 }' 八、验证机制推测 根据测试结果，AnyRouter 的验证逻辑推测如下： 收到请求 │ ├─ 提取 x-api-key 或 Authorization → 标准认证 │ ├─ 解析 JSON body │ ├─ 检查 system[0].text │ ├─ == "You are Claude Code, Anthropic's official CLI for Claude." → 继续 │ └─ 不匹配或不存在 → 拒绝 (500) │ ├─ 检查 metadata.user_id 格式 │ ├─ 匹配 user_{64hex}_account__session_{UUID} → 继续 │ └─ 格式不对或不存在 → 拒绝 (500) │ ├─ (可选) 如有 system[1]，检查 text == "null" │ └─ 转发到上游 Anthropic API → 返回响应 2026-03-20 补充：固定 user_id 被封禁 使用写死的 user_82a10c... 值持续请求后，该 user_id 被 AnyRouter 封禁，所有携带该值的请求返回 403（空响应体）。换用全零 user_id 或随机生成的值即可恢复。 结论 ：AnyRouter 虽然不校验 user_id 的具体内容，但会 对高频使用的固定 user_id 做封禁处理 。代理应每次请求随机生成 user_id 。 2026-03-28 补充：metadata.user_id 格式变更 & session_id 校验 格式变更 metadata.user_id 的格式已从旧的扁平字符串格式变更为 JSON 字符串 格式： 旧格式（已失效，返回 503）： user_{64位hex}_account__session_{UUID} 新格式（当前生效）： "{\"device_id\":\"82a10c807646e5141d2ffcbf5c6d439ee4cfd99d1903617b7b69e3a5c03b1dbf\",\"account_uuid\":\"\",\"session_id\":\"f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c\"}" 字段说明： device_id ：64 位十六进制字符串（SHA-256 哈希） account_uuid ：可为空字符串 session_id ：UUID v4 格式，与请求头 X-Claude-Code-Session-Id 的值一致 session_id 校验测试 # X-Claude-Code-Session-Id 请求头 user_id 中的 session_id 状态码 结论 1 随机 UUID 51ef0c33-... 同一随机值 503 拒绝 2 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c 同一值 200 通过 结论 AnyRouter 校验 session_id 的具体值 （已于 2026-03-30 变更，见下方补充） 请求头 X-Claude-Code-Session-Id 与 metadata.user_id 中的 session_id 应保持一致 device_id 与 session_id 独立校验测试（2026-03-28） # device_id session_id 状态码 结论 1 随机值 合法固定值 f81a44fc-... 200 device_id 不参与校验 2 合法固定值 82a10c... 随机 UUID 503 session_id 必须合法 3 随机值 随机 UUID 503 同上 2026-03-30 补充：session_id 白名单校验已取消 2026-03-28 确认的 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c 白名单值一度失效（503）， 但 2026-03-30 测试发现 AnyRouter 已取消 session_id 白名单校验 ，随机 UUID 全部通过： # session_id 状态码 1 28ea2f67-e043-4107-ae5f-cec919bfaa0c （随机） 200 2 67408c8f-96ee-4a6c-91a1-b21683aceb3f （随机） 200 3 0b9ce4f8-f337-4178-901f-fd9dd818acf8 （随机） 200 4 ee785666-9dda-47cb-b49b-445da13cf2a9 （随机） 200 5 9444af14-00d2-45a7-a806-dd4cff63f741 （随机） 200 6 f81a44fc-edfb-40f5-bdd4-f6fd4afbc27c （旧值） 200 结论 ： device_id 和 session_id 均可每次请求随机生成 metadata.user_id 仍须为 JSON 字符串格式（含 device_id 、 account_uuid 、 session_id 三个字段） AnyRouter 的验证现在回归到 仅校验格式，不校验具体值 设计意图推测 AnyRouter 通过检查 Claude Code 特有的 system prompt 和 metadata 格式来识别"Claude Code 请求"， 据此可能提供差异化的路由策略、计费方式或配额管理。验证策略经历了多次变化： 早期：旧格式 user_{64hex}_account__session_{UUID} ，仅校验格式 2026-03-28：新 JSON 格式 user_id ，一度校验 session_id 白名单 2026-03-30：取消白名单，回归仅校验格式 2026-04-09：部分端点/时段出现 session_id 校验回归——随机 session_id 返回 503，使用已验证的固定 session_id 可返回 200。此行为不稳定，可能取决于后端负载或灰度策略。建议代理服务默认使用固定 session_id 以提高成功率。 九、503 请求体验证 — thinking block signature 校验（2026-04-15 确认） 问题背景 一份包含 54 条消息的长对话请求体始终返回 503，而一份仅 2 条消息的新对话请求体正常返回 200。通过系统性排查定位到根因。 根因结论 assistant 消息中 thinking block 的 signature 字段为空时，触发 503。 503 请求体的 msg[46]（assistant 角色）包含一个 thinking block，其 signature 值为空字符串（长度=0）。这是导致 503 的 唯一根因 。 该请求体中所有 thinking block 的 signature 状态： 消息 signature 长度 状态 msg[2] 476 有效 msg[10] 484 有效 msg[16] 5,152 有效 msg[18] 8,872 有效 msg[32] 892 有效 msg[36] 2,792 有效 msg[38] 1,668 有效 msg[40] 596 有效 msg[46] 0 空/缺失 所有有效 signature 的 thinking block 均未触发 503；唯一空 signature 的 msg[46] 是故障点。 验证证据 关键对照表 测试场景 结果 thinking + 空 signature（ "" ） 503 thinking + 假 signature（非空但格式无效） 503 thinking 无 signature 字段 503 无 thinking block 200 完整 54 条消息 + 删除空 signature 的 thinking block 200 消息数量扫描 对原始请求体逐步截取前 N 条消息发送，确认 503 在 msg[46]（即 N=46）处首次以 user 结尾仍返回 503： N=28~45: user 结尾 → 200, assistant 结尾 → 503（API 标准规则） N=46: assistant 结尾 → 503 N=47: assistant 结尾 → 503（含空 signature thinking） N=48: user 结尾 → ❌ 503（首次出现 user 结尾也 503） N=48~54: 全部 503（无论末尾角色） N=48 以 user 结尾却 503，因为 msg[46] 的空 signature thinking block 已包含在内。 修复验证 删除 msg[46] 中的 thinking block（或删除所有空 signature 的 thinking block）后，完整 54 条消息恢复 200： ✅ msg[0:54] 删除空 signature 的 thinking → HTTP 200 回复: 让我先看看之前是否已经有部分输出了。 已排除因素 以下因素经过系统性测试， 确认与 503 无关 ： 可疑因素 测试方法 结果 call_ 前缀的 tool_use ID 替换为 toolu_ 前缀 仍 503 缺失 caller 字段 补全 caller: {"type": "direct"} 仍 503 call_ 前缀 + caller 同时修复 替换前缀 + 补全字段 仍 503 WebSearch 工具（503 有 10 个 tools vs 正常 9 个） 正常请求体 + WebSearch tools 200 请求体大小 缩短 system[2] / tool_result / thinking 内容 仍 503 billing header 差异（cc_version / cch 不同） 互换 system[0] 无影响 is_error: true 的 tool_result 包含/排除均测试 无影响 根因溯源 msg[46]-[50] 同时具备两个来自 OpenAI 兼容后端的特征： call_ 前缀的 tool_use ID（OpenAI 格式，非 Claude 原生 toolu_ 前缀） thinking block 的 signature 为空（OpenAI 兼容代理无法生成 Claude 原生签名） 这表明这些消息来自 OpenAI 兼容代理后端 ，在格式转换过程中 thinking block 的 signature 被丢弃，导致后续请求被拒绝。 次要发现：messages 以 assistant 结尾触发 503 测试过程中发现，messages 数组 以 assistant 角色消息结尾时 也会触发 503。这是 Claude API 的标准规则（messages 末尾必须是 user 角色），但经代理后错误码从 400 变为 503。 末尾角色 状态码 说明 user 200 正常 assistant 503 API 标准规则，代理包装为 503 此为独立问题，与 thinking signature 无关。 修复方案 发送请求前，删除所有 signature 为空的 thinking blocks： for msg in body["messages"]: if msg["role"] == "assistant": content = msg.get("content", []) msg["content"] = [ b for b in content if not (b.get("type") == "thinking" and not b.get("signature")) ] 如果代理服务需要保留 thinking 内容用于上下文，可改为在转发前将空 signature 替换为占位值，但经测试非空但无效的 signature 同样触发 503，因此 删除是最稳妥的方案 。 十、模型下线与切换：claude-opus-4-7 上线（2026-04-17 确认） 变更概述 模型 状态 claude-opus-4-6 已下线 claude-opus-4-7 已上线 （新默认 Opus） 验证方式变化 无变化。 现有验证机制（ anthropic-beta 头、 system[0].text 、 metadata.user_id JSON 格式、 X-Claude-Code-Session-Id 等） 完全复用 ，仅需把 model 字段改为 claude-opus-4-7 。 实测对照表 使用当前最小请求模板（零修改）分别测试： 模型 非流式 流式 响应示例 claude-opus-4-6 400 400 {"error":"claude-opus-4-6 已下线，请切换到 claude-opus-4-7 模型"} claude-opus-4-7 200 200 正常响应 claude-sonnet-4-5 429 — {"error":"Service Unavailable"} （限流，非验证问题） opus-4-6 返回的是 业务层提示 （验证已通过、模型路由拒绝），而非验证失败，可作为"验证机制未变"的旁证。 结论 model 字段值： claude-opus-4-6 → claude-opus-4-7 其余请求头、请求体字段、URL 全部保持不变 十一、Key 级别的可用性校验（2026-04-17 确认） 现象 即使请求体、请求头完全相同，不同 Key 的响应可能差异巨大： Key 状态 非流式响应 流式响应 说明 正常 Key 200 200 完整 SSE 流 / JSON 响应 被封禁/额度耗尽 Key 520 （空响应） 503 {"error":"Service Unavailable"} Cloudflare 层包装 实测同一请求模板： Key A（耗尽）→ 非流式 5/5 次 520 空响应，流式返回 503 Service Unavailable Key B（正常）→ 非流式 3/3 次 200，流式 3/3 次 200 SSE 结论 AnyRouter 对 Key 本身有独立的可用性校验 ，与模型版本、请求格式无关 520 空响应 / 503 Service Unavailable 很可能是 Key 级别问题，而非验证失败或模型下线 排查 520 / 503 时应 优先换用另一个 Key 复测，再排查请求体 状态码含义更新 结合历史结论，当前完整状态码含义： 状态码 含义 排查方向 200 验证通过且响应成功 — 400 验证失败（缺 anthropic-beta / system 错 / user_id 格式错） 或 模型已下线 读取 body 中的 error 提示 403 user_id 固定值被封禁 改为随机生成 user_id 429 限流 降低频率或换 Key 500 （历史）验证失败；现在很少出现 — 503 验证通过但后端不可用 或 Key 不可用（流式模式） 换 Key / 检查 thinking signature 是否为空 520 Cloudflare 上游异常，通常是 Key 不可用（非流式模式） 换 Key 复测 十二、最新最小可用请求模板（2026-04-17） curl https://anyrouter.top/v1/messages \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-xxx" \ -H "anthropic-beta: claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advanced-tool-use-2025-11-20,effort-2025-11-24,fast-mode-2026-02-01" \ -H "anthropic-version: 2023-06-01" \ -H "User-Agent: claude-cli/2.1.92 (external, cli)" \ -H "X-Claude-Code-Session-Id: <UUID，与 user_id.session_id 一致>" \ -H "x-app: cli" \ -d '{ "model": "claude-opus-4-7", "max_tokens": 1024, "system": [ {"type": "text", "text": "You are Claude Code, Anthropic'\''s official CLI for Claude."} ], "messages": [ {"role": "user", "content": "Hello"} ], "metadata": { "user_id": "{\"device_id\":\"<64hex>\",\"account_uuid\":\"\",\"session_id\":\"<UUID>\"}" }, "thinking": {"type": "adaptive"}, "output_config": {"effort": "high"}, "speed": "fast" }' 相比文档第七章的"早期最小模板"（仅 Content-Type + x-api-key + 旧格式 user_id ），当前版本新增了多个必需项。早期模板 已失效 ，保留作为历史参考。 演变时间轴 日期 关键变化 2026-03-16 初版测试：仅校验请求体 system[0].text + metadata.user_id （旧扁平格式） 2026-03-20 固定 user_id 被封禁（403），需随机生成 2026-03-28 user_id 格式变更为 JSON 字符串；一度引入 session_id 白名单 2026-03-30 session_id 白名单取消，回归仅校验格式 2026-04-09 部分端点/时段 session_id 校验回归（灰度） 2026-04-11 anthropic-beta 头变为 必需 （必须含 context-1m-2025-08-07 ） 2026-04-15 thinking block 空 signature 触发 503 2026-04-17 claude-opus-4-6 下线， claude-opus-4-7 上线；Key 级可用性差异显著 2026-04-17 确认 thinking 字段是 opus-4-7 必需项 （new-api 后端空指针 panic）， output_config 、 speed 可省略 十三、opus-4-7 请求体字段必需性测试（2026-04-17 确认） 测试背景 代码中 thinking / output_config / speed 三个字段是否都必须携带？针对 claude-opus-4-7 模型，逐个移除测试。 测试方法 以完整请求体为基准，按 7 种组合移除字段，每种测 2 次，观察响应状态码。 测试结果 测试组合 2 次结果 结论 全部保留（基准） 200 / 520* 通过 仅移除 thinking 500 / 500 new-api panic 仅移除 output_config 200 / 520* 可省略 仅移除 speed 200 / 520* 可省略 移除 thinking + output_config 500 / 500 panic 移除 thinking + speed 500 / 500 panic 移除 output_config + speed 200 / 520* 可省略 三个全移除 500 / 500 panic *520 为 Cloudflare 上游偶发错误，与字段无关。 500 panic 错误响应 移除 thinking 后返回的错误： { "error": { "message": "Panic detected, error: runtime error: invalid memory address or nil pointer dereference. Please submit a issue here: https://github.com/Calcium-Ion/new-api", "type": "new_api_panic" } } 结论 字段 必需性 说明 thinking 必需 缺失触发 new-api 后端 panic（非验证失败，是后端代码 bug） output_config 可省略 AnyRouter 不校验 speed 可省略 AnyRouter 不校验 根因分析 ：AnyRouter 验证层本身 不校验 这三个字段，500 来自上游 new-api 的空指针 bug —— 后端代码假定 thinking 字段一定存在而未做 nil 判断。这是 AnyRouter 上游实现缺陷 而非协议要求。 thinking 字段取值语义 "thinking": {"type": "adaptive"} 类型 含义 {"type":"enabled","budget_tokens":N} 旧版：固定 token 预算 {"type":"adaptive"} 新版（推荐） ：模型自适应决定思考深度 {"type":"disabled"} 或缺失 不思考（但对 opus-4-7 会触发 panic） adaptive 让模型根据问题难度自动调节思考量——简单问题少想、复杂问题多想，配合 output_config.effort 的 high/medium/low 共同控制行为。 最小必需请求体（2026-04-17 更新） { "model": "claude-opus-4-7", "max_tokens": 1024, "system": [ {"type": "text", "text": "You are Claude Code, Anthropic's official CLI for Claude."} ], "messages": [{"role": "user", "content": "Hello"}], "metadata": { "user_id": "{\"device_id\":\"<64hex>\",\"account_uuid\":\"\",\"session_id\":\"<UUID>\"}" }, "thinking": {"type": "adaptive"} } 相比第十二章的模板，可安全移除 output_config 和 speed ；但 不可移除 thinking 。 14 个帖子 - 14 位参与者 阅读完整话题
Xiaomi miclaw 正式通过中国信息通信研究院手机端智能助手（Claw）评测，成为国内首个通过该评审的手机端智能体。本次评测依据《智能助手基准测试通用框架》，从基础能力、端侧应用、综合能力三大维度严格评测。据介绍，Xiaomi miclaw 依托 Xiaomi MiMo 自研大模型，具备全生态底层支撑、深度记忆、跨域互联、持续自进化四大能力，可打通手机、PC、座舱、AIoT 设备，自主完成复杂指令。 finance.sina.com.cn – 17 Apr 26 国内首批！小米官方龙虾Xiaomi miclaw通过中国信通院手机端智能助手评测 国内首批！小米官方龙虾Xiaomi miclaw通过中国信通院手机端智能助手评测 2 个帖子 - 2 位参与者 阅读完整话题
一。 准备编译环境 我的开发环境是Ubuntu24.04 a. 下载编译器 Arm Developer Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer Download the GNU Embedded Toolchain for ARM, an open-source suite of tools for C, C++, and Assembly programming for 32-bit ARM Cortex-A, ARM Cortex-M and Cortex-R families 如图： b. 添加环境变量 vi /etc/profile 在文件最后添加 export PATH=$PATH:/usr/lib/gcc/gcc-arm-none-eabi-4_9-2014q4/bin 使能环境变量 source /etc/profile 注意：此命令只在当前终端有效，若需要在其它终端中使用，需要重启计算机。 c. 获取FreeRTOS源码并编译 git clone https://github.com/FreeRTOS/FreeRTOS.git --recurse-submodules cd FreeRTOS/FreeRTOS/Demo/CORTEX_MPS2_QEMU_IAR_GCC/build/gcc make 生成的镜像文件 output/RTOSDemo.out 二。启动测试 用下面命令启动虚拟机 qemu-system-arm -machine mps2-an385 -cpu cortex-m3 -kernel output/RTOSDemo.out -monitor none -nographic -serial stdio 三。 代码调试 通过vscode打开这个demo的代码 code /FreeRTOS/FreeRTOS/Demo/CORTEX_MPS2_QEMU_IAR_GCC 在vscode中创建launch.json 和 tasks.json 内容如下图： launch.json的内容如下： { "version": "0.2.0", "configurations": [ { "name": "Launch QEMU RTOSDemo", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/gcc/output/RTOSDemo.out", "cwd": "${workspaceFolder}", "miDebuggerPath": "arm-none-eabi-gdb", "miDebuggerServerAddress": "localhost:1234", "stopAtEntry": false, "preLaunchTask": "Run QEMU" }, ] } tasks.json的内容 如下： { "version": "2.0.0", "tasks": [ { "label": "Build QEMU", "type": "shell", "command": "make --directory=${workspaceFolder}/build/gcc", "problemMatcher": { "base": "$gcc", "fileLocation": ["relative", "${workspaceFolder}/build/gcc"] }, "group": { "kind": "build", "isDefault": true } }, { "label": "Run QEMU", "type": "shell", "command": "echo 'QEMU RTOSdemo started'; qemu-system-arm -machine mps2-an385 -cpu cortex-m3 -kernel ${workspaceFolder}/build/gcc/output/RTOSDemo.out -monitor none -nographic -serial stdio -s -S", "dependsOn": ["Build QEMU"], "isBackground": true, "problemMatcher": [ { "pattern": [ { "regexp": ".", "file": 1, "location": 2, "message": 3 } ], "background": { "activeOnStart": true, "beginsPattern": ".", "endsPattern": "QEMU RTOSdemo started", } } ] } ] } 按F5启动调试 如下图 1 个帖子 - 1 位参与者 阅读完整话题