Hermes Agent 是 NousResearch 开源的个人 Agent 运行时（MIT，提交 8f5693a）。如果只把它看成”提示词套壳”会看错重点：它更像一台回合制状态机——一次用户输入就是一个 turn，turn 内部是”模型调用 → 工具执行 → 再调用”的内循环，外层受预算、闸门与压缩约束。整个仓库约两万文件，其中 agent/ 目录 319 个 Python 文件、约 6.5 MB，这些复杂度几乎都在回答同一组问题：这次请求该发什么、发出去之后坏了怎么办、历史该怎么变短。 三条主线贯穿全部代码。第一，回合是唯一执行单元，任何层都不允许越权改写历史；第二，上下文是最稀缺的资源，系统提示词在会话期间按字节冻结，压缩是唯一被允许的改写，token 记账优先信 provider 返回的真实用量；第三，能力长在边缘、核心保持收窄，新能力默认走 skill、plugin、MCP，而不是往核心工具里加，学习靠”回合后 fork 一份自己复盘”。 所以它的架构定位可以概括成一句话：Prompt-cache-first 的同步 ReAct...

拆到最小，Codex 就是一个本地编码 Agent：用户输入、AGENTS.md、环境信息与工具定义被组装成 Prompt，经 Responses API 流式采样；模型返回的工具调用在审批策略与操作系统沙箱约束下执行，结果回填历史再采样，直到模型不再需要工具。 循环本身并不神秘，难的是周围的工程。官方协议用 Model、Codex、Session、Task、Turn 五个实体描述运行模型：Session 同一时刻只允许一个 Task，Task 由多个 Turn 组成，Turn 之间严格因果——上一轮输出就是下一轮输入。 决定体验的是循环之外的取舍：引擎与 UI 通过一对队列（Submission Queue / Event Queue）解耦，一份 core 支撑 TUI、IDE 插件、桌面 App 与 MCP Server；Prompt 只追加不改写以命中前缀缓存；改动以补丁表达；安全上则用审批与沙箱两个正交维度，再叠加 execpolicy 与网络代理。 一个 while 循环：输出即下一轮输入core/src/session/turn.rs 里的...

Claude Code 不是一个更聪明的模型，而是一层包在模型外面的 agentic harness。官方文档对它的定义只有一句话：agentic loop 由两个部件驱动——负责推理的模型，和负责行动的工具；Claude Code 就是围绕模型提供工具、并管理模型能看到什么的那一层。把这句话拆开，也就把整个系统拆开了。 模型这一侧只有 Messages API：一次无状态的 HTTP 调用，输入 system、工具定义和完整对话历史，输出 text / thinking / tool_use 内容块。它不能读文件，也不能跑命令。所谓“调用工具”，实际动作是模型写出一段结构化 JSON、把 stop_reason 置为 tool_use，然后停下等待。真正让这件事发生的是 harness：它做权限检查、执行工具、把结果以 tool_result 回填，再把完整上下文重新发过去。 分工带来的后果很直接：能力上限由工具集合决定，可靠性下限由权限、沙箱与检查点决定，而成本与效果落在上下文工程上。Claude Code...

Android Performance Studio 是一个开源、跨平台的 Android 性能分析工作台：从 Layout Inspector 到 Perfetto，从 HPROF 到 batterystats，采集、查看、关联、定位在一个窗口里完成。本地优先。 一、性能问题最难的地方，不是修，是找“首页滑动有点卡”“启动要两秒多”“内存又涨了 200MB”。 这三句话，背后往往是三套完全不同的工具链。 滑动卡顿，你要打开 Android Studio Profiler 抓 CPU，或者用 Perfetto 抓系统 trace，盯着 RenderThread 和 SurfaceFlinger 看；内存涨了，你要导 HPROF，翻类直方图、支配树和引用链；启动慢，你要跑 Macrobenchmark，看 TTID、TTFD 和 Baseline Profile；耗电异常，你要导 batterystats，再去 Battery Historian 里对 Wakelock 和 Alarm；再加上 simpleperf 看 Native 热点、AGI 看 GPU、OkHttp...

Android ANR（Application Not Responding）分析看起来像是在“读日志”，但真正困难的地方并不只是日志太多，而是证据太散、时间线不一致、系统上下文复杂，并且很容易因为某一段醒目的堆栈或日志而过早定责。 llm-anr 这个仓库要解决的正是这个问题：把 trace、EventLog、logcat、AnrManager dump、meminfo、kernel log 等多源原始材料，转换成按 ANR 事件隔离、可审计、可复盘的证据工作区，再引导 AI 或人工分析者逐层完成保守分析。 这篇文章从三个角度介绍这个项目：它为什么这样设计、开发流程如何组织，以及当前最终交付出了什么能力。 项目地址：yuchuangu85/llm-anr: Agent-driven Android ANR evidence extraction and AI-assisted root cause analysis pipeline. 一、项目要解决的问题在实际 Android 稳定性分析中，ANR bugreport...

上一章介绍了为什么要引入dagger，这节我们再贴一张Launcher3 引入dagger后的流程图，以及生成对象图。能够更清晰帮助我们理解Dagger的流程和作用。

从Android 16的qpr2版本开始Launcher3全面引入了Dagger，为什么要引入Dagger，我们看一下引入Dagger的架构对比。 引入前： 引入后： 再来一张放一起的图，更清晰： Dagger2 的引入核心目标是： 减少传统静态单例依赖 旧版 Launcher 大量使用 LauncherAppState.getInstance()、SomeSingleton.INSTANCE 等静态单例，这导致： 生命周期难以控制 测试难以替换依赖 进程或 Activity 生命周期边界不清 通过 引入Dagger2，将对象的创建与依赖关系交由 编译期生成的 Component/Module 管理。 明确依赖边界和作用域 Dagger2 的 Scope 注解用于划分对象生命周期： @LauncherAppSingleton：App 级单例，与进程生命周期绑定 @ActivityContextSingleton：ActivityContext 级单例，与 Activity 生命周期绑定 通过...

Launcher3项目是一个非常大、非常复杂的项目，虽然从界面看Launcher的界面很少，也不复杂，但是涉及的UI，动画，手势等非常多，与SystemUI，窗口都深度绑定，如果没有看过Launcher3源码还是比较难理解的。 Launcher3从整体的架构来看是分为两部分：一部分是基础部分，就是不与SystemUI和窗口绑定的，一部分（Quickstep）是与SystemUI和窗口绑定的。 基础部分一般是给开发三方桌面使用的，可以在任何Android手机安装，Quickstep部分是给手机厂商用的，依赖SystemUI和窗口。 先从架构开始，逐步分析整个Launcher3项目。 这篇先看看基础部分的架构： 由于内容比较多，这里也只是显示了部分内容，还有很多的内容没有呈现，比如一些动画，拖拽，手势等，后续逐步放出。 这个图先让我们对基础部分的架构有个了解，以帮助我们更好的学习整个Launcher3项目。

基于Google AOSP源码中的Launcher3源码进行分析：

​ 前几天Karpathy分享了他最新的工作流：使用 LLM 构建个人知识库（Personal Knowledge Base），这条推文一发布，引发大量关注和点赞，两天后，他把这套方法论写成了一份 gist 发到 GitHub（llm-wiki） 上，开源给所有人。 ​ 我最近也看到很多介绍这个构建知识库的帖子，但是很少有如何实战构建自己的知识库的操作步骤，所以开始也是很迷茫，到底该如何构建自己的知识库，正好今天没事找到一篇介绍如何使用的，我本地也实战了一下，记录一下操作步骤。 ​ 知识收集、整理是非常耗费时间的，我做开发十多年也整理了很多知识，放到github，博客，公众号，但是没有一个非常好的的管理方式，正好这个方法能够解决我的问题，可能也会解决很多人管理知识的问题。 ​ 下面我介绍下我的操作步骤。 准备工具 Obsidian – https://obsidian.md/ ：下载安装，这个是一个读取显示md文件的软件，具有很强大的功能，由于我也是刚开接触，因此很多还不熟悉，因此还在摸索阶段。 obsidian web clipper –...