云雀 · 轻技术笔记

2026年11月1日：五个 27B 打赢了前沿模型，而 OpenAI 的沙箱是被自己的组件捅穿的

AIAgentLLM大模型AIGC

先说结论。

10 月 31 日这一天，HN 首页前 30 条里 AI 相关至少 5 条，其中 4 条过了 100 分。排第一的不是 AI，是 Karpathy 用 HN 推荐流重造 YouTube —— 877 分，这个我待会儿会提一句。真正该看的两条，一条 311 分，一条 246 分。

311 分那条，是 Parameter.ai 团队写的一份 ChatGPT 账号接管的完整利用链：一个普通的公开分享链接，点开就能在受害者登录态里执行任意 JavaScript，枚举私有会话、读出内容、发到攻击者服务器。OpenAI 在 10 月 26 日修掉了，定级 P1，赏金 5000 美元。

246 分那条，是一个研究者发推说被 Anthropic 以「训练竞品」为由标记了。评论里澄清：其实不是封号，是 safeguard 在中途打断了一次查询。

这两条跟 AI 编程生态没什么关系对吧？

还早。

因为同一天，GitHub 上一个只有 34 星的 Go 项目（memdoor）在 HN 拿到 123 分，声称五个 Qwen3.8-27B 在 LiveCodeBench Hard 上打赢了 Fable 5。它的作者同时公开了全部 50 次运行的每一个请求、每一次回复、每一段程序和评分器的完整输出，还专门写了一节讲自己哪儿输了。

同日，Google 官方开源的 Elephant-Goldfish Model（7,944★）在做的事，是让一个零上下文的子 agent 去挑另一个 agent 写的规格书的毛病，硬约束是「金鱼评审必须开全新子 agent 上下文，主 agent 做不到就停下不评」。README 里写着：几千名 Google 工程师在用 EGM，在写代码之前先用深上下文 agent 起草规格，再用零上下文 subagent 压测它，最后由人来做架构权衡和批准。

同日，OpenAI 公告 12 月起 ChatGPT 与 Codex 共享额度。同日，小米官方 MiMo-Code 的 README 里写着：GPT-5.6 的 prompt 超过 272K 输入，整次请求按 2 倍输入、1.5 倍输出计价，「目录里写着 1M 不等于你的这条路由给你 1M」。同日，DeepSeek Harness 团队公开发表《Super-agent 设计探索》，把双层架构、存算分离、外部 Watchdog 写成了官方方法论。

摆一起，指向同一个位置。

1. 一场只有 34 个人关心的实验

先讲那个 34 星的项目，因为它最容易被当成噪音，也最容易说明问题。

memdoor，Go 写的，一个静态二进制，curl | bash 装完就能用。它的作者在 10 月 25 日读了 GVS5H 那篇论文（arXiv:2608.26480），然后用 memdoor 的 workflow 把 GVS5H 的方法重写了一遍，用同一批 prompt、同一套 loop，跑同一个模型 Qwen3.8-27B。

结果：

pass Memdoor workflow 作者原 harness Fable 5 单次
1 10 / 10 9 7
2 10 / 10 10 8
3 10 / 10 10 10
4 10 / 10 9 8
5 9 / 10 10 7
mean 9.8 9.6 8.0

五个 27B，赢了单次调用的 Fable 5。

先别急着欢呼。这张表有三个洞，作者自己全写在 README 里了，我们一个一个拆。

第一个洞：样本是 10 道题，不是 100 道。 论文跑的是 LiveCodeBench Hard 最新的 100 题，memdoor 只复现了前 10 题，五轮。10 道题上 9.8 和 9.6 的差距，是 2 道题的差别。

第二个洞：污染。 这 10 道题的赛题日期是 2025 年 3 月 29 日到 4 月 6 日，模型完全可能在训练里见过。README 原话是 "contamination cannot be ruled out"。而且 LiveCodeBench Hard 本身已经是老基准，社区早就饱和了。

第三个洞，也是最要命的：Fable 5 那一列不是在这个 harness 里跑出来的。 那是作者仓库里重新评分的结果文件里搬过来的单次调用成绩。等于说，拿「五次调用 + 一个 manager 盯着」去比「一次调用」，而且那一次调用还是别人跑的。

作者把这三条都写在正文的注里，没藏。

这就是为什么这个项目值得单独讲。不是因为它证明了小模型能打败大模型——它证明不了。而是因为一个 34 星的项目，愿意把自己的失败模式、成本明细、以及对自己有利的对比里所有的窟窿，一次性摊在你面前。今天 HN 上大部分 AI 讨论做不到这件事。

还有一点作者自己写在 README 里的：这套 workflow 文件不是人手写的。是一个 coder agent 根据方法描述自己写出来的（2026-10-25）。

2. 把账算完：50 次运行，$35.79，40 分钟

我们继续往下钻，因为细节比结论值钱。

成本账。 50 次运行，49 题解出，总花 $35.79，对应 1530 万输出 token。把那 16 次被时钟掐断、被叫停修 bug、或中途暂停的尝试算进去是 $38.77。单次运行中位数 $0.39、40 分钟模型时间，最长的一次 4 小时。

40 分钟出 $0.39 的结果。对比一下：Fable 5 单次跑一道题，得多快、多少 token，自己算。

这次复现到底有多硬？ 作者写了一个 parity 测试 lib/test_parity.py，拿 GVS5H 原 harness 的 multiagent_solve 和 memdoor 的 workflow 打同一个脚本化模型，逐个请求比对：4 个 case 逐字节相同，改一个字符就不同。温度也一样（plan 0.3，ideation 0.4，manager 和 worker 0.2，top_p 0.95，top_k 20），回复上限 128K，最多 10 轮。

这个测试是整个复现里最有说服力的部分，因为它排除的是「他偷偷换了个更好的 prompt 所以更强」这个最常见的质疑。

然后作者列了不同的地方。 唯一实质差异是 host：GVS5H 用自建 vLLM FP8，memdoor 走 OpenRouter，按 Modal、CoreWeave、Wafer 顺序问，Modal 掉到 14 tokens/s 之后就只走 FP8 那批（Wafer、Parasail、CoreWeave）。203 次调用由 Modal 服务，27 次 CoreWeave，115 次 Wafer；有 3 次运行中途换了 host，已完成的步骤保留。

有人留言说他们试过 Cerebras，卡在 32K 输出上限，128K 的推理预算塞不下。作者回：「Cerebras 的速度是真的。」

最后是最值钱的一节：「Where it lost.」

pass 5 的 abc399_e：第一轮的程序是对的。manager 凭空编了一个反例，反例的期望值是错的，团队信了，重写，新程序过了公开样例——公开样例不覆盖那个 case，hidden test 只对 32/44。

pass 4 的 arc196_c 和 arc196_d：一个通过了全部 hidden test 的程序，被后面某一轮覆盖掉了，因为 manager 没喊 done。两个程序在循环结束前都拿回来过正确版本——arc196_d 在第 8 轮，arc196_c 一直到最后一次调用。这两次运行花了 $3.44 和 $4.24，是全部 50 次里最贵的两次。

最贵的两次，都是因为编排层的 manager 说错话，不是模型不会写。

作者自己给了修法：拿暴力枚举去验 manager 编的反例；保留最后一个过了样例的程序。

这两个修法都不在 9.8 这个数字里。

3. 赢的那一层叫编排，不叫模型

现在把论文的数摆出来，因为 memdoor 复现的只是它的一个切片。

GVS5H 的方法叫 ledger-based zero-shot self-orchestration，零训练，核心是：模型的多个全新实例去分解问题，通过一个共享文件系统里的 plan / notes / 当前解来协调。

论文的数：

  • 在 pinned backend 上，这个方法带来最高 25.6 个百分点的提升
  • 编排后的 Qwen3.8 Flash Next 达到 93.0% pass@1，对 Fable 5 的 90.4%，成本是它的 9%
  • 本地部署的开源权重 Qwen3.8-27B，从 66.8% 升到 92.4%

第三条是这轮最值得盯的。66.8 → 92.4，一个本地 27B 从「差很多」变成「基本追平前沿」。

但论文自己写了一句很重要的话：「Gains are not universal: some models are unchanged or worse.」 增益不是普适的，有的模型不变，有的更差。transcript 分析把增益归因于两件事：分解（decomposition）和持久上下文（persistent context）。

也就是说，赢的是「五个角色 + 一份共享账本 + 一个不闭嘴的 manager」这套结构，不是 27B 这个参数量。

顺着这个思路看今天的项目，会发现一条很清晰的主线：今天真正在变的，是编排和输出形态，不是底座模型。

Google 官方的 Elephant-Goldfish Model 走的是反方向：Elephant 持有项目上下文起草规格，Goldfish 评审时不带之前的任何对话，只看草稿和它引用的源码，专门找没写出来的假设和含糊的需求。README 说得很直白——几千名 Google 工程师在用 EGM，在写代码之前先用深上下文 agent 起草规格，再用零上下文 subagent 压测它。

一个往上下文里加东西，一个从上下文里减东西。两个方向完全不同，但都不是模型能力问题，是编排策略问题。

还有 Ponytail：18 万星，README 自己报「有 Ponytail 时 98% 的风险逻辑带测试，没它只有 68%」——同一个 agent、Opus 5.5、39 个任务（含一个真实的 FastAPI + React 仓库）、各跑 5 次。同时报代码 -53%、时间 -41%、成本 -26%、token -45%。它敢把「没它的时候 68%」放在最显眼的位置，这才是能让人信的原因。

answer-me-with-html 更直接：9 个模型手写 HTML，平均 4893 token、31 秒；改成让模型只写 Markdown 草稿、其余交给 CLI，同一批问题 612 token、12 秒。8 倍 token、2.6 倍速度。分解到字节级——SVG 坐标和路径占 47%、CSS 15%、HTML 标签 17%，全部由 CLI 写，模型只写 21% 的文字。

模型能力在今天越来越不是瓶颈，编排和输出形态才是。

这也是为什么模型榜单越来越没用。榜单比的是「模型接到一个 prompt 之后单次输出的水平」，而你真正在工作流里感受到的是「一整套编排之后交付物长什么样」。这两件事的差距，恰恰是你能改的那部分。

4. 官方答案是把裁决层直接做进系统里

上面那些全是社区方案。同一晚上，大厂也在动同一层——只是动法完全不一样。

10 月 31 日晚，DeepSeek Harness 团队在官方公众号发了《Super-agent 设计探索：迈向更自主的 Agent 系统》。他们的判断是：模型能力提升催生了新的应用形态，个人助手开始集中涌现，但现有主流 Agent 设计还难以在多任务和团队协作的规模上支撑这一模式，多任务上限取决于人的注意力。

注意最后这半句。瓶颈不在模型能做什么，在于一个人能同时盯住几个任务。这是分工问题，不是能力问题。

他们给的解法有五个关键词：双层架构、事件驱动、异步多信道交互、存算分离、外部 Watchdog。核心是在底层接管了繁琐的会话管理与上下文同步，让人类从具体的执行细节上移到更高层的决策与验收。

具体到场景：他们说，基于这套思路构建的内部 Super-agent 实例已经在持续运行，日常参与问题复现与修复、代码审查响应，以及 DeepSeek Harness 自身的迭代。团队成员在群聊里反馈软件问题时，即使没有人 @AI，它也能识别出潜在缺陷，在后台尝试复现问题、寻找修复方案。

这一条最有意思。「群里没人 @ 它，它自己看到有人在报错，然后去后台复现」——这不是更聪明的模型，是一个真的在监听事件流、并被允许在没有明确指令的情况下启动工作流的系统。

把它和 memdoor / GVS5H 放一起看，这一天编排层至少出现了四种互不相同的策略：

策略 代表 核心动作 加在哪
加上下文 GVS5H / memdoor 五个角色 + 共享文件账本，manager 不闭嘴 角色之间
减上下文 Elephant-Goldfish 金鱼评审必须开全新子 agent，看不到之前任何对话 评审环节
拿走输出 answer-me-with-html 模型只写 21% 的 Markdown，其余 79% 交给 CLI 模型与产物之间
建事件层 DeepSeek Super-agent 存算分离 + 外部 Watchdog + 事件驱动 系统与系统之间

四种做法没有一条是「换个更强的模型」。

而且四种都对。 GVS5H 论文自己写了：增益不是普适的，有的模型不变，有的更差；transcript 分析把增益归因于分解和持久上下文。也就是说这套编排对某些模型是 25.6 个百分点的提升，对另一些是 0 甚至负数。

这句话的杀伤力比「27B 打败 Fable 5」大得多。因为它意味着：编排策略没有通用解，你必须自己测。 抄别人的 workflow 抄到的是别人的模型增益，不是你的。

5. 同一层的另一面：OpenAI 的沙箱是被自己的组件捅穿的

现在把 311 分那条拆开。这是今天技术含量最高的一份材料，Parameter.ai 团队把整条链写得像教科书。

事情发生在 2026 年 10 月。起点是一个看起来无害的问题：如果 Preview 的代码被关进一个独立的网站，它还能跟外面说什么？

ChatGPT 有个 HTML Preview 功能，能把模型输出的 HTML 代码块渲染成一个小网页。因为里面可能有任意代码，ChatGPT 把它塞进一个受限 frame，跑在另一个 web 地址上。这个设计是对的：Preview 里的代码读不到 chatgpt.com 主页面。

一开始确实如此。然后出事了。

第一步：图功能在主页面装了监听器。 一段正常的交互式数学图，背后加载了一个叫 MathLive 的数学库。加载它不只是画图——它还在主页面上装了一个监听器，接收和 MathLive 屏幕键盘相关的 message。

两个 frame 之间本来不能直接读对方的页面，但可以传消息。浏览器把这叫做「投信箱」：受限的 Preview 进不了主页面，但它可以把消息从槽里投进去。

这本来是安全的，前提是收信方会检查是谁寄的。

MathLive 没检查。它那个顶层控制器用的 origin 策略是 * —— 接受任何 web 地址发来的消息，也不要求消息来自先前批准过的窗口。

第二步：消息格式允许塞 raw HTML。 Preview 发两条消息。第一条把虚拟键盘的 layout 换成攻击者的 HTML，第二条让 MathLive 显示键盘。键盘一显示，MathLive 就把 layout 拼进一个 HTML 字符串，赋值给 innerHTML。

这里有个经典的、我在自己项目里也犯过的错，值得单独拎出来：MathLive 用了 Trusted Types，但它用的是 identity policy，不是 sanitizer。Trusted Types 限制的是「谁有资格往这个 sink 里赋值」，而一个 identity policy 只是给字符串盖了个「我信任它」的章，然后原样放行。

identity 是信任的标记，不是消毒。搞混这两者，等于把安全措施当成安全措施本身。

第三步：iframe 成了跳板。 脚本标签这条路走不通（后面说），所以攻击者改用 <iframe srcdoc="...">。MathLive 把这个 frame 插进主文档时没有加 sandbox 属性。两个后果：srcdoc 会触发一次全新的 HTML 文档解析；因为是主页面创建的，浏览器给它的 web 身份是 chatgpt.com。于是 frame 里的代码可以访问父页面。

第四步：CSP 拦住了 inline script，但放行了 YouTube。 ChatGPT 的 CSP 正确地拦下了内联 JavaScript。然后攻击者发现 CSP 里允许 youtube.com，而 YouTube 的 oEmbed 端点支持 JSONP 风格的 callback 参数。JSONP 的响应是 JavaScript 而不是普通 JSON。这个端点试图拒绝非法 callback，但它把 callback 塞进响应之后才返回校验错误：

https://www.youtube.com/oembed?callback=globalThis.__marker=31337;void

因为 YouTube 本来就在 CSP 白名单里，浏览器把这段响应当脚本加载了，我们的 callback 就跑起来了。

至此，任意 JavaScript 以 chatgpt.com 的身份运行。

第五步：拿到私有会话。 注入的代码读出页面本来就有的会话信息，拿到访问 token 和账户 ID（还会校验 token 里的 account ID 和 session 一致），然后：

Authorization: Bearer <token>
ChatGPT-Account-ID: <victim account>

GET /backend-api/conversations?exclude_conversation_origin=tpp&expand=false&is_archived=false&is_starred=false&limit=20&order=updated&offset=0
GET /backend-api/conversations/<id>?num_turns=2&include_has_versions=true

这不是「屏幕上刚好能看到的文字被爬走」，是直接带着受害者凭据调官方 API。列出会话、取内容、发出去，一个普通的图片请求就够了。

最后的体积数字，顺手也贴一下：最终 callback 5533 字符，YouTube URL 7309 字符，script 元素 7337 字符，iframe 标记 7390 字符。全部塞进一个公开分享链接。

受害者要做的只有一件事：点开链接。不用装 App，不用加入攻击者的 workspace，不用过一遍攻击者控制的登录流程。

OpenAI 自己的复盘给了四条修法：

  1. 消息接收方要同时验证发送方的 web 地址和被授权的那个具体窗口
  2. 跨窗口的设置项里不该放 raw HTML
  3. 动态创建的文档，只要内容可能受不可信 frame 影响，就必须保持 sandbox
  4. CSP 是备份控制，不是攻击者可控 HTML 到达主站之后的唯一屏障

第 1 条对应「用符号代替验证」，第 3 条对应「继承 origin 就以为安全了」，第 4 条对应「CSP 挡不住就换条路」。还有一条报告里点明的：YouTube 那条只是绕开 CSP 的最后手段，根因不是它。 只封那个端点，会消掉一条路径，但不可信的 Preview 照样能往 ChatGPT 里塞 HTML。

作者结尾那句话是整份报告最值钱的一句：

这个 bug 有意思的地方在于，每一个单独的 feature 看起来都合理。Preview 被隔离了。图可以加载数学键盘。frame 之间可以通信。CSP 允许一家大型媒体。公开会话可以被分享。漏洞只在所有这些同时出现在一个页面上时才出现。

和 34 星那个项目一样：一个组件都不坏，组合起来就是洞。

一边是编排让弱模型变强，一边是编排让强模型被捅穿。同一层，两个方向。

6. 今天真正在抢的，是裁决层

最后把 Anthropic 和 OpenAI 这两条放进来，它们跟前面两条的关系不是并列，是因果。

Anthropic 那边有两件事撞在一起。

一件是那个 246 分的推特：研究者 jiahao-shao1 说自己被标记了「训练竞品」。HN 上一位 ID 是 defender level cyber access 的用户说自己没事，另一位说自己用 Claude 搭推理和训练栈、把历史会话喂进 LoRA adapter 也从来没被拦过。还有人说自己拿 Claude 做《万智牌》的 RL，两个月前遇到过几次触发，现在换模型了。

然后是 10 月 31 日当天和前一天连着出的两条： Anthropic 开始阻断 Claude 做视频游戏克隆和逆向工程。HN 上 67 分和 116 分两个帖子，评论区一片 RE（逆向工程）老手在骂。更扎眼的是有人贴了 Anthropic 自己的研究页原话：

GLM-5.3 具有自主构建端到端网络利用的能力。但 GLM-5.3 与其他前沿模型不同，它是在没有有意义的安全措施限制滥用的情况下发布的。

一边写报告说别人没设防，一边自己用分类器划边界、划到你头上。

有个 RE 圈子的评论最说明问题：这是黑天鹅，禁令大概能撑一年，等消融过的开放权重模型追上来就进入开放赛季，大家会跑去用中国模型或者本地模型。这条评论预言的「一年」，在今天 Github 那 34 个 routing 层项目的星数里，已经有人在提前布局了。

这里必须把一件事说清楚，否则容易讲歪。

那 246 分的推特，严格说不是封号。 HN 上至少四条评论在纠正这一点：Anthropic 的 safeguard 在中途打断了某一次查询，用户换个会话、或者换个模型档位（比如从 Opus 切到别的），同一个请求就能过。

但「只是打断」这个说法让人更不安，因为它意味着判定发生在中间层，发生在你完全看不见的地方。你不知道哪一次调用会被拦，你只知道它这次没给你结果。

翻遍评论，误伤样本几乎都是同一类：

  • 有人在拿 Claude 搭自己的推理和训练栈，把历史会话直接喂进 LoRA adapter——没被拦
  • 有人用 Claude 做《万智牌》的强化学习，两个月前触发过几次，现在换模型了
  • 有人让 Claude 扫描自己旧的用户资料备份、列出哪些文件夹可以安全删除——被拒了，还降级到老版本 Opus
  • 有人让 Claude 从自己的单体代码库里提取服务模块——被拒，理由是「复制代码在道德上不对」

你看这几个的共同点：全是在做「把自己的东西拿出来」或者「改自己的模型」。没有一个是要攻击别人。

有个评论把这条边界画得很清楚：反制措施应该针对「把训练数据分类标注」这一类，也就是把别人未公开的数据变成资产；问「大型 MoE 模型怎么设计」这种通用知识，不该拦。

还有一个更刺眼的细节：有律师因为在法庭文件里用了 prompt injection 被制裁（HN 13 分那条）。当「提示词能不能写」开始有法律后果，模型的边界就不再是产品问题了。

而最讽刺的对照在这儿——HN 评论区有人贴出 Anthropic 自己研究页的一段原话：

GLM-5.3 具有自主构建端到端网络利用的能力。但 GLM-5.3 与其他前沿模型不同，它是在没有有意义的安全措施限制滥用的情况下发布的。

一边写报告论证别人没设防有多危险，一边自己用分类器划线、划到研究自己模型的人头上。这两件事同时为真，但它们放在一起，让人很难相信那条线是按原则划的，而不是按诉讼风险划的。

OpenAI 这边则是 12 月起 ChatGPT 与 Codex 共享额度。36 氪今早 9:47 的快讯写得很清楚：Plus、Pro、Business 套餐的额度在 ChatGPT 和 Codex 之间共享，按 token 统计，复杂任务消耗更多，即时对话不占用共享额度，官方预计「大多数用户等待额度重置的频率不会比现在更高」。

HN 那边 27 分的讨论里，最扎心的一条是：这会伤到用 GPT-6-Pro 的人，因为 Pro 在 Codex 和深度研究里都没有，这两个旗舰项目一合并，付 30 美元的人会很难受。底下有人回：OAI 想融 300 亿，现在连 110 亿都在砍成本。

额度合并、模型路由、账号轮换、免费池、禁令阈值、上下文计价悬崖——这些看着是六个不相干的产品决策，其实都在回答同一个问题：谁有权决定你用哪个模型、你的额度算谁的、你能拿模型做什么。

看今天 Github 上那几个项目就明白了：

  • magpie（27,059★，Go）：「Claude Code 跑 Kimi，Codex 跑 DeepSeek，Gemini CLI 跑 GLM，OpenCode 跑你的 ChatGPT 套餐」，一个本地网关全包。额度用完时「provider 的下一个账号自动接手，路由组再切到另一个模型或 provider，所以 Agent 根本看不到那个错误」。
  • opencodex（18,119★）：本地 10100 端口，内置 40+ provider。安全上做得比同类细——agent 驱动的运行需要 agent_consent 授权，API 直接回 403 agent_consent_required。
  • dsh-our-free-model（54,604★，今日 +1,532）：Ed25519 签名 + 公钥 pin 在插件内 + feedUrl 与更新源彻底解耦；转发口先做 DNS 解析再要求结果全为回环，请求体 1MB 上限。它的「EAC 通道」更狠——服务器侧校验你在 GitHub 上 star 了它才放行对话。
  • MiMo-Code（小米官方，13,738★）：compaction.max_context 可以把压缩点提到模型窗口之前，写法是 "200K" / "300K" / "1M" / "50%"，支持 anthropic/* 通配、最长模式优先，且只允许往下压，不能往上抬。为什么这么设计，README 里给了原因：OpenAI 对 GPT-5.6 超过 272K 输入的 prompt 按 2 倍输入、1.5 倍输出计价；同一个模型通过 ChatGPT/Codex 订阅、直连 API key、还是 OpenRouter 转售，拿到的可用窗口可能不一样，所以目录里标 1M 不代表你这条路由给你 1M。

再看一个细节，它把这张图切得更清楚。

dsh-our-free-model 里有个「EAC 通道」，桌面端专属，模型在 DeepSeek Harness 里显示成 EAC 前缀。它的放行条件是：服务器侧校验你在 GitHub 上 star 了它，才放行对话。 凭据加密密封，由宿主指纹闸门把守，命令行和其它宿主里这条通道完全不存在。

star 一个仓库，换一个模型通道。这个设计同时是三件事：一个分发机制、一个准入机制、一个防刷机制——它把社区行为直接变成了模型访问的授权凭据。

我不敢说这是好设计，但我敢说这是今天最诚实的一个：它承认了模型访问权已经变成一种需要分配的稀缺资源，所以干脆用公开的社区行为来分配，而不是假装它不存在。

再看另一头。苹果 CEO 特努斯 9 月初正式出任 CEO，他给苹果在 AI 上的迟缓辩护时说了一句很实在的话：

我们不想为了做 AI 而推出 AI。如果我们做得好，用户不会去思考这个功能到底是 AI 实现的，还是传统软件实现的。

同日，阿里巴巴与 Apple 达成合作，千问集成进 Apple 智能。同日，张朝阳说搜狐的内容不参与大模型收录。同日，OpenAI 奥特曼谈内存短缺，说全球 DRAM 应该优先供给数据中心，「闲置在玩家 PC 里是浪费」。

四家巨头同一天在说四件不同的事，但它们是同一个动作：重新分配「模型能力」的位置。 苹果把它藏进既有产品不让你看见，阿里把它接到系统层，张朝阳把它划成不训练区，奥特曼把它当成该从消费者手里回收的内存。

对普通用户来说，这意味着你能自己控制模型能力的渠道正在变窄：要么装本地，要么付钱给一个会随时改规则的服务。

把这四条加在一起，图景就清楚了：

模型厂商正在把「裁决层」从你手里拿走，同时又对这一层的安全性负责。

你买的明明是「Claude Code」，但你实际在用的是 magpie 的路由、opencodex 的 base URL、MiMo-Code 的预算分配、以及某个插件的免费模型池。这几层没有一个在模型厂商的文档里，也不在你的代码里。

7. 那就数数你的链路里有几层

这一节是我最想给读者的东西。不是概念，是能照着做的。

第一步：把你 agent 实际的 base URL 打出来。 不是配置文件里你写的那个，是运行时真正发请求的那个地址。如果你设了 ANTHROPIC_BASE_URL、OPENAI_BASE_URL 或者任何代理地址，那你已经在路由层里了，而且你可能不知道它在做什么改写。

第二步：查模型名是从哪来的。 客户端写死的？配置里的？网关注入的？这三种对应三种完全不同的故障模式——第三种最麻烦，因为模型名可能在一次工具调用后突然变了，而你在排查「为什么这个任务效果变差」。

第三步：量一次你真实的上下文长度，对上你这条 route 的实际上限。 MiMo-Code 那个 272K 悬崖是典型的：你以为你有 1M，你的 route 给你 200K；或者你以为你压得已经很紧了，其实你以为的窗口和 provider 收的窗口压根不是一回事。mimo models <provider> 那种「打印每个模型实际窗口」的命令，值得在自己的工具链里对一遍。

第四步：审一遍你「预览/渲染」类组件的 postMessage 接收器。 这是 Parameter.ai 那条链的第一个必要条件。你的组件有没有一个 origin 是 * 的 message 监听器？如果有，你已经在一个坑上站着了。OpenAI 的修法就一句：同时验证 origin 和被授权的具体窗口。

第五步：查你所有 Trusted Types 策略是 identity 还是 sanitizer。 一眼扫过去就能分。identity 出现在 sink 上，等于没写。这是我见过最隐蔽的一类「看起来做了安全」。

第六步：查你创建 iframe 的地方有没有 sandbox。 特别是用 srcdoc 的那些——srcdoc 会触发全新文档解析，且继承创建者的 origin，除非你显式 sandbox 掉。

第七步：模拟额度耗尽。 断开网络，或者把 key 改错，看你的 agent 是报一个清晰的错，还是静默换了个模型继续跑。magpie 那种「Agent 根本看不到那个错误」的设计对可用性是加分，对你的心智模型是减分——取决于你要不要知情。我建议你要知情。

顺便说一句 magpie 的机制细节，因为它把「裁决层」这个词落到了实处：它把「一个 provider 的下一个账号接手」和「路由组切到另一个模型或 provider」做成了默认行为，Agent 层面完全无感。它原话是：只有一个账号且没有组的时候，才没什么可切的，错误会直接到 Agent 面前。

换句话说，你的 Agent 可能连自己换了模型都不知道。 而 memdoor 的做法相反——它的 workflow 是 YAML，不指定模型，你把它指向哪个都行，包括 memdoor connect local 接本机的 Ollama、llama.cpp、vLLM、LM Studio。

同一个概念，两种实现哲学：magpie 把路由做进产品默认行为（你不用管，但你也看不见），memdoor 把路由做成一个显式的、被你写下来的决定（你得管，但你在管）。

我站 memdoor 这边，但这是有代价的：显式路由意味着你要自己承担选错模型的责任。 没有默认值的世界不友好，但至少它是真的。

第八步，也是我最想强调的一条：把你的编排策略当代码管理，而不是当感觉。 GVS5H 赢在分解 + 持久上下文，Elephant-Goldfish 赢在刻意清空上下文，Ponytail 赢在敢报自己的失败率，answer-me-with-html 赢在把 79% 的输出从模型手里拿走。这些全是编排层的决定，全都可以被写下来、被测试、被 review。 而你的直觉「这个任务让模型多想一会儿会更好」，是唯一一个不能被复现、不能被 diff、也不能被调优的东西。

8. 那么今天具体该做什么

三件事，从今天开始算。

把路由层显式化。 你至少要能回答三个问题：现在用的是哪个模型、为什么是这个模型、额度从哪来。这三个问题今天都答不上来的话，你对成本和效果的所有困惑都不可能靠调 prompt 解决。

把你的编排层当成可以测量的东西。 GVS5H 那套做法值得抄：五个角色、共享文件账本、manager 不许闭嘴、每个角色的温度写死在配置里。抄完立刻做一件作者做的事——把你自己那套的失败模式写出来。arc196_c 和 arc196_d 那两次 $3.44、$4.24 的失败，比 9.8 这个均值有信息量得多。

把 benchmark 当起点，不当结论。 10 道题、5 轮、可能有污染、基线还是从别人仓库里搬的——memdoor 作者把这四条全写在注里，这才叫诚实的复现。你自己跑评测的时候，也把这几条写在 README 里。没有把自己的失败模式写出来的 benchmark 数字，你没法判断该不该信。

最后说那个 877 分。

Karpathy 那篇 HackerTube 的思路是：把 HN 的推荐流当成训练信号，用视频推荐视频，造一个 YouTube。它今天排在 HN 首页第一。而 Parameter.ai 那份利用链的逻辑是：把一堆各自合理的组件摆在一起，看哪个组合能捅穿边界。

一个是路由层被拿来造新的分发网络，一个是路由层被拿来造新的攻击面。

同一层。今天这一整天的新闻——五个 27B 打赢 Fable 5、Google 官方的零上下文评审、ChatGPT 账号接管、Anthropic 封杀训练者、ChatGPT 和 Codex 合并额度、小米的 272K 计价悬崖——全部发生在这一层。

而这一层既不在你的代码里，也不在模型厂商的文档里。它在中间。

你不知道它在哪，你就永远在跟一个看不见的东西赛跑。编排层没有默认值，只有你亲手写下的那些。