版本 0.1 — 草案

OKF 是一种开放、对人类和智能体友好的格式，用于表示知识——即围绕数据和系统的元数据、上下文和精心整理的洞察。它旨在由人类编写、由智能体生成、跨组织交换，并由两者共同消费。

该格式有意保持极简：一个由 Markdown 文件和 YAML 前置元数据组成的目录。没有 Schema 注册中心，没有中央权威机构，也不需要任何特定工具。如果你能 cat 一个文件，你就能读取 OKF；如果你能 git clone 一个仓库，你就能分发它。

面向 AI 智能体的知识表示领域正在快速演进，许多互不兼容的约定正在涌现。OKF 的立场是，知识最好用常见、已建立的格式来表示，这些格式应具备以下特性：

• 无需工具即可被人类阅读。
• 无需定制 SDK 即可被智能体解析。
• 可在版本控制中进行差异比较。
• 可跨工具、组织和时间迁移。

该格式保持最低限度的主观性。它仅标准化一小套结构约定，使知识语料库能够自我描述——除此之外的一切留给生产者自行决定。

1. 定义一种通用格式，增强型智能体可以写入其中。
2. 告知消费型智能体应如何读取和遍历它。
3. 促进知识跨系统和组织的交换。
4. 标准化少量必需字段，使内容能够被有意义地消费。

• 定义固定的概念类型分类体系。
• 规定存储、服务或查询基础设施。
• 取代领域特定 Schema（Avro、Protobuf、OpenAPI 等）——OKF 引用它们，而非包含它们。

范围：Kilo CLI (packages/opencode/) / VS Code Extension (packages/kilo-vscode/) / Kilo Cloud (后端归因引擎)

本方案解决的核心问题是：精确量化 AI 在最终代码库中的实际贡献比例。现有方案（包括行业通用的"行数计数法"）只能回答"AI 被接受了多少行"，但无法回答"这些被接受的代码有多少存活到了最终提交，以及被人类修改了多少"。

本方案在 Kilo Code 现有架构上，引入 AST-aware MinHash 指纹归因引擎（基于 k-Shingle + LSH），构建一条从 AI 代码生成瞬间到 Git 最终提交的全链路追踪能力。三套代码生成路径（Tab 补全、Chat 对话、Agent 子任务）统一采集代码指纹，服务端在 Git 提交阶段进行归因匹配，最终产出精确到行级的 AI 贡献占比。

基于 OpenAI Whisper 的命令行工具，将音频文件批量转写为 VTT / SRT 格式字幕。

依赖	说明
Python	≥ 3.8
PyTorch	Whisper 的运行时依赖，自动安装
openai-whisper	语音识别引擎
ffmpeg	音频解码，系统级安装

• macOS：

brew install ffmpeg

• Ubuntu / Debian：

sudo apt update && sudo apt install ffmpeg

pip install openai-whisper

该命令会自动拉取 torch 等依赖。首次运行时 Whisper 模型文件会下载到 ~/.cache/whisper/。

使用系统 Python 或 miniconda 安装 whisper：

# miniconda（推荐，已预装 torch）
/opt/miniconda/bin/pip install openai-whisper

# 或系统 Python
/usr/bin/python3 -m pip install openai-whisper

编写文件：audio2sub.py

以下是完整的词汇表（共3100个单词，按字母顺序排列）：

这是一个非常实际的工业需求。MinHash 在这个场景中不是直接检测"是否 AI 生成"，而是作为代码指纹匹配引擎，追踪"AI 原始输出 → 人修改后最终代码"的相似度与存活比例。

下面给出完整的AI 生成代码占比统计系统设计方案。

在智能体编码助手（GitHub Copilot、Kilo Code、Cursor 等）的工作流中，代码的生命周期通常是：

AI 生成建议 → 人接受/修改 → 进入代码库 → 后续迭代中被修改

我们需要统计的是最终代码库中，可追溯至 AI 原始生成的代码比例。这不是简单的"谁按了 Tab 键"，而是：

统计维度	含义	计算方式
AI 原始贡献率	AI 生成的代码在最终代码中的存活比例	匹配上的代码行 / 总行数
人修改深度	人在 AI 代码基础上做了多大改动	1 - (AI 原始代码保留率)
人效提升系数	有 AI 辅助时人均产出 vs 无 AI 辅助	对比实验或历史基线

1. 人会修改：AI 生成的代码被人接受后，通常会修改变量名、加注释、调逻辑，文本相似度会下降
2. 代码重构：函数拆分、类提取等操作会让纯文本匹配失效
3. 规模问题：一个团队每天可能产生数千次 AI 交互，需要快速匹配

在文本挖掘和信息检索领域，$k$-Shingle（通常也被称为 $k$-gram）是一种将连续的文本切分成固定长度碎片的技术。它是海量文本去重（如 MinHash + LSH 架构）中极其关键的数据预处理阶段。

简单来说，它的核心任务是：把一篇文章（一维的字符串）转化成一个集合（Set），并且在这个集合中锁死文本的局部语序。

$k$-Shingle 的工作原理就像一把长度为 $k$ 的滑动尺子。尺子从文本的开头开始，每次框住 $k$ 个单位的内容作为一个 Shingle，然后向右平移一个单位，重复这个过程，直到文本结束。

根据具体需求，这里的“单位”可以是字符（Character），也可以是单词（Word）：

• 基于字符的 $k$-Shingle：通常用于拼写检查、DNA 序列分析或中文字符处理。
• 基于单词的 $k$-Shingle：通常用于英文等有天然空格分隔的文本去重与防抄袭。

我们以短语 abcde 为例，来看看在不同的 $k$ 值下，基于字符切分出来的 $k$-Shingle 集合是什么样的：

• 当 $k = 1$ 时（尺子长度为 1）：每次只框一个字母。
• 集合结果：{ "a", "b", "c", "d", "e" }

当 k=2k = 2k=2 时（尺子长度为 2）：第一次框 ab

在互联网大数据场景中，如何从海量数据（如百亿网页、千万级商品描述、巨大的开源代码仓库）中快速找出重复或高度相似的内容？这是一个极其经典的工业界痛点。

最朴素的想法是：对文章进行分词，转成集合后两两比对。若有 $N$ 篇文档，需要比较 $\frac{N(N-1)}{2}$ 次。当 $N = 10^7$（一千万）时，比较次数约为 50 万亿次。即便单次比较仅需 1 微秒，也需要 1.6 年 才能跑完。这种 $O(N^2)$ 复杂度的算法会导致服务器直接卡死崩溃。

本文将结合数学原理、算法推导与工程实战，深入拆解 Jaccard 相似度 的直觉陷阱，以及 MinHash（最小哈希） 算法如何对高维稀疏数据完成降维打击，最终给出可直接落地的工业级实现方案。

Jaccard 相似度（Jaccard Similarity） 是衡量两个集合重合度的标准数学方法。其核心思想非常直观：看两个集合的交集（共同拥有的元素）占它们并集（总共拥有的元素）的比例。

数学公式定义为：

$$J(A, B) = \frac{|A \cap B|}{|A \cup B|}$$

假设我们要对比两篇简短文本的词汇相似度： 文本 A 词集：{ 苹果, 香蕉, 梨, 桃子 }（4个元素） 文本 B 词集：{ 香蕉, 梨

• Introducing Gemma 4 12B: a unified, encoder-free multimodal model
• Gemma 4 12B: The Developer Guide
• Accelerating Gemma 4: faster inference with multi-token prediction drafters
• A Visual Guide to Gemma 4 12B
• Gemma 4: Byte for byte, the most capable open models
• Ollama Gemma 4

Gemma 4 12B 是谷歌最新推出的一款原生、无编码器（Encoder-free）的统一多模态大模型。它的核心定位是将高水平的“智能体（Agentic）”和多模态能力直接带到用户的笔记本电脑等日常消费级硬件上。

以下是对 Gemma 4 12B 大模型的详细介绍：

与传统的多模态模型（通常需要使用独立的、冻结的视觉或音频编码器将数据转化为文本格式）不同，Gemma 4 12B 采用了统一的、仅解码器（Decoder-only）的 Transformer 架构。

视觉嵌入器（Vision Embedder）：仅有 35M 参数，取代了传统复杂的视觉 Transformer 层。

罗福莉 2026年4月6日

两天前，Anthropic 切断了第三方客户端（Harnesses）使用 Claude 订阅的通道——这并不令人意外。三天前，MiMo 推出了其 Token 计划（Token Plan）——这是一个我投入了大量精力去设计的方案，也是我认为在实现合理的算力分配和智能体客户端开发方面一次严肃的尝试。将这两件事结合起来，我有以下几点思考：

Claude Code 的订阅制是一个专为平衡算力分配而设计的精美系统。 我的猜测是——它并不赚钱，甚至可能在亏本，除非他们的 API 利润率高达 10-20 倍，但我对此深表怀疑。虽然我无法严密地计算出第三方客户端接入所带来的损失，但我近距离观察过 OpenClaw 的上下文管理——它真的很糟糕。在单个用户查询中，它会把一轮轮低价值的工具调用作为独立的 API 请求发送出去，每个请求都携带长达 100K 以上 Token 的长上下文窗口——即便有缓存命中，这也是极大的浪费，在极端情况下还会推高其他查询的缓存未命中率。其单次查询的实际请求次数最终比 Claude Code 自身框架高出数倍。折算成 API 定价的话，真实成本恐怕是订阅价格的几十倍。这不仅是一个差距，而是一个巨大的黑洞。 像 OpenClaw/OpenCode 这样的第三方客户端依然可以通过 API 调用 Claude——它们只是不能再薅订阅制的羊毛了。

AGPL v3.0 许可证的开源豁免仅限于公司内部直签员工自用。由于公司混编了第三方外包人员，在法律主体上已被视作向外部第三方提供服务；一旦我们修改了该项目的核心代码，将直接触发强制开源机制，导致公司相关的商业源代码面临被迫向全社会彻底公开的重大合规风险。

版权所有 (C) 2007 Free Software Foundation, Inc. https://fsf.org/ 允许每个人复制和分发本许可证文档的完整副本，但不得修改它。

序言

GNU Affero通用公共许可证是一份自由的、著佐权性质的许可证，适用于软件及其他类型的作品，它专门设计用于确保在网络服务器软件的情况下与社区合作。

大多数软件的许可证旨在剥夺您分享和修改软件的自由。相反，我们的通用公共许可证旨在保证您分享和修改程序所有版本的自由——确保它对所有用户来说都是自由软件。

当我们谈论自由软件时，我们指的是自由，而非价格。我们的通用公共许可证旨在确保您拥有分发自由软件副本的自由（如果您愿意，也可以对此服务收费），确保您能够收到源代码或在需要时获取它，确保您可以更改软件或在新的自由程序中使用其部分内容，并且确保您知道您可以做这些事情。

使用我们的通用公共许可证的开发者通过两个步骤来保护您的权利：(1) 声明软件的版权，以及 (2) 向您提供本许可证，授予您复制、分发和/或修改软件的合法许可。

• 运行 (Run): bun run --conditions=browser ./src/index.ts
• 测试 (Test): bun test（运行所有测试）或 bun test test/tool/tool.test.ts（运行单个测试）
• 类型检查 (Typecheck): bun run typecheck（运行 tsgo --noEmit）

• @/* 映射到 ./src/*
• @tui/* 映射到 ./src/cli/cmd/tui/*

命名空间模块 (Namespace modules) —— 代码以 TypeScript 命名空间（Namespace）的形式组织，而不是类（Class）。每个模块导出一个包含其 Zod schema、类型和函数的命名空间：

export namespace Session {
  export const Info = z.object({ ... })
  export type Info = z.infer<typeof Info>
  export const create = fn(z.object({ ... }), async (input) => { ... })
}

Instance.state(init, dispose?) —— 针对每个项目的延迟加载单例。许多模块通过这种方式注册状态。

1. 探索 (Discover)	2. 设计 (Design)	3. 构建 (Build)	4. 部署 (Deploy)	5. 维护与扩展 (Support & Scale)
探索代码库与历史 (Explore codebase and history)	规划项目 (Plan project)	实现代码 (Implement code)	自动化 CI/CD (Automate CI/CD)	调试错误 (Debug errors)
搜索文档 (Search documentation)	制定技术规范 (Develop tech specs)	编写并执行测试 (Write and execute tests)	配置环境 (Configure environments)	大规模重构 (Large-scale refactor)
入职与环境配置 (Onboard & Setup)	定义架构 (Define architecture)	创建提交与 PR (Create commits and PRs)	管理部署 (Manage deployments)	监控使用情况与性能 (Monitor usage & performance)

⚠️ 国内用户会出现不能访问或卡住的问题。

curl -fsSL https://claude.ai/install.sh | bash

安装后的可执行文件路径：/Users/junjian/.local/bin/claude

下面是安装卡住，但是程序已经下载成功，我手动安装完成的过程：

下载的二进制文件会被保存在 ~/.claude/downloads 目录下：

ll ~/.claude/downloads

-rwxr-xr-x  1 junjian  staff   205M  5月 29 22:56 claude-2.1.156-darwin-arm64

我们需要把它移动到 ~/.local/share/claude/versions 目录下，并创建一个软链接到 ~/.local/bin：

在 Python 工具链大洗牌的今天，Astral 团队推出的 uv 已经成为了无可争议的“速度之王”。它不仅能用 Rust 带来百倍的速度提升，还展现出了统一 Python 生态的野心。

然而，很多刚从 pip 或 poetry 迁移过来的开发者，在看到 uv pip、uv add 和 uv tool 这三个都在“装包”的命令时，难免会产生疑问：它们难道不是重合的吗？为什么装个包还要分三种命令？

我们就来彻底拆解这三者的设计哲学和应用场景，帮你建立起最清晰的 uv 工作流。

其实，这是 uv 为了彻底解决 Python 长期以来“全局环境污染”、“虚拟环境混乱”以及“工具与项目依赖混淆”等痛点，而设计的三套完全独立的工作流。

命令	对应传统工具	管理的目标对象	核心作用
uv pip	pip / pip-tools	底层虚拟环境中的包	作为原生 pip 的超快替代品，直接向当前激活的环境中塞入依赖。
uv add	poetry add / pdm add	当前声明式项目的依赖	现代项目管理工作流。自动管理 pyproject.toml 和 uv.lock。
uv tool	pipx	全局可执行工具（如 ruff, black）	在完全隔离的专用环境中安装 CLI 工具，并自动暴露到全局，绝不污染项目。

虽然它们都是给项目安装依赖，但一个是命令式（Imperative），一个是声明式（Dec

• LiteLLM AI Gateway (Proxy) > Config.yaml > Overview
• DAY 0 Support: Gemini 3 on LiteLLM

uv tool install 'litellm[proxy]'

编写配置文件：config.yaml

model_list:
  - model_name: gpt-5
    litellm_params:
      model: openai/LongCat-2.0-Preview
      api_base: https://api.longcat.chat/openai/
      api_key: sk-xxx
  - model_name: gpt-5-nano
    litellm_params:
      model: openai/qwen3.5:9b
      api_base: http://localhost:11434/v1
      api_key: none

litellm --config config.yaml

⚠️ 通过测试说明 LiteLLM 代理只支持中转，上游没有提供对应的API支持（LongCat 只支持 Chat Completions），LiteLLM 也不支持。

使用 ImageMagick 的 magick 命令将一系列按时间顺序命名的 PNG 截屏图片合成为一个无限循环播放的动态 GIF 动图。

事件	描述
agent_start	智能体开始处理
agent_end	运行的最终事件。为此事件等待的订阅者仍会计入结算
turn_start	新轮次开始（一次 LLM 调用 + 工具执行）
turn_end	轮次完成，包含助手消息和工具结果
message_start	任何消息开始（user、assistant、toolResult）
message_update	仅限助手。 包含带有增量的 assistantMessageEvent
message_end	消息完成
tool_execution_start	工具开始执行
tool_execution_update	工具流式传输进度
tool_execution_end	工具执行完成

当你调用 prompt("Hello") 时：

@earendil-works/pi-agent-core

基于 @earendil-works/pi-ai 构建的有状态智能体，支持工具执行和事件流。

npm install @earendil-works/pi-agent-core

本 SDK 提供对 Pi 智能体能力的程序化访问。可用于将 Pi 嵌入其他应用、构建自定义界面，或集成到自动化工作流中。

典型使用场景：

• 构建自定义界面（网页、桌面、移动端）
• 将智能体能力集成到现有应用
• 用智能体推理创建自动化流程
• 构建可生成子智能体的自定义工具
• 以编程方式测试智能体行为

参见 examples/sdk/，获取从极简到全量控制的可运行示例。

SDK 已包含在主包中，无需单独安装。

createAgentSession() 使用 ResourceLoader 提供扩展、技能、提示模板、主题和上下文文件。若未提供，则使用带标准自动发现能力的 DefaultResourceLoader。

通过两种方式，在 TypeScript 中使用 @earendil-works 的 Pi Agent 框架连接本地运行的 Ollama 模型（以 qwen3.5:9b 为例）。

首先，初始化项目并配置为 ES Modules (ESM) 模式，以支持顶层 await 语法。

npm init -y

在生成的 package.json 中，手动添加 "type": "module"：