Agent 技术栈分层：Tool / MCP / CLI / Skill / Harness（The Agent Stack）

所属：01-fundamentals / 04-agent-architecture
面试权重：★★（这是「定位题」，不是「深度题」 —— 它不考你懂多深，考你能不能把已经知道的东西摆到正确的位置上）
来源：小红书《腾讯 Agent 二面凉经带答案》（A 级真题第 8 题，517 赞，内容全在 11 张图里）→ 原始摘录见 02-interview/questions/xhs-reports.md §4.10 + 通用领域知识；未做一手考证
相关知识点：本文是缝接材料，不是新知识块 —— tool-use.md（Tool 层）、10-tool-discovery.md（工具形态与披露）、mcp.md（MCP 层）、context-engineering.md（Prompt 的位置）、05-agent-evaluation/agent-eval.md 与 06-agent-infra/observability.md（Harness 的评测含义）、02-post-training/08-agentic-rl.md（Harness 的训练含义）、12-continual-evolution.md（Harness 作为门禁/否决器）

一句话#

面试官把 MCP / Prompt / CLI / Skill / Harness 这几个词摆在一起问「什么关系」，考的不是定义（每个都有标准答案），而是你能不能把它们分到不同的层。一句话的关系是：

Harness 评测 Agent，Agent 调用 Skill，Skill 通过 MCP 调用 CLI 等底层工具，Prompt 贯穿全程。

为什么重要（面试角度）#

• 它背不下来。单个概念都能查定义，但「这几个词怎么摆」没有标准答案清单 —— 它直接暴露你脑子里有没有一个统一的架构模型。
• 它是开场定位题。面试官问完这五个词，就知道后面该往哪一层深问；答得散，后面讲项目也失去坐标系。
• 它和每个项目都相关：QueWI 的 MCP 工具链、Writing Copilot 的 agent 编排、任何 agent 的评测。答好了是一次低成本的加分。
• 它有明确的易错点：最常见的错法是把不同层的东西并列比较（「Skill 和 MCP 有什么区别」这种问法本身是陷阱 —— 它们不在同一层，没法比）。

核心内容#

1. 先给一张分层图#

┌───────────────────────────────────────────────────────────┐
│ Harness（框架环境）                                        │  跑 / 评 / 调
│   批量运行 Agent、收集轨迹、自动打分、回归与 A/B             │
│  ┌─────────────────────────────────────────────────────┐  │
│  │ Agent（由 LLM 驱动的执行循环：推理—行动—观察）        │  │  决策
│  │  ┌───────────────────────────────────────────────┐  │  │
│  │  │ Skill（面向任务的可复用能力单元）              │  │  │  任务
│  │  │   = Prompt + 工具调用编排 + 控制逻辑           │  │  │
│  │  │  ┌─────────────────────────────────────────┐  │  │  │
│  │  │  │ MCP（协议：统一怎么接、怎么描述、怎么调）│  │  │  │  接入
│  │  │  │  ┌───────────────────────────────────┐  │  │  │  │
│  │  │  │  │ Tool / CLI（可执行的能力）         │  │  │  │  │  执行
│  │  │  │  └───────────────────────────────────┘  │  │  │  │
│  │  │  └─────────────────────────────────────────┘  │  │  │
│  │  └───────────────────────────────────────────────┘  │  │
│  └─────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────┘
          Prompt 不占某一层 —— 它贯穿以上全部

读图三句话：

1. 从下往上，抽象层级递增：能力 → 接入 → 任务 → 决策 → 评测。
2. 每层只解决自己那层的问题，所以跨层比较是范畴错误。
3. Prompt 不是一层，它是每一层都在用的媒介 —— 这是最容易答错的一处（很多人会把它错摆成「最上面一层」）。

⚠️ 这张图有一处故意反直觉的地方，必须先说清，否则下面整段都会读错。

图里把 Harness 画在最外层、包住 Agent —— 这是评测视角的读法：把 Agent 跑起来、批量评它的那套设施。

但 2026 年的主流用法（也是《深入理解 AI Agent》第 1 章的用法）恰好相反：

Agent = Model + Harness，其中 Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正

「Harness 不是模型之外的一切，而是 Agent 边界之内、模型之外的运行与治理层。」

也就是说，书里的 Harness 是 Agent 的组成部分，不是包住 Agent 的外部环境。这两种读法说的不是同一件东西，混着用会直接跑题 —— 面试官按书的语义问「你的 Harness 里约束、验证、纠正怎么做的」，你答成「我用 LLM-as-Judge 做评测」，就完全答偏了。详见 §3「关键区分 3」。

2. 逐层拆解#

关键区分 1 —— CLI 的两种角色。 原文点出：CLI 在 agent 系统里可以有两个角色：① Agent 可以去调用的命令行工具，这时它算是一种特殊的 Tool；② Agent 系统本身的交互入口（通过命令行启动一个 Agent 会话）。

原文倾向第一种理解：「CLI 是暴露给 Agent 的一种可执行能力，通过 MCP 包装后，Agent 就能理解和调用它。」 → 所以 CLI 和 MCP 的关系是：CLI 是「被包装的东西」，MCP 是「包装的方式」。

关键区分 2 —— Tool 和 Skill 的分界线。 ⚠️ 先说一个坑：「Skill」这个词目前有两个流通的义项，指的是不同东西。 只答其中一个，遇到另一个语义的追问就会错位。

义项 A 的例子（最好用）：

「『发送邮件』是一个工具（通过 MCP 暴露），但『撰写一封得体的会议纪要邮件并发送』就是一个 Skill。」

后者可能包含：调用 LLM 生成内容 → 调用邮件工具发送 → 调用日历工具更新状态。判据是「单个动作、无状态、可原子执行 → Tool」vs「面向一个任务、内含多步编排与判断 → Skill」。

义项 B 的机制（这是 A 漏掉、也最要紧的属性）：

• Skill 是一个文件夹，里面必有 SKILL.md，文件开头是 YAML frontmatter（name + description 两个字段）。
• 渐进式披露三层：① 元数据层 —— Agent 启动时只看到一份薄目录（每个 skill 的 name 与 description，合计数百 token）；② 核心流程层 —— 判断需要时才加载完整 SKILL.md 正文；③ 顺着正文里的引用再往下一层读脚本或子文档。
• 两条触发路径：用户显式敲斜杠命令（客户端本地展开，不花一次工具调用）；或模型读过目录后自己判断需要、调用专用 Skill 工具（多一次 ReAct 往返）。
• 注入位置很关键：正文在调用位置作为 user message 加入会话（模型自主触发时那条 tool result 只是一句「正在启动 Skill」的占位符，不承载正文）。
• 为什么它对上下文友好：常驻的只有目录，正文按需追加到上下文末尾，不影响已缓存的静态前缀 —— 所以它与 KV Cache 天然相容。
• 分发靠注册表而非协议：npx skills add <owner>/<repo>、ClawHub。MCP 统一的是专用工具的接入，Skill 那一侧用包管理器分发。

两个易错推论： ① 「Skill 和 MCP 不在同一层」这条判断，在义项 B 下依然成立，但理由变了 —— 义项 A 里它们是「任务封装层 vs 协议层」，义项 B 里它们分别是「两条能力分发渠道」（协议 vs 注册表）。 ② 「一个 SKILL.md 只描述单个动作，算不算 Skill？」 按义项 A 的粒度判据会答「不算，那是个 Tool」；按义项 B 则算，因为判据是「是不是一个可按需加载的知识包」，与动作数无关。遇到这个问题，先把两个义项摆出来再答，比硬选一个安全。

关键区分 3 —— Harness 是同一个词被用在了三个位置，必须分开说。 这是全篇最容易被答混、也最有价值的一处：

⚠️ 一句话记法：① 和 ③ 是同一件东西（Agent 里面的治理层），只是 ③ 强调的是「训练时用的那套」和「线上用的那套」是不是同一套；② 才是 Agent 外面的东西，也就是这张分层图画的那个位置。比喻：① / ③ 是「考场内部的规则与监考流程」，② 是「考完之后批卷的那套系统」。

① 的五个组成部分（值得背下来，面试问「生产级 Agent 和 demo 差在哪」时就是这张表）：

书里对这三项（约束 / 验证 / 纠正）有一个很硬的判断：以 Claude Code 为例，它的 Harness 中绝大部分代码都是约束、验证与纠正，而非上下文与工具 —— 工具本身只是一小部分。 这正好解释了为什么「能把 Agent 跑起来」和「能把它跑稳」差那么远。

⚠️ 附带修正一处旧说法：本文件此前写 Harness「不提升 Agent 本身的能力」—— 这句话只对一半，且很容易被反问。准确的说法是：Harness 不改变模型的智能上限，但显著改变任务表现。 有出处的证据：LangChain 在 Terminal Bench 2.0 上只改 Harness（自动检查执行结果、检测重复循环、优化思考策略）、不动模型，把成绩从 52.8% 提到 66.5%，排行榜从 30 名开外进到前 5。所以正确的表述是「不提升上限、极大影响达成度」，而不是「不提升能力」。

3. 最容易混的四对（面试官最可能追问的地方）#

4. 一个重要推论：训练 harness ≠ 生产 harness，是一个独立的失效模式#

这一点仓库此前完全没覆盖，而它恰恰是「Harness」这个词在 2026 年最要紧的含义。

阿里那篇 Agentic RL 报告（arXiv 2512.24873）为了解决它，专门在训练侧做了第二种模式：CLI-Native Mode —— 上下文、会话与历史信息完全由生产用的那个 Agent 框架（iFlow CLI）维护，训练框架（ROLL）只作调用方、不负责轨迹拼接。动机原话：

「在许多 Agentic RL 训练管线中，训练阶段的 prompt 设计与上下文管理，往往与生产环境中的真实 Agent 框架不同，这通常会导致部署后的模型能力下降。」

通用表述（值得背下来）：

训练时的 harness ≠ 上线时的 harness，模型会把训练 harness 的怪癖一起学走。

这个失效模式有三个特点，正因为它们，它才值得单列：

• 它不是「prompt 写得好不好」的问题 → 调 prompt 解决不了；
• 它不是「模型能力不够」的问题 → 换更大的模型也解决不了；
• 它只在训练/微调过的情况下才存在 → 纯调 API 的应用没有这个问题。

同样的错位也出现在评测侧：如果评测 harness 与线上 harness 不同（prompt 组织、上下文管理、工具集、重试策略各自维护一份简化实现），离线指标与线上表现会系统性背离。

→ 所以「用真实框架做 rollout / 评测，而不是自己搭一套简化版」是有依据的工程决策，不是一个风格选择。

5. 怎么用这个分层#

答这类题的模板：

1. 先给一句话的关系（Harness 评测 Agent，Agent 调用 Skill，Skill 通过 MCP 调用 CLI 等底层工具，Prompt 贯穿全程）；
2. 再按层展开，每层说「解决什么 / 不解决什么」—— 后半句是加分项；
3. 主动点出层与层之间的接缝（工具选择准确性不在 MCP 层、训练/生产 harness 一致性不在 Prompt 层）；
4. 落回自己的项目：QueWI 的 MCP 工具链在哪一层、Writing Copilot 的 agent 编排在哪一层。

这个分层真正的用处：它让「这个问题的责任在哪一层」变得可回答。

归因到层，才知道该动谁 —— 这是这个分层在面试里的实际价值，也是它值得单独成篇的理由。

常见面试问法#

Q：你怎么理解 MCP、Prompt、CLI、Skill、Harness 这些概念，以及它们之间的关系？ A：先给关系，再分层。「Harness 评测 Agent，Agent 调用 Skill，Skill 通过 MCP 调用 CLI 等底层工具，Prompt 贯穿全程。」展开：MCP 是协议，统一工具与数据源的发现、连接、描述、调用，把 M×N 的适配收敛成 M+N；CLI 是一种可执行能力（特殊的 Tool），通过 MCP 包装后 Agent 才能可靠理解调用 —— 所以 CLI 是「被包装的东西」、MCP 是「包装方式」；Skill 是面向任务的更高层封装，「发送邮件」是工具，「撰写一封得体的会议纪要邮件并发送」才是 Skill，本质是 Prompt + 工具调用编排 + 控制逻辑；Prompt 是直接输入 LLM 的文本指令、贯穿全程（一个 Skill 内部就有规划用、工具选择用、结果总结用的多个 Prompt）；Harness 是把 Agent 跑起来并评估它的框架环境，批量运行、收集轨迹、自动打分、可接 LLM-as-Judge，让回归与 A/B 成为可能。最后补一句边界：这几层不能跨层比较（「Skill 和 MCP 有什么区别」是范畴错误），而且每层都有它明确不解决的问题。

Q：Skill 和 Tool 的区别是什么？ A：粒度与是否面向任务。Tool 是单个动作、无状态、可原子执行（「发送邮件」）；Skill 面向一个任务，内含多步编排与判断（「撰写一封得体的会议纪要邮件并发送」= 调 LLM 生成内容 → 调邮件工具发送 → 调日历工具更新状态）。所以 Skill 的本质是 「Prompt + 工具调用编排 + 控制逻辑」，是可复用的能力单元。一个实用推论：能用 Tool 表达的就不要做成 Skill —— Skill 引入编排逻辑，就更难测、更难复用；反过来，如果一个流程需要「先判断再决定调哪个工具」，那它就该是 Skill，而不是一个「更聪明的 Tool」。

Q：CLI 在 agent 系统里算什么？为什么要通过 MCP 包装它？ A：CLI 是暴露给 Agent 的一种可执行能力，本质是一种特殊的 Tool。它有两个可能的角色：一是被 Agent 调用的命令行工具，二是Agent 系统自身的交互入口（通过命令行启动一个会话）—— 讨论架构时通常指前者。要包装的原因是：CLI 的输入是非结构化参数、输出是非结构化文本，而模型需要的是带 schema 的描述 + 结构化的结果。MCP 提供的就是这层标准化（发现、描述、调用、返回值整形）。收益是复用已有的命令行生态（没有 SDK 的工具也能接）；代价是多一层解析约定，而非结构化输出的解析本身就是错误来源。

Q：Harness 具体指什么？它和 Agent 是什么关系？ A：先给主流定义，再指出这个词被用在了三个位置。 主流定义（也是 2026 的用法）：Agent = Model + Harness，Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正，它是 Agent 边界之内、模型之外的运行与治理层 —— 注意是在 Agent 里面，不是包住 Agent。这个定义最值钱的一层是「约束 + 验证 + 纠正」：以 Claude Code 为例，Harness 中绝大部分代码是这三项，而不是上下文与工具，这正解释了「能跑起来」和「能跑稳」的差距。然后是三个位置：① 构建/运行（就是上面这个定义）② 评测 —— 把 Agent 跑起来并评估它的框架环境，批量运行、收集轨迹、自动打分、可接 LLM-as-Judge，让回归测试与 A/B 成为可能；③ 训练/生产一致性 —— 强调的是「训练时用的那套框架」与「线上那套」是不是同一套，不一致会有独立失效模式：模型会把训练 harness 的怪癖一起学走，阿里那篇 Agentic RL 报告为此做了 CLI-Native Mode，原文说这种不一致「通常会导致部署后的模型能力下降」。一句话记法：① 和 ③ 是同一件东西在 Agent 里面，② 才是 Agent 外面的那套设施。 比喻：①/③ 是考场内部的规则与监考流程，② 是考完之后批卷的系统。

Q：如果模型上线后比离线评测差很多，你会先怀疑 Harness 吗？ A：会，而且这是最容易被忽略的一类原因。 分两种可能：① 评测 harness 与线上 harness 不同 —— 评测时的 prompt 组织、上下文管理、工具集、重试策略若与线上不一致，离线指标就没在测真实系统，指标与线上表现会系统性背离；② 如果做过训练/微调，还有训练 harness 与生产 harness 不一致 —— 模型会把训练框架的怪癖（上下文如何拼接、工具调用格式、终止条件）一起学走，换到生产框架就退化。这两条的共同点是：都不是「模型能力」问题，所以换模型、调 prompt 都解决不了。排查方向是把 harness 对齐：让评测/训练使用与生产同一套框架和上下文管理，而不是各自维护一份简化实现。

易错点#

自测#

1. 用一句话说清 MCP / Prompt / CLI / Skill / Harness 的关系，并指出哪一个「不占某一层」、为什么。

2. 「发送邮件」和「撰写一封得体的会议纪要邮件并发送」，哪个是 Tool、哪个是 Skill？判据是什么？

3. 面试官问「Skill 和 MCP 有什么区别」，这个问题本身有什么问题？你该怎么回答？

4. Harness 的主流定义是什么？它是包住 Agent 还是被 Agent 包含？另外两个用法分别对应什么问题？

5. 「模型离线评测很好，上线就退化」——如果不怀疑模型能力，你会往 Harness 上想哪两件事？为什么这两件事调 prompt 都解决不了？