企业官网建设流程全解析

如果你关注过 2024 到 2025 年这一波“AI 手机”的营销大战，会发现一个现象：几乎所有厂商都在谈大模型、谈端侧推理、谈智能助手，但真正落到日常使用，大部分场景还是“你问一句，它答一句”。用户问天气、问百科、生成个文案，本质上和过去的语音助手没有代际差异。

真正的变化，发生在“目标”这个词上。

当用户不再需要说“帮我打开携程，查下周五上海到北京的机票”，而是说“我周五要去北京出差，你帮我安排一下”，手机里的 AI 才真正开始从“语音助手”变成“Agent”。而一套关于“手机里 Agent 到底能自主到什么程度”的行业分级，在过去一年里被反复讨论，其中以 L3 为分界线的讨论尤其多。

这篇文章我想先把结论放在前面：

L3 的价值，不在于又多了一个营销术语，也不在于“国标”二字本身，而在于它第一次为“手机里的人工智能到底可以多主动”这件事划出了一条可讨论、可设计、可评测的边界。

它让开发者第一次可以回答三个以前回答不了的问题：

• 这个 Agent 在什么条件下可以自主执行？
• 哪些动作必须回到用户确认？
• 不同厂商间的智能能力，拿什么尺度横向比较？

但是，如果你真的进入这个领域去开发，会发现 L3 只是起了个头。手机 AI Agent 后半场的竞争，不会停在“能不能自主订机票”，而会在工程架构、生态标准、权限边界、评测体系和跨应用协作这些更深的水域里展开。

这篇文章会从一条主线讲清楚这件事：先从 L3 分级的技术含义讲起，再拆解 AI Agent 手机的核心架构，然后落到开发者能动手做什么。最后，我会给出一份基于真实工程经验的实践路线，帮你在“L3 只是起点”这件事上，找到自己的切入点。

1. 为什么“L3”成了 AI Agent 手机的分水岭

1.1 从“能说话”到“能干活”，是一个代际跃迁

我们回顾一下手机 AI 的演进，大致可以分成三个阶段。

第一阶段是语音助手时代。Siri、Google Assistant、小爱同学、Bixby 都属于这一类。它们的核心能力是“听懂指令并执行”，但指令必须是用户完整给出的。用户说“设置十分钟后的闹钟”，它去做；用户说“附近有什么川菜馆”，它调起地图服务返回结果。整个交互链路里，决策权完全在用户手里，AI 只是一个个单项指令的翻译器。

第二阶段是大模型手机时代。端侧大模型让手机具备更强的语义理解、生成和摘要能力。它能写文案、改写内容、总结长文、识图问答。但注意，这些能力仍然是“单轮生成”或“单轮理解”，没有构成一个完整的行动闭环。用户说“把这篇论文总结成一页 PPT 大纲”，AI 做完了，任务就结束了。

第三阶段才是 AI Agent 手机时代。它和前两代的本质区别在于：用户提供的是一个目标，而不是一串指令。

用户说“帮我策划一场月底的同学聚会”，Agent 需要自己去拆解这个目标——确定时间、筛选地点、对比餐厅、生成邀请文案、发给指定的人。这个过程涉及多个应用、多个工具、多次判断，甚至需要根据闭环反馈不断修正之前的决策。

从“能说话”到“能干活”，这个跃迁才是 AI Agent 手机真正的判断标准。

1.2 L3 的边界：有条件的自主行动

那么 L3 在这个跃迁里处于什么位置？

在行业讨论里，手机 AI Agent 的分层模型大致可以这样理解：

这里需要特别澄清一个常见误区：L3 不是“全程不需要人管”。

L3 的关键词是“有条件”和“关键节点确认”。支付、发送消息、删除数据、提交订单这类不可逆动作，仍然必须回到用户。判断一个系统是不是真的到了 L3，要看的是它在常规步骤上是否具备自主决策能力，而不是看它能不能一句指令做一件事。

从产品设计角度理解，L3 是一道非常清晰的“信任分界线”。在 L2 阶段，用户每一次点击确认，都是在为 AI 的错误兜底。到了 L3，AI 需要在同一目标下连续执行 5 到 10 个工具操作，并且每一步都要保证之前的动作没有跑偏。这带来的工程难度，不是线性的，而是指数级的。

1.3 为什么需要一套“国标”式的分级

这里要先说明，所谓“L3 国标”，准确说是一个行业正在推动形成共识的方向，而不是某个已经落地、具有强制效力的细则。但为什么行业需要这样一套标准？

第一，统一预期。过去厂商宣传“AI 手机”，有的只说有端侧大模型，有的说能生成文案，有的说能跨应用操作，用户无法比较。分级之后，用户只要看“L2 还是 L3”，就知道这款手机里的 Agent 到底能自主到什么程度。

第二，明确责任边界。如果 Agent 自主完成了一次错误操作，责任是谁的？是手机厂商、应用开发者，还是用户？分级标准和事后可追溯的日志系统，是划定责任的前提。

第三，统一交互协议和评测基准。没有分级的时候，每个厂商对自己的 Agent 说“很强”，但拿什么指标衡量？L3 出现之后，行业才可能形成一套统一的任务评测集——比如“给定目标，Agent 在 N 步内完成，且用户介入次数不超过 M 次，则判定为 L3”。

对开发者来说，这套标准的意义在于：它把“AI Agent 手机”从一个模糊的概念，变成了一个可以用工程手段去逼近的目标。

1.4 小结

L3 之所以成为分水岭，不是因为它定义了某个炫酷的新功能，而是因为它定义了“手机 AI 何时可以开始对结果负责”。从这一刻起，AI 不再只是一个“回答问题的人”，而是一个“执行任务的人”。这就是为什么说，L3 是整个手机 Agent 生态真正转向“可用”的起点。

2. AI Agent 手机的核心技术架构

如果只把 L3 理解成一句话，那它就只是发布会上的一个标签。真正让它成立的东西，是背后一整套工程架构。

2.1 从五层架构看 Agent 手机

一个达到 L3 能力的手机 AI Agent，至少在系统层面需要具备以下五层能力：

感知层（Perception）：理解用户输入，包括文本、语音、图像、屏幕内容。因为很多任务不是靠一句自然语言就能说清的，Agent 需要能“看到”当前屏幕，才能知道怎么操作。

意图层（Intention）：把用户的目标解析成一个明确的、可拆解的任务。这里涉及意图识别、槽位抽取、歧义消解。比如“帮我订周五去北京的票”，是谁去？去几天？高铁还是飞机？预算多少？这些未明说信息，Agent 要么推理补全，要么主动追问。

规划层（Planning）：这是 L3 最核心的一层。Agent 要能自己生成一个多步行动计划，包括调用哪些工具、按什么顺序调用、何时需要用户确认。

执行层（Execution）：真正去调用系统 API、第三方应用接口、或者通过无障碍服务模拟点击操作屏幕上的按钮。执行层的好坏，直接决定 L3 的稳定性。

记忆层（Memory）：包括短期记忆（当前任务上下文）和长期记忆（用户偏好、历史习惯）。没有记忆的 Agent，每次对话都是“失忆”的，不可能在连续任务中做到真正的个性化。

这五层不是独立存在，而是一条流水线：感知进来，意图消化，规划决策，执行落地，记忆贯穿始终，最后形成反馈回到感知层。

传统手机上的语音助手，只实现了感知+执行，中间缺少规划层。大模型手机加上了意图层，但仍未解决规划层的问题。L3 Agent 手机真正补上的，就是规划层这个“大脑”。

2.2 端云协同：L3 为什么离不开端侧

你可能会有疑问：Agent 规划这么复杂，为什么不全部放到云端？

一个真实原因是隐私和响应速度。手机上的很多操作涉及个人数据——通讯录、位置、照片、聊天记录。如果每个任务都把数传上云，用户心理门槛和合规风险都会很高。而端侧大模型可以在不离开设备的情况下完成一部分感知和意图理解，敏感数据不出端。

但从当前硬件条件看，端侧推理能力还不足以支撑完整的 L3 规划。可靠的做法是端云协同：端侧负责“轻量意图理解+隐私数据处理+本地工具执行”，云侧负责“复杂规划+大模型推理+知识检索”。两边通过一套中间协议交换任务状态。

这也是为什么 L3 手机 Agent 的工程复杂度，远高于一个单纯的“云上聊天机器人”。它要能在两端之间优雅地切换，还能在网络断开时降级处理。

2.3 工具调用（Function Calling）是执行层的基石

L3 的一个显著特征是“执行”，而执行必然意味着调用外部工具。大模型本身不产生行动，它只产生决策。真正让行动落地的是工具调用机制。

一个典型的 Function Calling 过程是这样的：

1. 开发者定义一个函数结构，描述函数名、参数和用途。
2. 模型根据用户意图，决定是否需要调用该函数、传入什么参数。
3. 系统执行函数，把结果返回给模型。
4. 模型根据函数结果，决定下一步动作。

在手机场景里，这些“函数”可以是系统 API（打开蓝牙、创建日历事件）、第三方 App 的开放接口（调用地图、预订酒店）、也可以是 Agent 自己定义的原子技能（Skill）。

2.4 从单体指令到 BDI 式决策

早期 Agent 实现喜欢用“如果用户说 A，就执行 B”的规则。但到了 L3，任务不可枚举，Agent 需要一种更接近人的决策模型。

业界常用的是 BDI（Belief-Desire-Intention）模型的思想：

• Belief：Agent 对当前状态的理解，来自感知和记忆。
• Desire：用户目标经过解析后形成的意图。
• Intention：Agent 为达成 Desire 选定的行动计划。

L3 的“自主”就体现在 Intention 层：Agent 可以根据环境反馈动态修改计划，不需要每一次调整都询问用户。比如原计划订的航班取消了，Agent 收到通知后可以自动改签，只要改签方案在用户设定的价格和时间范围内。

这一点，才是“有条件的自主”的真意——用户给的是边界，Agent 在边界内做决策。

3. Agent、Skill 与工具：三个容易混淆的概念

很多刚开始学习 AI Agent 开发的人，会卡在一组概念的区分上：Agent、Skill、Tool 和 Workflow。这三个概念如果不理清楚，后面搭建 L3 任务时会非常混乱。

3.1 三者关系

我用一个比喻来讲：如果你把 Agent 看成是一家公司的“项目经理”，那么：

• Tool 是“基础工具”，比如电话、邮箱、打印机。它是单个动作的执行器。
• Skill 是“标准作业流程”，比如“完成一次差旅预订”“整理一份周报”。它是一个经过封装的能力包，内部可能调多个 Tool。
• Workflow 是“跨角色协作流程”，比如“从差旅申请到报销入账”，可能需要财务 Agent、行政 Agent、员工 Agent 一起配合。

核心区别是：Tool 负责“怎么执行”，Skill 负责“如何完成一类目标”，Workflow 负责“多方如何协作”。

很多新手把 Tool 直接当成一个 Agent 的全部能力，这是不对的。L3 自主能力的真正含量，体现在 Skill 的丰富度上。一个 Agent 如果只有十个底层的 Function，那它做什么都笨；如果它有了一个成熟的“行程规划 Skill”，那它面对“帮我安排五一出行”这种宽泛请求时，才能像经验丰富的秘书一样有章法。

3.2 一个 Agent 任务定义示例

下面这份 JSON 是一个“通用思路”的 Agent 描述文件，用于帮你理解 Agent、Skill、Tool 如何组织。注意，这不是某个厂商的官方 SDK，而是一个便于理解的示例结构：

{ "agent": { "id": "travel_agent", "name": "差旅助手", "description": "负责处理差旅相关的查询和预订任务", "l3_autonomy": true, "requires_confirmation": ["book", "pay", "cancel"], "memory": { "enabled": true, "scope": "user_preferences" }, "skills": [ { "id": "flight_search", "name": "航班查询", "tools": ["search_flight", "compare_price", "query_schedule"] }, { "id": "hotel_booking", "name": "酒店预订", "tools": ["search_hotel", "query_room", "reserve_hotel"], "confirmation_required": true }, { "id": "itinerary_build", "name": "行程编排", "tools": ["build_timeline", "add_reminder", "sync_calendar"] } ] } }

这里值得注意的地方是requires_confirmation和confirmation_required。它们是 L3 安全边界的关键。预订、支付、取消这类不可逆动作，Agent 必须停下来等用户确认；“行程编排”这种低风险动作，则可以自主完成。

3.3 Skill 开发为什么是下半场的重点

之前 Hugging Face 等社区在讨论 Agent 术语时，有一个核心观点：Agent 的能力取决于它可以调用的 Skill 的数量和质量。手机 Agent 上半场比拼的是“谁的模型推理强”，下半场比拼的则是“谁的 Skill 生态丰富”。

原因很简单。模型能力是可以通过采购、微调、蒸馏获得的，但一个能正常工作的“差旅预订 Skill”，需要踩过无数真实业务的坑：航空公司改签政策、退票手续费、不同平台的支付限制、酒店价格浮动的规则。这些工程沉淀，很难通过买模型得到。

所以，如果你现在想进入 AI Agent 手机生态，最务实的切入点不是去训练一个大模型，而是去研究“某个垂直场景到底需要哪些 Skill，以及这些 Skill 怎么被一个 L3 Agent 安全地编排起来”。

4. 开发者如何从 L3 切入：一个最小的示例

前面讲了不少概念。这一节我们落到代码层面，演示一个最小可运行的 L3 式 Agent 雏形。

需要提前声明：这里用的是通用 Python 示例，不代表任何手机厂商的官方 SDK。重点是理解“规划—执行—确认—反馈”的 L3 循环。

4.1 环境准备

基础环境要求如下：

• Python 3.10 或更高版本
• 一个支持函数调用（Function Calling）的大模型 API
• 依赖库：openai、requests、rich

安装依赖：

pip install openai requests rich

4.2 定义工具函数

先定义两个基础 Tool。一个是查询航班，一个是模拟预订操作。

# t_tools.py def search_flight(departure: str, arrival: str, date: str) -> dict: """ 模拟航班查询。真实项目中这里会调用航司或票务平台 API。 """ flights = [ {"id": "CA123", "departure": departure, "arrival": arrival, "date": date, "time": "08:00", "price": 1280}, {"id": "MU456", "departure": departure, "arrival": arrival, "date": date, "time": "10:30", "price": 980}, {"id": "CZ789", "departure": departure, "arrival": arrival, "date": date, "time": "15:20", "price": 1520}, ] return {"flights": flights} def book_flight(flight_id: str, username: str) -> dict: """ 模拟航班预订。真实项目中这是不可逆操作，L3 下必须用户确认。 """ return {"status": "booked", "flight_id": flight_id, "username": username}

这两个函数代表 Tool 层。search_flight是只读动作，L3 可以自主调用；book_flight是写入动作，必须有确认环节。

4.3 把工具注册给模型

接下来，把这两个函数以 JSON Schema 的方式注册给大模型。这里只展示核心的两个函数定义：

# t_agent.py tools = [ { "type": "function", "function": { "name": "search_flight", "description": "查询从出发地到目的地的航班列表", "parameters": { "type": "object", "properties": { "departure": {"type": "string", "description": "出发城市"}, "arrival": {"type": "string", "description": "到达城市"}, "date": {"type": "string", "description": "日期，格式 YYYY-MM-DD"} }, "required": ["departure", "arrival", "date"] } } }, { "type": "function", "function": { "name": "book_flight", "description": "预订航班。需要用户确认后才可调用。", "parameters": { "type": "object", "properties": { "flight_id": {"type": "string"}, "username": {"type": "string"} }, "required": ["flight_id", "username"] } } } ]

这里真正重要的不是 schema 本身，而是你在设计时给book_flight这类函数留下的“用户确认”预期。模型需要知道，这个动作不能自主执行。

4.4 主循环：规划、执行、确认、反馈

下面是主循环代码：

# t_agent.py（续） from openai import OpenAI from rich.console import Console from t_tools import search_flight, book_flight console = Console() api_key = "your-api-key" # 请替换为实际可用的 API Key client = OpenAI(api_key=api_key) def ask_model(messages): return client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=tools, tool_choice="auto" ) def run_agent(user_message: str, username: str): messages = [ {"role": "system", "content": "你是手机上的 L3 智能助手。你可以自主完成查询类操作。" "只要是预订、支付、删除等不可逆操作，必须先向用户确认，" "得到确认后再调用工具。"}, {"role": "user", "content": user_message}, ] # 第一轮：模型可能返回工具调用请求 resp = ask_model(messages) msg = resp.choices[0].message messages.append(msg) if msg.tool_calls: for tc in msg.tool_calls: fn_name = tc.function.name args = eval(tc.function.arguments) if fn_name == "search_flight": result = search_flight(**args) console.print(f"[cyan]> 自主查询航班：{args}[/cyan]") elif fn_name == "book_flight": # L3 安全边界：写入操作必须用户确认 console.print(f"[yellow]> 请求预订航班：{args}[/yellow]") confirm = input("确认预订？(y/n): ") if confirm.lower() != "y": result = {"status": "cancelled_by_user"} else: result = book_flight(**args) messages.append({ "role": "tool", "tool_call_id": tc.id, "content": str(result) }) # 第二轮：把工具结果交还模型，生成最终回答 final_resp = ask_model(messages) final_msg = final_resp.choices[0].message console.print(f"[green]> Agent 回复：{final_msg.content}[/green]") if __name__ == "__main__": # 示例：查询航班 + 尝试预订 run_agent("帮我查一下周五从上海到北京的航班，并预订最早的那班", "zhangsan")

4.5 运行与验证

运行方式：

python t_agent.py

预期的运行流程：

1. 模型收到“查询+预订”的目标后，会先调用search_flight。
2. Agent 打印出“自主查询航班”。
3. 模型会基于航班结果发起book_flight。
4. 此时程序打印确认提示，用户在终端输入y或n。
5. 最终模型根据执行结果生成总结回复。

判断运行成功的标准有三条：

• 只读操作（查询）没有经过用户确认。
• 写入操作（预订）在用户确认前没有被真正执行。
• 最终回复引用了工具的执行结果，而不是模型自己编出的航班信息。

如果第二步模型直接调用了book_flight，说明你的 system prompt 没有设置好安全边界，或者选择的大模型不支持严格的工具调用策略。这时候优先检查 system prompt 和工具描述。

这段代码很小，但它确实实现了一个核心的 L3 循环：目标驱动、自主规划、只读可自主、写入需确认。你把这个循环扩展 100 个工具，再配上可靠的记忆和评测，就是一个接近真实产品的 Agent 雏形了。

5. 从 L3 走向更高等级，还有哪些硬骨头

L3 只是起点。这句话不是口号。如果顺着 L3 往 L4、L5 走，你会撞到几块真正的硬骨头。

5.1 长任务可靠性

L3 的任务通常需要 5 到 15 个工具调用。L4 的任务可能持续几小时甚至几天，中间涉及数十次工具调用。问题是，大模型在长上下文里会丢失细节，早期决策的误差会被累积放大。

业界在做“多 Agent 协同”时，就是试图解决这个问题：让多个负责不同子任务的 Agent 并行工作，主 Agent 负责协调，而不是把全部任务压在一个超长上下文中。这种架构能降低单 Agent 的负担，但它要求 Agent 之间有稳定的协议、任务状态同步和失败回滚机制。这个问题目前并没有完美答案。

5.2 评测比开发更难

传统软件的评测很容易：输入进，断言输出。L3 Agent 的评测则是开放式的：同样一个“安排周五出差”的目标，可能有一百种合理的执行路径。你怎么判断某个 Agent 的规划是更优的？

业界已经有不少 Agent Benchmark 在做这件事，但从当前讨论来看，评测的核心难点在于“任务成功”的定义。是看最终结果对不对，还是看路径是否高效？是看用户介入次数，还是看兜底恢复能力？A 厂商的 Agent 可能结果正确但步骤繁冗，B 厂商的 Agent 步骤简洁但偶发失败。它们谁的 L3 更强？这类问题，还没有普适答案。

5.3 可解释性与失败恢复

一个 L3 Agent 说“我已经帮你订好了”，用户如何知道它哪里做了决策？后来内容对不对？如果用户发现问题，能不能把 Agent 的动作“撤销”？

这就要求系统为每次 Agent 行动记录完整的执行轨迹（trace），包括意图、规划、每个工具调用的输入输出、确认点、最终结果。它既是事后追责的证据，也是用户信任的基础。

更重要的是失败恢复：Agent 在某一步操作失败时，是停下来等用户？还是换个方案重试？还是回滚到上一个安全状态？这决定了 Agent 的“责任心”。

5.4 安全、隐私与授权边界

这是最敏感、也最不能绕开的问题。L3 的自主行动能力，意味着 Agent 需要更大的系统权限：读取位置、读取图片、操作日历、发送消息。权限越大，越需要精细的授权机制。

我的建议是：对所有 Agent 操作，至少要区分三个安全级别：

• 只读操作：可自主执行，但敏感信息如密码、身份证号等需要隐藏。
• 执行操作：需要用户确认。
• 破坏性操作：不仅需要确认，还要二次确认或需要生物识别。

开发者在设计工具 schema 时，就要把每个函数标注好“是否可自主执行”，而不是让模型自由猜测。这是 L3 能否落地的工程前提。

5.5 跨应用协作的标准化难题

目前手机 Agent 的真实难点不是“模型能不能推理”，而是“能不能获得服务的入口”。不同 App 是否提供开放接口？是否允许 Agent 读取数据？是否愿意被另一个系统编排？

这就是为什么手机厂商比普通开发者更有动力去推 L3 标准。只有应用厂商愿意开放服务接口，Agent 才可能真正跨应用工作。否则，Agent 只能停留在“模拟点击屏幕”的阶段，脆弱且不稳定。

从趋势看，未来的手机 Agent 生态很可能会形成类似 App Store 的“Agent 应用市场”。应用通过暴露标准化的“服务描述文件”（类似 HTTP API 的 OpenAPI）来描述自己的能力，Agent 动态发现并调用。真到这一步，AI Agent 手机才算是完成了从“演示”到“生态”的转身。

6. 给开发者的行动建议

说了这么多，最后落到一个更实际的问题：现阶段，普通开发者应该怎么进入 AI Agent 手机生态？

6.1 先掌握三个基本功

6.2 找一个最小真实场景，跑通一个 L3 循环

我不建议一上来就去搭一个全知全能的大 Agent。更务实的路线是：

1. 选定一个你熟悉的垂直场景，比如“差旅安排”“会议纪要整理”“快递追踪”。
2. 把该场景里的关键操作抽象成 3 到 5 个 Tool。
3. 用 L3 规则（只读自主、写入确认）实现一个最小 Agent。
4. 连续用 10 个不同表达的目标去测试它，记录成功率和用户介入次数。
5. 不断优化 system prompt、工具描述和任务规划提示。

参考已经存在的开源项目会很有帮助，GitHub 上可以找到不少 Agent 开发脚手架，包括多 Agent 协同、Skill 库、记忆模块等。结合自己的场景改造它们，比从零造轮子效率高得多。

6.3 关注评测与可观测性

从 L3 起，Agent 开发的核心问题不再是“模型会不会回答”，而是“任务是否可靠完成”。这意味着你要建立一套可度量的评测集。

建议至少记录四个指标：

• 任务完成率：目标是否在限定步数内达成。
• 用户介入次数：每 10 个任务，用户平均需要确认多少次。
• 错误恢复率：任务中途出错后，Agent 是否能自行恢复。
• 平均完成时长：从用户下单到目标完成的时间。

这些指标，比“模型答得漂亮”更能说明 L3 的水平。你未来在团队里推进 Agent 项目时，也需要靠这些数据说服业务方。

6.4 安全与合规意识要前置

最后提醒一点：L3 Agent 涉及用户真实操作，容易踩安全红线。

• 涉及用户敏感数据时，必须最小化采集，并在端侧完成处理。
• 不允许 Agent 在没有用户确认的情况下执行支付、发送、删除、发布等动作。
• 所有 Agent 行动要保留 trace，便于审计和回滚。
• 生产环境上线前，必须在测试环境用全量测试集验收，并设置开关和阈值，异常时人工接管。

这些原则听起来像是“政治正确”，但在 L3 场景里，它们就是代码的一部分。

7. 常见问题与排查思路

这里整理一些开发者最容易踩的问题：

如果这些排查不够用，建议先下降一级：不要让 Agent 一次处理太多目标。把大目标拆成多个小任务，每个小任务单独验证，再组合成完整流程。这是 L3 开发最有效的降风险手段。

8. 总结与后续学习方向

与其说 L3 是一个技术指标，不如说它是一个行业的“成年礼”。它意味着手机 AI 从可以聊天，走向可以做事；从回答问题，走向承担责任。哪怕标准还在演进，方向已经足够明确：谁能让用户放心地把目标交给手机，谁就能吃到 AI Agent 手机下半场的最大红利。

对开发者而言，现在的窗口期非常特殊。上半场拼的是模型和算力，门槛较高；下半场拼的是工具、Skill、场景封装和工程稳定性，这恰恰是大量软件工程师的主场。

下一步你可以按这个顺序走：

1. 先跑通本文的最小 Agent 示例，理解“规划—执行—确认—反馈”循环。
2. 把一个真实场景抽象成 3 到 5 个工具，加上确认机制，做自己的第一个 L3 雏形。
3. 建立评测集，记录完成率、介入次数、恢复率，持续优化。
4. 关注主流手机厂商和开源社区的 Agent 协议、Skill 规范，参与进生态标准的讨论。

L3 只是起点，这句话真正的意思是：技术能定义的是上限的框架，而在这个框架里能走多远，取决于每一个踏踏实实把 Agent 做可靠的开发者。手机 AI 的下半场，不是大模型的独角戏，而是应用层、工具层和系统层协作的共同工程。现在入场，不晚。