Skill、MCP 与多 Agent 协作

这两个词经常一起出现，但解决的是两类问题： Skill（技能）装的是知识：一类任务怎么做才对——步骤顺序、模板样式、质量标准、常见坑。比如「周报生成 Skill」里写着数据来源、章节结构、语气要求。它回答「这类活的标准打法是什么」。 MCP 装的是接口：一套标准化协议，让外部系统（文档、数据库、浏览器……）能以统一方式接进 Agent，不用每家各写一套私有对接。它回答「手怎么伸出去」。 类比一下：MCP 是标准插线板，Skill 是电器说明书。两者正交，常常配合使用——通过 MCP 连上工单系统（接口），再用客服处理 Skill（打法）去干活。 混着上的典型错误：想提升输出质量却去加新连接器（该写 Skill），想让 Agent 读新系统却拼命改提示词（该接 MCP）。 实际案例对照： 想让 Agent 回复客户更专业 → 写一份「客服话术 Skill」（知识）✅　不是接更多 API ❌ 想让 Agent 能查库存 → 接一个「库存系统 MCP」（接口）✅　不是在提示词里写 SQL ❌ 想让 Agent 自动发工单 → MCP（连工单系统）+ Skill（工单分类和优先级规则）= 配合使用 ✅

把一个 Agent 拆成一个团队（调研员、写手、审核员），收益是分工明确、上下文隔离、互相把关；代价是三笔新账： 通信成本：Agent 之间传递信息会损耗和失真，「我以为你理解了」在机器之间同样发生； 误差传递：上游一个小偏差，到下游放大成大问题； 调试复杂度：出问题时你要排查 N 个 Agent 和它们之间的全部对话。 拆与不拆的判据： 单上下文装不下（资料和规则太多，一个窗口塞不下）→ 值得拆； 环节间需要硬性隔离（生成者和审查者必须无共享偏见）→ 值得拆； 只是「觉得分工听起来更专业」→ 别拆，先让单 Agent 把活干好。 多数场景的正确路径是：单 Agent + 好 Skill 先跑到瓶颈，再考虑拆。

成熟产品里的提示词不是一个文件，而是分层叠加： 系统提示：角色、底线、全局规矩。最高优先级，轻易不动。 长期规则：项目约定、团队规范、领域术语表。中期稳定，按项目维护。 临时指令：本次任务的调整，「这次用中文」「这版短一点」。最低优先级，随用随抛。 冲突时大体遵循：系统 > 长期 > 临时。明白这一点，你就知道该在哪一层改东西——想永久修正行为却每次在对话框里重复交代，就是放错了层，迟早又忘。