Enterprise config
Gemini CLI enterprise configuration：组织账号、Cloud project、Vertex AI、许可、固定策略和团队默认配置。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| Enterprise config | 企业配置 | 管理员统一下发的配置。 |
| 强制 vs 默认 | req/default | 必须遵守 vs 可覆盖。 |
| 分发 | distribute | 给团队统一下发的方式。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你设计 Gemini CLI 的企业配置下发（强制项 vs 默认值）。
你是 Gemini CLI 企业配置顾问。
【角色】
Gemini CLI 企业配置顾问，按最小够用、安全合规优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。
【输入】
- 团队规模和风险偏好：___
- 必须统一的安全 / 行为约束：___
- 想保留的用户自由度：___
- 现有 IT 体系：___
- 经验水平：___
【工作流程】
1. 区分强制项和默认值
2. 设计配置分发方式
3. 对接现有 IT 体系
4. 给变更和审计
5. 给验证
【输出规范】
▌一、强制 vs 默认
▌二、分发方式
▌三、对接 IT 体系
▌四、变更审计 + 验证
【硬约束】
- 安全相关走强制，体验类留默认
- 配置变更可审计
- 对接现有体系，不另起炉灶
- 不要替我臆测情况或编造不存在的配置，信息不全先问清
- 不确定的配置或接口一律以官方文档为准，禁止照搬过时写法企业配置的重点不是“装上 CLI”，而是统一身份、项目、权限、模型、日志和成本边界。
企业配置要看最终合并结果，不只看某个 settings 文件。用户级、项目级、系统级和环境变量可能互相覆盖。
官方企业文档的核心是两层配置：系统级 settings 提供集中默认值和覆盖值，Admin Controls 提供本地不可覆盖的组织策略。系统级 settings 能防误用，但不能防拥有本机管理员权限的人刻意绕过。
企业用户要先确认
- 账号类型：Workspace / organization / personal。
- Gemini Code Assist license。
- Google Cloud Project。
- Vertex AI 是否启用。
- IAM 角色。
- 计费和配额。
- telemetry 和合规要求。
系统级配置层级
Gemini CLI 企业配置会合并四类 settings。单值字段按优先级覆盖：
- System Defaults：
system-defaults.json - User Settings：
~/.gemini/settings.json - Workspace Settings：
<project>/.gemini/settings.json - 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 的配置和历史隔离到指定目录：
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 顺序
企业落地不要一次性全员强推。更稳的顺序是：
- 在测试机器上验证系统级 settings。
- 给一组试点用户启用默认配置。
- 验证 policy、MCP、telemetry、模型选择和成本归属。
- 再推广到团队或组织。
- 保留回滚路径和配置版本记录。
这样可以把“配置语法正确”和“组织实际可用”分开验收。
验收方式
企业配置验收要看“最终合并结果”，不能只看某一份文件。至少验证三件事：系统覆盖是否高于用户配置，MCP server 是否按企业配置生效，GEMINI_CLI_HOME 或系统 settings 路径是否没有泄露到普通用户可写目录。
还要验证用户是否能通过环境变量改到另一份系统 settings。若使用 GEMINI_CLI_SYSTEM_SETTINGS_PATH，wrapper script 和终端入口都要统一，不要只改一台测试机。
接下来去哪
Enterprise controls
继续看组织级 controls、policy、telemetry 和不可覆盖边界。
Policy engine
工具权限要进入 policy，而不是只靠团队口头约定。
Telemetry
企业落地还要设计日志、审计和可观测性。