https://github.com/fuergaosi233/claude-code-proxy

上文用的litellm 配置豆包 1.6 使用claude code, 实际体验并不好。
新找了个开源项目效果还不错。

阅读全文 »

​
claudeCode 搞账号太难了。而且挺贵。
目前有白嫖的方式： https://anyrouter.top/register?aff=wWte
注册完，点击右上角的使用指南就可以了。
关键是配置环境变量：ANTHROPIC_AUTH_TOKEN 和 ANTHROPIC_BASE_URL

另外最近kimi开源的k2也可以这么搞。ANTHROPIC_BASE_URL填https://api.moonshot.cn/anthropic,ANTHROPIC_AUTH_TOKEN 填kimi的key就行。

豆包是openapi接口模型，麻烦点，要借助LiteLLM

概述

豆包1.6（Doubao-1.6）是字节跳动最新推出的通用大语言模型，具备强大的代码理解和生成能力。通过 LiteLLM 这个统一的 LLM API 框架，我们可以将豆包1.6 集成到 Claude Code 中，获得更优质的编程辅助体验。

为什么选择豆包1.6 + Claude Code

• 成本优势：豆包1.6 的定价相比 Claude 3.5 Sonnet 更具性价比
• 中文优化：对中文代码注释和技术文档的理解更准确
• 代码能力：在代码生成、重构、解释方面表现出色
• 稳定服务：依托火山引擎，提供企业级稳定性保障

前置条件

1. 已安装 Claude Code CLI 工具
2. 拥有火山引擎账号并完成实名认证
3. 开通了方舟大模型服务

步骤一：获取豆包 API 凭证

1.1 创建 API Key

1. 登录 https://console.volcengine.com/
2. 进入「方舟大模型服务」-「API Key 管理」
3. 点击「创建 API Key」，保存好生成的密钥

1.2 确认模型可用性

在控制台确认已开通 doubao-1-6 系列模型：

• doubao-1-6-chat-32k：通用对话模型
• doubao-1-6-pro-32k：高性能版本
• doubao-1-6-lite-32k：轻量快速版本

阅读全文 »

在云原生和容器化的世界里，Docker Swarm 为我们提供了一种简单而强大的方式来编排和管理容器集群。然而，在这种便利的背后，是一套复杂而精密的网络模型。当我们兴致勃勃地执行 docker service create 或 docker stack deploy 时，有时会迎面撞上一个令人困惑的错误，就像你遇到的那样：

network sandbox join failed: subnet sandbox join failed for "10.0.3.0/24": error creating vxlan interface: file exists

重启 Docker (systemctl restart docker) 似乎无济于事，但通过 docker stack rm 和 docker network prune 组合拳却能奇迹般地解决。这背后到底发生了什么？

要回答这个问题，我们不能只停留在“怎么解决”的层面，而必须深入底层，从第一性原理（First Principles）出发，理解 Docker Swarm 的网络是如何工作的。

阅读全文 »

在日常的系统运维和自动化部署流程中，证书管理是至关重要的一环。然而，有时候看似常规的证书更新操作，却可能引发意想不到的“血案”。最近，我就遇到了这样一次经历：在更新了服务器证书后，原本运行顺畅的自动发布流程突然挂了，日志中赫然躺着一行刺眼的错误：tls: failed to verify certificate: x509: certificate signed by unknown authority。

这个错误信息直译过来就是：“TLS 握手失败：无法验证证书，因为该证书由未知的颁发机构签署”。作为一名经验丰富的技术人员，我立刻意识到这很可能与证书信任链有关。经过一番抽丝剥茧的调查，最终发现问题的根源竟是——新证书所依赖的根证书“太新了”，而我的操作系统尚未“认识”它。

问题重现与初步排查

当我发现自动发布系统报错后，第一反应是检查新部署的证书本身是否正确。确认了证书的域名、有效期、私钥匹配都没有问题后，我开始怀疑是客户端（也就是执行发布任务的服务器）的信任问题。

为了验证这个猜想，我尝试了系统运维人员的“常规操作”：更新系统的 CA 证书库。在 CentOS/RHEL 系统中，这通常通过以下命令完成：

yum install ca-certificates

然而，这条命令执行后，问题依旧。经过仔细检查，我发现 yum 源中提供的 ca-certificates 包版本依旧是几年前的（例如 2021 版），里面包含的根证书列表自然也是那个时候的。而我新申请的证书，是由一个较新的中间 CA 机构签发的，其根证书（Root CA）可能在 2021 年之后才被广泛信任和收录。

这就完美解释了为什么会报错：我的服务器在尝试与一个使用新证书的服务建立 TLS 连接时，它会追溯该证书的签发链，一直到最顶端的根证书。然后，它会在自己本地的“受信任根证书颁发机构”列表（也就是 ca-certificates 包提供的那一套东西）里查找这个根证书。由于系统里的根证书列表太旧，找不到对应的根证书，系统便无法确认这个新证书的可信度，于是出于安全考虑，拒绝了连接，抛出了 x509: certificate signed by unknown authority 的错误。

刨根问底：证书信任链与 CA 体系

要理解为什么更新 CA 证书库能解决问题，我们首先需要了解 SSL/TLS 证书是如何工作的。

1. 信任的起点：根证书 (Root Certificate)
   操作系统和浏览器内部会预装一个列表，包含了它们无条件信任的顶级证书颁发机构（CA）的证书，这就是“根证书”。这些根证书是信任链的锚点，是整个信任体系的基石。

2. 信任的传递：证书链 (Certificate Chain)
   一个网站的服务器证书通常不是由根 CA 直接签发的，而是由一个或多个“中间 CA”签发的。这样就构成了一个信任链：

   • 根 CA 证书 签发 中间 CA 证书
   • 中间 CA 证书 签发 你的服务器证书

3. 验证过程
   当你的客户端（例如我们的自动发布服务器）连接到一个 HTTPS 网站时，服务器会出示它的证书以及相关的中间证书。客户端会沿着这条链进行验证：

   • 它首先检查服务器证书是否由一个中间 CA 签发。
   • 然后，它会继续检查这个中间 CA 的证书是否由更上一级的 CA 或根 CA 签发。
   • 这个过程会一直回溯，直到找到一个客户端本地信任库中存在的根证书为止。如果能成功追溯到，则验证通过；如果在本地找不到这条信任链顶端的根证书，验证就失败了。

我的问题正是出在了这最后一步：新证书链顶端的那个根证书，太新了，以至于系统自带的旧版 ca-certificates 包里没有包含它。

阅读全文 »

MCP 科普指南：小白也能懂的智能工具大全

你好！欢迎来到MCP的世界！即使你是一个10岁的小朋友，也能通过这篇文章学会使用这些超酷的智能工具！

🤖 什么是MCP？

MCP的全称是Model Context Protocol（模型上下文协议）。简单来说，它就像是一座桥梁，让你的AI助手（比如Claude、ChatGPT）能够连接到各种不同的工具和服务。

想象一下：

• 你的AI助手原本只能聊天
• 有了MCP，它就能帮你查天气、管理文件、发邮件、写代码等等！
• 就像给机器人装上了各种各样的工具！

🏠 MCP的两种类型

1. 本地MCP（在你的电脑上）

• ✅ 不需要网络也能用
• ✅ 数据很安全，不会泄露
• ✅ 运行速度快
• ❌ 功能可能有限

2. 服务端MCP（在云端）

• ✅ 功能超级强大
• ✅ 能处理大量数据
• ❌ 需要网络连接
• ❌ 可能需要付费

阅读全文 »

Python信号相关概念及运用

[TOC]

介绍

信号是软件中断。信号提供了一种处理异步事件的方法。

不存在编号为0的信号。kill函数对信号编号0有特殊的应用。POSIX.1将此信号编号值称为空信号。

很多条件可以产生信号：

• 当用户按某些按键时，引发终端产生的信号。(DELETE,Ctrl+C,Ctrl+,Ctrl+Z)。这些键可以自定义。
• 硬件异常产生信号：除数为0、无效的内存引用等。
• 进程调用kill(2)函数可将信号发送到另一个进程或进程组。有限制：只能发送给同一用户的进程，或者发送信号的进程所有者是超级用户。
• 用户可用kill(1)命令将信号发送给其他进程。
• 当检测到某种软件条件发生，并应将其通知有关进程时也产生信号。例句SIGURG、SIGPIPE、SIGALRM。

信号是异步事件的经典实例。产生信号的事件对进程而言是随机出现的。
可以要求内核在某个信号出现时按照下列方式之一进行处理:

1. 忽略此信号。大多数都可以，但有两个不能忽略，他们是SIGKILL和SIGSTOP。原因是：它们向超级用户提供了使进程终止或停止的可靠方法。
   另外，有些如果忽略由硬件异常引发的异常(如除0),则进程的行为是未定义的。
2. 捕捉信号。自定义信号处理函数。注意：不能捕捉SIGKILL和SIGSTOP信号。
3. 执行系统默认动作。针对大多数信号的系统默认动作是终止进程。

阅读全文 »