aws-samples / aws-samples/sample-autonomous-cloud-coding-agents

(orchestration): Context quality metrics on task completion

オープン
#415 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
enhancement observability orchestration
主要言語
TypeScript
スター
143
フォーク
46
平均マージ
3日 10時間
マージ済み PR(30日)
24

説明

## Component

API or orchestration

## Describe the feature

Emit and persist **context-quality signals** per task at completion: tool-call count, unique files touched, hydration token usage, retry/verify loops, turns consumed vs. budget, and optional “scope expansion” flag. Expose in API, CloudWatch metrics, and `bgagent stats`.

## Use case

High tool-call counts and repeated verify failures often indicate **missing harness context** rather than model weakness. Production teams use **tool calls per session** as a proxy: more curated skills/rules → fewer exploratory tool calls → faster task completion. Platform teams need this metric to prioritize repo onboarding and detect context drift after refactors.

## Proposed solution

1. Agent `progress_writer` / runner aggregates counters during execution.
2. Orchestrator writes `context_quality` object on task record and terminal `TaskEvent`.
3. CloudWatch embedded metric format for `ToolCallsPerTask`, `VerifyRetriesPerTask`.
4. Dashboard widget in operator dashboard; optional alarm on p95 tool calls per repo.

## Other information

- Complements roadmap **LLM-assisted trace analysis** (post-mortem) with cheap always-on counters.
- Pairs with **feature-service-catalog-context-hydration** and **Dynamic onboarding artifacts**.

## Acknowledgements

- [ ] I may be able to implement this feature
- [ ] This might be a breaking change

## Acceptance criteria

- [ ] Terminal tasks include `context_quality` in API responses when execution reached RUNNING.
- [ ] Metrics visible in CloudWatch with `repo` and `workflow_ref` dimensions.
- [ ] Documented interpretation guide in `EVALUATION.md`.
- [ ] Unit tests for aggregation logic in agent and handler layers.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず、エージェントの progress_writer または runner、オーケストレーターのタスクレコード、終端の TaskEvent 処理、およびオペレーターダッシュボードと CloudWatch メトリクスのエントリーポイントを特定します。完了データが API レスポンスに届くまでの流れを追跡し、その後 EVALUATION.md と既存の handler および agent のテストを確認します。完了の条件は、列挙された受け入れ基準が集約、永続化、メトリクス、ダッシュボードでの可視性、ドキュメント、テストにわたって満たされていることです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
aws, typescript
領域
backend-api-design, observability-sre
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。