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

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

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

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

Two layers in the Chinese repo

The project explicitly separates them:

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

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

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

What FrontierAgent actually is

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

The TUI ships two native workflows:

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

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

The pieces worth knowing about

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

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

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

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

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

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

Getting it running

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

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

Then fill in .env:

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

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

Environment details

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

Traps the Chinese docs call out

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

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

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

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

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

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

Why the Chinese version is worth having

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

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

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

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

---

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

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