kin v0.3.6

AI 智能体写出一次变更的速度，快于团队弄清它涉及什么、是否推翻了此前的修复、以及其影响能蔓延多远。Git 记录文件和行历史。Kin 则将软件本身记录为实体、关系、变更和溯源构成的图，从而为人类和智能体提供一个可查询、可审查的语义权威。一项变更所触及的内容会在合并前显现出来，智能体也能基于精确上下文工作，而无需重新通读代码库。

Kin 是 AI 编写软件的系统级语义事实记录。它是一个公开 alpha 版本，现在即可作为本地 CLI、守护进程、MCP 服务器、审查界面和图驱动文件系统投影使用。它处于 1.0 之前，因此请预期会有粗糙之处和破坏性变更。在将其用于关键工作流之前，请先查看最新稳定版本和当前限制。

在真实代码库上查看效果

ripgrep 中一处一行级签名变更在 diff 中看起来无害。在任何编译器运行之前，用 kin impact 询问它，它会指出该编辑所触及的范围。变更签名的调用者排在前面，然后是这些调用者背后牵动的所有内容。

针对 ripgrep 提交 e89fff89ac9af12e8d4ce9d5fd07beb408ca730f 的预构建图记录。3 跳内 13 个受影响实体，包括变更签名的 3 个直接调用者。图是预先构建的。没有运行任何编译器。确切命令：kinlab.ai/proof。原始运行目录尚不公开，因此这是一份可重新运行的配方，而非可审计的追踪记录。

Kin 呈现变更所触及的内容。变更是否正确，仍由你的编译器、测试和审查来判断。图由 kin init 预先构建，构建过程是成本较高的部分；此后，影响类问题基于图数据真相对答，而非重新读取目录树。

技术栈

Kin 是一个系统，带有几个清晰的公开界面：

各组件如何协同

Kin 是 AI 编写软件的系统级语义事实记录，下图中的一切要么接入该权威，要么为其提供支撑。人类和 AI 智能体通过 CLI、捆绑的 MCP 服务器或 VS Code 扩展接入。三者都询问同一个守护进程，而守护进程基于图权威作答，而非重新读取目录树。kin-vfs 通过普通文件系统调用将同一张图投影回去，因此编辑器、编译器和构建系统看到的仍然是文件。Git 作为导入和导出边界位于图旁边，而不是答案来源路径；KinLab 则是同一权威之上的托管层。

flowchart TD
    people["Humans and AI agents"]

    subgraph surfaces["Access surfaces"]
        cli["kin CLI"]
        mcp["Kin MCP server"]
        editor["kin-editor for VS Code"]
    end

    daemon["kin daemon"]
    authority["Graph authority<br/>entities, relations, changes, provenance"]
    db["kin-db<br/>graph storage, snapshots,<br/>index, text and vector search"]
    prims["kin-model, kin-blobs, kin-search,<br/>kin-vector, kin-infer, kin-lsp"]
    vfs["kin-vfs<br/>transparent file projection"]
    tools["Editors, compilers, build systems"]
    git["Git<br/>import and export boundary"]
    kinlab["KinLab<br/>hosted collaboration and control plane"]

    people --> cli
    people --> mcp
    people --> editor
    cli --> daemon
    mcp --> daemon
    editor --> daemon
    daemon --> authority
    authority --> db
    db --> prims
    authority <-->|"kin init imports, kin git export"| git
    authority -->|"publish and sync"| kinlab
    authority --> vfs
    vfs --> tools

这些界面之下，是系统赖以构建的各层：

这些是一个系统的实现层，而非需要新用户自行组装的产品。它们都不需要单独安装。

开源与 Kin 生态系统

Kin 的核心采用 Apache-2.0 开源：kin、kin-db、kin-vfs 和 kin-editor，以及支撑库 kin-model、kin-blobs、kin-search、kin-vector、kin-infer、kin-lsp 和 kin-actions。

KinLab 是基于这一开源核心构建的专有产品：即上文所述的托管协作与控制平面层。

同样的边界也适用于基准测试工作的共享方式。基准测试规范和一个独立的、无依赖的包验证器是公开的，因此任何论断都可以在无需访问产生它的系统的情况下被查验。生成密封证据包（sealed evidence bundles）的运行器和证明基础设施（编排、固定版本证明门禁、托管测量环境）目前仍为私有。规范和验证器先行开放；运行器可以稍后开放。

最短的图驱动上手路径

1. 安装并配置 Kin

在 macOS 或 Linux 上：

curl -fsSL https://get.kinlab.dev/install | sh
exec "$SHELL" -l
kin setup --intent agent

安装程序解析最新稳定版本，校验其发布的 SHA-256 校验和，将受管二进制安装到 ~/.kin 下，并启动设置流程。以显式的 agent 意图运行，会为检测到的受支持客户端配置内置 MCP 服务器。若不进行 MCP 配置、仅用于 CLI 和文件系统，请使用 --intent local；VS Code 路径则使用 --intent editor。

如需仅移除设置流程管理的集成，运行 kin setup uninstall。对于默认受管根目录（~/.kin），kin setup uninstall --all 还会停止所有 Kin 守护进程、移除精确匹配的旧版安装程序 PATH 块，并递归删除受管安装（--dry-run 可预览）。自定义的 KIN_HOME 永远不会被递归删除：请先运行 ledger 范围内的卸载，然后自行检查并显式删除该目录。被修改过的、由设置流程拥有的片段会阻止完整卸载，除非你添加 --force，因此卸载绝不会静默覆盖用户编辑过的客户端或 shell 配置。在 Windows 上，CLI 会在运行进程退出后立即将其锁定的安装目录排入删除计划。Windows 有意保留一个惰性的、仅限当前用户的同级权威 sidecar；保持该锁标识稳定，可防止崩溃或并发的未来安装创建两个独立的变更权威。CLI 和 JSON 结果会披露这份保留的协调元数据，而不是声称残留字节为零。

手动安装时，每个归档及其 .sha256 文件均发布在 https://github.com/firelock-ai/kin/releases/latest/download/ 之下。动态资源名称为 kin-macos-aarch64、kin-macos-x86_64、kin-linux-aarch64、kin-linux-x86_64 和 kin-windows-x86_64；请使用最新发布页上显示的 .tar.gz 后缀。Windows 还发布 kin-windows-x86_64.zip，PowerShell 安装程序和 npm 启动器获取的正是这个文件。

npm 入口解析的是同一个公开发布渠道：

npm install -g @kinlab/kin@latest

一个 Homebrew tap 跟踪同一个发布渠道：

brew install firelock-ai/kin/kin

该 tap 的 formula 是生成的，而非手工维护。其版本和各平台 SHA-256 由 tap 仓库中的 update-formula.yml 在发布自身发送的分发事件触发下，根据每次 Kin 发布重新生成，并配有每六小时一次的对账，可自愈漏掉的发布。这就是为什么 Homebrew 校验的校验和与归档旁发布的校验和相同，而非另行维护的副本。请像在任何安装路径上一样，用 kin --version 确认你安装的内容。

在 Windows 上，请在 PowerShell 中运行 irm https://get.kinlab.dev/install.ps1 | iex。原生 Windows x86_64 支持仍处于早期。代码库收录可用：kin init 导入 Git 代码库并发布图权威，图查询、词法查询以及守护进程支持的查询均可原生应答。Windows 上不提供透明文件系统投影，安装证明也尚未端到端覆盖该平台的 MCP 或审查工作流，因此 WSL2 仍是完整体验 Kin 的推荐路径。在选择 Windows 安装路径之前，请先阅读下文平台与成熟度。

2. 将现有代码库收录为图数据真相

cd /path/to/your/repository
kin init .

在被检测到的 Git 代码库中，kin init 以原子方式将完整可达历史、引用、原始对象、精确工作区树以及收录策略收录进 repository-v6 图权威。带有未提交编辑、暂存变更或未跟踪文件的工作树仍可收录：kin init 收录已提交状态，并披露未收录的内容。它绝不会用精确 HEAD 快照或原始文件系统语义重建来替代。受支持的代码库本地远程 URL、refspec、分支跟踪和推送默认值会被封存进 Kin 的 Git 共存配置；不安全、有歧义或不支持的传输设置会在发布前失败关闭。

收录过程还会为该历史中每个受支持的实体源文件推导语义实体与关系层，并且 kin init 会报告其提交的、按代际绑定的持久计数。kin status 报告该代码库权威视图；kin graph status 则单独报告守护进程的可变实时查询图，其中可能包含后续推导的增强数据。查询界面在存在图持有的增强数据时会使用它，并在缺失时报告缺失，而不是用原始文件搜索掩盖这一缺口。

哪些文件会成为实体

「受支持的实体源文件」指被 Kin 某个语言适配器认领的文件。适配器注册表即为完整集合，代码库中的每个文件都通过它来判定归属：

当 .h 头文件的内容表明其属于 C++ 时，它会被按 C++ 读取，因此 C++ 项目不会因 C 语法而丢失命名空间和模板。

其余所有文件都会作为内容被收录，仍可按历史和文本查询，但不会被解析为实体和关系。这包括 Markdown、HTML 和 CSS、SQL、YAML、JSON 和 TOML、shell 脚本、Objective-C、Scala、Elixir、Dart、Lua、R、Zig、Haskell 和 Nix。如果你的语言在这个列表中，locate 和 refs 将无法在其中找到符号。

3. 向图提出真实问题

kin locate "where are webhook retries handled"
kin refs ExactEntityName
kin trace ExactEntityName

将 ExactEntityName 替换为 locate 返回的符号。locate 查找与某个意图相关的实体，refs 显示图持有的调用者/导入者及引用，trace 返回焦点实体及附近的语义上下文。嵌入完成后，你配置的 AI 智能体即可使用基于向量的 semantic_locate 工具；get_context_pack、find_references 和 trace_data_flow 则直接暴露图邻域。

收录过程推导的是语义实体，而非其向量。运行 kin embed 为它们添加本地向量相似度，并用 kin graph status 确认覆盖范围。

审查 AI 编写的变更

AI 编写代码。Kin 证明变更了什么。

在你想要审查的分支上运行 kin init，让相关 Git 历史进入图中，然后将显式的提交 SHA 传给仅报告的 shadow 门禁：

kin review shadow "$(git rev-parse main)..$(git rev-parse HEAD)"

结果会是 PASS、NEEDS ATTENTION 或 WOULD BLOCK，并附带 Kin 从图中推导出的影响、修复所需的上下文，以及二者背后的证据。作者归属是声明式的，而非核验的。该命令不会阻止你的合并，也不会改变图状态。它把证据交给人类或 CI 策略，然后便到此为止。

Kin 与 Git 的关系

现阶段与 Git 并行存在。随时间推移，代码库权威将逐步转移。在存量代码库（brownfield）采纳期间，Git 仍然是显式的导入/导出互操作边界；它绝不回答 Kin 的运行时查询，也不修复缺失的图数据真相。

• kin init 导入完整可达的 Git 历史和精确的父边。Kin 刻意不提供部分历史或仅快照的初始化模式。
• 导入之后，Kin 的图持有代码库身份、目录树状态、历史、引用和语义关系。文件系统视图与 Git 视图都是投影。
• kin git export --output ../repo.git 从单个图持有的权威代际写入一个新的裸 Git 投影。它不查询工作文件，也不依赖环境中已有的 .git/ 对象存储，并且会拒绝已存在或位于代码库内的目标路径。对象、引用和目录会在无替换目标发布被确认前刷新落盘。基于能力锚定的发布目前仅在 Unix 主机上可用；其他主机会在创建导出之前直接拒绝。

这让团队能够在 Kin 成为权威的同时迁移现有代码库，而无需放弃编辑器、编译器、构建系统或 Git 互操作能力。

平台与成熟度

核心运行时与文件系统投影有着不同的支持边界：

首次索引会读取完整可达的 Git 历史，因此在大型或长期存续的代码库上，kin init 在嵌入开始前需要数分钟而非数秒。init 返回后，守护进程会在后台继续准备，大型代码库上的首次智能体调用响应时间会明显更长。

受限的 arm64 测试发现，核心图和词法路径在 512 MB 下可用，但完整嵌入需要下载约 522 MB 的模型，目前需要 2 GB 作为安全运行下限；1 GB 处于不安全边缘，512 MB 可能在嵌入过程中终止。这些是观察到的 alpha 约束，而非普适的内存规格承诺。

kin --version 成功仅能说明核心二进制可以运行，并不能说明 VFS 兼容性或实时的图驱动投影。在受支持的 Unix 主机上，请使用 kin setup status、kin-vfs status --workspace . 以及真实的 kin-vfs exec --workspace . -- <command> 启动。VFS 启动器包含一个 interposition 金丝雀，当操作系统剥离 shim 时会报告。kin-vfs README 包含完整边界说明。

发布产物均附带校验和发布，发布工作流在其支持的 runner 矩阵上运行匿名安装、守护进程/MCP、嵌入以及真实的图驱动 VFS 投影检查。工作流本身是公开的：Install Proof。一次绿色的发布只证明这些确切的产物和环境；它并不声称每个发行版、工具或代码库形态都已覆盖。

证明立场

已发布的预注册 Multi-SWE-Bench Go 证明包固定在一个较旧的构建上，而非动态更新的最新发布，因此它并不确立宽泛的速度、token 节省或类别优胜主张。在独立验证完成之前，此处不公布对比结果。

请在公开证明包中阅读方法论、任务集、构建身份和产物。在该可测量范围之外的主张，在获得自身可复现的证明之前，请将其视为假设。

学习与贡献

• 快速入门与高级配置
• 存储大小及其驱动因素
• MCP 工具参考
• 语言支持及各层提取内容
• 环境变量参考
• 图优先论文
• 写入权威模型及其过渡状态
• GitHub Discussions
• 错误报告与功能请求
• 贡献指南
• 私密安全报告

许可证

Apache-2.0.

会记住自己的软件。