Day 4 的预算设计给出了 ContextBuilder，Day 5 的 Golden Set给出了回归门槛。今天要把两者接起来，回答一个更具体的问题：压缩历史后，整项任务是否真的更便宜，而且没有丢掉决定结果的事实？
只看“输入 Token 减少了 40%”很容易得出错误结论。摘要本身要调用模型；改写早期上下文可能降低 Prompt Cache 命中；漏掉一次审批状态会引发重试或人工接管。最终应该比较的是同一批任务的成功率、总费用和延迟，而不是单次请求长度。
本文给出实验设计、计量口径、可直接照着实现的数据结构和报告模板。没有实际模型密钥和固定评测环境时，结果栏保持“待测”，不把示例数字包装成收益。
阅读更多...昨天为模型调用建立了 Token 账本和 ContextBuilder。它们有了版本和预算，接下来要回答上线前最关键的问题：新 Prompt 比旧版好在哪里，又把哪些原来正确的任务改坏了？
在普通 Java 服务里，接口字段变更有单元测试和契约测试；Prompt 改一行却可能让模型换工具、漏掉引用、把“先审批”理解成“直接执行”。只挑几道顺手的问题人工试聊，很难发现回归。今天把 Prompt 变更做成一次可复现的评测实验，再决定是否灰度发布。
阅读更多...昨天把模型调用收敛成了 ModelClient。今天继续解决一个很容易被 Demo 掩盖的问题：Agent 为什么越跑越慢、越跑越贵，而且还可能答得更差？
原因通常不是某一个模型突然变笨，而是每一轮都把系统指令、工具定义、历史消息、检索结果和上一次工具输出重新送进上下文。输入 Token 增长会带来更高的首 token 延迟和费用，也会让真正有用的信息在注意力里被稀释。上下文窗口变大只能延后问题，不能代替预算设计。
今天把 Token 当成一种需要分配、计量和回收的资源，建立一套适合 Java/后端服务的上下文预算方案：Prompt 有版本，消息有优先级，压缩有可回查指针，缓存有命中指标，租户有硬上限。
阅读更多...昨天我们把 Agent Runtime 的任务、步骤、事件和状态迁移固定下来。Runtime 要继续向前走，就必须有一个稳定的模型调用边界。否则业务代码会到处出现 if (provider == ...)：某家模型用 messages，另一家模型用 input；某家返回 choices，另一家返回事件流；结构化输出、工具调用、计费字段和错误码也各不相同。
今天实现第一层模型工程：**统一 ModelClient**。它不是把所有厂商能力抹平，而是把业务真正依赖的契约固定下来，把供应商差异收进适配器。后续切换模型、做灰度、设置超时降级和统计成本，都应在这个边界上完成。
昨天先把企业级 Agent 的目标拆成了任务、步骤、证据和 trace。今天继续往下实现运行时。很多 Agent Demo 的主循环只有几行：调用模型、执行工具、把结果放回上下文，直到模型说任务完成。
这段循环可以证明模型会调用工具，却不能证明系统能处理一个运行二十分钟的真实任务。服务重启怎么办，工具超时但实际已经成功怎么办，用户取消后迟到的结果写到哪里，两个执行器同时推进同一个任务怎么办？这些问题都属于 Agent Runtime，而不是 Prompt 的细节。
阅读更多...很多人学习大模型时，会在模型原理、Prompt、RAG、Agent 框架和各种新工具之间来回切换。每个概念都看过一些，真正面对一个企业需求时，却很难回答三个问题：任务如何可靠地完成，系统如何安全地接入业务，效果和成本如何长期运营。
这组文章从一个可以持续运行的项目出发，用 180 天把模型调用、Agent Runtime、知识库、工具权限、评测观测、前后端和部署串成一条路线。目标不是把所有框架都学一遍，而是能独立完成一个有状态、可恢复、可评测、可审计的 AI 应用，并能在面试中讲清楚取舍。
阅读更多...Agent 的效果很难用一个分数概括。它可能答对了最终问题，却越权读取了材料；也可能工具调用成功，但任务没有真正完成；还可能离线样本表现稳定，线上遇到长上下文和并发后延迟失控。
上线前评测的目标不是证明 Agent 永远正确，而是知道它在哪些条件下可靠、在哪些条件下必须拒答或交给人，并且能在结果变差时快速定位原因。
阅读更多...Agent 一旦可以查询订单、修改配置或发送消息，工具调用就不再是普通的函数调用，而是一次由自然语言触发的业务操作。模型可能误解用户意图，外部材料可能包含恶意指令，工具返回的数据也可能被拼接到下一轮提示词中。
因此，安全边界不能只写在系统提示词里。模型可以提出动作，但真正决定“能不能做、对什么对象做、做完是否生效”的，应该是独立于模型的策略和执行层。
阅读更多...企业做 AI 平台，最容易出现的误区是先搭一个“模型门户”，把模型列表、密钥和聊天页面放在一起，然后等待业务自己找到用法。真正进入生产后，团队需要解决的却是另一组问题：数据能不能被安全使用，模型输出能不能被评测，Agent 能不能调用业务系统，成本和故障能不能定位。
平台的价值是把一次项目里反复出现的能力沉淀下来，让业务团队专注于任务和流程。平台边界应围绕可复用能力划分，而不是围绕某个模型或某个项目划分。
阅读更多...很多团队把 Agent 项目理解成“接一个大模型，再加一段提示词”。演示阶段确实可以这样做，但一旦任务涉及权限、业务系统和长期运行，问题就会迅速变成工程问题：模型什么时候可以决定下一步，工具失败后如何恢复，用户中途修改要求时怎样取消旧任务，哪些结果需要人工确认。
企业级 Agent 的核心不是让模型多说几句话，而是把一个业务目标变成可追踪、可恢复、可审计的任务闭环。模型负责处理不确定性，平台负责约束不确定性。
阅读更多...请我喝杯咖啡吧~
支付宝
微信
