现在在做什么

AI Agent 的可靠性工程。

不是"能不能跑通 demo"，而是"在生产环境跑一周会不会挂"。

上个月给 AdalFlow（一个开源 Agent 框架，GitHub 4K+ star）提了 PR，修了 OpenAI Reasoning Models 的参数兼容问题和 Generator 里的 UnboundLocalError。修完之后反而更困惑了——这些 bug 之所以存在，是因为大家都在追求"能跑"，没人认真想过"挂了怎么办"。

具体来说，我在想三个问题：

• Agent 的"遗忘"——上下文窗口满了之后，怎么决定丢掉什么？现在主流方案是截断或摘要，但都有信息损失。
• 工具调用的幂等性——同一个 API 被调两次，第二次应该返回缓存还是重新执行？
• 降级策略——当 LLM API 超时或返回垃圾时，Agent 应该怎么优雅地退回来？

没有一个好答案。但我倾向于认为，Agent 框架的问题不在框架本身，而在我们对"可靠性"的定义太模糊。

个人网站在 AI 时代的价值。

AI 能生成一切的时代，手写一个网站是不是一种奢侈？

我觉得恰恰相反——正因为 AI 能生成一切，手动选择留下什么、去掉什么才变得更有价值。AI 可以帮你写 67 篇技术文章的结构，但它不会帮你决定哪篇值得放在首页、哪篇应该扔进"失败博物馆"。

这个网站本身就是答案。每一处排版选择、每一个观点表达、甚至这个 /now 页面，都是"一个人在此刻正在想什么"的记录。这是 AI 生成不了的。

• 《Designing Data-Intensive Applications》（DDIA）— 第三遍了。第一遍通读，第二遍跳着看，这次专门啃"一致性与共识算法"那几章。每次读都有新理解，这本书的密度太高了。
• Self-RAG 和 CRAG 的论文 — RAG 的下一步不是"检索更多"，而是"判断要不要检索"和"检索完了判断质量"。Self-RAG 让模型自己决定是否需要检索，CRAG 加了检索结果的验证层。两个方向都值得深挖。
• 各种 Agent 框架的源码 — 最近在翻 AdalFlow 和 LangGraph 的代码。看别人怎么设计状态机、怎么处理工具调用的错误恢复。读源码比读文档有用十倍。

以前觉得 Docker Compose 是"小玩具"，生产环境必须上 K8s。

现在觉得：对于 90% 的个人项目和小团队，Docker Compose 就是最优解。K8s 的运维成本被严重低估了——光是 etcd 备份、证书轮换、RBAC 配置就够一个人折腾一周。

我自己的 GlimmerAI 网站就是 Nginx + Docker Compose 部署在阿里云上，稳定运行，没有任何问题。简单就是美。

技术选型不是选"最先进的"，是选"最适合当前阶段的"。这句话听起来像废话，但真正内化需要踩很多坑。

在写一个关于 "AI 工程化" 的系列。不是教你怎么用 LangChain，而是教你怎么把 LangChain 写的东西部署到生产环境、监控它、调试它、在它挂掉的时候知道为什么挂。

这个系列会覆盖：日志追踪（一次 Agent 调用背后可能经过了 12 步，怎么追踪？）、评估体系（怎么知道 RAG 检索的质量？）、成本控制（token 费用怎么优化？）、故障降级（LLM 挂了怎么办？）。

已经发了几篇了，还在持续更新中。