尧图网站建设 
Gas Town 联邦架构Federation设计解析多工作区协调、Agent 溯源与 Dolt 联邦配置【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown关联设计文档federation.md导读联邦Federation是 Gas Town 面向多工作区Multi-workspace场景的架构蓝图目标是让多个 Gas Town 实例能够互相引用彼此的工作单元、跨组织协同并追踪分布式项目。本文以官方设计文档为骨架系统讲解其三级实体模型、hop://与beads://统一资源标识URI方案、Agent 溯源Provenance约定以及基于 Dolt 的联邦配置实操DoltHub / 本地 Remotesapi / 自建 DoltLab / Town 直连四种端点方案。读完本文你将理解 Gas Town 如何为分布式团队与多仓库项目设计身份与数据交换层并掌握 Dolt 联邦的完整配置命令与安全边界。状态提示该文档明确标注为Partially implemented部分实现——Dolt remotes 等基础设施已就绪而 URI 方案、跨工作区查询、委托delegation等核心联邦能力尚未实现。本文严格区分已实现与规划中两类内容。一、联邦要解决的问题在单机/单工作区模式下Gas Town 的 daemon 管理一个 Town工作区其下挂载多个 Rig如gastown、beads、wyvern、sky。当组织扩展到多个 Town、多个仓库甚至多个公司时就会出现三类诉求跨工作区引用Town A 的工作单元需要引用 Town B 的工作单元例如depends_on关系跨越两个工作区跨组织协同不同组织维护各自的 Town但需要协作完成一个项目同时保留各自的审计轨迹分布式项目追踪一个项目的工作分散在多个仓库、多个工作区需要统一视图。联邦正是为此设计的协调层它定义了一套实体模型Entity / Chain / Work Unit、一套统一 URI 方案hop://、beads://及短形式以及一套身份溯源约定BD_ACTOR / GIT_AUTHOR_*并依托Dolt 的 Git 式版本化能力DOLT_MERGE、DoltHub remotes作为数据交换的传输底座。从源码结构看dolt-storage.md 中已出现federation_peers (name PRIMARY KEY, remote_url, sovereignty, last_sync)表并在Three Data Planes中将Design 平面标注为通过 DoltHub commons 联邦共享规划中——这正是联邦在存储层的落点。二、实体模型三级分层文档定义了跨工作区协调的三级实体模型Level 1: Entity - Person or organization (flat namespace) Level 2: Chain - Workspace/town per entity Level 3: Work Unit - Issues, tasks, molecules on chains层级名称含义典型例子Level 1Entity实体人或组织扁平命名空间steveexample.com、acmeLevel 2Chain链每个实体下的工作区/Townmain-town、acme/backendLevel 3Work Unit工作单元链上的 issue、任务、moleculegp-xyz、ac-123这一分层与 identity.md 中Human Identity is Global的模型相互印证以 email 作为全局人类身份它已经存在于每个 git commit 中Town 作为工作区agent 执行器gastown/crew/joe、acme/polecats/nux作为执行主体。联邦的三级实体模型把人/组织 → 工作区 → 工作单元显式化为可寻址的命名层级为跨工作区引用提供了结构基础。三、统一 URI 方案hop:// 与 beads://3.1 HOP 协议完整工作单元引用跨工作区引用一个工作单元的完整格式HOP 协议hop://entity/chain/rig/issue-id hop://steveexample.com/main-town/greenplace/gp-xyz即hop:// Entitysteveexample.com Chainmain-town Riggreenplace Issue IDgp-xyz四级路径可完整定位任意工作区中的任意工作单元。3.2 beads:// 协议同平台跨仓库引用在同一托管平台platform上跨仓库引用时使用beads://beads://platform/org/repo/issue-id beads://github/acme/backend/ac-123格式为beads:// 平台github 组织acme 仓库backend Issue IDac-123。3.3 短形式工作区内的首选表达在同一工作区内文档推荐使用更简洁的短形式gp-xyz # Local (prefix routes via routes.jsonl) greenplace/gp-xyz # Different rig, same chain ./gp-xyz # Explicit current-rig refgp-xyz本地引用通过routes.jsonl前缀路由解析greenplace/gp-xyz同 chain同工作区内不同 rig 的引用./gp-xyz显式当前 rig引用。源码佐证routes.jsonl 前缀路由已实现短形式中提到的routes.jsonl前缀路由在仓库中已有完整实现见 routes.go路由记录结构Route{ Prefix, Path }routes.goprefix是 issue ID 前缀如gt-path是从 town root 到.beads目录的相对路径LoadRoutes从beadsDir/routes.jsonl逐行读取 JSON 路由routes.go空行与#注释被跳过畸形行仅告警不中断GetPrefixForRig/GetRigNameForPrefix/GetRigPathForPrefix等函数基于前缀在 town 与 rig 数据库之间解析工作单元归属routes.goResolveBeadsDirForID依据 issue ID 的前缀把操作路由到正确的.beads数据库routes.go。这正是gp-xyz本地短引用的底层机制Gas Town 通过routes.jsonl把前缀gt-、bd-、wy-等映射到具体的 rig 数据库路径实现工作单元 ID 的路由解析。相关测试见 routes_test.go 与 beads_routing_integration_test.go。文档引用说明原文档提及~/gt/docs/hop/GRAPH-ARCHITECTURE.md包含 URI 完整规范该路径位于运行环境非当前仓库完整 URI 规范以该外部文档为准。四、关系类型规划中的关系原语文档明确指出以下关系原语尚未实现not yet implemented属于规划内容employment雇佣关系entity 与 org 之间的成员关系cross-reference交叉引用跨工作区的depends_on链接。作为参考dolt-storage.md 中的dependencies表issue_id/depends_on_id/typetype 取值blocks、parent-child、thread目前仍是工作区内的依赖表达跨工作区的depends_on有待联邦实现后落地delegation委托跨工作区的任务分发附带条款terms与截止时间deadlines例如承包商协调场景中的级联完成cascading completion与溯源保留preserved attribution。五、Agent 溯源Provenance已实现的基石联邦的前提是每个 agent 操作都可归因。文档指出每个 agent 操作都被归因完整 BD_ACTOR 格式约定见 identity.md。该部分能力在实现状态清单中被标记为已实现具体体现在三个层面。5.1 Git 提交溯源# Set per agent session GIT_AUTHOR_NAMEgreenplace/crew/joe GIT_AUTHOR_EMAILsteveexample.com # Workspace owner结果abc123 Fix bug (greenplace/crew/joe steveexample.com)解读GIT_AUTHOR_NAME记录谁做了工作agentGIT_AUTHOR_EMAIL记录谁拥有这项工作工作区所有者两者永久保存在 git 历史中。这正是 identity.md 中Agents are not anonymous / Work is owned, not authored / Attribution is permanent设计原则的落地。5.2 Beads 操作溯源BD_ACTORgreenplace/crew/joe # Set in agent environment bd create --titleTask # Actor auto-populatedbd create会自动从环境变量BD_ACTOR填充created_by字段identity.md 中展示的 beads 记录示例为created_by: gastown/crew/joe、updated_by: gastown/witness。BD_ACTOR 采用斜杠分隔的路径式格式按角色类型区分角色类型格式示例MayormayormayorDeacondeacondeaconWitness{rig}/witnessgastown/witnessRefinery{rig}/refinerygastown/refineryCrew{rig}/crew/{name}gastown/crew/joePolecat{rig}/polecats/{name}gastown/polecats/toast斜杠格式镜像文件系统路径支持层级解析提取 rig / role / name、一致的邮件寻址gt mail send gastown/witness、beads 操作中的路径式路由以及 agent 位置的视觉清晰度。5.3 事件日志溯源所有事件都携带 actor 字段{ ts: 2025-01-15T10:30:00Z, type: sling, actor: greenplace/crew/joe, payload: { bead: gp-xyz, target: greenplace/polecats/Toast } }这套溯源体系使得跨工作区聚合审计成为可能bd audit --actorgastown/crew/joe、git log --authorgastown/crew/joe等查询详见 identity.md是联邦未来多 Town 聚合 CVbd cv steveexample.com规划中的数据基础。从源码看BD_ACTOR在 internal/config/env.go 等处被统一注入 agent 环境config.AgentEnv()负责跨所有 spawn 路径managers、daemon、boot一致地设置环境变量见 identity.md。六、发现机制Discovery规划中的远程注册与查询文档指出工作区元数据存于~/gt/.town.json含 owner、name、public_name 字段规划命令包括gt remote add/list远程注册与管理bd show hop://...跨工作区查看bd list --remote...跨工作区查询。源码路径说明从源码结构看该元数据文件在 Gas Town 中实际位于mayor/town.json——internal/beads/beads.go 的注释显示 town root 通过向上查找mayor/town.json来定位测试代码如 internal/beads/beads_test.go也以mayor/town.json写入{name:test}。文档中的~/gt/.town.json可理解为运行环境中的等价表达实际实现以mayor/town.json为准。七、实现状态清单文档给出的实现状态是理解当前能做什么的关键Agent identity in git commitsgit 提交中的 agent 身份BD_ACTOR default in beads createbd create 的 BD_ACTOR 默认值Workspace metadata file.town.json/mayor/town.json工作区元数据文件Cross-workspace URI schemehop://、beads://、本地短形式Dolt remotes configuredDoltHub 端点已配置Local remotesapi enabled本地 remotesapi 已启用端口 8000DoltHub authenticationdolt login未完成Remote registrationgt remote add未完成Cross-workspace queries跨工作区查询未完成Delegation primitives委托原语未完成八、Dolt 联邦配置已就绪的基础设施8.1 当前配置Town 级 Dolt 数据库已配置指向 DoltHub 的 remotes# Check configured remotes for town database cd ~/gt/.dolt-data/town dolt remote -v # origin https://doltremoteapi.dolthub.com/steveyegge/gastown-town {} # local http://localhost:8000/town {}8.2 已配置的 Remotes数据库Remote 名URL用途townoriginsteveyegge/gastown-townDoltHub 公共联邦townlocalhttp://localhost:8000/town本地开发/测试gastownoriginsteveyegge/gastown-rigDoltHub 公共联邦beadsoriginsteveyegge/gastown-beadsDoltHub 公共联邦8.3 四种联邦端点方案方案 1DoltHub公共联邦推荐类似GitHub for Dolt——公共、托管、零基础设施# Login to DoltHub (one-time setup) dolt login # Push to remote cd ~/gt/.dolt-data/town dolt push origin main方案 2本地 Remotesapi开发/测试已在~/gt/.dolt-data/config.yaml中启用端口8000模式只读完整联邦需设read_only: false# Test local remote dolt push local main方案 3自托管 DoltLab企业级用于组织内私有联邦部署 DoltLab 实例配置远程dolt remote add corp https://doltlab.corp.example.com/org/repo方案 4Town 直连高级两个 Gas Town 实例直接联邦Town A 在可访问端点上运行 remotesapiTown B 将 Town A 添加为远程dolt remote add town-a http://town-a.example.com:8000/town8.4 启用完整联邦的四个步骤DoltHub 认证dolt login # Opens browser for OAuth # Creates credentials in ~/.dolt/creds/创建 DoltHub 仓库访问 DoltHub 站点创建与 remote 名匹配的仓库如steveyegge/gastown-town。首次推送cd ~/gt/.dolt-data/town dolt push -u origin main为本地 remotesapi 开启写权限编辑~/gt/.dolt-data/config.yamlremotesapi: port: 8000 read_only: false # Enable writes重启 daemongt down gt up8.5 安全考量DoltHub默认公开敏感数据请使用私有仓库本地 remotesapi仅绑定 localhost需要网络访问时使用 TLS认证DoltHub 使用 OAuth自托管可使用 TLS 客户端证书。8.6 源码层面的印证internal/cmd/dolt.go 实现了gt dolt系列命令start/stop/status/logs/sql/init-rig/listdaemon 负责管理 Dolt SQL server 生命周期自动启动、每 30 秒健康检查、崩溃指数退避重启这是 remotesapi 得以稳定提供联邦端点的运行前提见 dolt-storage.mdDolt 的DOLT_MERGE能力被用于integration branches, federationdolt-storage.md为联邦数据合入提供底层支撑CHANGELOG.md 中提及Dolt remotes patrol —— 定期向 git remotes 推送以做好联邦准备表明联邦就绪度是持续维护的运维目标。九、未来用例规划文档列出了联邦启用后的目标场景多仓库项目Multi-repo projects用跨工作区引用追踪横跨多个仓库的工作分布式团队Distributed teams团队成员处于不同工作区、共同贡献同一项目各自保留审计轨迹承包商协调Contractor coordination跨组织的委托链级联完成且溯源保留跨工作区查询Cross-workspace queries跨组织的聚合工作视图bd list --org...。这些用例与 identity.md 中的Multi-Town Aggregation人类多 Town 一份 CV以及 WASTELAND.md 中多个 wasteland 可以并存、身份跨环境延续的设想相衔接——联邦是这些远期能力的数据层前提。相关联邦接入流程可参考 mvgt-integration.md。十、总结与演进路线Gas Town 的联邦架构呈现出清晰的分层渐进特征已落地Layer 0Agent 溯源git / BD_ACTOR / 事件日志、工作区元数据、URI 方案定义、Dolt remotes 基础设施DoltHub 本地 remotesapi:8000——这些是联邦可用的传输与身份底座待落地Layer 1dolt login认证、gt remote add/list远程注册、跨工作区查询bd show hop://...、bd list --remote...规划中Layer 2employment / cross-reference / delegation 关系原语以及多仓库、分布式团队、承包商协调等上层用例。对开发者而言当前可立即实践的是通过 identity.md 理解并验证 BD_ACTOR 溯源约定通过 routes.go 理解工作区内的前缀路由并通过第八节的 Dolt 配置步骤把本 Town 的数据库推送到 DoltHub——这些正是未来联邦能力的数据与身份前提。延伸阅读Agent 身份与溯源完整约定Dolt 存储架构与联邦数据平面前缀路由实现gt dolt 命令实现环境变量注入实现环境变量参考MVGT 联邦接入指南【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gas Town 联邦架构（Federation）设计解析：多工作区协调、Agent 溯源与 Dolt 联邦配置
Gas Town 联邦架构Federation设计解析多工作区协调、Agent 溯源与 Dolt 联邦配置【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown关联设计文档federation.md导读联邦Federation是 Gas Town 面向多工作区Multi-workspace场景的架构蓝图目标是让多个 Gas Town 实例能够互相引用彼此的工作单元、跨组织协同并追踪分布式项目。本文以官方设计文档为骨架系统讲解其三级实体模型、hop://与beads://统一资源标识URI方案、Agent 溯源Provenance约定以及基于 Dolt 的联邦配置实操DoltHub / 本地 Remotesapi / 自建 DoltLab / Town 直连四种端点方案。读完本文你将理解 Gas Town 如何为分布式团队与多仓库项目设计身份与数据交换层并掌握 Dolt 联邦的完整配置命令与安全边界。状态提示该文档明确标注为Partially implemented部分实现——Dolt remotes 等基础设施已就绪而 URI 方案、跨工作区查询、委托delegation等核心联邦能力尚未实现。本文严格区分已实现与规划中两类内容。一、联邦要解决的问题在单机/单工作区模式下Gas Town 的 daemon 管理一个 Town工作区其下挂载多个 Rig如gastown、beads、wyvern、sky。当组织扩展到多个 Town、多个仓库甚至多个公司时就会出现三类诉求跨工作区引用Town A 的工作单元需要引用 Town B 的工作单元例如depends_on关系跨越两个工作区跨组织协同不同组织维护各自的 Town但需要协作完成一个项目同时保留各自的审计轨迹分布式项目追踪一个项目的工作分散在多个仓库、多个工作区需要统一视图。联邦正是为此设计的协调层它定义了一套实体模型Entity / Chain / Work Unit、一套统一 URI 方案hop://、beads://及短形式以及一套身份溯源约定BD_ACTOR / GIT_AUTHOR_*并依托Dolt 的 Git 式版本化能力DOLT_MERGE、DoltHub remotes作为数据交换的传输底座。从源码结构看dolt-storage.md 中已出现federation_peers (name PRIMARY KEY, remote_url, sovereignty, last_sync)表并在Three Data Planes中将Design 平面标注为通过 DoltHub commons 联邦共享规划中——这正是联邦在存储层的落点。二、实体模型三级分层文档定义了跨工作区协调的三级实体模型Level 1: Entity - Person or organization (flat namespace) Level 2: Chain - Workspace/town per entity Level 3: Work Unit - Issues, tasks, molecules on chains层级名称含义典型例子Level 1Entity实体人或组织扁平命名空间steveexample.com、acmeLevel 2Chain链每个实体下的工作区/Townmain-town、acme/backendLevel 3Work Unit工作单元链上的 issue、任务、moleculegp-xyz、ac-123这一分层与 identity.md 中Human Identity is Global的模型相互印证以 email 作为全局人类身份它已经存在于每个 git commit 中Town 作为工作区agent 执行器gastown/crew/joe、acme/polecats/nux作为执行主体。联邦的三级实体模型把人/组织 → 工作区 → 工作单元显式化为可寻址的命名层级为跨工作区引用提供了结构基础。三、统一 URI 方案hop:// 与 beads://3.1 HOP 协议完整工作单元引用跨工作区引用一个工作单元的完整格式HOP 协议hop://entity/chain/rig/issue-id hop://steveexample.com/main-town/greenplace/gp-xyz即hop:// Entitysteveexample.com Chainmain-town Riggreenplace Issue IDgp-xyz四级路径可完整定位任意工作区中的任意工作单元。3.2 beads:// 协议同平台跨仓库引用在同一托管平台platform上跨仓库引用时使用beads://beads://platform/org/repo/issue-id beads://github/acme/backend/ac-123格式为beads:// 平台github 组织acme 仓库backend Issue IDac-123。3.3 短形式工作区内的首选表达在同一工作区内文档推荐使用更简洁的短形式gp-xyz # Local (prefix routes via routes.jsonl) greenplace/gp-xyz # Different rig, same chain ./gp-xyz # Explicit current-rig refgp-xyz本地引用通过routes.jsonl前缀路由解析greenplace/gp-xyz同 chain同工作区内不同 rig 的引用./gp-xyz显式当前 rig引用。源码佐证routes.jsonl 前缀路由已实现短形式中提到的routes.jsonl前缀路由在仓库中已有完整实现见 routes.go路由记录结构Route{ Prefix, Path }routes.goprefix是 issue ID 前缀如gt-path是从 town root 到.beads目录的相对路径LoadRoutes从beadsDir/routes.jsonl逐行读取 JSON 路由routes.go空行与#注释被跳过畸形行仅告警不中断GetPrefixForRig/GetRigNameForPrefix/GetRigPathForPrefix等函数基于前缀在 town 与 rig 数据库之间解析工作单元归属routes.goResolveBeadsDirForID依据 issue ID 的前缀把操作路由到正确的.beads数据库routes.go。这正是gp-xyz本地短引用的底层机制Gas Town 通过routes.jsonl把前缀gt-、bd-、wy-等映射到具体的 rig 数据库路径实现工作单元 ID 的路由解析。相关测试见 routes_test.go 与 beads_routing_integration_test.go。文档引用说明原文档提及~/gt/docs/hop/GRAPH-ARCHITECTURE.md包含 URI 完整规范该路径位于运行环境非当前仓库完整 URI 规范以该外部文档为准。四、关系类型规划中的关系原语文档明确指出以下关系原语尚未实现not yet implemented属于规划内容employment雇佣关系entity 与 org 之间的成员关系cross-reference交叉引用跨工作区的depends_on链接。作为参考dolt-storage.md 中的dependencies表issue_id/depends_on_id/typetype 取值blocks、parent-child、thread目前仍是工作区内的依赖表达跨工作区的depends_on有待联邦实现后落地delegation委托跨工作区的任务分发附带条款terms与截止时间deadlines例如承包商协调场景中的级联完成cascading completion与溯源保留preserved attribution。五、Agent 溯源Provenance已实现的基石联邦的前提是每个 agent 操作都可归因。文档指出每个 agent 操作都被归因完整 BD_ACTOR 格式约定见 identity.md。该部分能力在实现状态清单中被标记为已实现具体体现在三个层面。5.1 Git 提交溯源# Set per agent session GIT_AUTHOR_NAMEgreenplace/crew/joe GIT_AUTHOR_EMAILsteveexample.com # Workspace owner结果abc123 Fix bug (greenplace/crew/joe steveexample.com)解读GIT_AUTHOR_NAME记录谁做了工作agentGIT_AUTHOR_EMAIL记录谁拥有这项工作工作区所有者两者永久保存在 git 历史中。这正是 identity.md 中Agents are not anonymous / Work is owned, not authored / Attribution is permanent设计原则的落地。5.2 Beads 操作溯源BD_ACTORgreenplace/crew/joe # Set in agent environment bd create --titleTask # Actor auto-populatedbd create会自动从环境变量BD_ACTOR填充created_by字段identity.md 中展示的 beads 记录示例为created_by: gastown/crew/joe、updated_by: gastown/witness。BD_ACTOR 采用斜杠分隔的路径式格式按角色类型区分角色类型格式示例MayormayormayorDeacondeacondeaconWitness{rig}/witnessgastown/witnessRefinery{rig}/refinerygastown/refineryCrew{rig}/crew/{name}gastown/crew/joePolecat{rig}/polecats/{name}gastown/polecats/toast斜杠格式镜像文件系统路径支持层级解析提取 rig / role / name、一致的邮件寻址gt mail send gastown/witness、beads 操作中的路径式路由以及 agent 位置的视觉清晰度。5.3 事件日志溯源所有事件都携带 actor 字段{ ts: 2025-01-15T10:30:00Z, type: sling, actor: greenplace/crew/joe, payload: { bead: gp-xyz, target: greenplace/polecats/Toast } }这套溯源体系使得跨工作区聚合审计成为可能bd audit --actorgastown/crew/joe、git log --authorgastown/crew/joe等查询详见 identity.md是联邦未来多 Town 聚合 CVbd cv steveexample.com规划中的数据基础。从源码看BD_ACTOR在 internal/config/env.go 等处被统一注入 agent 环境config.AgentEnv()负责跨所有 spawn 路径managers、daemon、boot一致地设置环境变量见 identity.md。六、发现机制Discovery规划中的远程注册与查询文档指出工作区元数据存于~/gt/.town.json含 owner、name、public_name 字段规划命令包括gt remote add/list远程注册与管理bd show hop://...跨工作区查看bd list --remote...跨工作区查询。源码路径说明从源码结构看该元数据文件在 Gas Town 中实际位于mayor/town.json——internal/beads/beads.go 的注释显示 town root 通过向上查找mayor/town.json来定位测试代码如 internal/beads/beads_test.go也以mayor/town.json写入{name:test}。文档中的~/gt/.town.json可理解为运行环境中的等价表达实际实现以mayor/town.json为准。七、实现状态清单文档给出的实现状态是理解当前能做什么的关键Agent identity in git commitsgit 提交中的 agent 身份BD_ACTOR default in beads createbd create 的 BD_ACTOR 默认值Workspace metadata file.town.json/mayor/town.json工作区元数据文件Cross-workspace URI schemehop://、beads://、本地短形式Dolt remotes configuredDoltHub 端点已配置Local remotesapi enabled本地 remotesapi 已启用端口 8000DoltHub authenticationdolt login未完成Remote registrationgt remote add未完成Cross-workspace queries跨工作区查询未完成Delegation primitives委托原语未完成八、Dolt 联邦配置已就绪的基础设施8.1 当前配置Town 级 Dolt 数据库已配置指向 DoltHub 的 remotes# Check configured remotes for town database cd ~/gt/.dolt-data/town dolt remote -v # origin https://doltremoteapi.dolthub.com/steveyegge/gastown-town {} # local http://localhost:8000/town {}8.2 已配置的 Remotes数据库Remote 名URL用途townoriginsteveyegge/gastown-townDoltHub 公共联邦townlocalhttp://localhost:8000/town本地开发/测试gastownoriginsteveyegge/gastown-rigDoltHub 公共联邦beadsoriginsteveyegge/gastown-beadsDoltHub 公共联邦8.3 四种联邦端点方案方案 1DoltHub公共联邦推荐类似GitHub for Dolt——公共、托管、零基础设施# Login to DoltHub (one-time setup) dolt login # Push to remote cd ~/gt/.dolt-data/town dolt push origin main方案 2本地 Remotesapi开发/测试已在~/gt/.dolt-data/config.yaml中启用端口8000模式只读完整联邦需设read_only: false# Test local remote dolt push local main方案 3自托管 DoltLab企业级用于组织内私有联邦部署 DoltLab 实例配置远程dolt remote add corp https://doltlab.corp.example.com/org/repo方案 4Town 直连高级两个 Gas Town 实例直接联邦Town A 在可访问端点上运行 remotesapiTown B 将 Town A 添加为远程dolt remote add town-a http://town-a.example.com:8000/town8.4 启用完整联邦的四个步骤DoltHub 认证dolt login # Opens browser for OAuth # Creates credentials in ~/.dolt/creds/创建 DoltHub 仓库访问 DoltHub 站点创建与 remote 名匹配的仓库如steveyegge/gastown-town。首次推送cd ~/gt/.dolt-data/town dolt push -u origin main为本地 remotesapi 开启写权限编辑~/gt/.dolt-data/config.yamlremotesapi: port: 8000 read_only: false # Enable writes重启 daemongt down gt up8.5 安全考量DoltHub默认公开敏感数据请使用私有仓库本地 remotesapi仅绑定 localhost需要网络访问时使用 TLS认证DoltHub 使用 OAuth自托管可使用 TLS 客户端证书。8.6 源码层面的印证internal/cmd/dolt.go 实现了gt dolt系列命令start/stop/status/logs/sql/init-rig/listdaemon 负责管理 Dolt SQL server 生命周期自动启动、每 30 秒健康检查、崩溃指数退避重启这是 remotesapi 得以稳定提供联邦端点的运行前提见 dolt-storage.mdDolt 的DOLT_MERGE能力被用于integration branches, federationdolt-storage.md为联邦数据合入提供底层支撑CHANGELOG.md 中提及Dolt remotes patrol —— 定期向 git remotes 推送以做好联邦准备表明联邦就绪度是持续维护的运维目标。九、未来用例规划文档列出了联邦启用后的目标场景多仓库项目Multi-repo projects用跨工作区引用追踪横跨多个仓库的工作分布式团队Distributed teams团队成员处于不同工作区、共同贡献同一项目各自保留审计轨迹承包商协调Contractor coordination跨组织的委托链级联完成且溯源保留跨工作区查询Cross-workspace queries跨组织的聚合工作视图bd list --org...。这些用例与 identity.md 中的Multi-Town Aggregation人类多 Town 一份 CV以及 WASTELAND.md 中多个 wasteland 可以并存、身份跨环境延续的设想相衔接——联邦是这些远期能力的数据层前提。相关联邦接入流程可参考 mvgt-integration.md。十、总结与演进路线Gas Town 的联邦架构呈现出清晰的分层渐进特征已落地Layer 0Agent 溯源git / BD_ACTOR / 事件日志、工作区元数据、URI 方案定义、Dolt remotes 基础设施DoltHub 本地 remotesapi:8000——这些是联邦可用的传输与身份底座待落地Layer 1dolt login认证、gt remote add/list远程注册、跨工作区查询bd show hop://...、bd list --remote...规划中Layer 2employment / cross-reference / delegation 关系原语以及多仓库、分布式团队、承包商协调等上层用例。对开发者而言当前可立即实践的是通过 identity.md 理解并验证 BD_ACTOR 溯源约定通过 routes.go 理解工作区内的前缀路由并通过第八节的 Dolt 配置步骤把本 Town 的数据库推送到 DoltHub——这些正是未来联邦能力的数据与身份前提。延伸阅读Agent 身份与溯源完整约定Dolt 存储架构与联邦数据平面前缀路由实现gt dolt 命令实现环境变量注入实现环境变量参考MVGT 联邦接入指南【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考