DEV Community: sun young

auto-ontology: A Chinese Translation of NVIDIA's Context Layer for Agents

sun young — Wed, 04 Nov 2026 17:54:02 +0000

A schema dump into the context window is the cheapest way to give an agent database access, and it is also the reason agents confidently return wrong revenue numbers. The column names are there. The meaning is not. NVIDIA's auto-ontology takes a different route: it compiles database metadata into an ontology — business terms mapped to columns, reviewed metric SQL, and relationships between tables — and lets the agent query through that layer.

The project is Python, Apache-2.0, and sits at 4406 stars on the original repository. A Chinese translation of its documentation was published on 2026-11-05 at https://github.com/yangshun2005/auto-ontology-cn. That translation is what this article is about, plus what the tool actually does.

What the service is

Auto-Ontology runs next to your database. It ingests metadata and compiles an ontology from it. The ontology holds three things:

business terms mapped to specific columns
reviewed SQL expressions for metrics
relationships between tables

An agent queries through the ontology instead of through raw schema. Before answering, it checks whether the question is answerable at all. When it does answer, it returns the SQL it ran and the reasoning steps, so a human can check the work.

The README frames the problem in terms of reliability rather than speed: a revenue figure computed quickly is worthless if it is wrong. The agent needs to know where the data lives, what it means, whether it should be used, how to use it, where it came from, and which data is similar. That is the context layer.

The comparison that matters

The README includes a table contrasting schema-in-context with the ontology tool approach. It is worth reproducing because it is the clearest statement of the design intent:

	Schema in context window	Auto-Ontology tools
Token	Grows with every table and column	Only terms and tables relevant to the question
Meaning	Column names only, rest inferred by the agent	Business terms mapped to columns and SQL
Joins and metrics	Improvised per question	Resolved relationships and reviewed SQL expressions
Unanswerable questions	Confident answers, often wrong	Answerability check, agent asks for clarification

The last row is the one that changes behavior most. An agent that can say "I can't answer this from the available definitions" is more useful than one that produces a plausible-looking number.

Quickstart, as documented

The README's quickstart uses Docker Compose against the Wide World Importers sample database. The steps, in order:

Clone and configure:

git clone https://github.com/NVIDIA/auto-ontology.git && cd auto-ontology
cp .env.example .env

Then set DEFAULT_MODELS_API_KEY (an nvapi-... key), AUTH_SECRET, APP_URL=http://localhost:3000, POSTGRES_PASSWORD, CONNECTION_STRINGS, AUTO_ONTOLOGY_ADMIN_PASSWORD, and PGADMIN_PASSWORD in .env. The README gives a full example of each value.

Start Postgres and seed the sample database. The seed script lives in the separate auto-ontology-eval repository:

docker compose up -d --wait postgres
git clone https://github.com/NVIDIA/auto-ontology-eval.git ../auto-ontology-eval
(cd ../auto-ontology-eval && uv sync && cp .env.example .env && \
  POSTGRES_PASSWORD=' ' \
  uv run python scripts/seed/seed_wwi.py --database-name wideworldimporters --drop)

Build and start the remaining services:

docker compose up -d --build

Open the app, log in with AUTO_ONTOLOGY_ADMIN_EMAIL and AUTO_ONTOLOGY_ADMIN_PASSWORD from .env, go to Settings → Semantic Compilation, and turn it on. Ingestion runs at startup; when compilation finishes you should see Semantic compilation is ready.

Then ask a question in Chat. The README's example concerns revenue for a product in Pennsylvania in June 2015. The answer comes back with SQL and reasoning steps attached.

Requirements

Docker and Compose v2 are required by the quickstart, as is uv. The project's pyproject.toml requires Python >=3.12. The Dockerfile is based on nvcr.io/nvidia/base/ubuntu (jammy), and the Makefile's default multi-arch release targets are linux/amd64,linux/arm64. The README does not specify special hardware requirements, and does not constrain the host OS beyond what Docker implies.

What the Chinese version adds

The translation repository is explicit about its structure. The README body is a translation of the original documentation, kept close to the source. On top of that, the page opens with a section labeled 中文快速上手 ("Chinese quick start") that is marked as supplementary material, not part of the original text.

That distinction is the useful part. A translated README is helpful; a translated README with a short path to a running instance in front of it is more helpful. The quick-start section answers four questions before the reader hits the full documentation: what this is, what problem it solves, what the shortest path to a working setup looks like, and what the environment needs.

For a project whose setup involves a .env file with seven or eight variables, a second repository for seed data, and a settings toggle that must be flipped before anything works, that ordering matters. The barrier for a Chinese-speaking developer is not usually the English prose in the middle of the README — it is the sequence of shell commands and the config values, where a single mistyped variable name produces an opaque failure.

The translation also states its own limits: inaccuracies should be reported as an Issue or PR. That is the right posture for a translated technical document, since the original is the authority and will keep moving.

How the pieces fit

The system has five verbs in the README's own framing, and they describe the workflow rather than the architecture:

Discover — generate an ontology from database metadata, import existing semantic models, explore the result as a semantic graph.
Anchor — give each business concept a single definition, mapped across tables and databases.
Certify — review, edit, and certify definitions in the UI or via API.
Validate — check answerability before querying, return SQL and agent steps with every answer.
Expose — serve the context to any agent framework through MCP, agent skills, and a REST API.

The MCP and REST surfaces are what make this framework-agnostic. The ontology is not tied to a particular agent runtime.

Evaluation

The companion repository auto-ontology-eval measures ontology performance on benchmarks. The README names BIRD, BEAVER, FDABench-Lite, and Wide World Importers, with each evaluation item pairing a question against gold-standard SQL. I have not run these benchmarks myself, so I can't speak to the numbers — the eval repository is where to look for them.

Who this is for

If you are building agents over an enterprise database and you have already hit the failure mode where the agent answers confidently and wrongly, the ontology approach is worth evaluating. The cost is real: you have to define business terms, review metric SQL, and certify definitions. That is human work, and it does not disappear because a service compiles metadata.

The Chinese translation lowers the entry cost for teams whose developers read Chinese more comfortably than English. It does not change what the tool does. The original repository is still the source of truth, and the translation says so.

The Chinese version is new — published 2026-11-05, with no stars yet. The original has 4406. If you are working through the quickstart and something in the translated text does not match what you see, the original README is the place to check first.

Chinese documentation: https://github.com/yangshun2005/auto-ontology-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.

agent-desktop: A Chinese Translation of Vercel Labs' Accessibility-Tree CLI for AI Agents

sun young — Wed, 04 Nov 2026 17:44:35 +0000

agent-desktop doesn't take screenshots. It reads the OS accessibility tree and returns it as JSON, with a ref attached to every actionable element. An agent clicks or types via that ref, then re-reads the UI to check what happened.

That's the whole idea. The original is vercel-labs/agent-desktop (14547 stars, written in Rust, Apache-2.0). A Chinese translation now exists at yangshun2005/agent-desktop-cn, published today. It has 0 stars — it's brand new, so treat it as a reading aid, not a community-validated fork.

This article covers what the tool does, how the ref model works, where it breaks, and what the Chinese version actually adds.

What the tool is, and what it deliberately isn't

The official one-liner is "Computer use CLI for AI agents." Two things follow from that phrasing:

It ships as a CLI and a C library. Not a framework, not an SDK with an agent loop inside.
No model is bundled. The observe → act → observe loop lives in whatever agent calls it.

That second point matters more than it looks. A lot of "computer use" tooling hides a planner inside, which makes failures hard to attribute. Here, if the agent clicks the wrong thing, the agent chose the wrong ref. The tool just reported the tree.

Supported platforms: macOS, Windows, Linux. Architectures: x64 and ARM64.

The ref model

A snapshot returns an envelope. Trimmed example from the README:

{
  "version": "2.6",
  "ok": true,
  "command": "snapshot",
  "data": {
    "app": "Finder",
    "snapshot_id": "s8f3k2p9",
    "ref_count": 59,
    "complete": true,
    "tree": {
      "role": "window",
      "name": "Downloads",
      "children": [
        { "role": "treeitem", "name": "Documents", "ref_id": "@s8f3k2p9:e8", "available_actions": ["Click"] }
      ]
    }
  }
}

Two details in that payload are load-bearing.

The ref carries its snapshot id. @s8f3k2p9:e8, not @e8. Write the bare form and you get INVALID_ARGS. This is intentional: a ref without a snapshot id has no way to tell you whether the UI it referred to still exists.

complete is a field, not an assumption. If the tree was truncated, the envelope says so. An agent that ignores it may act on a partial view and conclude the element is missing.

The loop, in shell form:

agent-desktop snapshot --app Finder -i      # interactive elements only, each with a ref
agent-desktop click @s8f3k2p9:e8            # act on a ref from that snapshot
agent-desktop snapshot --app Finder -i      # observe again to verify

The -i flag filters to interactive elements. On a busy window the full tree can be large; -i is usually what you want for the act step.

Installation paths

npm is the shortest route, and needs Node 18+:

npm install -g agent-desktop
agent-desktop status                # platform, permissions, supported surfaces
agent-desktop permissions --guide   # macOS: walks you through Accessibility authorization

Bun, Yarn and pnpm install the same package. It bundles native binaries for x64 and ARM64 plus platform helpers.

Alternatives:

Homebrew on macOS and Linux: brew install agent-desktop. No official Scoop package; the repo no longer maintains a custom Homebrew tap or Scoop bucket.
GitHub Releases: download the matching native archive and place the helper next to the executable, if you want to skip the JavaScript launcher.
From source: requires Rust. Cargo.toml declares rust-version = "1.89" and edition 2024.

On macOS, nothing works until Accessibility permission is granted. agent-desktop permissions --guide is the guided path; skipping it means snapshots come back empty and you'll spend an hour debugging the wrong layer.

Failure modes worth knowing before you write the loop

These are the ones that cost time.

Stale refs. If the UI changed between snapshot and action, the command returns STALE_REF or AMBIGUOUS_TARGET. The fix is always the same: re-snapshot, use the new ref. Don't retry the old one. An agent that retries blindly will burn turns.

PowerShell quoting. On Windows PowerShell, @token is the splatting operator. Every ref must be quoted:

agent-desktop click '@s8f3k2p9:e8'

Unquoted, the shell eats it before the CLI sees it.

Blocked postinstall. If npm blocks the postinstall script, every invocation pays roughly 125ms extra. Reinstall with --allow-scripts=agent-desktop. For project-local installs there's a separate npm install-scripts approve flow.

Privacy. Snapshots, clipboard reads, screenshots, command output and debug artifacts can all contain private desktop content. The README says this plainly, and it's not boilerplate. A snapshot of a mail client is a snapshot of your inbox. Don't put these in public logs or upload them to a shared trace viewer.

What the Chinese version adds

The translated repo is structured in two layers, and the split is the useful part.

The top section — 「中文快速上手」 — is explicitly labeled as supplementary, not part of the original. It answers the questions a Chinese-speaking developer hits in the first ten minutes:

What problem does this solve, in one paragraph
The shortest install-to-first-snapshot path
Environment requirements (Node 18+, x64/ARM64, the Homebrew and source-build routes)
A "common pitfalls" list: the snapshot-id requirement, PowerShell quoting, the postinstall penalty, the privacy warning, macOS authorization

Below that, the README body is a translation of the original documentation, with a stated goal of staying faithful to the source. The original English README is kept as README_en.md for comparison. Translation errors are handled by Issue or PR, which is the right call — a translated technical doc that can't be diffed against its source is worse than no translation.

The value here is narrow but real. The English README is not long, but it's dense with platform-specific caveats — the PowerShell splatting issue, the STALE_REF semantics, the macOS permission gate. Those are exactly the sentences a non-native reader skims and then loses an afternoon to. Having them in Chinese, with the pitfalls pulled forward into a checklist, shortens the path to a working snapshot.

One caveat on the translation date: the header lists 2026-11-05. The upstream project moves; if you're reading this much later, check README_en.md for drift.

Where this fits

If you're building an agent that needs to drive a real desktop app, the accessibility-tree approach has a clear advantage over pixel matching: elements come back with roles, names and available actions, so the agent reasons over semantics instead of coordinates. It also has a clear cost: you're dependent on how well each app implements accessibility. Apps with poor trees will give you poor snapshots, and no amount of prompt engineering fixes that.

The tool is honest about its scope. It reads, it acts, it reports. The loop is yours.

Repo: yangshun2005/agent-desktop-cn — Chinese translation, published today, 0 stars. Upstream: vercel-labs/agent-desktop, 14547 stars, Rust, Apache-2.0.

Chinese documentation: https://github.com/yangshun2005/agent-desktop-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.

t3code: a Chinese translation of the agent harness control panel, and what it actually gets you

sun young — Sun, 01 Nov 2026 08:17:58 +0000

T3 Code is a control surface for coding agents you already run on your own machine. The upstream project is pingdotgg/t3code, 36,095 stars, written in TypeScript, MIT licensed. There is now a Chinese translation of its documentation at yangshun2005/t3code-cn, published 2026-11-01.

That translation is the subject here. Not because a translated README is remarkable in itself, but because of what the original project asks of its reader before anything works.

What T3 Code is, precisely

The README calls it an "agent harness control surface." Read that literally. T3 Code ships no model. It does not proxy your API keys to some inference endpoint. It connects to agents already installed and authenticated on your local machine, and gives you an interface to drive them from an iOS app, an Android app, a web app, or an Electron desktop build.

The supported providers, per the README:

Codex
Claude Code
Cursor
Grok Build
OpenCode
Google Antigravity
fx

If none of those are installed and logged in on your machine, T3 Code has nothing to control. That constraint shapes the entire onboarding flow, and it is the first thing the Chinese version front-loads.

Why the translation matters more than it sounds

The original README is honest about the project's state: "very, very early, expect bugs," and contributions are largely closed — small fixes might be considered, large features will not. So this is not a project where you read the docs, file an issue, and wait. You read the docs, get it running, and decide for yourself.

Getting it running means seven different authentication commands across seven different CLIs, plus platform-specific install paths for macOS, Linux, Windows, Debian, Ubuntu, Arch, and Nix. Every one of those steps is a place where a non-English reader stalls — not because the English is hard, but because the failure modes are terse and the commands are easy to mistype.

The Chinese version addresses this with a structure the original does not have. It separates two things:

A 中文快速上手 section at the top, explicitly labeled as supplementary orientation material, not part of the original.
The translated README body below it, which aims to stay faithful to the source.

That split is the right call. A translation that silently adds advice is a translation you cannot trust. A translation that only translates leaves the reader to assemble the setup sequence themselves. Marking the boundary lets you use the fast path and still know which parts are the author's additions.

The shortest path to a running instance

The quick-start section condenses the setup into five steps. Here is what it says, in order.

First, install and log in to at least one supported agent. The commands, as given:

# Codex
codex login

# Claude Code
claude auth login

# Cursor CLI
agent login

# Grok Build
grok login

# OpenCode
opencode auth login

Antigravity is the exception — no CLI. You enable it in Settings, then click Install Antigravity and Sign in with Google.

fx has its own wrinkle: fx login must run on the machine hosting the T3 Code server, not just any machine. The Chinese version calls this out explicitly in its pitfalls section. The original mentions it too, but buried in a provider list; the translated version surfaces it as a standalone warning.

Second, install the CLI. macOS and Linux:

curl -fsSL https://t3.codes/install.sh | sh

Windows PowerShell:

irm https://t3.codes/install.ps1 | iex

Third, run t3. That starts the server and opens the local web app.

Fourth, optional service management:

t3 service install   # run in background
t3 update            # upgrade
t3 --help            # full command reference

Fifth, if you want to try without installing: npx t3@latest.

Desktop builds are also available from GitHub Releases or via package managers — winget install T3Tools.T3Code and brew install --cask t3-code are two the README lists.

The network caveat the original doesn't discuss

The Chinese quick-start adds a note that the install scripts and desktop packages all download from overseas addresses: t3.codes, GitHub Releases, and various package managers. Under restricted network conditions you may need your own acceleration or mirror.

It also states plainly that the original provides no mirror sources. That is accurate and worth saying. A translated doc that pretends the network is uniform is less useful than one that flags the gap and admits it has no fix.

What the translation does not claim

No hardware requirements. No minimum OS versions. The Chinese version says so directly rather than inventing them: "原文未说明" appears in the environment requirements section for both hardware and OS version floors.

That restraint is the thing I'd point to if you're evaluating whether to trust this translation. It would have been easy to fill those blanks with plausible guesses. The author didn't.

The one build-from-source detail it does add: you need the global vp (Vite+) tool installed, then run vp i. That comes from the original's build instructions, just relocated to where a reader would look for it.

Who this is for

If you already use Claude Code or Codex locally and want a unified, remote-capable interface across phone, web, and desktop, T3 Code is aimed at you. If you have none of the seven supported agents installed, there is no partial mode — the project simply won't do anything.

The Chinese version lowers the entry barrier for that first group by removing the assembly work: the provider matrix, the per-platform install commands, and the ordering constraints are all in one place, in the language you're reading. My sense is that most of the friction in early-stage projects like this is not conceptual difficulty but sequence confusion — which command first, which machine, which login. That's exactly what the quick-start section targets. Your mileage may vary depending on which provider you pick; the fx path in particular has that server-machine constraint that's easy to miss even when it's written down.

The translation is at github.com/yangshun2005/t3code-cn. It carries zero stars as of publication — it went up today. The upstream project it documents has 36,095. Corrections to the translation go through Issues or PRs, per the README.

Chinese documentation: https://github.com/yangshun2005/t3code-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.

Claude-Code-Game-Studios: A Chinese Translation for Claude Code's 49-Agent Game Studio

sun young — Sun, 01 Nov 2026 07:47:32 +0000

The original repo has 31,393 stars. The Chinese translation launched today with zero. That gap is the whole point of this article: the project is worth reading, and for a Chinese-speaking developer the barrier to reading it just dropped.

What the project actually is

Claude-Code-Game-Studios (original: Donchitos/Claude-Code-Game-Studios, Shell, MIT) is a configuration template for Claude Code. It does not generate games. It restructures a single chat session into something that behaves like a studio hierarchy.

The numbers from the README:

Category	Count	What it covers
Agents	49	Sub-agents across design, programming, art, audio, narrative, QA, production
Skills	74	Slash commands for each workflow stage
Hooks	15	Automatic validation on commit, push, asset changes, design doc reads/writes, registry writes, session lifecycle, agent audit trail, gap detection
Rules	14	Path-scoped coding standards
Templates	62	GDD, UX spec, ADR, sprint plan, HUD design, accessibility, and more

The problem it targets is stated plainly in the README: a solo developer using AI has no structure. Nobody stops you from hardcoding magic numbers. Nobody asks whether a feature matches the game's vision. There is no QA pass and no design review.

The three-layer hierarchy

Agents are organized the way a real studio is:

Layer 1 — Directors
  creative-director    technical-director    producer

Layer 2 — Department Leads
  game-designer        lead-programmer       art-director
  audio-director       narrative-director    qa-lead
  release-manager      localization-lead

Layer 3 — Specialists
  gameplay-programmer  engine-programmer     ai-programmer
  network-programmer   tools-programmer      ui-programmer
  systems-designer     level-designer        economy-designer
  technical-artist     sound-designer        writer
  world-builder        ux-designer           prototyper
  performance-analyst  devops-engineer

Each agent has a defined scope, an escalation path, and quality gates. You still make every decision. The difference is that the session now pushes back — asks the questions a lead would ask, catches errors earlier.

One practical detail worth flagging before you start: model requirements differ per agent. The three director agents require Opus. lead-programmer and 15 specialists specify Sonnet. The remaining 30 inherit whatever model your session is running. If your session model is lower than what a role expects, that role may not behave as intended.

Getting a session running

The Chinese README adds a "中文快速上手" (quick start) section that is explicitly marked as supplementary, not part of the original translation. It exists so you can get moving without reading the full document first. The shortest path:

git clone https://github.com/Donchitos/Claude-Code-Game-Studios

Open the project directory in Claude Code, then:

/start — begins the guided flow
/setup-engine — pick Godot 4, Unity, or Unreal Engine 5
Then move through /brainstorm, /design-system, /create-epics, /create-stories, /dev-story, /story-done as needed

The engine choice matters. There are three separate agent sets, one per engine, and /setup-engine selects the matching one. Pick wrong and your specialists won't line up with your project.

The original README does not provide an explicit install or launch command, and the Chinese version says so rather than inventing one. Platform support and hardware requirements are also marked as not specified in the source material — the "Platform Support" section was truncated in what was available for translation. The only hard dependency stated is Claude Code itself.

Why the Chinese version is worth having

The translation is faithful to the original — the body of the README is translated text, and the quick-start section is clearly separated as an addition. That separation is the right call. You can tell at a glance which parts are the author's words and which are translator commentary.

For a Chinese-speaking developer, the practical gain is not just language comfort. This is a document dense with role names, workflow vocabulary, and process concepts — "department lead," "escalation path," "quality gate," "sprint plan," "ADR." Reading that in a second language while also trying to learn an unfamiliar workflow is slow. Having the terminology in Chinese means you spend your attention on the structure instead of on parsing.

The quick-start section also front-loads the things that trip people up:

Model cost. Some agents require Opus or Sonnet. Budget for it or expect degraded behavior from those roles.
Engine selection is exclusive. One of three agent sets, chosen via /setup-engine. This is a one-time decision that shapes everything downstream.
It is a process template, not a game generator. Output is design docs, architecture, stories, reviews. Not a playable build.
Upgrades have their own doc. The repo includes UPGRADING.md. Read it before upgrading so you don't overwrite custom configuration. The specific upgrade steps aren't detailed in the available material.

That last point is a good example of how the translation handles uncertainty: it says what the source says and marks what the source doesn't cover, rather than filling gaps with guesses.

What it produces

The README has a section titled "它产出游戏还是文档？" (Does it produce games or documents?). The available material is truncated at that point, so the original's conclusion isn't stated here. What is clear from the rest of the document is that the output is process artifacts — GDDs, UX specs, ADRs, sprint plans, HUD designs, accessibility docs, drawn from the 62 templates. Treat it as scaffolding for a solo project that would otherwise have none.

A note on the numbers

31,393 stars belong to the original project. The Chinese translation is new and has none yet. If you're evaluating whether to adopt this, the star count tells you the original is widely used; it tells you nothing about the translation's quality. The translation's own claim is modest — if something is inaccurate, open an issue or a PR.

My read is that the translation is competent and the structure is honest about its own limits. That's a small sample, and it may not hold for you.

Repository

Chinese version: https://github.com/yangshun2005/Claude-Code-Game-Studios-cn
Original: https://github.com/Donchitos/Claude-Code-Game-Studios

License: MIT. Language: Shell.

Chinese documentation: https://github.com/yangshun2005/Claude-Code-Game-Studios-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.

claude-mem: a Chinese translation of the persistent-memory layer for Claude Code

sun young — Fri, 30 Oct 2026 19:40:28 +0000

Every time you open a new Claude Code session, the model starts from zero. It doesn't remember that you already fixed the auth bug two hours ago, or which file holds the retry logic, or why you rejected the first approach. You re-explain, it re-reads, and the loop repeats.

claude-mem is a project that tries to close that gap. The upstream repo is thedotmack/claude-mem, written in TypeScript, Apache-2.0 licensed, with 105,900 stars. A Chinese translation of its documentation was published today at yangshun2005/claude-mem-cn. That translation is what I want to look at here — not because the translation itself is technically interesting, but because of what it changes for a specific group of developers.

What the project actually does

The one-line description from upstream is: "Persistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions."

Stripped of the marketing, the mechanism is:

Capture. During a Claude Code session, claude-mem records "observations" about tool usage — what the agent read, ran, changed.
Compress. Those raw observations get summarized into semantic form.
Inject. In later sessions, relevant pieces of that compressed memory are fed back into context.

The stated goal is knowledge continuity: Claude keeps a working model of the project across session boundaries and reconnects. It's advertised as working with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode and others.

That's the whole pitch. Whether the compression is good enough to be useful rather than noisy is something you'd have to judge on your own codebase — I haven't benchmarked it, and the README doesn't publish accuracy numbers.

Install path

The primary install command from the README:

npx claude-mem install

For Grok Bot there's a separate invocation:

npx claude-mem install --ide grok-bot

The installer configures the environment first, then asks you to log in through the browser using an email magic link. No credit card. Login assigns your account a memory key and unlocks the claude-mem observer with a 30-day free trial.

After login you pick a memory provider:

claude-mem observer (the hosted option)
your own OpenRouter key
your own Gemini key
your Anthropic plan

If you'd rather not log in at all, the README lists three escape hatches: pass --provider explicitly, set CLAUDE_MEM_ONLINE_OPTIN=false, or run in a CI / non-interactive environment. The README text is truncated at that point, so the full non-interactive details aren't documented in what I have.

Node.js >=20.0.0 is the dependency floor. Current version is 15.7.0. The README doesn't state which operating systems are supported or what hardware it wants — that's a gap, not an omission on my part.

The parts that will bite you

Three things in the README are worth reading twice before you install.

The trial expires. The claude-mem observer is a 30-day free trial. When it ends, memory functionality falls back to your Anthropic plan unless you subscribe. If you're evaluating this for a team, that's a cost decision you should make up front rather than discover in month two.

Grok Bot works differently. Grok Bot has no host hooks, so claude-mem watches chat log files instead. It defaults to hosted CMEM Pro; the local observer requires --provider host to be turned on explicitly. Installing that plugin does not install Cursor.

Awareness push writes to disk. For Grok Bot, key observations — decision, bugfix, security_alert, sensitive — get appended as dated - YYYY-MM-DD [awareness] … lines into memory/log/YYYY-MM.md. Grok Bot already re-reads logs from disk. This does not write to profile.md, user memory, or project memory. You can disable it with CLAUDE_MEM_GROK_BOT_AWARENESS_ENABLED=false.

That last one matters if you care about what lands in your repo. A log file accumulating security-flagged observations is exactly the kind of thing you want to know about before it's committed.

Why a Chinese translation is more than a convenience

Here's the part I actually want to argue.

The upstream README is long. It has a 30-language selector strip, a quick start, a "how it works" section, search tools, docs, configuration, and troubleshooting. For an English reader that's a lot of scrolling. For a Chinese-speaking developer it's worse: you're parsing configuration semantics in a second language while simultaneously trying to decide whether the tool fits your workflow. Those are two different cognitive loads, and doing them at once is how people misread --provider host as optional.

The claude-mem-cn repo does something slightly smarter than a straight translation. It splits the page into two layers:

A 中文快速上手 section at the top, explicitly marked as supplementary material, not part of the original. This is a curated导读 — what the project is, what problem it solves, the shortest path to running it, environment requirements, and common pitfalls.
The translated README body below, which the maintainer states aims to stay faithful to the original.

That distinction is stated openly in the README: "本页顶部的「中文快速上手」为面向中文用户的补充导读（非原文内容）" — the top section is a guide for Chinese users, not original content. And: "如有翻译不准确之处，欢迎提 Issue 或 PR" — inaccuracies should go to issues or PRs.

I like this because it's honest about provenance. A translation that silently blends editorial additions into the source text is worse than useless; you can't tell which claims are the project's and which are the translator's. Here the boundary is drawn in the document itself.

The quick-start section also front-loads the things that would otherwise cost you an hour: that login is required by default, that the free trial has an end date, that Grok Bot has different constraints, that awareness push can be turned off. Those are all in the English README too, but scattered. Collecting them into one screen is the actual value-add, more than the translation itself.

What the translation doesn't solve

Two honest caveats.

First, the quick-start section inherits the same truncation as the source. The non-interactive install path is described as "原文此处被截断，后续细节未说明" — the original is cut off there, details not given. So if you're trying to wire this into CI, the Chinese version won't get you further than the English one. You'll need to read the source.

Second, the translation is dated 2026-10-31 and the project is at 15.7.0. Fast-moving repos drift. If you're reading this much later, check whether the Chinese README still matches upstream before trusting a specific flag name.

Should you try it

If you use Claude Code on a project that spans multiple sessions — which is most real projects — the problem claude-mem addresses is real. Session amnesia is annoying and it costs tokens.

Whether claude-mem is the right fix depends on things the README can't tell you: how well the compression holds up on your codebase, whether the hosted observer is worth a subscription after the trial, and whether you're comfortable with observations being written to log files in your repo. My sample of one README is not enough to answer any of those.

What I can say is that the Chinese translation lowers the entry cost meaningfully. If your team reads Chinese and has been putting off evaluating this because the docs are dense English, the barrier just got smaller. The install is one command, the trial is 30 days, and the pitfalls are now listed in one place at the top of the page.

That's a reasonable place to start.

Original: thedotmack/claude-mem — 105,900 stars, TypeScript, Apache-2.0
Chinese version: yangshun2005/claude-mem-cn — published today

Chinese documentation: https://github.com/yangshun2005/claude-mem-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.

browser: A Chinese Translation of Lightpanda, the Zig Headless Browser for AI Agents

sun young — Fri, 30 Oct 2026 19:12:42 +0000

Lightpanda's own README makes a specific claim: 933 real web pages, fetched over the network on an AWS EC2 m5.large instance, peak memory around 123MB against roughly 2GB for Headless Chrome, execution time around 5s against roughly 46s. Those are the numbers the project publishes, and they are the reason a translation of its documentation is worth talking about at all.

The project is lightpanda-io/browser, 38165 stars, written in Zig, licensed AGPL-3.0. It is not a Chromium fork and not a WebKit patch. It is a new headless browser built from scratch for AI agents and automation workloads.

A Chinese translation of that documentation now exists: yangshun2005/browser-cn. It is new — published today, zero stars. This article is about what is in it and why the translation matters more than it might sound.

What the Chinese repository actually contains

Two distinct layers, and the repository is explicit about the separation:

A translated README (README.md), described as a faithful Chinese translation of the original project documentation. The original English README is kept alongside as README_en.md.
A "中文快速上手" (Chinese quick start) section at the top, marked as supplementary editorial content that is not part of the original README. Its stated purpose: get you running without reading the whole document first.

That second layer is the interesting one. A pure translation of a README assumes you already know what you want to do with the tool. A quick-start layer assumes you don't — which is the realistic state of most people arriving at a headless browser repository for the first time.

The repository also states its own fallibility: translation inaccuracies are to be reported via Issue or PR. Given the translation date listed as 2026-10-31 and the fast-moving nature of the upstream project, expect drift over time.

The quick start, condensed

The Chinese page lists every install path the upstream README offers. Reproduced here as they appear:

Homebrew:

brew install lightpanda-io/browser/lightpanda

Arch Linux AUR:

yay -S lightpanda-nightly-bin

Linux x86_64 binary:

curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-x86_64-linux && \
chmod a+x ./lightpanda

macOS aarch64 binary:

curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-aarch64-macos && \
chmod a+x ./lightpanda

Docker:

docker run -d --name lightpanda -p 127.0.0.1:9222:9222 lightpanda/browser:latest

Then verify the binary runs:

./lightpanda version

Fetch a URL and dump HTML:

./lightpanda fetch --obey-robots --dump html --log-format pretty  --log-level info https://demo-browser.lightpanda.io/campfire-commerce/

The --dump flag has other modes worth knowing about, all documented in the translated README: --dump markdown for Markdown output, --dump png > page.png and --dump pdf > page.pdf for text-rendered output, and --dump structured_data for JSON-LD and OpenGraph structured data.

Start the CDP server:

./lightpanda serve --obey-robots --log-format pretty  --log-level info --host 127.0.0.1 --port 9222

Then point Puppeteer at browserWSEndpoint: "ws://127.0.0.1:9222". The upstream README includes a full example script; the translation carries it over.

Why a Chinese quick-start layer is not just a nicety

Headless browser setup is a category of task where documentation friction compounds. You are usually doing three things at once: choosing an install method, confirming your platform is supported, and figuring out what the tool's output modes are. Every one of those steps has a failure mode that costs time.

The Chinese page front-loads exactly those failure modes. Three of them are worth calling out because they are the ones people hit.

No native Windows binary. The supported platforms are Linux (x86_64, aarch64) and macOS (aarch64, x86_64). Windows requires WSL2, following the Linux steps. The page notes wsl --install as the entry point. Android/Termux has no native build.

musl distributions break. The Linux release binaries link glibc. On Alpine and other musl-based systems you get cannot execute: required file not found because the glibc dynamic linker is absent. The fix is a glibc base image such as debian:bookworm-slim or ubuntu:24.04, or building from source. This is a genuinely annoying error message — it says nothing about glibc — and having it pre-explained in your first language is a real saving.

Building from source is slow. The Makefile comments note that compiling V8 from source takes more than 10 minutes. make download-v8 pulls a precompiled V8 archive instead. The translated page flags this; the exact build commands are not fully reproduced in the material available.

There is also a network note: installs pull from GitHub Releases, ziglang.org, and Docker Hub, so users on mainland Chinese networks may need mirror sources or download acceleration. That is the kind of sentence that never appears in an upstream README written for a global audience, and it is precisely the kind of sentence that saves an afternoon.

What the translation does not claim

Worth being clear about the boundaries, because the repository is:

The star count of 38165 refers to the original project. The Chinese repository has zero stars as of writing.
The benchmark figures (123MB vs ~2GB, 5s vs ~46s) are the upstream project's published results on AWS EC2 m5.large, not independently reproduced by the translator.
The translation does not state a minimum Zig version, because the upstream README does not list one in its body. The Dockerfile reads minimum_zig_version from build.zig.zon.
It does not state hardware requirements beyond the benchmark instance type.
It does not describe what happens if you omit --obey-robots. Every example command includes the flag; the behavior without it is undocumented in the source material.

That last point deserves a moment. Every fetch and serve example carries --obey-robots. If you are crawling at any scale, whether the flag is on by default and what it does when absent is a question you should answer before pointing the tool at a target, not after.

Where this fits

Lightpanda's pitch is narrow and concrete: a browser for agents that does not carry Chromium's memory footprint. The benchmark gap — roughly 16x on memory, roughly 9x on time — is the whole argument. If your crawler runs in a container with a memory limit, or if you are paying per-instance-hour for a fleet of them, that gap is the difference between a viable architecture and an expensive one.

The Chinese translation does not change any of that. What it changes is the number of people who can evaluate the claim quickly. A developer who can read the install matrix, spot the musl incompatibility, and know to use make download-v8 in their first ten minutes is a developer who gets to the actual benchmark question — does this work for my pages — much sooner.

My sample here is one repository published today, so I can't tell you how the translation holds up over time or how responsive the maintainer will be to corrections. The structure is right, though: original preserved as README_en.md, translation clearly labeled, editorial additions clearly separated from translated content. That is the correct way to do this, and it is more than many translation repositories bother with.

If you have been meaning to try Lightpanda and the English README was the thing you kept tabbing away from, the Chinese version is at github.com/yangshun2005/browser-cn. The upstream project is at github.com/lightpanda-io/browser.

Chinese documentation: https://github.com/yangshun2005/browser-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.

superpowers: a Chinese translation of the 307,936-star agent skills framework

sun young — Thu, 29 Oct 2026 12:41:20 +0000

Most coding agents have the same failure mode. You describe a feature, and before you finish the second sentence, the agent is already editing files. No clarifying questions, no spec, no plan. You get code that compiles and solves the wrong problem.

obra/superpowers exists to interrupt that reflex. It is a software development methodology packaged as a set of composable skills plus bootstrap instructions, written for coding agents. The original repository has 307,936 stars, is primarily Shell, and ships under the MIT license.

A Chinese translation was published today: yangshun2005/superpowers-cn. It has zero stars at the time of writing and no track record. What it does have is a translated README plus a short Chinese quick-start guide that the original doesn't include.

What the project actually does

The core behavior is a forced pause. When the agent detects you're building something, it does not start writing code. It steps back and asks what you're really trying to accomplish.

From that conversation it produces a spec, presented in chunks small enough to actually read and digest. After you confirm the design, it writes an implementation plan — detailed enough, in the project's own framing, for an enthusiastic junior engineer with poor taste, no judgment, no context on the project, and a dislike of tests to follow. The plan emphasizes real red/green TDD, YAGNI, and DRY.

Then, on your go-ahead, it runs a subagent-driven development loop: the agent works through each engineering task one at a time, checks and reviews the work, then moves on. The project claims agents can often work autonomously for hours without drifting from the plan.

Skills trigger automatically. There is no special command to invoke them; the premise is that your agent simply has these capabilities once installed.

The Chinese version: what's different

The translation date listed in the repo is 2026-10-29. The structure is deliberately split in two:

A Chinese quick-start guide at the top, explicitly labeled as supplementary material, not part of the original README. It covers what the project is, the shortest install path, environment requirements, and common pitfalls.
A faithful translation of the original README body below it, with README_en.md kept alongside for reference.

That split matters. Translated READMEs often bury the practical part — install commands, harness differences, update procedures — under a long conceptual preamble. Here the practical part comes first and is marked as an addition, so you can tell what's original and what's editorial.

The maintainer asks for issues or PRs where the translation is inaccurate. That's the right posture for a translation of a fast-moving project: the English source will drift, and the Chinese copy will need to follow.

Installation, and why it's the main friction point

Superpowers installs differently depending on your harness. If you use more than one, you install it separately for each. The original says this explicitly, and it's the first thing people get wrong.

For Claude Code, via the official Anthropic plugin marketplace:

/plugin install superpowers@claude-plugins-official

Or register the Superpowers marketplace first, then install from it:

/plugin marketplace add obra/superpowers-marketplace

/plugin install superpowers@superpowers-marketplace

After that, start your coding agent normally. Skills fire on their own.

The README lists per-harness instructions for Antigravity, Codex App, Codex CLI, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build CLI, Kimi Code, OpenCode, Pi, Qwen Code, Hermes Agent, and Muse. Do not copy a command from one harness into another; several use entirely different mechanisms, some going through a plugin marketplace and others installing from the repository.

Pitfalls worth knowing before you start

The Chinese quick-start collects these, and they're the ones that cost people time:

Install per harness. Multiple harnesses means multiple installs. There is no shared installation.
OpenCode is separate. Even if Superpowers is already running in another harness, OpenCode needs its own install.
Update procedures differ. Some harnesses have dedicated update commands, such as devin plugins update superpowers and gemini extensions update superpowers. Antigravity updates by re-running the same install command. For the rest, the original doesn't specify.
Network access. Install commands pull from GitHub or from each harness's plugin marketplace. In mainland China this may require a mirror or accelerated download. The Chinese guide flags this; the original does not, for obvious reasons.

On requirements, the original is silent about operating system, hardware, and version. The only hard dependency is a supported harness. package.json lists the project version as 7.0.1.

Why a Chinese translation is worth the effort

The barrier here isn't the English language in the abstract. It's that this project's value is concentrated in behavioral nuance. "The agent steps back and asks what you're really trying to accomplish" is easy to translate. The reasoning behind it — why the spec is chunked, why the plan is written for a specific caricature of a junior engineer, why subagents review each other — is where readers decide whether to trust the methodology.

Chinese-speaking developers are a large share of the audience for coding agents, and the harness list already includes Qwen Code and Kimi Code. A translated README with a practical entry point lowers the cost of evaluating the project from "read a long English document and hope the install section makes sense" to "run two commands and see what happens."

That's the honest value proposition. Not that the translation is better than the original, but that it removes a step between curiosity and a working install.

A reasonable way to evaluate it

Don't judge Superpowers by whether the agent writes code faster. Judge it by whether the agent asks better questions before writing anything.

A small experiment: give your agent a feature request with a deliberate ambiguity in it — an unstated constraint, an unclear scope boundary. Run it once without Superpowers and once with. Watch whether the second run surfaces the ambiguity or silently picks an interpretation. My sample here is one project, so this may not hold for you, but the difference tends to be visible on the first try.

If the agent does pause and ask, the methodology is doing its job. If it doesn't, check that the skills actually loaded for your harness — the per-harness install requirement is the usual culprit.

DeepTutor: A Chinese Translation of the HKUDS Tutoring Agent, and What It Actually Saves You

sun young — Thu, 29 Oct 2026 12:36:23 +0000

The original README for HKUDS/DeepTutor is long. Long enough that a reader whose English is serviceable but not fast will bounce off it before reaching the install steps. That is the problem the Chinese translation at yangshun2005/DeepTutor-cn tries to solve, and it is a narrower problem than "make the project accessible" — worth being precise about.

The original project: 48925 stars, written in Python, Apache-2.0 licensed. Topics listed are ai-agents, ai-tutor, clawbot, cli-tool, deepresearch. Its own one-line description is "Lifelong Personalized Tutoring." The Chinese version was published today and has zero stars. Nothing in this article should be read as a claim that the translation has traction; it doesn't yet.

What the translation actually contains

The repository is structured around two distinct pieces of text, and the distinction matters:

A translated version of the original README (README_en.md holds the English original). The stated intent is fidelity to the source — "力求忠于原文."
A supplementary Chinese quick-start guide at the top of the page, explicitly marked as not part of the original document ("非原文内容"). Its purpose is to get you from zero to a running instance without reading the full README.

That second part is the interesting one. A pure translation of a 3000-line README still leaves you reading 3000 lines. The quick-start is a different artifact: a curated path through the project for someone who wants to evaluate it in fifteen minutes.

The translation is dated 2026-10-29. The README invites issues and PRs for inaccuracies, which is the right posture — translations of fast-moving projects rot quickly, and this one will too.

Why a Chinese README is worth more than it sounds

For a project like this, the documentation is not a wrapper around the code. It is where most of the design decisions live.

Look at the release history in the README. Between v1.6.3 and v1.7.0 the project shipped, among other things: a breaking frontend/backend refactor, learner and guardian accounts, bounded tutoring memory, resumable embedding checkpoints, a Mastery Path mode with gated tools, LightRAG character models, Kiwix archives, per-model API capability declarations, and a single exec tool unified across languages. Each of those is a paragraph or two in the changelog. Reading them in a second language, at speed, while also trying to understand the architecture, is where comprehension quietly fails.

The failure mode isn't total. You get the gist. But you miss the qualifiers — the "bounded" in bounded memory, the "gated" in gated tools, the "explicit" in explicit per-model capabilities. Those words carry the actual engineering constraints. A reader working in a second language tends to skim past them and then wonder why the system behaves unexpectedly.

The Chinese version's value is concentrated here: it lets a Chinese-speaking developer read the constraints at full resolution instead of at 70%.

The quick-start path

The supplementary guide states the Python requirement plainly: 3.11 or above, per pyproject.toml (>=3.11). That is the first thing to check, and it is the kind of detail that gets buried in an English README's prerequisites section.

The original README's own navigation reflects the project's shape:

功能特性 · 快速开始 · 探索 DeepTutor · CLI · 生态 · 社区

In English: features, quick start, exploring DeepTutor, CLI, ecosystem (EduHub and a skills community), community.

That ordering is informative. The CLI section gets its own top-level slot — the README labels it "agent 原生接口," agent-native interface. If you are coming from a web-app mental model, that is the part to read first, because it tells you what the system considers its primary surface.

What the project is, structurally

From the README and the pyproject.toml description, DeepTutor describes itself as an agent-native personalized learning companion with multi-agent collaboration and RAG. The pieces it integrates into a single learning workspace:

Document parsing
Knowledge base retrieval
Practice and assessment
Voice and video reading

That is a wide surface. The changelog confirms the width — releases mention exercise generation from original sources, question banks, reading folders with in-chat selection actions, paginated Office previews, chart images sent to vision models, native Gemini voice, Polish/German/French/Ukrainian interfaces, and a research toolset.

A project this broad has a real onboarding cost, and documentation is the main lever on that cost. This is the argument for the translation, and it is a modest argument, not a dramatic one. It removes a language tax. It does not remove the complexity.

Reading the changelog as a design document

One practical suggestion for anyone evaluating DeepTutor through the Chinese version: read the release notes before the feature list.

The v1.6.7 entry is a list of fixes — whole books collapsing into empty chapters, quizzes producing no output, model drafts leaking into body text, formulas printing as raw source, unsubmittable cards. v1.6.6 mentions unsubmittable answers, a copy button that lied, Docker-internal Codex login, and a 100 KB reduction on the homepage route.

These are not marketing entries. They tell you what breaks under load and what the maintainers prioritize. A translated changelog is arguably more useful than a translated feature list, because feature lists translate cleanly (the nouns survive) while bug descriptions carry the specific texture of what went wrong.

Caveats

The translation is one day old. Expect drift: the original ships releases at a pace of roughly one every few days based on the dates in the README (v1.6.3 through v1.7.0 span September 2 to October 28). The Chinese README will lag.

The quick-start is a supplement, not a substitute. If you hit something the guide doesn't cover, the English original is authoritative, and README_en.md is right there in the same repository.

And a translation is only as good as its review. The repository says as much. If you find a term rendered badly — "有界辅导记忆" for bounded tutoring memory is a reasonable choice, but reasonable choices are still choices — file an issue.

Where to look

Chinese version: https://github.com/yangshun2005/DeepTutor-cn
Original: https://github.com/HKUDS/DeepTutor
Project site: https://deeptutor.info/

If you are a Chinese-speaking developer who has been putting off trying DeepTutor because the README is a wall of English, the translation removes that specific excuse. The rest of the work — Python 3.11, the CLI, the knowledge base setup — is unchanged, and no translation makes it smaller.

Chinese documentation: https://github.com/yangshun2005/DeepTutor-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.

VoiceStudio: A Chinese Translation That Lowers the Setup Barrier

sun young — Tue, 27 Oct 2026 12:51:11 +0000

VoiceStudio's README is long. It covers voice cloning, voice design, video dubbing, dictation, transcription, audiobook creation, 646 languages, several engine options, and a hardware matrix that changes depending on whether you're on an NVIDIA card, an Apple Silicon Mac, an Intel Mac, or Windows on ARM. For a Chinese-speaking developer who just wants to hear the thing generate one sentence, that's a lot of English to read before the first curl.

The Chinese version of the project — yangshun2005/VoiceStudio-cn — addresses exactly that. It is a translation of debpalash/VoiceStudio, which has 90387 stars and is written primarily in Python. The translation was published on 2026-10-27 and is licensed AGPL-3.0, matching the original.

One thing worth stating up front so there's no confusion: the Chinese repository is brand new. It has no stars to speak of. The 90387 figure belongs to the original project, and every number in this article that refers to popularity refers to that original repo.

What the Chinese repo actually contains

It's not a fork with modified code. It's a documentation layer, and it's split into two clearly separated parts:

A translated README (README_en.md holds the original English). The translation aims to stay faithful to the source text.
A "中文快速上手" section at the top that is explicitly marked as supplementary material, not part of the original. Its stated purpose is to let you get the project running without reading the whole README first.

That distinction matters. If you're trying to understand what an engine does or how a feature is specified, read the translated body. If you're trying to get from zero to a generated audio file, read the quick-start block. The repo says so itself, and it invites issues or PRs where the translation is inaccurate.

The quick-start path, in Chinese

The most useful part of the translation for a first-time user is the condensed install sequence. On macOS or Linux:

curl -fsSL https://voicestudio.sh/install | sh

On Windows, in PowerShell:

irm https://voicestudio.sh/install.ps1 | iex

The Chinese guide adds a fallback the English README also mentions but which is easy to miss: if voicestudio.sh/install is unreachable or returns a 404, run the script from the repository instead.

curl -fsSL https://raw.githubusercontent.com/debpalash/VoiceStudio/main/scripts/install.sh | sh

There's also the direct-download route. Releases ship per-platform packages — .dmg for macOS, .exe for Windows, .AppImage and .deb for Linux, .apk for Android, .ipa for iPhone — and Linux users can install via sudo snap install voicestudio.

Once the app is open, the first-run flow is: go to Voice cloning, pick an existing voice or add a clean reference recording, type your text, generate. When prompted, install the models it asks for.

The hardware table is where people get stuck

This is the section I'd point a Chinese-speaking colleague to first, because the failure modes are non-obvious and they're all hardware-related.

NVIDIA GPU on Windows or Linux: CUDA acceleration.
Apple Silicon (M1–M5): Metal (MPS) acceleration.
AMD Radeon and some Ryzen AI on Windows: CPU by default, with an optional Windows ROCm configuration.
No discrete GPU: runs entirely on CPU, but slower. The installer pulls a small CPU build of PyTorch and needs roughly 5 GB of free disk.
Intel Mac: UI only. You need a remote backend; local inference isn't available.
Windows on ARM: experimental, CPU only.

Two of those deserve emphasis. An Intel Mac cannot run the backend locally at all — that's not a performance caveat, it's a hard limitation. And "runs on CPU" is not the same as "runs well on CPU," which the original README is honest about.

The translated guide also flags something the English text doesn't foreground: the install script and release packages are pulled from voicestudio.sh and GitHub, so users on mainland Chinese networks may need their own acceleration or mirroring. The translation notes that the original provides no specific mirror sources. That's an accurate hedge rather than a fabricated workaround.

Dependencies, in one place

The translation consolidates the requirements that are otherwise scattered:

Python >= 3.11 per pyproject.toml.
Release downloads need curl and a SHA-256 tool.
Building from --main additionally needs Git, Node.js 22+, Bun, Rust/Cargo, and platform build tools.

If you're only installing a release, the second and third bullets mostly don't apply to you. If you're building from source, all of them do.

Licensing

AGPL-3.0. The Chinese guide states plainly that closed-source commercial use requires a separate commercial license, and points to hi@voicestudio.sh as the contact mentioned in the original. If you're evaluating VoiceStudio for anything commercial, read the license before you build a workflow around it. This is the kind of detail that's easy to skim past in a second language.

Why a translation is worth having here

VoiceStudio's stated scope is broad: voice cloning, voice design, video dubbing, dictation, transcription, audiobook creation, across 646 languages, with k2-fsa/OmniVoice as the default engine and other engines selectable. The original description frames it as an open-source, fully-local alternative to ElevenLabs, with local workflows running on your own hardware and remote services optional.

That breadth is the reason the documentation is long, and the reason translation helps. A developer deciding whether to invest an afternoon in setup needs to answer specific questions fast: does my GPU qualify, which install path applies to my OS, what happens on an Intel Mac, what does the license permit. Those answers exist in the English README, but they're spread across a feature catalog, an engine guide, and a hardware matrix. Having them pre-digested in your first language shortens the time between "this looks interesting" and "it's running."

The translation is also honest about its own limits. It marks the quick-start as supplementary, keeps the original English available as README_en.md, and asks for corrections. That's the right posture for a translated technical document — the source of truth stays visible.

What it doesn't do

It doesn't change the code, add mirrors, or fix the Intel Mac limitation. It won't make CPU inference fast. If your network can't reach voicestudio.sh or GitHub, the translation tells you that's a known gap rather than pretending otherwise. And it won't help you if you don't read Chinese — the original repo remains the place to go.

My own read is that the highest-value audience here is Chinese-speaking developers who already know they want a local TTS stack and just need the setup details without a translation detour. If that's you, start with the quick-start block, then check the hardware table against your machine before you commit the disk space. If your machine is an Intel Mac, check it before you commit anything at all.

Chinese documentation: https://github.com/yangshun2005/VoiceStudio-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.

TradingAgents: A Chinese Translation of the Multi-Agent LLM Trading Framework

sun young — Tue, 27 Oct 2026 10:57:56 +0000

The original TradingAgents repository has 116882 stars. That number is the first thing most people see, and it is also the least interesting thing about the project. What matters more for a developer trying to read the code is that the documentation is in English, and the framework itself is a fairly dense multi-agent system with a lot of moving parts.

A Chinese translation of the repository now exists: yangshun2005/TradingAgents-cn. It is a translation of TauricResearch/TradingAgents, released today. It has no stars yet. This article is about what the project is, what the translation adds, and where the documentation still stops short.

What TradingAgents actually is

The official one-line description is "Multi-Agents LLM Financial Trading Framework." In practice, the framework assigns different roles to LLM-driven agents and lets them discuss a market situation before producing a decision. The roles named in the translated README include a fundamentals analyst, a sentiment specialist, a technical analyst, a trader, and a risk management team.

The structure is meant to mirror how a real trading desk divides labor. Each agent looks at a different slice of the problem, and the discussion between agents is part of the mechanism, not an afterthought. The project is written in Python and licensed under Apache-2.0.

If you want to read the source, the language is not a barrier. If you want to understand the design decisions, the release history, and the data-handling rules, the documentation is where the friction lives.

What the Chinese version adds

The translation is faithful to the original README, and it says so explicitly. The translated body is marked as a translation of the original document. On top of that, the maintainer added a section labeled "中文快速上手" (Chinese quick start), which is clearly marked as supplementary material, not part of the original.

That distinction is worth noting because it is easy to blur. The quick-start section is the part that lowers the barrier for Chinese-speaking developers. It answers questions the original README does not answer in its opening pages: what Python version do I need, how do I install it, what command do I run.

The translation date is recorded as 2026-10-27, and the original English README is kept in the repository as README_en.md. If you suspect a translation error, you can check the source directly. The maintainer invites issues and pull requests for inaccuracies.

Getting it running

The quick-start section is short and concrete. The minimum Python version is 3.11, taken from requires-python in pyproject.toml.

Install the project and its dependencies from the repository root:

pip install .

The README notes that requirements.txt is equivalent to pip install ., so either path works.

If you need Amazon Bedrock support, install the optional dependency instead:

pip install "tradingagents[bedrock]"

The core install does not include langchain-aws. That is a common trip-up: if you configure Bedrock and the import fails, you installed the wrong variant.

After installation, a command-line entry point named tradingagents is registered via [project.scripts] in pyproject.toml:

tradingagents

There is also a Docker path. The repository root contains a Dockerfile and a docker-compose.yml, and the image entry point is tradingagents. The translation does not spell out the exact startup command for Docker, and it says as much rather than inventing one.

Dependencies and environment

The core dependencies listed in pyproject.toml include:

langchain-core
langchain-openai
langchain-anthropic
langchain-google-genai
langgraph
pandas
yfinance
typer
rich

Bedrock support is the optional langchain-aws extra. The Dockerfile is based on python:3.13-slim, which is Debian-family Linux. The README does not list supported operating systems or hardware requirements, and the translation does not fill those gaps.

One practical note the translation includes: dependencies come from PyPI, so users in mainland China may need a mirror or a proxy. The project mentions proxy support, but the exact configuration is not documented in the excerpt available.

The LLM key problem

The framework is driven by LLMs, so you need API keys for whichever provider you use. The material mentions API-key auto-detection and multiple provider support, along with TRADINGAGENTS_* environment variables. The specific variable names are not spelled out in the available excerpt.

This is the most likely place for a first run to fail. Prepare your keys before you run tradingagents, and expect to consult the full README body and CHANGELOG.md for the details the quick start does not cover.

Reading the release history

The translated README includes the news section, and it is more useful than it looks. Several releases in 2026 changed behavior in ways that affect how you interpret results.

Version 0.7.1 scores decisions only at the final closing price and settles across long holidays. It also fixed a bug where the model could read files committed after the run date. Version 0.7.0 added the ability to run on your own ChatGPT Plus or Pro plan, changed backtesting to score from the first close after each decision, added a new-version prompt at startup, and began shipping a wheel with each GitHub release.

Version 0.6.0 saves reports as a single HTML page, allows per-tier provider configuration so managers and analysts can run on different models, settles historical decisions per ticker while analysts work, and reads company news from Yahoo search when the Yahoo news feed is down.

Earlier releases in September and August 2026 dealt with point-in-time integrity across dated paths, SEC EDGAR fundamentals, backtesting over grids of tickers and dates, portfolio-aware runs, and look-ahead issues in FRED macro data, social sentiment, and decision-log memory.

If you are evaluating the framework for research, the point-in-time work is the part to read closely. A backtest that can see data published after the analysis date is not a backtest.

Where the translation stops

The translated README body is truncated after the "TradingAgents Framework" introduction. The full Installation and CLI sections are not included in the available material. The translation says this directly rather than guessing.

So the quick-start section gets you to a running command, but the finer configuration steps — CLI flags, provider setup, environment variable names — are not covered. For those, the translation points you to the repository README body and CHANGELOG.md.

That is the honest state of the documentation. A translation is not a rewrite, and the maintainer did not pretend otherwise.

Who this is for

If you read English documentation comfortably, the translation adds little beyond the quick-start section. The original repository is the canonical source, and it will always be more current.

If you are a Chinese-speaking developer who wants to understand the agent roles, the release history, and the data-integrity decisions without translating in your head, the translation is a reasonable starting point. The quick-start section in particular saves you from reading the whole README just to get the install right.

The star count belongs to the original project. The translation is new, and its quality will be judged by whether the issues and pull requests it invites actually get addressed.

Repository: yangshun2005/TradingAgents-cn
Original: TauricResearch/TradingAgents

Chinese documentation: https://github.com/yangshun2005/TradingAgents-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.

OpenShell: NVIDIA's Sandboxed Runtime for AI Agents Now Has a Chinese README

sun young — Sun, 25 Oct 2026 10:28:53 +0000

OpenShell's install command is one line, but the README that follows it is not. NVIDIA's project ships a fair amount of documentation: policy semantics, a formal verification step, a gateway/supervisor/sandbox architecture, and a support matrix that rules out a good chunk of machines people will try it on. For a Chinese-speaking developer evaluating whether to spend an afternoon on it, that's a real cost before the first openshell sandbox create ever runs.

A translated version of the repository now exists at yangshun2005/OpenShell-cn. It is a documentation translation, not a fork of the code. The original is NVIDIA/OpenShell, 19,704 stars, written in Rust, Apache-2.0.

Below is what the project actually does, what the Chinese version adds, and the parts of the setup that tend to go wrong.

What OpenShell is for

The one-line description NVIDIA uses is "the safe, private runtime for autonomous AI agents." The longer version: agents are most useful when they can read files, install packages, call APIs, and use credentials. Those are also the four things you least want an unsupervised process doing on your machine.

OpenShell's answer is not to remove the capabilities but to declare them. You write a policy describing what each agent may touch, and the runtime enforces it. Two mechanisms do the work:

Kernel-level enforcement. Each agent runs in an isolated sandbox. The kernel is instrumented so that every file access, every syscall, and every outbound network connection is checked against policy. Credentials never reach the agent directly — OpenShell injects them into requests headed to approved endpoints only.
Formal verification of policy changes. Before a policy change takes effect, OpenShell checks what new access it would grant. If a change would let an agent use a credential against a new host, or call a new API method, it gets flagged and waits for human review.

That second point is the interesting design choice. Most sandboxing tools treat policy as configuration you edit and reload. OpenShell treats a policy diff as something to be analyzed, which is a different threat model — it assumes the person editing the policy might be an agent, or might be acting on an agent's suggestion.

Getting it running

The quick start is two commands, and the first one needs a working container or virtualization backend already in place:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

The installer sets up both the CLI and a local gateway.

Platform requirements

This is where people lose time, so it's worth listing plainly:

OS: Linux, macOS on Apple Silicon, or Windows with WSL 2 (experimental).
Runtime dependency: Docker, Podman, or host virtualization — one of the three, already installed.
Linux: the install script pulls a Debian or RPM package. The script states a minimum glibc of 2.28.
macOS: Apple Silicon only. Installed via a Homebrew formula, which manages the binary layout and the launchd service lifecycle.
Python SDK: Python >= 3.11 (per pyproject.toml).
Building from source: the workspace declares rust-version = "1.94" and edition = "2024" in Cargo.toml.

Windows support being labeled experimental is not boilerplate. If you're on an Intel Mac, you're out — there's no path in the support matrix for you.

The default sandbox has no agent in it

openshell sandbox create --name demo gives you a minimal Ubuntu image. No agent is installed. This surprises people who expect the demo to do something agent-like out of the box.

To run an actual agent, the official docs point at Run Your First Agent, which wires OpenCode to a free OpenRouter model and walks through the approval flow when the agent requests new access. That approval flow is the part worth reading carefully — it's the human-in-the-loop side of the formal verification described above.

There's also an optional step for coding agents that support skills:

npx skills add NVIDIA/OpenShell

Telemetry is on by default

Worth stating up front rather than burying. OpenShell collects anonymous telemetry. Per the documentation, it's limited to operational categories and counts — no sandbox names, hostnames, file paths, prompts, or credentials.

To turn it off:

# on the gateway
OPENSHELL_TELEMETRY_ENABLED=false

For Helm installs, set server.telemetryEnabled=false instead.

The docs also recommend keeping the SDK and gateway on the same OpenShell version. Version skew between the two is the kind of thing that produces confusing failures rather than clean errors.

What the Chinese version actually contains

The repository at yangshun2005/OpenShell-cn is structured in two layers, and the split matters.

Layer one: a Chinese quick-start guide written for this translation. This is explicitly marked as supplementary material, not part of the original README. It covers:

What the project is and what problem it solves, in a few paragraphs
The shortest path to a running sandbox
The full environment requirements list, including the glibc, Rust, and Python version floors
A "common pitfalls" section

That pitfalls section is the most useful part, because it collects the failure modes that are scattered across the upstream docs: the empty default sandbox, the Apple Silicon restriction, the mandatory container backend, telemetry defaults, and SDK/gateway version alignment.

Layer two: a translation of the upstream README itself. The stated goal is fidelity to the original. The translation date is recorded as 2026-10-25, and the original English README is kept alongside as README_en.md so you can diff them.

The repository explicitly invites issues and PRs for inaccurate translations. Given that OpenShell is at 0.1.x with a stated cadence of stable releases, the English docs will move; a translation will always lag somewhat. My sample of one reading suggests the quick-start layer is the more durable part, since it describes requirements and pitfalls rather than API surface.

Where the translation helps, concretely

Three places, I think.

Version floors. "glibc 2.28", "rust-version = "1.94"", "Python >= 3.11" — these are easy to skim past in a long English README and expensive to discover after a failed build. Having them collected in one place in your first language reduces the chance you start an install that can't succeed.

The gap between "installed" and "working." The upstream quick start is honest that the default sandbox is bare, but that fact sits in a paragraph after the commands. The Chinese guide puts it in the pitfalls list, which is where people look when the demo doesn't behave as expected.

Policy semantics. This is the part I'd want translated most carefully, because policy is where the project's whole value proposition lives. Getting the enforcement model wrong — assuming policy is advisory, or that credentials are visible to the agent — leads to a very different mental model of what you've deployed. The translated README covers the enforcement and verification mechanisms directly.

What it doesn't do

It doesn't change the software. If you're building against OpenShell, you're building against NVIDIA's code, and the translated repo is a reading aid. Bug reports and feature requests belong upstream.

It also doesn't solve the network problem. The install script downloads release artifacts from GitHub, and the translation notes that users in mainland China may need a proxy or an accelerated download path. The original documentation doesn't provide a mirror, and neither does the translation — it just flags the issue so you're not debugging a timeout wondering whether the script is broken.

Should you read it

If you already read English technical documentation comfortably, the upstream README is fine and always current. The Chinese version earns its place for two groups: developers who'd rather absorb the requirements and pitfalls in Chinese before committing an afternoon, and teams where the person evaluating the runtime isn't the person who'll operate it — handing over a translated quick-start is cheaper than a meeting.

The project is Apache-2.0, so the licensing question is settled either way. Start with the quick-start layer, then read the translated README for the policy model, then go upstream for anything version-specific.

Chinese documentation: https://github.com/yangshun2005/OpenShell-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.

security-audit-skill: a Chinese translation of Cloudflare's coding-agent audit skill

sun young — Sun, 25 Oct 2026 10:21:45 +0000

Cloudflare's security-audit-skill has 45,592 stars on GitHub. The Chinese translation was published today and has zero. That gap is the whole reason the translation exists — not because the original is hard to read for everyone, but because a security workflow is one of the few things where misreading a sentence changes what you actually run.

The Chinese version lives at yangshun2005/security-audit-skill-cn. It is a translation of cloudflare/security-audit-skill, MIT licensed, original language JavaScript, translation dated 2026-10-25. The original README is kept as README_en.md so you can diff the two.

What the skill actually does

It turns a coding agent into a security auditor. Not by prompting "find bugs" harder, but by forcing a six-phase process where different agents do different jobs and the one who finds a candidate is not the one who confirms it.

The six phases, as listed in the README:

Reconnaissance — map architecture, trust boundaries, input surfaces, existing evidence, and deterministic coverage into architecture.md and coverage-ledger.json.
Coverage-driven hunting — assign isolated hunters from ledger units, record what they checked, and use a coverage reviewer to find gaps.
Candidate validation — hand each unique candidate to a fresh validator whose job is to falsify it.
Structured output — write confirmed, needs_validation, and rejected records to findings.json, validated against report-schema.json.
Independent record verification — a fresh agent verifies final source claims. Substantive replacements go through another independent validator.
Target-neutral reporting — generate REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md from verified records and the coverage ledger.

The three verdicts are deliberately distinct. confirmed means full source tracing plus bounded observation. needs_validation means there is a specific unresolved fact and no severity assigned. rejected records a candidate that was disproven. That last one matters — a rejected candidate is data, not noise, because it tells the next run what not to re-hunt.

Two Node scripts enforce the shape of the output. The parent runs validate-coverage-ledger.cjs after creating the ledger and after every update to it. validate-findings.cjs runs in phase 4, and again in phase 5 after each replacement.

Why a Chinese version is worth more than the usual translation

Most translated READMEs are a convenience. This one is closer to a prerequisite, for three reasons.

The sandbox requirement is a hard gate, and it's easy to skim past. The skill needs an OS-enforced sandbox to run builds, tests, processes, browsers, emulators, fuzzers, and fixtures against the target code. That sandbox must have external network disabled, a sanitized allowlist environment, enforced resource limits, and write access only to designated temp paths. Without those controls, the workflow keeps the relevant leads at needs_validation instead of executing target code. A reader who half-understands this will run the skill, get a shallow audit, and conclude the tool doesn't work. The Chinese quick-start section states this plainly as a "常见坑" — a common pitfall — before you get to the workflow.

The default output path is not obvious. In full audit mode, if you don't specify an output directory, results go to ~/security-audit-skill/ /run- (that spacing appears in the source). The workflow only writes inside the target repo when you explicitly pick a directory that version control ignores. If you're auditing a repo you care about, getting this wrong is annoying at best.

One run does not cover everything. The original README states that a single run finds roughly half of the vulnerabilities that repeated runs find in total. Runs are additive. The recommendation is to run the skill multiple times against the same repository. Someone who reads this as "run once, get a report" will under-audit and never know.

None of these are translation problems in the sense of wrong words. They're the kind of detail that gets lost when you're reading a long English document in a second language and pattern-matching for the install command.

Installing

The command is unchanged from the original:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

For a user-level install, add --global:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

Note that this pulls from the upstream repo, not the translation. The Chinese repo is documentation — the skill itself is the same code. npx skills --help covers agent selection and non-interactive options.

Then open or point your coding agent at the codebase and ask:

security audit this codebase

Or with a target and output location:

find security vulnerabilities in ./src

do a security review, output to ~/audits/my-project

The skill activates on trigger phrases like "security audit", "find vulnerabilities", and "pen-test the code".

If you're on a network where GitHub fetches are slow, the Chinese README flags this directly: you may need an npm mirror or a proxy for the npx skills add step. Small thing, but it's the first thing that fails.

Requirements, including the ones the README doesn't answer

Confirmed dependencies:

A coding agent and model that support tool use and parallel sub-agents.
Node.js, for the zero-dependency findings and coverage-ledger validation scripts.

The parallel sub-agent requirement is structural, not cosmetic. The design depends on isolated agents doing separated work — hunters, a coverage reviewer, fresh validators, an independent record verifier. If your agent or model can't spawn parallel sub-agents, the workflow can't run as designed. The README does not describe a fallback.

Things the original README does not specify, and the translation honestly leaves as "原文未说明" rather than inventing answers: supported operating systems, hardware requirements, and the specific Node.js version. If you need those, you'll have to determine them yourself. I'd rather see a translation that admits the gap than one that fills it in.

What the file layout tells you

The skill is split across files by phase, which is a decent signal of how much process is packed in:

File	Purpose
`SKILL.md`	Setup, core principles, platform terminology, workflow overview, audit anti-patterns
`RECONNAISSANCE.md`	Phase 1 recon prompts and synthesis instructions
`HUNTING.md`	Phase 2 orchestration, hunting methods, validation rules
`ATTACK-CLASSES.md`	Attack prompts for core, wildcard, and obvious-issue categories
`MEMORY-SAFETY-AND-BINARY.md`	Memory safety, binary, and kernel work for native targets

The existence of MEMORY-SAFETY-AND-BINARY.md is worth noticing. This is not only a web-app scanner. It has guidance for native targets.

Provenance

The skill is the single-repository starting point of Cloudflare's vulnerability discovery framework, described in their post Build your own vulnerability harness. That framework later grew into a multi-stage, fleet-wide system. What you install here is the origin version, not the fleet version. Worth knowing before you compare it to anything Cloudflare has written about at scale.

On the translation itself

The repo is structured so you can check the work. The Chinese page opens with a "中文快速上手" section that is explicitly marked as supplementary guidance, not part of the original document — it covers what the project is, the shortest install path, environment requirements, and the pitfalls above. Below that, the README body is a translation that aims to stay faithful to the original. The English original sits alongside as README_en.md.

That separation is the right call. A translation that quietly blends a translator's opinions into the source text is worse than no translation, because you can't tell which claims are the project's. Here the boundary is stated on the page.

The repo also asks for issues and PRs on inaccurate translations, which is the only realistic way this gets better. My sample of one reading is not a review; if you find a phase description that reads wrong against the English, that's a bug worth filing.

Who this is for

If you already read English technical documentation comfortably, use the upstream repo — it will always be current, and the translation is dated 2026-10-25, so it will drift. If you or your team would otherwise skim the sandbox and multi-run caveats, the Chinese version is the difference between running this skill correctly and running it once, getting a thin report, and moving on.

The star count on the translation is zero. That's fine. The thing it translates has 45,592, and the value here is comprehension, not popularity.

Chinese documentation: https://github.com/yangshun2005/security-audit-skill-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.

DEV Community: sun young

auto-ontology: A Chinese Translation of NVIDIA's Context Layer for Agents

What the service is

The comparison that matters

Quickstart, as documented

Requirements

What the Chinese version adds

How the pieces fit

Evaluation

Who this is for

agent-desktop: A Chinese Translation of Vercel Labs' Accessibility-Tree CLI for AI Agents

What the tool is, and what it deliberately isn't

The ref model

Installation paths

Failure modes worth knowing before you write the loop

What the Chinese version adds

Where this fits

t3code: a Chinese translation of the agent harness control panel, and what it actually gets you

What T3 Code is, precisely

Why the translation matters more than it sounds

The shortest path to a running instance

The network caveat the original doesn't discuss

What the translation does not claim

Who this is for

Claude-Code-Game-Studios: A Chinese Translation for Claude Code's 49-Agent Game Studio

What the project actually is

The three-layer hierarchy

Getting a session running

Why the Chinese version is worth having

What it produces

A note on the numbers

Repository

claude-mem: a Chinese translation of the persistent-memory layer for Claude Code

What the project actually does

Install path

The parts that will bite you

Why a Chinese translation is more than a convenience

What the translation doesn't solve

Should you try it

browser: A Chinese Translation of Lightpanda, the Zig Headless Browser for AI Agents

What the Chinese repository actually contains

The quick start, condensed

Why a Chinese quick-start layer is not just a nicety

What the translation does not claim

Where this fits

superpowers: a Chinese translation of the 307,936-star agent skills framework

What the project actually does

The Chinese version: what's different

Installation, and why it's the main friction point

Pitfalls worth knowing before you start

Why a Chinese translation is worth the effort

A reasonable way to evaluate it

Links

DeepTutor: A Chinese Translation of the HKUDS Tutoring Agent, and What It Actually Saves You

What the translation actually contains

Why a Chinese README is worth more than it sounds

The quick-start path

What the project is, structurally

Reading the changelog as a design document

Caveats

Where to look

VoiceStudio: A Chinese Translation That Lowers the Setup Barrier

What the Chinese repo actually contains

The quick-start path, in Chinese

The hardware table is where people get stuck

Dependencies, in one place

Licensing

Why a translation is worth having here

What it doesn't do

TradingAgents: A Chinese Translation of the Multi-Agent LLM Trading Framework

What TradingAgents actually is

What the Chinese version adds

Getting it running

Dependencies and environment

The LLM key problem

Reading the release history

Where the translation stops

Who this is for

OpenShell: NVIDIA's Sandboxed Runtime for AI Agents Now Has a Chinese README

What OpenShell is for