数据目录AI Agent人工智能知识管理示例工程【免费下载链接】knowledge-catalogGoogle Cloud Knowledge Catalog Tools and Samples项目地址https://gitcode.com/gh_mirrors/kn/knowledge-catalog点击查看免费下载导读分阶段交付计划 是toolbox/mdcodekcmd / Metadata as Code项目的工程路线图它以五个 Phase 定义了如何在 Knowledge CatalogDataplex之上构建元数据即代码Metadata as Code基础设施从 Phase 1 的只读快照与消费TypeScript 库 CLI MCP到 Phase 2 的基础发布push再到 Phase 3 的布局抽象与知识库kb表示、Phase 4 的健壮同步与状态管理以及 Phase 5 的未来工作流。读完本文你将掌握这套路线图中每个阶段的交付目标、对应的关键特性与验收测试并能对照仓库源码src/libts 与 tests/scenarios核实各阶段的实际落地程度从而在自己的项目里复刻这套库 CLI MCP三层架构与增量交付节奏。一、路线图背景为什么需要分阶段交付Metadata as Code 的核心主张是让数据管理员、数据生产者与 AI Agent 用**源码工件YAML Markdown**来创作、管理与消费元数据并借助版本控制与 CI/CD 完成上下文工程context engineering。概念文档 将其拆解为若干基石面向人与 Agent 双端友好的文件表示、与 Catalog 服务的双向同步、以及 1st party / 3rd party 元数据构造的完整支持。分阶段交付计划 正是这份构想的工程化拆解。它把庞大的能力面切成可独立验收的五个阶段每个阶段都包含四类交付物LibraryTypeScript核心库能力CLITypeScript-basedkcmd命令行MCPTypeScript-based供外部 Agent 调用的工具服务器Distribution 与 Testing分发方式与验收测试。之所以采用先只读、后写入、再重构表示、最后加固状态的顺序是为了尽早把快照消费这条价值链路打通——Phase 1 即可让用户与 Agent 通过 MCP 读取本地元数据快照随后再逐步补齐发布与数据完整性能力。这与 规范文档 中Library 面向 Knowledge Catalog Enrichment Agent但设计上可被任何构建 Agent 或自定义工具的开发者复用的定位一致。二、Phase 1MVP —— 只读快照与消费2.1 阶段目标Phase 1 的目标是用 TypeScript 库把元数据拉取到本地文件结构并通过 MCP 提供对该快照的只读访问支持早期分发。这一阶段刻意不写入服务端先把消费闭环跑通。2.2 关键特性与源码对照计划文档为 Phase 1 列出的关键工作如下交付物计划内容仓库中的实现证据Library (TS)为 BigQuery Dataset 或 Dataplex EntryGroup 拉取元数据创建镜像资源层级的本地目录结构按 Entry 生成主 YAML 文件Standard 布局分页拉取ADC 认证资源源实现位于 src/libts/sourcesbq-dataset.tsingestedEntries trueStandard 布局与 entrygroup.ts本地目录由 CatalogSnapshot 承载其_storeEntry通过source.localName(entry)把服务端 Entry 映射为本地文件名CLI (TS-based)实现kcmd init与只读kcmd pull命令处理器位于 src/tool/commands.ts入口在 src/tool/main.tskcmd init --bigquery-dataset projectId.datasetId与kcmd pull用法见 README.mdMCP (TS-based)提供list-entries与lookup-entry工具只读本地快照MCP 服务器实现在 src/tool/mcp.ts与 CLI 共用同一个kcmd二进制通过kcmd mcp --path root启动Distribution支持从源码仓库或本地包安装以早期试用项目以 npm 包 Bun 构建的独立二进制分发构建/测试命令见 README.mdTesting为 BigQuery Dataset 与 EntryGroup 的快照创建和目录布局实现测试用例场景化测试位于 tests/scenariospull_basic.yamlEntryGroup 单 Entry 拉取、pull_bq.yamlBigQuery 拉取、init_bqds.yaml动态初始化2.3 分页拉取与 ADC 认证的实现细节分页拉取在源码中体现为CatalogSource.entries()返回AsyncGenerator由 CatalogSync.pull() 用for await逐条消费async pull(): PromiseSyncResult { const entries this._snapshot.manifest.source.entries(this._catalog.context); for await (const entry of entries) { // 按 snapshot 配置过滤 entryType逐条 lookup 并写入本地快照 const res await this._catalog.lookupEntry(project, location, entry.name, [...this._snapshot.aspectTypes.keys()]); if (res.status ! 200 || !res.result) { continue; } await this._snapshot._storeEntry(res.result); } return { success: true }; }例如 BigQueryDatasetSource.entries() 先通过 BigQuery API 枚举数据集再逐个数据集枚举表然后以bigquery系统 EntryGroup 内的 Entry 名逐条lookupEntry。这一枚举 逐条读取的模式天然支持大规模资源的分页消费。认证方面设计文档 明确采用Application Default CredentialsADCApiContext.default()通过gcloud读取默认 project 与 token并在收到 401 时自动调用context.refresh()gcloud auth print-access-token。使用前需执行gcloud auth application-default login。2.4 Phase 1 验收形态本地快照目录Phase 1 交付的本地快照采用 Standard 布局其目录形态见 概念文档 与 规范文档path/to/root/ ├── catalog.yaml # Manifestscope、snapshot 等配置 └── catalog/ # 快照内容 └── dir1/ ├── entry-id1.yaml # 单文件 Entry元数据全部内联 └── dir2/ ├── entry-id2.yaml # 多文件 Entry └── entry-id2.aspect.md # 非结构化方面的 Markdown sidecar其中 bq-dataset.ts 的localName()给出了 BigQuery 资源的本地命名规则数据集映射为projectId.datasetId表映射为projectId.datasetId/tableIdroutine/model 则进入routines/projectId.datasetId/id子目录以避免与同名表冲突。这正对应计划文档强调的目录结构与资源层级对齐。三、Phase 2MVP —— 基础 Push发布3.1 阶段目标Phase 2 补上双向同步的另一半允许本地修改被推回 Catalog 服务。计划要求库支持读取本地 YAML 并重建 API payload、按 Entry 逐个推送更新、支持通过catalog.yaml中的publishing配置做解析与过滤CLI 侧实现基础kcmd push。3.2 关键特性与源码对照交付物计划内容仓库中的实现证据Library (TS)读取本地 YAML 重建 API payload按 Entry 逐个推送publishing配置过滤snapshot.ts 的_fetchEntry()在推送前检查publishingConfig.entries是否包含该 Entry 类型不包含则返回undefined跳过toServiceEntry()在组装 aspect 时同样按publishingConfig.aspects过滤CLI (TS-based)实现基础kcmd pushkcmd push命令及--dry-run/--force等选项见 README.md 与 commands.tsDistribution更新早期访问包以包含 push 能力与 Phase 1 相同经 npm / Bun 二进制分发Testing基础 push 操作与 publishing 配置过滤的测试tests/scenarios 下的 push_custom.yaml、push_filtered.yaml、push_bq.yaml、push_new_entry.yaml3.3publishing是snapshot的子集Manifest 的硬校验Phase 2 的核心语义是发布集合必须是快照集合的子集这在 manifest.ts 中做了强校验publishing中列出的 entry 或 aspect 类型若未出现在snapshot对应列表中CatalogManifest.load()会直接抛错。同时snapshot中被列出但未列入publishing的类型如>scope: bq-dataset.ecommerce-prod.ecommerce-dataset snapshot: entries: - bigquery-dataset - bigquery-table aspects: - overview - descriptions - queries - guidelines ->赞分享数据目录AI Agent人工智能知识管理示例工程【免费下载链接】knowledge-catalogGoogle Cloud Knowledge Catalog Tools and Samples项目地址https://gitcode.com/gh_mirrors/kn/knowledge-catalog点击查看免费下载相关推荐OpenChamber Isolated Spaces 分阶段落地路线图STAGES.md 全解读OpenChamber Isolated Spaces 分阶段落地路线图STAGES.md 全解读 STAGES.md 是 OpenChamber 隔离空间AI Agent人工智能代码智能体交互助手Screenshot-to-code代码重构路线图从基础到高级的分阶段改进计划Screenshot to code代码重构路线图从基础到高级的分阶段改进计划 Screenshot to code是一个革命性的开源项目它能够将网页截图自示例工程因子回测完整实战指南用backtrader快速验证选股策略因子回测完整实战指南用backtrader快速验证选股策略 很多人说回测是正收益实盘就亏坑往往不在策略而在回测环节佣金设得太低、数据缺了几年、信号金融科技数据分析机器学习上一篇3步实现Jellyfin硬件加速让你的媒体服务器性能提升300%下一篇DamaiHelper大麦抢票脚本使用指南告别手动刷票的烦恼创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考