Agent 工具调用的进化：从 MCP 到 CLI 再到 Workspace

相关链接：https://github.com/Zleap-AI/Zleap-Agent

（基于Workspace的开源Agent Harness）

一、MCP：先把工具接进来

MCP 最开始解决的是一个很真实的问题：工具接入太乱了。

以前每个 Agent、每个应用、每套工具，都要自己写一遍连接方式。接文件系统是一套，接数据库是一套，接搜索是一套，接企业软件又是一套。Agent 工具调用还没真正跑起来，工程复杂度先把人劝退了。

MCP 的意义，就是先把这件事统一起来。它像给 AI 应用做了一个通用接口：外部数据、工具、服务，都可以用一套协议接进来。

这一步很重要。没有统一协议，生态很难长出来。

但很快，新的问题出现了。

工具是更容易绑定了，Agent 却不一定更会用了。

当一个 Agent 一下子挂上几十个、上百个 MCP 工具，问题就从“怎么接工具”，变成了“Agent 到底该怎么选工具、怎么填参数、怎么判断什么时候该调用”。接入标准化了，调用成功率反而成了新的瓶颈。

这其实很正常。MCP 解决的是工具连接问题，不是 Agent 注意力问题。把所有工具都接上，不等于 Agent 就能稳定地用好它们。

二、CLI：另一个极端

后来 Claude Code 的思路，某种意义上是反过来的。

它没有把所有能力都做成 Agent 可见的复杂工具，而是把核心工具删减到极简：读文件、写文件、搜索、编辑、Bash。

其他更复杂的能力，不是直接变成一大堆工具 schema 摊给 Agent，而是通过 Skill + CLI 再往下分层。

这一步看起来很朴素，但效果很明显。

Agent 不需要在几十个名字相近的工具里做选择，也不需要理解一堆复杂参数。它只要学会几个基础动作：看文件、改文件、跑命令、读技能说明。复杂能力被藏到了 Skill 后面。

所以 Claude Code 的成功，不只是因为它有 Bash。更关键的是，它把工具面压缩了，把复杂度往后挪了。

工具少了，Agent 就不容易乱选；参数少了，Agent 就不容易漏填；流程被 Skill 包起来，Agent 就不需要每次重新发明一遍操作步骤。

这其实已经是在做分层了。

三、CLI 的风险：终端不是全部

但 Claude Code 也只做对了一半：它把工具分层了，但又把太多东西压到了 CLI 里。

对 Coding Agent 来说，CLI 很自然。写代码本来就围绕文件、命令、脚本、测试、构建展开。

但 Agent 不会永远只活在 Coding 场景里。

未来的 Agent 一定会从 in the machine 走向 out of the machine。

终端背后是一整套操作系统，能力很强，但也很重。很多 Agent 只是要调一个服务，没必要先背上一整个 Shell。

更大的问题是权限。

一个 CLI 工具一旦装到电脑上，本质上就拿到了本机执行权限。它可以读文件、扫目录、看环境变量、碰 SSH Key，甚至把东西上传出去。

如果这是闭源 CLI，你很难知道它到底做了什么。

对 Agent 来说，这个风险会被放大。因为不是人在手动敲命令，而是 Agent 在任务过程中不断调用 Bash。

所以 CLI-Anything 看起来简单，实际上是一种很粗暴的信任模型：只要装了，就默认它有了你的所有权限。

反过来，Remote MCP 很多时候反而更安全。

它本质上更像一次 HTTP 请求。你给它什么数据，它处理什么数据；它默认拿不到你的本地文件系统，也碰不到你的 SSH key。

远程服务当然也有隐私和合规问题，但它的权限边界更清楚，它不站在你电脑内部。

四、Workspace：到底是什么

所以我们提出 Workspace。

Workspace 这个想法，最早的灵感其实来自操作系统。

操作系统不会把所有能力都塞进一个软件里。写文档有文档软件，浏览网页有浏览器，管理文件有文件管理器，写代码有编辑器和终端。

Agent 也应该这样。

我们把工具按类别拆成不同的子 Workspace，就像操作系统里的不同软件。

每个子 Workspace 只收纳一类工具，也只保留这一类任务需要的上下文。

每次用户开始对话，先进入主 Workspace。主 Workspace 像桌面，负责判断任务应该交给哪个子 Workspace。

真正调用工具，是进入对应子 Workspace 之后才发生。

Workspace 不是子 Agent ，他们的根本区别，是生命周期。

子 Agent 是临时执行者，给它一个目标，做完回来，基本就结束了。

Workspace 更像操作系统里的软件，是长期存在的工作区，有持久化的记忆。搜索 Workspace 会保留搜索相关的上下文和记忆，CLI Workspace 会保留文件、命令、脚本和产物，浏览器 Workspace 会保留网页状态和交互历史。

所以 Workspace 不是为了多开一个 Agent，而是让同一个 Agent 进入不同工作区时，看到不同的工具、上下文、历史、记忆和权限。

五、Workspace 的优势：隔离上下文，不依赖 CLI

第一，隔离上下文，成功率更高。

Agent 不是一次看到全部工具、全部历史、全部技能，而是先由主 Workspace 路由，再进入具体子 Workspace 做事。

进入搜索 Workspace，就只看搜索相关的东西；进入 CLI Workspace，就只看文件和命令相关的东西。

上下文小了，选择少了，参数错填也少了。

这对小模型尤其重要。小模型不怕任务小，怕的是东西太多、干扰太多。

让它在一个干净空间里做事，成功率会明显更高。

第二，不会被 CLI 强绑定，更轻，也更安全。

换句话说，Workspace 像是更安全、更轻量的 CLI + Skills。

CLI 适合写代码、跑脚本、执行命令，但不是所有能力都应该被硬包成命令行。

能走MCP服务，就不要强行塞进 Bash。CLI 的权限天然更靠近整台机器，风险也更大。

Workspace不仅隔离了工具，也可以隔离Skills。

现在大家添加给 Agent 的 Skills 越来越多，Agent 经常不知道该选哪个。

Workspace 把工具和 Skills 一起按场景隔离，只给 Agent 当前需要的那一小组。

看得少，做得准；不绑死，也不乱放权。

六、总结

这条线其实很清楚。

MCP 解决连接：工具怎么接进来。

CLI 解决成功率：把工具缩减，让 Coding Agent 更稳定。

Workspace 解决边界：工具进来之后，Agent 应该在哪个场景里使用它。

MCP 是入口，CLI 是过渡，Workspace 才是组织方式。

把所有工具都平铺给 Agent，是放任。

把所有场景都塞进 CLI，是偷懒。

好的 Agent Harness，不应该追求让 Agent 看到更多工具。

它应该让 Agent 在正确的 Workspace 里，只看到此刻该看到的工具。