多 Agent LLM 系统现在很常见：一个负责规划，一个负责写代码，一个负责审查，一个负责总结。听起来像一个高效团队，但现实里经常出现一个问题：多个 LLM 被 prompt 临时组织起来，并不等于它们真的学会了协作。

Bohrium 这篇文章解读的 MAGRPO，全称是 Multi-Agent Group Relative Policy Optimization，它试图把“LLM 如何协作”从 prompt 工程问题，重新建模为一个多智能体强化学习问题。核心思想是：不要只靠提示词让多个模型“看起来像在配合”，而是在训练阶段用共享奖励让它们学会共同优化一个团队目标。(Bohrium)

1. 为什么普通多 Agent Prompt 容易失败？

很多多 Agent 系统本质上还是测试时编排：模型不变，只是在推理时通过 debate、discussion、review、sequential pipeline 等方式让它们交换输出。问题是，这些 Agent 并没有被训练成一个团队，它们只是被 prompt 临时要求“合作”。原论文指出，这类方法容易出现沟通低效、角色遵循不稳定、错误信息互相传播，以及 prompt/角色设计不清晰等问题。(ar5iv)

另一类方法是独立微调每个 Agent，比如给“规划者”“执行者”“审查者”分别设计奖励。但这又带来两个难点：

第一，奖励设计很复杂。你需要手动判断每个角色应该拿什么奖励，但协作任务的成功往往来自整体效果，很难拆成每个 Agent 的独立贡献。

第二，多智能体环境是非平稳的。当一个 Agent 的策略更新后，另一个 Agent 面对的“环境”也变了。这会让每个模型都在一个不断变化的环境里学习，收敛会更困难。原论文也明确批评了这类独立学习方法在非平稳环境下缺少可靠保证。(ar5iv)

所以，MAGRPO 要解决的不是“怎么写更好的多 Agent Prompt”，而是：

能不能让多个 LLM 在训练时就围绕同一个团队目标学习，并在推理时仍然保持并行、高效、去中心化执行？

2. MAGRPO 的基本思路：训练时集中，执行时分散

MAGRPO 把 LLM 协作建模为 Dec-POMDP，也就是 Decentralized Partially Observable Markov Decision Process，去中心化部分可观测马尔可夫决策过程。

这个名字很长，但直观理解并不复杂：

多个 Agent 共享一个最终目标，但每个 Agent 只能看到自己的局部输入。比如在协作写作中，一个 Agent 负责写摘要，另一个负责补充细节；在协作编程中，一个 Agent 写辅助函数，另一个 Agent 写主函数。它们不能直接读取彼此的内部状态，只能通过任务输入、历史输出或环境反馈间接协作。原论文把状态、局部观察、自然语言响应、共享奖励和回合限制都放进 Dec-POMDP 框架里，用它来描述 LLM 协作任务。(ar5iv)

MAGRPO 采用的是一种 Centralized Training, Decentralized Execution 的思路：

训练时，系统可以从整体结果计算一个共享奖励，判断多个 Agent 的联合输出好不好。

执行时，每个 Agent 不需要中心控制器逐步指挥，而是根据自己的局部上下文独立生成，多个 Agent 可以并行工作。

这点很关键。很多多 Agent 系统慢，是因为它们需要一轮轮对话、互相等待、反复汇总。MAGRPO 想要的是：协作能力在训练中学进去，推理时少沟通甚至不沟通，也能自然配合。

3. MAGRPO 和 GRPO 的关系

MAGRPO 是对 GRPO，也就是 Group Relative Policy Optimization 的多智能体扩展。

普通 GRPO 的一个重要思想是：不一定要训练一个额外的 value model，而是可以生成一组候选输出，然后用组内相对表现估计 advantage。MAGRPO 把这个思想扩展到多个 Agent 的联合输出上。

训练流程可以粗略理解为：

1. 从数据集中采样一个任务；
2. 多个 Agent 根据自己的局部 prompt 分别生成多组响应；
3. 把多个 Agent 的输出组合成联合动作；
4. 环境或奖励模型给这些联合输出打一个共享奖励；
5. 用组内平均表现作为基准，计算每组联合输出的相对优势；
6. 用这个优势去更新每个 Agent 的策略。

原论文特别强调，MAGRPO 不使用显式 value model，而是通过一组 Monte Carlo 样本估计当前状态的期望回报，从而获得一种集中式的 advantage 估计，再分别更新每个 Agent 的策略。(ar5iv)

这带来的好处是：它既不像传统 CTDE 方法那样依赖巨大的 centralized critic，也不像完全独立训练那样丢掉团队层面的反馈。它用“共享奖励 + 组内相对优势”在两者之间做了一个折中。

4. 实验结果：协作不是多聊几轮，而是训练出来的

原文和论文主要展示了两个方向的实验：协作写作和协作编程。

4.1 协作写作

写作实验包括 TLDR 摘要和 arXiv 摘要扩写。系统使用两个 Qwen3-1.7B Agent：一个负责更短的核心摘要，另一个负责更详细的总结或扩写。奖励由结构、风格一致性、逻辑连贯性等指标组合而成。(ar5iv)

结果很有意思：在 TLDR 任务上，MAGRPO 的速度是 202.3 tokens/s，响应时间约 2.1 秒；单个 Qwen3-4B 模型是 64.1 tokens/s，响应时间约 6.6 秒。也就是说，两个小模型并行协作，速度接近单个较大模型的 3 倍。更重要的是，MAGRPO 在 TLDR 上的 normalized return 达到 94.5%，明显高于 one-round discussion 的 22.3% 和 sequential generation 的 21.7%。(ar5iv)

这说明一个问题：多 Agent 的关键不是让模型“多讨论”，而是让它们在训练中学会稳定分工。

4.2 协作编程

编程实验里，论文让两个 Qwen2.5-Coder-3B Agent 协作生成 Python 函数：一个生成辅助函数，另一个生成主函数。它们的输出会被拼接成完整代码，并通过结构完整性、语法正确性、单元测试通过率和协作质量来评估。(ar5iv)

在 HumanEval 和 CoopHumanEval 上，MAGRPO 的结果整体优于 naive concatenation、sequential pipeline 和 one-round discussion 等 prompt-based baseline。尤其在 CoopHumanEval 这种更适合协作拆解的数据集上，multi-turn MAGRPO 的总回报达到 88.1%，明显高于其他 baseline。(ar5iv)

这里还有一个细节很重要：普通 HumanEval 中很多题本身并不适合拆成两个 Agent 协作，比如一个很短的原子函数。论文因此构造了 CoopHumanEval，让任务更具备协作结构。结果显示，当数据本身更适合分工，MAGRPO 的训练效果更稳定，回报也更高。(ar5iv)

这对工程落地很有启发：多 Agent 不应该强行套在所有任务上，它更适合那些天然可以模块化、并且有清晰反馈信号的任务。

5. MAGRPO 学到的不是固定流程，而是协作模式

在协作编程中，论文观察到 MAGRPO 会自然形成几类合作模式：

一种是 fallback。辅助函数尝试完成核心逻辑，主函数保留一套兜底逻辑，避免辅助函数出错导致整体失败。

一种是 decorator。辅助函数完成主要逻辑，主函数负责边界处理、格式整理或额外健壮性增强。

还有一些更主动的模式，比如主函数像 coordinator 一样拆解问题，或者辅助函数像 strategy filter 一样引导主函数处理特定情况。论文认为，这些合作模式是在简单共享奖励下自然涌现出来的。(ar5iv)

这也是 MAGRPO 最值得关注的地方：它不是写死一个 workflow，而是让多个 Agent 在奖励驱动下学出适合任务的协作策略。

6. 它适合什么场景？

MAGRPO 最适合下面这类任务：

任务可以拆成多个相对稳定的角色，比如摘要/扩写、主函数/辅助函数、前端/后端、规划/执行。

任务有可自动验证或半自动验证的奖励信号，比如单元测试、格式检查、结构约束、风格一致性、集成测试结果。

推理速度很重要，希望多个小模型并行执行，而不是一个大模型串行完成所有工作。

任务会反复出现，值得通过训练把协作模式沉淀进模型权重，而不是每次都靠 prompt 临时协调。

原文也提到，MAGRPO 可以启发软件开发、创意写作、隐私保护型诊断、多角色金融分析等应用。但其中很多属于长期设想，真正落地仍然依赖可验证奖励、数据质量和安全控制。(Bohrium)

7. 局限性：这还不是“通用 Agent 团队训练法”

MAGRPO 的局限也很明显。

首先，目前实验主要集中在短 horizon 任务，比如摘要、扩写、函数级代码生成。长周期任务，例如完整软件项目、长篇小说、多日研究流程，可能仍然需要显式通信、共享记忆和阶段性规划。Bohrium 原文也指出，当前结果还不能证明这种隐式协调能稳定扩展到极长上下文场景。(Bohrium)

其次，奖励设计并没有消失，只是从“给每个 Agent 手工设计奖励”变成了“给联合输出设计共享奖励”。在代码任务里，单元测试是天然反馈；但在开放式产品设计、复杂研究、商业决策中，什么是好结果并不总是容易量化。

第三，MAGRPO 的优势和数据结构强相关。论文中 CoopHumanEval 比原始 HumanEval 更适合协作，因此效果更好。这说明训练多 Agent 时，数据集本身是否具备可分工结构非常关键。(ar5iv)

最后，论文中的 baseline 多数仍是 prompt-based 方法，而不是其他强力 fine-tuned 多 Agent 方法。因此，MAGRPO 证明了“训练协作优于临时 prompt 协作”，但还需要和更多多智能体训练算法进一步比较。

8. 对 Agent 工程的启发

MAGRPO 给 Agent 系统设计带来的最大启发是：协作不应该只停留在 prompt 编排层，而应该进入训练目标层。

今天很多 Agent 框架的核心是“搭流程”：谁先说，谁后说，谁 review，谁总结。这个方向当然有用，但它更像是在组织一群没有磨合过的人开会。MAGRPO 的思路更像是训练一支长期配合的团队：每个成员不需要每一步都开会，但知道自己在什么位置、该如何输出、如何和别人的结果形成整体最优。

对工程实践来说，可以总结成三句话：

第一，不要迷信“多 Agent = 更强”。如果没有共享目标和反馈信号，多 Agent 可能只是更贵、更慢、更难 debug。

第二，优先选择有明确验证信号的任务做多 Agent 训练，比如代码生成、数据处理、报告生成、结构化写作。

第三，小模型并行协作可能比单个大模型串行执行更高效，但前提是这些小模型经过面向协作的训练，而不是只靠 prompt 分工。

结语

MAGRPO 的价值不只是提出了一个新算法，而是把多 Agent LLM 的问题重新摆正了：

多 Agent 系统真正难的不是让模型互相说话，而是让它们围绕同一个目标形成稳定、可泛化、可并行执行的协作策略。

如果未来 Agent 系统要从 demo 走向真实生产环境，光靠 prompt orchestration 可能不够。像 MAGRPO 这样的多智能体强化学习方法，可能会成为训练“专业 AI 团队”的关键路径之一。

参考：Bohrium 原文解读、arXiv 论文《LLM Collaboration With Multi-Agent Reinforcement Learning》，以及作者开源的 CoMLRL 框架。CoMLRL 提供了用于训练多个 LLM 协作的 MARL 算法实现，并包含 writing、coding、Minecraft 等环境和 benchmark。(Bohrium)

Finished reading? Leave a comment

在强化学习和多智能体系统中，经常会遇到几个层层递进的概念：MDP、POMDP、Dec-POMDP。

它们都在描述“智能体如何在环境中连续做决策”，但它们对智能体数量、状态可见性、信息共享方式的假设并不相同。

本文主要对比 MDP 和 Dec-POMDP，并顺带引入 POMDP 作为中间桥梁，帮助理解它们之间的演进关系。

1. MDP：完整可观测下的单智能体决策

MDP 全称是 Markov Decision Process，中文叫 马尔可夫决策过程。

它描述的是：

一个智能体在能够观察完整环境状态的情况下，如何选择动作来最大化长期累计收益。

一个 MDP 通常可以表示为：

$ \mathcal{M} = (S, A, P, R, \gamma) $

其中：

• S：状态集合，表示环境可能处于哪些状态；
• A：动作集合，表示智能体可以执行哪些动作；
• P(s' \mid s, a)：状态转移概率，表示在状态 s 下执行动作 a 后进入状态 s' 的概率；
• R(s, a)：奖励函数，表示在状态 s 下执行动作 a 可以获得的即时奖励；
• \gamma：折扣因子，用来衡量未来奖励的重要性。

MDP 的核心假设是 马尔可夫性：

$$ P(s_{t+1} \mid s_t, a_t, s_{t-1}, a_{t-1}, \dots)

P(s_{t+1} \mid s_t, a_t) $$

它的意思是：

下一步会发生什么，只取决于当前状态和当前动作，而不取决于更早的历史。

也就是说，只要当前状态 s_t 已经包含了足够的信息，智能体就不需要再关心过去发生了什么。

2. Bellman 方程：MDP 的核心思想

在 MDP 中，一个非常重要的公式是 Bellman 最优方程：

$ V(s) = \max_a \left[ R(s, a) + \gamma \sum_{s'} P(s' \mid s, a) V(s') \right] $

这个公式表达的是：

当前状态的最优价值，等于在所有可选动作中，选择那个“当前奖励 + 折扣后的未来期望价值”最大的动作。

拆开来看，V(s) 表示状态 s 的价值，也就是从状态 s 出发，之后都采取最优策略时，能够获得的长期期望收益。

R(s, a) 表示当前这一步马上获得的奖励。

而这一项：

$ \sum_{s'} P(s' \mid s, a) V(s') $

表示执行动作 a 后，未来可能进入多个不同状态。每个状态 s' 有不同的发生概率 P(s' \mid s, a)，也有自己的价值 V(s')，因此需要对这些未来状态价值做加权平均。

再乘上折扣因子：

$ \gamma \sum_{s'} P(s' \mid s, a) V(s') $

表示折扣后的未来期望价值。

所以这一整项：

$ R(s, a) + \gamma \sum_{s'} P(s' \mid s, a) V(s') $

表示：

在状态 s 下选择动作 a，能够带来的总价值。

最后外面的 \max_a 表示：

在所有可能动作中，选择总价值最大的那个动作。

因此，Bellman 方程本质上是在说：

一个动作好不好，不只取决于它眼前能带来多少奖励，还取决于它会把智能体带到什么样的未来状态。

这也是动态规划、Q-learning、DQN、PPO 等强化学习方法的重要理论基础。

3. POMDP：当智能体看不清完整状态

MDP 有一个较强的假设：智能体能够知道完整的当前状态。

但现实中，很多场景并不满足这个条件。

例如：

• 自动驾驶汽车无法知道所有车辆的真实意图；
• 机器人只能通过摄像头看到局部环境；
• 游戏 AI 可能看不到地图上的全部敌人；
• 推荐系统无法完全知道用户真实偏好。

这时就需要 POMDP。

POMDP 全称是 Partially Observable Markov Decision Process，中文叫 部分可观测马尔可夫决策过程。

相比 MDP，POMDP 多了一个核心概念：观察 Observation。

POMDP 通常可以表示为：

$ \mathcal{M} = (S, A, P, R, \Omega, O, \gamma) $

其中：

• S：真实状态集合；
• A：动作集合；
• P：状态转移函数；
• R：奖励函数；
• \Omega：观察集合；
• O(o \mid s', a)：观察概率函数；
• \gamma：折扣因子。

在 POMDP 中，智能体看不到真实状态 s，只能看到一个局部观察 o。

因此，策略不再直接写成：

$ \pi(a \mid s) $

而更像是：

$ \pi(a \mid o) $

不过更准确地说，智能体通常需要根据历史观察和历史动作维护一个 belief，也就是对真实状态的概率估计：

$ b(s) = P(s \mid h) $

其中 h 表示智能体过去经历过的观察和动作历史。

belief 可以理解为：

智能体对“当前真实状态是什么”的概率分布。

例如，一个机器人在迷宫中移动，但它的传感器不够精确。它可能会认为：

$ b(s_A) = 0.7 $

$ b(s_B) = 0.2 $

$ b(s_C) = 0.1 $

也就是说，它认为自己有 70% 的概率在位置 A，20% 的概率在位置 B，10% 的概率在位置 C。

这就是 POMDP 比 MDP 更难的地方：智能体不仅要做决策，还要推断自己到底处于什么状态。

4. Dec-POMDP：多个智能体，各自只能看到局部信息

Dec-POMDP 全称是 Decentralized Partially Observable Markov Decision Process，中文可以叫 去中心化部分可观测马尔可夫决策过程。

它可以理解成 POMDP 的多智能体版本。

如果用一句话对比：

• MDP：一个智能体，能看到完整状态；
• POMDP：一个智能体，只能看到局部观察；
• Dec-POMDP：多个智能体，每个智能体都只能看到自己的局部观察。

Dec-POMDP 描述的是：

多个智能体在无法看到完整环境、也无法完全知道彼此信息的情况下，如何协作完成一个共同目标。

一个 Dec-POMDP 通常可以表示为：

$ \mathcal{M} = (S, {A_i}*{i=1}^{n}, T, R, {\Omega_i}*{i=1}^{n}, O, \gamma) $

其中：

• S：全局真实状态集合；
• A_i：第 i 个智能体的动作集合；
• T：状态转移函数；
• R：团队共享奖励函数；
• \Omega_i：第 i 个智能体的观察集合；
• O：观察概率函数；
• \gamma：折扣因子；
• n：智能体数量。

在 Dec-POMDP 中，每个智能体 i 都有自己的动作 a_i。

所有智能体的动作组合在一起，形成联合动作：

$ \mathbf{a} = (a_1, a_2, \dots, a_n) $

环境根据当前真实状态 s 和联合动作 \mathbf{a} 转移到下一个状态 s'：

$ P(s' \mid s, \mathbf{a}) $

或者写成：

$ P(s' \mid s, a_1, a_2, \dots, a_n) $

每个智能体会收到自己的局部观察：

$ o_i \in \Omega_i $

整个团队获得一个共享奖励：

$ R(s, \mathbf{a}) $

目标是最大化团队的长期累计奖励：

$ \mathbb{E} \left[ \sum_{t=0}^{\infty} \gamma^t R(s_t, \mathbf{a}_t) \right] $

5. Decentralized 到底是什么意思？

Dec-POMDP 中的 Decentralized，重点不是说训练时一定不能使用集中信息，而是说：

执行时，每个智能体只能根据自己的局部信息独立做决策。

在 MDP 中，策略通常可以写成：

$ \pi(a \mid s) $

意思是：

给定完整状态 s，选择动作 a。

但在 Dec-POMDP 中，第 i 个智能体看不到完整状态 s，它只能根据自己的局部历史 h_i 选择动作：

$ \pi_i(a_i \mid h_i) $

这里的 h_i 可以表示：

$ h_i = (o_i^0, a_i^0, o_i^1, a_i^1, \dots, o_i^t) $

也就是说，第 i 个智能体只能基于自己过去看到过什么、做过什么，以及当前观察到了什么来决策。

多个智能体的局部策略组合起来，形成联合策略：

$ \boldsymbol{\pi} = (\pi_1, \pi_2, \dots, \pi_n) $

Dec-POMDP 要求我们寻找一个最优联合策略：

$ \boldsymbol{\pi}^* = \arg\max_{\boldsymbol{\pi}} \mathbb{E}*{\boldsymbol{\pi}} \left[ \sum*{t=0}^{\infty} \gamma^t R(s_t, \mathbf{a}_t) \right] $

这就是 Dec-POMDP 的核心问题。

6. 一个直观例子：仓库机器人协作

假设有两个机器人在仓库中寻找并搬运一个包裹。

如果用 MDP 建模，问题可能是：

• 只有一个机器人；
• 它知道完整仓库地图；
• 它知道自己和包裹的准确位置；
• 它每一步选择上、下、左、右；
• 目标是用最短路径找到包裹。

这时，机器人的策略可以写成：

$ \pi(a \mid s) $

也就是根据完整状态 s 选择动作 a。

但在 Dec-POMDP 中，情况会变成：

• 有多个机器人；
• 每个机器人只能看到自己附近的区域；
• 机器人之间不能实时共享所有信息；
• 每个机器人都不知道其他机器人具体观察到了什么；
• 它们需要协作完成寻找和搬运任务；
• 最终奖励由整个团队共享。

比如：

• 机器人 A 可能看到了包裹；
• 机器人 B 没看到包裹，但看到了通道堵塞；
• A 不一定知道 B 的观察；
• B 也不一定知道 A 的观察；
• 但它们仍然要通过各自的局部决策完成协作。

此时，两个机器人的联合动作可以写成：

$ \mathbf{a} = (a_A, a_B) $

环境转移可以写成：

$ P(s' \mid s, a_A, a_B) $

共享奖励可以写成：

$ R(s, a_A, a_B) $

机器人 A 和机器人 B 的策略分别是：

$ \pi_A(a_A \mid h_A) $

$ \pi_B(a_B \mid h_B) $

其中 h_A 和 h_B 分别是两个机器人各自的局部历史。

这就是 Dec-POMDP 的核心难点：

每个智能体都只掌握不完整的信息，但最终要形成全局协作行为。

7. MDP 与 Dec-POMDP 的核心区别

8. 为什么 Dec-POMDP 比 MDP 难很多？

MDP 的核心问题是：

当前状态下，如何选择最优动作？

但 Dec-POMDP 的难点是多层叠加的。

8.1 每个智能体看不到完整状态

在 MDP 中，智能体知道当前状态 s。

但在 Dec-POMDP 中，每个智能体只能看到自己的局部观察 o_i：

$ o_i \sim O_i(o_i \mid s) $

这意味着智能体必须先推断环境，再做决策。

8.2 每个智能体不知道其他智能体看到了什么

在多智能体协作中，一个智能体不仅要考虑环境，还要考虑队友。

但问题是：

我不知道队友看到了什么，也不知道队友会如何判断，但我还要和它配合。

这会导致协作难度显著上升。

8.3 联合动作空间会快速膨胀

如果有 n 个智能体，每个智能体都有 m 个动作，那么联合动作空间大小是：

$ |A| = m^n $

例如，5 个机器人，每个机器人有 10 个动作，那么联合动作空间就是：

$ 10^5 = 100000 $

这意味着动作组合数量会随着智能体数量指数级增长。

8.4 历史信息也会快速膨胀

在 MDP 中，智能体可以直接根据当前状态 s_t 做决策。

但在 Dec-POMDP 中，每个智能体通常要基于自己的历史信息 h_i^t 做决策：

$ h_i^t = (o_i^0, a_i^0, o_i^1, a_i^1, \dots, o_i^t) $

随着时间步 t 增长，可能的历史轨迹数量也会快速增加。

因此，Dec-POMDP 通常比 MDP 难求解得多。

9. 从 MDP 到 Dec-POMDP 的演进关系

可以用下面这个路径来理解：

$$ \text{MDP：}

\text{Single-Agent} + \text{Fully Observable} $$

$$ \text{POMDP：}

\text{Single-Agent} + \text{Partially Observable} $$

$$ \text{Dec-POMDP：}

\text{Multi-Agent} + \text{Partially Observable} + \text{Decentralized Execution} $$

也就是说，Dec-POMDP 在 MDP 的基础上同时增加了两个复杂度：

$ \text{Single-Agent} \rightarrow \text{Multi-Agent} $

$ \text{Fully Observable} \rightarrow \text{Partially Observable} $

如果再加上去中心化执行的限制，问题会进一步复杂化。

10. 集中训练，去中心化执行

在现代多智能体强化学习中，经常会使用一种范式：

Centralized Training, Decentralized Execution，简称 CTDE。

它的意思是：

训练时，可以使用更多全局信息，例如完整状态 s、所有智能体的动作 \mathbf{a}、全局奖励 R。

但执行时，每个智能体仍然只能根据自己的局部历史 h_i 做决策：

$ \pi_i(a_i \mid h_i) $

这种方式试图在训练效率和部署约束之间取得平衡。

也就是说，训练时可以“开上帝视角”，但真正执行时，每个智能体仍然必须只依赖自己的局部信息。

11. 总结

MDP 和 Dec-POMDP 都是在描述序列决策问题，但它们适用的场景不同。

MDP 更适合描述：

• 单个智能体；
• 能够观察完整状态；
• 根据当前状态做动作选择；
• 目标是最大化长期累计奖励。

它的策略形式通常是：

$ \pi(a \mid s) $

它的目标可以写成：

$ \pi^* = \arg\max_{\pi} \mathbb{E}*{\pi} \left[ \sum*{t=0}^{\infty} \gamma^t R(s_t, a_t) \right] $

Dec-POMDP 更适合描述：

• 多个智能体；
• 每个智能体只能看到局部信息；
• 执行时没有中心控制器；
• 所有智能体需要协作完成共同目标。

它的局部策略形式通常是：

$ \pi_i(a_i \mid h_i) $

它的联合优化目标可以写成：

$ \boldsymbol{\pi}^* = \arg\max_{\boldsymbol{\pi}} \mathbb{E}*{\boldsymbol{\pi}} \left[ \sum*{t=0}^{\infty} \gamma^t R(s_t, \mathbf{a}_t) \right] $

一句话总结：

MDP 是强化学习中最基础的单智能体决策模型；Dec-POMDP 则是面向多智能体、部分可观测、去中心化协作场景的更复杂模型。

如果说 MDP 关心的是：

我在当前状态下应该做什么？

那么 Dec-POMDP 关心的是：

我们每个人都只知道一部分信息，在无法完全共享视野的情况下，应该如何配合？

这也是 Dec-POMDP 在多机器人协作、自动驾驶车队、分布式控制、多智能体强化学习中非常重要的原因。

Finished reading? Leave a comment

在日常开发和运维中，rsync 是一个非常常见的文件同步工具。相比 cp、scp 这类直接复制工具，rsync 最大的特点是：它不一定会把整个文件重新传输，而是尽量只传输变化的部分。

这篇文章会从三个问题入手解释 rsync 的核心原理：

1. rsync 如何快速判断两个文件是否需要同步？
2. rsync 如何只传输文件中的差异部分？
3. rolling checksum 和 strong checksum 是如何协作的？

--

1. rsync 解决的核心问题

假设我们有两个文件：

源端新文件：A
目标端旧文件：B

我们希望把目标端的 B 更新成源端的 A。

最简单的做法是直接把 A 整个传过去，覆盖 B：

scp A remote:/path/B

但是如果文件很大，比如几个 GB，而实际只改了其中几 KB，那么整体传输就很浪费。

rsync 的目标就是：

尽量复用目标端已经存在的数据，只传输真正变化的部分。

这就是 rsync 的核心价值。

2. rsync 默认如何判断文件是否一致？

很多人以为 rsync 默认会对文件内容做 hash 校验，其实不是。

默认情况下，rsync 会使用一种很快的判断方式，通常叫做 quick check。

它主要看两个元信息：

1. 文件大小 size
2. 最后修改时间 mtime

如果源端和目标端的文件大小一致，并且修改时间也一致，rsync 默认会认为这个文件没有变化，不需要同步。

所以执行：

rsync -av src/ dst/

时，大多数未变化文件会被快速跳过。因为读取文件大小和修改时间只需要访问文件元数据，不需要把整个文件读一遍。

这也是 rsync 在同步大量文件时很快的原因之一。

不过，这种判断不是严格的内容校验。如果文件内容被修改了，但文件大小没变，而且修改时间也被人为恢复成原来的值，那么默认 rsync 可能无法发现变化。

如果你希望严格按文件内容判断，可以使用：

rsync -avc src/ dst/

其中 -c 或 --checksum 会让 rsync 计算文件内容的 checksum，再判断文件是否一致。

代价是：两端都要读取完整文件内容，所以会明显增加磁盘 I/O。

简单总结：

默认模式：size + mtime，速度快，但不是严格内容校验
checksum 模式：按内容校验，更可靠，但更慢

3. rsync 真正厉害的地方：差异传输

当 rsync 判断某个文件需要更新时，它并不一定会把整个文件重新传过去。

它会尝试找出：

源端新文件 A 中，哪些内容目标端旧文件 B 已经有了？
哪些内容是目标端没有的，需要真正传输？

这个过程就是 rsync 的 delta-transfer algorithm，也就是差异传输算法。

核心思想可以概括为一句话：

目标端告诉源端：我已有这些数据块；
源端扫描新文件：发现哪些块你已经有了，我就不传，只传你没有的部分。

4. 差异传输的基本流程

假设目标端已有旧文件 B。

第一步，目标端会把旧文件 B 切成固定大小的 block：

B = [B0][B1][B2][B3][B4]...

然后目标端会为每个 block 计算两个 checksum：

B0 -> weak0, strong0
B1 -> weak1, strong1
B2 -> weak2, strong2
...

这里有两种 checksum：

weak checksum：弱校验，也就是 rolling checksum
strong checksum：强校验，用来最终确认块是否真的一致

目标端不会把整个旧文件传给源端，而是只把这些 block 的 checksum 列表发给源端。

接下来，源端拿到这些 checksum 后，开始扫描源端的新文件 A。

5. rolling checksum 是什么？

rolling checksum 可以理解成一种适合“滑动窗口”的弱校验。

普通 hash 的问题是：如果窗口移动 1 个字节，通常要重新计算整个窗口的 hash。

例如窗口大小是 4KB：

窗口 1：[第 0 字节 ... 第 4095 字节]
窗口 2：[第 1 字节 ... 第 4096 字节]

两个窗口只差了一个字节，但普通 hash 通常需要重新读完整个 4KB 来计算。

rolling checksum 的优势是：它可以基于上一个窗口的结果，快速算出下一个窗口的校验值。

可以粗略理解为：

新 checksum = 旧 checksum - 离开窗口的字节 + 进入窗口的字节

真实算法会比这个更复杂，但直觉就是这样。

所以 rolling checksum 非常适合源端扫描新文件：

A = abcdefghijklmnop
    [----]            窗口 1
     [----]           窗口 2
      [----]          窗口 3

窗口每次向后滑动 1 个字节，都可以快速得到新的 weak checksum。

6. strong checksum 是什么？

rolling checksum 虽然快，但它是弱校验，可能发生碰撞。

也就是说，两个不同的数据块，有可能算出相同的 weak checksum。

如果 rsync 只依赖 rolling checksum，就可能把两个不同的数据块误认为相同，导致最终同步出来的文件内容错误。

所以 rsync 还需要 strong checksum。

strong checksum 的作用是：

当 rolling checksum 发现一个“疑似匹配”时，再用 strong checksum 做最终确认。

它比 rolling checksum 更可靠，但计算成本也更高。

因此，rsync 不会对每一个滑动窗口都计算 strong checksum，而是只在 weak checksum 命中时才计算。

7. rolling checksum 和 strong checksum 如何协作？

这部分是 rsync 算法的核心。

目标端旧文件 B 已经被切成多个 block，并且每个 block 都有一对 checksum：

B0 -> weak0, strong0
B1 -> weak1, strong1
B2 -> weak2, strong2
...

源端扫描新文件 A 时，会不断移动一个大小相同的窗口。

对于每个窗口，先计算 rolling checksum：

window = A[pos : pos + block_size]
weak = rolling_checksum(window)

然后拿这个 weak checksum 去目标端发来的 checksum 表中查找。

情况一：weak checksum 没有命中

如果没有命中，说明这个窗口大概率不是目标端已有的任何 block。

于是源端继续向后滑动 1 个字节：

当前位置没有匹配
=> 窗口后移 1 字节
=> 继续计算 rolling checksum

这一步很快，因为 rolling checksum 可以增量计算。

情况二：weak checksum 命中

如果 weak checksum 命中了某个旧 block，比如 B7：

A 的当前窗口 weak checksum == B7 的 weak checksum

这说明当前窗口“可能”和旧文件里的 B7 相同。

但这只是疑似匹配。

接下来，源端会对当前窗口计算 strong checksum：

strong = strong_checksum(A[pos : pos + block_size])

然后和 B7 的 strong checksum 比较：

如果 strong == strong7
=> 基本确认 A 的当前窗口和 B7 是同一段内容

确认匹配之后，源端就不需要发送这段数据本身了。

它只需要告诉目标端：

复制你本地旧文件里的第 7 个 block

也就是发送一条类似这样的指令：

copy block B7

对于无法匹配的内容，源端才会发送原始字节数据，也就是 literal data。

最终，目标端收到的是一串构造指令：

literal "abc"
copy B7
copy B8
literal "xyz"
copy B12
...

目标端根据这些指令，把旧文件已有的 block 和新传输的 literal data 组合起来，重建出新的文件 A。

8. 为什么不只用 strong checksum？

因为源端扫描新文件时，不是只看固定块边界，而是要在新文件的所有可能偏移位置上寻找匹配。

如果文件很大，每个偏移位置都计算 strong checksum，成本会非常高。

rolling checksum 的价值就在于：

它可以非常便宜地扫描大量候选位置。

所以它适合做第一层过滤。

只有当 rolling checksum 命中时，rsync 才会计算 strong checksum。

这样可以避免大量不必要的强校验计算。

9. 为什么不只用 rolling checksum？

因为 rolling checksum 是弱校验，存在碰撞风险。

如果只靠它判断两个 block 是否相同，就可能出现误判。

strong checksum 的作用就是降低误判概率，保证最终重建出来的文件尽可能可靠。

所以二者的分工是：

rolling checksum：负责快速发现疑似匹配
strong checksum：负责确认疑似匹配是否真的成立

可以把它理解成一个两阶段过滤器：

第一阶段：rolling checksum 快速筛选候选块
第二阶段：strong checksum 精确确认候选块

这就是 rsync 能同时做到“快”和“可靠”的原因。

10. 一个简化例子

假设目标端旧文件 B 被切成 4 个 block：

B = [B0][B1][B2][B3]

目标端计算并发送：

B0 -> weak0, strong0
B1 -> weak1, strong1
B2 -> weak2, strong2
B3 -> weak3, strong3

源端新文件 A 内容中，前面插入了一小段新数据，但后面大部分内容和旧文件一样：

A = [新数据][B1][B2][B3]

源端扫描 A 时，会发现：

开头的新数据无法匹配旧 block
=> 需要发送 literal data

后面的窗口匹配到 B1
=> 发送 copy B1

继续匹配到 B2
=> 发送 copy B2

继续匹配到 B3
=> 发送 copy B3

最终源端只需要发送：

literal "新数据"
copy B1
copy B2
copy B3

目标端就可以根据旧文件 B 和这些指令重建出新文件 A。

这就是为什么在大文件只改动一小部分时，rsync 的传输量会远小于直接复制整个文件。

11. 本地判断两个文件是否完全一致，应该用什么？

如果只是想在本机判断两个文件是否完全一致，最直接的方式其实不是 rsync，而是 cmp：

cmp -s file1 file2 && echo same || echo diff

cmp 会按字节比较两个文件。

几种方式的区别：

stat：
只看元数据，例如 size、mtime，最快，但不严格

cmp：
逐字节比较，适合判断两个本地文件是否完全一致

sha256sum：
计算完整 hash，适合生成指纹、跨机器保存和比对

rsync：
适合同步目录或跨机器增量同步

如果只是同步目录：

rsync -av src/ dst/

如果你怀疑文件的修改时间不可靠，希望按内容判断：

rsync -avc src/ dst/

如果只是想预览哪些文件会变化：

rsync -avcni src/ dst/

其中：

-a：归档模式，保留权限、时间等信息
-v：显示详细信息
-c：按 checksum 判断内容变化
-n：dry-run，只预演，不真正修改
-i：输出变更摘要

12. 总结

rsync 的实现原理可以分成两层：

第一层是快速判断文件是否需要处理。

默认情况下，rsync 使用：

文件大小 size + 修改时间 mtime

来快速跳过未变化文件。

第二层是对需要更新的文件做差异传输。

它使用：

rolling checksum + strong checksum

来寻找源端新文件中哪些数据块已经存在于目标端旧文件中。

两者的协作方式是：

rolling checksum 负责快速扫描和发现候选块；
strong checksum 负责确认候选块是否真的相同。

找到匹配块后，源端不需要发送真实数据，只需要发送类似：

copy block N

这样的引用指令。

找不到匹配的部分，才发送原始数据。

因此，rsync 能够在文件变化很小的情况下，大幅减少传输量。

一句话概括：

rsync 默认靠 size + mtime 快速判断文件是否变化；
真正同步变化文件时，靠 rolling checksum 找候选块，靠 strong checksum 确认匹配，只传输目标端缺失的数据。

这就是 rsync 高效同步的核心原理。

Finished reading? Leave a comment

很多人使用 AI 的方式，其实还停留在“搜索框时代”。

输入一个问题，等待一个答案。 如果答案看起来流畅，就觉得它“很聪明”；如果答案有点空，就换个模型再问一遍。

但这并没有真正发挥大模型的价值。

最近 Nav Toor 在 X 上分享了一套基于 Stanford STORM 思路的 Claude 调研方法，核心不是让 AI “更会回答”，而是让 AI 像研究者一样拆解问题：从多个立场提问，暴露冲突，综合证据，再进行自我审查。(X (formerly Twitter))

STORM 到底是什么？

STORM 是 Stanford OVAL 提出的一个知识整理与长文写作系统，全称是 Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking，大意是：通过检索和多视角提问来综合主题大纲。它的目标不是简单生成一篇文章，而是在写作之前先完成“研究”和“搭框架”的过程。(ACL Anthology)

它背后的思想很朴素：

好的问题，往往不是从一个角度问出来的。 真正的洞察，通常藏在不同视角的冲突里。

所以 STORM 不急着输出结论，而是先让模型模拟不同角色：实践者、学者、怀疑者、经济学人、历史学家。每个角色都带着自己的问题意识去看同一个主题。

这一步非常关键。 因为普通提问容易得到“互联网平均答案”，而多视角提问会逼迫模型暴露问题的复杂性。

一套可复用的 AI 深度调研流程

这套方法可以拆成四步。

第一步：多视角扫描

不要直接问：

帮我分析一下 X。

而是让 AI 从多个角色出发：

请从实践者、学术研究者、怀疑论者、经济学人、历史观察者五个角度分析这个问题。 每个角度都要说明：它最关心什么、它掌握什么证据、它可能看到哪些其他角度忽略的事实。

这样做的好处是，模型不会只顺着一个方向讲故事。

实践者会提醒你现实操作里的摩擦； 学者会要求证据和同行评议； 怀疑者会专门找漏洞； 经济学人会追问利益结构； 历史学家会寻找周期和先例。

一个问题被五种视角同时照亮后，信息密度会明显提高。

第二步：画出矛盾地图

多视角分析之后，不要马上总结。 下一步应该让 AI 找冲突。

你可以继续问：

上面这些视角之间，哪些观点是直接矛盾的？ 哪些证据最强？哪些证据最弱？ 所有视角都承认的共识是什么？ 有没有所有人都忽略的盲区？

这一步的价值在于：它把“看起来都对”的观点放到同一张桌子上比较。

很多 AI 生成内容的问题，不是没有信息，而是没有冲突。 它会把各种材料平铺出来，但不告诉你哪些观点互相打架、哪些论点其实站不住。

而研究的关键，恰恰是识别冲突。

第三步：综合成研究简报

当视角和冲突都清楚之后，再让 AI 输出正式简报。

可以要求它包含：

1. 用一段话讲清楚核心结论
2. 按可信度排序列出关键发现
3. 说明每个发现由哪些视角支持、又被哪些视角质疑
4. 找出一个隐藏关联
5. 给出面向具体角色的行动建议
6. 提出一个最值得继续研究的前沿问题

这一步很适合用于写文章、做竞品分析、研究新技术方向、准备面试、判断商业机会。

因为它输出的不是“资料堆砌”，而是一份有结构、有冲突、有行动含义的研究结果。

第四步：让 AI 自我评审

最后一步很多人会忽略：让 AI 审查自己的答案。

你可以问：

请对刚才的研究简报做一次严格评审。 哪些结论置信度最高？哪些最弱？ 是否存在偏见？ 是否缺少关键视角？ 如果由一位严苛的教授审阅，他会要求你修改哪里？

这一步不是形式主义。

大模型最大的问题之一，是它很容易把“讲得顺”包装成“讲得对”。 自我评审的作用，就是强制它把结论拆开，标记不确定性，暴露薄弱环节。

为什么这比普通 Prompt 更有效？

普通 Prompt 的逻辑是：

我问一个问题，你给一个答案。

STORM 式 Prompt 的逻辑是：

我先让你从多个角度提出问题，再让你比较冲突，最后才综合答案。

这两者差别很大。

前者像搜索。 后者像研究。

搜索追求速度，研究追求结构。 搜索容易得到结论，研究会先暴露不确定性。 搜索把 AI 当信息压缩器，研究把 AI 当思考协作者。

Stanford 的 STORM 论文也强调了预写作阶段的重要性：在正式写作前，系统需要先发现不同视角、模拟带有不同立场的提问，并基于可信来源整理信息和大纲。(ACL Anthology)

适合用在哪些场景？

这套方法特别适合复杂问题，比如：

• 调研一个新技术方向
• 分析一个产品机会
• 判断一个行业趋势
• 写一篇深度博客
• 准备面试或分享
• 做投资、职业、创业方向判断
• 分析一个争议性观点

它不太适合问简单事实，比如“某个命令怎么写”“某个概念是什么意思”。 但只要问题涉及多方利益、历史背景、证据强弱、行动决策，这套方法就很有用。

但也别神化它

STORM 不是让 AI 自动变成博士。 它只是把研究流程结构化了。

你仍然需要注意三件事：

第一，AI 可能引用不可靠来源。 第二，它可能把无关事实强行关联。 第三，它可能继承检索结果里的偏见。

STORM 论文中也提到，生成长文仍然会遇到来源偏差转移、无关事实过度关联等挑战。(arXiv)

所以更准确的说法是：

STORM 不是替你完成判断，而是帮你搭建一个更好的判断框架。

一个可直接复制的通用模板

你可以把下面这段保存下来，以后调研复杂问题时直接使用：

我想对【你的研究主题】做一次深度调研。

请不要直接给结论，而是按照以下流程完成：

1. 多视角分析：
请从实践者、学术研究者、怀疑论者、经济学人、历史观察者五个角度分析这个主题。
每个角度需要给出：
- 核心立场
- 最重要的证据
- 它能看到但其他视角容易忽略的事实

2. 矛盾地图：
请比较这些视角之间的冲突：
- 哪些观点直接矛盾？
- 哪些证据最强，哪些证据最弱？
- 所有视角都承认的共识是什么？
- 是否存在共同忽略的盲区？

3. 研究简报：
请把以上内容整理成一份研究简报：
- 一段话核心总结
- 5 个最重要发现，并按可信度排序
- 一个隐藏关联
- 面向【你的身份/目标】的行动建议
- 一个最值得继续研究的问题

4. 自我评审：
请审查这份简报：
- 每个关键发现的置信度
- 最薄弱的论点
- 可能存在的偏见
- 是否缺少关键视角
- 如果由严苛专家审阅，最需要修改哪里

结语

AI 时代真正重要的能力，可能不是“会不会用某个模型”，而是“会不会组织问题”。

当你只问一个问题时，AI 给你的往往是平均答案。 当你让它从多个视角互相辩论时，它才更可能产出洞察。

不要只把 Claude、ChatGPT 或 Gemini 当搜索框。 让它们成为你的研究小组。

这才是 STORM 方法最值得借鉴的地方。

Finished reading? Leave a comment

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

《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 系统的核心基础设施。

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

Finished reading? Leave a comment

—— 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 能高效工作的系统。

Finished reading? Leave a comment

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 系统工程里，很多时候 更好的系统设计比更大的模型更重要。

Finished reading? Leave a comment

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%”。

Finished reading? Leave a comment

最近看到宝玉叔分享的一场来自 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 时代，一个非常重要的认知转变是：

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

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

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

Finished reading? Leave a comment

最近，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 太快。 而是我们对变化的感知太慢。

Finished reading? Leave a comment