主动信息收集机制

核心口径

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

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

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

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

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

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

更准确的表达是：

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

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

触发条件

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

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

收集流程

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

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

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

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

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

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

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

部门和系统识别

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

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

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

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

请求授权的最小模板

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

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

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

补充信息如何外挂

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

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

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

与企业微信/飞书的关系

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

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

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

收集结果的质量门槛

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

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

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

MVP 顺序

当前 MVP 先跑通：

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

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