「操作系统谬误」：为什么模型越强，orchestration 反而越重要
英文版：English
一个我反复遇到的论断
大意是这样：现在这些 agentic coding 的工程层——上下文裁剪、编排框架、外部规则——都是为了绕过模型当前的缺陷而搭的临时脚手架。推理模型一变强，长上下文一变便宜，这些东西就没有存在理由了。所以别在 orchestration 上投入，那是过渡期的拐杖。
这个论断有一半是对的，而且它对的那一半相当锋利。我想说清楚的是错的那一半错在哪 —— 它不是方向错了，是级别错了。
它等价于这句话：因为 CPU 越来越快，所以操作系统会消失。
CPU 变快确实杀死了一批 OS 层的东西：内存覆盖（overlay）技术、手工 DMA 管理、为了省几个周期而写的汇编内循环。这些当年被当作核心技艺，今天没人碰。但进程管理、权限控制、设备驱动、文件系统 —— 这些不仅没消失，反而随硬件变强而变得更重要。因为硬件越强，跑在上面的东西越多，需要被隔离、被调度、被审计的边界就越多。
先把对的那一半说完
这个论断背后有一条原则，我认为它完全成立：
任何依赖中间层抽象来填补底层缺陷的方案，最终都会被底层技术的进步淘汰。
这条原则很好用，而且它已经杀死了一批东西。这些不是猜测，是有数字的：
| 被淘汰的 | 被什么替代 | 证据 |
|---|---|---|
| CoT prompting | 推理模型内置推理 | Wharton GAIL：对推理模型用 CoT 只换来 +2.9-3.1% 准确率，代价是 +20-80% 时间 |
| Output parser / retry 循环 | Structured Outputs | 合规率 35% → 100% |
| Few-shot 模板机制 | 零样本能力 | 部分任务里 few-shot 反而降低性能 |
| 基础 tool calling 编排 | 原生 function calling | 已是所有主流 API 的标准参数 |
| 视觉 OCR pipeline | 多模态原生输入 | 主流模型直接吃图 |
如果你 2023 年写的 agent 代码里大半是这些，那确实白写了。这条原则的价值就在这儿：它能提前告诉你哪些工作会短命。
错误发生在下一步 —— 把所有 orchestration 都归类成「填补模型缺陷」。
顺手说一个方法论问题：那篇文章引用了一篇不存在的论文
这个论断的第三层依据是：新一代稀疏注意力机制（文中写作 “NSA+”）让模型可以自主管理上下文，外部上下文管理因此变得毫无必要。
我去查了。公开文献里没有 “NSA+” 这个东西。 真实发表的是 NSA（2025 年 2 月，arXiv 2502.11089，ACL 2025 最佳论文）和 DSA（DeepSeek Sparse Attention，2025 年 9 月随 V3.2 部署），后续还有一篇叫 NOSA（2025 年 10 月）。没有 “NSA+”。
而且 NSA 论文自己写得很清楚，它是计算效率优化，不是语义理解提升：
可训练的稀疏注意力只能缓解 memory-bound 瓶颈，不能减少 KV cache 大小。
它在稀疏阶段每个 query 只挑约 2048 个 KV 条目 —— 那是在做近似，不是在保证模型"读懂"了全部上下文。
反方向的实证同时在累积：Chroma 测了 18 个前沿模型，发现每一个模型、在每一个测试的输入长度增量上，输出质量都随 token 增加而下降；标称 200K 窗口的模型在约 130K 处已不可靠。“Lost in the Middle” 现象持续存在，中段准确率掉 30% 以上。有效上下文与标称上下文的差距最高可达 99%。
所以**「长上下文会吃掉上下文管理」这个前提本身没有成立**，而支撑它的那条引用是虚构的。
我把这段单独拎出来，不是为了抓谁的错。是因为这类论断现在很容易被 AI 协助生成，而生成出来的东西看起来完全像真的 —— 术语的形状对、时间线的形状对、语气的确定性甚至比真论文更强。唯一的防线是回到一次源头。这件事本身就是这篇文章的一个副论点。
那么 orchestration 究竟去哪了：三处重新分配
它没有消失。它换了位置，而且总量在增加。
一、被 RL 烘进模型权重。 Cognition 训练 SWE-1.5、Cursor 推出 Composer 2 —— 都是在真实任务环境里端到端 RL，把 plan-execute 循环、错误恢复、工具选择这些行为内化成权重。这其实是那个论断最有力的间接验证，但实现路径恰好相反：不是「去掉 scaffold」，而是 scaffold → 训练数据 → 模型权重。scaffold 没被删掉，它被吃掉了。
二、标准化成协议。 MCP 把 N×M 的工具集成问题压成 N+M，SDK 月下载量从 2M 涨到 68M，并入 Linux Foundation。这不是 orchestration 消失，是 orchestration 基础设施化 —— 就像 HTTP 之于 web。没人再说"我在做 HTTP 编排"，因为它变成了地基。
三、压薄成 thin harness。 Claude Code 的 agent 主循环大约 50 行（while(tool_call) → execute → feed results → repeat），18 个工具，单线程，没有 multi-agent swarm。但它外面包着 29,000+ 行 harness。心脏变薄了，骨架变厚了。
一条可检验的判别式
把那 29,000 行拆开，能分成七类。每一类都有一个「为什么模型吸收不了它」的结构性理由：
| 类别 | 典型内容 | 为什么留在 harness |
|---|---|---|
| A. 外部世界接口 | Bash、文件读写、Git、MCP、IDE | 物理鸿沟：模型产文本，不产 syscall |
| B. 信任边界 | 权限、审批、沙箱、黑白名单 | 架构原理：不能让被审计者当审计员 |
| C. 跨会话状态 | 会话持久化、任务跟踪、项目记忆 | 时间维度：状态必须活得比任何单次 context 长 |
| D. 多 agent 协调 | 子 agent 派发、worktree 隔离、消息路由 | 这是分布式系统问题，与模型能力正交 |
| E. 经济管理 | token 预算、prompt caching、模型路由 | 模型看不到全局成本 |
| F. 人机界面 | 终端渲染、diff、hooks、slash command | 这是 agent 之外的接口，不是推理问题 |
| G. 工程脚手架 | schema 校验、工具检索、重试 | 理论上可吸收，目前不划算 |
A 到 F 全部涉及模型之外的东西：物理、信任、时间、协调、经济、人。G 是唯一一类会随成本下降被吃掉的。
于是判别式可以写成一句话：
能被压缩成「更好的 next-token-prediction」的能力，会被模型吸收。
涉及模型外部世界（物理 / 信任 / 时间 / 协调 / 经济 / 人机）的能力，会留在 harness。
这条式子可以正着用，也可以反着用。反着用更狠：如果你正在做的事情可以被压缩成"更好的提示词模式"，那它大概率会被下一代模型消灭。 拿它检查一遍自己的技术押注，比读十篇趋势预测有用。
但 scaffold 到底还重不重要？这是可以证伪的
不用争论，看数字：
- 同一个模型，换 scaffold，差 12 到 30 分。 SWE-bench Pro 上基础与优化 scaffold 之间有 22 分以上的摆动；单是把上下文检索做好就能加 4 到 10 分。
- Epoch AI 的结论：一个优秀的模型配平庸的 scaffold，会输给一个良好的模型配出色的 scaffold。
- SWE-bench Verified 上榜首已经 85% 到 94%，但更接近真实场景的 SWE-bench Pro 最高分只有约 23%。
最后这组对比值得停一下。同一批模型，换一套更像真实工作的题，分数掉到四分之一。 那掉下去的部分不是模型智能的缺口，是"世界没有被组织好"的缺口 —— 也就是 harness 的活。Anthropic 自己的工程博客把这件事说得最准：
agentic 系统的主要短板不是模型的智能，而是为它组装出的那个世界的质量。
顺带说，"简单胜于复杂"确实有权威背书 —— Anthropic 官方指南明确说最成功的实现都没用复杂框架，而是用简单可组合的模式。但**「简单」和「不存在」是两件事**。Claude Code 那 50 行循环之所以能简单，正因为它下面压着 29,000 行。
两条我因此改掉的判断
第一条：易用性是一种由底层工程师偿还的债。
上层抽象越简单，底层必然越复杂 —— 这两者是反向耦合的，不是独立的。SQL 一行查询背后是博士级难度的查询优化器；pip install 背后是 HTTP/2 + TLS + DNS + TCP + IP 整条栈；git push 背后是分布式一致性与冲突检测；iPhone 的 “It Just Works” 背后是 iOS 加 Secure Enclave 加几千人的工程团队。
机制有四条：用户越多需求维度越杂；每加一层抽象就多一组「是 A 还是 B 还是接口」的排查空间；上层接口一旦稳定就不能动，底层所有变化都得伪装成"接口没变"；越基础的东西挂掉越是灾难，可靠性 bar 只会单调上升。
反直觉的结论：如果你的软件"用起来很简单"，不是因为问题简单，是因为有人替你把复杂度承担了。
第二条：便宜是滞后指标，难是领先指标。
CRUD 今天极其便宜。这不是因为它简单，是因为四十年的基础设施投资被压缩进了一个 pip install —— 你在消费一种被凝结的复杂度化石燃料。
| 阶段 | 难度 | 时代 |
|---|---|---|
| 前沿 | 博士论文级 | Codd 的关系代数，1970s |
| 框架 | 专家领域 | SQL 标准化，1980s |
| 标准 | 多数人可用 | MySQL / Postgres，1990s |
| 基础设施 | 不可见 | Rails / Django，2000s |
| 商品化 | 小时级搭完 | 2020s 的 CRUD |
Harness 今天很难，意味着它正处在这张表的第一行。今天的 hard，就是 2040 年的 pip install。
所以：押注 cheap 的东西是消费过去的复杂度，边际价值递减；押注 hard 的东西是生产未来的复杂度，边际价值递增但波动大。
落到 SRE 视角
我做的是基础设施可靠性，所以这件事在我这儿有个更直接的说法。
接口问题不会因为接口的任何一侧变强而消失。 工具集成、安全门禁、系统边界管理、跨会话的错误恢复 —— 这些不是在填补模型的缺陷，它们在管理模型与外部世界之间的那道界面。模型变强只会让界面另一侧的动作更有力、后果更大，于是界面本身更需要被设计。
这正是操作系统的历史。CPU 变快没有让 OS 消失，它让"谁能碰哪块内存、哪个进程能发哪个 syscall、失败时谁来回滚"变得更要紧。
agent harness 现在走的是同一条路。而且比 OS 那次更急 —— 因为 CPU 不会自信地编造一个不存在的答案，模型会。
文中所有数字与论文均来自公开来源：Wharton GAIL 的 CoT 研究、Chroma 的 context rot 报告、Epoch AI 的 scaffold 对比、Scale AI 的 SWE-bench Pro 榜单、NSA（arXiv 2502.11089）、a16z 的 LLMflation 数据、Anthropic 的工程博客与官方 agent 指南。可检验，欢迎反驳。