一个真实的痛点
假设你在做一个创业产品，核心能力依赖 AI Agent——可能是一个智能客服、一个数据分析助手、一个自动化写作工具、或者任何需要 Agent 持续交互的服务。
你的 Agent 本身可能已经很好用了。但当你想把它变成一个产品，让 100 个用户同时用的时候，你会发现要解决的工程问题远比 Agent 本身复杂：
- 每个用户需要独立隔离的运行环境
- 高峰期的并发请求怎么调度和排队
- Agent 执行失败了怎么自动恢复
- 怎么把 Agent 的实时进度推给前端
- 怎么监控每个任务的状态和资源消耗
这些问题跟你的产品本身毫无关系，但不解决就上不了线。一个小团队可能要花 3 个月搞这些基础设施。
opencode-scale 就是为了解决这个问题——一个通用的 AI Agent 编排层，让你跳过基础设施建设，直接做产品。
它是什么
一句话：你有一个 Agent 服务，想让很多用户同时用，中间缺的那一层就是它。
你的产品（Web / App / API / 小程序）
↓
opencode-scale（编排层）
↓
Agent 实例 × N（隔离沙箱）
你负责上面的产品层和下面的 Agent 能力，opencode-scale 负责中间所有的脏活：
| 能力 | 说明 |
|---|---|
| 多租户隔离 | 每个用户的 Agent 跑在独立 gVisor 沙箱里，互不干扰 |
| 并发调度 | 架构水平可扩，已验证 2000+ 并发 workflow 调度 |
| 智能排队 | 容量满时自动排队，通过 SSE 实时推送排队位置 |
| 失败自愈 | Temporal workflow 自动重试、超时保护、完整执行记录 |
| 实时推送 | SSE 流式返回 Agent 执行进度和结果 |
| 结果校验 | JSON Schema 校验 Agent 输出，不合格自动重试 |
| 全链路可观测 | Prometheus + Grafana + Temporal UI + 审计日志，开箱即用 |
适用场景
opencode-scale 不限定 Agent 的类型。任何需要"隔离环境 + 并发调度"的 Agent 服务都适用：
AI 编程产品 — 每个用户一个隔离的 Agent 编码环境，在线 AI 编程助手的后端
智能客服 / 咨询类产品 — 每个对话会话一个独立 Agent 实例，互不干扰
数据分析平台 — 用户提交分析任务，Agent 在沙箱里操作数据，结果流式推送
内容生成 SaaS — 批量生成文档、报告、翻译，每个任务独立执行，失败自动重试
AI 教育平台 — 每个学生一个独立 Agent 环境，平台监控任务状态和资源用量
Agent 能力评测 — 同一批任务用不同 Agent 跑，隔离执行，结果自动收集对比
核心逻辑都一样：你有一个 Agent，它很强但只能一个人用。opencode-scale 让它能同时服务很多人。
架构
Client → Kong Gateway → Router (Go) → Temporal → Worker → Sandbox (你的 Agent)
↓
Pool Manager → K8s SandboxClaim CRD
为什么用 Temporal
一个 Agent 任务不是一个简单的 job。它是一个多步骤流程：分配沙箱 → 发送请求 → 流式接收结果 → 校验输出 → 释放沙箱。任何一步都可能失败。
Temporal 的 workflow 语义天然匹配这个模型：
- 每一步自动重试
- 超时自动处理
- 每个任务有完整的执行记录可追溯
- 可视化 UI 看到每个 workflow 的状态
比自己写状态机 + 消息队列可靠得多。
为什么用 K8s SandboxClaim CRD
每个用户的 Agent 需要隔离运行。我们用 gVisor 沙箱容器 + Kubernetes CRD 来做：
- SandboxWarmPool — 预热池，提前准备好 N 个沙箱，用户来了直接分配，不用等冷启动
- SandboxClaim — 声明式申领，用完自动释放
这不是 HPA 那种被动扩缩容——是主动的资源池管理。
双模式
开发和生产用同一套代码：
pool:
mode: local # 本地开发：mock 服务，不需要 K8s
# mode: k8s # 生产：真实 gVisor 沙箱
扩展能力
架构每一层都水平可扩：
| 层 | 扩展方式 |
|---|---|
| Router | 无状态，加副本 |
| Worker | 无状态，加副本 |
| Temporal | 单集群支持百万级 workflow |
| 沙箱 | 加机器加节点 |
软件层没有上限，瓶颈只在你的集群有多大。 已验证 2000+ 并发 workflow 调度，全部有完整执行记录。
2 分钟跑起来
不需要 K8s，Docker Compose 一键启动：
git clone https://github.com/YOUR_USERNAME/opencode-scale.git
cd opencode-scale
make compose-up # 启动全部服务
make seed # 提交示例任务
# 实时查看任务进度
curl -N http://localhost:8080/api/v1/tasks/{taskId}/stream
API
提交任务
curl -X POST http://localhost:8080/api/v1/tasks \
-H "Content-Type: application/json" \
-d '{
"prompt": "你的 Agent 任务描述",
"timeout": 300,
"userId": "user-123"
}'
SSE 实时推送
curl -N http://localhost:8080/api/v1/tasks/{taskId}/stream
event: status
data: {"status":"running"}
event: result
data: {"status":"completed","result":"...","duration":45.2}
前端监听这个端点即可，任务完成后流自动关闭。
带输出校验
curl -X POST http://localhost:8080/api/v1/tasks \
-H "Content-Type: application/json" \
-d '{
"prompt": "...",
"outputSchema": "{\"type\":\"object\",\"required\":[\"answer\",\"confidence\"]}"
}'
Agent 输出不符合 Schema，系统自动带校验反馈让 Agent 重试，最多 3 轮。
生产部署
# Helm
helm install opencode-scale ./charts/opencode-scale \
--namespace opencode-scale --create-namespace
# Kustomize
make deploy-prod # 3 Router + 5 Worker + 200 池上限
可选：S3/MinIO 归档 workflow 历史，释放数据库空间。
技术栈
| 技术 | 用途 |
|---|---|
| Go 1.25 | 核心编排 |
| Temporal | workflow 编排、重试、执行记录 |
| Kubernetes + gVisor | 沙箱隔离 |
| Kong | API 网关、限流、认证 |
| OTel + Prometheus + Grafana | 可观测 |
路线图
- Plugin 接口：标准化 Agent 接入协议
- Web Dashboard：任务和资源可视化管理
- 多集群调度
- 生产级安全加固
写在最后
如果你在做一个依赖 AI Agent 的创业产品，最难的部分往往不是 Agent 本身——而是把"我自己用着挺好"变成"让很多人同时用"。
opencode-scale 帮你解决这个中间层的问题。
Apache 2.0 开源，欢迎 Star、Issue、PR。
GitHub: github.com/ssyhape-pix…
