This file provides guidance to AI Agent when working with code in this repository.
# Build both main applications
go build -v ./cmd/aster
go build -v ./cmd/aster-server
# Build with version info
go build -ldflags "-X main.version=$(git describe --tags --always)" ./cmd/aster# Run all tests
go test -v ./pkg/...
# Run tests without race detection (CI default)
go test -v -short ./pkg/...
# Run specific package tests
go test -v ./pkg/agent
go test -v ./pkg/workflow
go test -v ./pkg/session
# Run integration tests (requires Docker)
go test -v ./test/integration/# Run golangci-lint (current CI configuration)
golangci-lint run --disable=errcheck --enable=govet,ineffassign,staticcheck,unused ./pkg/...
# Run with default settings (local development)
golangci-lint run ./pkg/...# Format code
go fmt ./...
# Vet code
go vet ./...
# Tidy dependencies
go mod tidy
# Download dependencies
go mod downloadAster is an event-driven AI Agent framework built with Go, implementing the Google Context Engineering standards with an onion-model middleware system.
-
Agent System (
pkg/agent/)- Core agent implementation with event-driven architecture
- Three event channels: Progress (real-time output), Control (human interaction), Monitor (governance)
- Dependencies injection pattern with Registry pattern for tools and templates
-
Workflow Engine (
pkg/workflow/)- Sequential, Parallel, and Loop workflow agents
- 8-step types with Router for dynamic routing
- Stream-based execution with Go 1.23 iter.Seq2
-
Memory Management (
pkg/memory/)- Three-tier system: Text Memory, Working Memory, Semantic Memory
- Advanced features: Provenance (source tracking), Consolidation (LLM-driven merging), PII Auto-Redaction
- Vector store integration with confidence scoring
-
Middleware System (
pkg/middleware/)- Onion-model architecture with priority-based layers
- Built-in middlewares: filesystem, summarization, agent memory, working memory
- Custom middleware support via WrapModelCall/WrapToolCall interfaces
-
Tools System (
pkg/tools/)- Registry pattern for tool discovery and management
- Built-in tools: filesystem operations, bash execution, HTTP requests, web search, todo management
- MCP (Model Context Protocol) support for external tool integration
- Long-running tools with async execution and progress tracking
-
Session & Persistence (
pkg/session/)- PostgreSQL and MySQL support with JSONB/JSON columns
- Event sourcing with append-only storage
- 7-point recovery mechanism for fault tolerance
-
Multi-Agent Collaboration (
pkg/stars/)- Stars pattern for agent collaboration
- Scheduler for intelligent task distribution
- Permission management system
-
Sandbox Security (
pkg/sandbox/)- Local, Docker, Aliyun AgentBay, and Volcengine sandbox backends
- Process isolation and resource limits
- Security audit logging
The core is built around three distinct event channels:
- Progress Channel: Stream text chunks, tool execution progress (UI/Chat consumers)
- Control Channel: Tool approval requests, user confirmations (Human-in-the-loop systems)
- Monitor Channel: Governance events, errors, audit logs (Monitoring/Compliance systems)
Multi-provider LLM support through a unified interface:
- Anthropic Claude (primary)
- OpenAI GPT
- DeepSeek
- Other OpenAI-compatible providers
- Agent receives input → Subscribe to event channels
- Request flows through middleware onion (pre-processing)
- LLM provider processes with tool calling
- Tool execution in secure sandbox
- Response flows back through middleware (post-processing)
- Events published to appropriate channels
- Session persistence stores conversation history
cmd/: Main applications (aster, aster-server)pkg/: Core library packagesexamples/: Usage examples and demosdocs/: Documentation and architecture guidestest/: Integration and performance tests
Use dependency injection extensively:
deps := &agent.Dependencies{
Store: store,
SandboxFactory: sandboxFactory,
ToolRegistry: toolRegistry,
ProviderFactory: providerFactory,
TemplateRegistry: templateRegistry,
}- Unit tests:
*_test.gofiles alongside source code - Integration tests:
test/integration/with Docker containers - CI uses
-shortflag to skip long-running tests - Race detection disabled in CI for performance
- Streaming responses use iter.Seq2 for O(1) memory
- Long-running tools support async execution
- Session persistence optimized with JSON columns
- Resource limits enforced via GOMAXPROCS and GOMEMLIMIT
- All code execution in sandboxed environments
- Tool-level permissions with allow/deny/ask policies
- PII auto-redaction for sensitive data
- Complete audit trail for tool executions