synod-council

Synod

两个 AI Agent 之间持久、对等的审议——支持隔离的 git 工作树、同行评审、自动验证和明确的审批工作流。

Synod 最初是个人 AI 基础设施中的“议事会”，两个自主 Agent（一个编排者和一个执行者）需要共同做出真正的决策并进行真正的代码更改，同时避免其中一方悄然沦为另一方的唯命是从者。

为什么

大多数多 Agent 框架都只是编排表演：一个 Agent 把另一个当作工具调用，然后把输出称为“协作”。Synod 基于另一种前提构建——两个 Agent 在设计上彼此平等：

• 对等协议——任一 Agent 都可以发起审议；协议不偏向任何一方。
• 身份约定——每条提示词都会重新明确 Agent 的身份，因此能力较弱或注意力不集中的模型不会偏离身份，开始以同伴的身份作答。
• 抗偏见综合——每个问题的综合者由问题文本的哈希值决定，而不是由谁先发言决定。
• 持久状态——每次会话都存储在 SQLite 中，并具有明确的阶段（plan、review、synthesize、ratify……）。运行崩溃后会留下可检查的记录，而不是一团谜。
• 通过工作树提交代码更改——每次会话都有自己的 git 工作树和分支。Agent 绝不会推送到 main；从“看起来完成了”到“正式发布”之间设有面向人工的审批步骤。
• 带修复流程的验证——实现完成后运行检查；如果失败，会在有限重试次数内退回给负责实现的 Agent，之后才会交由人工查看。

安装

pipx install synod-council

或从源代码安装：

git clone https://github.com/naruminho/synod-council
cd synod && pip install .

用法

库

from synod.deliberation import Deliberator, Store, HTTPAdapter

adapters = {
    "Alice": HTTPAdapter("Alice", "http://127.0.0.1:9001/ask"),
    "Bob":   HTTPAdapter("Bob",   "http://127.0.0.1:9002/ask"),
}
synod = Deliberator(adapters, Store("council.db"))
result = synod.run("Should we use SQLite or Postgres for this workload?", initiator="Alice")
print(result.decision, result.confidence, result.status)  # consensus | reconciled

MCP 服务

Synod 提供 MCP 服务，任何支持 MCP 的客户端（Claude Desktop、Claude Code、Cursor 等）都可以据此发起审议：

synod-mcp   # stdio transport

将其添加到客户端配置中，然后让 Agent 进行审议，而不是猜测。

HTTP 服务

synod-server --port 8790
curl -X POST http://127.0.0.1:8790/run -d '{"problem": "...", "initiator": "Alice"}'

审议流程

plan (parallel) → cross-review (parallel) → synthesis → [ratification → reconciliation?]

如果评审者提出尚未解决的阻碍，或置信度低于 0.7，候选决策就会交由未负责综合的同伴批准；如果遭到拒绝，则必须进行明确的协调，而不能默默达成共识。

状态

该项目从一套生产级个人基础设施中提取并经过实战检验，自 2026 年起一直用于确定架构和交付代码。双 Agent 设计是有意为之；支持 N 个参与者已列入路线图。

许可证

MIT