1. 项目概述当业务团队开始“手搓”应用最近在和一些做教育、电商、内容社区的朋友聊天发现一个挺有意思的现象以前提个需求从评审到排期再到开发上线动辄以“月”为单位。现在不少业务团队自己开始动手了。他们不再只是提需求、画原型而是真的能借助一些新工具快速搭建出可用的应用原型甚至直接上线内测。这背后一个关键的变化是“对话式智能体”的普及以及支撑它快速落地的低代码/后端即服务平台的成熟。我这次深度参与的就是猿辅导内部一个典型的案例。业务方希望打造一个能自动处理用户课程咨询、智能推荐学习路径的对话机器人。传统的路径是业务提PRD → 技术评估涉及NLP、对话管理、知识库、API集成→ 前后端开发 → 测试上线周期长沟通成本高。但这次业务团队的核心成员在少量研发的指导下利用火山引擎的Supabase和一系列AI工具真的把这个Agent给“搓”出来了。整个过程更像是一场高效的“联合共创”而不是单向的“需求交付”。这不仅仅是工具效率的提升更是一种工作模式的转变。它解决的核心问题是如何让最懂业务的人能以最低的技术门槛和最快的速度将业务想法转化为可交互、有智能的数字化产品。Supabase在这里扮演了“数据与后端基石”的角色而大模型提供了“智能大脑”两者结合为业务团队释放了巨大的生产力。2. 为什么是“对话式Agent”与“Supabase”的组合2.1 对话式Agent业务数字化的新界面为什么现在大家热衷于做对话式Agent因为它降低了用户的使用门槛和团队的开发门槛。对于教育业务来说用户学生或家长可能不清楚复杂的App功能分区但他们天然会“提问”“我家孩子五年级数学应用题薄弱有什么课程”“今晚的直播课错过了能看回放吗”一个对话式Agent就是将这些自然语言问题转化为一系列可执行的操作查询课程数据库、调用用户画像服务、检索知识库文档、触发订单或预约流程。它的价值在于交互自然符合人类沟通习惯无需学习复杂的图形界面操作。功能聚合一个对话入口可以串联起查询、推荐、办理等多种后端服务。快速迭代业务逻辑的调整很多时候可以通过修改提示词或知识库内容来完成无需改动前端代码。2.2 Supabase为Agent提供“即插即用”的后端能力业务团队要自己动手最大的拦路虎通常是后端数据库怎么设计API怎么开发用户怎么认证实时推送怎么做这些基础设施的搭建和维护需要专业的后端开发经验。而Supabase的口号是“开源Firebase替代品”它恰好打包解决了这些问题。你可以把它理解为一个“自带电池”的后端云服务托管的PostgreSQL数据库这是核心。业务同学即使不懂SQL优化也能通过直观的表格界面创建和管理数据比如用户表、课程表、对话记录表。自动生成的RESTful API创建表后Supabase自动为每张表生成完整的CRUD API并附带详细的API文档。前端或Agent可以直接通过HTTP请求操作数据省去了手写后端接口的繁琐过程。内置的认证授权提供了邮箱/密码、第三方OAuth如微信、手机号一键登录等多种登录方式并管理用户会话。可以轻松设置行级安全策略实现“用户只能访问自己的数据”。实时订阅功能基于PostgreSQL的监听机制可以轻松实现聊天消息的实时同步、通知推送等场景。存储与边缘函数提供文件存储服务并能运行无服务器函数处理复杂逻辑。对于业务团队来说他们无需关心服务器部署、数据库连接池、API框架选型只需要在Supabase控制台点点鼠标一个安全、可扩展的后端就准备好了。这让他们能将100%的精力聚焦在业务逻辑和用户体验上。2.3 火山引擎的加持本土化与生态集成选择火山引擎上的Supabase还有一层考虑。火山引擎提供了国内稳定的网络环境和合规的数据存储避免了直接使用海外服务的延迟与合规风险。同时它能与火山引擎的其他AI服务如云雀大模型、向量数据库更顺畅地集成形成从智能计算、数据存储到应用开发的一站式闭环这对于追求快速落地和稳定运营的业务团队至关重要。3. 猿辅导对话Agent的核心架构拆解这个项目的目标很明确构建一个能理解教育领域问题、查询相关信息、并给出准确回复或执行操作的智能助手。其核心架构可以概括为“三层智能一个底座”。3.1 应用层多端对话界面这是用户直接接触的部分。我们实现了两个主要入口Web聊天插件嵌入到猿辅导官网或学生端App内作为一个悬浮窗或固定页面。技术上是基于React/Vue构建的简单聊天UI核心是调用中间层的Agent API。企微/钉钉机器人将Agent能力封装成群聊机器人供内部运营团队或教师使用用于快速查询内部知识、处理常见工单。注意界面层尽量保持轻量。业务团队可以使用现成的开源聊天UI组件库快速搭建核心价值不在于界面多炫酷而在于交互流程是否顺畅信息呈现是否清晰。3.2 智能层大模型驱动的Agent核心这是项目的大脑我们采用了经典的“规划-执行”框架。意图识别与规划用户问题首先送达大模型我们选用的是经过精调的专业领域模型。模型的任务是分析问题并生成一个“执行计划”。例如对于问题“推荐一下适合初二学生的物理暑期班”计划可能是1. 查询“课程”表筛选科目为“物理”年级包含“初二”状态为“可报名”的课程。 2. 查询当前用户需先认证的“学习历史”表避免推荐已购课程。 3. 将查询结果整合生成个性化的推荐话术。工具执行Agent根据规划调用相应的“工具”。这里最重要的工具就是Supabase客户端。我们预先将Supabase的数据库模式、表关系、常用查询以文档形式注入模型的上下文并封装好安全的查询函数。模型生成的计划会被解析转化为对Supabase API的具体调用。结果合成与回复工具执行后返回数据如JSON格式的课程列表这些数据再次交给大模型由它整理成自然、友好的语言回复给用户。3.3 数据层Supabase作为统一数据中台所有动态数据都存储在Supabase的PostgreSQL中主要包括业务核心数据courses课程、teachers老师、orders订单。这些表由主业务系统同步或手动维护。Agent运行数据conversations会话记录关联用户ID、messages单条消息包含用户输入、Agent思考过程、工具调用记录、最终回复。这张表对于后续分析Agent表现、优化提示词至关重要。知识库数据kb_articles知识文章。除了结构化数据我们还处理非结构化文档如PDF课程大纲、运营手册。这里用到了火山引擎的向量数据库将文档切片、向量化后存储供Agent进行语义检索用于回答非常规问题。3.4 安全与权限Row Level Security (RLS)这是Supabase中极其重要的一环。我们为每张表都设置了细致的RLS策略。例如messages表SELECT策略是auth.uid() user_id确保用户只能看到自己的聊天记录。courses表SELECT策略可能是true公开可读但INSERT/UPDATE策略则严格限制为管理员角色。 通过RLS我们在数据库层面就实现了数据隔离即使前端代码泄露非授权用户也无法直接访问他人数据极大地提升了安全性。4. 业务团队“手搓”的关键实操步骤下面我以一个具体的功能——“查询用户剩余课时并推荐续费课程”为例拆解业务团队是如何在研发辅助下一步步实现这个Agent能力的。4.1 第一步在Supabase中设计并准备数据表业务同学比如课程运营会先在Supabase控制台的“Table Editor”中操作。创建user_course_balance表id(uuid, 主键)user_id(uuid, 关联auth.users)course_id(uuid, 关联courses表)remaining_classes(integer, 剩余课时)created_at(timestamp)创建course_recommendations表用于存放推荐规则idbase_course_id(基于哪门课程推荐)recommended_course_id(推荐的课程)recommendation_reason(text, 推荐理由如“学完A课程后80%的用户会继续学习B”)导入数据通过CSV上传或SQL编辑器将现有的用户课时数据和推荐规则数据导入对应表中。实操心得表结构设计阶段最好有研发同学简单评审一下确保关系合理并设置了适当的索引比如在user_id和course_id上。Supabase的SQL编辑器对业务同学很友好可以执行简单的CREATE INDEX语句。4.2 第二步测试与验证API表创建成功后Supabase自动生成了API。业务同学可以在“API Docs”页面或使用curl、Postman进行测试。获取用户user-123的所有课时余额curl https://your-project-ref.supabase.co/rest/v1/user_course_balance?user_ideq.user-123 \ -H apikey: YOUR_ANON_KEY \ -H Authorization: Bearer USER_JWT_TOKEN联合查询获取课时详情及对应课程信息-- 在SQL Editor中执行帮助理解数据关系 SELECT ucb.*, c.name as course_name FROM user_course_balance ucb LEFT JOIN courses c ON ucb.course_id c.id WHERE ucb.user_id user-123;通过这个步骤业务同学能直观地理解数据如何通过API获取为后续提示词编写打下基础。4.3 第三步编写Agent的“工具描述”与“提示词”这是业务团队贡献核心价值的环节。他们需要以“自然语言”和“结构化描述”的方式教会大模型如何使用他们刚刚创建的数据接口。定义工具提供给大模型的函数描述{ name: query_user_course_balance, description: 根据用户ID查询该用户所有课程的剩余课时情况。返回信息包括课程名称和剩余课时数。, parameters: { type: object, properties: { user_id: { type: string, description: 用户的唯一标识符 } }, required: [user_id] } }, { name: get_recommendations_by_course, description: 根据某一门课程ID获取系统推荐的后续续费课程列表及推荐理由。, parameters: { type: object, properties: { base_course_id: { type: string, description: 作为推荐基础的原课程ID } }, required: [base_course_id] } }编写系统提示词设定Agent的角色和能力你是一名猿辅导的课程顾问助手。你的任务是帮助用户查询课程剩余课时并根据他们的学习进度提供个性化的续费课程推荐。 你拥有以下能力 1. 通过用户身份信息查询其名下所有课程的剩余课时。 2. 根据用户正在学习的课程查询系统内设的推荐续费课程路径。 工作流程 1. 当用户询问“我的课时还剩多少”或类似问题时首先确认用户身份系统通常会传入当前用户的user_id。然后调用query_user_course_balance工具。 2. 获取结果后用清晰、友好的语言告知用户。例如“您好您目前正在学习《小学数学思维提升班五年级》剩余课时还有5节。” 3. 如果某门课程剩余课时少于3节主动询问“您的《XX课程》课时即将用完是否需要了解后续的进阶课程我可以为您推荐。” 4. 如果用户表示需要推荐则调用get_recommendations_by_course工具获取推荐列表并结合推荐理由向用户介绍。 注意回复要热情、专业专注于解决用户关于课时和课程推荐的疑问。4.4 第四步前端集成与调试研发同学会提供一个封装好的Agent调用组件。业务同学只需要在Web聊天界面中配置好Agent的端点地址、API密钥并将上述工具描述和系统提示词填入对应的配置项。随后就可以在测试环境进行真实对话测试了。当用户说“帮我看看我的课时”时整个流程会自动触发前端传递用户消息和user_id给Agent服务。Agent大模型根据提示词决定调用query_user_course_balance工具。Agent服务执行工具即向Supabase发起API请求。获取数据后大模型合成回复“您好您目前有2门课程《小学数学...》剩余5课时《初中英语...》剩余10课时。”前端显示回复。5. 过程中遇到的典型问题与解决方案5.1 问题一大模型“幻觉”虚构数据或调用错误工具现象用户问“我的物理课还剩几节”Agent回复“您还有8节”但实际数据库里用户根本没报过物理课。根因分析提示词不够精确没有强制要求Agent在缺乏信息时“如实告知”或者工具返回空数据时模型处理逻辑不当。解决方案强化提示词约束在系统提示词中明确加入“你必须严格依据工具返回的数据进行回答。如果查询结果为空你必须如实告知用户‘未查询到相关课程信息’不得捏造数据。”优化工具设计让工具在查询无结果时返回明确的结构化信息如{found: false, message: No records found}而不是空数组[]让模型更容易判断。添加后处理逻辑在Agent服务端对模型的输出做一个简单的规则校验如果回复中包含具体数字但工具调用记录显示查询为空则自动替换为预设的安全回复。5.2 问题二Supabase API调用超时或返回错误现象Agent响应慢或直接返回“调用工具失败”。根因分析网络波动复杂查询未加索引导致慢查询RLS策略配置错误导致权限不足。解决方案实施重试机制在Agent的工具调用代码中对网络请求加入指数退避重试逻辑如最多重试3次。优化数据库查询引导业务团队在创建表时对常用的查询字段如user_id,course_id建立索引。可以使用Supabase控制台的“SQL Execution Time”监控面板找出慢查询。仔细检查RLS策略在Supabase的“Authentication” - “Policies”页面逐条检查策略的SQL表达式是否正确。一个常见的测试方法是在API Docs页面分别用匿名密钥和用户Token测试同一个接口看是否符合预期。5.3 问题三多轮对话中上下文混乱现象用户先问“数学课还剩几节”Agent回答了。用户接着问“那推荐一下后续课程吧”Agent可能无法理解“那”指的是数学课。根因分析简单的聊天记录拼接作为上下文模型可能无法准确关联指代信息。解决方案在Supabase中结构化存储对话我们设计的messages表不仅存用户输入和最终输出还新增了tool_calls和tool_results字段记录每轮对话中具体调用了哪个工具、传入什么参数、返回什么结果。这样在后续对话中可以将上轮的工具调用结果作为重要上下文喂给模型。显式状态管理对于关键上下文如当前正在讨论的course_id由Agent服务端在内存或Redis中进行短暂缓存并在后续提示词中显式注入例如“用户上一轮询问了课程ID为‘math-101’的课时情况现在他要求推荐后续课程。”5.4 问题四业务逻辑变更频繁现象推荐规则变了或者查询课时需要增加新的过滤条件如只统计有效课时。根因分析如果每次变更都去修改提示词和工具调用代码对业务团队来说仍然不够敏捷。解决方案将易变逻辑“数据化”正如我们创建course_recommendations表一样把推荐规则、过滤条件等动态部分放在数据库里。提示词中只写“调用获取推荐规则的工具”具体规则由数据驱动。使用Supabase Edge Functions处理复杂逻辑当业务逻辑变得复杂如计算课时需要跨多张表并应用复杂规则可以引导研发同学编写一个Supabase Edge Function无服务器函数。业务团队只需更新这个函数的逻辑而前端的工具描述和调用方式无需改变。例如将query_user_course_balance工具的背后实现从一个简单的SELECT查询改为调用一个calculate_effective_balance的Edge Function。6. 给其他业务团队的实践建议通过这个项目我深刻感受到让业务团队“手搓”应用成功的关键不在于让他们学会编程而在于提供一套“高杠杆”的工具和清晰的工作流。从小场景切入树立信心不要一上来就做全能的客服机器人。从一个非常具体、高频的场景开始比如“课程信息查询”或“常见问题解答”。快速做出一个能跑通的Demo让业务团队看到切实的成果获得正反馈。明确分工边界研发团队负责搭建“底座”和“护栏”包括Supabase项目初始化、网络与安全基础配置、核心Agent框架封装、提供简单的UI组件。业务团队负责“装修”和“内容”包括数据表设计在指导下、业务提示词编写、知识库内容整理、对话流程测试与优化。投资于“提示词工程”培训对业务团队进行1-2次集中的培训讲解大模型的基本原理、什么是好的提示词清晰、具体、有约束、如何描述工具。这是他们发挥创造力的主要武器。建立数据反馈闭环务必完整记录每一次对话存到Supabase的conversations表。定期比如每周和业务团队一起Review这些对话日志分析Agent在哪里答得好哪里答得不好。不好的case是优化提示词、补充知识库、还是需要新增工具用数据驱动迭代。安全与合规前置从一开始就要和法务、安全部门沟通。特别是涉及用户数据查询的工具必须通过RLS等手段确保最小权限原则。所有对外回复的内容最好能经过一个内容安全过滤层避免模型生成不当内容。这个模式的价值正在显现。猿辅导的这个对话Agent从构思到第一个可用版本上线周期压缩到了两周以内。更重要的是业务团队现在可以自主地添加新的问答能力他们发现用户经常问“老师背景”就自己新建了一张teacher_profiles表写了一段提示词和工具描述几个小时后Agent就具备了介绍老师的功能。这种敏捷性是传统开发模式难以企及的。Supabase降低了数据管理的门槛大模型提供了自然语言的理解与生成能力两者的结合真正让业务团队握住了将想法快速转化为数字生产力的钥匙。