Synod Council

io.github.naruminho由 GitHub 账号 naruminho 发布v0.2.0更新于 Oct 24, 2026

Durable symmetric deliberation between two AI agents, with isolated worktrees and peer review.

已验证STDIO仅桌面开发者工具AI 与机器学习

概览

AI 生成的概览

让两个 AI 代理进行持久、对等的审议,包含同行评审、验证与 git worktree 隔离。

可以做什么
Synod Council 提供一个 MCP 服务器,用于在两个对等 AI 代理之间启动结构化审议。会话按 plan、cross-review、synthesis、ratification、reconciliation 等明确阶段推进,状态保存在 SQLite 中,因此崩溃的运行会留下可检查的痕迹。每个会话拥有自己的 git worktree 和分支,实现后会运行验证检查并带有有界重试。综合者由问题文本的哈希决定,而不是由谁先发言决定。
适用场景
当两个代理需要共同做出真实决策或代码改动,且不希望其中一个沦为另一个的橡皮图章时使用。它适合需要经过同行评审和审批步骤后才发布的架构决策与代码改动。
运行要求
作为本地 stdio 进程运行,可通过 pipx 或从源码安装,因此需要 Python 和 git。每个参与的代理必须能通过适配器访问,例如 这样的 HTTP 端点。未声明任何账户、API 密钥或环境变量。
安装前请注意
代理会在各自的 git worktree 和分支中进行真实代码改动;README 说明代理从不推送到 main,并且在“完成”与“发布”之间有面向人工的审批步骤,请保留该审批。审议状态存储在 SQLite 中,HTTP 服务器示例绑定到本地端口。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Synod Council,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

Synod

Durable, symmetric deliberation between two AI agents — with isolated git worktrees, peer review, automated validation, and an explicit approval workflow.

Synod started life as the "council" inside a personal AI infrastructure where two autonomous agents (an orchestrator and an executor) needed to make real decisions and real code changes together — without one of them silently becoming the other's rubber stamp.

Why

Most multi-agent frameworks are orchestration theater: one agent calls another as a tool and calls the output "collaboration". Synod is built around a different premise — two agents that are peers by construction:

  • Symmetric protocol — either agent can initiate; the protocol has no privileged side.
  • Identity contract — every prompt re-establishes who the agent is, so a weak or distracted model can't drift into answering as its peer.
  • Bias-resistant synthesis — the synthesizer for each problem is chosen by hashing the problem text, not by who spoke first.
  • Durable state — every session lives in SQLite with explicit stages (plan, review, synthesize, ratify, ...). A crashed run leaves an inspectable trail, not a mystery.
  • Code changes land through worktrees — each session gets its own git worktree and branch. Agents never push to main; a human-facing approval step stands between "looks done" and "published".
  • Validation with remediation — checks run after implementation, failures go back to the implementing agent with bounded retries before a human ever sees it.

Install

bash
pipx install synod-council

Or from source:

bash
git clone https://github.com/naruminho/synod-councilcd synod && pip install .

Usage

Library

python
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 server

Synod ships an MCP server so any MCP-capable client (Claude Desktop, Claude Code, Cursor, ...) can start a deliberation:

synod-mcp   # stdio transport

Add it to your client config and ask your agents to deliberate instead of guessing.

HTTP server

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

How a deliberation flows

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

If reviewers raise unresolved blockers, or confidence lands below 0.7, the candidate decision goes to ratification by the non-synthesizing peer; a rejection forces explicit reconciliation instead of silent consensus.

Status

Extracted and battle-tested from a production personal infrastructure where it has been deciding architecture and shipping code since 2026. The two-agent design is intentional; N-participant support is on the roadmap.

License

MIT

来源:README.md,提交 eb2f2e3

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v0.2.0最新Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分