archgraph-argo-beta
使用一条命令部署 ArchGraph ARGO 工具链、技能和规则（架构、脚本、argo-init 技能、全局规则）。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:derekhu0002/archgraph#cfbe65ba589d8752b203cca6996d73c96ec5be30Archgraph Argo Beta 以 archgraph-argo-beta 发布，当前版本为 0.27.0-beta.16。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A knowledge-graph framework with an ontology you define — wired into your coding agent through one MCP interface.
For teams running coding agents on a real codebase, ArchGraph gives the agent durable, tiered long-term memory on an intent graph — a versioned architecture graph that records why the system is built the way it is, not just how. You and the agent read and write it through a single MCP server (MCP = Model Context Protocol, the open standard that lets an AI tool call external servers as tools). The graph's shape is set by an ontology — its vocabulary of element and relationship types — and that ontology is yours to define. The built-in default is ArchiMate 3.2 + ARGO extensions, where ArchiMate is a standard enterprise-architecture modeling language and ARGO is the toolchain and agent-workflow layer behind the argo-deploy and argo init commands. A repository can plug in its own ontology — and this one does. One install, one interface to learn.
Ready to try it? Jump to Build your own graph.
Install · Build your own graph · Why ArchGraph · Capabilities · Docs · Community
ArchGraph core model — one graph for the agent's memory and the product's design
If you run coding agents on a real codebase, every session starts cold and the "why" behind the system lives nowhere. ArchGraph makes one architecture graph the single source of truth — the agent's memory and the product's design in one model. It is one MCP interface to install and learn: the agent restores context at session start, recalls detail on demand, and reuses what it already knows instead of duplicating it (a duplicate needs an explicit override).
→ Full onboarding: docs/getting-started.html
Every team running coding agents hits the same wall: the code is in the repo, but the reasoning behind it lives nowhere. Four common fixes exist, and each works until it doesn't.
The real differentiator is not "custom vs. locked". Protégé/OWL, Neo4j, TerminusDB, and Archi/EA all let you extend a model or bring your own vocabulary. It is that ArchGraph makes the ontology a first-class, validated, runtime-resolved schema bundle — and puts it behind one MCP interface the agent reads and writes, with typed dedup and commit traceability built in.
The honest, cost-included comparison lives in one canonical place — docs/capabilities.html#compare.
A knowledge-graph framework that speaks only one language is not a framework. ArchGraph separates the core from the ontology: a repository drops a schema bundle under .argo/schema/ (element/relationship types, endpoint rules, an actor contract, an optional guide), and validation, MCP guidance, and the .qea projection follow it. A bundle can extends: "default" — inheriting the built-in ArchiMate 3.2 + ARGO extensions — and add its own types; no framework change required.
This repository is the proof: its own bundle uses extends: "default" and layers a UML 2 state-machine profile on top, resolved at runtime from .argo/schema/ rather than hardcoded in the framework.
→ Worked example — define an ontology, then build the graph step by step: docs/case-team-graph.html · runnable bundle: custom-schema/
Prerequisite: Node.js ≥ 18 (the ARGO toolchain and the MCP server both run on Node).
npm install -g archgraph-argo
argo-deploy
argo-deploy registers the argo MCP server and installs the skills and rules into GitHub Copilot, Cursor, OpenCode, DeepSeek Harness, OpenClaw, and Codex (agents are installed where the host supports them). It then prompts for the few settings in ~/.argo/.env. After deploying, restart your editor / host so it reloads the MCP server. Semantic queries additionally need Neo4j and an embedding endpoint — see Build your own graph.
There is one canonical start: Build your own graph — install once, then pick Route A (the default ontology) or Route B (your own). That section carries every step and MCP call; this one deliberately keeps no second copy, so there is only one path to follow.
The one prerequisite that is not out of the box: semantic (Graph RAG) retrieval needs a Neo4j instance and an OpenAI-compatible embedding endpoint. Context reads, writes, and Enterprise Architect interop work without them; the Cypher (Neo4j's graph query language) structural projection and all semantic retrieval need Neo4j.
Pick one of two routes. Everything happens through your coding agent and the ARGO MCP server; the only commands you run yourself are the install. Once initialized, the intent graph is the single source of truth.
No schema work: use the built-in ArchiMate 3.2 + ARGO extensions.
Install (once). Requires Node.js ≥ 18.
npm install -g archgraph-argo
argo-deploy
Then restart your editor / host so it reloads the MCP server.
Initialize. Ask your coding agent to run argo init (the initializeWorkspace MCP call). It creates and validates the starter design/KG/SystemArchitecture.json, which already contains the project's root view named SystemArchitecture.
Add elements and relationships. Ask your coding agent to call applySystemArchitectureMutation and attach every new element and relationship to the project's existing root view — tell it to resolve that view's real view_id first (queryNeo4jGraph / getArchitectureViewContext). Do not pre-create a view: a new view called SystemArchitecture would collide with the one argo init made, and any view_ids pointing at a different id would then fail.
Verify. Ask your coding agent to call validateSystemArchitecture, then queryNeo4jGraph with {"schema": true} to confirm the element and relationship types in effect.
Install (once). As in Route A.
Author your schema. Put your modeling language under .argo/schema/. A standalone bundle — a full SystemArchitecture.schema.json, editing its two $defs enum arrays, archimateElementType and archimateRelationshipType — must also declare actorElementType in schema-bundle.config.json, set to one of your element types (or to null if your schema genuinely has no actor concept), or loading fails closed (bundleValidation.status: "failed") and validation/writes are blocked. A bundle that only extends: "default" needs just the config. schema-bundle.rules.json stays optional (without it, endpoint checks are permissive).
Author the graph yourself. With a custom schema, argo init does not create the graph — the packaged default would not match your vocabulary — and it fails closed with NO_DEFAULT_GRAPH. Before any MCP write, create design/KG/SystemArchitecture.json by hand, using your own element and relationship types and your own root view. Then ask your coding agent to run argo init to validate it.
Add into YOUR root view. Ask your coding agent to call applySystemArchitectureMutation, attaching each element and relationship to the root view you authored (not the default one).
Verify. Ask your coding agent to call validateSystemArchitecture, then queryNeo4jGraph with {"schema": true}.
The fully-illustrated, step-by-step walkthrough is docs/case-team-graph.html (Chinese), and the runnable example bundle is custom-schema/. The result looks like this:
Each line links to a short page — this is the map, not the manual.
.qea; human EA edits return as a semantic diff.Initialize once (argo init), then open your project and let your coding agent work. It will:
The intent architecture graph is the single source of truth.
| Harness | MCP | Skills | Rules | Agents |
|---|---|---|---|---|
| GitHub Copilot | ✓ | ✓ | ✓ | ✓ |
| Cursor | ✓ | ✓ | ✓ | ✓ |
| OpenCode | ✓ | ✓ | ✓ | ✓ |
| DeepSeek Harness | ✓ | ✓ | ✓ | ✓ |
| OpenClaw | ✓ | ✓ | ✓ | — |
| Codex | ✓ | ✓ | ✓ | — |
A single argo-deploy registers the argo MCP server and installs all artifacts into each harness automatically.
Cross-project access runs over two separate channels — they must not be conflated:
workspaceRoot reads a peer project's graph on the same machine. Writes are read-only by design: a foreign write is refused with WORKSPACE_WRITE_DENIED.projectId is routed through the federation center, authorized there (denied by default), and returned by reference.Whether the local channel works depends on the harness, because a harness may bridge the MCP server and pin the workspace per call:
| Harness | Local read (workspaceRoot) | Local write | Federated read (projectId) |
|---|---|---|---|
| OpenCode | ✓ | blocked (WORKSPACE_WRITE_DENIED) | ✓ |
| Codex | ✓ | blocked (WORKSPACE_WRITE_DENIED) | ✓ |
| DeepSeek Harness | ✗ | ✗ | ✓ |
| GitHub Copilot | ✓ | blocked (WORKSPACE_WRITE_DENIED) | ✓ |
| Cursor | 待测 | 待测 | ✓ |
| OpenClaw | 不涉及 | 不涉及 | ✓ |
DeepSeek Harness cannot do local cross-project access: its bridge pins the session workspace, so the request never reaches the server as written and only the federated channel works.
ArchGraph runs on open co-building: share and reuse architecture subgraphs across projects. Sharing is federated — each project keeps its graph sovereign, and members register, discover, authorize, and read opened content by reference (denied by default; nothing copied or merged). The center is a registry–broker that holds federation metadata, never content.