Archcore MCP Server

官方

本地 stdio MCP 服务器，让 AI 编码代理直接从你的仓库中读取并维护结构化的架构、规则和决策。

文档

Archcore CLI

让你的 AI 代理停止猜测，开始遵循你的架构。

Git 交付你的代码。CI/CD 交付你的交付流程。Archcore 交付你的理解。

Archcore 将你的决策、规则和约定存储在 Git 中——让你的 AI 代理自动遵循它们。适用于 Claude Code、Cursor、Copilot、Gemini CLI、Codex、OpenCode、Roo Code 和 Cline。

Archcore 以 CLI 和本地 stdio MCP 服务器的形式交付——任何兼容 MCP 的编码代理都可以通过标准工具读取和写入你的仓库上下文，而 Claude Code / Cursor 插件则增加了更高层的工作流层。

正在使用 Claude Code 或 Cursor？ 将 CLI 与 Archcore 插件配对使用——相同的引擎，外加开箱即用的技能、意图命令和护栏。坚持使用 CLI 也很棒——它适用于所有其他代理。

60 秒快速上手

curl -fsSL https://archcore.ai/install.sh | bash
cd your-project && archcore init

然后打开你的 AI 代理并说：

"我们使用 PostgreSQL 作为主存储。记录这个决策。"

完成。现在 .archcore/ 中有一个结构化的 ADR，每个未来的会话——在任何代理中——都可以读取。

在 Windows 上？使用 PowerShell：irm https://archcore.ai/install.ps1 | iex。对于 WSL，go install，以及其他选项，请参阅安装方法或完整安装指南。

向你的 AI 询问类似以下内容

一旦你的仓库中有一些文档，你的代理就可以使用它们。试试：

"在我接触认证模块之前，这里适用哪些 ADR 和规则？"

代理在编辑任何一行代码之前，会加载与该区域相关的决策和规则。

"添加一个新的 API 处理器，并遵循这个仓库的约定。"

代理会显示匹配的规则（例如“处理器位于 src/api/handlers/”），并将代码放置在你的架构指定的位置。

"我们的错误处理规则是什么？"

代理直接从 .archcore/ 读取 error-wrapping.rule.md，而不是根据代码库中的几个示例进行猜测。

首先尝试这些

这些提示捕获_新的_上下文——决策、规则、计划、事件。每个都会创建一个结构化的文档，代理（或任何团队成员）以后可以重用。

新仓库？archcore init 创建 .archcore/。MCP 服务器也可以在空仓库中工作，并公开一个 init_project 工具，因此代理可以为你引导。

"我们决定使用 PostgreSQL 而不是 MongoDB 作为我们的主数据库。记录这个决策。"

创建 infrastructure/use-postgres.adr.md，包含上下文、决策、考虑的替代方案和后果。

"我们有一个团队约定：始终使用 fmt.Errorf 和 %w 包装错误并附加上下文。将此作为一条规则。"

创建 backend/error-wrapping.rule.md，包含命令式指导、理由以及好/坏代码示例。

"上周我们发生了一起连接池耗尽事件，因为空闲连接没有被回收。记录此事，以免重蹈覆辙。"

创建 incidents/connection-pool-exhaustion.cpat.md，包含根本原因分析和预防步骤。

"我需要一个用户通知功能的 PRD——推送、电子邮件摘要和应用内提醒。"

创建 notifications/user-notifications.prd.md，包含目标、用户故事、需求和成功指标。

"为通知 PRD 创建一个实施计划，并将它们链接起来。"

创建 notifications/notifications-implementation.plan.md，然后通过 implements 关系将其链接到 PRD。

如果其中任何一个引起共鸣，Archcore 的其余部分也大同小异——只是结构化了。

安装后有什么变化

没有 Archcore，代理会：

忽略你的架构
打破你的约定
重复已经存在的逻辑
重新争论你的团队已经做出的决策
需要在每次聊天中重复相同的约定
会话一结束就丢失项目真相

有了 Archcore，同样的要求产生的代码会：

落在你的架构指定的位置
尊重已在 Git 中的 ADR、规范和规则
遵循在会话开始时自动加载的团队约定
将新的决策反映为未来的护栏，而不是 markdown 墓地

AI 应该遵循你的系统，而不是猜测它。

何时使用 Archcore

你的代理编写代码，但不是以这个仓库期望的方式
你的 CLAUDE.md / .cursorrules / AGENTS.md 不断增长和偏离
你使用 2 个以上的代理或 2 个以上的宿主工具（Claude Code + Cursor + Copilot）
你希望决策、规则和规范在 Git 中——而不是在聊天记录中

不适用于——聊天记忆、提示库或一次性规范到代码的生成器。Archcore 是编码代理的仓库真相层，而不是方法论工具包。

为什么不仅仅是指导文件？

CLAUDE.md、AGENTS.md 和仓库指导是有用的起点，但当你的团队需要以下内容时，它们就会失效：

不止一个扁平的记忆文件
结构化的文档类型——ADR、规则、计划、事件
跨多个 AI 工具的可重用上下文
随代码库增长的版本化项目知识
文档之间的关系（一个_实施_PRDs 的计划，一个_扩展_ADR 的 RFC）
事件学习和代理以后可以拾取的重复工作流

指导文件告诉代理_你想要什么_。Archcore 告诉代理_你的系统如何运作_——这样代理就可以遵循你的系统，而不是猜测它。

支持的代理

Archcore CLI 本身就是一个本地 stdio MCP 服务器——这是下表中每个兼容 MCP 的代理的共享集成表面。钩子在代理支持的地方添加主动的会话开始上下文。

代理	钩子	MCP
Claude Code	是	是
Cursor	是	是
Gemini CLI	是	是
GitHub Copilot	是	是
OpenCode	—	是
Codex CLI	—	是
Roo Code	—	是
Cline	—	手动

工作原理

初始化你的仓库 archcore init 创建 .archcore/ 并为支持的代理安装集成。
捕获持久上下文 将架构决策、规则、计划、产品文档和事件学习存储为结构化的 Markdown 文件。
让代理重用它们 钩子和 MCP 让你的编码代理读取现有上下文，并在实际工作中创建或更新文档。
将其保存在 Git 中 像代码一样审查上下文更改，随时间演变它们，并保持它们在工具间的可移植性。

心智模型

Archcore CLI 是上下文编译器——它将分散的文档转化为结构化的、机器可读的上下文。MCP 和钩子是运行时——代理在实际工作中消费该上下文所使用的表面。用于 Claude Code 和 Cursor 的 Archcore 插件是建立在此之上的更高级运行时。

implicit repo knowledge  →  structured context  →  AI-readable system

`.archcore/` 中有什么

.archcore/
├── settings.json
├── .sync-state.json
├── auth/
│   ├── jwt-strategy.adr.md
│   └── auth-redesign.prd.md
├── backend/
│   └── error-wrapping.rule.md
├── incidents/
│   └── connection-pool-exhaustion.cpat.md
└── notifications/
    └── notifications-implementation.plan.md

结构是自由形式的——按领域、功能、团队或任何适合你仓库的方式组织文档。类别是虚拟的，根据文件名中的文档类型推断（slug.type.md）。

使用 .archcore/ 存储：

架构决策
编码规则和约定
实施计划
产品需求
事件和事后分析
可重用的工作流知识

请参阅 Archcore CLI 仓库本身以获取工作示例：此仓库中的 .archcore/

开箱即用的内容

18 种文档类型，涵盖愿景、知识和经验
4 种关系类型——related、implements、extends、depends_on
10 个 MCP 工具——list_documents、get_document、create_document、update_document、remove_document、search_documents、init_project，外加关系管理（add_relation、remove_relation、list_relations）
5 个多文档提示——跟踪级联，可作为来自兼容 MCP 代理的斜杠命令调用
钩子集成，适用于 4 个代理（Claude Code、Cursor、Gemini CLI、GitHub Copilot）和 MCP 集成，适用于 8 个

文档类型

Archcore 将上下文组织成 3 个知识层：愿景、知识和经验。

愿景

类型	全称	描述
`prd`	产品需求文档	目标、用户故事、验收标准和成功指标
`idea`	想法	轻量级捕获产品技术想法以供未来探索
`plan`	计划	分阶段任务列表，包含验收标准和依赖关系

Archcore 还为需要结构化发现或正式分解的团队支持两个额外的需求轨道：

来源轨道（MRD → BRD → URD）——捕获需求_来自_哪里：

类型	全称	描述
`mrd`	市场需求文档	市场格局、TAM/SAM/SOM、竞争分析和市场需求
`brd`	业务需求文档	业务目标、利益相关者、投资回报率和业务规则
`urd`	用户需求文档	用户画像、旅程、可用性需求和验收标准

ISO/IEC/IEEE 29148:2018 轨道（BRS → StRS → SyRS → SRS）——捕获需求_如何_分解：

类型	全称	描述
`brs`	业务需求规范	使命、目标、目的和业务运营概念
`strs`	利益相关者需求规范	利益相关者需求、运营概念和用户需求
`syrs`	系统需求规范	系统功能、接口、性能和设计约束
`srs`	软件需求规范	软件功能、外部接口和详细行为规范

对于大多数项目，使用 PRD。当你需要结构化的需求发现时，添加来源轨道。当你需要为受监管或复杂的多团队系统提供正式的可追溯性时，添加 ISO 29148。可以自由混合——某些功能可以使用 PRD，而其他功能使用完整的级联。

知识

类型	全称	描述
`adr`	架构决策记录	捕获最终的技术决策，包含上下文、替代方案和后果
`rfc`	征求意见稿	提出一个重大变更，供团队审查和反馈
`rule`	规则	带有命令式指导和示例的编码或流程标准
`guide`	指南	完成特定任务的分步说明
`doc`	文档	参考文档、注册表和描述性材料
`spec`	规范	系统、组件、接口或协议的规范性合同

经验

类型	全称	描述
`task-type`	任务类型	用于重复性任务的可复用检查清单与工作流
`cpat`	代码变更模式	对缺陷或事故进行根因分析，并附上预防步骤

每个文档都是一个带有 YAML 前置元数据的 Markdown 文件：

---
title: "Use PostgreSQL for Primary Storage"
status: draft
tags: [database, infrastructure]
---

## Context

...

有效状态：draft、accepted 和 rejected。标签是可选的，形式自由——用它们来标记跨领域主题（security、golang、frontend）。

文档关系

文档可以通过有向关系链接到其他文档：

related — 一般关联
implements — 源文档实现了目标文档所指定的内容
extends — 源文档在目标文档的基础上进行扩展
depends_on — 源文档需要目标文档才能继续

关系存储在 .sync-state.json 中，并由 AI 代理通过 MCP 工具自动管理。

AI 代理集成

Archcore 通过三种方式与 AI 编码代理集成：

钩子在会话开始时注入上下文，因此代理从第一条消息起就能感知到你的 .archcore/ 文档。
MCP 工具 赋予代理实时列出、搜索、读取、创建、更新和链接文档的能力。MCP 服务器也可以在空仓库中工作，并暴露一个 init_project 工具，因此代理可以自行引导 .archcore/。
MCP 提示 是现成的多文档工作流，你可以通过斜杠命令从代理中触发。

提示

提示在一次调用中编排完整的文档级联——代理会为你创建并链接轨道中的每个文档。大多数兼容 MCP 的客户端会将其显示为斜杠命令（例如 /architecture_track）；具体前缀取决于客户端。

提示	功能
`product_track`	想法 → PRD → 计划（轻量级功能流程）
`architecture_track`	ADR → 规格说明 → 计划（技术设计与实现）
`standard_track`	ADR → 规则 → 指南（将团队标准规范化）
`sources_track`	MRD → BRD → URD（市场/业务/用户发现）
`iso_track`	BRS → StRS → SyRS → SRS（正式的 ISO 29148 级联）

示例。 在你的代理中，运行 /product_track feature="user notifications"。代理会起草一个想法，派生出一个 PRD，构建一个实施计划，并自动将它们链接起来。

本地 MCP 服务器

Archcore 不需要托管服务。CLI 运行一个本地 stdio MCP 服务器：

archcore mcp

默认情况下，archcore mcp 从当前目录提供文档服务。传递 --project /path/to/repo（或设置 ARCHCORE_PROJECT_ROOT）将其指向其他位置——当服务器是从非工作区的目录启动时（例如，由编辑器集成启动），这很有用。

将其接入 Claude Code：

claude mcp add --transport stdio archcore -- archcore mcp

或为受支持的代理自动安装：

archcore mcp install --agent cursor

安装集成

# Auto-detect agents in your project and install everything
archcore hooks install

# Or target a specific agent
archcore mcp install --agent opencode
archcore hooks install --agent cursor

命令

命令	描述
`archcore init`	交互式初始化 `.archcore/` 目录
`archcore doctor`	检查你的 archcore 设置并修复问题
`archcore status`	检查 .archcore/ 结构和文档健康状况
`archcore config`	查看或修改设置
`archcore hooks install`	为检测到的 AI 代理安装钩子
`archcore update`	将 Archcore 更新到最新版本
`archcore mcp`	运行 MCP stdio 服务器
`archcore mcp install`	为检测到的代理安装 MCP 配置

更新

archcore update

该命令会检查 GitHub Releases 中是否有更新的版本，下载它，验证 SHA-256 校验和，并原子性地替换当前二进制文件。

安装方法

macOS / Linux

curl -fsSL https://archcore.ai/install.sh | bash

Windows

irm https://archcore.ai/install.ps1 | iex

将 archcore.exe 安装到 %LOCALAPPDATA%\Programs\archcore 下，并将其添加到你的用户 PATH 中。安装后打开一个新的 PowerShell 窗口，以便 PATH 的更改生效。

Windows (WSL)

安装 WSL，然后在其中运行：

curl -fsSL https://archcore.ai/install.sh | bash

Go install

go install github.com/archcore-ai/cli@latest

从源码安装

git clone https://github.com/archcore-ai/cli.git
cd cli
go build -o archcore .

支持的平台： macOS、Linux、Windows — amd64 和 arm64。

关于环境变量（ARCHCORE_VERSION、ARCHCORE_INSTALL_DIR、GITHUB_TOKEN）和 PATH 故障排除，请参阅 docs.archcore.ai 上的完整安装指南。

配置

设置存储在 .archcore/settings.json 中，并在 archcore init 期间创建。

字段	描述	值
`sync`	同步模式。云端和本地部署即将推出。	`none`（仅本地）、`cloud`、`on-prem`
`language`	文档语言。帮助代理以正确的语言生成文档。	字符串，默认为 `en`

archcore config                              # show all settings
archcore config get <key>                    # get a specific value
archcore config set <key> <value>            # set a value

开发

先决条件

Go 1.24+

构建与测试

# Build
go build -o archcore .

# Run all tests
go test ./...

# Run a specific package
go test ./cmd/

# Run a single test
go test ./cmd/ -run TestConfigCmd

项目结构

├── cmd/              # Cobra commands (init, doctor, config, status, hooks, mcp, ...)
├── internal/
│   ├── agents/       # Supported AI agents with hooks/MCP capabilities
│   ├── api/          # HTTP client for archcore server
│   ├── config/       # Settings management and directory init
│   ├── display/      # Terminal output formatting (lipgloss)
│   ├── update/       # Self-update logic (version check, download, verify, replace)
│   ├── mcp/          # MCP stdio server, tools, and prompts
│   └── sync/         # Sync logic
├── templates/        # Document type templates
├── install.sh        # Install script
└── .goreleaser.yaml  # Release configuration

Archcore 是否类似于 BMAD / Spec Kit / Memory Bank？

不——它们解决的是不同的问题。快速对照：

工具	类别	是什么	Archcore 的不同之处
BMAD	方法论	代理式 SDLC 方法论——12+ 角色，34+ 工作流	Archcore 存储_工件_；BMAD 规定_流程_
Spec Kit	方法论	规格说明驱动的工作流：`specify → plan → tasks → implement`，一次性	Spec Kit 是一次性交接；Archcore 维护一个随代码库演变的动态图谱
Agent OS	方法论	代码库标准提取 + 规格说明驱动开发	定位最接近。Archcore 增加了类型化文档、经过验证的关系以及可选的 ISO 级联
claude-mem / Mem0	记忆	自动捕获会话记忆，跨代理回忆	记忆工具记住_你做了什么_；Archcore 存储_系统是如何构建的以及做出了什么决策_
Cline Memory Bank	文档	固定模式的 markdown 文件（`projectbrief`、`activeContext`、`systemPatterns`…）	精神相同，仪式感更低。Archcore 增加了类型化关系、MCP 验证和多步骤级联
CLAUDE.md / .cursorrules	指令	代理在会话开始时读取的单个扁平文件	Archcore 用类型化、相关联、可查询的文档取代了不断增长的指令文件

选择一个方法论工具来获得有主见的开发流程。选择一个记忆工具来保持会话连续性。当你希望获得类型化、可查询的_项目真相_——即_这个_仓库的决策、规则和架构——并且你的编码代理在每次请求时都能遵循时，选择 Archcore。

链接与许可证

文档： docs.archcore.ai
网站： archcore.ai
插件（Claude Code、Cursor）： github.com/archcore-ai/archcore-plugin
问题： github.com/archcore-ai/cli/issues
许可证： Apache 2.0