夜雨聆风
🚨 本周高频坑点 TOP 10
1. Copilot 不是“包月随便用”了，长上下文 Agent 任务要开始算账
• 现象：从 6 月 1 日开始，很多 Copilot 用法会按 GitHub AI Credits 计费。一次 Agent 任务消耗多少，不只看你问了几次，还看模型、输入 token、输出 token、缓存 token。GitHub 文档写得很直接：1 个 AI Credit = 0.01 美元。 • 影响范围：Copilot Pro、Pro+、Business、Enterprise 用户。最容易中招的是三类用法：让 Agent 扫大仓库、让它多轮修 PR、让它输出很长的分析报告。 • 原因：Copilot 的成本模型从“请求次数”转向“模型 + token”。这件事本身不神秘，LLM 的真实成本一直在那里，只是现在更直接地出现在账单上。 • 怎么处理： • 把“补全”和“Agent 任务”分开看。补全可以继续日常用，Agent 任务要有边界。 • prompt 里明确限定文件、限定 diff、限定输出长度。 • 团队管理员先开预算和用量监控，不要等账单出来再猜是谁烧的。 • 来源：GitHub Copilot usage-based billing 文档
2. Copilot 自动审 PR 会吃 Actions minutes，私有仓库尤其要注意
• 现象：Copilot code review 现在不只是 AI Credits 成本。私有仓库里，每次自动 review 还会消耗 GitHub Actions minutes。 • 影响范围：把 Copilot review 接进 PR 流程的团队，尤其是私有仓库、PR 数量多、自动 review 默认开启的项目。 • 原因：GitHub 说明 Copilot code review 的 agentic tool-calling 架构跑在 GitHub Actions runner 上。也就是说，它不是一个“轻量评论机器人”，而是一次真实的 runner 任务。 • 怎么处理： • 不建议所有 PR 默认开自动 review。先给大 PR、关键模块、外部贡献 PR 开。 • Actions minutes 和 Copilot Credits 要分开设预算。 • 如果已有自托管 runner，可以评估迁移 review runner，但 AI Credits 仍然会消耗。 • 来源：GitHub Changelog：Copilot code review 从 2026-06-01 开始消耗 Actions minutes
3. Claude Code 6 月 2 日中断提醒了一件事：Agent 工作流不能只绑一个供应商
• 现象：6 月 2 日，Claude Code、Claude.ai、API 都出现过间歇性问题。开发者看到的可能是 Claude Code 卡住、响应变慢、API 错误率升高。 • 影响范围：当天依赖 Claude Code 改代码、跑 CI 修复、自动开 PR 的团队。 • 原因：这是服务端可用性事件，不是你本地 .mcp.json或 CLI 配置突然坏了。The Register 记录称中断约从 06:00 UTC 开始，10:42 UTC 状态页显示已实施修复；Anthropic 后续回应称 Claude Code、Cowork、Claude.ai 和 API 都有用户受到影响。• 怎么处理： • 先看 status page，不要第一反应就重装 CLI、清缓存、删配置。 • 关键工作流准备第二 provider，比如 Codex、Copilot Agent 或本地 vLLM。 • CI 里的 Agent 任务要设置最长运行时间，防止服务没恢复时一直挂住。 • 来源：The Register 对 2026-06-02 Claude outage 的记录、Anthropic status page
4. OpenAI 6 月 3 日也出现错误率升高，Codex 和 Responses API 都受影响
• 现象：OpenAI 状态页显示，6 月 3 日 Codex、ChatGPT、Responses API 出现 elevated error rates，事件最终恢复。 • 影响范围：Codex CLI、Codex App、Responses API、依赖 OpenAI 做自动化处理的脚本。 • 原因：OpenAI 服务端 partial outage。对开发者来说，这类问题最麻烦的地方是：它看起来很像“模型突然变笨”或“代码写错了”，但其实是底层服务不稳定。 • 怎么处理： • API 层把 429、500、server_error分开处理。• 对 streaming 响应做中断恢复。 • Codex 长任务拆小，保留 diff，别让一次服务异常吞掉整轮工作。 • 来源：OpenAI Status：Elevated error rates on Codex, ChatGPT and Responses API
5. macOS 上的 OpenAI 应用要在 6 月 12 日前更新，不然可能被系统安全机制卡住
• 现象：OpenAI 要求 macOS 用户在 2026 年 6 月 12 日前更新 OpenAI 应用。旧版本后续可能因为证书撤销和 notarization 变化，被 macOS Gatekeeper 阻止新下载或首次启动。 • 影响范围：macOS 上使用 ChatGPT、Codex 等 OpenAI 桌面应用的用户；企业 MDM 分发也要检查。 • 原因：TanStack npm 供应链攻击波及 OpenAI 的签名相关材料。OpenAI 选择轮换安全证书，并阻止继续使用受影响材料进行 notarization。 • 怎么处理： • 只从 OpenAI 官方渠道更新。 • 企业管理员检查 MDM 包版本，6 月 12 日前替换旧包。 • 如果遇到 Gatekeeper 拦截，先确认版本和签名，不要教用户绕过系统安全策略。 • 来源：OpenAI 对 TanStack npm 供应链攻击的回应
6. TanStack 事件真正该查的是 CI 信任边界，不只是 package 版本
• 现象：TanStack 披露，攻击者在 2026-05-11 19:20-19:26 UTC 发布了 42 个 @tanstack/*包的 84 个恶意版本。• 影响范围：依赖 TanStack 的前端项目、组件库、内部工具、构建机、GitHub Actions workflow。 • 原因：官方 postmortem 指向几个经典但很危险的组合： pull_request_target风险模式、GitHub Actions cache poisoning、fork/base 信任边界，以及从 runner 进程内存提取 OIDC token。• 怎么处理： • 查 lockfile 里是否锁到了 2026-05-11 附近的异常 @tanstack/*版本。• 轮换 CI 里能发布包或访问云资源的 token。 • pull_request_targetworkflow 不要直接 checkout 并执行 fork 代码。• 对高风险依赖设置安装延迟，避开刚发布几小时内的供应链风险窗口。 • 来源：TanStack 官方 postmortem
7. Codex CLI 0.133.0 在 Windows 上有 sandbox 读文件异常，遇到就先回退验证
• 现象：有 Windows 11 + PowerShell 7 用户反馈，Codex CLI 升到 0.133.0 后，Agent 在项目目录内也读不到文件；回退到 0.132.0 后恢复。 • 影响范围：Windows 上使用 Codex CLI sandbox 的用户，特别是需要本地读写项目文件的场景。 • 原因：GitHub issue 标记为 CLI、sandbox、windows-os 相关 bug。目前更准确的说法是“社区可复现反馈”，还不是官方确认的完整结论。 • 怎么处理：
codex --version
npm install -g @openai/codex@0.132.0回退后，用一个最小仓库验证：让 Codex 读取根目录 README、package.json 或任意小文件。如果恢复，再把系统、终端、Codex 版本、复现步骤补到 issue。
8. Claude Code 的 MCP 工具没出现在上下文里，不一定是掉线
• 现象：Claude Code changelog 提到，当 MCP tool 描述超过上下文窗口 10% 时，会自动延迟加载，不再一次性塞进上下文，而是通过 MCPSearch发现工具。• 影响范围：配置了大量 MCP server、插件、skills 的 Claude Code 用户。 • 原因：这是上下文管理策略变化。工具太多时，把所有工具描述都塞进 prompt，会浪费上下文，也会降低模型注意力。 • 怎么处理： • 先让 Claude 搜工具，不要直接判断 MCP server 失效。 • 需要调整阈值时，用官方新增的 auto:N语法。• 如果必须恢复旧行为，可以把 MCPSearch加入disallowedTools，但副作用是上下文更容易被工具描述吃掉。• 来源：Claude Code changelog
9. vLLM 升级别只看“能启动”，CUDA 和 KV cache 默认值都会改变线上行为
• 现象：vLLM release notes 显示，默认 PyPI wheel 和 vllm/vllm-openai镜像已切到 CUDA 13.0；文档里kv_load_failure_policy默认值为fail，KV cache load 失败会直接失败，而不是自动重算。• 影响范围：自托管推理、P/D disaggregation、KV offload、LMCache/NIXL、长上下文服务。 • 原因：vLLM 正在快速演进。性能、CUDA、KV cache、speculative decoding 都在变。平均性能提升很有吸引力，但尾部失败模式也会跟着变。 • 怎么处理： • CUDA 12.9 环境不要盲升默认 wheel，按 release notes 选对应 backend。 • 如果业务希望 KV 失败时自动重算，显式确认 kv_load_failure_policy。• 灰度压测要覆盖长上下文、并发、KV eviction、worker 重启，不要只跑短 prompt smoke test。 • 来源：vLLM releases、vLLM KV transfer docs
10. Ollama 默认上下文变大后，大显存机器也可能被拖慢
• 现象：Ollama issue 中有用户提醒，预发布说明里的默认上下文长度会按 VRAM 调大。例如 >=48GiB VRAM 默认 262,144 context，可能导致模型溢出到 CPU，表现为 Ollama 卡住、吞吐暴跌。 • 影响范围：本地大显存机器、Mac/Windows 桌面用户、本地 coding agent 接 Ollama 的场景。 • 原因：上下文不是越大越好。模型、量化、KV cache、并发都要一起算。只看 VRAM 容量，很容易忽略 CPU spill。 • 怎么处理：
OLLAMA_CONTEXT_LENGTH=32768 ollama serve或者在 Modelfile 里固定：
PARAMETER num_ctx 32768如果生成突然变慢，先看 GPU/CPU 占用，再判断是不是模型或 prompt 问题。
🛠 解决方案归档
Copilot 成本先按“补全、Agent、PR review”拆开
本周之后，Copilot 成本不要混在一起看。
补全：日常写代码，继续用。
Agent 任务：看模型、上下文、轮次和输出长度。
PR review：私有仓库同时看 AI Credits 和 Actions minutes。
给 Agent 的任务边界可以写得很硬：
只读取以下文件：
- src/...
- package.json
只输出：
1. 修改摘要
2. 涉及文件
3. 需要我手动确认的风险
不要扫描整个仓库。
不要生成长篇解释。
不要修改未列出的文件。这是最朴素的办法，但通常最有效。Don't be a hero.
Claude / OpenAI 出问题时，先判断是不是服务端事故
如果同一时间很多人都说 Claude Code、Codex、Responses API 卡住，优先查 status page。不要一上来就重装 CLI。
团队脚本建议加三层保护：
1. 单次请求超时
2. 指数退避重试
3. provider fallback 或任务暂停Agent 工作流真正难的不是 90% 场景能跑，而是服务抖动、网络失败、工具卡住时，系统还能不能保持可恢复状态。
npm 供应链排查从 lockfile 和 CI 权限开始
先查依赖：
npm ls @tanstack/react-router @tanstack/query-core @tanstack/react-query
npm audit signatures再查 CI：
• pull_request_target是否执行了 fork 代码• publish job 是否只允许受保护分支触发 • npm token、GitHub token、云厂商 token 是否需要轮换 • 是否能给新发布包加 minimum release age
这不是前端小坑。这是 Software 1.0 的供应链问题，打到了 Software 3.0 的工具链上。
Windows 上 Codex CLI 升级前，先保留回退路径
Windows 用户建议每次升级前先记版本：
codex --version如果升级后项目内文件也读不了，先回退验证：
npm install -g @openai/codex@0.132.0能用最小复现证明问题，就不要在本地权限设置里绕太久。
🔧 AI 编程工具变化
VS Code Copilot Agent 更强了，也更需要预算和权限边界
GitHub 6 月 3 日的 VS Code Copilot changelog 提到：Agents window 进入 Stable preview，远程 agent、session sync、BYOK token visibility、reasoning effort controls、terminal output compression、sandbox 网络命令重试等能力都在推进。
开发者实际要注意的是：
• 多 session 并行会提高效率，也会并行消耗 token。 • BYOK token visibility 很有用，尤其是接企业自己的 OpenAI-compatible endpoint。 • terminal 输出压缩可以省上下文，但排查构建失败时要保留原始日志。 • 网络命令自动重试更方便，但企业环境要看代理、白名单和审计策略。
来源：GitHub Copilot in VS Code May releases
Claude Code 的 MCP 自动搜索，本质上是在给工具做索引
MCP server 多的人会明显受益。排障方式也要变：以前看工具有没有被塞进上下文，现在要看 MCPSearch 能不能找到工具、工具描述是否足够清楚、阈值是否合适。
来源：Claude Code changelog
🧩 API / MCP / Agent 兼容性提醒
Responses API 要把服务端错误当成正常输入
6 月 3 日 OpenAI incident 同时影响 Codex、ChatGPT 和 Responses API。生产里接 Responses API，建议至少做这些：
• 429、500、server_error分开处理。• streaming 响应要能中断恢复。 • 工具调用链路保存中间状态，避免一次失败丢掉整个 Agent 任务。
MCP 工具描述以后会更重要
工具描述不是给人看的装饰，它会变成模型检索工具的入口。建议每个 MCP tool 描述都写清楚：
• 这个工具解决什么问题 • 输入参数是什么 • 什么时候不要用 • 和相似工具有什么区别
工具越多，越要克制。否则上下文会被工具说明吃掉，模型反而更难工作。
⭐ 值得关注的开源项目
vLLM：性能很强，但升级要像升级数据库一样谨慎
vLLM 的 CUDA、KV cache、speculative decoding、disaggregated serving 都在快速变化。生产环境别只看“启动成功”。先固定镜像和 CUDA 组合，再压测，再灰度。
Ollama：适合本地 Agent，但默认上下文要自己管
Ollama 很适合本地 coding agent。真正要管的是 num_ctx、量化、并发和 GPU/CPU 占用。上下文开太大，体验不一定更好。
TanStack：这次复盘值得前端和平台团队都读
它的重点不只是“哪些版本有问题”，而是 GitHub Actions、OIDC、cache、fork PR 信任边界。做组件库、npm 私服、前端基础设施的团队都应该复盘一遍。
📊 趋势观察：AI 编程工具已经变成基础设施，基础设施就会有基础设施的坑
这一周的共同点很清楚：问题不在“模型又发布了什么”，而在 AI 工具链开始进入真实工程系统。
• 账单会成为工程问题：长上下文、多 Agent、自动 review 都会变成可观成本。 • 可用性会影响开发节奏：Claude 和 OpenAI 的服务中断会直接打断当天工作。 • 供应链会打到 AI 公司：npm、CI、签名证书这些老问题，现在会影响 AI 桌面应用和 Agent 工具。 • 本地部署也有尾部问题：vLLM、Ollama 的默认值变化，会影响吞吐、显存和稳定性。
我觉得这就是 Software 3.0 很现实的一面：自然语言成了新的编程界面，但它下面仍然跑着旧世界的东西：账单系统、CI、证书、runner、CUDA、KV cache、网络重试。
所以这周最值得做的，不是追一个新模型，而是给自己的 AI 工具链补护栏：预算、版本锁、状态监控、provider fallback、CI 权限边界、最小复现和可回退命令。
就这样。
📌 本文由「路先生的AI库」整理发布，每日更新 AI 圈、技术圈重要资讯。
🧠 关注路先生的AI库，不错过每一次技术浪潮。
