Posts

Google ADK 架构解析：如何用软件工程思维构建 AI Agent 系统 Agent Development Kit（ADK）是 Google 在 2025 年开源的一个 AI Agent 开发框架，目前在 GitHub 上有超过 18000 个 star，支持 Python、TypeScript、Go 和 Java 四种语言的实现。ADK 的设计目标很明确：让 Agent 开发回归软件工程的范式，而不是停留在 prompt engineering 的阶段。这意味着它需要提供清晰的抽象层级、可组合的模块、确定性的执行流程、以及工业级的状态管理能力。 当前 AI Agent 领域的框架呈现出一种两极分化的态势：一端是 LangChain 这样高度灵活但过于松散的链式调用框架，另一端是各家云厂商封闭的托管服务。ADK 试图在这两者之间找到一个平衡点——既保持代码优先（code-first）的灵活性，又提供足够的结构化约束来支撑复杂的多 Agent 系统。这个定位是否站得住脚，需要从架构层面逐一拆解。 在进入细节之前，先从宏观上理解 ADK 的整体分层结构： ┌─────────────────────────────────────────────────────────────────┐ │ Application Layer │ │ adk web / adk run / adk api_server │ ├─────────────────────────────────────────────────────────────────┤ │ Runner (Event Loop) │ │ yield/pause/resume cycle ── Event processing │ ├───────────────┬───────────────┬─────────────────────────────────┤ │ Agent Layer │ Tool Layer │ Flow Layer │ │ BaseAgent │ BaseTool │ BaseLlmFlow │ │ ├ LlmAgent │ ├ FunctionTool│ ├ SingleFlow │ │ ├ Sequential │ ├ AgentTool │ └ AutoFlow │ │ ├ Parallel │ ├ MCPTool │ (LLM request/response │ │ ├ Loop │ └ ... │ + tool execution loop) │ │ └ Custom │ │ │ ├───────────────┴───────────────┴─────────────────────────────────┤ │ Model Abstraction │ │ BaseLlm ── LLMRegistry ── Gemini / OpenAI / ... │ ├─────────────────────────────────────────────────────────────────┤ │ Services Layer │ │ SessionService │ ArtifactService │ MemoryService │ │ (state + history) (binary blobs) (cross-session search) │ ├─────────────────────────────────────────────────────────────────┤ │ Infrastructure │ │ InMemory / Database / GCS / Vertex AI Agent Engine │ └─────────────────────────────────────────────────────────────────┘ 自底向上，Infrastructure 层提供可插拔的存储后端；Services 层管理状态、产物和记忆的持久化；Model 层抽象了不同 LLM 供应商的差异；Agent/Tool/Flow 三层构成了核心的执行逻辑；Runner 层驱动整个事件循环；Application 层则提供了面向开发者和终端用户的接口。 ...

Redis 持久化机制: RDB 和 AOF Redis 持久化 为什么需要持久化? Redis 是基于内存的数据库, 服务一旦宕机, 内存中的数据将全部丢失. 通常来说可以通过数据库来恢复这些数据, 但这会给数据库带来非常大的读压力, 并且这个过程会非常缓慢, 并导致程序响应慢, 因此 Redis 提供了把内存数据持久化到硬盘, 并通过备份文件来恢复数据的功能, 即持久化机制. 持久化的方式 目前 Redis Documentation 上对持久化的支持有以下几种方案: RDB (Redis Database): 将某个时间点上的数据生成快照 (snapshot) 并保存到硬盘上 AOF (Append Only File): 将每个接收到的写操作记录到硬盘上, 这些操作可以在 Redis 重启时被重放, 并用于重新构建 Redis 数据库 RDB + AOF: AOF 和 RDB 的混合模式 RDB RDB 指对整个数据集在特定时间点生成快照 (point-to-time snapshot), 可用于Redis的数据备份, 转移和恢复. 它是 Redis 默认使用的持久化方案. 工作原理 RDB 利用操作系统提供的写时复制 (Copy-on-Write) 机制来进行持久化, 即当主进程 P fork 出子进程时 Q 时, Q 和 P 共享同一块内存空间, 当 P 准备对某块内存进行写操作时, P 会将这块内存页进行复制, 并在新的副本上对数据进行修改, 而 Q 仍然读取原先的内存页. 这样既能够保证 Redis 实例继续服务外部流量, 又能够以最小的成本完成数据的持久化. 但正因如此, 持久化过程中的写操作是不会被记录的. ...

Disaster Recovery Architecture on AWS [TOC] The downtime of software systems could have a significant impact on business, customer satisfaction, reputation, or income of the company. Thus maintaining the availability and durability must be the most crucial part of a software system. Disaster recovery (DR) helps engineers prepare for disaster events. This post summaries the architecture for DR on AWS. DR objectives There are two key objectives: Recovery time objective (RTO): The maximum time range between service collapse and service restoration. It represents how quickly the service could be restarted. ...

Git Reference HEAD 用法 HEAD 最后一次 commit HEAD^ 倒数第二次 commit HEAD^^ 倒数第三次 commit，以此类推 HEAD~0 最后一次 commit HEAD~1 倒数第二次 commit HEAD^2 倒数第三次 commit，以此类推 回到以前的某次 commit git reflog # Reference logs 记录了本地仓库每一次更新分支的操作 git reset HEAD@{index} # 回到某一次提交，把文件修改留在工作区 git reset hash --hard # 加上 --hard 可以忽略掉所有文件修改 在最后一次 commit 的基础上添加部分改动 git add . # 把改动添加到暂存区 git commit --amend # git commit --amend --no-edit # 加上 --no-edit 如果最后一次 commit 已经 push 到 remote，那么在再次 push 的时候需要加上 -f 在以前的某次 commit 的基础上添加部分改动 git log # 找到要修改的 commit 的前一次 git rebase -i hash # 将 HEAD 移到需要修改的 commit 上 (vim) R edit # 将首行的 pick 改成 edit，保存退出 # 修改文件 git add . git commit --amend # 追加改动到这次 commit 上 git rebase --continue # 恢复 HEAD 把未 commit 的修改移动到其他分支上 git reset HEAD~ --soft # 撤销最后一次 commit 操作，但是保留文件修改 git stash git checkout another-branch git stash pop git add . git commit -m "your message here" 把某一次 commit 添加到其他分支上 git log # 找到需要移动的 commit 的 hash git checkout another-branch git cherry-pick hash # 把对应的 commit 应用到当前的 branch 撤销某次 commit git log # 找到需要撤销的 commit 的 hash git revert hash # 撤销对应的改动并直接 commit 撤销某次 commit 的某个文件 git log # 找到需要撤销的 commit 的 hash git checkout hash -- path/to/file # 把修改之前的文件添加到工作区 git commit -m "your message here" 放弃治疗 git fetch origin git checkout master git reset --hard origin/master git clean -d --force # 删除工作区所有 untracked 的文件和目录 或者 ...

使用 Mac Mini M1 作为软路由让全家设备出国 [TOC] 本文介绍如何将功耗超低的 Mac Mini M1 改造为软路由，让局域网内连上 Wi-Fi 的所有家庭设备都可以免设置直接出国。 代理客户端 首先需要下载一个可以运行在 M1 上的代理客户端，推荐使用 Surge 或者 ClashX Pro，前者买断价格较贵（每个 Mac 设备 $49.99），后者免费，本文以后者为例。 配置 一般机场会提供 Clash 的订阅链接，如果没有可以自行搜索 ssr/v2ray 转 clash 的第三方订阅转换服务，生成 Clash 订阅链接。 有了订阅链接之后，点击顶部菜单栏的 Clash 图标 -> Config -> Remote config -> Manage 管理订阅。 点击 Add，在 Url 中输入订阅链接，Config Name 可以任意填。 除此之外还要勾选 Clash 图标里的 Set as system proxy 和 Enhanced Mode 两个选项，这样才能保证 Mac Mini M1 能够成为网关。 ...