# RFC 0001：天工桌面智能中枢架构与路线图

## 状态
- 状态：提案（Draft）
- 作者：项目维护者与贡献者
- 最后更新：2026-02-12

## 实现对齐（截至 2026-02-12）
- 已实现：基于 Hetu 的最小桌面应用骨架（`main/ui` 分层、样式与资源目录）。
- 已实现：项目愿景、能力边界与阶段路线图已在 `README.md` 明确。
- 未实现：Planner、Agent Runtime、Memory、Tool Executor、模型接入层尚未进入可运行状态。

## 1. 概要

本 RFC 定义 Silent-Tiangong（天工）的产品定位与技术路线：
- 定位为“桌面 AI 自动化中枢”，而非仅对话壳层。
- 在 Hetu 框架上构建可规划、可执行、可扩展的 Agent 系统。
- 采用“单一远程模型供应商”策略，优先保证实现效率、成本可控与安全一致性。

## 2. 背景与动机

桌面端 AI 应用若仅提供对话能力，难以支撑复杂任务自动化。天工希望补齐以下能力缺口：
- 将自然语言目标转化为可执行任务图。
- 在可控权限下执行工具调用、脚本与系统自动化动作。
- 通过可审计运行时实现“可追踪、可回滚、可治理”的 Agent 执行流程。

## 3. 目标与非目标

### 3.1 目标（MUST / SHOULD）

**MUST（第一阶段基线）**
- 提供桌面端原生交互界面（对话、任务状态、执行日志可视化）。
- 建立核心执行链路：`输入 -> 规划 -> 调度 -> 工具执行 -> 结果反馈`。
- 建立最小安全基线：密钥安全存储、工具沙箱、权限控制、执行审计。
- 模型层采用单一远程供应商接入，并提供稳定请求/重试/统计机制。

**SHOULD（后续增强）**
- 支持 Task Graph 与多步骤自动执行。
- 提供 Memory Layer（上下文记忆与长期记忆）。
- 支持插件机制与自动化工作流模板。

### 3.2 非目标（本 RFC 不做）
- 不在首期支持多模型供应商并行路由。
- 不在首期引入分布式多节点调度。
- 不在首期覆盖移动端与 Web 端。

## 4. 总体架构

天工采用分层架构，核心引擎与 UI、框架运行时解耦：

- 桌面层（Desktop UI）
  - 对话交互、任务编排视图、Agent 状态可视化。
- 核心引擎层
  - `Planner`：任务拆解与计划生成（Task Graph）。
  - `Agent Runtime`：生命周期管理、任务调度、执行控制。
  - `Memory Layer`：上下文与长期记忆。
  - `Tool Executor`：工具调用、插件执行、权限治理。
- 框架基础层（Hetu Runtime）
  - 异步执行、事件驱动、资源调度、模块通信。
- 模型层（Remote Model Provider）
  - 单一供应商 API 接入与统一请求接口。

## 5. 模型接入策略（单供应商模式）

模型层由以下模块组成：
- `Model Client`：封装模型 API 请求与响应。
- `Provider Config`：API Key 配置与安全存储。
- `Request Handler`：推理请求编排、结果解析。
- `Error & Retry`：故障分类、重试与降级策略。
- `Usage Monitor`：Token 与成本统计。

设计原则：
- 单接口抽象，避免业务层耦合供应商细节。
- 先稳定再扩展，预留未来替换能力。

## 6. 安全与治理基线

- API Key 本地加密存储。
- 工具执行采用沙箱隔离。
- 文件与命令访问遵循最小权限原则。
- 执行日志全链路可审计。
- 高风险动作要求显式授权。

## 7. 运行机制

1. 用户输入目标或任务。
2. Planner 生成任务计划与执行步骤。
3. Agent Runtime 调度具体执行单元。
4. Tool Executor 调用工具或插件。
5. Remote Model Provider 提供推理能力。
6. 结果回传 UI，并记录可审计日志。

## 8. 里程碑与交付范围

### P1 基础能力
- 单 Agent 对话能力。
- 基础任务执行。
- 工具调用接口（最小集合）。

### P2 任务编排
- Task Graph 支持。
- 多步骤自动执行。
- 状态管理与失败重试。

### P3 系统自动化
- 文件系统操作能力。
- Shell 执行沙箱。
- 权限管理系统。

### P4 扩展能力
- 插件扩展机制。
- 自动化工作流模板。
- 面向 DevOps 的自动化能力。

### P5 自主智能
- Reflection 反思机制。
- 自我优化策略。
- 动态执行优化。

## 9. 验收标准（RFC 采纳条件）

本 RFC 进入“已采纳（Accepted）”前需满足：
- 架构分层与职责边界达成一致。
- 单供应商模型策略与安全边界达成一致。
- 各阶段里程碑具备可验证交付项（至少 P1 范围清晰可落地）。
- 后续 `PLAN.md` / `TODO.md` 与本 RFC 的映射关系明确。

## 10. 与现有文档关系

- 本 RFC 以 `README.md` 的愿景、能力与路线图为事实来源。
- 本 RFC 用于将 README 的叙述性内容转为可执行工程约束。
