大多数人对 AI 助手的体验就是浏览器里的一个聊天框。输入问题，阅读回答，关闭标签页。好用是好用，但这样用其实是把它当搜索引擎在使——而不是当助手。真正的助手应该知道你关心什么，替你做事，偶尔还能告诉你一些你没想到要问的事情。

一批开源项目正在试图构建这样的东西——OpenClaw (docs.openclaw.ai)、QwenPaw (github)、Hermes Agent (hermes-agent.nousresearch.com) 等等。这篇文章想讨论两个问题：个人助手到底是什么？我们应该怎么构建它？我的观点是，"一个能帮你操作 PC 的聊天机器人"这种常见框架太窄了。个人助手更应该被理解成一个 agent 系统：它既可以直接和人交互（直接在控制台里使用它，或通过 Slack 等消息渠道跟它对话）、也可以被另一个 agent 调用（一个研究 agent 让它给十篇新论文排序；一个项目管理 agent 让它起草一封给客户的邮件）、或被一个应用集成（IDE 把它嵌进来做代码推理；CRM 调用它生成客户沟通文案；像 Redfin 这样的站点支持它，让 agent 替用户去与房源、成交对比、看房预约交互），还可以自己按计划在后台跑定时任务，主动把结果推给你（或推给上面任何一方），而不是等着被问。这些情况下核心都是同一个——变的只是接口。我也会介绍我基于 QwenPaw 搭的一个小 demo——Copilot Digest。

§01 — 框架

个人助手 vs. 聊天机器人

我说"个人助手"，是指：一个持续运行在你的机器（或你控制的服务器）上的程序，能访问本地文件和工具，连接你日常使用的消息渠道，并且可以在你不在场的情况下执行操作。上述三个项目都能接入你已经在用的消息平台——Slack、Discord、Telegram、WhatsApp、iMessage、邮件等等 (OpenClaw, 2025; QwenPaw, 2025; Nous Research, 2025)。它们也越来越多地支持标准工具协议——MCP 面向 Claude.ai、IDE 这类 LLM 宿主应用，ACP 面向其他 agent——让非人类的调用方无需定制集成就能接进来。

仅此一点就是不错的体验提升，但另一个有意思的部分是你没有在跟它对话的时候发生的事情。

心跳与定时任务

这些项目通常都提供某种形式的定时主动行为。它们称之为心跳（heartbeat）：你在一个 markdown 文件中写下问题，设置间隔——比如早 8 点到晚 10 点之间每两小时一次——助手会按计划回答这些问题，并将回复推送到你最近聊天的渠道。你一觉醒来看到一条消息："昨晚有三篇关于检索增强生成的新预印本发布，以下是排序摘要。"你没有问过，它只是知道该去查。

独立的定时任务系统允许你调度各自独立的工作，每个有自己的时间和推送目标。早上 8 点的摘要推送、周五的合规检查、站会前的 PR 评审提醒。这些功能共同将助手从你去"拉取"的工具，变成了主动"推送"给你的存在。

这是一个很棒的概念——确实好用。但日复一日地使用之后，会暴露出一些从外部很容易低估的摩擦。

§02 — 不太舒服的部分

成本与安全

Token 消耗

每一次心跳触发都是一次完整的 LLM 推理调用。每一个定时任务都是一轮对话。一个每 30 分钟触发一次、覆盖 14 小时活跃窗口的心跳，每天上限约 28 次调用——而你还没有亲自问过一个问题。如果你使用的是云端模型（大多数人都是，因为在长链路 agentic 任务上，云端模型仍然比消费级硬件上能跑的本地模型更稳定可靠），成本积累得很快。根据模型和上下文长度的不同，单个常驻助手仅定时活动的 API 费用就能轻松达到每月数十美元。

你可以通过缩短上下文、使用更便宜的模型或拉长间隔来缓解，但有一个根本性的矛盾：你希望助手越主动、越有上下文感知能力，它消耗的 token 就越多。天下没有免费的午餐。

安全

这些助手拥有真实的工具——文件读写、shell 执行、网页浏览。各个项目采取了不同的防护策略：QwenPaw 叠加了基于模式匹配的工具守卫、文件路径限制和技能（skill）安全扫描 (QwenPaw 安全文档)；OpenClaw 使用 DM 配对、白名单和可选的 Docker 沙箱 (OpenClaw 安全文档)；Hermes Agent 提供六种执行后端（local、Docker、SSH、Daytona、Singularity、Modal），支持容器加固和隔离子助手 (Nous Research, 2025)。

这些都是有意义的防护措施，但并非无懈可击。模式匹配检测有盲区。提示注入——通过恶意输入诱使助手执行非预期操作——仍是一个开放性问题 (Greshake et al., 2023)。在生产环境中运行这些助手意味着要接受一定的运维开销：监控日志、审查工具调用、保持规则更新。

§03 — 我们在往哪里走

我们在往哪里走

整个生态在从两个方向扩展同一个核心——一条来自用户，一条来自项目本身。

在用户这一侧，主要的扩展机制是技能（skills）：领域特定的能力包（一个研究技能、一个代码评审技能、一个客户沟通技能），可以插进 agent 运行时，教它新的本领。因为技能生活在运行时之上，助手可以在边缘变得更聪明，而底层项目不必为此发新版本——任何人都可以通过写或装一个技能来扩展自己的助手。

在项目本身这一侧，工作沿两条互补的轴线推进。第一条是接口支持：面向人的消息渠道越来越多，同时 MCP 和 ACP 在整个生态中陆续落地，让 agent 和 LLM 宿主类应用都能无需定制集成就接进来。第二条是更强的 agent harness：运行时本身在变得更强。以 Hermes Agent 为例，它是自我改进（self-improving）的——它会把完成过的复杂任务蒸馏成可复用的技能、在使用中迭代这些技能，并周期性地把学到的东西持久化到 MEMORY.md 里 (Nous Research, 2025)。更好的工具调用循环、更好的记忆、更好的安全护栏——天花板在上移的同时，地板也在抬升。

§04 — 一个小 demo

一个小 demo：Copilot Digest

为了将这一点付诸实践，我基于 QwenPaw 构建了一个名为 Copilot Digest (源码) 的助手——可以把它想象成一个个性化的知识播客，帮你消化重要内容，在通勤、散步或做家务等碎片时间保持信息更新。它会摄取你发送给它、但没时间读的论文、文章、博客和新闻，然后将它们整理、排序、总结到一个本地知识库中。你可以浏览阅读列表、获取排序简报（"这周有什么值得关注的？"）、阅读完整文章摘要、深入讨论某篇论文、记录笔记和待办事项，以及导出编译报告。所有内容都以文件形式存储在你的机器上——一个包含索引、文章摘要、工作产出和导出的工作空间目录。

通过将定时任务指向你的 RSS 源或收藏链接，知识库会在你睡觉时自动增长。助手负责阅读、总结和归档；你只需出现并问有什么新的。这正是个人助手的用武之地——持续的、后台运行的工作，聊天机器人根本做不到。

我最想让 Copilot Digest 做的第一件事，就是在我不在屏幕前的时候也能用它——通勤、散步、做家务。光有语音输入是不够的，我要的是完整的、脱手脱眼的对话——开口说话、听它回复、一路聊下去，全程不用碰手机。这正是 Claude.ai 的 voice mode 现成就能做到、而且做得很好的事。要在这些 agent 项目上自己搭一层能与之相当的语音对话（它们自带的聊天界面顶多支持语音输入，不支持完整的双向语音对话），本身就是另一个项目。

我也不必自己做。只要能让 Claude.ai 去驱动我的 Copilot Digest agent，整套 voice mode 的体验就随之而来。MCP 就是那座桥：我把 Copilot Digest 暴露成一个 MCP 服务器，再作为自定义连接器注册到 Claude.ai 里，一个 LLM 宿主应用就变成了我本地 agent 的 voice mode 前端。agent 本身完全不用改。同一个核心，换一个消费者，语音对话就突然能用了。

§05 — 开放讨论

开放讨论

还有几个我仍在想的问题——目前这一波项目也没完全回答。

agent、工具和调用方需要都跑在同一台机器上吗？最省事的情况是"是"。但实际很少如此——我希望能从手机上给跑在笔记本上的 agent 发消息（但我不想走消息渠道）；也希望在公司电脑上用 IDE 接入一台桌下 Mac mini 上的 agent。这两种场景都需要把 agent 暴露到宿主机之外，而每一条暴露路径都有安全成本。消息渠道会把 agent 敞开给任何能给它发消息的人——prompt injection 就成了现成的攻击面；而一旦 bot token 泄露，攻击者还能直接冒充 bot。直接把端口暴露到公网更糟：今年年初 Censys 扫到超过 21,000 个 OpenClaw 实例把 gateway 绑到了 0.0.0.0 而不是 localhost，其中很多泄露了 API key 和聊天记录 (Censys, 2026)。有几种做法值得考虑——每个接口面单独做认证（API key、OAuth）挡住没凭证的陌生人；每个调用方都有自己的白名单，让拿到 token 的人也只能做部分事；再把整套东西放进像 Tailscale 这样的私有 overlay 网络里，让 agent 根本不用暴露到公网、连被敲门的机会都没有。

当 MCP、ACP 和消息渠道都不够用时怎么办？它们覆盖了常见场景，但本质上是通用型设计——为了服务尽可能多的调用方，只暴露所有人都能共用的那一小块能力。一个更高阶的构建者，如果想把助手深度嵌进一个产品里——带自定义状态、特定的 UI 语言、或某些没法用工具调用干净往返的操作——一定会撞墙。一个出口是项目本身给构建者提供 SDK，比如用来调用 "magic commands"，把一些希望 agent 固定执行的操作沉淀下来——用户在对话框里输入的斜杠式快捷指令（比如 /compact 压缩上下文、/clear 清空会话），由构建者把它们映射到确定的操作上。好处是那些常用、希望行为稳定的操作能被固化下来；代价是这套指令只在认这套 SDK 的产品里能用。我猜做得好的助手最后会两条路都走：协议让别的系统能接进来，SDK 让构建者自己掌握面向用户的那一层。

§06 — 结语

结语

大多数人今天用 AI，还是在用搜索引擎的方式——打开、输入、关闭。上面提到的这些项目指向一种更丰富的可能：一个能按自己的节奏运行、能接受来自其他 agent 和应用的调用、能出现在你本来就在工作的地方的助手。

再往远一点想："个人（personal）"这个定位本身，也许也是一种自我限制。等 SDK 这一层真的被做起来、MCP 和 ACP 这些接口协议真的稳定下来之后，没有什么理由让这类系统永远停留在小众玩家手里——它完全可以成为默认形态，替代聊天机器人，成为大多数人接触 AI 的方式。今天的个人助手，也许就是明天人人都在用的智能体。