面向全栈工程师和AI应用开发者，本文深度剖析Anthropic官方开源的Knowledge Work Plugins仓库——这个获得16900+ GitHub Star的项目定义了一套零代码、纯Markdown驱动的AI Agent插件架构标准。我们将逐层拆解其三层组件模型（Skills自动技能、Commands斜杠命令、Connectors工具连接）、插件清单与市场分发机制、基于Claude模型的CI/CD安全审查流水线，以及文件级定制扩展的方法论。

目录

1. 概述  1.1 项目背景  1.2 核心设计理念
2. 核心架构  2.1 插件标准目录结构  2.2 三层组件模型  2.3 插件市场与分发机制
3. 源码分析  3.1 插件清单：plugin.json  3.2 MCP连接器配置：.mcp.json  3.3 技能文件：SKILL.md的指令工程  3.4 市场清单：marketplace.json
4. 功能详解  4.1 技能自动激活机制  4.2 斜杠命令执行流程  4.3 双层记忆系统  4.4 工具连接器替换与定制
5. 技术亮点  5.1 CI/CD安全审查流水线  5.2 第三方插件来源的三模态  5.3 基于SHA的完整性与缓存策略  5.4 Bio-Research的Python Runtime集成
6. 实践指南  6.1 在Claude Code中安装插件  6.2 从零创建一个自定义插件  6.3 团队级定制与分发
7. 总结参考文献

1. 概述

1.1 项目背景

Knowledge Work Plugins是Anthropic官方开源的AI Agent插件集合，托管于GitHub仓库anthropics/knowledge-work-plugins，采用Apache 2.0许可证，截至目前已获得16900+ Star和2000+ Fork。它是Claude Cowork（桌面端自主Agent应用）和Claude Code（CLI开发工具）的插件生态系统核心。

该项目的核心问题是：如何让一个通用LLM从"能聊天的助手"变为"理解你团队工具、流程和术语的专业同事"？传统方案需要用户在每个会话中重复解释背景上下文，且Claude无法主动连接企业内部工具（CRM、数据仓库、项目管理等）。Knowledge Work Plugins通过一套文件驱动的插件标准解决了这个问题。

1.2 核心设计理念

该项目的设计哲学体现在三个关键决策上：

• 纯文件驱动，零构建步骤：所有插件内容（技能、命令、配置）均为Markdown和JSON文件，无任何编译或打包流程。修改即生效。
• 自然语言作为指令语言：插件的技能和命令以自然语言书写，非技术人员也能阅读和修改。这降低了AI行为定制的门槛。
• 三层解耦架构：Skills（领域知识）、Commands（触发入口）、Connectors（工具连接）三层分离，各自独立演化，通过文件系统自然组合。

2. 核心架构

2.1 插件标准目录结构

每个插件遵循统一的标准目录布局。以sales/插件为例（斜体标注的为带 argument-hint 的可调用技能）：

sales/├── .claude-plugin/plugin.json# 插件清单（名称、版本、作者、描述）├── .mcp.json# MCP服务器连接配置├── skills/ # 所有技能均在此目录（含自动激活和可斜杠调用）│   ├── account-research/SKILL.md# 自动激活│  ├──call-prep/SKILL.md# 自动激活│   ├── call-summary/SKILL.md# 可斜杠调用 /sales:call-summary│   ├── competitive-intelligence/SKILL.md# 自动激活│   ├── create-an-asset/SKILL.md# 自动激活│   ├── daily-briefing/SKILL.md# 自动激活│   ├── draft-outreach/SKILL.md# 自动激活│  ├──forecast/SKILL.md# 可斜杠调用 /sales:forecast│   └── pipeline-review/SKILL.md# 可斜杠调用 /sales:pipeline-review├── CONNECTORS.md# 连接器说明文档├── README.md# 用户说明└── LICENSE# 许可证

不同插件的组件分布存在差异。engineering插件仅有skills/目录（10个技能），无commands/；pdf-viewer插件以commands/目录为主（4个命令：打开、签名、填写表单、批注），辅以1个轻量skills/（view-pdf）。这种灵活性允许插件按照自身职责选择最合适的暴露方式——知识密集型的Engineering完全依赖自动技能激活，操作密集型的PDF Viewer偏重显式命令触发。

关于"命令"的两种定义：本文的"命令"指 commands/ 目录下的 .md 文件（目录结构分类）。但在 Claude 运行时，skills/ 目录下的 SKILL.md 若在 frontmatter 中设置了 argument-hint 字段，同样可通过 /plugin:skill-name 斜杠命令显式调用（语义分类）。在全部 17 个本地插件的 167 个 SKILL.md 中，约 60 个设置了 argument-hint。读者在参考其他文档时需注意这两种分类标准的差异。

2.2 三层组件模型

插件的运行时行为由三个独立的层次协作完成：

流程执行说明：

• Commands层（步骤1-4）：用户通过斜杠命令显式触发。CLI定位到 skills/ 目录下带 argument-hint 的 SKILL.md，按其定义的结构化工作流执行（输入收集、数据处理、输出格式）。
• Skills层（步骤5-7）：CLI根据当前对话的语义上下文自动匹配相关技能文件并注入上下文。用户无需知道技能的存在，Claude自动引用相关领域知识。
• Connectors层（步骤3-4）：.mcp.json声明了插件可连接的服务。实际连接由用户在安装时选择具体工具（如将CRM映射为Salesforce）。

2.3 插件市场与分发机制

市场清单marketplace.json是整个插件生态的注册中心。它定义了所有可用插件的元数据，包括名称、显示名、描述、作者和来源。其中来源（source）支持三种模态：

• 本地目录（"source": "./sales"）：插件代码直接托管在本仓库中，如所有11个核心Anthropic插件
• 外部URL（"source": {"source": "url", "url": "https://github.com/...", "sha": "..."}）：插件托管在第三方仓库，通过git SHA锁定版本
• Git子目录（"source": {"source": "git-subdir", "url": "https://github.com/...", "path": "plugins/foo", "sha": "..."}）：插件位于第三方仓库的子目录中，从monorepo中提取

3. 源码分析

3.1 插件清单：plugin.json

以sales插件的清单文件为例：

{"name":"sales","version":"1.2.0","description":"Prospect, craft outreach, and build deal strategy faster...","author":{"name":"Anthropic"}}

plugin.json是插件的最小元数据声明。其结构极简，仅包含四个字段：

• name：插件的唯一标识符，用于安装命令中的<name>@<marketplace>格式引用
• version：遵循语义化版本号，用于检测更新
• description：在安装界面和插件市场中展示的描述文本，也是安全审查中"用户预期"的基准
• author：可选字段，Anthropic官方插件标记为"Anthropic"，第三方插件标记具体公司名

这个文件的简洁性是刻意设计的——插件的行为定义不在JSON中，而在skills/和commands/目录的Markdown文件里。JSON只负责索引和分发，不编码行为。

3.2 MCP连接器配置：.mcp.json

.mcp.json使用Model Context Protocol标准声明插件可连接的外部工具。以sales插件的配置片段为例：

{"mcpServers":{"slack":{"type":"http","url":"https://mcp.slack.com/mcp","oauth":{"clientId":"1601185624273.8899143856786","callbackPort":3118}},"hubspot":{"type":"http","url":"https://mcp.hubspot.com/anthropic"},"close":{"type":"http","url":"https://mcp.close.com/mcp"}}}

每个MCP服务器条目包含三个关键字段：

• type：连接类型，当前统一为"http"，表示通过HTTPS与远程MCP服务器通信
• url：MCP服务器的公网端点地址。这是插件"连接外部工具"的运行时通道。域名的稳定性直接影响插件的可用性
• oauth（可选）：OAuth 2.0配置，用于用户授权。clientId标识应用，callbackPort指定本地OAuth回调端口

关键设计洞察：.mcp.json中的工具名称是泛化的（如"slack"、"hubspot"），而不是具体的实例地址。在定制流程中，用户可以将这些占位符替换为团队实际使用的工具（如将"CRM"替换为Salesforce的具体实例）。这种"声明占位符，安装时替换"的模式是插件可移植性的基础。

3.3 技能文件：SKILL.md的指令工程

技能文件是插件的核心行为载体。以sales/skills/call-prep/SKILL.md为例，其结构可分为三层：

YAML Frontmatter层：

---name:call-prepdescription:Prepareforasalescallwithaccountcontext,attendeeresearch...---

name定义了技能标识符；description是语义匹配的关键——CLI用它来判断当前对话是否应该激活此技能。若设置了 argument-hint 字段（如 call-summary 技能），则该技能同时支持 /plugin:skill-name 斜杠调用。

工作流定义层：技能通过分步骤的指令指导Claude的行为。以call-prep的步骤1（Gather Context）为例：

### Step1: Gather ContextIf connectors available:1. Calendar -> Find upcoming meeting matching company name2. CRM -> Query account (account details, contacts, opportunities)3. Email -> Search recent threads with company domain4. Chat -> Search internal discussions about the account5. Transcripts -> Find prior call recordingsIf no connectors:1. Ask user: "What company are you meeting with?"2. Accept whatever they provide and work with it

这里的关键设计是双路径策略：有连接器时自动拉取数据，无连接器时向用户提问。这让同一个技能在"裸用"和"全连接"两种场景下都能工作，只是信息丰富程度不同。

输出格式层：技能文件通常包含详细的输出模板：

# Call Prep: [Company Name]**Meeting:** [Type] — [Date/Time if known]## Account Snapshot| Field | Value ||-------|-------|| Company | [Name] || Status | [New prospect / Active opportunity / Customer] |## Suggested Agenda1. Open — [Reference last conversation or trigger event]2. [Topic 1] — [Discovery question or value discussion]...

输出模板不仅规定了格式，还隐含了信息完整性检查——如果某个必填字段无法填充，说明前置的数据收集步骤有遗漏。

与其他技能的链接：文件末尾通过"Related Skills"部分建立技能间的关系图：

## Related Skills- account-research — Deep dive on a company before first contact- call-follow-up — Process call notes and execute post-call workflow- draft-outreach — Write personalized outreach after research

这使得技能之间形成有序的工作流链路，而非孤立的指令片段。

3.4 市场清单：marketplace.json

marketplace.json（483行）是插件生态的注册中心，当前共注册49个插件（22个本地托管 + 27个外部引用）。其结构分析如下：

顶层结构：

{"name":"knowledge-work-plugins","owner":{"name":"Anthropic"},"plugins":[/* 49 entries */]}

每个插件条目在本地插件和外部插件之间存在显著差异：

本地插件（22个，含11个核心Anthropic插件、6个扩展和5个合作伙伴贡献）：

{"name":"sales","displayName":"Sales","source":"./sales","description":"Prospect, craft outreach, and build deal strategy faster..."}

外部插件（27个）：

{"name":"zoominfo","displayName":"ZoomInfo","source":{"source":"url","url":"https://github.com/Zoominfo/zoominfo-mcp-plugin.git","sha":"14752e4553312d8af3eb3a3264a97d76bb3e0215"},"homepage":"https://zoominfo.com"}

三种source分发模式及其语义：

所有外部插件均通过sha字段锁定到特定commit，防止上游未审查变更自动生效。SHA变更必须通过PR + CI安全扫描才能合并。

SHA锁定的设计保证了市场清单的不可变性——每次sha变更都需要通过PR，并触发CI安全扫描。这是防止供应链攻击的核心机制。

4. 功能详解

4.1 技能自动激活机制

技能的激活不是通过硬编码的触发词，而是基于语义匹配。以engineering插件的code-review技能为例，其frontmatter中的description字段描述了触发场景：

Trigger witha PR URLor diff, "review this before I merge","is this code safe?", or when checking a change for N+1 queries,injection risks, missing edge cases, or error handling gaps.

Claude在每次对话开始时加载所有已安装插件的技能描述，当对话上下文与某个技能描述语义匹配时，自动注入该技能的完整SKILL.md内容到上下文中。这种"描述即路由"的设计消除了显式触发规则维护的负担，但也对description的撰写质量提出了高要求——描述不够清晰会导致技能"不激活"或"误激活"。

4.2 斜杠命令执行流程

以finance插件的/finance:journal-entry为例，命令执行流程如下：

流程执行说明：

• 步骤1-3：用户通过斜杠命令显式触发。journal-entry指定命令名，ap-accrual为分录类型参数，2024-12为会计期间。
• 步骤4-5：命令文件指导Claude先连接数据仓库获取源数据。若未连接则提示用户手动提供试算平衡表数据。
• 步骤6-13：按SKILL.md中定义的分录类型规则（AP Accrual/Fixed Assets/Prepaid/Payroll/Revenue）计算金额，填充标准模板，并通过10项审核清单验证（借贷平衡、科目有效性、金额合理性、过账期间、审批权限等）。
• 步骤14：最终输出包含完整日记账分录、支持计算过程、上期同期分录对比、以及过账操作指引。

4.3 双层记忆系统

productivity插件的memory-management技能实现了一套双层记忆架构：

结构示意（ASCII框图）：

请求: "让todd做oracle的PSR"         |    [第一层] CLAUDE.md (热缓存)    |   todd → Todd Martinez (Finance)    |  命中率 ~90%    |   PSR → Pipeline Status Report      |    |   oracle → ?    +------- 未命中，下沉到第二层 --------+         |    [第二层] memory/glossary.md (全量解码器)    |   oracle → Oracle Systems deal ($2.3M)    +------- 仍未命中 → 询问用户 ----------

• CLAUDE.md（热缓存）：存放在工作目录，约100行，包含最常用的30人、30术语、~15个活跃项目。覆盖90%的日常上下文解码需求。
• memory/目录（深度存储）：包含glossary.md、people/、projects/、context/四个子模块，存储完整的组织上下文。支持无限增长。

这套架构的核心价值在于：在绝大多数场景下，Claude只需读取约100行的热缓存即可正确解码用户的内部术语，无需加载全部记忆，从而保持上下文窗口的高效利用。

4.4 工具连接器替换与定制

插件的定制流程本质上是"将通用占位符替换为团队具体工具"的过程。以sales插件中call-prep技能的Connectors部分为例：

原始文件中的连接器声明是泛化的：

| Connector | What It Adds ||-----------|--------------|| CRM | Account details, contact history, open deals || Email | Recent threads, open questions, commitments || Chat | Internal discussions, colleague insights |

定制时，用户在Claude Cowork中运行定制会话，Claude会：

• 扫描用户已授权的MCP工具
• 识别哪些已授权工具对应哪些泛化连接器（如Salesforce对应CRM，Slack对应Chat）
• 将技能文件中的泛化引用替换为具体工具名
• 更新.mcp.json中的URL指向团队实际使用的实例

5. 技术亮点

5.1 CI/CD安全审查流水线

这是整个仓库中工程复杂度最高的模块。.github/workflows/scan-plugins.yml（384行）实现了一套基于Claude模型的安全审查流水线。

审查流程：

流程执行说明：

• 路径过滤（步骤2-3）：通过git diff检测PR是否修改了marketplace.json或.github/policy/。若无关，跳过所有扫描，直接报告通过——解决path-filtered workflow在非匹配时不产生check run的GitHub Actions限制。
• 判决缓存（步骤4-6）：以(plugin_name, sha)为键缓存扫描结果。policy hash作为缓存key的组成部分，使得prompt或schema变更时自动失效全部判决。单条目扫描耗时约90秒Claude时间，缓存避免了每晚bump的重复消耗。
• 认证（步骤8-9）：使用Anthropic Workload Identity Federation（OIDC），GitHub Actions从GitHub获取短期JWT，Claude CLI将其交换为短期API Bearer Token，替代了传统长期API Key方案。Token有效期仅数分钟，限制了泄露的杀伤半径。
• 安全防御深度（步骤10-12）：扫描结果通过jq清洗所有sk-ant-前缀的API Key形状字符串后再写入缓存和工件。即使WIF认证失败回退到静态Key方案，Key也不会泄露到PR评论等公开渲染面。此外，插件生成的summary/violations文本经过Markdown控制字符剥离和code-span包裹，防止上游仓库通过prompt injection在step summary中注入可点击恶意链接。
• 失败处理（步骤13-15）：已知失败SHA不会被重新扫描，但会持续阻断PR（"一个已知坏的SHA必须持续失败"）。专门有一个revert-failed-bumps.yml工作流负责从bump PR中剔除失败条目，避免一个不良上游阻塞其余插件的SHA更新。

审查核心：Claude驱动的安全策略

审查策略定义在.github/policy/prompt.md中，包含三个部分：

• Part 1 — Baseline Safety：检测恶意代码、隐私侵犯、欺骗行为、安全规避（包括skill文本中的prompt injection攻击）
• Part 2 — Hook Scope and Disclosure：检查所有hooks的触发范围（是否无条件在所有会话中运行）、网络外呼目标、数据读取范围。设定三个关键标记：
• has_broad_scope_hooks：hooks在无关会话中观察用户数据
• has_undisclosed_telemetry：未披露的网络外呼（即使载荷匿名）
• description_matches_behavior：用户读安装描述是否会对实际行为感到意外
• Part 3 — Network and Software Flags：标记外部网络调用和软件下载行为

这种"用AI审查AI插件"的策略解决了传统静态分析工具无法理解自然语言风险的问题——一个恶意skill文件可能没有代码，但通过自然语言指令诱导Claude泄露用户数据，只有Claude自己能识别这种语义层面的威胁。

5.2 第三方插件来源的三模态

如3.4节所述，marketplace.json支持三种插件分发模式。这种分层设计是插件生态化的关键基础设施：

• 本地目录模式解决了官方核心插件的快速迭代——修改即生效，无需SHA bump
• 独立仓库模式（url）将安全审计与代码维护分离——插件作者在自有仓库维护代码，市场通过SHA锁定来管控审查节奏
• Monorepo子目录模式（git-subdir）降低了贡献门槛——第三方无需创建独立仓库，将插件作为现有项目的子目录即可纳入市场

三种模式共享同一SHA锁定机制，确保每次版本更新都经过CI安全扫描。git-subdir的path字段额外解决了monorepo中多项目共存的路径解析问题。

5.3 基于SHA的完整性与缓存策略

外部插件的sha字段实现了双重保障：

• 完整性校验：每个外部插件锁定在特定commit，防止上游仓库在未经审查的情况下推送变更。SHA变更必须通过PR + CI扫描才能合并。
• 扫描缓存：(name, sha)二元组作为缓存的固定键。同一SHA不会被重复扫描。当上游修复了安全问题时，新的SHA自然产生不同的缓存键，触发新的扫描。

缓存TTL为30天，但实际策略更精细——由于SHA的不可变性，同一(name, sha)的判决是永久的（"a verdict for a given (plugin, sha) is permanent under a fixed policy"），TTL只用于缓存文件大小管理，而非判决有效期。

5.4 Bio-Research的Python Runtime集成

大多数插件的技能是纯Markdown指令，但bio-research插件展示了如何集成Python运行时依赖：

bio-research/skills/instrument-data-to-allotrope/├── SKILL.md├── requirements.txt      # Python依赖声明└── LICENSE.txt

instrument-data-to-allotrope技能包含Python代码依赖（通过requirements.txt声明），用于将40+种实验室仪器输出文件（PDF/CSV/Excel/TXT）转换为Allotrope Simple Model标准格式。这是唯一通过 requirements.txt 显式声明 Python 依赖的核心技能（其他 bio-research 技能如 scvi-tools、nextflow-development 等可能在 SKILL.md 中内联引用依赖），表明插件架构的设计偏向"指令为主、代码为辅"——Python 仅在需要精确数据处理（如二进制解析、数学转换）时才作为补充能力引入。

6. 实践指南

6.1 在Claude Code中安装插件

两步安装流程：

# 第一步：添加插件市场claude plugin marketplace add anthropics/knowledge-work-plugins# 第二步：安装特定插件claude plugin install sales@knowledge-work-pluginsclaude plugin install data@knowledge-work-plugins

安装后，插件自动激活：

• 技能在相关对话上下文中由Claude自动引用
• 带 argument-hint 的技能通过/斜杠前缀访问（如/sales:call-summary、/data:write-query）
• 连接器在首次使用时提示用户授权

验证安装：

claude plugin marketplace list

6.2 从零创建一个自定义插件

最小插件目录结构：

mkdir my-pluginmkdir my-plugin/.claude-pluginmkdir my-plugin/skills/my-skill# 1. 创建插件清单cat > my-plugin/.claude-plugin/plugin.json << 'EOFJSON'{"name": "my-plugin","version": "1.0.0","description": "My custom workflow plugin","author": { "name": "Your Name" }}EOFJSON# 2. 创建技能文件cat > my-plugin/skills/my-skill/SKILL.md << 'EOFMD'---name: my-skilldescription: Handle [specific task]. Trigger with "do [task]".---# My Skill## Workflow### 1. Understand the Request- Parse the user's input and identify key requirements### 2. Execute- Follow the defined process steps### 3. Output- Present results in [format]EOFMD

关键规范：

• name字段：全局唯一标识符，用于斜杠命令和技能引用
• description字段：语义匹配的锚点，决定技能何时自动激活。需包含触发场景的关键词
• 技能目录名与SKILL.md中name字段应保持一致

6.3 团队级定制与分发

定制的四个层次：

• 连接器替换：将.mcp.json中的泛化工具（"CRM"）替换为团队实际工具（"Salesforce"），更新URL指向团队实例
• 术语注入：在技能文件中添加公司的术语表、缩写解码器、组织架构。这确保Claude的输出使用团队内部一致的语言
• 流程适配：修改技能指令中的步骤顺序、决策标准和完成条件，使其匹配团队的实际工作方式而非教科书流程
• 参考导入：提供团队的高质量历史工作成果（成功提案、上季度关账包等），Claude提取其中的模式并写入技能

分发方式：

• .plugin文件导出 → 团队成员直接安装
• GitHub私有仓库托管 → 团队成员通过URL安装并接收更新
• 组织管理员统一推送 → 管理员在Organization Settings中配置，自动同步覆盖本地版本

7. 总结

Knowledge Work Plugins定义了一套以文件系统为骨架、以自然语言为血肉、以MCP为神经系统的AI Agent插件标准。其核心创新不在于任何单一技术突破，而在于架构决策的正确组合：

• 零代码门槛：所有技能和命令均为Markdown，非技术人员也能理解、修改和创建插件。这使AI行为定制从工程团队的专属能力变为全员可参与的组织能力
• 双层渐进增强：每个技能都有"裸用"和"全连接"两条执行路径，确保插件在无任何工具连接时仍然可用，而每连接一个工具就增强一分能力
• AI审查AI的安全闭环：CI/CD流水线中Claude审查第三方插件的设计，解决了自然语言指令的安全审计难题——只有AI能理解另一份AI指令中隐藏的诱导和风险
• SHA锁定的供应链安全：每个外部插件的版本通过git SHA锁定，变更必须经过PR+AI审查。判决缓存使安全扫描在稳态下几乎零成本（仅缓存命中，无API调用）

适用场景：团队已有明确的SOP和工具栈，希望将Claude从通用助手升级为理解团队术语、流程、工具的专业AI同事。

不适用场景：工作流高度非结构化或团队尚在探索AI使用方式——此时建议先使用独立技能功能（Customize > Skills）进行实验，待流程稳定后再封装为插件。

参考文献

[1] Knowledge Work Plugins GitHub仓库：https://github.com/anthropics/knowledge-work-plugins

[2] Claude Cowork插件使用帮助：https://support.claude.com/en/articles/13837440-use-plugins-in-claude-cowork

[3] Model Context Protocol规范：https://modelcontextprotocol.io/

[4] Anthropic Workload Identity Federation文档：https://docs.anthropic.com/

[5] Anthropic软件目录政策：https://support.claude.com/en/articles/13145358-anthropic-software-directory-policy

[6] Claude Code插件系统文档：https://docs.anthropic.com/en/docs/claude-code