缺失的工作空间层：Agentic Polyrepo 开发

Source: Dev.to

请提供您希望翻译的具体文本内容，我将按照要求将其译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！

问题概述

编码代理可以在单个仓库中将功能从规格转化为可工作的 PR——这部分基本已经解决。
但要实现功能的 端到端，通常意味着跨多个仓库工作。你需要：

1. 了解跨所有仓库的架构——编码规范、服务关系、各部分如何连接。
2. 协调分支——在每个涉及的仓库中使用相同的功能分支。
3. 跨仓库验证——运行测试、检查状态，并在整个堆栈上进行验证，而不仅仅是在单个检出中。

在单仓库中，代理能够自然地处理所有这些。而跨仓库时，你往往需要手动为每个仓库配置上下文、一次创建一个分支，并切换终端进行验证。

工作区层

Mars 创建一个工作区，所有仓库都位于同一树结构下：

workspace/
├── .claude/          # or .cursor/, .aider.conf — any agent config
├── CLAUDE.md         # shared context: architecture, standards, patterns
├── mars.yaml         # workspace definition
└── repos/
    ├── backend-api/
    ├── frontend-app/
    ├── shared-lib/
    └── infra/

• 工作区根目录下的代理配置会被 每个仓库继承。
• 你只需 一次 配置代理——包括架构概览、编码标准、服务关系——所有仓库会自动获得这些上下文，无需在每个仓库重复配置。

Mars 在此基础上提供结构 以及 跨仓库的操作。

与 Mars + 编码代理的一天

上午同步

mars sync              # pull latest across all repos
mars status            # one table: every repo's branch, dirty state, ahead/behind

开始一个功能

mars branch feature-auth --tag backend    # coordinated branch across backend repos

代理已经从工作区级别的配置中获取了完整的架构上下文，因此它了解各服务之间的关系、编码标准以及需要遵循的模式——跨所有仓库。

验证

mars exec "npm test" --tag frontend   # targeted tests on frontend repos
mars status                           # which repos changed? any drift?

审核与合并

使用您常用的 git/GitHub 工具。Mars 协调工作区；其余工作流程保持不变。

工作区本身可以是 Git 仓库

git clone git@github.com:org/platform-workspace.git
cd platform-workspace
mars clone    # clones all repos defined in mars.yaml
# done — full workspace with shared agent config, all repos, ready to work

• 将版本控制的 mars.yaml 以及 你的代理配置一起管理。
• 任意开发者（或 CI 任务）克隆该仓库，运行 mars clone，即可在两条命令内获得完整的、已启动的工作区。
• 团队入职：几分钟即可开始工作，而不是数小时。
• CI 环境：同样的两条命令即可完成跨仓库的验证设置。
• 标准化：唯一的真相来源，明确哪些仓库应当放在一起，以及代理在这些仓库中的运行方式。

这为你提供了单体仓库的共享上下文和可复现性，却 不 需要耦合 Git 历史、CI 流水线或发布周期。

基于标签的过滤

在 mars.yaml 中的每个仓库都会获得 标签——以适合你项目的方式：

repos:
  - url: git@github.com:org/frontend.git
    tags: [frontend, web]
  - url: git@github.com:org/backend-api.git
    tags: [backend, api, payments]
  - url: git@github.com:org/shared-lib.git
    tags: [shared, backend, frontend]

所有命令都支持 --tag 来定位子集：

mars branch feature-x --tag backend          # branch only backend repos
mars exec "npm test" --tag frontend          # test only frontend repos
mars status --tag payments                    # status for payments‑related repos
mars sync --tag shared                        # pull latest on shared repos only

每个仓库可以拥有多个标签，从而实现 跨领域操作。标记为 [backend, payments] 的仓库会同时出现在 --tag backend 和 --tag payments 查询中。可以按功能、团队、部署组等方式打标签——只要符合你们团队对代码库的认知即可。

与其他多仓库工具的比较

Mars 用 零依赖和简洁性 取代了可扩展性和插件系统。其主要区别在于设计意图：工作区结构使得代理配置共享成为一种自然属性。其他工具管理仓库；Mars 创建一个代理可以驻留的工作区。

安装

npm install -g @dean0x/mars
# or:
brew install dean0x/tap/mars
# or:
curl -fsSL https://raw.githubusercontent.com/dean0x/mars/main/install.sh | bash

快速入门

# 创建工作区
mars init

# 添加仓库（标签是可选的，但推荐使用）
mars add https://github.com/org/frontend.git --tags frontend
mars add https://github.com/org/backend.git  --tags backend

# 克隆所有内容并查看状态
mars clone
mars status

完整文档位于 GitHub：
网站：

何时选择 Mars

• 多个仓库需要一起工作。
• 编码代理是工作流的一部分。
• 您需要在整个技术栈中拥有 共享上下文 和 协同操作。

何时不使用 Mars

• 您的代码库已经是 单一 monorepo（Mars 解决的问题并不存在）。
• 您需要 大量自定义插件生态系统，而 Mars 为了简化刻意避免这些。
• 您有严格的 git‑history 耦合 或发布周期约束，而 monorepo 已经能够满足这些需求。

项目概述

• 仓库结构

  • 紧密耦合的仓库 – 使用 Git 子模块。
  • 单一仓库 – 直接使用普通 Git。

• 平台支持

  • 需要兼容 Windows。

• 许可证

  • 开源，采用 MIT 许可证。

• 社区反馈

  • 我很期待反馈——尤其是来自使用编码代理跨多仓库的朋友。
  • 你的工作空间是怎样的？