Question 1

SKILL.md の name と description が skills API で空と表示されるのはなぜですか（UTF-8 BOM の問題）？

Accepted Answer

ファイルは「UTF-8 with BOM」として保存されていました。これは Windows Notepad や PowerShell 5.1 の `Set-Content -Encoding UTF8` でよく見られる形式です。開始の `---` フェンスの前に挿入された不可視の BOM 文字（U+FEFF）が原因で、フロントマターパーサーが YAML ブロックを検出できず、ファイル全体が本文として扱われ、name/description が空として表示されていました。

修正: この問題は `develop` ブランチで解決済みです。共有フロントマターヘルパー（`src/octop/infra/utils/frontmatter.py::parse_frontmatter`）は、`---` フェンスをスキャンする前に先頭の U+FEFF を1文字だけ除去するようになりました。また、skills ルーター（`src/octop/api/routers/skills.py`）は、ローカルの `_parse_frontmatter` ではなくこの共有パーサーを使用するように統合されました。

古いバージョンでの回避策: SKILL.md を BOM なしの UTF-8 として保存し直してください（例: VS Code のステータスバーのエンコーディングメニューで「UTF-8 with BOM」ではなく「UTF-8」を選択）。あるいは、解析前に `text.lstrip('\ufeff')` を使ってプログラム的に BOM を除去してください。

Question 2

Octop の LDAP エラー「enabling LDAP over ldap:// requires StartTLS; otherwise use an ldaps:// URL」を修正するには?

Accepted Answer

これはバグではなく、Octop（`infra/auth/ldap/config.py`）における意図的なセキュリティ制限です。平文の `ldap://` は、パスワードがクリアテキストで送信されないようにブロックされており、セキュリティ設定にはこれを無効にするトグルはありません。修正方法: 1) サーバーURLを `ldaps://`（例: `ldaps://192.168.1.1:636`）に変更し、Windows AD ドメインコントローラーで LDAPS を有効にする。または 2) AD サーバーで StartTLS を有効にし、`ldap://192.168.1.1:389` を維持したまま Octop の LDAP 設定で StartTLS オプションをオンにする。明示的な「安全でない平文を許可する」回避策が必要な場合は、機能リクエストを提出してください。

Question 3

エージェントが ripgrep を使用せずにファイルシステム検索を実行した際に発生する octop のメモリオーバーフロー（OOM）を修正する方法

Accepted Answer

これは octop 1.0.1（deepagents 0.7.9）における既知のバグです：ripgrep（`rg`）が PATH 上に存在しない場合、スコープを指定しない grep 検索はピュア Python による検索にフォールバックし、`/` からの走査を行い、`/proc/<pid>/pagemap` のような疑似ファイルを無制限の `readline()` で読み取るため、ホストのメモリを枯渇させます。修正方法と緩和策：

1. **octop v1.0.2 以降へのアップグレード** — PR #2116 で修正済み：公式イメージには ripgrep が同梱されるようになり（kill 可能なサブプロセス経路）、`OctopServer.start()` が deepagents の `_python_search` にパッチを適用して、`/proc`、`/sys`、`/dev` をスキップし、行ごと・ファイルごとの読み取りサイズに上限を設けます。

2. **コンテナ内に ripgrep をインストール** — 静的な `rg` バイナリを PATH に追加し、Python フォールバックが使用されないようにします。

3. **コンテナのメモリ上限を設定** — 例えば `docker run --memory=4g ...` のように設定し、カーネルの OOM キルがホスト全体ではなくコンテナのみを対象とするようにします。

4. **`backend.root_dir` の制限** — エージェントのシェルにホストファイルシステム全体へのアクセスを与えるデフォルトの `root_dir='/'` を避けます。

Question 4

langgraph Postgres checkpointer で psycopg ConnectionPool を使用する際の "AdminShutdown: terminating connection due to administrator command" エラーの修正方法

Accepted Answer

このエラーは、psycopg_pool の `ConnectionPool` がデフォルトで `check=None`（生存確認プローブなし）になっているために発生します。そのため、`max_lifetime`（デフォルト3600秒）によるコネクションのリサイクルが同時実行中の `getconn()` 呼び出しと重なると、切断済みのコネクションが呼び出し元に渡され、`execute()` が致命的に失敗します。修正方法: 明示的な生存確認チェックと明示的な max_lifetime を指定してプールを構築します。

```python
from psycopg_pool import ConnectionPool

def _check_conn(conn):
    conn.execute("SELECT 1")

pool = ConnectionPool(
    conninfo=dsn,
    min_size=1,
    max_size=4,
    check=_check_conn,        # 引き渡す前にプローブして死んだコネクションを破棄
    max_lifetime=3600,        # 明示的に設定。PG/サーバー側のタイムアウト以下に合わせることを検討
    kwargs={"autocommit": True, "prepare_threshold": 0, "row_factory": dict_row},
    open=True,
)
```

`check` コールバックは、コネクションが渡される前に `SELECT 1` を実行します。死んだコネクションは検出され、透過的に破棄・再構築されます。追加の強化策として、`PostgresSaver`/`get_tuple` の execute パスを `psycopg.errors.AdminShutdown`（または `OperationalError`）に対するリトライでラップし、単一の死んだコネクションがジョブにとって致命的にならないようにしてください。この問題は、cron のような同時実行ワークロード下で langgraph の Postgres チェックポインターを使用する psycopg 3.x / psycopg_pool 3.3.x のセットアップに影響します。

Question 5

{"matches":...} のメモリ JSON で始まる Octop の返信が原因で WeChat の送信が失敗する（ret=-2 prepare failed）問題を修正するには？

Accepted Answer

根本原因：cronプロンプトがエージェントにmemory_saveの呼び出しを要求すると、モデルはまずMEMORY.mdの編集を試み、FilesystemGuardにブロックされ、その後memoryツールチェーンにフォールバックする。内部のreconciliation JSON（octop_memory/operations/retention.pyからの{"matches":[{"atom_id",...}]}）がメインのダイアログコンテキストに混入し、モデルは最終返信の冒頭でそれをそのままオウム返しする（glm-5.3-flashおよびglm-4.6で再現確認済み、モデル非依存）。肥大化したコンテンツ（最大約220k文字）はWeChatチャネルによって約2000文字のセグメントに分割され、レート制限'ret=-2, errmsg=prepare failed'を引き起こし、メッセージ消失が発生する。検証済みの回避策（セルフホスト）：1）エージェント設定で"memory_recall_inject_enabled": falseを設定し、atom_idやrecallメタデータをチャネルに漏洩させる自動<memory-context>注入を無効化する。2）cron/automationプロンプトを書き換えてmemory_*ツールを使わないようにし、代わりにプレーンなワークスペースファイルに履歴を記録する（例：dinner-log.mdの読み書き）。両方の変更後、同じcronタスクはクリーンな出力を生成する（400文字未満の標準フォーマットで、単一セグメントとして送信される）。長期的な修正には、reconcile JSONをmemoryサービス内に留めること、recall注入をatom_idを含まないプレーンな要約としてレンダリングすること、およびチャネル層が注入ブロックと異常に長いコンテンツをフィルタリング・切り捨てることが必要である。

Octop

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト