把 Agent 的知识、技能和权限放回 Git：Hexis 如何用 MCP 建立可审查的团队工作区
团队给 Claude Code、Cursor、ChatGPT 之类的 Agent 接入内部资料时，很容易走向两种极端：要么每个人各自维护一套提示词、连接器和密钥；要么把所有上下文塞进某一个厂商的管理后台。前者难以复用和审计，后者则把迁移成本、权限边界和组织知识一起锁进了某个产品。
Hexis 是 Bevel 平台开源的核心组件。它把团队的知识、技能、工具说明与访问规则放在自有 Git 仓库中，再通过内置的远程 MCP 服务交给支持 MCP 的 Agent 使用。它不是替代模型或编程 Agent，而是把“Agent 能知道什么、能做什么、谁批准了变化”变成一套可版本化的基础设施。
问题不只是提示词，而是配置的所有权
一次性的个人自动化，用本地配置文件已经足够。但当多个成员、多个 Agent 和多个业务系统同时加入，配置本身就成为需要治理的资产。
例如，销售支持 Agent 需要读取产品资料、调用 CRM，并根据规则生成回复草稿；研发支持 Agent 则需要访问架构文档和代码审查流程。若这些资料分别存放在不同 Agent 厂商的工作区中，团队会遇到三个问题：内容重复复制；权限只能在各家控制台里分别配置；当流程被修改时，难以判断是谁在何时改变了什么。
Hexis 的做法是把这些定义移到团队拥有的仓库。技能采用 SKILL.md 这类 Markdown 文档保存；知识、工具和访问规则同样作为受版本控制的文件管理。这样，分支、变更请求、代码评审和回滚不需要为 Agent 另造一套机制，而是复用团队已经熟悉的 Git 协作链路。
这也改变了“上下文”的含义：它不再是一段被复制到聊天窗口的文本，而是可以被维护、审查和追溯的工作产物。文档的来源、最近修改者和验证时间可以成为知识节点的属性；某项流程更新则可以在合并前由负责人确认。
从仓库到 Agent：MCP 只做交付层
Hexis 的架构重点不是要求所有人使用同一个 Agent，而是把 Git 仓库作为事实来源，把 MCP 作为交付接口。平台说明中将工作区拆为知识、技能、工具与权限四部分：知识为团队资料提供结构化上下文；技能是可阅读的操作规程；工具清单描述可调用能力及访问范围；身份与角色决定谁能看到哪些内容。
Agent 连接到 MCP 服务后，应该只发现其角色允许读取的技能、工具和上下文，而不是得到一个全量的共享提示词包。这种限制特别适合把内部资料接给多个运行时：团队可以按任务混用不同 Agent，而不必为每个厂商重建一遍知识库和权限模型。
对 Agent 而言，连接流程可以很轻；对组织而言，真正的复杂度仍留在可评审的仓库和访问规则中。这是有意的取舍：降低使用者接入门槛，但不把权限决定藏进难以检查的客户端配置。
一个可复现的最小部署
Hexis 官方 README 给出的自托管路径以 Docker Compose 为起点。准备 Docker、Compose 与一个空的 Git 仓库后，先取得源码并创建环境文件：
git clone https://github.com/Bevel-Software/Hexis.git cd Hexis cp .env.example .env
初始配置需要定义管理员邮箱、登录密码，以及用于会话和密钥加密的 JWT_SECRET、SECRETS_ENC_KEY。这些值不应提交进仓库；README 提供了用 Node 生成随机字节并转为 Base64 的示例。随后，在反向代理后的典型部署中可启动 Compose：
docker compose -f docker-compose.yml up -d
官方特别区分了这条命令和直接执行 docker compose up -d 的场景：前者显式跳过覆盖文件，适用于由反向代理通过 Compose 网络连接服务的部署；直接暴露服务时才使用默认配置。不要只看命令形式相近就混用它们，否则重部署时可能遇到端口占用问题。
首次登录后，需要提供知识库仓库的 HTTPS clone URL、具有读写权限的 Git 凭据，以及默认分支与受保护分支的策略。空仓库会被初始化为模板；之后对受保护分支的改变可经过变更请求和所有者批准，再成为 Agent 可使用的内容。
连接一个 MCP 客户端时，先验证边界
以 Cline 为例，项目 README 给出了连接公开演示实例的命令：
cline mcp install hexis --transport http https://demo.bevel.software/api/mcp --yes
执行后需要在浏览器完成 OAuth 登录。这里的演示地址只适用于官方 demo；部署自己的实例时，应替换为自己的服务主机。更重要的是，不要把演示配置、管理员凭据或 Git token 当成可复制的“快速上线方案”。生产环境至少应确认公开访问地址、反向代理 hop 数、OAuth 回调地址、Git token 的最小权限，以及备份策略。
README 指出，持久化状态包含 Postgres 数据和若干应用卷，而知识库 Git 仓库本身也是需要备份的核心对象。这意味着恢复计划不能只备份数据库：如果技能、工具定义和知识节点的版本历史位于 Git，仓库与数据库要一起纳入演练。
把规则当作代码维护时，几个细节不能省
“Git-backed” 不等于只要把几个 Markdown 文件提交进去。要让它成为真正可靠的控制面，团队还要明确文件与运行时之间的责任边界。
第一，技能文件适合记录稳定的操作过程，例如输入条件、允许调用的工具、输出格式和人工升级条件；它不适合保存会频繁过期的访问令牌或临时业务数据。后两类信息应分别进入密钥管理与知识库更新流程。第二，变更请求的评审者应当与资产所有者匹配：修改销售话术的人未必可以扩大 CRM 写权限，修改部署流程的人也不应自动得到生产数据库的访问权。第三，角色规则要做负向测试——用一个低权限测试账户连接 MCP，确认它既看不到不该看的知识，也不会发现不该调用的工具。
部署侧也要避免把“能启动”当作“可运营”。建议把 /api/health 接入监控；在升级前备份 Postgres 卷与知识库仓库；为管理员和普通成员分别演练登录、OAuth 回调、Git 写入失败和受保护分支拒绝合并等路径。Hexis 的首启会执行迁移并初始化知识库，因此健康检查短暂未就绪不必立刻判为故障，但应给首次启动保留足够的等待窗口。
最后，MCP 连接应被视为一个受管理的入口，而不是一次复制粘贴。撤销成员权限、轮换 Git token、修改角色规则后，都应检查已建立连接的 Agent 是否按预期收敛到新权限。这样，Git 历史记录的才不只是文档改动，还包括 Agent 工作边界如何随组织决策演变。
适合什么团队，不适合什么团队
Hexis 最适合已经拥有 Git 协作习惯、希望同时支持多个 Agent 运行时，并且需要对内部知识和工具权限留下审查轨迹的团队。它的价值不在于让 Agent 更聪明，而在于让团队能以已有的工程流程管理 Agent 所依赖的资产。
代价也很明确：你需要维护 Git 凭据、数据库、部署环境和身份接入；技能文件写得再漂亮，如果没有明确的所有者、分支策略和权限审查，仍然无法自动获得治理效果。对于只想给个人脚本加一条简单 MCP 连接的用户，这套控制面可能过重；但当“谁能让 Agent 读什么、调什么”开始成为常态问题时，把答案放进可审查的仓库，通常比散落在多个产品后台更可靠。