Marico's space

最近折腾 Stripe Webhook 的重放机制，踩了一个不大不小的坑——签名验证超时。团队接入了死信队列（DLQ），处理支付事件的容错能力是有了，但每次重放积压的事件，SDK 就会抛出一个冷冰冰的错误： Error: Webhook signature verification failed: Timestamp outside the tolerance zone (1800s > 300

最近踩了一个Webhook签名验证的坑，排查了半小时才搞清楚根因。这篇把问题说清楚，重点是：签名检查必须在任何JSON解析中间件运行之前完成，要用接收到的原始字节来校验签名。 部署后签名检查失败的常见原因很明确：发送方对一组字节序列做了签名，而服务端校验的是另一组字节序列。express.json()会消费掉请求流，把req.body替换成一个JavaScript值。再把这个值序列化回去不是补救

最近折腾了一个从前端触发测试修复的 Agentic 工作流，踩了不少坑，这篇把整个过程说清楚。 我们前端每次改个 UI 组件，就引发一场小噩梦：测试挂了，测试自动化（TA）团队被叫过来，然后就是没完没了的来回拉锯。 我琢磨着能不能通过在工作流中引入一个无头 Agent来减少这种摩擦——让 Agent 自动接手失败的测试并尝试修复。 不过搞这种自动化确实是个硬骨头——要设计有意义的工作流、处理

最近折腾 Claude Code 的 MCP（模型上下文协议）权限配置，踩了几个坑，这篇把问题说清楚。 添加一个 MCP 服务器后，Claude Code 每次调用它的工具都会弹出确认框。光是查个只读数据都要点一下确认，用不了多久就烦了。 核心用法很简单：在 permissions.allow 里写 mcp__<服务器名> 就能自动批准该服务器的所有工具，或者写 mcp__<服务器名>__<工

最近给客户做两个 Odoo 18 实例之间的集成，踩了不少坑。这篇把一个核心问题说清楚：重试（Retry）不等于恢复（Recovery）。 一个集成任务失败了，第一反应往往是：放回队列重跑。 这可能修复一个临时网络故障。但也可能产生重复订单、重复发货更新，或者触发一个已经发生的外部副作用。 直接说结论：重试是重复执行一个操作；恢复是让系统回到已知的、一致的状态。恢复可能需要重试，但更多时候需

最近折腾AWS成本优化，踩了几个坑，这篇把问题说清楚。 AWS（亚马逊云服务）为开发团队提供了极大的灵活性。几分钟就能启动基础设施，应用自动扩缩容，存储海量数据集，跑多地域工作负载，还不用自建机房。听起来挺美的。 但问题来了——这种灵活性是有代价的，AWS账单的增长速度往往超出预期。 一个小型开发环境可能悄悄变成昂贵的生产平台。闲置资源不断累积。EC2实例配得太大，7x24小时跑着，应用却几

最近折腾了一款叫 Hemory 的 App，专门解决一个问题：你的 AI 助手知道你在网上搜了什么，但它不知道你今天下午跟客户聊了什么。这个工具本质上是把你的日常对话变成可搜索的记忆，让 AI agent（人工智能代理）能调取你真正说过的话。这篇把核心用法、最实用的几个提示词、以及怎么用它赚钱都说清楚。 一句话总结： Hemory 是个持续监听的应用，把你的日常对话转成可搜索的记忆，通过 MCP

这两年在生产环境里跑 AI Agent，踩过的坑比想象中多得多。最初以为只要砸钱上最大的模型就能解决一切问题，结果发现同样一个模型，换个"外壳"表现能差出一倍不止。这篇文章把 Agent Harness（智能体框架层）这个概念彻底讲清楚，为什么它比模型权重本身更能决定你的应用能不能上生产。 在前几年大模型爆发的时候，整个行业几乎陷入了一种"唯参数论"的狂热——觉得任何技术瓶颈，不管是代码幻觉、编

最近在项目中引入 AI 代理（Agent），踩了几个坑，这篇把问题说清楚。 AI 代理的能力越来越强了。 能搜信息、能跨数据推理、能调用工具、能操作应用，越来越频繁地替我们干活。 机会是巨大的。 但也引出了一个我觉得值得更多关注的问题： > AI 代理“能”访问某样东西，就意味着它“应该”访问吗？ 当我们从主要生成回答的 AI 助手，走向能执行动作的代理时，负责任的 AI（Respon

最近折腾了一个身份验证系统的课设项目，踩了几个坑，这篇把踩坑经验和设计思路说清楚。身份验证是现代应用安全的基础，不管是校园管理系统、在线教育平台还是企业内部工具，都需要一个可靠的方式来识别用户、控制访问权限。 一个登录表单看起来很简单，但构建安全的身份验证系统远不止接收用户名和密码这么简单。完整的设计必须保护密码安全、验证用户输入、安全管理会话、防止未授权访问、处理登录失败场景、保护敏感信息、提