夜雨聆风上一篇研究 MCP，最后留下了一个一直没有真正想明白的问题：Host 到底是什么？
MCP 官方把 Host 描述为承载、协调 MCP Client 的 AI application，VS Code 就可以是一个 MCP Host。定义并不难记，但我还是没有形成很具象的理解。VS Code 明明就是每天打开的代码编辑器，为什么在这里又叫 Host？它到底 Host 了什么？Agent、LLM、Tool 又分别在哪里？
本来只是想继续把 Host 搞懂，没想到和 AI 一层层追问下去，反而发现自己之前对 Agent 一直有一个更底层的误解。
一直以为，Agent 就是终于可以“动手”的 LLM
之前理解 LLM 和 Agent 的区别时，我脑子里一直有一张很简单的图：传统 LLM 只能生成文字，Agent 则可以使用 Tool，所以 Agent 相当于给 LLM 装上了“手脚”。
比如以前问 ChatGPT：
帮我运行 npm test。
LLM 最多只能告诉我应该输入什么 command，我还得自己复制到 Terminal 里执行。但到了 Agent，它可以自己打开 Terminal、运行测试、看到报错、修改代码，再重新运行。
所以我一直很自然地理解成：
LLM
↓ 获得 Tool 和权限
可以操作电脑
↓
Agent这个理解一直没有让我觉得有什么问题。直到这次继续追问 Host，我突然问了 AI 一个很基础的问题：
LLM 到底是怎么使用 Tool 的？
AI 的回答里有一句让我停了下来：
LLM 本身并不会真正执行 Tool。
那谁在执行？
LLM 其实还是只负责“输出”
继续追问以后，我才发现自己以前把两件完全不同的事情混在了一起：生成一个 Action，和真正执行这个 Action。
比如模型判断现在应该运行测试，它可能产生一个类似这样的 Tool Call：
run_in_terminal({
"command": "npm test"
})我以前看到这里，脑子里默认下一步就是“LLM 执行了 Terminal Tool”。
但实际上，到这里 LLM 的这一次工作已经结束了。
它只是产生了一个结构化输出，大意是：
我下一步希望调用 run_in_terminal，参数是 npm test。
至于谁看到这个输出，谁找到对应的 Tool，谁真正让 Terminal 执行 npm test，并不是 LLM 自己完成的。
这个发现看起来只是一个很小的技术细节，却一下子把我原来对 Agent 的理解拆开了。
如果 LLM 没有真的在操作 Terminal，那么平时看到 Agent 自己读文件、执行 command、点击 Browser，到底是谁在“动手”？
那连接 LLM 输出和 Tool 执行的到底是谁？
于是继续问：
如果 LLM 只负责输出 Tool Call，那外面一定还有一个程序。是谁读取 LLM 的输出，然后真正调用 Tool？
这次第一次认真碰到了两个以前见过、但几乎没有概念的词：
Agent runtime 和 orchestration layer。
不同 Agent 系统的具体架构并不完全相同，这两个词也不能简单理解成某一个固定的软件。但对现在的我来说，可以先用一个很简化的过程理解它们在干什么：
User
↓
Agent system / runtime
↓
LLM
↓
产生 Tool Call
↓
Agent runtime
↓
调用并执行 Tool
↓
得到 Tool Result
↓
Agent runtime
↓
把结果重新提供给 LLM
↓
LLM 再判断下一步假如我告诉 Agent：
运行测试，如果失败就看看是什么问题。
第一次调用 LLM，模型可能判断应该运行测试，于是产生一个 Terminal Tool Call。外面的 runtime 接到这个请求，真正执行 Tool，然后得到：
3 tests failedruntime 再把这个结果交给模型。模型看到失败信息以后，可能判断需要读取某个文件，于是又产生一个 File Tool Call。runtime 再去执行，把文件内容送回来。模型重新判断，也许决定修改代码，然后重新运行测试。这样不断循环。
原来我看到的那个“会自己做事的 Agent”，并不是一个 LLM 突然拥有了真正操作电脑的能力，而是外面还有一套系统在不断把模型的判断变成真实 Action，再把真实世界的结果送回模型。
原来 Agent 的“行动”发生在模型之外
这一点让我重新理解了以前经常说的“Agent 会操作电脑”。
以前脑子里的结构是：
LLM
↓
思考
↓
操作 Tool
↓
看到结果
↓
继续思考现在更接近：
┌───────────────┐
│ LLM │
│ 判断下一步行动 │
└───────┬───────┘
↓
Tool Call
↓
┌───────────────┐
│ Agent runtime │
│ / orchestration│
└───────┬───────┘
↓
真正执行 Tool
↓
Tool Result
↓
┌───────────────┐
│ Agent runtime │
└───────┬───────┘
↓
把结果交回 LLM
↓
再判断这也让我意识到，之前把 Agent 理解成：
LLM + Tool + Permission其实少掉了非常重要的一层。
LLM 可以决定“下一步想做什么”，Tool 提供可以调用的外部能力，permission 决定某些操作是否允许执行，但还需要有外部系统负责组织这一切：把 Tool 告诉模型、处理模型产生的 Tool Call、执行或调度相应能力、取得结果，再把结果重新送回模型。
Agent 的“行动能力”并不是全部长在 LLM 里面。
Agent runtime 到底是什么？
但理解到这里，我又犯了一个很自然的错误：既然终于找到了那个“中间执行者”，那 Agent runtime 是不是一个具体的软件？
继续追问才发现，好像又不能这么简单理解。
“Runtime”更接近让 Agent 实际运行起来的执行环境和相关逻辑，而 orchestration 强调的是这些不同部分怎样被协调起来。不同 Agent 产品内部可能有完全不同的实现，并不存在一个所有 Agent 都必须安装的、统一叫作“Agent Runtime”的程序。
这也是为什么在研究 Agent 时经常会看到 orchestration 这个词。Agent 要完成一个任务，并不是简单地：
Prompt → LLM → Answer而可能需要不断协调：
LLM
Tools
Context
Tool results
Conversation state
Permissions
下一轮 LLM request什么时候调用模型、给模型哪些 context、提供哪些 Tools、模型要求调用 Tool 后如何执行、执行结果怎样重新加入下一轮 context、什么时候停止整个循环，这些都需要模型之外的系统处理。
我以前把所有这些过程都模糊地归到了“Agent 会自己做”，现在才第一次意识到，“会自己做”背后其实有大量 orchestration。
那 Agent 到底是什么？
问题到这里反而变得更有意思了。
如果 LLM 不是 Agent，Tool 不是 Agent，Agent runtime 也不能完全等于 Agent，那么平时说的 Agent 到底指什么？
目前我只能先把它理解成一种系统，而不是一个单独的模型：
Agent system
LLM
+
Tools
+
Context / State
+
Runtime / Orchestration
+
不断观察、判断、行动的 Loop这仍然只是帮助自己建立概念的简化版本，不同框架和产品对 Agent 的定义、边界和实现并不完全一样。但至少有一个以前的理解可以先放弃了：
Agent 不是“获得电脑操作权限的 LLM”。
模型仍然是整个系统非常核心的判断部分，但真正让它表现出连续行动能力的，是模型和外部执行、Tool、状态以及 orchestration 一起形成的系统。
这也让我开始理解为什么同一个 LLM 放进不同 Agent 产品里，最后表现出来的能力可能差别很大。模型可能相同，但外面围绕它搭建的系统并不相同。
那 Agent runtime 和 Host 是什么关系？
绕了一圈，又回到了这一篇最开始的问题：Host。
MCP 语境里的 Host 是更大的应用。VS Code 可以作为 MCP Host；而 Agent runtime / orchestration 更像是这个 AI application 中负责驱动 Agent 工作过程的一部分逻辑。
现在我暂时把自己的实际场景理解成：
┌────────────── VS Code / Host ──────────────┐
│ │
│ Agent system │
│ │ │
│ Runtime / Orchestration │
│ ↙ ↘ │
│ LLM Tools │
│ │ │
│ Terminal / Files │
│ │ │
│ MCP Client │
└────────────────────────────┼───────────────┘
↓
Playwright MCP Server这张图肯定仍然是过度简化的，尤其是 LLM 本身通常并不是“住在 VS Code 里面”，实际产品架构也远比这复杂。但它至少帮我把几个以前混成一团的概念暂时分开了。
Host 不是 LLM，Host 也不等于 Agent runtime。它更像承载和协调这些 AI 能力的 application environment。在我的例子里，就是 VS Code。
但我现在依然不能说自己真正理解了 Host。“VS Code 是 Host”已经可以记住，可“它到底 Host 了什么、哪些东西真的运行在 VS Code 本地、哪些又是远程服务”，还是没有完全建立起来。
继续问 Host，又发现我对 Server 也有误解
就在继续追 Host 的时候，我又问出了一个现在回头看很基础的问题：
Host 是不是一种 Cloud Service？是不是类似以前学 AWS 时那些 Server？
因为以前学过一点 AWS 基础知识，接触过 EC2、server、load balancer，脑子里一直留下一个很模糊的印象：
Server ≈ 云上的一台 Virtual PC所以看到 Playwright MCP Server，我也一直隐约把它想象成某种“服务器电脑”。
继续问以后才发现，Server 更根本的含义并不是某一种机器，而是在一段通信关系里提供服务的一方。Client 请求服务，Server 接收请求并返回结果：
Client → Request → Server
Client ← Result ← ServerServer 可以运行在云上的 virtual machine，也可以运行在 physical machine、container，甚至只是自己电脑上的 local process。所以 Playwright MCP Server 叫 Server，并不代表它一定存在于某台远程云服务器上。它可以就在本地运行，只是在 MCP 这段通信关系中扮演 Server 的角色。
这也是我第一次真正意识到：Client 和 Server 首先描述的是通信关系中的角色，而不是两种固定的机器。
原来真正的 Gap 比 Host 更底层
这一篇原本只是上一篇 MCP 留下来的补充：想弄明白 Tool 和 Host。
结果一路问下来，Tool 没有继续深挖，Host 到现在也没有完全搞懂，却意外修正了一个更重要的误解：我一直把 Agent 的行动理解成 LLM 自己在操作 Tool，而忽略了模型之外真正负责执行和协调的系统。
Agent runtime 和 orchestration layer 目前也只是刚刚知道它们的存在，远没有真正理解。它们反而成了下一步最想继续追的问题：一次 Agent Loop 到底是谁控制的？谁决定什么时候再次调用 LLM？Tool Result 是怎样重新加入 context 的？如果 Tool 执行失败，谁决定 retry？Agent 的 state 存在哪里？runtime 是本地程序还是远程服务？VS Code Copilot Agent 的 orchestration 又究竟发生在哪里？
继续追问以后，目前暴露出来的基础 Gap 也越来越清楚：
Program / Process / Runtime。 一个软件“运行起来”到底是什么意思？Runtime 到底是一个程序、一个环境，还是一套执行逻辑？
Client / Server。 两个程序怎样通信？Request、response、HTTP、port、localhost、remote server 到底分别是什么？
Machine / VM / Container / Cloud。 程序究竟运行在哪里？为什么以前会把 Server 和 Virtual Machine 混在一起？
Agent architecture。 LLM、runtime、orchestration、Tools、context 和 state 到底怎样组成一个真正工作的 Agent？
Host。 VS Code 到底 Host 了什么？Host 与 Agent runtime、MCP Client 之间真正的边界在哪里？
所以这一篇最后还是没有把 Host 完全搞懂。但和上一篇研究 MCP 时一样，我开始觉得，暂时没有得到一个漂亮的答案反而更接近真实的学习过程。每次以为自己只是缺一个定义，继续问下去才发现，真正缺的是定义下面那一层关系。
下一步想继续追 Agent runtime 和 orchestration。与其继续记“Agent 会调用 Tool”，我更想沿着一次真实的 Agent 操作，从我输入一句 prompt 开始，看它怎样到达 LLM，怎样变成 Tool Call，谁执行 Tool，结果怎样回来，又是谁启动下一轮判断。
也许把这条链真正走一遍以后，Agent 和 Host 才会第一次从几个抽象名词，变成一个可以在脑子里运行起来的系统。
References
- Model Context Protocol — Architecture Overview
https://modelcontextprotocol.io/docs/learn/architecture - Visual Studio Code — Agent Tools
https://code.visualstudio.com/docs/agents/concepts/tools - Visual Studio Code Extension API — Language Model Tool API
https://code.visualstudio.com/api/extension-guides/ai/tools - Visual Studio Code — MCP Servers
https://code.visualstudio.com/docs/copilot/chat/mcp-servers - Visual Studio Code — Approvals and Permissions
https://code.visualstudio.com/docs/agents/approvals - Microsoft — Playwright MCP
https://github.com/microsoft/playwright-mcp - Model Context Protocol — Understanding MCP Servers
https://modelcontextprotocol.io/docs/learn/server-concepts