Terminal AI Coding Agents: Setup, Connecting Domestic Model Providers, and Real-World Workflows

This article answers three questions: how to install an AI coding Agent in the terminal, how to connect it to domestic models, and how to turn it into a workflow that actually gets work done.

1. Define the Boundary First: An Agent Goes as Far as It Can See and Touch

An AI coding Agent running in the terminal (referred to as the “Agent” below) can read code, edit code, run commands, and call external tools from the command line. What sets it apart from an assistant in a chat window is that it has “hands”: it can actually change the state of your machine.

In practice, the ceiling on an Agent’s capabilities is set by roughly three things:

• What it can read: the latest documentation, error messages, and known solutions for similar problems, or only what the model remembers from training.
• What it can touch: text files only, or also real pages, real devices, and running processes.
• Whether it can verify its own work afterward: a model “feeling” that it is right, or actual logs, screenshots, and network requests.

Mapped onto automation capability, these give three foundational layers:

Layer	Capability	Typical tooling	What happens when it’s missing
Information	Web search, fetching web pages	Retrieval built into the Agent, search tool services, self-hosted retrieval services	Cannot answer questions about what is “latest” or “current”; tends to solve new problems with outdated approaches
Interface	Opening pages, clicking, filling forms, taking screenshots	Browser automation service	Cannot operate web systems without APIs; end-to-end verification depends on manual clicks
Device	Installing packages, launching apps, interacting, reading logs	Mobile device debugging tools	Real-device behavior cannot be verified; mobile issues break at the last step

Put together, the three form a complete closed loop:

retrieval (latest docs, similar errors, past issues)
        ↓
execution (edit code, run commands, operate web pages or real devices)
        ↓
verification (screenshots, runtime logs, network requests, assertion results)
        ↓
passed? ──no──→ back to "retrieval" with the failure details, adjust the approach, retry
    │yes
    ↓
output changes plus evidence, for human review

Without any one of these layers, an Agent tends to stop at “looks done” rather than “verified correct.” Everything below is organized around this loop.

2. Installing a Terminal Agent: Environment Prep and Permission Boundaries

2.1 Prerequisites

1. Runtime environment: these Agents are mostly distributed as Node.js packages. Install an LTS (Long-Term Support) release of Node.js and, if dependency downloads are slow, point npm at a registry mirror close to you:

   node -v
   npm -v
   npm config set registry <mirror-url>

2. Terminal environment: you need a terminal that supports an interactive UI. The classic Windows console has limited support for some terminal capabilities, so use Windows Terminal, or run the Agent inside a Linux-compatible environment such as WSL. Your terminal font must also render non-ASCII characters, such as Chinese, correctly.
3. Command-line tools: make sure basics such as git and curl work, and set your git user name and email in advance.
4. API credentials: have the API key for your model service ready, keep it in an environment variable, and never hard-code it in project code.

2.2 Installation and Initialization

# Install the Agent CLI globally
npm install -g @<vendor-org>/<agent-cli>
# Check the version to confirm the installation
<agent> --version
# First run: enter the interactive UI and sign in or authorize with your API key
<agent>

Installation problems usually fall into a few categories:

• Insufficient permissions: if the global install fails with permission errors, configure a user-level global directory for npm instead of using elevated (admin/root) commands.
• Command not found: add the package manager’s global bin directory to your PATH, then reopen the terminal.
• Download timeouts: configure an npm mirror, or set a proxy for Node.js (use your actual proxy address and port).
• Garbled text: check that the terminal encoding is UTF-8.

2.3 Permission Boundaries: Set the Rules Before Granting Access

An Agent’s execution permissions amount to handing over part of the control of your machine. Before you start using it, set the boundaries first:

• Working directory: use the directory-addition flag to widen the scope the Agent can access. Anything outside that scope should be refused.

  <agent> --add-dir /path/to/another-repo

• Tool allowlist: expose only the tools that are necessary. For example, for a read-only review, allow only reading and search. Open up Bash only when you actually need to run commands.

  <agent> --allowedTools "Read,Grep,Glob"

• Sensitive files: do not hand .env files, private keys, or credential files directly to the Agent. If it truly needs to read them, redact them first by replacing real values with placeholders.
• High-risk commands: force deletes, disk formatting, system configuration changes, and similar commands should always be confirmed manually, one by one. Keep a list of high-risk command patterns as interception rules.
• Sandboxing: whenever possible, run the Agent in a virtual machine, a container, or a dedicated development branch, so it never touches your main branch or core system directories directly.

3. Connecting Domestic Models: Direct, Routing, and Aggregation

In this context, “domestic models” means Chinese large language models and the services that host them (for example, ERNIE, DeepSeek, Qwen, and GLM).

3.1 Four Things to Confirm Before Connecting

Agent clients are usually designed around a particular model API protocol. Before connecting, check each of the following:

1. API protocol: most major Chinese model services offer an API that is compatible with the common Chat Completions style, and most Agent clients can be adapted to it.
2. Tool calling: the Agent relies on function calling to read and write files and run commands, so this is the most critical item. Confirm in particular whether parallel calls are supported and whether nested objects and arrays in the arguments are parsed correctly.
3. Context length: codebases are often large, and a context window that is too small causes frequent truncation. Long-context models usually cost more as input length grows, so choose with your budget in mind.
4. Rate limits and billing: know your quotas (such as requests per minute and tokens per minute) and how billing works, so batch tasks do not trip rate limits.

3.2 Pattern 1: Direct Connection

The simplest approach is to point the Agent’s request URL, API key, and model names at the domestic model service. With a typical compatible-endpoint setup, for example:

# Point the Agent at a model service that speaks the OpenAI-compatible API protocol
export ANTHROPIC_BASE_URL="https://<model-service-url>/v1"
export ANTHROPIC_AUTH_TOKEN="<your-api-key>"
# Use the model IDs returned by the service; see the service documentation for valid values
export ANTHROPIC_MODEL="<model-name-main>"
export ANTHROPIC_SMALL_FAST_MODEL="<model-name-lightweight>"

Best fit: individual trials, validating model capabilities, and cases where a single model is enough.

Limitations:

• Keys are scattered across every machine, which makes them hard to manage centrally.
• Switching models means changing the configuration on every machine.
• There is no unified usage tracking, rate limiting, or failure retry.

3.3 Pattern 2: Routing

Deploy a lightweight gateway locally or on your intranet. The Agent points to the gateway, and the gateway forwards requests to different model services according to rules.

Core responsibilities of the gateway:

• Key custody: API keys live only on the gateway side. Clients hold only a gateway access token.
• Capability mapping: some Agent clients pick a parameter format based on a specific model name. The gateway needs to map these names to the real IDs of the domestic models and convert request and response formats in both directions.
• Usage tracking and rate limiting: record token consumption by user, project, and session. Requests that exceed the limit are automatically rejected or downgraded.
• Retry and fallback: on timeouts, rate limits, or server-side errors, retry with exponential backoff. If the primary model fails repeatedly, switch to a backup model automatically.

Example routing rules (the fields are illustrative and must be adapted to the actual gateway product):

routes:
  - name: fast-tasks
    match:                        # matching conditions
      any:
        - tool: [Write, Edit]     # small file edits
        - agent: explore          # lightweight retrieval tasks
    target: "<model-name-lightweight>"   # forwarding target
  - name: heavy-tasks
    match:
      any:
        - tool: [Bash, WebFetch]
        - agent: [plan, general-purpose]
    target: "<model-name-main>"
fallback: "<model-name-backup>"  # fallback model when the primary model is unavailable

Best fit: small teams sharing a setup, where cost needs to stay under control and you want to switch models at any time without touching clients.

3.4 Pattern 3: Aggregation

Routing answers “where to forward”; aggregation answers “how do different models complement each other and cross-check one another.” An aggregation layer is usually deployed server-side. It exposes a single unified endpoint to the outside, maintains multiple model services internally, and adapts them to a common standard:

• Capability normalization: differences between providers in function calling, JSON output, and streaming responses are unified into one format, so clients never see them.
• Complementary scheduling: complex reasoning such as planning and architecture analysis goes to the strongest reasoning model. Formatting, summaries, and simple refactoring go to a faster lightweight model.
• Cross-validation: for a critical change, two models can each produce a proposal. You compare the differences and then decide which one to adopt. This suits high-risk changes and code review.
• Stability fallback: if one service misbehaves, traffic switches automatically. Paired with result caching, it reduces the cost of repeated calls.

Best fit: teams already using multiple domestic models who want each task to play to the right model’s strengths, or production environments with high stability requirements.

3.5 Which Pattern Should You Choose?

Pattern	Advantages	Costs	Best for
Direct	Minimal configuration, ready in minutes	No central management, expensive to switch models	Individual trials, single-model setups
Routing	Centralized keys, usage tracking, easy model switching	Extra gateway to deploy and maintain	Small teams, shared setups
Aggregation	Complementary capabilities, automatic failover	Complex architecture, latency and consistency to watch	Production, multi-model setups

If you use a cloud model service (for example, calling ERNIE models on Baidu AI Cloud’s Qianfan platform), it usually takes three steps in the console to obtain the endpoint and credentials: enable the service, create an API key, and select a model. If you need your own gateway for unified control, you can deploy it on a cloud VM or a container platform, and pair it with logging, monitoring, and alerting to track call volume and error rates in one place.

3.6 Integration Troubleshooting Checklist

Symptom	Common cause	Where to look
The model does not call tools, only says it did	Incompatible function-calling format, or too many tools for the model to handle	Test connectivity with a single, simplest tool call, then add tools back one at a time
Tool-call arguments are empty or arrive as a string	Objects and arrays in the arguments were serialized into text	Inspect the request and response bodies at the gateway and fix the format conversion
Context-length errors	Input exceeds the model’s window	Trim the prompt, enable session compaction, or switch to a long-context model
Frequent 429 rate limiting	Quota exceeded or concurrency too high	Lower concurrency, add backoff retries, request a quota increase
Truncated or empty replies	Streaming response timeout or cut-off	Adjust timeouts and check the gateway’s buffering settings

4. MCP, Skills, and Project Instruction Files: Turn the Agent Into Your Workspace

The model itself is only the “brain.” To make it work reliably on a specific project, you need three more things: a unified interface to external tools, reusable procedures, and stable project rules.

4.1 MCP: Connect to the Outside World With One Protocol

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external data sources and tools in a uniform way. Architecturally, it has these sides:

• Host: the Agent itself.
• Client: a separate connection the host establishes with each server.
• Server: exposes one capability (such as file access, database queries, or browser control) as tools, resources, or prompt templates, running either as a lightweight local process or as a remote service.

An example host configuration file:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@<vendor-org>/<filesystem-server>", "/path/to/project"]
    },
    "remote-search": {
      "type": "sse",
      "url": "https://<internal-service-url>/sse",
      "headers": { "Authorization": "Bearer <access-token>" }
    }
  }
}

Things to keep in mind when configuring MCP:

• Transport: local servers usually communicate over standard input/output (stdio), while remote ones usually use SSE or Streamable HTTP.
• Scope: project-level configuration can be shared with the repository, while user-level configuration applies only to you. Put keys in user-level configuration, or reference them through environment variables. Never commit them to the repository.
• Least privilege: each server should expose only the capabilities needed for the task. For example, a read-only search server should not allow writes.
• Timeouts and count: set timeouts for remote servers, and avoid connecting too many at once, or the tool list becomes so long that it interferes with the model’s tool selection.

4.2 Skills: Capture Repetitive Workflows

Describing the same kind of task in natural language every time wastes tokens and produces inconsistent results. A Skill solves this by capturing such workflows in structured Markdown files placed in the agreed skills directory. The Agent decides whether to load a skill based on the task description.

A skill usually contains:

• Metadata: name, description, and trigger scenarios.
• Workflow steps: the order of operations, step by step.
• Templates and scripts: code you can reuse directly.
• Reference material: detailed documentation loaded only when needed, so it does not consume too much context up front.

Example:

skills/release-note/
├── SKILL.md            # skill description and workflow
├── template.md         # release notes template
└── scripts/collect.py  # script that gathers commit records

# SKILL.md (excerpt)
---
name: release-note
description: Generate release notes from the commits in a specified range.
---
## Steps
1. Run scripts/collect.py to get the commits merged in the range.
2. Group them into "features / fixes / improvements"; ignore docs-only and formatting-only commits.
3. Format the output according to template.md, with summary stats at the end.
4. If there are breaking changes, list migration guidance separately at the top.

Tasks that are good candidates for a skill usually share three traits: they recur, their steps are relatively fixed, and they have clear formatting requirements. Examples include code review checklists, API documentation generation, writing release notes, and initial triage of production logs.

4.3 Project Instruction Files: Help the Agent Understand the Project Quickly

Every time the Agent enters a new project, it has to figure out the tech stack, directory structure, and command conventions from scratch. A project instruction file captures this information once, and the Agent reads it automatically at startup. A common approach is to agree on a main instruction file that the Agent looks for at several levels, such as your home directory and the project root, and merges.

A practical project instruction file should include:

# Project overview (example)
## Overview
- Tech stack: <framework, language, and versions>
- How to run: start locally with <start command>
## Directory structure
- src/api/: backend endpoints
- src/web/: frontend pages
## Common commands
- Install dependencies: <install command>
- Run locally: <run command>
- Unit tests: <test command>
- Linting: <lint command>
- Build and release: <build command>
## Coding conventions
- Commit message format: <commit convention>
- Naming style: <naming convention>
- Comments and docs: <requirements>
## Constraints
- Do not modify code under src/legacy/
- Dependency version changes must be committed separately

Three points to keep in mind when writing it:

1. Lead with commands: spell out how to build, test, and lint, so the Agent can close its own verification loop.
2. Spell out what is forbidden: which directories are off-limits and which operations require asking first. This reduces out-of-bounds changes.
3. Maintain it in layers: keep general preferences in global rules and project-specific conventions in project rules. Rules should be updated as the project evolves, ideally under version control.

4.4 How the Three Work Together

A concrete scenario shows how they fit together:

1. A request lands in the project, and the Agent learns how to build and test from the project instruction file.
2. When it needs internal documentation or the latest information, it reaches a search service through MCP.
3. When the task matches a repetitive workflow (such as generating API documentation), it loads the corresponding skill and follows it.

5. Everyday High-Frequency Operations and Commands

5.1 Command Quick Reference

Scenario	Command (example)	Description
Start an interactive session	<agent>	Enter the interactive UI for a continuous conversation
One-shot execution	<agent> -p "Add unit tests for the login endpoint"	Print the result and exit; good for scripts
Specify a model	<agent> --model <model-name>	Temporarily switch models
Continue the last session	<agent> -c "Keep fixing the error from before"	Retain the previous context
Resume a specific session	<agent> -r <session-id>	Return to a past session
Check the version	<agent> --version	Confirm the version after an upgrade
Custom system prompt	<agent> --append-system-prompt "Reply in English"	Adjust behavior without changing config
Widen accessible directories	<agent> --add-dir <directory>	Coordinate changes across multiple repositories
Exit the interactive UI	/exit	End the session

Note: flag names may differ slightly between versions. Run <agent> --help to see the flags supported by your version.

5.2 Common Actions in the Interactive UI

• @ to reference a file: add a file to the context, or have the Agent read a specific file.
• ! to run a command: run a shell command directly in the session; its output enters the context.
• # to record a rule quickly: write a convention straight into project memory, with no manual file editing.
• /compact to shrink the context: when a long session nears the context limit, compress the history and keep the key conclusions.
• Esc to interrupt: stop the Agent immediately when it goes off track, and give it a clearer instruction.
• Shift+Tab to switch mode: switch between permission modes.

5.3 Choosing a Permission Mode

Mode	Behavior	Best for
Default	Asks for confirmation before edits and similar operations	Day-to-day development
Accept edits	File edits are accepted automatically; commands still need confirmation	Clear scope of changes, fast iteration
Plan	Analyzes and plans only, with no actual changes	Complex requests where you align on the approach first
Bypass permissions	Skips most confirmations	Isolated environments or containers only

6. Scheduling and Always-On: Let the Agent Keep Watch 24/7

Everything above follows the pattern of “a human starts it, the Agent executes.” But real work also involves plenty of repetitive watching and monitoring:

• Checking every day whether documentation or versions have been updated
• Doing initial triage when an alert fires
• First-pass analysis after a nightly CI build fails

These tasks fit two modes: scheduled loop-driven execution and unattended one-shot calls.

6.1 Loop Mode: Let the Agent Iterate on Its Own

The idea behind loop mode is to set a goal and a termination condition, then let the Agent read the previous round’s results and keep improving until verification passes or it hits the round limit. Example:

> Loop: run the unit tests, analyze the failing cases and fix them, until all tests pass or 5 rounds are reached

You can interrupt at any time with Esc. It suits tasks with a clear goal that can be verified automatically, such as fixing failing tests, passing lint checks, or filling in type definitions to a spec.

6.2 One-Shot Calls: The Basis for Scripts and Scheduled Jobs

# Pipe input: hand an error log to the Agent for analysis
tail -n 200 app.log | <agent> -p "Analyze the errors in the log below; list likely causes and troubleshooting steps"
# Structured output: easy for downstream programs to parse
<agent> -p "List every TODO comment in this project as a JSON array" --output-format json > todos.json
# One-shot call with an extra system prompt
<agent> -p "Review this change for security issues" --append-system-prompt "Reply in English"

Combined with the system scheduler (such as crontab), the Agent can run checks on a fixed schedule:

# Generate the dependency security audit report at 9:00 on weekdays
0 9 * * 1-5 cd /path/to/project && <agent> -p "Check the dependency manifest versions and output, as JSON, the dependencies with known risks and recommended versions" --output-format json >> /var/log/agent-audit.log 2>&1

6.3 Four Design Principles for Unattended Tasks

1. One goal: each call does a single thing. Tasks that are too complex push up the failure rate.
2. Verifiable: define exactly what “done” means, and let the Agent check its own output, such as whether the JSON parses or the tests pass.
3. With fallbacks: set retry counts, timeouts, and failure alerts so a task does not spin idly and burn through your quota.
4. Auditable trail: log the model, token usage, and result of every call. An aggregation or routing gateway is an ideal place to capture this call data.

7. End-to-End in Practice: Operating Web Pages and Devices

7.1 Operating Web Pages: Let the Agent “Use” the System Itself

Many internal systems expose no API, and end-to-end issues can only be reproduced on a real page. That is when the Agent needs the ability to drive a browser. Browser automation is usually connected as an MCP server, through which the Agent can:

• Open pages, click, type, select, and scroll
• Read the page’s accessibility snapshot to locate elements
• Take screenshots as visual evidence before and after an action
• Inspect network requests and console errors

Example configuration:

{
  "mcpServers": {
    "browser": {
      "command": "npx",
      "args": ["-y", "@<vendor-org>/<browser-automation-server>", "--isolated"]
    }
  }
}

Four things are worth noting in practice:

1. Session isolation: by default, use a separate browser instance so your personal login state is not used by mistake. If you really need to reuse a login, specify it explicitly by saving and loading a session file.
2. Credential safety: never put usernames and passwords directly in a prompt. Prefer environment variables or a saved session, so credentials never end up in conversation records or logs.
3. Compliant use: only operate systems you are authorized to access, and follow the target site’s terms of use and rate limits.
4. Stability: changes to page structure cause locators to fail. Prefer locating elements by text and semantic role, and add waits and retries for critical steps.

7.2 Operating Devices: Close the Loop on Mobile

Mobile issues often surface only after the app is installed on a real device. Mobile device debugging tools can:

• List connected devices and install or uninstall app packages
• Launch screens, simulate taps, swipes, and text input
• Capture screenshots and UI hierarchy information
• Collect runtime logs and crash stack traces

Common debugging commands (command names depend on the actual debugging tool):

# List connected devices
adb devices
# Install the app package
adb install -r app-release.apk
# Launch a specific screen
adb shell am start -n <package-name>/<activity-class-name>
# Simulate taps and input
adb shell input tap 540 1200
adb shell input text "hello"
# Capture runtime logs and crash information
adb logcat -d > run.log
adb shell dumpsys activity activities | grep mResumedActivity

The corresponding service form is a device automation service. Through it, the Agent takes instructions in natural language, for example: “install the latest test build, open the home screen, tap the search button, enter a keyword, and take a screenshot.” After execution, the Agent reads the logs and screenshots to judge the result. If something goes wrong, it retries automatically or goes back to retrieval to look for a solution.

Keep these points in mind as well:

• Real devices may hold personal accounts, text messages, and other sensitive data, so avoid capturing unrelated data when troubleshooting.
• Only operate test devices that you own.
• For sensitive operations such as login and payment, keep a manual confirmation step.

7.3 The Full Loop Across Both Platforms: Just State the Intent

Combine retrieval, web, and device capabilities and you can complete a full loop. Suppose you need to handle this report: “After saving a draft on PC, Android sometimes doesn’t show it.” Manually reproducing this used to mean switching back and forth between both platforms. Now you just state the intent:

Investigate and fix the issue where a draft saved on PC sometimes does not appear on Android: first locate the relevant code on both sides, reproduce the PC save action in the browser and capture the request and response, then check the Android read logic on a real device. Once the cause is found, fix it and verify that the data is consistent on both sides.

The Agent will roughly plan its path like this:

Search the code and past issues to locate the draft-related modules on both sides
        ↓
Browser: sign in → save a draft → capture the request and response, confirm whether the server-side data is correct
        ↓
Device: install the test build → open the drafts page → check logs and API responses
        ↓
Compare data from both sides and pinpoint the cause (e.g., inconsistent time formats or pagination parameters)
        ↓
Fix the code → run tests → verify on both browser and real device → report conclusions with evidence

The value of this loop is that you define “what to do” and “what counts as correct,” while the model plans the path on its own. So when describing the intent, spell out the goal, the constraints, and the acceptance criteria. Also keep manual review at key checkpoints, especially for operations that touch production data or involve public releases.

8. Final Thoughts: Get In and Stay Close to the Edge of What the Agent Can Do

Six months ago, many people were still taking a “wait and see” stance toward terminal Agents. Today, they can take over large amounts of day-to-day work: code review, bug fixing, documentation maintenance, environment checks. What really separates people is not who uses the stronger model, but who plugged their own workflows in sooner.

If you haven’t started yet, here is a suggested order:

1. This week: finish the installation and run a real code-change task end to end on a domestic model.
2. This month: write your project instruction file and two or three high-frequency skills, and connect a search and code retrieval service.
3. This quarter: try browser or device automation, hand one or two repetitive workflows to scheduled jobs, and let the Agent keep running.

The boundary of what Agents can do keeps moving. Steps that still need a human safety net today may be supported natively a few months from now. One habit is enough: when you run into repetitive work, first ask, “Can this be plugged into the Agent?” Get in, stay close to the edge of what it can do, and what you gain is not just a tool, but a whole new way of working.