AI时代移动端开发：AppFunctions让App把能力暴露成“自描述函数”供Gemini等Agent直接调用，Android的组织逻辑开始从“用户主动打开App”转向“AI Agent按需调用能力”——当App不再被“打开”而是被“调用”，移动端开发者该重新设计的到底是App的UI，还是App的“可被Agent发现和编排”的接口边界？

一、背景与问题定义：从“入口经济”到“能力经济”

1.1 移动端二十年的默认假设正在松动

移动互联网的经典组织逻辑可以概括为“入口—路径—转化”：App 图标是入口，页面栈是路径，埋点漏斗是转化。这套逻辑成立的前提是人类是唯一的操作主体——用户必须看见界面、理解控件、完成点击。Android 的 Activity/Intent 模型、iOS 的 URL Scheme 与 Universal Links，都是围绕“人类触达界面”设计的。

当 LLM 驱动的 Agent 成为新的操作主体时，前提被改写：Agent 不需要“看见”界面，它需要的是结构化的能力声明与可验证的调用结果。Google 在 Android 开发者文档与 Gemini 相关能力中推进的 AppFunctions，正是对这一前提变化的系统级回应：把 App 功能以函数形式暴露给系统，由系统侧的 Agent 完成意图解析与函数选择。本文评述：这不是又一个“快捷方式”式的增量特性，而是对 App 与操作系统之间契约层级的重新划分。

1.2 问题定义：三个必须回答的工程问题

把“App 被调用”落到工程上，至少要回答三个问题，它们构成本文的分析骨架：

这三个问题分别对应本文的第三、四、五章。笔者认为，绝大多数团队在评估 AppFunctions 时会把注意力放在“怎么注册函数”这一 API 层面，而真正的成本与风险集中在后两个问题：语义契约的稳定性与权限边界的可证明性。

1.3 一条贯穿全文的主线：能力边界即产品边界

传统产品边界由 UI 划定：用户能点到什么，产品就到哪。Agent 时代，产品边界由可被调用的能力集合及其语义精度划定：Agent 能可靠调用的能力，才是产品真正对外提供的价值。UI 退化为“人类用户仍需要的那部分能力的可视化外壳”。这一判断并非修辞，它有可检验的推论：若某能力无法被稳定描述与调用，则它在 Agent 渠道中的有效覆盖趋近于零，无论其 UI 多么精致。

本文评述：把“能力边界即产品边界”作为主线，意味着接口设计不再是“前端联调的后置环节”，而是与信息架构同级的一等公民。这与微服务时代“API 即产品”的论断同构，但约束更强——Agent 的容错来自语义清晰度，而非人类用户的常识补全。

二、AppFunctions 的机制模型：自描述函数如何被 Agent 消费

2.1 概念界定

本文所称自描述函数（self-describing function），指一个在注册时即携带完整元数据的可调用单元，元数据至少包含：函数标识、自然语言意图描述、参数 Schema、返回值 Schema、副作用等级、所需权限、幂等性与超时约束。它与传统 RPC 接口的关键差异在于：描述本身是给模型读的，因此必须兼顾机器可解析（结构化）与语义可泛化（自然语言）。

AppFunctions 在 Android 语境中的定位，可以理解为系统层提供的一套“能力注册—检索—调用—回执”通道：App 通过声明式配置或注解把函数注册到系统，系统侧 Agent 在解析用户意图后，从可用函数集合中检索候选、构造参数、发起调用并处理结果。需要说明的是，该能力在不同 Android 版本与设备上的可用性存在差异，工程上必须以运行时探测为准，不能假设全量可用。

2.2 调用链的五个阶段

把一次 Agent 调用拆开，可以得到如下阶段模型，每个阶段都有独立的失败模式与工程对策：

这张表的工程价值在于：它把“接入 Agent”从一个模糊的集成任务，拆成了五个可分别度量、分别优化的子问题。笔者建议团队在接入初期就为每个阶段建立独立的失败率指标，而不是只看端到端成功率——后者会把问题掩盖在平均值里。

2.3 一个最小可用的注册骨架

下面给出一个跨平台通用的声明式骨架（以 JSON Schema 表达，具体注解形式随平台而异），重点不在语法而在字段取舍：

{
  "name": "create_meeting_room_booking",
  "description": "为指定时间段预订会议室；若目标时段不可用，返回候选时段列表而不自动改期。",
  "parameters": {
    "type": "object",
    "properties": {
      "room_hint": { "type": "string", "description": "会议室名称或容量偏好，如 '8人' 或 'A301'" },
      "start": { "type": "string", "format": "date-time" },
      "duration_minutes": { "type": "integer", "minimum": 15, "maximum": 480 }
    },
    "required": ["start", "duration_minutes"]
  },
  "returns": {
    "type": "object",
    "properties": {
      "status": { "enum": ["confirmed", "conflict", "denied"] },
      "booking_id": { "type": "string" },
      "alternatives": { "type": "array", "items": { "type": "string" } }
    }
  },
  "side_effect": "write",
  "idempotency_key": "start+room_hint",
  "requires_confirmation": true
}

注意三个设计决策：其一，description 明确写出“不自动改期”，这是给模型的负向约束；其二，returns 用枚举而非布尔，让 Agent 能区分“冲突”与“被拒”；其三，requires_confirmation 把人类确认作为协议的一部分，而非 UI 的临时弹窗。本文评述：负向约束与结构化失败态，是自描述函数区别于普通 API 文档的两个最关键增量。

三、Schema 与语义契约：把“能做什么”写成机器可读的合同

3.1 语义契约的三层结构

笔者认为，一个可被 Agent 稳定消费的函数，其语义契约应分三层：语法层（类型、必填、取值范围）、语用层（何时该用、何时不该用、与其他函数的关系）、效果层（副作用、幂等性、可撤销性）。多数团队只做语法层，导致 Agent 在语用层频繁误选。

3.2 命名与粒度：原子能力优先

函数粒度存在一个可验证的权衡：粒度过粗（如 do_everything）会让参数空间爆炸，模型难以正确填充；粒度过细（如把“打开页面”也做成函数）会让候选集膨胀，检索精度下降。工程上的经验法则是：以“用户可独立表述的意图”为原子单位，而不是以代码方法为单位。

命名上建议采用“动词_对象_限定”的三段式，并保持跨版本稳定。一旦函数名进入 Agent 的检索索引，改名等同于破坏性变更，需要走废弃周期。本文评述：这一点与公开 API 的版本治理同构，但反馈更快——Agent 的调用日志会在一周内暴露命名歧义。

3.3 描述文本的写法：给模型看的“使用说明书”

描述文本不是文档注释的搬运，而应遵循可检验的写作规则：

3.4 版本化与兼容策略

建议在函数标识中保留主版本号（如 create_booking_v2），并在描述中声明废弃时间。参数只做“加可选字段”的向后兼容变更，删除或改语义必须升主版本。工程上可用如下伪代码在注册期做契约校验：

def validate_contract(fn, prev):
    # 1) 必填参数不得减少
    assert set(prev.required) <= set(fn.required)
    # 2) 已有参数类型不得变更
    for k, t in prev.types.items():
        assert fn.types.get(k) == t
    # 3) 副作用等级不得静默提升
    assert rank(fn.side_effect) <= rank(prev.side_effect)
    # 4) 描述必须包含负向约束关键词
    assert any(w in fn.description for w in ["不", "仅", "除非"])

这段校验可以在 CI 中运行，把“契约漂移”从线上事故前移到合并请求阶段。笔者认为，这是接入 Agent 能力时投入产出比最高的一项工程实践。

四、权限、沙箱与信任边界：可调用不等于可放任

4.1 副作用的四级分类

把函数按副作用分级，是权限设计的前提。笔者建议采用四级模型，并与确认策略绑定：

本文评述：L3 应被明确排除在“无人值守调用”之外。这不是技术保守，而是可证明的风险控制——一旦允许 Agent 在无人类在场的情况下完成 L3 操作，责任归属在现有法律框架下无法闭环。

4.2 最小权限与运行时探测

函数注册时应声明所需权限，系统在调用前校验；App 侧再做一次运行时校验，形成双重防线。工程上建议把权限检查封装为统一的装饰器，避免散落在业务代码中：

@app_function(
    name="transfer_funds_v1",
    side_effect="L3",
    requires=["auth.strong", "device.trusted"]
)
def transfer_funds(amount, to_account, otp):
    ctx = current_call_context()
    if not ctx.user.has_role("verified"):
        return {"status": "denied", "reason": "role_unverified"}
    if amount > ctx.user.daily_limit:
        return {"status": "denied", "reason": "limit_exceeded"}
    return do_transfer(amount, to_account, otp)

4.3 提示注入与参数污染

当函数参数部分来自用户自然语言、部分来自页面内容时，存在提示注入（prompt injection）风险：恶意页面文本可能诱导 Agent 构造越权参数。缓解手段包括：对来自非用户输入的参数做来源标记、对金额与账号等敏感字段做格式白名单校验、在 L2 以上操作中强制回显关键参数供人类核对。本文评述：这些措施与传统的输入校验同源，但威胁模型从“恶意用户”扩展到“恶意内容”，需要在威胁建模阶段显式列出。

五、工程落地路径：从能力盘点 to 灰度发布的七步法

5.1 七步法总览

下面给出一条可直接执行的路径，每一步都有明确产出物，便于团队按里程碑推进：

5.2 能力盘点的可操作模板

盘点阶段最容易失控，建议用固定字段的表格约束讨论范围。字段至少包括：用户任务、触发场景、输入、输出、副作用等级、是否已有稳定后端接口、是否依赖登录态。笔者在实践中发现，“是否已有稳定后端接口”这一列能快速筛掉大量伪需求——很多 UI 功能背后并没有可复用的服务端能力。

5.3 UI 的重构顺序：先减法后加法

回到本文开头的问题：该重设计 UI 还是接口边界？笔者的答案是分阶段的。第一阶段以接口边界为主，UI 只做必要适配（如为 L2 操作提供确认页）；第二阶段再做 UI 减法——把已被 Agent 高频覆盖的路径从主导航降级，把人类仍需精细控制的部分（如复杂筛选、创意编辑）强化。判断依据来自调用日志：某路径的 Agent 覆盖率超过阈值且失败率低于人工路径时，才具备降级条件。

本文评述：先减法后加法是常见的错误顺序。在接口尚未稳定时就大改 UI，会导致人类路径与 Agent 路径同时不可用，且无法归因。以日志驱动的渐进式降级，是风险更低的路径。

5.4 组织协同：接口边界需要“产品—后端—客户端”三方共管

能力契约横跨三方：产品定义语义与优先级，后端保证能力真实可用与幂等，客户端负责注册、权限与回执封装。建议设立“能力契约负责人”角色，对契约变更做单点把关。这与 API 治理中的 API Owner 制度同构，可复用既有流程。

六、评测体系：如何度量“可被编排性”

6.1 四个核心指标

“可被编排性”需要可度量，否则无法优化。建议至少跟踪四个指标，并按函数维度拆分：

需要说明的是，上述指标的具体数值高度依赖设备、模型版本与用户分布，本文不给出通用基准值，以免误导。团队应建立自己的基线，并以周为单位观察趋势。

6.2 评测集构建与数据预处理

评测集应覆盖三类样本：典型意图、边界意图（缺参数、多意图）、对抗意图（诱导越权）。构建时需做如下预处理并记录：去重（语义相似度阈值）、脱敏（账号与金额替换为占位符）、分层抽样（按函数与副作用等级分层）。若使用模拟数据，应在报告中明确标注为模拟数据，不得与真实线上数据混算。

6.3 离线评测与在线 A/B 的衔接

离线评测用于快速迭代描述与 Schema，在线 A/B 用于验证真实分布下的收益。二者之间需要一致的指标口径，否则会出现“离线涨、线上跌”的常见错配。笔者建议以“端到端任务完成率”作为唯一对齐指标，其余作为诊断指标。

七、对比与局限：相对 Intent、Deep Link、MCP 的取舍

7.1 与既有机制的对比

本文评述：三者不是替代关系。Deep Link 仍适合“把用户带到某个页面”，AppFunctions 适合“让 Agent 完成某个动作”，MCP 类协议适合“跨设备、跨运行时的能力编排”。理性的架构是分层共存，而非押注单一机制。

7.2 必须承认的局限

7.3 拓展资源

以下资源可用于延伸阅读与动手实践（均在新窗口打开）：

八、结论与展望：UI 与接口边界的再平衡

回到标题提出的问题：当 App 不再被“打开”而是被“调用”，开发者该重设计的是 UI 还是接口边界？基于前文的机制分析与工程推演，笔者的结论是：接口边界优先，UI 随后按日志证据渐进重构。接口边界决定了 App 在 Agent 渠道中的“可发现性、可理解性、可信任性”，这三者共同构成新的产品边界；UI 则收敛为人类用户仍需精细控制的那部分能力的呈现层。

展望未来，有三个方向值得持续观察：其一，能力描述标准的收敛，跨平台契约有望在 MCP 类协议与平台原生机制之间形成映射层；其二，评测基础设施的成熟，使“可被编排性”像性能一样成为常规质量门禁；其三，责任框架的建立，为 L2/L3 操作的自动化闭环提供制度基础。本文评述：在这三者成熟之前，理性的策略是“小步灰度、契约先行、日志驱动”，而非一次性重构。

主要参考文献与资料

本文写作过程中参考了平台官方文档、开放协议规范、安全威胁清单与学术预印本等资料，累计参考条目 60 余项，其中近三年（2023—2025）资料占比超过 50%。以下列出 9 项主要参考文献，完整引用请以原始文献为准：

涉及评测数据集的说明：本文所述评测集构建方法为工程方法论描述，未使用特定公开数据集的原始样本；若团队自建数据集，需完成去重、脱敏与分层抽样预处理，并在报告中标注数据来源与是否为模拟数据。