#Target 与能力地图

本页回答三个问题：该编写什么、该选择哪种输出，以及能力边界在哪里。 要先做出一个可用工具，请从快速开始入手。精确且带版本记录的宿主行为由 自动生成的矩阵说明；不要假定所有宿主都实现同一种插件接口。

#全部内置输出 target

以下是 agent-bundle.config.ts 的 targets 支持的五个内置值。它们选择编译器生成的内容， 不是账户、模型或正在运行的开发会话。

省略 targets 时只选择 portable。显式配置会替换这个默认值：

import { 
const defineConfig: (config: AgentBundleConfig | ConfigFactory) => AgentBundleConfig | ConfigFactorydefineConfig } from 'agent-bundle/config';

export default 
function defineConfig(config: AgentBundleConfig | ConfigFactory): AgentBundleConfig | ConfigFactorydefineConfig({
  
AgentBundleConfig.plugin: AgentBundlePluginConfigplugin: { 
AgentBundlePluginConfig.name: stringname: 'project-tools', 
AgentBundlePluginConfig.description?: string | undefineddescription: 'Tools for this project.' },
  
AgentBundleConfig.targets?: string[] | undefinedtargets: ['claude', 'codex', 'cursor'],
});

只为某次构建选择其他投影时，重复使用 --target。请先在项目中安装正确的框架包：

npx --no-install agent-bundle build --target claude --target codex

只有实际组件能够共存时，组合才有效。同一路径的不同内容、或某个宿主意外发现另一个宿主的组件， 都会导致构建错误，而不是允许后一个投影覆盖前一个。改变 target 顺序不能解决冲突。 参见组合规则。

项目创建提供的 target 与编译器注册的完全一致，包含 amp。它只拒绝编译器同样会拒绝的组合： MCP 模板中由编译器拥有的本地服务器会被 Amp 的 Skill 级 MCP 契约拒绝 （amp.mcp.generated-local），因此 Amp 项目应从别的模板起步。 嵌套安装根目录和重新加载步骤见安装指南。

#权威能力矩阵

以下页面从适配器使用的同一组固定能力记录生成，包含原始文档、观测版本、详细限制和省略原因。 不要在插件仓库中再维护一套原生支持清单。

每项能力判断都限定到具体功能及其证据：

运行验证是另一个维度。适配器可以已经实现，但依赖账户的激活仍然是 unverified。 Amp 就是当前例子：实验性、已核对契约、运行时未验证。没有账户不是宿主无法执行操作的证据；反过来， 文件放置成功也不证明宿主已启用插件或调用工具。

#框架能构建什么

下表是编写导航，不承诺每个 target 都接受每一种组件。可用性由宿主矩阵和实际构建的 inspection 决定。

高级 custom/command/remote MCP 服务器、原生元数据、原生 hook 文档、预构建 payload 和打包器覆盖仍按文档支持。 它们解决真实的集成需求，不是编写普通工具之前必须完成的设置。

#兼容客户端不是额外 target

宿主矩阵中的 Recorded third-party clients 部分描述现有输出格式的读取方。 这些客户端名称不是 targets 的额外取值。某宿主的研究 issue 也不代表已经存在可安装的适配器。

同时阅读客户端的 tier 与各表面记录。仅支持 Skills 的客户端可能不读取 plugin.json。 能读取 mcp.json 的客户端不一定展开启动服务器所需的路径占位符。安装命令可能只是注册目录， 而不是复制目录。高优先级清单可能重定向组件路径；单独的 MCP 文件覆盖不一定遮蔽无关的 Skills。 插件未编写的可选组件不会凭空出现。

详情以生成的客户端记录中的带日期来源为准。 笼统地说某客户端“支持插件”，不足以证明它能消费这个具体产物。 这里不会把尚无已实现或已记录路径的宿主宣传为受支持 target。

#构建、开发与展示是不同维度

通过高级 TargetRegistry 注册的第三方适配器，在当前组合契约下单独构建。 它们不会自动继承内置 target 之间的发现隔离保证。

#检查自己的插件

各 inspection focus 分开运行，不要在同一次调用中组合多个 focus：

npx --no-install agent-bundle inspect --json
npx --no-install agent-bundle inspect --routes --json
npx --no-install agent-bundle inspect --hooks --json
npx --no-install agent-bundle inspect --state --json
npx --no-install agent-bundle validate

构建之后，不需要重新发现源码即可检查和校验交付物：

npx --no-install agent-bundle inspect --artifact artifact --json
npx --no-install agent-bundle validate --artifact artifact

事件需求是语义性的时，使用受支持的 config.requires 能力声明；刻意面向原生行为时，使用显式宿主选择。 不要通过丢弃阻止决定、虚构上下文或扩大批准范围来宣称支持。 互斥声明和能力不可用诊断见事件指南。

交付物应保留生成的 INSTALL.md，并遵循其中真实的宿主、根目录与 scope 指令。 成功编译、打包进程测试、原生安装与经过身份验证的智能体调用证明的是不同事情；记录实际执行过的级别。