一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > Serverless > 正文内容

FaaS与AI的理性结合：为什么我们不需要另一个Dify

anycodes2个月前 (06-28)Serverless700

当阿里云推出FunctionAI，试图用函数计算和Cloudflow重新构建一个云上的AI应用平台时，一位开发者朋友的吐槽引起了我的注意："我翻遍了火山引擎、腾讯云SCF、阿里云FC的文档，都没找到一篇教我如何用FaaS开发Agent的实用指南。大家都在忙着做平台，却没人告诉我怎么把一个想法变成一个可运行的Agent。"

这个吐槽道出了当前AI基础设施领域的一个悖论：**平台越来越多，但开发者的困惑却并未减少**。

## 重复造轮子背后的产品迷思

这让我想起了云计算早期的一个现象：当AWS证明了IaaS的商业模式后，几乎每个IT巨头都在做自己的"AWS"。历史似乎在重演，只是这次的主角从云计算变成了AI，从IaaS变成了AI应用平台。但问题是，当每个云厂商都在做自己的Dify时，用户真的需要这么多功能雷同的平台吗？

更讽刺的是，这种重复不仅发生在公司之间，甚至发生在同一家公司内部。**不同的技术团队基于自己的技术栈，都试图构建"完整的AI故事"**，结果是资源分散、定位重叠、用户迷茫。

从产品管理的角度看，这是典型的**"解决方案导向"而非"问题导向"**的思维。团队先有了技术（函数计算），然后寻找可以应用的场景（AI），最后包装成一个平台。但用户需要的真的是另一个平台吗？

Dify的成功有其独特的时代背景和先发优势。作为LLM时代的早期开拓者，它不仅占据了用户心智，更重要的是建立起了完整的生态系统。即便如此，Dify在企业级场景、性能优化、成本控制等方面仍有明显短板。一个非AI专业的团队想要在几个月内做出一个更好的Dify，这种想法本身就违背了产品发展的基本规律。

## 被忽视的开发者真实需求

回到那位开发者的吐槽，它揭示了一个被严重忽视的真相：**开发者不缺平台，缺的是路径**。

当前的现状是什么？打开任何一个云厂商的FaaS文档，你会看到大量的技术规格说明：内存配置、并发限制、触发器类型。但当一个开发者想要构建一个AI Agent时，他真正需要知道的是如何设计Agent的输入输出接口，如何优雅地处理与LLM的交互，如何在无状态的函数中管理必要的会话上下文。他需要理解在函数的生命周期限制下如何处理可能的超时问题，需要掌握如何在本地环境中模拟和调试Agent的行为，更需要知道上线后如何监控Agent的实际表现和成本消耗。

这些问题在现有的文档中几乎找不到答案。云厂商忙着搭建宏大的平台架构，却忘记了最基本的事情：**帮助开发者走通从想法到实现的第一步**。

这反映出产品设计中的一个常见误区：**过度关注功能完整性，忽视用户旅程设计**。一个优秀的产品不应该只是功能的堆砌，而应该是用户达成目标的桥梁。

## 从平台思维到赋能思维的转变

那么，FaaS与AI的正确结合方式是什么？我认为关键在于思维模式的转变：**从"我要做一个AI平台"转变为"我要让开发者更容易地构建AI应用"**。

这种转变首先体现在工具链的设计理念上。与其构建大而全的平台，不如提供精准解决问题的工具。开发者需要的是一个能够快速生成Agent脚手架的CLI工具，需要预配置好的模板来处理常见的Agent模式，需要在本地就能模拟LLM响应的调试环境，更需要能够分析Token使用和响应时间的性能工具。这些看似零散的工具，恰恰是开发者日常工作中最需要的支撑。

> 这里触及了一个深层困境。上述功能在Dify等专业平台中都已成熟实现，而计算平台涉足这些领域时，面临的不仅是技术挑战，更是定位的根本矛盾。以Token统计为例，看似简单的需求背后隐藏着无穷的产品细节和技术决策。**这种困境的本质是角色错位：不做这些功能，似乎缺失关键能力；做了，又陷入与专业AI平台的同质化竞争，背离了计算平台的核心定位。**

其次是最佳实践的沉淀方式。开发者真正需要的不是抽象的架构图和概念说明，而是能够直接参考和修改的代码示例。如何实现一个稳定的天气查询Agent，其中的错误处理和重试机制如何设计；如何构建一个高效的数据分析Agent，在函数的内存限制下如何处理大量数据；如何优雅地处理长时间运行的任务，在函数超时前如何保存中间状态；如何实现多个Agent之间的协作，在无状态环境下如何传递上下文。这些具体而微的知识，才是开发者真正的需求所在。

最后是生态连接的构建。FaaS的价值不在于替代现有的AI平台，而在于成为一个高效的连接器。它应该提供与主流AI服务如OpenAI、Claude的标准化集成方案，与LangChain、Semantic Kernel等流行框架的无缝适配，与各类向量数据库的便捷接入方式，以及与企业现有的监控、日志、计费系统的深度对接。这种连接不是简单的API封装，而是要深入理解不同系统的特性，提供最优的集成方案。

## 回归本质，计算平台的核心价值

在产品定位上，我们需要认清一个事实：**FaaS首先是一个计算平台，而不是一个AI平台**。它的核心价值在于提供更好的计算抽象，而不是更多的AI功能。

从这个角度看，FaaS在AI时代的真正机会在于发挥其独特的技术优势。AI推理的间歇性负载特征与FaaS的按需计费模式有着天然的契合度。但要真正释放这种价值，需要的不是另一个应用平台，而是更精细的资源调度和计费模型。试想，如果能够实现真正的按Token计费，按实际推理时长收费，而不是按照预留资源收费，这将从根本上改变AI应用的成本结构，让更多的创新应用成为可能。

> 前段时间参与信通院Serverless×AI规范标准制定时，有人提出FaaS的计费模式应该支持按Token计费。这是典型的用户视角思维——尽管这与FaaS的技术本质并不完全匹配，但却深刻反映了一个问题：**用户对AI平台的认知是功能驱动的，他们关注的是"平台能否满足我的需求"，而非"平台的技术架构是什么"**。当FaaS无法提供Token级别的统计和计费时，即便它在技术上多么适合运行AI工作负载，也难以在用户心智中建立"AI平台"的认知。这种认知鸿沟，恰恰是FaaS在AI时代面临的最大挑战之一。

当我们谈论Agent时，本质上是在谈论可被AI调用的函数。FaaS天然就是运行这些函数的最佳环境。但关键不在于提供更多的功能，而在于定义清晰的标准和规范，让任何函数都能够轻松地被AI发现、理解和调用。这需要的是对AI工作方式的深刻理解，以及对函数接口设计的精心打磨。

用户的AI应用很少是孤立存在的，它们需要访问数据库、调用其他服务、触发复杂的工作流。FaaS的事件驱动特性使其成为天然的集成层，但这种集成必须是无缝的、高效的、可靠的。这要求FaaS平台不仅要理解计算，还要理解数据流、理解业务逻辑、理解系统架构。

## 产品成功的关键：克制与专注

从产品战略的角度看，成功的关键往往不在于做得更多，而在于做得更精。对于FaaS平台而言，明确不做什么与明确要做什么同样重要。不做另一个Dify，不做prompt管理平台，不做模型训练平台，这些领域已经有专业的玩家在深耕，强行进入只会分散资源、模糊定位。

真正应该聚焦的是核心价值的打磨。做最好的Agent运行环境意味着要在冷启动、资源调度、错误处理等技术细节上精益求精；提供最优的成本效益意味着要深入理解AI工作负载的特征，设计出真正符合使用模式的计费方案；构建最顺畅的开发体验意味着要站在开发者的角度，消除每一个可能的摩擦点。

但核心价值的打磨不应止步于此。**FaaS的使命是帮助开发者快速构建应用——不仅仅是AI应用，而是任何类型的应用**。无论是传统的Web API、数据处理管道，还是新兴的AI Agent，都应该能够在FaaS平台上找到最适合的构建路径。这种普适性才是计算平台的根本价值所在。

特别是在Agent领域，仅仅提供一个安全的sandbox运行环境是远远不够的。**真正的挑战在于生态对接**——如何与Dify、LangChain、FastGPT等主流平台无缝集成，如何适配不同的Agent协议和标准，如何让开发者的Agent能够被更广泛的AI应用发现和调用。功能不会是孤立的，函数不会是孤立的，生态更不会是孤立的。从某种意义上说，**在AI时代，得生态者得天下**。

当然，在AI浪潮席卷的当下，结合AI发力是必然选择。但我们必须时刻清醒地认识到：**发力的目的是为了更好地满足用户需求，帮助用户构建成功的应用，与用户一起成长**。这不是关于"我们能做什么"或"我们要做什么"的技术秀，而是关于"用户需要什么"和"如何让用户更成功"的价值创造。只有坚持这种用户导向的产品哲学，FaaS才能在AI时代找到真正的立足点。

**平台的成功最终取决于在其上构建的应用的成功**。这要求我们把开发者体验放在首位，从文档的组织到API的设计，从错误信息的表述到社区的运营，每一个细节都应该围绕"如何让开发者更成功"，"如何让用户更成功"来思考。

在AI浪潮中，每个技术平台都在寻找自己的位置。但真正的机会不在于随波逐流，而在于找到自己的独特价值。对于FaaS而言，这个价值就是成为AI时代最可靠、最经济、最灵活的计算基础设施。**不是通过做另一个AI平台，而是通过让每一个AI应用都能更好地运行**。

这种克制，恰恰是最大的野心。

扫描二维码推送至手机访问。

本文链接：https://www.runor.cn/?id=11

标签: 云计算函数计算 AI平台开发者体验技术生态

分享给朋友：

返回列表

上一篇：从 Serverless AI 引发的思考：从确定性模板到意图驱动

下一篇：FaaS+Agent：深入探索无服务器计算的产品边界

“FaaS与AI的理性结合：为什么我们不需要另一个Dify” 的相关文章

刘博说云

大家都在搜：

FaaS与AI的理性结合：为什么我们不需要另一个Dify

“FaaS与AI的理性结合：为什么我们不需要另一个Dify” 的相关文章

当AI学会用AWS CLI：AIOps实践的新思路

AI Coding 与 FaaS 的融合：软件开发范式的必然演进

从 Serverless AI 引发的思考：从确定性模板到意图驱动

当AI成为云函数的"造物主"：从AI Coding到AI Service的演进

FaaS+Agent：深入探索无服务器计算的产品边界

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

FaaS与AI的理性结合：为什么我们不需要另一个Dify

“FaaS与AI的理性结合：为什么我们不需要另一个Dify” 的相关文章

当AI学会用AWS CLI：AIOps实践的新思路

AI Coding 与 FaaS 的融合：软件开发范式的必然演进

从 Serverless AI 引发的思考：从确定性模板到意图驱动

当AI成为云函数的"造物主"：从AI Coding到AI Service的演进

FaaS+Agent：深入探索无服务器计算的产品边界

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论