docs: 里程碑拆分、Agnet 集成 API 设计；官网增强；愿景与 README 称谓更新
- docs/milestones: M1～M5 交付里程碑与索引 - docs/integration: Agnet 权限、隔离、编排与可视化接口草案 - website: 能力矩阵、优势对比、典型场景与样式 - vision/README/new-api/cc-haha: Heicode Manager / 客户端命名与愿景收敛 Made-with: Cursor
This commit is contained in:
gongzhiyong
@@ -1,21 +1,24 @@
|
||||
# Heicode
|
||||
|
||||
Heicode 是一个**面向团队的智能体驱动软件交付**工作区：把 **改造后的大模型网关（New API / TaijiAICloud）**、**终端与桌面上的智能体编程客户端（cc-haha）**，以及 **Agnet 平台上的子智能体团队** 串成一条从想法到上线、再到运维迭代的闭环。
|
||||
Heicode 面向**多人协作、可追溯交付**的软件团队：把需求对齐、实现、验证、发布和持续运营连成一条少断层的链路，并用**可编排的智能体角色**承接其中可标准化的环节——强调「能复盘、能审计、能按团队规模裁剪」，而不是罗列某一家的工具栈。
|
||||
|
||||
## 这个仓库里有什么
|
||||
下面的目录表仅供工程查阅；**不代表对外产品承诺、路线图或你必须采用的集成方式。**
|
||||
|
||||
| 目录 | 作用 |
|
||||
|------|------|
|
||||
| `cc-haha/` | **CLI / 本地服务 / Desktop（Tauri）**；类 **Claude Code** 体验，与平台登录、模型发现对齐。 |
|
||||
| `new-api/` | 网关与运营能力（渠道、计费、鉴权、中继等），含 HeiCode 浏览器登录等适配。 |
|
||||
| `website/` | 产品说明**静态官网**（可用 Docker 本地预览）。 |
|
||||
| `_all-in-one-upload/` | 历史或打包上传相关目录（按需维护）。 |
|
||||
## 这个仓库里有什么（工程布局）
|
||||
|
||||
| 目录 | 大致含义 |
|
||||
|------|----------|
|
||||
| `cc-haha/` | **Heicode**（终端与桌面客户端及本地服务；此为源码目录名）。 |
|
||||
| `new-api/` | **Heicode Manager**（网关与管理控制台服务端；此为源码目录名）。 |
|
||||
| `website/` | 产品介绍的静态页面（可本地 Docker 预览）。 |
|
||||
| `docs/` | 愿景与范式；**[`docs/milestones/`](./docs/milestones/README.md)** 交付里程碑；**[`docs/integration/`](./docs/integration/README.md)** Agnet 等平台接口设计。 |
|
||||
| `_all-in-one-upload/` | 历史或打包目录（按需维护）。 |
|
||||
|
||||
## 产品在解决什么问题
|
||||
|
||||
- **自动化开发范式**：覆盖需求、实现、测试、**多云部署**、运维与迭代，以及 **瀑布 / 敏捷** 子智能体团队模板（详见 `docs/vision-heicode-full-stack-agentic-dev.md`）。
|
||||
- **单仓交付**：客户端与网关同步迭代，减少版本错位；发版时同一标签回归登录、模型拉取、对话等主线。
|
||||
- **可审计交付**：多智能体协作、产品文档、开发日志与发布版本关联。
|
||||
- **协作范式**：把瀑布 / 敏捷下的角色分工落到可复述的闸门与智能体承接边界（**方向与原则**见 `docs/vision-heicode-full-stack-agentic-dev.md`；编队明细在文档附录）。
|
||||
- **交付可追溯**：文档、沟通与变更尽量与版本、发布对齐，便于复盘与合规。
|
||||
- **工程上**：同一仓库便于客户端与服务端**同步发版、统一回归**，减少「谁和谁版本对不上」的摩擦。
|
||||
|
||||
## 详细愿景与范式
|
||||
|
||||
@@ -24,10 +27,10 @@ Heicode 是一个**面向团队的智能体驱动软件交付**工作区：把 *
|
||||
## 快速启动（开发联调）
|
||||
|
||||
```bash
|
||||
# 根依赖（若使用 bun 工作区）
|
||||
# 根依赖（Bun monorepo 根目录）
|
||||
bun install
|
||||
|
||||
# HeiCode 本地服务
|
||||
# Heicode 客户端本地服务（目录 cc-haha）
|
||||
cd cc-haha
|
||||
bun run src/server/index.ts
|
||||
|
||||
@@ -42,12 +45,12 @@ bun run tauri dev
|
||||
HEICODE_TAIJIAICLOUD_BASE_URL=http://localhost:3000 bun run src/server/index.ts
|
||||
```
|
||||
|
||||
`new-api` 中与 HeiCode 登录相关的路由（最小集，以实际代码为准）：
|
||||
**Heicode Manager**（`new-api/`）中与 Heicode 登录相关的路由（最小集，以实际代码为准）：
|
||||
|
||||
- `GET /heicode/oauth/authorize`
|
||||
- `GET /heicode/oauth/session`
|
||||
|
||||
平台侧能力还包括模型发现（如 `GET /v1/models`）与 Anthropic Messages 兼容入口等，详见 `new-api` 与 `cc-haha` 各自 README。
|
||||
平台侧能力还包括模型发现（如 `GET /v1/models`）与 Anthropic Messages 兼容入口等，详见 **Heicode Manager**（`new-api/`）与 **Heicode 客户端**（`cc-haha/`）各自 README。
|
||||
|
||||
## 官网静态站（本地 Docker）
|
||||
|
||||
@@ -73,4 +76,4 @@ docker compose up --build
|
||||
|
||||
## 许可证
|
||||
|
||||
各子项目许可证见各子目录内 `LICENSE`（例如 `new-api` 侧常见为 AGPLv3）。
|
||||
各子项目许可证见各子目录内 `LICENSE`（例如 Heicode Manager / `new-api/` 侧常见为 AGPLv3）。
|
||||
|
||||
+3
-3
@@ -1,6 +1,6 @@
|
||||
# HeiCode Client (`cc-haha`)
|
||||
# Heicode（源码目录 `cc-haha`）
|
||||
|
||||
HeiCode 客户端工程，目标是把 “Claude Code 使用体验” 产品化，并对接企业模型平台。
|
||||
本目录实现 **Heicode** 终端与桌面客户端（CLI + Desktop + 本地服务）。目录名 `cc-haha` 为历史工程名；对外产品与文档统一称 **Heicode**（与 **Heicode Manager** 区分时亦称「Heicode 客户端」）。目标是把终端编程体验产品化，并对接企业模型平台。
|
||||
|
||||
## 你能得到什么
|
||||
|
||||
@@ -60,7 +60,7 @@ HEICODE_TAIJIAICLOUD_BASE_URL=http://localhost:3000 bun run src/server/index.ts
|
||||
|
||||
## 已完成改造（本分支）
|
||||
|
||||
- 品牌统一为 `HeiCode`
|
||||
- 品牌统一为 `Heicode`
|
||||
- 登录页去除 API Key 输入区域及相关提示文案
|
||||
- 设置页移除 Providers 菜单
|
||||
- 侧边栏和 About 移除 GitHub 链接与图标
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
# 集成与平台接口
|
||||
|
||||
| 文档 | 说明 |
|
||||
|------|------|
|
||||
| [agnet-platform-api-design.md](./agnet-platform-api-design.md) | **Agnet 平台**对 Heicode 暴露的 API 设计：身份、RBAC、多租户隔离、编排、运行态、事件流、审计。 |
|
||||
|
||||
**里程碑**（何时落地哪些能力）见 [`../milestones/README.md`](../milestones/README.md)。
|
||||
@@ -0,0 +1,255 @@
|
||||
# Agnet 平台 ↔ Heicode 集成接口设计（草案）
|
||||
|
||||
本文描述 **Agnet 平台**应向 **Heicode（Manager / 客户端 / 自动化服务）** 暴露的 **控制面、数据面隔离、权限模型与可视化/事件接口**。
|
||||
路径、字段名为 **设计意图**；落地时可等价映射为 gRPC 或 GraphQL，但**语义与隔离边界**应保持一致。
|
||||
|
||||
**关联里程碑**：[`../milestones/`](../milestones/README.md) 中 M3～M5。
|
||||
|
||||
---
|
||||
|
||||
## 1. 设计目标
|
||||
|
||||
| 目标 | 说明 |
|
||||
|------|------|
|
||||
| **权界清晰** | 调用方身份可解析为「谁、属于哪一租户、具备何种角色」 |
|
||||
| **租户默认隔离** | 无显式授权则不可读他租户资源 |
|
||||
| **有状态可观测** | 执行单元生命周期与运行态可通过 API + 事件流呈现 |
|
||||
| **可演进** | 资源带 `api_version` / schema 版本；破坏性变更走新版本路径 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 身份与调用方式
|
||||
|
||||
### 2.1 服务间（推荐生产）
|
||||
|
||||
- **Heicode Manager** 使用 **服务账号** 调用 Agnet：`Authorization: Bearer <m2m_jwt>`。
|
||||
- JWT 声明至少包含：`sub`（服务主体）、`tenant_id`（若适用）、`scope`（见 §3）、`exp`。
|
||||
- Agnet **校验Issuer**（Manager 签发的委托令牌 **或** Agnet 签发的服务令牌，二选一应文档化）。
|
||||
|
||||
### 2.2 用户委派（可选）
|
||||
|
||||
- 终端用户经 Heicode OAuth 后，Manager 代发 **用户委派令牌** 访问 Agnet 只读/受限写接口；Claims 含 `user_id`、`org_id`、`roles`。
|
||||
|
||||
### 2.3 必需传递的上下文头（建议）
|
||||
|
||||
| Header | 必填 | 说明 |
|
||||
|--------|------|------|
|
||||
| `Authorization` | 是 | Bearer Token |
|
||||
| `X-Request-Id` | 强建议 | 全链路追踪 |
|
||||
| `X-Tenant-Id` | 多租户时必填 | 顶层隔离键；与 Token 声明互相校验，不一致则 **401** |
|
||||
| `X-Org-Id` | 视模型 | 组织内子划分 |
|
||||
| `X-Project-Id` | 编排相关 API 建议 | 资源挂载点 |
|
||||
| `X-Environment` | 可选 | `dev` / `staging` / `prod` |
|
||||
| `X-Heicode-Correlation-Id` | 强建议 | 与 Manager 审计日志关联 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 权限模型（RBAC 概要）
|
||||
|
||||
### 3.1 角色（示例命名，可映射贵司 IAM）
|
||||
|
||||
| 角色 | 典型 scope | 说明 |
|
||||
|------|------------|------|
|
||||
| `agnet:platform_admin` | 全租户元数据、调试接口 | 极少人数 |
|
||||
| `agnet:org_admin` | 本租户内项目、编队、凭据绑定 | |
|
||||
| `agnet:project_editor` | 指定项目下部署/停止/读状态 | |
|
||||
| `agnet:operator_readonly` | 读状态、读事件、读审计 | |
|
||||
| `agnet:auditor` | 仅审计与导出 | |
|
||||
|
||||
### 3.2 权限分离原则
|
||||
|
||||
- **控制面**（部署/改策略）与 **观测面**（读指标）可分角色授予。
|
||||
- **凭据类写操作**（绑定 Git Token、云 SA）单独 scope：`agnet:credential:write`。
|
||||
- **拒绝隐式升级**：只读 Token **不得**通过查询参数绕过 body 校验升格为写操作。
|
||||
|
||||
---
|
||||
|
||||
## 4. 多租户与数据隔离
|
||||
|
||||
### 4.1 隔离键层级
|
||||
|
||||
```
|
||||
Tenant（租户）
|
||||
└── Organization（可选）
|
||||
└── Project（项目）
|
||||
└── Deployment（一次编队部署）
|
||||
└── AgentInstance（执行单元实例）
|
||||
```
|
||||
|
||||
- 所有持久化资源 **必须**带 `tenant_id`；API 默认按 Token + Header 解析租户并 **强制过滤**。
|
||||
- **跨租户引用**：禁止在 URL 中使用「全局唯一但不带租户前缀」的裸 ID；推荐 `tenant_scoped_id` 或 `(tenant_id, local_id)` 复合。
|
||||
|
||||
### 4.2 数据面实现选项（择一或组合）
|
||||
|
||||
| 方案 | 适用 | Agnet 侧责任 |
|
||||
|------|------|----------------|
|
||||
| **逻辑隔离** | 快速迭代 | 每张业务表 `tenant_id` + RLS 或统一拦截器 |
|
||||
| **Schema 分库** | 强合规 | 每租户独立 schema / database |
|
||||
| **命名空间隔离（K8s）** | 执行单元运行时 | 编排器按租户分配 NS 与网络策略 |
|
||||
|
||||
### 4.3 负例测试（验收必备）
|
||||
|
||||
- 使用 Tenant A 的凭证访问 Tenant B 的 `deployment_id` → **403** 或 **404（对外不区分）**。
|
||||
- 列表接口默认 **不得**返回其他租户资源，即使 ID 被猜到。
|
||||
|
||||
---
|
||||
|
||||
## 5. 编排与控制面 API（M3）
|
||||
|
||||
> 下列 REST 仅为示意；实际路径前缀可为 `/api/v1` 或 `/agnet/v1`。
|
||||
|
||||
### 5.1 部署编队
|
||||
|
||||
`POST /deployments`
|
||||
|
||||
**请求体（示意）**
|
||||
|
||||
```json
|
||||
{
|
||||
"project_id": "prj_xxx",
|
||||
"template": "agile_min",
|
||||
"correlation_id": "mgr_cor_abc",
|
||||
"parameters": {
|
||||
"unit_overrides": {}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**响应**
|
||||
|
||||
```json
|
||||
{
|
||||
"deployment_id": "dep_yyy",
|
||||
"status": "accepted",
|
||||
"agent_instances": [
|
||||
{ "instance_id": "agi_1", "role": "AG-PO", "phase": "pending" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 查询部署
|
||||
|
||||
- `GET /deployments/{deployment_id}` —— 含租户校验。
|
||||
- `POST /deployments/{deployment_id}:stop` —— 优雅停止。
|
||||
|
||||
### 5.3 Webhook / 回调（Agnet → Heicode）
|
||||
|
||||
- Manager 注册 URL：`POST /integration/heicode/callback-config`（或由 Agnet 控制台配置）。
|
||||
- 负载含：`deployment_id`、`instance_id`、`event_type`、`payload`、`occurred_at`、`signature`。
|
||||
|
||||
**签名**：HMAC-SHA256（共享密钥或 JWKS）；拒绝无签名请求。
|
||||
|
||||
---
|
||||
|
||||
## 6. 运行态与可视化 API（M5）
|
||||
|
||||
### 6.1 实例快照
|
||||
|
||||
`GET /agent-instances/{instance_id}`
|
||||
|
||||
**响应字段（示意）**
|
||||
|
||||
```json
|
||||
{
|
||||
"instance_id": "agi_1",
|
||||
"deployment_id": "dep_yyy",
|
||||
"tenant_id": "ten_1",
|
||||
"role": "AG-PO",
|
||||
"phase": "running",
|
||||
"health": "ok",
|
||||
"last_heartbeat_at": "2026-04-30T12:00:00Z",
|
||||
"queue_depth": 2,
|
||||
"current_task": { "id": "task_7", "summary": "Review API draft" },
|
||||
"resource": { "cpu_pct": 12, "mem_mb": 512 },
|
||||
"errors_recent": [{ "at": "...", "code": "UPSTREAM_TIMEOUT", "message": "..." }]
|
||||
}
|
||||
```
|
||||
|
||||
### 6.2 项目级聚合
|
||||
|
||||
`GET /projects/{project_id}/dashboard-snapshot`
|
||||
|
||||
返回：活跃实例数、按 phase 分布、近 1h 失败率、平均任务耗时等 **JSON 聚合**（供 Heicode 控制台图表）。
|
||||
|
||||
### 6.3 指标导出（可选）
|
||||
|
||||
- `GET /metrics` —— Prometheus 文本；或
|
||||
- `GET /projects/{project_id}/metrics.json` —— 简化 JSON。
|
||||
|
||||
---
|
||||
|
||||
## 7. 事件流（SSE / WebSocket）
|
||||
|
||||
### 7.1 SSE（推荐易调试）
|
||||
|
||||
`GET /agent-instances/{instance_id}/events`
|
||||
|
||||
- Headers：`Accept: text/event-stream`
|
||||
- 事件：`id`、`event`、`data`（JSON）
|
||||
|
||||
**data 示例**
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": 1,
|
||||
"type": "phase_changed",
|
||||
"from": "pending",
|
||||
"to": "running",
|
||||
"at": "2026-04-30T12:00:01Z"
|
||||
}
|
||||
```
|
||||
|
||||
### 7.2 WebSocket（高吞吐）
|
||||
|
||||
`WS /projects/{project_id}/stream`
|
||||
|
||||
- 首帧 **鉴权**（query token 或子协议）；订阅主题：`deployment.*`、`instance.*`。
|
||||
|
||||
### 7.3 重连与顺序
|
||||
|
||||
- 支持 `Last-Event-ID`；服务端保留短期 **环形缓冲**（如 15 分钟）以便断线续传。
|
||||
|
||||
---
|
||||
|
||||
## 8. 审计与合规（跨 M4/M5）
|
||||
|
||||
- `GET /audit-logs?tenant_id=&from=&to=` —— 仅 `auditor` / `org_admin`。
|
||||
- 每条：`actor`、`action`、`resource`、`tenant_id`、`request_id`、`correlation_id`、`result`。
|
||||
|
||||
---
|
||||
|
||||
## 9. 错误模型
|
||||
|
||||
| HTTP | 含义 | 客户端行为 |
|
||||
|------|------|------------|
|
||||
| 400 | 参数错误 | 展示校验细节 |
|
||||
| 401 | 未认证 | 刷新令牌 |
|
||||
| 403 | 权限不足 | 引导申请角色 |
|
||||
| 404 | 不存在或无权（对外统一） | 不泄漏存在性 |
|
||||
| 409 | 状态冲突（重复部署） | 幂等重试策略 |
|
||||
| 429 | 限流 | 退避 |
|
||||
| 503 | 编排背压 | 重试 + 降级文案 |
|
||||
|
||||
**响应体**统一 envelope：
|
||||
|
||||
```json
|
||||
{ "error": { "code": "FORBIDDEN_CROSS_TENANT", "message": "...", "request_id": "..." } }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. 版本与演进
|
||||
|
||||
- URL 前缀：`/api/v1`；破坏性变更引入 `/api/v2`。
|
||||
- 事件 `schema_version` 递增；客户端忽略未知字段。
|
||||
|
||||
---
|
||||
|
||||
## 11. OpenAPI / 交付物建议
|
||||
|
||||
- Agnet 侧维护 **OpenAPI 3.1** 与 **异步 API（SSE/WS）说明**；
|
||||
- 提供 **Postman Collection** + **租户穿越测试集合**。
|
||||
|
||||
---
|
||||
|
||||
*本文档随里程碑评审更新；实现细节以 Agnet 与 Heicode 联合 RFC 为准。*
|
||||
@@ -0,0 +1,31 @@
|
||||
# M1 · 契约与身份对齐
|
||||
|
||||
## 目标
|
||||
|
||||
在**不绑定具体云厂商**的前提下，冻结 **Heicode Manager** 与 **Heicode 客户端** 之间的最小身份与 API 语义，使后续 Agnet 集成可通过同一身份体系挂载授权。
|
||||
|
||||
## 完成定义（DoD）
|
||||
|
||||
- [ ] **登录与会话**：浏览器 OAuth / loopback 回调语义文档化；`session` 与 `token` 字段含义与过期策略书面一致。
|
||||
- [ ] **模型发现**：`GET /v1/models`（或等价路径）的请求头、错误码与分页/过滤约定写入契约草案。
|
||||
- [ ] **用户上下文**：客户端携带的租户/组织标识（若有）与 Manager 侧解析规则一致，避免 silent ignore。
|
||||
- [ ] **版本协商**：客户端 `User-Agent` / `X-Heicode-Client-Version` 与 Manager 最低兼容矩阵写明。
|
||||
|
||||
## 依赖
|
||||
|
||||
- 无前置里程碑；为本目录后续里程碑的**共同前置**。
|
||||
|
||||
## 与 Agnet 的衔接（预备）
|
||||
|
||||
M1 **不要求** Agnet 已接入；但契约中预留：
|
||||
|
||||
- `X-Tenant-Id` / `X-Org-Id`（可选）传播约定，便于 M4 多租户对齐。
|
||||
|
||||
## 验收建议
|
||||
|
||||
- 自动化契约测试或 Postman/Newman 集合跑通最小路径。
|
||||
- 产品侧评审：登录失败、令牌过期、权限不足三类错误对用户可见且可诊断。
|
||||
|
||||
## 风险
|
||||
|
||||
- 契约频繁变动会导致 M3 编排回调身份映射返工——M1 冻结后应通过**版本号**约束变更。
|
||||
@@ -0,0 +1,29 @@
|
||||
# M2 · 本地端到端闭环（单环境）
|
||||
|
||||
## 目标
|
||||
|
||||
在**单机或本地 Docker 网络**内跑通：**官网/文档 → Manager → Heicode 客户端 → 一次「写仓库 / 触发流水线」的示意闭环**（不要求生产级 SLA）。
|
||||
|
||||
## 完成定义（DoD）
|
||||
|
||||
- [ ] 本地可启动 Manager 与 Heicode 客户端（CLI 或 Desktop 至少其一）。
|
||||
- [ ] 用户完成登录后，可拉取模型列表并成功发起**至少一类**对话或任务请求。
|
||||
- [ ] **可追溯锚点**：产生一条可与 Git 提交或 CI Run ID 关联的记录（哪怕是脚本化演示）。
|
||||
- [ ] 文档：开发者可在 30 分钟内按 README 复现上述路径。
|
||||
|
||||
## 依赖
|
||||
|
||||
- [M1](./M1-contract-identity.md) 契约可用。
|
||||
|
||||
## 与 Agnet 的衔接
|
||||
|
||||
- 本里程碑可用 **模拟编排**（静态 JSON / Mock Server）代替真实 Agnet；接口形状应对齐 [`agnet-platform-api-design.md`](../integration/agnet-platform-api-design.md) 中的 **Dry-run / Mock** 一节（若已定义）。
|
||||
|
||||
## 验收建议
|
||||
|
||||
- 录制简短屏幕录像或自动化 E2E（可选）。
|
||||
- 清单式回归：**登录 → 模型 → 对话 → 追溯记录存在**。
|
||||
|
||||
## 风险
|
||||
|
||||
- 若跳过可追溯锚点，后续 M4/M5 审计字段难以回补。
|
||||
@@ -0,0 +1,31 @@
|
||||
# M3 · Agnet 编排桥接（执行单元生命周期）
|
||||
|
||||
## 目标
|
||||
|
||||
**Agnet 平台**按约定 API 向 Heicode 暴露：**编队部署、执行单元状态、任务回写** 能力；Heicode Manager / 客户端可将编排动作纳入同一身份与审计链路。
|
||||
|
||||
## 完成定义（DoD）
|
||||
|
||||
- [ ] Agnet 侧实现集成文档中 **编排控制面** 最小集（部署/伸缩/停止编队或等价操作）。
|
||||
- [ ] **回调/Webhook**：执行单元状态变更可推送到 Heicode 可订阅地址（或 Manager 注册 webhook URL）。
|
||||
- [ ] **幂等与关联 ID**：每次部署生成全局唯一的 `deployment_id`，与 Heicode 侧 `correlation_id` 可互查。
|
||||
- [ ] **失败语义**：超时、部分就绪、不可调度等状态码与可重试策略文档化。
|
||||
- [ ] 联调环境：至少一套非生产 Agnet 与 Heicode **对打成功**（见集成文档验收用例）。
|
||||
|
||||
## 依赖
|
||||
|
||||
- [M1](./M1-contract-identity.md)
|
||||
- [M2](./M2-local-e2e.md)（可用 Mock 缩短并行时间，但上线前需真实联调）
|
||||
- 阅读 [`../integration/agnet-platform-api-design.md`](../integration/agnet-platform-api-design.md) 第 4～6 节
|
||||
|
||||
## 与 Agnet 的衔接
|
||||
|
||||
- 本里程碑直接消费 **部署类 API**、**Agent 实例 CRUD 语义**、**事件订阅**（见集成文档）。
|
||||
|
||||
## 验收建议
|
||||
|
||||
- 表格化测试用例：部署成功、部署失败回滚、并发部署隔离（与 M4 交叉验证）。
|
||||
|
||||
## 风险
|
||||
|
||||
- Agnet 若尚未稳定 **deployment_id → 实例列表** 映射，会导致 Heicode 客户端「状态面板」空洞（转入 M5）。
|
||||
@@ -0,0 +1,31 @@
|
||||
# M4 · 租户模型、RBAC 与数据隔离
|
||||
|
||||
## 目标
|
||||
|
||||
在 Agnet 与 Heicode 联合语境下，落实 **权限分离** 与 **多租户数据隔离**，使「平台管理员 / 组织管理员 / 项目成员 / 只读审计」可分工，且任意 API **默认不可跨租户泄漏**。
|
||||
|
||||
## 完成定义（DoD）
|
||||
|
||||
- [ ] **租户模型**：`tenant`（或 `org`）为顶层隔离边界；`project` / `environment` 为常用次级边界；标识符在请求头或路径中明确（见集成文档）。
|
||||
- [ ] **RBAC**：至少四类角色行为矩阵落地（创建编队、查看密钥类操作、只读观测、平台运维）；拒绝默认「幂等全局读」。
|
||||
- [ ] **数据面隔离**：存储层按租户分区（逻辑 schema / 物理库 / 命名空间之一），查询默认带 `tenant_id` 谓词；集成测试含 **跨租户负例**（必须 403/404）。
|
||||
- [ ] **密钥与凭据**：连接 Git/云的凭据 **从不**在跨租户 API 响应中回显；轮换与审计字段可查。
|
||||
- [ ] **审计日志**：敏感操作（部署、凭据绑定、策略变更）写入 **追加式审计流**，含操作者主体与 `correlation_id`。
|
||||
|
||||
## 依赖
|
||||
|
||||
- [M1](./M1-contract-identity.md)
|
||||
- [M3](./M3-agnet-orchestration-bridge.md)（编排 API 已存在才可测隔离）
|
||||
|
||||
## 与 Agnet 的衔接
|
||||
|
||||
- 对齐集成文档 **§3 认证与授权**、**§5 多租户与数据隔离**。
|
||||
|
||||
## 验收建议
|
||||
|
||||
- 自动化 **租户穿越测试**（Tenant A 的 token 访问 Tenant B 资源必须失败）。
|
||||
- 数据团队/安全团队走查 RBAC 矩阵与审计字段。
|
||||
|
||||
## 风险
|
||||
|
||||
- 「软隔离」（仅应用层过滤）在复杂查询下易遗漏——需在评审中明确 **查询路径全覆盖**。
|
||||
@@ -0,0 +1,31 @@
|
||||
# M5 · 可观测性与可视化（运行态对外）
|
||||
|
||||
## 目标
|
||||
|
||||
为 **有状态执行单元** 提供 **可视化接口**：Heicode 客户端与 Manager 控制台可展示 **健康、阶段、资源占用、近期事件与错误摘要**，降低「黑盒智能体」带来的运维与信任成本。
|
||||
|
||||
## 完成定义（DoD）
|
||||
|
||||
- [ ] **快照 API**：按 `agent_id` / `deployment_id` 返回结构化状态（阶段、版本、最近心跳、队列深度等字段见集成文档）。
|
||||
- [ ] **事件流**：支持 SSE 或 WebSocket **订阅**单实例或项目级事件；含断线重连与 `Last-Event-ID` 语义。
|
||||
- [ ] **聚合视图**：项目级 Dashboard 所需指标（活跃单元数、失败率、平均耗时）可由 Agnet 聚合端点提供，或约定由 Heicode Manager 拉取后缓存（二选一须文档化）。
|
||||
- [ ] **与权限联动**：只读角色仅能访问允许范围内的实例；事件流不得泄漏其他租户 ID。
|
||||
- [ ] **SLI 约定**：可选暴露 RED/USE 类指标端点（Prometheus 或 JSON），便于接入现有监控。
|
||||
|
||||
## 依赖
|
||||
|
||||
- [M3](./M3-agnet-orchestration-bridge.md)（实例存在）
|
||||
- [M4](./M4-tenant-rbac-isolation.md)（否则可视化接口本身成为数据泄漏面）
|
||||
|
||||
## 与 Agnet 的衔接
|
||||
|
||||
- 对齐集成文档 **§6 运行态与可视化 API**、**§7 事件与订阅**。
|
||||
|
||||
## 验收建议
|
||||
|
||||
- 业务方 UAT：非技术成员能否从 UI 判断「卡在哪一步」。
|
||||
- 负载测试：事件流在 **N 并发订阅** 下仍满足延迟上限（自定阈值）。
|
||||
|
||||
## 风险
|
||||
|
||||
- 若事件 schema 不版本化，客户端与平台升级易出现「半屏空白」——需 **schema 版本** 字段。
|
||||
@@ -0,0 +1,26 @@
|
||||
# Heicode 交付里程碑（索引）
|
||||
|
||||
本目录将整体交付拆成**可验收、可并行准备**的里程碑事件；每个文件定义**完成定义（DoD）**、**依赖**与**与 Agnet 平台的衔接点**。
|
||||
全局范式仍以 [`../vision-heicode-full-stack-agentic-dev.md`](../vision-heicode-full-stack-agentic-dev.md) 为准。
|
||||
|
||||
## 推荐阅读顺序
|
||||
|
||||
| 顺序 | 文档 | 摘要 |
|
||||
|------|------|------|
|
||||
| 1 | [M1-契约与身份对齐](./M1-contract-identity.md) | Heicode Manager ↔ 客户端最小契约；登录与令牌语义 |
|
||||
| 2 | [M2-本地端到端闭环](./M2-local-e2e.md) | 单环境跑通：登录、模型发现、对话、一次发布链路（示意） |
|
||||
| 3 | [M3-Agnet-编排集成](./M3-agnet-orchestration-bridge.md) | 拉起编队、执行单元生命周期与回调 Heicode |
|
||||
| 4 | [M4-租户隔离与权限](./M4-tenant-rbac-isolation.md) | 多租户数据面隔离、RBAC、审计字段落地 |
|
||||
| 5 | [M5-可观测与可视化](./M5-observability-visualization.md) | 运行态可视、指标与事件流对接 Heicode 客户端/控制台 |
|
||||
|
||||
## 与集成设计文档的关系
|
||||
|
||||
Agnet 平台应对外暴露的 **HTTP/gRPC 契约、事件流与隔离模型** 详述见：
|
||||
|
||||
**[`../integration/agnet-platform-api-design.md`](../integration/agnet-platform-api-design.md)**
|
||||
|
||||
里程碑 **M3～M5** 分别对应集成文档中的「编排 API」「安全与隔离」「观测与可视化 API」的落地节奏。
|
||||
|
||||
---
|
||||
|
||||
*新增里程碑时请在本表追加一行，并在文档内标明前置依赖。*
|
||||
@@ -1,194 +1,166 @@
|
||||
# Heicode 全栈智能体开发范式（愿景与产品说明）
|
||||
# Heicode 愿景：团队软件交付范式（方向性说明）
|
||||
|
||||
本文档把当前对 **Heicode** 工作区的技术理解，与产品侧「全自动化编程、多子智能体团队、与现有平台对接」的构想，整理成**可讨论、可迭代**的范式说明。随实现推进，应持续更新本文件中的状态与待决问题。
|
||||
本文档只回答 **「为何存在」「指向何方」「坚持什么原则」**——不涉及版本排期、接口冻结清单或逐步交付计划；后者应在路线图或项目管理工具中单独立项。
|
||||
|
||||
---
|
||||
**代号表（与真实工程名无绑定，仅为行文一致）**
|
||||
|
||||
## 一、三问（直接回答）
|
||||
|
||||
### 1. 能否大致说清楚这个项目是干嘛的？
|
||||
|
||||
**可以。**
|
||||
|
||||
- **工作区层面**：`heicode` 是一个多项目容器，目前可见的核心是
|
||||
- **`cc-haha`**：面向终端与桌面的智能体编程体验（CLI、API 路由、MCP/任务/团队等子系统，并含 `desktop` 的 Tauri 相关结构），目标方向与 **Claude Code 类** 工具体验一致。
|
||||
- **`new-api`**：基于社区 **New API** 生态的 **大模型网关与运营侧能力**（渠道、计费、鉴权、多协议中继等），经你方 **深度改造** 后，作为 **用户/团队登录后看到的「后台」与 API 能力层**。
|
||||
|
||||
- **产品叙事层面（你的目标）**：Heicode 不是「单一编码插件」，而是 **结合 Agnet 平台子智能体团队 + 改造后的 New API + 类 oh-my-claudecode 的编程流程**，在 **软件全生命周期** 内支撑 **从需求到代码、到测试、到多云部署、到运维与迭代** 的 **自动化开发范式**；与仅「在 IDE 里写代码」相比，更强调 **多成员（多子 Agnet）协作、可重复的标准化团队模式、以及可审计的交付物**（产品文档、开发日志、多智能体沟通记录等）。
|
||||
|
||||
---
|
||||
|
||||
### 2. 能否做到和 Claude Code 目前一个效果？
|
||||
|
||||
**「方向一致、体验对等」是可实现的产品目标；「逐像素、逐协议完全一致」需要刻意对齐与持续跟进。**
|
||||
|
||||
| 维度 | 说明 |
|
||||
| 称谓 | 含义 |
|
||||
|------|------|
|
||||
| **CLI / Desktop 登录与会话** | 技术上可对齐同一套账号体系（OAuth/令牌）、同一后端（改造后的 New API），使你描述的「下载 CLI/Desktop → 登录 → 对话界面」闭环成立；是否与 Claude Code **完全一致**取决于是否采用相同的认证提供方、相同的会话模型以及相同的客户端发布节奏。 |
|
||||
| **插件 / MCP / 工具生态** | `cc-haha` 已有 MCP、路由与工具链相关代码路径；要达到「一模一样」，除功能对等外，还需 **兼容性测试矩阵**（版本、权限模型、错误语义）。 |
|
||||
| **结论** | 作为 **自托管 / 深度集成 Agnet + New API** 的产品，更合理的承诺是：**在贵司账号与策略域内，提供与 Claude Code 同等量级的「可开发、可协作、可部署」能力**；对 **商业 Claude Code 本身** 的 1:1 复刻，受外部产品变更与条款约束，应作为**长期对标**而非一次性验收项。 |
|
||||
| **Heicode Manager** | 账户、模型与路由策略、计费与渠道等能力的网关及管理控制台。 |
|
||||
| **Heicode** | 终端与桌面侧人机编程客户端及本地服务（与 Manager 区分时亦称「Heicode 客户端」）。 |
|
||||
| **Orchard** | 子智能体编排与团队模板所在平台（概念名）。 |
|
||||
| **执行单元** | 在编排侧按角色模板实例化的智能体实例。 |
|
||||
|
||||
---
|
||||
|
||||
### 3. 目前这个项目处于什么状态？
|
||||
## 一、我们想改变什么
|
||||
|
||||
**综合判断：偏「能力已铺底、产品叙事与平台级整合仍处早中期」的状态。**
|
||||
组织交付软件时，常见断层出在：**规格与实现脱节**、**质量闸门含糊**、**发布与环境无人认领**、**事后难以复盘**。个人侧的「写代码更快」解决不了这些结构性问题。
|
||||
|
||||
| 信号 | 观察 |
|
||||
|------|------|
|
||||
| **工程** | `new-api` 与 `cc-haha` 均具备可读的领域代码与测试痕迹；但工作区**根级**未形成单一 `README` 与统一发布说明，**多仓/多副本**（如 `_all-in-one-upload`）暗示仍在整合或迁移中。 |
|
||||
| **产品** | 你描述的 **Heicode 官网 → New API 后台 → CLI/Desktop 下载 → Agnet 一键部署子智能体** 的完整闭环，在文档与入口上**尚未在仓库内完全固化**（正是本文档要补的）。 |
|
||||
| **平台依赖** | **Agnet 生产已部署**；**权限、多租户数据隔离、有状态子智能体可观测性** 仍属平台侧待完善项，会直接影响 Heicode 的**企业级**叙事落地节奏。 |
|
||||
Heicode 的关切点是：**在多人、多环境、多迭代的条件下，如何让对齐方式、责任边界与可追溯性默认成立**——智能体适合承接其中 **标准化、可重复** 的环节；人机分工与审批边界则由组织策略定义，而不是由某一工具一次性替你定死。
|
||||
|
||||
---
|
||||
|
||||
## 二、愿景一句话
|
||||
## 二、北极星与成功图景（定性）
|
||||
|
||||
**Heicode = 面向团队的、贯穿软件生命周期的「智能体软件交付」平台**：
|
||||
以 **改造后的 New API** 为统一账户与模型/计费/策略网关，以 **Agnet 平台上的子智能体团队** 为执行单元，以 **类 Claude Code 的 CLI/Desktop** 为人机界面，把「想法 → 规格 → 实现 → 验证 → 发布 → 运维 → 迭代」压缩成**可重复、可审计、可按团队规模裁剪**的标准范式。
|
||||
- **北极星**：团队能以可复述的方式回答——「谁在何时对什么负责」「依据是什么」「如何回溯到某次发布或某条决策」。
|
||||
- **成功图景（不写 KPI）**：人在关键环节保有裁决权；机器与智能体放大吞吐与一致性；交付物（规格、代码、测试结论、发布记录）能与版本或发布锚点关联；编排与权限足以支撑多团队并存而不互相踩踏。
|
||||
|
||||
---
|
||||
|
||||
## 三、架构鸟瞰（逻辑分层）
|
||||
## 三、指导原则
|
||||
|
||||
1. **可追溯优于单次极速**：宁可多一道可查的记录，也不依赖口头默契替代闸门。
|
||||
2. **范式可裁剪**：瀑布与敏捷是协作隐喻，不是教条；规模与角色应由组织工作坊裁剪，而非照搬单一数字。
|
||||
3. **集成可替换**：Manager、客户端、编排平台、云与流水线均以「契约与边界」相接，避免叙事绑死在某一厂商或目录名上。
|
||||
4. **人机协同**：涉及权限、费用、生产变更与高敏数据的决策，默认保留人在回路；自动化扩展 **提案权**，不默认 **无限代理权**。
|
||||
5. **对内对外叙事分层**：愿景文档不写实施说明书；角色代号与编队明细放入附录，以免喧宾夺主。
|
||||
|
||||
---
|
||||
|
||||
## 四、战略支柱（方向）
|
||||
|
||||
### 4.1 身份与策略一元化
|
||||
|
||||
使人机在统一身份与组织策略下工作：谁能访问何种模型与渠道、何种环境、何种仓库与密钥——应有清晰归属与审计预期，而不是散落在若干控制台口径不一致。
|
||||
|
||||
### 4.2 编排与角色范式
|
||||
|
||||
把「谁在流水线哪一段接力」说清楚：既可按阶段闸门（瀑布隐喻）也可按迭代闭环（敏捷隐喻）组织 **执行单元**；重点是 **闸门不被静默跳过**、**角色不重叠到互相推诿**。具体几人几岗属于落地裁剪，见附录。
|
||||
|
||||
### 4.3 全生命周期可信交付
|
||||
|
||||
从构想到运营，关键产物应能对齐到分支、标签或发布单元：**规格、实现、验证、发布、运维与复盘** 之间有可追溯链路；多云与环境仅是载体，原则是 **最小权限与环境晋升**。
|
||||
|
||||
### 4.4 平台化协作而非单机熟练度
|
||||
|
||||
与「个人终端技巧」相比，Heicode 更强调 **跨角色、跨会话、跨环境** 的一体化协作叙事——客户端与 Manager、编排侧共同服务于同一交付故事线。
|
||||
|
||||
---
|
||||
|
||||
## 五、概念分层（鸟瞰）
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ 用户 / 团队 │
|
||||
│ 浏览器（官网、New API 控制台）│ CLI │ Desktop（Tauri） │
|
||||
└───────────────┬─────────────────────────────┬───────────────────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌───────────────────────────┐ ┌───────────────────────────────────┐
|
||||
│ 改造后的 New API │ │ cc-haha（CLI / Desktop / 本地服务） │
|
||||
│ 账号 · 令牌 · 模型网关 │◄──► 对话 · 工具 · MCP · 任务 · 团队视图 │
|
||||
│ 计费 · 渠道 · 策略（可选） │ │ 与 New API 对齐登录态与 API │
|
||||
└───────────────┬───────────┘ └───────────────────┬───────────────┘
|
||||
│ │
|
||||
│ ┌───────────────────────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Agnet 平台（已部署生产；权限/隔离/可观测性仍在演进） │
|
||||
│ 一键部署「子 Agnet 团队」· 瀑布 / 敏捷 模板 · 有状态子 Agnet │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ 外部系统（默认假设「已具备集成能力」） │
|
||||
│ Git · GCP · AWS · Azure · CI/CD · 监控 · 工单/文档库 │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
人机入口（官网 · 控制台 · CLI / Desktop）
|
||||
↓ 同一身份与策略边界
|
||||
Heicode Manager ←→ Heicode 客户端
|
||||
↓
|
||||
编排与执行（Orchard：角色模板 · 执行单元 · 状态）
|
||||
↓
|
||||
资产与环境（仓库 · 流水线 · 运行环境与观测）
|
||||
```
|
||||
|
||||
**边界声明**：下文 **不展开 Agnet 内部如何实现**，默认平台已提供「创建子智能体、编排、与外部工具集成」等能力；Heicode 侧聚焦 **集成契约、用户体验与安全边界**。
|
||||
**边界**：编排平台内部实现细节不属于愿景正文；Heicode 关心的是 **契约、体验与安全边界** 是否说得清、守得住。
|
||||
|
||||
---
|
||||
|
||||
## 四、核心用户旅程（目标体验）
|
||||
## 六、协作范式（方向性，非排期）
|
||||
|
||||
1. 访问 **Heicode 官网**，了解产品与下载入口。
|
||||
2. **登录** 进入 **改造后的 New API** 控制台：查看配额、令牌、模型/渠道策略（**现阶段可不新增功能，仅作为已有能力的聚合展示**）。
|
||||
3. **下载** 官方构建的 **CLI** 与 **Desktop**，安装后以 **与 Claude Code 对齐的登录方式** 进入 **对话界面**，并能看到 **与子 Agnet / 任务相关的状态**（具体 UI 依赖 Agnet 与本地 Agent 状态上报）。
|
||||
4. 在 **Agnet 平台** 对某一项目 **一键部署子 Agnet 团队**（瀑布或敏捷模板），与本地/云端仓库、流水线权限绑定。
|
||||
5. 团队在 **全生命周期** 内完成开发、测试、部署、运维与迭代；产物包括 **代码、产品文档、沟通记录、开发日志**。
|
||||
- **瀑布隐喻**：强调阶段闸门与可审计链条；适合强合规、长评审链的组织语境——「最小编队 / 最大编队」表示协调复杂度量级，不是 HR 编制。
|
||||
- **敏捷隐喻**：强调短迭代与跨职能闭环；适合快速试错的产品语境——同样，人数区间是 **协调上限的提示**，落地时需结合真实产能与依赖。
|
||||
- **超出协调上限时**：拆分子系统、拆分 Squad 或引入共享平台能力，而不是在同一队列上无限堆角色。
|
||||
|
||||
全生命周期上，Heicode 主张覆盖 **构思 → 规格 → 实现 → 验证 → 发布 → 运维 → 迭代** 的 **语义连贯**，而非单独优化其中一环的工具速度。
|
||||
|
||||
---
|
||||
|
||||
## 五、子 Agnet 团队：瀑布 vs 敏捷（规模与角色）
|
||||
## 七、可信交付与多主体协作（方向）
|
||||
|
||||
本节给出 **Heicode 范式下的「最小 / 最大」子 Agnet 数量判断**，并为 **每一个子 Agnet 写明角色名称与职责边界**，供 Agnet 平台「一键部署团队」时直接映射为实例规格（名称可按平台惯例缩写）。
|
||||
|
||||
### 5.1 判定依据（为什么是这个区间）
|
||||
|
||||
| 维度 | 瀑布模式 | 敏捷模式 |
|
||||
|------|----------|----------|
|
||||
| **流程特征** | 阶段闸门强、文档与评审链长，角色边界清晰 | 迭代短、反馈密，强调跨职能小闭环 |
|
||||
| **最小团队含义** | 仍能走完「规格→设计→实现→验证→上线」且 **不合并关键闸门**（否则失去瀑布的可审计性） | 仍能在一个迭代内完成「可演示增量」且具备 **独立质量门禁** |
|
||||
| **最大团队含义** | 覆盖大型传统组织常见 **专岗**（安全、文档、前后端分立），且不超过单项目协调上限（约 **9** 个并行协调节点） | 覆盖规模化 Scrum 小组（双轨开发 + 嵌入式 SRE/UX），且不超过 **两个披萨团队** 上限（约 **8** 人 equivalent） |
|
||||
| **超出上限时** | 应拆 **子系统 / 子项目** 或多套瀑布实例，而不是继续堆角色 | 应拆 **多个 Squad** 或引入 **平台组共享**，而不是单队列无限加 Agnet |
|
||||
多执行单元、多人协作时，需要 **可关联的会话与决策摘要**、与分支或发布对齐的文档、以及可供审计的开发日志聚合维度——实现形态可为日志服务、工单或治理平台，愿景层只坚持 **可追溯** 这一条。
|
||||
|
||||
---
|
||||
|
||||
### 5.2 规模总览
|
||||
## 八、已知张力（非缺陷清单）
|
||||
|
||||
| 模式 | 最小团队（子 Agnet 数） | 最大团队（子 Agnet 数） |
|
||||
组织级叙事依赖 **编排侧的租户隔离、权限模型与可观测性**；客户端体验若对标商业产品，属于 **长期对齐** 而非愿景正文承诺。工程仓库如何组织、文档入口如何统一，属于 **工程卫生**，与范式方向并行演进。
|
||||
|
||||
---
|
||||
|
||||
## 九、阶段性方向（非路线图）
|
||||
|
||||
仅给出 **时间无序** 的三层递进意象，方便对齐讨论；**不绑定季度、不设里程碑编号**：
|
||||
|
||||
1. **对齐**：身份、策略与叙事口径一致，避免「各说各话」。
|
||||
2. **贯通**：人机链路在一条交付故事线下可走通，关键闸门有据可查。
|
||||
3. **规模化**：编队模板与审批策略可按组织复制，而不是单次项目手工拼装。
|
||||
|
||||
---
|
||||
|
||||
## 十、开放议题（范式层）
|
||||
|
||||
- 执行单元的 **所有权**：按项目、组织还是环境切分？
|
||||
- **人在回路**：哪些类别动作必须人工批准？
|
||||
- **商业与责任**：对内效率工具与对外承诺的边界如何划分？
|
||||
|
||||
---
|
||||
|
||||
## 附录 A：编队规模与角色明细（落地参考）
|
||||
|
||||
以下为 **职务说明书级别的参考**，用于工作坊裁剪与编排映射；**不属于愿景层的承诺范围**。数字与代号均可按组织调整。
|
||||
|
||||
### A.1 规模总览
|
||||
|
||||
| 模式 | 最小编队（执行单元数） | 最大编队（执行单元数） |
|
||||
|------|-------------------------|-------------------------|
|
||||
| **瀑布** | **5** | **9** |
|
||||
| **敏捷** | **3** | **8** |
|
||||
|
||||
---
|
||||
### A.2 判定依据摘要
|
||||
|
||||
### 5.3 瀑布模式 — 最小团队（5 个子 Agnet）
|
||||
| 维度 | 瀑布 | 敏捷 |
|
||||
|------|------|------|
|
||||
| **流程特征** | 阶段闸门强、评审链长 | 迭代短、反馈密 |
|
||||
| **「最小」含义** | 仍能走完规格→设计→实现→验证→上线且不合并关键闸门 | 仍能在一个迭代内交付可演示增量并有独立质量门禁 |
|
||||
| **「最大」含义** | 覆盖常见专岗且不超过约 9 个并行协调节点 | 覆盖规模化小组且不超过约「两个披萨」协调上限 |
|
||||
| **溢出策略** | 拆子系统或多套实例 | 拆 Squad 或平台组共享，而非单队列无限加人 |
|
||||
|
||||
适用于：**阶段清晰、评审链存在、但人力收紧** 的项目。五人对应瀑布五条「硬闸门」，互不合并，以保证可追溯。
|
||||
### A.3 瀑布 — 最小编队（5）
|
||||
|
||||
| # | 角色代号（建议） | 角色名称 | 职责（该子 Agnet 专属） |
|
||||
|---|------------------|----------|-------------------------|
|
||||
| W1 | `WF-BA` | **业务/需求分析师** | 需求规格说明书、范围与假设、验收标准、变更登记；组织需求评审输入材料 |
|
||||
| W2 | `WF-ARC` | **解决方案架构师** | 系统架构、模块边界、接口与数据契约、非功能需求（性能/可用/扩展）落档 |
|
||||
| W3 | `WF-DEV` | **软件工程师（实现）** | 按设计实现功能、单元测试、静态检查与本地验证、参与设计澄清 |
|
||||
| W4 | `WF-QA` | **测试工程师** | 测试策略与用例、集成/系统测试、缺陷管理与回归、**发布前质量门禁结论** |
|
||||
| W5 | `WF-REL` | **发布与运维工程师** | CI/CD 流水线、环境一致性、发布编排与回滚预案、上线后健康检查与基础可观测 |
|
||||
| 代号 | 角色 | 职责摘要 |
|
||||
|------|------|----------|
|
||||
| `WF-BA` | 业务/需求分析师 | 规格、范围、验收标准、变更登记 |
|
||||
| `WF-ARC` | 解决方案架构师 | 架构边界、接口与数据契约、NFR 落档 |
|
||||
| `WF-DEV` | 软件工程师 | 实现、单测、静态检查、设计澄清 |
|
||||
| `WF-QA` | 测试工程师 | 测试策略与用例、缺陷与回归、发布前质量门禁结论 |
|
||||
| `WF-REL` | 发布与运维工程师 | CI/CD、环境一致性、发布编排与回滚预案、基础可观测 |
|
||||
|
||||
**说明**：最小瀑布 **不单独设** PM/安全/文档岗——由 BA（对外表述）、ARC（安全架构底线）、REL（Runbook 最低集）**兼带轻量职责**；若监管或合同要求独立签字，应升级到 **最大团队**。
|
||||
### A.4 瀑布 — 最大编队（9）
|
||||
|
||||
---
|
||||
在 A.3 思路上扩展：`WF-PM`、`WF-DEV-B`、`WF-DEV-F`、`WF-SEC`、`WF-DOC` 等专岗；职责聚焦「合规、前后端分立、安全与文档独立审计」场景。
|
||||
|
||||
### 5.4 瀑布模式 — 最大团队（9 个子 Agnet）
|
||||
### A.5 敏捷 — 最小编队（3）
|
||||
|
||||
适用于：**强合规、多干系人、前后端并行、安全与文档独立审计** 的大型项目。
|
||||
| 代号 | 角色 | 职责摘要 |
|
||||
|------|------|----------|
|
||||
| `AG-PO` | 产品负责人 | Backlog、验收标准、冲刺目标 |
|
||||
| `AG-DEV` | 软件工程师 | 迭代实现与设计澄清、评审协作 |
|
||||
| `AG-QA` | 测试工程师 | 迭代测试、自动化与探索性测试、DoD 质量项 |
|
||||
|
||||
| # | 角色代号（建议） | 角色名称 | 职责（该子 Agnet 专属） |
|
||||
|---|------------------|----------|-------------------------|
|
||||
| W1 | `WF-PM` | **产品经理** | 路线图与里程碑、干系人沟通、优先级裁决、发布范围与 Go/No-Go 协同 |
|
||||
| W2 | `WF-BA` | **业务/需求分析师** | 需求规格与验收标准、变更控制、与 PM 对齐「做什么」 |
|
||||
| W3 | `WF-ARC` | **解决方案架构师** | 总体架构与技术选型、跨团队接口冻结、架构评审组织 |
|
||||
| W4 | `WF-DEV-B` | **后端开发工程师** | 服务/API、领域模型、数据访问与集成、后端侧单元与契约测试 |
|
||||
| W5 | `WF-DEV-F` | **前端开发工程师** | UI 实现、前端状态与可访问性、与后端联调、前端侧测试 |
|
||||
| W6 | `WF-QA` | **测试工程师** | 端到端质量责任、测试环境与数据、缺陷 SLAs、发布签字前的测试结论 |
|
||||
| W7 | `WF-SEC` | **安全与合规专员** | 威胁建模输入、密钥与凭据策略、依赖与供应链审查、发布前安全复核 |
|
||||
| W8 | `WF-DOC` | **技术文档工程师** | 用户文档、API/集成说明、对内 Runbook 与培训材料 |
|
||||
| W9 | `WF-REL` | **发布与运维工程师** | 多云/多环境发布路径、IaC 与配置治理、监控告警与值班交接 |
|
||||
### A.6 敏捷 — 最大编队（8）
|
||||
|
||||
**说明**：若项目为 **纯后端或纯工具链**，可折叠 `WF-DEV-F` 与 `WF-DEV-B` 之一，团队规模降到 **8**，仍属瀑布最大思想的变体。
|
||||
在 A.5 基础上扩展：`AG-SM`、`AG-TL`、`AG-DEV-A`、`AG-DEV-B`、`AG-UX`、`AG-SRE` 等；强调双轨并行与嵌入式流程时协调上限。
|
||||
|
||||
---
|
||||
|
||||
### 5.5 敏捷模式 — 最小团队（3 个子 Agnet）
|
||||
|
||||
适用于：**单迭代内完成可演示增量** 的 **最小跨职能小组**（对标经典 PO + Dev + QA）。
|
||||
|
||||
| # | 角色代号（建议） | 角色名称 | 职责（该子 Agnet 专属） |
|
||||
|---|------------------|----------|-------------------------|
|
||||
| A1 | `AG-PO` | **产品负责人（Product Owner）** | 迭代 Backlog 排序、验收标准、冲刺目标对齐、对「完成」有定义的解释权 |
|
||||
| A2 | `AG-DEV` | **软件工程师** | 迭代内设计与实现、重构、代码评审协作；简单流水线改动可由本角色在策略允许下执行 |
|
||||
| A3 | `AG-QA` | **测试工程师** | 迭代测试计划、自动化与探索性测试、DoD 中质量项、阻塞发布的缺陷升级 |
|
||||
|
||||
**说明**：**不设专职 Scrum Master / SRE**——节奏由 PO 与团队自律维持，环境与发布依赖 **平台默认模板** 或 **WF-REL 类共享服务**（组织级平台组）。
|
||||
|
||||
---
|
||||
|
||||
### 5.6 敏捷模式 — 最大团队（8 个子 Agnet）
|
||||
|
||||
适用于：**双轨并行特性、节奏复杂、需要嵌入式流程与平台能力** 的规模化迭代。
|
||||
|
||||
| # | 角色代号（建议） | 角色名称 | 职责（该子 Agnet 专属） |
|
||||
|---|------------------|----------|-------------------------|
|
||||
| A1 | `AG-PO` | **产品负责人** | Backlog、价值排序、迭代目标与验收 |
|
||||
| A2 | `AG-SM` | **敏捷教练 / 流程负责人（Scrum Master）** | 阻碍清除、仪式效率、改进项跟踪；**不作**业务优先级裁决（与 PO 分工） |
|
||||
| A3 | `AG-TL` | **技术负责人（Tech Lead）** | 迭代内架构切片、技术债边界、难点攻关与跨 Dev 对齐 |
|
||||
| A4 | `AG-DEV-A` | **开发工程师 A** | 特性/区域 A 的端到端交付（含与 QA 的自动化协作） |
|
||||
| A5 | `AG-DEV-B` | **开发工程师 B** | 特性/区域 B 的并行交付，减少单点阻塞 |
|
||||
| A6 | `AG-QA` | **测试工程师** | 迭代质量策略、CI 质量门禁、发布候选验证 |
|
||||
| A7 | `AG-UX` | **UX/UI 设计师** | 迭代内交互与视觉、可用性标准、与设计系统对齐 |
|
||||
| A8 | `AG-SRE` | **DevOps / SRE 工程师** | 流水线即代码、环境晋升策略、可观测与容量、发布与回滚执行 |
|
||||
|
||||
**说明**：超过 **8** 时优先 **拆分第二个 Squad（另一套 3～8 人模板）**，而不是在同一 backlog 上继续加角色，否则协调成本会吞噬并行收益。
|
||||
|
||||
---
|
||||
|
||||
### 5.7 角色对照（可选摘编）
|
||||
|
||||
与 **5.1 通用抽象** 的对应关系：
|
||||
### A.7 角色对照（摘编）
|
||||
|
||||
| 通用抽象 | 瀑布最小 | 瀑布最大 | 敏捷最小 | 敏捷最大 |
|
||||
|----------|----------|----------|----------|----------|
|
||||
@@ -197,72 +169,13 @@
|
||||
| 开发 | DEV | DEV-B + DEV-F | DEV | DEV-A + DEV-B |
|
||||
| 测试 | QA | QA | QA | QA |
|
||||
| DevOps/SRE | REL | REL | （平台/兼任） | SRE |
|
||||
| 安全/合规 | （ARC 兼） | SEC | （门禁委托） | （可由平台策略 + TL） |
|
||||
| 安全/合规 | （ARC 兼） | SEC | （门禁委托） | （平台策略 + TL） |
|
||||
| 技术写作 | （REL 兼） | DOC | （最小化） | （可由 PO 兼） |
|
||||
| 流程推动 | — | — | — | SM |
|
||||
| 体验设计 | — | （可由 DEV-F 兼） | — | UX |
|
||||
|
||||
---
|
||||
|
||||
## 六、全生命周期能力（Heicode 要覆盖的「范式」）
|
||||
*愿景正文止于附录之上；附录仅供落地与工作坊使用。*
|
||||
|
||||
| 阶段 | 目标产出 | 依赖（概念） |
|
||||
|------|-----------|--------------|
|
||||
| 构思 / 规格 | PRD、接口草案、风险清单 | 产品子 Agnet + 文档模板 |
|
||||
| 实现 | MR/PR、代码、Review 记录 | 开发子 Agnet + Git 权限 |
|
||||
| 验证 | 测试报告、覆盖率门禁 | 测试子 Agnet + CI |
|
||||
| 发布 | 灰度、版本说明 | DevOps 子 Agnet + 云平台凭证 |
|
||||
| 运维 | 告警、Runbook、容量 | SRE 子 Agnet + 监控 |
|
||||
| 迭代 | 路线图、变更日志 | 与 Backlog/发布节奏联动 |
|
||||
|
||||
**自动化部署全流程**：在策略上授予子 Agnet **Git + 多云** 的最小权限（按仓库、按环境、按资源组），并通过 **New API / 企业 IdP** 做 **人机审批** 或 **策略引擎**（避免无人值守的越权发布）。
|
||||
|
||||
---
|
||||
|
||||
## 七、多智能体协作与可审计交付物
|
||||
|
||||
- **多 Agnet 沟通**：需要 **会话标识、线程 ID、决策摘要** 写入不可篡改或可追溯存储（至少 **追加式日志**）。
|
||||
- **产品文档**：与代码分支或发布版本 **绑定**（例如 tag / release 维度）。
|
||||
- **开发日志**：多成员场景下，按 **人/子 Agnet/任务** 维度聚合，便于复盘与合规。
|
||||
|
||||
---
|
||||
|
||||
## 八、与 oh-my-claudecode 的关系
|
||||
|
||||
**定位**：oh-my-claudecode 提供的是 **「高效使用 Claude Code 类的实践与脚手架」**；Heicode 在其之上叠加 **平台化**（New API + Agnet）与 **团队级生命周期**，从「个人极致效率」扩展到 **组织级交付**。
|
||||
|
||||
---
|
||||
|
||||
## 九、已知缺口与风险（诚实清单）
|
||||
|
||||
| 领域 | 缺口 | 对 Heicode 的影响 |
|
||||
|------|------|-------------------|
|
||||
| Agnet 平台 | 权限与数据隔离未完善 | 多租户与企业售卖受阻 |
|
||||
| Agnet 平台 | 有状态子 Agnet 的可视化运行态不足 | CLI/Desktop 内「状态面板」信息不完整 |
|
||||
| 客户端对标 | 与 Claude Code 完全一致 | 需专门里程碑与合规评估 |
|
||||
| 仓库治理 | 根目录 README/单一构建入口 | 新成员与发布节奏成本高 |
|
||||
|
||||
---
|
||||
|
||||
## 十、推荐路线图（粗粒度）
|
||||
|
||||
1. **契约冻结**：New API 与 cc-haha 的 **登录、令牌、用户上下文** API 冻结一版。
|
||||
2. **MVP 闭环**：官网下载 → 安装 → 登录 → 能看到 **账户/配额** 与 **一次完整 Git 推送流水线**（可先单云）。
|
||||
3. **Agnet 集成**：一键部署 **最小敏捷团队**，打通 **状态上报** 到 CLI。
|
||||
4. **可观测与合规**：审计日志、最小权限、环境隔离。
|
||||
5. **规模化**：瀑布/敏捷模板、最大团队配置、多云与混合审批。
|
||||
|
||||
---
|
||||
|
||||
## 十一、开放问题（供脑爆继续）
|
||||
|
||||
- 子 Agnet **所有权模型**：按项目、按组织、还是按环境？
|
||||
- **审批**：哪些操作必须人工（生产发布、费用、密钥）？
|
||||
- **计费**：模型调用走 New API；Agnet 算力是否单独计费？
|
||||
- **SLA**：对内工具 vs 对客户承诺的边界？
|
||||
|
||||
---
|
||||
|
||||
*文档版本：与仓库内实现同步演进；修改时请更新本节日期。*
|
||||
|
||||
**最近更新**：2026-04-30
|
||||
**最近更新**：2026（愿景重写：方向优先，明细迁入附录）
|
||||
|
||||
+11
-11
@@ -1,14 +1,14 @@
|
||||
# TaijiAICloud Gateway (`new-api`)
|
||||
# Heicode Manager（源码目录 `new-api`）
|
||||
|
||||
这是 HeiCode 产品线中的平台侧网关工程，基于 `new-api` 深度改造，目标是让 HeiCode 客户端能够“浏览器登录后即用模型”。
|
||||
本目录实现 **Heicode Manager**：网关与管理控制台（账号、渠道、模型策略、计费等）。目录名 `new-api` 为历史工程名；对外产品与文档统一称 **Heicode Manager**。目标是支撑 **Heicode 客户端**「浏览器登录后即用模型」。
|
||||
|
||||
## 本仓库角色
|
||||
|
||||
- 作为模型统一入口，管理渠道、用户、令牌、计费策略
|
||||
- 提供 HeiCode 需要的授权桥接接口
|
||||
- 提供 Heicode 需要的授权桥接接口
|
||||
- 输出标准模型发现能力（`/v1/models`）给客户端
|
||||
|
||||
## HeiCode 相关新增能力
|
||||
## Heicode 相关新增能力
|
||||
|
||||
### 1) 浏览器登录授权入口
|
||||
|
||||
@@ -19,12 +19,12 @@
|
||||
|
||||
- 校验 `redirect_uri` 必须是 loopback（`127.0.0.1` / `localhost` / `::1`）
|
||||
- 若用户未登录平台控制台，先引导登录
|
||||
- 登录后签发或复用 HeiCode 专用 token
|
||||
- 登录后签发或复用 Heicode 专用 token
|
||||
- 回跳本地客户端并携带 `state` 与 `token`
|
||||
|
||||
### 2) 客户端模型发现
|
||||
|
||||
- HeiCode 通过 `GET /v1/models` 拉取可用模型集合
|
||||
- Heicode 通过 `GET /v1/models` 拉取可用模型集合
|
||||
- 客户端不再依赖硬编码模型列表
|
||||
|
||||
## 快速运行（本地 Docker）
|
||||
@@ -43,18 +43,18 @@ docker compose logs -f new-api
|
||||
|
||||
默认访问地址：`http://localhost:3000`
|
||||
|
||||
## HeiCode 联调检查清单
|
||||
## Heicode 联调检查清单
|
||||
|
||||
- 平台已可正常登录 Web 控制台
|
||||
- `GET /heicode/oauth/authorize` 返回流程可达
|
||||
- `GET /heicode/oauth/session` 可反映登录态
|
||||
- `GET /v1/models` 返回模型列表不为空
|
||||
- HeiCode 客户端登录后可直接发起模型请求
|
||||
- Heicode 客户端登录后可直接发起模型请求
|
||||
|
||||
## 目录关注点
|
||||
|
||||
- `controller/heicode_oauth.go`：HeiCode 授权与会话检测核心逻辑
|
||||
- `router/heicode-router.go`：HeiCode OAuth 路由注册
|
||||
- `controller/heicode_oauth.go`：Heicode 授权与会话检测核心逻辑
|
||||
- `router/heicode-router.go`：Heicode OAuth 路由注册
|
||||
- `router/main.go`：总路由接入点
|
||||
- `docker-compose.override.yml`：本地开发构建入口
|
||||
|
||||
@@ -67,4 +67,4 @@ docker compose logs -f new-api
|
||||
|
||||
## 许可证与来源
|
||||
|
||||
本工程基于 `new-api` 上游能力演进，遵循对应许可证要求。企业使用前请完成内部合规审查。
|
||||
本工程在开源网关上游基础上演进（目录名 `new-api` 仅为历史路径），遵循对应许可证要求。企业使用前请完成内部合规审查。
|
||||
|
||||
+222
-2
@@ -174,8 +174,29 @@ nav a:hover {
|
||||
.lead {
|
||||
color: var(--muted);
|
||||
font-size: 1.08rem;
|
||||
max-width: 36rem;
|
||||
margin: 0 0 1.5rem;
|
||||
max-width: 40rem;
|
||||
margin: 0 0 1rem;
|
||||
}
|
||||
|
||||
.hero-suite {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 0.5rem;
|
||||
margin-bottom: 1.35rem;
|
||||
}
|
||||
|
||||
.suite-pill {
|
||||
font-size: 0.8rem;
|
||||
padding: 0.4rem 0.75rem;
|
||||
border-radius: 999px;
|
||||
background: rgba(61, 214, 198, 0.1);
|
||||
border: 1px solid rgba(61, 214, 198, 0.25);
|
||||
color: var(--text);
|
||||
}
|
||||
|
||||
.suite-pill strong {
|
||||
color: var(--accent);
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.hero-actions {
|
||||
@@ -243,6 +264,10 @@ section:nth-child(even) {
|
||||
margin: 0 0 2rem;
|
||||
}
|
||||
|
||||
.section-desc-wide {
|
||||
max-width: 52rem;
|
||||
}
|
||||
|
||||
.grid-3 {
|
||||
display: grid;
|
||||
gap: 1.25rem;
|
||||
@@ -270,6 +295,201 @@ section:nth-child(even) {
|
||||
font-size: 0.95rem;
|
||||
}
|
||||
|
||||
.card--accent-border {
|
||||
border-color: rgba(61, 214, 198, 0.35);
|
||||
background: rgba(18, 25, 32, 0.85);
|
||||
}
|
||||
|
||||
/* 核心能力矩阵 */
|
||||
.cap-grid {
|
||||
display: grid;
|
||||
gap: 1rem;
|
||||
}
|
||||
@media (min-width: 640px) {
|
||||
.cap-grid {
|
||||
grid-template-columns: repeat(2, 1fr);
|
||||
}
|
||||
}
|
||||
@media (min-width: 1000px) {
|
||||
.cap-grid {
|
||||
grid-template-columns: repeat(4, 1fr);
|
||||
}
|
||||
}
|
||||
|
||||
.cap-card {
|
||||
background: var(--bg-card);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
padding: 1.15rem 1.25rem;
|
||||
position: relative;
|
||||
padding-top: 2.25rem;
|
||||
min-height: 100%;
|
||||
}
|
||||
|
||||
.cap-card:hover {
|
||||
border-color: rgba(61, 214, 198, 0.35);
|
||||
}
|
||||
|
||||
.cap-num {
|
||||
position: absolute;
|
||||
top: 0.85rem;
|
||||
left: 1.25rem;
|
||||
font-family: var(--font-mono);
|
||||
font-size: 0.7rem;
|
||||
font-weight: 700;
|
||||
color: var(--accent);
|
||||
opacity: 0.85;
|
||||
}
|
||||
|
||||
.cap-card h3 {
|
||||
margin: 0 0 0.55rem;
|
||||
font-size: 1rem;
|
||||
line-height: 1.35;
|
||||
letter-spacing: -0.02em;
|
||||
}
|
||||
|
||||
.cap-card p {
|
||||
margin: 0;
|
||||
font-size: 0.88rem;
|
||||
color: var(--muted);
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
/* 核心优势对比 */
|
||||
.advantage-list {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0;
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
overflow: hidden;
|
||||
background: var(--bg-card);
|
||||
}
|
||||
|
||||
.adv-row {
|
||||
display: grid;
|
||||
gap: 1rem;
|
||||
padding: 1.25rem 1.35rem;
|
||||
border-bottom: 1px solid var(--border);
|
||||
}
|
||||
.adv-row:last-child {
|
||||
border-bottom: none;
|
||||
}
|
||||
@media (min-width: 900px) {
|
||||
.adv-row {
|
||||
grid-template-columns: minmax(140px, 180px) 1fr minmax(160px, 220px);
|
||||
align-items: start;
|
||||
gap: 1.5rem;
|
||||
}
|
||||
}
|
||||
|
||||
.adv-vs {
|
||||
font-size: 0.82rem;
|
||||
font-weight: 700;
|
||||
color: var(--warn);
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.04em;
|
||||
}
|
||||
|
||||
.adv-heicode {
|
||||
font-size: 0.95rem;
|
||||
color: var(--text);
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
.adv-heicode strong {
|
||||
color: var(--accent);
|
||||
}
|
||||
|
||||
.adv-gap {
|
||||
font-size: 0.85rem;
|
||||
color: var(--muted);
|
||||
line-height: 1.5;
|
||||
padding-left: 0;
|
||||
border-left: 3px solid rgba(143, 163, 184, 0.35);
|
||||
padding-left: 0.85rem;
|
||||
}
|
||||
|
||||
@media (max-width: 899px) {
|
||||
.adv-gap {
|
||||
border-left: none;
|
||||
padding-left: 0;
|
||||
padding-top: 0.5rem;
|
||||
border-top: 1px dashed var(--border);
|
||||
}
|
||||
}
|
||||
|
||||
/* 典型场景 */
|
||||
.scenario-grid {
|
||||
display: grid;
|
||||
gap: 1.25rem;
|
||||
}
|
||||
@media (min-width: 800px) {
|
||||
.scenario-grid {
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
}
|
||||
}
|
||||
|
||||
.scenario-card {
|
||||
background: var(--bg-elevated);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
padding: 1.35rem;
|
||||
}
|
||||
|
||||
.scenario-card h3 {
|
||||
margin: 0 0 0.65rem;
|
||||
font-size: 1.08rem;
|
||||
color: var(--text);
|
||||
}
|
||||
|
||||
.scenario-card > p {
|
||||
margin: 0 0 0.85rem;
|
||||
font-size: 0.92rem;
|
||||
color: var(--muted);
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
.scenario-ul {
|
||||
margin: 0;
|
||||
padding-left: 1.1rem;
|
||||
font-size: 0.88rem;
|
||||
color: var(--muted);
|
||||
line-height: 1.55;
|
||||
}
|
||||
|
||||
.scenario-ul li {
|
||||
margin-bottom: 0.35rem;
|
||||
}
|
||||
|
||||
/* 生命周期条 */
|
||||
.lifecycle-strip {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
align-items: center;
|
||||
gap: 0.35rem 0.5rem;
|
||||
margin-bottom: 1.5rem;
|
||||
padding: 1rem 1.25rem;
|
||||
border-radius: var(--radius);
|
||||
background: rgba(26, 34, 45, 0.55);
|
||||
border: 1px solid var(--border);
|
||||
font-size: 0.88rem;
|
||||
color: var(--text);
|
||||
justify-content: center;
|
||||
}
|
||||
|
||||
.lifecycle-arrow {
|
||||
color: var(--accent);
|
||||
opacity: 0.8;
|
||||
user-select: none;
|
||||
}
|
||||
|
||||
.team-note {
|
||||
margin: 1rem 0 0;
|
||||
font-size: 0.85rem;
|
||||
color: var(--muted);
|
||||
}
|
||||
|
||||
.arch-diagram {
|
||||
display: grid;
|
||||
gap: 1rem;
|
||||
|
||||
+234
-87
@@ -5,9 +5,9 @@
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<meta
|
||||
name="description"
|
||||
content="Heicode — 面向团队的智能体软件交付：New API、CLI/Desktop、Agnet 子智能体团队与全生命周期自动化。"
|
||||
content="Heicode — 组织级智能体软件交付：统一策略中枢 Heicode Manager、Heicode 终端/桌面客户端、可编排角色编队与全链路可追溯，覆盖规格到运维。"
|
||||
/>
|
||||
<title>Heicode · 智能体驱动的团队交付</title>
|
||||
<title>Heicode · 智能体驱动的团队软件交付</title>
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com" />
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
|
||||
<link
|
||||
@@ -27,15 +27,18 @@
|
||||
</a>
|
||||
<nav aria-label="主导航">
|
||||
<ul>
|
||||
<li><a href="#capabilities">产品能力</a></li>
|
||||
<li><a href="#advantages">核心优势</a></li>
|
||||
<li><a href="#scenarios">典型场景</a></li>
|
||||
<li><a href="#vision">愿景</a></li>
|
||||
<li><a href="#architecture">架构</a></li>
|
||||
<li><a href="#architecture">协作层次</a></li>
|
||||
<li><a href="#journey">体验路径</a></li>
|
||||
<li><a href="#teams">团队范式</a></li>
|
||||
<li><a href="#lifecycle">生命周期</a></li>
|
||||
<li><a href="#docs">文档</a></li>
|
||||
</ul>
|
||||
</nav>
|
||||
<a class="btn btn-primary" href="#cta">开始使用</a>
|
||||
<a class="btn btn-primary" href="#cta">了解范式</a>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
@@ -44,51 +47,180 @@
|
||||
<div class="wrap hero-grid">
|
||||
<div>
|
||||
<div class="badge-row">
|
||||
<span class="badge">New API</span>
|
||||
<span class="badge">CLI · Desktop</span>
|
||||
<span class="badge">Agnet</span>
|
||||
<span class="badge">多云交付</span>
|
||||
<span class="badge">组织交付</span>
|
||||
<span class="badge">策略中枢</span>
|
||||
<span class="badge">终端 + 桌面</span>
|
||||
<span class="badge">可编排编队</span>
|
||||
<span class="badge">全链路可追溯</span>
|
||||
</div>
|
||||
<h1>从想法到上线<br />用智能体团队完成整条交付链</h1>
|
||||
<h1>让「谁负责、何时签字、如何复盘」<br />默认成立</h1>
|
||||
<p class="lead">
|
||||
Heicode 将<strong>改造后的大模型网关</strong>、<strong>类 Claude Code 的终端与桌面客户端</strong>，以及
|
||||
<strong>Agnet 平台上的子智能体团队</strong>连成一体：需求、实现、测试、部署与运维在同一范式下可审计、可扩展。
|
||||
Heicode 面向<strong>多人协作与可追溯交付</strong>：把<strong>统一策略与账号（Heicode Manager）</strong>、<strong>同源终端与桌面体验（Heicode 客户端）</strong>，以及<strong>编排侧的角色编队与执行单元</strong>放进同一套范式——智能体放大<strong>标准化环节</strong>的吞吐，人在关键环节保留<strong>裁决与审计</strong>。
|
||||
</p>
|
||||
<p class="hero-suite">
|
||||
<span class="suite-pill"><strong>Manager</strong> 策略 · 模型 · 配额 · 渠道</span>
|
||||
<span class="suite-pill"><strong>Heicode</strong> CLI · Desktop · 本地服务</span>
|
||||
<span class="suite-pill"><strong>编排</strong> 瀑布 / 敏捷模板 · 执行单元</span>
|
||||
</p>
|
||||
<div class="hero-actions">
|
||||
<a class="btn btn-primary" href="#architecture">了解架构</a>
|
||||
<a class="btn btn-ghost" href="#teams">查看团队模板</a>
|
||||
<a class="btn btn-primary" href="#capabilities">查看能力矩阵</a>
|
||||
<a class="btn btn-ghost" href="#advantages">为何不同</a>
|
||||
</div>
|
||||
</div>
|
||||
<aside class="hero-panel" aria-label="集成示意">
|
||||
<div><span class="comment">// Heicode 集成骨架（示意）</span></div>
|
||||
<div><span class="key">platform</span>: {</div>
|
||||
<div> <span class="key">gateway</span>: <span class="str">"new-api"</span>,</div>
|
||||
<div> <span class="key">client</span>: <span class="str">"cc-haha-cli-desktop"</span>,</div>
|
||||
<div> <span class="key">agents</span>: <span class="str">"agnet-squads"</span>,</div>
|
||||
<div> <span class="key">clouds</span>: [<span class="str">"gcp"</span>, <span class="str">"aws"</span>, <span class="str">"azure"</span>]</div>
|
||||
<div>}</div>
|
||||
<aside class="hero-panel" aria-label="交付链路">
|
||||
<div><span class="comment"># 北极星（定性）</span></div>
|
||||
<div><span class="key">可追溯</span> <span class="str">决策 → 版本 / 发布锚点</span></div>
|
||||
<div><span class="key">可复述</span> <span class="str">闸门 · 角色 · 例外记录</span></div>
|
||||
<div><span class="key">可裁剪</span> <span class="str">编队规模随组织调整</span></div>
|
||||
<div><span class="comment"># 链路意象</span></div>
|
||||
<div><span class="key">align</span> → <span class="key">build</span> → <span class="key">ship</span> → <span class="key">learn</span></div>
|
||||
</aside>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="capabilities">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">核心能力矩阵</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
下列能力共同构成「组织级交付」闭环；实施时可按环境裁剪集成方式，但<strong>语义上</strong>应能回答：谁在何种策略下、对哪些资产、完成了何种闸门。
|
||||
</p>
|
||||
<div class="cap-grid">
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">01</span>
|
||||
<h3>统一策略与账号中枢（Heicode Manager）</h3>
|
||||
<p>集中管理账号、令牌、模型与渠道策略、计费与配额视图——避免「每人一套 Key、口径对不齐」导致的失控与浪费。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">02</span>
|
||||
<h3>同源终端与桌面（Heicode 客户端）</h3>
|
||||
<p>CLI 与 Desktop 共享会话与 Provider 逻辑，本地服务承载状态与扩展；降低「终端能跑、桌面另一套」的割裂成本。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">03</span>
|
||||
<h3>可编排角色编队</h3>
|
||||
<p>按瀑布或敏捷隐喻一键拉起「执行单元」队列，覆盖规格、架构、开发、测试、发布等闸门；规模可按组织工作坊裁剪。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">04</span>
|
||||
<h3>规格—发布全链路可追溯</h3>
|
||||
<p>推动 PRD、契约、评审结论、测试结果与发布记录<strong>对齐到分支 / Tag / 发布单元</strong>，支撑复盘、合规与责任界定。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">05</span>
|
||||
<h3>环境与多云的安全衔接</h3>
|
||||
<p>以最小权限连接仓库、流水线与运行环境；敏感变更走<strong>策略 + 审批</strong>，而非长期明文漫游凭证。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">06</span>
|
||||
<h3>人机闸门与设计态权限</h3>
|
||||
<p>生产变更、费用与高敏数据访问默认保留<strong>人在回路</strong>；智能体擅长提案与执行标准化路径，不默认无限代理权。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">07</span>
|
||||
<h3>多主体协作与状态可视</h3>
|
||||
<p>支持多执行单元、多会话协作时的任务与状态聚合视图——减少「黑盒跑脚本、出事找不到责任人」。</p>
|
||||
</article>
|
||||
<article class="cap-card">
|
||||
<span class="cap-num">08</span>
|
||||
<h3>范式优先、集成可替换</h3>
|
||||
<p>网关、编排平台与云厂商以<strong>契约</strong>相接；叙事强调交付范式与闸门，而非绑定单一供应商路线图。</p>
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="advantages">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">核心优势：相对常见路径多了什么</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
不是替代某一 IDE 插件或某一云平台，而是在<strong>协作语义</strong>上补齐缺口。
|
||||
</p>
|
||||
<div class="advantage-list">
|
||||
<div class="adv-row">
|
||||
<div class="adv-vs">相对「只有编码提效工具」</div>
|
||||
<div class="adv-heicode">
|
||||
<strong>Heicode</strong> 覆盖<strong>规格、质量、发布、运维</strong>的组织对齐；代码只是交付链上的一环。
|
||||
</div>
|
||||
<div class="adv-gap">单纯加速敲键盘无法回答「谁在何时对发布签字」。</div>
|
||||
</div>
|
||||
<div class="adv-row">
|
||||
<div class="adv-vs">相对「个人账户 + 散落脚本」</div>
|
||||
<div class="adv-heicode">
|
||||
<strong>Manager + 统一身份</strong>把模型调用、策略与审计收口到组织边界；减少密钥复制粘贴与责任悬空。
|
||||
</div>
|
||||
<div class="adv-gap">个人英雄路径难以规模化复盘与合规举证。</div>
|
||||
</div>
|
||||
<div class="adv-row">
|
||||
<div class="adv-vs">相对「只买云平台不加范式」</div>
|
||||
<div class="adv-heicode">
|
||||
提供<strong>瀑布 / 敏捷编队模板与闸门语义</strong>，团队知道「最小跑通」与「溢出如何拆 Squad」。
|
||||
</div>
|
||||
<div class="adv-gap">仅有资源没有协作语义，仍易出现断层与推诿。</div>
|
||||
</div>
|
||||
<div class="adv-row">
|
||||
<div class="adv-vs">相对「工具链堆叠无叙事」</div>
|
||||
<div class="adv-heicode">
|
||||
愿景文档与站点对齐<strong>北极星（可追溯 / 可复述 / 可裁剪）</strong>，产品与工程可在同一故事线下演进。
|
||||
</div>
|
||||
<div class="adv-gap">堆叠工具不等于交付方法论。</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="scenarios">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">典型场景</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
以下为<strong>叙事级</strong>示例；实际行业与合规要求以贵司治理为准。
|
||||
</p>
|
||||
<div class="scenario-grid">
|
||||
<article class="scenario-card">
|
||||
<h3>强合规与审计友好团队</h3>
|
||||
<p>需要把<strong>规格结论、变更记录、测试结果与发布包</strong>关联到可追溯锚点；Heicode 强调闸门与日志聚合维度，而非事后补材料。</p>
|
||||
<ul class="scenario-ul">
|
||||
<li>角色编队支撑独立 QA / 安全 / 文档签字</li>
|
||||
<li>策略中枢统一令牌与渠道口径</li>
|
||||
</ul>
|
||||
</article>
|
||||
<article class="scenario-card">
|
||||
<h3>高频迭代的产品研发</h3>
|
||||
<p>需要在短周期内保持<strong>「完成定义」一致</strong>；敏捷最小编队（3）到扩展编队（8）可按并行度上调，溢出拆 Squad。</p>
|
||||
<ul class="scenario-ul">
|
||||
<li>CI 门禁与发布候选可视化</li>
|
||||
<li>客户端内一致的模型发现与登录体验</li>
|
||||
</ul>
|
||||
</article>
|
||||
<article class="scenario-card">
|
||||
<h3>平台工程与多团队协作</h3>
|
||||
<p>多产品线共享<strong>模型策略与成本视图</strong>，同时避免互相踩踏环境与密钥；Manager 侧收口策略，编排侧按项目切分执行单元。</p>
|
||||
<ul class="scenario-ul">
|
||||
<li>配额与渠道策略共享视图</li>
|
||||
<li>环境晋升与最小权限默认立场</li>
|
||||
</ul>
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="vision">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">我们在解决什么问题</h2>
|
||||
<p class="section-desc">
|
||||
单一编码插件只能加速「写代码」；Heicode 面向<strong>团队与组织</strong>，把自动化扩展到规格、协作、质量门禁、多云发布与运维迭代，并形成可追溯的产物（文档、日志、多智能体沟通）。
|
||||
<h2 class="section-title">愿景：我们在解决什么问题</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
交付失败的根因常常是<strong>对齐失败</strong>而非编码不够快：规格与实现脱节、质量闸门含糊、发布无人认领、事后无法复盘。Heicode 把<strong>同一身份与策略边界</strong>、<strong>可编排的角色闸门</strong>与<strong>可追溯的产物锚点</strong>作为默认立场——智能体承接其中可标准化、可重复的劳动。
|
||||
</p>
|
||||
<div class="grid-3">
|
||||
<article class="card">
|
||||
<h3>统一账号与模型策略</h3>
|
||||
<p>登录改造后的 New API 控制台，管理令牌、配额与渠道策略，终端与桌面客户端与服务端对齐同一身份。</p>
|
||||
<article class="card card--accent-border">
|
||||
<h3>一元化策略</h3>
|
||||
<p>人机入口背后共享账号、配额与合规边界，避免「控制台口径不一致」导致的隐性风险。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>可编排的子智能体团队</h3>
|
||||
<p>在 Agnet 一键部署瀑布或敏捷模板（5～9 / 3～8 子 Agnet），按角色分工覆盖从需求到上线的闸门。</p>
|
||||
<article class="card card--accent-border">
|
||||
<h3>闸门可编排</h3>
|
||||
<p>瀑布 / 敏捷模板只是隐喻；关键是<strong>闸门不被静默跳过</strong>，角色可映射到执行单元。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>全生命周期与可审计</h3>
|
||||
<p>Git 与云资源在策略下自动化；交付物与版本、发布关联，支持多成员协作下的沟通与开发日志沉淀。</p>
|
||||
<article class="card card--accent-border">
|
||||
<h3>交付可审计</h3>
|
||||
<p>关键产物能与分支、标签或发布单元对齐，支撑复盘、责任界定与对内对外举证。</p>
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
@@ -96,31 +228,31 @@
|
||||
|
||||
<section id="architecture">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">逻辑架构</h2>
|
||||
<p class="section-desc">
|
||||
浏览器与 CLI/Desktop 共用网关能力；Agnet 承载子智能体编排；外部系统（Git、公有云、CI/CD）在最小权限原则下接入。
|
||||
<h2 class="section-title">协作层次（概念）</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
帮助分清<strong>人在哪里决策</strong>、<strong>执行单元在哪里接力</strong>、<strong>资产与环境在哪里托管</strong>——具体网关与云 implementation 可替换。
|
||||
</p>
|
||||
<div class="arch-diagram">
|
||||
<div class="arch-box">
|
||||
<h4>体验层</h4>
|
||||
<h4>人机入口</h4>
|
||||
<ul>
|
||||
<li>官网 / 文档</li>
|
||||
<li>New API 控制台</li>
|
||||
<li>CLI · Desktop（Tauri）</li>
|
||||
<li><strong>Heicode Manager</strong> 控制台（账号 · 配额 · 策略）</li>
|
||||
<li><strong>Heicode</strong> CLI / Desktop</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="arch-box">
|
||||
<h4>平台层</h4>
|
||||
<h4>编排与执行</h4>
|
||||
<ul>
|
||||
<li>改造后的 New API（账号 · 计费 · 中继）</li>
|
||||
<li>本地服务 / API 路由（cc-haha）</li>
|
||||
<li>角色模板与执行单元编队</li>
|
||||
<li>规格 · 质量 · 发布类闸门</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="arch-box">
|
||||
<h4>执行与基础设施</h4>
|
||||
<h4>资产与环境</h4>
|
||||
<ul>
|
||||
<li>Agnet：子智能体团队 · 有状态实例</li>
|
||||
<li>Git · GCP · AWS · Azure</li>
|
||||
<li>源码与制品仓库</li>
|
||||
<li>流水线与运行环境（最小权限）</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
@@ -129,28 +261,28 @@
|
||||
|
||||
<section id="journey">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">核心用户路径</h2>
|
||||
<p class="section-desc">从访问官网到持续迭代，目标体验拆成可落地的五步。</p>
|
||||
<h2 class="section-title">体验路径（目标图景）</h2>
|
||||
<p class="section-desc">从了解到持续迭代，期望形成闭环叙事（实施节奏以实际版本为准）。</p>
|
||||
<div class="flow">
|
||||
<div class="flow-step">
|
||||
<strong>发现</strong>
|
||||
<span>访问官网，了解范式与下载入口。</span>
|
||||
<span>了解范式、能力与下载入口。</span>
|
||||
</div>
|
||||
<div class="flow-step">
|
||||
<strong>登录控制台</strong>
|
||||
<span>进入改造后的 New API，查看令牌与策略。</span>
|
||||
<strong>登录 Manager</strong>
|
||||
<span>统一身份下查看配额、令牌与组织策略。</span>
|
||||
</div>
|
||||
<div class="flow-step">
|
||||
<strong>安装客户端</strong>
|
||||
<span>下载 CLI / Desktop，登录后与网关对齐会话。</span>
|
||||
<strong>安装 Heicode</strong>
|
||||
<span>CLI / Desktop 与会话、账号体系对齐。</span>
|
||||
</div>
|
||||
<div class="flow-step">
|
||||
<strong>部署子团队</strong>
|
||||
<span>在 Agnet 一键拉起瀑布或敏捷子 Agnet 队列。</span>
|
||||
<strong>拉起编队</strong>
|
||||
<span>编排侧启用瀑布或敏捷模板（含规模裁剪）。</span>
|
||||
</div>
|
||||
<div class="flow-step">
|
||||
<strong>交付与迭代</strong>
|
||||
<span>开发、测试、发布、观测与计划任务更新。</span>
|
||||
<span>开发、测试、发布、观测与持续改进。</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -158,14 +290,14 @@
|
||||
|
||||
<section id="teams">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">团队范式（子 Agnet）</h2>
|
||||
<p class="section-desc">
|
||||
规模设计兼顾协调成本：瀑布强调阶段闸门（最小 5、最大 9）；敏捷强调迭代闭环（最小 3、最大 8）。详细职责见仓库内愿景文档。
|
||||
<h2 class="section-title">团队范式（角色队列）</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
规模为<strong>协调复杂度提示</strong>：瀑布最小 <strong>5</strong>、最大 <strong>9</strong>；敏捷最小 <strong>3</strong>、最大 <strong>8</strong>。详细代号与职责表见仓库愿景文档<strong>附录</strong>。
|
||||
</p>
|
||||
<div class="team-grid">
|
||||
<div class="team-block">
|
||||
<div class="team-head">
|
||||
<h3>瀑布模式</h3>
|
||||
<h3>瀑布隐喻</h3>
|
||||
<span class="team-meta">最小 5 · 最大 9</span>
|
||||
</div>
|
||||
<div class="team-body">
|
||||
@@ -187,7 +319,7 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td><span class="role-tag">WF-DEV</span></td>
|
||||
<td>软件工程师（最小配置）</td>
|
||||
<td>软件工程师（最小编队）</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><span class="role-tag">WF-QA</span></td>
|
||||
@@ -199,14 +331,12 @@
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p style="margin: 1rem 0 0; font-size: 0.85rem; color: var(--muted)">
|
||||
最大配置扩展为 PM、前后端分立、安全、文档等专岗 — 详见文档第五节。
|
||||
</p>
|
||||
<p class="team-note">最大编队可含 PM、前后端分立、安全、文档等专岗。</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="team-block">
|
||||
<div class="team-head">
|
||||
<h3>敏捷模式</h3>
|
||||
<h3>敏捷隐喻</h3>
|
||||
<span class="team-meta">最小 3 · 最大 8</span>
|
||||
</div>
|
||||
<div class="team-body">
|
||||
@@ -232,9 +362,7 @@
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p style="margin: 1rem 0 0; font-size: 0.85rem; color: var(--muted)">
|
||||
最大配置增加 SM、Tech Lead、双轨 Dev、UX、SRE — 超出 8 人等价容量时拆第二支 Squad。
|
||||
</p>
|
||||
<p class="team-note">扩展时可加入 SM、Tech Lead、双轨 Dev、UX、SRE；溢出拆第二支 Squad。</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -243,13 +371,30 @@
|
||||
|
||||
<section id="lifecycle">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">软件生命周期</h2>
|
||||
<p class="section-desc">同一范式覆盖规格、实现、验证、发布、运维与迭代；敏感操作由策略与人机审批约束。</p>
|
||||
<h2 class="section-title">软件生命周期覆盖</h2>
|
||||
<p class="section-desc section-desc-wide">
|
||||
同一范式下串联<strong>构思 → 规格 → 实现 → 验证 → 发布 → 运维 → 迭代</strong>；敏感动作遵守策略与人机审批。
|
||||
</p>
|
||||
<div class="lifecycle-strip">
|
||||
<span>构思</span>
|
||||
<span class="lifecycle-arrow">→</span>
|
||||
<span>规格</span>
|
||||
<span class="lifecycle-arrow">→</span>
|
||||
<span>实现</span>
|
||||
<span class="lifecycle-arrow">→</span>
|
||||
<span>验证</span>
|
||||
<span class="lifecycle-arrow">→</span>
|
||||
<span>发布</span>
|
||||
<span class="lifecycle-arrow">→</span>
|
||||
<span>运维</span>
|
||||
<span class="lifecycle-arrow">→</span>
|
||||
<span>迭代</span>
|
||||
</div>
|
||||
<div class="lifecycle">
|
||||
<article class="card">
|
||||
<small>规格 · 协作</small>
|
||||
<h3>需求与设计</h3>
|
||||
<p>PRD、接口契约、风险与非功能需求落档，与子 Agnet 角色对齐。</p>
|
||||
<p>PRD、接口契约、风险与非功能需求落档，与角色模板对齐。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<small>构建 · 质量</small>
|
||||
@@ -258,8 +403,8 @@
|
||||
</article>
|
||||
<article class="card">
|
||||
<small>发布 · 运维</small>
|
||||
<h3>部署与迭代</h3>
|
||||
<p>多云发布、可观测、回滚与 Runbook；计划任务驱动持续迭代。</p>
|
||||
<h3>部署与持续运营</h3>
|
||||
<p>发布编排、可观测、回滚与 Runbook；计划任务驱动改进闭环。</p>
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
@@ -267,25 +412,27 @@
|
||||
|
||||
<section id="docs">
|
||||
<div class="wrap">
|
||||
<h2 class="section-title">文档与参考</h2>
|
||||
<h2 class="section-title">文档与自助</h2>
|
||||
<p class="section-desc">
|
||||
仓库内维护完整愿景与角色表；外部可参考 Claude Code 生态实践（如 oh-my-claudecode）。Agnet 与 New API 以实际部署环境为准。
|
||||
愿景、原则与编队明细见仓库；集成与部署以实际环境为准。
|
||||
</p>
|
||||
<div class="grid-3">
|
||||
<article class="card">
|
||||
<h3>愿景范式（仓库）</h3>
|
||||
<p><code>docs/vision-heicode-full-stack-agentic-dev.md</code></p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>Oh My Claude Code</h3>
|
||||
<h3>愿景与范式</h3>
|
||||
<p>
|
||||
<a href="https://ohmyclaudecode.com/" rel="noopener noreferrer" target="_blank">ohmyclaudecode.com</a>
|
||||
— 终端效率实践参考
|
||||
<code>docs/vision-heicode-full-stack-agentic-dev.md</code><br />
|
||||
方向、原则与附录中的编队参考。
|
||||
</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>工程 README</h3>
|
||||
<p><strong>Heicode Manager</strong>（<code>new-api/</code>）与 <strong>Heicode</strong> 客户端（<code>cc-haha/</code>）子目录说明。</p>
|
||||
</article>
|
||||
<article class="card">
|
||||
<h3>本地预览本站</h3>
|
||||
<p>在项目根目录执行 <code>docker compose up --build</code>，浏览器访问站点端口。</p>
|
||||
<p>
|
||||
<code>docker compose up --build</code> 或 <code>python3 -m http.server</code> 托管 <code>website/</code>。
|
||||
</p>
|
||||
</article>
|
||||
</div>
|
||||
</div>
|
||||
@@ -294,11 +441,11 @@
|
||||
<section class="cta" id="cta">
|
||||
<div class="wrap">
|
||||
<div class="cta-box">
|
||||
<h2>把「想法」连接到你的平台现实</h2>
|
||||
<h2>用范式对齐组织，而不是用口号代替交付</h2>
|
||||
<p>
|
||||
Heicode 正在把网关、客户端与 Agnet 团队揉合成一条可落地的交付链。下一步：冻结账号契约、打通一键部署与状态回传。
|
||||
Heicode 提供的是<strong>可追溯、可复述、可裁剪</strong>的协作语义，以及 Manager / 客户端 / 编排能力上的<strong>落地抓手</strong>。具体集成路线随环境而定，但北极星一致。
|
||||
</p>
|
||||
<a class="btn btn-primary" href="#architecture">返回架构</a>
|
||||
<a class="btn btn-primary" href="#capabilities">回到能力矩阵</a>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
@@ -306,8 +453,8 @@
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="wrap footer-row">
|
||||
<span>© Heicode · 智能体软件交付范式（静态预览站）</span>
|
||||
<span>本地 Docker 部署 · 仅用于产品与团队对齐</span>
|
||||
<span>© Heicode · 智能体软件交付</span>
|
||||
<span>静态站点 · 产品与团队对齐</span>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user