2026 年 7 月 15 日,Y Combinator S26 批次的 Vendo 在 Hacker News 上线公开 beta(2 颗星),定位「让用户在你的产品之上自建功能」的开源定制层。Vendo 的工程回答是给 B2B SaaS 提供一个「嵌入式 Agent」:Agent 复用产品的现有 API、主题、路由作为已登录用户身份行动,在 sandboxed、brand-native 的界面里渲染用户描述的 UI——而不需要 SaaS 团队为每个客户的微小定制需求写一行代码。Vendo 的工作流分为三步:Extract 读取产品的 API surface 转为 Agent 可调用的工具;Generate 在 iframe jail(connect-src 'none')或 QuickJS 沙箱里执行 Agent 生成的 UI 代码;Guard 在执行 choke point 集中处理策略、审批、授权、断路器、审计。Vendo 的设计哲学精确命中了 B2B SaaS「每个客户都要一点不同」的现实痛点:与其把这些请求放进产品路线图、变成一次性工程工作、或推给客户的电子表格,Vendo 让用户自己在产品里创建缺失功能。两件事合在一起,清晰勾勒出 2026 年「让用户在你的产品之上自建功能」这条 SaaS 工程化路径的真实门槛:**嵌入式 Agent 必须把「Agent 写 UI 代码 → UI 在沙箱里跑 → 客户用产品的真实 API 调用基础设施」三件事工程化**,而不是停留在「演示一个 Agent 生成漂亮界面」的层面。
一、SaaS 「每个客户都要一点不同」的根本痛点
在过去二十年的 SaaS 演进中,产品团队长期面临一类结构性矛盾:产品要做「通用化」才能服务更多客户,但每个客户都有「特殊需求」要求产品做「定制化」——通用化与定制化在产品工程上是天然冲突的。传统 SaaS 的应对策略有三种:把这些定制需求放进产品路线图(等几个月到几个季度才上线,客户体验差);由工程师做一次性定制开发(成本高,不可规模化);让客户用电子表格、外部工具、Zapier 等 workaround(数据脱节,体验割裂)。
Vendo 给出了第四种工程回答:**让 Agent 实时理解产品 API、实时生成 UI、实时让用户验证、实时把生成的 UI 部署到沙箱里跑,整个过程不离开产品**。这一选择直接消除了传统定制开发的时间与成本瓶颈,同时也避免了「外部工具」造成的体验割裂。客户在产品里描述自己需要什么,Agent 在几分钟内生成可用的功能,客户立即在产品里试用,任何调整都通过自然语言对话完成。整个流程从「季度级」压缩到「分钟级」,从「工程外包」压缩到「自助服务」。
二、Vendo 的三步架构与 QuickJS 沙箱设计
Vendo 的工程架构围绕三个明确分离的步骤展开。第一步 Extract 解决「Agent 怎么知道产品的能力边界」:读取产品的 OpenAPI、TypeScript 类型、路由配置,自动把这些信息转为 Agent 可调用的工具集。这一步让 Vendo 对产品的集成变得「声明式」——SaaS 团队只需要把 Vendo npm 包安装到产品代码里,npx vendo init 就自动完成 API 抽取与工具生成,不需要 SaaS 团队手写任何 Agent 配置。
第二步 Generate 解决「Agent 创建的 UI 如何安全运行」:Agent 在 Vendo 受控的沙箱里生成 UI 代码(React/Preact 组件),沙箱有严格的隔离边界——iframe jail 的 `connect-src 'none'` 禁止组件直接访问网络;QuickJS VM 禁止访问 DOM、network、clock。沙箱只能返回 UI tree,而真实的数据来自宿主通过 Vendo guard 转发的 API 调用。这一设计与 WebMCP 规范的 untrusted annotation 思路一致:Agent 生成的代码被严格隔离,无法绕过宿主直接访问系统资源。
第三步 Guard 解决「Agent 行为如何被治理」:所有 API 调用、UI 操作、状态修改都必须经过 Vendo guard 单一执行 choke point,在这一 choke point 上实施 policy(哪些操作允许)、approvals(高风险操作需要人类确认)、grants(权限管理)、breakers(异常行为熔断)、audit(完整审计日志)。这一集中治理让 SaaS 团队可以审计所有 Agent 行为、限制 Agent 权限、在异常时熔断——Agent 不会因为 prompt injection 或错误指令而执行超出权限的操作。
Vendo 的沙箱设计尤其值得关注。Agent 生成的 UI 代码运行在 QuickJS VM 里,VM 只能返回 UI tree、不能访问 DOM/network/clock,所有用户点击触发的 API 调用都由宿主通过 Vendo guard 执行,执行结果再回传到 VM。这种「双向隔离」确保了 Agent 生成的代码即使包含恶意逻辑,也无法直接访问产品或客户的数据——任何敏感操作都必须经过 Vendo guard 的策略与审批检查。
三、与同类方案的工程对比
把 Vendo 与同类嵌入式 Agent 方案对比,可以看清工程路径的差异。当前同类方案主要有四类。第一类是「生成式 UI 嵌入聊天」(Vercel AI SDK、CopilotKit、Thesys 等):Agent 在聊天里生成 UI 组件,但生成的 UI 是临时性的、不能跨会话保留、不能被其他用户共享、不能被设置成自动化触发器。Vendo 的差异是「生成的 UI 是持久化的、跨会话可重用、可共享、可触发自动化」,这是 SaaS 产品的核心需求。
第二类是「应用内嵌到别人的 Agent」(OpenAI Apps SDK、MCP Apps):用户的 Agent 应用运行在 ChatGPT、Claude 等外部 Agent 里,Vendo 的差异是「Agent 运行在产品内部」——用户的使用场景是「在 SaaS 产品里创建定制功能」,而不是「在 ChatGPT 里调用 SaaS API」。后者是 SaaS 产品的 API 暴露问题,前者是 SaaS 产品的 UI 可扩展性问题。
第三类是「MCP + 自定义客户端」(blakeashleyjr 在 HN 评论中提到的模式):SaaS 提供 MCP server,客户用 Claude 等 Agent 直接调用。这种模式适合 Agent 工程师,但对非工程岗位的客户不友好——他们没有 Claude subscription、不知道如何用 Agent,只能继续用电子表格 workaround。Vendo 把 Agent 嵌入产品内部,让任何客户(包括非工程岗位)都能用自然语言创建定制功能。
第四类是「SaaS 工程师用 AI 辅助开发」(Claude Code、Codex 等工程师在 SaaS 代码库里):这是 SaaS 团队内部的工作流,不是给 SaaS 客户的。Vendo 让 SaaS 客户自己创建功能,而不是 SaaS 工程师更快地创建功能。
四、企业 SaaS 嵌入式 Agent 的工程新基线
把 Vendo 的设计与同类方案的对比合并,可以提炼出企业 SaaS 嵌入式 Agent 必须落地的五项关键基线。
第一项基线是「Agent 必须以「已登录用户」身份调用 API」。Vendo 让 Agent 用 SaaS 客户的真实身份调用产品 API,这一设计把 Agent 的权限与用户权限绑定,任何越权操作都对应实际用户的越权,而不是「Agent 自己有特殊权限」。这一基线让 SaaS 团队不需要为 Agent 单独设计权限系统,直接复用现有 RBAC、Audit Log、Rate Limiting 等基础设施。
第二项基线是「Agent 生成的代码必须在隔离沙箱里运行」。Vendo 使用 QuickJS VM + iframe jail 双重隔离,Agent 不能直接访问 DOM、network、clock。这一基线把 Agent 生成的不可信代码与产品代码、用户数据、网络资源完全隔离开,即使 Agent 被 prompt injection 攻陷、被攻击者诱导生成恶意代码,恶意代码也无法直接造成损害。
第三项基线是「关键操作必须经过策略 choke point」。Vendo 把所有 API 调用、状态修改、跨用户操作都集中到 Vendo guard 单一执行 choke point,在这一 choke point 上实施 policy、approvals、grants、breakers、audit。这一基线让 SaaS 团队可以在一个地方管理 Agent 的所有行为,而不是把策略分散到产品的各个角落。
第四项基线是「Agent 生成的 UI 必须是持久化的、可共享的」。Vendo 强调生成的 UI 不是「聊天里的一次性组件」,而是「用户在产品里拥有的真实应用」——可以跨会话重用、可以组织内共享、可以设置成自动化触发器。这一基线把 Agent 生成物从「临时」升级到「持久」,让 SaaS 客户真正能够依赖 Agent 创造的功能。
第五项基线是「Agent 安装必须自助化」。Vendo 提供 `npm install` + `npx vendo init` 的自助安装,以及 `agents.md` 让任何 Coding Agent(Claude Code、Cursor 等)自己完成 Vendo 集成。这一基线把 Agent 的工程化门槛降到最低——SaaS 团队不需要为 Vendo 写专门的集成代码,只需要让 Coding Agent 读 `agents.md` 文件。
五、链路视角下的最终结论
Vendo 的工程价值,可以用一句格言概括:**「让 Agent 用产品的真实身份、真实 API、真实数据,在产品里替用户写代码」**。传统嵌入式 UI 系统的痛点是「需要工程师 + 需要时间 + 需要 SaaS 团队排期」,Vendo 通过 Agent 让「客户自己 + 实时 + 几分钟」完成 UI 定制。这一选择不是用 Agent 取代工程师,而是用 Agent 取代「客户提需求 → 工程师排期 → 几个月后上线」的漫长链路,把定制开发的瓶颈从「工程师产能」迁移到「Agent 推理能力 + 沙箱隔离能力」。当 Agent 推理能力提升时,客户能创建的 UI 复杂度自然提升;当沙箱隔离能力增强时,客户能创建的应用范围自然扩大——两个能力维度共同决定了 SaaS 嵌入式 Agent 的产品上限。
把视角拉到企业 AI 落地的长周期,可以看到三个必然迁移。第一,SaaS 必须从「提供固定 UI」迁移到「让 Agent 在产品里生成 UI」,这一迁移让 SaaS 产品从「刚性」变成「可塑」,让每个客户都能拥有属于自己的版本。第二,Agent 生成物必须从「临时」迁移到「持久」,SaaS 产品里的定制功能必须能跨会话、跨用户、跨组织地被重用与分享——这是 Agent 时代的 SaaS 与传统 SaaS 的根本差异。第三,Agent 行为治理必须从「分散」迁移到「集中 choke point」,所有 Agent 触发的敏感操作都必须经过单一治理入口,而不是把策略分散到产品的各个角落。
模型可以迭代——Claude Sonnet 5 之后会有更强的 Sonnet,Fable 5 之后会有更强的 Opus——但 SaaS 嵌入式 Agent 的链路基线(已登录用户身份 / 隔离沙箱 / 集中 choke point / 持久化 UI / 自助安装)不会因为模型升级而失效。把资源投到这些不散的链路层要素上,是企业 AI 落地性价比最高的工程方向,也是把「模型可换、链路不散」立场落到 SaaS 嵌入式 Agent 领域的具体实践。Vendo 给 SaaS 团队一个清晰的信号:Agent 时代的产品不再是被动接受用户反馈的封闭系统,而是能让用户主动创造功能的可塑平台——这一迁移重新定义了 SaaS 的产品形态与商业模式。
