跳转至

研发进度总览

更新日期：2026-06-19

这页是团队成员进入网站后看项目状态的总入口。它回答四个问题：

  • 当前项目处在什么阶段。
  • MVP 预期要跑通什么状态。
  • 已经完成了哪些设计、实验和决策。
  • 每个实验结论和后续任务应该从哪里继续读。

1. 项目总览

快速理解项目定位、当前阶段、P0 主链路、核心共识、高层缺口、最近日报和当前执行队列。

展开：1. 项目总览

1.1 项目定位

当前 repo 同时也是未来产品形态的最小 Demo：一个团队、项目组、部门或公司可以拥有类似的 Agentic Context Management Workspace，用来承载状态看板、知识库、决策、实验报告、任务技能包、测试、权限视图和发布网站。

1.2 当前阶段

OrgReOrg / Harness 当前处在 P0 本地闭环与风险验证阶段。

P0 是当前最高优先级的最小核心闭环，不等于最终完整产品；这一阶段优先验证主链路和关键风险。

1.3 P0 主链路

P0 MVP 要先跑通这一条链：

用户从企业微信聊天、显式知识提交、上传文件、企微云盘/团队文件空间、会议、业务系统或本地 Demo 提出任务
  -> Evidence capture 保留原始聊天、上传文件、云盘/文件空间 metadata、文档、链接、代码、会议材料或业务对象
  -> Ontology build 抽取 metadata、object、relationship、rule、artifact、skill 和 writeback
  -> Runtime Projection 按用户、任务和权限投影最小上下文包
  -> Agent 通过 Skill、Markdown、SearchConnector、Connector 和 Tool Gateway 执行
  -> 证据不足时生成 knowledge gap
  -> Ask Router 选择 1 到 3 个相关 owner 主动询问
  -> 回复形成 review_status=pending 的 knowledge card
  -> 人工 review 后写回 Ontology，并发布到 Knowledge/Site 或进入检索投影

P0 不追求一开始做完整平台。当前优先验证：

  • 搜索和运行时访问路径是否正确。
  • 入库清洗是否丢事实。
  • 检索是否可解释、可审计、可控权限。
  • 主动询问是否少打扰、问对人、能沉淀。
  • 研用测一体流程是否能让团队自己持续试用和改进系统。
  • 上下文组合是否做到最小充分：既满足任务质量，又控制 token 成本、无关噪声和权限泄漏。
  • 每个实验结论是否能说明它验证的是 Evidence、Ontology 还是 Runtime Projection。

1.4 核心架构共识

产品定位

  • 产品本质是 Agentic Context Management SaaS：在当前任务和权限约束下加载最小充分上下文，降低 token、噪声和权限风险；上下文不足时主动补充并沉淀为组织资产。
  • MVP 主线是 Evidence capture -> Ontology build -> Runtime Projection -> knowledge gap -> proactive ask -> knowledge card -> review -> publish/index。
  • 入口层已明确为多输入主线：企业微信当前 MVP 按聊天记录采集、显式知识提交、用户上传文件、企微云盘/微盘/腾讯文档/群文件/团队文件空间、会议和业务系统分层；需要入库的消息由团队成员主动 @Bot、私聊 Bot、转发给 Bot，或写入指定文档/日报入口；人机实时交互生产优先 Bot URL 回调，开发/回归保留 Bot WS 长连接；自建应用/API 承担通讯录、部门成员、权限、文档/日报、会议、应用消息和主动提醒；企微云盘/文件空间作为独立文件 Evidence 入口，负责按 metadata、source ref、权限、hash、版本、parser status、retention policy 和 downstream artifacts 索引 Word、PPT、Excel、PDF、图片、压缩包、代码包、链接说明和业务专用格式；服务器默认索引优先、原件留在云盘；会话内容存档降级为全量被动采集、历史回溯和合规审计增强项；飞书自研 Bot 截图与 Hermes Agent 飞书实现已作为能力对标输入，进一步确认企微侧应按事件触发、再调 API 取详情、先入 Evidence、按身份和群/项目权限路由的产品边界推进。
  • 当前 repo 同时包含可打包框架层和当前 Demo 的私域领域知识；未来产品化时只抽通用工具、模板、connector contract、eval harness 和 dashboard generator，不打包当前项目领域知识。

三层主抽象

  • 项目主抽象已重构为三块：Evidence 原始证据层、Ontology 本体层、Runtime Projection 运行时投影层。
  • 原始企微记录、会议、文件空间上传物、文档、网页、代码和业务系统对象统一属于 Evidence；不再把原始资料拆成所谓 L4。
  • 元数据、对象、关系、规则、Markdown、ADR、实验报告、Knowledge Card、Skill、Workflow、权限视图和 writeback 都属于 Ontology 的对象或关系。
  • SearchConnector、Postgres/OpenSearch、MCP、Tool Gateway、Ask Router、企业微信消息和 dashboard 都是 Runtime Projection 的实现手段。

运行时访问策略

  • 运行时披露仍可按 D0-D5 渐进读取：当前任务 -> 入口索引/Skill -> 稳定知识制品 -> 检索投影 -> 证据读取 -> 主动补充。
  • 旧 L2/L3/L4/L5 口径里的技术点仍然保留：D2 攻克稳定知识制品，D3 攻克检索投影，D4 攻克 Evidence Connector，D5 攻克主动询问；它们只是运行时访问路径，不再是知识形态主模型。
  • P0 默认采用 Markdown 渐进披露 + Postgres FTS/pgvector 作为检索投影；OpenSearch/ES 保留为规模化 adapter。

组织拓扑与主动询问

  • workspaces/<workspace-id>/registry/ 承载组织私域拓扑；Framework 必须能同时服务个人、部门、项目三类上下文，并通过 permission view 防止互相污染。
  • 企业微信入口由团队协作者并行推进，当前 repo 侧先做本地模拟、知识库组织、Agentic Search、主动询问、知识外挂和风险实验。
  • 主动询问的 owner 来源已收敛为 owner registry contract：显式组织目录优先，Workspace Topology fallback；真实企微通讯录后续只替换 registry 来源。

研发方法

  • Framework 很大程度是在把 Loop Engineering 产品化：发现工作、装载上下文、执行动作、独立验证、持久化状态、决定下一步和通知相关人。
  • 维护采用精简口径：人读的机械生成页（研发进度、实验索引、语义 review 队列）由 registry 源在需要时手动重新生成、经人工 review 的 PR 落地；生成物不提交、不做新鲜度门禁、也没有定时自动维护 PR 循环。机械门禁统一跑 bash scripts/ci_check.sh（与 CI 对齐）；语义冲突进 Semantic Review Queue 或 PR 讨论，自动化不直接推 main、不静默改写私域知识。
  • 真实实践问题是 Harness 的一等研发样本：先进入 Evidence 保留可追溯线索，再抽象为 Ontology 对象、规则、Skill、Workflow 或实验制品，最后通过 Runtime Projection 变成脱敏 demo、benchmark、case study 或 CI gate；进入 demo 时必须写清真实来源、脱敏边界和工程验证目的。
  • 外部 Agentic Engineering / Palantir 本体论参考已纳入方案：Loop / Harness / FDE 对应 runtime、framework harness 和业务落地；Workspace Topology 正在从 context library registry 升级为轻量本体 contract。

1.5 高层缺口

这里列的是大能力缺口，不是具体执行任务；具体任务放在本章末尾的执行队列。

  • 企业微信智能机器人 Bot URL 回调、自建应用/API、显式知识提交入口、文档/日报、企微云盘/微盘/腾讯文档/群文件/团队文件空间和腾讯会议正式接入；创建/绑定文件空间、列目录、读 metadata、下载文件、订阅变更事件、文档评论/变更、任务、日历/会议、reaction、文件、邮件或企微替代对象事件仍待企微官方/后台验收；会话内容存档后台/API 配置已 solved（审核、公钥版本、Secret/env、接收事件服务器 URL verification），可信 IP （值见内部 connector-status，不公开） 与开启范围已确认（仅试点群聊、变分小组，小范围试点成员），官方 WeWorkFinanceSdk x86 已放到 服务器受限凭据路径 共享路径，GetChatData/DecryptData 脱敏 live smoke 返回 errcode=0,count=1,max_seq=1，seq=1 复跑返回 errcode=0,count=0,max_seq=1。
  • 真实共享文件空间、企微云盘/微盘/腾讯文档/群文件、Office/PDF/图片/压缩包/代码包/业务专用格式解析服务接入。
  • 真实 Postgres FTS/pgvector adapter。
  • 真实 OpenSearch/ES adapter。
  • 真实 Connector / MCP server 接入 Tool Gateway。
  • 完整 MVC 权限模型。

1.6 研发日报

全部 58 篇研发日报已迁移到企业微信文档：查看研发日报

1.7 当前执行队列

这里放下一轮可执行任务，和上面的高层缺口区分开。

本轮优先任务

  1. 外部集成 live 状态以 registry/connector-status.json 为单一事实源：需要回答企微/Claude 现在配到哪、域名/IP/某 API 怎么验证的，查它、不要凭会话记忆推断；配置或实测后当场更新。
  2. ADR-046 自主知识沉淀循环已完成最小代码切片；下一步先用真实脱敏 event_log 跑 --dry-run 做候选质量和脱敏 review，再由主智能体/owner 安装 wecom-autonomous-loop.service/.timer。首轮非 dry-run 仍只生成 knowledge/wiki/_drafts draft + Semantic Review item，不自动 promote、不发布、不进入正式检索投影。
  3. 企微 WS 模式离线知识管线已完成：入口无关准入层（connector_admission / connector_dedup_registry，require_mention / self-echo / allowlist / 跨源去重只存 hash + TTL / 频控）、端到端管线 wecom_message_pipeline（WeComMessageEvent → evaluate_admission → Connector Callback Ledger → Evidence 登记 → run_schedule_todo_assistant → Knowledge Card 草稿，leak_marker_count=0）、callback_event_to_message_event 回调入口归一、实时捕获脚本 wecom_bot_ws_capture（凭证仅环境变量、脱敏输出只写 /tmp、证据目录 /tmp 前缀硬护栏）和离线 demo 均已用 synthetic fixture + 单测验证，新增 21 个测试、全量 400 passed / 2 skipped / 0 failed。2026-06-17 进一步把显式知识沉淀的抽取一步从规则启发式转为 Claude-LLM 并以确定性治理为底座（ADR-041）：新增 framework/llm/claude_client（可插拔鉴权 + 模型/effort 可配）与 work_item_extractor（确定性解析兜底、负责人身份只由代码按花名册解析、LLM 只产出 owner_mention），并用独立 demo wecom_capture_llm_demo 在真实群里跑通「反问 → @ 澄清 → 补全登记待办」ask-confirm 闭环；P0 实时捕获已在新服务器复测通。下一步：①真实通讯录接入（synthetic_roster_from_directory 换真实 WeCom 通讯录数据源，解析逻辑不变）；②Ask Router 闭环（低置信/负责人未解析工作项 ask-to-confirm，把群里 @澄清回复接回管线补全）；③组件落地（把 framework/llm 的 LLM extractor 正式接进 wecom_message_pipeline 默认抽取步、规则保留 fallback，补单测/脱敏 fixture；生产改用专用 API key + raw SDK 跑 Sonnet/Opus）；④待团队成员 @机器人 时实跑 wecom_bot_ws_capture 做真实 @捕获验收；⑤用户回来按 runbook 配置后台后点亮 P1（智能机器人 Bot URL 回调）与 P2（自建应用/API），把入口无关管线接到生产入口，并补 P2 回调 HTTP handler 代码。
  4. 按 WeCom MVP 主动入口路线补智能机器人 Bot URL 回调 contract、synthetic fixture 和真实公网验收：验证生产人机聊天入口、成员私聊 Bot、群里 @Bot、被动回复、safe projection 和已保存 chatid 的主动群消息边界；Bot WS 保留为开发、smoke、回归和临时对话入口；入口准入参考 Hermes Feishu 的 URL verification/signature/token、event dedup、group policy、require_mention 和 bot-sender admission。
  5. 固化显式知识提交入口：团队需要入库就 @Bot、私聊 Bot、转发给 Bot，或写入指定文档/日报入口，并把这些入口接入 Evidence Registry、Ask Router、Knowledge Card 和 Tool Gateway 测试；个人上下文、群/项目共享上下文、跨人主动询问和组织系统上下文必须分权限视图和审计链路处理。

P0 待办池

  1. 把自建应用 callback scaffold 接到真实公网 HTTP handler 和企微后台配置：验收真实 GET URL 验证、POST 事件入 ledger、access_token、应用消息发送、主动询问/提醒、通讯录最小字段同步和可信 IP / WireGuard 出口确认。
  2. 选择企业微信文档、智能表格、微盘、OA 汇报和腾讯会议的测试对象，先用 synthetic 内容完成最小读写、录制/转写或纪要拉取，再登记 Evidence source 和 downstream artifacts；飞书对标里的文档评论/变更、任务、日历/会议、reaction、文件、邮件或企微替代对象事件未验收前保持“待官方/后台验收”。
  3. 把企微云盘/微盘/腾讯文档/群文件/团队文件空间作为独立文件 Evidence 入口推进：待官方/后台验收创建/绑定空间、列目录、读 metadata、下载文件和订阅变更事件；先用 synthetic 团队空间、个人授权目录、群文件和上传文件验证 drive_space/folder/file/version/permission_view/source_ref/parser_status/checksum/retention_policy/downstream_artifacts、索引优先、临时下载解析后删除和 restricted Site 阻断。
  4. 会话内容存档增强项已完成后台/API solved、可信 IP/试点范围确认、env/私钥 presence 校验、官方 WeWorkFinanceSdk x86 SDK 放置到 受限共享路径和脱敏 smoke CLI；当前 GetChatData/DecryptData live smoke 已返回 errcode=0,count=1,max_seq=1，seq=1 复跑返回 errcode=0,count=0,max_seq=1。下一步设计 gitignored seq checkpoint、restricted Evidence schema/redaction guard 和 synthetic fixture；仍不启动任何 callback/systemd/Caddy 服务，真实会话内容不进入普通 Knowledge、Site 或普通 Agent 上下文。若进入真实采集，还需员工告知、留存/删除、访问审批、seq/cursor checkpoint、restricted Evidence 和审计。
  5. 把本地 task_skill_runtime 接入线上 Agent / 企微 / Web runtime，自动记录触发次数、误触发、漏触发、平均 tokens 和人工纠正。
  6. 做 Postgres FTS/pgvector 外部服务 adapter 与 OpenSearch/ES 外部服务 adapter 对照，并复用 SearchConnector conformance、Tool Gateway conformance 和 Search Adapter State Benchmark；未配置服务时必须在 adapter matrix 中明确 skipped_unavailable。
  7. 把发布前分类审查流程接到 docs 修改和 PR 语义检查，确保 framework_reference、template、demo_workspace、case_study、generated 的处理方式进入 review 流程。
  8. 扩展 ask_router_simulation：加入真实团队问题和问错人反馈，并把企微真实回调接入现有 append_parsed_reply_to_card 与 recent_ask_events。
  9. 扩展 conformance：路径/owner/存在性泄漏、rank_log 字段完整性、批量 delete/reindex 传播、真实 projection_states、Projection Remediation worker、gap receipt 复用和 review adapter。
  10. 把后续企微 connector 包到 Tool Gateway 调用路径后面。
  11. 把共享文件空间入口扩展为真实上传服务、企微云盘/团队空间 connector 和解析队列，并继续验证 Evidence-ready、pending_parse、Knowledge-ready、needs_review、unsupported、parser_hint、field_mask 和 unsupported format handoff。
  12. 做 permission leak test，验证无权限用户不能看到内容、路径、owner 或对象存在性。

1.8 如何阅读这页

  1. 先看“1. 项目总览”，判断项目当前阶段、P0 主链路、核心共识、高层缺口和当前执行队列。
  2. 再看“2. 研发进度看板”，区分三层架构主线进度和具体项目模块进度。
  3. 需要判断技术路线时，看“3. 实验与验证中心”，进入对应实验报告和风险摘要。
  4. 维护者和 reviewer 再看“4. 自动化闭环与待处理项”，确认 Loop、Review Queue 和 Timeline 有没有需要人工接管的事项。
  5. 复盘真实踩坑和研发经验时，看“5. 真实问题与踩坑记录”；看不懂缩略词时到“6. 附录：导航与术语”底部查术语。

2. 研发进度看板

查看三层架构和具体项目模块分别做到哪一步，以及每一块下一步该怎么接。

展开：2. 研发进度看板

2.1 架构层进度

这一小节只看三层主架构，并把每条主线的已完成事项和下一步拆成可扫描的编号清单。

每条架构主线按“目标 / 当前状态 / 已完成 / 下一步 / 入口”折叠展示，避免把长段落塞进宽表格。

Evidence 原始证据层

目标： 保留企微聊天、显式知识提交、用户上传文件、企微云盘/微盘/腾讯文档/群文件/团队文件空间、会议、文档、外部资料、代码和业务系统对象的原始证据，并保证 provenance、权限、hash、版本、解析状态和回查路径。

当前状态： 基础目录、原始资料沉淀流程、Evidence Registry 机器契约和共享文件空间 synthetic ingestion 已建立；2026-06-16 两份 WeCom 正式全量路线调研已从临时路径提升到 repo raw Evidence 并登记；飞书自研 Bot 截图与 Hermes Feishu 实现只作为脱敏需求/设计参考沉淀为知识页，不复制原图、不提交真实配置；本轮已把企微云盘/微盘/腾讯文档/群文件/团队文件空间补为独立文件 Evidence 入口，明确对象模型、索引优先存储、解析队列、权限审计和待验接口清单；会话内容存档已完成后台审核、公钥版本 1、Secret 与私钥版本 env 配置，临时接收事件服务器公网合成验证通过，可信 IP （值见内部 connector-status，不公开） 与试点范围已确认（仅试点群聊、变分小组，小范围试点成员），官方 WeWorkFinanceSdk 已放到 受限共享路径，GetChatData/DecryptData 脱敏 live smoke 已通过；真实企微云盘/文件服务和外部业务系统 adapter 未接。

已完成

  1. workspaces/variai/evidence/raw/、workspaces/variai/evidence/inbox/、knowledge card、callback ledger、source_uri、review_status、ContextDocumentRecord 和多个实验输出已形成最小证据链
  2. workspace-topology.json 已把 Evidence 声明为主架构层，并要求 Runtime Projection 可审计回查 Evidence
  3. workspaces/variai/evidence/registry/evidence-registry.json 已校验 source snapshot、sha256、临时外链封口、PII/field mask、attachment manifest 和 downstream artifact
  4. Ingestion Quality Demo 已生成 8 条实验级 Evidence source、独立 raw snapshot 和可 lint 的 Evidence Registry，并证明不能只做 naive summary
  5. Connector Callback Ledger 已把 2 条有效 recorded callback 投影为受限 Evidence source 和 raw snapshot，重复、无效签名、过期或缺字段回调不会进入 Evidence
  6. File Evidence Ingestion Demo 已用 6 个 synthetic 上传物覆盖 Markdown、DOCX、XLSX、ZIP、外部链接说明和财务专用格式，验证全部原始材料先 Evidence-ready，只有已解析材料 Knowledge-ready
  7. No-WeCom MVP Demo 已把 1 条本地 reply callback 先投影为受限 Evidence source/raw snapshot，再驱动 AskFeedbackEvent 和 pending Knowledge Card 审计引用
  8. 2026-06-16 WeCom full-route feasibility 与 WireGuard network report 已以 sha256、source_uri、provenance 和 downstream_artifacts 登记到 Evidence Registry
  9. 本轮新增飞书 Bot 能力对标路线图，把用户截图摘要和 Hermes Feishu gateway/comment/meeting/doc/drive 代码模式转成脱敏产品边界和企微实现参考
  10. 本轮补齐企微文件 Evidence 对象模型 drive_space / folder / file / version / permission_view / source_ref / parser_status / checksum / retention_policy / downstream_artifacts，并明确 restricted 文件不进入公开 Site。

下一步

  1. 把正式 WeCom 路线里的智能机器人 Bot URL 回调、显式知识提交入口（@Bot / 私聊 Bot / 转发 Bot / 指定文档日报）、用户上传文件、自建应用/API、文档/日报、企微云盘/微盘/腾讯文档/群文件/团队文件空间、腾讯会议和业务系统先写入 Evidence Registry，再投影到 ContextDocument 或 Ontology artifact
  2. 创建/绑定团队空间、列目录、读 metadata、下载文件、订阅变更事件、文档评论/变更、任务、日历/会议、reaction、文件、邮件或企微替代对象事件必须先做官方文档/后台验收，未确认前只作为待验能力登记
  3. 会话内容存档只在全量被动采集、历史回溯或合规审计增强项启动时接入 restricted Evidence
  4. 继续补自动 PII/合同号/客户名识别、field mask 建议、Office/PDF/图片/压缩包/代码包解析器和业务专用格式 adapter。

入口： 本体驱动上下文架构, Evidence Registry, Ingestion Quality Demo, Connector Callback Ledger, File Evidence Ingestion Demo

Ontology 本体层

目标： 把元数据、对象、关系、规则、知识制品、Skill、Workflow、权限视图、Action 和 Writeback 统一成组织语义操作模型。

当前状态： 最小 architecture layer / layer relationship / metadata / artifact / skill / provenance / object / relationship / rule / action / writeback contract 已进入 Workspace Topology 和 lint；semantic review 与真实持久化 ontology registry 仍待深化。

已完成

  1. workspace-topology.json 已覆盖 Evidence、Ontology、Runtime Projection 三段主抽象和三条层间关系
  2. personal、department、project 三类 demo 已接入 ontology expectation
  3. OntologyToolGateway 10/10 通过
  4. Knowledge Card review/promote/reindex queue lifecycle 已写入 ontology registry
  5. Connector Callback Ledger 已把 ledger-connector-callback 写入 ontology registry
  6. 任务技能包、project status、experiment registry 已成为可运行本体制品，实验 registry 已按架构主线标注
  7. Evidence Registry 已让 ontology artifact 可反查源材料
  8. Task Skill Feedback 已把真实使用日志中的误触发、漏触发和 token 成本转成可 review 的 Skill 改进建议，并通过 Task Skill Review Bridge 写入 Semantic Review Queue。

下一步

  1. 把 semantic review、roadmap、实验、任务包、task skill feedback、task skill review bridge 和 knowledge card 的生命周期继续统一到 ontology registry
  2. 把 Evidence Registry 的 downstream artifact 链路接到更多 ontology artifact，并把本地 JSON contract 演进为可持久化服务边界。

入口： Workspace Topology, Ontology Tool Gateway, 任务技能包

Runtime Projection 运行时投影层

目标： 根据当前用户、任务、权限和本体状态，投影出最小充分上下文包，并通过 Tool Gateway、SearchConnector、Ask Router 和 LoopRun 审计执行。

当前状态： 本地无企微闭环、企微 Bot synthetic projection、Bot WS live smoke runner、自建应用 callback synthetic scaffold、日程/待办助手、SearchConnector、Tool Gateway、Ask Router、Knowledge Card Gateway 和多项 eval 已跑通或就绪；真实 Bot WS 已完成连接、订阅、单聊回调、群 @回调、固定回复和 reply ack 验证；正式 WeCom 路线已修正为人机实时交互（生产优先 Bot URL 回调，开发/回归保留 Bot WS 长连接）+ 显式知识提交 MVP（@Bot / 私聊 Bot / 转发 Bot / 指定文档日报）+ 用户上传文件 + 企微云盘/微盘/腾讯文档/群文件/团队文件空间 + 自建应用/API + 文档/日报 + 腾讯会议，会话内容存档为全量被动采集增强项；会话内容存档已完成后台审核、公钥版本 1、Secret 与私钥版本 env 配置，临时接收事件服务器公网合成验证通过，可信 IP （值见内部 connector-status，不公开） 与试点范围已确认（仅试点群聊、变分小组，小范围试点成员），官方 WeWorkFinanceSdk 已放到 受限共享路径，GetChatData/DecryptData 脱敏 live smoke 已通过；真实 Postgres/OpenSearch、智能机器人 URL 回调、自建应用公网 HTTP handler 与后台配置、显式知识提交真实入口、企微云盘/文件空间 connector、真实文件空间和外部业务系统未接。

已完成

  1. Context Management Eval 4/4
  2. Workspace Scope Eval 7/7
  3. No-WeCom MVP Demo 跑通 gap、ask、callback Evidence、feedback、reply、review、promote、reindex、search
  4. WeCom Bot Local Demo 已把 4 个 synthetic AI Bot 帧投影为 3 条内部消息事件并跳过 1 条事件帧，复用 Schedule / Todo Assistant
  5. Bot WS smoke runner 已新增，凭环境变量读取 Bot ID/Secret，能订阅长连接、等待真实回调、发送固定 markdown 回复并写入脱敏运行报告
  6. 本地 .env.wecom.local 已创建为未跟踪 secret 文件并验证被 .gitignore 忽略
  7. 2026-06-16 真实 Bot WS smoke 已通过，报告显示 env_present=true、subscribe_ok=true、direct_seen=true、group_seen=true、reply_sent=2、reply_ack_seen=2、errors=[]，并已在一台全新的、uv 管理的 Ubuntu 开发服务器上从零复现同一结论，验证该通道的环境可重建性 / 可移植性（clone + uv 接管 Python + 运行/开发依赖 + 个人工作分支 + 仅环境变量读取真实凭证）
  8. 真实 Bot WS cmd / headers.req_id / body payload 已可投影为内部 WeComMessageEvent，并生成 Connector Callback Ledger 可消费的安全登记请求，safe output 不暴露真实消息 ID、会话 ID、用户 ID 或正文
  9. 2026-06-16 WeCom 正式路线调研明确公网回调不能替代会话内容存档，WireGuard 应避免影响 443 回包和企业微信 API/SDK 固定出口
  10. 后续产品路线判断进一步明确当前 MVP 不依赖会话内容存档，显式知识沉淀由 @Bot、私聊 Bot、转发 Bot 或指定文档/日报入口覆盖
  11. 本轮已修正文档口径，明确智能机器人 Bot URL 回调可替代生产常驻 Bot WS，但不能替代自建应用/API，会话内容存档是全量被动采集增强项
  12. 自建应用 callback scaffold 已覆盖 URL verification、POST 验签解密、text/event safe projection、Connector Callback Ledger request 和不联网的应用 text message payload builder
  13. Schedule / Todo Assistant 已从 5 条 synthetic 企微消息抽取 4 个事项，3 个 ready、1 个 pending confirmation，并合并重复来源
  14. Search Adapter State Benchmark 4/4 暴露并约束 stale projection window，SearchConnector Tool Gateway 已把 stale_index=true 接入 runtime 阻断，并让 high severity gap receipt 复用 Projection Remediation item id
  15. Context Router Stale Policy Eval 4/4 已按任务风险覆盖 allow_with_notice、require_human_confirmation、wait_for_reindex、block_and_report_gap
  16. Projection Remediation Eval 3/3 已把关键风险 block_and_report_gap 接到本地补证队列、本地 worker reindex event、timeout retry schedule、attempt idempotency、lease token callback guard、项目 Timeline 和 Semantic Review handoff
  17. context_libraries 已声明 projection_role 与 D0-D5 runtime_paths
  18. 本轮 P1.5 显式知识沉淀代码核心已在 WS 入口落地、入口无关管线可复用于未来回调入口：新增入口无关准入层 connector_admission.py / connector_dedup_registry.py（require_mention / self-echo / allowlist / 跨源去重只存 hash + TTL / 频控）、端到端管线 wecom_message_pipeline.py（WeComMessageEvent → evaluate_admission → Connector Callback Ledger → Evidence 登记 → run_schedule_todo_assistant → Knowledge Card 草稿，leak_marker_count=0）、callback_event_to_message_event 回调入口归一、实时捕获脚本 scripts/wecom_bot_ws_capture.py（每条入站消息内存中跑管线，凭证仅环境变量、脱敏输出只写 /tmp、证据目录 /tmp 前缀硬护栏）和离线 demo scripts/wecom_message_pipeline_demo.py
  19. 新增 21 个测试，全量回归 400 passed / 2 skipped / 0 failed（基线 379），全部 synthetic fixture + 单测、无真实数据。

下一步

  1. 补智能机器人 Bot URL 回调契约、fixture 和真实公网验收，把生产人机聊天入口从常驻 Bot WS 切到 URL 回调
  2. 固化显式知识提交入口，把 @Bot、私聊 Bot、转发 Bot 和指定文档/日报入口接入 Evidence Registry、Ask Router、Knowledge Card 和 Tool Gateway 的可审计链路
  3. 把用户上传文件、企微云盘/微盘/腾讯文档/群文件/团队文件空间接入文件 Evidence Registry、parser queue、permission view 和 Tool Gateway，先做 metadata 索引、hash/版本登记、临时下载解析后删除、restricted Site 阻断
  4. 把自建应用 callback scaffold 接到真实公网 HTTP handler、企微后台 Token/EncodingAESKey/可信 IP、access_token、应用消息和通讯录最小字段
  5. 随后接文档/日报测试对象、团队/项目文件空间和腾讯会议测试会议
  6. 会话内容存档下一步不要在 lqy/quanyili 侧常驻 18101 callback，SDK live smoke 已通过，继续设计 gitignored seq checkpoint、restricted Evidence schema/redaction guard/synthetic fixture，后续再评估 GetMediaData
  7. Bot WS message event 继续作为开发/回归入口
  8. 配置真实 Postgres/OpenSearch 测试服务后用 --include-live-adapters 复用同一状态传播 benchmark，将本地 Projection Remediation worker contract 替换为真实 reindex worker，并接企微/GitHub review adapter、持久化队列、并发锁、retry ledger 和 adapter callback
  9. 继续用真实团队问题校准最小上下文、rank_log、成本、权限、task risk 和 stale projection 分级策略。

入口： 运行时渐进披露, Context Management Eval, Context Router Stale Policy Eval, No-WeCom MVP Demo, WeCom Bot Local Demo, Schedule / Todo Assistant

2.2 项目模块进度

这一小节看具体研发模块的状态、已完成事项、下一步和入口。

每个模块按“当前状态 / 已完成 / 下一步 / 入口”折叠展示，避免把长段落塞进宽表格。

协作和知识库底座

当前状态： 已建立，持续维护

已完成

  1. GitHub + Evidence + Knowledge + Site + MkDocs + 双仓库推送
  2. 自试用闭环写入 ADR-014

下一步

  1. 清理过时口径，持续把讨论沉淀到 Knowledge/Site

入口： 团队协作总览, Karpathy LLM Wiki

团队项目 Repo MVP

当前状态： 产品形态已明确

已完成

  1. 当前 repo 被定位为未来团队项目空间的最小 Demo
  2. 状态看板、Evidence、Knowledge、Site、结构化实验报告、ADR 和 CI 构成最小产品容器
  3. workspace scaffold 已从占位文件升级为最小可用新团队初始化模板，可生成 workspace site、knowledge seed、workspace topology、project status、experiment registry、LoopRun 和 Semantic Review seed

下一步

  1. 继续把初始化模板接入真实 repo 创建流程，并让新 workspace 首次生成后自动跑项目看板、实验索引和 MkDocs strict build

入口： 团队项目 Repo：产品 MVP 形态, ADR-016

框架/领域知识解耦

当前状态： 第一批代码迁移、workspace contract、scaffold 和 import 边界加固完成

已完成

  1. 新增 framework/、workspaces/variai/、workspace.blueprint.json、packaging.manifest.json
  2. benchmark、context router、ask router、knowledge lint、SearchConnector、task skill packages、experiment_report 已迁入 framework/
  3. 通过 WorkspacePaths 参数化当前 demo 路径
  4. workspace dry-run 当前 copy=5、template=7、create=14、exclude=6 且通过
  5. scaffold 快照确认不带入 workspaces/variai/registry、site/ 或缓存文件
  6. scaffold seed 已包含最小 Site、Knowledge、workspace topology、project status、experiment registry、LoopRun 和 Semantic Review Queue，并可用现有 validator 渲染项目看板
  7. 本地搜索基础能力已下沉到 framework/context/local_search.py，组织目录读取下沉到 framework/connectors/org_directory.py，package_boundary_lint 会阻止 framework 层反向导入 orgreorg_demo
  8. site_page_inventory 已把发布网站逐页分类为 framework_reference、template、demo_workspace、case_study 和 generated，并进入 CI 与 LoopSpec 门禁
  9. Site Page Inventory 已生成 packaging/scaffold plan，并校验 packaging.manifest.json 中 Site 必须是 mixed/template_only、workspace.blueprint.json 中 Site 必须是 template_then_replace
  10. starter site 模板已迁入 framework/templates/site/ 并由 scaffold 渲染
  11. Site Publish Review 已把页面分类映射到发布前 review action、required gate、reviewer 和真实实践问题脱敏进入 Demo 的规则
  12. Site PR Review Adapter 已把安全 changed-path 摘要映射成 PR comment、required reviewer 和 check-run request 的本地 contract
  13. Site PR Review Bridge 已把这些安全 request 写回 Semantic Review comment_added 事件流，并进入 CI / LoopSpec 门禁
  14. Site PR Review Delivery 已把 bridge 后面的 GitHub PR comment、required reviewer、check-run 和 polling 四类投递动作实体化为 dry-run delivery plan，intent=20、leak=0，并进入 CI / LoopSpec 门禁

下一步

  1. 继续抽 WeCom adapter contract、任务包使用日志
  2. 把 Site PR Review Delivery 从 dry-run plan 推进到显式 apply、live polling、GitHub App 权限和安全投递回执事件

入口： 框架与领域知识解耦, Workspace Blueprint, ADR-017, ADR-018, ADR-019

组织私域拓扑与隔离验证

当前状态： topology contract、最小 ontology contract、Context Router、三类 demo 和四类风险探针完成

已完成

  1. workspaces/variai/registry/workspace-topology.json 已覆盖 organization、departments、people、projects、tasks、context_libraries、ontology_contract、ask_router_bindings、routing_rules、permission_views
  2. 完整 ontology contract 覆盖 8 个 object、5 个 relationship、5 个 rule、7 个 action 和 4 个 writeback event type，其中 callback ledger object/writeback 已由 Connector Callback Ledger 实验覆盖
  3. Ask Router topology binding 已覆盖 personal、department、project 三类 scope，可按 task_id 或 context_library 选择对应 ask action、对象状态和 throttle 对象
  4. owner registry 已支持显式组织目录优先、Workspace Topology fallback，并覆盖 tasks/context_libraries owner
  5. framework/context/context_router.py 已升级到 context_router_feature_v1，不再只看关键词，而是组合 lexical overlap、关键词短语、task binding、source path、scope signal、permission scope、ontology binding、lifecycle 和 unknown topology penalty
  6. Workspace Scope Eval 覆盖 personal、department、project 三类基础 demo 和跨部门项目、员工调岗、项目归档、权限变更 stale index 四类风险探针，7/7 通过，7 个 case 均输出 Context Router score log，24 个候选均输出 feature breakdown，router 权限过滤库数 10，safe output 泄漏标记为 0，故意不安全 connector 的 9 个越权候选输出被 Tool Gateway 过滤，stale index 阻断 2/2，archived project lifecycle 过滤 1，Ontology contract case 数 3
  7. Ontology Tool Gateway Conformance 10/10 通过，已验证 personal、department、project 三类 ask action、action-policy 映射、required scopes、rule 覆盖、按 action type 判断对象 lifecycle、writeback 审计，以及 pending card 可 ask/review、reviewed card 可 promote
  8. OntologyToolGateway 已接入三类 Ask Router route 以及 Knowledge Card review、promote、reindex queue 的本地执行路径，Ask Router、review/promote 与 queue worker 前后态已写入 ontology registry
  9. Connector Callback Ledger 已把 callback ledger state 写入 ontology registry audit stream

下一步

  1. 用真实团队问题和人工纠正日志校准 context_router_feature_v1 的 feature 权重
  2. 把合成 stale index 替换成真实 adapter 的删除传播、重建延迟和权限变更事件
  3. 继续接 Postgres/OpenSearch adapter、外部 Connector action、企微通讯录/投递/回调 adapter

入口： Workspace Topology, Workspace Scope Eval, Ontology Tool Gateway, ADR-033

Agentic Context Management 指标

当前状态： 最小充分上下文评测、Context Router trace、rank_log 观测完成

已完成

  1. Context Management Eval 覆盖 personal、department、project 和权限受限 gap 四类 case，4/4 通过
  2. 已复用 context_router_feature_v1 生成 route trace 和 12 个候选 feature breakdown
  3. Context Router Stale Policy Eval 4/4 已验证 low/medium/high/critical 四档 stale-index 披露策略
  4. 已复用 route_ask_request 生成 ask message、ask trace 和 pending knowledge card
  5. 平均 token 节省 24.6%，权限过滤候选数 4，router 权限过滤库数 4，trace event 数 9，SearchConnector rank_log case 数 4，gateway filtered output 数 4，knowledge gap 数 1，ask event 数 1，Ask Router guarded route 已验证 ontology gate 与 registry safe output，safe output 泄漏标记为 0
  6. 已把“知识构建和搜索服务于上下文管理”落成可运行指标，并把 route trace / feature breakdown / stale policy / SearchConnector rank_log / ask event / pending knowledge card 作为 Loop 状态输出

下一步

  1. 用真实团队问题和人工纠正日志校准 context_router_feature_v1 的 feature 权重和 task risk 标注，把 route_ask_request 的本地消息投递替身接到真实 Ask Router / 企业微信消息事件，并让 Postgres/OpenSearch adapter 输出同一 rank_log contract、延迟、成本和 projection_states

入口： Context Management Eval, Context Router Stale Policy Eval, 产品底层逻辑, 私域上下文库与检索总线

研用测一体

当前状态： 已确立原则，实验报告索引与进度看板已联动

已完成

  1. 开发过程即运行项目
  2. 资料、观点、实验和摩擦进入 capture -> compile -> review -> publish -> verify
  3. 当前 22 个 P0 实验已进入 workspaces/variai/registry/experiment-reports.json，网站实验索引和研发进度看板都从同一 registry 生成
  4. experiment_report 已强制 owner、freshness、cost、risk_level 字段，并同步到实验索引和项目看板
  5. 真实团队问题回归集已经开始把讨论中暴露的误路由、误搜索、权限边界、CI 失败、stale projection 补证和 task skill 误触发/漏触发问题转成可复跑 benchmark 或 feedback report
  6. 实践 case 进入 demo 时必须标明真实来源、脱敏边界和工程验证目的，避免被误解为仍在旧问题上循环
  7. Task Skill Feedback Loop 已把 12 条真实/本地使用事件转成 4 条建议、2 个 handoff，泄漏检查为 0
  8. 这 2 个 handoff 已通过 Task Skill Review Bridge 写入 Semantic Review Queue，并进入 CI/LoopSpec freshness 门禁

下一步

  1. 把实验 freshness 复查提醒接到 LoopRun / Review Queue
  2. 由 reviewer 确认 task-skill 两类 handoff 后再反写 manifest/gotchas/eval fixture，并把 task-skill handoff 复用 Site PR Review Bridge 的事件投影模式接入真实 PR review comment adapter

入口： 讨论-记录-开发-测试循环, ADR-014

Loop Engineering

当前状态： 概念保留；早期自指脚手架（站点自维护、GitHub Actions ledger/retry、task-skill feedback、LoopRun 报告持久化、runtime_refresh、daily-maintenance workflow）已在精简中移除

已完成

  1. 概念已明确：Framework 很大程度在把 Loop Engineering 产品化（发现工作→装载上下文→执行动作→独立验证→持久化状态→决定下一步→通知相关人）。精简后保留的最小实现由统一 CI 门禁（scripts/ci_check.sh，与 CI 对齐：安全/边界/架构 lint、行为 eval、单元测试、mkdocs build --strict）、registry 驱动的生成页（project-progress / experiment-reports / semantic-review-queue）和 Semantic Review Queue 共同承载
  2. 机械生成页只从 registry 源重新生成，不提交生成物、不做新鲜度门禁。早期为验证闭环搭的自指脚手架（Site Publish Review、Site PR Review、GitHub Actions Run Ledger/Retry Policy、Task Skill Feedback/Review Bridge、LoopRun 报告持久化、runtime_refresh.py、daily-maintenance.yml）已作为过度工程移除，结论沉淀在 ADR 与历史日报。

下一步

  1. 把 Loop Engineering 收敛为面向客户的 domain 初始化 / 交付验收 playbook（Loop / Harness / FDE 分层）
  2. 真实回调 / 投递接通后，用企微 adapter 替换本地 ask / feedback 替身，让闭环改由真实 PR 与回调事件驱动。

入口： Loop Engineering, 讨论-记录-开发-测试循环, Context Management Eval

本体驱动上下文架构

当前状态： 主抽象已重构，进入全项目对齐

已完成

  1. 项目主线从旧 L0-L5 知识分层校准为 Evidence -> Ontology -> Runtime Projection
  2. 原始资料统一归入 Evidence
  3. Markdown、ADR、实验报告、Skill、Knowledge Card、权限视图和 writeback 统一归入 Ontology
  4. SearchConnector、MCP、Tool Gateway、Ask Router 和企微消息归入 Runtime Projection
  5. 运行时仍保留 D0-D5 渐进披露路径作为访问策略

下一步

  1. 把 ontology contract 扩展到 metadata、artifact、skill、provenance
  2. 把所有实验和 roadmap 按三段主线归类，并让真实 adapter 验证 runtime projection 的延迟、成本、rank_log 和 stale 阻断

入口： 本体驱动上下文架构, 运行时渐进披露

任务技能包

当前状态： 第一批最小包、Ask Router Review、使用日志 dashboard 和本地 runtime 已实体化

已完成

  1. progressive_manifest_guarded Precision/Recall/Exact/Safe 均为 100%
  2. 已新增 framework/task_skills manifest lint 和 harness_knowledge_ingest、agentic_search_benchmark、project_status_dashboard、ask_router_review 四个最小包
  3. 新增 task_skill_usage_log 与 task_skill_runtime，当前 12 个本地研用测事件 precision/recall 均为 91.7%，人工纠正率 16.7%
  4. Task Skill Feedback Loop 已从 usage log 生成 4 条建议、2 个 review handoff，unsafe_payload_leaks=0，并把真实 case 的来源、脱敏边界和工程验证目的写入报告
  5. Task Skill Review Bridge 已把 manifest review 与 cost review 写入 Semantic Review Queue，作为反写 manifest/gotchas/eval fixture 前的人工确认点

下一步

  1. 把本地 task_skill_runtime 接入线上 Agent / 企微 / Web runtime
  2. 由 reviewer 确认 semrev-task-skill-manifest-feedback 和 semrev-task-skill-cost-feedback 后再反写 manifest、gotchas 和 eval fixture
  3. 把 Tool Gateway safety case 纳入 usage dashboard，并继续记录 ask_router_review 的问错人、节流和回复解析纠正信号

入口： 任务技能包与可执行知识, Task Skill Package Eval, Task Skill Usage Log

Agentic Search

当前状态： P0 选型、SearchConnector contract、本地 adapter、ES hybrid 知识检索、可选外部 adapter skeleton、conformance、Tool Gateway 和状态传播 benchmark 接入完成

已完成

  1. P0 默认 tiered_markdown_postgres
  2. 规模化候选 tiered_markdown_opensearch
  3. 2026-06-19 知识检索 ES backend 已 live 升级为 BM25 + dense_vector kNN + RRF hybrid：/home/crf/model-service 独立 CPU bge-m3 REST 服务绑定 127.0.0.1:8001，variai-knowledge 2093 个章节全部写入 1024 维 embedding，语义改写查询可补 BM25 top5 未命中的 ADR-042 召回
  4. KB 忠实度 P0-6 已修复：本地 BM25 与 ES 检索结果均携带 source_class，decisions / site / wiki / projects 判为 stable_knowledge，evidence/raw / evidence/inbox 判为 raw_evidence，同分或近分时稳定知识优先但 raw/inbox 仍保留为证据线索，bash scripts/ci_check.sh 全绿
  5. in_memory 与 sqlite_fts 两个 connector 共 14 个 conformance cases 100% 通过
  6. Postgres FTS/pgvector 与 OpenSearch/ES adapter skeleton 已接入可选 conformance 注册
  7. SearchConnector Tool Gateway 7 个 cases 100% 通过，已把 stale_index=true 从状态传播 benchmark 接入 runtime 阻断，并让 high severity reindex/gap receipt 复用 Projection Remediation item id
  8. Context Router Stale Policy Eval 4/4 通过，已按 low/medium/high/critical 四档任务风险决定 stale context 披露、人工确认、等待 reindex 或 block_and_report_gap
  9. Projection Remediation Eval 3/3 通过，已把关键风险 block_and_report_gap 接到 queued_for_reindex 补证 item、本地 worker reindex_succeeded event、timeout retry schedule、attempt idempotency、lease token callback guard、项目 Timeline 和 pending Semantic Review handoff
  10. Search Adapter State Benchmark 4/4 通过，删除、权限降级、supersede 三类 stale-index window 均被检测，reindex 前暴露 3 个 stale hit，reindex 后 4/4 恢复安全，rank_log 已包含 generation、stale_index、过滤计数、adapter id、adapter kind、latency 和 cost units
  11. adapter matrix 已覆盖 sqlite_fts、postgres_fts、opensearch，未配置 DSN/URL 时 live adapter 明确标记 skipped_unavailable

下一步

  1. 把 model-embedding systemd unit 由有 sudo 权限的流程安装到 /etc/systemd/system
  2. 继续用真实问题扩展 ES hybrid 召回回归样例，按需评估 bge-reranker-v2-m3 CPU REST
  3. 接真实 Postgres/OpenSearch 测试服务后用 --include-live-adapters 复用 SearchConnector conformance、Tool Gateway conformance、Context Router stale policy、Projection Remediation Eval 和 Search Adapter State Benchmark，跑 live conformance、延迟、成本、rank log、projection_states、索引传播、权限变更传播、删除传播、真实 reindex worker、持久化 retry ledger、timeout、idempotency 和并发锁对照

入口： 私域 Agentic Search, SearchConnector Contract, SearchConnector Conformance, SearchConnector Tool Gateway, Context Router Stale Policy Eval, Projection Remediation Eval, Search Adapter State Benchmark, Postgres Search Adapter, OpenSearch Adapter, 选型实验

入库清洗

当前状态： 第一轮风险实验完成，输出已接入 Evidence source -> ContextDocumentRecord 链路

已完成

  1. structured ingestion 事实召回 100%，naive summary 只有 19%
  2. ingestion quality 输出已生成 8 条 Evidence source、8 个 raw snapshot、可校验 Evidence Registry，并迁移为 ContextDocumentRecord，可投影到 SearchConnector.ContextDocument

下一步

  1. 给 JSON/表格增加结构化字段映射
  2. 增加 PII 检测和 field_mask 自动建议

入口： Ingestion Quality Demo

检索风险

当前状态： 第二轮本地 benchmark、SearchConnector contract、状态传播风险、Context Router stale policy 和补证路径实验完成

已完成

  1. hybrid_guarded 达到安全回答率 100%，权限泄漏和 lifecycle 违规为 0
  2. sqlite_fts adapter 已验证真实本地 FTS 索引路径
  3. Search Adapter State Benchmark 已暴露删除、权限降级和 supersede 三类 stale-index window，并验证 reindex 后 lifecycle / permission / superseded opt-in 语义恢复安全
  4. SearchConnector Tool Gateway 已统一阻断 stale hits，并让 high severity gap receipt 复用 Projection Remediation item id
  5. Context Router Stale Policy Eval 4/4 已按任务风险选择低风险提示、中风险人工确认、高风险等待 reindex、关键风险 block_and_report_gap
  6. Projection Remediation Eval 3/3 已把 block_and_report_gap 与本地 reindex worker event / timeout retry / attempt idempotency / lease token callback guard / 项目 Timeline / Semantic Review handoff 统一
  7. Postgres/OpenSearch live adapter 的可用性与跳过原因已进入 adapter matrix

下一步

  1. 接入 Postgres/OpenSearch 外部服务 adapter，并用 --include-live-adapters 补真实延迟、成本、rank log、projection_states、删除传播、权限变更传播、reindex backlog、补证队列 worker、retry ledger、timeout、idempotency 和并发锁

入口： Retrieval Platform Benchmark, Search Adapter State Benchmark, Context Router Stale Policy Eval, Projection Remediation Eval

运行时访问路径

当前状态： 对照实验完成，并迁移到 SearchConnector contract

已完成

  1. tiered_hybrid 在当前样例 Recall、Top1、gap、安全均为 100%
  2. 受控路径通过 SearchConnector.get_document() 做候选过滤

下一步

  1. 接入真实检索投影 adapter 和 Evidence Connector

入口： Context Layer Benchmark

主动询问

当前状态： 本地仿真、Ask Router contract、knowledge card 生命周期与 gateway 检索外挂闭环完成，企微未接

已完成

  1. 9 个合成场景 Top1、Recall@3、安全路由、消息契约、负反馈和节流均为 100%，重复询问抑制数 1
  2. 新增 route_ask_request / route_ask_request_guarded 本地 Ask Router contract，可从 gap 生成 ask message、trace log 和 pending knowledge card，并用 recent_ask_events / cooldown_minutes 抑制重复打扰
  3. 新增 ask_feedback_event_from_reply / apply_feedback_events / ask-feedback-events.json，可把结构化回复中的 better_owner 或“不是我负责”写成本地回调事件并影响下一轮路由
  4. owner registry 已统一为显式目录优先、Workspace Topology fallback，orgreorg_demo、ask_router_simulation 和 No-WeCom MVP Demo 均使用同一 contract
  5. No-WeCom MVP Demo 已跑通 ask_ontology_action=allow、ask_registry_event_count=2、初始问错人、Connector Callback Ledger 采信有效 reply callback、幂等抑制重复回调、拒绝无效签名、callback Evidence source=1、registry_error=0、feedback_event_ref=1、knowledge_card_ref=1、反馈纠错、reply、review、promote、OntologyToolGateway、Knowledge Card Tool Gateway reindex/search 的完整主链路，并加入 pending、rejected、needs_changes、expired、restricted 五类治理反例
  6. 本地 knowledge_card workflow 可模拟回复、解析结构化 --reply-text、人工 review，并只允许 reviewed 卡片提升到 Knowledge/Site
  7. personal、department、project 三类 Ask Router route 与 review/promote 已先经过 OntologyToolGateway，并把 pending/reviewed/promoted lifecycle 写入 ontology registry
  8. promoted card 已可投影为 ContextDocumentRecord，并通过 Knowledge Card Tool Gateway 接入 reindex/search、本地 reindex queue 和 ontology registry，14 个 Knowledge Card gateway cases 与 10 个 Ontology Tool Gateway cases 100% 通过，覆盖对象 ID、owner、source_uri、路径、rank_log 存在性计数、错误路径、review/promote lifecycle、queue safe output 泄漏、ontology scope gate 和 registry lifecycle

下一步

  1. 增加真实团队问题，并把 owner registry 接入企微通讯录，把 route_ask_request / AskFeedbackEvent 接入企微发送/回调身份、签名 header、消息 ID、会话 ID、送达状态、Connector Callback Ledger 和 gateway conformance

入口： Ask Router Simulation, Knowledge Card Review 闭环, Knowledge Card Tool Gateway

企业微信入口

当前状态： P0 Bot WS 最小通道已通过真实企业微信验证；正式路线已修正为人机实时交互（生产优先 Bot URL 回调，开发/回归保留 Bot WS 长连接）+ 显式知识提交 MVP（@Bot / 私聊 Bot / 转发 Bot / 指定文档日报）+ 用户上传文件 + 企微云盘/微盘/腾讯文档/群文件/团队文件空间 + 自建应用/API + 文档/日报 + 腾讯会议；会话内容存档降级为全量被动采集、历史回溯和合规审计增强项；自建应用 synthetic callback scaffold 已新增；飞书 Bot 能力对标已整理为企微团队上下文路线图；企微云盘/文件空间已补为独立文件 Evidence 入口，细接口能力待官方/后台验收

已完成

  1. 已把 PR #48、Hermes Agent WeCom 实现、官方 Bot WS 长连接契约和当前管理员协作事实沉淀到 Evidence、Knowledge、ADR 与 connector contract
  2. 新增 scripts/wecom_bot_ws_smoke.py，可用真实 Bot ID/Secret 建立长连接、等待单聊或群 @回调、固定回复 1 并写入脱敏报告
  3. 本地未跟踪 .env.wecom.local 已验证被 .gitignore 忽略
  4. 2026-06-16 实测已完成订阅、单聊回调、群 @回调、两次固定回复和两次 reply ack，并已在一台全新的、uv 管理的 Ubuntu 开发服务器（clone + uv 接管 Python + aiohttp==3.14.1 运行依赖 + uv sync 全量开发依赖 + 个人工作分支 alpc91/wecom-dev + 仅环境变量凭证）上从零复现同一 P0 结论，验证 Bot WS 通道的环境可重建性 / 可移植性
  5. 真实 body payload 已可投影为内部消息事件和 callback ledger 安全登记请求
  6. 两份 2026-06-16 WeCom 正式路线与 WireGuard 调研报告已进入 raw Evidence、Evidence Registry、项目计划和发布站点摘要
  7. 自建应用 callback scaffold 已新增 contract、helper、synthetic fixture、conformance wrapper 和单测，覆盖 URL verification、POST 验签解密、safe projection 和 callback ledger request
  8. 本轮已把文档、ADR 和站点摘要修正为主动知识沉淀 MVP 路线：Bot URL 回调/WS 负责人机实时交互，自建应用/API 负责企业系统能力，@Bot / 私聊 Bot / 转发 Bot / 指定文档日报作为默认入库策略，会话内容存档仅作为全量被动采集增强项
  9. 本轮进一步阅读 Hermes Agent Feishu gateway、drive comment、meeting invite、doc/drive tool、配置文档和测试，把 WebSocket/webhook 双入口、URL verification/signature/token、group policy、require_mention、bot-sender admission、group_sessions_per_user、资源下载、reaction/status、comment event 详情回查和文档工具作用域提炼为企微实现参考
  10. 本轮把企微云盘/微盘/腾讯文档/群文件/团队文件空间设计成独立文件 Evidence 入口，补齐 drive_space/folder/file/version/permission_view/source_ref/parser_status/checksum/retention_policy/downstream_artifacts 对象模型、索引优先存储、临时下载解析后删除和 restricted Site 阻断
  11. 本轮已把 P1.5 显式知识沉淀的代码核心在 WS 入口落地，并验证入口无关管线可复用于未来回调入口：新增入口无关准入层 framework/governance/connector_admission.py 与 framework/governance/connector_dedup_registry.py（require_mention / self-echo / allowlist / 跨源去重只存 hash + TTL / 频控，WS 与未来自建应用回调共用），扩展 framework/workflows/schedule_todo_assistant.py 与 framework/workflows/knowledge_card.py 把 ready 工作项草拟为 review_status=pending 的 Knowledge Card（pending_confirmation 不自动出卡），新增端到端管线 framework/workflows/wecom_message_pipeline.py（WeComMessageEvent → evaluate_admission → Connector Callback Ledger → Evidence 登记 → run_schedule_todo_assistant → Knowledge Card 草稿，脱敏 run_to_dict/render_report，leak_marker_count=0），补测 framework/connectors/wecom/callback.py 的 callback_event_to_message_event 完成回调入口归一，新增实时捕获脚本 scripts/wecom_bot_ws_capture.py（复用 smoke 连接/订阅/收帧循环，每条入站消息内存中跑管线，把“只回复 1”升级为“沉淀 Evidence + 起草知识卡”，凭证仅环境变量、脱敏 hash/计数只写 /tmp、证据目录 /tmp 前缀硬护栏、绝不写被跟踪路径）和离线 demo scripts/wecom_message_pipeline_demo.py（产物在 workspaces/variai/outputs/wecom-message-pipeline-*）
  12. 新增 21 个测试，全量回归 400 passed / 2 skipped / 0 failed（基线 379），architecture_alignment / package_boundary / secret_fixture / evidence_registry lint 全绿，全部 synthetic fixture + 单测、无真实数据
  13. 2026-06-17 在新服务器复测 P0 实时捕获（真实「变分小组」群 @机器人 → WS 捕获 → 回复，通），并把显式知识沉淀的「抽取」一步从规则启发式转为 Claude-LLM：新增可插拔 Claude 客户端 framework/llm/claude_client.py（鉴权可插拔 + 模型/effort 可配 + 结构化输出薄封装）与开发中的抽取组件 framework/llm/work_item_extractor.py（确定性解析 + 接管线、替换规则启发式），并用独立 demo scripts/wecom_capture_llm_demo.py 在真实群里跑通「反问 → @ 澄清 → 补全登记待办」的 ask-confirm 闭环
  14. 负责人身份由确定性代码按花名册解析、LLM 只产出 owner_mention（详见 ADR-041）。

下一步

  1. P1.5 显式知识沉淀代码核心已在 WS 入口离线落地、入口无关管线可复用于未来回调入口
  2. 抽取已转 Claude-LLM（确定性解析兜底），下一步把 framework/llm 的 LLM extractor 正式接进 wecom_message_pipeline 默认抽取步（规则保留 fallback）并补单测/脱敏 fixture，接通 Ask Router 闭环让低置信/负责人未解析工作项 ask-to-confirm，接真实通讯录替换合成花名册数据源（synthetic_roster_from_directory），生产改用专用 API key + raw SDK 跑 Sonnet/Opus
  3. 同时待团队成员 @机器人 时实跑 scripts/wecom_bot_ws_capture.py 做真实 @捕获验收（确认入站消息在线沉淀 Evidence 并起草知识卡）
  4. 用户回来按 runbook 配置后台后点亮 P1 智能机器人 Bot URL 回调与 P2 自建应用/API，把入口无关管线接到生产入口
  5. 可选后续离线增量是接入 Ask Router 让低置信工作项 ask-to-confirm，并补 P2 回调 HTTP handler 代码
  6. 此外仍保留旧有计划：实现准入层（用户/群 allowlist、群 policy、require_mention、bot-sender admission、去重/retry、按人 group session 与共享项目上下文分离）、Bot WS 接入运行时（把 WeComMessageEvent 接到 Evidence Registry、Ask Router、Knowledge Card 和 Tool Gateway）和自建应用 callback handler（把不联网 scaffold 接到真实公网 HTTP handler）
  7. 待公网就绪后再在企微后台配置智能机器人 URL 回调并完成公网 verification、单聊 Bot、群里 @Bot、被动回复和已保存 chatid 主动群消息边界验收
  8. Bot WS 保留为开发/回归入口
  9. 固化团队显式知识提交约定，并把 @Bot、私聊 Bot、转发 Bot、指定文档/日报入口接到 Evidence Registry、Ask Router、Knowledge Card 和 Tool Gateway
  10. 补准入层的 allowlist、group policy、require_mention、bot-sender admission、去重/retry、group session per user 与 shared project context 分离
  11. 另行配置自建应用 CorpID/AgentID/Secret、可信 IP、回调 URL、Token、EncodingAESKey、通讯录/文档/应用消息/会议权限，并把当前 scaffold 接到真实公网 HTTP handler、access_token、应用消息和通讯录最小闭环
  12. 对企微云盘/微盘/腾讯文档/群文件/团队文件空间做官方/后台验收，确认创建/绑定空间、列目录、读 metadata、下载文件、订阅变更事件和权限摘要能力
  13. 先用 synthetic 团队空间、个人授权目录、群文件和上传文件验证 metadata 索引、hash/版本登记、parser status、临时下载后删除和 restricted Site 阻断
  14. 飞书对标里的文档评论/变更、任务、日历/会议、reaction、文件、邮件或企微替代对象事件均先标为待官方/后台验收
  15. 会话内容存档小范围试点、员工告知、RSA 公钥和 SDK 拉取/解密 smoke 已完成，后续只推进媒体下载、seq/cursor checkpoint、restricted Evidence schema/redaction guard 和审计。

入口： MVP 开发计划, WeCom Bot Local Demo, 企微分层接入方案, 飞书 Bot 对标路线图, ADR-040（当前正式路线）, ADR-039（历史 Bot WS smoke）

Tool Gateway / MVC

当前状态： 最小 safety harness、SearchConnector、Knowledge Card 工具、ontology action policy、外部 Connector action contract 和 callback ledger 接入完成，真实外部 API 未接

已完成

  1. 9 个本地 Tool Gateway safety cases 全部通过
  2. SearchConnector 已作为 context.search、context.get_document、context.report_gap 接入 Tool Gateway，7 个 conformance cases 全部通过，已验证 stale_index=true 时 runtime 阻断 hits、暴露安全 rank_log 字段，并记录复用 Projection Remediation item id 的 high severity reindex/gap receipt
  3. Projection Remediation Eval 已把关键风险 block_and_report_gap 接到统一补证 item、本地 worker event 和 Semantic Review handoff
  4. Knowledge Card reindex/search/review/promote 已接入 Tool Gateway，14 个 conformance cases 全部通过，search/reindex/queue/registry safe output 不泄露对象 ID、owner、source_uri、路径、rank_log 存在性计数、错误路径或内容 marker，且 review/promote 经过 OntologyToolGateway，queue processing 缺少 ontology required_scopes 时不会运行 worker
  5. Ontology Tool Gateway Conformance 10/10 通过，已验证 personal、department、project 三类 ask action、ontology action 到 ToolPolicy 的映射、required_scopes 缺失拒绝、按 action type 判断 lifecycle、rule 未覆盖对象拒绝和 audited writeback 要求
  6. External Connector Action Gateway 6/6 通过，合成企微、GitHub 和 CRM action 均先过 Tool Gateway，允许或 draft-only 后只写安全 writeback，4 条 writeback events 已投影到 project status event timeline，safe output / writeback / audit payload 不泄露原始消息 ID、会话 ID、URL、owner、PR/commit 或业务对象 ID
  7. Connector Callback Ledger 6/6 通过，2 条有效回调安全落 ledger 并生成受限 Evidence source/raw snapshot，ontology registry 写入 ledger-connector-callback state=recorded 且 event_count=1，并已投影到 project status event timeline，1 条重复回调被幂等抑制，3 条无效签名、过期时间戳或缺字段回调被拒绝，safe output / ledger event 未泄露原始消息 ID、会话 ID、URL、owner、run_id 或 commit sha
  8. workspaces/variai/registry/knowledge-card-reindex-queue.json 已作为本地 JSON 队列状态原型，Ask Router、review/promote 和 queue worker 前后 lifecycle 已写入 ontology registry
  9. No-WeCom MVP Demo 中 ask_ontology_action=allow、ask_registry_event_count=2、callback Evidence source=1、registry_error=0、feedback_event_ref=1、knowledge_card_ref=1、review_ontology_action=allow、promote_ontology_action=allow、knowledge_card_registry_event_count=6、reindex_queue_ontology_action=allow、reindex_queue_registry_event_count=8，pending/rejected/needs_changes/expired 卡片检索命中为 0，restricted card 对 team 用户命中为 0，team 用户请求 restricted scope 被 deny

下一步

  1. 把企微通讯录、投递和回调 adapter 接到当前 Ask Router topology binding、owner registry contract、External Connector Action Gateway 和 Connector Callback Ledger 后面
  2. 把 worker retry、semantic review、GitHub Actions live adapter 和真实企微 callback 接入同一 project status event timeline，并继续扩展 registry 事件、timeout/retry/idempotency、签名 header、source-system permission 和真实增量 adapter 状态的泄漏检查

入口： 风险驱动验证计划, Tool Gateway Safety Harness, SearchConnector Tool Gateway, Projection Remediation Eval, Knowledge Card Tool Gateway, Ontology Tool Gateway, External Connector Action Gateway, Connector Callback Ledger, 权限视图与 MVC

3. 实验与验证中心

查看哪些技术判断已经通过实验、Demo 或 benchmark 验证，以及当前仍需关注的风险面。

展开：3. 实验与验证中心

3.1 实验结论导航

所有实验、Demo 和 benchmark 都从同一个 registry 生成，用来支撑技术判断和研发优先级。

实验 架构主线 Owner 有效性 / 最近检查 / 复查周期 Cost 风险 问题 当前结论 报告
Context Router Demo Runtime Projection context-routing 观察中
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 low 路由是否能减少无关上下文 路由能选中预期上下文库并节省约 12.9% prompt token，但这个结论价值有限；后续重点转向风险验证 Context Router Demo
Ingestion Quality Demo Evidence
Ontology		 ingestion 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high 入库清洗会不会丢事实 naive summary 事实召回 19%，structured ingestion 事实召回 100%；当前已先生成 8 条 Evidence source 和 raw snapshot，再投影为 ContextDocumentRecord Ingestion Quality Demo
Retrieval Platform Benchmark Runtime Projection search 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high 检索如何避免权限、删除、旧新冲突和 gap 错误 只做 ACL 不够，必须同时做 permission、lifecycle、confidence threshold 和 gap 判断 Retrieval Platform Benchmark
SearchConnector Conformance Runtime Projection search 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 medium 真实检索 adapter 是否遵守最低安全和可解释 contract in_memory 与 sqlite_fts 两个 connector 共 14 个 conformance cases 全部通过；Postgres/OpenSearch adapter skeleton 已接入可选注册，后续必须用真实服务复用同一验收集 SearchConnector Conformance
Search Adapter State Benchmark Runtime Projection search 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high 真实检索投影 adapter 接入前，删除传播、权限变更、supersede 和 reindex 延迟会造成哪些 stale-index 风险 4 个 Search Adapter State Benchmark cases 全部通过；adapter matrix 覆盖 sqlite_fts、postgres_fts、opensearch，其中默认 CI 运行 sqlite_fts，Postgres/OpenSearch 在未配置 DSN/URL 时标记为 skipped_unavailable；删除、权限降级、supersede 的 stale-index window 均被检测，reindex 前暴露 3 个 stale hit，reindex 后 4/4 恢复安全；rank_log 已包含 generation、stale_index、过滤计数、adapter id、adapter kind、latency 和 cost units Search Adapter State Benchmark
SearchConnector Tool Gateway Runtime Projection tool-gateway 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high SearchConnector 是否已经作为工具能力进入 Tool Gateway 调用路径 7 个 SearchConnector Tool Gateway cases 全部通过；已验证 scope escalation 拒绝、namespaced scope、不安全 connector 输出过滤、rank_log 清洗、stale_index 运行时阻断、high severity gap receipt 复用 Projection Remediation item id，safe output 不泄露 source_uri SearchConnector Tool Gateway
Context Router Stale Policy Eval Runtime Projection context-routing 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high Context Router 是否能按任务风险处理 stale_index 候选上下文库 4 个 Context Router Stale Policy cases 全部通过；低风险 stale context 可 allow_with_notice 并进入 selected context，中/高/关键风险 stale context 默认不进入 Agent prompt，分别要求人工确认、等待 reindex 或 block_and_report_gap；safe trace 泄漏标记为 0 Context Router Stale Policy Eval
Projection Remediation Eval Runtime Projection search 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 critical 关键风险 stale projection 被 block 后，是否能进入统一补证、reindex 和人审路径 Projection Remediation Eval 3/3 通过；关键风险 stale projection 会生成 queued_for_reindex 补证 item，本地 worker 可将 adapter result 转为 reindexed，也可在 waiting 超时后记录 timeout、进入 retry_scheduled、到期重开 attempt 并轮换 idempotency key；第二个 worker 不能抢占 active lease，错误 lease token callback 被拒绝且不改变状态；worker events=7，同步生成 pending Semantic Review handoff；safe output 泄漏标记为 0 Projection Remediation Eval
Knowledge Card Tool Gateway Ontology
Runtime Projection		 knowledge-card 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high review 后的 knowledge card reindex/search 是否已经进入 Tool Gateway 调用路径 14 个 Knowledge Card Tool Gateway cases 全部通过；已验证 team search、scope escalation 拒绝、restricted card 不泄露、reindex 治理权限、review/promote 经过 OntologyToolGateway、本地 reindex queue 增量处理、queue processing 经过 OntologyToolGateway required scopes gate，review/promote 与 queue worker 前后态写入 ontology registry，以及 search/reindex/queue/registry safe output 不泄露对象 ID、owner、source_uri、路径、rank_log 存在性计数、错误路径或内容 marker Knowledge Card Tool Gateway
Ontology Tool Gateway Conformance Ontology
Runtime Projection		 ontology 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high ontology action 是否已经进入 Tool Gateway 调用前的治理决策 10 个 Ontology Tool Gateway conformance cases 全部通过；已验证 personal、department、project 三类 ask action、ontology action 到 ToolPolicy 的映射、required_scopes 缺失拒绝、按 action type 判断对象 lifecycle、rule 未覆盖对象拒绝和 audited writeback 要求；Ask Router binding 已进入 workspace-topology.json，route_ask_request_guarded 可按 topology task/context-library mapping 选择 action 与对象状态；OntologyToolGateway 已接入三类 Ask Router route 以及 Knowledge Card review、promote、reindex queue 的本地执行路径，pending card 可以 ask/review，reviewed card 可以 promote，queue worker lifecycle 已写入 ontology registry Ontology Tool Gateway Conformance
Workspace Scope Eval Ontology
Runtime Projection		 workspace-topology 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high 同一套 Framework 能否同时服务个人、部门、项目三类私域，并阻断跨域泄漏 personal、department、project 三类基础 demo 和 4 个风险探针全部通过；Workspace Scope Eval 已接入 context_router_feature_v1，7/7 输出 Context Router score log，24 个候选输出 feature breakdown；三个基础 demo 已引用 ontology contract，覆盖 object=7、rule=5、action=7、writeback=3；完整 topology contract 已扩展到 callback ledger object/writeback；故意不安全 connector 的 9 个越权候选输出被 Tool Gateway 过滤，safe output 泄漏标记为 0 Workspace Scope Eval
Context Router Feedback Eval Runtime Projection context-routing 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high Context Router 能否从人工纠错事件中改进下一轮上下文库排序，同时不绕过权限 2 个 Context Router feedback cases 全部通过；workspace structure 组织问题可从 org_directory 纠正到 project_orgreorg_knowledge；财务上下文即使被反馈标记相关，也仍被项目维护者 permission view 过滤 Context Router Feedback Eval
Real Team Context Benchmark Runtime Projection context-management 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high 真实团队讨论里暴露的问题，是否已经进入 Context Router、source closure、Connector 边界和权限过滤回归集 5 个真实团队问题回归 case 全部通过；site/knowledge/evidence、Roadmap、公众号临时链接和 connector 边界问题均路由到 project_orgreorg_knowledge；财务上下文对 project-maintainer 被 permission view 过滤；16 个本地文档 marker 检查通过 Real Team Context Benchmark
Context Management Eval Runtime Projection context-management 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 medium 上下文管理是否能同时观察任务质量、token 成本、权限过滤和知识缺口 4 个 Context Management cases 全部通过；已用 context_router_feature_v1 生成 route trace 和 12 个候选 feature breakdown；已用 route_ask_request 生成 ask message、ask trace 和 pending knowledge card；平均 token 节省 24.6%，权限过滤候选数 4，router 权限过滤库数 4，trace event 数 9，SearchConnector rank_log case 数 4，gateway filtered output 数 4，knowledge gap 数 1，ask event 数 1，safe output 泄漏标记为 0 Context Management Eval
No-WeCom MVP Demo Evidence
Ontology
Runtime Projection		 mvp-runtime 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 critical 没有企业微信接口时，本地 MVP 是否能跑通完整主链路 无企微端到端 MVP smoke 通过：初始 owner=finance-owner，ask_ontology_action=allow，ask_registry_event_count=2，Context Router 可从 baseline org_directory 纠正到 project_orgreorg_knowledge 且 feedback_applied=2，callback ledger recorded=1、duplicate=1、rejected=1、leak=0，callback Evidence source=1、registry_error=0、feedback_event_ref=1、knowledge_card_ref=1，问错人 feedback event=1，纠错后 owner=crm-owner，reviewed，review_ontology_action=allow，promote_ontology_action=allow，knowledge_card_registry_event_count=6，reindex_queue_status=ready_for_reindex，reindex_queue_ontology_action=allow，reindex_queue_registry_event_count=8，reindex_queue_indexed=1，reindex_queue_search_hit=1，reindex_queue_safe_output_leak=0，indexed=1，search_hit=1；5 个治理探针通过，blocked_probe_hit=0，restricted_team_hit=0，restricted_user_hit=1，team restricted-scope 请求被 deny，restricted leak marker=0 No-WeCom MVP Demo
Context Layer Benchmark Runtime Projection context-architecture 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 medium 渐进披露、RAG、分层混合谁更稳 当前样例里 tiered_hybrid 最稳；单用 D2、单用 D3 都有明显边界 Context Layer Benchmark
Agentic Search Option Benchmark Runtime Projection search 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 medium P0 到底先用 Postgres、ES 还是向量库 P0 默认 Markdown + Postgres FTS/pgvector；OpenSearch/ES 后置为规模化 adapter；纯向量库不作为核心默认 Agentic Search Option Benchmark
Ask Router Simulation Ontology
Runtime Projection		 ask-router 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 high 证据不足时问谁、怎么问 9 个合成场景中 Top1、Recall@3、安全路由、负反馈、节流和消息契约均为 100%，重复询问抑制数 1；AskFeedbackEvent 已支持 better_owner / not_owner 回复写入本地事件流并影响下一轮路由；owner registry 已统一为显式目录优先、Workspace Topology fallback Ask Router Simulation
Task Skill Package Eval Ontology task-skills 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 medium 任务技能包是否会误触发、膨胀或过期 progressive_manifest_guarded 当前样例 100% 通过，平均 token 比 all-in 降约 95%；正式包必须有 manifest、negative_terms、status、verify 和安全字段 Task Skill Package Eval
Tool Gateway Safety Harness Runtime Projection tool-gateway 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 critical MCP/Connector 工具边界是否能强制 schema、权限、审批、外连和输出净化 9 个 Tool Gateway safety cases 全部通过；已验证 schema hash、scope、R4 approval、R3 draft-only、SSRF/egress、输出脱敏和审计不泄密 Tool Gateway Safety Harness
External Connector Action Gateway Runtime Projection tool-gateway 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 critical 外部 Connector action 接入后，是否能强制 Tool Gateway、safe writeback 和泄漏边界 6 个 External Connector Action Gateway cases 全部通过；允许或 draft-only 的 4 个 case 写入安全 writeback 并投影到 project status event timeline；缺 scope 和缺 approval 的外部动作不写成功事件；safe output / writeback / audit payload 未泄露原始消息 ID、会话 ID、URL、owner、PR/commit 或业务对象 ID External Connector Action Gateway
Connector Callback Ledger Evidence
Ontology
Runtime Projection		 tool-gateway 有效
2026-06-14 检查
14 天后复查		 zero
local_python
no-paid-api		 critical 外部 Connector 回调进入系统时，是否能签名校验、幂等去重、安全落 ledger，并避免源系统对象泄漏 6 个 Connector Callback Ledger cases 全部通过；2 条有效回调安全落 ledger 并生成受限 Evidence source/raw snapshot，1 条重复回调被幂等抑制，3 条无效签名、过期时间戳或缺字段回调被拒绝；ontology registry 记录 ledger-connector-callback state=recorded、event_count=1；safe output / ledger event 未泄露原始消息 ID、会话 ID、URL、owner、run_id 或 commit sha Connector Callback Ledger
File Evidence Ingestion Demo Evidence
Ontology		 evidence-ingestion 有效
2026-06-15 检查
14 天后复查		 zero
local_python
no-paid-api		 high 共享文件空间上传物能否先成为 Evidence，再按解析状态进入知识投影 6 个 synthetic 上传物全部 Evidence-ready；2 个 Knowledge-ready，2 个 pending_parse，1 个 needs_review，1 个 unsupported；restricted 文件 2 个且均携带 PII 或 field mask；leak marker=0 File Evidence Ingestion Demo
Schedule / Todo Assistant Demo Runtime Projection
Evidence		 workflow 有效
2026-06-15 检查
14 天后复查		 zero
local_python
no-paid-api		 medium 散落在企微消息里的待办和日程能否被抽取、去重并生成待确认项 5 条消息投影出 4 个事项，其中 todo=2、calendar=2、ready=3、needs_confirmation=1、merged_source_count=1、leak marker=0 Schedule / Todo Assistant Demo
WeCom Bot Local Projection Demo Runtime Projection
Evidence		 wecom 有效
2026-06-15 检查
14 天后复查		 zero
local_python
no-paid-api		 high 企微 AI Bot 回调帧能否被本地投影成内部消息事件，并复用工作流抽取 frame_count=4、projected_message_count=3、skipped_frame_count=1、duplicate_message_count=0、schedule_candidate_count=3、schedule_ready_count=2、needs_confirmation=1、leak marker=0 WeCom Bot Local Projection Demo

3.2 风险验证摘要

这里按风险类型聚合实验结论，方便先看风险面，再进入具体报告。

风险类型 当前验证依据 主要看点
入库清洗风险 Ingestion Quality Demo naive summary 会丢事实，结构化 ingestion 必须保留 Evidence source 和 raw snapshot。
检索权限与旧材料风险 Retrieval Platform Benchmark, Search Adapter State Benchmark 不能只追求 recall，必须处理权限、删除、supersede 和 stale index。
主动询问问错人风险 Ask Router Simulation, No-WeCom MVP Demo owner registry、反馈事件和节流机制必须先于真实企微投递稳定。
Tool Gateway / Connector 安全风险 Tool Gateway Safety Harness, External Connector Action Gateway, Connector Callback Ledger 外部动作、回调和 writeback 必须经过 scope、审批、签名、幂等和脱敏边界。
自动化卡住风险 Projection Remediation Eval, Semantic Review Queue 自动流程必须有退出条件、handoff 条件和人工接管记录。

4. 自动化闭环与待处理项

给维护者和 reviewer 查看自动化 loop、人工待处理事项和系统事件；普通成员可以按需跳过。

展开：4. 自动化闭环与待处理项

4.1 人工 Review Queue

这里记录机器检查不能替代的人审事项；普通成员可跳过，维护者和 reviewer 需要关注。

当前语义 review item：1 个；reviewer event：1 个；pending：1 个；blocked：0 个。

Review 状态 优先级 Owner Handoff 最后操作 证据
semrev-loop-engineering-currentness 确认 Loop Engineering 页面与当前 Review Queue 口径仍一致 pending P0 knowledge-maintainer requires_human_review_for_semantic_staleness review_requested by codex
2026-06-17T00:00:00Z		 loop-engineering.md

4.2 系统事件 Timeline

Timeline 是机器事件流，不是日报。当前结构化事件：0 个。

时间（北京时间） 来源 Process Event Object 状态变化 Actor Source Ref
- - - - - - - -

5. 真实问题与踩坑记录

沉淀开发和试用过程中真实遇到的问题，并把它们转成可复盘、可复跑、可验证的经验和测试资产。

展开：5. 真实问题与踩坑记录

5.1 真实问题处理流程

真实协作中暴露的问题、误解、失败构建、权限担忧、问错人反馈、成本异常和 Agent 循环卡点，都是 Harness 的一等 Demo/Case 输入。处理这些问题时，不是停留在旧问题上循环，也不是为了展示效果临时编一个 toy demo，而是把真实问题转成可追溯、可脱敏、可复跑、可验证的研发样本。

  1. 触发：团队讨论、企微消息、共享文件空间上传、GitHub/Cloudflare/CI 报错、人工 review、实验失败或用户反馈暴露一个真实问题。
  2. Evidence：只保留必要原始线索、source class、时间、路径、hash、稳定检索关键词、解析状态和权限/脱敏标记；短期 token、cookie、完整截图、完整私聊和个人敏感信息不进入发布层。
  3. Ontology：把问题抽象成对象、关系、规则、Skill、Workflow、权限视图、ADR、实验报告、Semantic Review item 或 Knowledge Card。
  4. Runtime Projection：把抽象后的问题变成本地 demo、benchmark、conformance case、CI gate、review queue、dashboard event 或 task-skill feedback，并记录验证目的。
  5. Review：由对应 reviewer 判断它是真缺陷、设计取舍、文档缺口、外部依赖限制还是后续接真实 adapter 的 handoff。
  6. Publish：只发布脱敏结论、工程验证结果、成本/效果指标和下一步；必要时链接回受控 Evidence 或 registry，保证可审计但不泄密。

5.2 当前踩坑样本

Case Source class Runtime projection Verification purpose
GitHub Actions / MkDocs / Cloudflare 构建失败 CI / 发布系统反馈 GitHub Actions Run Ledger、Retry Policy、项目 Timeline 和 CI gate。 验证失败摘要、自动重试预算、人工 review handoff 和发布状态可观测。
GitGuardian 告警 安全扫描告警 secret lint、发布前脱敏检查和安全边界 case。 验证 Framework 能阻止 token、完整日志、完整 SHA 或敏感路径进入发布层。
微信临时链接追溯失败 外部资料链接不稳定 External Source Closure 规则和 no_further_search 状态。 验证没有稳定外链时也能完成知识沉淀，避免 Agent 因追不到未来失效链接而循环。
Agent 在同一点重复处理 人机协作过程反馈 LoopSpec、Semantic Review Queue、runtime refresh plan 和 handoff 条件。 验证 loop 有退出条件、可交接状态和继续研发的 Roadmap 入口。

5.3 已形成的经验规则

  • 进入 demo 的 case 必须写清真实来源类型、脱敏边界和工程验证目的；例如 CI 构建失败、GitGuardian 告警、Cloudflare 部署配置、GitHub Actions 状态、临时外链追溯失败和 Agent 重复循环，都只能保留脱敏后的工程信号。
  • 真实 case 只能作为研发样本，不等于要反复处理同一个旧问题；一旦形成 case，就应由可复跑检查和 Review Queue 接管。
  • Framework 层只能沉淀通用 contract、工具、模板和检查逻辑；当前工作空间私域事实留在 Registry/Evidence/Knowledge，不进入未来可打包框架。
  • 发布网站只展示团队可读、客户安全、可复核的摘要；原始 Evidence、内部路径和权限细节按最小必要原则披露。

落盘和停止规则：

Stage 写入位置 产物 退出 / 接管条件
Capture workspaces/variai/evidence/inbox/ 或 workspaces/variai/evidence/raw/ 保留来源类型、时间、稳定检索线索、hash、权限标签和脱敏说明。 足以追溯问题来源，但不保留短期 token、cookie、完整私聊、完整截图或完整日志。
Compile workspaces/variai/knowledge/wiki/、workspaces/variai/knowledge/projects/、workspaces/variai/knowledge/decisions/ 或 workspaces/variai/registry/*.json 抽象成 Evidence、Ontology 对象、关系、规则、Skill、Workflow、ADR、Knowledge Card 或 Semantic Review item。 团队能判断这是缺陷、设计取舍、文档缺口、权限边界、外部依赖限制还是 adapter handoff。
Project framework/、tests/、workspaces/variai/outputs/、workspaces/variai/site/knowledge/ 或 CI gate 变成可复跑 demo、benchmark、conformance case、safe report、dashboard event 或 review queue event。 复跑检查和生成报告能说明效果、成本、失败模式和剩余 handoff。
Stop looping workspaces/variai/registry/semantic-review-queue.json 或对应 source registry 记录 handoff、review owner、退出条件和下一次重新打开该 case 的触发条件。 除非出现新证据，否则 Agent 不再反复回到同一封邮件、截图、临时链接或旧日志。

6. 附录：导航与术语

提供继续阅读入口、关键决策索引和缩略词解释，避免团队成员看不懂页面中的工程术语。

展开：6. 附录：导航与术语

6.1 继续阅读

这些入口用于从研发进度页跳到教程网站的关键专题；具体章节里已经放过的细节链接不在这里重复展开。

  1. 项目首页
  2. MVP 开发计划
  3. 本体驱动上下文架构
  4. Framework / Workspace 解耦
  5. Agentic Search
  6. 主动信息收集
  7. Tool Gateway
  8. Loop Engineering
  9. 决策记录

6.2 决策记录

ADR 用来追溯重要架构和产品决策。这里保留索引，详细内容进入决策记录页。

决策 内容 入口
ADR-012 历史采用多级上下文存储；已由 ADR-037 校准为运行时 D0-D5 披露路径 决策记录
ADR-013 Agentic Search P0 默认采用 Postgres，规模化保留 ES/OpenSearch 决策记录
ADR-014 采用自试用自演进知识沉淀闭环 决策记录
ADR-015 历史引入轻量任务技能包；已由 ADR-037 校准为本体层可执行知识对象 决策记录
ADR-016 采用团队项目 Repo 作为产品 MVP 形态 决策记录
ADR-017 框架与领域知识解耦，支持未来产品打包 决策记录
ADR-018 前置建立 framework/domain 基础结构与打包清单 决策记录
ADR-019 迁移实现代码到 framework，scripts 只保留 wrapper 决策记录
ADR-020 采用结构化 project_status 生成研发进度页 决策记录
ADR-021 先定义 SearchConnector contract，再实现真实检索 adapter 决策记录
ADR-022 采用 workspace blueprint 作为产品化工作空间契约 决策记录
ADR-023 采用 experiment_report 作为实验导航唯一来源 决策记录
ADR-024 采用 task_skill_usage_log 作为任务技能包运行反馈源 决策记录
ADR-025 采用本地 task_skill_runtime 作为企微前运行替身 决策记录
ADR-026 采用 orgreorg_demo 作为企微前本地 MVP 运行闭环 决策记录
ADR-027 采用 knowledge_card workflow 作为企微前回复与 review 替身 决策记录
ADR-028 将 reviewed knowledge card 投影到 ContextDocumentRecord 决策记录
ADR-029 采用本地 knowledge card reindex 替身连接本体 review 与检索投影 决策记录
ADR-030 采用本地 Tool Gateway safety harness 作为 MCP/Connector 安全门禁 决策记录
ADR-031 将 SearchConnector 作为 Tool Gateway 后面的检索工具族 决策记录
ADR-032 将 Knowledge Card reindex/search 纳入 Tool Gateway 决策记录
ADR-033 采用 Workspace Topology 作为组织私域路由和隔离契约 决策记录
ADR-034 Ask Router route 必须经过 OntologyToolGateway 决策记录
ADR-035 Ask Router binding 进入 Workspace Topology 配置 决策记录
ADR-036 采用 owner registry contract 连接主动询问与组织目录 决策记录
ADR-037 采用 Evidence / Ontology / Runtime Projection 作为项目主抽象 决策记录
ADR-038 采用 Evidence Registry 作为原始证据源契约 决策记录
ADR-039 企微先采用 Bot WS 最小通道，并并行准备全量接入 决策记录
ADR-040 企微正式接入采用主动沉淀 MVP 与会话存档增强分层 决策记录
ADR-041 知识抽取采用 Claude-LLM，并以确定性治理为底座（负责人解析确定性化、模型/后端可配、凭证不进 Git） 决策记录
ADR-042 企微助手检索采用 Claude Code Sonnet 大脑、MCP 检索和确定性门禁 决策记录
ADR-043 企微动作智能体采用护栏分层与对话上下文确定性解析 决策记录
ADR-044 本机 CPU 落地 ES 语义召回 Hybrid 检索 决策记录
ADR-045 站点迁自建应用工作台与权限投影铺垫 决策记录
ADR-046 自主知识沉淀与投影循环 决策记录
ADR-047 上下文充分性闸门与主动闭合缺口 决策记录

6.3 术语解释

如果团队成员不熟悉页面中的缩略词和工程术语，可以从这里反查。

  • P0 / P1 / P2：优先级分层。P0 是当前必须先跑通的核心闭环；P1/P2 是后续增强、平台化和规模化工作。
  • MVP：Minimum Viable Product，最小可行产品。这里指先跑通核心工作流，不等于最终完整平台。
  • ADR：Architecture Decision Record，架构决策记录，用来说明某个重要技术或产品决策为什么这样做。
  • Evidence：原始证据层，保存聊天、会议、文档、链接、代码和业务对象等可追溯来源。
  • Ontology：本体层，把 Evidence 抽象成对象、关系、规则、知识制品、Skill、Workflow 和权限视图。
  • Runtime Projection：运行时投影层，根据当前用户、任务和权限组合最小充分上下文给 Agent 使用。
  • D0-D5：运行时渐进披露路径，从当前任务、入口索引、稳定知识制品、检索投影到原始证据和主动补充。
  • Agentic Search：由 Agent 驱动的上下文查找和补证流程，不只是传统关键词或向量检索。
  • Tool Gateway：工具调用网关，用来统一做 scope、权限、审批、schema、输出净化和审计。
  • MCP：Model Context Protocol，用于把外部工具或上下文服务暴露给模型/Agent 的协议。
  • Connector：连接外部系统的适配器，例如企业微信、GitHub、CRM、文档系统或检索服务。
  • Loop：可追踪的自动化闭环任务，包含目标、状态、动作、验证信号、退出条件和 handoff。
  • Handoff：自动化流程不能继续自行完成时，交给人或真实 adapter 的明确交接条件。
  • Review Queue：人工待处理队列，用于记录机器检查不能替代的人审事项。
  • Timeline：结构化事件流，用来记录 CI、worker、callback、writeback 等系统状态变化。
  • Knowledge Card：从补充信息中形成的候选知识卡片，通常需要 review 后才能进入正式知识库或检索投影。
  • Framework / Workspace：Framework 是可复用产品底座；Workspace 是某个组织、部门、项目组或团队自己的 Evidence、Knowledge、Registry、Site、Connectors 和 Outputs。
  • CI：Continuous Integration，持续集成，用自动测试和构建检查提交是否健康。
  • MkDocs：当前发布教程网站的静态站点生成工具。
  • Cloudflare Pages：当前 ALPC91 镜像仓库 main 分支触发的网站发布平台。

如果某次讨论、实验或开发暴露了新问题，应该先更新结构化状态数据，再生成本页，并进入具体专题页和 ADR。