Beads KV 存储设计解读用bd kv为编码 Agent 构建跨会话的轻量级记忆【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beadsBeads 项目为编码 Agent 提供了记忆增强能力而bd kv子命令体系就是其中一块关键拼图它以键值对的形式持久化那些放不进 issue 模型的轻量级元数据——特性开关、项目配置、工作流状态乃至 Agent 跨上下文轮换存续的短记忆。本文以仓库中的设计文档 engdocs/design/kv-store.md 为骨架结合当前仓库中已落地的实现代码cmd/bd/kv.go、internal/storage/kvkeys/kvkeys.go与测试用例完整讲解bd kv的命令用法、底层存储模型、同步机制、保留命名空间约束以及面向未来的扩展设计读完即可上手使用并理解其内部原理。一、为什么需要 KV 存储issue 模型之外的轻量元数据Beads 的核心数据模型是 issuebead它承载 id、标题、描述、状态、优先级、类型等完整字段生命周期遵循open → work → close。但对很多场景来说这套模型过于笨重特性开关bd kv set debug_mode true一条布尔标记即可项目配置bd kv set entry_point src/main.ts供后续 Agent 会话读取跨会话工作流状态bd kv set current_sprint 42记录进行中的上下文Agent 短记忆在上下文轮换后依然存活的轻量记忆。设计文档明确给出了两条为什么不用现有机制的决策理由为什么不用 config 表config 表承载的是 Beads 内部设置同步模式、集成配置等把用户数据与内部配置混在一起会产生命名空间冲突独立表更干净也能避免未来冲突。为什么不把 KV 对变成 issue/beadKV 讲究轻量issue 有显著的开销id、标题、描述、状态等两者的生命周期完全不同——KV 是set and forget设置后不再维护issue 是open → work → close而且把 KV 做成 issue 会污染bd list的查询结果。从当前仓库的实现看这一设计意图得到了保留cmd/bd/kv.go中kvCmd的 Long 描述明确写道KV 存储用于存储在会话之间持久化的 flags、环境变量或其他用户自定义数据。二、命令体系set / get / clear / list设计文档规划的命令签名如下bd kv set key value # Set a key-value pair bd kv get key # Get a value (exit 1 if not found) bd kv delete key # Delete a key bd kv list [prefix] # List all pairs (optionally filtered by prefix)所有命令都支持--json输出。需要注意的一点是文档草案规划的是delete而仓库中实际落地实现为clear。在 cmd/bd/kv.go 中删除子命令的Use是clear key输出为Cleared key。这是设计与实现存在差异的典型例证使用时应以仓库当前行为为准。2.1 完整用法示例# 存储项目元数据 bd kv set primary_language go bd kv set entry_point cmd/bd/main.go # 读取值未找到时输出 (not set) 并静默以非零码退出 bd kv get primary_language # Output: go # 列出全部键值对按键名排序 bd kv list # Output: # Key-Value Store: # entry_point cmd/bd/main.go # primary_language go # 前缀过滤文档规划的能力注意当前实现按 --json 及全量返回为主 bd kv list entry # Output: # entry_point cmd/bd/main.go # JSON 输出 bd kv list --json # Output: {entry_point:cmd/bd/main.go,primary_language:go} # 删除键 bd kv clear primary_language # Output: Cleared primary_language执行细节与文档差异的说明文档示例的 JSON 输出形如[{key:primary_language,value:go,set_at:2026-01-21T10:30:00Z,set_by:beads/crew/collins},...]即包含set_at、set_by元数据的数组形态而当前实现中bd kv list --json输出的是{key:value}形式的扁平 map见 cmd/bd/kv.go 的printKVListResult。这对应了文档中是否在 config 之上单独建表记录set_at/set_by这一尚待 Dolt 团队评审的设计分歧——当前实现优先保证了机器可读性set_at/set_by元数据留待后续演进。bd kv get对不存在的键遵循SilentExit契约非 JSON 模式下向 stderr 输出key (not set)并以非零码退出便于脚本判错JSON 模式下返回{key:...,value:,found:false}见printKVGetResultcmd/bd/kv.go。2.2 参数校验与保留命名空间validateKVKeycmd/bd/kv.go在写入前对 key 施加严格约束这是一般 KV 工具不具备的安全层校验规则理由key 不能为空或纯空白基础合法性key 不能以kv.开头防止产生嵌套的kv.kv.*前缀破坏前缀隔离key 不能以memory.开头保留给bd remember/bd forget的持久记忆命名空间避免与 merge resolver 的自动冲突解决机制互相干扰GH#2474key 不能以sync.、conflict.、federation.、jira.、linear.、export.、import.开头这些是内部配置前缀用户写入会造成命名空间污染其中的kv.与memory.前缀由独立包 internal/storage/kvkeys/kvkeys.go 集中定义Prefix kv.、MemoryPrefix memory.、MemoryConfigKeyPrefix kv.memory.。该包的文档注释揭示了设计动机此前前缀散落在cmd/bd/kv.go、cmd/bd/memory.go和 storage 层三处结构上被迫复制的副本里任何一处的重命名都会静默漂移导致 merge resolver 匹配不到真实记忆键、pull/sync 配置楔子config wedge在改名后悄悄复发。集中定义后一次修改即可被契约测试 internal/storage/kvkeys/kvkeys_test.go 捕获——该测试把kv.memory.前缀钉死为不可变契约。三、存储模型config 表上的前缀层设计文档规划的是独立 Dolt 表CREATE TABLE kv ( key VARCHAR(255) PRIMARY KEY, value TEXT NOT NULL, set_at DATETIME NOT NULL, set_by VARCHAR(255) NOT NULL );ColumnTypeDescriptionkeyVARCHAR(255)主键查找键valueTEXT存储的值恒为字符串set_atDATETIME设置时间UTCset_byVARCHAR(255)设置者如 beads/crew/collins、human而当前仓库的实际实现走的是另一条路KV 存储是config 表之上的薄前缀层thin prefix layer。kvPairsFromConfigcmd/bd/kv.go把全部 config 键值过滤出kv.前缀并剥离前缀得到用户视角的 KV 对写入时则反向拼接kvPrefix key作为实际存储键通过store.SetConfig/store.GetConfig/store.DeleteConfig/store.GetAllConfig完成读写见kvSetCmd/kvGetCmd/kvClearCmd/kvListCmd的 RunE。这套前缀层方案天然继承了 config 表已有的同步、合并、并发控制能力与文档中独立 Dolt 表 独立 RPC的规划形成对照属于设计演进中的合理简化。这一点在 proxied-server 模式的实现注释中讲得最直白cmd/bd/kv_proxied_server.go 写道kv store 是 config 表之上一个薄前缀层kv.*因此这些处理器镜像 config_proxied_server.go每次写调用一次 RunTx 并携带真实提交消息读用 RunTxRead。其中写操作set/clear走uow.RunTx提交消息形如bd: kv set key成功后置位commandDidWrite读操作get/list走uow.RunTxRead底层存储错误原样透传如Merge conflict detected、constraint violation, transaction rolled back调用方据此重试——这保证了错误语义在经典模式与代理服务器模式之间不漂移。四、同步行为随 config 一起走的共享记忆设计文档规划的同步链路是导出push 时 KV 表导出到.beads/kv.jsonl导入pull 时.beads/kv.jsonl导回 KV 表合并基于set_at时间戳的 last-write-wins。JSONL 格式为每行一个 JSON 对象{key:primary_language,value:go,set_at:2026-01-21T10:30:00Z,set_by:beads/crew/collins} {key:entry_point,value:cmd/bd/main.go,set_at:2026-01-21T10:31:00Z,set_by:human}文档论证了该格式的三个优势git 中人类可读且可 diff、流式友好追加无需重写、与issues.jsonl模式一致。在当前实现中由于 KV 落位在 config 表内同步行为与配置同步天然统一kv.*行跟随 config 数据一起参与同步与合并。doctor命令提供了可视化的健康检查——cmd/bd/doctor/kv.go中的CheckKVSyncStatus打开数据库、统计kv.前缀条目数输出类似12 KV pairs stored (syncs via Dolt)的检查结果表明 KV 数据通过 Dolt 同步是当前实现的事实路径。set_at/set_by归属信息在文档中被论证为支持多方写入场景下的冲突解决当前实现把这一职责留给了 Dolt 的合并能力与 config 层的冲突处理。五、服务器模式下的 RPC 操作设计规划对于 server 模式设计文档规划在 RPC 协议中新增以下操作OperationArgsResponsekv_set{key, value}{success: bool}kv_get{key}{value: string, found: bool}kv_delete{key}{success: bool}kv_list{prefix?: string}{items: [{key, value, set_at, set_by}]}当前仓库以另一种等价机制实现了 server 模式支持bd kv在检测到usesProxiedServer()时自动路由到 cmd/bd/kv_proxied_server.go 的四个runKV*ProxiedServer处理器通过 UnitOfWork 的RunTx/RunTxRead在代理服务器上执行而输出复用printKV*共享助手——注释特别强调下游邮件传输解析kv list --json输出必须跨模式字节级一致。这保证了经典直连模式与代理服务器模式的输出形状永不漂移。六、并发与行为验证测试怎么说仓库用三层测试锁定了 KV 的行为契约单元测试cmd/bd/kv_test.go直接以kv.为前缀的键调用SetConfig/GetConfig/DeleteConfig覆盖 set/get、不存在的键返回空串、覆盖更新、删除后不可见等基础语义嵌入式集成测试cmd/bd/kv_embedded_test.go以真实bd二进制运行bd kv set/get/list/clear覆盖写入覆盖overwrite、含空格的值、--json解析、缺参报错并发测试TestEmbeddedKVConcurrent用 8 个 worker 各写 5 个键再读回验证了并发写受one writer at a time排他锁约束未持锁的写方会收到明确错误代理服务器集成测试cmd/bd/kv_proxied_integration_test.go验证 proxied-server 路径的输出与经典模式一致。运行嵌入式集成测试需要设置BEADS_TEST_EMBEDDED_DOLT1环境变量见测试文件头部的 skip 逻辑这也是本仓库 Dolt 相关集成测试的统一约定。七、未来扩展方向v1 之外的预留设计设计文档明确列出了不在 v1 范围内、但设计已为之留出空间的四个方向本地专用键Local-only keys可用_local.前缀约定表示不同步的键TTL/过期后续可增加expires_at列命名空间Namespaces可增加namespace列做作用域隔离值类型当前仅支持字符串未来可加--typejson标志。结合当前实现这些扩展方向与kv.前缀层模型的兼容性值得关注memory.保留命名空间已经是命名空间化的先行案例set_at/set_by元数据文档中为冲突解决预留当前未在 CLI 表面暴露若未来落地 JSON 数组形态的输出或独立kv表需要同步更新printKVListResult与测试中的 JSON 解析逻辑cmd/bd/kv_embedded_test.go 的bdKVListJSON以{起始的扁平 map 解析是一个需要随演进维护的解析契约。八、与其他存储机制的边界bd kv并非 Beads 中唯一的持久化手段理解边界有助于选择正确的工具config 表bd config内部设置同步模式、集成配置用户键受前缀校验保护不得侵入issue/beadbd create等完整工作项有生命周期与状态流转出现在bd list中bd remember持久记忆位于kv.memory.命名空间merge resolver 对这类键自动以--theirs解决冲突bd kv set的校验规则阻止普通用户键写入该命名空间避免用户数据被远端静默覆盖cmd/bd/kv.go 注释详述了该设计动机bd kv轻量、set-and-forget、跨会话的用户自定义数据随 config 同步。结语bd kv是 Beads 中小而美的设计样本一份处于 Draft 状态的设计文档规划了独立 Dolt 表、RPC 操作与set_at/set_by元数据而落地实现则务实地选择了 config 表前缀层方案在继承同步、合并、排他锁能力的同时用kvkeys单点前缀定义与三层测试守住了命名空间契约。对使用者而言bd kv set/get/clear/list足以覆盖特性开关、项目配置与跨会话 Agent 记忆的绝大多数场景对想要扩展它的开发者而言engdocs/design/kv-store.md 中未来考虑一节与文档末尾留给 Dolt 团队的四个评审问题schema 设计、DATETIME 存储方式、同步合并的 Dolt 细节、冲突解决归属正是下一步演进的路线图。【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Beads KV 存储设计解读：用 `bd kv` 为编码 Agent 构建跨会话的轻量级记忆
Beads KV 存储设计解读用bd kv为编码 Agent 构建跨会话的轻量级记忆【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beadsBeads 项目为编码 Agent 提供了记忆增强能力而bd kv子命令体系就是其中一块关键拼图它以键值对的形式持久化那些放不进 issue 模型的轻量级元数据——特性开关、项目配置、工作流状态乃至 Agent 跨上下文轮换存续的短记忆。本文以仓库中的设计文档 engdocs/design/kv-store.md 为骨架结合当前仓库中已落地的实现代码cmd/bd/kv.go、internal/storage/kvkeys/kvkeys.go与测试用例完整讲解bd kv的命令用法、底层存储模型、同步机制、保留命名空间约束以及面向未来的扩展设计读完即可上手使用并理解其内部原理。一、为什么需要 KV 存储issue 模型之外的轻量元数据Beads 的核心数据模型是 issuebead它承载 id、标题、描述、状态、优先级、类型等完整字段生命周期遵循open → work → close。但对很多场景来说这套模型过于笨重特性开关bd kv set debug_mode true一条布尔标记即可项目配置bd kv set entry_point src/main.ts供后续 Agent 会话读取跨会话工作流状态bd kv set current_sprint 42记录进行中的上下文Agent 短记忆在上下文轮换后依然存活的轻量记忆。设计文档明确给出了两条为什么不用现有机制的决策理由为什么不用 config 表config 表承载的是 Beads 内部设置同步模式、集成配置等把用户数据与内部配置混在一起会产生命名空间冲突独立表更干净也能避免未来冲突。为什么不把 KV 对变成 issue/beadKV 讲究轻量issue 有显著的开销id、标题、描述、状态等两者的生命周期完全不同——KV 是set and forget设置后不再维护issue 是open → work → close而且把 KV 做成 issue 会污染bd list的查询结果。从当前仓库的实现看这一设计意图得到了保留cmd/bd/kv.go中kvCmd的 Long 描述明确写道KV 存储用于存储在会话之间持久化的 flags、环境变量或其他用户自定义数据。二、命令体系set / get / clear / list设计文档规划的命令签名如下bd kv set key value # Set a key-value pair bd kv get key # Get a value (exit 1 if not found) bd kv delete key # Delete a key bd kv list [prefix] # List all pairs (optionally filtered by prefix)所有命令都支持--json输出。需要注意的一点是文档草案规划的是delete而仓库中实际落地实现为clear。在 cmd/bd/kv.go 中删除子命令的Use是clear key输出为Cleared key。这是设计与实现存在差异的典型例证使用时应以仓库当前行为为准。2.1 完整用法示例# 存储项目元数据 bd kv set primary_language go bd kv set entry_point cmd/bd/main.go # 读取值未找到时输出 (not set) 并静默以非零码退出 bd kv get primary_language # Output: go # 列出全部键值对按键名排序 bd kv list # Output: # Key-Value Store: # entry_point cmd/bd/main.go # primary_language go # 前缀过滤文档规划的能力注意当前实现按 --json 及全量返回为主 bd kv list entry # Output: # entry_point cmd/bd/main.go # JSON 输出 bd kv list --json # Output: {entry_point:cmd/bd/main.go,primary_language:go} # 删除键 bd kv clear primary_language # Output: Cleared primary_language执行细节与文档差异的说明文档示例的 JSON 输出形如[{key:primary_language,value:go,set_at:2026-01-21T10:30:00Z,set_by:beads/crew/collins},...]即包含set_at、set_by元数据的数组形态而当前实现中bd kv list --json输出的是{key:value}形式的扁平 map见 cmd/bd/kv.go 的printKVListResult。这对应了文档中是否在 config 之上单独建表记录set_at/set_by这一尚待 Dolt 团队评审的设计分歧——当前实现优先保证了机器可读性set_at/set_by元数据留待后续演进。bd kv get对不存在的键遵循SilentExit契约非 JSON 模式下向 stderr 输出key (not set)并以非零码退出便于脚本判错JSON 模式下返回{key:...,value:,found:false}见printKVGetResultcmd/bd/kv.go。2.2 参数校验与保留命名空间validateKVKeycmd/bd/kv.go在写入前对 key 施加严格约束这是一般 KV 工具不具备的安全层校验规则理由key 不能为空或纯空白基础合法性key 不能以kv.开头防止产生嵌套的kv.kv.*前缀破坏前缀隔离key 不能以memory.开头保留给bd remember/bd forget的持久记忆命名空间避免与 merge resolver 的自动冲突解决机制互相干扰GH#2474key 不能以sync.、conflict.、federation.、jira.、linear.、export.、import.开头这些是内部配置前缀用户写入会造成命名空间污染其中的kv.与memory.前缀由独立包 internal/storage/kvkeys/kvkeys.go 集中定义Prefix kv.、MemoryPrefix memory.、MemoryConfigKeyPrefix kv.memory.。该包的文档注释揭示了设计动机此前前缀散落在cmd/bd/kv.go、cmd/bd/memory.go和 storage 层三处结构上被迫复制的副本里任何一处的重命名都会静默漂移导致 merge resolver 匹配不到真实记忆键、pull/sync 配置楔子config wedge在改名后悄悄复发。集中定义后一次修改即可被契约测试 internal/storage/kvkeys/kvkeys_test.go 捕获——该测试把kv.memory.前缀钉死为不可变契约。三、存储模型config 表上的前缀层设计文档规划的是独立 Dolt 表CREATE TABLE kv ( key VARCHAR(255) PRIMARY KEY, value TEXT NOT NULL, set_at DATETIME NOT NULL, set_by VARCHAR(255) NOT NULL );ColumnTypeDescriptionkeyVARCHAR(255)主键查找键valueTEXT存储的值恒为字符串set_atDATETIME设置时间UTCset_byVARCHAR(255)设置者如 beads/crew/collins、human而当前仓库的实际实现走的是另一条路KV 存储是config 表之上的薄前缀层thin prefix layer。kvPairsFromConfigcmd/bd/kv.go把全部 config 键值过滤出kv.前缀并剥离前缀得到用户视角的 KV 对写入时则反向拼接kvPrefix key作为实际存储键通过store.SetConfig/store.GetConfig/store.DeleteConfig/store.GetAllConfig完成读写见kvSetCmd/kvGetCmd/kvClearCmd/kvListCmd的 RunE。这套前缀层方案天然继承了 config 表已有的同步、合并、并发控制能力与文档中独立 Dolt 表 独立 RPC的规划形成对照属于设计演进中的合理简化。这一点在 proxied-server 模式的实现注释中讲得最直白cmd/bd/kv_proxied_server.go 写道kv store 是 config 表之上一个薄前缀层kv.*因此这些处理器镜像 config_proxied_server.go每次写调用一次 RunTx 并携带真实提交消息读用 RunTxRead。其中写操作set/clear走uow.RunTx提交消息形如bd: kv set key成功后置位commandDidWrite读操作get/list走uow.RunTxRead底层存储错误原样透传如Merge conflict detected、constraint violation, transaction rolled back调用方据此重试——这保证了错误语义在经典模式与代理服务器模式之间不漂移。四、同步行为随 config 一起走的共享记忆设计文档规划的同步链路是导出push 时 KV 表导出到.beads/kv.jsonl导入pull 时.beads/kv.jsonl导回 KV 表合并基于set_at时间戳的 last-write-wins。JSONL 格式为每行一个 JSON 对象{key:primary_language,value:go,set_at:2026-01-21T10:30:00Z,set_by:beads/crew/collins} {key:entry_point,value:cmd/bd/main.go,set_at:2026-01-21T10:31:00Z,set_by:human}文档论证了该格式的三个优势git 中人类可读且可 diff、流式友好追加无需重写、与issues.jsonl模式一致。在当前实现中由于 KV 落位在 config 表内同步行为与配置同步天然统一kv.*行跟随 config 数据一起参与同步与合并。doctor命令提供了可视化的健康检查——cmd/bd/doctor/kv.go中的CheckKVSyncStatus打开数据库、统计kv.前缀条目数输出类似12 KV pairs stored (syncs via Dolt)的检查结果表明 KV 数据通过 Dolt 同步是当前实现的事实路径。set_at/set_by归属信息在文档中被论证为支持多方写入场景下的冲突解决当前实现把这一职责留给了 Dolt 的合并能力与 config 层的冲突处理。五、服务器模式下的 RPC 操作设计规划对于 server 模式设计文档规划在 RPC 协议中新增以下操作OperationArgsResponsekv_set{key, value}{success: bool}kv_get{key}{value: string, found: bool}kv_delete{key}{success: bool}kv_list{prefix?: string}{items: [{key, value, set_at, set_by}]}当前仓库以另一种等价机制实现了 server 模式支持bd kv在检测到usesProxiedServer()时自动路由到 cmd/bd/kv_proxied_server.go 的四个runKV*ProxiedServer处理器通过 UnitOfWork 的RunTx/RunTxRead在代理服务器上执行而输出复用printKV*共享助手——注释特别强调下游邮件传输解析kv list --json输出必须跨模式字节级一致。这保证了经典直连模式与代理服务器模式的输出形状永不漂移。六、并发与行为验证测试怎么说仓库用三层测试锁定了 KV 的行为契约单元测试cmd/bd/kv_test.go直接以kv.为前缀的键调用SetConfig/GetConfig/DeleteConfig覆盖 set/get、不存在的键返回空串、覆盖更新、删除后不可见等基础语义嵌入式集成测试cmd/bd/kv_embedded_test.go以真实bd二进制运行bd kv set/get/list/clear覆盖写入覆盖overwrite、含空格的值、--json解析、缺参报错并发测试TestEmbeddedKVConcurrent用 8 个 worker 各写 5 个键再读回验证了并发写受one writer at a time排他锁约束未持锁的写方会收到明确错误代理服务器集成测试cmd/bd/kv_proxied_integration_test.go验证 proxied-server 路径的输出与经典模式一致。运行嵌入式集成测试需要设置BEADS_TEST_EMBEDDED_DOLT1环境变量见测试文件头部的 skip 逻辑这也是本仓库 Dolt 相关集成测试的统一约定。七、未来扩展方向v1 之外的预留设计设计文档明确列出了不在 v1 范围内、但设计已为之留出空间的四个方向本地专用键Local-only keys可用_local.前缀约定表示不同步的键TTL/过期后续可增加expires_at列命名空间Namespaces可增加namespace列做作用域隔离值类型当前仅支持字符串未来可加--typejson标志。结合当前实现这些扩展方向与kv.前缀层模型的兼容性值得关注memory.保留命名空间已经是命名空间化的先行案例set_at/set_by元数据文档中为冲突解决预留当前未在 CLI 表面暴露若未来落地 JSON 数组形态的输出或独立kv表需要同步更新printKVListResult与测试中的 JSON 解析逻辑cmd/bd/kv_embedded_test.go 的bdKVListJSON以{起始的扁平 map 解析是一个需要随演进维护的解析契约。八、与其他存储机制的边界bd kv并非 Beads 中唯一的持久化手段理解边界有助于选择正确的工具config 表bd config内部设置同步模式、集成配置用户键受前缀校验保护不得侵入issue/beadbd create等完整工作项有生命周期与状态流转出现在bd list中bd remember持久记忆位于kv.memory.命名空间merge resolver 对这类键自动以--theirs解决冲突bd kv set的校验规则阻止普通用户键写入该命名空间避免用户数据被远端静默覆盖cmd/bd/kv.go 注释详述了该设计动机bd kv轻量、set-and-forget、跨会话的用户自定义数据随 config 同步。结语bd kv是 Beads 中小而美的设计样本一份处于 Draft 状态的设计文档规划了独立 Dolt 表、RPC 操作与set_at/set_by元数据而落地实现则务实地选择了 config 表前缀层方案在继承同步、合并、排他锁能力的同时用kvkeys单点前缀定义与三层测试守住了命名空间契约。对使用者而言bd kv set/get/clear/list足以覆盖特性开关、项目配置与跨会话 Agent 记忆的绝大多数场景对想要扩展它的开发者而言engdocs/design/kv-store.md 中未来考虑一节与文档末尾留给 Dolt 团队的四个评审问题schema 设计、DATETIME 存储方式、同步合并的 Dolt 细节、冲突解决归属正是下一步演进的路线图。【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考