为了方便解释 Android Binder 框架运行逻辑，将整个 binder 单独抽出来，使其可以独立编译、分析和运行。 一、为什么 Android 选了 Binder Linux 上做跨进程通信有不少现成方案：管道、Unix domain socket、共享内存、System V IPC。Android 选择 Binder，主要原因有两个。 安全性。传统 Unix IPC 不要求调用方自证身份

大模型发布会的话术这两年已经固定下来：总参数数万亿，MoE 架构加持，推理成本却比同级别模型低一大截。面试里也常出现同一道题，让人说清 Transformer 和 MoE 的区别，不少答案会把两者摆成并列的两种架构互相比较。 它们处在不同层级。Transformer 定义了「注意力 + 前馈」的主干结构，MoE 是在这条主干上针对前馈层做的一次去密集化改造，把单个庞大的前馈网络换成路由器加一组并行

一、问题：摘要没错，执行却跑偏 1.1 现象：上下文摘要准确无误，Agent 却越执行越偏 面试里经常会问一个看似矛盾的问题：上下文摘要明明没有丢事实，Agent 为什么越执行越偏？ 用一个数据任务举例：从订单表查出本月已支付订单并生成汇总报表。原始上下文里还有几条执行要求：分页查询，每页 1000 条；逐批处理，直到没有下一页；只能访问只读副本库；SQL 超时 30 秒；失败重试不超过三次。 经

一、插件框架要回答的三个问题 一个插件框架绕不开三点： 引擎怎么知道有哪些插件 引擎怎么用统一方式驱动它们 插件之间怎么传数据 pyplugin-framework 给出的方案是： 第一个问题交给元类：插件类定义完成的瞬间，元类会把这个类写进一张全局注册表，引擎侧不需要维护任何登记代码。 第二个问题交给 PluginCore：所有插件都从它派生，引擎统一调用它们的 invoke 方法。 第三个问题

在 Android 架构设计里，"main-safe" 经常被提到，但大多数人只把它理解成一句简单的话："Repository 要切线程，UI 层不用关心 IO。" 如果只停留在这个理解，其实还远远没抓住它的本质。 main-safe 并不仅仅是线程规范，它的本质是一种架构契约——Data 层对调用方的承诺，也正因如此，它成了衡量架构是否真正分层的一道分水岭。 一、什么是 main-safe？ m

我第一次接触 LiveData 的时候，觉得它非常惊艳。在那个时代，Android 开发充满了 Callback、生命周期问题、内存泄漏风险。LiveData 让 Android 开发第一次拥有了一个和生命周期结合的数据观察方案。那时候我觉得：LiveData 真的好棒，简单好用。 但是几年之后，我越来越少使用 LiveData。现在的新项目里，我基本不会主动选择 LiveData，而更多使用 K

一、项目概述 AgentPlanFlow 是一个面向多智能体协作编程的桌面工作台。它把 Codex（OpenAI）、Claude Code（Anthropic）和 Hermes（Nous Research）组织在同一个原生桌面窗口里，让不同智能体可以围绕同一工作目录运行、协作、委托任务，并共享执行上下文。 它并不是简单地把几个终端拼在一起。AgentPlanFlow 在桌面侧负责窗口、终端、进程和

draw-io-illustrator Codex插件可以通过 draw.io 的图形 API ，将流程图片里的元素逐对象绘制复刻到draw io工程。 一、Codex 插件的最小结构 Codex 插件本质上是一个目录，包含： 声明文件 plugin.json 技能目录 skills/ .mcp.json 和对应的服务端脚本（非必须） plugin.json 是 Codex 识别插件的唯一入口。d