SynapseAI

AI-Native Multi-Agent Development Platform with 4-Layer Memory Pipeline

Where AI agents learn, collaborate, and deliver — with persistent memory that grows smarter with every project.

English · 中文

Why SynapseAI?

Current AI coding assistants share a fatal flaw: they forget everything. Every session starts from zero. Context windows overflow. Multi-file changes break things silently. No quality gates exist between "code generated" and "code shipped."

SynapseAI takes a fundamentally different approach:

• Memory-first architecture — a 4-layer pipeline that captures, structures, and reuses knowledge across sessions and projects
• Multi-agent collaboration — specialized agents work in parallel instead of one overloaded chatbot
• Forced quality workflow — autonomous code review, strict requirement confirmation, and enforced development phases
• Smart context injection — a Dispatcher Agent uses LLM to select only relevant context, preventing overflow

How It Solves Real Pain Points

| The Problem | What Others Do | What SynapseAI Does | |---|---|---| | No memory between sessions | Start from zero every time. Re-learn the codebase. Repeat mistakes. | 4-layer memory pipeline — L1 traces → L2 task records → L3 scored experiences → L4 global knowledge. Every session builds on prior work. | | Single agent, single context | One agent plans, codes, tests, documents. Context fills up → quality drops. | Role-specialized agent team — PM plans, Workers code in parallel, Reviewers inspect, Dispatcher selects context. Each agent has a focused, manageable context. | | No code quality gate | Code gets written and shipped. Bugs slip through silently. | Forced code review cycle — Reviewer Agent inspects every task output. If issues found, task resets with feedback injected. Loop continues until code passes or rounds exhausted. | | Context window overflow | Stuff everything into the prompt. When it overflows, things break. | Index-mode injection + LLM Dispatcher — inject compact indexes (~30 tokens/entry), let Dispatcher Agent select only what's relevant, agents query full details on demand. | | Experience lost between projects | Every new project repeats the same learning curve and pitfalls. | Cross-project experience promotion — high-generality experiences auto-promote to L4 global knowledge. New projects bootstrap from proven patterns. | | Requirements get lost | Agent starts coding before fully understanding what's needed. | Enforced 5-phase workflow — PM must complete requirements confirmation, design, and task planning before any code is written. |

4-Layer Memory & Experience Pipeline

This is SynapseAI's core innovation. Knowledge flows unidirectionally through four layers, each adding structure and reusability:

┌─────────────────────────────────────────────────────────────────┐
│                     4-Layer Memory Pipeline                      │
│                                                                   │
│  L1 Raw Traces          L2 Task Records         L3 Experiences  │
│  ┌───────────┐         ┌──────────────┐        ┌─────────────┐  │
│  │ Worker    │  LogAgent│ Structured   │  Exp    │ Scored      │  │
│  │ actions   │ ──────→ │ summary with │ ──────→ │ patterns    │  │
│  │ Reasoning │         │ pitfalls,    │  Agent  │ with repro/ │  │
│  │ PM chats  │         │ solutions,   │         │ general/act │  │
│  │           │         │ files        │         │ scores      │  │
│  └───────────┘         └──────────────┘        └──────┬──────┘  │
│                                                        │          │
│                              User approves (generality │ 75)     │
│                                                        ▼          │
│                                                L4 Global Knowledge│
│                                                ┌──────────────┐   │
│                                                │ Cross-project│   │
│                                                │ reusable     │   │
│                                                │ patterns     │   │
│                                                └──────────────┘   │
└─────────────────────────────────────────────────────────────────┘

| Layer | What It Stores | How It's Created | Who Uses It | |---|---|---|---| | L1 Traces | Raw tool calls, reasoning steps, PM conversations | Append-only, captured in real-time during agent execution | LogAgent → feeds L2 | | L2 Task Records | Structured summaries: goal, approach, pitfalls, solutions, files modified | LogAgent summarizes L1 traces when task reaches terminal state | ExperienceAgent → feeds L3 | | L3 Experiences | Scored reusable patterns (reproducibility, generality, actionability) | ExperienceAgent extracts from L2 records; awaits user review | DispatcherAgent → context injection | | L4 Global | Cross-project verified knowledge | Auto-promoted when user approves L3 experience with generality ≥ 75 | All new projects |

Key design decisions:

• Pipeline is event-driven, not periodic — triggered on task completion
• L3 experiences require explicit user approval before activation
• L4 promotion is automatic based on generality score threshold
• All layers are queryable by agents via tool calls during execution

Enforced 5-Phase Development Workflow

SynapseAI enforces a strict development workflow. You can't skip phases — the PM Agent gates each transition:

Phase 1              Phase 2            Phase 3            Phase 4               Phase 5
Requirements    →    Tech Design    →   Task Planning  →  Parallel Execution →  Delivery
   ↓                   ↓                  ↓                  ↓                    ↓
User confirms       PM proposes        PM creates tasks    Workers execute      Docs & tests
requirements         design, user       with dependencies   in parallel.         written by PM
via conversation     confirms gates     & completion        Reviewer inspects
                                        criteria            each task output

Phase 1 — Requirements — PM Agent conducts a structured conversation to elicit requirements. Produces a PRD. User must explicitly confirm before proceeding.

Phase 2 — Technical Design — PM designs architecture, records decisions, produces design doc. User must confirm the design before any tasks are created.

Phase 3 — Task Planning — PM breaks design into dependency-ordered tasks with concrete completion criteria. User must confirm the plan before scheduling starts.

Phase 4 — Parallel Execution — Scheduler dispatches tasks to Worker Agents:

1. Workers execute tasks in parallel (up to configurable concurrency)
2. After each Worker completes, a Reviewer Agent inspects the code diff
3. If issues found → task resets, new Worker picks it up with review feedback injected
4. Loop until code passes or max review rounds reached
5. All tasks done → system auto-creates integration test task

Phase 5 — Delivery — PM writes deployment docs, test reports, final README.

Scenario-Aware PM Workflows

Traditional AI coding tools treat every request the same way: receive instruction → start coding. SynapseAI's PM Agent detects the scenario first, then follows a purpose-built workflow for that specific situation. This prevents the most common failures.

Scenario A: New Project (from scratch)

The standard 5-phase flow described above. Works well — no changes needed.

Scenario B: Project Analysis

Two-phase deep analysis — not just reading README.

Phase 1: Structural Scan
  PM scans project structure (package.json, directory tree, entry points, config)
  → Produces a "Project Map" identifying functional modules and dependencies
  → User confirms the map is accurate

Phase 2: Module Deep Dive
  PM creates parallel research tasks — one per functional module
  → Each Worker gets: module boundary, project map context, key questions to answer
  → Workers analyze modules in parallel, reading source code and tracing data flows
  → PM synthesizes all results into a comprehensive PROJECT_ANALYSIS.md

Scenario C: Add Feature

Simplified version of Scenario A. PM first scans the relevant existing code to understand conventions, then plans tasks that integrate with the existing architecture. No need to re-design the whole system.

Scenario D: Delete / Modify Feature

Two-phase process with mandatory user confirmation before any destructive action.

Phase D1: Impact Analysis + Confirmation (NO code changes yet)
  PM analyzes what will be affected:
  → Files to modify/delete, dependent code that will break,
    API changes, data model changes, affected tests
  → Presents structured impact report to user
  → ⚠️ WILL NOT create any task until user explicitly confirms

Phase D2: Execution + Residual Check
  After confirmation: PM creates scoped tasks
  After execution: PM runs residual check
  → grep for remaining references, dangling imports, dead code, orphaned config
  → Reports findings, asks whether cleanup is needed

Scenario E: Bug Fix

Three-phase process — clarify first, investigate second, fix third.

Phase E1: Bug Clarification (NO investigation yet)
  PM asks structured questions:
  → Expected behavior? Actual behavior?
  → Reproducible every time or conditional?
  → Error messages / logs / screenshots?
  → Recent changes that might be related?
  PM restates the bug in precise format → user confirms accuracy

Phase E2: Investigation + Diagnosis
  PM investigates root cause using bash (read files, trace code paths, check git history)
  → Presents structured diagnosis:
    Root cause, location, why it happens, suggested fix, risk assessment
  → User confirms the diagnosis is correct

Phase E3: Fix
  Only after confirmed diagnosis → PM creates targeted bugfix tasks
  After fix → verification that original bug is resolved + no regression

Summary: Scenario Comparison

| Scenario | Traditional Agent | SynapseAI PM | |---|---|---| | Analyze project | Read README + a few files → shallow summary | Structural scan → parallel module analysis → comprehensive report | | Delete/modify | Immediately start deleting → hope for the best | Impact analysis → user confirmation → execution → residual check | | Bug fix | "Doesn't work" → immediately debug wrong problem | Structured clarification → confirmed diagnosis → targeted fix |

Intelligent Context Injection

The traditional approach is to stuff everything into the prompt. SynapseAI does the opposite:

Index-Mode Injection

Each Worker receives a compact index (title + summary, ~30 tokens per entry) instead of full documents:

## Relevant Experience Index
- E03 JWT auth race condition [score: 87] — token refresh race, fix: dual-token approach
- E07 SQLite migration pitfalls [score: 72] — lock contention, fix: WAL mode + transaction batching

## Project Memory Index
- #12 Backend routing architecture — layered routing, Express Router, middleware chain
- #34 Database migration plan — better-sqlite3 migrator, version tracking

DispatcherAgent (LLM-Powered Selection)

Instead of rule-based filtering, a lightweight LLM call selects the most relevant experiences, skills, and MCP tools from the full index:

DispatcherAgent receives: task title + description + full experience/memory/skill/MCP index
DispatcherAgent returns: selected_experience_ids + selected_skill_ids + selected_mcp_ids

On-Demand Query

Workers have tool access to query full details when needed:

• memory_search / memory_get — query project memories
• experience_search / experience_get — query verified experiences
• Skill and MCP tool invocation — extend capabilities dynamically

Result: near-zero context waste. Agents see only what's relevant, query details on demand.

Forced Code Review

Every task output goes through an autonomous review cycle:

Worker completes task
        │
        ▼
Reviewer Agent spawns (separate Worker Thread)
        │
        ├─ Reads git diff for the task branch
        ├─ Examines files in full context via read_file
        ├─ Runs tests via bash
        ├─ Checks project conventions via memory_search
        │
        ▼
Outputs structured verdict:
  ├── passed → merge to main, mark task complete
  └── issues found → task resets with feedback, new Worker retries
                        (up to max_review_rounds, then force-fail)

Configurable strictness levels:

• Off — skip review entirely
• Loose — only flag crashes, data loss, security holes
• Medium — + business logic errors, code structure, missing error handling
• Strict — + security vulns, race conditions, performance, naming, duplication

Multi-Agent Parallel Architecture

User ←→ PM Agent (SSE streaming conversation + agentic tool loop)
                    │
                    ▼
            MemoryButler (long-running coordinator)
             ├─ Scheduler (task dispatch + review loop + concurrency)
             ├─ ContextInjector (index injection + DispatcherAgent)
             ├─ LogAgent (L1 → L2 task record summarization)
             ├─ ExperienceAgent (L2 → L3 experience extraction with scoring)
             ├─ EventQueue + WebSocket (real-time UI updates)
             └─ WriteQueue (serial SQLite write safety)
                    │
           ┌────────┼────────┐
           ▼        ▼        ▼
        Worker   Worker   Reviewer   (Worker Threads, parallel execution)
           │        │        │
           └────────┼────────┘
                    ▼
          Global Memory Store (SQLite + sqlite-vec)

Each agent role is purpose-built:

• PM Agent — converses with user, plans requirements, designs architecture, creates tasks
• Worker Agent — executes development tasks with scoped file access and memory tools
• Reviewer Agent — read-only inspection of Worker output, configurable strictness
• LogAgent — summarizes L1 execution traces into structured L2 task records
• ExperienceAgent — extracts scored, reusable patterns from L2 records
• DispatcherAgent — LLM-powered selection of relevant context for each task

Multi-Model Flexibility

Assign different models to different roles for cost-performance optimization:

| Role | Recommended Tier | Reason | |---|---|---| | PM Agent | Strong reasoning (Opus, GLM-5) | Deep analysis, architecture design | | Worker Agent | Balanced (Sonnet, GLM-4) | High volume coding | | Reviewer Agent | Balanced (Sonnet, GLM-4) | Diff reading, checklist verification | | Experience Agent | Lightweight (Haiku, GLM-4-Flash) | Summarization and extraction | | Dispatcher Agent | Lightweight (Haiku, GLM-4-Flash) | Selection from index | | Embedding | Dedicated embedding model | Cheaper than chat for vectors |

Supports Anthropic and OpenAI-compatible protocols — plug in any provider (Ollama, vLLM, DeepSeek, Groq, local models, etc.).

Code Graph — Persistent Project Knowledge

Every time a Worker Agent picks up a task, it should understand the project structure — not rediscover it from scratch via bash/grep. SynapseAI maintains a persistent code knowledge graph per project, powering precise code understanding for PM, Workers, and the Web UI.

What the Graph Stores

codegraph_files      — Every parsed source file (language, hash, parse status)
codegraph_symbols    — Functions, classes, methods, interfaces, types, enums, imports
codegraph_edges      — imports, calls, extends, implements, contains, uses_type, exports

Each symbol has: qualified name (e.g. UserService.authenticate), kind, line range, modifiers (export/async/static/...), parent symbol, and doc comment. Each edge links a source symbol to a target symbol or external package.

30+ Language Support via AST

SynapseAI uses tree-sitter WASM grammars for accurate AST-based extraction — not fragile regex. 38 pre-compiled grammar files cover 30+ languages:

| Category | Languages | |---|---| | Web & Frontend | TypeScript, TSX, JavaScript, JSX, Vue, HTML, CSS (SCSS/LESS) | | Systems | C, C++, Rust, Go, Zig, Objective-C | | JVM & .NET | Java, Kotlin, Scala, C# | | Scripting | Python, Ruby, PHP, Lua/Luau, Bash/Zsh | | Functional | Haskell, Elixir, Erlang, OCaml, Elm, Gleam, ReScript | | Mobile | Swift, Dart, Kotlin | | Data & Config | JSON, YAML, TOML, SQL | | Specialty | Solidity, Julia, R, TLA+, Swift |

17 specialized AST extractors handle language-specific node types, import syntax, call patterns, and modifier systems. A generic config-driven extractor provides baseline support for remaining languages.

Incremental Graph Updates

The graph stays fresh without full rebuilds:

Worker completes task  →  Reviewer passes  →  Incremental update triggered
                                                    │
                                                    ├─ Re-parse modified files only
                                                    ├─ Find and re-parse direct dependents (files that import modified files)
                                                    └─ Wrapped in SQLite transaction for atomicity

First encounter with an existing project (Scenario B) triggers a full build. After that, only changed files and their dependents are re-parsed.

Graph-Aware Agent Workflows

PM Agent has two dedicated tools:

• build_graph — Build or rebuild the full project graph (used in Scenario B: Project Analysis)
• query_graph — Query the graph with subcommands: structure, dependents, impact, symbol, search

Scenarios C/D/E now start with a mandatory graph query step — PM reviews project architecture and impact scope before any analysis or code changes.

Worker Agent has codegraph_query tool for real-time queries:

• symbol — Find a symbol definition and its location
• callers / callees — Trace call chains
• imports / imported_by — Trace import dependencies

Context Injection — The graph automatically injects relevant code structure into each Worker's context based on the task's writable file scope, providing symbol definitions and dependency relationships without manual exploration.

Web Graph Visualization

The built-in Web panel includes a dedicated Graph page:

• Directory tree with collapsible folders, language badges, and symbol counts per file
• File detail view showing symbols grouped by kind (class/function/method/interface/type/enum), with color-coded badges
• Import relationship view — see what a file imports and what imports it
• Symbol search with live results
• Build status — file/symbol/edge counts, last build time, manual rebuild button

Web Management Panel

Built-in full-stack UI with real-time WebSocket updates:

| Page | What You See | |---|---| | Projects | Create and manage projects | | Chat | SSE streaming conversation with PM Agent, tool call visualization, model selection | | Agents | Real-time agent monitor — running/idle status, activity timeline, emergency stop | | Graph | Project code graph — directory tree, symbol browser, import relationships, impact analysis | | Memory | 5-tab pipeline view — Overview (pipeline stats), L1 Traces, L2 Task Records, L3 Experiences (approve/reject/batch), L4 Global Knowledge | | Models | Configure LLM providers, API keys, role assignments, capabilities | | Settings | Language (en/zh), concurrency, review strictness, review rounds |

Quick Start

Prerequisites

• Node.js 22 LTS or later — https://nodejs.org
  • Prebuilt binaries for native modules are automatically downloaded during installation
  • No compilation tools (Visual Studio, Xcode, build-essential) required

Install

# 全局安装
npm install -g @jiuicy/synapseai

# 验证安装
syna --version

# 创建并启动项目
syna init my-project
cd my-project
syna start

Open http://localhost:8896 in your browser. The UI will guide you through:

1. Configure a model — add an LLM provider with your API key
2. Create a project — name, type, and working directory
3. Chat with PM — describe what you want to build

Tech Stack

| Component | Choice | |---|---| | Language | TypeScript (strict mode) | | Runtime | Node.js 22+ | | Storage | SQLite (better-sqlite3) | | Code Parsing | web-tree-sitter (38 WASM grammars, 30+ languages) | | Vector Search | sqlite-vec | | LLM Protocol | Anthropic + OpenAI-compatible | | MCP | @modelcontextprotocol/sdk | | Frontend | React + Vite + TailwindCSS | | Communication | REST API + WebSocket + SSE streaming |

Comparison

| Feature | Cursor / Windsurf / Claude Code | Devin | SynapseAI | |---|---|---|---| | Persistent memory across sessions | ✗ | ✗ | 4-layer structured memory pipeline | | Multi-agent parallel collaboration | Single agent | Fixed pipeline | Role-specialized team with parallel execution | | Autonomous code review | ✗ (manual) | Basic | Configurable Reviewer Agent with retry loop | | Cross-project experience reuse | ✗ | ✗ | L4 global knowledge with auto-promotion | | Token-efficient context | Stuff everything | Fixed window | Index injection + LLM Dispatcher + on-demand query | | Enforced development workflow | ✗ | ✗ | 5-phase gated workflow with user confirmation | | Self-hosted | ✗ | ✗ (cloud only) | Fully self-hosted, data stays local | | LLM provider flexibility | Locked to vendor | Locked | Any OpenAI-compatible or Anthropic provider | | Project code graph | ✗ | ✗ | 30+ language AST parsing, incremental updates, graph-aware workflows | | Real-time monitoring | ✗ | Basic dashboard | WebSocket-powered agent activity timeline |

License

SynapseAI is free for personal and educational use. Commercial use requires a license.

• Personal / Education / Open Source Projects: Free under AGPL-3.0
• Commercial Use: Contact jiuicy for commercial licensing

See LICENSE for details.

Built with care by jiuicy

If you find this project useful, consider giving it a ⭐

为什么做 SynapseAI？

当前主流 AI 编程助手都有一个致命缺陷：它们会忘掉一切。每次会话从零开始，上下文窗口溢出，多文件改动静默出错，代码生成和代码交付之间没有任何质量关卡。

SynapseAI 采用了完全不同的思路：

• 记忆优先架构 — 4 层管线自动捕获、结构化、复用知识，跨会话、跨项目持续积累
• 多 Agent 并行协作 — 专业化 Agent 团队并行工作，替代单 Agent 对话式压缩
• 强制质量工作流 — 自主代码审查、需求严格确认、强制阶段门控
• 智能上下文注入 — DispatcherAgent 用 LLM 精选相关上下文，从根源防止溢出

解决现有工具的核心痛点

| 痛点 | 其他工具的做法 | SynapseAI 的做法 | |---|---|---| | 跨会话无记忆 | 每次从零开始，重新学习代码库，重复犯错。 | 4 层记忆管线 — L1 原始日志 → L2 任务记录 → L3 评分经验 → L4 全局知识。每次会话都站在之前的工作之上。 | | 单 Agent 单上下文 | 一个 Agent 包揽规划、编码、测试、文档。上下文爆满 → 质量暴跌。 | 角色专业化团队 — PM 规划，Worker 并行编码，Reviewer 审查，Dispatcher 精选上下文。每个 Agent 专注处理精简的上下文。 | | 无代码质量关卡 | 写完代码直接交付，bug 静默混入。 | 强制代码审查循环 — Reviewer Agent 审查每个任务产出。发现问题则重置任务并注入反馈，循环直到通过。 | | 上下文窗口溢出 | 把所有内容塞进 prompt，溢出后开始出错。 | 索引注入 + LLM Dispatcher — 注入精简索引（每条约 30 token），DispatcherAgent 精选相关内容，Agent 按需查询完整详情。 | | 经验无法跨项目复用 | 每个新项目重复踩坑，学习曲线永远存在。 | 跨项目经验晋升 — 高通用性经验自动晋升至 L4 全局知识库。新项目直接从已验证模式启动。 | | 需求理解不到位 | Agent 还没搞清楚要做什么就开始写代码。 | 强制 5 阶段工作流 — PM 必须完成需求确认、设计和任务规划，用户逐阶段确认后才开始编码。 |

4 层记忆与经验管线

这是 SynapseAI 的核心创新。知识沿单向管线流经 4 个层级，每一层都增加结构和可复用性：

┌──────────────────────────────────────────────────────────────────┐
│                     4 层记忆与经验管线                              │
│                                                                    │
│  L1 原始日志            L2 任务记录            L3 项目经验        │
│  ┌───────────┐         ┌──────────────┐        ┌─────────────┐  │
│  │ Worker    │ LogAgent │ 结构化摘要    │ 经验    │ 评分模式     │  │
│  │ 操作记录  │ ──────→ │ 陷阱/方案/   │ Agent  │ 复现/通用/  │  │
│  │ 推理过程  │         │ 修改文件     │ ──────→ │ 可操作评分  │  │
│  │ PM 对话   │         │              │        │             │  │
│  └───────────┘         └──────────────┘        └──────┬──────┘  │
│                                                        │          │
│                              用户审核通过（通用性 ≥ 75）│         │
│                                                        ▼          │
│                                                L4 全局知识         │
│                                                ┌──────────────┐   │
│                                                │ 跨项目可复用  │   │
│                                                │ 已验证模式    │   │
│                                                └──────────────┘   │
└──────────────────────────────────────────────────────────────────┘

| 层级 | 存储内容 | 生成方式 | 消费者 | |---|---|---|---| | L1 原始日志 | 原始工具调用、推理步骤、PM 对话 | Agent 执行期间实时捕获，仅追加 | LogAgent → 输入 L2 | | L2 任务记录 | 结构化摘要：目标、方法、陷阱、解决方案、修改文件 | LogAgent 在任务完成时汇总 L1 日志 | ExperienceAgent → 输入 L3 | | L3 项目经验 | 评分可复用模式（复现性、通用性、可操作性 3 维度评分） | ExperienceAgent 从 L2 记录中提取；等待用户审核 | DispatcherAgent → 上下文注入 | | L4 全局知识 | 跨项目已验证知识 | 用户审核通过且通用性 ≥ 75 时自动晋升 | 所有新项目 |

核心设计决策：

• 管线是事件驱动的，在任务完成时触发，而非定时轮询
• L3 经验需要用户显式审核才会激活
• L4 晋升基于通用性评分阈值自动化完成
• 所有层级在 Agent 执行期间都可通过工具调用查询

强制 5 阶段开发工作流

SynapseAI 强制执行严格的开发流程，PM Agent 在每个阶段转换处设置门控：

阶段 1              阶段 2            阶段 3            阶段 4               阶段 5
需求确认        →   技术设计       →  任务规划       →  并行执行          →  交付
   ↓                  ↓                 ↓                 ↓                    ↓
用户通过对话       PM 提出设计方案    PM 创建带依赖     Worker 并行执行       PM 撰写
确认需求           用户确认门控       关系和完成标准的   Reviewer 审查         文档与测试
                                     任务列表          每个任务产出

阶段 1 — 需求确认 — PM Agent 通过结构化对话引导需求，产出 PRD。用户必须明确确认才能继续。

阶段 2 — 技术设计 — PM 设计架构、记录决策、产出设计文档。用户必须确认设计后才能创建任务。

阶段 3 — 任务规划 — PM 将设计拆解为按依赖排序的任务，附带具体完成标准。用户必须确认计划后调度器才启动。

阶段 4 — 并行执行 — 调度器将任务分发给 Worker Agent：

1. Worker 按依赖关系并行执行（可配置最大并发数）
2. 每个 Worker 完成后，Reviewer Agent 审查代码差异
3. 发现问题 → 任务重置，新 Worker 带着审查反馈重新执行
4. 循环直到代码通过或达到最大审查轮次
5. 全部任务完成 → 系统自动创建集成测试任务

阶段 5 — 交付 — PM 撰写部署文档、测试报告和最终 README。

场景感知的 PM 工作流

传统 AI 编程工具处理所有请求的方式都一样：收到指令 → 开始编码。SynapseAI 的 PM Agent 先判断场景，再执行专门针对该场景设计的工作流。这避免了最常见的失败模式。

场景 A：从零开始项目开发

即上文描述的标准 5 阶段流程，效果良好，无需改动。

场景 B：项目解读与分析

两阶段深度分析 — 不只是读 README。

阶段 1：结构扫描
  PM 扫描项目结构（package.json、目录树、入口文件、配置文件）
  → 产出"项目地图"，识别功能模块和依赖关系
  → 用户确认地图准确

阶段 2：模块深潜
  PM 创建并行研究任务 — 每个功能模块一个
  → 每个 Worker 获得：模块边界、项目地图上下文、需要回答的关键问题
  → Worker 并行分析模块，阅读源码并追踪数据流
  → PM 汇总所有结果，产出完整的 PROJECT_ANALYSIS.md

场景 C：新增功能

场景 A 的简化版本。PM 先扫描相关现有代码了解约定和模式，再规划与现有架构集成的任务。不需要重新设计整个系统。

场景 D：删除/修改功能

两阶段流程 + 强制确认，执行任何破坏性操作前必须获得用户确认。

阶段 D1：影响分析 + 确认（此时不改动任何代码）
  PM 分析将要受影响的内容：
  → 需要修改/删除的文件、会受影响的依赖代码、
    API 变更、数据模型变更、受影响的测试
  → 向用户呈现结构化影响报告
  → ⚠️ 用户明确确认前不会创建任何任务

阶段 D2：执行 + 残留检查
  确认后：PM 创建限定范围的任务
  执行后：PM 运行残留检查
  → grep 检查残留引用、悬空 import、死代码、孤立配置
  → 报告发现，询问是否需要创建清理任务

场景 E：修复 Bug

三阶段流程 — 先确认、再排查、后修复。

阶段 E1：Bug 确认（此时不进行任何排查）
  PM 用结构化提问引导：
  → 期望行为是什么？实际行为是什么？
  → 每次都复现还是有特定条件？
  → 有报错信息/日志/截图吗？
  → 近期有相关改动吗？
  PM 用精确格式复述 bug → 用户确认描述准确

阶段 E2：排查 + 诊断
  PM 用 bash 排查根因（读文件、追踪代码路径、查 git 历史）
  → 呈现结构化诊断报告：
    根因、位置、原因、建议修法、风险评估
  → 用户确认诊断正确

阶段 E3：修复
  确认诊断后才创建针对性修复任务
  修复后验证：原始 bug 已解决 + 无回归

场景对比总结

| 场景 | 传统 Agent | SynapseAI PM | |---|---|---| | 项目解读 | 读 README + 几个文件 → 浅层摘要 | 结构扫描 → 并行模块分析 → 综合报告 | | 删除/修改 | 立即动手删除 → 祈祷不出事 | 影响分析 → 用户确认 → 执行 → 残留检查 | | 修复 Bug | 「点不开」→ 立刻排查错误的问题 | 结构化确认 → 确认诊断 → 针对性修复 |

智能上下文注入

传统方法把所有内容塞进 prompt。SynapseAI 做法完全相反：

索引模式注入

每个 Worker 只接收精简索引（标题 + 摘要，每条约 30 token），而非完整文档：

## 相关经验索引
- E03 JWT 认证竞态问题 [评分: 87] — token 刷新竞态，方案: 双 token 机制
- E07 SQLite 迁移陷阱 [评分: 72] — 锁竞争，方案: WAL 模式 + 事务批处理

## 项目记忆索引
- #12 后端路由架构 — 分层路由, Express Router, 中间件链
- #34 数据库迁移方案 — better-sqlite3 migrator, 版本追踪

DispatcherAgent（LLM 驱动的智能选择）

不使用规则过滤，而是用一个轻量 LLM 调用从全量索引中精选最相关的经验、技能和 MCP 工具：

DispatcherAgent 输入：任务标题 + 描述 + 完整经验/记忆/技能/MCP 索引
DispatcherAgent 输出：selected_experience_ids + selected_skill_ids + selected_mcp_ids

按需查询

Worker 通过工具调用按需查询完整详情：

• memory_search / memory_get — 查询项目记忆
• experience_search / experience_get — 查询已验证经验
• Skill 和 MCP 工具调用 — 动态扩展能力

结果：接近零的上下文浪费。 Agent 只看到相关内容，按需获取详情。

代码图谱 — 持久化项目知识

每次 Worker 接任务都不应该从零探索代码（bash/grep/read）。SynapseAI 为每个项目维护一个持久化代码知识图谱，让 PM、Worker、Reviewer 都能基于图谱精准理解项目结构。

图谱存储内容

codegraph_files      — 每个已解析的源文件（语言、内容哈希、解析状态）
codegraph_symbols    — 函数、类、方法、接口、类型、枚举、import
codegraph_edges      — imports、calls、extends、implements、contains、uses_type、exports

每个符号包含：限定名（如 UserService.authenticate）、类型、行范围、修饰符（export/async/static/...）、父符号、文档注释。每条边连接一个源符号到目标符号或外部包。

30+ 语言 AST 解析

SynapseAI 使用 tree-sitter WASM 语法文件进行精确的 AST 提取，而非脆弱的正则匹配。38 个预编译语法文件覆盖 30+ 语言：

| 类别 | 语言 | |---|---| | Web 与前端 | TypeScript, TSX, JavaScript, JSX, Vue, HTML, CSS (SCSS/LESS) | | 系统编程 | C, C++, Rust, Go, Zig, Objective-C | | JVM 与 .NET | Java, Kotlin, Scala, C# | | 脚本语言 | Python, Ruby, PHP, Lua/Luau, Bash/Zsh | | 函数式 | Haskell, Elixir, Erlang, OCaml, Elm, Gleam, ReScript | | 移动端 | Swift, Dart, Kotlin | | 数据与配置 | JSON, YAML, TOML, SQL | | 专业领域 | Solidity, Julia, R, TLA+, Swift |

17 个专用 AST 提取器处理各语言特有的节点类型、import 语法、调用模式和修饰符体系。通用配置驱动提取器为其余语言提供基线支持。

增量图谱更新

图谱无需全量重建即可保持最新：

Worker 完成任务  →  Reviewer 通过  →  触发增量更新
                                            │
                                            ├─ 仅重新解析修改的文件
                                            ├─ 查找并重新解析直接依赖者（import 了修改文件的文件）
                                            └─ 包裹在 SQLite 事务中保证原子性

首次接触已有项目（场景 B）触发全量构建。之后仅重解析变更文件及其依赖者。

图谱驱动的 Agent 工作流

PM Agent 拥有两个专用工具：

• build_graph — 构建或重建完整项目图谱（用于场景 B：项目解读与分析）
• query_graph — 查询图谱，支持子命令：structure、dependents、impact、symbol、search

场景 C/D/E 现在在开头增加了强制图谱查询步骤 — PM 在分析和代码修改前先查看项目架构和影响范围。

Worker Agent 拥有 codegraph_query 工具用于实时查询：

• symbol — 查找符号定义及其位置
• callers / callees — 追踪调用链
• imports / imported_by — 追踪 import 依赖

上下文注入 — 图谱根据任务的可写文件范围，自动将相关代码结构注入到每个 Worker 的上下文中，提供符号定义和依赖关系，无需手动探索。

Web 图谱可视化

内置 Web 管理面板提供专用图谱页面：

• 目录树 — 可折叠文件夹，语言标记，每个文件的符号计数
• 文件详情 — 按类型分组的符号列表（class/function/method/interface/type/enum），彩色标记
• import 关系视图 — 查看文件 import 了什么以及被谁 import
• 符号搜索 — 实时搜索结果
• 构建状态 — 文件/符号/边数量、最后构建时间、手动重建按钮

强制代码审查

每个任务产出都要经过自主审查循环：

Worker 完成任务
      │
      ▼
Reviewer Agent 启动（独立 Worker Thread）
      │
      ├─ 读取任务分支的 git diff
      ├─ 通过 read_file 检查完整文件上下文
      ├─ 通过 bash 运行测试
      ├─ 通过 memory_search 检查项目约定
      │
      ▼
输出结构化审查报告：
  ├── 通过 → 合并到 main，标记任务完成
  └── 发现问题 → 任务重置并注入反馈，新 Worker 重试
                    (最多 max_review_rounds 轮，超过则强制标记失败)

可配置的审查严格度：

• Off — 跳过审查
• Loose — 仅标记崩溃、数据丢失、安全漏洞
• Medium — + 业务逻辑错误、代码结构、缺失的错误处理
• Strict — + 安全漏洞、竞态条件、性能问题、命名规范、代码重复

多 Agent 并行架构

用户 ←→ PM Agent（SSE 流式对话 + Agent 工具循环）
                    │
                    ▼
            MemoryButler（常驻协调器）
             ├─ Scheduler（任务调度 + 审查循环 + 并发控制）
             ├─ ContextInjector（索引注入 + DispatcherAgent）
             ├─ LogAgent（L1 → L2 任务记录汇总）
             ├─ ExperienceAgent（L2 → L3 经验提取与评分）
             ├─ EventQueue + WebSocket（实时 UI 更新）
             └─ WriteQueue（SQLite 串行写入安全）
                    │
           ┌────────┼────────┐
           ▼        ▼        ▼
        Worker   Worker   Reviewer   （Worker Thread，并行执行）
           │        │        │
           └────────┼────────┘
                    ▼
          全局记忆库（SQLite + sqlite-vec）

每个 Agent 角色专精于一项工作：

• PM Agent — 与用户对话，规划需求，设计架构，创建任务
• Worker Agent — 执行开发任务，受限文件访问，具备记忆查询工具
• Reviewer Agent — 只读审查 Worker 产出，可配置严格度
• LogAgent — 将 L1 执行日志汇总为结构化 L2 任务记录
• ExperienceAgent — 从 L2 记录中提取评分可复用模式
• DispatcherAgent — LLM 驱动的上下文精选

多模型灵活配置

为不同角色分配不同模型，优化性价比：

| 角色 | 推荐模型档次 | 原因 | |---|---|---| | PM Agent | 强推理（Opus, GLM-5） | 深度分析、架构设计 | | Worker Agent | 均衡（Sonnet, GLM-4） | 量大，需良好编码能力 | | Reviewer Agent | 均衡（Sonnet, GLM-4） | 读 diff，按清单审查 | | Experience Agent | 轻量（Haiku, GLM-4-Flash） | 摘要与提取 | | Dispatcher Agent | 轻量（Haiku, GLM-4-Flash） | 索引选择 | | Embedding | 专用嵌入模型 | 向量化成本低于对话模型 |

支持 Anthropic 和 OpenAI 兼容协议——可接入任意提供商（Ollama、vLLM、DeepSeek、Groq、本地模型等）。

Web 管理面板

内置全栈管理界面，WebSocket 实时更新：

| 页面 | 功能 | |---|---| | 项目 | 创建和管理项目 | | 对话 | SSE 流式与 PM Agent 对话，可视化工具调用，模型选择 | | Agent | 实时 Agent 监控 — 运行/空闲状态、活动时间线、紧急停止按钮 | | 图谱 | 项目代码图谱 — 目录树、符号浏览器、import 关系、影响分析 | | 记忆与经验 | 5 标签管线视图 — 概览（管线统计）、L1 原始日志、L2 任务记录、L3 项目经验（审核/驳回/批量操作）、L4 全局知识 | | 模型 | 配置 LLM 提供商、API Key、角色分配、能力参数 | | 设置 | 语言（中/英）、并发数、审查严格度、审查轮次 |

快速开始

前置要求

• Node.js 22 LTS 或更高版本 — https://nodejs.org
  • 安装时自动下载预编译的原生模块
  • 无需安装编译工具（Visual Studio、Xcode、build-essential）

安装

# 全局安装
npm install -g @jiuicy/synapseai

# 验证安装
syna --version

# 创建并启动项目
syna init my-project
cd my-project
syna start

在浏览器打开 http://localhost:8896，UI 会引导你：

1. 配置模型 — 添加 LLM 提供商和 API Key
2. 创建项目 — 名称、类型和工作目录
3. 与 PM 对话 — 描述你想构建什么

技术栈

| 组件 | 选型 | |---|---| | 语言 | TypeScript（严格模式） | | 运行时 | Node.js 22+ | | 存储 | SQLite（better-sqlite3） | | 代码解析 | web-tree-sitter（38 个 WASM 语法文件，30+ 语言） | | 向量搜索 | sqlite-vec | | LLM 协议 | Anthropic + OpenAI 兼容 | | MCP | @modelcontextprotocol/sdk | | 前端 | React + Vite + TailwindCSS | | 通信 | REST API + WebSocket + SSE 流式 |

横向对比

| 特性 | Cursor / Windsurf / Claude Code | Devin | SynapseAI | |---|---|---|---| | 跨会话持久记忆 | ✗ | ✗ | 4 层结构化记忆管线 | | 多 Agent 并行协作 | 单 Agent | 固定流水线 | 角色专业化团队，并行执行 | | 自主代码审查 | ✗（手动） | 基础 | 可配置 Reviewer Agent + 重试循环 | | 跨项目经验复用 | ✗ | ✗ | L4 全局知识自动晋升 | | Token 高效上下文 | 全量塞入 | 固定窗口 | 索引注入 + LLM Dispatcher + 按需查询 | | 强制开发工作流 | ✗ | ✗ | 5 阶段门控工作流，用户逐阶段确认 | | 自托管 | ✗ | ✗（仅云端） | 完全自托管，数据留在本地 | | LLM 提供商灵活度 | 绑定厂商 | 绑定 | 任意 OpenAI 兼容或 Anthropic 提供商 | | 实时监控 | ✗ | 基础面板 | WebSocket 驱动的 Agent 活动时间线 | | 项目代码图谱 | ✗ | ✗ | 30+ 语言 AST 解析，增量更新，图谱驱动工作流 |

许可证

SynapseAI 个人和教育用途免费。商用需要获得授权。

• 个人 / 教育 / 开源项目：免费使用，基于 AGPL-3.0
• 商用：请联系 jiuicy 获取商业授权

详见 LICENSE。

Built with care by jiuicy

如果这个项目对你有帮助，请给个 ⭐