Skillbot：用Markdown定义AI技能，实现声明式AI助手开发

1. 项目概述：一个用Markdown文件定义能力的AI助手

如果你和我一样，对市面上的AI助手框架感到既兴奋又头疼——兴奋于它们强大的自动化潜力，头疼于要为每个新功能编写和维护成百上千行代码——那么Skillbot的出现，可能会让你眼前一亮。这个项目彻底颠覆了传统AI助手的构建范式。它的核心洞察极其简单，却又充满力量：既然大语言模型（LLM）能读懂指令，那我们为什么还要为它写代码？

Skillbot是一个个人AI助手，其核心理念是“技能即文档”。在这里，每一个功能，从查询天气、管理GitHub仓库，到控制智能家居、分析市场数据，都不是通过传统的TypeScript或Python插件实现的，而是由一个纯文本的Markdown文件来定义。你不需要编写任何调用API、解析响应或处理错误的代码，只需要用平实的英文，在Markdown文件中写下“做什么”的指令和示例。剩下的，交给LLM去理解和执行。

想象一下，你想让助手学会用Docker。在传统框架里，你需要安装SDK、处理认证、定义函数、编写错误处理逻辑。而在Skillbot里，你只需要创建一个docker.md文件，写上“列出所有容器：docker ps -a”和“启动服务：docker compose up -d”。就这么简单。这种声明式而非过程式的构建方式，将复杂性从应用程序代码转移到了LLM可读的文档中，使得技能扩展变得前所未有的轻量和快速。

这个项目最初从OpenClaw和nanobot等优秀项目中汲取灵感，但走上了一条截然不同的道路。它用仅815行的核心代码，支撑起了33个功能各异的技能，而其唯一的npm生产依赖仅仅是openaiSDK。这种极简主义的设计，背后是对“工具本质”的深刻理解：与其为每个服务重新造轮子，不如让LLM学会使用那些已经无处不在、且无比强大的现有工具——无论是curl、gh这样的命令行工具，还是任何可以通过HTTP访问的API。

2. 核心设计哲学：从“如何做”到“做什么”的范式转移

2.1 传统AI助手框架的困境

在深入Skillbot之前，我们先看看主流AI助手框架是如何工作的。无论是基于LangChain、LlamaIndex，还是其他自研框架，其核心模式可以概括为“用户请求 → 代码路由 → 工具调用 → 结果解析 → 格式化回复”。在这个链条中，“工具”是关键。每个工具都是一个独立的、硬编码的函数或类，它封装了对某个特定服务（如GitHub API、天气API）的调用逻辑。

这种模式带来了几个显著问题：

1. 开发成本高：每增加一个新功能，都需要开发者熟悉对应服务的API，编写完整的调用、错误处理和结果解析代码。一个中等复杂度的功能，轻松就能写出几百行代码。
2. 维护负担重：服务API一旦更新，对应的工具代码就必须同步修改。依赖的第三方SDK升级也可能带来兼容性问题。
3. 灵活性差：工具的行为在编码时就被固定了。如果用户的需求稍有变化（例如，从“获取仓库列表”变为“获取最近有更新的仓库列表”），往往需要修改代码并重新部署。
4. 系统膨胀：随着功能增多，代码库会急剧膨胀，依赖项也会越来越多，给安全性和部署带来挑战。

2.2 Skillbot的解决方案：技能即Markdown

Skillbot从根本上跳出了这个循环。它提出了一个大胆的假设：LLM本身就是一个强大的、通用的“代码解释器”和“指令执行器”。我们不需要教AI“如何调用GitHub API”，只需要告诉它“GitHub能做什么，以及用什么命令去做”。

这个“告诉”的过程，就是编写技能Markdown文件。一个技能文件通常包含以下几个部分：

• Frontmatter（元数据）：用YAML格式定义技能的名称、描述、适用平台等。
• 指令说明：用自然语言描述这个技能的目的、使用场景和注意事项。
• 命令示例：列出完成特定任务所需的具体shell命令或curl请求。

例如，一个简单的web-search.md技能可能长这样：

--- name: web-search description: Perform a web search using the DuckDuckGo instant answer API. platform: cross-platform --- # Web Search Use this skill to get quick answers or summaries from the web without opening a browser. ## How to search To search for something, use `curl` to query the DuckDuckGo API. The API returns a JSON response. Example command to search for "latest TypeScript features": ```bash curl -s -H "Accept: application/json" "https://api.duckduckgo.com/?q=latest+TypeScript+features&format=json&pretty=1"

Understanding the response

The API returns aAbstractfield with a summary, and aRelatedTopicslist. Focus on theAbstractfor direct answers.

当用户问“TypeScript最近有什么新特性？”时，Skillbot的LLM核心会： 1. 读取所有技能目录，发现`web-search`技能可能相关。 2. 加载`web-search.md`文件内容。 3. 理解指令，并组合生成最终的`curl`命令。 4. 通过内置的`bash`工具执行该命令。 5. 获取JSON响应后，LLM再根据技能文件中的提示（“关注Abstract字段”），从原始结果中提取、总结信息，并最终生成对用户友好的回复。 **这个过程的精妙之处在于**：所有复杂的逻辑——判断该用哪个技能、如何组合参数、如何解析非结构化的API响应——都交给了LLM。开发者只需提供“说明书”（Markdown文件）。这极大地降低了开发门槛，一个不懂编程但熟悉命令行和API的人，也能轻松为Skillbot添加强大功能。 > **实操心得：技能文件的“教学”艺术** > 编写技能文件不是简单的命令罗列，而是一种“教学”。你需要像教一个聪明但不懂行的助手一样去写。好的技能文件会： > 1. **明确边界**：说明这个技能擅长什么，不擅长什么。 > 2. **提供范例**：不止一个命令，而是多个典型场景的示例，帮助LLM举一反三。 > 3. **解释输出**：告诉LLM命令执行后会得到什么，哪些部分是重要的，应该如何解读。这对于处理复杂JSON或文本输出至关重要。 > 4. **考虑错误**：虽然不写错误处理代码，但可以在说明中提示常见错误原因（如“如果返回`404`，可能是API路径错误”），引导LLM做出更合理的反应。 ### 2.3 架构对比：复杂度转移的价值 让我们量化一下这种范式转移带来的差异。以一个“获取GitHub Issue列表”的功能为例： | 维度 | 传统框架实现 | Skillbot 实现 | | :--- | :--- | :--- | | **代码行数** | 约80-150行 (TS/Python) | 约15-30行 (Markdown) | | **核心内容** | 认证逻辑、API客户端初始化、请求函数、类型定义、错误处理、响应解析、格式化函数。 | Markdown文件，包含：功能描述、`gh issue list`命令示例、输出字段说明。 | | **依赖** | `@octokit/rest` 等官方SDK及其传递依赖。 | 系统已安装的 `gh` (GitHub CLI) 工具。 | | **维护点** | SDK版本、API端点变更、认证方式更新、错误码变化。 | `gh` CLI工具的版本和命令语法。 | | **灵活性** | 功能固定。想从“列出issue”变为“列出带有特定label的PR”，需修改代码。 | LLM可根据自然语言指令，灵活组合`gh`的不同参数，如`gh pr list --label bug`。 | 可以看到，Skillbot将复杂度从“框架代码”转移到了“LLM的推理能力”和“系统环境的管理”上。它用LLM的通用能力，替代了大量定制化的胶水代码。这种设计的**优势**是极致的简洁和灵活；**代价**则是需要LLM具备可靠的工具使用能力，并且运行环境需要预装相应的命令行工具。 ## 3. 核心机制深度解析：两大工具与动态技能加载 ### 3.1 万能的“双工具”模型 Skillbot的核心引擎异常简洁，它只提供了两个基础工具（Tool），却通过它们撬动了无限的可能性： 1. **`bash` 工具**：这是Skillbot的“瑞士军刀”。它可以执行任何shell命令。安全性通过三层防护保障（下文详述）。几乎所有技能都通过这个工具与外部世界交互。 2. **`spawn` 工具**：用于运行后台子代理（Subagent）。当遇到一个复杂、多步骤的任务时，主代理可以“孵化”一个子代理，赋予其特定的目标和上下文，让其独立运行。子代理同样可以调用技能，完成后将结果返回给主代理。这实现了简单的任务分解与并行处理能力。 这种设计哲学是**“提供基础能力，而非封装服务”**。例如，它不提供一个封装好的`GitHubTool`，而是通过`bash`工具去执行`gh issue list`命令。这意味着： - **零集成代码**：无需为GitHub、Docker、Spotify等成百上千个服务单独编写集成代码。 - **直接利用生态**：直接使用这些服务官方维护的、功能最全的CLI工具或API。 - **HTTP API即技能**：对于没有CLI的服务，技能文件可以直接写`curl`命令来调用其HTTP API，同样无需额外代码。 ### 3.2 动态技能加载与提示词工程 一个拥有33个技能的助手，如果把所有技能的详细指令都塞进系统提示词（System Prompt），上下文长度将爆炸，成本高昂且影响推理速度。Skillbot采用了一种巧妙的**动态加载（On-Demand Loading）** 机制。 系统启动时，Skillbot会扫描`skills/`目录下的所有`.md`文件。但它不会把全部内容都加载到内存或提示词中。处理流程如下： 1. **构建技能目录**：提取每个技能文件的Frontmatter（主要是`name`和`description`），生成一个简洁的目录列表。这个目录只有约2K tokens，会被注入到系统提示词的开头，告知LLM“我拥有以下技能”。 ``` 可用技能： - weather: 获取当前天气和预报。 - github: 管理GitHub仓库、Issue和PR。 - docker: 管理Docker容器和镜像。 ... ``` 2. **常驻技能**：仅有少数几个标记为 `always: true` 的技能（如 `memory`, `security`, `context-manager`）的完整内容会被注入系统提示词。它们是助手持续运行的基础。 3. **按需读取**：当用户提出请求，LLM根据技能目录判断可能需要某个技能（如`github`）时，它会主动发出一个“读取文件”的指令。Skillbot的核心引擎会捕获这个意图，然后**动态地**去读取`skills/github.md`文件的全部内容，并将其作为新的上下文提供给LLM。 4. **指令执行**：LLM在阅读了`github.md`的具体指令后，就能生成正确的`gh`或`curl`命令，再通过`bash`工具执行。 这个过程就像是一个工程师在解决问题：先看工具箱的目录（技能列表），找到可能有用的工具（技能名称），然后拿出说明书（技能文件）仔细阅读，最后使用工具（执行命令）。这种设计完美平衡了**提示词长度**和**功能完备性**。 > **注意事项：技能文件的编写规范** > 动态加载机制对技能文件的编写提出了要求： > - **描述要精准**：`description`字段必须一目了然，让LLM能准确判断何时调用该技能。 > - **结构要清晰**：使用清晰的Markdown标题（如`## 列出仓库`，`## 创建Issue`）划分不同功能块，便于LLM快速定位。 > - **自包含性**：每个技能文件应尽可能独立，减少对其他技能文件的隐含依赖。如果必须依赖，需在文件开头明确说明。 ### 3.3 三层安全防护体系 让AI直接执行Shell命令是强大而危险的。Skillbot设计了一个深度防御的安全模型： | 安全层 | 机制 | 配置与说明 | | :--- | :--- | :--- | | **第一层：拒绝列表（Deny-list）** | 硬编码拦截 | 始终启用。包含一系列已知的危险命令模式，如 `rm -rf /`、`mkfs`、`dd` 破坏性操作、`:(){ :\|:& };:`（fork炸弹）等。这是最基本的安全网。 | | **第二层：命令白名单（Whitelist）** | 选择性启用 | 通过 `SKILLBOT_COMMAND_WHITELIST` 环境变量配置。设置为 `default` 会使用内置白名单（涵盖33个技能所需的所有命令，如 `curl`, `gh`, `docker`, `cat`, `grep`, `ls` 等）。也可自定义，如 `curl,git,python3`。**这是生产环境推荐的核心安全策略**，遵循“最小权限原则”。 | | **第三层：工作空间限制（Workspace Restriction）** | 选择性启用 | 通过 `SKILLBOT_RESTRICT_WORKSPACE=1` 启用。将所有文件路径操作限制在Skillbot项目目录内，防止助手意外或恶意操作到系统关键文件。 | **为什么白名单优于黑名单？** 黑名单（拒绝列表）永远在追赶新的攻击方式。攻击者可以使用命令拼接、编码、别名或利用不常见的系统工具来绕过检测。而白名单是“默认拒绝”策略：只允许明确列出的命令执行。只要白名单足够精简，就能极大缩小攻击面。Skillbot内置的`default`白名单是经过精心挑选的，确保了所有自带技能能运行，同时排除了大多数危险或无关的命令。 **生产环境安全配置建议：** ```bash # .env 文件 SKILLBOT_COMMAND_WHITELIST=default SKILLBOT_RESTRICT_WORKSPACE=1

同时，确保运行Skillbot的系统用户权限尽可能低，不要使用root或管理员账户运行。

4. 高级特性：记忆、人格与多通道交互

4.1 基于Markdown的双层记忆系统

大多数AI助手将记忆作为内部状态或数据库条目来处理。Skillbot再次回归文件系统，用Markdown文件构建了一个独特且透明的记忆系统：

• MEMORY.md：长期记忆。存储需要持久化的关键事实，如用户的偏好（“我喜欢用dark mode”）、重要上下文（“正在进行的项目叫‘Phoenix’”）、系统配置等。LLM会在对话中主动读写这个文件。
• memory/YYYY-MM-DD.md：短期/日记记忆。每天自动创建一个新的日志文件，记录当天的完整对话历史。这提供了对话的上下文追溯能力。

记忆技能（memory）是一个always: true的技能，它被注入到每个系统提示中。它的指令教会LLM如何管理记忆：

• 何时保存：当用户提供重要个人信息或做出明确偏好陈述时。
• 保存什么：提取关键事实，以简洁的条目格式追加到MEMORY.md。
• 如何检索：当问题涉及已知信息时，使用grep -i "keyword" MEMORY.md来快速查找。
• 记忆压缩：在对话历史接近上下文窗口限制前，LLM会触发“压缩”操作：将当前会话中的重要信息提炼后存入MEMORY.md或当日日志，然后清空会话历史中的旧内容，腾出窗口继续对话。这模拟了人类的记忆整理过程。

这种文件式的记忆管理好处显而易见：完全透明且可调试。你可以随时用文本编辑器打开MEMORY.md查看助手“记住”了什么，也可以手动修改或清理。它不依赖任何外部数据库，极其轻量。

4.2 可定制的人格与用户画像

Skillbot的人格不是硬编码的，而是由两个Markdown文件定义：

• SOUL.md：定义助手的人格。包括它的名字、说话风格（正式、随意、幽默）、核心原则（如“乐于助人但安全第一”）、行为边界（不做什么）。你可以把它塑造成一个严谨的管家、一个热情的伙伴，或一个高效的顾问。
• USER.md：定义用户的画像。包含用户的姓名、职业、常用工具、技术背景、沟通偏好等。这帮助助手更好地理解对话对象，提供个性化的回复。

这两个文件的内容会被拼接起来，放在系统提示词的最前面。这意味着，改变人格只需编辑一个文本文件并重启服务。例如，你可以创建一个SOUL_cheerful.md和一个SOUL_serious.md，根据需要切换，让同一个代码库运行出不同性格的助手。

4.3 多通道集成与心跳机制

Skillbot的设计允许它轻松接入不同的交互前端：

• CLI（命令行）：默认模式，npm start即可开始对话。
• Telegram/Discord/Slack：通过对应的channel-*.ts适配器，可以将Skillbot变成群聊机器人。只需配置相应的Bot Token，它就能在聊天群组中响应指令。
• iMessage（仅macOS）：通过imsgCLI工具，实现与Mac原生信息应用的集成。

心跳机制（Heartbeat）是一个有趣的主动式功能。通过配置SKILLBOT_HEARTBEAT_INTERVAL（默认30分钟），助手会定期读取HEARTBEAT.md文件。你可以在这个文件里写下需要定期执行的任务指令，例如：

# 每日检查 - 检查GitHub仓库是否有新的重要Issue。 - 查询今日日程安排并提前10分钟提醒。 - 获取今日天气，如果下雨则提醒带伞。

当心跳触发时，LLM会读取这些指令并逐一执行，实现后台自动化任务，让助手从被动的问答机变为主动的管家。

5. 实战：从零构建一个自定义技能

理论说了这么多，我们来实战一下，为Skillbot添加一个实用的新技能：通过jq命令行工具处理和分析JSON数据。这个技能对于开发者和运维人员非常有用。

5.1 技能规划与设计

首先，明确技能目标：让助手能够理解用户对JSON数据操作的描述，并组合使用curl（获取JSON）、jq（处理JSON）和cat/echo（提供JSON）等命令来完成工作。

我们需要涵盖几个常见场景：

1. 从URL获取JSON并提取特定字段。
2. 过滤和筛选数组中的对象。
3. 进行简单的数据计算（如求和、平均值）。
4. 格式化输出。

5.2 编写技能Markdown文件

在项目的skills/目录下，创建新文件json-query.md。

--- name: json-query description: Query, filter, and manipulate JSON data using the jq tool. platform: cross-platform always: false dependencies: jq (can be installed via package managers) --- # JSON Query & Manipulation This skill allows you to work with JSON data from files, APIs, or direct input. It uses `jq`, a powerful and lightweight command-line JSON processor. ## Installation of jq If `jq` is not installed, here's how to get it: - **macOS (Homebrew):** `brew install jq` - **Ubuntu/Debian (APT):** `sudo apt-get install jq` - **Fedora (DNF):** `sudo dnf install jq` - **Windows (Chocolatey):** `choco install jq` - **Or download manually:** from https://stedolan.github.io/jq/ ## Basic Examples ### 1. Reading JSON from a file and extracting a field ```bash cat data.json | jq '.key'

2. Fetching JSON from a URL and extracting nested data

curl -s https://api.example.com/data | jq '.users[0].name'

3. Filtering an array

To get items whereactiveis true:

cat items.json | jq '.[] | select(.active == true)'

4. Mapping and creating new structures

To create a new array with only names and IDs:

cat users.json | jq '[.[] | {name: .username, id: .id}]'

5. Performing calculations

To sum thevaluefield of all objects in an array:

cat records.json | jq '[.[].value] | add'

To calculate the average:

cat records.json | jq '[.[].value] | add / length'

6. Formatting and syntax highlighting

Pretty-print a JSON file:

cat compressed.json | jq '.'

CommonjqPatterns Reference

• .: The entire input.
• .key: Access a field.
• .[]: Iterate over an array (or object keys).
• .[0]: First element of an array.
• select(condition): Filter elements.
• map(.expression): Transform each element.
• length: Get the length of an array or string.
• add: Sum an array of numbers.
• keys: Get the keys of an object.
• has("key"): Check if a key exists.

Important Notes

• jqexpects well-formed JSON. If you get parse errors, check your input.
• You can chainjqoperations using pipes|within a singlejqcall.
• For complex queries, it's often easier to write thejqfilter in a step-by-step manner.
• The input JSON can come fromcat file.json,curl -s API_URL, or directly from a string usingecho '{"a":1}' | jq ..

### 5.3 测试新技能 保存文件后，无需重启Skillbot（部分版本支持热加载，或不需重启）。在CLI中启动Skillbot (`npm start`)，然后进行对话测试：

你： 帮我从这个API https://jsonplaceholder.typicode.com/users 获取所有用户的邮箱，并整理成列表。 Skillbot: （思考过程：识别出需要json-query技能。读取技能文件。理解需要获取JSON并提取email字段。） （执行）我将从该API获取数据并提取邮箱列表。 > bash: curl -s https://jsonplaceholder.typicode.com/users | jq '.[].email' 你： 很好。现在假设我有一个本地的logs.json文件，里面是日志数组，每个日志有level和message字段。我只想看到level为 "ERROR" 的日志。 Skillbot: （识别为json-query技能的过滤操作。） 你可以使用这个命令来筛选ERROR级别的日志： > bash: cat logs.json | jq '.[] | select(.level == "ERROR")'

通过这个简单的例子，我们可以看到，添加一个功能强大的数据处理技能，仅仅需要编写一个结构清晰的Markdown文档。LLM承担了理解自然语言请求、匹配技能、组合命令参数的所有智能工作。 > **避坑技巧：技能文件的调试** > 如果新技能不工作，可以按以下步骤排查： > 1. **语法检查**：确保Markdown文件格式正确，特别是Frontmatter的YAML部分不能有语法错误。 > 2. **描述准确性**：检查`description`是否清晰。LLM主要靠它来匹配技能。可以把它想象成搜索引擎的关键词。 > 3. **示例典型性**：提供的命令示例是否覆盖了核心用例？LLM通过示例学习“模式”。 > 4. **环境依赖**：技能所需的命令行工具（如本例的`jq`）是否已在运行Skillbot的系统环境中安装并位于PATH？可以在技能文件中加入安装指引。 > 5. **白名单**：如果启用了命令白名单，确保新技能用到的命令（如`jq`）已被添加到`SKILLBOT_COMMAND_WHITELIST`中。 ## 6. 部署、配置与生产环境考量 ### 6.1 多模型提供商支持 Skillbot的核心LLM模块抽象得很好，支持多达9种后端提供商，只需配置相应的环境变量即可切换： | 提供商 | 环境变量 | 典型模型 | 适用场景 | | :--- | :--- | :--- | :--- | | **OpenAI** | `OPENAI_API_KEY` | `gpt-4o`, `gpt-4o-mini` | 通用性强，工具调用能力优秀。 | | **Anthropic** | `ANTHROPIC_API_KEY` | `claude-3-5-sonnet` | 长上下文，指令跟随和安全性好。 | | **Azure OpenAI** | `AZURE_OPENAI_API_KEY`等 | `gpt-4` | 企业级部署，需要Azure集成时。 | | **Google Gemini** | `GEMINI_API_KEY` | `gemini-2.0-flash` | 性价比高，响应速度快。 | | **Groq** | `GROQ_API_KEY` | `llama-3.3-70b` | 极致推理速度（LPU硬件）。 | | **本地模型 (vLLM)** | `VLLM_BASE_URL` | `Llama-3.1-8B` | 数据隐私要求高，离线环境。 | **配置示例 (`/.env`)**： ```env SKILLBOT_PROVIDER=openai OPENAI_API_KEY=sk-你的密钥 # 或者使用本地模型 # SKILLBOT_PROVIDER=local # VLLM_BASE_URL=http://localhost:8000/v1

选择模型时，需要权衡成本、速度、上下文长度和工具调用/指令遵循的可靠性。对于Skillbot这类重度依赖工具使用的场景，GPT-4o或Claude 3.5 Sonnet通常是更稳妥的选择。

6.2 生产环境部署建议

将Skillbot用于个人自动化或小团队协作是理想的，但在生产环境部署需要考虑更多：

1. 安全性加固：

   • 强制使用白名单：如前所述，SKILLBOT_COMMAND_WHITELIST=default是必须的。
   • 工作空间限制：设置SKILLBOT_RESTRICT_WORKSPACE=1。
   • 独立用户运行：创建一个专用的、低权限的系统用户来运行Skillbot进程。
   • 网络隔离：考虑在Docker容器或虚拟机内运行，限制其网络访问（例如，只允许访问必要的API端点）。
   • 审计日志：Skillbot的会话是持久化的（JSONL格式），确保日志文件得到妥善保管和定期审查。

2. 可靠性保障：

   • 进程守护：使用pm2、systemd或supervisor来守护Node.js进程，实现崩溃自动重启。
   • 资源监控：监控进程的内存和CPU使用情况，避免内存泄漏。
   • 上下文管理：合理设置SKILLBOT_CONTEXT_WINDOW，并依赖其自动压缩功能，避免因上下文过长导致API调用失败或成本激增。

3. 技能管理：

   • 版本控制：将skills/目录纳入Git管理，方便协作和回滚。
   • 技能审核：建立新技能添加的审核流程，特别是涉及敏感操作（如文件删除、API写操作）的技能。
   • 依赖文档化：在每个技能的Markdown中清晰说明其命令行工具依赖，便于在新环境部署时一键安装。

6.3 性能优化与成本控制

• 模型选择：对于简单、模式固定的任务（如文件操作、信息查询），可以使用更小、更便宜的模型（如gpt-4o-mini）。对于复杂规划和推理任务，再切换到更强模型。
• 提示词优化：保持SOUL.md和USER.md简洁。冗长的人格描述会占用宝贵的上下文令牌。
• 技能描述精炼：技能文件的description要简短准确，技能内部的指令说明则应详细。前者影响匹配效率，后者影响执行准确性。
• 利用心跳：将周期性的、不紧急的批量任务（如数据备份、报告生成）放在HEARTBEAT.md中，利用非高峰时间执行。

7. 常见问题与故障排查

在实际使用和部署Skillbot的过程中，你可能会遇到一些典型问题。以下是一个速查指南：

调试技巧： 启动时添加SKILLBOT_DEBUG=1环境变量，可以打印出详细的决策日志，包括：

• 加载了哪些技能。
• LLM收到了什么样的提示词。
• LLM决定调用哪个工具、参数是什么。
• 命令执行的实际输出。 这对于诊断技能匹配问题或命令生成错误非常有帮助。

Skillbot代表了一种构建AI应用的清新思路：它不试图用代码封装一切，而是选择信任和利用LLM的原生能力与现有的强大工具生态。它将开发者的角色从“编码实现者”转变为“指令撰写者”和“系统设计者”。这种转变大幅降低了为特定领域创建智能助手的门槛，也让系统的可维护性和可解释性得到了提升。当然，这种架构也将其成功押注于LLM工具调用的可靠性和外部命令执行的安全性之上。在目前LLM能力快速演进、安全工具日益完善的环境下，Skillbot无疑为个人和小团队提供了一个极具吸引力的、轻量级且高度可定制的AI自动化解决方案。它的价值不仅在于其现有的33个技能，更在于它开启了一种用自然语言“编程”自动化工作流的新可能。