多方AI调解实验：只记录双方共识事实的中立Agent

从一对一对话到多方调解

大多数AI聊天工具都是为一对一交互设计的。你输入提示词，模型给出答案，交互到此为止。而一位开发者在周末尝试了一个截然不同的方向——多方纠纷调解。

这个实验的核心设置是：两个存在实际争议的人（比如押金纠纷、自由职业者的工作范围蔓延，或是谁来养共同宠物）进入一个群聊，由一个AI调解者来引导整场对话。这打破了传统AI应用的单向交互模式，把大语言模型放进了一个多方博弈的真实场景中。

只记录"双方都认可"的事实

这个实验最关键的约束设计在于"事实"的处理逻辑。调解Agent拥有把已确认事实记录到共享白板上的工具，但它被严格限制：除非双方在聊天中明确确认，或有人提供收据、签署合同这类具体证据，否则任何内容都不能被记录为事实。

换句话说，如果一方声称某件事，而另一方提出异议，这条信息就无法进入事实白板。这个设计直击调解场景的痛点——争议双方往往对"发生了什么"各执一词，而一个中立的记录者只固化双方共识，能有效避免AI被单方叙事带偏，也降低了模型"编造"或偏袒的风险。

从共识出发的调解逻辑

除了事实约束，这个Agent还承担了引导对话的职能。它会倾听双方陈述，把带有敌意的言辞重新表述为背后的真实诉求，并尝试从已有的共同点向外扩展，再提出折中方案。

这套逻辑其实借鉴了人类专业调解中的"基于利益的谈判"思路——不纠缠于立场对抗，而是挖掘立场背后的利益，从共识地带逐步搭建解决方案。让LLM来扮演这个角色，是对模型情商与推理能力的一次真实考验。

一个值得关注的细节是：聊天室在双方都进入之前会保持锁定状态，防止一方在另一方到场前进行单方面的情绪宣泄。这个看似简单的机制，实际上是在为对话营造一个更对等的起点。

「基于利益的谈判」（Interest-Based Negotiation）源自哈佛谈判项目，由Fisher与Ury在1981年的著作《Getting to Yes》中系统阐述。其核心区分了「立场」（position）与「利益」（interest）：立场是当事人明确表达的要求（"我要全额退款"），利益则是驱动这一要求的深层需求（"我担心被欺骗、需要被尊重"）。传统谈判常陷入立场对抗的零和博弈，而基于利益的方法试图找到满足双方深层需求的创造性方案。在人类调解实践中，这需要调解员具备高度的倾听技巧与情绪管理能力。将这一框架交由LLM执行，理论上有其优势——模型不会被情绪激怒，能持续保持中立表述——但也面临局限：模型可能误判当事人的"真实利益"，或将复杂情感需求简化为可协商的条件清单。

技术实现

从技术栈来看，这个实验运行在部署于 Deno Deploy 的 Next.js 之上，数据层由 InstantDB 支撑，加密群组传输则通过 prompt2bot 以及 Alice and Bot 实现。整体是一套偏向快速验证的现代 Web 技术组合，适合这种周末原型级别的探索。

开发者本人明确表示，这只是一个实验，目的在于观察两点：一是LLM如何处理人际摩擦，二是人们究竟会觉得一个自动化的中立方是有帮助的，还是令人反感的。

Deno Deploy 是基于 Deno 运行时的边缘计算平台，与传统 Node.js 服务器不同，它将代码部署到全球分布的边缘节点，以降低延迟。Next.js 运行于 Deno Deploy 之上意味着这套系统具备较低的冷启动时间，适合实时聊天类应用。InstantDB 是一个面向实时协作场景的客户端数据库，内置同步与权限控制，无需手动搭建 WebSocket 层，这解释了为何此类周末原型能快速实现多方实时消息同步。这套技术组合的选型逻辑清晰：边缘计算保证响应速度，实时数据库简化多方状态同步，而非为生产级可靠性或合规性做优化——与作者"快速验证"的实验定位高度吻合。

它可能在哪里失效？

这个方向抛出了一个耐人寻味的问题：你会信任AI来调解你和另一个人之间的纠纷吗？

从设计上看，"只记录共识事实"确实规避了AI主观臆断的风险，但真实纠纷远比事实记录复杂。当双方对基本事实都无法达成一致时，事实白板可能长期空白，调解也就无从展开。此外，情绪化的当事人是否愿意接受一个机器的"重新表述"，是否会觉得被冒犯或被操控，都是这类产品落地的现实障碍。

信任问题则更为根本——法律、财产、亲密关系中的争议往往涉及高利害，人们对AI中立性的怀疑、对隐私的顾虑，都可能成为采用的阻力。

不过，作为一次探索LLM社会化应用边界的实验，它的价值在于把AI从"回答问题的工具"推向了"协调人际关系的参与者"。这个方向即便充满不确定性，也为AI Agent的应用场景打开了一扇新的窗口。