Skill 和Tool分别是什么，通俗类比
Function‑call / Tool：是单个工具原子，比如调用百度搜索、调用数据库，相当于「扳手、螺丝刀」单个工具。- Skill：一套完整业务操作手册 + 流程 SOP，相当于一本完整维修说明书，告诉 Agent 遇到某类任务，第一步做什么、第二步做什么、遵循什么约束、输出什么格式、哪些事不能做火山引擎文...。
Skill 内容可以包含：
- 业务处理步骤 SOP（例如工单分诊流程、数据分析流程）
- 领域约束规则、合规要求
- 输出 JSON/markdown 格式模板
- 工具调用的使用建议（应该什么时候调用哪个 tool）
- 示例 few‑shot 样例
Skill 解决什么痛点（现实问题）
痛点 1：System Prompt 无限膨胀，难以维护
如果把几十条业务 SOP、约束、格式全部塞到system_prompt字符串里面：
- 几千上万字，prompt 巨大，token 消耗高；
- 修改流程要改代码，没法版本管理；
- 多个 Agent 复用同一套业务流程，要复制粘贴一大段提示词。
Skill 解决：业务流程抽成独立 Skill 包。多个 Agent 直接引用同一个 skill‑id；更新 Skill 版本，所有引用它的 Agent 自动生效，不用修改每个 Agent 的 prompt 代码火山引擎文...。
痛点 2：复杂业务流程写在 prompt 里面模型容易遗忘步骤
比如工单处理：1 确认现象 →2 收集证据 →3 评估严重等级 →4 输出处理建议。 直接写在 system prompt，大模型多轮对话经常跳步骤、漏步骤。
Skill 解决：把完整 SOP 固化进 Skill，Agent 遇到匹配场景自动加载这份操作手册，强制引导模型按步骤执行任务。
痛点 3：业务能力需要跨多个 Agent 复用
公司内部：工单分诊流程，客服 Agent、质检 Agent 都要用同一套处理规范。 不用两份大段 prompt 复制；只维护一份 Skill，多个 Agent 引用。
痛点 4：业务规则迭代、灰度更新
Skill 支持版本，你可以上线 v2 版本做测试，没问题再切正式版本；不需要改动 Agent 本身配置。
Skill不能直接写 Python 代码执行外部接口；真正调用 API、浏览器等外部操作，依然依赖 Function‑call/Tools。Skill 负责告诉模型怎么用好这些工具，按什么流程用，Skill 本身不执行代码。
Skill vs Function‑call (Tool) vs LangGraph Harness 对比（重点）
| 对象 | 定位 | 干什么 |
|---|---|---|
| Function‑call Tool | 原子工具（手脚） | 调用外部 API、浏览器、数据库做实际操作 |
| Skill | 业务 SOP 能力包（操作说明书） | 流程、规则、输出格式、few‑shot，纯提示层面约束模型思考逻辑 |
| LangGraph Harness | 代码层运行驾驭层 | 代码写死循环、状态、分支、最大迭代、异常捕获 |
三者配合：Skill(告诉业务流程怎么做)+Tools(原子工具)+Harness(代码控制循环/状态)一起完成 Agent 任务。
什么时候不适合用 Skill
- 一次性临时任务：不需要封装成 Skill，直接写 system prompt 即可。
- 需要复杂条件分支、状态持久化、死循环防护：优先用 Harness 代码（LangGraph），不要指望 Skill 的 markdown 文档完全控制复杂逻辑，大模型依然会幻觉跳步骤。
简单实例：一个客服工单分诊 Skill
SKILL.md核心片段：
# 工单分诊SOP ## 适用场景：用户提交账号故障工单 1. 复述用户确认的故障现象，**禁止编造信息** 2. 收集缺失关键信息：账号id、报错截图描述 3. 评估故障严重等级 P0/P1/P2 4. 输出结构化JSON结果 > 如果需要查询账号数据，调用query_account工具；不要随意调用无关工具。
