企业官网建设流程全解析

Obot是一个开源的AI 治理平台（Complete AI Governance Platform），帮助企业统一管理 AI 客户端与模型、工具之间的连接：它内置MCP Gateway（MCP 网关）和LLM Gateway（大模型网关），提供受管控的 AI 工具分发（MCP 注册表与 Skills 注册表）、沙箱化的 MCP Server 托管、设备级 AI 活动审计，以及完整的身份与访问控制。无论是 Claude Code、Cursor、Codex 还是其他 IDE/CLI，都能按需接入 Obot，而无需强迫整个团队统一某一种 AI 客户端或模型供应商。

Obot 是什么？一个"AI 世界的网关 + 管家"

如果把企业里的 AI 工具比作自来水，那 Obot 就是总水表和总阀门：所有模型调用、工具调用都必须经过它，管理员才能知道"谁、在什么时间、调用了什么、花了多少钱"，并在中间实施权限与内容策略。

Obot 平台的整体架构分为三部分：用户设备（User Devices）、Obot Server 和外部服务（External Services）。在用户设备上，桌面 AI 客户端通过 Obot 网关接入；Obot Sentry负责在设备端扫描、审计并执行 AI 活动策略；Obot Server 则提供网关、沙箱托管、平台服务和注册表四大能力。

架构细节可参考：docs/docs/overview.md、README.md

核心能力详解：Obot 能为企业解决什么问题？

MCP Gateway：AI 工具的唯一受管入口

MCP（Model Context Protocol）让 AI 客户端连接外部工具（数据库、API、文档系统……），但工具一多，企业就面临失控：员工各自连接、凭证各自保管、无人知道谁调了什么。

MCP Gateway把所有 MCP Server 收拢到一个受管控的入口，解决四类问题：

• 统一接入：代理托管在 Obot 内或运行在外部网络的任意 MCP Server
• 组合复用：通过 vMCP（虚拟 MCP）把多个 Server 中精选的工具合并为一个端点，一个 URL 即可分发给团队
• 细粒度权限：按用户或身份提供商（IdP）分组控制每个 Server、每个工具的访问
• 流量治理：用 MCP 或 Webhook 过滤器检查、拒绝甚至改写 MCP 请求与响应
• 凭证集中：统一管理 MCP OAuth、用户/共享凭证和 Kubernetes 密钥绑定

下图展示了 Obot 中 LLM 网关、MCP 目录与 MCP 网关如何把 AI 客户端（Obot Chat、Cursor、Claude、其他 Agent）统一导向模型与工具：

延伸阅读：docs/docs/concepts/mcp-gateway.md、docs/docs/mcp-gateway/access.md、docs/docs/functionality/filters.md

LLM Gateway：模型密钥不再满天飞

团队里每个人手里都有 OpenAI、Anthropic 的 API Key？账单算不清、权限收不回，是普遍痛点。LLM Gateway的做法很直接：

• 管理员把OpenAI、Anthropic、Amazon Bedrock、Azure等供应商凭证配置在 Obot 上（Model Provider），不再分发给个人
• 用户拿带作用域的 Obot API Key调用兼容端点（如/api/llm-proxy/openai、/api/llm-proxy/anthropic）
• 通过Model Access Policy（模型访问策略）限制每个用户可见、可调用的模型范围，/v1/models只会返回被授权的模型
• 自动记录每次请求/响应、客户端与会话元数据、token 用量和估算成本

网关内部先做身份认证，再执行部署与代理转发，形成清晰的信任边界：

延伸阅读：docs/docs/llm-gateway/how-it-works.md、docs/docs/configuration/model-providers.md

MCP 与 Skills 注册表：企业级"AI 应用商店"

就像内部软件商店一样，Obot 的MCP Registry和Skills Registry让管理员集中策展（curate）可分发的 AI 资产：

• 在 Obot 内直接整理目录，或从GitHub、GitLab 等 Git 仓库同步目录（GitOps 风格）
• 通过标准MCP Registry API对外暴露目录
• 对单个条目、仓库或整个目录应用MCP 访问策略 / Skill 访问策略
• 跨目录复用集中管理的 Git 凭证

延伸阅读：docs/docs/registries/overview.md、docs/docs/registries/publish-skills.md

沙箱托管 MCP Server：把 AI 工具关进隔离环境

企业最怕的不是工具不够多，而是工具跑起来后能"摸到"生产环境。Obot 可以自行运行 MCP Server（npx、uvx或容器化），以Docker 容器或 Kubernetes 工作负载的形式隔离执行，并通过网络策略提供者对托管 Server 应用基于域名的出站（egress）规则——从源头限制它能访问哪些外部地址。

在管理界面中，添加 MCP Server 时可选择托管（Hosted）、远程（Remote）、单人/多人等多种类型，类型选择决定了它的部署与访问方式：

延伸阅读：docs/docs/concepts/mcp-hosting.md、docs/docs/configuration/mcp-server-egress-control.md

Obot Sentry：治理延伸到用户设备（Beta）

网关只管"经过 Obot 的流量"，那在员工本地电脑上直接发生的 AI 活动呢？Obot Sentry（设备管理功能，当前为 Beta）把它也纳入治理范围：

• 设备注册（Enroll）接入 Obot 平台，可手动安装或通过 Microsoft Intune 等MDM批量部署
• 自动盘点设备上安装的AI 客户端、MCP Server、Skills 和插件
• 为Claude Code、Codex、Cursor、VS Code安装钩子（Hooks），记录本地工具调用
• 支持对受管设备上的 AI 活动做监控与强制执行（enforcement）策略

延伸阅读：docs/docs/device-management/how-sentry-works.md、docs/docs/device-management/enforce.md

身份、权限与审计日志：合规的底座

• 身份与访问控制：对接企业身份提供商（Auth Provider）认证用户；对 MCP Server、MCP 工具、Skills、模型和管理 API 分别授权；可为 AI 客户端与 Agent 工作负载签发作用域凭证
• 关联审计日志：把 MCP 请求/响应、LLM 请求/响应与成本、设备端 Sentry 捕获的本地工具调用关联起来，可按用户、Server、工具、模型、客户端、设备或会话过滤
• 灵活的导出：审计数据可一次性或按计划定时导出；敏感的请求/响应正文仅Auditor附加角色可见，实现敏感内容分级

延伸阅读：docs/docs/security/authentication.md、docs/docs/security/audit-data.md、docs/docs/security/policy-coverage.md

5 分钟快速上手：Docker 部署体验 Obot

评估场景下，一条docker run命令即可启动（内置 PostgreSQL 与本地存储；生产环境建议使用 Kubernetes + 外部 PostgreSQL）：

docker run -d \ --name obot \ -p 8080:8080 \ -v obot-data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -e OBOT_SERVER_ENABLE_AUTHENTICATION=true \ -e OBOT_BOOTSTRAP_TOKEN=<token> \ ghcr.io/obot-platform/obot:latest

打开http://localhost:8080，用引导令牌（至少 6 位字符）登录，首次进入会看到引导弹窗：先配置认证提供商（Auth Provider），按需配置模型提供商（仅使用 LLM Gateway 时必需）：

之后就可以创建 vMCP、分享端点、接入 AI 客户端，体验完整的"治理链路"。

延伸阅读：docs/docs/installation/overview.md、docs/docs/installation/docker-deployment.md

总结：企业引入 Obot 的 3 个直接收益

Obot 采用MIT License开源（见 LICENSE），且允许团队渐进式采用——不需要强制统一 AI 客户端、模型供应商或工具生态，每个团队按需接入即可。相关架构决策记录（ADR）也随仓库公开维护，见 adr/README.md。