随着 Claude Code、Codex、GitHub Copilot 等编程代理工具在 2025 年的快速成熟，越来越多的工程团队开始将这些 AI 助手纳入日常工作流程。然而，一个核心矛盾也随之浮现：企业希望借助 AI 提升研发效能，却难以对这些代理的访问行为进行有效监控和安全管控。传统的 API 密钥分发模式不仅增加了密钥泄露风险，更让安全团队对 AI 消耗的 Token 成本和使用模式几乎处于「盲区」。Tailscale 于 2026 年 1 月推出的 Aperture 正是针对这一痛点的解决方案，它将 Tailscale 在零信任网络领域的积累延伸到了 AI 代理访问层。本文将从架构设计、部署实践和关键参数三个维度，解析 Aperture 如何在不破坏开发者体验的前提下，实现对 AI 代理的统一管控与可见性。
零信任架构向 AI 层的延伸
Tailscale 的核心设计理念是将身份验证作为网络通信的第一公民，这一理念在 Aperture 中得到了延续和扩展。传统的企业 AI 访问模式通常依赖两种路径：要么为每个开发者或 CI/CD 环境单独配置 API 密钥，导致密钥管理成本随团队规模线性增长；要么通过统一代理层进行流量转发，但这类方案往往需要额外部署身份同步机制，难以与现有企业身份体系深度集成。Aperture 的创新之处在于它直接复用 Tailscale 已经在 tailnet 中建立的设备身份和用户身份体系，将每个 AI 请求与具体的用户身份和设备身份绑定，从而消除了对独立 API 密钥的依赖。
这种设计带来了显著的安全收益。首先，由于 Aperture 运行在已有的 Tailscale 网络之上，它能够直接获取 WireGuard 隧道建立时携带的加密身份信息，无需额外的身份同步或凭据传递环节。其次，身份绑定是透明的 —— 当开发者从笔记本电脑向 Claude API 发起请求时，Aperture 能够识别请求者的具体用户身份（如 user:alice@example.com）和设备标签（如 tag:dev-laptop），并将这一元数据记录在访问日志中，而开发者侧几乎感知不到这一层拦截的存在。第三，这种架构天然支持混合环境 —— 无论是开发者的本地机器、虚拟机、容器还是 GitHub Actions Runner，只要能够通过 Tailscale 建立连接，就能够无缝接入 Aperture，无需为每种环境单独配置认证凭据。
从技术实现角度看，Aperture 本质上是一个工作在应用层的反向代理，它位于企业内部网络（或更准确地说，位于 tailnet 内部）与外部 LLM 提供商之间。当开发者配置其 AI 工具指向 Aperture 的端点时，所有请求首先到达 Aperture 网关，网关在完成身份解析后，将请求透明转发至目标 LLM 提供商。这种透明转发机制意味着 Aperture 能够支持 OpenAI 兼容的 API 规范，包括 v1 chat completions 和 v1 responses 两种响应格式，因此不仅能够对接 OpenAI 官方 API，还能够兼容 Anthropic、Google Gemini、AWS Bedrock、Azure OpenAI Service 等几乎所有主流云端和自托管 LLM 部署。
部署架构与关键配置参数
Aperture 的部署设计遵循 Tailscale 一贯的简洁原则，其核心目标是让安全合规的 AI 访问成为「阻力最小的路径」。在实际部署中，管理员首先需要在 Aperture 控制台中添加组织使用的 LLM 提供商配置，这通常只需要提供 API 端点地址和对应的 API 密钥。Aperture 会将这些凭据安全存储，并在转发请求时自动注入。由于 Aperture 采用了 Tailscale 平台的内置身份系统，管理员无需为 Aperture 单独创建用户账户或配置访问控制列表 —— 所有权限管理直接继承自 tailnet 的 ACL 配置。
从开发者体验的角度看，接入 Aperture 的配置开销被压缩到了最低限度。以 Claude Code 为例，开发者只需要在其 ~/.claude/settings.json 配置文件中添加 Aperture 的端点地址，即可完成接入。这一配置可以通过 MDM（移动设备管理）工具批量推送到所有企业设备，确保开发者在首次使用时无需任何手动操作。更重要的是，由于 Aperture 复用了 Tailscale 的身份基础设施，开发者无需为每个 AI 工具单独管理 API 密钥 —— 单个 Aperture 端点可以对接多个 LLM 提供商，开发者只需要在工具配置中切换目标模型，Aperture 会自动处理路由和身份绑定。
在组织规模方面，Aperture 的 alpha 版本支持 3 个免费用户，但这一限制主要针对的是个人或小规模试用场景。对于企业部署，Aperture 可以运行在任何 Tailscale 套餐类型之上，支持的组织规模从数十人到数千人不等。根据 Tailscale 官方透露的信息，对于需要为大规模工程团队部署 AI 代理管控的企业，可以申请专用实例，以获得更高的并发处理能力和更灵活的配置选项。
可见性设计：使用模式与成本追踪
Aperture 的核心价值主张之一是提供对 AI 代理使用模式的完整可见性。在传统模式下，企业安全团队很难回答一些基本问题：哪些团队成员在使用 AI 编程工具？他们在使用哪些模型？每次会话消耗了多少 Token？工具调用了哪些 MCP（Model Context Protocol）工具？这些信息的缺失不仅影响了成本核算的准确性，更让安全团队难以识别潜在的异常行为 —— 比如某台机器在非工作时间发起了大量 API 请求，或者某个用户突然开始访问之前从未使用过的模型。
Aperture 的日志与仪表板功能直接解决了这些问题。它能够追踪的核心指标包括：请求次数、输入 Token 数量、输出 Token 数量、缓存 Token 数量、推理 Token 数量（针对支持推理分项计费的模型）、工具调用次数以及使用的模型类型。这些指标可以按用户、按设备、按时间段进行聚合和筛选，帮助工程和 IT 领导者快速掌握组织内部的 AI 采用趋势。例如，仪表板可以展示某位工程师在过去一周的 Claude Code 使用情况，包括其会话的工具调用分布（bash 命令、文件读取、代码编辑、grep 搜索等），从而为后续的效率优化或安全审计提供数据支撑。
值得注意的是，Aperture 的可见性设计并非简单的「记录并展示」，而是考虑了与企业现有安全基础设施的集成需求。所有收集到的使用日志都可以导出到 S3 存储桶，进而与企业现有的 SIEM（安全信息和事件管理）系统对接。这种导出能力对于需要满足合规要求的企业尤为重要 —— 安全团队可以将 AI 访问日志与其他安全事件日志进行关联分析，识别潜在的数据泄露风险或凭据滥用行为。此外，Aperture 还支持与 Oso 等专注于 AI Agent 安全的产品进行集成，Oso 的仪表板可以展示基于风险评分的工具调用分析，为安全团队提供更细粒度的行为洞察。
从编程代理到更广泛的 AI 代理场景
Aperture 在 alpha 阶段的重点是 CLI 和 VS Code 环境下的编程代理工具，包括 Claude Code、Codex、 Gemini CLI 以及基于自定义框架的代理方案。这一选择具有明确的产品逻辑：编程代理是目前企业采用最成熟、场景最明确的 AI Agent 形态，开发者对其工作模式已经有一定认知，部署和测试的反馈周期也相对较短。然而，Tailscale 明确表示 Aperture 的定位远不止于此 —— 代码生成只是 AI Agent 时代的起点，组织内部还有大量非编码场景的代理工作流正在等待「它们的编码代理时刻」。
从产品路线图来看，Aperture 后续将向两个方向扩展。第一个方向是扩展到更典型的 Chat UI 场景，这意味着 Aperture 不仅要支持命令行工具，还需要兼容通过 Web 界面或 API 调用的对话式 AI 助手。第二个方向是支持更多类型的代理工作流 —— 除了代码生成，AI 代理在数据处理、运维自动化、内容生成等领域的应用正在快速增长，这些场景同样需要统一的身份管理和访问控制。Tailscale 在公告中提到，他们已经看到一些团队尝试将 Aperture 扩展到非编码场景，并计划在后续版本中提供更完善的支持。
这种扩展策略背后反映的是 Tailscale 对 AI Agent 时代的整体判断：随着 Agent 能力的增强和场景的多元化，组织需要一个能够跨越不同工具和用例的统一安全层，而不是为每个 AI 应用单独部署管控方案。Aperture 的架构设计已经预留了这种扩展性 —— 它的核心是一个基于身份的通用代理层，理论上只要目标服务兼容 OpenAI 格式的 API 规范，Aperture 就能够为其提供身份绑定和流量可见性。
落地建议与工程化注意事项
对于考虑在组织内部部署 Aperture 的技术团队，以下几点实践经验值得关注。首先，由于 Aperture 直接复用了 tailnet 的身份体系，组织应当确保现有的 ACL 配置已经覆盖了 AI 访问管控的需求 —— 例如，是否需要限制某些用户或设备组访问特定的 LLM 提供商？是否需要为敏感模型启用额外的审批流程？这些细粒度的访问控制可以直接在 Tailscale 的 ACL 文件中定义，无需 Aperture 单独配置。
其次，对于已经使用 Tailscale 的组织，Aperture 的接入几乎是零迁移成本的 —— 现有的 tailnet 配置、身份提供同步、设备标签体系都可以直接复用。但如果组织此前使用的是传统 VPN 或其他远程访问方案，则需要先完成向 Tailscale 的迁移，才能充分利用 Aperture 的身份优势。这可能是部分企业面临的第一个门槛。
第三，关于成本追踪的落地实践，建议组织在 Aperture 部署初期就建立清晰的模型成本对账机制。由于不同 LLM 提供商的计费模型存在差异（按 Token 计费、按请求计费、推理分项计费等），Aperture 收集的原始指标需要经过一定的换算才能与账单对应。建议组织在 Aperture 的基础上建立自动化的成本分摊脚本，按团队、按项目汇总 AI 消耗，并将这些数据纳入现有的云成本管理流程。
最后，关于安全团队与工程团队的协作模式，Aperture 提供了一个有趣的范式：它让安全管控变成了开发者体验的一部分，而非额外的负担。当 Aperture 成为组织内访问 AI 服务的「最低摩擦路径」时，开发者自然会选择通过合规渠道使用 AI 工具，从而减少了 Shadow IT 带来的安全风险。这种「用进废退」的策略，比单纯依靠禁止和审批更为有效。
参考资料
- Tailscale Blog: A first look at Aperture by Tailscale (private alpha)