企业官网建设流程全解析

打开 macOS 的“系统设置 -> 隐私与安全性”，找到“辅助功能”和“屏幕录制”，单独为 Hunch 授权。

6. 完整示例：用一个可复刻的 MCP Server 体验同样思路

如果你不想在看完这篇文章后还停留在概念层，下面这个例子可以让你 10 分钟内体会“LLM 通过 MCP 驱动 Mac”到底是怎么运转的。

它的思路和 Hunch 完全一致：一个后台服务把 Mac 能力包装成 Tool，LLM 通过标准协议调用它。

6.1 用 fastmcp 实现一个最小桌面工具服务

# 文件路径：server.py import os import time from pathlib import Path from mcp.server.fastmcp import FastMCP # 创建一个 MCP Server 实例，名字可以随意 mcp = FastMCP("hunch-demo") @mcp.tool() def desktop_files() -> str: """返回当前用户桌面上的文件清单。""" desktop = Path.home() / "Desktop" files = [p.name for p in desktop.iterdir() if p.is_file()] return "\n".join(files) if files else "桌面是空的" @mcp.tool() def send_notification(title: str, message: str) -> str: """发送一条 macOS 系统通知。""" import subprocess script = f'display notification "{message}" with title "{title}"' subprocess.run(["osascript", "-e", script], check=True) return "已发送通知" @mcp.tool() def create_screenshot_folder() -> str: """在桌面创建一个 screenshots 目录。""" target = Path.home() / "Desktop" / "screenshots" target.mkdir(exist_ok=True) return f"目录就绪：{target}" if __name__ == "__main__": mcp.run()

这是基于 fastmcp 库的官方用法写的，不是 Hunch 的源码。但它的结构能让你看清关键点：

1. FastMCP("hunch-demo")创建了一个符合 MCP 协议的服务端。
2. @mcp.tool()注册一个可调用的工具，函数名、参数、docstring 都会变成发送给 LLM 的工具描述。
3. mcp.run()启动服务，默认走 stdio 传输，等待客户端连接。

6.2 安装和启动

pip install fastmcp python server.py

正常情况下，进程会保持运行，不再输出内容。这说明它已经作为后台服务在等待来自 MCP client 的请求了。

6.3 用支持 MCP 的客户端连接

以 Claude Desktop 为例，在配置文件~/Library/Application Support/Claude/claude_desktop_config.json中加入：

{ "mcpServers": { "hunch-demo": { "command": "python", "args": ["/绝对路径/server.py"] } } }

重启 Claude Desktop，页面里能找到hunch-demo下面的desktop_files、send_notification、create_screenshot_folder三个工具。

6.4 让 LLM 执行一次完整任务

在对话里输入：

先看一下桌面上有哪些文件，然后创建一个 screenshots 目录，最后通知我“桌面准备就绪”。

你会发现 LLM 会依次调用三个工具：

1. desktop_files：读文件列表；
2. create_screenshot_folder：创建目录；
3. send_notification：发通知。

这就是 Hunch 类工具的完整工作链路。你可以把这里的任意一个函数换成日历、邮件、系统设置，本质都是同一套模式：LLM 理解意图，MCP 执行动作。

这个例子的价值在于：它把 Hunch 的“魔法感”还原成了可理解的标准协议操作。

7. 运行结果与效果验证

接入 Hunch 或上面这个 demo 之后，怎么判断它真的在工作？这里给一套可复用的验证流程。

7.1 检查服务进程

pgrep -fl hunch pgrep -fl hunch-demo

如果能看到对应进程，说明服务还在后台运行。如果刚启动就退出，大概率是命令路径、依赖或权限有问题。

7.2 检查 MCP 工具是否被发现

在 MCP client 中打开服务管理面板，正常情况下你会看到 Hunch 暴露的工具列表。如果你用的客户端不支持图形面板，可以观察对话中 LLM 是否自动出现“工具调用”动作。

工具列表为空时，最优先检查配置文件的 JSON 是否合法，然后检查 command 指向的二进制是否存在、是否有执行权限。

7.3 用一条只读任务做冒烟测试

不要一上来就测试“删除文件”，先让 LLM 执行只读操作，例如：

列出桌面上最近修改的 5 个文件。

如果这一步能返回准确结果，说明服务连接、权限读取和 LLM 工具选择都正常。再继续测试通知、文件移动等写操作。

7.4 查看 macOS 统一日志

log show --predicate 'process == "hunch"' --last 10m

出现TCC、permission、denied等字样时，优先去系统设置里检查隐私权限。

7.5 失败时的第一步

先看日志，再看权限，最后再看网络。对这类工具来说，90% 的启动问题都出在“配置合法但服务没起来”，以及“服务起来了但没有隐私权限”。

8. 常见问题与排查思路

9. 安全边界与最佳实践

Hunch 这类工具的价值和风险是同源的：“让 LLM 执行 Mac 操作”越顺畅，意味着 LLM 被授予的权限越大。

9.1 权限最小化，不授则不用

macOS 的“辅助功能”权限可以控制任何界面元素，“屏幕录制”权限可以读取任何屏幕内容。这两项权限不要顺手全给。

建议只对 Hunch 本身体授权，而不是把整个终端 App 都放到“辅助功能”列表里。如果你需要一个工具读写桌面文件，就不需要给它网络管理权限；如果你只需要日历操作，就不必开放终端执行。

9.2 限制 LLM 能接触的数据范围

把敏感文件移出容易被扫描的目录。桌面和“下载”目录是这类工具默认会先读取的位置。密钥、Token、合同、个人数据尽量不要长期放在这些目录里。如果 Hunch 支持配置忽略路径，优先配置。

9.3 重要操作默认加人工确认

删除、批量移动、发送消息、付款这类操作，理想情况下都应该有“执行前确认”机制。如果你的客户端不支持人工确认，就不要把这类权限暴露给模型，宁可关闭。

9.4 优先使用 dry_run 模式

Hunch 如果支持预览模式，务必先跑一遍。比如文件整理任务，可以先让 LLM 输出“将移动哪些文件、移到哪里”的计划，确认无误后再执行。这个习惯比事后回滚便宜得多。

9.5 日志审计与密钥轮换

要求保留工具调用日志，至少包含时间、调用方、工具名、入参、结果。每周抽查日志，看到不符合预期的调用，立即收回 API Key 和系统权限。

9.6 团队协作时要走评审

别把自动化配置文件直接推到生产电脑。配置先提交到版本仓库，由同事 review，确认后再部署。权限变更也应当走同样的流程，保留“谁在什么时候授权了什么”的痕迹。

9.7 不要给 LLM 任意 shell 权限

“让模型直接跑 shell 命令”看起来很强，实际上是把你的整台电脑交给一个可能产生幻觉的系统。理想状态是暴露白名单命令，例如只允许osascript发通知，只允许mv在指定目录内移动文件。

10. 两条实用建议

Hunch 的价值不在于“多了一个能控制 Mac 的 AI 工具”，而在于它验证了一种可行的交互模型：桌面自动化不再是“提前写死每一步的脚本”，而是“由模型按需调用标准工具”。桌面操作从“程序员的脚本”变成了“自然语言会话”，这是真实的生产力变化，但前提是你愿意承担新的安全责任。

最后提醒两件事：

第一，别急着把“整个磁盘整理”这种大任务交给它。先从读目录、发通知、创建文件夹这类只读或可逆任务开始，确认它理解你的意图，再逐步放开能力。

第二，把这份排查思路收藏起来。以后无论你用 Hunch、用 fastmcp 自建工具，还是接入其他 MCP 桌面服务，这套“配置是否正确 -> 进程是否存活 -> 权限是否授予 -> 日志是否报错”的排查顺序都适用。