试想这样一个典型场景：你积压了大量客户投诉录音，需要让 MiniMax Agent 帮你“整理一番”——转写为文字、提取情绪关键词、生成日报摘要，最终自动同步到飞书表格。需求听起来清晰易懂，对吧？但如果直接对 Agent 下达一句“帮我处理投诉录音”，你大概率会得到令人失望的结果。原因很简单：这种涉及多环节、跨模态、带条件分支的复杂任务，必须严格遵循原子性、闭环性和依赖顺序三大原则，逐一拆解为可执行的步骤。
在动手写指令之前，我们不妨一起梳理一下拆解思路。
第一步：明确核心目标，清除模糊描述
拿到原始需求后，首先通读全文，划掉所有主观形容词和开放式动词。例如“快速整理”——什么才算“快”？没有量化标准，Agent 根本无法判断。“帮忙看看”——这并非可执行动作。“大概总结一下”——“大概”的范围是什么？摘要要写多长？这些模糊表述都要剔除。只保留那些具备明确输入源、确定输出格式、且可判定成败的动作短语。
举个例子，“生成日报摘要”这个指令，在 Agent 看来等同于没有说明。你需要拆解为“输出一个 Markdown 表格，包含日期、投诉编号、情绪标签（愤怒/失望/困惑）、TOP3 问题关键词，共 7 行，首行为表头”。这样一来，每项输出都可以通过程序自动校验字段是否缺失或行数是否正确。一组数据，一套标准，清晰明了。
第二步：按依赖顺序构建线性子任务链
需求明确后，下一步就是按照执行顺序排成线性链条。我们一步步来看。
第一步：确认输入就位。在开始转写之前，先确认输入文件是否就绪。具体而言，检查本地文件夹 “/complaints/202607/” 是否存在以 “CALL_” 开头、扩展名为 “.m4a” 的音频文件，且数量至少为 1。如果不存在，直接中断并返回错误码 E101。这一步相当于保险丝，能避免后续任务在空转中浪费计算资源。
第二步：语音转写。调用语音转写命令，参数需指定模型、语言和输出格式为 .srt，输出路径固定。这一步的输出将直接作为下一步的输入，环环相扣。
第三步：情绪识别。读取上一步生成的全部 .srt 文件，利用情绪分析工具逐段打标，仅保留置信度大于 0.85 的情绪标签，合并去重后输出 JSON 数组。为什么要设定这个阈值？因为置信度太低的结果会导致后续分析失真。这一步的输出质量直接决定了摘要的可信度。
第四步：摘要生成。将第三步输出的 JSON 与对应的 .srt 文本拼接为新上下文，输入模型，严格限定输出格式：总计受理多少通、情绪分布饼图数据（纯数字）、问题关键词云（限 5 个，按频次降序）、建议措施（3 条，每条不超过 12 字）。四个模块缺一不可。
第五步：飞书同步。调用 API，将第四步输出的四个模块分别写入指定表格的指定区域。写入前必须校验目标表格是否拥有编辑权限，否则报错并暂停任务。这一步看似简单，却最容易出现“权限类”意外，前置校验必不可少。
第三步：为非线性分支添加显式条件标注
复杂任务往往不是一路直行，遇到分支该怎么办？两种方法可以解决。
方法一：用 if-then 语法内嵌判断逻辑。比如在第四步指令末尾追加：“如果情绪标签包含‘愤怒’且出现频次 ≥ 3，则在‘建议措施’末尾强制增加第 4 条：‘立即升级至客诉总监’；否则不添加。”这样一来，分支条件就变成了可执行的逻辑规则。
方法二：预设失败兜底动作。在第五步描述后加上一句：“若 API 返回 403 错误，自动切换备用账号 token 并重试一次；若仍失败，则将摘要内容保存为 PDF 到指定路径，不再重试。”注意：条件分支必须绑定具体触发值——比如“出现频次 ≥ 3”或“错误码 403”——禁止使用“如果很多”“假如不行”这类模糊表述，否则 Agent 无法解析执行。
第四步：为每个子任务分配唯一 ID 与验收锚点
最后，也是容易被忽视的一步：为每个子任务分配一个唯一 ID 和对应的验收锚点。例如：
第一步的 ID 是 T1_INPUT_CHECK，验收锚点是“返回文件列表或 E101 错误码”；
第二步的 ID 是 T2_TRANSCRIBE，验收锚点是“在 /transcripts/ 目录下生成同名 .srt 文件且大小大于 5KB”；
第三步的 ID 是 T3_EMOTION_TAG，验收锚点是“输出 JSON 中每个 call_id 对应 emotion 数组长度至少为 1”；
第四步的 ID 是 T4_SUMMARY_GEN，验收锚点是“输出严格包含 4 个编号段落，第 2 段为纯数字，第 3 段为 5 个中文词”；
第五步的 ID 是 T5_FEISHU_SYNC，验收锚点是“飞书表格 A1 单元格值等于当日日期字符串”。
缺少任何一个锚点，Verifier 就会判定该子任务失败并触发回滚。这样一来，每个环节都具备了明确的“止损点”，整个任务的可靠性才能落到实处。
说到底，编写 Agent 指令本质上就是在做系统设计——把模糊的需求转化为可执行、可验证、可回滚的工程流程。这套方法初看可能有些繁琐，但当你真正跑完一个多阶段、跨模态的复杂任务后就会发现：所有前期拆解的功夫，最终都节省了数倍的后端调试时间。