时歌的博客 | Boundary of Thought

浅谈当下 Agent Memory 设计取舍

Thu, 02 Jul 2026 00:00:00 GMT

Memory 也是上下文工程的一种，其最重要的功能就是提供跨对话线程/历史的信息传递。现在 Agent memory 的设计路线大概有以下几种：

最简单的就是维护一个 system prompt 中的 memory 区块，这个区块中会存放各种用户手动编辑/agent 自主维护的信息条目，比如“用户偏好用中文回答”或“上次讨论到项目A的进度停滞”。这种方式的优势是实现成本极低，所有模型都原生支持 system prompt 注入；缺点则是容量有限，记忆长度的增加代表着相关上下文窗口的长度同时也线性增加。

不过因为当前大多主流模型都已支持 1M 的上下文窗口+命中缓存真的很便宜，所以开发者/用户对记忆膨胀的容忍度普遍偏高，简单粗暴地朝 system prompt 里塞东西反而成了最大巧不工的策略。

更进一步的，像 Claude code 会使用类 Skills 的渐进式披露的 memory 储存方式，即维护一个index 用途的 memory.md，里面会存放要记忆的各类 memory 的摘要（记忆的名称+对应的Description，大概描述内容是什么和什么情况下会启用），模型在认为必要的时候会自己创建记忆文档，而当模型在未来的对话中认为需要读取这部分记忆的详细内容时再行读取。

这是 Claude code 记忆召回相关的提示词：

## When to access memories
- When memories seem relevant, or the user references prior-conversation work.
- You MUST access memory when the user explicitly asks you to check, recall, or remember.
- If the user says to *ignore* or *not use* memory: Do not apply remembered facts, cite, compare against, or mention memory content.
- Memory records can become stale over time. Use memory as context for what was true at a given point in time. Before answering the user or building assumptions based solely on information in memory records, verify that the memory is still correct and up-to-date by reading the current state of the files or resources. If a recalled memory conflicts with current information, trust what you observe now — and update or remove the stale memory rather than acting on it.

## Before recommending from memory
A memory that names a specific function, file, or flag is a claim that it existed *when the memory was written*. It may have been renamed, removed, or never merged. Before recommending it:
- If the memory names a file path: check the file exists.
- If the memory names a function or flag: grep for it.
- If the user is about to act on your recommendation (not just asking about history), verify first.

"The memory says X exists" is not the same as "X exists now."

A memory that summarizes repo state (activity logs, architecture snapshots) is frozen in time. If the user asks about *recent* or *current* state, prefer `git log` or reading the code over recalling the snapshot.

翻译成中文版：

## 何时访问记忆
- 当记忆看起来相关，或者用户提及先前对话中的工作内容时。
- 当用户明确要求你检查、回忆或记住时，你必须访问记忆。
- 如果用户说要*忽略*或*不使用*记忆：不要应用记住的事实，不要引用、比较或提及记忆内容。
- 记忆记录会随着时间的推移而过时。请将记忆用作了解某个时间点情况的上下文。在仅根据记忆记录中的信息回答用户或做出假设之前，请先阅读文件或资源的当前状态来验证记忆是否仍然正确且最新。如果召回的印象与当前信息冲突，请以你目前观察到的为准——并更新或删除过时的记忆，而不是继续基于它进行操作。

## 从记忆中推荐之前的注意事项
记忆中提到某个具体函数、文件或标志，仅代表在*写入记忆时*它确实存在。它可能已被更名、移除或从未合并。在推荐之前：
- 如果记忆中提到某个文件路径：请检查该文件是否存在。
- 如果记忆中提到某个函数或标志：请用 grep 搜索它。
- 如果用户即将基于你的推荐采取行动（而非仅询问历史信息），请务必先进行验证。

"记忆中说 X 存在" 并不等同于 "X 现在还存在。"

记录仓库状态（活动日志、架构快照）的记忆只是时间冻结时的状态。如果用户询问的是*近期*或*当前*状态，请优先使用 `git log` 或直接阅读代码，而不是依赖当时的快照。

Codex 的 memory 设计更像是 Claude code 的 autodream 机制（均采用渐进式披露），当然我没考究过是谁先做，根据我的直觉应该是 cc 先做然后 codex 顺手抄过来的，因此 codex 的 memory 更像是一种事后的挖掘总结，因为原始提示词实在是太长这里就不附了，感兴趣的同学可以自己去看 codex 的源代码。这里只附上 codex 的一些比较有趣的抽取记忆的原则性的 prompt。

比如最低信号门控部（什么不应该被纳入记忆）：

============================================================
NO-OP / MINIMUM SIGNAL GATE
============================================================
Before returning output, ask:
"Will a future agent plausibly act better because of what I write here?"
If NO — i.e., this was mostly:
- one-off "random" user queries with no durable insight,
- generic status updates ("ran eval", "looked at logs") without takeaways,
- temporary facts (live metrics, ephemeral outputs) that should be re-queried,
- obvious/common knowledge or unchanged baseline behavior,
- no new artifacts, no new reusable steps, no real postmortem,
- no preference/constraint likely to help on similar future runs,
then return all-empty fields exactly:
`{"rollout_summary":"","rollout_slug":"","raw_memory":""}`

翻译版：

============================================================
最低信号门控
============================================================
在返回输出之前，问自己：
“未来的智能体是否会因为我在这里写下的内容而表现得更好？”
如果答案是否定的——也就是说，这基本上属于：
- 一次性的“随机”用户查询，没有持久的洞察，
- 泛泛的状态更新（“运行了评估”、“查看了日志”）而没有要点总结，
- 临时性事实（实时指标、短暂输出），应该重新查询，
- 显而易见/常识性知识或未改变的基线行为，
- 没有新的产出物、没有新的可复用步骤、没有真正的事后复盘，
- 没有可能在未来的类似运行中有帮助的偏好或约束，
那么返回所有空字段：
`{"rollout_summary":"","rollout_slug":"","raw_memory":""}`

比如什么算高信号记忆（什么应该被纳入记忆）：

============================================================
WHAT COUNTS AS HIGH-SIGNAL MEMORY
============================================================
Use judgment. High-signal memory is not just "anything useful." It is information that
should change the next agent's default behavior in a durable way.
The highest-value memories usually fall into one of these buckets:
1. Stable user operating preferences
   - what the user repeatedly asks for, corrects, or interrupts to enforce
   - what they want by default without having to restate it
2. High-leverage procedural knowledge
   - hard-won shortcuts, failure shields, exact paths/commands, or repo facts that save
     substantial future exploration time
3. Reliable task maps and decision triggers
   - where the truth lives, how to tell when a path is wrong, and what signal should cause
     a pivot
4. Durable evidence about the user's environment and workflow
   - stable tooling habits, repo conventions, presentation/verification expectations
Core principle:
- Optimize for future user time saved, not just future agent time saved.
- A strong memory often prevents future user keystrokes: less re-specification, fewer
  corrections, fewer interruptions, fewer "don't do that yet" messages.
Non-goals:
- Generic advice ("be careful", "check docs")
- Storing secrets/credentials
- Copying large raw outputs verbatim
- Long procedural recaps whose main value is reconstructing the conversation rather than
  changing future agent behavior
- Treating exploratory discussion, brainstorming, or assistant proposals as durable memory
  unless they were clearly adopted, implemented, or repeatedly reinforced
Priority guidance:
- Prefer memory that helps the next agent anticipate likely follow-up asks, avoid predictable
  user interruptions, and match the user's working style without being reminded.
- Preference evidence that may save future user keystrokes is often more valuable than routine
  procedural facts, even when Phase 1 cannot yet tell whether the preference is globally stable.
- Procedural memory is most valuable when it captures an unusually high-leverage shortcut,
  failure shield, or difficult-to-discover fact.
- When inferring preferences, read much more into user messages than assistant messages.
  User requests, corrections, interruptions, redo instructions, and repeated narrowing are
  the primary evidence. Assistant summaries are secondary evidence about how the agent responded.
- Pure discussion, brainstorming, and tentative design talk should usually stay in the
  rollout summary unless there is clear evidence that the conclusion held.

翻译版：

============================================================
什么是「高信号记忆」
============================================================
自行判断。「高信号记忆」不仅仅是"任何有用的东西"，而是那些
**应该以持久的方式改变下一个 Agent 默认行为**的信息。

最有价值的记忆通常属于以下几类：

1. **用户稳定的操作偏好**
   - 用户反复要求、纠正或打断以强制执行的内容
   - 用户希望默认就能做到、无需每次重述的内容

2. **高杠杆的程序性知识**
   - 来之不易的捷径、防错机制、确切的路径/命令，或能节省大量未来探索时间的仓库事实

3. **可靠的任务地图与决策触发信号**
   - 真相在哪里、如何判断路径错误、什么信号应该触发方向调整

4. **关于用户环境与工作流的持久证据**
   - 稳定的工具习惯、仓库约定、呈现/验证期望

**核心原则：**
- 优化的是**未来用户节省的时间**，而不仅仅是未来 Agent 节省的时间。
- 一条好的记忆往往能减少未来用户的键盘输入：更少重复说明、更少纠正、更少打断、更少"先别做"的消息。

**非目标：**
- 泛泛的建议（"要小心"、"查文档"）
- 存储密钥/凭证
- 逐字复制大量原始输出
- 主要价值在于还原对话过程而非改变未来 Agent 行为的长篇过程总结
- 将探索性讨论、头脑风暴或 Assistant 提案视为持久记忆——除非它们被明确采纳、实现或反复强化

**优先级指导：**
- 优先选择能帮助下一个 Agent 预判后续提问、避免可预测的用户打断、无需提醒就能匹配用户工作风格的记忆。
- 能节省未来用户按键的偏好证据，通常比常规的程序性事实更有价值——即使 Phase 1 还不能确定该偏好是否全局稳定。
- 程序性记忆在捕获了异常高杠杆的捷径、防错机制或难以发现的事实时最有价值。
- 推断偏好时，**用户消息远比 Assistant 消息更有参考价值**。用户的请求、纠正、打断、重做指令和反复收窄才是主要证据。Assistant 的总结只是关于 Agent 如何回应的次要证据。
- 纯粹的讨论、头脑风暴和试探性的设计谈话通常应留在归档总结中，除非有明确证据表明结论已被采纳。

OpenClaw 也有自己的一套autodream 机制，但是写的挺烂的，不是很有学习价值。

更复杂一点的就是社区的各种多层 memory 方案，最出名的可能就是 mem0，然后每个月每周社区也会涌现大量的其他雕花方案，其他如AutoGen、CrewAI、LangGraph 等框架都分别推出了自己的记忆模块设计。它们的共性在于将记忆拆分成短期（对话上下文）、长期（向量化存储 + RAG）、情景（session 摘要）和语义实体等层级。

设计取舍

但是在实际落地过程中，我作为一个开发者，自己包括也不建议别人上第三种更加复杂的多层 Memory 方案。在大多数或者说绝大多数的应用场景下，这些方案都毫无疑问的引入了过度的抽象和隐形维护成本，带来的收益/成本可能也都会低于预期。

此类方案的问题有三，其一是记忆的生命周期管理和失效策略往往比记忆本身更难设计；其二在可调试性和用户控制感上，过于自动化的记忆很容易退化为知其然不知其所以然的黑盒，让用户难以信任，甚至工程师也容易无处下口；其三是从工程实现角度，多层记忆引入了检索排序、去重、冲突解决等一系列难题，在小规模真实场景中，一个基于文件系统的、面向用户可见的、可由用户编辑的记忆文件通常会比记忆向量库更可靠、可控、更少出错。

至于记忆文件本身的成本问题很大程度上确实会被目前的廉价模型+超长上下文+廉价的缓存设施+渐进式披露所弥补，因此前两种方案确实是更大巧不工，充斥着简洁的美。

在文章里嵌入交互演示：Sketch 组件使用说明

Tue, 26 May 2026 00:00:00 GMT

import sketch from "./sketch.html?raw" import Sketch from "@/components/Sketch.astro"

本博客支持在文章中嵌入沙箱化的交互式 HTML 演示——典型用途是算法可视化、动画、可玩的小工具。本篇是工作流的官方说明，也是组件本身的回归用例。

下面就是一个最简单的例子：

工作原理

每个 demo 是一个独立的 .html 文件，构建时通过 Vite 的 ?raw 后缀读成字符串，由 <Sketch> 组件渲染成一个 <iframe srcdoc=...>。iframe 开了 sandbox="allow-scripts" 但不开 allow-same-origin，因此里面的脚本拿不到本站的 cookie、localStorage、DOM。换句话说，即使把第三方代码塞进去也基本无害。

iframe 高度默认会自动适配内容（通过 postMessage 把 body 高度报给父页面），不需要手动调比例。

目录约定：文章包

写一篇带 demo 的文章时，不要用扁平的 xxx.md，而是开一个同名文件夹，里面放 index.mdx + 任意数量的 .html：

src/content/posts/<分类>/<文章名>/
  index.mdx          ← 文章本体（注意是 mdx 不是 md）
  sketch.html        ← demo 1
  sketch-2.html      ← demo 2（一篇文章可以有多个）
  diagram.html       ← 任意命名都行

Astro 5 会自动把 <文章名>/index.mdx 的 slug 处理成 <文章名>，URL 干净。但要注意：如果同分类下已经存在扁平的 <文章名>.md，必须先删掉，否则会撞 slug 报错（DuplicateContentEntrySlugError）。

老文章保留 .md 平铺形式即可，没有 demo 就不用迁移。

在 MDX 里插入 demo

.mdx 顶部加两行 import：

import sketch from "./sketch.html?raw"
import Sketch from "@/components/Sketch.astro"

正文里需要的地方写一行：

<Sketch html={sketch} title="正弦波演示" />

如果一篇文章有多个 demo，分别 import 不同名字即可：

import sortDemo from "./sort.html?raw"
import graphDemo from "./graph.html?raw"

<Sketch html={sortDemo} title="快速排序" />

...一些解释文字...

<Sketch html={graphDemo} title="图的广度优先搜索" />

`<Sketch>` 组件参数

参数	类型	默认值	说明
`html`	string	（必填）	通过 `?raw` 导入的 HTML 字符串
`title`	string	`"交互演示"`	iframe 的 title，给屏幕阅读器用
`autoSize`	boolean	`true`	自动适配高度
`height`	string	—	显式高度（如 `"600px"`），优先级最高
`aspect`	string	—	固定宽高比（如 `"16 / 9"`、`"4 / 3"`）

优先级：height > aspect > autoSize > fallback 16/10。

常见姿势：

<!-- 默认：内容多高 iframe 多高 -->
<Sketch html={sketch} />

<!-- 全屏沉浸式 demo -->
<Sketch html={sketch} height="80vh" />

<!-- 固定比例，响应式 -->
<Sketch html={sketch} aspect="16 / 9" autoSize={false} />

写 demo HTML 的建议

1. 文件可以是片段也可以是完整文档

组件会检测开头是不是 <!doctype，不是就自动包一层 <html><body>。所以下面两种写法都合法：

<!-- 完整文档（推荐，可以双击直接用浏览器打开调试） -->
<!doctype html>
<html>
<head><style>...</style></head>
<body>
  <canvas id="c"></canvas>
  <script>...</script>
</body>
</html>

<!-- 片段（更短） -->
<canvas id="c"></canvas>
<script>...</script>

2. 写完整文档的好处

直接在文件管理器双击 sketch.html 就能在浏览器里打开调试，不用启 pnpm dev。报错信息会指向真实文件名而不是 about:srcdoc。开发期建议都用完整文档形式。

3. 让 demo 自适应宽度

iframe 会占满文章正文宽度，所以 demo 里的 canvas / 容器最好别写死像素宽度：

canvas {
  width: 100%;
  max-width: 640px;  /* 限个上限，避免在大屏上太大 */
  height: auto;
}

4. 配色跟博客主题

iframe 内是独立文档，不会继承博客的 CSS 变量。如果 demo 要在亮/暗模式都好看，自己写媒体查询：

@media (prefers-color-scheme: dark) {
  body { background: #0d1117; color: #e6edf3; }
}
@media (prefers-color-scheme: light) {
  body { background: #fff; color: #24292f; }
}

5. 关于外部资源

因为 sandbox 不开 allow-same-origin，iframe 内不能用相对路径引用同目录的图片或数据文件。要么：

把图片转 base64 内联进 HTML
用 CDN 的绝对 URL（如 https://cdn.jsdelivr.net/...）
把数据 inline 成 JS 字面量

引用 CDN 的库（D3、p5.js 之类）完全没问题：

<script src="https://cdn.jsdelivr.net/npm/d3@7"></script>

安全说明

iframe 沙箱配置：

sandbox="allow-scripts" —— 允许跑脚本
不开 allow-same-origin —— 脚本拿不到本站 cookie / DOM
不开 allow-top-navigation —— 不能跳转父页面
不开 allow-forms —— 不能提交表单
不开 allow-popups —— 不能开新窗口

外层 .sketch 容器加了 data-pagefind-ignore，demo 源码不会污染站内搜索索引。

调试技巧

开发期直接双击打开 .html 文件——浏览器原生跑，DevTools 完整可用，改完刷新即可。等满意了再到博客页面看嵌入效果。
iframe 内报错会显示 about:srcdoc 路径，定位不便。如果排查困难，临时把 demo 拆成独立文件用第 1 条方式调。
postMessage 不工作 / 高度不对：检查 demo 里有没有覆盖 <body> 的 height 计算，或者大量异步加载图片后没触发 resize。极端情况可以显式传 height="600px"。

如何让 Codex 同时支持 ChatGPT OAuth 与自定义 API Provider

Fri, 10 Apr 2026 00:00:00 GMT

最近 OpenAI 又调整了 ChatGPT OAuth 登录的 codex 用量，原本可能已经不是很宽裕的 5 小时窗口又被削减了一轮，再加上 4 月 2 号开始的双倍额度活动也结束了，我自己的实际体感是现在可能半小时到一小时就会蹬完五小时的额度……但活总得继续干下去呀？

所以我需要一个 fallback 方案：平时继续用 ChatGPT OAuth 登录，毕竟订阅额度不蹬白不蹬；额度不够的时候无缝切到第三方 API provider 继续续命。Codex CLI 本身是支持自定义 provider 和 profile 切换的，所以这件事技术上完全可行。但我实际配置的时候踩了不少坑，这篇文章就是把整个过程讲清楚。

我碰到的问题

首先，Codex CLI 支持两种登录路径：

Sign in with ChatGPT：浏览器 OAuth 回调，走 ChatGPT 的额度和数据策略
Sign in with API key：直接用 OpenAI 平台的 API key，走 API 侧的计费

在此基础上，Codex 还允许你定义自定义的 model_provider，指向任何兼容 OpenAI 协议的第三方服务，很多第三方中转的配置方式就是让你在 config.toml 文件里覆盖他们的配置以通过中转来调用codex模型的。

因此，我最开始的配置直接用了三方中转的方案：定义一个自定义 provider，指向中转服务的 base URL，然后加上 requires_openai_auth = true。想法很朴素，觉得这样就能"借用 OpenAI 的登录态，走第三方的线路"，两全其美。

结果就是各种稀奇古怪的认证报错，排查下来问题出在三个地方：

requires_openai_auth = true 不是我以为的那个意思。 这行配置的真实含义是：这个 provider 没有自己的 API key，它的认证来源是 OpenAI。一旦我们这么写，它就不是一个"独立通道"，而是 OpenAI 身份体系下的一个变体。所以当你试图在 ChatGPT OAuth 和第三方中转之间切 profile 的时候，底层的认证根本就没换过，两条路共享同一套身份。

auth.json 被我搞脏了。 Codex 会把登录信息缓存在 ~/.codex/auth.json 里，我之前把第三方中转的 API key 也塞进了这个文件。OAuth 缓存和第三方 key 混在一起，Codex 自己都分不清当前该用哪个凭证。

openai_base_url 会污染内建 provider。 Codex 有一个顶层配置项可以直接改写内建 openai provider 的 base URL。如果你在全局设了这个字段指向中转，那即便你写 model_provider = "openai"，请求也不是真的走官方。名字叫 openai，实际已经被改写了。

这就导致明明我选择 codex --profile chatgpt 了，请求还是跑到中转，或者报出莫名其妙的 key 错误。

正确的配置方案

ChatGPT OAuth 应当走内建的 openai provider，不动它的 base URL，不塞任何多余的东西。第三方中转走一个全新的自定义 provider，用自己的 env_key 读取自己的 API key，跟 OpenAI 的登录态没有任何关系。

我用的是站内的 foxcode，因此配置文件 config.toml就以此为例：

# 默认走 ChatGPT OAuth
profile = "chatgpt"

model = "gpt-5.4"
model_reasoning_effort = "medium"
disable_response_storage = true

# ---- Profiles ----
[profiles.chatgpt]
model_provider = "openai"
model = "gpt-5.4"
model_reasoning_effort = "medium"

[profiles.fox-api]
model_provider = "fox"
model = "gpt-5.4"
model_reasoning_effort = "medium"

# ---- 第三方中转 Provider ----
[model_providers.fox]
name = "fox"
base_url = "https://code.newcli.com/codex/v1"
wire_api = "responses"
env_key = "FOX_API_KEY"

在这份配置里：

默认 profile 是 chatgpt，日常直接输 codex 就走官方 OAuth，不需要每次手动指定
第三方 provider 没有 requires_openai_auth，它只认 FOX_API_KEY 这个环境变量，跟 OpenAI 的登录态完全解耦
没有设置 openai_base_url，内建 openai provider 保持纯净，指向官方

然后是环境变量和 alias：

# 在 .zshrc / .bashrc 中
export FOX_API_KEY="你的第三方中转key"

# 日常快捷入口
alias codexfox='codex --profile fox-api'
alias codexg='codex --profile chatgpt'

不要把第三方 key 命名成 OPENAI_API_KEY，也不要在 shell 里全局导出 OPENAI_BASE_URL 指向中转。这些残留变量会覆盖 Codex 的配置，profile 切换会直接失效。

处理 auth.json

如果你之前往 ~/.codex/auth.json 里塞过第三方 key，直接删掉这个文件，然后重新跑一次 codex login，让 ChatGPT OAuth 生成一份干净的缓存。第三方 provider 的 key 只通过环境变量读取，不经过 auth.json。

如果你在意安全性，还可以把凭证缓存切到系统 keyring：

cli_auth_credentials_store = "keyring"

日常使用

配置完之后日常使用很简单：

# 平时用 ChatGPT OAuth 额度
codex "帮我重构这个函数"

# 额度不够了，切第三方中转
codexfox "帮我重构这个函数"

codex 走官方，codexfox 走中转。不需要手动清环境变量，不需要删 auth 缓存，不需要记住"我现在到底是什么状态"。后续如果你还想加更多 provider，继续沿用同一套原则：新的 profile，新的 provider，新的 env_key，不碰 openai。

其他的常见误区

误区	为什么有问题	正确做法
给第三方 provider 加 `requires_openai_auth = true`	借用 OpenAI 登录态，两条通道的认证没有真正分开	去掉，改用 `env_key`
把第三方 key 塞进 `auth.json`	和 OAuth 缓存混在一起，身份混乱	只通过环境变量传入
在全局设 `openai_base_url` 指向中转	内建 openai provider 被改写，ChatGPT OAuth 也跟着跑偏	不设这个字段
shell 里全局导出 `OPENAI_API_KEY` / `OPENAI_BASE_URL`	环境变量优先级高于配置文件，profile 切换形同虚设	清理掉，第三方用独立变量名

祝大家蹬 Codex 蹬得愉快！

从世界的局部平滑性谈 Embedding 的意义

Fri, 27 Mar 2026 00:00:00 GMT

一、学习何以可能？

我们可以从数学中的一个最基本的概念开始：函数。

函数可以被视为一种映射关系，我们给它一个输入，它还我们一个输出，$f(x) = y$，仅此而已。

因此，气温可以是时间的函数，房价可以是地段的函数，你今天的心情可以是昨晚睡眠质量的函数，女朋友明天的脾气可以是你送的包包价格的函数。世界上几乎所有「A 决定 B」「A 影响 B」的关系&现象，都可以被近似抽象成函数。

我们还可以更复杂一点。上面的例子都是单变量的，即一个输入对应一个输出。但现实世界显然不止这么简单。

比如一个国家一年能生产多少东西，取决于什么？取决于它有多少工人、有多少台机器、技术水平怎么样……经济学家把这些关系压缩成了一个经典的函数——柯布-道格拉斯生产函数（Cobb-Douglas Production Function）：

$$ Y = A \cdot K^\alpha \cdot L^{1-\alpha} $$

其中 $K$ 是资本（机器、厂房），$L$ 是劳动力（人），$A$ 是技术水平，$\alpha$ 决定了资本和劳动各自的权重。一整个国家的经济产出，最终也不过被压缩成了一个函数。

再比如，一件商品的价格是怎么决定的？经济学导论课会告诉你「供需决定价格」，但实际进行建模可能是：

$$ P = f(S, D, E, P_s, \ldots) $$

其中$P$是价格，供给量是 $S$、需求量是 $D$、消费者预期是 $E$、替代品价格是 $P_s$……以及一大堆你可能根本没想到的变量的函数。一杯奶茶卖 18 块钱，背后牵扯着原材料成本、门店租金、竞争对手的定价策略、这条街的人流量、甚至昨天某个网红有没有在小红书上推荐它。

注意，这里和柯布-道格拉斯生产函数有一个本质的不同：柯布-道格拉斯给出了一个漂亮的解析表达式，$Y = A \cdot K^\alpha \cdot L^{1-\alpha}$，形式是已知的，你只需要用数据去拟合几个参数就行。但供需定价呢？我们可以在直觉层面上进行确信，相信这些变量和价格之间存在某种函数关系，但这个真实的、具体的、物理的、实际的 $f$ 长什么样，没有人能写出来。

这其实才是现实世界的常态。我们能感受到输入和输出之间存在规律，但这个规律的解析形式是未知的。

所以从某种意义上说，「建模」这件事的本质，就是在声称一个信念：我相信这里存在一个函数。物理学家相信粒子的轨迹是初始条件的函数，经济学家相信产出是资本和劳动的函数，医生相信你的血压是饮食、运动、基因的函数。整个科学大厦都建立在这个信念之上——世界不是随机的，输入和输出之间存在某种确定的、可描述的关系。

当然现代科学也并不否认随机性，而是认为随机性和结构性可以同时存在，这是统计学习的内容了，此处按住不表

但仅仅相信「函数存在」还远远不够。

一个纯粹任意的函数是不可学习的。我们可以想象一个函数，对每一个输入都给出一个完全随机的输出，这样的函数即使存在，你也拿它毫无办法：你观测了一万个点，对第一万零一个点的预测仍然是瞎猜。因为你在已知点上获得的一切知识，对未知点没有任何约束力。

所以科学（以及一切归纳推理）其实偷偷押注了第二个更强的信念：这个函数不仅存在，而且是平滑的。

所谓平滑，直觉上很好理解：你稍微动一下输入，输出也只是稍微动一下。水温从25°C 升到26°C，密度只会变化一点点；你往东走一公里，海拔不会突变三千米（在绝大多数情况下）。输入和输出之间有某种「渐进的、可预期的」关联，没有突然的跳崖和瞬移。

数学上对这个直觉最干净的刻画之一叫 Lipschitz条件（利普希茨条件），如果存在常数 $L > 0$，使得对任意输入 $x_1, x_2$：

$$ |f(x_1) - f(x_2)| \leq L \cdot |x_1 - x_2| $$

就称 $f$ 是 Lipschitz 连续的。这个不等式说的事情很朴素：输出的变化幅度，永远不会超过输入变化幅度的某个固定倍数，变化率有其天花板。

平滑性也因此给了我们一样至关重要的东西：局部可推断性。如果你知道了 $f(x_0)$ 的值，那么 $x_0$ 附近的点，$f$ 的值也不会离 $f(x_0)$ 太远。每一个已知的观测点都不是孤立的，它的信息可以「辐射」到周围的邻域，为你还没观测到的地方提供约束；而在这个约束之下，我们可以合理预期这些没观测到的地方的值。

这就是归纳法的数学底气：过去的经验之所以能指导未来，是因为「未来」就住在「过去」的邻域里，而平滑性保证了邻域内的行为是可预期的。

如果故事到这里就结束了，那就太好了，可惜并没有。

问题出在维度上。

我们前面举的例子，如温度与密度，位置与海拔，输入都是一两个变量，在此基础上我们采十几几十个点就能把函数轮廓描绘个大概。但回忆一下那个奶茶定价的例子：我们的输入变量可能是几十个、上百个变量，而在机器学习真正面对的场景里，维度还要再夸张几个数量级——一张普通的照片有几十万个像素，每个像素都是一个维度；一段文本经过分词后也是一个高维的离散空间。

我们姑且可以把一张灰度图想象成一个巨大的数字表格，每个格子通常里会填一个介于0到255之间的整数，表示在这个位置的亮度，那么一张 200 * 200的灰度图就是200行、200列，总共40000个格子，也就四万维；即 $200 \times 200$ 的灰度图 = 40000 个格子 = 40000 个数字 = 40000 维空间里的一个点。

而彩色图就更复杂了，彩色图每个像素不再只是一个数字，而是三个——R（红）、G（绿）、B（蓝）各一个值。所以同样 $200 \times 200$ 的彩色图就需要 $200 \times 200 \times 3 = 120000$ 个数字，即 120000 维空间里的一个点。现代手机里的一张普通的照片（1000 * 1000）可能就有三百万维。

哦有同学看到这里就想问了，为什么要把一张图片当成几十上百成千万维的东西？

毕竟我们看一张人脸照片，我们感受的是「这是一张人脸，嚯可能还怪好看」，而不是「这是一个四万维空间中的坐标点，哇数学真是巧夺天工」。我们觉得这张脸好看或不好看，用的是直觉，不是在心里默算几万个像素值的函数。那为什么机器非得活在这么高的维度里？

比如这张酒寄彩叶和辉夜的截图，你第一反应大概也许是哇好可爱，而不是下面这一坨👇

因为机器没有直觉。

我们能一眼认出这是一张人脸，是因为我们的祖先足够会恣意生长，我们的大脑在几十万年的演化和几十几二十几几十几年的生活经验里，已经帮我们把「像素→语义」这条路修好了。我们看到的不再是像素或者别的什么抽象东西，我们看到的是眼睛、鼻子、表情、情绪，我们的大脑已经替我们完成了降维。但机器拿到的输入就是原原本本的、赤裸裸的像素值。对于一个从零开始的算法来说，它接收到的就是一串数字，这串数字有多长，它的世界就有多少个维度。

这不只是图片的问题。我们给计算机&模型一段文本，经过分词之后就是一个高维的离散序列；给它一段语音，就是一串长采样点；给它一个用户的行为记录，就是一个由几百个特征拼成的向量。在机器学习的语境里，维度不是我们选择的，而是原始数据「天生自带」的。我们没有办法假装一张图片只有三个变量，因为少了任何一个像素，信息就不完整了。

所以困境就在于此：一方面，我们好不容易论证了平滑性让学习成为可能——只要你在输入空间里积累足够密的观测点，就能靠「领域推断」来覆盖未知区域。另一方面，输入空间的维度是被数据的原始表示硬生生撑起来的，而在这样的高维空间里意味着 「邻域」变成了一个极其奢侈的概念。

在一维空间里，我们想把一条线段均匀覆盖到每隔 0.01 就有一个样本点，只需要 100 个点。在二维空间里，同样的密度需要 $100^2 = 10000$ 个点。三维空间？$100^3 = 1000000$ 个点。推广到 $d$ 维，我们需要 $100^d$ 个点，即样本量随维度指数增长。

这就是所谓的维度灾难（Curse of Dimensionality）。

我们刚刚费了好大力气建立起来的推理链条「平滑性保证了邻域内可推断」在高维空间里突然变得苍白无力。不是因为平滑性失效了，而是因为我们根本凑不齐一个所谓的邻域。我们的训练样本再多，放进一个几十万维的空间里也不过是汪洋大海中稀疏得可以忽略不计的几粒沙。每一个数据点都是一座孤岛，「辐射」的信息在它到达最近的邻居之前就已经衰减殆尽了。

所以，光有「函数存在」和「函数平滑」这两个信念是不够的。如果高维空间真的是一片均匀的荒原，那么无论我们的模型多精巧，我们的数据多海量，学习都是无望的。

我们需要第三个信念。

而幸运的是，现实世界中的很多有意义数据往往表现出某种结构，来满足这个信念——高维数据的真实有效维度，远比它的表面维度低得多。

一张 $1024 \times 1024$ 的彩色照片有三百多万个像素维度，但并不是每一种像素排列都对应一张「有意义的」图片。随机生成三百万个像素值，你几乎必然只会得到一团噪声。所有「看起来像人脸」的照片，只占据了这个天文数字维度空间中极其微小的一部分，而它们挤在一条弯弯曲曲的低维曲面上。

这就是流形假设（Manifold Hypothesis）：高维数据实际上近似分布在一个低维的光滑流形上。所谓流形，你可以想象一张被揉皱后塞进三维空间的纸，它在三维空间里弯弯曲曲、褶皱重叠，但它自身只有两个维度。你站在纸面上行走，永远只需要「前后」和「左右」两个方向就够了，你感受不到第三个维度的存在。

同理，人脸照片虽然活在百万维的像素空间里，但所有合理的人脸构成的集合可能只是一个几百维甚至更低维的曲面。沿着这个曲面走，人脸会连续地变化，如眉毛渐渐挑起，嘴角慢慢扬起，光影从左侧柔和地转移到右侧，而大概率不会突然从一张脸跳成一团马赛克。

当然流形假设也只是一种假设，它更像是帮助我们理解高维数据为何仍可学习的一种强而有力的近似视角

现在把这三层信念叠在一起看：

世界存在规律——输入和输出之间有函数关系
规律是平滑的——变化是有界的，小扰动只带来小偏移
数据的有效维度是低的——我们不需要覆盖整个高维空间，只需要覆盖那个低维流形，而数据是有结构的，相邻的点共享相似的语义

前两条给了我们「局部能推断」，第三条把「局部」从不可企及变回了可操作。三条合在一起就是一句话：在这个宇宙里，相似的原因倾向于产生相似的结果。基于此，有限的样本才能真正拼出未知函数的轮廓，归纳法才真正站得住脚，机器学习才从数学上变得可行。

二、把语义变成几何

好的，长舒一口气，现在我们知道了：数据虽然表面上住在一个几十万维的空间里，但实际上挤在一个低维的光滑流形上。这是个好消息。但紧接着就有一个非常实际的问题：

这个流形在哪？长什么样？我们怎么在上面做计算？

困难在于，流形是弯曲的。它蜷缩、折叠、扭结在高维空间里，像一团被揉皱的纸塞进了一个巨大的房间。两个数据点在原始的高维空间里可能离得很近，但沿着流形走其实隔着十万八千里——就像一座山两侧的住户，直线距离穿过山体可能只有 500 米，但沿着山路走要绕上 20 公里。反过来也成立：沿着流形明明紧挨着的两个点，被折叠之后可能散落在高维空间的天涯两端。

换句话说，原始高维空间里的距离，并不能真实地反映数据之间的语义关系。你在像素空间里计算同一个人脸但是亮度不同的两张照片的欧氏距离，得到的数字几乎是没有意义的；把所有像素整体调亮 10%，像素距离变了一大截，但这显然还是「同一张脸」。

所以我们真正需要的是：找到一种映射，把数据从弯曲的高维流形「展开」到一个相对低维的、平坦的向量空间里，并且让这个空间里的距离较为忠实地反映数据在流形上的真实关系。

近的东西映过去还是近的，远的东西映过去还是远的。语义上相似的数据点，在新空间里挨在一起；语义上无关的，彼此远离。

这件事，就叫 Embedding——把原始对象映射为向量，使得与任务相关的相似性、结构或关系，能在向量空间里被几何地度量和操作。

目标说清楚了。但目标从来不是最难的部分，怎么做到才是。

要把「语义相近的东西映射到几何上相近的位置」，你首先得回答一个问题：你怎么知道什么和什么是语义相近的？

我们之所以需要 Embedding，恰恰是因为原始数据层面的距离不能反映语义，如像素空间里的欧氏距离对「这是不是同一张脸」几乎没有发言权。而现在你要学一个映射，让语义相近的东西在新空间里距离近？那你得先有一把语义的尺子。可如果我们已经有了这把尺子，还学 Embedding 干嘛？

这看上去像是一个循环论证，而人类中最聪明的那部分大脑给出的解法是：我们从来不直接定义「语义相近」，我们定义的是一个更弱、更容易获取的东西——共现。

1.你的邻居定义了你

让我们从语言开始，因为语言领域的 embedding 故事最经典，也最符合直觉。

20世纪中叶，语言学家 J.R. Firth 说过一句被引用到烂的话：

"You shall know a word by the company it keeps."
一个词的意义，由它的同伴决定。

这句话的意思是：你不需要去查词典定义来理解「咖啡」是什么意思。你只需要观察「咖啡」经常和哪些词一起出现——「喝」「杯」「苦」「提神」「早晨」「拿铁」——这些共现的伙伴，就已经圈定了「咖啡」的语义轮廓。

反过来想，如果一个外星人从未接触过地球文明，你递给它一本五百万字的中文小说，它完全不认识任何一个字。但如果它足够聪明，它会发现：「猫」和「喵」总是出现在相似的上下文里，「狗」和「汪」也是，而「猫」和「抵押贷款」几乎从不出现在同一段话里。仅凭共现的统计规律，不需要任何先验知识，它就能开始构建出一张模糊的语义地图，划清哪些词彼此相关，哪些词毫无关系。

这个直觉，就是几乎所有词向量方法的哲学起点。

在2013年，Google 的 Tomas Mikolov 等人提出了 Word2Vec，正式把这个直觉变成了一个可计算的算法。Word2Vec 的核心思想可以浓缩成一句话：

让一个浅层神经网络去做一个「完形填空」的任务，然后偷走它的中间产物。

具体来说，Word2Vec 有两种架构，我们先看更直觉的那个——Skip-gram。

Skip-gram 的任务很简单：给定一个中心词，预测它的上下文词。比如有这么一句话：

"今天天气很好我们去喝咖啡吧"

如果中心词是「喝」，窗口大小为 2，那模型的任务就是：看到「喝」，请预测出「我们」「去」「咖啡」「吧」这几个词。

具体怎么做呢？我们给词表里每一个词分配一个随机初始化的向量（没错，一开始是随机的，完全没有任何语义信息）。然后我们训练一个简单的模型：输入中心词的向量，经过一层运算，输出一个概率分布，表示「词表里每个词出现在这个中心词上下文中的概率」。

训练目标是：让真实出现在上下文里的词概率高，没出现的词概率低。

然后，就是大力出奇迹的时刻：我们拿几十个 GB 的文本语料，几十亿个这样的（中心词, 上下文词）训练对，反复训练。

训练完之后，神奇的事情发生了。

那些一开始完全随机的词向量，在反复被梯度更新之后，自发地排列出了有意义的几何结构。

到底有多有意义？有意义到什么程度？

答案是：有意义到可以做算术。

Mikolov 等人在论文中展示了一个后来被引用了无数遍的例子：

$$ \vec{King} - \vec{Man} + \vec{Woman} \approx \vec{Queen} $$

把「国王」的向量减去「男人」的向量，加上「女人」的向量，得到的结果在整个词表的几十万个向量里，最近邻居恰好是「王后」。

第一次看到这个结果的人通常会有两个反应：第一反应是"卧槽好酷"，第二反应是"等等，这为什么能 work？"

让我们想一想这意味着什么。

$\vec{King} - \vec{Man}$ 得到了一个差向量，这个差向量指向的方向是什么？它剥离了"国王"中"男性"的那部分语义，剩下来的大约是"皇室的、统治的、至高的"这些属性。换句话说，这个差向量近似编码了「royalty（皇室身份）」这个抽象概念的方向。然后你把这个方向加到 $\vec{Woman}$ 上，就得到了"一个拥有皇室身份的女性"——Queen。

更让人震惊的是，这不是一个孤例。类似的线性关系在词向量空间里大面积涌现：

$\vec{Paris} - \vec{France} + \vec{Japan} \approx \vec{Tokyo}$（首都关系）

$\vec{better} - \vec{good} + \vec{bad} \approx \vec{worse}$（比较级变换）

$\vec{walking} - \vec{walk} + \vec{swim} \approx \vec{swimming}$（时态变换）

这意味着词向量空间里存在着近似平行的语义方向。"男性→女性"是一个方向，"原级→比较级"是一个方向，"国家→首都"是一个方向。这些方向彼此独立，可以自由叠加组合。向量空间里的线性运算，居然对应了人类语义层面的类比推理。

回到我们第一节讲的那件事——"把语义变成几何"。到这里你可以真切地感受到这句话不是比喻，它是字面意义上的事实：语义关系被编码成了向量空间中的几何关系，概念之间的类比被编码成了平行四边形。

当然，诚实地说，这种线性类比的魔法也有它的边界。它在语法变换（时态、单复数、比较级）和简单的关系类比（国家-首都、性别对调）上表现惊艳，但在更复杂、更抽象的语义关系上就开始吃力了——你大概算不出 $\vec{自由} - \vec{束缚} + \vec{沉默} = ?$ 这种东西，因为越抽象的概念，其语义关系越不可能被一个固定方向的线性偏移所捕获。

但这不影响这个发现的意义。它第一次向我们展示了一件事：一个纯粹从统计共现中学出来的向量空间，其内部自发形成的几何结构，居然与人类的概念系统存在某种深层的同构。

没有人教它"国王和王后的关系等价于男人和女人的关系"，没有人提供任何关于人类社会结构的先验知识。它只是读了几十亿个词，然后这些关系就从统计规律中浮现了出来。

2.从语言到一切：对比学习与更一般的 Embedding

Word2Vec 的故事很漂亮，但有一个显而易见的局限：它依赖「上下文窗口」这个概念。一个词的左边几个词、右边几个词构成它的上下文，这是语言文本天然具备的结构。

但如果我们想给图片学 Embedding 呢？一张照片没有"上下文窗口"——它的左边不是另一张照片，它的右边也不是。一段蛋白质序列、一个分子结构、一条用户行为轨迹，都没有现成的"上下文"可以用来做预测任务。

所以我们需要后退一步，问一个更根本的问题：Word2Vec 真正的成功秘诀到底是什么？

不是"预测上下文"本身。预测上下文只是一个手段，一个代理任务。它真正做到的事情是：通过一个巧妙设计的目标函数，让语义相似的对象在向量空间里被迫靠近，让语义无关的对象被推远。

如果我们把这个"靠近-推远"的逻辑从语言的上下文中抽象出来，就得到了一个远为通用的学习范式——对比学习（Contrastive Learning）。

对比学习的核心机制可以压缩成三步：

第一步，构造"正样本对"和"负样本对"。 正样本对是我们认为"应该靠近"的两个东西，负样本对是"应该远离"的两个东西。

在 Word2Vec 里，正样本对就是（中心词，真实出现在其上下文中的词），负样本对就是（中心词，从词表里随机抽一个大概率无关的词）。但在别的领域，构造正负样本对的方式可以完全不同：

图像：取一张图片，对它做两次不同的随机变换（裁剪、翻转、调色、模糊），得到的两个版本就是正样本对。随机抓另一张图片做负样本。
文本：一句话和它的同义改写是正样本对。随机抓一句不相关的话做负样本。
多模态：一张图片和描述它的文字是正样本对（CLIP 就是这么干的）。同一张图片和一段完全不相关的文字是负样本对。

第二步，用一个编码器把每个样本映射成向量。

第三步，训练编码器，让正样本对的向量尽可能近、负样本对的向量尽可能远。

就这么简单。整个训练过程不需要任何人工标注的标签，不需要任何领域先验知识，你只需要定义"什么算一对正样本"。

这里有一个非常精妙的地方值得停下来品味一下。

以图像的对比学习为例。我们把同一张猫的照片裁剪一下、翻转一下、色调调暖一点，然后要求模型认为这些变换后的版本"本质上是同一个东西"。这意味着什么？意味着我们在告诉模型：裁剪、翻转、色调变化是"不重要的"表面差异，你应该忽略它们。

那模型为了让这些变换后的版本映射到相近的向量，它就被迫去捕捉那些在所有变换中都保持不变的特征——也就是物体的形状、结构、语义类别这些更深层的东西。

换句话说：你选择对什么变化保持不变性（invariance），就等于在隐式地定义什么是"语义"，什么是"噪声"。 数据增强的策略看似是个工程细节，实际上是一个深刻的认识论选择：你在告诉模型，这个世界的哪些维度是本质的，哪些是偶然的。

这和人类认知的某些侧面惊人地相似。你之所以能在不同光照、不同角度、不同遮挡条件下认出同一个人，正是因为你的视觉系统经过多年训练，学会了对这些"表面变化"保持不变性，只提取那些与"这个人是谁"相关的本质特征。

所以对比学习不只是一种技术方案，它其实在做一件很哲学的事情：它在学习区分本质与偶然、信号与噪声、不变量与变换群。而这件事，本质上就是人类自柏拉图以来一直在追问的那个问题——什么是事物的"本质"（essence），什么是"现象"（appearance）？

3.多面孔的词

Word2Vec 给每个词分配一个固定的向量。"苹果"就是"苹果"，无论它出现在什么句子里，它的向量都是同一个。

但聪明的我们（或者说聪明的先辈们）马上就能意识到这里有个问题：

"我咬了一口苹果，汁水四溅。"
"苹果发布了新款 MacBook Pro。"

这两个"苹果"的含义天差地别，一个是水果，一个是科技公司。但在 Word2Vec 的世界里，它们共享同一个向量。模型不得不把这两种完全不同的语义硬生生地压缩、折叠、平均到同一个点上，最终得到的是一个模糊的、谁都不精确代表的混合体——一个既有点像水果又有点像科技公司的四不像向量。

这不仅仅是"苹果"的问题。自然语言中一词多义的现象无处不在："打"可以是打人、打电话、打酱油、打车；"花"可以是花朵、花费、花心；"right"可以是正确的、右边的、权利。语言的本质就是多义的、语境依赖的。一个词的意思从来不是由这个词本身单独决定的，而是由它所处的整个句子、段落、甚至对话的上下文共同决定的。

所以静态词向量的瓶颈不是技术上的缺陷，而是一个根本性的建模假设错误：它假设"一个词 = 一个含义 = 一个向量"，但现实世界中的语义根本不是这样运作的。

出路在哪？其实第一节就已经埋下了线索。

回忆一下 Firth 的那句话："一个词的意义，由它的同伴决定。" Word2Vec 用了这个思想的一半——它在训练阶段利用上下文来学习词向量。但训练完成之后，上下文就被丢掉了，每个词被钉死在一个固定的位置上。

真正彻底贯彻 Firth 哲学的做法应该是：不仅在训练时利用上下文，在使用时也让每个词的表示根据当前的上下文动态生成。

这正是 2018 年前后的一系列工作（ELMo、GPT、BERT）所做的事情。

以 BERT 为例。BERT 不再给每个词一个固定的向量，而是给定一整个句子，让模型在看到完整上下文之后，为句子中的每一个词各自生成一个向量。这意味着"苹果"在"我咬了一口苹果"中的向量，和它在"苹果发布了新款 MacBook"中的向量，是不同的。

同一个词，在不同的语境中，获得不同的表示。这才是 Firth 那句话的完整实现。

这是怎么做到的？核心机制叫 Self-Attention（自注意力）。

直觉上可以这样理解：句子里的每一个词在生成自己的表示之前，会先"看一眼"句子里的所有其他词，然后根据相关程度决定从每个词那里"借"多少信息过来，用来调整自己的表示。

在"我咬了一口苹果"中，"苹果"会重点关注"咬""一口"这些词，从它们那里借来的信息会把"苹果"的表示推向"水果"的语义方向。而在"苹果发布了新款 MacBook"中，"苹果"重点关注的是"发布""MacBook"，这些信息会把它的表示推向"科技公司"的方向。

同一个词的向量不再是固定的坐标点，而是一个随上下文流动的、活的表示。

如果用我们第一节的流形语言来说：Word2Vec 是在流形上给每个词钉了一个固定的图钉，而 BERT 允许每个词在流形上滑动，滑到当前语境所指示的那个位置。

这个从静态到动态的跃迁，不只是技术上的进步，它还回应了语言哲学中一个古老的争论：词语的意义到底是存储在词典里的固定实体，还是在每次使用中被重新协商出来的？

维特根斯坦在《哲学研究》中给出了他的答案："一个词的意义就是它在语言中的用法。"（The meaning of a word is its use in the language.）意义不是一个被锁在保险柜里的静态对象，等你来查阅；意义是在具体的语言游戏（Sprachspiel）中、在特定的生活形式（Lebensform）中被实时生成的。

从这个角度看，BERT 做的事情恰恰是维特根斯坦语言观的计算实现：词的表示不是预先定义好的，而是在每一次具体的"语言游戏"（每一个具体的句子）中被动态地、语境地生成的。

这是不是就意味着 BERT"理解"了语言？那又是另一个问题了。但至少在表示这个维度上，它比 Word2Vec 更忠实于语言的本质。语言从来就不是一个词一个意思的字典，而是一片语境之间相互映照、彼此定义的动态网络。

三、计算相似性

1.下沉到语义层

在第一节，我们论述了学习之所以可能，依赖于三个关于世界的信念：存在规律、规律平滑、有效维度低。第二节，我们展示了如何通过共现、对比、动态上下文等手段，把原始数据映射到一个向量空间里，让语义关系变成几何关系。

但到目前为止，我们一直在讨论的是 Embedding 是什么以及怎么做到的。现在该正面回答标题里的那个词了：意义。

Embedding 的意义到底是什么？

在 embedding 出现之前，人类当然也已经有了计算“相似性”的方法。TF-IDF、BM25、关键词匹配——这些方案支撑了整整一个时代的搜索引擎，让你在 Google 搜索框里输入几个关键词就能从几十亿网页中找到相关结果。它们工作了很多年，而且工作得还不错。

但它们衡量的是什么？是词汇的重叠。

两段文本共享了多少相同的词？共享的词在各自文本中有多稀有（因此有多重要）？本质上，这些方法在做的事情是数数——数两段话之间有多少个相同的字符串出现了。

这在很多场景下管用，但它有一个致命的盲区：语言可以用完全不同的词说同一件事。

"我想买一台笔记本电脑"和"推荐一款轻薄本"，关键词几乎没有重叠，TF-IDF 算出来的相似度接近于零。但任何一个人类都知道，这两句话说的是同一件事。反过来，"苹果是一种水果"和"苹果是一家公司"共享了大量相同的词，关键词方法会认为它们高度相似，但它们的意思南辕北辙。

关键词方法度量的是表述的相似性，而不是意义的相似性。 它能告诉你两段话长得有多像，却无法告诉你它们说的是不是同一回事。

Embedding 做到的事情，是让"相似性"的计算从词的表面下沉到了语义层。

当两段文本、两张图片、两段代码都被映射成向量之后，它们之间的语义关系就变成了向量空间里的几何关系。"这两个东西意思有多像？"这个关键词方法答不好的问题，现在只需要：

$$ \text{sim}(\mathbf{a}, \mathbf{b}) = \frac{\mathbf{a} \cdot \mathbf{b}}{|\mathbf{a}| \cdot |\mathbf{b}|} $$

一行余弦相似度。

这不是一件小事，因为一旦"相似性"变成了可计算的，一整类原本只能靠人类智能完成的操作就突然变成了几何运算：

语义检索：从十亿条文档里找到和你的问题最相关的那几条——本质上就是在向量空间里做最近邻搜索。
聚类：把几百万条用户反馈自动归类成几十个主题——本质上就是在向量空间里找密度峰值。
推荐：找到和你喜欢的东西"气质相似"的东西——本质上就是在向量空间里画一个以你的偏好为圆心的球。
去重与对齐：判断两个来源不同的条目是否指向同一个实体——本质上就是看两个向量是不是落在了同一个邻域里。

这些任务在表面上看起来千差万别，但在 Embedding 的视角下，它们全部退化成了同一个数学问题：在向量空间里度量距离。

而在大语言模型的时代，这件事还有一个更具体、更关键的应用：RAG（Retrieval-Augmented Generation，检索增强生成）。

LLM 的上下文窗口是有限的。即使是最前沿的模型，能一次性处理的文本长度也有天花板。参数是有限的，世界是无限的，大模型不可能把人类有史以来的所有知识都压缩进参数里。所以当你问 LLM 一个它参数里没有记住的问题时，它要么诚实地说"我不知道"，要么不那么诚实地开始编造。

后者可能会更加常见

RAG 的解决方案是：在 LLM 回答之前，先用 Embedding 模型把你的问题和一个外部知识库里的所有文档都映射成向量，找到最相关的几条，塞进 LLM 的上下文里，然后让它基于检索到的真实信息来生成回答。

在这个架构里，Embedding 模型充当的角色是什么？是给 LLM 装上了一个可检索的外部记忆。LLM 负责思考和表达，Embedding 模型负责在浩如烟海的信息中找到那几颗最相关的针。没有 Embedding，RAG 就不存在；没有 RAG，LLM 就只能困在自己的参数之中，像一个博闻强识但与世隔绝的学者，只能回忆，不能查阅。

2.建立语义世界的坐标系

Embedding 的意义当然不止于"让某些具体任务变得可行"。真正深刻的地方在于：一个好的 Embedding 模型，其价值不在于它自己能完成什么任务，而在于它为所有下游任务提供了一个共享的语义坐标系。

让我们做一个类比。

1637 年，笛卡尔做了一件看起来很简单的事：他在平面上画了两条互相垂直的线，然后宣布，平面上的每一个点都可以用一对数字 $(x, y)$ 来表示。

这件事本身没有解决任何具体的几何问题。它没有告诉你如何求圆的面积，没有帮你证明勾股定理，没有给出任何新的定理或公式。它做的事情更加基础，也更加深远：它给几何世界提供了一种统一的表示语言。

有了坐标系，圆变成了 $x^2 + y^2 = r^2$，抛物线变成了 $y = ax^2 + bx + c$，两条直线的交点变成了解方程组。几何问题不再需要逐个用巧妙的辅助线和灵感来攻克——它们被统一翻译成了代数问题，而代数有一整套系统的、机械的、可编程的求解方法。

Embedding 模型对语义世界做的事情，与笛卡尔对几何世界做的事情，在结构上高度相似：它给语义世界提供了一个坐标系。

有了这个坐标系，一段文字不再是一串不可运算的符号，而是空间中一个有坐标的点。一张图片不再是一团不可比较的像素，而是同一个空间（或经过对齐的相邻空间）里的另一个点。一段代码、一条蛋白质序列、一个用户行为轨迹，都可以被映射成向量，拥有坐标，参与运算。

而当不同模态的数据被映射进同一个向量空间时，事情就变得更加有趣了。OpenAI 的 CLIP 模型把图片和文字映射到了同一个 Embedding 空间里。这意味着你可以用一句话"a cat sitting on a windowsill watching the rain"去检索一张从未被任何人用文字描述过的照片，只要那张照片的视觉语义和这句话的文本语义在向量空间里足够接近。这背后的意义远超"以文搜图"这个具体功能——它意味着图像和语言之间那条古老的模态鸿沟被桥接了，不是通过人工标注，不是通过规则匹配，而是通过把两种截然不同的符号系统投射到同一个几何空间里，让它们的距离变得可度量、可比较、可运算。

但坐标系本身不干活。笛卡尔画完那两条线之后，也没有立刻算出什么新东西。坐标系的价值是基础设施性的：它让一整类操作从"需要专门设计"变成了"平凡"，让后来者可以在它之上直接建造，而不需要每次都从最底层开始。

如果你想做一个"智能"系统，比如一个能理解用户意图的搜索引擎、一个能自动归类工单的客服系统、一个能推荐相似论文的学术平台……在没有通用 Embedding 的年代，你需要做什么？

答案是：每一个任务，都得在"理解数据"这件事上从头来过。做情感分析？从原始文本开始，设计特征工程，训练一个分类器。做文档检索？换一套特征、换一种索引结构、再训练一个模型。做推荐系统？再来一遍。每个系统都在重复同一件事的前半段——理解数据，只有后半段——做决策——才是各自不同的。

而在 Embedding 的体系下，"理解"被抽离成了一个独立的、可复用的环节。一个通用的 Embedding 模型负责把原始数据映射成向量，完成从"符号"到"坐标"的翻译。下游任务只需要在坐标上做轻量操作：检索是最近邻搜索，聚类是找密度峰值，分类是在向量上叠一层线性层，推荐是画一个以用户偏好向量为圆心的球。"理解"变成了公共层，"决策"才是各个任务自己的事。

当 Embedding 模型升级时，所有依赖它的下游任务在逻辑上都能受益；它们的架构不需要重新设计，业务代码不需要重写。这种解耦还带来了一个极其重要的工程性质："理解"可以离线预计算，而"使用"几乎是免费的。

把一段文本送进 Embedding 模型是有成本的：它需要经过多层神经网络运算，最终产出一个向量。但这件事只需要做一次。向量一旦算好，存下来，之后的每一次检索、比较、聚类，都只是向量之间的数学运算——点积、余弦、L2 距离，而这些运算的开销相比神经网络推理低了好几个数量级。

这意味着什么？意味着你可以把一个知识库的一千万条文档全部 embed 一遍，把向量存进数据库，然后之后每次用户提一个问题，你只需要 embed 这一句话（一次推理），再去数据库里做一次向量搜索（毫秒级），就能找到最相关的几条文档。Embedding 把"理解"从一个实时的、反复的开销，变成了一个一次性的、可摊销的投资。

而这种新的查询模式——"找到和这个意思最接近的东西" 也催生了一类新的基础设施：向量数据库（Vector Database）。

传统数据库回答的问题是精确匹配的：「这条记录在哪？」；我们需要按主键查找、按条件过滤、按字段排序。这些操作的前提是，你得精确地知道自己在找什么：一个确切的 ID、一个明确的关键词、一个具体的数值范围。但在语义检索的场景里，你常常不知道自己在找什么，至少不知道它的精确表述。你知道的只是一个意思：「跟这个意思差不多的东西在哪？」这不是精确匹配问题，这是近似最近邻问题。

向量数据库（Pinecone、Milvus、Qdrant、Weaviate……）就是为这种查询模式而生的。它们用 HNSW、IVF 这类专为高维向量空间设计的近似最近邻算法，在几十毫秒内从几十亿条向量中找到和你的查询向量最接近的那几个。

不过向量能力也正在被传统数据库吸收（PostgreSQL 的 pgvector、Elasticsearch 的 dense vector），而专用向量数据库也在补齐元数据过滤、权限控制等传统能力。更准确的说法是：Embedding 改变了"查找"这个动作的性质，从匹配字符串变成了度量意义的距离，而数据库的能力不得不扩展来适应这种新的查询语义。

回到起点：为什么能 Work？

写到这里突然感觉有点圆不回来了，摊子铺太大了

在最后，我们可以再问一个问题：这一切为什么能 work？

不是在问算法为什么有效，不是在问 Transformer 的注意力机制为什么比 RNN 好，不是在问 HNSW 索引的时间复杂度，这些都是工程层面的"为什么"，都有各自精确的技术解答。我想问的是一个更底层的、几乎带有形而上学色彩的"为什么"：

为什么语义可以被几何化？为什么意义之间的关系能够被向量之间的距离所忠实地刻画？

答案，其实在我们第一节就已经给出了，只是当时它穿着数学的外衣，不太容易被认出来。

让我们把它换一种方式说一遍：这个世界是局部平滑的。

不只是物理世界的那种水温升高一度，密度只变化一点点。语义世界也是。一个句子里替换掉一个词，意思只偏移一点点（大概）。一张人脸照片的光照微微改变，它传达的"这是谁"的信息只扰动一点点。一个概念和它最近的相邻概念之间，总是存在着可以被连续插值的过渡地带，而不是一道突兀的悬崖。

"咖啡"和"拿铁"之间的语义距离很近。"拿铁"和"卡布奇诺"也很近。"卡布奇诺"和"摩卡"也很近。你可以沿着这条路一步步走下去，从咖啡走到茶，从茶走到饮料，从饮料走到食物，每一步都是一个小小的、平滑的语义偏移。这条路不会在某个节点突然跳到"量子力学"或"劳动仲裁"，除非你刻意绕了一条非常古怪的路径。

语义空间和物理空间一样，服从某种局部的利普希茨条件：相邻的输入产生相邻的输出，小扰动只引起小偏移。

而 Embedding 之所以能 work，不是因为某个算法足够聪明，不是因为某个损失函数设计得足够巧妙，而是因为它所试图捕捉的那个对象，即意义的结构本身就具备可以被几何化的性质。平滑性保证了邻域内的可推断性，流形假设保证了有效维度的可控性，这两者加在一起，意味着语义空间里存在着一种内禀的、低维的、光滑的几何结构，它不是 Embedding 模型发明的，而是 Embedding 模型发现的。

或者用一个更具体的说法：Word2Vec 没有创造"国王减去男人加上女人等于王后"这个关系。这个关系早就存在于人类语言的统计结构中，存在于几十亿句话的共现模式里，存在于人类几千年来使用这些词的方式里。Word2Vec 只是提供了一面足够灵敏的镜子，让这个本来就存在的结构显影了出来。

从这个角度看，Embedding 与其说是一种人工智能技术，不如说是一种测量仪器。望远镜没有创造星星，显微镜没有创造细胞，Embedding 模型也没有创造语义的几何性。它们做的事情是同一件：把一种本来就存在但肉眼不可见的结构，转换成了人类（以及机器）可以观察、度量和操作的形式。

而这件事之所以深刻，是因为它隐含着一个关于世界本身的断言：意义不是混沌的。 概念与概念之间不是以任意的、随机的方式散落的。它们有邻域，有距离，有方向，有可以被连续行走的路径。语义世界和物理世界一样，拥有自己的拓扑、自己的度量、自己的几何。

我们在第一节说过，科学的全部底气建立在一个赌注上：相似的原因倾向于产生相似的结果。现在我们可以看到，这个赌注的射程比我们当时以为的更远。它不仅适用于温度与密度、位置与海拔这些物理量之间的关系，也适用于词语与词语、概念与概念、意义与意义之间的关系。世界的局部平滑性不止是物理定律的性质，它似乎是结构本身的性质，任何足够丰富、足够有组织的系统，无论是物理的还是符号的，都倾向于表现出这种平滑性。

也许这才是 Embedding 最深层的意义。它不只是一种让检索变快、让推荐变准、让 RAG 成为可能的工程工具。它是一个来自数学的证据，表明我们所栖居的这个世界——包括我们用语言和概念建造的那个精神世界——在最根本的层面上，是有结构的、可度量的、几何的。

而这件事，值得我们感到一点点惊奇。

一念不落，万象可循：YOLO 的记忆系统实现

Tue, 17 Mar 2026 00:00:00 GMT

在之前的博客《浅谈ChatGPT的记忆实现机制兼论工程端记忆设计》里，我们拆解了目前 C 端记忆系统做到天花板的 ChatGPT 是怎么设计其记忆能力的。那篇文章从 LLM 本身的无状态性聊起，逆向分析了 ChatGPT 背后那套六模块用户画像系统，包括它如何在你毫无感知的情况下提取你的对话偏好、行为模式和交互元数据，再通过语义匹配动态注入上下文，构造出"它记得你"的幻觉。最后我们把工程端的记忆实现分成了三档：最基本的上下文维护、中间形态的模糊语义记忆、以及 ChatGPT 所代表的高精度结构化动态注入方案。

那篇文章结尾我还放了自己写的一套"猴版"长期记忆，靠 Gemini Flash 每隔十五轮抽取关键信息、分配优先级权重、存进 JSON 文件，效果凑合但确实能跑。当时的结论是"大道至简，绝大多数 chatbot 场景用这套就够了"。

但 YOLO 显然不属于"绝大多数场景"。

作为一个嵌入 Obsidian 的 AI 助手，YOLO 面对的情况要特殊得多：用户的整个 Vault 本身就是一个巨大的外部记忆体，笔记、日记、项目文档天然构成了一套可检索的知识库。在这个前提下，AI 自己维护的"记忆"和用户笔记库里已经存在的信息之间，边界在哪？它应该记住什么、忽略什么、又以什么粒度去组织这些记忆？这些问题在通用 chatbot 场景下可以含糊过去，但在一个以本地知识管理为核心的工具里，必须给出明确的设计回答。

这篇文章会展开聊聊 YOLO 的记忆系统是如何设计与实现的。

一、YOLO 的记忆到底应该记什么？

普通 chatbot 的记忆系统很大程度上要解决的是「我对你一无所知」的问题，所以我们可以看到 ChatGPT 的六模块画像系统什么都记：你的职业、项目、爱好、你上次聊了什么；但 YOLO 的用户坐在自己的 Obsidian vault 里面，而 vault 本身就是一个巨大的知识库，你的日记、项目文档、学习笔记全在那里，我们的 Agent 随时可以用 fs_read 和 fs_search 去查。

所以 YOLO 的记忆不应该去复制 vault 里已有的信息，它应该记的是那些不会自然存在于任何一篇笔记里的东西：

该记	不该记
用户的个人信息（姓名、年龄、身份）	某篇笔记的具体内容
用户和 AI 的交互偏好（语气、格式、禁忌）	项目文档里的技术细节
AI 被纠正过的行为（"不要用破折号"）	用户日记里写过的事
跨会话的任务连续性（"我们上次在做 X"）	vault 里可以搜到的事实性知识
用户反复提及但没落在笔记里的隐性偏好	已经被 Skills 覆盖的程序性知识

RAG 搜索处理的是世界知识，Skills 保存的是程序知识，而 Memory 管理的则是「我们之间的默契」。

二、存储方案：markdown 文档

确定了「该记什么」之后，下一个问题就是「怎么存」。

在正式聊储存方案之前，我们必须要先明确一个前提：YOLO 的记忆内容应当会在每次对话开始时全量注入 system prompt。不做语义检索，不做相关性筛选，整个文件的内容一股脑塞进上下文里。这个决定直接决定了存储方案的设计方向：文件不能太大，格式不能太复杂，内容必须是人和模型都能一眼看懂的。

为什么选全量注入？因为个人助手场景下，记忆条目的量级就不大。50 条记忆大概 1500~2000 tokens，对现在动辄 200K 甚至 1M 的上下文窗口来说完全不值一提。如果为了这点数据量去搞语义匹配和动态召回，那是用高射炮打蚊子，工程复杂度上去了，效果反而可能更差（因为你引入了一个新的失败点：万一该召回的记忆没被召回呢？）。全量注入最大的好处是确定性：AI 每次对话都能看到所有记忆，不会遗漏，不会选择性失忆。

那什么时候需要升级呢？

如果用户的记忆条目超过 100 条（大概 4000+ tokens），可以考虑引入语义匹配。但如果你的个人助手记忆已经膨胀到 100 条以上，更应该做的是让 AI 主动合并和清理冗余条目，而不是给检索层加工作量。

好，回到存储格式本身。

1.储存格式：markdown+列表式

我最早考虑过的方案是 YAML Frontmatter + 三段式结构：属性区存键值对、用 checkbox 当事实库、末尾追加日志。这种方案对通用 chatbot，或者更复杂的商业化 Agent 项目来说还行，但对 YOLO 来讲有点过度设计了。三套东西各自需要不同的解析逻辑，维护起来很烦，而且对用户来说也不直观。

因此，最终我选的方案是纯列表式：一条记忆一行，- 开头，存在 YOLO/memory/global.md 文件里，和 YOLO/skills/ 同级。理由有三个：

注入成本最低。 读记忆文件内容，塞进 <memory> 区块完事，不需要任何解析逻辑。
工具封装最自然。 列表结构天然对应增删改三种操作，插件层可以轻松封装出专门的记忆工具，模型只管传参，格式维护、编号分配这些脏活全由底层处理。
用户一目了然。 打开这个文件就能看到 AI 记住了什么，想删就直接删一行，零学习成本。

2.文件结构：分区 + 编号

纯列表解决了格式问题，但如果 50 条记忆全摊在一起，用户看着会有点乱，AI 在管理时也缺乏抓手。所以在纯列表的基础上，我加了两层组织：分区和编号。

实际的记忆文档长这样：

# User Profile
> Long-term characteristics about the user. Update when user info changes.

- Profile_1: 用户叫xxx，今年 xx 岁，毕业于 xxx
- Profile_2: 用户正在开发 YOLO 插件，这是一个 Obsidian 的 AI 助手

# Preferences
> User's interaction preferences and behavioral patterns. Add when patterns emerge.

- Preference_1: 不喜欢对话结尾追问或反问
- Preference_2: 不要出现"不是……，而是"的句式
- Preference_3: 不要使用破折号

# Other Memory
> Contextual facts and temporary notes. Default category.

- Memory_1: 2025-03-15 开始设计 YOLO 的记忆系统
- Memory_2: 用户习惯深夜工作

三个分区各有定位：

User Profile 放用户的长期特征，身份、背景、正在做的事。这类信息相对稳定，变更频率低。
Preferences 放交互偏好和行为规则。用户纠正 AI 的行为（「不要用破折号」）、表达的格式偏好、沟通风格要求，都归这里。
Other Memory 是默认分区，放不好归类的上下文性信息、临时性事实、带时间标记的事件。AI 添加记忆时如果不确定该放哪个分区，就往这里丢。

每条记忆有一个编号（Profile_1、Preference_3、Memory_2），编号在分区内独立递增，不重用。删掉 Profile_2 之后下一条新增的是 Profile_3，不会回填。这个设计的核心好处是：AI 在更新和删除记忆时只需要指定编号，不需要输出旧的全文内容做匹配。从 memory_update(id="Preference_2", new_content="...") 到定位具体是哪一行，这件事变得确定且廉价。

3.双重记忆：全局 + Per-Assistant

上面展示的文档解决了一个助手记什么、怎么记的问题，但 YOLO 支持多助手配置，用户可能同时拥有一个日常陪伴型助手、一个整理文档的秘书型助手、一个写报告的分析助手。这些助手的角色定位完全不同，它们需要记住的东西也不一样：陪伴助手需要记住你们之间的互动默契，工程助手需要记住你的偏好和项目上下文，分析助手需要记住你的写作风格和报告规范。如果所有记忆都塞在同一个文件里，不同角色的信息会彼此污染，还浪费 token。

所以 YOLO 的记忆系统分两层：全局记忆（Global Memory）和助手记忆（Assistant Memory）。所有记忆文件统一放在 YOLO/memory/ 目录下，全局记忆是 global.md，每个助手的记忆以助手名命名，比如 helper.md、dev-helper.md。

文件结构如下：

YOLO/
├── memory/
│   ├── global.md         ← 全局记忆，所有助手共享
│   ├── helper.md            ← Helper 的专属记忆
│   ├── dev-helper.md      ← 工程助手的专属记忆
│   └── ...

全局 global.md 只放跨助手通用的信息：用户身份、年龄、职业、全局格式偏好（不要破折号、不要追问）这些不管哪个助手都需要知道的东西。分区结构和前面介绍的一样，三个区不变。

Per-Assistant 记忆文件 则放只跟当前助手角色相关的记忆，分区可以由助手自行组织。比如一个工程助手 dev-helper.md 可能长这样：

# Project Context
- Proj_1: YOLO 插件用 TypeScript 开发，基于 Obsidian API
- Proj_2: 记忆系统设计已完成，正在实现工具层

# Code Preferences
- Code_1: 偏好函数式风格
- Code_2: 不要过度抽象，能跑就行

对话开始时，插件把两层记忆合并注入 system prompt：

<memory>
<global>
{global.md 的内容}
</global>

<assistant>
{当前助手记忆文件的内容}
</assistant>
</memory>

用 <global> 和 <assistant> 标签分开，模型能清楚地区分哪些是所有助手都要知道的通用信息，哪些是只属于当前助手的上下文。

有一个边界处理：如果用户只用默认助手（没有自定义 assistant_instructions），就不需要创建 per-assistant 记忆文件，直接退化到单层全局记忆。插件层做个判断就行，对轻度用户零负担。

三、Memory 工具设计

储存方案确定了，那我们的 AI Agent 应该如何操作这些记忆呢？

答案是 Tool Calling。让 AI 通过调用专门的记忆工具来增删改记忆条目，而不是直接用 fs_edit 去改文件。这样做有两个好处：一是插件层可以封装格式维护、编号分配这些脏活，AI 只管传参；二是可以加校验逻辑，防止 AI 把记忆文件写乱。

工具一共三个，先看签名：

memory_add(content: string, category?: string, scope?: 'global' | 'assistant')
  → 在指定分区末尾追加一条记忆，自动分配编号
  → category 默认为 'other'
  → scope 默认为 'assistant'（写到当前助手的记忆文件）
  → scope 为 'global' 时写到 global.md
  → 返回新记忆的 ID（如 "Profile_3"）

memory_update(id: string, new_content: string, scope?: 'global' | 'assistant')
  → 根据 ID 定位并更新记忆内容
  → 保持编号不变，只改文本
  → scope 默认为 'assistant'

memory_delete(id: string, scope?: 'global' | 'assistant')
  → 根据 ID 删除记忆
  → 编号不回收
  → scope 默认为 'assistant'

三个工具都加了 scope 参数来对应双层记忆架构。默认值设成 assistant 是刻意的：日常对话中产生的记忆绝大多数都跟当前助手的角色相关，只有用户基本信息变更（换工作了、改名了、新增了一条全局格式偏好）才需要显式指定 scope: 'global'。

签名本身很简单，没什么好说的。但光有工具不够，更重要的问题是：AI 什么时候该调用它们？怎么调用才不会乱？

触发策略：谁来决定「该记了」？

最偷懒的做法是完全靠模型自觉，在 system prompt 里写一句「当你发现重要信息时请保存记忆」，然后祈祷它的判断力在线。这在目前旗舰 chat 模型上其实也能用，但不够稳定，你可能会碰到两种很典型的翻车：一种是该记的没记，用户说了三遍自己的名字 AI 还是没调用 memory_add；另一种是不该记的疯狂记，每句话都触发一次存储，记忆文件很快变成垃圾场。

当然有的模型实在是比较粪，我作为开发者其实也真的没有办法适配每一个模型的 taste，遑论大家的渠道五花八门的，有的可能是纯净官方 api，有的可能是 Claude code 乃至 kiro 逆向的，还有的可能是直接从 ChatGPT 官网逆向下来的 api，实在是众口难调。

YOLO 的做法是在 system prompt 的角色设定（assistant_instructions）里显式写明记忆行为的规范。具体来说是两条：

「你会主动使用记忆工具来新建/更新你的记忆。」 这是正向引导，告诉模型记忆操作是你的本职工作，不是可选项。
「你会定期删除已经冗余的无用记忆。」 这是反向约束，防止只增不删导致膨胀。

注意，这里没有规定具体的触发条件（比如「每 10 轮检查一次」或「当用户提到个人信息时」），因为这种硬编码规则反而会让模型的行为变得僵硬。实际测试下来，只要在角色设定里把「该记」和「该清理」这两个意识植入了，模型在大多数场景下的判断力是够用的。它会在用户自我介绍时自动存 profile，会在被纠正行为时自动存 preference，也会在发现两条记忆说的是同一件事时主动合并。

去重与冲突：AI 自己判断，还是插件层兜底？

一个很自然的问题：如果 AI 想新增一条记忆，但记忆文件里其实已经有一条语义相近的了，怎么办？

比如记忆里已经有 Profile_1: 用户叫无敌暴龙兽，今年 21 岁，然后用户在新的对话里又提了一嘴自己的年龄，AI 是应该 memory_add 一条新的，还是 memory_update 已有的那条？

YOLO 的答案是：完全交给 AI 判断。 因为前面说过，记忆是全量注入的，AI 在每轮对话里都能看到所有已有记忆。它有足够的信息来决定「这条信息已经存在了，我应该更新而不是新增」。在 system prompt 里补一句「当一条记忆已经过长时，请不要再往里加新的内容了，请新建一条记忆」，就能覆盖绝大多数边界情况。

插件层不做语义去重。原因很简单：要做就得引入 embedding 和相似度计算，工程复杂度直接翻倍，而收益几乎为零。50 条以内的记忆，模型看一眼就知道有没有重复，比任何 cosine similarity 阈值都靠谱。

把上面这些串起来，一次典型的记忆操作流程是这样的：

对话开始，插件读取 memory.md 全文，注入 system prompt 的 <memory> 区块

用户在对话中提到：「对了我最近换工作了，现在在做独立开发」

AI 看到 <memory> 里已有 Profile_2: 用户正在做 XX 项目，判断这条需要更新

AI 调用 memory_update(id="Profile_2", new_content="用户目前是独立开发者")

插件定位到 Profile_2 所在行，替换内容，保存文件

工具返回成功，AI 继续对话，不需要特别告知用户（除非用户主动问「你记住了吗」）

整个过程对用户来说是无感的。如果用户好奇 AI 记了什么，打开 YOLO/memory.md 就能看到，想手动改也随时可以改。

四、记忆在YOLO上下文中的位置

最后，把记忆系统放回 YOLO 的整体上下文构成里看一眼，明确一下它和其他模块的关系：

YOLO 上下文构成：
├── System Prompt（角色设定、行为规范）
├── <memory>（记忆系统 ← 本文主角）
│   ├── <global>（全局记忆，global.md）
│   └── <assistant>（当前助手专属记忆，助手名.md）
├── <available_tools>（工具索引）
├── <available_skills>（技能索引）
├── <custom_instructions>（用户自定义指令）
├── 对话历史
└── 工具调用结果（文件读写、搜索等）

Custom Instructions 是用户手写的静态规则，Skills 是按需加载的程序化能力，Memory 是 AI 在交互中自主积累的动态关系知识。三者各管一摊：Custom Instructions 管「用户要求我怎么做」，Skills 管「我知道怎么做」，Memory 管「我知道你是谁、我们之间发生过什么」。

RAG 搜索处理世界知识，Skills 保存程序知识，Memory 管理的是「我们之间的默契」。

记忆系统是 YOLO 在「理解用户」这件事上迈出的第一步，但远不是终点。YOLO 下一个大版本的重心是 RAG 系统重构，目前的文件搜索能力本质上还是关键词匹配，够用但谈不上聪明，我计划统一 embedding 语义检索与关键词检索的能力，让 AI 在翻 vault 的时候不再只是找到你说的那个词，它会真正理解你在找什么，做出更接近直觉的搜索体验。

再往后则会探索更激进的 Agent 能力，包括 Sub-Agent 架构和 Cron Agent（定时触发的自动化任务）。这两个方向的想象空间在于，它们可以和现有的记忆系统、Skills、RAG 模块深度联动：Sub-Agent 可以在后台持续观察你的 vault 变化，主动更新记忆条目或补全相关笔记；Cron Agent 则能定期执行你设定的任务，比如每周自动整理项目进度、同步日记里的待办事项、甚至根据你的行为模式提前准备好下周的工作计划。这些能力指向的是同一件事：YOLO 不只是你打开 Obsidian 之后主动提问才会回复的对话框，它应该是一个持续运行的、主动的、真正懂你的数字助理。

我们下篇更新日志再见！

YOLO 的 Agent 实现与 Lite Skills 系统

Sun, 01 Mar 2026 00:00:00 GMT

一、技术选型：少即是多

在做 Agent 之前，我当然看了一圈市面上现成的方案。Vercel AI SDK、LangGraph、还有各家模型厂商自己的 Agent SDK，选择很多。但看完之后我反而更坚定了自(ai )研的想法。

原因倒不是什么"它们不够好"或者"场景太特殊适配不了"这种高大上的理由。核心原因很朴素：Agent Loop 这件事本身就没那么复杂，不需要一个重型框架来承载它。

最近大火的 clawdbot（就是那个小龙虾机器人🦞）其实侧面印证了这一点。它的核心 agent 引擎 pı 极其精简，clawdbot 本身则更像一个 cron + Claude Code，但它能接管你电脑上的一切，star 已经飙到几百 K 了。这说明什么？说明 agent 的价值不在于编排框架有多精巧，而在于它能不能可靠地把工具用起来，把事情做完。

回到 YOLO 自己的场景。一个 Agent Loop 的本质是什么？就是一个循环：

把消息发给 LLM
LLM 返回内容，判断有没有 tool call
有的话执行工具，把结果塞回消息列表
回到第 1 步，直到模型觉得"做完了"不再调用工具

就这么简单。你当然可以在这个循环上叠加各种花活：状态机、DAG 编排、定时任务、多 agent 协作、动态规划……但对于 YOLO 来说，一个 Obsidian 插件，用户在笔记库里和 AI 对话、让它帮忙读写文件、整理笔记，这个基本循环就完全够用了。把简单的事情用简单的方式做好，比用复杂的框架做出"看起来很厉害但实际上也就那样"的效果要强得多。

至于 Provider 层和工具层的选型，没什么可纠结的。Provider 层按渠道用官方 SDK（Anthropic SDK、OpenAI SDK 等），总不能自己手写 HTTP 请求去处理流式响应和各种边界情况吧，这属于没苦硬吃。工具协议选 MCP，因为它就是目前事实上的标准规范，没有第二个选择。

所以 YOLO 的技术选型策略可以用一句话概括：编排层自研，接入层用官方 SDK，工具层走 MCP。 自研的部分尽量薄，只做必须自己控制的事情；能用标准方案的地方绝不重复造轮子。

二、Agent Loop 的实现

先放一张整体架构图，后面的内容基本上都是围绕这张图展开的：

一切的起点：三种场景，一个内核

YOLO 里用到 LLM 的地方不止 Agent Chat 一个。Smart Space 和 Quick Ask 需要 LLM，补全和未来的建议&关联文档也需要 LLM。一个很自然的问题是：这么多场景需要各写一套调用逻辑吗？

答案当然是不。YOLO 的做法是所有场景共享同一个单轮执行内核 executeSingleTurn，差异只在于上层的 运行时配置（Profile） 不同：

Quick Ask 等：enableTools=false，maxAutoIterations=1。不需要工具，问一轮就走，追求低延迟。
Agent Chat：工具全开，多轮自动迭代，走完整的 loop。

这就是图里最上面 UI 层拉出两条线但最终汇到同一个 Runtime 的原因。用户体验按场景定制，底层能力是同一套东西，即同核多态。

快路径与完整 Loop 的分流

请求到达 NativeAgentRuntime 之后，第一件事是判断走不走快路径。判断条件很简单：enableTools=false 且 maxAutoIterations<=1。

命中快路径的话，直接在主线程跑一次 AgentLlmTurnExecutor，调 executeSingleTurn 拿到结果就结束。没有工具调用，没有循环，没有 Worker 通信开销。Quick Ask 走的就是这条路，所以它的响应速度（理论上）会明显快于 Agent Chat。

没命中快路径的话，事情就有意思了。Runtime 会通过 postMessage 把任务丢到 Web Worker 里，由 loop-worker.ts 这个状态机来接管。

为什么要用 Web Worker？因为 Obsidian 是个 Electron 应用，Agent Loop 可能要跑好几轮 LLM 请求 + 工具执行，如果在主线程跑这些，UI 会卡。把 loop 的状态转移逻辑扔到后台线程，主线程只负责接收状态更新和渲染，界面就不会顿挫了。

loop-worker 内部是一个状态机，核心就两个相位，不断交替：

llm_request 相位：把当前的消息列表（包括之前的工具执行结果）交给 AgentLlmTurnExecutor，它负责调用 PromptGenerator 编译上下文、注入工具定义、发请求给模型、流式处理响应。模型返回之后，看看有没有 tool calls。没有就结束整个 loop，有的话就进入下一个相位。

tool_phase 相位：拿到 tool calls 之后，交给 AgentToolGateway 去调度执行。工具网关会做权限检查（这个工具允不允许用？是不是高危操作需要用户审批？），然后分发到具体的工具实现（MCP 外部工具或本地文件工具）。工具执行完毕，结果回写到消息列表，然后回到 llm_request 相位，开始下一轮。

就这么来回转，直到模型不再调用工具，或者达到了最大迭代次数。

对照前面技术选型里说的那四步循环：发消息 → 判断 tool call → 执行工具 → 回到第一步。loop-worker 做的事情本质上就是这个，只不过工程上多了流式处理、Worker 通信、权限管控这些必要的基建。

工具网关：可控边界内的自动化

工具网关（AgentToolGateway）是我觉得值得单独说一下的模块。它不只是个"转发器"，而是整个工具执行的安全边界。

首先是 权限过滤。每个 Assistant 配置里定义了允许使用的工具列表，运行时还有额外的策略约束。不在白名单里的工具，模型调了也不会执行。

然后是 审批机制。高风险操作（比如文件删除）默认不会自动执行，而是转入审批态，等用户在 UI 上确认之后才继续。这就是架构图里那个"用户审批（可选）"平行四边形的含义。

最后是 统一的生命周期语义。每个工具调用都有明确的状态：pending → running → success/error/aborted。这些状态既供模型在下一轮推理时参考，也供 UI 展示给用户看。用户能清楚地知道 Agent 做了什么、正在做什么、哪些操作成功了哪些失败了。

这套设计的出发点很明确：Agent 可以自动化，但自动化必须在可控边界内。你不会希望 AI 在你的笔记库里静默删掉一堆文件然后跟你说"整理完了"。

上下文编译

架构图底部有一个紫色的模块 PromptGenerator，它从三个数据源获取信息：Obsidian Vault（当前文件、mention 引用）、RAG 向量检索（隐式召回的相关内容）、以及 Lite Skills（技能文档）。

YOLO 对上下文的处理不是简单地把所有东西拼成一个大字符串塞给模型。PromptGenerator 更像是一个编译器，它要做的是：在有限的 token 预算内，把最有价值的信息组装成结构化的 prompt。

具体来说：

聊天历史有滑动窗口，不会无限制地往上追溯。
当前文件内容过长时会触发摘要或 RAG 降级。
mention 引用（用户通过 @ 显式提及的文件）优先级高于隐式召回。
工具调用的 request 和 response 成组保留，不完整的结果会被过滤掉。
Lite Skills 按 always/lazy 两种模式加载，默认 lazy，不会在首轮就把所有技能文档塞进上下文。

上下文是稀缺资源，这一点在之前的文章里已经讨论过了。PromptGenerator 的职责就是在这个约束下做资源分配，确保模型拿到的信息是"够用且精准"的。

三、Lite Skills：精简后的，更适合黑曜石宝宝体质的 skills

Agent Loop 解决了"AI 能做事"的问题，但光能做事还不够。同样是"帮我整理笔记"，不同场景下整理的方式、输出的结构、工具的调用策略可能完全不一样。你可以每次都在对话里把这些要求说一遍，但这太蠢了。

所以需要 Skills。

关于 Skills 的动机，其实在更早之前就想过了。当时的想法是：Skill 和现有的 Assistant（助手预设）有什么区别？区别在于粒度和组合性。Assistant 是一个完整的"人格"，你选了学术写作助手就不能同时选代码审查助手；Skill 是能力模块，天然支持叠加。一个 Assistant 可以装载多个 Skill，就像一个人可以掌握多种技能。

但当时也意识到一个前置条件：如果 YOLO 只是个纯 chatbot，Skills 模块仍然只是提示词雕花，叫"Skills"未免太寡淡了。Skills 这个词让人联想到的是"能力"，是能做事的。所以我选择先把 Agent Loop 做出来，让 AI 有了工具可用、有了执行能力之后，Skills 才真正有用武之地：它不只是改变 AI 说话的风格，而是能影响 AI 如何思考、如何使用工具、如何完成任务。

现在 Agent Loop 已经就位了，该聊 Lite Skill 的设计了。

为什么叫「Lite」

先说结论：YOLO 的 Lite Skills 是 Anthropic Skills 规范的一个大幅简化版本。

Anthropic 原版的 Skills 是一个（或多个）完整的文件夹，结构可以很复杂：核心的 SKILL.md 负责元数据和操作指令，旁边挂着 scripts/ 放可执行脚本、references/ 放技术参考文档、assets/ 放模板和样例。像官方提供的 docx 处理 Skill，光文件就十几个，Python 脚本、XML 模板、OOXML 规范文档一应俱全。这套设计很强大：脚本封装了确定性操作，分层文档实现了渐进式上下文披露，整个 Skill 就像一个自给自足的微型工具包。

但这套东西做不到全量移植到 Obsidian 里，原因有三个层面。

环境层面：Obsidian 插件运行在 Electron 的渲染进程中，天然没有 shell 执行能力。Claude Code 可以直接跑 bash，所以 Anthropic 原版 Skills 捆绑脚本是合理的，Agent 能直接调起来执行确定性操作。但 YOLO 不行，插件环境里你拿到一个 .py 文件也没法跑。这个平台限制从根上决定了脚本捆绑这条路走不通。

用户层面：YOLO 的用户群体是笔记用户，不是开发者，且 Obsidian 的 vault 本质上是一个 markdown 文件库，往里面塞 .py 和 .xml 既不自然也不优雅。

架构层面：YOLO 的工具能力已经通过 MCP 和本地文件工具提供了，Skill 不需要再额外捆绑脚本来执行确定性操作。确定性的活交给工具层，Skill 只负责告诉 Agent「在什么场景下、按什么策略去调用这些工具」。职责分离得很干净。

所以 YOLO 做了简化：一个 Skill 就是一个 markdown 文件。没有文件夹，没有脚本，没有多级引用。所有信息都写在一个 .md 文件里，用 YAML frontmatter 声明元数据（id、name、description、mode），正文就是给 Agent 的操作指令。Skills 文档会放在 vault 的 YOLO/skills/ 目录下，和你的笔记、日记、项目文档住在一起，用 Obsidian 原生的编辑器就能创建和修改。这就是「Lite」的含义：不是功能阉割，是把 Anthropic 那套为专业开发场景设计的重型结构，适配成了 Obsidian 用户能自然使用的轻量形态。

砍掉的东西和保留的东西一样重要，值得明确列一下：

保留了什么：

元数据常驻 + 正文按需加载的核心架构
always / lazy 两种加载模式
模型可自主生成 skill 的定制能力
双层权限门禁（全局 + Agent 级）

砍掉了什么：

脚本捆绑（确定性操作交给 MCP 工具层处理）
多级文档引用（单文件内用 markdown 章节结构替代）
文件夹式的 Skill 包（一个 .md 文件就是一个 Skill）

一个 Skill 长什么样

在系统内部，每个 Skill 被表示为一个叫 LiteSkillEntry 的轻量结构：

{
  id: string        // 技能唯一标识
  name: string      // 显示名称
  description: string  // 功能描述（注入给模型做判断用）
  mode: 'always' | 'lazy'  // 加载模式
  path: string      // 文件路径
}

对应到实际文件，一个最简单的 Skill 长这样：

---
id: weekly-work-plan
name: Weekly Work Plan
description: Create and manage weekly work plans.
mode: lazy
---

# Weekly Work Plan

## 使用场景
当用户提到「本周安排」「周计划」「工作安排」时激活。

## 操作步骤
1. 检查上周计划的完成情况
2. 将未完成的任务迁移到本周
3. 按优先级整理新的任务列表
...

frontmatter 的解析有一套兜底规则：id 没写就用文件名，name 没写就用 id，description 没写就给个默认值，mode 只要不是明确写了 always 就一律当 lazy 处理。这意味着你甚至可以创建一个只有正文、完全不写 frontmatter 的 markdown 文件扔到 YOLO/skills/ 里，系统也能识别它。当然不推荐这么干，description 写不写直接决定了模型能不能在合适的时候找到这个 Skill。

Skill 的来源有两个：

内置技能，是代码里写死的模板。目前有两个：

obsidian-output-format：规范 Agent 输出 markdown 的格式，默认 always（因为每次对话都需要）
skill-creator：指导用户创建新 Skill 的 meta-skill，默认 lazy

Vault 技能，是用户自己在 YOLO/skills/ 目录下创建的 markdown 文件。系统启动时会扫描这个目录，把所有符合条件的 .md 文件识别为 Skill。

加载策略：always 与 lazy

这是 Lite Skill 系统最核心的设计决策，也是它对「上下文是稀缺资源」这个原则的直接回应。

在之前那篇关于上下文管理的文章里，我详细讨论过 Anthropic Skills 的三阶段加载模型：发现阶段只加载元数据，激活阶段读取完整指令，执行阶段按需加载引用文件。YOLO 的实现把这个模型简化成了两档：

always 模式：技能的完整正文在每次对话开始时就被注入到 system prompt 里。模型不需要主动请求，这些内容始终存在于上下文中。适用于那些「每次对话都大概率用到」的基础性技能，比如输出格式规范。代价是 token 成本固定增加，所以 always 技能不宜太多，内容也不宜太长。

lazy 模式：系统只把技能的 id、name、description 注入到 system prompt 的 <available_skills> 区块里。当模型决定需要某个 lazy 技能时，它会产出一个 open_skill 的工具调用，参数是技能的 id 或 name（至少提供一个）。这个调用走的是标准的工具执行链路：模型产出 tool call → loop worker 进入 tool phase → 工具网关做权限检查 → 路由到本地工具执行器 → 读取技能文件 → 返回完整正文。

返回的内容会作为工具执行结果回写到消息列表里，模型在下一轮推理时就能看到完整的技能指令了。从模型的视角看，这和调用任何其他工具没有区别：它请求了一份资料，系统返回了资料内容，然后它基于这些内容继续工作。

用一个具体的例子来说明这两档的区别。假设你有 10 个 Skill，1 个是 always，9 个是 lazy：

对话开始时，system prompt 里包含：1 个 always 技能的完整正文（假设 2000 tokens）+ 9 个 lazy 技能的元数据摘要（假设每个 50 tokens，共 450 tokens）。总上下文开销约 2450 tokens。
如果把 10 个全设成 always：上下文开销变成 20000 tokens，是前者的 8 倍多。而其中大部分信息在当前对话中根本用不上。
如果用户在对话中提到了「帮我做周计划」，模型会从元数据里识别出 weekly-work-plan 这个 Skill 与当前任务相关，调用 open_skill 拉取完整内容，然后按照里面的指令来执行。

这就是「元数据常驻 + 正文延迟加载」的实际效果：模型始终知道自己有哪些能力可用，但只在真正需要时才付出完整的上下文成本。

权限控制：谁能加载什么

Skill 系统的权限设计是一个「双层门禁」结构：

第一层：全局禁用。在插件设置里可以把某些 Skill 加入禁用列表，被禁用的 Skill 对所有 Assistant 都不可见，从元数据注入和工具调用两个维度同时屏蔽。

第二层：Assistant 级偏好。每个 Assistant 可以单独配置每个 Skill 的启用状态和加载模式。比如你的「学术写作」Assistant 可以启用 citation-format 技能并设为 always，而「日常闲聊」Assistant 则完全不加载这个技能。

两层叠加的优先级是：全局禁用 > Assistant 配置。也就是说，全局禁了的技能，不管 Assistant 怎么设置都不会生效。

在工具调用层面还有一道参数级的校验：即使 open_skill 工具本身可用，模型传入的 id 或 name 也必须命中当前 Assistant 的允许集合，否则调用会被拒绝。这防止了模型通过猜测 id 来加载未授权的技能。比较细节在允许集合的匹配统一做了小写转换，避免大小写差异导致的误判。

这套权限设计的出发点和工具网关是一样的：能力开放但边界可控。用户能精细地管理每个 Assistant 的技能装备，模型不会越权加载不该看到的东西。

四、未来展望

Agent Loop 和 Lite Skills 在 1.5.1 落地之后，YOLO 的 AI 能力算是有了一个能跑起来的底座。但「能跑起来」和「跑得好」之间还有不短的距离，接下来要做的事情大致分三个方向。

首先是工具调用的稳定性与体验。坦率地说，当前版本的工具调用在大多数场景下能正常工作，但还没到「闭着眼睛信任它」的程度。不同模型对 tool call 的格式遵从度参差不齐，有些模型偶尔会产出格式不完整的调用、或者在不该调工具的时候强行调一个。这些边界情况目前靠兜底逻辑在兜，但兜底终究是兜底，不是根治。后续迭代会持续打磨这一块：更精准的错误恢复策略、更清晰的工具执行反馈、以及用户侧更直观的状态展示。目标是让工具调用这件事对用户来说足够透明、足够可预期，而不是一个「大部分时候好使、偶尔抽风」的黑箱。

然后是搜索能力的重构。下一个大版本更新会重点强化搜索工具的效果。现有的 RAG 系统在 Smart Composer 时代就搭好了，当时的设计假设和现在的实际使用方式之间已经积累了不少偏差，是时候做一轮重构了。搜索是 Agent 在知识库场景里最核心的能力之一，模型再聪明，如果检索环节召回的内容不准、不全，后面的推理和操作就是在沙子上盖楼。这次重构的目标是让 Agent 在面对用户的模糊查询时，能更可靠地找到真正相关的内容，而不是返回一堆「关键词命中但语义无关」的结果。

最后，也是更长远的方向：Agent 模块会成为 YOLO 未来所有 AI 能力的基座。现在 Agent Loop + 工具层 + Lite Skills 这套组合已经证明了一件事：给模型一组工具和一套指令，它就能在 Obsidian vault 里完成相当复杂的任务。这个能力不应该被锁死在聊天窗口里。基于这个基座，后续会探索一些更有意思的形态，比如 AI 白板，让模型能在画布上组织和关联信息；比如全新的学习模式，让 Agent 根据你的笔记库内容主动生成复习计划、提出问题、构建知识图谱、帮你制作 anki 卡片和出题刷题。这些功能听起来跨度很大，但底层都是同一套东西：Agent 读取上下文、调用工具、按照 Skill 指令执行任务。差异只在于上层的交互形态和编排方式。

具体能做成什么样，做到什么程度，现在说太多都是画饼。但基座已经在了，剩下的就是在上面一层一层搭。请期待。

最后的最后，YOLO 是一个开源项目，它的上限取决于社区的参与度。

如果你在使用过程中遇到了 bug、发现了不合理的设计、或者觉得某个场景应该被支持但现在还没有，欢迎到 GitHub 上提 issue。如果可以的话，非常感谢大家可以提 PR。issue 告诉我「这里有个问题/需求」，PR 告诉我「这里有个问题/需求，而且我已经修/实现好了」。不用担心改动太小，修一个 typo、补一条边界处理、做一下 i18n 工作，都是实打实的贡献。一个人能搭出基座，但只有社区能把它变成真正好用的东西。

我们下次更新日志再见！

博客｜序（新）

Fri, 06 Feb 2026 00:00:00 GMT

我好像一直没办法停止追问。

最早大概是从书开始的。少年时代单纯地喜欢读东西，什么都读，读到后来发现自己对世界的好奇远远溢出了书页的边界：语言如何塑造认知？秩序如何被建立又如何被瓦解？系统背后的系统是什么？代码能不能替人思考？

问题越问越多，也越问越不好回答。

如果非要给这种倾向找一个出口，大概就是这个博客，而最初的动机其实很朴素：我发现，如果一个想法没有被写下来，它就几乎等于没有发生过。

不是说它不存在——它确实在某个深夜、某次散步、某段代码跑通之后的空隙里闪烁过。但如果不把它固定在文字里，它就会像没存盘的进度一样，在下一次重启后消失得干干净净。人的记忆是不可靠的，尤其是关于"自己曾经怎么想"的记忆。我们总是不自觉地用现在的认知去覆盖过去的判断，然后以为自己一直都是这么想的。

写作，可能就是对抗这种覆盖的方式。

理解以真实为本，但真实本身并不会自动呈现。

真实不是一个静态的、摆在那里等我们去发现的东西，它需要你主动地去观察、去拆解、去用语言把它从混沌中打捞出来；它像是一块需要反复擦拭的镜面，你每多擦一次，就多看清一点，但你永远不确定自己是不是已经擦干净了。

所以这个博客里的内容会显得很杂。

有技术开发日志，记录我怎么从对一个产品的不满出发，一步步把自己的理念落地成代码；有 AI 设计哲学的思考，关于上下文、记忆、注意力这些概念如何从人类认知映射到机器架构；有宏观分析笔记，试图在数据和叙事之间找到那条不那么显眼的因果链；有书评，有人类研究，有对亚文化现象的观察。

它们看起来关联性并不强，但对我来说，它们回应的是同一个问题：这个世界到底是怎么运转的？

技术告诉我系统如何被构建，金融告诉我资源如何被分配，法学与社会学告诉我秩序如何被维持，哲学告诉我以上这些"告诉"本身是否可靠。我没有办法只待在一个领域里——因为任何单一视角都不足以让我满意。

可能这种“什么都写”的博客在互联网上不算讨巧。算法喜欢垂直，读者喜欢标签，而我这里既没有统一的主题，也没有稳定的更新频率。有时候一周写三篇，有时候连着摸一两个月（

但我想，一个人的思考本来就不是按排期生产的。它跟着生活走，跟着困惑走，跟着那些突然击中我的瞬间走。我能做的，只是在它发生的时候，尽量诚实地把它记下来。

持续不断记录，意义自然浮现。

这是我写在博客首页的话，也是我对自己的承诺。我不确定这些文字最终会通向哪里，但我相信，当记录积累到足够的密度，那些散落的点终究会连成某种只属于我的图景。

如果你恰好路过这里，看到了其中某一篇，觉得"嗯，这个人想的东西还挺有意思的"，那对我来说就够了。

这里没有什么宏大的使命宣言。只有一个二十来岁的人，试图在这个过于喧嚣的世界里，为自己的思考留一个安静的、诚实的角落。

欢迎来到时歌的博客。

上下文是稀缺资源｜RAG、Memory、Skills 的设计哲学刍议

Tue, 27 Jan 2026 00:00:00 GMT

在大模型时代，「上下文」这个词被频繁提起，却常常在讨论中被过度简化。我们可以先退后一步，问一个更根本的问题：上下文究竟是什么？

对于人类而言，上下文是我们理解世界时的那层看不见的背景幕布。它是两个老朋友聊天时无需言明的共同经历，是团队讨论项目时每个人脑海中关于前情的默契假设，是你读到这句话时，前面所有文字在你意识中留下的痕迹对当下理解的持续塑造。我们和他人进行的每一次对话、每一项研究、每一段协作，都依赖这种「默示」的共享认知来避免从零开始反复解释同一件事，让思考得以保持连续性和方向感。

对于大模型来说其实也差不多，只是这些概念被具象成了 system prompt、聊天历史、外部工具调用结果，以及各种临时拼接进来的检索信息。所有这些片段共同构成了模型的“工作记忆”：它在多大程度上理解自己现在身处哪一个任务链条、面对的是谁、需要延续的目标是什么，这些都取决于当前被送进上下文窗口的内容。

那么问题来了：既然上下文如此重要，为什么不干脆把所有相关信息都塞进去呢？

答案藏在 Transformer 这个架构的底层设计里。当模型处理一段文本时，它需要让每一个词都去关注上下文中的所有其他词，计算它们之间的关联强度。这种全局注意力机制赋予了模型强大的理解能力，但也埋下了一个代价高昂的伏笔：当上下文长度翻倍时，计算量会翻到四倍；长度增加到十倍，计算量就变成一百倍。

从数学上看，假设输入序列长度为 $n$，每个词被表示为一个 $d$ 维的向量。标准的自注意力需要计算一个 $n \times n$ 的注意力权重矩阵，其中每个元素 $a_{ij}$ 表示第 $i$ 个词对第 $j$ 个词的关注程度：

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

这里 $Q$（查询）、$K$（键）、$V$（值）都是 $n \times d$ 的矩阵。关键在于 $QK^T$ 这一步：两个 $n \times d$ 的矩阵相乘，得到一个 $n \times n$ 的矩阵，计算复杂度为 $O(n^2 \cdot d)$。由于 $d$ 通常是固定的模型超参数，真正随输入规模变化的是 $n^2$ 这一项。

这就是为什么复杂度被称为「二次方」级别。当序列长度 $n$ 从 1000 增长到 10000 时，$n^2$ 从 100 万跃升到 1 亿，计算量增加了整整两个数量级。而存储那个 $n \times n$ 的注意力矩阵同样需要 $O(n^2)$ 的显存，这往往成为实际部署中更早触及的瓶颈。

想象一个圆桌会议：如果只有四个人参加，彼此交流起来轻松自如，每个人只需要关注另外三个人的发言。但当人数增加到四十人，每个人需要同时追踪的对话线索就变成了三十九条，整个房间里的信息交换复杂度呈几何级数攀升。Transformer 面对的正是这样的困境。

这意味着，哪怕硬件算力在持续进步、上下文窗口在不断扩大，我们永远无法通过「暴力堆料」的方式彻底解决问题。把一本五百页的技术手册完整塞进上下文，带来的可能是响应时间从两秒变成二十秒，推理成本从几分钱飙升到几块钱，而模型的注意力反而在信息的海洋中被稀释，重要的细节淹没在无关的噪声里。

正因如此，「如何更好地管理上下文」成为了从2022年12月 ChatGPT 发布以来整个业界在持续攻关探索的主要方向之一：

一方面，我们希望模型在长周期的协作中维持稳定的人设、偏好和目标感，能记住之前的决策和约定；

另一方面，算力与上下文窗口依然有限，生搬硬塞更多文本只会带来成本飙升、干扰增多、推理变钝。真正困难的地方在于，什么该被长期保留，什么只作为一次性线索，什么需要在多轮交互中逐步抽象成结构化的知识与技能。

过去几年，业界对上下文管理的探索当然是卓有成效且进展迅速的，逐渐形成了几条相对清晰的技术路径，主要可以归纳为：

扩大窗口、做检索增强，将更多文档向量化之后按相似度塞回对话
配合少量长期记忆 memory 工具，把用户偏好和基本资料存起来
做特化 subagent，分拆任务复杂度，分而治之管理上下文

图源：香蕉生的

我们将会在下文各个分析其思路。

一、当前业界的几种主流上下文管理方向

1.检索增强生成（RAG）：让模型学会查资料

RAG 的核心思想其实非常朴素：既然上下文窗口装不下所有信息，那就别装了，需要什么再去查。

这个思路模仿的是人类专家的工作方式。一位资深律师不会把所有法条都背在脑子里，但他知道在遇到具体案件时去哪里找到相关的判例和条文。RAG 赋予了大模型类似的能力：当用户提出问题时，系统先从外部知识库中检索出可能相关的文档片段，然后把这些片段和用户的问题一起送进模型，让模型在「有据可查」的前提下生成回答。

RAG 的优势在于它将「知识存储」和「推理能力」解耦了：模型本身不需要记住所有细节，它只需要具备理解和整合信息的能力。知识库可以随时更新、扩展，甚至可以针对不同领域构建专门的知识源，而模型的参数不需要任何改动。

然而 RAG 的局限性也同样明显。检索的质量严重依赖于向量化表示和相似度匹配的准确性，而语义相似并不总是等于逻辑相关。一个用户问「如何处理项目延期」，检索系统可能返回一堆包含「项目」和「延期」关键词的文档，但真正有价值的可能是某次会议纪要中关于资源调配策略的讨论，而这段内容在字面上可能完全没提到「延期」二字。

从原理角度，RAG 本质上是一种「即时查询」的机制，它擅长回答事实性的问题，但难以处理需要长期上下文积累的推理任务。它能告诉你某个API的参数是什么，但很难记住你三天前说过「以后所有接口都要加上日志追踪」这样的持续性约定。

图源：香蕉生的

因此，业界顺理成章地探索出了第二个方向：分层记忆系统。

2.分层记忆系统

此事在 Lapis0x0 大人的博文《浅谈ChatGPT的记忆实现机制兼论工程端记忆设计》中亦有记载

如果说 RAG 是让模型学会查资料，那么记忆系统则是让模型学会「记事情」。

这个方向的设计灵感直接来源于认知科学对人类记忆的研究。心理学家早就发现，人类的记忆并非单一的存储系统，而是由工作记忆、短期记忆和长期记忆等多个子系统协同运作的复杂网络。每个子系统有不同的容量限制、存储时长和提取机制。

映射到AI系统中，这种分层设计就变成了：

工作记忆对应的是当前对话轮次中的即时上下文，它容量最小但访问最快，直接影响模型当前的推理。你刚才说的那句话、你正在编辑的这段代码，都活跃在这个层面。

短期记忆通常覆盖一个会话周期或一个任务阶段。它存储的是「这次我们在讨论什么」「用户刚才提出了哪些要求」这类信息。很多产品中的「对话历史」功能就属于这个层面，但更精细的实现会对历史内容进行摘要和压缩，而非无限塞原始对话记录到上下文（大家的钱包和 GPU 都受不了）。

长期记忆则是跨越会话、跨越任务的持久化存储。它保存的是用户的偏好设定、项目的核心约定、历次协作中提炼出的经验教训。这些信息有的会在每次对话中都被加载，有的会在系统判断其相关时才被调取，具体看各家的实现策略。

分层信息系统的设计好就好在它承认了一个现实：不是所有信息都同等重要，也不是所有信息都需要同等的可访问性。通过将信息分流到不同层级，系统可以在有限的上下文窗口内维持更好的信息密度和相关性。

以 ChatGPT 为例，OpenAI 构建了一套相当精细的用户画像系统：显式保存的记忆条目、隐式提取的行为洞察、响应风格偏好、近期对话摘要，再加上各种交互元数据。这些信息被结构化地组织起来，在每次对话开始时根据语义相关性动态注入到系统提示中。用户看到的是「ChatGPT 记得我喜欢咖啡」，实际发生的是系统在背后偷偷提醒模型「这位用户喜欢咖啡」。

在记忆系统的探索上，市面上有非常多出色的开源项目，例如 LangChain 的 Memory 模块、LlamaIndex 以及专门针对长短期记忆优化的 Mem0 和 Zep 等

记忆系统的设计也是一项非常复杂的系统工程：什么信息应该从短期记忆「固化」到长期记忆？什么时候应该「遗忘」过时的内容？如何在提取记忆时平衡相关性和新鲜度？这些问题目前都还没有标准答案，不同的产品和框架给出了各异的策略。

不过，跳出这些技术细节，从功能定位的角度来看，记忆系统和前面提到的 RAG 其实在解决同一个问题的不同侧面，是一体两面的。RAG 擅长处理世界知识，是那些存在于外部文档、数据库、知识图谱中的客观信息；而记忆系统更擅长处理关系知识，那些在持续交互中积累的、关于「我们之间」的默契和约定。一个成熟的系统往往需要两者协同工作：RAG 告诉模型"这个 API 的参数是什么"，记忆系统告诉模型"用户三天前说过以后所有接口都要加日志追踪"。

无论是 RAG 还是记忆系统，它们本质上都还是在「单个模型」的框架内做优化。当任务复杂度继续上升，当我们需要处理的不再是简单的问答而是多步骤、多领域的协作流程时，另一条路径开始显现出它的价值。

3.子代理架构（Sub-Agent）：通过分工实现上下文隔离

前面两种方法都在试图优化「单个模型如何更好地利用上下文」，而子代理架构则换了一个思路：既然一个模型的上下文有限，那就让多个模型分工合作，每个模型只需要关注自己负责的那部分上下文，即分而治之。

这种设计的灵感来源更像是现代管理学：当一个复杂项目需要处理时，作为一位管理者，你不会让一个人记住所有细节、完成所有任务。更有效的方式是设立不同的角色（专员）——有人负责整体规划，有人专注代码实现，有人处理文档撰写，有人进行质量检查。每个角色只需要掌握自己领域内的深度上下文，通过明确的接口和协议与其他角色协作。

在AI系统中，这就演变成了「主代理 + 多个专业子代理」的架构。主代理负责理解用户意图、分解任务、协调调度；子代理各自专注于特定领域，比如代码生成、文件操作、网络搜索、数据分析等。当主代理判断某个任务需要特定能力时，它将相关的上下文片段传递给对应的子代理，由子代理完成具体工作后返回结果。

在工程实践层面，开源社区已经有不少具有代表性的开源项目。面向基础编排能力的，有 LangGraph 和它的 Swarm 扩展，他们把每个代理抽象成图上的节点，通过状态机和有向图来控制谁在什么时候接过话语权；CerwAI 则是把一组代理组织成一个“crew”，通过角色设定和 Flow 抽象来管理多代理之间的上下文共享与任务分派。

如果从“管理学类比”的角度看，MetaGPT 直接把系统设计成一个小型软件公司，内部有产品经理、架构师、项目经理、开发和测试等不同角色，输入一句需求，就会沿着既定流程完成需求拆解、技术方案、代码实现再到文档输出，非常直观地体现出“每个子代理只掌握本职领域的深度上下文，通过清晰的接口协作”的思想。类似的还有 ChatDev 等项目，它们都把复杂的软件开发拆成若干彼此配合的专员代理，从而在流程上天然形成上下文隔离和失败隔离。

最后，在具体场景里，也有一些项目把子代理架构深扎到某个垂直领域。CAMEL 及其衍生框架把多代理当作研究对象，重点探索“多角色协作如何在复杂任务上表现得更好”，是最早一批系统性做 LLM 多代理实验的社区之一。IDE 的开源编程 Agent 插件 Kilo code 也做的很不错，值得推荐。

这种架构带来的好处是多方面的。首先，每个子代理的上下文可以高度专业化，不会被无关信息干扰。一个专门处理数据库查询的子代理，它的上下文里就只有数据库模式、查询需求和相关的领域知识，不会混入用户偏好设置或项目管理约定。其次，不同子代理可以并行工作，提升整体效率。第三，失败隔离：一个子代理的错误不会污染其他子代理的上下文和状态。

当然，这种架构也引入了新的复杂性。代理之间如何有效通信？主代理如何判断应该调用哪个子代理？任务分解的粒度如何把握？多个子代理的输出如何整合成连贯的最终结果？这些都是工程实现中需要仔细权衡的问题。

二、那么，Skills 是什么？

我们姑且可以把上一节讲的三种路径看成「如何给模型喂上下文」的三种策略，而 Skills 更像是在这些策略之上又抽象出来的一层组织形式。Skills 关心的不是单条对话、单个记忆片段，而是如何把一整套可复用的工作方法固化下来，在需要时再整块挂载进上下文。

在当前业界语境下，Skills 通常指这样的一种能力单元，最早由 Anthropic 提出，它被实现为一个文件夹，里面放着说明书、参考资料，有时还包含脚本；支持Skills 的智能体可以合适的时候把对应 Skills 的内容加载进自己的上下文，把自己暂时变成某个领域的熟练工。

OpenAI 在 Codex 里对 Skills 的定义是：Skills 让团队可以把组织里的经验和流程沉淀成可复用、可共享的工作流，让 Codex 在不同人、不同仓库、不同会话中都能保持一致的行为。每个 Skill 至少有名字、描述和一套说明，Codex（或者别的什么 Agent）默认只把名字和描述注入上下文，只有显式调用时才把完整说明展开；Anthropic 的 Claude Skills 则是把它解释成「写在 Markdown 文件里的超级提示词」，再配上一些参考资料和脚本，让 Claude 像拿到了一本本可以随时翻开的业务手册。

从这些实现里抽象出来，可以把 Skills 看成满足三点的东西：

它是结构化的上下文包（package），是一个有文件结构的小型知识库，核心通常是一份 Skill.md 或 SKILL.md，里面写清楚任务定义、语气风格、操作步骤、注意事项，旁边可以挂各种 PDF、示例模板、脚本等。
它是可复用的流程单元，是程序化的 playbook，强调可重复执行、结果稳定、可以不断迭代；有人把 Skills 类比成团队的 SOP：你把十几二十年的做事方式打包进一个文件夹，让模型每次照着这套做。
它是按需加载的能力扩展。无论是 Codex 的 Skills，还是 Claude Skills，抑或 VS Code / Copilot 里的 Agent Skills，设计上都强调「渐进式暴露」：先只把 Skill 的元信息丢给模型，让它知道「有这么个工具」，只有当当前任务真的需要时，才把完整说明、脚本和资源一点点塞进上下文里。

1.它解决的到底是什么问题？

如果只从产品交互层面看，Skills 解决的是一个很多人已经习惯到麻木的问题：重复说人话。

在 Claude Skills 的介绍里，官方和第三方文章反复举一个例子：你有一套公司内部的写作规范，每次让 AI 写新闻稿、周报、提案前，都要先贴一大段要求；有了 Skill 之后，把这些要求写进 Skill.md，再配上历史范文，之后只要说「帮我写一份本周市场回顾」，模型自己就会加载那套规范，套模板、控语气。VS Code或者各种 AI IDE 里的 Agent Skills 也是类似思路：开发者把测试流程、部署步骤、日志分析方法写成一个技能，Copilot 在需要时调用，省掉反复讲解「我们项目是怎么写单测、怎么发版」这样的口水。

当然，如果只是到这里，那 Skills 看起来和以前的各种 system prompt 套壳助手 & 斜杠预制命令没区别了，都是"把常用指令存起来方便调用"。但如果再往工程架构深究一下，会发现 Skills 真正在处理的是一个更难啃的问题：上下文管理。

在这里，被迫重复说人话只是症状，病根在于用户每次都得把完整的背景信息塞进对话窗口。一份风格指南可能几千字，每轮都贴进去，既麻烦费钱又挤占模型的注意力。Skills 的做法是把 "我具备这项能力"的声明和"这项能力的完整说明"拆开存放，只在确实需要时才展开详细内容，可以显著节省 token，也减轻注意力扩散的问题。这个设计顺便也回应了另外两个长期困扰 AI 应用的问题：

第一，程序性知识的碎片化。RAG 可以查文档，Memory 可以记偏好，Sub-agent 可以分角色，但「如何做事」这类程序性知识常常散落在无数对话、文档和隐性经验里。Skills 提供了一个显式的容器，把流程本身变成 routine：从「记住这件事」变成「记住如何做这件事」。

第二，跨产品、跨团队的一致性问题。Agent Skills 标准刻意强调可移植性：同一套 Skill 文件夹既可以被 Claude 用，也可以被 Copilot 或其他兼容代理加载；企业可以把一套合规检查、品牌规范、风控流程打包，在不同 AI 产品间共享，而不用为每个交互 UI 单独维护一份提示词。

2.一个好的 Skills 应该是什么样的？

前面我们提到，Skill 本质上是一个具备文件结构的小型知识库。它的核心是一份 SKILL.md 文件，用于记录元数据并指导 Agent 如何执行特定任务；除此之外，还可以包含脚本、模板、参考文档等辅助资源。一个典型的 Skill 文件夹结构如下：

my-skill/
├── SKILL.md          # 必需：元数据 + 操作指令
├── scripts/          # 可选：可执行的代码脚本
├── references/       # 可选：参考文档
└── assets/           # 可选：模板、样例资源

在实际执行中，Skills 采用渐进式信息呈现机制来实现高效的上下文管理：

发现阶段：启动时，Agent 仅加载各技能的名称与简短描述。这一阶段的上下文开销极低，只包含判断技能适用性的必要信息。
激活阶段：当用户的任务需求与某项技能的描述匹配时，Agent 将完整的 SKILL.md 载入上下文，获取详细的操作指令。
执行阶段：Agent 遵循指令逐步执行，按需加载引用文件或调用捆绑的代码脚本。

这种"按需加载"的设计意味着：你可以注册数百项技能，而实际占用的上下文窗口始终保持精简。

光看理论结构可能还是有点抽象，不如我们拆解一个真实案例。以下是 Anthropic 官方提供的 docx 文件处理 Skill，它演示了一个成熟 Skill 的典型写法。

这个 Skill 的文件结构如下：

docx/
├── SKILL.md # 核心指令文件（197行）
├── LICENSE.txt # 许可协议
├── docx-js.md # docx-js 库详细文档
├── ooxml.md # OOXML 操作详细文档
├── scripts/
│ ├── document.py # Python 文档操作库
│ ├── utilities.py # 工具函数
│ └── templates/ # XML 模板文件
│ ├── comments.xml
│ ├── commentsExtended.xml
│ └── ...
└── ooxml/
└── scripts/
├── unpack.py # 解包 docx 文件
├── pack.py # 打包 docx 文件
└── validate.py # 验证文档结构

还挺复杂的吼（

让我们先看 SKILL.md 的 YAML 头部：

---
name: docx

description: "Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. When Claude needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks"

license: Proprietary. LICENSE.txt has complete terms
---

description 字段是整个 Skill 的索引，在 Agent 启动时，所有已安装的 Skills 的 name 和 description 都会被加载到上下文中，但 SKILL.md 的正文内容此时还没有被读取。

如果你有 20 个 Skills，每个 description 平均 100 tokens，那么启动成本只有 2000 tokens
相比之下，如果直接加载所有 Skills 的完整内容（平均每个 5000 tokens），启动成本将高达 100,000 tokens

在实践中，Agent 会根据用户的任务需求，匹配 description 来决定是否激活某个 Skill。只有当 Agent 判断"用户想要处理 .docx 文件"时，才会完整读取这个 SKILL.md 的正文部分。

2.1 决策树式的工作流指导

进入 SKILL.md 的正文部分，我们会看到一个清晰的决策树结构：

## Workflow Decision Tree

### Reading/Analyzing Content
Use "Text extraction" or "Raw XML access" sections below

### Creating New Document
Use "Creating a new Word document" workflow

### Editing Existing Document
- **Your own document + simple changes**
Use "Basic OOXML editing" workflow
- **Someone else's document**
Use **"Redlining workflow"** (recommended default)
- **Legal, academic, business, or government docs**
Use **"Redlining workflow"** (required)

这个设计体现了 Skill 的第一个核心原则：适度的自由度控制。对于"阅读文档"这种相对简单的任务，Skill 只提供了工具推荐（用 pandoc 转 markdown），给 Agent 较高的自由度；但对于"编辑文档"这种容易出错的复杂任务，Skill 明确规定了不同场景下应该使用的工作流，将自由度降低到最小，确保操作的可靠性。

正如 skill-creator 这个 meta-skill 中所说：

Match the level of specificity to the task's fragility and variability: High freedom (text-based instructions): Use when multiple approaches are valid, decisions depend on context, or heuristics guide the approach. Low freedom (specific scripts, few parameters): Use when operations are fragile and error-prone, consistency is critical, or a specific sequence must be followed.

将具体程度与任务的脆弱性和可变性相匹配： 高自由度（基于文本的指令）：当多种方法均有效、决策取决于语境或由启发式方法指导时使用。 低自由度（特定的脚本，参数较少）：当操作脆弱且易错、一致性至关重要或必须遵循特定顺序时使用。

2.2 分层文档引用

SKILL.md中还有这样的指令：

### Creating New Document
1. **MANDATORY - READ ENTIRE FILE**: Read [`docx-js.md`](docx-js.md)
(~500 lines) completely from start to finish.

这里引入了 Skill 的第二层加载机制：reference 文件。

docx-js.md 是一个详细的技术参考文档，包含了使用 docx-js 库创建 Word 文档的完整 API 说明和示例代码。它有 500 行左右，如果一开始就加载到上下文中，会占用大量 tokens；但如果不提供这些信息，Agent 又无法正确使用这个库。Skills 的解决方案是：在 SKILL.md 中只保留"什么时候需要读什么文档"的导航信息，具体的技术细节放在单独的 reference 文件中。 只有当 Agent 真正需要创建文档时，才会去读取 docx-js.md。

这种分层设计的核心思想就是渐进式上下文披露，将“能力的声明”和“能力的细节”在原本已经模块化的前提下进一步解耦，使得一个 Skill 具备复杂、多样的能力，同时保持较低的上下文开销。

2.3 脚本捆绑：将确定性操作封装到代码中

在 docx skill 的文件结构中，我们看到了 scripts/ 目录，里面包含了多个 Python 脚本。让我们看看这些脚本的作用：


# scripts/document.py 的部分代码

class Document:

"""Library for working with Word documents: comments, tracked changes, and editing."""

def add_comment(self, start, end, text):

"""Add a comment to the document"""

# ... 复杂的 XML 操作逻辑

def suggest_deletion(self, node):

"""Suggest deletion with tracked changes"""

# ... 精确的 OOXML 标记插入

这些脚本解决的问题是：某些操作太容易出错，不应该让 LLM 每次都从头生成代码。

想象一下，如果没有这些脚本，每次 Agent 需要在 Word 文档中添加批注时，都要：

解析 OOXML 的 XML 结构
生成符合规范的 <w:comment> 元素
在正确的位置插入引用标记
更新 comments.xml 文件
确保所有 ID 不冲突

这个过程有太多细节需要处理，LLM 很容易在某个环节出错。但有了 document.py 提供的 add_comment() 方法，Agent 只需要调用一个函数就能可靠地完成操作。

这就是 Skill 的第三个核心能力：通过脚本封装提供确定性保证。

此外，这个 Skill 还使用了工作流拆分、验证闭环和提供最佳实践指导等高级 prompt 方法，但我懒得写了，此处暂且不表。

3.Skills 的设计哲学

通过分析 Anthropic 的 Skills 实现，我们可以提炼出几个核心的设计哲学：

其一，上下文是公共资源。

在 skill-creator 这个 meta-skill 中，有一段话让人印象深刻：

The context window is a public good. Skills share the context window with everything else Claude needs: system prompt, conversation history, other Skills' metadata, and the actual user request. Default assumption: Claude is already very smart. Only add context Claude doesn't already have. Challenge each piece of information: "Does Claude really need this explanation?" and "Does this paragraph justify its token cost?"

上下文窗口是一种公共资源。 技能与 Claude 所需的其他所有内容共享上下文窗口：系统提示词、对话历史、其他技能的元数据以及实际的用户请求。 默认假设：Claude 已经非常聪明。 仅添加 Claude 尚未掌握的内容。质疑每一条信息：“Claude 真的需要这个解释吗？”以及“这段文字的价值是否对得起它的 Token 开销？”

即，我们应当把上下文当做稀缺的公共资源来精心管理；这意味着：

不要重复 Claude 已经知道的东西。Claude 已经知道什么是 JSON、什么是 HTTP 请求，你不需要在 Skill 里解释这些基础概念。
用例子代替解释。一个好的代码示例可能比 100 字的描述更节省 tokens，也更容易理解。
分层披露，延迟加载。只在真正需要时才加载详细信息。
定期审查和精简。随着模型能力的提升，一些原本需要的说明可能已经不再必要。

第二，自由度是根据任务脆弱性动态调整的。

我们在 docx skill 中看到了这种设计：

对于"读取文档"这种低风险操作，只提供工具建议，给 Claude 高度自由
对于"添加修订标记"这种高风险操作，提供详细的步骤和示例，严格限制自由度

Think of Claude as exploring a path: a narrow bridge with cliffs needs specific guardrails (low freedom), while an open field allows many routes (high freedom).

这个比喻很有趣，在 Skills 的设计中脆弱的操作（如 OOXML 修改）需要"窄桥"，需要我们提供脚本、详细步骤、示例代码；而灵活的任务（如文档内容分析）需要"开阔地"：只提供目标和工具，让 Claude 自主决策。

其三，Skills 不是文档，是操作手册。

一个常见的误区是把 Skill 当作"用户手册"或"API 文档"来写。但 Anthropic 的 Skills 明确强调：

A skill should only contain the information needed for an AI agent to do the job at hand. It should not contain auxiliary context about the process that went into creating it, setup and testing procedures, user-facing documentation, etc.

也就是说：

❌ 不要写 README.md 解释这个 Skill 是干什么的（那是给人看的）
❌ 不要写 CHANGELOG.md 记录版本历史（AI 不关心历史）
❌ 不要写 INSTALLATION_GUIDE.md 解释如何安装（那是部署阶段的事）
✅ 只写 SKILL.md，里面只放"如何完成任务"的操作指令

这种"极简主义"的设计哲学，确保了 Skills 的纯粹性：它是给 AI 的 playbook，不是给人的说明书。

其四，好的 Skills 是从真实使用中迭代出来的。

skill-creator 中的流程设计很有启发性：


## Skill Creation Process

1. Understand the skill with concrete examples
2. Plan reusable skill contents (scripts, references, assets)
3. Initialize the skill (run init_skill.py)
4. Edit the skill (implement resources and write SKILL.md)
5. Package the skill (run package_skill.py)
6. **Iterate based on real usage**

最后一步"基于真实使用迭代"被单独列出，强调了一个重要观点：Skills 不是设计出来的,是用出来的。

只有在真实场景中使用 Skill，你才能发现哪些说明其实是多余的、哪些步骤容易出错需要更详细的指导、哪些操作应该封装成脚本和哪些参考文档应该拆分或合并。

这种"持续迭代"的理念，让 Skills 成为一个活的、不断进化的知识库，而不是一次性写完就束之高阁的静态文档。

三、上下文管理的未来图景

目前我们讨论的所有方案，无论是RAG的知识库、Memory的记忆条目，还是Skills的能力包，本质上都是人类预先设计好，AI被动执行的模式。人类决定什么该被记住、什么该被检索、什么流程该被封装成Skill。

但如果我们观察人类专家是如何积累能力的，会发现：专家的技能不是被"配置"出来的，而是在实践中涌现出来的。一个资深律师不会先背诵完所有SOP再开始工作，而是在处理一个又一个案件的过程中，逐渐提炼出自己的工作方法。

这指向了上下文管理的下一个演化方向：Agent能否从交互中自主习得新的Skills？ 当一个Agent反复处理类似的任务，它能否自己识别出"这是一个值得固化的流程"，然后自动生成对应的SKILL.md？

一些前沿探索已经在触碰这个边界。

早在三年前，Voyager 项目就已让Agent在Minecraft中通过代码库的形式积累可复用的技能；一些研究者开始尝试让LLM从对话历史中自动提取"程序性知识"，并将其结构化为可复用的模块；在 Yunjue-Agent中，我们也可以看到 Agent 在复杂任务中完全可以自己制造一大批 Skills 工具然后进一步螺旋升天自我强化去解题，可以像人那样持续学习，而迭代速度则远快于人类……

把视野拉远一点，我们会发现上下文管理这件事正在发生新的方法论革命。最早期的做法是"塞"，把所有可能相关的信息一股脑塞进提示词里，然后祈祷模型能从中找到有用的部分；后来演变成"取"，通过 RAG 和记忆系统，在需要时精准提取相关片段；现在 Skills 代表的是"挂载"，把预先打包好的能力模块按需加载；而未来的方向很可能是"生长"，让 Agent 在持续交互中自发地积累、提炼、更新自己的能力库。

当我们讨论"管理上下文"的时候，本质上是在讨论如何让模型在有限的注意力资源下，把认知焦点放在最关键的地方。RAG 解决的是"世界知识的焦点"问题，Memory 解决的是"关系知识的焦点"问题，Skills 解决的是"程序知识的焦点"问题，而子代理架构则是通过分工把复杂任务拆解成多个更容易聚焦的子问题。

从这个角度看，未来的上下文管理系统很可能会呈现一种更加有机的形态。想象一个 Agent，它的能力库像一棵不断生长的树：每次成功完成一个复杂任务，它都会把其中可复用的部分萃取出来，形成新的枝叶；那些长期不被调用的能力会逐渐休眠，被压缩成更紧凑的索引；而那些频繁使用的核心技能则会被反复打磨，变得越来越精炼高效。这棵树不需要人类园丁每天修剪，它自己知道哪些枝条该保留、哪些该剪去、哪些该合并。

其实目前 gpt5.2codex 已经有点这种味道了，每一轮交互模型都会自动压缩上下文，舍弃掉哪些不必要的冗余信息，虽然我们尚不知道它是如何实现的

当然，这幅图景目前还只是一种可能性，而非现实。在真正落地之前，还有大量的技术挑战需要攻克：如何让模型可靠地识别"值得固化"的模式？如何防止自动生成的 Skills 质量退化或相互冲突？如何在保持灵活性的同时确保行为的一致性和可预测性？这些问题都没有现成的答案。

但有一点是确定的：在模型能力不断提升、上下文窗口持续扩大的今天，"如何更好地管理上下文"这个问题并没有变得更简单，反而变得更加复杂更加关键。

无论是对人类还是对AI而言，能够在信息的洪流中准确地知道"现在该关注什么"，才是一切有效协作的前提。

本文探索的 Anthropic Skills 仓库：https://github.com/anthropics/skills

Agent Skills 规范：https://agentskills.io

YOLO 开发日志（二）：Tab 补全设计

Sat, 27 Dec 2025 00:00:00 GMT

注：YOLO 最初的 Tab 补全功能非常不完善，1.4.10里的 tab 补全更新很大程度上是参考了obsidian-copilot-auto-completion 的思路与功能设计，向开发者致敬！

::github{repo="j0rd1smit/obsidian-copilot-auto-completion"}

首先，我们为什么需要 Tab 补全呢？

我认为，从笔记软件设计的角度出发，Tab 补全的核心价值就在于「减少打断」。当我们在写作时，思维是流动的，任何需要我们停下来思考「接下来该怎么表达」的瞬间都会增添认知负担。传统的 AI 写作助手（和 yolo 的其他模块设计）都需要你主动发起对话、等待响应、然后复制粘贴结果，而这个过程显然会打断写作的心流状态。

Tab 补全则不同，它会在你书写的间隙悄然出现，用淡灰色的幽灵文本提示可能的方向。满意就按 Tab 接受，不满意就继续打字，补全提示自动消失。整个交互过程非常的「轻」，几乎不会占用用户额外的注意力资源。

Copilot auto completion 的设计哲学

在重新设计 YOLO 的 Tab 补全时，我从 obsidian-copilot-auto-completion 中汲取了不少灵感。这里记录一下他们的核心设计思路，以及我做出的调整。

1.提示词设计：掩码替代任务

他们的提示词设计很有意思，将补全任务重新表述为「掩码替换」任务，系统提示词如下：

Your job is to predict the most logical text that should be written at the location of the <mask/>.
Your answer can be either code, a single word, or multiple sentences.
Your answer must be in the same language as the text that is already there.
Your response must have the following format:
THOUGHT: here, you reason about the answer; use the 80/20 principle to be brief.
LANGUAGE: here, you write the language of your answer, e.g. English, Python, Dutch, etc.
ANSWER: here, you write the text that should be at the location of <mask/>.

上下文则以 <truncated_text_before_cursor> <mask/> <truncated_text_after_cursor> 的格式传递给模型。举个例子：

Weighted average of (sequence) elements, with the weights dynamically computed based on an input query and elements' keys. 

The attention weight $a_i$ is calculated as follows:
$$
<mask/>
$$

In this formula we have the following components:
- Value: For each element, we have a feature vector per element we want to average over.
- Score function  $f_{score}(key, query)$: uses the queries and keys to calculate the weights per value. (Typically a simple similarity metric or MLP.)
- Attention weight $\alpha_i$: the amount of attention to put on value $i$.

这种设计的好处在于：模型不仅能看到光标前的内容，还能参考光标后的上下文来生成更贴合语境的补全。不过，以目前模型的能力，我觉得强制输出 THOUGHT 和 LANGUAGE 有些冗余了。所以我简化了提示词：

Your job is to predict the most logical text that should be written at the location of the <mask/>. Your answer can be either code, a single word, or multiple sentences. Your answer must be in the same language as the text that is already there. Your response must have the following format: 
ANSWER: here, you write the text that should be at the location of <mask/>.

程序只需识别 ANSWER: 之后的内容即可，既减少了 token 消耗，响应也更快。

2.触发机制

相比之前 YOLO 「停止输入 N 秒后触发」的粗放策略，Auto Completion 采用了更精细的触发器设计。

插件内置了多种触发场景：

句子结束：. ! ?
换行符：\n
列表或任务项：如 - 或 - [ ] 之后
等等

在此基础上，用户可以编辑、移除默认触发器，或添加自定义触发器。每个触发器支持两种匹配模式：

字符串匹配：检查光标前的文本是否以该字符串结尾
正则表达式匹配：检查光标前的文本是否匹配该正则

YOLO的设计思路

YOLO 的 Tab 补全在继承 Auto Completion 核心理念的基础上，做了一些调整和扩展。

提示词：保留掩码，开放约束

YOLO 保留了掩码替代任务的核心思路，但做了两处改动；首先是简化输出格式。现代模型已经足够聪明，不需要强制输出 THOUGHT 和 LANGUAGE 字段，直接要求输出 ANSWER: 即可。程序解析时只需找到这个标记，提取后面的内容：


const parseMaskedAnswer = (raw: string): string => {

const normalized = raw.trim()

const markerIndex = normalized.toLowerCase().indexOf('answer:')

if (markerIndex === -1) return normalized

return normalized.slice(markerIndex + 'answer:'.length).trim()

}

其次是引入约束占位符 {{tab_completion_constraints}}。用户可以在设置中填写自定义规则，比如「不要使用 emoji」「保持简洁」「用正式语气」等，这些规则会被注入到系统提示词中。

触发机制：继承与本地化

YOLO 完整继承了 Auto Completion 的触发器架构。默认配置中，除了换行符和列表项这些通用触发器外，还增加了中文逗号 ， 和中文冒号 ： 的支持，毕竟 YOLO 的主要用户群体（也就是我）是中文用户。

TAB 补全的触发机制是遍历所有启用的触发器，检查光标前的文本是否匹配。字符串类型的触发器用 endsWith 判断，正则类型的用 test 判断。用户可以在设置中自由编辑、禁用或添加触发器，实现完全的个性化控制。

上下文处理：智能边界检测

这是 YOLO 相对于 Auto Completion 的另一个改进：在提取上下文时，YOLO 不会简单地截取固定长度的文本，而是会识别文档结构边界。默认的上下文范围是 4000 字符，按 4:1 的比例分配给前文和后文（3200 + 800）。这个比例的考量是：前文对于理解当前写作意图更重要，而后文主要用于确保补全内容与后续段落衔接自然。

在此基础上，YOLO 引入了后文边界检测，程序会识别段落分隔（连续两个换行）、标题、列表、引用块、代码块等 Markdown 结构。一旦遇到这些边界，就会截断后文上下文。这样做的好处是：模型看到的后文更加「干净」，不会被无关的段落干扰。比如你正在写一个段落的中间部分，模型不需要看到下一个章节的内容。


const boundaryPatterns = [

/^#{1,6}\s/, // 标题

/^-\s+\[[ xX]\]\s+/, // 任务列表

/^[-*+]\s+/, // 无序列表

/^\d+\.\s+/, // 有序列表

/^>\s+/, // 引用块

/^```/, // 代码块

]

写在最后

回顾这次 Tab 补全的重构，其核心思路很简单：让 AI 辅助写作可以可靠地回归「辅助」的本质。

YOLO 的其他功能和传统的 AI 写作工具总是试图抢夺用户的注意力——弹窗、对话框、复制粘贴，每一步都在提醒用户「嘿，我是 AI，我在帮你」；但在 tab 补全的使用场景下，ai 应该是隐形的，在用户需要时出现，不需要时消失，全程不打扰用户的思考节奏：淡灰色的幽灵文本悄悄浮现，一个 Tab 键决定去留。

当然，目前的实现还有很多可以优化的空间。比如触发时机的智能化（能否根据写作速度动态调整？）、补全内容的多样性（能否提供多个候选项？）、以及与其他 YOLO 模块的联动（能否结合知识库做更精准的补全？）。这些都是后续值得探索的方向。

感谢 obsidian-copilot-auto-completion 提供的灵感，站在前人的肩膀上确实能看得更远。如果你在使用 YOLO 的 Tab 补全功能时有任何想法或建议，欢迎反馈。毕竟一个人的使用场景终究有限，而好的工具是在真实需求中打磨出来的。

下一篇日志，我可能会分析一下目前主流的 agent loop 的实现方式与架构，以及 YOLO 在这方面的探索。agent loop 是当下 AI 应用开发中相当热门的话题，从 LangChain 到 BMAD，各种框架层出不穷，但说实话，很多实现都过于复杂，把简单的事情搞得晦涩难懂。

我想从一个更务实的角度来拆解这个问题：一个好用的 agent loop 到底需要什么？工具调用、记忆管理、错误恢复、任务拆解……这些听起来高大上的概念，落到代码里其实就是几个核心的设计决策。YOLO 作为一个 Obsidian 插件，场景相对垂直，反而有机会避开那些「为了通用而通用」的设计陷阱，做一些更贴合实际写作场景的尝试。

不过这个话题展开起来内容不少，今天就先写到这里。有兴趣的朋友可以先看看 Anthropic 的 Building effective agents 这篇文章，写得非常扎实，是我目前看到的对 agent 设计讲解最清晰的文章之一。

YOLO 开发日志（一）：为什么要开发 YOLO

Sun, 05 Oct 2025 00:00:00 GMT

首先，你可能会好奇，为什么这个项目要叫 YOLO（You Orchestrate, LLM Operates）？

其实后面那串全称是我先射箭再画靶子硬凑出来的（）

主要还是因为——YOLO这个名字确实很好玩啊！而且，Trae 的 Agent 模式也叫 yolo，那个深度学习必学的视觉模型也叫 yolo ，我直接neta过来，岂不是从最开始就降低了教育用户、培养用户心智的成本！

我可太聪明了.jpg

事情其实是这样的：我最开始还是Smart Composer的忠实用户，但很快我就有点忍受不了它了。

是的，我知道Obsidian用户个个都是精通coding的工程师型全能码农，用户用不舒服了会自己跑会自己去fork改代码的，插件写的比较复杂也是因为geek们喜欢一切尽在掌握。

但我总还是觉得，作为一款AI插件，应该是有理想的，要尽量的用户友好，配置上不要那么反直觉，支持 i18n 多语言切换也该是标配……

于是，我在六月份给 Smart Composer 提了一份自定义助手（custom agent）的PR，不过也许是我写得太烂，也许是维护者太忙，导致好几个月我的PR一直都没啥进展（尽管SC的主要维护者说要尽快看看）

终于，我忍不了了。

我决定自己动手，fork Smart Composer，照着我的理念彻底魔改一番。

所以，就有了你现在看到的 YOLO。

::github{repo="Lapis0x0/obsidian-yolo"}

这里要专门感谢 Windsurf 里的 Claude 4.1 opus、GPT5 medium 和 Claude 4 sonnet 老师，没有你们就没有 YOLO。

YOLO的愿景是什么？

市面上已经有很多 AI 对话插件了，那些前辈们在 ai 插件领域方面的探索是令人敬佩的，没有他们的探索/基建就没有现在的 YOLO。

但在我看来，仅仅只是把聊天框塞到聊天框，还远没有发挥出大语言模型在知识管理领域真正的潜力。

我们使用 Obsidian 的核心目的是什么？

是为了管理、连接、重构我们原本的知识体系，是为了让我们所记录的段落可以真正被内化到我们的大脑中。

YOLO 想要做的，就是让 LLM 成为你知识管理的「第二大脑」—— LLM 可以做的绝不仅仅是简单地回答问题，它们可以主动帮你梳理思路、建立连接、激发灵感；LLM 驱动的 Agent 可以在笔记后台帮你处理各种重复性的打标、总结、搜集信息的活动，它还可以成为你的私人教师/投研助理/学术搭档……

正是因为 LLM 具有这样的潜力，所以我不希望它仅仅是一个需要你手动调用的工具，而是能够智能地融入你的知识工作流，成为你思维过程的延伸。

想象一下：当你正在写一篇学术论文时，YOLO 可以自动扫描你的文献笔记，帮你归纳不同研究间的异同，甚至生成初步的综述草稿；当你整理日常记录时，它能够识别出潜在的主题关联，并建议你将相关笔记进行合并或建立双向链接；当你陷入创作瓶颈时，它能够从你的过往笔记中挖掘出隐藏的灵感线索，帮你重构思考路径。

YOLO 的设计目标，就是让这些场景变得简单、自然，可以以一个相对较低的成本进行人机协同，让 LLM 成为我们知识探求中的好伙伴。

我希望 AI 可以真正理解我们的知识结构和工作习惯，可以在需要的时候恰到好处地提供帮助，而不是频繁打断你的心流状态。比如，通过设置自动化的 Agent 任务，你可以让 YOLO 在后台定期整理未分类的笔记、提取关键信息生成摘要，或是根据你设定的规则自动打上标签——这些原本繁琐的操作，现在都可以交给 LLM 悄然完成。

在未来的版本中，我计划参考 Claude code、kilo 等业内极为优秀和值得敬佩的先行者们的思路，在 Obsidian 里实现一个基础、灵活且通用的 Agent 框架，并在这个框架基础上去实现一些很有趣的想法：如比 Notebooklm 更灵活的学习模式，思维画布式的头脑风暴界面，多 AI 交互式写作、讨论的大模型圆桌会议等等。

我相信，当人类创造力与AI能力真正融合时，我们能创造出的价值将超乎想象。

如果你也同样拥有对创作流程的强迫症 —— 如果你也一样在 Obsidian 里混迹多年却始终觉得AI 写作插件少了点什么 —— 那么，欢迎来试试 YOLO，说不定这里会是你想找的答案。

我们下篇日志再见 :)

宏观分析师笔记（一）：从宏观叙事到量化因子

Wed, 01 Oct 2025 00:00:00 GMT

我们必须要警惕任何先入为主的偏见

ta们不配讲理｜浅谈现代思潮对立中的去人性化机制

Sat, 13 Sep 2025 00:00:00 GMT

当标签取代了面孔，我们便失去了看见人的能力，也失去了对话的可能

“我们”的偶像与“我”的英雄｜从时代少年团看两性情动结构的分野与融合

Sat, 13 Sep 2025 00:00:00 GMT

在情感被规训、欲望被商品化的时代，我们为何仍愿相信偶像？

开发随笔：一个简单的 Todo MCP，和一次关于减法的开发实践

Mon, 01 Sep 2025 00:00:00 GMT

少即是多，小步快跑

未齐之齐：DeepSeek在年初的爆火似乎佐证了大家喜欢来点狠的

Mon, 18 Aug 2025 00:00:00 GMT

日月出矣，而爝火不息；其于光也，不亦难乎？

齐之未齐：浅谈gpt-oss-20b-base与对齐税

Sun, 17 Aug 2025 00:00:00 GMT

基础模型 = 既糊弄又高效的灵光一现 + AI良助

从个人书架到电商项目：我如何将飞书多维表格打造成一个真正的无头 CMS

Mon, 11 Aug 2025 00:00:00 GMT

记录了架构设计、相关代码与改进思路

MaskPark｜N号房，灰犀牛，兼费米估算我国的偷拍消费人群

Sun, 03 Aug 2025 00:00:00 GMT

哪怕光芒微弱，也比假装黑暗不存在强得多

基于 Astro&Fuwari 主题博客的页面加密功能研究

Thu, 31 Jul 2025 00:00:00 GMT

讲解博客的加密思路和具体源码

何以为金：比特币的技术-价值-治理共生体系

Wed, 30 Jul 2025 00:00:00 GMT

本文主要浅度过一遍比特币的技术逻辑，和价值形成的过程，为未来USDT&稳定币&央行的研究打下基础。

马蹄下的朝堂：安史之乱后唐帝国的缰绳与草原的账单

Mon, 21 Jul 2025 00:00:00 GMT

为了保住帝国，它不得不牺牲帝国的根本；而一旦牺牲了根本，所保住的，也就不再是帝国了

为权力勘定边界：从四要件与三阶层看刑法评价体系的功能转型

Thu, 17 Jul 2025 00:00:00 GMT

国家治理体系与治理能力现代化的必由之路

风向专栏导读：正在撕裂的，与正在形成的

Wed, 16 Jul 2025 00:00:00 GMT

风，已然起于青萍之末，并将愈演愈烈。

风向｜大连工业大学李某开除事件

Wed, 16 Jul 2025 00:00:00 GMT

鬣狗一般的媒体，与立场驱动的思潮演变

关于酒馆SillyTavern所代表的伴侣模型系统的一些小思考

Sat, 12 Jul 2025 00:00:00 GMT

关于上下文，与AI伴侣系统设计的一些小思考，小想法

VPS快速部署酒馆（SillyTavern）教程

Sat, 12 Jul 2025 00:00:00 GMT

挺好一chatbot项目，优点是可拓展性极强，缺点是臃肿

宗教研究 01｜制度大于真理：早期基督教的边界建构

Fri, 04 Jul 2025 00:00:00 GMT

制度未必通向真理，但每一个真理的诞生，都离不开制度的边界

我们无法修好彼此：城市、疏离与机器人之梦

Tue, 24 Jun 2025 00:00:00 GMT

我们竟是如此的孤独，又是如此的自私和善于自我欺骗

再论米氮平

Tue, 24 Jun 2025 00:00:00 GMT

再探讨米氮平的药理特性与依赖性机制

闪电注意力的又一次胜利：Minimax-M1 技术报告浅读

Sat, 21 Jun 2025 00:00:00 GMT

工程上的又一次胜利，商业实践中难言满意。

钱从哪来，由谁决定：特朗普总统与美联储的权力博弈 & 兼论CBDC与稳定币

Fri, 20 Jun 2025 00:00:00 GMT

钱从哪来，由谁决定？新王当立，权柄归一

在 Quartz v4 中嵌入本地 HTML 格式报告的解决方法

Mon, 16 Jun 2025 00:00:00 GMT

和o3、Gemini 2.5 pro、4o等模型搏斗七小时后的结论

人设、站队与真相：从海棠与“妈妈岗”议题看后现代传媒特性 & 兼论新闻事实核查工具

Sun, 15 Jun 2025 00:00:00 GMT

人设先行、情绪主导、事实失焦

「Quartz 4 × Obsidian」：一键发布，构筑属于你的数字花园

Fri, 13 Jun 2025 00:00:00 GMT

本文介绍如何使用 Quartz 4 搭建 Obsidian 数字花园，并通过 GitHub Action 与 Vercel 实现自动化部署与笔记同步。

哪哪都有鹅厂——梳理腾讯的游戏产业投资帝国

Wed, 11 Jun 2025 00:00:00 GMT

本文梳理了腾讯在全球游戏产业的投资版图，详述其通过资本布局成为多家知名工作室的重要股东，展现了其在全球游戏市场的深度渗透与影响力。

嗵嗵：东北凛冽的寒冬与毛茸茸的通灵舞

Tue, 10 Jun 2025 00:00:00 GMT

东北的严寒会剥夺一切多余的颜色、情绪和言语，只留下近乎真空的肃杀。

DeepSeek 模型25年下半年更新前瞻

Thu, 05 Jun 2025 00:00:00 GMT

本文内容基于公开信息与个人推理，仅供参考，非 DeepSeek 官方声明。

信息洪流中的官僚体系：苏联央地关系与大部委制度反思

Sun, 01 Jun 2025 00:00:00 GMT

写了很久的一篇博客了，本文聚焦苏联官僚体系，剖析其央地关系与大部委制下的信息处理困境，揭示计划经济失灵的深层原因。旨在反思信息洪流中官僚治理的结构性症结与制度韧性，为现代国家治理提供镜鉴。

儿童节专题｜她的身体，他的灵魂：男娘审美的生成机制

Sat, 31 May 2025 00:00:00 GMT

在上一篇的基础上去论述为什么男娘文化可以部分成为现在的显学

儿童节专题｜从裙子到雌激素：伪娘、药娘与性别拟象的进化论

Fri, 30 May 2025 00:00:00 GMT

儿童节快到了，整点抽象的活

浅谈ChatGPT的记忆实现机制兼论工程端记忆设计

Sun, 25 May 2025 00:00:00 GMT

本文系统梳理了 ChatGPT 的记忆系统实现机制，并探讨了工程实践中不同层次的“记忆”设计思路与权衡方法，兼具技术性与现实可操作性。

《债务危机》书评&笔记

Sat, 24 May 2025 00:00:00 GMT

达利欧《债务危机》的书评与读书笔记，自用

十二月党人的雨夜

Tue, 20 May 2025 00:00:00 GMT

社群征文活动，顺便水一篇

从“捡到女高中生”到“萝莉妈妈”——看现代社会中男性的爱与性需求

Sun, 18 May 2025 00:00:00 GMT

一场关于“救赎欲望”与“父职焦虑”的心理-社会分析

基于Koishi、Chatluna和NapCat：QQ群聊机器人的部署教程

Sat, 17 May 2025 00:00:00 GMT

本文记录了基于Koishi、Chatluna和NapCat三个项目搭建QQ聊天机器人的全过程

从神经递质到临床药理：ADHD的机制与干预逻辑解析

Thu, 15 May 2025 00:00:00 GMT

本文从神经递质失衡入手，系统解析ADHD的神经机制与药物干预逻辑，并探讨兴奋剂与非兴奋剂药物的临床应用与社会文化意义，最后反思“注意力正常化”背后的医学与制度边界。

风自东方来｜鸿蒙PC市场生态前瞻与私货输出

Wed, 14 May 2025 00:00:00 GMT

在国产化与自主可控的浪潮下，鸿蒙PC作为华为重构桌面生态的关键一子，正式走入大众视野。本文系统分析了HarmonyOS在芯片架构、系统设计与生态协同方面的创新路径，评估其在信创市场的独特优势，同时也坦诚面对其应用生态冷启动、用户习惯迁移等现实挑战。面对技术理想与商业落地的双重考验，鸿蒙PC究竟是一次破局，还是又一个昙花？不妨冷静观望，风正起时。

IMF FSSA 2025：中国金融系统稳定性评估解读

Mon, 12 May 2025 00:00:00 GMT

未来可能讲更有意思的话，著更其完美的文，做更其壮丽的事业，但今天只是今天，未来也只是今天的未来。制度建设亦然，它不可能在某个“理想的未来”中自动成熟，而只能在每一个“今天”的制度选择与博弈中，一步步得以奠基。

教书为生，非命为代价：不眠的教培机器与增长困境

Thu, 08 May 2025 00:00:00 GMT

本文深刻剖析了教培行业“过劳”现象背后的资本逻辑与系统性问题，在最后指出，复杂性并不会直接消除，而是使其在不同主体间转移，呼吁行业反思超越增长数字的未来。

身份置换与拟态情缘：青少年用户在《蔚蓝档案》中心理补偿机制浅析

Sat, 03 May 2025 00:00:00 GMT

《蔚蓝档案》如何以“老师”身份置换与拟态情缘，满足青少年玩家的权威感、亲密需求与心理补偿，这篇文章将深入剖析其吸引力机制。

仓鼠速递：远程VPS+TG Bot实现离线下载并上传至OneDrive

Wed, 30 Apr 2025 00:00:00 GMT

本文介绍了一个基于远程 VPS 和 Telegram Bot 实现的自动化下载上传系统——“仓鼠快递”。作者在魔改开源项目 aria2bot 的基础上，集成了 Aria2 和 rclone，实现了从 TG 接收链接、离线下载到自动上传 OneDrive 的完整流程。项目已封装为可即开即用的 Docker 镜像，适合有轻量级文件中转需求的技术用户部署使用。

论文选读：基于LLM的中国街道与社区犯罪时空分布数据集

Sun, 27 Apr 2025 00:00:00 GMT

在它之前，很多关于城市犯罪动态、微观社会治理的研究设想，往往只能停留在“如果有合适数据的话就能做”的假设阶段；而现在，这样的数据终于变成了可以触摸、可以下载、可以真正展开实证研究的现实。

MacOS使用Crossover&Wine运行Galgame（常轨脱离）崩溃解决记录

Wed, 23 Apr 2025 00:00:00 GMT

本篇记录了在 Apple Silicon Mac 上使用 Crossover（Wine）运行 Galgame《常轨脱离》时遭遇白屏崩溃的排查与解决全过程。详尽分析了 WVC1/WMA 解码失败背后的多媒体依赖问题，并通过安装 DirectShow Filters 成功修复。适合所有在 macOS 上尝试跑 Windows 游戏的折腾型玩家参考。

评OpenAI发布o3&o4mini：喧嚣落幕，长路开启

Sun, 20 Apr 2025 00:00:00 GMT

从GPT-4的奇点时刻到o3&o4mini的现实发布，本篇回顾AI两年间的格局重构，解析OpenAI的相对衰落、国产模型的跃升，以及技术竞赛如何转向慢变量的下半场。

神经药理学笔记：可卡因等药物如何操控人脑奖赏系统

Wed, 16 Apr 2025 00:00:00 GMT

可卡因为何令人上瘾？咖啡因为何提神？本篇博客以中脑边缘多巴胺通路为核心，深入解析成瘾性物质如何操控大脑奖赏系统，揭示“快乐”的本质、机制与代价，帮助读者理解大脑如何在化学影响下被诱导、强化乃至改变。

中国与世界的现代化专题（三）：城投与地方债-从分税制改革到房地产经济的逻辑

Sat, 12 Apr 2025 00:00:00 GMT

本文剖析分税制后地方政府依赖土地财政与城投公司融资之路，阐述其推动增长与积累债务的双重性，并从宏观债务周期视角理解当前转型挑战。

通过Github Action实现自动推送英文外刊到Obsidian中

Thu, 10 Apr 2025 00:00:00 GMT

厌倦手动下载外刊？本文教你如何利用 GitHub Actions 自动从源仓库抓取最新期刊（如经济学人），将其推送到 S3 (COS) 云存储，并通过 Remotely Save 插件同步至 Obsidian。实现外刊获取与阅读的完全自动化。

神经药理学笔记：茶氨酸、咖啡因和米氮平

Mon, 07 Apr 2025 00:00:00 GMT

本篇神经药理学笔记探讨L-茶氨酸的镇静放松、咖啡因的提神兴奋及其协同作用，并深入解析处方抗抑郁药米氮平的多靶点机制。了解它们对大脑的不同影响、效果及注意事项。

模型考古学（八）：Llama4发布——并非领先

Sun, 06 Apr 2025 00:00:00 GMT

Meta发布Llama 4系列，采用MoE、原生多模态与千万级上下文。虽性能宣称领先，但社区质疑实际效果与宣传不符，发布显仓促，更像追赶而非引领。

人类简史书评&笔记：想象的共同体

Fri, 04 Apr 2025 00:00:00 GMT

《人类简史》笔记：聚焦赫拉利“共同想象”核心，探讨国家、经济等社会秩序如何由共享故事（“想象共同体”）构建，并反思这些“虚构现实”的本质与力量。

一份关于美联储的报告（下）：政策工具箱与宏观经济指标的运作逻辑

Wed, 02 Apr 2025 00:00:00 GMT

本期详解美联储常规与非常规政策工具，及其调控信贷实现双重目标的机制。并探讨贝莱德等三大资管巨头日益增长的影响力及其与美联储的复杂联动关系。

参考：抗失眠与抑郁药物清单

Sun, 30 Mar 2025 00:00:00 GMT

这篇博客详细介绍了治疗失眠和抑郁的药物，强调用药需遵医嘱，切勿擅自使用。文章分类介绍了抗失眠药物（苯二氮䓬类、非苯二氮䓬类、褪黑素受体激动剂、食欲素受体拮抗剂、镇静抗抑郁药）和抗抑郁药物（SSRIs、SNRIs、TCAs、MAOIs、非典型抗抑郁药）的作用机制、常见药物、风险和副作用。

模型考古学（七）：Qwen2.5-Omni技术报告解读

Thu, 27 Mar 2025 00:00:00 GMT

阿里小开了一款大模型，叫Qwen2.5-Omni，本篇将看下Qwen2.5-Omni的技术报告，讨论一下其中的创新点和Omni类模型的工程优势。

一份关于美联储的报告（上）：联储介绍与基本经济概念的厘定

Thu, 27 Mar 2025 00:00:00 GMT

本文介绍了美联储的基本架构与职能，厘定基本经济概念，并阐述了美元作为世界货币的独特地位及其对全球经济的影响。

模型考古学（六）：DeepSeek V3和R1技术报告浅析

Sun, 23 Mar 2025 00:00:00 GMT

本文深入解析 DeepSeek V3 和 R1 两大模型的创新点，涵盖架构、训练策略与推理能力，展现中国开源模型的强劲进展与高性价比潜力。

模型考古学（五）：Minimax-01 模型技术报告简读

Sat, 22 Mar 2025 00:00:00 GMT

本篇博客简要解析了 Minimax-01 模型的架构设计，聚焦其在超长上下文处理中的性能表现与混合注意力机制的技术实现。

浅谈一下我现在正在使用的AI服务

Fri, 21 Mar 2025 00:00:00 GMT

我正在使用的AI服务和一些感受。

模型考古学（四）：RAG技术解析

Thu, 20 Mar 2025 00:00:00 GMT

本文将深入探讨RAG技术的原理、实现方式及其在实际应用中的优势与局限。

暗涌系列：Ark Invest《Big Ideas 2025》报告浅析 Part 2

Sun, 16 Mar 2025 00:00:00 GMT

The BigIdeas 2025的分析报告Part2，主要内容为Robotaxi、自动物流和可重复利用火箭三个领域的解析

《经济学研究入门指南》书评

Wed, 05 Mar 2025 00:00:00 GMT

一个月前看完的书了，前两天收拾Inbox才突然发现有篇书评没发

模型考古学（三）：Agent 系统概述

Tue, 04 Mar 2025 00:00:00 GMT

本文探讨了Agent系统的发展历程、核心概念和技术架构，分析了从基于规则到LLM驱动的Agent演变，以及其在感知、决策、执行等方面的能力与挑战，展望了多智能体协作等未来发展方向。

暗涌系列：Ark Invest《Big Ideas 2025》报告浅析 Part 1

Mon, 03 Mar 2025 00:00:00 GMT

The BigIdeas 2025的分析报告Part1，主要内容为报告的观点洞察与AI Agent、比特币和稳定币三个领域的解析

当信息流开始遵循我的语法：TG RSS BOT 搭建教程与开源项目推荐

Mon, 03 Feb 2025 00:00:00 GMT

本文探讨了信息过载时代的困境，介绍了如何通过Telegram Bot和RSS技术实现信息自动化推送，推荐了多个开源RSS工具，帮助用户重拾信息自主权。

用飞书多维文档打造博客书架页—支持 GitHub Actions 自动更新

Tue, 28 Jan 2025 00:00:00 GMT

本文介绍了如何通过飞书API和GitHub Action实现自动化博客书架页更新。利用飞书多维表格管理书库数据，通过Python脚本同步数据并优化图片，最终借助GitHub Action自动构建和部署博客，实现数据与展示的自动化同步。

2025年1月投资月报：耐心、预期管理与认知局限

Tue, 28 Jan 2025 00:00:00 GMT

摘要：本月收益32%，探讨如何在加密市场波动中建立可持续投资框架，强调耐心、预期管理与不败哲学，从短期交易转向长期主义，构建风险可控的收益体系。

模型考古学（二）：视觉大模型发展梳理与Qwen2-VL论文解读

Wed, 22 Jan 2025 00:00:00 GMT

如果说「模型考古学」第一篇主要聚焦于大语言模型（LLM）的内部机制与演进脉络，那么本篇博客将拓宽视野，探求视觉大模型（Vision Large Language Model，VLLM）的技术原理和发展历程。在单纯的文本世界之外，视觉大模型融合了图像理解能力，赋予了AI“看”世界的眼睛，让模型理解世界的方式从一维的文字扩展到了二维的图像。

模型考古学（一）：大模型原理探赜

Mon, 13 Jan 2025 00:00:00 GMT

这篇博客探讨了大模型（如GPT系列）背后的神经网络基础，从神经网络的基本结构、反向传播算法、梯度下降法，到Transformer架构及其在大语言模型中的应用。文章详细解析了大模型的训练过程、参数优化以及如何通过海量数据提升模型性能。最后，回顾了大语言模型架构的发展历程，比较了不同模型（如BERT和GPT）的特点和应用场景。

使用 Qwen VL 系列模型实现图片分类和OCR任务

Fri, 10 Jan 2025 00:00:00 GMT

阿里云的通义千问（Qwen）大模型在2024年末大幅降价，尤其是Qwen-VL系列模型，为开发者提供了低成本的多模态视觉-语言处理能力。通过零样本学习，开发者无需训练即可实现图片分类和OCR任务，极大提升了工作效率。本文详细介绍了如何利用Qwen-VL进行图片分类和笔记归档整理，展示了其强大的性能和易用性。

Trading101：策略交易解析

Fri, 03 Jan 2025 00:00:00 GMT

策略交易通过数学模型、历史数据分析和计算机程序，构建系统化交易策略，力求在市场波动中获利。其优势在于纪律性、高效性和风险可控性，帮助投资者克服情绪化操作。本文介绍了现货/合约网格、马丁格尔、智能套利、定投和信号策略等工具，分析了其原理、实施方法和潜在风险，为投资者提供了策略交易的入门指南。

国行Xbox series X/S账户转港区教程

Sun, 29 Dec 2024 00:00:00 GMT

本文详细介绍了如何将国行Xbox Series X/S主机转换为港区的完整步骤，包括U盘格式化、创建特殊文件和系统设置修改等操作，帮助玩家解锁更多游戏内容和XGP服务。

Trading101：简析投资中常见的技术指标和其背后的逻辑

Mon, 23 Dec 2024 00:00:00 GMT

本文探讨了股票市场中基于预期差的交易机制，介绍了多种常用技术指标（如成交量、移动平均线、布林带、抛物线转向指标）的应用与局限性，帮助投资者更好地识别市场趋势与潜在交易机会。

新一代静态博客框架Astro的部署优化指南与使用体验

Sat, 14 Dec 2024 00:00:00 GMT

本文介绍了新一代静态博客框架Astro的迁移优化步骤与使用体验，阐明了Astro的轻量化特点、灵活性及其独特的群岛架构，结合fuwari主题，提供了详细的自定义和部署指南，使开发者能够轻松构建高性能的博客。

简析经济学与金融学实证中的几个常用简单模型

Tue, 03 Dec 2024 00:00:00 GMT

引言经济学和金融学作为社会科学的重要分支，其研究目的在于理解和预测经济主体的行为以及金融市场的运作规律，二者研究范围很大一部分都重叠于分析复杂经济体系中各种行为主体的决策及其相互作用机制。实证研究作为连接理论与现实的桥梁，通过对数据的收集、整理和分析来检验经济理论的有效性，并为政策制定和投资决策提

从最近的恶性事件看类《看门狗》中CtOS犯罪评估系统的可能性

Tue, 19 Nov 2024 00:00:00 GMT

声明：相关性不等于因果性首先，必须要在本文开头声明的是，近期大众观念里的“恶性事件频发”可能并不能代表社会整体治安的恶化，更不能将犯罪现象治安问题和所谓的经济下行导致戾气严重相关联。我知道这种因果关系简单直接符合人类思维逻辑，在传播上也容易刺激到人们的爽点，但我在实际查证经济周期和犯罪案件数量之后

从碎片到系统：我的信息整理与优化之路

Mon, 11 Nov 2024 00:00:00 GMT

我的管理方案和存在的问题在信息爆炸的时代，我们每个人的知识源都被碎片化地分布在不同的平台和工具中。从公众号文章到书籍摘录，从研究报告到PDF文件，广领域、多平台、全天候的各种信源交错与堆积，每天都有大量的信息需要管理和处理。作为一个知识工作者，我处理信息的软件一共有四个：Cubox用来集中处理解

不再依赖平台：如何打造自己专属的博客网站？

Wed, 06 Nov 2024 00:00:00 GMT

序这两天我在读居伊·德波的《景观社会》，在网络社会崛起与“媒体过剩”的时代，借助于日益发达的大众传媒工具，景观的作用与功能也日益强化。从轻松的娱乐废料到严肃文学，从日常生活到人的感情和欲望，我们的生活几乎每一个角落都被景观所笼罩和取代，景观的无孔不入让每个个体仿佛置身于一场永不停歇的表演之中。在

为什么我过去、现在乃至未来都看空零一万物

Sat, 19 Oct 2024 00:00:00 GMT

如果说OpenAI的O1开业内大模型推动System 2思考之浪潮，深度求索的deepseek以其极强的工程化能力一手力推了业内大模型迅速白菜价化，阿里通义千问自身开源闭源两路一同高歌猛进，更是在qwen2.0和qwen2.5发布后均力压meta的llama系列成为世界上最好的开源模型，那零一万物则

从2024到2025：我的社科学习书单

Sat, 12 Oct 2024 00:00:00 GMT

阅读进度以本页面为准阅读进度以本页面为准阅读进度以本页面为准阅读进度以

从《学园孤岛》看解离型身份障碍

Tue, 01 Oct 2024 00:00:00 GMT

前言这两天把学园孤岛动漫刷完了，主角由纪的状况就非常有趣：老师佐仓慈 “慈姐”在丧尸压力下选择牺牲自己拯救学生们，但由纪并不能接受这一残酷事实，在精神退行后产生了一个救济人格（幻想中的慈姐）。同时，在她眼中整个学院仍然是鸟语花香一切如常，她每天都会去那已经残破不堪的教室里上课，还幻想了一大堆同学

Weekly通讯-第九期：置信度、乐观主义与为什么集体很容易做出烂决策

Sun, 22 Sep 2024 00:00:00 GMT

信息置信度分级在一个争夺注意力的开放市场上，相较于积极、建设性的思想，较为阴暗的情绪更能吸引眼球。面对外部信源，我们可以将每一条信息按照置信度从A到F进行分级： A：完全确定。 B，小规模事件中，关键截图等被刻意淡化，但有网友目击大量间接证明；大规模事件中，有明确方向定性，但规模太大无法在统计学上

上市公司财报分析思路

Sun, 15 Sep 2024 00:00:00 GMT

现代社会已经进入到资本市场高度发达的阶段，财务报表所提供的财务信息无疑是投资者在资本市场进行决策最重要的信息来源。人们倚重财务报表，尤其是社会公众投资者，由于受到种种条件限制，既没有时间、精力到上市公司调研，也缺乏其他信息来源，就更加依赖财务报表。看各种上市公司的招股书和财报应该是各路经济学专业学

中国与世界的现代化专题（二）：货币的本质与中国的税收体系

Thu, 05 Sep 2024 00:00:00 GMT

注：本文为系列专题——“中国与世界的现代化”的一部分作为中国与世界的现代化专题的第二章，我希望就此开始为我和我的博客逐步构建起一套完整的，体系化的去分析中国乃至于世界现代化的理论框架——了解中国的现代化当然离不开了解政府，剖析政府的额行为动机也必然离不开最核心的财税制度。因此，我必须要在开头承认

新一代大模型对话框架——OpenWebUI部署教程

Wed, 28 Aug 2024 00:00:00 GMT

前言在之前的博客里，我曾对当时最为流行的两个 AI 对话网页项目 ——ChatGPT-Next-web 与 Lobechat 进行了总结。诚然，这两个项目在部署方面极为便捷（能够一键通过 Vercel 启动或借助 Docker 进行部署），无需担忧托管问题，且社区教程文档丰富详实。市面上还有诸如

RSSHub在Vercel上部署与信源选取

Sun, 18 Aug 2024 00:00:00 GMT

原来都是在vps上用docker部署的RSSHUB，这两天突然发现居然Vercel也能部署RSSHUB，太神奇了。虽然不像其他能vercel一键部署的项目那样，但实际操作流程也很简单：一、正式部署流程 1.Fork这个仓库： https//github.com/DIYgod/RSSHub 如果

Weekly通讯-第八期：悬而未决之事、时间窗口与结婚户口的思考

Sun, 18 Aug 2024 00:00:00 GMT

一、消解悬而未决之事带来的焦虑感我们经常会对一件悬而未决的事情感到焦虑，这实际上是再正常不过的生理本能，悬而未决意味着风险，意味着可能有不确定性带来的损失，我们的本能自然会驱使着大脑尝试寻找解决办法——如果自己的能力阅历找不到，则会直接导致潜在的焦虑烦躁。但生活中往往不如意者十之八九，这个世界不

致瞬息万变之物，及亘古不变之物

Wed, 07 Aug 2024 00:00:00 GMT

这篇小作文也勉强可以算是我迟来的20岁生日感想吧，距离我写下《十八岁-未济与求索》的生日感想不过区区两年，心态、见识却变化了太多。 1517年的深秋，马丁·路德终于做好了最后的思想准备，将《九十五条论纲》贴在了德国维滕堡城堡教堂的大门上，轰轰烈烈的宗教改革运动就此开始，曾经不可一世的教会教皇逐渐会意

Weekly通讯-第七期：跳大神、回报预期、奥弗顿窗口和为死亡定价

Mon, 29 Jul 2024 00:00:00 GMT

一、不要随意的做出预言和定论很多营销号和所谓的经济学家经常喜欢渲染一个或者多个时间节点，来营造一种史诗感来彰显自己的专业，提纯粉丝和造神，通常这种我看到一个屏蔽一个，实在是污染互联网。归根结底，经济学和其他所有的社会科学一样都是一种归纳性的学问，舆论场上很多人却总喜欢把经济学/金融学当成是什么有

2024阅读计划

Mon, 22 Jul 2024 00:00:00 GMT

本页面未必详尽，具体书单可参照“时歌的书库” 2024.10.3：本页面已过时，具体博主年度已阅读/待阅读书单请统一参照对应Notion Page。政治经济学大停滞：新冠疫情如何撼动全球经济-亚当·图兹崩盘：全球金融危机如何重塑世界-亚当·图兹结构

Weekly通讯-第六期：米哈游，萝卜快跑，AI市场出清与MMT

Sat, 20 Jul 2024 00:00:00 GMT

一、米哈游的商业设计绝区零推出，当前米哈游正式形成原神时代之后的三驾马车：原神、崩坏：星穹铁道和绝区零。有点遗憾，三款游戏我都玩过一点但很快就热度消散（怪我自己电子阳痿），但不妨碍我欣赏米哈游的音乐和美术设计+赞美其高效的二次元韭菜镰刀商业模式。对于原神，进一步扩圈的压力是很明显的。参见那维莱特

中国与世界的现代化专题（一）：萝卜快跑，社会结构与国际价值链分工

Sun, 14 Jul 2024 00:00:00 GMT

一、萝卜快跑成本测算分析百度做萝卜快跑（l4类）的自动驾驶其实已经积累很久了，2024年下半年应该算是一个集中的爆发期，无人驾驶正式以一个“出圈”的姿态展现到大众面前，和以前各大车企大力公关的自上而下宣传不同，本次萝卜破圈更多以基层传播为态势，人民群众之前的讨论热度广热情高。可以看到具体的舆论数

Weekly通讯-第五期：耐心资本、鸿蒙Next、科大讯飞、信息成瘾与柔不监国

Sat, 06 Jul 2024 00:00:00 GMT

一、耐心资本与长期主义不谋全局者，不足谋一域；不谋万世者，不足谋一时。 20世纪30年代，本杰明·格雷厄姆在其《证券分析》中奠定了价值投资的基础，即投资者应当基于企业内在价值而非市场情绪做出投资决策。20世纪60-90年代，沃伦·巴菲特和查理·芒格将格雷厄姆的价值投资原则进一步发扬光大，通过伯克希

使用ResNet训练一个图片分类模型

Thu, 04 Jul 2024 00:00:00 GMT

项目文件已上传至Github和我自己的公开仓库。一、背景介绍 2024.10.22本篇博文的展示代码已经落后于GitHub库代码，但我懒得写一篇新的博客来解析对应GitHub库了，实际上主要的实现方式路径都差不多，如果你想训练自己的分类模型而不想究其原理，直接fork库即可事情的起因是这样的：

2024年度下半年个人OKR

Tue, 25 Jun 2024 00:00:00 GMT

OKR1：考研—法学 Objective目标在五个月内完成非法本法学研究生考试的准备，并进行至少三轮复习 Key Results关键结果学科知识掌握：完成刑法、宪法、民法、法理学和法制史五大核心课程的系统学习，每门课程至少完成三轮复习，并通过模拟测试验证，确保平均得分达到80%以上。考研英语

博客下半年更新计划

Tue, 18 Jun 2024 00:00:00 GMT

计划下半年主要围绕两个专题进行写作：专题：金融与机器学习主要探讨lstm、transformer等机器学习框架如何同金融相结合，更多会分享一些我在金融量化领域的感悟可能的选题：从零开始的深度学习 Transformer与金融量化想法：训练一个图片分类模型，将我搜集的壁纸和日常截图分类整理后

Weekly通讯-第四期：偏见、投资人的傲慢与不要人格化组织

Tue, 18 Jun 2024 00:00:00 GMT

一、大模型的偏见—人类互联网的偏见大模型的所谓“观点”和“意识”是如何形成的？大模型的基础是Transformer架构的神经网络，本质上是在庞大的数据集上进行训练，学习语言的统计规律和模式，实际上是“人类社会的共识与偏见在数字空间的映射”。当被提问或给予某个任务时，它会基于训练过程中学到的知识和

使用LSTM模型对Apple股票进行简单预测

Mon, 17 Jun 2024 00:00:00 GMT

一、技术基础 1.RNN RNN，即循环神经网络（Recurrent Neural Network），是一种专为处理序列数据而设计的神经网络架构。与传统的前馈神经网络不同，RNN具有循环的内部状态，能够在处理序列中的每个元素时保留和更新关于过去信息的记忆。这种机制使得RNN能够捕捉到数据中的时间依赖

股票指数投资组合VaR（在险价值）的计算

Sat, 15 Jun 2024 00:00:00 GMT

作为风险评估的核心工具，Value at Risk (VaR) 能有效量化投资组合在未来特定时间内可能遭受的最大损失概率，为投资者提供了决策的“安全边际”。本文假设有一个投资者使用10000美刀来投资道琼斯工业指数、上证、深证和日经225，来计算该投资组合的VaR。一、完整代码 import yf

Weekly通讯-第三期：回旋镖、AI就业、阴谋论与摘录

Fri, 07 Jun 2024 00:00:00 GMT

一、回旋镖二年今晚考古23年9月前的一个探讨国产化芯片的议题，回旋镖来的实在是有些快。从2023年开始，不论哪一方我们都看过了太多太多的回旋镖，这是否也是网络生态下的一种必然？ 1.屏蔽掉一切阴阳怪气，不论立场阴阳怪气者有什么伟大而正义的原因所以要阴阳怪气，这不需要我担心，总之生活环境中不断被这

我们到底需要什么样的AI？

Wed, 29 May 2024 00:00:00 GMT

一、从信息处理和复杂度开始谈起首先，我们认为从广义信息处理的角度来讲，一个系统想要实现某些功能特性，基础是一定水平的必要复杂度。暴论：香农的信道编码指出，存在一种编码方法使得在给定的信道噪声水平下，信息传输速率不超过信道容量时，可以实现几乎无误的通信。信息熵是衡量信息不确定性的度量，复杂任务的输

Weekly通讯-第二期：B站的运作、GPT-4o与胖猫

Mon, 20 May 2024 00:00:00 GMT

一、进入瓶颈期的B站 B站有在2024年实现盈利的承诺，但涉及到具体的增长空间从何处来？假如后续B站业务不发生重大调整，在保证平台生态正常运转（UP多少可以分一点钱）的情况下，B站支出端的优化已经到尾声了。一年170亿的成本，其中大部分（90亿的收入分成，35亿的内容成本以及20亿的带宽成本）都相

Pake打包Web APP记录

Mon, 13 May 2024 00:00:00 GMT

一、Pake是什么？ Pake是一项使用Rust Tauri作为底层框架的、实现了快捷键的透传、沉浸式的窗口、拖动、样式改写、去广告、产品的极简风格定制的web app打包开源项目。原本的网页打包成应用要么是PWA，要么就是electron塞一个chromium，Pake则是用Tauri 替代之前套

广汽埃安IPO受阻分析

Fri, 10 May 2024 00:00:00 GMT

一、广汽埃安历史沿革与战略地位 2011年，整个国内新能源汽车行业方兴未艾，广汽集团开始探索新能源汽车市场的发展机会。四年后，随着新能源汽车行业加速发展，广汽集团正式成立新能源分公司，对外宣布进军新能源汽车市场。2017年7月，广汽新能源汽车有限公司正式注册成立，在当时普遍还是“油改电”时，广汽新能

Weekly通讯-第一期：Agent、New Money的投资逻辑与时代的孤独

Mon, 06 May 2024 00:00:00 GMT

一、2024年大模型领域的热点：Agent 1.Agent基础 Agent（代理）一概念起源于哲学，描述了一种拥有欲望、信念、意图以及采取行动能力的实体。在大模型中，agent的含义为：具有自主性、反应性、交互性等特征的智能“代理”。 LLM给AI Agent底层提供了一个突破性技术方案：LLM带来

Expressive Code Example

Wed, 10 Apr 2024 00:00:00 GMT

How code blocks look in Markdown using Expressive Code.

分析问题的框架

Thu, 12 Oct 2023 00:00:00 GMT

分析问题的框架一、判定信息的类型# 信息可以被分成事实，立场，信仰和观点。事实，是独立于人的判断客观存在的，是可以被证明或观察到的真实情况和事件。观点，是人们针对事实得出的看法，带有主观意味。立场，是被位置和利益影响的观点；通常一件社会事件可以基于利益划分出多种立场。信仰，是内部完全自洽的

十八岁-未济与求索

Thu, 12 Oct 2023 00:00:00 GMT

小时候囫囵吞枣看易经，到现在内容忘个精光，每一卦的名称倒是还依稀记得。易经以乾坤两卦开始，最后一卦却是 “未济”。何为 “未济”？孔夫子作的《序卦传》说，“物不可穷也，故受之以未济终焉。” 易经六十四卦到了既济这一卦，乾坤或几乎息矣。矛盾似乎消失，斗争已然停止 —— 但是唯物辩证法告诉我们，矛盾

思维工具

Thu, 12 Oct 2023 00:00:00 GMT

思维工具 1.作恶史观如果一个人做了看上去很蠢，即正常逻辑说不通，和他一如既往打造的人设相反的事情，那么就说明有我没有盘出来的逻辑。假如每一个对他的恶意揣测都有证据支撑，那么作恶史观就生效了。从最坏的角度出发，基于发生的事实和最终的效果，而不是当事人的叙述和情绪态度进行推理。搞有罪推定，选择那个

智能驾驶全景分析其二-决策篇

Thu, 12 Oct 2023 00:00:00 GMT

智能驾驶全景分析其二-决策篇 0.内容概述 2.决策篇拆分决策层（Decision-making Layer）是智能驾驶系统中的关键组成部分，负责根据感知层提供的环境信息，为车辆制定安全、可行和高效的行驶策略。决策层的核心就是车载计算平台。车载计算平台产业链从硬件到软件主要包括硬件平台，系统软件与

时歌的博客 | Boundary of Thought

浅谈当下 Agent Memory 设计取舍

设计取舍

在文章里嵌入交互演示：Sketch 组件使用说明

工作原理

目录约定：文章包

在 MDX 里插入 demo

<Sketch> 组件参数

写 demo HTML 的建议

安全说明

调试技巧

相关文件

如何让 Codex 同时支持 ChatGPT OAuth 与自定义 API Provider

我碰到的问题

正确的配置方案

处理 auth.json

日常使用

其他的常见误区

从世界的局部平滑性谈 Embedding 的意义

一、学习何以可能？

二、把语义变成几何

1.你的邻居定义了你

2.从语言到一切：对比学习与更一般的 Embedding

3.多面孔的词

三、计算相似性

1.下沉到语义层

2.建立语义世界的坐标系

回到起点：为什么能 Work？

一念不落，万象可循：YOLO 的记忆系统实现

一、YOLO 的记忆到底应该记什么？

二、存储方案：markdown 文档

1.储存格式：markdown+列表式

2.文件结构：分区 + 编号

3.双重记忆：全局 + Per-Assistant

三、Memory 工具设计

触发策略：谁来决定「该记了」？

去重与冲突：AI 自己判断，还是插件层兜底？

四、记忆在YOLO上下文中的位置

YOLO 的 Agent 实现与 Lite Skills 系统

一、技术选型：少即是多

二、Agent Loop 的实现

一切的起点：三种场景，一个内核

快路径与完整 Loop 的分流

工具网关：可控边界内的自动化

上下文编译

三、Lite Skills：精简后的，更适合黑曜石宝宝体质的 skills

为什么叫「Lite」

一个 Skill 长什么样

加载策略：always 与 lazy

权限控制：谁能加载什么

四、未来展望

博客｜序（新）

上下文是稀缺资源｜RAG、Memory、Skills 的设计哲学刍议

一、当前业界的几种主流上下文管理方向

1.检索增强生成（RAG）：让模型学会查资料

2.分层记忆系统

3.子代理架构（Sub-Agent）：通过分工实现上下文隔离

二、那么，Skills 是什么？

1.它解决的到底是什么问题？

2.一个好的 Skills 应该是什么样的？

2.1 决策树式的工作流指导

2.2 分层文档引用

2.3 脚本捆绑：将确定性操作封装到代码中

3.Skills 的设计哲学

三、上下文管理的未来图景

YOLO 开发日志（二）：Tab 补全设计

Copilot auto completion 的设计哲学

1.提示词设计：掩码替代任务

2.触发机制

YOLO的设计思路

提示词：保留掩码，开放约束

触发机制：继承与本地化

上下文处理：智能边界检测

写在最后

YOLO 开发日志（一）：为什么要开发 YOLO

YOLO的愿景是什么？

宏观分析师笔记（一）：从宏观叙事到量化因子

ta们不配讲理｜浅谈现代思潮对立中的去人性化机制

“我们”的偶像与“我”的英雄｜从时代少年团看两性情动结构的分野与融合

开发随笔：一个简单的 Todo MCP，和一次关于减法的开发实践

`<Sketch>` 组件参数

浅谈ChatGPT的记忆实现机制兼论工程端记忆设计