飞书 Bot 能力对标：企微团队上下文能力路线图

本页把用户提供的飞书自研 Bot 能力截图转成企业微信后续开发路线。截图只作为脱敏需求材料，不保存原图，不复制个人信息，也不把飞书能力直接等同为企业微信已具备能力。

核心结论：企微路线不应按“企微有没有某个接口”来排，而应按团队上下文产品场景拆成六条线：人机实时交互、显式知识提交、文件 Evidence 入口、主动收集事件、团队上下文构建、权限与 Evidence Registry。飞书截图里的关键边界同样适用于企微：事件通知只表示“有变化”，不是自动执行；事件要预注册；bot 身份和用户身份要区分；默认先拿元数据，详情必须再按权限调用对应 API；可见范围由群、会话、文档、云盘/文件空间、应用和成员授权共同决定。

入口分层先按产品事实建模：聊天记录采集、显式知识提交、用户上传文件、企微云盘/微盘/腾讯文档/群文件/团队文件空间、会议和业务系统是并列入口。文件空间不是聊天附件的附属能力；它要用独立的 drive/file 对象、权限视图、版本、hash、解析状态和下游产物生命周期。

对标口径

飞书截图能力层	企微产品目标	当前企微路线	当前状态
IM 被动响应：发消息、群聊、@、reaction	成员私聊 Bot、群里 @Bot、被动回复、主动提醒	智能机器人 Bot URL 回调 / Bot WS；自建应用 message/send	Bot WS 已 smoke；Bot URL 回调、自建应用真实发送待公网和后台验收；建群、拉人、reaction 事件待官方/后台验收
日历、任务、会议室	团队日程、会议、待办和资源占用进入上下文	腾讯会议 API/Webhook；日程/任务先用文档、智能表格、日报或业务系统替代	腾讯会议路线已有调研；企微日历、会议室、任务接口未在当前资料中确认，标为待官方/后台验收
云文档、Base、附件	指定文档、智能表格、企微云盘/微盘/腾讯文档/群文件/团队文件空间作为独立文件 Evidence 入口	企业微信文档、智能表格、微盘、OA 汇报 API；必要时腾讯文档 OAuth；文件空间 connector	官方链接已登记；真实读写、创建/绑定空间、列目录、读 metadata、下载、评论/变更事件和权限范围待后台验收
妙记、会议纪要、逐字稿、音视频	会议摘要、转写、录制和参会者进入 Evidence	腾讯会议云录制、转写/纪要 API 或 Webhook	条件可行；依赖企业会议账号、录制/转写开启和鉴权方式
群聊/邮件搜索、生成草稿	按权限检索历史协作材料，必要时生成回复草稿	显式入库 + 文档/日报/会议/文件入口；全量聊天靠会话内容存档增强；邮件待独立 connector	普通聊天不作为 MVP 默认采集；邮件能力待官方/后台验收
主动事件：@Bot、文档评论、邮件、表格变更、reaction	事件驱动地发现上下文变化，再决定是否补拉详情或生成 Knowledge Card	Bot 回调、自建应用回调、文档/表格/汇报/微盘轮询或待验证事件、会议 Webhook、会话存档增强	只把已验证 Bot 回调和已有 API 列为当前路线；细事件不编造，统一列待验

Hermes 飞书实现参考

本轮同时阅读了本机 Hermes Agent 的飞书实现，核心参考路径包括 /home/ai/.hermes/hermes-agent/gateway/platforms/feishu.py、feishu_comment.py、feishu_comment_rules.py、feishu_meeting_invite.py、tools/feishu_doc_tool.py、tools/feishu_drive_tool.py、飞书 messaging 文档、cli-config.yaml.example 和对应 gateway 测试。以下只提炼实现模式，不迁移任何 Hermes 配置值、凭证、真实用户标识或消息正文。

可复用到企微路线的模式：

• 双入口但同一消息通道：Hermes 飞书把 WebSocket 和 webhook 都收敛到同一 event handler；webhook 做 URL verification、verification token、签名、content-type、body size、rate limit 和 anomaly tracking。企微也应把 Bot WS、Bot URL 回调和自建应用 callback 归入统一 connector callback contract，入口不同，安全投影和 Evidence 入库一致。
• 准入管线先于 Agent：Hermes 在消息进入 Agent 前先做 self echo、bot-sender admission、DM bypass、group policy、require_mention、按群规则和 bot identity hydration。企微 P1/P2 也应先有 allowlist / group policy / require_mention / bot-sender / self-echo 等价策略，再接 Ask Router 或 Knowledge Card。
• 群会话默认按人隔离：Hermes 默认 group_sessions_per_user: true，避免同群成员共享上下文、审批和成本。企微群/项目上下文应区分“个人会话状态”和“群共享 Evidence”，群共享知识必须通过 review/promote 进入共享容器。
• 资源与富文本是能力矩阵，不是自由下载：Hermes 对 text/post/image/file/audio/media、reply/update、thread/topic、markdown fallback、message resource download、上传文件、processing reaction、dedup/retry 都有显式处理。企微路线需要先建 Tool Gateway capability registry，分别登记发送、回复、更新、附件上传/下载、媒体缓存、引用上下文和降级策略。
• 文档评论事件只做触发：Hermes feishu_comment.py 收到 drive.notice.comment_add_v1 后先过滤 self reply、receiver、notice type，再按文档规则和 pairing/allowlist 授权；随后并行查文档 meta 和 comment batch query，按 whole/local comment 构建 timeline，必要时做 wiki reverse lookup，最后由受限的 doc/drive toolset 生成回复。企微文档评论/变更即使后续确认可订阅，也应照此走“事件元数据 -> 权限 -> API 补详情 -> Evidence -> pending card/回复”的链路。
• 会议邀请也是合成消息，不是后台特权：Hermes 会议邀请 handler 只解析会议号、邀请人和会议主题，去重后转成发给邀请人的 synthetic DM event，仍进入正常准入和消息处理管线。企微/腾讯会议事件也应如此，不能绕过用户权限、审计或 Tool Gateway。
• 工具作用域跟触发上下文绑定：Hermes 飞书文档和云盘工具通过 comment handler 注入 client，只在评论会话里可用；这对企微意味着文档、微盘、会议、汇报工具不能变成全局任意读取能力，必须绑定 source、scope、permission view 和审计。

功能路线

1. 人机实时交互和被动响应

目标是让成员能在企微里直接把任务交给 Harness，并收到可审计回复。

• 私聊 Bot、群里 @Bot：生产优先智能机器人 Bot URL 回调；开发、smoke、回归保留 Bot WS。
• 被动回复：通过 Bot 回调绑定入站消息回复；长回复后续再做分片、markdown 降级、引用来源摘要、reply fallback 和失败可见状态。
• 主动提醒、补充询问、状态通知：默认走自建应用消息；Bot 主动群消息只作为补充能力，必须按已保存 chatid、群权限和频控单独验收。
• 建群、拉人、@人、reaction：飞书截图里是 IM 能力，但当前企微官方资料未在本仓库确认等价接口和事件范围，列为待官方/后台验收；可先用自建应用消息、Knowledge Card 按钮和显式回复替代 reaction/workflow 信号。

2. 显式知识提交

MVP 默认规则仍是“主动提交才入库”：

• 群里需要沉淀时 @Bot，并写清要记录的结论、任务、风险或待确认问题。
• 私聊 Bot 提交个人日报、问题、补充说明、会议结论或文件线索。
• 重要消息转发给 Bot，由 Bot 生成脱敏 Evidence 摘要和待 review Knowledge Card。
• 指定文档、日报、汇报、智能表格或微盘目录作为稳定入口，由自建应用/API 或相邻企业级 API 拉取。
• 未 @Bot、未转发、未写入指定入口的普通聊天，不进入 MVP 默认采集。

2.5 文件 Evidence 入口：企微云盘 / 团队空间

飞书 Drive、云文档、Base 和附件能力对企微的产品启发是：文件入口需要独立建模，而不是被归并成聊天附件。企微侧应把企业云盘、微盘、腾讯文档、群文件、团队/项目文件空间和用户上传文件作为并列文件 Evidence source。

文件空间对象模型：

• drive_space：部门、项目、群或个人授权的文件空间容器，记录 owner、scope、默认目录模板和 retention policy。
• folder：目录对象，记录父子关系、稳定 source ref、权限继承和用途。
• file：文件对象，记录脱敏标题、类型、大小、当前版本、permission view、parser status 和 downstream artifacts。
• version：版本对象，记录 version ref、mtime、checksum、actor hash 和 source ref。
• permission_view：当前用户、群/项目、部门、组织或 restricted 的可见范围。
• source_ref：可回查但不泄露真实 file id、真实路径、下载 URL、cookie 或 token 的稳定引用。
• parser_status：Evidence-ready、pending_parse、knowledge-ready、needs_review、unsupported。
• checksum、retention_policy、downstream_artifacts：用于去重、缓存、留存、解析文本、OCR、表格 schema、压缩包 manifest、代码索引和 Knowledge Card 追踪。

团队/项目空间创建：

• 后续需要支持按部门、项目或试点任务创建或绑定团队云盘空间，配置 owner、可见范围、默认目录模板、restricted 子目录和留存策略。
• 本仓库尚未确认企微是否可通过当前接口创建空间、绑定空间或设置目录模板，均标为“待官方/后台验收”。

个人/团队云盘拉取：

• 个人云盘只索引成员明确授权的目录或文件，默认不进入组织全局 RAG。
• 团队空间、群文件和共享目录只在 permission view 覆盖范围内索引、补拉和投影。
• 文件新增/变更事件如果无法订阅，先用指定目录轮询、用户显式提交或人工触发补拉替代。

存储与解析策略：

• 默认索引优先，原件留在企微云盘、微盘、腾讯文档或团队空间；服务器只保存脱敏 metadata、稳定 source ref、权限、checksum、版本摘要、parser status、downstream artifacts 和必要缓存。
• 大文件临时下载到服务器解析，处理完删除临时文件；必要时使用 content-addressed cache 和 TTL，缓存命中也必须重新校验 permission view。
• Office、PDF、图片、压缩包、代码包和业务专用格式进入解析队列；压缩包/代码包优先生成 manifest 和风险提示；无解析器的业务格式进入 needs_review 或 unsupported。
• restricted 文件不进入公开 Site；只能发布 review 后的脱敏结论。

权限与审计：

• 下载、解析、重拉、链接打开、缓存命中和上下文投影都必须经过 Tool Gateway 与 permission view。
• 审计记录保存 actor hash、action、reason、timestamp、checksum、source ref 和结果摘要，不保存真实 file id、真实路径、下载 URL、cookie 或 token。
• 权限变化、版本变化、文件删除或解析失败要触发 stale projection 处理或 Semantic Review Queue。

3. 主动收集事件

飞书截图中的主动收集能力本质是“事件通知 + 详情补拉 + 权限判断”。企微也应按这个模式实现，而不是让事件直接执行写库或写回。

事件来源	企微替代路线	处理方式	验收状态
群聊里 @Bot 的消息	智能机器人 Bot 回调	收到消息后生成 restricted Evidence source，再按任务进入 Ask Router 或 Knowledge Card	Bot WS 已验证，Bot URL 回调待验
文档新评论 / 文档变更	企业微信文档 API 或待验证文档事件	先记录元数据，再按 docid 和权限补拉详情；评论事件是否可订阅待后台确认	待官方/后台验收
智能表格记录变更	企业微信智能表格 API 或轮询	先记录 record id、字段 schema、变更时间，再补拉详情；事件订阅待确认	API 路线已登记，事件待验
新邮件	企业邮箱或独立邮件 connector	不默认并入企微；按邮箱系统单独授权、审计和脱敏	待官方/后台验收
reaction 新增/取消	待验证企微消息 reaction 等价事件	不能把 reaction 当成已可用信号；可先用显式回复、按钮或 Knowledge Card review 替代	待官方/后台验收
文件新增/变更	企微云盘、微盘、腾讯文档、群文件、团队空间 API 或指定目录轮询	先登记 metadata、source ref、permission view、checksum、version 和 parser status；内容需要时再临时下载解析	创建/绑定空间、列目录、读 metadata、下载和事件订阅均待官方/后台验收
会议结束、录制、纪要	腾讯会议 Webhook/API	先登记会议元数据和录制状态，再拉取录制/转写/纪要	条件可行，待真实账号验收
普通群聊/单聊全量消息	会话内容存档增强项	只进入 restricted Evidence；必须有试点范围、告知、RSA、SDK 和审计	增强项，非 MVP 前置

主动事件的统一入口 contract：

1. webhook / WS / poller 收到事件，只生成 callback ledger 记录和 restricted Evidence source。
2. Context Router 按 source scope、permission view、任务风险和 stale 状态决定是否补拉详情。
3. Tool Gateway 执行详情补拉、回复、写文档、发消息或会议操作；任何写动作默认需要审计，必要时需要审批。
4. Knowledge Card 默认 pending，review 后才进入共享 Knowledge / Site / 检索投影。

4. 团队上下文构建

上下文层	产品含义	企微路线
个人上下文	成员主动提交的个人日报、问题、补充说明和授权材料	私聊 Bot、个人授权文档、个人可见 Evidence；默认只投影给本人或被授权任务
群 / 项目上下文	群里明确要求沉淀的讨论、项目文档、日报、会议和文件	群 @Bot、项目文档/智能表格/汇报、团队/项目文件空间、群文件、会议 Evidence；按群/项目 permission view 投影
跨人主动询问	Agent 发现缺口后问 1 到 3 个相关 owner	Ask Router 从 owner registry 选人，自建应用消息或 Bot 触达；回复先形成 pending Knowledge Card
组织系统上下文	通讯录、部门、角色、项目、权限、共享容器和系统对象	自建应用通讯录/部门 API 替换本地 owner registry；Wiki/Base/文档/表格作为统一沉淀容器

这四层不能混成一个“全员聊天 RAG”。Context Router 每次只按当前用户、任务、权限和成本选择最小充分上下文。

5. 权限、身份、可见范围和审计边界

• 身份：Bot 身份只代表机器人入口；自建应用身份代表企业应用；用户身份或 OAuth 代表个人授权。需要用户身份的数据，不能用 bot 或管理员身份绕过。
• 可见范围：机器人可见范围、群成员、应用可见范围、通讯录权限、文档权限、云盘/文件空间权限、会议权限和会话存档开启范围都要分别建模。
• 事件详情：事件进入系统时只登记元数据；正文、文档内容、附件、会议转写等详情必须由对应 connector 在权限校验后补拉。
• Evidence Registry：每条来源至少记录 source id、source system、source type、actor hash、scope、timestamp、raw snapshot hash、permission view、review_status 和 retention policy；文件 Evidence 还需记录 drive_space、folder、file、version、source_ref、checksum、parser_status 和 downstream_artifacts。
• 审计：外发消息、主动询问、文档写入、记录变更、文件下载/解析/重拉、会话存档拉取和 Knowledge Card promote 都必须有 Tool Gateway / callback ledger / writeback event。
• 发布边界：原始消息、真实 user id、chat id、doc id、file id、真实路径、下载 URL、cookie、token、回调 payload 和截图原图不得进入 repo、Knowledge 或 Site。

与核心运行模块的对接

模块	对接方式
Tool Gateway	所有企微读写动作先注册 allowlist、schema、scope、审批、频控、输出净化和审计；bot、自建应用、文档、会议、云盘/文件空间、会话存档都不能绕过网关。
Ask Router	只负责“问谁、问什么、怎么节流”；owner registry 后续由企微通讯录补充，真实投递和回调只替换 delivery/callback adapter。
Knowledge Card	@Bot、私聊、转发、文档日报、文件 Evidence、会议纪要和跨人回复先生成 pending card；review 后才进入 Knowledge、Site 或检索投影。
Context Router	按 personal / group / project / org 权限视图选择上下文库；遇到 stale、缺证或待授权对象时，触发补证、主动询问或 human confirmation。

下一步开发拆分

1. 补智能机器人 Bot URL 回调 contract、synthetic fixture 和公网验收，替代生产常驻 Bot WS。
2. 把准入策略抽象为可配置 contract：用户 allowlist、群规则、默认 require_mention、bot sender 策略、自回声过滤、消息去重和按会话串行处理。
3. 把 @Bot、私聊 Bot、转发 Bot、指定文档/日报入口和用户上传文件统一登记到 Evidence Registry，并生成 Knowledge Card。
4. 把自建应用 callback scaffold 接到真实 HTTP handler、access_token、应用消息发送和通讯录最小字段同步。
5. 为企业微信文档、智能表格、企微云盘/微盘、腾讯文档、群文件、团队/项目文件空间、OA 汇报和腾讯会议分别做最小 synthetic metadata 索引、读写或拉取验收。
6. 建立事件能力待验清单：创建/绑定空间、列目录、读 metadata、下载文件、文档评论、文档变更、智能表格变更、reaction、文件变更、邮件、日历/任务/会议室。
7. 只有当全量被动采集、历史回溯或合规审计明确成为需求时，再启动会话内容存档小范围试点。

Evidence 和来源

• 用户提供的飞书自研 Bot 能力截图摘要，作为脱敏需求材料处理。
• 企业微信全量接入可行性调研：workspaces/variai/evidence/raw/2026-06-16-wecom-full-route-feasibility-research.md
• 企业微信管理员与 Hermes 参考材料：workspaces/variai/evidence/raw/2026-06-15-wecom-admin-and-implementation-materials.md
• 企微分层接入方案：workspaces/variai/site/knowledge/wecom-official-full-route.md
• 项目计划：workspaces/variai/knowledge/projects/企微全量接入开发计划.md
• 当前正式决策：workspaces/variai/knowledge/decisions/ADR-040-企微正式主线采用公网自建应用回调与会话内容存档.md
• Hermes Agent 飞书实现参考：/home/ai/.hermes/hermes-agent/gateway/platforms/feishu.py、feishu_comment.py、feishu_comment_rules.py、feishu_meeting_invite.py、tools/feishu_doc_tool.py、tools/feishu_drive_tool.py、飞书 messaging 文档、cli-config.yaml.example 和 gateway 测试。只提炼代码结构和能力模式，不复制配置或真实标识。
• 企业微信官方文档入口包括：智能机器人长连接、回调配置、发送应用消息、会话内容存档、通讯录、企业微信文档、智能表格、微盘、汇报接口，以及后续待验的腾讯文档、群文件和团队/项目文件空间能力；具体链接保留在上述 raw evidence 的“官方/主要外部来源”清单，未确认的细能力不写成已具备。