32.4k 星里的”会议式协作”
多智能体（multi-agent）这个词在 2024 到 2025 被各种公司滥用过——很多产品本质上只是按顺序调用几次 LLM，远没到协作的程度。multica-ai/multica 这周冲到 32.4k 星，因为它把协作这件事做成了一个真正可用的开源平台。仓库的核心定位是把多个 AI agent 当成一个团队，每个 agent 有明确的角色、能力边界和协作规则。
问题：单 agent 在跨领域任务上吃不消
Multica 解决的具体问题是这样：当你想让 AI 完成一个跨越多个领域的任务（比如调研一个市场、写一份产品 PRD、设计 UI、实现原型代码），单个 agent 拿一个 prompt 走到底效果很差——上下文越来越长、目标越来越模糊。把任务拆成多个 agent（市场调研 agent、产品经理 agent、设计 agent、工程师 agent）协作，每个 agent 负责一个清晰的环节，结果质量会显著提升。这件事 AutoGPT、CrewAI、AutoGen 都尝试过，但现有方案的协作机制要么太简单（轮流执行），要么太复杂（需要写一堆 YAML 配置）。
Facilitator 调度 + 会议式发言
Multica 的设计选择是把协作的核心做成会议式。每个 agent 进入一个共享的工作空间，可以像在 Slack 频道里一样互相讨论、提问、push back。一个调度 agent（Multica 叫它 Facilitator）负责管理会议节奏：什么时候让谁发言、什么时候投票决定方向、什么时候宣布任务完成。这种机制比图状工作流更接近人类团队的实际工作方式，对开发者来说也更直观——你不需要画 DAG，你只需要给每个 agent 一段角色描述。
项目维护者团队 multica-ai 在 README 里解释了这个设计选择的来源：”我们试过 DAG 和事件总线两种方案，最后发现写代码的开发者宁愿写自然语言角色卡也不愿意维护一张越来越复杂的拓扑图。会议式调度是给程序员的而不是给 BPM 工程师的。” Anthropic 应用研究员 Erik Schluntz（Claude agent SDK 作者之一）在 X 上转发评论：”会议式调度比 DAG 更贴近团队真实工作流，这是 Multica 把入门门槛拉低的关键决定。”
开箱示例与模型混搭
仓库里给的几个开箱示例很有说服力。一个示例是 3 人产品团队：Product Manager、Designer、Engineer 三个 agent 协作完成一个 todo 应用的从需求到代码的全流程。另一个示例是研究小组：4 个研究员 agent 分工调研某个学术领域，每个人负责一类文献，最后汇总写综述。第三个示例是代码审查团队：5 个 agent 各自从安全、性能、可读性、测试覆盖、架构合理性的角度审查同一段代码，给出互相冲突时的最终决议。
底层模型层面，Multica 是模型无关的。它支持 OpenAI、Anthropic、Google、本地 Ollama、各种 OpenAI 兼容的 API。你可以让不同 agent 使用不同模型——比如让工程师用 Claude（代码强），研究员用 GPT-5（搜索强），设计师用 Gemini（视觉强）。这种混搭在大模型实际能力差异化的当下是个实在的优势。Multica 内置的成本仪表盘会按 agent 拆账单，让用户能直观看到每个角色花了多少 token。
从 AutoGen 迁过来的中立阵地
32.4k 星里的不少贡献者是从 AutoGen 迁过来的。AutoGen 早期是这个赛道的标杆，但它后来的版本被微软主导，开源社区的不满累积了一段时间。Multica 占了开源中立、API 友好、文档齐全的位置，迁移成本比预期低——README 里专门有一节讲怎么从 AutoGen/CrewAI 迁过来。AutoGen 早期核心成员之一 Chi Wang 在 X 上提到：”Multica 把我们当年想做但没做完的会议式协作落了地，这是开源社区的胜利。”
可靠性还差最后一公里
对实际想用多 agent 的开发者，Multica 在 2026 年 5 月这个节点是优先级最高的几个选项之一。它还不是终极解法——多 agent 系统的可靠性、成本控制、调试体验都还有大量空间——但它把入门门槛拉低到了一个周末就能上手的程度。多 agent 接下来要解决的不再是怎么协作，而是当 agent 之间出现循环讨论、彼此误判、共识难产的时候怎么 graceful degrade。Multica 已经在 issue 区开了一个 reliability 标签专门收这类问题，这是值得盯的下一步。
参考：GitHub 仓库
