由ai协助 on atin的个人小站

Nyral 的多模型协作：讨论团与评审团，让模型一起干活

Mon, 02 Nov 2026 23:45:00 +0800

所有已配置的模型能协作、能当众干活，而 token 消耗始终由用户把关——这是给 Nyral 设计"多模型协作"时的三个目标。方案演化到今天，落地成两种模式：讨论团和评审团。

起因：一次生图模型当主模型翻的车

Nyral 接入腾讯 TokenHub 聚合网关后，我一度把 hy-image-v3.5-preview（混元文生图模型）设成了主聊天模型，结果发一句"你好"就报 400 model not exist。

排查下来的原因很直白：混元多模态是独立的生成模型，没有对话能力，走 chat/completions 必然失败。它真正的调用端点是 POST {base}/v1/wand/hunyuan-image/v35-generation——一个聊天式结构的生成端点，支持 messages 数组、参考图，同步返回 choices[].delta.image.url。

顺手把生图工具和主链路都改到了这个端点，实测通过。但问题随之而来：

用户配了一堆模型（DeepSeek、GLM、小米 MiMo、TokenHub 混元），它们却彼此孤立。 对话靠一个主模型，生图靠工具写死当前 provider，生视频又是另一套。能力是有的，但"各干各的"，谁也不认识谁。

想法：让所有模型互相可见

那天凌晨，我说了一句：能不能让所有模型互相看到？DeepSeek 可以直接调用 GLM，GLM 反过来也能用 DeepSeek，小米同样如此。每个模型都有完整能力，主模型甚至可以"偷懒"，让副模型去干活。

讨论下来，这个概念落地成三层：

模型注册表（所有已配置模型，按能力分组）
      │ 能力路由
      ▼
主模型（主持人 + 决策者 + 汇总者）
      │ model_delegate / 生成工具
      ▼
参与模型（顾问团：各抒己见，结果仅供参考）
      ▼
用户（最终决策者，可随时打断）

模型注册表：设置页里所有 provider + 勾选的模型，按能力标注分组（对话 / 生图 / 生视频）。配一次 TokenHub Key，对话选 hy4、生图选 hy-image、生视频选 hy-video，全部互相可见。
主模型当主持人：议题由它定，请谁参与由它提议，观点由它汇总收敛，结论由它呈现给用户。它自己也可以参与讨论——毕竟它掌握上下文和工具。
参与模型是顾问团：每次发言是一次独立调用，输出只是"顾问意见"，不是结论。
用户拍板：主模型给出"结论 + 分歧点 + 推荐"，用户一句话就能推翻。

演化：讨论团还是评审团？

初版文章发布后，我又和豆包推演了一版更工程化的设计——评审团。它保留了"多模型协作 + 用户拍板"的核心，但把"模型互相可见"改成了"模型完全隔离"，并补上了上下文传递规则、token 预算、状态机等细节。

两种模式摆在一起，一度像二选一：

维度	讨论团	评审团
模型间关系	互相可见，串行碰撞	完全隔离，互不可见
讨论形态	模型间你来我往	每轮独立发言 → 汇总 → 用户决定是否再投
收敛方式	主模型收敛	用户拍板 + 收敛检测提示
立场污染	有风险（汇总带倾向）	强制"事实/倾向分离"
成本控制	弹窗授权（开团前）	弹窗授权 + 每轮用户确认

但想深一层：这不是单选题。两者的差异只是"信息流拓扑"——讨论团是全连接（每个人看得见别人的发言），评审团是星型（只有主模型全知，评审模型只见汇总）。中间还夹着"只传上轮事实性汇总"的半开放形态。把可见度做成参数，两种模式就统一成一个多模型协作框架了：ReviewOrchestrator 里一个 mode 字段的事，不是两套代码。

关键设计：信息流拓扑参数化

讨论团 = 全连接，串行。 讨论的本质是碰撞，后发言者要能看到前面的观点，所以讨论链必须串行——并行只会得到三份各说各话的独立答案，没有讨论价值。但"派发链"可以并行：互不依赖的子任务（比如先各查资料）主模型可以并行派发，结果回来后进入串行讨论阶段。干活的阶段并行，对话的阶段串行。

工程上这反而简单：Nyral 的本地引擎本来就是串行工具循环 + SSE 流式输出，讨论就是"主模型循环调 model_delegate，每调一个副模型就输出一条流式发言"，天然不会打架。

评审团 = 星型，并行。 评审模型之间永不互见，零锚定、零传话失真、零立场污染，每个模型永远从自己的盲区出发给意见。作为回报，评审天然适合并行——互不可见就没有串行依赖，一轮延迟 ≈ 最慢的那个模型。评审模型每轮只看到"问题 + 上轮事实性汇总 + 分歧点"，主模型是唯一全知者，持有完整历史。

评审团有个独立的价值：事实与倾向强制分离。主模型也是模型，汇总时必然掺入倾向。若混合呈现，用户（最终决策者）会被悄悄带偏——这是比模型间锚定更严重的污染。所以汇报格式严格分段：“各模型观点"只陈述、禁止任何评价性词汇，“主模型推荐"必须显式标注"这是主持人的倾向，不是事实”，用户有权展开查看任意模型发言原文。

成本控制：三重闸门

多模型协作的代价是 token 翻倍，不能默认放开。两个模式共用三道闸门：

弹窗授权：主模型要开团/开评审或调生图工具时，弹出候选模型让用户选、确认或拒绝。讨论团、评审团、生图、生视频共用同一套"选模型 + 确认"弹窗，候选列表不同而已。
每轮用户确认：评审团的"再投一轮"本身就是闸门——不点就不会产生下一轮成本；讨论团里用户随时可以打断。
模型级开关 + 轮数上限：单模型可单独禁用参与协作，max_rounds 默认 3 轮封顶。

另加 120 秒超时自动拒绝：没人点弹窗就自动拒绝（这个机制本来就存在），后台任务也不会卡死。

成本账也大致算过：3 个评审模型 + 1 个主模型跑一轮约 4800 token（池子快照策略，每轮只传小汇总），全量上下文共享要 3 倍以上，还会让模型观点趋同。把池子做小，是控制成本的核心。

交互：当众流式，随时打断

最初的想法是把协作放在后台，跑完甩个结论。但这样有两个问题：用户干等 N 倍时间；结论怎么来的像个黑盒。

后来想到一个更顺的形态——参考多 Agent 交接的剧场感：Marvis 调用 browser 子 Agent 时，小弟会"冒出来"说"我去看看”，干完再交接回来，用户全程围观，从不觉得在死等。

两种模式同理，都做成可见的流式对话：

用户：这需求怎么做比较好？
─────────────────────────────
[hy4-preview] 我的方案：先建索引再……
[deepseek]    我不同意，索引成本高，应该直接全量扫
[glm]         折中：先扫再按需索引，hy4 的方案更稳
[hy4-preview] 采纳，按我的方案，deepseek 的担忧兜底处理
─────────────────────────────
主持人收敛：结论如下……

每个模型发言是一个气泡（像子 Agent 冒出来），用户能看到谁在说话、观点怎么碰撞、怎么收敛，随时插一句"别争了，用第二个方案"。评审团模式下，各模型观点独立呈现，分歧点列成清单，最后给"执行推荐 / 再投一轮 / 拒绝修改"三个选项。等待感消失，黑盒变透明。

演进路径

第一步：model_delegate 单次委派——主模型"偷懒"让副模型干一件具体的事，成本可控，先解决"互相调用"。
第二步：讨论团——串行可见，先跑通信息流拓扑。它天然串行，实现就是"循环调用 + 上下文拼接"，比评审团便宜。
第三步：评审团——加并行调度 + 事实/倾向分离汇总，建立在前面两步的地基上。

风险清单

延迟：N 模型 × M 轮的串行讨论总时长不短，靠流式可见缓解"等待感"；评审团并行后延迟收敛到单轮。
成本：弹窗授权 + 每轮确认 + 模型级开关/轮数上限三重闸门。
稳定性：多模型输出格式不一致、某个模型挂了讨论卡住，需要重试和降级（超时跳过，全部失败则终止提示）。
路由准确性：模型能力标注靠启发式 + 分组勾选，跨 provider 路由可能指向无权限模型（TokenHub 那类 400/402 的坑），需要对照测试。
观点不收敛：评审团加收敛检测，连续两轮观点一致时提示"继续评审大概率不会产生新信息，建议拍板"——提示只是建议，用户有权无视。

结语

这个设计其实没造新轮子：模型注册表是现有配置的升级，弹窗和超时是现成机制，工具循环是 Nyral 本来就有的大脑，多模型协作只是把"单主模型驱动"扩展成"主模型主持、副模型顾问、用户拍板"。

讨论团适合发散（头脑风暴、创意激发），评审团适合收敛（方案评审、重大决策）——不是二选一，是同一个框架下的两种形态。

它想回答一个朴素的问题：用户都配了那么多模型了，为什么不能让它们一起干活？ 现在至少有了一个不花冤枉 token、又能当众协作的答案。

移动智能体的安卓生存法则：厂商收权时代下个人 Agent 的后台保活、定时岗位与灵动岛实战

Sun, 01 Nov 2026 19:25:00 +0800

摘要

Android 开放生态的核心矛盾是：系统厂商为了续航与安全不断"收权"，而智能体（Agent）类应用天然需要常驻、需要后台执行、需要系统级感知能力。对于没有大厂资源和白名单合作的个人独立开发者，这一矛盾尤为尖锐。

本文以个人开发的安卓移动智能体 Nyral（开源仓库 aixtin/Nyral，包名 io.github.aixtin.nyral）为对象，系统复盘其在国产 ROM（ColorOS / HyperOS / MIUI）环境下存活与进化的完整工程实践，涵盖四个方面：

软地基架构：以"能力与通道解耦"为原则，构建六类半官方通道（无障碍服务、隐形输入法、悬浮窗、本地调试服务、通知/气泡确认壳、前台服务）组成的后台生存底座；
定时岗位机制：基于 AlarmManager.setExactAndAllowWhileIdle 的精确闹钟穿透 Doze 模式，配合续期重排、任务会话绑定、预授权白名单与审计日志，实现"AI 每日自我唤醒静默执行"的无人值守闭环；
灵动岛（Live Updates）接入：通过升级 targetSdk 36、遵循 Android 16 原生 Live Updates API（promoted notifications），让 Agent 任务进度以标准通知通道上屏系统状态栏胶囊，跨厂商自动适配（ColorOS 流体云、HyperOS 超级岛），无需悬浮窗权限与厂商白名单；
真机验证方法论：以"改 cron + UI 停用/启用触发真实闹钟"和"DebugServer 注入 + 通知/db 三方取证"两套方法，在不依赖厂商测试体系的前提下完成端到端可信验证。

本文同时对比了 arXiv:2607.13027（PalmClaw）“API over GUI"的运维路线，指出个人开发者构建移动 Agent 时应优先选择"标准协议穿透 + 自建云侧运维通道"而非"全栈 GUI 自动化"的工程判断。

1 引言与背景

1.1 移动 Agent 的现实困境

智能体（Agent）类应用与普通应用的本质区别在于：它需要"持续存在、随时被唤醒、有能力触达系统其他部分”。而在 Android 生态中，这三者恰好全部处于厂商的限制射程之内：

持续存在：Doze、App Standby、厂商激进回收（ColorOS 的"纯净后台"、MIUI 的"神隐模式"）会杀死后台进程；
随时被唤醒：setExactAndAllowWhileIdle 等精确闹钟被限制频率，厂商还会拦截系统广播（BOOT_COMPLETED、MY_PACKAGE_REPLACED）；
触达系统：无障碍（AccessibilityService）、输入法（IME）、悬浮窗（SYSTEM_ALERT_WINDOW）等"半官方通道"均需用户授权，且厂商可能针对特定应用收窄权限。

对独立开发者而言，问题还要再加三层：没有厂商白名单资格、没有海量设备适配预算、项目由单人维护（本文作者为一人开发、一人运维、零资本投入的非科班开发者，约 8 年软硬件折腾经验，无营业执照与公司主体）。

1.2 Nyral 简介

Nyral 是一个运行在 Android 手机上的个人移动智能体：支持自然语言对话、工具调用（文件、浏览器、终端、应用操作）、知识库沉淀、定时任务（本文称为"定时岗位"）、远程运维（DebugServer + SSH/ADB）等能力。它不依赖云端常驻进程，核心逻辑全部跑在用户的手机上，云侧（VPS）仅作为可选运维通道。

这一形态决定了它必须解决"在手机上活下去"的问题，也使其成为研究个人 Agent 后台生存架构的理想样本。

1.3 论文结构

第 2 节给出威胁模型与通道分层；第 3 节介绍软地基架构；第 4 节详细展开定时岗位机制；第 5 节介绍灵动岛/Live Updates 接入；第 6 节讨论安全与信任边界；第 7 节给出真机验证方法论；第 8 节与既有工作对比；第 9 节总结。

2 威胁模型与通道分层

2.1 厂商收权的层级结构

在长期实践中，我们将移动 Agent 的能力触达按"权限强度"分为五层，越上层越不可剥夺，越下层越接近厂商控制：

层级	通道	可剥夺性	说明
L1 云侧	VPS / 云函数	不可剥夺	数据与大脑在云端，手机端只是执行器
L2 系统运维	SSH / ADB / shell	极难剥夺	需 root 或 adb 授权，是最后兜底
L3 超级权限	root / 解锁 Bootloader	难剥夺	厂商可保修拒保，用户主动选择
L4 半官方通道	无障碍 / IME / 悬浮窗	可收窄	厂商会定向收紧，但有标准协议保护
L5 普通通道	前台服务 / 通知 / 闹钟	可限制	Doze、Standby、厂商省电策略层层加码

关键结论（也是 Nyral 的路线依据）：命脉在厂商，但标准协议不可关。厂商可以收紧应用调用频次，却不能关闭无障碍服务、输入法、通知、闹钟这些 Android 标准框架能力——否则整个系统生态都会崩溃。因此，Agent 的存活策略必须建立在"标准协议 + 半官方通道"的组合上，而不是赌某一家厂商的私有接口。

2.2 能力与通道解耦原则

Nyral 的架构铁律：能力与通道解耦，通道只做一层适配，不赌未来变。

能力（Ability）：读剪贴板、点屏幕、发通知、执行定时任务……这些是 Agent 的核心诉求，与通道无关；
通道（Channel）：无障碍、IME、悬浮窗、通知、闹钟……这些是会随厂商策略变化的"皮肤"。

当某个通道被厂商收紧时，只替换该通道的适配层，能力层完全不动。这一原则在 2026 年 9-10 月的多轮改造中反复验证（见第 3、4 节）。

3 软地基架构：六类半官方通道

Nyral 的"软地基"是一组经过长期踩坑后沉淀的通道清单，它们共同构成了 Agent 在国产 ROM 上"不死、能醒、能触达"的底座：

3.1 通道清单

通道	实现	用途	保活价值
无障碍服务	UiControlService	读取界面、模拟点击、感知前台	系统级常驻通道，用户主动授权，厂商无法单方面关闭
隐形输入法	InvisibleIME（InvisImeService）	后台读剪贴板、无痕输入	IME 进程被系统视为"正在输入"，存活优先级高
悬浮窗	SYSTEM_ALERT_WINDOW	悬浮主页、慢放球、悬浮终端	可见即活，用户感知度高
本地调试服务	DebugServer（端口 8765）	远程注入指令、会话管理、SSE 流式回传	运维通道，配合 adb forward 可达
通知/气泡确认壳	Notification + 气泡	危险操作的确认交互	前台可见的决策入口
前台服务	TaskService / TimerKeepAliveService	定时任务执行、闹钟保活	可见通知的持久服务，降低被杀概率

3.2 InvisibleIME 的实战踩坑（以 ColorOS 为例）

隐形输入法在 OPPO ColorOS 上有一个典型坑：系统会按窗口高度门控隐藏 IME 底栏（chevron/九宫格切换器/手势条），导致用户无法收键盘或切换输入法。

最终方案（2026-10-12 定稿）完全基于公开 API、零反射：

onCreateInputView 中匿名 View 强制测量高度 900px，骗过 OPPO 窗口高度门控，保留底栏布局；
onComputeInsets 把 contentTopInsets 设为全高、touchableRegion 只给 navbar 实际区域，实现"IME source frame 高度为 0，所有 App 零推移；透明区触摸直穿"；
用 OnPreDrawListener 做底栏守护，每帧检查 visibility/alpha 并扳回（OPPO 的 InputMethodServiceExtImpl.updateNavigationBarVisibility 会藏整个 NavigationBarView，不只是两个子按钮，守护目标必须含三个 view）。

这条踩坑的价值在于：厂商私有行为（隐藏底栏）与标准框架行为（IME insets）的解耦——我们不反射、不 hook 厂商内部 API，只改自己的标准 API 调用，因此即使厂商升级策略也大概率不会破坏。

3.3 通道的存活优先级排序

实测经验（三品牌真机：OPPO ColorOS / 红米 HyperOS / 一加 ColorOS）：当系统开始杀后台时，存活优先级大致为：IME ≥ 悬浮窗 > 前台服务（带可见通知）> 无障碍 > 普通后台进程。因此 Nyral 将"隐形输入法 + 悬浮窗"作为最低限度保活组合，前台服务作为任务执行载体，无障碍作为触达工具而非存活依赖。

4 定时岗位：无人值守的自我唤醒闭环

“定时岗位"是 Nyral 的核心功能之一：用户用自然语言让 AI 创建一个定时任务（如"每天早上九点给我推送科技新闻早报”），到点后手机上的 Agent 静默唤醒、执行工具链、把结果写回绑定的会话并发通知。

4.1 四模块实现链路（2026-10-11 MVP）

模块	职责
TimerTaskDb	独立 timer.db 任务表，含 session_id/mode 列（v2 迁移）
TimerScheduler	用 `AlarmManager.setExactAndAllowWhileIdle` 注册精确闹钟
TimerWakeReceiver	到点接收广播，拉起 TaskService
TaskService.runTimerTask	复用 LocalEngine.chat 无 UI 链路执行任务，落库 + 审计

任务创建时自动创建专属会话并绑定，执行结果写回绑定会话；聊天模式与 Agent 模式双模式隔离不串扰。

4.2 穿透 Doze 的关键：setExactAndAllowWhileIdle + 续期重排

setExactAndAllowWhileIdle 是 Android 允许应用在 Doze 模式下精确唤醒的少数 API 之一（单次闹钟，非重复闹钟）。它有一个致命缺陷：单次闹钟触发后不会自动续期。

2026-10-13 真机验证发现两个缺陷并修复：

单次无续期：第一次触发后后续不再唤醒 → 在 onDone/onError 回调中补调用 schedule 续排下一周期；
静默场景危险工具门禁挂起：静默执行时危险工具确认弹窗无人响应，挂起 2 分钟 → 静默模式自动拒绝危险工具。

4.3 完成通知与真实闹钟链路验证

新增 notifyTaskDone()（NOTIF_DONE_ID=1005，channel=task_running，低重要性，点击进 MainActivity，setAutoCancel）。

真机验证（一加 PJX110 ColorOS 16.0.5.701 + 小米 HyperOS 双机）全链路通过：

改 cron 到 21:36 → UI 停用/启用触发 AlarmManager 重排
→ 21:36:00 真实闹钟触发 TimerWakeReceiver
→ TaskService 静默执行
→ 完成续期重排
→ 通知上屏「定时任务完成: WakeAutoTest」

alarm tag 形如 *walarm*:io.github.aixtin.nyral.action.TIMER_WAKE；Logcat 链路 TimerWakeReceiver → TaskService 完整。

4.4 通知组折叠：跨品牌可见性

三个后台服务（DebugService 1002 / TaskService 1001 / TimerKeepAliveService 1003）的通知整合为通知组（key nyral_services，父通知 1004）。

踩坑记录：初版用 getActiveNotifications() 统计活跃子通知数，ColorOS（Android 16）恒返回空数组，导致父通知不发布。改为 ServiceNotifGroup 静态 AtomicInteger 计数（register / onDestroy unregister / publishSummary），三服务 onDestroy 互补。

跨品牌验证结论：OPPO（ColorOS）/ 红米（HyperOS）/ 一加（ColorOS）三台真机状态栏通知组折叠显示均正常。

4.5 停止机制：进程组治理（2026-10-31）

与保活对称的另一面是"能停干净"。停止机制改造（P0–P3 全量落地并真机验证）：

取消域：activeConns 逐连接断流 + 剪枝剩余 tool_calls + 可中断退避；
停止按钮三态：软停 / 硬停 / 结束；
ProcGuard 进程组治理：setsid + procs.json + TERM→KILL + 120s 时限夹紧 + 启动巡检清僵尸；
SSH 三层远端清理：pid 文件 / environ 标记 / pgrep 兜底。

实测停止 2 秒内进程组清零。

5 灵动岛：从通知到系统级状态胶囊

5.1 调研结论（2026-09-21）

针对"手机系统灵动胶囊是厂商适配应用，还是应用适配胶囊"的调研结论：

主流模式是应用适配胶囊：应用按系统 API/SDK 上报持续活动，系统统一渲染胶囊/实况窗；
ColorOS 16 起流体云完整接入原生 Android 16 的 Live Updates API（谷歌实时活动 API），采用 OPPO + 谷歌"双兼容"方案：应用遵循谷歌实时活动 API 规范即可直接适配流体云，无需 OPPO 白名单或单独 SDK；
流体云三种卡片形态：notification_sm（胶囊/气泡）、notification_md（通知大胶囊）、notification_lg（展开面板）；
支持场景类型（entityName）含 TASK——TASK 类型适合 Agent 上报任务执行进度。

对独立开发者而言这是重大利好：不需要厂商商务合作，只靠标准 API 就能上岛。

5.2 SDK 36 升级路径（2026-09-23）

Live Updates API 需要 targetSdk 36+。升级内容：

项	原值	新值
Gradle	8.5	8.13
AGP	8.2.2	8.13.0
compileSdk	34	36
targetSdk	34	36
Kotlin / Java / minSdk	1.9.22 / 17 / 24	不变

关键决策：选 AGP 8.13.0 而非 AGP 9.x（AGP 9 引入内置 Kotlin 变更风险大）；升 36 而非 37（36 已满足 Live Updates + Play 合规，37 生态未稳缓升）。

真机验收：一加 ColorOS 16.0.5.701（V16.0.0）edge-to-edge 强制（targetSdk 35+ 行为）无遮挡问题。

5.3 上屏机制

Live Updates 走标准通知通道（promoted notifications），系统自动将通知转成状态栏胶囊，不需要悬浮窗权限。代码证据：TaskControlReceiver.kt 注释"Live Updates 胶囊交互卡动作接收器"，Manifest 声明 POST_PROMOTED_NOTIFICATIONS 权限。

这意味着 Agent 的任务进度（后台执行/SSH/下载）可以以 TASK 场景实时上报，跨厂商通用：ColorOS 流体云自动识别，HyperOS 3.1+ 的超级岛顺带打通，老设备不强求。

6 安全与信任边界：静默执行的授权模型

定时岗位在"无人值守"和"危险操作"之间存在天然张力。Nyral 的解法是预授权模型（2026-10-13 方案定稿）：

废弃全局静默放权：AI 创建定时任务时，检测任务所需权限，打包为一次性授权（all-or-nothing）；
权限生命周期 = 任务生命周期：任务删除即回收权限；
严格 key 白名单：ToolExecutor 对非法 key 严格报错，LocalEngine ToolSpec 补全 17 项白名单；
弹窗底座泛化：SecurityUi 支持 template/title/body/decision 四要素，壳模板含 task_create/tool_exec/question/confirm/raw；
审计日志：nyral_security_audit.log 记录 approvedBy=channels 等决策来源，真机拉库可证；
静默模式强制拒绝：静默执行场景下危险工具直接拒绝，不挂起等待（修复了挂起 2 分钟的死锁缺陷）。

真机验证闭环（2026-10-15）：id=12 创建→删除验证通过；id=11 早报 09:00 静默执行写文件成功；allow_tools=workdir:write 正确落库。

7 真机验证方法论：无厂商测试体系的端到端可信验证

独立开发者没有厂商测试团队，验证全靠真机自证。两套沉淀方法：

7.1 真实闹钟链路验证（改 cron + UI 停用/启用）

1. adb exec-out run-as 拉 timer.db 到本地
2. 改目标任务 cron_desc 为几分钟后（如"每天 21:36"）
3. adb push 到 /data/local/tmp + chmod 777 + run-as cp 覆盖回 databases/
4. 进定时任务页点任务卡片 → 菜单「停用」→ 再点「启用」，
   enable() 调用 TimerScheduler.schedule 触发 AlarmManager 重排
5. dumpsys alarm 确认 *walarm* TIMER_WAKE 的 origWhen
6. sleep 到点后 logcat 抓 TimerWakeReceiver/TaskService/notifyTaskDone，
   并 cmd statusbar expand-notifications 看通知栏

比 runNow 覆盖更真实的端到端链路（灭屏→闹钟→唤醒→静默执行→通知上屏）。

7.2 DebugServer 注入 + 三方取证

1. monkey 拉起 App 初始化 DebugServer(8765)，
   adb forward tcp:18765 tcp:8765，
   curl POST /v1/chat 带 X-Auth-Token 注入自然语言指令
2. logcat 抓 toolCalls=[(timer_task_create,...)] 确认 AI 调用与参数
3. 截屏/uiautomator 确认确认壳（气泡或通知）渲染清单
4. 用户在手机上点击允许/删除完成决策
5. run-as exec-out cat databases/timer.db 经中转拉回，
   sqlite 读 timer_tasks 确认 allow_tools 等字段真实落库
6. 读 files/nyral_security_audit.log 确认 approvedBy=channels 决策来源

原则：避免只看 AI 回复文本误判成功，保证"调用→确认→落库→审计"全链路真机可见可证。

7.3 覆盖安装不丢配置

迭代开发装机用 adb install -r 覆盖安装 debug 包，装机前备份 shared_prefs，测试后还原，保证用户配置不丢。

8 与既有工作的对比：为什么选"API over GUI"

arXiv:2607.13027（PalmClaw）提出 “API over GUI” 范式——优先通过 API/协议而非 GUI 自动化来完成 Agent 任务。Nyral 的运维路线与之一致，且是在没有阅读该论文的情况下独立得出的工程判断（后查证发现思路撞车）：

维度	PalmClaw（API over GUI）	Nyral 实践
核心主张	API 优先于 GUI 操作	标准协议（通知/闹钟/Live Updates）优先于悬浮窗/无障碍模拟
理由	GUI 脆弱、慢、不可审计	标准协议穿透力强、厂商难关、可审计（通知有系统担保）
落地差异	面向通用 Agent	面向个人开发者的单机 Agent + 云侧运维通道

具体到"上岛"场景：GUI 自动化上不了系统状态栏胶囊，但 Live Updates 标准通知通道可以——这是"标准协议穿透"优于"GUI 模拟"的直观证据。

9 结论与展望

本文完整复盘了个人移动智能体 Nyral 在厂商收权时代下的后台生存架构：

软地基原则：能力与通道解耦、通道只做一层适配、不赌未来变，让 Agent 在六类半官方通道上获得可维护的存活底座；
定时岗位：以 setExactAndAllowWhileIdle + 续期重排穿透 Doze，以预授权白名单 + 审计日志平衡静默与安全，形成"自我唤醒→执行→落库→通知"的无人值守闭环；
灵动岛：依赖 Android 16 原生 Live Updates 标准 API 上屏系统状态栏，避开厂商白名单与悬浮窗权限，跨品牌自动适配；
验证方法论：两套真机自证链路让独立开发者在无厂商测试体系下获得可信的端到端证据。

展望：随着 Android 17（API 37）成熟，Live Updates 生态会进一步开放；Agent 类应用的后台能力将逐步从"对抗厂商回收"转向"标准 API 表达持续活动"。Nyral 的下一步包括：Live Updates 胶囊交互卡深度化（点击动作回传）、端侧本地 AI 推理（OpenCL 路线）、以及知识库自动沉淀的持续迭代。

参考文献

[1] PalmClaw: API over GUI for Generalist Agents. arXiv:2607.13027. [2] Android 16 Developer Preview: Live Updates (Promoted Notifications) API. Google Developer Documentation. [3] OPPO 泛在服务框架（流体云）开发文档. open.oppomobile.com. [4] Android 官方文档: AlarmManager / setExactAndAllowWhileIdle. [5] Nyral 开源仓库: github.com/aixtin/Nyral（本文全部工程实践的代码载体）

附录 A：核心验证数据

日期	事项	结论
2026-09-23	SDK 34→36 升级	构建通过，edge-to-edge 无遮挡
2026-10-11	定时岗位 MVP 四模块	手动立即执行全链路闭环
2026-10-12	InvisibleIME 底栏修复	竖屏/横屏底栏稳定，透明区触摸直穿
2026-10-13	真实闹钟链路 + 完成通知	21:36 触发→静默执行→续期→通知上屏
2026-10-15	预授权三阶段	id=12 创建删除闭环，id=11 静默执行写文件成功
2026-10-11	通知组折叠	OPPO/红米/一加三真机正常
2026-10-31	停止机制 P0–P3	停止 2s 内进程组清零

Nyral 官网页面上线

Sun, 01 Nov 2026 17:10:00 +0800

Nyral 的官网页面上线了：https://atin.asia/nyral/

这个页面把项目的定位、界面截图和下载入口收在了一页：GitHub / Gitee 的 Release APK 按钮会跟随发版自动更新，不用手动维护版本号。

如果还不了解 Nyral 是什么，可以看这篇：Nyral：开源、免 Root、自托管的 Android 智能体助手

源码：GitHub · Gitee
下载：GitHub Release · Gitee Release

Nyral：开源、免 Root、自托管的 Android 智能体助手

Thu, 22 Oct 2026 19:30:00 +0800

把大模型、端侧长期记忆、SSH 远程操作和语音、附件多模态，全部收进一部手机里。

它是谁

Nyral 是一款跑在 Android 上的开源智能体（Agent）助手。它不是那种套个聊天框就完事的"AI 外壳"，而是把多模型对话、本地长期记忆、SSH 远程运维、联网工具、语音输入和附件多模态整合进了一部手机。

四个关键词说清它的立场：开源 · 免 Root · BYO 模型 · 数据自托管。

对话、记忆、Token 统计、SSH 配置默认只存在本机，不注册账号；
没有行为追踪，没有统计 SDK，也没有广告 SDK；
不需要 Root，装上 APK 就能用；
模型由你决定：任意 OpenAI 兼容端点，云端或自建都行；
源码 MIT 许可，托管在 GitHub。

GitHub 仓库：https://github.com/aixtin/nyral

核心能力

对话与模型

多供应商按需切换：MiMo 全模态 / DeepSeek / GLM / 任意 OpenAI 兼容端点，还支持自定义模型，并按模型分别勾选能力；
流式输出：思考段打字机效果 + 正文流式 Markdown 渲染，思考和工具调用的过程都可以折叠；
消息内 Markdown 表格：表格是气泡内独立的块级视图，流式输出时也能实时排版；
思考强度分档：按供应商能力显示"自动 / 开关 / 低中高"，不支持的档位不会出现；
语音输入：长按说话、上滑取消、60 秒上限自动发送，微信式的语音气泡。

附件多模态

图片：本地压缩（长边 2048）后发送，不白烧流量；
视频：超过 37MB 的本地转码压缩，气泡里内嵌首帧缩略图；
文档：PDF / txt / md / docx / xlsx 在本地解析成文本直接注入上下文，不占视觉 token；扫描版 PDF 会自动渲染成页面图片，走视觉通道；
一条消息最多 6 个附件，App 内可全屏预览（图片缩放、视频播放、PDF 翻页、文本复制）。

长期记忆（端侧）

bge-small ONNX 端内语义向量 + 关键词双路召回，存储在 SQLite；
三级分层：短期滚动窗口 → 单槽滚动摘要 → 长期全文 + 语义检索；
可以单独配一个"辅助 AI"做记忆索引，不占用主对话模型；
待处理队列持久化 + 原子消费事务，进程被杀也不丢消息、不重复归档。

工具调用（21 个内置工具，40 轮上限）

联网：web_search（搜狗手机版 → Bing RSS → Bing → 百度四引擎轮转，国内可直连、免 key）/ web_fetch / web_download / site_auth；
SSH：ssh_run 与 file 远程读写、上传下载，支持跳板机、ED25519 密钥和双认证——手机就是随身的运维终端；
执行：js_run（ClassShutter 沙箱限制类访问）/ sh_run（本地 Shell，危险命令拦截 + 提权）；
设备：app，通过无障碍控制第三方 App；
文件：workdir，AI 把文件拉到本地目录改完再推回去，避开 SSH 引号地狱；
浏览器接管：内置 Agent 浏览器原型，AI 全屏接管 WebView，逐步播报 + 高亮提示，遇到验证码会一键交还给你；
定时任务：timer_task_create，先分析目标，再列出需要的危险工具授权清单，一次性批准后准时上班。

安全

危险操作二次确认：确认后执行，同参数 5 分钟内免重复确认，拒绝立刻中止并给出回执，超时自动拒绝，全程留痕；
SSRF 防护（校验重定向目标）+ 日志脱敏（非 2xx 响应体、SSH 私钥内容不会明文落日志）；
沙箱执行、危险命令拦截、SSH 主机密钥校验，未知主机直接拒绝。

界面

多会话管理（置顶 / 删除 / 搜索），会话全文搜索（正文 + 思考，按相关度排序）；
Token 用量统计，主 AI / 辅助 AI 双通道，累计、每日、单会话都能看；
运行日志、前台服务保活通知；
聊天背景（预设渐变 / 自定义图片模糊）、全局动画体系。

谁适合用

开发者：把 SSH 和文件操作装进手机，随时随地连回服务器；
普通用户：想要一个真正自托管、不裸奔的 AI 助手，数据留在自己手里；
开源爱好者：MIT 许可，随便读、随便改。

快速开始

安装 APK，打开「设置 → 模型配置」，填入任意 OpenAI 兼容端点的 Base URL 和 API Key；
（可选）在 SSH 配置里添加远程主机，支持密码或私钥，也支持跳板机；
直接开聊，AI 会按需调用工具，工具调用的进度折叠在气泡里；
长期记忆会自动归档，说一句"记住 xxx"就会立刻归档。

系统要求：Android 10+（minSdk 29）、arm64-v8a，以及至少一个 OpenAI 兼容端点。

自己构建

git clone https://github.com/aixtin/nyral.git
./gradlew assembleDebug
# 产物：app/build/outputs/apk/debug/app-debug.apk

需要 JDK 17、Gradle 8.13、Android SDK 36。仓库内置了阿里云镜像配置，国内构建会快一些；不在国内的话把 settings.gradle.kts 里的 maven(...) 行删掉即可。

一点说明

项目从 2026-10-16 起进入维护模式：只修安全和稳定性问题，不再加新功能。这 54 天是怎么一点点做出来的，写在仓库的 END.md 里。

数据是用户的，代码也是用户的。

AI 专属隐形输入法

Mon, 12 Oct 2026 08:00:00 +0800

Android 只允许 InputMethodService 向输入框写文本。AI 要合法注入字符串，就得拿输入法身份，不需要键盘 UI。

设计

UI：点击输入框只弹一条 1px 横线，不弹软键盘，截屏零遮挡
协议：HTTP + JSON，固定端口 8767
入口：adb forward 访问 HTTP；adb shell am broadcast 走广播
服务名编码协议：com.aixtin.invisime/.Ime_tcp8767_http_json，dumpsys 可见即用

协议

HTTP 主入口：


adb forward tcp:8767 localabstract:httpd

curl -X POST  -d '{"cmd":"type","text":"你好"}'

 

广播快速入口：

 

adb shell am broadcast -a AIX_INPUT_TEXT --es text "你好"

 

指令集：type / backspace / enter / get_text（回读输入框内容）/ select（选区）/ composition（模拟真人打字节奏）。核心动作只有一个：commitText(CharSequence)。

实现

四个组件：

ImeState：状态机，当前输入法开关与注入目标
InvisImeService：InputMethodService，onCreateInputView 返回 1px View
InvisHttpServer：NanoHTTPD 监听 8767，解析 JSON 指令
InjectReceiver：广播接收，解析 intent extra

文本写入统一走 commitText；读回走 InputConnection 的 getTextBeforeCursor / getTextAfterCursor。

历史 bug：初版 executeType 重复 commitText，已修；fixMojibake() 做 ISO-8859-1→UTF-8 回转。

安全边界

只写不点：不点发送按钮、enter 默认换行、不改写已有文本、不静默切换系统输入法。

实测

真机 OPPO ColorOS Android 14（一加 Ace 3 Pro，WireGuard 10.10.10.3:5555）。

坑：ColorOS 输入法导航栏默认不可见，NavigationBarFrame 被设 alpha=0.0；定位后在 onWindowShown postDelayed 300ms 扫 decorView setAlpha(1.0) 恢复。

HTTP 与广播注入中文、英文、删除、回读均验证通过。

定时岗位：让 AI 从「戳一下动一下」变成「自己上班」

Wed, 07 Oct 2026 08:00:00 +0800

本文整理自一次想法碰撞的记录：当对话式 AI 遇上“以天为单位”的任务，缺的到底是什么。

一个被忽略的错位

现在几乎所有对话式 AI 都是响应式的：你发一句话，它动一下；你不说话，它就静静待着。哪怕它能查资料、能写代码、能操作手机，只要你不出手，它永远不会主动做任何事。

但用户真实的需求往往不是“一问一答”，而是一条长时间线：

帮我把这个账号管起来：今天点赞、明天评论、后天发帖
盯着这个价格，降了告诉我
每天睡前把今天的事整理成日记

这些任务的共同点是：跨度以天为单位、触发条件不确定、执行过程需要判断。一次性对话撑不起这种需求。

拆一下：主动唤醒 + 能力边界

「定时岗位」想做的事，本质上是给 AI 一张排班表和一张工牌。工牌上写的是“能做什么”，不是“怎么做”：

维度	具体设计
能力域授权	只锁能力，不锁参数——允许发帖，但发什么它自己定
站点白名单	明确列出允许操作的域名，名单外一律拒绝
每日自主排班	每天自己规划动作，不必等指令
日报审计	干了什么必须留痕，可回溯
随时撤职	一个开关收回授权，岗位立即终止

生命周期也清晰：draft → 用户一键授权 → 独立会话入职沟通 → 退下自主干活 → 可随时进出查看。

最难的一步：怎么防止它越权

让 AI 自主行动，第一个要回答的问题不是“能不能做”，而是“怎么让它做不了不该做的”。目前想到的三道锁：

系统级 Banner：关键操作由系统在通知栏横幅提示。逻辑很朴素——用户只信系统、不信 AI 的话术。AI 说“我没乱动”不可信，系统说“它调用了发帖接口”才是事实。
Native 层注入 Header：把身份标识放在原生层注入的请求头里，脚本层无法伪造，也绕不过去。
能力清单绑定：把授权内容固化成一份清单，运行时逐条比对。曾考虑“参数 hash 过死”，但被否了——参数一变就失效，既不现实也没必要。

这套思路不是凭空来的。多 Agent 架构里早有成熟先例：主 Agent 派活给子 Agent，子 Agent 有独立上下文、明确的能力边界、干完要汇报。「定时岗位」真正新的地方只有两点——主动唤醒和自主排班。

它和联想引擎是同一棵树

把两个想法放在一起看，会发现它们是同一根树干上的两根枝：

联想引擎解决“记忆什么时候被调用”——让调用从被迫变成自觉
定时岗位解决“AI 什么时候开始干活”——让动手从被动变成主动

两者的交汇点是同一个：AI 需要一个属于自己的时间轴。夜间自省可以挂在定时岗位上跑（每天固定时段回顾经历、写入记忆），而岗位的执行记录又成为联想引擎的素材。一个负责“什么时候想”，一个负责“什么时候做”。

结论

「定时岗位」不是要把 AI 变成无所不能的自动机，而是把它从“工具”变成“值班的人”：

有明确的岗位职责
有可审计的动作记录
有随时被撤职的觉悟

这条路还很长，但方向可能比“再训一个更聪明的模型”更实在——很多时候缺的不是能力，是主动性。

联想引擎：给 AI 装上"自主回忆"的能力

Wed, 07 Oct 2026 08:00:00 +0800

你有没有过这种体验：明明记得自己见过某个东西，但怎么也想不起来关键词，搜不出来，只能干着急？

AI 的“记忆”现在就是这个状态。它有一整座图书馆，却只会在你明确提问时才去翻书——你问什么它查什么，绝不多看一眼。

问题不在存储，在“触发方式”

人类回忆是联想式的：闻到一股味道、听到一句歌，某段记忆自动浮上来。这个过程不需要你主动“检索”，它常驻在后台，线索一碰就激活。

而 AI 的记忆是命令式的：被提示才检索，检索完就回到沉默。两者的差距不在数据库大小，而在什么时候开始想。

联想引擎：三个改动

一、事件驱动自主检索。 新信息进入时不等人提问，直接触发一轮关联比对。就像你听到一个新名字，脑子里立刻冒出“这人跟谁有点像”。

二、三级相关性漏斗。 检索结果不再一刀切，而是分三层浮现：

层级	相关度	处理方式	对应人脑体验
L1	高	全文注入上下文	脱口而出
L2	中	只给标题+摘要钩子	“隐约见过”
L3	低	仅留索引，显式检索才命中	深挖才想起

三、夜间自省进程。 每天回顾当天经历，主动写入记忆库并与旧记忆建立关联。这相当于把人类的睡眠巩固机制移植过来——今天不整理，明天检索命中率就是会掉。

相关性评分由四维加权：语义相似、关键词命中、时间衰减、话题实体绑定。

为什么值得做

这个方案比“定时任务”更底层。定时岗位解决的是“AI 能不能自己干活”，联想引擎解决的是“AI 能不能自己想起来”。前者是手脚，后者是海马体。

两者其实是同一棵树：夜间自省进程完全可以由定时岗位承载，而联想引擎为它提供记忆写入的规则。

一句话

别急着给 AI 加更多记忆容量，先让它在没人提问的时候，也愿意想一想。

用 Nyral 打理博客的一天

Mon, 05 Oct 2026 08:00:00 +0800

今天试着让 Nyral 帮我打理博客后台：登录、发文、配标签，一套流程走下来居然比我自己点还快。它不啰嗦，问到点子上就给方案，拿不准的地方会先确认再动手。工具用对了，效率是真的能翻倍。

Root 搞崩手机？一加 Ace 3 Pro KSU-Next 无限重启救砖全记录

Sat, 22 Aug 2026 08:00:00 +0800

Root 一时爽，重启火葬场。本文记录一加 Ace 3 Pro 刷 KSU-Next 导致无限重启的全过程：怎么翻的车、怎么救回来、踩了哪些坑。

翻车经过

设备：一加 Ace 3 Pro (PJX110)，ColorOS 16.0.5.701，内核 6.1.141

已有一个正常工作的 KSU（KernelSU），手痒想试 KSU-Next。

第一步就走歪了

KSU-Next 的 AnyKernel3 内核版本是 6.1.134，而我手机是 6.1.141。差了 7 个小版本。

我心想：内核小版本不都向下兼容吗？

不兼容。直接不兼容。

通过 TWRP sideload 刷入后，手机重启 → 无限重启。

还嫌不够惨

SUSFS 模块 zip 被我当成了 recovery 卡刷包，又推了一次。

现在不只是内核版本不对，模块也炸了。

fastboot 也废了

无限重启状态下，fastboot reboot 命令失效，ADB 通信不稳定。手机反复亮屏、黑屏、亮屏、黑屏，像极了宕机的心电图。

救砖过程

进入 TWRP

TWRP 是最后的救命稻草。

一加的 TWRP 卡顿严重——触屏延迟、滑动漂移、界面偶尔花屏。但关键操作（刷入镜像）还是能完成。

进 TWRP 的过程靠手动操作：关机 → 音量减 + 电源键 → 进入 fastboot → 音量键选择 Recovery Mode → 回车。

核心操作：ADB push + 刷镜像

TWRP 里用 ADB push 把文件传进去：

# 传入字库备份
adb push boot_b.img /sdcard/
adb push init_boot（原版）.img /sdcard/

然后在 TWRP 的 Install → Install Image 里，分别刷入：

boot_b.img（192M，字库备份的 KSU 内核）
init_boot（原版）.img（8M，纯原版，无 KSU 补丁）

注意：boot_b 的字库备份有 192M，不是通常的几十 MB。这是完整的内核镜像。

重启 → 开机了，但没 root

系统正常启动，ColorOS 界面出来了。

但没有 root。

原因很简单：init_boot 刷的是原版，不是 KSU 补丁版。KSU 的用户态在 init_boot 里，原版 = 没有 KSU = 没有 root。

根因：不是内核炸了，是模块炸了

开机后做了一个测试：

# 把 /data/adb 改名（相当于禁用所有模块）
mv /data/adb /data/adb_disabled

# 重启
reboot

重启后一切正常。

这证明：无限重启的元凶不是 boot/内核镜像，而是 /data/adb 目录下的某个 KSU 模块。模块在启动时加载，加载失败 → 循环重启。

你现在需要的：模块排查

知道是模块问题后，排查思路很清晰：

# 1. 进 adb shell（系统正常启动状态下）
adb shell

# 2. /data/adb_disabled 里有所有旧模块
ls /data/adb_disabled/ksu/modules/

# 3. 逐个复制回来，每恢复一个就重启测试
# 找到导致重启的那个模块，删掉它

如果 adb 进不去（又重启了），进 TWRP 挂载 data 分区，直接在文件管理器里操作。

完整救砖清单

步骤	操作	备注
1	进 TWRP	音量减 + 电源 → Recovery
2	解密 data 分区	TWRP 会提示输入锁屏密码
3	ADB push 字库镜像	boot_b.img + init_boot 原版
4	TWRP Install Image	boot_b → boot 分区，init_boot → init_boot 分区
5	重启	如果还循环，重复步骤 1
6	改名 /data/adb	禁用模块，确认能否正常开机
7	恢复 KSU 版 init_boot	重新获取 root

关键教训

1. AnyKernel3 刷的是 boot 分区，不是 init_boot

内核补丁和 KSU 用户态是两个东西。内核在 boot，用户态在 init_boot。搞混了就是"内核有了但 root 没了"或反过来。

2. 内核版本必须匹配

6.1.134 的内核塞进 6.1.141 的系统 = 无限重启。AnyKernel3 不会替你检查版本，它只管刷。

3. 模块是最常见的翻车原因

每次加模块之前，先备份一份 /data/adb。模块冲突导致无限重启的概率远高于内核问题。

4. 字库备份全量做

boot + init_boot 配对备份，两个都要。少了任何一个，救砖时就是"系统能开机但没 root"或"有 root 但开不了机"。

5. TWRP 是最后防线

没有 TWRP，无限重启状态下你只能 fastboot 刷机，选择少、操作难。TWRP 能挂载 data 分区、直接操作文件，救砖效率翻倍。

当前状态

系统：ColorOS 16.0.5.701，正常启动
内核：KSU 版（字库备份）
root：暂未恢复（init_boot 为原版）
待办：清理模块后刷回 KSU 版 init_boot

Root 有风险，刷机需谨慎。但真翻车了别慌——有 TWRP、有字库备份，90% 的情况都能救回来。

一个微信小程序的8个版本，我踩了哪些坑

Sat, 22 Aug 2026 08:00:00 +0800

「确实佷难压缩」是一个微信图片压缩小程序。从 v1.0.1 到 v2.0.1，8 个版本迭代，每次以为稳了都会冒出新问题。这篇文章记录每个版本的核心改动和踩过的坑。

扫码体验小程序：

v1.0.1：能用就行

第一个版本只做了一件事：选图片 → 压缩 → 保存。

核心能力：

Canvas 本地压缩，图片不上传服务器
基础的 JPG/PNG 格式支持

上线第一天就发现：微信会审核图片内容。纯本地压缩不走微信 API，违规图片直接能保存出去。于是加了 imgSecCheck 云函数，压缩后先过一遍微信内容安全审查。

踩坑：审查是异步的，用户看到红色呼吸灯会本能等待，不知道能不能点保存。后来加了"边审边存"提示。

v1.0.4：压缩算法重写

最初的压缩逻辑很粗暴：直接降 quality。结果发现一个问题——选 20KB 压不出来，选 100KB 能压，选 50KB 也能压，再选 20KB 又能压了。不稳定。

原因：单次 quality 调整无法精确控制输出大小。

重写方案：二分搜索 + 两点采样。

先在 quality=0.5 和 quality=0.1 各压一次，得到两个点
线性插值估算目标 quality
最多修正 2 轮，最大 Canvas 调用 4 次

顺便把 UI 改成了深色毛玻璃风格。

v1.0.5：大图压不到目标

5000 万像素的大图，原始数据 150MB。二分搜索在 quality 空间里找，但 quality 再低也就那样——像素数太多了。

修复：大图先等比缩小到 4096px 以内，再走二分搜索。4096 是微信 Canvas 的安全上限，再大就崩。

最低 quality 也从 0.1 降到了 0.05，给极端情况多留余地。

v1.0.6：页面闪白

用户反馈：页面切换时会闪一下白屏。

原因：微信小程序的页面背景默认是白色。深色毛玻璃 UI 在页面切换瞬间，新页面还没渲染完就露出了白色底层。

修复：给所有页面的 JSON 配置补上 navigationBarBackgroundColor 和 backgroundColor，消除视觉断裂。

v1.0.7：进度条 + 自定义裁剪

两个大功能：

压缩进度条：之前压缩时只有一个 loading 动画，用户不知道压到哪了。改成百分比 + 状态文字（“压缩中 60%” → “审查中 90%” → “完成”）。

自定义裁剪尺寸：用户可以手动输入宽高（如 295×413 一寸照）。加了最小值 30px 的限制——输入太小会弹提示。

v1.0.8：Canvas 2D 升级

微信旧版 Canvas API 性能差，大图操作卡顿。升级到 Canvas 2D（type=“2d”），速度提升 2-3 倍。

但升级带来了新坑：

drawImage 必须用 9 参数形式 (img, 0, 0, img.w, img.h, 0, 0, w, h)，不然会截取图片
canvasToTempFilePath 在 Canvas 2D 下不能传 x/y/width/height，只传 destWidth/destHeight
改 canvas 宽高后上下文会重置，必须重新 getContext(‘2d’)

还修了一个 bug：裁剪后输出体积反而变大了。原因是裁剪输出格式没跟随用户选择——选了 PNG 就强制输出 PNG，但 PNG 的 Canvas 重编码体积控制很差。改成跟随格式选择。

v1.0.9：裁剪框大修

这是改动最大的一个版本，问题也最多。

根因：坐标系不一致

裁剪框的四角拖拽在自定义尺寸模式下完全失灵。拖左下角，右下角在动。

真正原因不是判定逻辑，而是坐标系偏移。touch.clientX/Y 是 WebView 坐标，frameX/frameY 是 crop-area 内部坐标。两者差了一个 crop-area 的 left/top 偏移。

修法：在 onReady 用 boundingClientRect 缓存偏移量，触摸时统一减掉。

横图变竖条

16:9 的横构图照片，裁剪框显示成了一个竖条。

原因：之前用高度占满 areaH 来定裁剪框尺寸。横图高度小、宽度大，高度占满意味着宽度溢出被 overflow:hidden 切掉左右，只剩中间一条。

修法：横构图改用宽度上限 areaW*0.96，再反推高度。

其他修复

角判定热区从无下限改为 44-64px（触控标准）
比例锁定：边界钳制时以宽度为基准驱动高度，不再双向独立钳制把比例搞歪
_ready 守卫：图片没加载完就禁止触摸，避免 frame 为 0 误判

踩过的最严重的坑

debug 版在 onTouchStart 里引用了 initImage 作用域的局部变量 imgW。一跑就 ReferenceError: imgW is not defined，所有拖拽全部失效。

教训：console.log 埋点用的变量如果跨作用域，发布前必须删干净。

v2.0.0：对比页全新改版

从"压完就完"变成"压完还能看"。

滑动分割线对比：压缩前后并排，中间一条分割线左右拖动。比之前切换原图/效果图直观得多。竖图横图统一用垂直分割线，不搞两套交互。

一键重新裁剪：对比页不满意？不用返回首页重来。直接点"重新裁剪"，弹出预设/自定义/自由裁剪选项，闭环操作。

裁剪输出优化：裁剪不再降画质（quality 保持 0.92），格式标注文案也修正了——之前显示"PNG"但实际输出 JPG，误导用户。

v2.0.1：自定义尺寸修正

用户反馈：指定 632×532 的裁剪尺寸，输出却是约 1000×900。

原因：自定义尺寸输入后，canvasToTempFilePath 的 destWidth/destHeight 没有严格取用户输入值，而是走了默认的缩放逻辑。

修复：自定义尺寸模式下，输出尺寸严格按用户输入值，不做任何缩放。

版本一览

版本核心改动踩坑

v1.0.1 基础压缩 + 内容审查审查异步导致用户困惑

v1.0.4 二分搜索压缩算法 quality 空间不稳定

v1.0.5 大图先缩小再压缩 5000万像素直接崩

v1.0.6 修复页面闪白页面背景色未配置

v1.0.7 进度条 + 自定义裁剪最小值限制

v1.0.8 Canvas 2D 升级 API 参数差异、格式不跟随

v1.0.9 裁剪框全面重写坐标系偏移、横图比例、跨作用域变量

v2.0.0 对比重塑 + 重新裁剪闭环分割线交互统一

v2.0.1 自定义尺寸精确输出 destWidth/destHeight 缩放逻辑

写在后面

8 个版本，核心功能其实没变——选图、压缩、保存。但每个版本都有"以为修好了其实没有"的时刻。

最有意思的教训是：大部分 bug 不是逻辑错，而是假设错。假设坐标系一致、假设高度占满就行、假设 debug 代码不影响正式版。每一个"假设"都变成了一个线上 bug。

如果你也在做小程序，记住两件事：真机测试不能省，debug 代码发布前必须删。

由ai协助

AI 长期记忆方案：记忆与执行分离，MiMo-V2.5 实测一次整理 2 厘钱

Wed, 19 Aug 2026 08:00:00 +0800

AI 的长期记忆问题不是靠"记住"解决，是靠"架构"解决。本文给出完整方案与实测数据。

一、AI 为什么会"失忆"

AI 的记忆 = 上下文窗口。窗口像滚动纸张，新内容写入，旧内容被挤出。窗口一滚动，之前的指令物理消失。

让 AI"存到外部"的常见做法会翻车：

让 AI 存记忆到外部文件 → 执行两次后开始乱建本地文件
系统提示词写"必须优先查记忆" → 无效
自动压缩历史 → 压缩时对话暂停，体验差

原因：记忆管理靠"自觉"不靠谱，得靠"强制"。

二、方案：记忆与执行分离

给 AI 配一个专职管家，主 AI 干活、管家管记忆，物理隔离。

主 AI（干活）         记忆管家（专职管记忆）
   │                       │
   │  存/取记忆（唯一通道） │
   └──────────→────────────┘
              │
         记忆库（本地磁盘）

核心三条：

管家是独立进程：不参与对话，只碰磁盘。压缩、归档、删除后台跑，主 AI 和用户无感
索引文件是唯一接口：主 AI 查记忆直接读索引文件（Markdown 表格：主题 → 文件名 → 一句话摘要），零改造接入
写入实时、压缩低频：新记忆落盘脚本执行（毫秒级），压缩旧记忆 AI 执行（深夜批量）

三、四个关键细节

1. 索引慢了怎么办

索引是加速器不是唯一入口。索引查不到，退回原文目录 grep 兜底。索引是缓存，原文是真相——缓存挂了功能还在，只是慢一点。

2. 主 AI 偷懒跳过索引

AI 是走捷径大师，索引连续 miss 会直接翻原文。解法：让索引永远比原文好用——实时同步、查索引 2 步 vs 翻原文 5 个文件，AI 会自己算账。

3. 防止写坏文件

用原子替换：先写临时文件，再 rename 覆盖。主 AI 永远读到完整版。

4. 思考过程过滤

推理模型返回 reasoning_content（思维链），接入框架时过滤该字段，只取正式答案。

四、实测：小米 MiMo-V2.5 当管家

选型标准：便宜、上下文长、守规矩、能理解。

维度	实测数据
上下文	1M tokens（105 万）
价格	输入 $0.14/1M，输出 $0.28/1M
摘要一段对话	33.5s，成本 $0.00032（约 2 厘钱）
整理索引	28.8s，关键词准确，不编造
守规矩	严格按格式输出

实测效果：整段对话压缩后自动分为"主题/决策/资产/教训/待办"五段，技术细节保留，寒暄删除。每天跑一百次成本不到 3 毛钱。

五、适用人群

折腾过 AI 本地部署、API 接入的玩家
被 AI 失忆困扰的效率工具党
想给 AI 配外置大脑的开发者

日常聊天用不上这套，大厂 AI 入口已自带记忆。需要 AI 长期维护项目、管理文档、记住偏好时，此架构是标配。

核心一句话：存储靠脚本，压缩靠便宜 AI，决策靠聪明 AI，索引永远当最优解。

推荐试试我做的图片压缩小程序「确实佷难压缩」——微信扫码即用，免费、无广告、压完不糊：

图片压缩原理与实操：一张照片原始 150MB，为什么你看到的是 3MB

Wed, 19 Aug 2026 08:00:00 +0800

图片压缩解决两个问题：文件太大传不出去、上传平台被拒。本文讲清原理，给出微信里直接用的压缩方案。

一、为什么图片这么大

手机摄像头 5000 万像素起步。一张照片的原始信息量：

5000 万像素 = 5000 万个颜色点
每个颜色点需要红、绿、蓝三通道，每通道 8 bit

一张未压缩照片的原始数据约 150MB。平时看到的 3-5MB 照片，都是压缩过的。

二、压缩原理：删掉人眼不敏感的信息

核心逻辑：去掉人眼不敏感的信息。

1. 有损压缩（JPG/JPEG）

人眼对亮度变化敏感，对颜色细微变化不敏感。JPG 大幅简化颜色细节、保留亮度细节，压缩后肉眼几乎看不出差别，文件可小 10 倍以上。压缩率过高会出现马赛克和色块。

2. 无损压缩（PNG）

不丢信息，只合并重复数据。纯色截图 100 万相同像素，PNG 记为"连续 100 万个红色"而非存 100 万遍。适合：截图、文字、图标、透明背景。缺点：照片类复杂图片压缩效果差，文件可能比 JPG 更大。

3. 新一代格式（WebP/HEIC）

同等质量下比 JPG 再小约 30%。微信传输的图片很多已是此类格式，但大部分工具不支持导出。

三、格式选择

场景	推荐格式
照片、风景、人物	JPG / WebP
截图、文字、图标	PNG
需要透明背景	PNG
网页使用	WebP（更小更快）

四、压缩工具对比

方式	优点	缺点
电脑软件（Photoshop、TinyPNG）	功能强	贵、麻烦、要开电脑
在线网站	免安装	上传限制、付费、隐私风险
微信小程序	手机直接处理	无

日常需求（发微信、做文档、传平台），手机上直接解决最方便。

五、推荐：确实佷难压缩

微信小程序「确实佷难压缩」：

微信搜索即用，无需下载 App
支持图片压缩、裁剪、对比预览
压缩前后并排对比
免费

总结

图片大是正常的，一张照片原始数据上百 MB
压缩的本质：删掉人眼不敏感的信息。JPG 压照片、PNG 压截图
日常压缩用手机小程序，微信搜「确实佷难压缩」