ナレッジと連携
Codeer が業務につながる方法は大きく二つあります。
- Agent がうまく答えるために使う knowledge
- チームや product が workflow を動かすために使う integration
接続する data は、Agent に扱わせたい検証済みシナリオを支えるためのものです。source material は多ければよいわけではありません。
シンプルな customer service Agent なら、最初の data は次の程度で十分かもしれません。
- 最初のシナリオに必要な承認済み policy や service facts
- first scope の外に出たときの handoff boundary
- 承認済み action scenario に必要な form、API、channel details
この章で決めること
ここでの判断は大きく二つです。
- source material をどこに置くか
- hosted channel だけではなく integration が必要になるのはいつか
前者は Knowledge Base 側の仕事です。後者は、検証済みシナリオが tool や API-driven workflow の必要性を示したときの設計です。
まずナレッジ、その次に連携
Knowledge Base には二つの役割があります。
Folders: Agent が使う可能性のあるファイルを整理するConnections: 外部アカウントや接続元を確認する
実務では、operator が最もよく触るのは Folders です。
product や backend integration では、役割はこう分かれます。
- API Access: どの workspace を使うかを決め、key を発行する
- API Reference: engineering team が request flow を実装する
Operator 向けの実用ルール
接続する前に、まず次を考えてください。
- どの検証済みシナリオがこの source を必要としているか
- 毎ターン必ず従うべき内容か
- 一部の会話でだけ必要か
- source は Agent が読むのに十分きれいか
その答えで置き場はほぼ決まります。
| 情報の性質 | 向いている場所 |
|---|---|
| 毎ターン必須 | Instructions |
| 必要な時だけ検索したい参照資料 | Knowledge Base tool |
| まだノイズが多く整理不足 | 先に整えてから接続する |
| 自分たちの product や backend が実行すべきもの | API Access と API Reference |
まだどの検証済みシナリオにも必要ない source は、いったん入れないでください。失敗した case が knowledge gap をはっきり示したときに追加します。
データは管理された snapshot と考える
接続したファイルは、自動で何でも同期される live source ではなく、管理された copy と考える方が安全です。
元ファイルが変わったら、接続済みの version も更新すべきか確認してください。