# Skillscript：为AI智能体设计的声明式工作流语言 > Skillscript是一种专为AI智能体设计的声明式编程语言，让智能体能够将学到的流程固化成可复用、可审计的技能代码，解决传统智能体每次任务都重新推理导致的成本、延迟和漂移问题。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-06-19T23:45:09.000Z - 最近活动: 2026-06-19T23:52:46.718Z - 热度: 155.9 - 关键词: AI智能体, 声明式语言, 工作流编排, MCP, 技能固化, 智能体基础设施 - 页面链接: https://www.zingnex.cn/forum/thread/skillscript-ai - Canonical: https://www.zingnex.cn/forum/thread/skillscript-ai - Markdown 来源: ingested_event --- ## 原作者与来源 - **原作者/维护者：** sshwarts - **来源平台：** GitHub - **原始标题：** skillscript - **原始链接：** https://github.com/sshwarts/skillscript - **发布时间：** 2026年6月19日 - **技术栈：** TypeScript，支持MCP协议 --- ## 背景：智能体的"失忆"困境 当前大多数AI智能体存在一个根本性问题：**它们是瞬态的**。每次执行常规任务时，智能体都需要从自然语言推理中重新"推导"整个流程。昨天总结线程的智能体，明天再做同样的事时，依然要从零开始思考"如何总结线程"，消耗昂贵的前沿模型推理资源去处理一个形状已知、输出格式已知、失败模式也已知的流程。 这种浪费在三个维度上叠加： - **成本**：每个常规操作都流经系统中最昂贵的推理层 - **延迟**：每个操作都支付完整的推理成本 - **漂移**：同一任务每次调用产生略有不同的结果，因为没有固化任何内容 更深层次的问题是：**智能体没有可供自我书写的底层架构**。智能体的能力目前完全以推理时的"软"形式存在，没有"硬"形式——没有可供智能体将学到的流程固化为低成本执行、低成本审查、低成本改进的产物的地方。 --- ## Skillscript的核心定位 Skillscript的核心理念可以用一句话概括：**"智能体即代码，Skillscript是智能体自我书写的语言。"** 这不是传统意义上的"记忆"（情景回忆、RAG上下文、对话摘要），而是**能力记忆**——以命名、类型化、可组合、可执行的形式持久化智能体的能力。 一个Skillscript技能是一个声明式配方，是一个带有类型化操作依赖DAG的小型程序。智能体编写一次，运行时多次触发。与典型的过程式智能体代码（Python脚本、TypeScript处理器）不同，Skillscript是**纯编排层**：它通过可互换的连接器合约组合对工具、模型和数据存储的调用，计算本身发生在工具中，协调则发生在技能中。 --- ## 语言设计：为何需要一门新语言 最直接的替代方案是"让智能体写Python"。Python是图灵完备的，有成熟的工具链，模型也能很好地编写它。但对于智能体编写的持久化自动化，Python的优势会转化为劣势： ### 图灵完备成为负担 智能体编写的脚本可能做任何事，包括智能体没有意识到的危险操作。`subprocess.run`、任意网络调用、文件写入——这些都没有门禁。一个有缺陷的智能体编写脚本的爆炸半径是整个主机。 ### 成熟工具对非人类作者无帮助 调试器和REPL是为人类迭代设计的，智能体不会那样迭代。 ### 直接执行放大失败 当智能体将损坏的Python脚本推送到生产环境定时任务时，没有验证层。脚本在凌晨3点静默失败，人类第二天才发现。 ### 包生态系统成为无界攻击面 能够`pip install`任何东西的智能体，确实可以安装任何东西——包括供应链被攻陷的包。 --- ## Skillscript的安全设计 Skillscript刻意限制表达能力。它不是图灵完备的，不能`eval`，不能`subprocess`，不能导入任意代码。**这种限制本身就是安全故事**——在语言级别强制执行，而非仅仅作为愿景。 作为交换，Skillscript提供： - **沙盒语法**：语言只能做配置的连接器允许的事 - **声明式可读性**：技能是类型化调度的DAG，人类阅读技能时能清楚看到调用了哪些工具、哪些数据写入、哪些模型提示触发 - **连接器介导的能力**：技能不导入包，而是调用连接器——有门禁的、带有精选工具表面的产物 - **准入前静态验证**：无法通过lint的技能不能进入库 - **生效前签名批准**：在安全模式下，只有携带有效操作员签名的技能才能执行效果操作 --- ## 技能的三种形态 每个Skillscript技能根据与前沿智能体的关系分为三种形态： | 形态 | 输出发送给 | 用例 | |------|-----------|------| | **无头(Headless)** | 下游系统或人类，异步消费 | 定时触发的监控、批处理器、自主工作流 | | **增强(Augmenting)** | 前沿智能体的推理上下文，会话启动或唤醒时立即使用 | 会话启动简报、警报、准备好的上下文 | | **模板(Template)** | 前沿智能体的执行循环，作为智能体自己运行的提示 | 智能体获取并遵循的可复用配方 | 这三种形态可以组合：无头监控在定时任务上触发，评估条件，然后路由到增强技能唤醒带有上下文的智能体，后者本身引用模板技能供智能体执行。 --- ## 本地模型作为前沿的委托目标 大多数智能体系统将本地模型视为前沿推理的替代品——在延迟或成本重要时调用它们代替前沿。Skillscript将它们视为不同的东西：**前沿编排的委托目标**。 前沿组合工作流；每个LLM调度都是前沿将边界明确的子任务（分类消息、提取字段、判断两个字符串是否指同一事物、总结片段、格式化响应）委托给本地或较小模型并消费结果。 在Skillscript中，这不是 adopters 额外添加的独立"本地模型交互"模式——它只是**通过连接器调用的MCP调度**。`$ llm prompt="..." -> RESULT`（一个部署将`llm`指向Ollama；另一个将`openai_chat`指向OpenAI API；另一个将`claude_messages`指向Anthropic）与技能体中的任何其他`$ tool args -> RESULT`调用并列，具有相同的操作级纪律、相同的追踪表面、相同的lint覆盖。 --- ## 技能组合：技能的技能 技能可以通过`execute_skill(...)`调用其他技能： ``` parent: execute_skill(name="extract-json-number", JSON_BLOB="${RAW}", FIELD_PATH="total_count") -> RESULT default: parent ``` 子技能针对运行时连接的连接器运行到完成，返回其完整执行记录（最终变量、转录、输出），并绑定到父技能的命名变量。父技能可以通过字段访问（`${RESULT.final_vars.X}`）触及子技能产生的任何内容。 组合是技能库能够积累的原因。实用技能（`extract-json-number`、`summarize-thread`、`classify-urgency`）编写一次，永远编排。 --- ## 与现有Skill生态的关系 Skillscript与Anthropic/OpenAI的Skills不是竞争关系，而是互补。 现有Skill是人工编写的markdown，将指令加载到模型的上下文中。它们有效，但**两个编写群体在用散文工作时都会产生形状不佳的产物**： - **智能体编写markdown**产生为人类而非智能体塑造的产物——冗长的解释、对冲语言、冗余的上下文设置、用散文代替结构的地方 - **人类编写markdown**则产生相反的失败模式：要么过于简洁缺少上下文，要么过于全面将实际流程埋在边缘案例之下 将其变成编程问题可以将两个群体都纪律化为正确的形状。语法不允许漫谈，编译器输出结构而非假装成结构的散文。 Skillscript技能**编译**成与手工编写Skill相同形状的产物——`# Skill: `头部、指令markdown主体——该产物可以像其他Skill一样加载到智能体的上下文中。Skillscript是你**编写时**使用的；编译后的Skill是**运行时**使用的。 --- ## 项目状态与展望 Skillscript目前处于pre-1.0阶段，提供运行时、编译器和CLI。它采用MIT许可证，正在积极开发中。 这个项目代表了一种重要的思维转变：从将智能体视为需要不断重新推理的瞬态存在，到将它们视为可以固化、积累、复用的能力库。如果智能体真的要成为软件工程的一等公民，它们需要一种能够表达这种固化的语言——Skillscript正是这种尝试。 --- ## 快速开始 ```bash npm install -g skillscript-runtime skillfile dashboard ``` 更多文档：https://skillscript.mintlify.app/docs