加载失败
Weave 是一个以“实体”为单位做语言感知合并的实现，作为 git 的 merge driver 插入，不改变仓库历史或常用工作流。讨论集中在两条路线的权衡：一类是把 AST 当作 VCS 的原生存储以便做跨分支语义查询（例如 Beagle 提议用 key-value + BASON 存 AST），另一类像 Weave 这样在合并时用 tree-sitter（一个容错增量解析器）临时生成 AST 做实体合并以提高可用性。社区关切点包括解析性能（大文件与 C/C++ 宏会让解析变慢或失败）、重构与语义冲突的检测策略（例如 structural_hash 的脆弱性）以及多 agent/自动化编程场景下的实体预占与协调（Weave 的 MCP 与 sem/inspect 等工具在此提供补充）。讨论也涉及与其他工具（mergiraf、Lix 等）的比较、基准结果以及对项目推广与可信度的质疑。
一些评论主张将源码从 blob 存储替换为在 VCS 内保存 AST，这样系统可以像数据库一样做语义级查询（比如并发分支是否触及某个函数、函数被新增用法累积了多少等）。作为示例，Beagle 被提出为把 AST 以 BASON（二进制可合并 JSON）形式存在 key-value 存储的方案，从而把 SCM 变成活动枢纽。反面意见强调工程代价：解析与 diff 若放入读写热路径会很慢——有人指出 tree-sitter 在一份 25MB、约 750KLoC 的 C 文件上导入需数秒，而且 C/C++ 的宏与预处理器会让解析变得脆弱。务实折中是像 Weave 一样留在 git 层面，仅在合并时解析三份文件（观测值约 5–67ms），兼顾向后兼容与实体级合并，而原生 AST 存储能带来更强的跨分支查询能力但需要改动底层存储栈。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
Weave 的目标是把合并从行级提升到实体级（函数/类/方法），以消除多分支或多 agent 并行添加不同实体时的“虚假冲突”。在讨论中给出的基准显示实体级合并能把可自动解决的案例从 15/31 提升到 31/31；实现方式是作为 git 的 merge driver（通过 .gitattributes 调用），对不支持的语言回退到行级，从而不改变开发者现有工作流。Weave 同时以一个 MCP server 发布并捆绑 14 个工具，允许 agents 在编辑前申领实体、检测谁在触碰什么并在合并前发现冲突；配套的 sem 可做实体级 diff 与依赖图，用于 PR triage 和风险评分。多位用户与项目使用者反馈实际场景中能显著减少人工干预和 AI 令牌消耗，且已有实务整合与关注，说明兼顾可用性与向后兼容是其核心卖点。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
实体级合并并不能消除所有语义级问题：如果两个提交在语义上互相废弃（例如一侧删除或重构掉另一侧依赖的实体），合并后可能出现死代码或逻辑错误。团队为此实现了合并后语义验证，会检查实体依赖并在发现一侧废弃另一侧依赖时报警，但这仍需人工复核与测试以判定正确性。重构识别存在争议：项目使用 structural_hash（对 AST 归一化后的哈希）来匹配改名实体，但有评论指出对复杂重构非常脆弱，任何结构性改动都可能破坏匹配。另一些边界情形包括 C/C++ 的宏与预处理器导致解析失败、rebase 与 merge 的差异，以及对未支持语言（例如某些 shell 脚本）依赖回退到行级合并。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
比较显示不同工具在匹配粒度和协作链路上有显著差别：某些工具基于 GumTree/PCS 三元组做节点级匹配，生成细粒度的 AST 节点映射；Weave 则以整个实体作为合并单位，追求更简单、更可读的冲突输出（如直接标注冲突发生在哪个函数）。产品层面的差异还包括协作支持：Weave 绑定 MCP 协调套件并与 sem/inspect 结合用于 PR 分流和风险评分，而其它工具在代理预占实体或代理协作方面没有同等的集成。社区建议将这些工具加入对比基准表，并通过补充缺失的 tree-sitter grammar 来扩展对特定语言（如 bash）的实体级支持。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
讨论既有热烈支持也有强烈怀疑：部分用户分享在大规模合并中自动解决大量冲突的成功案例并称其能明显降低 AI 令牌消耗，而另一些人质疑推广方式像是自动化自我宣传或怀疑机器人账号参与。围绕可信度的争议有回应，说明仓库归属、贡献历史与第三方提供的试用额度；但情绪化的反对也很明显，有开发者公开表达反感“把生态为 AI 优化”的倾向并强调人类审查的重要性。总体上社区既看到工具的实用点与被整合的可能性，也对边界条件、透明度与长期维护提出质疑和要求更多实测。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
AST（Abstract Syntax Tree，抽象语法树）: 程序源代码的语法结构树状表示，描述函数/类/语句等结构，便于做语义级别的 diff、匹配和重构检测。
tree-sitter: 一个增量且容错的解析器生成库，用于为多种语言生成 AST；Weave 用它提取实体并进行三路合并，但在含宏的 C/C++ 或超大文件上解析成本和容错能力是实际问题。
BASON: binary mergeable JSON 的缩写，一种二进制且可合并的 JSON 格式（在 Beagle 等 AST-native 存储方案中被提出用于表示 AST）。
git merge driver（合并驱动）: Git 提供的可插拔接口，允许在合并中文件内容合并步骤调用自定义程序；Weave 通过 .gitattributes 将自身作为 merge driver 集成到现有仓库。
实体级合并（entity-level merge）: 以函数/类/方法等语义实体为单位进行三路合并而非按行或按节点细粒度匹配，目标是减少因行级分割而产生的上下文丢失和虚假冲突。
structural_hash: 对 AST 做归一化后计算的哈希值，用于忽略标识符重命名来匹配同构的实体，但对结构性改动较为敏感。
sem（项目）: 与 Weave 相关的工具，负责从 git 历史中提取实体依赖图并提供实体级 diff，用于 PR triage 和按实体聚合变更视图。
MCP server（实体协调服务）: Weave 提供的服务组件（讨论中称 MCP），包含一组用于多代理协作的工具，允许 agents 在编辑前申领实体、检测冲突并协调变更。