摘要：测试发现DeepSeek大模型存在一个易复现的异常行为：当用户发送未闭合的XML标签（如"<think"）时，模型会完全忽略输入内容，进入空输入状态并随机生成完整的对话场景，每次输出都不相同。这种现象在网页端和移动端均可100%复现，不依赖深度思考或联网功能。技术分析表明，未闭合标签破坏了Prompt结构，导致输入被"吞噬"，模型转而基于训练数据

本文记录了作者在开发环境中使用ClaudeCode连接MiMo模型时遇到的协议变更问题。十天后，原本正常工作的配置突然出现400错误，原因是MiMo要求在多轮会话中必须回传模型思考时产生的"reasoning_content"字段。作者尝试了禁用思考模式、清空会话历史、更换客户端等多种方案均未奏效。最终发现直连官方API可行，但通过中转站时字段会被丢弃。文章详细记录了排查过程，

摘要：本文探讨了NewAPI公益站在使用MiMo模型时出现的推理链缺失问题。虽然官方API已解决reasoning_content回传问题，但公益站的"透传"机制导致400错误。作者提出五层代理链路方案，核心是在公益站前增加MiMoProxy中间层，专门缓存和回填推理内容。该方案虽然抽象但实用，完整链路包括ClaudeCode、CCSwitch、MiMoProxy、NewAPI

之前一直在用 OpenClaw，一个社区推动的 AI Agent 工具。后来发现 Nous Research 推出了 Hermes Agent——一个号称"越用越强"的自主 Agent，支持持久记忆、自动创建技能、跨会话学习，还能跑在 Telegram、Discord 等多个平台上。作为一个爱折腾的人，当然想上手试试。但我有几个硬性要求不装 Docker（太占资源）不装 WSL（不想碰 Linux

摘要：本文对比了ClaudeCode/Codex（全量暴露）和Hermes（渐进式披露）两种AI编程助手的架构差异。测试发现，全量暴露方案虽提示词庞大，但凭借缓存机制实际Token消耗更低，且能保持思维连贯性；而渐进式披露虽看似轻量，却因缓存命中率低导致综合成本更高，且存在思维断片风险。文章建议：复杂编程任务适合全量暴露，短平快场景可选渐进式披露，并指出优化缓存机制是渐进式方案的关键挑战。

摘要：本文分析了ClaudeCode缓存失效问题，指出其随机归属头机制导致系统提示词前缀不一致，使缓存无法命中。通过对比KVCache与提示词缓存的差异，阐述了DeepSeek采用硬盘持久化、多层落盘等策略的缓存优势。同时讨论了API中转站对缓存的影响，建议开发者关注环境变量设置和中转站处理策略，以优化推理速度和成本。

本文分享了解决ClaudeCode在第三方API中转时搜索功能失效的完整方案。通过使用Tavily MCP服务器替代内置搜索工具，配合用户级提示词注入，成功绕过协议不兼容问题。文章详细介绍了Tavily的优势、MCP服务器配置步骤（包括常见错误修正）、提示词重定向规则设置，并提供了完整操作速查表。该方案不依赖中转站协议更新，具有自主可控、灵活性强等特点，特别适合习惯使用ClaudeCode但遇到搜

本文探讨了实时语音交互技术的发展，对比分析了WebSocket和WebRTC两种方案在语音传输中的优劣。WebSocket适合文本传输但存在延迟问题，而基于UDP的WebRTC能实现更低延迟的全双工通话。文章重点介绍了语音活动检测(VAD)技术和豆包采用的端到端模型创新，这种模型直接理解语音信号而非依赖文字转译，使交互更自然流畅。最后指出随着5G和端到端模型的发展，语音交互将实现更接近真人对话的体

本文提出了一种多协议翻译代理方案，旨在解决AI编程工具生态中三种不兼容API协议（ChatCompletions、ResponsesAPI、Messages）的兼容性问题。该方案通过三层处理流水线实现：协议翻译层将不同协议请求转换为统一格式，推理注入层补充推理内容，上游转发层完成请求转发。核心创新包括：1）单代理支持多协议入口；2）统一缓存机制；3）精确的流式事件映射；4）透明的错误透传设计。该架

本文针对AI推理模型API在多轮会话中因缺失推理内容字段导致工具调用链断裂的问题，提出了三级优化方案：首先采用填充空推理字段的临时方案确保协议兼容性；随后引入SQLite持久化缓存解决内存缓存易失性问题，并通过工具调用ID索引提升缓存复用率；最终构建两级缓存架构（内存+SQLite）实现性能与可靠性的平衡。方案采用WAL模式、线程安全连接等技术保障稳定性，并配备可视化仪表盘便于运维管理。该零外部依