索未 · SEO ｜ 规范与标准流程

· · ·

从 Resource Ownership、Lease、Fencing Token 到 Authority Graph，建立真正可控的 Multi-Agent Production System

上一篇，我们解决了 Desired State、Actual State、Drift Detection 与 Reconciliation：

Desired State ↓ Actual State ↓ Semantic Diff ↓ Drift Detection ↓ Reconciliation

也就是说，系统不再是：

部署成功 ↓ 任务结束

而是持续确认：

但只要 Reconciliation 真正开始持续运行，另一个问题很快就会出现。

假设同一时刻，一个 WordPress 页面正在被多个参与者处理：

Content Agent → 修改正文  SEO Agent → 修改 canonical  Internal Linking Agent → 重写内部链接  Human Editor → 修改标题  Drift Reconciler → 准备恢复 Desired State  Publisher Replica → 因任务重试再次执行

问题来了。

这些参与者可能都有合法权限。

但：

“允许你修改”与“现在轮到你修改”，是两件完全不同的事。

这就是多 Agent 真正进入生产环境后，必须补上的一层：

这篇要解决的核心问题，可以压缩成一句话：

授权告诉我们“谁可以做”。

协调机制决定“这一刻到底由谁做”。

· · ·

一个成熟的多 Agent 系统，至少要区分：

Authority Ownership Coordination

它们回答的是三个不同问题。

Authority：你有没有权做？

例如 SEO Agent 拥有：

UPDATE_CANONICAL

说明它在特定条件下可以修改 canonical。

这是授权问题。

Ownership：这份状态最终由谁负责？

例如：

canonical → SEO Control Plane  body → Content Control Plane  worker source → Git  incident freeze → Incident Control Plane

Ownership 表示某一类 Managed State 的最终权威来源。

Coordination：现在轮到谁写？

即使两个主体都有权限，也不能因此同时改同一份互斥状态。

Coordination 解决的是：

Who may modify this resource right now?

可以把它理解为一种带时间维度的临时控制权。

所以：

有权限 ≠ 拥有该状态  拥有该状态 ≠ 当前持有写入权  持有 Lease ≠ 自动获得业务授权

这三个概念必须彼此连接，又不能互相替代。

· · ·

最简单的并发控制，很容易从下面这个字段开始：

{   "locked": true }

但马上会出现三个问题：

谁锁的？

锁它干什么？

持有者崩溃以后，谁来解锁？

于是系统开始增加：

{   "locked_by": "publisher-agent-7",   "locked_at": "...",   "expires_at": "..." }

到这里，它实际上已经开始从 Lock 演化为 Lease——有期限的临时控制权。

这也是 Lease 比“永久锁”更适合分布式 Agent 的原因。

如果 Agent 因为进程崩溃、网络分区或者部署替换而消失，它不能永远占有生产资源。Lease 允许控制权到期、续约和重新竞争。

Kubernetes 就提供了一个很值得借鉴的例子。官方文档中，coordination.k8s.io 下的 Lease 对象被用于节点心跳和组件级 Leader Election；

Lease 可以包含 holderIdentity、renewTime、leaseDurationSeconds 等信息。([Kubernetes])

但这里有一个非常重要的边界：

本文后面的 Ownership Registry、Authority Graph、Coordination Receipt 等，都属于项目层工程设计。

· · ·

Lease 解决了“现在由谁协调”，但它并不能自动解决所有分布式并发问题。

第一个典型问题叫：

假设 Content Agent 读取了文章 Revision 31。

随后 SEO Agent 更新了 Meta 信息，文章变成 Revision 32。

但 Content Agent 手里仍然拿着旧快照，最后把整个对象重新写回。

结果可能是：

SEO Agent 的修改 → 被旧快照覆盖

更安全的做法不是 Blind Write，而是：

READ revision = 31  ↓  MODIFY  ↓  WRITE only if revision still = 31

如果资源已经变成 Revision 32：

CONFLICT

而不是继续覆盖。

Kubernetes API 本身也使用 resourceVersion 处理这类乐观并发问题。

官方文档说明，对已有对象执行条件更新时，如果客户端携带的 resourceVersion 已经过期，API Server 可以拒绝这次写入并返回 409 Conflict，从而避免丢失更新。([Kubernetes][2])

因此第一条原则是：

但还有第二个问题更隐蔽。

假设 Agent A 获得 Lease：

epoch = 100

随后它发生长时间暂停。

Lease 到期后，Agent B 接管：

epoch = 101

此时 Agent A 又恢复了。

如果生产端只相信 Agent A 自己保存的“我曾经持有 Lease”，它可能继续提交旧操作。

这就是：

解决这个问题，需要在真正的写入边界加入 Fencing Token 思路。

例如：

Agent A epoch = 100  Agent B epoch = 101

生产写入端已经接受了 101。

此时 A 再提交：

epoch = 100

直接拒绝：

100 < 101 → REJECT

本文可以把这一单调递增序号称为：

但需要明确：

“Fencing Epoch”是本文项目里的工程命名，并不是 Kubernetes Lease 的官方字段。

真正要实现的安全性质只有一个：

· · ·

很多系统一发现并发问题，第一反应就是加大锁。

例如：

lock = wordpress

结果一个 Agent 修改一篇文章，整个网站其他发布任务全部停止。

安全是安全了。

吞吐量也没了。

但反过来，如果锁得过细：

post:1024:title

另一个 Agent 同时修改：

post:1024:slug

又可能间接影响 URL、canonical、redirect 和内部链接。

所以真正的问题不是：

而是：

本文更建议使用：

而不是：

Smallest Possible Scope

例如：

wp:post:1024  site:example.com:robots  site:example.com:product-template  worker:seo-publisher:production

这里还会引出一个非常容易被忽略的问题：

不同 Agent 必须把同一个逻辑资源解析成同一个 Coordination Key。

否则：

Agent A → wp:post:1024  Agent B → wordpress:article:1024

两边都成功取得 Lease，却实际上修改的是同一个对象。

因此 Coordination Key 不应该让每个 Agent 临场自己生成，而应该存在统一的：

更进一步，两个物理资源不同的操作，也可能存在语义冲突。

例如：

Agent A → 修改 canonical 模板  Agent B → 批量修改页面 canonical

资源 ID 不一样。

但它们属于同一个：

SEO_METADATA / INDEXING_CONTROL

冲突域。

所以成熟系统不仅要识别：

same resource

还必须能够识别：

semantic conflict

· · ·

如果 Multi-Agent Coordination 最后变成：

所有写入 ↓ 全部排队

那实际上只是把分布式系统退化成了单线程系统。

更合理的做法，是先定义资源的并发语义。

例如可以把操作归为：

READ_SHARED WRITE_OPTIMISTIC WRITE_EXCLUSIVE MULTI_WRITER_MERGEABLE

读取 GSC、GA4 或文章当前状态，通常可以共享执行。

修改带 Revision 的 Metadata，可以采用 Optimistic Concurrency。

robots.txt、生产部署、数据库 Schema Migration 等高冲突状态，更适合排他协调。

但如果：

Agent A → meta_description  Agent B → featured_image

而 Adapter 又确实支持字段级安全更新，两者未必需要串行化。

所以资源 Schema 可以进一步定义：

body → exclusive  title → exclusive  meta_description → field-versioned  featured_image → field-versioned  tags → merge policy

关键点不是“让 LLM 判断这次应该怎么合并”。

而是：

LLM 可以提出修改意图。

不能临场发明生产环境的并发语义。

· · ·

这里可以借鉴 PostgreSQL Advisory Lock 的一个非常重要的设计事实。

PostgreSQL 官方文档明确说明，Advisory Lock 的含义由应用定义，而且数据库并不会强制所有应用一定遵守这套锁协议；正确使用依赖应用自身遵守约定。([PostgreSQL][3])

这对 Agent 系统非常有启发。

假设：

Agent A → 正常检查 Lease  Agent B → 绕过 Gateway → 直接调用生产 API

那么无论 Lock Registry 设计得多漂亮，都没有意义。

因此 Coordination 不能只是：

Agent 自己检查

而必须在真正的 Production Mutation Choke Point 强制执行。

例如：

Agent ↓ Action Gateway ↓ Validate Authority ↓ Validate Ownership ↓ Validate Lease ↓ Validate Epoch ↓ Validate Resource Version ↓ Execute

换句话说：

· · ·

传统权限模型常常是：

User ↓ Role ↓ Permission

但真正的 Multi-Agent Production System 很快会出现更复杂的关系：

SEO Controller → owns canonical  Content Controller → owns body  Agent A → may write resource X  Agent B → may approve Agent A  Agent C → may delegate to Agent D  Incident Commander → may preempt Release Controller  Governance Engine → may revoke capability

这些关系更适合表达为：

它不是组织架构图。

它描述的是：

例如一条 Authority Edge 不能只写：

SEO Agent MAY_WRITE canonical

还应该能够带上：

site = example.com environment = production resource_type = product_page valid_until = ... risk <= MEDIUM

这样 Authority 才真正从“这是一个受信任 Agent”，变成：

principal + action + resource + environment + context + time

这也与 NIST SP 800-207 的 Zero Trust 思路相吻合。

NIST 强调按具体请求进行最小权限访问判断，并通过 Policy Decision Point / Policy Enforcement Point 对 Subject 到 Resource 的访问进行判断和强制执行，而不是因为主体已经通过一次认证，就默认后续所有请求都可信。

([NIST Publications][4])

但同样要注意：

NIST 并没有定义本文所说的 Authority Graph。

Authority Graph 是本文把 Zero Trust 的 request-scoped authorization 思路应用到 Multi-Agent Production Governance 后形成的工程模型。

· · ·

Orchestrator 收到：

Optimize 5,000 pages

它不可能所有工作都自己完成。

它可能把任务拆给：

Content Agent SEO Agent Internal Link Agent Schema Agent Publisher Agent

问题是：

不应该。

一个更稳妥的约束是：

Delegated Authority ⊆ Parent Authority

而且最好继续收缩。

例如：

Parent → UPDATE_POST  Child → UPDATE_POST    only:    title    meta_description

这就是 Authority Attenuation。

委托链还必须能够追溯：

Root Authority ↓ Delegation 1 ↓ Delegation 2 ↓ Capability ↓ Production Action

否则事故发生以后，只能看到：

seo-agent-7 修改了页面

却不知道：

谁把权限给了它？ 为什么能给？ 给到什么范围？ 是否已经到期？

SPIFFE / SPIRE 在身份层面提供了一个很有价值的参考。

SPIFFE Workload API 的目标之一就是让运行中的 workload 获取并使用可验证的工作负载身份，而不只是依赖应用自己声明的一个名字；SVID 可以让身份以密码学方式被验证。([SPIFFE][5])

而 SPIRE 的 Delegated Identity API 更直接提示了委托的风险：官方文档明确说明，被授权的 trusted delegate 可以代表其他 workload 获取 SVID，并可能以这些 workload 的身份执行操作，因此必须把它视为高信任能力。

([SPIFFE][6])

这与 Agent Delegation 的风险非常相似：

因此高风险生产委托必须受到 Governance 控制，并且能够撤销、过期和向下传播失效。

· · ·

到了这里，一次成熟的生产写入，可以形成下面这条协议：

1. Resolve Resource 2. Resolve Owner 3. Validate Authority 4. Detect Conflicts 5. Resolve Coordination Key 6. Acquire Lease / Coordination Right 7. Read Current Version 8. Validate Preconditions 9. Execute 10. Verify Critical Postconditions 11. Write Receipt 12. Release Lease

这里有两个细节特别重要。

第一个：

Lease 不应该在 API 返回 200 的瞬间立即释放。

因为：

HTTP 200

只说明某次请求被成功处理。

它不必然等于：

Desired State 已经真正建立

所以更合理的 Critical Section 是：

Acquire ↓ Read ↓ Write ↓ Immediate Verification ↓ Receipt ↓ Release

但 Lease 也不能覆盖整个业务结果观察周期。

例如索引状态、排名变化、CTR 变化可能需要异步观察。

这些属于：

Outcome Monitoring

而不是：

Critical Section

因此不要让一个 SEO 实验为了等待搜索引擎结果，持有几小时甚至几天的生产 Lease。

第二个：

Conflict 并不等于 Failure。

如果另一个 Agent 已经持有协调权，当前请求收到：

RESOURCE_BUSY

这是一个正常的协调结果。

不是理由让十个 Agent：

retry every 100ms

否则很快就会形成 Retry Storm。

更合理的是：

backoff + jitter + queue + governed priority + fairness

Lock 解决“谁现在持有”。

Queue 解决“下一个轮到谁”。

这两个问题不能混在一起。

· · ·

如果系统允许 Agent 自己声明：

priority = CRITICAL

很快所有 Agent 都会变成 Critical。

所以生产优先级必须来自 Governance，而不是执行主体自己填写。

事故场景尤其如此。

例如普通 Publisher 正在批量发布，此时系统检测到站点范围的 noindex 风险。

此时可以设计：

SEV1 Incident Control > Normal Release

允许 Incident Controller 抢占普通发布控制权。

但这并不意味着：

Human always wins

“人类”本身不是一个无限权限角色。

一个普通 WordPress Editor 不应该仅仅因为是人，就能够覆盖站点级安全策略。

真正应该比较的是：

Authority Role Scope Context Priority Emergency State

而不是：

Human vs AI

这也是多 Agent 系统非常重要的一次认知变化：

· · ·

两个 Agent 完全可能出现：

Agent A holds post:100 waits post:101  Agent B holds post:101 waits post:100

双方谁也无法继续。

这就是 Deadlock。

PostgreSQL 官方文档不仅说明数据库会检测这类死锁并中止其中一个事务，还明确建议：当多个对象需要加锁时，应尽量保持一致的获取顺序，以降低死锁发生概率。([PostgreSQL][3])

Agent Coordination 同样可以借鉴这一原则。

例如规定全局顺序：

site ↓ template ↓ post ↓ field

或者对 Canonical Resource Key 排序后再获取 Lease。

同时必须存在：

deadline timeout

避免无限等待。

否则“引入锁”本身，可能只是把 Race Condition 变成了 Deadlock。

· · ·

WordPress 场景

Content Agent 修改 Body。

SEO Agent 修改 Canonical。

如果 Adapter 使用旧快照整对象回写，两者就可能互相覆盖。

更安全的方案是：

Field Ownership + Current Revision + Patch Semantics + Conflict Policy + Post-write Verification

如果两个字段被证明独立，而且 Adapter 支持字段级安全修改，可以并行。

如果都修改 Body，则序列化。

Human Editor 场景

人工正在后台编辑标题和正文。

Publisher Agent 同时准备写回整篇文章。

正确答案不应该是：

Agent wins

也不应该固定成：

Human wins

而应该把：

Human Presence Resource Revision Fields Touched Managed Fields

正式作为 Coordination Evidence。

存在冲突时：

HOLD

往往比偷偷覆盖人工修改更安全。

Production Deployment 场景

两个 Release Controller 同时准备把不同版本推向 Production。

代码仓库本身可以并行开发。

但：

Code Concurrency ≠ Deployment Concurrency

生产环境完全可以被建模为一个独立的 Coordination Resource：

worker:seo-publisher:production

Rollout Critical Section 中只允许一个有效控制者推进状态。

Scheduled Job 场景

同一个定时发布任务因为平台重试，同时启动两个 Runner。

如果两边都直接执行：

bulk publish

可能出现重复发布和重复 Side Effect。

Job 本身也可以成为 Lease Resource：

job:daily-seo-publish

其他 Runner 没有拿到 Coordination Right，就退出或者进入队列。

· · ·

过去的 Execution Receipt 回答：

What happened?

但 Multi-Agent 系统还需要回答：

Why was this actor the one allowed to do it now?

所以可以单独设计：

例如：

{   "coordination_id": "coord_992",   "principal": "seo-agent-7",   "resource_key": "wp:post:1024",   "owner": "seo-control-plane",   "authority_epoch": 91,   "ownership_epoch": 12,   "lease_id": "lease_771",   "lease_epoch": 803,   "expected_version": "rev_331",   "final_version": "rev_332",   "conflicts": [],   "status": "COMPLETED" }

Execution Receipt 证明“发生了什么”。

Coordination Receipt 证明“为什么当时轮到它执行”。

事故复盘时，这个差异非常重要。

如果发生 Double Write，我们不能只问：

Which code failed?

还应该问：

为什么两个主体 会同时认为 自己拥有生产控制权？

根因可能不是业务代码 Bug。

也可能是：

Missing Owner Stale Owner Wrong Coordination Key Lease Not Enforced Missing Fencing Delegation Too Broad Authority Revocation Failure Incorrect Conflict Policy

这才是 Multi-Agent Production System 新增的故障空间。

· · ·

不是 Agent 有多少个。

也不是“Agent Swarm”听起来有多先进。

真正应该看的，是：

一个成熟的平台，至少应该逐步形成下面这些不变量：

No Valid Authority → No Production Mutation  No Resolved Ownership → No Managed Write  No Valid Coordination Right → No Exclusive Write  Stale Lease Epoch → No Production Mutation  Stale Resource Version → No Blind Overwrite  Delegated Authority ⊆ Parent Authority  One Managed State → One Authoritative Owner

然后把它们真正压到执行链路里：

Identity ↓ Governance ↓ Authority ↓ Ownership ↓ Conflict Detection ↓ Lease / Version ↓ Fencing ↓ Action Gateway ↓ Execution ↓ Verification ↓ Coordination Receipt ↓ Release ↓ Drift Detection

这时候，多 Agent 才不再是：

multiple scripts calling the same APIs

而真正开始接近：

· · ·

而是：

Agent 数量越多，系统未必越自主。

如果缺少：

Scoped Authority + Explicit Ownership + Bounded Delegation + Versioned State + Lease-based Coordination + Enforced Fencing

更多 Agent 只会带来更多：

Race Condition Lost Update Authority Ambiguity Unpredictable Side Effect

所以这一篇最值得留下的原则，其实只有一句：

共享生产状态，必须拥有明确、可验证、可强制执行的协调协议。

到了这里，我们终于把三个层次真正分开：

AUTHORITY = May you do it?  OWNERSHIP = Who governs this state?  COORDINATION = Who may act now?

下一篇可以继续向下走。

当系统已经知道：

谁拥有 Authority？ 谁是 Owner？ 谁持有当前 Lease？

下一个问题就是：

于是第（三十五）篇将进入：

从“Agent 名称”继续走向：

Cryptographic Workload Identity ↓ Attestation ↓ Short-lived Credential ↓ Capability ↓ Production Action ↓ Verifiable Execution Identity

真正回答：

· · ·

01官方依据与工程边界

本文的 Kubernetes 部分主要借鉴 Lease、Leader Election 与 resourceVersion 的并发控制机制；

Kubernetes 官方确认 Lease 用于节点心跳和组件级 Leader Election，并说明对象更新可以通过 resourceVersion 检测过期写入。([Kubernetes])

PostgreSQL 部分借鉴 Advisory Lock、死锁与一致加锁顺序的思想。其官方文档明确指出 Advisory Lock 的业务含义由应用定义，系统不会替应用强制所有参与者遵守这一语义。([PostgreSQL][3])

SPIFFE / SPIRE 部分用于说明可验证 Workload Identity 以及 Delegated Identity 的安全边界。([SPIFFE][5])

NIST SP 800-207 提供的是 Zero Trust、per-request access、least privilege、PDP/PEP 等基础原则，而不是一套 Agent Authority Graph 标准。

([NIST Publications][4])

本文提出的 Authority Graph、Coordination Control Plane、Coordination Key Registry、Conflict Domain、Ownership Registry、Fencing Epoch、Authority Epoch 与 Coordination Receipt，均属于本系列为了 SEO / GEO Multi-Agent Production Governance 建立的工程抽象，不应写成 Kubernetes、PostgreSQL、SPIFFE 或 NIST 的官方统一规范。