很多人做 Agent 时，第一反应是把 prompt 写得更长、工具接得更多、自动化程度提得更高。但真正走到真实任务里后，你很快会发现，用户最在意的不是“这个 Agent 会不会思考”，而是“它现在在做什么，出问题后我还能不能接得住”。

所以我现在做多步 AI 工作流，通常会先画状态，再写 prompt。

Agent 不是一句话，而是一条流程

单轮问答里，prompt 可能就是主体；但只要应用要经历规划、调用工具、读取数据、生成结果、等待确认这些阶段，它就已经是流程系统了。流程系统最怕的不是偶尔失败，而是失败方式不可见。

如果用户只看到一个“正在处理中”的 loading，然后过很久得到一个不稳定结果，他们很难建立信任。相反，就算系统还不完美，只要状态足够清楚，用户通常也更愿意继续配合。

先画状态，再写 prompt

我会先把一条典型任务拆成几个可见状态，例如：

  • 等待输入
  • 生成计划
  • 调用工具
  • 整理结果
  • 等待用户确认
  • 完成或失败

这一步看起来很“传统产品”，但对 Agent 特别重要。因为只有状态先被定义出来，你才知道哪些信息应该暴露给用户、哪些错误需要单独处理、哪些节点应该允许人工打断。

人工接管不是补丁，而是能力

很多 Agent 产品把人工接管理解成“自动化失败之后的兜底”。但我更愿意把它当成产品能力的一部分。原因很简单：真实任务里总会出现权限不足、上下文不全、目标临时变化、外部工具异常这些情况，用户需要在关键时刻拿回控制权。

所以我会优先考虑这些问题：

  • 哪一步允许用户暂停或重试。
  • 哪一步必须展示原始中间结果。
  • 哪一步适合让用户确认后再继续。
  • 系统失败时，是重新执行、退回上一步，还是直接交还给人。

Agent 的“智能感”当然重要，但我越来越相信，让流程变得可见、可控、可回退，才是它真正能被长期使用的前提。