如何以 AI Agent 團隊構建即時電子商務支援平台

Ever abandoned a shopping cart because you couldn't quickly ask, "When will my package arrive?" Industry averages put cart abandonment at around 70%, and slow answers are a major cause: contact forms, ticket portals, and emails that get a reply hours later.

That problem led me to build Aura Gear, a real-time customer support platform for e-commerce. It's also an experiment in how an engineer and a team of AI agents can build a complete system together, from specification to operations.

⚡ Aura Gear: Real-Time E-Commerce Customer Support Platform

An asynchronous, ultra-low latency real-time customer support platform built for modern e-commerce storefronts. Features an embeddable customer concierge widget with instant order tracking and a multi-pane support agent command center.

🌐 Live Production Deployment

• 🛍️ Storefront & Live Customer Chat: https://appbuild-607895321006.asia-southeast2.run.app

• 🎧 Support Agent Command Console: https://appbuild-607895321006.asia-southeast2.run.app/agent.html
• 🩺 Operational Health Endpoint: https://appbuild-607895321006.asia-southeast2.run.app/api/health

📋 Evaluation Rubric Alignment Matrix (12 Criteria / 24 Points)

…

The Problem

Online shoppers usually need fast answers on three things:

• Parcel tracking and carrier timelines
• Return and exchange policies
• Sizing, specifications, and inventory availability

Aura Gear addresses this with two components:

1. Customer concierge widget: an embeddable chat for online stores with instant order tracking.
2. Agent command center: a multi-pane dashboard for the support team.

Architecture at a Glance

• Frontend: a lightweight glassmorphic UI (under 150KB) with no build step
• Backend: Python 3.10+ with FastAPI and Uvicorn, using native asynchronous WebSockets
• Persistence: a thread-safe asynchronous chat store for conversations, messages, and agent assignments, with session recovery
• Deployment: multi-stage Docker image on Google Cloud Run

Run it locally with one command:

python3 app_build/server.py

Or with containers:

docker compose up -d --build

Built by an AI Agent Team

The project was designed, built, and verified by six agent personas, each with a specific role:

Each agent has its own skill (an instruction file) under .agents/skills/, and a single startcycle.md workflow orchestrates the whole cycle with a human approval gate. Humans keep the final say.

Context Management: Keeping Agents on Track

AI agents perform well when their context is clear, so the repo uses modular documentation:

• AGENTS.md: the master governance file
• docs/architecture.md: architecture and sequence diagrams
• docs/permissions.md: tool execution boundaries, filesystem safety, credential isolation
• security/ai-data-policy.md: telemetry policy (no PII or credentials)
• ops/runbook.md: diagnosis and alerting guide

Well-organized documentation is the agent's working memory. The clearer the boundaries, the more dependable the results.

Testing and CI/CD

One command runs all tests:

python3 -m unittest discover tests

• Unit tests: order ID normalization (#ORD-1001, ord-1001, 1001), the order catalog, and the chat store
• Integration tests: health endpoint, order lookup, 404 handling, and the macro endpoint

The GitHub Actions pipeline has three stages:

Push / Pull Request
        |
        v
 Stage 1: CI     -> flake8 + unit/integration tests
        |
        v
 Stage 2: CD Dev -> build container, deploy & verify dev
        |
        v  (manual approval)
 Stage 3: CD Prod -> workflow_dispatch, promote to production
                     + probe Cloud Run health URL

Production deployment sits behind a manual approval gate. Automation can be aggressive in dev, but production calls for a conscious decision.

Alerting on Real User Impact

Instead of generic CPU or RAM graphs, alerts target what users actually feel:

1. WebSocket drop rate above 5% within 3 minutes (shoppers losing connection)
2. p95 latency above 500ms (chat feels laggy)
3. 5xx error rate above 2% on /api/orders (order tracking failing)

Every WebSocket connection carries a trace_id so logs can be correlated easily, and telemetry never includes personal data, payment details, or credentials.

The On-Call Agent

When an alert fires, @oncall-responder wakes up on its own:

1. Parses the alert webhook
2. Correlates error logs via trace_id
3. Cleans up memory from orphaned sessions
4. Restarts ASGI workers if they become unresponsive
5. Verifies recovery with ops/health-check.sh

This is where platform engineering meets AI engineering: a well-written runbook can become the "brain" of an operational agent.

Try It Yourself

• Storefront and live chat: https://appbuild-607895321006.asia-southeast2.run.app
• Support agent console: https://appbuild-607895321006.asia-southeast2.run.app/agent.html
• Health endpoint: https://appbuild-607895321006.asia-southeast2.run.app/api/health

Lessons Learned

1. Spec first, code second. An OpenAPI contract and a task tracker with acceptance criteria keep agents focused.
2. Clear roles make agents more reliable. One agent, one responsibility, each with its own skill.
3. Keep humans in the loop. Approval gates in the workflow and in production deploys preserve control.
4. Alert on user impact, not just infrastructure numbers.
5. Runbooks are AI assets. Documented procedures can be executed directly by agents.

Closing Thoughts

Aura Gear is more than a chat app. It's an exercise in building a complete software delivery lifecycle with AI agents: specification, code, tests, containers, CI/CD, observability, and incident response.

If you're working at the intersection of data/platform engineering and AI engineering, I'd love to hear how you structure agent roles and guardrails in your own projects. Share your approach in the comments, and a ⭐ on the repo is always appreciated.