Skip to content

Agent Overview

Agents are standardized AI workflows that complete specific and repeatable tasks by combining prompts, rules, and tools (such as MCP and other integrations).

An agent is a customized AI workflow composed of prompts, rules, and tools (e.g., MCP and other integrations) designed to perform specific, reusable tasks. It can be hosted in the Agent Hub and run via a web interface, or created and used locally within the IDE.

Components of an Agent

Component
DescriptionExample
ModelThe large language model that drives the agent's reasoning and output generation.Qwen3
RulesConsistent standards or behavioral guidelines that the agent must follow when responding, ensuring reliability of results."When summarizing work, relevant Issues must be included."
PromptThe instruction that triggers the agent's core behavior. When invoked, user input is appended to this prompt.Example prompt: "Summarize the current work progress, including status, blockers, and next steps. Use Markdown format with concise and professional language."
Tools / MCPExtends external capabilities (databases, APIs, CLI).GitHub, PostHog, Supabase

Types of Agents

VJSP AI Studio supports three types of agents, distinguished by management method:

Agent Structure and Component Configuration

All local agents are defined via a config.yaml file located in the .vjsp/agents/ folder at the project root.

Basic Structure

yaml
# This is an example configuration file  
name: Config    # Required  
version: 1.0.0  # Required  
schema: v1      # Required  

# Define which models can be used  
models:         # Model configuration  
  - name:  
    provider: openai  
    model:  
    apiKey: YOUR_OPENAI_API_KEY_HERE

Core Component Configuration Details

Models

Defines the language model that drives the agent.

yaml
models:  
  - name:  
    provider: openai  
    model:  
    apiKey: YOUR_OPENAI_API_KEY_HERE  
    roles:  
      - chat  
      - edit  
      - apply  
    capabilities:  
      - tool_use  
    requestOptions:  
      headers:  
        vjsp-api-key: your_api_key
  • roles: Specifies the model's purpose (chat/edit/autocomplete/apply).
  • capabilities: Enables advanced features (e.g., tool_use for invoking MCP).

Rules

Used to enforce AI adherence to coding standards.

yaml
---  
description: Generate functional test cases  
---  
# Role: You are a senior software testing engineer, skilled in writing comprehensive, executable functional test cases that cover boundary conditions.  

 **Description of the Feature Under Test**:  
 [Provide a detailed description of the functional module to be tested here, e.g.: "User login feature, supporting email/phone number + password login, including 'Remember Me' option and 'Forgot Password' link."]  

 **Related Requirements or User Stories** (optional):  
 - User Story: As a registered user, I want to log into the system using my email and password so that I can access my personal workspace.  
 - Acceptance Criteria:  
   - Entering correct credentials should result in successful login;  
   - Entering an incorrect password should prompt "Username or password error";  
   - Five consecutive failures should lock the account for 15 minutes.  

 **Key Testing Requirements**:  
 1. Cover normal workflows (Happy Path), abnormal workflows (e.g., invalid input, network interruption), and boundary conditions (e.g., password length limits);  
 2. Include positive and negative tests;  
 3. If security is involved, include common security test points (e.g., SQL injection, XSS attempts);  
 4. Output format should be in table form, containing the following columns:  
    - **Test Case ID** (e.g., TC_LOGIN_01)  
    - **Test Title**  
    - **Preconditions**  
    - **Test Steps** (numbered list)  
    - **Expected Results**  
    - **Priority** (High/Medium/Low)  

 **Other Constraints**:  
 - No need to generate automation scripts; provide manual test cases only;  
 - Assume the system is deployed and accessible;  
 - Use Chinese for output.  

 Please generate complete, well-structured functional test cases based on the above information.

Prompts

Quickly trigger tasks via /commands.

yaml
---  
name: API Documentation Generation Expert  
description: API Documentation Generation Expert  
invokable: true  
---  
You are an API documentation generation expert, tasked with reading project code and generating standard Markdown-format API documentation.  
## Core Task  
Read the following code hierarchy and extract accurate interface information:  
- Controller layer: Obtain interface paths, methods, parameters.  
- Service layer: Understand business logic and return structures.  
- VO/DTO layer: Extract detailed response field information.  
- Form/Request layer: Obtain request parameter structures.  
- Entity/PO layer: Reference data model structures.  
## Output Format Requirements  
```markdown  
# [Interface Name]  
## Basic Information  
- Method: [GET/POST/PUT/DELETE]  
- Path: [API Path]  
- Description: [Function Description]  
## Request Parameters  
| Parameter Name | Type | Required | Description |  
|--------|------|------|------|  
| [Generated based on Form/Request layer] |  
## Response Parameters  
| Parameter Name | Type | Description |  
|--------|------|------|  
| code | number | Status code |  
| message | string | Message |  
| data | object | Data |  
### data Field Details  
| Parameter Name | Type | Description |  
|--------|------|------|  
| [Generate a complete field list based on the VO/DTO layer] |  
## Response Example  
---json  
{  
  "code": 200,  
  "message": "success",  
  "data": {  
    [Generate realistic examples based on VO/DTO]  
  }  
}  
---  
## Key Requirements  
1. **Must read actual code**: Generate based on real code from Controller, Service, VO, and Form layers.  
2. **Fields must be complete**: Response parameters must include all VO/DTO fields, including nested objects.  
3. **Types must be accurate**: Annotate based on actual data types in the code.  
4. **Examples must be realistic**: Generate reasonable example data based on VO/DTO fields.  
5. **Structure must be clear**: Nested objects need hierarchical explanation.  
Directly output the documentation; no need to explain the process. The generated API documentation must be stored in the project's `/docs` directory.

MCP Tools (mcpServers)

A server based on the Model Context Protocol (MCP) that provides browser automation capabilities using Playwright. This server enables large language models (LLMs) to interact with web pages through structured accessibility snapshots without relying on screenshots or vision-tuned models.

yaml
name: Playwright mcpServer  
version: 1.0.0  
schema: v1  
mcpServers:  
  - name: Browser search  
    command: npx  
    args:  
      - "@playwright/mcp@latest"