三个月前，我们把 MCP 接进飞书，希望自动收集日程、项目和文档，生成一份可以直接发送的周报。
第一个月的问题很直接：令牌静默过期、消息重复推送、多人同时写表发生冲突。逐项修完以后，工作流终于能稳定运行，但周报并没有因此变得可靠。
2026 年 4 月至 6 月，我们复核了 13 周、743 份自动周报。第一周，无需修改即可发出的比例是 71%；到第六周反而降到 68%，随后长期停在 65%—70%。返工项里，日程遗漏占 38%，项目归属错误占 27%，格式漂移占 21%。每周平均还要花 47 分钟修改，只比第一个月少 5 分钟。
这时再继续换模型，收益已经很有限。真正没处理好的，是 Agent 能看见什么、如何理解字段，以及哪些决定不能交给它。
日历接口通了，Agent 看到的日程却不完整
我们最早只给 Agent 暴露了 calendar:calendar.v2.event.list。它可以读取日历事件，却不等于能拿到所有与用户有关的安排。
实际使用中，日程可能来自个人日历、多维表格中的 calendar_event，也可能是会议室预约。跨部门会议由共享日历发起，客户拜访由行政助理代建，这些事件未必出现在 Agent 默认读取的范围里。结果是接口调用成功，周报仍然漏项。
重复事件更麻烦。修改过的 recurring event 可能产生新的 instance_id，列表里于是出现两条相似记录。其中一条 description 为空，Agent 仍会把它写进周报，留下“某客户会议（待补充）”这样的条目。
我们的处理方式不是再加一句“请仔细检查”，而是把筛选步骤写死：先拉取周一 00:00 至周日 23:59 的全部事件，按 mod_time 倒序排列；遇到重复记录，只保留最新一条。
调整后，日程遗漏率从 38% 降到 11%，token 消耗增加了 14%。这笔开销可以接受，因为它换来的不是文案更漂亮，而是数据范围更完整。
“Phoenix”到底属于哪个项目
项目归属是另一类错误。
飞书项目中的 work item、飞书文档和飞书表格之间，并不总有统一且强约束的项目编号。一项任务可能关联 A 项目，执行人写下的文档却存放在 B 项目空间。Agent 如果按照最近编辑记录判断，很容易把“帮 B 项目改了一个 bug”归到 A 项目名下。
代号重复时，问题更明显。团队内部有 3 个项目用过“Phoenix”。Agent 只看到文档中的代号，便可能通过近邻匹配，把 2024 年的旧项目写进 2026 年的周报。
这类判断无法靠更长的 Prompt 根治。我们最后放弃了全自动归属，改成“Agent 提名，人来确认”。
Agent 必须同时给出判断依据：关联了哪个 work item、引用了哪份文档、使用了哪个时间戳。多维表格里增加 ai_suggested_owner 一列，只存放它建议的项目归属。复核人不必重读整份周报，只需要检查这一列并点选确认。
归属错误率由 27% 降到 6%，代价是生成流程多了一步。它没有完全消灭人工操作，但把原本分散在全文里的检查，压缩成了一次明确确认。
飞书项目的 MCP Server 已经提供 project:project.v2.info:read、work_item:work_item.v2.info:read 等工具，用于查询项目空间和工作项信息。工具能返回数据，却不能替团队定义“这项工作究竟算在哪个项目”。这是调用和判断之间的分界线。
Markdown 写得没错，落进飞书还是会变形
周报模板使用 Markdown，最终载体却是飞书文档，中间还隔着一次 Markdown 到 docx 的转换。
三个月里，我们遇到过几种固定问题：代码块的反引号直接显示，Markdown 表格被第一个单元格撑开，[文字](URL) 变成裸链接，超过 3 层的嵌套列表被压平成一层。
飞书开放平台对 MCP 的定位，是把 OpenAPI 封装成更适合 AI 调用的工具能力。它改善的是接口调用，不负责保证 Markdown 与飞书文档的渲染结果完全一致。转换规则仍然要由上层工作流处理。
我们因此收紧了输出格式：代码块使用 code 标记，表格改成简化结构，链接统一写成“文本：URL”，列表最多嵌套 2 层。格式漂移率从 35% 降到 9%。
剩下的问题出现在长上下文里。输入超过 8K token 后，Agent 偶尔会忽略开头的语法限制。与其不断追加提醒，不如缩短单次任务：先整理事实，再单独生成飞书文档结构。任务拆开以后，每一步的规则都更短，也更容易检查。
代码捕获不了“看起来成功”的错误
最初，我们在 Agent 外层加了 Python 异常捕获。它能处理超时和接口报错，却拦不住一种更常见的情况：MCP 工具调用成功，但返回空列表或缺少关键字段。
对代码来说，这不一定是异常；对周报来说，它意味着数据不完整。Agent 如果没有后续规则，就可能根据上下文自行补全，生成并不存在的工作记录。
后来，我们把语义层的异常处理写进任务流程：
- calendar 返回空列表时，先检查
userKey是否过期； - work item 缺少字段时，回退到
project.v2.info； - 两次调用都失败时，将当周标记为“数据缺失周”；
- 简版周报只写已经确认的数据，不允许根据历史记录补齐。
这套规则上线后，部分数据缺失时的“幻觉填充”率从 22% 降到 4%。关键不是让 Agent 学会处理所有异常，而是明确告诉它：什么时候必须停下来，不能猜。
MCP 负责把工具接进来，不负责替人下结论
飞书开发者手册记录了 2025 年 5 月 12 日的 OpenAPI 限流方式和阈值调整公告。接口稳定性会继续改善，MCP 也让模型调用飞书能力变得更直接。我们的调用成功率从 78% 提升到 96%，但调用成功和周报准确仍是两套指标。
日程是否完整，取决于读取范围；项目属于谁，取决于团队的业务口径；文档怎么显示，取决于转换和渲染规则。这些问题不能只靠协议解决。
有开发者因此放弃 MCP，转向 Skill 与飞书 CLI，理由是“由模型自主决定何时查资料”不够可控。我们的结论没有这么绝对。MCP 在跨工具编排上仍然有价值，但更适合停留在调用层：查日历、读项目、取文档、写入表格。涉及项目归属、数据缺失补偿和最终发布时，仍需要确定性规则或人工确认。
经过后续调整，自动周报可用率达到 78%，返工耗时从 52 分钟降到 26 分钟。它没有变成一套完全无人值守的系统，但人工复核已经从“重写整份周报”缩小到“检查少数高风险字段”。
目前保留下来的结构很简单：MCP 调工具，Prompt 管边界，人负责确认。模型可以继续升级，飞书各产品之间的字段语义却不会自动统一。先把哪些数据能读、哪些规则要写死、哪些判断必须留给人划清楚，通常比再换一个模型更有效。
参考资料：
相关阅读：MCP 接入企业微信和飞书后：自动周报工作流的真实故障清单 | 审批权交给 Agent，先堵住这三个漏洞 | Cursor 2.0 多 Agent 实战：先拆任务，再审 diff
