Writing in public · 慢但认真

Agent落地实践总结/探索

不是“AI 在企业里落地的未来”散文, 是一个个 fix 、 一段段 trace、一堆复盘的工单。
// 慢更. 一篇打磨两周, 每一篇都有可复现的 fix 点。

正在攒第一篇...

已经写完, 准备发的主题:
· 「为什么企业合规不走 LLM, 走纯函数规则引擎」 —— PAC 不重复发明的根本原因
· 「WebHook 重试策略 — 为什么不是越多越好」 —— 3 次指数退避 vs 8 次线性重试
· 「多 PM2 进程间共享状态, 为什么我们不接 Redis」 —— 纯 JSON 文件契约的优缺点
· 「飞书多租户部署 — 12 个隐藏坑」 —— 仅仅重读一次官方文档不够的原因

// 订阅, 发出来第一时间通知

订阅更新

PAC 引擎走了 9 个原子 commit

v1.0 · published 2026-08-17 · 4 SDK + MCP + Docker
→

为什么企业合规不走 LLM, 走纯函数规则引擎

draft · 3,200 字 · 2026 Q3 (打磨中)
→

Webhook 重试策略: 为什么不是越多越好

draft · 2,800 字 · 2026 Q3
→

多 PM2 进程间共享状态, 为什么我们不接 Redis

draft · 4,500 字 · 2026 Q4 (排期中)
→

飞书多租户部署 — 12 个隐藏坑

idea · TBD
→

我会写什么

不一定都写, 看灵感. 但这是会出现的方向.

Agent 工程与架构

多 Agent 状态机 / 规则引擎设计 / 跨进程会话 / 凭证生命周期 / Webhook 重试 / 审计 trace ID 模式。

🤝

LLM 与传统代码的边界

什么场景适合 LLM、什么场景必须走代码、什么场景两个都要。带生产案例, 不空谈。

生产事故复盘

具体 trace log、为什么 fix、不同设计取舍。一篇一篇写, 不整文集, 不拖更。

🐛

Debug 日记

一些奇怪的 bug, 不一定能复现, 但搜到能笑出来.

Agent 工程踩坑周报

订阅, 我每发一篇工程复盘就推一次。频率低于每周一封, 不会打扰. 你随时能退。

// 你邮箱只用来推文章, 不会卖给第三方