第 6 章：从“万能工”到“专家团”——Skill 技能系统与角色定义

第 6 章：从“万能工”到“专家团”——Skill 技能系统与角色定义

"通才往往意味着平庸。"

在 Agent 的世界里，没有什么“万能提示词”。Skill（技能）系统的本质，就是把 System Prompt（人设）、工具白名单（装备）和参数约束（纪律）打包成一张张“职业卡”，让 Agent 能够在“代码审计师”和“市场研究员”之间一键切换。

6.1 核心痛点：瑞士军刀的尴尬

在前几章，我们解决了工具调用（手脚）和 MCP 互联（接口）的问题。现在，你的 Agent 拥有了访问 GitHub、搜索网页、查询数据库的能力。看起来很强大，对吧？

但当你试图用同一个 Agent 既写代码又写诗时，问题出现了：

1. 认知干扰：你让它做市场调研，它却总是试图用 Python 代码来分析文本，因为它记得自己是个“程序员”。
2. 工具迷茫：你给它挂载了 50 个工具，它在回答简单问题时，为了“表现自己”，非要调用几个无关的 API，导致响应变慢且昂贵。
3. 安全隐患：你只是想让它写个文案，但它手里却握着“删除数据库”的工具，这就像让实习生拿着核按钮去买咖啡。

这就是“通用 Agent”的困境——就像瑞士军刀，虽然什么都能干，但切牛排不如餐刀，锯木头不如电锯。

为了解决这个问题，我们需要引入 Skill（技能）系统，或者更准确地说，Role（角色）系统。

6.2 本质还原：一张标准的“职业卡”

Skill 到底是什么？它不是一段神奇的代码，而是一份“岗位说明书” (Job Description)。

在 Shannon 框架中，一个标准的 Skill 包含三个核心要素，公式如下：

$Skill = Persona(人设) + Capability(能力) + Boundary(边界)$

1. Persona（人设）：注入灵魂

也就是 System Prompt。这不仅仅是告诉它“你是一个助手”，而是要定义它的思维模式。

• 对于“代码审查员” ：你要强调“怀疑精神”、“关注边界条件”、“安全第一”。
• 对于“创意作家” ：你要强调“发散思维”、“修辞优美”、“拒绝陈词滥调”。

2. Capability（能力）：工具白名单

也就是 Allowed Tools。这是 Skill 系统中最具工程价值的设计。

• 最小权限原则：一个“文案写手”角色，不需要（也不应该）拥有 shell_execute 或 database_delete 的工具权限。
• 认知减负：只给它任务必须的 3-5 个工具，Agent 的决策会更精准，幻觉会更少。

3. Boundary（边界）：行为约束

也就是 Caps (Parameters) 。这决定了 Agent 的工作风格和成本控制。

• Temperature (创造力) ：审查代码用 0.1（严谨），写小说用 0.8（奔放）。
• Max Tokens (话痨程度) ：简报员限制 500 词，深度研究员放开到 16k。

6.3 深度解剖：如何设计一个“深度研究员”？

让我们通过一个真实的案例——Deep Research Agent，来看看一个高级 Skill 是如何炼成的。

简单的 Skill 可能只有两行字，但一个工业级的 Skill 需要精心编排。

设计理念：元认知 (Metacognition)

普通的 Prompt 只是下指令，高级的 Skill 会教 Agent “如何思考”。

在 Deep Research 的 System Prompt 中，我们植入了以下思维链：

1. 时间感知 (Temporal Awareness) ：

   • 指令：“当前时间是 2026年1月。对于时效性话题，优先查找近 6 个月的资料。”
   • 目的：防止 Agent 拿 2022 年的过时数据来回答 2026 年的问题。

2. 渐进式侦查 (Progressive Investigation) ：

   • 指令：“先进行广度搜索了解背景；每调用一次工具后，自问：‘我拿到的信息够了吗？还有哪些缺口？’；如果不够，基于缺口进行二次搜索。”
   • 目的：打破“搜一次就回答”的懒惰模式，模仿人类研究员的迭代过程。

3. 认知诚实 (Epistemic Honesty) ：

   • 指令：“保持怀疑。搜索结果只是线索，不是事实。如果不同来源有冲突，请同时展示双方观点，不要强行统一。”
   • 目的：提升回答的可信度，避免 AI 编造事实（幻觉）。

战术配置：工具与约束

• 工具箱：web_search (搜), web_fetch (读), web_crawl (爬)。注意：这里没有 file_write，因为研究员只负责看和想，不负责改文件。
• 硬限制：max_tool_calls = 5。这是为了防止 Agent 陷入死循环，一直搜个没完，烧光你的 Token 预算。

6.4 另类流派：Claude Code 的“自然语言编程”模式

在 Skill 的设计光谱上，传统的做法（如 Shannon）是“开发者定义工具”——你需要写 Python 代码来创建工具。而 Claude Code（Anthropic 的 CLI 工具）的 Skill 功能则代表了另一种极端：“用户定义工具”。

1. 什么是 Claude Code 的 Skill 功能？

Claude Code 允许用户通过自然语言来注册一个新的“技能”。你不需要写任何代码，只需要告诉 Agent 这个技能叫什么，以及它是干什么的。

场景： 你是一个项目经理，你不懂如何写 Python 脚本，但你希望 Agent 能一键完成“代码合规性检查”。

定义过程（自然语言） ：

"Hey Claude, learn a new skill called compliance-check. When I ask you to run it, I want you to:

1. Run pylint on the current directory.
2. Run trufflehog to scan for secrets.
3. If any fail, summarize the errors in a markdown table."

Agent 的反应： 它会将这段描述“编译”成一个持久化的配置。下次当你输入 /compliance-check 时，它会自动拆解并执行这一系列步骤。

2. 核心原理：SOP 的可执行化

Claude Code 的 Skill 本质上是 Standard Operating Procedure (SOP，标准作业程序) 的数字化。

• 传统 Skill：Python Code -> Tool Definition -> Agent Execution
• Claude Code Skill：Natural Language SOP -> Orchestration Prompt -> Bash Primitives

它并没有真正生成一个新的 Python 函数。相反，它是在 System Prompt 中注入了一段“元指令”：

"Here is a list of custom skills you know. If the user invokes 'compliance-check', your plan should be to execute pylint and trufflehog using your bash tool..."

3. 为什么这很重要？

这种模式打破了“开发者”和“使用者”的界限：

• 低代码/零代码：任何能把业务逻辑讲清楚的人，都能为 Agent 增加新技能。
• 动态演进：Skill 可以随着业务变化随时修改，不需要重新部署代码。
• 原子能力复用：这种 Skill 建立在底层原子能力（如 bash, file_edit）之上，组合极其灵活。

对比总结： 如果说 Shannon 的 Skill 是“精密的瑞士手表”（结构严谨，出厂即定），那么 Claude Code 的 Skill 功能就是“乐高积木”（原子简单，用户自己拼搭）。

6.5 动态与静态：Prompt 的渲染艺术

Skill 定义通常是静态写在配置文件里的（Static Config），但现实世界是动态的。

一个好的 Skill 系统需要在运行时进行“动态注入” (Dynamic Injection)。

1. 变量替换 (Templating)

比如“数据分析师”角色，它的 Prompt 里不能写死用户的 ID。

You are analyzing data for User ID: ${user_id}
Current Project Context: ${project_desc}

在运行时，系统会把 ${user_id} 替换成真实的 12345。这就像 HR 给新员工发工牌，工牌模板是一样的，但上面的名字和部门是动态填写的。

2. 环境感知 (Context Injection)

Agent 需要知道它身处何地。Shannon 会在 System Prompt 的开头自动注入环境信息：

• 当前日期：让 Agent 有时间观念。
• 用户语言：如果用户用中文提问，强制 Agent 用中文回复。
• 所处环境：是“测试环境”还是“生产环境”？如果是测试环境，Agent 可能会更详细地输出调试信息。

6.6 工程模式：Vendor Adapter (供应商适配)

在商业落地中，我们经常遇到这样的需求：

“我要一个 GA4 分析师，一个 Salesforce 分析师，还有一个飞书文档助手。”

它们本质上都是“分析师”或“助手”，但背后的工具和知识库完全不同。

Shannon 采用 Adapter（适配器）模式 来管理这些 Skill：

• Base Role（基类） ：定义通用的分析逻辑（“先看数据，再找异常，最后给建议”）。

• Vendor Role（实现类） ：

  • GA4 Role：继承基类，绑定 ga4_query 工具，注入 Google Analytics 的字段定义知识。
  • Salesforce Role：继承基类，绑定 crm_search 工具，注入销售漏斗的领域知识。

这种设计让核心逻辑（How to analyze）和领域知识（What to analyze）解耦，方便扩展。

6.7 避坑指南：由血泪换来的经验

陷阱 1：System Prompt 写得像“许愿池”

• 错误：“你是一个有用的助手，请帮我把工作做好。”（太模糊，Agent 只能猜）
• 正确：“你是一个技术文档以此人员。你的输出必须遵循 Markdown 格式。对于代码示例，必须包含注释。不要使用敬语，保持客观冷静。”（具体、可执行）

陷阱 2：工具权限“大撒把”

很多开发者为了省事，给所有 Skill 都挂载了全套工具（All-in-One）。 后果：

1. 安全性：一个只是用来聊天的角色，却拥有了删除文件的权限，一旦被 Prompt 注入攻击，后果不堪设想。
2. 准确性：工具越多，Agent 选择错误的概率越大（选择悖论）。 原则：最小权限 (Least Privilege)。只给它完成任务必须的最小工具集。

陷阱 3：参数约束缺失

忘了设置 max_tokens 或 timeout。 后果：某个 Agent 遇到死循环逻辑，在那儿自言自语了 10 万个 Token，直到把你这个月的 API 额度刷爆。

5.8 总结：角色定义的护城河

Skill 系统不仅仅是配置文件的堆砌，它是 Agent 走向专业化和工程化的分水岭。

1. 专业分工：通过 Skill，我们将通用的 LLM 切割成了无数个专用的“数字员工”。
2. 安全隔离：通过工具白名单，我们限制了 AI 的破坏半径。
3. 知识复用：精心调教的 Prompt 和工具组合可以被打包、版本化、分发。

现在，我们的 Agent 已经有了强健的手脚（MCP 工具），也有了清晰的职业身份（Skill 角色）。它能看、能做、也能像专家一样思考。

但是，在它执行任务的过程中，我们怎么知道它有没有跑偏？如果它在疯狂烧钱怎么办？如果它在做危险操作前，我们需要人工审批怎么办？

这就是下一章的内容——Hooks 与事件系统。我们需要给这个数字员工装上“监控摄像头”和“审批流”。