Marico's space

做过公开表单接口的应该都有过这种经历：接口跑得好好的，突然有一天数据库账单翻了几倍，查日志才发现有个客户端在不断重试，一秒钟请求了上千次。这种事情发生一次就够刻骨铭心了。 现在每个有公开接口的项目，我都会上这套防护方案。 1. 用 UPSTASH 做速率限制 Upstash 的 Redis 方案对 Next.js 很友好，专门为无服务器场景设计，每次请求不需要保持连接。 npm inst

最近折腾了 AI Agent 的权限继承问题，踩了几个坑，这篇把核心问题说清楚。 当一个 AI Agent 需要做实际工作时，最危险但省事的做法就是给它一个 API Key，然后祈祷 prompt 能管住它。 这条路走不通。一个有用的 Agent 现在可以读取工单、创建 issue、更新 CRM 记录、运行查询、触发工作流、调用内部工具。如果这些都通过一个宽泛的 Key 来做，你有的不是用户权

最近在给项目接 Ace Data Cloud 的登录功能，官方文档写得很散，自己踩了几个坑才跑通。这篇把 OAuth 2.0 配合 PKCE 的完整流程梳理一遍，包括注册应用、生成授权链接、换取令牌、调 API，都覆盖到。 能做什么 如果你需要代表用户访问 Ace Data Cloud 的资源，让用户手动复制 API Key 是个很糟糕的体验。更合理的做法是用 OAuth 2.0 授权码流程

"同样的问题，今天花了四十秒。上周只要十秒。" 又是第2、3部分那位测试同学。她问Agent："我能退掉上一单的那件蓝色外套吗？"这个问题需要两次工具调用：一次查订单，一次读退换政策。上周大概十秒搞定。那天花了四十秒。 什么都没变。没有发布新版本，没有改配置，没有新数据。代码一周没动过。 但我解释不了，因为我没有任何一个步骤的具体耗时。我有日志，但那是一堆HTTP层的文本堆砌。我说不清那多出

最近看到 Pillar Security 披露的 Google ADK（Agent Development Kit，智能体开发工具包）安全漏洞，忍不住想聊聊这事儿。AI 工作流自动化听着很爽，但权限管理一旦没到位，分分钟被人拿来做坏事。这篇把漏洞的来龙去脉和技术细节捋清楚，看完你就知道现在 Agent 系统里那些"自动化"到底埋了多少雷。 自动化仓库里的利用路径 核心风险在于一个 triag

最近在整理Google AI产品线，发现NotebookLM改名这事儿比我想象的要复杂一些——不只是换个名字那么简单，实际的访问权限部署是分阶段的。这篇把我查到的信息整理一下，顺便说说对实际使用的影响。 简单说就是：Gemini Notebook（原NotebookLM）确实在扩大覆盖范围，但官方说的是"分阶段发布"，不是所有订阅用户同时拿到。有几个坑值得注意，特别是如果你打算基于这个产品设计工

最近折腾 Next.js 的 Edge Middleware，踩了几个坑，这篇把问题说清楚。 做了这么多年 Web 开发，一直被一个老问题困扰：安全检查到底放在哪里做最合理？传统方案是请求先到中心服务器，验完身份再放行。但如果用户在广州访问托管在北京的服务器，光物理距离就要付出几十毫秒的代价。更憋屈的是，如果用户压根没登录，或者 Token 已经过期，这几十毫秒完全是白跑——服务器浪费算力处理了

测试内容

终于写到第 4 部分了，这个系列也该收尾了。简单回顾一下我们之前折腾的东西： 1. 搭了一个并行跑 Frontend（Angular）和 Backend（.NET）的流水线 2. 把 CI/CD 从收费云服务迁移到了自建的 Self-Hosted Runner（省钱才是硬道理） 3. 实现了 Tag 和 Changelog 的自动生成 到这一步，你的流程已经比很多中小厂要专业了。但如果你

最近折腾了一圈AI编程助手，发现一个挺有意思的矛盾：这些模型训练时看过互联网上几乎所有的公开代码，但偏偏对自己正在写的项目一无所知。行业里过去几年一直在靠"提示词猜测"——把附近几行代码塞进上下文窗口，赌LLM能自己猜出语义关系。这种做法脆得很，一旦涉及跨文件引用、隐式类型推导或者分散在多个模块里的逻辑，AI就开始瞎编。 解决方案不是更大的模型，而是更好的协议。LSP（语言服务器协议）就是静态分