真实问答记录

Q1 · AI 的 message 接口或 response 接口有哪些参数？含义是什么？

提问背景：直接列举主流 LLM API 的请求参数和响应字段，作为理解 API 契约的基准。

Anthropic Messages API

Endpoint: POST /v1/messages

Response 返回字段（Anthropic）

OpenAI Chat Completions API

Endpoint: POST /v1/chat/completions

Response 返回字段（OpenAI）

两者核心差异

• Anthropic 的 system 是顶层参数，OpenAI 放在 messages 里 role=system
• Anthropic 没有 frequency_penalty / presence_penalty
• Anthropic 支持 top_k，OpenAI 不支持
• OpenAI 支持 n、seed、response_format，Anthropic 不支持
• 两者都支持流式（stream）和工具调用（tools）
• 停止原因命名不同：stop_reason（Anthropic）vs finish_reason（OpenAI），值也不同

Q2 · 怎么权衡 cache 和长上下文？

提问背景：Prompt Caching 要求前缀稳定才能命中；长上下文意味着每次对话前缀都在变化，缓存命中率下降。核心矛盾是缓存效率与上下文丰富度之间的权衡。

核心矛盾

缓存效率 ←————————→ 上下文丰富度
（成本低、延迟低）      （信息全、理解准）

三种策略对比

1. 全量上下文（不缓存）

• 优点：模型拥有完整对话历史，理解最准确
• 缺点：token 成本高、延迟大，随对话增长线性恶化
• 适用：短对话、高价值场景（如代码审查、复杂分析）

2. 激进缓存（固定前缀）

• 优点：成本最低、延迟最低
• 缺点：丢弃历史细节，模型可能"忘记"早期内容
• 做法：将 system prompt 缓存，对话历史只保留最近 N 轮
• 适用：高频、低成本场景（如客服、简单问答）

3. 分层策略（推荐）

┌─────────────────────────────────────┐
│  System Prompt（缓存，稳定前缀）      │  ← 高命中率
├─────────────────────────────────────┤
│  长期记忆摘要（缓存，低频更新）        │  ← 中命中率
├─────────────────────────────────────┤
│  近期对话（不缓存，每轮更新）          │  ← 低命中率但内容少
└─────────────────────────────────────┘

具体权衡指标

实用技巧

1. 滑动窗口 + 摘要：保留最近 5-10 轮原文，更早的对话用 LLM 压缩成摘要放入缓存区
2. 结构化缓存 key：将稳定部分（system prompt、用户画像）放最前，变化部分（对话历史）放最后，最大化缓存命中
3. 按需召回：用向量检索从历史中召回相关片段，而非全量塞入上下文
4. 成本监控：对比 cache read（便宜 10x）vs cache miss 的成本，动态调整缓存粒度

一句话总结

稳定的放缓存，变化的放上下文，用摘要做桥梁，用检索补细节。

Q3 · Skill 渐进式加载怎么实现？依赖哪些工具？

提问背景：理解 agent 系统中 skill 的按需加载机制，以及它依赖的工具链。

核心思路

全量加载：启动时把所有 skill 内容塞进 context → 浪费 token、启动慢
渐进加载：只加载索引，按需加载完整内容 → 节省 token、响应快

实现机制

第一层：元数据索引（启动时加载）

system-reminder 中只注入 skill 名称 + 一句话描述。例如：

- superpowers:brainstorming — You MUST use this before any creative work
- superpowers:test-driven-development — Use when implementing any feature
- lark-im — 飞书即时通讯：收发消息和管理群聊

这一层占用极小，只够模型判断"要不要用这个 skill"。每个 skill 约 50 tokens。

第二层：完整内容（按需加载）

当模型决定使用某个 skill 时，调用 Skill 工具：

Skill(skill: "superpowers:brainstorming")

工具返回该 skill 的完整 prompt 内容，注入当前对话上下文，模型按指令执行。

第三层：子依赖（链式加载）

某些 skill 内部会引用其他 skill 或资源，按需进一步加载，而非预先全部展开。

依赖的工具链

设计要点

1. 索引与内容分离

索引（始终在 context 中）：skill name + 1句描述 → ~50 tokens/skill
内容（按需加载）：完整 prompt → 500~5000 tokens/skill

2. 触发判断由模型完成

• 模型根据用户意图 + 索引信息判断是否需要某个 skill
• 判断标准写在每个 skill 的 description 字段里

3. 加载即执行

• Skill 加载后直接变成当前轮的指令，模型立即遵循
• 不需要额外的"激活"步骤

通用化设计（伪代码）

class SkillRegistry:
    def __init__(self):
        self.index = {}    # name -> description (always in context)
        self.content = {}  # name -> full prompt (lazy loaded)

    def get_index(self) -> str:
        # 返回所有 skill 的摘要，注入 system prompt
        return "\n".join(f"- {k}: {v}" for k, v in self.index.items())

    def load(self, skill_name: str) -> str:
        # 按需读取完整内容
        if skill_name not in self.content:
            self.content[skill_name] = read_file(f"skills/{skill_name}.md")
        return self.content[skill_name]

关键设计选择

• 索引粒度：名称+描述 vs 名称+触发条件 vs 名称+完整 schema
• 缓存策略：加载后缓存 vs 每次重新读取（允许 skill 热更新）
• 冲突处理：多个 skill 同时触发时的优先级（当前实现：process skill > implementation skill）

一句话总结

索引常驻、内容懒加载、模型决策触发、工具链执行 —— 用最小的 context 成本覆盖最大的能力范围。

Q4 · 哪些工具适合 tools，哪些适合 skill/cli？如何权衡？

提问背景：AI Agent 系统中，能力应该实现为 Tool、Skill 还是 CLI，判断依据是什么。

三者本质区别

Tool：模型直接调用的原子能力，返回结构化结果
Skill：注入模型的流程/方法论，指导"怎么做"
CLI：终端原生命令，模型通过 Bash 间接调用

适合做成 Tool 的特征

典型例子：文件操作（Read/Write/Edit/Glob/Grep）、代码执行（Bash）、网络请求（WebFetch/WebSearch）、浏览器控制（Playwright）、子任务调度（Agent/TaskCreate）。

适合做成 Skill 的特征

典型例子：开发流程（TDD、brainstorming、code review）、工作流编排（会议纪要整理、日报生成）、最佳实践（debugging 方法论、git 提交规范）、领域知识（API 使用指南）。

适合做成 CLI 的特征

典型例子：包管理（npm/yarn/pip）、版本控制（git/gh）、构建工具（webpack/vite/make）、部署工具（docker/kubectl/terraform）、云服务 CLI（aws/gcloud/az）。

决策矩阵

                    原子性高
                       │
                       ▼
              ┌────────┴────────┐
              │                 │
         高频使用           低频使用
              │                 │
              ▼                 ▼
           Tool             CLI
        (Read/Write)     (git/npm)

                    原子性低
                       │
                       ▼
              ┌────────┴────────┐
              │                 │
         流程固定           需要判断
              │                 │
              ▼                 ▼
           CLI             Skill
      (固定脚本)        (TDD/debug)

灰色地带的权衡

场景：代码审查

• 做成 Tool：review_code(file_path) → 返回审查结果。优点：调用简单；缺点：审查标准硬编码，难以自定义
• 做成 Skill：加载 code-review skill，模型按流程审查。优点：标准可演进，能结合上下文；缺点：消耗 token，执行慢
• 做成 CLI：eslint / pylint / sonar。优点：成熟稳定；缺点：只能做静态分析，缺乏语义理解

推荐：Skill + CLI 组合 —— skill 指导审查流程，CLI 做静态检查，模型做语义审查。

场景：数据库查询

• 做成 Tool：query_db(sql) → 返回结果。优点：直接；缺点：安全风险，需要模型写 SQL
• 做成 Skill：加载 db-query skill，教模型安全查询规范。优点：可以注入安全最佳实践；缺点：仍需配合 tool 或 CLI
• 做成 CLI：psql / mysql 客户端。优点：功能完整；缺点：输出解析麻烦

推荐：Tool（封装连接和安全检查）+ Skill（注入查询规范）。

一句话总结

Tool 做原子能力，Skill 做流程方法，CLI 做现有工具 —— 复杂场景三者组合使用。

拓展问题

以下是基于上述 4 个原始问题可以进一步深挖的方向，部分已在 Session 10 和 Session 11 中展开为面试题。

围绕 Q1（API 参数）可拓展

• Streaming 模式下 SSE 事件类型有哪些？如何组装 tool_use 的流式 chunk？
• tool_choice 的 auto/any/tool 三种策略在什么场景下用哪种？
• stop_reason 的每种值对应用层意味着什么？如何据此决定下一步动作？
• response_format 的 json_object 模式有什么陷阱？和 tool calling 取 JSON 哪个更可靠？
• OpenAI 的 n>1 多候选返回如何影响成本和延迟？什么场景值得用？

围绕 Q2（Cache vs 上下文）可拓展

• Anthropic 的 cache_control 有哪些断点控制？如何手动指定缓存边界？
• 缓存盈亏平衡点怎么算？给定 QPS 和平均 token 数，缓存策略是否划算？
• 对话超过窗口时，摘要保留哪些内容、丢弃哪些？如何验证摘要没丢关键状态？
• 多用户场景下，用户画像摘要应该放在缓存层还是每轮注入？
• RAG 检索结果和对话历史的缓存策略有何不同？

围绕 Q3（Skill 加载）可拓展

• Skill 的 description 字段写多长合适？太短误触发，太长浪费索引 token，怎么平衡？
• 多个 Skill 同时被触发时，如何决定执行顺序和优先级？
• Skill 内部引用其他 Skill 时，如何避免循环加载和 context 爆炸？
• Skill 热更新如何通知运行中的 agent？是否需要中断当前会话？
• 如何评估一个 Skill 是否真的有效？有 skill 和无 skill 的 paired eval 怎么设计？

围绕 Q4（能力分层）可拓展

• 什么时候应该把 CLI 包装成 Tool？包装的边界在哪？
• Tool schema 变更是 breaking change，如何做版本管理和灰度发布？
• 50 个 Tool 平铺给模型 vs 分组注册，选择准确率差异有多大？
• Skill 和 system prompt 中的指令有什么本质区别？什么时候用哪个？
• MCP（Model Context Protocol）如何解决跨厂商的工具注册和发现问题？

与 Sessions 的对应关系

建议学习路径：先读本页保留的原始答案建立知识基准，再进入对应 Session 做面试题化训练。