About
为什么创建 aster
aster 诞生的背景和思考
为什么创建 aster
问题背景
在探索 AI Agent 应用时，我们发现现有框架存在一些挑战：
1. 生产环境的挑战
主流 Agent 框架多为快速原型设计，缺少生产级特性：
- 并发能力不足：难以支持大规模用户（Python GIL 限制）
- 安全性薄弱：代码执行缺乏有效隔离
- 可观测性差：缺少完善的监控和审计能力
- 扩展性受限：同步阻塞模式难以应对复杂场景 ::
- 流式输出体验差：无法实时展示 AI 生成内容
- 人机交互不灵活：工具审批等场景实现复杂
- 扩展性受限：难以支持多 Agent 协作和复杂工作流
- 前端 UI 订阅，展示生成内容
- 内存占用 O(1)，支持无限长对话 ::
- 安全网关订阅，拦截敏感操作
- 支持同步等待审批结果 ::
- 监控系统订阅，记录所有操作
- 支持 OpenTelemetry 分布式追踪 :: ::
- 非阻塞流式交互
- 灵活的订阅机制
- 清晰的职责分离
- 原生支持阿里云 AgentBay、火山引擎云沙箱
- 安全隔离的代码执行环境（网络、文件系统、资源限制）
- 弹性伸缩能力，按需创建和销毁沙箱
- 成本优化，闲置自动回收 ::
2. Go 生态的缺失
主流 Agent 框架集中在 Python/TypeScript，但 Go 有独特优势：
| Go 优势 | 具体价值 |
|---|---|
| 高性能并发 | 原生 goroutine，支持 100+ 并发 Agent，无 GIL 限制 |
| 部署简单 | 单二进制文件，无运行时依赖，容器镜像小于 50MB |
| 类型安全 | 编译期检查，减少运行时错误，适合大型项目 |
| 企业友好 | 静态类型，易维护，适合团队协作和长期维护 |
| 性能优异 | 内存占用低，启动快速，适合云原生部署 |
3. 架构设计的困境
许多框架采用同步阻塞模式，导致：
我们的答案
aster 从生产需求出发，提供完整的企业级解决方案：
事件驱动架构
三通道分离关注点：
Progress 通道
实时文本流、工具执行进度
Control 通道
工具审批请求、人机交互
Monitor 通道
治理事件、错误、审计日志
优势：
云端沙箱集成
生产级安全隔离：
agent.Create(ctx, &types.AgentConfig{
Sandbox: &types.SandboxConfig{
Kind: types.SandboxKindAliyun, // 阿里云 AgentBay
WorkDir: "/workspace",
Timeout: 300,
},
})
洋葱模型中间件
清晰的职责分层：
请求 → [Middleware 1] → [Middleware 2] → Agent Core → [Middleware 2] → [Middleware 1] → 响应
内置中间件：
| 中间件 | 功能 | 适用场景 |
|---|---|---|
| Summarization | 自动总结长对话 | 上下文超过 170k tokens |
| PII Redaction | 自动脱敏隐私数据 | 处理用户敏感信息 |
| Tool Filter | 工具访问控制 | 限制危险操作 |
| Retry | 自动重试失败请求 | 提高系统可靠性 |
设计哲学
1. 简单但不简陋
提供强大功能，但保持 API 简洁：
// ✅ 简洁的 API
ag, err := agent.Create(ctx, config, deps)
result, err := ag.Chat(ctx, "创建 hello.txt 文件")
// ❌ 不需要复杂的配置
// ag.SetEventHandler(...)
// ag.SetMiddleware(...)
// ag.Initialize()
2. 灵活但有主见
- 提供最佳实践的默认配置（开箱即用）
- 支持深度定制和扩展（满足复杂需求）
- 清晰的扩展点设计（Middleware、Tool、Provider） ::
- 客服系统（70% 自动解决率）
- 文档处理
- 知识库管理 ::
- AgentPool（生命周期管理）
- Room（消息路由）
- Workflow（编排执行） ::
- 1GB RAM = 100 个并发 Agent
- 单节点处理 1000+ QPS
- 水平扩展，无状态设计 ::
- Docker 镜像 < 50MB
- Kubernetes 原生支持
- 支持多云部署 :: ::
3. 生产就绪
| 特性 | 实现 |
|---|---|
| 错误处理 | 完善的错误类型，详细的错误上下文 |
| 日志监控 | OpenTelemetry 集成，分布式追踪 |
| 断点恢复 | 7 段断点机制，会话中断后可恢复 |
| 性能优化 | stream.Reader 流式处理，内存降低 80%+ |
| 测试覆盖 | 80%+ 单元测试 + 集成测试 |
目标场景
aster 专为以下场景设计：
企业应用
需要高可靠性、安全性和审计能力
多 Agent 系统
复杂协作和任务分发
大规模部署
支持 100+ 并发 Agent
云原生环境
容器化部署，弹性伸缩
与其他框架对比
| 特性 | aster | LangChain | AutoGPT |
|---|---|---|---|
| 语言 | Go | Python | Python |
| 并发模型 | Goroutine (真并行) | GIL 限制 | 单线程 |
| 流式处理 | stream.Reader (O(1) 内存) | Generator | ❌ |
| 中间件 | 洋葱模型 (27M ops/s) | Chain (低性能) | ❌ |
| 云沙箱 | ✅ 原生支持 | ❌ | ❌ |
| 分布式追踪 | ✅ OpenTelemetry | 部分支持 | ❌ |
| 测试覆盖 | 80%+ | 中等 | 低 |
持续演进
我们将继续：