很多 Agent 演示看起来像一段流畅聊天：用户提出目标，模型拆步骤，调用工具，最后返回结果。但放进真实业务后，问题马上变复杂。生成报告可能要几分钟，批量处理可能要几十个工具调用，代码修复可能要跨多个阶段，用户还可能中途关闭页面或要求停止。
这时 Agent 不能只被当成一次 HTTP 请求。它更像一个后端任务系统：要排队、要调度、要能取消、要能失败重试，也要能在服务重启后恢复现场。
先把任务从会话里拆出来
聊天会话适合承载用户意图和交互历史，但不适合直接承载长任务执行状态。一个生产化设计通常会把用户请求转成 job：记录任务 ID、用户、目标、输入、状态、创建时间、优先级和结果位置。
会话可以显示任务进度，但任务本身应该独立持久化。这样用户刷新页面、换设备、服务重启，都不影响后台执行状态。否则一旦连接断开，系统很难判断任务是失败、继续执行，还是已经产生了部分副作用。
执行器需要租约和心跳
后台 worker 拉取任务后，不应该只在内存里标记“我拿到了”。更稳的方式是给任务加租约：某个 worker 在一段时间内拥有执行权，并定期心跳续租。如果 worker 宕机，租约过期后任务可以被其他 worker 接手。
这套机制能避免任务永久卡在 running 状态。接手时还要看任务是否幂等，哪些步骤已经完成，哪些工具调用不能重复执行。Agent 的每一步都应该有可记录的阶段，而不是只保存一段模型上下文。
取消不是杀线程这么简单
用户点击停止时，系统要做几件事：标记任务取消意图，停止后续模型调用，尽量取消正在进行的上游请求，不再执行新的有副作用工具，并把当前已完成结果保存为可查看状态。
如果工具调用已经发出，就不能假装它没发生。比如已经创建工单、发送通知、修改配置，取消后要么展示已完成动作，要么进入补偿流程。取消语义要写进状态机，而不是在前端隐藏加载动画。
优先级和隔离决定系统能不能扛住
Agent 任务天然容易变长、变贵。一个用户提交大量批处理，不能把所有 worker 占满，影响其他用户的短任务。队列要有并发限制、用户级限额、任务类型隔离和优先级策略。
比如交互式任务优先级更高，批量离线任务可以低峰执行；高风险工具调用需要等待确认；失败重试要退避，不能在下游故障时不断放大流量。这里的设计和普通后端任务系统非常接近，只是每一步多了模型不确定性。
结果要能复盘
Agent 任务结束后，不能只保存最终回答。生产系统至少要能看到步骤、工具参数、执行结果、耗时、错误和模型关键决策。这样用户质疑结果时，团队能判断是规划错、检索错、工具错，还是权限和数据本身有问题。
面试里可以这样总结：Agent 后台任务不是把模型调用放进异步线程池，而是完整的任务系统设计。job 状态机、队列调度、租约心跳、取消语义、幂等执行、优先级隔离和审计复盘都要具备，Agent 才能从演示变成可靠产品。