作者：寒斜
Kimi-K2 近期火爆异常，优秀的性能表现甚至都将 DeepSeek 从全球开源模型第一的王座上拉了下来。该模型最让我们开发者关注是其编程能力，经测试，代码生成效果的确非常惊艳。
紧接着，Qwen3 系列的编程模型 Qwen3-Coder 王者归来，震惊全球，本次先按照顺序主要介绍 Kimi-K2 的能力，Qwen3 Coder 稍后再给大家做详细介绍（可以先根据末尾切换模型篇进行切换测试）。
为了能够更清晰地向大家展示其中的效果，本篇文章使用 AI 应用来做示例。当然，不仅仅与此，我们希望为广大开发者，泛开发者，以及企业展示一个更完整的编码智能体解决方案，我们深信当前 AI 的发展已经不仅仅是在讲技术或者工具的故事而是真正到交付价值交付效果的阶段了。
本方案是基于 Serverless 架构搭建的超实用 VibeCoding 解决方案，托管于 Function AI 之上，主要目标是帮助企业或者个人解决一些长尾开发需求的问题，比如构建一个网站或者是一个收集数据的表单页面等，方案践行"创意到上线"的理念。
（*注，本方案主要用于演示基于 Serverless 构建 Agentic 应用效果，不提供 SLA 保障）
效果演示
为了先给大家一个直观的感受再决定要不要继续阅读下去， 我们准备了一个小小的 UserStory 场景：
相信每一个男孩都喜欢玩游戏，希望可以拥有更多有趣的游戏可以玩，甚至拥有一个自己的游戏网站，今天我们模拟此场景，构建一个在线的小游戏站点。
核心设计分两个步骤。
一、让 AI 开发 9 款经典小游戏，发布上线
主要这部分需要的是用户的创意，只需要输入创意，然后跟 AI 持续 prompt 即可。
二、让 AI 开发一个带数据库的在线小游戏平台，展示并让玩家玩这些小游戏
这部分需要有一定的逻辑设计思维，好在，你不需要很懂软件工程设计，专家模式提供了项目经理，数据库，全栈开发 3 个专家智能体，跟你协作完成这项工作。
如何获取
现在，获取这套 Serverless 架构的 VibeCoding 方案极其简单。只需要访问阿里云 Function AI 控制台，根据指引操作，即可快速拥有，下面展示操作教程。
部署 智能体底座（AgentCraft）【需2分钟】
关于 AgentCraft 介绍，请参考【1】。
为什么需要先部署智能体底座？是因为 Serverles 架构 VibeCoding 解决方案的设计理念。
该解决方案整体分为三个部分：
- 智能能力中心[Agent 编排，模型调用，工具调用等]
- 上下文交互工程[上述演示的交互效果]
- 测试执行环境[Function AI 的底层能力 Function Compute 以及 Serverless Devs 构建工具]
核心思想是把智能体作为最原子化的能力，类似我们使用函数的用法只关注输入和输出，由智能能力中心设计后产出，然后交给上下文工程完成业务侧的编排以及人&AI、人&环境（UI）、AI&环境（生成及验证）的上下文交互，最后是独立的执行环境，利用函数计算 FC 的 SandBox 能力完成 AI 对 Compute Use 的执行需求，环境可以让人和 AI 共同验证生成结果的正确性。
需要注意的是智能体底座是有状态的，我们提供了免费的共享数据库提供给广大用户进行测试，但如果您希望用于生产，请自行采买专业数据库部分。
访问阿里云 Function AI【2】 控制台
根据指引进行授权。
点击创建项目-> 基于模板创建。
搜索人工智能分类，找到"智能体世界"应用模板。
根据指引进行配置部署（需要输入百炼 ApiKey ，访问模型用）。
根据指引授权后进行一键部署（约一分钟即可）。
访问 agentcraft-frontend 前端服务，进入系统配置。
为了方便快速体验，可以点击"共享体验数据库"完成数据库的一键配置（该数据库不会保存您的秘钥等敏感信息，但请注意勿上传您的私密的数据集，生产使用需自购专属的 pg 数据库）。
Embedding 基于阿里开源的最新模型 text-embedding-v4 即可。
配置成功后进行账号注册。
部署码呀码VibeCoding服务【需2分钟】
进入 AgentCraft 探索发现，关闭快速开始查看 Agentic AI 应用模板。
选中 mayama 进行一键部署。
AgentCraft 会基于此原生 AI 应用模板，构建工具&MCP，创建 LLM 代理以及智能体等一系列工作，之后会生成一个应用客户端，在 Function AI 上进行部署。
部署完成后访问地址即可进入 mayama vibe coding 主页。
操作教程
普通模式
实际上非专家模式的状态下，该解决方案的使用已经做到了极致的简化，如果你不知道怎么操作，直接跟 AI 沟通即可。
一但接收到 coding 需求，进入 AI 开始进行生成，同时系统开始展开工作空间。
专家模式
简介
专家模式是借鉴了软件工程项目协作的理念，设计了三个智能角色。
专家PM[M] - 负责梳理用户需求，提供建议。
DBA[D]专家 - 负责根据 PM 的引导设计，构建标准 pg sql 以及提供 sql 的验证修改，数据 mock。
全栈专家[X] - 根据前面两个角色的输出进行编码，这里没有把应用的部署放进去，主要考虑部署是非常确定的操作，基于传统的 GUI 会更稳定。
比如这里用户只需要说出自己的需求，M 会帮助进行分析拆解，构建专业的 ER 关系图。
当用户觉得设计没问题之后，M 会通知 D（用人类的@, 系统内置观察员角色控制对话流的自动化）D 接下来会进行数据库的设计。
值得注意的是数据库的部分使用了阿里云托管的 supabase 方案，这是一个理想的构建轻量后端服务的方案，我们需要先去进行开通及创建数据库。
Supabase 数据库创建
1. 创建服务关联角色
2. 创建数据库实例
这里为每一个用户提供了 2 个免费的实例额度，您只需要根据指引创建好即可。
3. 授权 FcDefaultRole 操作数据库管理的权限
Supabase 的集成部分有的权限的设置，即需要给 AliyunFcDefaultRole【3】（部署AgentCraft 底座的时候已经获取）增加一个 AliyunGPDBFullAccess 的权限，这样在页面上才能看到相关的数据。
4. 等待创之后刷新页面，点开右上角查看实例是否创建成功。
执行数据库操作
Supabase 创建及授权后继续下面的流程
对于 D 的专业产出作为非开发者也不同担心，只需要点击"执行SQL"按钮，AI 系统可以自行到 supbase 服务进行验证。
注意，这里慎重开启自动执行及验证，可能会出现不停的循环生成（AI 幻觉无法解决的情况下，总会有错误产出）
数据库的构建生成会有自动化的效果，SQL 生成-> Supbase 数据库环境执行-> 失败提示->SQL 再生成。
数据库生成无误之后，D 在征得用户同意后，会通知 X 进入开发（多智能体的协作有固定流程 M-D-X，即使流程损坏也无关系， 方案中提供了主动唤起任意智能体的交互，可以允许人类进行容错）。
X 同样会拥有工作空间，来自动化的验证修改程序，这个后续再介绍。
专家模式中 X 用的模型目前是 DeepSeek-R2，主要是拥有更长的上下文。模型的切换可以到智能体底座轻松完成。
技术实现
限于篇幅问题这里对技术部分做一些简单整理，有需要的同学可以进入 Serverless Devs 开发者社区进行沟通探讨。
整体架构
智能体设计
普通模式
普通模式的智能体路由架构，普通模式下多智能体的路由模式就是简单的意图识别。
专家模式
专家模式多智能体和人的交互则是组网式的，在智能体的设置中已经让他们感知对方的存在，可以根据实际情况通过 '@' 指定下一位操作人，其次 UI 上将每一个智能体具体的切换方式透出，当多智能体协作出现问题时，可以让人进行纠偏。
上下文工程
实际上对于应用开发者而言，上下文工程恐怕是最最重要的部分，我们知道，当前 AI 应用领域已经从提示词阶段升级到了上下文工程阶段，上下文是一个非常综合的内容。以当前方案为例，我们做一下简单整理。
Agent 系统的内置上下文
这部分主要是系统提示词。
外挂工具的上下文
经典的就是 MCP 或者 Function Call 调用的自定义工具。
外联数据上下文
这里主要是 RAG 方案提供的内容。
上述是我们对于以往熟知的上下文体系，但在完整的 Agentic 应用还远远不够。多数 Agentic 系统的设计是把跟人的交互排除在外的，这里面非常相悖的事实是，Agentic 应用的核心交互对象应当是人，因为系统设计一旦脱离人的控制范畴，后续可能会引发意想不到的风险，我的一个猜想是，今天 AI 应用的爆发没有来到，很大一部分原因是大家更关注底层技术的发展，而忽略了对人机交互。
用户的输入上下文
用户的输入上下文，包括不限于多模态的输入内容以及通过 Agentic 应用提供的干预入口进行输入的上下文。
生成内容在环境中的验证结果
AI 输出 token, token 被工程手段变成结构化的数据、指令或者代码，结构化的数据、指令、或者代码经过真实环境的校验得到反馈，然后再作为下一步判断的上下文，让 AI 进行持续输出。这是 AI 自动化的基础。
值得一提的是，持续的上下文会有更大的价值，意味着 AI 可以掌握最多的信息能够给出最佳的判断 AgentCraft 内置了可以将多个智能体协作信息作为共享上下文的能力，因此可以实现多智能体间的丝滑沟通。
在上述应用实践中，多智能体协作的上下文信息共享可以保障 M,D,X 协作的无缝衔接。
编程智能体以及数据库智能体跟环境（FunctionAI 的 Compute 以及 Supabase 实例）的自主交互则有效保障 AI 可以自主化解决问题的能力。
环境及交互
实际上本次实践总共有三个真实执行环境。
- FunctionAI 的 SandBox （linux 系统，内置 node20 运行时，以及提前准备好的 nextjs 的相关依赖还有 nginx 网关）
- Supabase 实例（通过 API SDK 跟实例进行关联，可以让生成的 SQL 进入执行环境，构建数据表或者模拟数据）
- 浏览器环境（这个环境即服务于人也服务于系统，服务于人主要是提供工程的前端预览效果，服务于系统则是在发生前端工程异常时，会被系统捕获作为修复工程问题的上下文）
优势
Function AI 的 SandBox 在应对企业级别的需求有着非常大的优势，我们拥有 Debian9-Debian12 的操作系统运行时，同时支持 nodejs,java,go 等多种语言环境，换句话说不仅仅是前端后续如果您的企业希望构建更多后端工程方案从可行性上完全没问题。另外 layer 能力也是一大亮点，今天在构建在真实生产过程中，重复的依赖包无需从头安装，直接通过 layer 在项目工程下进行软连接是一个更好的方案，这里可以节省大量的安装时间。
此外 SandBox 在此类场景中对于 Session 亲和以及运行时隔离都有比较高的要求，所以 Session 亲和是指确保客户端的会话请求被定向到同一台服务器处理，以维持会话状态。
比如本场景情况下，每一个用户的所有请求都应该只访问自己的服务器如果不同用户的请求会进入同一个实例，导致指令执行效果交付都会出现大乱子，这是不被接受的，而 Function AI 的 SandBox 方案可以通过在请求头注入关键信息，使得携带该种 header 的请求都进入统一实例中，Function AI 的 SandBox 还拥有极强的运行时隔离能力，实例运行时通过类似 Firecracker 的 MicroVM 做强隔离，不共享内核。
这个能力可以帮助完成企业的多租需求。
阿里云数据库提供的 Supabase 方案也有非常多的优势：
云原生数据仓库 AnalyticDB PostgreSQL 版重磅推出了Supabase 托管版本。相较于完全自建方案，阿里云托管版拥有以下核心优势，让你的 Vibe Coding 应用开发更轻松高效：
极简部署，开箱即用。无需本地复杂安装与组件配置，只需几步即可自动化完成 Supabase 后端服务的创建，让你专注于应用开发或者 Vibe Coding，而不是花时间在基础设施上。
企业级高可用与安全保障 云原生数据仓库 AnalyticDB PostgreSQL 版提供高可用架构、多重备份和自动容灾能力，远超自建环境的稳定性与可靠性。
极速访问，国内网络优化 托管于阿里云国内数据中心，配备专线和网络加速方案，显著降低网络延迟，访问速度远胜于海外托管与自行部署，助力你的产品实现极致体验。
与阿里云产品生态深度集成 支持与阿里云丰富的云产品无缝衔接，比如对象存储直接使用阿里云 OSS，助力构建更强大的应用生态。
未来，我们还将推出：
- Branching 特性
虽然当下大模型的能力已十分强大，但完全交由大模型进行编码，依然存在风险，尤其是上大模型进行后端操作时，甚至可能会出现删库删表等高危操作。而 AnalyticDB PostgreSQL 版提供的 Branch 能力，可以让用户和使用版本管理工具 git 一样使用数据库。提供 vibe coding 的安全和容错能力。
- 本土化认证
更符合国内的认证方式，比如微信、支付宝、抖音账号等三方鉴权登录，以及三大运营商短信认证的登录方式。增强国内用户的使用体验。
成本说明
相信这部分也是大家关心的话题，这个方案包含的成本如下：
计算
Function AI 的 CPU 算力，计费模式【4】参考。
本次方案详细使用情况
agentCraft 前端 （2C3G）
agentCraft 后端（2C3G）
vibecoding-main 编程项目(16C32G10G)
vibecoding-web-server 托管服务(1C2G)
vibecoding-share-storage 共享存储的辅助函数(0.35C512M)
LLM Token
百炼的大语言模型 token 算力成本。
| 智能体 | 使用模型 | 输入价格（每千token元） | 输出价格(每千token元) |
|---|---|---|---|
| 主问答引导器 | qwen-plus | 0.0008 | 0.002 |
| 游戏设计 | qwen-plus | 0.0008 | 0.002 |
| 前端编程 | Moonshot-Kimi-K2-Instruct | 0.004 | 0.016 |
| 意图识别器 | qwen-plus | 0.0008 | 0.002 |
| 系统观察员 | qwen-plus | 0.0008 | 0.002 |
| 项目经理 | qwen-plus | 0.0008 | 0.002 |
| 数据库专家 | qwen-plus | 0.0008 | 0.002 |
| 全栈专家 | deepseek-r1 | 0.004 | 0.016 |
数据库
包含智能体底座的数据库和 vibecoding 的 supbase 数据库。
如果只是体验共享数据库免费，如果作为新用户构建最低规格数据库是 200+一年
supabase 数据库基础版本（1C2G）免费。
存储
使用 Nas 通用型存储，主要存储项目源代码，依赖安装等。小游戏平均 30M 大小，10 个小游戏总共 300M。
Nas 通用性存储的单价为 0.35元/GiB/月。也就是 100 个小游戏存储费用一年大约 12 块左右。
网络
公网流量费用。
每月提供 20 GB 的普通 BGP 公网流量免费额度。
问题及挑战
需要强调的是，虽然 AI 的强大有目共睹，但是在落地实践中依然存在很多问题。例如：
模型本身的指令遵从，幻觉会导致生成内容不符合要求，且很难通过引导提示解决，遇到这种情况，需要专业人员介入参与修改，比如这里代码工程可能会存在多次 prompt 也无法解决的情况，此时需要让专业开发帮助解决，当需要引入人类专家介入的时候，意味着产品功能要增加对应的专业能力，比如 CICD, DevOps 等。
模型上下文长度问题，构建复杂工程需要跟 AI 系统进行反复沟通协作，当前的大语言模型上下文是有限的，超出后模型会异常响应，需要工程做好控制，另外预留好上下文窗口的控制机制，方便随着模型上下文能力增强而增强。
工程版本管理，上述方案没有给出完整的工程版本方案，但是在企业生产中一定是需要的，而且这里更复杂的部分在于，我们不仅需要管理代码版本，包括数据库版本，线上运行时版本等都需要进行管理，这也是一个系统性的问题。
数据和开发运行时环境隔离，上述提到了开发运行时如何避免开发环境不隔离的问题，而数据库层面本次为了最大程度复用单库的价值，采取通过项目前缀做数据表分离的方式，在企业生产中建议使用严格的库隔离，另外对于 SQL 执行要做权限控制。
生产环境高可用，上线之后随着访问量的增加会遇到各种问题，需要确保生产环境的高可用，此时基于云 Serverless 架构的优势会更加明显，本次方案在单一实例中内置了 Nginx 用来分离 开发运行时的环境和发布运行时的环境，真正生产建议使用云原生网关进行替代，可以实现更强大的能力（使用二级域名连接发布的应用项目确保生产安全，对于高并发流量的有效管控）。
观测运维，应用发布如何保障系统稳定以及发掘业务价值，也是一个很重要的问题，这里的观测方案包含前端用户端侧的使用路径，前端系统检测，以及后端服务的全栈观测。
探索更多
持续集成方案
如上述提到的挑战， 当确定 AI 不可以 100% 完成工作的时候，剩余部分需要人类专家介入，这里有两种方案：
一、将代码工程下载到本地，提供给工程调试，然后基于代码仓库进行版本管理使用本地的智能IDE继续完成持续的迭代，再进行部署。
二、直接集成到现有的解决方案中，比如在单一的项目占位 UI 中增加持续集成功能，之后每次的自然语言更新可以自动创建分支，提交代码，构建，发布。
无论上述哪种方案，在代码工程的基础设施上都需要有足够的支持，这里推荐使用阿里云的云效方案，拥有完备的项目管理，代码工程，持续集成工作流能力，且已经服务众多的企业客户，可以跟内部的业务系统做好衔接。
基于这套基础设施，企业内部甚至可以尝试【需求->上线】的最短路径，即当整个系统足够智能以及拥有足够的上下文，他的输入是需求，输出是更新后的上线结果，这应该会非常酷。
生产网关
正如上述问题挑战中提到的，当前的解决方案通过在实例中内置 Nginx 的方式。
这种方案大规模生产下会存在一些问题，尤其是生产网关部分，只能使用 / 的方式分离不同的项目，而理想的应该是 . 子域名的方式，这种更加安全。这项能力也只能是专业的服务网关能做到，开发态核心问题是如何应对更高的并发，做流控，安全等能力。
如果有相关的需求可以访问官网查看详情【5】。
项目可观测
这里方案的可观测能力主要集中在基础平台上，智能体底座以及编程智能体的运行时天生具备云上的各种可观测指标,基础设施运维部分几乎不用担心。
对于业务执行的部分需要关注几个点：
-
端侧交互的部分，本次解决方案提供的是一个相对比较复杂的智能交互方案，多智能体自动组网的运行正常与否，生成页面的执行成功率都是需要在业务侧进行关注的，多智能体按照正常的流程应当是 M-D-X，一但观测到顺序的差异，可能是智能体的协作除了问题，引得人工介入了。另外应用的生成本身会抛出前端的系统异常，涵盖页面执行异常，模块依赖缺失，安装版本问题等，部分异常提供了自主修复能力，也提供了魔法修复这样的人类接口，但是端侧系统级别的监控仍然是必须的，因为它可以让我们更清晰的了解输出效果，从而感知产品的真实用户体验。
-
后端智能体执行的记录，包含执行的详细过程，除了对话的结果（这个部分应该体现在对外服务协议中，作为隐私信息开启与否），还要关注智能体的详细执行路径，比如 RAG 的召回路径，或者工具的调用入参，执行过程，出参等。
-
智能体编排层的执行路径，本方案比较独特的一点是将智能体的编排层提取了出来，使用了 nextjs 框架构建前后端一体的交互方案，智能体编排层本质上属于后端服务体系，从这层可以清晰的观测整个智能体服务体系的流程情况，可以通过设置 M-D-X 闭环率的指标感知更真实的服务完成率情况，当然对于整个上下文工程还包含对云资源的调度等也可以在这层的监控获取更详细的数据。
对于上述需要监控的内容，我们也提供了完备的方案，比如前端监控可以清晰的探查端侧应用的各种情况，执行异常，控制台的错误日志等，此外通过 session replay 可以获取更清晰的用户操作轨迹。后端基于 SLS 为底座的监控体系，支持对智能体业务底座的深度感知，将详细信息收集上报，然后提供专业的大盘查看信息。更多详情请参考【6】。
Q&A
是否可以更换模型，怎么换？
可以，而且非常简单，切到智能体底座 AgentCraft 后台添加兼容 openai 的任意模型（内置百炼服务，支持 Kimi-K2，DeepSeek，Qwen 等国内最先进模型）。
注：当前最强的 Qwen3 Coder 的模型名称为 qwen3-coder-plus，使用参数建议 temperature0.7, top_p为 0.8。
然后到智能体部分切换即可。
前端工程部分不需要任何更改，不过即便于此针对不同模型的测试效果也建议多测试后再切换。
自定义域名配置
本身 Function AI 提供的测试域名只有 1 天的使用权限，之后过期就无法继续使用了，因此如果您希望能够长期使用该解决方案，需要配置自己的域名。
以域名配置为例。
1. 进入 Function AI 项目
2. 配置自定义域名
同理需要把 vibecoding-web-server 的自定义域名也要配置上，该服务主要用于对外服务。
AgentCraft 主要为管理后台用，根据需要配置相关域名。
当把 vibecoding-web-server 的自定义域名配置好之后，根据需要到智能体底座 AgentCraft 后台进行修改，方便后续操作使用。
生成的项目整体数据存储在哪里？
生成的项目数据存储在 NAS 存储，可以登录阿里云 NAS 控制台【7】，开启 NAS 浏览器。
在根目录下可以看到。
专家模式的预览慢为什么？
现在使用了 vite 和 nextjs 14 两种框架，非专家模式是纯静态的 vite，启动时间只有几秒钟，可以很快看到页面预览，而专家模式考虑到安全和扩展性使用了 nextjs ，nextjs14 版本使用的是 webpack 构建模型，因此启动较慢，后续会升级到 nextjs15 使用 turbopack 构建器，会快很多。
专家模式无法发布
这个部分正在构建中，先在的解决方案是可以将项目 download 下来，然后使用 s 工具【8】部署到函数服务上使用。
后续的升级方案
智能体底座 AgentCraft 和 VibeCoding 的应用都是基于 S 应用模版构建，其中底座的升级可以通过在 FunctionAI 上构建新的版本来实现，而内部的应用可以通过在底座上直接新建获得最新版，新版本测试无误后可以切换域名路由进来。
【1】AgentCraft介绍
agentcraft-docs.serverless-developer.com/
【2】阿里云Function AI控制台
cap.console.aliyun.com/projects
【3】AliyunFcDefaultRole
ram.console.aliyun.com/roles/detai...
【4】产品计费模式
help.aliyun.com/zh/cdt/prod...
【5】AI 网关
help.aliyun.com/zh/api-gate...
【6】Web & H5应用快速入门
help.aliyun.com/zh/arms/use...
【7】阿里云NAS控制台
nas.console.aliyun.com/cn-hangzhou...
【8】s工具