*一门让代理自我编写的语言。* skillscript.ai • 文档 TL;DR — npm install -g skillscript-runtime && skillfile init && skillfile dashboard 。查看快速入门。内容 问题 框架 为什么要有一种新语言 为什么不让代理编写技能？ 三种技能 唤醒代理 将本地模型作为前沿工具 组合：技能调用技能 静态与动态技能 你能得到什么 下注 快速入门 一个规范的自治技能 连接器模型 配置与安全选项 CLI MCP 服务器表面 示例 架构和深度文档 状态 贡献 许可证 问题 AI 代理大多是瞬态的。每个常规任务都是从文字推理中重新推导出来的。昨天总结一个线程的代理，明天会通过从零开始推理如何总结线程来总结另一个线程，消耗前沿推理资源在已知形状、已知输出格式和已知失败模式的过程上。浪费在三个方面累积：成本（每个常规操作都经过系统中最昂贵的推理层），延迟（每个操作都支付完整的推理成本），以及漂移（同样的任务在每次调用时会产生略有不同的结果，因为没有任何东西得以凝结）。更深的问题在于代理没有书写自己的基底。代理部分是通过它们可以做的事情定义的，而这些事情目前完全以软的、瞬态的推理形式在推理时保持。没有硬性形式。没有地点让代理将学习到的过程凝结成便宜的执行、便宜的检查和便宜的改进。目前大多数代理基础设施项目专注于记忆——情节回忆、检索增强的上下文、对话总结。这些项目回答的是“代理知道什么”。它们并没有以任何持久的、可执行的、可检查的形式回答“代理可以做什么”。Skillscript 旨在回答第二个问题。 框架 代理是代码，而 skillscript 是它们自我编写的语言。不是记忆的回忆意义。不是提示模板。不是配置。代码，严格意义上是命名、类型化、可组合、可执行的能力构成物。一个 skillscript 技能是一个声明式食谱，一个有类型操作的依赖 DAG 的小程序——代理编写一次，运行时多次触发。典型的代理代码是程序化的（Python 脚本，TypeScript 处理程序），而 skillscript 仅用于编排：它通过可更换的连接器合约将调用组合到工具、模型和数据存储中。计算存在于工具中；协调存在于技能中。 # 技能：hello # 状态：已批准 # 描述：规范的首次运行示例。 # 变量：WHO=world 你好，${WHO}！欢迎来到 Skillscript。这是一个完整的、可运行的技能——主体文本是输出。没有目标，没有样板，没有 emit() 仪式：运行时根据技能的变量渲染主体并发布它。同样的结构扩展到多阶段 DAG，分类输入，派发到 LLM，查询数据存储，基于条件进行分支，并编排子代理，所有这些都在同样的声明式语法中。 为什么要有一种新语言 明显的替代方案是“让代理编写 Python。” Python 是图灵完备的，工具成熟，模型也很好地编写它。对于一次性的探索性工作或计算至关重要的情况，Python 是合适的工具，而我们并不建议任何人在这方面停止使用它。但是，代理编写的持久自动化具有不同的形状：一个代理（而不是人类）编写代码。代码独立运行——定时触发、事件触发——在人类不参与的情况下执行。工作呈派遣形状：调用工具，分类结果，分支，调用另一个工具。不是算法计算。代码需要被人类按照人类的节奏审计，即使它是由代理的节奏编写的。对于这种形状，Python 的优势转化为负担：图灵完备性反而成为一种负担。代理编写的脚本可以做任何事情，包括代理未意识到的危险事情。subprocess.run、任意网络调用、文件写入。这些都没有门槛。一个有缺陷的代理编写的脚本的爆炸半径是整个主机。当代理将一个损坏的 Python 脚本发布到生产 cron 时，没有验证层。脚本在凌晨 3 点无声失败，第二天人类才发现。包生态系统变成了无限的攻击面。能够 pip 安装任何东西的代理可以安装任何东西——包括受到供应链攻击的包。包生态系统假设人类在采纳之前有审查；代理的采纳打破了这个假设。 Skillscript 故意限制表现力。它不是图灵完备的。它不能 eval，不能 subprocess，不能导入任意代码。这种限制是安全的...