飞书表格里的业务记录，怎样交给 Agent 生成待办草案

飞书表格里的业务记录可以先交给 Agent 整理成待办草案，再由有权限的负责人确认创建。最常见的问题不是模型不会总结，而是记录、人员和日期字段没有对齐，最后给错人建了重复任务。本文以多维表格为主要合成场景；普通电子表格的行号与多维表格记录 ID 不相同，实际接口能力需分别核对，不把二者混用。

先确定输入是一条记录还是一段视图

明确来源应用、表、记录 ID、读取范围与源版本，不依赖画面上的“第三行”定位对象。视图排序和筛选随时可能变化，行位置不能当稳定业务身份。业务用户选择某个视图，也不表示应用已经拥有读取所有字段的权限。先确定应用授权与请求人的数据范围，只把本次生成待办必需的信息送入处理链。

飞书开放平台的查询记录文档是核对目标多维表格记录接口的官方入口；分页、字段格式和权限应以当前文档与应用实际配置为准。本文不复制未经联调的调用路径或参数，也不宣称一份字段表即可自动开通任务创建。查询业务记录与创建原生待办属于不同动作，要分别确认权限和可用能力。

假设合成记录含客户问题、责任人、截止日期、处理状态与说明。输出草案包括标题、任务描述、责任人内部标识、明确日期、来源记录引用和异常项。标题可以由模型提炼，责任人必须从已验证的人员字段解析，不能从姓名猜账号。日期缺失时输出待确认，不自动填今天；原记录已完成时，根据业务规则跳过，别再生成一个新的待办。

下载记录到草案的字段映射样例。三条合成记录分别演示正常映射、缺少负责人和日期歧义。对“下周处理”这类文本，保留原文与待确定日期，要求业务人选定；对人员字段中有多个人的记录，明确是共同负责、主责加关注，还是需要拆任务。不同理解会改变外部通知与工作分配，不能由模型随意选择。

预览中展示源记录更新时间、将创建的任务标题、接收人、截止时间、是否通知和来源链接。异常记录单列，不把它们混在一段“已完成三条”的总结里。确认人可以修改标题与日期，但修改以后重新计算草案摘要。来源数据在等待期间变化，执行前重新校验相关字段，必要时要求再次确认，防止按照已经失效的责任人建任务。

创建任务或发送通知属于业务写操作，应验证请求人的分配权限，并由具备权限的人确认最终对象与参数。能读取多维表格不意味着能给任意员工派任务。若目标系统只支持机器人身份创建，应在审计中保留真实请求人与确认人，并明确是否代表本人。默认只生成可复制草案也可以完成有价值的试点，不必为追求全自动忽略权限边界。

建立来源记录到目标任务的映射，键至少包含来源范围、记录 ID 和明确的任务类型。再次处理时先查映射：已有任务是更新、追加评论还是跳过，由业务规则决定。不能每次总结文本稍变就生成新任务，也不能把同一记录以后合法的新一轮处理永久吞掉。源记录版本与业务阶段分开记录，有助于区分重复触发与新的工作。

接口超时后先按映射或业务请求号核对目标，确定未创建才能重试。创建成功但写回表格失败时，不要再次创建；保留待补写映射的状态，让恢复流程只补来源状态。写回来源也要限制字段范围，不能把任务结果写回整条记录时覆盖其他人的最新备注。若平台或接口不支持可靠查询，未知结果交给人工核对。

先在隔离表中准备正常、缺字段、无权限三类合成输入。验证正常项只生成一份草案，缺字段项停在人工补齐，无权限项不暴露正文。再重复触发同一记录、修改源日期、撤销创建权限，检查去重、版本冲突和授权拒绝。所有预期结果都写在附件对应行，不把生成了一段好看的任务描述当作全部验收通过。

交付时附字段字典、角色表、来源映射、确认记录和失败恢复说明。业务负责人应能解释为什么某条记录未建任务，管理员应能找到创建凭据与撤销入口。示例没有使用真实飞书环境，因此目标租户的字段类型、接口额度和应用可见范围仍需按授权联调。未来更换表结构时先跑这组三条样例，再发布映射变更。

来源链接也需要权限核对。确认人能查看待办草案，并不代表任务接收人能打开原表记录。预览时检查接收范围，必要时只提供已批准的摘要和受控附件，不为方便访问而扩大整张表的共享权限。任务里保留的客户资料同样按最小化原则处理，完成后的留存与清理另有责任人。

更多思路见流程自动化专题与平台能力边界，人工操作拦截可参考确认后再执行。需要将飞书业务表接成待办辅助流程，可通过定制咨询提供脱敏字段结构、负责人规则和任务创建方式，评估先产草案与确认写入的边界。