WPF实战：基于.NET 7的《永劫无间》战绩桌面助手开发
2026/9/26 7:04:42
然后把mcp的python代码写在scripts/里
你的理解部分正确，但需要澄清一个关键点：
Agent Skills 并不是“把 MCP 方法改成 CLI 方法”，而是提供了一种更轻量、更结构化的方式来封装任务逻辑——其中可以包含 CLI 调用、脚本执行、提示词模板等。MCP 和 Agent Skills 是互补的，而非替代关系。
✅ 正确的理解应该是：
表格
| 维度 | MCP（Model Context Protocol） | Agent Skills |
|---|---|---|
| 定位 | 连接协议：统一接入外部工具/数据源（如数据库、API、文件系统） | 能力包：封装“怎么做某类事”的完整流程（含指令、脚本、资源） |
| 作用 | 让 Agent能访问外部能力（“有插座”） | 让 Agent知道怎么用这些能力（“有操作手册”） |
| 实现方式 | 通过标准 JSON-RPC 协议与独立服务通信 | 本地文件夹（SKILL.md+scripts/），可直接调用 CLI/脚本 |
| 是否依赖 CLI？ | 不一定（MCP 工具可用任何语言实现） | 可以使用 CLI，但不是必须（也可用 Python 脚本、纯提示词等） |
🔍 为什么你会觉得“Skills 是把 MCP 改成 CLI”？
因为在实际落地中，很多原本通过 MCP 暴露的简单工具（比如fetch、git、pdf-parse），现在被开发者直接写成 Shell/Python 脚本，放进 Skill 的scripts/目录，并通过subprocess调用——绕过了 MCP Server 的部署复杂性。
举个例子：
- MCP 方式：
启动一个mcp-server-git服务 → Agent 通过 MCP 协议调用git clone。 - Skill + CLI 方式：
在 Skill 中直接写：python编辑
→ 无需 MCP Server，更轻量。subprocess.run(["git", "clone", url], cwd=work_dir)
✅这确实是当前流行的做法，尤其适合：
- 内部工具
- 确定性高、安全性可控的场景
- 快速原型开发
🧠 官方视角（Anthropic / Agentic AI Foundation）
“MCP connects Claude to data, Skills teach Claude what to do with that data.”
—— Anthropic 工程团队
也就是说：
- MCP 负责“拿数据”（连接世界）
- Skills 负责“处理数据”（专业做事）
你完全可以：
- 用MCP 获取数据库记录
- 用Skill 中的 Python 脚本分析数据并生成报告
两者协同工作。
✅ 结论
表格
| 说法 | 是否准确 |
|---|---|
| “Agent Skills 就是把 MCP 改成 CLI” | ❌不准确（过度简化） |
| “Agent Skills 可以用 CLI 实现原本由 MCP 提供的工具功能，从而简化架构” | ✅准确（工程实践中的常见优化） |
| “Skills 和 MCP 是竞争关系” | ❌错误（它们是上下层协作关系） |
💡 建议用法
- 简单、确定性任务（如文件处理、Git 操作、HTTP 请求）→ 用Skill + CLI/脚本（轻量高效）
- 复杂、需治理的系统集成（如企业 ERP、多租户 API、审计日志）→ 用MCP（安全、标准化、可监控）
技术选型不是非此即彼，而是“该用 MCP 时用 MCP，该用 Skill 时用 Skill”。
如果你正在迁移一个具体 MCP 工具到 Skill，欢迎提供工具名称或功能，我可以帮你写出对应的 CLI/Skill 实现方案。