团队日报散落在企业微信群、飞书表格和内部系统里，周报却还要靠人复制粘贴。要减少这类重复整理，关键是先把数据获取、内容归档、摘要生成和消息发送连成一条稳定的工作流。
这套方案以飞书工作流中的 AI Agent 节点为核心。企业微信负责提供原始消息，MCP 工具负责把消息交给 Agent，飞书多维表格保存结构化记录，最后由工作流生成并发送周报。
企业微信日报
↓
自定义 MCP 工具
↓
飞书 AI Agent 节点
↓
飞书多维表格
↓
周报摘要 → 飞书群
飞书官方文档显示，工作流中的 AI Agent 节点可以自选大模型，并根据指令调用工具；如果预置工具不够，还可以添加自定义 MCP 工具。节点每月有一定免费额度，超出后可继续使用企业购买的 AI 额度。具体额度以企业后台显示为准。
先确定MCP工具要返回什么
这条链路能否稳定运行，很大程度取决于 MCP 工具的输出。不要把企业微信接口返回的整段 JSON 原样交给 Agent，先在 MCP Server 中整理成固定字段。
可以把工具命名为 get_wework_messages，输入参数保持简单：
{
"group_id": "目标群标识",
"start_time": "开始时间",
"end_time": "结束时间"
}
输出只保留周报真正需要的信息：
{
"messages": [
{
"message_id": "消息标识",
"sender": "发送人",
"sent_at": "发送时间",
"content": "消息正文"
}
]
}
message_id 建议保留。工作流重复执行时，可以先在多维表格中查找这条消息是否已经入库，避免同一份日报被统计两次。
企业微信侧需要完成应用授权、消息读取和接口调用。不同企业可用的接口与权限范围可能不同，这部分应以企业微信当前开放能力和管理员授权为准。MCP Server 只负责两件事：调用已获授权的接口，以及把返回结果整理成 Agent 容易使用的结构。
在飞书准备一张周报原始数据表
进入工作流之前，先建一张多维表格。表名可以设为“周报原始数据”，至少包含以下字段：
- 消息标识
- 姓名
- 日期
- 工作内容
- 当前进展
- 问题或阻塞
- 原始消息
这里同时保留“结构化字段”和“原始消息”。前者方便汇总，后者用于复核。Agent 如果把人员、进度或项目状态整理错了，还能回到原文检查。
飞书公开的工作流示例提到，AI Agent 节点可以使用多维表格等工具，也可以切换为流程触发者身份获取权限。配置时要确认 Agent 对目标表格具备查找和新增记录的权限，否则提示词写得再完整，也无法真正读写数据。
接入企业微信MCP工具
在 AI Agent 节点的工具配置中添加自定义 MCP 工具，并连接已经部署好的 MCP Server。工具被识别后，只启用当前流程需要的能力，例如 get_wework_messages。
不要一开始就把多个内部接口全部交给 Agent。工具越多，名称和用途越相似，调用时越容易选错。周报流程先保留三类能力即可：
- 获取企业微信消息
- 查找飞书多维表格记录
- 新增飞书多维表格记录
调用企业微信工具的指令可以这样写：
调用 get_wework_messages，获取指定群聊在给定时间范围内的消息。
只处理工具实际返回的内容，不补充缺失消息。
返回结果为空时，直接输出“该时间范围内没有可处理的日报”。
调试阶段，建议先用飞书消息触发工作流。飞书公开示例给出的做法是：选择“接受飞书消息触发”，再把消息内容引用为 AI Agent 节点的输入。你可以先在测试群里发送群标识和日期范围，确认 MCP 调用、表格写入与消息发送都正常，再接入团队实际使用的定时触发方式。
把日报拆成可汇总的记录
Agent 取得消息后，需要先查重，再写入多维表格。节点指令可以直接约束处理顺序：
处理 messages 中的每一条消息：
1. 使用 message_id 查找“周报原始数据”表。
2. 已存在的消息跳过，不重复新增。
3. 从消息正文中提取姓名、日期、工作内容、当前进展、问题或阻塞。
4. 无法确认的字段留空，不允许猜测。
5. 将原始消息完整写入“原始消息”字段。
6. 完成后返回新增、跳过和失败的记录列表。
字段不要拆得过细。日报原文通常不够规范，如果要求 Agent 同时识别项目编号、优先级、完成比例、责任部门等大量字段，缺失信息很容易被错误补全。先围绕“做了什么、进展如何、卡在哪里”整理，已经足够支撑常规周报。
生成周报时，把边界写进提示词
原始数据入表后，再增加一个 AI Agent 节点，读取本周记录并生成摘要。为了避免人员与事项错配，提示词里要明确数据边界和输出格式。
读取“周报原始数据”表中指定日期范围内的记录，并按姓名分组。
输出结构：
### 本周完成事项
### 进展中事项
### 风险与阻塞
### 未提交或信息不足
要求：
- 只使用表格中已有记录。
- 不推测完成状态，不补写项目结果。
- 不把不同人员的事项合并到同一人名下。
- 内容存在冲突时，保留原始表述并标注“待确认”。
- 某人没有有效记录时，标注“未发现有效日报记录”。
- 每项内容尽量保留负责人和对应日期。
这一步最好直接读取多维表格，不要依赖上一个节点留下的长文本。表格字段更稳定，也方便后续人工核对。
最后发送到飞书群
汇总节点之后添加“发送飞书消息”动作，目标选择团队周报群，消息正文引用 Agent 生成的摘要。
首次上线时，可以在正文前加一行状态说明：
以下内容根据本周已入库日报自动整理，请负责人核对风险与阻塞项。
先让工作流在测试群运行几次，重点检查四件事：
- 同一条企业微信消息是否重复入库
- 姓名与工作事项是否对应
- 日期范围是否覆盖完整
- Agent 是否补写了原文中没有的状态
确认结果稳定后，再把触发方式调整为团队需要的周期。如果飞书后台提供定时触发，可以设置为每周固定时间执行；如果当前环境没有对应触发器，也可以继续使用消息触发，或接入团队已有的调度服务。不同版本和企业权限下的可用节点可能有差异，以实际后台为准。
最常见的问题不在模型
工具能连接，但读取不到数据
先检查调用身份。飞书工作流示例特别提到，可以切换为流程触发者身份获取权限。MCP Server 和多维表格也要分别确认授权，连接成功不等于拥有目标数据的读取权限。
同一份日报反复出现
不要仅按正文去重。员工可能连续几天提交相似内容，正文相同不代表同一条消息。应优先使用消息接口返回的唯一标识，并在写入前执行查找。
摘要里出现原文没有的进度
把“无法确认时留空”和“不得推测完成状态”写进节点指令，同时保留原始消息字段。涉及交付、风险和责任人的内容，仍应允许人工复核。
工作流突然无法继续执行
检查 AI 额度和工具调用状态。飞书官方说明，AI Agent 节点每月有一定免费使用额度，超出后可使用企业购买的 AI 额度。消息量较大的团队应关注后台实际用量，不要根据人数预估消耗。
这条链路还能怎么复用
周报只是一个容易验证的起点。只要外部系统能够被封装成 MCP 工具，同样的结构还可以用于汇总客诉、订单异常、项目风险或待办事项：外部系统提供数据，Agent 负责调用工具和整理内容，飞书承接存储、协作与发送。
复用时不必重做整条工作流。通常只需要替换 MCP 工具、调整多维表格字段，再改写 Agent 的整理规则。接口输出越稳定，后续改造越省事。
参考资料：
