北京
微软最近发布了APM——Agent Package Manager。这个项目在GitHub上已经拿到3200颗星，用一份apm.yml清单文件，配合锁定文件、策略文件、SBOM导出功能，就能配置八个编程助手。工作量不小，是个正经项目。
我维护的agkit，专门用来搭建和管理智能体插件市场。所以APM一出，我的第一反应你能猜到：我的项目还有存在的必要吗？
先声明，我不是中立观察者，接下来的话你掂量着看。但我花了一周时间泡在APM的文档和议题追踪器里，想认真回答这个问题。答案既不是"没有"，也不是"当然有"，比这两个结论都有意思。表面看，两个工具几乎完全重叠，但底下有个根本分歧，这个分歧决定了你会选哪个。
最省事的说法是这样：APM负责安装，agkit负责发布。一个是消费者，一个是生产者，同一枚硬币的两面，大家握握手各干各的。
这个说法错了，最好趁它没传开就消灭掉。因为APM发布市场的能力一点不差。apm init --marketplace就能启动一个会发布自己市场的项目。apm marketplace init会在apm.yml里追加一个marketplace代码块，同时创建.claude-plugin目录。配套的创作辅助命令也齐全：check、outdated、migrate、package。最关键的是apm pack，它从那个marketplace代码块构建出.claude-plugin/marketplace.json——这就是发布步骤，文件就是产物。微软的apm-action工作流把整个发布流程跑通：门禁检查、矩阵打包、sha256侧车文件、marketplace.json的偏差检测、GitHub Release创建。
两个工具做的事情一样：把你硬盘上的技能打包，变成别人能按名称、按版本安装的东西。如果你想找个理由二选一，"生产者对消费者"这个理由不成立。
它们真正的分歧在哪里？APM的真理来源是apm.yml加上.apm目录树。marketplace.json是从另一头掉出来的结果。apm pack是个编译器，APM团队有意这么设计：GitHub Action不预设哪个命令行工具消费输出，它只管按照你声明的outputs映射来吐东西——claude对应marketplace.json，codex对应plugins.toml。天生就是供应商中立的。插件目录只是构建产物。
agkit的真理来源是.claude-plugin/marketplace.json文件本身。对Claude Code和Copilot来说，没东西需要编译，因为它们直接读那个文件。agkit sync的方向完全相反：README里的插件表格和AGENTS.md列表是从目录派生出来的，这样它们就不可能跟实际内容产生偏差。目录才是真理来源。
同一个文件名，相反的数据流向。剩下的一切都由此而来。
编译这一步到底值不值？真正的抽象层有它的价值，APM就做到了。一份清单文件覆盖多个生态：声明一次，就能部署到Copilot、Claude Code、Cursor、OpenCode、Codex、Gemini、Windsurf和Kiro。以后哪个供应商改了格式，那是APM要操心的事，跟你没关系。编译步骤还给治理留下了空间——你没法对手工编辑的文件执行锁定、哈希、扫描和合规检查。一旦目录变成构建产物，发布流程就变成了经过编译的供应链，可以给它套上你需要的一切管控手段。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
