第一次用智能体工作台，最容易踩的坑是一次性把整条业务串起来：取数、判断、生成、写回全塞进一个流程，结果每个环节都在报错，日志混在一起，不知道该先改哪里。可行的做法是把拆解顺序倒过来——先挑一条环节最少、结果能肉眼校验的闭环，跑通并且连续跑稳，再按次序往外加步骤。适用范围是可拆成多步的业务流程；边界是每加一步都要能单独验证，衔接一旦出问题就退回单步，不要在一个会话里同时改两个变量。

先挑一条环节最少、结果能肉眼核对的任务，只配必要输入跑通一次；同一份输入连跑三次确认可重复；稳定后再加第二步，并让第二步直接复用第一步的产物。适用场景是可拆成多步的业务流程，风险边界是每加一步都必须能独立验证，衔接失败就退回单步排查，不要一边改提示词一边调下一步。

挑一条环节最少、结果能肉眼校验的任务

选点标准通常看三条：步骤数尽量不超过两步、优先只读不写回任何系统、输出能靠人工逐条核对。三条都满足，失败原因基本能从产物本身看出来，不需要翻一堆中间日志。

可以先按这三条给手上的任务打分，选分数最高、与真实业务最接近的那个作为起点。含写操作的候选任务先放着，等只读闭环稳了再考虑接进来。

只给这一步配必要输入并完整跑一遍

最小条件下智能体能否独立产出结果，比它在复杂条件下偶尔成功更有参考价值。输入清单建议只保留三类：一段待处理的数据、一份任务说明、一份输出格式约定；工具权限除读取外先关掉，避免它自己去找数据源。

下发内容可以直接粘贴到工作台的单步任务里，下面是一个可替换的骨架：

角色：只做一件事，把下面文本里的待办抽成清单
输入：
（在这里粘贴原文，保持原样，不要额外加说明）
输出格式：每条待办一行，字段顺序 负责人 | 事项 | 截止时间
规则：
1. 不要补充原文没有的信息
2. 缺少的字段写 未提，判断不了的写 待确认，不要猜
3. 只输出清单本身，不要解释过程
约束：不调用其它工具，不写入任何系统

跑完以后按字段逐条人工核对，把结论记成一行模板：原始条数、产出条数、字段缺失处数、有无原文不存在的编造内容。核对结论只需要是事实描述，例如「原文 7 条待办，产出 7 条，2 条截止时间写为未提，无编造条目」，不要在这里估算准确率或收益。

连续跑三次看结果是否稳定

一次成功说明不了什么，可能是输入恰好规整。建议用同一份输入、同一份提示词连跑三次，重点看四处差异：清单条数、字段取值、输出格式、条目顺序。

• 三次条数一致、字段一致，只是顺序不同：一般属于可接受波动，可以在输出约定里补一条排序规则固定下来。
• 条数不一致：通常是输入里的判定边界不清，先把输入缩到语义明确的段落再试。
• 字段值飘动：多为缺少判定规则，把规则明确写进提示词，而不是靠模型自行理解。
• 格式每次都变：把输出约定改成固定字段和固定分隔符，必要时要求输出 JSON。

不稳定时先固定这些输入：原文、提示词全文、模型与参数、可用的工具权限，以及时间、地区这类上下文。一次只固定一项，改完再跑三次，否则又会回到分不清原因的状态。

稳定后再加第二步并复用上一步产物

加第二步的前提是第一步已经连续稳定，并且第二步能直接吃第一步的输出，不需要人工搬运。产物传递方式一般有三种：结构化文本或 JSON、固定分隔符的表格、落盘文件的路径。建议优先用字段固定的结构化产物，字段名统一英文小写下划线，减少解析歧义。

衔接是否成功，看三件事：第一步的字段是否被完整保留、有没有被第二步悄悄改写、第二步是在第一步结论上继续加工而不是从头再推一遍。衔接失败的典型表现是字段丢失或改名、格式被自由发挥，以及第二步把第一步的结论当成待处理数据又重新处理一次。

一旦衔接失败，回退到单步：把第二步单独拿出来，用第一步的真实产物作为输入跑一遍，确认第二步本身没问题，再把它接回流程。不要一边改第一步的提示词一边调第二步。

扩步骤可以按下面的次序推进，写操作永远放在最后：

整条顺序的核心判断只有一个：每一步都要能单独看出对错。看不出来，就说明这一步拆得还不够小，需要结合自己的环境和日志再往下分。