Agentic AI 这个词近期被反复提及，但大多数讨论还停留在“单个智能体自主规划、调用工具、完成指令”。真正难的部分在后面：当系统里同时存在多个智能体、多个利益相关方、多套价值判断，Agentic AI 怎么协调这些不同视角？Socially Grounded Agentic AI（社会性 Agentic AI）要解决的就是这个问题。它不是一个具体的开源项目，而是一种设计思路：借用社会理论中的角色、规范、协商机制，让多视角共存时依然能产出可解释、可追溯、有约束的决策。下面这套拆解主要面向正在做多智能体系统、想做群体决策支持或组织级 LLM 应用的开发者和研究者。
1. 先搞清楚“社会性”在 Agentic AI 里到底解决什么问题
1.1 多智能体不等于社会性
过去一年里，我见过不少把多智能体理解成“多开几个大模型实例”的项目。做法通常是：给 A 模型一个角色，给 B 模型另一个角色，然后把 A 的输出塞给 B，再让 B 输出最终结果。这种设计能跑通，但它本质上是并行处理加流程拼接，不是社会性。
社会性的关键标志有四个：角色之间存在差异化；行为受到规范约束；智能体之间需要沟通协商；不同视角必须被显式保留，而不是被平均掉。如果只是工作流里的上下游，那叫流水线；只有当每个智能体都带有不可替代的视角，并能在分歧中通过协商形成决策时，才谈得上社会性。
1.2 社会性解决的是视角冲突，不是流程编排
流程编排解决的是“先做什么、再做什么”。例如先检索、再总结、最后生成报告。视角冲突解决的是“同一件事，不同的人、不同角色的价值判断不一样，该听谁的”。
举一个例子：城市更新方案评估。居民视角关心居住安全和补偿公平，政府视角关心公共安全和财政预算，企业视角关心商业回报。这三个视角不是谁对谁错，而是优先级不同、约束条件不同。传统 RAG 能做的只是把材料拼起来，工作流能决定的只是先调用哪个模型，真正缺少的是把三种视角放上谈判桌、经过协商得出一个平衡方案的能力。社会性 Agentic AI 要补的正是这一层。
1.3 谁适合关心这个方向
我把读者大致分成三类。第一类是已经在做多智能体产品的工程师，你会发现现有的 prompt 拼装方式处理简单任务够用，一旦涉及多方利益就失衡。第二类是做决策支持系统、政策模拟、组织管理工具的研究者，社会理论对你来说不是新概念，难点是怎么把它变成可运行的架构。第三类是看到 Agentic AI 概念但还不清楚从哪深入的人，可以先把它理解成“多视角协商系统”。
2. 从社会理论到系统设计：三个可以直接落地的概念
把社会理论落到代码里，不需要构建一个完整的社科模型。我建议先抓三个概念：角色与规范、协商与共识、多元视角的显式表示。这三个概念都有对应的工程实现方式。
2.1 角色与规范
角色规定了智能体在系统中的位置、能做什么、不能做什么。规范是限制行为的规则，相当于给智能体的活动空间画了边界。
工程上，角色体现为每个智能体的系统提示词和可用工具集合；规范体现为约束层，例如“该视角只能输出与居民利益相关的意见，不能替政府做预算决策”“所有提案必须附带证据来源”。实现方式可以是提示词约束，也可以是在生成之后加一道规则校验。
为什么要单独强调规范？因为不设规范，多个智能体很容易互相越界，最后所有智能体都在输出全知全能型建议，视角区分就失效了。我一般会先定义 5 条以内的硬性规范，写完让每个智能体对同一问题给出提案，看它们是否还能保持角色边界。
2.2 协商与共识机制
多视角协调的核心动作不是投票，而是协商。协商过程可以抽象成四步：提案、质询、修订、仲裁。
- 提案：每个视角基于自己的约束和证据给出方案。
- 质询：其他视角对方案提出质疑，指出遗漏、冲突和证据不足。
- 修订：提案方根据质询修改方案。
- 仲裁：如果几轮后仍有分歧，由仲裁机制决定最终方案。
共识机制需要提前选型。常见的有三种：全体一致、多数投票、权威仲裁。全体一致最理想但成本高；多数投票效率高但容易牺牲少数视角；权威仲裁适合有明确决策权归属的场景。实际系统里可以在不同层级混用，比如一般事项多数投票，涉及底线约束时启用权威仲裁。
2.3 多元视角的显式表示
最容易踩坑的是把多个视角塞进同一个 context，让大模型自己“综合”一下。这样做的结果是视角全部被平均成一段四平八稳的文本，丢失了冲突，也丢失了可追溯性。
正确的做法是给每个视角一个独立的数据结构，至少包含：视角名称、角色描述、价值权重、优先级、硬性约束、可用证据。协调过程中所有对视角的处理都基于这个结构进行，而不是让模型凭感觉判断。
3. 实际搭建时怎么做：一个最小可行的多视角协调架构
如果要实际落地，我不建议一上来就做重型框架。先搭一个最小系统，跑通之后再逐步加能力。
3.1 系统组成
一个最小系统至少包含四个模块：
- 视角注册表：登记所有参与协调的视角。
- 通信层：定义视角之间传递消息的格式。
- 协调引擎：执行提案、质询、修订、仲裁流程。
- 过程记录：保留完整协商记录，用于追溯和调优。
这四个模块缺一不可。很多人只做协调引擎，忽略视角注册表和过程记录，结果就是系统能跑，但无法解释，也调不动。
3.2 视角注册的数据结构
视角注册表是整个系统的基础。下面给一个简化示例，实际项目里可以根据业务增加字段。
{ "perspective_id": "resident", "name": "居民视角", "role": "代表受影响居民的居住权益与社区关系", "values": ["居住安全", "补偿公平", "社区连续性"], "priorities": ["居住安全", "补偿公平"], "constraints": [ "不替政府决定财政预算", "所有主张必须包含受影响范围说明" ], "evidence_sources": ["居民调研", "社区反馈记录"] }这段结构解决一个核心问题：视角的独立性不依赖模型，而依赖数据。只要这个数据结构存在，后续无论换模型、换参数，视角主张都能保持稳定。
3.3 协调引擎的流程
最小流程可以这样设计：
- 接收一个待决策问题。
- 从视角注册表加载所有相关视角。
- 每个视角独立生成初始提案。
- 所有视角对彼此提案进行质询。
- 根据质询意见，各视角生成修订版提案。
- 检查是否收敛。如果收敛则进入最终仲裁；如果未收敛且未达到最大轮数，回到第 4 步。
- 仲裁模块作出最终决策，并附上决策依据和少数视角保留意见。
这个流程我会拆成两个阶段。第一阶段先跑单轮协商，看每个视角的初始提案差异是否真实存在；第二阶段再加多轮修订。不要一上来就设置五轮协商，否则排查时根本分不清问题出在视角定义、模型回答还是协商逻辑。
3.4 伪代码示例
下面是一个协调引擎的示意伪代码，重点在流程，不在具体实现。
def coordinate(perspectives, question, max_rounds=3): proposals = {p.id: p.propose(question) for p in perspectives} for round_idx in range(max_rounds): critiques = cross_critique(perspectives, proposals) if is_converged(proposals, critiques): break proposals = { p.id: p.revise(question, critiques[p.id]) for p in perspectives } final_decision = arbitrate(perspectives, proposals) return { "decision": final_decision, "proposals": proposals, "critiques": critiques, "minority_opinions": collect_minority(proposals, final_decision) }注意这里的cross_critique、arbitrate需要根据业务定义。我是把质询和仲裁设计成独立模块，避免所有逻辑都堆在提示词里。模型负责生成内容，流程负责控制过程，两者解耦后更容易排查问题。
4. 关键参数和判断标准：不要只看结果，要看过程质量
搭建阶段最常犯的错误是只盯着最终决策好不好看。多视角协调系统真正要评估的是过程质量，包括视角覆盖率、分歧保留程度、决策可追溯性、协商成本。
4.1 核心参数
下面这些参数是我在调试时会优先关注的：
| 参数 | 含义 | 建议起始值 | 调整方向 |
|---|---|---|---|
| 视角数量 | 参与协调的独立视角个数 | 2 到 3 个 | 场景复杂时可以增加，但超过 7 个协调成本会明显上升 |
| 最大协商轮数 | 提案和修订最多进行几轮 | 2 轮 | 分歧大时增加；结果总是不收敛时优先检查仲裁逻辑 |
| 收敛阈值 | 判断提案是否足够接近 | 按文本相似度或关键字段一致率 | 阈值太松会导致过早收敛，太紧会导致轮数耗尽 |
| 仲裁模式 | 多数投票、全体一致、权威仲裁 | 多数投票 | 底线场景切换为权威仲裁 |
| 温度系数 | 模型输出的随机性 | 提案阶段低，质询阶段高 | 提案需要稳定，质询需要找漏洞 |
4.2 判断标准
我给每个标准写一个可判断的问题。
- 视角覆盖率：最终决策里是否明确提到了每个视角关心的核心利益？
- 分歧保留程度：被否决的少数视角意见是否被单独记录，而不是直接消失？
- 可追溯性：看到最终决策时，能不能说清是哪个视角提出、哪个视角反对、依据是什么？
- 协商成本：完整流程消耗的 token、轮数、耗时是否在可接受范围内？
这四个标准建议做成自动检查项，每次跑完任务直接输出，不要人工逐条看。
4.3 三种方案对比
如果要判断自己的项目是否真的需要社会性协调，可以先做一次对比：
| 方案 | 适合场景 | 优势 | 局限 |
|---|---|---|---|
| 单智能体 | 目标明确、无重大利益冲突 | 快、省 token | 无法处理多方视角 |
| 多智能体流水线 | 任务可拆、步骤清晰 | 并行、结构清晰 | 没有协商，视角被流程掩盖 |
| 社会性协调 | 多方利益、价值冲突、需要解释 | 可追溯、保留分歧 | 成本高、延迟大、调试复杂 |
如果你的系统可以靠前两种方案解决，没必要上社会性协调。这个方向的价值体现在复杂决策场景，不是为了炫技而加的。
5. 三个典型故障：群体趋同、协商死循环、效果倒退
5.1 故障一：所有视角的输出都趋同
现象是注册了三个视角，但最终提案长得都一样。这种问题在技术上叫群体思维，在多智能体系统中非常普遍。
先检查视角定义是否真的独立。很多项目把视角数据放在同一个 prompt 里，所有 agent 共享同一个上下文、同一份证据，那输出当然趋同。其次检查质询阶段是不是形同虚设。我会把每个视角的初始提案单独打印出来，看它们在进入协商之前是否有差异。如果初始提案就没差异，问题出在视角注册或提示词；如果初始有差异但协商后趋同，问题出在质询和修订逻辑。
5.2 故障二：协商陷入循环，无法收敛
现象是轮数耗尽，所有视角还在反复质疑同一个点。
这种情况通常不是模型问题，而是缺少终止条件或仲裁机制。检查一下是不是max_rounds设置得过大，检查收敛判断逻辑是否真的能识别“意见已经不再变化”。还有一个很常见的原因是质询信息没有结构化，每个视角收到的是整段含糊反馈，修订时不知道该改哪里。解决方法是把质询输出为结构化清单，例如“反对点、缺失证据、修改建议”三个字段分别列出。
5.3 故障三：协调后的结果比单智能体还差
这种情况最容易让人怀疑方向选错了。我会按下面顺序排查：先确认每个视角是否真的带来了增量信息；再看协商过程是不是把有效信息弄丢了；最后看仲裁逻辑是不是选错了方案。
一个容易忽略的边界是：视角越多，并不代表信息越丰富。如果注册了五个视角，但其中三个都向同一个数据源要证据，那它们本质上是一个视角的三个分身。
5.4 通用排查顺序
遇到问题时，不要急着改参数。我的固定排查顺序是：
- 先看视角注册：每个视角的数据结构是否独立、约束是否有效。
- 再看初始提案：协商前的输出差异是否真实反映视角差异。
- 再看协商记录：质询是否结构化、修订是否回应了质询。
- 再看仲裁逻辑：最终决策依据是否可解释。
- 最后才看模型和参数：温度、轮数、上下文长度。
这个顺序的核心想法是：流程问题优先于模型问题。大多数协调异常都不是模型能力不足，而是流程里的信息结构不完整。
6. 边界与展望：社会性 Agentic AI 能做什么、不能做什么
6.1 适用边界
我自己的判断是，社会性 Agentic AI 适合以下场景：决策结果需要多方认可；决策依据需要向外部解释；视角之间确实存在结构性差异；系统有足够的时间和 token 预算。
不适合的场景也很明确：响应速度要求极高的自动任务、目标单一且没有实质冲突的流程、低成本的轻量功能。如果一个任务用规则引擎就能做，不要为了概念引入协商机制。
6.2 成本与效率
这个方向的成本是真实存在的。每增加一个视角，每增加一轮协商，都会带来 token 和延迟的增长。在工程上需要考虑缓存策略、并行质询、提前终止条件。
一种常见的降本方式是分层处理：先用低成本模型做快速提案，只有出现明显分歧时才调用更强模型做质询和仲裁。另一种方式是知识隔离，让每个视角只加载自己需要的那部分证据，而不是把全部资料塞进所有视角的上下文。
6.3 给实践者的建议
如果只能带走一条建议，我会说：先把视角数据结构做好，再写协商流程。视角注册表是整个系统的地基，地基不稳，后面所有模块都无从谈起。
另外，日志一定要完整。协商过程的每一步都应该被记录下来，包括每个视角看到了什么证据、提出了什么提案、被谁反对、如何修订。没有这个过程记录，你无法调优，也无法回答“为什么做出这个决策”这类问题。
真正落地的时候，最该盯住的不是模型又提升了多少，而是视角是否真实、协商是否有效、决策是否可解释。这三点做到位，Socially Grounded Agentic AI 才不只是一个学术概念，而是一个能真正支撑多方决策的系统设计方法。
