最近看到一篇非常有意思的论文：

《The Missing Memory Hierarchy: Demand Paging for LLM Context Windows》

论文地址：

• The Missing Memory Hierarchy: Demand Paging for LLM Context Windows
• 原文：https://arxiv.org/abs/2603.09023

这篇论文的核心观点非常简单但极具启发性：

LLM 的上下文窗口，本质上是一个没有内存管理系统的“裸内存”。

如果把 LLM Agent 看成一个程序，那么当前的设计就像：

• 所有历史数据都一直留在内存里
• 每次执行都重新扫描整个内存
• 没有分页
• 没有缓存
• 没有工作集
• 没有淘汰策略

这显然是非常原始的。

论文作者做了一件很“操作系统味”的事情：

给 LLM 上下文加一个虚拟内存系统。

一、问题：LLM 上下文在大量浪费 token

作者首先做了一件很重要的事情：

分析真实生产日志。

数据来源：

• 857 个 Claude Code 会话
• 54,170 次 API 调用
• 总输入 token：4.45B

作者把每条消息拆成几类：

• 用户输入
• 模型回复
• 工具输出（read file / bash / etc）

然后统计：

• token 占比
• 使用频率
• 重复读取情况

结果非常惊人。

1 结构性浪费：21.8%

约 21.8% 的 token 是结构性浪费：

主要来自：

1️⃣ 工具定义

很多工具定义几千 token 但会话里从未调用。

却在 每一轮请求里重复发送。

2️⃣ 旧工具输出

比如：

Read file: file.py (10KB)

后续 80 轮对话里：

• 每一轮 API 调用
• 都重新发送这 10KB
• 都参与 attention

但实际 再也没被引用过。

3️⃣ 重复配置

例如：

• skill 列表
• agent 说明
• prompt 模板

经常被复制多份。

二、关键观察：工具输出会被“无限放大”

论文提出一个概念：

Amplification Factor（放大因子）

例如：

• 第 5 轮读取一个文件
• 文件大小 10KB
• 会话共 85 轮

那么这个文件会被：

重复发送 ≈ 80 次

放大因子：

80×

而每一次都要参与 attention 计算。

三、解决方案：给 LLM 上下文做“虚拟内存”

论文的核心系统叫：

Pichay

它的实现非常巧妙。

不是改模型。

而是：

在客户端和 LLM API 之间插一个代理。

架构如下：

IDE / Agent
      ↓
   Pichay Proxy
      ↓
   LLM API

代理负责：

• 统计 token
• 修改上下文
• 删除旧内容
• 必要时再恢复

模型和客户端完全无感。

四、核心思想：Demand Paging

作者把 LLM 上下文类比为操作系统内存。

1 淘汰策略（Eviction）

非常简单：

当一个工具输出满足：

大小 > 500B
且
超过 4 个用户回合未使用

就淘汰。

2 被淘汰的内容如何表示？

替换成一个 占位符：

[Paged out: Read file.py (8192 bytes). Re-read if needed]

模型如果需要：

就会再次调用工具。

3 Page Fault（缺页）

如果模型再次调用：

Read file.py

代理检测到：

刚刚淘汰过这个内容

于是：

• 重新读取文件
• 注入上下文

这就是：

LLM 的 page fault。

4 Fault-driven Pinning

如果某个页面：

被淘汰 → 发生缺页

说明淘汰太早。

系统就会：

pin 这个页面

以后不再淘汰。

除非：

文件内容发生变化

五、离线实验：删错概率极低

作者用 29 个完整会话做离线重放实验。

模拟：

如果当时删掉这些内容
后面会不会再用？

结果：

• 模拟删除：1,393,000 次
• 缺页：354 次

缺页率：

0.0254%

也就是说：

99.97% 的删除都是安全的。

六、在线实验：token 下降 37%

作者对比三种策略：

结果：

Trimmed
↓
token -22.6%

Compact + Trim
↓
token -37.1%

而任务：

• 全部完成
• 没有质量下降

甚至有些情况下：

回答质量更好。

原因很简单：

噪音减少，注意力更集中。

七、真实生产案例

作者把 Pichay 用在自己的开发环境。

Case A：正常开发

原始上下文：

剩余空间：7%

启用分页：

剩余空间：43%

删除：

15 个数据块

缺页：

1 次

几乎完美。

Case B：极端长会话

681 轮。

系统出现：

Thrashing（抖动）

删除 680 次
缺页 659 次

原因：

工作集太大。

不断：

删 → 读 → 删 → 读

类似操作系统的：

swap storm。

八、最重要的理论结论

传统操作系统：

缺页很贵

所以策略是：

尽量减少缺页

但 LLM 完全相反。

LLM 的成本模型

如果一个内容一直留在上下文：

每生成一个 token 都要重新计算 attention。

复杂度：

O(n²)

因此：

保留 token 的累计成本非常高。

而重新读取文件：

成本是：

O(n)

所以结论是：

在 LLM 中，宁可多一点 page fault，也不要保留太多 token。

九、这件事为什么很重要

这篇论文其实在说一件很大的事情：

未来的 LLM 系统必须有内存层级。

可以类比成：

当前 LLM 系统：

只有 L1。

十、未来方向

论文提出了很多值得研究的方向：

1 成本驱动的 eviction

不再看：

回合数

而是计算：

未来 attention 成本

2 phase-aware memory

识别：

planning phase
execution phase

不同阶段使用不同策略。

3 pin decay

当前：

缺页一次 → 永久 pin

未来：

pin 逐渐衰减

4 object-level memory

不再按：

文件
消息

分页。

而是：

决策
任务
debug 会话

十一、我的一些思考

这篇论文的最大价值是：

把 LLM memory 问题彻底系统化。

它告诉我们：

未来 AI Agent 的架构可能会像这样：

LLM
 ↓
Memory Manager
 ↓
Context Cache
 ↓
Retrieval System
 ↓
Persistent Memory

而不是：

LLM
 ↓
巨大 prompt

换句话说：

Prompt Engineering → Context Engineering

十二、总结

这篇论文最核心的发现：

1️⃣ 21.8% token 是结构性浪费

2️⃣ 简单分页策略缺页率只有 0.025%

3️⃣ token 使用减少 37%

4️⃣ 回答质量没有下降

5️⃣ LLM 的成本模型与传统虚拟内存完全相反

如果未来 LLM agent 真的要：

• 长时间工作
• 多工具协作
• 持续项目开发

那么：

Memory hierarchy 可能会成为 AI 系统的核心基础设施。

而这篇论文很可能会成为这个领域的 早期经典工作之一。

看完了？说点什么呢

—— OpenAI 如何用 Codex 构建一个 100 万行代码的系统

最近 OpenAI 工程团队分享了一篇非常值得工程师阅读的文章：

原文： https://openai.com/zh-Hans-CN/index/harness-engineering/

文章讲述了他们进行的一次实验：

构建一个真实的软件产品，但整个代码库没有一行代码是人工编写的。

所有代码，包括：

• 应用逻辑
• 测试
• CI/CD
• 文档
• 运维脚本
• 内部工具

全部由 Codex 生成。

而人类工程师只做一件事：

设计系统、约束和反馈循环。

最终他们用 3 个工程师 在 5 个月内构建了一个接近 100 万行代码的系统。

这篇文章其实揭示了一个重要趋势：

软件工程正在从 “写代码” 转变为 “设计 AI 能工作的系统”。

下面我把这篇文章的核心内容拆解出来，分析它对未来工程模式意味着什么。

一、实验：一个完全由 AI 生成代码的产品

OpenAI 团队从 一个空 Git 仓库开始。

初始架构由 Codex + GPT-5 自动生成，包括：

• 项目结构
• CI 配置
• 代码格式规则
• 包管理
• 应用框架
• AGENTS.md

甚至：

指导 AI 如何在仓库中工作的文档，也是 AI 写的。

5 个月后结果：

• 约 100 万行代码
• 1500+ Pull Request
• 团队只有 3 个工程师
• 平均 每人每天处理 3.5 个 PR

系统已经有：

• 内部日活用户
• 外部 Alpha 用户

换句话说：

这不是 Demo，而是一个真实运行的产品。

他们的核心原则是：

Humans steer, agents execute. 人类掌舵，AI 执行。

二、工程师角色发生了变化

在这个体系下：

工程师几乎不写代码。

工程师的工作变成：

1️⃣ 设计系统结构 2️⃣ 定义任务目标 3️⃣ 设计反馈循环 4️⃣ 构建 AI 能使用的工具

换句话说：

以前：

工程师 -> 写代码 -> 提 PR

现在：

工程师 -> 描述任务
      -> 运行 Agent
      -> Agent 提 PR
      -> Agent review
      -> 自动修复

整个流程类似这样：

Engineer
   ↓
Prompt
   ↓
Codex
   ↓
Open PR
   ↓
Agent Review
   ↓
Fix
   ↓
Merge

很多时候：

PR review 也是 AI 做的。

三、系统必须“对 Agent 可读”

一个非常重要的经验：

Agent 看不到的知识 = 不存在。

例如：

• Slack 讨论
• Google Docs
• 人脑记忆

对 AI 来说都是 不可见的知识。

因此他们做了一个关键决定：

把代码仓库变成唯一的信息来源。

所有内容都写入 repo：

• 架构文档
• 设计文档
• 产品规格
• 执行计划
• 技术债务
• 决策记录

目录结构大概是这样：

AGENTS.md
ARCHITECTURE.md

docs/
 ├ design-docs/
 ├ exec-plans/
 ├ product-specs/
 ├ references/
 ├ SECURITY.md
 ├ RELIABILITY.md
 └ QUALITY_SCORE.md

AI 通过这个结构：

• 找信息
• 推理系统
• 修改代码

他们称这种方式为：

Agent-readable repository

四、不要写 1000 行 prompt

他们曾尝试：

一个巨大 AGENTS.md

结果完全失败。

原因是：

1 情境窗口是稀缺资源

长文档会挤掉：

• 代码
• 任务
• 重要上下文

2 过多规则会失效

当所有东西都重要：

其实没有东西重要。

3 文档会腐烂

如果维护成本太高：

文档会变成：

过期规则的坟场

他们最后采用的方法是：

AGENTS.md 只做目录

类似：

AGENTS.md
  ↓
ARCHITECTURE.md
  ↓
docs/
  ↓
design-docs/

也就是：

给 AI 一张地图，而不是一本说明书。

五、架构必须严格

Agent 在这种环境下有一个特点：

会复制已有模式。

如果架构不严格：

代码会快速漂移。

因此他们强制使用：

严格分层架构

例如：

Types
  ↓
Config
  ↓
Repo
  ↓
Service
  ↓
Runtime
  ↓
UI

规则：

• 只能向下依赖
• 不允许跨层调用

所有规则通过：

• custom linter
• 结构测试

自动执行。

也就是说：

架构约束是机器执行的。

六、吞吐量改变了工程文化

Agent 写代码的速度远远超过人类。

这带来了一个新问题：

代码吞吐量远大于人类审查能力。

因此他们改变了传统工程文化：

以前：

严格 gate
必须 review
CI 必须通过

现在：

快速 merge
问题后修

因为：

等待的成本比修复更高。

七、AI 可以自动完成整个开发流程

随着工具完善，现在 Codex 已经可以：

自动完成整个开发流程：

1️⃣ 验证代码库状态 2️⃣ 复现 bug 3️⃣ 录制 bug 视频 4️⃣ 实现修复 5️⃣ 运行应用验证 6️⃣ 录制修复视频 7️⃣ 提 PR 8️⃣ 处理 review 9️⃣ 修复 CI 🔟 自动 merge

人类只在必要时介入。

八、新问题：AI 会制造“技术债”

完全 AI 开发会带来一个问题：

AI 会复制错误模式。

例如：

• 不一致的实现
• 不合理 abstraction
• 重复工具

他们最初的做法是：

每周五清理 AI 代码。

后来发现不可扩展。

最终解决方法是：

把工程原则写进代码。

例如：

• 禁止 YOLO parsing
• 强制 typed SDK
• 优先共享工具库

然后：

定期运行 Refactor Agent。

类似：

自动垃圾回收（GC）。

九、真正稀缺的资源：人类注意力

这篇文章最后总结了一句话：

软件工程的瓶颈不再是写代码，而是人类注意力。

未来工程体系的核心问题变成：

• 如何设计环境
• 如何设计反馈循环
• 如何设计约束系统

而不是：

写代码。

十、对未来软件工程的启示

这篇文章透露了一个非常重要的趋势：

软件工程正在进入：

Agent-first engineering

未来工程师更像：

系统设计师

而不是：

代码工人

未来的核心能力可能是：

• 架构设计
• Agent workflow
• 工程自动化
• feedback loop 设计
• 工程知识建模

而不是：

• 写 CRUD

结语

这篇文章其实说明了一件事：

AI 不只是写代码工具。

它正在改变：

软件工程本身的结构。

未来的软件团队可能会变成：

少量工程师
+
大量 AI Agent
+
高度结构化的代码仓库

而工程师的核心价值将变成：

设计 AI 能高效工作的系统。

看完了？说点什么呢

SWE-MiniSandbox: Container-Free Reinforcement Learning for Building Software Engineering Agents arXiv:2602.11210

近年来，**Software Engineering Agents（AI 自动修 bug / 改代码）**成为一个热门方向，例如：

• SWE-agent
• OpenHands
• Devin 类系统
• SWE-bench 等评测体系

但这类系统背后有一个 非常现实的工程问题：

如何为 AI agent 提供可执行代码、运行测试、修改仓库的隔离环境？

传统方案几乎全部依赖 Docker 容器。

然而容器带来了新的问题：

• 环境准备慢
• 镜像非常大
• 高并发训练成本高
• 需要 Docker / Kubernetes 基础设施

最近的一篇论文 SWE-MiniSandbox 提出了一种非常有意思的思路：

完全不使用容器，而是用 Linux 内核机制实现轻量隔离环境。

结果是：

• 存储占用减少 85%+
• 环境准备时间降低 75%
• RL 训练效果几乎一致

本文我们来系统分析这套系统。

一、问题背景：为什么 Docker 会成为瓶颈

在 SWE Agent 系统中，一个任务通常是：

1. clone GitHub repo
2. checkout 某个 commit
3. 安装依赖
4. 运行测试
5. agent 修改代码
6. 再次运行测试
7. 判断 patch 是否成功

为了防止：

• 不同任务互相污染
• 依赖冲突
• agent 执行危险命令

通常每个任务都会运行在 独立 Docker 容器里。

典型流程：

task -> docker container
     -> code repo
     -> python env
     -> run tests

但问题在于：

1 镜像体积巨大

很多 SWE-bench 任务的镜像：

1GB ~ 3GB

几十个任务就可能：

> 100GB

2 启动时间慢

容器启动 + 初始化环境：

~90 秒

3 RL 训练并发非常高

强化学习训练常见：

128 - 512 parallel environments

Docker 带来的开销就变得非常明显。

二、核心思想：用 Linux 内核替代容器

SWE-MiniSandbox 的关键思路是：

容器其实不是必须的。

很多隔离能力 Linux 内核本身就提供了。

论文选择了两个核心机制：

mount namespace
+
chroot

实现隔离 sandbox。

三、核心技术一：mount namespace

Linux 的 namespace 是容器技术的基础。

Docker 本质上就是组合了：

PID namespace
Network namespace
Mount namespace
User namespace
...

SWE-MiniSandbox只使用其中一部分。

mount namespace 的作用

它可以让一个进程：

看到 完全不同的文件系统挂载视图

例如：

主机目录

/
├── home
├── usr
└── data

sandbox 内看到：

/
├── repo
├── venv
└── tmp

每个 sandbox：

文件系统完全独立

四、核心技术二：chroot

chroot 是 Linux 非常古老但强大的功能。

它可以：

改变进程的 root 目录

执行：

chroot /sandbox/task_001

后这个进程看到的：

/ == /sandbox/task_001

所以：

/repo
/venv
/tmp

都变成了独立环境。

结合 mount namespace + chroot：

每个任务就像拥有一个 自己的 Linux 根目录。

但它仍然共享：

kernel
系统库
部分资源

所以非常轻量。

五、核心技术三：Python 环境复用

SWE-MiniSandbox 的另一个关键优化：

避免重复创建 Python 环境

传统 Docker：

每个镜像包含
OS
Python
依赖

体积很大。

MiniSandbox 的方案：

Step 1：共享 miniconda

宿主机安装：

miniconda3

Step 2：创建 venv

每个任务：

python -m venv

venv 结构：

venv/
  bin/
  site-packages/
  symlink -> python

很多文件其实是：

符号链接

所以体积只有：

~100MB

六、核心技术四：环境缓存

环境构建最慢的步骤是：

pip install
repo setup
test run

MiniSandbox 的做法：

预构建环境

第一次：

repo
+ venv
+ dependencies
+ tests

全部准备好后：

tar.gz

缓存。

之后每个任务只需要：

untar

就能直接使用。

七、核心技术五：I/O 并发控制

解压 tar 包其实是 磁盘 I/O 密集任务。

如果 100 个任务同时解压：

磁盘直接打爆

作者提出一个简单模型：

假设：

磁盘带宽 = B
每个解压 = bj

同时解压数量：

∑ bj ≤ B

实现方式：

Ray resource tags
+
semaphore

控制同时解压任务数。

八、系统架构

MiniSandbox 并不是单独系统，而是嵌入 SWE Agent 生态。

整体结构：

                +-------------------+
                |      SkyRL        |
                |  RL distributed   |
                +---------+---------+
                          |
                          |
               +----------v-----------+
               |      SWE-agent       |
               |   solve issues       |
               +----------+-----------+
                          |
                          |
                +---------v---------+
                |      SWE-Rex      |
                | terminal control  |
                +---------+---------+
                          |
                          |
                +---------v---------+
                |   MiniSandbox     |
                | mount + chroot    |
                +-------------------+

每个 sandbox：

repo
venv
terminal

九、实验结果

论文使用：

SWE-smith
SWE-bench Verified

1 存储节省

节省：

85%+

2 环境准备时间

加速：

~4x

3 rollout 时间

平均任务时间：

Docker       ~350s
MiniSandbox  ~250s

明显更快。

4 训练效果

论文引入指标：

Reward MD (Mean Deviation)

衡量：

两种框架训练的 reward 差异

结果：

≈ 0

说明：

RL 训练信号几乎一致。

十、为什么这项工作重要

这篇论文并没有提出新的 AI 模型。

但它解决了一个 非常关键的系统问题：

如何低成本运行 SWE agents。

它带来的影响可能是：

1 降低研究门槛

很多团队没有：

Docker cluster
Kubernetes

MiniSandbox：

普通 Linux 服务器
+
Python

即可运行。

2 大规模 RL 更可行

强化学习非常依赖：

并行环境数量

环境越轻：

rollout 越快

训练成本就越低。

3 企业部署更容易

企业内部：

CI
测试
自动修 bug

很多场景其实不需要：

完整容器

MiniSandbox 更轻。

十一、局限性

论文也非常坦诚地指出问题。

1 安全隔离不如容器

MiniSandbox 只有：

mount namespace
chroot

而 Docker 还有：

cgroup
seccomp
user namespace
capabilities

所以安全性略弱。

2 Python 项目为主

实验主要集中：

Python repos

对于：

C++
Rust
Java
复杂 build system

仍需验证。

3 I/O 仍然是瓶颈

即使优化后：

repo copy
venv copy
untar

仍然消耗较多时间。

未来可能用：

overlayfs
copy-on-write

进一步优化。

十二、我的一些思考

这篇论文最有意思的地方是：

很多 AI 系统瓶颈其实不是模型，而是系统工程。

SWE agent 的发展：

模型能力
+
工具链
+
环境系统

缺一不可。

MiniSandbox 本质上是在做：

AI infra optimization

类似于：

RL environment acceleration

如果未来：

• SWE agents
• Devin 类系统
• 自动代码修复

大规模部署，

这种 轻量 sandbox 很可能成为新的基础设施。

总结

SWE-MiniSandbox 的核心贡献可以总结为一句话：

用 Linux 原生隔离 + Python 环境缓存，替代 Docker 容器，构建轻量级 SWE agent 运行环境。

带来的收益：

• 存储降低 85%+
• 环境准备 4x 加速
• RL 训练效果 几乎一致

这说明：

在 AI 系统工程里，很多时候 更好的系统设计比更大的模型更重要。

看完了？说点什么呢

Structurally Aligned Subtask-Level Memory for Software Engineering Agents
Kangning Shen, Jingyuan Zhang, Chenxi Sun et al.
arXiv:2602.21611 (2026)
🔗 原论文地址：https://arxiv.org/abs/2602.21611

✨ 一句话总结

这篇论文解决的是：

❌ 过去：AI 只会“按整道题记经验”，容易误用
✅ 现在：AI 按 推理步骤 记经验，只在对应阶段调用 → 更稳、更准、更能复用

在 SWE-bench Verified 上：

• 平均提升 +4.7% Pass@1

• 困难任务最高 +8.7%

• 同时 显著降低结果波动

对于一个已经很难提升的 benchmark，这个增幅非常有含金量。

🧠 问题背景：为什么现有 Agent 的“记忆”不好用？

现在很多 SWE Agent 的记忆方式是这样的：

做完一个 issue → 写一份完整复盘 → 下次找“最像的一题”

问题在于：

看起来像 ≠ 推理过程一样

例如：

文本都包含 “login”，但解决路径完全不同。

这会导致：

• 检索到错误经验

• 强模型反而被误导

• 性能波动变大

🧩 核心思想：记忆必须和推理结构对齐

软件工程任务天然是分阶段的：

1. ANALYZE — 分析问题

2. REPRODUCE — 复现 bug

3. EDIT — 修改代码

4. VERIFY — 验证修复

论文的核心设计：

不再按“整道题”记
而是按“子任务阶段”记

🗂 新的记忆单元长什么样？

每条记忆变成三元组：

(z, d, e)

1️⃣ z：阶段标签

例如：

• ANALYZE

• EDIT

• VERIFY

2️⃣ d：当时的小目标（意图）

结构化描述：

• 当前要解决什么

• 关键线索（函数名 / 报错）

3️⃣ e：抽象经验

不是存全过程，而是提炼：

✅ 可迁移策略
❌ 仓库特有细节

例如：

当 a+b 正常但 b+a 报错 → 检查 radd

这就是可以跨项目复用的经验。

🔍 检索机制：只在“当前阶段的抽屉”里找

传统方式：

在整个记忆库做语义相似度匹配 ❌

论文方式：

先按阶段过滤
再做语义匹配

效果：

• 避免跨阶段干扰

• Top-1 检索也足够稳

🧠 经验是如何产生的？

在子任务结束时做一次 反思：

成功 → 总结套路
失败 → 总结反模式

然后抽象成经验卡片写入记忆。

这是一个 在线自进化系统：

做的任务越多 → Agent 越像老员工

📊 实验结果

总体表现

在 SWE-bench Verified：

对强模型的影响

实例级记忆：

• 性能下降

• 方差变大 ❌

子任务级记忆：

• 性能提升

• 更稳定 ✅

说明：

强模型不怕没记忆
怕错误记忆

对困难任务的提升最大

按轨迹长度划分：

因为困难任务最依赖经验复用。

🧪 关键消融实验

❌ 只强制分步骤思考（不存记忆）

仅 +1%

→ 真正的提升来自“经验复用”

❌ 不按阶段分类检索

提升只剩 +1.6%

→ 阶段对齐是关键

❌ 存原始轨迹

提升 +1.2%

→ 必须做抽象

🏗 工程视角：这件事为什么重要？

这篇论文最有价值的地方在于：

不需要训练新模型
只靠系统设计就能提升

现实系统可以直接复用：

• Cursor / Devin 类 Agent

• 企业内部 Code Agent

• 自动化修复 Bot

对团队的意义

AI 不再是：

每次都从零开始的实习生

而是：

会积累项目经验的老员工

带来的变化：

• 更快修复重复问题

• 更稳定的 CI 自动修复

• 更低的 onboarding 成本

🌍 这套范式可以迁移到所有 Agent

不仅限于写代码：

数据分析 Agent

阶段：

• 理解需求

• 找数据

• 建模

• 解释结果

客服 Agent

阶段：

• 澄清问题

• 查政策

• 给方案

• 跟进

科研 Agent

阶段：

• 检索文献

• 提出假设

• 设计实验

• 分析结果

⚠️ 局限性

论文目前还没有解决：

1️⃣ 记忆无限增长问题

需要：

• 淘汰机制

• 压缩

• 分层记忆

2️⃣ 错误经验污染

现在的系统：

写进去就信

未来必须解决：

• 记忆可信度

• 自动降权

• 版本控制

3️⃣ 子任务划分仍是手工设计

未来方向：

自动学习阶段结构

🔮 未来值得关注的方向

我认为最有潜力的三个：

1️⃣ 记忆治理系统

类似：

• Git for memory

• memory diff / rollback

2️⃣ 多 Agent 共享经验库

团队级 AI 知识沉淀。

3️⃣ 长期运行的代码管家

真正的：

AI 老员工

🏁 我的评价

这篇论文的价值在于：

它不是做了一个更大的模型
而是回答了一个更本质的问题：

Agent 应该“如何学习经验”

这是：

LLM → 真正智能体
过程中非常关键的一步。

📌 Takeaway

如果你正在做 Agent 系统，这篇论文给了一个可以直接落地的设计原则：

✅ 正确的记忆设计

• 记忆单位 = 推理子任务

• 只存抽象经验

• 检索必须阶段对齐

而不是：

• 存整段对话

• 全局相似度检索

🧵 最后

如果你在做：

• AI 编程工具

• 企业代码 Agent

• 自动化修复系统

这篇论文属于：

可以直接改系统设计的那种工作

而不是“只在 leaderboard 上多 1%”。

看完了？说点什么呢

最近看到宝玉叔分享的一场来自 Pragmatic Summit 的演讲总结，主讲人是 DX 公司 CTO、Core 4 开发者生产力框架的联合作者 Laura Tacho。

她手里有一份非常恐怖的数据集：

• 12 万开发者
• 450+ 公司真实样本

这不是方法论，而是基于真实组织行为的数据科学结论。

这篇文章最有价值的点在于： 👉 它重新定义了“开发效率到底是什么”。

一、开发者生产力的误区

很多公司衡量研发效率的方式：

• 写了多少行代码
• 提交次数
• 需求完成数量
• 工时利用率

这些指标有一个共同问题：

❌ 衡量的是「忙碌程度」 而不是「价值交付能力」

真正的问题是：

我们如何更快、更稳定、更可持续地把价值交付到用户手里？

二、Core 4：开发者生产力的四个核心维度

Core 4 并不看“人写了多少代码”，而是看系统是否高效。

1️⃣ 速度（Speed）

不是单纯的快，而是：

• 从 idea → production 的时间
• PR 合并周期
• 发布节奏

核心问题：

组织是否能快速把想法变成可运行的软件？

2️⃣ 易用性（Ease）

开发环境是否顺滑：

• 本地启动是否痛苦
• CI 是否经常炸
• 调试是否困难

这直接决定：

🧠 开发者每天有多少时间在“真正创造价值”

3️⃣ 质量（Quality）

不是测试覆盖率，而是：

• 变更失败率
• 线上回滚频率
• 修复周期

高质量团队的特点：

👉 发布更频繁 👉 反而更稳定

4️⃣ 影响力（Impact）

这是最容易被忽略的：

开发者是否在做：

• 高价值项目
• 对业务真正重要的事情

而不是被：

• 低效流程
• 组织阻塞
• 技术债

消耗掉。

三、一个反直觉的关键结论

数据表明：

提升开发者生产力 ❌ 不是靠压榨个人 ✅ 而是优化系统体验

真正高效的公司在做的是：

• 投资 DevEx（开发者体验）
• 优化 CI/CD
• 减少等待时间
• 自动化流程

而不是：

❌ 强制加班 ❌ 增加 KPI ❌ 用绩效驱动代码产出

四、AI 时代对研发效率的真正影响

这部分是我认为最值得思考的。

AI 确实在提升：

• 写代码速度
• 生成样板代码能力

但 Core 4 的视角会告诉你：

如果你的系统存在这些问题：

• 发布流程 2 天
• CI 30 分钟
• 环境初始化半天
• 需求评审一周

那么：

🤖 AI 只能让你更快写完 ⛔ 但无法让你更快交付

五、高绩效团队真正的投资方向

数据中表现最好的团队有几个共同点：

✅ 极度重视开发者体验

把 DevEx 当作产品在做。

✅ 减少“等待时间”

包括：

• 等 CI
• 等评审
• 等环境
• 等权限

等待 = 最大的生产力黑洞

✅ 小批量、高频发布

这会带来：

• 更低风险
• 更快反馈
• 更高稳定性

六、对个人开发者的启示

很多人关心：

AI 会不会取代程序员？

但从这个模型看，真正的分水岭变成了：

初级开发者

只会：

• 写代码
• 完成功能

高级开发者

会：

• 优化交付流程
• 设计工程系统
• 提升团队整体效率

未来最值钱的能力不再是：

❌ 写代码速度

而是：

✅ 提升系统生产力的能力

七、总结

Core 4 的本质是在说一件事：

开发者生产力是一个系统问题，而不是个人问题。

真正决定效率的不是：

“你有多努力”

而是：

• 工程体系是否顺滑
• 组织是否减少阻力
• 工具链是否现代化

最后的思考

在 AI 时代，一个非常重要的认知转变是：

个人写代码的速度正在被抹平 但：

🏗 构建高效工程系统的能力 正在成为核心竞争力

这可能才是软件工程的下一个分水岭。

看完了？说点什么呢

最近，AI 创业者 Matt Shumer 写了一篇标题颇具张力的文章：

Something Big Is Happening

标题看起来像危言耸听，但读完之后，我反而觉得值得认真对待。

这篇文章真正讨论的，并不是“AI 会不会变强”，而是一个更重要的问题：

AI 是否已经跨过了一条能力分界线？

1. 从“辅助工具”到“任务执行者”

过去两年，大多数人对 AI 的理解停留在一个工具层面：

• 帮你写代码
• 帮你润色文章
• 帮你总结文档
• 帮你生成脚本

它很强，但仍然需要频繁的人类介入。

Shumer 的判断是： 最近模型的变化，已经从“能力增强”转向“能力形态改变”。

关键区别在于：

• 能否持续执行多步骤任务
• 能否发现自身错误并修复
• 能否在没有人工干预的情况下完成目标

如果一个系统可以完成任务闭环，那么它的角色就不再只是工具。

2. 为什么他说这是“质变”

文章中提到几个信号：

（1）模型开始参与模型研发

像 OpenAI、Anthropic 这样的机构，已经在使用模型辅助代码生成、测试与评估流程。

这意味着：

AI 不只是被训练的对象，它开始参与自身的改进。

这在技术史上具有象征意义。

工具开始成为生产工具的组成部分。

（2）认知型任务的边际成本快速下降

过去十年，自动化主要替代的是：

• 重复劳动
• 流水线作业
• 标准化操作

而现在，AI 正在逼近的是：

• 分析
• 推理
• 写作
• 编程
• 决策支持

也就是说，它触及的是“认知层工作”。

这才是这篇文章真正令人不安的地方。

3. 但我们需要避免技术情绪化

我并不完全认同那种“马上全面替代”的叙事。

历史上每一次技术跃迁都经历了三个阶段：

1. 技术突破
2. 应用验证
3. 结构重构

现在显然处在第一阶段向第二阶段过渡的时期。

真实世界仍然存在：

• 成本约束
• 可靠性问题
• 系统整合难度
• 法律与监管
• 企业流程惯性

技术能力的出现 ≠ 立刻改变产业结构。

4. 真正重要的不是“替代”，而是“结构变化”

我更关心的是一个趋势：

认知工作的边际成本正在下降。

当认知成本下降，会带来什么？

• 小团队能力上限提升
• 个人生产力极大放大
• 创业门槛降低
• 决策周期缩短

这意味着竞争模型会变化。

可能不是“你失业”， 而是“你所在的组织结构被重写”。

5. 对个体的现实意义

如果你是知识型工作者：

• 程序员
• 产品经理
• 研究员
• 分析师
• 内容创作者

真正值得思考的问题不是：

AI 会不会替代我？

而是：

在 AI 存在的情况下，什么能力仍然具有稀缺性？

可能包括：

• 判断力
• 系统性思维
• 抽象建模能力
• 多领域整合能力
• 复杂问题拆解能力

执行层的价值可能会压缩， 结构层的价值可能会上升。

6. 也许我们低估的不是风险，而是速度

这篇文章最值得重视的一点，并不是它的语气，而是它的判断：

能力跃迁往往不是线性的。

当模型跨过某个阈值时， 它带来的变化会突然显现，而不是渐进体现。

如果这一判断成立，那么真正的挑战不是技术本身，而是：

我们的认知是否跟得上技术曲线。

结语

这篇文章并不是一篇技术论文。 它更像是一种时代感知。

也许时间线会比作者预想得慢。 也许某些行业的变化会更温和。

但有一点越来越清晰：

AI 已经不再处在“实验玩具阶段”。

它正在进入真实生产环境。

真正危险的不是 AI 太快。 而是我们对变化的感知太慢。

看完了？说点什么呢

1. LLM 最简原理：它在做什么？

LLM（Large Language Model）本质上做的是一件事：

给定上下文，预测下一个 token 是什么。

它不断生成 token 并拼接成文本，因此看起来能“对话”“写作”“编程”。底层关键架构是 Transformer，依靠 Attention（注意力机制） 在上下文里动态关注关键信息。

图 1：LLM 的生成过程（Next-token prediction）

工程上要牢记：LLM 的目标是生成“最可能的文本”，不是保证“事实正确”，所以会出现 幻觉（Hallucination）。

2. Function Call：让模型能“调用工具”

Function Call（函数调用） 让 LLM 不只是输出自然语言，而是输出结构化参数（常见 JSON），由系统执行真实工具/API，再把结果返回给模型总结。

图 2：Function Call 的基本闭环

意义：

• 避免模型瞎编实时信息

• 输出可校验、可重试

• 多次调用可串联成流程

3. MCP：Function Call 之后的“标准工具接入层”

当工具变多，难点从“能不能调用”变成：

如何规模化、标准化地把工具暴露给模型？

MCP（Model Context Protocol） 提供统一的工具/数据源/上下文暴露方式，让模型用一致方式发现、理解、调用。

图 3：没有 MCP vs 有 MCP（接入复杂度对比）

一句话：

• Function Call 是“怎么调用一次工具”

• MCP 是“怎么把一堆工具接入做到标准化、可扩展、可管理”

4. Agent：LLM + 多步规划 + 工具循环

Agent 是把 LLM 变成“任务执行体”的系统形态。典型循环是：

1. 理解目标

2. 规划步骤

3. 调用工具

4. 观察结果

5. 迭代直到完成

图 4：Agent 的多步执行循环（Plan-Act-Observe）

Agent 的挑战更像系统工程：失败重试、成本控制、权限与安全、结果验证等。

5. Skills：Agent 的“可复用技能模块”（按 Claude Code 定义）

在 Claude Code 体系里，Skill可以理解为：

把某类能力写成标准化的“技能说明书”，让模型在合适时自动使用，或用户手动触发（例如 /skill-name）。

Skill 通常通过 name/description 等元信息描述“何时用、怎么用”，把经验沉淀成可复用模块，让能力更产品化、更可控。

图 5：Skills 在系统中的位置（沉淀与复用）

6. 一句话串起来

LLM 负责理解与生成；Function Call 让它能可靠调用工具；MCP 让工具接入标准化；Agent 用多步规划把工具串成任务；Skills 则把这些能力沉淀成可复用技能库，让系统更稳定、更可控、更易扩展。

看完了？说点什么呢

Agent 并不是突然出现的，它更像是 Prompt Engineering 一路“堆能力”的自然结果。在 Agent 之前，我们主要靠提示词让 LLM 更稳定地完成复杂任务，演进大致经历以下阶段：

0）Role：最早期的“角色设定”

最经典、最早期的提示方式是 Role Prompt：

“你是一个资深产品经理 / 你是一个资深 SRE / 你是一个代码审查专家……”

它的作用是给模型一个行为边界与输出风格，让回答更贴合领域语境，例如：

• 语气更专业

• 输出结构更像行业习惯

• 更倾向于该角色的关注点（风险、边界、指标等）

局限： Role 只能改变“说话方式和偏好”，并不会真正提高事实可靠性或执行能力。

1）Step by Step：让模型显式分步

随后常用的是：

“请一步一步思考 / Step by step”

它能显著提升复杂任务的完成率：模型会先拆解再回答，减少跳步错误。

2）Few-shot：用示例教会模型“套路”

Few-shot Prompt 是提供几个示例（输入→输出），让模型学习：

• 输出格式（如 JSON / 表格）

• 解决套路（如对比、分类、总结）

• 任务边界（什么该输出，什么不要输出）

3）Thinking：从“答案”到“推理过程”

再进一步，我们希望模型不仅给结论，还能给 reasoning / thinking：

• 让复杂任务更稳定

• 更利于 debug（知道它为什么这么做）

4）ReAct：把“思考（Reason）”和“行动（Act）”结合起来

ReAct（Reason + Act）是从 Prompt 到 Agent 的关键跃迁：

• Reason：决定下一步做什么

• Act：调用工具（搜索、数据库、API）并获取结果

这让 LLM 从“会推理”变成“会执行”。

5）Agent：多步循环 + 工具 + 状态

当 ReAct 再加上：

• 多轮循环（Plan-Act-Observe）

• 状态/记忆（Memory）

• 失败重试与校验

就形成了我们今天说的 Agent。

图：从 Prompt Engineering 到 Agent 的演进路径

 flowchart LR  

R[Role Prompt] --> A[Step by Step]  
A --> B[Few-shot Examples]  
B --> C[Thinking / Reasoning]  
C --> D[ReAct: Reason + Act]  
D --> E[Agent: Multi-step loop + Tools + Memory]

小结（可作为补充结尾）

从 Role 到 Step-by-step、Few-shot、Thinking，本质是在增强 LLM 的“表达质量与推理稳定性”；而从 ReAct 开始，模型被赋予了“行动能力”，再叠加循环与状态管理，就自然演进成 Agent 系统。

看完了？说点什么呢

在跨境电商搜索里，多语言相关性一直是个又重要又难搞的问题。

英语模型强，不代表它懂泰语；
懂泰语的模型，可能又看不懂东南亚常见的“混合语言 query”；
而现实世界的用户，偏偏就爱这么搜。

最近一篇来自 Lazada 的论文给了一个非常工程化、可落地的答案：
与其训练一个越来越大的“万能模型”，不如让多个各有所长的大模型协同工作。

这篇文章，我想用尽量少的公式、尽量多的直觉，讲清楚他们到底做了什么，以及为什么这套方案值得做搜索/推荐/广告的团队认真看一眼。

一、问题背景：一个大模型，真的能覆盖所有语言吗？

在多国家、多语言电商平台中，搜索 query 往往有这些特点：

• 语言混杂（本地语言 + 英文品牌）

• 低资源语言多（泰语、越南语、印尼语等）

• query 很短，语义高度依赖文化和习惯

现实中的情况是：

• Qwen 这类模型英文、中文很强

• Sailor 这种模型在东南亚语言上更有优势

• Gemma 在某些商品理解上又更稳

👉 没有一个模型在所有语言、所有市场都同时最强。

那直觉上的做法就来了：

那我多用几个模型，一起算不就好了？

问题是：“一起算”这件事，其实非常容易做错。

二、为什么「简单模型融合」反而会翻车？

很多工程实践里的“多模型融合”，是这么干的：

• 多个模型各自算一个 embedding

• 然后 加权平均（weighted sum）

• 再拿去做打分或分类

这在同构模型（同结构、同 tokenizer）下可能还凑合，但在这篇论文的设定里：

每个专家模型，结构不同、训练数据不同、embedding 空间完全不对齐

作者用了一个非常形象的比喻：

• 模型 A 的 x 轴表示「颜色」

• 模型 B 的 x 轴表示「材质」

• 你把这两个 x 轴直接加起来 —— 语义直接乱套

结果就是：

• 有用特征互相抵消

• embedding 变得“糊成一团”

• 效果甚至 不如用单一模型

👉 这篇论文一个非常重要的观点是：

多模型 ≠ 简单 ensemble，异构模型必须尊重“表示空间不同”这个事实。

三、核心思路：多位 LLM 专家 + 智能调度 + 保持各自表达

他们的整体方案可以概括成一句话：

冻结多个大模型作为“专家”，用一个轻量路由器挑人干活，再用“拼接而非加权”的方式融合专家意见。

拆开来看，有三步。

1️⃣ 多个冻结的 LLM 专家

先准备好几位“专家模型”，比如：

• Qwen2.5-14B

• Gemma2-9B

• Sailor2-20B

它们：

• 用同一份搜索数据各自微调一轮

• 然后 参数全部冻结

• 后续不再改动模型本体

这样做的好处是：

• 模型稳定、可控

• 不需要搞复杂的 MoE-aware 微调

• 非常适合已有多个 LLM 资产的团队

2️⃣ 请求级稀疏路由：只找最合适的专家

不是每个 query 都要叫上所有专家。

作者设计了一个轻量路由器，输入是：

• 用户 query

• 商品标题

• 国家 / 地区信息

输出是：

• top-k（比如 2 个）最合适的专家

关键点：

• 路由是 端到端训练的

• 使用 Hard Routing（训练和推理一致）

• 加了 负载均衡损失，防止所有流量都挤到一个专家上

结果是：

• 每条请求只激活少数专家

• 效果更好、延迟更低

• 吞吐率明显提升

👉 实验表明：
“挑对人干活”，比“所有人都发言”更重要。

3️⃣ 关键创新：拼接，而不是加权融合

这是全文最有价值、也最容易被忽略的一点。

流程是：

1. 每个被选中的专家输出一个向量

2. 各自先做线性投影（只对齐维度，不强行对齐语义）

3. 直接拼接（concatenation） 成一个大向量

4. 用一个小 MLP 学“怎么综合这些意见”

直觉理解是：

• 向量前一段：专家 A 的世界观

• 向量后一段：专家 B 的世界观

• 两者互不干扰

• 决策层来学：什么时候信谁、怎么联合判断

论文用 t-SNE 可视化清楚地展示了这一点：

• 拼接后的 embedding：正负样本清晰分离

• 加权融合的 embedding：纠缠在一起，边界模糊

👉 这在工程上非常重要的启示是：

不要强迫异构模型共享一个语义坐标系。

四、工程落地：离线 MoE，当“超级老师”

当然，现实世界里你不可能：

• 在线对每个 query 调多个 10B+ 的大模型

他们的解法非常务实：

1. 离线用 MoE / LLM 做高质量相关性打分

2. 用这些打分作为 teacher

3. 蒸馏训练一个小而快的学生模型（ColBERT）

4. 线上只跑学生模型

结果是：

• MoE 不仅自己效果好

• 作为 teacher 反而比单一 LLM 更稳健

• 学生模型在真实线上流量中：

  • Bad Ratio 更低

  • AUC 更高

👉 多专家 MoE 的价值，不只是“直接上线”，
而是提升整个检索系统的知识上限。

五、这篇论文真正值得抄的地方

如果你在做搜索 / 推荐 / 广告相关性，我认为有三条非常实用的结论：

✅ 不要迷信“一个更大的模型”

在多语言、多区域场景下，
专家协同 > 单模型扩规模

✅ 异构模型融合，几何结构比参数更重要

• Weighted sum 很可能是错的

• 拼接 + 小 MLP 是一个简单但有效的工程解法

✅ 把复杂留在离线，把简单留给线上

• 离线：多专家 + 路由 + 融合

• 在线：蒸馏后的小模型

• 是一条非常可复制的工业路径

六、写在最后

这篇论文最难得的地方在于：

• 问题来自真实业务

• 方法不过度理想化

• 工程细节说得足够清楚

• 指标提升有实际业务意义

它传递了一个很重要的信号：

在大模型时代，
如何组织和协作已有模型，可能比继续堆参数更重要。

如果你手上已经有多个微调过的 LLM，
这篇论文，真的值得你认真读一遍。

看完了？说点什么呢

一句话总结：MixLM 让大模型参与搜索排序不再“贵到用不起”，通过把长文本离线压缩成 embedding token，在线只让 Ranker 看 query + 少量向量，就能把吞吐提升 10×～75×，还保持接近全文本排序的效果。

论文原文

1. 背景：为什么“用 LLM 排序”这么难上线？

很多人做过类似尝试：

• 把 query + 候选 item（比如职位描述、商品详情、文章正文）拼起来

• 丢给 LLM 问：“这个 item 和 query 相关吗？”

• 用 LLM 的 yes/no 或打分当排序依据

这方法确实强，因为 LLM 擅长理解语义、意图、上下文。

但它几乎注定上线困难，原因很现实：

问题 1：输入太长

item 文本经常上千 token（职位描述、商品详情都很长），每个 item 都要重复喂一次。

问题 2：计算量爆炸

Transformer 注意力复杂度 ~ token²
token 一长，成本直接炸裂。

问题 3：线上排序是“一次对几百上千个 item”

搜索排序不是问一次问题，而是：

同一个 query 要对几百～几千个候选 item 打分

所以成本会乘以 item 数量，完全扛不住。

2. MixLM 的核心思想：别让 Ranker 在线读全文

MixLM 其实干了一件非常工程化但很聪明的事：

把 item 的长文本提前离线压缩成少量“向量 token”，在线只喂这些 token 给 LLM。

传统方案（全文本 cross-encoder）

Ranker 输入：

系统提示 + query + item 全文

每个 item 都是一大串。

MixLM（text-embedding mix-interaction）

把排序拆成两步：

Step A：离线 Encoder 压缩 item

用 Encoder LLM 把 item 全文 → embedding tokens（比如 1 个 token）

Step B：在线 Ranker 只看 query + embedding tokens

Ranker 输入：

query 文本 + item embedding tokens

类比：
以前是“面试官每次都从头看完整简历”
现在是“简历提前被浓缩成几行摘要，面试官只看摘要 + 岗位需求”

3. 为什么这种压缩不会严重掉效果？

直觉上你可能会怀疑：

item 全文没了，只剩 1 个 embedding token，Ranker 怎么理解 item？

MixLM 的关键不在结构，而在训练方法：

不是随便做 embedding，而是让 Encoder 和 Ranker 在强监督下共同训练，并强制对齐。

他们用了一个非常“老师带学生”的训练 pipeline。

4. 训练策略：三阶段老师-学生体系（最精华的部分）

MixLM 的训练可以理解为：
先培养一个“超级懂业务的大老师”，再让学生模型继承能力，最后再学会用 embedding 版本输入。

Stage I：先教小模型“怎么思考”（领域推理微调）

他们先训练一个 7B judge 模型，让它对 query-item 打 0～4 分，并写推理理由（类似 CoT）。

然后用它去蒸馏一个 0.6B 小模型：

让小模型学会 judge 的“思考方式 + 打分倾向”

这一步的意义是：
让 Ranker 先具备领域推理能力，否则后面训练会很难。

Stage II：训练一个效果极强的“全文本 Teacher Ranker”

接着用 Stage I 的小模型，喂入完整文本训练 cross-encoder 排序器：

输入：

系统提示 + query + item 全文

输出：

yes/no 概率

它效果很强（NDCG@10 0.9432），但太慢不能上线。

于是它变成“teacher”。

Stage III：真正训练 MixLM（embedding 输入版）

这一步才是 MixLM：

• Encoder：负责 item 全文 → embedding tokens

• Ranker：负责 query + embedding tokens → relevance score

并且用三种损失把它拉住：

1. SFT（软标签监督）：对齐 7B judge 的打分倾向

2. Distillation（蒸馏）：对齐全文本 teacher 的输出分布

3. Self-alignment（自对齐）：强制 “embedding 输入” 和 “全文本输入” 在 Ranker 内部表征一致

这一步非常关键：

不是让 Ranker 自己适应 embedding，而是用强约束避免它“脑回路跑偏”。

5. 系统工程：不止模型结构，吞吐靠工程榨出来

MixLM 另一大亮点是：它不是停在论文结构，而是把系统做到了生产级。

关键工程点 1：共享 query 前缀（prefix KV cache）

同一个 query 对几百个 item：

• query 部分完全一样

• 只需要算一次 prefix KV cache

• 后面 item 只算 suffix

这能省掉巨量重复计算。

关键工程点 2：多 item 一次性打分（multi-item scoring）

把多个 item suffix 串起来，做 attention mask 阻止跨 item 信息泄露。

这样 GPU batch 利用率更高。

关键工程点 3：接口直接支持“文本 + embedding”

他们把 embedding 作为 gRPC 请求字段传给服务端：

避免 server 重复算 embedding，也方便 embedding 缓存

6. 效果怎么样？（论文最硬的结果）

Offline 指标（排序质量）

• Full-text teacher：NDCG@10 = 0.9432（最强但慢）

• MixLM：NDCG@10 = 0.9239（略低但很接近）

• embedding retrieval：0.8380（明显差）

• summarized+pruned：0.9218（接近 MixLM）

结论：MixLM 基本保住了 cross-encoder 的交互能力。

Online 线上指标（工业价值）

• 吞吐：22,000 items/s/GPU（H100，500ms 延迟预算）

• 相比 full-text LLM：75.9× 提升

• 相比 summarized-text：10× 提升

• LinkedIn 全流量 A/B：DAU +0.47%

0.47% 可能看着不大，但在 LinkedIn 这种体量上非常可观。

7. 这篇论文最值得借鉴的点

我认为它最大的价值是：给了一个“LLM 排序可落地”的标准模板。

关键 takeaway

1）不要让 LLM 在线读长文本

把长文本变成可预计算的压缩特征（embedding tokens）

2）embedding 不等于“直接用向量”

要让 Encoder 和 Ranker 联合训练，并且对齐内部表征

3）真正的吞吐来自系统工程

KV cache、batch、prefix sharing、服务栈优化缺一不可

8. 局限与适用场景

局限

• 需要大量数据、强 teacher/judge

• pipeline 复杂，工程门槛高

• token 压缩太狠时（1 token）可能丢细粒度语义

适用场景

非常适合：

• 搜索排序（job/product/doc）

• 推荐排序（feed、内容）

• 广告候选重排

• 任何 item 文本长、候选多的 rerank 场景

9. 结语

过去业界对“LLM 排序”的普遍结论是：

效果好，但太贵，上不了全量。

MixLM 的贡献在于证明了另一条路：

LLM 排序不是只能做小流量实验，它可以通过结构 + 蒸馏 + 系统优化变成工业级能力。

如果未来搜索/推荐要全面 LLM 化，MixLM 这种“模型 + 训练 + serving 一体化设计”的路线，很可能会成为主流范式。

看完了？说点什么呢