Knowledge Work Plugins:让工作助手使用共享任务文件
部署 Knowledge Work Plugins:版本、文件与连接器
把插件作为宿主配置进行发布,记录版本、备份工作记忆、逐项审批连接器,并准备明确的回退方案。
你将学会
- 记录实际使用版本
- 连接器逐个授权
- 回退覆盖文件边界
开始前需要
- 基本命令行与配置阅读能力
- 能够在独立且获准的环境中试验
设计独立的只读解析预览,在保存前展示不支持的 Markdown、分组冲突和往返序列化差异。
先看结论
- 插件发布不需要虚构容器服务。
- 空连接器地址必须明确处理。
- 移除插件与撤销授权是两件事。
记录实际使用版本
这里的部署单元是宿主中的插件,以及它读取和修改的工作区文件。需要记录插件修订与宿主版本;市场内容更新可能改变指令,即使任务文档本身没有发生变化。
试点保留经过审阅的副本或发布引用,并记录宿主支持的安装方式。不要认为添加市场命令会固定到 ebd7990c;这个提交只是本文研究快照,不保证未来安装得到相同内容。
连接器逐个授权
审阅的 productivity .mcp.json 列出了多个工作服务的 HTTP 地址,但 Gmail 和 Google Calendar 的 URL 为空。因此配置里出现名称,不能算作集成已经可用或部署已经完成。
每次只接入一个获准的测试账号和连接器,检查实际授权范围及宿主提示,先完成无害读取再考虑写入。README 的服务分类列表不能替代你当前环境中的认证状态清单。
回退覆盖文件边界
更新前备份 TASKS.md、CLAUDE.md 和 memory/,迁移期间暂停助手和看板的并发编辑。如果新指令或序列化器造成不合意修改,应同时恢复已验证的插件版本和文件快照。
停用插件不一定撤销远端账号授权,也不一定清除已保存的工作信息。发布记录中要分别跟踪这些状态。本章提供基于源码的部署方案,不声称已完成企业环境的真实部署。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
记录宿主、插件版本和工作目录。
- 2
逐个验证获准连接器,暂不开放全面扫描。
- 3
保存旧插件和记忆快照以便回退。
可复制示例
{
"rolloutProposal": true,
"hostVersion": null,
"approvedConnectors": [],
"backup": [
"TASKS.md",
"CLAUDE.md",
"memory/"
],
"liveConnectorTested": false
}常见问题
安装后所有服务都能使用吗?
不能,需要分别验证地址、宿主支持和账号授权。
备份包含什么?
任务文件、工作记忆、深层记忆,以及解释这些文件的插件版本。
资料来源
- Knowledge Work Plugins / README.md来源核查 2026-09-18
- Knowledge Work Plugins / productivity/README.md来源核查 2026-09-18
- Knowledge Work Plugins / productivity/.mcp.json来源核查 2026-09-18
- Knowledge Work Plugins / productivity/skills/task-management/SKILL.md来源核查 2026-09-18