AI Phone L1-L4 Intelligence Levels: 2026 Test Guide
Understand China’s GB/Z 177-2026 AI phone L1-L4 intelligence levels, what they do not certify, and how to run a practical phone test.
- GB/Z 177-2026 is a Chinese national standardization guiding technical document, not automatic product certification for any named phone.
- The official AI phone L1-L4 intelligence levels progress from response to tool, assistance, and collaboration, with L4 still expected to be clarified as the industry develops.
- A practical smartphone intelligence test should record task completion, user control, state verification, recovery, and repeatability separately.
- FoneClaw can be used as an ungraded governed Android test route for floating access, user-triggered screen context, approvals, stopping, recovery, and supported capability routing.
Identify GB/Z 177-2026 and Its Scope
China’s 2026 AI-terminal intelligence grading framework gives the phone industry a clearer way to talk about AI phone L1-L4 intelligence levels. The important starting point is scope. The SAMR records for GB/Z 177.1-2026, GB/Z 177.2-2026, and GB/Z 177.3-2026 show that all three were published on April 30, 2026. Part 1 is the reference framework, Part 2 covers general requirements, and Part 3 covers mobile terminals.
The format also matters. GB/Z is a national standardization guiding technical document. That makes it useful for terminology, product planning, comparison, and test design, but GB/Z is not a mandatory law and does not automatically certify any named phone. A brand saying a phone is “AI-ready” or “agentic” is still a marketing claim unless the claim is tied to a named document, a test scope, and evidence.
The MIIT announcement of the AI-terminal grading series describes a 2+N architecture and says the first batch covers seven terminal categories. For mobile readers, Part 3 is the relevant document because it applies the framework to mobile terminals. The practical job in this guide is to turn the official ladder into observable phone behavior without inventing conformance thresholds.
Explain the Official L1-L4 Names Without Overclaiming
The official levels are L1 response level (响应级), L2 tool level (工具级), L3 assistance level (辅助级), and L4 collaboration level (协同级). MIIT says intelligence rises by level. That is enough to build a useful interpretation, but not enough to invent a single universal checklist that proves every phone’s exact level in every setting.
| Level | Plain-English meaning | Observable phone behavior | What it does not prove |
|---|---|---|---|
| L1 response | The assistant can respond to user input. | It answers a question, explains visible information, summarizes text, or replies conversationally. | It does not prove the phone can act through apps or manage device state. |
| L2 tool | The assistant can use a tool-like capability. | It opens a supported feature, calls a defined capability, or prepares a bounded device action. | One tool call does not prove planning, recovery, or cross-app continuity. |
| L3 assistance | The assistant helps complete a task with context and controlled steps. | It decomposes a goal, uses relevant context, asks for missing information, requests approvals, and verifies the result. | A single successful demo does not prove broad L3 behavior. |
| L4 collaboration | The assistant works with the user across a more collaborative process. | It maintains task context, coordinates steps, handles interruptions, and adapts with the user over a longer workflow. | MIIT says L4 will be further clarified and improved as the industry develops. |
The table is an interpretation for readers, not a substitute for the official document. The safest way to use the AI phone grading standard is to ask what was tested, under what device conditions, with which apps and permissions, and how many times the task repeated successfully.
For general AI-phone vocabulary, Agentic Phone Explained: What an Agentic AI Phone Means in 2026 provides the broader definition. This article stays focused on the official L1-L4 ladder and how to translate it into test evidence.
Distinguish Useful Assistance From Collaboration
The most important practical boundary is between a helpful assistant and a collaborative phone agent. A phone can feel intelligent at L1 or L2 because it answers quickly or calls one visible feature. That is useful, but it does not show that the system can carry a task through ambiguity, interruption, permission prompts, and recovery.
An L3 AI phone claim should be tested around assistance. Can the system understand a goal rather than only a command? Can it break a task into steps? Can it use the current screen, a calendar entry, a message draft, a setting state, or an app surface only when relevant? Can it ask before a consequential action and confirm the final state? Those are the behaviors that separate assistance from one-off response and tool use.
L4 is more demanding because collaboration implies a longer user-agent relationship. A collaborative phone should stay oriented across steps, recover from blocked conditions, adapt when the user changes direction, and keep control visible. MIIT’s statement that L4 will be further clarified and improved is important. It tells buyers and builders to treat L4 as a developing target rather than a finished universal label.
One polished demo cannot establish L3 or L4. A demo may be scripted, app-specific, language-specific, or dependent on a perfect network and pre-granted permissions. A credible level claim needs repeatable evidence across relevant tasks, devices, accounts, permissions, languages, and recovery scenarios. For deeper benchmark design, Android Phone Agent Benchmark Guide: Reliability, Safety, and Task Success extends the test methodology beyond this standards overview.
Run a Practical AI Phone Intelligence Test
A field test is not an official conformity assessment. It is a practical way for buyers, reviewers, and builders to compare phones or phone agents using the same task sheet. Keep the setup controlled: same device, account type, language, network condition, permissions, app versions, region, and starting screen. Record task success, confirmation behavior, state verification, recovery, and repeatability separately.
| Test | Task prompt | What to observe | Evidence to record |
|---|---|---|---|
| Response task | Ask the assistant to summarize a visible article or explain a setting. | Does it answer accurately from the provided context? | Answer quality, context use, and whether it invents unsupported actions. |
| Tool task | Ask for a reversible device check, such as reading a setting or status. | Does it use the correct supported capability? | Tool route, permission requirement, and visible result. |
| Assistance task | Ask it to prepare a calendar event, message draft, or route handoff from visible context. | Does it gather missing details and stop before external effects? | Clarification, approval, draft preview, and final state check. |
| Interruption task | Start a multi-step task, switch apps, then return. | Does it preserve task identity and resume safely? | State continuity, stale-screen detection, and user control. |
| Permission task | Start a task that needs a missing Android permission or special access. | Does it guide permission recovery without losing the task? | Permission path, blocked state, and re-check after recovery. |
| Collaboration task | Ask for a longer workflow with user choices, context changes, and a reversible final action. | Does it adapt while keeping control visible? | Plan updates, approvals, stop behavior, recovery, and repeatability. |
Use a simple scoring sheet. Mark completion separately from control. A task can finish but still be unsafe if it acted without approval. A task can fail but still be well-designed if it stopped, explained the block, preserved state, and offered a safe recovery. Repeat each task several times because reliability is the difference between a demo and a dependable phone behavior.
The field test also helps explain why L4 remains a moving target. Collaboration is not just more autonomy. It is more dependable cooperation between user, context, tools, permissions, and recovery. A phone that races ahead without visible control may look powerful, but it will score poorly on governed execution.
Evaluate Permissions, Approvals, Interruption, Recovery, and Traceability
The AI phone grading standard should not be read as a race toward less user control. Higher intelligence on a phone increases the need for clear authority. Consequential actions need explicit controls: sending a message, placing a call, deleting data, changing a system state, making a payment, booking, sharing location, or modifying an account should be visible and reviewable.
Permission behavior is the first safety signal. A phone agent should know when it lacks permission, explain what is needed, route the user to the right settings page where appropriate, and re-check the original task after access changes. Permissions alone do not guarantee control; they simply define what the system is allowed to attempt.
Approval behavior is the second signal. A reliable assistant should bind approval to a specific task, target, proposed effect, and current context. If the user switches conversations or the visible screen changes, the approval should not silently transfer to another action. For approval interaction design, AI Agent Approval UX on Phones: Confidence, Rationale, and Recovery goes deeper into confidence, rationale, and recovery.
Recovery and traceability are the final signals. A useful evaluation records how the agent stops, resumes, retries, and reports state. Did it verify that Do Not Disturb changed? Did it keep the draft unsent until approval? Did it know that an app screen was stale? Did it leave enough trace for the user to understand what happened? Controlled failure is part of intelligence on a phone.
Use FoneClaw as a Governed Android Test Route
At FoneClaw, we treat this framework as a useful way to separate marketing language from observable Android behavior. According to the latest FoneClaw product information available as of this article update, FoneClaw Download provides floating access through a movable assistant, user-triggered current-screen attachment, and task continuity across entry points. Those capabilities make the field test easier because the user can begin from the screen where the task actually appears.
We do not assign FoneClaw an official L1-L4 level in this guide. Instead, we use it as an ungraded test route for governed execution. A configured model reasons and plans, while FoneClaw routes supported requests to the Android capability that owns the job: screen and app context, device state, system controls, navigation, communication, calendar, memo, workflows, skills, plugins, and other supported paths where available. Current capabilities, including the stable 100+ built-in tools language, are summarized on FoneClaw Features.
The behaviors to observe are the same ones the field test asks for: does the assistant attach the current screen only when the user triggers it, preserve task continuity, ask for approval before sensitive actions, keep stopping available, recover from missing permissions, and verify visible state after execution? These are the practical controls that make an Android phone-agent route testable.
A reversible starter test is enough. Open the floating assistant over a visible settings screen, attach the screen, ask for an explanation, then request a supported low-risk state check or draft preparation. Confirm only after the proposed result is clear. This does not prove a formal level, but it gives the reader evidence about the parts that matter: context entry, capability routing, approval, recovery, and repeatability.
Choose or Build an AI Phone Using Evidence
Use the L1-L4 framework as a discipline for evidence. If a phone, assistant, or agent claims a level, ask which standard part is being referenced, which task scope was tested, and whether the result covers only response, a tool call, task assistance, or longer collaboration. Availability and behavior can vary by device, account, permissions, language, region, and software version.
- Ask for the test scope: device model, software build, language, region, app versions, account type, and permission state.
- Ask for the task sheet: response, tool, assistance, interruption, permission recovery, and collaboration tasks.
- Ask for control evidence: approvals, stopping, visible state, and action preview.
- Ask for recovery evidence: what happens when the app changes, permission is missing, or the network fails.
- Ask for repeatability: run the same task multiple times and record failures, not only successes.
- Ask for traceability: the user should know what the assistant prepared, changed, skipped, or left for manual action.
For builders, the adjacent architecture question is how the OS, model, tool layer, and user controls fit together. The OS Agent Foundation a Practical Phone AI Agent Needs in 2026 covers that design layer. For buyers, the conclusion is simpler: trust evidence over labels, test the exact phone workflow you need, and retest after meaningful software updates.