把 Skills 留在服务器，用 WorkBuddy 调用我们的 Agent
从 PDF 提取与 Word 模板案例出发，思考通过 WorkBuddy 和远程 MCP 交付服务器 Agent 能力的分工、维护与服务价值。
本文目录
本文记录一种能力交付方案。文中远程 Agent 服务与业务团队尚未上线，示意图不代表已经完成客户端联调。
最近，我在考虑一种能力交付方式：用户使用自己的 WorkBuddy，我们把 Agent 和核心 Skills 部署在自己的服务器上。用户通过连接器提出任务，我们的服务完成处理，再把成果交回去。
我认为这很有价值。用户可以沿用熟悉的工作入口，我们可以持续维护背后的专业方法。两边通过接口协作，为把 Skills 做成长期服务提供了一条值得探索的路径。
从 PDF 到 Word 模板
设想一位用户已经在用 WorkBuddy，现在需要从几份 PDF 中提取项目名称、日期和金额，核对出处，再填入公司的 Word 模板。他可以这样提出要求：
请用迭变笔记的文档助手，整理这些 PDF，把信息填入这个 Word 模板；找不到的字段请标出来，并保留出处，方便我核对。
在这个方案示例中，用户先连接服务并完成授权，随后通过我们实现的上传接口传递允许处理的材料。WorkBuddy 调用文档任务入口，服务器上的 Agent 安排解析、字段核对和模板生成，最后返回文件与待确认项。
如果任务时间较长，可以先返回任务编号，让用户查询进度；遇到材料缺失，再把问题交回 WorkBuddy，请用户补充。服务器需要实现这些过程，MCP 提供的是调用接口。
图 1｜任务如何往返。公开的能力说明帮助客户端调用工具；核心方法在服务器上执行。这是服务设计示意。
这种接入有官方接口基础。WorkBuddy 支持自定义 MCP 连接器，远程服务可通过 HTTPS 的 SSE 或 Streamable HTTP 接入。用户连接并授权之后，便能在任务中调用外部能力。WorkBuddy 连接器开发说明、客户端连接器操作说明
可以把四个角色这样理解：WorkBuddy 是用户的工作入口；MCP 是双方约定的调用方式；Agent 负责组织任务；Skills 保存具体方法、判断规则与配套资源。
不发核心 Skill 也能调用服务
MCP 工具会提供名称、用途和参数格式。模型根据这些说明与用户要求选择工具，所以通常不需要一句必须逐字匹配的“触发口令”。MCP 工具规范
例如，文档入口的说明可以写清楚：“从 PDF 和 Word 材料中提取信息，核对出处，并按指定模板生成文档。”用户明确说“用迭变笔记文档助手处理”，更有利于选中我们的服务；最终调用仍取决于工具是否启用、权限和模型判断。
WorkBuddy 官方文档明确说明：MCP 已提供标准工具描述时，客户端 Skill 是可选的。对于复杂任务，我们也可以给客户端一份简短说明，教它怎样传材料、查询进度和处理补充问题。完整的提取规则、核对方法、模板逻辑仍留在服务器上。客户端 Skill 的作用
用户拿到的是调用入口和使用说明，服务方维护的是执行能力。仅把一个 SKILL.md 放到服务器还不够：那里必须运行能够读取方法、调用工具并交付结果的程序。
能力广的 Agent 可以按业务分组
如果服务覆盖文档、内容和软件开发，我倾向于给用户三个清楚的业务入口。文档组处理提取、核对和模板；内容组处理研究、写作和配图；开发组处理网站、App 和客户端相关任务。
这些入口可以作为同一个 MCP 连接器提供的多个工具。每个工具说明自己擅长的任务，服务器再决定交给哪些 Agent。用户需要知道“找哪一组”，内部执行细节由服务方维护。MCP 多工具接口
图 2｜入口按业务分组，内部按任务协作。综合入口用于跨组任务；这是我们可以设计的结构，并非 WorkBuddy 自带的服务器团队。
跨组任务还可以有一个综合入口。例如“研究这个行业，写一篇文章，再做一个展示网页”，由总调度 Agent 协调研究、创作和开发。如果各组需要独立安装、授权或面向不同客户，再考虑拆成不同连接器。
服务能力应写得具体。“什么都能做”很难帮助用户判断，也容易让客户端选错工具。综合入口同样需要说明适用任务、需要哪些输入、能够交付什么。
我看重的四个价值
用户可以继续使用熟悉的客户端
用户已经习惯在 WorkBuddy 中提要求、提供材料和查看结果，远程服务便有机会成为他现有工作过程的一部分。接入以后，使用者可以把注意力放在需求和验收上，减少安装解析工具、配置运行环境和更新能力包的负担。
这仍需要一次连接与授权，也取决于服务能否把材料传输、进度和下载做好。入口越简单，背后越需要可靠的实现。
专业方法能够集中维护
字段漏提、表格错位、模板变化，都需要修改方法。如果核心流程在服务器上，我们可以集中更新依赖、规则和模板，验证后再发布。用户不必逐人安装新包，服务方也能保留版本并在出错时回退。
这让经验更容易持续积累：一次真实问题产生一条处理规则，一条规则经过验证，再服务下一位用户。更新的价值，最终要体现在结果上。
多种能力能够组合交付
用户的任务往往跨越几种专业。例如整理材料后，要形成汇报，再配图或搭建展示页面。把能力按组组织，让它们共享明确的任务要求与交付约定，就有机会把一段工作连续完成。
协作效果取决于任务拆分、数据传递和结果检查。文档组交出的字段与出处，内容组要能正确理解；开发组采用的材料，也需要经过确认。增加 Agent 数量本身无法保证质量。
可以围绕真实需求经营持续服务
我们能够根据服务中暴露的问题改进方法：哪些模板反复出现，用户为什么补充材料，哪些结果仍需要大量修改。反馈收集应建立在用户知情和授权基础上，也可以只记录故障类型等必要信息。
图 3｜能力在真实任务中迭代。反馈可以来自失败、待确认项和用户修订；改进后需要验证，再投入下一次服务。
我更看好这种能不断接受检验的能力。为别人解决“如何解析 PDF”“如何填好 Word 模板”这样具体的问题，可以逐渐积累案例、方法与信任，也让用户看见我们能够提供怎样的培训和合作。
收费与长期价值都要落到交付上
这类服务可以探索按任务收费、订阅额度，或为企业提供模板定制、系统接入、培训与持续维护。每种收费方式都要讲清楚交付范围、额度、失败处理和后续支持。
运行账也要分清：WorkBuddy 侧的模型理解与调度可能消耗用户的积分；我们服务器上的模型调用、存储和运维，则需要另行承担并计入服务成本。远程智能体的执行费用不能默认由用户的客户端套餐覆盖。WorkBuddy 积分消耗说明
核心 Skills 留在服务器上，减少了完整能力包的分发，有助于控制实现与更新。但这不等于绝对防泄露。接口说明和输出仍会被用户看到，执行程序也需要约束内部信息的返回范围。
长期竞争力来自懂业务、交付稳定、发现问题后持续改进。 仅仅把文件藏起来，并不足以让用户持续付费。
先把一项能力做可靠
要让这个设想成立，需要稳定可用的接口、清楚的进度、失败后的恢复方式，以及能被用户核对的成果。文档任务尤其要保留出处、标出缺失与冲突；企业材料还需要说明发送位置、保存期限、删除方式和权限边界。
本地文件路径不能直接当作服务器可读取的材料。WorkBuddy 能读取文件，与已经把文件上传给服务，是两件需要分别实现的事情；远程 Agent 要操作用户电脑上的文件或软件，也需要客户端在授权范围内配合。
我会从文档处理这样边界清楚的需求开始：先把提取、核对和模板填充做可靠，再扩展分组与协作。用户继续使用自己的工作入口，我们维护自己的专业能力。双方能够清楚地分工，并围绕结果建立合作，这正是我认为这种模式有价值的原因。