若无底层 Git，你会如何捕获两个即将执行不兼容变更的智能体？

我维护着 Foremerge，一个为并行编码智能体设计的开源协调协议。声明：这是我的项目，本文是设计探讨而非推广或发布。其机制很轻量。智能体在编辑任何内容前，会发布其计划变更的范围（scopes），每个范围都附带声明的操作。例如，一个智能体声明 symbol:PaymentService 并执行替换操作，另一个智能体则对同一范围声明扩展操作。在任一行代码写入之前，后者就会收到一个“高度冲突”提示。存储采用 SQLite，位于仓库的 Git 公共目录下，因此隔离的工作树可共享该存储。声明是租用且建议性的，不涉及实际锁机制。在审视该协议假设为代码的环节时，我发现其生命周期分为前后两半。前半部分除了定位存储库之外，不依赖 Git：包括意图声明、冲突声明、冲突检测、智能体自身对重叠的判断记录、协调消息、审批及解决。目前的范围词汇表是封闭的（包括 symbol, api, schema, config, infra, test, migration, env, file, component, contract, domain），但其比较逻辑是基于类别、键和操作类型。操作是添加、扩展、修改、替换、删除、重命名还是迁移，是任何资源的属性，而非源代码的属性。而后半部分则完全依赖 Git。变更集（ChangeSet）通过文件树和差异生成指纹。验证过程会运行命名检查，仅当指纹在运行前后保持一致时才计数。接受步骤会在 refs/foremerge/accepted 下固化一个不可变提交，依赖关系和落地完成都通过提交的祖先关系来证明。因此问题是：如果你运行的智能体作用于非仓库的东西，你的“Git”是什么？具体来说：什么能提供智能体即将变更内容的、基于内容寻址的快照？是文档修订 ID？Terraform 状态序列号？CRM 记录版本号？对于许多 SaaS 服务，类似机制并不存在。此时后半部分就退化为“智能体声称已完成”，审计轨迹只能标记为“已声明”而非“已验证”。你实际上在非编码智能体之间见过哪些冲突场景？我能想到的有：一个支持智能体准备退款，而另一个智能体却在升级该订单；两个外联智能体向同一联系人发送草稿；两个内容流水线在同一日向同一频道发布同一主题。我尚未量化这些情况，更想听取真实案例。范围词汇表应该是开放式的，让项目自行定义类型（如 record:hubspot/contact/123），还是应该为不同领域定义专属配置文件及匹配规则？令牌相似性匹配会将 symbol:CreditLedgerService 与 symbol:CreditLedger 关联起来，但对于仅差一位数字的 ID 可能会产生误判。当操作不可逆时，前置检测的价值是否更高？Git 使回滚成本低廉，因此在代码中节省的是返工成本。已发送的邮件或已发出的退款无法撤回。我并非在问是否应让模型判断冲突。该设计刻意避免引入模型循环：检测器是确定性的，执行操作的智能体自行记录其对重叠的判断。我希望保持这一点。限定范围，以免有人费力寻找：本地优先、单机运行，目前唯一的底层基座是 Git。本文所述均基于已发布的代码或文档。我有意弱化了关于前半部分“不依赖 Git 以定位存储”的描述，因为命令行工具仍会拒绝在无显式数据库路径的情况下打开仓库外的存储。