Practical Coding Agent Deployment: Environment Setup, Model Integration, and Automated Workflows

Why You Need to Act Now

More than half a year ago, I made a judgment: although Chinese LLMs still lag behind the top-tier models, developers should already get familiar with agent-style coding tools. The reason is simple: the toolchain matures much faster than model capabilities catch up. By the time model capabilities fully arrive, the productivity gap between skilled and unskilled users will be difficult to close.

Looking back now, that judgment has largely held up. Agents can already take over a large amount of daily development work: writing code, checking documentation, running tests, operating web pages, and debugging real devices. More importantly, the user’s mindset has changed—from “learning to use this tool” to “can this process be automated? Can this system be connected?”

This article is therefore not limited to introductory topics such as installation and configuration. Instead, it follows a complete practical path: environment setup → model integration → capability expansion → daily workflows → automated closed loop. The reference environment is Windows 11 + a recent Node.js version + Git Bash. Differences on other platforms are noted separately.

1. The Three Foundations of Automation

Before going into specific steps, here is a core judgment that runs through the article:

How far an agent can automate depends on what it can “see” and “touch.”

Information access, interface operation, and device control form the three foundations of automation:

Layer	Capability	Common implementation	Consequence if missing
Information layer	Search and fetch web pages	Built-in agent search, general search/fetch MCP services	Can only rely on training data and cannot answer “latest” or “current” questions
Interface layer	Open, click, fill forms, take screenshots	MCP services based on browser automation protocols	Cannot operate web systems without open APIs; end-to-end verification breaks
Device layer	Install, launch, tap, read logs	MCP services based on device debug bridges	Cannot verify real-device behavior; mobile automation cannot close the loop

The following sections expand on this framework step by step. Remember the conclusion first: only when all three layers are in place can an agent form a complete loop: search and locate the problem → execute operations on the web or device → read results and verify.

2. Environment Setup

2.1 Prerequisites

Intelligent coding agents usually run as command-line tools and depend on the Node.js runtime. Recommendations:

• Node.js: Install the current LTS or a newer version to ensure long-term compatibility.
• Git: The agent’s version management capabilities depend on Git. It is recommended to complete basic configuration at the same time (username, email, default branch name).
• Terminal: Windows users should use Git Bash or the new Windows Terminal to avoid compatibility issues with interactive commands in the old cmd.

Verify after installing Node:

node -v
npm -v

2.2 Install the Agent Tool

Mainstream command-line coding agents are generally installed globally via npm:

npm install -g <agent-cli>
# Verify
<agent-cli> --version

The first launch usually guides you through login or API configuration. If you choose to use a third-party model service, you can skip the login flow and go directly to the API configuration in the next section.

2.3 A Habit Worth Building: Version-Controlled Configuration

It is recommended to include agent-related configuration files in dotfiles management (make sure to add the file containing the API key to .gitignore). Looking back half a year later, you will appreciate the versioning—the history of configuration evolution is itself a history of workflow evolution.

3. Integrating Chinese LLMs

3.1 Three Integration Patterns

There are currently three main patterns for connecting Chinese models to coding agents, each with its own use cases:

Pattern 1: Direct connection. Fill in the API endpoint and key provided by the model service provider directly in the agent configuration. The advantages are the shortest path, lowest latency, and no intermediary; the disadvantage is that switching models requires manual configuration changes. Suitable for developers who use one or two fixed models for a long time.

Pattern 2: Routing layer. Deploy a lightweight local proxy service that receives agent requests and forwards them to different model providers according to rules. Benefits include unified key management, failure retries, and routing by task type (for example, code completion to a small model and complex planning to a flagship model). Suitable for scenarios with diverse model usage.

Pattern 3: Aggregation platform. Use a third-party aggregation service to access multiple models with one key. This is the fastest way to get started, but it introduces dependency on an external service. You need to evaluate its stability, data policy, and billing transparency.

The three patterns can be combined: for example, a local routing layer as the primary channel and an aggregation platform as a backup channel.

3.2 Configuration Essentials

Regardless of the pattern, the core is to make the agent’s requests point to the correct API endpoint. A typical configuration contains three fields:

{
  "base_url": "https://your-model-endpoint/v1",
  "api_key": "sk-xxxx (never commit this to a code repository)",
  "model": "model identifier"
}

Engineering practice recommendations:

1. Secret redaction: Inject keys through environment variables instead of storing them in plaintext configuration files. If a key has leaked, revoke it in the console immediately and issue a new one.
2. Low-cost validation: After integration, first use a low-cost task (such as asking the agent to summarize a file) to verify the link and confirm that requests actually go through the new channel.
3. Pay attention to context length and tool-calling support: Coding agents rely heavily on tool calling and long context. When selecting a model, confirm its support for these two points, not just benchmark scores.

3.3 The Idea Behind Community Switching Tools

There are open-source tools in the community specifically for “one-click switching between multiple model configurations.” Their core idea is worth understanding: host multiple configuration files under a unified entry point and switch the active configuration through a menu. Even without a ready-made tool, you can achieve the same effect with a few lines of shell script:

#!/bin/bash
# switch_model.sh: switch between multiple model configurations
case "$1" in
  a) export BASE_URL="https://provider-a/v1"; export MODEL="model-a" ;;
  b) export BASE_URL="https://provider-b/v1"; export MODEL="model-b" ;;
  *) echo "usage: switch_model.sh a|b"; exit 1 ;;
esac
echo "Switched to $MODEL"

4. Capability Expansion: Turn the Agent into a Personal Workbench

By default, an agent is just a conversational coding assistant that can read and write files. The real productivity leap comes from three extension mechanisms:

4.1 MCP: Give the Agent “Hands and Feet”

MCP (Model Context Protocol) is an open protocol that allows agents to call external tools in a standardized way. An MCP service is a capability plugin: search, browser operation, database query, log retrieval, and more can all be packaged as MCP services and mounted for the agent.

Conceptual configuration example:

{
  "mcpServers": {
    "browser": { "command": "npx", "args": ["-y", "some-browser-mcp"] },
    "device":  { "command": "npx", "args": ["-y", "some-device-mcp"] }
  }
}

4.2 Skill: Capture Reusable Operating Procedures

When a task flow is executed repeatedly (for example, a “pre-release checklist”), it can be solidified into a Skill—a structured instruction document that the agent automatically applies when it matches the corresponding scenario. The essence of a Skill is turning personal engineering experience from “word of mouth” into “machine-executable.”

4.3 CLAUDE.md-Like Mechanism: Project-Level Context

Place a documentation file in the project root directory (conventionally named CLAUDE.md or similar) and include the project structure, coding standards, common commands, testing methods, and so on. The agent reads it at every startup, equivalent to an onboarding handbook for a new colleague. From experience: the quality of this file directly determines the upper limit of the agent’s performance in the project, and it is worth maintaining continuously.

5. High-Frequency Daily Workflows

• Code generation and refactoring: Let the agent read the relevant files and propose a plan before acting. This is a level higher in quality than giving instructions directly.
• Test-driven workflow: Let the agent write tests based on requirements before writing the implementation, and hand regression verification to the agent for automatic loop execution.
• Commit and review: Let the agent generate compliant commit messages or conduct a round of “pre-review” on uncommitted changes.
• Batch automation: Through non-interactive mode (such as agent -p "task description"), embed the agent into CI scripts or scheduled tasks for unattended execution. Some tools also provide loop execution mechanisms, allowing the agent to perform periodic autonomous inspections.

Non-interactive mode is the key to “full automation”—when an agent can be invoked from cron, pipelines, and hook scripts, it is no longer just a tool, but a schedulable “digital employee.”

6. The Ultimate Closed Loop: Operating Web Pages and Devices

Return to the framework in Section 1. The information layer is usually ready out of the box. What really creates a gap is the interface layer and the device layer.

6.1 Operating Web Pages

Through MCP services based on browser automation protocols, an agent can open pages, locate elements, click, fill forms, take screenshots, and read console logs. Typical scenarios:

• End-to-end verification of internal web systems that do not expose APIs;
• Automated repetitive form operations and data entry;
• Fetching data from pages that require a logged-in session to support analysis.

6.2 Operating Devices

Through MCP services that wrap device debug bridges (such as the commonly used Android adb protocol), an agent can install and launch apps, simulate taps and swipes, take screenshots, and capture logcat logs. Mobile developers can try an instruction like this: “Install the latest build, open the app, walk through the login flow, and if it crashes, paste the crash log and stack trace.”

6.3 Dual-End Closed Loop: State Intent, Not Scripts

When all three layers of capability are in place, the way of working changes qualitatively. You no longer write automation scripts; you state intent:

“Confirm the field descriptions for the new API in the online documentation, then verify whether the corresponding display in the app is correct, and summarize any issues in a report.”

The agent will plan the path autonomously: first search and fetch the documentation (information layer), then drive the browser to check the web content (interface layer), then execute operations on a real device and read logs (device layer), and finally summarize the output. The human shifts from “executor” to “acceptor.” This is the ultimate form of automation.

Final Thoughts: Get Hands-On and Stay Close to the Capability Boundary

Looking back at this path: install the tools, connect Chinese models, give the agent search and operation capabilities through extension protocols, solidify high-frequency processes, and finally bring web and device operations into the loop. The technical barrier at each step is not high; what is difficult is the persistence to keep iterating.

Two suggestions to close:

1. Get hands-on. Do not just read tutorials. This week, pick the repetitive task that consumes the most of your time and hand it to an agent once.
2. Stay close to the capability boundary. Model capabilities improve noticeably every quarter. What was impossible half a year ago may now be easy. Periodically throw previously “impossible” tasks back to the agent for testing, and you will find that the boundary keeps moving outward.

After some time, many processes that still require manual execution today will be quietly automated. Rather than being forced to catch up then, build this workbench now—once the tools are ready, what remains is imagination.