这次我们来看一个很有意思的折腾场景在一台 Android 手机上用 Termux 跑一套 10 层 SQLite Agent Mesh。手机不是服务器但如果你只是想做个边缘侧多 agent 实验或者手头正好有台旧手机想废物利用这套方案比买云服务器便宜很多。真正的难点不是装环境而是热节流thermal throttling——SoC 温度一上来系统直接压低大核频率mesh 的整体吞吐量会断崖式下降。下面从架构设计、Termux 部署、SQLite 调优到温度监控和降频规避完整过一遍。这套方案的核心是把 SQLite 当成 agent 网格的共享状态总线。10 层 agent 各自承担不同职责通过数据库表传递任务和结果不需要额外引入消息队列。本文会给出层级划分、Schema 设计、Termux 部署步骤、热节流检测脚本和常见排查清单。适合想在 Android 设备上做轻量级 agent 实验、边缘计算或临时内网服务的开发者。先说硬件门槛。只要手机是 Android 7 以上、有 4GB 内存基本都能跑。CPU 最好是 8 核因为 10 层 mesh 如果都开多进程核心太少会互相争抢。温度控制比绝对配置更重要这也是下文重点展开的部分。全程不强制要求 root但部分 CPU 调频手段在非 root 下不可用我会在对应位置标清楚。所有操作都建议只在自有设备上测试不要用于扫描、爆破或任何未授权访问。1. 核心能力速览先给一张表快速判断这个方案适不适合你。能力项说明方案类型Termux SQLite 构成的 10 层 Agent Mesh 架构层级规模10 层 agent 流水线层间通过 SQLite 表传递任务状态消息总线SQLite 单文件数据库WAL 模式无额外中间件运行平台Android 手机 / 平板Termux 环境内存门槛建议 4GB 起步8 核 SoC 更稳热节流关键指标/sys/class/thermal/thermal_zone*/temp温度、scaling_cur_freq当前频率批量任务能力通过 agent_tasks 队列表 背压机制批量消费API 服务能力可在 Termux 中安装 FastAPI/Flask 自建 HTTP 接口数据持久化SQLite 单文件重启不丢任务适合场景本地多 agent 实验、轻量级边缘计算、内网工具链需要说明这不是某个现成的一键开源项目而是一套可以在 Termux 里手工搭建的架构方案。实际温度、功耗、吞吐量会因手机型号和 SoC 调度策略不同而有明显差异下面的内容以通用部署路径为主。2. 适用场景与使用边界这方案最适合三类人。第一类是做 agent 框架实验的开发者。Agent 之间需要共享上下文和任务状态SQLite 比内存队列更稳比正式消息队列更轻。手机跑实验不花钱随时重启环境坏了直接删数据重来。第二类是边缘计算爱好者。家里有旧手机可以把它变成一台低功耗的小型任务处理节点比如定时拉取数据、执行文本处理、生成结构化报告。SQLite 单文件存储非常适合这种小规模、低并发、长周期的任务场景。第三类是想验证数据库承载能力的工程师。SQLite 通常被认为只适合单机小应用但通过 WAL 模式、批量事务、单写多读设计它也能在低负载下充当多个 agent 之间的消息总线。这篇方案本身就是一次比较极端的压力实验。使用边界要提前讲清楚只允许在具备授权和自主控制权的设备上使用。手机、电脑、服务器只要不是自己的或不具备测试授权都不要碰。Termux 功能很完整但不代表可以拿去做渗透、扫描、爆破、流量攻击、破解无线网络等未授权行为。这类用法违法也会带来严重安全风险。Agent mesh 如果接入公网服务注意只在可信网络环境运行避免开放高权限端口。如果涉及真实用户数据、文本、图片处理前必须确认数据来源合法并做好脱敏。3. 10 层 Agent Mesh 架构设计为什么用 SQLite 做网格存储Agent Mesh 的核心思路是多个 agent 不是简单串行调用而是形成一个网状协作结构。每个 agent 有独立职责通过共享状态感知任务进度。在这个方案里共享状态就是 SQLite 数据库。10 层不是随便写的数字而是把一条相对完整的任务流水线拆成了 10 个职责阶段Tier职责说明Tier 0入口接入接收外部请求生成任务Tier 1任务解析把原始输入拆成结构化指令Tier 2数据清洗去重、格式校验、字段补全Tier 3上下文增强从 SQLite 历史表读取上下文Tier 4检索查询按条件查询相关任务或知识条目Tier 5推理计算执行核心逻辑或调用本地模型Tier 6工具调用执行文件操作、网络请求等工具任务Tier 7结果校验检查输出格式和合法性Tier 8输出整理生成最终结构化结果Tier 9审计归档写入审计表完成闭环每个 agent 都是独立的 Python worker轮询agent_tasks表中属于自己 tier 的任务。处理完当前任务后写入 result并创建下一个 tier 的任务。数据库中的表就是 agent 之间通信的“网格总线”。这种设计有几个好处不需要独立部署消息队列依赖更少。任务状态天然持久化手机重启后还在。SQLite 事务保证任务状态一致性。每个 tier 可以独立启停方便调试。但它也有代价SQLite 的写入并发能力有限多个 agent 同时写同一张表会锁库。所以要靠“批量事务 单写者 背压”来规避后面会细说。4. Termux 部署环境准备与基础配置Termux 建议从 F-Droid 安装官方版本不推荐 Play Store 版本因为 Play 版长期不更新部分包会装不上。安装完成后先做基础更新和包安装。# 更新 Termux 包索引和已安装包 pkg update -y pkg upgrade -y # 安装 Python、SQLite、构建工具和 Git pkg install -y python sqlite openssl git build-essentialPython 自带sqlite3标准库所以理论上不需要额外安装 SQLite 包。但建议单独安装一遍 sqlite3 命令行工具方便直接查库。# 验证 Python 和 SQLite 版本 python --version sqlite3 --versionTermux 虽然默认有 storage 权限但直接访问 /sdcard 会受限。建议通过termux-setup-storage授权一次存储访问权限这样可以把数据库文件放到手机存储里慢慢归档。注意这会把手机内部存储路径暴露给 Termux 环境只在自己设备上使用即可。# 授权 Termux 访问手机存储 termux-setup-storage如果需要监控电池温度可以安装 termux-api 和对应插件pkg install termux-api这样就能用termux-battery-status拿到电池温度后面会把它作为热节流辅助监控数据。CPU 内部温度则通过读取 Linux 的 thermal zone 接口获得。5. 建库、建网格与层级任务启动环境准备完成后先设计数据库 Schema。这里的核心表只有三张agent_tasks存储所有任务agent_meta记录每个 agent 的运行状态audit_log保存审计记录。-- schema.sql PRAGMA journal_modeWAL; PRAGMA synchronousNORMAL; PRAGMA busy_timeout5000; CREATE TABLE IF NOT EXISTS agent_tasks ( id INTEGER PRIMARY KEY AUTOINCREMENT, tier INTEGER NOT NULL, status TEXT DEFAULT pending, payload TEXT, result TEXT, error TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX IF NOT EXISTS idx_agent_tasks_pending ON agent_tasks(tier, status, created_at); CREATE TABLE IF NOT EXISTS agent_meta ( tier INTEGER PRIMARY KEY, agent_name TEXT, last_seen TIMESTAMP, processed_count INTEGER DEFAULT 0 ); CREATE TABLE IF NOT EXISTS audit_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id INTEGER, tier INTEGER, action TEXT, detail TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );把 schema 保存下来然后在 Termux 里建库mkdir -p ~/agent-mesh cd ~/agent-mesh sqlite3 mesh.db schema.sql接下来写一个最小可运行的 agent worker。下面这个脚本每个进程启动时可以选择负责某个 tier。import sqlite3 import json import time import sys DB_PATH mesh.db TIER int(sys.argv[1]) def get_connection(): conn sqlite3.connect(DB_PATH, timeout10) conn.row_factory sqlite3.Row return conn def process_pending_tasks(tier): conn get_connection() while True: # 用 BEGIN IMMEDIATE 降低锁竞争 conn.execute(BEGIN IMMEDIATE) try: row conn.execute( SELECT * FROM agent_tasks WHERE tier? AND statuspending ORDER BY created_at LIMIT 1, (tier,) ).fetchone() if row is None: conn.commit() time.sleep(2) continue # 拿到任务后标记为 processing conn.execute( UPDATE agent_tasks SET statusprocessing, updated_atCURRENT_TIMESTAMP WHERE id?, (row[id],) ) conn.commit() # 假设每个 tier 的 agent 都往 result 里写一段处理标记 result { tier: tier, input_id: row[id], note: fprocessed by tier {tier} } # 写回结果并生成下一 tier 的任务 conn.execute(BEGIN IMMEDIATE) conn.execute( UPDATE agent_tasks SET statusdone, result?, updated_atCURRENT_TIMESTAMP WHERE id?, (json.dumps(result), row[id]) ) if tier 9: conn.execute( INSERT INTO agent_tasks(tier, status, payload) VALUES (?, pending, ?), (tier 1, json.dumps({parent_id: row[id]})) ) conn.execute( INSERT INTO audit_log(task_id, tier, action) VALUES (?, ?, completed), (row[id], tier) ) conn.commit() except Exception as e: conn.rollback() print(error:, e) time.sleep(2) finally: conn.close() if __name__ __main__: process_pending_tasks(TIER)启动方式开 10 个 Termux 会话或后台进程分别指定 tier 0 到 9。cd ~/agent-mesh nohup python worker.py 0 worker_0.log 21 /dev/null nohup python worker.py 1 worker_1.log 21 /dev/null # 其他 tier 同理生产环境不建议 nohup 这样裸跑建议写一个start_all.sh管理进程。可以先在 Termux 前台跑一个 worker确认能轮询任务后再放后台。6. 热节流检测先学会看温度和降频热节流的本质是SoC 温度超过阈值系统通过 DVFS 动态电压频率调节降低 CPU 频率减少发热。检测热节流重点看两个指标thermal zone 温度和 CPU 实时频率。Android 的 Linux 内核一般会在/sys/class/thermal下暴露多个 thermal_zone。不同型号厂商对 zone 编号定义不同通常某个 zone 对应 CPU某个 zone 对应电池。先用下面命令把全部温度拉出来for zone in /sys/class/thermal/thermal_zone*/; do printf %s: $(basename $zone) cat $zone/temp done温度单位一般是毫摄氏度除以 1000 就得到摄氏度。比如输出75000表示 75℃。再查 CPU 当前频率# 查询每个 CPU 核当前频率单位 kHz for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq; do printf %s: $(basename $(dirname $cpu)) cat $cpu done如果当前频率持续低于scaling_min_freq或无法达到scaling_max_freq基本可以判断发生了降频。不同 SoC 的正常空载频率范围不同所以更实用的方式是观察负载起来之前记录一次频率基线运行 mesh 后再记录一次对比是否被明显压住。建议写一个 Python 温度监控脚本一边跑任务一边记录变化import os import time import json THERMAL_PATH /sys/class/thermal def read_thermal_zones(): zones {} try: for name in sorted(os.listdir(THERMAL_PATH)): if not name.startswith(thermal_zone): continue zone_path os.path.join(THERMAL_PATH, name, temp) if os.path.exists(zone_path): with open(zone_path, r) as f: temp_raw f.read().strip() zones[name] int(temp_raw) / 1000.0 except Exception as e: print(failed to read thermal zone:, e) return zones def read_cpu_freqs(): freqs [] base /sys/devices/system/cpu try: for name in sorted(os.listdir(base)): if not name.startswith(cpu) or not name[3:].isdigit(): continue freq_path os.path.join(base, name, cpufreq, scaling_cur_freq) if os.path.exists(freq_path): with open(freq_path, r) as f: freqs.append(int(f.read().strip()) / 1000.0) except Exception as e: print(failed to read cpu freq:, e) return freqs while True: temp read_thermal_zones() freq read_cpu_freqs() record { time: time.time(), temp: temp, freq_mhz: freq } with open(thermal_log.jsonl, a) as f: f.write(json.dumps(record) \n) time.sleep(3)这个脚本会在后台持续记录跑完一轮 mesh 任务后用数据判断有没有发生明显降频。7. SQLite 调优与热节流规避热节流规避不能只靠“少干活”还要在架构层面让负载更平缓。SQLite 是这套系统的核心存储调好它既减少锁等待也降低 CPU 峰值占用。7.1 设置 WAL 模式和合理的 PRAGMA前面 schema 里已经写了journal_modeWAL、synchronousNORMAL。WAL 模式下读写并发能力更强写入时也不需要频繁刷盘。synchronousNORMAL在极端断电情况下可能丢最近事务但手机场景可接受。启动时还可以加PRAGMA mmap_size268435456提高内存映射大小减少系统调用开销。注意虚拟内存占用会上升内存小于 4GB 的设备不要设置太大。sqlite3 mesh.db PRAGMA journal_modeWAL; sqlite3 mesh.db PRAGMA synchronousNORMAL; sqlite3 mesh.db PRAGMA mmap_size268435456;7.2 批量事务agent worker 如果每处理一条任务都立刻提交一个事务磁盘写入会很频繁。更好的方式是每次拉一批任务批量处理攒到一定数量再统一提交。这样能显著减少 fsync 次数也就减少了 CPU 峰值负载和发热。适当改造 worker 的循环逻辑一次拿 10 条任务处理完后在同一个事务里更新状态。SQLite 对同一个连接的写事务是串行的但在 WAL 模式下读和写可以并发。7.3 背压机制10 层 mesh 里如果上游 tier 拼命生成任务下游 tier 处理不过来数据库里的 pending 任务就会越堆越多。SQLite 本身不是队列服务器无限堆积会影响查询性能。背压机制的做法是每个 worker 在处理新任务前先检查自己 tier 的 pending 数量超过阈值就 sleep 更长时间。def get_pending_count(conn, tier): return conn.execute( SELECT COUNT(*) FROM agent_tasks WHERE tier? AND statuspending, (tier,) ).fetchone()[0] # 在 worker 循环里如果 pending 数量太多就等待更久 pending get_pending_count(conn, tier) if pending 20: time.sleep(5) else: time.sleep(1)这样做的好处是压力大的时候所有 agent 自动降速避免持续峰值负载。这个机制对热节流非常重要因为“持续全速跑”正是手机温度飙升的主要原因。7.4 进程级资源限制Termux 非 root 环境下能做的基础资源控制用nice降低进程优先级让系统调度器优先保证系统进程和其他应用。用taskset限制 agent 进程只在部分核心上跑给其他核心留出空闲。用timeout给单条任务加超时防止某个 agent 卡死。# 以较低优先级运行 tier 0 的 agent nice -n 10 python worker.py 0 # 限制进程只使用 CPU0 到 CPU3 taskset -c 0-3 python worker.py 0需要说明的是nice只能改变优先级不能直接锁频。如果手机温度还是压不住root 设备可以尝试通过sysfs直接修改scaling_max_freq但不同设备接口差异大这里不展开实际操作前需要确认内核是否开放权限。7.5 间歇性运行代替长时全速运行如果温度持续逼近 70℃ 以上更实用的是把任务改成“间歇性批量跑”。比如脚本每 10 分钟唤醒一次处理完当前批次后进入 sleep。这样每个周期内 CPU 都有休息时间温度曲线是波动而不是单边上升。8. 功能测试与效果验证部署完成后先做一组功能测试确认 mesh 能跑通再判断热节流影响。建议按以下步骤走。8.1 插入一条 Tier 0 测试任务sqlite3 mesh.db INSERT INTO agent_tasks(tier, status, payload) VALUES (0, pending, {\test\: 1});然后只启动一个负责 tier 0 的 worker确认它能消费任务并生成 tier 1 任务。用 SQL 查询验证sqlite3 mesh.db SELECT id, tier, status, result FROM agent_tasks ORDER BY id DESC LIMIT 5;预期结果是第一条任务 tier 0 变为 done并产生一条 tier 1 pending 任务。8.2 启动完整 10 层链路全部 worker 启动后再插入一条任务。正常运行情况下任务会从 tier 0 一路流转到 tier 9最终所有状态为 done。可以用下面命令统计各 tier 任务量sqlite3 mesh.db SELECT tier, status, COUNT(*) FROM agent_tasks GROUP BY tier, status;如果某个 tier 一直有 pending 没被消费说明该 tier 的 worker 没启动、崩溃或者轮询循环有问题。8.3 批量任务测试生成 100 条测试任务观察完成时间和温度变化for i in $(seq 1 100); do sqlite3 mesh.db INSERT INTO agent_tasks(tier, status, payload) VALUES (0, pending, {\id\: $i}); done跑完后结合thermal_log.jsonl看温度曲线。如果温度超过 75℃ 或频率被压到基线以下说明热节流已经发生需要启用背压和批量事务优化。8.4 稳定性观察观察点有三个worker 是否长时间无日志输出。agent_tasks表中是否出现长期卡在 processing 的记录。温度是否持续上升不回落。如果出现某个 task 长期 processing大概率是 worker 处理异常或进程崩溃。排查时可以把这个 task 的 status 改回 pendingsqlite3 mesh.db UPDATE agent_tasks SET statuspending, updated_atCURRENT_TIMESTAMP WHERE statusprocessing AND updated_at datetime(now, -5 minutes);9. 常见问题与排查方法问题现象可能原因排查方式解决方案Termux 安装包失败源连接慢或索引过期检查pkg update日志更换镜像源或稍后重试Python 提示 sqlite3 版本过低Termux 自带包版本较旧python -c import sqlite3; print(sqlite3.sqlite_version)执行pkg upgrade升级依赖Worker 启动后立刻退出参数缺失或代码语法错误查看 nohup 日志或前台运行检查sys.argv[1]是否传入 tier任务一直在 pendingWorker 未运行或轮询异常ps auxgrep worker.py数据库提示 database is locked多进程写锁竞争查看 busy_timeout 配置开启 WAL 模式增加 busy_timeout温度持续超过 75℃负载过高或散热差查看 thermal 日志和 CPU 频率启用背压降低任务速率换更强散热环境手机整体卡顿多个 worker 抢占 CPU查看系统 CPU 占用使用 nice 和 taskset 限制 worker 资源任务状态变成 processing 后无人处理Worker 在执行过程中崩溃查看日志和审计表增加异常捕获重置超时任务频率一直很低系统主动降频对比负载前后频率基线降低任务并发等待温度回落10. 最佳实践与合规提醒这套方案想长期稳定跑建议从第一天就养成下面几个习惯。第一把数据库、日志、任务输入输出分目录管理。Termux 里目录混乱会让排查变得很痛苦。建议用~/agent-mesh/data存数据库~/agent-mesh/logs存日志~/agent-mesh/scripts存脚本。第二不要一上来就拉满 10 层。先跑通 tier 0 到 1再逐步加层。每加一层都观察一次温度和频率变化。10 层 mesh 是最终形态不是初始形态。第三给每个 agent 进程加超时和重试。SQLite 锁冲突不是偶发现象多进程下几乎必然出现。代码里要把异常处理和重试逻辑写清楚。第四定期清理任务表。agent_tasks如果长期不清理表越来越大查询会变慢。可以用定时任务把已完成的记录归档到独立表。第五合规边界。再次强调Termux 方案只适用于自有设备或明确授权的测试环境。不得使用它扫描、爆破、攻击未授权设备不得抓取和分析非授权网络的流量。涉及个人数据、文本、图片时先确认来源合法并做脱敏处理。在手机这类个人设备上跑 agent尤其要注意不把敏感上下文写入会被第三方读取的位置。11. 总结与下一步10 层 SQLite Agent Mesh 在 Termux 上能不能跑从架构设计角度看完全可以真正的控制点不是性能而是热节流。SQLite 作为轻量级共享状态总线配合 WAL、批量事务、背压机制可以把 CPU 峰值负载压下去让手机在可接受温度范围内稳定运行。最先应该验证的三件事第一tier 0 到 tier 1 的任务流转是否正常第二查看/sys/class/thermal的温度读取是否成功第三跑 100 条批量任务后看温度和scaling_cur_freq的变化曲线。先把这三步跑通再扩展后续层级。最容易踩的坑是 SQLite 锁竞争和手机降频同时出现。多 worker 写入时busy_timeout 设置太小任务频繁失败agent 不断重试CPU 占用继续上升温度继续升高形成恶性循环。解决思路是先降并发再加背压最后才是调 SQLite 参数。下一步可以继续扩展的方向很多给这套 mesh 加一个 FastAPI 接口让内网其他设备能提交任务把 SQLite 换成更强的本地时序存储方案或者为每个 agent 增加独立日志追踪链路。核心思路不变能用数据库解决的问题就不要引入过重的中间件在手机上尤其如此。