agent platform 基础方案
需求分析
一、业务需求
| 编号 | 需求 | 说明 |
|---|---|---|
| BR-01 | 自动化软件开发 | 用户仅需提出需求，平台自动完成编码、测试、PR、部署全流程 |
| BR-02 | 多用户隔离 | 每个用户拥有独立的工作空间，数据与资源互相隔离 |
| BR-03 | 需求到交付闭环 | 从需求输入到可访问的预览环境，全过程无人值守 |
| BR-04 | 质量自保障 | 平台必须自我验证代码质量，测试不通过不允许进入下一环节 |
| BR-05 | 安全合规 | 代码操作和部署操作必须在受控沙箱中执行，避免恶意行为 |
二、功能需求
F1. 任务管理
| 编号 | 需求 | 优先级 |
|---|---|---|
| F1.1 | 用户可提交文本形式的需求描述 | P0 |
| F1.2 | 系统自动将需求拆解为可执行的 Issue / Task | P0 |
| F1.3 | 用户可查看任务执行进度与当前状态 | P0 |
| F1.4 | 系统在整个流程中可通过中断点等待用户审批 | P1 |
F2. Agent 编排
| 编号 | 需求 | 优先级 |
|---|---|---|
| F2.1 | 平台支持多种 Agent 类型（OpenCode、Claude 等） | P0 |
| F2.2 | Agent 可挂载 MCP 工具集和 Skills 技能包 | P0 |
| F2.3 | 支持 Master/Worker/Reviewer 多 Agent 协作模式 | P0 |
| F2.4 | Supervisor Agent 监控协作过程，检测死锁与循环 | P1 |
| F2.5 | 支持自定义 Agent 类型的注册与扩展 | P2 |
F3. 代码实施
| 编号 | 需求 | 优先级 |
|---|---|---|
| F3.1 | 在隔离沙箱中自动 clone 代码仓库 | P0 |
| F3.2 | Agent 通过 LSP 协议进行精准代码修改 | P0 |
| F3.3 | 修改后自动执行 build | P0 |
| F3.4 | 测试失败时自动收集错误堆栈并修复 | P0 |
| F3.5 | 测试通过后自动创建 PR | P0 |
F4. 部署交付
| 编号 | 需求 | 优先级 |
|---|---|---|
| F4.1 | PR 合并后自动部署到预览环境 | P0 |
| F4.2 | 支持 Vercel / Cloudflare Pages / K8s 等多种部署目标 | P1 |
| F4.3 | 部署完成后通知用户访问入口 | P0 |
| F4.4 | HITL 审批节点可阻断或放行部署流程 | P1 |
三、非功能需求
| 编号 | 需求 | 指标 |
|---|---|---|
| NF1 | 隔离性 | 每个任务的执行环境必须物理隔离，沙箱间禁止网络互通 |
| NF2 | 安全性 | 沙箱内禁止访问内网 IP，仅开放白名单 API 域名 |
| NF3 | 可靠性 | 支持状态检查点持久化，运行时崩溃后可恢复任务进度 |
| NF4 | 可观测性 | 任务状态、Agent 行为、工具调用全链路可追踪 |
| NF5 | 扩展性 | Agent 类型和 Skills 技能包可插拔，支持第三方注册 |
| NF6 | 冷启动性能 | 沙箱冷启动时间控制在秒级（Wasm 方案 < 500ms） |
| NF7 | 并发性 | 支持多用户、多任务并行执行，互不干扰 |
四、用户角色
| 角色 | 权限 | 场景 |
|---|---|---|
| 普通用户 | 提交需求、查看任务状态、访问预览环境 | 日常使用平台完成开发任务 |
| 审批者 | 在 HITL 断点处审核代码变更与部署请求 | 需要人工确认的关键节点 |
| 平台管理员 | 管理 Agent 类型、配置 Skills、监控系统状态 | 平台运维与扩展 |
| Agent 开发者 | 注册新的 Agent 类型、开发 MCP 工具、编写 Skills | 平台生态建设 |
五、系统边界
平台系统边界分为内部核心域与外部依赖域两部分。
内部核心域（平台职责范围）
| 子系统 | 职责 | 边界说明 |
|---|---|---|
| 任务管理 | 需求接收、任务拆解、状态跟踪、用户通知 | 对用户：提供 Web UI / API 接口 |
| Agent 编排引擎 | Master Agent 调度、Worker Agent 分配、DAG 规划执行、Supervisor 监控 | 对沙箱：下发执行指令，接收执行结果 |
| 部署网关 | PR 创建、部署触发、预览环境管理 | 对 Git/CI：通过标准化 Webhook/API 集成 |
| 沙箱执行环境 | 代码隔离执行、环境管理、安全策略执行 | 对编排引擎：提供隔离的执行上下文 |
| Workspace | 虚拟文件系统、Git 仓库管理、快照与恢复 | 对 Agent 实例：提供工作目录和运行时 |
外部依赖域（平台调用的外部服务）
| 外部服务 | 用途 | 通信方式 | 方向 |
|---|---|---|---|
| GitHub API | 仓库 clone、PR 创建与合并、Code Review | HTTPS REST | 平台 → GitHub |
| Vercel / Cloudflare | 部署预览环境 | HTTPS REST / Webhook | 平台 → 部署平台 |
| LLM API | Agent 推理（OpenAI / Claude / 开源模型） | HTTPS REST / SSE | 平台 → LLM 服务 |
| Vector DB | RAG 知识检索 | 内部 gRPC / HTTP | 平台内服务间 |
系统交互示意
┌──────────────┐
│ 用户 / 审批者 │
└──────┬───────┘
│ Web UI / API
▼
┌──────────────────────────────────────────────────┐
│ Agent 平台 │
│ │
│ ┌──────────┐ ┌──────────────┐ ┌────────────┐ │
│ │ 任务管理 │ │ Agent │ │ 部署网关 │ │
│ │ │ │ 编排引擎 │ │ │ │
│ └────┬─────┘ └──────┬───────┘ └──────┬─────┘ │
│ │ │ │ │
│ ┌────▼───────────────▼──────────────────▼─────┐ │
│ │ 沙箱执行环境 │ │
│ │ ┌──────────────────────────────────────┐ │ │
│ │ │ Workspace 虚拟文件系统 │ │ │
│ │ │ (git / 环境 / 运行时 / 快照) │ │ │
│ │ └──────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌────────────────┐
│ GitHub │ │ LLM API │ │ Vercel / CF │
│ API │ │ │ │ Pages │
└──────────┘ └──────────┘ └────────────────┘
六、核心用例
用例 1：用户提交任务
主流程：
1. 用户提交自然语言需求
2. 系统触发 Event，启动 Workflow
3. Master Agent 拆解需求为 Issue 列表
4. Runtime 分配沙箱并挂载 Workspace
5. Worker Agent 逐个实现 Issue
6. Review Agent 运行测试并验证
7. 全部通过后提交 PR
8. 自动部署到预览环境
9. 通知用户完成
扩展流程：
3a. 需求模糊 → Master Agent 向用户追问澄清
6a. 测试失败 → 自动修复后重新验证（最多 N 次）
7a. HITL 模式 → 等待审批者确认后继续
用例 2：多 Agent 协作
主流程：
1. Master Agent 将大需求拆分为多个子任务
2. 多个 Worker Agent 并行处理不同子任务
3. Supervisor Agent 监控各 Worker 进度
4. 检测到文件冲突时启用悲观锁
5. 检测到死循环时强制终止并通知 Master
6. Review Agent 统一验证集成结果
技术架构
一、总体架构设计
1.1 架构总览
Agent 平台采用分层架构设计，各层职责清晰、解耦独立：
| 层 | 职责 | 核心组件 |
|---|---|---|
| 接入层 | 用户交互、需求输入、任务管理 | Web UI / API Gateway |
| 编排层 | 需求解析、Agent 调度、工作流编排 | Orchestrator + DAG 规划器 |
| 执行层 | Agent 运行、工具调用、代码实施 | Agent Runtime + MCP Gateway |
| 沙箱层 | 代码执行隔离、环境管理 | K8s Pod / Wasm / Firecracker |
| 基础设施层 | 持久化存储、可观测性、安全 | S3/MinIO + PostgreSQL + Vector DB + ES + Prometheus |
1.2 核心技术栈
| 类别 | 技术选择 | 用途 |
|---|---|---|
| 容器编排 | Kubernetes | 沙箱调度与资源管理 |
| 轻量沙箱 | Wasm / Firecracker | 高性能与高安全场景 |
| 运行时 | Node.js / Python / Rust / Go | Agent 执行环境 |
| 存储 | S3/MinIO + PostgreSQL + Vector DB | 快照持久化、任务状态、RAG 检索 |
| 可观测性 | Elasticsearch + Prometheus/Grafana + Jaeger/Tempo | 日志、指标、链路追踪 |
| 协议层 | MCP (Model Context Protocol) | Agent 工具调用标准化 |
| AI 模型 | 多模型兼容（OpenCode、Claude 等） | Agent 推理与决策 |
| 密钥管理 | Vault | 凭证安全存储与运行时注入 |
二、核心模块设计
2.1 Workspace 管理
Workspace 是每个任务执行时的虚拟工作目录，为 Agent 提供隔离的、可恢复的文件系统环境。
┌──────────────────────────────────────────┐
│ Workspace │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 代码仓库 │ │ 环境配置 │ │
│ │ (Git) │ │ (ENV) │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ ┌────▼──────────────▼─────┐ │
│ │ 运行时环境 │ │
│ │ (Node/Python/Rust/...) │ │
│ └───────────┬─────────────┘ │
│ │ │
│ ┌───────────▼─────────────┐ │
│ │ 用户配置 │ │
│ │ (Git凭证/API Key/权限) │ │
│ └─────────────────────────┘ │
└──────────────────────────────────────────┘
设计要点
| 维度 | 实现方案 |
|---|---|
| 代码库 | 任务启动时 git clone 目标仓库至 Workspace，Agent 在此目录内操作。支持指定分支、commit SHA |
| 环境变量 | 从 Secrets Store（如 Vault）注入 ENV，包括 GitHub Token、API Key、部署凭证。仅对任务内的 Agent 可见 |
| 运行时环境 | 预装多语言运行时（Node.js、Python、Rust、Go 等）。Workspace 内含 .tool-versions 声明项目所需版本，启动时自动配置 |
| 用户配置 | 包括 Git 用户信息、SSH 密钥、npm/cargo 镜像源、IDE 配置等。存储在持久化层，每次任务注入 |
| 快照/恢复 | Workspace 定期生成文件系统快照。任务中断后可从最近快照恢复，Agent 继续工作而非重新开始 |
关键设计决策：Workspace 生命周期
任务创建 ─→ 分配 Workspace ─→ 注入配置 ─→ Agent 工作 ─→ 任务完成 ─→ 归档/销毁
│ │
└── 快照定期写入 S3/EFS ─────┘
│
任务失败恢复时
从最近快照重建
Workspace 采用 Copy-on-Write (CoW) 机制，基于基础镜像快速克隆，冷启动时间 < 2s。
2.2 Agent 管理
Agent 管理模块是整个平台的核心调度层，负责 Agent 的注册、生命周期管理、路由和监控。
Agent 注册与发现
Agent Registry (服务注册表)
│
├── Agent A: OpenCode ── 擅长通用编码
├── Agent B: Claude ── 擅长复杂推理与架构设计
├── Agent C: Custom ── 用户自定义 Agent
│
└── Agent Spec:
├── 能力声明 (支持的 MCP、Skills)
├── 资源配额 (CPU/Mem/并发数)
├── 适用场景标签
└── 基础镜像地址
不同类型的 Agent 注册为独立服务，Master Agent 根据任务特性自动路由。
Agent 生命周期
IDLE ─→ ASSIGNED ─→ RUNNING ─→ COMPLETED
│
├── FAILED ─→ 重试/回滚
└── PAUSED ─→ HITL 等待审批
- IDLE：Agent 空闲待命中
- ASSIGNED：Master 分配任务，注入 Task Spec
- RUNNING：执行中，持续上报心跳和进度
- COMPLETED：任务完成，释放资源
- FAILED：自动重试（可配置次数），超出则通知人工介入
Agent 路由策略
DAG-based 规划器策略：
- Master Agent 解析任务后生成 Task DAG（有向无环图）
- 每个 DAG 节点标注所需能力标签（如
code-gen,test-run,debug） - 调度器匹配 Agent 的 Spec，选择最优 Agent
- 支持优先级调度和负载均衡
2.3 MCP 协议层
MCP 是 Agent 与外部工具交互的标准协议层。工具集成设计—— 通过 shell、编辑器、浏览器三大工具与环境交互——本平台通过 MCP 实现标准化工具扩展。
MCP 架构
Agent ──→ MCP Gateway ──→ MCP Server A (文件操作)
├── MCP Server B (代码搜索)
├── MCP Server C (数据库查询)
├── MCP Server D (API 调用)
└── MCP Server E (浏览器自动化)
MCP 核心设计
| 模块 | 说明 |
|---|---|
| MCP Gateway | 统一的工具调用入口，负责认证、限流、路由、日志 |
| 工具注册 | 每个 MCP Server 声明其 Tools（名称、输入 Schema、输出格式） |
| 权限控制 | 每个 Tool 有独立权限声明，Agent 动态获取授权 |
| 调用审计 | 所有工具调用全量日志，支持回放审计 |
| 超时与熔断 | 每个 Tool 有最大执行时间，超时自动熔断 |
2.4 Skills 系统
Skills 是 Agent 的能力增强包，封装特定领域的知识、工作流和最佳实践。
Skills 分类
Skills Repository
│
├── 基础能力
│ ├── git-workflow (Git 操作流)
│ ├── code-style (代码规范检查)
│ └── test-pattern (测试编写模板)
│
├── 框架技能
│ ├── react-patterns (React 最佳实践)
│ ├── rust-idioms (Rust 习语)
│ └── python-packaging(Python 打包)
│
└── 领域技能
│ ├── security-audit (安全审计)
│ ├── perf-optimize (性能优化)
│ └── api-design (API 设计模式)
Skills 加载机制
Agent 启动 → 加载基础 Skills → Master 分析任务 → 按需加载领域 Skills
│
Skills Chain 串联执行
每个 Skill 包含：
- Trigger 条件：什么场景下激活（正则匹配或语义匹配）
- Instructions：行为指导（系统提示词片段）
- Tools：关联的 MCP 工具
- Checklist：输出验证清单
Skills 可在任务执行过程中动态加载和卸载，避免上下文窗口膨胀
2.5 沙箱执行环境
Sandbox 是 Agent 执行代码的物理隔离环境，是平台安全性的基石。
沙箱架构
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 任务 A │ │ 任务 B │ │ 任务 C │
│ Sandbox │ │ Sandbox │ │ Sandbox │
│ ┌──────┐ │ │ ┌──────┐ │ │ ┌──────┐ │
│ │ Agent│ │ │ │ Agent│ │ │ │ Agent│ │
│ │Shell │ │ │ │Shell │ │ │ │Shell │ │
│ │Editor│ │ │ │Editor│ │ │ │Editor│ │
│ │MCP │ │ │ │MCP │ │ │ │MCP │ │
│ └──────┘ │ │ └──────┘ │ │ └──────┘ │
└──────────┘ └──────────┘ └──────────┘
│ │ │
└──────────────┼──────────────┘
│
┌──────▼──────┐
│ K8s Pod / │
│ Wasm 实例 │
└─────────────┘
沙箱实现方案对比
| 方案 | 隔离级别 | 冷启动 | 资源开销 | 适用场景 |
|---|---|---|---|---|
| K8s Pod | 完整 OS 级 | ~5-10s | 高 | 复杂项目、多语言环境 |
| Wasm 沙箱 | 进程级 | < 500ms | 低 | 轻量任务、高并发 |
| Firecracker 微VM | 硬件级 | ~3-5s | 中 | 高安全场景 |
本平台采用分级沙箱策略：
- 大多数任务使用 K8s Pod（通用型）
- 简单/原子任务使用 Wasm 沙箱（高性能）
- 高敏感任务可选 Firecracker 微VM（强隔离）
沙箱安全策略
| 策略 | 说明 |
|---|---|
| 网络隔离 | 禁止内网访问，仅开放白名单 API 域名 |
| 文件系统隔离 | OverlayFS，任务间文件不可见 |
| 资源配额 | CPU/Memory/Disk 硬限制 |
| 超时控制 | 单任务最长执行时间可配置 |
| 网络白名单 | 仅 GitHub、npm、Docker Registry 等必需的域名可通过 |
2.6 编排引擎
Agent 编排是平台最核心的能力层，负责将需求转化为可执行的工作流，并确保无人值守下的任务必完成。
编排架构概览
用户需求
│
▼
┌──────────────────┐
│ Orchestrator │ ← 核心编排引擎
│ (DAG 规划器) │
└──────┬───────────┘
│
├──→ Task DAG (有向无环图)
│
├──→ Agent Assignment (Agent 分配)
│
├──→ Execution Plan (执行计划)
│
└──→ State Machine (状态机)
│
▼
┌──────────┐
│ Checkpoint│ ← 每阶段落地
│ 持久化 │
└──────────┘
│
故障时恢复
无人接管设计（Mission Assurance）
无人接管（Unattended Operation）是本平台的核心差异化能力。系统必须保证：
- 任务自治性：Agent 在无人工干预的情况下独立完成从编码到部署的全流程
- 异常自愈：遇到错误自动诊断和修复，不需要人工介入
- 容错恢复：任何组件故障不影响任务最终完成
任务必完成机制
┌────────────────────────┐
│ Orchestrator │
│ │
│ Task DAG 设计原则： │
│ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │
│ │S1│→│S2│→│S3│→│S4│ │
│ └──┘ └──┘ └──┘ └──┘ │
│ Each step has: │
│ • 主路径 (happy path) │
│ • 降级路径 (fallback) │
│ • 重试策略 (retry) │
└────────────────────────┘
每个 DAG 节点内置三重保障：
| 层级 | 机制 | 说明 |
|---|---|---|
| L1 重试 | 自动重试（3 次） | 临时性错误（网络抖动、超时）自动重试 |
| L2 降级 | 替换方案 | 当前路径失败后切换备用路径（如 K8s 失败→Wasm） |
| L3 人工兜底 | 通知+等待 | 所有自动策略耗尽后，通知负责人并等待指令 |
每个 DAG 节点采用 "Plan-Do-Verify" 三阶段循环模式。
多 Agent 协作模型
并行 Agent 架构，本平台支持：
Master Agent
│ │ │
┌─────┘ │ └─────┐
▼ ▼ ▼
Worker A Worker B Worker C
(模块A) (模块B) (测试)
│ │ │
└──────────┼──────────┘
▼
Review Agent
│
┌────┴────┐
▼ ▼
PR 提交 Superviosr
│
┌─────┴──────┐
▼ ▼
死锁检测 循环检测
| 角色 | 职责 |
|---|---|
| Master Agent | 需求解析、Task DAG 构建、子任务分派、结果汇总 |
| Worker Agent | 具体代码实现、测试编写、Bug 修复 |
| Review Agent | 代码审查、测试验证、质量标准把控 |
| Supervisor Agent | 监控 Agent 心跳、检测死锁/循环、资源调度 |
部署到生产环境的无人值守闭环
需求输入
│
▼
┌──────────────────────────────────────┐
│ 无人值守闭环 │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌───┐ │
│ │ 规划 │→│ 编码 │→│ 验证 │→│部署│ │
│ │DAG │ │LSP │ │Test │ │CI │ │
│ └──┬───┘ └──┬───┘ └──┬───┘ └─┬─┘ │
│ │ │ │ │ │
│ └────────┴────────┴────────┘ │
│ Checkpoint 持久化 │
└──────────────────────────────────────┘
│
▼
任务完成 / 通知用户
只有在以下情况下才需人工介入：
- DAG 所有路径均失败（L1+L2 耗尽）
- 安全策略触发（如检测到高危操作）
- HITL 节点显式配置（如生产环境部署审批）
三、数据流与状态管理
3.1 任务生命周期
任务从创建到完成经历以下完整生命周期：
需求提交 ─→ DAG 规划 ─→ 编码实施 ─→ 测试验证 ─→ PR 提交 ─→ 部署交付 ─→ 通知完成
│ │ │ │ │ │
└───────────┴───────────┴───────────┴──────────┴──────────┘
每阶段可回退重试
每个阶段由 Orchestrator 驱动，通过 DAG 状态机确保流程正确性。
3.2 Checkpoint 与失败恢复
将 Agent 的工作状态持久化，确保任务可恢复：
Agent 思考链路 (Thought Chain)
Agent 决策日志 (Decision Log)
文件系统快照 (FS Snapshot)
│
▼
┌─────────────┐
│ Checkpoint │
│ 持久化层 │
│ │
│ • S3/MinIO │
│ • PostgreSQL │
│ • Vector DB │
└─────────────┘
Checkpoint 策略：
| 触发条件 | 持久化内容 | 用途 |
|---|---|---|
| 每完成一个 DAG 节点 | 文件系统快照 + 任务状态 | 节点级恢复 |
| 每 5 分钟（定时） | Agent 思考链路 + 决策日志 | 长时间运行恢复 |
| Agent 心跳超时 | 最近一次完整 Checkpoint | 崩溃恢复 |
| 手动触发 | 全量快照 | HITL 断点保存 |
失败恢复流程：
Runtime 崩溃或 Agent 失联
│
▼
Orchestrator 检测到心跳丢失
│
▼
加载最近 Checkpoint
│
▼
重建 Workspace（从快照恢复文件系统）
│
▼
拉起新 Agent，注入历史上下文
│
▼
从断点继续执行
这种能力构成了平台的可恢复执行引擎。
四、可观测性设计
4.1 监控数据流
Agent ──→ 行为日志 ──→ Log Collector ──→ Elasticsearch
│ │
├──→ 性能指标 ──→ Metrics Collector ──→ Prometheus
│ │
├──→ 工具调用 ──→ Audit Log ──→ S3/对象存储
│ │
└──→ 决策链路 ──→ Trace Collector ──→ Jaeger/Tempo
4.2 四维监控体系
| 维度 | 采集内容 | 存储 | 用途 |
|---|---|---|---|
| Logs（日志） | Agent stdout/stderr、工具调用输入输出、系统事件 | Elasticsearch | 问题排查、行为分析 |
| Metrics（指标） | 任务执行时间、Agent 响应耗时、沙箱资源利用率、工具调用频次 | Prometheus + Grafana | 性能监控、容量规划 |
| Traces（链路） | 任务 DAG 中每个节点的执行链、跨 Agent 调用关系 | Jaeger / Tempo | 分布式追踪、瓶颈分析 |
| Session（会话） | Agent 每一步操作的时间线记录、决策上下文 | S3 + PostgreSQL | 审计回放、调试复现 |
4.3 会话时间线 (Session Timeline)
每个任务生成一条完整的时间线，记录 Agent 的所有操作：
时间线 T0: Master Agent 解析需求，生成 DAG
时间线 T1: Worker A 开始编码
时间线 T2: Worker A 调用 file-write MCP
时间线 T3: Worker A 调用 shell-exec MCP (npm test)
时间线 T4: Test 失败，Worker A 读去错误日志
时间线 T5: Worker A 修复代码，重新验证
时间线 T6: Review Agent 验证通过
时间线 T7: PR 提交成功
每条时间线记录包含：
- Timestamp：操作时间
- Action：执行的操作类型
- Input/Output：调用参数和返回结果
- Token Cost：LLM 消耗
- Duration：操作耗时
- Decision：Agent 在该节点的决策依据
本平台的 Session Timeline 支持按 DAG 节点筛选和聚合。
4.4 告警体系
| 告警 | 条件 | 动作 |
|---|---|---|
| Agent 失联 | 心跳超过 30s 未上报 | 自动拉起新实例，从 Checkpoint 恢复 |
| 任务超时 | 超过预估时间的 3 倍 | 通知负责人 |
| 工具调用失败率 > 20% | 连续 10 次工具调用中 3 次失败 | 升级 Supervisor 介入 |
| 沙箱资源超限 | CPU/Memory 超过配额 90% | 自动扩容或限流 |
五、安全设计
本平台的安全设计贯穿沙箱隔离、网络安全、凭证管理和审计追溯四个维度。
| 维度 | 策略 | 说明 |
|---|---|---|
| 沙箱隔离 | OverlayFS 文件系统隔离 + 物理级沙箱 | 任务间文件、进程完全隔离，不可互相访问 |
| 网络安全 | 网络白名单 + 内网 IP 禁止访问 | 仅开放 GitHub、npm、Docker Registry 等必需域名 |
| 资源管控 | CPU/Memory/Disk 硬限制 + 超时自毁 | 防止资源滥用，单任务最长执行时间可配置 |
| 凭证管理 | Secrets Store（Vault）注入 | 凭证仅对当前任务内 Agent 可见，任务结束后自动销毁 |
| 权限控制 | MCP 工具级权限声明 + Agent 动态授权 | 每个工具调用有独立权限校验 |
| 审计追溯 | 全链路日志 + Session Timeline 回放 | 所有操作可追溯、可审计、可回放 |
本系统对业务已有问题的解决方式
本章从业务问题出发，阐述本平台如何系统性地解决已有业务难题。
一、业务问题到技术方案的映射
BR-01：自动化软件开发（用户提需求，平台自动完成）
| 问题维度 | 本平台解决方案 | 对应模块 |
|---|---|---|
| 需求理解 | Master Agent 拆解需求为 Issue，DAG 规划执行路径 | 编排层、Agent 基础层 |
| 代码编写 | Worker Agent 在沙箱中通过 LSP 精准修改代码 | Agent 基础层、Sandbox |
| 质量保障 | 自我校验循环：Build → Test → 修复 → 重验 | 编排层（自愈循环） |
| PR 提交 | Review Agent 验证通过后自动创建 PR | 编排层、监控链路 |
| 部署交付 | 自动部署到预览环境，通知用户访问入口 | 编排层（部署集成） |
BR-02：多用户隔离
| 问题 | 解法 |
|---|---|
| 用户数据互相可见 | 每个用户独立 Workspace，文件系统 OverlayFS 隔离 |
| 任务互相干扰 | 每个任务分配独立 K8s Pod 或 Wasm 沙箱，随用随毁 |
| 凭证泄露风险 | 从 Secrets Store 注入，仅对当前任务内 Agent 可见 |
BR-03：质量自保障（测试不通过不允许进入下一环节）
本平台的质量保障体系融合了三层防护：
| 防护层 | 机制 |
|---|---|
| L0：反馈左移 | 在编码阶段就执行 lint + 类型检查，不通过则原地修复 |
| L1：确定性校验 | Build 失败 → 自动收集错误堆栈 → LLM 分析并修复 → 重验 |
| L2：独立评估 | Review Agent 从代码质量、测试覆盖率、安全合规等维度评估 |
| L3：一次修复机会 | CI 失败后仅给一次自动修复机会，再次失败则通知人工 |
反馈左移（Shift-Left）管道：
Lint 检查 ──→ 类型检查 ──→ 单元测试 ──→ 集成测试 ──→ CI 验证
↑ ↑ ↑ ↑ ↑
│ │ │ │ │
└────── 任一环节失败，立即停止后续，进入修复循环 ──────┘
BR-04：安全合规
| 安全维度 | 方案 |
|---|---|
| 代码执行 | 沙箱内 OverlayFS 文件隔离，物理级隔离 |
| 网络访问 | 白名单域名，禁止内网 IP 访问 |
| 部署操作 | HITL 断点审批，高危操作需人工确认 |
| 凭证管理 | Secrets Store 注入，仅任务内 Agent 可见 |
| 审计追溯 | 全链路日志 + Session Timeline 回放 |
二、无人值守的核心挑战与三层兜底
无人值守（Unattended Operation）是本平台的核心设计目标。本平台构建了三层兜底体系：
┌──────────────────────┐
│ 评估层兜底 │
│ │
│ Agent 跑偏写了无关 │
│ 代码 → 评估不通过 │
│ → 评估理由重定向方向 │
└──────────────────────┘
▲
┌────────────┴──────────┐
│ │
┌────────┴──────────┐ ┌─────────┴─────────┐
│ 结构层兜底 │ │ 编排层兜底 │
│ │ │ │
│ LLM 节点无限循环 → │ │ Agent 进程挂掉 → │
│ 确定性节点卡住流程 │ │ Checkpoint 恢复 │
└───────────────────┘ └───────────────────┘
| 失败模式 | 兜底机制 |
|---|---|
| Agent 擅自修改非任务范围的代码 | 评估层不通过，评估理由重新约束范围 |
| Agent 陷入无限循环 | 结构层中确定性节点（lint/test）强制中断 |
| Agent 进程崩溃 | Checkpoint 持久化 + 自动恢复 |
| LLM 编码出现逻辑错误 | 自我校验循环发现 → 自动修复（一次机会） |
| Sandbox 被恶意利用 | 最小权限 + 网络白名单 + 超时自毁 |
补充：成本控制机制
| 控制项 | 策略 |
|---|---|
| CI 修复次数 | 每个 CI 失败仅自动修复 1 次，再次失败通知人工 |
| Token 预算 | 每个 LLM 节点设置 maxTokens，超限自动截断 |
| 评估化费 | Review Agent 使用轻量模型，评估轮次的 token 成本 < 主模型的 5% |
| 并行度限制 | 单任务最大 Worker 数可配置，防止资源失控 |
附录
系统架构图（主模块简易版）
任务流转图
同产品调研
以下为市场上与本平台理念相近的平台级产品（具备端到端能力、提供托管服务或在远端隔离环境中运行，非本地工具或 IDE 插件）。
| 产品 | 厂商 | 定位与架构 | 沙箱 | 部署 | 与本平台核心差异 |
|---|---|---|---|---|---|
| Devin | Cognition | 首个 AI 软件工程师。单 Agent 架构，拥有独立 IDE/终端/浏览器，端到端完成开发 | ✅ 云端隔离工作区 | ✅ 内置 | Devin 是单 Agent 独立工作，本平台采用 Master/Worker/Reviewer 多 Agent 协作，任务可分解并行 |
| Copilot Workspace | GitHub (Microsoft) | Issue 驱动的 AI 开发环境。用户描述需求，AI 生成方案并创建 PR，但需人工审核编辑 | ❌ 无隔离沙箱 | ❌ 仅到 PR | 定位是开发辅助而非全自动流水线，仍需开发者深度参与；本平台追求完全无人值守闭环 |
| OpenHands | 社区开源 | 开源自主 AI 开发 Agent。Docker 沙箱内完成编码、网页浏览等任务。单 Agent 设计 | ✅ Docker 沙箱 | ❌ 无内置部署 | 开源生态最接近的项目，但单 Agent + 无部署管线；本平台增加编排层、Checkpoint 恢复和部署网关 |
| Replit Agent | Replit | 浏览器内 AI 全栈开发。描述需求→生成代码→部署到 Replit 托管 | ✅ 内置沙箱 | ✅ Replit 平台 | 单 Agent 架构，部署锁定在 Replit；本平台 Agent 编排更灵活，部署目标支持 Vercel/Cloudflare/K8s |
| Bolt.new | StackBlitz | 浏览器内全栈 Web 应用生成。输入提示词即可生成并预览可运行应用 | ✅ 浏览器沙箱 | ✅ StackBlitz | 侧重快速原型，不涉及 Git 管理、CI/CD、多 Agent；本平台面向真实工程项目的完整开发流程 |
| Factory | Factory AI | 多 Agent 编码平台。支持沙箱化执行、多 Agent 协调、自动创建 PR | ✅ 沙箱环境 | ✅ 自动 PR | 架构最相似。差异在于编排层：本平台内置 DAG 规划器和 Checkpoint 恢复，长时间任务容错更强 |
| v0.dev | Vercel | AI UI 组件生成工具。自然语言描述界面，直接生成 React + Tailwind 代码并实时预览 | ✅ 云端沙箱 | ✅ Vercel | 定位于前端 UI 单组件生成，不涉及完整项目开发、测试、CI/CD；本平台覆盖全生命周期 |
| Vercel AI SDK | Vercel | 开源 AI 应用框架。提供流式响应、Tool Calling、Agent 编排等能力 | ❌ 框架层 | ❌ 需自行集成 | AI SDK 是开发框架，需开发者自行集成沙箱和部署管线；本平台是完整托管平台，内置隔离执行和部署 |
| Claude Code | Anthropic | 终端原生 AI 编码 Agent。通过 CLI 在本地读写文件、运行命令、使用 MCP 工具 | ❌ 本地执行 | ❌ 无部署 | 本地单 Agent 工具，依赖开发者手动启动监督；本平台是多 Agent 托管服务，支持无人值守闭环和 Checkpoint 恢复 |
| Claude + MCP | Anthropic | Model Context Protocol，Claude 连接外部工具和数据的标准化协议 | — | — | 本平台 MCP 设计吸收相同理念，但 MCP Gateway 增加了认证、限流、审计、熔断等企业级治理能力 |
| Claude Max | Anthropic | 企业增强版，更大上下文窗口和更长任务执行 | — | — | Claude Max 通过增大上下文提升能力；本平台通过 Checkpoint 持久化 + 多 Agent 分治实现无限任务时长 |