
Bevel
Bevel 是一个与供应商无关、由 Git 支持的企业 AI 代理控制平面,它将代理、上下文、技能、工具、权限和身份定义为您拥有并可通过 MCP/UTCP 提供给任何代理运行时的文件。
https://www.bevel.software/?ref=producthunt&utm_source=aipure

产品信息
更新于:2026年08月14日
什么是 Bevel
Bevel 是一个总部位于慕尼黑(成立于 2024 年)的控制平面,旨在帮助组织操作化 AI 代理,而无需将其核心代理逻辑和治理锁定在单一供应商的产品中。Bevel 不会将提示、工具连接、知识和访问控制分散到多个控制台和连接器面板中,而是将您的存储库作为版本化事实的单一来源。它允许团队使用存储在您的基础设施中的纯 Markdown 和 YAML 定义代理知道什么、它们如何行为、它们被允许做什么以及它们扮演谁的角色——这样,相同的受控代理设置就可以被公司内不同的代理运行时使用。
Bevel 的主要功能
Bevel 是一个与供应商无关、由 Git 支持的企业 AI 代理控制平面,它允许组织将代理的上下文、技能、工具、权限和身份定义为存储在自己的基础设施中并通过 MCP(及相关协议工具)提供给任何代理运行时的纯文件(Markdown/YAML)。它集中了受治理、版本化的代理知识和程序的“事实来源”,强制执行细粒度访问规则和每个代理的凭据,并通过标准 Git 工作流(分支、差异、更改请求)使更改可审查,从而使团队能够通过强大的归因和控制,在面向员工和无人值守/后台自动化中扩展代理部署。
Git 支持的文件形式的代理配置: 在您自己的存储库中以 Markdown/YAML 格式定义代理、知识、技能、工具清单和访问策略——使用标准的 Git 分支、差异和审查,而不是特定于供应商的控制台。
带来源的类型化上下文图: 将知识存储为带来源(来源、最后编辑者、验证时间)的类型化节点,并将其编译成可遍历的图,用于更新、审计和仪表板。
作为可读、可审查程序的技能: 以纯 Markdown 格式(而不是隐藏的提示片段)编码操作程序,使其对流程所有者可理解,并可在代理运行时之间移植。
工具清单 + 受治理的权限: 通过清单一次性声明工具,将秘密保存在保险库中,并应用访问规则,控制哪些代理可以读取哪些文件或调用哪些端点——更改需经过审查。
每个代理的身份和归因: 每个代理都是一个具有自己凭据和范围访问权限的命名参与者(没有共享服务帐户),从而提高了所采取行动的可审计性和问责制。
通过 MCP 进行运行时无关的交付: 将相同的受治理代理界面提供给多个运行时(例如,桌面编码助手和服务器端/后台代理),因此您可以在不重新构建的情况下切换或混合供应商。
Bevel 的使用场景
采购与寻源副驾驶: 通过将版本化程序(技能)与对内部文档和采购工具的受控访问相结合,创建用于 RFI、招标管理和供应商资格认证的代理。
GTM 营销活动自动化: 统一 Salesforce 和广告平台等系统中的碎片化数据,然后运行具有受治理工具访问和可重用上下文的营销活动规划/执行代理。
市场情报代理: 将外部市场数据与内部信号连接起来,向正确的团队提供精选见解,同时通过来源保持来源、编辑和验证的可追溯性。
企业级代理治理与合规: 标准化所有团队定义代理知识、权限和身份的方式;通过 Git 审查工作流强制执行最小权限访问和可审计的变更控制。
多运行时代理可移植性(反供应商锁定): 在不同的运行时(交互式桌面助手和无人值守后台代理)中运行相同的代理,而无需为每个供应商重新实现连接器、提示或知识存储。
优点
与供应商无关的设计通过将代理定义和知识保存在您的基础设施中并通过 MCP 提供给任何运行时来减少锁定。
强大的治理:文件级访问规则、保险库中保存的秘密、每个代理的身份以及基于 Git 的审查提高了安全性和可审计性。
操作清晰:Markdown 中的技能和有来源支持的上下文使代理行为更容易理解、维护和随着时间的推移进行改进。
缺点
需要严格的存储库/流程所有权(信息架构、审查和维护)才能保持上下文和技能的准确性和实用性。
在实现价值之前,采用可能涉及前期集成和策略设计工作(工具清单、权限建模、身份设置)。
习惯于供应商 UI 的团队在转向基于文件、以 Git 为中心的代理管理工作流时可能会面临学习曲线。
如何使用 Bevel
1) 决定您指的是哪个“Bevel”: 资料来源提到了多个不相关的名为“Bevel”的产品(bevel.software 上的企业 AI 代理控制平面、一个健康应用、Blender 的倒角工具等)。提供的官方网站是 Bevel(用于企业 AI 代理的 Git 支持的控制平面)。以下步骤涵盖了该 Bevel。
2) 创建(或选择)一个 Git 存储库作为您的事实来源: Bevel 的模型是“您的存储库是事实来源”。在您公司的基础设施中创建一个存储库,其中代理上下文、技能、工具、身份和访问规则将作为文件存在。
3) 添加标准的 Bevel 文件夹结构: 将您的存储库组织成官方网站上描述的基于文件的布局,例如 knowledge/、skills/、tools/、agents/、access/,以便所有内容都可以通过 Git 进行版本控制和审查。
4) 定义代理知道什么(上下文): 使用带有事实来源(来自哪里、最后由谁修改、何时验证)的类型化知识节点填充 knowledge/。此上下文被编译成一个可遍历的图,您可以对其进行批量更新并构建仪表板。
5) 定义代理如何工作(技能): 将程序作为纯 Markdown 文件写入 skills/(而不是供应商控制台中的提示片段)。保持它们对流程所有者可读,并可在差异中进行审查。
6) 声明工具以及它们如何公开(工具清单): 在 tools/ 中创建工具清单文件(例如 salesforce.yaml、sharepoint.yaml)。这些清单一次性声明工具,以便它们可以通过 MCP/UTCP 提供给任何代理运行时。
7) 配置工具的秘密处理: 确保工具秘密保存在保险库中(根据官方网站:“工具清单,秘密保存在保险库中”)。将秘密排除在 Git 之外;只存储检索所需的引用/元数据。
8) 定义每个代理可以做什么(权限/访问规则): 在 access/ 下创建文件级访问规则(例如 policy.yaml),指定哪个代理可以读取哪个文件并调用哪个端点。像任何其他更改一样,通过代码审查路由更改。
9) 定义代理扮演谁的角色(身份): 为每个代理创建身份,以便每个代理都是一个具有自己凭据和范围的命名参与者(而不是共享服务帐户)。这使得操作可以归因于特定的代理。
10) 组装代理定义: 在 agents/ 中创建代理配置文件(例如 tender-desk.yaml),将四个部分联系起来:上下文引用、技能程序、工具访问和身份/范围。
11) 通过 MCP 或 UTCP 连接代理运行时: 通过“MCP”(和/或 UTCP,如所述)将存储库定义的上下文/技能/工具/权限提供给运行时。官方网站列出了支持的运行时,例如 Claude Code、Cursor、ChatGPT 桌面、opencode、后台代理和平台内自托管模型。
12) 验证受控访问行为: 通过尝试在定义的访问策略内部和外部进行读取/调用,测试“代理连接并准确读取它们被允许读取的内容”,确认未经授权的文件/端点被阻止。
13) 通过 Git 工作流(分支、更改请求、差异)进行操作: 通过编辑 Markdown/YAML、打开更改请求和审查差异来进行更新。这是主要的操作模型:治理和演进通过标准的 Git 实践而不是供应商特定的控制台进行。
14) 维护和发展可重用的上下文和技能: 持续更新共享工件(知识节点、技能、工具清单、策略),以便改进成为持久的“每个人共享的工件的已审查编辑”,而不是在聊天记录中丢失。
Bevel 常见问题
Bevel是一个与供应商无关的、由Git支持的企业AI代理控制平面。它允许公司在自己的基础设施中,将AI代理的上下文、技能、工具、权限和身份定义为公司拥有的文件,并通过MCP将其提供给任何代理运行时。











