Skillscript 开源：给 AI Agent 工具编排换一套骨架
一个叫 Skillscript 的项目昨天登上 Hacker News，作者用声明式语法加沙箱隔离重做了 AI Agent 的工具编排层。它不是又一个可视化画布，而是把工具调用当成一门可以静态分析的小语言来写。
昨天 Hacker News 上冒出来一个叫 Skillscript 的项目，作者 sshwarts 直接把它定位成"一门用于工具编排的声明式沙箱语言"。24 小时内票数冲进首页前列，评论区吵得挺凶——支持的人觉得终于有人认真做这件事了，反对的人则问：又一个 DSL，凭什么？
我看完仓库和讨论，觉得这个东西值得单独说一下。它不是又一个 Dify、Coze 式的可视化画布，也不是 LangGraph 那种 Python 库，而是把 Agent 的工具调用层当成一门独立的小语言来设计，配上运行时沙箱。这个切入点在 2026 年这个时间点，其实挺关键。
为什么现在需要"另一门语言"
过去一年多，Agent 编排的主流方案基本是两条路：一条是 LangChain/LangGraph 这种以 Python 代码为核心的库，另一条是 Dify、n8n、Coze 那种拖拽画布。前者灵活但脆弱，后者上手快但一到复杂逻辑就露馅。
真正暴露问题的是 Anthropic 十月份推的 Claude Skills 和后来谷歌 Antigravity 跟进的 Agent Skills 规范。Skills 这套思路把"一个能力"打包成可复用的小模块，理论上很美——但落地时大家发现，Skill 内部到底怎么写、怎么串工具、怎么隔离权限，各家标准五花八门。有的用 YAML，有的直接塞 Python，有的干脆让模型自己生成 shell。
Skillscript 的作者在 README 里说得很直接：现在 Agent 调用工具，本质上是让 LLM 在运行时即兴写代码，然后寄希望于沙箱兜住。这个模式在 demo 里很酷，在生产环境里是噩梦——你没法静态分析、没法审计、没法在部署前知道这段编排会碰哪些外部资源。
他的解法是：把编排逻辑从"运行时生成"挪到"部署前声明"。
语法长什么样
从仓库的示例看，Skillscript 的语法有点像 HCL（Terraform 那套）加了一层类型系统。一个典型的 Skill 大概是这样的结构：
skill "fetch_and_summarize" {
input {
url: string @validate(url)
}
capabilities {
network.outbound = ["*.example.com"]
fs.read = false
fs.write = false
}
step fetch {
tool: http.get
args: { url: input.url }
timeout: 10s
}
step summarize {
tool: llm.complete
args: {
model: "claude-sonnet",
prompt: "Summarize: ${fetch.body}"
}
depends_on: [fetch]
}
output: summarize.text
}
几个设计点值得单独拎出来：
capabilities 块是硬性声明。你想让这个 Skill 访问网络，就得把域名白名单写死；想读文件系统，就得显式开。运行时如果尝试做没声明的事，直接拒绝。这个思路跟 Deno 的权限模型是一脉相承的，但落到 Agent 场景更合适——毕竟 LLM 生成的调用链本身就不可预测。
step 之间是显式依赖。没有隐式的"上一步的输出"这种约定，你必须写 depends_on 或者通过变量引用来串。这让整个 Skill 变成一个 DAG，可以静态分析、可以并行执行、可以在没跑之前就画出调用图。
类型系统是可选但被鼓励的。input 和 output 都能标类型，@validate 这种装饰器可以挂校验规则。这在跟 LLM 交互时特别有用——你可以在 Skill 边界强制约束模型的输出格式，而不是靠 prompt 里祈祷。
沙箱是怎么做的
HN 评论区问得最多的一个问题是：沙箱到底靠什么实现？作者的回答是分层的。
最外层是进程级隔离，每个 Skill 执行开一个独立的子进程，用 Linux 的 namespace 和 seccomp 限制系统调用。这块基本是照抄了 gVisor 和 Firecracker 的经验，没什么新意但够用。
中间一层是网络代理，所有出站请求走一个 sidecar，根据 capabilities 声明的白名单放行或拦截。这个设计跟腾讯云那篇 Skills 文章里提到的"出站网络管控和 sidecar 代理管理凭据"思路完全一致，说明业界已经收敛到类似的模式了。
最里层是解释器本身的限制——Skillscript 不是图灵完备的。它没有 while 循环，没有任意递归，控制流只有条件分支和有限的 map/reduce。这个选择很激进，作者在 issue 里被追问过，他的回复是："如果你需要图灵完备，说明你在用错工具，去写 Python 调这个 Skill 就行。"
我个人觉得这个态度是对的。Agent 编排层本来就不该承担通用计算的责任，它该做的是可靠地把 LLM 的意图翻译成一串受控的工具调用。图灵完备是 bug 不是 feature。
跟现有方案比，位置在哪
拉一张表对比一下就清楚了：
- LangGraph：Python 库，灵活性拉满，代价是每个 Agent 都是一份需要维护的代码库，跨团队复用基本靠自觉。
- Dify / Coze：可视化画布，上手门槛低，但复杂逻辑一多就变成"意大利面画布"，版本管理也是个老大难。
- Claude Skills / Antigravity Skills：标准化的能力封装，但内部实现语言不统一，跨厂商迁移成本高。
- Skillscript：文本化、声明式、沙箱内建，跟 Git 天然友好，但需要学一门新语法，生态几乎为零。
Skillscript 的定位更像"Agent 世界的 Terraform"——不是要取代 Python 或者画布，而是在"我要严格控制这个 Agent 能干什么"的场景下补一块拼图。金融、医疗、企业内网这些对权限敏感的场景，我觉得会是它最先落地的地方。
有几个没解决的问题
泼点冷水。看完代码和 issue，我列几个真实的疑虑：
第一，生态是零。目前仓库里只有几个内置工具（http、fs、llm 的基础封装），要接 Slack、Notion、数据库这些常用系统，全得自己写适配器。作者说计划做一个类似 npm 的注册中心，但那是画饼。
第二，跟 MCP 的关系没理清。Anthropic 的 MCP 协议今年基本成了工具调用的事实标准，Claude Code、Codex CLI、Figma 那些都在用。Skillscript 目前是自己一套工具接口，没直接兼容 MCP。作者在 issue #12 里说下个版本会加 MCP adapter，但还没影。
第三，调试体验一般。声明式的东西好处是可静态分析，坏处是出问题时不好断点。目前只有一个 CLI 的 dry-run 模式，能打印执行计划但没法真正 step-through。这个在生产环境是硬伤。
第四，语法品味见仁见智。有人在 HN 上吐槽这套语法"看着像 HCL 但没 HCL 好看"，也有人觉得比 YAML 强多了。我个人偏向后者，但审美这事说不清。
值得关注但别急着 all-in
把话说透：Skillscript 现在还是个周末项目量级的东西，GitHub 上一千多个 star，作者一个人在推。它有意思的地方不在于代码本身，而在于它提出的问题——Agent 的工具编排层，到底该长什么样？
过去两年大家都在往"让 LLM 自己写代码"这个方向卷，Anthropic 的 Skills、谷歌的 Antigravity、各种 DeepAgent+Sandbox 组合，本质上都是在给这个即兴创作的过程套缰绳。Skillscript 走的是相反的路——先把缰绳做好，再让 LLM 在缰绳允许的范围内跳舞。
哪条路会赢，现在下结论太早。但至少这个项目让讨论回到了一个基础问题：可审计、可复用、可静态分析的 Agent，比即兴生成的 Agent，在生产环境里价值高得多。
如果你在做企业内部的 Agent 平台，或者在给 Skills 生态选型，Skillscript 值得跑一遍它的 example，感受一下声明式编排的手感。如果你只是在做个人项目的 demo，那 LangGraph 或者 Dify 依然是更省事的选择。
另外顺一句，OpenAI Hub 目前对接了 GPT、Claude、Gemini、DeepSeek 等主流模型，一个 Key 全走通，国内直连、兼容 OpenAI 格式。Skillscript 里的 llm.complete 工具想快速接多家模型验证，走这种聚合网关会省不少事。
参考来源
- Show HN: Skillscript – A declarative, sandboxed language for tool orchestration — 项目主仓库，含语法说明、示例和 issue 讨论
