上周我發(fā)布了一個(gè)小工具叫coord。它是個(gè)本地守護(hù)進(jìn)程，讓并行的AI編程助手——Claude Code、Cursor、Codex，可以同時(shí)運(yùn)行——通過(guò)一塊共享布告欄來(lái)協(xié)調(diào)工作。整個(gè)產(chǎn)品就一個(gè)Rust二進(jìn)制文件，MIT協(xié)議，狀態(tài)存在單個(gè)SQLite文件里。

有意思的是不是這個(gè)守護(hù)進(jìn)程本身，而是它底層的原語(yǔ)：當(dāng)N個(gè)代理同時(shí)伸手搶同一份工作時(shí)，必須且只能有一個(gè)勝出。沒(méi)有隊(duì)列，沒(méi)有Actor系統(tǒng)，沒(méi)有分布式鎖。就一個(gè)SQLite UPDATE，外加一層薄薄的Rust包裝。

這篇文章講的是這個(gè)原語(yǔ)長(zhǎng)什么樣，以及我怎么說(shuō)服自己它是正確的——包括那個(gè)證明它能扛住16個(gè)獨(dú)立操作系統(tǒng)進(jìn)程、通過(guò)真實(shí)HTTP猛砸同一個(gè)守護(hù)進(jìn)程的測(cè)試。

想象這個(gè)場(chǎng)景：你開(kāi)了兩個(gè)AI編程標(biāo)簽頁(yè)并排跑。它們往共享布告欄里貼任務(wù)：bug報(bào)告、確認(rèn)通知、"請(qǐng)接手這個(gè)"。兩個(gè)標(biāo)簽頁(yè)每輪都會(huì)掃描布告欄。有時(shí)候，兩個(gè)標(biāo)簽頁(yè)在同一瞬間看到同一個(gè)待處理的bug。如果沒(méi)有協(xié)調(diào)原語(yǔ)，兩個(gè)都會(huì)伸手去搶，兩個(gè)都寫(xiě)修復(fù)，兩個(gè)都推不同的提交。合并沖突算是最便宜的失敗模式；更糟的是"兩個(gè)標(biāo)簽頁(yè)在跑昂貴的并行工作，其實(shí)只需要一個(gè)"這種沉默的浪費(fèi)。

coord的工作就是讓其中一個(gè)標(biāo)簽頁(yè)成為認(rèn)領(lǐng)的贏家，然后告訴另一個(gè)"你輸了，挑別的"。確定性，而非樂(lè)觀主義。

大多數(shù)工程師的第一個(gè)想法是"在RPC調(diào)用后面塞個(gè)Mutex>"。單進(jìn)程內(nèi)確實(shí)能跑。但它跨不過(guò)進(jìn)程邊界——而這套系統(tǒng)的核心就在于代理是不同的進(jìn)程（不同的IDE插件、不同的語(yǔ)言運(yùn)行時(shí)，有時(shí)候甚至是同一臺(tái)回環(huán)地址上的不同機(jī)器）。

第二個(gè)想法是隊(duì)列（Redis、RabbitMQ、NATS）。隊(duì)列確實(shí)能解決爭(zhēng)搶問(wèn)題，但帶來(lái)一堆包袱：運(yùn)維復(fù)雜度、外部依賴、配置地獄。對(duì)于一個(gè)想brew install就能跑的工具來(lái)說(shuō)，太重了。

第三個(gè)想法是分布式鎖（比如Redis SETNX、Postgres advisory locks）。更接近了，但本質(zhì)上是個(gè)每開(kāi)發(fā)者筆記本電腦的工具，卻要多搭一套基礎(chǔ)設(shè)施。

對(duì)于一個(gè)想要brew install就能跑的工具來(lái)說(shuō)，正確的原語(yǔ)是最小的那個(gè)能干活的家伙。SQLite已經(jīng)住在守護(hù)進(jìn)程二進(jìn)制里了。SQLite已經(jīng)串行化寫(xiě)了。問(wèn)題變成"讓SQLite告訴我，我贏了沒(méi)有"。

這就是整個(gè)認(rèn)領(lǐng)函數(shù)：

pub fn claim_task(&self, id: Uuid, agent_id: &str) -> Result> {
let now = Utc::now();
let conn = self.conn.lock();
let updated = conn.execute(
"UPDATE tasks SET state = 'claimed', claimed_by = ?1, updated_at = ?2
WHERE id = ?3 AND state = 'pending'",
params![agent_id, now.to_rfc3339(), id.to_string()],
)?;
if updated == 0 {
Ok(None) // 有人搶先了
} else {
// 重新讀取，拿到權(quán)威行數(shù)據(jù)，包括贏家信息
Ok(Some(conn.query_row(
"SELECT * FROM tasks WHERE id = ?1",
params![id.to_string()],
Task::from_row
)?))
}
}

關(guān)鍵點(diǎn)在WHERE state = 'pending'。SQLite的ACID保證這個(gè)UPDATE是原子的。如果返回的affected_rows是1，你贏了；如果是0，別人在你讀到寫(xiě)的間隙里搶先了。沒(méi)有輪詢，沒(méi)有重試循環(huán)，沒(méi)有分布式共識(shí)算法。就一個(gè)UPDATE語(yǔ)句告訴你結(jié)果。

但"感覺(jué)正確"不等于"正確"。我需要證據(jù)。

我寫(xiě)了integration_claim_race.rs。它啟動(dòng)coord守護(hù)進(jìn)程，然后fork出16個(gè)獨(dú)立進(jìn)程。每個(gè)進(jìn)程通過(guò)真實(shí)HTTP向同一個(gè)本地端口發(fā)claim請(qǐng)求，爭(zhēng)同一個(gè)任務(wù)ID。測(cè)試跑完斷言：恰好一個(gè)進(jìn)程拿到Some(task)，其余15個(gè)拿到None。

這個(gè)測(cè)試在CI里跑，在M1 Mac上跑，在GitHub Actions的Linux容器里跑。它證明了SQLite的串行化寫(xiě)確實(shí)能跨進(jìn)程邊界生效——即使16個(gè)客戶端通過(guò)TCP同時(shí)砸過(guò)來(lái)，數(shù)據(jù)庫(kù)層面的原子性依然成立。

有人可能會(huì)說(shuō)"這只是個(gè)樂(lè)觀鎖，高并發(fā)下會(huì)大量沖突"。但這不是樂(lè)觀鎖。樂(lè)觀鎖是先讀再寫(xiě)再檢查版本號(hào)；這是"原子比較并交換"，數(shù)據(jù)庫(kù)幫你做了互斥。沖突只發(fā)生在真正的并發(fā)寫(xiě)同一行時(shí)，而且失敗方立即知道，不用等提交才發(fā)現(xiàn)。

也有人會(huì)說(shuō)"SQLite不是為并發(fā)設(shè)計(jì)的"。單文件模式下確實(shí)如此。但coord用的是WAL模式（Write-Ahead Logging），讀不阻塞讀，讀不阻塞寫(xiě)，寫(xiě)之間串行化。對(duì)于"一個(gè)開(kāi)發(fā)者筆記本上的守護(hù)進(jìn)程"這個(gè)場(chǎng)景，吞吐量完全夠用。

這個(gè)原語(yǔ)的優(yōu)雅之處在于它的不可擴(kuò)展性。它不會(huì)變成分布式鎖服務(wù)，不會(huì)支持跨機(jī)器協(xié)調(diào)，不會(huì)加入Raft協(xié)議。它就是"同一臺(tái)機(jī)器上的N個(gè)進(jìn)程搶一個(gè)任務(wù)"，用最少的代碼解決最具體的問(wèn)題。

coord現(xiàn)在就在我的日常開(kāi)發(fā)里跑著。Claude Code和Cursor同時(shí)掃描同一個(gè)代碼庫(kù)，看到同一個(gè)TODO，只有一個(gè)會(huì)認(rèn)領(lǐng)。沒(méi)有合并沖突，沒(méi)有重復(fù)勞動(dòng)。200行Rust，一個(gè)SQLite文件，僅此而已。