Agent 的效果很难用一个分数概括。它可能答对了最终问题，却越权读取了材料；也可能工具调用成功，但任务没有真正完成；还可能离线样本表现稳定，线上遇到长上下文和并发后延迟失控。

上线前评测的目标不是证明 Agent 永远正确，而是知道它在哪些条件下可靠、在哪些条件下必须拒答或交给人，并且能在结果变差时快速定位原因。

Agent 一旦可以查询订单、修改配置或发送消息，工具调用就不再是普通的函数调用，而是一次由自然语言触发的业务操作。模型可能误解用户意图，外部材料可能包含恶意指令，工具返回的数据也可能被拼接到下一轮提示词中。

因此，安全边界不能只写在系统提示词里。模型可以提出动作，但真正决定“能不能做、对什么对象做、做完是否生效”的，应该是独立于模型的策略和执行层。

企业做 AI 平台，最容易出现的误区是先搭一个“模型门户”，把模型列表、密钥和聊天页面放在一起，然后等待业务自己找到用法。真正进入生产后，团队需要解决的却是另一组问题：数据能不能被安全使用，模型输出能不能被评测，Agent 能不能调用业务系统，成本和故障能不能定位。

平台的价值是把一次项目里反复出现的能力沉淀下来，让业务团队专注于任务和流程。平台边界应围绕可复用能力划分，而不是围绕某个模型或某个项目划分。

很多团队把 Agent 项目理解成“接一个大模型，再加一段提示词”。演示阶段确实可以这样做，但一旦任务涉及权限、业务系统和长期运行，问题就会迅速变成工程问题：模型什么时候可以决定下一步，工具失败后如何恢复，用户中途修改要求时怎样取消旧任务，哪些结果需要人工确认。

企业级 Agent 的核心不是让模型多说几句话，而是把一个业务目标变成可追踪、可恢复、可审计的任务闭环。模型负责处理不确定性，平台负责约束不确定性。

旧博客的异步下单文章，把请求放进消息队列，再由消费者写订单。它很适合展示一个变化：用户请求不必一直等待完整的数据库操作。

这次再看代码，更值得继续讨论的是失败以后会发生什么。消息进了队列就一定有订单吗？库存已经更新，但订单插入失败怎么办？用户重复发一次请求，系统认得出来吗？

下面基于旧学习 demo 做一次代码阅读。它不是生产故障复盘，也没有新的压测结论。

翻回以前的 Java 笔记，会发现主题已经不少了：HashMap、ConcurrentHashMap、JVM、MySQL、Redis、Spring、MQ，还有项目设计。

这些知识点单独看都很重要。但如果只是把答案一条条背下来，遇到“讲讲你的项目”时，依然容易变成一串组件名称。

可以换一个复习角度：沿着一笔订单走一遍，看这些知识分别解决哪一段问题。

镜像打好了，容器启动了，健康检查也是绿色。打开用户入口，看到的却还是旧版本。

这不一定是代码没更新。可能新实例还没接流量，可能入口指向另一组服务，也可能应用加载的配置仍然来自旧文件。

服务内部的成功信号很重要，但它们需要与用户真正经过的路径连接起来。

给知识库换了检索策略，测试分数从 80 变成 90，可以上线了吗？

先别急。这个分数到底在衡量什么？搜到了目标文档，答案写得像参考答案，还是用户真的得到了可以使用的结论？

同样一个问题，可能文档找对了、答案却用错了版本；也可能答案正确，引用却点不开。把它们压成一个总分，最需要修复的地方反而不容易看见。

假设有人问：“我们正在用的这个版本，能不能处理扫描件？”

知识库搜到了三份材料：一份产品介绍、一份新版本说明，还有一份测试记录。模型读完以后回答：“支持，上传文件即可。”

听起来很顺。但再看一眼，产品介绍没有写版本，新版本说明说的是下个月准备发布的功能，测试记录只覆盖了一种文档。

问题出在哪里？材料确实找到了，可它们还不足以回答眼前这个问题。

缓存热点数据

在秒杀实际的业务中，一定有很多需要做缓存的场景，比如售卖的商品，包括名称、详情等。访问量很大的数据，可以算是“热点”数据了，尤其是一些读取量远大于写入量的数据，更应该被缓存，而不应该让请求打到数据库上。