Marico's space

最近折腾了 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（语言服务器协议）就是静态分

最近折腾AI编程助手，踩了几个坑才明白一件事：当前这波AI代码工具，其实有个挺根本的矛盾——训练数据里塞满了全球的公开代码，结果对咱们自己项目里的代码结构反而一脸懵。 行业里通用做法是"靠提示词蒙"（Prompt Guessing）——把光标附近的代码片段塞给大模型，希望语义关联是"意会"的。这招太脆了。符号被import了不知道，类型推断不出来，跨文件的逻辑更是瞎子摸象。 解法不是上更大的模