AI 手机已经被讨论了好几年，但真正决定它能不能落地的，并不是手机上再加一个聊天入口，而是模型能否理解系统状态、规划多步操作，并在权限和安全边界内稳定执行。
在 9 月 22 日的云栖大会上，阿里千问发布了 AI 手机全栈解决方案 Qwen Intelligence。它不负责生产硬件，而是面向手机厂商提供一套“模型 + 平台 + 场景方案”的 AI 底座。方案的核心是系统级 Agent Harness，并通过多个 Agent 协同完成从意图理解到手机操作的闭环。
从“调用模型”转向“运行 Agent”
传统手机助手通常是这样的链路：用户输入问题，模型生成文本，应用再决定是否执行某个动作。这种模式适合问答，却很难处理“帮我找出上周收到的机票，并把行程加入日历”这类跨应用任务。
Agent Harness 解决的重点不只是模型能力，而是模型周围的运行环境。一个可用的手机 Agent 至少需要具备以下能力：
- 读取受控的系统和应用状态，而不是只看用户输入。
- 把自然语言目标拆成可验证的步骤。
- 调用日历、消息、搜索等工具，并处理工具返回结果。
- 在涉及支付、发送消息、删除数据等高风险操作时暂停并请求确认。
- 记录每一步的状态，失败后能够重试、回滚或向用户解释原因。
Qwen Intelligence 的定位正是把这些能力封装成手机厂商可以集成的系统级方案。根据发布信息，方案内置三大 Agent，其中 Mobile Planner Agent 负责充当手机的“大脑”，把用户目标转化为任务计划。其余 Agent 则可以理解为执行和协同层的一部分，具体职责应以厂商集成文档和实际产品定义为准。
“模型 × Harness”为什么比单独升级模型更重要
只提高模型参数量，无法自动解决手机操作中的几个硬问题。
第一，手机任务具有明显的状态依赖。模型必须知道当前页面、登录状态、权限状态以及上一步操作是否成功。第二，手机任务往往是长链路任务，一个步骤出错可能导致后续全部失效。第三，执行结果必须可观测，厂商需要知道任务在哪一步失败，而不是只看到一个“操作失败”。
Harness 可以把模型从一次性文本生成器变成受控的任务执行器。一个典型闭环可以表示为：
用户目标
-> Planner 生成结构化计划
-> Harness 检查权限、风险和前置条件
-> Executor 调用系统或应用工具
-> Harness 校验结果并更新状态
-> 成功、重试、回滚，或请求用户确认
这也解释了为什么发布信息把成功率提升到 90% 作为重要指标。成功率不是模型回答是否流畅，而是完整任务是否在真实环境中完成。不过，评估这个数字时仍然要看任务集合、设备环境、失败判定、是否允许人工确认等上下文，不能直接把它理解为所有手机操作都能达到 90%。
一个可改造的 Harness 最小实现
下面的 Python 示例不是 Qwen Intelligence 的官方 SDK，而是一个可以运行的最小化 Harness 原型。它演示了三个关键点：计划结构化、工具白名单和高风险动作确认。保存为 agent_harness_demo.py 后可直接运行。
from dataclasses import dataclass
from typing import Any, Callable
@dataclass
class Step:
tool: str
args: dict[str, Any]
risk: str = "low"
class Harness:
def __init__(self, tools: dict[str, Callable[..., Any]]) -> None:
self.tools = tools
def run(self, steps: list[Step]) -> list[Any]:
results = []
for index, step in enumerate(steps, start=1):
if step.tool not in self.tools:
raise ValueError(f"tool is not allowed: {step.tool}")
if step.risk == "high":
answer = input(
f"Step {index} will run {step.tool} {step.args}. Confirm [y/N]: "
)
if answer.lower() != "y":
return results + [{"status": "cancelled", "step": index}]
try:
result = self.tools[step.tool](**step.args)
results.append({"status": "ok", "step": index, "result": result})
except Exception as exc:
results.append({"status": "failed", "step": index, "error": str(exc)})
break
return results
def search_flights(keyword: str) -> list[str]:
return [f"Found calendar item matching: {keyword}"]
def add_calendar(title: str, date: str) -> str:
return f"Calendar event created: {title} on {date}"
if __name__ == "__main__":
# In production, these steps should come from a planner model and pass schema validation.
plan = [
Step("search_flights", {"keyword": "last week's flight"}),
Step(
"add_calendar",
{"title": "Flight itinerary", "date": "2025-09-28"},
risk="high",
),
]
harness = Harness({
"search_flights": search_flights,
"add_calendar": add_calendar,
})
print(harness.run(plan))
这个原型距离系统级手机 Agent 还有很大距离，但边界已经比较清楚：Planner 只负责提出结构化计划，Harness 负责校验和调度，工具层负责执行具体动作。实际接入手机系统时，还需要增加权限映射、超时控制、幂等键、状态持久化、审计日志和敏感数据脱敏。
手机厂商真正需要关注什么
Qwen Intelligence 对手机厂商的价值，不只是减少一次模型接入工作，更在于提供从底层模型到场景落地的组合方案。厂商可以把精力放在设备能力、系统体验和分发渠道上，而不必从零搭建每一个 Agent 基础设施组件。
但一站式底座并不意味着集成工作消失。落地时至少要验证四组问题：
- 权限边界：Agent 能读取哪些应用数据？哪些动作必须弹窗确认？权限是否能被用户随时撤回？
- 失败处理：网络中断、页面变化、登录过期或工具返回异常时，系统如何恢复？
- 隐私与数据驻留：哪些内容发送到云端，哪些内容必须留在设备端？日志中是否会记录短信、联系人或位置数据？
- 评测口径：90% 的成功率对应哪些任务？是端到端一次成功，还是允许多次重试和人工确认？
AI 手机的竞争，最终不会只看谁把一个更大的模型放进系统设置，而会看谁能把 Agent 做成稳定、可解释、可控的系统能力。Qwen Intelligence 把这条路线概括为“模型 × Harness”，对行业的启发是：模型是能力来源，Harness 才是把能力变成产品的工程边界。
落地检查清单
- 用结构化计划替代直接执行自然语言。
- 为每个工具定义参数模式、权限级别和超时策略。
- 对发送、购买、删除和隐私数据导出等动作强制二次确认。
- 保存每一步的输入、输出和失败原因，便于评测和调试。
- 用真实跨应用任务评估端到端成功率，而不是只测试单轮问答。
- 把成功率和用户信任一起纳入上线门槛。
对于手机厂商和系统开发者而言，Qwen Intelligence 值得关注的并不是“AI 手机”这个概念本身，而是它把 Agent 从一个应用层功能提升为系统级基础设施之后，带来的产品和工程变化。