一、背景知识篇

Q1. 什么是 /command? 和 skill 的区别是什么? 什么时候用 command (已 deprecated), 什么时候用 skill?

参考答案:

  • /command (Slash Command): 早期 Claude Code 的扩展机制. 用户在 .claude/commands/ 下放置 .md 文件, 通过在对话中输入 /command-name 来触发. 本质是”用户主动调用的 prompt 片段”. 当前在 Claude Code 中已被官方标记为 deprecated, 由 skill 替代.

  • Skill: 新一代扩展机制, 位于 .claude/skills/<name>/SKILL.md (或 ~/.claude/skills/、plugin 中). 区别在于:

    1. 可被模型自主调用 —— Skill 在 YAML frontmatter 里写 description, Claude 会根据语义判断是否启用, 而不仅靠用户敲 /.

    2. 支持附属文件 —— skill 目录里可放脚本、参考文档、子模板.

    3. 生命周期管理 —— skill 在 /compact 时会被重新注入 (前 5K token, 全局 25K 预算).

    4. 细粒度受控 —— frontmatter 可指定 allowed-tools、disable-model-invocation、paths (路径范围限定)、effort、model.

  • 何时使用:

    • 优先 skill: 几乎所有新场景, 尤其是希望模型在合适时机自动启用、或需要附带脚本/示例文件的.

    • command 仍合理的少数场景: 完全确定性的、必须人工显式触发的一行 prompt 包装 (例如某些团队遗留资产); 但新项目不再推荐.


Q2. 什么是 agent? 什么情况下我们使用 agent, 什么情况下使用 skill?

参考答案:

  • Agent (Sub-agent): 一个拥有独立 system prompt、独立上下文窗口、独立工具白名单的”小型 Claude”. 在 Claude Code 中通过 .claude/agents/<name>.md 定义, 由主对话通过 Agent 工具派发. Sub-agent 完成任务后只把”总结”回传给主对话, 中间过程不污染主上下文.

  • Skill: 一段供模型读取的指令/规程 (instructions), 它不开新上下文, 而是在当前对话里指导 Claude 接下来怎么做.

区别本质:

维度 Skill Agent
上下文 共享主上下文 独立上下文
调用代价 低 (只是注入文本) 高 (一次完整推理回合)
适合 “怎么做” 的指导、规范、check-list 大量工具调用、可能产生大量噪声的子任务
结果 改变后续主对话行为 返回一段总结
  • 决策原则:

    • 任务会产生大量工具输出(读几十个文件、跑测试、抓日志) → 用 agent, 避免污染主上下文.

    • 任务是告诉 Claude 一种规程(比如”提交前先跑 lint”) → 用 skill.

    • 任务是只读的探索/搜索 → 优先用 Explore 这类内置 agent.

    • 任务需要多步骤设计且要保留思考过程在主对话 → 不开 agent, 让主对话自己做.


Q3. Sub-agent 是什么? Sub-agent 之间可以互相通信吗?

参考答案:

  • Sub-agent: 见 Q2. 关键特征是”独立上下文 + 独立工具集 + 只回传 summary”.

  • 能否互通?

    • 默认不能直接通信. Claude Code 的 sub-agent 通信模型是星型: 所有 sub-agent 只与主对话通信, 主对话作为 hub 在它们之间转发信息.

    • 实验性 Agent Teams (需要开启 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) 引入了 SendMessage 工具, 才允许同级 agent 间用 ID 直接发消息; 但这是另一套模型 (见 Q4).

  • 设计原因: 强制信息汇聚到主对话, 保证状态可追溯、可审计, 也防止 agent 之间形成不可控的循环对话.


Q4. Agent Team 和 Sub-agent 之间最大的区别是什么?

参考答案:

  • Sub-agent: “雇一个临时工去做一件事, 回来汇报”. 一次性、星型、汇报式. 主对话发起 → sub-agent 执行 → 返回 summary → sub-agent 即销毁.

  • Agent Team: “组建一个长期协作的团队, 成员之间可以互相喊话”. 持续性、可互通、并行.

    • 每个 teammate 拥有持久的独立上下文.

    • 通过 SendMessage(to=<agent_id>, message=...) 直接互发消息.

    • 适合”多个长期角色并行推进”的场景 (例如 frontend 工程师 + backend 工程师 + reviewer 同时工作).

  • 最大区别:

    • 拓扑: Sub-agent 是”主→子”的树; Agent Team 是”成员之间互通”的图.

    • 生命周期: Sub-agent 是 fire-and-forget; Teammate 是长期存在.

    • 状态共享: Sub-agent 只返回最终 summary; Teammate 之间可来回讨论, 维护持续上下文.

  • 取舍: Agent Team 更接近”多 agent 协作”研究方向, 但也更难调试、更容易上下文爆炸; 大多数日常任务用 sub-agent 就够.


Q5. MCP 是什么? 它和 API 接口的区别是什么?

参考答案:

  • MCP (Model Context Protocol): Anthropic 主导、现已开源的协议, 用于把”外部工具/资源/prompt”以标准格式暴露给大模型. 一个 MCP server 进程可同时声明它提供哪些 tools、resources、prompts, 客户端 (Claude Code、Claude Desktop、Codex 等) 通过统一协议发现并调用. 与”直接调 API”的区别:
维度 裸 API MCP
描述方式 自然语言 + 文档, 每个 LLM/客户端自己实现适配 标准 schema, 一次声明全网客户端通用
工具发现 需要预先告知模型 客户端连接时自动 list tools
鉴权 各 API 自己一套 标准 OAuth 2.0, 支持 dynamic client registration
传输 HTTP 各异 stdio / HTTP / SSE 三种标准传输
复用 每个 LLM 平台都要重做 一份 MCP server, 所有支持 MCP 的客户端可用
  • 类比: API 是”USB 线”, 每家形状不一样; MCP 是”USB-C”, 给所有 LLM 客户端统一接口.

  • 本质区别: MCP 不仅传数据, 还自描述能力 —— 工具签名、参数 schema、是否可写、是否需要确认, 模型据此推理”何时调用、怎么调用”.


Q6. Sub-agent 可否再衍生 (派生) 它自己的 sub-agents?

参考答案:

  • 不可以. Claude Code 官方文档明确说明: sub-agent 无法再启动 sub-agent.

  • 原因:

    1. 防止无限递归 —— 一旦允许嵌套, agent 树深度不可控, 调试和成本控制变成噩梦.

    2. 保持信息汇聚 —— 所有总结必须回到主对话, 才能让用户和主 agent 有完整可审计的轨迹.

    3. 避免上下文窗口指数爆炸 —— 嵌套调用每层都是独立 context, 容易把账单和延迟拉爆.

  • 如果确实需要”嵌套委托”, 怎么办?

    • 在 sub-agent 里使用 skill 来组织内部步骤 (skill 不开新上下文).

    • 让主对话串行并行地多次派发 sub-agent (扁平化).

    • 使用 Agent Team 模型 (但那是平级互通, 不是嵌套).