Agent 做短问答时，一次请求就能结束；但很多真实任务不是这样。生成一份报告、分析一批简历、整理知识库、调用多个内部系统，都可能需要几十秒甚至几分钟。长任务 Agent 如果只靠一次上下文和同步请求，很容易超时、丢状态、无法恢复。
面试里讲 Agent 长任务，要把它当成工作流系统，而不是一个更长的 prompt。
长任务要进入队列
长任务不适合一直占着 HTTP 请求等待。更稳的方式是创建任务记录，把任务放入队列或任务执行器，立即返回任务 ID。前端通过轮询、WebSocket 或通知查看进度。这样用户不用卡在一个请求里，后端也能更好地控制并发和重试。
队列还可以做限流和优先级。高价值用户、短任务、实时任务可以优先执行；低优先级批处理任务可以延后。没有队列，所有 Agent 任务同时跑起来，很容易把模型调用和工具调用打满。
每一步都要有状态
多步骤 Agent 不能只记录最终结果。系统应该知道当前执行到哪一步，每一步用了什么输入，调用了什么工具，返回什么结果，是否失败，失败能不能重试。这样任务中断后才能恢复，而不是从头再来。
检查点尤其重要。比如一个 Agent 已经完成资料检索和初步分析，只是在生成最终报告时失败，就不应该重新检索所有资料。保存中间结果可以降低成本，也能减少重复副作用。
恢复机制要区分错误类型
不是所有失败都能重试。模型输出格式错误可以修正后重试，网络抖动可以退避重试，权限不足不能重试，用户输入缺失需要追问。把所有错误都当成可重试，会浪费成本，也可能放大下游压力。
如果某一步已经产生外部副作用，比如创建工单、发送消息、修改状态，恢复时还要检查这个副作用是否已经发生。否则重跑任务可能造成重复操作。
用户要看到可信进度
长任务最怕用户不知道系统在做什么。进度不一定要精确到百分比，但至少要能展示当前阶段：排队中、检索资料、调用工具、生成结果、等待确认、失败待处理。失败时也要给出可理解原因，而不是只说任务异常。
一个成熟的回答可以是：长任务 Agent 会落到任务表和步骤表里，执行器按队列调度，每一步保存检查点和审计信息；失败按类型处理，可恢复就续跑，不可恢复就停止并提示用户。这样 Agent 才能从演示流程变成可靠的后台任务系统。
长任务 Agent 还要考虑用户取消。用户发现任务方向错了，或者不想继续消耗额度，系统应该能停止后续步骤。取消不是简单杀线程，而是把任务状态标记为取消中，等待当前不可中断步骤结束，然后停止后续调度。
如果已经产生外部动作，还要告诉用户哪些步骤已经完成，哪些没有执行。这个细节能体现工程边界：Agent 不是聊天窗口里的黑盒，而是一个有状态、有审计、有用户控制权的任务系统。