跳到主要内容

198 篇博文 含有标签「Node.js」

查看所有标签

为什么我更喜欢把 AI 能力做成可组合服务：先拆 contract、适配器，再谈 Agent

· 阅读需 4 分钟
一介布衣
一介布衣
全栈开发者

我现在越来越少把一整段 AI 逻辑塞进一个“很聪明的 Agent”里。不是因为 Agent 没价值，而是只要功能开始进入多人协作、线上排查和持续演进阶段，把能力拆成可组合服务，几乎总会比单一大黑盒更容易维护。

一次缓存策略误判带来的延迟问题

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-30 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多人做 AI 服务优化时，一看到延迟上来，第一反应就是“加缓存”。这当然不是错，但问题在于：缓存并不是天然减延迟，它只是在某些命中条件下减延迟。

前阵子我就遇到过一次很典型的反效果。团队本来是想给一条 AI 处理链降一点时延，结果缓存加上去之后，p95 反而更高了。

后来排查下来，问题不是 Redis 慢，也不是代码写挂了，而是我们缓存错了层。

线上 AI 服务的超时策略，我更推荐这三层

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-25 11:40。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

如果只拿一个线上场景来说超时策略，我会选“知识问答 + 检索 + 工具调用”的组合请求。

这类请求最容易暴露一个错觉：团队经常以为“只要给 SDK 设一个 30 秒超时就够了”。但真实请求进来之后你会发现，30 秒这个数字根本没有回答任何关键问题：

  • 用户愿意盯着这个页面等多久？
  • 整条链路最多能烧掉多少预算时间？
  • 单个检索或工具步骤慢到什么程度时就该放弃？

当这些问题没有分开，超时就不会是一个边界，而只是一个会随机爆炸的数字。

队列、缓存、限流，AI 接口成本失控前的三个信号

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-09 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

AI 功能一旦进入真实流量，成本问题迟早会从“财务关心的事情”变成“工程必须立刻处理的事情”。最麻烦的是，它通常不会一开始就用一种非常明显的方式爆炸，而是会先通过一些不太起眼的信号慢慢浮上来。等到大家真正感觉到痛，往往已经不是“优化一下”能解决的程度了。

我现在看 AI 接口成本是否快要失控，不会先看总账单，而会先看系统里有没有出现下面三个信号。它们一旦出现，就意味着网关层和调度层必须尽快补队列、缓存和限流，不然越往后越被动。

Node.js 接 AI 服务时，为什么网关层比业务层更先复杂

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-05-06 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

如果只用一个真实链路来解释这个标题，我会选“内部知识问答 API”。

这套服务最开始的目标很简单：前端把用户问题丢给后端，后端转发给模型，再把答案返回。最早大家以为复杂度会集中在业务逻辑上，比如：

  • 检索怎么做
  • 答案怎么组织
  • 是否需要引用来源

但上线后很快发现，真正最先失控的不是这些，而是业务层外面那一圈：谁能调用、该走哪个模型、超时怎么退、缓存怎么命中、配额怎么算、错误怎么统一。

也就是说，业务逻辑还没来得及长大，网关层已经先膨胀了。