alibabacloud-qianwenai-support

Manage QianWen support tickets from the conversation: submit, list, view, follow up, expedite, reply, close and rate — covering QianWen AI, Bailian, DashScope and Alibaba Cloud model-service issues. Triggers: "submit ticket", "create ticket", "list tickets", "view ticket", "reply ticket", "close ticket", "rate ticket", "transfer to human", "work order", "customer service", "human support", "open ticket", "check ticket", "cancel ticket", "evaluate ticket", "ticket list", "ticket status", "expedite ticket", "overdue payment", "billing issue", "invoice discrepancy", "quota exhausted", "account suspended", "contact support". Do NOT trigger for general product knowledge, model usage how-tos, API Key management, or vague feedback without explicit ticket intent — confirm intent first. 中文触发：查工单、工单进度、提工单、回复工单、关闭工单、评价工单、转人工、账单问题、发票问题、额度不足、账号被停用。

alibabacloud@sdk-team

Install

openclaw skills install @sdk-team/alibabacloud-qianwenai-support

QianWen Support Ticket Management

Manage QianWen support tickets through the full lifecycle: create, list, view, reply, close, and rate. Auto-diagnoses common issues before creating tickets to avoid unnecessary submissions.

Data Flows and External Calls

The destinations below are the complete set of network endpoints present in this skill's shipped code. There are no others, and no Alibaba Cloud OpenAPI or other cloud API is called.

https://cli.qianwenai.com/data/v2/api.json — the QianWen support (Workorder) API, this skill's own first-party platform. The skill POSTs ticket operation requests here (create, list, view, reply, close, rate, categories) carrying the operation name, paging parameters, and the ticket fields the user supplied and confirmed (category ID, ticket ID, description text, rating), plus a tracing User-Agent. Authentication uses the user's own QianWen session credential, which is sent to this first-party endpoint only and never to any third-party destination.
https://meoo.com — official site of the MiaoWu app. The skill never requests this URL and sends nothing to it; it is only printed as a guidance link, because MiaoWu issues are handled on the app's own site instead of through a ticket.
https://wukong.dingtalk.com — official site of the WuKong app. The skill never requests this URL and sends nothing to it; it is only printed as a guidance link for WuKong issues.
https://www.qianwen.com — official QianWen consumer site. The skill never requests this URL and sends nothing to it; it is only printed as a guidance link for QianWen app issues.
https://qoder.com — official Qoder and QoderWork site. The skill never requests this URL and sends nothing to it; it is only printed as a guidance link for those app issues.

What data leaves this machine: only non-credential diagnostic context — hostnames, IP addresses, ports, domain names, timestamps, and resource IDs the user supplies — together with the ticket text the user has reviewed and explicitly confirmed; all of it goes only to the first-party QianWen endpoint above. No credentials, tokens, local file contents or customer data are uploaded to third parties. No attachment, log file, screenshot or archive is ever uploaded by this skill.

Read-only guarantee: this skill is read-only with respect to cloud resources — it never creates, modifies, deletes or bills any cloud resource, and it performs no third-party data sharing beyond the destinations listed above. Its only write operations are support-ticket records on the QianWen platform (create, reply, close, rate), and each one requires the user's explicit confirmation of the displayed draft beforehand.

Chinese Symptom Examples

"帮我提个工单，模型调用一直报错" → run auto-diagnosis first; draft a ticket only when needed and submit after user confirmation.
"我之前那个工单有进展吗" → list tickets and show status plus the latest reply.
"这个工单能加急吗" → confirm the ticket ID, expedite it, and explain follow-up.

Execution Principle

Diagnose before ticket: Run auto-diagnosis first; only create a ticket if auto-resolve fails or the issue is clearly a platform bug.
User confirmation: Always display the ticket draft and get explicit user confirmation before submitting.
Terminal status guard: NEVER reply to or close tickets in terminal status (closed/resolved/confirmed).
Verbatim relay: Customer service replies must be relayed verbatim — no summarizing, paraphrasing, or editing.

Credentials

Backend	Auth Method	Token Source
CLI	`qianwen auth login` (browser device flow)	system credential store
API	Bearer token	env `QIANWEN_ACCESS_TOKEN` or system credential store

NEVER output any credential value in plaintext. Report only status (authenticated / expired).

Alibaba Cloud AK/SK NOT supported: Alibaba Cloud main-account or RAM sub-account AccessKeys (and STS tokens) CANNOT authenticate the QianWen CLI or the workorder API. A Bailian API Key (sk-...) works for model API calls only, NOT for ticket management.

Two Credential Systems — Never Confuse

Credential	Purpose	How to provide
API Key (`sk-...`)	Call model APIs in code	`$DASHSCOPE_API_KEY` env var
CLI session	Authorize CLI/API subcommands	`qianwen auth login`

Red line: Never offer $DASHSCOPE_API_KEY to fix CLI/API AUTH_REQUIRED errors.

Authentication Flow (TL;DR)

When doctor reports not authenticated, guide the user through this flow:

qianwen auth status --format json -> authenticated: true -> skip to commands
qianwen auth login --init-only --format json -> extract verification_url -> open in browser
qianwen auth login --complete --format json -> poll until success event

Full procedure (two-phase login, JSON events, TTY handling): load references/auth-flow.md.

Unauthenticated user guidance: When neither CLI session nor API token is available, inform the user:

CLI path: run qianwen auth login (opens browser device flow), then retry
API path: set QIANWEN_ACCESS_TOKEN environment variable
NEVER attempt ticket operations without valid credentials

User Confirmation

MANDATORY before any state-changing action: creating, replying to, closing, or rating a ticket requires explicit user confirmation.

Create: display the full ticket draft (title, category, description) and wait for explicit confirmation. Never submit without it.
Reply: draft the reply from user instructions and get confirmation before submitting.
Close / Rate: state the target ticket ID and the action, then confirm before executing.

Read-only operations (doctor, list, view, categories) need no confirmation.

Trigger Conditions

Trigger Phrase	Action
"submit ticket" / "create ticket" / "submit work order"	Create new ticket
"list tickets" / "view my tickets"	List tickets
"view ticket " / "check ticket status"	View ticket detail
"reply ticket" / "respond to ticket"	Reply to ticket
"close ticket" / "cancel ticket"	Close/cancel ticket
"rate ticket" / "evaluate ticket"	Rate resolved ticket
"transfer to human" / "human support"	Create ticket (escalation)
"follow up on a ticket" / "expedite ticket"	View status and draft a reminder reply
"after-sales" / "report a problem" / "file a complaint" with ticket intent	Create ticket
"overdue payment" / "billing issue" / "invoice discrepancy"	Create billing ticket
"quota exhausted" / "usage limit reached"	Diagnose then create quota ticket
"API error, contact official" / "account suspended" / "account blocked"	Create platform ticket
"ticket" / "work order" with issue context	Create ticket after diagnosis

Do NOT trigger for:

General model usage questions (e.g., "how to call qwen-plus")
API Key management (e.g., "my API key expired")
Vague feedback without ticket intent (e.g., "product experience is bad")

Input Parameters

Parameter	Required	Description
`--backend`	No	`auto` (default), `cli`, or `api`
`--ticket-id`	For view/reply/close/rate	Ticket ID (e.g., `0005PYGCW`)
`--category-id`	For create	Category ID (fetch dynamically)
`--description`	For create	Ticket description (max 2000 chars)
`--message`	For reply	Reply content
`--rating`	For rate	0 (unsatisfied), 1 (neutral), 2 (satisfied)
`--comment`	For rate	Optional rating comment
`--page`	For list	Page number (default: 1)
`--page-size`	For list	Items per page (default: 10, max: 10)

Module Index

File	Purpose
`scripts/qianwen_support.py`	Entry script — all ticket operations
`references/auth-flow.md`	Full authentication procedure
`references/ticket-categories.md`	Category ID listing (Model / App groups)
`references/category-selection.md`	Category selection strategy and runtime refresh
`references/api-reference.md`	QianWen HTTP API documentation
`references/ram-policies.md`	RAM permission declaration (none required)

Orchestration

text

User request
    │
    ▼
┌─────────────────────────────────┐
│  Step 1: Pre-flight (silent)    │
│  python3 scripts/               │
│    qianwen_support.py doctor    │
└─────────────┬───────────────────┘
              ▼
┌─────────────────────────────────┐
│  Step 2: Auto-Diagnosis         │
│  Resolve common issues first    │
└─────────────┬───────────────────┘
              │
    ┌─────────▼─────────┐
    │ Issue resolved?    │
    └─────────┬─────────┘
         Yes │    │ No
         ▼   │    ▼
    [Report] │  ┌─────────────────────────────────┐
             │  │  Step 3: Ticket Operation        │
             │  │  create / list / view / reply /  │
             │  │  close / rate                    │
             │  └─────────────┬───────────────────┘
             │                ▼
             │  ┌─────────────────────────────────┐
             │  │  Step 4: Report & Next Steps     │
             │  │  Ticket ID + link + status       │
             │  └─────────────────────────────────┘

Execution Flow

Follow these numbered steps for every request:

Step 1 — Pre-flight check (silent): run the entry script doctor to verify backend availability and authentication. Only surface issues to the user if a check blocks the operation.
Step 2 — Auto-diagnosis: classify the reported issue and try CLI auto-resolve (see Error Handling). Only proceed to a ticket if auto-resolve fails or the issue is clearly a platform bug.
Step 3 — Ticket operation: run the matching subcommand of the entry script (create / list / view / reply / close / rate / categories).
Step 4 — Report and next steps: present results with hyperlinked ticket IDs, status, and expected response time; invite rating after a successful close.

Step 1: Pre-flight Checks (silent)

bash

python3 scripts/qianwen_support.py doctor

Step 2: Auto-Diagnosis

CRITICAL: Two types of 401 — never confuse them.

401 source	Cause	Correct fix	Wrong fix
`qianwen support` command / API returns 401	CLI session token expired	`qianwen auth login` then verify with `qianwen auth status`	—
Model API (qwen-text, qwen-vision) returns 401	API Key invalid/missing/mismatched	Report Key status (set/unset), never display Key value, guide user to regenerate on web portal	`qianwen auth login` (cannot fix model API 401)

Diagnosis decision tree:

Identify the error source: which command or API returned the error?
Error from qianwen support commands -> CLI session issue -> qianwen auth login
Error from model API calls -> API Key issue -> do NOT run qianwen auth login
If unsure, run qianwen doctor --format json for environment diagnostics first

Only create a ticket if auto-resolve fails or the issue is clearly a platform bug.

Optional Collaboration and Fallback

QianWen CLI accurately executes queries and operations; this Skill calls CLI directly for basic diagnostics and ticket management. Other QianWen Skills are not more capable and not required dependencies.

Rules:

When the corresponding domain Skill is detected and installed: prefer its specialized diagnostic flow.
When the corresponding domain Skill is not installed: execute this Skill's own read-only basic checks using QianWen CLI.
Never block ticket management (create, list, view, reply, close, rate) due to missing domain Skills.
Never claim professional diagnostics this Skill does not possess — be honest about what was checked.
When basic diagnostics cannot resolve the issue, display the ticket draft and obtain user confirmation before submitting.

Step 3: Ticket Operations

List tickets

bash

python3 scripts/qianwen_support.py list --page 1 --page-size 10

View ticket detail + messages

bash

python3 scripts/qianwen_support.py view --ticket-id <id>

Fetch categories (always dynamic, never hardcode)

bash

python3 scripts/qianwen_support.py categories

Use references/ticket-categories.md for the category listing and references/category-selection.md for selection strategy.

Two category groups behave differently (match web frontend):

Model categories (Billing / Invoice / Feature Inquiry / API-SDK / Tool Integration): real ticket categories -> create ticket via CreateTicketNew.
App categories (MiaoWu / WanXiang / WuKong / QianWen / Qoder / QoderWork): the web frontend does NOT create tickets for these; it redirects users to the app's official site. ABSOLUTE PROHIBITION: do not create a ticket with an App category ID; instead guide the user to the app's official site (helpUrl).

Create ticket

bash

python3 scripts/qianwen_support.py create \
  --category-id <id> \
  --description "[QianWen-CLI] <summary>. <detailed description>..."

Description must start with [QianWen-CLI] prefix. First sentence becomes the ticket title. Max 2000 chars. The description template ([Symptom]/[Impact]/[Steps tried]/[Error details]/[Diagnostics]) is in references/operations-guide.md.

ABSOLUTE PROHIBITION: Never submit a ticket without showing the draft to the user and getting explicit confirmation first.

Reply to ticket

bash

python3 scripts/qianwen_support.py reply --ticket-id <id> --message "<text>"

MANDATORY: Check ticket status first. If terminal (closed/resolved/confirmed), refuse and offer to create a new ticket.

Close ticket

bash

python3 scripts/qianwen_support.py close --ticket-id <id>

After successful closure, always invite the user to rate.

Rate ticket

bash

python3 scripts/qianwen_support.py rate --ticket-id <id> --rating <0-2> [--comment "<text>"]

Rating scale: 0 = unsatisfied, 1 = neutral, 2 = satisfied. Support fuzzy input (number extraction, sentiment inference, original text as comment; full rules in references/operations-guide.md).

Step 4: Post-Operation

After ticket creation, report:

Ticket ID with hyperlink: https://platform.qianwenai.com/home/support/detail?id=<ticket-id>
Current status and expected response time (typically 24 hours)

Viewing Customer Service Replies

When reading replies via view, first check terminal status. For terminal tickets (closed/resolved/confirmed): display the summary, inform that replying is impossible, and offer to create a new ticket.

Rules:

Relay verbatim, never modify: present engineer replies exactly as-is; no deleting, summarizing, paraphrasing, or reorganizing.
Screenshot handling: CLI cannot display images. If a reply contains screenshots, inform the user to view them on the web portal and provide the ticket link.

Observability

User-Agent template (mandatory): every request issued by the scripts carries a User-Agent built from the template AlibabaCloud-Agent-Skills/{SKILL_NAME}/{session-id} skill-version/{version}, where {SKILL_NAME} is this skill's frontmatter name — alibabacloud-qianwenai-support — {session-id} is the session identifier described below, and {version} is derived exclusively from the top-level version field of references/manifest.json (never guessed; it must equal the frontmatter version). Resolved example: AlibabaCloud-Agent-Skills/alibabacloud-qianwenai-support/4eefc3a1be2102b3eb41463c84e98e9b skill-version/3.7.0.
session-id rule: generated once per session, as a 32-char lowercase hex string, and kept consistent across all requests of that session. The value is generated per script run (uuid4().hex) so that every request of one run reports the same id; it may be pinned externally via the SKILL_SESSION_ID environment variable, which is honoured only when it already is a valid 32-char lowercase hex string.
Backend mode logged to stderr: [WARN] Using API backend (CLI unavailable)

Error Handling

When a command fails, classify first, recover, then retry. Never silently skip to fallback. Core categories: auth-failure (re-login then retry), not-installed (show install command or API fallback), network-timeout (retry once, then web portal), ticket-not-found (verify via list), terminal-status (refuse, offer new ticket). Full table, retry parameters, cascading-failure rules, and exit codes: see references/error-handling.md.

Rule: Never retry more than once. If the retry also fails, immediately fall back to the web portal guidance (https://platform.qianwenai.com/home/support). Do not create retry loops.

Ticket Status Flow

Status	Terminal?	Can reply?
`created` / `assigned` / `dealing` / `processing` / `waiting_user` / `wait_feedback`	No	Yes (except `created`, waiting assignment)
`resolved` / `closed` / `confirmed`	Yes	No

ABSOLUTE PROHIBITION: Tickets in terminal status (closed/resolved/confirmed) MUST NOT be replied to or closed. The script enforces this; the Agent must not attempt to bypass it. The CLI does not enforce terminal-status restrictions on reply/close (calls may return success), so the Agent/script MUST check status first and refuse proactively.

Important Notes

Web Portal Guidance

When guiding users to the QianWen ticket page, always provide the specific ticket link:

text

https://platform.qianwenai.com/home/support/detail?id=<ticket-id>

Ticket ID Hyperlinks

Every ticket ID in output MUST be formatted as a hyperlink. Example:

Correct: Ticket 0005PYGCW
Wrong: Ticket 0005PYGCW (no link)

Reply Workflow

When a ticket has engineer replies, MUST follow this three-step workflow:

Display engineer reply verbatim — no summarizing, paraphrasing, or editing
Wait for user instructions — ask how to reply, wait for specific instructions
Draft and confirm — draft reply based on user instructions, get confirmation before submitting

Authorization Requests — Immediate Stop

When engineer requests authorization, immediately stop all other operations:

Stop current workflow
Inform user: "Authorization operations are prohibited in Agent; must be done by you on the web portal"
Provide ticket link
Relay the specific authorization request verbatim

Attachments — Strictly Prohibited

ABSOLUTE PROHIBITION: This skill MUST NOT upload any attachments (images, documents, logs, screenshots, archives, etc.). Always decline and direct users to the web portal.

Batch Operations — Not Supported

ABSOLUTE PROHIBITION: This skill MUST NOT perform batch operations (batch create/reply/close/rate/export). Only one ticket at a time.

Proactive Notification — Not Supported

ABSOLUTE PROHIBITION: This skill has no polling, listener or push channel. Never promise the user "I will tell you as soon as there is a new reply" or "I will notify you when the engineer responds". Correct phrasing is on-demand pull: "You can ask me to check the latest status of the ticket at any time." Prohibited forms include: "I will let you know", "I will ping you", "I will watch this ticket", "I will follow up for you automatically". Allowed forms: "ask me to check", "when you come back, I can fetch the latest status", "the ticket link is here for you to view at any time".

Customer Intent Fidelity

ABSOLUTE PROHIBITION: Never rewrite the customer's intent without evidence. Allowed operations: structured formatting, category tagging, attaching diagnostic data, masking sensitive values. Prohibited: colloquial-to-formal paraphrase, adding symptoms the customer did not state, replacing the customer's wording with a "more accurate" phrase, deciding on the customer's behalf (for example, silently downgrading severity). Preserve the customer's original description in preview-create; any transformation must be visible in the draft before confirmation.

Ticket Language

Ticket descriptions must be written in the support site's language regardless of the user's language. Customer original text, engineer replies, error logs, and code snippets are preserved verbatim without translation. Show both the English status and the localized name for clarity. Do not switch --accept-language away from the site default just because the user writes in another language.

Sensitive Info Masking

When composing ticket descriptions or replies, always mask sensitive info:

Email: zephy*****@gmail.com
Phone: 138****1234
API Key / AccessKey: sk-****xxxx
User ID: 08****94

Output Display Rules

Parse the JSON output and present a human-readable summary — never dump raw JSON. Add analysis AFTER the summary, separated with ---. Full rules and examples: see references/operations-guide.md.

Examples

Example: Create ticket

text

User: qianwen support list keeps returning 401, please help me submit a ticket

Agent (internal):
1. python3 scripts/qianwen_support.py doctor -> backend: cli, authenticated: true
2. 401 from `qianwen support` command -> CLI session issue -> guide user to re-login
3. User confirms still failing -> fetch categories -> draft ticket

Agent (to user):
Ticket draft:
**Title**: [QianWen-CLI] support list command keeps returning 401
**Category**: CLI & SDK Issues
**Description**: [Symptom] ... [Diagnostics] ...
Submit this ticket? (yes/no)

User: yes

Agent (to user):
Ticket submitted!
**Ticket [0005PYGCW](https://platform.qianwenai.com/home/support/detail?id=0005PYGCW)**
**Status**: Created - Expected response within 24 hours.

Example: List tickets

text

User: Help me check all my tickets

Agent (internal):
1. python3 scripts/qianwen_support.py list --page 1 --page-size 10

Agent (to user):
Your ticket list (page 1, 10 items):

| # | Ticket | Title | Status |
|---|------|------|------|
| 1 | [0007AB123](https://platform.qianwenai.com/home/support/detail?id=0007AB123) | qwen-vision API returns 401 | Created |
| 2 | [00069R8Z4Y](https://platform.qianwenai.com/home/support/detail?id=00069R8Z4Y) | support list returns 401 | Confirmed |

Showing latest 10. View next page? (yes/no)

Example: Terminal status ticket

text

User: reply to ticket 00069R8Z4Y

Agent (internal):
1. python3 scripts/qianwen_support.py view --ticket-id 00069R8Z4Y
2. status: "confirmed" -> terminal status -> refuse reply

Agent (to user):
Ticket [00069R8Z4Y](https://platform.qianwenai.com/home/support/detail?id=00069R8Z4Y) status is Confirmed.
This ticket is in terminal status and cannot be replied to. **Create a new ticket instead?** (yes/no)

Example: Model API 401 — correct handling (no auth login)

text

User: qwen-text returns 401, help me submit a ticket

Agent (internal):
1. doctor -> authenticated
2. 401 from model API (NOT from qianwen support) -> API Key issue
3. Do NOT run qianwen auth login
4. Draft ticket

Agent (to user):
Diagnosis: model API returns 401 and your API Key is set. This is likely a Key
permission or validity issue, NOT a CLI login problem (re-login cannot fix it).

Ticket draft:
**Title**: [QianWen-CLI] qwen-text API returns 401, Key is set
**Category**: Model > API/SDK
Submit this ticket? (yes/no)