Building an Intelligent Agent Workflow: Setup, Integration, and Automation in Practice

0. The Three Foundational Layers of Automation: Information, Interface, and Device

The extent to which an intelligent agent can automate tasks depends on what it can perceive and operate on. This capability can be broken down into three layers, each addressing a different set of problems.

Layer	Core Capability	Typical Implementation	Consequence of Missing It
Information Layer	Internet search, webpage content extraction	General search APIs, webpage content extraction services	Relies only on training data; cannot answer time-sensitive questions
Interface Layer	Open pages, click, fill forms, take screenshots	Browser automation frameworks	Cannot operate web systems without public APIs; difficult to perform end-to-end verification
Device Layer	Install apps, launch, click, read logs	Command-line debugging interfaces for mobile devices	Cannot verify real-device behavior; mobile automation chain is interrupted

These three layers complement each other. The information layer provides factual grounding, letting the model know current version numbers, API documentation, and industry standards. The interface layer turns web pages into operable objects, enabling the agent to execute backend workflows and verify page results. The device layer brings mobile devices into the same pipeline, allowing installation, launch, and interaction to be automatically recorded. Without any one layer, automation breaks at a certain point and requires manual intervention.

1. Installation and Basic Environment

The installation steps may seem simple, but they determine the reliability of all subsequent configurations. Follow the sequence below.

1. Confirm the runtime environment. Check the operating system version, command-line terminal type, network proxy settings, and available package manager. In enterprise intranet environments, also confirm whether external download sources are accessible.
2. Install from official channels. Prefer the installation commands or packages given in the official documentation, and verify the publisher and checksum. Do not pipe remote scripts directly to the shell unless you have reviewed the script content.
3. Verify the installation. Check the version number and confirm that the command can be invoked from any directory.
4. Complete initial configuration. Follow the prompts to log in or complete local configuration, and explicitly set the working directory. Once set, the agent’s file read/write scope is determined by it, so choose the project root directory rather than the user home directory.

Example commands are shown below; replace the angle-bracket placeholders with actual values from the official documentation:

# 1. Check the runtime environment
<package-manager> --version
# 2. Globally install the intelligent coding tool
<package-manager> install -g <officially published package name>
# 3. Verify the installation
<tool-command> --version

After installation, run a minimal test in a blank directory, such as asking the agent to list the directory structure and explain the purpose of one file. This test quickly exposes permission, network, and login issues, preventing them from surfacing later in a real project.

2. Connecting Domestic Large Language Models: Three Modes

Intelligent coding tools typically communicate with models via a certain interface protocol. Most domestic (Chinese) large language models provide service endpoints compatible with mainstream protocols, but the tool’s default configuration, authentication method, and request format may not match. Therefore, the core issue of integration is: after the request leaves the tool, which stages does it pass through before reaching the model, and who is responsible for conversion at each stage?

Three modes are common in practice.

2.1 Direct Connection Mode

The tool directly accesses an endpoint provided by a single model service provider, with no forwarding layer in between.

• Advantages: Shortest path, easiest to troubleshoot, lowest latency.
• Disadvantages: Can only use a single model; if the tool’s protocol is not fully compatible with the server, manual configuration adjustments are needed; API keys are scattered across tool configurations, increasing management overhead.
• Use cases: Individuals or small projects that use only one model and require high control over the chain.

2.2 Routing Mode

A local or intranet forwarding layer sits between the tool and multiple models. This layer decides which model to send each request to based on rules that can consider task type, context length, cost limits, or model availability.

• Advantages: Can switch models by scenario, such as using a larger model for long-context tasks and a cheaper model for simple queries; can automatically switch when a single model fails.
• Disadvantages: Adds an extra component to maintain; errors in the forwarding layer affect all requests; logs need to be aggregated centrally for effective troubleshooting.
• Use cases: Teams that use multiple models and want to optimize cost or stability per task.

Keep routing rules simple. A practical approach is to route by request label:

# Example: choose the model by task type; field names are generic and need to match the actual forwarding component
routes:
  - match: { task: "code_edit" }
    model: "<high-capability model identifier>"
  - match: { task: "summary" }
    model: "<low-cost model identifier>"
  - default:
    model: "<general-purpose model identifier>"

2.3 Aggregation Mode

A unified gateway exposes multiple models behind a single endpoint. The gateway handles authentication, quotas, billing records, and model list management. The tool only needs to be configured with one address and one API key.

• Advantages: Most convenient configuration; centralized key management; easy usage statistics and cost control.
• Disadvantages: The gateway becomes a dependency; its availability and data handling policies must be evaluated in advance; differences in model capabilities may be flattened by the gateway, making certain features unusable.
• Use cases: Enterprise environments that need unified governance over multiple models, with requirements for cost and auditing.

2.4 How to Choose

When choosing, prioritize three questions: do you need multi-model switching? How strict are your team’s requirements for key management and auditing? Can you accept the operational overhead of an extra component? The usual path is to start with direct connection to get the workflow running, then introduce routing or aggregation as needed. Do not stack multiple forwarding layers from the beginning—when problems occur, it becomes hard to identify which layer is at fault.

Regardless of the mode, store API keys in environment variables or a key management service, never in code repositories or logs.

# Example: inject keys through environment variables to avoid hardcoding
export MODEL_API_BASE="https://<model-service-address>/v1"
export MODEL_API_KEY="<read from key management service>"

If you use Baidu AI Cloud’s model services, configure the endpoint and key in the same way; refer to the official documentation for specific parameters.

3. Extending Capabilities and Project Instructions: Turning the Tool into a Workbench

By default, an agent can only use built-in capabilities. To adapt it to a specific project, three types of mechanisms are needed.

3.1 Tool Protocols

Tool protocols allow the agent to call external services through a standard interface, such as querying databases, reading ticket systems, or calling internal APIs. The value of protocols lies in standardizing the interface form: as long as a service implements the protocol, any compatible agent can connect without writing custom adapter code for each tool.

When connecting external services, follow the principle of least privilege. Only expose operations necessary for the current task, such as read-only queries; operations involving writes, deletions, or sending messages should require human confirmation.

3.2 Skill Modules

Skill modules are packaged sets of instructions, templates, and scripts for completing a fixed type of task, such as generating API documentation, checking code style, or writing release notes from a template. Skill modules are reusable and versionable, allowing team members to share the same workflow.

When writing a skill, clearly define inputs, outputs, and execution conditions. Avoid stuffing all logic into a single prompt.

3.3 Project Instruction Files

A project instruction file is a documentation file placed in the repository root that the agent reads every time it starts. It is suitable for recording:

• Standard commands for building, testing, and launching;
• Code style and directory conventions;
• Prohibited operations, such as disallowing direct modifications to production configuration;
• How to handle common issues.

Example structure:

# Project Instructions
## Common Commands
- Install dependencies: `<package-manager> install`
- Run tests: `<package-manager> test`
## Conventions
- New APIs must include unit tests.
- Database migration scripts go into `migrations/`; do not manually modify released scripts.
## Prohibited
- Do not commit key files.
- Do not delete branches or data without confirmation.

Keep the instruction file concise, recording only information that is used repeatedly. Overly long content consumes context space and reduces the model’s adherence to key constraints.

4. Daily High-Frequency Operations and Commands

The daily usage of intelligent coding tools centers on a few categories of operations. Mastering these operations is more valuable than memorizing many parameters.

4.1 Session Management

• New session: Start a new session for a well-defined goal to avoid unrelated context interfering.
• Resume session: After interruption, you can restore the previous context and continue unfinished work.
• Compress context: When a session grows long, use compression to keep key decisions and pending tasks while discarding outdated discussion.

4.2 Permission Modes

Most tools provide multiple permission modes. A typical pattern: reading files and running read-only commands are allowed by default; modifying files, executing scripts, and accessing the network require confirmation. Keep confirmation mode enabled in daily development, and only relax permissions temporarily in a trusted sandbox.

4.3 Non-Interactive Invocation

Non-interactive mode lets the agent accept a single instruction, execute it, output the result, and exit. This is suitable for embedding in scripts or pipelines.

# Example: run once and output the result
<tool-command> -p "Check src/ directory for unused imports, only output file paths and line numbers"

For non-interactive invocations, structure the output, such as requesting JSON format, for easier parsing by downstream scripts.

4.4 Custom Commands

Save frequently used prompts as custom commands to reduce repetitive input. Command files should include clear parameter descriptions and execution boundaries, such as “analyze only, do not modify files.”

4.5 Scheduled and Long-Running Execution

Some tasks require periodic execution, such as aggregating error logs daily, checking dependency vulnerabilities on a schedule, or polling build status. There are two implementation approaches.

The first is an in-session loop. The agent repeatedly checks a condition at fixed intervals within one session, such as checking the build result every ten minutes and notifying the user when the status changes. This approach works for short-term monitoring; the loop stops when the session ends.

The second is delegating to system scheduled tasks. Use the operating system’s scheduling mechanism to periodically start the agent in non-interactive mode to perform a task, writing the result to a file or sending it to a designated channel. This suits long-running tasks, but note the following:

• Tasks should be idempotent; repeated execution must not produce side effects;
• The run account should have only the minimum permissions needed for the task;
• Logs must be retained for auditing each execution;
• Credentials are injected through secure storage, not written into the scheduled task script.

5. End-to-End Closed Loop: Operating Web Pages and Devices

The three layers of capability described earlier must ultimately materialize in specific verification workflows. Below we describe automation methods for web pages and mobile devices, then present a dual-end closed-loop design.

5.1 Operating Web Pages: Browser Automation

Browser automation lets the agent control a real browser instance to perform tasks like opening pages, locating elements, entering text, clicking buttons, and taking screenshots for comparison. Compared with direct API calls, it covers systems that do not expose public APIs and can reveal front-end rendering, styling, and interaction issues.

Implementation notes:

• Use a separate browser profile. Do not reuse your daily browser’s login state, to avoid accidentally operating on personal accounts.
• Choose stable locators. Prefer semantic attributes such as roles, label text, and test IDs. Avoid selectors that depend heavily on DOM structure; otherwise, minor page changes break the script.
• Set explicit waits. Wait for target elements to appear or network requests to finish, rather than relying on fixed sleep times.
• Save evidence. Take screenshots and capture page text at each key step for later review.

A typical verification flow:

1. Open the test environment’s login page.
2. Log in with a test account.
3. Navigate to the order list and filter records with status “Pending”.
4. Click the first record and verify the detail page amount matches the list page.
5. Take a screenshot and record the result.

5.2 Operating Devices: Mobile Device Debugging Interfaces

Mobile device debugging interfaces allow command-line tools to communicate with connected devices to perform actions like installing apps, launching activities, simulating taps, reading system logs, and capturing screens. This verifies application behavior on real devices, bridging the gap between simulators and real devices.

Usage notes:

• Connect only test devices; do not run batch operations on personal phones.
• Logs may contain sensitive information; sanitize them before collecting or sharing.
• Click and input operations rely on coordinates or the UI hierarchy; after the UI changes, re-locate elements.
• After each operation, check the device state to prevent the script from continuing on an unexpected screen.

An illustrative command sequence (actual commands depend on the tool’s documentation):

# Example: install a test package, start an activity, read recent logs
<device-debug-command> install <test-package-path>
<device-debug-command> shell am start -n <package-name>/<activity-class>
<device-debug-command> logcat -d -t 200 > run_log.txt

5.3 Dual-End Automation Closed Loop

The goal of the dual-end closed loop is: the developer only describes a business intent; the agent autonomously plans the operation path and performs verification across both web and mobile devices. For example, “after a new user registers, they should see a welcome page on mobile.” The flow can be broken down as:

1. Call the backend API or trigger the registration event from the web side.
2. Verify the user record is created in the backend database.
3. On the mobile device, install the latest build, launch the app, and log in with the newly registered account.
4. Check that the welcome page appears and capture a screenshot.
5. Record the result and attach the relevant logs.

This loop combines all three layers: information retrieval, interface operation, and device operation. It ensures that changes introduced on one end are validated on the other end, forming a complete automated verification chain.