天风的博客

文章摘要：Google Cloud提出高吞吐生成式AI流水线架构，强调在高流量系统中应避免将所有事件都交给Agent处理。文章指出常见误区是将所有数据直接输入模型，导致成本、延迟和限流问题。作者建议采用分层过滤机制：先通过基础校验和规则引擎过滤大部分事件，仅将需要复杂推理的少量事件（约5%）送入Agent处理。文中还提供了基于Spring Boot+Kafka的简化实现方案，强调预处理层应保持轻量高效，并给出关键性能指标（如关键事件召回率≥99.5%、Agent流量减少≥80%）。最后提醒注意事件去重和元数

Google Cloud 和 Box 合作推出多模态企业 RAG 方案，强调应保留文档的原始多模态特性（如表格结构、图表关系），而非简单转为纯文本。该方案支持整页或区域级检索，能更好处理财务表格等复杂内容，同时提出了分层索引、混合检索、跨模态对账等实用落地方法。建议企业采用渐进式迁移策略，针对不同文档类型选择最优索引方式，并建立专门的多模态评测体系，重点关注数字准确性、引用位置和权限控制等关键问题。

Spring AI 2.0已经提供Redis语义缓存能力，可以通过`SemanticCacheAdvisor`在调用大模型前查找相似问题，并支持显式TTL、上下文哈希和同步/流式调用。但企业RAG不能把一个默认Advisor直接挂到所有`ChatClient`上就结束。

多Agent系统的核心难题不是创建多个`ChatClient`，而是让Supervisor在有限Token、成本、工具次数、并发和Deadline下，选择真正必要的Sub-Agent，并确保它们只能读取被授权的上下文、使用被允许的工具、提交版本一致的结果。

AI应用发布不能只依赖单元测试和接口可用性。一次模型、Prompt、RAG、Tool、Graph或Policy变更，可能在HTTP状态仍为200的情况下让任务成功率下降、重复工具调用增加、成本暴涨、长尾语言失效，甚至出现未经审批的真实副作用。

当Agent开始执行代码、操作浏览器、下载文件和提交表单后，业务系统不能再把这些能力当成普通工具函数。代码与浏览器运行时拥有文件、网络、计算资源和用户会话，一旦权限、租户、生命周期或副作用边界处理错误，就可能造成数据泄露、资源滥用、账户锁定和重复业务操作。

Spring AI的模块化RAG架构允许在检索完成后使用`DocumentPostProcessor`对文档进行Rerank、去重、噪声过滤和内容压缩。但在企业系统中，仅实现一个“把长文本摘要成短文本”的PostProcessor远远不够。上下文压缩必须同时解决Token预算、数字与否定条件保真、父子Chunk依赖、原文Source Span、Evidence ID冻结、Claim引用、缓存一致性和权限复核。

多Agent系统常见的故障并不是“某个Agent不会回答”，而是多个Agent拿到的上下文并不一致：研究Agent已经更新了供应商报价，财务Agent仍基于旧价格计算；Supervisor已经切换到Plan V4，执行Agent却继续完成V3中的步骤；用户在主会话中纠正了客户名称，子Agent仍使用创建时复制的旧消息。

企业RAG中的查询增强不能只是调用一个`RewriteQueryTransformer`。真实请求可能包含多轮指代、产品编号、版本号、日期范围、否定条件和租户权限；不同Query又分别适合原始检索、普通改写、Multi-Query、HyDE或问题分解。如果所有请求统一生成多个Query，不仅成本和延迟失控，还可能因为实体被改写、子问题漏掉权限条件或候选集合膨胀而降低Precision。

多租户RAG系统最严重的问题不是回答不准确，而是把其他租户的合同、制度、客户资料或内部文档召回给当前用户。很多项目在代码中已经写了`tenantId`过滤，日志里也能看到类似`tenant_id == 'T001'`的表达式，却仍然出现跨租户召回。

AI报告生成、代码仓库分析、批量知识入库、视频处理、多Agent研究和跨系统审批等任务，可能持续几十秒、数分钟甚至数小时。面对这些任务，团队通常在三种架构之间选择：继续使用同步HTTP接口、把任务投递到Kafka/RabbitMQ等消息队列，或者引入Temporal、Camunda等工作流引擎。

Spring AI的`ChatClient.call().entity()`可以把模型输出直接转换为Java对象，但生产项目经常遇到JSON前后带解释文字、被Markdown代码块包裹、必填字段缺失、枚举值不匹配、日期格式错误或Provider不支持完整JSON Schema等问题。默认结构化输出本质上仍可能是“Prompt约束＋文本解析”，并不天然保证100%成功。本文从目标类型设计、原始响应留存、Provider原生结构化输出、Schema校验与自修复、流式限制和错误分级六个方面给出完整排查方案。

企业接入多个大模型后，若每个业务系统自行处理Moderation、敏感信息脱敏、Prompt Injection、工具权限和日志审计，安全策略很快会失控。本文使用Spring Boot设计一个统一AI安全网关，通过标准请求对象串联身份校验、输入长度限制、PII检测、内容审核、Prompt Injection检测、模型代理、输出DLP和审计日志，并提供可扩展接口与核心代码骨架。

Spring AI 2.0已经可以通过Micrometer输出模型调用耗时与Token指标，但企业要真正控制成本，还需要把模型价格、业务场景、租户、预算、重试、Tool Calling和降级事件统一起来。本文实现一个轻量级AI成本与稳定性监控服务：从ChatResponse读取Usage，计算单次费用，写入业务成本表，同时用Micrometer记录低基数指标，并提供租户月预算、场景成本、429、熔断和降级看板所需的数据模型与PromQL。

企业接入多个MCP Server后，如果让每个Agent直接连接订单、仓储、客户、知识库和文件工具，会快速出现认证分散、工具重名、权限不一致、审计缺失和服务端地址泄露等问题。本文使用Spring Boot设计一个MCP工具网关：上游连接多个MCP Server，下游向Agent提供统一工具目录，并在调用前执行租户校验、工具白名单、风险审批、参数脱敏、超时和审计。文章给出核心数据模型、路由代码和生产配置思路。

直接把订单、退款、邮件、文件删除等业务方法暴露给大模型，会把模型的不确定性带入真实业务系统。更稳妥的做法是建立独立工具执行网关：模型只能提出工具名称和参数，网关负责身份校验、工具白名单、JSON Schema验证、风险分级、人工确认、幂等执行、结果脱敏和审计。本文使用Spring Boot实现一个可运行的轻量级工具网关，并给出ToolDefinition、PolicyEngine、Approval、Idempotency和Audit的核心代码。

Spring AI内置Chat Memory适合维护模型上下文，但企业系统还需要完整聊天记录、会话所有权、消息状态、审计日志和删除策略。本文使用Spring Boot、PostgreSQL与Spring AI 2.0设计一个双层存储方案：`ChatMemoryRepository`负责模型短期上下文，业务表负责完整Chat History；同时实现会话创建、所有权校验、消息写入、Memory调用和清空流程。

Spring AI 2.0升级后，使用`MessageChatMemoryAdvisor`或`VectorStoreChatMemoryAdvisor`的项目可能直接抛出`conversationId`不能为空、缺少`ChatMemory.CONVERSATION_ID`或历史对话突然失效。原因是新版本要求每次经过内置Memory Advisor的调用都显式提供会话ID，旧版默认会话ID和Builder上的`.conversationId()`方式已经不再适用。本文给出正确传参、多租户会话ID设计、流式接口

企业同时接入DeepSeek、OpenAI、Qwen或本地模型后，如果每个业务系统直接对接Provider，很快会出现流式协议不一致、错误码分散、取消无效、Token统计缺失和模型切换困难。本文实现一个轻量级Spring Boot AI流式网关，统一请求协议、SSE事件、模型路由、任务状态、取消接口、日志审计与Provider适配，并说明如何避免网关成为新的单点瓶颈。

本文实现一个面向企业知识库的增量索引服务：通过文档Checksum和Chunk Hash识别变化，只对新增或修改片段生成Embedding；使用稳定Point ID写入Qdrant；通过版本状态实现新旧索引原子切换；失败任务可重试，删除操作可幂等执行。示例使用Spring Boot、Spring AI和Qdrant，重点展示工程结构、数据模型、任务状态和核心代码。

单一Dense向量检索擅长语义理解，却容易漏掉产品型号、合同编号和专业缩写；纯关键词检索能够精确命中术语，却难以理解自然语言。本文使用Spring Boot、Spring AI和Qdrant设计一个可复用的企业混合检索服务，完成Dense与Sparse双路召回、租户权限过滤、RRF融合、去重、可观测日志和统一响应结构，并给出后续接入Cross-Encoder重排的扩展点。

Spring AI提供DocumentReader、DocumentTransformer和VectorStore等ETL能力，但复杂PDF的版面、表格和OCR往往需要更专业的解析工具。Docling可以将PDF解析成包含页面、标题、段落、表格和图片信息的结构化文档。本文通过“Python Docling解析服务＋Spring Boot入库服务”的方式，实现PDF转换、表格导出、统一Chunk模型、质量校验和Spring AI VectorStore写入。

一套从零开始使用沉浸式翻译插件实现外文网页、PDF、论文、视频字幕、EPUB电子书、图片和会议内容双语阅读的完整教程，覆盖安装、设置、翻译引擎选择、阅读流程、场景评分、隐私边界和常见错误。

从浏览器侧边栏、网页总结、PDF/YouTube阅读、写作改写、多模型接入、知识库沉淀、价格和隐私风险等角度，系统比较 Monica 与 Sider 两款AI浏览器插件。

一个轻量 CLI 工具：git add 后运行 aicommit，AI 自动读 diff、生成规范的 Conventional Commit message。支持一键提交和小名配置。

用 FastAPI 搭建 AI API 网关：多模型路由、IP 限流、自动降级到备选模型、成本统计，150 行代码搞定。

将 AI 代码审查嵌入 GitHub Actions / GitLab CI：每次 PR 自动获取 diff、AI 分析安全/性能/质量问题、评论在 PR 上。附 pre-commit hook。

开发一个 README 自动生成工具：扫描项目代码结构（语言、依赖、测试、CI）、提取 Git 信息、AI 生成结构化 README。

扫描 Markdown 文件夹，AI 生成导航和索引页，一键输出带代码高亮的静态 HTML 网站。几十行 Python 代码实现。

最后做一个 Agent 工作流引擎：定义多个 Agent 角色、串联执行、上下文传递。内置研究和代码审查两个预定义工作流。系列完结篇。

用 FastAPI + aiohttp + SSE 搭建 AI 聚合搜索页面：同时查多个 AI 搜索、流式输出结果、对比展示。附完整可运行代码。

用 Streamlit + Pandas + LLM 搭建 AI 数据看板：上传 Excel/CSV，AI 自动分析数据、生成图表和洞察、支持对话式问答。

从零开发 AI 周报生成器：用 git log 读提交、统计分析、调用 LLM 生成结构化 Markdown 周报。包含项目概况、主要工作、问题修复等章节。

封装一个可复用的 AI 聊天框架：多模型切换、流式输出、对话管理、一键部署 FastAPI 服务。支持 DeepSeek/豆包/OpenAI。

从零开发 AI 代码审查 CLI：读取 Git diff、调用 LLM 分析安全漏洞/性能问题/代码质量、支持 staged 审查和历史提交审查、可配 Git Hook。

从零开发 Chrome 划词翻译插件：Manifest V3、content script 注入、LLM API 调用、浮动气泡翻译。选中英文自动显示中文翻译。

从零开发命令行 AI 翻译工具：Python + Click CLI + LLM API，支持单句翻译、文件翻译、交互模式、批量翻译，翻译十万字成本不到 1 元。

从零开发本地 RAG 知识库：文档索引、文本切分、BGE 向量化、本地检索、流式 LLM 回答。支持 PDF/MD/TXT，全本地运行，数据不出本机。

从零开发 VS Code AI 插件：右键菜单调用 LLM 解释/优化代码、自动生成单元测试，WebView 展示结果。附完整 extension.js 代码和打包安装流程。