彩虹马的博客

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

引言给智能体增加记忆，常见的第一步是把历史消息存进 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类型数值，组成部分使用了时间戳，保证了粗略自增。 优缺点优点 高性能高可用：完全在内存中生成，不依赖数据库。 高吞吐：每 ...

高可用三大核心原理CAP 分布式数据存储系统不可能同时满足一致性、可用性和分区容忍性。 一致性 Consistency 可用性 Availability 分区容忍性 Partion Tolerance BASE 核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 基本可用 Basically Available 软状态 Soft State 最终一致性 Eventually Consistency FLP 异步通信场景中，即使只允许一个节点失败，也没有任何确定性算法能够保证非失败进程达到一致性。 Safety Fault Tolerance Liveness FEMA具体含义 Failure：假设系统某些组件或者模块出现故障。 Mode： 故障发生的方式、可能性。 Effect ：故障的影响。 Analysis：分析系统的可能反应，以及如何改进。 评估维度 大纲 业务及灾备架构常用架构 同城双中心。 跨域紧邻双中心。 跨域远端双中心。 跨国数据中心。 异地多活架构模式业务定制型按照业务的优先级进 ...