mu：把工具和消息放进一个入口
用 AI agent 一段时间后，最常见的麻烦不是模型不够聪明，而是工具和消息被拆散了：查新闻要一个服务，读邮件要换另一个客户端，看行情还有一套接口；自己写的脚本、存的文档、和 agent 的历史对话，也散落在不同地方。token 烧在哪里、每个 agent 到底做了什么，又往往不可审计。
近期一堆项目在补这个洞：tare、tokentab、ctxrs/ctx 做 token 消耗审计与成本分析；concord-mcp、HarnessRouter、cumora、Firstmate 尝试多代理协作；还有不少 DeepSeek Harness (DSH) 插件在往前挤。原文把这三类分别标为 rising、steady、noisy，趋势时间是 2026-08-31。
mu 的切点不同：README 里没有 token 审计，也没提多代理互连，它只把 agents、tools、services 放进同一个入口。
以下内容基于 micro/mu 的 README 和仓库结构，我没有实际部署验证；安装和 MCP 两处未实测。
mu 是什么
一句话：为 agents、tools 和 services 提供一个共同的家。邮件、聊天、新闻、视频、搜索等服务可以通过网页、命令行、HTTP API 或 MCP 使用，产生的数据存在本地，可统一搜索。
先把它当工具箱用
mu 内置一批可直接调用的服务：
mu news list
mu web search "AI safety"
mu markets list --category stocks
mu weather forecast --lat 51.5 --lon -0.12
命令背后是服务和方法。网页、API、CLI、MCP 共用同一份工具目录：服务端加一个工具，其他入口跟着生效。这个比单独堆一批命令有价值——agent 不用为每个服务单独接一套接口。
README 列出 30 多个服务，包括新闻、邮件、市场、天气、地图、文件、任务、网页搜索（服务列表）。
agent 就是「名字 + 提示词 + 工具权限」
mu 里定义一个 agent 不需要代码。一个 agent 由名字、提示词、允许使用的工具组成。比如只做研究的 agent 只给新闻和网页搜索权限；处理个人资料的 agent 可以访问文档和收件箱。
通过网页、邮件、XMPP 或命令行对话：
mu ask "what is in my inbox?"
mu ask --agent research "anything new this week?"
每个 agent 有独立的 notes，一个 agent 的项目背景不会混进另一个 agent 的上下文。
这里解决的是一个现实问题：agent 变多之后，最难管的是它到底能访问什么。把工具权限写进配置，边界就清楚了。
Inbox：不是又一个邮箱
mu 提供统一 Inbox，邮件、聊天、短信、你和 agent 的对话都在同一个线程列表里。项目原话是：Inbox 只是这些记录的统一视图，不会造一个孤立的邮箱系统。也可以用普通邮件客户端走 IMAP 读（项目说明）。
这个设计对消息来源多的人有用：早上在命令行问过 agent，晚上收到邮件，第二天在网页里继续跟进，能回到同一条记录里。
代价也明显：所有消息放一起不等于它们自然会变清晰，搜索、线程、权限做不好，Inbox 就是一个新的垃圾堆。这三项的实际效果原文未提供，我也没有实测。
自托管能跑起来，配置不是零成本
官方提供安装脚本，支持 Docker Compose 和源码构建（安装说明）：
curl -fsSL https://raw.githubusercontent.com/micro/mu/main/install.sh | sh
mu --serve
启动后访问本地 8080 端口，第一个创建的账号是管理员。
装好只是开始：
- 网页搜索、视频、部分 AI 模型需要各自 API key。
- 邮件、Google 登录、支付是可选项。
- 默认客户端连
micro.mu托管实例；自己跑服务端要用mu login指到自己的地址（配置说明）。
HTTP API 和 MCP 共用工具目录。对外提供 API 用 token 或 OAuth；MCP 客户端连 /mcp。MCP 实际连通性未实测。
适合谁，不适合谁
适合：手里有邮件、文档、多个 agent 和一堆工具，希望网页、CLI、API、MCP 访问同一套能力，并且愿意自己维护自托管。
不适合：
- 只想找个 AI 聊天窗口，mu 偏重。
- 想要 token 消耗审计，mu 的 README 未提供这项能力，原文也没写明。
- 没有自托管经验，API key、数据存储、权限、模型配置都要自己理。
附带两个边界：许可协议是 AGPL 3.0；具体服务能不能用，还得看数据源和第三方服务条款。
mu 有意思的地方在于，它没有把 agent 当成孤立聊天窗口，而是放到服务、消息和本地数据之间。最后能不能成，取决于工具是否稳定、数据是否真可控、权限是否够清楚。
项目地址：github.com/micro/mu