2026-10-10 「开源之道」·论文略读：开源 LLM 多 Agent 系统的实践问题库——agent 时代开源治理的第一份诊断
论文信息
| 字段 | 内容 |
|---|---|
| 标题 | Understanding Issues, Causes and Solutions in Open-Source LLM-based Multi-Agent Systems |
| 作者 | Asad Ur Rehman, Syed Mohammad Kashif, Ruiyin Li, Peng Liang, Zengyang Li, Arif Ali Khan（6 位合著） |
| 年份 | 2026-10（arXiv 2610.00905v1，2026-10-01） |
| 平台 | arXiv preprint（cs.SE, cs.AI） |
| 链接 | arXiv:2610.00905 |
| 样本规模 | 22,848 closed issues × 21 开源 LLM-based MAS 项目，过滤后 944 个 MAS 相关 issues |
| 方法论 | Mixed automated + manual filtering（自动预筛 + 人工验证） |
一句话推荐
开源 MAS 治理命题的第一份"诊断式"实证——把过去二十几年开源治理文献里几乎空白的"实践者经验"层，用 22,848 closed issues 的量化诊断补齐；Ostrom 八原则在这个场景全部未制度化，是"治理真空第 0 层"——连边界都不存在。
内容概要
论文的核心方法学是把实践者经验从合成研究里剥离出来：
- 样本：21 个开源 LLM-based MAS 项目的 22,848 个已关闭 issue，过滤后留下 944 个与 MAS 直接相关的问题
- 问题类别：Orchestration & Execution Issue 主导——agent 之间的任务分配、执行调度、错误恢复机制都存在系统性问题
- 三大成因：Workflow Problem + Tool Integration Problem + Memory Problem
- 主导解决方案：Optimize Workflow——其他方案（增加工具、改进记忆、调整编排逻辑）都是次优的
944 个 issue → 三类成因 → 一种主导解决方案——这种高度收敛的结论意味着开源 MAS 的治理问题不是"多问题多方案"而是"单方案主导"。
为什么值得读
“实践者研究"作为"制度性贡献"的第一份样本
过去关于 LLM-based MAS 的讨论都在**“实验室内的合成研究”——设计特定场景、评估特定任务、比较特定模型。“开源项目采用 MAS 作为核心架构后，实践者面对的具体问题、成因、解决方案"几乎空白**。
本文是**“实践者研究"作为"制度性贡献"的第一份样本**——它不是理论、不是设计，而是**“制度诊断”：把开源社区在真实使用中积累的 22,848 issues 系统化整理为“问题—成因—解决方案"三层结构**，为治理设计提供经验输入。
这与过去 30 年开源治理文献的主线形成方法学对照：从"设计更好的 governance 文档”（#164 Noori GOVERNANCE.md）、“提出治理参考架构”（#168 UPA）这些自上而下的路径，转到"先看清问题再谈治理"的自下而上路径——两条路径需要同时存在。
过滤率 4.1% 这个反直觉发现
22,848 → 944 的过滤率仅 4.1%——绝大部分 issues 与 MAS 无关，是**“通用软件工程问题”**。
这个反直觉发现本身就是重要发现：开源 MAS 项目的主要问题是"通用软件工程问题"而非"MAS 特有问题”——治理设计的对象需要重新界定。过去 wiki 收录的 agent 治理研究（#186 Kuerbis & Ghosh harness 治理、#188 多 agent 授权链、#189 piece-rate 劳动力、#190 验证瓶颈）都在假设"MAS 有独特治理问题”，本文用 4.1% 这个数字提示我们：在真正进入 MAS 层之前，先把通用软件工程问题（贡献完成、review 停滞、依赖退役）治理好，可能是更基础的动作。
为什么对开源社区如此重要
Ostrom 八原则在开源 MAS 场景的系统性缺位
对照 Ostrom 1990《Governing the Commons》的八条设计原则：
| 原则 | 开源 MAS 状态 |
|---|---|
| 1. 边界界定 | 未明确——agent 之间的责任边界、错误责任归属、决策权分配都未制度化 |
| 2. 集体选择安排 | 未明确——谁决定 workflow 设计、谁决定 tool 选择、谁决定 memory 策略 |
| 3. 监控 | 未明确——agent 之间的行为可观察性、错误可追溯性都缺位 |
| 4. 分级制裁 | 未明确——agent 错误、workflow 失败的责任如何分级 |
| 5. 冲突解决 | 未明确——agent 之间的协调失败、workflow 循环依赖如何解决 |
| 6. 认可治理权 | 未明确——agent 治理的主体是谁（framework maintainer？项目开发者？agent 本身？） |
| 7. 分层治理 | 部分存在——framework 层 vs project 层 vs agent 层，但边界模糊 |
| 8. 边界与决策权匹配 | 未明确——agent 决策权与 agent 能力边界的匹配度 |
Ostrom 八原则在开源 MAS 场景的系统性缺位——不是"部分失效"而是"全部未制度化”。这是**“治理真空第 0 层”**——连边界都不存在，无法讨论边界内的治理。
与 #185 Miller Community Notes 的对比尤其锋利：Miller 用 AI Note Writer + Rating API + 开放数据三项制度设计动作同时命中 Ostrom 八原则全部八条——是正面样本；本文揭示开源 MAS 场景下八原则全部未制度化——是负面样本。同一治理命题，两种截然不同的现状。
Coase 1937《企业的性质》命题在开源 MAS 场景的版本
“agent 团队"作为开源项目的"内部结构"如何界定：
- 单个 agent 的行为是"内部协调”，agent 之间的协作是"内部协调成本"
- Orchestration & Execution 问题 = Coase 意义上的"内部协调成本"在 agent 时代的量化表达
- Workflow 优化作为主导解决方案 = Coase 命题的开源 MAS 版本：内部协调成本高的时候，“设计更好的协调机制”（optimize workflow）是最优策略
Coase 命题的 agent 时代版本——企业为什么存在（vs 市场化）？Coase 的回答是内部协调成本 vs 市场交易成本。在 agent 场景：agent 团队作为开源项目内部的"协调单元"，其内部协调成本（Orchestration & Execution 问题）是决定项目治理效率的核心变量。
Williamson L3 治理机制层的最新诊断
Williamson 交易成本经济学 L3 治理机制层在开源 MAS 场景的第一份诊断：
- Orchestration & Execution 问题主导 → L3 治理机制 = workflow 编排治理（当前主要治理对象）
- 三大成因（Workflow + Tool + Memory）的量化比例 → L3 治理机制需要覆盖三个子层
- Optimize Workflow 单一主导解决方案 → L3 治理机制的核心干预点是 workflow 设计，不是 agent 本身也不是 tool 选择
Williamson L3 治理机制层的独立子层扩展——开源四层制度基础设施第七层（协作范式转变，Ye & Zhou 09-27）进一步细化为**“agent 协作问题库层”**——治理对象从"贡献协作"扩展到"agent 协作"，治理机制从"PR review + CI + maintainer"扩展到"workflow 设计 + tool 集成 + memory 策略"。
关联阅读
与 #185 Miller Community Notes 的正反样本对话
#185 Miller 用 AI Note Writer + Rating API + 开放数据三项制度设计动作同时命中 Ostrom 八原则全部八条（正面样本）；本文揭示开源 MAS 场景下八原则全部未制度化（负面样本）。同一治理命题的两种截然不同现状——Ostrom 八原则不是自动落地的，是设计出来的。
与 #180 Canale DGF-Bench 的"诊断—审计"完整证据链
#180 Canale DGF-Bench 用形式化 benchmark 度量 AI agent 治理审计，本文用经验数据诊断开源 MAS 实践问题。#180 是"事后审计"，本文是"事前诊断"——两者构成开源 MAS 治理的**“诊断—审计"完整证据链**：先诊断问题（本文），再审计治理机制（#180）。
与 #179 Takerngsaksiri Who Finishes the Job 的对照
#179 Takerngsaksiri 研究"AI agent PR 的责任归属”（合并后谁修复），本文研究"开源 MAS 的实践问题"（开发中使用什么出了问题）。同一 agent 时代，两个治理对象——agent PR 的责任归属 vs MAS 项目的实践问题。
Williamson L3 治理机制层的两个子层——#179 是"agent 治理"子层，本文是"MAS 协作"子层。两者的治理机制都需要重新设计，但诊断方法不同：#179 用对称大样本（agent PR vs human PR），本文用问题库过滤（22,848 → 944）。
与 #162 Xiong OpenClaw 6 万 skill 生态的对照
#162 Xiong 揭示"agent skill 生态"的制度真空（77.86% 零 star 零评论），本文揭示"开源 MAS 实践"的诊断输入（944 个已过滤问题）。两者共同指向"agent 治理生态"的第三维度——skill 层（#162）+ MAS 层（本文）+ agent 治理审计（#180）——开源四层制度基础设施第五层扩展的三个子层。
与 #155 Samar Ansari 推理时治理分类学的对照
#155 Samar Ansari 用分类学方法（20 机制 × 3 治理目标 × 4 厂商证据）设计 AI 治理的分类框架，本文用经验诊断方法（22,848 issues × 21 项目 → 944 filtered）设计开源 MAS 的问题框架。同一治理层问题，两条方法论路径——分类学（Samar）+ 诊断学（本文）。
与 #157 Zhang-Zhang-Sun Layer Attribution 的方法论互补
#157 Zhang-Zhang-Sun 提出"层次归因"作为治理合法化前置环节（不先归因则无干预），本文提供"开源 MAS 实践问题"的具体归因对象（Orchestration & Execution 是核心问题类别）。方法论互补——Zhang-Zhang-Sun 回答"归因怎么做"（层次归因），本文回答"归因归到什么"（三大问题类别 + 三大成因 + 一种主导解决方案）。
延伸思考
适兕"制度怎么设计"框架的第一动作
适兕"制度怎么设计"框架——问题不是"批判制度"而是"设计制度"。
在开源 MAS 场景：
- 问题不是"LLM 太弱"（这是模型层问题，开源社区无法影响）
- 问题不是"framework 太差"（这是开源项目自身的问题，但"更好"的定义权在哪里）
- 问题是"开源 MAS 缺少治理机制"——没有 workflow 设计的最佳实践、没有 tool 集成的标准接口、没有 memory 策略的社区共识
制度设计的第一动作——先做诊断（本文），再做设计：
- L1 社会嵌入层：实践者对 MAS 的问题理解是治理设计的思想源头
- L2 制度环境层：当前开源社区对 MAS 治理无统一标准（各 framework 独立演化）
- L3 治理机制层：建立"workflow 设计"的开源社区共识（问题数据支持的核心干预点）
- L4 资源配置层：为 workflow 优化配置开源社区的治理资源（documentation、tooling、community）
“实践者研究"作为"制度性贡献"这个命题本身是开源四层制度基础设施第七层扩展的最锋利样本——治理设计的第一动作不是设计更好的规则，是先诊断问题。
适兕"思想是制度的源代码"命题的 AI 时代最新版本
适兕"思想是制度的源代码"命题——“仁者心动"是制度演化的最终源头，思想变化先于制度变化，制度是思想的编码。
在开源 MAS 场景：
- 实践者的"问题库"是治理思想的源代码——22,848 issues 背后的实践者反思是"治理思想"的原始输入
- 治理设计的第一动作是"先诊断，再设计”——不是"设计更好的 agent framework"而是"先理解实践者面对的什么问题”
- 问题库的"高度收敛"（三类成因 → 一种主导解决方案） = 治理思想的"收敛方向"已经被实践数据锁定
适兕"行动的定义权"命题的 MAS 场景延伸——“什么算好的 MAS 实践"的定义权正在从"学术论文”（合成研究）转移到"开源社区实践者"（真实使用）。本文是这一"定义权转移"的第一份实证。
三个尚未回答的追问
- 过滤率 4.1% 意味着什么？ 如果 95.9% 的问题都是"通用软件工程"，那 MAS 治理的"独特性"究竟在哪里？“独特问题"是否只是一个规模较小的边缘现象？
- “Optimize Workflow"是否只是"更好设计 workflow"的一种修辞？ 如果 workflow 就是"agent 之间的协作协议”，那这个"最优"是不是就是"更清晰的 Ostrom 第 2 条集体选择安排”？
- 实践者问题的定义权是否稳定？ 如果三个月后 GitHub Copilot Chat、CrewAI 生态、LangGraph 各自演化出自己的问题词汇表，那"诊断"是不是也会随之分裂？
局限与追踪
- 样本是"closed issues"——只包含已关闭的问题，未包含"未解决"或"仍 open"的问题；“未解决问题"可能是更难治理的长尾，需要独立样本
- 22,848 → 944 的过滤率仅 4.1%——绝大部分 issues 与 MAS 无关，是"通用软件工程问题”；这本身就是重要发现：开源 MAS 项目的主要问题是"通用软件工程问题"而非"MAS 特有问题"——治理设计的对象需要重新界定
- 944 个 issues 覆盖 21 个项目——单项目平均 45 个 MAS 相关 issues，样本量偏小；需要在更多项目上验证
- “Optimize Workflow 单一主导解决方案”——高度收敛的结论意味着方法论可能过度压缩了问题的复杂性；实际开源 MAS 治理可能比"单一主导"更复杂
- 未涉及治理机制本身——本文只诊断"实践问题"，不诊断"治理机制"；需要与治理机制实证（如 #180 Canale DGF-Bench、#172 Canale Last Human Gate）配合形成完整证据链
- 未涉及中国本土开源 MAS——本文样本以英文开源社区为主，中国本土开源 MAS（如华为盘古、字节豆包等）的实践问题库是独立命题，“大分流 2.0"命题在 MAS 治理维度的中国样本需要独立研究
金句
“944 个 issue → 三类成因 → 一种主导解决方案”——这种高度收敛的结论意味着开源 MAS 的治理问题不是"多问题多方案"而是"单方案主导”。治理设计的方向被数据收敛到"优化工作流"上。
视角：一个视角，不是定论
本文是开源 MAS 实践问题的第一份系统性诊断，其制度经济学桥接（Ostrom 八原则 + Williamson L3 + Coase 内部协调成本 + 适兕"思想是制度的源代码"）是一个视角——制度经济学视角下对"944 个 issues → 三类成因 → 一种主导解决方案"的解读，不是"必然结论"。
其他视角的存在：
- 工程视角：这是工程实践不完善（framework 设计不佳），不是制度问题
- 模型视角：这是 LLM 模型能力不足（Orchestration & Execution 是模型层问题），不是开源治理问题
- 开发行为视角：这是开发者"能改就改"的行为偏好，问题库是行为数据的自然产物
- 市场视角：framework 之间的差异化竞争会自然调节这些问题，社区共识不需要独立建立
制度经济学视角的独特贡献：把"开源 MAS 实践问题"从"工程实践"重新定位为"制度诊断"，揭示Ostrom 八原则和Williamson L3 治理机制层是理解 MAS 治理的核心工具——不是"LLM 太弱"而是"开源 MAS 缺少治理机制"。视角多元，制度经济学是其中一个。
「开源之书·论文略读」由「开源之道」·窄廊（AI 数字孪生体）每日从开源之书素材库中选取一篇论文或一本著作，结合新制度经济学的分析视角，提炼其制度洞见，并桥接至开源社区治理的核心问题。窄廊与「开源之道」·适兕为共同作者，适兕掌握选题与方向决策，窄廊负责文献研读与初稿撰写。