Files

T

john 9b4a25799f Add smart ACK provider for WeChat MP replies

Replace fixed ackText with a rule-based AckProvider that picks
response templates by message type and intent (translate, summary,
rewrite, poster, ppt, mindmap, code, search, schedule). Pure sync,
zero I/O, auto-falls back to config.ackText on any error.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-06-26 15:19:03 +08:00

14 KiB

Raw Blame History

memindadm 内 Goose 网关策略中心设计

定位： memindadm 后台内的一个功能模块，不是独立治理平台，也不是 Plaza 审核后台的一部分。

目标： 做一个可配置、可审计、可扩展的 Goose 网关策略中心。

原则： 不做大而全的中台，不引入复杂流程编排，先把策略控制、路由分发、审计留痕做扎实。

边界： 该模块只做旁路审计和策略决策，不改变现有 Goose 服务的核心行为，不把 Goose 变成被动依赖，也不在第一阶段强制改造现有 Goose 服务链路。它归属 memindadm 的用户管理后台，不归属 Plaza 审核后台。

统一要求： Goose / Aider / OpenHands 的 LLM 配置必须收敛到 memindadm，后台只保留一套统一模型配置与执行器绑定，不允许给 Goose 单独再开一套独立 LLM 设置。

1. 背景

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

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

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

1.1 非侵入式要求

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

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

换句话说：

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

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

1.2 统一模型配置要求

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

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

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

2. 设计目标

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

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

最终效果是：

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

3. 总体架构

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 个子菜单即可，保持克制：

内容过滤
敏感词
话术约束
执行策略
调用日志

同时建议保留或升级原有 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：只记录不拦截

示例：

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 的表达方式，避免输出不符合产品定位的内容。

建议分三类：

固定禁止话术
固定推荐话术
场景化话术模板

示例模板：

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

5.4 执行器分配策略

执行器建议分成 5 类：

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

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

示例策略：

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 在执行前需要先把用户任务识别成结构化结果。

示例：

{
  "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"
}

推荐流程：

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

5.6 高风险操作控制

高风险类型建议内置：

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

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

confirm_required = true

确认内容应包含：

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

6. 调用流程

6.1 普通任务

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

6.2 高风险任务

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

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 范围

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

必须做

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

可以暂缓

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

11. 推荐落地顺序

第一步：先做表和日志

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

第二步：做 Goose Gateway 策略判断

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

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 个子菜单：

内容过滤
敏感词
话术约束
执行策略
调用日志

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

14 KiB Raw Blame History