CLI、MCP、Skill与Agent：AI时代四层架构重塑人机交互-三亩地-编程学习日记

1. 项目概述：CLI的“文艺复兴”与四层架构的崛起

如果你在2025年还在用鼠标点点点，那你可能已经落后了。这不是危言耸听，而是我作为一个在开发一线摸爬滚打了十几年的老兵的切身感受。就在最近这一年，一个沉寂了多年的“老古董”——命令行界面，也就是我们常说的CLI，突然以一种前所未有的姿态杀回了技术舞台的中心。你可能会觉得奇怪，图形界面不是更直观、更友好吗？为什么这个看起来黑乎乎、需要敲键盘的“老家伙”又火了？

核心原因其实就藏在我们每天打交道的AI里。当AI Agent（智能体）开始试图接管我们的工作流时，它们发现了一个尴尬的现实：花花绿绿的图形界面，对人类很友好，但对机器来说，却像是一本没有索引的天书。按钮在哪？菜单层级是什么？状态如何判断？这些对人类而言的“直觉”，对AI来说都是需要额外解析的复杂视觉信号。而CLI则不同，它天生就是结构化的文本流，输入是明确的命令和参数，输出是格式化的文本或JSON。这种确定性，正是AI Agent理解和操作世界的完美接口。所以，CLI的复兴，本质上不是人类怀旧，而是AI时代人机协作范式变革的必然结果。它不再是极客的玩具，而是成为了连接人类意图与AI执行力的“战略要道”。

这次复兴，远不是简单地把ls、cd命令重新用起来那么简单。它催生了一套全新的、层次分明的技术架构。我们谈论的已经不再是单个的CLI工具，而是一个由**CLI（命令行界面）、MCP（模型上下文协议）、Skill（技能）和Agent（智能体）**构成的四层协同体系。这套体系正在重塑我们与计算机交互的方式。本文将为你彻底拆解这四层架构，讲清楚每一层是什么、为什么重要、以及它们如何环环相扣，最终让CLI从一个单纯的工具，进化成为AI原生时代的核心基础设施。无论你是开发者、运维工程师，还是对效率工具有追求的技术爱好者，理解这套架构，都意味着握住了开启下一代生产力工具的钥匙。

2. 架构全景：CLI、MCP、Skill、Agent四层协同解析

要理解这场变革，我们必须跳出“CLI就是一个黑色终端窗口”的旧有认知。在新的范式下，CLI、MCP、Skill、Agent各自扮演着不可或缺的角色，它们自上而下，构成了一条清晰的指令传递与能力执行链。

2.1 核心层定义与角色分工

我们可以把这四层架构想象成一家现代化的餐厅。

Agent（智能体）是那位理解你复杂需求的“私人管家”。你不需要告诉它“去厨房拿刀，切西红柿，打开炉子，倒油……”，你只需要说“我想吃一份番茄炒蛋”。它理解你的终极目标，并负责规划和协调。
Skill（技能）就是厨房里各项具体的“厨艺技能”。炒菜、煲汤、摆盘，每一项都是一个封装好的、可重复调用的技能。管家（Agent）知道要做番茄炒蛋，但它自己不下厨，而是调用“炒菜”这个技能。
MCP（模型上下文协议）是管家与厨房之间的“标准化订单传票”。它定义了一套统一的格式，确保管家写的“番茄炒蛋，少盐，加糖”能被任何一个符合协议的厨房（或技能执行环境）无歧义地理解。没有它，管家和厨房就得每次重新约定沟通方式，效率极低。
CLI（命令行界面）则是厨房里每个厨具自带的“精确控制面板”。比如炒锅的火力旋钮、烤箱的温度定时器。当“炒菜”技能被调用时，它最终会转化为一系列对CLI的精确调用：“开大火至9档”、“下油50毫升”、“放入食材”。CLI提供了最底层、最确定性的原子操作。

在这个比喻中，CLI的复兴，正是因为AI管家（Agent）需要一种可靠、无歧义的方式来操控“厨具”（各种工具和服务）。图形界面就像是一个需要眼神和手势交流的厨师，而CLI则是带有标准刻度盘和按钮的现代化厨具，显然后者更适合被程序化调用。

2.2 自底向上：从CLI到Agent的能力抽象

让我们从最底层开始，看看能力是如何一层层被抽象和汇聚的。

第一层：CLI - 确定性的原子操作层这是一切的基石。一个设计良好的现代CLI工具，比如gh（GitHub CLI）、aws（AWS CLI）、kubectl（Kubernetes CLI），通常具备以下特征：

结构化输出：支持--output json或-o json这样的参数，将其执行结果以机器可读的JSON格式输出，而不是仅供人类阅读的文本表格。
非交互式：所有操作可以通过单条命令加参数完成，无需中途人工输入。这通过--non-interactive标志或合理的默认值来实现。
明确的退出码：成功（0）或不同的错误码（1, 2, 3...），让调用者能明确判断命令执行状态。
良好的文档与模式：不仅有人类文档，更有机器可读的Schema（如通过--help-json输出），方便被自动发现和集成。

注意：并非所有传统CLI都直接适合被AI调用。很多老旧工具输出的是格式不固定、包含装饰性字符的文本，这会给上层的解析带来巨大麻烦。因此，现代CLI的“AI友好型”改造，首要任务就是提供稳定、纯净的结构化数据接口。

第二层：MCP - 统一的通信协议层当有了成百上千个不同的CLI工具（厨具）时，让Agent（管家）去学习每一种工具的调用语法是不现实的。这就需要MCP（Model Context Protocol）。你可以把它理解为工具领域的“USB协议”。

MCP的核心思想是服务发现与标准化描述。一个支持MCP的CLI工具（或任何其他工具，如数据库、API），会向MCP服务器注册自己，并声明：“我能提供哪些能力（Resources）？我能执行哪些操作（Tools）？我的输入输出格式（Schema）是什么？”例如，一个天气CLI工具可能注册一个名为get_weather的Tool，并声明它需要一个city: string参数，返回一个包含temperature、condition的JSON对象。

Agent不需要知道这个Tool背后是用curl调用API，还是执行一个本地的Python脚本。它只需要按照MCP协议规定的格式，发送请求，就能得到标准化响应。这极大地降低了Agent集成新工具的复杂度。目前，由Anthropic推动的MCP协议正在成为这一领域的事实标准，许多工具已经开始提供MCP Server实现。

第三层：Skill - 可复用的任务单元层Skill是对一个或多个MCP Tools（或底层CLI操作）的编排和封装，用以完成一个具体的、有意义的任务。它比单一的Tool更高级，包含了逻辑判断、错误处理和一定的业务流程。

继续用餐厅比喻，MCP Tool是“切菜刀”，而Skill是“将西红柿切成1厘米见方的小块”这个完整的操作流程。一个Skill可能包含：检查西红柿是否存在、选择正确的刀具、执行切割动作、检查切割结果是否符合规格。

在技术实现上，一个Skill可以是一个脚本、一个函数、或一个配置文件。它接收更上层的、面向目标的指令（如ingredient: tomato, size: 1cm），并将其“编译”成一系列对底层MCP Tools的调用序列。Skill的存在，让Agent不需要关心实现细节，只需关注目标本身。

第四层：Agent - 理解与决策的大脑层Agent位于架构的顶端，它是具备自主理解、规划、执行和反思能力的AI系统。用户用自然语言向Agent提出请求：“帮我分析一下上个月项目仓库的代码提交活跃度，并生成一份报告。”

Agent的工作流程如下：

理解与规划：利用大语言模型理解用户意图，并将其分解为一系列子任务。例如：“1. 获取仓库列表；2. 获取每个仓库上个月的提交记录；3. 按提交者统计；4. 生成可视化图表；5. 汇总成文档。”
技能匹配与调用：Agent检查自身可用的Skill库和通过MCP发现的Tools。它发现有一个get_git_repo_statsSkill可以完成任务1-3，有一个generate_chartTool可以完成任务4，有一个write_markdown_documentTool可以完成任务5。
执行与协调：Agent按顺序或并行地调用这些Skill和Tool，并管理它们之间的数据传递（如上一步的输出作为下一步的输入）。
反思与调整：如果某个步骤失败（如没有访问仓库的权限），Agent能够分析错误，调整计划（如先尝试认证，或跳过该仓库），并继续执行。

在这一架构中，CLI的价值被无限放大。因为几乎所有复杂的、涉及外部系统的操作，最终都能找到或封装成一个CLI命令，然后通过MCP暴露给Skill，最终被Agent所驾驭。CLI成为了Agent“手脚”的延伸。

3. 核心组件深度剖析：MCP协议与Skill编码

理解了四层架构的宏观图景后，我们需要深入其中两个最为关键且新颖的组件：MCP和Skill。它们是连接AI思维（Agent）与物理世界操作（CLI）的桥梁和粘合剂。

3.1 MCP协议：工具生态的“通用插座”

MCP协议的设计目标非常明确：让任何工具都能以一种标准化的方式，将其功能暴露给AI模型使用。它主要定义了两种核心概念：

1. Resources（资源）：代表可供AI读取的静态或动态信息。比如：

一个数据库连接可以提供一个“当前活跃连接数”的资源。
一个服务器可以提供“系统负载”的资源。
一个项目管理工具可以提供“当前冲刺待办事项列表”的资源。 Resources是只读的，用于为AI提供上下文信息。

2. Tools（工具）：代表可供AI调用的操作，通常会有副作用（写操作）。比如：

一个“创建Git分支”的工具。
一个“发送Slack消息”的工具。
一个“重启服务”的工具。

MCP Server是协议的实现方，它负责管理本地的工具和资源，并通过标准接口（通常是stdio或HTTP）与MCP Client（通常是AI Agent平台，如Claude Code、Cursor等）通信。当Client连接上Server后，会发起一个initialize握手，之后Server会通过list_tools和list_resources告诉Client：“我这里有这些东西可用”。

一个简单的MCP Server示例（概念模型）：假设我们有一个管理本地Docker的MCP Server。

// Client询问：“你有什么工具？” // Server回复： { "tools": [ { "name": "list_containers", "description": "列出所有运行中的Docker容器", "inputSchema": { "type": "object", "properties": { "all": { "type": "boolean", "description": "是否显示所有容器（包括已停止的）" } } } }, { "name": "stop_container", "description": "停止指定的Docker容器", "inputSchema": { "type": "object", "properties": { "containerId": { "type": "string", "description": "容器的ID或名称" } }, "required": ["containerId"] } } ] }

当AI Agent需要查看容器时，它只需向这个Server发送一个格式为{"name": "list_containers", "arguments": {"all": true}}的调用请求，而完全不必知道背后实际执行的是docker ps -a这个CLI命令。

实操心得：为现有CLI工具包装MCP Server是当前一个高价值实践。你不需要重写工具逻辑，只需写一个轻量级的“适配器”脚本。这个脚本监听MCP请求，将其翻译成对应的CLI命令，执行后，再将输出解析、格式化成MCP要求的JSON响应。Python的mcpSDK让这个过程变得非常简单。

3.2 Skill编码：将复杂操作封装为“乐高积木”

如果说MCP Tools是单一的“积木块”，那么Skill就是拼装好的“乐高模型”。Skill编码的本质，是编写一段能够被Agent可靠调用的、完成特定复合任务的程序。

Skill的关键特性：

目标导向：Skill描述的是“做什么”（What），而不是“怎么做”（How）。例如：“部署应用到预发环境”是一个Skill，“执行kubectl apply -f deployment.yaml”是一个具体的MCP Tool调用。
参数化：Skill应该接受参数以适应不同场景。例如，“部署应用”Skill可能需要参数app_name,environment,image_tag。
错误处理与重试：一个健壮的Skill必须包含对底层操作失败的处理逻辑，比如网络超时后的重试，或资源不存在时的创建操作。
结果标准化：无论内部操作多复杂，Skill应该返回一个结构化的结果，表明任务成功与否，以及关键产出物（如部署后的访问URL）。

Skill的常见实现形式：

脚本文件：最简单的形式，可以是一个Shell脚本（.sh）、Python脚本（.py）或任何可执行文件。Agent通过命令行调用它并传递参数。

配置文件（声明式）：更高级的形式，例如在一个YAML文件中定义Skill的元信息、输入参数、执行步骤（每一步调用哪个MCP Tool）。这需要有一个Skill执行引擎来解析并运行这个YAML。

# deploy-app.skill.yaml name: deploy_to_staging description: 将指定版本的应用部署到预发环境 inputs: - name: app_name type: string required: true - name: image_tag type: string required: true steps: - name: 验证Docker镜像存在 tool: docker_check_image arguments: image: "registry.example.com/{{ app_name }}:{{ image_tag }}" - name: 更新K8s部署配置 tool: k8s_update_deployment arguments: file: "manifests/{{ app_name }}/deployment.yaml" patch: spec: template: spec: containers: - name: app image: "registry.example.com/{{ app_name }}:{{ image_tag }}" - name: 等待部署就绪 tool: k8s_wait_for_rollout arguments: deployment: "{{ app_name }}-deployment" namespace: staging

函数（在Agent框架内）：在一些AI Agent开发框架（如LangChain、AutoGen）中，Skill可以直接实现为一个Python函数，并用装饰器标注，框架会自动将其暴露给Agent。

Skill与MCP Tool的关系：一个Skill内部通常会调用多个MCP Tools。它负责编排这些Tools的执行顺序、传递数据、处理中间状态。Skill让Agent的“思考”可以停留在更高的任务层面，而无需陷入琐碎的操作细节中。这也意味着，一个丰富的Skill库，是提升Agent能力的关键。

4. 实战：构建一个完整的AI-CLI工作流

理论说得再多，不如动手实践。让我们构想一个真实的场景，并一步步构建起一个基于四层架构的自动化工作流。假设你是一个开发者，经常需要处理GitHub仓库的日常事务。

场景：每周一早上，你需要查看所有你关注的仓库在过去一周的活跃度（Issue/PR情况），并将需要你Review的PR列出一个优先级清单。

传统方式：你需要打开浏览器，逐个访问仓库，人工查看并记录，费时费力且容易遗漏。AI驱动的新方式：你只需要对AI助手说：“帮我生成一份上周我关注仓库的活跃度报告，并高亮需要我Review的PR。”

4.1 第一步：夯实基础——准备AI友好的CLI工具

首先，我们需要确保底层工具是“AI可调用”的。以GitHub为例，官方的ghCLI工具本身就是优秀的典范。

安装与配置：确保gh已安装，并通过gh auth login完成认证。这是所有操作的前提。

验证结构化输出：我们测试几个关键命令，确保它们支持机器可读的输出格式。

# 列出我的仓库，以JSON格式输出 gh repo list --limit 5 --json name,updatedAt,owner # 查看某个仓库的PR列表，以JSON格式输出 gh pr list --repo owner/repo --state open --json number,title,author,createdAt,reviewDecision

这些命令会返回纯净的JSON数组，没有多余的人类可读文本装饰，非常适合程序解析。

4.2 第二步：建立连接——创建GitHub MCP Server

接下来，我们创建一个MCP Server，将ghCLI的能力暴露出去。这里我们用Python的mcp库快速实现。

# github_mcp_server.py import subprocess import json from mcp.server import Server, NotificationOptions from mcp.server.models import InitializationOptions import mcp.server.stdio server = Server("github-mcp-server") @server.list_tools() async def handle_list_tools(): """向客户端声明本Server提供的工具""" return [ { "name": "list_my_repos", "description": "列出我拥有的或星标的仓库", "inputSchema": { "type": "object", "properties": { "limit": {"type": "integer", "description": "返回数量限制"} } } }, { "name": "get_repo_pulls", "description": "获取指定仓库的拉取请求列表", "inputSchema": { "type": "object", "properties": { "owner": {"type": "string", "description": "仓库所有者"}, "repo": {"type": "string", "description": "仓库名称"}, "state": {"type": "string", "enum": ["OPEN", "CLOSED", "MERGED"], "description": "PR状态"} }, "required": ["owner", "repo"] } } ] @server.call_tool() async def handle_call_tool(name: str, arguments: dict): """处理客户端对工具的调用请求""" if name == "list_my_repos": limit = arguments.get("limit", 10) # 调用底层 gh CLI 命令，捕获JSON输出 result = subprocess.run( ["gh", "repo", "list", "--limit", str(limit), "--json", "name,owner,nameWithOwner,updatedAt"], capture_output=True, text=True, check=True ) repos = json.loads(result.stdout) return {"content": [{"type": "text", "text": json.dumps(repos, indent=2)}]} elif name == "get_repo_pulls": owner = arguments["owner"] repo = arguments["repo"] state = arguments.get("state", "OPEN") result = subprocess.run( ["gh", "pr", "list", "--repo", f"{owner}/{repo}", "--state", state, "--json", "number,title,author,createdAt,reviewDecision"], capture_output=True, text=True, check=True ) pulls = json.loads(result.stdout) return {"content": [{"type": "text", "text": json.dumps(pulls, indent=2)}]} else: raise ValueError(f"Unknown tool: {name}") async def main(): async with mcp.server.stdio.stdio_server() as (read_stream, write_stream): await server.run(read_stream, write_stream, InitializationOptions()) if __name__ == "__main__": import asyncio asyncio.run(main())

这个Server启动后，任何支持MCP Client的AI Agent（如配置了该Server的Claude Code）就能直接发现并调用list_my_repos和get_repo_pulls这两个工具了。

4.3 第三步：封装逻辑——编写周报生成Skill

现在，我们编写一个Skill，它利用上述MCP Tools，完成周报生成的复合任务。这个Skill可以是一个Python脚本。

# weekly_github_report_skill.py import argparse import json from datetime import datetime, timedelta # 假设我们有与MCP Server交互的客户端库 # from mcp_client import call_tool def get_my_repos(limit=20): """调用MCP Tool: list_my_repos""" # 模拟MCP调用返回 # response = call_tool("list_my_repos", {"limit": limit}) # 这里为演示，我们模拟数据 return [ {"name": "ai-agent-project", "owner": {"login": "myorg"}, "updatedAt": "2025-04-01T10:00:00Z"}, {"name": "cli-toolkit", "owner": {"login": "myorg"}, "updatedAt": "2025-03-28T15:30:00Z"}, ] def get_repo_pulls(owner, repo, state="OPEN"): """调用MCP Tool: get_repo_pulls""" # response = call_tool("get_repo_pulls", {"owner": owner, "repo": repo, "state": state}) # 模拟数据 if repo == "ai-agent-project": return [ {"number": 123, "title": "Add MCP support", "author": {"login": "alice"}, "reviewDecision": "REVIEW_REQUIRED"}, {"number": 122, "title": "Fix bug in skill loader", "author": {"login": "bob"}, "reviewDecision": "APPROVED"}, ] return [] def generate_report(days=7): """生成周报的核心逻辑""" one_week_ago = (datetime.utcnow() - timedelta(days=days)).isoformat() + "Z" repos = get_my_repos() report = {"generated_at": datetime.utcnow().isoformat(), "repositories": []} for repo in repos: repo_name = repo["name"] owner = repo["owner"]["login"] # 获取近期PR pulls = get_repo_pulls(owner, repo_name, "OPEN") recent_pulls = [p for p in pulls if p.get("createdAt", "") > one_week_ago] needs_my_review = [p for p in recent_pulls if p.get("reviewDecision") == "REVIEW_REQUIRED"] repo_info = { "name": f"{owner}/{repo_name}", "recent_activity": { "total_pulls_last_week": len(recent_pulls), "pulls_needing_review": len(needs_my_review) }, "pulls_to_review": needs_my_review } report["repositories"].append(repo_info) return report if __name__ == "__main__": parser = argparse.ArgumentParser(description="生成GitHub仓库周报") parser.add_argument("--days", type=int, default=7, help="统计过去几天的活动") args = parser.parse_args() report = generate_report(args.days) print(json.dumps(report, indent=2))

这个Skill脚本定义了一个清晰的边界：它接收一个--days参数，内部封装了获取仓库列表、筛选PR、判断是否需要Review等所有逻辑。对于AI Agent来说，它只需要知道“调用weekly_github_report_skill这个技能，并告诉它统计过去7天”，就能得到一份结构化的报告，而不需要了解其中调用了多少次gh命令、如何处理时间过滤。

4.4 第四步：智能驱动——让AI Agent使用这一切

最后，我们将所有部分连接起来。在一个集成了MCP Client的AI Agent环境（例如Claude Code、Cursor with Agent）中：

启动MCP Server：在后台运行我们写的python github_mcp_server.py。
配置Agent：在Agent的设置中，添加这个MCP Server的连接（通常是stdio或socket）。
暴露Skill：将weekly_github_report_skill.py这个脚本放在Agent可以访问的路径，或者将其也封装成一个MCP Tool。
发出指令：现在，你可以直接对你的AI助手说：“运行每周GitHub报告技能。”或者更自然地说：“看看我上周有哪些PR需要处理？”

Agent会理解你的意图，自动调用对应的Skill。Skill在执行过程中，会通过MCP协议调用底层的GitHub工具，最终将一份整洁的报告呈现给你。整个过程，你无需打开浏览器，也无需记忆任何GitHub CLI命令语法。

5. 常见问题、挑战与最佳实践

在实际构建和运用这套四层架构时，你会遇到一些典型的挑战。下面是我在实践过程中踩过的一些坑和总结出的经验。

5.1 安全性：最大的挑战与应对策略

当CLI能力被AI Agent大规模调用时，安全边界变得模糊且至关重要。

权限泛滥：一个被授予了ghCLI访问权限的Agent，理论上可以删除你的仓库、修改生产配置。解决方案是实施最小权限原则。为AI Agent创建专用的、权限受限的账户或API Token。例如，GitHub Token只授予read:org, repo:read权限，而非完整的repo权限。
命令注入：如果Skill或Agent将未经严格过滤的用户输入直接拼接到CLI命令中，将导致严重的命令注入风险。解决方案是永远使用参数化调用，避免字符串拼接。例如，使用subprocess.run([‘gh’, ‘pr’, ‘view’, pr_number])而不是subprocess.run(f’gh pr view {user_input}’, shell=True)。
审计与溯源：必须记录每一个由AI发起的CLI调用。最佳实践是为MCP Server添加详细的日志功能，记录谁（哪个Agent/Session）、在什么时间、调用了什么工具、传入了什么参数、返回了什么结果。这不仅是安全需要，也是调试和优化工作流的关键。

5.2 错误处理与稳定性

AI Agent并不完美，它可能生成不合法的参数，或对工具能力产生误解。

工具调用失败：MCP Tool或底层CLI可能因各种原因失败（网络、权限、资源不存在）。Skill设计必须包含健壮的错误处理。不能因为一个仓库拉取失败就让整个周报任务崩溃。应该采用“尽力而为”的策略，收集部分成功的结果，并对失败部分提供清晰的错误信息，让Agent能决定是重试、跳过还是向用户求助。
输入验证与Schema：在MCP Tool和Skill的输入Schema中定义尽可能严格的校验规则（类型、枚举范围、正则表达式）。这能在调用发生前就拦截大部分无效请求。例如，stop_container工具的containerId参数，可以关联一个list_containers资源，让Agent先获取有效ID列表，再进行操作，避免盲目猜测。
超时与重试：网络CLI调用必须设置合理的超时。对于暂时的失败（如网络抖动），应在Skill或MCP Server层面实现指数退避的重试机制。

5.3 性能与成本考量

频繁通过AI Agent调用CLI可能会带来性能开销。

启动延迟：每次调用都启动一个新的CLI进程（如subprocess.run）开销很大。对于高频工具，考虑实现常驻的守护进程或使用客户端库。例如，对于Git操作，可以初始化一个GitPython客户端，在MCP Server进程内重复使用，而不是每次都调用git命令。
上下文管理：一些CLI操作是有状态的（如登录会话）。确保MCP Server能妥善管理这些状态，并在多个调用间保持，避免重复认证。
成本：如果底层CLI调用的是按量付费的云服务API（如awsCLI），AI Agent的频繁、自动化调用可能导致意外费用。务必设置预算告警和用量监控。可以在MCP Server层添加简单的限流和成本计量功能。

5.4 工具发现与Skill管理

随着工具和Skill越来越多，如何让Agent有效地发现和理解它们成了问题。

语义化描述：MCP Tool和Skill的description字段至关重要。要写得清晰、具体，包含典型用例和关键参数说明。好的描述能让AI更准确地匹配用户请求与可用能力。
Skill库与版本化：像管理代码库一样管理你的Skill。建立一个内部的Skill仓库，进行版本控制、依赖管理和文档维护。可以开发一个简单的Skill注册中心，让Agent在启动时能自动发现和加载可用的Skill。
测试：为Skill编写单元测试和集成测试。模拟MCP Tool的调用，验证Skill在各种输入和边界条件下的行为是否符合预期。这是保证AI驱动工作流可靠性的基石。

CLI在2025年的复兴，绝非简单的技术轮回。它是AI能力向现实世界渗透过程中，对确定性和可编程性接口的必然选择。CLI、MCP、Skill、Agent构成的四层架构，为我们提供了一套清晰、可扩展的蓝图，来设计和构建下一代人机协作应用。作为开发者，现在的任务不再是争论CLI好还是GUI好，而是如何将我们手中的工具和服务，更好地封装成AI可理解、可调用的“积木”。这个过程，本身就是一场深刻的效率革命。从我个人的实践来看，从一个小而具体的场景开始（比如自动化的GitHub周报），亲手搭建这条从自然语言到CLI命令的完整链路，是理解这套架构精髓最快的方式。当你看到AI助手流畅地执行着你曾经需要手动重复的操作时，你就会明白，未来已来，只是分布得还不均匀。而掌握这套架构，就是让你率先抵达未来的一张船票。

日记详情

CLI、MCP、Skill与Agent：AI时代四层架构重塑人机交互