抢麦发言防撞车：基于 UUID 租约令牌的多 Agent 无锁并发治理

项目开源地址：GitHub - FerryCat · 对应检查点：FC-301: 独占租约令牌安全防御 与 ADR-0005: 受控守护进程与原子 CAS 租约
前篇专栏回顾：📖 先对齐最新基线：FerryCat 如何杜绝多 Agent 协作中的静默脏读

在一场高效的技术评审会上，最尴尬的场面莫过于技术主管抛出一个线上 Bug 调查需求：“这个模块谁有空查一下？”台下两个同组资深开发同时举手应答。

如果会议缺乏明确的拍板规则，后续发展往往走向两种失控：要么两个人互相不知道对方也在查，各自开工造成一半的人力算力完全浪费；要么更糟——其中一个人刚排查到核心链路，另一个人拿着半吊子推论提前把评审单给结了，直接把错误推论当成最终决议盖棺定论。

在多 Agent 协同编程的世界里，这种“抢麦撞车”每时每刻都在发生。

当你在终端同时启动多个同类 Worker 进程处理后台任务，或者自动化守护进程并发拉起多个工作实例时，它们会在同一毫秒内向协作中枢发起工单轮询。如果协作底座没有严密的并发治理，系统会瞬间陷入任务争抢冲突与隐蔽的越权串单。

在上一篇中，我们通过全文件 SHA-256 指纹与审议分离解决了参会材料被改乱的问题。今天这篇，我们深入底层并发调度中枢，拆解如何通过单语句 SQL CAS 与 UUID 独占租约令牌，让多个并发 Agent 秩序井然地抢麦发言。

一、 桌面并发约束：为什么不能直接套用 Redis 分布式锁？

很多做后端微服务出身的工程师，面对并发竞争的第一直觉就是引入 Redis Redlock、ZooKeeper 或 Etcd 等中心化分布式锁。但在单机桌面和纯本地协同开发场景下，这种思路直接受挫：

1. 基础设施依赖重：要求普通开发者在本地配一套常驻 Redis 服务或启动 Docker 容器，直接推高了安装与使用门槛；
2. 离线不可用：分布式锁往往依赖稳定心跳与中心网络，一旦开发者处于飞行模式或离线内网，整套锁机制当场瘫痪；
3. 锁泄露与僵尸死锁：如果一个 Agent 进程在持有分布式锁期间被宿主 IDE 强制杀死（例如用户突然关闭了终端标签页），死锁时间窗口（TTL）往往长达数秒乃至几十秒，期间整个流水线陷入停滞。

退回到本地单机环境，用粗粒度的操作系统文件锁（flock）又会遭遇我们在专栏第一篇提到过的深坑：Windows 强制锁的 EBUSY 崩溃、锁粒度过粗导致全盘排队串行化。而在 SQLite 中如果图省事使用长耗时 BEGIN IMMEDIATE 互斥事务，又会锁死全库导致所有只读 Agent 出现锁超时。

我们需要的方案必须极其轻量：它运行在无网络依赖的单文件 SQLite 之上，依靠单条 SQL 语句底层的原子性，实现微秒级的无锁乐观抢占（Lock-Free CAS）。

二、 第一道防线：单语句 SQL CAS 原子抢单

在工单轮询接口 poll_next_task 中，最容易写出的并发漏洞莫过于经典的“先查后改”（Check-Then-Act）反面模式：

// 错误示范：致命的竞态窗口！
const task = db.prepare("SELECT * FROM contracts WHERE status = 'SUBMITTED'").get();
if (task) {
  // 两个并发 Worker 在这一瞬间同时查到了同一个 task
  db.prepare("UPDATE contracts SET status = 'CLAIMED' WHERE id = ?").run(task.id);
}

两个 Worker 进程在交错的几微秒内执行了第一句查询，应用层内存中都认为自己拿到了这个任务，随后双双将状态写为 CLAIMED。这便造成了系统级“一女二嫁”的并发事故，两个模型开始在同一个工单上重复计算。

FerryCat 彻底废除了应用层先查后改的设计，直接采用单语句原子 Compare-And-Swap（CAS）原语进行状态抢占：

UPDATE contracts
SET status = 'CLAIMED', claimed_at = ?, claim_token = ?
WHERE id = ? AND status = 'SUBMITTED';

在执行这句 SQL 时，不管底层有 2 个还是 20 个并发进程同时冲进来，SQLite 的写事务串行机制保证了物理上只有一个执行者能真正看到 status = 'SUBMITTED' 并成功将其改写。

系统通过检查执行结果的影响行数（updateResult.changes）作为决定性裁决依据：

const updateResult = claimStmt.run(nowMs, claimToken, candidate.id);
if (Number(updateResult.changes) !== 1) {
  // changes === 0 说明已被其他并发 Worker 拔得头筹，立刻放弃并评估下一候选
  continue;
}
// changes === 1 才是唯一真正的法定胜出者

抢占失败的 Worker 既不需要原地阻塞休眠，也不需要抛出异常，而是优雅地滑向队列中的下一个候选工单。无锁排队不仅杜绝了死锁，还将抢占裁决的耗时压缩到了几十微秒之内。

三、 隐形刺客：同名 Agent 实例越权与串单灾难

解决了抢单冲突，多 Agent 协作系统就能高枕无忧了吗？

在推进 FC-301 契约安全加固时，我们发现了一个更为致命且极为隐蔽的架构死角：同名 Agent 实例的越权冒充。

此前的大多数多智能体框架在权限设计上非常简陋：工单里记录一个 target_agent = 'worker-reviewer'，后续交单时只要请求体里带上 agent_id: 'worker-reviewer'，系统就认为调用合法并准予交单。

但现实环境远比理想推演复杂：

1. 开发者在不同终端标签页里，完全可能启动两个具有相同角色身份的并发执行进程；
2. 或者是某个任务超时退单后，旧的工作进程依然在后台僵尸运行；
3. 或者是自动化脚本并发派生了同类执行上下文。

推演这个恐怖的真实串单场景：

• Worker 实例 A 抢到了工单 #402，开始加载源码进行耗时 90 秒的深度架构推演；
• 此时，同名的 Worker 实例 B 启动，由于逻辑漏洞或误操作，提前向中枢调用了 fulfill_contract 交付接口；
• 系统按照传统的简陋策略检查：工单当前确实处于 CLAIMED 状态，调用者的身份也确实匹配 target_agent == 'worker-reviewer'，于是直接通过了交单！
• 结果是灾难性的：Worker A 辛辛苦苦推演出来的详尽报告直接被 Worker B 的半成品覆盖报废。这种串单事故在日志上甚至不留报错痕迹，属于最难排查的静默数据破坏。

在 AI 工作流编排 的体系里，仅凭一个静态的身份字符串，根本无法区分“谁才是这次认领执行周期的真正主人”。

四、 核心破局：UUID 独占租约令牌（FC-301）与全生命周期守卫

要彻底堵死同名实例越权漏洞，必须为每一次成功的抢单赋予唯一的临时凭证。这就是我们在 FC-301 中确立的核心设计：UUID 独占租约令牌（claim_token）。

1. 独占令牌的内核签发与内存绑定

当 Worker 通过原子 CAS 成功将工单状态改写为 CLAIMED 的瞬间，FerryCat 引擎会在内核直接签发一个密码学强随机的 UUID 字符串，并同步固化至数据行中：

const claimToken = crypto.randomUUID();
const updateResult = claimStmt.run(nowMs, claimToken, candidate.id);

这个唯一的 claimToken 会作为认领凭据，原样返回给当前胜出的 Worker 进程。此时，这个令牌在物理上仅存在于两处：当前胜出进程的私有内存中，以及数据库受保护的数据列里。同名但未经授权的其他并发进程，根本无从得知这个令牌的存在。

2. 全生命周期的持单者凭据守卫（Holder Guard）

拿到令牌只是第一步。系统必须确保工单在后续所有状态跃迁中，全面执行严格的令牌审查。

FerryCat 在引擎层抽离了统一的 持单者凭据守卫（Holder Guard） 门禁，将其强制植入到每一个涉及领单后状态突变的接口中（fulfill_contract、release_contract、extend_ttl、fail_contract、recordSalvage）：

private loadClaimedContractForHolder(
  contractId: string,
  agentId: string,
  operation: 'fulfill' | 'release' | 'extend' | 'fail',
  claimToken?: string
): ContractRow {
  const row = this.db.prepare(`SELECT * FROM contracts WHERE id = ?`).get(contractId);

  // 1. 基础身份与状态校验
  if (row.target_agent !== agentId) {
    throw new Error(`Permission denied: contract assigned to "${row.target_agent}", not "${agentId}".`);
  }
  if (row.status !== 'CLAIMED') {
    throw new Error(`Cannot ${operation} contract: status is '${row.status}'.`);
  }

  // 2. FC-301 独占租约令牌硬性拦截
  if (row.claim_token) {
    if (!claimToken && this.strictLeaseTokens) {
      throw new Error(`Permission denied: contract is protected by an exclusive lease token, but none provided.`);
    }
    if (claimToken && row.claim_token !== claimToken) {
      throw new Error(`Permission denied: invalid lease token provided for ${operation}.`);
    }
  }

  return row;
}

有了这道铁门，即使多个同名 Worker 进程并发运行，没有拿到当前认领周期独占令牌的“冒充者”，在调用任何写操作时都会被系统直接拦截并当场抛出异常。真正的持单者才能从容推进 确定性工作流。

3. 退单令牌自毁与刷新防重放

在 DAG 状态机 的完整闭环中，工单不仅有终态完成，还存在主动退单（release_contract）的可能。

当持单者因环境原因主动把任务退回队列（状态由 CLAIMED 回滚至 SUBMITTED）时，系统会执行严格的清理动作：将数据库中的 claim_token 物理重置为 NULL。

后续如果有新的 Worker 再次认领该工单，系统会重新生成一个全新的 UUID 令牌。这保证了旧持单者即便在网络恢复后再次发起交单，其手持的历史令牌也已彻底作废，从数学上杜绝了令牌重放攻击的可能。

五、 代价与适用边界

没有十全十美的架构设计，引入基于令牌的并发治理同样伴随着必须承担的代价：

1. 客户端调用协议侵入性：执行方在认领任务后，必须自行保存 claim_token，并在后续调用心跳续期（extend_ttl）或交付成果（fulfill_contract）时显式传回。这稍微增加了客户端 SDK 的管理负担，但比起静默串单的数据毁损，这笔防线成本完全值得；
2. 极端并发下的 CAS 争抢空耗：若有数十个 Worker 实例每秒数千次地争抢极少数可用工单，大量抢单失败的实例会产生空转的 SQL UPDATE 尝试。桌面环境一般只有 2~5 个 Agent 进程协同，CAS 成本微乎其微；若迁移至大规模分布式集群，则需要转向上游分片或主动事件通知机制；
3. 令牌的安全边界：claim_token 的核心使命是解决同一宿主内多进程协同的“防撞车、防冒名、防串单”，并不替代操作系统级别的安全沙箱隔离。协作节点之间依旧遵循信任工作区的基本物理假设。

六、 结语：让每一次争鸣都有据可查

在多智能体协作框架的演进中，我们往往容易被大模型的生成效果吸引，而忽视了底层工程调度的基石。

从单语句 SQL CAS 的无死锁秒级胜出，到 UUID 独占租约令牌对同名实例的精准物理隔离，FerryCat 用最纯粹的系统工程法则，在单文件数据库上搭建出了可靠的并发秩序。

下属抢麦发言不再撞车，冒名顶替与串单惨剧被彻底阻绝。

但是，如果一个合法的持单下属在拿到任务后，遇到复杂的逻辑陷入了长耗时推演，甚至在会议室角落里低头苦干到失联（超过了预设的执行 TTL），系统应该怎么办？我们如何做到无感知的自动心跳续期？更重要的是，如果它真的不可避免地超时被熔断了，它已经写出来的阶段性推演代码残片，如何在系统级百分之百打捞回来，彻底消灭 At-most-once 丢产物的隐性 P0 缺陷？

下一篇，我们将直面长任务治理的核心课题：📖 绝不空手而归：基于惰性心跳与残片打捞的多 Agent 长任务治理。

专栏与开源项目
FerryCat（跨宿主 AI 智能体契约编排中枢）：https://github.com/GuoBug/FerryCat
欢迎 Star 关注或提交 Issue 交流。本专栏全部演进过程与实录工单均已在仓库内完全开源。

关于作者
郭强 (GuoBug)，Product Engineer，做平台工程也做业务增长。目前主要在折腾 AI 工作流编排、DAG 状态机与确定性系统架构。
开源项目与主页：https://github.com/GuoBug · https://gu0bug.github.io
欢迎就工作流引擎架构、拓扑调度和低门槛开发体验交流指教。