AI Agent Token 成本为什么会失控：本地手机动作如何省钱

AI Agent Token 成本到底花在哪里

很多团队第一次做 AI Agent，会把成本理解成“模型一次回答多少钱”。真正跑起手机任务后才会发现，AI agent token cost 的大头不一定是单次对话，而是一个任务从发起、理解、计划、调用工具、等待结果、解释失败到再次尝试的整个过程。用户说“帮我整理今天重要通知，再提醒我回复客户”，这不是一句问答，它会牵涉通知内容、联系人、时间、消息草稿、提醒设置和确认动作。

公开的 OpenAI API 价格说明和 Google Cloud Vertex AI 生成式 AI 价格说明都能看出一个基本事实：云端生成式 AI 成本通常与模型、输入输出量、模态和调用方式有关。本文不引用具体价格，因为价格会变化，也不把任何供应商的价格当成 FoneClaw 的成本承诺。我们关心的是结构：为什么同样是“帮我完成手机任务”，有的方案会反复消耗上下文，有的方案可以把支持动作做得更直接。

手机任务比普通聊天更容易放大成本。普通聊天只要回答清楚即可；手机 Agent 还要判断现在在哪个 App、用户想改哪个设置、是否需要权限、下一步能不能继续、结果是否已经完成。关于多步手机任务本身，可以参考 Android 任务自动化指南：用一个语音命令完成多步手机任务。我们的判断是，成本分析不能只看 token 单价，还要看每个任务是否被设计成可重复、可确认、可恢复的手机动作。

真正贵的往往是长上下文和失败重试

Agent 成本最容易漏算的地方，是失败循环。一次任务如果需要把屏幕截图、通知摘要、工具列表、历史对话、用户偏好和上一次失败原因都重新传给模型，token 很快就会增长。更麻烦的是，失败并不总是显眼的系统错误。有时只是 Agent 打开了错误页面、读错了联系人、没有找到按钮，或者需要用户补充一句“不是这个群，是客户群”。

手机场景里的 token 浪费通常有几类。第一类是上下文过长：为了让模型理解手机状态，系统反复描述屏幕、App、权限和历史步骤。第二类是工具说明过多：模型每轮都要看到一大串可用工具，却只需要其中一个小动作。第三类是确认成本：敏感动作需要给用户看清楚，模型还要生成解释、摘要和下一步建议。第四类是纠错成本：用户一旦说“你理解错了”，前面的计划和上下文可能又要重新整理。

这就是为什么“更聪明的模型”不一定自动等于“更便宜的 Agent”。模型能力强，可以减少某些误判；但如果手机动作本身不稳定，每次都要靠云端重新推理，成本仍然会被失败循环吃掉。对产品来说，真正省钱的不是把所有步骤压成一次超长提示，而是把常见任务拆成更可靠的手机动作，让模型在该理解的时候理解，在该执行支持动作的时候少猜。

只在云端思考，未必能省下手机操作成本

云端 AI 很适合做总结、写作、分析和复杂推理，但手机控制有一个现实问题：理解任务和真正改变手机状态不是一回事。一个云端助手可以告诉用户“请打开设置，进入通知，找到某个 App，再关闭提醒”，这会消耗 token，也可能说得很准确；可如果最终仍要用户一步步手动操作，成本就从 API 账单转移到了用户时间上。

更典型的例子是消息回复。云端模型可以起草一段很好的回复，但手机端还要找到正确联系人、打开正确会话、填入草稿、等待用户确认，并确保没有发错人。如果云端方案只能反复解释“你可以这样做”，却不能在用户授权后完成支持范围内的手机步骤，它就可能在描述上花很多 token，在结果上仍停留在建议。

这并不是说云端没有价值。复杂理解、跨文档分析、长文本生成和多来源推理仍然需要强模型。问题在于，手机 Agent 的成本要把“能否完成动作”算进去。对安全和信任的更完整讨论，可以看 AI Agent 信任指南：本地手机 Agent 与云端 AI 安全怎么选。在成本层面，我们关注的是同一个原则：能在手机上用清晰权限完成的支持动作，不应该每次都变成云端反复猜测的长对话。

本地 Android 动作能减少哪些重复推理

把部分支持动作靠近 Android 设备完成，并不是为了制造“完全离线”或“万能控制”的口号。它的成本价值在于减少重复解释。比如打开某个 App、读取可见通知、准备一条草稿、切换某个系统入口、设置一个提醒，这些动作如果已经被产品稳定支持，就不需要每次都把完整操作路径交给模型重新规划。

Android 的隐私和权限机制也提醒我们，手机上的动作必须尊重用户授权。Android 隐私与安全文档说明了权限和安全控制在应用体验中的基础地位。对 FoneClaw 来说，本地 Android 动作不是绕过系统，也不是暗中控制 App，而是在用户允许的边界内，把支持任务做得更直接、更可见。

省下来的不只是 token。稳定的本地动作还可以减少用户解释成本。用户不用反复说“我在说那个通知”“不是发出去，只是写草稿”“先打开导航，不要提交订单”。如果产品把常见意图、支持动作和确认节点设计清楚，模型调用可以更集中地用于理解目标和处理例外，而不是每轮都重新观察手机、重写计划、再问用户一次。

FoneClaw 的成本观：支持动作要稳定、确认、留痕

我们做 FoneClaw 时，不把“少用 token”理解成单纯压缩提示词。真正的成本控制，是让支持范围内的手机动作更确定。一个动作如果经常失败，便宜的模型也会变贵；一个动作如果需要用户反复纠正，再低的 API 单价也会损失体验。FoneClaw 是我们的 Android 手机 AI Agent，面向支持的手机动作，而不是一个声称能控制所有 App 的万能系统。

我们的设计取向可以概括为四点：支持动作要明确，权限请求要清楚，敏感步骤要确认，完成结果要能回看。比如用户让 FoneClaw 准备消息回复，我们希望它先识别对象和内容，生成草稿，再让用户确认是否发送；如果用户让它处理提醒或通知，也应让用户知道它读取了什么、准备做什么、最后有没有完成。

这种做法同样服务于企业和团队场景。Agent 成本一旦进入组织使用，就不只是模型账单，还包括安全评审、权限管理、出错后的追踪和支持成本。关于企业侧为什么更需要权限和记录，可以参考 企业 AI 代理安全：为什么手机代理更需要本地优先、权限和审计。我们不承诺无确认购买、无边界控制或绕过权限；这类承诺短期看像效率，长期看会把成本转嫁给风险处理。

评估 Agent 总成本时要看这几项

如果你在评估一个手机 Agent 或云端助手，不要只问“每百万 token 多少钱”。更有用的问题是：一次任务平均要几轮？失败后是否从头再来？手机动作是否稳定？用户需要看多少解释？敏感步骤是否会产生人工复核？这些问题比单价更接近真实成本。

可以用下面的清单做初步判断：

• 模型调用：任务需要多少轮输入输出，是否每次都传入长上下文、截图或完整历史。
• 动作稳定性：常见手机动作是否被产品支持，还是每次都靠模型临时推断按钮和页面。
• 失败处理：出错后能否从当前状态恢复，还是重新规划、重新读取、重新询问用户。
• 权限和确认：涉及消息、支付、账号、位置、文件和设置时，是否有清楚的用户确认。
• 记录与支持：完成后是否能看见结果，出错后是否知道哪一步失败，团队是否能复盘。
• 人工时间：用户是否被迫在多个 App 间切换、复制、粘贴、核对和重复说明。

我们对 FoneClaw 的判断是：手机 Agent 的长期竞争力不会只来自更大的模型，而来自更少的无效循环。该由云端理解的复杂意图，可以交给强模型；该在手机上完成的支持动作，应尽量变成清楚、可确认、可记录的操作。这样省下的，不只是 token 成本，还有用户的注意力、产品支持成本和信任成本。