SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场genkit

genkit

智能体与模型

查看项目

更新于 10-15 16:33

技能介绍

用途

本技能聚焦一个问题：某个 Firebase AI 功能究竟应该做成直接的客户端 SDK 集成，还是可复用的服务端自有 Genkit 工作流。它不是 Genkit 的教程、CLI 目录或 Firebase 产品导览，而是帮助确定当前需求信息包、选择一种归属边界与运行模式，并把 Firebase 平台操作与宽泛的框架比较分流到相邻技能。

适用时机

  • 移动或 Web 应用需要直接的 Firebase AI Logic 客户端 SDK 集成，包括模型设置、结构化输出、流式传输、App Check 或安全的客户端/服务端边界。
  • 后端或全栈功能需要可复用的 Genkit 流程，而不是散落在路由处理器中的一次性 provider 调用。
  • 需要类型化契约、工具调用、检索、提示文件、评估、追踪，或在服务端自有边界下部署。
  • 请求明确涉及 Firebase AI Logic、Genkit，或需要在客户端自有与服务端自有形态之间做决策。
  • 已有的 Firebase AI 功能需要调试、评估、可观测性或上线准备审查。

不适用时机

  • 主要工作是 Firebase 引导、模拟器使用、托管/函数部署、认证登录或管理员 CLI 工作，应转交 firebase-cli。
  • 请求是通用前端流式/渲染，没有 Firebase AI SDK 或 Genkit 边界，应转交相关前端/Web 技能。
  • 真正的问题是宽泛的框架选型（Genkit 对比 Vercel AI SDK 等），应转交 survey。
  • 普通 provider SDK 或简单路由处理器已足够且 Firebase/Genkit 并非必需，则应说明回退并保持轻量。

使用方式

技能按步骤运作：

  1. 框定当前需求信息包：记录应用形态（web/mobile/backend/fullstack/mixed/unknown）、归属（客户端功能/后端能力/混合/未知）、已有材料（路由处理器/功能简报/架构说明/已部署流程/评估追踪问题/部署计划/无）、工作流需求（简单生成/结构化输出/工具/检索/提示文件/评估/可观测性/部署/未知）、交付压力（单端点/多界面复用/上线准备/迁移/可靠性关注/未知）。

  2. 先选择信息包类型：新的后端能力包、已有路由/处理器包、已部署流程质量包、部署/运行时包、比较/回退包，或尚无可用包。规则是不要仅因应用已使用 Firebase 就强行套用服务端 Genkit 流程。

  3. 选择归属层：在命名工具或模型之前，明确客户端与服务端的归属边界。客户端 AI Logic 适用于直接移动/Web SDK 使用、客户端流式或结构化输出、App Check 与客户端可见的模型配置；服务端自有 Genkit 模式适用于可复用的后端 AI 契约、统一管理工具/检索/提示/评估/追踪、跨客户端或作业共享的能力。

  4. 从七个主模式中选一个主要模式（可选一个次要模式）：client-ai-logic、flow-foundation、tool-and-agent、retrieval-and-prompt、evaluation-and-observability、deployment-runtime、comparison-or-fallback。规则是不要将客户端 SDK 接线、后端流设计、部署运维与架构比较混成一团。

  5. 冻结最小功能边界：对客户端模式定义单一应用功能与模型交互、输入/输出或流式契约、客户端可见与服务端专属数据、App Check/认证/错误处理与滥用边界；对服务端 Genkit 模式定义一个命名的后端能力与类型化流契约、必须保留在服务端的内容、可选的工具/检索/提示，以及调用它的客户端或作业。避免巨型流、向客户端泄露服务端密钥，或在一条基本路径可用前就加入工具/检索。

  6. 诚实命名回退或分流：Firebase CLI/模拟器/部署/管理员工作转交 firebase-cli；无 Firebase AI SDK 边界的通用前端渲染转交相关前端技能；宽泛框架比较或架构不确定性转交 survey；轻量非 Firebase 模型调用回退到普通 provider SDK 或路由处理器；耐久性、重试或后台编排占主导的问题转交队列/作业/工作流基座。

  7. 选取最小的下一步切片，不要跳到庞大的系统图：接线一条客户端 SDK 生成/流式路径并加入验证与滥用边界、定义或包装一个服务端流契约、添加一个工具或检索边界、添加一组代表性评估集，或选择一种运行时/部署形态。

  8. 当工作流已存在而信心是瓶颈时，使用评估与追踪：代表性输入、本地追踪审查/Developer UI 检查、小型评估集、契约/提示/工具清理，证据闭环足够好后再推出。

  9. 返回 Firebase AI 实现简报，包含：范围（应用形态、归属、信息包、主模式、信心）、层决策、功能边界（能力、输入/输出或流式契约、客户端可见/服务端专属职责、工具/检索/提示文件需求、认证/App Check/错误与滥用边界）、最小下一步切片、分流/回退。

示例形态

  • 可复用后端支持工作流：预期为 tool-and-agent 或 retrieval-and-prompt，明确的服务端自有流边界与一个工具/检索计划。
  • 直接 Firebase 应用功能：预期为 client-ai-logic，带应用自有 SDK 边界、结构化输出或流式契约、App Check/认证，且无需不必要的服务端流。
  • 已有流程上线前需要信心：预期为 evaluation-and-observability，小型证据闭环，运行时细节与 Firebase CLI 操作分开。
  • 框架选择仍不清晰：预期为 comparison-or-fallback，将宽泛框架选择转交 survey，再带 client-ai-logic 或服务端 Genkit 模式返回。

最佳实践

  • 在命名工具或模型之前先选择客户端或服务端归属边界。
  • 优先一个清晰的功能/流边界，而非庞大的 AI 功能集合。
  • 将密钥与受保护资源保留在服务端；为直接客户端工作定义 App Check/认证与滥用边界。
  • 当普通路由处理器/provider SDK 足够时，应承认这一回退。
  • 将运行时选择视为架构决策，而非 Genkit 必需的证据。
  • 在扩大推出前使用追踪与评估。
  • 当前门边界变化时，同步紧凑的发现界面。

参考资料

  • Firebase Genkit 文档：https://firebase.google.com/docs/genkit
  • Genkit 文档：https://genkit.dev/docs/
  • Genkit 流程文档：https://genkit.dev/docs/js/flows/
  • Genkit 客户端访问文档：https://genkit.dev/docs/client/
  • Firebase AI Logic 文档：https://firebase.google.com/docs/ai-logic
  • Firebase AI Logic Web SDK 文档：https://firebase.google.com/docs/ai-logic/get-started?api=web
  • ../firebase-cli/SKILL.md
  • ../survey/SKILL.md