每个客户都要一套专属功能，产品团队扛得住吗？用 Vendo 把定制需求留在受控边界内
B2B SaaS 的“定制化”往往从一张报表开始：客户希望把两个指标放在同一页、在某个状态变化时提醒 Slack，或给现有表单多加一个业务字段。传统处理方式只有三个：塞进产品 roadmap、交给交付团队做一次性开发，或者让客户回到表格和外部自动化工具。前两种把工程产能变成瓶颈，后一种则让数据、权限和操作散落在产品之外。
Vendo 试图把这个矛盾换一个位置处理。它不是让客户拿到源码后自行“vibe coding”，而是把 Agent 嵌在既有产品里：客户用自然语言描述需要的视图、微型应用或自动化；生成内容通过产品自身 API 读取数据、执行动作，并在品牌一致的界面中运行。对产品团队而言，关键不在于“能不能生成一个页面”，而在于怎样让生成能力始终经过可审计的工具调用边界。
先区分：定制 UI 与可执行的客户应用
聊天窗口里临时出现一段 UI，和可以保存、复用、定时运行的客户应用，并不是同一件事。前者通常只负责回答当前问题；后者可能成为团队每天使用的业务流程，因而必须处理状态、权限、失败和后续维护。
Vendo 的开源仓库把它定位为“嵌入式 Agent”：它代表已登录用户，通过宿主产品的 API 行动，而不是直接修改宿主源码。项目说明将其工作拆为三个层次：
- Extract：读取产品 API，并将可用能力变成 Agent 工具；
- Generate：生成视图和用户拥有的小应用；
- Guard：在统一执行点放置策略、审批、授权、断路器与审计。
这种划分很重要。若模型既写界面、又随意构造请求、还直接访问第三方系统，出错后很难判断问题在生成、权限还是数据层。把“能做什么”收束为宿主 API 工具，至少能让动作入口保持有限且可观察。
安装只是起点，先让它认识宿主产品
仓库给出的最小安装流程如下：
npm install @vendoai/vendo npx vendo init
npx vendo init 不应被理解为把一个聊天组件丢进 React 应用。根据项目的 Launch HN 说明，它会读取产品的 API 表面、主题与路由等信息，为后续生成提供宿主上下文。实际接入时，应把这一步当作一次接口盘点：哪些 API 可以暴露为工具？哪些只能读不能写？哪些调用必须由最终用户确认？
一个更稳妥的产品侧顺序是：先选择只读、低风险的场景，例如“生成本周异常订单报表”；验证审计记录与权限继承无误后，再逐步引入写操作和跨工具自动化。不要一开始就把付款、删除、权限授予等高影响动作交给生成式工作流。
生成代码不等于获得执行权限
Vendo 对生成 UI 的一个具体做法是将组件放入隔离环境。项目说明提到：生成组件可在 iframe 隔离环境中运行，并限制 connect-src 'none'；需要更强隔离时，Launch HN 介绍了 QuickJS VM：组件在其中以 Preact 运行，不能直接访问 DOM、网络或时钟。
这意味着生成组件不能自行绕过产品后端发请求。当用户点击按钮时，隔离环境产生工具调用，由宿主经 Vendo 的 guard 执行，再把结果传回同一运行环境。它不是万能安全证明，但提供了清晰的控制面：
- UI 代码与宿主页面隔离，降低直接篡改页面的机会；
- 数据应来自已注册的 API 工具，而非模型凭空拼出的 URL；
- 高风险工具可以要求审批，且调用能进入审计链路；
- 工具失败时可返回结构化结果，而不是让模型用猜测填补空白。
因此，产品团队要审查的核心对象不只是提示词，还包括工具清单、每个工具的输入 schema、用户身份映射和审批策略。“规则写进代码通常比规则只写进提示词更可靠”也是 Vendo 团队在发布说明中强调的工程取向。
一个可落地的场景：客户自建逾期跟进台
设想财税或供应链 SaaS 的客户提出需求：“每天早上列出缺资料的客户；离截止日两天内的项目标红；把需要人工跟进的条目发到 Slack。”这类需求经常不值得为每一家客户开发一个固定模块，但又确实依赖产品里的实时业务数据。
在受控设计中，产品只需要向 Agent 暴露经过最小化授权的能力：查询项目、读取截止日期、创建跟进任务，以及发送一条受限的通知。客户描述目标后，生成的应用可以组合这些能力形成视图和自动化；但它不能取得数据库直连凭据，也不能调用未登记的管理接口。
上线前应明确三条边界：第一，通知或任务创建是否每次都需要确认，还是允许在用户预先授权的范围内定时执行；第二，生成应用是否能被团队共享、复制和撤销；第三，客户把它当成关键流程后，谁负责版本、故障提示与人工接管。HN 讨论中也有人指出，客户生成的流程会逐渐变成“业务关键”；这不是反对定制化，而是提醒团队必须把支持与治理设计在前面。
模块化架构给团队什么选择
Vendo 不只有一个单体包。仓库列出的包将存储、运行时、动作、治理、应用生成、自动化、UI 与 MCP 分开；默认组合是 @vendoai/vendo。其中 PGlite 可作为零配置数据存储，生产环境则使用同一 schema 对接 Postgres。项目采用 Apache-2.0 许可证，开源部分可自托管；某些云端分享、发布和组织能力需要 VENDO_API_KEY。
这对已有 Agent 架构的团队尤其有用：如果已经有自己的模型调用循环，可以关注工具包与 guard，而非强行替换整套聊天体验；如果还没有 Agent，则可从默认组合开始。文档还列出将宿主工具通过 MCP 提供给外部客户端的路径，不过这会扩大客户端与授权面，应该单独评估，而不应顺手打开。
适合谁，又不适合谁
Vendo 适合 API 边界清晰、客户差异大、但不希望为每个差异长期维护分支的 B2B 产品。它最有价值的地方不是替代产品规划，而是把长尾的报告、工作台和轻量自动化放进产品自己的身份、数据与审计体系。
它不适合把“任意自然语言”直接升级为无限权限。在缺少稳定 API、没有角色权限模型、无法承接客户生成流程的支持成本，或涉及不可逆高风险操作时，先补齐产品基础设施比接入生成 UI 更重要。好的路径是从只读场景开始，逐步扩大工具面，并把每一次权限扩大都视为产品与安全评审，而不是一次模型配置。
把失败当成产品能力来设计
生成式定制最容易被忽略的不是首次演示，而是第二周的变化：某个 API 字段改名、用户权限被回收、定时任务遇到限流，或原先“只是一个报表”的应用被团队当作日常决策依据。因而工具调用的返回值应能区分无权限、参数不合法、上游失败和需要人工确认；界面也应显示数据的更新时间与失败状态，而不是用模型生成的解释掩盖错误。
同时，为每个生成应用保留创建者、所用工具、授权范围、版本和最近运行记录。这样客户要交接、暂停或删除一个流程时，团队不必从聊天记录里猜它做过什么。Vendo 的 packages 将自动化、审计与 guard 分层，提供的是实现这种治理的切入点；最终是否可靠，仍取决于宿主产品是否把工具 schema、幂等性、限流和人工兜底真正落实。