Agent 怎么沉淀技能:把一个好 prompt 变成全队资产

团队中有人利用 Claude Code 打磨出了一套效果极佳的 prompt 指令，例如“重构前先执行测试、修改完成后运行一遍 lint、提交信息遵循约定式提交格式”。这套工作流程对全队都有很大帮助，但问题在于它只存在于那位同事的脑海和本地配置里。一旦换人操作或更换 Agent，这一经验就会丢失。

市面上的 chatbot 之所以不存在此问题，是因为它们根本没有“团队”这一概念——每次对话都是从头开始。然而 Multica 把 Agent 视为真正的同事，同事会轮班、会扩招，经验必须能够沉淀下来并跟随组织，而不是依附于个人。通过通读代码可以发现，Multica 给出的答案是 Skills 系统。

本篇要解决的核心问题

设想一下，团队里有位同事用 Claude Code 整理出了一套近乎完美的 prompt，例如“重构前先跑测试、改完跑一遍 lint、提交信息按约定式格式”。这套方法对全队极具价值，但问题依然在于它只存在于那位同事的头脑和本机配置里。换个人、换个 Agent，这套经验就会消失。

市面上的 chatbot 没有这个难题，因为它们根本不具备“团队”概念——每次对话都是从零开始。但 Multica 将 Agent 视为同事，同事会换班、会扩招，经验必须沉淀下来随组织走，而不是随个人走。仔细阅读代码后可以发现，Multica 的解决方案就是 Skills 系统。

心智模型：一个 skill 就是一个 SKILL.md 文件

一个 skill 的本质很简单：一个 SKILL.md 文件，外加可选的辅助文件（脚本、配置、参考模板）。SKILL.md 中记录的是“遇到这类任务该如何思考、如何执行”。

Multica 采用了 Anthropic 的 Agent Skills 开放标准，因此任何符合规范的 skill（来自 Anthropic 官方仓库、ClawHub、skills.sh 上的包）都能直接导入。这是一个明智的选择——不创造新格式，而是建立在逐渐形成的行业标准之上。

skill 有两种来源：

工作区 skill 存储在 Multica 云端，挂载到智能体后，任务执行时会自动同步到你的本机——这是团队共享的标准方式。本机 skill 直接存放在你的本地目录，适合先进行测试或涉及敏感本地信息的场景。

深度点一：为什么“同步到本地”如此关键

这里有一个容易被忽略但却极其重要的设计原则：skill 最终必须落到执行它的那台机器上。

回顾第 1 篇文章：Agent 并非在服务器上运行，而是在你的机器上运行。所以 skill 不能只存在于云端——它必须出现在你本机 AI 工具能够读取的位置。Multica 在执行任务时，会将该 Agent 上挂载的所有 workspace skill 同步到本地。

// server/internal/daemon/local_skills.go
// 任务执行时：workspace skill → 同步到本地工具约定的目录
// localSkillRootForProvider tracks the user-level skill locations
// exposed by each provider's CLI

这就是为什么 skill 的注入路径每款工具都各不相同——因为每款工具读取 skill 的目录是由工具自身决定的，Multica 只能遵循各家的规则将文件放置到正确的位置：

值得注意的反直觉点：当你在 Multica 中为一个 Gemini Agent 挂载了 skill，Multica 会老老实实地同步到 .agent_context/skills/ 目录，但 Gemini 这款工具本身可能根本不会读取这个目录。Multica 把文件放对了，但工具是否采纳则是工具自身的事。

skill 从云端到本地执行进程的完整同步链路如下：

这就是为什么 skill 在不同工具上的生效程度各有差异——这不是 Multica 的 bug，而是工具自身能力边界所致。

深度点二：slash 链接——让 skill 在文档中可被显式引用

通过通读代码可以发现一个巧妙的设计，位于 server/internal/daemon/slash_skill.go。skill 不只是被动等待工具读取，Multica 还支持在 prompt 中使用 slash 链接来显式引用某个 skill：

// server/internal/daemon/slash_skill.go
// 匹配 [名字](slash://skill/) 这种链接
// ExtractSlashSkills(md string) []SlashSkillRef

[重构指南](slash://skill/multica-refactor) 这种写法会被解析出来，并在任务执行时将对应 skill 的内容注入。这使得 skill 变成了可引用的知识单元——你可以在 issue 描述、评论、autopilot 的 prompt 中直接指名要求某个 skill 介入，而不是寄希望于工具自己发现它。

这个设计的全栈闭环为：前端的 skill 管理 UI（创建/导入/挂载）→ Go 的 skill 存储持久化 → 任务派发时 daemon 将 workspace skill 同步到本地 → slash 链接解析并注入到 prompt → AI 工具执行时读取。整条链路将“云端定义的团队知识”可靠地送到了“本地执行的那个进程”手中。

深度点三：Multica 自己用 skill 教 Agent 使用 Multica

一个特别有意思的设计：Multica 内置了一套 skill，用于教 Agent 如何操作 Multica 本身。

// server/internal/service/builtin_skills/
// multica-autopilots / multica-creating-agents
// multica-mentioning / multica-projects-and-resources
// multica-runtimes-and-repos / multica-skill-importing
// multica-squads / multica-working-on-issues

这 8 个内置 skill 是元级别的——它们让 Agent 学会“在 Multica 里如何 @人、如何创建 issue、如何配置 autopilot”。一个被分配任务的 Agent 如果需要了解平台机制（比如“我该把这个子任务派给谁”），它可以调用这些内置 skill 来获取指引。

这是一个自举（self-bootstrapping）的设计：平台利用自身最核心的能力（技能系统）来教会运行在它之上的 Agent 如何用好这个平台。这比编写一份给 Agent 阅读的文档要可靠得多——skill 会被同步到本地、被 slash 引用、被工具按约定路径读取，而文档只会躺在网页上无人问津。

这就是 Multica 对“经验沉淀”的完整解答：skill 是知识的载体，workspace/local 双来源覆盖了团队共享和本地敏感两种场景，工具差异通过各自的注入路径被吸收，slash 链接让知识可被显式调用，内置 skill 使平台能教 Agent 使用自己。一个 2 人团队的 best practice，一旦挂载为 skill，新加入的第 10 个 Agent 立刻就能继承。

下一篇将探讨同事多了如何分工——Multica 的 Squad 如何让你 @ 一个团队而不是某个人。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Agent 怎么沉淀技能:把一个好 prompt 变成全队资产要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题