主动信息收集机制

核心口径

企业微信和飞书是人与 Agent 交互的统一入口，但不是组织信息的完整来源。

真实业务信息分散在各部门自己的系统里：

• 研发：GitHub、Issue、PR、CI、技术文档、监控和事故记录。
• 财务：财务系统、报销、预算、合同、发票、付款和回款。
• 销售：CRM、商机、客户沟通、合同、回款和客户成功记录。
• 产品：需求池、Roadmap、原型、用户反馈和发布计划。
• 运营：数据看板、工单、活动后台、社群和内容后台。
• 管理：组织架构、制度、审批、会议纪要和决策记录。

Agent 必须从企业微信、飞书或 Web 工作台这个统一入口出发，主动询问、请求授权、接入对应业务系统，才能把分散在各部门系统里的信息转化为组织私域知识能力。

主动收集不是以个人记忆为主

主动收集可以向员工确认经验、判断和例外情况，但重点不是把信息来源描述为主要来自个人记忆。

更准确的表达是：

组织信息主要沉淀在部门业务系统、文档、流程和交易记录中；人的经验用于解释上下文、确认规则、补足例外，而不是替代系统数据源。

这一区分很重要。OrgReOrg 要建设的是组织级信息基础设施，不是依赖临时访谈的知识整理工具。

触发条件

主动收集由以下事件触发：

• 用户提出问题，但 Agentic Search 找不到足够证据。
• Workflow 执行时发现缺少系统授权、文件、负责人或业务字段。
• 连接器返回“权限不足”“对象不存在”“数据过期”。
• 多个系统中的信息互相冲突。
• 新项目、新客户、新制度或新流程出现，但知识库没有记录。
• 审计或评测发现 Agent 回答缺少可靠来源。

收集流程

1. 识别缺口
   Agent 标记缺少什么信息、影响哪个任务、需要哪个系统。

2. 识别来源
   判断信息可能位于哪个部门、系统、项目或负责人处。

3. 请求授权或资料
   通过企业微信、飞书或 Web 工作台向负责人发起请求。

4. 接入系统或导入资料
   优先接入业务系统 Connector，其次导入文件或链接。

5. 解析与索引
   将数据转为可检索、可引用、可权限控制的知识对象。

6. 验证
   抽样搜索、引用原始记录、让负责人确认关键字段。

7. 持久化
   写入知识库、索引、审计日志和维护任务。

部门和系统识别

Agent 收集前应先生成一份信息源判断：

问题类型	优先系统	可能负责人	收集动作
代码和研发进展	GitHub / Issue / CI	研发负责人 / repo owner	请求 repo 权限或 issue 链接
报销和预算	财务系统 / OA	财务负责人	请求只读查询或导出字段
商机和客户状态	CRM	销售负责人 / 客户成功	请求商机视图或客户记录
需求和 Roadmap	产品管理系统	产品负责人	请求需求池、优先级、版本计划
运营数据	BI / 工单 / 活动后台	运营负责人	请求指标口径和看板权限
制度和流程	文档系统 / OA	行政 / HR / 法务	请求制度原文和更新时间

问谁：主动询问路由

主动询问的难点不是“能发消息”，而是判断应该问谁、问什么、问到什么程度。

第一版不应群发。Agent 应从上下文中选择 1 到 3 个候选人，并说明选择原因。候选人来源包括：

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

候选人排序可以先采用简单打分：

score = 相关度 + owner 匹配 + 最近活跃 + 权限匹配 + 历史回答质量 - 打扰成本

MVP 阶段先用规则和日志验证这个排序是否有效，后续再引入学习型路由。

第一轮 ask_router_simulation 的修正结论：

• 当前提问人只做兜底，不参与常规 owner 排名。
• not_owner、busy、wrong_team 这类负反馈要直接影响下一轮候选，not_owner 本轮硬排除。
• 候选人不能只靠泛化 token overlap 入选，至少需要领域、职责短语、证据路径或正反馈等强信号。
• Top3 不能机械填满；使用相对分数阈值过滤弱相关候选，宁可少问，也不要顺手多问。
• 同一 owner、同一任务、同一缺口在冷却窗口内已问过时，本轮不重复询问，也不改问 requester 绕过节流。
• 回复中的 better_owner 或“不是我负责”要转成 AskFeedbackEvent，并在下一轮通过 apply_feedback_events 更新 feedback 和建议 owner，而不是只留在聊天记录里。

详见：Ask Router Simulation：主动询问路由仿真。

当前 Context Management Eval 已把 gap 后的最小主动询问 contract 下沉为 framework/workflows/ask_router.py 的 route_ask_request：输入是 task、question、missing information、suggested owners、evidence paths、use scope、recent ask events 和 cooldown；输出是结构化 ask message、候选 owner、trace log，以及 review_status=pending 的 knowledge card。企微接入后应替换发送和回调 adapter，而不是重新定义消息、卡片或 trace 字段。

问错人反馈目前也已下沉为本地 contract：ask_feedback_event_from_reply 从回复文本和 better_owner 字段生成 AskFeedbackEvent，apply_feedback_events 将该事件应用到下一次 AskRouteRequest。真实企微回调后续只需要提供被问 owner、task_id、缺口、回复正文和解析出的 better owner。

无企微 MVP 中，orgreorg_demo --feedback-log workspaces/variai/registry/ask-feedback-events.json 用本地 JSON 事件流模拟真实消息回调；--ask-feedback-log 则把这些反馈事件重新加载进下一次路由。后续企微 adapter 应替换事件来源，而不是替换 Ask Router 的反馈语义。

请求授权的最小模板

主动收集请求应该可审计、可拒绝、可限时。

任务：需要回答或执行什么
缺口：当前缺少哪些信息
建议来源：哪个系统、项目、文档或对象
请求权限：只读 / 写入草稿 / 高风险动作
使用范围：本次任务 / 项目 / 部门知识库
保留周期：临时上下文 / 长期索引
审计记录：请求人、授权人、时间、范围

默认优先请求只读权限。写入、删除、外发、付款、合并代码等动作必须走人工确认。

补充信息如何外挂

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

层级	形态	用途
临时上下文	当前任务 artifact	只服务本次任务
待确认材料	workspaces/variai/evidence/inbox/ 或 workspaces/variai/evidence/raw/	保留来源和上下文，等待整理
知识对象	workspaces/variai/knowledge/wiki/、项目页或决策记录	经 Agent 编译和人工 review 后复用
发布内容	workspaces/variai/site/	对团队可读、结构稳定、客户安全

最小数据结构可以先叫 knowledge_card，包含任务、问题、回答、回答人、来源时间、可信度、可见范围、review 状态和提升目标。

当前本地 MVP 已把 knowledge card 生命周期做成可复跑 workflow：orgreorg_demo --reply-card 模拟被询问人回复，--reply-text 解析结构化企微式回调文本，--review-card 记录人工 review，--promote-card 只提升 reviewed 卡片，--context-document-card 将 promoted card 投影到 ContextDocumentRecord，--enqueue-reindex-card / --process-reindex-queue 先用本地 JSON queue 模拟增量 reindex，--reindex-cards / --search-card-index 通过 Knowledge Card Tool Gateway 进入本地 SQLite FTS SearchConnector 检索路径。详细流程见 Knowledge Card Review 闭环。

Context Management Eval 中的 pending knowledge card 是这个生命周期的上游入口：它还没有真实回答，但已经固定了任务、缺口、owner、证据路径、使用范围和 review 状态。当前 append_parsed_reply_to_card 已先把回复解析 contract 固定下来，后续真实企微回调应进入同一条 review / promote / reindex 链路。

与企业微信/飞书的关系

企业微信和飞书在主动收集中承担三类角色：

• 入口：员工用自然语言发起问题或任务。
• 通知：Agent 请求资料、授权、确认、审批或澄清。
• 身份：映射组织架构、部门、角色和负责人。

它们不应承担全部数据源职责。聊天记录可以作为线索和上下文，但不能替代 GitHub、财务系统、CRM、项目管理系统、文档系统、BI 等正式业务系统。

收集结果的质量门槛

进入正式知识库或搜索索引前，需要满足：

• 来源明确。
• 权限范围明确。
• 更新时间明确。
• 可引用原始对象。
• 敏感字段已标记或脱敏。
• 负责人或系统 owner 可追溯。
• 后续更新机制明确。

不满足这些条件的材料可以进入 workspaces/variai/evidence/inbox/ 或临时任务上下文，但不应作为长期可信知识直接发布。

MVP 顺序

当前 MVP 先跑通：

1. 企业微信入口。
2. 私域搜索。
3. 缺口识别。
4. 主动询问。
5. knowledge_card 外挂。
6. 人工确认后进入 vault。

完整 MVC 权限模型后置，等真实任务、知识卡片、工具调用和审计记录足够后再实现。