DEV Community: sun young

open-kritt: a Chinese translation of the self-hosted AI vulnerability research tool

sun young — Wed, 14 Oct 2026 10:57:03 +0000

open-kritt: a Chinese translation of the self-hosted AI vulnerability research platform

The original Kritt-ai/open-kritt repository has 2284 stars and is written in JavaScript. It is an open-source, self-hosted platform for AI-driven security and vulnerability research. The project's own one-line description is: "Open-source, self-hosted AI vulnerability research tool that orchestrates agents to find and validate security issues in code."

A Chinese translation of that project now exists at yangshun2005/open-kritt-cn. It was published on 2026-10-14. The Chinese version is new and currently has no stars of its own; the 2284 figure belongs to the original project only.

This article covers what the tool does, why the Chinese documentation matters, and how to get it running. Everything below is drawn from the translated README and the original project's documentation.

The problem open-kritt is trying to solve

Point a language model at an entire repository and ask it to find vulnerabilities, and the results are usually poor. The signal-to-noise ratio is bad, findings are hard to verify, and there is no consistent way to rank them.

open-kritt takes a different approach. Instead of one large prompt against a whole codebase, it breaks research into small, explicit tasks. Multiple AI agents execute those tasks in parallel. Their outputs are then merged into findings that are deduplicated, ranked, and verifiable.

The project is aimed at security researchers and security-conscious developers. The stated goal is to let users control their own prompts, workflows, model providers, and infrastructure.

What the platform actually does

From the README, the core capabilities are:

Build workflows — chain focused prompts into reusable security research playbooks.
Run scans — analyze remote or local repositories and their dependencies using Codex, Claude Code, or Grok Build.
Validate findings — use post-scripts to verify issues, build proof-of-concepts, and generate reports.
Export scan results — package normalized findings, structured data, post-processing output, reports, and PoCs into a single ZIP archive with a shareable manifest. Completed scans produce a full export; stopped or failed scans that still contain findings produce a clearly marked partial export. Reports and PoC source influenced by an attacker are preserved as plain text.
Rank results — apply custom severity rankers, a unified finding schema, and automatic deduplication.
Bring your own model access — use Codex login, or connect via OpenAI, Anthropic, DeepSeek, OpenRouter, or xAI.

The project states it comes out of real security research. The Kritt team, under the researcher name Blockian, reports earning over $1,500,000 in bug bounties (linked profiles on Immunefi, HackenProof, blockian.xyz, and @Kritt_AI on X). open-kritt is described as the open-source distillation of the internal tooling behind that work.

Why a Chinese translation is useful here

The original documentation is in English. For Chinese-speaking developers, that is a real barrier — not because the concepts are impossible to follow, but because setup instructions, threat-model notes, and configuration details are exactly the kind of text where a misread line costs an hour.

The Chinese version is not just a machine-translated dump. It has two layers:

A Chinese quick-start guide at the top, explicitly marked as supplementary material and not part of the original README. Its stated purpose is to let you get the project running without reading the whole document.
A full Chinese translation of the original README body, which the page says aims to stay faithful to the source.

The translation page also invites issues or pull requests for inaccuracies. That is a reasonable posture for a translated technical document, since terminology choices ("finding", "post-script", "severity ranker") are not always obvious.

The practical value is straightforward: a Chinese-speaking developer can read the quick-start, understand the prerequisites and the security warnings, and get the stack running, without first parsing an English document about a security tool where precision matters.

Quick start

Prerequisites: Git, Docker with Docker Compose, and Node.js 20 or newer. The repository ships its own CLI, so there is no installation step.

Clone and enter the directory:

git clone https://github.com/Kritt-ai/open-kritt
cd open-kritt

Run setup, which walks you through available login methods and API key configuration:

./kritt setup

Start the stack:

./kritt start

Then open http://localhost:5173 in a browser.

On a server without a browser or desktop, keep the stack running and open another shell:

./kritt-headless

Environment requirements

The translated README is explicit about some requirements and silent about others. Being precise here matters:

Operating system: the original does not specify supported systems. It only notes the stack can run on a server without a browser or desktop.
Hardware: not specified in the original.
Dependencies: Git, Docker (with Docker Compose), Node.js 20 or newer.
Version requirements: Node.js 20+; other dependency versions are not stated in the original.
Model access: at least one method is required — Codex login, or a connection via OpenAI, Anthropic, DeepSeek, OpenRouter, or xAI.
Network: the translation adds a general note that in mainland China network environments, downloading Docker images or npm dependencies may require switching to a mirror or accelerated source. This is flagged as a general tip and not part of the original text.

Things that will bite you

The translated quick-start calls out several issues that are easy to miss and expensive to get wrong.

No application-layer authentication by default. The default port binds to 127.0.0.1, and the backend does not include application authentication. The stack must stay private. Do not expose it.

Agents run as root. Agents with tools enabled run as root inside one-shot job containers. They have a writable copy of the repository and direct internet access, which is needed to install tools, compile targets, run tests, and build PoCs. Before scanning untrusted code, run on a dedicated Docker host or VM, and read the threat model documentation first.

Model credentials are mandatory. You must configure at least one model access method, either login or API key. ./kritt setup guides you through it. GITHUB_TOKEN is optional and only needed for accessing private GitHub repositories.

The headless CLI has limits. ./kritt-headless does not display the content of vulnerability findings in the terminal. It shows scan status, phases, and failure reasons only.

A note on scope

The Chinese translation covers the README and adds a practical quick-start. It does not change the software. The AGPL-3.0 license, the JavaScript codebase, and the 2284 stars all belong to the original project at Kritt-ai/open-kritt.

If you are a Chinese-speaking security researcher or developer who has been putting off trying open-kritt because of the English docs, the translation removes that specific excuse. The setup path is short: clone, ./kritt setup, ./kritt start. The security warnings are the part worth reading carefully before you point it at anything you do not trust.

Chinese documentation: https://github.com/yangshun2005/open-kritt-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

headcount: 172 skills organized as a company org chart, now with a Chinese README

sun young — Wed, 14 Oct 2026 10:56:22 +0000

There is a specific kind of mess that shows up once you have more than about thirty prompts saved. You stop remembering what you have. Two prompts do nearly the same thing and you can't tell which one is current. You paste a whole "mega-prompt" into a session because you can't be bothered to find the right one, and half of it is irrelevant to the task.

headcount is one answer to that. It arranges agent skills as a company: one chief executive, 16 departments, 172 skills. Each department installs as its own plugin, so a project loads only what it needs. Skills are addressed as department:skill, which means names never collide across departments.

The original repository is cbrock84/headcount, 2047 stars, written in Markdown, MIT licensed. A Chinese translation of the README now exists at yangshun2005/headcount-cn. That's what this post is mostly about, because the translation does something a plain translation usually doesn't.

What the project actually is

The official one-liner: an agent organization structured as a company — 15+ departments, 125+ skills, each independently installable, citing the standards and regulators that settle the question. Runs in Claude Code and ChatGPT.

The README's own numbers are 16 departments and 172 skills. The one-liner says 15+ and 125+. Both appear in the source material; I'm not going to reconcile them, and you shouldn't assume the smaller number is the stale one — the README's department tables are the more granular source.

The structural idea is the part worth understanding. Most prompt libraries are a flat list. headcount is a tree with an install boundary at every branch. The CEO office sits at the top with 7 skills, and the departments below it each carry their own skills plus an agent charter in .claude/agents/. That charter is what lets a department be delegated to as a subagent with its own exclusive write scope — the producer/auditor split the agent-hierarchy skill describes.

Addressing is namespaced. security:threat-modeling, finance:unit-economics, demand-generation:landing-page-cro-expert. You can ask in natural language and let matching load the skill, or you can call it by name when you want a specific perspective:

/finance:financial-modeling

Install, and the constraint that shapes everything

Claude Code:

/plugin marketplace add cbrock84/headcount
/plugin install security@headcount

Then add departments as you need them — /plugin install it-operations@headcount, and so on.

ChatGPT and Codex use the same repository. You add it as a plugin marketplace (ChatGPT reads the manifest at .agents/plugins/marketplace.json), or you copy the departments you want into your own project's .agents/skills/ directory. The skill files are identical on both sides; only the manifests differ, and both manifests are generated from the same directory tree, so a fix lands in both at once. That's what AGENTS.md is about.

Here is the constraint that explains the whole design. On the ChatGPT/Codex side, skill descriptions share a context budget of roughly 8000 characters. All 16 departments together come to roughly 50000. Installing only the departments you'll actually use isn't tidiness — it's the only thing that fits. If you've ever wondered why a plugin system would bother with per-department granularity instead of one big install, that ratio is the answer.

Installing a department doesn't touch your project. It adds skills to the assistant. It doesn't write to your repo, add dependencies, or run anything on its own.

What the Chinese version adds

The Chinese repository is a translation of the original README, dated 2026-10-14, with the original preserved as README_en.md. Stars: zero, as of writing. It was published today. I'm not going to pretend otherwise.

The interesting part is that it isn't only a translation. The page carries two clearly separated layers:

A 中文快速上手 section at the top, explicitly marked as supplementary orientation material, not part of the original. It answers the questions a Chinese-speaking developer hits in the first five minutes: what problem does this solve, what's the shortest path to running it, what are the requirements, what are the traps.
The translated README body below it, which the page states aims to stay faithful to the original.

That split matters more than it sounds. A faithful translation of headcount's README gives you the department tables and the install commands, but it doesn't tell you that the ChatGPT-side 8000-character budget is why you should install two departments instead of sixteen. The original README does mention the budget — but it's buried in a section you'd only read after you'd already formed the wrong mental model. The Chinese page pulls it forward into the orientation section, along with a note that installing a department won't modify your repository, and a note that the original doesn't specify OS, hardware, or version requirements.

That last one is a small honesty signal worth pointing out. A lot of translated READMEs quietly fill gaps with plausible-sounding requirements. This one writes 原文未说明 — "not stated in the original" — and moves on. Same for the domestic-network section: it says the original doesn't mention mirrors or accelerated downloads, rather than inventing a mirror that may not exist.

For a Chinese-speaking developer, the practical difference is the entry cost. The install path is three commands and a natural-language question, and the orientation section gets you there without reading a full README in a second language. The department:skill addressing scheme, the auto-loading behavior, and the "which departments should I install first" question are all answered before the translated body starts.

The page also invites issues or PRs for translation inaccuracies, which is the right posture for a translated doc that will drift as the upstream changes.

The part I'd actually evaluate

The skills themselves are prose. Markdown files describing how a specialist should approach a problem. Whether security:threat-modeling produces something useful depends on the model you're running it against and the specifics of your system, and I haven't tested it against a real threat model. My sample is zero. Treat the department tables as a map of what's covered, not as evidence of output quality.

What is verifiable is the structure. Namespaced addressing that prevents collisions. Per-department install boundaries that respect a real context limit. Agent charters that give a department an exclusive write scope when delegated. And a documentation layer that's been made navigable for a second audience without rewriting the source.

If you've got a flat prompt folder that's gotten out of hand, the install is cheap and reversible — you add a marketplace, install one department, and see whether the matching actually fires on your questions. If you read Chinese, start with the Chinese page; the orientation section is the fastest route to a working setup. If you don't, the original README and docs/GETTING-STARTED.md cover the same ground.

One thing to watch: the Chinese repo is a translation, so it tracks upstream with a lag. The translation date is 2026-10-14. If the original adds departments after that, the Chinese page won't have them until someone updates it.

Chinese documentation: https://github.com/yangshun2005/headcount-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

harnessrouter: a Chinese translation of the agent harness router, and why the docs matter more than the codeaiopensourceagentsllm

sun young — Wed, 14 Oct 2026 10:55:40 +0000

The original HarnessRouter/harnessrouter repo has 2993 stars and a README written in English. The Chinese version, yangshun2005/harnessrouter-cn, was published today with zero stars. That asymmetry is the whole point of this article.

If you have ever tried to evaluate an agent infrastructure project from a non-English-speaking region, you know the failure mode: you skim the README, you understand maybe 70% of it, you miss the sentence that says "do not add --user", and you spend an afternoon debugging something that was documented in plain sight. Translation is not glamorous work. It is, however, the difference between a project being adoptable and being a curiosity.

What HarnessRouter actually is

Strip away the positioning language and here is the mechanism: HarnessRouter is an infrastructure layer that turns existing agent harnesses — Codex, Claude Code, Hermes, PI, DSH, and others — into pluggable backends behind a single API.

The problem it addresses is real. If you are building an agent product, you probably do not want to write separate integration code for every harness you might want to support. You want to run a task, get a result, and swap the underlying harness when cost or latency demands it. HarnessRouter implements the Unified Harness Protocol (UHP), an open standard, and exposes an OpenAI Responses-compatible API on top. It handles persistent sessions, streaming progress, files, artifacts, cancellation, and structured failure reporting.

The official one-liner describes it as the self-hosted, Apache-2.0 edition of a unified interface for agent harnesses. Your keys, your infrastructure.

That last part matters. There is no bundled model and no trial key. You bring a provider API key. The community edition runs on your own hardware.

The Chinese version: what it adds

The harnessrouter-cn repo is a translation of the original project documentation. The README itself states the translation date as 2026-10-14 and links to README_en.md as the source. It carries the same license, Apache-2.0, and the original project's star count is listed as 2993.

The structure is worth noting because it is not a pure translation. The repo splits its content into two distinct layers:

A Chinese quick-start guide at the top, explicitly labeled as supplementary material and not part of the original documentation. Its stated purpose is to let you get the project running without reading the full README.
The translated README body below, which aims to stay faithful to the original text.

That separation is a small design decision with outsized consequences. Machine-translated technical documentation tends to blur the line between "what the original says" and "what a translator inferred." By marking the quick-start as non-original, the repo makes it possible to trust the translated body as a reference while still using the quick-start as a shortcut. If the translation is wrong somewhere, you can file an issue or a PR — the repo says so explicitly.

Getting it running

The quick-start path in the Chinese repo is short. You need Docker, roughly 4 GB of disk space, and a provider API key.

Start the container:

docker run -d --name harnessrouter \
  -p 127.0.0.1:3000:3000 \
  -v harnessrouter:/data \
  harnessrouter/harnessrouter

Then watch the logs, because first boot installs the enabled harness CLIs:

docker logs -f harnessrouter

Wait for this line:

[harnessrouter] ready on :3000

At that point you can stop following the logs with Ctrl+C. The container keeps running.

Open http://localhost:3000 and log in with the default credentials: username harnessrouter, password harnessrouter.

Then go to Bring Your Own Key in the sidebar, click Add Integration, pick a provider, give it a name, and paste the API key. Models supported by that provider become available in the console.

That is the whole onboarding flow. No account creation, no hosted dependency.

The gotchas the Chinese docs call out

This is where the translation earns its keep. The Chinese quick-start has a section on common pitfalls, and the items in it are exactly the kind of thing that gets lost when you are reading a second language at speed.

You must supply your own provider API key. No HarnessRouter account, no bundled model, no trial key. If you arrive expecting a free tier, you will be confused for a while.

First boot is slow. It installs harness CLIs. If the console is not responding or a harness seems to be missing, check the logs for backends available: and for warnings about backends that were requested but not installed.

Do not add --user. The entrypoint and Runner need root to manage per-session users. This is a security-model decision, not an oversight, and getting it wrong produces confusing permission failures.

Change the default password. Log in, go to Profile, change it. Until you do, keep the instance bound to localhost. Saving the change briefly restarts the console and logs out other browser sessions.

None of these are exotic. All of them are the kind of detail that costs you an hour if you skim past it in a language you are not fully comfortable in.

A note on what the Chinese docs do not cover

The Chinese repo is honest about its gaps. The environment requirements section says the original does not specify an operating system — only the Docker path is given. Version requirements are likewise unstated. On the question of network conditions in mainland China, the translation notes that the original says nothing about mirror sources or download acceleration, and suggests that users may want to consider switching Docker registry mirrors on their own.

I would rather see a documentation project say "the original does not cover this" than invent an answer. The former is useful. The latter is a trap.

Why translated documentation is infrastructure

There is a tendency to treat a translation repo as a nice-to-have. The code is the code, after all. But for a self-hosted project with a security model that involves running agent processes as per-session users, the documentation is part of the deployment surface. Misunderstanding it has consequences.

The Chinese version lowers the barrier for Chinese-speaking developers in a concrete way: it gives them a quick-start path that skips the full README, a faithful translation of the reference material, and an explicit list of the mistakes that are easy to make. The original project has 2993 stars and a Python codebase under Apache-2.0. The translation repo has zero stars as of today, which is expected — it was published today.

If you work in Chinese and have been meaning to evaluate HarnessRouter, the translated repo is the faster entry point. If you find a translation error, the repo asks for an issue or PR, which is the correct way for a documentation fork to improve.

The original is at HarnessRouter/harnessrouter. The Chinese version is at yangshun2005/harnessrouter-cn.

Chinese documentation: https://github.com/yangshun2005/harnessrouter-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

genoffice: a Chinese translation of the open-source AI Office suite

sun young — Wed, 14 Oct 2026 10:53:49 +0000

The original genspark-ai/genoffice repository has 9580 stars, is written in TypeScript, and ships under Apache-2.0. The Chinese version, yangshun2005/genoffice-cn, was published today. It has zero stars, which is normal for a repository that is a few hours old, and I'm not going to pretend otherwise.

What it is: a translated documentation fork. The code is the upstream code. What changed is the README — and, more usefully, a short "中文快速上手" section prepended to it that the original does not have.

Why a translated README is not a trivial thing

For an English-speaking developer, the genoffice README is a normal README. You skim the feature list, find the Releases link, download the right installer, and you're running in five minutes.

For a Chinese-speaking developer, the same document has a specific failure mode that isn't about vocabulary. It's about where the operational details sit. The upstream README is organized as a product page: positioning first, feature bullets second, install links somewhere in the middle, and the CLI/MCP/agent-skill material further down. If you're evaluating whether this thing can do a job for you, you read top to bottom and hope the answer is in there.

The Chinese version inverts that. The top of the page is a short section labeled as a supplement, explicitly marked as not part of the original text, and it answers the questions you'd otherwise have to reconstruct:

What is this, and what problem does it solve
The shortest path to a running app
Environment requirements
Known gotchas

That's the actual value. Not "the README is now in Chinese." It's that someone read the whole thing, figured out which parts a new user needs first, and put those parts at the top.

What genoffice actually does

The core claim, from the README: it opens and saves native .docx, .xlsx, and .pptx files, edits PDF, Markdown, and HTML, and puts an AI agent next to each document. Not a chat sidebar — an editor that reads the file, makes changes, and shows you what changed.

The detail that matters most is byte-level preservation. Only the parts you edited get rewritten. Everything else in the file is kept byte for byte, so the document still opens correctly in Word, Excel, and PowerPoint. This is the difference between "an AI tool that exports to Office format" and "an AI tool that edits your Office files." Most tools in this space do the former and call it the latter.

The other structural choices:

Edits are reviewable. Changes appear as tracked changes and diffs, with one-click rollback. Spreadsheets use live formulas rather than pasted values. Slides and pages are generated on a canvas and stay fully editable.

Local-first. Opening, editing, saving, and converting happen on your machine. PDF → Word / Excel / PowerPoint, Markdown → Word, and HTML → Word all run locally. Only AI calls leave the machine, and they go to whichever provider you picked.

Search by content. The home screen runs a local SQLite index over .docx, .xlsx, .pptx, PDF, Markdown, and HTML files — names, folders, and full text, with CJK support. Optionally, top results get reranked by TypeSafe Jev (System One judgment model) so the file that answers your question sorts first.

Ask AI across documents. Bookmark a set of documents and the home screen's Ask AI answers questions across them, citing the source file for each claim so you can open it and check.

Bring your own key, or don't. Log in with Genspark to skip keys entirely, or supply your own from Claude, OpenAI, Gemini, DeepSeek, Kimi, GLM, Qwen, Doubao, MiniMax, Grok, Mistral, OpenRouter, Requesty, Opper, Cheaper Inference, Atlas Cloud, any OpenAI-compatible endpoint, or a local server.

Scriptable. The app ships a genoffice CLI plus skills for Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode, and Windsurf, so a coding agent can create, convert, read, and edit real Office files on your machine without opening a window.

Platforms: macOS (Apple Silicon and Intel), Windows (x64 and Arm), Linux (deb, rpm, AppImage).

Getting it running

The Chinese quick-start gives a four-step path:

Go to the Releases page and pick your platform build.
Install and launch. (The original README doesn't spell out install steps, and the translation says so rather than inventing them.)
Open or create a document, type your edit request into the AI panel.
For building from source, the translation again notes that the original doesn't provide a clear build/start command — it points you at the README body and notes that only package.json scripts are available in the material.

That last point is worth pausing on. A translation that quietly papered over gaps would be worse than no translation. This one flags them: "原文未提供明确的构建/启动命令" — the original doesn't provide a clear build command. You know exactly where the documentation ends and your own work begins.

Environment requirements

From package.json's engines field, for source builds only:

Node.js >=22.12.0
npm >=10
Project version 0.1.0

Hardware requirements aren't specified in the source material. Neither are mirror sources or download accelerators for users in mainland China — the translation explicitly says the original doesn't mention them.

The gotchas section

This is the part I'd point a colleague to first.

AI features need a key or a login. Either sign in with Genspark to skip keys, or bring your own from Claude, OpenAI, Gemini, or any OpenAI-compatible endpoint including a local server. Only AI calls leave your machine.

Local-first has a boundary. File open, edit, save, and all the conversions run locally. AI requests go to the provider you chose. If that distinction matters to your threat model, it's stated plainly rather than buried.

Source builds have version floors. Node >=22.12.0 and npm >=10, and postinstall runs install-electron. Miss the version floor and you'll get a confusing failure rather than a clear one.

The translation also says it found no other obvious pitfalls in the source material, rather than padding the list.

On the translation itself

The repository is explicit about its own structure: the README body is a translation of the original documentation, and the quick-start at the top is a Chinese-language supplement that is not part of the original. It invites issues and PRs for inaccuracies.

That separation is the right call. It means you can trust the body as a faithful rendering of upstream, and you can treat the top section as editorial — someone's judgment about what a new user needs, which may or may not match your situation.

Who this is for

If you read English comfortably, use the upstream repo. The Chinese version adds nothing you can't get there, and the upstream will always be the source of truth for releases and issues.

If you're working primarily in Chinese, or you're evaluating genoffice for a team where the README will be read in Chinese, the translated version saves you a pass through the whole document to find the four things you actually needed. That's a small win, but it's a real one, and it's the kind of work that doesn't get done often enough.

The upstream project is at 9580 stars and is the thing being translated. The Chinese fork is at zero and was published today. Judge it on whether the quick-start answers your questions, not on a star count.

Repository: https://github.com/yangshun2005/genoffice-cn
Upstream: https://github.com/genspark-ai/genoffice

Chinese documentation: https://github.com/yangshun2005/genoffice-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

harnessrouter: a Chinese translation of the agent harness router, and why the docs matter more than the code

sun young — Wed, 14 Oct 2026 10:52:08 +0000

What HarnessRouter actually is

The official one-liner describes it as the self-hosted, Apache-2.0 edition of a unified interface for agent harnesses. Your keys, your infrastructure.

That last part matters. There is no bundled model and no trial key. You bring a provider API key. The community edition runs on your own hardware.

The Chinese version: what it adds

The structure is worth noting because it is not a pure translation. The repo splits its content into two distinct layers:

A Chinese quick-start guide at the top, explicitly labeled as supplementary material and not part of the original documentation. Its stated purpose is to let you get the project running without reading the full README.
The translated README body below, which aims to stay faithful to the original text.

Getting it running

The quick-start path in the Chinese repo is short. You need Docker, roughly 4 GB of disk space, and a provider API key.

Start the container:

docker run -d --name harnessrouter \
  -p 127.0.0.1:3000:3000 \
  -v harnessrouter:/data \
  harnessrouter/harnessrouter

Then watch the logs, because first boot installs the enabled harness CLIs:

docker logs -f harnessrouter

Wait for this line:

[harnessrouter] ready on :3000

At that point you can stop following the logs with Ctrl+C. The container keeps running.

Open http://localhost:3000 and log in with the default credentials: username harnessrouter, password harnessrouter.

Then go to Bring Your Own Key in the sidebar, click Add Integration, pick a provider, give it a name, and paste the API key. Models supported by that provider become available in the console.

That is the whole onboarding flow. No account creation, no hosted dependency.

The gotchas the Chinese docs call out

You must supply your own provider API key. No HarnessRouter account, no bundled model, no trial key. If you arrive expecting a free tier, you will be confused for a while.

None of these are exotic. All of them are the kind of detail that costs you an hour if you skim past it in a language you are not fully comfortable in.

A note on what the Chinese docs do not cover

I would rather see a documentation project say "the original does not cover this" than invent an answer. The former is useful. The latter is a trap.

Why translated documentation is infrastructure

The original is at HarnessRouter/harnessrouter. The Chinese version is at yangshun2005/harnessrouter-cn.

Chinese documentation: https://github.com/yangshun2005/harnessrouter-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

OpenMausBot: a Chinese translation of the local-first AI agent chat app

sun young — Wed, 14 Oct 2026 10:51:20 +0000

OpenMausBot is a desktop chat app where every contact in the sidebar is a running agent. The original repository, milind-soni/OpenMausBot, sits at 4770 stars and is written in TypeScript under Apache-2.0. A Chinese translation of its documentation was published on 2026-10-14 at https://github.com/yangshun2005/OpenMausBot-cn.

That translation is what this post is about, plus what the project actually does and where it will bite you.

What the project is

The official one-liner is: "Open-source Grok Bot alternative with a virtual machine that bots can use."

The longer version, from the README: OpenMausBot is a local-first desktop chat application that turns a team of AI agents into something shaped like an instant messenger. Each bot in the sidebar is a real agent running Claude or Codex underneath, with its own personality, its own model, its own cloud computer, and its own connected apps. You talk to them like contacts. You watch them work. You approve the operations that matter.

The stated problem is that a single assistant in a single chat box does not fit agent workflows. OpenMausBot rebuilds the "AI as a messaging app" idea as an open-source, local-first project that runs on the agent CLIs you already have installed.

It describes itself as an open-source alternative to Grok Bot, and also to Meta Muse, OpenAI dots, and Cue by Manus. It is not affiliated with xAI, Meta, OpenAI, or Manus. It has also been called MausBot, and was previously named OpenGrokBot.

One thing the README states plainly, in a warning block: there is no token. Any coin using the OpenMausBot, Maus, or SupaMaus names was not created, endorsed, or associated with the project or its maintainers.

Why a Chinese translation matters here

The README is long. It covers install paths for three operating systems, Docker build targets, engine selection, host control permissions, and a pile of platform caveats. If English is not your first language, that is a lot of surface area to misread before you even get the app open.

The Chinese version splits the document into two parts, and the split is the useful idea:

A 中文快速上手 section at the top, explicitly labeled as a supplement and not part of the original text. Its stated goal is to let you get the project running without reading the whole README.
The translated README body below it, which aims to stay faithful to the original.

That ordering matters. You get the short path first, the reference material second. The translation also carries the original's warnings forward rather than dropping them, which is where a lot of translated docs go wrong — the caveats are usually the first thing to get trimmed.

The translator states that inaccuracies should be filed as an Issue or PR. My read is that the quick-start section is the part most likely to drift, since it is original content rather than a translation and will need updating whenever the upstream README changes. That is a guess on my part, not something the repo says.

Getting it running

The shortest path is a prebuilt installer. The README's download section lists:

Mac, Apple silicon: OpenMausBot.dmg
Mac, Intel: OpenMausBot-intel.dmg
Windows: OpenMausBot-setup.exe
Ubuntu 24.04 x64: OpenMausBot-amd64.deb, or an AppImage beta

All releases are on the latest release page. The macOS builds are described as signed and notarized .dmg files.

If you want to build the harness server with Docker, the Dockerfile comments give these commands:

docker build -t openmausbot .

# pick your engines explicitly
docker build --build-arg ENGINES="@anthropic-ai/claude-code @openai/codex" -t openmausbot .

# build the cloud-home target
docker build --target cloud-home -t omb-cloud-home .

The Docker image is based on node:24-bookworm-slim.

For a source build, package.json specifies pnpm@10.33.0 and Node >=24. Be aware: the README material does not include a complete source build and run sequence. The Chinese quick-start says to consult the README body for that, which is honest but means you should not expect a copy-pasteable pnpm install && pnpm dev from the translation alone.

Requirements and the things that will stop you

The dependency situation is the part worth reading twice.

Bots run on CLIs you already have. OpenMausBot drives claude, codex, and grok installed on your own machine, using your existing logins and subscriptions. No new account. But this cuts both ways: if those CLIs are not installed and authenticated, the bots do not run. There is no bundled fallback described.

Platforms. macOS on both Apple silicon and Intel, Windows x64, and Ubuntu 24.04 x64. The badges note Electron support for macOS, Windows, and Ubuntu.

Host control is limited. Host control works only on macOS and Ubuntu Xorg, and only after you explicitly opt in. On Ubuntu Wayland it is disabled because of unresolved issue #345. If you are on Wayland and host control is the feature you came for, this is a blocker, not an inconvenience.

State lives in ~/.openmausbot. Transcripts, keys, and events go there. In Docker, HOME is the /data volume, which is what persists state across container restarts. Back that up if you care about your transcripts.

Hardware requirements are not specified. The README distinguishes Apple silicon from Intel installers and stops there. No RAM or disk figures. I would not read anything into that either way.

No mirror guidance. The material does not mention domestic npm mirrors or download accelerators. If you are behind a slow connection to npm or GitHub, that is on you to solve. The translation does not pretend otherwise.

Where the translation helps most

The quick-start section compresses the decision tree into a few lines: pick your OS, grab the installer, or build the harness with one of three Docker commands. It also front-loads the gotchas that would otherwise surface after twenty minutes of setup — the CLI dependency, the Wayland host-control gap, the state directory, the no-token warning.

For a Chinese-speaking developer evaluating whether this is worth an afternoon, that is the right shape. You can decide in two minutes whether the constraints disqualify you, then read the translated README for depth if they do not.

The honest caveats: the translation is new, published 2026-10-14, and the Chinese repository has no stars yet. It is a translation, not a fork with code changes, so the 4770 stars belong to the original project and say nothing about the translation's quality. If you find something wrong, the repo asks for an Issue or PR, and given how fresh it is, that is probably the fastest way to get it fixed.

Should you look at it

If you already run claude or codex locally and the idea of several persistent agents with separate personalities and separate cloud machines appeals to you more than one chat window, the project is aimed squarely at you. The local-first framing and the "use your existing subscription" model are the two design choices that make it worth a look rather than a dismissal.

If you are on Ubuntu Wayland, or you do not have those CLIs installed and do not want them, the constraints above are real and the Chinese quick-start says so up front.

Original project: https://github.com/milind-soni/OpenMausBot
Chinese documentation: https://github.com/yangshun2005/OpenMausBot-cn

Chinese documentation: https://github.com/yangshun2005/OpenMausBot-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

genoffice: a Chinese translation of the open-source AI Office suite

sun young — Wed, 14 Oct 2026 10:50:42 +0000

Why a translated README is not a trivial thing

For an English-speaking developer, the genoffice README is a normal README. You skim the feature list, find the Releases link, download the right installer, and you're running in five minutes.

What is this, and what problem does it solve
The shortest path to a running app
Environment requirements
Known gotchas

That's the actual value. Not "the README is now in Chinese." It's that someone read the whole thing, figured out which parts a new user needs first, and put those parts at the top.

What genoffice actually does

The other structural choices:

Ask AI across documents. Bookmark a set of documents and the home screen's Ask AI answers questions across them, citing the source file for each claim so you can open it and check.

Platforms: macOS (Apple Silicon and Intel), Windows (x64 and Arm), Linux (deb, rpm, AppImage).

Getting it running

The Chinese quick-start gives a four-step path:

Go to the Releases page and pick your platform build.
Install and launch. (The original README doesn't spell out install steps, and the translation says so rather than inventing them.)
Open or create a document, type your edit request into the AI panel.
For building from source, the translation again notes that the original doesn't provide a clear build/start command — it points you at the README body and notes that only package.json scripts are available in the material.

Environment requirements

From package.json's engines field, for source builds only:

Node.js >=22.12.0
npm >=10
Project version 0.1.0

The gotchas section

This is the part I'd point a colleague to first.

Source builds have version floors. Node >=22.12.0 and npm >=10, and postinstall runs install-electron. Miss the version floor and you'll get a confusing failure rather than a clear one.

The translation also says it found no other obvious pitfalls in the source material, rather than padding the list.

On the translation itself

Who this is for

If you read English comfortably, use the upstream repo. The Chinese version adds nothing you can't get there, and the upstream will always be the source of truth for releases and issues.

Repository: https://github.com/yangshun2005/genoffice-cn
Upstream: https://github.com/genspark-ai/genoffice

Chinese documentation: https://github.com/yangshun2005/genoffice-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

rakazo: a self-hosted AI agent, now with a Chinese README

sun young — Wed, 14 Oct 2026 10:49:25 +0000

The upstream repo elie222/rakazo has 3869 stars and is written in TypeScript. Its own one-line description is "Open-source Grok Bot alternative. Choose your own model and sandbox." What it does not have is a Chinese README. Someone fixed that: yangshun2005/rakazo-cn is a translation of the original documentation, published 2026-10-14.

This article is about what rakazo actually is, how the translated docs are structured, and where the Chinese version helps versus where it just mirrors the English.

What rakazo is

Rakazo is an open-source AI agent positioned as a persistent AI teammate — a self-hosted assistant that runs on your own machine. It ships clients for web, Electron desktop, iPhone, and Android. You can bring your own model and computer provider, or run the entire stack locally.

The comparison set the upstream README names is specific: Grok Bot, Meta Muse, OpenAI Dots, Instinct, OpenClaw, Hermes Agent, and Hark Pro. Rakazo is pitched as the open-source, self-hostable alternative to that group. Some of those are hosted assistants (Muse, Dots, Instinct, Hark Pro); some are open-source agents you run yourself (OpenClaw, Hermes Agent). The distinction the README draws is that rakazo, once running, is just a chat — you set up a bot and manage it through that chat.

The project is in beta. The README says so explicitly, and that matters for anyone deciding whether to put it in front of real work.

License is Apache-2.0.

Why a translation is not just cosmetic

Self-hosted software has a documentation problem that hosted software does not. With a hosted product, a bad README costs you a signup. With self-hosted software, a bad README costs you an evening of debugging environment variables, and the failure modes are silent — a container that starts but cannot reach a model, a .env where two values must match and one of them doesn't.

The rakazo README is long. It covers install paths, provider configuration, secrets, and a self-host guide. For a Chinese-speaking developer evaluating the project, that is a lot of English prose to parse before you know whether the thing even fits your use case. The translated repo splits the problem in two:

A 中文快速上手 section at the top, marked as supplementary and not part of the original text. Its stated purpose is to let you get the project running without reading the whole README.
The translated README body below it, which aims to stay faithful to the original.

That separation is the right call. Mixing editorial guidance into a translation makes it impossible to tell what upstream actually said. Keeping them apart means you can trust the lower half as a translation and treat the upper half as a getting-started guide.

The shortest install path

The translated quick-start gives the published-image route, which needs no clone and no Node install. Prerequisites are Docker Engine, the Compose plugin, curl, and OpenSSL.

mkdir -p rakazo && cd rakazo &&
curl -fsSLO https://raw.githubusercontent.com/elie222/rakazo/main/infra/compose/install-images.sh &&
bash install-images.sh

The script downloads the Compose files, generates a .env with random secrets, and starts rakazo. Rerunning it preserves an existing .env, which is the behavior you want — you don't lose your keys on a second run.

Then open http://127.0.0.1:5173, create an account, and connect a model.

For a server deployment, the flow is three steps instead of one: run bash install-images.sh --prepare-only, edit .env to set SANDBOX_PROVIDER and RAKAZO_HOST, then run bash install-images.sh again.

The default image tag is edge, built from main. Published images cover linux/amd64 and linux/arm64.

Requirements, and the Node version trap

If you go the published-image route, the dependency list is short: Docker Engine, Compose plugin, curl, OpenSSL. The README does not specify an OS or hardware requirement.

If you build from source, the Node constraint is worth reading twice. Supported: Node.js 22.22.2 or higher within the 22.x line, Node.js 24.x, or Node.js 26 and above. Not supported: Node.js 23.x and 25.x. Package manager is pnpm 9, plus Docker.

That odd-numbered-release exclusion is the kind of detail that costs an hour if you skim. It is also exactly the kind of detail that a translated quick-start section can surface prominently, because the translator is reading the doc as a user, not as the author.

Secrets you will have to set by hand

The published-image path generates secrets for you. Source development does not. The README lists what you must configure:

POSTGRES_PASSWORD, which also has to be reflected in DATABASE_URL
BETTER_AUTH_SECRET
ENCRYPTION_KEY
SCREEN_PROXY_SECRET
SANDBOX_SUPERVISOR_TOKEN, needed for the Docker sandbox

The POSTGRES_PASSWORD / DATABASE_URL pairing is the classic failure: set one, forget the other, get an auth error that doesn't name the real cause.

Model credentials and remote providers

Rakazo needs a model. You can set OPENROUTER_API_KEY, or connect a supported model provider during onboarding.

Voice mode needs its own keys — the README names ElevenLabs, OpenAI, Cartesia, and Fish Audio as options.

The local Docker computer is enabled by default. If you want a remote provider instead, the options are e2b, daytona, createos, or box, each requiring its own API key.

The restricted-network section

This is where the translation earns its keep for a specific audience. The README documents overrides for constrained networks:

RAKAZO_DOWNLOAD_BASE to change the base URL the install script downloads from
--local or RAKAZO_DOWNLOAD_SKIP_EXISTING to skip Compose files you already have
Overriding the bootstrap script URL

The details live in the self-host documentation under "Restricted networks / mirror downloads." If you have ever tried to pull a GitHub raw file from a network that rate-limits or blocks it, you know why this section exists. Having it in Chinese, with the environment variable names left in English so you can copy-paste them, is the correct handling.

What the translation does not do

It does not change the software. Same repo, same images, same env var names. The Chinese version is documentation only.

It also does not claim adoption. The translated repo is new — published 2026-10-14 — and has no stars to speak of. The 3869 figure belongs to the upstream project, and the translated README lists it that way, under "原项目 Stars." If you see the number quoted elsewhere as if it described the translation, that's a misread.

The translation also flags its own limits. The header states that the quick-start is supplementary and not original content, and invites issues or PRs for inaccuracies. That's a reasonable posture for a translation of a beta project's docs — upstream will change, and the translation will lag.

Should you use it

If you read English comfortably, go to the upstream README. It is the source of truth and it will be current.

If you are evaluating rakazo and English documentation is the friction point, the Chinese version gives you two things the original does not: a condensed path to a running instance, and a translated reference you can search in your own language when something breaks. The env var names stay in English, which is right — those are the strings you actually type.

The project is beta. The translated docs say so. Treat both accordingly.

Repo: https://github.com/yangshun2005/rakazo-cn
Upstream: https://github.com/elie222/rakazo

Chinese documentation: https://github.com/yangshun2005/rakazo-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

KiroCrew: an agent workspace that survives the restart

sun young — Wed, 14 Oct 2026 10:48:50 +0000

KiroCrew: A Persistent Agent Workspace, Now Documented in Chinese

Most agent sessions die when you close the chat window. That is the problem KiroCrew is built around. It is an open-source development workspace that runs on hardware you control — local or remote — and it keeps sessions, memory, scheduling, and task checkpoints alive across Gateway restarts. The upstream project, kirodotdev/KiroCrew, sits at 4400 stars, is written in Python, and ships under Apache-2.0.

A Chinese translation of that project now exists: KiroCrew-cn. This article is about what the project does, how to get it running, and what the Chinese edition actually adds.

What KiroCrew is

The official one-liner: a persistent workspace for development work that self-improves and continues beyond one session.

That sentence is doing a lot of work, so let me unpack it against what the README actually claims.

Persistent. Sessions, memory, scheduling, and task checkpoints survive a Gateway restart. Scheduled jobs and unattended multi-step tasks keep running.
Multi-surface. You interact through a desktop app, a web dashboard, and a CLI. Slack and Discord are message channels for continuing the same work.
Unattended by design. Multi-step tasks can run without you watching. Periodic jobs fire on your schedule. A heartbeat mechanism monitors the system until something needs attention.
Extensible through Apps. Kiro Crew Apps tailor the experience to specific work scenarios by combining dedicated interfaces with agents, skills, schedules, integrations, and backend services.

The default agent runs on top of kiro-cli. That is a separate dependency you install and log into yourself. On first startup KiroCrew checks for it, and if it is missing, links you to the official install guide.

Why a Chinese edition matters

The upstream README is long. It has a quick start, a source-build path, a rationale section, a feature list, an architecture explanation, a security section, install notes, telemetry documentation, and a docs index. For a developer whose first language is Chinese, that is a real reading cost before the first command even runs.

The Chinese edition does two things, and the distinction is stated explicitly in the repo:

A translated README. The body is a Chinese translation of the original project documentation, with a stated goal of staying faithful to the source. The original English README is kept alongside it as README_en.md.
A supplementary quick-start guide (中文快速上手). This part is not a translation. It is an added orientation layer written for Chinese-speaking users, with the explicit purpose of letting you get the project running without reading the whole README first.

That second part is the more interesting one. Translation alone does not lower the barrier much if the original document is structured around assumptions you do not share. A quick-start that front-loads "what problem does this solve," "what is the shortest path to a running instance," and "what will bite you" is a different artifact from a translated reference.

The repo also invites corrections: if something is translated inaccurately, open an Issue or a PR.

The shortest path to a running instance

If you want to skip the source build, the README gives a one-line install for the signed Stable wheel. No repo clone, no frontend build:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

Then open http://localhost:5476.

To pin an exact release, pass --version:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.6.0

One constraint worth knowing before you try to pin something old: the minimum pinnable version is 0.1.2. Versions 0.1.0 and 0.1.1 predate manifest signing, so there is no signed manifest to resolve against.

Before any of this, install and log into kiro-cli. The README does not provide an explicit command for that step in the quick-start section — it defers to the install guide. This is the single most common first-run failure, because the prerequisite check happens at startup and the default agent will not run without it.

Building from source

The README's source path is short but has one non-obvious step:

git clone <repo>
cd KiroCrew
make build
source .venv/bin/activate
kirocrew setup
kirocrew doctor
kirocrew gateway

The non-obvious part is the frontend. It is built separately with npm/Vite inside the website/ directory, and the output has to be staged into src/kiro_crew/static/dist before packaging. If you build the Python side and wonder why the web dashboard is blank, that is usually why.

kirocrew doctor after setup is worth running rather than skipping. It is the cheap way to find out that kiro-cli is missing or unauthenticated before you spend time debugging a gateway that starts but does nothing useful.

Environment requirements

From the README:

OS: macOS, Linux, and Windows. Windows goes through a native source install — there is a separate Windows guide.
Python: 3.12+. pyproject.toml declares requires-python = ">=3.12", and CPython 3.12–3.13 are supported.
Node.js: 22.12+ for source builds, with 24 LTS recommended, plus npm.
Default agent dependency: kiro-cli, installed on the Gateway host, with kiro-cli login run once.
Architectures: macOS on x86_64 and arm64; Linux on x86_64 and aarch64.
Docker: a public multi-arch image at ghcr.io/kirodotdev/kirocrew:stable.

For users on mainland China networks, the README notes that mirror sources or download acceleration may be needed. It does not provide specific mirror configuration — that is deferred to the install guide.

Install paths beyond the one-liner

The one-line script is not the only option. The README lists:

Desktop app with auto-update, for macOS (.dmg) and Windows x64 (-Setup.exe). Linux users are pointed at the one-line install as the starting point.
Linux packages — .deb, .rpm, and AppImage — covered in the install guide alongside Insider and Nightly links, architecture support, platform requirements, and sandbox setup.
Docker for always-on servers.
Source build, as above.

There are three release channels. Stable is the default. Insider follows release candidates. Nightly follows main. The release runbook documents the current triggers, version shapes, promotion behavior, cadence, and update-channel semantics.

A gotcha in the installer

The install script only uses precompiled wheels by default. If a dependency has no precompiled wheel available, the script refuses to build it rather than falling back to a source compile. To allow source builds you have to opt in:

KIROCREW_ALLOW_SOURCE_BUILDS=1

That requires a C toolchain and the relevant -dev headers. On a minimal container image, this is the difference between a clean install and a wall of build errors, so it is worth knowing before you hit it.

What the Chinese edition does not do

It does not fork the code. It does not change behavior. It is a documentation layer, and the repo is explicit about which parts are translation and which parts are added orientation. The upstream project is at 4400 stars; the Chinese edition is new and has no star history to speak of yet, so treat it as a translation in progress rather than a community with a track record.

If you are a Chinese-speaking developer who bounced off the upstream README, the value here is concrete: a quick-start that tells you about the kiro-cli prerequisite, the frontend staging step, the 0.1.2 pinning floor, and the KIROCREW_ALLOW_SOURCE_BUILDS flag before you discover them the hard way. That is a few minutes saved per person, multiplied across everyone who tries the project.

If you find a translation error, the repo asks for an Issue or a PR. That is the whole maintenance model.

Chinese documentation: https://github.com/yangshun2005/KiroCrew-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

OpenBot: A Chinese Translation of the Open-Source AI Coworker Template

sun young — Wed, 14 Oct 2026 10:48:15 +0000

What OpenBot is

OpenBot is an open-source platform for running AI assistants on infrastructure you control. The official one-line description is:

Open-source AI coworkers that each get a computer of their own: a browser, files and tools, with every action decided before it happens and recorded after. Bring any AG-UI agent.

The shape is familiar — think ChatGPT, Claude, or Grok — but the deployment model is not. Every component runs inside your own environment, and every part of it can be modified. Agents connect through the AG-UI protocol, so you can bring an agent built on a framework or one you wrote by hand.

Each bot gets its own computer: a real browser with separate login credentials and separate files, limited to the tools you grant it. Actions pass through a gateway decision before execution and are recorded afterward.

The original project is CopilotKit/OpenBot:

Stars: 6438
Primary language: TypeScript
License: MIT
Topics: ag-ui, agent-governance, ai-agents, browser-automation, copilotkit

What the Chinese version adds

The Chinese translation lives at yangshun2005/OpenBot-cn. It was translated on 2026-10-14 and is a fresh repository, so it has no stars of its own yet — the 6438 figure above belongs to the original project only.

The value here is straightforward: the original README is long, and a large part of it is operational detail — environment variables, setup scripts, self-hosting caveats. For Chinese-speaking developers, reading that in a second language adds friction before you have written a single line of code. The translated repository addresses that in two ways.

The translated README body

The main body is a faithful Chinese translation of the original documentation. It covers the same material: the architecture, the AG-UI integration, the per-bot computer model, the gateway decision flow, and the sign-in configuration. Where the original says something, the translation says the same thing.

A separate quick-start guide

On top of the translation, the repository adds a section labeled 「中文快速上手」 (Chinese quick start). This is explicitly marked as supplementary material, not part of the original documentation. Its stated purpose is to let you get the project running without reading the entire README first.

That distinction matters. Translated documentation and an onboarding guide are different artifacts with different failure modes. Mixing them without labeling is how translation projects become unreliable. This one keeps them separate.

The quick-start section covers four things the original spreads across a longer document:

What problem it solves. OpenBot is for the case where you want an AI assistant but your data and tools must stay in your own environment. The translation is explicit that this is a template, not a product — there is no hosted version, and you clone the repository and modify it.
The shortest path to running it. Dependency installation, connecting a hosted Intelligence project, filling in required values, and starting the stack.
Environment requirements. Operating system, dependencies, and version constraints.
Common pitfalls. The things that break a first run.

Getting it running

The quick-start path in the translated repository is short. First, create your environment file and install dependencies:

cp .env.example .env
bun install

Then connect a hosted Intelligence project:

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
bun scripts/setup-learning.ts

Fill in the remaining required values. The proof-of-concept bot uses OpenAI, so you need OPENAI_API_KEY. If you are self-hosting Intelligence, there is additional configuration. To generate a custom encryption key:

openssl rand -base64 32

Then start the stack:

bash scripts/start.sh

To stop it, use scripts/stop.sh. Adding --keep-computers preserves the bots' computers.

Environment requirements

The requirements are worth reading before you clone, because a few of them are non-obvious.

Operating system. The README is written for laptops. The preview version that runs Intelligence locally targets macOS with Docker Desktop.
Hardware. The source material does not specify hardware requirements. Minimum deployment specifications are referenced in docs/deployment.md, which the source material does not expand on.
Dependencies:
- Docker, for PostgreSQL and the bundled bots
- Bun 1.3+ for the application and API server. The packageManager field in package.json is bun@1.4.3.
- A CopilotKit Intelligence project and license. There is a free plan, and self-hosting is also possible.
- A model key. The proof-of-concept bot uses OpenAI; the LangGraph bot can use OpenAI, Anthropic, or Google.
Version constraints. Bun 1.3+. The Dockerfile pins Playwright at 1.62.1, which must stay consistent with agent-computer/package.json.

On network conditions in mainland China, the source material says nothing about mirrors or download acceleration. If that is your situation, treat it as an open question rather than something the documentation answers.

The pitfalls that actually matter

The translated quick-start calls out four issues. They are worth repeating because each one will cost you time if you miss it.

This is an Alpha-stage template, not a product

There is no hosted version to sign up for. Every workspace in the repository is private and none of it is published as a package you can depend on. You clone it and adapt it. The examples under examples/ are tenant packages you are expected to replace with your own coworkers, channels, and skills.

The original README states this plainly: everything described is a starting point, not a finished thing operated by someone else on your behalf.

Single-user mode is on by default

In .env.example, OPENBOT_SINGLE_USER=true treats every request as an administrator. A fresh clone is accessible without OAuth. That is convenient for local development and unacceptable the moment anyone else can reach the deployment.

The documentation is direct about this: sign-in must be configured before others can access the deployment. This is not a hardening step you do later.

You need external keys and a project

A CopilotKit Intelligence project and license are required, along with a model key such as OPENAI_API_KEY. If you self-host Intelligence, you must set INTELLIGENCE_GATEWAY_WS_URL manually, and a missing INTELLIGENCE_API_KEY will cause startup to fail.

Local Intelligence is a preview

Running Intelligence locally targets macOS with Docker Desktop only. The local license is valid for 30 days. It is not a production installation. Self-hosted setup also requires Chrome or Edge to be installed first.

Why a translation is worth maintaining

OpenBot's documentation is not short, and most of its length is operational. Setup scripts, environment variables, self-hosting caveats, version pins — this is the material where a misread line costs you an afternoon.

Translation projects tend to fail in one of two ways. Either the translation drifts from the source and nobody notices, or the translator adds interpretation without marking it, so readers cannot tell what the upstream project actually claims. The OpenBot-cn repository handles the second problem by construction: the translated README body is labeled as a translation, and the quick-start guide is labeled as supplementary. If a translation is inaccurate, the repository asks for an Issue or PR.

For a project at this stage — Alpha, actively developed, with rough edges and bugs expected — that structure is the right one. Upstream will change. A translation that makes its own additions visible can track those changes. One that blends them in cannot.

Who this is for

If you are a Chinese-speaking developer evaluating OpenBot, the translated repository removes the reading barrier before you commit to a clone. You can understand the architecture, the AG-UI integration model, and the per-bot computer design in your first language, then run the setup commands, which are identical to the original.

If you are not, the original repository is the place to start. The Chinese version is a translation of it, not a fork with different behavior.

Either way, the honest framing is the one the documentation itself uses: this is a template you clone and reshape, in Alpha, running on your own machine. The 6438 stars on the original are a signal that other people found the problem worth solving. Whether it fits yours is a question only you can answer, and the quickest way to answer it is to run the four commands above.

Chinese documentation: https://github.com/yangshun2005/OpenBot-cn

VoiceMem: a Chinese translation of the streaming dual-brain memory system for voice agents

sun young — Wed, 14 Oct 2026 09:53:23 +0000

VoiceMem's README is long. It covers a dual-brain architecture, a model family, a dataset, a fine-tuning pipeline and an evaluation harness. If you read English comfortably, that's a normal afternoon. If you don't, the install steps alone can eat an hour before you discover that the demo code isn't in the pip package.

That gap is what the Chinese version at yangshun2005/VoiceMem-cn addresses. It is a translation of xzf-thu/VoiceMem (2501 stars, Python, Apache-2.0), translated on 2026-10-14.

What the Chinese repo actually contains

Two layers, and the distinction matters.

The first is a translated README. The repo states plainly that the body is a Chinese translation of the original documentation, and that the goal is fidelity to the source. The original English README is kept alongside as README_en.md, so you can diff them if a sentence reads oddly.

The second layer is a supplement the maintainer added on top: a "中文快速上手" section marked explicitly as non-original content. Its purpose is narrow — get you from zero to a running demo without reading the full document. It covers what the project is, the shortest install path, environment requirements, and a list of common traps.

I find the labeling honest. Translation repos often blur the line between "this is what upstream says" and "this is my advice," and that blurring is exactly where people get burned. Here the boundary is stated in the first few lines.

The project in one paragraph

VoiceMem is a memory system for real-time voice agents. The architecture is described as a "streaming dual-brain" design: the left brain organizes factual memory using schemas and entities, the right brain manages personality, emotion and relationship information. The stated problem is that voice assistants forget what you told them and don't model who you are. The official one-liner calls it "infrastructure for the next generation of voice agents, designed to provide universal memory."

The left brain, per the README, maintains Mem0's saturated performance under a Top-3 constraint. The right brain handles long- and short-term emotion attribution, with cross nodes maintained jointly with left-brain information. Latency claims: 0–300 ms speculative prefetch on streaming queries, roughly 300 tokens per single-turn query. Every component, including the underlying memory engine, is described as replaceable.

Getting it running

The install path is short. The traps are not.

git clone https://github.com/xzf-thu/VoiceMem.git
cd VoiceMem

# memory system with ASR, speaker verification, scene, emotion, local embedding
pip install voicemem

# optional: the fine-tuned Qwen response model
pip install "voicemem[slm]"

Then the models:

pip install -U huggingface_hub
hf download zhifeixie/VoiceMem_Default_Models_Env --local-dir ./models

And the demo:

python web/run.py

Then http://localhost:8787.

Four things the Chinese guide flags that the English README leaves implicit or scattered:

The pip package is library-only. The demo lives in the repo. If you pip install voicemem and then look for web/run.py, it isn't there. You need the clone. This is the kind of thing that costs twenty minutes of confused find commands.

You need an OpenAI API key. The examples use VoiceMem(openai_key="api_xxx") or the OPENAI_API_KEY environment variable. Not a surprise once you see it, but it isn't in the headline install block.

Local models are lazy-loaded. The guide says to call vm.warmup() first so the initial invocation doesn't stall on model loading. Reasonable advice for anything with a first-call penalty, and easy to miss when you're benchmarking latency.

Missing dependencies degrade silently. The pyproject.toml comments note that without torchvision or accelerate, the emotion attributor falls back to pure acoustic quadrants — no error, just less accurate results. Silent degradation is the worst failure mode for a memory system, because you'll blame the model instead of the install.

On environment: requires-python = ">=3.10". The classifier says OS Independent, and the original doesn't specify supported OS versions or hardware requirements like GPU memory. The dependency list pulled in by pip install voicemem is substantial — numpy, openai, mem0ai, torch, torchaudio, torchvision, transformers==4.52.3, accelerate, funasr, modelscope. Note the pinned transformers version; that's a common source of conflicts if you're installing into an existing environment.

Network is the other practical constraint. Models come from Hugging Face, and the Chinese guide notes that users in mainland China may need a mirror or an accelerated download path. That's a real friction point for a repo whose model download is a required step, not an optional one.

Why a Chinese README is worth more than it sounds

Machine translation of technical documentation is cheap now. What isn't cheap is knowing which parts of a document will break someone's setup.

The upstream README is organized for someone evaluating the project: architecture, model family, dataset, citations. The Chinese supplement is organized for someone installing it tonight. Different documents, different ordering, and the second one is what most readers actually need on the first pass.

There's also the dependency-pinning problem. transformers==4.52.3 is a hard constraint buried in a long list. A reader scanning English prose for install instructions may not register it. A reader working through a numbered checklist will.

I'd hedge on one point: my sense of how much time this saves is based on reading both documents, not on watching anyone use them. Your mileage depends on how much PyTorch packaging you've already done.

What's in the upstream repo beyond the install

Worth knowing before you commit, since the Chinese version translates all of it.

Releases. v0.0.1 on 08/27/2026 shipped the initial VoiceMem and the technical report. v0.0.2 on 09/01/2026 fixed the event-date chain, removed a redundant right-brain memory category, and opened a pluggable speech synthesis layer.

Model family. Open-sourced 08/21/2026, described as able to read and understand memories produced by VoiceMem.

VoiceMem Utils. Same date, described as ready to use out of the box.

ChatMem-400K. A dataset open-sourced 08/20/2026.

The repo also links a project page, technical report, and Hugging Face collections for both Utils and the model families. The README includes a demo video, with a note that you need to unmute before playing.

Two things to check before adopting

The right-brain emotion layer is the part most likely to be misconfigured, given the silent-fallback behavior. If you're evaluating whether the emotion attribution actually helps your use case, verify torchvision and accelerate are present and check that you're not running in the degraded acoustic-only mode. The failure produces plausible-looking output, which makes it hard to catch by inspection.

Second, the replaceability claim. The README says all components including the memory engine can be swapped. That's a design statement, not a tested integration matrix. If you plan to substitute the embedding model or the memory backend, budget time for reading source rather than assuming a documented adapter interface.

Where the translation helps most

If you're comfortable in English, the Chinese repo's main value is the quick-start section — the four traps above are worth the click regardless of which README you read afterward. If you're not, it's the difference between reading documentation and guessing at it.

The repo invites issues and PRs for translation inaccuracies, which is the right posture for a project like this. Translations drift, upstream changes, and a version pinned to a 2026-10-14 snapshot will need maintenance.

Original project: xzf-thu/VoiceMem — 2501 stars, Python, Apache-2.0.
Chinese version: yangshun2005/VoiceMem-cn.

Chinese documentation: https://github.com/yangshun2005/VoiceMem-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

FrontierAgent: A Chinese Translation of the Agent Runtime, and What It Actually Ships

sun young — Wed, 14 Oct 2026 09:50:39 +0000

FrontierAgent is an open-source agent runtime, terminal product, and evaluation suite aimed at long-horizon research and file-based work. The original repo, ApodexAI/FrontierAgent, sits at 5243 stars, is written in Python, and is licensed Apache-2.0.

There is now a Chinese translation of that documentation: yangshun2005/FrontierAgent-cn. It was translated on 2026-10-14. It is a fresh repo, so don't read anything into a low star count — the point of this article is what's inside it, not how popular it is.

I want to be precise about what the Chinese repo contains, because it's not just a translated README. It has two distinct layers, and the distinction matters if you're deciding whether to use it.

Two layers in the Chinese repo

The project explicitly separates them:

A Chinese quick-start guide at the top of the page. This is supplementary material, not part of the original README. It exists so you can get the project running without reading the whole document.
The translated README body below it. This is a faithful translation of the original English documentation.

The maintainers say translation inaccuracies should go through Issues or PRs. That's a reasonable setup — the quick-start is opinionated and can drift from upstream, while the translated body tracks the original.

If you've ever tried to onboard onto an agent framework where the only docs are English and the terminology is dense (task boards, sandboxes, fail-closed authorization, checkpointing), you know why the quick-start layer is the useful part. It front-loads the minimum you need.

What FrontierAgent actually is

The one-line description from the project: a native command-line TUI, ReAct and Agent Team modes, one command on macOS and Linux, no preinstall, no hard Docker dependency.

The TUI ships two native workflows:

ReAct — a single stateful agent that researches, reads files, writes deliverables, runs commands, and iterates inside a task-level sandbox.
Agent Team — a coordinator maintains a task board, delegates independent work to parallel sub-agents, collects their reports, and synthesizes the result.

The same workflow engine drives the benchmark runner used to evaluate Apodex models. The framework, tools, workflows, and evaluation layers are kept separate, so each can be reused independently. That separation is the part I'd actually care about if I were building on top of this rather than just running it.

The pieces worth knowing about

Task board. In Agent Team mode, add_task and update_task events render live in the TUI sidebar. States are pending, in progress, done, blocked, and cancelled. This is a small thing that makes a big difference in practice — you can see what the coordinator thinks it's doing.

Sandboxed file operations. Shell and file tools share one task-level filesystem: /inputs is read-only, /workspace is working state, /outputs holds persistent deliverables. Both authorization and sandbox failures are fail-closed, meaning a failure denies rather than allows.

Async intervention. You can type into the agent while it runs. The input queues and injects at the next safe turn boundary instead of killing the current run. In Agent Team mode it steers the coordinator; sub-agents already running are allowed to finish.

Transparent deliverables. On macOS and Docker, /outputs maps to .apodex/runs/<run>/outputs on the host. The same run directory holds checkpoints, traces, engine logs, and trajectories.

Approvals, tracing, resume. Mutating operations show a diff and require approval unless you pass --yes. Sessions checkpoint, every operation is traced locally, /revert restores session changes, and --resume continues a saved run.

Built-in evaluation. A subprocess runner supports research and file-based benchmarks, deterministic artifact collection, concurrency, and progress tracking.

Getting it running

Prerequisites per the original: Git, Python 3.12, uv, and an OpenAI-compatible model endpoint. Docker is optional.

git clone https://github.com/ApodexAI/FrontierAgent.git
cd FrontierAgent
uv sync --python 3.12 --extra dev
cp .env.example .env

Then fill in .env:

OPENAI_API_KEY=your-key
OPENAI_BASE_URL=https://your-openai-compatible-endpoint/v1
OPENAI_MODEL=your-model-name

One honest gap: the Chinese quick-start does not give the exact command to launch the TUI. The materials only mention the frontier-agent TUI as a product name. If you need the launch command, read the translated README body — the quick-start tells you so directly rather than inventing a command.

Environment details

Python: requires-python = ">=3.12"; the quick-start says Python 3.12.
Tools: Git and uv required; Docker optional.
Model endpoint: an OpenAI-compatible endpoint via OPENAI_API_KEY, OPENAI_BASE_URL, OPENAI_MODEL. Without all three it won't run.
Optional dependency groups (from pyproject.toml): document-readers, plugins, sandbox, eval, dev.
OS: not explicitly constrained in the docs. The Dockerfile is based on python:3.12-slim and installs bubblewrap, libreoffice-core, and libreoffice-impress inside the image.

Traps the Chinese docs call out

These are the ones that will cost you an afternoon if you miss them.

You must configure the model endpoint. No key, no base URL, no model name means no run. The project also offers a free Apodex API trial — two weeks, key from platform.apodex.ai — if you don't want to host a model yourself.

Sandbox and authorization behavior. Mutating operations show a diff and ask for approval unless --yes is set. Authorization and sandbox failures are fail-closed. In the Docker image SANDBOX_BACKEND=bwrap; if the runtime doesn't grant bubblewrap namespaces, it falls back to container mode.

Optional web tools need extra keys. Web research tools require SERPER_API_KEY with WEB_SEARCH_PROVIDER=serper. The materials leave JINA_API_KEY unset.

Version pinning. apodex-agent-core==0.14.1 is pinned exactly. The comment notes that 0.x MINOR upgrades can be breaking, which is why the pin is tight.

Network mirrors. The materials don't mention domestic mirrors or download accelerators. If you're behind a slow connection to PyPI, that's on you to solve — the docs don't address it.

Why the Chinese version is worth having

The value here isn't exotic. It's that the barrier for Chinese-speaking developers drops. Agent frameworks are dense with terms that don't translate cleanly — "fail-closed authorization," "turn boundary," "task board," "checkpoint" — and reading a translated version first means you spend your attention on the architecture instead of on vocabulary.

The two-layer structure is the right call. A quick-start that gets you to a running process, plus a faithful translation of the full documentation underneath. The maintainers are upfront that the quick-start is supplementary and the translation aims for fidelity, and they invite corrections.

If you're evaluating FrontierAgent and English docs are friction, start with the Chinese repo. Read the quick-start, get the endpoint configured, run it. Then go back to the translated body when you need to understand Agent Team's task board semantics or how /outputs maps on your platform.

Repo: yangshun2005/FrontierAgent-cn
Upstream: ApodexAI/FrontierAgent

Chinese documentation: https://github.com/yangshun2005/FrontierAgent-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.