Android Agent 怎样分层，才能更换模型和适配不同系统？

标准回答

我会把系统分成五个职责：UI 展示任务状态；编排层决定下一步和管理超时取消；模型适配层处理不同供应商或本地模型；工具层封装 Android 能力；数据层保存任务、配置和允许保留的记忆。这是职责划分，不一定要拆成五个进程或五个大型模块。

UI 只提交用户意图并观察状态，不直接拼模型请求，也不直接调用系统服务。编排层持有任务状态机，通过模型接口获得结构化输出，再交给工具注册表执行。权限、幂等和结果核实属于执行边界，不能藏在某一个模型的提示词里。

模型适配层统一文本增量、工具调用、完成和错误事件，同时保留能力差异，例如是否支持工具调用、图片输入或特定上下文长度。不能为了接口统一，假设不同模型行为完全一致。系统工具则通过能力查询和适配实现隔离 OS、机型、授权差异，业务层收到明确的可用或不可用结果。

测试时可以注入假模型和假工具，稳定复现“模型输出非法参数、设备超时、服务重启、用户取消”等路径。是否拆独立进程取决于权限隔离、资源占用和崩溃影响；进程增加后还要承担 IPC、启动和状态同步成本，我不会把多进程本身当成架构先进的证明。

从云端模型切换到本地小模型时，聊天页面与设备工具接口保持稳定。适配层报告本地模型不支持某类工具输出，编排层改走受支持的固定流程，而不是让 UI 到处增加模型名称判断。

模型和机型实现可以用策略与适配器隔离差异，工具调用可以封装成命令，任务过程用状态机表达，数据读写通过 Repository 收口。我会先说明每种模式解决了什么变化，再决定是否使用；简单场景用几个清楚的接口就够，不为了模式名称增加层级。

通常不是。还要处理消息格式、工具 Schema 支持、流式事件、错误语义、上下文限制和能力差异。接口接通后，需要用同一批任务比较工具选择、参数正确率、任务成功率和延迟；只有这些行为达到要求，才能说明替换完成。

ViewModel 能跨某些配置变化保留状态，但不能替代进程死亡后的持久化；依赖注入也不会自动解决职责混乱。