Agent on Code Plato

Agent Skill 制作手册 01：入门篇

Thu, 28 May 2026 00:00:00 +0000

Agent Skill 制作手册是一个系列教程。这是第一篇。

什么是 skill

很多程序员问，Agent Skill 是什么？我敢说，Agent Skill 是你们学习编程以来能学到的最简单的技术之一。

skill 是怎么发展出来的

就像跟人一起工作一样。你有一个新入职的同事，就算他技术再好，也总要先看一些你们公司的 how to 文档，才能开始做事。人们发现，跟 LLM 工作也有同样的模式。你让 LLM 直接做事情，那多半会做出一件偏离你预期的漂亮事，这就很尴尬了。

然后就有人发现，如果先在提示词里面加上做事情的步骤，LLM 就做得好。所以大家就一直给 LLM 喂 how to 手册。

但是 LLM 的上下文有限啊，而且你每次塞这么多上下文，你的钱包先爆了。于是人们又想，其实我们自己工作的时候也记不住 how to 的内容。我们大概记得有那么个 how to 教了我做这件事情，但具体内容不记得了。没关系啊，我们到时候再去 wiki 看看不就得了。那我们也可以让 LLM 只记住这个 how to 是做什么的，具体需要的时候再看呗。于是我们可以把每一个 how to 的描述喂给 LLM，LLM 看描述就知道，需要做事情的时候要找哪个 how to 了。

到这里，我们已经可以推导出一个简单的、给 LLM 量身定做的 how to 了。它只有两个重要属性：name 和 description，剩下的就是正文了。每次加载只加载 name 和 description，LLM 自己会判断是否需要读取这个 how to 的正文。

这就是 skill。其实这个东西叫什么不重要，它可以叫 howto、guide、manual 都可以，但是大家觉得 skill 这个名字够短、好记，还自解释，就用它了。可能在别的平行宇宙里，它叫 guide。

skill 是哪家的？

这种 SKILL.md 形态的 Agent Skill，最早是 Anthropic 系统公开推广的；但 skill 这个词和"让 AI 学技能"的思想并不属于某家公司。OpenAI、OpenClaw、Hermes Agent 都有自己实现的 skill。这只是一个概念，各家有各家自己的实现，这些实现在细节上有些区别，但都是指同一个事情。

怎么写 skill

skill 通用规范

各家的 skill 规范的共同点是：skill 是一个文件夹。结构是：

my-skill/
 SKILL.md # 必须：元数据 + 指令
 scripts/ # 可选：可执行脚本
 references/ # 可选：文档、说明、规范

而其中的 scripts、references 都不是必须的，只是大家习惯的一种最佳实践而已。最重要的是 SKILL.md。有的 skill 只有这一个文件，而这个文件的结构也很简单。

一个最小的 SKILL.md，在元数据层面只需要 name 和 description。正文可以很短，但最好写清楚 agent 被触发后到底要做什么。

---
name: skill的名字
description: 解释这个skill是干嘛的，什么时候应该被触发，什么时候不应该被触发等
---

当你的 skill 比较复杂，需要一些结构化的数据和逻辑的时候，就可以考虑建立 scripts 文件夹，然后在里面写代码。当你的 skill 引用的文档比较多，你怕把上下文给撑爆了，就可以把大部分文档移到 references 里面。

写一个 skill

来动手写一个 skill 吧。我保证这是你看到的最短的教程。这个 skill 会在你说三次 Hello 的时候回复三个 World。新建 SKILL.md，并在里面写：

---
name: hello-world
description: 当用户说三次"Hello"（例如"Hello Hello Hello"）时，回复三次"World"："World World World"。
---

# Hello World

当用户的消息中包含恰好三个"Hello"时，只回复：

World World World

不说其他任何内容，只有这三个字。

然后安装到你的 AI agent 里面。你问我怎么安装？这都什么年代了，你问你自己的 AI agent 怎么安装，它自会告诉你的。

安装好后就试试吧。

skill 规范

Codex、Claude Code、OpenClaw、Hermes Agent 它们都对 skill 有自己的一些细节上的规范，我就不在此赘述。不过有几点我觉得有必要提。

Skill 防触发机制

基本上，是否触发 Skill 是看 LLM 自己决定的。这其实带来另外一个问题，就是 skill 经常被误触发，或者不被触发。对此各家都有各自的措施。

禁止自动触发，但允许手动触发
- Claude / OpenClaw: disable-model-invocation: true
- Codex: agents/openai.yaml 里的 allow_implicit_invocation: false
彻底禁用 skill
- Codex: [[skills.config]] enabled = false
- OpenClaw: skills.entries.<skillKey>.enabled = false

从这里可以看出，skill 的优点在于自由，但缺点也是自由。有时候你想触发，却触发不了；不想触发，它却一直被触发。不过在之后的教程中我会介绍一些范式来解决这个问题。

Skill 的分类

在 skill 慢慢被越来越多的人使用后，skill 也开始出现一些分类方式。

skill 和 command

在 OpenClaw 和 Claude 桌面版中，skill 是可以用斜杠（/）调用的。区别在于，在 Claude 桌面版中，你安装了 Skill 后，按 / + <skill名> 就可以触发 skill；而在 OpenClaw 中，你是通过设置 user-invocable: true 来让这个 skill 可以用斜杠触发的。

在 OpenClaw 里，一部分 skill 可以被暴露成 slash command。command 是调用方式，不一定是独立分类。这就引发了一个有趣的思考：当你建立一个新 skill 的时候，你可以思考一下，你这个 skill 是一个普通的 skill，还是一个 command。毕竟在手机上找到斜杠，并不像在电脑上这样容易。有些生活类的 skill，你可以依赖 LLM 去猜测；而有些需要精确被触发的，就可以用斜杠。

工作流式和应用式

你会发现，有些 skill 仅仅只是定义了一件事情该怎么做，而有些 skill 更像是一个你自己定义的 app。定义了该怎么做的，可以被称为工作流式。

比如你让 LLM 帮你归纳一下会议纪要。这样的 skill 就只需要 SKILL.md 就够了。如果流程比较复杂，那就把流程抽取到 references 里面。
如果是应用式的，比如你要做一个购物清单，你需要比较复杂的逻辑和比较规范的数据存储。你就需要将某些逻辑抽取出来写成 scripts。但是 scripts 不是越多越好，只有需要确定性行为或外部工具时才用 scripts。

AI时代应该怎么写代码：督导和编排

Wed, 20 May 2026 00:00:00 +0000

程序员的迷茫

程序员这个行业从来没有像现在这么迷茫过。我看到太多不同的说法：

有个老板要求员工的 AI 写代码率必须超过 70%
有的人手写代码，然后让 AI 来写单元测试、做测试
有人在面试时被问到是否用过 Claude Code，会觉得很生气
有人说 vibe coding 是一场赌博
有人说程序员要失业了，我们不再需要程序员了
有人说只要用 TDD、BDD 写出来的项目就会很稳定
有人说 AI 写出来的代码，测试都能通过，但实际一运行就挂掉
有人说 AI 编程是个骗局，只是各大厂商为了卖 token 的营销手段

2 个坏消息

其实这些说法都对了一部分，也错了一部分。我想说两个坏消息：

Cursor 会死，JetBrains 会死，甚至 Copilot 也会死，几乎整个 IDE 产业最后可能都不存在
虽然已经裁了很多程序员了，但裁得还不够

我不喜欢坏消息，但我也不喜欢假装一切都很好。这就像你明明有重大疾病，却不去体检一样。这样只会害了你。

AI 编程的极限

这几个月 AI 编程领域高歌猛进。看起来它似乎是无敌的，最终会统治世界。确实，我们现在对 AI 编程的开发还远远没有到极限。

但是，AI 编程是有极限的。

我们要知道，我们现在用来编程的 AI，其实不是 AGI。我们既然是专业人士，就不要再用"AI"这个笼统的词了。我们真正使用的是大语言模型（LLM）。

大语言模型的工作原理，本质上是预测下一个 token。这跟抽象思维、大局思维、创造力并不是一回事。

所以，大语言模型有几个非常致命的问题：架构偏移、软件熵增、上下文困境、token 滥用。

架构偏移：如果你让 LLM 长时间独立完成一件事情，它最终可能会偏离轨道，走到一个你完全想不到的方向。
软件熵增：如果你让 LLM 自己写一个大型项目，最终很可能会生成屎山代码。实际上甚至不需要大型项目，只要让它写一个稍微复杂一点的模块，都可能出现代码质量失控。我甚至发现，让它帮我写一个类的单元测试，它也能写出屎山代码。
上下文困境：当上下文过长时，LLM 的工作效率会明显下降，因为过长的上下文会让它"分心"。于是你会陷入两难：压缩上下文，会丢失信息；不压缩上下文，LLM 又几乎无法高效工作。你当然可以通过摘要、归档以及渐进式披露来缓解这个问题，但代价就是性能下降。LLM 每做一次修改，都可能需要思考很久。
token 滥用：这是一个非常现实的问题。token 是要付费的，而且并不便宜。你没有无限的 token 可以挥霍。但由于缺乏监管的 AI 容易写出糟糕的逻辑和单元测试，最终会导致你修改逻辑时的 token 消耗越来越高，让维护成本变得越来越昂贵。

程序员的作用

程序员不会失业，但"写代码的程序员"这个职业会逐渐消失。

写代码的方式会彻底改变，而且会分成两个阶段：督导和编排。

督导

有人问，用 AI 写代码的比例多少比较合适。

我的答案是：100%。

当人类开始使用拖拉机播种之后，人工播种的比例是多少？是 0%。

用了 AI 写代码之后，人类已经没有必要继续用缓慢、而且容易拼写错误的方式手写代码。你真正要做的事情，是"督导"。

督导的作用，就是克服 LLM 的那 4 个核心问题。

程序员的大部分时间，将不再是写代码，而是审核 AI 写的代码、提出修改意见，并防止 AI 下次再犯同样的错误。或者指导 AI 用更好的实践去管理代码。

所以，设计模式、代码整洁、代码品味、重构、如何写好的单元测试——这些以前看起来很高级的东西，现在会变成基础能力。

原因很简单，不是为了"优雅"，而是为了一个很现实的目标：

写出可维护、bug 更少、并且节省 token 的代码。

IDE 的终结

但这样一来，其实已经不太需要传统 IDE 了。

因为 IDE 本质上是为了"人类写代码"而诞生的。

如果 AI 写的代码不会出现低级错误，也不需要 auto-complete，而人类自己又不再直接写代码，那么 IDE 中那些辅助人类编写代码、重构代码的功能，其意义就会大幅下降。

未来也许还会有 IDE，但会是非常轻量级的 IDE：秒开、功能简单，只保留一些最基础的能力。

而且这种东西很难再形成高利润产业，因为它太简单了，最终一定会出现大量开源、免费的替代方案。

就像胶卷和录像带租赁行业一样，这个产业最终会逐渐消失。

编排

单独开一个 agent 写代码，效率其实还是不够高。

你可以回忆一下，当你拿到一个新的 requirement 时，你是怎么工作的。

你肯定不是直接开始写代码。

你会先细化需求、设计实现方案，有时候甚至还需要先做 POC 验证方案，然后才开始真正写代码、测试功能。

所以，最终整个软件开发流程都会 AI 化。

但由于上下文问题的存在，又无法让一个 agent 完成所有事情。

注意：这并不是"上下文长度限制"这种可以单纯靠技术升级解决的问题，而是 LLM 工作原理本身带来的限制。

所以，未来真正的开发环境，很可能会变成一个完整的 AI 工作流。

整个工作流中，会有多个不同角色的 AI 工作者：

开发方案设计者 + N 个开发者 + 测试方案设计者 + N 个测试者

之所以没有"需求分析者"这个角色，是因为这部分最好仍然由人类亲自完成。

因为需求分析只要偏移一点点，后面的整个架构就可能彻底偏掉。

但这个工作流并不是搭建完就没事了。

因为如果你让它自己无限制地运行，它绝对会耗费大量 token，最终给你生成一个不可维护的屎山代码库。这就是架构偏移。

虽然 OpenAI 和 Anthropic 都在研究长时间运行的 AI 项目开发，但你可以把这些研究理解成"实验室中的理想环境"。

它们不需要太在意 token 消耗，但你需要。

而且我相信，它们所谓的"长时间运行项目"，本质上也是有督导存在的。人工需要不断增加规则、纠正 AI 的工作方式。

这其实也就是现在越来越多人提到的 Harness Engineering。

于是，程序员最终的工作，就会变成：

搭建、调试并使用这个 AI 工作流。

因为你仍然需要督导 AI。

总结

因为 LLM 在原理上存在一些暂时无法解决的问题，所以程序员这个职业，短时间内仍然会以另一种形态继续存在。

直到真正的 AGI 出现的那一天。

但我还是希望大家尽快开始转型，否则很可能会被这个时代淘汰。

实例讲解什么是上下文治理

Tue, 19 May 2026 00:00:00 +0000

上下文治理（Context Governance）是上下文工程（Context Engineering）中的一个部分。但我觉得，上下文治理是上下文工程里最有意思的部分。

光这么说，你肯定会像我一开始一样，觉得这个概念很抽象。但是，如果你跟我一样，了解了几种主流智能体（Agent）的上下文治理之后，你一定会对"上下文治理"有一个非常直观的理解。

接下来，我会通过比较 4 种智能体的上下文治理方式，让你直观地理解什么是上下文治理。以下四种工具的上下文治理，从简单到复杂、从低级到高级。

Codex

首先是 OpenAI 的 Codex。虽然 OpenAI 是第一个做出 LLM 的公司，但是它们的智能体产品反而最年轻。

虽然它最年轻，但它的上下文治理也是最简单的。在 .codex/ 目录下，有一个叫 AGENTS.md 的文件。这是一个简单的 AGENTS.md 文件示例：

# 仓库规范

## 项目结构
- `src/` 存放应用代码
- `tests/` 存放测试代码

## 常用命令
- 运行测试：`npm test`
- 运行代码检查：`npm run lint`

## 编码规范
- 优先使用 TypeScript
- 避免使用 default export（默认导出）
- 使用 async/await，而不是直接使用原始 Promise

Codex 在开始工作之前，会先读取这个文件的内容。这个文件需要你手动维护，不断往里面添加规则。

除了这个文件以外，还有一个文件夹：~/.codex/memories/ 顾名思义，就是"记忆"。Codex 会自动往里面写文件。

大概的结构如下：

类型	可能内容
summaries	session 摘要
durable	长期稳定记忆
recent	最近上下文
evidence	来源证据

可以看到，Codex 的上下文治理其实非常轻量。

它本质上还是：

一个规则文件
一个自动记忆目录

仅此而已。

Claude Code

Claude Code 的上下文治理很特别。

官方支持的其实跟 Codex 差不多：

CLAUDE.md
~/.claude/projects/<project>/memory/

就这两个东西。你一看名字基本就懂了。但是，Claude Code 的社区自己增强了它的上下文治理，逐渐演化成了这样：

名字	类型	作用	人工/自动
`CLAUDE.md`	文件	项目规则、Agent 行为规则	人工
`MEMORY.md`	文件	长期记忆、长期偏好、长期经验	半自动
`NOTES.md`	文件	临时工作笔记、scratchpad	人工
`DECISIONS.md`	文件	关键架构/技术决策历史	人工
`ARCHITECTURE.md`	文件	系统结构、模块关系、数据流	人工
`LEARNINGS.md`	文件	踩坑经验、经验总结	半自动
`TASKS.md`	文件	当前任务列表、待办事项	人工
`SESSION.md`	文件	当前 session 工作记录	半自动
`docs/`	文件夹	长文档上下文来源	人工
`memory/`	文件夹	memory 分类存储	半自动
`prompts/`	文件夹	prompt 模板、workflow prompt	人工
`.cursorrules`	文件	Cursor 兼容规则	人工

这下就比 Codex 复杂很多了。但是你会发现，这里面有大量文件都需要人工维护。而且整个结构特别像我们以前做项目时写的 Wiki 文档结构。

其实，为了让 Agent 更好地工作，它也应该像我们一样，先看看项目 Wiki。人们现在只是把 Wiki 文档，变成了上下文 Markdown 文件而已。这样理解就很容易了。Claude Code 在这些上下文文档的基础上，工作的方式越来越像一个真正的程序员。

Open Claw

Open Claw 的定位跟 Claude Code 不太一样。它更偏向生活助手。而且 Claude Code 社区版的上下文治理，需要管理的文件太多了。不同于 Claude Code，Open Claw 的用户更多是普通人。很多用户其实并不会直接编辑 Open Claw 的上下文文件，甚至都不知道这些文件需要人工维护。

但是，Open Claw 的上下文设计其实比 Claude Code 社区版更"Agent 化"。因为 Claude Code 社区版的上下文结构，还是带有很强的人类项目管理思维。但在 Agent 面前，其实并不一定需要拆成那么多文档。

Open Claw 的上下文治理更偏向"角色"和"人格"。它有这些上下文文件：

核心指令层（静态，你手动维护）

SOUL.md — 人格、价值观、边界。回答"你是谁"。定义语气、性格、不可违反的约束。
AGENTS.md — 操作流程和规则。回答"你做什么、怎么做"。最大也最重要的文件，放复杂工作流和步骤化指令。
USER.md — 用户信息。你的名字、时区、偏好、工作背景。相当于个性化层。
IDENTITY.md — 结构化身份档案（名称、角色、目标、语气）。用于一致性地重新应用已知身份。（其实我觉得这个有点多余。）
TOOLS.md — 工具文档。不控制权限（权限是 config 管的），而是告诉 Agent 如何使用已有工具。

自动化层

HEARTBEAT.md — 定时任务，相当于用自然语言写的 cron。比如"每 30 分钟检查一次"“每周一 8 点生成报告”。
BOOTSTRAP.md — 首次运行的初始化脚本。setup 完成后会自动删除。
BOOT.md — 每次启动时执行的 hook。

记忆层

MEMORY.md — 长期记忆。持久化的事实、偏好、决策摘要，跨周跨月生效。
memory/YYYY-MM-DD.md — 每日笔记。当天和昨天的笔记自动加载，更早的内容通过 memory_search 检索。
DREAMS.md — dreaming 系统的日记，记录从短期记忆向长期记忆的"晋升过程"，供人类审阅。这是一个实验性功能。

可以看出，Open Claw 已经比前两个系统复杂很多了。所以你在使用 Open Claw 的时候，会明显觉得它"更聪明"。

Hermes Agent

接下来就是重头戏了。如果你不理解上下文治理，你可能会觉得 Hermes Agent 跟 Open Claw 没什么区别。但不知道你有没有发现：Open Claw 里仍然有很多文件需要你手动维护。

甚至就算是我，用了这么久 Open Claw，也是最近才知道这些文件需要人工维护。这就导致 Open Claw 设计的很多上下文，其实一直都没有真正被使用起来。Hermes Agent 的上下文治理跟 Open Claw 和 Claude Code 都不太一样。它的核心设计理念是：

“自我进化”——Agent 自己写自己的记忆和技能。

整个体系住在 ~/.hermes/ 目录下。

身份层（静态）

SOUL.md — system prompt 的第一个 slot，定义人格、语气、价值观、行为边界。这是全局的，从 HERMES_HOME 加载。这个文件你仍然可以手动编辑。

项目上下文层（按优先级，只加载第一个匹配的）

.hermes.md
AGENTS.md
CLAUDE.md
.cursorrules

先找到谁就用谁。

这意味着 Hermes 同时兼容 Claude Code 和 Cursor 的项目配置文件。

记忆层（三层，Agent 自己维护）

MEMORY.md — 长期记忆。存环境信息、项目惯例、工具使用经验。
USER.md — 用户档案。存你的名字、沟通偏好、技能水平。注意，这回 USER.md 已经变成自动维护了。
state.db — SQLite 数据库，带 FTS5 全文索引，存所有历史消息。Agent 不会默认全部加载，而是在需要时通过 session_search 按需检索。

这时候，记忆已经开始进入数据库时代了。因为只有数据库，才能真正支撑长期上下文检索。

技能层（Hermes 最独特的部分）

skills/ 目录 — 每个技能都是一个文件夹，里面包含一个 SKILL.md（带 YAML frontmatter），以及可选的模板和脚本。

关键区别在于：

技能不是人类写的。Agent 在完成非平凡任务之后，会通过 skill_manage 工具自己创建技能。同样，记忆也不再主要依赖人类维护。Agent 会在对话间隙，自己编辑 MEMORY.md 和 USER.md。而且技能是按需加载的。不用的技能不会进入上下文。这其实已经开始接近真正的"上下文自动治理"了。

调度层

cron jobs — 定时任务，类似 Open Claw 的 HEARTBEAT.md。

到了这一步，上下文治理不仅变复杂了，还开始自动化了。

总结

AI 是否真的能干活、干得好不好，已经不仅仅是模型之间的区别了。很多时候，更好的上下文治理，对智能体工作效率的提升，甚至比你换一个更强的模型还明显。

电子脑

随之而来的，还有一个很有意思的问题：上下文，其实就是智能体的"电子脑"。一个 Agent 用久了，那份上下文就会逐渐变成独一无二的它。只要上下文还在，就算换了一个"壳"，你的小助手还是你的小助手。如果智能体坏了需要重装，或者你想迁移到另一个智能体平台，只要把上下文迁移走，你的助手理论上就还能继续存在。

于是，一个新的问题出现了：如何安全地迁移上下文？

但现在的问题是：各家之间的文件名、结构、格式都完全不同。这就导致上下文迁移非常麻烦。我相信，未来一定会出现更统一、更标准化的上下文协议。而"上下文治理"，也会逐渐成为 AI Agent 最核心的能力之一。

基于 LLM 的 AI 智能体架构：一台长在你设备里的新型电脑

Tue, 05 May 2026 00:00:00 +0000

基于 LLM 的 AI 智能体架构：一台长在你设备里的新型电脑

过去，我们一直把 AI 理解成一个"聊天机器人"。

但如果从系统架构角度重新观察，会发现未来真正成熟的 AI 智能体，更像是一台安装在你设备里的新型个人电脑。

它拥有：

计算核心
内存
文件系统
软件系统
输入输出设备
长期存储

只是：

它的核心不再是传统 CPU，而是 LLM。

一、LLM 引擎：没有记忆的"CPU"

LLM 本身其实没有长期记忆。

它更像一个推理引擎：

接收输入
读取上下文
进行推理
输出结果
然后"失忆"

它无法天然记住过去发生的事情。

因此：

LLM 本身更像 CPU，而不是完整的智能体。

它只负责计算。

真正让 AI “看起来认识你"的，是外部为它提供的上下文。

二、上下文：AI 智能体的内存

如果 LLM 是 CPU，
那么 Context（上下文）就是 AI 的内存。

而这个内存，其实应该分成两层。

1. 全局上下文（Global Context）

这一层属于整个智能体。

它记录：

用户偏好
长期目标
常用习惯
人格设定
长期规则
历史知识

例如：

“用户喜欢 Markdown”
“用户正在学习 AI Agent”
“用户习惯使用中文写作”

这些信息会长期影响智能体行为。

2. 会话上下文（Session Context）

这一层只属于当前对话。

例如：

当前正在讨论的话题
当前文章结构
最近几轮对话
临时推理结果

它更像程序运行时的临时内存。

上下文窗口，本质上是"内存限制”

LLM 的 Context Window 并不是无限的。

这意味着：

历史不能无限累积
信息会越来越贵
超过限制后必须被压缩

于是：

智能体必须像操作系统一样管理内存：

压缩历史
总结摘要
清理低优先级信息
转移长期信息
动态加载需要的数据

因此：

Context Window 本质上就是 AI 的内存容量。

三、Markdown 文件：智能体的硬盘

长期数据不应该一直放在上下文里。

否则：

成本会越来越高
推理速度会下降
Context 会迅速膨胀

因此：

长期记忆应该存在文件系统中。

而一种非常自然的形式，就是 Markdown 文件。

例如：

笔记
项目资料
日记
世界观
用户档案
写作素材
长期知识库

都可以直接存成 Markdown。

这意味着：

传统电脑	AI 智能体
硬盘	Markdown 文件系统

Markdown 有一个巨大优势：

它既能被 AI 阅读，也能被人类直接阅读。

因此：

人类可以编辑
AI 可以处理
Git 可以版本管理
文件可以同步
即使脱离 AI 依然存在

这会形成一种：

“人与 AI 共用的知识空间”。

四、Skill：安装在 AI 上的软件

未来的 AI 智能体，不会只有"知识"。

它还会拥有"技能"。

例如：

写作 Skill
编程 Skill
视频剪辑 Skill
数据分析 Skill
项目管理 Skill

这些 Skill 可能由：

Prompt
工作流
Python 代码
MCP 配置
Tool 调用规则

共同组成。

它们就像：

安装在 AI 身上的软件。

因此：

传统电脑	AI 智能体
软件 / App	Skill

Skill 可以：

安装
卸载
更新
共享
组合

未来甚至可能出现：

Skill Store
Skill Marketplace
开源 Skill 社区

五、输入输出：不只是文字

传统聊天机器人最大的误导之一，是大家以为 AI 只有文字交互。

实际上未来的 AI 智能体，会拥有完整的多模态输入输出系统。

输入

AI 可以读取：

文字
语音
图片
视频
摄像头
文件
屏幕内容
设备状态

输出

AI 可以生成：

文本
语音
图像
视频
自动化操作
控制指令

因此：

AI 智能体本质上是一种新的交互层。

电脑整机：一种"类冯诺依曼结构"的 AI 计算机

如果把整个架构放在一起：

传统计算机	AI 智能体
CPU	LLM 引擎
内存	Context
硬盘	Markdown 文件系统
软件	Skill
输入设备	多模态输入
输出设备	多模态输出

你会发现：

它已经越来越像一台真正的计算机。

只是：

这台计算机不是围绕 GUI 构建的。

而是围绕：

“语言理解与推理”

构建的。

操作系统：个人 AI 操作系统

未来每个人设备中，都可能长期存在一个 AI Agent。

它：

理解你
记住你
帮助你工作
管理你的知识
调度你的 Skills
操作你的设备
与你长期共同成长

那时：

我们使用的可能不再只是：

Windows
macOS
Android

而是：

一个以 LLM 为核心的新型个人 AI 操作系统。

而今天的聊天框，

可能只是这个新时代最早期的雏形。

参考资料

Park, Joon Sung et al.
MemGPT: Towards LLMs as Operating Systems
arXiv:2310.08560
https://arxiv.org/abs/2310.08560
Wang, Lei et al.
LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem
arXiv:2312.03815
https://arxiv.org/abs/2312.03815