第 11 天已经把每次供应商调用接进成本账本，并用原子预留守住任务和租户预算。预算通过后，请求仍可能被供应商限流、被本系统并发限制挡住，或遇到临时过载。把所有失败都当成“再试一次”，会让重试流量放大故障。
今天给模型网关加一层可解释的准入与恢复策略：谁占用了哪一维额度，为什么等待或拒绝，何时允许重试，何时可以切模型。文中的网关接口和调度算法是工程设计；供应商错误码、用量口径与响应头以引用的官方文档为准。
阅读更多...AI 成本账本怎么做：请求、任务、租户三级计量与预算硬上限
第 9 天用“每成功任务成本”衡量路由，第 10 天拆开了 Prompt 缓存和应用缓存。接下来要回答一个更实际的问题：一个 Agent 任务包含规划、检索、模型调用、失败重试和工具执行，账单应该记在哪里？当两个任务同时启动，怎样保证它们不会一起穿透租户预算？
今天把模型供应商的原始用量接成调用尝试 → 任务 → 租户三级账本，并设计预算预检、预留和结算。本文的数据模型与控制流程是工程设计推导；各供应商的字段语义与 API 行为以文末官方文档为准。
阅读更多...Prompt 缓存与语义缓存怎么分：命中、失效和租户隔离
第 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**。它不是把所有厂商能力抹平，而是把业务真正依赖的契约固定下来，把供应商差异收进适配器。后续切换模型、做灰度、设置超时降级和统计成本，都应在这个边界上完成。
