当企业谈论人工智能成本时，话题几乎总是从模型开始：该用哪个模型，每百万Token的费用是多少，较小的模型是否"够用"。在AI还只是聊天机器人的时代，这种思路是合理的。
但现在，随着智能体在生产环境中承担起真正的工作，这种思路就不太合适了。一个智能体任务可能会发出数十次查询，从多个系统中提取上下文，多次调用模型并写回结果。一项任务的成本和运行速度，越来越多地取决于模型周围发生的一切。
在本周Couchbase公司扩展其AI数据平面之前的预先说明会上，该公司AI业务高级副总裁蒂姆·芬利强调了一个关键趋势。公司宣布推出与亚马逊云科技Bedrock的原生集成，支持语义缓存、全托管的智能体内存，以及在亚马逊云科技上运行的模型上下文协议服务器，同时在其分析引擎（现已更名为Operational Insights）中加入向量搜索功能。
更值得关注的是此次发布背后的推理逻辑，它指出了一个大多数IT领导者尚未充分意识到的问题。
智能体是一种不同类型的用户
芬利首先用排队论来解释这个问题。随着负载上升，延迟增长速度会超过流量增长速度，而智能体正迅速推高这种负载。芬利援引了思科系统公司的一项研究，该研究发现智能体在执行同样工作时，每项任务产生的流量比人类多450%；他还引用了Cloudflare的数据，显示机器流量在今年6月就已超过人类流量，比预测提前了约18个月。
"为人类增长曲线设计的容量规划，很可能会崩溃，"芬利说。他将智能体描述为"在运行系统方面，你能想象到的最苛刻、最难伺候的用户"。我认为这是智能体AI领域最被低估的风险。大多数生产数据库的规模设计，都是基于点击、等待、再点击的人类用户模式。而智能体会并行分散成多个任务，需要在同一个循环中同时获取当前和历史数据，并且永不休息。如果把它们当作"只是更多的用户"，数据层就会成为瓶颈——通常就在成功的试点项目说服企业扩大规模之后。
企业正在降级智能以支付账单
预先说明会上最值得IT和业务领导者关注的，是模型选择与能力之间的权衡取舍。"客户一旦达到规模化阶段，面对账单，往往会主动牺牲智能，降级使用的模型，"芬利说。这与我从IT领导者那里听到的情况相符。
试点项目运行在前沿模型上，结果看起来很棒，但当财务部门看到生产规模下的推理账单时，团队就会退回到更便宜的模型，从而削弱了最初支撑该项目立项的效果。而这种权衡往往并非必要，因为大部分开支都是浪费：重复发送同样的问题、臃肿的提示词，以及每次会话都从零开始的智能体。
这正是Couchbase此次公告能够帮助缓解这种权衡的地方。语义缓存可以为相似查询提供服务，而不需要再次调用模型，该公司表示这能将大语言模型调用次数减少40%到60%。公司还宣称，在LoCoMo（长期对话记忆）基准测试中，智能体内存相比其他方案能将Token使用量降低33%到45%，而基于向量的上下文检索生成的提示词比完整上下文方案小约70%。
这些是Couchbase自己给出的数据，实际效果在很大程度上取决于工作负载的重复程度。但方向是对的：大多数企业在削减Token浪费方面的空间，要比提升模型质量的空间大得多。
融合与整合的区别
在说明会上，芬利解释了融合与整合之间的区别。后者是减少所付费使用的工具数量。而对于前者，"一个融合系统的价值大于其各部分之和"，因为每项能力都共享同一份数据。
Operational Insights中的向量搜索就是一个很好的例子。芬利以一家手机制造商的用例进行了说明，该案例要确定哪些工厂与最多的正面电池续航评价相关联。通常，这需要用到关系型数据库、键值存储、向量数据库、ETL管道和数据仓库。
Couchbase表示，它可以用一条SQL查询就解答这个问题，使用类似"group by"的"cluster by"操作，然后将结果写回，供智能体读取。"长期以来，分析领域存在一个误区，认为获得一个出色的洞察就是终点，"芬利说。"我们认为，真正的终点是行动。"
系统之间的每一次跳转都会增加延迟，引入可能失败的同步作业，增加另一套安全模型，并产生另一个数据可能过时的环节。基于过时数据工作的智能体，可能会表现得"自信而错误"。更少的环节，对AI的速度和准确性的重要性，不亚于其对成本的影响。
竞争格局
Snowflake公司和Databricks公司都押注于Postgres，而搭配pgvector的Postgres因其免费且为人熟知，已成为许多AI团队的默认选择。曾在亚马逊云科技数据库业务部门工作过的芬利并未否定这种价值，但他认为，一旦向量数量达到数亿级别，在财富2000强企业的规模下，这种方案会显得力不从心。Couchbase还指出，其产品已在领英、Amadeus以及电信软件提供商Mavenir等公司得到部署。
云、AI及IMS业务战略高级副总裁兼总经理布兰登·拉森解释道："多年来，Couchbase一直是Mavenir语音解决方案实现高可用性的关键组成部分。现在我们正在打造需要快速获取可靠上下文的新型AI语音服务，而Mavenir正在用Couchbase构建这个上下文层，因为它在生产环境中已被证明具有可靠性能。"
给IT领导者的建议
要对智能体负载建模，而不是用户负载。围绕并行分散、每项任务的多次查询以及持续的突发流量，重新构建容量规划。在扩大试点规模之前，用模拟的智能体流量对数据层进行负载测试。如果延迟增长速度超过请求量增长速度，说明排队效应正在起作用。
在降级模型之前，先衡量每项任务的成本。弄清楚有多少提示词是近似重复的，每轮对话中重新发送了多少上下文，以及智能体重建已有状态的频率有多高。缓存、内存和更好的检索机制应该是首选的优化手段。切换到更便宜的模型，应该是基于质量的决策，而不是基于预算的决策。
要计算智能体循环中的跳转次数。绘制智能体完成一项典型任务时所接触的每个系统和同步管道。每一次跳转都是一项延迟成本、一个故障点和一个治理缺口。无论选择哪家供应商，这张地图都能显示出融合方案能在哪些地方带来回报。
把缓存和内存当作生产数据来对待。语义缓存和智能体内存存储着客户上下文和模型输出。从第一天起就应用保留策略、用户级隔离、访问控制和审计追踪。向真正不同的问题返回"相似"答案的缓存，存在正确性风险，因此需要调整并监控相似度阈值。
坚持要求在你自己的规模下进行验证。供应商的基准测试只是一个起点。要在你自己的数据量、并发量和向量数量下进行测试，同时检查召回率和吞吐量。在一千万向量规模下有效的方案，在十亿规模下可能就不适用了。
保持内存层的可移植性。智能体框架正在快速演进。选择能跨LangGraph、CrewAI、LlamaIndex等多个框架工作的内存服务，这样切换框架时就不需要重建技术栈中最有价值的部分。
最后的思考
过去两年，行业一直在围绕模型展开争论。接下来的两年，焦点将转向规模化运行智能体的成本和可靠性，而这其中的大部分问题，都将在数据层得到解决。Couchbase的判断是正确的：智能体是一种从根本上不同的用户类型，其对Token经济性的关注，正呼应了当下首席信息官正在与首席财务官展开的对话。该公司面临的挑战，是要在客户默认选择他们已经熟悉的"Postgres加上各种单点工具"技术栈之前，赢得这场架构层面的争论。
宙斯·克拉瓦拉是Kerravala咨询公司下属ZK Research的首席分析师。他为SiliconANGLE撰写了这篇文章。
图片来源：Couchbase
