Liqiang 的个人网站2026-08-10T23:03:58+08:00https://liqiang.devd6cdbb0d-9ba8-41ce-a989-b1fa173dc7102026-08-10T23:03:58+08:002026-08-10T23:03:58+08:00

Based on Pi Agent v0.83.0 source code, this article systematically organizes its main flow and core mechanisms: the layered structure with one-directional dependencies between modules and progressive type extension design; the runLoop assembly process from the process entry point to Agent construction; the conceptual distinction between Trace and Turn; the dual-layer core loop driven by stopReason along with peripheral capabilities such as steering and followUp; the five-step pipeline for tool execution and parallel/serial strategies; the twelve event contracts unifying over thirty LLM providers; and the event feedback mechanism based on the emit synchronization barrier, which ensures that message persistence, UI rendering, and loop state remain synchronized.

6b0388f2-6342-4801-b5e0-457fda18608e2026-07-19T20:12:57+08:002026-07-05T20:12:57+08:00

This article, drawing on official documentation from July 2026 and observable artifacts from the locally installed Codex 0.144.0-alpha.4, surveys the local sandbox implementations of Codex and Claude Code: Codex's OS-level sandbox, Seatbelt/bubblewrap/Windows Sandbox, network_proxy, and cloud containers; Claude Code's permission model, the `/sandbox` Bash sandbox, Seatbelt/bubblewrap/socat/optional seccomp, network proxying, and extension paths such as sandbox-runtime, dev containers, and VMs.

09fbf464-4361-4867-9eeb-6c973c33b6bb2026-07-13T23:43:09+08:002026-07-01T12:27:34+08:00

Mapping mid-2026 AI agent sandboxes by isolation boundary and operation target: from code execution, hardened containers, microVMs, and gVisor, to browsers, desktop GUIs, all-in-one agent runtimes, and network egress governance.

222c48ba-c693-410a-b2b2-e55eb596f1d02026-07-11T18:51:42+08:002026-06-22T23:16:23+08:00

This article provides an in-depth introduction to ETCD's cluster architecture and leader election mechanism. ETCD is a distributed key-value store based on the Raft consensus algorithm, widely used in cloud-native environments such as Kubernetes for storing cluster state. The article focuses on the Raft algorithm's leader election process: cluster nodes are divided into three roles — Leader, Follower, and Candidate. An election is triggered when a Follower times out without receiving a heartbeat, and a candidate node becomes the new Leader by collecting a majority of votes. In addition, the article covers core principles such as log replication, the term mechanism, and consistency guarantees under network partitions, helping readers gain a comprehensive understanding of the implementation foundation of ETCD's high-availability cluster.

f832bb2a-98c9-46a9-ad23-1e764d00cb382026-06-20T18:10:52+08:002026-06-20T18:10:27+08:00

Starting from a transaction anomaly where an ordinary SELECT sees 8 rows but a range UPDATE matches 9 rows, this article explains InnoDB snapshot reads, current reads, Read View, SELECT ... FOR UPDATE, gap locks, next-key locks, intention locks, MDL, and common table-lock semantics under MySQL RR.

50d77ea0-0efe-49f2-bec5-4c60512c90ec2026-05-24T14:36:57+08:002026-05-24T14:36:57+08:00

This article follows a single `INSERT` statement to trace the complete internal path of a write operation in MySQL InnoDB. The Server layer parses SQL, checks permissions, and invokes the storage engine interface. InnoDB locates the target leaf page in the clustered-index B+ tree, writes Undo Log before modification to support rollback, and appends Redo Log after modification to guarantee crash recovery. Random writes to secondary indexes can be delayed and merged through the Change Buffer. During transaction commit, Redo Log and Binlog are coordinated through two-phase commit to ensure consistency between the transaction state and replication. By referencing MySQL 5.7.44 source paths, the article connects scattered concepts into a traceable execution chain.

92c9d753-f7ac-484e-815d-0d8574f190d32026-05-16T14:06:35+08:002026-05-16T13:59:00+08:00

After several months of using AI deeply and involving it in real-world engineering work, I have formed some personal reflections on its role. In this article, I discuss the capability boundaries of AI in large-scale microservice systems, as well as its strengths and limitations. At the same time, I believe AI is not merely a productivity tool, but also a mirror: it exposes the context debt within a system and pushes engineers to rebuild shared knowledge, strengthen their judgment, and spend more energy on architecture, business understanding, and system evolution.

b420972a-8bc2-4af8-b6ef-34a1e2d1a87a2026-04-05T22:27:49+08:002026-04-05T22:16:18+08:00

Recently, I ran into an issue while using AI. I think I had probably seen it before, but I never paid much attention to it. Lately, because I’ve been doing some additional development on Agents myself, I started paying closer attention to how AI executes tasks, and that’s when I noticed the problem: sometimes an Agent gets stuck in a loop, repeatedly trying to complete an impossible task, and it does so tirelessly.