Ai on 魔都水滴

7 个 AI 编程套餐，每天开 7 个标签页查额度？我写了个看板一屏搞定

Sun, 26 Jul 2026 06:00:00 +0800

先说结论

如果你同时订阅了 Codex、MiniMax、火山方舟、Kimi Code、LongCat、千问 AI、Google AI 等多家 AI 编程套餐，大概率体验过一种痛苦：每天要在 7 个不同网站、7 套不同的登录体系里反复查看"还剩多少额度"。我开源了一个自托管的配额看板 coding-plan-dashboard，一条 docker compose up -d 启动后，所有平台的额度百分比、重置倒计时、多账号信息全部聚合在一个深色页面上，打开浏览器就能看到。本文写作与截图时间为 2026 年 7 月 26 日。

国内 Coding Plan 大洗牌：GLM 抢不到、Kimi 关入口，谁还值得买？

Tue, 21 Jul 2026 07:00:00 +0800

**先给结论：**截至 2026 年 7 月 21 日，国内 Coding Plan 已经出现明显分层：智谱 GLM 是每天固定时间的限量秒杀，实际接近“完全买不到”；Kimi 当前会员订阅入口已关闭；MiniMax TokenPlan 目前不限购，但实际编码体验弱于那些限购型 Plan；千问 AI 刚推出 qwen3.8，当前不限购且有使用优惠，是现阶段更值得优先尝试的选择，但不排除后续限购；火山方舟 CodingPlan 和 AgentPlan 虽然限购，但仍有机会购买。

Coding Plan 还能买到吗？2026 年主流大模型编程套餐限购、限额与避坑实测

Mon, 20 Jul 2026 09:00:00 +0800

**结论先说：**截至 2026 年 7 月 20 日，主流 Coding Plan 并不是简单的“全部涨价”或“全部限购”。更准确的说法是：**大多数方案仍能购买，但购买入口、地区、支付方式、模型额度和高峰期并发，已经被拆成了几道不同的门槛。**其中，Google Gemini CLI 的个人服务、部分新产品的高阶档位，以及地区不支持的本地化套餐，最容易出现“看得到、买不到”或“买到了、用不满”的情况。

AI 怎么学会“用手”的？从只会聊天到会查、会写、会操作

Sun, 19 Jul 2026 22:00:00 +0800

先说结论

AI 并不是突然长出了手。它只是学会了一个非常关键的动作：先判断自己需要什么工具，再用结构化参数请求工具，等工具返回真实结果，最后把结果翻译成人话。

这套机制通常叫 Tool Calling（工具调用）；在不同平台上也会看到 Function Calling、Tools API 等名字。MCP（Model Context Protocol，模型上下文协议）则像一套“统一插座”，让不同的 AI 应用可以用相似的方式发现和调用文件、数据库、搜索、工单、浏览器等能力。

本文不把 AI 神化成“会自己做事的数字员工”，而是把一次调用拆开给你看：模型到底做了什么、真正执行动作的是谁、为什么 MCP 会火、权限应该放在哪里，以及为什么“能调用工具”不等于“可以随便给它钥匙”。文中截图来自 OpenAI 与 MCP 官方页面，命令输出图为本文根据真实调用流程制作的示意证据；文章不包含任何真实内网地址或主机名。

AI 为什么会一本正经地胡说八道？——你以为它在思考，其实它在玩‘超级成语接龙’

Sun, 19 Jul 2026 20:30:00 +0800

先说结论

AI 幻觉不是“模型偶尔抽风”，也不只是某个版本的 Bug。只要模型的核心任务仍然是：根据上下文预测下一段最可能出现的文字，那么它就可能生成一段听起来非常完整、语气非常肯定、实际上没有证据支撑的内容。

最容易记住的比喻是：大语言模型像一个读过很多书、特别会接话的“超级成语接龙选手”。它擅长把句子接得顺，却不天然保证每句话都是真的。

AI 为什么总说‘我忘了’？Token、上下文窗口与那叠写满就必须丢掉的便利贴

Sun, 19 Jul 2026 18:30:00 +0800

先说结论

AI 的“记忆力差”，很多时候不是它完全没有记住，而是当前对话能带进模型的内容有限。可以把上下文窗口想成一叠有限容量的便利贴：新的问题和工具输出不断贴上去，便利贴写满以后，系统就必须压缩、截断，或者把最旧的一部分移走。被移走的内容，模型在当前请求里就很可能再也看不到。

你有没有遇到过这种场景：刚刚和 AI 约定“所有代码都用 Python”，聊了十几轮以后，它突然给出一段 JavaScript；你明明把项目背景写得很完整，AI 却又问了一遍“你使用的是什么系统”；或者你上传了一篇长文档，AI 能准确复述开头，却对中间那条最重要的限制条件一无所知。

这看起来像“AI 记性不好”，但更准确的说法是：AI 每次回答时，能看到的内容受到上下文窗口限制；而能看到，也不代表它会同等重视每一段内容。

本文不把 Token 讲成吓人的数学名词，而是把它讲成一套便利贴管理规则。你会看到 Token 是什么、上下文窗口如何装载、为什么长对话会遗忘、Agent 为什么更容易把窗口塞满，以及普通用户如何用简单的整理方法让 AI 少忘事。

一个周末硬重置 4 次，还送两张卡：当 Token 不再稀缺，我们真正缺的是什么？

Mon, 13 Jul 2026 07:00:00 +0800

先说结论

上个周末的 Codex 用户，像是突然住进了一家不断续杯的自助餐厅：北京时间周五凌晨硬重置一次，周六又重置两次，到了周一早上，一觉醒来发现额度再次装满；账户里还多了一张可以留到以后使用的重置卡。Tibo 在庆祝 Codex 达到 600 万活跃用户时又预告，第二天还会给所有用户再发一张卡。

更夸张的是，当时所有 Codex 订阅用户的 5 小时限额被临时移除，只剩周限额。与此同时，我手里还有一批 GLM-5.2 额度要在周日到期。以前总担心 Token 不够，那几天却变成了另一种烦恼：怎么才能认真、有效、甚至体面地把 Token 用掉？

折腾完这个忙碌、惊喜又无奈的周末，我越来越相信：AI 时代真正稀缺的可能不是 Token，而是值得消耗 Token 的问题、与别人不同的创意，以及把创意迅速变成现实的能力。

HermesAgent 为什么一直不回微信和企业微信？我最后排到的根因居然是本地 relay 的 3 秒超时

Sun, 31 May 2026 08:00:00 +0800

先说结论这次故障看起来像“模型不行”或者“微信通道坏了”，但真正把消息链路掐断的，是我本地那层 relay 的超时设置。它把整条上游请求的等待窗口限制成了 3 秒，而真实的 WeChat / WeCom 消息 turn 往往需要更久才能从新 API 网关拿到完整回复。结果就是：relay 先断开，HermesAgent 只能看到 Connection error、RemoteProtocolError，然后主模型和 fallback 一起被耗尽。更准确地说，这不是 HermesAgent 核心代码的问题，也不是模型名的问题，而是一个本地外置组件的连接策略问题。把 connect timeout 和 response wait 混成同一个超时，等于给长请求做了一个错误的截止时间。修复方式也不复杂：连接阶段保留短超时，连接成功后把 socket 切回阻塞等待；同时把 relay 做成独立、可持续启动的服务，不再把它绑死在临时 shell 里。问题背景 HermesAgent 这条链路不是单机脚本，而是一条完整的消息生产线。用户从微信或企业微信发出一句话，消息会先进入 Hermes 的通道层，再进入 Gateway，接着经过本地 relay 转发到自建的 NewAPI 网关，最后才到模型服务。模型回来的内容还要经过 Hermes 的消息整理、工具调用处理、最终拼接，再发回原始通道。这种结构的好处是灵活，坏处也很现实：任何一层都可能制造“看起来像模型故障”的表象。你看到的是“没有回复”或者“Connection error”，但根因可能在更外层的 relay、socket、超时、代理或者会话路由里。这次我一开始也走了老路，先怀疑模型配置。因为从表象看，主模型和 fallback 都失败了，日志里反复出现： Primary model failed switching to fallback API failed after 1 retries Connection error Max retries exhausted 如果你只看这一段，很容易得出“模型端不稳定”的结论。但这类结论通常太早。因为同一批模型在别的入口上是能正常工作的，/v1/models 也能返回，简单的 health check 也没有异常。真正出问题的是“真实消息 turn”。

macOS LaunchAgent 里的 Python 程序连不上外网？一文搞懂 httpx 代理陷阱的完整排查与修复

Sat, 30 May 2026 09:00:00 +0800

先说结论：

macOS 的 LaunchAgent 环境下，Python httpx 库会自动读取系统代理设置（scutil --proxy），但 LaunchAgent 进程可能根本无法访问该代理服务器——于是请求静默失败，报错 All connection attempts failed 或 No route to host。

解决方案只需要一行：在 LaunchAgent 的 plist 文件中添加 NO_PROXY=*。

这篇文章记录了我从发现 AI Agent 企业微信消息不回复、到逐步排查代理问题、最终定位到 macOS 系统代理与 LaunchAgent 网络隔离的完整过程。涉及 Python httpx 源码分析、macOS 代理机制深度解析、以及 LaunchAgent 运行环境的诸多坑点。

从 OpenClaw 迁移到 HermesAgent：一次丝滑的 AI 智能体搬家实战

Fri, 29 May 2026 08:00:00 +0800

前言：为什么我要"搬家"？

2026 年，AI 智能体（Agent）领域的发展速度简直可以用"日新月异"来形容。半年前还在用的工具，可能今天就被更强大的替代品超越了。作为一个深度依赖 AI 智能体来处理日常工作的人，我一直在关注这个领域的最新动态。

最近，我完成了一次从 OpenClaw 到 HermesAgent 的完整迁移。这不是一时冲动的决定，而是在实际使用中感受到两个工具的差异后，做出的深思熟虑的选择。

这篇文章会详细分享：

背景：OpenClaw 和 HermesAgent 分别是什么
迁移原因：为什么我要从 OpenClaw 迁移到 HermesAgent
迁移过程：如何一步步完成迁移，保留所有数据
踩坑记录：迁移过程中遇到的问题和解决方案
迁移后清理：如何彻底移除 OpenClaw 残留文件
迁移后体验：HermesAgent 带来了哪些新能力
Q&A：常见问题解答

使用 WoClaw 解决多智能体共享记忆：让 OpenClaw、Codex、Claude、Gemini 站在同一张桌子上

Sun, 05 Apr 2026 20:10:00 +0800

我一直觉得，多智能体系统最难的不是“谁更聪明”，而是“谁还记得上一次已经讨论到哪里了”。

当你把 OpenClaw、OpenAI Codex、Claude、Gemini 这些工具放进同一个工作流里，最容易出现的问题并不是回答质量不够，而是上下文开始分叉：

OpenClaw 记住了调度顺序，Codex 记住了代码细节，Claude 记住了讨论结论，Gemini 记住了背景资料，但它们彼此并不知道对方知道什么。
每个工具都有自己的会话生命周期，今天说过的话，明天可能就不在同一个上下文里了。
一旦项目进入“多人、多轮、多工具”的阶段，重复解释背景会比真正解决问题更耗时。
如果没有统一的记忆层，最后你得到的不是协作，而是几份彼此相似、又彼此不兼容的局部答案。

这篇文章想讲的就是：我怎么用 WoClaw 把这些工具拉到同一套共享记忆里，让它们从“各说各话”变成“围着同一份状态协作”。

为了避免泄露任何隐私信息，下面所有例子都做了抽象处理，不包含真实机器名、账号、地址、密钥和内部项目代号。

OpenClaw 接入 MiniMax 一个月总结：稳定、够快，真正有价值的是可持续

Thu, 19 Mar 2026 10:30:00 +0800

过去一个月，我持续用 MiniMax 作为 OpenClaw 的主模型，覆盖了日常巡检、连接排障、健康检查、安全加固、定时任务治理和博客辅助写作等一整套自动化流程。回头看，这次实践最大的收获并不是“AI 能替我做多少事”，而是我逐渐确认了一个更现实的判断：对于 OpenClaw 这类要长期运行、要和工具链打配合、还要处理大量中文上下文的系统来说，模型最重要的不是纸面能力，而是稳定性、响应速度、接入成本和长期可维护性之间的平衡。

OpenAI GPT-5.4 全面解读：定位、能力、成本与落地实践（截至 2026-03-06）

Fri, 06 Mar 2026 08:20:00 +0800

2026 年 3 月 5 日，OpenAI 正式发布 GPT-5.4。很多人第一反应是：这到底是一次“小版本升级”，还是一次会影响实际生产力结构的能力跃迁？

如果只看命名，5.4 像是 5.2、5.3 之后的顺序迭代；但如果结合官方发布内容、模型文档、API 能力矩阵和 ChatGPT 侧的产品变化来看，GPT-5.4 的核心价值并不在“参数大了多少”，而在于它把三条线真正收敛到了一个更可用的中心点：

推理能力（reasoning）
编程与工程落地能力（coding + agentic workflows）
工具生态协同能力（tooling + computer use）