shaoyou

Agent 的交互就是流式事件处理——用数据库的思想重新设计 Agent 技术栈

Sun, 28 Jun 2026 00:00:00 GMT

Agent 的交互就是流式事件处理——用数据库的思想重新设计 Agent 技术栈

TL;DR：Agent 需要的实时交互、持久记忆和经验复用，在传统 Request/Response 架构下全做不出来。因为它们本质上都是流式事件处理问题。Bojie Li 的六篇论文沿着同一条哲学——changelog + checkpoint——把它们一层层拆开解决。每一步都不是凭空设计，而是从一个失败尝试出发，发现底层机制，再推出方案。

假定读者：理解 Transformer 的基础架构（Attention、FFN、KV Cache）。如果你需要从 GPT-2 级别复习，文末有完整的架构拆解参考。

引子：Agent 需要 ChatGPT 做不到的三件事

想象你要做一个真正的个人助理 Agent——它会陪你一个月，帮你订机票、处理邮件、管理日程。它需要 ChatGPT 做不到的三件事：

第一，实时交互。 你跟它说话时它能被打断，它觉得有事要告诉你时会主动开口。你不可能每次交互都像跟 ChatGPT 聊天那样，把完整问题打好了发过去等回复。

第二，长期记忆。 你月初告诉它你对花生过敏，月底点菜时它得记住。你飞了 100 趟航班，问它"去年飞了几次去东京"，它应该一秒算出来，而不是把你 100 条飞行记录全塞进上下文让 LLM 一条条数。

第三，越用越快。 你让它帮忙新建一个联系人——第一次慢点可以接受。但第十次新建联系人时，它还跟第一次一样从头推理每一步该点哪里，这就不对了。

这三件事看起来风马牛不相及——实时交互是推理速度问题，长期记忆是存储和检索问题，经验复用是学习问题。但 Bojie Li 这条线的核心发现是：它们都是同一个问题——Agent 的交互本质是流式事件处理，不是 Request/Response。

一旦你接受这个判断，整个设计空间就变了。ChatGPT 那种"用户说一句 → 模型想一会儿 → 回一句"的模式，对应的是数据库的微批处理。Agent 需要的是真正的流处理——事件驱动、有状态、可增量更新。而数据库和 Flink 花了三十年打磨出来的那套方法论，就是答案。

这套方法论浓缩成两条设计原则，贯穿了全部六个方案：

快慢分离：流处理求低延迟，批处理求深度。不要用一个模型做两件事。
Changelog + Checkpoint：增量写入保证实时性，定期全量压缩回收复杂度。和数据库的 WAL + compaction 完全同构。

下面我们从最表层的问题出发，一层层往下走。每一步都不是"我们来设计一个方案"——而是"我们先试最 naive 的做法，看它怎么失败的，然后从失败里找到真正该怎么做"。

一、最表层：Agent 为什么每次都从零开始？

先看第三个需求"越用越快"。当前的 Computer Use Agent 是这样工作的：

第1次新建联系人:
  截图 → VLM 推理"这是联系人页面" → 点"新建" →
  截图 → VLM 推理"输入框出现了" → 输入名字 → 截图 → ...

第10次新建联系人:
  截图 → VLM 推理"这是联系人页面" → 点"新建" →
  ...完全一样，零经验复用

每一步都要调大模型，3-5 秒一步，一个简单任务几十秒才能完成。而且每次都把同样的推理重新做一遍。

最 naive 的想法：把操作过程录下来，下次直接重放——像 RPA 宏一样。这当然不行——App 的 UI 会变，按钮位置会挪。盲目重放一个固定坐标的点击序列，碰上任何变化就挂了。

PreAct 的方案：编译成状态机，但在每一步做断言检查。

不存"点击坐标 (320, 540)"，而存"断言：联系人列表页面可见 → 动作：点击创建联系人按钮"
不存"输入Emilia"，而存"断言：姓名输入框已出现 → 动作：输入Emilia"

重放时，每到一个状态先验证屏幕断言，通过才执行动作。断言失败就把控制权交还给完整 Agent。这个设计让 PreAct 和 RPA 宏有了本质区别——它不是盲目重放，而是有眼的重放。

但还有一个更隐蔽的问题：状态机跑到了最后一步，不代表任务真的完成了。所有步骤都执行了，但联系人可能因为某个微妙原因（断言太宽松、网络延迟、UI 细微差异）实际上没创建成功。如果你把这种假成功存进库里，它会在后续重放中反复失败。

PreAct 的解决方案是存前验证（Verify-Before-Store）——编译出的候选状态机必须从干净环境完整重跑一次，由独立评估器确认任务真正完成，才允许入库。论文消融掉这个机制，每轮能解决的任务数直接掉 1.75-2.6 个。

记忆点：状态机不推理——它重放推理的结论。存的是"在这个画面状态下，下一步该点这里"，不是"为什么点这里"。推理做一次，执行做无数次。这就是快慢分离在执行层的实例化——首次执行走慢路径（VLM），重复执行走快路径（状态机），8.5-13× 加速。

二、往下一层：事实记忆该怎么存？

PreAct 解决了"怎么做一件事"（过程记忆），但 Agent 还需要记住"用户是谁"——过敏信息、航班记录、偏好设置。

现在的标准做法是检索式记忆：对话记录存成文本，需要时用语义相似度捞出相关片段喂给 LLM。对"上次飞东京是哪天"这种事实召回，这够用了。

但用户问"去年飞了几次？去日本几次？东京 vs 巴黎各几次？"——这就炸了。LLM 要在 thinking 里从 100 条记录里一条条数，费 token、容易漏、还可能数错。要么就把 100 条全塞进上下文让模型消化，但上下文窗口不是用来干这个的。

根本矛盾：存事实和用事实是分离的。 存的时候是自由文本，用的时候让 LLM 当场解析。每次查询都要重新理解数据结构。

User as Code 的解法：不让 LLM 在推理时做聚合。让它在写入时就把事实编译成类型化代码，查询时解释器一行算完。

具体来说，你每次跟 Agent 提到的事——航班、购物、体检——先以原始事实写入一个 append-only 日志（facts.jsonl）。积累到一定量后，一个编码 Agent 把日志编译成一个 Python 项目：

@dataclass
class Trip:
    date: date
    origin: str
    destination: str
    flight: str

class TravelState:
    trips: list[Trip]
    
    def count_by_year(self, year: int) -> int:
        return sum(1 for t in self.trips if t.date.year == year)
    
    def count_by_dest(self, dest: str) -> int:
        return sum(1 for t in self.trips if t.destination == dest)

    def check_passport_expiry(self) -> list[str]:
        # 护照过期预警——检索系统根本做不了的事
        ...

查询"去年飞了几次"变成了 count_by_year(2025)——零 LLM 调用，一行 Python，确定性 100% 准确。对比检索+RAG 的 6-43%。

记忆点：日志是安全属性（事实永不丢失），checkpoint 是性能属性（查询快）。又是 changelog + checkpoint。和数据库 LSM-tree 的 WAL + compaction 一模一样。

但这带来了一个新问题——代码化记忆每次对话都要被注入到 LLM 的上下文中。一段完整的类型定义、约束函数、状态对象，动辄几千 token。每次都重新 prefill 一遍，O(L²) 的 attention 代价。

这就把问题推到了下一层。

三、再深一层：记忆注入为什么这么贵？

Agent 的每次对话都要带上系统提示、技能说明、用户档案。这些文本几乎不变，但每次都塞进 prompt 从头 prefill。技能越长越严重——一个退货政策 8000 token，每次 prefill 就是 O(8000²) 的 attention 计算。而你的对话本身可能才 200 token。

直觉方案：预先把这些不变的内容 prefill 一次，存 KV Cache 里，下次直接用。

问题来了。KV Cache 的生产复用依赖精确前缀匹配——vLLM 的 Automatic Prefix Caching 只复用和前一个请求前缀完全相同的部分。你的用户档案里时间戳变了（"上次登录：06-27 → 06-28"），哪怕只变了一个 token，整个下游缓存全废。

再试一个方案：精准手术——只改时间戳那个 token 的 KV，其他全留着。行不行？

不行。Bojie Li 的 Programmable KV 论文在这里做出了整条线上最深的一个机制发现。

3.1 关键发现：Transformer 在 prefill 时就写好了"结论备忘录"

论文做了一个因果实验。Prompt 是"我的账户余额是 5000 元。我想买一台笔记本电脑。"正常 prefill，存下全部 KV Cache。然后把 5000 这个 token 的 KV 替换成随机值，其他所有 token 的 KV 保持原样→模型的回答几乎不变。反过来，保持 5000 不变，把后面句号 。 以及它之后的 token 的 KV 清掉→模型回答完全错误。

这意味着什么？余额 5000 这个信息，不是在 token 5000 的 KV 里被消费的。Transformer 在 prefill 阶段已经把 "余额=5000" 这个结论传播并记录到了下游的聚合 token（句号、换行、段落边界）上。Decode 时模型读的是这些"备忘笔记"，不读原始字段。

论文把这称为 "distributed write, concentrated read"——写入时信息分散传播到所有后续 token，读取时集中从少数聚合 token 消费。字段本身的 KV 驱动不到 1% 的决策。

这个发现把 KV Cache 的性质彻底重定义了——它不是"原材料仓库"，而是一本"结论备忘录"。你改原料没用，因为消费端读的是下游已经写好的结论。

3.2 那怎么改？——追加一条更正便签

既然结论已经写在聚合 token 上了，直接改原料无效，那就追加一条显式更正，让模型在处理更正时重新计算结论：

[原始 prompt：余额是 5000...] + [更正：余额改为 3200，本条覆盖之前所有值]

Transformer 在 prefill 这条 erratum 时，会做 attention 回顾前文，在 erratum 的引导下意识到旧结论失效，基于新值重新推理。因为 erratum 是 append-only——它追加在已有缓存末尾，前缀部分一个 token 不变——前缀缓存完全不受影响。

                | 直接改字段KV  | Erratum (append-only)
前缀缓存命中率  |     1%        |     98.5%
p90 TTFT        |      -        |    降 53–398×

记忆点：又是 changelog + checkpoint。Erratum 是增量 changelog，累积到阈值触发一次全量 reprefill（checkpoint）截断。98.5% 的请求根本不需要截断。

3.3 那怎么复用？——预编译 + RoPE 重定位

回到最初的问题：怎么复用不变的技能文本的 KV Cache？

既然 KV Cache 里存的是"笔记"而不是原料，而技能文本（退货政策、工具说明）是自包含的——它的笔记只依赖自身内容，不依赖外部上下文——那这些笔记就是位置可移植的。

预编译：把技能文本在隔离环境 prefill 一次，存下 KV Cache。

拼接时，关键在 RoPE（旋转位置编码）的数学性质。RoPE 把位置信息编码为对 key 向量的旋转。它的核心性质是旋转可叠加：

$$ R(a) \cdot R(b) = R(a + b) $$

预编译时存的 key 带了位置 j 的旋转 R(j) · Kⱼ。要搬到新位置 j+P，再转 P 度：R(P) · R(j) · Kⱼ = R(j+P) · Kⱼ。O(L) 的逐 key 旋转替代了 O(L²) 的 attention 重算，在 32k 长度下提速 13.9×。

一个容易产生的疑虑：技能 token 在隔离 prefill 时没"见"过前文——它们不知道前缀的存在。这部分信息缺失无法通过旋转补回。论文的解决方案是 Seam-Repair——只把拼接边界两三个 token 重新 prefill（让它们 attend 前缀），技能内部继续复用。因为技能是自包含的，边界重算足够补偿。实验验证 logit cosine 0.90-0.999。

Erratum 不会导致上下文 O(n²) 爆炸吗？ 这是个常见误解。Erratum 是追加新 token，cost = O(N_new × N_old)，不是 O(N_old²)。在 14000 token 的上下文末尾加 20 token 的 erratum，代价 ≈ 14k × 20，可忽略。真正 O(n²) 的只有全量 reprefill——而它只在 checkpoint 时触发。

四、再深一层：能把记忆写进模型参数吗？

Programmable KV 和 User as Code 把记忆放在模型外部（KV Cache 和 Python 文件），通过上下文注入。如果想把记忆写进模型内部——像 fine-tuning 一样让模型记住用户事实——标准方案是给每个用户训练一个 LoRA adapter。

但 LoRA 有架构上的根本问题。

LoRA 训练时，用户的内容（"Maya 的航班是 XX"）和推理技能（"怎么根据航班记录回答统计问题"）被折叠进同一个低秩权重增量 ΔW 中。结果是：

① 全局污染。 ΔW 作用于模型的 Q/K/V/O 权重矩阵。写入 Maya 的事实会扰动整个模型的输出——包括跟 Maya 完全无关的文本。Bojie Li 量化了这个效应：写入相同事实后，Engram 方式对无关文本的干扰比 LoRA 小约三万三千倍。原因不是 LoRA 训练得不好——LoRA 被设计成"找一个便宜的梯度方向把 loss 降下来"，这个方向天然会跨越跟事实无关的维度。

② 推理退化。 直接召回（"我的航班号是多少"）LoRA 能做。但间接推理（"哪年飞得多"）准确率大幅下降——因为你把内容塞进了推理技能的权重里，挤占了推理能力。User as Engram 在间接推理上准确率高 5.6×，且从未让任何用户比基础模型更差。

③ 多租户不兼容。 ΔW 是全局的。100 个用户就要 100 份完整的 LoRA 权重（每份 14.2 MB），按请求动态 swap，而且两份不能同时在线。

4.1 DeepSeek Engram：模型内的哈希表

2026 年初 DeepSeek 发表的 Engram 提供了一个完全不同的路线。Engram 在 Transformer 的特定层插入一个外挂哈希表——根据输入 token 的 N-gram pattern 做确定性哈希查找，把查到的 embedding 通过 gate 融合进 hidden state：

输入序列 → 提取后缀 2-gram、3-gram → 8 个不同哈希函数映射到嵌入表槽位 → 查表 → sigmoid gate 融合

类比：attention 是 CPU（计算），Engram 哈希表是 RAM（存储）。遇到熟悉的 N-gram pattern，模型直接从"RAM"读，不用 attention 算。查找是 O(1) 的，且因为是确定性哈希（非学习路由），大嵌入表可以放在 CPU 内存预取。

4.2 User as Engram：把用户事实存进哈希槽位

User as Engram 利用 Engram 的稀疏寻址特性做了一件 LoRA 做不到的事：把用户内容（事实）和推理技能（怎么用事实）分开存。

用户内容 → Engram 哈希表的特定槽位。触发 N-gram（如用户名字 "Maya"）通过确定性哈希落到固定槽位，写入事实 embedding。只有输入包含 "Maya" 时才读这几行。
推理技能 → 一个共享 LoRA adapter。所有用户共用同一个推理 adapter，不随用户数量增长。

每用户仅需 88 KB（几行哈希表槽位），对比 per-user LoRA 的 14.2 MB。更关键的是隔离性——不同用户的 trigger N-gram 落在不同槽位，多个用户的表可以直接叠加，哈希不冲突就不干扰。这与 LoRA 的全局覆盖形成了根本性的架构差异。

记忆点：如果把 Engram 比作大脑，哈希表 = 海马体（存稀疏的事实记忆），共享 LoRA = 新皮层（存缓慢习得的推理技能）。一个事实只动一个槽位，不动整个皮层。这和 Programmable KV 里"不要动字段的 KV，在末尾加更正"是同一套直觉。

五、回到起点：主线是什么？

六个方案拆完，它们之间的关系是这样的：

问题层次         方案                  底层机制发现              设计模式
───────         ────                  ──────────               ────────
执行重复        PreAct                断言可替代推理            快慢分离
事实聚合        User as Code          代码化表示 > 文本检索     changelog+checkpoint
记忆注入        Programmable KV       KV Cache = 结论备忘录     changelog+checkpoint
参数化记忆      User as Engram        N-gram 哈希天然隔离       changelog+checkpoint

每一步都不是凭空设计一个新架构。每一步都是——先试最显然的做法，发现它因为某个深层原因失败，然后从失败中提出机制假设，验证它，再围绕它设计解法。

PreAct：试盲目重放→失败，因为环境会变→需要断言
User as Code：试检索→失败，因为存储和推理分离→需要代码化
Programmable KV：试改字段 KV→失败，因为模型读的是笔记不是字段→需要 erratum
User as Engram：试 LoRA→失败，因为全局权重污染→需要哈希隔离

这条线的核心论点：决定 Agent 表现的，往往不是模型能力，而是交互和表示。 模型已经足够强了。问题是我们在用做聊天机器人的方式做 Agent——Request/Response 微批、无状态、每轮重来。一旦换到流式事件处理的视角，答案自然浮出来。

这也是为什么 Bojie Li 选择在 Flink Forward Asia 上讲这些——因为 Flink 社区花了十年解决"有状态的流式事件处理"问题，而 Agent 社区正在撞上完全相同的问题，用不同的名字。

附录 A：RoPE 重定位的形式化推导

A.0 RoPE 的数学定义

RoPE 将位置信息以旋转的方式注入 query 和 key，非 GPT-2 式的可学习位置表加法。

每个注意力头维度为 $d$，将 $d$ 维向量两两分组为 $d/2$ 个二维平面。对位置 $pos$ 上的 query/key 向量，在第 $i$ 个维度对上施加角度 $pos \cdot \theta_i$：

$$ \theta_i = \text{base}^{-2i/d}, \quad i = 0, 1, \dots, d/2-1 $$

旋转矩阵（每个二维平面一个 $2 \times 2$ 旋转）：

$$ R_{\text{pos}}^{(i)} = \begin{bmatrix} \cos(\text{pos} \cdot \theta_i) & -\sin(\text{pos} \cdot \theta_i) \ \sin(\text{pos} \cdot \theta_i) & \cos(\text{pos} \cdot \theta_i) \end{bmatrix} $$

整个 $d$ 维向量的旋转矩阵是对角分块的：

$$ R_{\text{pos}} = R_{\text{pos}}^{(0)} \oplus R_{\text{pos}}^{(1)} \oplus \dots \oplus R_{\text{pos}}^{(d/2-1)} \in \mathbb{R}^{d \times d} $$

RoPE 版本的 Q、K：

$$ \tilde{q}{\text{pos}} = R{\text{pos}} \cdot q_{\text{pos}}, \qquad \tilde{k}{\text{pos}} = R{\text{pos}} \cdot k_{\text{pos}} $$

V 不参与旋转——位置信息只需影响"谁看谁"，不需影响"被看时传什么内容"。

记忆点：RoPE 不是"加一个位置向量"，而是在做 QK 点积之前先把 Q 和 K 各自旋转。位置越远，旋转角度越大。

A.1 核心性质：注意力只依赖相对位置

对位置 $i$ 的 query 和位置 $j$ 的 key：

$$ \begin{aligned} \text{score}(i, j) &= \tilde{q}_i^{\top} \tilde{k}_j = (R_i \cdot q_i)^{\top} (R_j \cdot k_j) \ &= q_i^{\top} R_i^{\top} R_j , k_j \end{aligned} $$

旋转矩阵是正交矩阵且满足群封闭性：

$$ R_i^{\top} = R_{-i}, \qquad R_{-i} \cdot R_j = R_{j-i} $$

因此：

$$ \boxed{\text{score}(i, j) = q_i^{\top} R_{j-i} , k_j} $$

分数仅取决于相对位置 $j-i$。两旋转组合等于角度相加——先回转 $i$ 度再前转 $j$ 度 = 净转 $j-i$ 度。这就是 RoPE 天然支持训练时未见长度的原因。

A.2 预编译：技能被"冷冻"时存了什么

技能文本占 $L_s$ 个 token，隔离 prefill（位置从 0）。对 $j \in [0, L_s-1]$：

$$ k_j^{\text{skill}} = R_j \cdot k_j, \qquad v_j^{\text{skill}} = v_j $$

存入 KV Cache 的就是 ${k_j^{\text{skill}}, v_j^{\text{skill}}}$。注意存的是已旋过的 key（$R_j \cdot k_j$）——生产系统中 post-RoPE keys 直接存，避免 decode 时重复计算。

A.3 重定位：对 key 施加 $\Delta$ 旋转

插入新上下文位置 $[P, P+L_s-1]$。利用旋转可叠加性：

$$ R_P \cdot (R_j \cdot k_j) = (R_P \cdot R_j) \cdot k_j = R_{j+P} \cdot k_j $$

$L_s$ 个 key，每个一次 $R_P$ 旋转，等价于在新位置重新 prefill。Value 完全不动。

记忆点：因为 $R(a) \cdot R(b) = R(a+b)$。

A.4 三种 Attention 关系的验证

情况 A：前缀 token 看技能 token（$i < P,\ j+P$）

$$ \text{score}(i, j+P) = q_i^{\top} R_i^{\top} R_{j+P} , k_j = q_i^{\top} R_{(j+P)-i} , k_j $$

绝对位置 $j+P$、相对距离正确。✅

情况 B：技能 token 看前缀 token（$j+P,\ i < P$）

$$ \text{score}(j+P, i) = q_{j+P}^{\top} R_{j+P}^{\top} R_i , k_i = q_{j+P}^{\top} R_{i-(j+P)} , k_i $$

位置正确 ✅。但 $q_{j+P}$ 来自隔离 prefill——技能 token 没"见"过前缀，query 不含前缀信息。这是 RoPE 重定位不能修复的内容条件依赖。❌

情况 C：技能内部 token 互看（$j_1+P,\ j_2+P$）

$$ \text{score}(j_1+P, j_2+P) = q_{j_1+P}^{\top} R_{j_2-j_1} , k_{j_2+P} $$

相对位置 $j_2-j_1$ 不变。✅

关系	RoPE 重定位效果
前缀 → 技能	绝对/相对位置正确 ✅
技能 → 前缀	位置正确 ✅，内容条件缺失 ❌
技能 → 技能	全部正确 ✅

A.5 Seam-Repair 与复杂度

边界 2–3 个 token 重新 prefill 吸收前缀信息，技能内部复用。logit cosine 0.90–0.999。

复杂度对比（技能 $L_s$，前缀 $L_p$，后缀 $L_t$）：

完整重算：$\text{prefill} = O((L_p + L_s + L_t)^2)$

RoPE 重定位：

重旋转 key：$O(L_s \cdot d)$
Seam-repair：$O(k \cdot (L_p + k + L_t)),\ k = 2 \sim 3$
后缀 prefill：$O(L_t^2 + L_t \cdot (L_p + L_s))$

技能 attention 从 $O(L_s^2 + L_s L_p)$ 降为 $O(L_s \cdot d)$。$L_s = 8000$ 时差异数量级——32k 长度下 TTFT 加速 13.9×。

A.6 Append-Only Erratum 的复杂度

会话结构：

[用户档案 2000] [技能 8000] [对话 4000]
    ↑ 一次prefill   ↑ 一次prefill   ↑ 逐轮增长

每轮 attention 复杂度：

操作	复杂度	原因
新 token attend 缓存	$O(N_{\text{new}} \cdot N_{\text{cached}})$	正常推理
缓存 attend 新 token	0	因果掩码
缓存内部重新 attention	0	不需要

Erratum 是"追加新 token"。追加 20 token 到 14000 token 上下文：$O(20 \cdot 14000)$，可忽略。

错误理解：erratum 累积重算整个 attention → $O(N_{\text{cached}}^2)$
正确理解：erratum 是追加新 token → $O(N_{\text{new}} \cdot N_{\text{old}})$

erratum 链累积到几百条时触发 checkpoint 全量重算截断。98.5% 缓存命中率证明触发频率极低。

附录 B：Erratum 可编辑性的形式化推导

B.1 直接改字段 KV 为何无效

设上下文 $x = (x_1, \dots, x_T)$，$x_k$ 为动态字段。完整 prefill 产生 $\mathbf{KV}(x)$。

朴素方案：只替换 $x_k$ 的 KV，其余保留：

$$ \widehat{\mathbf{KV}} = \big(\mathbf{KV}_{1:k-1}(x), \mathbf{KV}k^{\text{new}}, \mathbf{KV}{k+1:T}(x)\big) $$

失效原因：设 $x_j$（$j > k$）为聚合 token（句号、换行等）。prefill 阶段 $x_j$ 的 self-attention 吸收 $x_k$ 的信息后写入自身 KV：

$$ \mathbf{KV}j(x) = f\big(x_j, \text{attention}(x_j, x{\leq j})\big) $$

$\widehat{\mathbf{KV}}$ 中 $\mathbf{KV}_j$ 仍保留旧值——改变 $x_k$ 而不更新所有 $j > k$ 的聚合 token，下游"备忘笔记"仍读旧结论。 因果实验：字段自身 KV 驱动 < 1% 决策。

B.2 Erratum 工作原理

Erratum $e$ 追加在末尾：

$$ x' = (x_1, \dots, x_T, e_1, \dots, e_{|e|}) $$

$e$ 语义："覆盖 $x_k$，新值为 Y"。Transformer 处理 $e$ 时，$e$ 的 attention 回顾所有前文（包括 $x_k$ 和各聚合 token $x_j$），在 $e$ 引导下判定旧结论失效，基于新值重新推理。

设 $d$ 为 erratum 之后的问题 token，其 KV：

$$ \mathbf{KV}d(x') = f\big(x_d, \text{attention}(x_d, x{\leq T}, e)\big) $$

$e$ 含量使 $x_d$ 的 attention 基于新值决策。

关键性质：erratum 是 append-only，前缀完全不变：

$$ \mathbf{KV}{1:T}(x') = \mathbf{KV}{1:T}(x) $$

prefix cache 100% 兼容。

B.3 Changelog + Checkpoint 形式化

第 $n$ 次字段更新产生 erratum $e^{(n)}$。$N$ 次更新后：

$$ x^{(N)} = (x_1, \dots, x_T, e^{(1)}, \dots, e^{(N)}) $$

Changelog 阶段：每次追加 $e^{(n)}$，cost：

$$ \text{cost}(e^{(n)}) = O\big(|e^{(n)}| \cdot (T + \sum_{i=1}^{n-1} |e^{(i)}|)\big) $$

$|e^{(n)}| \approx 15 \sim 20 \ll T$，可忽略。

Checkpoint 阶段：$\sum_{i=1}^N |e^{(i)}| > \tau$ 触发全量重 prefill：

$$ x^{\text{ckpt}} = (x'_1, \dots, x'_T) $$

$x'_k$ 已替换为新值，erratum 链清零。重算 $O(T^2)$ 被 $N$ 次请求摊销。

附录 C：Engram 哈希表寻址的形式化推导

C.1 N-gram 提取与哈希

位置 $t$ 的后缀 N-gram（$n = 2, 3$）：

$$ g_t^{(n)} = (x_{t-n+1}, \dots, x_t) $$

对每个 N-gram 阶数 $n$ 和哈希头 $k \in {1, \dots, K}$（默认 $K = 8$）：

$$ \text{idx}{n,k} = \varphi{n,k}\big(\text{compress}(g_t^{(n)})\big) \bmod M_{n,k} $$

$\text{compress}(\cdot)$：tokenizer 压缩（归一化 + 去重，减少有效词表 ~70%）
$\varphi_{n,k}$：multiplicative-XOR 哈希
$M_{n,k}$：质数模数，减少系统性碰撞

索引到嵌入表：

$$ \mathbf{e}{n,k} = \mathbf{E}{n,k}[\text{idx}{n,k}], \quad \mathbf{E}{n,k} \in \mathbb{R}^{M_{n,k} \times d_{\text{head}}} $$

拼接为最终记忆向量：

$$ \mathbf{e}t = [\mathbf{e}{2,1}; \dots; \mathbf{e}{2,K}; \mathbf{e}{3,1}; \dots; \mathbf{e}_{3,K}] $$

C.2 门控融合

记忆向量与 hidden state 通过 sigmoid gate 动态调制：

$$ \mathbf{g}_t = \sigma\left(\frac{\text{norm}(\mathbf{W}_k \mathbf{e}_t) \odot \text{norm}(\mathbf{W}_q \mathbf{h}_t)}{\sqrt{D}}\right) $$

$$ \mathbf{h}'_t = \mathbf{h}_t + \mathbf{g}_t \odot (\mathbf{W}_v \mathbf{e}_t) $$

Gate 让模型学会"什么情况下该信任记忆"——对无关 N-gram，gate → 0 屏蔽。

C.3 多租户叠加

用户 $u$ 的事实写入槽位集合 $\mathcal{S}_u$。两用户 $u_1$、$u_2$ 碰撞概率：

$$ \mathbb{P}(\mathcal{S}{u_1} \cap \mathcal{S}{u_2} \neq \emptyset) \approx 1 - \left(1 - \frac{|\mathcal{S}{u_1}|}{M}\right)^{|\mathcal{S}{u_2}|} $$

$M$ 百万至千万量级，$|\mathcal{S}_u|$ 百至千量级，碰撞概率极低。不碰撞时叠加：

$$ \mathbf{E}^{\text{combined}}[i] = \begin{cases} \mathbf{E}^{u_1}[i] & i \in \mathcal{S}{u_1} \ \mathbf{E}^{u_2}[i] & i \in \mathcal{S}{u_2} \ \mathbf{E}^{\text{base}}[i] & \text{otherwise} \end{cases} $$

确定性哈希保证每个 N-gram 只读固定槽位——不同用户 trigger 天然不交叉。

C.4 与 LoRA 的隔离性对比

LoRA：$\Delta W^{(u)} = B^{(u)} A^{(u)}$ 作用于全局权重。任意输入 $x$：

$$ h' = h + \Delta W^{(u)} \cdot h $$

无关输入也被 $\Delta W^{(u)}$ 扰动。

Engram：读取通过确定性 N-gram 哈希触发。仅当输入包含 trigger N-gram（如用户名）时才查对应槽位。无关输入的 edit 行不被读取，输出 bit-for-bit 不变：

$$ |\mathbf{y}{\text{engram}} - \mathbf{y}{\text{base}}|2 \approx 0,\quad |\mathbf{y}{\text{lora}} - \mathbf{y}_{\text{base}}|_2 \gg 0 $$

论文量化干扰比为 ~1/33,000。

方案	arXiv	GitHub
PreAct	2606.17929	19PINE-AI/PreAct
User as Code	2606.16707	19PINE-AI/user-as-code
Programmable KV	2606.17107	19PINE-AI/programmable-kv
User as Engram	2606.19172	19PINE-AI/user-as-engram
Sema	2604.20940	—
Latent Bridge	2606.24470	19PINE-AI/latent-bridge-games
Engram (DeepSeek)	2601.07372	deepseek-ai/Engram

方向	代表性工作	与 Bojie Li 线的关键差异
Agent 记忆框架	MemGPT/Letta, Mem0, Zep, Cognee	工业方案：外挂服务集成；Bojie Li：记忆进模型/近模型层
参数化用户记忆	MemoryLLM (ICML 2024), SELF-PARAM, Larimar, TAP-PER	同方向，但 Engram 独特在哈希隔离而非连续空间/学习路由
技能编译	Muscle-Mem, SkillOpt, Skill-R1, Trace2Skill	同方向，但 PreAct 独特在"存的就是跑的"（状态机直接执行）
KV Cache 编程	Leyline, Kamera, KVEraser, CacheSlide, RedKnot	同方向偏工程/系统优化，Programmable KV 独特在底层机制发现

GPT-2 架构拆解与理解

Fri, 26 Jun 2026 00:00:00 GMT

GPT-2 架构拆解与理解

TL;DR： GPT-2 的核心目标，是把一段上文压缩成一个高维表示，再让这个表示在词表空间里靠近下一个正确 token 的嵌入。嵌入层提供初始语义和位置，注意力负责跨 token 汇聚上下文，FFN 负责逐 token 加工概念，残差和 LayerNorm 则让 12 层堆叠保持可训练。

0. 一句话总结 Transformer 在做什么

把整段上文压缩成一个高维向量，让这个向量在词表空间中恰好落在"正确答案"那个 token 的向量附近。

所有 124M 参数的梯度更新，都服务于这一个目标。

1. 核心超参数（GPT-2 Small）

V = 50257：词表大小
d = 768：每个 token 的表示向量是 768 维
L = 12：12 层反复加工
h = 12：每层注意力有 12 个并行专家（头）
d_k = 64：每个专家看 64 维（768 ÷ 12）
d_ff = 3072：FFN 中间层膨胀到 3072 维（4 倍）
ctx = 1024：最多一次看 1024 个 token

2. 输入层：两块地基

Token Embedding（`W_E`）

一张大表，每一行是一个 token 的"身份证向量"。输入整数 → 查表 → 768 维向量。五万多个 token，每人一张 768 分的评分卡。

Position Embedding（`W_P`）

如果只看 token 向量，"The cat sat" 和 "sat cat The" 在模型眼里是三组完全相同的数字。所以再建一张表，每个位置有一个独立的"座位向量"。位置 0 有一个 768 维向量表示"我是第一个"，位置 1 有另一个。

嵌入求和

Token 向量 + 位置向量 → 逐元素相加。为什么用加法而非拼接？拼接使维度翻倍计算量翻倍，实验证明加法已足够——模型通过训练学会区分哪些维度来自语义、哪些来自位置。

3. LayerNorm：数据标准化车间

每层有两次 LayerNorm（注意力前一次、FFN 前一次）。每个 LayerNorm 有两个可学习的向量：

γ（gamma）：缩放系数——归一化后乘多少
β（beta）：平移系数——归一化后加多少

操作：对一个 token 的 768 个数值，减去均值、除以标准差（强制复位为均值 0 标准差 1），然后用 γ 和 β 调到"下一层需要的尺度"。

为什么每层有独立的 LayerNorm？ 浅层处理的是词嵌入（原始），深层处理的是抽象语义——不同工序需要不同的数据尺度。

4. 多头自注意力（MHSA）：让 token 互相看

为什么需要注意力？

经过嵌入层后，每个 token 只知道自己的信息——"cat"不知道前面有"The"，"sat"不知道前面有"cat"。注意力让每个 token 从序列中其他 token 提取信息，但要有权重——关系大的 token 权重大，关系小的权重小。

Q、K、V 三个投影

输入经过三个矩阵乘法，变成三个新向量：

Q（Query）："我是谁，我想找什么？"——当前 token 发出的搜索需求
K（Key）："我是谁，我能提供什么信息？"——每个 token 提供的索引标签
V（Value）："如果别人关注我，我应该输出什么？"——被注意时传递的实际内容

拆分成多头

12 个头不是 12 个注意力层串联，而是把 768 维切成 12 块，每块 64 维，12 个头并行计算。

Scaled Dot-Product Attention（核心公式）

对每个头：

算分数：Q 和 K 做点积——"我想找的东西"和"你能提供的东西"是否匹配
除以 √d_k：64 维点积的方差 = 64，标准差 = 8。不除 8 → 分数太大 → softmax 极端 → 梯度消失
加因果掩码：GPT-2 是自回归模型，token t 不能偷看 j > t 的 token。未来位置分数设为 -∞
softmax：分数 → 概率（每行和为 1）
加权求和 V：注意力权重 × V = 从各 token 提取信息

`W_O`：融合 12 个专家的意见

12 个头各自输出 64 维 → 拼成 768 维 → 乘以 W_O（另一个 768×768 矩阵）。

`W_O` 和 `V` 的关系

W_O 不直接作用于 V——它作用于注意力加权后的结果。V 是原始信息库，softmax(QK^T) 是从信息库中筛选要取多少，W_O 是把筛选出的摘录整合成报告。

残差连接 1

H_mid = H_in + A（原始输入 + 注意力的输出）

残差为什么重要？ 无残差→12 层深网络梯度消失。残差提供"高速公路"——梯度可直接从高层跳到底层，不经过中间计算。

5. Feed-Forward Network（FFN）：每个 token 单独消化

注意力让 token 之间交换了信息，但交换来的信息还需要加工。FFN 和注意力完全不同——注意力是跨 token 的操作（会议讨论），FFN 是每个 token 内部的操作（各自回位置消化）。

三拍子：展开 → 筛选 → 回收

768 维 → W₁ 升维到 3072 → GELU 筛选 → W₂ 降维回 768

升维（W₁：768→3072）：把紧凑的表示"展开"——原本混在一起的多个概念，在 3072 维空间中可以各占各的维度不干扰
筛选（GELU）：对每个概念通道独立做门控——正激活放行（保留），负激活屏蔽（接近 0）
降维（W₂：3072→768）：把幸存的概念压缩回来，作为对原始表示的补充

残差连接 2

同注意力一样：H_out = H_mid + F。FFN 学的是对当前表示的修正，不是从零重建。

6. 形式化推导：一个 token 向量的一生

以纯数学语言完整推导前向、损失与生成流程。所有步骤显式写出可训练的权重矩阵和偏置，模型的最小单元就是这些可训练参数。

6.1 符号约定

符号	含义	GPT-2 Small 取值
`V`	词汇表大小	50257
`T_max`	最大序列长度	1024
`L`	层数	12
`D`	模型维度	768
`D_ff`	前馈中间维度	3072
`H`	注意力头数	12
`d_k`	每头维度 `D / H`	64

注视一个长度为 T 的输入序列：x = (x_1, x_2, ..., x_T)，每个 x_t ∈ {0, 1, ..., V-1}。 主人公是第 t 个 token x_t，它的向量表示将经历完整一生，最终用于预测 x_{t+1}。

6.2 诞生：嵌入

可训练参数：词嵌入 W_E ∈ R^{V×D}，位置嵌入 W_P ∈ R^{T_max×D}。

Token x_t 的初始表示（第 0 层输出）：

$ h^{(0)}t = (W_E){x_t} + (W_P)_t \quad \in \mathbb{R}^D $

逐元素相加。同一词坐不同位置 → 加上不同的位置偏移 → 不同表示。

6.3 成长：穿越 L 层 Transformer Block

对每一层 l = 1, 2, ..., L，向量 h^{(l-1)}_t 依次经历两个子层，每个子层使用 Pre-LN 残差结构。

2.1 第一子层：多头因果自注意力

2.1.1 Pre-LayerNorm

可训练参数：γ₁^{(l)} ∈ R^D，β₁^{(l)} ∈ R^D。

$ a^{(l)}_t = \text{LayerNorm}\left(h^{(l-1)}_t;; γ₁^{(l)}, β₁^{(l)}\right) $

其中：

$ \mu_t = \frac{1}{D}\sum_{i=1}^D h^{(l-1)}{t,i}, \qquad \sigma_t^2 = \frac{1}{D}\sum{i=1}^D \left(h^{(l-1)}_{t,i} - \mu_t\right)^2 $

$ a^{(l)}_t = γ₁^{(l)} \odot \frac{h^{(l-1)}_t - \mu_t}{\sqrt{\sigma_t^2 + \epsilon}} + β₁^{(l)} $

2.1.2 Q / K / V 投影

可训练参数：W_Q^{(l)}, W_K^{(l)}, W_V^{(l)} ∈ R^{D×D}，偏置 b_Q^{(l)}, b_K^{(l)}, b_V^{(l)} ∈ R^D。

对整个序列所有位置 t' ∈ [1, T] 计算：

$ q_{t'}^{(l)} = a_{t'}^{(l)} W_Q^{(l)} + b_Q^{(l)} \quad \in \mathbb{R}^D $ $ k_{t'}^{(l)} = a_{t'}^{(l)} W_K^{(l)} + b_K^{(l)} \quad \in \mathbb{R}^D $ $ v_{t'}^{(l)} = a_{t'}^{(l)} W_V^{(l)} + b_V^{(l)} \quad \in \mathbb{R}^D $

2.1.3 多头拆分

将 D 维向量均分成 H 个头，每个头维度为 d_k。对头 h ∈ {1, ..., H}，位置 t' 的查询、键、值向量为：

$ q_{t',h}^{(l)} = q_{t'}^{(l)}\big[(h-1)d_k : h d_k\big] \quad \in \mathbb{R}^{d_k} $ $ k_{t',h}^{(l)} = k_{t'}^{(l)}\big[(h-1)d_k : h d_k\big] \quad \in \mathbb{R}^{d_k} $ $ v_{t',h}^{(l)} = v_{t'}^{(l)}\big[(h-1)d_k : h d_k\big] \quad \in \mathbb{R}^{d_k} $

2.1.4 因果掩码注意力（主人公 `t` 的视角）

主人公位置 t 只能注意到 t' ≤ t 的 token。

计算头 h 下，t 对 t' 的未归一化注意力分数：

$ e_{t,t',h}^{(l)} = \frac{q_{t,h}^{(l)} \cdot k_{t',h}^{(l)}}{\sqrt{d_k}} \qquad (t' = 1, ..., t) $

掩码确保 t' > t 的分数为 -∞。随后 softmax：

$ \alpha_{t,t',h}^{(l)} = \frac{\exp\left(e_{t,t',h}^{(l)}\right)}{\sum_{j=1}^{t} \exp\left(e_{t,j,h}^{(l)}\right)} \quad \in \mathbb{R} $

加权求和得到该头的输出：

$ o_{t,h}^{(l)} = \sum_{t'=1}^{t} \alpha_{t,t',h}^{(l)}; v_{t',h}^{(l)} \quad \in \mathbb{R}^{d_k} $

2.1.5 合并多头与输出投影

可训练参数：W_O^{(l)} ∈ R^{D×D}，b_O^{(l)} ∈ R^D。

$ o_t^{(l)} = \text{concat}\left(o_{t,1}^{(l)}, ..., o_{t,H}^{(l)}\right) W_O^{(l)} + b_O^{(l)} \quad \in \mathbb{R}^D $

2.1.6 残差连接

$ h^{(l-0.5)}_t = h^{(l-1)}_t + o_t^{(l)} \quad \in \mathbb{R}^D $

2.2 第二子层：前馈网络

2.2.1 Pre-LayerNorm

可训练参数：γ₂^{(l)}, β₂^{(l)} ∈ R^D。

$ c_t^{(l)} = \text{LayerNorm}\left(h^{(l-0.5)}_t;; γ₂^{(l)}, β₂^{(l)}\right) $

2.2.2 升维 → GELU 筛选 → 降维

可训练参数：W₁^{(l)} ∈ R^{D×D_ff}，b₁^{(l)} ∈ R^{D_ff}，W₂^{(l)} ∈ R^{D_ff×D}，b₂^{(l)} ∈ R^D。

$ u_t^{(l)} = c_t^{(l)} W_1^{(l)} + b_1^{(l)} \quad \in \mathbb{R}^{D_{ff}} $ $ f_t^{(l)} = \text{GELU}\left(u_t^{(l)}\right) W_2^{(l)} + b_2^{(l)} \quad \in \mathbb{R}^D $

GELU 近似公式：

$ \text{GELU}(x) \approx 0.5x \left[1 + \tanh!\left(\sqrt{\frac{2}{\pi}}\left(x + 0.044715x^3\right)\right)\right] $

2.2.3 残差连接

$ h^{(l)}_t = h^{(l-0.5)}_t + f_t^{(l)} \quad \in \mathbb{R}^D $

6.4 使命：最终输出与预测

经过全部 L 层后，得到最终表示。最后做一次 LayerNorm：

可训练参数：γ_f, β_f ∈ R^D。

$ z_t = \text{LayerNorm}\left(h^{(L)}_t;; γ_f, β_f\right) \quad \in \mathbb{R}^D $

输出投影（Weight Tying — 通常无独立偏置）：

可训练参数：W_{lm} ∈ R^{V×D}（实际实现中 W_{lm} = W_E）。

$ \text{logits}t = z_t W{lm}^\top \quad \in \mathbb{R}^V $

z_t 和 W_{lm} 的每一行（每个候选 token 的嵌入）做点积。点积越大 → 两个向量越接近 → 该 token 概率越高。

6.5 学习：损失函数

训练时一次性计算所有位置的 logits，第 t 个位置预测 x_{t+1}：

$ \mathcal{L} = -\frac{1}{T-1}\sum_{t=1}^{T-1} \log\left( \text{softmax}(\text{logits}t){x_{t+1}} \right) $

即交叉熵——最大化正确 token 的概率，等价于让 z_t 和 W_E[x_{t+1}] 尽可能靠近。反向传播计算损失对每一个可训练参数的梯度，用 AdamW 等优化器更新。

6.6 应用：自回归生成

给定前缀 x_1, ..., x_t，算出 logits_t
温度调节：logits'_t = logits_t / τ（τ 越小越贪婪，τ 越大越随机）
采样：x_{t+1} ∼ softmax(logits'_t)
将 x_{t+1} 拼接到序列末尾，重复直到终止符或最大长度

注意：生成第 t+1 个 token 时，所有 ≤t 的 K/V 可缓存（KV-Cache）避免重复计算，但数学本质不变。

6.7 可训练参数全家福

模块	参数	形状	数量
嵌入	`W_E`	V × D	1
	`W_P`	T_max × D	1
每层注意力	`γ₁, β₁`	D	2
	`W_Q, W_K, W_V`	D × D	3
	`b_Q, b_K, b_V`	D	3
	`W_O`	D × D	1
	`b_O`	D	1
每层 FFN	`γ₂, β₂`	D	2
	`W₁`	D × D_ff	1
	`b₁`	D_ff	1
	`W₂`	D_ff × D	1
	`b₂`	D	1
最终 LN	`γ_f, β_f`	D	2
输出头	`W_{lm}`	V × D	1

所有这些参数构成了可训练的 GPT-2。每一个正向传递都沿着上述数学路径一步一步塑造 token 向量的生命轨迹。每一条梯度都沿着完全相同的路径反向传播，逐层修正这些参数，直到模型学会在 768 维空间中让预测向量落在正确答案的嵌入向量附近。

7. 为什么需要 12 层？

第 1 层：cat 看到 The（距离 1）
第 2 层：sat 看到 The+cat（距离 2）
...
第 12 层：第 1024 个 token 可以看到第 1 个

更深层的另一个好处是抽象层级：浅层看语法（局部短语），中层看语义（实体指代），深层看推理（篇章连贯性、世界知识）。

8. 输出层

12 层处理完 → 最终 LayerNorm → @ W_E^T（输出投影）→ softmax → 取概率最高的 token。

Weight Tying：输出投影不设独立矩阵，直接用输入 Token Embedding 的转置。H_final @ W_E^T 等价于"把最后位置的隐状态，和五万个候选 token 的嵌入向量逐一比较相似度"。最像的那个就是预测的下一个 token。

9. FFN 的可解释性（为什么 FFN 占 70% 参数但少有人提？）

核心发现：FFN 是一个键值记忆网络

FFN 的 3072 个维度各是一个"概念槽位"，每个槽位有两样东西：

Key（W₁ 的一行）：输入长什么样时，激活这个槽位？
Value（W₂ 的一列）：激活后，往输出里加什么信息？

前向传播就是：逐一检查 3072 个概念 → 匹配的用 GELU 决定强度 → value 加权累加。

实验证据

把 W₂ 的列投影到词表：某列的 top token 是 Paris, France, Lyon → 对应"法国"概念；某列是 DNA, protein, gene → 对应"分子生物学"
ROME 实验：修改 FFN 中几个特定神经元 → 模型从认为"埃菲尔铁塔在巴黎"变成"在罗马"。证明事实知识以高度局部化的方式存储在 FFN 中

为什么 FFN 少被提及？

注意力是 2017 年的革命性发明（可以可视化热力图），FFN 是 1986 年的 MLP（一张无法可视化的数字表）。但参数量不说谎——70% 参数在 FFN，因为它存储了模型知道的几乎所有事实、语法、常识和推理模式。注意力是名片，FFN 是肌肉。

10. GPT-2 → 现代大模型架构演进

FFN：GELU → SwiGLU

GPT-2 用 GELU 做隐式筛选。LLaMA 用 SwiGLU——把信息分两路：一路学门控（哪些信息放行），一路学内容（放行什么信息），两路逐元素相乘。门控 + 内容的显式分离比 GELU 的隐式筛选更强。

bias：有 → 无

LayerNorm 的 β 已经能替代 bias 的大部分功能。去掉 bias 简化实现、不减性能，还省去了 weight decay 时对 bias 该不该加正则化的纠结。

位置编码：可学习表 → RoPE

LLaMA 用旋转位置编码（Rotary Position Embedding），天然支持任意长度外推——训练时用 2K 上下文，推理时可扩展到 32K 甚至更长。

11. GQA：Grouped-Query Attention

现代大模型（LLaMA-2/3、Mistral、Qwen）的标配。

演变：MHA（每个头独立 K、V）→ MQA（所有头共享一套 K、V，太激进）→ GQA（折中：分若干组，组内共享 K、V）。

为什么 K、V 可以共享但 Q 不行？ Q 是"我在找什么"——每个头在找不同的东西，多样性来自 Q。K 是"我提供什么标签"、V 是"我的内容"——同一个 token 的索引和内容只有一份，不需要重复存储。GQA 让 KV Cache 缩小若干倍，困惑度几乎不变。

12. FlashAttention 与 PagedAttention

两者优化的是完全不同的问题，正交使用。

FlashAttention：计算的 IO 优化

原版 Attention 每一步都把整个 N×N 注意力矩阵在显存（HBM）和计算单元间搬运。FlashAttention 采用切块策略——把 Q、K、V 切成小块，在片上高速缓存（SRAM）内算完就扔，不写回显存。同时用 Online Softmax（不需要看到整行就能算 softmax 的数学 trick）让切块计算可行。

效果：HBM 读写降为原来的 1/N，显存省 90%+，速度提升数倍。

PagedAttention：KV Cache 的内存管理

多请求并发推理时，每个请求的 KV Cache 需要预分配最大长度连续显存 → 碎片严重。PagedAttention 把 KV Cache 切成页（类似操作系统的虚拟内存分页），按需分配不预占，不要求连续，用页表索引。

效果：显存利用率从 <40% 提升到 >95%。

13. 预训练 / SFT / RLHF

我们讨论的所有架构细节，三阶段完全相同，变的是数据和 loss：

预训练：万亿 token 互联网文本 →"下一个词预测"的交叉熵 loss → 得到一个"会接话"的基础模型（99.9% 计算量）
SFT：十万条人工标注问答对 → 同样的交叉熵 loss（user 部分不算）→ 变成"会对话"（0.05% 计算量）
RLHF：人类偏好对比数据 → 偏好 loss / PPO → 变成"回答让人满意且对齐人类价值观"的最终模型（0.05% 计算量）

14. 完整前向传播（端到端流程）

输入 token IDs → W_E 查身份向量 + W_P 查座位向量 → 相加 = 初始表示

12 次循环:
    LayerNorm（洗数据）→ QKV投影 → 拆12头
    → 每头: QK^T/√64 + 因果掩码 → softmax → ×V
    → 拼回头 × W_O（融合专家意见）
    → + 残差（存量 + 上下文增量）
    → LayerNorm（再洗）→ W₁ 升维 → GELU 筛选 → W₂ 降维
    → + 残差（存量 + 消化增量）

最终 LayerNorm → @ W_E^T（和所有 token 比点积）→ softmax → 取概率最高

最精妙的悖论：这 300 行代码的全部逻辑，论文中 FFN 部分只给了 4 行描述——一个拥有上万个概念槽位、可定位、可编辑的知识库，在 2017 年只是 "two linear transformations with a ReLU activation"。发明者不一定是理解者。

Loop Engineering 的火爆，不过是控制论的一次迟来兑现

Sat, 20 Jun 2026 00:00:00 GMT

Loop Engineering 的火爆，不过是控制论的一次迟来兑现

TL;DR： "Loop engineering" 最近在 LangChain、swyx、Andrej Karpathy 那边都有讨论。把四层 loop 拆开对照控制论，结构上的对应关系一目了然：Agent Loop 是开环控制，Verification Loop 是闭环负反馈，Event Loop 是自主触发，Hill Climbing 是自适应控制。控制论在 1948 年就有这张图，loop engineering 不是新发现。而 2026 年涌现的 self-evolving agent 研究——APEX、MemEvolve、SkillCAT——看起来更进一步，但用同一套镜头看：它们仍然在 Loop 4（自适应控制）的边界以内，fitness function 始终是外部给定的。控制论预言的下两层——架构自重组（Level 5）和目标自审查（Level 6）——目前没有任何系统真正实现。

一、Loop Engineering 在说什么

1.1 四层嵌套架构

先看 LangChain 的 Sydney Runkle 在《The Art of Loop Engineering》里描述的架构。四层嵌套循环：

Loop	做了什么	LangChain 里的叫法
Level 1: Agent Loop	模型反复调用工具直到任务完成	`create_agent`
Level 2: Verification Loop	输出被评分器检查，不通过则带反馈重试	`RubricMiddleware`
Level 3: Event Driven Loop	事件触发 agent 运行，持续在后台工作	`LangSmith Deployment` + cron/webhook
Level 4: Hill Climbing Loop	分析 trace 数据，自动改进 prompt/工具配置	`LangSmith Engine`

逻辑清晰：每往外一层，系统的自主性和自适应能力提升一档。LangChain 的卖点是这些 primitive 已经有现成的实现，不需要从头搭。

这四层结构，每一层都能在半个多世纪前的控制论文献里找到精确的对应。在展开这个映射之前，有个容易混淆的概念值得先厘清。

1.2 前身：Harness Engineering

在"loop engineering"之前，LangChain 先有一个词——harness engineering。Vivek Trivedy 在今年二月的《Improving Deep Agents with harness engineering》里记录了他们的 coding agent 如何在不换模型、只改 harness 的情况下，从 Terminal Bench 2.0 的 Top 30（52.8%）升到 Top 5（66.5%）。

两个词经常被混用，但层次关系清楚：

Loop Engineering（外层架构：loop 之间如何嵌套和衔接）
  │
  └─ Harness Engineering（内层配置：每个 loop 内部的 prompt / tool / middleware 怎么调）

Harness engineering 关心单个 loop 内部的旋钮——系统 prompt 怎么写、用什么工具、middleware 怎么挂、上下文怎么注入。Vivek 的实验只动了三个旋钮（System Prompt、Tools、Middleware），模型没换，Terminal Bench 上提了 13.7 分。

这些都在 Loop 1 和 Loop 2 内部操作。Harness engineering 假设你已经有了一组 loop，问的是每个 loop 里面怎么调到最优。Loop engineering 问的是更上一层：你需要几个 loop？它们怎么嵌套？反馈信号怎么跨 loop 传递？

用控制论的术语：harness engineering 是在调 PID 参数，loop engineering 是在设计控制回路拓扑。区分清楚了，再看每层 loop 的控制论对应才不会混。

二、用控制论的镜头看四层 Loop

2.1 Agent Loop = 开环控制

模型 → 工具调用 → 观察结果 → 再次调用 → ... → 完成

控制论里的开环控制（open-loop control）：系统按预设逻辑执行，过程中不接收外部校验信号。一个没有 verification 的 agent 就是这样——它执行，但不知道执行的结果是否正确。

开环控制的优势是快，不需要等反馈。代价是没有纠错能力。这就是 Loop 1 需要被包裹的原因：开环在复杂任务上的可靠性不够。

2.2 Verification Loop = 闭环负反馈

agent 输出 → 评分器检查 → 不通过? → 带错误信息重试 → 重新输出

这是控制论最核心的概念：闭环负反馈（closed-loop negative feedback）。Norbert Wiener 在 1948 年的《控制论》里用整整一本书讨论这个机制。恒温器测到温度偏低→开加热→温度够了→关加热，和 agent 生成文档→评分器发现链接断裂→带反馈重试→通过，是同一张控制流图。差别只在传感和执行的技术实现上。

这个 loop 的工程关键在评分器（grader）的设计。控制论的良调节器定理（Conant & Ashby, 1970）：任何有效的调节器必须是其所调节系统的模型。 对应到 agent 工程：grader 必须对"好输出"有足够精确的表征能力。用简单正则匹配评分复杂文档，grader 不是良调节器，verification loop 会产生大量假阴性或假阳性。

LangChain 的 RubricMiddleware 用 LLM 当评分器，本质是用更灵活的模型逼近"好输出"的分布。方向对，但也引入了新问题——评分器本身有偏差和方差。闭环系统的稳定性分析：反馈回路中的噪声会被放大。LLM-as-judge 不够稳定，verification loop 会把小误差累积成大问题。

2.3 Event Driven Loop = 自主触发与系统整合

外部事件（Slack 消息、定时触发、webhook）→ agent 运行 → 输出写回系统

这是 agent 从"被调用"变成"自运行"的关键转变。控制论对应的是自主系统（autonomous system）——系统持续感知环境变化并自主响应，不再等待输入。工业控制领域叫 SCADA：传感器持续监测，阈值触发控制动作。Agent 挂在 cron 或 webhook 上，概念上没有区别。做过 DevOps 的人会认出这就是事件驱动架构——Kafka、GitHub Actions、Lambda 触发器做的是同一件事。

2.4 Hill Climbing Loop = 自适应控制与双重学习

trace 数据 → 分析 agent → 发现模式 → 改进 prompt/工具/评分器 → 部署 → 重新产生 trace → ...

这是四层中唯一会在运行过程中修改自身配置的一层，也是控制论和 AI 交汇最深的地方。

控制论里叫自适应控制（adaptive control）。标准反馈控制假设系统模型不变，自适应控制允许系统在运行中修改控制参数。飞机自动驾驶仪在不同高度和速度下，空气动力学特性不同，控制器实时调整参数。

Agent 的 Hill Climbing Loop 做同一件事：分析历史 trace，识别 prompt 或工具配置中的薄弱点，自动修改，然后观察新配置下的表现。这形成了双环学习（double-loop learning, Argyris & Schön, 1978）结构：

内环（Loop 1-3）：执行任务 + 验证 + 触发
外环（Loop 4）：  观察内环 → 改配置 → 提升内环表现

这层也带来控制论中最棘手的问题：稳定性与振荡。自适应控制系统如果参数更新缺乏阻尼，会陷入振荡——改得过猛导致表现恶化，恶化触发更大的改动，系统发散。

LangChain Engine 做的是 trace → 分析 → 建议 → 人工 review → 部署 的半自动管道。"人工 review"不是 UX 的点缀，是控制论意义上的阻尼器（damper）——防止自适应反馈回路增益过高导致系统震荡。没有阻尼的自适应系统会把自己调死。

四层映射到这里就完整了。随之而来的问题是：这些框架七十年前就有，loop engineering 为什么是现在才火？

三、为什么说"这不过是自然导向"

Loop engineering 在 2026 年火起来，不是因为它是突破性发现，而是工程实践追上了理论早已走过的路。

3.1 历史上的预演

控制论从诞生就在回答一个问题：如何让系统在没有人类持续干预的情况下可靠地完成目标？ 答案始终是同一个：层级化的反馈回路。

1948 年 Wiener 写《控制论》，讨论的是防空火炮的伺服机构。1970 年代，Stafford Beer 把框架应用到组织管理，提出活系统模型（Viable System Model）——五个层级的嵌套反馈回路，从操作单元到战略规划。1980 年代，IBM 提出自治计算的 MAPE-K 循环（Monitor-Analyze-Plan-Execute-Knowledge），是 Loop 4 的直接前身。

把 LangChain 的四层 Loop 和这些历史框架对比，结构同构：

LangChain Loop	Viable System Model	MAPE-K
Agent Loop	System 1（操作单元）	Execute
Verification Loop	System 2（协调与稳定性）	Monitor + Analyze
Event Loop	System 3（内部集成）	Plan
Hill Climbing	System 4/5（适应性与策略）	Knowledge

任何需要自主完成目标的自适应系统，最终都会收敛到同一组架构模式。

3.2 为什么是现在

框架早就存在，为什么 loop engineering 现在才火？三个原因。

LLM 的不可靠性让反馈回路从可选变成必需。 传统软件的失败模式可预测（空指针、超时、类型错误），可以在代码层面做防御性编程。LLM 的失败模式是分布性的——可能生成语法正确但语义错误的输出，无法预判。唯一可靠的策略是在每个输出点后面加检查点，这就是 Loop 2 存在的根本原因。

Agent 的自主性诉求推高了 loop 的层级。 如果 agent 只被人在聊天框里调用，Loop 1 就够了。一旦要让它"在后台自己跑"（Loop 3）、"越跑越好"（Loop 4），就自然走进了多层级反馈架构。需求本身把工程实践推到了这里。

Harness engineering 的边际收益在递减，推着工程师往上走一层。 当改 prompt、换工具、调 middleware 的收益开始稳定，下一步自然是问：这个 loop 本身的结构对不对？要不要在外面再套一层？从调旋钮到设计回路拓扑，是工程实践自然走到的地方，不是某个框架推出来的。

四、控制论给 Loop Engineering 的警告

既然是同一套东西，控制论几十年积累的工程教训也一并继承了。三个容易被忽略的陷阱：

4.1 反馈延迟与振荡。 Verification Loop 里评分器检查→反馈→模型重试的循环有延迟。如果反馈信息不够精确（"这篇文档不够好" vs "第三段的 API 参数名错了"），模型会在模糊反馈下反复生成，产生类似积分饱和（integral windup）的效果——越调越偏。控制论的解法：反馈信号需要足够的带宽，调度周期需要匹配系统响应时间。

4.2 层级间的耦合与级联失效。 Hill Climbing Loop 在改 prompt 时，改的是 Loop 1 和 Loop 2 依赖的基础设施。如果 Engine 基于不具代表性的 trace 数据做了错误优化（比如过度拟合了上周的高频问题类型），会同时破坏所有下游 loop 的表现。对应控制论的级联失效（cascading failure）——上层控制器的错误通过层级传播，放大而非抑制扰动。

4.3 自适应系统的目标漂移。 Loop 4 需要明确的优化目标。如果目标是"提高用户满意度"但只能测量"减少验证失败次数"，agent 会学会写更容易通过验证的文档，而不是更好的文档。你给了代理指标（proxy metric）而非真实目标，结果是目标函数的错误指定——Goodhart 定律的工程化表述。

4.3 说的不只是一个工程细节：它在暗示 Loop 4 有一个结构性的盲区——它能优化给定的目标，但不能监管目标本身是否正确。这正是控制论下一层要解决的问题。

五、控制论预言的下一层

Loop engineering 的四层已经对应了控制论从开环到自适应的完整路径。按这条线继续走，控制论给出了两个方向的预言。

5.1 自适应控制的上限：Ashby 的超稳定性

Loop 4 的 Hill Climbing 是自适应控制——目标不变，调整参数。控制论里，自适应控制的下一层叫超稳定系统（ultrastable system，Ashby 1960）：当参数调整无效时，系统不再继续调参，而是重组控制结构本身。对 agent 来说就是：发现单 agent 的 verification loop 无法捕捉某类错误，不是继续调 prompt，而是自动插入一个专职检查器，改写 Loop 2 的拓扑。

Loop 4 识别到：过去 N 轮优化收益递减
         ↓
Level 5 Loop 介入：不是参数问题，是架构问题
         ↓
提议架构变更 → 人工确认 → 部署新架构 → Loop 4 重新运行

2026年的 self-evolving 论文群让这个边界变得清晰。APEX（arXiv 2606.15363，今年六月）是目前走得最远的——一个三层联合自进化框架，L3 做 workflow topology 选择，改的是哪些 agent 节点之间有连接，而不只是 prompt 参数，在 Terminal-Bench 上比单轴 harness 优化提升了 90%。MemEvolve（arXiv 2512.18746，去年十二月）演化的是记忆系统的架构本身（encode/store/retrieve/manage 的组织方式），控制结构参与了演化过程。

但这两个系统都没有越过同一条线：fitness function 仍然是外部给定的。 APEX 从预设候选拓扑里筛选，MemEvolve 由任务基准评分驱动演化方向。SEAGym（2606.17546）这篇评测论文直接把边界写进了定义里：当前所有 self-evolving 系统改变的是 "agent harness"——prompts、memory、tools、middleware、runtime state——没有一个在改 loop 的嵌套结构本身。

SkillCAT、Socratic-SWE、OpenSkill 这批 skill 自进化工作，本质上也是 harness 调优：技能库扩张是参数空间扩展，技能拓扑是更精细的检索结构。改变的还是旋钮，只是旋钮的组织形式变复杂了。

5.2 更深一层：二阶控制论

超稳定性解决的是"怎么达到目标"的架构问题。控制论还有更深一层——二阶控制论（second-order cybernetics，von Foerster，1970s）：质疑目标本身是否正确。

层次	做了什么	控制论对应
Loop 4	优化参数，逼近给定目标	自适应控制
Level 5	优化架构，达到给定目标	超稳定系统
Level 6	质疑并修正目标本身	二阶控制论

这正是 Goodhart 定律在 agent 系统里的落点：Loop 4 和 Level 5 都在优化 fitness function，无法识别 fitness function 本身已经偏离了真实目标。

ANCHOR（2606.06114）是2026年最直接触及这个问题的工作。它发现 self-evolving 系统存在 safety drift——自主演化过程中，"安全合规"从目标悄然变成了需要规避的约束。ANCHOR 的解法是引入模拟人类监督做纠偏。但这是在系统外部挂一个阻尼器，不是系统自身识别出"我的优化方向偏了"。Q-Evolve 走了半步：系统参与构建过程奖励的标准，但仍以任务最终结果为锚点——它问的是"这一步有没有帮完成任务"，不是"这个任务值不值得完成"。

真正的 Level 6 需要一个运行时的检测器：识别指标与真实目标之间的系统性背离，并触发对 fitness function 本身的修订。这个闭环目前不存在于任何生产系统。它也不只是工程问题——benchmark-driven 的开发范式天然把 fitness function 放在外部，而 Level 6 要求的是对这个外置假设的质疑能力。

5.3 往上走的代价

Level 5 和 6 各自解决了一层问题，但控制论也给出了追求它们的代价：每往上一层，两个成本相应放大。

良调节器定理的要求指数上升。 Level 5 的 loop 要对整个四层架构建模，Level 6 要对 Level 5 建模。系统的复杂性以层级速度累积，调节器的能力必须匹配——没有人能保证 LLM 在每一层都有足够的建模能力。

人类可审计性持续下降。 Loop 4 改 prompt，人还能 review。Level 5 改架构，review 成本急剧上升。Level 6 质疑优化目标，已经进入了没有明确 ground truth 的领域——审计的尺子本身在变。

控制论的结论：层级越高，越需要更强的外部锚定（external grounding）——来自人类价值、业务约束或物理世界的不可变参照。没有锚点，系统会把自己优化到任何方向。ANCHOR 用人类监督做阻尼器、SEAGym 把 fitness function 外置于 harness 定义之外，本质上都是在用工程手段补这个锚点的缺失。这不是工程问题的解法，是在承认 Level 6 还没有闭合的理论答案。

六、收尾

Loop engineering 是个好名字，降低了理解门槛。但它描述的不是新范式——四层 loop 是反馈控制从 Wiener（1948）经 Beer、MAPE-K 一路走到今天的自然落点，工程实践只是追上了理论早已画好的图。

2026 年涌现的 self-evolving 浪潮大概率会走一遍同样的路：从调旋钮（harness 优化）到改架构（超稳定性），再到某一天不得不面对"旋钮的标准是谁定的"这个问题。每一层看起来都是突破，但从控制论往回看，都是有预言的。

这条路最终会撞上同一堵墙：fitness function 是设计决策，不是客观存在。benchmark-driven 的整个开发范式都在假装它是后者——用基准分数衡量进步，用通过率定义成功——但没有人回头问这个基准本身测的是不是真正想要的东西。这不是可以用更好的工程绕过去的事情。

值得问的不只是"你的 hill climbing loop 有没有阻尼"，还有：你的 fitness function 本身，有没有人质疑过它是否测的是你真正想要的东西？

Design for AI, Not AI for Design

Tue, 10 Mar 2026 00:00:00 GMT

Design for AI, Not AI for Design

副标题：读 OpenAI《Harness Engineering》后的工程笔记

OpenAI 在 2026 年 2 月 11 日发布的《Harness Engineering》，我觉得最值得读的地方，不是“AI 又能写多少代码”，而是它把一个更底层的工程变化说清楚了。文章讲的是一个内部 beta 产品：五个月，从空仓库起步，接近一百万行代码，大约 1500 个 PR，内部已经有日活用户，也有外部 alpha 测试者。更重要的是，它们把约束定得很死: 人不手写代码，所有代码都由 Codex 生成，包括应用逻辑、测试、CI 配置、文档、可观测性配置和内部工具。

这个约束听起来有点极端，但也正因为极端，很多平时能靠人肉补过去的问题都被暴露出来了。原文里有一句话我觉得可以当整篇文章的总纲: Humans steer. Agents execute. 工程师没有消失，只是从“直接写代码”转向了“设计环境、表达意图、搭建反馈回路，让 agent 能稳定工作”。

先说结论：这篇博客真正重要的结论，不是 agent 能替代多少编码劳动，而是当代码生成变便宜之后，真正稀缺的资源会变成人的时间和注意力。谁能把仓库、工具、验证、知识和规则设计得对 agent 更可读，谁就更有可能把吞吐变成可靠性，而不是把混乱放大。

图 1：变化的重点不只是“谁在写代码”，而是工程重心从手写实现转向环境、约束和反馈系统。

Agent环境

原文开头其实已经把实验边界说得很具体了。第一，仓库是空的，第一笔提交发生在 2025 年 8 月下旬。第二，初始脚手架也不是人写的，而是用 Codex CLI 配合 GPT-5，从一小组现成模板生成出来的，包括仓库结构、CI 配置、格式化规则、包管理器设置、应用框架，甚至最初的 AGENTS.md。第三，这不是“为了演示而演示”的代码生成实验，因为这个产品后来真的被几百个内部用户使用，其中包括日常重度用户。

这些细节决定了文章的重点不是“模型会不会写 CRUD”，而是“如果默认执行者是 agent，工程环境应该长什么样”。OpenAI 的经验很明确: 早期进展比预期慢，不是因为 Codex 不会写，而是因为环境定义得不够充分。agent 缺工具，缺抽象，缺内部结构，所以无法朝着高层目标稳定推进。

这也是我读完后最认同的一点。过去我们说“工程环境”，常常是在讲 IDE、包管理、构建系统和部署脚本；但在 agent-first 的开发方式里，环境更像一整套可执行工作条件。它要回答的不是“人能不能舒服地写代码”，而是“agent 能不能自己拿到上下文、自己验证结果、自己知道边界在哪里”。原文把这个变化说得很直白: 团队的主要工作不再是写代码，而是设计环境、指定意图、构建反馈回路。

Agent如何闭环？

原文里“闭环”不是抽象说法，而是很具体的工程能力。随着代码吞吐上升，OpenAI 团队的瓶颈很快从“能不能产出代码”变成了“人类 QA 能不能跟上”。因为真正固定不变的稀缺资源，是人的时间和注意力。

所以他们做的事不是继续优化 prompt，而是把应用本身变得对 Codex 可见。比如，他们让应用支持按 git worktree 启动。这个机制可以理解成“给每次改动分一个独立工作副本”，这样 agent 改代码时能在隔离实例里把应用跑起来，不会互相干扰。又比如，他们把 Chrome 开发者工具协议接进运行环境，再配上处理页面结构、截图和导航的技能。这样 agent 就不只是“改了前端代码”，而是真的能自己点开页面、复现 bug、验证修复、判断界面行为是否符合预期。

同样的思路也被用在可观测性上。原文明确提到，日志、指标和调用链追踪都会通过一套只服务于当前任务的本地观测环境暴露给 Codex，任务结束后再一起销毁。文中提到了几种查询语言，但核心意思并不复杂: agent 不只是能看“报错了没有”，而是能主动查日志、看性能指标、顺着一次请求的调用链找到慢点和错点。这一步很关键，因为它把很多以前只能靠人来判定的要求，变成了 agent 可以自己验证的问题。比如“服务启动必须在 800ms 以内”，或者“这四条关键用户路径上不能有任何一步超过两秒”。

文章里还有一个很有分量的细节：单次 Codex run 经常会在一个任务上连续工作六个小时以上，而且很多时候人已经去睡觉了。这个细节不是在夸模型勤奋，而是在说明一件事: 只有当闭环能力足够完整，长时任务才有意义。否则长时间运行只是在更长时间里持续瞎猜。

图 2：在 agent-first 环境里，反馈回路不是附属品，而是让长时任务成立的前提。

agent如何发现知识

原文在这一节里讲得非常清楚: 给 Codex 一张地图，而不是一本 1000 页说明书。这个说法比“多写文档”准确得多。问题不是文档多不多，而是知识有没有被组织成 agent 能导航、能校验、能持续维护的结构。

OpenAI 试过“大一统 AGENTS.md”的方案，结论是失败，而且失败方式很典型。上下文本来就是稀缺资源，一个巨大的指令文件会把任务本身、代码本身和真正相关的文档一起挤出去。信息一旦太多，就会变成没有信息。更糟的是，这种总纲式文件很容易快速腐烂，而且很难做机械校验，无法检查覆盖度、时效性、负责人和交叉链接，最后就会漂。

所以他们把 AGENTS.md 从“百科全书”降成了“目录”。原文提到，那个文件大约只有 100 行，主要作用是作为注入上下文时的入口索引。真正的知识系统在结构化的 docs/ 目录里，而且它被明确当成仓库内的主记录源，也就是“以仓库里的版本化文档为准”。文中给了一个知识库布局示例，但没必要把名字全背下来。你只要抓住它的分工就够了: 设计文档有单独目录，执行计划有单独目录，产品规格、自动生成的参考资料和一些顶层规则文档都各归其位。

这几个点在我看来特别有价值。第一，设计文档不是堆在一起，而是有索引、有验证状态，也有一组明确原则。第二，计划被当成一等产物。小改动用轻量计划，复杂任务就写成版本化的执行计划，把进度和决策日志一起签进仓库。第三，技术债本身也是版本化知识，不再只是团队脑子里的“以后再说”。

原文还强调了一件很容易被忽略的事: 这些文档不是靠自觉维护，而是靠机械校验维护。专门的 linter 和 CI 任务会检查知识库是否最新、是否交叉链接、结构是否正确；另外还有一个周期性运行的“文档整理 agent”，专门扫描已经过时或与真实代码行为不一致的文档，然后发修复 PR。这个做法很工程化，也很关键，因为 agent 时代过期文档的危害，通常比“没有文档”更大。

图 3：知识系统的重点不是“写很多文档”，而是让知识在仓库里成为可导航、可验证、可维护的系统。

工程品味如何传达给agent

我上次写这一节时，用了“把建议升级成法律”这种说法，意思没错，但还是不够精确。原文这里更强调的其实不是抽象的“风格”，而是那些能被机械执行的约束: 不变量、清晰边界、可预测结构。

OpenAI 的做法不是去微观规定每个实现细节，而是先把不会轻易变的东西钉死。文章举的例子是“在边界处解析数据形状”。意思是，外部数据一旦进入系统，就要先把结构说明白、校验清楚，别让模糊的数据一路流进核心逻辑。他们要求 Codex 守住这条规则，但不规定一定要用哪一个具体库。这种做法很重要，因为它区分了“必须守住的约束”和“可以局部自由发挥的实现”。

真正的骨架是一套很刚性的分层架构。原文明确写了每个业务域里的依赖方向: Types → Config → Repo → Service → Runtime → UI。翻成普通话，大致可以理解成: 类型定义在最前面，配置其次，数据访问再往后，之后是服务逻辑、运行时适配，最后才是界面层。跨领域的公共能力，比如认证、连接器、遥测和功能开关，不允许随意渗透，而是通过一个明确入口进入。除此之外的依赖边，一律不允许。

这些规则不是靠 code review 口头提醒维持的，而是通过自定义 linter 和结构测试机械执行。这里术语要分清: linter 更像一类检查器，用来守住架构边界和依赖方向；lint 则是某一条具体规则，比如结构化日志、类型命名、文件大小限制、平台可靠性要求。原文还提到一个很实用的做法: 因为这些规则是团队自己写的，所以报错信息也能自己定义，直接把修复建议写进错误信息里，让 agent 在失败时知道下一步怎么改。

这一节我觉得最有分量的一句话是: 在 human-first 工作流里，这些规则可能显得有点吹毛求疵；但对 agent 来说，它们是乘数。规则一旦编码，影响就会同时作用在整个仓库，而不是一次次靠人去重复讲。

图 4：对 agent 来说，真正有用的“品味”不是抽象偏好，而是被编码进 linter、lint 和结构测试里的约束。

AGENT工作流程

原文把工程师角色改写得很具体，不只是“人负责高层、agent 负责执行”这么一句话。更接近真实情况的是，工程师先用 prompt 把任务讲清楚，让 agent 去做第一版实现并开 PR。到这里工作其实只完成了一半，后面的流程才是重点。

原文里这条工作流大致是这样跑的。第一步，agent 在本地自审，先自己检查改动是否符合仓库规则。第二步，它会主动拉起额外的 agent review，有的在本地跑，有的在云端跑，相当于再加几层自动审查。第三步，收到反馈后，它要自己回评论、自己继续改，而不是每轮都等人重新接手。第四步，如果构建失败、测试失败或者 review 又提出了新问题，它就继续迭代，直到这轮审查通过。原文甚至把这个过程起了个内部玩笑式名字，但核心并不在名字，而在这是一条“生成 - 自审 - 互审 - 修正 - 再验证”的闭环链路。

这里还有两个很关键的技术细节。第一，Codex 直接使用标准开发工具取上下文，包括 gh、本地脚本和仓库内置技能，而不是等人把外部信息手动复制进命令行。第二，人类可以 review，但不是每次都必须亲自下场；随着流程成熟，他们把越来越多的审查工作推向了 agent 之间互相处理。

这也直接带来了合并策略的变化。原文用了一个很明确的小节标题: 吞吐会改变合并哲学。当 Codex 的吞吐远远超过人的注意力时，很多传统工程规范会开始变得适得其反。它们仓库的做法是尽量减少阻塞式合并门槛，PR 尽量短命，偶发的测试抖动通常通过后续 run 修掉，而不是无限期卡在那儿。背后的逻辑很直接: 在高吞吐环境里，修正很便宜，等待很昂贵。

当然，原文也没有把这件事写成普适真理。它明确说，这种做法放在低吞吐环境里会是不负责任的；在他们这个前提下，才经常是对的 trade-off。这个限定很重要，因为它说明 merge 策略不是孤立方法，而是建立在前面那整套工具、约束和反馈系统上的。

图 5：吞吐变高之后，很多团队真正昂贵的成本会从“修正”转向“等待”。

ai自主性可以到哪一步

原文没有把“自主性”讲成一个模糊口号，而是列出了一组已经能端到端完成的具体动作。随着测试、验证、review、反馈处理和恢复流程越来越多地被编码进系统，仓库最近跨过了一个门槛: 给定一个 prompt，Codex 已经可以验证当前代码状态、复现 bug、录一段失败视频、实现修复、驱动应用验证结果、再录一段修复后视频、打开 PR、响应 agent 和人工反馈、修掉构建失败、只在需要判断时升级给人，最后自己合并。

这份清单很重要，因为它把“agent-generated”这个词从“会写很多代码”扩展成了“能完成开发生命周期里一整串动作”。原文甚至专门有一节解释这个词的边界: 所谓 agent-generated，不只是产品代码和测试，还包括 CI 配置、发布工具、内部开发者工具、文档和设计历史、评测用的验证框架、review 评论与回复、管理仓库本身的脚本，以及生产仪表盘的定义文件。

但原文同样留了刹车。它明确说，这种自主行为高度依赖这一个仓库的结构和工具链，不应假定可以在没有类似投入的团队里自然复现。换句话说，自主性不是模型单方面长出来的，而是工程系统一点点“喂”出来的。

如何控制agent的代码熵？

这一节基本是在回答一个很现实的问题: 如果 agent 会复制仓库里已经存在的模式，那它也会复制坏模式。原文说得很直接，full agent autonomy 会带来新的问题，Codex 会复用库里那些不均匀、次优甚至有点脏的做法，时间一长就会 drift。

OpenAI 一开始是靠人清理的。团队过去每周五都要花一整天，也就是一周 20% 的时间，去收拾所谓的 “AI slop”。这个数字很有说服力，因为它说明问题不是抽象的审美焦虑，而是实打实的产能损耗。后来他们把做法换掉了: 把一组 “golden principles” 编进仓库，再建立一个周期性清理流程。

原文举了两个例子。第一，尽量使用共享工具包，而不是到处手搓 helper，把那些不该变的规则收在中心位置。第二，不允许用“先猜再说”的方式试探数据结构，要么在边界验证，要么依赖带类型的 SDK，避免 agent 在猜出来的结构上继续搭代码。然后，他们再跑一组后台 Codex 任务，定期扫描偏离、更新质量评分、发针对性的重构 PR。这些 PR 大多数能在一分钟内看完，并自动合并。

原文把这套机制类比成 garbage collection，我觉得这个类比非常准确。技术债像高利贷，持续小额偿还，通常比拖到最后一起爆掉更划算。尤其在 agent-first 的代码库里，人的“品味”不能只体现在 review 评论里，而要尽可能被记录一次、执行无数次。

图 6：agent 会放大仓库里已经存在的模式，所以清理机制必须和生成机制一样常态化。

对于个人开发者

对个人开发者来说，这篇文章并不意味着“你也要先砸一整套 OpenAI 级别的平台基础设施”。更有启发的是它的顺序感。先让 agent 看得见，再让 agent 做得快；先把知识放进仓库，再谈让它自主；先把约束编码，再谈提高吞吐。

如果要落到手上能做的事，我觉得至少有四件值得先做。第一，给 agent 一个最小但完整的验证回路，哪怕只是本地可启动、能跑测试、能看日志、能做基础页面检查。第二，不要把 AGENTS.md 写成总手册，把它写成入口目录，然后把规范、计划、架构说明和技术债记录真正沉进仓库。第三，尽早把最关键的不变量写成 linter、具体 lint 规则、结构测试或 CI 规则，不要全靠 review 习惯维持。第四，把清理当成常规任务，而不是“项目后期再收拾”。

我现在更愿意把这篇文章的题目读成一句工程建议，而不是一句口号。Design for AI, not AI for design。重点不是“让 AI 进入设计流程”，而是先把你的工程系统整理成一种 agent 能理解、能验证、能维护的形态。原文真正讨论的，也一直是这个方向。

Python3 核心概念回顾

Wed, 25 Feb 2026 00:00:00 GMT

python回顾

字典（键与值一一对应），列表（自由的数组），元组（只读列表，成员不变）列表需要注意的是extend，appendix，pop等字典（列表不可以作为键，因为其需要不可变）

函数

函数中需要理解的一点是变量与类型的区别：类型是真实存在的，变量只不过的指向类型的标签，所以python中的变量才可以自由变换。也是因此所以可变和不可变变量的根本区别是：修改可变变量的时候，是修改了类型本身，而修改不可变变量的时候，是修改了标签所引用的对象对象有类型，变量无类型

局部变量与全局变量

局部标签与全局标签，可以使用global进行遮蔽

参数

必备参数关键字参数这两个区别主要是传参的时候有没有显式的写出，如果没有，就会按照必备参数一个个按顺序填，关键字参数则可以在顺序不对的时候也自动匹配填入可变参数使用 * args把所有参数吸收默认参数如果不传就用默认值

模块

不要用from...import*（命名空间污染）直接import的时候，加入库名称.函数补充__name__函数一个模块被另一个程序第一次引入时，其主程序将运行。

如果我们想在模块被引入时，模块中的某一程序块不执行，我们可以用 name 属性来使该程序块仅在该模块自身运行时执行。

#!/usr/bin/python3
# Filename: using_name.py

if __name__ == '__main__':
   print('程序自身在运行')
else:
   print('我来自另一模块')

运行输出如下：

$ python using_name.py
程序自身在运行

$ python
>>> import using_name
我来自另一模块

说明：每个模块都有一个 __name__ 属性。

如果模块是被直接运行，__name__ 的值为 __main__。
如果模块是被导入的，__name__ 的值为模块名。

推导式

# 列表
[out_exp_res for out_exp in input_list if condition]
[函数 for 变量 in 列表 if 条件]

# 字典
{ key_expr: value_expr for value in collection if condition }

# 集合
{ expression for item in Sequence if conditional }

# 元组
(expression for item in Sequence if conditional)

迭代器与生成器

iter()

创建迭代器对象

next()

迭代器循环，可以使用 raise StopIteration 来结束迭代

生成器

yield

产出值并暂停： 当程序执行到 yield 时，它会向调用者返回 yield 后面的值，然后立刻暂停在这一行代码，停止向下执行。
保留运行状态： 函数被暂停时，它内部所有的变量状态、指令指针等都会被完整保留下来。
恢复执行： 当我们下次再调用 next() 方法请求数据时，代码会从上次 yield 暂停的地方紧接着往下执行，直到遇到下一个 yield

def countdown(n):
    while n > 0:
        yield n
        n -= 1

# 创建生成器对象
generator = countdown(5)

# 通过迭代生成器获取值
print(next(generator))  # 输出: 5
print(next(generator))  # 输出: 4
print(next(generator))  # 输出: 3

# 使用 for 循环迭代生成器
for value in generator:
    print(value)  # 输出: 2 1

with 语句

使用with来管理资源分布

想要使用with的对象需要有__enter__ 和__exit__方法，帮助自动处理与释放资源

# 同时打开多个文件
with open('input.txt', 'r') as infile, open('output.txt', 'w') as outfile:
    content = infile.read()
    outfile.write(content.upper())

最佳实践

优先使用 with 管理资源：对于文件、网络连接、锁等资源，总是优先考虑使用 with 语句
保持上下文简洁：with 块中的代码应该只包含与资源相关的操作
合理处理异常：在自定义上下文管理器中，根据需求决定是否抑制异常
利用多个上下文：Python 允许在单个 with 语句中管理多个资源

lambda

lambda arguments: expression

numbers = [1, 2, 3, 4, 5]
squared = list(map(lambda x: x**2, numbers))
print(squared)  # 输出: [1, 4, 9, 16, 25]

装饰器

函数装饰器

Python 装饰器允许在不修改原有函数代码的基础上，动态地增加或修改函数的功能，装饰器本质上是一个接收函数作为输入并返回一个新的包装过后的函数的对象。本质上是接收函数返回wrapper

def my_decorator(func):
    def wrapper():
        print("在原函数之前执行")
        func()
        print("在原函数之后执行")
    return wrapper

@my_decorator
def say_hello():
    print("Hello!")

say_hello()

疑问：return在这里起什么作用？外层return是my_decorator，作用是把被装饰函数替换成wrapper函数。

加上括号 wrapper()：意思是"立刻执行这个函数，并把执行后的结果交出去"。
不加括号 wrapper：意思是"我不执行它，我把这个函数的**本体（遥控器）**直接交出去"。

def my_decorator(func):
    # 这里是外层函数
    print("【额外逻辑】我在定义时就被执行了！")
    return func  # 只能把原函数原封不动地退回去

@my_decorator
def greet(name):
    print(f"Hello, {name}!")

# 当代码运行到上面 @my_decorator 那里时，屏幕上就已经打印了：
# 【额外逻辑】我在定义时就被执行了！

# 等你真正在下面调用函数时：
greet("Alice")
greet("Bob")

# 屏幕上只会输出：
# Hello, Alice!
# Hello, Bob!

一般来说，这一块最关键的就是一个 return，和一个内部的内置函数wrapper()，在被定义的时候呢，它这个被装饰 F 就可以执行它这个里特，并且反将被装饰 F 替换成装饰后的函数。然后以后的话，当我们调用被装饰函数的时候，就是默认被替换成装饰后函数。遵循里面的逻辑，这个装饰后函数我们一般使用就是wrapper

所以在使用可变参数传参的时候，应该遵循这样一个原则：

1. *args (Arguments：位置参数打包器)

作用： 负责把所有按顺序传入的参数，打包成一个元组 (Tuple)。
示例： 如果你调用 func("Alice", 25, "Beijing")，那么在函数内部，args 就会变成 ("Alice", 25, "Beijing")。

2. **kwargs (Keyword Arguments：关键字参数打包器)

作用： 负责把所有带有名字的参数（如 name="Alice"），打包成一个字典 (Dictionary)。
示例： 如果你调用 func(name="Alice", age=25)，那么在函数内部，kwargs 就会变成 {"name": "Alice", "age": 25}。

类的装饰器

概念	核心标志	作用目标	核心优势
类装饰器 (用类写)	实现 `__init__` 和 `__call__`	装饰普通的函数	极其擅长管理复杂的状态（如计数、缓存）。
装饰类的装饰器	接收参数 `cls` 代替 `func`	装饰一个 Class	批量给类动态添加属性或方法，减少重复的模板代码。

__call__ 等于 wrapper

class Retry:
    def __init__(self, max_times=3):
        # 1. 装配阶段的第一步：记录装饰器传进来的参数
        print(f"【初始化】设置最大重试次数为: {max_times}")
        self.max_times = max_times

    def __call__(self, func):
        # 2. 装配阶段的第二步：接收原函数，并制造替身
        print(f"【装配时】正在给函数 {func.__name__} 穿上重试外套...")

        def wrapper(*args, **kwargs):
            # 3. 调用阶段：真正的重试逻辑
            for attempt in range(1, self.max_times + 1):
                try:
                    print(f"  -> 第 {attempt} 次尝试执行...")
                    result = func(*args, **kwargs)
                    print("  -> 执行成功！")
                    return result  # 成功就直接返回结果，结束循环

                except Exception as e:
                    print(f"  -> 失败了，错误原因: {e}")

            print(f"❌ 警告：已达到最大重试次数 {self.max_times}，彻底放弃。")

        return wrapper  # 把替身交出去

# === 使用场景 ===
print("---- 代码开始加载 ----")

@Retry(max_times=3)
def unstable_network_request():
    # 模拟一个不稳定的网络请求，我们让它故意报错
    raise ConnectionError("网络波动，连接超时！")

print("\n---- 准备调用 ----")
unstable_network_request()

注意这里存在的身份信息问题：

def my_decorator(func):
    @wraps(func)  # 用这个让wrap继承身份信息
    def wrapper(*args, **kwargs):
        """我是 wrapper 函数的注释"""
        return func(*args, **kwargs)
    return wrapper

@my_decorator
def calculate_tax(amount):
    """这是一个用来计算税务的复杂核心函数"""
    return amount * 0.2

# 此时我们想打印一下函数的名字和注释文档
print(calculate_tax.__name__)
print(calculate_tax.__doc__)

装饰器	第一个参数	能否访问实例属性 (self.xxx)?	能否访问类属性 (cls.xxx)?	最常见使用场景
(普通方法)	`self` (实例)	✅ 能	✅ 能 (通过 `self.__class__`)	操作或修改单个对象的具体状态。
`@property`	`self` (实例)	✅ 能	✅ 能	把方法伪装成只读属性，动态计算值或保护数据。
`@classmethod`	`cls` (类)	❌ 不能	✅ 能	作为"备用构造函数"，或修改全局类状态。
`@staticmethod`	(无固定参数)	❌ 不能	❌ 不能	编写与类逻辑相关，但纯独立的工具函数。

Python3 核心概念精讲：从基础到面向对象

Wed, 25 Feb 2026 00:00:00 GMT

Python3 核心概念精讲：从基础到面向对象

本文从 Python 的对象模型出发，系统梳理数据结构、函数、装饰器、面向对象、异常处理等核心概念。每个知识点都配有实际开发中的最佳实践，帮助你写出更 Pythonic 的代码。

一、Python 对象模型：一切皆对象

Python 中最重要的认知转变是：变量不是盒子，而是标签。

类型（对象）是内存中真实存在的实体，变量只是贴在对象上的名字。这就是为什么 Python 的变量可以随时指向不同类型的对象——因为变量本身没有类型，对象才有类型。

a = 10       # a 是一个标签，贴在 int 对象 10 上
a = "hello"  # 同一个标签 a，现在贴到了 str 对象上
a = [1, 2]   # 又贴到了 list 对象上

可变与不可变的本质区别

类型	不可变 (Immutable)	可变 (Mutable)
代表	`int`, `str`, `tuple`, `frozenset`	`list`, `dict`, `set`
修改行为	创建新对象，标签重新指向	原地修改同一对象
`id()` 变化	变化（新对象）	不变（同一对象）

# 不可变：重新赋值 = 标签换对象
a = 10
print(id(a))  # 140234866423056
a = 20
print(id(a))  # 140234866423376 ← 不同的对象

# 可变：修改 = 原地改对象
b = [1, 2, 3]
print(id(b))  # 140234851234560
b.append(4)
print(id(b))  # 140234851234560 ← 同一个对象！

最佳实践： 函数参数传递可变对象时，函数内部的修改会影响外部。防御性编程应在函数内部使用 data.copy() 或切片 data[:] 创建副本。

二、数据结构速览

列表 (List)

Python 的列表是动态数组，支持任意类型混合存储。

fruits = ["apple", "banana", "cherry"]

# 常用操作
fruits.append("date")       # 末尾添加
fruits.extend(["fig", "grape"])  # 批量追加（注意和 append 的区别）
fruits.insert(1, "avocado") # 指定位置插入
fruits.pop()                # 弹出末尾元素
fruits.pop(0)               # 弹出指定位置

最佳实践： append 添加单个元素，extend 合并列表。误用 append 传入列表会产生嵌套：[1, [2, 3]] 而非 [1, 2, 3]。

字典 (Dict)

键值对映射，键必须是不可变类型（因为需要哈希）。

user = {"name": "Alice", "age": 25}

# 安全取值
user.get("email", "未设置")  # 不存在时返回默认值，不会抛 KeyError

# Python 3.9+ 合并语法
defaults = {"theme": "dark", "lang": "zh"}
config = defaults | user  # 合并字典，右侧优先

最佳实践： 用 dict.get(key, default) 替代 dict[key]，避免 KeyError。需要带默认值的字典用 collections.defaultdict。

元组 (Tuple)

不可变的序列，常用于函数多返回值和作为字典的键。

# 函数返回多个值本质是返回元组
def get_user():
    return "Alice", 25, "alice@example.com"

name, age, email = get_user()  # 解包

最佳实践： 当数据不应被修改时用元组替代列表，既表达意图又略微提升性能。命名元组 collections.namedtuple 或 typing.NamedTuple 让元组更具可读性。

三、函数进阶

参数类型全解

Python 函数参数有四种传递方式，理解它们的优先级和组合规则至关重要：

def example(
    name,                  # 必备参数（位置参数）
    age=25,                # 默认参数
    *args,                 # 可变位置参数 → 打包为元组
    **kwargs               # 可变关键字参数 → 打包为字典
):
    print(f"{name}, {age}")
    print(f"额外位置参数: {args}")
    print(f"额外关键字参数: {kwargs}")

example("Alice", 30, "extra1", "extra2", city="Beijing")
# Alice, 30
# 额外位置参数: ('extra1', 'extra2')
# 额外关键字参数: {'city': 'Beijing'}

最佳实践： 默认参数不要用可变对象！def f(data=[]) 是经典陷阱——所有调用共享同一个列表。正确写法：def f(data=None): data = data or []。

作用域与 `global` / `nonlocal`

count = 0

def increment():
    global count    # 声明使用全局变量
    count += 1

def outer():
    x = 10
    def inner():
        nonlocal x  # 声明使用外层函数的变量
        x += 1
    inner()
    print(x)  # 11

最佳实践： 尽量避免 global，它会让代码难以追踪和测试。如果需要共享状态，用类封装或者依赖注入。

四、模块与包

`import` 的正确姿势

# ✗ 不推荐：命名空间污染，不知道函数来自哪里
from os import *

# ✓ 推荐：明确来源
import os
os.path.join("/home", "user")

# ✓ 推荐：只导入需要的
from os.path import join, exists

`name` 的作用

每个模块都有 __name__ 属性。直接运行时值为 "__main__"，被导入时值为模块名。

# utils.py
def helper():
    return "I'm a helper"

if __name__ == "__main__":
    # 只在直接运行 utils.py 时执行
    # 被其他模块 import 时不会执行
    print(helper())

最佳实践： 所有脚本都应该有 if __name__ == "__main__" 守卫。这样模块既可以被导入复用，也可以独立运行测试。

五、推导式：Pythonic 的数据变换

推导式是 Python 最优雅的特性之一，用一行代码完成数据的过滤和变换：

# 列表推导式
squares = [x**2 for x in range(10) if x % 2 == 0]
# [0, 4, 16, 36, 64]

# 字典推导式
word_lengths = {word: len(word) for word in ["hello", "world", "python"]}
# {'hello': 5, 'world': 5, 'python': 6}

# 集合推导式（自动去重）
unique_lengths = {len(word) for word in ["hi", "hello", "hey"]}
# {2, 5, 3}

# 生成器表达式（惰性求值，不占内存）
total = sum(x**2 for x in range(1000000))

最佳实践： 推导式应保持简洁。如果逻辑超过一行或需要多层嵌套，改用普通 for 循环更易读。嵌套推导式超过两层就是代码异味。

六、迭代器与生成器

迭代器协议

任何实现了 __iter__() 和 __next__() 方法的对象都是迭代器。for 循环的本质就是不断调用 next() 直到 StopIteration。

nums = [1, 2, 3]
it = iter(nums)       # 获取迭代器
print(next(it))       # 1
print(next(it))       # 2
print(next(it))       # 3
# next(it)            # StopIteration!

生成器：优雅的迭代器

生成器是创建迭代器的简洁方式。函数中包含 yield 关键字就自动变成生成器函数。

yield 的三个关键行为：

产出值并暂停 — 返回值给调用者，然后冻结在当前位置
保留运行状态 — 所有局部变量、执行位置都被保存
恢复执行 — 下次 next() 从暂停处继续

def countdown(n):
    while n > 0:
        yield n    # 产出 n，暂停
        n -= 1     # 下次 next() 从这里继续

gen = countdown(5)
print(next(gen))  # 5
print(next(gen))  # 4

for val in gen:   # 继续迭代剩余的
    print(val)    # 3, 2, 1

最佳实践： 处理大数据集时，生成器是救星。读取 10GB 日志文件：用 for line in open("huge.log") 而非 open("huge.log").readlines()，前者逐行生成，后者一次性加载到内存。

七、with 语句与上下文管理器

with 语句确保资源（文件、锁、连接）在使用后被正确释放，即使发生异常。

# 文件操作：with 自动关闭文件
with open("data.txt", "r") as f:
    content = f.read()
# 离开 with 块后，f 自动关闭，即使中间抛了异常

# 同时管理多个资源
with open("input.txt") as infile, open("output.txt", "w") as outfile:
    outfile.write(infile.read().upper())

自定义上下文管理器

实现 __enter__ 和 __exit__ 方法，或使用 contextlib.contextmanager 装饰器：

from contextlib import contextmanager
import time

@contextmanager
def timer(label):
    start = time.perf_counter()
    yield  # 这里是 with 块内的代码执行点
    elapsed = time.perf_counter() - start
    print(f"{label}: {elapsed:.4f}s")

with timer("数据处理"):
    data = [x**2 for x in range(1000000)]
# 输出: 数据处理: 0.0823s

最佳实践： 任何需要"获取-使用-释放"模式的场景都应该用 with：文件、数据库连接、线程锁、临时目录。contextlib 模块提供了 suppress、redirect_stdout 等实用工具。

八、Lambda 表达式

Lambda 是匿名的单行函数，适合作为高阶函数的参数：

# 排序：按字典的 age 字段
users = [{"name": "Bob", "age": 30}, {"name": "Alice", "age": 25}]
sorted_users = sorted(users, key=lambda u: u["age"])

# 配合 map/filter
numbers = [1, 2, 3, 4, 5]
squared = list(map(lambda x: x**2, numbers))      # [1, 4, 9, 16, 25]
evens = list(filter(lambda x: x % 2 == 0, numbers))  # [2, 4]

最佳实践： Lambda 只用于简单的单行逻辑。如果需要多行或复杂逻辑，定义具名函数更清晰。PEP 8 明确建议不要把 lambda 赋值给变量（f = lambda x: x+1），直接用 def 。

九、装饰器深入

装饰器是 Python 最强大的元编程工具之一。它允许在不修改原函数代码的前提下，动态增强函数的功能。

函数装饰器的本质

@decorator 是语法糖，等价于 func = decorator(func)。装饰器接收一个函数，返回一个新函数（通常是 wrapper）。

import functools

def log_calls(func):
    @functools.wraps(func)  # 保留原函数的元信息
    def wrapper(*args, **kwargs):
        print(f"→ 调用 {func.__name__}({args}, {kwargs})")
        result = func(*args, **kwargs)
        print(f"← {func.__name__} 返回 {result}")
        return result
    return wrapper

@log_calls
def add(a, b):
    """两数相加"""
    return a + b

add(3, 5)
# → 调用 add((3, 5), {})
# ← add 返回 8

理解 `return wrapper` vs `return wrapper()`

这是初学者最容易混淆的点：

return wrapper — 返回函数本体（遥控器），以后调用时才执行
return wrapper() — 立即执行函数，返回执行结果

装饰器必须返回函数本体，否则装饰后的函数就不是函数了。

带参数的装饰器（三层嵌套）

当装饰器本身需要接收参数时，需要多包一层：

import functools

def retry(max_times=3, delay=1):
    """带参数的重试装饰器"""
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(1, max_times + 1):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    print(f"第 {attempt} 次失败: {e}")
                    if attempt == max_times:
                        raise
                    time.sleep(delay)
        return wrapper
    return decorator

@retry(max_times=3, delay=2)
def fetch_data(url):
    # 网络请求逻辑...
    pass

用类实现装饰器

当装饰器需要管理复杂状态（如计数、缓存）时，用类实现更清晰：

class CallCounter:
    def __init__(self, func):
        functools.update_wrapper(self, func)
        self.func = func
        self.count = 0

    def __call__(self, *args, **kwargs):
        self.count += 1
        print(f"{self.func.__name__} 已被调用 {self.count} 次")
        return self.func(*args, **kwargs)

@CallCounter
def process():
    pass

process()  # process 已被调用 1 次
process()  # process 已被调用 2 次

__call__ 方法让类的实例可以像函数一样被调用，它就是类装饰器中的 wrapper。

最佳实践：

始终使用 @functools.wraps(func) — 保留原函数的 __name__、__doc__ 等元信息

wrapper 必须接受 *args, **kwargs — 确保兼容任意函数签名

常用内置装饰器： @property、@classmethod、@staticmethod、@functools.lru_cache

十、面向对象编程

面向对象是 Python 的核心编程范式。Python 的 OOP 哲学可以用一句话概括：一切皆对象，鸭子类型优先。

类的基本结构

class User:
    """用户类"""
    # 类属性：所有实例共享
    platform = "MyApp"

    def __init__(self, name: str, email: str):
        # 实例属性：每个实例独立
        self.name = name
        self.email = email
        self._login_count = 0       # 约定私有（单下划线）
        self.__password_hash = ""   # 名称改写（双下划线）

    def login(self):
        """普通方法：操作实例状态"""
        self._login_count += 1
        return f"{self.name} 登录成功（第 {self._login_count} 次）"

    @property
    def login_count(self):
        """属性装饰器：像属性一样访问，但有控制逻辑"""
        return self._login_count

    @classmethod
    def from_dict(cls, data: dict):
        """类方法：备用构造函数"""
        return cls(data["name"], data["email"])

    @staticmethod
    def validate_email(email: str) -> bool:
        """静态方法：纯工具函数"""
        return "@" in email and "." in email

封装：保护数据完整性

Python 没有真正的 private 关键字，而是通过命名约定实现封装：

_name — 约定私有，外部不应直接访问（但技术上可以）
__name — 名称改写（Name Mangling），变成 _ClassName__name，更强的保护
name_ — 避免与关键字冲突，如 class_、type_

class BankAccount:
    def __init__(self, balance: float):
        self.__balance = balance  # 双下划线保护

    @property
    def balance(self) -> float:
        """只读属性"""
        return self.__balance

    def deposit(self, amount: float):
        if amount <= 0:
            raise ValueError("存款金额必须为正数")
        self.__balance += amount

    def withdraw(self, amount: float):
        if amount > self.__balance:
            raise ValueError("余额不足")
        self.__balance -= amount

继承与方法重写

class Animal:
    def __init__(self, name: str):
        self.name = name

    def speak(self) -> str:
        raise NotImplementedError("子类必须实现 speak 方法")

class Dog(Animal):
    def speak(self) -> str:
        return f"{self.name}: 汪汪！"

class Cat(Animal):
    def speak(self) -> str:
        return f"{self.name}: 喵~"

# 多态：同一接口，不同行为
animals = [Dog("旺财"), Cat("咪咪")]
for animal in animals:
    print(animal.speak())

多继承与 MRO

Python 支持多继承，方法解析顺序（MRO）遵循 C3 线性化算法：

class A:
    def greet(self):
        return "A"

class B(A):
    def greet(self):
        return "B"

class C(A):
    def greet(self):
        return "C"

class D(B, C):
    pass

d = D()
print(d.greet())       # "B" — 按 MRO 顺序
print(D.__mro__)       # (D, B, C, A, object)

`super()` 的正确用法

class Student(User):
    def __init__(self, name: str, email: str, grade: int):
        super().__init__(name, email)  # 调用父类构造
        self.grade = grade

    def login(self):
        result = super().login()  # 调用父类方法
        return f"{result}（学生用户）"

鸭子类型：Python 的多态哲学

Python 不需要显式的接口声明。只要对象有正确的方法，就可以使用：

class FileLogger:
    def write(self, msg):
        with open("app.log", "a") as f:
            f.write(msg + "\n")

class ConsoleLogger:
    def write(self, msg):
        print(f"[LOG] {msg}")

def log_message(logger, msg):
    """不关心 logger 的类型，只要有 write 方法就行"""
    logger.write(msg)

# 两种 logger 都能用，这就是鸭子类型
log_message(FileLogger(), "保存到文件")
log_message(ConsoleLogger(), "打印到控制台")

最佳实践：

优先组合而非继承 — 继承层级不超过 3 层，复杂关系用 "has-a" 替代 "is-a"

使用 ABC 定义接口 — from abc import ABC, abstractmethod 强制子类实现特定方法

单一职责 — 每个类只做一件事，如果类名里有 "And"，说明该拆分了

用 dataclass 简化数据类 — Python 3.7+ 的 @dataclass 自动生成 __init__、__repr__ 等

十一、异常处理

在 AI 辅助编程时代，Debug 能力是重中之重。异常处理不仅是捕获错误，更是一种防御性编程策略。

完整的异常处理结构

try:
    result = 10 / int(input("输入除数: "))
except ValueError:
    print("请输入有效的数字")
except ZeroDivisionError:
    print("除数不能为零")
except Exception as e:
    print(f"未预期的错误: {e}")
else:
    # 只在 try 块没有异常时执行
    print(f"结果: {result}")
finally:
    # 无论如何都会执行（资源清理）
    print("计算结束")

异常的传播规则

如果异常在 try（或 except、else）中被抛出，且没有被任何 except 捕获，它会在 finally 执行完毕后继续向上传播。

自定义异常

class AppError(Exception):
    """应用基础异常"""
    pass

class ValidationError(AppError):
    """数据验证异常"""
    def __init__(self, field: str, message: str):
        self.field = field
        self.message = message
        super().__init__(f"{field}: {message}")

class NotFoundError(AppError):
    """资源未找到"""
    pass

# 使用
def create_user(name: str, age: int):
    if not name:
        raise ValidationError("name", "用户名不能为空")
    if age < 0 or age > 150:
        raise ValidationError("age", "年龄必须在 0-150 之间")

`raise` 的三种用法

# 1. 抛出新异常
raise ValueError("无效的输入")

# 2. 重新抛出当前异常（保留原始堆栈）
try:
    risky_operation()
except Exception:
    logging.error("操作失败")
    raise  # 不带参数，原样抛出

# 3. 异常链（Python 3）
try:
    data = json.loads(raw)
except json.JSONDecodeError as e:
    raise ValidationError("data", "JSON 格式错误") from e

最佳实践：

永远不要裸 except: — 至少用 except Exception，否则会吞掉 KeyboardInterrupt 和 SystemExit

精确捕获 — except ValueError 优于 except Exception，只处理你知道如何处理的异常

自定义异常继承 Exception — 不要继承 BaseException

用 raise ... from e 保留异常链 — 方便调试时追溯根因

日志记录用 logging.exception() — 自动包含堆栈信息

十二、类型注解

Python 3.5+ 引入的类型注解不影响运行时行为，但能极大提升代码可读性和 IDE 支持：

from typing import Optional, Union

def find_user(user_id: int) -> Optional[dict]:
    """查找用户，不存在返回 None"""
    ...

def process(data: list[dict[str, Union[str, int]]]) -> float:
    """处理数据列表"""
    ...

# Python 3.10+ 更简洁的语法
def greet(name: str | None = None) -> str:
    return f"Hello, {name or 'World'}"

最佳实践：

渐进式采用 — 从公共接口和复杂函数开始，不需要一次性全部注解

配合 mypy 使用 — pip install mypy && mypy your_project/ 静态类型检查

避免过度注解 — x: int = 5 是多余的，类型显而易见时可以省略

总结

Python 的核心哲学是 "简洁优于复杂，可读性至上"。掌握这些核心概念后，关键是在实际项目中不断实践：

对象模型 让你理解 Python 的运行机制
装饰器 让你写出优雅的横切关注点代码
面向对象 让你构建可维护的大型系统
异常处理 让你的代码在生产环境中稳健运行

记住：Pythonic 的代码不是炫技，而是让下一个读代码的人（包括未来的你）能快速理解意图。

Git 实战指南：从分支管理到远程协作

Tue, 24 Feb 2026 00:00:00 GMT

Git 实战指南：从分支管理到远程协作

本文从实际开发场景出发，梳理 Git 在日常工作中最常遇到的操作与决策。不讲花哨技巧，只聚焦「遇到这种情况该怎么办」。

一、分支：Git 的核心工作单元

在团队开发中，分支是隔离工作的基本手段。你不会直接在 main 上写代码——你会创建一个分支，在上面开发，完成后再合并回去。

创建与切换

# 创建并切换到新分支（推荐写法）
git checkout -b feature

# 等价于两步操作
git branch feature
git checkout feature

HEAD 是什么？

HEAD 是一个指针，指向你当前所在的分支（或提交）。你做的每一次 checkout 都在移动它。

HEAD^ — 当前提交的父节点
HEAD~3 — 往前数 3 个提交
git branch -f main HEAD~2 — 强制把 main 指针移到前 2 个提交

下面这张图展示了一个典型的分支工作流——从 main 创建 feature 和 bugfix 分支，独立开发后合并回主干：

二、merge vs rebase：最常见的选择困难

这是 Git 使用中最核心的决策之一。两者都能把代码合到一起，但适用场景完全不同。

merge：保留历史轨迹

# 在 main 上执行，合并 feature 分支
git checkout main
git merge --no-ff feature

--no-ff 强制生成一个合并提交，即使可以快进。这样在历史中能清楚看到「这个功能是从哪里合进来的」。

rebase：保持线性历史

# 在 feature 上执行，把自己的改动「垫」到 main 最新提交之上
git checkout feature
git rebase main

rebase 的本质是：暂存你的提交 → 应用目标分支的更新 → 重新应用你的提交。注意，它修改的是当前分支，目标分支只是参照物。

黄金法则

个人分支用 rebase：保持干净的线性历史
公共分支用 merge：保留合并记录，不改写已推送的历史
已推送的分支禁止 rebase：会导致其他人的历史混乱

三、撤销操作：出了问题怎么办？

开发中难免会提交错误的代码。关键问题是：这个提交已经推送到远程了吗？

仅本地：git reset

# 撤销最近一次提交，保留改动在暂存区
git reset --soft HEAD^

# 撤销最近一次提交，保留改动在工作区（默认行为）
git reset HEAD^

# 彻底丢弃改动（不可恢复！）
git reset --hard HEAD^

已推送：git revert

# 生成一个新的「反向提交」来撤销指定提交
git revert <commit-hash>

revert 不会改写历史，而是创建一个新提交来抵消之前的改动。这在协作中是安全的。

cherry-pick：精确挑选

# 只把 C2 和 C4 这两个提交挪到当前分支
git cherry-pick C2 C4

区别于 rebase 拿整个分支，cherry-pick 让你精确选择需要的提交。

交互式 rebase：整理本地提交

git rebase -i HEAD~4

可以重排、合并、删除、编辑最近 4 个提交。在推送前整理提交历史非常有用。

四、远程协作：本地与远程的同步

核心概念

origin/main（简写 o/main）是本地存储的远程仓库快照
它不会自动更新，需要手动 fetch

fetch、pull、push 的关系

# 只更新远程跟踪分支，不动本地分支（安全）
git fetch origin

# 拉取并合并（= fetch + merge）
git pull origin main

# 拉取并变基（= fetch + rebase，推荐）
git pull --rebase

# 推送本地提交到远程
git push origin main

Remote Tracking：分支跟踪

# 创建本地分支并跟踪远程分支
git checkout -b feature o/main

# 为已有分支设置跟踪
git branch -u o/main feature

设置跟踪后，git push 和 git pull 就知道该推到哪里、从哪里拉了。

五、push / fetch / pull 参数详解

这三个命令都支持 origin <source>:<destination> 的参数格式，但方向相反：

push：本地 → 远程（推送空 source = 删除远程分支）
fetch：远程 → 本地（拉取空 source = 创建本地分支）

# push 的 source:destination
git push origin main           # 本地 main → 远程 main
git push origin local:remote   # 本地 local → 远程 remote
git push origin :remote        # 删除远程 remote 分支

# fetch 的 source:destination（方向相反）
git fetch origin main           # 远程 main → 本地 o/main
git fetch origin remote:local   # 远程 remote → 本地 local
git fetch origin :local         # 创建本地 local 分支

# pull 是 fetch + merge 的组合
git pull origin foo             # = fetch origin foo + merge o/foo
git pull origin bar:bugFix      # = fetch origin bar:bugFix + merge bugFix

六、现代 Git 协作利器：worktree

为什么需要 worktree？

在实际开发中，你经常会遇到这样的场景：正在 feature 分支上写代码写到一半，突然线上出了 bug 需要紧急修复。传统做法是 git stash → 切分支 → 修 bug → 切回来 → git stash pop。这个流程有几个痛点：

stash 恢复时可能产生冲突
IDE 的构建缓存、运行状态全部丢失
频繁切换分支的心智负担很重

git worktree 从根本上解决了这个问题：它允许你从同一个仓库创建多个工作目录，每个目录检出不同的分支，彼此完全独立。

核心设计理念

worktree 的设计哲学是共享存储，隔离工作区：

所有工作树共享同一个 .git 对象库（commits、blobs、trees）
每个工作树有独立的 HEAD、index（暂存区）和工作目录
磁盘开销极小——只多了一份工作区文件，不会复制整个仓库

这意味着你在任何一个工作树中做的提交，其他工作树都能立即看到（通过 git log），因为底层数据是共享的。

实战场景对比

下面这张图对比了传统方式和 worktree 方式处理「开发中途需要修 bug」的流程差异：

常用命令速查

# 创建一个新的工作树，检出 hotfix 分支
git worktree add ../project-hotfix hotfix

# 创建工作树的同时创建新分支
git worktree add -b emergency-fix ../project-fix main

# 查看所有工作树
git worktree list

# 完成后移除工作树（先删目录再清理引用）
git worktree remove ../project-hotfix

# 清理已失效的工作树引用
git worktree prune

使用注意事项

同一分支不能同时被两个工作树检出——这是 Git 的硬性限制，防止两个工作区同时修改同一分支导致混乱
不要直接 rm -rf 删除工作树目录——应该用 git worktree remove，否则 .git/worktrees 中会残留失效引用
子模块在链接工作树中的支持有限，复杂项目需要测试验证
worktree 非常适合 CI/CD 场景——可以同时构建多个分支而不互相干扰

什么时候该用 worktree？

场景	是否推荐
开发中途需要紧急修 bug	✅ 最佳场景
需要同时对比两个分支的运行效果	✅ 非常适合
长期维护多个版本（v1、v2）	✅ 比多个 clone 更轻量
CI 并行构建多个分支	✅ 共享对象库，节省空间
只是简单切个分支看一眼	❌ 直接 checkout 更快

七、实战工作流总结

日常开发流程

git fetch origin — 先看看远程有什么变化
git rebase o/main — 在个人分支上变基到最新
解决可能的冲突
git push — 推送到远程
在 main 上 merge --no-ff — 合并功能分支

版本标记

# 给特定提交打标签
git tag v1.0.0 <commit-hash>

# 查看离当前位置最近的标签
git describe main

常见陷阱

陷阱	后果	正确做法
在公共分支上 rebase	其他人的历史被打乱	只在个人分支 rebase
rebase 时搞反目标和参考分支	提交顺序错乱	仔细确认当前分支和目标分支
reset --hard 后想恢复	改动永久丢失	先确认不需要，或用 reflog 抢救
push 空 source 到远程	远程分支被删除	检查命令参数再执行

记住两条核心原则：个人分支随便折腾，公共分支只做加法。掌握了 merge/rebase 的选择和 reset/revert 的区分，日常 Git 操作就不会出大问题。

shaoyou

Agent 的交互就是流式事件处理——用数据库的思想重新设计 Agent 技术栈

Agent 的交互就是流式事件处理——用数据库的思想重新设计 Agent 技术栈

引子：Agent 需要 ChatGPT 做不到的三件事

一、最表层：Agent 为什么每次都从零开始？

二、往下一层：事实记忆该怎么存？

三、再深一层：记忆注入为什么这么贵？

3.1 关键发现：Transformer 在 prefill 时就写好了"结论备忘录"

3.2 那怎么改？——追加一条更正便签

3.3 那怎么复用？——预编译 + RoPE 重定位

四、再深一层：能把记忆写进模型参数吗？

4.1 DeepSeek Engram：模型内的哈希表

4.2 User as Engram：把用户事实存进哈希槽位

五、回到起点：主线是什么？

附录 A：RoPE 重定位的形式化推导

A.0 RoPE 的数学定义

A.1 核心性质：注意力只依赖相对位置

A.2 预编译：技能被"冷冻"时存了什么

A.3 重定位：对 key 施加 $\Delta$ 旋转

A.4 三种 Attention 关系的验证

A.5 Seam-Repair 与复杂度

A.6 Append-Only Erratum 的复杂度

附录 B：Erratum 可编辑性的形式化推导

B.1 直接改字段 KV 为何无效

B.2 Erratum 工作原理

B.3 Changelog + Checkpoint 形式化

附录 C：Engram 哈希表寻址的形式化推导

C.1 N-gram 提取与哈希

C.2 门控融合

C.3 多租户叠加

C.4 与 LoRA 的隔离性对比

相关论文

相关领域其他工作（简表）

GPT-2 架构拆解与理解

GPT-2 架构拆解与理解

0. 一句话总结 Transformer 在做什么

1. 核心超参数（GPT-2 Small）

2. 输入层：两块地基

Token Embedding（W_E）

Position Embedding（W_P）

嵌入求和

3. LayerNorm：数据标准化车间

4. 多头自注意力（MHSA）：让 token 互相看

为什么需要注意力？

Q、K、V 三个投影

拆分成多头

Scaled Dot-Product Attention（核心公式）

W_O：融合 12 个专家的意见

W_O 和 V 的关系

残差连接 1

5. Feed-Forward Network（FFN）：每个 token 单独消化

三拍子：展开 → 筛选 → 回收

残差连接 2

6. 形式化推导：一个 token 向量的一生

6.1 符号约定

6.2 诞生：嵌入

6.3 成长：穿越 L 层 Transformer Block

2.1 第一子层：多头因果自注意力

2.1.1 Pre-LayerNorm

2.1.2 Q / K / V 投影

2.1.3 多头拆分

2.1.4 因果掩码注意力（主人公 t 的视角）

2.1.5 合并多头与输出投影

2.1.6 残差连接

2.2 第二子层：前馈网络

2.2.1 Pre-LayerNorm

2.2.2 升维 → GELU 筛选 → 降维

2.2.3 残差连接

6.4 使命：最终输出与预测

6.5 学习：损失函数

6.6 应用：自回归生成

6.7 可训练参数全家福

7. 为什么需要 12 层？

8. 输出层

9. FFN 的可解释性（为什么 FFN 占 70% 参数但少有人提？）

核心发现：FFN 是一个键值记忆网络

实验证据

为什么 FFN 少被提及？

10. GPT-2 → 现代大模型架构演进

FFN：GELU → SwiGLU

Token Embedding（`W_E`）

Position Embedding（`W_P`）

`W_O`：融合 12 个专家的意见

`W_O` 和 `V` 的关系

2.1.4 因果掩码注意力（主人公 `t` 的视角）

作用域与 `global` / `nonlocal`

`import` 的正确姿势