[!info] related notes

• 所属 MOC: AI MOC, 前端工程化 MOC
• 相关概念: LLM, Function Calling, Built-in tools, mcp, Skills, Orchestration, ai-agent-creation, AI Agent Memory Layer, Augmented LLM
• 实践工具: docker-mcp-toolkit-moc, mcp-client-configuration
• 面试问法: what-is-mcp-interview-question, skills-in-ai, what-is-agent-in-frontend-engineering-interview-question

AI的能力以及对应的协议

AI 看起来会聊天、会查资料、会读文件、会写代码、会执行命令、还能围绕目标持续做事，但这些能力并不是都来自同一个地方。

今天一个“看起来很强”的 AI，通常是多层能力叠加出来的结果：

• LLM 提供基础语言智能
• Augmented LLM 负责把模型和检索、工具、记忆拼成基础执行构件
• prompt、历史消息、检索结果、工作区文件提供当前任务上下文
• Built-in tools 提供宿主产品原生能力
• Function Calling 提供结构化工具调用机制
• mcp 提供外部能力标准化接入方式
• Skills 提供可复用任务经验
• Orchestration 负责调度这些能力如何协同
• Agent Runtime 负责把这些能力放进真实执行环境
• Agent 把这些能力组织成持续执行的闭环

所以讨论 AI 工程时，不能只问“模型是什么”，还要问“它拿到了什么上下文、接了什么工具、运行在哪个产品里、由谁来编排执行”。

一句话定义

AI 的能力不是单靠模型本身产生的，而是由模型、上下文、工具、协议、宿主运行时和 Agent 编排共同组成的一套能力栈。

先分清“能力来源”而不是只盯着模型

1. 模型本体：LLM 提供基础智能

LLM 负责的是：

• 理解自然语言
• 生成文字、代码和结构化内容
• 做摘要、改写、归纳和一定程度的规划
• 在上下文足够时完成有限推理

但它天然也有明显边界：

• 不知道训练截止后的新信息
• 不会自己访问数据库、网页、终端或本地文件
• 不擅长长期稳定维护多步任务状态

一句话说，模型本身负责“会想、会说、会规划一点”，但默认不会直接碰外部世界。

2. 上下文层：当前任务需要的信息从这里来

很多时候 AI 答得好，不是因为模型“本来全知道”，而是因为系统在调用前给了它额外上下文，比如：

• 系统提示词
• 当前对话历史
• 上传文件
• 项目代码
• 检索结果
• 规则文档和知识库内容

所以 AI 的一部分能力其实来自“拿到了什么信息”，而不是只来自模型参数。

2.5 记忆层：有些信息不该只存在于当前上下文里

除了当前上下文，很多 agent 还会维护一层更持久的 memory layer，例如：

• 项目结构和架构约定
• 用户的长期偏好
• 常见坑、历史决策和复用经验
• 文件化规则层，如 AGENTS.md
• 外接的 shared memory backend

这层能力解决的是：

• 会话结束后还要不要继续记得
• 多次进入同一项目时能否少重复解释
• 多个客户端或多个 agent 能否共享长期状态

所以 memory 不是普通聊天记录的别名，而是更偏长期状态管理。

3. 产品工具层：Built-in tools 让 AI 能直接做事

Built-in tools 是宿主 AI 产品原生提供给模型的工具能力，比如：

• 网页搜索
• 文件读取与编辑
• 代码执行或终端命令
• 浏览器或界面操作

这层能力的关键点是：

• 一般已经和具体产品绑定
• 用户通常不需要自己部署额外服务
• 能不能用，取决于产品运行时是否开放这些能力

所以很多“AI 会查、会改、会跑”的表现，首先是宿主产品给了它内置工具。

3.5 组合构件层：Augmented LLM 是更贴近工程实现的起点

很多 agentic system 真正直接使用的，不是“裸模型”，而是 Augmented LLM：

• 基础模型负责理解和生成
• retrieval 负责补现场信息
• tools 负责与外部世界交互
• memory 负责保留任务状态

从工程角度看，后面的 workflow 和 agent 大多都是围绕这块基础构件展开的。

4. 调用机制层：Function Calling 告诉系统“该怎么调工具”

Function Calling 解决的不是“工具从哪来”，而是“模型如何把调用意图表达成结构化请求”。

常见流程是：

1. 系统先把可用工具定义告诉模型
2. 模型判断是否要调用工具
3. 模型生成工具名和参数
4. 宿主程序真正执行工具
5. 结果再回给模型继续生成

所以 Function Calling 更像调用机制，而不是工具生态本身。

5. 接入协议层：MCP 告诉客户端“外部能力怎么标准化接进来”

mcp 解决的是“外部工具、资源、提示能力怎么以统一协议接入 AI 客户端”。

它的主要价值是：

• 降低不同客户端分别适配不同工具的成本
• 让 tools / resources / prompts 有统一暴露方式
• 让外部能力生态更容易复用

所以 MCP 不是 Agent，也不是单次工具调用本身，而是更偏接入层标准。

6. 经验资产层：Skills 让能力更稳定可复用

Skills 不是协议层，而是工作流资产层。

它把已经验证过的高频任务经验固化下来，例如：

• 任务步骤
• 输出结构
• 规则约束
• 工具使用顺序

因此 Skills 提升的不是模型的“智力上限”，而是任务执行的一致性、稳定性和复用效率。

7. 编排执行层：Orchestration 和 Agent 负责把前面这些能力串成闭环

Agent 的关键不是“会多轮聊天”，而是：

• 围绕目标拆解步骤
• 根据上下文和工具结果继续推进
• 在必要时循环调用工具
• 尝试把任务推进到可交付状态

而 Orchestration 负责的是更高一层的调度与控制，例如：

• 是让 Manager 持续总控，还是通过 Handoffs 直接切给 specialist
• 当前步骤由模型自己决定，还是由代码硬控
• 状态、guardrails、tracing 和恢复执行挂在哪一层
• 哪些动作要走 approval checkpoints

Agent 更偏执行主体，orchestration 更偏工作流编排层，而 runtime 则负责把这些编排真正跑起来。

如果继续往下拆，常见工作流模式可以看：

• Prompt Chaining
• LLM Task Routing
• LLM Parallelization
• Orchestrator-Workers
• Evaluator-Optimizer

如果从单个 agent 的微观循环去看，还可以再拆成：

• Agent 中的 Planning Loop
• Agent 中的 Tool Use

如果从信息层和多 agent 编排去看，还可以进一步拆成：

• Memory、Context、Knowledge 与 Instruction Files 的边界
• 多 Agent 编排模式

一张表看懂能力和来源

层次	主要来源	提供什么能力	解决什么限制
基础智能层	[[llm	LLM]]	理解、生成、摘要、初步推理
上下文层	prompt / 历史消息 / 文件 / 检索结果	当前任务所需信息	弥补模型不知道当前现场的问题
产品工具层	[[built-in-tools	Built-in tools]]	搜索、文件、终端、浏览器等
调用机制层	[[function-calling	Function Calling]]	结构化工具调用请求
接入协议层	mcp	标准化 tools / resources / prompts 接入	让外部能力更容易被接入和复用
经验资产层	[[skills-in-ai	Skills]]	高质量任务模板和规则
运行时控制层	[[agent-runtime	Agent Runtime]]	run loop、状态、工具执行、审批、追踪
编排执行层	[[orchestration	Orchestration]] / [[ai-agent-creation	Agent]]

它们怎么组合成一个“会做事的 AI”

一个能在 IDE 或终端里帮你完成任务的 AI，常见组合通常是：

1. LLM 负责理解需求和生成计划
2. 当前仓库、文档、历史消息提供上下文
3. Built-in tools 或外部工具提供搜索、文件、终端等执行手段
4. Function Calling 或产品内部工具接口负责表达调用意图
5. mcp 负责把更多外部能力标准化接进客户端
6. Skills 约束输出方式和任务流程
7. Agent Runtime 提供真正执行这些动作的受控环境
8. Orchestration 决定 manager、handoff、tool call 和状态怎么协同
9. Agent 把这些能力串起来，持续执行直到完成

所以用户看到的是“一个 AI 在干活”，工程上真正发生的是多层能力协同。

最容易混淆的几个点

Built-in tools 不等于 MCP

• Built-in tools 是产品自带能力
• MCP 是外部能力接入标准

Function Calling 不等于工具本身

• Function Calling 是调用表达机制
• 真正执行工具的是宿主程序或外部系统

Skills 不等于普通 prompt 收藏夹

• Skills 更强调稳定工作流和任务约束
• 它们通常和具体场景绑定

Memory 不等于聊天历史

• 聊天历史更像最近发生过什么
• memory 更像之后还要继续复用什么

成熟的 coding agent memory 往往会进一步区分：

• session state
• project memory
• personal memory
• instruction files
• external memory backend

Agent 不等于会多轮对话

• 多轮对话只是交互形式
• Agent 的核心是目标驱动、工具调用和结果反馈闭环

面试里怎么最短说明

不要把 AI 的能力都归因于模型本身。模型只提供基础智能；真正让 AI “能查、能读、能改、能执行”的，是上下文注入、Built-in tools、Function Calling、MCP、Skills 和 Agent 编排这些层一起工作。

最短记忆方式

LLM 负责理解与生成，上下文负责补现场信息，Built-in tools 和 Function Calling 负责让模型能调工具，MCP 负责统一接外部能力，Skills 负责沉淀经验，Agent 负责把这些能力串成闭环。

harness 工程

用户
  ↓
Harness / Runtime / Control Plane
  ├─ Session / State / Memory
  ├─ Guardrails / Approvals / Auth / Audit
  ├─ Tracing / Evals / Replay
  ├─ Orchestration (manager, handoffs, specialists)
  ├─ Tool Registry / Dispatcher
  │    ├─ Built-in tools (web, file, code interpreter…)
  │    ├─ Function calls (your app code)
  │    └─ MCP servers (local stdio / remote HTTP)
  ├─ Skill Loader (SKILL.md, scripts, refs, assets)
  ├─ AGENTS.md Loader
  └─ Sandbox / Shell / Filesystem / Container
           ↓
           LLM

这里的编排层可以进一步拆到 Orchestration、Manager 和 Handoffs 三个概念去看。

面试要点

来自 what-is-mcp-interview-question 的面试视角整理。

一句话回答

MCP 可以理解成让模型统一连接外部工具、数据源和能力的标准协议。它的价值在于把模型从纯文本推理扩展到可访问项目上下文、执行工具和调用外部能力的协作形态。

最稳的回答主线

• 先说 MCP 是连接协议，不是具体工具产品
• 再说它的价值是统一接能力和上下文
• 最后补一句它通常和 Skills、Agent 一起出现，但不是同一层概念

可以怎么展开

• 没有 MCP 时，模型更多停留在纯文本问答
• 有 MCP 后，模型可以标准化访问文件、命令、知识和服务
• 这样更容易把 AI 接进真实研发流程，而不是只停留在聊天窗口里

常见误区

• 把 MCP 说成 Agent 框架
• 把 MCP 理解成某一家厂商的私有方案
• 只说能接工具，没有说标准化连接的意义

可能追问

• MCP 和 Agent、Skills 的区别是什么
• MCP 为什么会对工程化很重要
• 前端研发里哪些能力适合通过 MCP 接进来

最短记忆方式

MCP 让模型不只会聊天，还能稳定接能力。