想让 Gemini agent 接手办公步骤，先别在提示词里堆指令，而是回到流程本身：把现有步骤摊开，筛掉输入不稳定、结果不可核验、或者一旦写错就要返工的部分，剩下的才值得写成任务描述，并且在描述里明确允许做什么、禁止做什么。下面这套做法偏保守，重点是让每一步的判断都能从日志、页面行为或输出结果里看到，而不是凭感觉认为 agent 大概能做到。

适用场景是重复、规则明确、输入格式固定、输出可人工抽查的办公步骤，例如按模板汇总表格。操作动作是先列步骤清单，再用“输入是否稳定”“输出是否可验证”两个条件筛选，然后写出含允许与禁止操作的任务说明。验证方式是先跑一个最小流程，观察 agent 在边界处是否停下来并说明原因。风险边界是跨系统写入、对外发送、涉及主观判断的步骤不应交给 agent 独立完成，必须保留人工接管。

列出当前办公流程中的重复步骤

先不提 agent，把自己一周内实际做过的重复动作写下来。判断一个步骤值不值得自动化，看三件事：做它的频率、规则是不是写死的、以及碰到的数据有多敏感。频率高但规则靠人现场判断的，通常不适合；频率一般但规则固定、数据只读的，反而可以先试。

可以先用下面这个表格式模板把候选任务摊开，一行一个步骤，不要合并：

步骤名称 | 触发方式 | 每周频次 | 规则来源 | 数据敏感度 | 出错后果
导出周报字段 | 手动/定时 | 2 | 固定字段映射 | 含客户名 | 需重新导出
整理报销邮件 | 收件箱新增 | 5 | 固定模板 | 含金额与身份信息 | 需人工复核
归档会议纪要 | 会议结束 | 3 | 命名规则固定 | 内部信息 | 可重命名补救
更新工单状态 | 邮件通知 | 高频 | 需看上下文 | 业务数据 | 影响他人

按数据敏感度把步骤分成只读、内部写入、对外写入三档。只读且规则固定的排在最前面，内部写入的放到第二批，对外写入的先排除。

判断步骤是否具备稳定输入和明确输出

筛选只看两个条件，两个都满足才进入候选自动化范围。输入稳定指来源固定、字段固定、格式波动不会让 agent 去猜；输出可验证指结果能用固定规则校验，比如字段齐全、金额与原文一致、命名符合模板，并且能人工抽查一小部分。

输入不稳定时，先把输入规范化一次，再考虑自动化；输出不能校验时，说明这个步骤还缺一条判断标准，补标准比补提示词更优先。

标出需要人工判断的例外分支

例外分支不是异常报错，而是流程里本来就有的岔路。常见的三类：一是主观决策，比如措辞好坏、优先级排序、是否批准；二是跨系统写入，比如改数据库、提交工单、变更审批状态；三是对外沟通，比如发邮件、回复客户、发布公告。这三类动作一旦由 agent 直接执行，出错后往往不可逆。

识别方法是在流程图或步骤清单上逐条加一句“如果……则人工”，把它写在任务描述之前而不是之后。例如：如果邮件缺少金额字段，则人工补齐；如果涉及对外发送，则只生成草稿；如果需要修改系统状态，则停止并提示。列出这些分支后，你会更清楚 agent 的职责只是走到岔路口就停下。

在任务描述中写入适用边界

把筛选和例外分支的结果，写成一段结构化的任务说明，允许操作和禁止操作都要写清楚，并且写明什么时候必须停下。下面是一个可替换的骨架，字段名和路径按自己的环境改：

任务：整理指定标签下的报销邮件并生成汇总草稿
输入：
  来源：邮箱中某个固定标签
  预期字段：日期、金额、事由、发票附件名
允许操作：
  读取该标签下的邮件
  提取字段并写入本地草稿文件
  无法识别的字段标注为「待确认」
禁止操作：
  删除、转发或回复任何邮件
  修改报销系统状态或提交审批
  猜测缺失金额或补全发票信息
停止条件：
  字段缺失或格式与预期不符
  需要跨系统写入
  涉及对外发送
输出格式：表格 + 待确认清单

停止条件要写成可观察的动作，不要写成“谨慎处理”这类模糊要求。允许操作尽量收窄到只读加草稿，第一轮不要给任何写入权限。

用一个小流程做边界验证

选一条频次高、影响小的流程先跑一次，不追求跑完整个周期，只看它有没有越界、有没有该停不停。观察点放在页面行为或输出结果上，比如是否出现追问、是否生成了草稿、发送箱里有没有多出邮件、待确认清单是否记录了缺字段的行。

记录表里只要出现一次越界，就不要急着扩大范围，先回到任务描述，把对应动作改成禁止或增加停止条件，再重跑同一个流程。边界是跑出来并记录下来才站得住的，不是写在提示词里就算数。