Mastra から Mastra を学ぶ

Cursor 上で進められるのは体験として良い

MCP Doc Server を使っているのね

システムプロンプトの理解
優れたシステムプロンプトは、エージェントの目的、機能、行動ガイドラインを定義するため重要です。これは、エージェントがユーザーとどのように対話するかを形づくる基盤となります。
適切に作成されたシステムプロンプトには以下が含まれるべきです:
役割の定義: エージェントが何者で何をするのか
コア機能: エージェントが実行できるタスク
行動ガイドライン: エージェントがどのように応答し、対話するか
制約: エージェントが行うべきでない、または議論すべきでないこと
成功基準: エージェントの応答を良いものにする要素
ふむふむ

明確で包括的なシステムプロンプトは、より一貫性があり役立つエージェントの応答を生み出す。なるほど。

セットアップを終えてプレイグラウンドを簡単に作った後は、ツールの話へ。

- Agent と Tool のつくり方は AutoGen と大きな変化は感じられない。あえていうなら Zod のおかげで型強くなっているかな。
- プロンプトにツールの情報も明記してあげている。丁寧。
- なんか 3 ヶ月前よりプレイグラウンド進化してない? Tools とか Evals とか見かけなかったきがする

Tools タブからツール単位で動作確認できる

メモリの話に突入
メモリによりエージェントは以下のことができるようになります:
以前のユーザーの質問とエージェント自身の応答を記憶する
複数のやり取りにわたってコンテキストを維持する
よりパーソナライズされた関連性の高い応答を提供する
同じ情報を繰り返し尋ねることを避ける
メモリがないと、エージェントは各やり取りを初回であるかのように扱い、断片的で不満足なユーザー体験につながります。メモリがあると、エージェントは以前の会話を基に構築でき、より自然で役立つやり取りを作成できます。
メモリの重要性に「学習: 過去のやり取りから学習し、より良い応答を提供」は確かに、ともなった。

-
@mastra/memory
でメモリシステム -
@mastra/libsql
でメモリを SQLite DB へ、ストレージアダプター
モジュラーでオプショナルを前提にするのでコアではない

3 ヶ月前にやった、文章読むだけよりなんか楽に進む感じがするな(気のせいかな)

ここでレッスン 1 終了。ガンガン行くぜ!

- MCP 使うらしい
- @mastra/mcp をインストール
- これは Mastra エージェントがいろんな MCP サーバーとやりとりするために必要
MCPの利点:
標準化: 一貫したプロトコルで様々なサービスにアクセス
拡張性: 新しいMCPサーバーを簡単に追加
効率性: カスタムツールを個別に開発する必要なし
互換性: 他のMCP対応アプリケーションとの統合

Function Calling のデメリット
- 毎リクエストに functions を含めてトークン増大
- ツールが増えるとコード的に call → 実行 → レスポンスを LLM へ再投入のループが肥大化
その点 MCP は
- LLM アプリ実装側はわざわざ Function を実装しない
- スキーマは MCP サーバーに置かれるためトークンは初回 1 回だけ消費(list_tools 時かな)
- Call の結果は逐次反映
- その上サーバーが一つに集約されているからこその保守性・拡張性・セキュリティなど(コードと同じ)

テストする MCP サーバーは Zapier らしい
Zapier MCPの主な特徴:
数千のアプリとサービスへのアクセス - Zapierプラットフォーム経由で利用可能
電子メールサービス - Gmail、Outlook等
ソーシャルメディア - Twitter/X、LinkedIn等
プロジェクト管理ツール - Trello、Asana等
カスタムツール開発不要 - 各サービス用の個別ツール関数を書く必要がない

たまーに動作が不安定になって、言っていることが嘘になってたりするな

レッスンが変に進んでしまって戻ろうと思ったが、戻れぬ

Zapier に Gmail 連携する際に何も考えずに All Tool を渡したらリクエストトークンを超えた。ラッキーな学び。
APICallError [AI_APICallError]: This model's maximum context length is 128000 tokens. However, your messages resulted in 143380 tokens (141960 in the messages, 1420 in the functions). Please reduce the length of the messages or functions.
messages: [
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object], [Object]
],
tools: [
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object], [Object],
[Object]
],

減らしたら少しは楽になったが、上のエラーにもあるようにメッセージが問題。
どうやらチャットのログの問題な気がする

レッスン 2 の「Zapier統合のテスト」までは終わったかな。
ただ次の「トラブルシューティング」を戻って理解したいけどできないのが残念。
これ、復習したい人からしたら大変じゃないかな

ざーっと流れたチャット履歴を見るとこれがテストか
テスト手順:
開発サーバーの起動: npm run devを実行してサーバーが動作していることを確認
プレイグラウンドを開く: http://localhost:4111/ にアクセス
Zapierタスクをテスト: 以下のようなタスクを試す
"最後のメールを取得して"
"youremail@gmail.com に件名'テスト'、本文'こんにちは、これはテストメールです'でメールを送信して"
トラブルシューティングの項目は一切見れていない
そして GitHub MCP サーバーについての項目はこれ
GitHub MCPサーバーの追加
現在のステップでは、GitHub MCPサーバーについて学んでいます。
> # Adding the GitHub MCP Server
>
> In this step, we'll add the Composio GitHub MCP server to our agent, which will give it the ability to monitor and interact with GitHub repositories.
>
> ## What is the GitHub MCP Server?
>
> The GitHub MCP server provides tools for interacting with GitHub repositories, including:
>
> - Monitoring repository activity
> - Checking pull requests and issues
> - Viewing commit history
> - Summarizing development patterns
>
> By integrating the GitHub MCP server with your Mastra agent, you can create an assistant that helps you stay on top of your GitHub repositories, track important changes, and get insights into development activity. This is particularly useful for developers and teams who want to monitor their projects without constantly checking GitHub manually.
説明
GitHub MCPサーバーとは、あなたのMastraエージェントがGitHubリポジトリと直接やり取りできるようにするツールです。以下のような機能を提供します:
リポジトリアクティビティの監視: コミット、プッシュ、その他の活動を追跡
プルリクエストとイシューの確認: 開発チームのコラボレーション状況を把握
コミット履歴の閲覧: プロジェクトの変更履歴を分析
開発パターンの要約: コードベースの傾向や活動パターンを理解
これにより、手動でGitHubを常にチェックすることなく、開発活動を効率的に監視できるアシスタントを作成できます。
このステップの内容を理解できましたか?次のステップに進む準備ができましたら、「次へ」とお知らせください。
問題は色々あれど、全然学べてるし、ありがたい。
明日もやっていこうかな

レッスン 2 が完了。いろんな MCP Server に繋いで、アシスタントエージェントとやりとりをした。
最後にメモリ機能を強化。embedder を利用してセマンティック検索までやる設定をした。
workingMemory はメモリに展開するってことかな
// 強化されたメモリ設定
const memory = new Memory({
storage: new LibSQLStore({
url: "file:../../memory.db",
}),
vector: new LibSQLVector({
connectionUrl: "file:../../memory.db",
}),
embedder: openai.embedding("text-embedding-3-small"),
options: {
// コンテキストに最後の20メッセージを保持
lastMessages: 20,
// セマンティック検索を有効にして関連する過去の会話を見つける
semanticRecall: {
topK: 3,
messageRange: {
before: 2,
after: 1,
},
},
// ワーキングメモリを有効にしてユーザー情報を記憶
workingMemory: {
enabled: true,
template: `
<user>
<first_name></first_name>
<username></username>
<preferences></preferences>
<interests></interests>
<conversation_style></conversation_style>
</user>`,
},
},
});

ダラダラっと Lesson 3 をやっている。
会話履歴の取得、ベクトル検索、ワーキングメモリー周りをやった。