Gas Town 工作账本Work Ledger架构解析用结构化数据构建企业级多 Agent 编排的可见性、归属与验证体系【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastownGas Town 是 GitHub Trending 精选的 multi-agent workspace manager多 Agent 工作区管理器。本文以 docs/why-these-features.md 为骨架结合仓库源码internal/cmd、internal/beads、internal/events 等系统讲解 Gas Town 如何用工作账本这一核心设计理念回答企业引入 AI Agent 后必然会面临的五个问题谁做了什么、谁可靠、谁能做、什么与什么相关、全局进展如何。读完本文你将掌握 Gas Town 的实体归属Attribution、工作历史Agent CV、递归工作分解、跨项目引用、验证质量门与实时活动流等核心能力的命令用法、数据模型与源码实现位置并能据此评估其在自身多 Agent 编排场景中的适用性。问题当 AI Agent 规模化后工程管理工具集体失效假设你已经部署了一批 AI Agent它们写代码、审 PR、修 Bug、加功能。运行一段时间后你会发现连最基础的问题都回答不上来谁做了什么这段出问题的代码是哪个 Agent 写的谁可靠哪些 Agent 能稳定交付高质量成果谁能做这件事这个 Go 重构该派给哪个 Agent什么与什么相关前端这个改动是否依赖后端的某个 PR全貌是什么12 个仓库的项目整体进展如何传统工具对此无能为力CI/CD 只跟踪构建结果不跟踪能力Git 只跟踪提交不跟踪 Agent 绩效项目管理工具只跟踪工单却无法反映谁实际做了什么、做得怎么样这一微妙现实。解决方案把工作变成结构化数据——Work LedgerGas Town 的核心答案是把工作当作结构化数据来管理。每一次动作都被记录每一个 Agent 都有履历每一份工作都有出处provenance。这不是监控surveillance而是可见性visibility——与任何严肃工程系统所期望的可见性一致。从源码结构看这一理念贯穿于 Gas Town 的四大数据通道中Git 提交通过注入GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL保留 Agent 身份Beads 工单每条工单的created_by/updated_by记录操作者Town Log记录 spawn / done / handoff / crash 等 Agent 生命周期事件事件流~/gt/.events.jsonl中的每条 JSON 事件都携带actor字段。下文逐一展开 Gas Town 如何用这四条通道支撑六大核心能力。功能一实体追踪与归属Entity Tracking and Attribution问题你在 10 个项目里部署了 50 个 Agent。其中某个引入了一个严重 Bug。是哪一个传统git blame只会显示一个笼统的 AI Assistant甚至更糟——显示的是人类的姓名。解决方案Gas Town 中每个 Agent 都有独立身份每一次动作都被归属attributed到具体身份Git commits: gastown/polecats/toast ownerexample.com Beads records: created_by: gastown/crew/joe Event logs: actor: gastown/polecats/nux身份格式BD_ACTOR 约定归属的基础是统一的身份命名。Gas Town 使用BD_ACTOR环境变量以斜杠分隔的路径格式标识 Agent详见 docs/concepts/identity.md该变量在 Agent 被派发时自动设置用于所有归属记录角色类型格式示例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 所在位置。三条归属通道的实现证据1. Git 提交Agent 会话期间设置环境变量让提交同时保留谁写的与归谁所有两层信息见 docs/concepts/identity.mdGIT_AUTHOR_NAMEgastown/crew/joe # 谁做的Agent GIT_AUTHOR_EMAILsteveexample.com # 归谁所有监督者git log中永久保存两者abc123 Fix bug (gastown/crew/joe steveexample.com)。2. Beads 记录Beads 工单的created_by字段在创建时从BD_ACTOR环境变量自动填充。在源码 internal/beads/beads_agent.go 的CreateAgentBead及其 store 路径createAgentBeadViaStore中可以看到CreatedBy: actoractor 来自b.getActor()最终落到BD_ACTOR并打上gt:agent标签用于标识 Agent 生命周期工单。updated_by则记录最后修改记录者。3. 事件日志所有事件都携带 actor 归属。事件模型定义在 internal/events/events.goEvent结构体含Timestamp / Source / Type / Actor / Payload / Visibility字段其中Actor string \json:actor是必备字段事件以 JSON Lines 形式追加写入~/gt/.events.jsonlEventsFile .events.jsonl写入时通过flock 加文件锁保证多进程并发追加安全。为什么重要调试Debugging把问题追溯到具体 Agent而不是笼统的AI 干的合规Compliance为 SOX、GDPR 及企业内控提供审计轨迹——谁在什么时间批准了这段代码问责Accountability精确掌握谁在何时触碰了什么。功能二工作历史与 Agent CVWork History问题你想分配一个复杂的 Go 重构任务手头有 20 个 Agent有的擅长 Go有的从未碰过有的不稳定。怎么选解决方案每个 Agent 都持续积累工作历史形成可查询的履历# 这个 Agent 做过什么 bd audit --actorgastown/polecats/toast # 在 Go 项目上的成功率 bd stats --actorgastown/polecats/toast --taggo注bd为 Beads 生态的 CLI在 Gas Town 仓库内工作历史查询的等价实现是gt audit源码见 internal/cmd/audit.go而 Agent CV 汇总的等价实现是gt polecat identity show源码见 internal/cmd/polecat_identity.go。bd stats/bd skills属于能力统计类功能当前仓库中尚无对应实现属于原文档中已标注为 Planned 的能力路由功能的一部分。gt audit跨数据源的统一工作历史gt audit是一个真正的账本查询命令——它不是查单一数据源而是把四类来源汇聚成一条统一时间线源码见 internal/cmd/audit.go 的runAudit数据源内容实现位置Git 提交该 actor 署名的 commitgit log --all --author...collectGitCommitsBeads 工单该 actor 创建的工单created_by与关闭的工单按assigneecollectBeadsActivityTown Logspawn / done / handoff / crash / kill / nudge / wake 等生命周期事件collectTownlogEvents事件流.events.jsonl中的 sling / merged / handoff / done / mail 等事件collectFeedEvents命令参数来自 internal/cmd/audit.gogt audit --actorgreenplace/crew/joe # 查看 joe 的全部工作 gt audit --actorgreenplace/polecats/toast # 查看 polecat toast 的工作 gt audit --actormayor # 查看 mayor 的活动 gt audit --since24h # 最近 24 小时全部活动 gt audit --actorjoe --since1h # 组合过滤 gt audit --json # JSON 输出便于脚本化处理--actor按 Agent 地址过滤支持部分匹配matchesActor会从完整 actor 中提取末段名称做模糊匹配--since时间窗过滤支持1h、24h等 Go duration并额外支持7d这类天级后缀parseDuration--limit/-n最大条数默认 50--json结构化输出AuditEntrytimestamp / source / type / actor / summary / details / id方便对接自动化审计流水线。文本输出会按日期分组展示[git]、[beads]、[log]、[events]四种来源用不同样式区分crash、kill 等异常事件有独立高亮一眼可定位问题 Agent。gt polecat identity showCV 摘要gt polecat identity show rig name展示单个 polecat 的角色卡源码见 internal/cmd/polecat_identity.go 的polecatIdentityShowCmd身份工单 ID 与创建日期会话数session count完成统计完成 / 失败 / 放弃的工单数语言分布按文件扩展名统计如 Go、Python、TypeScript 各占多少工作类型分布feat / fix / refactor 等最近工作列表带相对时间。gt polecat identity show gastown Toast gt polecat identity show gastown Toast --json该命令还支持add从 rig 的名称池生成名字、rename改名但保留 CV 历史——新建身份工单、复制 CV 链接、关闭旧工单、remove带安全检查与--force。为什么重要绩效管理用客观数据评估 Agent 可靠性而不是凭感觉能力匹配把工作路由到有成功经验的 Agent持续改进识别表现不佳的 Agent 以便调优。这在A/B 测试模型时尤其有价值让 Claude 与 GPT 承担相似任务跟踪完成率与质量用数据做模型选型决策。功能三基于能力的路由Capability-Based Routing状态规划中Planned—— 技能追踪与自动路由尚未实现。当前工作分配通过gt sling手动完成。问题你有 Go、Python、TypeScript、Rust 多种技术栈的工作Agent 能力参差不齐人工分配无法规模化。设计方案工作携带技能要求Agent 具备从工作历史推导出的已证实能力匹配自动化# Agent 能力由工作历史推导 bd skills gastown/polecats/toast # → go: 47 tasks, python: 12 tasks, typescript: 3 tasks # 基于匹配度路由 gt dispatch gt-xyz --prefer-skillgo当前仓库的实际状态从仓库源码检索看gt dispatch --prefer-skill形式的技能路由命令尚未实现gt dispatch目前仅存在于 internal/cmd/dog.go 的dogDispatchCmdgt dog dispatch --plugin name把插件执行派发给空闲的 dog 工人走Deacon 指派 → 邮件下发指令 → dog 执行并回传 DOG_DONE的流程。因此原文档中的bd skills与gt dispatch --prefer-skill应视为设计愿景实际落地前以gt sling手动分配为准。当前工作分配入口gt slinggt sling被官方定位为THE unified work dispatch command统一工作派发命令见 internal/cmd/sling.go能力覆盖派发给现有 Agentmayor、crew、witness、refinery目标为 rig 时自动派生 polecat派发给 dogDeacon 的辅助工人公式实例化与 wisp 创建自动创建 convoy 以便在仪表盘可见除非--no-convoy。gt sling gt-abc gastown # 派发工单并自动创建 convoy gt sling gt-abc gastown --no-convoy # 跳过自动 convoy gt sling gt-abc gastown --mergedirect # 完成后直接推 main gt sling gt-abc gastown --mergemr # 走合并队列默认 gt sling gt-abc gastown --mergelocal # 保留在功能分支 gt sling gt-abc # 派给自己 gt sling gp-abc greenplace # 在 rig 中自动派生 polecat gt sling gt-abc greenplace/Toast # 派给指定 polecat gt sling gt-abc gastown --crew mel # 派给 crew 成员 gt sling gt-abc deacon/dogs # 自动派发给空闲 dog为什么重要设计动机效率合适的人Agent干合适的活质量Agent 在擅长的领域表现更好规模消除人工分派瓶颈。功能四递归工作分解Recursive Work Decomposition问题企业项目复杂度高——一个feature会裂变成跨 8 个仓库、4 个团队、50 个任务的网状结构。扁平的问题列表无法承载这种结构。解决方案工作天然地递归分解Epic: User Authentication System ├── Feature: Login Flow │ ├── Task: API endpoint │ ├── Task: Frontend component │ └── Task: Integration tests ├── Feature: Session Management │ └── ... └── Feature: Password Reset └── ...每一层都有自己的依赖链汇总roll-up自动完成——你随时知道自己处在什么位置。源码实现Convoy 与依赖图递归分解的底层载体是Convoy车队系统internal/cmd/convoy.go共 2900 行与 Beads 的依赖表Epic → Feature → Task 层级gt convoy launch/gt convoy stage等命令把大型目标拆解为可跟踪的 convoy 结构gt convoy --tree提供树形视图依赖查询convoy 通过 dependencies 表按方向遍历——downissue_id → depends_on_id找下游updepends_on_id → issue_id找上游对应SELECT issue_id FROM dependencies WHERE depends_on_id ?这类 SQL见 internal/cmd/convoy.go 中的依赖遍历逻辑自动汇总gt sling单条工单也会自动创建 convoyswarm of one保证所有工作都能在gt convoy list中出现从而让整体进度视图完整。为什么重要可见性既见森林又见树木协调依赖关系显式化进度追踪每一层都有准确的状态。功能五跨项目引用Cross-Project References问题前端必须等后端 API 落地才能发布而两者在不同的仓库。传统工具不追踪这种跨仓库依赖。解决方案显式的跨项目依赖depends_on: beads://github/acme/backend/be-456 # 后端 API beads://github/acme/shared/sh-789 # 共享类型数据模型IssueDep 与依赖类型在 Beads 的数据模型中依赖被建模为结构化的IssueDep见 internal/beads/beads.go 第 350 行起type IssueDep struct { ID string json:id Title string json:title Status string json:status Priority int json:priority Type string json:issue_type DependencyType string json:dependency_type,omitempty CloseReason string json:close_reason,omitempty }依赖关系被明确区分为阻塞型与非阻塞型两类源码中的blockingDependencyTypes/nonblockingDependencyTypes映射阻塞型blocks、conditional-blocks、waits-for、merge-blocks非阻塞型tracks、parent-child、related、discovered-from、thread。基于该模型HasUnresolvedBlockers(issue)判断工单是否存在未解决的阻塞依赖FirstUnresolvedBlockerID(issue)返回第一个阻塞者 ID见 internal/beads/beads.go 的unresolvedBlockingDependencyIDs实现——这正是你知道什么在挡路的代码级支撑。URI 设计从本地短格式到跨仓库跨仓库引用的完整 URI 体系在 docs/design/federation.md 中定义同平台跨仓库引用采用beads://platform/org/repo/issue-id beads://github/acme/backend/ac-123同一工作区内优先使用短格式gp-xyz本地通过routes.jsonl前缀路由、greenplace/gp-xyz同 chain 不同 rig、./gp-xyz显式当前 rig 引用。为什么重要无意外明确知道什么在阻塞什么协调团队能看见自己对别人的影响规划基于真实依赖关系做现实排期。功能六联邦Federation状态规划中Planned—— 基于 Highway Operations ProtocolHOP的联邦能力已完成设计但尚未实现。Gas Town 目前以单城镇single-town系统运行。问题企业项目横跨多个仓库、多个团队有时还跨越多个组织承包商、合作伙伴。可见性碎片化。设计中的解决方案相互引用的联邦化工作区# 注册远程工作区 gt remote add partner hop://partner.com/their-project # 跨工作区查询 bd list --remotepartner --tagintegration设计文档中的联邦架构按 docs/design/federation.md状态标注为 Partially implemented——Dolt 远端基础设施已存在URI 方案、跨工作区查询、委派等核心联邦能力尚未实现联邦采用三级实体模型Level 1: Entity - 个人或组织扁平命名空间 Level 2: Chain - 每个实体的工作区/城镇 Level 3: Work Unit - Chain 上的工单、任务、分子完整的工作单元引用HOP 协议hop://entity/chain/rig/issue-id hop://steveexample.com/main-town/greenplace/gp-xyz设计中还规划了三类关系原语employment实体与组织成员关系、cross-reference跨工作区depends_on链接、delegation带条款与期限的跨工作区工作委派——目前均未实现。为什么重要设计动机企业规模不被单一仓库思维限制承包商协作追踪委派出去的工作分布式团队尽管仓库分离仍保持统一视图。功能七验证与质量门Validation and Quality Gates问题Agent 说做完了。真的做完了吗代码质量合格吗通过评审了吗解决方案带归属的结构化验证{ validated_by: gastown/refinery, validation_type: merge, timestamp: 2025-01-15T10:30:00Z, quality_signals: { tests_passed: true, review_approved: true, lint_clean: true } }实现落点Refinery 合并队列质量门在 Gas Town 中的实际执行者是Refinery精炼厂——合并队列处理器。事件模型internal/events/events.go 与 internal/cmd/activity.go定义了一组与验证流水线直接对应的事件类型merge_started—— Refinery 开始处理一个 MRmerge_complete/merged—— 合并成功merge_failed—— 合并失败冲突、测试不过等merge_skipped—— 跳过已合并等queue_processed—— Refinery 处理完整个队列。gt sling --mergemr即把工作纳入这条队列由 Refinery 负责在合并前把关gt dog dispatch则把带质量门open gates的插件工作分派给 dog 执行。由此门是数据而非仅仅策略gates are data, not just policy这一理念在仓库中有可运行的事件流支撑。为什么重要质量控制不要信任要验证dont trust, verify审计轨迹谁在何时批准了什么流程执行质量门是一等公民数据不只是口头制度。功能八实时活动流Real-Time Activity Feed问题复杂的多 Agent 工作是不透明的。你往往要等它完成或失败才知道发生了什么。解决方案把工作状态做成实时流bd activity --follow [14:32:08] patrol-x7k.arm-ace bonded (5 steps) [14:32:09] → patrol-x7k.arm-ace.capture in_progress [14:32:10] ✓ patrol-x7k.arm-ace.capture completed [14:32:14] ✓ patrol-x7k.arm-ace.decide completed [14:32:17] ✓ patrol-x7k.arm-ace COMPLETE仓库中的实现gt feed 与 gt activity实时流的仓库内实现是gt feedinternal/cmd/feed.go与gt activity emitinternal/cmd/activity.go。gt feed默认启动交互式 TUI 仪表盘聚合三类事件源feed.NewMultiSourceGT 事件Agent 活动patrol、sling、handoff读自.events.jsonlBeads 活动工单创建、更新、完成Convoy 状态进行中与近期落地的 convoy每 10 秒刷新。TUI 布局顶部 Agent 树按角色组织、显示最新活动、中间 Convoy 面板、底部可滚动事件流Vim 风格导航j/k滚动、tab切换面板、1/2/3选面板、q退出。--problems/-p进入问题优先视图通过结构化 beads 数据hook 状态、时间戳检测卡死 Agent并显示 GUPP 违规hooked work 30 分钟无进展按Enter附加、n提醒nudge、h交接。常用参数gt feed # 启动 TUI 仪表盘 gt feed --problems # 从问题视图启动 gt feed --plain # 纯文本输出等价于 bd activity gt feed --window # 在专用 tmux 窗口打开 gt feed --since 1h # 只看最近一小时 gt feed --rig greenplace # 用指定 rig 的 beadsgt feed --plain支持--limit默认 100、--since、--mol按分子/工单 ID 前缀过滤、--typecreate/update/delete/comment、--rig过滤且当 stdout 非 TTY管道、Agent 场景时自动禁用 follow 模式避免阻塞。gt activity emit允许任意 Agent/角色向流中写入事件事件类型与必需参数如下gt activity emit patrol_started --rig greenplace --count 3 gt activity emit polecat_checked --rig greenplace --polecat Toast --status working --issue gp-xyz gt activity emit polecat_nudged --rig greenplace --polecat Toast --reason idle for 10 minutes gt activity emit escalation_sent --rig greenplace --target Toast --to mayor --reason unresponsive gt activity emit patrol_complete --rig greenplace --count 3 --message All polecats healthy事件符号约定源码中列出创建/绑定、→进行中、✓完成、✗失败、⊘删除、patrol 开始、⚡提醒、sling、交接MQ 符号⚙merge 开始、✓merged、✗merge 失败、⊘merge 跳过。为什么重要实时调试问题发生时即时可见状态感知永远知道什么在跑模式识别发现瓶颈与低效环节。企业价值主张The Enterprise Value PropositionGas Town 本质上是开发者工具——像 IDE 之于编程Gas Town 之于 AI 编排。但它的架构提供了企业级地基能力开发者收益企业收益归属Attribution调试 Agent 问题合规审计工作历史Work history调优 Agent 分派绩效管理技能路由Skill routing更快完成任务资源优化联邦Federation多仓库项目跨组织可见性验证Validation质量保证流程执行活动流Activity feed实时调试运营感知模型评估在可比任务上部署不同模型客观跟踪结果用数据决定哪个模型用在哪儿长周期项目观察 Agent 不止在单任务上的表现而是在复杂、多阶段、跨职能项目中的整体表现跨职能团队在仓库、团队甚至组织之间保持统一可见性。设计哲学Design Philosophy这些能力不是事后拼装的外挂而是架构地基。原文档总结了五条设计原则且每一条都能在仓库中找到实现锚点归属不可省略Attribution is not optional——每个动作都有 actor。支撑internal/events/events.go 中Event.Actor为必填字段docs/concepts/identity.md 定义 BD_ACTOR 全角色命名约定。工作即数据Work is data——不只是工单而是结构化、可查询的数据。支撑internal/beads/beads.go 中Issue/IssueDep的完整 JSON 模型与unresolvedBlockingDependencyIDs等查询逻辑。历史很重要History matters——履历决定信任。支撑internal/cmd/audit.go 跨四源汇聚时间线internal/cmd/polecat_identity.go 的 CV 摘要与改名保留 CV。规模是默认前提Scale is assumed——从第一天就面向多仓库、多 Agent、多组织。支撑docs/design/federation.md 的 HOP URI 与三级实体模型当前为规划态。验证优先于信任Verification over trust——质量门是一等公民原语。支撑Refinery 合并队列的merge_started / merged / merge_failed / merge_skipped事件闭环与gt sling --mergemr入口。结语为企业的下一个问题而建Gas Town 的设计目标是当 AI Agent 成为工程工作流的核心时回答企业必然要提出的那些问题。当前仓库中归属、工作历史gt audit、gt polecat identity show、递归分解convoy dependencies、验证Refinery 合并队列与实时活动流gt feed均已落地可运行而基于技能的路由bd skills/gt dispatch --prefer-skill与跨组织联邦HOP则明确标注为 Planned是值得关注的演进方向。对正在规模化多 Agent 编排的团队而言这套工作账本思路——把可见性、归属与验证内建为数据原语——本身就是可复用的架构范式。延伸阅读仓库内身份与归属约定见 docs/concepts/identity.md联邦架构设计见 docs/design/federation.md工作派发命令见 internal/cmd/sling.go活动流 TUI 见 internal/cmd/feed.go 与 internal/tui/feed依赖与工单数据模型见 internal/beads/beads.go。【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
