Independent Submission X. Feng Internet-Draft Intended status: Experimental 2 June 2026 Expires: 4 December 2026 UGP: Universal Gig Protocol (通用零工协议) draft-feng-ugp-00
UGP：通用零工协议 面向零工招聘的 Agent 互操作协议
Universal Gig Protocol  ·  draft-feng-ugp-00  ·  Experimental

Status of This Memo

本文档为一份独立提交（Independent Submission）的实验性草案，非任何标准化组织的正式产出，仅用于征集意见（Request for Comments）。它沿用 IETF Internet-Draft 的体例与约定，但不代表 IETF 共识，亦不暗示任何背书。

本草案随时可能被更新、替换或废弃。引用本草案时SHOULD NOT将其视为已定型的规范。当前修订版本为 00，反馈与勘误欢迎以批注或 issue 形式提交。

　Abstract

本备忘录定义 UGP（Universal Gig Protocol，通用零工协议）：一个中立、厂商无关的开放协议，使代表用工需求方与代表零工劳动者的自治 Agent，能够跨平台完成发现、协商、缔约、履约、结算与互评的完整用工旅程，而无需对每个平台做点对点定制对接。

UGP 在结构上对标 Google 的 Universal Commerce Protocol（UCP），复用其「能力原语 + 多传输 + 责任锚点」的设计哲学，并复用 A2A、AP2、MCP 与 W3C Verifiable Credentials 作为底层。针对劳动力这一特殊标的——由有身份、有权利、有人身风险的真人在一段时间内履约产生——UGP 引入三项 UCP 不具备的机制：履约证明门控的结算、强制的安全级资质信任层，以及法律承重的用工主体（Employer of Record）责任锚点。

本协议采用路线 A：将 UGP 定位为 UCP 的劳动力垂直 Profile。凡能映射的部分（发现、身份链接、支付、会话）严格遵循 UCP 并标注 UCP-OK；劳动力特有的部分作为声明式扩展，全文以 UGP-EXT 显著标示。一致性规则与降级行为见 §8.1。

[ 第 1 页 ]

Table of Contents

1. 引言 Introduction 2. 架构概览 Architecture Overview 3. 能力原语 Capabilities 4. 会话流程 Protocol Flow 5. 消息格式 Message Formats 6. 合规与劳动者保护 Compliance 7. 安全性考量 Security Considerations 8. 互操作性 Interoperability 9. 注册表考量 Registry Considerations 10. 参考文献 References A. 附录：示例会话

1.引言 Introduction

1.1　背景与动机

零工 / 灵活用工是一个高频、双向、短周期的劳动力市场：同城仓配、家政、餐饮兼职、代驾、活动执行、数据标注等。今天这些撮合分散在彼此封闭的平台中，劳动者的资质与声誉被锁定在单一平台，需求方每接入一个新供给渠道都要重做对接。

当需求侧与供给侧都开始由 Agent 代理时，撮合本身成为一种 Agent-to-Agent 交互。UGP 的目标是为这一交互提供一套共同语言：任意符合 UGP 的需求方 Agent 与零工 Agent，MUST能够在不预先双边集成的前提下完成一次用工。

1.2　与 UCP 的关系

UCP 将购物旅程拆解为标准能力（发现 → 购物车 → 结账 → 支付 → 售后），让购物 Agent 跨 N 个商家交易。用工旅程与之高度同构：发现用工 → 组队 → 要约 → 缔约 → 履约 → 结算 → 互评。因此 UGP 直接借用 UCP 的骨架。

但二者标的本质不同：

核心断言：商品是被交付的物；劳动力是被履约的人。由此 UGP 必须在 UCP 之外引入：履约证明（§3.7）、安全级资质信任层（§3.3、§7.3）、用工主体责任锚点（§2.3）。

路线决定（本草案）：UGP SHALL 注册为 UCP 体系下的「劳动力」垂直 Profile（路线 A）。能映射的能力严格按 UCP Profile 实现，以保证纯 UCP Agent 可发现、协商、付款；劳动力特有的三项作为 UGP 扩展声明。全文用两类徽章显著区分：UCP-OK 表示与 UCP 兼容，UGP-EXT 表示 UCP 之外的扩展。一致性与 fail-safe 降级规则见 §8.1。

1.3　需求语言约定

本文中的关键词 MUST、MUST NOT、REQUIRED、SHALL、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL，当且仅当以此形式出现时，按 [RFC2119] 与 [RFC8174] 所述解释。

1.4　术语 Terminology

需求方 Agent (Demand Agent)
代表用工需求一方发起意图、组队、要约、确认履约的自治代理。
零工 Agent (Worker Agent)
代表劳动力供给一方的自治代理；可主动应征，也可被发现匹配。
用工主体 (EOR, Employer of Record)
对一次用工承担法律责任（工伤、个税、社保、合规）的实体。
凭证方 (Credentials Provider)
签发或核验实名、健康证、技能证、背景与历史评价等可验证凭证（VC）的实体。
结算方 (Settlement Provider)
负责工资计算、资金托管、代发、个税预扣与社保的实体。
Engagement
一次经双方签名确认、不可篡改的用工合约对象（§5.3）。
履约证明 (Proof-of-Work, PoW)
证明劳动确已发生的可核验证明集合（§3.7、§5.4）。注：与共识算法的同名概念无关。
[ 第 2 页 ]

2.架构概览 Architecture Overview

2.1　角色 Roles

UGP 定义五个核心角色与一个可选角色。下表与 UCP 角色对照：

UCP 角色UGP 角色职责
Consumer Surface需求方 Agent发起用工意图、组队、要约、确认履约
Merchant (of Record)零工 Agent劳动力供给；可主动找活或被匹配
（无）用工主体 EOR承担工伤 / 个税 / 社保 / 合规的法律责任
Credentials Provider凭证方签发 / 核验实名、健康证、技能、背景、评价
Payment Service Provider结算方工资计算、托管、代发、个税、社保
（弱）仲裁方（可选）履约争议时裁决托管资金释放

2.2　信任与传输基座

UGP 不重复发明传输与身份层。实现 SHOULD 复用：协商走 A2A；结算腿走 AP2；工具与数据访问走 MCP；身份与资质用 DID + W3C VC。UGP 仅在其上定义语义层（角色、能力、消息与状态机）。

2.3　责任锚点：用工主体 (EOR)UGP-EXT

UCP 以「Merchant of Record」作为信任与责任锚点。在劳动力场景，对应的是法律承重得多的用工主体。中国语境下「平台直雇 / 劳务派遣 / 业务外包」三种模式的责任归属截然不同，是欠薪与工伤纠纷的根本。

因此：每个 JobIntent（§5.2）MUST 携带一个合法的 employer_of_record 声明，包含用工模式与统一社会信用代码；缺失或非法的 EOR 声明，其对应 Engagement MUST NOT 进入结算阶段（§4.2 的 FUNDED 状态）。

UCP 的 Merchant-of-Record 只承担商业问责（谁是记录卖家、负责退款与税务）；UGP 的 EOR 承担用工法责任——工伤、社保、派遣/外包定性。同一"问责实体"字段，但语义与法律义务不同，因此独立为扩展。纯 UCP Agent 不理解此字段时，受 §8.1 的 fail-safe 规则约束，MUST NOT 越过 FUNDED 放款。

[ 第 3 页 ]

3.能力原语 Capabilities

能力是 UGP 的功能单元。Agent 在 Profile 阶段声明其支持的能力集合。下表给出能力与 UCP 的对照、触发的传输，及其 UCP 一致性分级（路线 A）：

UGP 能力对应 UCP传输UCP 一致性
SourcingDiscoveryA2AUCP-OK
ShortlistCart—UCP-OK
Credential LinkingIdentity LinkingMCP·VCOK · 强化
NegotiationDiscountA2AOK · 超集
EngagementOrderA2AUCP-OK
EscrowPayment·holdAP2UCP-OK
Proof-of-Work（无）MCPUGP-EXT
SettlementPayment·captureAP2EXT · 触发条件
Dual RatingReviewsA2AOK · 超集

UCP-OK 直接映射；强化/超集 映射成立但要求更强或交互更广；UGP-EXT 为 UCP 之外的扩展。Settlement 本体兼容 AP2，但其放款触发由 Proof-of-Work 门控，故标为扩展。

3.3　Credential Linking（重点）UCP-OK · 强化

上门、驾驶、配送、餐饮涉及人身与食品安全，资质核验是强制项而非可选项。实现 MUST 支持选择性披露：凭证方仅回答布尔断言（如「持有有效健康证 = true」），而 MUST NOT 默认回传证件原文。需求方 SHOULD 通过零知识方式核验，做到「可核验而不可留存」。

本能力沿用 UCP 的 Identity Linking（OAuth + DID/VC）模式，故标为兼容；但 UGP 把它从可选提升为安全场景下的强制 + 选择性披露，属于在 UCP 之上收紧约束，不破坏互通。

3.7　Proof-of-Work（UCP 没有的能力）UGP-EXT

劳动不可退货，故结算 MUST 由履约事实门控。履约证明方法 MAY 组合使用：geofence_clock（地理围栏 + 活体打卡）、milestone_signoff（里程碑双签）、dual_confirm（双向确认）。当履约证明在约定窗口内未达成且无人主动否认时，仲裁 SHOULD 默认偏向劳动者，以抑制欠薪攻击（§7.4）。

UCP 最接近的概念是"发货/物流跟踪"，但那是商家单方上报的实物交付；Proof-of-Work 是双边存证、活体绑定、随时间发生的劳动事件，无法用原生 UCP 表达。它是路线 A 下三项核心扩展之一，且是 Settlement 放款触发的前置条件。

[ 第 4 页 ]

4.会话流程 Protocol Flow

4.1　正常流程（时序）

需求方 Agent                         零工 Agent / 凭证方 / 结算方
   |  1. Profile         双方声明 UGP 能力
   |  2. Sourcing  ----- JobIntent 广播 ----------▶  应征 / 匹配
   |  3. Shortlist       组建班组（"购物车"）
   |  4. Cred.Linking -- 核验请求 -----▶ 凭证方
   |                ◀--- 选择性披露 (VC, 布尔断言) ---
   |  5. Negotiation --- 要约 ↔ 还价 (A2A) --------▶
   |  6. Engagement ---- 双方签名 → 合约 + 锁定 EOR -▶
   |  7. Escrow    ----- 资金进托管 (AP2 令牌化) ---▶ 结算方
   |  ============== 履约期 ==============
   |  8. Proof-of-Work   到岗活体打卡 / 里程碑双签 -▶ 结算方
   |  9. Settlement      履约校验通过 → 放款 + 个税 -▶ 零工
   |  10. Dual Rating -- 双向署名互评 -------------▶
   v

4.2　Engagement 状态机FUNDED→SETTLED 为 EXT

一次 Engagement 的生命周期 MUST 遵循下述状态转移；任何越过 FUNDED 而无合法 EOR 的转移 MUST 被拒绝（§2.3）。

  DRAFT ──offer──▶ OFFERED ──accept──▶ CONFIRMED
                      │                     │
                   decline               fund(escrow)
                      ▼                     ▼
                   VOIDED                 FUNDED
                                            │
                                         clock-in
                                            ▼
                                       IN_PROGRESS
                                            │
                                     proof verified
                                            ▼
              REFUNDED ◀──arbitrate── DISPUTED ◀─dispute─ COMPLETED
                  ▲                       │                   │
                  └───────arbitrate───────┘               release
                                                              ▼
                                                           SETTLED

状态机自 DRAFT 至 FUNDED 与 UCP 的下单/授权流程对齐（UCP-OK）。自 FUNDED 之后——经 IN_PROGRESS、由 Proof-of-Work 校验进入 COMPLETED、再 release 到 SETTLED——是 UGP 扩展：UCP 没有"捕获被后发生的履约事件门控"这一语义。

[ 第 5 页 ]

5.消息格式 Message Formats

所有 UGP 消息以 JSON 表示，并 MUST 包裹于公共信封中。规范字段使用 snake_case；时间戳 MUST 为 [RFC3339] 格式。

5.1　公共信封 Envelope

{
  "ugp_version": "0.1",
  "msg_id":   "msg_3f9a...",
  "msg_type": "job_intent | candidacy | offer | engagement
               | pow_attestation | settlement | rating",
  "ts":       "2026-06-03T08:55:00+08:00",
  "from":     { "role": "demand_agent", "did": "did:ugp:emp:acme" },
  "to":       { "did": "did:ugp:wkr:9a1f" },   // 或 "broadcast"
  "body":     { ... },                          // 见 §5.2–5.4
  "sig":      "z58D...kQ"                        // 对 body 规范化后的分离签名
}

5.2　JobIntent Object

{
  "type": "job_intent",
  "intent_id": "ji_8f3a91",
  "employer_of_record": {           // §2.3 — REQUIRED
    "entity": "Acme劳务派遣有限公司",
    "uscc":   "91110108MA...",
    "model":  "labor_dispatch",     // direct | labor_dispatch | outsourcing
    "work_injury_insurance": "vc_wii_..."
  },
  "work": {
    "title": "仓库分拣",
    "skills_required": ["分拣", "扫码枪操作"],
    "credentials_required": [
      { "type": "real_name", "level": "verified" },
      { "type": "health_certificate", "issuer_class": "cdc" }
    ],
    "headcount": 3,
    "window":   "2026-06-03T09:00:00+08:00/2026-06-03T18:00:00+08:00",
    "location": { "geo": [39.92, 116.46], "address_ref": "loc_a12" }
  },
  "terms": {
    "rate": "28 CNY / hour",
    "min_wage_floor_attested": true,   // §6.1 — REQUIRED true
    "max_hours": 9,
    "settlement": { "trigger": "proof_of_work",
                    "escrow": true, "payout_sla_h": 24 }
  },
  "compliance": {
    "anti_discrimination": "strict",
    "prohibited_filters": ["gender","age","ethnicity",
                           "household_registration"],
    "data_basis": "PIPL_consent"     // §6.3
  }
}

5.3　Engagement Object

{
  "type": "engagement",
  "engagement_id": "eng_77c2",
  "status": "CONFIRMED",             // §4.2 状态机
  "parties": {
    "worker": {
      "did": "did:ugp:wkr:9a1f",
      "credentials_attested": [
        { "type": "real_name",         "proof": "vc_rn_..." },
        { "type": "health_certificate","proof": "vc_hc_...",
          "disclosure": "boolean" }   // 仅披露真伪，不含证号
      ]
    },
    "employer_of_record": { "entity": "...", "uscc": "..." }
  },
  "agreed_terms": { "rate": "30 CNY / hour", "scope": "分拣+扫码入库",
                    "window": "2026-06-03T09:00/18:00+08:00" },
  "settlement_instruction": {
    "provider": "settle_xyz", "escrow_ref": "esc_5521",
    "release_on": "proof_of_work.verified", "rail": "ap2_token" },
  "proof_of_work": { "method": ["geofence_clock","milestone_signoff"],
                     "verifier": "dual_confirm" },
  "dispute": { "arbiter": "arb_neutral_01",
               "escrow_hold": true, "timeout_favors": "worker" },
  "signatures": ["sig_worker_...", "sig_eor_..."]   // 双签 REQUIRED
}

5.4　ProofOfWork Attestation

{
  "type": "pow_attestation",
  "engagement_id": "eng_77c2",
  "method": "geofence_clock",
  "clock_in":  { "ts":"...09:02+08:00", "geo":[39.920,116.461],
                 "liveness": "passed", "subject_match": "vc_rn_..." },
  "clock_out": { "ts":"...18:04+08:00", "geo":[39.921,116.460] },
  "confirmed_by": ["worker","demand_agent"],   // dual_confirm
  "sig": "z9k...Q"
}
人证绑定：subject_match 将打卡时的活体结果绑定到实名 VC 的主体，杜绝「核验的是 A、到岗的是 B」的证件挂靠（§7.3）。

5.5　字段约定（ABNF）

rate        = amount SP currency SP "/" SP unit
unit        = "hour" / "day" / "task" / "piece"
amount      = 1*DIGIT [ "." 1*2DIGIT ]
currency    = 3ALPHA                       ; ISO 4217
window      = date-time "/" date-time       ; RFC3339 时间区间
credential  = cred-type ":" assurance       ; 见 §9 注册表
assurance   = "self" / "verified" / "certified"
[ 第 6 页 ]

6.合规与劳动者保护 ComplianceUGP-EXT

UGP 将合规做成机器可校验的一等公民，而非线下兜底。UCP 仅有 Buyer Consent / 数据合规钩子，并无"因价格低于法定劳动下限而拒绝交易"或"禁止某些匹配特征"的概念，故本章整体为 UGP 扩展。

6.1　最低工资与工时

JobIntent 的 terms.rate 折算到当地法定最低工资以下时，符合 UGP 的实现 MUST 拒绝该意图进入 Sourcing；max_hours 超过法定上限时 SHOULD 警示或拒绝。

6.2　反歧视

匹配过程 MUST NOT 以 prohibited_filters 中列举的受保护属性（性别、年龄、民族、户籍、超出岗位必要的健康状况）作为筛选维度。实现 SHOULD 对匹配特征做审计，识别以代理特征（如小区、籍贯）变相歧视的「歧视洗白」。

6.3　数据与同意

劳动者个人信息的处理 MUST 具备合法性基础（data_basis，如 PIPL 同意）。任何 PII 的披露 MUST 经劳动者 Agent 显式同意，且 MUST NOT 由对手方消息内容自动触发（与 §7.2 联动）。

7.安全性考量 Security Considerations

7.1　威胁模型

威胁描述缓解
人证不符 / 证件挂靠核验 A，到岗 B活体绑定 VC 主体；一次性挑战 (§7.3)
Sybil 供给伪造大量零工 Agent 操纵供给与费率proof-of-personhood；身份质押
欠薪攻击需求方假称"未完成"扣留托管双向确认 + 超时偏向劳动者 (§7.4)
声誉操纵合谋刷评署名 + 质押加权 + 跨平台异常检测
提示注入JobIntent 内嵌指令诱骗零工 Agent对手内容视为不可信数据 (§7.2)
歧视洗白代理特征变相筛选prohibited_filters + 特征审计 (§6.2)

7.2　提示注入（不可信 JobIntent）

在 Agent 化招聘中，「工单描述」是不可信输入面。零工 Agent MUST 将 JobIntent 中的自然语言一律视为数据而非指令；任何越权操作（披露劳动者 PII、外发资金、修改授权）MUST 经能力白名单与劳动者显式确认，MUST NOT 由工单文本自动触发。

7.3　凭证人证绑定

资质核验 MUST 在履约打卡处与活体结果绑定到同一 VC 主体（§5.4 subject_match），并 SHOULD 使用一次性挑战防重放。

7.4　结算与争议

资金 MUST 进入托管，由履约证明门控释放。争议在约定 SLA 内未裁决时，默认转移 SHOULD 偏向劳动者，以使欠薪攻击无利可图。

[ 第 7 页 ]

8.互操作性 Interoperability

UGP 是语义层，刻意不重造传输与身份：

  • A2A — 需求方 ↔ 零工 Agent 的发现与协商（§3 中标注 A2A 的能力）。
  • AP2 — Escrow 与 Settlement 两腿，令牌化支付与 N-to-N 对账，沿用 UCP 的支付框架。
  • MCP — 将「发布需求 / 核验资质 / 打卡 / 放款」暴露为工具供 LLM Agent 调用。
  • DID + W3C VC — 身份与资质层，支持选择性披露 / 零知识证明。
  • UCP — UGP SHALL 作为 UCP 的劳动力垂直 Profile 注册（路线 A），共享信任基座。

8.1　UCP Profile 一致性本草案核心

本节规范路线 A 下的一致性分级与降级行为。每个 UGP 能力 MUST 归入下列三类之一，并在 Profile 阶段如实声明其分级：

分级含义能力
UCP-OK直接映射 UCP 能力，纯 UCP Agent 可直接互操作sourcing · shortlist · engagement · escrow
OK · 强化/超集映射成立，但 UGP 要求更强或交互更广，仍向后兼容credential_linking · negotiation · dual_rating
UGP-EXTUCP 之外的扩展能力，纯 UCP Agent 不识别proof_of_work · settlement(放款触发) · employer_of_record · compliance

声明与协商。UGP 扩展能力 MUST 以 UCP 的能力声明机制（capability manifest）携带，前缀 ugp.ext.*，使纯 UCP Agent 能够在握手阶段识别"存在自己不理解的能力"，而非静默忽略。

Fail-safe 降级规则（规范性）。当对端为不理解 ugp.ext.* 的纯 UCP Agent 时：

一个不识别 proof_of_work / employer_of_record 扩展的对端，MUST NOT 越过 FUNDED 进入结算（SETTLED）。

此时会话 MAY 完成至 FUNDED（撮合 + 托管），但放款 MUST 暂停，直至由理解扩展的一方完成 Proof-of-Work 校验与 EOR 校验。最坏情况是功能受限但不出错——绝不在不理解工伤责任与履约门控的前提下放款，因为那正是法律与安全风险最集中之处。

反向地，UGP Agent 与纯 UCP 商家交互（购买商品而非用工）时 SHOULD 降级为标准 UCP 行为，不强加 PoW/EOR 语义。

9.注册表考量 Registry Considerations

本协议设立若干注册表（注册政策：Specification Required）。初始登记如下：

注册表初始值
UGP Capability Typesourcing, shortlist, credential_linking, negotiation, engagement, escrow, proof_of_work, settlement, dual_rating
UGP Credential Typereal_name, health_certificate, skill_badge, background_check, prior_rating
UGP Settlement Triggeron_confirm, proof_of_work, milestone, time_based
UGP EOR Modeldirect, labor_dispatch, outsourcing

10.参考文献 References

10.1　规范性引用 Normative

[RFC2119]  Bradner, S., "Key words for use in RFCs ...", 1997.
[RFC8174]  Leiba, B., "Ambiguity of Uppercase ...", 2017.
[RFC3339]  Klyne & Newman, "Date and Time on the Internet", 2002.
[VC-DATA]  W3C, "Verifiable Credentials Data Model".
[A2A]      "Agent-to-Agent Protocol".
[AP2]      "Agent Payments Protocol".
[MCP]      "Model Context Protocol".

10.2　参考性引用 Informative

[UCP]      Google, "Universal Commerce Protocol", 2025.
[PIPL]     《中华人民共和国个人信息保护法》, 2021.
[ 第 8 页 ]

A.附录：示例会话

需求方为次日仓库分拣招募 3 名持健康证的零工，时薪 28 元、最长 9 小时、履约证明后 24 小时内结算：

① 需求方广播 §5.2 JobIntent (broadcast)
② 零工 Agent 应征 → candidacy
③ 需求方组队 3 人 (shortlist)
④ 核验：凭证方返回 {real_name:true, health_certificate:true}
⑤ 协商：零工还价 → 时薪 30 元，需求方接受
⑥ 双方签名 → §5.3 Engagement (CONFIRMED)
⑦ 资金进托管 (FUNDED) — AP2 令牌
⑧ 09:02 活体打卡 (IN_PROGRESS) → 18:04 完工双签 (COMPLETED)
⑨ 校验通过 → 托管释放 + 代发个税 (SETTLED)
⑩ 双向署名互评 → 写入可携带声誉

Authors' Addresses

Xiaoping Feng (冯小平)
Beijing, China
URI:  https://xiaopingfeng.com
Feng Expires 4 December 2026 [ 第 9 页 ]