Parley

---

安装

pip install parley-consensus              # zero-dependency core
pip install "parley-consensus[crypto]"    # + Ed25519-signed verdicts

发行包名为 parley-consensus（PyPI 上的 parley 是无关项目）；导入名为 parley。

from parley.agent import Agent
from parley.consensus import run_consensus
from parley.preferences import HardConstraint, PreferenceSheet

options = [
    {"venue": "rooftop", "cost": 900},
    {"venue": "garden", "cost": 600},
    {"venue": "diner", "cost": 300},
]
ana = PreferenceSheet(
    "Ana", utility=lambda o: 1.0 if o["venue"] == "rooftop" else 0.4)
# a red line: code, not a preference
bob = PreferenceSheet(
    "Bob",
    hard=[HardConstraint("budget", lambda o: o["cost"] <= 700)],
    utility=lambda o: 1 - o["cost"] / 1000)
cara = PreferenceSheet(
    "Cara", utility=lambda o: 0.9 if o["venue"] == "garden" else 0.5)

agents = [Agent(s.owner, s) for s in (ana, bob, cara)]
result = run_consensus(agents, options)
print(result.status, result.decision)
print("receipt sha256:", result.transcript.hash())
# each owner replays their own private sheet, locally
for sheet in (ana, bob, cara):
    ok = result.transcript.verify_non_betrayal(sheet, result.decision)
    print(sheet.owner, "not betrayed:", ok)

agreed {'venue': 'garden', 'cost': 600}
receipt sha256: 30483303e4d94e22833161d9bb8c292c0effff88c3303d7e195e57d49c88f516
Ana not betrayed: True
Bob not betrayed: True
Cara not betrayed: True

上面的哈希是 0.2.1 及更高版本打印的结果：被否决方案的得分会报告为 0。对于同一段代码，0.2.0 版本打印的是 a9cb75c0...；决策和判定结果相同。

屋顶露台是 Ana 最喜欢的方案，但最终还是落选：它越过了 Bob 的预算红线，因此在评估任何得分之前就被否决了。协调方始终只看到 red-line，从未看到预算或方案表。

贡献者请从克隆的仓库安装：pip install -e ".[dev]"（参见状态）。

在 MCP 主机（Claude、Cursor）中使用

基础安装附带一个仅依赖标准库、通过 stdio 通信的 MCP 服务。将主机指向它：

{"mcpServers": {"parley": {"command": "parley-mcp"}}}

如果主机的 PATH 中找不到控制台脚本，请通过安装了该包的解释器启动它：{"command": "python", "args": ["-m", "parley.mcp"]}。

此服务同时支持 MCP 的两代协议：使用 2026-07-28 修订版（无 initialize，版本和功能写在每个请求的 _meta 中，通过 server/discover 进行发现）的主机可使用无状态模式；使用 2025-11-25 或更早版本的主机则会执行常规的 initialize 握手。两者使用相同的工具，并生成相同的回执哈希。 会显示三个工具：parley_decide（输入选项和各方的红线及偏好；输出 status、decision、transcript 和 transcript_sha256）、parley_verify_receipt（重新计算 transcript 的哈希，并根据记录的判定重新计算最大最小决策），以及 parley_check_party（根据某个决策重新检查一方的红线）。要检查 parley_decide 返回的内容，请将其 transcript 和 transcript_sha256 传给 parley_verify_receipt：scripts/verify-receipt.py 读取的是收据文件（由 examples/real_decision.py 写入），而不是 parley_decide 的结果，并会拒绝该结果。 输入 与 examples/demo/ 中的示例配方使用的 JSON 相同，通过一个 spec 键传入。如果你直接调用这些工具，而不是通过宿主调用，三个调用如下（即 tools/call 的 arguments）：

{"name": "parley_decide",
 "arguments": {"spec": {"title": "...", "options": [...],
                        "parties": [...]}}}
{"name": "parley_verify_receipt",
 "arguments": {"transcript": {...},
               "sha256": "<transcript_sha256 from parley_decide>"}}
{"name": "parley_check_party",
 "arguments": {"party": {"owner": "Bob", "hard": [...],
                        "utility": [...]},
               "decision": {...}}}

parley_decide 的结果不是供 scripts/verify-receipt.py 使用的收据文件；请使用 parley_verify_receipt 检查。示例提示词：

我们三个人要选一个场地：屋顶（900）、花园（600）、小餐馆（300）。Bob 不接受超过 700 的费用；Ana 更喜欢屋顶，Cara 更喜欢花园，Bob 更喜欢最便宜的选项。使用 parley_decide，然后验证 收据哈希，并检查 Bob 的红线是否得到遵守。

此模式能做什么，不能做什么。 宿主持有每一方的规范，并在一次调用中全部传入，因此各方之间以及各方与宿主之间都没有隐私。仍然有效的是引擎在代码中强制执行的规则：红线会确定性地否决选项；最大最小规则会从对所有人都可行的选项中作出选择；收据哈希会让 transcript 后续的任何修改都显现出来，但前提是哈希由可能修改 transcript 的人之外的其他人保管：该哈希没有签名，服务端也不存储它，因此来自同一方的哈希和 transcript 无法相互证明。max_min_verified 不依赖哈希：它会根据记录的判定重新计算最终选项。对于隐私表格，请通过 HTTP 为每位所有者各运行一个进程 （examples/run_env.py）；这样协调方只能看到经过遮蔽的判定。

---

2026 年的大多数 Agent 工具要么解决传输和身份问题（A2A、MCP），要么面向一对一的 Agent 商务（由 Agent 为你购买或预订），要么用于同一所有者旗下 Agent 之间的协作式辩论。Parley 致力于解决尚无产品化方案的缺口：由一组代表不同主体、具有相互冲突且私密利益的代表，达成人人都能信任的决策，并证明各自的 Agent 没有背叛委托人。

适用对象。 适用于需要由多方共同作出决策、决策不能触碰任何一方红线，且各方都能在事后证明这一点的团队和平台。最初面向受监管的多方工作流：合规与开户决策（KYC/AML、制裁红线）、市场交易与 P2P 争议，以及委托治理（委员会、评审小组）。

其核心优势是三项由代码强制执行、而非交由大模型自行决定的特性：

1. 确定性红线。 每位所有者的硬性约束都是由代码检查的谓词。提案一旦触碰其中任何一条，就会被否决，绝不会通过协商取消。“我的 Agent 不会背叛我”因此成为可证明的属性，而非一种希望。
2. 利益冲突下的共识。 协调方只能看到经过遮蔽的判定、可行性标记、软评分和经过遮蔽的原因（ok/red-line），绝不会看到私密表格，也不会知道涉及哪条约束。决策必须对每个 Agent 都可行；在可行选项中，采用平等主义的最大最小规则进行选择（提升满意度最低的参与者），并以总福利作为平局判定依据。这属于社会选择，而非多数表决。没有可行选项时 ⇒ 坦诚地陷入僵局。
3. 可验证的 transcript。 以 SHA-256 记录所有经过遮蔽的判定，并能检测篡改。每位所有者都可以在本地根据自己的私密表格重新检查，以证明没有触碰红线，而无需向任何人透露表格。

为什么要构建它（以及我们从中学到了什么）

Agent 开始替我们采取行动：预订、谈判、入职、分配。当两个 Agent 服务于不同的所有者时，“我的 Agent 有没有出卖我？”不再是杞人忧天，而成了一个现实问题。加密领域给出的 Agent 信任方案（把它放到链上，再加个代币）崩跌了 89–99.7%；真正持久的需求是信任原语本身，且与代币脱钩。

不会说谎、可供查验的 AI。 2026 年的 Agent 热潮周期证明，病毒式传播可以与真相完全脱钩。Parley 是可证明的版本：每次协商中的每个裁决都是可重新哈希的收据；每位所有者都能重放自己的私有表单，证明没有越过任何红线。无需信任任何人，只需查验即可。

构建 v0 让我们认识到，这个切入点比“多 Agent 共识”更聚焦、更明确：价值不在投票，投票是免费的（Snapshot、投票）；价值在于在私有利益冲突下可证明不会背叛——任何一方都不必透露自己的私有表单，也不必透露所涉的红线；任何红线都不能被交易掉；每个人都能自行查验收据。这些都无法由现成组件组合实现，也是我们用代码强制执行、而不是交由大模型的善意来保障的唯一要点。完整的证明示例：docs/dogfood-01-p2p-escrow.md。

相关项目，以及它们的不足之处

以下内容摘自各项目截至 2026-10-25 的公开介绍；它们是为不同任务设计的不同工具，其中一些可以互补。

相关项目	功能	Parley 的补充
MPAC（arXiv，2026 年 4 月）	让不同委托方的 Agent 基于共享状态进行协调：声明意图、处理结构化冲突、由人类仲裁	基于私有底线的决策规则：将红线写入代码、对经过掩码处理的裁决进行 max-min 计算，并在本地重放。MPAC 摘要未提及私有偏好、掩码处理或可验证的记录
Legal Context Protocol（美国仲裁协会及合作伙伴，2026-06-24 发布）	让法律条款、同意和争议解决在 Agent 交易时可被发现和验证	在发生争议前作出决策：LCP 涵盖条款和救济途径，Parley 则从多个选项中作出选择。两者互补
Acuerdio（西班牙）	在线调解平台；从邀请“另一方”开始；提供认证邀请函和 MASC 证书，按方收费（其网站标价 19 EUR）	让三位或更多所有者在各自设有私有底线的情况下参与，并提供每个人都能重新计算的记录。Parley 不颁发 MASC 证书，也不声称符合任何法律要求

状态：v0（核心功能可用）

纯标准库、零依赖核心。采用进程内传输，并留有清晰的接入点，下一步将接入 A2A （分布式发现 + 已签名的 Agent Cards）。基于大模型引导填写的偏好表单 （parley/elicit.py）和 Ed25519 签名记录（parley/net/identity.py，可选的 crypto extra）也已包含在内。这个 v0 刻意将新颖部分——共识与 不背叛机制——独立出来，并且不重复利用已经成为通用组件的功能。

python3 -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/pytest -q                     # the full suite, all green
# the money-shot: open http://127.0.0.1:8080 → Run
.venv/bin/python examples/demo/server.py
# three delegates pick a meeting slot
.venv/bin/python examples/meeting.py
# bots as separate processes, consensus over HTTP
.venv/bin/python examples/run_env.py
# run a real decision with real people, each one ratifies
.venv/bin/python examples/real_decision.py \
    --options examples/demo/recipe_committee.json

30 秒内了解

examples/demo/server.py 运行着一个网页背后的真实引擎： 彼此对立的各方、一个最大最小决策、一个被红线标记为 BLOCKED 的选项，以及一份可重新哈希验证的收据， 每一方都可以私下验证。这是一个完整的 P2P 托管争议实操示例，其中展示了每一方的“这样更好，因为……”，见 docs/dogfood-01-p2p-escrow.md （合成示例）。另一个是真实且匿名化的争议：对提前解除租约事件进行回顾性重放，租户认可了一个“这样本来会更好”的结果，见 docs/dogfood-02-early-lease-exit.md（如实说明边界：房东一方的立场是推断得出的，并未认可）。原生截图证明卡片位于 examples/demo/proofcard_p2p.html。

没有 Python？用 Docker 运行演示：

# then open http://127.0.0.1:8080
docker build -t parley . && docker run --rm -p 8080:8080 parley

在线试用：parleyprotocol.com/demo 运行着一个网页背后的真实引擎， 无需安装，也无需注册。更倾向于自托管？代码库附带 Dockerfile（以及 render.yaml Blueprint），只需一条命令，就能在任何地方运行同一个演示。

由 Agent 团队构建

产品旨在实现不同所有者的 Agent 之间的信任。它由一位所有者的 Agent 团队打造：它们负责规划、编写代码、相互审查，并在严格的关卡下发布；由人类指挥并把守不可逆的关卡（公开发布、外联），团队则负责工程实现。每项更改都要通过你也可以自行运行的同一关卡：scripts/ship-gate.sh，测试全部通过，核心零依赖，示例可运行，并遵守常规提交规范。

安全性（v0.1）

网络层已针对明显的攻击进行加固（参见 tests/test_redteam.py）：

• 签名裁决（Ed25519）。 每个机器人都会对其针对特定选项的裁决进行签名，将内容绑定到密钥。verify_transcript(require_signed=True) 随后会拒绝任何被篡改的裁决，或任何在预期应有签名时却未签名的裁决。范围（请阅读）： 此检查只能证明每个签名与该记录中携带的公钥在内部一致。它并不能证明其真实性，也就是不能证明该公钥确实是所有者的真实密钥，因为目前没有受信任的 owner → key 名册：组装对话记录的协调器可以替换成自己的密钥对。目前应将签名视为篡改证据，而不是可由第三方验证的身份凭证。
• 身份验证 + 速率限制 + 输入验证。 未提供 Bearer 令牌时，/consider 会返回 401；暴力枚举会受到限流（429）；过大或格式错误的请求体会被拒绝（413/400）。这弥补了偏好信息提取漏洞（未通过身份验证的攻击者此前可通过探测还原机器人的私有底线）。
• 结果验证。 verify_outcome(transcript)（位于 parley.consensus）会根据记录的裁决重新计算极小极大获胜选项，并检查结果是否与公布的决定一致，因此可以发现协调器最终选定了一个可行但非极小极大（或不可行）的选项。任何人都可以通过公开记录重放验证，无需私有表单。传入 expected_owners= 指定预期名册；否则，即使协调器在每条记录中都删去一个所有者，验证仍会通过。（verify_non_betrayal 仍只能证明你自己的底线得到遵守。）

尚未实现（v0.1 的实际限制，请勿将其视为可抵御恶意参与方的生产级安全方案）：

• 真实性固定验证：签名会根据自行声明的密钥进行验证，而非受信任的名册（见上文）；名册固定验证（根据每个机器人的发现 Agent Card 中的密钥进行验证）将在 v0.2 实现。目前只有协调器自身会固定验证：客户端会检查是否存在使用该 Card 密钥的签名；签名是否有效则由 verify_transcript(require_signed=True) 检查。examples/run_env.py 现在会运行此检查，其他调用方也必须运行。
• 重放绑定：裁决不包含会话或 nonce，因此签名裁决可以被重放到复用相同选项的其他协商中。
• 范围掩码分数：每个已接受选项的软基数 score 都会公开在对话记录中，因此不受信任的协调器可以推断这些选项之间的偏好排序；acceptable 标记也会显示各方的可行区域（被拒绝的选项始终报告分数 0；拒绝原因和私有表单仍会保密；MPC/范围掩码属于未来工作）。
• TLS/mTLS，以及博弈论层面的串通/策略性虚报抵御能力（研究方向）。

托管演示版 parleyprotocol.com 使用 GA4 进行基本流量分析——请参阅收集的数据。协议和可自托管的 docker run 路径不会收集任何数据。

钱从哪里来（开放核心论点）

共识机制本身是商品化的（投票／共识是免费的，例如 Snapshot、投票）。价值和付费意愿随着决策利害程度 × 参与方数量 × 对隐私／中立性／审计的需求而提升。付费层是可信的中立中介：托管身份／信任注册表、可用于审计的签名记录，以及托管式自托管服务，而不是算法。首批候选领域：私密的多方 B2B 谈判（采购／SOW）和可审计的委托治理（委员会、评审小组）。与 Fetch.ai / Olas 的差异（真实的先前方案：围绕账本和代币构建的 Agent 平台）：它们的页面没有描述红线或共识机制，而 Olas 是链上且基于代币；Parley 实现多方群体共识、可证明的不背叛、无加密货币，且可自托管。

演示展示了三个人，他们的 Agent 持有私密且相互冲突的约束条件，最终找到一个所有人的红线都允许的时间段；随后每位所有者都证明自己没有背叛。第二轮则会诚实地陷入僵局，而不是强行做出糟糕的决定。

架构

层	v0	下一步
传输／发现／身份	进程内	A2A（签名 Agent Cards、mDNS／注册表），复用，不要重建
Agent 大脑	纯代码，或 parley/elicit.py（LLM 起草，参与者确认）	更完善的需求征询体验
红线执行	parley/preferences.py（代码谓词）	核心；保持确定性
共识	parley/consensus.py（最大－最小）	纳什议价、加权规则
可验证性	parley/transcript.py（哈希 + 本地重放），可选 Ed25519 签名	范围掩码分数（MPC）
对抗性	不适用	拜占庭／串通抵抗能力，研究级贡献

路线图 → 开放核心

• **现在：**共识核心 + 红线防护 + 可验证记录（本仓库，Apache-2.0）。
• **下一步：**加入 A2A 传输，让运行在不同机器上的 Agent 能够相互发现，并通过局域网协商。 （LLM 征询生成的表单和 Ed25519 签名记录已随项目提供。）
• **研究：**注入一个撒谎／串通的 Agent，展示最大－最小 + 拜占庭鲁棒聚合能够抵御它。这部分可能会引起前沿 R&D 的兴趣。
• **付费（自托管）：**托管中继／信任注册表，让 Agent 能够在局域网之外安全会面， 并在你自己的硬件上托管 Agent。开源核心，付费联邦服务。

首个 ICP：一个封闭群体（团队／部门／家庭），由一位运营者部署所有 Agent，从而绕过网络冷启动效应。“将立场委托给你的 Agent，让 Agent 找到共同决定”正是这种场景。

贡献

核心刻意保持精简；目前最有价值的贡献是对抗性测试，以及对共识协议的第二意见。请从 CONTRIBUTING.md 开始，提交附有复现步骤的缺陷报告，或发起讨论。当前有六个小型的单文件任务（类型提示、测试、CI 检查），列在 适合新手的问题 下。 请通过 SECURITY.md 私下报告安全问题。

Star 历史

如果你觉得 Parley 可证明不背叛的方案很有意思，点个 Star 能帮助更多人发现它。

许可证

Apache-2.0，宽松许可，明确授予专利许可（便于通过企业法律审查）。请参阅 LICENSE + NOTICE。