Grok 工具内核oppnc/dsh-kernel-grok

dsh-kernel-grok

DSH 有个很朴素的想法：一切都是插件。模型是插件，工具是插件，子代理也是插件，想怎么拼就怎么拼。

顺着这个思路，我们把 Grok Build 写成了 DSH 插件。你熟悉的 grok-build 工具面——run_terminal_cmd、read_file、search_replace、list_dir、grep、web_search、web_fetch、todo_write、task、get_task_output、kill_task、ask_user_question、enter_plan_mode、exit_plan_mode——现在就是 DSH 的原生工具，名字一样、schema 一样、行为一样。

好处很简单：在 DSH 里原生使用 grok 这套工具，和直接打开 Grok Build 没有任何区别。每个模型都待在自己最熟悉的环境里，不管是主 agent 还是 subagent，感觉就像回家一样。

两条 grok 原生的规矩，原样保留：search_replace 就是 grok 的写入工具（新建文件传空 old_string）；run_terminal_cmd 必须带 description 说明为什么要跑这条命令。

web_search 用 Grok OAuth JWT 打 cli-chat-proxy.grok.com（tools: [{type:'web_search'}]），不走 DeepSeek 搜索。web_fetch 是经同一代理的本地 HTTPS GET。对齐 grok-build e5fd481（2026-08-13）；之后 origin/main 只动 workspace/权限/媒体内部，没有新的 grok_build 工具名。

系统提示词与子代理

lib/system-prompt.js 携带上游 Grok Build 的 prompt.md（按 DSH 工具面解析）；
apply() 把它注册为 agent 唯一的 system-prompt 段（complete: true +
suppressRuntimeContext()）。

lib/subagents.js 提供该内核自己的子代理配方——grok-agent（general-purpose）、
grok-explore、grok-plan——每个都是上游 subagent_prompt.md 注入内置角色
prompt 后的结果。mesh 会加载它们，并在每个子代理上以 config.tools 白名单挂载
本插件，所以 grok 子代理看到和使用的正是 grok 子代理的工具。

安装

1. 用官方插件命令把本包装进你的 profile：

dsh plugin --profile web add dsh-kernel-grok

GitHub 也可以（dsh plugin --profile web add github:oppnc/dsh-kernel-grok），因为本仓库已经提交了 lib/。

本包是普通插件（没有 dsh.bundle 声明），dsh plugin 会把它作为不激活的依赖安装——这是预期行为：下面的预设行会按名字引用它。

2. grok-kernel agent 预设随 dsh-kernel-mesh 的 presets/ 目录分发。把它复制到官方用户预设根目录（如果你不用 mesh，就从 mesh 仓库取预设目录）：

dsh_home="${DSH_HOME:-$HOME/.dsh}"
cp -r "$dsh_home/profiles/web/node_modules/dsh-kernel-mesh/presets/grok-kernel" "$dsh_home/.agent-presets/"

预设已经在 planning 分组里包含 grok-surface 行；如果你自己写预设，就把它加进该分组：

- id: grok-surface
name: dsh-kernel-grok

grok-kernel 预设也会替你禁用 DSH 里重名的行（tool-fs-search、tool-web、tool-todo、tool-ask-user）。

使用

选 grok-kernel 预设和 grok-kernel / grok-4.6 模型。你的 agent 就跑在 Grok 内核上，用的还是 grok 原生那套工具。

许可证

MIT —— 见 LICENSE。