面向客户 VPC 内 AI 厂商的合规 trace 中继，导出脱敏支持证据，不泄露原始数据。

1. AI 遥测数据量正在让传统按字节计费的可观测性定价对 Agent 工作负载在结构上失去经济可行性。
2. 企业买家现在要求遥测数据和 prompt 留在自有云账号内，为厂商制造了新的工具空白。
3. 调试现代 Agent 需要 prompt 级追踪、置信度分数和调用图，而不只是日志和指标。
4. 具名客户和六位数合同证明高端 BYOC AI 可靠性基础设施已有真实预算。

催化因素。 Tsuga 的市场牵引力表明：因为 AI 追踪既高度敏感又体量庞大，企业已开始坚持要求 AI 可观测性留在云内——传统 SaaS 可观测性模式已不适用。

产品在客户租户内（即 AI 厂商已部署应用的地方）部署轻量级采集器和策略引擎。它在本地记录完整的 Agent 追踪、prompt 溯源、置信度分数和调用图，再自动生成脱敏后的故障包、回归差异和基准快照，供厂商集中访问。客户控制哪些字段可以离开账号、证据保留多久，以及是否允许导出回放产物。厂商无需要求客户开放广泛的可观测性访问权限，即可获得跨租户实例群健康状况、发布质量对比，并大幅加快故障处理速度。

差异化。 传统可观测性厂商希望客户购买另一套后端；这家初创公司卖给厂商的是专为隔离客户云部署实例群打造的、以支持为核心的中继。核心 IP 是策略感知的证据打包能力：完整追踪留在本地，只有经过批准的摘要、差异和脱敏产物才能离开租户。这使该产品在客户已有 Datadog、Grafana 或 CloudWatch 的情况下依然有价值——因为它解决的是厂商跨租户调试和发版支持问题，而不是替换客户的工具链。

待完成任务

flowchart LR
  Buyer[BYOC AI vendor] --> Pain[Blind support inside customer clouds]
  Pain --> Product[In-tenant trace relay and policy engine]
  Product --> Outcome[Faster MTTR with safe cross-tenant insight]

高管要点

• 切口真实但较窄：痛点不是泛用监控，而是在客户控制的云中运行 AI 产品的厂商侧支持。
• 私有连接、数据脱敏、留存控制和可审计性是该品类的入门门槛，而非高端附加项。
• 当痛点足够尖锐时预算是存在的，但最早的支出集中在拥有多个在线 BYOC 租户并承受持续 Sev-1 支持压力的 AI 厂商身上。
• GTM 风险更多在于安全审查摩擦和安装复杂度，而非底层遥测技术栈能否构建。

市场定义

面向在客户云中部署的 AI 软件公司的厂商支持和可靠性层，介于通用可观测性工具和托管支持运营之间。

用户与买方

经济决策人通常是面临企业 BYOC 续约的 CTO 或工程副总裁，而日常推动者是目前协调客户手动拉取日志和看板访问的可靠性工程师、平台工程师和高级解决方案工程师。

购买触发点

• 新的或续约的企业账号要求私有云部署，使厂商在没有支持安全中继的情况下无法直接访问。 [2][29][31]
• AI 遥测账单或采样缺口使传统 SaaS 可观测性在经济上和运营上对 Agent 工作负载产生痛苦。 [2][3][21][26]
• 糟糕的发版或跨隔离租户的重复故障，暴露了手动收集证据和实例群对比能力薄弱的代价。 [4][11][24]
• Governance work forces automatic logging, masking, and audit trails into the production checklist before more regulated customers can go live. [8][18][32][36][38]

支付意愿

当痛点足够尖锐时，高端支出是合理的：Tech Funding News 报道 Tsuga 已达数百万美元 ARR、合同均价为六位数，而 Langfuse、LangSmith 和 groundcover 显示付费层级集中在留存、可审计性、支持和企业管控方面，而非单纯的追踪能力。 [2][9][15][23]

品类动态

增长信号 16% 年复合增长率（可观测性市场 2024-2034，引自 Tech Funding News 报道）。

验证信号

• Tsuga 在此架构领域已报告数百万美元 ARR、六位数均价合同及具名客户。
• 邻近可观测性厂商现已将 BYOC、本地部署和隔离部署模式作为一等方案提供。
• 各大云厂商已将私有连接和更严格的 AI 服务数据边界控制常态化，降低技术可行性风险。
• 遥测层正在围绕 OTel 式语义标准化，降低新进入者的连接器风险。

监管与技术约束

• 在受监管环境中访问模型和传输遥测数据，私有网络和无公共出站模式往往是强制要求。
• prompt 和日志的脱敏、删除和可审计性必须是产品一等功能，而非后处理步骤。
• 零留存承诺因云和功能而异；部分服务商工作流仍会留存或监控 prompt 或响应内容。
• AI Act 式要求将自动事件记录、上市后监控和故障证据推入运行时技术栈更深层。

基础设施层竞争拥挤，但厂商支持工作流层仍然碎片化。大多数产品为应用团队或集中式后端优化；专为从许多隔离客户租户向厂商支持组织导出策略安全证据而构建的产品较少。

为什么现有厂商不会默认胜出

• 云平台. AWS、Azure 和 Google Cloud 现在提供买家期望的私有网络和数据边界原语，但仅止于基础设施原语，不解决跨租户厂商支持工作流。
• 通用可观测性套件. Datadog 类平台可统一 AI 和基础设施遥测，但仍假设足够多的数据可以集中至可观测性后端，并在模块化平台合同下付费。
• 开源与自托管方案. Langfuse 和 Helicone 等自托管工具提供本地控制，但买家仍需自己组装导出策略、支持包和实例群级对比流程。
• Agent 生命周期平台. LangSmith 和 Arize 在部署、评估和私有连接方面介入更深，但其重心是应用团队工程生产力，而非跨客户云的厂商安全远程支持。

BYOC Agent 支持中继是一家为 AI 软件厂商提供支持基础设施的公司，服务对象是在客户自有云账号内部署 Agent 的厂商。滩头市场是在受监管行业拥有 5 至 20 个在线 BYOC 租户的 A 轮至 C 轮厂商——这些厂商每周仍依赖客户手动拉取日志和临时脚本处理升级请求。首款产品不是泛用可观测性套件，而是以 AWS 为先的租户内 trace 中继和策略引擎，默认不导出原始 prompt 或追踪数据，而是生成脱敏故障包、发版回归差异和实例群健康信号。该切口精准匹配研究所揭示的购买触发因素——新企业 BYOC 合同、续约或糟糕的发版把厂商可靠性团队压垮。定价应从付费试点开始，再转换为按在线租户数计费的年订阅，因为价值随隔离部署数量增长，而非随席位增长。节奏刻意保持克制：先在一套云、一种支持工作流、一个导出审批模型上跑通，再扩展至多云覆盖、SLA 证明或计费分析。最有力的投入理由是：痛点明确、有高端预算先例，且相对通用可观测性工具具备差异化工作流。最大的否定风险是：安全团队拒绝任何形式的出站产物导出，或具备足够在线 BYOC 租户的真实厂商数量少于预期。研究同样未能厘清私有云主流 Agent 框架或首批预算归属，因此前六个月必须将连接器选择和预算归属作为明确的测试项。

问题

• AI 厂商的产品一旦在客户 VPC 内运行，根因追踪速度便大打折扣——支持团队不得不依赖客户手动拉取日志、共享看板和 SSH 会话来诊断故障。
• 现有可观测性产品要么要求敏感遥测数据离开租户，要么对无采样 AI 追踪定价不合理；而手动流程既无法跨隔离客户环境对比故障，也无法比对回归。

解决方案

• 部署以 AWS 为先的租户内采集器和策略引擎，在本地捕获完整 Agent 追踪，只导出经过批准的脱敏故障包、回归差异和实例群健康摘要。
• 为厂商可靠性团队提供集中式跨租户支持控制台，用于 P1 分诊、发版对比和导出审批，无需强迫客户替换 Datadog、Grafana 或 CloudWatch。

为什么我们会赢

• 产品服务的是厂商的支持和发版调试工作流，而非要求客户购买另一套可观测性后端——从而规避了正面的平台替换式销售。
• 可复用的脱敏策略、导出模板，以及跨多个租户不断积累的脱敏故障包和修复案例语料库，叠加成更快的诊断速度和工作流护城河。

里程碑

flowchart LR
  Wedge[BYOC support relay] --> MVP[AWS-first incident bundle MVP]
  MVP --> Proof[Faster triage and paid pilot conversion]
  Proof --> Expansion[More tenants plus release validation and SLA evidence]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少有一个目标细分市场拥有足够多、当前具备 5 个以上在线 BYOC 租户的厂商，能够支撑高效的创始人主导销售漏斗。
• 安全团队批准预定义脱敏导出架构的频率要足够高，使中继无需每次都经历完整的人工定制审查才能运行。
• 中继在提升获取首个可操作根因包的速度和整体 MTTR 上的效果，足以让买家从现有可靠性或支持预算中划拨资金。
• AWS 为先的部署能够足够标准化，使试点不会演变为定制化服务项目。
• 在位可观测性工具和自托管方案不能充分解决跨租户厂商支持工作流，从而在扩张之前侵蚀切口。

待尽调问题

• 最佳初始潜在客户实际运营（而非仅试点）的在线 BYOC 租户数量是多少？
• 安全团队批准出站故障包前需要具备哪些确切字段和审批步骤？
• 前 20 个潜在客户中哪些云和 Agent 框架组合占主导，从而决定连接器路线图优先级？
• 同类买家在哪里为邻近工具划拨预算：可靠性工程、支持运营还是安全架构？
• 要让潜在客户从试点转化为六位数年合同，需要多少可量化的 MTTR 改善？

模型合理性

• 收入引擎. 基础情景由生产厂商从第 1 年末 2 家增长至 Q4Y3 的 28 家驱动，混合 ACV $130K，大部分价值来自可复制的 AWS 部署和租户扩张。
• 必须成立的条件. 安全审查必须以足够高的频率批准标准脱敏包工作流，使合作伙伴辅助试点能在 Q4Y2 前转化为 14 家生产客户。
• 模型崩溃条件. 若销售周期拉长至 8 至 9 个月或毛利率滞留在 67% 以下，悲观情景将使 EBITDA 持续深度为负，现金底部收缩至约 $0.6M。
• 下一轮融资证明点. 当公司能展示 14 至 20 家生产客户、合作伙伴辅助安装和发版回归追加销售、且不偏离 70% 毛利率路径时，种子轮故事成立。

情景

敏感性

flowchart LR
  Leads[Qualified BYOC vendors] --> Pilots[Paid pilots]
  CACSpend[CAC spend] --> Pilots
  Pilots --> Customers[Production customers]
  Customers --> Tenants[More live tenants]
  Tenants --> Revenue[Annual subscription revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> EBITDA[EBITDA]
  EBITDA --> Cash[Ending cash]
  Churn[Churn and security friction] --> Customers

警示项: 模型假设有足够多的目标账号批准出站脱敏故障包，以在第 24 个月前达到 14 家生产客户，但研究仍未厘清预算归属和导出策略通过率。 · 毛利率只有在部署工作量控制在商业计划约定的每客户两个工程师周阈值附近时才能达到 70% 目标；否则解决方案工作将推高融资需求。 · 收入不含付费试点和入驻费用，使 ARR 保持保守，但若公司为赢得早期订单更多依赖服务，现金路径可能出现偏差。

• 安全审查耗时过长. 每个客户租户在安装中继前可能需要独立进行安全和采购审查。 缓解措施: 优先与已向受监管账号销售 BYOC 的厂商合作，并提供有规范的参考架构、脱敏默认配置和审计产物。
• 在位可观测性厂商功能重叠. 客户可能认为其现有的 Datadog、Grafana 或 CloudWatch 方案已能解决问题。 缓解措施: 将产品定位为运行于客户自有工具之上的厂商侧支持基础设施，聚焦跨租户证据打包，而非替换现有技术栈。
• 滩头市场过于狭窄. 第一年内拥有足够多在线 BYOC 租户的厂商数量可能少于预期。 缓解措施: 先在 BYOC 支持场景落地，再扩展到发版验证、SLA 证明和更广泛私有部署软件市场的计费证据。