---
title: "Enterprise config"
description: "Gemini CLI enterprise configuration：组织账号、Cloud project、Vertex AI、许可、固定策略和团队默认配置。"
verifiedAt: "2026-05-09"
---

企业配置的重点不是“装上 CLI”，而是统一身份、项目、权限、模型、日志和成本边界。

> [!NOTE]
> 企业配置要看最终合并结果，不只看某个 settings 文件。用户级、项目级、系统级和环境变量可能互相覆盖。

官方企业文档的核心是两层配置：系统级 settings 提供集中默认值和覆盖值，Admin Controls 提供本地不可覆盖的组织策略。系统级 settings 能防误用，但不能防拥有本机管理员权限的人刻意绕过。

## 企业用户要先确认

- 账号类型：Workspace / organization / personal。
- Gemini Code Assist license。
- Google Cloud Project。
- Vertex AI 是否启用。
- IAM 角色。
- 计费和配额。
- telemetry 和合规要求。

## 系统级配置层级

Gemini CLI 企业配置会合并四类 settings。单值字段按优先级覆盖：

1. System Defaults：`system-defaults.json`
2. User Settings：`~/.gemini/settings.json`
3. Workspace Settings：`<project>/.gemini/settings.json`
4. System Overrides：`settings.json`

System Overrides 拥有最终决定权。数组和对象字段会合并，例如 `includeDirectories` 可能拼接，`mcpServers` 可能按 key 合并。

Firecrawl 抓到的官方企业页也强调：allowlist 比 blocklist 更稳，`tools.core` 适合明确允许哪些内置工具，`tools.exclude` 更适合少量补充限制。企业默认策略不要只靠 exclude。

系统级 settings 路径：

- Linux：`/etc/gemini-cli/settings.json`
- macOS：`/Library/Application Support/GeminiCli/settings.json`
- Windows：`C:\ProgramData\gemini-cli\settings.json`

也可以用 `GEMINI_CLI_SYSTEM_SETTINGS_PATH` 指定路径。企业落地时通常会用 wrapper script 固定这个环境变量，避免用户随意改到另一份 settings。

## 共享环境隔离

在 CI、共享构建机或实验平台上，不要复用默认 `~/.gemini` 状态。官方支持用 `GEMINI_CLI_HOME` 把 Gemini CLI 的配置和历史隔离到指定目录：

```bash
export GEMINI_CLI_HOME="/tmp/gemini-job-123"
gemini
```

这样能减少不同用户、不同 job 之间的配置污染。

## 配置建议

个人偏好不要覆盖组织策略。团队默认配置应通过项目级 settings 和企业系统级 settings 统一管理。高风险工具不要只靠口头约定，应该结合 `tools.core` allowlist 和 policy engine 控制。

| 配置目标 | 推荐落点 |
| --- | --- |
| 个人 UI 偏好 | 用户级 settings |
| 团队 MCP 默认 | 项目级或系统级 settings |
| 企业不可绕过策略 | Admin controls / system overrides |
| CI 隔离 | `GEMINI_CLI_HOME` |
| 成本和审计 | telemetry + Cloud project |

## Rollout 顺序

企业落地不要一次性全员强推。更稳的顺序是：

1. 在测试机器上验证系统级 settings。
2. 给一组试点用户启用默认配置。
3. 验证 policy、MCP、telemetry、模型选择和成本归属。
4. 再推广到团队或组织。
5. 保留回滚路径和配置版本记录。

这样可以把“配置语法正确”和“组织实际可用”分开验收。

## 验收方式

企业配置验收要看“最终合并结果”，不能只看某一份文件。至少验证三件事：系统覆盖是否高于用户配置，MCP server 是否按企业配置生效，`GEMINI_CLI_HOME` 或系统 settings 路径是否没有泄露到普通用户可写目录。

还要验证用户是否能通过环境变量改到另一份系统 settings。若使用 `GEMINI_CLI_SYSTEM_SETTINGS_PATH`，wrapper script 和终端入口都要统一，不要只改一台测试机。

## 接下来去哪

<Cards>
  <Card title="Enterprise controls" description="继续看组织级 controls、policy、telemetry 和不可覆盖边界。" href="/docs/gemini-cli/official/06-security-enterprise/63-enterprise-controls" />
  <Card title="Policy engine" description="工具权限要进入 policy，而不是只靠团队口头约定。" href="/docs/gemini-cli/official/06-security-enterprise/61-policy-engine" />
  <Card title="Telemetry" description="企业落地还要设计日志、审计和可观测性。" href="/docs/gemini-cli/official/06-security-enterprise/64-telemetry" />
</Cards>

## 官方来源

- [Gemini CLI for the enterprise](https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/enterprise.md)
- [Gemini CLI settings](https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/settings.md)
