这一层最容易被“新操作系统”叙事带热

只要企业真的开始把 Agent 放进生产环境，立刻就会出现一串新需求：怎么部署、怎么隔离、怎么授权、怎么监控、怎么在错误动作落地前拦住、怎么让 Agent 真正持有并花钱。这些需求全部都是真的，所以基础设施层一定会热。问题在于，需求真实不等于每一层都值得独立估值。

这一组项目真正要回答的，其实是控制点问题。它到底站在控制平面上，还是只做了一个围绕 Agent 的功能插件？只要这个问题没看清，就很容易因为 category 叙事太新而高估整组公司。

IncidentFox：最难也最贵的一类 Agent 问题

IncidentFox 试图做 AI SRE agent，帮企业 triage、协调并修复生产事故。这是个非常好的切口，因为只要它真正有效，给客户省下来的不是人力，而是 downtime、brand damage 和工程团队的心智负担。

但它也是 adoption 难度最高的一类。企业愿意接受自动 incident investigation，比接受自动修复更容易；而从 investigation 到可信的 remediation，中间隔着大量系统上下文、安全边界和责任问题。

  • 成熟度：公开信息显示产品边界和技术方向都已经很清楚，但商业落地仍处在较早阶段。
  • 方向潜力：SRE 是高价值预算，单客户价值和粘性都可能很高，一旦做成就是非常好的 enterprise product。
  • 商业价值：如果它只能做事故观察和建议，价值不错但未必稀缺；如果它能走到可信 remediation，价值会陡然放大。
  • 投资判断：值得高关注，但 adoption 节奏一定慢，必须用 enterprise trust build 的速度去预期它。
  • 下一个验证点：从 incident triage 走向自动 remediation 的真实比例、生产环境中的人工审批深度，以及首批客户是否愿意把更高风险权限开放给它。

Terminal Use：如果 background agent 成真，这层就会很值钱

Terminal Use 用 “Vercel for background agents” 这个定位去切 orchestration，尤其强调使用文件系统的 background agents。这个方向之所以值得看，是因为它抓住了一个正在出现的现实：越来越多真正有价值的 Agent，并不是前台聊天框，而是在后台持续执行、读写文件、隔离资源、循环评估与部署。

这类公司的最大问题不是需求是否存在，而是最终谁来吃掉这层价值。Terminal Use 必须证明自己不是又一个 ephemeral infra wrapper，而是开发者真的会依赖的执行环境。

  • 成熟度：仍在早期，但问题抓得非常准，团队的 Palantir 背景也有助于 enterprise-facing 的 execution。
  • 方向潜力：只要 background agents 成为企业默认形态之一，orchestration 层就会自然变重。
  • 商业价值：最关键的不是托管本身，而是隔离、评估、部署和持续改进这一整条工作流能否形成黏性。
  • 投资判断：这是我愿意继续深挖的基础设施项目之一，因为它抓到的是非常靠近 execution 的层。
  • 下一个验证点：开发者留存、平均 agent runtime 时长，以及是否开始形成与具体模型厂商无关、迁移成本明显上升的工作流黏性。

Agentic Fabriq：最有“平台控制面”潜质的一类项目

Agentic Fabriq 的一句话是 “Okta for Agents”。如果企业未来真的在内部大规模使用 Agent，那么身份、权限、审计和工具访问边界一定会重新定义。今天的 IAM 系统并不是按 autonomous agent 设计的，这给了新公司一个真实窗口。

问题同样清楚：身份与权限市场最终极度容易被 incumbent 盯上。Agentic Fabriq 必须先抢到“agent-native governance”这块心智，再把自己做成默认控制面，才能避免被更大 IAM 厂商当成功能补丁。

  • 成熟度：仍早，但问题是真问题，而且是大企业会认真买单的问题。
  • 方向潜力：只要企业 Agent 使用扩大，identity governance 会从 nice-to-have 变成 must-have。
  • 商业价值：相比普通 observability，权限控制层更靠近真正的控制点，因此平台潜力也更高。
  • 投资判断：如果这组基础设施公司里要选最像“未来平台控制面”的方向，Agentic Fabriq 会在我名单前列。
  • 下一个验证点：是否拿到真正的 enterprise design partners、能否挂到关键数据源和工具链上，以及它在现有 IAM 体系中到底是外挂还是正在成为独立控制面。

Clam：它不是纯安全产品，而是自动化执行层

Clam 很容易被外界讲成“Agent 安全公司”，但从 YC 公开材料看，它更像带安全约束的 AI integration engineer 和 self-fixing automation 层。这个定位其实更有意思，因为它试图解决的不只是安全，而是 automation build-and-break 的整个循环。

这类项目的吸引力在于，它面对的是 startup 最实际的痛点：没人有时间自己持续修自动化。但这也意味着它很容易掉进轻咨询与轻项目制的陷阱，最后变成“很好用，但难复制”的产品。

  • 成熟度：方向明确，但离标准化产品还有距离，交付形态需要持续观察。
  • 方向潜力：如果它真能降低 automation maintenance 成本，会比传统 no-code 工具有更强的留存。
  • 商业价值：决定成败的不是安全标签，而是能不能真的把 broken workflow 自动修起来。
  • 投资判断：谨慎乐观。它抓到的是痛点，但必须尽快证明自己不是一门隐性的服务生意。
  • 下一个验证点：自动修复成功率、同一客户内部的自动化扩张速度，以及新客户上线是不是越来越少依赖人工定制。

Salus：离执行动作越近，价值越硬

Salus 的定位很清晰：在 Agent 的动作真正执行之前，先做 runtime validation。这个位置比事后监控更靠前，也更接近真正的 business risk。因为很多企业要的不是“事后知道它错了”，而是“别让它先把退款、审批、改库动作做错”。

在我看来，Salus 之所以值得高看，是因为它站在 action gateway 上，而不是站在报告层上。只要它能把“拦截错误动作 + 提供 retry feedback”做好，就天然比纯 dashboard 更有结构性价值。

  • 成熟度：产品边界非常清楚，是典型的早期但形状正确的项目。
  • 方向潜力：随着 Agent 开始做高风险动作，runtime validation 的需求只会更强。
  • 商业价值：action gateway 通常比 observability dashboard 更接近控制点，也更不容易被简单替代。
  • 投资判断：这是我会重点关注的中间层公司，因为它离真正的业务风险很近。
  • 下一个验证点：被拦截的错误动作占比、误杀率、对客户实际损失的减少幅度，以及是否能站进关键工作流默认链路。

Sentrial：Datadog for Agent Reliability 是好叙事，但会很拥挤

Sentrial 的价值主张简单明快：检测 loops、hallucinations、tool misuse 和用户挫败感。这个叙事非常适合当前市场，因为每个 deploying agents 的团队都能马上理解它在解决什么。

但它同时也落在最拥挤的一层。因为一旦大家都意识到 agent observability 很重要，就会有大量公司朝这个方向涌入，最后比拼的是谁先成为默认入口，而不是谁先讲明白问题。

  • 成熟度：产品故事完整，但仍处于 category building 初期。
  • 方向潜力：生产环境监控一定存在需求，只是最后会不会沉淀成少数大平台仍未定。
  • 商业价值：如果它能拿到默认 dashboard 位置，扩展空间很大；如果没有，就容易变成功能层。
  • 投资判断：值得跟踪，但必须看清 design partner 和长期留存，而不是只看叙事顺畅度。
  • 下一个验证点：监控告警是否被工程团队持续使用、是否形成跨团队默认入口、从可视化走向 remediation 的能力，以及是否出现明显的客户扩张信号。

Moda：同样做监控，但更偏业务后果视角

Moda 也做 reliability & monitoring，但它更强调 hallucination、forgetfulness、tool call failures 对用户留存、NPS 和 churn 的影响。这个视角比单纯技术日志更贴近 business owner。

这当然是一个有价值的差异化，但问题在于，这个差异化到底够不够形成独立 category。很多时候，业务指标只是 observability 的一个上层视图，而不是一条足够独立的新赛道。

  • 成熟度：方向清晰，但和相邻玩家的重叠度较高。
  • 方向潜力：如果企业越来越以业务后果而不是纯技术错误来评估 agent，Moda 的角度会有吸引力。
  • 商业价值：真正难的不是看到“业务后果”，而是成为客户愿意每天打开的默认入口。
  • 投资判断：先观察，不急着高估。这类公司往往输赢很快取决于 distribution。
  • 下一个验证点：业务指标层是否真的驱动采购、客户到底是把它当业务仪表盘还是工程工具，以及这层差异能不能转化成独立预算而不是附加功能。

Sponge：支付入口一旦成立，就是极硬的控制点

Sponge 是这组里上限最高、也最看 timing 的项目之一。它让 agents 能直接持有和使用 bank accounts、cards、crypto，从而成为 autonomous economic actors。三位创始人都来自 Stripe Crypto，这个 team-market fit 很强。

支付和钱包层为什么重要？因为只要 autonomous commerce 真发生，很多中间层都可能被替代，但 money movement 很难被绕开。问题在于，这个未来到底什么时候到来，以及合规、风控和责任界定能否同步成熟。

  • 成熟度：概念远超 adoption，仍处在偏前置的位置。
  • 方向潜力：一旦 agent-to-agent commerce 出现，payment rails 很可能是最稀缺的基础设施之一。
  • 商业价值：支付基础设施天然具备网络效应和平台控制点价值，这是它最诱人的地方。
  • 投资判断：高赔率、高 timing risk。适合把它看成未来 autonomous commerce 的支付期权。
  • 下一个验证点：真实交易量、首批 agent-native 商户或平台接入、KYC 与风控流程是否开始产品化，以及是否出现真正“agent 直接采购”的高频场景。

把这八家公司放在一起后，最值得记住什么

这八家公司不该被一股脑归成“Agent 基础设施”。更准确的说法是，它们站在不同深度上。

  • IncidentFox、Terminal Use、Salus 更靠近执行层。
  • Agentic Fabriq 更靠近权限和控制面。
  • Sentrial、Moda 更靠近监控与诊断层。
  • Sponge 更靠近支付与资金入口。
  • Clam 则更像执行型自动化层。

站得越靠近执行、身份和资金，控制点价值通常越高；站得越靠近“看见问题”和“报告问题”，越容易落入拥挤和 bundling。对这一组项目，真正要看的不是谁更会讲 Agent，而是谁最先站到不容易被绕开的那一层。

竞争格局会怎样展开：两头挤压，中间最难

这组基础设施公司未来大概率会同时承受两类压力。第一类来自上游模型与 agent framework 平台。只要 Anthropic、OpenAI、云厂商和 orchestration 平台继续往下做部署、权限、监控和评测，它们就会不断蚕食“通用中间层”的叙事空间。第二类来自下游 vertical agent 公司。很多垂直应用一旦把工作流跑深，会自己长出最贴业务的验证、监控与权限层，不一定愿意再额外挂一套独立产品。

所以最难的位置，其实是“看起来像平台、实际上只是横向补丁”的那层。纯 observability、纯 dashboard、纯 reporting 工具最容易被双向压缩。相反，真正贴着动作执行、身份边界和资金流转的公司，虽然更难做，但也更有机会形成无法被轻易替换的基础设施位置。

谁更容易被 bundling，谁更可能长成平台

如果从 bundling 风险看，Sentrial 和 Moda 所在的监控层风险最高。不是因为需求不真，而是因为监控太容易被更大的开发平台、模型平台或安全平台顺手纳入。Clam 也面临类似压力，只是它如果能把“自动修复 broken workflow”做成明显结果，仍有机会从工具层往执行层抬升。

相比之下，Terminal Use、Agentic Fabriq、Salus 和 Sponge 更接近平台位。Terminal Use 站在 agent runtime 与 orchestration 上；Agentic Fabriq 站在身份和治理上；Salus 站在动作放行前的 action gateway 上；Sponge 则试图站到 agent economy 的支付 rails 上。它们共同的特点是，一旦进入默认链路，替换成本会显著高于普通 dashboard。

IncidentFox 有点特殊。它不是典型横向基础设施，但如果它能在高价值 incident workflow 中建立可信自动 remediation，它会拿到一种“结果型控制点”。这类控制点不像平台权限层那样通用，却可能比通用监控更有预算穿透力。

哪些情况下，这组投资逻辑会失效

第一种失效方式，是企业并没有像今天叙事里假设的那样，把大量高权限 Agent 放进生产环境。如果大多数企业最后仍把 Agent 限定在低风险辅助层，那么身份治理、runtime validation、agent-native payment 这些基础设施都会比预期慢很多。

第二种失效方式，是平台收口过快。如果未来主流 agent stack 被少数大平台以“模型 + 托管 + eval + guardrails + monitoring”打包交付，那么独立中间层能留下的空间会比今天乐观叙事小得多。基础设施公司的机会，不是抽象地服务 Agent，而是尽快占住平台暂时还做不深、客户又已经愿意付费的真实断点。

第三种失效方式，是客户宁可内建。越靠近安全、权限、支付和关键生产动作的层，客户越可能认为这是不能外包的能力。因此这组公司真正要证明的，不只是产品能做，而是它们比客户自建更快、更稳、更便宜，或者更容易通过审计和合规。谁证明不了这一点，谁最后就会停留在概念上。