Building a Full‑Chain AI Agent for Intelligent Ticketing: From Config to Closed‑Loop

1. Background and Positioning

As overseas business volume grows, ticket volume rises and manual handling becomes a bottleneck: response times of 5‑15 minutes, scattered knowledge, and inconsistent quality. The platform aims to provide a unified Agent runtime framework so that technical staff only need to configure tools and skills, turning "human does it" into "Agent does it, human supervises".

2. Architecture Overview

The system consists of three layers: Backend Configuration (engineers register tools), Runtime Processing (Agent executes automatically), and Closed‑Loop Feedback (BadCase‑driven continuous optimization). Core design principles are group isolation, hot‑config deployment via Diamond + Tair, and simulation‑first validation.

3. Backend Configuration

Configuration follows a five‑step workflow: Tool Registration → Skill Configuration → Ticket Grouping → Simulation Regression → Release Gate . Five tool types are supported:

Native : built‑in methods for core capabilities such as ticket detail queries.

ideaLab : tools registered on the ideaLab platform for AI‑driven diagnosis and knowledge retrieval.

HSF : generalized HSF calls to existing middleware services.

SuperAgent : Mobius SuperAgent instances for complex sub‑task orchestration.

MCP : Model Context Protocol for integrating external standardized tool protocols.

All tools are managed on a single page with enable/disable, mock debugging, and 30‑day usage statistics (call volume, success rate, average latency) to help locate abnormal tools quickly.

4. Runtime Processing Flow

When a ticket enters the system, the Agent automatically processes it through the following stages:

Entry → Formatting → Intent Recognition → Skill Ranking → ReAct Multi‑turn Scheduling → Output → Tracking

4.1 Multi‑Entry Integration

MQ Message (MetaQ TicketsSubscriber): automatic ticket hand‑off, main traffic entry.

DingTalk Query: users @Bot in DingTalk groups.

Page Trigger (TicketAgentController): manual trigger from the admin console.

4.2 Intelligent Scheduling (ReAct Multi‑turn)

Intent Recognition (TicketIntentRouter): analyses title and description to identify problem type.

Skill Matching & Ranking (SkillIntentMatcher): selects top‑3 skills for the current group.

Knowledge Retrieval (KnowledgeService): routes to the group‑specific knowledge base.

ReAct Multi‑turn (TicketReactAgentRuntime): the Agent iteratively "think → call tool → observe result" until a conclusion is reached.

Execution & Output : generates a handling plan and performs ticket reply or transfer.

4.3 Output and Notification

Ticket reply/transfer via GOC interface.

DingTalk notification pushes results to the corresponding group.

Full‑process progress is written to Tair → SLS for audit.

4.4 Operations Dashboard

The dashboard visualises multi‑dimensional data, filterable by time range, environment, and group, showing seven core metrics (new tickets, AI‑handled, comments, group transfers, personal transfers, returns, completions), trend charts, detailed tables, and AI‑unhandled alerts.

5. Closed‑Loop Feedback

Failures in runtime or business re‑opens generate BadCases, which are automatically collected, clustered by group/skill/error type, fed back into simulation regression as evaluation samples, and drive Skill optimization and knowledge‑base enrichment. After passing the release gate, the updated version is redeployed, completing a true closed loop.

Runtime failure → BadCase auto‑collect → Cluster by group/skill/error → Feed to simulation regression → Drive Skill & Knowledge improvement → Pass gate → Redeploy → Closed‑loop

6. Integration Guide

Business domains can onboard in three steps:

Register Tools : add required diagnostic tools (HSF, ideaLab, MCP) on the tool‑management page.

Configure Skills : write a SKILL.md defining processing steps, intent tags, and dependent tools.

Enable Group : create a service group, bind tools and skills, and turn on the Agent switch. Verify in the simulation environment before going live.

After these steps, tickets for the service group are automatically processed by the Agent.

7. Technical Selection

LLM Invocation : DashScope (qwen‑max) with cluster‑level concurrency limiting.

Configuration Distribution : Diamond for hot‑config rollout.

Status Cache : Tair for task status and Skill persistence.

Message Ingestion : MetaQ for asynchronous ticket consumption.

Logging : SLS for full‑link processing records.

Framework : Pandora Boot (Spring Boot 2.7) on Java 21 runtime.

8. Summary

The platform has progressed from "can run" to "can operate": five tool types unified under one management console, eight business skills covering logistics, payment, refund, and merchant services, six service groups (five with Agent enabled), and a >97% tool success rate with average handling time under 10 seconds. Future work focuses on expanding domain coverage, improving end‑to‑end resolution, and building an automated effectiveness evaluation system.