飞书 Agent 组织管理系统

一句话定位

飞书 Agent 组织管理系统面向单一飞书租户，在现有协作能力之上提供 Agent 的授权、人工审批、任务执行追踪和审计。首个经过真实业务验收的切片是“会议纪要转飞书任务”；高校课程组教研是后续目标场景，目前仅完成虚构样本的本地技术契约。

用户与核心问题

会议发起人需要知道待办从哪句话来，并逐条决定是否创建；负责人需要看到与批准内容一致的任务；管理员需要追溯 Agent 版本、权限和执行依据。项目研究的是 Agent 提议怎样在企业内受控落地，而不只是生成一段回答。

产品边界

层次	采用方式	当前证据
身份、文档、卡片、任务	复用飞书	真实会议与成员试点
权限、审批、TaskRun、审计	自研控制平面	已有本地测试和部分线上工作域
语义执行	Hermes 经 RuntimeAdapter 接入	会议提取已真实验收
教研业务	飞书内课程来源与只读引用	虚构样本本地契约，未做真实教学验收

当前不做通用会议纪要、第二套任务系统、对外多租户或第二教学平台。其他 Runtime、完整教研工作台与教师自定义 Agent 均不能写成现有交付。

已证明的切片与限制

真实会议试点产生 7 条待办草稿、21 处引用、7 张审批卡片；发起人批准 5 条、拒绝 2 条。5 条批准动作逐条做写前复核、远端任务创建、按 ID 回查与负责人可见性验证，真实成员另完成接受和退回各一次。这证明有限场景的受控执行链路。

5 条既有任务的截止日期与批准记录不一致，后续确认和提醒因此阻断。线上持续写入及个人助手消息入口保持关闭。2026 年 10 月的教研来源隔离、版本指纹和人工标注引用只在本地虚构样本中验证；没有真实课程审核或教学效果数据。

演示路径：纪要证据到人工审核

以下四张图来自项目真实 H5 页面和隔离测试网关，会议、成员与待办均为虚构样本。这条路径展示：系统提出待办后，人如何回查证据、补齐责任信息，再决定是否提交。

01 从建议回到原文

操作：打开“产品发布协调会”的待办卡片，展开来源证据。核查：待办“整理部署文档”能回到纪要原文段落；负责人和截止日期被标成待确认。

02 人工补全责任信息

操作：选择当前演示成员为负责人，填写截止日期；保留该待办。核查：原文没有明确日期，因此日期由人决定，页面不把它伪装成自动提取结果。

03 保存草稿

操作：点击“保存草稿”。核查：页面反馈保存成功，负责人、日期与证据仍留在卡片中；此时没有提交审批。

04 提交，等待审批

操作：提交并确认。核查：会议状态变为“待审批”，提示“1 项操作待审批，卡片已发送 0 项”。这一步验证了审核门槛，不代表远端任务已创建。

历史试点与当前边界

项目进度记录中，真实会议试点产生 7 条待办、21 处引用、5 条批准、2 条拒绝。这组虚构截图不能替代真实租户的脱敏证据，也不能证明线上持续运行。历史试点中的 5 条远端任务截止日期与批准记录不一致，线上持续写入和个人助手消息入口目前关闭；教研方向尚无真实业务演示。后续公开真实素材时，应补上批准与拒绝后的远端回查、负责人接受与退回，以及日期差异的阻断画面。

场景与目标

会议文档里可能同时存在明确待办和仍需讨论的事项。产品的首要任务是让 AI 给出带来源的提议，由有权限的人确认，再把批准结果落实到飞书任务并能追溯。验收单位是每一条提议从来源到远端对象的链路，而非单纯的提取数量。

目标	验收依据
提议可核查	待办关联原文引用与来源版本
写入有责任人	发起人逐条批准或拒绝，拒绝不进入写入
执行可追踪	批准记录、写入结果、远端 ID 和可见性可关联
异常不自动扩大	权限或来源变化须阻断；结果未知先对账

用户角色

角色	任务	权限边界
会议发起人	核对引用，批准或拒绝待办	AI 不代替业务决定
任务负责人	接受或退回分配任务	任务内容和日期应与批准记录一致
管理员与审核官	管理 Agent 发布、暂停和审计	不自审自批，保留操作依据

核心流程

1. 成员授权读取飞书文档，会议 Agent 输出待办草稿与引用；引用不足的内容需要人工核对。
2. 发起人在 H5 审核草稿。审批卡片上的批准与拒绝应绑定操作人、内容版本和具体提议。
3. 批准记录形成待执行动作；Worker 写入前再次检查权限和来源，再创建飞书任务并按远端 ID 回查。
4. 对网络中断等不确定结果保留 UNKNOWN，先核验远端是否创建，不能直接重派造成重复任务。
5. 负责人接受或退回。若远端任务与批准内容不一致，后续跟进停止并交由人核验。

已验收与未验收

真实会议样本验收了 7 条草稿、21 处引用、7 张卡片、5 批准和 2 拒绝；5 条批准任务完成逐条远端核验。负责人接受、退回各一次。当前 5 条任务的日期不一致问题仍未解决，不能把提醒和持续写入视为闭环完成。正式 Card 草稿审核和个人助手消息入口在线上关闭。

后续教研方向需要课程成员与来源授权、教学目标/周历/教案引用、负责人审定及可追溯建议。现在完成的是来源隔离、指纹、撤权、人工标注引用和只读委托轨迹的本地契约；自动教学内容分析、真实课程联调与教学质量评测尚未完成。

比较问题

本项目关注 Agent 进入组织后的治理：谁能发布、能读取什么、谁批准写入、一次动作如何回溯、异常如何停止。下面比较的是产品形态及其公开定位，不是对某个企业版的功能实测；具体权限与审计能力应在选型时按目标版本验证。

产品形态	适合的任务	与本项目的比较点
飞书/钉钉内置自动化与机器人	已在协作平台内的轻量流程	优先复用其身份、文档、消息和任务；需要另核对动作级审批与追踪要求
Dify、Coze 等 AI 应用平台	快速构建和编排 AI 应用	更关注 Agent 的生产与编排；本项目聚焦单租户内的运行权限、人工批准和远端对账
通用流程自动化平台	连接多系统并执行确定性流程	接入生态通常更广；本项目目前只验证飞书内受控业务切片

本项目的选择

复用飞书已有的协作入口，自研控制平面并让 Hermes 经适配器调用工具，目的在于把授权、审批和审计集中到可检查的一层。代价是产品目前没有通用连接器生态，也缺真实多租户和广泛业务场景验证。对只需快速搭建问答或内部自动化的团队，现有平台可能更省投入；对必须逐条审批高风险写入并追踪远端对象的单租户试点，本项目的切片更贴合当前验证目标。

验证结论的边界

会议试点证明了该设计能支撑一条有限流程，同时暴露远端日期与批准记录不一致的问题。它不能证明上述平台缺少同类能力，也不能证明本系统在成本、易用性或稳定性上优于成熟产品。后续选型需基于实际版本的权限模型、审计粒度、集成成本及故障恢复做同场景测试。

系统结构

控制平面使用 Python、FastAPI 与 SQLite WAL，面向单一飞书租户。飞书网关负责成员入口和远端文档/任务操作；控制平面保存 Agent 配置、TaskRun、权限、审批、outbox 与审计；Hermes 通过 RuntimeAdapter 提供会议文本的语义提取，不能直接绕开工具网关写入飞书。目标架构中出现的 PostgreSQL、Redis、pgvector 和其他 Runtime 均不代表当前已部署。

会议任务的执行契约

1. 成员授权读取会议文档，会议 Agent 输出带引用的待办草稿。
2. 发起人在 H5 或卡片逐条批准、拒绝；回调验证审批人、内容版本和重复提交。
3. 批准动作在事务中形成 PREPARED 工具调用及 outbox；审批本身不直接写远端任务。
4. Worker 领取 outbox 后再次检查当前权限、来源版本和写入条件，调用飞书任务接口，再按远端 ID 查询与核对负责人可见性。
5. 响应丢失或连接中断进入 UNKNOWN，先对账；无法确认远端是否创建时停止自动重派，转人工核验。

这条状态链避免把“用户点了批准”误记成“任务已完成”。代价是状态和远端对象必须持续对账；现有 5 条任务的截止日期与批准记录不一致，就是这类约束在真实数据上的阻断案例。

教研来源与权限

后续教研切片为课程、负责人和任课教师建立绑定。飞书 docx 以成员 OAuth 只读访问，来源记录保存版本、内容指纹和提交人；读取时重新验证课程成员、飞书授权及来源版本。教学目标、周计划与教案片段目前由人标注引用，代码核对摘录与授权正文并保存不可变证据。人工标注到课程资料 Agent 的只读委托轨迹、两名教师来源隔离、跨课程拒绝和撤权已在虚构样本的本地 API 契约中覆盖，尚无真实课程联调或自动教学内容分析验收。

验证证据

会议试点有 7 条待办草稿、21 处引用、7 张审批卡片，5 条批准任务逐条完成写入与远端核验；真实成员对任务接受和退回各操作一次。2026 年 10 月 21 日的本地全量回归为 272 项通过。这些结果分别证明会议场景的有限真实闭环和教研技术契约的本地正确性，不能合并称为“教研系统已上线”。

当前限制

服务器持续写入和个人助手消息入口仍关闭；无回执 UNKNOWN 的线上恢复、Runtime 跨进程租约、部门隔离和真实教学业务质量尚未验收。教研课程组 H5 及第二教学平台不在当前已实现范围。后续部署与验证应以项目进度记录为准。