跳到正文
DEV Community· Naimish·· 2 小時前AI 評分45

GitOS:GitHub 圖譜驅動的生態防禦與情報層

GitOS: Graph-Powered Ecosystem Defense & Intelligence Layer for GitHub

AI 導讀

GitOS 以 FalkorDB 為圖譜引擎分析 GitHub PR,先透過確定性查詢評估呼叫影響範圍、未測試變更及疑似 AI 幻覺死碼。系統從 GitHub recursive Git Trees API 在記憶體解析程式碼,圖譜遍歷低於 10 毫秒,毋須複製儲存庫。之後才啟動 5-agent swarm,並以 Groq Llama 3.3 70B 處理,提示詞少於 800 tokens。

正文

Why We Built GitOS: The Graph-Powered Defense Layer Open Source Desperately Needs

By Naimish Singh & Team BitBuddies (Graph Hacks: Context for AI Agents 2026)


The Uncomfortable Reality of Modern GitHub

If you maintain an open-source library with more than a few hundred stars, you already know what happened over the last twelve months:

Your notifications exploded. But they didn’t explode with deep bug reports or thoughtful refactors. They exploded with AI-generated pull requests.

Someone pastes an issue into a frontier LLM, prompts it to "fix this," and hits Submit PR without reading a single line of the diff. On the surface, the PR looks articulate. The markdown description is immaculate, formatted with bullet points and emojis. But when you inspect the code:

  • Variable names were renamed cosmetically across 18 files.
  • A modified helper function in routing.py broke 14 callers across unrelated modules because the author never ran the test suite.
  • A newly hallucinated utility function was injected into the codebase that is never called by anything (in_degree == 0).
  • Worse: existing automated "AI review bots" chime in by generating 50-comment threads, burning tens of thousands of LLM tokens on speculative guesses while spamming everyone on the thread.

We watched maintainers of projects like FastAPI, Flask, and React spend their weekends acting as human spam filters.

We asked ourselves a simple engineering question:

Why are we using stochastic, token-hungry LLMs to guess at structural code relationships when a graph database can determine them with 100% mathematical certainty in under 10 milliseconds?

That question gave birth to GitOS.


The Paradigm Shift: Deterministic Graph-First, LLM-Last

Before building GitOS, we laid down three non-negotiable architectural axioms:

  1. Zero LLM Tokens for Structural Math: An LLM should never be asked "what functions call add_api_route?" That is a graph traversal problem.
  2. Zero Disk Clone: Open-source maintainers don’t want a bot cloning 5GB repositories to a third-party server. Everything must parse directly from GitHub’s recursive Git Trees API in-memory.
  3. Zero Unconsented Bot Spam: No automated comments, labels, or PR closures unless a human maintainer clicks a button with an explicit confirmation dialog under their own authenticated OAuth session.

To make this possible, we needed a graph engine with sub-millisecond traversal latencies on in-memory topologies. That engine was FalkorDB.


How GitOS Works Under the Hood

When a maintainer or contributor pastes a GitHub PR URL into GitOS, the system doesn’t prompt an LLM. Instead, it triggers a 4-layer deterministic pipeline:

[GitHub PR URL] 
      │
      ▼ (In-Memory Tree Fetch - 0 Disk Clones)
[Universal AST Parser (Python & Tree-Sitter)]
      │
      ▼ (Subgraphs Persisted by commit_sha)
[(FalkorDB Graph Engine)]
      │
      ├──> Filter 1: Untested Call-Graph Impact ([:TESTED_BY] Traversal)
      ├──> Filter 2: AST Delta vs. Raw Text Diff Ratio (Cosmetic Churn)
      ├──> Filter 3: Dead Code Injection (In-Degree == 0)
      └──> Filter 4: Maintainer Architectural Boundaries (Forbidden Edges)
      │
      ▼ (Sub-10ms Subgraph Results)
[3D Interactive Force Graph & Multi-Agent Swarm]

1. In-Memory AST Projection

We extract classes, functions, calls, and imports into formal graph primitives:

  • Nodes: (:Function), (:Class), (:Module), (:Test)
  • Relationships: [:CALLS], [:IMPORTS], [:TESTED_BY], [:DEFINES]

2. The FalkorDB Cypher Queries Doing the Heavy Lifting

Instead of asking an AI to "spot bugs", GitOS executes deterministic Cypher queries directly against FalkorDB.

A. Multi-Hop Blast Radius:
When a PR alters a signature, how far does the blast wave travel?

MATCH (target:Function) WHERE target.id IN $modified_targets
MATCH path = (caller:Function)-[:CALLS*1..$hops]->(target)
RETURN caller.id, target.id, length(path) AS hop_distance
ORDER BY hop_distance ASC LIMIT 100;

In FalkorDB, this recursive traversal returns in 3 to 7 milliseconds. It instantly reveals that changing APIRouter.add_api_route in Python cascades into an unverified TypeScript gateway controller two hops away.

B. Catching Hallucinated Dead Code:
LLMs frequently hallucinate dead helper functions. We query incoming call in-degrees:

MATCH (fn:Function {commit_sha: $commit_sha})
WHERE NOT fn.name STARTS WITH 'test_' AND NOT fn.name STARTS WITH '__'
OPTIONAL MATCH (caller:Function)-[:CALLS]->(fn)
WITH fn, count(caller) AS in_degree
WHERE in_degree = 0
RETURN fn.id, fn.file_path, fn.line_start;

If in_degree == 0, GitOS immediately flags the injected symbol as potential AI hallucination. Zero tokens spent.

C. Cosmetic Churn Ratio:
We compare AST node mutations against raw line diffs. If a PR touches 1,480 lines of text across 18 files but only mutates 3 AST nodes (a ratio of 0.002), GitOS flags it as cosmetic AI slop before maintainers waste cognitive energy reviewing it.


The 5-Agent Swarm: True Agentic Context

Only after FalkorDB computes the deterministic metrics does our 5-agent swarm take the stage:

  1. TriageAgent: Synthesizes the blast radius score and maintainer executive brief.
  2. GraphAgent: Traverses isolated repository graphs (gitos_{owner}_{repo}) to identify cross-module dependency regressions.
  3. SecurityAgent: Scans for AST security sinks (eval, command injection) and package slopsquatting.
  4. OnboardingAgent & Pathfinder: Translates open GitHub issues into precise AST symbol edit scopes for contributors.
  5. ReleaseAgent: Analyzes AST changes to automatically determine semantic SemVer impacts (PATCH, MINOR, or MAJOR) and draft structured release notes.

Because FalkorDB compresses the entire problem into a tiny, high-density subgraph, when we do call an LLM (Groq Llama 3.3 70B), the prompt is under 800 tokens. No prompt bloat, no token bankruptcy, and no hallucinations.


What Building on FalkorDB Taught Us

When we started the hackathon, we experimented with relational joins and document stores. They fell apart the moment we hit multi-hop traversals across enterprise codebases like Flask and FastAPI.

With FalkorDB:

  • Speed is real: Running recursive graph traversals on Redis-backed memory primitives gave our agents sub-second responsiveness on live UI keystrokes.
  • Multi-Graph Isolation is a superpower: FalkorDB lets you create isolated graphs (gitos_fastapi_fastapi, gitos_pallets_flask) on the fly inside a single instance without deploying separate database clusters. This made multi-tenant per-repo memory effortless.
  • Traceability replaces guesswork: In an era where AI agents are accused of being black boxes, a Cypher query path (A)-[:CALLS]->(B)-[:CALLS]->(C) is deterministic proof you can show to any senior engineer.

How to Run GitOS in 60 Seconds

We made sure anyone—especially hackathon judges—can run GitOS locally with a single command:

git clone https://github.com/ace-ify/GitOS.git
cd GitOS
cp .env.example .env
# Add your GitHub token in .env
docker-compose up --build
  • Open http://localhost:3000 to interact with the 3D topology graph.
  • API Swagger docs live at http://localhost:8000/docs.
  • Test suite: 40/40 unit & integration tests passing out of the box.

Final Thoughts

AI shouldn’t make open source harder to maintain. It should make ecosystems cleaner, safer, and more accessible.

By pairing modern AI agents with the structural rigor of FalkorDB graph databases, we don't just guess what code does—we trace it, defend it, and understand it.

Check out the open-source code on GitHub: https://github.com/ace-ify/GitOS

來源:DEV Community · dev.to