Claude Code 安装、更新与卸载指南

安装 Claude Code

1. Native 安装(推荐)

⚠️ 国内用户会出现不能访问或卡住的问题。

curl -fsSL https://claude.ai/install.sh | bash

安装后的可执行文件路径:/Users/junjian/.local/bin/claude

下面是安装卡住,但是程序已经下载成功,我手动安装完成的过程

下载的二进制文件会被保存在 ~/.claude/downloads 目录下:

ll ~/.claude/downloads
-rwxr-xr-x  1 junjian  staff   205M  5月 29 22:56 claude-2.1.156-darwin-arm64

我们需要把它移动到 ~/.local/share/claude/versions 目录下,并创建一个软链接到 ~/.local/bin

彻底搞懂 uv pip、uv add 和 uv tool 的核心区别

在 Python 工具链大洗牌的今天,Astral 团队推出的 uv 已经成为了无可争议的“速度之王”。它不仅能用 Rust 带来百倍的速度提升,还展现出了统一 Python 生态的野心。

然而,很多刚从 pippoetry 迁移过来的开发者,在看到 uv pipuv adduv tool 这三个都在“装包”的命令时,难免会产生疑问:它们难道不是重合的吗?为什么装个包还要分三种命令?

我们就来彻底拆解这三者的设计哲学和应用场景,帮你建立起最清晰的 uv 工作流。

💡 一分钟核心速览

其实,这是 uv 为了彻底解决 Python 长期以来“全局环境污染”“虚拟环境混乱”以及“工具与项目依赖混淆”等痛点,而设计的三套完全独立的工作流。

命令 对应传统工具 管理的目标对象 核心作用
uv pip pip / pip-tools 底层虚拟环境中的包 作为原生 pip 的超快替代品,直接向当前激活的环境中塞入依赖。
uv add poetry add / pdm add 当前声明式项目的依赖 现代项目管理工作流。自动管理 pyproject.tomluv.lock
uv tool pipx 全局可执行工具(如 ruff, black 在完全隔离的专用环境中安装 CLI 工具,并自动暴露到全局,绝不污染项目。

🔍 深度对比:为什么它们不能互相替代?

LiteLLM 代理实践:安装、配置与测试

安装

uv tool install 'litellm[proxy]'

配置

编写配置文件:config.yaml

model_list:
  - model_name: gpt-5
    litellm_params:
      model: openai/LongCat-2.0-Preview
      api_base: https://api.longcat.chat/openai/
      api_key: sk-xxx
  - model_name: gpt-5-nano
    litellm_params:
      model: openai/qwen3.5:9b
      api_base: http://localhost:11434/v1
      api_key: none

运行

litellm --config config.yaml

测试

⚠️ 通过测试说明 LiteLLM 代理只支持中转,上游没有提供对应的API支持(LongCat 只支持 Chat Completions),LiteLLM 也不支持。

我现在收到的很多创始人邮件都写成了一种强硬的新闻体风格。我知道它们是 AI 写的,因为以前从来没有创始人这样写过。一旦你意识到某件事是 AI 写的,就很难不去忽略它。

我从未 knowingly 读完过一封由人署名但由 AI 写的邮件。这感觉像被欺骗,谁会忍受呢?

这让我对作者评价降低。这意味着他们无法独立写好(或者觉得自己写不好),而且他们试图欺骗我。

用 AI 帮你写东西并不令人印象深刻;任何青少年都能做到。

来源: Simon Willison 的网络日志

Paul Graham

Pi Agent Event Examples

事件流

事件类型

事件 描述
agent_start 智能体开始处理
agent_end 运行的最终事件。为此事件等待的订阅者仍会计入结算
turn_start 新轮次开始(一次 LLM 调用 + 工具执行)
turn_end 轮次完成,包含助手消息和工具结果
message_start 任何消息开始(user、assistant、toolResult)
message_update 仅限助手。 包含带有增量的 assistantMessageEvent
message_end 消息完成
tool_execution_start 工具开始执行
tool_execution_update 工具流式传输进度
tool_execution_end 工具执行完成

prompt() 事件序列

当你调用 prompt("Hello") 时:

Pi Agent SDK 参考文档

本 SDK 提供对 Pi 智能体能力的程序化访问。可用于将 Pi 嵌入其他应用、构建自定义界面,或集成到自动化工作流中。

典型使用场景:

  • 构建自定义界面(网页、桌面、移动端)
  • 将智能体能力集成到现有应用
  • 用智能体推理创建自动化流程
  • 构建可生成子智能体的自定义工具
  • 以编程方式测试智能体行为

参见 examples/sdk/,获取从极简到全量控制的可运行示例。

快速上手 import { AuthStorage, createAgentSession, ModelRegistry, SessionManager } from "@earendil-works/pi-coding-agent"; // 设置凭证存储与模型注册器 const authStorage = AuthStorage.create(); const modelRegistry = ModelRegistry.create(authStorage); const { session } = await createAgentSession({ sessionManager: SessionManager.inMemory(), authStorage, modelRegistry, }); // 订阅事件流 session.subscribe((event) => { if (event.

惨痛的教训(The Bitter Lesson)

AI 的未来不在于将人类现有的经验硬塞给机器,而在于设计出能够利用无限算力进行搜索与学习的“元方法”。

回顾70年人工智能研究历程,最深刻的一条教训是:依托算力的通用方法,最终效果远超其他路径,且优势极其显著。究其根本,源于摩尔定律——或者更广义地说,单位计算成本持续呈指数级下降。绝大多数人工智能研究开展时,都默认智能体可使用的算力是恒定的(这种情况下,借助人类知识就成了提升性能为数不多的手段之一)。但只要研究周期稍长于普通科研项目,海量算力必然会成为现实。

研究者为追求短期见效的性能提升,往往试图融入自身对领域的人类认知;但从长远来看,真正起决定性作用的,只有对算力的充分利用。这两条路径本不必相互对立,现实中却常常冲突:投入在一方的时间,就无法用于另一方。研究者会在心理上执着于某一种研究思路;而依赖人类知识的方法,往往会让模型变得复杂,反而难以适配依托算力的通用优化路径。

人工智能研究者们屡屡迟来地领悟到这一惨痛教训,回顾其中几个典型案例,颇具启发意义。

在国际象棋领域,1997年击败世界冠军卡斯帕罗夫的算法,依靠的是大规模深度搜索。彼时,多数国际象棋计算机研究者对此倍感沮丧——他们此前一直钻研的,是融入人类对国际象棋特有棋局结构理解的方法。

Reachy Mini Conversation App

源码安装

克隆 Reachy Mini Conversation App

git clone https://github.com/wang-junjian/reachy_mini_conversation_app
cd reachy_mini_conversation_app

创建虚拟环境并安装依赖

uv venv --python 3.12
source .venv/bin/activate
uv sync

⚠️ 注意:要完全复现此仓库 uv.lock 文件中的依赖关系,请运行 uv sync --frozen 命令。这将确保 uv 直接从 lock 文件安装依赖项,而无需重新解析或更新任何版本。

安装可选功能

uv sync --extra local_vision         # Local PyTorch/Transformers vision
uv sync --extra yolo_vision          # YOLO face-detection backend for head tracking
uv sync --extra mediapipe_vision     # MediaPipe-based head-tracking
uv sync --extra all_vision           # All vision features

合并额外功能或包含开发依赖项:

Kilo Code - AI 编码智能体架构设计文档

项目总览

Kilo Code 是一个功能强大的开源 AI 编码助手,基于 OpenCode 框架开发。项目采用 Monorepo 架构,使用 Turborepo 和 Bun Workspaces 管理多个包。

核心数据

指标 数值
Monorepo 包数量 23
TypeScript 文件数 5800+
支持的 AI 模型 500+
内置工具数量 50+
UI 组件数(kilo-ui) 65+
国际化语言 19 种
开源协议 MIT

核心特性

  • 多模型支持:支持 500+ AI 模型,包括 Claude、GPT、Gemini、Grok、Codex、GLM 等
  • 多客户端:CLI、VS Code 扩展、Web UI 和桌面应用,满足不同场景
  • 丰富的工具集:50+ 内置工具,涵盖文件操作、命令执行、代码搜索
  • 插件扩展:支持外部插件和 MCP 服务器,动态加载自定义工具
  • 会话管理:完整的会话系统,支持父子会话、上下文压缩、会话恢复
  • 浏览器自动化:集成 Playwright,AI agent 可操作网页、截图、表单填充

Monorepo 依赖架构

Kilo Code 采用 Turborepo + Bun Workspaces 分层架构,23 个包协同工作。

架构分层

Pi - AI 编码智能体架构设计文档

Pi 是一个模块化的 AI 编码智能体 Monorepo,使用 TypeScript 构建。它提供统一的 LLM 抽象层、通用的智能体运行时、丰富的终端 UI 框架,以及完全可扩展的编码智能体命令行工具。

1. 项目概览

Pi(@earendil-works/pi-mono)是由 Mario Zechner 开发的 AI 编码智能体 Monorepo,设计理念是模块化、可扩展、供应商无关。它将多个 LLM 供应商的复杂性抽象为统一 API,提供强大的智能体运行时和工具执行能力,并附带生产就绪的终端 UI。

核心能力

能力 说明
统一 LLM API 9 种 API 协议和 30+ 供应商品牌的单一接口。只需修改一个字符串即可切换供应商。
智能体运行时 完整的智能体循环,支持并行工具执行、消息注入队列和上下文压缩。
丰富的终端 UI 独立的终端 UI 框架,支持差异化渲染、文本编辑器、图片显示和浮层系统。
扩展系统 80+ 扩展示例、20+ 生命周期钩子。可注册工具、命令、快捷键和供应商。
Web 组件 基于 Lit 的聊天 UI,支持沙箱化 Artifact 渲染(HTML、SVG、PDF、DOCX 等)。
多运行模式 交互式终端、管道友好的打印模式,以及用于 IDE 集成的 JSONL RPC 模式。

包依赖关系图

搭建 Reachy Mini 语音对话智能体

部署 Reachy Mini 语音智能体

安装 reachy_mini_conversation_app 到 Reachy Mini

在 MacBook 上运行 Reachy Mini Control,单击 Start 按钮。

Applications 页面,单击 Discover apps 后,搜索 reachy_mini_conversation_app

单击 Install 按钮安装 reachy_mini_conversation_app

MacBook 上实时模式运行 Speech To Speech

安装 Speech To Speech

uv venv --python 3.12
source .venv/bin/activate
uv pip install speech-to-speech
uv pip install "speech-to-speech[faster-whisper]"

中文

Speech To Speech:使用开源模型构建本地语音智能体

方法

架构

本仓库实现了一个语音到语音的级联管道,包含以下部分:

  1. 语音活动检测(VAD)
  2. 语音转文本(STT)
  3. 语言模型(LM)
  4. 文本转语音(TTS)

模块化

该管道提供了一种完全开放且模块化的方法,重点是利用 Hugging Face Hub 上 Transformers 库提供的模型。代码设计易于修改,我们已经支持特定设备和外部库的实现:

VAD

STT

LLM

TTS ChatTTS Pocket TTS - Kyutai Labs 提供的支持语音克隆的流式 TTS Kokoro-

使用 Claude Code:HTML 超乎寻常的妙用

Thariq: Using Claude Code: The Unreasonable Effectiveness of HTML

Markdown 已成为智能体(agent)与我们沟通时占主导地位的文件格式。它简单、可移植,具备一定的富文本能力,且易于编辑。Claude 甚至已经相当擅长在 Markdown 文件中使用 ASCII 绘制图表。

但随着智能体变得越来越强大,我感到 Markdown 已成为一种受限的格式。我发现自己很难阅读超过一百行的 Markdown 文件。我想要更丰富的可视化效果、色彩和图表,并且希望能轻松分享它们。

我也越来越不亲自编辑这些文件,而是将它们用作规格说明、参考文件、头脑风暴输出等。当我确实需要编辑时,我通常会让 Claude 来编辑,这就削弱了 Markdown 最大的一个优势。

我开始更偏爱 HTML 作为输出格式,而不是 Markdown,并且越来越多地看到 Claude Code 团队中的其他人也在使用它。以下就是原因。

(如果你想先看一些示例,可以在这里看到一大堆:https://thariqs.github.io/html-effectiveness ,不过记得回来看更多关于"为什么"的内容。)

为什么选择 HTML?

信息密度

与 Markdown 相比,HTML 能够传达更丰富得多的信息。

可以说,在我人生的前四分之一个世纪里,尽管我对编程一直充满痴迷,却始终无法摆脱一种内疚感——我总是在怀疑,自己手头正在构建的工具,是不是早在 30 年或 40 年前就已经被别人用更好、更完美的方式实现了。比如,我可能会自己写一个支持 TSV(标签分隔值)的查找与替换程序,但随后却发现早就有了一个叫 awk 的工具,能一举解决这一整类问题。

而我核心的论点在于:这其实是一个陷阱

必须去重新发明几个轮子,才能触及人类对“造轮子”这件事的认知边界。不是发明一千个轮子,也不是一个都不发明。在大多数领域,重新发明四五个轮子就足够了;而在数学计算机科学这种在认识论上极度严密且成熟的领域,这个数字可能更接近二十三十个。你所重新发明的每一个轮子,以及一路上提出的每一个针对性问题,都会把你推向真正的技术前沿——其速度之快,是把同样的时间花在盲目死板的学习上,甚至是花上其五倍的时间,都无法比拟的。 来源: Simon Willison 的网络日志

Andrew Quinn

Reachy Mini Python SDK 开发实战:从运动控制到视觉音频交互

Notebook 0 — First Connection & Movement

🎯 目标:连接 Reachy Mini 并执行你的第一条运动指令。

架构概述

Reachy Mini 采用客户端-服务器架构

graph LR
    subgraph Client
        A[Your Python Script]
    end
    
    subgraph Server
        B[Reachy Daemon]
    end
    
    subgraph Reachy Mini
        C[Robot Hardware or Simulation]
    end
    
    A <--> B
    B --> C

核心概念:

  • 守护程序(Daemon):一个后台服务程序,直接控制机器人的电机、传感器、摄像头和音频。
  • Python SDK:你用来发送指令的 reachy_mini 软件包。

为什么采用这种架构?

  • 多个客户端可以同时连接(如网页应用、脚本、Jupyter Notebook)。
  • 守护程序负责安全地处理底层硬件操作。
  • 你可以通过网络远程控制机器人。例如,在与机器人连接的树莓派(Raspberry Pi)上运行守护程序,同时在性能强大的服务器上运行你的 AI 代码。

验证连接

在运行代码之前,请先确认机器人已启动并正常运行。

你应该使用 Reachy Mini Control 来检查机器人是否已连接并准备就绪。

LLM Wiki:基于大语言模型的个人知识库构建模式

使用大语言模型(LLM)构建个人知识库的模式。

这是一份概念文件,设计用于复制粘贴到你自己的 LLM 智能体中(例如 OpenAI Codex、Claude Code、OpenCode / Pi 等)。它的目标是传达高层级的理念,而具体细节将由你的智能体与你协作构建。

核心理念

大多数人与 LLM 和文档打交道的体验看起来像是 RAG:你上传一批文件,LLM 在查询时检索相关片段,然后生成答案。这确实有效,但 LLM 每次都要从零开始重新发现知识,没有任何积累。当你问一个需要综合五份文档的微妙问题时,LLM 必须每次都找到并拼凑相关片段,没有任何东西被沉淀下来。NotebookLM、ChatGPT 文件上传以及大多数 RAG 系统都是这样工作的。

这里的理念不同。与其仅在查询时从原始文档中检索,LLM 增量式地构建并维护一个持久的维基 —— 一个结构化的、相互关联的 Markdown 文件集合,位于你和原始来源之间。当你添加新来源时,LLM 不只是将其索引以备后用。它会阅读来源,提取关键信息,并将其整合到现有维基中 —— 更新实体页面、修订主题摘要、标注新数据与旧主张的矛盾之处、强化或挑战不断演进的综合结论。知识被编译一次,然后保持最新,而不是每次查询都重新推导。

这就是关键区别:维基是一个持久的、复合增长的产物。

给 GitHub Pages 博客加评论:用 Giscus 开启原生的 Discussions 方案

1. 开启仓库的 Discussions 功能

默认情况下,GitHub 仓库没有开启讨论(Discussions)功能。

  • 进入 wang-junjian.github.io 仓库。
  • 点击顶部的 Settings(设置)。
  • General 页面向下滚动,找到 Features 区域。
  • 勾选 Discussions 选项。

2. 安装并授权 giscus app

为了让 Giscus 有权限向你的仓库写入评论,你需要:

  • 访问 github.com/apps/giscus
  • 点击 Install,并选择将其安装到你的 wang-junjian.github.io 仓库上。

3. 配置分类 (Category)

在你的 Discussions 页面中,建议创建一个专门的类别(例如命名为 AnnouncementsComments),并确保该类别的 Discussion format 设置为 Announcement,这样普通用户就不能直接在 GitHub 页面随意发起讨论,只能通过你的博客留言板生成。

4. 获取配置代码

访问 giscus.app,在“仓库”栏输入 wang-junjian/wang-junjian.github.io,它会自动检测并生成一段配置代码。

5. 博客中评论

Hermes 与 OpenClaw —— 该选哪个智能体?

Hermes vs. OpenClaw - When to Reach for Which Agent

发布时间:2026-05-07 作者:Brendan O'Leary

上周,有人在 Kilo Discord 里问:"我该从 OpenClaw 切换到 Hermes 吗?" 自 Hermes 今年二月发布以来,这个问题我已经见过不下十几次。问得好 —— 两者都是开源的,都能连接你的聊天应用,都能运行工具、记住上下文。单看功能列表,它们几乎一模一样。

但过去两个月同时运行两者之后,我认为功能清单反而让人分心 —— 真正让它们分道扬镳的是设计哲学。

Hermes 是在一个学习型智能体外包裹了一个网关。

OpenClaw 是在一个消息网关内包裹了一个智能体。

这个区别听起来很抽象,但它对你配置和与每个工具交互的方式有着切实的影响。

Hermes:智能体优先

Hermes Agent 来自 Nous Research,于 2026 年 2 月发布。截至本文撰写时,GitHub 星标数约为 13.5 万。其 headline 功能是所谓的"学习循环" —— 智能体会基于自身行为创建并进化自己的技能。

根据其功能文档

  • 自我改进的技能:智能体从经验中生成程序性知识。同一类任务跑上一百次,Hermes 真的会越做越好。
  • 五种沙箱后端:本地执行、Docker、SSH、Singularity 和 Modal。你可以自行选择命令执行的隔离程度。
  • 子智能体委派:生成拥有独立上下文和终端的子智能体。并行工作流,互不污染上下文。
  • 更广泛的浏览器/语音栈:Browserbase、Browser Use、Firecrawl、本地 Chrome,外加 Discord 频道原生语音支持。

KiloClaw 安全白皮书

KiloClaw 安全

安全架构、租户隔离与面向托管式AI智能体算力的数据保护

2026年2月 v1.0;Andrew Storms 独立安全评估

KiloClaw 是一个托管式计算平台,在每个专用虚拟机中运行每个用户的 AI 智能体实例。每位客户都会获得一个隔离的环境,其 AI 智能体可以在其中执行代码、访问文件系统、浏览网页以及连接到聊天频道(如 Telegram、Discord 和 Slack)。

对于代表客户执行任意代码的 AI 智能体托管式计算这类产品,其安全风险本身就很高。租户隔离的失误可能会将一个客户的秘密、对话和已连接账户暴露给另一个客户。机密管理的失误可能会危及客户托付给该平台的 API 密钥。

本白皮书介绍了 KiloClaw 的安全架构、保护客户数据的控制措施,以及 2026 年 2 月进行的独立安全评估的结果。它面向评估 KiloClaw 是否适合其组织的安全团队、合规官和技术决策者。

评估摘要

一项为期10天的独立安全评估通过威胁建模(采用 PASTA 框架,涵盖13项资产中的30个威胁)、代码审查、60多项对抗性测试以及实时基础设施测试,验证了 KiloClaw 的架构。总体结论是:KiloClaw 的安全架构是健全的,并在多个独立层实施了租户隔离。

KiloClaw 的工作原理

理解安全模型需要先理解其架构。

集成个人助手(OpenClaw|Hermes)的方式

聊天软件集成 OpenClaw 的方式

聊天软件要集成 OpenClaw,主要有这几类方式(可以组合): 用 OpenClaw 自带的“Channel 插件”直连(推荐,最省事) Telegram、WhatsApp、Discord、Slack、飞书/Lark、钉钉、Teams、Google Chat、Mattermost、Matrix、IRC、LINE、Signal、iMessage 等。 在 OpenClaw 的初始化或 openclaw channels add 里直接选通道、按向导配置即可。 本质上是:各 IM 的 Bot API / Webhook / Socket Mode / QR 扫码 对接到 OpenClaw 的 Gateway。初始化向导里可以看到支持的通道清单。 通用 HTTP 接口集成(适合任意聊天平台) OpenClaw 的 Gateway 提供了一个 HTTP 端点 /tools/invoke,可以调用单个工具(例如创建会话、发消息、拉取历史等),支持 Bearer 认证和 OpenAI 兼容的 /v1/* 风格接口。 你的聊天软件后端只要能发 HTTP POST,就可以用这个接口和 OpenClaw 交互。

研究编码智能体(Kilo Code)开源项目的最佳实践

研究编码智能体开源项目的最佳实践

基于 Kilo Code 的架构特征和当前编码智能体领域的生产实践 ,以下是系统研究此类项目的 方法论框架

阶段 1:宏观定位(Why & Where)

研究维度 关键问题 Kilo Code 的启示
Fork 溯源 上游是谁?核心差异点?社区分裂原因? Kilo 从 Roo Code 分叉,差异集中在 Cloud 集成和商业化功能
生态位 是「IDE 插件」「CLI 工具」还是「平台」? Kilo 是「IDE 扩展 + CLI + Cloud」的三位一体
许可策略 是否存在 BSL/SSPL 等限制性条款? MIT 许可证,无商业限制
模型绑定 是否硬编码单一提供商? 模型中立是核心卖点,避免供应商锁定

阶段 2:架构解构(How)

建议的代码阅读路径(以 Kilo 为例):

  1. 入口层src/extension/activate.ts(VS Code 生命周期)、src/extension/api.ts(IPC 外部 API)
  2. 核心代理循环 — 查找 Cline/Roo/Kilo 主类,理解 Plan → Act → Verify 的循环
  3. 工具调用层McpHub 如何集成外部工具(文件系统、终端、浏览器)
  4. 上下文管理层 — Memory Bank、Context Mentions、自动索引的实现
  5. 模式系统 — Custom Modes 的解析与切换逻辑
  6. 差异标记 — 搜索 // kilocode_change 快速定位增量代码

Reachy Mini 机器人

Reachy Mini

2025年12月买的 Reachy Mini 机器人,近5个月终于到手了。

购买链接

介绍

Reachy Mini 是由法国机器人公司 Pollen Robotics 开发的一款开源的桌面级人形机器人,旨在为教育、研究和创意项目提供一个灵活且易于使用的平台。Reachy Mini 是 Reachy 机器人的小型版本,具有相似的功能和设计,但体积更小,更适合在桌面环境中使用。

硬件版本

功能特性 Wireless (无线版) Lite (轻量版)
价格 449449 299
电机与机械结构 9 个伺服电机 9 个伺服电机
头部运动 6 自由度 (pitch, roll, yaw, x, y, z) 6 自由度 (pitch, roll, yaw, x, y, z)
身体旋转 ±160° ±160°
天线 2 个动力感应天线 2 个动力感应天线
摄像头 广角摄像头 广角摄像头
麦克风 4 麦克风阵列 4 麦克风阵列
扬声器 5W 扬声器 5W 扬声器
板载算力 树莓派 CM 4 (16GB 存储) -
加速计 内置 IMU -
Wi-Fi 连接 支持 -
独立模式 支持 需通过 USB 连接控制
供电方式 电池供电 + 电源适配器 (7.3V / 5A) 仅限电源适配器 (7.3V / 5A)

开箱与初体验 Welcome to Reachy Mini!

macOS 图像转为 WebP 格式(Automator)

macOS 图像转为 WebP 格式工具使用说明

本工具是一个专为 macOS 设计的自动化脚本,它能帮助您将选择的图片转换为 WebP 格式。

该工具设计为通过 macOS 的“快速操作”或 Automator 工作流程来调用,从而实现便捷的图像转换操作。

  • 作为“快速操作”使用:
    • 设置“快速操作”: 您需要将提供的脚本保存为 Automator 工作流程的“快速操作”。
      • 打开 Automator 应用(在“应用程序” -> “实用工具”中)。
      • 选择 “文件”>“新建”
      • 选择 “快速操作” 并点击“选取”。
      • 在左侧的库中,搜索并拖动 “运行 Shell 脚本” 到右侧的工作流程区域。
      • 在“运行 Shell 脚本”模块中,将“传递输入”设置为 “作为自变量”
      • 将本工具的完整代码粘贴到“运行 Shell 脚本”的文本框中。
      • 选择 “文件”>“存储”,为您的快速操作命名,例如“图像转换为 WebP”。
    • 使用方法:
      • 打开 Finder,导航到您要转换的图片所在的文件夹。
      • 选中您希望转换的所有图片(请确保至少选择一张)。
      • 右键点击选中的图片,或者点击 Finder 窗口顶部的“服务”菜单。
      • 在上下文菜单中,找到并点击您刚才创建的“快速操作”名称,例如 “图像转换为 WebP”
      • 一个对话框会弹出,询问您希望转换为哪种格式。选择您的偏好。
      • 工具将自动处理图片,并将转换后的新图片保存在您选中的图片所在的相同文件夹中。

Kilo Code:基于智能体工程的自动化软件开发平台

Kilo Code

简介

Kilo Code 是一个开源的一站式智能体工程(Agentic Engineering)平台,旨在通过 AI 智能体(Agents)自动化软件开发全流程。它是目前 GitHub 上非常活跃的项目,核心定位是作为开发者的 AI 辅助引擎,帮助构建、部署和迭代代码。

安装

# npm
npm install -g @kilocode/cli

# Or run directly with npx
npx @kilocode/cli

Kilo CLI

主要功能

Kilo项目核心能力分析

基于项目文档和代码结构分析,Kilo是一个开源的AI编码智能体平台,主要用于加速软件开发过程。它是OpenCode项目的fork版本,增强为全面的agentic工程平台。以下是其核心能力的详细分析:

  1. AI驱动的代码生成与自动化 核心功能:支持从自然语言描述生成代码,例如用户输入"add input validation to the signup form",智能体会自动生成相应的代码片段。 自动化任务:能够自动化重复性编码任务,如重构代码、运行测试、修复错误等。智能体会自我检查工作,确保代码质量。 内联自动完成:提供实时AI驱动的代码补全建议,提升编码效率。