一份带类型的配置
单个 agent-bundle.config.ts 承载项目身份、target 选择与策略。配置没说的部分由 src/ 约定补齐;两者描述同一件事时,配置始终优先。
一次性描述 Skill、钩子、MCP 服务器与脚本,编译出可直接安装到 Claude Code、Codex 与 Cursor 的产物。
单个 agent-bundle.config.ts 承载项目身份、target 选择与策略。配置没说的部分由 src/ 约定补齐;两者描述同一件事时,配置始终优先。
每个 Skill 一个目录,包含 SKILL.md 与自己的资源;无需声明即可被发现,并按固定版本的 Agent Skills 规范校验。
从 sessionStart 到 workspaceOpen 共七种事件,用 TypeScript 写一次,编译成每个宿主实际拉起的包装脚本。
手写的 stdio 服务器,或每个 tool、resource、prompt 各占一个模块的生成式服务器。浏览器端 MCP App 编译为自包含的 HTML。
普通脚本或渲染式脚本、逐字节复制的静态资源,以及从同一项目输出的 CLI bin 或库入口——一次构建,两份输出。
agent-bundle dev 在回环地址上提供开发者 Workbench:诊断、产物树、带原始协议轨迹的 MCP playground,以及钩子 playground。
路由、协议、CLI、打包与宿主安装等各级证明,把“能构建”变成可复核的证据;某一级别的通过绝不会被当作另一级别的收据来报告。
评估套件具有通过、失败与不确定三种语义,针对真实输出的产物运行,而不是它的模拟品。
已构建的 target 目录就是你安装的那个单位——它自带宿主清单与生成的 INSTALL.md。旁边的产物根目录保存着 agent-bundle.manifest.json,即校验、MCP、钩子与评测所读取的 SHA-256 记录。
输入是一份配置文件加一棵按约定组织的 src/ 目录树。输出是每个宿主各一个可直接安装的目录,
各自带有自己的宿主清单、生成的包装脚本,以及用捆绑包真实名称写成的安装说明——它们共同位于一个产物根目录之下,
根目录还保存着整个产物据以校验的 agent-bundle.manifest.json。
Skill、MCP 服务器与脚本都按约定被发现。只有钩子需要声明,因为处理器必须绑定到某个事件。
生成的包装脚本文件名以一段短摘要结尾,摘要来自编译它的声明,而非文件内容。artifact/agent-bundle.manifest.json
记录每个输出文件及其 SHA-256,因此后续校验比对的是真实字节,而不是检查某个路径是否存在。
编写 agent-bundle.config.ts,把 Skill、钩子、MCP 路由与脚本放到 src/ 下。
agent-bundle inspect 会展示归一化后的模型,让你确认哪些文件是按约定被发现的、哪些是由配置声明的。
agent-bundle dev 在每次变更时重新构建,并在回环地址上提供开发者
Workbench:诊断、Skill 文档、带来源信息的产物树,以及驱动输出的
MCP 服务器与钩子包装脚本的 playground。
用彼此区分的证明级别针对产物做测试——从路由单元测试一直到通过真实宿主 CLI 安装的捆绑包——并运行结果为通过、失败或不确定的评估。
agent-bundle build 校验项目并为每个 target 写出一个目录。校验
依据清单检查产物,安装则走每个宿主自己的安装路径。
各宿主能加载的内容不同,编译器会在构建时明确指出:你为某个 target 选择了它无法表达的表面,就会得到一条
被报告的诊断,绝不会被悄悄省略。唯一有意为之的例外是没有自己的 targets 的钩子:它只继承支持钩子的
宿主——正如上面的 portable 标签页所示——而不是让构建失败。每条诊断都有稳定的 AB 代码,记录在
诊断参考中。