n8n Agents：让 AI 决定下一步，让工作流规定怎样执行
n8n 是连接应用和业务流程的自动化工具。Agents 让团队用目标驱动跨工具任务，再用明确的工作流、审批和执行记录控制实际动作。
先给出你的方案与理由，再展开思路，检查是否遗漏了重要的取舍与验证。这些问题没有唯一答案。
01
产品思考中阶
Agent 升级工单前，用户到底在批准什么？
练习场景
客服 Agent 已整理好一位客户的问题，准备把摘要发到值班频道。发送会让另一组人看到客户信息，因此需要用户先确认。你要设计一个审批界面，让用户看懂“谁的信息、发到哪里、发什么”，并知道自己批准的是当前这次动作，而不是对以后所有发送的长期授权。
已知条件与要求
为一个客服 Agent 设计“升级给值班人员”的审批界面。
- Agent 已查过客户信息，准备把摘要发到值班频道；读者可能正在处理多个客户。
- 一次审批只对应当前客户、当前收件位置和当前摘要；审批后任意字段被修改，都需要重新判断。
- 用户可以批准、拒绝或回到对话补充材料；不要让每次只读查询都弹窗。
- 说明界面如何展示上下文、影响范围、修改后的失效状态，以及重复点批准时的反馈。给出能发现误批的验证任务，不假设这是 n8n 现有界面。
用这个情境检查你的方案
页面最初展示客户 A、频道 X 和摘要第一稿；用户查看期间，摘要改成第二稿，或者收件频道改为 Y。请展示原审批如何失效、用户怎样知道变化，以及重新批准前要看到什么。
需要交付什么
交付审批前、内容改变、执行中和结果未知时的页面草图或状态表，写出批准与拒绝的关键反馈，再给出一项能发现误批的观察任务。无需设计 Agent 的检索或推理算法。
查看思路
- 让影响先于技术名词。 显示客户、接收频道、拟发送内容和触发原因；可展开查询依据，但不要把长日志作为默认主界面。
- 把批准绑定到具体版本。 修改客户或正文后，原批准失效并展示变化；“允许升级”不能变成对后续任意升级的长期授权。
- 区分拒绝、待补充和已执行。 拒绝后不能显示已通知；已执行后重复点击应回到同一结果；结果未知时显示待确认，不能假装撤回。
- 观察选择结果。 给测试者两个相近客户、一次收件频道变动及一条响应超时记录，观察是否察觉对象变化、是否把未知当失败。真正完成测试后再总结效果。