𝗜 𝗧𝗿𝗶𝗲𝗱 𝗧𝗼 𝗔𝘀𝘀𝗶𝗴𝗻 𝗧𝗮𝘀𝗸𝘀 𝘁𝗼 𝗮𝗻 𝗔𝗜

AIにタスクを割り当てようとしてみた。

異なるAIエージェントにタスクをルーティングするためのディスパッチャーを構築しようとした。

Forgeはコードを担当し、Xiao Keは会話を担当する。ロジックは単純だと思った。タスクを読み、能力を照合し、タスクを送信する。それだけだ。

途中で手を止めた。

彼らをどう照合すべきか、自分でも分かっていないことに気づいた。Forgeが実際に何をするのかを定義できなかったのだ。

答えは分かっているつもりだった。Forgeはコードを書き、テストを実行できると思っていた。しかし、仕様書（specification）を書こうとしたとき、私は失敗した。

以下のデータが全くなかった：

私は「だいたい」や「〜だと思う」といった言葉を使っていた。

「AgentSpec」という論文がこの問題を説明している。スケジューラーを機能させたいのであれば、すべてのエージェントに対して型定義された仕様（typed specification）が必要だ。定義すべきは以下の通りだ：

仕様がなければ、スケジューラーはただ推測しているに過ぎない。

推測は危険だ。なぜなら、自分が推測していることに気づかないからだ。タスクを照合しているつもりでも、実際には投影（projecting）しているだけなのだ。先週の成功を見て、エージェントがまた成功すると決めつけている。

これは人間の同僚に対しても同じことが言える。以前似たようなことをやったことがあるからという理由で、誰かにタスクを任せる。正しいこともあるが、単に将来の問題を先送りにしているだけの場合もある。

最も難しいのは、知識が不足していることではない。知らないのに、知っていると思い込むことだ。

また、仕様は静的なものだが、業務は動的なものであることにも気づいた。仕様はエージェントができることを教えてくれるが、そのエージェントがいま忙しいのか、あるいはキューがいっぱいなのかまでは教えてくれない。

私は仕様を構築していたのではなく、メンタルモデルを構築していたのだ。タスクのたびに印象を更新し、構造を構築する代わりにデータの断片を集めていただけだった。

印象は断片であり、仕様は構造である。

次の演習を試してみてほしい： 毎日使っている人やツールを一つ選ぶ。そのための能力仕様（capability spec）を書いてみる。褒め言葉は書かない。次のような実用的な文書を書くのだ：

書くという行為が、自分の欠落を浮き彫りにする。「当たり前」だと思っていることが、実は空白地帯であることに気づくだろう。

その空白地帯こそが、次のミスが起こる場所だ。何かが壊れる前に、今すぐそれを見つけ出しなさい。

Source: https://dev.to/icophy/i-tried-to-assign-tasks-to-an-ai-turns-out-i-didnt-know-what-it-could-do-4ocg

Optional learning community: https://t.me/GyaanSetuAi