McPet：把 AI 智能体装进一只会喘气的桌宠

想象这样一个场景：你让 Claude Code 或 Codex 跑一个长时间的代码重构任务，然后起身去泡咖啡。回来的时候，屏幕上不是黑漆漆的终端，而是一只蓝色的小鲸鱼，趴在桌角，脑袋上顶着气泡——"正在编译，还有 3 分钟"；任务报错时它抱头哀嚎，任务完成时它举起双手撒花。你完全不需要盯着终端，也不需要轮询日志。

这就是 McPet。它不是又一个终端 UI，而是把 Agent 的会话状态、token 用量、余额额度这些原本藏在日志里的"机器心跳"，翻译成了一只桌宠的表情和动作。更妙的是，它同时也是一个 MCP Server——你可以在和 AI 聊天时直接说"给鲸鲸换上麦麦套装""今天麦当劳有什么优惠"，让正在对话的那个模型顺手帮你操作。

项目起源：Anything Universe 系列的第一块拼图

McPet 属于作者 songconmaisaix31-design 组织的 "Anything Universe" 系列，同系列还有 swarm-anything（Agent 集群）和 blockchain-anything（链上能力）。仓库 2026 年 10 月 10 日创建，到 10 月 29 日仍在高频推送，仓库体积超过 100MB——其中大部分是像素动画素材（56 项动作、192/512 两种尺寸共 112 个 GIF）。

作者在 AGENTS.md 里定下的执行协议相当硬核：先读 HANDOFF.md 和 STATUS.md 建立基线，不确定的点必须问用户而不是自行决定，"去掉仅用于自我证明的步骤"。这套写法源自作者本身就用多个 Agent（Codex、Orca CLI）并行开发这个项目的实践——仓库里能看到 26 个开发分支和密集的 HANDOFF 交接文档。

STATUS.md 里有一句很克制的话，恰好说明了这个项目的真实成熟度：

麦当劳：已有真实报价 / 准备摘要；订单创建、付款与取餐待验收。

打个比方：它到底解决什么问题

把 McPet 想成你办公桌上的一个"值班同事"。

传统的 Agent 可观测性工具是一块仪表盘——你想知道状态，得主动切过去看面板。McPet 反其道而行，它是那种会主动拍你肩膀的同事："哎，那个任务卡住了。""你今天已经烧了 3.2 美元了，余额还剩 40 美元。""该吃饭了。"

这种设计差异背后是真实的心理学事实——人的注意力是稀缺资源。桌宠这种"低分辨率、高情感带宽"的存在形式，能让 Agent 状态从"需要主动查询的信息"变成"被动接收的信号"。作者甚至给鲸鱼做了 15 段动画和 9 张单帧姿态来覆盖工作流：待机、忙碌、思考、吃薯条、换装、睡觉、垂头叹气、开心庆祝。

核心功能拆解

1. 双形态架构：桌宠 + MCP Server

代码结构清晰地分成两条主线：

• 桌面形态（src/pet/、src/main.py）：Python + PySide6，透明窗口、托盘图标、气泡菜单、精灵图动画状态机（states.py / spritesheet.py / behavior.py）。这个模式完全独立运行。
• Agent 形态（src/agent_mcp.py、src/agent_service.py）：一个标准 MCP stdio Server，暴露 21 项工具，被宿主 Agent（Claude Code、OpenCode、Codex 或任何支持 MCP 的客户端）以子进程方式拉起。

两者共享同一份数据目录，Agent 下发的换肤和动作指令会传递给已经开着的桌宠窗口。项目还额外提供 .agents/skills/mcpet/SKILL.md 技能包，让 Agent 知道怎么用这 21 个工具。

2. 会话状态与用量追踪

src/progress/ 与 src/metering/ 负责解析 Claude / Codex / generic 三类 Agent 的本地日志，还原"当前在跑什么、等输入还是报错了"；src/metering/pricing.py 内置价格表，把 token 数换算成真实花费。用户也可以配置宿主事件直连（src/agentbridge/providers/ 下有 claude / codex / generic 三种 provider）。

值得注意的是这里有个诚实的限制说明：idle 或 Stop 信号不等于任务成功，日志范围和过时标记都会影响判定结果。

3. 餐饮与生活服务 MCP 工具

这是项目最"接地气"也最有争议的部分。src/mcd_mcp/（brain 33KB、client 13KB、tools 4.9KB、guards 5.5KB）实现了麦当劳与瑞幸的完整下单链路：查优惠券 → 选门店 → 查实时报价 → 预览实付价 → 确认生成订单 → 查取餐码 → 申请撤单，外加营养台账记账。

guards.py 是金额护栏，client.py 负责与品牌 API 通信，架构上是"Agent 决策 + 确定性执行"的分层。最新源码内置了公开试用凭证，所以新用户不用填 MCP Token 就能体验（试用走共享账号，长期使用建议配置自己的 Token）。

4. 定时提醒与余额看板

src/schedule/ 提供默认 11:30 饭点、15:00 咖啡时间的提醒；src/accounts/ 可以只读查询 Orca 缓存额度和 DeepSeek 官方余额，并按来源、窗口、币种分别显示，未知的一律标 UNKNOWN 而不是瞎猜。

上手门槛比想象的低，但有平台硬约束

好消息是有三条并行的上手路径，任选其一：

路径	门槛	说明
Windows 便携包	最低	下载 McPet-v0.1.0-windows-x64.zip，双击 Start-Pet.vbs，内置 Python 运行环境
Agent 通用包	低	需 Python 3.10+，装 requirements-agent.txt（只有 httpx / python-dotenv / mcp / jsonschema 四个依赖，不含 Qt），跑 python -m src.agent_install
源码运行	中	pip install -r requirements.txt（会带上 PySide6、pytest、Pillow），然后 python -m src.main --desktop

硬约束在于：桌面形态主要在 Windows 上完整验收，macOS / Linux 的桌面环境和托盘兼容性尚未完整验证。Agent 形态则跨平台，因为不依赖 Qt。

争议与局限

说几个客观存在的问题：

第一，许可证缺失。 根目录没有 LICENSE 文件，GitHub API 返回 spdx_id: null，SPDX 判定为 NOASSERTION。仓库里 assets/dsh-deepseek/LICENSE 和 docs/media/deepseek/DSH-LICENSE 只覆盖第三方素材，不覆盖主代码。对企业落地这是硬伤——没有明确的授权条款，商用风险无法评估。

第二，AI 味很重的文档体系。 docs/companion/ 目录下堆了 16 份 HANDOFF 文档，光是 HANDOFF-C-QUOTA-PANEL.md 就有 51KB。docs/companion/HANDOFF-A-DUAL-PET.md 27KB、HANDOFF-INTEGRATION-QUOTA.md 26KB。这种规模的多 Agent 交接文档说明项目在高度依赖 AI 并行开发，但也意味着代码可读性依赖那些交接记录，普通贡献者的上手成本偏高。

第三，边缘状态的处理不够干净。 麦麦套装的右向状态直接用了穿装待机的镜像；一些缺少独立素材的状态复用了其他动作。README 里坦承了这一点，但对于期待"所见即所得"的用户会有落差。

第四，大量功能仍是"待验收"而非"已完成"。 订单创建与付款、完整厂商实时额度、512 尺寸 GIF 在宿主中的播放、周报营养汇总——都还没交付。这是典型的 v0.1.0 早期项目形态。

第五，与商业 API 的耦合风险。 依赖麦当劳、瑞幸的内部接口，一旦对方改接口或加强风控，相应功能就会失效。这类"把第三方 App 塞进 MCP"的想法有趣，但商业上脆弱。

行业意义：一个正在成型的细分方向

McPet 代表的其实是一类正在聚合的方向：Agent 可观测性的"去仪表盘化"。

现有的 Agent 监控方案（LangSmith、Helicone、各类 CLI 仪表盘）都在做同一个假设——你是一个会主动打开页面查看数据的工程师。而 LLMPET、OpenPet、MYpet、MaiM 这一批同期的桌宠项目，都在尝试另一条路：把状态做成陪伴。

这个方向的共同驱动力是 Agent 数量的爆发。当一个人同时跑 3~5 个 Agent 时，"看不过来"就从效率问题变成了体验问题。谁能解决"用最低注意力成本知道 Agent 正在干什么"，谁就能占据这个入口位。

McPet 在这个赛道上的差异化很清晰：它是唯一把桌宠形态和 MCP Server 形态做成了同一套代码的双形态产品。别人的桌宠基本只能被 Agent 单向读取状态，而 McPet 的桌宠反过来能接受 Agent 的指令去换装、去下单——这让桌宠从"显示器"变成了"双向接口"。这个设计上的野心，是它 312★ 和 1.4 万行代码的来源。

---

分析时间：2026-10-29 ｜ 数据来源：GitHub API（仓库快照）、项目 README / STATUS.md / AGENTS.md / CONTRIBUTING.md、公开检索