跳转至

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

「路线与落地」怎么读：项目状态 看现在到哪了；本页是 P0 执行计划；OrgReOrg 近期路线图 看近期阶段；长期路线图 看远期定位；从内部实践到外部方案商 看对外交付方向。最高风险与验证计划见 风险驱动验证计划。

核心判断

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

企业微信入口
  -> Evidence capture 保留原始上下文
  -> Ontology build 抽取对象、关系、规则、制品和 Skill
  -> Runtime Projection 组合最小充分上下文
  -> Agentic Search / Connector / Skill 执行
  -> 证据不足时生成知识缺口
  -> 主动询问相关人员
  -> 补充信息挂载到当前任务
  -> 人工确认
  -> 沉淀到团队知识库

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

从 Framework 视角看，MVP 不是单条聊天流程，而是 Loop Engineering 的产品化：每个任务都要有 goal、state、action、verifier、memory、governance、budget、audit 和 handoff。企业微信只是入口和通知 adapter；Framework 要负责 loop contract、上下文装载、动作边界、验证信号、持久化状态和下一步决策。

MVP 优先级

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

当前协作分工：企业微信接口由团队协作者推进；ALPC91 侧优先负责 P0 中的 Agentic Search、主动询问、知识外挂、知识库组织和验证实验。P1/P2 暂不进入当前开发主线。

P0 研发方式采用“研用测一体”：研究外部方案和团队讨论，立即沉淀到 Knowledge/Site；用本仓库真实执行知识入库、检索和发布流程；用 benchmark、lint、build 和 review 验证效果与成本。

企业微信入口

企业微信在 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 中登记的系统负责人。
  • 企业微信通讯录中的部门负责人或业务接口人。
  • 当前任务、历史任务和群聊上下文中被明确提到的人。

每次主动询问都应说明：

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

补充信息的沉淀方式

补充信息先不要直接写入正式知识库。第一版按 Evidence / Ontology / Runtime Projection 处理：

阶段 形态 进入条件
Evidence 当前任务 artifact、workspaces/variai/evidence/inbox/、workspaces/variai/evidence/raw/、source snapshot、evidence-registry.json 来源明确、保真保存、hash 匹配、权限和 provenance 可追溯
Ontology artifact knowledge card、Markdown wiki、项目页、ADR、实验报告、Skill 经 Agent 编译、结构化和人工 review
Runtime projection SearchConnector document、rank log、Tool Gateway safe output、任务上下文包 按用户、任务和权限临时组合
Published view workspaces/variai/site/、项目进度页、实验索引 结构稳定、团队可读、客户安全

当前已新增 Evidence Registry：workspaces/variai/evidence/registry/evidence-registry.json 和 scripts/evidence_registry_lint.py。它会校验 source snapshot 是否存在、sha256 是否匹配、临时外链是否已封口、task_only / restricted 材料是否带 PII 或 field mask，以及下游 artifact 是否能追溯。

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

task_id
source_type
question
answer
responder
source_time
confidence
permission_scope
review_status
promote_to

开发里程碑

M0：文档和任务拆分

  • 发布本计划。
  • 明确企业微信入口、主动询问、知识卡片和最小审计字段。
  • 用 5 到 10 个真实团队问题做测试集。
  • 提供本地 Demo，在未接入企业微信前先验证搜索、缺口识别、问谁路由和 knowledge card 生成。
  • 定义第一批轻量任务技能包候选：harness_knowledge_ingest、harness_site_publish、agentic_search_benchmark、ask_router_review、project_status_dashboard。

本地运行：

python scripts/orgreorg_demo.py "客户合同付款状态现在该问谁确认？" --write-card
python scripts/orgreorg_demo.py "继续沉淀这条链接，进入团队知识库。" --json --record-usage

Demo 使用：

  • workspaces/variai/site/ 和 workspaces/variai/knowledge/ 作为已收集信息源。
  • workspaces/variai/knowledge/system/org-directory.json 作为临时组织目录。
  • workspaces/variai/evidence/inbox/ 作为 knowledge card 输出入口。
  • workspaces/variai/registry/task-skill-usage-log.json 作为任务技能包触发日志。

M1：企业微信 POC

  • 建立企业微信自建应用或智能机器人接入方式。
  • 完成身份映射。
  • 实现发送消息和接收用户回复。
  • 从企业微信创建一条任务，并在 Web 工作台显示任务详情。
  • 索引 workspaces/variai/site/、workspaces/variai/knowledge/ 和 GitHub issue/PR 的最小子集。
  • 建立上下文库 registry，描述每个上下文库的 scope、owner、source、权限、MCP/HTTP endpoint、freshness SLA 和检索投影索引名。
  • 实现 Context Router，根据用户、部门、项目、任务和实体选择 1 到 3 个候选上下文库。
  • 定义 Evidence / Ontology / ContextDocument 映射：metadata 字段、chunk 规则、embedding 字段、ingest pipeline 版本、lifecycle、review_status、supersedes、permission_scope 和 provenance。
  • Evidence Registry 已作为 source snapshot / hash / PII hint / downstream artifact 的 P0 机器契约；下一步把 ingestion samples 和 Connector callback 先写入 Evidence Registry，再投影到 ContextDocument。
  • 选型基线已更新：P0 默认采用 Markdown 渐进披露 + Postgres FTS/pgvector；OpenSearch/Elasticsearch 保留为规模化 adapter；纯向量库不作为核心默认方案。
  • 实现 search、get_document、report_gap，并把 Search Connector 放在 Tool Gateway 后面。
  • 回答必须带证据来源；证据不足时生成知识缺口。
  • 路由日志要能解释为什么选中某几个上下文库，而不是调用全部 MCP 服务。

当前已完成 agentic_search_option_benchmark 第一轮：P0 profile winner 为 tiered_markdown_postgres，scale profile winner 为 tiered_markdown_opensearch，Ontology authoring profile winner 为 markdown_progressive_only。SearchConnector contract、ContextDocumentRecord schema 和 adapter conformance test 已落地；下一步做 Postgres FTS/pgvector 与 OpenSearch/ES 的真实检索投影 adapter 对照，并复用同一 conformance。

当前已完成 task_skill_package_eval 第一轮：progressive_manifest_guarded 在 9 个合成任务上 Precision、Recall、Exact Match、Safe Activation 均为 100%，平均上下文 token 为 766.7；all-in 方案平均 14020.0 token，并暴露过期包和不安全包。当前已实体化 harness_knowledge_ingest、agentic_search_benchmark、project_status_dashboard、ask_router_review 四个最小任务包，新增 manifest lint、task_skill_usage_log 和本地 task_skill_runtime，并已接入本地 orgreorg_demo；下一步接入线上 Agent / 企微 / Web runtime，并继续把 usage log 中的误触发/漏触发样例反写到 eval fixture。

同时引入 agentic_search_benchmark 任务技能包，把 fixture、指标、rank log、成本记录、失败样例和运行命令收敛成可复跑单元。它不替代检索实现，只让实验过程稳定、可 review、可复用。

M3：主动询问闭环

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

当前已完成 ask_router_simulation 第一轮：9 个合成场景 Top1、Recall@3、安全路由、负反馈、节流和消息契约均为 100%，重复询问抑制数 1。本地 knowledge_card 已新增 --reply-text，可先解析企微式结构化回复文本并写回 pending card。下一步在接企微前继续增加真实团队问题集和问错人反馈。

主动询问已经沉淀为 ask_router_review 任务技能包：每次发问前检查候选人、问题清晰度、使用范围、节流策略和 knowledge card 提升路径。当前本地 runtime 已能在 ask_router_review 任务中选中该包，并把一次真实研用测事件写入 usage log。

当前新增本地 knowledge_card 生命周期 workflow：在企业微信回复入口未接入前，orgreorg_demo 可通过 --reply-card 模拟被询问人回复，通过 --reply-text 解析结构化回调文本，通过 --review-card 记录人工 review，通过 --promote-card 将 reviewed 卡片提升到 workspaces/variai/knowledge/wiki/、workspaces/variai/knowledge/projects/ 或 workspaces/variai/site/，再通过 --context-document-card 投影为 ContextDocumentRecord。--reindex-cards / --search-card-index 已切到 KnowledgeCardToolGateway：search 复用 context.search 的 SearchConnector Tool Gateway，reindex 被视为治理动作。未 review、未 promote、被 reject、needs_changes 或越界路径都不能提升、投影或进入索引。

当前新增 No-WeCom MVP Demo：在没有企微 adapter 时，用本地事件跑通用户问题、搜索、gap、初始询问、问错人反馈、改路由、回复、review、promote、reindex 和 Tool Gateway 查询，作为端到端 loop smoke test；并加入 pending、rejected、needs_changes、expired、restricted 五类治理反例，验证未确认/拒绝/待修改/过期卡片不进索引，restricted 卡片不向 team 用户泄漏。

M4：最小治理

  • 默认只读。
  • 高风险动作只生成草稿或请求人工确认。
  • 记录任务、工具、询问、回复、来源和 review 状态。
  • 使用 public / team / task_only / restricted 作为最小可见范围。
  • 新增 Tool Gateway：MCP server 不能被 Agent 直接自由调用，必须经过身份、scope、allowlist、schema hash、审批、审计和输出净化。
  • Zenoh 不作为 MVP 主线依赖；第一阶段使用 JSON / Postgres registry + HTTP/gRPC，后续按服务发现、审计事件回放、边缘 queryable 等需要分别评估 NATS、Kafka / Redpanda 或 Zenoh。

当前已完成 tool_gateway_safety_harness 第一轮：9 个合成 case 全部通过，覆盖 allowlist、schema hash、scope、R4 approval、R3 draft-only、URL egress、输出脱敏和审计不泄密。随后完成 SearchConnector Tool Gateway 第一轮：context.search、context.get_document、context.report_gap 已进入 Tool Gateway 调用路径，6 个 conformance cases 全部通过，并支持 person:*、dept:*、project:* namespaced scopes。当前又完成 Knowledge Card Tool Gateway 第六轮：reviewed/promoted card 的 reindex/search、本地 reindex queue、OntologyToolGateway gate 和 ontology registry lifecycle 进入验收，14 个 conformance cases 全部通过，search/reindex/queue/registry safe output 不泄露对象 ID、owner、source_uri、路径、rank_log 存在性计数、错误路径或内容 marker，且 queue processing 缺少 ontology required_scopes 时不会运行 worker。Ontology Tool Gateway Conformance 扩展到 10/10，route_ask_request_guarded 已让 personal、department、project 三类 Ask Router route 先过 ontology action policy，并把对应对象状态写入 registry；No-WeCom MVP Demo 当前记录 ask_registry_event_count=2、knowledge_card_registry_event_count=6、reindex_queue_registry_event_count=8。下一步把后续企微 connector 包到 Tool Gateway 调用路径后面，并扩展 registry 事件、worker retry 事件和真实增量 adapter 状态的泄漏检查。

M5：后续 MVC 权限模型

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

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

验收标准

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

调研依据