彩虹马的博客

引言给大模型应用增加一个统一入口，看起来只需要代理几个接口。但当模型数量、Agent数量和调用成本上来以后，问题会逐渐变成：简单问题能不能用便宜的模型？复杂任务什么时候升级？同一个会话是否应该一直使用同一个模型？这些判断应该由业务、网关还是模型服务负责？ 围绕这些问题，对vLLM Semantic Router和Higress做了一次梳理。两者都有路由能力，但关注的层次不同：一个侧重理解请求并选择模型，一个侧重统一接入和流量治理。职责不先讲清楚，两个组件叠在一起，只会多出一套规则和一个排障入口。 先把三个问题拆开请求难不难、应该用哪个模型、最终请求发到哪个节点，是三个不同的问题。 层次 需要回答的问题 输出示例 请求判断 任务属于什么领域？推理要求高不高？上下文是否复杂？ 领域标签、复杂度信号、难度分数 模型决策 在成本、质量、约束和会话状态下选谁？ 某个模型或模型能力路径 流量执行 这个模型的哪个实例能接收请求？ 某个可用后端节点 比如“查询一个Java方法的用法”和“分析一个跨服务事务的一致性方案”，都可能归到编程领域，但适合的模型不一定相同。反过来，同一个 ...

引言智能体返回了 HTTP 200，工具也没有报错，但用户仍然说“答案不对”。另一类情况是回答最终正确，用户却等待了很久。这些问题说明：链路执行成功、任务完成、答案正确和响应及时，是不同的判断维度。 Langfuse 的价值在于把请求过程、评价信号和回归实验关联起来，让排查从猜测变成有证据的分析。本文围绕 badcase 的发现、定位与验证展开，重点区分运行异常、效果问题和性能问题，建立可持续积累的工程闭环。 先定义什么是 BadcaseBadcase 指未达到明确预期的案例。预期可以是业务正确性、任务完成条件，也可以是延迟或资源消耗目标。没有事先定义的标准，仅凭“这个回答看起来一般”，难以形成稳定的改进依据。 问题类型 典型现象 后续工作 验证重点 运行异常 工具报错、模型请求失败、执行异常终止 故障排查与修复 错误率、恢复能力、任务是否完成 效果问题 链路正常，但答案错误、缺乏依据、答非所问 效果评测 正确性、相关性、依据充分性、任务成功率 性能问题 首段有效内容出现晚、总耗时高、循环过多 性能评测 首答延迟、端到端延迟、吞吐与成本 这三类可以同时存在。例如 ...

引言给智能体增加记忆，常见的第一步是把历史消息存进 Redis，再接入一个长期记忆服务。但真正进入业务场景后，问题很快会变成：每轮对话都要读取长期记忆吗？每次问答都要写 Mem0 吗？用户修改偏好后，Redis 中的旧画像什么时候失效？ 这些问题不能靠“短期放 Redis，长期放 Mem0”一句话解决。需要先区分记忆的作用域、数据的权威来源，以及读取、写入和上下文组装各自的职责。本文围绕这些边界展开，讨论一种适用于 AgentScope 等智能体运行时的设计思路。 先区分记忆、上下文和业务事实记忆是可保存和检索的信息，上下文是本次模型调用实际接收的信息。 数据已经存储，不代表模型会自动知道它；只有通过检索、筛选和组装进入当前请求，才会影响这次推理。 短期和长期主要描述信息的使用范围，不是数据库产品分类。Redis 可以承载会话状态，也可以承担画像缓存；关系数据库可以保存会话检查点，长期记忆也不必全部放进向量数据库。 信息类别 主要作用 示例 读取与更新方式 短期记忆 保持当前会话或任务连续性 当前目标、最近消息、已确认约束、工具结果摘要 按会话隔离，随任务推进更新 长期 ...

引言大模型应用从“回答问题”走向“完成任务”后，需要查询业务数据、调用内部 API、检索知识库或执行操作。若每个 Agent 都单独适配一种后端，连接方式、工具描述、参数格式和权限控制很快会变得重复而难以维护。 Model Context Protocol（MCP）为模型应用与外部能力之间提供一套通用协议。AgentScope 则在 Agent 运行时中管理工具、MCP 客户端和工具组。理解两者的边界，才能回答工具如何发现、如何暴露给模型、同类工具如何区分，以及升级如何控制风险。本文按 MCP 基础、Tool 设计和 AgentScope 接入逐步展开。 MCP 是什么MCP 是连接 AI 应用与外部数据源、工具服务的一种开放协议。它约定 Client 与 Server 如何初始化、协商能力、交换请求和返回结果，让应用可以用相对一致的方式连接不同能力提供方。MCP 本身不是大模型，也不负责替业务系统实现权限、事务或模型决策。 一个常见部署由三类角色组成： 角色 职责 Host 承载 Agent 和用户交互的应用，例如 IDE、桌面助手或业务 Agent 服务 Clien ...

引言在 macOS 上运行 Docker，常见选择是安装 Docker Desktop。对于主要通过终端管理容器的开发者，也可以使用 Docker CLI 配合 Colima，按需启动容器环境。 两种方式都可以服务本地开发，但提供的使用体验不同。Docker Desktop 集成了图形界面和多项管理能力；Colima 更适合希望直接控制虚拟机生命周期、通过命令行完成容器操作的场景。选择应围绕实际工作流，而不是简单认定某一种工具一定更快或更省资源。 先分清 Docker CLI、Engine 和 Colima安装完成后，终端能够执行 docker --version，只能说明 Docker 客户端可用，不能证明容器引擎已经运行。 组件 主要职责 所在位置 Docker CLI 解析 docker 命令，向目标 Engine 发送请求 macOS Docker Compose 读取 Compose 配置，通过 Engine 管理一组服务 macOS 上的 CLI 插件 Colima 创建、配置和启停容器开发环境 macOS Lima 为 Colima 提供 Linu ...

引言在 Spring Boot 项目里，Controller、Service、Mapper 是熟悉的组合。随着业务规则变多，Service 可能同时承担流程编排、状态校验、数据转换和消息发布等职责，修改一个用例也会牵动多个功能。此时常见的问题是：要不要从 MVC 改成 DDD？@Transactional 应该放在哪层？ 这几个概念解决的不是同一类问题：MVC组织请求入口，DDD帮助团队理解和表达业务，COLA则把面向对象、分层和工程结构落实为一种应用架构实践。理解分层不需要先套入某个业务用例，先看每层拥有什么职责、依赖朝向哪里即可。 MVC 与 DDD 关注点不同MVC用于组织表现层的输入、模型和输出。在 Spring Boot Web 应用中，Spring MVC负责处理HTTP请求、参数绑定和响应；Controller把请求交给应用层，是一种常见实现方式。 DDD（Domain-Driven Design，领域驱动设计）是一套围绕业务领域进行分析和建模的方法。它帮助团队统一业务语言、识别模型边界，并把重要规则放在明确的领域模型中。DDD不是一个Web框架，也不要求项目采用某种固定 ...

引言前面文章中介绍了很多架构相关理论，接下来说一说怎样才能画出一幅好看、好懂、好用的架构图。俗话说“一图胜千言”，一张好的结构图是不需要过多解释的，他应该是自描述的，并且要具备一致性、健壮性和足够的准确性，能够和代码相呼应。 架构图分类 产品/业务架构使用一套方法论/逻辑对产品（项目）所涉及到的业务进行边界划分，需要考虑各个模块的分层和边界。主要包括业务规划、业务模块和流程以及问题域的列表等。 模板可参考我的ProcessOn文件：产品蓝图、产品架构图 应用架构对整个系统实现的总体上的架构，需要指出系统的层次、系统各个层次的应用服务、组成关系、依赖关系。 体现了架构是分层的，不同层次有不同的规则与关联。 类似Java开发里面的三层架构，数据访问层、业务逻辑层、展现层。或者类似领域模型中的领域服务层、应用层、界面接口层分层方法。 模板可参考我的ProcessOn文件：应用架构图 存储/数据架构是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景 ，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。 技术架构离程序员最近的架构设计，突出技 ...

引言在众多分布式ID中，雪花算法是比较简单且常用的算法，分布式ID一般具有的特性有： 唯一性：生成的ID全局唯一，在特定范围内冲突极小。 有序性：生成的ID全局或按规则有序，便于数据库插入及排序。 可用性：可保证高并发下的可用性，确保任何时候都能正确的生成ID。 自主性：分布式情况下不依赖中心认证即可自行生成ID。 安全性：不暴露系统和业务的信息，如：订单数、用户数…. 常见的分布式ID生成方式比较 比较点 SnowFlake Leaf UidGenerator Redis 依赖数据库 否 是 可选 是 支持分布式 是 是 是 是 可预测 - - - - 依赖性 毫秒级时间戳 + 标识 位 + 序列号 时间戳 + node + pid + 序列号 秒级时间戳 + workId + 序列 Redis单线程自增 维护中 多个变种 是 否 - 雪花算法SnowFlake是Twitter开源的分布式ID生成算法，生成的一个64bit的long类型数值，组成部分使用了时间戳，保证了粗略自增。 优缺点优点 高性能高可用：完全在内存中生成，不依赖数据库。 高吞吐：每 ...