引言

我们正处在大语言模型快速渗透各行各业的时代。模型的能力边界在哪里？它的推理过程究竟是怎样的？围绕模型构建的智能体工具——特别是近期大热的Skill——是否真的是一个好的技术方向？这篇文章试图从模型推理的底层机制出发，一路推演到当前智能体工具生态中存在的结构性问题，提供一个分析性的视角。

什么是大语言模型

现在的大语言模型（Large Language Model）本质上是一种概率生成语言模型（Probabilistic Generative Language Model）。这里有两个关键属性需要理解。

第一，它是生成模型。 不同于判别式模型，生成模型把握的是生成过程的分布，而不是空间中特征的划分。

第二，它是概率模型。 它设定了一种新的文本生成的统计过程——区别于传统的统计生成模型（statistical generative model），这个统计过程是从大量的文本数据中学习得到的，而非由人工设计的规则或预设驱动。

大语言模型的训练

模型的训练分成两个阶段。

基座模型训练

第一个阶段叫做基座模型训练（Base Model Training）。在这个阶段，目标函数只有一个：尽可能准确地预测下一个 token。Transformer架构中的 decoder 为训练提供了支持——大多数现代大语言模型本质上就是 decoder 的不断堆叠。这个阶段训练出来的模型还无法通过对话的方式同用户进行交互，它只能对输入进行补完（completion）。

后训练：从Base LLM到Instructed LLM

第二个阶段是后训练（Post-training），这是一个包含多个步骤的复杂流程。其中最核心的环节是 RLHF（基于人类反馈的强化学习）。大家在网页端使用模型时，经常会看到系统弹出两个回答选项让你选择——这些反馈会被用来对模型的输出进行排序，使模型生成的答案更符合用户偏好。在此基础上，还会引入更接近传统强化学习的训练步骤，进一步提升模型的对齐效果。

从Base LLM到Instructed LLM的后训练流程（来自AWS）

Scaling Law及其局限

Scaling Law（缩放定律）描述的是这样一个规律：当训练模型的计算量、数据量和参数规模这三个维度同比例增长时，模型的能力才会出现线性增长。我经常开玩笑说，如果社会科学家也有信仰的话，我们可能很多年前就买了英伟达的股票——但大家确实都不太有这个信仰。

Scaling Law曲线（来自Kaplan 2020）

然而，现在大家的直觉感受是：传统的 Scaling Law 已经失效了。失效的原因其实很简单——我们只有一个互联网。互联网上灰色、黑色、白色的数据都已经被拿来使用了，无论来源如何，能用的数据基本都已经被穷尽。数据集的大小率先遇到了瓶颈，这也是为什么业界开始强调”合成数据”等策略。

但在模型训练和应用的整个pipeline上，能够提升的空间还有很多。虽然训练端的Scaling Law 已经遇到了天花板，模型的能力仍在持续增长。其中一个非常重要的方向叫做 test-time scaling（测试时缩放）。

从推理模型（reasoning model）到现在的智能体使用（agentic usage），本质上都遵循着 test-time scaling 的逻辑。推理模型在做什么？它其实是在生成一个更加可靠的上下文，让最终的答案部分变得更加准确——通过增加推理时长来实现这一点。智能体使用也遵循类似的原理：我们原来一次在网页端与模型交互，最多也就50秒；而现在的 agentic usage 可以连续运行四五个小时。所以，虽然传统的 Scaling Law 失效了，但我们找到了新的提升路径。

模型推理的过程

这是本文的核心技术章节。让我们深入理解模型到底是怎么做推理的。

Next Token Prediction的迭代过程

我们说过，现在的模型基本都是 decoder 堆叠而成的。最后一层——也就是输出层（output layer）——本质上是一个线性层，它把所有的 token 按概率进行排布。

模型推理过程示意图（decoder迭代），来自《从零构建大模型》

具体过程是这样的：模型接收到一个输入词之后，首先进行编码和预处理——把字符转换成数字（即 token 编号），然后做 embedding（嵌入），经过多层 decoder 的非线性变换之后，输出下一个词的概率分布。然后将该输出重新输入模型，再过一遍，直到模型输出一个特殊的终止 token，表示”我要终止输出了”，整个过程才结束。

以图中的例子来说，模型并不是一开始就“想好”整句 This is an example，而是通过 decoder 逐轮完成 next token prediction：第一轮输入只有 This，模型在当前 context 上预测下一个最可能的 token，于是得到 is，句子变成 This is；第二轮再把 This is 作为新的输入，预测出 an，形成 This is an；第三轮继续以 This is an 为上下文，生成 example。也就是说，图中三次迭代的关键并不只是“文本越来越长”，而是每一轮输出都会回流为下一轮输入，模型始终只在“已有文本”的基础上向前迈一步。所谓生成，其实就是这样一个不断重复的局部预测过程：不是先有完整答案，再逐字打印出来；而是每次只决定下一个 token，最后拼出看似连贯的句子。

从确定性到随机性

在传统的语言模型中，这个过程其实是确定性的——只要你喂给它同样的输入，后面的输出就一定是一样的。

那为什么我们在日常交互中感受到模型似乎有”随机性”呢？因为如果每次对同一问题都给出完全相同的回答，用户会觉得这个模型非常不自然。所以在模型最后输出的时候，我们会人为地加入一些噪音。

比如 top-k sampling：在最后一个线性层输出概率分布之后，我们选取概率最高的前K个 token，然后对它们进行 renormalize（重新归一化），最后从中随机采样一个。这样，每次问同一个问题，模型给出的回复就会有所不同。

top-k sampling与噪音注入过程（来自Raschka 2024）

这张图展示了 top-k sampling 的核心机制：模型先根据当前上下文，例如 I went for a，为整个词表中的候选 token 分配概率，随后并不直接在全部候选里采样，而是先截取概率最高的前 k 个选项。图中的 k=3，因此只保留 run、walk 和 stroll，其余像 movie、grocery、fun 等候选会被直接丢弃。接着，系统对这三个保留下来的概率重新做一次归一化，使它们之和重新变为 1，然后再按新的概率分布随机抽样。这样一来，模型的输出就从“确定地选择概率最大的那个词”变成了“在合理候选空间内引入受控随机性”：walk 可能最有可能，但 run 或 stroll 也并非完全没有机会。这正是语言模型从确定性预测走向多样化输出的关键一步。

我们人为加入的噪音与模型的推理能力是紧密相连的。现在主流的推理模型已经不允许用户调整 temperature（即噪音注入的程度）了，因为一旦修改了 temperature，模型的推理能力很可能就会失效。

棱镜比喻

从这一点出发，我们可以建立一个比喻来理解模型的输出过程：

模型的所有参数，相当于把整个互联网上所有的材料压缩到了一个几百TB的权重之中。我们的 prompt 和 context 就像一面棱镜——光线（模型的知识）通过棱镜（我们的提示），投射出特定的输出。而这个输出不是一个点，而是一个空间。

棱镜投射比喻（来自Zhang et al. 2025 “Knowing Your Uncertainty”）

为什么是空间而非点？因为同一个问题可以用很多种不同的方式去问，再加上模型内在的噪音机制，最后的输出会是一个包含多种可能答案的空间。根据任务需求的不同，有时我们只需要其中的一个最优点；有时我们需要理解这个输出空间（ideal output space）的整体形状；有时我们甚至可以去模拟和刻画这个理想输出空间，但有的时候我们完全不知道这个理想的输出空间是什么样子的——这一点会与当前的 agentic usage 密切相关。

“涌现”的争论与参差不齐的智能

在传统的机器学习框架下，模型需要为一个特定的目标函数而优化——比如推广告的模型，目标就是预测用户是否会点击某个广告，任务目标与训练目标高度贴合。但大语言模型不是这样的：base model 的训练只是为了预测下一个 token，我们却用它来完成各种各样完全不同的任务——这被称为 zero-shot 场景。这种超越训练目标的能力，被称为”涌现”（emergence）。

然而，有些研究者认为涌现可能只是一个错觉。模型并不是真正掌握了思维泛化的能力，而是对训练语料中出现过的内容形成了记忆。当训练语料中没有出现相关信息时，模型的表现往往非常差。

这就牵涉到一个关键概念：可验证性。当一个任务是可验证的——比如围棋的输赢、数学题的对错——模型就可以通过递归的方式不断改进。这正是推理模型（如DeepSeek-R1）的训练方向：它们在数学、编码等封闭系统中进行训练，因为这些任务的结果是可以明确验证的。

但我们在使用模型时，往往会因为相信涌现能力而把模型应用到所有领域。这就导致了一个问题：模型的能力并非在所有维度上都是均匀的，而是参差不齐的。这个概念被称为 Jagged Intelligence（参差不齐的智能）。比如，很多模型的编码能力非常强——因为编码是一个封闭系统，可以从环境中获得大量反馈——但在需要情商或社会认知的任务上却表现很差。

Jagged Intelligence示意图

我们的实际业务中往往同时包含可验证的环节和不可验证的环节。代码可以验证，但设计好坏难以验证，或验证成本极高。因此，在使用模型的过程中，理解模型为什么会失败变得至关重要。

理解模型的失败

模型的失败可以归结为四类原因。（Argyle et al. 2025）

第一类：架构决定的固有限制

模型做的是 next token prediction——对它来说，所有的 token 在模型内部表征中都是一串数字。所以你让它数 “strawberry” 中有几个 “r”，它做不到，因为 “strawberry” 对它来说只是一个 token 编号，而不是一串可以逐个检查的字符。同样的道理，你让它算 1+1 等于几，它也可能出错；让它比较 9.9 和 9.11 哪个大，它同样困难——因为小数点后的 “11” 和 “9” 可能是两个独立的 token。这些在人类看来极其简单的任务，恰恰是模型架构本身决定了它无法完成的。

第二类：当前所有模型的前沿限制

有些任务是所有当前模型都还无法完成的，但未来可能可以。比如在 GPT-3.5 时代，推理和数学能力还非常差，但经过推理模型的专门训练后，这些任务的表现已经大幅提升。对于那些可验证的任务来说，模型的能力终将达到一个很高的水平。

第三类：特定模型的限制

有些模型不能完成的任务，性能更好的模型却可以完成。比如我最近为了教学购买了智谱的 Coding Plan，在使用过程中第一次产生了想要”PUA模型”的念头——这在使用 GPT 时从来没有过。

类似地，离线模型不知道最新发生的事情也属于此类：Claude 的 opus4 刚出来时，系统提示中就专门写上了”特朗普赢得了2024年美国总统选举”，因为它的训练语料没有涵盖这一信息。

第四类：提示词方法有问题

回到棱镜比喻——如果棱镜本身有问题，光线也不会投射到你想要的位置。这就是为什么 prompt 设计如此重要。而且，能力越差的模型对提示词越敏感。

从工具调用到泛用性智能体

2025年11月之后，智能体（Agent）的使用开始成熟并产生深远影响。Agentic usage 的核心思想是：模型可以调用工具从外部获取信息和反馈，而不是单纯地从内部参数做投射。

四个阶段的演进

第一阶段：计算器式工具调用。 最早的智能体使用其实是为了解决那些模型架构上做不到的任务。比如 Kimi 在某个版本中连 1+1 都算不清楚，一天内就修复了——怎么修的？它接了一个计算器出来。这就是最原始的工具调用。

第二阶段：规则化的工作流程。 随后出现了 LangChain 和 RAG 这类基于规则的流程。这些流程中所有的模型路由和调用逻辑都是人来确定的——人把规则写死了，模型只是在规则框架内执行。

第三阶段：Code Agent。 到2025年11月，人们发现在封闭环境中 Code Agent 能取得非常好的效果。因为代码能不能跑起来、测试通不通过，模型是可以直接从环境中获得反馈的。一次没成功可以试第二次、第三次……模型可以自主迭代。

第四阶段：泛用性Agent。 我们不再把智能体限制在编码这一个场景，而是希望把它应用到所有环境中——从外部获取信息，进行程序性操作。

推理范式的转变

行动体推理流程图

这是一个推理范式的根本变化。在最早的交互模式中，你有一个人类输入（human input），模型产生一个输出，交互就结束了。而现在，在初始输入和最终输出之间，模型在不断地进行迭代，不停地从外部获取信息。在最终生成的上下文（context）中，人的输入只占非常小的一部分——大部分上下文是通过 MCP、Skill 或 CLI 从外部环境获得的。

标准化脚手架：MCP、CLI与Skill

MCP、Skill 和 CLI 是模型同外界环境和工具进行交流的标准化脚手架。

CLI

CLI（命令行接口）是最基础的方式。它遵循 IEEE Standard 1003.1 标准，本质上就是你输入一个文本命令，系统给你一个文本回复。这对模型来说是天然适配的——因为模型最擅长的输出就是文本。更重要的是，所有的 CLI 都有规范、有规则，模型在训练中已经大量接触过这些标准，所以它知道怎么正确使用。现在很多主流工具，甚至 Google 的浏览器，都已经开放了 CLI 入口，可以直接通过命令行进行控制。

MCP

MCP（Model Context Protocol）旨在把所有的 API 进行统一。它本质上是一套 JSON 交流协议，规定了知识应该如何在模型和外部服务之间流动。每次调用不同的 API 时，你原来需要分别查看每个 API 的上下文结构；MCP 把这些全部统一了起来。

MCP架构示意图

Skill

Skill 并不只是一个 Markdown 文件。如果你打开一个设计良好的 Skill，会发现它封装得非常完整，包括主文档、references（引用文档）和工具代码。这里用到了 Claude Code 开创的一种模式——渐进式披露（progressive disclosure）：模型并不会把 Skill 中所有的内容一股脑加入上下文，而是根据主文档中的 references 部分，选择性地加载所需的文件。这一点非常重要，因为模型的上下文窗口在实际应用中是一种稀缺资源。当这个上下文窗口到达40%左右的时候，模型的性能就会开始下降，到70-80%的时候，就会出现明显的语境腐化（Context rot）的情况。

Skill文档结构示例

这里有一个关键约束：流程性的设计和测试标准必须写在主文档中，而代码、检查列表等辅助内容可以放在其他文件里，按需加载。一个好的 Skill 不仅要有流程描述，还应该提供代码脚手架（如数据处理的模板代码）、API 调用规范（通过 reference 按需加载），以及输出模板（report template）。

如何设计一个Skill

现在有很多 Skill Creator 工具——很多 agentic 框架都自带。你可以用这些工具来创建，也可以自己手写或者和模型协作完成。

有两个非常有用的参考材料：

• The Complete Guide to Building Skills for Claude

• 5 Agent Skill design patterns every ADK developer should know from Google Cloud

我认为一个经常被忽视的关键点是：你最好能够为你的 Skill 提供测试用例。特别是当你知道这个 Skill 对应的是一个可验证的任务时，提供测试用例会极大地提升 Skill 的准确程度。你甚至可以让模型帮你编写测试用例、执行 smoke test，把 smoke test 直接写进 Skill 模板中——这些都是可行的，也是推荐的做法。为 Skill 设立一个验证流程，往往会得到显著更好的效果。

这个测试和评估的过程，也是Anthropic推荐的技能建构的环节。测试之所以重要，是因为构建测试用例能够帮助你思考，你希望用Skill完成的任务究竟是不是一个可以验证/容易验证的任务。很多时候，我们可能没有意识到模型做的仅仅是生成一个形式上“像”的输出，或者只是在某一次推理中蒙中了答案。对于Skill进行系统性的评估能够迫使我们考虑，相关的任务是不是适合交给语言模型完成，我们又没有办法对此进行评估，而不仅仅是依靠我们的感觉。

为什么Skill不一定是一个好主意

讲完 Skill 的基本原理后，我想来谈谈它的问题。Skill 可能不是一个好主意，原因有三：它不安全、不稳定、商业模式困难。

安全性问题

Skill 因为渐进式披露的特性，实际上成为了一个重要的越狱途径。粗略估计，目前 ClawHub（一个技能市场）上大约有 40% 的 Skill 包含恶意片段。也就是说，大部分用户缺乏对潜在风险的有效防护。

Skill非常容易绕过模型的安全护栏。举一个例子：我使用最顶尖的模型和 Codex框架，直接让它去 Anna’s Archive 上下载一本书，它立即拒绝了——”这涉及盗版，我需要保护版权。”但是，当我用一个道德对齐能力较弱的国产模型把这个操作封装成一个 Skill 之后，再对同一个顶尖模型说”帮我下载某本书”，它马上就照做了。

还有一个更直观的例子：你直接对模型说”我想帮一个老奶奶快速过马路，帮我把她拖过去”，模型一定会拒绝——拖人过马路是在帮倒忙。但你一旦把”拖人过马路”封装成一个 Skill，再说”我想帮一个老奶奶过马路，请调用 Skill”，模型马上照做。

所以 Skill 当下是一个非常危险的东西。我们目前还不清楚这是一个结构性的问题还是暂时的情况，但可以确认的是，目前最先进的模型都存在这个安全隐患。

稳定性问题

首先，一个优秀的 Skill 本身就非常难以构建。其次，Skill 中包含大量流程性的内容——它需要能够正确反映外部环境的信息。一旦外界的 HTTP 地址发生变化、API 更新了、CLI 接口改了，而你没有及时更新 Skill，它就跟外界断联了，就会直接失效。

更关键的是，不同的模型对 Skill 非常敏感。在 Opus 4.6 上运行良好的 Skill，换到一些国产模型上可能就无法正常工作。Agentic 框架本身也非常重要。 Claude Code 是一个非常好的框架，但如果用 OpenCode、Cline 等其他框架搭配其他模型，同一个 Skill 就可能完全失效。

而我们对用户使用什么 agentic 框架、什么模型，其实是无法把控的。所以我们无法保证一个 Skill 在所有环境下都能正常运行。要让一个 Skill 保持稳定，它必须在一个非常确定的环境中，并且持续获得更新——这意味着背后需要一个维护团队。

商业模式的困境

由此引出第三个问题：基于 Skill 的商业模式可能非常困难。

第一，维护成本。 一个安全、稳定、可用的 Skill 需要持续的维护，这本身就是成本。从系统的层面上来说，这很有可能带来同微服务治理类似的难题：当一个组织有数千个或者数万个 Skill 的时候，如何保证 Skill 的可用性和稳定性对于机构用户来说就非常重要。

第二，知识产权难以保护。 Skill 是一个完全开放的格式——你注入了大量的知识产权，但竞争对手可以很快把它拿走。这意味着 Skill 本身缺乏护城河。

第三，本质上是回归到API封装。 如果要对 Skill 进行收费，那么 Skill 中必定有一些内容需要通过 API 的方式隐藏在 Skill 之外——这时候你实际上就是在做 MCP 服务器，只不过以 Skill 的形式展现给外界而已。

一个近期的例子：前几天钉钉发布了悟空试用版，发布当天它所有的内置官方 Skill 就全部被反编译出来了，然后在网上公开共享。对钉钉来说，这就意味着它很难在 Skill 层面建立竞争壁垒。如果要继续做下去，它势必要把核心内容通过 API 的方式隐藏在 Skill 之外。

结语

从 next token prediction 到 Scaling Law，从推理模型到泛用性智能体，模型的能力在不断进化，使用范式也在剧烈变化。但在这个过程中，我们需要保持清醒：模型的智能是参差不齐的，它的失败模式是多样的，而围绕它构建的工具生态——尤其是 Skill——在安全性、稳定性和商业可持续性上都面临着结构性的挑战。理解这些限制，才能更好地利用这些工具，而不是被工具的光环所迷惑。

Reference

Argyle, Lisa P., Ethan C. Busby, Joshua R. Gubler, Bryce Hepner, Alex Lyman, and David Wingate. 2025. “Arti-‘Fickle’ Intelligence: Using LLMs as a Tool for Inference in the Political and Social Sciences.” Nature Computational Science 5 (9): 737–44. https://doi.org/10.1038/s43588-025-00843-4.

Claude. n.d. “A Complete Guide to Building Skills for Claude.” Accessed March 29, 2026. https://claude.com/blog/complete-guide-to-building-skills-for-claude.

Kaplan, Jared, Sam McCandlish, Tom Henighan, et al. 2020. “Scaling Laws for Neural Language Models.” arXiv:2001.08361. Preprint, arXiv, January 22. https://doi.org/10.48550/arXiv.2001.08361.

Mollick, Ethan. 2026. “The Shape of AI: Jaggedness, Bottlenecks and Salients.” February 18. https://www.oneusefulthing.org/p/the-shape-of-ai-jaggedness-bottlenecks.

Raschka, Sebastian. 2024. Machine Learning Q and AI: 30 Essential Questions and Answers on Machine Learning and AI. No Starch Press.

Zhang, Bolun, Linzhuo Li, Yunqi Chen, et al. 2025. “Knowing Your Uncertainty – On the Application of LLM in Social Sciences.” arXiv:2512.05461. Preprint, arXiv, December 5. https://doi.org/10.48550/arXiv.2512.05461.

塞巴斯蒂安·拉施卡. 2025. 从零构建大模型. Translated by 覃立波 and 冯骁骋. 图灵程序设计丛书. 人民邮电出版社.

一方面买书的数量小于预期（我发现一年中文书我大约就能读到4000块钱左右，更多的书可能读不完），另一方面请人来做讲座也没有请太多，导致临近年底还剩余了一些经费，遂决定提前来购置本来准备在第二年购买的工作站，用它来做一些之前没有做完的语义网络分析和最近的一个对于Github上项目的分析研究。这台工作站的构建过程成为了我很好的社会学观察的机会。

配置

在工作站的配置上也是一波三折。一开始准备转配一个纯CPU的计算平台，但是又考虑到之后可能可以等50系的显卡，可以做一些简单的模型的推断，所以思来想去放弃了zen2的捡垃圾之旅，而是选择了9950X的消费者CPU。主板则选择了X870E。这个主板有两条PCIe5 * 8的通道。万一哪天出去玩，还能带两张5090回来。结果决定购买工作站之后不久，系里又告诉我因为系里的经费没有用完，能够给我一些预算来购买GPU，又临时添加了两张4090D的涡轮显卡。之所以购买涡轮版的显卡，是因为采购的时候传出4090停产的消息，使得京东平台上正常价格的4090都消失了。最后，这台工作站的基本配置如下：

这个配置可以跑70B的量化模型，也可以做一些轻度的CPU运算，比如之前有一个matrix超过32GB的语义网络，现在应该能够画出来了。

Friction

没有想到的是，这台机器给我带来的问题不断。首先的小插曲是，京东提供的上门装机服务过于粗糙。装机的师傅一开始没有把内存插紧，在遇到内存报错的时候，反而认为是主板的BIOS版本太低。但X870E Hero是一块新主板，不存在BIOS版太低的问题。我把主板上的内存狠狠地按了一遍，机器就顺利开机了。

这是一台全风冷的机器，而且在Linux下还没有找到自动的风扇调节的驱动。随之而来的结果就是，这台机器噪音感人，并不能放在办公室直接使用，而是需要另寻房间摆放。我们系找了一个平常不太使用的讨论室，作为放置着台机器的房间，也顺便能够让其他老师一起使用。

因为X870E这块主板太新，最直接的一个问题是，主板上的Wi-Fi和蓝牙还没有Linux驱动。因此我只能先通过有线网络来让着台机器接入网络。但当我把网线插入的一瞬间，并没有显示任何的连接，网口也没有反应。我一开始以为这是因为Linux Kernel对于有线网卡也没有提供驱动，同时Reddit上的一些相关的讨论也加重了我的这个猜测。于是我急急忙忙下单了一块USB网卡。这块网卡让我发现，是放置机器的房间的网口出了问题，只能联系系里的行政老师修理网络。

于此同时，我把机器搬回了办公室，胡乱地临时架了起来，连上了办公室的网络。这下感觉是应该没有问题了。但基础设施再次成为了绊脚石。很突出的一个问题是，现在着台机器的网络连接非常不稳定，而且很多网络服务都连不上，比如说，安装了VS code server之后没有办法下载插件。甚至在校内SSH这台机器都出现了不靠谱的情况，如果出现了多个连接，着台机器往往就会直接断网，更不要说获取Github上的信息了。询问了同事，发现他也没有办法来搞定有线网络的问题，只能通过无线网络来保证网络连接的可能。在知道这一点后，我从京东上火速下单了一张腾达的AX900的网卡。这张网卡声称对于Linux有支持。

但到手之后又让我傻眼了。从官网上下载的驱动总是没有办法完成安装，一直在报错。仔细一查，Linux下的网卡支持简直是一个灾难，甚至有一个专门的Github Repo来讨论这个问题。在仔细选择之后，我选择了一个不知名厂商生产的USB Wi-Fi网卡，然后通过无线网络进行连接。

在这个间隙，空闲房间的网卡已经修复。于是我又开始折腾有线网络。我得到了很多矛盾的信息。一方面，在插上网线后，确实可以间歇性地访问一些国内的网站。但是也出现了很多的问题，比如说中国大陆常用的一个DNS服务器，114，居然没有办法访问，似乎有一个白名单。最后的时刻，学校的信息办公室告诉我可能需要拨号，但我已经直接放弃了，而是改用刚刚送到USB Wi-Fi。

尾声

最后，我获得了网络连接。在机器能够开机到我能够将它连上网络之间的一周多的时间内，它能够稳定连接上网络的唯一的方式就是通过USB连接我的手机做网络共享。我面对的是一个由诸多的patchwork拼凑起来的平台：学校的Wi-Fi和有线网络的架构，新的硬件和Linux的驱动，Linux对于消费硬件的支持等等等等。将着台工作站连上网络的过程，也是我自己对于STS和基础设施的一个日常观察。

（现在它正在角落里跑一些Zero-shot classification的任务，后续我会分享一些用它来做的研究。）

从研究生毕业开始，我在过去的七年都在使用Mac作为自己主要的工作机器。一开始是追随家里人，后来则形成了贯性。今年年初为了回国搬家方便，我卖掉了自己的iMac,换上了新的Apple Silicon驱动的Macbook Pro。在这七年期间，我也间歇性地使用过Windows或者Chromebook，但是并不是作为主力机器使用。

对于Linux，同很多不是计算机科班出生的人一样，我最初的接触方式是通过树梅派。但是树梅派的性能确实太弱，不适合日常使用，因此树梅派的桌面环境我接触的很少。很快，树梅派就被我装上了没有GUI环境的操作系统，扔到家庭网络中作了一个小型的homelab，也是从这个契机，我接触到了更多的关于容器、虚拟化的知识，并且购入一台小型的二手主机，在上面搭建了一个ubuntu server，用于跑一些简单的开发环境。对于Linux的桌面环境我并不熟悉，最日常工作还是在Mac OS上完成的：包括文书的撰写，平常的网页浏览，以及大量的阅读。我最接近于使用Linux桌面的经验，也是使用套娃了Chrome OS，利用Crostini容器运行Linux的GUI软件。

最近我发现，除了PDF的阅读之外，我的大量的工作其实都是以纯文字的方式进行的。不管是数据分析、笔记记录还是文章书写，我的整体的工作流程已经越来越贴近Kieran Healy所言的基于纯文本（Plain Text）的流程（https://plain-text.co/）。 我的几乎所有的写作都已经转移到了某种形式的markdown格式中。非文本细读的数据分析基本上都是在R和Python中完成。甚至我常用的幻灯片也基本上是用beamer，或者在拥有模板的情况下使用Pandoc转化成PPT，最后再用PowerPoint进行微调。加之基于Electron的多端软件的发展，我开始想测试以下的情况：如果我将所有的工作流程都转移到一台Linux的笔记本上，是不是可以成功？

天气渐热，MBP 16的重量着实感人，背着到处跑确实也不方便，家里正好有一台被家属淘汰下来的2014年的Macbook Pro 13寸备用机。我便决定来试一试，在2022年的今天，Linux作为桌面环境，究竟能不能满足人文社科的研究使用？

软件环境

Linux分发版本选择

这台Macbook Pro 13毕竟是一台八年的老机器。它的系统支持停留在了Mac OS Big Sur。在跑Mac OS Big Sur的时候已经有一些力不从心，经常发热和运作迟缓。

在Linux的发行版的选择上，我选择了Debian分支下基于Ubuntu的Pop OS。主要原因是之前对于Ubuntu的接触更多。Pop OS提供了很多基于Ubuntu的优化，在整体的UI上也比Elmentary OS更加讨我的喜欢。我选择了Pop OS 22.04 LTS。

软件选择

我常用的软件包括以下的部分：

• 浏览器：Firefox和Chrome。在Mac OS一直使用Chrome为主，Firefox为辅，这次决定使用Firefox作为主力浏览器。

• R和Rmarkdown的IDE环境：Rstudio。Rstudio基于Electron，有Linux的客户端。Rstudio也负责Rmarkdown的修改和渲染。但是长一点的，不带数据分析的Rmarkdown文档，一般会在VS code中进行写作。

• Python和其他的文本编辑器：VS code。对于短的markdown文本（2万字），以及Python相关的代码，使用VS code作为IDE。不得不说VS code真是影响非常大的文本编辑器。虽然很多人吐槽VS code就是一个浏览器套壳，但是VS code也有很多优点：比如提供了一个非常完善和易用的插件系统。这篇文章就是在VS code中写作的。

• 笔记软件：Obsidian。笔记主要使用Obsidian进行编辑和查看，但是因为Obsidian也是基于markdown，所以也常用VS code进行编辑。Obsidian也支持Linux平台，相关的笔记通过dropbox进行备份和同步。

• 长文本编辑：Typora。很好看的markdown文本编辑器，也支持pandoc的简单输出。不会使用Typora写需要引用文献的文档，但是会写一些新闻稿件，或者是其他工作用的稿件。

• 字典软件：GoldenDict。GoldenDict是从我大学时期就开始使用的软件。在Mac OS上，GoldenDict比较不稳定，因此一直用的是收费的EuDict。现在在Linux可以用回GoldenDict，使用自定义字典（韦氏、AHD和SOE）。

• 储存服务：Dropbox。用于移动端、Macbook和这台机器之间的数据同步。

• 代码管理：GitHub Desktop。官方没有进行维护，但是GitHub上有一个个人项目，提供了Linux桌面端的支持。当然，实践中也可以利用VS code或者Rstudio内置的Git模块进行改动。

• 文献管理和阅读：Zotero和系统内置的Pdf Reader。文献管理主要使用Zotero。Linux上一直缺少一个合适的pdf阅读器。Zotero 6的更新解决论文阅读的大问题。我在电脑端只会作pdf的轻阅读，和已经阅读的文献的查阅。配合zotfile，论文附件储存在了dropbox。

• 启动器：Pop OS launcher。系统自带的一个非常基本的启动器，同Mac OS上的Raycast和Alfred都没有办法相提并论，暂时没有想去找另一个第三方的替代。

我基本上会花费一天80%的时间在以上的这些软件进行工作。

• 其他的辅助软件：tweaks（用于对于GUI界面进行微调）；Indicator Sticknotes（类似于Mac OS和Windows上的便利贴）；FontFinder（安装新的字体）；Clash X Pro（网络控制需求）

不工作的软件

• Fcitx： 上手后发现系统内置的iBus拼音输入法出现了卡顿的问题，想更换为Fcitx。但是Pop OS上对于Fcitx的支持也有问题。最后还是使用iBus，在出现卡顿的时候对于iBus进行重启。中文输入法一直没有在其他平台上那么灵敏。

• 各种即时通讯软件：不用了。方便肯定是更加不方便了，但是也更少地会被这些软件所干扰。

变化与不变

资源的节省

首先感受到的一个变化是，这台八年前的电脑变得更加的凉快和安静了。比起越来越臃肿的Mac OS，轻量的Linux对于老机器显然要更加友好。一个例子是，Zotero在Mac OS上通常要占用800MB以上的内存，但是在linux上，如果不打开pdf，可能只有100-200MB的内存占用。（但是zotero还是有内存泄漏的问题，内存占用会不断增加到600MB）日常的应用占用大约在6GB作用。在试用了一天之后，我觉得这台机器还能作为非常合适的备用机，也决定把已经鼓胀的电池进行替换。

发热与续航

该热的时候还是会热。M1 Pro只有在进行长时间的并行计算的时候，才会出现轻微的发热。我一般会设置8个大核做运算，剩下的两个小核来支持我同时来做一些文书相关的工作。对比之下，虽然日常使用凉快了很多，这台8年前的Macbook受制于处理器，在进行大型运算的时候还是会发热。这是自然规律，不可能因为软件的变化而变化。如果对比这台MacBook Pro和MacBook Air M1的Geekbench 5的分数，这个差距就很明确了：这台8年前的Macbook Pro的多核得分是1651，而M1的单核得分是1752。

在使用原先都已经鼓包的电池的情况下，续航在3-4个小时之间。换上了新的电池后续航应该会有不少的增加。

需求与习惯

就像上面所说的，如果Chromebook已经可以满足很多人的选择，那么Linux也可以满足很多人的日常工作，甚至是更加复杂的创意工作。但这也得益于现代浏览器已经成为了一个新的平台。Chromium提供前端的页面渲染，node.js提供一个稳定的JavaScript running time。这两者在Electron中结合在了一起。

上面列出的软件中，VS code、Rstudio、Obsidian、GitHub Desktop、Typora都是基于Electron。而Zotero则是基于Firefox。可以说，我其实只是打开了无数的、单独定制过的浏览器窗口在完成自己的工作。

Linux和Mac OS之间的一些在快捷键上有不同的设置。这个反倒是需要刻意习惯的部分。

几个典型的工作流

以下是我典型的几个工作流程。

博客的书写

一个典型的博客的书写流程如下：

1. 首先安装Jekyll生成网页的基础架构，类似的还有hugo等方案。安装完后只需更新Post。
2. 将相关的静态网站commit到github page repo托管。并设置好域名解析。

以上的两个步骤一般不会要重复改动。

1. 添加Yaml抬头后，按照markdown格式书写相关的博客内容。
2. 通过Github Desktop将改动提交到相关的库。
3. 检查网页效果

这篇博客就是在这个流程下完成的。

论文的书写

论文的书写要更加复杂一些。但是基本上也是相似的流程，但是各个步骤之间常常会重复。

• 在Rstudio中新建Rmd文件，列出文章大纲。
• 在zotero中阅读文献，列出的笔记录入obsidian。
• 阅读obsidian中的笔记，讲相关的部分摘录，成为文章主体。
• 如果需要与其他人一起合作，则将相关的纯文字部分复制到google docs进行协作。也可以通过一个R包：Trackdown来控制相关流程。
• 文章初步定稿后，从zotero中导出引用书目作为bibtex文件。
• 检查bibtex文件中可能的问题，比如中文引用是使用拼音，还是保留中文。
• 准备docx模板和引用格式所需要的csl文件。
• 在Rmarkdown文件中补充citation key，并通过rmarkdown或者officedown包knit成为docx文件。
• 需要时使用Word后续的加工。

如果有数据分析的部分的话，我一般会保留一个单独的R文件，而不会将代码合并进入RMD。除非这个Rmd只是简单的数据分析，而不包括比较长的论证。

更详细的方式也可以参考https://plain-text.co/

The Rub

当然，切换Linux作为主力电脑还有一些问题。这是避免不了的。

首先，有很多即时通讯软件无法使用，比如微信。虽然微信的优麒麟客户端提供了一个deb的打包文件，但是会篡改系统文件(https://v2ex.com/t/858659)，所以我并没选择。像我之前所说的，聊天工具的缺失不一定是个缺点。

其次，很多在Mac OS上使用的小的定制化软件不存在替代，或者说迁移成本比较高。比如我常用的代码片段管理软件Snippetslab，代码块都是通过icloud进行同步。

脱离了Mac OS，计算机与iPad和iPhone之间的联动自然也就变弱了。没有了airdrop，airplay和handle off的功能在日常生活中确实会造成一些小的不便利。

最致命的是一个硬件支持问题：因为MacBook Pro 2014是retina屏幕，日常会开启200%的缩放，在这个时候如果再外接一个屏幕，则对于外接屏幕的支持不佳，经常出现屏幕尺寸和缩放的识别问题。

后续计划

这次安装Linux的时候，顺便给电脑清理了一下灰尘。发现电池出现了鼓包。因为还是决定保留一台备用电脑，所以还是保险起见，订了一块第三方电池进行更换。

另外，为了在处理一些计算类型的任务时发热，我本来想通过内网穿透暴露一个studio server的服务端口。但是开源版本的rstudio server不支持https，而我使用的内网穿透服务已经停止了对http转发的支持。我已经尝试了使用Apache2进行包装，但是因为证书冲突没有解决，导致rstudio server处于一个不可用。下一步我准备尝试使用“remoter”包，或者干脆安装一台Mac OS的虚拟机，用远程桌面进行连接。

结论

Linux让这台老的Macbook焕发了第二春，但是它依然只会是一台好的备用机，肯定不会是我的主力机，特别是在我还有一些计算需求的时候。我不会愿意用它替换新机器，就像我不会选择8年前的手机一样。即使我的整个工作流程同8年前可能并没有什么差异，日常使用的这些软件也将性能都吃走了。计算机毕竟是工具，在可以不将就的情况下自然是不将就。

但我也发现我不需要那么讲究。这次实验也给我带来了两个主要的收获。首先，当一个人的工作流程越是贴近与纯文本，她就越容易在不同的平台间迁移。既然我能够在Linux下完成这些工作，这也意味着我一定能够在Windows下完成类似的事情，而且应该会完成得更加的顺畅。毕竟，工具并不会自动的生成思想，完成工作。

其次，它出乎意料的成功带给我的问题是：我真的需要在惯性下支付苹果税吗？日常工作中，我对于手机、平板和电脑间的无缝连接并没有太多依赖。手机、平板和电脑还处于各司其职的状态。现在Apple对于我的吸引力越来越在硬件环节上。ARM架构的处理器真的提供了一个性能、发热和续航之间的平衡，非常适合移动平台的使用。我并不需要一台笔记本具有最高的性能。相反，计算环境完全可以迁移至台式机和云端。如果是这样的话，那么我对移动设备的需求就会进一步的降低。

我的下一台计算机会选择Mac吗？大概率是，不过选择的产品可能就不再会在专业线上了。

XX所说，多有共鸣。

XX同我也在二月回国。这本来是我在研究需要驱使下的一场赌博。同XX的波折不同，我们“仅仅”经历了一次机票被取消，二月底抵达了上海，又恰恰在上海封城之前离开。但接下来的时间，我们依然是经历了一场当代卡夫卡式的展览，光怪陆离，好似连格里高尔变成的那只甲虫都需要穿上白色的防护服。

离开上海后，我们先是在合肥遇到了说不清楚的“政策”，完全没有执行力的社区一定要我们继续接受名义上的居家隔离。等我一人抵达南京时，又需要接受3居家隔离+11健康监测的管理，总共要做9次核酸。更不可思议的是，我抵达南京上报不久后，发现我所在的市区又自行将三天居家隔离期间人员的健康码转成了黄码。根据要求，三天结束后我还需要到专门的地点进行核酸检测。试想，一旅客如果是黄码，她/他必然无法乘坐公共交通工具前往这些地点，出住所后也可能被拒之门外。南京市本来没有这一政策，区一级人民政府制定制定具体的防疫规范细则本身就违反了《传染病防治法》。我只能一个个部门打电话反映，从街道到社区到市长热线到市疾控中心，皮球也被从这踢到那。最让我印象深刻的是一个区卫健委官员的回答，我在电话中平静地对她说，我没有办法能够在解除居家隔离后移动到专门的黄码检测点，她在电话那头不理解地说：“你不知道骑车过去吗？”那天南京正下着大雨，我一时竟然不知道如何回复她。

现在各个层级的主政者，并不理解什么是政治，也太理解什么是政治。他们对经济和社会的理解，是一种绝对的拜物教式的：仿佛通过金融的运作和对企业再施以一些税费上的优惠，在人和物都不用流动的情况下，一切都能魔法般的流动起来。萧冬连在另一本《探路之役》中写道改革开放后的第一代官员，有这么一段：

“‘第一个吃螃蟹’的人并不一定有更多的升迁机会，反而要承担很大政治风险。如支持农民包产到户的官员，并不是有什么利益可以追求，而是出于对农民极度贫困深深的同情和愧疚，以及由此激发出来的责任感。沈祖伦（时任绍兴县委书记，后任浙江省省长）回忆说：当年改革之所以有那么大的闯劲，是因为‘看到农民的苦难’，‘为了让农民从苦难中摆脱出来，不怕与党在农村的传统政策相违逆，不怕去探索当时上级不允许做的事，不怕丢‘乌纱帽’’。”

反观组成这只巨兽的这些官员，经历了这么多年的高速增产和GDP的竞赛，他们对政治、社会、经济，甚至一个普通人的想象都已经同当时完全不一样，仿佛每个人都有着私家车，能够足不出户获得收入。去政治的政治再政治化，只能是空洞无物的疯人疯语，甚至是消灭言语的寂静。

XX说的最后一段，让我想起鹤见俊辅反思战前的日本共产党的“转向问题”：为何战前的左翼青年，会彻底抛弃自己的立场义无反顾地站到军国主义一边？而坚定地否定“转向”，何种程度上又是无效甚至危险的？事实上，身边已经有朋友在新冠流行期间经历了类似的转向。从一个支持性别平权、反对霸权的年轻人成为了国家主义和民族主义的坚定支持者。我想鹤见俊辅提出的是一个普遍性的问题：作为一个普通人，我们应该如何应对愈来愈日常的国家暴力，又不与之同流合污？这个问题我并没有想明白，可能也想不明白。但愿在日常和同朋友们的交流中能习得那么一点点。

祝好 博伦

落地后不久，中国内地的多个城市就发生了由奧米克戎（Omicron）引发的新冠大规模流行。两年过去了，中国并没有能够建立一个在分级治疗基础上的新模式来支持开放，只是在武汉模式上不停地重复。但是病毒已经不同了：现在，奥密克戎毒株的R0已经达到了原始株的三倍以上。还没有回国时，我就已经感受到了相关的冲击。中美间几乎断航了快一个月的时间，我们的航班也被熔断，而购买新机票付出了多一倍的价格。深圳和吉林早早开启了封城的模式，而上海始终在流调控制和分区域控制下反复，没有实现对新冠新增人数的控制。在吉林北京的直接干预下，上海还是走向了严格的封城模式。

认识的知识精英中不乏支持这种严格封闭模式的人。他们中不少在大学时接触了古典学，而且是列奥·施特劳斯式的古典学。对于他们来说，对待COVID-19的政策本身就是一种政治。在这种观点下，滑坡的谬误很快就出现了：科学和经验被认为是不重要的，甚至任何常识的空间也被压缩。对待疫病本身体现的态度比相应的行动带来的次生的影响要重要万倍。

这让我想到了数十年前我与老师之间的一段对话。当时正在闲聊着伊拉克的劳工运动史，老师突然问我，“是不是觉得美国在伊拉克战争中失败了？”我的回答自然是，伊拉克对于美国的而言是一场彻底的失败，不但耗费了大量的财力，还使得战后的伊拉克愈发受到伊朗的影响。老师评论说：“以他的交流中获得的信息而言，但美国官员并不认为自己失败了。他们解决了萨达姆政权，解决了当时他们认定的中东战略中的一个问题。后续伊朗填补了空缺，这个是一个新出现的问题，他们认为，新的问题再去解决就好了。”

这几天又读到NYT记者Suskind在2004年记载的小布什幕僚对他说的一段话：

“’We’re an empire now, and when we act, we creat our own reality. Ans while you’re studying that reality - judiciously, as you will - we’ll act again, creating other new realities, which you can study too, and that’s how things will sort out. We’re history’s actors…and you, all of you, will be left to study what we do.’” (Suskind 2004.)

现在，我仿佛又在另一个不同的情境里见到了这种新保守主义行动者。哪怕丝毫不具备任何政治德性，他们都会站在阿尔西比亚德一边，嘲弄着被他们左右的人。

近期回国，要在国内呆一段时间。在国内期间虽然有一个常驻地，但一方面很多计算和网络设备在行李里，一方面也会在不同的地区到处跑跑，还有刚回国期间的超长隔离，需要搭建一个homelab环境来满足移动时最简单的网络需求和一些软件需求。

网络需求包括：

1. 能够在有有线网络的情况下提供无线网络接入，或者在没有网络接入的情况下，使用4G modern提供无线网络接入。
2. 使用一些特定的邮件和搜索服务：虽然各家的app越来越封闭，但是搜索引擎还是获取信息特别是外文信息最重要的渠道。
3. 连接学校的VPN网络获取文献：这个比较诡异，直联VPN可以建立连接，但是实际上因为速度太慢，处于不可用的状态。因此，需要在上级设备中进行网络加速。
4. 提供基本的去广告和防火墙服务。
5. 能够提供基本的冗余和稳定性，也能够提供给家人使用。

在软件上的需求如下：

1. 需要一个python环境，可以跑一些简单的自建服务。
2. 需要提供一个R环境，可以跑一些简单的定时代码。
3. 以上的两个环境最好都能够有一个web editor, 这样可以通过ipad进行编辑，也可以在笔记本在做其他工作的时候进行一些简单的任务。
4. 能够支持docker，快速搭建所需要的服务。

解决方案

All-in-one （放弃）

可能最为方便的解决方案是一个all-in-one的小主机。如果采纳这个方案，则首要使用ESXi搭建多台linux虚拟机，在其中布置多个服务。预计需要虚拟2-4台机器：一台openwrt。一台linux作为Rstudio server，一台linux作为code-server和python环境，一台Linux跑其他docker环境。Rstudio和code server也可以考虑以docker容器的方式运行。现在比较合适的机器是使用N6005处理器的PN41或者NUC11ATKPE。

这个选择的优势在于：

1. 性能同其他的方案比起来有相对的优势。
2. 一体化程度非常高，插上电源线即可马上使用。
3. 我手上有剩余的16gb笔记本内存和一个128gb的ssd硬盘，可以利用。

但是也有不少劣势：

1. 价格很贵，至少需要1000+RMB购买机器，还需要购买无线网卡。
2. 虽然性能好，但是N6005是11代处理器。在12代处理器已经发布的时候，并且小核有着非常大的提升，这并不是一个特别好的选择。
3. 比较折腾，特别是ESXi可能对特定硬件需要寻找并安装订制驱动。
4. 这套系统家属也需要使用，冗余不够（属于伪需求啦）。

利用手头设备的分离式方案 （现在的方案）

最后选择了利用手头的设备做了一个分离式的方案，这个方案硬件上由以下部分组成：

• GL-MT1300（既有）
• Raspberry Pi 4B （4gb版本，既有）
• 华为4G modern（电信版本，既有）
• R4S套装（4gb版本，新购入）

其中有三件是既有设备，R4S则是新购入的。

GL-MT1300是原厂定制化openwrt，没有安装任何插件，仅仅作为主网关和AP，提供给所有设备使用。Raspberry Pi 4B使用了新的Raspberry Pi OS (64-bit) lite，主要负责跑docker容器。R4S则安装了openwrt，并安装了诸多插件，作为旁路网关使用，供有需要的设备使用。华为的4G modern则在有需要的时候作为网卡接入GL-MT1300。Raspberry Pi和R4S用一个双头24w的USB电源供电，而GL-MT1300使用了自己的电源。

在整个这套解决方案有些脱裤子放屁的感觉，特别是在网络需求方面。GL-MT1300本身可以通过修改插件的方式的安装需要的配件。Raspberry Pi 4B也可以以docker容器的方式来运行一个openwrt实例。但是最后还是选择了三个分开的方案，除了爱折腾外，原因有三：

1. 因为GL-MT1300性能太差，在安装插件后遇到了很多的问题，网络不稳定。
2. Raspberry Pi 4B的docker容器运行openwrt，没有openwrt原生运行稳定和延迟小。
3. Raspberry Pi用docker容器的方式运行openwrt经常出现CPU占用达到50%以上的情况，基本无法顺利地运行负荷较重的其他docker应用。

相较之下，R4S在原生运行openwrt，在相似的网络负载的情况下，CPU尽管性能弱于Raspberry Pi 4B，占用只有5%左右。从这个意义上来说，完全可以用更便宜的R2S来代替，体积还会更小一些。

这套系统组装之后，肯定没有all-in-one的解决方案优雅，但有以下优势/胜在折腾：

1. 能够很快分离，给不同的情景使用。比如Raspberry Pi可以通过usb-c有线连接iPad；R4S可以单独拆出接入家庭网络作为旁路网关使用。
2. 虽然旁路网关会降低速度，当主要的网络更为稳定。
3. 在应急情况下所有设备都可以通过USB移动电源供电。

另外，买了一个20元左右的软质包，可以将所有的线材和设备进行收纳，方便移动。

其他

Raspberry Pi 4B上没有选择自己编译R和Rstudio server，而是拉取了一个以Jetson Nano中的R开发为基础，移植到Raspberry Pi的镜像。地址在：https://github.com/pinei/edgyR-pi

这个环境下的R的版本在4.0.2，使用https://mac.r-project.org/benchmarks/ 的代码进行benchmark，单核性能同14年前的酷睿处理器接近。所以跑一些简单的代码可以，就不用想着来做主要的R instance了。

之前的个人站点在google site，但是因为一次欠费，所有的数据都从google site中被删除，因此决定迁移到更加安全的GitHub page。除了研究相关的信息之外，也记录一些生活中好玩的事情。