旧手机也能跑 Agent？Nokia 110 4G 把通话、手电筒和闹钟接进 AI 对话
AI Agent 并不一定要运行在高端手机、云服务器或桌面电脑上。一个只有数字键盘、约 48 MB 内存的 Nokia 110 4G，也可以通过反向工程和极简工具调用逻辑，完成问答，并操作手机自身的功能。这个由 anupray 开发的实验项目目前仍是原型，但它提出了一个很有价值的问题：Agent 的核心究竟是庞大的运行时，还是“根据意图选择受限动作”的能力？
它在手机上做了什么
项目作者修改了 Nokia 110 4G 的固件，把原本的 Calculator 应用改造成一个原生聊天应用。用户使用数字键盘输入问题，应用通过 SIM 卡的数据连接访问 DeepSeek Chat API，再根据模型返回的工具调用执行手机动作。
目前 README 明确展示了五类能力：
- 查询电池电量；
- 打开或关闭手电筒；
- 发起电话呼叫；
- 设置闹钟；
- 通过手机网络回答问题。
这不是在 Nokia 上运行一个完整的通用 Agent 框架。设备内存有限，普通 Agent 运行时很难直接塞进固件，所以项目采用了非常小的自定义 Agent，并通过更小的构建产物、压缩 payload 和复用缓冲区来控制内存占用。模型负责理解自然语言，手机端只保留连接、解析和执行动作所需的最小部分。
最关键的工程取舍：先跑在 RAM 里
项目没有选择直接刷写永久固件，而是通过 Calculator 的入口把自定义代码加载到 RAM 中。这样做的好处是风险更低，便于反复测试；代价是手机重启或关机后，代码需要再次从电脑加载，永久安装仍未解决。
这个限制反而说明了原型的边界：它已经能在拔掉 USB 后使用移动数据独立工作，但还不是可以交付给普通用户的安装包。对于固件实验，先把“能启动、能联网、能调用动作”的闭环跑通，通常比一开始追求永久刷机更稳妥。
从浏览器搜索到原生动作
作者的实现过程大致经历了几个阶段。最初是在 Opera Mini 中增加 AI 搜索功能，这证明手机可以完成网络请求，却不能让模型直接控制原生功能。随后，作者研究启动流程和固件响应回调，让自定义代码可以从 Calculator 入口运行；再解决 SIM 数据请求的返回路径、文本输入、界面绘制和按键处理问题。
真正困难的是把聊天变成动作。普通手机 Agent 往往可以调用系统 API，但这台设备没有适合现代应用开发的公开原生接口。项目因此需要在固件层找到已有能力的调用路径，同时避免写错样式字段或破坏内存布局。README 记录了一个实际调试教训：一次颜色修改写入了错误的 style 字段，导致设备重启，最后通过追踪固件行为定位并修复。
一个适合边缘设备的工具调用模型
这个项目最值得借鉴的不是“把 AI 塞进老手机”的猎奇感，而是它展示了边缘 Agent 的简化架构：
用户输入 ↓ 手机端聊天应用 ── SIM 数据 ──> DeepSeek Chat API ↑ ↓ └──── 受限工具调用：电量 / 手电筒 / 电话 / 闹钟
在这种架构中，模型不直接拥有任意代码执行权限。手机端只实现少量明确动作，并把参数转换成设备能理解的调用。对嵌入式设备来说，这比部署完整 Python 或 JavaScript 运行时更现实，也更容易审计。
如果要把类似思路用于自己的硬件项目，可以遵循三条原则。第一，先列出最小动作集合，不要从“让 Agent 控制一切”开始。第二，把模型输出当作不可信输入，在设备端校验动作名称和参数。第三，为网络不可用、模型返回格式错误和动作执行失败设计明确的降级路径。比如电话动作应当要求二次确认，闹钟参数必须检查时间范围，手电筒则可以设计成幂等的开关操作。
它还不能证明什么
项目没有上传完整源码，作者说明工程中散落着敏感数据；GitHub 仓库也没有声明一个可直接复用的开源许可证。因此，读者可以参考架构和调试过程，但不应把它当作可直接烧录的发行版。它也没有证明老式功能手机已经适合运行通用 AI：当前原型依赖外部 API，永久安装未解决，功能集合仍然很小。
不过，正因为限制清楚，这个实验才有参考价值。它把 Agent 拆成了几个可验证的问题：如何输入、如何联网、如何解析意图、如何映射到原生动作，以及如何在极少内存中保持稳定。对做 IoT、无障碍设备或离线终端的开发者来说，这种“云端理解、端侧执行少量安全动作”的模式，可能比追求一个完整的本地大模型更容易落地。