1. 从“提需求”到“搭应用”一场业务团队的效率革命最近和几个不同公司的产品、运营朋友聊天发现一个挺有意思的现象大家抱怨的焦点已经从“技术排期太满需求做不完”逐渐变成了“我有个小想法想快速验证一下但不想麻烦研发”。这个转变背后其实是业务团队对敏捷性的新追求。他们不再满足于仅仅提出需求而是希望拥有一种能力能自己动手快速将想法转化为一个可交互、可验证的“最小可行产品”MVP。这听起来有点像“手搓”应用——用现成的、低门槛的工具像搭积木一样把业务逻辑拼装出来。猿辅导在对话式 Agent智能体的落地实践中就遇到了类似的挑战。Agent 的核心在于与用户进行多轮、有状态的复杂对话背后涉及意图识别、状态管理、知识库查询、工具调用等多个环节。传统的开发模式是业务团队比如教研、课程顾问提出一个智能辅导或答疑场景的需求然后产品经理出 PRD交给后端、前端、算法工程师进行排期开发。这个周期动辄以“月”为单位等上线时市场反馈或业务重点可能已经变了。而他们找到的“积木”之一是火山引擎的 Supabase。你可能听说过它一个开源的 Firebase 替代品提供了开箱即用的数据库、身份认证、实时订阅、存储等后端服务。但它的价值远不止“替代品”那么简单。对于业务团队而言Supabase 最大的魅力在于它通过一套极其友好的工具链——尤其是其数据库的“表视图”操作、行级安全策略RLS和 Edge Functions——极大地降低了后端逻辑和数据管理的门槛。这让非技术背景的业务人员在少量技术支持的指导下也能参与到应用核心数据流和业务规则的定义中从而加速像对话式 Agent 这类复杂应用的落地闭环。简单说这不是要让业务同学去写复杂的并发代码而是让他们能直接“看见”和“操作”业务数据流并基于此设计对话流程。接下来我就结合对这类场景的理解拆解一下如何利用 Supabase 这套工具让业务团队也能深度参与甚至主导一个对话式 Agent 应用的原型搭建。2. 对话式 Agent 的核心骨架为什么数据层是瓶颈在动手“搭积木”之前我们得先搞清楚要搭的是什么。一个典型的对话式 Agent比如一个智能课程答疑助手它的核心工作流程可以抽象为以下几个环节对话管理维护与用户当前会话的上下文。用户问了什么助理回答了什么现在对话进行到哪一步了这需要持久化存储对话历史。状态追踪记录对话中的关键业务状态。例如用户正在咨询“三年级数学暑期班”那么“科目数学”、“年级三年级”、“意向暑期班”就是需要跟踪的状态。这决定了下一步 Agent 该调用哪个工具如查询课程表或给出什么回复。知识库查询根据用户问题从课程资料、FAQ、政策文档中检索最相关的信息。这通常涉及向量化存储和相似性搜索。工具调用与执行Agent 决定需要执行一个具体操作比如“查询用户剩余课时”、“预约试听课”。这需要安全、可控地调用内部 API 或执行数据库操作。响应生成与呈现将检索到的信息、工具执行的结果组织成自然流畅的回复返回给用户。传统的技术实现中环节 1、2、4 都需要大量的后端开发工作。需要设计数据库表结构conversations,messages,session_states编写 CRUD API实现状态机逻辑并确保每个用户只能访问自己的数据权限隔离。这些工作繁琐、重复且一旦业务逻辑调整就需要修改代码、重新部署。这就是业务团队无法介入的瓶颈所在数据层和业务规则层被封装在复杂的代码之后他们看不见也摸不着。他们可能用流程图画出了一个完美的对话流程但要将流程图转化为数据库表和 API中间隔着一道技术的鸿沟。Supabase 的切入点正是试图填平这道鸿沟。它不直接解决 AI 模型如大语言模型的问题而是为 Agent 所需的数据和逻辑基础设施提供了一套“可视化”和“声明式”的搭建方式。3. Supabase 工具箱业务团队能直接上手的“积木块”那么Supabase 具体提供了哪些“积木”让业务同学也能参与搭建呢我们重点看几个与对话式 Agent 强相关的功能。3.1 数据库与表视图让数据结构“看得见摸得着”Supabase 基于 PostgreSQL但它提供了一个强大的 Web 管理界面——Table Editor。业务人员在技术同事简单培训后可以像使用 Excel 或 Airtable 一样直观地看到数据库中有哪些表。对于我们的答疑 Agent技术同学可以先创建核心表结构profiles: 存储用户基本信息与 Supabase Auth 用户关联。conversations: 存储每次对话会话的元信息如user_id,title,created_at。messages: 存储每条对话消息包含conversation_id,role(user/assistant),content,created_at。session_states: 存储对话的当前状态如conversation_id,state_key(例如 “current_topic”),state_value。创建好后业务产品经理可以直接在 Table Editor 里点击“查看数据”甚至插入一些测试数据。他们能立刻理解“哦原来用户的一次对话是这样存下来的消息是一条条记录的。” 这种直观性比看 API 文档或 ER 图要有效得多。更重要的是他们可以通过“表视图”功能创建自定义的数据视角。比如创建一个“活跃对话视图”只显示过去24小时内有过消息的会话并关联出用户昵称和最后一条消息内容。这个视图可以直接被前端应用调用无需后端另写接口。业务方想要调整这个视图的逻辑比如把24小时改成12小时在界面里修改 SQL 过滤条件即可这种可控感是前所未有的。3.2 行级安全策略用“规则”代替“代码”管理权限这是 Supabase 的“王牌”功能也是能让业务团队定义核心业务规则的关键。RLS 允许你为数据库表设置基于 SQL 的访问策略。以前确保用户只能看自己的对话数据需要后端在每一个查询接口里手动添加WHERE user_id current_user_id。现在技术同学可以在messages表上启用 RLS并创建这样一条策略CREATE POLICY “用户只能管理自己会话的消息” ON messages FOR ALL USING ( EXISTS ( SELECT 1 FROM conversations WHERE conversations.id messages.conversation_id AND conversations.user_id auth.uid() ) );这条策略用白话解释就是“允许所有操作但仅当这条消息所属的会话的user_id等于当前登录用户的 ID 时才生效。”业务团队能做什么他们可以和技术一起用自然语言描述权限规则“学生只能看自己发的帖子和回复”、“课程顾问只能查看分配给自己的学员对话”。技术人员将这些描述转化为类似的 RLS 策略。一旦策略生效无论前端怎么调用 Supabase 客户端库甚至是直接通过 SQL 查询数据安全都能得到保证。业务方可以放心地让前端直接查询messages表而不用担心数据越权。他们参与定义了系统的“安全护栏”。3.3 Edge Functions无服务器函数封装复杂逻辑有些逻辑不适合直接写在数据库策略里比如调用外部 AI 接口、进行复杂的计算、或者调用内部某个老旧系统的 API。这时就需要 Edge Functions。Supabase Edge Functions 是基于 Deno 的无服务器函数。技术同学可以编写一个函数例如handle_agent_turn接收当前会话 ID 和用户最新消息。从数据库查询历史上下文和当前状态。调用大语言模型 API如火山方舟、OpenAI。解析模型返回的意图可能需要查询知识库或调用工具函数。将模型回复存入数据库并更新对话状态。返回回复给前端。编写这个函数是技术工作但部署和管理过程可以极大简化。函数部署后会生成一个唯一的 URL。业务团队可以在他们熟悉的工具如 Zapier、Make甚至 Excel里通过 Webhook 调用这个 URL 来触发 Agent 处理。他们可以测试不同的输入观察输出和数据库的变化从而更深入地理解 Agent 的决策逻辑。3.4 实时订阅让对话流“活”起来对话式应用天然是实时的。Supabase 的 Realtime 功能可以轻松实现。前端可以订阅特定频道的消息比如conversation:${id}。当 Edge Function 将助理的回复写入messages表后利用 PostgreSQL 的触发器Trigger向 Realtime 频道发送一个事件前端监听到事件后就能实时更新界面显示助理的回复。这套机制由技术同学搭建好后业务方感受到的就是一个流畅、无刷新、类似聊天软件的体验。他们可以基于这个体验更准确地提出对交互细节的优化需求。4. 实战推演业务与技术协同搭建答疑 Agent让我们模拟一个猿辅导内部的场景看业务团队如何与技术协同快速落地一个“小学数学难题答疑 Agent”的原型。角色产品经理业务方小猿懂教育业务略懂技术概念。全栈工程师技术方大程负责技术选型和核心搭建。第一阶段需求对齐与数据建模第1天需求梳理小猿向大程描述场景“我们需要一个 Agent学生可以拍照上传数学题Agent 能识别题目从题库里找到相似题和解析并以 step-by-step 的方式引导学生思考过程中可以记录学生卡在哪一步。”核心数据实体确认大程引导小猿一起在白板或 Figma Jam上画出核心实体用户、对话、消息、题目图片、解题状态。他们确定解题状态可以作为一个 JSON 字段存放在session_states表里记录当前步骤、已尝试的方法等。在 Supabase 中建表大程打开 Supabase 项目现场创建上述表格。每创建一个表都向小猿解释每个字段的意义user_id是外键关联 Authstate_data是 JSON 可以灵活存各种信息。小猿能通过 Table Editor 立即看到空表的结构并提出“我们是不是加一个difficulty字段在session_states里记录系统评估的本题难度” 大程觉得合理当场添加。这个过程是双向的、可视的而不是单向的需求文档传递。第二阶段定义业务规则与权限第2天RLS 策略共创大程为conversations和messages表启用 RLS。他问小猿“关于数据权限我们有什么规则”小猿说“学生只能看自己的对话教研老师可以看所有对话用于分析但教研老师不能修改或删除对话。”大程将这些规则翻译成两条 RLS 策略对学生角色auth.uid() user_id对教研老师角色auth.jwt()-role teacher仅 SELECT 权限 大程编写策略时小猿在旁边看并确认 SQL 条件是否符合业务预期。工具函数抽象大程问“Agent 需要调用哪些‘工具’”小猿列出search_similar_questions(搜索题库)、get_hint_for_step(获取步骤提示)。大程决定先将这些工具实现为 Supabase Edge Functions。他告诉小猿每个工具会有一个 API 端点前端可以调用。第三阶段前端原型与集成第3-5天选择前端工具为了极致速度他们决定使用 Vercel Next.js并利用 Supabase 提供的 JavaScript/React 客户端库。大程快速搭建一个聊天界面消息列表直接通过 Supabase 客户端查询messages表并订阅实时更新。连接 Agent 大脑大程编写核心的handle_agent_turnEdge Function。这个函数内调用多模态大模型 API 识别图片中的题目文本。将题目文本向量化使用 Supabase 的pgvector扩展在题库中进行相似度搜索。根据搜索结果和学生当前状态构造提示词调用大语言模型生成引导性回复。将回复和更新的状态保存回数据库。业务方验收与调优大程将前端原型和 Agent 函数部署到测试环境。小猿用自己的账号登录开始上传题目进行测试。她发现 Agent 在某些几何题上识别不准。她不需要提“优化OCR模型”这种技术需求而是可以直接在 Table Editor 里查看session_states表看到模型识别出的原始文本是什么从而判断问题是出在图片质量、还是模型能力上。她可以将这些“问题案例”的会话 ID 记录下来形成一份高质量的问题反馈给算法团队。同时她可以和大程一起调整 Edge Function 中调用大模型的提示词Prompt比如加入“如果你是位耐心的数学老师请用更口语化的方式提问”并立即测试效果。第四阶段迭代与扩展持续原型跑通后新的想法自然涌现小猿“我们能不能加一个‘求助老师’按钮当学生卡住时可以把当前对话上下文一键转发给在线老师”大程评估后认为这可以在messages表加一个forwarded_to字段并写一个新的 Edge Function 来处理转发逻辑。小猿“我想每周看一份报告看看学生们最常卡在哪些知识点。”大程可以基于session_states表的数据用 SQL 或另一个 Edge Function 生成聚合数据甚至直接用 Supabase 的 PostgreSQL 数据库连接 BI 工具如 Metabase让小猿自己拖拽生成报表。整个流程中小猿作为业务方始终能接触到应用的“数据心脏”并能基于真实数据提出具体、可执行的优化点。大程作为技术方则专注于构建稳定、可扩展的底层能力和处理最复杂的逻辑集成。5. “手搓”的边界技术兜底与最佳实践让业务团队“手搓”应用绝不是让他们取代工程师。恰恰相反这需要更清晰的责任边界和强有力的技术兜底。Supabase 这类工具是降低了“应用构建”的门槛而不是“软件工程”的门槛。技术团队的职责重心转移从“写业务CRUD接口”到“搭建并维护安全、高效的数据平台与核心抽象”技术同学需要设计合理的、可扩展的底层表结构编写关键的、复用性高的 Edge Functions设置好全局的、安全的 RLS 策略模板。他们是平台的搭建者和守护者。提供“乐高积木”而非“黑盒”将业务能力封装成一个个边界清晰、文档完善的 Edge Function 或数据库视图并培训业务团队如何使用这些“积木”。例如提供update_conversation_state(state_key, value)这样的函数而不是让业务直接写 SQL 更新session_states表。设立安全与性能护栏通过 RLS 确保数据安全底线通过数据库索引、查询性能监控防止业务人员的复杂查询拖垮数据库对 Edge Functions 进行资源限制和超时设置。业务团队的可行操作域数据查看与探索在 Table Editor 中查看、筛选、排序数据理解业务运行现状。基于视图的简单查询在技术同学创建好的视图基础上进行自定义过滤和查询用于生成临时报表或数据验证。配置化调整修改某些存储在数据库配置表中的参数如提示词模板、开关状态或调整视图的过滤条件。工作流组装在低代码平台如利用 Supabase Webhooks 触发 Zapier中组装已有的“积木”Edge Functions来实现简单的自动化流程。需要警惕的陷阱RLS 策略复杂度爆炸过于复杂的 RLS 策略会难以理解和维护且可能影响查询性能。策略应尽量简单、正交。复杂的多角色权限系统可能仍需部分后端逻辑辅助。数据库被当作计算引擎避免让业务人员在客户端执行复杂的、多表关联的分析型查询。这类查询应封装成 Edge Function 或物化视图。Edge Functions 的无状态性Edge Functions 是无状态的不适合处理长耗时任务或维护全局状态。需要长时间运行的任务应提交到任务队列处理。工具链锁定Supabase 虽好但过度依赖其特定接口如它的客户端库可能导致未来迁移成本。在核心业务逻辑层做好抽象是有必要的。6. 效果评估不只是快更是协同模式的进化采用 Supabase 助力业务团队参与后带来的价值是多维度的1. 交付速度的质变原型验证周期从“周/月”缩短到“天”最复杂的对话状态管理和数据持久化被 Supabase 标准化解决团队可以集中精力在 Agent 的核心逻辑提示工程、工具调用和用户体验上。迭代反馈循环极速缩短业务方发现一个流程问题技术方可能只需要修改一条 RLS 策略或一个视图的 SQL几分钟内就能上线验证无需经过完整的开发-测试-部署流水线。2. 沟通成本的显著降低统一的事实来源过去业务说“数据不对”技术需要查日志、查数据库现在双方可以同时打开 Table Editor指着同一行数据讨论。“你看这条消息的状态字段没更新是不是我们的 Function 逻辑有分支没覆盖”这种基于事实的沟通效率极高。消除“翻译”误差业务对权限规则、数据关系的描述能通过 RLS 和表关系更直观地体现出来减少了产品文档被技术误解的可能性。3. 业务创新能力的激活从“提需求者”到“共创者”业务团队在安全边界内获得了更大的探索自由。他们可以自己尝试组合数据提出更贴近业务本质的优化点甚至能自己搭建一些简单的数据看板驱动决策。技术资源聚焦高价值问题工程师得以从无穷无尽的业务 CRUD 和简单 API 开发中解脱出来去解决更复杂的架构问题、性能优化和算法挑战。回过头看猿辅导的案例对话式 Agent 的落地难点往往不在 AI 模型本身而在于如何将模型能力与具体的业务数据、流程、状态有机地结合起来形成一个稳定、可维护、可扩展的系统。Supabase 提供了一套恰好匹配这个“结合部”需求的工具集它像一层“胶水”和“脚手架”把前端、AI 能力、业务数据流畅地粘合在一起并且把这层“胶水”的控制权部分地、安全地交到了业务团队手中。这不仅仅是引入了一个新工具更是一种团队协作模式的进化。它让技术更专注于创造强大的“原子能力”和“安全平台”而让业务更专注于理解和塑造“业务流”本身。当业务团队能够“手搓”应用时他们打磨的是对业务更深的理解和更敏捷的响应能力而这才是应对快速变化市场的终极武器。 1. 从“提需求”到“搭应用”一场业务团队的效率革命最近和几个不同公司的产品、运营朋友聊天发现一个挺有意思的现象大家抱怨的焦点已经从“技术排期太满需求做不完”逐渐变成了“我有个小想法想快速验证一下但不想麻烦研发”。这个转变背后其实是业务团队对敏捷性的新追求。他们不再满足于仅仅提出需求而是希望拥有一种能力能自己动手快速将想法转化为一个可交互、可验证的“最小可行产品”MVP。这听起来有点像“手搓”应用——用现成的、低门槛的工具像搭积木一样把业务逻辑拼装出来。猿辅导在对话式 Agent智能体的落地实践中就遇到了类似的挑战。Agent 的核心在于与用户进行多轮、有状态的复杂对话背后涉及意图识别、状态管理、知识库查询、工具调用等多个环节。传统的开发模式是业务团队比如教研、课程顾问提出一个智能辅导或答疑场景的需求然后产品经理出 PRD交给后端、前端、算法工程师进行排期开发。这个周期动辄以“月”为单位等上线时市场反馈或业务重点可能已经变了。而他们找到的“积木”之一是火山引擎的 Supabase。你可能听说过它一个开源的 Firebase 替代品提供了开箱即用的数据库、身份认证、实时订阅、存储等后端服务。但它的价值远不止“替代品”那么简单。对于业务团队而言Supabase 最大的魅力在于它通过一套极其友好的工具链——尤其是其数据库的“表视图”操作、行级安全策略RLS和 Edge Functions——极大地降低了后端逻辑和数据管理的门槛。这让非技术背景的业务人员在少量技术支持的指导下也能参与到应用核心数据流和业务规则的定义中从而加速像对话式 Agent 这类复杂应用的落地闭环。简单说这不是要让业务同学去写复杂的并发代码而是让他们能直接“看见”和“操作”业务数据流并基于此设计对话流程。接下来我就结合对这类场景的理解拆解一下如何利用 Supabase 这套工具让业务团队也能深度参与甚至主导一个对话式 Agent 应用的原型搭建。2. 对话式 Agent 的核心骨架为什么数据层是瓶颈在动手“搭积木”之前我们得先搞清楚要搭的是什么。一个典型的对话式 Agent比如一个智能课程答疑助手它的核心工作流程可以抽象为以下几个环节对话管理维护与用户当前会话的上下文。用户问了什么助理回答了什么现在对话进行到哪一步了这需要持久化存储对话历史。状态追踪记录对话中的关键业务状态。例如用户正在咨询“三年级数学暑期班”那么“科目数学”、“年级三年级”、“意向暑期班”就是需要跟踪的状态。这决定了下一步 Agent 该调用哪个工具如查询课程表或给出什么回复。知识库查询根据用户问题从课程资料、FAQ、政策文档中检索最相关的信息。这通常涉及向量化存储和相似性搜索。工具调用与执行Agent 决定需要执行一个具体操作比如“查询用户剩余课时”、“预约试听课”。这需要安全、可控地调用内部 API 或执行数据库操作。响应生成与呈现将检索到的信息、工具执行的结果组织成自然流畅的回复返回给用户。传统的技术实现中环节 1、2、4 都需要大量的后端开发工作。需要设计数据库表结构conversations,messages,session_states编写 CRUD API实现状态机逻辑并确保每个用户只能访问自己的数据权限隔离。这些工作繁琐、重复且一旦业务逻辑调整就需要修改代码、重新部署。这就是业务团队无法介入的瓶颈所在数据层和业务规则层被封装在复杂的代码之后他们看不见也摸不着。他们可能用流程图画出了一个完美的对话流程但要将流程图转化为数据库表和 API中间隔着一道技术的鸿沟。Supabase 的切入点正是试图填平这道鸿沟。它不直接解决 AI 模型如大语言模型的问题而是为 Agent 所需的数据和逻辑基础设施提供了一套“可视化”和“声明式”的搭建方式。3. Supabase 工具箱业务团队能直接上手的“积木块”那么Supabase 具体提供了哪些“积木”让业务同学也能参与搭建呢我们重点看几个与对话式 Agent 强相关的功能。3.1 数据库与表视图让数据结构“看得见摸得着”Supabase 基于 PostgreSQL但它提供了一个强大的 Web 管理界面——Table Editor。业务人员在技术同事简单培训后可以像使用 Excel 或 Airtable 一样直观地看到数据库中有哪些表。对于我们的答疑 Agent技术同学可以先创建核心表结构profiles: 存储用户基本信息与 Supabase Auth 用户关联。conversations: 存储每次对话会话的元信息如user_id,title,created_at。messages: 存储每条对话消息包含conversation_id,role(user/assistant),content,created_at。session_states: 存储对话的当前状态如conversation_id,state_key(例如 “current_topic”),state_value。创建好后业务产品经理可以直接在 Table Editor 里点击“查看数据”甚至插入一些测试数据。他们能立刻理解“哦原来用户的一次对话是这样存下来的消息是一条条记录的。” 这种直观性比看 API 文档或 ER 图要有效得多。更重要的是他们可以通过“表视图”功能创建自定义的数据视角。比如创建一个“活跃对话视图”只显示过去24小时内有过消息的会话并关联出用户昵称和最后一条消息内容。这个视图可以直接被前端应用调用无需后端另写接口。业务方想要调整这个视图的逻辑比如把24小时改成12小时在界面里修改 SQL 过滤条件即可这种可控感是前所未有的。3.2 行级安全策略用“规则”代替“代码”管理权限这是 Supabase 的“王牌”功能也是能让业务团队定义核心业务规则的关键。RLS 允许你为数据库表设置基于 SQL 的访问策略。以前确保用户只能看自己的对话数据需要后端在每一个查询接口里手动添加WHERE user_id current_user_id。现在技术同学可以在messages表上启用 RLS并创建这样一条策略CREATE POLICY “用户只能管理自己会话的消息” ON messages FOR ALL USING ( EXISTS ( SELECT 1 FROM conversations WHERE conversations.id messages.conversation_id AND conversations.user_id auth.uid() ) );这条策略用白话解释就是“允许所有操作但仅当这条消息所属的会话的user_id等于当前登录用户的 ID 时才生效。”业务团队能做什么他们可以和技术一起用自然语言描述权限规则“学生只能看自己发的帖子和回复”、“课程顾问只能查看分配给自己的学员对话”。技术人员将这些描述转化为类似的 RLS 策略。一旦策略生效无论前端怎么调用 Supabase 客户端库甚至是直接通过 SQL 查询数据安全都能得到保证。业务方可以放心地让前端直接查询messages表而不用担心数据越权。他们参与定义了系统的“安全护栏”。3.3 Edge Functions无服务器函数封装复杂逻辑有些逻辑不适合直接写在数据库策略里比如调用外部 AI 接口、进行复杂的计算、或者调用内部某个老旧系统的 API。这时就需要 Edge Functions。Supabase Edge Functions 是基于 Deno 的无服务器函数。技术同学可以编写一个函数例如handle_agent_turn接收当前会话 ID 和用户最新消息。从数据库查询历史上下文和当前状态。调用大语言模型 API如火山方舟、OpenAI。解析模型返回的意图可能需要查询知识库或调用工具函数。将模型回复存入数据库并更新对话状态。返回回复给前端。编写这个函数是技术工作但部署和管理过程可以极大简化。函数部署后会生成一个唯一的 URL。业务团队可以在他们熟悉的工具如 Zapier、Make甚至 Excel里通过 Webhook 调用这个 URL 来触发 Agent 处理。他们可以测试不同的输入观察输出和数据库的变化从而更深入地理解 Agent 的决策逻辑。3.4 实时订阅让对话流“活”起来对话式应用天然是实时的。Supabase 的 Realtime 功能可以轻松实现。前端可以订阅特定频道的消息比如conversation:${id}。当 Edge Function 将助理的回复写入messages表后利用 PostgreSQL 的触发器Trigger向 Realtime 频道发送一个事件前端监听到事件后就能实时更新界面显示助理的回复。这套机制由技术同学搭建好后业务方感受到的就是一个流畅、无刷新、类似聊天软件的体验。他们可以基于这个体验更准确地提出对交互细节的优化需求。4. 实战推演业务与技术协同搭建答疑 Agent让我们模拟一个猿辅导内部的场景看业务团队如何与技术协同快速落地一个“小学数学难题答疑 Agent”的原型。角色产品经理业务方小猿懂教育业务略懂技术概念。全栈工程师技术方大程负责技术选型和核心搭建。第一阶段需求对齐与数据建模第1天需求梳理小猿向大程描述场景“我们需要一个 Agent学生可以拍照上传数学题Agent 能识别题目从题库里找到相似题和解析并以 step-by-step 的方式引导学生思考过程中可以记录学生卡在哪一步。”核心数据实体确认大程引导小猿一起在白板或 Figma Jam上画出核心实体用户、对话、消息、题目图片、解题状态。他们确定解题状态可以作为一个 JSON 字段存放在session_states表里记录当前步骤、已尝试的方法等。在 Supabase 中建表大程打开 Supabase 项目现场创建上述表格。每创建一个表都向小猿解释每个字段的意义user_id是外键关联 Authstate_data是 JSON 可以灵活存各种信息。小猿能通过 Table Editor 立即看到空表的结构并提出“我们是不是加一个difficulty字段在session_states里记录系统评估的本题难度” 大程觉得合理当场添加。这个过程是双向的、可视的而不是单向的需求文档传递。第二阶段定义业务规则与权限第2天RLS 策略共创大程为conversations和messages表启用 RLS。他问小猿“关于数据权限我们有什么规则”小猿说“学生只能看自己的对话教研老师可以看所有对话用于分析但教研老师不能修改或删除对话。”大程将这些规则翻译成两条 RLS 策略对学生角色auth.uid() user_id对教研老师角色auth.jwt()-role teacher仅 SELECT 权限 大程编写策略时小猿在旁边看并确认 SQL 条件是否符合业务预期。工具函数抽象大程问“Agent 需要调用哪些‘工具’”小猿列出search_similar_questions(搜索题库)、get_hint_for_step(获取步骤提示)。大程决定先将这些工具实现为 Supabase Edge Functions。他告诉小猿每个工具会有一个 API 端点前端可以调用。第三阶段前端原型与集成第3-5天选择前端工具为了极致速度他们决定使用 Vercel Next.js并利用 Supabase 提供的 JavaScript/React 客户端库。大程快速搭建一个聊天界面消息列表直接通过 Supabase 客户端查询messages表并订阅实时更新。连接 Agent 大脑大程编写核心的handle_agent_turnEdge Function。这个函数内调用多模态大模型 API 识别图片中的题目文本。将题目文本向量化使用 Supabase 的pgvector扩展在题库中进行相似度搜索。根据搜索结果和学生当前状态构造提示词调用大语言模型生成引导性回复。将回复和更新的状态保存回数据库。业务方验收与调优大程将前端原型和 Agent 函数部署到测试环境。小猿用自己的账号登录开始上传题目进行测试。她发现 Agent 在某些几何题上识别不准。她不需要提“优化OCR模型”这种技术需求而是可以直接在 Table Editor 里查看session_states表看到模型识别出的原始文本是什么从而判断问题是出在图片质量、还是模型能力上。她可以将这些“问题案例”的会话 ID 记录下来形成一份高质量的问题反馈给算法团队。同时她可以和大程一起调整 Edge Function 中调用大模型的提示词Prompt比如加入“如果你是位耐心的数学老师请用更口语化的方式提问”并立即测试效果。第四阶段迭代与扩展持续原型跑通后新的想法自然涌现小猿“我们能不能加一个‘求助老师’按钮当学生卡住时可以把当前对话上下文一键转发给在线老师”大程评估后认为这可以在messages表加一个forwarded_to字段并写一个新的 Edge Function 来处理转发逻辑。小猿“我想每周看一份报告看看学生们最常卡在哪些知识点。”大程可以基于session_states表的数据用 SQL 或另一个 Edge Function 生成聚合数据甚至直接用 Supabase 的 PostgreSQL 数据库连接 BI 工具如 Metabase让小猿自己拖拽生成报表。整个流程中小猿作为业务方始终能接触到应用的“数据心脏”并能基于真实数据提出具体、可执行的优化点。大程作为技术方则专注于构建稳定、可扩展的底层能力和处理最复杂的逻辑集成。5. “手搓”的边界技术兜底与最佳实践让业务团队“手搓”应用绝不是让他们取代工程师。恰恰相反这需要更清晰的责任边界和强有力的技术兜底。Supabase 这类工具是降低了“应用构建”的门槛而不是“软件工程”的门槛。技术团队的职责重心转移从“写业务CRUD接口”到“搭建并维护安全、高效的数据平台与核心抽象”技术同学需要设计合理的、可扩展的底层表结构编写关键的、复用性高的 Edge Functions设置好全局的、安全的 RLS 策略模板。他们是平台的搭建者和守护者。提供“乐高积木”而非“黑盒”将业务能力封装成一个个边界清晰、文档完善的 Edge Function 或数据库视图并培训业务团队如何使用这些“积木”。例如提供update_conversation_state(state_key, value)这样的函数而不是让业务直接写 SQL 更新session_states表。设立安全与性能护栏通过 RLS 确保数据安全底线通过数据库索引、查询性能监控防止业务人员的复杂查询拖垮数据库对 Edge Functions 进行资源限制和超时设置。业务团队的可行操作域数据查看与探索在 Table Editor 中查看、筛选、排序数据理解业务运行现状。基于视图的简单查询在技术同学创建好的视图基础上进行自定义过滤和查询用于生成临时报表或数据验证。配置化调整修改某些存储在数据库配置表中的参数如提示词模板、开关状态或调整视图的过滤条件。工作流组装在低代码平台如利用 Supabase Webhooks 触发 Zapier中组装已有的“积木”Edge Functions来实现简单的自动化流程。需要警惕的陷阱RLS 策略复杂度爆炸过于复杂的 RLS 策略会难以理解和维护且可能影响查询性能。策略应尽量简单、正交。复杂的多角色权限系统可能仍需部分后端逻辑辅助。数据库被当作计算引擎避免让业务人员在客户端执行复杂的、多表关联的分析型查询。这类查询应封装成 Edge Function 或物化视图。Edge Functions 的无状态性Edge Functions 是无状态的不适合处理长耗时任务或维护全局状态。需要长时间运行的任务应提交到任务队列处理。工具链锁定Supabase 虽好但过度依赖其特定接口如它的客户端库可能导致未来迁移成本。在核心业务逻辑层做好抽象是有必要的。6. 效果评估不只是快更是协同模式的进化采用 Supabase 助力业务团队参与后带来的价值是多维度的1. 交付速度的质变原型验证周期从“周/月”缩短到“天”最复杂的对话状态管理和数据持久化被 Supabase 标准化解决团队可以集中精力在 Agent 的核心逻辑提示工程、工具调用和用户体验上。迭代反馈循环极速缩短业务方发现一个流程问题技术方可能只需要修改一条 RLS 策略或一个视图的 SQL几分钟内就能上线验证无需经过完整的开发-测试-部署流水线。2. 沟通成本的显著降低统一的事实来源过去业务说“数据不对”技术需要查日志、查数据库现在双方可以同时打开 Table Editor指着同一行数据讨论。“你看这条消息的状态字段没更新是不是我们的 Function 逻辑有分支没覆盖”这种基于事实的沟通效率极高。消除“翻译”误差业务对权限规则、数据关系的描述能通过 RLS 和表关系更直观地体现出来减少了产品文档被技术误解的可能性。3. 业务创新能力的激活从“提需求者”到“共创者”业务团队在安全边界内获得了更大的探索自由。他们可以自己尝试组合数据提出更贴近业务本质的优化点甚至能自己搭建一些简单的数据看板驱动决策。技术资源聚焦高价值问题工程师得以从无穷无尽的业务 CRUD 和简单 API 开发中解脱出来去解决更复杂的架构问题、性能优化和算法挑战。回过头看猿辅导的案例对话式 Agent 的落地难点往往不在 AI 模型本身而在于如何将模型能力与具体的业务数据、流程、状态有机地结合起来形成一个稳定、可维护、可扩展的系统。Supabase 提供了一套恰好匹配这个“结合部”需求的工具集它像一层“胶水”和“脚手架”把前端、AI 能力、业务数据流畅地粘合在一起并且把这层“胶水”的控制权部分地、安全地交到了业务团队手中。这不仅仅是引入了一个新工具更是一种团队协作模式的进化。它让技术更专注于创造强大的“原子能力”和“安全平台”而让业务更专注于理解和塑造“业务流”本身。当业务团队能够“手搓”应用时他们打磨的是对业务更深的理解和更敏捷的响应能力而这才是应对快速变化市场的终极武器。 
