Hexis Hexis为AI智能体提供集中管理的技能、工具和知识库，支持版本控制与权限管控，帮助企业安全部署和治理AI代理工作流。 热门评论 PH 用户嘿，Product Hunt！👋我们推出 Hexis，是因为我们看到每个人（包括我们自己）都在把技能和上下文放进 GitHub。版本管理、PR、审查；一开始还行。但后来非技术人员就不得不学习整套工作流。GitHub 是为软件开发而生的，当你把它大规模用于它本非所长的场景时，它就会崩掉。Hexis 是构建在 Git 之上的一层。它保留了核心（版本管理、PR），并加了一层对非开发者友好的用户体验，同时支持基于文件的访问权限管理（这在 GitHub/GitLab 根本做不到）。公司用户可以通过 MCP server 随便连上他们选的任何智能体，使用技能、建议修改、提交新技能，完全不用碰 Git 工作流。管理员管理每个人、团队或智能体能访问哪些上下文、工具和技能。他们批准请求的变更，审核提交上来的技能。P.S：在亚里士多德哲学里，'hexis' 是一种不是你只做一次、而是真正拥有的技能。PH 用户这让我切换正在用的智能体变得超级简单，也给各种任务创建后台智能体变得超级简单，简直不可思议！你也可以在深入了解自托管之前，直接去 demo.bevel.software 试一下 demo。PH 用户访问控制的角度对我来说很有意思。我日常通过一个按目录限定作用域的 Skill 工具来加载技能，最让我卡壳的是当同一个技能名存在于两个治理层级时（比如团队级技能和项目级本地覆盖），解析顺序是怎样的。Hexis 会自动选择更具体的那一个，还是这个冲突需要管理员手动解决？PH 用户嗨，团队！我们真的很为自己在这里做出的成果感到骄傲。我们聊过的人反复提到，在组织里共享和连接技能、工具和上下文有多难。具体来说有两个原因：同事之间共享技能很慢很笨拙，因为你得分享文件和文件夹；用 GitHub 来存储和分发技能，对非技术用户来说学习曲线太陡。通过开源我们的工作，我们希望你现在有了一种简单的方式来上传、分享和改进你们团队的上下文、技能和工具！很期待你的反馈 ❤️PH 用户把 Git 作为唯一事实来源，这个角度对企业来说是正确选择。版本管理和 PR 审查已经是开发者所理解的信任层，所以在其上叠加智能体技能治理，意味着你不需要让组织从头接受一套新的信任模型。我很好奇，当两个团队提交同一个技能的相互冲突的版本时，你们是怎么处理的？是走标准的 PR 审查流程，还是有单独的治理步骤？ 热门产品Ali Raza2026-08-08原文 打开互动版
我们推出 Hexis，是因为我们看到每个人（包括我们自己）都在把技能和上下文放进 GitHub。版本管理、PR、审查；一开始还行。但后来非技术人员就不得不学习整套工作流。GitHub 是为软件开发而生的，当你把它大规模用于它本非所长的场景时，它就会崩掉。
Hexis 是构建在 Git 之上的一层。它保留了核心（版本管理、PR），并加了一层对非开发者友好的用户体验，同时支持基于文件的访问权限管理（这在 GitHub/GitLab 根本做不到）。
公司用户可以通过 MCP server 随便连上他们选的任何智能体，使用技能、建议修改、提交新技能，完全不用碰 Git 工作流。
管理员管理每个人、团队或智能体能访问哪些上下文、工具和技能。他们批准请求的变更，审核提交上来的技能。
P.S：在亚里士多德哲学里，'hexis' 是一种不是你只做一次、而是真正拥有的技能。
你也可以在深入了解自托管之前，直接去 demo.bevel.software 试一下 demo。
我们真的很为自己在这里做出的成果感到骄傲。
我们聊过的人反复提到，在组织里共享和连接技能、工具和上下文有多难。
具体来说有两个原因：同事之间共享技能很慢很笨拙，因为你得分享文件和文件夹；用 GitHub 来存储和分发技能，对非技术用户来说学习曲线太陡。
通过开源我们的工作，我们希望你现在有了一种简单的方式来上传、分享和改进你们团队的上下文、技能和工具！
很期待你的反馈 ❤️