Anthropic 岗位插件:把 Prompt 做成工作流包

👆 点击上方「迷斯特的小宇宙」，加「星标」不错过精彩内容

很多团队给 AI 配置“岗位”，第一步是写一段很长的系统提示词：你是一名销售、产品经理、法务顾问或数据分析师，请按某套方法工作。

这种方式适合做 Demo。进入真实组织后，问题很快变成另一组：岗位知识放在哪里？怎么连接 CRM、工单、文档和数据仓库？哪些动作可以自动执行？谁来批准写操作？流程更新后如何发布和回归测试？

Anthropic 开源的 knowledge-work-plugins，给出了一套值得拆解的工程答案。

它把岗位能力拆成 Marketplace、Manifest、Skills、Commands、Subagents、MCP 连接器、参考资料和脚本。Claude 负责理解目标与编排，外部系统提供实时数据和执行能力，企业再补上权限、审批、内部术语和质量评估。

本文基于仓库固定提交 33d3dea 做静态审计，并结合 Anthropic 官方插件与组织管理文档核验边界。

一个岗位插件里装了什么

一段 Prompt 为什么不够

长 Prompt 可以描述角色、语气和工作原则，却很难维护完整的岗位系统。

以销售会前准备为例，最终产物看似只是一页 brief，背后至少涉及五类能力：

• 从日历确认会议和参会人；

• 从 CRM 读取客户、机会阶段与历史承诺；

• 从 Gong 或会议记录提取异议；

• 从邮件、Slack、文档补充近期上下文；

• 给每项判断附上可追溯的原始记录。

如果把这些规则、工具说明、输出模板和安全约束全部塞进一个 Prompt，版本很快失控。任何连接器变化、字段变化或流程调整，都可能影响整段指令。

knowledge-work-plugins 的做法是把它们拆成可独立维护的资产。

岗位插件的七层结构

1. Marketplace：分发索引

Marketplace 决定插件从哪里安装。固定提交中的清单共有 123 个条目，其中 22 个指向当前仓库内的插件目录，101 个指向外部 Git 仓库或子目录。

这个拆分很重要。123 个条目不能全部算作 Anthropic 完整开发和审计的插件产品。Marketplace 同时承担第一方模板与第三方生态的分发功能，外部条目的代码、MCP 服务、许可证和更新节奏需要单独评估。

2. Manifest：插件身份证

每个本地插件都有 .claude-plugin/plugin.json。它声明插件名称、描述、版本等基础信息，是安装和发现的入口。

在仓库提供的创建规范中，Manifest 是唯一必需组件，最小必需字段只有 name。其余能力按任务复杂度逐步加入。

3. Skills：岗位方法与流程

Skills 是仓库的主体。固定提交中共有 252 个 SKILL.md。

一个 Skill 通常包含：

• 什么时候触发；

• 需要收集哪些上下文；

• 调用哪些工具；

• 如何处理异常和不可信内容；

• 输出采用什么结构；

• 哪些动作必须等待用户确认。

它更像可执行的岗位 SOP。销售 call-prep 会先探测可用工具和 CRM schema，再并行读取日历、CRM、会议记录、邮件和聊天，最后生成带来源链接的一页会前简报。

4. Commands：保留的显式入口

仓库仍有 15 个 command 文件，例如产品插件中的 /brainstorm。不过插件管理指南已经把 commands 标为 legacy，推荐优先使用 Skills。

这也解释了一个容易误读的现象：README 会展示 /variance-analysis、/review-contract 之类的调用形式，但它们未必对应独立的 commands/*.md，也可能直接由 Skill 暴露为用户入口。

5. Subagents：只给长任务使用

仓库只有 5 个 subagent 文件，而且都集中在 partner-built 的 Brand Voice 插件。17 个顶层岗位插件没有显式 subagent。

主流模式是 Skill 直接编排 MCP。只有跨多个知识库做长时间、并行、自治搜索时，才值得启动专用 subagent。

Brand Voice 的 discover-brand 就是一个例子：Skill 启动专用 Agent，由它跨 Notion、Confluence、Box、Drive、Microsoft 365、Slack、Gong、Figma 等来源搜索，生成品牌发现报告，再交给下游 Skill 生成指南。

6. MCP 与 Connectors：实时数据和执行能力

22 个本地插件中，21 个带有 .mcp.json，17 个提供 CONNECTORS.md。MCP 配置负责声明可连接的服务，Connector 文档解释类别、认证与配置方式。

它们是“接线定义”，并不代表连接已经认证、授权或可用。固定提交中的本地插件共声明 186 个 server entry，其中 31 个 URL 为空，仍需组织补充实现或配置。

7. References、Scripts 与 Examples：可维护的专业资产

复杂岗位知识没有继续堆在主 Skill 中，而是拆进参考资料、模板和示例。仓库里能找到数百个 references/reference 文件和 151 个 examples。

README 将插件概括为 Markdown 和 JSON、无需构建步骤，但实际仓库还包含 Python、Shell、HTML、依赖和配置文件。例如生物研究插件会调用 Python 脚本检查环境、抓取 SRA/GEO 数据并生成样本表；数据插件也包含打包公司专属 Data Skill 的脚本。

因此，更准确的说法是：插件没有统一的传统应用构建产物，但可以携带代码与运行时资产。

一次任务到底怎样流动

典型知识工作任务流

以销售会前准备为例，完整链路大致如下：

用户目标   → 触发 call-prep Skill   → 探测已授权工具与 CRM schema   → MCP 并行读取日历、CRM、Gong、邮件、Slack   → 归一化参会人、机会阶段、异议、承诺和开放事项   → 生成一页 brief，并附原始证据链接   → 用户决定是否继续更新 CRM 或发送消息

这条链路里没有专用 subagent。主 Agent 按 Skill 直接完成编排。

其他岗位也沿用类似结构，但自动化程度不同。

产品：上下文聚合加结构化表达

产品插件的 /brainstorm 会从知识库、产品分析、项目管理和聊天系统拉取背景，经过发散、挑战和收敛，再把确定的方向交给 write-spec 生成 PRD。

PRD 模板覆盖问题、目标、非目标、用户故事、P0/P1/P2、成功指标、开放问题和时间线。产品判断仍由人负责，插件主要压缩检索和成文成本。

客服：先生成升级材料

customer-escalation 会关联客服平台、CRM、聊天、项目管理和知识库，形成包含严重程度、影响范围、收入风险、复现步骤、目标团队、截止时间和证据链接的 escalation brief。

默认链路在这里停下来，再询问用户是否发布到 Slack、回复客户或建立提醒。它把高风险写操作留在第二阶段。

法务：企业 Playbook 决定上限

review-contract 可以读取 PDF、DOCX、URL 或粘贴文本，按 GREEN、YELLOW、RED 分类条款，并给出 redline、fallback、业务影响和升级路径。

但它明确要求优先加载企业 negotiation playbook。缺少 playbook、授权矩阵、实体信息和适用法域时，只能按通用商业标准生成审阅初稿。仓库也要求由合格法律人员复核。

财务：方法论完整，系统接入更难

财务 Skills 已包含差异分析、对账、分录、报表和 SOX 测试方法。例如 variance analysis 会做 price/volume、rate/mix、人员成本和费用分类拆解，并提供 materiality 和管理层叙述模板。

问题在数据与控制环境。默认 Connector 文档没有提供 ERP/Accounting 的现成 MCP，Snowflake、Databricks 等配置仍有空 URL。企业还需要补齐科目表、重要性阈值、月结日历、职责分离和审批证据。

数据：把企业语义做成新的 Skill

Data Context Extractor 的思路更有价值：Agent 先访问 warehouse schema，再访谈分析师，提取实体、指标、过滤规则和常见陷阱，最后生成公司专属 Data Skill 并打包。

这里自动化的对象不只是一次查询，而是组织的数据语义。以后再问“活跃用户”“ARR”或“流失”，Agent 可以调用公司定义，而不是临时猜口径。

仓库规模说明了什么

固定提交的结构统计如下：

• 22 个仓库内插件；

• 101 个外部 Marketplace 条目；

• 252 个 Skills；

• 15 个 legacy commands；

• 5 个 subagents；

• 21 份 .mcp.json；

• 17 份 CONNECTORS.md；

• 31 个脚本文件；

• 0 个 hooks。

这里能看出三个设计倾向。

第一，Skills 是核心抽象，Commands 正在退居兼容入口。

第二，多数任务由主 Agent 直接调用 MCP，Subagent 并非岗位插件的标配。

第三，仓库更关注岗位知识、连接配置和交付模板，强制性的审批状态机、审计日志与策略执行仍依赖宿主和企业系统。

企业启用前要补七道治理闸门

企业启用插件前的治理闸门

Anthropic 的宿主产品负责沙箱、权限询问、OAuth 和组织级插件策略。插件仓库本身主要提供 Markdown、JSON、脚本与配置资产，不提供一套独立、统一的强制执行沙箱。

企业启用插件前，至少要补齐七项治理：

来源审查：区分仓库内插件与外部 Marketplace 条目，检查维护者、许可证和依赖。

版本固定：锁定 Git 提交或版本，避免外部更新静默改变指令与工具行为。

最小权限：按岗位和任务限制 MCP、OAuth scope、文件系统与网络访问。

数据边界：定义 PII、合同、财务数据和客户信息可以进入哪些模型与连接器。

写操作审批：更新 CRM、发消息、签署、付款等动作必须设置明确确认点。

质量 Eval：结构校验和连接器存活测试无法证明业务输出正确，需要真实任务集、回归样本和失败分级。

日志与更新治理：记录调用、证据、审批和最终写入结果，并对插件升级做重新评估。

官方安全文档也提醒：插件可能以用户权限运行代码；Skills 和 Agents 会向模型上下文注入指令；Hooks、本地 MCP、LSP 与后台 monitor 可能在沙箱外运行；Anthropic 不控制第三方插件包含的 MCP 服务和其他软件，也不保证它们的行为保持不变。

因此，Marketplace 解决的是发现和分发，不等于供应链自动可信。

这套模型真正值得借鉴的地方

knowledge-work-plugins 最值得复用的不是某个销售或法务 Prompt，而是它的拆分方式：

• 把岗位方法写进 Skills；

• 把实时数据和执行交给 MCP；

• 把复杂知识拆进 references；

• 把稳定交付结构做成 artifact 模板；

• 把长时间自治搜索交给 subagent；

• 把分发信息放进 manifest 和 marketplace；

• 把权限、审批和质量控制留给宿主与组织治理。

这让岗位能力可以分别更新、审查、测试和复用。

对准备在企业内部做 Agent 的团队，我更建议从一个高频、证据明确、写操作可控的任务开始，例如销售会前准备、客服升级包或数据口径提取。先建立可追溯的读取链路和人工确认点，再逐步开放写权限。

岗位 Agent 的工程质量，最终取决于四件事：组织知识是否清晰，工具权限是否受控，输出是否可验证，流程变更是否能回归测试。

插件仓库提供了骨架。企业自己的 schema、playbook、审批与 eval，决定这副骨架能否进入生产环境。

审计说明

• 仓库：Anthropic knowledge-work-plugins

• 固定提交：33d3dea41a341b341d4f5da2e8801ae0c89be2b8

• 审计日期：2026 年 10 月 24 日

• 方法：仓库静态审计、结构脚本统计、官方插件/安全/组织管理文档交叉核验

• 限制：未对第三方 MCP 服务逐一完成授权、连接和真实业务输出测试；结构与 CI 状态不能替代业务质量评估

岗位插件可以复制流程骨架，生产质量仍来自组织知识、受控权限、人工审批和持续 Eval。

迷斯特的小宇宙，客户端技术背景，大前端技术、AI前沿技术分享，偶尔写写生活日记。

如果这篇文章对你有启发，点个「在看」或转发给朋友，是对我最大的支持 🙏