OpenViking：统一 Agent 记忆与 RAG 的自进化上下文数据库
OpenViking 把 agent 的知识、记忆、技能组织成 viking:// 虚拟文件系统，配合 L0/L1/L2 三层加载和目录限定检索，让记忆可浏览可编辑。官方基准显示记忆准确率从 24–57% 提升到 80–83%，token 与延迟大幅下降。
模型挂了的兜底：降级路径与快速失败
存量系统接上大模型后，模型调用成了请求链路上的新单点。这篇讲这条外部依赖挂掉时怎么降级：超时与有限重试、限流退避、熔断冷却、分场景兜底与快速失败，并给出可运行的封装示例，最后说明什么场景才值得上全套。
QwenLM/qwen-code：住在终端里的开源 AI 编程智能体
这个仓库把 Gemini CLI 的终端外壳接上了四类模型协议，再用一层 ACP 把终端、IDE、Web 和 IM 都变成前端。这篇按 README 和仓库结构梳理它的分层方式、安装与无头用法、评测口径，以及哪些设计能直接搬走、哪些坑得自己填。
灰度发布：把新功能的开关按部门切开
上一章的权限链路做完，AI 功能仍然是一上线就全量。本篇接着讲怎么把开关切到部门粒度：开关表怎么建、部门判断放在请求入口的哪一步、关闭后怎么降级回旧入口，以及放量时看哪几个指标。
AIHOT 拆解：一个自己找热点、自己写日报的开源框架
AIHOT 把从信源到日报的整条链路开源了出来：六步流水线、同一标准打两次分、事件级热度算法，以及全部评分提示词与入选门槛。本文拆它的关键设计，也说清这套引擎现在的边界。
权限别绕开：复用已有权限体系的三道做法
语义层补好之后，旧库能查了，但谁能看什么还没解决。本篇给出存量系统接 AI 时复用现有权限体系的三道做法：AI 服务以服务账号运行并代传用户身份、在检索出口做行级过滤、把已有 RBAC 封装成模型可调用接口，并列出三个常见的越权路径。
open-webui：一个界面管住 Ollama 和 OpenAI 后端
open-webui 把本地 Ollama 和云端 OpenAI 兼容 API 统一到一个自托管界面里，加上 RBAC、RAG 和插件管线，是自建 AI 工作台的常用底座。这篇拆它的多后端抽象、权限和工具管线设计，以及能复用到其它 AI 应用的思路。
数据不搬家：在旧库上补一层语义
承接上一章选定的只读问答落地点，这一篇解决「模型读不懂老库字段」的问题。不迁移数据、不改表结构，只在旧库外面补一层语义：字段字典、枚举映射、注入 prompt，让模型按业务含义而不是字段名去理解数据，并说清这套做法能扛住什么、扛不住什么。
DeepSeek-Reasonix：一个 Go 重写的社区编码智能体
拆解 DeepSeek-Reasonix（Reasonix）这个社区编码智能体：模型可换、配置驱动、Go 重写、权限分级与 rewind 回退。附 reasonix.toml 配置骨架和上手命令，以及与 Claude Code 的定位差异。注意它是 esengine 社区项目，非 DeepSeek 官方。
存量系统接 AI，第一个落地点选只读需求
承接上一章摸清的数据、部署、测试底数，这一篇回答「老系统那么多地方，第一个 AI 落地点选哪」。结论是只读优先：从一张字段稳定、查询量大的表做只读问答，写回单独走受控通道，规避字段漂移的坑。
rea：让 Agent 读懂二进制的 MCP 工具
rea（Reverse Engineer Anything）是一个逆向工程的 MCP 工具，让 Agent 在没有源码的情况下检查二进制、JS/Electron、.NET 应用，返回带证据的结论。这篇讲它的工作方式、安装命令、CLI 用法，以及证据链和本地分析这两个可复用设计。
存量系统接 AI，先把数据与部署的底摸清
给运行多年的存量系统接入大模型，翻车点往往不在模型，而在没摸清的数据、部署、测试约束。这是「存量系统的 AI 改造」系列第 1 篇，讲接模型前要把哪几件事摸清，并给一段只读审计脚本，避免一上来就改老代码。
手搓生产级 AI Agent 系统（40）：Spring AI 配置排错与多模型选型
本篇承接第 39 篇的工程落地，聚焦 Spring AI 在 Spring Boot 项目中的配置细节、常见错误排查思路，以及多模型提供商接入时的选型对比与迁移注意事项，帮助读者把 Agent 系统从能跑推进到可运维。
拆 Spring AI 2.0 的 MCP 工具链：参数校验、权限与人工确认
Spring AI 2.0 把 MCP 工具接入简化成注解声明，但 MCP 本身不做鉴权，可靠性得在应用层自己补。本文用退款审批场景搭一条最小工具链，讲参数校验、权限确认、人工审批三道边界怎么落到代码里，以及什么场景值得上这套。
Vercel AI SDK 开源选型：多框架接入与许可证风险
基于 vercel/ai 官方 README 与仓库公开信息，梳理 AI SDK 的 TypeScript 定位、统一 Provider 接入方式、跨前端框架的 UI 集成路径，并结合 27.4k stars、5.4k forks 与 NOASSERTION 许可证状态，给出 Agent 与生成式 UI 场景下的开源选型评估要点。
拆了一下 DeepSeek Harness 的插件架构
DeepSeek 开源的 agent harness，没有可改的核心代码：模型适配器、工具注册表、会话日志、连主循环本身都是插件。这篇拆它的 profile 与 bundle 分层、启动时的层序，以及「模型能看到就必须记进日志」这条硬约束。
手搓生产级 AI Agent 系统（39）：Spring AI 工程落地指南
本文是《手搓生产级 AI Agent 系统》第39篇，承接上一篇 Spring AI 与 MCP 工具调用可靠性话题，从 Java 开发者视角梳理 Spring AI 从快速入门到生产环境的关键工程考量。基于公开教程与搜索资料摘要，讨论模型接入、提示工程、工具调用、RAG 与排错等核心环节，并给出集成配置、排错思路与生产准备的可执行建议。关键配置项与版本行为仍需以官方文档和实际依赖版本为准。
vercel/ai 开源选型考察：多框架与多 Provider 的边界
基于 vercel/ai 官方 README 与仓库公开信息，梳理 AI SDK 作为 TypeScript 工具库的定位、统一 Provider 架构、UI 集成方式与工程选型时需要核实的边界，区分官方事实与待验证的工程判断。
手搓生产级 AI Agent 系统（38）：Spring AI + MCP 工具调用可靠性
本文是系列第 38 篇，基于社区示例梳理 Spring AI + MCP 工具调用的可靠性设计。文章明确标注版本、依赖与注解 API 需以官方文档核验，并围绕参数校验、权限校验与人工确认三道防线，给出服务端校验、身份来源与幂等执行的工程方案，强调 MCP 不替代业务鉴权。
从 vercel/ai 元数据看 TypeScript AI 工具链选型边界
以 vercel/ai 的公开元数据与 README 为事实基础，拆解其 Provider 抽象、跨框架 UI 集成与 Agent 能力标签，给出 TypeScript 技术栈选择 AI 应用开发库时的判断框架，并标注仍需从源码与官方文档验证的边界。