尧图网页设计 
大家好我是你们的技术博主。最近在做一个移动端项目时遇到一个很有意思的需求业务方希望 App 内部不只是一个“被动响应指令”的工具而是一个能够理解用户意图、自动拆解任务、调用系统能力并最终交付结果的智能体。说白了就是要做一个An agent built for Mobile。这块资料目前比较分散大部分 AI Agent 教程都是围绕服务端或者纯 Python 环境展开真正从移动端视角出发、把 Agent 核心机制讲清楚的内容不多。这篇文章我就结合最近的实践完整拆解一下移动端 Agent 的架构设计、核心代码实现、工具调用机制、记忆管理、多 Agent 协作方式以及上线过程中容易踩的坑。如果你是移动端开发想快速理解 Agent 并落地到自己的 App 中这篇文章应该能帮到你。1. 为什么需要移动端 Agent1.1 从云端 Agent 到移动端 Agent 的转变过去一年AI Agent 的热度非常高。无论是基于大语言模型的个人助理还是企业内部流程自动化机器人大家提到 Agent默认场景往往是云服务器、容器环境、Python 脚本。这类 Agent 有一个共同特点算力充足、网络稳定、不需要考虑移动端碎片化问题。但真实用户场景中大量交互发生在手机上。想象一下这些需求用户对手机说“帮我把明天上午的会议改到下午三点并通知参会人”。用户拍了一张名片照片要求“提取信息并保存到联系人”。用户在购物 App 里说“找一款 2000 元左右、续航好、适合跑步的蓝牙耳机对比三款发给我”。这些场景如果全部把数据上传到云端由云端 Agent 处理后再返回结果体验上会有几个明显问题网络往返延迟高尤其弱网环境下体验很差。涉及用户通讯录、照片、位置等敏感数据全部上云有隐私风险。很多系统能力比如调用系统日历、发送本地通知、读取传感器数据必须由移动端原生代码完成云端 Agent 无法直接触摸到。所以移动端 Agent 并不是简单把 LLM大语言模型的 SDK 集成到 App 里而是要在移动设备端构建一个具备“感知、决策、执行、记忆”能力的 Agent 运行时环境。1.2 移动端 Agent 能解决什么真实问题移动端 Agent 的本质是把大模型的理解能力与移动设备的系统能力结合起来。大模型负责理解用户意图、拆解任务、决定调用哪个工具移动端原生代码负责真正执行操作。举个例子用户说“帮我定一个明早 8 点的闹钟明天要早起赶高铁”。传统做法是App 解析关键词“闹钟”“明早 8 点”跳转到闹钟设置页让用户手动操作。Agent 的做法是理解“明早 8 点”是一个具体时间点。理解“赶高铁”这个背景可以附带一个提醒事项。调用系统闹钟工具创建闹钟。调用日历工具添加日程。向用户反馈执行结果。这种任务拆解和工具调用的能力正是 Agent 区别于普通语音助手或规则引擎的核心。1.3 移动端 Agent 与移动应用 AI 功能的边界这里需要先厘清一个容易混淆的概念移动端接入大模型 API 不等于移动端 Agent。如果你的 App 只是调用大模型接口实现一个“智能问答”或“文本总结”功能那是 AI 功能集成不是 Agent。Agent 的核心特征有三个自主规划能根据目标拆解成多个步骤。工具调用能调用外部工具或系统 API。记忆能力能记住上下文并基于历史信息做决策。移动端 Agent 也可以有不同形态完全端侧运行模型部署在手机本地适合离线场景但受限于手机算力。云端模型 端侧执行模型在云端工具调用和系统操作在端侧这是目前主流方案。混合模式简单的意图识别在端侧完成复杂推理交给云端。这篇文章主要讨论第二种方案因为它在工程实现上最成熟也最容易在现有 App 架构中落地。2. 移动端 Agent 的核心架构设计在设计移动端 Agent 时我的做法是先把整个系统拆分成几个独立模块。这样做的好处是每个模块可以单独测试、单独替换后续扩展多 Agent 协作时也会容易很多。下面是我在项目中常用的一种分层设计2.1 Agent Loop循环、决策、执行Agent Loop 是整个智能体的心脏。它做的事情可以理解为接收用户输入。把输入和当前上下文一起交给大模型。模型决定直接回答还是调用某个工具。如果需要调用工具执行工具函数把工具结果返回给模型。模型根据工具结果决定下一步动作或生成最终回答。循环直到模型认为任务已结束。在移动端实现时这个循环通常不是简单写一个 while 循环就行。因为移动端有生命周期问题App 可能随时进入后台网络可能中断用户可能取消操作。所以我的建议是把 Agent Loop 设计为状态机每个状态可以持久化这样即使 App 被系统杀掉下次启动时也能恢复任务。下面是一个简化的状态定义// agent-types.ts export type AgentState | { phase: idle } | { phase: thinking; input: string } | { phase: awaiting_tool; toolName: string; args: Recordstring, unknown } | { phase: executing; toolName: string } | { phase: responding; message: string } | { phase: error; message: string } | { phase: done };2.2 工具调用与 Function Calling工具调用是 Agent 执行力的来源。在移动端工具通常分成两类本地系统工具闹钟、日历、相机、相册、定位、通知、剪贴板等。远程服务工具查询天气、查快递、下单、获取订单信息等。移动端 Agent 中工具注册表的设计非常关键。每个工具需要包含名称、描述、参数 schema参数结构说明、执行函数。模型通过描述和 schema 来决定何时调用、传入什么参数。这里需要注意Function Calling 不一定只在云端模型 API 中支持。很多开源模型和端侧模型也支持 function call 协议只是效果参差不齐。2.3 记忆划分短期上下文与长期记忆记忆是 Agent 进阶能力中最容易忽略的部分。没有记忆的 Agent每次对话都是全新的用户需要反复重复自己的偏好和背景信息。在移动端环境中记忆模块通常分为两层短期记忆当前任务中的上下文包括用户本轮输入、Agent 中间推理步骤、工具执行结果。短期记忆可以用循环缓冲区保存防止上下文过长超过模型窗口。长期记忆跨会话保存的用户偏好、历史重要信息。长期记忆需要持久化存储比如本地 SQLite 数据库或轻量级的向量数据库。长期记忆的一个典型实现方式是把用户的历史对话做摘要存入本地数据库。下次用户发起新任务时先检索相关记忆摘要作为额外上下文注入模型。这样既不会撑爆上下文窗口又能让 Agent 具备“记住用户”的能力。2.4 模型与 API 的连接方式移动端 Agent 一般不会直接把模型部署在手机上主流方式是请求云端 LLM API。这里就涉及一个很实际的问题API Key 放在哪里很多初学者会直接把 API Key 写在 App 代码里这是非常危险的做法。因为客户端代码可以被反编译密钥会被泄露。正确做法是通过自己的后端服务转发模型请求。在服务端保存 API Key。移动端先做身份认证获取临时 token再请求自己的后端由后端调用大模型 API。这个策略既保护了密钥安全也方便在服务端统一做限流、审计和成本控制。3. 环境准备与通用依赖3.1 技术栈选择移动端 Agent 技术栈没有统一标准。你可以使用原生开发iOS 的 Swift、Android 的 Kotlin也可以使用跨平台框架。考虑到 Agent 的工程复杂度这里我推荐使用 TypeScript React Native 来做示例讲解原因是TypeScript 类型系统对 Agent 状态机和工具 schema 的定义有天然优势。React Native 能调用原生能力也支持 JavaScript 生态中的大模型 SDK。同一套 Agent 核心逻辑可以复用到 iOS、Android甚至未来的桌面端。当然这只是一个可选的方案不是唯一方案。如果你使用 Flutter 或纯原生核心思路是一样的只是语言和框架的差异。3.2 项目结构建议把 Agent 相关代码独立成模块不要和业务代码混在一起。我常用的目录结构如下mobile-agent-demo/ ├── src/ │ ├── agent/ │ │ ├── core/ │ │ │ ├── AgentLoop.ts │ │ │ ├── ToolRegistry.ts │ │ │ └── MessageBus.ts │ │ ├── memory/ │ │ │ ├── ShortTermMemory.ts │ │ │ └── LongTermMemory.ts │ │ ├── tools/ │ │ │ ├── system/ │ │ │ │ ├── AlarmTool.ts │ │ │ │ ├── CalendarTool.ts │ │ │ │ └── ClipboardTool.ts │ │ │ └── remote/ │ │ │ └── WeatherTool.ts │ │ └── llm/ │ │ └── LLMClient.ts │ ├── screens/ │ └── services/我们可以简单理解core 是 Agent 引擎memory 是记忆模块tools 是 Agent 可调用的工具集合llm 是大模型通信层。3.3 版本说明与环境变量本文的代码示例以 TypeScript React Native 0.72 为例大模型接口使用 OpenAI 兼容格式。注意大模型相关版本迭代非常快LLM API 的返回结构在不同平台可能略有差异。你需要在自己的项目中把 API Base URL、API Key、模型名称等配置放到环境变量或后端配置中心不要硬编码在源码中。示例// src/config/env.ts export const ENV { apiBaseUrl: process.env.API_BASE_URL ?? , modelName: process.env.MODEL_NAME ?? qwen-plus, apiTimeout: Number(process.env.AGENT_API_TIMEOUT ?? 15000), };如果你的项目没有接入环境变量管理也可以使用 react-native-config 这类库来处理核心原则就是“源码不出现密钥”。4. 完整实战构建一个移动端任务助手 Agent接下来我们动手实现一个精简但完整的移动端 Agent。这个 Agent 能处理两种任务设置闹钟。添加日历日程。你可以根据业务需求扩展更多工具。4.1 实现 Agent 核心循环AgentLoop 是整个模块的核心。它接收一个用户输入字符串逐步和 LLM 交互执行工具调用最终返回答复。下面是核心代码// src/agent/core/AgentLoop.ts import { LLMClient } from ../llm/LLMClient; import { ToolRegistry } from ./ToolRegistry; import { ShortTermMemory } from ../memory/ShortTermMemory; type AssistantMessage { role: assistant; content?: string; tool_calls?: ToolCall[]; }; type ToolCall { id: string; type: function; function: { name: string; arguments: string; }; }; export class AgentLoop { constructor( private llm: LLMClient, private tools: ToolRegistry, private memory: ShortTermMemory, private maxIterations 5, ) {} async run(userInput: string): Promisestring { this.memory.add({ role: user, content: userInput }); let iterations 0; while (iterations this.maxIterations) { iterations 1; const response await this.llm.complete({ messages: this.memory.getMessages(), tools: this.tools.getToolSchemas(), }); const message: AssistantMessage response.message; if (message.tool_calls message.tool_calls.length 0) { // 记录模型的中间决策 this.memory.add(message); for (const call of message.tool_calls) { const toolName call.function.name; const args JSON.parse(call.function.arguments || {}); console.log([Agent] 调用工具: ${toolName}, args); const result await this.tools.execute(toolName, args); this.memory.add({ role: tool, tool_call_id: call.id, content: JSON.stringify(result), }); } continue; } if (message.content) { this.memory.add({ role: assistant, content: message.content, }); return message.content; } } throw new Error(Agent 执行超过最大迭代次数); } }这段代码实现了完整的 Agent Loop。核心逻辑是把用户输入加入短期记忆。调用 LLM传入消息历史和工具 schema。如果模型返回 tool_calls就逐个执行工具并把工具结果回传给 LLM。如果模型直接返回文本内容说明任务结束返回最终答复。设置 maxIterations 防止死循环。4.2 注册本地工具工具注册表ToolRegistry负责维护所有可用工具。每个工具必须提供描述信息和 schema这样模型才能正确调用。下面是工具注册表的实现// src/agent/core/ToolRegistry.ts type ToolExecutor (args: Recordstring, unknown) Promiseunknown; export interface ToolDefinition { type: function; function: { name: string; description: string; parameters: Recordstring, unknown; }; } export class ToolRegistry { private executors new Mapstring, ToolExecutor(); private definitions: ToolDefinition[] []; register(tool: ToolDefinition, executor: ToolExecutor) { this.definitions.push(tool); this.executors.set(tool.function.name, executor); } getToolSchemas(): ToolDefinition[] { return this.definitions; } async execute(name: string, args: Recordstring, unknown) { const executor this.executors.get(name); if (!executor) { throw new Error(工具 ${name} 未注册); } try { return await executor(args); } catch (error) { return { error: (error as Error).message }; } } }然后我们注册两个系统工具。这里以 React Native 为例创建闹钟和日历日程// src/agent/tools/system/AlarmTool.ts import { ToolRegistry } from ../../core/ToolRegistry; import NativeAlarmModule from ../../../services/NativeAlarmModule; export function registerAlarmTool(registry: ToolRegistry) { registry.register( { type: function, function: { name: create_alarm, description: 创建系统闹钟。用户要求设置闹钟时调用此工具。, parameters: { type: object, properties: { hour: { type: number, description: 小时0-23 }, minute: { type: number, description: 分钟0-59 }, label: { type: string, description: 闹钟标签例如起床闹钟 }, }, required: [hour, minute], }, }, }, async (args) { const { hour, minute, label } args as { hour: number; minute: number; label?: string; }; const id await NativeAlarmModule.createAlarm({ hour, minute, label: label ?? 闹钟, }); return { success: true, alarmId: id }; }, ); }// src/agent/tools/system/CalendarTool.ts import { ToolRegistry } from ../../core/ToolRegistry; import NativeCalendarModule from ../../../services/NativeCalendarModule; export function registerCalendarTool(registry: ToolRegistry) { registry.register( { type: function, function: { name: create_calendar_event, description: 创建日历日程。用户要求添加日程、安排会议或提醒时调用此工具。, parameters: { type: object, properties: { title: { type: string, description: 日程标题 }, startTime: { type: string, description: 开始时间ISO8601 格式 }, endTime: { type: string, description: 结束时间ISO8601 格式 }, notes: { type: string, description: 日程备注 }, }, required: [title, startTime, endTime], }, }, }, async (args) { const { title, startTime, endTime, notes } args as { title: string; startTime: string; endTime: string; notes?: string; }; const id await NativeCalendarModule.createEvent({ title, startTime, endTime, notes, }); return { success: true, eventId: id }; }, ); }这里我假设NativeAlarmModule和NativeCalendarModule是已经封装好的原生桥接模块。实际项目中你需要用 React Native 的 NativeModules 编写对应的原生代码或者使用第三方库比如react-native-alarms、react-native-calendar-events。4.3 接入简易记忆模块短期记忆用简单的消息数组实现。这里有两点需要注意要限制最大消息条数。如果对话太长需要做截断或摘要把早期消息压缩。工具调用结果不要无限累积否则超出模型上下文窗口。// src/agent/memory/ShortTermMemory.ts export type MemoryMessage { role: system | user | assistant | tool; content?: string; tool_call_id?: string; tool_calls?: unknown[]; }; export class ShortTermMemory { private messages: MemoryMessage[] []; constructor(private maxMessages 30) {} add(message: MemoryMessage) { this.messages.push(message); if (this.messages.length this.maxMessages) { const overflow this.messages.length - this.maxMessages; this.messages.splice(1, overflow); } } getMessages(): MemoryMessage[] { return this.messages; } clear() { this.messages []; } }长期记忆模块在示例中先做简化处理把每次任务的摘要保存到本地存储。生产环境推荐使用 SQLite 或者本地向量数据库来做检索。// src/agent/memory/LongTermMemory.ts import AsyncStorage from react-native-async-storage/async-storage; const MEMORY_KEY agent_long_term_memory; export class LongTermMemory { async saveSummary(summary: string) { const history await this.getAll(); history.push({ content: summary, timestamp: Date.now(), }); const recent history.slice(-100); await AsyncStorage.setItem(MEMORY_KEY, JSON.stringify(recent)); } async getAll(): PromiseArray{ content: string; timestamp: number } { const raw await AsyncStorage.getItem(MEMORY_KEY); if (!raw) return []; return JSON.parse(raw); } }在 Agent 启动时可以把最近的长期记忆作为 system prompt 注入让模型知道用户的偏好和过去完成的任务。4.4 UI 交互层设计Agent 运行过程中模型可能会连续调用多个工具如果 UI 一直不响应用户会以为卡死了。好的交互设计应该把 Agent 的中间状态可视化。我们可以设计一个简单的消息流界面// src/screens/AgentChatScreen.tsx import React, { useState } from react; import { View, TextInput, Button, FlatList, Text } from react-native; export function AgentChatScreen({ agent }: { agent: AgentLoop }) { const [input, setInput] useState(); const [messages, setMessages] useState Array{ id: string; type: user | agent | tool | status; text: string } ([]); const send async () { if (!input.trim()) return; const userText input.trim(); setInput(); setMessages((prev) [ ...prev, { id: ${Date.now()}-user, type: user, text: userText }, { id: ${Date.now()}-status, type: status, text: Agent 思考中... }, ]); try { // 这里可以监听工具调用事件更新 UI const result await agent.run(userText); setMessages((prev) { const withoutStatus prev.filter((msg) msg.type ! status); return [ ...withoutStatus, { id: ${Date.now()}-agent, type: agent, text: result }, ]; }); } catch (error) { setMessages((prev) { const withoutStatus prev.filter((msg) msg.type ! status); return [ ...withoutStatus, { id: ${Date.now()}-error, type: agent, text: 执行失败${(error as Error).message} }, ]; }); } }; return ( View style{{ flex: 1 }} FlatList data{messages} keyExtractor{(item) item.id} renderItem{({ item }) Text{item.text}/Text} / TextInput value{input} onChangeText{setInput} placeholder试试说帮我设置一个明早7点的闹钟 style{{ borderWidth: 1, padding: 8 }} / Button title发送 onPress{send} / /View ); }这段代码实现了最基本的人机交互界面。如果你想展示工具调用的中间状态可以通过订阅事件的方式在 UI 中滚动显示“正在调用闹钟工具”“闹钟创建成功”等状态卡片。4.5 运行与验证完成以上代码后启动 App输入下面这段对话测试帮我设置一个明早 7 点的闹钟标签写“早起”。正常情况下模型会返回一个 tool_calls 调用请求AgentLoop 捕获后执行create_alarm工具。如果原生模块实现正确手机系统会出现一个 7:00 的闹钟模型最终回复类似已为你设置明早 7:00 的闹钟标签为“早起”。再测试一下组合任务明天下午 3 点有一个产品评审会帮我加到日历里提醒我提前 10 分钟。Agent 会调用create_calendar_event在实际的日历 App 中创建日程并设置提醒。5. 多 Agent 协作机制阿一个只处理闹钟和日程的 Agent 相对简单。真实场景中一个 Agent 往往不够用这时就需要考虑多 Agent 协作。5.1 为什么需要多 Agent当一个任务的复杂度上升后单一的 Agent 会出现几个问题工具数量过多模型的 function calling 选择准确率下降。上下文过长模型容易丢失关键信息。安全边界不清晰比如一个负责操作财务系统的 Agent 不应该随意访问通讯录。多 Agent 的思路是把不同职责拆分给不同角色。比如在一个 App 中助手 Agent负责整体对话协调。日程 Agent专门处理日历相关任务。通信 Agent专门处理消息、邮件相关任务。搜索 Agent专门负责信息查询和内容总结。当用户说“帮我安排明天下午的会议并通知参会同事”调度器会先让日程 Agent 创建会议再把结果交给通信 Agent 发送通知。5.2 分工与编排多 Agent 的编排方式有很多种常见的有单一调度器Supervisor一个主 Agent 负责分发任务给子 Agent。流水线Pipeline任务按步骤依次交给不同 Agent。图编排GraphAgent 之间按照依赖关系 DAG 执行。在移动端场景下Supervisor 模式最容易实现也最容易调试。调度器本身也是一个 Agent它只负责理解意图、选择子 Agent、汇总结果。// src/agent/core/SupervisorAgent.ts export class SupervisorAgent { private agents: Recordstring, AgentLoop {}; register(name: string, agent: AgentLoop) { this.agents[name] agent; } async dispatch(userInput: string): Promisestring { // 简化实现这里可以通过 intent classification 决定交给哪个子 Agent if (userInput.includes(闹钟) || userInput.includes(日历)) { return this.agents.schedule.run(userInput); } if (userInput.includes(天气)) { return this.agents.search.run(userInput); } return this.agents.default.run(userInput); } }生产环境不建议写这种简单的 if-else 分法更好的方案是让调度器模型输出{agent: schedule, reason: ...}这样的结构化结果再由代码转发。5.3 消息传递与会话管理多 Agent 协作时消息传递是一个容易出问题的地方。每个子 Agent 都有自己的短期记忆但它们之间需要共享用户意图和最终上下文。建议做法是子 Agent 返回结构化结果而不仅仅是文本。调度器把子 Agent 的结果整合后再更新全局会话上下文。使用事件总线机制解耦各个 Agent 的通信。6. 常见问题与排查思路移动端 Agent 开发中大家碰到的问题往往集中在以下几个方面问题现象常见原因解决思路模型不调用工具直接回复文本工具描述不够清晰或模型不支持 function calling优化工具 description检查模型接口是否开启 tools 参数工具参数解析失败模型生成的 JSON 格式不合法增加 JSON 解析容错比如使用渐进式 JSON 解析器Agent 进入死循环工具一直返回错误模型反复重试设置 maxIterations并在工具执行失败时返回明确错误信息上下文超出模型限制短期记忆未做截断或摘要使用滑动窗口对早期消息做摘要压缩调用系统工具无响应原生模块未正确注册或权限未申请检查 NativeModules 桥接确认 Android/iOS 权限配置API Key 泄露源码中硬编码了密钥改为后端代理转发客户端只请求自己的服务弱网环境响应慢每次循环都请求云端 LLM增加本地缓存、轻量级意图预判或启用端侧小模型做路由如果你遇到 Agent 执行到一半报错可以参考下面的排查顺序打印每次 LLM 的原始返回结构确认 tool_calls 是否存在。确认工具是否完成注册名称是否与模型返回一致。检查工具执行结果是否成功失败时返回的 error 是否包含足够信息。检查短期记忆中消息角色是否正确特别是 tool 消息的 tool_call_id 必须和 assistant 工具调用匹配。逐步提高 maxIterations观察是否仍出现死循环。7. 最佳实践与工程建议7.1 安全边界必须前置设计移动端 Agent 因为能调用系统能力安全风险比普通 App 更高。如果 Agent 可以随意创建闹钟、发送短信、读取通讯录恶意提示词注入可能造成严重问题。建议所有工具执行前做参数校验禁止越权参数。危险操作二次确认比如发送消息、删除数据、付费操作。对模型输入做基础的注入检测尤其是在工具结果返回后拼接进上下文时防止工具结果中的恶意内容污染后续决策。服务端做好用户级权限隔离Agent 能访问的数据范围不能超过用户自身权限。7.2 工具 schema 要像 API 文档一样维护工具 schema 是模型理解工具的唯一依据。描述模糊或者参数说明不清楚模型就会乱调用。我的经验是工具命名使用动词开头如create_alarm、send_message、query_order。description 写清楚触发条件和边界情况。参数尽量使用枚举值减少模型自由发挥的空间。对于可选参数标注默认行为。7.3 日志与可观测性Agent 的调试难度远高于普通功能因为它是多轮循环调用黑盒感很强。建议在关键节点输出日志用户输入原文。模型每次返回的 message 全文。工具调用名称、参数、执行结果。短期记忆截断/摘要行为。生产环境将这些日志上报到后台方便后续分析模型表现和用户使用模式。7.4 成本控制LLM API 按 token 计费移动端 Agent 的每一次工具调用都会额外消耗 token。成本优化可以从下面几个方向入手限制 maxIterations避免无效循环消耗。对长上下文做摘要压缩。使用端侧模型处理简单意图判断只有复杂任务才请求云端大模型。在服务端增加缓存比如相同或相似的用户请求直接返回缓存结果。7.5 移动端特有的性能考虑移动端 CPU、内存、网络资源都有限。Agent 运行过程中要注意不要在 UI 线程执行任何 Agent 逻辑。LLM 请求要做超时处理建议 15 秒以上但不要无限等待。如果 Agent 在后台运行需要申请后台任务权限或者改为服务端执行方案。需要关注 App 进程被杀后的状态恢复Agent 状态要支持持久化。8. 总结移动端 Agent 并不是一个遥不可及的概念。把大模型的能力与移动端系统能力整合起来就能让 App 从一个“界面语言”升级为具备任务拆解和自动执行能力的智能助手。本文从 Agent Loop、工具注册、记忆管理、多 Agent 协作等核心模块出发给出了一套可以落地的最小实现方案。在实际项目中建议先从单一场景试点比如只做日程管理或者闹钟设置跑通整个闭环后再逐步扩展工具库。这样既能控制成本也方便定位问题。移动端 Agent 的想象空间很大但工程上还是一步一步来更稳妥。如果你正在做移动端 Agent 项目欢迎在评论区交流你的架构方案和踩坑经验。后续我还会整理一篇关于移动端 Agent 记忆增强和向量检索的实战文章感兴趣的话可以先收藏关注。 移动端Agent实战：从架构设计到工具调用
大家好我是你们的技术博主。最近在做一个移动端项目时遇到一个很有意思的需求业务方希望 App 内部不只是一个“被动响应指令”的工具而是一个能够理解用户意图、自动拆解任务、调用系统能力并最终交付结果的智能体。说白了就是要做一个An agent built for Mobile。这块资料目前比较分散大部分 AI Agent 教程都是围绕服务端或者纯 Python 环境展开真正从移动端视角出发、把 Agent 核心机制讲清楚的内容不多。这篇文章我就结合最近的实践完整拆解一下移动端 Agent 的架构设计、核心代码实现、工具调用机制、记忆管理、多 Agent 协作方式以及上线过程中容易踩的坑。如果你是移动端开发想快速理解 Agent 并落地到自己的 App 中这篇文章应该能帮到你。1. 为什么需要移动端 Agent1.1 从云端 Agent 到移动端 Agent 的转变过去一年AI Agent 的热度非常高。无论是基于大语言模型的个人助理还是企业内部流程自动化机器人大家提到 Agent默认场景往往是云服务器、容器环境、Python 脚本。这类 Agent 有一个共同特点算力充足、网络稳定、不需要考虑移动端碎片化问题。但真实用户场景中大量交互发生在手机上。想象一下这些需求用户对手机说“帮我把明天上午的会议改到下午三点并通知参会人”。用户拍了一张名片照片要求“提取信息并保存到联系人”。用户在购物 App 里说“找一款 2000 元左右、续航好、适合跑步的蓝牙耳机对比三款发给我”。这些场景如果全部把数据上传到云端由云端 Agent 处理后再返回结果体验上会有几个明显问题网络往返延迟高尤其弱网环境下体验很差。涉及用户通讯录、照片、位置等敏感数据全部上云有隐私风险。很多系统能力比如调用系统日历、发送本地通知、读取传感器数据必须由移动端原生代码完成云端 Agent 无法直接触摸到。所以移动端 Agent 并不是简单把 LLM大语言模型的 SDK 集成到 App 里而是要在移动设备端构建一个具备“感知、决策、执行、记忆”能力的 Agent 运行时环境。1.2 移动端 Agent 能解决什么真实问题移动端 Agent 的本质是把大模型的理解能力与移动设备的系统能力结合起来。大模型负责理解用户意图、拆解任务、决定调用哪个工具移动端原生代码负责真正执行操作。举个例子用户说“帮我定一个明早 8 点的闹钟明天要早起赶高铁”。传统做法是App 解析关键词“闹钟”“明早 8 点”跳转到闹钟设置页让用户手动操作。Agent 的做法是理解“明早 8 点”是一个具体时间点。理解“赶高铁”这个背景可以附带一个提醒事项。调用系统闹钟工具创建闹钟。调用日历工具添加日程。向用户反馈执行结果。这种任务拆解和工具调用的能力正是 Agent 区别于普通语音助手或规则引擎的核心。1.3 移动端 Agent 与移动应用 AI 功能的边界这里需要先厘清一个容易混淆的概念移动端接入大模型 API 不等于移动端 Agent。如果你的 App 只是调用大模型接口实现一个“智能问答”或“文本总结”功能那是 AI 功能集成不是 Agent。Agent 的核心特征有三个自主规划能根据目标拆解成多个步骤。工具调用能调用外部工具或系统 API。记忆能力能记住上下文并基于历史信息做决策。移动端 Agent 也可以有不同形态完全端侧运行模型部署在手机本地适合离线场景但受限于手机算力。云端模型 端侧执行模型在云端工具调用和系统操作在端侧这是目前主流方案。混合模式简单的意图识别在端侧完成复杂推理交给云端。这篇文章主要讨论第二种方案因为它在工程实现上最成熟也最容易在现有 App 架构中落地。2. 移动端 Agent 的核心架构设计在设计移动端 Agent 时我的做法是先把整个系统拆分成几个独立模块。这样做的好处是每个模块可以单独测试、单独替换后续扩展多 Agent 协作时也会容易很多。下面是我在项目中常用的一种分层设计2.1 Agent Loop循环、决策、执行Agent Loop 是整个智能体的心脏。它做的事情可以理解为接收用户输入。把输入和当前上下文一起交给大模型。模型决定直接回答还是调用某个工具。如果需要调用工具执行工具函数把工具结果返回给模型。模型根据工具结果决定下一步动作或生成最终回答。循环直到模型认为任务已结束。在移动端实现时这个循环通常不是简单写一个 while 循环就行。因为移动端有生命周期问题App 可能随时进入后台网络可能中断用户可能取消操作。所以我的建议是把 Agent Loop 设计为状态机每个状态可以持久化这样即使 App 被系统杀掉下次启动时也能恢复任务。下面是一个简化的状态定义// agent-types.ts export type AgentState | { phase: idle } | { phase: thinking; input: string } | { phase: awaiting_tool; toolName: string; args: Recordstring, unknown } | { phase: executing; toolName: string } | { phase: responding; message: string } | { phase: error; message: string } | { phase: done };2.2 工具调用与 Function Calling工具调用是 Agent 执行力的来源。在移动端工具通常分成两类本地系统工具闹钟、日历、相机、相册、定位、通知、剪贴板等。远程服务工具查询天气、查快递、下单、获取订单信息等。移动端 Agent 中工具注册表的设计非常关键。每个工具需要包含名称、描述、参数 schema参数结构说明、执行函数。模型通过描述和 schema 来决定何时调用、传入什么参数。这里需要注意Function Calling 不一定只在云端模型 API 中支持。很多开源模型和端侧模型也支持 function call 协议只是效果参差不齐。2.3 记忆划分短期上下文与长期记忆记忆是 Agent 进阶能力中最容易忽略的部分。没有记忆的 Agent每次对话都是全新的用户需要反复重复自己的偏好和背景信息。在移动端环境中记忆模块通常分为两层短期记忆当前任务中的上下文包括用户本轮输入、Agent 中间推理步骤、工具执行结果。短期记忆可以用循环缓冲区保存防止上下文过长超过模型窗口。长期记忆跨会话保存的用户偏好、历史重要信息。长期记忆需要持久化存储比如本地 SQLite 数据库或轻量级的向量数据库。长期记忆的一个典型实现方式是把用户的历史对话做摘要存入本地数据库。下次用户发起新任务时先检索相关记忆摘要作为额外上下文注入模型。这样既不会撑爆上下文窗口又能让 Agent 具备“记住用户”的能力。2.4 模型与 API 的连接方式移动端 Agent 一般不会直接把模型部署在手机上主流方式是请求云端 LLM API。这里就涉及一个很实际的问题API Key 放在哪里很多初学者会直接把 API Key 写在 App 代码里这是非常危险的做法。因为客户端代码可以被反编译密钥会被泄露。正确做法是通过自己的后端服务转发模型请求。在服务端保存 API Key。移动端先做身份认证获取临时 token再请求自己的后端由后端调用大模型 API。这个策略既保护了密钥安全也方便在服务端统一做限流、审计和成本控制。3. 环境准备与通用依赖3.1 技术栈选择移动端 Agent 技术栈没有统一标准。你可以使用原生开发iOS 的 Swift、Android 的 Kotlin也可以使用跨平台框架。考虑到 Agent 的工程复杂度这里我推荐使用 TypeScript React Native 来做示例讲解原因是TypeScript 类型系统对 Agent 状态机和工具 schema 的定义有天然优势。React Native 能调用原生能力也支持 JavaScript 生态中的大模型 SDK。同一套 Agent 核心逻辑可以复用到 iOS、Android甚至未来的桌面端。当然这只是一个可选的方案不是唯一方案。如果你使用 Flutter 或纯原生核心思路是一样的只是语言和框架的差异。3.2 项目结构建议把 Agent 相关代码独立成模块不要和业务代码混在一起。我常用的目录结构如下mobile-agent-demo/ ├── src/ │ ├── agent/ │ │ ├── core/ │ │ │ ├── AgentLoop.ts │ │ │ ├── ToolRegistry.ts │ │ │ └── MessageBus.ts │ │ ├── memory/ │ │ │ ├── ShortTermMemory.ts │ │ │ └── LongTermMemory.ts │ │ ├── tools/ │ │ │ ├── system/ │ │ │ │ ├── AlarmTool.ts │ │ │ │ ├── CalendarTool.ts │ │ │ │ └── ClipboardTool.ts │ │ │ └── remote/ │ │ │ └── WeatherTool.ts │ │ └── llm/ │ │ └── LLMClient.ts │ ├── screens/ │ └── services/我们可以简单理解core 是 Agent 引擎memory 是记忆模块tools 是 Agent 可调用的工具集合llm 是大模型通信层。3.3 版本说明与环境变量本文的代码示例以 TypeScript React Native 0.72 为例大模型接口使用 OpenAI 兼容格式。注意大模型相关版本迭代非常快LLM API 的返回结构在不同平台可能略有差异。你需要在自己的项目中把 API Base URL、API Key、模型名称等配置放到环境变量或后端配置中心不要硬编码在源码中。示例// src/config/env.ts export const ENV { apiBaseUrl: process.env.API_BASE_URL ?? , modelName: process.env.MODEL_NAME ?? qwen-plus, apiTimeout: Number(process.env.AGENT_API_TIMEOUT ?? 15000), };如果你的项目没有接入环境变量管理也可以使用 react-native-config 这类库来处理核心原则就是“源码不出现密钥”。4. 完整实战构建一个移动端任务助手 Agent接下来我们动手实现一个精简但完整的移动端 Agent。这个 Agent 能处理两种任务设置闹钟。添加日历日程。你可以根据业务需求扩展更多工具。4.1 实现 Agent 核心循环AgentLoop 是整个模块的核心。它接收一个用户输入字符串逐步和 LLM 交互执行工具调用最终返回答复。下面是核心代码// src/agent/core/AgentLoop.ts import { LLMClient } from ../llm/LLMClient; import { ToolRegistry } from ./ToolRegistry; import { ShortTermMemory } from ../memory/ShortTermMemory; type AssistantMessage { role: assistant; content?: string; tool_calls?: ToolCall[]; }; type ToolCall { id: string; type: function; function: { name: string; arguments: string; }; }; export class AgentLoop { constructor( private llm: LLMClient, private tools: ToolRegistry, private memory: ShortTermMemory, private maxIterations 5, ) {} async run(userInput: string): Promisestring { this.memory.add({ role: user, content: userInput }); let iterations 0; while (iterations this.maxIterations) { iterations 1; const response await this.llm.complete({ messages: this.memory.getMessages(), tools: this.tools.getToolSchemas(), }); const message: AssistantMessage response.message; if (message.tool_calls message.tool_calls.length 0) { // 记录模型的中间决策 this.memory.add(message); for (const call of message.tool_calls) { const toolName call.function.name; const args JSON.parse(call.function.arguments || {}); console.log([Agent] 调用工具: ${toolName}, args); const result await this.tools.execute(toolName, args); this.memory.add({ role: tool, tool_call_id: call.id, content: JSON.stringify(result), }); } continue; } if (message.content) { this.memory.add({ role: assistant, content: message.content, }); return message.content; } } throw new Error(Agent 执行超过最大迭代次数); } }这段代码实现了完整的 Agent Loop。核心逻辑是把用户输入加入短期记忆。调用 LLM传入消息历史和工具 schema。如果模型返回 tool_calls就逐个执行工具并把工具结果回传给 LLM。如果模型直接返回文本内容说明任务结束返回最终答复。设置 maxIterations 防止死循环。4.2 注册本地工具工具注册表ToolRegistry负责维护所有可用工具。每个工具必须提供描述信息和 schema这样模型才能正确调用。下面是工具注册表的实现// src/agent/core/ToolRegistry.ts type ToolExecutor (args: Recordstring, unknown) Promiseunknown; export interface ToolDefinition { type: function; function: { name: string; description: string; parameters: Recordstring, unknown; }; } export class ToolRegistry { private executors new Mapstring, ToolExecutor(); private definitions: ToolDefinition[] []; register(tool: ToolDefinition, executor: ToolExecutor) { this.definitions.push(tool); this.executors.set(tool.function.name, executor); } getToolSchemas(): ToolDefinition[] { return this.definitions; } async execute(name: string, args: Recordstring, unknown) { const executor this.executors.get(name); if (!executor) { throw new Error(工具 ${name} 未注册); } try { return await executor(args); } catch (error) { return { error: (error as Error).message }; } } }然后我们注册两个系统工具。这里以 React Native 为例创建闹钟和日历日程// src/agent/tools/system/AlarmTool.ts import { ToolRegistry } from ../../core/ToolRegistry; import NativeAlarmModule from ../../../services/NativeAlarmModule; export function registerAlarmTool(registry: ToolRegistry) { registry.register( { type: function, function: { name: create_alarm, description: 创建系统闹钟。用户要求设置闹钟时调用此工具。, parameters: { type: object, properties: { hour: { type: number, description: 小时0-23 }, minute: { type: number, description: 分钟0-59 }, label: { type: string, description: 闹钟标签例如起床闹钟 }, }, required: [hour, minute], }, }, }, async (args) { const { hour, minute, label } args as { hour: number; minute: number; label?: string; }; const id await NativeAlarmModule.createAlarm({ hour, minute, label: label ?? 闹钟, }); return { success: true, alarmId: id }; }, ); }// src/agent/tools/system/CalendarTool.ts import { ToolRegistry } from ../../core/ToolRegistry; import NativeCalendarModule from ../../../services/NativeCalendarModule; export function registerCalendarTool(registry: ToolRegistry) { registry.register( { type: function, function: { name: create_calendar_event, description: 创建日历日程。用户要求添加日程、安排会议或提醒时调用此工具。, parameters: { type: object, properties: { title: { type: string, description: 日程标题 }, startTime: { type: string, description: 开始时间ISO8601 格式 }, endTime: { type: string, description: 结束时间ISO8601 格式 }, notes: { type: string, description: 日程备注 }, }, required: [title, startTime, endTime], }, }, }, async (args) { const { title, startTime, endTime, notes } args as { title: string; startTime: string; endTime: string; notes?: string; }; const id await NativeCalendarModule.createEvent({ title, startTime, endTime, notes, }); return { success: true, eventId: id }; }, ); }这里我假设NativeAlarmModule和NativeCalendarModule是已经封装好的原生桥接模块。实际项目中你需要用 React Native 的 NativeModules 编写对应的原生代码或者使用第三方库比如react-native-alarms、react-native-calendar-events。4.3 接入简易记忆模块短期记忆用简单的消息数组实现。这里有两点需要注意要限制最大消息条数。如果对话太长需要做截断或摘要把早期消息压缩。工具调用结果不要无限累积否则超出模型上下文窗口。// src/agent/memory/ShortTermMemory.ts export type MemoryMessage { role: system | user | assistant | tool; content?: string; tool_call_id?: string; tool_calls?: unknown[]; }; export class ShortTermMemory { private messages: MemoryMessage[] []; constructor(private maxMessages 30) {} add(message: MemoryMessage) { this.messages.push(message); if (this.messages.length this.maxMessages) { const overflow this.messages.length - this.maxMessages; this.messages.splice(1, overflow); } } getMessages(): MemoryMessage[] { return this.messages; } clear() { this.messages []; } }长期记忆模块在示例中先做简化处理把每次任务的摘要保存到本地存储。生产环境推荐使用 SQLite 或者本地向量数据库来做检索。// src/agent/memory/LongTermMemory.ts import AsyncStorage from react-native-async-storage/async-storage; const MEMORY_KEY agent_long_term_memory; export class LongTermMemory { async saveSummary(summary: string) { const history await this.getAll(); history.push({ content: summary, timestamp: Date.now(), }); const recent history.slice(-100); await AsyncStorage.setItem(MEMORY_KEY, JSON.stringify(recent)); } async getAll(): PromiseArray{ content: string; timestamp: number } { const raw await AsyncStorage.getItem(MEMORY_KEY); if (!raw) return []; return JSON.parse(raw); } }在 Agent 启动时可以把最近的长期记忆作为 system prompt 注入让模型知道用户的偏好和过去完成的任务。4.4 UI 交互层设计Agent 运行过程中模型可能会连续调用多个工具如果 UI 一直不响应用户会以为卡死了。好的交互设计应该把 Agent 的中间状态可视化。我们可以设计一个简单的消息流界面// src/screens/AgentChatScreen.tsx import React, { useState } from react; import { View, TextInput, Button, FlatList, Text } from react-native; export function AgentChatScreen({ agent }: { agent: AgentLoop }) { const [input, setInput] useState(); const [messages, setMessages] useState Array{ id: string; type: user | agent | tool | status; text: string } ([]); const send async () { if (!input.trim()) return; const userText input.trim(); setInput(); setMessages((prev) [ ...prev, { id: ${Date.now()}-user, type: user, text: userText }, { id: ${Date.now()}-status, type: status, text: Agent 思考中... }, ]); try { // 这里可以监听工具调用事件更新 UI const result await agent.run(userText); setMessages((prev) { const withoutStatus prev.filter((msg) msg.type ! status); return [ ...withoutStatus, { id: ${Date.now()}-agent, type: agent, text: result }, ]; }); } catch (error) { setMessages((prev) { const withoutStatus prev.filter((msg) msg.type ! status); return [ ...withoutStatus, { id: ${Date.now()}-error, type: agent, text: 执行失败${(error as Error).message} }, ]; }); } }; return ( View style{{ flex: 1 }} FlatList data{messages} keyExtractor{(item) item.id} renderItem{({ item }) Text{item.text}/Text} / TextInput value{input} onChangeText{setInput} placeholder试试说帮我设置一个明早7点的闹钟 style{{ borderWidth: 1, padding: 8 }} / Button title发送 onPress{send} / /View ); }这段代码实现了最基本的人机交互界面。如果你想展示工具调用的中间状态可以通过订阅事件的方式在 UI 中滚动显示“正在调用闹钟工具”“闹钟创建成功”等状态卡片。4.5 运行与验证完成以上代码后启动 App输入下面这段对话测试帮我设置一个明早 7 点的闹钟标签写“早起”。正常情况下模型会返回一个 tool_calls 调用请求AgentLoop 捕获后执行create_alarm工具。如果原生模块实现正确手机系统会出现一个 7:00 的闹钟模型最终回复类似已为你设置明早 7:00 的闹钟标签为“早起”。再测试一下组合任务明天下午 3 点有一个产品评审会帮我加到日历里提醒我提前 10 分钟。Agent 会调用create_calendar_event在实际的日历 App 中创建日程并设置提醒。5. 多 Agent 协作机制阿一个只处理闹钟和日程的 Agent 相对简单。真实场景中一个 Agent 往往不够用这时就需要考虑多 Agent 协作。5.1 为什么需要多 Agent当一个任务的复杂度上升后单一的 Agent 会出现几个问题工具数量过多模型的 function calling 选择准确率下降。上下文过长模型容易丢失关键信息。安全边界不清晰比如一个负责操作财务系统的 Agent 不应该随意访问通讯录。多 Agent 的思路是把不同职责拆分给不同角色。比如在一个 App 中助手 Agent负责整体对话协调。日程 Agent专门处理日历相关任务。通信 Agent专门处理消息、邮件相关任务。搜索 Agent专门负责信息查询和内容总结。当用户说“帮我安排明天下午的会议并通知参会同事”调度器会先让日程 Agent 创建会议再把结果交给通信 Agent 发送通知。5.2 分工与编排多 Agent 的编排方式有很多种常见的有单一调度器Supervisor一个主 Agent 负责分发任务给子 Agent。流水线Pipeline任务按步骤依次交给不同 Agent。图编排GraphAgent 之间按照依赖关系 DAG 执行。在移动端场景下Supervisor 模式最容易实现也最容易调试。调度器本身也是一个 Agent它只负责理解意图、选择子 Agent、汇总结果。// src/agent/core/SupervisorAgent.ts export class SupervisorAgent { private agents: Recordstring, AgentLoop {}; register(name: string, agent: AgentLoop) { this.agents[name] agent; } async dispatch(userInput: string): Promisestring { // 简化实现这里可以通过 intent classification 决定交给哪个子 Agent if (userInput.includes(闹钟) || userInput.includes(日历)) { return this.agents.schedule.run(userInput); } if (userInput.includes(天气)) { return this.agents.search.run(userInput); } return this.agents.default.run(userInput); } }生产环境不建议写这种简单的 if-else 分法更好的方案是让调度器模型输出{agent: schedule, reason: ...}这样的结构化结果再由代码转发。5.3 消息传递与会话管理多 Agent 协作时消息传递是一个容易出问题的地方。每个子 Agent 都有自己的短期记忆但它们之间需要共享用户意图和最终上下文。建议做法是子 Agent 返回结构化结果而不仅仅是文本。调度器把子 Agent 的结果整合后再更新全局会话上下文。使用事件总线机制解耦各个 Agent 的通信。6. 常见问题与排查思路移动端 Agent 开发中大家碰到的问题往往集中在以下几个方面问题现象常见原因解决思路模型不调用工具直接回复文本工具描述不够清晰或模型不支持 function calling优化工具 description检查模型接口是否开启 tools 参数工具参数解析失败模型生成的 JSON 格式不合法增加 JSON 解析容错比如使用渐进式 JSON 解析器Agent 进入死循环工具一直返回错误模型反复重试设置 maxIterations并在工具执行失败时返回明确错误信息上下文超出模型限制短期记忆未做截断或摘要使用滑动窗口对早期消息做摘要压缩调用系统工具无响应原生模块未正确注册或权限未申请检查 NativeModules 桥接确认 Android/iOS 权限配置API Key 泄露源码中硬编码了密钥改为后端代理转发客户端只请求自己的服务弱网环境响应慢每次循环都请求云端 LLM增加本地缓存、轻量级意图预判或启用端侧小模型做路由如果你遇到 Agent 执行到一半报错可以参考下面的排查顺序打印每次 LLM 的原始返回结构确认 tool_calls 是否存在。确认工具是否完成注册名称是否与模型返回一致。检查工具执行结果是否成功失败时返回的 error 是否包含足够信息。检查短期记忆中消息角色是否正确特别是 tool 消息的 tool_call_id 必须和 assistant 工具调用匹配。逐步提高 maxIterations观察是否仍出现死循环。7. 最佳实践与工程建议7.1 安全边界必须前置设计移动端 Agent 因为能调用系统能力安全风险比普通 App 更高。如果 Agent 可以随意创建闹钟、发送短信、读取通讯录恶意提示词注入可能造成严重问题。建议所有工具执行前做参数校验禁止越权参数。危险操作二次确认比如发送消息、删除数据、付费操作。对模型输入做基础的注入检测尤其是在工具结果返回后拼接进上下文时防止工具结果中的恶意内容污染后续决策。服务端做好用户级权限隔离Agent 能访问的数据范围不能超过用户自身权限。7.2 工具 schema 要像 API 文档一样维护工具 schema 是模型理解工具的唯一依据。描述模糊或者参数说明不清楚模型就会乱调用。我的经验是工具命名使用动词开头如create_alarm、send_message、query_order。description 写清楚触发条件和边界情况。参数尽量使用枚举值减少模型自由发挥的空间。对于可选参数标注默认行为。7.3 日志与可观测性Agent 的调试难度远高于普通功能因为它是多轮循环调用黑盒感很强。建议在关键节点输出日志用户输入原文。模型每次返回的 message 全文。工具调用名称、参数、执行结果。短期记忆截断/摘要行为。生产环境将这些日志上报到后台方便后续分析模型表现和用户使用模式。7.4 成本控制LLM API 按 token 计费移动端 Agent 的每一次工具调用都会额外消耗 token。成本优化可以从下面几个方向入手限制 maxIterations避免无效循环消耗。对长上下文做摘要压缩。使用端侧模型处理简单意图判断只有复杂任务才请求云端大模型。在服务端增加缓存比如相同或相似的用户请求直接返回缓存结果。7.5 移动端特有的性能考虑移动端 CPU、内存、网络资源都有限。Agent 运行过程中要注意不要在 UI 线程执行任何 Agent 逻辑。LLM 请求要做超时处理建议 15 秒以上但不要无限等待。如果 Agent 在后台运行需要申请后台任务权限或者改为服务端执行方案。需要关注 App 进程被杀后的状态恢复Agent 状态要支持持久化。8. 总结移动端 Agent 并不是一个遥不可及的概念。把大模型的能力与移动端系统能力整合起来就能让 App 从一个“界面语言”升级为具备任务拆解和自动执行能力的智能助手。本文从 Agent Loop、工具注册、记忆管理、多 Agent 协作等核心模块出发给出了一套可以落地的最小实现方案。在实际项目中建议先从单一场景试点比如只做日程管理或者闹钟设置跑通整个闭环后再逐步扩展工具库。这样既能控制成本也方便定位问题。移动端 Agent 的想象空间很大但工程上还是一步一步来更稳妥。如果你正在做移动端 Agent 项目欢迎在评论区交流你的架构方案和踩坑经验。后续我还会整理一篇关于移动端 Agent 记忆增强和向量检索的实战文章感兴趣的话可以先收藏关注。