北京
100个AI代理同时往一个代码库里提交改动，100条被确认的变更，丢失0条。这组数字来自一次受控评估：单一私有部署，后端用PostgreSQL和S3兼容存储。评估方同时强调，这只能说明该测试条件下的行为，不是吞吐基准，也不是生产可靠性的保证。
真正被摆上台面的问题，是Git本身。Git是优秀的分布式版本控制，并发、分布式开发它本来就支持。摩擦出在它上面那层工作流：分支、变基、拉取请求、合并队列，这套东西是围绕少数几个"还记得昨天干了什么"的人设计的。
当大量自主代理同时修改同一份代码，这层工作流就变成了编排活。总得有人——或者某个脚本——去建分支、排合并顺序、重试变基、把上一个会话的知识带到下一个会话。Strata的思路是把协调、集成和上下文搬进版本控制系统内部。
它列出的痛点很具体：每个任务每个代理一个分支，命名、追踪、清理都是活；每次合并进主干，其他所有打开的分支基线全部位移；合并顺序得有人拍板；代理看不见谁在改同一批文件；文本冲突标记是写给人看的，不是给程序看的；代理学到的东西随会话结束而消失；决策散落在聊天记录、PR评论和提示词里；围绕Git写的自动化脚本，在代理频繁撞上的边界情况上碎掉。
Strata的工作流是这样走的：代理接到任务，任务带负责人、依赖和状态；系统在当前权威修订版本上开一个隔离工作区；检索该任务的决策、发现和检查点；代理提交改动，提交的是候选，不是往分支上推；系统对照当前状态做校验和集成，重叠的部分以结构化冲突返回；历史与上下文带来源信息留存，交给下一个代理或开发者。
多代理场景下，三个代理共用一个仓库：两条改动干净集成，第三条重叠，回来的是结构化冲突，而不是被静默合并。这里有个边界说得很清楚——集成安全只保证已确认的改动不丢，不保证合并后的代码在语义上正确，那仍然是测试和评审的事。
上下文这块，代理会忘，仓库不该忘。代理把学到的东西记成结构化上下文：任务目标、架构决策、实现发现、进度检查点、交接记录。每条记录带来源修订版本和状态，代码往前走时可以核验或作废。系统只存代理明确写下的内容，不读取模型的私有推理过程。上下文是证据，下一个代理要拿它对照当前仓库状态。
架构上，Strata不是LLM，也不写代码，它是代理和开发者共同面对的记录系统。后端用Go写，以Docker容器交付，PostgreSQL存元数据，S3兼容对象存储存仓库内容。它不绑定特定模型供应商，任何会说MCP、原生API或Git的代理都能用。
Git兼容性的做法是保留Git、换掉工作流：开发者照旧用现有客户端通过HTTP或SSH克隆、拉取、推送；代理走原生接口，拿工作区、交候选、收结构化冲突、读写上下文。两条路径读写同一份权威仓库状态。兼容范围限定在被测试覆盖的操作上，参考文档里列了支持的操作和已知限制。
部署方面，Strata开源，跑在你自己运维的基础设施上，仓库内容、上下文记录和身份都留在你的网络内。当前部署已通过PostgreSQL、S3兼容存储、Git HTTP与SSH、IAM、MCP与gRPC、恢复与备份的评估。但它尚未被宣布为生产就绪，路线图上还列着剩余事项。
100个代理、100条确认改动、0丢失，这组数字的注脚和数字本身一样值得读：它描述的是测试条件下的行为，不是规模上限。代理不会累，但流程会。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
