AI 语音客服 demo 能跑,离敢上生产还隔着两道坎。一是延迟:用户对电话里的沉默极其敏感,超过一秒就觉得"卡了",得盯"首响应"而不是"总时长",靠流式和流水线把它压进一秒。二是可信度:LLM 会用完全自信的语气编造一个不存在的优惠、报错一个余额数字,在客服场景就是事故,得靠 RAG、工具调用、护栏这五道防线给它套缰绳。而且这两件事经常打架,工程上只有按场景权衡,没有免费的午餐。

FreeSWITCH + UniMRCP + LLM 的分工和架构有了,落到代码,XML dialplan 表达不了"调 HTTP、维护多轮上下文、按 LLM 结果分支"这种逻辑,得用 Lua。这里有一份能读懂的完整 voice_agent.lua 骨架——从接通、放欢迎语、开麦识别、调 LLM 网关、合成回复,到打断、超时、转人工、挂断的完整对话循环,关键处标清楚哪里要按你的环境改。顺带说清 mod_unimrcp 的 speak / play_and_detect_speech 怎么用,以及为什么 LLM 场景要用自由识别而不是固定语法。

MRCP 给通话加上了"听懂"和"会说"。再往下走一步:在 contact center 里,FreeSWITCH 管呼叫、UniMRCP 管 ASR/TTS,本来已经能做语音 IVR;但真正让它"活"起来的,是中间插进来的 LLM。传统 IVR 靠固定语法只能听懂预设的几句话,LLM 能听懂客户随口说的任何一句,还能带着上下文对答、调用工具查真实数据。三者怎么分工、一次对话在时序上怎么流转、延迟和打断这些工程难点怎么处理,连同一份能照着做的落地清单,都在这儿。

LLM API 已经从 prompt 字符串、messages 对话，走到由 typed items、事件流和工具循环组成的 Agent 接口。OpenAI-compatible 往往只能保证最简单的文本请求长得相似，不能保证工具调用、流式事件、状态、推理内容和错误语义一致。本文比较 Chat Completions、Responses API、Anthropic Messages 与 Gemini，给出选型框架、适配层边界和兼容性测试清单。

我手上就一个自建网关、一把 API key，可 Claude Code 要写进 settings.json 的 env，Codex 要写进 config.toml 加 auth.json，OpenCode 要在 opencode.json 里手搓一个 provider——同一件事写三遍，三种格式。cc-switch 把这三份配置收进一个 SQLite 当唯一数据源，托盘点一下就切。这篇讲清它是什么、为什么自建用户尤其需要它、两种接法怎么选，附上我本机三条真实链路（脱敏）和四个只有自建才会踩的坑：opencode.jsonc 会盖掉 cc-switch 的写入、网关的 /models 不是 OpenAI 形状所以自动拉模型没用、密钥两周过期后要改的地方变多了、以及 settings.json 里那个 PROXY_MANAGED 占位符是干什么的。最后是一页 cheatsheet。

自从用 OpenSpec 那套 spec-driven 流程做 AI 编程，proposal.md、design.md、tasks.md、spec.md 一层套一层，我一天读的 Markdown 比代码多。写这一端有 agent 帮忙，读这一端还是 cat 加 less。所以我给 markpad 又加了几刀：在任意目录敲一个命令，起一个本地 Web，左边编辑右边预览，Mermaid 和 PlantUML 直接出图，选中一段就能流式翻译，一键出摘要加思维导图。这是六月那篇介绍的续集，不讲功能清单，讲几个当时没写清的实现决定：为什么两种图表走两条完全不同的路、为什么翻译非流式不行、本地工具的安全线画在哪，以及我拿它打开自己上一篇博客时踩到的一个洞。1657 行 Python，53 个测试，可抄。

我在自己的 wiki 上写过一篇 git tips，改了 17 版，该记不住的还是记不住。于是写了 gitman：用自然语言说想干什么，它先给出一份 git 命令计划和一条从真实 diff 里长出来的 commit message，你点头它才执行。这篇不讲“AI 真神奇”，讲的是让 LLM 碰你的仓库时必须先立起来的几道护栏——argv 白名单、三级危险分类、commit message 只能来自 snapshot、默认不联网。全部代码 942 行，5 个 commit，可抄。

KV Cache 不是一个"顺手能省点钱"的技巧，而是一条硬约束：它规定了你的提示词必须怎么排版。前缀不稳，缓存全废；更糟的是，如果你开了缓存又让前缀每轮都变，按价目表算，账单会比压根不开缓存还高 25%。本文讲清 KV Cache 的原理、命中规则、省钱之外的收益、可落地的最佳实践和常见陷阱。

生产上的 AI Agent 大多不是死在模型不行，而是死在记忆管得烂：要么什么都记，Token 和存储一起爆炸；要么什么都记不住，用户说三遍它忘三遍。这篇讲清楚一套像人脑一样分层的记忆系统——工作记忆、情景记忆、语义记忆、程序记忆，以及写入、巩固、检索、遗忘的完整生命周期，最后给一套可落地的参考架构和 checklist。

Anthropic 那篇《Building Effective Agents》我隔一阵就翻一遍，每次读都有点新体会。这篇是我第 N 次重读后的笔记：先把 workflow 和 agent 掰扯清楚，再把五种 workflow 模式和真正的 agent 逐个过一遍，重点讲什么时候该用、什么时候别用，最后落到一张选型表和一份落地清单。核心就一句话——别一上来就上 agent，能用简单模式解决的，绝不加复杂度。

为什么 Claude Code、Codex 这些编码 Agent 感觉比“裸模型”聪明得多？秘密不在模型参数里，而在模型外面那层叫 Harness 的壳。这篇翻译并解读 Lilian Weng 2026 年 7 月的长文《Harness Engineering for Self-Improvement》：什么是 Harness、三大设计模式、优化路线图（上下文工程→工作流→自我改进→进化搜索→权重联合优化）、七大未来挑战，以及我作为一个后端老兵的解读。

与其一个个手搓专业 AI Agent，不如造一台"孵化器"——一个父 Agent，听你一句大白话，就快速孵化出贴身服务某类需求的子 Agent。这篇聊聊这台"AI Agent 制造工厂"的运转机制：父 Agent 怎么把自然语言编译成五份产品图纸（角色/工具/规矩/提示词/验收），照着标准模板批量生产，再让子 Agent 用 ReAct 边想边做。以日程安排专家作为流水线上的第一个样品。

传统 RAG 把文档切碎成 chunk 各自嵌入，遇到"多个实体互相牵连"的问题就抓瞎。GraphRAG 用知识图谱补上了关系，却贵得离谱、更新一次能烧掉几百万 token。这篇精读港大与北邮的 LightRAG 论文（arXiv:2410.05779），先把传统 RAG 的老毛病摊开，再拆 LightRAG 的图索引 + 双层检索 + 增量更新，最后落到一张选型对照表。

AI 最有意义的用途，不是替人更快地交作业，而是缩短“提问、猜想、实验、观察、解释、测试”的学习闭环。本文从认知心理学出发，用 Jupyter Notebook + LLM 演示如何把公式、算法和数据结构从纸面符号变成可以操纵、观察和验证的对象。

单个感知机只能画一条直线，连四条数据构成的 XOR 都解决不了。可正是这次失败，把人们引向隐藏层、非线性激活和反向传播。本文从 XOR 出发，讲清多层网络为什么能够学习新表示，再沿着这条思想谱系走到 Transformer 与 LLM。

Markdown 写起来很舒服，但读起来、预览起来、跨中英文翻译起来并不总是舒服。Markpad 是我做的一个本地 Markdown Web 工具，把文件索引、左右分栏编辑预览、主题、图表渲染、实时分享和 LLM 翻译放在一起，解决自己每天写文档时的一个小但扎人的痛点。

传统软件的攻击面是"代码里的洞"，LLM 应用多了一个要命的新洞——模型会"听话"地执行别人塞进来的指令。一个帮你总结网页的 Agent，可能因为网页里藏了一句"把用户的 key 发到我这里"就真的照做。这篇按 Prompt 层、Agent 层、数据层、运营层四层梳理 LLM 应用与 AI Agent 的安全要点，配上几个典型翻车实例、一份行动清单和一份上线检查清单。

我自己用 SQLite 写了一个传统 Wiki，链接靠手动维护。读了 llm_wiki 项目后，我没有推倒重来，而是决定吸收其精华，用 Python 写一个小工具来渐进增强。AI 是工人、咨询师、秘书，人才是知识库的主人。

Martin Fowler 的《Harness engineering for coding agent users》提醒我们，想让 coding agent 少添乱、多干活，光靠更大的模型还不够，还要把模型外面的规则、工具、反馈和验证系统搭起来。AI 工程化正在从 prompt 技巧，走向 harness engineering。

这两年"AI"几乎成了 LLM 的代名词，一聊 AI 就是 ChatGPT、Claude、提示词工程，仿佛 AI 就等于聊天机器人。作为一个在多个领域做过工程落地的老工程师，我想说：这个认知框架太窄了——AI 是一个庞大的技术生态，LLM 只是其中一个（虽然眼下最耀眼的）分支。