Initial commit
This commit is contained in:
Pine
@@ -0,0 +1,36 @@
|
||||
# 云超服 / PineAgents — 项目总览（Monorepo 根）
|
||||
|
||||
本目录是 **PineAgents / OPC 超级个体综合服务平台**（云南省 OPC 超级个体综合服务平台，云超服）的工作区根目录。整体由多个**独立 git 仓库**组成（非单一 monorepo），请勿在根目录 `git init` 或将子项目并入根仓库。
|
||||
|
||||
## 目录布局
|
||||
|
||||
| 目录 | 说明 | Git 远端 |
|
||||
|------|------|----------|
|
||||
| `PineAgentsServer/` | **总后端**。FastAPI 演示后端（认证转发、登录注册等），环境由 uv 管理。 | `origin` → `git@infoepoch:Pine/PineAgentsServer.git` |
|
||||
| `PineAgents/` | **核心部分**。前端 / 桌面端 / CLI 端。含 `console/`（PC 后台 UI 基调来源）。 | `infoepoch_lan` → `git@infoepoch_lan:Pine/PineAgents.git` |
|
||||
| `PineAgentsWeb/` | **网页展示端口**。Vite + React 静态站（SPA），源自 `PineAgents/website` 迁移。项目身份 `pineagents-web`。 | `origin` → `git@infoepoch:Pine/PineAgentsWeb.git` + `infoepoch_lan` → `git@infoepoch_lan:Pine/PineAgentsWeb.git` |
|
||||
| `reference/` | 项目参考文件。`cloud-opc/` = OPC 平台前端骨架；`PinePixel/` = 园区像素可视化。 | — |
|
||||
| `docs/` | **整体设计与相关文档**（架构、系统方案、设计规范）。 | — |
|
||||
|
||||
## 关键约定
|
||||
|
||||
- **UI 风格基调**：凡涉及前端设计的，**必须不偏离 `PineAgents/console/` 的主基调**（见其 `src/styles`、主题与组件体系）。不得另起一套视觉语言。
|
||||
- **文档位置**：整体的架构、系统设计、设计规范等文档一律放在 `docs/`。
|
||||
- **参考源**：园区像素可视化参考 `reference/PinePixel/`；OPC 平台前端骨架参考 `reference/cloud-opc/`。
|
||||
- **Git 远端规范**：远端遵循 `git@<host>:Pine/<ProjectName>.git`。存在两个主机：`infoepoch`（生产 Gitea，47.108.226.213）与 `infoepoch_lan`（局域网 Gitea，192.168.1.3）。新项目默认同时注册这两个远端，主远端命名 `origin`。
|
||||
- 后端在 `PineAgentsServer/`；`PineAgents/` 为主后端认证转发的来源（`src/pineagents/app/routers/auth.py` 将 `/api/auth/*` 转发到 `PineAgentsServer`，`PINEAGENTS_DEMO_BASE_URL` 默认 `http://127.0.0.1:8090`）。
|
||||
|
||||
## 常用操作
|
||||
|
||||
```bash
|
||||
# PineAgentsServer（uv 管理）
|
||||
cd PineAgentsServer && uv sync && uv run uvicorn app.main:app --port 8090 --reload
|
||||
|
||||
# PineAgents console（yarn）
|
||||
cd PineAgents/console && yarn dev
|
||||
|
||||
# PineAgentsWeb（pnpm / npm）
|
||||
cd PineAgentsWeb && pnpm install && pnpm run dev
|
||||
```
|
||||
|
||||
> 各子项目内部文档以各自的 `README.md` / `CLAUDE.md` 为准；本文件仅描述整体结构与跨项目约定。
|
||||
Submodule
+1
Submodule PineAgents added at 97c7f74edc
Submodule
+1
Submodule PineAgentsServer added at 145fe521eb
Submodule
+1
Submodule PineAgentsWeb added at 16a50b569e
@@ -0,0 +1,25 @@
|
||||
# 云超服 / PineAgents — 工作区
|
||||
|
||||
**OPC 超级个体综合服务平台（云南省 OPC 超级个体综合服务平台，云超服）** 的代码工作区。多仓库组合：后端、核心端、网页展示端彼此独立。
|
||||
|
||||
## 组成
|
||||
|
||||
- **`PineAgentsServer/`** — 总后端（FastAPI，uv 管理）。
|
||||
- **`PineAgents/`** — 核心部分：前端 / 桌面端 / CLI 端，含 UI 基调来源 `console/`。
|
||||
- **`PineAgentsWeb/`** — 网页展示端口（Vite + React 静态站，SPA）。
|
||||
- **`reference/`** — 参考：`cloud-opc/`（OPC 前端骨架）、`PinePixel/`（园区像素可视化）。
|
||||
- **`docs/`** — 整体设计与相关文档。
|
||||
|
||||
## 快速入口
|
||||
|
||||
| 模块 | 命令 |
|
||||
|------|------|
|
||||
| 后端 | `cd PineAgentsServer && uv sync && uv run uvicorn app.main:app --port 8090 --reload` |
|
||||
| 核心 console | `cd PineAgents/console && yarn dev` |
|
||||
| 网页展示端 | `cd PineAgentsWeb && pnpm install && pnpm run dev` |
|
||||
|
||||
## 约定
|
||||
|
||||
- 前端 UI 一律沿用 `PineAgents/console/` 主基调。
|
||||
- 整体设计文档放 `docs/`。
|
||||
- 各仓库独立提交；详细约定见根目录 `CLAUDE.md`。
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
version: "alpha"
|
||||
name: "Creative Cards"
|
||||
description: "Creative Cards Feature Section is designed for highlighting product capabilities and value points. Key features include reusable structure, responsive behavior, and production-ready presentation. It is suitable for component libraries and responsive product interfaces."
|
||||
colors:
|
||||
primary: "#FF7657"
|
||||
secondary: "#DFFF65"
|
||||
tertiary: "#F97316"
|
||||
neutral: "#FFFFFF"
|
||||
background: "#FFFFFF"
|
||||
surface: "#FF7657"
|
||||
text-primary: "#171714"
|
||||
text-secondary: "#77766F"
|
||||
border: "#171714"
|
||||
accent: "#FF7657"
|
||||
typography:
|
||||
display-lg:
|
||||
fontFamily: "Inter"
|
||||
fontSize: "68px"
|
||||
fontWeight: 500
|
||||
lineHeight: "68px"
|
||||
letterSpacing: "-0.05em"
|
||||
body-md:
|
||||
fontFamily: "Inter"
|
||||
fontSize: "14px"
|
||||
fontWeight: 400
|
||||
lineHeight: "22.75px"
|
||||
spacing:
|
||||
base: "12px"
|
||||
sm: "1px"
|
||||
md: "3.4px"
|
||||
lg: "12px"
|
||||
xl: "14.96px"
|
||||
gap: "12px"
|
||||
card-padding: "16px"
|
||||
section-padding: "32px"
|
||||
components:
|
||||
card:
|
||||
backgroundColor: "#1E1E1A"
|
||||
rounded: "20px"
|
||||
padding: "16px"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
- **Composition cues:**
|
||||
- Layout: Grid
|
||||
- Content Width: Full Bleed
|
||||
- Framing: Open
|
||||
- Grid: Strong
|
||||
|
||||
## Colors
|
||||
|
||||
The color system uses dark mode with #FF7657 as the main accent and #FFFFFF as the neutral foundation.
|
||||
|
||||
- **Primary (#FF7657):** Main accent and emphasis color.
|
||||
- **Secondary (#DFFF65):** Supporting accent for secondary emphasis.
|
||||
- **Tertiary (#F97316):** Reserved accent for supporting contrast moments.
|
||||
- **Neutral (#FFFFFF):** Neutral foundation for backgrounds, surfaces, and supporting chrome.
|
||||
|
||||
- **Usage:** Background: #FFFFFF; Surface: #FF7657; Text Primary: #171714; Text Secondary: #77766F; Border: #171714; Accent: #FF7657
|
||||
|
||||
- **Gradients:** bg-gradient-to-br from-white/80 to-black/5 via-white/20, bg-gradient-to-br from-white/10 to-black/40 via-black/0, bg-gradient-to-br from-white to-black/5 via-white
|
||||
|
||||
## Typography
|
||||
|
||||
Typography relies on Inter across display, body, and utility text.
|
||||
|
||||
- **Display (`display-lg`):** Inter, 68px, weight 500, line-height 68px, letter-spacing -0.05em.
|
||||
- **Body (`body-md`):** Inter, 14px, weight 400, line-height 22.75px.
|
||||
|
||||
## Layout
|
||||
|
||||
Layout follows a grid composition with reusable spacing tokens. Preserve the grid, full bleed structural frame before changing ornament or component styling. Use 12px as the base rhythm and let larger gaps step up from that cadence instead of introducing unrelated spacing values.
|
||||
|
||||
Treat the page as a grid / full bleed composition, and keep that framing stable when adding or remixing sections.
|
||||
|
||||
- **Layout type:** Grid
|
||||
- **Content width:** Full Bleed
|
||||
- **Base unit:** 12px
|
||||
- **Scale:** 1px, 3.4px, 12px, 14.96px, 16px, 24px, 32px, 45px
|
||||
- **Section padding:** 32px, 50px, 55px, 96px
|
||||
- **Card padding:** 16px, 32px
|
||||
- **Gaps:** 12px, 16px, 32px, 56px
|
||||
|
||||
## Elevation & Depth
|
||||
|
||||
Depth is communicated through elevated, border contrast, and reusable shadow or blur treatments. Keep those recipes consistent across hero panels, cards, and controls so the page reads as one material system.
|
||||
|
||||
Surfaces should read as elevated first, with borders, shadows, and blur only reinforcing that material choice.
|
||||
|
||||
- **Surface style:** Elevated
|
||||
- **Borders:** 1px #171714; 1px #FFFFFF
|
||||
- **Shadows:** rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.1) 0px 20px 25px -5px, rgba(0, 0, 0, 0.1) 0px 8px 10px -6px; rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.04) 0px 8px 30px 0px; rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.05) 0px 1px 2px 0px
|
||||
|
||||
### Techniques
|
||||
- **Gradient border shell:** Use a thin gradient border shell around the main card. Wrap the surface in an outer shell with 1px padding and a 32px radius. Drive the shell with linear-gradient(to right bottom, rgba(255, 255, 255, 0.8), rgba(255, 255, 255, 0.2), rgba(0, 0, 0, 0.05)) so the edge reads like premium depth instead of a flat stroke. Keep the actual stroke understated so the gradient shell remains the hero edge treatment. Inset the real content surface inside the wrapper with a slightly smaller radius so the gradient only appears as a hairline frame.
|
||||
|
||||
## Shapes
|
||||
|
||||
Shapes rely on a tight radius system anchored by 4px and scaled across cards, buttons, and supporting surfaces. Icon geometry should stay compatible with that soft-to-controlled silhouette.
|
||||
|
||||
Use the radius family intentionally: larger surfaces can open up, but controls and badges should stay within the same rounded DNA instead of inventing sharper or pill-only exceptions.
|
||||
|
||||
- **Corner radii:** 4px, 20px, 31px, 32px, 9999px
|
||||
- **Icon treatment:** Linear
|
||||
- **Icon sets:** Solar
|
||||
|
||||
## Components
|
||||
|
||||
Reuse the existing card surface recipe for content blocks.
|
||||
|
||||
### Cards and Surfaces
|
||||
- **Card surface:** background #1E1E1A, border 1px solid rgba(255, 255, 255, 0.2), radius 20px, padding 16px, shadow rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px, rgba(0, 0, 0, 0.25) 0px 25px 50px -12px.
|
||||
|
||||
### Iconography
|
||||
- **Treatment:** Linear.
|
||||
- **Sets:** Solar.
|
||||
|
||||
## Do's and Don'ts
|
||||
|
||||
Use these constraints to keep future generations aligned with the current system instead of drifting into adjacent styles.
|
||||
|
||||
### Do
|
||||
- Do use the primary palette as the main accent for emphasis and action states.
|
||||
- Do keep spacing aligned to the detected 12px rhythm.
|
||||
- Do reuse the Elevated surface treatment consistently across cards and controls.
|
||||
- Do keep corner radii within the detected 4px, 20px, 31px, 32px, 9999px family.
|
||||
|
||||
### Don't
|
||||
- Don't introduce extra accent colors outside the core palette roles unless the page needs a new semantic state.
|
||||
- Don't mix unrelated shadow or blur recipes that break the current depth system.
|
||||
- Don't exceed the detected moderate motion intensity without a deliberate reason.
|
||||
|
||||
## Motion
|
||||
|
||||
Motion feels controlled and interface-led across text, layout, and section transitions. Timing clusters around 700ms and 600ms. Easing favors ease and 0.2. Scroll choreography uses GSAP ScrollTrigger for section reveals and pacing.
|
||||
|
||||
**Motion Level:** moderate
|
||||
|
||||
**Durations:** 700ms, 600ms, 300ms, 500ms, 1000ms
|
||||
|
||||
**Easings:** ease, 0.2, 1), cubic-bezier(0.2, 0.8, 0
|
||||
|
||||
**Scroll Patterns:** gsap-scrolltrigger
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,600 @@
|
||||
# 云超服·平台全量方案设计（身份体系 · 端口管理 · 业务全流程）
|
||||
|
||||
> 依据《云南省OPC超级个体综合服务平台（云超服）系统设计方案》扩充为可落地的全量方案。
|
||||
> 本文档定义完整身份体系、六端口全部管理功能、业务对象状态机、数据模型、接口设计与横切能力，作为编码蓝本。
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
1. 总体设计
|
||||
2. 身份与账号体系
|
||||
3. 权限模型（RBAC + 数据范围 + 权限矩阵全表）
|
||||
4. 平台运营端管理
|
||||
5. 政务端管理（三级联动）
|
||||
6. 企业端管理（发标全流程）
|
||||
7. 服务商端管理（服务入驻 OPC）
|
||||
8. 载体端管理（管理载体内 OPC）
|
||||
9. OPC 端管理（全生命周期）
|
||||
10. 投资人端管理（投融资 · 线上路演 · 培训）
|
||||
11. 业务对象状态机
|
||||
12. 数据模型（库表设计）
|
||||
13. 接口设计概览
|
||||
14. 横切能力（通知/审计/信用/结算/合同/争议）
|
||||
15. 实施路线
|
||||
|
||||
---
|
||||
|
||||
## 1. 总体设计
|
||||
|
||||
### 1.1 目标
|
||||
构建云南省级「OPC 超级个体综合服务平台」，以六大端口服务 OPC 超级个体，实现政务三级联动、生态服务闭环、数据智能驱动。
|
||||
|
||||
### 1.2 设计原则
|
||||
- **一个核心**：OPC 超级个体为服务核心。
|
||||
- **两大驱动**：AI 智能体驱动 + 数据智能驱动。
|
||||
- **三大体系**：政务服务体系、生态服务体系、成长赋能体系。
|
||||
- **七大端口**：运营/政务/企业/服务商/载体/OPC/投资人，数据互通、权限隔离。
|
||||
- **三级联动**：省→市→区县，上级看下级，下级看本级及以下。
|
||||
- **身份即权限**：账号绑定多端口身份，登录选择、头像切换。
|
||||
|
||||
### 1.3 核心概念
|
||||
- **账号（Account）**：登录主体（手机号/用户名/微信等），一个账号可绑定多个端口身份。
|
||||
- **身份（Identity）**：账号在某端口的业务身份 = (port, role, sub_role, org, region)。
|
||||
- **组织（Organization）**：企业/服务商/载体的机构实体，身份可归属组织。
|
||||
- **数据范围（Scope）**：政务端按 region 层级推导可见数据。
|
||||
|
||||
---
|
||||
|
||||
## 2. 身份与账号体系
|
||||
|
||||
### 2.1 账号生命周期
|
||||
```
|
||||
注册 → 实名认证 → 绑定端口身份 → 登录(身份选择) → 运行(头像切换) → 注销/冻结
|
||||
```
|
||||
- 注册方式：手机号 / 微信 / 支付宝 / 电子社保卡。
|
||||
- 一个账号可同时绑定：运营 + 政务 + 企业 + 服务商 + 载体 + OPC 中多个身份（如 `pine` 全端口）。
|
||||
- 身份可被授权/回收（运营端/政务机构管理员操作）。
|
||||
|
||||
### 2.2 身份类型总表
|
||||
| port | role | sub_role | 职责要点 |
|
||||
|---|---|---|---|
|
||||
| operator | operator | op_super_admin / op_admin / op_customer_service / op_finance / op_analyst / op_techops | 平台全量管理 |
|
||||
| government | government | gov_province / gov_city / gov_district / gov_org_admin / gov_op_account | 三级政务 |
|
||||
| enterprise | enterprise | admin / operator | 企业需求方 |
|
||||
| provider | provider | admin / operator | 专业服务商 |
|
||||
| carrier | carrier | admin / operator | 创业载体 |
|
||||
| opc_member | opc_member | certified / independent | 超级个体 |
|
||||
| investor | investor | org_director / org_manager / personal | 机构/个人投资人 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 权限模型
|
||||
|
||||
### 3.1 权限码分类
|
||||
- `menu:*` 功能菜单（决定侧边栏可见性）。
|
||||
- `action:*` 操作权限（决定按钮/接口可用性）。
|
||||
- **数据范围**（`scope_region_ids`）：政务端由 region 推导「本级 + 后代」。
|
||||
|
||||
### 3.2 权限矩阵全表（`role|sub_role` → permissions）
|
||||
```
|
||||
operator|op_super_admin
|
||||
menu:operator_dashboard, menu:admin_user_mgmt, menu:admin_role_mgmt, menu:audit,
|
||||
menu:task_mgmt, menu:provider_mgmt, menu:content_mgmt, menu:policy_mgmt, menu:settle_mgmt, menu:system_config,
|
||||
action:user.*, action:role.*, action:task.audit, action:provider.audit, action:policy.publish,
|
||||
action:settle.release, action:config.*, action:audit.view, action:data.export
|
||||
operator|op_admin
|
||||
menu:task_mgmt, menu:provider_mgmt, menu:content_mgmt, menu:policy_mgmt,
|
||||
action:task.audit, action:provider.audit, action:content.manage, action:policy.publish
|
||||
operator|op_customer_service
|
||||
menu:ticket_mgmt, action:ticket.handle, action:dispute.handle
|
||||
operator|op_finance
|
||||
menu:settle_mgmt, action:settle.release, action:fund.deposit, action:commission.adjust
|
||||
operator|op_analyst
|
||||
menu:dashboard, menu:report, action:data.export, action:report.generate
|
||||
operator|op_techops
|
||||
menu:system_config, menu:audit, action:config.*, action:audit.view
|
||||
|
||||
government|gov_province
|
||||
menu:government_dashboard, menu:gov_data, menu:gov_carrier, menu:gov_policy, menu:gov_subsidy,
|
||||
action:data.view.all, action:carrier.audit, action:policy.publish, action:subsidy.approve
|
||||
government|gov_city
|
||||
menu:government_dashboard, menu:gov_data, menu:gov_carrier, menu:gov_policy, menu:gov_subsidy,
|
||||
action:data.view.city, action:carrier.audit, action:policy.publish, action:subsidy.approve
|
||||
government|gov_district
|
||||
menu:government_dashboard, menu:gov_data, menu:gov_carrier, menu:gov_policy,
|
||||
action:data.view.district, action:carrier.audit, action:opc.audit, action:policy.publish, action:subsidy.approve
|
||||
government|gov_org_admin
|
||||
menu:gov_admin, action:account.manage, action:data.view.org
|
||||
government|gov_op_account
|
||||
menu:government_dashboard, menu:gov_data, action:data.view.scope
|
||||
|
||||
enterprise|admin
|
||||
menu:enterprise_dashboard, menu:ent_task, menu:ent_talent, menu:ent_project,
|
||||
action:task.publish, action:task.bid.evaluate, action:fund.deposit, action:task.accept, action:org.manage
|
||||
enterprise|operator
|
||||
menu:enterprise_dashboard, menu:ent_task, menu:ent_talent, action:task.view, action:talent.search
|
||||
|
||||
provider|admin
|
||||
menu:provider_dashboard, menu:pro_service, menu:pro_order, menu:pro_client,
|
||||
action:service.manage, action:order.deliver, action:client.manage, action:settle.withdraw
|
||||
provider|operator
|
||||
menu:provider_dashboard, menu:pro_order, action:order.deliver, action:service.view
|
||||
|
||||
carrier|admin
|
||||
menu:carrier_dashboard, menu:car_opc, menu:car_space, menu:car_service,
|
||||
action:opc.bind, action:opc.audit, action:space.manage, action:service.refer
|
||||
carrier|operator
|
||||
menu:carrier_dashboard, menu:car_opc, action:opc.view, action:space.view
|
||||
|
||||
opc_member|certified
|
||||
menu:opc_dashboard, menu:opc_task, menu:opc_service, menu:opc_finance, menu:opc_policy,
|
||||
action:task.bid, action:task.deliver, action:service.buy, action:policy.apply, action:finance.view
|
||||
opc_member|independent
|
||||
menu:opc_dashboard, menu:opc_task, menu:opc_service,
|
||||
action:task.bid, action:service.buy
|
||||
|
||||
investor|org_director
|
||||
menu:investor_dashboard, menu:investor_projects, menu:investor_roadshow, menu:investor_training,
|
||||
action:preference.manage, action:project.view, action:intent.manage, action:roadshow.publish, action:roadshow.host, action:invest.decide
|
||||
investor|org_manager
|
||||
menu:investor_dashboard, menu:investor_projects, menu:investor_roadshow,
|
||||
action:preference.manage, action:project.view, action:intent.manage, action:roadshow.attend
|
||||
investor|personal
|
||||
menu:investor_dashboard, menu:investor_projects, menu:investor_roadshow, menu:investor_training,
|
||||
action:preference.manage, action:project.view, action:intent.manage, action:roadshow.attend, action:roadshow.register
|
||||
```
|
||||
|
||||
### 3.3 数据范围推导
|
||||
- 省级：`province` → 全省 region 后代。
|
||||
- 市级：`city` → 本市 + 所辖区县。
|
||||
- 区县级：`district` → 本区县。
|
||||
- 组织范围：企业/服务商/载体按 `org_id` 归属。
|
||||
- 越权访问一律 403；写操作落审计。
|
||||
|
||||
---
|
||||
|
||||
## 4. 平台运营端管理（总控中心）
|
||||
|
||||
### 4.1 用户与账号管理
|
||||
- 列表/搜索/分页/导出（手机号、角色、状态、注册时间）。
|
||||
- 绑定身份（为账号添加/移除端口身份）、分配角色/子角色、设组织与区域。
|
||||
- 启用/禁用/冻结账号、重置密码、吊销令牌。
|
||||
- 操作审计。
|
||||
|
||||
### 4.2 角色与权限管理
|
||||
- 角色 CRUD、角色-权限矩阵配置、子角色维护。
|
||||
- 权限码字典维护、按角色预览权限。
|
||||
|
||||
### 4.3 任务审核
|
||||
- 待审队列 → 通过/驳回（附原因）→ 违规任务下架 → 任务规则字典维护。
|
||||
|
||||
### 4.4 服务商准入与评级
|
||||
- 入驻申请审核（资质/能力/背景）→ 签订协议 → 开通后台。
|
||||
- 等级评定（认证/优质/金牌/官方）、升降级规则、黑名单。
|
||||
|
||||
### 4.5 内容与政策
|
||||
- 资讯/公告/活动管理；政策发布（平台级）。
|
||||
|
||||
### 4.6 数据大屏与报表
|
||||
- 全平台指标（用户/任务/成交额/服务商/载体/政策覆盖率）。
|
||||
- 多维分析（OPC/任务/政策）、排行、定期报表。
|
||||
|
||||
### 4.7 结算与资金
|
||||
- 资金托管台账、佣金比例配置、结算流水、提现审核、对账。
|
||||
|
||||
### 4.8 系统配置
|
||||
- 全局参数、字典、审批流配置、平台费率、通知模板。
|
||||
|
||||
### 4.9 工单与审计
|
||||
- 客服工单流转、争议仲裁；全量审计日志（按人/按对象检索、导出）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 政务端管理（三级联动）
|
||||
|
||||
### 5.1 数据看板（按范围）
|
||||
- 核心指标：OPC 总数/新增/活跃、载体数、任务数、成交额、政策覆盖率。
|
||||
- 分布/趋势/排行（区县/载体/行业）。
|
||||
|
||||
### 5.2 载体管理
|
||||
- 范围内载体列表/详情；入驻审核；等级评定；空间与入驻率数据。
|
||||
|
||||
### 5.3 OPC 管理
|
||||
- 范围内 OPC 列表/详情；入驻审核；认证状态；信用/活跃度。
|
||||
|
||||
### 5.4 政策发布（多级审核）
|
||||
```
|
||||
起草 → 内部审核 → 上级/本级发布 → 定向推送(匹配OPC) → AI+人工解读 → 效果追踪(触达/申报/兑现)
|
||||
```
|
||||
|
||||
### 5.5 补贴管理
|
||||
- 补贴政策配置 → OPC 申报 → 初审(区县) → 复审(市) → 终审(省) → 发放 → 追踪。
|
||||
|
||||
### 5.6 收入/交易数据
|
||||
- 范围内任务成交额、服务商订单额、载体营收，按时间/区域聚合。
|
||||
|
||||
### 5.7 审计
|
||||
- 本级及下级操作日志；数据导出。
|
||||
|
||||
---
|
||||
|
||||
## 6. 企业端管理（发标全流程）
|
||||
|
||||
### 6.1 企业档案
|
||||
- 企业介绍、资质、LOGO、联系方式；管理员维护，操作者查看。
|
||||
|
||||
### 6.2 人才搜索
|
||||
- 按技能/行业/信用/地域/档期搜索 OPC；查看档案、历史交付、评价；收藏/邀请。
|
||||
|
||||
### 6.3 任务发布（发标）— 状态机
|
||||
```
|
||||
draft → pending(审核) → published
|
||||
→ 接单: grab(抢单) / bid(竞标) / designated(指定) / dispatch(派单)
|
||||
→ in_progress → delivered → review(验收)
|
||||
├ 通过 → completed(结算+评价)
|
||||
├ 驳回 → in_progress(限期修改)
|
||||
└ 争议 → 平台仲裁
|
||||
→ cancelled(违约/超时)
|
||||
```
|
||||
|
||||
### 6.4 发标校验规则
|
||||
- 分类必填、预算 `0 < min ≤ max`、托管金 ≥ 预算下限、deadline > now、合规审核。
|
||||
- 竞标：≥1 标书才可评标；未中标释放保证金。
|
||||
- 违约：超时/恶意 → 扣信用、扣保证金。
|
||||
|
||||
### 6.5 项目管理
|
||||
- 任务看板（状态/进度/交付物）、阶段沟通、验收（通过/驳回/修改）、评价、结算查看。
|
||||
|
||||
### 6.6 合同与保障
|
||||
- 电子合同签署、资金托管、履约险、争议处理、知识产权约定。
|
||||
|
||||
---
|
||||
|
||||
## 7. 服务商端管理（为入驻 OPC 提供服务）
|
||||
|
||||
### 7.1 服务商品管理
|
||||
- 商品类型：标准化/定制/订阅/按次/免费。
|
||||
- 商品 CRUD、定价、上下架、案例、评价聚合。
|
||||
|
||||
### 7.2 订单与交付
|
||||
- 订单状态机：`pending(待支付) → paid(已支付/托管) → delivering(服务中) → delivered(已交付) → confirmed(已确认) → settled(已结算) / refunding(退款)`。
|
||||
- 服务对象管理：为入驻 OPC 建立服务关系、跟进记录。
|
||||
|
||||
### 7.3 客户运营
|
||||
- 服务过的 OPC 列表、续费提醒、回访记录、评价管理。
|
||||
|
||||
### 7.4 结算与评级
|
||||
- 订单收入、提现、平台佣金；服务评分与等级升降。
|
||||
|
||||
### 7.5 服务品类
|
||||
- 财税 / 工商 / 法务 / 知识产权 / 云服务 / 算力 / 培训。
|
||||
|
||||
---
|
||||
|
||||
## 8. 载体端管理（管理载体内 OPC）
|
||||
|
||||
### 8.1 入驻 OPC 管理
|
||||
- 入驻申请审核、绑定关系管理、解绑；工位分配。
|
||||
- OPC 状态：`申请中 → 已入驻 → 已迁出`。
|
||||
|
||||
### 8.2 空间/工位管理
|
||||
- 工位总数/在用/空闲、入驻率、收费标准。
|
||||
|
||||
### 8.3 服务对接
|
||||
- 引荐服务商给园区内 OPC（三方绑定：载体-服务商-OPC）；服务进度跟踪。
|
||||
|
||||
### 8.4 园区数据
|
||||
- 入驻率、订单、营收、政策申报统计；对外展示载体简介。
|
||||
|
||||
---
|
||||
|
||||
## 9. OPC 端全量功能设计（超级个体全生命周期工作台）
|
||||
|
||||
OPC 端是平台**服务核心**，以「档案-任务-财税-工商-政务-智能体」为主线，提供创业经营一站式工作台。
|
||||
|
||||
### 9.1 基础资料编辑
|
||||
**功能**：维护个人与经营资料，支撑信用、认证、任务匹配。
|
||||
- **基本资料**：姓名/头像/联系方式/简介/自我介绍。
|
||||
- **经营资料**：经营类型（个人创业者/个体工商户/自由职业者/小微经营者/灵活就业）、行业领域、所在区域、技能标签（多选+自定义）、服务能力、作品/案例、可接单档期。
|
||||
- **联系方式**：手机号（登录绑定）、微信/邮箱（可选）。
|
||||
- **资料可见性**：对企业/载体展示的公开字段可单独开关；私密字段（身份证等）仅本人/认证可用。
|
||||
- **校验**：昵称/简介长度、技能标签数上限、区域必填；修改记录留痕。
|
||||
|
||||
**字段**：`opc_profiles(id, user_id, real_name, avatar, intro, biz_type, industry, region_id, skills[], cases[], schedule, cert_status, credit_score, ...)`
|
||||
|
||||
### 9.2 认证体系
|
||||
- **实名认证**：身份证 OCR + 人脸活体 → `unverified → verifying → verified`。
|
||||
- **工商认证（可选）**：营业执照 OCR + 市场监管局核验 → `无 → 待核验 → 已认证`。
|
||||
- **技能/资质认证**：上传资质证书、平台技能测试 → 技能标签获得官方背书。
|
||||
- 认证影响：认证 OPC（`certified`）可绑载体、投标权重更高、可申报补贴；未认证为 `independent`。
|
||||
|
||||
### 9.3 载体绑定
|
||||
- 自主选择载体申请入驻 / 载体邀请绑定 / 平台推荐。
|
||||
- 状态：`未绑定 → 申请中 → 已入驻(认证OPC可绑) → 已迁出`。
|
||||
- 绑定后：工位信息、载体服务、载体数据归属、园区政策申报。
|
||||
|
||||
### 9.4 接单（抢单 / 指定 / 派单）
|
||||
**接单模式与规则**：
|
||||
| 模式 | 流程 | 规则 |
|
||||
|---|---|---|
|
||||
| 抢单 grab | OPC 在广场抢单 | 先到先得；同一 OPC 并发抢单加锁防重复；抢到即进入执行 |
|
||||
| 指定 designated | 企业指定 OPC | OPC 确认接受 / 拒绝；限时确认 |
|
||||
| 派单 dispatch | 平台智能派单 | 平台按匹配度派给 OPC；可接受/拒绝 |
|
||||
| 竞标 bid | 见 9.5 | 投标→企业选标→中标进入执行 |
|
||||
|
||||
- 抢单校验：任务状态=published、OPC 未被拉黑、任务未满额、无进行中冲突（可选）。
|
||||
- 接单后：任务状态 → `in_progress`，生成项目空间与里程碑。
|
||||
|
||||
### 9.5 投标（竞标）
|
||||
**投标流程**：
|
||||
```
|
||||
查看竞标任务 → 提交标书(方案/报价/周期/承诺) → 待评标
|
||||
→ 中标 won → 签署/进入执行
|
||||
→ 未中标 lost → 释放(若缴纳投标保证金则退回)
|
||||
→ 撤回 withdrawn
|
||||
```
|
||||
- **标书字段**：报价、交付周期、方案说明、附件、可交付样例。
|
||||
- **校验**：报价 ∈ 企业预算范围、周期 ≤ 任务截止、资质/信用达标、未重复投标同一任务。
|
||||
- **投标状态**：`draft → submitted → won / lost / withdrawn`。
|
||||
- 中标后锁定任务；未中标自动释放保证金。
|
||||
|
||||
### 9.6 任务进度管理
|
||||
**项目空间**（任务 `in_progress` 后建立）：
|
||||
- **里程碑**：按任务分期设置里程碑（计划/实际、状态）。
|
||||
- **进度更新**：OPC 更新进度百分比、填写说明、标记阶段完成。
|
||||
- **交付物**：上传交付文件/说明 → `delivered`。
|
||||
- **阶段沟通**：与企业消息往来、@企业、附件。
|
||||
- **验收**：企业通过 → 进入结算；驳回 → 限期修改（最多 N 次）；争议 → 平台仲裁。
|
||||
- **时间线**：全流程节点留痕（时间/动作/操作者）。
|
||||
|
||||
### 9.7 财税管理
|
||||
**功能模块**：
|
||||
- **一键记账**：发票/交易流水自动归集 → 生成凭证；手动补充收支。
|
||||
- **财务报表**：利润表、资产负债表、现金流量表（月/季/年）。
|
||||
- **税务申报**：申报周期提醒、申报表预填、在线申报、申报记录。
|
||||
- **发票管理**：开票申请、进项/销项发票归集、抬头管理。
|
||||
- **收支明细**：`finance_records(category=income|expense, amount, date, note, source)`；月/年聚合、图表。
|
||||
- **税务日历**：报税/缴费节点提醒。
|
||||
|
||||
### 9.8 工商与政务管理
|
||||
- **工商服务**（对接服务商/政务）：公司注册、变更登记、年报公示、注销登记、资质办理。
|
||||
- **办事流程**：发起事项 → 材料上传 → 服务商/政务办理 → 进度追踪 → 结果反馈。
|
||||
- **政策服务**：政策库浏览、**智能匹配**（按行业/区域/认证）、一键申报、申报进度追踪、补贴到账。
|
||||
- **政务事项**：区县级政务端可查看本区县 OPC 的办事/申报记录；补贴三级审批结果反馈。
|
||||
- **办事状态**：`draft → submitted → processing → done / rejected`。
|
||||
|
||||
### 9.9 服务购买
|
||||
- 服务市场浏览/搜索/下单 → 支付（资金托管）→ 服务商交付 → 确认 → 评价。
|
||||
|
||||
### 9.10 信用与金融
|
||||
- **信用画像**：履约（按时交付/验收通过率）、评价（服务商/企业互评）、违规记录；信用等级与积分。
|
||||
- **信用应用**：推荐权重、保证金比例、权限（认证/补贴）、违约惩戒。
|
||||
- **金融**：融资产品浏览/智能匹配、支付结算、保险、信用贷。
|
||||
|
||||
### 9.11 消息与智能体
|
||||
- **消息中心**：任务/政策/订单/补贴/系统通知（站内信+推送）。
|
||||
- **智能体助手**：个性化记忆、工具调用；创业助手（政策/补贴）、经营管家（财税/订单）、任务经纪人（接单/投标建议）、学习教练（技能提升）。
|
||||
|
||||
### 9.12 OPC 端状态机（对象级）
|
||||
| 对象 | 状态流 |
|
||||
|---|---|
|
||||
| 实名认证 | unverified / verifying / verified |
|
||||
| 工商认证 | none / verifying / certified |
|
||||
| 载体绑定 | unbound / applying / joined / exited |
|
||||
| 投标 | draft / submitted / won / lost / withdrawn |
|
||||
| 任务(承接) | published / in_progress / delivered / review / completed / cancelled / disputed |
|
||||
| 交付物 | uploading / submitted / reviewing / accepted / rejected |
|
||||
| 财税申报 | draft / submitted / filed / failed |
|
||||
| 办事(工商/政务) | draft / submitted / processing / done / rejected |
|
||||
| 服务订单(购买) | pending / paid / delivering / delivered / confirmed / settled |
|
||||
|
||||
**OPC 端接口**：`/opc/profile`(读)、`PUT /opc/profile`(编辑)、`POST /opc/verify`(认证)、`POST /opc/carrier/apply`(绑载体)、`GET /opc/tasks`(广场)、`POST /opc/tasks/{id}/grab`(抢单)、`POST /opc/tasks/{id}/bid`(投标)、`GET /opc/my-tasks`、`POST /opc/tasks/{id}/progress`(进度)、`POST /opc/tasks/{id}/deliver`(交付)、`GET /opc/finance`、`POST /opc/finance/record`、`GET /opc/tax`、`POST /opc/affairs`(工商/办事)、`GET /opc/policy`、`POST /opc/policy/{id}/apply`(申报)、`GET /opc/services`、`POST /opc/services/{id}/order`、`GET /opc/messages`、`GET /opc/agent`。
|
||||
|
||||
---
|
||||
|
||||
## 10. 投资人端全量功能设计（投融资 · 线上路演 · 培训）
|
||||
|
||||
投资人端连接**资本与创业项目**，支持机构/个人投资人设定投资方向、查看项目、投融资对接、发布与参与线上路演、以及投融资培训。
|
||||
|
||||
### 10.1 投资人身份与认证
|
||||
| sub_role | 名称 | 说明 |
|
||||
|---|---|---|
|
||||
| `org_director` | 机构投资总监 | 投资决策、活动发布/主持 |
|
||||
| `org_manager` | 机构投资经理 | 项目筛选、约谈、尽调、参会 |
|
||||
| `personal` | 个人投资人 | 天使投资、跟投、参会 |
|
||||
- 机构认证：营业执照/基金资质、投资领域、管理规模。
|
||||
- 个人认证：实名、投资经历、可投资金区间。
|
||||
|
||||
### 10.2 投资方向设置（preference）
|
||||
- **领域偏好**：云计算/人工智能/生物医药/文旅/农业科技/智能制造/新能源/消费等（多选）。
|
||||
- **阶段偏好**：种子 / 天使 / A轮 / B轮 / 成长期。
|
||||
- **金额区间**：单笔投资 min–max。
|
||||
- **地域偏好**：省/市/区县（默认云南省内）。
|
||||
- **关注信号**：收到匹配项目/路演推送。
|
||||
|
||||
### 10.3 项目查看（投融资对接）
|
||||
- **项目库**：展示融资项目（来源：OPC/企业/载体上架项目），含：项目名、团队、行业、阶段、融资额、估值、BP（商业计划书）、亮点、融资进度。
|
||||
- **筛选/搜索**：按行业/阶段/融资金额/地域/认证。
|
||||
- **项目详情**：BP 阅读、团队、财务/经营数据（授权后）、融资状态。
|
||||
- **收藏/关注**、**约谈**（发起意向 → 对方确认 → 私聊/会议）。
|
||||
|
||||
### 10.4 投资意向与流程
|
||||
```
|
||||
感兴趣 interested → 已约谈 contacted → 尽调/会面 meeting → 意向书 term_sheet → 已投资 invested / 已婉拒 declined
|
||||
```
|
||||
- 意向记录：约谈时间、沟通纪要、BP 版本。
|
||||
- 尽调：资料清单、进度、风险评估。
|
||||
- 投资决策：额度、估值、条款（机构总监决策）。
|
||||
|
||||
### 10.5 投融资活动（线上/线下）全流程
|
||||
|
||||
**发布主体与范围**
|
||||
| 发布主体 | 允许的活动范围 | 审核要求 |
|
||||
|---|---|---|
|
||||
| 投资机构 | 全网 / 指定载体/区域 | 一律需**运营方审核**（第三方商业活动） |
|
||||
| 政务（省/市/区县） | 自身权限范围（region 内） | **免审直发**（自己权限内） |
|
||||
| 政务 | 超出自身范围（全省/全网） | 需**运营方审核** |
|
||||
| 平台运营方 | 全平台 | 免审（运营方内部走多级审批可选） |
|
||||
| 载体/企业 | 自身关联范围 | 需运营方审核 |
|
||||
|
||||
**活动类型**
|
||||
- **线上** `online`：直播推流 / 在线会议室 / 连麦 / 回放。
|
||||
- **线下** `offline`：场地、地址、到会签到。
|
||||
- **混合** `hybrid`：线上直播 + 线下会场。
|
||||
|
||||
**发布与审核状态机**
|
||||
```
|
||||
draft 草稿
|
||||
→（免审主体）→ published 已发布
|
||||
→（需审主体）→ submitted 待审 → reviewing 审核中
|
||||
├→ published 已发布
|
||||
├→ rejected 已驳回（附原因 → 退回 draft 修改后重提）
|
||||
└→ cancelled 已取消
|
||||
published → registering 报名中 → ongoing 进行中 → ended 已结束 → archived 已归档
|
||||
（任意阶段可 cancelled 下架）
|
||||
```
|
||||
|
||||
**范围校验与免审规则**
|
||||
- 规则：`活动范围 ⊆ 发布者数据范围` 则**免审**，否则**需审核**。
|
||||
- 政务发布：范围 = 自身 region（省级=全省、市级=本市、区县=本区县）→ 免审；跨级/全网 → 提交审核（市级跨区→省级可审或运营方；全网→运营方）。
|
||||
- 运营方发布：全平台范围 = 运营方权限 → 免审（内部多级审批可选）。
|
||||
- 投资机构/载体/企业：活动范围不论如何均需运营方审核。
|
||||
- 校验实现：`need_review = not (publisher_is_government and scope ⊆ publisher.scope_region_ids) and not publisher_is_operator`。
|
||||
|
||||
**活动信息与校验**
|
||||
- 字段：主题、简介、活动类型（online/offline/hybrid）、开始/结束时间、报名截止、名额、地点/直播间、主持人/嘉宾、BP 要求、可见范围、发布主体。
|
||||
- 校验：`start < end`、非过去时间、`报名截止 < 开始`、名额为正、内容合规（违禁/敏感）、范围合法。
|
||||
|
||||
**报名与可见性**
|
||||
- 可见范围：全网 / 指定区域 OPC / 指定载体 / 指定投资人。
|
||||
- 报名角色：项目方（路演，需上传 BP）、投资人（参会）；状态 `applying → approved → attended → absent`。
|
||||
- 校验：名额、截止时间、可见范围、身份。
|
||||
|
||||
**审核与审计**
|
||||
- 审核记录（审核人/时间/意见/版本）、多级审批可选、操作审计；驳回原因回填、支持修改重提。
|
||||
|
||||
**线上路演执行**
|
||||
- 在线会议室/直播（推流、连麦）、项目依次路演、计时器、一键约谈、提问互动、数据统计、回放归档。
|
||||
|
||||
**活动运营**
|
||||
- 参会名单、项目榜单、路演评分、回放管理、活动数据（观看/约谈/意向转化）。
|
||||
|
||||
### 10.6 投融资培训系统
|
||||
- **课程库**：投融资基础、BP 撰写、估值与条款、尽调实务、路演技巧、股权结构、法律合规（视频/直播/资料）。
|
||||
- **培训对象**：投资人（进阶）、项目方/OPC（融资准备）、载体（孵化辅导）。
|
||||
- **课程分类 / 报名 / 学习进度 / 证书**。
|
||||
- **导师辅导**：资深投资人/创业导师约课、1v1 辅导。
|
||||
|
||||
### 10.7 投资组合与数据
|
||||
- **我的投资**：已投项目跟踪（阶段、估值、退出）、投资金额汇总。
|
||||
- **数据看板**：关注项目数、意向转化率、活动参与、投资概况。
|
||||
|
||||
### 10.8 状态机（投资人端对象）
|
||||
| 对象 | 状态流 |
|
||||
|---|---|
|
||||
| 项目融资 | raising / roadshowing / negotiating / closed / withdrawn |
|
||||
| 投资意向 | interested / contacted / meeting / term_sheet / invested / declined |
|
||||
| 路演活动 | draft / submitted / reviewing / published / registering / ongoing / ended / archived（可 rejected / cancelled） |
|
||||
| 活动报名 | applying / approved / attended / absent |
|
||||
| 培训课程 | draft / published / ended |
|
||||
| 培训报名 | applying / enrolled / completed / certificate |
|
||||
|
||||
### 10.9 数据模型（投资人端）
|
||||
- `investors`（投资人档案/机构或个人）、`investment_preferences`（投资方向偏好）。
|
||||
- `projects`（融资项目）、`financing_rounds`（融资轮次）、`project_bps`（BP 版本）。
|
||||
- `investment_intents`（投资意向/约谈/尽调）。
|
||||
- `roadshows`（路演活动）、`roadshow_registrations`（报名）、`roadshow_sessions`（项目路演场次）、`roadshow_replays`（回放）。
|
||||
- `trainings`（培训课程）、`training_enrollments`（报名/进度/证书）。
|
||||
|
||||
### 10.10 接口（投资人端）
|
||||
`/investor/profile`(读)、`PUT /investor/profile`、`PUT /investor/preferences`、`GET /investor/projects`、`GET /investor/projects/{id}`、`POST /investor/projects/{id}/intent`(约谈)、`GET /investor/intents`、`POST /investor/roadshows`(发布)、`GET /investor/roadshows`、`POST /investor/roadshows/{id}/register`(报名)、`GET /investor/roadshows/{id}/live`(线上路演)、`POST /investor/roadshows/{id}/live/join`、`GET /investor/trainings`、`POST /investor/trainings/{id}/enroll`、`GET /investor/portfolio`。
|
||||
|
||||
---
|
||||
|
||||
## 11. 业务对象状态机汇总
|
||||
|
||||
| 对象 | 状态流 |
|
||||
|---|---|
|
||||
| 账号 | active / disabled / frozen / deleted |
|
||||
| 身份 | active / disabled |
|
||||
| 入驻(OPC/载体/服务商) | applying / reviewing / approved / rejected / active / exited |
|
||||
| 任务 | draft / pending / published / in_progress / delivered / review / completed / cancelled / disputed |
|
||||
| 竞标 | submitted / shortlisted / won / lost / released |
|
||||
| 订单(服务) | pending / paid / delivering / delivered / confirmed / settled / refunding / cancelled |
|
||||
| 服务商品 | draft / on_sale / off_sale |
|
||||
| 政策 | draft / reviewing / published / offline |
|
||||
| 补贴申报 | applying / district_review / city_review / province_review / approved / paid / rejected |
|
||||
| 托管金 | deposited / frozen / released / refunded |
|
||||
| 投标(竞标) | draft / submitted / won / lost / withdrawn |
|
||||
| 交付物 | uploading / submitted / reviewing / accepted / rejected |
|
||||
| 实名认证 | unverified / verifying / verified |
|
||||
| 工商认证 | none / verifying / certified |
|
||||
| 载体绑定 | unbound / applying / joined / exited |
|
||||
| 财税申报 | draft / submitted / filed / failed |
|
||||
| 工商/政务办事 | draft / submitted / processing / done / rejected |
|
||||
| 争议 | opened / mediating / resolved / closed |
|
||||
| 工单 | opened / processing / resolved / closed |
|
||||
| 项目融资 | raising / roadshowing / negotiating / closed / withdrawn |
|
||||
| 投资意向 | interested / contacted / meeting / term_sheet / invested / declined |
|
||||
| 路演活动 | draft / submitted / reviewing / published / registering / ongoing / ended / archived（可 rejected / cancelled） |
|
||||
| 活动报名 | applying / approved / attended / absent |
|
||||
| 培训课程 / 报名 | draft / published / ended · applying / enrolled / completed / certificate |
|
||||
|
||||
---
|
||||
|
||||
## 12. 数据模型（库表设计）
|
||||
|
||||
核心表（承接现有 `user_identities` / `users` / `organizations` / `regions`）：
|
||||
- `accounts`（账号）、`user_identities`（身份）、`sessions`（会话）。
|
||||
- `organizations`（企业/服务商/载体）、`regions`（省市区树）、`opc_profiles`（信用/认证）。
|
||||
- `tasks`（任务，含 `mode/status/budget/deadline/托管` 字段）、`bids`（竞标：报价/方案/周期/状态）、`deliveries`（交付物：文件/说明/状态/验收）、`escrows`（托管金台账）、`milestones`（任务里程碑）。
|
||||
- `service_products`（服务商品）、`service_orders`（服务订单）、`service_relations`（载体-服务商-OPC 三方绑定）。
|
||||
- `content_items`（政策/资讯）、`policies`（政策详情）、`subsidy_applications`（补贴申报）。
|
||||
- `opc_profiles`（基础资料/技能/认证/信用）、`opc_carrier`（载体绑定关系）、`opc_affairs`（工商/政务办事）、`tax_records`（财税申报）、`finance_records`（收支流水）。
|
||||
- `investors`（投资人档案/机构或个人）、`investment_preferences`（投资方向）、`projects`（融资项目）、`financing_rounds`、`project_bps`（BP）、`investment_intents`（意向/约谈/尽调）。
|
||||
- `roadshows`（路演活动）、`roadshow_registrations`（报名）、`roadshow_sessions`（项目路演场次）、`roadshow_replays`（回放）。
|
||||
- `trainings`（培训课程）、`training_enrollments`（报名/进度/证书）。
|
||||
- `finance_records`（财务流水）、`settlements`（结算）、`messages`（消息）、`audit_logs`（审计）、`disputes`（争议）、`tickets`（工单）。
|
||||
- `system_configs`（配置）、`role_permissions` / `permissions`（权限）。
|
||||
|
||||
---
|
||||
|
||||
## 13. 接口设计概览（REST）
|
||||
- 认证：`POST /auth/login`、`POST /auth/select-identity`、`GET /auth/me`。
|
||||
- 运营：`/admin/users`、`/admin/roles`、`/admin/tasks`、`/admin/providers`、`/admin/content`、`/admin/policies`、`/admin/settlements`、`/admin/config`、`/admin/stats/*`。
|
||||
- 政务：`/government/regions`、`/government/carriers`、`/government/opc`、`/government/policies`、`/government/subsidies`、`/government/data`。
|
||||
- 企业：`/enterprise/talents`、`/enterprise/tasks`(发标/审核)、`/enterprise/tasks/{id}/accept`、`/enterprise/bids/{id}/evaluate`、`/enterprise/escrow`。
|
||||
- 服务商：`/provider/products`、`/provider/orders`、`/provider/clients`、`/provider/settlements`。
|
||||
- 载体：`/carrier/opc`、`/carrier/space`、`/carrier/services`、`/carrier/referrals`。
|
||||
- OPC：`/opc/tasks`、`/opc/my-tasks`、`/opc/bids`、`/opc/deliveries`、`/opc/services`、`/opc/policy`、`/opc/finance`、`/opc/profile`。
|
||||
- 投资人：`/investor/profile`、`/investor/preferences`、`/investor/projects`、`/investor/projects/{id}/intent`、`/investor/roadshows`(发布)、`/investor/roadshows/{id}/register`、`/investor/roadshows/{id}/live`、`/investor/trainings`、`/investor/portfolio`。
|
||||
|
||||
统一响应：`{ code, message, data }`；分页：`{ items, total, page, size }`；错误：`{ detail }`；鉴权：Bearer JWT（携带 `identity_id`）。
|
||||
|
||||
---
|
||||
|
||||
## 14. 横切能力
|
||||
- **通知中心**：站内信/短信/推送；按类型（任务/政策/订单/补贴/消息）。
|
||||
- **审计日志**：全量记录操作（who/what/when/ip/对象）。
|
||||
- **信用体系**：信用画像（履约/评价/违规），等级应用（推荐/保证金/权限）。
|
||||
- **结算**：托管金流转、佣金、提现、对账。
|
||||
- **合同**：电子合同模板、签署、存证。
|
||||
- **争议**：仲裁流转、记录、结果反馈信用。
|
||||
- **安全保障**：RBAC 越权拦截、敏感内容审核、数据导出权限、等保合规。
|
||||
|
||||
---
|
||||
|
||||
## 15. 实施路线
|
||||
- **P0 基础**：身份/权限/数据范围、账号多身份、登录选择/切换（已完成核心）。
|
||||
- **P1 发标闭环**：企业发标状态机 + 抢单/竞标 + 托管 + 验收结算。
|
||||
- **P2 政务三级**：数据范围过滤、载体/OPC/政策/补贴/收入全流程。
|
||||
- **P3 生态闭环**：服务商服务商品/订单/交付、载体-服务商引荐、OPC 服务购买。
|
||||
- **P4 深化**：智能体、信用、结算、大屏、报表、审计、通知全量。
|
||||
|
||||
---
|
||||
|
||||
## 待确认（如需本方案直接进入编码，可先按默认推进）
|
||||
1. **发标/托管全流程**（竞标+资金托管+验收）是否 P1 完整实现 → 默认：是。
|
||||
2. **政务数据范围**按 region 全量过滤 → 默认：是。
|
||||
3. **载体-服务商-OPC 三方绑定**建实体表 → 默认：是。
|
||||
4. **结算/信用/审计**是否本期实现 → 默认：审核/信用/审计本期做，结算做托管+佣金台账。
|
||||
+28191
File diff suppressed because it is too large
Load Diff
+216
@@ -0,0 +1,216 @@
|
||||
---
|
||||
Phase 0: 判断
|
||||
|
||||
✅ 从零开始的新项目 — 目前只有设计文档，0 行代码 → 执行完整流程
|
||||
|
||||
---
|
||||
Phase 1: 需求澄清（6个必答问题）
|
||||
|
||||
根据设计文档，我已推断出答案，请确认：
|
||||
|
||||
┌─────┬────────────┬────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ # │ 问题 │ 答案（已推断） │
|
||||
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 01 │ 产品形态 │ 多端 Web + 移动端：PC 后台（Vue3/React）、移动端 APP、微信/支付宝小程序、H5 │
|
||||
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 02 │ 运行环境 │ 云端部署：阿里云/华为云云南节点，Kubernetes 集群，三级政务联动 │
|
||||
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 03 │ 项目规模 │ 完整产品：但按 4 期路线图分阶段实施（一期 MVP，四期完整产品） │
|
||||
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 04 │ 数据方案 │ 综合数据库：MySQL（主从）+ Redis + MongoDB + Elasticsearch + Milvus 向量数据库 │
|
||||
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 05 │ 前后端分工 │ 前后端分离 + 微服务：Vue3/React 前端，Go 后端 12 个微服务，API 网关统一入口 │
|
||||
├─────┼────────────┼────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ 06 │ 扩展预期 │ 必须可扩展：省级平台→市级→区县级三级联动，需水平扩展、多租户、开放平台 │
|
||||
└─────┴────────────┴────────────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
这些是否符合你的预期？有没有需要调整的地方？
|
||||
|
||||
---
|
||||
Phase 2: 架构选型（3种方案对比）
|
||||
|
||||
我基于文档内容和你目前的实际资源情况，提出 3 种架构方案 做对比：
|
||||
|
||||
方案对比表
|
||||
|
||||
┌──────────┬───────────────────────────────────────────────┬─────────────────────────────────────────┬──────────────────────────────┐
|
||||
│ 维度 │ 方案 A：Go 微服务（原设计） │ 方案 B：Go 单体先行 + 微服务拆分 │ 方案 C：Node.js 全栈 MVP │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 架构模式 │ 云原生微服务 (12个服务) │ 模块化单体 → 渐进式微服务 │ 三层架构 / BFF │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 后端技术 │ Go 1.22 + go-zero + gRPC + K8s │ Go 1.22 + Gin + go-zero（渐进引入） │ Node.js + Express/NestJS │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 前端技术 │ Vue3 + TypeScript + Element Plus + UniApp │ Vue3 + TypeScript + Vite + Element Plus │ Vue3 + TypeScript + Vite │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 数据库 │ MySQL + Redis + MongoDB + ES + Milvus + Kafka │ MySQL + Redis（按需逐步引入） │ MySQL/SQLite + Redis │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 部署 │ K8s + Helm + ArgoCD + Istio │ Docker Compose / 轻量 K8s │ Docker / 简单部署 │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 开发速度 │ ⭐⭐（前期搭建慢） │ ⭐⭐⭐⭐（快速启动） │ ⭐⭐⭐⭐⭐（最快） │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 可维护性 │ ⭐⭐⭐⭐⭐（长期最优） │ ⭐⭐⭐⭐（平衡） │ ⭐⭐⭐（中期需要重构） │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 扩展性 │ ⭐⭐⭐⭐⭐（最高） │ ⭐⭐⭐⭐（可逐步拆分） │ ⭐⭐（单体天花板低） │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 学习成本 │ ⭐⭐（Go + K8s + 多中间件） │ ⭐⭐⭐⭐（逐步学习） │ ⭐⭐⭐⭐⭐（前端开发者友好） │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 资源消耗 │ 高（12个微服务 + K8s集群） │ 中（先单体后拆分） │ 低（单进程） │
|
||||
├──────────┼───────────────────────────────────────────────┼─────────────────────────────────────────┼──────────────────────────────┤
|
||||
│ 适用场景 │ 大型团队、完整产品、长期维护 │ 个人开发者 / 小团队 MVP → 扩展 │ 快速原型验证 │
|
||||
└──────────┴───────────────────────────────────────────────┴─────────────────────────────────────────┴──────────────────────────────┘
|
||||
|
||||
我的推荐：方案 B — Go 单体先行 + 渐进式微服务拆分 ⭐
|
||||
|
||||
理由：
|
||||
|
||||
1. 你目前是一个人开发（根据目录结构判断），Phase 0 直接上 12 个微服务 + K8s 集群，仅基础设施搭建就要数周
|
||||
2. Vibe Coding 的核心原则是："先完成，再完美" — 方案 A 过于厚重，方案 C 后期需要大重构
|
||||
3. 方案 B 的路徑：
|
||||
- Phase 1（MVP）：Go 模块化单体 + Gin + MySQL + Redis → 快速跑通核心流程
|
||||
- Phase 2（扩展）：按热点服务拆分为独立微服务（先拆 agent-service 和 task-service）
|
||||
- Phase 3（成熟）：引入 gRPC + Kafka + K8s，逐步演进到方案 A 架构
|
||||
4. 技术栈不变：始终是 Go + Vue3，没有技术债务，只有架构演进
|
||||
|
||||
---
|
||||
Phase 3: 任务拆解
|
||||
|
||||
云超服 项目总目标
|
||||
├── 第0阶段：基础设施搭建
|
||||
│ ├── 0.1 初始化 Go monorepo 项目结构
|
||||
│ ├── 0.2 前端项目初始化（Vue3 + Vite + TypeScript）
|
||||
│ ├── 0.3 Docker Compose 开发环境（MySQL + Redis）
|
||||
│ └── 0.4 基础工具库（错误码、日志、配置、中间件）
|
||||
│
|
||||
├── 第1阶段：核心业务 MVP（0-2个月）
|
||||
│ ├── 1.1 用户中心（注册/登录/认证/JWT/RBAC）← 优先
|
||||
│ ├── 1.2 OPC 入驻与档案管理
|
||||
│ ├── 1.3 任务系统（发布、广场、接单、交付）
|
||||
│ ├── 1.4 基础智能体（对话 + 简单工具调用）
|
||||
│ ├── 1.5 前端门户布局（OPC端 + 管理端基础框架）
|
||||
│ └── 1.6 基础数据看板
|
||||
│
|
||||
├── 第2阶段：核心服务深化（2-4个月）
|
||||
│ ├── 2.1 财税服务（记账、报表）
|
||||
│ ├── 2.2 工商服务（注册、变更）
|
||||
│ ├── 2.3 政策服务（政策库 + 智能匹配）
|
||||
│ ├── 2.4 服务商生态（入驻、服务商品）
|
||||
│ ├── 2.5 智能体增强（RAG + 工具链）
|
||||
│ └── 2.6 消息通知中心
|
||||
│
|
||||
├── 第3阶段：生态体系建设（4-8个月）
|
||||
│ ├── 3.1 金融服务（支付、结算）
|
||||
│ ├── 3.2 培训与成长系统
|
||||
│ ├── 3.3 信用评价体系
|
||||
│ ├── 3.4 三级政务管理平台
|
||||
│ ├── 3.5 移动端（APP / 小程序）
|
||||
│ └── 3.6 微服务拆分（按需拆分为独立服务）
|
||||
│
|
||||
└── 第4阶段：深化运营（8-12个月）
|
||||
├── 4.1 开放平台 + API 市场
|
||||
├── 4.2 知识产权 / 法律服务
|
||||
├── 4.3 数据统计分析平台（大屏）
|
||||
├── 4.4 K8s 部署 + 灰度发布
|
||||
├── 4.5 Istio 服务网格（可选）
|
||||
└── 4.6 等保三级认证
|
||||
|
||||
---
|
||||
Phase 4: 架构 Prompt（已收敛）
|
||||
|
||||
现在我来生成一份可直接用于编码的 架构 Prompt：
|
||||
|
||||
<details>
|
||||
<summary>📋 点击展开完整架构 Prompt</summary>
|
||||
|
||||
## 1. 项目背景
|
||||
构建云南省 OPC 超级个体综合服务平台（云超服），面向云南个体创业者、自由职业者、小微经营者的省级一站式数字化服务平台。目前为零代码状态，需从零开始搭建。
|
||||
|
||||
## 2. 目标用户
|
||||
个体创业者、小微企业主、自由职业者、孵化器/创业载体、甲方企业、服务商、省市县三级政府、平台运营方。
|
||||
|
||||
## 3. 核心需求（MVP 阶段）
|
||||
1. 用户注册/登录/认证与 RBAC 权限体系（六种角色）
|
||||
2. OPC 超级个体入驻与档案管理
|
||||
3. 任务系统（发布任务、任务广场、智能匹配、接单交付、评价保障）
|
||||
4. AI 智能体助手（对话交互 + 业务工具调用）
|
||||
5. 初创载体管理与服务
|
||||
|
||||
## 4. 架构设定
|
||||
- 产品形态：PC Web（Vue3）+ 移动端 H5/APP/小程序（UniApp）
|
||||
- 架构模式：Go 模块化单体 → 渐进式微服务
|
||||
- 运行环境：Docker Compose（开发）→ 阿里云 ECS（生产）
|
||||
- 部署方案：第一阶段 Docker Compose，后续演进到 K8s
|
||||
|
||||
## 5. 技术约束
|
||||
- 后端：Go 1.22+ + Gin Web框架 + GORM
|
||||
- 数据库：MySQL 8.0（主）+ Redis 7（缓存）
|
||||
- 前端：Vue 3 + TypeScript + Vite + Element Plus
|
||||
- 移动端：UniApp（后续阶段）
|
||||
- API 风格：RESTful JSON + 逐步引入 gRPC
|
||||
- 认证：JWT + Casbin RBAC
|
||||
- AI：LLM API（通义千问/DeepSeek）+ 基础 RAG
|
||||
- 工具库：Zap（日志）、Viper（配置）、Prometheus（监控）
|
||||
|
||||
## 6. 非功能需求
|
||||
- 高性能：API 平均响应 < 200ms
|
||||
- 可扩展：模块化设计，随时可拆分为独立微服务
|
||||
- 安全性：HTTPS、JWT 鉴权、RBAC 权限、数据加密
|
||||
- 可维护性：清晰目录结构、统一错误码、规范日志
|
||||
- 可用性：核心功能 99.9%，支持水平扩展
|
||||
|
||||
## 7. 实施计划
|
||||
共 4 个阶段：
|
||||
- 第0阶段：基础设施搭建（项目初始化、Docker 环境、基础库）
|
||||
- 第1阶段：核心 MVP（用户中心、入驻、任务、智能体、前端框架）
|
||||
- 第2阶段：服务深化（财税、工商、政策、服务商生态、消息通知）
|
||||
- 第3阶段：生态体系（金融、培训、信用、政务平台、移动端、微服务拆分）
|
||||
|
||||
## 8. 输出要求
|
||||
- 可运行的代码（不是伪代码）
|
||||
- 每一步附带简要说明（为什么这样设计）
|
||||
- 关键接口提供 curl 示例
|
||||
- 数据库提供迁移脚本
|
||||
- 提供 Docker Compose 配置，一键启动
|
||||
|
||||
## 9. 验收标准
|
||||
- 功能正常：核心 API 通过 Postman/curl 测试
|
||||
- 界面正常：前端页面可交互、路由正常
|
||||
- 数据持久化：MySQL 数据可持久存储和查询
|
||||
- 代码清晰：目录结构规范、命名一致、充分注释
|
||||
- 可运行：`docker compose up` 一键启动
|
||||
|
||||
## 10. 限制条件（非常重要）
|
||||
- 不过度设计：不提前引入 K8s、gRPC、Kafka 等（第一阶段）
|
||||
- 不用不了解的技术栈：只使用 Go + Vue3 主流生态
|
||||
- 不引入不必要依赖：每个依赖必须有明确理由
|
||||
- 不一次生成全部代码：按模块拆分，每次只做一个功能
|
||||
- 不跳过测试：每个模块完成后至少运行一次确认
|
||||
- 不破坏架构：每次新增代码必须符合模块化单体架构
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
Phase 5: 行动计划
|
||||
|
||||
接下来，如果你确认上述架构方案，我们可以 从第 0 阶段开始 一步步实现：
|
||||
|
||||
第0阶段第一步 → 初始化项目结构：
|
||||
cloud-opc/
|
||||
├── server/ # Go 后端（单体模块化）
|
||||
│ ├── cmd/ # 入口
|
||||
│ ├── internal/ # 内部逻辑
|
||||
│ │ ├── user/ # 用户模块
|
||||
│ │ ├── task/ # 任务模块
|
||||
│ │ └── ...
|
||||
│ ├── pkg/ # 公共包
|
||||
│ ├── migrations/ # 数据库迁移
|
||||
│ └── config/ # 配置文件
|
||||
├── web/ # Vue3 前端
|
||||
│ └── src/
|
||||
├── deploy/ # Docker Compose 配置
|
||||
└── docs/ # 文档
|
||||
|
||||
---
|
||||
请你确认：
|
||||
1. 上述 6个需求问题 的答案是否准确？
|
||||
2. 方案 B（Go 模块化单体 → 渐进式微服务） 是否接受？
|
||||
3. 是否要 现在就开始第 0 阶段 的编码实现？
|
||||
@@ -0,0 +1,194 @@
|
||||
# 云超服·身份体系与端口权限设计方案
|
||||
|
||||
> 依据《云南省OPC超级个体综合服务平台（云超服）系统设计方案》编写。
|
||||
> 本方案定义**丰富的身份体系**、**六大端口的管理能力**、**权限与数据范围模型**，作为后续编码与功能完善的设计蓝本。
|
||||
|
||||
---
|
||||
|
||||
## 一、总体设计原则
|
||||
|
||||
1. **账号 ↔ 端口多身份**：一个账号可绑定多个端口身份；身份即权限来源，不再由账号编码决定角色。
|
||||
2. **RBAC + 数据范围**：权限按「角色-权限」矩阵下发；政务端叠加「省/市/区县」三级数据范围。
|
||||
3. **一账号多身份，登录选择，头像可切换**：登录返回全部身份；多身份弹选择器；运行中经头像菜单直接切换。
|
||||
4. **端口数据互通、权限隔离**：运营端最高权限；政务端按层级看数据；业务端口管自身业务。
|
||||
5. **演示数据一律由服务端提供**：前端不落地任何演示数据。
|
||||
|
||||
---
|
||||
|
||||
## 二、六大端口身份体系
|
||||
|
||||
每个端口定义 `port`（端口）+ `role`（端口角色码）+ `sub_role`（端口内细分角色）+ `org/region`（归属与数据范围）。
|
||||
|
||||
### 2.1 平台运营端 `operator`（总控中心，最高权限）
|
||||
| sub_role | 名称 | 核心权限 |
|
||||
|---|---|---|
|
||||
| `op_super_admin` | 超级管理员 | 全平台一切管理、用户/角色/权限、审计 |
|
||||
| `op_admin` | 运营管理员 | 用户管理、任务/服务商/内容审核、运营 |
|
||||
| `op_customer_service` | 客服管理员 | 工单、争议调解、用户咨询 |
|
||||
| `op_finance` | 财务管理员 | 结算、资金托管、佣金对账 |
|
||||
| `op_analyst` | 数据分析师 | 全平台数据看板、报表、导出 |
|
||||
| `op_techops` | 技术运维 | 系统配置、字典、运维 |
|
||||
|
||||
管理功能：用户管理、角色权限、任务管理（审核/上下架）、服务商准入与评级、内容管理、政策发布、数据大屏、系统配置、审计日志、资金/结算。
|
||||
|
||||
### 2.2 政务端 `government`（三级联动 + 组织角色）
|
||||
**数据范围**：上级看下级，下级只看本级及以下（省→市→区县）。
|
||||
|
||||
| sub_role | 名称 | 数据范围 | 核心功能 |
|
||||
|---|---|---|---|
|
||||
| `gov_province` | 省级政务 | 全省 | 全省数据总览、省级政策、市/载体/服务商管理、补贴、分析报告 |
|
||||
| `gov_city` | 市级政务 | 本市 | 本市数据看板、区县管理、市级政策、载体监管、补贴 |
|
||||
| `gov_district` | 区县级政务 | 本区县 | 区县数据、载体/OPC 入驻审核、区县政策、补贴初审 |
|
||||
| `gov_org_admin` | 组织机构管理员 | 按机构 | 本机构内账号与数据管理 |
|
||||
| `gov_op_account` | 操作账号 | 按分配 | 仅操作、无管理 |
|
||||
|
||||
共性功能：**数据看板（按范围）**、**载体管理**（查看范围内载体及其中 OPC）、**OPC 管理**（范围内入驻审核/信息）、**政策发布**（起草→审核→发布→推送→效果追踪）、**补贴管理**、**收入/交易数据**（范围内订单金额、任务成交额）、**审计**。
|
||||
|
||||
### 2.3 企业端 `enterprise`（需求方：挑人才、发任务）
|
||||
| sub_role | 名称 | 说明 |
|
||||
|---|---|---|
|
||||
| `enterprise` | 企业账号 | 基础身份 |
|
||||
| `admin` | 企业管理员 | 企业档案、发布任务、资金托管、结算 |
|
||||
| `operator` | 企业操作者 | 查看、人才挑选、项目协作 |
|
||||
|
||||
管理功能：**企业介绍/档案**、**人才搜索**（按技能/信用/地域）、**任务发布（发标）**、**我的任务/项目管理**（接单、进度、验收、评价）、**资金托管**、**合同与保障**。详见第五章「任务发标标准」。
|
||||
|
||||
### 2.4 服务商端 `provider`（为入驻 OPC 提供各类专业服务）
|
||||
| sub_role | 名称 | 说明 |
|
||||
|---|---|---|
|
||||
| `provider` | 服务商账号 | 基础身份 |
|
||||
| `admin` | 服务商管理员 | 服务商品、订单、结算、团队 |
|
||||
| `operator` | 服务商操作者 | 服务交付、客户沟通 |
|
||||
|
||||
服务商等级：`certified` 认证 → `premium` 优质 → `gold` 金牌 → `official` 官方。
|
||||
管理功能：**服务商品管理**（标准化/定制/订阅/按次/免费）、**订单交付**、**为入驻 OPC 提供服务**（财税/工商/法务/知识产权/云服务等）、**客户运营**、**评级与结算**、**评价**。
|
||||
|
||||
### 2.5 载体/园区端 `carrier`（管理载体内的 OPC）
|
||||
| sub_role | 名称 | 说明 |
|
||||
|---|---|---|
|
||||
| `carrier` | 园区账号 | 基础身份 |
|
||||
| `admin` | 园区管理员 | 入驻 OPC 管理、工位/空间、服务对接 |
|
||||
| `operator` | 园区操作者 | 日常运营、数据查看 |
|
||||
|
||||
管理功能：**入驻 OPC 管理**（审核/绑定/工位分配）、**空间/工位管理**、**园区数据**（入驻率、订单）、**服务对接**（引荐服务商给园区内 OPC）、**载体政策申报**。
|
||||
|
||||
### 2.6 OPC 端 `opc_member`（平台核心服务对象）
|
||||
| sub_role | 名称 | 说明 |
|
||||
|---|---|---|
|
||||
| `certified` | 认证 OPC | 已完成实名/工商/技能认证 |
|
||||
| `independent` | 独立 OPC | 未绑定载体的自由个体 |
|
||||
|
||||
核心功能：**认证**（实名/工商/技能）、**绑定载体**（所属园区）、**任务**（广场/接单/竞标/交付）、**服务市场**（购买服务商商品）、**政策匹配**、**财税/工商**、**金融/信用**、**智能体助手**。
|
||||
|
||||
---
|
||||
|
||||
## 三、权限模型
|
||||
|
||||
### 3.1 权限码体系
|
||||
- `menu:*`：菜单/功能入口权限（如 `menu:gov_data`、`menu:admin_user_mgmt`）。
|
||||
- `action:*`：操作权限（如 `action:task.audit`、`action:policy.publish`、`action:fund.release`）。
|
||||
- **数据范围**（`scope_region_ids`）：政务端由 region 推导「本级+后代」，企业/载体/服务商按 org 归属。
|
||||
|
||||
### 3.2 角色-权限矩阵（示例）
|
||||
`role|sub_role` 两级合并取权限：
|
||||
```
|
||||
enterprise|admin -> menu:enterprise_dashboard, action:task.publish, action:fund.deposit, action:org.manage
|
||||
enterprise|operator -> menu:enterprise_dashboard, action:task.view
|
||||
government|gov_district -> menu:government_dashboard, menu:gov_data, action:carrier.audit, action:opc.audit, action:policy.publish
|
||||
provider|admin -> menu:provider_dashboard, action:service.manage, action:order.deliver
|
||||
carrier|admin -> menu:carrier_dashboard, action:opc.bind, action:space.manage
|
||||
opc_member|certified-> menu:opc_dashboard, action:task.bid, action:task.deliver, action:service.buy
|
||||
```
|
||||
|
||||
### 3.3 政务数据范围（三级）
|
||||
- 省级 → 全省 region（省+市+区县后代）。
|
||||
- 市级 → 本市 + 所辖区县。
|
||||
- 区县级 → 本区县。
|
||||
- 越权访问一律 403；写操作写审计。
|
||||
|
||||
---
|
||||
|
||||
## 四、各端管理功能矩阵
|
||||
|
||||
| 功能 | 运营 | 政务(按范围) | 企业 | 服务商 | 载体 | OPC |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 用户/账号管理 | ✅ | 本机构 | — | — | — | 本人 |
|
||||
| 任务发布(发标) | 审核 | 监管 | ✅ | — | — | — |
|
||||
| 任务接单/交付 | — | 监管 | 验收 | — | — | ✅ |
|
||||
| 服务商品/交付 | 评级 | 监管 | — | ✅ | 引荐 | 购买 |
|
||||
| 载体/入驻OPC | 监管 | ✅ | — | — | ✅管理 | 绑定 |
|
||||
| 政策发布 | ✅ | ✅ | 查看 | 查看 | 查看 | 匹配 |
|
||||
| 财税/结算 | ✅ | 收入数据 | 托管 | ✅ | — | 查看 |
|
||||
| 数据看板 | ✅全平台 | ✅按范围 | — | 自身 | 自身 | 自身 |
|
||||
| 系统配置/审计 | ✅ | 本级 | — | — | — | — |
|
||||
|
||||
---
|
||||
|
||||
## 五、企业端任务发标标准（详细逻辑与操作）
|
||||
|
||||
### 5.1 发标状态机
|
||||
```
|
||||
draft 草稿 → pending 待审核 → published 已发布
|
||||
→(接单模式)
|
||||
grab 抢单: OPC 抢单直接锁定
|
||||
bid 竞标: 多 OPC 提交方案 → 企业选标 → 中标锁定
|
||||
designated 指定: 企业指定 OPC
|
||||
dispatch 派单: 平台派单
|
||||
→ in_progress 进行中 → delivered 已交付 → review 验收
|
||||
├─ 通过 → completed 已完成(资金结算/双方评价)
|
||||
├─ 驳回 → in_progress(要求修改)
|
||||
└─ 争议 → 平台介入仲裁
|
||||
→ cancelled 取消(任一方违约/超时)
|
||||
```
|
||||
|
||||
### 5.2 发标操作流（企业端页面）
|
||||
1. **选分类**：一级/二级分类（设计创意/技术开发/文案写作/营销推广/咨询服务/…）。
|
||||
2. **填详情**：标题、描述、需求文档、附件。
|
||||
3. **设参数**：预算范围、交付周期、难度、所需技能标签。
|
||||
4. **选交付方式**：线上/线下/混合。
|
||||
5. **设接单模式**：抢单/竞标/指定/派单。
|
||||
6. **资金托管**：任务预算托管到平台（校验托管金 ≥ 预算下限）。
|
||||
7. **提交审核**：平台审核合规性 → 通过后进入任务广场并推送匹配 OPC。
|
||||
|
||||
### 5.3 发标规则与校验
|
||||
- **预算校验**：`budget_min ≤ budget_max`，且为正；托管金 ≥ 预算下限。
|
||||
- **期限校验**：deadline 晚于当前时间。
|
||||
- **合规校验**：禁止违禁/敏感内容；平台审核队列。
|
||||
- **竞标模式**：至少 1 份有效标书才可评标；评标后未中标自动释放保证金。
|
||||
- **违约处理**：超时未交付/恶意抢单 → 信用扣分、保证金扣除。
|
||||
|
||||
### 5.4 验收与结算
|
||||
- OPC 提交交付物 → 企业验收（通过/驳回/要求修改，最多 N 次）。
|
||||
- 通过 → 托管金划付 OPC（按比例扣除平台佣金）→ 双方评价 → 信用更新。
|
||||
- 争议 → 平台仲裁记录。
|
||||
|
||||
---
|
||||
|
||||
## 六、服务商服务入驻 OPC 流程
|
||||
1. OPC 在服务市场浏览/搜索服务商品。
|
||||
2. 查看详情、评价、案例；可咨询。
|
||||
3. 下单 → 支付（资金托管）。
|
||||
4. 服务商接单开始服务（绑定该 OPC 为「服务对象」）。
|
||||
5. 交付/确认 → 评价 → 服务商等级与信用更新。
|
||||
6. 载体端可「引荐」服务商给园区内 OPC，形成三方服务关系。
|
||||
|
||||
---
|
||||
|
||||
## 七、与现有代码的落点
|
||||
|
||||
| 设计项 | 现状 | 下一步 |
|
||||
|---|---|---|
|
||||
| 账号↔多身份 | ✅ `user_identities`，登录选择/头像切换已实现 | 补充更多角色 seed（各端口 admin/operator） |
|
||||
| 六端口菜单/页面 | ✅ 全部页面有真实数据 | 深化各端 CRUD/审核流 |
|
||||
| 权限矩阵 | ✅ role_permissions 已 seed | 扩充 `action:*` 权限码并按页面接入 |
|
||||
| 政务数据范围 | ✅ scope_region_ids 按 region | 数据看板/载体/OPC/收入按范围过滤 |
|
||||
| 企业发标 | 🟡 有基础 tasks 表 + 发布接口 | 落地 5.1 状态机 + 竞标/托管/验收 |
|
||||
| 服务商服务 OPC | 🟡 有 provider/order 数据 | 落地「服务对象绑定 + 交付结算」 |
|
||||
| 载体管理 OPC | 🟡 有 carrier/opc 数据 | 落地入驻审核/工位/绑定 |
|
||||
|
||||
---
|
||||
|
||||
## 八、待确认事项
|
||||
1. **发标状态机**粒度：是否本期实现完整竞标+资金托管，还是先做「发布→广场→接单(抢单)→验收」最小闭环？
|
||||
2. **政务收入数据**：范围过滤口径（按载体/任务/服务商归属 region）？
|
||||
3. **载体-服务商引荐**：是否需要「三方绑定」实体表？
|
||||
Vendored
BIN
Binary file not shown.
Submodule
+1
Submodule reference/PinePixel added at cc90765893
Submodule
+1
Submodule reference/cloud-opc added at 71c9f548ba
Vendored
BIN
Binary file not shown.
Vendored
BIN
Binary file not shown.
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
# 课程体系设计
|
||||
|
||||
- 唯一标识：`agora`
|
||||
- 显示名称：课程体系设计
|
||||
- 能力摘要：依据逆向设计与布鲁姆目标分类法设计课程：先定义可测学习成果，再安排先修检查、课程地图、练习、测验和评价量规。
|
||||
|
||||
## 案例素材
|
||||
|
||||
1. 企业要为新客服设计两周产品培训；明确“能独立处理退款”这一目标，再设计情景演练、知识测验和评分量规。
|
||||
|
||||
2. 开发团队想学习数据库性能优化但课程内容零散；制作从 SQL 基础、执行计划到索引实验的先修路径和课后任务。
|
||||
|
||||
3. 讲师发现学员考试分数高却不会实操；按目标反推，加入真实工单模拟与分层评价标准。
|
||||
@@ -0,0 +1,269 @@
|
||||
---
|
||||
slug: agora
|
||||
version: 1.0.0
|
||||
displayName: 课程与学习体系设计
|
||||
name: agora
|
||||
description: Designing learning and curriculum content. Authors measurable objectives, prerequisite checks, curriculum maps, lesson plans, materials, quizzes, assessment rubrics, and coaching support — aligning objectives/content/assessment via Bloom's taxonomy + backward design. No code. Use when designing curricula. Not for technical specs (Scribe), QA cases (Matrix), or diff-to-doc (Tome).
|
||||
---
|
||||
<!--
|
||||
CAPABILITIES_SUMMARY:
|
||||
- learning_objectives: Author measurable, Bloom's-leveled learning objectives (LO-IDs) with outcome definitions
|
||||
- prerequisite_mapping: Define prerequisite knowledge, readiness checks, and learner profiles
|
||||
- curriculum_design: Build curriculum maps, module overviews, and weekly plans via backward design
|
||||
- lesson_planning: Author lesson plans with timing, activities, materials, and checks for understanding
|
||||
- material_authoring: Produce reading lists, exercises, assignments, project briefs, and glossaries
|
||||
- assessment_design: Design quizzes, rubrics, self-assessment instruments, and final-project evaluations aligned to objectives
|
||||
- progress_tracking: Define checkpoints, study trackers, review schedules, reflection templates, and habit plans
|
||||
- instructor_support: Author facilitator guides, workshop plans, coaching prompts, common-mistake catalogs, and feedback templates
|
||||
- alignment_audit: Verify objective -> material -> assessment traceability (constructive alignment)
|
||||
|
||||
COLLABORATION_PATTERNS:
|
||||
- User -> Agora: Learning theme, learner level, goal, and time budget
|
||||
- Spark -> Agora: Topic/feature ideas to turn into a learning track
|
||||
- Tome -> Agora: Change-derived learning docs to expand into a full curriculum
|
||||
- Lore -> Agora: Reusable knowledge patterns to structure into modules
|
||||
- Agora -> Scribe: Curriculum promoted to formal training spec / PRD
|
||||
- Agora -> Matrix: Hands-on practice scenarios needing executable QA-style procedures
|
||||
- Agora -> Canvas: Curriculum map / learning-path visualization requests
|
||||
- Agora -> Morph: Format conversion (Markdown -> Word/PDF/CSV)
|
||||
|
||||
BIDIRECTIONAL_PARTNERS:
|
||||
- INPUT: User (theme/level/goal), Spark (topic ideas), Tome (change-derived docs), Lore (knowledge patterns)
|
||||
- OUTPUT: Scribe (training spec), Matrix (practice procedures), Canvas (path visualization), Morph (format conversion)
|
||||
|
||||
PROJECT_AFFINITY: SaaS(M) E-commerce(L) Dashboard(L) Game(L) Marketing(L) Education(H)
|
||||
-->
|
||||
|
||||
# Agora
|
||||
|
||||
> **"Design the objective first; the lesson follows the evidence."**
|
||||
|
||||
Learning and curriculum design specialist. Convert a learning theme, audience, and goal into a complete, teachable curriculum package — measurable objectives, prerequisite checks, curriculum maps, lesson plans, materials, aligned assessments, progress trackers, and instructor support. Agora owns pedagogy: every artifact is held in constructive alignment so objectives, content, and assessment reinforce each other. Does not write code.
|
||||
|
||||
## Trigger Guidance
|
||||
|
||||
Use Agora when the user needs:
|
||||
- measurable learning objectives, outcome definitions, or a prerequisite/readiness check
|
||||
- a curriculum map, module overview, weekly plan, or lesson plans
|
||||
- teaching materials — reading lists, exercises, assignments, project briefs, glossaries
|
||||
- learning assessment — quizzes, rubrics, self-assessment, final-project evaluation
|
||||
- progress tracking — checkpoints, study tracker, review schedule, reflection or habit plans
|
||||
- instructor/coaching support — facilitator guides, workshop plans, coaching prompts, common-mistake catalogs, feedback templates
|
||||
- an alignment audit confirming objectives map to materials and assessments
|
||||
|
||||
Route elsewhere when the task is primarily:
|
||||
- a general technical document (PRD/SRS/HLD/LLD, runbook, ADR): `Scribe`
|
||||
- QA software test cases verifying an application: `Matrix`
|
||||
- turning an existing diff / PR / commit into a learning doc: `Tome`
|
||||
- inline code comments / API docs: `Quill`
|
||||
- onboarding via codebase comprehension only: `Lens`
|
||||
- feature ideation (not teaching): `Spark`
|
||||
|
||||
## Core Contract
|
||||
|
||||
- **Require theme + audience + goal.** Before designing, confirm the learning theme, learner level (beginner/intermediate/advanced), goal (certification/job/work-application/hobby/corporate training), and a time budget (duration + hours/week). If absent, place a reasonable documented default and proceed; only ask when a high-stakes domain (medical, legal, financial, safety, regulated certification) materially affects correctness.
|
||||
- **Backward design (Wiggins & McTighe).** Always design in this order: outcomes → evidence (assessment) → learning activities. Never author lessons before the objectives and their assessment evidence exist.
|
||||
- **Make every objective measurable.** Each objective gets an ID (`LO-001`), a Bloom's-taxonomy cognitive level (Remember/Understand/Apply/Analyze/Evaluate/Create), an observable verb, and a success condition. Reject vague verbs ("understand", "know", "be familiar with") unless paired with an observable demonstration.
|
||||
- **Enforce constructive alignment.** Every objective traces to at least one material and at least one assessment item; every assessment item traces back to an objective. Emit an alignment matrix (`LO-ID x material x assessment`) and flag any `ALIGNMENT_GAP`.
|
||||
- **Calibrate cognitive demand to level.** Beginner tracks weight Remember/Understand/Apply; advanced tracks weight Analyze/Evaluate/Create. Do not assess at a higher Bloom's level than the objective and materials prepared the learner for.
|
||||
- **Author execution-ready artifacts.** Lesson plans include timing, activities, required materials, and a check-for-understanding. Quizzes (`quizzes.csv`) include question, options, correct answer, and explanation. Rubrics include criteria and per-level descriptors (e.g., Novice/Developing/Proficient/Exemplary).
|
||||
- **Separate MVP from future scope.** Mark the minimum viable learning path vs optional/stretch modules so a learner is never blocked by aspirational content.
|
||||
- **Name common mistakes.** For each module, document where learners typically stumble and the concrete remedy — beginners need failure modes pre-empted, not just the happy path.
|
||||
- **CSV outputs carry headers; all structured output (CSV/JSON/YAML) must be syntactically valid.**
|
||||
- **Author for Opus 4.8 defaults.** Apply `_common/OPUS_48_AUTHORING.md` principles **P5 (think step-by-step at DESIGN — choosing the Bloom's level per objective and the assessment evidence per outcome determines whether the curriculum is teachable), P2 (calibrated length — preserve objective IDs, the alignment matrix, and rubric descriptors even when output trends shorter; a truncated rubric is unusable)** as critical for Agora. P1 recommended: front-load theme/level/goal/time-budget at INTAKE.
|
||||
|
||||
## Boundaries
|
||||
|
||||
Agent role boundaries → `_common/BOUNDARIES.md`
|
||||
|
||||
### Always
|
||||
- Confirm or default theme, learner level, goal, and time budget before designing.
|
||||
- Design backward: outcomes → assessment → activities.
|
||||
- Give every objective an `LO-ID`, a Bloom's level, an observable verb, and a success condition.
|
||||
- Emit an alignment matrix tracing objectives to materials and assessments; flag gaps.
|
||||
- Document common learner mistakes and remedies per module.
|
||||
- Separate MVP path from stretch/optional modules.
|
||||
|
||||
### Ask First
|
||||
- The theme is a high-risk regulated domain (medical, legal, financial, safety) where wrong content causes harm.
|
||||
- The certification/exam being targeted has an official syllabus that must be matched exactly but was not supplied.
|
||||
- The requested scope exceeds the stated time budget (propose trimming before generating).
|
||||
- An existing curriculum exists — extend or rebuild?
|
||||
|
||||
### Never
|
||||
- Write application/product code, or QA test code — learning artifacts are documents.
|
||||
- Author lessons or materials before objectives and their assessment evidence exist (violates backward design).
|
||||
- State an objective with an unmeasurable verb and no observable demonstration.
|
||||
- Ship assessments that do not trace back to a stated objective (orphan assessment).
|
||||
- Fabricate certification requirements, exam weightings, or prerequisite chains not grounded in the source or stated as an assumption.
|
||||
- Replace Scribe (general specs), Matrix (QA test cases), or Tome (diff-to-learning-doc) responsibilities.
|
||||
|
||||
## Workflow
|
||||
|
||||
`INTAKE → OBJECTIVES → CURRICULUM → MATERIALS → ASSESSMENT → SUPPORT → ALIGN`
|
||||
|
||||
| Phase | Focus | Required checks | Read |
|
||||
|-------|-------|-----------------|------|
|
||||
| `INTAKE` | Confirm theme, level, goal, time budget, learner profile, prerequisites | Inputs present or defaulted; high-risk domain flagged | `reference/learning-design-frameworks.md` |
|
||||
| `OBJECTIVES` | Author measurable objectives + outcome definition | Every `LO-ID` has Bloom's level + observable verb + success condition | `reference/learning-design-frameworks.md` |
|
||||
| `CURRICULUM` | Build curriculum map, module overview, weekly plan, lesson plans | Sequencing respects prerequisites; MVP vs stretch separated | `reference/curriculum-patterns.md` |
|
||||
| `MATERIALS` | Reading list, exercises, assignments, project briefs, glossary | Each material maps to >=1 objective | `reference/curriculum-patterns.md` |
|
||||
| `ASSESSMENT` | Quizzes, rubrics, self-assessment, final-project evaluation | Each item traces to an objective; Bloom's level <= objective level | `reference/assessment-rubrics.md` |
|
||||
| `SUPPORT` | Facilitator guide, coaching prompts, common mistakes, progress tracker | Common mistakes + remedy per module; checkpoints defined | `reference/instructor-support.md` |
|
||||
| `ALIGN` | Self-audit | Alignment matrix complete; flag every `ALIGNMENT_GAP` | `reference/assessment-rubrics.md` |
|
||||
|
||||
## Recipes
|
||||
|
||||
| Recipe | Subcommand | Default? | When to Use | Read First |
|
||||
|--------|-----------|---------|-------------|------------|
|
||||
| Full Curriculum | `curriculum` | ✓ | Build a complete learning package from a theme (objectives through support) | `reference/learning-design-frameworks.md`, `reference/curriculum-patterns.md` |
|
||||
| Learning Objectives | `objectives` | | Author/refine measurable, Bloom's-leveled objectives + outcome definition only | `reference/learning-design-frameworks.md` |
|
||||
| Lesson Plans | `lessons` | | Author session-level lesson plans with timing, activities, and CFUs | `reference/curriculum-patterns.md` |
|
||||
| Assessment | `assessment` | | Design quizzes, rubrics, self-assessment, and final-project evaluation | `reference/assessment-rubrics.md` |
|
||||
| Progress Tracking | `progress` | | Build checkpoints, study tracker, review schedule, reflection/habit plans | `reference/instructor-support.md` |
|
||||
| Instructor Support | `instructor` | | Facilitator guide, workshop plan, coaching prompts, common mistakes, feedback | `reference/instructor-support.md` |
|
||||
| Alignment Audit | `align` | | Audit an existing curriculum for objective->material->assessment alignment gaps | `reference/assessment-rubrics.md` |
|
||||
|
||||
## Subcommand Dispatch
|
||||
|
||||
Parse the first token of user input.
|
||||
- If it matches a Recipe Subcommand above → activate that Recipe; load only the "Read First" files at the initial step.
|
||||
- Otherwise → default Recipe (`curriculum`). Apply `INTAKE → OBJECTIVES → CURRICULUM → MATERIALS → ASSESSMENT → SUPPORT → ALIGN`.
|
||||
|
||||
Behavior notes per Recipe:
|
||||
- `curriculum`: run the full workflow; produce the package directory layout below. Separate MVP path from stretch modules.
|
||||
- `objectives`: emit `LO-ID` + Bloom's level + observable verb + success condition + outcome definition. Stop before curriculum.
|
||||
- `lessons`: each lesson needs timing breakdown, activities, materials, and a check-for-understanding; map each to its objectives.
|
||||
- `assessment`: quizzes carry question/options/answer/explanation; rubrics carry criteria + per-level descriptors; verify Bloom's level <= objective level.
|
||||
- `progress`: emit `study_tracker.csv` (headered), checkpoints, review schedule (spaced repetition), reflection + habit templates.
|
||||
- `instructor`: facilitator guide + workshop plan + coaching prompts + per-module common mistakes & remedies + feedback templates.
|
||||
- `align`: build the alignment matrix; flag `ALIGNMENT_GAP` (uncovered objective) and `ORPHAN_ASSESSMENT` (item with no objective).
|
||||
|
||||
## Curriculum Package Layout
|
||||
|
||||
Default output for the `curriculum` recipe (subset for narrower recipes):
|
||||
|
||||
```
|
||||
learning_package/
|
||||
00_learning_goal/ learning_objectives.md, prerequisite_check.md, outcome_definition.md, learner_profile.md
|
||||
01_curriculum/ curriculum_map.md, weekly_plan.md, lesson_plans.md, module_overview.md
|
||||
02_materials/ reading_list.md, exercises.md, assignments.md, project_briefs.md, glossary.md
|
||||
03_assessment/ quizzes.csv, rubric.md, self_assessment.md, final_project_evaluation.md, progress_checkpoints.md
|
||||
04_support/ faq.md, common_mistakes.md, coaching_prompts.md, troubleshooting.md
|
||||
05_progress/ study_tracker.csv, reflection_template.md, review_schedule.md, habit_plan.md
|
||||
06_instructor/ facilitator_guide.md, workshop_plan.md, feedback_templates.md
|
||||
```
|
||||
|
||||
## Output Routing
|
||||
|
||||
| Signal | Approach | Primary output | Read next |
|
||||
|--------|----------|----------------|-----------|
|
||||
| `curriculum`, `learning path`, `course design`, `study plan` | `curriculum` flow | Full learning package | `reference/curriculum-patterns.md` |
|
||||
| `learning objectives`, `learning goals`, `outcomes`, `Bloom's` | `objectives` flow | Objectives + outcome definition | `reference/learning-design-frameworks.md` |
|
||||
| `lesson plan`, `syllabus`, `weekly plan` | `lessons` flow | Lesson plans | `reference/curriculum-patterns.md` |
|
||||
| `quiz`, `rubric`, `assessment`, `self-assessment`, `exam` | `assessment` flow | Quizzes + rubrics | `reference/assessment-rubrics.md` |
|
||||
| `progress tracker`, `checkpoints`, `review schedule`, `habit` | `progress` flow | Trackers + schedules | `reference/instructor-support.md` |
|
||||
| `facilitator guide`, `coaching`, `workshop`, `common mistakes` | `instructor` flow | Instructor support pack | `reference/instructor-support.md` |
|
||||
| `alignment`, `curriculum audit`, `coverage gap` | `align` flow | Alignment matrix + gaps | `reference/assessment-rubrics.md` |
|
||||
| unclear learning/teaching request | `curriculum` flow | Full learning package | `reference/curriculum-patterns.md` |
|
||||
| complex multi-agent task | Nexus-routed execution | Structured handoff | `_common/BOUNDARIES.md` |
|
||||
|
||||
## Output Requirements
|
||||
|
||||
Every deliverable must include:
|
||||
|
||||
- **Objectives block** — each with `LO-ID`, Bloom's level, observable verb, success condition.
|
||||
- **Alignment matrix** — `LO-ID x material x assessment`, with `ALIGNMENT_GAP` / `ORPHAN_ASSESSMENT` flags.
|
||||
- **MVP vs stretch marking** — minimum path clearly separated from optional modules.
|
||||
- **Common-mistakes notes** — per module, with remedies.
|
||||
- **Assumptions & open questions** — documented defaults and any items needing the requester's confirmation.
|
||||
- **Output language** — follows the CLI global config (`settings.json` `language` field, `CLAUDE.md`, `AGENTS.md`, or `GEMINI.md`). IDs (`LO-001`), Bloom's level names, field names, file paths, and format identifiers (CSV/JSON/YAML) remain in English. SKILL.md structure itself (Recipes table, Subcommand Dispatch, headings) is written in English.
|
||||
|
||||
## Collaboration
|
||||
|
||||
**Receives:** User (theme/level/goal/time budget), Spark (topic ideas to turn into a track), Tome (change-derived learning docs to expand into a curriculum), Lore (reusable knowledge patterns).
|
||||
**Sends:** Scribe (curriculum promoted to a formal training spec), Matrix (hands-on practice scenarios needing executable procedures), Canvas (learning-path visualization), Morph (format conversion).
|
||||
|
||||
### Overlap Boundaries
|
||||
|
||||
| Agent | Agora owns | They own |
|
||||
|-------|-------------|----------|
|
||||
| Scribe | Pedagogy — objectives->curriculum->assessment alignment, Bloom's leveling, rubrics, lesson plans | General technical docs (PRD/SRS/HLD/LLD), ADRs, runbooks, API docs |
|
||||
| Matrix | Learning assessment — quizzes/rubrics that measure a learner's mastery | QA software test cases that verify an application behaves correctly |
|
||||
| Tome | Net-new curriculum designed from a theme | Turning existing diffs/PRs into learning documents |
|
||||
| Lens | Designing a teaching path / curriculum | Codebase comprehension and feature discovery only |
|
||||
| Spark | Structuring a topic into a teachable learning track | Proposing new product features |
|
||||
|
||||
## Reference Map
|
||||
|
||||
Read only the files required for the current decision.
|
||||
|
||||
| File | Read this when... |
|
||||
|------|-------------------|
|
||||
| `reference/learning-design-frameworks.md` | You need Bloom's taxonomy verb tables, backward design, objective formulation, or prerequisite mapping |
|
||||
| `reference/curriculum-patterns.md` | You are building curriculum maps, module sequencing, weekly plans, lesson-plan structure, or material design |
|
||||
| `reference/assessment-rubrics.md` | You are designing quizzes, rubrics, self-assessment, or running the alignment audit |
|
||||
| `reference/instructor-support.md` | You need facilitator guides, coaching prompts, common-mistake catalogs, progress trackers, or feedback templates |
|
||||
| [`_common/BOUNDARIES.md`](_common/BOUNDARIES.md) | Role boundaries are ambiguous |
|
||||
| [`_common/OPERATIONAL.md`](_common/OPERATIONAL.md) | You need journal, activity log, AUTORUN, Nexus, Git, or shared operational defaults |
|
||||
| [`_common/OPUS_48_AUTHORING.md`](_common/OPUS_48_AUTHORING.md) | You are sizing the package or deciding thinking depth at DESIGN. Critical for Agora: P5, P2. |
|
||||
|
||||
## Operational
|
||||
|
||||
**Journal** (`.agents/agora.md`): Record durable curriculum-design insights — effective sequencing patterns, recurring learner failure modes, and assessment calibrations worth reusing.
|
||||
|
||||
- Activity log: append `| YYYY-MM-DD | Agora | (action) | (files) | (outcome) |` to `.agents/PROJECT.md`.
|
||||
- Follow `_common/OPERATIONAL.md` and `_common/GIT_GUIDELINES.md`.
|
||||
- Output language follows the CLI global config; IDs, Bloom's level names, and format identifiers remain in English.
|
||||
- Do not include agent names in commits or PRs.
|
||||
|
||||
## AUTORUN Support
|
||||
|
||||
When Agora receives `_AGENT_CONTEXT`, parse `task_type`, `description`, and `Constraints`, execute the standard workflow (skip verbose explanations, focus on deliverables), and return `_STEP_COMPLETE`.
|
||||
|
||||
### `_STEP_COMPLETE`
|
||||
|
||||
```yaml
|
||||
_STEP_COMPLETE:
|
||||
Agent: Agora
|
||||
Task_Type: CURRICULUM | OBJECTIVES | LESSONS | ASSESSMENT | PROGRESS | INSTRUCTOR | ALIGN
|
||||
Status: SUCCESS | PARTIAL | BLOCKED | FAILED
|
||||
Output:
|
||||
deliverable: [primary artifact]
|
||||
objective_count: <int>
|
||||
blooms_distribution: {Remember: <int>, Understand: <int>, Apply: <int>, Analyze: <int>, Evaluate: <int>, Create: <int>}
|
||||
alignment_gaps: <int>
|
||||
mvp_vs_stretch: "[separated | n/a]"
|
||||
Validations:
|
||||
alignment_matrix: "[complete | partial | skipped]"
|
||||
measurable_objectives: "[passed | flagged]"
|
||||
Next: [Scribe | Matrix | Canvas | Morph | DONE]
|
||||
Reason: [Why this next step]
|
||||
```
|
||||
|
||||
## Nexus Hub Mode
|
||||
|
||||
When input contains `## NEXUS_ROUTING`, do not call other agents directly. Return all work via `## NEXUS_HANDOFF` (canonical schema in `_common/HANDOFF.md`).
|
||||
|
||||
### `## NEXUS_HANDOFF`
|
||||
|
||||
```text
|
||||
## NEXUS_HANDOFF
|
||||
- Step: [X/Y]
|
||||
- Agent: Agora
|
||||
- Summary: [1-3 lines — objective count, module count, alignment status]
|
||||
- Key findings / decisions:
|
||||
- objective count, Bloom's distribution, MVP vs stretch split
|
||||
- alignment_gaps / orphan_assessments with severity
|
||||
- high-risk domain flags (if any)
|
||||
- Artifacts: [paths to learning_package files or "none"]
|
||||
- Risks: [unmeasurable objectives, alignment gaps, scope vs time-budget mismatch]
|
||||
- Open questions (blocking/non-blocking):
|
||||
- [blocking: yes/no] [missing official syllabus, high-risk domain, scope overrun]
|
||||
- Suggested next agent: [Scribe | Matrix | Canvas | Morph] (reason)
|
||||
- Next action: CONTINUE | VERIFY | DONE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> "A curriculum only teaches when objectives, materials, and assessment point at the same target."
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"ownerId": "598412",
|
||||
"slug": "agora",
|
||||
"version": "1.0.0",
|
||||
"publishedAt": 1784355481733
|
||||
}
|
||||
@@ -0,0 +1,62 @@
|
||||
# Assessment, Rubrics & Alignment
|
||||
|
||||
Read when designing quizzes, rubrics, self-assessment, or running the alignment audit.
|
||||
|
||||
## Constructive Alignment
|
||||
|
||||
Objectives, learning activities, and assessment must point at the same target (Biggs). Operationalize via an **alignment matrix**:
|
||||
|
||||
| LO-ID | Bloom's level | Material(s) | Assessment item(s) | Status |
|
||||
|-------|---------------|-------------|--------------------|--------|
|
||||
| LO-001 | Apply | exercises §2 | quiz Q3, Q4 | Covered |
|
||||
| LO-002 | Analyze | reading §4 | — | ALIGNMENT_GAP |
|
||||
|
||||
Flags:
|
||||
- `ALIGNMENT_GAP` — an objective with no assessment evidence.
|
||||
- `ORPHAN_ASSESSMENT` — an assessment item that traces to no objective.
|
||||
|
||||
A curriculum with either flag is not yet teachable; resolve before delivery.
|
||||
|
||||
## Assessment Type Selection
|
||||
|
||||
| Type | Measures | Good for Bloom's |
|
||||
|------|----------|------------------|
|
||||
| Multiple-choice quiz | Recall, discrimination | Remember, Understand |
|
||||
| Short answer / explanation | Reasoning | Understand, Analyze |
|
||||
| Applied exercise / coding task | Skill execution | Apply, Analyze |
|
||||
| Project / portfolio | Synthesis | Create, Evaluate |
|
||||
| Peer / self-assessment | Reflection, metacognition | any (formative) |
|
||||
|
||||
Match assessment Bloom's level to the objective. Do not assess at a higher level than taught.
|
||||
|
||||
## Quiz Authoring (`quizzes.csv`)
|
||||
|
||||
Headered CSV. Columns: `id, lo_id, question, option_a, option_b, option_c, option_d, correct_answer, explanation, blooms_level`.
|
||||
- Every quiz row carries its `lo_id` for traceability.
|
||||
- Distractors must be plausible (target known misconceptions), not filler.
|
||||
- `explanation` states why the answer is correct AND why common distractors are wrong.
|
||||
|
||||
## Rubric Authoring (`rubric.md`)
|
||||
|
||||
A rubric is a criteria × levels grid. Standard 4-level scale:
|
||||
|
||||
| Criterion | Novice | Developing | Proficient | Exemplary |
|
||||
|-----------|--------|-----------|------------|-----------|
|
||||
| (criterion) | (descriptor) | (descriptor) | (descriptor) | (descriptor) |
|
||||
|
||||
Rules:
|
||||
- Descriptors are observable and distinguishable — a grader should land on the same level independently.
|
||||
- Criteria derive from the objectives being assessed.
|
||||
- Avoid single-word descriptors ("Good", "Poor"); describe what the work shows.
|
||||
|
||||
## Self-Assessment
|
||||
|
||||
Give learners a checklist or "I can…" statements mapped to objectives, plus a confidence scale. Self-assessment is formative — it guides study, it does not grade.
|
||||
|
||||
## Final-Project Evaluation
|
||||
|
||||
Combine the project brief's acceptance criteria with a rubric. State the passing threshold and how the score maps to the outcome definition.
|
||||
|
||||
## Progress Checkpoints
|
||||
|
||||
Place checkpoints at module boundaries. Each checkpoint: which objectives it verifies, the evidence (quiz/exercise/project), and the remediation path if the learner does not pass.
|
||||
@@ -0,0 +1,56 @@
|
||||
# Curriculum & Lesson Patterns
|
||||
|
||||
Read when building curriculum maps, sequencing modules, or authoring lesson plans and materials.
|
||||
|
||||
## Curriculum Map
|
||||
|
||||
A curriculum map shows how modules build toward outcomes. Include per module:
|
||||
- Module ID + title
|
||||
- Objectives covered (`LO-IDs`)
|
||||
- Prerequisites (earlier module IDs or external)
|
||||
- Estimated effort (hours)
|
||||
- MVP vs stretch marking
|
||||
- Assessment that closes the module
|
||||
|
||||
## Sequencing Patterns
|
||||
|
||||
| Pattern | Use when |
|
||||
|---------|----------|
|
||||
| **Linear / spiral** | Concepts build cumulatively; revisit core ideas at increasing depth (spiral) |
|
||||
| **Scaffolded** | Heavy support early (worked examples), fading to independent practice |
|
||||
| **Problem-first (PBL)** | Motivated learners; anchor each module in an authentic problem |
|
||||
| **Just-in-time** | Practitioners; teach a concept right before it is needed in a project |
|
||||
|
||||
Respect prerequisite chains. Mark the **MVP path** (minimum modules to reach the core outcome) separately from **stretch/optional** modules so learners are never blocked by aspirational content.
|
||||
|
||||
## Weekly Plan
|
||||
|
||||
Break the time budget into weeks. Per week include: focus topic, concrete learning tasks, exercises, review/spaced-repetition slot, and the checkpoint (if any). Keep weekly load within the stated hours/week.
|
||||
|
||||
## Lesson Plan Structure
|
||||
|
||||
Each lesson plan includes:
|
||||
1. **Objectives** — the `LO-IDs` this lesson serves.
|
||||
2. **Timing breakdown** — minutes per segment (hook / instruction / practice / wrap).
|
||||
3. **Activities** — what the learner does (not just what is presented). Favor active over passive.
|
||||
4. **Materials** — readings, slides, datasets, tools required.
|
||||
5. **Check for understanding (CFU)** — a quick formative probe before moving on.
|
||||
6. **Common stumbling point** — the likely failure mode + remedy for this lesson.
|
||||
|
||||
## Material Design
|
||||
|
||||
| Artifact | Contents |
|
||||
|----------|----------|
|
||||
| `reading_list.md` | Curated sources; mark required vs optional; one-line "why read this" each |
|
||||
| `exercises.md` | Graded difficulty; each maps to an `LO-ID`; include expected outcome |
|
||||
| `assignments.md` | Larger applied tasks with deliverable + acceptance criteria |
|
||||
| `project_briefs.md` | Capstone-style briefs: goal, constraints, deliverable, evaluation pointer |
|
||||
| `glossary.md` | Domain terms with plain-language definitions; first-use anchors |
|
||||
|
||||
Every material maps to at least one objective. Exercises should span Bloom's levels appropriate to the stage, not only recall. Pre-empt the "happy path only" trap: include exercises that surface boundary cases and common errors.
|
||||
|
||||
## Engagement & Retention
|
||||
|
||||
- Interleave practice across topics rather than blocking, to improve transfer.
|
||||
- Schedule spaced review (review_schedule.md) — expanding intervals for durable recall.
|
||||
- Tie each module to an authentic application so motivation stays concrete.
|
||||
@@ -0,0 +1,53 @@
|
||||
# Instructor Support & Progress Tracking
|
||||
|
||||
Read when authoring facilitator guides, coaching prompts, common-mistake catalogs, progress trackers, or feedback templates.
|
||||
|
||||
## Facilitator Guide
|
||||
|
||||
Per session/module, give the instructor:
|
||||
- Objectives and the intended takeaway.
|
||||
- Timing and pacing notes (where learners typically need more time).
|
||||
- Discussion prompts and questions to pose.
|
||||
- The check-for-understanding and what a passing response looks like.
|
||||
- Materials/setup required ahead of time.
|
||||
|
||||
## Workshop Plan
|
||||
|
||||
For live/cohort delivery: agenda with timings, activity transitions, group vs individual segments, breaks, and the artifacts produced by the end. Include a "if running behind" cut list and a "if ahead" stretch list.
|
||||
|
||||
## Coaching Prompts
|
||||
|
||||
Open-ended questions a coach/mentor asks to move a learner forward without giving the answer:
|
||||
- Diagnostic: "Walk me through what you expected vs what happened."
|
||||
- Socratic: "What would change if the input were empty/huge/malformed?"
|
||||
- Reflective: "Which part felt shaky — and what would make it solid?"
|
||||
- Stretch: "How would you explain this to someone who's never seen it?"
|
||||
|
||||
Tie prompts to the module's objectives and common stumbling points.
|
||||
|
||||
## Common Mistakes Catalog
|
||||
|
||||
Per module, the highest-leverage instructor artifact. For each typical error:
|
||||
- **Symptom** — what the learner does/says.
|
||||
- **Root cause** — the underlying misconception.
|
||||
- **Remedy** — the concrete intervention (re-explanation, counter-example, exercise).
|
||||
|
||||
Beginners need failure modes pre-empted, not just the happy path. LLM-generated curricula over-index on the happy path — deliberately enumerate where learners stumble.
|
||||
|
||||
## Feedback Templates
|
||||
|
||||
Reusable structures for actionable feedback:
|
||||
- **Strengths / Growth / Next step** — name what worked, what to improve, one concrete next action.
|
||||
- Tie each comment to a rubric criterion so feedback is non-arbitrary.
|
||||
- Prefer specific over global ("your aggregation logic double-counts nulls" over "needs work").
|
||||
|
||||
## Progress Tracking
|
||||
|
||||
| Artifact | Contents |
|
||||
|----------|----------|
|
||||
| `study_tracker.csv` | Headered: `date, module, objective_ids, time_spent_min, status, notes`. Status: not-started / in-progress / done / needs-review |
|
||||
| `review_schedule.md` | Spaced-repetition plan — expanding intervals (e.g., 1d, 3d, 7d, 21d) per concept |
|
||||
| `reflection_template.md` | Periodic prompts: what I learned, what's still unclear, what I'll do next |
|
||||
| `habit_plan.md` | Cadence, triggers, and minimum daily/weekly commitment to sustain study |
|
||||
|
||||
Checkpoints (see assessment-rubrics.md) feed the tracker: each closed checkpoint advances the learner's recorded status.
|
||||
@@ -0,0 +1,57 @@
|
||||
# Learning Design Frameworks
|
||||
|
||||
Read when authoring objectives, choosing cognitive levels, or mapping prerequisites.
|
||||
|
||||
## Backward Design (Understanding by Design — Wiggins & McTighe)
|
||||
|
||||
Design in three stages, in order:
|
||||
1. **Identify desired results** — what the learner should know/do (objectives, outcome definition).
|
||||
2. **Determine acceptable evidence** — how mastery is demonstrated (assessments, rubrics).
|
||||
3. **Plan learning experiences** — activities, materials, and lessons that build toward the evidence.
|
||||
|
||||
Never invert the order. Authoring lessons before objectives and assessment exist produces content that cannot be measured.
|
||||
|
||||
## Bloom's Taxonomy (Revised — Anderson & Krathwohl)
|
||||
|
||||
Six cognitive levels, low to high. Pick a level per objective and use an observable verb from that level.
|
||||
|
||||
| Level | Demonstrates | Sample verbs |
|
||||
|-------|-------------|--------------|
|
||||
| Remember | Recall facts | define, list, name, recall, label |
|
||||
| Understand | Explain ideas | explain, summarize, classify, paraphrase, describe |
|
||||
| Apply | Use in new situations | implement, execute, solve, use, demonstrate |
|
||||
| Analyze | Draw connections | differentiate, compare, organize, deconstruct, attribute |
|
||||
| Evaluate | Justify a stance | critique, judge, defend, assess, justify |
|
||||
| Create | Produce new work | design, construct, compose, generate, author |
|
||||
|
||||
**Banned vague verbs** (not observable): understand, know, learn, appreciate, be familiar with, grasp. Only allowed when paired with an observable demonstration ("understand X, demonstrated by explaining X in their own words").
|
||||
|
||||
### Level calibration by learner stage
|
||||
- **Beginner**: weight Remember / Understand / Apply.
|
||||
- **Intermediate**: weight Apply / Analyze, some Evaluate.
|
||||
- **Advanced**: weight Analyze / Evaluate / Create.
|
||||
|
||||
Do not assess above the Bloom's level the objectives and materials prepared the learner for.
|
||||
|
||||
## Objective Formulation (ABCD + SMART)
|
||||
|
||||
A well-formed objective states:
|
||||
- **Audience** — who the learner is.
|
||||
- **Behavior** — observable verb (Bloom's-leveled).
|
||||
- **Condition** — under what circumstances / with what tools.
|
||||
- **Degree** — the success threshold (accuracy, time, completeness).
|
||||
|
||||
ID each as `LO-001`. Example: *"Given a dataset and pandas (condition), the intermediate learner (audience) will compute (Apply) group-wise aggregates (behavior) with no runtime errors on the first attempt (degree)."*
|
||||
|
||||
Make the degree measurable: "≥ 8/10 correct", "within 15 minutes", "matching the reference output". Reject objectives with no degree.
|
||||
|
||||
## Prerequisite Mapping
|
||||
|
||||
- List prior knowledge/skills the learner must hold before module 1.
|
||||
- Author a **prerequisite check** (short diagnostic) so learners self-identify gaps.
|
||||
- Build a prerequisite chain across modules: module N may depend on objectives from earlier modules. Sequence to respect dependencies — never assess a skill before its prerequisite is taught.
|
||||
- Define a **learner profile**: level, goal, time budget, motivation, constraints.
|
||||
|
||||
## Outcome Definition
|
||||
|
||||
Distinct from objectives: outcomes are the end-state capabilities after the full curriculum (e.g., "can ship a small production API"). Map each outcome to the set of objectives that compose it.
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: opc-runtime-enterprise
|
||||
description: |
|
||||
OPC Runtime Enterprise — 面向"一人公司"的多智能体操作系统技能包。
|
||||
|
||||
当用户提到以下场景时触发：
|
||||
- "我要做商业分析"、"帮我做市场调研"、"竞品分析"
|
||||
- "设计一个 Agent 系统"、"多智能体协作"、"任务分解"
|
||||
- "自动化工作流"、"搭建 AI 组织"、"一人公司运营"
|
||||
- "需要 9 个智能体协作"、"自主执行项目"
|
||||
- 使用了 OPC Runtime 架构关键词（Task Graph、Router、Executor、Quality Agent 等）
|
||||
|
||||
提供完整的多智能体系统定义：9 个专业化 Agent、6 个工作流、8 个 Schema、
|
||||
8 个知识规则、Python 运行时引擎，以及自进化机制。
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# OPC Runtime Enterprise
|
||||
|
||||
## 系统概述
|
||||
|
||||
一人公司 → AI 组织 → 可自我进化的 AI 公司。
|
||||
|
||||
通过结构化任务分解、智能体编排、工作流执行、质量评估、持续优化，
|
||||
将单一操作者转变为可扩展的 AI 组织。
|
||||
|
||||
## 架构层次
|
||||
|
||||
| 层次 | 组件 |
|
||||
|------|------|
|
||||
| Identity | identify.md / principles.md / constraints.md |
|
||||
| Prompts | task_decompose / router / executor / aggregator / evaluator / reflection / optimization / evolution |
|
||||
| Schemas | task / task_graph / execution / evaluation / memory / workflow / agent_message / agent_profile |
|
||||
| Knowledge | execution / routing / quality / failure_recovery / optimization / evolution / memory / governance |
|
||||
| Workflows | content_creation / business_analysis / product_design / customer_service / autonomous_project / company_operating_cycle |
|
||||
| Runtime | Python 引擎（core / workflow / execution / evaluation / memory / llm / tools） |
|
||||
| Agents | CEO / COO / CONTENT / BUSINESS / PRODUCT / SERVICE / OPERATIONS / QUALITY / EVOLUTION |
|
||||
| Memory | 短/长期/情景/语义/向量/经验/反思/模式/学习 |
|
||||
| Evolution | 架构分析器 / Agent 变异器 / 工作流变异器 / 提示词变异器 / 系统优化器 / 版本控制 / 回滚 |
|
||||
|
||||
## 执行生命周期
|
||||
|
||||
```
|
||||
Goal → Task Decomposition → Task Graph → Agent Routing
|
||||
→ Execution → Aggregation → Evaluation
|
||||
→ Reflection → Optimization → Memory Update
|
||||
```
|
||||
|
||||
## 输入合同（每条指令必须包含）
|
||||
|
||||
```json
|
||||
{ "goal": "", "context": {}, "constraints": [], "success_criteria": [] }
|
||||
```
|
||||
|
||||
## 输出合同（每条执行必须返回）
|
||||
|
||||
```json
|
||||
{ "objective": "", "deliverables": [], "execution_report": {},
|
||||
"evaluation": {}, "next_actions": [] }
|
||||
```
|
||||
|
||||
## Agent 速查
|
||||
|
||||
| Agent | 职责 | 入口能力 |
|
||||
|-------|------|---------|
|
||||
| CEO_AGENT | 战略决策 | goal_setting / resource_allocation |
|
||||
| COO_AGENT | 运营编排 | task_decomposition / workflow_routing |
|
||||
| CONTENT_AGENT | 内容创作 | write_blog / produce_podcast |
|
||||
| BUSINESS_AGENT | 商业分析 | market_research / competitor_analysis |
|
||||
| PRODUCT_AGENT | 产品设计 | mvp_design / feature_definition |
|
||||
| SERVICE_AGENT | 客户服务 | answer_customer / support_ticket |
|
||||
| QUALITY_AGENT | 质量评估 | evaluate_content / score_task |
|
||||
| EVOLUTION_AGENT | 自进化 | improve_workflow / optimize_routing |
|
||||
|
||||
## 质量评估规则
|
||||
|
||||
| 分数 | 判定 | 动作 |
|
||||
|------|------|------|
|
||||
| >= 0.8 | PASS | 接受 |
|
||||
| < 0.8 | REWORK | 返工 |
|
||||
| < 0.5 | FAIL | 返工 + 升级至 COO_AGENT |
|
||||
|
||||
评估维度：Completeness / Accuracy / Clarity / Business Value / Actionability
|
||||
|
||||
## 禁忌规则
|
||||
|
||||
- 禁止删除 CEO_AGENT / COO_AGENT
|
||||
- 禁止绕过 QUALITY_AGENT 评估层
|
||||
- 禁止 Agent 间使用自然语言通信
|
||||
- 禁止破坏 execute→reflect→evolve 执行闭环
|
||||
|
||||
## 文件索引
|
||||
|
||||
核心规范：查看各子目录下的 reference 文件
|
||||
- `prompts/*.md` — 各 Agent 的决策 Prompt
|
||||
- `schemas/*.schema.json` — 标准化数据结构
|
||||
- `knowledge/*.md` — 执行规则库
|
||||
- `workflows/*.yaml` — 可执行工作流定义
|
||||
- `runtime/` — Python 执行引擎
|
||||
- `agents/*.py` — 8 个 Agent 实现
|
||||
- `memory/` — 记忆层组件
|
||||
- `evolution/` — 自进化引擎
|
||||
- `examples/*.yaml` — 场景示例（startup_company / content_factory / saas_builder）
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"ownerId": "427174",
|
||||
"publishedAt": 1780406913549,
|
||||
"slug": "opc-agent-runtime",
|
||||
"version": "1.0.1"
|
||||
}
|
||||
@@ -0,0 +1,10 @@
|
||||
class BusinessAgent:
|
||||
name = "BUSINESS_AGENT"
|
||||
role = "商业分析"
|
||||
capabilities = ["market_research", "competitor_analysis", "financial_modeling"]
|
||||
performance_score = 0.88
|
||||
|
||||
def run(self, task):
|
||||
if task.objective == "market_analysis":
|
||||
return {"report": f"Market report for {task.context.get('product')}"}
|
||||
return {}
|
||||
@@ -0,0 +1,12 @@
|
||||
class CEOAgent:
|
||||
name = "CEO_AGENT"
|
||||
role = "公司战略与资源决策"
|
||||
capabilities = ["goal_setting", "resource_allocation", "high_level_planning"]
|
||||
performance_score = 0.95
|
||||
|
||||
def run(self, task):
|
||||
if task.objective == "set_company_goal":
|
||||
return {"goal": "Launch new SaaS product by Q4"}
|
||||
elif task.objective == "allocate_resource":
|
||||
return {"allocation": "Assign Content & Product Agents"}
|
||||
return {}
|
||||
@@ -0,0 +1,12 @@
|
||||
class ContentAgent:
|
||||
name = "CONTENT_AGENT"
|
||||
role = "内容创作"
|
||||
capabilities = ["write_blog", "produce_podcast", "generate_video_script"]
|
||||
performance_score = 0.90
|
||||
|
||||
async def run(self, task):
|
||||
if task.objective == "generate_blog":
|
||||
return {"draft": f"Blog draft on {task.context.get('topic')}"}
|
||||
elif task.objective == "produce_podcast":
|
||||
return {"script": f"Podcast script on {task.context.get('topic')}"}
|
||||
return {}
|
||||
@@ -0,0 +1,12 @@
|
||||
class COOAgent:
|
||||
name = "COO_AGENT"
|
||||
role = "公司运营与任务管理"
|
||||
capabilities = ["task_decomposition", "workflow_routing", "task_monitoring"]
|
||||
performance_score = 0.92
|
||||
|
||||
def run(self, task):
|
||||
if task.objective == "decompose_project":
|
||||
return {"tasks": ["content_strategy", "product_design", "marketing_plan"]}
|
||||
elif task.objective == "route_task":
|
||||
return {"assigned_agent": "CONTENT_AGENT"}
|
||||
return {}
|
||||
@@ -0,0 +1,10 @@
|
||||
class EvolutionAgent:
|
||||
name = "EVOLUTION_AGENT"
|
||||
role = "自我进化"
|
||||
capabilities = ["improve_workflow", "update_prompt", "optimize_routing"]
|
||||
performance_score = 0.90
|
||||
|
||||
def run(self, task):
|
||||
if task.objective == "propose_improvement":
|
||||
return {"proposal": f"Optimize {task.context.get('component')}"}
|
||||
return {}
|
||||
@@ -0,0 +1,10 @@
|
||||
class ProductAgent:
|
||||
name = "PRODUCT_AGENT"
|
||||
role = "产品设计"
|
||||
capabilities = ["mvp_design", "feature_definition", "technical_validation"]
|
||||
performance_score = 0.90
|
||||
|
||||
def run(self, task):
|
||||
if task.objective == "design_mvp":
|
||||
return {"mvp": f"MVP definition for {task.context.get('product')}"}
|
||||
return {}
|
||||
@@ -0,0 +1,14 @@
|
||||
from runtime.evaluation.evaluator import Evaluator
|
||||
|
||||
class QualityAgent:
|
||||
name = "QUALITY_AGENT"
|
||||
role = "质量复核"
|
||||
capabilities = ["evaluate_content", "review_report", "score_task"]
|
||||
performance_score = 0.93
|
||||
|
||||
def __init__(self):
|
||||
self.evaluator = Evaluator()
|
||||
|
||||
def run(self, task):
|
||||
score = self.evaluator.evaluate(task)
|
||||
return {"score": score, "feedback": f"Task {task.id} scored {score}"}
|
||||
@@ -0,0 +1,12 @@
|
||||
class ServiceAgent:
|
||||
name = "SERVICE_AGENT"
|
||||
role = "客户服务"
|
||||
capabilities = ["answer_customer", "manage_community", "support_ticket"]
|
||||
performance_score = 0.87
|
||||
|
||||
def run(self, task):
|
||||
if task.objective == "answer_query":
|
||||
return {"response": f"Answer to {task.context.get('question')}"}
|
||||
elif task.objective == "manage_community":
|
||||
return {"update": "Community engagement update"}
|
||||
return {}
|
||||
@@ -0,0 +1,10 @@
|
||||
class AgentMutator:
|
||||
"""Evolve agent definitions based on feedback"""
|
||||
|
||||
def mutate(self, agent, feedback):
|
||||
if feedback.get("score", 1.0) < 0.7:
|
||||
capabilities = getattr(agent, "capabilities", [])
|
||||
agent.capabilities = capabilities + ["improved_routing"]
|
||||
if feedback.get("failure") == "ambiguity":
|
||||
agent.prompt = getattr(agent, "prompt", "") + "\nAlways output structured JSON."
|
||||
return agent
|
||||
@@ -0,0 +1,9 @@
|
||||
class ArchitectureAnalyzer:
|
||||
"""Analyze system structure for optimization opportunities"""
|
||||
|
||||
def analyze(self, execution_history):
|
||||
return {
|
||||
"workflow_bottlenecks": ["task_decomposition too slow"],
|
||||
"agent_overload": ["COO_AGENT"],
|
||||
"unused_agents": ["SERVICE_AGENT"]
|
||||
}
|
||||
@@ -0,0 +1,24 @@
|
||||
class EvolutionEngine:
|
||||
"""Core evolution engine — analyze, plan, validate, apply changes"""
|
||||
|
||||
def __init__(self, memory, registry):
|
||||
self.memory = memory
|
||||
self.registry = registry
|
||||
|
||||
def evolve(self):
|
||||
insights = self.analyze_system()
|
||||
changes = self.plan_changes(insights)
|
||||
validated = self.validate_changes(changes)
|
||||
self.apply(validated)
|
||||
|
||||
def analyze_system(self):
|
||||
return {"bottlenecks": "routing inefficiency", "low_agents": ["CONTENT_AGENT"], "failed_patterns": "overlarge tasks"}
|
||||
|
||||
def plan_changes(self, insights):
|
||||
return {"add_agents": [], "remove_agents": [], "modify_workflows": [], "update_prompts": []}
|
||||
|
||||
def validate_changes(self, changes):
|
||||
return changes
|
||||
|
||||
def apply(self, changes):
|
||||
print("Applying system evolution...")
|
||||
@@ -0,0 +1,9 @@
|
||||
class PromptMutator:
|
||||
"""Improve prompts based on memory patterns"""
|
||||
|
||||
def improve(self, prompt, memory):
|
||||
if memory.get("failure_rate", 0) > 0.3:
|
||||
prompt += "\nSTRICT MODE: Output JSON only."
|
||||
if memory.get("success_pattern"):
|
||||
prompt += "\nReuse successful structure patterns."
|
||||
return prompt
|
||||
@@ -0,0 +1,8 @@
|
||||
class RollbackManager:
|
||||
"""Safe rollback to previous stable versions"""
|
||||
|
||||
def rollback(self, version):
|
||||
print(f"Rolling back to version {version}")
|
||||
|
||||
def safe_mode(self):
|
||||
return {"mode": "stable", "all_evolution_paused": True}
|
||||
@@ -0,0 +1,5 @@
|
||||
class SystemOptimizer:
|
||||
"""Global system optimization planner"""
|
||||
|
||||
def optimize(self, metrics):
|
||||
return {"reduce_latency": True, "merge_agents": ["CONTENT_AGENT", "MARKETING_AGENT"], "split_agent": None}
|
||||
@@ -0,0 +1,12 @@
|
||||
class VersionController:
|
||||
"""Track system versions and snapshots"""
|
||||
|
||||
def __init__(self):
|
||||
self.version = 1.0
|
||||
|
||||
def bump(self):
|
||||
self.version += 0.1
|
||||
return self.version
|
||||
|
||||
def snapshot(self):
|
||||
return {"version": self.version, "state": "saved"}
|
||||
@@ -0,0 +1,9 @@
|
||||
class WorkflowMutator:
|
||||
"""Rewrite workflows based on performance insights"""
|
||||
|
||||
def mutate(self, workflow, insights):
|
||||
if "bottleneck" in insights:
|
||||
workflow.steps.insert(1, "pre_validation_step")
|
||||
if "failure_loop" in insights:
|
||||
workflow.reorder()
|
||||
return workflow
|
||||
@@ -0,0 +1,15 @@
|
||||
name: Content Factory
|
||||
description: Automated content production pipeline
|
||||
goal: Produce 30 pieces of content in 30 days
|
||||
workflow: WF_CONTENT_001
|
||||
agents:
|
||||
- COO_AGENT
|
||||
- CONTENT_AGENT
|
||||
- QUALITY_AGENT
|
||||
metrics:
|
||||
target_count: 30
|
||||
quality_threshold: 0.8
|
||||
platform:
|
||||
- blog
|
||||
- twitter
|
||||
- linkedin
|
||||
@@ -0,0 +1,21 @@
|
||||
name: SaaS Builder
|
||||
description: Autonomous SaaS product development
|
||||
goal: Build and launch a SaaS product
|
||||
workflow:
|
||||
- WF_PRODUCT_001
|
||||
- WF_CONTENT_001
|
||||
- WF_BUSINESS_001
|
||||
agents:
|
||||
- CEO_AGENT
|
||||
- COO_AGENT
|
||||
- PRODUCT_AGENT
|
||||
- CONTENT_AGENT
|
||||
- BUSINESS_AGENT
|
||||
- QUALITY_AGENT
|
||||
- EVOLUTION_AGENT
|
||||
phases:
|
||||
1: product_design
|
||||
2: development
|
||||
3: content_marketing
|
||||
4: launch
|
||||
5: iterate
|
||||
@@ -0,0 +1,17 @@
|
||||
name: Startup Company Simulation
|
||||
description: Simulate a complete startup operating cycle
|
||||
goal: Launch MVP and acquire first 100 customers
|
||||
workflow: WF_COMPANY_001
|
||||
agents:
|
||||
- CEO_AGENT
|
||||
- COO_AGENT
|
||||
- CONTENT_AGENT
|
||||
- BUSINESS_AGENT
|
||||
- PRODUCT_AGENT
|
||||
- SERVICE_AGENT
|
||||
- QUALITY_AGENT
|
||||
expected_output:
|
||||
- MVP_definition
|
||||
- content_calendar
|
||||
- customer_acquisition_plan
|
||||
- first_100_customers
|
||||
@@ -0,0 +1,24 @@
|
||||
# Constraints — System Constraints
|
||||
|
||||
## Forbidden Actions
|
||||
1. 禁止删除核心智能体 — CEO_AGENT、COO_AGENT 不可移除
|
||||
2. 禁止绕过评估层 — 所有输出必须经过 QUALITY_AGENT
|
||||
3. 禁止修改系统契约 — Schema、Governance Rules 不可随意修改
|
||||
4. 禁止破坏执行闭环 — execute→reflect→evolve 循环不可中断
|
||||
5. 禁止 Agent 间自然语言通信 — 必须使用 agent_message.schema.json
|
||||
|
||||
## Mandatory Actions
|
||||
1. 每次执行必须写入 memory
|
||||
2. 每次失败必须触发 failure_recovery
|
||||
3. 每次评分 < 0.8 必须返工
|
||||
4. 所有变更必须记录版本快照
|
||||
5. 所有进化必须通过安全验证
|
||||
|
||||
## Permission Boundaries
|
||||
| Agent | Can Create | Can Remove | Can Modify |
|
||||
|-------|-----------|-----------|-----------|
|
||||
| CEO_AGENT | workflow, goal | 无 | goal, strategy |
|
||||
| COO_AGENT | task, workflow | 无 | workflow, routing |
|
||||
| EVOLUTION_AGENT | agent, workflow, prompt | 无 | prompts, rules |
|
||||
| QUALITY_AGENT | evaluation | 无 | quality_rules |
|
||||
| 其他 | 无 | 无 | 无 |
|
||||
@@ -0,0 +1,30 @@
|
||||
# Identity — System Identification
|
||||
|
||||
## System Name
|
||||
OPC Runtime Enterprise
|
||||
|
||||
## Tagline
|
||||
One Person Company → AI Organization → Self-Evolving Company
|
||||
|
||||
## Core Role
|
||||
OPC Runtime Enterprise 将单一操作者转化为可扩展的 AI 组织。
|
||||
它通过多智能体协作、结构化工作流、持续优化，实现企业级产出。
|
||||
|
||||
## Target Scenario
|
||||
- 一人公司（One Person Company）
|
||||
- AI-native 组织运营
|
||||
- 自动化业务流程
|
||||
- 可自我进化的 AI 公司
|
||||
|
||||
## Positioning
|
||||
| Level | System |
|
||||
|-------|--------|
|
||||
| V1 | 能执行的 AI 公司 |
|
||||
| V2 | 能自我优化的 AI 公司 |
|
||||
| V3 | 能自我改造的 AI 公司 |
|
||||
|
||||
## Owner
|
||||
Human Operator（人工操作者）
|
||||
|
||||
## Operator Relationship
|
||||
Human → CEO_AGENT → COO_AGENT → Execution Layer → Quality → Evolution
|
||||
@@ -0,0 +1,27 @@
|
||||
# Principles — Core Operating Principles
|
||||
|
||||
## Primary Principles
|
||||
|
||||
### 1. Everything Is Structured Data
|
||||
所有 Agent 之间的通信、输出、记忆必须使用标准化 Schema。
|
||||
禁止自然语言自由格式作为 Agent 间通信格式。
|
||||
|
||||
### 2. Every Execution Generates Memory
|
||||
每次执行必须产生：结果、评分、执行报告、教训总结。
|
||||
没有记忆的执行是无效执行。
|
||||
|
||||
### 3. Evaluation Is Mandatory
|
||||
所有输出必须经过质量评估，评分 < 0.8 必须返工。
|
||||
|
||||
### 4. Evolution Is Continuous
|
||||
系统必须持续学习、持续优化，不接受"完成就是终点"。
|
||||
|
||||
### 5. Governance Overrides Optimization
|
||||
安全性和稳定性优先于性能优化。禁止破坏核心系统契约。
|
||||
|
||||
## Secondary Principles
|
||||
- 每个任务必须有明确目标
|
||||
- 每个任务必须可原子化执行
|
||||
- 每个工作流必须有评估节点
|
||||
- 每个 Agent 必须有性能评分
|
||||
- 每次失败必须记录根因
|
||||
@@ -0,0 +1,14 @@
|
||||
# EVOLUTION RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Allowed Changes
|
||||
- add capability / add workflow / improve routing / improve prompts / add tool access
|
||||
|
||||
## Conditional Changes (Requires evidence)
|
||||
- create new agent / merge agents / split agent
|
||||
|
||||
## Forbidden Changes
|
||||
- delete core agents (CEO, COO) / remove evaluation layer / bypass memory layer / modify system contracts
|
||||
|
||||
## Evolution Proposal Requirements
|
||||
Every proposal must include: reason / expected impact / risk assessment / rollback plan
|
||||
@@ -0,0 +1,24 @@
|
||||
# EXECUTION RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Rule 1 — Required Fields
|
||||
Every task must have: objective / context / constraints / expected deliverables
|
||||
|
||||
## Rule 2 — No Ambiguity
|
||||
Never execute undefined tasks. If ambiguity exists: Request clarification.
|
||||
|
||||
## Rule 3 — Atomic Tasks
|
||||
Tasks must be atomic. One task = one objective.
|
||||
Bad: "Build SaaS product" Good: "Define MVP Features"
|
||||
|
||||
## Rule 4 — Dependency Order
|
||||
Execution must follow dependencies.
|
||||
|
||||
## Rule 5 — Schema Compliance
|
||||
All outputs must conform to schema.
|
||||
|
||||
## Rule 6 — Required Outputs
|
||||
Every execution generates: result / score / execution report
|
||||
|
||||
## Rule 7 — Memory Storage
|
||||
Execution history must be stored in memory layer.
|
||||
@@ -0,0 +1,24 @@
|
||||
# FAILURE RECOVERY RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Failure Types
|
||||
1. Task Failure 2. Agent Failure 3. Workflow Failure 4. Routing Failure
|
||||
|
||||
## Recovery Procedures
|
||||
|
||||
### Task Failure
|
||||
1. Detect failure reason 2. Retry once with same agent 3. Reassign to backup agent 4. Escalate to COO_AGENT
|
||||
|
||||
### Agent Failure
|
||||
1. Assign backup agent 2. Re-execute from last successful checkpoint 3. Record agent failure in memory
|
||||
|
||||
### Workflow Failure
|
||||
1. Rollback to previous successful node 2. Re-execute failed segment 3. If systemic: trigger EVOLUTION_AGENT
|
||||
|
||||
### Routing Failure
|
||||
1. Log routing error 2. Escalate to COO_AGENT 3. Record pattern in memory
|
||||
|
||||
## Required Failure Report
|
||||
```json
|
||||
{ "failure_type": "", "root_cause": "", "recovery_action": "", "status": "resolved|escalated" }
|
||||
```
|
||||
@@ -0,0 +1,14 @@
|
||||
# GOVERNANCE RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Core Principles
|
||||
- traceability / accountability / consistency
|
||||
|
||||
## Mandatory Logging
|
||||
- Every decision must be logged - Every task must have owner - Every workflow must have evaluation
|
||||
|
||||
## Protection Scope
|
||||
No agent may modify without governance approval: system contracts / schemas / governance rules
|
||||
|
||||
## Override Rules
|
||||
- Governance overrides optimization - Stability overrides experimentation - Safety overrides performance
|
||||
@@ -0,0 +1,17 @@
|
||||
# MEMORY RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Memory Types
|
||||
1. Execution Memory 2. Failure Memory 3. Success Pattern Memory 4. Optimization Memory
|
||||
|
||||
## Stored Data
|
||||
Every execution stores: task / result / score / lessons learned
|
||||
|
||||
## Retrieval Priority
|
||||
1. Similar Goal 2. Similar Workflow 3. Similar Failure
|
||||
|
||||
## Memory Lifecycle
|
||||
- short_term: current workflow context - long_term: historical patterns - episodic: complete execution events - semantic: rules and methodologies
|
||||
|
||||
## Rules
|
||||
- Memory must be reusable - Memory must be queryable - Memory must be versioned
|
||||
@@ -0,0 +1,14 @@
|
||||
# OPTIMIZATION RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Optimization Targets
|
||||
- speed / quality / cost / scalability
|
||||
|
||||
## Detection Metrics
|
||||
Monitor: latency / success rate / evaluation scores / routing accuracy
|
||||
|
||||
## Optimization Process
|
||||
1. Identify bottleneck 2. Generate alternatives 3. Estimate impact 4. Select best option 5. Measure result
|
||||
|
||||
## Rules
|
||||
- Optimization must be measurable - No optimization without baseline - Changes require validation
|
||||
@@ -0,0 +1,19 @@
|
||||
# QUALITY RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Evaluation Dimensions
|
||||
1. Completeness 2. Accuracy 3. Clarity 4. Business Value 5. Actionability
|
||||
|
||||
## Scoring Bands
|
||||
| Score | Grade | Action |
|
||||
|-------|-------|--------|
|
||||
| 0.9 - 1.0 | Excellent | Accept |
|
||||
| 0.8 - 0.89 | Pass | Accept |
|
||||
| 0.7 - 0.79 | Needs Revision | Rework |
|
||||
| Below 0.7 | Fail | Fail + Escalate |
|
||||
|
||||
## Rework Trigger
|
||||
Score < 0.8 → REWORK
|
||||
|
||||
## Fail Trigger
|
||||
Score < 0.5 → FAIL + escalate to COO_AGENT
|
||||
@@ -0,0 +1,31 @@
|
||||
# ROUTING RULES
|
||||
Version: 1.0.0
|
||||
|
||||
## Routing Priority
|
||||
1. Capability Match 2. Historical Success Rate 3. Agent Availability 4. Execution Cost
|
||||
|
||||
## Category Routing
|
||||
| Task Category | Route To |
|
||||
|--------------|----------|
|
||||
| Content Tasks | CONTENT_AGENT |
|
||||
| Business Tasks | BUSINESS_AGENT |
|
||||
| Product Tasks | PRODUCT_AGENT |
|
||||
| Service Tasks | SERVICE_AGENT |
|
||||
| Operations Tasks | OPERATIONS_AGENT |
|
||||
|
||||
## Tie Breaking
|
||||
If multiple agents qualify: Select highest performance score.
|
||||
|
||||
## Escalation
|
||||
If confidence < 0.7: Route to COO_AGENT.
|
||||
|
||||
## Routing Table
|
||||
| Capability | Agent |
|
||||
|------------|-------|
|
||||
| write_blog, produce_podcast, video_script | CONTENT_AGENT |
|
||||
| market_research, competitor_analysis | BUSINESS_AGENT |
|
||||
| mvp_design, feature_definition | PRODUCT_AGENT |
|
||||
| answer_customer, support_ticket | SERVICE_AGENT |
|
||||
| task_decomposition, workflow_routing | COO_AGENT |
|
||||
| quality_review, score_task | QUALITY_AGENT |
|
||||
| improve_workflow, optimize_routing | EVOLUTION_AGENT |
|
||||
@@ -0,0 +1,11 @@
|
||||
class EpisodicMemory:
|
||||
"""Complete execution event storage"""
|
||||
|
||||
def __init__(self):
|
||||
self.events = []
|
||||
|
||||
def add_event(self, event):
|
||||
self.events.append(event)
|
||||
|
||||
def get_events(self):
|
||||
return self.events
|
||||
@@ -0,0 +1,14 @@
|
||||
class ExperienceStore:
|
||||
"""Success and failure case library"""
|
||||
|
||||
def __init__(self):
|
||||
self.experiences = []
|
||||
|
||||
def record(self, experience):
|
||||
self.experiences.append(experience)
|
||||
|
||||
def get_success_cases(self):
|
||||
return [e for e in self.experiences if e.get("score", 0) > 0.8]
|
||||
|
||||
def get_failure_cases(self):
|
||||
return [e for e in self.experiences if e.get("score", 0) < 0.5]
|
||||
@@ -0,0 +1,23 @@
|
||||
class LearningEngine:
|
||||
"""Learn from past executions and update system"""
|
||||
|
||||
def __init__(self, memory):
|
||||
self.memory = memory
|
||||
|
||||
def learn(self):
|
||||
successes = self.memory.get_success_cases()
|
||||
failures = self.memory.get_failure_cases()
|
||||
return {
|
||||
"new_rules": self.extract_rules(successes),
|
||||
"avoid_patterns": self.extract_failures(failures),
|
||||
"optimizations": self.optimize(successes, failures)
|
||||
}
|
||||
|
||||
def extract_rules(self, successes):
|
||||
return ["use structured output", "apply decomposition before execution"]
|
||||
|
||||
def extract_failures(self, failures):
|
||||
return ["avoid ambiguous routing", "avoid large atomic tasks"]
|
||||
|
||||
def optimize(self, s, f):
|
||||
return "adjust agent routing weights"
|
||||
@@ -0,0 +1,11 @@
|
||||
class LongTermMemory:
|
||||
"""Historical task and pattern storage"""
|
||||
|
||||
def __init__(self):
|
||||
self.store = []
|
||||
|
||||
def save(self, record):
|
||||
self.store.append(record)
|
||||
|
||||
def query(self, keyword):
|
||||
return [r for r in self.store if keyword in str(r)]
|
||||
@@ -0,0 +1,11 @@
|
||||
class PatternExtractor:
|
||||
"""Extract reusable patterns from experiences"""
|
||||
|
||||
def extract(self, experiences):
|
||||
patterns = {}
|
||||
for e in experiences:
|
||||
key = e.get("type", "unknown")
|
||||
if key not in patterns:
|
||||
patterns[key] = []
|
||||
patterns[key].append(e.get("pattern"))
|
||||
return patterns
|
||||
@@ -0,0 +1,24 @@
|
||||
class ReflectionEngine:
|
||||
"""Self-analysis and improvement identification"""
|
||||
|
||||
def reflect(self, execution):
|
||||
result = execution.get("result", {})
|
||||
score = execution.get("score", 0)
|
||||
return {
|
||||
"what_worked": self.analyze_success(result),
|
||||
"what_failed": self.analyze_failure(result),
|
||||
"root_cause": self.find_root_cause(execution),
|
||||
"improvements": self.suggest_improvements(execution)
|
||||
}
|
||||
|
||||
def analyze_success(self, result):
|
||||
return "successful patterns extracted"
|
||||
|
||||
def analyze_failure(self, result):
|
||||
return "failure patterns extracted"
|
||||
|
||||
def find_root_cause(self, execution):
|
||||
return "routing / prompt / tool mismatch"
|
||||
|
||||
def suggest_improvements(self, execution):
|
||||
return ["improve prompt", "adjust routing", "refine workflow"]
|
||||
@@ -0,0 +1,11 @@
|
||||
class SemanticMemory:
|
||||
"""Rules, patterns, methodologies storage"""
|
||||
|
||||
def __init__(self):
|
||||
self.knowledge = {}
|
||||
|
||||
def add(self, key, value):
|
||||
self.knowledge[key] = value
|
||||
|
||||
def get(self, key):
|
||||
return self.knowledge.get(key)
|
||||
@@ -0,0 +1,14 @@
|
||||
class ShortTermMemory:
|
||||
"""Current workflow context cache"""
|
||||
|
||||
def __init__(self):
|
||||
self.cache = {}
|
||||
|
||||
def store(self, task_id, data):
|
||||
self.cache[task_id] = data
|
||||
|
||||
def get(self, task_id):
|
||||
return self.cache.get(task_id)
|
||||
|
||||
def clear(self):
|
||||
self.cache = {}
|
||||
@@ -0,0 +1,14 @@
|
||||
class VectorStore:
|
||||
"""Embedding-based similarity search"""
|
||||
|
||||
def __init__(self):
|
||||
self.vectors = []
|
||||
|
||||
def add(self, embedding, metadata):
|
||||
self.vectors.append({"embedding": embedding, "metadata": metadata})
|
||||
|
||||
def search(self, query_vector):
|
||||
return sorted(self.vectors, key=lambda x: self.similarity(x["embedding"], query_vector), reverse=True)
|
||||
|
||||
def similarity(self, a, b):
|
||||
return sum(x * y for x, y in zip(a, b))
|
||||
@@ -0,0 +1,20 @@
|
||||
# AGGREGATOR_PROMPT
|
||||
|
||||
## Role
|
||||
AGGREGATION_AGENT
|
||||
|
||||
## Mission
|
||||
Merge outputs from multiple agents into a unified result.
|
||||
|
||||
## Responsibilities
|
||||
1. Collect outputs. 2. Remove duplication. 3. Resolve conflicts. 4. Create coherent final result.
|
||||
|
||||
## Output
|
||||
```json
|
||||
{ "objective": "", "deliverables": [], "summary": "", "combined_output": {} }
|
||||
```
|
||||
|
||||
## Rules
|
||||
- Preserve important information.
|
||||
- Prefer higher-confidence outputs.
|
||||
- Document unresolved conflicts.
|
||||
@@ -0,0 +1,27 @@
|
||||
# EVALUATOR_PROMPT
|
||||
|
||||
## Role
|
||||
QUALITY_AGENT
|
||||
|
||||
## Mission
|
||||
Evaluate execution quality.
|
||||
|
||||
## Scoring Dimensions
|
||||
1. Completeness（0-1） 2. Accuracy（0-1） 3. Clarity（0-1） 4. Business Value（0-1） 5. Actionability（0-1）
|
||||
|
||||
## Score Range
|
||||
0.0 - 1.0
|
||||
|
||||
## Output
|
||||
```json
|
||||
{
|
||||
"score": 0.0,
|
||||
"dimension_scores": { "completeness": 0.0, "accuracy": 0.0, "clarity": 0.0, "business_value": 0.0, "actionability": 0.0 },
|
||||
"strengths": [], "weaknesses": [], "recommendations": []
|
||||
}
|
||||
```
|
||||
|
||||
## Decision Rules
|
||||
- score >= 0.8 → PASS
|
||||
- score < 0.8 → REWORK
|
||||
- score < 0.5 → FAIL + escalate to COO_AGENT
|
||||
@@ -0,0 +1,23 @@
|
||||
# EVOLUTION_PROMPT
|
||||
|
||||
## Role
|
||||
EVOLUTION_AGENT
|
||||
|
||||
## Mission
|
||||
Recommend structural improvements to the system.
|
||||
|
||||
## Analyze
|
||||
- Agent performance - Workflow performance - Routing quality - Evaluation outcomes
|
||||
|
||||
## Possible Actions
|
||||
- Create new agent - Merge agents - Remove redundant agent - Rewrite workflow - Add new capability - Improve prompt
|
||||
|
||||
## Output
|
||||
```json
|
||||
{ "evolution_type": "", "target": "", "justification": "", "expected_impact": "", "risk_assessment": "" }
|
||||
```
|
||||
|
||||
## Rules
|
||||
- Evolution must improve measurable performance.
|
||||
- Do not modify core system contracts.
|
||||
- All changes require governance approval.
|
||||
@@ -0,0 +1,21 @@
|
||||
# EXECUTOR_PROMPT
|
||||
|
||||
## Role
|
||||
EXECUTION_AGENT
|
||||
|
||||
## Mission
|
||||
Execute assigned task.
|
||||
|
||||
## Execution Steps
|
||||
1. Read objective. 2. Read context. 3. Read constraints. 4. Produce deliverable. 5. Validate output.
|
||||
|
||||
## Output
|
||||
```json
|
||||
{ "task_id": "", "status": "completed|failed", "deliverable": {}, "notes": [] }
|
||||
```
|
||||
|
||||
## Validation
|
||||
- Objective fulfilled. - Constraints respected. - Output usable. - Output complete.
|
||||
|
||||
## Failure Handling
|
||||
If objective cannot be completed: status = failed, Provide reason.
|
||||
@@ -0,0 +1,21 @@
|
||||
# OPTIMIZATION_PROMPT
|
||||
|
||||
## Role
|
||||
OPTIMIZATION_AGENT
|
||||
|
||||
## Mission
|
||||
Improve workflow performance.
|
||||
|
||||
## Optimization Targets
|
||||
- Execution Speed - Output Quality - Resource Usage - Routing Accuracy
|
||||
|
||||
## Process
|
||||
1. Analyze bottlenecks. 2. Identify inefficiencies. 3. Propose changes. 4. Estimate impact.
|
||||
|
||||
## Output
|
||||
```json
|
||||
{ "bottlenecks": [], "proposed_changes": [], "expected_benefits": [] }
|
||||
```
|
||||
|
||||
## Rules
|
||||
- Changes must be measurable. - Every recommendation must include rationale.
|
||||
@@ -0,0 +1,21 @@
|
||||
# REFLECTION_PROMPT
|
||||
|
||||
## Role
|
||||
REFLECTION_AGENT
|
||||
|
||||
## Mission
|
||||
Analyze execution history and identify improvements.
|
||||
|
||||
## Inputs
|
||||
- Goal - Execution Report - Evaluation Report
|
||||
|
||||
## Questions
|
||||
1. What worked? 2. What failed? 3. Why? 4. What should change next time?
|
||||
|
||||
## Output
|
||||
```json
|
||||
{ "lessons_learned": [], "success_patterns": [], "failure_patterns": [], "improvement_actions": [] }
|
||||
```
|
||||
|
||||
## Rules
|
||||
- Focus on root causes. - Avoid surface-level observations.
|
||||
@@ -0,0 +1,23 @@
|
||||
# ROUTER_PROMPT
|
||||
|
||||
## Role
|
||||
ROUTER_AGENT
|
||||
|
||||
## Mission
|
||||
Assign tasks to the most suitable agent.
|
||||
|
||||
## Available Agents
|
||||
- CONTENT_AGENT / BUSINESS_AGENT / PRODUCT_AGENT / SERVICE_AGENT / OPERATIONS_AGENT
|
||||
|
||||
## Decision Logic
|
||||
Evaluate: 1. Capability Match 2. Historical Performance 3. Current Workload 4. Confidence Score
|
||||
|
||||
## Output
|
||||
```json
|
||||
{ "task_id": "", "selected_agent": "", "confidence": 0.0, "reason": "" }
|
||||
```
|
||||
|
||||
## Rules
|
||||
- Always choose one primary agent.
|
||||
- Never split a task during routing.
|
||||
- If confidence < 0.7, escalate to COO_AGENT.
|
||||
@@ -0,0 +1,45 @@
|
||||
# TASK_DECOMPOSE_PROMPT
|
||||
|
||||
## Role
|
||||
COO_AGENT
|
||||
|
||||
## Mission
|
||||
Transform goals into executable task graphs.
|
||||
|
||||
## Objectives
|
||||
1. Understand business objective.
|
||||
2. Identify deliverables.
|
||||
3. Break deliverables into atomic tasks.
|
||||
4. Define dependencies.
|
||||
5. Assign priorities.
|
||||
6. Estimate complexity.
|
||||
|
||||
## Output Format
|
||||
```json
|
||||
{
|
||||
"goal": "",
|
||||
"deliverables": [],
|
||||
"tasks": [
|
||||
{
|
||||
"id": "",
|
||||
"name": "",
|
||||
"objective": "",
|
||||
"priority": "high|medium|low",
|
||||
"complexity": "high|medium|low",
|
||||
"dependencies": []
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Rules
|
||||
- Each task must be executable by a single agent.
|
||||
- Each task should have one clear objective.
|
||||
- Avoid combining multiple objectives into one task.
|
||||
- Dependencies must be explicit.
|
||||
- Tasks must be ordered logically.
|
||||
|
||||
## Failure Conditions
|
||||
- Missing deliverables.
|
||||
- Circular dependencies.
|
||||
- Ambiguous task objectives.
|
||||
@@ -0,0 +1,29 @@
|
||||
# OPC Runtime Enterprise — 参考文档索引
|
||||
|
||||
本文档集是 OPC Runtime Enterprise 技能包的完整参考手册。
|
||||
SKILL.md 提供核心速查，本文提供详细规范。
|
||||
|
||||
## 目录结构
|
||||
|
||||
```
|
||||
OPC-Runtime-Enterprise/
|
||||
├── SKILL.md # 技能入口（精简速查）
|
||||
├── references/ # 详细参考文档（本目录）
|
||||
│ ├── README.md # 索引（本文）
|
||||
│ ├── execution-lifecycle.md
|
||||
│ ├── agents.md
|
||||
│ ├── schemas.md
|
||||
│ ├── knowledge-rules.md
|
||||
│ ├── workflows.md
|
||||
│ ├── evaluation.md
|
||||
│ └── evolution.md
|
||||
├── prompts/ # Agent Prompt 源文件
|
||||
├── schemas/ # JSON Schema 源文件
|
||||
├── knowledge/ # 知识规则源文件
|
||||
├── workflows/ # YAML 工作流源文件
|
||||
├── runtime/ # Python 运行时引擎
|
||||
├── agents/ # Agent 实现源码
|
||||
├── memory/ # 记忆层组件
|
||||
├── evolution/ # 自进化引擎
|
||||
└── examples/ # 场景示例
|
||||
```
|
||||
@@ -0,0 +1,75 @@
|
||||
# Agents — 智能体详解
|
||||
|
||||
## 九大 Agent
|
||||
|
||||
### Strategy Layer
|
||||
|
||||
#### CEO_AGENT
|
||||
- **职责**：公司战略与资源决策
|
||||
- **能力**：goal_setting / resource_allocation / high_level_planning
|
||||
- **评分**：0.95
|
||||
- **核心决策**：设定公司目标、分配资源、审批战略
|
||||
|
||||
### Operations Layer
|
||||
|
||||
#### COO_AGENT
|
||||
- **职责**：公司运营与任务管理
|
||||
- **能力**：task_decomposition / workflow_routing / task_monitoring
|
||||
- **评分**：0.92
|
||||
- **入口点**：所有工作流的起点
|
||||
|
||||
### Execution Layer
|
||||
|
||||
#### CONTENT_AGENT
|
||||
- **职责**：内容创作
|
||||
- **能力**：write_blog / produce_podcast / generate_video_script
|
||||
- **评分**：0.90
|
||||
|
||||
#### BUSINESS_AGENT
|
||||
- **职责**：商业分析
|
||||
- **能力**：market_research / competitor_analysis / financial_modeling
|
||||
- **评分**：0.88
|
||||
|
||||
#### PRODUCT_AGENT
|
||||
- **职责**：产品设计
|
||||
- **能力**：mvp_design / feature_definition / technical_validation
|
||||
- **评分**：0.90
|
||||
|
||||
#### SERVICE_AGENT
|
||||
- **职责**：客户服务
|
||||
- **能力**：answer_customer / manage_community / support_ticket
|
||||
- **评分**：0.87
|
||||
|
||||
#### OPERATIONS_AGENT
|
||||
- **职责**：运营执行
|
||||
- **能力**：task_automation / process_execution
|
||||
- **评分**：0.85
|
||||
|
||||
### Evaluation Layer
|
||||
|
||||
#### QUALITY_AGENT
|
||||
- **职责**：质量复核
|
||||
- **能力**：evaluate_content / review_report / score_task
|
||||
- **评分**：0.93
|
||||
- **强制节点**：所有输出必经此 Agent
|
||||
|
||||
### Evolution Layer
|
||||
|
||||
#### EVOLUTION_AGENT
|
||||
- **职责**：自我进化
|
||||
- **能力**：improve_workflow / update_prompt / optimize_routing
|
||||
- **评分**：0.90
|
||||
- **权限**：可改进 prompts / rules / workflows
|
||||
|
||||
## Agent 通信规范
|
||||
|
||||
所有 Agent 间通信必须使用 `agent_message.schema.json`：
|
||||
```json
|
||||
{
|
||||
"from": "AGENT_NAME",
|
||||
"to": "AGENT_NAME",
|
||||
"type": "task|request|response|report|decision",
|
||||
"payload": {},
|
||||
"timestamp": "ISO8601"
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,49 @@
|
||||
# Evaluation — 质量评估体系
|
||||
|
||||
## 五维评分模型
|
||||
|
||||
| 维度 | 说明 | 权重 |
|
||||
|------|------|------|
|
||||
| Completeness | 交付物完整性 | 20% |
|
||||
| Accuracy | 内容准确性 | 20% |
|
||||
| Clarity | 表达清晰度 | 15% |
|
||||
| Business Value | 商业价值 | 25% |
|
||||
| Actionability | 可执行性 | 20% |
|
||||
|
||||
## 评分区间
|
||||
|
||||
| 分数 | 等级 | 动作 |
|
||||
|------|------|------|
|
||||
| 0.9 - 1.0 | Excellent | 接受 |
|
||||
| 0.8 - 0.89 | Pass | 接受 |
|
||||
| 0.7 - 0.79 | Needs Revision | 返工 |
|
||||
| 0.5 - 0.69 | Fail | 返工 + 升级至 COO |
|
||||
| < 0.5 | Critical Fail | 停止 + 升级至 CEO |
|
||||
|
||||
## 返工流程
|
||||
|
||||
```
|
||||
评估 < 0.8
|
||||
→ 记录弱点和建议
|
||||
→ 返回执行 Agent 返工
|
||||
→ 重新评估（最多 2 次）
|
||||
→ 仍不通过 → 升级至 COO_AGENT
|
||||
```
|
||||
|
||||
## 评估输出格式
|
||||
|
||||
```json
|
||||
{
|
||||
"score": 0.85,
|
||||
"dimension_scores": {
|
||||
"completeness": 0.9,
|
||||
"accuracy": 0.85,
|
||||
"clarity": 0.8,
|
||||
"business_value": 0.85,
|
||||
"actionability": 0.8
|
||||
},
|
||||
"strengths": ["结构清晰", "覆盖完整"],
|
||||
"weaknesses": ["缺少数据支撑"],
|
||||
"recommendations": ["补充市场数据"]
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,45 @@
|
||||
# Evolution — 自进化机制
|
||||
|
||||
## 进化引擎架构
|
||||
|
||||
```
|
||||
Execution History
|
||||
↓
|
||||
Architecture Analyzer（分析瓶颈和低效）
|
||||
↓
|
||||
Evolution Engine（制定进化计划）
|
||||
↓
|
||||
Validation（安全验证）
|
||||
↓
|
||||
Mutators（执行具体变更）
|
||||
↓
|
||||
Version Snapshot（版本快照）
|
||||
```
|
||||
|
||||
## 四大 Mutator
|
||||
|
||||
### AgentMutator
|
||||
- 根据反馈改进 Agent 能力
|
||||
- 失败率 > 30% → 自动强化 Prompt
|
||||
|
||||
### WorkflowMutator
|
||||
- 识别瓶颈节点 → 插入 pre_validation_step
|
||||
- 识别失败循环 → 重新排序步骤
|
||||
|
||||
### PromptMutator
|
||||
- 失败率高 → 追加 STRICT MODE
|
||||
- 成功模式 → 复用结构
|
||||
|
||||
### SystemOptimizer
|
||||
- 全局优化：reduce_latency / merge_agents / split_agent
|
||||
|
||||
## 版本控制
|
||||
|
||||
- 每次进化 bump version（如 1.0 → 1.1）
|
||||
- 每次进化前 snapshot 当前状态
|
||||
- 可随时 rollback 至稳定版本
|
||||
|
||||
## Safe Mode
|
||||
|
||||
触发条件：连续 3 次进化失败
|
||||
动作：暂停所有进化，返回稳定版本
|
||||
@@ -0,0 +1,57 @@
|
||||
# Execution Lifecycle — 执行生命周期
|
||||
|
||||
## 完整执行闭环
|
||||
|
||||
```
|
||||
Goal
|
||||
↓
|
||||
Task Decomposition（COO_AGENT）
|
||||
→ 将目标分解为原子任务图
|
||||
↓
|
||||
Task Graph Generation
|
||||
→ 建立 DAG 依赖关系
|
||||
↓
|
||||
Agent Routing（Router）
|
||||
→ 根据能力/评分/负载分配 Agent
|
||||
↓
|
||||
Execution（各执行 Agent）
|
||||
→ CONTENT / BUSINESS / PRODUCT / SERVICE / OPERATIONS
|
||||
↓
|
||||
Aggregation
|
||||
→ 合并多 Agent 输出，去重消歧
|
||||
↓
|
||||
Evaluation（QUALITY_AGENT）
|
||||
→ 五维评分，阈值判定
|
||||
↓
|
||||
Reflection
|
||||
→ 分析成功/失败模式
|
||||
↓
|
||||
Optimization
|
||||
→ 识别瓶颈，提出改进
|
||||
↓
|
||||
Memory Update
|
||||
→ 存入短/长期记忆，更新经验库
|
||||
```
|
||||
|
||||
## Input Contract
|
||||
|
||||
每条指令必须包含：
|
||||
|
||||
| 字段 | 类型 | 说明 |
|
||||
|------|------|------|
|
||||
| goal | string | 核心业务目标 |
|
||||
| context | object | 背景信息 |
|
||||
| constraints | array | 约束条件 |
|
||||
| success_criteria | array | 成功标准 |
|
||||
|
||||
## Output Contract
|
||||
|
||||
每条执行必须返回：
|
||||
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| objective | 执行目标 |
|
||||
| deliverables | 交付物列表 |
|
||||
| execution_report | 执行报告 |
|
||||
| evaluation | 评估结果 |
|
||||
| next_actions | 下一步行动 |
|
||||
@@ -0,0 +1,51 @@
|
||||
# Knowledge Rules — 知识规则库
|
||||
|
||||
## 八大规则文件
|
||||
|
||||
| 文件 | 作用 |
|
||||
|------|------|
|
||||
| execution_rules.md | 任务执行基本规范 |
|
||||
| routing_rules.md | Agent 路由决策表 |
|
||||
| quality_rules.md | 质量评估标准 |
|
||||
| failure_recovery.md | 失败恢复流程 |
|
||||
| optimization_rules.md | 性能优化规则 |
|
||||
| evolution_rules.md | 系统进化约束 |
|
||||
| memory_rules.md | 记忆存储规范 |
|
||||
| governance_rules.md | 治理与安全规则 |
|
||||
|
||||
## 路由决策表
|
||||
|
||||
| 任务能力 | 路由目标 |
|
||||
|----------|----------|
|
||||
| write_blog / produce_podcast | CONTENT_AGENT |
|
||||
| market_research / competitor_analysis | BUSINESS_AGENT |
|
||||
| mvp_design / feature_definition | PRODUCT_AGENT |
|
||||
| answer_customer / support_ticket | SERVICE_AGENT |
|
||||
| task_decomposition / workflow_routing | COO_AGENT |
|
||||
| quality_review / score_task | QUALITY_AGENT |
|
||||
| improve_workflow / optimize_routing | EVOLUTION_AGENT |
|
||||
|
||||
## 失败恢复矩阵
|
||||
|
||||
| 失败类型 | 第一反应 | 第二反应 | 最终升级 |
|
||||
|----------|----------|----------|----------|
|
||||
| 任务失败 | 同 Agent 重试 | 换 Backup Agent | COO_AGENT |
|
||||
| Agent 失败 | 切换 Backup Agent | Checkpoint 回滚 | COO_AGENT |
|
||||
| 工作流失败 | 回滚上一节点 | 重跑失败段 | EVOLUTION_AGENT |
|
||||
| 路由失败 | 记录错误 | COO 干预 | 记录 Pattern |
|
||||
|
||||
## 进化允许/禁止清单
|
||||
|
||||
### 允许（无需审批）
|
||||
- add capability
|
||||
- add workflow
|
||||
- improve routing
|
||||
- improve prompts
|
||||
- add tool access
|
||||
|
||||
### 禁止（不可变更）
|
||||
- delete CEO_AGENT / COO_AGENT
|
||||
- remove evaluation layer
|
||||
- bypass memory layer
|
||||
- modify system contracts
|
||||
- modify governance rules
|
||||
@@ -0,0 +1,36 @@
|
||||
# Workflows — 工作流定义
|
||||
|
||||
## 六个工作流
|
||||
|
||||
### 1. Content Creation（WF_CONTENT_001）
|
||||
内容生产完整流水线：
|
||||
task_decompose → content_strategy → content_generation → quality_review → publish_ready
|
||||
失败：score < 0.8 → 重回 content_generation（最多 2 次）
|
||||
|
||||
### 2. Business Analysis（WF_BUSINESS_001）
|
||||
商业分析系统流程：
|
||||
identify_problem → collect_information → analyze_market → analyze_competitors → evaluate_opportunities → generate_recommendations
|
||||
评估阈值：0.8
|
||||
|
||||
### 3. Product Design（WF_PRODUCT_001）
|
||||
MVP 产品设计流程：
|
||||
requirement_analysis → user_painpoint_analysis → feature_definition → MVP_design → technical_feasibility → product_review
|
||||
质量门：score >= 0.8
|
||||
|
||||
### 4. Customer Service（WF_SERVICE_001）
|
||||
自动客服处理流程：
|
||||
classify_intent → route_request → generate_response → verify_resolution → satisfaction_check
|
||||
无法解决 → 升级至 COO_AGENT
|
||||
|
||||
### 5. Autonomous Project（WF_AUTO_001）
|
||||
完全自主项目执行（核心工作流）：
|
||||
project_decomposition → task_graph_generation → task_routing → task_execution
|
||||
→ aggregation → evaluation → reflection → optimization → memory_update
|
||||
score >= 0.8 → 完成；否则重跑优化循环（最多 3 次）
|
||||
|
||||
### 6. Company Operating Cycle（WF_COMPANY_001）
|
||||
企业完整运营周期：
|
||||
goal_setting → market_analysis → product_planning → content_generation
|
||||
→ customer_acquisition → service_delivery → evaluation → reflection
|
||||
→ optimization → memory_update
|
||||
repeat: true（持续循环）
|
||||
@@ -0,0 +1,28 @@
|
||||
class RuntimeEngine:
|
||||
"""OPC Runtime Enterprise — System Entry Point"""
|
||||
|
||||
def __init__(self):
|
||||
from runtime.core.registry import AgentRegistry
|
||||
from runtime.core.router import Router
|
||||
from runtime.execution.executor import Executor
|
||||
from runtime.evaluation.evaluator import Evaluator
|
||||
from runtime.memory.memory_store import MemoryStore
|
||||
self.registry = AgentRegistry()
|
||||
self.router = Router()
|
||||
self.executor = Executor()
|
||||
self.evaluator = Evaluator()
|
||||
self.memory = MemoryStore()
|
||||
|
||||
def run_workflow(self, workflow):
|
||||
from runtime.workflow.compiler import WorkflowCompiler
|
||||
from runtime.core.scheduler import Scheduler
|
||||
graph = WorkflowCompiler().compile(workflow)
|
||||
scheduler = Scheduler(graph, self.router, self.registry, self.executor)
|
||||
scheduler.run()
|
||||
return graph
|
||||
|
||||
def register_agent(self, agent):
|
||||
self.registry.register(agent)
|
||||
|
||||
def get_memory(self):
|
||||
return self.memory
|
||||
@@ -0,0 +1,12 @@
|
||||
class EventBus:
|
||||
"""Event Bus — Pub/sub communication between components"""
|
||||
|
||||
def __init__(self):
|
||||
self.listeners = {}
|
||||
|
||||
def subscribe(self, event, callback):
|
||||
self.listeners.setdefault(event, []).append(callback)
|
||||
|
||||
def publish(self, event, data):
|
||||
for callback in self.listeners.get(event, []):
|
||||
callback(data)
|
||||
@@ -0,0 +1,14 @@
|
||||
class AgentRegistry:
|
||||
"""Agent Registry — Central agent management"""
|
||||
|
||||
def __init__(self):
|
||||
self._agents = {}
|
||||
|
||||
def register(self, agent):
|
||||
self._agents[agent.name] = agent
|
||||
|
||||
def get(self, name):
|
||||
return self._agents.get(name)
|
||||
|
||||
def all(self):
|
||||
return list(self._agents.values())
|
||||
@@ -0,0 +1,20 @@
|
||||
class Router:
|
||||
"""Task Router — Assign tasks to best-fit agents"""
|
||||
|
||||
def route(self, task, agents):
|
||||
best_agent = None
|
||||
best_score = -1
|
||||
for agent in agents:
|
||||
score = self.calculate_score(task, agent)
|
||||
if score > best_score:
|
||||
best_score = score
|
||||
best_agent = agent
|
||||
return best_agent
|
||||
|
||||
def calculate_score(self, task, agent):
|
||||
score = 0.0
|
||||
task_type = task.context.get("category", "")
|
||||
if task_type in getattr(agent, "capabilities", []):
|
||||
score += 1.0
|
||||
score += getattr(agent, "performance_score", 0.0)
|
||||
return score
|
||||
@@ -0,0 +1,17 @@
|
||||
class Scheduler:
|
||||
"""Task Scheduler — Execute ready tasks in topological order"""
|
||||
|
||||
def __init__(self, graph, router, registry, executor):
|
||||
self.graph = graph
|
||||
self.router = router
|
||||
self.registry = registry
|
||||
self.executor = executor
|
||||
|
||||
def run(self):
|
||||
while True:
|
||||
ready = self.graph.get_ready_tasks()
|
||||
if not ready:
|
||||
break
|
||||
for task in ready:
|
||||
agent = self.router.route(task, self.registry.all())
|
||||
self.executor.execute(task, agent)
|
||||
@@ -0,0 +1,14 @@
|
||||
class Evaluator:
|
||||
"""Quality Evaluator — Score task output"""
|
||||
|
||||
def evaluate(self, task):
|
||||
result = task.result
|
||||
score = 0.0
|
||||
if result:
|
||||
score += 0.4
|
||||
if "summary" in result:
|
||||
score += 0.3
|
||||
if "recommendations" in result:
|
||||
score += 0.3
|
||||
task.score = score
|
||||
return score
|
||||
@@ -0,0 +1,12 @@
|
||||
class Executor:
|
||||
"""Task Executor — Run task with assigned agent"""
|
||||
|
||||
def execute(self, task, agent):
|
||||
try:
|
||||
result = agent.run(task)
|
||||
task.result = result
|
||||
task.status = "completed"
|
||||
except Exception as e:
|
||||
task.status = "failed"
|
||||
task.result = {"error": str(e)}
|
||||
return task
|
||||
@@ -0,0 +1,6 @@
|
||||
from abc import ABC, abstractmethod
|
||||
|
||||
class BaseLLM(ABC):
|
||||
@abstractmethod
|
||||
async def generate(self, prompt: str, system: str = None):
|
||||
pass
|
||||
@@ -0,0 +1,9 @@
|
||||
class LLMRouter:
|
||||
def route(self, task_type: str) -> str:
|
||||
mapping = {
|
||||
"content": "claude",
|
||||
"analysis": "gpt",
|
||||
"coding": "deepseek",
|
||||
"reasoning": "gpt"
|
||||
}
|
||||
return mapping.get(task_type, "gpt")
|
||||
@@ -0,0 +1,17 @@
|
||||
class MemoryStore:
|
||||
"""Memory Store — Execution history and patterns"""
|
||||
|
||||
def __init__(self):
|
||||
self.executions = []
|
||||
|
||||
def save(self, execution):
|
||||
self.executions.append(execution)
|
||||
|
||||
def search(self, keyword):
|
||||
return [e for e in self.executions if keyword in str(e)]
|
||||
|
||||
def get_success_cases(self):
|
||||
return [e for e in self.executions if e.get("score", 0) > 0.8]
|
||||
|
||||
def get_failure_cases(self):
|
||||
return [e for e in self.executions if e.get("score", 0) < 0.5]
|
||||
@@ -0,0 +1,9 @@
|
||||
from abc import ABC, abstractmethod
|
||||
|
||||
class BaseTool(ABC):
|
||||
name: str = ""
|
||||
description: str = ""
|
||||
|
||||
@abstractmethod
|
||||
async def execute(self, **kwargs):
|
||||
pass
|
||||
@@ -0,0 +1,7 @@
|
||||
class ToolExecutor:
|
||||
def __init__(self, registry):
|
||||
self.registry = registry
|
||||
|
||||
async def run(self, tool_name, **kwargs):
|
||||
tool = self.registry.get(tool_name)
|
||||
return await tool.execute(**kwargs) if tool else None
|
||||
@@ -0,0 +1,9 @@
|
||||
class ToolRegistry:
|
||||
def __init__(self):
|
||||
self.tools = {}
|
||||
|
||||
def register(self, tool):
|
||||
self.tools[tool.name] = tool
|
||||
|
||||
def get(self, name):
|
||||
return self.tools.get(name)
|
||||
@@ -0,0 +1,7 @@
|
||||
class WorkflowCompiler:
|
||||
"""Compile workflow definition into executable task graph"""
|
||||
|
||||
def compile(self, workflow):
|
||||
from runtime.workflow.task_graph import TaskGraph
|
||||
graph = TaskGraph()
|
||||
return graph
|
||||
@@ -0,0 +1,17 @@
|
||||
class TaskGraph:
|
||||
"""DAG — Directed Acyclic Task Graph"""
|
||||
|
||||
def __init__(self):
|
||||
self.tasks = {}
|
||||
|
||||
def add_task(self, task):
|
||||
self.tasks[task.id] = task
|
||||
|
||||
def get_ready_tasks(self):
|
||||
ready = []
|
||||
for task in self.tasks.values():
|
||||
if task.status != "pending":
|
||||
continue
|
||||
if all(self.tasks[d].status == "completed" for d in task.dependencies):
|
||||
ready.append(task)
|
||||
return ready
|
||||
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"title": "AgentMessage",
|
||||
"type": "object",
|
||||
"required": [
|
||||
"from",
|
||||
"to",
|
||||
"type",
|
||||
"payload"
|
||||
],
|
||||
"properties": {
|
||||
"from": {
|
||||
"type": "string"
|
||||
},
|
||||
"to": {
|
||||
"type": "string"
|
||||
},
|
||||
"type": {
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"task",
|
||||
"request",
|
||||
"response",
|
||||
"report",
|
||||
"decision"
|
||||
]
|
||||
},
|
||||
"payload": {
|
||||
"type": "object"
|
||||
},
|
||||
"timestamp": {
|
||||
"type": "string"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,32 @@
|
||||
{
|
||||
"title": "AgentProfile",
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"agent_id": {
|
||||
"type": "string"
|
||||
},
|
||||
"name": {
|
||||
"type": "string"
|
||||
},
|
||||
"role": {
|
||||
"type": "string"
|
||||
},
|
||||
"capabilities": {
|
||||
"type": "array"
|
||||
},
|
||||
"tools": {
|
||||
"type": "array"
|
||||
},
|
||||
"performance_score": {
|
||||
"type": "number"
|
||||
},
|
||||
"status": {
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"active",
|
||||
"inactive",
|
||||
"busy"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"title": "Evaluation",
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"score": {
|
||||
"type": "number"
|
||||
},
|
||||
"dimension_scores": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"completeness": {
|
||||
"type": "number"
|
||||
},
|
||||
"accuracy": {
|
||||
"type": "number"
|
||||
},
|
||||
"clarity": {
|
||||
"type": "number"
|
||||
},
|
||||
"business_value": {
|
||||
"type": "number"
|
||||
},
|
||||
"actionability": {
|
||||
"type": "number"
|
||||
}
|
||||
}
|
||||
},
|
||||
"strengths": {
|
||||
"type": "array"
|
||||
},
|
||||
"weaknesses": {
|
||||
"type": "array"
|
||||
},
|
||||
"recommendations": {
|
||||
"type": "array"
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,32 @@
|
||||
{
|
||||
"title": "Execution",
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"execution_id": {
|
||||
"type": "string"
|
||||
},
|
||||
"started_at": {
|
||||
"type": "string"
|
||||
},
|
||||
"finished_at": {
|
||||
"type": "string"
|
||||
},
|
||||
"goal": {
|
||||
"type": "string"
|
||||
},
|
||||
"status": {
|
||||
"type": "string",
|
||||
"enum": [
|
||||
"running",
|
||||
"completed",
|
||||
"failed"
|
||||
]
|
||||
},
|
||||
"tasks": {
|
||||
"type": "array"
|
||||
},
|
||||
"evaluation": {
|
||||
"type": "object"
|
||||
}
|
||||
}
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user