nanobot 架构解析从 AgentLoop 到 Provider、Channel、Tools 的源码级运行地图【免费下载链接】nanobotUltra-lightweight, open-source, self-hosted personal AI agent framework in Python with WebUI, tools, memory, MCP, multi-agent workflows, automation, and chat apps项目地址: https://gitcode.com/gh_mirrors/nanob/nanobotnanobot 是一个超轻量级的自托管个人 AI Agent 框架其架构文档的核心价值在于把运行时行为精确映射到源码文件。读完本文你将掌握 nanobot 的完整消息流转链路Channel → MessageBus → AgentLoop → AgentRunner → Provider → Tools理解 AgentLoop 与 AgentRunner 的职责分界、Provider 注册与自动推断机制、Channel/Tool/MCP 等扩展点的接入方式以及配置与路径体系的默认值约定——这些内容能帮助你快速定位任意一个用户可见行为背后的源码位置。核心消息流从 InboundMessage 到 OutboundMessagenanobot 的运行时可以概括为一条闭环消息流官方文档给出了核心文件对照表这张表是调试内部的起点区域文件消息事件与队列nanobot/bus/events.py、nanobot/bus/queue.py回合turn编排nanobot/agent/loop.pyProvider/工具对话循环nanobot/agent/runner.py上下文构建nanobot/agent/context.py会话存储与压缩nanobot/session/manager.py长期记忆与 Dreamnanobot/agent/memory.py从源码看消息总线由两个数据类和一个队列组件构成。在 nanobot/bus/events.py 中InboundMessage携带channel、sender_id、chat_id、content、timestamp、media、metadata等字段并提供session_key属性——默认为f{channel}:{chat_id}也支持session_key_override做线程级会话覆盖OutboundMessage携带回复内容、reply_to、media、buttons以及用于内部运行时/UI 语义的event字段源码中还定义了内部保留的 metadata 键如INBOUND_META_RUNTIME_CONTROL注释明确这些键只能由受信传输层铸造不能来自不受信客户端——这是消息边界安全的一个细节体现。MessageBusnanobot/bus/queue.py负责入站/出站队列的流转。无论消息来自 CLI、WebUI、Telegram 还是 Discord进入 AgentLoop 之后的流程完全一致。AgentLoop 与 AgentRunner 的职责分界这是整个架构中最关键的设计决策一个偏渠道侧的编排层一个偏模型侧的执行层。AgentLoopnanobot/agent/loop.py 中的class AgentLoop拥有面向渠道的回合接收入站消息确定生效的 session 与 workspace 作用域构建上下文历史、记忆、技能、渠道元数据接入 hooks、进度事件与渠道元数据发布出站消息。AgentRunnernanobot/agent/runner.py 中的class AgentRunner拥有面向模型的循环向选定的 provider 发送消息处理流式 delta 与推理reasoning块执行工具调用把工具结果回喂给模型在产出最终答案或触及运行时限制迭代上限等时停止。AgentRunner的类注释也印证了这一定位Run a tool-capable LLM loop without product-layer concerns.运行一个无产品层关切的可调用工具的 LLM 循环。从源码看AgentRunner的执行结果封装在共享结果对象中包含final_content、messages、tools_used、逐轮round_usages、stop_reason、provider 会话状态检查点等字段支撑恢复recovery与继续注入injection等机制。MCP 连接属于应用层基础设施架构文档特别强调MCP 连接是应用拥有的application-owned基础设施而非 AgentLoop 的一部分。组合根composition root负责创建MCPProvider、把它的ToolRegistry共享给AgentLoop、在使用前await connect()、并在关停时保证aclose()AgentLoop 不管理这个生命周期。因此AgentLoop.from_config()要求调用方提供自己拥有的ToolRegistry——使用 MCP 的调用方需将其与自有的MCPProvider共享。相关实现可见 nanobot/agent/tools/mcp.py 中的MCPProvider与 nanobot/agent/tools/registry.py 中的ToolRegistry。调试时的分工口诀如果问题涉及渠道路由、session 键、workspace 选择或出站投递从 nanobot/agent/loop.py 入手如果涉及 provider 调用、工具调用、流式输出或迭代限制从 nanobot/agent/runner.py 入手。Providers集中注册表驱动的模型后端Provider 元数据集中在 nanobot/providers/registry.py配置字段在 nanobot/config/schema.py。该注册表文件头部注释写得很直白——新增 provider 只需两步在PROVIDERS中添加一个ProviderSpec在config/schema.py的ProvidersConfig中添加对应字段。环境变量、配置匹配、状态展示都由此派生。从源码看ProviderSpec是一个 frozen dataclass关键字段包括name/keywords/env_key配置字段名、模型名匹配关键词、API key 环境变量名backend决定使用哪个 provider 实现openai_compat、anthropic、azure_openai、openai_codex、bedrock等is_gateway/is_local/detect_by_key_prefix/detect_by_base_keyword网关型可路由任意模型、本地部署、API key 前缀与 base URL 推断的标记thinking_style、reasoning_effort_remap、supports_prompt_caching等处理各厂商推理开关、提示缓存等协议差异is_oauth/is_directOAuth 型如 OpenAI Codex与直连型 provider 的区分。Provider 选择遵循以下优先级与文档一致显式的agents.defaults.provider或 preset 中的 providerprovider 注册表关键词模型名匹配API key 前缀与 API base URL 提示配置了apiBase时的本地 provider 回退网关型 provider 回退可路由多模型家族。Provider 实现位于nanobot/providers/大多数托管 provider 复用 OpenAI 兼容实现而 Anthropic、Azure OpenAI、AWS Bedrock、OpenAI Codex 与 GitHub Copilot 走专门实现路径对应 anthropic_provider.py、azure_openai_provider.py、bedrock_provider.py、openai_codex_provider.py、github_copilot_provider.py。实操配置可参考 providers.md 与 configuration.md#providers。Channels自包含包式发现Channel 负责把外部平台翻译成InboundMessage事件并把OutboundMessage发回平台。核心文件区域文件基础 Channel 契约nanobot/channels/base.py各 Channel 包nanobot/channels/channel/发现与生命周期nanobot/channels/manager.pyWebSocket/WebUI 通道nanobot/channels/websocket/从源码结构看Channel 采用插件化发现机制ChannelManager通过nanobot.channels.registry.discover_plugins()扫描nanobot/channels/下的自包含包每个包导出一个ChannelPlugin描述符定义于 nanobot/channels/plugin.py并把运行时与可选的 setup 表面封装在同一个包内。新增 channel 只需贡献一个遵循 channel-package-guide.md 规范的包无需改动核心代码。WebUI 与 Gateway长驻进程的组成nanobot gateway启动的内容包括已启用的聊天 channel配置了 WebSocket 时的 WebSocket channelworkspace 作用域的 cron 服务Dream、heartbeat 等系统作业gateway.port上的健康检查端点。一个容易混淆的点打包的 WebUI 由 WebSocket channel 提供而不是健康检查端点。两者的默认地址表面默认地址Health endpointhttp://127.0.0.1:18790/healthWebUI/WebSockethttp://127.0.0.1:8765源码印证nanobot/config/schema.py 中 gateway 配置的port字段默认值即为18790。WebUI 前端源码位于 webui/生产构建输出到nanobot/web/dist/并打入 wheel。相关文档webui.md使用指南、webui/README.md前端源码开发、websocket.md协议细节。Tools模型契约的一部分工具从 nanobot/agent/tools/ 与插件入口点发现。重要文件对照工具区域文件工具基类与 schemananobot/agent/tools/base.py、nanobot/agent/tools/schema.py工具发现nanobot/agent/tools/registry.pyShell 执行nanobot/agent/tools/shell.py文件系统工具nanobot/agent/tools/filesystem.pyWeb 搜索/抓取nanobot/agent/tools/web.pyMCP 工具nanobot/agent/tools/mcp.pyCronnanobot/agent/tools/cron.py、nanobot/cron/图片生成nanobot/agent/tools/image_generation.py运行时自省nanobot/agent/tools/self.py当前仓库的工具目录实际还包含apply_patch.py、exec_session.py、long_task.py、search.py、spawn.py子代理、sandbox.py、message.py等模块可见工具面比文档表格更宽。架构文档特别警告工具行为是模型契约的一部分——除非有意变更应保持用户可见的工具名、schema 与错误消息稳定。配置与路径默认值与作用域边界配置 schema 在 nanobot/config/schema.py加载与保存在 nanobot/config/loader.py运行时路径助手在 nanobot/config/paths.py。默认路径路径默认值Config~/.nanobot/config.jsonWorkspace~/.nanobot/workspace/Sessionsconfig-dir/sessions/workspace-id/*.jsonl默认~/.nanobot/sessions/...Memoryworkspace/memory/Cron 存储workspace/cron/jobs.jsonWebUI/media/日志运行时数据配置目录下的子目录如webui/、media/、logs/源码印证nanobot/config/paths.py 中get_workspace_path()在未指定时解析到~/.nanobot/workspaceget_runtime_subdir()负责media/、cron/、logs/、webui/等实例级运行时子目录。schema 同时接受 camelCase 与 snake_case 键但回写磁盘时统一使用 camelCase 别名如apiKey、modelPresets、intervalS。Agent 自有状态 vs 生效项目上下文运行时区分了配置的 agent workspace与会话作用域携带的生效项目 workspace。两者常常是同一目录但 WebUI 聊天可以选择独立项目关切路径所有者会话命名空间、SOUL.md、USER.md、memory、自定义 skills配置的 agent workspace项目AGENTS.md、相对工具路径、shell 工作目录生效的项目 workspaceworkspace 访问模式与项目元数据会话的 workspace 作用域ContextBuildernanobot/agent/context.py把项目指令与 agent 自有的 profile、记忆合并文件系统与搜索工具以项目为常规边界仅对内置/agent 技能与精确的 agent 历史文件获得能力特定的只读访问。架构文档提醒保持这些跨根cross-root能力只读且显式不要将整个 agent workspace 当作允许的根目录。Memory 与 Sessions两级状态存储会话历史是近端的对话回放memory 是远端的 workspace 状态存储文件区域会话 JSONL 文件config-dir/sessions/workspace-id/长期记忆workspace/memory/MEMORY.md整合来源历史workspace/memory/history.jsonl引导身份文件workspace/SOUL.md、workspace/USER.md模板见 nanobot/templates/Dream记忆整合/梳理机制实现在 nanobot/agent/memory.py由运行时在启用时调度。会话的存储与压缩逻辑在 nanobot/session/manager.py。安全边界与安全相关的代码路径架构文档列出了安全敏感路径供修改工具/渠道/文件访问/网络抓取时对照边界文件Workspace 作用域nanobot/security/workspace_access.py、nanobot/security/workspace_policy.pyShell 沙箱nanobot/agent/tools/shell.pySSRF/网络检查nanobot/security/network.py、nanobot/agent/tools/web.pyPTH 防护与 CLI 启动安全nanobot/security/ 与 CLI 入口渠道访问控制各nanobot/channels/*.py中的渠道配置文档同时要求当变更涉及工具、channel、文件访问、WebUI workspace 行为或网络抓取时把安全当作功能行为的一部分并在用户可见边界变化时同步更新文档。扩展点接入新能力的官方路径架构文档以表格形式给出七类扩展的标准做法扩展方式Provider在 providers/registry.py 添加ProviderSpec在 config/schema.py 添加 schema 字段仅在通用后端不够时才实现新 providerChannel导出ChannelPlugin描述符运行时与 setup 表面放在一个包内遵循 channel-package-guide.mdTool在agent/tools/下实现工具或暴露插件入口点Agent Plugin在workspace/plugins/下添加 v1 包并从 Apps 启用MCP添加tools.mcpServers配置或在 Agent Plugin 中捆绑 serverSkill添加workspace/skills/下的 workspace 技能、在 Agent Plugin 中捆绑或在 nanobot/skills/ 添加内置技能CLI App加入 CLI Apps 目录安装器负责可执行文件生命周期并写出一个 skills-only 的 Agent Plugin总原则是优先复用已有的注册/发现模式避免临时接线ad hoc wiring。测试与验证按变更面选择最小验证常用检查命令pytest tests/test_openai_api.py::test_function -v ruff check nanobot/ cd webui bun run test cd webui bun run build按变更面选择最小验证变更最小有效验证Provider 行为Provider 单元测试或 mock API 路径条件允许时用安全配置跑nanobot agent -m Hello!Channel 行为Channel 测试 nanobot gateway启动路径WebUI 行为WebUI 测试/构建路由/设置/聊天变更需通过 gateway 做浏览器级验证工具行为工具单元测试schema 或面向模型行为变化时补充 agent 运行路径文档链接检查、命令与 CLI/schema 的一致性核对、git diff --check对面向用户的流程架构文档建议至少走一条用户实际接触的公共表面CLI 命令、HTTP 端点、WebSocket/WebUI、聊天渠道或打包导入。小结nanobot 的架构可以浓缩为三句话一条Channel → MessageBus → AgentLoop → AgentRunner → Provider/Tools → 回写的消息闭环一组按元数据集中在注册表 自包含包发现组织的扩展点Provider、Channel、Tool、Skill、Plugin、MCP以及一套围绕~/.nanobot/配置目录与 workspace 的清晰路径边界。这份源码映射文档配合 concepts.md 的产品级心智模型、configuration.md 的参数参考构成了理解、调试乃至扩展 nanobot 的完整入口。【免费下载链接】nanobotUltra-lightweight, open-source, self-hosted personal AI agent framework in Python with WebUI, tools, memory, MCP, multi-agent workflows, automation, and chat apps项目地址: https://gitcode.com/gh_mirrors/nanob/nanobot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 nanobot 架构解析：从 AgentLoop 到 Provider、Channel、Tools 的源码级运行地图
nanobot 架构解析从 AgentLoop 到 Provider、Channel、Tools 的源码级运行地图【免费下载链接】nanobotUltra-lightweight, open-source, self-hosted personal AI agent framework in Python with WebUI, tools, memory, MCP, multi-agent workflows, automation, and chat apps项目地址: https://gitcode.com/gh_mirrors/nanob/nanobotnanobot 是一个超轻量级的自托管个人 AI Agent 框架其架构文档的核心价值在于把运行时行为精确映射到源码文件。读完本文你将掌握 nanobot 的完整消息流转链路Channel → MessageBus → AgentLoop → AgentRunner → Provider → Tools理解 AgentLoop 与 AgentRunner 的职责分界、Provider 注册与自动推断机制、Channel/Tool/MCP 等扩展点的接入方式以及配置与路径体系的默认值约定——这些内容能帮助你快速定位任意一个用户可见行为背后的源码位置。核心消息流从 InboundMessage 到 OutboundMessagenanobot 的运行时可以概括为一条闭环消息流官方文档给出了核心文件对照表这张表是调试内部的起点区域文件消息事件与队列nanobot/bus/events.py、nanobot/bus/queue.py回合turn编排nanobot/agent/loop.pyProvider/工具对话循环nanobot/agent/runner.py上下文构建nanobot/agent/context.py会话存储与压缩nanobot/session/manager.py长期记忆与 Dreamnanobot/agent/memory.py从源码看消息总线由两个数据类和一个队列组件构成。在 nanobot/bus/events.py 中InboundMessage携带channel、sender_id、chat_id、content、timestamp、media、metadata等字段并提供session_key属性——默认为f{channel}:{chat_id}也支持session_key_override做线程级会话覆盖OutboundMessage携带回复内容、reply_to、media、buttons以及用于内部运行时/UI 语义的event字段源码中还定义了内部保留的 metadata 键如INBOUND_META_RUNTIME_CONTROL注释明确这些键只能由受信传输层铸造不能来自不受信客户端——这是消息边界安全的一个细节体现。MessageBusnanobot/bus/queue.py负责入站/出站队列的流转。无论消息来自 CLI、WebUI、Telegram 还是 Discord进入 AgentLoop 之后的流程完全一致。AgentLoop 与 AgentRunner 的职责分界这是整个架构中最关键的设计决策一个偏渠道侧的编排层一个偏模型侧的执行层。AgentLoopnanobot/agent/loop.py 中的class AgentLoop拥有面向渠道的回合接收入站消息确定生效的 session 与 workspace 作用域构建上下文历史、记忆、技能、渠道元数据接入 hooks、进度事件与渠道元数据发布出站消息。AgentRunnernanobot/agent/runner.py 中的class AgentRunner拥有面向模型的循环向选定的 provider 发送消息处理流式 delta 与推理reasoning块执行工具调用把工具结果回喂给模型在产出最终答案或触及运行时限制迭代上限等时停止。AgentRunner的类注释也印证了这一定位Run a tool-capable LLM loop without product-layer concerns.运行一个无产品层关切的可调用工具的 LLM 循环。从源码看AgentRunner的执行结果封装在共享结果对象中包含final_content、messages、tools_used、逐轮round_usages、stop_reason、provider 会话状态检查点等字段支撑恢复recovery与继续注入injection等机制。MCP 连接属于应用层基础设施架构文档特别强调MCP 连接是应用拥有的application-owned基础设施而非 AgentLoop 的一部分。组合根composition root负责创建MCPProvider、把它的ToolRegistry共享给AgentLoop、在使用前await connect()、并在关停时保证aclose()AgentLoop 不管理这个生命周期。因此AgentLoop.from_config()要求调用方提供自己拥有的ToolRegistry——使用 MCP 的调用方需将其与自有的MCPProvider共享。相关实现可见 nanobot/agent/tools/mcp.py 中的MCPProvider与 nanobot/agent/tools/registry.py 中的ToolRegistry。调试时的分工口诀如果问题涉及渠道路由、session 键、workspace 选择或出站投递从 nanobot/agent/loop.py 入手如果涉及 provider 调用、工具调用、流式输出或迭代限制从 nanobot/agent/runner.py 入手。Providers集中注册表驱动的模型后端Provider 元数据集中在 nanobot/providers/registry.py配置字段在 nanobot/config/schema.py。该注册表文件头部注释写得很直白——新增 provider 只需两步在PROVIDERS中添加一个ProviderSpec在config/schema.py的ProvidersConfig中添加对应字段。环境变量、配置匹配、状态展示都由此派生。从源码看ProviderSpec是一个 frozen dataclass关键字段包括name/keywords/env_key配置字段名、模型名匹配关键词、API key 环境变量名backend决定使用哪个 provider 实现openai_compat、anthropic、azure_openai、openai_codex、bedrock等is_gateway/is_local/detect_by_key_prefix/detect_by_base_keyword网关型可路由任意模型、本地部署、API key 前缀与 base URL 推断的标记thinking_style、reasoning_effort_remap、supports_prompt_caching等处理各厂商推理开关、提示缓存等协议差异is_oauth/is_directOAuth 型如 OpenAI Codex与直连型 provider 的区分。Provider 选择遵循以下优先级与文档一致显式的agents.defaults.provider或 preset 中的 providerprovider 注册表关键词模型名匹配API key 前缀与 API base URL 提示配置了apiBase时的本地 provider 回退网关型 provider 回退可路由多模型家族。Provider 实现位于nanobot/providers/大多数托管 provider 复用 OpenAI 兼容实现而 Anthropic、Azure OpenAI、AWS Bedrock、OpenAI Codex 与 GitHub Copilot 走专门实现路径对应 anthropic_provider.py、azure_openai_provider.py、bedrock_provider.py、openai_codex_provider.py、github_copilot_provider.py。实操配置可参考 providers.md 与 configuration.md#providers。Channels自包含包式发现Channel 负责把外部平台翻译成InboundMessage事件并把OutboundMessage发回平台。核心文件区域文件基础 Channel 契约nanobot/channels/base.py各 Channel 包nanobot/channels/channel/发现与生命周期nanobot/channels/manager.pyWebSocket/WebUI 通道nanobot/channels/websocket/从源码结构看Channel 采用插件化发现机制ChannelManager通过nanobot.channels.registry.discover_plugins()扫描nanobot/channels/下的自包含包每个包导出一个ChannelPlugin描述符定义于 nanobot/channels/plugin.py并把运行时与可选的 setup 表面封装在同一个包内。新增 channel 只需贡献一个遵循 channel-package-guide.md 规范的包无需改动核心代码。WebUI 与 Gateway长驻进程的组成nanobot gateway启动的内容包括已启用的聊天 channel配置了 WebSocket 时的 WebSocket channelworkspace 作用域的 cron 服务Dream、heartbeat 等系统作业gateway.port上的健康检查端点。一个容易混淆的点打包的 WebUI 由 WebSocket channel 提供而不是健康检查端点。两者的默认地址表面默认地址Health endpointhttp://127.0.0.1:18790/healthWebUI/WebSockethttp://127.0.0.1:8765源码印证nanobot/config/schema.py 中 gateway 配置的port字段默认值即为18790。WebUI 前端源码位于 webui/生产构建输出到nanobot/web/dist/并打入 wheel。相关文档webui.md使用指南、webui/README.md前端源码开发、websocket.md协议细节。Tools模型契约的一部分工具从 nanobot/agent/tools/ 与插件入口点发现。重要文件对照工具区域文件工具基类与 schemananobot/agent/tools/base.py、nanobot/agent/tools/schema.py工具发现nanobot/agent/tools/registry.pyShell 执行nanobot/agent/tools/shell.py文件系统工具nanobot/agent/tools/filesystem.pyWeb 搜索/抓取nanobot/agent/tools/web.pyMCP 工具nanobot/agent/tools/mcp.pyCronnanobot/agent/tools/cron.py、nanobot/cron/图片生成nanobot/agent/tools/image_generation.py运行时自省nanobot/agent/tools/self.py当前仓库的工具目录实际还包含apply_patch.py、exec_session.py、long_task.py、search.py、spawn.py子代理、sandbox.py、message.py等模块可见工具面比文档表格更宽。架构文档特别警告工具行为是模型契约的一部分——除非有意变更应保持用户可见的工具名、schema 与错误消息稳定。配置与路径默认值与作用域边界配置 schema 在 nanobot/config/schema.py加载与保存在 nanobot/config/loader.py运行时路径助手在 nanobot/config/paths.py。默认路径路径默认值Config~/.nanobot/config.jsonWorkspace~/.nanobot/workspace/Sessionsconfig-dir/sessions/workspace-id/*.jsonl默认~/.nanobot/sessions/...Memoryworkspace/memory/Cron 存储workspace/cron/jobs.jsonWebUI/media/日志运行时数据配置目录下的子目录如webui/、media/、logs/源码印证nanobot/config/paths.py 中get_workspace_path()在未指定时解析到~/.nanobot/workspaceget_runtime_subdir()负责media/、cron/、logs/、webui/等实例级运行时子目录。schema 同时接受 camelCase 与 snake_case 键但回写磁盘时统一使用 camelCase 别名如apiKey、modelPresets、intervalS。Agent 自有状态 vs 生效项目上下文运行时区分了配置的 agent workspace与会话作用域携带的生效项目 workspace。两者常常是同一目录但 WebUI 聊天可以选择独立项目关切路径所有者会话命名空间、SOUL.md、USER.md、memory、自定义 skills配置的 agent workspace项目AGENTS.md、相对工具路径、shell 工作目录生效的项目 workspaceworkspace 访问模式与项目元数据会话的 workspace 作用域ContextBuildernanobot/agent/context.py把项目指令与 agent 自有的 profile、记忆合并文件系统与搜索工具以项目为常规边界仅对内置/agent 技能与精确的 agent 历史文件获得能力特定的只读访问。架构文档提醒保持这些跨根cross-root能力只读且显式不要将整个 agent workspace 当作允许的根目录。Memory 与 Sessions两级状态存储会话历史是近端的对话回放memory 是远端的 workspace 状态存储文件区域会话 JSONL 文件config-dir/sessions/workspace-id/长期记忆workspace/memory/MEMORY.md整合来源历史workspace/memory/history.jsonl引导身份文件workspace/SOUL.md、workspace/USER.md模板见 nanobot/templates/Dream记忆整合/梳理机制实现在 nanobot/agent/memory.py由运行时在启用时调度。会话的存储与压缩逻辑在 nanobot/session/manager.py。安全边界与安全相关的代码路径架构文档列出了安全敏感路径供修改工具/渠道/文件访问/网络抓取时对照边界文件Workspace 作用域nanobot/security/workspace_access.py、nanobot/security/workspace_policy.pyShell 沙箱nanobot/agent/tools/shell.pySSRF/网络检查nanobot/security/network.py、nanobot/agent/tools/web.pyPTH 防护与 CLI 启动安全nanobot/security/ 与 CLI 入口渠道访问控制各nanobot/channels/*.py中的渠道配置文档同时要求当变更涉及工具、channel、文件访问、WebUI workspace 行为或网络抓取时把安全当作功能行为的一部分并在用户可见边界变化时同步更新文档。扩展点接入新能力的官方路径架构文档以表格形式给出七类扩展的标准做法扩展方式Provider在 providers/registry.py 添加ProviderSpec在 config/schema.py 添加 schema 字段仅在通用后端不够时才实现新 providerChannel导出ChannelPlugin描述符运行时与 setup 表面放在一个包内遵循 channel-package-guide.mdTool在agent/tools/下实现工具或暴露插件入口点Agent Plugin在workspace/plugins/下添加 v1 包并从 Apps 启用MCP添加tools.mcpServers配置或在 Agent Plugin 中捆绑 serverSkill添加workspace/skills/下的 workspace 技能、在 Agent Plugin 中捆绑或在 nanobot/skills/ 添加内置技能CLI App加入 CLI Apps 目录安装器负责可执行文件生命周期并写出一个 skills-only 的 Agent Plugin总原则是优先复用已有的注册/发现模式避免临时接线ad hoc wiring。测试与验证按变更面选择最小验证常用检查命令pytest tests/test_openai_api.py::test_function -v ruff check nanobot/ cd webui bun run test cd webui bun run build按变更面选择最小验证变更最小有效验证Provider 行为Provider 单元测试或 mock API 路径条件允许时用安全配置跑nanobot agent -m Hello!Channel 行为Channel 测试 nanobot gateway启动路径WebUI 行为WebUI 测试/构建路由/设置/聊天变更需通过 gateway 做浏览器级验证工具行为工具单元测试schema 或面向模型行为变化时补充 agent 运行路径文档链接检查、命令与 CLI/schema 的一致性核对、git diff --check对面向用户的流程架构文档建议至少走一条用户实际接触的公共表面CLI 命令、HTTP 端点、WebSocket/WebUI、聊天渠道或打包导入。小结nanobot 的架构可以浓缩为三句话一条Channel → MessageBus → AgentLoop → AgentRunner → Provider/Tools → 回写的消息闭环一组按元数据集中在注册表 自包含包发现组织的扩展点Provider、Channel、Tool、Skill、Plugin、MCP以及一套围绕~/.nanobot/配置目录与 workspace 的清晰路径边界。这份源码映射文档配合 concepts.md 的产品级心智模型、configuration.md 的参数参考构成了理解、调试乃至扩展 nanobot 的完整入口。【免费下载链接】nanobotUltra-lightweight, open-source, self-hosted personal AI agent framework in Python with WebUI, tools, memory, MCP, multi-agent workflows, automation, and chat apps项目地址: https://gitcode.com/gh_mirrors/nanob/nanobot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考