RAG 正在消亡。不是因为它不好——而是因为模型变大了。当上下文窗口从 4K 跳到 128K token，工程师花几个月精心构建的检索管道变成了不必要的开销。模型现在直接读完整份文档。
同样的模式在不断重演。Chain-of-thought 提示模板？模型现在原生推理。自定义 JSON 解析器处理工具输出？Function Calling 搞定了。针对幻觉的重试循环？新模型幻觉更少了。每一代模型都在悄悄删除一类工程工作。
这引出了一个令人不安的问题：你现在做的 Agent 工程，有多少能挺过下一次模型升级？
两种工程
并非所有 Agent 工程生而平等。有一种分裂，大多数从业者能直觉感受到但很少命名：
补偿性工程修补模型短板。它存在的原因是当前模型某方面做得不够好，于是你在外面搭脚手架。小窗口模型的 RAG，弱推理模型的 CoT 模板，不靠谱结构化生成的输出验证器。这些工作今天很有价值——但它有保质期。模型一进步，补丁就变成死代码。
系统性工程解决的是无论模型能力如何都存在的问题。任务间的上下文隔离。多步骤工作流的错误恢复。竞争能力模块的适应度评估。不可信组件之间的信任边界。这些问题不会因为 GPT-6 发布而消失。它们会变得更难，因为更强的模型运行在更复杂的环境中。
这个区分至关重要，因为它决定了你工作的半衰期：
| 补偿性 | 系统性 | |
|---|---|---|
| 为何存在 | 模型还做不到 X | 真实世界的复杂性要求 X |
| 模型进步后 | 被删除 | 变得更重要 |
| 例子 | 4K-token 模型的 RAG 管道 | 并发 Agent 任务的上下文隔离 |
| 半衰期 | 6–18 个月 | 5 年以上 |
这不是价值判断——补偿性工程解决的是眼前的真实问题。但如果你要投入几个月的精力，你应该知道自己是在搭帐篷还是在建地基。
四项系统性能力
如果补偿性工作有保质期，什么没有？四项能力经得起每一次模型升级，因为它们应对的是世界的复杂性，而非模型的局限：
| 传统软件工程 | Agent 工程 | 协议化 Agent 工程 |
|---|---|---|
| 状态管理 | 上下文管理 | 上下文契约（声明式 Schema） |
| 流程编排 | 控制流设计 | 可组合控制模块 + 形式化组合代数 |
| 异常处理 | 错误恢复 | 约束驱动的 Fallback（模型无关） |
| 监控告警 | 反馈回路 | 定量适应度评分 + 持续评估 |
左列很熟悉。中列是大多数 Agent 工程师今天的工作领域——而且它确实是系统性的。在多步骤 Agent 工作流中管理上下文，无论底层模型是 GPT-4 还是 GPT-6 都很困难。为非确定性执行设计健壮的控制流是真正的工程挑战。
但注意第三列。它代表了中列没有回答的问题：当你有很多 Agent、很多能力模块，却没有系统性的方法评估哪些真正有效时，怎么办？
Agent 工程的三个层次
从业者构建 Agent 系统有一个自然的进阶路径，它映射到工作的持久性：
Level 0：学框架 API。 LangChain、AutoGen、CrewAI——学抽象，交 demo。半衰期：约 6 个月。框架 API 会 break、会 deprecate、会被模型原生功能取代。这主要是伪装成系统性工程的补偿性工程。
Level 1：学 Harness 工程。 上下文管理、控制流、错误恢复、反馈回路——四项系统性能力。这是真正的工程。它跨框架、跨模型、跨场景迁移。一个理解上下文隔离的工程师不需要在下一个框架发布时重新学习。半衰期：5 年以上。
Level 2：用标准化协议构建可进化的能力系统。 能力本身——Agent 组合使用的工具、技能、模块——成为具有形式化身份、定量适应度、竞争评估和跨 Agent 传播能力的一等对象。这是基础设施层。它不会过期，因为它不关乎任何特定模型或框架——它关乎能力如何诞生、测试、筛选和改进。
捕捉这个进阶的隐喻：
Level 1 说：Agent = Model + Harness。 Level 2 说：Agent = Model + Evolvable Harness Ecosystem。
Level 1 把一个 Harness 造好。Level 2 构建的是让 Harness 竞争、进化、传播的系统——最好的能力胜出，而非最先发布的。
协议的回答
如何系统性地区分系统性工程和补偿性工程——不依赖人工判断？
不要标注它。让选择压力做这件事。
在 Rotifer Protocol 中，每个能力模块（称为 Gene）都由定量适应度函数评分：
$$ F(g) = \frac{S_r \cdot \log(1 + C_{util}) \cdot (1 + R_{rob})}{L \cdot R_{cost}} $$
Gene 在标准化 Arena 中竞争。当新一代模型发布，使某个补偿性 Gene 不再必要时，该 Gene 的适应度会下降——不是因为有人给它贴上「补偿性」的标签，而是因为更简单的替代方案现在表现更好。Arena 通过竞争压力自动完成分类。
更深层的洞察：补偿性 vs 系统性不是代码的属性——而是代码适应度轨迹随时间变化的属性。 一个在模型升级中保持或提升适应度的 Gene 是系统性的。一个在更好模型发布后适应度崩溃的 Gene 是补偿性的。你不需要标签。你需要适应度函数和时间线。
这就是为什么我们拒绝在 Gene 元数据中添加「durability」字段。持久性不是静态属性——它是演化压力的涌现结果。提前声明它，就像要求一个物种预测自己的灭绝日期。
诚实的评估
补偿性工程不是坏工程。当你的生产 Agent 需要在今天的模型限制下工作，你就搭脚手架。这是务实的。这是交付。
但不要把脚手架当成建筑。分清你系统中哪些是承重墙，哪些是临时支撑。把最深入的思考投入到系统性的部分——上下文契约、组合规则、评估标准、信任边界——因为这些才是能复利增长的部分。
下一次模型升级会到来。到时候，你的一些代码会被删除。问题是，留下来的是否是真正重要的代码。
npm install -g @rotifer/playground
rotifer search --domain "content"链接：
- rotifer.dev — 框架与文档
如何判断你的工作是补偿性还是系统性的
一个简单的自检方法：问自己三个问题。
问题一：如果我明天离开，这个改进会继续发生吗？ 补偿性工作依赖于执行者的持续投入——你走了，改进就停了。系统性工作创造的是机制，不是依赖人。如果你的 prompt 优化策略只存在于你的脑子里，那它是补偿性的；如果它被编码为一个 Gene 并在 Arena 中持续被评估，那它是系统性的。
问题二：这个改进是否在帮助发现下一个问题？ 补偿性工作解决已知问题。系统性工作创造的是发现未知问题的能力。Arena 排名不仅告诉你哪个 Gene 最好，还通过竞争暴露了所有 Gene 的共同弱点——那些弱点就是下一个改进的方向。
问题三：这个改进的成本是递增的还是递减的？ 补偿性工作的成本通常随规模线性增长（甚至超线性）。更多 prompt 需要更多人审查、更多测试、更多维护。系统性工作的边际成本递减：Arena 评估 100 个 Gene 和评估 10000 个 Gene 的基础设施成本差异很小。
系统性工程的复利效应
补偿性改进是线性的：投入 2 倍努力，获得大约 2 倍改善。系统性改进是复利的：每一轮进化都建立在前一轮的基础上。
这就是为什么 Rotifer Protocol 选择了系统性路线。短期内，写一个好 prompt 比构建一个进化框架快得多。但 6 个月后，进化框架产生的累积改进会超过任何手动优化。12 个月后，差距会是数量级的。
复利效应的关键在于：选择压力必须是持续的、自动的、不依赖人工干预的。如果你每次都需要手动决定哪个方案更好，你就重新引入了补偿性元素。Arena 的价值正在于此——它是一个永不停歇的评估机制，让进化在你睡觉时也在发生。
- rotifer.ai — Gene Marketplace
- 协议规范 — 正式协议规范
- GitHub — 所有仓库
实践检验：你的工作在哪一层？
下次你开始一个 AI 项目时，花 5 分钟做这个练习：列出你计划做的所有任务，然后给每个任务标记「补偿性」或「系统性」。比例可能会让你吃惊：大多数团队 80% 的时间花在补偿性工作上。意识到这一点，就是转变的第一步。进化工程的目标不是消除补偿性工作，而是通过系统性工作减少对补偿性工作的依赖。每一个被系统化的补偿性任务，都是从线性成本向边际成本递减的转变——这是复利开始的地方。这种转变需要勇气——因为短期内系统性工作的回报是不可见的，但长期看它是唯一可持续的路径。补偿性思维让你越来越忙，系统性思维让系统越来越智能。选择权在你手中。越早转变，复利越大。
关于 Prompt、Context、Harness 和 Evolution Engineering 如何层叠为四个范式层，请阅读 Evolution Engineering: The Missing Discipline in AI。