Hexis 是一个面向企业集中管理 AI 智能体技能、工具、上下文、权限与身份的控制平面。它自托管、以 Git 为后端并原生支持 MCP（Model Context Protocol），把公司全部 AI 插件、工具和知识集中在一处，经过统一管理、评审和访问控制，可从任意 AI 智能体使用。该仓库是 Bevel 平台的开源内核，据称有团队正在使用。
用途与定位
Hexis 的目的是为 AI 智能体的技能、工具手册、上下文和身份权限提供统一存放与管理入口。每个技能、工具手册和权限都是你所拥有的 Git 仓库中的一个文件，因此审计轨迹就是存储层本身：谁改了什么、何时改的、谁批准的、如何撤销，都可以追溯。智能体只能执行运行它的人所能执行的操作，权限按文件解析，且智能体从不持有它使用的凭据。系统运行在你自己的基础设施上，位于你自己的 SSO 之后。
主要能力
- Git 支撑的变更与评审：技能和工具手册是可评审的文件。任何人都可以提出变更；在受保护分支上，变更会送达所涉文件的所有者，只有所有者批准后才会生效。智能体同样可以提议：如果某个智能体在任务中遇到损坏的技能，它可以建议修复，由人来决定是否采纳。
- 双向管理：与仅单向消费的 MCP 网关不同，Hexis 允许用户提出变更或分享新的技能和 MCP 服务器，并具备细粒度的查看和评审权限控制。
- 角色与访问控制：可以将队友加入角色或按需直接授权。所有人连接同一个工作区，但每个人及其智能体只能看到被允许阅读的内容。
- MCP 原生集成：可与任何支持 MCP 的客户端配合，包括 Claude Code、Codex、Cursor、Cline 和 ChatGPT，各自仅能看到其用户角色允许的内容。
- 本地 MCP 服务器：在自有机器上运行的智能体可以启动
npx -y @bevel-software/hexis-mcp作为本地 MCP 服务器，从而在托管端点提供的能力之外，额外加入插件的本地专属工具。该命令需要 Node 22.13+ 或 24，且从 Dock 或桌面图标启动的客户端可能看不到 PATH 中的 npx，需用which npx（Windows 用where npx）获取完整路径并填入 "command"。 - 知识页面支持相对链接与图片，访问权限随文件夹，导出时保持链接有效；不支持粘贴 base64 图片。
- 每次保存都是一次提交，历史、blame 和回滚与代码管理一致；受保护分支的变更以可评审的变更请求形式发布。
使用方式
体验与连接
- 可将 Claude 通过 MCP 连接至 Hexis，然后正常提问。Claude 可以发现并加载你的角色有权访问的已批准技能说明和公司上下文，无需在工具间复制提示词。
- Cline 可直接作为远程 Streamable HTTP MCP 服务器连接 Hexis，使用 Cline CLI 安装公开演示连接，在浏览器中完成 OAuth 登录后，Cline 即可发现你的 Hexis 角色可访问的技能、工具和上下文；自建部署时把
demo.bevel.software替换为你的部署主机。 - 公开实例
demo.bevel.software可用 Google 账号登录，内含虚构公司的知识、技能和工具，Start here 页面引导完整流程。该演示是共享且偏只读的（访客提议、所有者批准）。
托管与部署
- 托管实例：官方可代为运行（托管、升级、备份、SSO），团队只需登录，联系邮箱为 ali.raza@bevel.software。
- Docker 部署：需要带 Compose 的 Docker（服务器或笔记本均可）以及一个空 Git 仓库（任意托管均可）存放知识库；首次运行会以起始模板初始化仓库。
- 下载两个部署文件，无需克隆；编辑
.env填入四个必填值。生成两个密钥（运行两次，分别粘贴）；公开 HTTPS 部署还需设置 DOMAIN。启动命令会拉取 CI 发布镜像，服务器上不编译，小型实例即可。可在.env中固定版本（HEXIS_VERSION=0.15.1），升级和备份见 UPGRADING.md。从源码构建使用deployment/docker-compose.build.yml。 - 公开 HTTPS 且自备无代理：
httpsprofile 会在应用前启动 Caddy，自动为 DOMAIN 获取 Let's Encrypt 证书并做 HTTP→HTTPS 重定向。需要 DNS A/AAAA 记录指向服务器，开放 80 和 443 端口（80 端口必须开放，用于证书挑战和重定向）。 - 在自有反向代理（Coolify、Traefik、nginx）之后：跳过该 profile，改为设置 origin 值和代理跳数，确保 OAuth 重定向正确、限流看到真实客户端 IP。显式使用
-f会跳过docker-compose.override.yml，应用不发布宿主端口，代理通过 compose 网络在 3001 端口访问。这是有意为之：固定发布端口会导致每次重新部署时替换容器启动而旧容器仍占用端口，从而报端口已被分配。 - 笔记本试用：步骤相同，去掉 DOMAIN 和 origin 值，并额外获取
docker-compose.override.yml把应用放到 localhost；打开http://localhost:3001（换端口用APP_PORT=8080 docker compose up -d）。此处不要设置 TRUST_PROXY，因为无前置代理时信任转发头会让客户端伪造自己的地址。
首次登录设置
应用会询问无法猜测的信息，并在保存前对真实主机进行测试：知识库仓库的 https 克隆 URL；具备读写权限的 Git 凭据（GitHub 上可用对该仓库有 Contents 读写权限的细粒度个人访问令牌）；分支模型（默认分支和受保护分支，受保护分支的变更仅通过批准的变更请求生效）。如果仓库为空，应用会用内置模板初始化，并写入 roles.yaml，第一个 Admin 就是你。之后在 Skills & Tools 创建第一个插件和技能，在 Connect 菜单通过 MCP 接入智能体。
知识页面
页面是 markdown。指向其他页面的链接用相对路径，Hexis 会在应用内打开；图片同理，放在使用它们的页面旁边的 assets/ 文件夹并相对链接。访问权限跟随文件夹，因此能读页面的人也能看到其截图，移动文件夹可保持所有链接有效；共用一个 Uploads/ 文件夹会失去这两点优势。
本地开发
需要 Node 22.13 或更新（.nvmrc；引擎范围 >=22.13 <23）、pnpm 10、git ≥ 2.41 以及 Postgres 17。打开 http://localhost:5173（开发服务器代理到后端）。常用命令：pnpm test、pnpm typecheck、pnpm lint。迁移会在启动时自动运行，开发和生产都没有单独的迁移步骤。
适用场景
- 企业集中管理 AI 智能体技能、工具与上下文，并需要审计与审批流程。
- 需要按文件粒度控制谁能查看、谁可提议、谁可批准。
- 希望智能体只能执行运行者可执行的操作且不持有凭据。
- 需要与多种 MCP 客户端（Claude Code、Codex、Cursor、Cline、ChatGPT 等）协同。
- 需要在自有基础设施、自有 SSO 之后部署。
限制
- 权限按文件解析，访问跟随文件夹；共用 Uploads 文件夹会失去按文件夹的访问与链接稳定性。
- 不支持粘贴 base64 图片。
- 本地 MCP 命令需要 Node 22.13+ 或 24，且某些客户端可能找不到 npx。
- 显式使用
-f时应用不发布宿主端口，需通过 compose 网络访问。 - 无前置代理时不应设置 TRUST_PROXY。
- 关于收费、价格、具体性能指标、支持的完整客户端列表以及演示之外的规模限制，资料未提供。
许可
Apache-2.0。
