Build an AI Coding Agent From Scratch: Connecting Chinese LLMs and Automating Workflows

0. The Three Building Blocks of Automation: Information, Interface, and Devices

How far an agent can automate depends first on what it can “see” and what it can “touch”. However capable the model is, if it can rely only on training data it cannot answer questions about what is “latest” or happening “right now”; if it can only read files, it cannot verify how a page actually behaves or what happens on a real device. So before building any AI coding agent, take inventory of its senses and its hands and feet.

Layer	Capability	Common implementation	Impact when missing
Information layer	Web search, page fetching	Built-in web retrieval in the agent, web search and page-reading context services, search tool services	Can only rely on training data; cannot answer time-sensitive questions
Interface layer	Opening pages, clicking, filling forms, screenshots	Browser automation context services	Cannot operate web systems without an API; end-to-end verification breaks
Usable layer	Installing, launching, tapping, reading logs	Device debugging context services	Cannot verify real-device behavior; the mobile chain breaks

The source material calls the third layer the “device layer”; this article uses “usable layer” to avoid confusion with the literal meaning of “device”. Together the three layers form a complete closed loop:

Agent (planning and decision-making)
   │ instructions
   ├─ search / fetch ──────→ latest information and docs
   ├─ browser operations ──→ page state, screenshots, console logs
   └─ device debugging ────→ install & launch, view hierarchy, runtime logs
   ↑                                      │
   └────────── execution results fed back ←┘

The loop can be summarized as “observe — plan — act — verify — correct”: the model feeds execution results back into its context, judges whether the goal was met, and decides the next step. A coding agent does not “see” the world directly; it wraps each layer of capability into a callable tool. The more complete the tools and the more precise the feedback, the higher the share of tasks it can complete autonomously.

1. Installing the Agent CLI: Putting an Agent Into Your Terminal

The mainstream approach is an agentic coding tool that runs directly in the terminal (referred to below as the “agent CLI”). It can read and write code repositories, execute commands, and call external tools — currently the lowest-cost option to adopt and the one most tightly integrated with the development workflow.

1.1 Prerequisites

• Terminal and operating system: Works on mainstream desktop operating systems. On Windows, use the official Linux compatibility layer to get a consistent scripting and toolchain experience.
• Runtime environment: These tools are usually distributed as JavaScript runtime packages, so confirm the runtime version meets the requirements before installing.
• Version management: Pin the runtime version with a version manager to avoid behavioral differences between machines and between teammates.
• Base toolchain: Version control, build tools, and package managers must be in place first, otherwise the agent cannot complete the “change code — run tests — read results” loop.
• Network: The model service must be reachable, and you may need to configure a proxy specifically for the CLI.

1.2 Installation Options and Caveats

# Option 1: global install via a package manager (package name per official docs)
npm install -g <agent-cli-package>
# Option 2: download and review the official install script before running it
curl -fsSL <official-install-script-url> -o install.sh
less install.sh        # confirm what the script does, then run it
sh install.sh
# Option 3: containerized run, isolating the filesystem and dependencies
docker run --rm -it \
  -v "$PWD:/workspace" -w /workspace \
  <agent-cli-image> <agent-cli-command>

Each option has trade-offs. The package manager is the lightest; the install script handles the runtime setup for you; containers isolate dependencies and permissions but you must make sure the agent’s tool calls remain reachable and that file mounts are set up correctly. If you use a mirror source, replace only the download address, and verify file integrity and origin with a checksum.

1.3 Post-Install Self-Check

agent-cli --version                 # show the version
agent-cli --help                    # list available commands and options
agent-cli doctor                    # one-shot environment check, if provided
agent-cli -p "Explain an idempotent API in one sentence"   # non-interactive connectivity check

A self-check should cover at least four things: the version matches expectations; help output works; the model responds; and the current directory is correctly recognized as the workspace.

2. Connecting Chinese Models: Direct, Routing, and Aggregation

2.1 What Connecting Actually Means: Swapping the Inference Backend

The capability of an agent CLI comes from two parts: the orchestration layer, which handles tool calling, context management, and permission control, and the inference layer, which understands instructions and produces solutions. Connecting a Chinese model means replacing the inference layer with a Chinese LLM service.

Most Chinese model providers expose HTTP APIs authenticated with an API key, typically serving chat completion requests under a /v1/chat/completions-style path. As long as the model supports tool calling, most agent CLIs can be connected by replacing the endpoint URL, the key, and the model name.

Confirm three capabilities before switching:

1. API compatibility: Does it follow the mainstream chat completion API convention?
2. Tool calling: Can it reliably return structured function call requests? This is a prerequisite for the agent to call external tools.
3. Context window: How much input can it hold? This directly affects large codebase analysis and reading long files.

Check the actual capabilities in the model provider’s official documentation, and do not copy someone else’s configuration blindly.

2.2 Preparation: Key Management and Layered Configuration

# Recommended: inject via environment variables so keys never land in
# config files or the code repository
export AGENT_MODEL_BASE_URL="https://<model-endpoint-host>/v1"
export AGENT_MODEL_API_KEY="<your-api-key>"
export AGENT_MODEL_NAME="<model-name>"
# Specify a model temporarily for a single run
agent-cli --model "$AGENT_MODEL_NAME" -p "Check the test coverage of the current directory"

Configuration usually has three layers, in increasing priority:

• System / tool-level configuration: default model, theme, permission policy;
• User-level configuration: personal preferences and frequently used models;
• Project-level configuration: team-wide constraints, versioned together with the repository.

Three more points matter. First, keep keys only in environment variables, a credential manager, or CI secret variables, and add ignore rules so they are never committed by mistake. Second, for model services on an internal network, configure a dedicated proxy for the tool. Third, on Windows with the Linux compatibility layer, verify that environment variables are inherited correctly.

2.3 Mode 1: Direct Connection

The agent CLI sends requests straight to one model service with no intermediary.

When it fits: individual development, prototype validation, and cases where a single model already meets the need.

Advantages: shortest path, lowest latency, simplest to debug.

Limitations: changing models means editing configuration on every machine and in every project; there is no unified usage tracking or failover.

2.4 Mode 2: Routing

Insert a “model router” between the agent and the models. The router dispatches requests to different models based on task characteristics, codebase size, budget, and similar conditions. For example:

• Deep reasoning tasks such as architecture design and complex bug localization go to a model with stronger long-context reasoning;
• Mechanical tasks such as batch formatting and generating commit messages go to a lightweight model that is fast and cheap;
• Core code-generation work goes to the model with the strongest coding ability.

Routing can be handled on the tool side through multi-model configuration (for example, defining a “planning model” and an “execution model”), or by a gateway applying rules. The value of routing is allocating compute on demand, instead of spending every task on the strongest and most expensive model.

2.5 Mode 3: Aggregation

An aggregation layer exposes multiple model services through a single entry point and implements cross-cutting concerns — authentication, routing, retries, rate limiting, metering, and auditing — in one place. Developers only need to point the endpoint at the aggregation layer.

When it fits: unified team control, model failover, environment isolation, usage auditing, and cost control.

Advantages: models become pluggable, which makes side-by-side comparison and smooth migration easy.

Cost: one extra network hop and another service to operate.

2.6 Comparing the Three Modes and Choosing

Dimension	Direct	Routing	Aggregation
Path complexity	Low	Medium	High
Unified control	Weak	Medium	Strong
Model replaceability	Poor	Fair	Good
Failover	Manual	Rule-based	Automatic retry / fallback
Best for	Individuals	Small teams	Mid-size and large teams

A pragmatic evolution path: start with a direct connection to get the chain working; introduce routing once different tasks clearly need different models; add an aggregation layer when the team grows and needs unified auditing and cost control.

3. Instruction Files, Skill Packages, and Context Protocols: Turning the Tool Into a Workspace

An agent straight out of the box is only a generic assistant. To make it a workspace that understands your project, you need to accumulate three kinds of assets over time: a project-level instruction file, reusable skill packages, and external capabilities introduced through a context connection protocol.

3.1 Project-Level Instruction Files: Teaching the Agent Your Project

Maintain an instruction file in the repository root (give it whatever name the agent reads as context). It works like an onboarding handbook for a new team member. Recommended contents:

• Tech stack and versions: language versions, core frameworks, package manager;
• Directory conventions: what each directory is for and where new code goes;
• Common commands: install, build, test, lint, local startup;
• Coding standards: naming, comments, error handling, logging style;
• Prohibitions: files that must not change, commands that must not run, branches that must not be touched.

# Project Conventions
## Tech Stack
- Language and runtime version: <language-version>
- Package manager: <package-manager>
## Common Commands
- Install dependencies: `<install-cmd>`
- Run tests: `<test-cmd>`
- Lint: `<lint-cmd>`
- Start locally: `<dev-cmd>`
## Coding Standards
- Every function needs a doc comment describing purpose, parameters, and return value
- Errors must be raised as the project's custom exception types
- New dependencies need a stated reason; prefer actively maintained libraries
## Prohibitions
- Do not modify production config files under `config/`
- Do not run commands with data-deleting semantics
- Do not commit directly to the main branch

Three advanced techniques. First, use layering: a global file for personal preferences, project files for team conventions, subdirectory files for module-level rules. Second, use import statements to split coding standards and interface docs into separate files that are referenced on demand, keeping the main file lean. Third, agree on automatic maintenance rules so the agent checks and refreshes outdated content before every commit, keeping the file in sync with the code.

3.2 Skill Packages: Packaging Workflows as Reusable Capabilities

A skill package is a “capability bundle” organized around a class of task, typically containing documentation, executable scripts, and reference material. It works roughly like this:

1. On startup, the agent loads only the skill’s name and description;
2. When a user request matches the description, the full instructions are loaded;
3. If more detail is still needed, attachments are read on demand.

This on-demand loading keeps irrelevant content from crowding out the context window. Below is a sample structure for a code review skill package:

my-review-skill/
├── skill.md             # name, description, execution steps
├── scripts/
│   └── collect-diff.sh  # collect the scope of the current change
└── references/
    └── checklist.md     # team code review checklist

If the metadata in skill.md says “enable during code review and pre-commit checks”, the agent will pick it up automatically based on user intent. Teams can also accumulate common workflows into a shared skill library, so a workflow is written once and reused by everyone.

3.3 Context Connection Protocols: A Standard Interface to the Outside World

Context connection protocols (the widely adopted open specifications for exposing tools and data to models) let developers plug external systems into an agent in a uniform way. They generally provide three kinds of capability:

• Tools: functions the model can call, such as querying a database or calling an internal API;
• Resources: data the model can read, such as documents, configuration, and database schemas;
• Prompt templates: predefined prompt templates invoked explicitly by the user.

Take log querying as an example: a context server can expose a tool that “searches logs by service name and time range”. Once the agent retrieves the logs, it can reason over real errors instead of guessing.

{
  "servers": {
    "log-query": {
      "command": "<server-runtime>",
      "args": ["<path-to-server-entry>"],
      "env": { "LOG_ENDPOINT": "<log-service-endpoint>", "LOG_TOKEN": "<token>" }
    }
  }
}

The field names above are illustrative only; use the names documented for the tool you actually run.

Things to watch when connecting: the context server process runs on the local machine, so run it with least privilege; write-capable tools must require confirmation or be restricted to an allowlist; and timeouts, retries, and response sizes should all be bounded so they cannot stall the agent’s main loop.

4. High-Frequency Daily Operations and Commands

4.1 Common Built-In Commands

• /help: list commands;
• /clear: clear context, useful when switching tasks;
• /compact: compress conversation history while keeping key conclusions;
• /model: switch models;
• /cost: show usage and spend for the current session;
• /permissions: review and adjust tool permissions.

The context-related commands are the ones most worth turning into a habit. Long conversations keep accumulating history, which increases cost and can dilute the key information.

4.2 Custom Commands: Templating Repeated Instructions

Create a Markdown file named after the command in the commands directory, and a custom command appears. The file body is the prompt template, and it supports these placeholders:

• $ARGUMENTS: the arguments passed when the command is invoked;
• !`command` : run a command and embed its output in the prompt;
• @path: embed the contents of a file in the prompt.

# Command: pre-commit self-check
Run the following checks on the current changes:
1. Run `!<test-cmd>` and confirm all cases pass
2. Run `!<lint-cmd>` and fix the warnings
3. Generate a commit message following @docs/commit-guide.md
Arguments: $ARGUMENTS

4.3 Common Workflow Examples

• Understanding an unfamiliar codebase: have the agent produce a module map and call graph first, then drill into each part.
• Diagnosing a production bug: paste the error stack and relevant code, let it list likely causes and the steps to verify them.
• Bulk refactoring: state one rule plus the affected scope, have the agent execute in batches, and run tests after each batch.
• Code review: combine a custom command with a checklist to self-check before committing.
• Writing documentation: extract interface descriptions from code and comments to create or update docs.

5. Scheduling and Always-On: Loops and Non-Interactive Mode

5.1 Loops: Keeping the Agent Pushing a Task Forward

Some tools and community extensions provide a “loop” style command that repeats a task on a fixed interval. It suits monitoring build results, following up on dependency updates, and periodically inspecting code quality.

Set clear exit conditions when using it, for example: all tests pass, the PR is merged, or N consecutive runs show no change. Without one, the task can loop indefinitely and burn compute for nothing.

5.2 Non-Interactive Mode: Wiring the Agent Into Scripts and Pipelines

Beyond interactive sessions, agent CLIs usually offer a non-interactive mode: accept a prompt once, execute the task, print the result, and exit. This is the foundation for scheduled automation and CI/CD integration.

#!/usr/bin/env bash
set -euo pipefail
TASK_FILE="task.txt"
for i in $(seq 1 10); do
  PROMPT="Keep pushing the task forward and update the task file: $TASK_FILE
Current contents of the task file:
$(cat "$TASK_FILE")"
  # Pass the prompt on stdin; check the tool's docs for exact arguments
  OUTPUT=$(agent-cli -p < "$TASK_FILE" 2>&1 <<< "$PROMPT") || {
    echo "[$(date '+%F %T')] Round $i failed, retrying later" >&2
    sleep 60
    continue
  }
  echo "$OUTPUT"
  echo "[$(date '+%F %T')] Round $i done" >&2
  sleep 60
done

Combined with a system scheduler, this gives you scheduled inspections. Typical CI uses include code review triggered by pull requests with comments posted back, nightly automatic fixes for failing tests, and periodic dependency upgrades submitted as PRs. When running in CI, follow these rules:

• Inject model credentials through secret variables;
• Set a timeout and a cost cap for every run;
• Archive outputs as logs and reports;
• Allow the agent to modify only designated directories.

5.3 Four Design Points for a Long-Running Agent

• Persistent state: write the task list and completed items to files so a run can resume after interruption.
• Idempotent design: repeated execution must not produce side effects — check before creating, and avoid duplicate submissions.
• Human checkpoints: pause and wait for confirmation for anything touching production, deleting data, or publishing externally.
• Observability: log the input, output, duration, and cost of every round so you can review and tune later.

6. The Full Practical Closed Loop: Operating Web Pages and Devices

6.1 Operating Web Pages: Browser Automation Services

Browser automation context services (called browser-demo below) typically provide tools for:

• Navigation: open, forward, back, and refresh pages;
• Snapshots: read the page’s accessibility structure to get numbered interactive elements;
• Interaction: click, type, select, upload files;
• Information retrieval: get page text, run scripts, read console and network logs;
• Visual records: screenshots and recordings of the interaction.

The working method is an “operate-by-snapshot loop”:

Navigate → accessibility snapshot → locate target element → click/type → screenshot to confirm → done?
  ↑                                                                         │ no
  └─────────────────────────────────────────────────────────────────────────┘

Operating from a structural snapshot is more stable than acting on screenshot coordinates alone, and it survives small layout changes. To keep multi-round tasks going, let the browser hold a persistent session; if you need to reuse a login state, log in once, save the session state file, and load it later.

6.2 Operating Devices: Debugging Context Services

Device debugging context services (called device-demo below) connect to real phones, tablets, and emulators through a debugging channel. Common capabilities include:

• Listing connected devices, or connecting to a specific one over wireless debugging;
• Installing and uninstalling apps, launching a specific screen;
• Simulating taps, swipes, text input, and key presses;
• Exporting the view hierarchy so the agent can locate controls;
• Reading runtime logs in real time and filtering by keyword;
• Taking screenshots, recording the screen, and clearing app data.

# 1. Check device connection status
device-demo devices
# 2. Install and launch the app
device-demo install -r build/app-debug.apk
device-demo shell am start -n com.example.app/.MainActivity
# 3. Dump the current view hierarchy so the agent can locate controls
device-demo dump-ui > ui.xml
# 4. Tap at the given coordinates
device-demo shell input tap 540 1200
# 5. Stream logs and filter by keyword
device-demo logcat | grep -E "Exception|Error"
# 6. Capture a screenshot of the result
device-demo exec-out screencap -p > screenshot.png

Verify the command names against the documentation of the tool you use. Before running commands like these, make sure the device has debugging authorization enabled, and use test accounts and test data in an isolated environment.

6.3 The Dual-Device Closed Loop: Just Describe the Intent

With all three layers in place, the user only needs to describe the goal and the agent plans the path itself. A typical scenario:

“Verify the new login flow: create a test account in the web admin console and submit a login verification request; install the latest build on the test phone, log in with that account, and reach the profile page; confirm nothing is broken, and put the screenshots and logs into a report.”

The agent roughly follows this path:

Step	Layer used	Key actions	Feedback basis
1	Information layer	Read the requirements doc and API notes	Document content
2	Interface layer	Open admin console, log in, create the account	Page snapshots and screenshots
3	Usable layer	Install the build, launch the app, log in	View hierarchy and runtime logs
4	Interface layer	Open the profile page, screenshot to verify	Screenshot and page text
5	Summary	Collect screenshots and logs, write the verification report	Results of each step

The key to the loop is not that each step is complex, but that every step has observable feedback. Page structure, view hierarchy, and runtime logs are the agent’s eyes; with them, the model can tell whether it actually got things right.

7. From Usable to Good: Five Engineering Recommendations

1. Manage context: compress history proactively in long tasks, split work by module, and write key conclusions to files rather than leaving them in the conversation.
2. Authorize by risk tier: allow read-only tools by default; require confirmation before writing code; require human approval for high-risk actions such as deleting data, changing production configuration, and publishing externally.
3. Security and compliance: keep keys out of the repository; redact sensitive data before sending it to a model; keep a complete audit log of tool calls.
4. Balance cost and quality: choose models by task type, set per-task and per-day cost caps, and review the usage distribution regularly.
5. Define the human–machine boundary: let the agent handle repetitive retrieval, writing, and verification, and let people own goal definition, trade-off decisions, and final sign-off.

8. Closing: Get Your Hands Dirty and Work Along the Capability Boundary

The value of an AI coding agent is not that it replaces a few lines of code a developer would type, but that it compresses the chain of “search — read — modify — run — verify” into a single conversation. Using it well, though, means expanding along its capability boundary step by step:

• Inside the boundary is what it already does reliably: reading and writing files, running commands, calling tools;
• Outside the boundary is territory that is not yet verified: complex business logic, production changes, cross-system coordination.

The pragmatic approach is to get the smallest loop working first — install, connect a model, complete one task — then layer on instruction files, skill packages, context services, and automation scripts. Validate every expansion against a real task, and write the results back into the instruction files and skill packages.

Tools keep iterating and model capabilities keep advancing quickly. Rather than chasing every new tool, it is better to build a working style where capabilities are pluggable, workflows are reusable, and risk is controllable. Get your hands dirty and work along the capability boundary — that is the durable way to use an agent well.