内置工具清单
在决定一个可由代理调用的工具应保留在核心二进制中、变为功能门控、移至 WASM 插件、作为技能包发布，还是使用 MCP 或 CLI 支持的集成时，请参考此页面。
这是一个分类映射，不是移除计划。在替代方案保留操作员契约之前，不要移除或外部化任何工具：配置、安全策略、工具回执、审计可见性、兼容性和回滚。
运行时注册表的权威来源是 crates/zeroclaw-runtime/src/tools/mod.rs，尤其是 default_tools、all_tools_with_runtime 和 register_skill_tools_with_context_and_runtime。共享工具实现主要位于 crates/zeroclaw-tools/ 下。
分类桶
| 存储桶 | 含义 | 下一步操作 |
|---|---|---|
| 保留内置内容 | 基线代理契约的一部分，或与运行时策略、收据、内存、会话或委派紧密耦合。 | 除非通过 RFC 更改代理契约，否则保留在 core 中。 |
| 功能开关候选项 | 第一方行为仍应属于 ZeroClaw，但依赖、平台、二进制大小或运维风险成本不应影响最小构建。 | 在考虑移除之前，添加或收紧一个特性/配置门控。 |
| 稍后外部化 | 有用的能力，但长期拥有者应该是一个插件、技能包、MCP server 或外部 CLI，因为该行为主要是对某个产品、供应商 API 或可选工作流的封装。 | 保持兼容性，直到外部接口真正可用并有文档说明。 |
| 暂未操作 | 当前证据不足以选择不同的主目录。 | 保留原样，并结合源、用法和替换证据重新查看。 |
保留内置内容
这些工具构成最小的本地代理工作面。它们由 default_tools 注册，并由完整注册表再次注册。
| 工具(s) | 为什么它们会停留 |
|---|---|
shell | 在 ZeroClaw 的 shell 策略、沙盒、运行时适配器、路径守卫和收据下执行本地命令。 |
file_read, file_write, file_edit | 拥有工作区文件契约、持久化行为、路径防护和审计面。 |
glob_search, content_search | 提供本地发现，无需依赖特定 shell 的命令语法。 |
这些完整注册表工具也应保留为内置，因为它们是运行时、内存、协调或操作者控制的原语，而不是可选的产品集成。
| 工具(s) | 为什么它们会停留 |
|---|---|
memory_store, memory_recall, memory_forget, memory_export, memory_purge | 长期记忆是第一方运行时契约，并使用共享内存所有权规则。 |
cron_add, cron_list, cron_remove, cron_update, cron_run, cron_runs, schedule | 调度会影响自主执行、所有权和运行历史；请在核心中将其保持为策略可见。 |
spawn_subagent, delegate, send_message_to_peer | 委派是 agent 执行模型的一部分，必须共享风险配置、工具、记忆以及父/子约束。 |
ask_user, escalate_to_human, reaction, poll, channel_room | 这些是具有后绑定通道句柄和回执的通道桥接运算符交互原语。 |
sessions_current, sessions_list, sessions_history, sessions_send | 会话可见性和消息发送必须共享守护进程/网关会话后端以及 agent 所有权边界。 |
model_routing_config, model_switch, proxy_config | 这些暴露当前的模型/代理路由控制平面，不应偏离 config-source 的行为。 |
TodoWrite | 在运行时工具界面中维护代理的结构化任务列表；在核心层保持其稳定的工具名称和生命周期行为。 |
read_skill 和由技能定义的工具，kind = "shell"、kind = "http" 或 kind = "builtin" | Skills 是预期的扩展面，但将已安装的 skills 转换为 tools 的运行时桥接是核心。 |
功能开关候选项
这些工具目前属于第一方，但它们值得明确划分功能/配置边界，因为它们会增加平台、依赖、网络或 UI 表面面积。
| 工具(s) | 边界 | 分类 |
|---|---|---|
browser, browser_open, browser_delegate, text_browser | 由配置控制且依赖运行时。 | 保留 first-party，但继续收紧功能/配置门控，因为浏览器自动化是一个很大的受信任攻击面。 |
http_request, web_fetch, web_search_tool | 受配置控制的网络访问。 | 在 SSRF、allowlist、provider 路由和 receipt 行为仍由 ZeroClaw 拥有时，保持 first-party。仅在 MCP/plugin 替换能够表达相同网络策略后再重新审视。 |
SOP 工具（sop_list、sop_execute、sop_advance、sop_approve、sop_status 和有条件的 sop_workshop） | 受运行时句柄限制；sop_workshop 还需要程序性记忆。 | 保留第一方；SOP 生命周期、审批流程、程序记忆和审计记录属于运行时状态，而非通用的外部集成。 |
| WASM 插件工具 | 编译特性和配置门控的宿主桥接。 | 保持宿主桥为第一方；各个插件能力应置于核心之外。 |
execute_pipeline | 由配置控制的工具链式调用。 | 在工具链策略、逐步收据和调用方允许列表足够稳定、可判断其是否为核心之前，保持受限。 |
knowledge | 受配置门控的知识表面。 | 在关系记忆和图谱工作流仍在被提升到面向用户的文档和技能中时，保持受限。 |
file_upload, file_upload_bundle, file_download | 受配置控制的数据移动。 | 保持门控；这些是策略敏感的数据移动工具，在外部化之前需要显式替换。 |
backup, data_management | 本地状态变更面。 | 考虑更清晰的特性/配置边界，因为两者都会在 обыч规文件编辑流程之外修改本地状态。 |
screenshot, image_info, canvas | 可视化/UI 工具界面。 | 先保留；待插件和仪表板边界确定后，再用可视化/UI 工具界面进行分类。 |
llm_task | 依赖于提供方的子任务执行。 | 保留，直到 provider 作用域的子任务执行与委派具有单独的契约。 |
security_ops | 由配置门控的安全操作。 | 保持受限；在插件能够宣告等效的权限、收据和回滚之前，安全操作需要第一方策略可见性。 |
verifiable_intent | 由配置控制的信任策略。vi_verify 工具暂时未在模型可见的注册表中提供。 | 继续保持门控并仅限第一方提供；意图签发和验证会影响信任策略，因此在凭据边界稳定之前应继续仅由第一方提供。由于尚不存在链验证器，即使 verifiable_intent.enabled = true，vi_verify 也不会注册；现在启用该配置节只会发出一条指明这一缺口的警告：该警告会在进程启动时记录、每次守护进程重新加载时再次记录，并在 zeroclaw config patch 将该配置节从禁用改为启用时再记录一次；此外，zeroclaw doctor 和配置 API 会将其报告为 verifiable_intent_tool_withheld 验证警告，因此即使 observability.log_persistence = "none"，该警告也能保留。不提供该工具并不会移除签发和验证的库路径，这些路径仍可供嵌入方使用。仅在一个使用已验证链结果的验证并评估路径之后恢复注册，并在同一变更中一并停用这两种渠道。 |
硬件探测（hardware_board_info、hardware_memory_map、hardware_memory_read） | 外设门控的硬件访问。 | 在通过 peripheral registry 路径添加硬件工具并且在 ZeroClaw 权限规则下接触物理设备时，保持 first-party。 |
稍后外部化
这些是替换接口存在后最有可能从核心二进制中移出的最强候选项。在此之前，请保持它们兼容且对策略可见。
| 工具(s) | 可能的长期驻留地 | 为什么 |
|---|---|---|
notion, jira, microsoft365, google_workspace, linkedin, composio | 插件、MCP server 或基于 CLI 的集成。 | 这些大多封装了第三方产品和认证模型，它们可以独立于核心运行时演进。 |
claude_code, claude_code_runner, codex_cli, gemini_cli, opencode_cli | 由 CLI 支持的集成或技能包。 | 外部 CLI 已经负责认证、命令行为和发布节奏；如果 ZeroClaw 调用它们，ZeroClaw 应保留收据和策略。 |
email_search, email_read | 通道 companion 插件或 MCP 服务器。 | 电子邮件搜索/读取很有用，但它依赖外部账户认证和频道设置，而不是基础代理契约。 |
discord_search | Channel companion plugin 或 archive-query 技能。 | 它依赖于该频道生成的 Discord 存档数据库；在存档 API 明确之前，请将其保留在该频道附近。 |
image_gen, cloud_ops, cloud_patterns, project_intel, report_template | Skill 包、插件或 MCP 服务器。 | 这些是可选的工作流或供应商/数据服务包装器，而不是核心执行原语。 |
weather | 技能包或 HTTP 支持的技能；如果需要自定义格式或策略且达到同等能力，后续可用插件或 MCP 服务器。 | 当前内置功能是一个无密钥的 wttr.in 封装器。一个最小查询符合 HTTP 技能形状，但完全外部化仍需要在格式化输出、tool.weather 代理策略以及内置工具名称 / 自动批准行为方面保持一致。 |
pushover | 通过 system.notify 的通用通知路径，以及一个作用范围很窄的服务插件。 | 其核心形态是设备通知，与标准节点能力有重叠；Pushover 特有的认证、投递、失败模式以及适配器兼容性在移出核心运行时之前仍需要验证。 |
git_operations | CLI 支持的集成或作用范围狭窄的插件。 | 它会对本地和远程仓库产生副作用，因此任何外部替代方案都必须保留策略检查、收据以及明确的操作者可见性。 |
尚未执行任何操作
在另一个设计切片产生更好的证据之前，请保持这些表面不变：
calculator：体积小、依赖轻，而且足够无害，把它移出去可能带来的复杂性比节省的还多。tool_search和延迟的 MCP 激活：这是当前 MCP 发现流程的一部分，但其确切的长期边界取决于 v0.8.2 插件/MCP 工作。- 会话重置/删除工具：实现已存在，但代理注册表默认不会注册破坏性的未限定变体。除非某个 operator/admin 界面明确需要它们，否则请保持这一边界。
迁移规则
在将任何工具移出 core 之前，替代方案必须回答：
- 哪个配置仍然属于第一方，哪个配置会移到插件、技能、MCP server 或 CLI？
- 替换如何保留自治性检查、允许/拒绝列表、工具收据、审计日志和归因？
- 当内置工具消失时，现有配置会如何失效或迁移？
- 运维人员能否看到该 capability 是已安装、已启用、已禁用、已阻止还是缺失？
- 如果外部包损坏，回滚路径是什么？
如果未来某个切片需要代码证明，请从“Externalize later”表中选择一个低影响范围的候选项，并在不删除同一 PR 中内置工具的情况下证明替换路径。