Phantom：把整台机器交给 AI 同事之后，你要付什么代价
An AI co-worker with its own computer. Self-evolving, persistent memory, MCP server, secure credential collection, email identity. Built on the Claude Agent SDK.
秒懂
- 它是什么？
- Phantom 是 ghostwright 用 TypeScript 写的自托管 AI 同事，跑在 Docker 里，带持久记忆、MCP 工具和自进化管线。本文只依据仓库与文档能确认的内容，说明它的机制、启动方式、以及 Docker socket 挂载和自进化带来的真实边界。
- 适合谁用？
- Phantom 适合已经在用 Slack 协作、且愿意为它单独准备一台机器或 VM 的团队，因为它的记忆、渠道和自建工具都沉淀在那台机器上，换机器等于重来。不适合把生产 Docker 主机当试验场的人：README 明确写了 compose 文件挂载 /var/run/docker.sock，容器因此拥有对 Docker daemon 的 root 级等价权限，被攻破的 Phantom 进程可以创建、修改或删除宿主机上的任意容器。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 91 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是会话结束即失忆这件事
README 开篇把问题定义得很直白：现在的 AI agent 是一次性的，开一个对话，拿到答案，关掉标签页，上下文就没了，下次从零开始，每一次会话都是第一天。Phantom 的应对方式是给 AI 分配一台自己的计算机，让它在那台机器上装软件、起数据库、做看板，并且记住你上周说过什么。
目标用户不是想在自己笔记本上跑个聊天窗口的人。README 里有一句判断值得注意：你的笔记本还是你的，agent 的工作区是它自己的。这句话决定了它的使用姿势，你需要一台可以牺牲的机器。它的入口也不是命令行，而是 Slack、一个挂在 /chat 的网页界面，以及它自己的邮箱地址。换句话说，它假定你已经有一个团队在 Slack 里工作，而不是假定你一个人对着终端。
Sdk 之上叠了记忆、渠道和自进化三层
从仓库材料能确认的架构是分层的。最底层是 Claude Agent SDK，负责模型调用与工具循环。往上第一层是持久记忆，Docker 启动时 Qdrant 一并起来，同时 Ollama 会拉取 embedding 模型，说明记忆走的是向量检索而不是简单的对话历史拼接。第二层是渠道，README 列出 Slack、Telegram、Email、Webhook 四种内置渠道。第三层是自进化管线，README 提到 evolution judge 会随 provider 一起切换，说明存在一个对 agent 行为或产物做评估的独立环节。
工具侧走 MCP。README 里那个 ClickHouse 的案例值得拆开看：agent 先在自己的 VM 上装 ClickHouse，导入 Hacker News 数据集，再建了一个 REST API，最后把这个 API 注册成 MCP tool。这个顺序说明 MCP 在 Phantom 里不只是消费外部工具，也是它把自建能力固化下来给未来会话和其他 agent 复用的机制。这一点比它自称自进化更有工程意义：能力被注册成工具之后，就脱离了单次会话的上下文。
启动只需要三条命令，但 .env 是关键
README 给出的 Docker 路径是三条命令加一次编辑。先拉取 compose 和 env 模板：
curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/docker-compose.user.yaml -o docker-compose.yaml curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/.env.example -o .env
然后编辑 .env，README 点名要填的是 ANTHROPIC_API_KEY、Slack tokens 和 OWNER_SLACK_USER_ID，最后 docker compose up -d。健康检查在 http://localhost:3100/health。如果配好了 Slack，它准备就绪时会主动给你发私信。想让它发邮件就再加 RESEND_API_KEY。
模型切换集中在 phantom.yaml，README 给的例子是 model 字段加一个 provider 块，块里写 type、api_key_env 和 model_mappings，比如把 sonnet 映射到 glm-5.1，密钥通过 ZAI_API_KEY 从环境变量读。README 说得很清楚：切换之后主 agent 和每一个 evolution judge 都走新 provider，工具、记忆、自进化管线都不变。要留意 model_mappings 这一层间接映射，如果你把 sonnet 映射到了一个能力差距较大的模型，出问题的不会只是聊天质量，评审环节的判断也会跟着变。
Docker socket 挂载是一个写在明面上的取舍
README 自带一段安全说明，这在同类项目里不常见，值得原样对待。compose 文件把 /var/run/docker.sock 挂进 Phantom 容器，目的是让它能启动兄弟容器，比如做沙箱化的代码执行。README 自己承认这是有意的架构取舍：这个 socket 等于给了容器对 Docker daemon 的 root 级等价权限，一个被攻破的 Phantom 进程可以创建、修改或销毁宿主机上的任何容器。文档给出的缓解办法是把它跑在专用机器或 VM 上，不要放在个人工作站。
这段说明的诚实程度应该被肯定，但它同时划定了适用边界。只要 socket 在，容器隔离对 Phantom 而言基本不存在，agent 能做的事和宿主机管理员能做的事高度重叠。再叠加它默认在 Slack 上接收指令、并且会自己装软件起服务这两点，攻击面就不只是模型输出，还包括谁能给这个 Slack 机器人发消息。README 没有在给出的片段里展开渠道侧的权限控制，这部分需要你自己去 docs 里确认。
自进化的证据是案例，不是可复现的指标
README 用三个生产实例支撑自进化的说法：装 ClickHouse 处理 2870 万行 Hacker News 数据并做成看板与 API；在用户询问后自己实现 Discord 渠道，而 Discord 并不在它内置的四种渠道里；发现一个只有 3 个 star 的开源监控项目 Vigil，接进自己的 ClickHouse，做 30 秒一批的同步管线和实时看板。
这些案例有说服力，但它们是叙述，不是基准。README 没有给出任务成功率、自进化前后的对比数据，也没有说明这些案例重复出现过多少次。仓库里 1819 个测试通过是徽章上的数字，能说明测试规模，说明不了 agent 在开放环境里的可靠性。真正决定你能不能用的，是它在你的任务上表现如何，而那需要你自己跑。另外，Discord 那个案例里 agent 说的是「现在不行，但可以建」，这种先承认边界再动手的行为模式，比它建成了什么更值得观察。
和只做编排的框架相比，差别在状态放在哪
把 Phantom 和 LangGraph、CrewAI 这类编排框架放在一起看，差别不在模型能力，而在状态归属。编排框架通常把 agent 当成你应用里的一个函数：状态存在你的数据库或进程内存里，工具由你的代码注册，生命周期跟着你的服务走。Phantom 反过来，它是一个长期驻留的服务，记忆存在它自己的 Qdrant 里，工具由它自己在运行中注册，渠道是它自己持有的身份。
这个差别决定了迁移成本。用编排框架，换实现是重写代码；用 Phantom，换机器等于把它积累的记忆和自建工具一起搬走，而 README 没有描述导出或迁移记忆的路径。反过来说，如果你的需求是一次性的批处理任务，或者需要把 agent 嵌进已有的后端逻辑里，Phantom 这种常驻形态反而是负担，你会为了一个函数调用去维护一整套容器、向量库和消息渠道。
多 provider 是成本控制手段，也是维护负担
README 列出七种后端：Anthropic 默认，Z.AI、OpenRouter、Ollama、vLLM、LiteLLM，以及任何兼容 Anthropic Messages API 的自定义端点。文档称 Z.AI 的 GLM-5.1 在编码质量接近的情况下比 Claude Opus 便宜约 15 倍，这是仓库自己的说法，本文无法验证。Ollama 和 vLLM 这两条路意味着 API 成本可以降到零，代价是你得有 GPU。
维护成本要分两块看。一块是 provider 抽象本身，Anthropic 保持默认，已有部署不需要改配置，这一点降低了升级摩擦。另一块是自进化管线，它和主 agent 共用 provider，所以你换模型时实际影响的是两套逻辑。项目版本号是 0.20.2，还在 0.x 阶段，最后提交时间在 2026 年 6 月，说明迭代仍在进行，升级时值得先读 release notes 再动。许可证是 Apache-2.0，允许商用和修改，具体义务以 LICENSE 原文为准，这里不构成法律意见。
先确认这三件事再决定要不要上
第一件是机器归属。README 反复强调专用机器或 VM，这不是建议而是前提，因为 docker.sock 挂载把容器安全和宿主机安全绑在了一起。如果你只有一台跑着其他服务的生产主机，Phantom 不该放上去。
第二件是渠道权限。它默认在 Slack 上接指令，谁能给这个机器人发消息，谁就间接获得了操作那台机器的能力。README 给出的片段里没有展开这层控制，需要去 docs 确认。第三件是模型映射。phantom.yaml 里的 model_mappings 决定了主 agent 和 evolution judge 实际调用哪个模型，映射错了不会报错，只会让行为悄悄偏离预期。
如果这三件都能落实，Phantom 值得一试，它的 MCP 工具注册机制让 agent 的自建能力可以跨会话沉淀，这是它和一次性 agent 最实质的区别。如果只能把它塞进现有工作站，那 Docker socket 这一条就足够让你先停下来。
编辑结论
Phantom 适合已经在用 Slack 协作、且愿意为它单独准备一台机器或 VM 的团队，因为它的记忆、渠道和自建工具都沉淀在那台机器上，换机器等于重来。不适合把生产 Docker 主机当试验场的人：README 明确写了 compose 文件挂载 /var/run/docker.sock，容器因此拥有对 Docker daemon 的 root 级等价权限，被攻破的 Phantom 进程可以创建、修改或删除宿主机上的任意容器。上手前先确认三件事：目标机器是否专用、.env 里的 OWNER_SLACK_USER_ID 和 Slack token 是否配好、以及你选定的 provider 是否被 phantom.yaml 的 model_mappings 正确映射，因为主 agent 和自进化评审都会走同一个 provider。
社区笔记