跳转至

MVP 开发计划：企微入口与主动信息收集

核心判断

OrgReOrg 的最小 Demo 不应先做完整平台，而应先跑通一条真实业务闭环：

text 企业微信入口 -> Agentic Search 搜索已有知识 -> 证据不足时生成知识缺口 -> 主动询问相关人员 -> 补充信息挂载到当前任务 -> 人工确认 -> 沉淀到团队知识库

MVC 权限模型仍然重要，但先后置。当前阶段先在小团队内验证流程、数据结构、询问路由和知识沉淀方式。

MVP 优先级

优先级 模块 本阶段目标
P0 企业微信入口 承接个人用户输入、任务通知、主动询问和确认
P0 Agentic Search 搜索 docs/、vault/、GitHub 或最小文档源
P0 主动询问 缺口不足时判断问谁、问什么、如何追踪
P0 知识外挂 补充信息先进入任务上下文和待确认知识卡片
P1 Web 工作台 承接复杂任务、文件、证据和确认动作
P2 MVC 权限模型 在闭环跑通后再实现完整权限化上下文视图

企业微信入口

企业微信在 MVP 中承担四类职责：

  • 输入：用户发起任务、补充资料、回复 Agent 问题。
  • 输出：Agent 推送任务状态、缺口请求、结果摘要。
  • 身份：建立企业微信用户、部门、角色和内部用户之间的映射。
  • 跳转：复杂任务进入 Web 工作台继续处理。

可调研的企业微信官方能力包括自建应用与智能机器人对接、应用消息发送、回调配置、网页授权、成员读取、部门列表和成员 ID 列表。

主动收集流程

主动收集分为两类：

  1. 系统内收集：Agent 先搜索团队知识库、GitHub、文档源和已接入 Connector。
  2. 人员询问：当证据不足、过期、冲突或权限不足时，Agent 主动向相关人请求补充。

人员询问不应群发。第一版 ask_router 可以按这些信号选择 1 到 3 个候选人：

  • 文档 owner、最近编辑者或页面维护人。
  • 项目 owner、issue owner、PR reviewer、最近提交者。
  • GitHub CODEOWNERS。
  • Connector registry 中登记的系统负责人。
  • 企业微信通讯录中的部门负责人或业务接口人。
  • 当前任务、历史任务和群聊上下文中被明确提到的人。

每次主动询问都应说明：

  • 当前任务是什么。
  • 缺少什么信息。
  • 为什么询问这个人。
  • 希望得到什么格式的补充。
  • 该信息是临时使用还是准备进入知识库。

补充信息的沉淀方式

补充信息先不要直接写入正式知识库。第一版按四层处理：

层级 形态 进入条件
临时上下文 当前任务 artifact 只支撑本次任务
待确认材料 vault/00-inbox/ 或 vault/10-raw/ 来源明确但未整理
知识对象 vault/20-wiki/、项目页或 ADR 经 Agent 编译和人工 review
发布内容 docs/ 结构稳定、团队可读、客户安全

最小数据结构可以先叫 knowledge_card：

text task_id source_type question answer responder source_time confidence permission_scope review_status promote_to

开发里程碑

M0：文档和任务拆分

  • 发布本计划。
  • 明确企业微信入口、主动询问、知识卡片和最小审计字段。
  • 用 5 到 10 个真实团队问题做测试集。
  • 提供本地 Demo，在未接入企业微信前先验证搜索、缺口识别、问谁路由和 knowledge card 生成。

本地运行：

bash python scripts/orgreorg_demo.py "客户合同付款状态现在该问谁确认？" --write-card

Demo 使用：

  • docs/ 和 vault/ 作为已收集信息源。
  • vault/90-system/org-directory.json 作为临时组织目录。
  • vault/00-inbox/ 作为 knowledge card 输出入口。

M1：企业微信 POC

  • 建立企业微信自建应用或智能机器人接入方式。
  • 完成身份映射。
  • 实现发送消息和接收用户回复。
  • 从企业微信创建一条任务，并在 Web 工作台显示任务详情。
  • 索引 docs/、vault/ 和 GitHub issue/PR 的最小子集。
  • 建立上下文库 registry，描述每个上下文库的 scope、owner、source、权限、MCP endpoint 和索引名。
  • 实现 Context Router，根据用户、部门、项目、任务和实体选择 1 到 3 个候选上下文库。
  • 定义 ES 文档结构、metadata 字段、chunk 规则、embedding 字段和 ingest pipeline 版本字段。
  • 实现 search、get_document、report_gap。
  • 回答必须带证据来源；证据不足时生成知识缺口。
  • 路由日志要能解释为什么选中某几个上下文库，而不是调用全部 MCP 服务。

M3：主动询问闭环

  • 实现 knowledge_gap 和 ask_router。
  • 通过企业微信向候选人发送结构化问题。
  • 回复进入当前任务，形成 knowledge_card。
  • 负责人确认后，材料进入 vault 编译流程。

M4：最小治理

  • 默认只读。
  • 高风险动作只生成草稿或请求人工确认。
  • 记录任务、工具、询问、回复、来源和 review 状态。
  • 使用 public / team / task_only / restricted 作为最小可见范围。

M5：后续 MVC 权限模型

当真实任务、知识卡片、工具调用和审计记录足够后，再实现完整 MVC：

  • Model：统一知识对象、业务对象、工具结果、索引和审计记录。
  • View：用户、部门、项目、角色和任务上下文视图。
  • Controller：权限判断、上下文裁剪、审批和审计。

验收标准

  • 团队成员能从企业微信发起一个真实问题。
  • Agent 能搜索已有知识并给出证据引用。
  • 搜索不足时，Agent 能说明缺口并选择少数相关人询问。
  • 被询问人能在企业微信回复，回复能回到任务上下文。
  • 补充信息不会未经 review 直接进入正式知识库。
  • 企业微信未接入前，本地 Demo 能完成同样的数据流模拟。
  • Agentic Search 能根据任务路由到不同上下文库，而不是只调用一个全局搜索服务。
  • mkdocs build --strict 通过。

调研依据