彩虹马的博客

引言给大模型应用增加一个统一入口，看起来只需要代理几个接口。但当模型数量、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 ...

生成参数控制模型如何输出，上下文管理决定模型能够使用哪些信息。 前者影响随机性、长度和停止条件，后者影响证据完整性与任务连续性。优化时应同时关注回答质量、稳定性、延迟和总成本。 模型参数与输出控制生成参数是在推理时设置的解码配置，通常不会修改模型权重。它们能够改变输出行为，但不能补齐缺失的知识、事实或业务约束。 Temperature（温度）Temperature 通过调整候选 Token 的概率分布，控制采样随机性。 直观理解：保守派 vs 冒险家 温度设置 分布变化 通常表现 低于 1、但大于 0 高概率候选更占优势 输出差异较小 等于 1 保持温度缩放前的分布形状 按基准分布采样 高于 1 分布趋于平缓 更容易选择其他候选 低温度不等于高准确率，高温度也不会增加模型知识。 缺少正确证据时，低温度可能只是让错误答案更加稳定；提高温度则主要增加表达和方案的差异。 核心机制：概率的“锐化”与“拉平”模型先计算候选 Token 的分数，再通过温度缩放改变它们的相对概率。降低温度会扩大高分候选的优势，提高温度则会减弱这种差异。 Temperature=0 通常由服务实 ...

提示词要素决定“需要表达哪些内容”，消息角色决定“这些内容以什么身份进入模型、发生指令冲突时如何处理”。 两者属于不同维度。写下“你是一名架构师”，是在设定角色定位；通过 API 发送 role: "system"，是在指定消息角色。前者不会自动获得后者的指令权限。 提示词的核心要素提示词可以从任务指令、上下文、输入数据和输出要求四类基本内容组织，再按需要加入角色定位与约束。 这些是设计维度，不是固定协议。简单任务不需要填满所有要素，复杂任务则应明确区分职责，避免将背景、规则和待处理数据混在一起。 角色定位：定义职责与分析视角角色定位用于约束模型的工作职责、专业视角和表达方式。 它的主要作用是明确关注点。同一段代码可以从性能、可维护性或安全角度分析，角色定位帮助模型选择合适的检查范围。 123你是一名 Java 后端代码审查助手。重点检查事务边界、并发安全和异常处理。只报告能够依据代码说明的问题。 相比“你是一位拥有二十年经验的顶级专家”，明确职责和判断标准通常更有实际价值。 需要注意： 角色设定不会增加模型原本不具备的知识、工具或访问权限。 身份描述不能代替 ...

Reasoning Model、CoT、ToT 与 Agent Loop 分别处于模型能力、提示方法、搜索策略和执行机制四个层级。 它们可以组合使用，并不是四种互斥的技术方案。 例如，代码修复智能体可以使用推理模型分析问题，通过 Agent Loop 读取源码、修改代码、执行测试；存在多种候选修复路径时，再引入 ToT 搜索。 Reasoning Model：模型的推理能力定义与工作原理Reasoning Model 是经过专门训练或优化，能够通过额外推理计算处理复杂问题的模型。 这类模型通常结合推理过程学习、强化学习等技术，在生成答案前或任务执行过程中进行分析、规划和检查。具体训练路线与内部机制因模型而异，不能统一描述为某一种算法。 以使用推理 Token 的实现为例，模型会在最终答案之外消耗额外 Token，用于中间计算。这些内容不一定直接展示给用户。推理模型机制 需要区分： 概念 含义 推理能力 解决多步骤、复杂约束问题的实际能力 推理预算 一次任务允许投入的推理计算资源 可见解释 返回给用户的步骤、依据或分析摘要 分析文字更长，不代表推理能力更强；没有展 ...

引言在 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 ...