# 技能 > **“技能是学会做事的文档。”** 元协议：技能如何发挥作用、如何发展、如何组合，以及 MOOLLM 如何推进最先进的技术。 ** ** ## 基金会：我们与 Anthropic 分享的内容 MOOLLM 技能建立在 Anthropic 卓越的技能模型基础之上：人择原理| MOOLLM 实施 |分享原因 ---|---|--- **文档优先** | `README.md` \+ `SKILL.md` |自动化之前先解释一下 **工具定义** | YAML frontmatter + `CARD.yml` |机器可读规格 **可组合性** |原型继承+燕尾榫|从简单到复杂 **人门** | “计划-然后-执行”协议 |信任但验证 **技能库** | `skills/` 目录 |中央、可共享 **基础是健全的。** MOOLLM 对其进行了补充（请参阅下面的第 1-10 节）。 ** ** ## MOOLLM 的独特贡献 ### 1\.技能原型（自我继承） > _“物体一直向下。”_ — David Ungar 传统技能是静态文档。 **MOOLLM 技能是创建实例的原型：** # 原型（技能）技能/冒险/ ├── SKILL.md # 文档 ├── CARD.yml # 接口 └── *.tmpl # 模板 # 实例（由技能创建）例子/冒险-4/ ├── ADVENTURE.yml # 从模板实例化 ├── 角色/ # 游戏过程中填充 ├── pub/ # 一个房间实例 └──sessions/#随时间变化的状态 **为什么这很重要：** * 技能不仅仅是文档——它们是**工厂** * 实例继承自原型但可以重写 * 状态存在于实例中，行为存在于原型中 * 对原型的更改会自动增强所有实例请参阅：[delegation-object-protocol.md]() ** ** ### 语义图像金字塔：多分辨率阅读就像计算机视觉中的图像金字塔一样，技能和实体具有**多种分辨率**以满足不同的需求：流程图TB 子图 GLANCE [“👁️ GLANCE（~5-70 行）”] G["INDEX 条目或 GLANCE.yml
'这相关吗？'"] 结束子图 CARD ["📇 CARD.yml (~50-200 行)"] C["接口、方法、广告
'它能做什么？'"] 结束子图 SKILL ["📜 SKILL.md (~200-1000 行)"] S[“完整协议，示例
'它是如何工作的？'”] 结束子图自述文件 [“📚 自述文件 + 资源（~500-5000+ 行）”] R[“深层背景、历史、基本原理
'为什么建造它？'”] 结束 G --> C --> S --> R **GLANCE 是眼球** — 最小的有用单位： * 对于技能：INDEX.yml 条目（每个技能约 5 行） * 对于字符：GLANCE.yml（~50-70 行 vs 941 行） * 对于房间：GLANCE.yml（~50-70 行 vs 930 行） **阅读顺序（自上而下）：** 水平|文件|线路 |使用时间 ---|---|---|--- 👁️ 浏览 | INDEX.yml 条目 / GLANCE.yml | 5-70 | “这是什么？”快速扫描 📇 卡 |卡.yml | 50-200 | “它能做什么？”接口检查 📜 技能 |技能.md | 200-1000 | “它是如何运作的？”协议详情 📚 深 | README.md + 资源 | 500-5000+ | “为什么？”完整的上下文 **规则：** 在未先加载上一层的情况下，切勿加载下一层。 **对于启动优化：** * Skills/INDEX.yml 让您了解所有 110 多种技能 * 仅加载您将使用的技能的卡片 * 仅当您需要协议详细信息时才加载技能 * 仅加载考古学的自述文件请参阅：[bootstrap/SKILL.md]() 了解 GLANCE 协议 ** ** ### 2\.卡牌：可玩的功能包技能成为可以玩、交易、收集的**卡牌**： # CARD.yml — 接口契约卡： ID：冒险名称：《文字冒险》类型：[技能、游戏、叙事] 表情符号：🎲 稀有度：稀有方法：探索：{描述：“移动到相邻的房间”} 检查：{描述：“看一些东西”} TAKE: { 描述: "拿起一个物体" } 广告：叙事探索：得分：90 条件：“想要互动小说” **为什么这很重要：** * 清晰的接口契约 * 广告功能（如模拟人生对象！） * 可播放、堆叠、组合 * 机器可读的编排 ** ** ### 3\. K 线：作为激活向量的名称 > _“K 线是一种线状结构，当你解决问题时，它会附着在任何活跃的心理机构上。”_ — 马文·明斯基当您按名称调用技能时，您会激活其**整个知识上下文**： > 将 YAML-JAZZ 应用于此配置。 # 这个单一名称激活： # - 语义评论哲学 # - 具体语法模式 # - 示例和反模式 # - 情感基调（爵士乐、即兴创作） # - 相关概念（POSTEL、soul-chat） **当你实例化一个角色时，他们的名字就变成了他们的 K 线。** “Palm”激活了 Palm 的一切——历史、个性、目标、关系、化身故事。 **为什么这很重要：** * 名称不仅仅是标签——它们是**语义激活** * 上下文来自调用 * 相关概念自动可用 * 法学硕士的联想记忆对我们有用 ** ** ### 4\.环境技能：始终在线的行为塑造 > _“就像持续清洁的空气过滤器，而不仅仅是在闻到烟味时才清洁。”_ 有些技能应该是“悬而未决”的——始终可用，始终在无需明确调用的情况下塑造输出。这些是**环境技能**。 **关键见解：** AMBIENT 是一种广告类型！这非常适合，因为： * 广告已有分数和条件 * 编排器已经知道如何处理广告 * 它在语义上是准确的——该技能实际上是在宣传“我想要处于上下文中” **声明环境技能：** # 在 CARD.yml 中广告： # 定期广告（按需调用）创造技能：得分：90 条件：“需要创建新的可重用功能” # 环境广告（始终在上下文中）环境： Score: 100 # 上下文预算的优先级条件：always # 或者：“编写 YAML 时” scope: session # 持续多长时间决议：摘要 # 上下文中需要保留多少内容 **环境广告字段：** 领域 |选项|含义 ---|---|--- `分数` | 0-100 |上下文预算的优先级（更高=保留更长时间） `条件` | `always`，条件字符串 |何时激活 `范围` | `会话`、`对话`、`房间`、`仅卡` |持续时间 `决议` | `完整`、`摘要`、`嗅探`、`仅卡` |装载多少 **环境技能示例：** # no-ai-slop：始终开启，语法卫生环境：得分：100 条件：始终范围：会话决议：仅卡片#只是主要罪恶清单 # yaml-jazz：编写 YAML 时环境：得分：90 条件：“编写或编辑 YAML 文件时” 范围：对话决议：摘要 # 表征伦理：模拟真人时环境：得分：95 条件：“当描绘真实人物或敏感话题时” 范围：对话分辨率：全 **编排行为：** 协调器通过以下方式处理 AMBIENT 广告： 1. **收集** ：从加载的技能中收集所有 AMBIENT 广告 2. **评估**：根据当前上下文检查条件 3. **排序** ：按分数排序（优先级最高的在前） 4. **加载**：在其声明的分辨率中包含技能，直到上下文预算耗尽 5. **刷新**：重新评估环境变化（新房间、新主题等） **标准架构的优势：** 由于 CARD.yml 遵循 **标准架构** ，因此智能编排器可以： 1. 以编程方式解析所有广告 2.自动查找AMBIENT声明 3. 在没有法学硕士干预的情况下实施它们 4. **将它们无形地注入LLM的大脑** 这就是“神奇位置”原则——编排器知道要查看的结构化位置（如“advertisements.AMBIENT”）。 **两种模式：聪明与愚蠢的协调器** 协调员|环境处理|法学硕士经验 ---|---|--- **MOOCO（智能）** |驱动程序解析CARD，自动注入|隐形——“我会把它们注入你的大脑” **光标（哑）** |咨询模式，手动热榜|可见——LLM手动管理上下文 **智能编排器（MOOCO）承诺：** 定制司机对法学硕士说： > _“不用担心用文件工具看环境技能。_ _我会把它们源源不断地注入你的大脑。”_ 法学硕士从来没有见过这个机制。卡就在那里。总是。 **愚蠢的协调器（光标/克劳德代码）后备：** 我们无法控制这些协调器，因此： 1. **在 CARD.yml 中声明 AMBIENT** — 该技能宣传其环境性质 2. **手动热门列表** — 将重要的卡片保留在 `.moollm/hot.yml` 或工作集中 3. **分辨率字段** — 技能声明要保留多少页面（“仅卡片”、“摘要”、“完整”） 4. **信任 LLM** — 一旦 CARD 处于上下文中，LLM 就知道应用其约束这是“放下挑战”的架构：**如果你想要环境，定义一个环境广告。** 该机制适应协调器。 **为什么不使用单独的 AMBIENT.yml？** 我们考虑了分层唤醒系统： * `AMBIENT.yml` — 压缩激活文件（始终分页） * 触发加载 `SKILL.md` → 资源 → 模板 * 动态评分、上下文门、资源包 **被拒绝的原因是：** * 标准 CARD.yml 架构已支持智能编排 * 智能编排器可以直接从CARD解析广告 * 愚蠢的协调器无论如何都需要手动管理 * 一个文件 (CARD.yml) 可在两种模式下工作 * 现有的广告系统已经完美解决了前提条件、分数、优先级的问题，所以我们不必为AMBIENT.yml重新实现它 **设计优雅：** 相同的 CARD.yml，不同的运行时： * **MOOCO** ：Orchestrator 读取 AMBIENT 广告并注入它们 * **光标** ：咨询模式，LLM手动管理 * **未来自定义**：任何编排器都可以解析标准模式 **空气净化器的比喻：** 类型 |它过滤什么 |条件 ---|---|--- `没有-ai-slop` |句法污泥|总是 `无ai光泽` |语义污泥（委婉说法）|总是 '波斯特尔' |稳健性失败 |总是 `yaml-爵士乐` |错误的 YAML 结构 |编写 YAML 时 `代表伦理` |有害的描述|模拟人的时候 **为什么将环境作为广告：** 1. **统一机制**：不需要特殊的“环境”字段——只需一个特殊的广告 2. **自然评分**：上下文预算分配使用现有的优先级系统 3. **条件激活**：与其他广告相同的条件评估 4. **可组合**：环境广告通过正常评分与其他广告互动 **`no-ai-*` 命名空间：** 强制执行行为边界的环境技能遵循“no-ai-*”命名模式： no-ai-slop: # 语法卫生环境：{ 得分：100，条件：始终 } no-ai-gloss: # 语义卫生环境：{ 得分：100，条件：始终 } no-ai-sycophancy: # (未来) 社会卫生环境：{ 得分：95，条件：始终 } 这些是**环境拒绝**——防止特定伤害的始终存在的约束。 ** ** ### 5\.同理心模板：智能实例化 > _“模板能够理解您的意思，而不仅仅是您所写的内容。”_ 传统模板：`{{name}}` → 文字替换同理心模板：`{{describe_character}}` → **智能生成** # 模板描述：| {{describe_appearance_based_on_species_and_personality}} # 上下文品种：“金毛混合犬” 性格：[“热情”、“忠诚”、“愚蠢”] # 生成描述：| 饼干是一种蓬松、永远快乐的金毛猎犬与眼睛里闪烁着无限的热情。他的尾巴在一个持续的摇摆状态，毛茸茸的快乐节拍器。 **为什么这很重要：** * 不是字符串替换 — **语义生成** * LLM 在实例化过程中增加价值 * 上下文决定内容 * 结果是连贯的，而不是机械的请参阅：[../empathic-templates/]() ** ** ### 6\.多层状态持久化技能在多个级别上保持状态（这是 MOOLLM 所独有的）：等级 |地点 |寿命 |使用 ---|---|---|--- **平台** |光标会话 |短暂的|工作记忆 **叙述** | `LOG.md`、`TRANSCRIPT.md` |主要阅读 |数据孤岛、事件 **状态** | `*.yml` 文件 |读写|角色、房间、库存 **数据岛：** 使用“#object-id”寻址嵌入日志中的对象： # LOG.md 嵌入对象 — 可寻址为 LOG.md#session-artifact id：会话工件类型：技能输出模式_发现： - “API 需要 auth 标头” **升级模式：** 如果需要编辑，则升级为`.yml`文件。 **为什么这很重要：** * 正确的数据持久化 * 日志保持只读（审计跟踪） * 状态文件是可变的（世界状态） * 高效的上下文管理 ** ** ### 7\.光速：经过验证的多智能体模拟 > _“一次调用多次。即时通信。无需往返。”_ 这不是理论上的。 **我们已经证明了它：** 示范|转 |代理|证明 ---|---|---|--- **Stoner Fluxx 游戏** | 33 | 33 8 个以上字符 |完整的游戏状态、抽牌、规则更改 **猫午夜徘徊** | 21 | 21 10 只猫 |平行路径、领土标记、统一 **棕榈的化身** | 1 | 1 + 法庭 |通过委员会辩论进行完整的角色创建 # 一次 LLM 通话中 33 轮 Stoner Fluxx： # - 安迪和克里斯汀·鲁尼玩自己的游戏 # - 规则更改（手牌限制 2、抽奖 3、全部玩） # - 目标卡（和平、420、吃零食） # - 8 名球员的守门员管理 # - 自然的对话和笑话 # - 始终保持一致的状态 **为什么这很重要：** * 外部多代理系统：Agent A → API → Agent B → API → ... * MOOLLM：单个调用模拟所有代理的辩论、决定 * **速度提高 10 倍，成本降低 10 倍，完美的一致性** * 对抗委员会、整体推理、真实审议请参阅：[../speed-of-light/]() ** ** ### 8\.道德框架：基于房间的上下文继承 > _“房间决定了表演。里面的一切都继承了它的框架。”_ 当你进入一个空间时，你继承了它的道德和表演背景： # 酒吧/ROOM.yml 房间：名称：格泽利海德石窟取景：模式：【表演、庆典、致敬】继承给孩子：true 描述： | 这是一个表演和庆祝的场所。这些墙内的一切都被理解为： - 社交游戏 - 娱乐与表达 - 致敬表演——向我们敬佩的人致敬这意味着什么：辩论：“争论是运动，不是战争” 表演：“舞台是开放的，判断是仁慈的” 致敬：“我们将那些我们钦佩的人视为充满爱的模拟” **为什么这很重要：** * 酒馆中的角色自动继承“表演模式” *致敬模仿被视为庆祝，而不是欺骗 * 道德背景从房间流向所有儿童 * 无需在每个分室重复取景 **示例：** 当 Palm 在酒吧中扮演安迪·鲁尼 (Andy Looney) 时，房间的框架使其明确成为_致敬_ — 著名的粉丝表演，而不是欺骗性的模仿。请参阅：[../representation-ethics/]() ** ** ### 9\.房间、角色和物体的技能在 MOO 传统中，一切都可以以多种方式体现。 MOOLLM 技能是**三元**： **作为房间（探索空间）：** > 输入冒险技能您在冒险工作室。出口：酒吧、迷宫、人物画廊对象：房间模板、NPC 目录、谜题设计 **作为角色（咨询专家）：** > 向冒险专家询问谜题设计 “考虑锁和钥匙的模式：玩家在里面找到钥匙 A房间，用它来解锁B房间的门……” **作为对象（使用工具）：** > 以房间建造者为例现在你有了房间建造者。 > 在森林清理中使用房间构建器使用 ROOM.yml 模板创建森林清理/... **三元技能的卡片结构：** 卡：名称：冒险作为房间：描述：“构建文本冒险的研讨会” 出口：[酒吧、迷宫、模板] 对象：[房间建造者、NPC 工厂、拼图套件] 作为字符：描述：“互动小说设计专家” 专长：[谜题设计、节奏、氛围] 性格：“有创意、有趣、鼓舞人心” 作为对象：描述：“创建冒险游戏的工具” 动词：[创建房间、生成NPC、设计谜题] 便携：真实 ** ** ### 10\.代码库作为可导航的世界像 Cursor 这样的现代 IDE 可以安装多个存储库。每个代码库都成为一个可导航的世界： * **目录是房间** — 输入 `@central/apps/insights/pyleela/brain/` * **文件是对象** — 检查 `Schema.py`，查看它的类和函数 * **功能是房间** - 输入“createSyntheticItemIfNeeded”以将焦点集中在那里 * **角色有代码位置** — `location: "@repo/path/file.py:142"` * **各方共同探索** — 在一次法学硕士通话中进行多专家代码审查 **位置路径语法：** @repo/path/to/file.py # 文件 @repo/path/to/file.py:42 # 具体行 @repo/path/to/file.py:42-67 # 行范围 @repo/path/dir/ # 目录（房间） **参见：** * [room/]() — 目录作为房间，文件作为带有房间的对象 * [character/]() — 代码位置、基于团队的审核 ** ** ## 游戏-学习-提升循环每项技能的发展都经历三个阶段： # 玩 → 学习 → 提升循环技能进化：玩：行动：“手动执行。探索。犯错误。” 例如：“A 房间里掉了奶酪……” 学习：行动：“注意模式。记录它们。” 例如：“每个房间都需要一个独特的标记......” 电梯：行动：“提取可重复使用的技能。分享它。” 结果：技能：“迷宫绘图” 程序：“在每个房间中放置独特的物品” **文档→程序→脚本→工具** 这是系统化的**演示编程**。请参阅：[../play-learn-lift/]() ** ** ## 技能剖析（所需结构）每个技能目录包含：技能/ 我的技能/ README.md # 人类入口点（GitHub 渲染） SKILL.md # 带有 YAML frontmatter 的完整规范 CARD.yml # 机器可读的接口 *.tmpl # 根级别的模板（可选）文件 |目的|必填 ---|---|--- `自述文件.md` |人性化登陆页面 | ✓ `技能.md` |带有 YAML frontmatter 的完整规范 | ✓ `CARD.yml` |界面：方法、工具、状态、广告 | ✓ `*.tmpl` |实例化模板|可选 `*.py` |自动化姐妹脚本 |可选 ### 为什么 README.md （不同意 Anthropic） Anthropic 建议不要使用技能中的“README.md”。我们谨表示不同意： * **GitHub 将 README.md** 作为登陆页面 * **人类在调用技能之前会浏览技能** * **游戏-学习-提升**从探索开始 * **两个受众**：人类（自述文件）和法学硕士（SKILL.md + CARD.yml） **保留两者。** README 用于发现，SKILL.md 用于执行。 ### 发布和元数据（MOOLLM 技能）技能可以独立发布（技能目录的 zip 或裸 SKILL.md）。 **政策：** [designs/SKILL-PUBLISHING-POLICY.md]()。简而言之：（1）**独立**——SKILL.md 必须单独工作；不要依赖 CARD/README 来执行关键行为。 (2) **相关技能** - 在 frontmatter 和正文中的一小部分中记录“相关”和可选的“benefits_from”。 (3) **MOOLLM 的一部分** — 包括标准简介：直接指向 GitHub 上该技能的目录根（这样任何 LLM 都可以浏览并获取完整的技能目录）；提及一次存储库和技能/自述文件。放置遵循狗屁股嗅探：可选的最短线在开始（扫视），完整部分在结束。请参阅政策了解理由。 (4) **元数据** — Core = `name`, `description`（兼容人类/特工技能）； MOOLLM 扩展 = `允许的工具`、`权限`、`相关`、`许可证`、`标签`、`积分`、可选的`moollm`。覆盖范围是根据权限推断的。完整的 MOOAM 模型（IAM 风格）：[designs/MOOAM.md]()。此技能中的模板已包含简介和元数据提示。 ### 图表：按受众划分的格式不同的文件服务于不同的受众。相应地选择图表格式：文件 |主要受众|最佳格式|为什么 ---|---|---|--- `技能.md` |法学硕士 | **YAML 爵士乐** |结构化、可解析、可嗅探 `自述文件.md` |人类 | **美人鱼** |由 GitHub 渲染，视觉两者 | — | **不是 ASCII 艺术** |浪费代币，难以维护 **SKILL.md — 法学硕士 YAML Jazz：** # 法学硕士立即解析此内容数据流：输入：“用户请求” 步骤： - 行动：“解析意图” 输出：“结构化命令” - 行动：“执行” 输出：“结果” 输出：“格式化响应” **README.md — 人类和好奇的法学硕士的美人鱼：** 图LR A[用户请求] --> B[解析意图] B --> C[执行] C --> D[响应] **为什么不是 ASCII 艺术：** # ❌ ASCII 艺术浪费令牌并且容易损坏 ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 输入 │────►│ 处理 │────► 输出 │ └──────────┘ └──────────┘ └──────────┘ ASCII 艺术是： * **令牌昂贵** - 框字符，对齐填充 * **脆弱** - 编辑中断，难以维护 * **非结构化** — 法学硕士无法解析关系 * **装饰性** - 看起来很漂亮，但不携带语义数据 YAML Jazz 是： * **紧凑** — 无装饰开销 * **可解析** — 法学硕士直接提取结构 * **可维护** — 添加/删除项目而无需重绘 * **语义** — 键和值具有意义美人鱼是： * **渲染** — GitHub/GitLab 显示实际图表 * **版本可控** — 文本差异有效 * **富有表现力** — 流程图、序列、状态机 * **人类优化** — 视觉理解 ** ** ## 扁平化到结构化的增长技能可以从简单开始，逐渐变得有条理： ### 第一阶段：平坦的开始技能/我的技能/ ├── 自述文件.md ├── 技能.md ├── CARD.yml └── helper.py ### 第 2 阶段：根据需要添加结构技能/我的技能/ ├── 自述文件.md ├── 技能.md ├── CARD.yml ├──scripts/ # 当你有多个脚本时 │ └── helper.py ├── templates/ # 当你有多个模板时 │ └── INSTANCE.yml.tmpl └──references/ # 当你有支持文档时 └── 算法.md ### 第 3 阶段：实例库模式 **技能可以有一个用于可重用实例的子目录！** 技能/增益/ ├── 自述文件.md ├── 技能.md ├── CARD.yml ├── BUFF.yml.tmpl # 新buff的模板 └── buffs/ # ← 可重用实例库！ ├── fire-resistance/ # 实例作为目录 │ └── BUFF.yml ├── haste.yml # 实例作为单个文件 └── INDEX.yml # 多个实例捆绑 **三种组织风格（均有效，自由组合）：** 风格|何时使用 |示例 ---|---|--- **目录** |具有资产的复杂实例 | `buffs/耐火/BUFF.yml` **单个文件** |简单的独立实例| `buffs/haste.yml` **INDEX.yml** |许多小的相关实例| `buffs/INDEX.yml` 有 20 个 buff **该模式适用于许多技能：** 技能/buff/buffs/ # 增益库技能/角色/角色/ # 角色原型技能/房间/房间/ # 房间模板 Skills/object/objects/ # 对象原型 Skills/image-mining/images/ # 可挖掘的图像 Skills/adventure/adventures/ # 冒险模板 **INDEX.yml 捆绑示例：** # 技能/buff/buffs/INDEX.yml # 一个文件中的多个实例增益：耐火性：名称：《防火》持续时间：10 效果：“免疫火焰伤害” 赶紧：名称：《急速》持续时间：5 效果：“+2速度，额外行动” 隐形：名称：《隐形》持续时间：8 效果：“除非攻击否则看不见” Breaks_on：[“攻击”，“cast_spell”] **引用库实例：** # 来自世界任何地方性格：增益： - 参考：技能/buff/buffs/fire-resistance.yml - 参考：技能/buff/buffs/INDEX.yml#haste **为什么这很重要：** * 技能是产生实例的工厂 * 实例库是预制产品的目录 * 用户可以浏览、复制或引用现有实例 * 通过示例教授技能（玩-学-举！） **规则：** 顶级 `SKILL.md` 引用所有文件，无论嵌套如何。没有等级狩猎。 ** ** ## 前端嗅探法学硕士可以通过阅读前 50 行来有效地理解技能： # 技能标题（第 1-15 行） --- 名称：我的技能描述：“一行摘要” 权限：[文件] 允许的工具：[读文件，写文件] 相关：[房间、卡片、角色] --- # 目的（第 16-25 行） # 我的技能 > 一行哲学 ## 它的作用简要说明... # 文件映射（第 26-40 行） ## 本技能中的文件 - `README.md` — 登陆页面 - `CARD.yml` — 接口定义 - `scripts/helper.py` — 自动化工具 - `templates/INSTANCE.yml.tmpl` — 实例化模板 **为什么这很重要：** * 法学硕士不需要阅读所有内容 * Front-matter 总结能力 * 文件地图显示可用内容 * 50 行 = 上下文高效的发现 ** ** ## Python 脚本：双受众结构当技能包括 Python 时，人类和法学硕士的结构： #!/usr/bin/env python3 “”“我的技能：简要描述。该文档字符串变为 --help 并且对 LLM 可见。用法： python my-skill.py [命令] ”“” # 导入（第 8-15 行）导入点击从 pathlib 导入路径 # 常数（第 17-25 行） DEFAULT_ROOM =“开始” VALID_COMMANDS = [“探索”、“检查”、“采取”] # CLI 结构（第 27-50 行） @click.group() def cli(): """主入口点。""" 通过 @cli.command() @click.argument(“目标”) def 检查（目标：str）： “”“仔细看看某件事。”“” ... # 实现（第 52 行以上） # LLM 仅在需要实现细节时才阅读此内容消费者 |他们读什么 ---|--- **人类** | `./tool.py --help` **法学硕士** |前 50 行（导入、常量、CLI 结构） **DRY：** 作为代码编写一次的命令结构。没有重复的文档。 ** ** ## 实例化模式技能并不总是需要完全实例化：模式|文件？ |坚持|何时使用 ---|---|---|--- **提到** |没有 |无 |快速调用：“在此申请POSTEL” **建模** |没有 |仅聊天 |对话中的引导探索 **嵌入式** |在文档中 |文件|设计讨论（文学编程） **实例化** |是的 |完整|运行带有状态的实例 **启动灯光，需要时实例化。** ** ** ## 技能构成技能组成类似的函数：技能：名称：《冒险探索》组成： - 房间#导航 - 卡# 库存 - Soul-chat # NPC对话 - action-queue # 代理行为 - speed-of-light # 多智能体模拟编排： - “利用活动空间” - “使用卡片购买物品” - “用心灵对话进行对话” - “对整体场景使用光速” **简单构建块的复杂功能。** ** ** ## 本地技能的出现技能可以从游戏中产生并被捕获： # 播放后在player.yml中学到的技能： - 名称：格鲁-避免 learnt_from：“死了 7 次” 技巧：“在进入黑暗的房间之前一定要检查灯” can_lift_to：技能/避免惊慌/ - 名称：供应商讨价还价 learn_from：“购买灯油” 技巧：“批量购买，先检查黄金” local_only: true # 太具体而无法概括 **角色具有习得的技能。** 物体和 NPC 可以教授技能。 ** ** ## 命令命令 |行动 ---|--- `技能[名称]` |调用或描述技能 `技能` |列出可用技能 `学习技能[名称]` |开始学习一项技能 `LIFT-SKILL [名称]` |将本地技能提取到中央 `实例化[技能] [位置]` |从原型创建实例 ** ** ## 协议符号符号|含义 ---|--- `技能` |调用此元技能 “玩-学-举”|开发生命周期 `技能实例化` |从原型创建实例 `原型` |自体遗传 `同理心模板` |智能语义实例化 ** ** ## 证明：我们已经证明了什么这不是理论。 MOOLLM 已经证明： ### 1\.自主角色创建 * **手掌猴子**：带有法庭辩论的完整化身，自选的名字，家庭，特征，目标 * **饼干狗**：自主命名、品种选择、居家安置 ### 2\.扩展多智能体模拟 * **33回合Stoner Fluxx**：8+角色，规则变化，一致的游戏状态 * **21 回合猫警探**：10 只猫并行，领地标记，协调返回 ### 3\.复杂叙事的一致性 * **会话日志**：6000 多行一致的叙述 * **世界状态**：房间用标记更新，角色记住交互 * **关系**：角色之间不断发展的联系 ### 4\.光速审议 * **法庭辩论**：多个角色同时交叉询问 * **集成推理**：单次调用中的不同视角 **该架构有效。结果证明了这一点。** ** ** ## 配合 * **[../prototype/]()** — 自类继承哲学 * **[../k-lines/]()** — K 线命名约定 * **[../play-learn-lift/]()** — 技能开发方法 * **[../empathic-templates/]()** — 智能实例化 * **[../empathic-expressions/]()** — 意图解释 * **[../speed-of-light/]()** — 多智能体模拟 * **[../room/]()** — 技能存在于房间中（三元组：as_room） * **[../card/]()** — 技能变成卡片（三元组：as_object） * **[../character/]()** — 技能成为专家（三元组：as_character） * **[../constructionism/]()** — 通过构建来学习 (Papert) * **[../schema-mechanism/]()** — Drescher 的因果学习：情境 + 行动 → 结果 ### 协议文档（在此目录中） * **[delegation-object-protocol.md]()** — 自类继承 * **[skill-instantiation-protocol.md]()** — 技能如何成为实例 ** ** ## 未来方向：技能编译器 > **TODO：** 构建一个“技能编译器”，优化运行时部署的技能。 ### 问题具有综合 SKILL.md、CARD.yml 和 README.md 的全功能技能非常适合： * 开发与调试 * 人类的理解和反思 * 需要时在运行时进行深度学习但对于针对特定应用程序的生产部署： * 许多K线和链接未使用 * README 文档与 SKILL.md 是多余的 * 并非所有方法/属性/协议都是必需的 * 上下文窗口预算很宝贵 ### 解决方案：技能编译就像编译器的链接器执行死代码消除和优化一样，**技能编译器**将： 1. **观看技能执行情况** * 技能要有测试用例和基准数据 * 观察实际调用了哪些K线、方法、协议 * 配置文件上下文使用模式 2. **了解目标环境** * 目标平台（Cursor、Claude Code、通用、自定义） * 目标应用领域 * 正在部署的目标技能子集 * 优化提示（大小与全面性） 3. **优化和改造** * **死K线消除** : 删除未使用的符号引用 * **链接修剪** ：删除对不需要的相关技能的引用 * **README吸收** ：将README中的关键细节注入SKILL.md，丢弃其余部分 * **接口剥离** ：仅导出 CARD.yml 中必要的方法/属性 * **绑定和专门化**：目标技能子集的预解析参考 * **分层分辨率**：创建多分辨率版本（嗅探→扫描→深度） 4. **生产优化的工件** * 预先索引的技能内容 * 分类和标记以便有效发现 * 多层解析层（标题、摘要、完整） * K线优化（仅相关激活） * 相关概念的总结集群 * 高效的运行时技能 ### 编译模式编译器：模式：发展： # 完整的技能，所有的文档 # 最大自省能力 strip_unused：假 include_readme：正确 include_examples：正确生产： # 针对运行效率进行优化 strip_unused: 真 include_readme: false # 吸收到SKILL.md中 inline_ritic_refs：真最小： # 尽可能最小的占地面积 # 仅在测试套件中实际调用的方法 strip_unused: 真内联全部：真单文件输出：true ### 源代码与编译技能技能/ # 来源：完整的开发技能 ├── 冒险/ │ ├── README.md # 人类文档 │ ├── SKILL.md # 完整协议规范 │ ├── CARD.yml # 完整接口 │ └── tests/ # 编译器的测试用例 │ ├── test_cases.yml │ └── benchmark_data/ 编译/ # 输出：针对目标进行优化 ├──cursor-leela/ # 目标：光标+Leela AI域 │ └── 冒险/ │ ├── SKILL.md # 精简，README 吸收 │ └── CARD.yml # 仅使用的方法 └──minimal/#目标：最小足迹 └── Adventure.yml # 单文件包 ### K线优化 K 线是激活向量。编译器应该： # 来源：全K线网络相关：[房间、卡牌、人物、灵魂对话、光速、动作队列、移情模板、yaml-jazz、postel，...] # 已编译：仅在目标上下文中实际激活了 K 线相关：[房间、卡片、角色]# 精简为必需品 ### 多层解决方案编译的技能应该支持渐进加载：等级： - 等级：0 名称：《闻闻》内容：“frontmatter + 10行摘要” 代币：~100 - 等级：1 名称：“扫描” 内容：“接口+方法签名” 代币：~500 - 等级：2 名称：《深》内容：“完整协议+示例” 代币：~2000 ### 实施说明 * 编译需要测试套件（如类型检查器的类型注释） * 编译器应该保守：当有疑问时，包括 * 人类可读的输出：优化后的技能仍应可读 * 可逆：跟踪调试时被剥离的内容 * 版本戳：编译技巧参考源码版本 ### 另请参阅 * [../k-lines/]() — K 线激活模式 * [../speed-of-light/]() — 上下文效率很重要 * [../bootstrap/]() — 最小技能加载 ** ** ## 总结：MOOLLM 推动艺术进步特色|人类基金会|穆尔姆贡献 ---|---|--- 文档 | ✓ | \+ README.md 用于发现工具定义| ✓ | \+ 带广告的 CARD.yml 可组合性| ✓ | \+ 原型继承（自身）无国籍| — | **多层持久性** 单代理| ✓ | **光速多代理** 字符串模板 | ✓ | **移情模板** 静态技能| ✓ | **可实例化原型** 姓名 | ✓ | **K 线（激活向量）** 单方面| ✓ | **三元组：房间/角色/物体** 孤立技能| ✓ | **作为可导航世界的代码库** **我们拥有良好的基础，并热忱邀请其他人加入我们。我们添加了实例化、继承、同理心、三元表现和经过验证的多代理模拟。** ** ** _“从爵士乐开始，以标准乐结束。但永远不要停止演奏。”_