aws-samples / aws-samples/sample-autonomous-cloud-coding-agents
(orchestration): Context quality metrics on task completion
- 主要言語
- 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