把大模型接进真实流水线时的架构判断、本地推理与调参。
本地 Docker 跑一个代理,把 Claude 的 OAuth 订阅账号转成标准 API(localhost 上同时暴露 OpenAI 和 Anthropic 两种兼容端点),这样各种只认 API key 的工具就能复用订阅额度。
OAuth 登录踩坑:本机操作免 SSH 隧道、务必用最新的 state、交互式登录最稳。这是我本地 AI 基础设施的第一块砖。
接 Anthropic 的 web_search 工具时踩到一个隐蔽的版本坑。
web_search_20260209 引入了 dynamic filtering,会在中间插一层 code_execution。副作用:你的 query 不再出现在流式 input 里,如果你按「query 出现次数」统计搜索数,会恒定数到 0。而且在代理链路下容易触发 900s 超时或 pause_turn。
对策:简单场景强制用老版本 web_search_20250305;搜索计数一律改看 web_search_tool_result 块,别数 query。附带教训:credit 余额 400 报错容易被误诊成没搜到,其实是配额问题。
想用本地模型(LM Studio 跑 Qwen)驱动一套白盒审计 rig,省订阅钱。结论:Claude 路径能跑通并产出真实漏洞,本地 qwen 的真正硬墙不是智力,是上下文。
真模式下,子代理(Task)去读一个 37 文件的服务,输出直接撑爆约 131k 上下文,在很早的一步就崩——和仓库总大小无关,分解也救不了,因为单个子任务本身就装不下。大上下文还慢。
配置层面全都能修通:thinking 必须关(否则输出空 / 不合规)、provider 走 lm_studio、ctx 拉到 131k、温度 0.2。修通之后经 LiteLLM 能正确吐 Anthropic 的 tool_use。
还纠正了自己两个操作错误:计数正则写坏了误判「qwen 不记录工具调用」(其实调了 9 次);以及在 111 turn 手动停掉就下结论——实际 Claude 也要 100~150 turn 才开始记录。别带着预判去验证,会自我实现。