Technical Briefing: TencentDB-Agent-Memory

The Problem

Teams using AI agents face repetitive onboarding: every new session repeats context explanation, every agent re-reads the same documents, and validated workflows must be rediscovered. This repository addresses that by turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) governed across a team of agents. It is not a chat interface—it is a memory hub that accumulates experience and passes it to the next agent.

What This Does

TencentDB Agent Memory comprises five self-contained projects. MemoryCore (324 files, 285 code files) is the central hub—it stores, transforms, and routes memory assets. MemoryProxy (150 files, 137 code files) handles agent integration and injection points. MemoryPanel (200 files, 143 code files) provides the web UI for asset review and management. MemoryKnowledge (69 files, 57 code files) manages documentation and code-to-wiki conversion. The sdk (38 files, 26 code files) offers a consumable interface for external frameworks.

Recurring techniques across projects include: TypeScript-first internal APIs (578 TS files), Docker-gated deployments, pnpm workspace dependency management, and GitHub Actions CI. The openclaw-plugin within MemoryCore exports tools for conversation search, memory search, and COS storage operations, while the hermes-plugin provides a Python gateway client for the Hermes research agent framework.

How It Is Wired

Execution begins at MemoryCore/index.ts, which aggregates and exports the five projects. The internal call graph reveals key hubs and cycles:

  • MemoryCore/src/core/types (Ca 36, Ce 0, instability 0): 36 modules import this types definition; it is the most depended-upon stable module in the core.
  • MemoryProxy/src/types (Ca 44, Ce 0, instability 0): 44 modules import the proxy’s type surface—wide blast radius, low internal complexity.
  • MemoryProxy/src/injection/index (Ca 2, Ce 35, instability 0.95): high instability; few import it, but it imports 35 modules, making it a volatility point.
  • MemoryCore/src/gateway/server (Ca 0, Ce 49, instability 1): nothing imports it, but it imports 49 modules—an unstable leaf node.
  • MemoryCore/src/core/storage/adapter (Ca 30, Ce 1, instability 0.03): stable adapter with 30 importers; one outgoing import.

A soundness-level import cycle involves three files: MemoryCore/src/core/store/types.ts, MemoryPanel/web/src/lib/api/base.ts, and MemoryCore/src/core/record/l1-writer.ts. This cycle must be broken before new core features can be safely added without risk of circular dependency breakage.

The gateway server at MemoryCore/src/gateway/v2-router.ts is oversized (1396 lines), and MemoryCore/src/metadata/service/metadata-service.ts (also oversized) both exemplify cognitive load findings where a single change ripples widely.

How To Use It

Setup: Clone the repository verbatim:

git clone https://github.com/moses-y/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory

Install dependencies with pnpm:

pnpm install

Configuration: Copy the example environment file:

cp MemoryCore/.env.example .env

Edit .env to fill in two sets of LLM parameters (memory group + proxy group) as documented in INSTALL.md.

Running it: Start all three services (memory-core, memory-hub, proxy) in one command:

cd deploy/global-images
cp .env.example .env
$EDITOR .env
./start-all.sh

The panel opens at <http://localhost:8125>. For standalone Memory Hub deployment, Proxy usage with Claude Code/CodeBuddy, or stop/cleanup procedures, consult INSTALL.md.

Migration from older versions: If upgrading from v1.x/v0.x, use the data migration tool referenced in MemoryCore/scripts/migrate-v2-to-v3/README.md.

Real-World Use

A mid-sized AI team onboard three new agents to a codebase. Instead of each agent re-reading the architecture docs and repeating prior design decisions, the team loads the existing Code-Graph and Skill assets from the Memory Hub. New agents receive pre-extracted context, reducing onboarding turns from hours to minutes and eliminating redundant design discussions. The team’s accumulated experience persists across sessions, and the Code-Graph asset ensures future agents navigate the codebase without starting from page one.

Code Health & Issues

The static analysis (657 source files analyzed) produced 220 findings across 7 kinds. The 12 code health audit findings are:

  • [HIGH] No test suite — 657 source files, zero test files. Any change ships with no signal that existing behavior holds; regressions reach production undetected. Fix: add one test per public entry point, then a CI step that runs them.
  • [HIGH] Missing lockfile — MemoryCore/openclaw-plugin/package.json has a manifest but no committed lockfile. An unlocked range means the tested artifact can differ from the shipped one. Fix: run the package manager once and commit the generated lockfile.
  • [MEDIUM] GITHUB_TOKEN permissions — .github/workflows/pr-ci.yml declares no permissions. The token inherits repository defaults, allowing injected steps to push or mint releases. Fix: add permissions: contents: read at the top of the workflow.
  • [MEDIUM] No dependency update bot — 8 manifests, no Dependabot or Renovate configured. Published advisories go unpatched unless manually audited. Fix: commit .github/dependabot.yml covering repo ecosystems and github-actions.
  • [MEDIUM] CI installs from source, not lockfile — npm install with a committed package-lock.json means the tested dependency set differs from the locked one. Fix: use npm ci, yarn install --immutable, or pnpm install --frozen-lockfile in CI.
  • [MEDIUM] Untagged Docker base image — MemoryCore/Dockerfile uses node:22-slim without a digest. Today’s build and last month’s contain different libc and a different CVE set, with no record of which shipped. Fix: use image:tag@sha256:<digest> and enable Dependabot’s docker ecosystem.
  • [MEDIUM] No dependency vulnerability scan in CI — No dependency-review-action or osv-scanner gate on pull requests. Fix: add dependency-review-action on pull_request, or osv-scanner on push and a schedule.
  • [MEDIUM] Large binaries in repository — assets/videos/memoryhub_demo.mov (9.3MB) and memoryhub_demo.cn.mov (8.6MB) are checked in. Every clone and CI checkout pays for undiffed data. Fix: track with Git LFS or move to object storage and fetch in a setup step.
  • [MEDIUM] Checkout retains token — pr-ci.yml checkout keeps the token, then installs dependencies. The token stays in .git/config for later steps, so a malicious postinstall script could read pushable credentials. Fix: add persist-credentials: false on checkout, and pass an explicit token only to the step that pushes.
  • [MEDIUM] No non-root user in Docker image — MemoryCore/Dockerfile has no USER directive. A process running as root in the container is root against every mounted volume, turning any container escape into a host-level issue. Fix: create an unprivileged user, chown what it needs, and end the Dockerfile with USER.
  • [MEDIUM] High branching density — MemoryCore/src/config.ts, MemoryCore/src/core/store/embedding.ts, and MemoryCore/src/core/record/l1-writer.ts have 183 branch points over 545 lines. Fix: decompose decision-heavy logic; consider table/strategy dispatch.
  • [MEDIUM] Deep nesting — MemoryPanel/web/src/pages/code/CodePage/components/CodeSourcesPanel.tsx, MemoryPanel/web/src/pages/team/components/shared.tsx, and MemoryPanel/web/src/pages/wiki/WikiPage/components/WikiSourcesPanel.tsx have max indentation depth 8. Fix: flatten with early returns/guard clauses; extract inner blocks.

Additional structural findings include: an import cycle among three files, 18 hub modules with high blast radius, 7 oversized files, 1653 duplicated 6-line blocks across 197 files, and broad exception handling in MemoryCore/hermes-plugin/memory/memory_tencentdb/client.py.

The Bottom Line

This is a functional, well-scoped portfolio of five projects that solve a real team-onboarding pain point through reusable memory assets. MemoryCore and MemoryProxy are the substantial, heavily-connected projects; the others are smaller but integral to the hub. The code health picture is mixed: strong technical execution (TypeScript rigor, Docker configuration, CI pipeline) but significant SDLC gaps—no tests, no lockfile, no dependency scanning, and large binaries in the repo. Teams that can tolerate the current hygiene gaps will gain immediate value from the memory-hub concept; teams requiring production-grade CI/CD and test coverage should plan remediation before scaling.

Use if: You need a team memory hub for AI agents and can work around the current test and dependency hygiene gaps. Avoid if: You require out-of-the-box test coverage, strict supply-chain guarantees, or a minimal bundle size.