memind/docs/memindadm-goose-gateway-design.md

# memindadm 内 Goose 网关策略中心设计

> **定位：** `memindadm` 后台内的一个功能模块，不是独立治理平台，也不是 Plaza 审核后台的一部分。
>
> **目标：** 做一个可配置、可审计、可扩展的 Goose 网关策略中心。
>
> **原则：** 不做大而全的中台，不引入复杂流程编排，先把策略控制、路由分发、审计留痕做扎实。
>
> **边界：** 该模块只做旁路审计和策略决策，不改变现有 Goose 服务的核心行为，不把 Goose 变成被动依赖，也不在第一阶段强制改造现有 Goose 服务链路。它归属 `memindadm` 的用户管理后台，不归属 Plaza 审核后台。
>
> **统一要求：** `Goose / Aider / OpenHands` 的 LLM 配置必须收敛到 `memindadm`，后台只保留一套统一模型配置与执行器绑定，不允许给 Goose 单独再开一套独立 LLM 设置。

## 1. 背景

现有 `memindadm` 后台已经承担了平台管理、能力配置、审计查看等职责。基于这套后台能力，可以新增一个面向 Goose 调用链路的策略模块，用来统一管理：

- 输入内容过滤
- 敏感词与敏感表达屏蔽
- 输出话术约束
- 执行器分配策略
- 高风险操作拦截与人工确认
- 调用审计与复盘

这里的核心不是“再做一个后台”，而是把 Goose 的调用前、调用中、调用后策略，纳入 `memindadm` 统一管理。

### 1.1 非侵入式要求

这一版必须满足两个硬约束：

1. 现有 Goose 服务仍然可以按原方式独立运行。
2. `memindadm` 只在调用入口、审计链路、策略配置层提供旁路能力，不要求 Goose 原服务先完成深度改造。

换句话说：

- 先接策略，不先改服务。
- 先留审计，不先改执行。
- 先做可观察性，不先做强制接管。

如果后续要把 `memindadm` 的策略真正注入到 Goose 执行链路里，再单独做一个可控的接入阶段。

### 1.2 统一模型配置要求

模型配置必须只有一个控制平面：

- `memindadm` 维护 Provider、API Key、Base URL、模型列表、默认模型。
- `Goose`、`Aider`、`OpenHands` 只从 `memindadm` 读取模型绑定。
- 后台不再出现“Goose 单独配置 LLM”的入口。
- 某个执行器如果暂时不用，可以禁用绑定，但不能绕开 `memindadm` 单独配。

迁移期间如果需要，可以先停掉原来的独立 Goose 服务配置，让它完全切到 `memindadm` 的统一配置上。

## 2. 设计目标

这个模块要解决的事情很明确：

1. 当前任务是否允许执行。
2. 输入内容是否包含敏感信息。
3. 输出话术是否符合产品约束。
4. 当前任务应该由 Goose 自处理、Aider 执行，还是 OpenHands 执行。
5. 是否需要人工确认。
6. 执行结果是否需要记录、复核或回滚。
7. `Goose / Aider / OpenHands` 是否使用同一 Provider 下的不同模型绑定。

最终效果是：

- `memindadm` = 策略配置与审计后台
- `memindadm` = 统一模型与策略控制台
- Goose Gateway = 策略执行入口
- Aider / OpenHands = 具体执行器
- Audit Log = 全链路留痕

## 3. 总体架构

```mermaid
flowchart TD
  U["用户 / 前端 / 管理员"] --> A["memindadm 后台"]
  A --> P["Goose 网关策略中心"]
  P --> G["Goose Gateway"]
  G --> E["策略判断引擎"]
  E --> F["内容过滤规则"]
  E --> S["话术约束规则"]
  E --> R["执行器分配规则"]
  E --> H["高风险操作规则"]
  E --> M["人工确认规则"]
  E --> X["执行器路由"]
  X --> G1["Goose 自处理"]
  X --> G2["Aider 执行"]
  X --> G3["OpenHands 执行"]
  G1 --> L["结果 / Diff / 审计日志"]
  G2 --> L
  G3 --> L
  L --> A
```

### 架构解读

- `memindadm` 负责配置和查看，不直接承担执行。
- Goose Gateway 是统一入口，所有 Goose 相关调用都从这里经过。
- 策略判断引擎先做规则匹配，再决定是否执行、交给谁执行、是否要人工确认。
- 执行结果回流到 `memindadm` 审计中心。

## 4. 菜单结构

建议在 `memindadm` 下新增一个一级菜单：

- `Goose 网关`

下面放 5 个子菜单即可，保持克制：

1. 内容过滤
2. 敏感词
3. 话术约束
4. 执行策略
5. 调用日志

同时建议保留或升级原有 `LLM 配置` 页面为 `统一模型中心`，专门管理：

- Provider
- API Key
- Base URL
- 模型列表
- 默认模型
- 执行器绑定

这个页面要同时服务 `Goose / Aider / OpenHands`，不是只给 Goose 用。

如果后续确实需要，再补：

- 风险规则
- 人工确认
- 策略测试

第一版不建议拆太多页，避免后台变复杂。

## 5. 核心模块

### 5.1 内容过滤规则

内容过滤用于处理三类文本：

- `input`：用户输入
- `prompt`：发给 Goose / Aider / OpenHands 的任务内容
- `output`：最终返回给用户的内容

推荐支持的匹配方式：

- 关键词匹配
- 正则表达式匹配
- 敏感字段检测
- 文件路径检测
- 高危命令检测
- 代码操作风险检测

推荐动作：

- `pass`：允许通过
- `mask`：脱敏替换
- `block`：阻断执行
- `confirm`：需要人工确认
- `log_only`：只记录不拦截

示例：

```yaml
rule_id: filter_001
name: 禁止输出密钥
target: output
type: regex
pattern: "(sk-[a-zA-Z0-9]{20,}|AKIA[0-9A-Z]{16})"
action: mask
replacement: "[已屏蔽密钥]"
level: high
enabled: true
```

### 5.2 敏感词管理

敏感词不建议只做单一词库，最好分层：

- 基础敏感词：明确禁止出现的词
- 业务敏感词：项目、客户、合同、价格、内部系统等
- 技术敏感词：密钥、Token、数据库连接串、服务器地址、生产账号等

对于技术类内容，不建议一律 `block`。更合理的策略是：

- 普通讨论：允许
- 包含真实值：脱敏
- 涉及生产操作：人工确认
- 要求输出密钥：阻断

### 5.3 话术约束

话术约束主要用于控制 Goose 的表达方式，避免输出不符合产品定位的内容。

建议分三类：

1. 固定禁止话术
2. 固定推荐话术
3. 场景化话术模板

示例模板：

```yaml
scene: coding_task_result
name: 编码任务完成话术
template:
  - 执行器：{executor}
  - 修改范围：{changed_files}
  - 测试结果：{test_result}
  - 风险提示：{risk_summary}
  - 下一步建议：{next_action}
```

### 5.4 执行器分配策略

执行器建议分成 5 类：

- `goose`：分析、设计、轻量编排
- `aider`：小范围代码修改、补丁式修复
- `openhands`：复杂开发任务、多文件改造、仓库探索、命令执行
- `manual`：需要人工确认
- `reject`：拒绝执行

建议第一阶段使用规则引擎，不做复杂模型决策。

示例策略：

```yaml
policy_id: route_001
name: 小范围代码修改走 Aider
conditions:
  task_type: code_change
  max_files: 3
  requires_browser: false
  requires_long_running_env: false
  risk_level: low
executor: aider
priority: 100
enabled: true
---
policy_id: route_002
name: 复杂仓库任务走 OpenHands
conditions:
  task_type:
    - feature_dev
    - bug_fix_complex
    - repo_refactor
  min_files: 4
  requires_command_execution: true
executor: openhands
priority: 90
enabled: true
---
policy_id: route_003
name: 只分析不改代码走 Goose
conditions:
  task_type:
    - architecture_design
    - code_review
    - requirement_analysis
  write_permission_required: false
executor: goose
priority: 80
enabled: true
---
policy_id: route_004
name: 高风险操作需要人工确认
conditions:
  risk_keywords:
    - 删除数据库
    - 生产环境
    - 支付接口
    - 权限系统
    - 用户数据
  risk_level: high
executor: manual
priority: 200
enabled: true
```

优先级原则：

- 高风险规则优先
- 阻断规则优先
- 人工确认优先
- 明确执行器规则优先
- 默认 Goose 自处理

### 5.5 任务识别器

Goose Gateway 在执行前需要先把用户任务识别成结构化结果。

示例：

```json
{
  "task_type": "feature_dev",
  "risk_level": "medium",
  "requires_code_change": true,
  "requires_command_execution": true,
  "estimated_files": 5,
  "requires_browser": false,
  "target_repo": "memind-h5",
  "suggested_executor": "openhands"
}
```

推荐流程：

1. 用户输入
2. LLM 初步识别任务类型
3. 规则引擎二次校验
4. 匹配执行器策略
5. 生成执行计划

### 5.6 高风险操作控制

高风险类型建议内置：

- 生产数据库操作
- 删除文件或目录
- 批量修改用户数据
- 支付、充值、订单相关逻辑
- 权限、登录、Token、密钥相关逻辑
- 服务器部署、重启、停止服务
- 对外发送消息、邮件、公众号发布

这些动作统一进入人工确认：

```text
confirm_required = true
```

确认内容应包含：

- 任务说明
- 执行器
- 目标仓库
- 计划修改文件
- 预计执行命令
- 风险点
- 回滚建议

## 6. 调用流程

### 6.1 普通任务

```text
用户提交任务
  ↓
Goose Gateway 接收
  ↓
内容过滤
  ↓
任务识别
  ↓
执行器策略匹配
  ↓
调用 Aider / OpenHands / Goose
  ↓
结果过滤
  ↓
话术约束
  ↓
返回用户
  ↓
写入审计日志
```

### 6.2 高风险任务

```text
用户提交任务
  ↓
内容过滤
  ↓
命中高风险规则
  ↓
生成执行计划
  ↓
进入人工确认
  ↓
管理员确认
  ↓
执行器执行
  ↓
结果审计
  ↓
返回用户
```

## 7. 审计日志

每一次调用都必须记录。

建议字段：

- `request_id`
- `user_id`
- 原始输入
- 过滤结果
- 命中规则
- 任务类型
- 风险等级
- 选择的执行器
- 执行参数
- 执行日志
- 修改文件
- diff 摘要
- 测试结果
- 最终输出
- 创建时间
- 完成时间
- 执行状态

审计日志第一阶段可以先不做复杂可视化，但数据库结构要先预留。

## 8. 表结构建议

### `goose_policy_rule`

- `id`
- `rule_name`
- `rule_type`
- `target`
- `match_type`
- `pattern`
- `action`
- `risk_level`
- `priority`
- `enabled`
- `created_at`
- `updated_at`

### `goose_sensitive_word`

- `id`
- `group_name`
- `word`
- `scope`
- `action`
- `enabled`
- `created_at`
- `updated_at`

### `goose_route_policy`

- `id`
- `policy_name`
- `task_type`
- `conditions_json`
- `executor`
- `priority`
- `enabled`
- `created_at`
- `updated_at`

### `goose_execution_log`

- `id`
- `request_id`
- `user_id`
- `task_type`
- `risk_level`
- `executor`
- `input_text`
- `filtered_input`
- `matched_rules_json`
- `execution_status`
- `execution_summary`
- `diff_summary`
- `test_result`
- `llm_provider`
- `llm_model`
- `created_at`
- `finished_at`

### `goose_manual_confirm`

- `id`
- `request_id`
- `confirm_type`
- `risk_summary`
- `planned_action`
- `status`
- `operator_id`
- `confirmed_at`
- `created_at`

## 9. `memindadm` 后台页面建议

### 9.1 内容过滤规则页

字段：

- 规则名称
- 检测对象
- 匹配方式
- 关键词 / 正则
- 处理动作
- 风险等级
- 是否启用
- 优先级

### 9.2 敏感词管理页

字段：

- 词库分组
- 敏感词
- 作用范围
- 处理动作
- 是否启用

### 9.3 话术约束页

字段：

- 场景
- 禁止话术
- 推荐话术
- 输出模板
- 是否启用

### 9.4 执行器分配策略页

字段：

- 策略名称
- 任务类型
- 条件配置
- 目标执行器
- 风险等级
- 优先级
- 是否启用

### 9.5 调用日志页

字段：

- 请求时间
- 用户
- 任务类型
- 命中规则
- 执行器
- 风险等级
- 执行状态
- 详情查看

## 10. MVP 范围

第一阶段只做小而精，不做复杂流程引擎。

### 必须做

1. 内容过滤规则配置
2. 敏感词配置
3. 执行器分配策略配置
4. Goose 调用前策略判断
5. Aider / OpenHands 路由选择
6. 调用审计日志
7. 统一模型中心

### 可以暂缓

1. 多级审批
2. 复杂权限矩阵
3. 策略版本管理
4. 复杂可视化编排
5. 自动回滚
6. 多租户策略隔离

## 11. 推荐落地顺序

### 第一步：先做表和日志

先把规则、敏感词、执行器策略、日志表建起来。

### 第二步：做 Goose Gateway 策略判断

在 Goose 调用前增加统一入口：

```text
before_execute(task)
```

负责：

- 过滤输入
- 识别任务
- 判断风险
- 选择执行器
- 生成执行计划

### 第三步：接入 Aider

先支持小范围代码任务走 Aider，因为调用简单、成本低、见效快。

### 第四步：接入 OpenHands

再把复杂任务转给 OpenHands，让它负责仓库探索、多文件开发和命令执行。

### 第五步：把 Goose 也切到统一模型中心

Goose 不再使用单独的模型配置页面，而是直接读取 `memindadm` 的统一模型中心。必要时可以先停掉原来独立的 Goose LLM 配置，保证入口只有一个。

### 第六步：做 `memindadm` 后台页面

先做简单 CRUD，不追求复杂交互。

## 12. 预期效果

完成后，`memindadm` 会具备一套轻量级 Goose 网关治理能力：

- 可配置内容过滤
- 可配置敏感词屏蔽
- 可配置话术约束
- 可配置执行器路由
- 可拦截高风险操作
- 可审计每次调用过程

这样 Goose 不再只是单一 Agent，而是变成一个可以统一调度 Aider、OpenHands、Claude Code 等工具的策略入口。

## 13. 最终定位

- `memindadm` = 用户与策略后台
- `Goose Gateway` = Agent 编排入口
- `Aider` = 小型代码修改执行器
- `OpenHands` = 复杂代码任务执行器
- `Goose` = 策略与分析执行器，模型同样来自统一模型中心
- `Policy Center` = 安全与路由规则中心
- `Audit Log` = 行为留痕与复盘中心

第一版建议在产品命名上保持克制，后台菜单直接叫：

- `Goose 网关`

只放这 5 个子菜单：

1. 内容过滤
2. 敏感词
3. 话术约束
4. 执行策略
5. 调用日志

这样产品上小，架构上完整，后续可以自然扩展。