nanobot
自托管个人助手，把多渠道对话、工具与自动化接入轻量 Python 运行时。
按维度查看评分与理由
证据显示：SECURITY.md 详细说明了 API 密钥管理、通道访问控制（allowFrom）、shell 执行沙箱（bwrap）、文件系统限制等安全实践，并明确要求用户配置 allowFrom 和启用沙箱，体现了最小权限原则。用户确认方面，README 提到首次运行 WebUI 时需确认启用本地 WebSocket 通道，但未广泛覆盖所有敏感操作。数据流透明度方面，WebUI 可查看推理、工具调用、文件编辑等，但未提供完整的数据流图。敏感数据处理方面，SECURITY.md 建议使用环境变量引用密钥，并限制配置文件权限，但未强制。依赖安全方面，SECURITY.md 建议使用 pip-audit 并保持依赖更新，但未提供自动化扫描。外部影响方面，工具如 exec 可执行 shell 命令，但提供了沙箱和危险模式检测。回滚方面，未明确提供配置或操作的回滚机制。来源归属方面，README 和 LICENSE 明确列出了作者和贡献者，但发布者未经验证。扣分原因：用户确认机制不全面，依赖安全缺乏自动化，回滚机制缺失。
证据显示：README 和文档结构一致，pyproject.toml 中的依赖版本范围明确，CI 工作流覆盖多平台和 Python 版本，测试文件存在。依赖可用性方面，依赖列表完整，但未提供锁文件（uv.lock 未在源文件中看到）。失败消息方面，SECURITY.md 和文档提供了故障排除指南，但未提供具体的错误消息示例。扣分原因：依赖锁定不明确，失败消息示例不足。
证据显示：README 提供了多种安装方式（一键脚本、uv、pip、源码），并针对不同用户（无技术背景、开发者）提供了指南。能力边界方面，文档列出了支持的工具和通道，但未明确限制。触发精度方面，自动化功能（cron）有文档，但未详细说明触发条件。环境适配方面，支持多种操作系统和部署方式（Docker、Render），但未提供所有环境的详细配置。扣分原因：能力边界和触发精度描述不够详细。
证据显示：README 提供了清晰的信息架构，文档目录完整。安装说明详细，包括多种方法和故障排除。命名稳定性方面，项目名称和 CLI 命令一致。示例和 FAQ 方面，提供了快速入门和文档链接，但未提供 FAQ 页面。已知限制方面，SECURITY.md 列出了安全限制，但未列出功能限制。许可证为 MIT，版本和变更日志在 README 中提及。维护责任方面，README 列出了联系人和贡献者，但未明确维护政策。扣分原因：缺少 FAQ 和功能限制说明，维护责任不明确。
证据显示：输出可用性方面，WebUI 和 CLI 提供了清晰的输出，但未提供输出格式的详细说明。边际价值方面，项目提供了多种集成和自动化功能，但未与其他类似工具对比。成本效益方面，项目是开源的，但未提供性能或资源消耗数据。扣分原因：缺乏对比和性能数据。
证据显示：README 中的声明（如功能列表）与文档和代码一致，但未提供具体的验证方法。跨来源佐证方面，文档和代码相互印证，但未提供外部验证。事实与推断分离方面，README 明确区分了功能描述和安装步骤，但未明确标注推断。扣分原因：缺乏外部验证和明确的推断标注。
- 发布者身份未经验证，需谨慎对待供应链风险。
- 依赖安全仅建议手动扫描，未提供自动化机制。
- 用户确认机制不全面，敏感操作可能未充分提示。
- 回滚机制缺失，配置或操作错误可能难以恢复。
这个 Agent 能做什么，适合哪些场景？
nanobot 是一个用 Python 编写、可自托管的个人 AI Agent 运行时。它通过 WebUI、终端和聊天应用接收任务，并以小型 Agent loop 驱动模型调用与工具执行。运行时支持会话历史、名为 Dream 的长期记忆、MCP 集成、模型路由、子代理委派与定时自动化。它可使用文件、Shell、网页搜索、网页抓取、图像生成和 cron 等工具，并提供 Python SDK 与 OpenAI 兼容 API。部署边界覆盖本机或服务器上的长期运行网关，以及 Docker、Docker Compose、Linux 服务、macOS LaunchAgent 和 Render Blueprint。
用户可通过 nanobot webui 启动本地浏览器工作台，或通过 nanobot agent 进入终端会话；nanobot agent -m "Hello!" 会完成一次请求后退出。完整网关由 nanobot gateway 运行，可持续承载聊天频道和自动化任务。消息从 WebUI、终端或已连接的 Telegram、Discord、Slack、WeChat、Email、Mattermost 等聊天应用进入；模型决定是否调用文件、Shell、web search、web fetch、MCP、cron、image generation 或 subagents。运行时保存会话历史并通过 Dream 使用长期记忆，WebUI 可展示推理、工具调用、文件修改、diff、命令输出与生成的产物。它还向其他集成暴露 Python SDK 和 OpenAI-compatible API。
- 需要把个人助手长期运行在自己电脑或服务器上的个人用户，可用 WebUI 管理不同主题、工作区和模型。
- 已在 Telegram、Discord、Slack、WeChat、Email 或 Mattermost 中协作的团队，可把聊天消息接入同一个 Agent 网关。
- 需要从终端脚本触发一次模型请求的开发者，可使用
nanobot agent -m进行单次调用。 - 希望让助手按计划执行工作的用户，可配置 cron 和 scheduled automations，并以后台网关持续运行。
- 需要把本地工具、MCP 服务或 OpenAI 兼容接口接入现有自动化的集成开发者，可使用其工具运行时、Python SDK 与 API。
这个 Agent 有哪些优点和局限？
- 将 WebUI、终端、聊天频道和长期运行网关放在同一套轻量 Python 核心中。
- 内置 Dream 长期记忆、MCP、模型路由、子代理、cron 和定时自动化，而非仅提供一次性聊天。
- 同时提供 Python SDK 和 OpenAI-compatible API，便于接入本地工具与外部自动化。
- 发布包已包含 WebUI，无需单独构建前端。
- 必须配置模型提供商、凭据和模型后才能获得正常回复；这些配置并非开箱即用。
- 源码安装额外需要 Git 及 bun 或 npm，Windows 可能需要手动构建 WebUI。
- 聊天频道、自动化和后台服务依赖持续运行的 gateway，运维复杂度高于
nanobot agent的单次终端调用。 - Render 持久磁盘需要付费服务；README 未说明各模型提供商、搜索或图像生成服务的具体费用。
如何安装或部署这个 Agent？
运行环境需要 Python 3.11 或更高版本。可安装发布包：uv tool install nanobot-ai，或 python -m pip install nanobot-ai；随后用 nanobot --version 验证。首次启动执行 nanobot webui，在浏览器的 Settings → Models 中选择提供商、填写凭据并选择模型；这一步需要相应模型提供商的 credential。源码安装需要 Git 以及 bun 或 npm：克隆仓库后在已激活的虚拟环境中运行 python -m pip install .。
如何使用这个 Agent？
首次运行 nanobot webui，它会在需要时创建配置和工作区，并打开 http://127.0.0.1:8765；默认绑定 localhost。完成 Settings → Models 配置后，新建主题并发送 Hello! 验证模型、工作区和网关。需要持续运行时使用 nanobot webui --background，并用 nanobot gateway status、nanobot gateway logs、nanobot gateway restart 或 nanobot gateway stop 管理；不需要浏览器启动流程时可直接运行 nanobot gateway。
这个 Agent 与同类方案有什么区别？
README 将 nanobot gateway 描述为熟悉 OpenClaw 或已把 Agent 作为长期服务运行的用户可采用的网关优先入口；文中没有给出功能逐项对比。
常见问题
能否完全在本地使用？
127.0.0.1，不会暴露到局域网。仍需为所选模型提供商配置凭据。是否必须使用浏览器？
nanobot agent 提供交互式终端聊天，nanobot agent -m "Hello!" 可执行单次请求；nanobot gateway 可直接运行完整网关。它会访问哪些本地资源？
可以长期运行并连接聊天应用吗？
nanobot gateway 或 nanobot webui --background 可让频道和自动化在启动器退出后继续运行；支持的频道包括 Telegram、Discord、Slack、WeChat、Email 和 Mattermost。部署到 Render 需要什么？
ANTHROPIC_API_KEY 和私有 NANOBOT_WEB_TOKEN，并为会话、记忆和 WebUI 历史配置持久存储；持久磁盘需要付费 Render 服务。