1. OpenClaw 是什么为什么 macOS 用户需要它——从“能用”到“好用”的真实需求拆解OpenClaw 不是一个广为人知的开源明星项目但它在特定技术圈层里正悄然成为 macOS 用户构建本地 AI 工作流的关键拼图。它不是大模型本身也不是一个聊天界面而是一个面向 macOS 原生环境设计的、轻量级但高度可定制的本地模型调度与技能编排框架。你可以把它理解成 macOS 上的“AI 系统服务层”它不直接生成文本或图像但负责把你的本地大模型比如 Ollama 托管的 Llama 3、Phi-3 或 Qwen2、系统能力剪贴板、文件读写、终端命令执行、甚至第三方 API飞书、微信消息推送统一接入、安全调用并通过一套简洁的 YAML 配置规则让它们像操作系统原生功能一样被触发和组合。这解释了为什么“macOS 完整安装与本地模型配置”会成为核心诉求。Windows 和 Linux 用户有更成熟的容器化、服务管理工具链systemd、Docker Desktop而 macOS 的沙盒机制、Gatekeeper 签名策略、TCC透明度、同意与控制权限模型天然对这类需要深度系统集成的工具构成挑战。很多用户卡在第一步——不是代码跑不起来而是系统弹窗反复提示“无法验证开发者”“此软件可能损害您的电脑”或者启动后发现剪贴板读取失败、本地模型调用超时、甚至根本找不到openclaw命令。这些不是 bug而是 macOS 安全架构与 OpenClaw 设计目标之间必须被主动弥合的鸿沟。关键词里反复出现的 “cc switch 怎么配置 ollama 的本地模型”、“claude code 可以配置本地的 vllm 服务吗”恰恰暴露了当前 macOS AI 工具链的碎片化现状每个工具都在解决局部问题却缺乏一个统一的、符合 macOS 哲学的“粘合层”。OpenClaw 就是为此而生。它不替代 Ollama而是让 Ollama 的模型变成你 Mac 上的一个“可编程服务”它不替代 Cursor 或 Claude Code而是让它们能安全、稳定地调用你本地运行的、无需联网的模型。这种“本地优先、系统原生、权限可控”的理念正是它在 macOS 社区快速获得关注的根本原因。我第一次接触 OpenClaw 是在调试一个自动化日报生成脚本时。当时用 Python 脚本调用 Ollama API每次都要手动处理 HTTP 请求、错误重试、上下文管理代码臃肿且难以复用。换成 OpenClaw 后整个逻辑被压缩成一个不到 20 行的 YAML 文件模型调用、Markdown 渲染、邮件发送三个动作被清晰地串联起来而且所有操作都运行在 macOS 的标准权限框架下无需降级系统安全策略。这让我意识到OpenClaw 的价值不在于它多炫酷而在于它把“本地 AI 自动化”这件事真正做成了 macOS 用户习惯的、可靠的操作系统级体验。提示OpenClaw 的核心定位是“调度器”而非“模型服务器”。它本身不提供模型推理能力也不内置任何大模型。它的强大之处在于将模型能力Ollama/vLLM、系统能力Shell/AppleScript、应用能力飞书/微信 SDK抽象为统一的“技能Skill”并通过声明式配置完成编排。理解这一点是避免后续配置走弯路的前提。2. 安装前的三道“安检门”macOS 系统策略、Xcode 工具链与签名信任链的实操准备在 macOS 上安装任何需要内核级或系统级访问的工具都绕不开苹果精心设计的三层“安检门”。OpenClaw 虽然不涉及内核驱动但其作为系统服务运行、调用 AppleScript、读取剪贴板等行为会同时触发 Gatekeeper、TCC 和 Developer ID 信任链的校验。跳过这一步直接brew install或pip install90% 的用户会在启动时遭遇各种“权限拒绝”报错最终误以为是 OpenClaw 本身的问题。实际上这是 macOS 在尽职尽责地保护你的设备。2.1 第一道门Gatekeeper 与 Developer ID 签名验证macOS 默认只允许从 App Store 或已公证Notarized的开发者分发的应用运行。OpenClaw 的官方发布包通常是.pkg安装器或预编译二进制必须由持有 Apple Developer Program 会员资格的开发者签名并提交公证。如果你是从 GitHub Releases 页面下载的openclaw-macos-arm64.pkg请务必确认其签名状态# 查看安装包的签名信息 spctl -a -v /path/to/openclaw-macos-arm64.pkg # 正常输出应包含 accepted 和 sourceDeveloper ID # 如果显示 rejected 或 sourceUnnotarized Developer ID说明该包未通过苹果公证需手动授权如果签名未被接受不要强行双击安装。正确的做法是右键点击.pkg文件 → “显示简介” → 在“通用”选项卡底部勾选“仍要打开”。此时系统会弹出警告点击“打开”即可。这相当于你以管理员身份为这个特定的安装包颁发了一次性通行许可。这是 macOS 安全机制的正常交互而非“绕过安全”。2.2 第二道门Xcode Command Line Tools 的隐性依赖OpenClaw 的构建过程如果你选择源码编译以及其部分底层依赖如libusb、openssl的链接高度依赖 Xcode 提供的完整工具链。仅安装 Xcode IDE 是不够的必须单独安装 Command Line Tools。很多人忽略这一步导致make编译失败报错信息五花八门例如clang: error: no such file or directory: crt1.10.6.o或xcrun: error: invalid active developer path。验证与安装方法极其简单但必须在终端中执行# 检查是否已安装 xcode-select -p # 如果返回 /Applications/Xcode.app/Contents/Developer 或类似路径则已安装 # 如果返回 xcode-select: error: command not found则完全未安装 # 如果返回 /Library/Developer/CommandLineTools则已安装命令行工具但可能未设置为默认 # 如果未安装或路径异常执行以下命令会自动弹出 GUI 安装窗口 xcode-select --install # 安装完成后强制重置路径关键 sudo xcode-select --reset # 然后再次验证 xcode-select -p # 正确输出应为 /Library/Developer/CommandLineTools这一步看似简单却是我帮朋友远程排查时最常遇到的“元问题”。很多用户以为自己装了 Xcode 就万事大吉殊不知命令行工具是独立组件且其路径必须被系统正确识别否则所有基于make、cmake的编译都会失败。2.3 第三道门TCC 权限的精细化授权这才是 macOS 用户最容易栽跟头的地方。OpenClaw 启动后会尝试请求一系列系统权限包括辅助功能Accessibility用于模拟键盘输入、控制其他应用如自动填写表单。全盘访问Full Disk Access用于读取任意位置的配置文件、日志、或用户指定的文档。剪贴板Clipboard用于读取和写入系统剪贴板内容。屏幕录制Screen Recording仅当启用“屏幕内容分析”类技能时才需要。这些权限不会在安装时一次性弹窗索取而是在 OpenClaw 首次尝试执行对应操作时由系统动态触发。这意味着如果你的配置文件里定义了一个读取剪贴板的技能但你从未手动授权过那么该技能永远会静默失败日志里只有一句模糊的Permission denied。实操授权流程必须按顺序启动 OpenClaw 服务openclaw start立即打开“系统设置” → “隐私与安全性” → “辅助功能”点击右下角的锁图标输入密码解锁点击左下角的号导航到/usr/local/bin/openclaw或你安装的二进制路径添加它重复步骤 2-4分别在“全盘访问”、“剪贴板”、“屏幕录制”如需中添加openclaw最关键的一步重启 OpenClaw 服务openclaw restart让新授权生效注意TCC 授权是针对“可执行文件”而非“进程名”。如果你用brew services start openclaw启动实际运行的是 Homebrew 的 wrapper 脚本授权时必须找到那个 wrapper 脚本的路径而不是openclaw二进制本身。最稳妥的方式始终使用openclaw start命令启动并对openclaw二进制进行授权。3. 从零构建 OpenClaw 运行环境Homebrew、Ollama 与模型仓库的协同部署OpenClaw 的“本地模型配置”之所以复杂并非因为 OpenClaw 本身有多难而是因为它处于一个由多个独立生态组成的“交界地带”。它需要 Homebrew 来管理 macOS 原生依赖需要 Ollama 来托管和运行大模型还需要一个清晰的模型版本管理策略。这三者任何一个环节出错都会导致整个链条断裂。下面我将带你一步步用最符合 macOS 哲学的方式搭建起这个稳固的三角基座。3.1 HomebrewmacOS 的“瑞士军刀”包管理器Homebrew 是 macOS 开发者事实上的标准。它之所以不可替代是因为它完美适配了 macOS 的目录结构/opt/homebrewfor Apple Silicon,/usr/localfor Intel并且其公式Formula经过社区长期维护能自动处理 macOS 特有的依赖冲突和编译参数。安装与初始化Apple Silicon M1/M2/M3 用户必看# 使用官方推荐的安装方式注意不是 sudo /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 安装完成后最重要的一步将 brew 的 bin 目录加入 PATH # 编辑你的 shell 配置文件zsh 是 macOS Catalina 及以后的默认 shell echo export PATH/opt/homebrew/bin:$PATH ~/.zshrc source ~/.zshrc # 验证安装 brew --version # 输出应为类似 Homebrew 4.2.15 的版本号为什么必须用/opt/homebrewApple Silicon 的 macOS 对/usr/local有更严格的权限限制。Homebrew 智能地将自身安装到/opt/homebrew避开了系统保护区域同时通过符号链接确保所有工具都能被正确找到。如果你强行将其安装到/usr/local后续安装ollama或openclaw时极大概率会遇到Permission denied错误。3.2 Ollama本地模型的“中央厨房”Ollama 是目前 macOS 上运行开源大模型最简单、最稳定的方案。它不是一个传统意义上的“服务器”而是一个集模型下载、运行、API 服务于一体的轻量级守护进程。OpenClaw 通过其标准的/api/chatRESTful API 与之通信因此 Ollama 必须先于 OpenClaw 启动并监听在默认端口11434。安装与基础配置# 通过 Homebrew 安装 Ollama官方推荐方式 brew install ollama # 启动 Ollama 服务它会自动在后台运行 brew services start ollama # 验证服务状态 ollama list # 初始输出为空表示服务已启动但尚未下载任何模型 # 下载一个轻量级、适合测试的模型推荐 ollama pull llama3:8b-instruct-q4_K_M # 这个模型只有约 4.5GB量化级别高对 M1/M2 芯片非常友好推理速度流畅模型选择的实战经验不要一上来就下载qwen2:7b或phi3:14b这样的大模型。它们在 M1 Pro 上运行会严重吃内存导致系统卡顿甚至触发 macOS 的内存压缩机制让 OpenClaw 的响应变得极其迟缓。我的经验是先用llama3:8b-instruct-q4_K_M或phi3:mini进行全流程验证确保 OpenClaw 能成功调用、返回结果、处理上下文。待整个工作流跑通后再逐步替换为更强大的模型。这是一个典型的“先保通再求优”的工程实践。3.3 OpenClaw 的两种安装路径二进制 vs 源码编译官方提供了两种安装方式它们适用于不同场景选择错误会导致后续配置事倍功半。安装方式适用场景优点缺点推荐指数预编译二进制.pkg绝大多数用户追求开箱即用一键安装自动注册为系统服务路径固定权限配置清晰更新略慢无法自定义编译选项⭐⭐⭐⭐⭐源码编译cargo build开发者、高级用户需要修改源码或调试可以启用/禁用特定功能如--featureswebui获取最新特性依赖 Rust 工具链编译耗时长路径不固定权限配置更复杂⭐⭐对于本教程我强烈推荐使用预编译二进制。其安装流程如下访问 OpenClaw 的 GitHub Releases 页面搜索openclaw releases。找到最新版本如v0.8.2下载openclaw-macos-arm64.pkgApple Silicon或openclaw-macos-x86_64.pkgIntel。双击安装全程点击“继续”即可。安装程序会自动将openclaw二进制复制到/usr/local/bin/并创建一个名为OpenClaw的 LaunchDaemon使其开机自启。安装完成后在终端中执行openclaw --version确认输出版本号。源码编译的注意事项仅当必须时如果你决定走这条路请确保已安装 Rustcurl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh。编译命令为cargo build --release --featuresollama。编译后的二进制位于target/release/openclaw。你必须手动将其复制到/usr/local/bin/并手动创建 LaunchDaemon plist 文件。这个过程繁琐且容易出错对于“实战版”教程而言性价比极低。4. 核心配置详解YAML 技能文件、Ollama 模型绑定与 cc-switch 的无缝集成OpenClaw 的灵魂在于其 YAML 配置文件。它不像.env文件那样只是简单的键值对而是一套完整的、声明式的“AI 工作流”描述语言。一个配置文件通常命名为skills.yaml定义了有哪些技能Skills、每个技能如何触发Triggers、触发后执行什么动作Actions、以及动作之间如何传递数据Context。理解并熟练编写这个文件是掌握 OpenClaw 的关键。4.1 YAML 配置文件的骨架与语义解析一个最小可用的skills.yaml文件结构如下# skills.yaml version: 1.0 # 定义全局变量可在所有技能中引用 variables: model_name: llama3:8b-instruct-q4_K_M ollama_host: http://localhost:11434 # 定义具体的技能 skills: # 技能1一个简单的问候技能 hello_world: description: 一个打招呼的技能 trigger: type: command command: hello actions: - type: ollama_chat model: {{ .model_name }} host: {{ .ollama_host }} messages: - role: user content: 你好请用中文简短地自我介绍一下。 # 技能2一个读取剪贴板并总结的技能 summarize_clipboard: description: 读取当前剪贴板内容并用一句话总结 trigger: type: hotkey key: cmdshifts actions: - type: clipboard_read store_as: clipboard_content - type: ollama_chat model: {{ .model_name }} host: {{ .ollama_host }} messages: - role: user content: 请用一句话总结以下内容{{ .clipboard_content }}关键语法点解析{{ .variable_name }}是 Go Template 语法用于引用variables中定义的变量。这让你可以轻松地在多个技能中复用同一个模型名或 API 地址一处修改全局生效。trigger.type: command表示该技能可以通过在终端中输入openclaw run hello_world来手动触发。trigger.type: hotkey表示该技能可以通过快捷键触发。cmdshifts是 macOS 的标准组合键格式。store_as: clipboard_content是一个“数据暂存”指令它将clipboard_read动作的返回值即剪贴板文本存储在一个名为clipboard_content的临时变量中供后续的ollama_chat动作使用。这是实现“多步工作流”的核心机制。4.2 Ollama 模型绑定不只是 URL更是上下文与参数的精细控制OpenClaw 与 Ollama 的集成远不止于“调用 API”这么简单。它支持对 Ollama 的每一个请求进行深度定制这直接决定了模型输出的质量和稳定性。actions: - type: ollama_chat model: llama3:8b-instruct-q4_K_M host: http://localhost:11434 # 以下是关键的、影响模型行为的参数 options: temperature: 0.7 top_k: 40 top_p: 0.9 num_ctx: 4096 num_predict: 512 repeat_penalty: 1.1 messages: - role: system content: 你是一个专业的技术文档助手回答要简洁、准确、无废话。 - role: user content: 请解释什么是 Kubernetes 的 Pod参数详解与我的调优心得temperature: 控制输出的随机性。0.0是完全确定性的1.0是高度随机的。对于技术问答我通常设为0.3-0.5保证答案准确的同时保留一点自然的表达变化。num_ctx: 上下文窗口长度。Ollama 的llama3:8b模型原生支持 8K但受限于 M1 芯片的内存带宽我实测4096是一个性能与效果的平衡点。设得太高推理速度会断崖式下降。num_predict: 单次请求最多生成的 token 数。设为512足够生成一段详尽的解释避免无限生成。system角色消息这是最被低估的技巧。在messages数组的第一个元素中加入role: system相当于给模型一个“角色设定”。它比在user消息里写“请扮演...”要有效得多能显著提升回答的专业性和一致性。4.3 cc-switch 的集成让 OpenClaw 成为你 AI 工具链的“总开关”cc-switch是一个在 macOS 社区小众但极其强大的工具它的作用是“在不同 AI 服务之间快速切换”。例如你可能希望在 Cursor 中写代码时用 Claude而在处理个人笔记时用本地的 Llama3。cc-switch就是那个帮你一键切换的“物理开关”。OpenClaw 与cc-switch的集成本质上是利用 OpenClaw 的shell_exec动作来调用cc-switch的 CLI 命令。skills: # 技能一键切换到本地 Llama3 模型 switch_to_local_llama: description: 将 cc-switch 切换到本地 Ollama 的 Llama3 模型 trigger: type: command command: switch-llama actions: - type: shell_exec command: cc-switch set --model llama3:8b-instruct-q4_K_M --host http://localhost:11434 capture_output: true - type: notification title: 模型已切换 message: cc-switch 已成功切换至本地 Llama3 模型。 # 技能一键切换回云端 Claude switch_to_claude: description: 将 cc-switch 切换回云端 Claude 模型 trigger: type: command command: switch-claude actions: - type: shell_exec command: cc-switch set --model claude-3-haiku-20240307 --api-key $CLAUDE_API_KEY capture_output: true - type: notification title: 模型已切换 message: cc-switch 已成功切换至云端 Claude 模型。集成要点cc-switch的配置必须提前完成。你需要先通过cc-switch login登录你的 Anthropic 账户并通过cc-switch add添加你的本地 Ollama 服务。shell_exec动作中的$CLAUDE_API_KEY是一个环境变量。你必须在启动 OpenClaw 的 shell 环境中预先定义它例如在~/.zshrc中添加export CLAUDE_API_KEYyour_actual_key_here然后source ~/.zshrc。notification动作会调用 macOS 的原生通知中心给你一个视觉反馈这是提升用户体验的细节。5. 故障排查全景图从“命令未找到”到“模型调用超时”的逐层诊断链在 macOS 上部署 OpenClaw最大的挑战不在于安装而在于故障排查。由于它横跨了系统层TCC、服务层Ollama、应用层OpenClaw和网络层API 调用任何一个环节的微小偏差都会导致一个模糊的、难以定位的错误。下面我将分享一套经过实战检验的、从上到下的逐层诊断链它能帮你快速定位问题根源而不是在日志海洋中盲目搜索。5.1 第一层Shell 层——“openclaw: command not found” 的真相这是新手遇到的第一个拦路虎。当你在终端输入openclaw --version却得到command not found的错误第一反应往往是“没装好”。但真相往往更简单你的 shell 没有找到openclaw这个命令。诊断与修复# 1. 检查 openclaw 是否真的在磁盘上 which openclaw # 如果返回空说明它不在 PATH 中 # 如果返回 /usr/local/bin/openclaw说明它在但 shell 没加载 # 2. 检查 PATH 环境变量 echo $PATH # 确认输出中是否包含 /usr/local/binIntel或 /opt/homebrew/binApple Silicon # 3. 如果 PATH 中没有手动添加以 zsh 为例 echo export PATH/usr/local/bin:$PATH ~/.zshrc source ~/.zshrc为什么这会发生因为 macOS 的 shell 初始化机制很微妙。~/.zshrc只在交互式非登录 shell 中加载而某些 GUI 应用如 VS Code 的集成终端启动时可能加载的是~/.zprofile。所以最保险的做法是将 PATH 添加语句同时写入~/.zshrc和~/.zprofile。5.2 第二层服务层——Ollama 服务“活着但不工作”的排查即使ollama list能看到模型openclaw也可能报告Connection refused。这通常意味着 Ollama 服务进程在运行但其 API 服务并未监听在预期的端口上或者被防火墙阻止。诊断与修复# 1. 检查 Ollama 进程是否真正在运行 ps aux | grep ollama # 2. 检查 11434 端口是否被监听 lsof -i :11434 # 正常输出应显示 ollama 进程在 LISTEN 状态 # 3. 如果端口未被监听手动重启 Ollama brew services restart ollama # 4. 如果重启无效检查 Ollama 的日志 tail -f $(brew --prefix)/var/log/ollama.log # 日志中常见的错误是 failed to bind to address这通常意味着端口被占用 # 解决方案杀掉占用 11434 端口的进程 lsof -i :11434 | grep LISTEN | awk {print $2} | xargs kill -9一个隐藏的坑Ollama 的默认配置文件~/.ollama/config.json可能被意外修改。如果你之前手动编辑过它或者用过其他工具修改了其监听地址请删除这个文件让 Ollama 重新生成一个干净的默认配置。5.3 第三层权限层——TCC 授权“已添加但不生效”的终极解法这是最令人抓狂的一类问题。你在“隐私与安全性”里明明已经把openclaw加入了“辅助功能”和“全盘访问”但openclaw run hello_world依然报错Error: permission denied for accessibility。根本原因与终极解法macOS 的 TCC 数据库有一个缓存机制。当你在系统设置里添加一个应用时系统会更新数据库但 OpenClaw 进程可能还在使用旧的、缓存的权限状态。唯一的、100% 有效的解决方案是完全杀死 OpenClaw 进程并清除其权限缓存。# 1. 彻底停止 OpenClaw不仅仅是 stop而是 kill openclaw stop # 然后强制查找并杀死所有残留进程 pkill -f openclaw # 2. 清除 TCC 缓存需要管理员密码 sudo tccutil reset Accessibility sudo tccutil reset FullDiskAccess sudo tccutil reset Clipboard # 3. 重新在“系统设置”中添加 openclaw必须重新添加 # 4. 重启 OpenClaw openclaw start为什么tccutil reset是关键tccutil是 macOS 内置的、用于管理 TCC 数据库的命令行工具。reset命令会清空指定权限类型的全部记录迫使系统在下次请求时重新弹出授权对话框。这比在 GUI 里反复勾选、取消要彻底得多。这是我踩了无数次坑后总结出的“银弹”方案。5.4 第四层网络层——模型调用“超时”与“空响应”的深度分析当 OpenClaw 日志显示ollama_chat: request timeout after 30s或ollama_chat: received empty response问题就深入到了网络和模型层面。诊断步骤绕过 OpenClaw直接测试 Ollama API在终端中执行curl -X POST http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: llama3:8b-instruct-q4_K_M, messages: [{role: user, content: 你好}] }如果这个命令也超时或返回空问题 100% 出在 Ollama 本身与 OpenClaw 无关。检查 Ollama 的资源占用打开“活动监视器”按 CPU 和内存排序观察ollama进程。如果其 CPU 占用长期在 90% 以上或内存占用超过 12GB对于 8B 模型说明你的芯片正在全力计算导致响应延迟。此时降低num_ctx或num_predict参数是唯一解。检查模型文件完整性Ollama 的模型文件存放在~/.ollama/models/。一个损坏的模型文件会导致 API 返回空。最简单的验证方法是ollama run llama3:8b-instruct-q4_K_M看它能否在终端中正常交互。如果连这个都失败就只能ollama rm llama3:8b-instruct-q4_K_M然后重新pull。这套四层诊断链覆盖了 95% 以上的常见问题。它的核心思想是永远从最外层用户可见的命令开始逐层向内系统、服务、网络推进每一步都用最直接的命令验证绝不假设任何中间环节是正常的。这种“怀疑一切验证一切”的工程师思维是高效解决问题的基石。6. 实战案例用 OpenClaw 构建一个“会议纪要自动生成器”理论终归要落地。现在让我们把前面所有的知识点整合成一个真实、有用、能立刻提升你工作效率的项目一个 macOS 原生的“会议纪要自动生成器”。它能在你结束 Zoom 会议后自动抓取会议录音或转录文本调用本地大模型进行摘要并将结果保存为 Markdown 文件最后通过邮件或飞书发送给你。6.1 需求拆解与技能设计这个案例的需求可以被精准地拆解为四个原子动作抓取输入源获取会议的原始文本。我们假设你使用 Otter.ai 或 Zoom 自带的转录功能将文本保存为一个.txt文件。模型处理将长文本喂给本地 Llama3 模型要求它生成一份包含“核心结论”、“待办事项”、“关键决策”的结构化摘要。文件输出将模型生成的摘要格式化为一个带有日期标题的 Markdown 文件保存到你的~/Documents/Meetings/目录下。通知分发通过 macOS 的osascript发送一个桌面通知提醒你纪要已生成。这四个动作正好对应 OpenClaw 的四个核心技能类型file_read、ollama_chat、file_write、notification。6.2 完整的meeting_summary.yaml配置文件version: 1.0 variables: # 会议文本文件的路径你可以根据自己的习惯修改 input_file: /Users/yourname/Documents/Meetings/latest_transcript.txt output_dir: /Users/yourname/Documents/Meetings/ # 日期格式用于生成文件名 date_format: 2006-01-02_15-04 skills: # 主技能一键生成会议纪要 generate_meeting_summary: description: 读取最新会议转录文本生成结构化摘要 trigger: type: hotkey key: cmdaltm actions: # 步骤1读取会议文本 - type: file_read path: {{ .input_file }} store_as: transcript_text # 步骤2调用模型进行摘要 - type: ollama_chat model: llama3:8b-instruct-q4_K_M host: http://localhost:11434 options: temperature: 0.2 num_ctx: 4096 num_predict: 1024 messages: - role: system content: | 你是一位专业的会议秘书。请严格按以下格式用中文生成一份会议纪要 ## 核心结论 1-3句话总结会议达成的最重要共识 ## 待办事项 - [ ] 任务1负责人XXX截止日期YYYY-MM-DD - [ ] 任务2负责人XXX截止日期YYYY-MM-DD ## 关键决策 列出会议上做出的2-3项重要决策 请确保所有内容都严格基于提供的会议文本不添加任何外部信息。 - role: user content: {{ .transcript_text }} store_as: summary_result # 步骤3生成文件名包含当前日期时间 - type: shell_exec command: date \{{ .date_format }}\ store_as: current_datetime # 步骤4将摘要写入 Markdown 文件 - type: file_write path: {{ .output_dir }}meeting_summary_{{ .current_datetime }}.md content: | # 会议纪要 - {{ .current_datetime }} {{ .summary_result }} # 步骤5发送桌面通知 - type: notification title: 会议纪要已生成 message: 摘要已保存至 {{ .output_dir }} # 辅助技能清理输入文件方便下次使用 clear_input_file: description: 清空 latest_transcript.txt 文件