无人预警的竞态条件
针对同一个代码仓库运行两个克劳德代码（Claude Code）会话——一个正在重构某个模块，另一个正在修复三个文件之外的一个拼写错误，而该操作恰好也触及了一个共享配置文件——最终，这两个会话可能会在几百毫秒内决定写入同一个文件。没有任何机制能阻止这种情况发生。第二次写入会静默胜出。第一个智能体的更改将丢失，且两个会话都完全不知道发生了此事。
在下一层也会发生同样的情况，只是使用的是模型上下文协议（MCP）服务器而非原生编辑器工具：由两个智能体进程调用的 MCP 文件系统服务器，或由数据库服务器暴露的 run_migration 工具，被两个不相关的会话在短时间内连续调用两次。海姆达尔（Heimdall）MCP 早已具备工具名称策略（v1.2）和参数级策略（v1.4）——你可以规定“绝不在 /etc/passwd 上调用 write_file”——但这些策略都无法回答另一个问题：当对同一资源的两个调用同时到达时会发生什么？
这正是 1.5.0 版本旨在解决的故障模式。
代码仓库：https://github.com/enmanuelmag/heimdall-mcp
网站：https://stack.cardor.dev/heimdall
发布内容
1.5.0 版本增加了资源锁，在两个层级上强制执行，且共享相同的底层机制：通过海姆达尔代理路由的 MCP 工具调用，以及完全不经过代理的主机原生工具（克劳德代码的 Write/Edit/MultiEdit/NotebookEdit，以及 OpenCode 的等效工具）。
第一层：MCP 服务器上的锁
一个以工具名称为键的 locks 配置块，与服务器的现有 tools 和 toolPolicies 配置并列：
// heimdall.config.ts
export default {
servers: {
filesystem: {
tools: { allow: ['read_file', 'write_file'] },
locks: {
write_file: { resource: 'path', ttl: 30_000 },
run_migration: { resource: 'db-migration', onConflict: 'warn' },
},
},
},
} satisfies HeimdallConfig
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
