Website Agentを作るときに避けたかったのは、既存のSSH接続、局所置換、バックアップ、SHA-256照合、復元といった安全機構を、Agent分割のために壊すことだった。

そこで大規模な移動はせず、まずWebsiteAgentToolsを実行境界として用意した。Agentが受け取るのは、対象ファイル一覧、実ファイルに基づく問い合わせ、局所編集の入口だけである。

TK Agent
  ↓
Website Agent
  ↓
固定された処理
  ├─ 対象ファイル一覧
  ├─ 読み取りと編集案
  ├─ バックアップ
  ├─ SHA-256照合と復元
  └─ 人間確認付きデプロイ

提案と本番編集を分ける

「紹介文を短くする案を作って」のような提案依頼では、実ファイルを読んだうえで、対象ファイルとold_text → new_textを含む編集案を作る。ここでは本番確認を表示せず、作業コピーまでに留める。

一方で通常の本番編集は、従来どおり人間の承認後にだけ進める。LLMが生成したShellコマンドを直接実行する経路は用意しない。

操作できる範囲を明示する

remember / forgetはManagerのグローバル処理として、Website Agentへ入る前に実行する。そのためWebsite Agentへ記憶操作関数は渡さず、Article AgentとSNS AgentにもWeb編集用関数を公開しない。

環境管理でも同じ原則を使った。対象環境、プロジェクト、systemdジョブ、同期対象はPython側の許可リストで確認し、任意パスやLLM出力をShellコマンドへ組み立てない。同期はファイル単位の選択と確認後に、バックアップ、転送、SHA-256照合の順で行う。

検証した項目

  • Websiteへの問い合わせが正しいRouter経路になること
  • 編集案がdeploy=Falseの提案モードに留まること
  • Website Agentから記憶操作を呼べないこと
  • 局所置換、承認、バックアップ、照合、復元の既存経路を維持していること

Agentの役割を分けるときは、コードの置き場所を変えるより先に、どの機能を渡し、どの機能を渡さないかを決める方が安全性を保ちやすい。