野生のオランと私たちを驚かせたもの

リリース ノートには、バージョンの機能が説明されています。次に何が起こったのかを説明することはあまり一般的ではありません。その理由の 1 つは、答えがやや恥ずかしいものであることが多いためです。

ここで私たちが間違っていたことが 3 つあります。

コストには原価帰属が使用されることを期待していました

Oran 3.1 では、チームが費用にいくらかかるかを答えられなかったため、エージェントごとの支出を推測しました。それは正解でしたが、その用途は私たちが期待していたものではありませんでした。

ほとんどのチームがエージェントごとのアトリビューションに関して最初に行ったことは、支出を削減することではありませんでした。それは、誰も知らないエージェントが実行されていたことを発見したのです。アトリビューションは、財務ツールである前に在庫ツールであることが判明しました。所有者が認識されていないコストラインは、何かが忘れられていることを示す最も明確なシグナルであるためです。

これは所有権についての考え方を再構築したものであり、3.6 が所有権を規約ではなくエージェントの所有物として扱う理由の大部分を占めています。

予算が寛大に設定されることを期待していました

暴走行為に対するセーフティネットとして、チームが予想使用量を大幅に上回る上限を設定することを想定して、3.2 でサーキットブレーカーの予算を構築しました。

多くは、予想される使用法に近いように意図的にタイトに設定し、ブロックを保護ではなく信号として使用していました。エージェントが限界に達すると、それは情報です。「何かが変わった、見てください」ということです。

私たちはガードレールを建設し、チームはそれを煙探知機として使用していました。それは機能しますが、それはこの機能の目的ではありません。

eval はデプロイメント前に記述されることを期待していました

Oran 3.3 の想定基準は事前に定義されており、これが私たちが推奨することであり、ほとんど誰もやらないことです。

実際には、ほとんどのチームは、エージェントが何か問題を生成した後、失敗から逆算して最初の評価を作成しました。結果として得られた基準は、想像上の失敗ではなく実際の失敗をコード化しているため、設計されたセットよりも狭く、多くの場合、より有用です。

私たちはこれをチームが不正に行っているとして扱うのをやめました。実際の失敗から成長したセットは良いものに収束し、存在するという利点があります。

何があったのか

読み書きの非対称性。 Teams は、私たちが取り組んでいるすべてのセクターにわたって、エージェントに広範な読み取りアクセスと狭い書き込みアクセスを一貫して許可します。その前提に基づいてポリシー層を構築したことは正しかったです。

共有カタログの値。チーム間の重複は予想どおり大きく、エージェント ハブは予想どおりそれに対処しました。これは、このリストの中で最も驚くべき項目ではありません。

ミスを公開する理由

なぜなら、メーカーが期待したことだけを基にして構築されたプラットフォームは、ユーザーの行動から離れていくからです。上記の 3 つの驚きは、それぞれ 3.6 で何かを変更しましたが、ロードマップからは浮上しなかったものはどれもありません。

あなたのデプロイメントで、明らかに私たちが設計していないことを Oran で実行している場合は、それについてお聞きしたいと思います。 That is genuinely the most useful thing we receive.

次へ

バージョン ページでは、Keter 1.0 以降のすべてのバージョンをカバーしています。オープン開発コミュニティへの参加は無料で、観察は contact@capconsultor.eu に送信できます。