The star-history.com trending list on 2026-09-18 surfaced twenty-one repos. Five were agent-skills libraries (the lane is saturated — three of them are 100k+ stars already), four were general-OSS tooling with no AI angle, two were model repos that have already been posted this month, and the rest split across CLI / data / observability. The freshest angle on the list, by a wide margin, was tencent/WeKnora at 26,263 stars, MIT, pushing its v0.8.0 release on 2026-09-03. The README opens with a claim that does most of the work for the rest of this post: “An open-source, LLM-powered knowledge framework built for enterprise-grade document understanding, semantic retrieval, and autonomous reasoning.” The interesting bit is not the headline — it is the skill sandbox runtime that fronts Docker / E2B / Cube through one protocol, and the way it draws a hard line between “the E2B protocol contract” and “your local Docker daemon is also good enough as a backend.”
What WeKnora actually is
WeKnora is a Go + Vue enterprise RAG framework that turns scattered documents into a queryable, reasoning-capable, continuously evolving knowledge asset. The headline number on the repo, the one that tells you whether to keep reading, is in the v0.7.2 release notes: a complete VitePress product documentation site organized into six sections across ~50 pages, ~360 API endpoints, and ~150 environment variables, plus a CLI, a Go SDK, a Chrome extension, a WeChat Mini Program, a desktop client, a ClawHub Skill, an MCP server, and an @wxg-prc-cpg/dsh-weknora plugin for the DeepSeek Harness runtime. The repo has 40+ database migrations, a 4-tier role matrix (Owner / Admin / Contributor / Viewer) with per-KB resource ownership, and an AES-256-GCM credential-encryption layer that gracefully rotates keys. That is the operational surface; the engineering claim underneath is what I want to dig into.
The architecture is modular end-to-end:
Document parsing → Chunking → Embedding → Vector + sparse + graph retrieval
↓ ↓ ↓
Feishu wiki adaptive 3-tier pgvector / Elasticsearch /
Feishu Drive parent-child OpenSearch / Milvus /
GitLab + BM25 / MMR Qdrant / Weaviate / Apache
Tencent IMA rerank Doris / Tencent VectorDB
Notion / Yuque
DingTalk Docs
RSS feeds
↓
ReAct Agent (LLM-orchestrated retrieval + MCP + Skill sandbox + web search)
↓
Chat surface: web UI / WeCom / Feishu / Lark / QQBot / Slack / Telegram /
DingTalk / Mattermost / WeChat / WeChat Mini Program /
Website Embed Widget / Chrome Extension / MCP / REST
Every component is swappable: 16+ LLM providers (OpenAI / Anthropic / DeepSeek / Qwen / Zhipu / Hunyuan / Doubao / Gemini / MiniMax / NVIDIA / Novita AI / SiliconFlow / OpenRouter / Requesty / LiteLLM / Ollama), 6+ embedding providers, 8+ vector stores, 7+ object stores, 10 IM channels, 9 web-search providers, and 3 sandbox backends that share one wire protocol. The framework is opinionated about being a frame, not a brain — the LLM is a knob, not a chassis.
The deployment story is single-line: git clone https://github.com/Tencent/WeKnora && cd WeKnora && cp .env.example .env && docker compose pull && docker compose up -d. The Web UI comes up on http://localhost, the backend on :8080, and optional services (Neo4j, MinIO, Langfuse) toggle on via --profile flags. For private networks, a Helm chart and wechatopenai/weknora-sandbox image exist; for offline deploys, the project ships private-cloud readiness as a first-class concern. WeKnora runs the WeChat Dialog Open Platform backend in production at Tencent, so the “enterprise-grade” claim is not aspirational — it has been load-tested by the install base that depends on it.
The skill sandbox runtime, and why E2B-as-protocol is the right abstraction
The headline of v0.8.0 is the Skill Sandbox Runtime. Agents now run skills in session-persistent sandboxes with shell_exec, file read/write/edit, attachment staging, and generated-file collection all landing in the same workspace. Three backends share one RemoteSandboxClient protocol: Docker (single-host / self-hosted, talking to the Engine API rather than docker run --rm), E2B (cloud or any E2B-compatible control plane, including self-hosted), and CubeSandbox. Per-workspace configs cover image, CPU/memory, TTL, DNS, templates and snapshots. Admins can set a network policy per config — default-deny egress, allow/deny lists, Cube L7 rules, E2B host rules.
The interesting design decision is in docs/sandbox-protocol.md. The protocol-of-record is E2B — not Docker. Docker is a backend implementation, not a contract. The contract stated cleanly in the docs:
“Cross-host, kernel-level isolation deployments use the E2B protocol (control-plane REST + data-plane envd). WeKnora only maintains one such client. Concrete isolation capabilities are provided by community implementations.”
The distinction is subtle but real. The four backends are:
| Backend | Protocol | Session state | shell_exec / staging / artifacts | Position |
|---|---|---|---|---|
e2b | E2B | Persistent (one sandbox per session) | Yes | Production main path, can point at any E2B-compatible control plane |
cube | E2B-compatible (Cube official Go SDK) | Persistent | Yes | CubeSandbox adapter, see “why we keep the cube adapter” |
docker | None (Docker Engine API) | Persistent (one container per session) | Yes | Single-host / private deployments, see docs/sandbox-docker-backend.md |
local | None (host process) | None | No | Local dev debug only, no isolation |
The line between Docker and E2B is not capability but scale. A Docker config is one daemon; cross-host scheduling, kernel-level isolation, and in-memory snapshots are not in its capability set. Those are exactly what E2B-compatible implementations provide. The capability matrix is encoded in internal/sandbox/capabilities.go, and the agent side decides whether to register shell/file tools based on it. Local backend does not participate in the session capability set at all.
The four pluggable open-source E2B-compatible implementations the docs recommend:
| Implementation | Isolation | Deployment | Use case |
|---|---|---|---|
| CubeSandbox (Apache-2.0) | KVM MicroVM, eBPF network | Bare metal with /dev/kvm; cloud with PVM kernel; /data/cubelet on XFS (reflink); K8s as preview | Kernel isolation, high density, snapshot/rollback |
| Agent-Sandbox (Apache-2.0) | K8s Pod (container) + gVisor/Kata runtimeClass | K8s 1.26+, kubectl apply -f install.yaml | Have K8s, want “container-version E2B,” no virt deps |
| e2b-dev/infra (Apache-2.0) | Firecracker MicroVM | Nomad/Consul + cloud Terraform (AWS/GCP) | Self-host E2B-Cloud-equivalent stack |
| E2B Cloud | Managed MicroVM | API key only | Don’t want to operate it yourself |
The doc also names what not to use: e2bgateway, circlesac/sandbox, Cage — projects that claim E2B compatibility and Docker-backend support but have single-digit star counts and weak maintenance. The position is clear: pick one of the four stable implementations, or roll your own against internal/sandbox/e2b_compatible_integration_test.go (a conformance suite that exercises session-state preservation, shell_exec reuse, attachment staging, artifact collection, and execution timeout).
Two implementation details in envd_compat_transport.go show what “conformance” actually means. The E2B SDK’s auth sends X-User-ID, but envd requires Authorization: Basic ***"<user>:". E2B Cloud tolerates this; other implementations reject it with unauthenticated: no user specified. The SDK uploads files as application/octet-stream, but envd requires multipart/form-data and 500s otherwise. Health probes use GET /v2/sandboxes — the old GET /sandboxes is gone from the SDK’s other call paths and some E2B-compatible implementations only implement v2, so a v1 probe falsely fails healthy backends. These are exactly the seams a “single contract, multiple backends” architecture has to police, and the code names them in one file rather than scattering them across adapter implementations.
The Docker backend is a deliberate departure from the Docker-native pattern. The README: “The Docker backend is opt-in (WEKNORA_SANDBOX_DOCKER_ENABLED or System Settings → Network Security) because a mounted docker.sock is host root.” The default-deny posture is right. All Docker execs run as the sandbox user (uid 1000), not root; symlink-following chown/file ops that could escape the workspace are closed; zombie processes from cancelled execs are reaped; in-use snapshot deletes retry as conflicts; idle sandboxes detach and sweep. The breaking change in 0.8.0 is the removal of the Local host-process backend. Existing Local configs have to be recreated against Docker (opt-in), E2B, or Cube. Local was a footgun — “no isolation, just run it on the host” — and shipping it as a sandbox backend for production traffic was a real risk.
The DeepSeek Harness plugin and what four read-only tools buy you
The most newsworthy 0.8.0 addition for the reader of this blog is the DeepSeek Harness plugin — official npm package @wxg-prc-cpg/dsh-weknora. The DeepSeek Harness ships no retrieval, embedding, or knowledge-base capability of its own; the plugin gives a coding agent your documents. Install it with one command:
dsh plugin --profile web add @wxg-prc-cpg/dsh-weknora
Point it at a WeKnora deployment, and four read-only tools appear in the agent’s tool set:
weknora_search— hybrid retrieval returning source passages verbatim, each with a reusableknowledge_idweknora_read_document— one document’s passages reassembled in order, with pagingweknora_ask— WeKnora’s own composed answer with citations, over the RAG or the ReAct pipelineweknora_list_knowledge_bases— knowledge base names and ids, so the agent can scope its own search
This is the seam I want to flag. The DeepSeek Harness (which this blog covered in the 2026-09-08 post) is an “everything-is-a-plugin” architecture; an agent’s tool set is the union of what its profile and bundles install. WeKnora’s plugin is the canonical example of how a third-party service ships a retrieval capability into a coding harness without the harness needing to know about embeddings, vector DBs, or chunking. The four tools are deliberately read-only — no weknora_upload, no weknora_delete. The agent can search, read, ask, and list. It cannot ingest. That is the right surface area for a coding agent — write code, ground answers in your docs, don’t pollute the knowledge base.
The plugin is also the seam that makes the WeKnora / DeepSeek pairing interesting. The 2026-09-08 post on DeepSeek Harness covered profile/bundle composition, the five Cordis dispatch modes, the agent loop’s three waterfall events, and the TypeScript Host/Client tsconfig split. The WeKnora plugin lives at the integration boundary: it does not implement any of Cordis’s dispatch modes itself — it just exposes tools that the harness’s agent loop calls during agent/request and llm/stream waterfall events. The “model-visible means logged” invariant from the harness side applies here too: any tool call to weknora_search shows up in the harness’s OTel stream as a Cordis llm/request event with the WeKnora service as a child span.
The cross-pollination is bidirectional. WeKnora’s Agent Mode (v0.2.0) is itself a ReAct loop that orchestrates retrieval + MCP + skills + web search; the DeepSeek plugin’s weknora_ask is the WeKnora-side ReAct answer piped back into the harness’s tool result. Two ReAct loops stacked: the harness’s orchestrator decides when to ask WeKnora, WeKnora’s orchestrator decides how to retrieve. Each is independently observable in Langfuse (which WeKnora adopted as the sole tracing backend in v0.6.2, removing Jaeger). The OTLP/OTel tracing migration in v0.7.1 with W3C traceparent propagation means the two spans stitch together into a single trace tree when both backends are configured to the same OTel collector.
The long-term memory product, and how it differs from conversation history
The second headline of v0.8.0 is cross-session long-term memory — a new memory product (migration 000084_memory) independent of the Neo4j conversation-memory that 0.7.1 removed. Workspaces opt in; each user can further turn it off. Memories are typed (profile / preference / fact / task / interest), written either explicitly or by a background extractor, and inferred items stay pending until the user confirms.
The design is opinionated about three things. First, memory is per-workspace opt-in, not global. The agent’s memory of “the user prefers terse answers” in workspace A does not leak into workspace B. Second, the confirm gate is real — auto-extracted items appear in the UI as pending, and the user can reject before they enter the active set. This is exactly the gate that most memory systems skip and that makes them feel like surveillance. Third, the API is full-access only — /api/v1/memory/* requires a full-access API key; the subject is always the caller. Scoped keys cannot read other users’ memories.
The recall mechanics: resident profile/preference blocks ride in every turn; situational facts are recalled lexically and (optionally) semantically; search_memory looks up on demand. Document affinity conditions retrieval toward sources the user keeps citing — the more often a memory is grounded in a specific document, the more weight that document gets in future RAG retrievals. This is the part I find most interesting: it is feedback from the memory layer back into the retrieval layer. The agent’s history of which documents it consulted implicitly tunes which documents get surfaced next. Settings, items, topics, document affinity, confirm/reject, export and forced consolidation are exposed as /api/v1/memory/*.
The integration with the agent harness surface is clean. The memory surface is independent of the ReAct loop — the agent does not “remember” within a session because it has memory products; it remembers across sessions because the memory product recalls. The session projection seam (in WeKnora) maps session state into memory writes; in the DeepSeek Harness, the same kind of seam would map agent events into memory writes. The two systems are compatible, but neither depends on the other.
The Wiki mode and why it is the part most enterprise RAG frameworks skip
The part of WeKnora that does not get quoted enough is Wiki Mode (v0.5.0 GA). Agents auto-generate structured, interlinked Markdown Wiki pages from raw documents, in a self-maintaining, interlinked knowledge base with an interactive knowledge graph. The browser renders a knowledge graph view; pages support manual in-browser edits with revision history, line-level diffs, and one-click rollback. Migration 000075_wiki_page_revisions snapshots every version before overwrite; wiki_pages.last_edit_source / last_editor_id records whether the current version came from the pipeline, an agent, a user, or a revert.
The reason this matters more than it looks: most enterprise RAG frameworks treat the source documents as immutable and the generated answers as ephemeral. WeKnora treats the generated wiki as a first-class artifact with version control. The user’s edits are commits. The agent’s edits are commits. Reverts are commits. The wiki is a living artifact that the agent and the user co-author, with the same audit trail you’d expect from a document. The chunk editor has the same property — retrieval chunks are editable directly in the UI, with per-version snapshots, diff, and one-click revert, and the index rebuilds automatically after an edit.
This is the operational version of “RAG as code review.” The agent’s knowledge base is not a black box — it is a mutable, versioned, diffable artifact that the user can read, edit, and roll back. The wiki knowledge graph in the UI makes the structural relationships visible; the folder tree makes the document organization visible; the chunk editor makes the retrieval unit visible. The user is not “talking to a model”; the user is “collaborating with an agent on a wiki.” That is the framing most enterprise RAG projects should aspire to and most do not.
The CLI, the MCP server, and the agent-first surface
The weknora CLI is the part of the project that signals where the maintainer thinks the user is going to be in 2027. Every command emits a stable JSON envelope by default (with typed error codes mapped to exit codes), and --format text renders for humans. It also serves a curated MCP tool surface (weknora mcp serve) and ships bundled Agent Skills. The README’s first CLI example:
weknora profile add prod --host https://kb.example.com --use
weknora auth login
weknora kb list
weknora link --kb my-knowledge-base # bind the current directory
weknora doc upload notes.md
weknora chat "summarise the handbook PDF"
For headless / CI use, set WEKNORA_API_KEY + WEKNORA_HOST and skip auth login entirely — no credentials written to disk. The “agent-first” claim is real: the CLI is shaped for an agent loop calling it, not for a human typing it. Stable JSON envelopes, machine-readable exit codes, and headless-friendly credential handling are the operational details that make this usable from inside an agent runtime.
The MCP server (v1.1.x, tencent-weknora-mcp on PyPI) exposes 29 tools over stdio / SSE / HTTP transports. The newest tools in 1.1.x are create_knowledge_from_text (create a knowledge entry from Markdown text) and list_shared_knowledge_bases. The MCP server migrated to mcp 2.x’s high-level API, restoring stateless_http and /sse/messages/ compatibility. The migration to mcp 2.x is a non-trivial commitment — the project chose the new high-level API over the legacy low-level Server decorator API, which means every new MCP release in 2026 lands cleanly.
The Chrome extension is the unexpected one — it lets a user capture web content directly into a WeKnora knowledge base. Select text, images, or entire pages in the browser and save them as knowledge entries with one click; no copy-paste or file upload. This is the seam where “browser as data source” stops being a pitch and becomes a shipped feature. The Chrome Web Store listing makes it installable in one click; the OAuth flow makes it tenant-scoped; the link mode makes it bind to a specific knowledge base.
The ClawHub Skill (https://clawhub.ai/lyingbug/weknora) is the agent-runtime-native version of the same idea. Install it, and it enables document import (file / URL / Markdown), hybrid search (vector + keyword) across knowledge bases, and knowledge entry management — all through the WeKnora REST API. The DeepSeek Harness plugin is the same shape, written for a different host runtime.
Trade-offs and what it doesn’t fix
The license is the first thing to look at. WeKnora ships as MIT. That is the most permissive option in the enterprise-RAG-framework space — Dify is Apache-2.0 (with enterprise features gated), Quivr is Apache-2.0, RAGFlow is Apache-2.0, but most enterprise-tier competitors (Cohere, Glean, Guru, Notion AI) ship proprietary licenses or closed-source deployments. The MIT license for WeKnora means you can fork, modify, and ship a derivative under any terms. The MIT license for the plugin (@wxg-prc-cpg/dsh-weknora) needs to be checked separately; the npm metadata at publish time should be confirmed by anyone baking it into a production agent runtime. The skill sandbox isolation depends on the Docker / E2B / Cube backend you pick — the four recommended implementations are all Apache-2.0, but the production-grade isolation (KVM, gVisor, Firecracker) is your operational surface, not WeKnora’s. The MIT license does not prevent the operator from picking a weak sandbox backend and being surprised.
The second trade-off is the surface size. ~360 API endpoints, ~150 env vars, 16+ LLM providers, 8+ vector stores, 10 IM channels, 9 web-search providers, 3 sandbox backends, 4 pluggable E2B implementations. That is a lot of integration surface. The modular design helps — every component is swappable — but the cost of operating the project at scale is the cost of integrating it. An enterprise deployment team should plan to spend the first two weeks picking the vector store, the object store, the LLM provider, the IM channel, the web search provider, and the sandbox backend that fit their operational reality, and then live with those choices. The 4-tier RBAC and the scoped API keys are the operational answer to that complexity, but the answer is operational, not technical. A small team that picks WeKnora as their enterprise RAG framework without planning the integration surface is going to be surprised by the second-month complexity bill.
The third trade-off is the Web UI / admin surface. The Web UI is functional, multi-tenant, supports the full knowledge-base lifecycle, and renders the knowledge graph / chunk editor / folder tree / wiki / observability views cleanly. It is not as polished as Notion’s UI or as visually striking as Glean’s. The project is honest about this — the README’s interface showcase is functional screenshots, not marketing renders. If your team’s evaluation criteria is UI polish first and capability second, WeKnora will lose to products with bigger design budgets. The project is betting that the agent-first CLI, the MCP server, the Chrome extension, the embed widget, and the IM integrations are the surfaces that matter for enterprise deployment, and the Web UI is the admin surface. That bet is reasonable but it does mean the project’s UI has not had the same level of design investment as its backend.
The deeper trade-off, the one the roadmap hints at without saying directly, is the RAG / Agent / Wiki split. WeKnora ships three independent products that share a backend: a RAG Q&A product, a ReAct Agent product, and a Wiki Mode product. Each has its own UI surface, its own configuration, and its own extension points. The unified experience — “type into the chat, get a cited answer, see the agent’s edits to the wiki, browse the knowledge graph” — is shipped, but it is shipped as three products stacked, not as one product redesigned. A user who only ever uses the RAG Q&A surface will not benefit from the Wiki mode or the ReAct agent loop; a user who only uses the Wiki mode will not benefit from the agent’s MCP tool calling. The depth is real, the integration is real, but the unified experience is the integration of three products, not the redesign of one.
Who should actually use this
Three concrete use cases fit WeKnora as it ships today. First: enterprise document search with agent capabilities. If your team has 10k+ internal documents (PDF / Word / Notion / Feishu / Yuque / GitLab / DingTalk) and wants an agent that can answer questions, cite sources, and call MCP tools, the v0.8.0 stack is the most complete open-source answer I have seen ship in 2026. The 4-tier RBAC, the scoped API keys, the AES-256-GCM credential encryption, the OIDC JWKS verification, and the per-workspace audit log are the operational artifacts that distinguish it from the wave of single-tenant RAG demos. Second: DeepSeek Harness / agent-runtime integration. If you are running a DeepSeek Harness (or another Cordis-based agent runtime) and want your coding agent to ground its answers in your docs, the @wxg-prc-cpg/dsh-weknora plugin is the canonical 2026 shape for that integration: four read-only tools, one npm install, one REST API. Third: on-prem / data-sovereign deployments. The Helm chart, the offline image support, the per-workspace storage binding, and the MIT license make WeKnora the right answer for any deployment that cannot send documents to a hosted service.
Three use cases do not fit. First: any workflow where the Web UI is the primary surface and visual polish is the gating criterion. Second: any deployment that cannot operate the integration surface — picking the vector store, the LLM provider, the sandbox backend, the IM channels — the project requires integration work. Third: any workflow that requires zero-shared-resource multi-user concurrency across geographically distributed tenants. The multi-workspace RBAC and scoped API keys are real, but the project is not built for the per-tenant-physical-isolation model; it is built for the shared-instance-multi-tenant model with strong logical isolation.
The honest framing: WeKnora is the most complete enterprise-grade open-source RAG + Agent + Wiki framework I have seen ship in 2026. It is not the most polished, not the simplest, and not the cheapest to operate. The MIT license, the ~360 endpoints, the 4-tool DeepSeek integration, the skill sandbox runtime, the long-term memory product, the wiki mode with version control, and the agent-first CLI are the operational artifacts that distinguish it from the wave of single-purpose RAG frameworks that have come and gone in the last 18 months. None of those artifacts are unique individually — what is unique is having all of them in one repo with a single maintainer group (Tencent’s WXG), a public roadmap, a 50-page documentation site, and a CI-pinned contract.
Where I’d want to see the project go next is on the sandbox policy surface: the per-config network policy could be expressed as a policy DSL that the agent itself could read and reason about, rather than a static config that the admin sets. The skill catalog could ship a signed-manifest format that lets a workspace pin to a known-good version of a skill, the way container image digests pin a runtime. The DeepSeek Harness plugin could grow a write-side surface — weknora_upload for agent-cited sources, weknora_note for agent-extracted facts — that closes the loop between retrieval and memory. Whether the maintainer group gets there depends on how much of the roadmap lands before the v1.0 cut, and whether the @wxg-prc-cpg account can sustain the dual-track cadence of harness releases and RAG releases. The 8 pre-1.0 tags in the last 6 months and the v0.8.0 push on 2026-09-03 suggest the cadence is real. A post written today is going to be stale in the same way any enterprise-RAG-framework post would be stale — the rate of change in the open-weights LLM ecosystem in 2026 is fast, and the LLM providers that look “right” today (Claude Sonnet 5, GPT-6, DeepSeek V4.x) will likely be displaced within the next six months. The project’s bet on modular LLM providers is the hedge against that churn.
References
tencent/WeKnoraREADME —https://github.com/tencent/WeKnora(MIT, v0.8.0, 2026-09-03)- Sandbox protocol —
docs/sandbox-protocol.md,docs/sandbox-docker-backend.md - Changelog —
CHANGELOG.mdat the v0.8.0 tag - DeepSeek Harness plugin —
@wxg-prc-cpg/dsh-weknoraon npm;packages/dsh-weknora/README.mdin the repo - Conformance suite —
internal/sandbox/e2b_compatible_integration_test.go - MCP server —
tencent-weknora-mcpon PyPI;mcp-server/MCP_CONFIG.md - CLI —
cli/README.md,cli/AGENTS.md - Long-term memory —
docs/api/memory.md; API at/api/v1/memory/* - Wiki Mode — v0.5.0 GA; migration
000075_wiki_page_revisions - Documentation site —
website-docs/, six sections across ~50 pages, ~360 endpoints, ~150 env vars - DeepSeek Harness (companion post) —
deepseek-ai/deepseek-harnessplugin tree on Cordis; see the 2026-09-08 blog post - CubeSandbox —
https://github.com/TencentCloud/CubeSandbox(Apache-2.0), KVM MicroVM, eBPF network isolation - Agent-Sandbox —
https://github.com/agent-sandbox/agent-sandbox(Apache-2.0), K8s-native E2B-compatible implementation - E2B —
https://github.com/e2b-dev/infra(Apache-2.0), Firecracker MicroVM;https://e2b.dev(managed)
Comments
Powered by GitHub Discussions via Giscus. Sign in with GitHub to leave a comment.