<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ecs on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/ecs/</link><description>Recent content in Ecs on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sat, 04 Jul 2026 12:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/ecs/feed.xml" rel="self" type="application/rss+xml"/><item><title>Auto Agent System - Part 4 - 生產化之路:Langfuse 可觀測性、Docker 瘦身與 AWS 部署</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/</link><pubDate>Sat, 04 Jul 2026 12:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/</guid><description>「在我電腦上跑得起來」和「能給一群人用」之間,隔著四道牆: 你看得到它在做什麼嗎(可觀測性)?它打包起來多大、部署多快(image)? 它能自動擴縮、掛了會自己重啟嗎(部署)?誰能用、能用什麼由誰決定(權限)? 這一篇,就是 agent_auto_system 翻過這四道牆的過程。
前三篇我們把系統的「能力」講完了:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)。這一篇談的是另一個維度——生產化(productionization):讓這套系統能被真實地、多人地、可維運地跑起來。四個主題,對應四個 merged PR。
一、Langfuse 可觀測性:在唯一的漏斗上掛 trace 對應 PR #19:feat(harness): add Langfuse LLM-observability integration
Part 2 我們反覆強調:LLM 的「錯」不是當機,而是品質退化——HTTP 200,但答案是編的。你需要一種能看見「品質」的監控,這就是 LLM 可觀測性,而 Langfuse 是這個領域的代表工具。
這個 PR 最漂亮的地方,是它的 PR 描述本身就是一堂架構課:
「CrewAI 1.x 直接呼叫各家原生 provider SDK(不走 litellm),所以要把 Langfuse 掛在 executor——這個已經知道 model、tokens、cost、eval score、status 的唯一漏斗。」
拆解這句話為什麼重要:
很多人以為的 Langfuse 接法: 在「LLM 呼叫的那一行」自動攔截(靠 litellm 之類的中介層) 但 CrewAI 1.x 直接打原生 SDK,沒有那個中介層可攔 │ ▼ 聰明的做法:不在「呼叫點」攔,而在「執行點」記 │ ▼ executor 是所有任務的必經之路,而且它手上早就有: model + tokens + cost + eval score + status → 在這裡發一條 trace,一次到位、還帶品質分數 ┌─────────────────────────────────────────────────┐ │ executor.</description></item><item><title>Building Centralized Grafana + Prometheus Monitoring with AWS CDK: Multi-Service Observability Platform</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/centralized-grafana-prometheus-monitoring-aws-cdk/</link><pubDate>Sat, 17 Jan 2026 11:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/centralized-grafana-prometheus-monitoring-aws-cdk/</guid><description>Comprehensive guide to architecting a production-ready centralized Prometheus + Grafana monitoring platform using AWS CDK that aggregates metrics from multiple services, clusters, and infrastructure components with federation, remote storage, and advanced alerting.</description></item><item><title>Deploying Apache Superset at Scale: Production-Ready BI Platform with AWS CDK and ECS Fargate</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/deploying-apache-superset-production-aws-cdk-ecs-fargate/</link><pubDate>Sat, 10 Jan 2026 11:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/deploying-apache-superset-production-aws-cdk-ecs-fargate/</guid><description>Comprehensive guide to architecting a highly available, production-grade Apache Superset deployment using ECS Fargate, RDS PostgreSQL, and AWS CDK for enterprise business intelligence at scale.</description></item><item><title>Building Scalable WordPress on AWS ECS Fargate</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/scalable-wordpress-ecs-fargate-architecture/</link><pubDate>Sun, 10 Aug 2025 16:08:16 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/scalable-wordpress-ecs-fargate-architecture/</guid><description>Comprehensive guide to deploying production-ready WordPress on AWS ECS Fargate, exploring containerization strategies, infrastructure decisions, and scalability patterns for high-traffic content management systems.</description></item></channel></rss>