现在在做什么

AI Agent 的可靠性工程

不是“能不能跑通 Demo”，而是“在生产环境跑一周会不会挂”。

上个月给 AdalFlow（一个 Agent 框架，GitHub 4K+ Stars）提了 PR，修复了 OpenAI Reasoning Models 的参数兼容问题和 Generator 中的 UnboundLocalError。修完之后反而更困惑了——这个 Bug 之所以存在，是因为大家都在追求“能跑”，却很少思考系统挂了该怎么处理。

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

• Agent 的「遗忘」——当上下文窗口满了之后，怎么决定丢弃什么？
• 工具调用的幂等性——同一个 API 调用，多次请求是返回缓存还是重新执行？
• 降级策略——当 LLM API 超时或返回异常时，Agent 应该如何优雅降级？

这些问题没有唯一答案，但我倾向于认为：Agent 框架的问题不在于框架本身，而在于我们对“Agent”的定义太模糊。

为什么手写代码在 AI 时代的价值

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

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

这个网站本身就是答案——每一处排版选择、每一个标点表达，甚至这个 Now 页面，都是“我为什么想说这些”的记录。这是 AI 生成不了的。

• 《Designing Data-Intensive Applications》（简称 DIA），已经读了一半了。第一遍通读，第二遍跳着看，特别是「复制、分区与共识算法」那几章。每次都有新理解，这本书的密度太高了。
• 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 挂了怎么办？）。

已经发布了几篇，仍在持续更新。