企业采用 Claude Code，不能只看“模型会不会写代码”。更关键的是：权限如何控制，API 如何接入，MCP 如何鉴权，token 如何审计，开发者环境如何统一。
过去两天 Claude Code 的 GitHub 更新和 issue 很适合作为观察样本。v2.1.137 修复 Windows 上 VS Code 扩展激活失败；v2.1.136 修复 MCP OAuth refresh token 并发丢失、/clear 后 MCP server 消失、Plan mode 写文件拦截、WSL2 图片粘贴、CJK 终端显示、插件 hooks 等问题；v2.1.133 还修复了代理、mTLS 没有覆盖完整 MCP OAuth 流程的问题。
这些都是企业接入时会遇到的真实问题。
一、MCP 是能力入口，也是治理入口
Claude Code 通过 MCP 连接外部系统。企业内部可能接代码仓库、知识库、工单、CI、日志平台、数据库只读查询、云资源管理接口。能力越强，边界越重要。
建议把 MCP 分为三类：
只读工具：文档、issue、PR、日志查询。
受控写工具：创建分支、提交 MR、更新工单状态。
高风险工具：生产数据库、云资源变更、密钥和权限系统。
Claude Code 近两天关于 MCP OAuth、server reconnect、工具列表显示的修复说明，MCP 不是一次配置完就不用管的东西。企业应保留登录审计、工具调用日志、失败重试记录，并对高风险工具增加二次确认。
二、模型网关比单点模型更重要
企业不会永远只用一个模型。复杂设计可以用 Claude 4.7，测试生成可以用 GPT-5.5，低成本批处理可以用更便宜的模型。关键是让开发者工具看到稳定的模型入口。
Claude Code 的 model configuration 文档支持 ANTHROPIC_BASE_URL，并可通过 CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1 从兼容 gateway 的 /v1/models 发现模型。这个能力适合企业统一管理模型路由。
国内团队还要考虑 Anthropic 官方 supported countries policy、网络稳定性、账单、合规审批。词元无忧 API（token5u API）这类多模型 API 平台，可以作为试点阶段的统一入口：先让团队验证 Claude Code 工作流，再逐步纳入内部审计、额度和权限体系。它的角色不是替代企业网关，而是降低早期多模型接入成本。
三、权限和工作区隔离要先设计
Claude Code 能读写文件、运行 shell、创建 worktree。企业落地时建议默认采用临时分支或隔离 worktree，避免 agent 直接改主工作区。v2.1.133 新增 worktree.baseRef，允许选择从 origin/ 或本地 HEAD 创建 worktree，这对企业流程很关键。如果开发者有未 push 的本地提交，baseRef 选择不当会导致 agent 看不到最新改动。
还要注意 Plan mode。v2.1.136 修复了 Plan mode 在某些 allow rule 下没有正确阻止文件写入的问题。企业如果依赖“先计划、后执行”的审批流程，应确认版本已经更新，并做一次本地验证。
四、token 和成本审计不能后补
GitHub issue 中出现了 stream idle timeout、retry loop、tsc 循环、weekly limit 快速消耗等反馈。AI agent 的成本不是“调用一次模型多少钱”，而是一次任务里读了多少文件、失败重试多少次、是否命中缓存、是否反复跑工具。
建议企业至少记录：
模型名称和版本，例如 Claude 4.7、GPT-5.5。
输入、输出、cache creation、cache read token。
MCP 工具调用次数和失败原因。
shell 命令、退出码、耗时。
文件改动范围。
没有这些记录，出了问题只能看开发者截图。
五、国内企业的额外限制
国内团队要提前评估：
官方 Claude 服务所在地区是否可用。
公司代理、证书、DNS 是否影响 OAuth。
GitHub、MCP 服务、模型网关是否在同一网络策略下。
数据是否允许出境。
API key 是否能集中管理。
供应商是否提供日志、限额和故障响应。
Claude Code 可以提高工程效率，但它不是一个可以随便装到每台电脑上的玩具。企业真正要建设的是“AI 编程工作流治理层”。
