When I awoke, the snow was already gone.

This was the one hundred thousand and thirty-second year I had spent in cryogenic suspension. The hatch opened without a sound, as though reluctant to disturb something long at rest. The air was warm and moist, free of disinfectant or metallic odor, and for a moment I was seized by a strange illusion—that I had merely slept through an ordinary night.

The person who came to receive me stood outside the chamber. Her appearance differed almost not at all from the people of my own era—limbs, features, skin, even the familiar curvature of a smile. And yet the smile showed no emotional modulation, like the surface of a perfectly still lake.

“Welcome back,” she said. “You have rested long enough.”

I had expected a future beyond recognition: alien cities, unfamiliar forms of life, humanity rewritten beyond recall. But nothing seemed changed. Streets were still streets. The sky remained blue. The Sun rose along its ancient orbit.

现在如果你不计较为LLM API付费，那么理论上今天所有新的软件服务需求可以使用一个通用的agent service来实现。 你可以如常定义所有功能API，后台由一个LLM驱动的智能体接受用户发送来的数据，然后由他决定做出什么样的合理响应。 好比放一个人蹲守在自动售货机的里面，他检查用户的按键和投币，然后把对应商品塞到出口。 除了慢一点，贵一点，完全可行是不是？

你说不对呀，现在的 Agent 还有很多事做不好，不堪大用啊？ 没关系，咱们 Agent 会写代码，只要是你传统软件能做到的事，我 Agent 都能开发出来，大不了我现场开发一个呗。 当然了，现实中如果真的这么做可能会慢到不可忍受，不过这给我们提供了软件开发范式的一种新思路。

1. 从通用智能体开始

首先，我们搭建一个基础的 Agent 脚手架，并赋予它一套基础的通用工具，比如shell命令执行器（咦？好像一个就够了）。 这就像给一个智能体配备了万能工具箱，让它能够在各种需求下先跑起来。

2. 通过持续互动，让智能体“长出”专用能力

之后，我们通过需求驱动与 Agent 反复互动，让它尝试实现各种功能。 在这个过程中，你会自然观察到哪些操作被频繁调用、重复性高、对系统至关重要。 于是，你可以从这些“使用痕迹”中抽象出更稳固的专用模块，让 Agent 使用更高效的版本。

3. 开发是一种从“液态”到“固态”的固化过程

整个模式可以理解为一种演化：

• 一开始，工具与逻辑是灵活的、临时的，液态的。
• 随着需求稳定，你将关键逻辑固化成结构化、可复用的模块，“凝固”为固态。
• 最终，Agent 的工具变得越来越鲁棒且高效，而 Agent 则站在这个不断进化的基础设施之上继续工作。

既然我们未来大概率也要往系统中塞进一个 Agent 与用户交互（越来越多的App已经在这样做了）， 不如转而以智能体协作为核心，通过对话与反馈循环，让系统逐步自我沉淀与强化。

整个世界的运转居然是由一个孤独的老人独立维持的，而老人没有任何魔法，只有卓越的技艺。 但是老人已经很老了（就像执剑人罗辑？），他需要给自己寻找一个接班人。 其实，如果有一天整个世界都随他而去，又何尝不是一种解脱？但是也许这世界上还有他爱的人吧。 好在他还有筹码，他是世界上唯一能修星星的人。 天上一颗星，地上一个人。星星出了毛病，地上那个人也会生病。 当人们求老人帮他们修理星星救命的时候，老人会提出他唯一的要求，接自己的班。 然而这份苦差事哪有人愿意接？直到一个小男孩的到来……

《烧火工》是刘慈欣比较冷门的一个作品，也是除了《死神永生》中的三个童话故事之外，唯一的童话故事作品。 虽说是童话，但这个故事更多是写给成人看的。 至少在我看来，其语言的复杂度和过多的技术细节会劝退绝大多数小读者（以及小听众）。 然而这一点也不妨碍《烧火工》是一篇佳作，只要稍加改造，还是能成为一个真正的“童”话。 毕竟能把对童话（以及科学幻想）的好奇心保持到成年的人还是少数，童话主要还是讲给孩子听的。

这就是我把《烧火工》改编成儿童绘本的主要动机。 整个绘本算上封面封底一共36张图画，像个动画片分镜头脚本一样。 受限于目前技术水平，图画之间的角色一致性方面还有很大问题，敬请见谅。 因此也仅作为个人业余爱好之作，没有任何商业企图。

^{[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15]}

距离上一篇打造音乐创作AI（一）已经过去一年多了， 一直忙于工作和家庭，音乐算法研究进展甚微。 最近看到了NotaGen^[15:1]的发表，堪称符号算法作曲领域的里程碑式工作。 不得不承认，自己还在半山腰磨蹭，别人已经把旗子插上山顶了。 索性第二篇就介绍一下NotaGen，自己这边的思路以后再整理吧。

这篇由中央音乐学院与多所大学联合团队发表的工作，无论从算法路线和数据来源都做得非常完备。 不仅发表了论文，也开放了源代码和Demo。 当然最宝贵的数据集并没有放出（可能是考虑版权问题）。

除了官方Demo，这里给出一些我自己使用NotaGen生成的键盘作品（曲谱图片可点开大图）：

依据paper和源代码这些可观察到的内容，以下从三个要点来简要介绍一下NotaGen的工作。

众所周知，写博客或日记有两种方式，一种是使用Web2.0时代的UGC平台网站（如豆瓣、新浪博客等），另一种是自己搭建个人网站。 第一种选择门槛低，可以立即开始写作，但缺点是无法控制所有细节，对富文本格式（尤其是程序员喜欢的Markdown）支持有限。 第二种选择，如Hexo，则需要折腾一些代码，配置大量细节选项，写博客如同开发一个小型项目。如果只是作为个人备忘性质的日志，就过于繁琐了。

本文提供了一种新的折衷思路，即直接把Github当作UGC平台，兼取两者优点，可谓懒人良方。

本篇是笔者多年前刚刚接触深度学习时的一些思考，最近才抽空整理出来， 顺便也引用了一些近年新出现的网络结构作为例子。 希望能给同行带来一些有益的启发。

早些年读深度学习论文的时候经常有一种感觉，作者已经在深入描述网络结构的细节，但笔者自己连其应用环境的大致图景还没有清晰概念。 固然有对其前置工作了解不足的因素，但笔者认为还有一个重要原因是深度学习领域还缺少一种成熟的建模图示标准，类似UML。 一个统一直观的图示系统应该有力地体现出神经网络的一些通用的基本要素，并对建模问题分析有辅助作用。 本文可以视为笔者针对有向图模型通用图示的一个尝试性的提议。

首先我们尝试从一个简单模型结构入手。

简单分类模型

考虑一个拍照识物应用^[1]，我们可以将其建模为一个简单的分类模型， 用数学语言描述，我们的目标是想获得这样一个函数：

$$ y’=f_\theta(x) $$

其中x代表输入的图像，y’是模型输出的类别概率向量。 函数f是我们建模的一套计算图（譬如CNN网络），其下标θ代表模型权重，可以理解为计算图中待填入的知识。 下文中笔者将计算图函数均写作二元函数，即接受权重和输入数据两个参数。

模型的训练是一个数值优化问题，通常记作如下表达式的求解：

$$ \arg \min_\theta { \mathbb{E}_{(x,y)\sim (X,Y)} [l(f(\theta, x), y)] } $$

其中(X, Y)是一个有标注数据集，即特征-标签（图像-类别）集合。 小写的x,y是来自数据集中的 (特征, 标签) 采样。 $l$是损失函数，是某种度量模型输出值与标签的距离的函数，针对不同模态的数据可以有不同的选择。 argmin代表求解某个θ的取值，使得右侧的期望表达式达成最小化。

数学表达式晦涩难读，但却是理解很多论文的最佳途径，因为其精确给出了问题的全景。 有没有更直观的表达方式？针对上式笔者脑补了如下的图形：

其中竖着写的~是数学中的服从分布符号，可以理解为从数据集（或某种先验分布）中采集一个样本。

f上的*代表其中具有可训练参数^[2]，即权重θ。 这里其实笔者可以使用颜色来标注，但为了与平时在草纸上手写时的记号习惯保持一致，仍保留了星号。

圆圈中的ce即损失函数$l$，这里采用分类任务常用的交叉熵(Cross Entropy)。

loss左侧的尖朝下三角形▽代表优化目标^[2:1]为最小化loss的值。

整个计算图的方向为由上至下，与很多paper作者采纳的习惯相反。 这是出于以下考虑：数据是绝大多数深度学习任务的基础，因此分析建模问题时我们可以先列出可资利用的各种数据资源。 （按自然的方式）在草稿上把所有数据项列在最上一行，然后从上至下画出可能的模型结构。

关于模块的形状，笔者考虑把数值模块和纯解析模块区分开来，纯解析模块用圆圈表示，提示其中不含权重（不论是当前训练中的还是来自预训练）。 在笔者想象中，纯解析计算像是一种柏拉图实在（不似尘世之物），而数据集和权重则来自物理实在，充满各种细节和随机性。

如果是由我们自己来搭建一个针对某个任务的模型计算图，我们只要掌握其中的要点就可以确保做出一个实际可行的方案。^[3] 为了看出这其中的要点在哪里（同时也为了不失一般性），下面笔者简化了刚才的数学表达式。 由于X, Y都是数据，可以合并为一个符号X来表示；而$f$, $l$都是计算图中的函数，可以合并为函数$g$，于是上式改写成：

$$ \arg \min_\theta { \mathbb{E}_{x\sim X} [ g(\theta, x) ] } $$

我们把右侧的期望表达式记为优化目标A：

$$ A = \mathbb{E}_{x\sim X} [ g(\theta, x) ] $$

刚才说了，模型训练是一个数值优化过程。 具体说是把计算图中每个环节对训练权重θ求导，然后反向传播梯度，这个过程可以（略为粗糙地）记作下式：

$$ \theta \gets \theta - \gamma \cdot \frac{\mathrm{d} }{\mathrm{d} \theta} A $$

其中$\gamma$是学习率，对我们的讨论不重要。

这里$g$就是我们想要搭建的计算图，它的组成部分我们暂时可以当作黑箱。 现在我们可以看出，约束计算图g的三个要素是数据集X、训练权重θ和优化目标A。 这是因为X和θ都是$g$的参数，而A决定了θ怎样得到更新。

这里还有一个重要的观察是，虽然计算图是从上至下的，但优化过程里只有θ是变量，所以信息的流动方向其实是从X流向θ。 因此，有向图模型的范式可以概括为：凭借目标A，信息由数据X注入权重θ，以此获得智能。 这里的“智能”指的是某种信息编码/解码能力，类似于人类处理问题的快速反应能力，或者叫直觉。

以下我们使用三要素分析方法，来考察一下各种常见的有向图模型结构。 这里我们仍把计算图中各模块的细节当作黑箱，只关注大框架上各种模型与数据之间的作用方式。

以本篇作为起始，计划写一个算法作曲相关的系列，记录一些音乐算法研发中的想法。

起源

2018年Google发布的Music Transformer是算法作曲中具有里程碑意义的工作。 它证明了自回归模型在音乐领域中的巨大潜力。 其中一个值得重视的基础性工作在其paper附录中，关于如何把MIDI格式编码成易于自回归模型训练的token序列。

后来在笔者的OMR项目上线完成后（OMR项目的心得笔者将另开系列分享）， 笔者发现借助OMR技术的能力，完全可以另辟蹊径，尝试开发一套基于五线谱的音乐生成模型。 相对MIDI来说，由于直接来自于作曲家，五线谱的符号系统更接近自然语言。 从信息科学角度来说，其编码形式的信息熵密度更大，这是有利于机器学习的。 当然缺点也很明显，作为音乐格式，五线谱不像MIDI可以直接播放成声音，阅读门槛较高。 不过这个可以靠开发曲谱演奏模型来弥补。 而反过来，由于五线谱易于表达音乐构思和指导演奏，把音频和MIDI转成曲谱（即扒谱）也是一个很有价值的方向。 无论如何，开发一个可以写作曲谱的AI agent的想法总是很诱人的。