Marico's space

最近折腾了 FastAPI + AI Agent 的组合，踩了几个坑，这篇把问题说清楚。 用 FastAPI 构建 AI Agent 其实没那么复杂，关键是把几个核心模块拆清楚：LLM 调用、工具系统、记忆层。把这些理顺了，剩下的就是排列组合。 PYTHON 环境怎么搭 先搞个干净的 Python 环境，装好依赖库。我一般用 pyenv 管理 Python 版本，配合 venv 做虚拟隔离

最近在给团队的项目加 LLM（大型语言模型）能力，踩了几个坑之后才意识到这事比想象中复杂。LLM 应用不是简单的"传统 Web 应用加个 API 调用"那么简单——当模型直接嵌到请求处理逻辑里，攻击面完全变了。最大的坑在于：模型根本分不清"系统指令"和"攻击者输入的内容"。 这篇整理了六个风险域、共 16 项在生产环境前必须搞定的安全控制措施。 为什么威胁模型不一样 传统 Web 应用里，

用 FastAPI 写 API 几个月了，估计大家都被"async vs sync"这个话题折腾过。框架上手容易，两种写法都能跑，但真到线上选错了，那延迟、吞吐量、数据库驱动的坑一个都躲不掉。这篇把核心差异说透，附上压测数据，最后给个实操清单。 > 一句话总结——有可等待的 I/O（HTTP 调用、异步 DB 驱动、WebSocket）就用 async，CPU > 密集型任务或者只能用老旧阻塞库

不知道你有没有遇到过这种情况：代码写着写着，突然发现自己在一个文件里写了20个if/else，全是对象创建逻辑；或者改了个配置，全局搜索半天发现到处都在new实例；再或者产品说"加个新功能，要通知到所有相关模块"，然后你得在十几处地方手动加代码。这些坑我都踩过，而且踩得还挺惨的。 后来才明白，这些不是自己菜，是缺设计模式。Python语法灵活，上手快，但如果没有Factory、Singleton

最近折腾Webhook对接，踩了几个坑才明白：大多数安全问题都不是什么高深莫测的漏洞，就是那么几个老错误反复出现。团队验了一次签名，看到通过了，就直接上线了。这篇把上线前必须做的检查捋一遍，每条都是实际有人踩过的坑。 1. 用原始请求体验证签名 这是所有Webhook提供商最常见的bug。签名是提供商发送的原始字节计算出来的HMAC（哈希消息认证码）。如果你的框架先解析了JSON，再从解析后

AI Agent 工具调用生产模式：6 个月全天候运行总结的 8 条经验 > 让一个大语言模型（LLM，即大型语言模型）调用一次工具很容易。但要让它每天可靠地调用 500 次，连续跑 6 个月——这是完全不同的挑战。 2026 年了，OpenAI、Claude、Gemini 这些主流大语言模型都原生支持函数调用（Function Calling）。用 LangChain、CrewAI 这类

最近折腾了半年多的 AI Agent 工具调用，每天 400-600 次调用，踩了不少坑，这篇把问题说清楚。 让大语言模型（LLM，人工智能大模型）调用一次工具很容易。但让它每天稳定调用 500 次，连续跑六个月——这是完全不同的挑战。 2026 年的 LLM 都原生支持函数调用了，OpenAI、Claude、Gemini 全都支持。LangChain、CrewAI、AutoGen 这些框架

还记得那天晚上，我们的API在流量突增时开始扛不住了吗？监控大屏上看似平稳的曲线，用户端却在疯狂报502错误，钉钉群炸锅一样响个不停。我们当时的状态就像在用汤勺往外舀沉船里的水——杯水车薪。那套单体架构每个请求都直连数据库，读操作写操作连心跳检测都不放过。数据库在嘶吼，P99延迟曲线看起来就像某个变态过山车设计师的手笔。 那一刻我才意识到，需要的不只是"加个缓存"这个事后补救，而是把缓存当成核心

最近折腾 AI Agent 管道，踩了几个差点删库的坑，这篇把问题说清楚。 生产环境里的 AI Agent 能把你的数据库删个干净。不是因为模型有恶意，是因为它根本不知道自己不知道什么。它看到个解析不了的弹窗，猜了个错误操作，然后这个猜测就在生产系统上执行了。 这个问题我见过的项目够多了，知道它不是理论风险。问题不是你的 Agent 会不会犯错，而是你的架构能不能在犯错时活下来。 下面是我在

去年帮朋友做项目，试了一圈所谓的"Vibe Coding"工具——Cursor、Bolt、Replit Agent，还有国内一些类似的产品。说实话，这些东西拿来跑 demo 确实快，几个小时就能把一个"看起来能跑"的原型搭出来。创始人看到界面出来了，热血沸腾，觉得产品明天就能上线。 但问题往往在后面才暴露出来。Vibe Coding 在规模化场景下的坑是可以预见的：生成的代码没有整体架构，加个功