第 9 天讨论模型路由时，缓存会直接影响模型调用的延迟和账单。但“命中缓存”可能指完全不同的事：供应商复用相同 Prompt 前缀的计算、应用复用上次检索列表，或者把旧答案直接返回给用户。三者的收益、风险和失效方式不能混在一起。
今天的目标是给缓存划清责任边界，并做一套可回放的本地实验：缓存每次命中都能说明“复用了什么、为何仍可用、节省了多少、是否跨越了权限边界”。
阅读更多...模型路由怎么落地：能力门槛、缓存命中与每成功任务成本
前面已经有统一 ModelClient、Token 预算和 Prompt 回归集。第 8 天又给检索结果加上了版本、权限和评测。现在要回答一个更像平台工程的问题：同一个接口后面接了多个模型，请求进来时到底选谁？
本篇用一个客服任务贯穿路由、缓存和成本账本。目标是把“选更便宜的模型”变成可审计的路由决策：先判断能力和权限是否满足，再比较质量、延迟和任务成本；出故障时明确重试、降级或失败。文中的价格与运行结果均是设计示例，不代表真实供应商报价或已完成的线上实验。
阅读更多...Embedding 不只是相似度：向量检索的输入、召回与评测基础
第 7 天把模型调用、任务状态、预算和评测接成了闭环。今天进入第 1 月的第二段：Embedding、模型路由、缓存和成本统计。先把最容易被一句“算余弦相似度”带过的部分讲清楚：Embedding 是检索系统的输入契约，向量库只是执行近邻搜索的基础设施，最终是否答对要由证据和评测证明。
本文只做向量检索的基础，不把它冒充完整 RAG 项目。第 3 月会继续补文档版本、权限、引用、SQL 和多模态数据；今天先交付一条可以在本地重放和定位问题的检索链路。
阅读更多...AI 全栈开发首周验收：把 Runtime、ModelClient、预算和评测接成闭环
前六篇分别讲了架构、Agent Runtime、ModelClient、Token 预算、Prompt 回归和上下文压缩。今天是第 7 篇，按系列约定做第一次周复盘与小测。
本篇提供一套可执行的验收标准：用本地固定响应和模拟工具串起最小闭环，给出故障夹具、八道自测题及答案。系列文章里有接口、伪代码和实验模板；是否真正完成代码、测试或真实模型降本，要以自己的提交物和运行记录证明，不能把阅读文章算作项目验收。
阅读更多...上下文压缩到底省了什么：Token 计量、事实保留与任务成本实验
Day 4 的预算设计给出了 ContextBuilder，Day 5 的 Golden Set给出了回归门槛。今天要把两者接起来，回答一个更具体的问题：压缩历史后，整项任务是否真的更便宜，而且没有丢掉决定结果的事实？
只看“输入 Token 减少了 40%”很容易得出错误结论。摘要本身要调用模型；改写早期上下文可能降低 Prompt Cache 命中；漏掉一次审批状态会引发重试或人工接管。最终应该比较的是同一批任务的成功率、总费用和延迟，而不是单次请求长度。
本文给出实验设计、计量口径、可直接照着实现的数据结构和报告模板。没有实际模型密钥和固定评测环境时，结果栏保持“待测”，不把示例数字包装成收益。
阅读更多...Prompt 改一行如何安全上线：Golden Set、回归门槛与灰度
昨天为模型调用建立了 Token 账本和 ContextBuilder。它们有了版本和预算，接下来要回答上线前最关键的问题：新 Prompt 比旧版好在哪里，又把哪些原来正确的任务改坏了？
在普通 Java 服务里，接口字段变更有单元测试和契约测试；Prompt 改一行却可能让模型换工具、漏掉引用、把“先审批”理解成“直接执行”。只挑几道顺手的问题人工试聊，很难发现回归。今天把 Prompt 变更做成一次可复现的评测实验，再决定是否灰度发布。
阅读更多...Token 与上下文预算怎么做：从 Prompt 版本、压缩到成本可控
昨天把模型调用收敛成了 ModelClient。今天继续解决一个很容易被 Demo 掩盖的问题：Agent 为什么越跑越慢、越跑越贵，而且还可能答得更差？
原因通常不是某一个模型突然变笨，而是每一轮都把系统指令、工具定义、历史消息、检索结果和上一次工具输出重新送进上下文。输入 Token 增长会带来更高的首 token 延迟和费用，也会让真正有用的信息在注意力里被稀释。上下文窗口变大只能延后问题，不能代替预算设计。
今天把 Token 当成一种需要分配、计量和回收的资源，建立一套适合 Java/后端服务的上下文预算方案：Prompt 有版本，消息有优先级，压缩有可回查指针，缓存有命中指标，租户有硬上限。
阅读更多...统一 ModelClient 怎么设计：消息、结构化输出、流式与重试的边界
昨天我们把 Agent Runtime 的任务、步骤、事件和状态迁移固定下来。Runtime 要继续向前走，就必须有一个稳定的模型调用边界。否则业务代码会到处出现 if (provider == ...)：某家模型用 messages，另一家模型用 input；某家返回 choices，另一家返回事件流；结构化输出、工具调用、计费字段和错误码也各不相同。
今天实现第一层模型工程：**统一 ModelClient**。它不是把所有厂商能力抹平，而是把业务真正依赖的契约固定下来，把供应商差异收进适配器。后续切换模型、做灰度、设置超时降级和统计成本，都应在这个边界上完成。
Agent Runtime 怎么设计：状态机、可恢复执行与幂等
昨天先把企业级 Agent 的目标拆成了任务、步骤、证据和 trace。今天继续往下实现运行时。很多 Agent Demo 的主循环只有几行：调用模型、执行工具、把结果放回上下文，直到模型说任务完成。
这段循环可以证明模型会调用工具，却不能证明系统能处理一个运行二十分钟的真实任务。服务重启怎么办，工具超时但实际已经成功怎么办，用户取消后迟到的结果写到哪里，两个执行器同时推进同一个任务怎么办？这些问题都属于 Agent Runtime，而不是 Prompt 的细节。
阅读更多...企业级 Agent 全栈开发路线图：从模型调用到可运营平台的 180 天
很多人学习大模型时，会在模型原理、Prompt、RAG、Agent 框架和各种新工具之间来回切换。每个概念都看过一些，真正面对一个企业需求时，却很难回答三个问题：任务如何可靠地完成，系统如何安全地接入业务，效果和成本如何长期运营。
这组文章从一个可以持续运行的项目出发，用 180 天把模型调用、Agent Runtime、知识库、工具权限、评测观测、前后端和部署串成一条路线。目标不是把所有框架都学一遍，而是能独立完成一个有状态、可恢复、可评测、可审计的 AI 应用，并能在面试中讲清楚取舍。
阅读更多...
