- ブログ
- Hermes はアシスタントではなく、デジタル従業員の組織システム:Profile、Orchestrator、Kanban 実践ガイド
Hermes はアシスタントではなく、デジタル従業員の組織システム:Profile、Orchestrator、Kanban 実践ガイド
目次
- このシステムはどのような問題を解決しますか?
- Profile は従業員ファイルです
- 1 つの AI、複数の位置に分割
- Orchestrator はタスク マネージャーであり、ユニバーサル ワーカーではありません
- Kanban はマルチエージェントの作業キューです
- Kanbanを初期化する
- タスクを作成して割り当てる
- タスクの実行プロセスを観察する
- ブロック、再試行、および回復を処理します。
- 特定の worker セッションのトラブルシューティングに戻る
- Dashboard: 人々が見るためのコンソール
- フェイシュはフロントデスク、Kanban は組立ラインです
- 最初に実装するのに最適な 4 つのワークフロー
- セキュリティ境界について間違えないでください
- 最小着陸ルート
Hermes はアシスタントではなく、デジタル従業員の組織システム:Profile、Orchestrator、Kanban 実践ガイド
多くの人は、Hermes を、質問をしたり、コマンドを実行したり、コードを変更したりできる、よりスマートなチャット アシスタントだと考えています。しかし、より強力な使用法は、小規模なデジタル従業員組織に変えることです。異なる profile が異なる役割を担当します。 Orchestrator は解体とスケジュール設定を担当し、Kanban はタスクを追跡可能、回復可能、反復可能なワークフローに変換することを担当します。

本当の変化は、より賢く答えることではなく、組織構造を持ち始めることです。
このシステムはどのような問題を解決しますか?
AI アシスタントを 1 つだけ使用すると、複雑なタスクが簡単にブラック ボックスになる可能性があります。「完了しました」と表示されますが、タスクが明確に分割されているかどうか、誰がどのステップを実行したか、どこに障害があり、製品がどこに配置されているかがわかりません。 Hermes のデジタル従業員システムは、この問題を 4 つの層に分類します。
- Profile: すべてのデジタル ワーカーの ID、メモリ、ツール、権限。
- Orchestrator: タスク マネージャーはすべての作業を自分で行うのではなく、タスクを分割し、タスクを割り当て、依存関係を文字列化し、結果を確認します。
- Kanban: 永続タスク ダッシュボード、タスク ステータス、実行ログ、コメント、依存関係、配信結果を記録します。
- Gateway / Feishu / Telegram およびその他のポータル: 人間がシステムに要件を送信し、情報を補足し、承認し、結果を受け取ります。
つまり、Hermes は単なる「agent」ではなく、最小限の AI 組織を作成できるということです。
Profile は従業員ファイルです
Profile は単純な文字ではありません。これは独立した従業員のホーム ディレクトリに似ており、独自の config.yaml、.env、memory、sessions、skills、cron およびステータス データベースがあります。つまり、独立したメモリ、ツール、権限、および作業履歴を持ちます。

*役割の境界は、ファイル、記憶、スキル、権限に基づいて定められる必要があります。 *
役割 profile を作成します。
hermes profile create researcher --clone
hermes profile create coder --clone
hermes profile create reviewer --clone
hermes profile create writer --clone
hermes profile create orchestrator --clone
ここでの --cloneは、現在のマスター profile の基本構成とキーをコピーすることを意味し、クイック スタートに適しています。将来的に権限を分離したい場合は、profile、ツール、モデルを 1 つずつ調整する必要があります。
既存の従業員を表示:
hermes profile list
hermes profile show researcher
従業員との直接の会話に移ります。
hermes --profile researcher
hermes --profile coder chat -q "检查这个仓库的测试入口"
1 つの AI、複数の位置に分割
profile が増えると、Hermes は単なる「AI と話す」だけではなくなり、組織のようになります。orchestrator は解体タスクを担当し、researcher は情報を確認し、coder は実装を担当し、reviewer は受け入れを担当し、publisher または writer は外部出力を担当します。

※ポストに整理した後、タスクの割り当て、検討、引き継ぎが可能です。 *
最小位置構成は次のように理解できます。
orchestrator: 依存関係の解体、配布、リンク、および進行状況の確認のみを担当します。依存症になって自分で実行しないようにしてください。researcher: 検索、データ収集、競合製品分析、事実確認を担当します。coder: コードの変更、スクリプトの実装、テストの実行を担当します。reviewer: 受け入れ、コードレビュー、リスク検査を担当します。writer: 研究またはエンジニアリングの結果を記事、ドキュメント、リリースに記述する責任を負います。
これは「正式にもう少し役割を増やす」ということではなく、複雑なタスクを大きなブラックボックスから目に見える責任の連鎖に分解するということです。
Orchestrator はタスク マネージャーであり、ユニバーサル ワーカーではありません
Orchestrator の主なルールは次のとおりです: 最初に分解とスケジュールを設定し、最後に個人的な実行を行う。ターゲットを Kanban カードに分割し、それらを実際の profile に割り当て、依存関係を使用して順序を制御する必要があります。
最も推奨される開始方法は、通常のチャットのホスト agent を一時的に Orchestrator として機能させるのではなく、実際の orchestratorprofile を作成し、Kanban を通じてタスクを受け入れるようにすることです。
まず、orchestrator スキルと worker スキルの両方が存在することを確認します。
hermes --profile orchestrator skills list | grep kanban-orchestrator
hermes --profile researcher skills list | grep kanban-worker
不足している場合は、組み込みスキルを復元できます。
hermes --profile orchestrator skills reset kanban-orchestrator --restore
hermes --profile researcher skills reset kanban-worker --restore
次に、Orchestrator の「ルート タスク カード」を作成します。
hermes kanban create "拆解并组织完成:为我的产品写一篇上线介绍文章" \
--assignee orchestrator \
--skill kanban-orchestrator \
--body "你是 Orchestrator。不要自己完成全部内容。请先确认已有 profile,然后拆成 research、draft、review 三类任务,给每张子任务写清楚验收标准,并用依赖关系串起来。" \
--workspace scratch
このタスクが dispatcher によってプルアップされた後、orchestratorworker は、kanban_create、kanban_link、kanban_comment、およびその他の Kanban ツールを通じてサブタスクを作成します。注: **worker は、シェル内で hermes kanbanを実行するのではなく、内部でツール呼び出しを使用します。 ** 人間は端末で CLI を使用し、agent は実行時に kanban_*ツールを使用します。最終的には両方とも同じ Kanban データベースに書き込みます。
Orchestrator の逆アセンブリを手動でシミュレートする場合は、CLI を直接使用して依存関係チェーンを作成することもできます。
# 1. 2つの調査タスクを並列で実行
hermes kanban create "调研目标用户痛点" \
--assignee researcher \
--body "输出 5 条真实痛点、来源链接、可引用句子" \
--workspace scratch
hermes kanban create "调研竞品上线页写法" \
--assignee researcher \
--body "找 5 个竞品页面,总结标题、卖点、CTA 写法" \
--workspace scratch
# 2. 上記2つの task id を取得したら、それらに依存する執筆タスクを作成
hermes kanban create "合成上线介绍文章初稿" \
--assignee writer \
--parent t_research_1 \
--parent t_research_2 \
--body "基于两个父任务结果,写一篇 1200 字中文文章,结构清晰,有标题、小节和 CTA" \
--workspace scratch
# 3. 最後に writer の結果に依存するレビュータスクを作成
hermes kanban create "审核上线介绍文章" \
--assignee reviewer \
--parent t_writer_1 \
--body "检查事实准确性、表达是否像人话、是否有可执行 CTA" \
--workspace scratch
実際の使用では、t_research_1、t_research_2、および t_writer_1を、前のコマンドによって返された実際のタスク ID に置き換えます。
Kanban はマルチエージェントの作業キューです
Hermes の Kanban は、通常の To Do リストではなく、耐久性のあるマルチエージェント コラボレーション ダッシュボードです。 「大きなタスク→分割→割り当て→実行→ログ→製品→承認」を同じタスクボードに入れて、各profileがいつタスクを受け取ったのか、何を行ったのか、どこで失敗したのか、そして最終的な製品がどこにあるのかを確認できるようになります。

*Kanban の値は、最終応答をただ待つのではなく、マルチエージェントのコラボレーション プロセスを明示することです。 *
Kanban は次のシナリオに適しています。
- 研究レポート: 複数の researcher が異なる方向を並行してチェックし、要約のために writer に引き渡されます。
- プロジェクトの納品: coder コード修正、reviewer レビュー、tester 検証。
- コンテンツパイプライン: 素材収集、初稿、編集、出版が分離されています。
- 長期的な運用と保守: 毎日の検査、毎週のレビュー、障害後の再試行。
- 人間の参加: タスクカードが blocked になった後、人間のコメントは unblock になります。
これと delegate_taskの違いは非常に重要です。delegate_taskは関数呼び出しに似ており、親 agent は子 agent が返されるのを待ちます。 Kanban は永続的なタスク キューに似ており、サブタスクはプロセス、時間、profile をまたいでログとステータスを保持できます。
Kanbanを初期化する
Kanban は永続的なワーク キューであるため、最初のステップはデータベースを初期化し、gateway で dispatcher を開始することです。
hermes update
hermes kanban init
hermes gateway start

※初期化完了後、Kanbanに必要なローカルデータベースとワークスペース構造が作成されます。 *
複数のプロジェクト ストリームがある場合は、異なるボードを作成できます。
hermes kanban boards list
hermes kanban boards create content-system --name "内容生产系统" --switch
hermes kanban boards show
現在のボードを切り替えずに、指定したボードを操作します。
hermes kanban --board content-system list
hermes kanban --board content-system create "写一篇产品文章" --assignee writer
タスクを作成して割り当てる
最も基本的なタスク作成コマンドは次のとおりです。
hermes kanban create "Research AI funding landscape" \
--assignee researcher \
--body "Research recent AI funding rounds and write a concise report." \
--workspace scratch
一般的に使用されるパラメータ:
--assignee researcher: どのprofileを実行するかを指定します。--body "...": ミッションの説明。具体的であればあるほど良いです。--workspace scratch: タスクに一時的なワークスペースを与えます。--workspace dir:/absolute/path: worker をウェアハウスや Obsidian vault などの既存のディレクトリで動作させます。--workspace worktree: コーディング タスクの場合、worker に git worktree を使用させます。--parent <task-id>: 依存関係を作成し、サブタスクは親タスクが完了した後にのみ ready に入ります。--skill <skill-name>: このタスク カードに特定のスキルを追加します。--max-runtime 2h: 1 回の実行時間を制限します。--max-retries 3: 連続故障ヒューズのしきい値。--triage: 最初にそれを triage 列に入れ、次に specifier を使用して完全なタスクに展開します。

*gateway はメッセージ エントリだけでなく、Kanban worker のスケジューリングも担当します。 *
タスクの実行プロセスを観察する
タスクの作成後、最も一般的に使用されるコマンドのセットは次のとおりです。
# タスク一覧を見る
hermes kanban list
hermes kanban stats
hermes kanban assignees
# 単一タスクの詳細、コンテキスト、実行履歴を見る
hermes kanban show <task-id>
hermes kanban context <task-id>
hermes kanban runs <task-id>
# ログとイベントを追跡する
hermes kanban log <task-id>
hermes kanban tail <task-id>
hermes kanban watch

*worker ログは、通常の会話と比較して、Kanban の最も重要な可観測性エントリです。 *
タスクが完了すると、タスクが ready / runningから doneに移行し、結果の概要、試行履歴、および worker 配信の証拠が保持されることがわかります。

※ただ回答を返すだけではなく、実行トレースや完了の証拠も残ります。 *
タスクがファイルを書き込んだと主張しているのにそれが見つからない場合は、単に profile ディレクトリを調べないでください。 Kanban タスク プロダクトは、最初にワークスペースに配置されます。
hermes kanban show <task-id>
hermes kanban context <task-id>

*profile は従業員の ID と構成を保持します。 kanban ワークスペースには作業成果物が保持されます。 *
ブロック、再試行、および回復を処理します。
実際のタスクは必ずスタックするため、Kanban の価値は「自動実行」だけでなく、回復機能にもあります。
worker が人間の入力を必要とする場合、タスクは blocked に変わります。コメントを再度追加できます unblock:
hermes kanban comment <task-id> "采用 2026 版 schema,不要用旧字段"
hermes kanban unblock <task-id>
worker がスタックしているか、正しく構成されていない場合は、reclaim または reassign を使用できます。
# 現在の running claim を解放し、タスクを再取得可能な状態に戻す
hermes kanban reclaim <task-id>
# 別の profile に再割り当てし、同時に reclaim する
hermes kanban reassign <task-id> reviewer --reclaim
手動でマークアップを補完する必要がある場合は、構造化ハンドオフを作成することもできます。
hermes kanban complete <task-id> \
--result "文章初稿已完成" \
--summary "已根据研究结果完成 1200 字中文初稿,包含标题、痛点、方案和 CTA" \
--metadata '{"artifact":"draft.md","verification":["人工通读一遍"]}'
特定の worker セッションのトラブルシューティングに戻る
特定の worker の結果に問題がある場合は、メインの profile に戻って推測する代わりに、それが属する profile のセッションを再開できます。
hermes --profile researcher sessions list
hermes --profile researcher --resume <session-id>

*複数の profile セッションは分離されます。これは役割分離の一部です。 *
Dashboard: 人々が見るためのコンソール
CLI は自動化に適しており、Dashboard は人間による監視に適しています。 [Kanban] タブでは、Hermes Dashboard を開いて、タスク バーの表示、ステータスのドラッグ アンド ドロップ、コメントの表示、実行記録の確認を行うことができます。
hermes kanban init
hermes dashboard
ローカル アクセスのみが必要な場合は、デフォルトの 127.0.0.1のままにしてください。 Kanban にはタスク テキスト、コメント、ワークスペース パス、実行結果が含まれるため、ダッシュボードをパブリック ネットワークに公開しないでください。
フェイシュはフロントデスク、Kanban は組立ラインです
Feishu、Telegram、Slack などのポータルは、単なるチャット ウィンドウではなく、デマンド ポータル、引き継ぎデスク、承認デスクにもなることができます。 Kanban はワークキューです。要件がカンバンに入力され、分解、実行、レビューされ、最後に結果が返されます。このようにして、複数の profile が流れ作業のように連携できます。

※入口、列、位置、返却機構が接続されて運用システムを構成します。 *
gateway では、/kanbanスラッシュ コマンドを直接使用してタスクを管理できます。
/kanban list
/kanban show t_abcd
/kanban create "写一篇产品上线文章" --assignee writer
/kanban comment t_abcd "这里要强调 ROI,不要只讲功能"
/kanban unblock t_abcd
/kanban stats
gateway から作成された Kanban タスクは、完了、ブロック、クラッシュ、タイムアウトなどの最終イベントを自動的にサブスクライブし、元のチャットに戻って通知します。これが「フロント入口+バックグラウンドパイプライン」の最小の閉ループです。
最初に実装するのに最適な 4 つのワークフロー
1. 1 人による機能の提供
まず、profile に、レポートの作成、マークダウンの整理、小さなバグの修正などの特定の小さなタスクを完了させます。いきなり5人を採用しないでください。
hermes kanban create "整理 10 个竞品页面的 CTA 写法" \
--assignee researcher \
--body "输出 Markdown:页面链接、CTA 文案、适用场景、可借鉴点" \
--workspace scratch

*最初から完全に自動化されたチームを追求しないでください。まずは1つのポジションを安定して配信しましょう。 *
2. 研究 → 執筆 → レビューのパイプライン
これは、コンテンツ制作の最も一般的な構造です。researcher は情報の確認、writer は最初のドラフトの作成、reviewer は承認です。
hermes kanban create "调研 Hermes Kanban 的核心概念" \
--assignee researcher \
--body "输出概念解释、命令示例、适合场景" \
--workspace scratch
hermes kanban create "写 Hermes 数字员工系统文章" \
--assignee writer \
--parent <research-task-id> \
--body "基于父任务研究结果,写中文长文,保留命令示例" \
--workspace scratch
hermes kanban create "审核 Hermes 数字员工系统文章" \
--assignee reviewer \
--parent <writer-task-id> \
--body "检查命令准确性、结构完整性、是否适合新手照做" \
--workspace scratch
3. 複数の役割によるプロジェクトの実施
エンジニアリング タスクは、coder、tester、および reviewer に分割できます。重要なのは、各ステップで「合格基準」と「製品の場所」を --bodyに書き込むことです。
hermes kanban create "实现登录接口限流" \
--assignee coder \
--body "在当前仓库实现登录接口限流;完成后写明改动文件和测试命令" \
--workspace dir:/Users/yubinlee/git/my-product
hermes kanban create "验证登录接口限流" \
--assignee reviewer \
--parent <coder-task-id> \
--skill github-code-review \
--body "查看父任务改动,运行测试,指出风险;不要直接合并" \
--workspace dir:/Users/yubinlee/git/my-product

*ブラックボックスの一回限りの配信というよりも、観察可能なワークフロー システムに似ています。 *
4. フリート ファーミング: バッチ同型タスク
20 個のキーワード ページ、20 個のソーシャル メディア アカウント、20 個の競合製品分析など、20 個の同様のタスクがある場合、同じ profile を使用してタスクをバッチで作成し、Kanban を使用してスループットを観察できます。
hermes kanban create "分析关键词 A 的 SERP" --assignee researcher --body "输出搜索意图、竞品、内容结构" --workspace scratch
hermes kanban create "分析关键词 B 的 SERP" --assignee researcher --body "输出搜索意图、竞品、内容结构" --workspace scratch
hermes kanban create "分析关键词 C 的 SERP" --assignee researcher --body "输出搜索意图、竞品、内容结构" --workspace scratch
hermes kanban watch --assignee researcher
セキュリティ境界について間違えないでください
Profile は、セキュリティ サンドボックスと同等ではない ID とコンテキストの分離を解決します。信頼できないコード、馴染みのないウェアハウス、および高リスクのコマンドは、依然として Docker、Daytona などのサンドボックスに配置する必要があります。また、1 人の従業員がすべての権限を取得できないように、キーは profile に従って分離する必要があります。

*Profile は安全ではありません。サンドボックスは実行層のセキュリティ境界です。 *
実践的な提案:
orchestratorあまり多くの実行権限を与えず、タスクのルーティングのみを許可するようにしてください。researcherは Web/検索権限を持つことができますが、実稼働システム キーは必ずしも必要ではありません。coderはコード リポジトリにアクセスできますが、リスクの高いリポジトリはサンドボックスまたは worktree を使用する必要があります。reviewerは差分を読み取ってテストを実行できますが、デフォルトでは製品リリース権限を持っていません。- 各 profile の
.envを個別に管理し、すべての API key を各従業員に与えないでください。
最小着陸ルート

*マスターにはユニバーサルアシスタントはいませんが、継続的に成果を提供できるデジタル従業員ワークショップが付いています。 *
次の順序でビルドすることをお勧めします。
ステップ 1: メイン profile の実行
hermes doctor
hermes model
hermes chat -q "用一句话确认你能正常工作"
ステップ 2: 3 つのポジションを作成する
hermes profile create orchestrator --clone
hermes profile create researcher --clone
hermes profile create writer --clone
hermes profile list
ステップ 3: Kanban および gateway を初期化する
hermes kanban init
hermes gateway start
hermes kanban stats
ステップ 4: 最初に単一カード タスクを実行する
hermes kanban create "写一份 500 字的 Hermes Kanban 入门说明" \
--assignee writer \
--body "面向新手,必须包含 3 个命令和 3 个注意事项" \
--workspace scratch
hermes kanban watch
ステップ 5: Orchestrator にタスクを再度分割させます
hermes kanban create "组织完成一篇数字员工系统完整教程" \
--assignee orchestrator \
--skill kanban-orchestrator \
--body "请拆成 researcher、writer、reviewer 三阶段。每张卡写清楚输入、输出、验收标准。不要自己完成全部任务。" \
--workspace scratch
ステップ 6: Dashboard またはスラッシュ コマンドを使用して操作します
hermes dashboard
または、Telegram / フェイシュウ / Slack:
/kanban list
/kanban show <task-id>
/kanban comment <task-id> "补充要求:文章要更适合小白"
/kanban unblock <task-id>
## 結論は
Hermes の強みは、「AI アシスタントの方が賢い」ということではなく、AI の作業を整理できることです。Profile では従業員がアイデンティティを持つことができ、Orchestrator ではタスクを分解でき、Kanban では実行プロセスが観察可能、回復可能、反復可能になり、Gateway では人間が使い慣れたチャット ポータルでコラボレーションに参加できるようになります。
実行可能な最小システムは、メイン profile 1 つ、orchestrator 1 つ、researcher 1 つ、writer 1 つ、および Kanban ボード 1 つです。まずは記事やちょっとした特集を安定的に配信させて、徐々にresearcher / coder / reviewer / publisherのデジタル従業員ワークショップに拡張していきます。
最新の記事
Vibe Coding Tools チームによる比較・レビュー・ワークフローの最新インサイト。
bb-browser はログイン済みの実ブラウザを AI 向け JSON インターフェースに変え、面倒な認証や対策回避を簡潔にするツールです。
lossless-claw は SQLite 全保存と DAG 要約で OpenClaw の長時間対話を支え、必要な詳細をあとから正確に引き戻せます。
WebMCPはスクリーンショット頼みの推測操作を終わらせ、Webサイトの機能を構造化ツールとしてAIエージェントに安全かつ正確に提供します。
