Marico's space

最近折腾了一段时间开源权重大语言模型的 API 集成，踩了几个坑，这篇把问题说清楚。 AI 领域的玩法正在转变。很长一段时间里，用大语言模型（LLM）意味着把你的数据扔给一个闭源黑盒，祈祷它别出事，还得为这个"特权"付高价。但风向变了。 开源权重 LLM 的时代来了。和闭源模型不同，开源权重模型公开了模型权重、架构，甚至训练方法。对开发者来说，这是游戏规则的改变——意味着透明、可定制，以及摆脱

最近在处理支付系统 webhook 的时候，被重复投递的问题折腾了一把。说实话，之前一直没把这个当回事，觉得 webhook 发过来处理就是了。结果线上还真复现了一次——业务逻辑跑完了，但返回给支付方的响应因为网络抖动超时了，对方直接重试，导致同一个订单被处理了两遍。好在金额不大，没有造成实际损失，但这个坑让我意识到，webhook 幂等性不是"锦上添花"的优化项，而是必须做的基本功。 这篇文章

最近折腾了一个叫 orkestr Functions 的平台，踩了几个坑，这篇把问题说清楚。 没人调用的函数应该不花钱，一旦有人调用又能瞬间响应。这是 Serverless（无服务器计算）的设计初衷，也是大多数欧盟团队偷偷放弃的东西——为了数据驻留选 AWS Lambda，为了速度又得找个美国托管的备选方案。以前你必须二选一。但这周，orkestr Functions 换上了新的Serving引

最近折腾了 MCP 服务器，想让 AI agent 能帮创始人自动发布产品、推送更新、发 changelog。搭完之后想接入 Claude Connectors Directory，结果一头撞上了 OAuth 2.1 + PKCE + 动态客户端注册这堵墙。踩了几个坑，这篇把问题和解决方案说清楚。 思路：让 AGENT 干那些重复的活 我运营的是 BetaFinds，一个早期产品发现平台。每

核心问题从来不是"更多智能体就能更聪明"。关键在于：不能让同一个智能体同时扮演正确性的"作者"和"裁判"。这篇文章是写给想在自己技术栈上构建这套东西的人——一个可移植的参考架构，拿走就能用，不是我的机器日志。 你大概有过这种经历：让一个编程智能体从规划一路做到实现。能用——但你心里清楚风险：同一个智能体定义了什么是"正确"，又自己判断是否达到了正确。绿灯是自己给的，diff审查也是自己做。绝大多

前阵子踩了个坑，某iPaaS平台在Kubernetes上跑的集成运行时Pod频繁重启。排查了一圈，最初以为是集成逻辑的问题——消息处理正常、API响应稳定、平台看起来没什么异样。但就是有几个Pod一天能被拉起好几次。 第一反应是应用层的问题。平台要处理大量的数据转换、消息路由和连接器执行，就怕是哪个集成流创建了过多对象或者有内存泄漏。结果呢，堆内存占用率远低于配置上限，GC日志看着也很健康，Pr

我关注代理式编程（Agentic Coding）的原因，和我关注工程流程的原因一样：任务一旦变得复杂，我希望工作能以可检查、可重复、可持续的方式推进下去。 现在的AI辅助编程，大多数时候还是一种即兴表演。问一下，给个结果，调一下提示词，再试一次，然后祈祷有用的推理过程还藏在聊天记录里。小的改动这样做还行。但一旦任务涉及到架构、测试、评审或者合并请求（PR），这套玩法的说服力就大打折扣了。 我真

最近折腾了一段时间的AI隔离架构，踩了几个坑才把这里面的门道摸清楚。传统的安全方案对付现在的自主AI勒索软件已经开始力不从心了，这篇把我研究的一些思路整理出来，跟大家聊聊怎么设计沙箱环境来应对这种新型威胁。 说白了，自主AI系统和传统恶意软件最大的区别就是：传统软件按套路出牌，而AI能自己思考、动态调整战术。你以为把它关进沙箱就安全了？它可能比你更懂怎么识破这个沙箱。 自主勒索软件威胁向量

这是 Qwen Cloud 黑客松的参赛作品，拿了博客文章奖。项目地址在 GitHub 上，有兴趣可以去看看。 写这篇的原因是觉得这个方向挺有意思的——不是单纯把应用跑起来，而是把迁移过程中的踩坑经验固化成可复用的东西。 为什么做这个 现在的 AI 应用基本都是一个套路：绑死一个云服务商、一个模型、一个 SDK（通常是官方提供的）。这样开发确实方便，直到出问题时才发现麻烦了。 如果哪天某

最近折腾了一下电子护照（eMRTD）阅读库的差分测试，踩了几个安全层面上的坑，这篇把问题说清楚。 一致性测试套件告诉你某个库是否通过了自己的测试用例。但它没法回答一个更根本的问题：两个独立实现的库，在收到完全相同的协议流量时，会不会做出同样的安全决策？ICAO Doc 9303 定义了电子护照应该怎么工作，但你在项目中选择的开源库，决定了你的应用实际会遭遇什么。单元测试通过是一回事，互操作测试是