背景与动机
生产级 Agent 和 Demo 最大的区别是：Demo 只要跑通一次，生产系统要稳定、可控、可追踪、可回滚。
因此生产实践里不能只关注模型效果，还要关注任务调度、权限、失败恢复和人工确认。
任务队列模式
把用户请求转成任务队列，可以获得：
- 可重试。
- 可暂停。
- 可排队。
- 可限流。
- 可审计。
任务结构建议包含：
任务 ID用户目标输入上下文Agent 版本环境 ID当前状态重试次数最终结果这样任务不会因为一次请求中断而丢失。
多 Agent 协作模式
生产系统里可以按职责拆 Agent：
- Planner：拆任务。
- Executor：执行工具。
- Reviewer：审查结果。
- Summarizer：输出摘要。
不要让一个 Agent 同时承担所有职责。职责越清楚，越容易测试和替换。
人工确认点
这些动作建议强制人工确认：
- 删除数据。
- 发布生产。
- 修改权限。
- 发送外部消息。
- 产生费用的操作。
- 无法自动回滚的操作。
确认点要在系统层实现，而不是只靠模型说“我会先问你”。
回滚和补偿
不是所有工具动作都能直接回滚。设计时要区分：
- 可回滚：Git 提交、草稿文件、临时环境。
- 可补偿：发送修正通知、创建反向记录。
- 不可逆：删除生产数据、外部支付、公开发布。
不可逆动作应该尽量放在人工确认之后。
常见陷阱
- Demo 代码直接上线，没有权限隔离。
- 所有任务都同步执行，失败后无法恢复。
- 没有任务状态机，只靠聊天上下文记状态。
- 审查 Agent 和执行 Agent 共用同一套宽泛提示。
生产上线前检查
是否有任务状态机？是否能重试和恢复？是否区分 Planner、Executor、Reviewer？是否有高风险操作确认点？是否记录 Agent 版本和事件日志？是否有成本和失败率监控？是否能回滚或补偿？如果这些问题还没有答案，系统更适合停留在内部工具或实验环境。
一句话总结
生产级 Agent 的重点不是让模型更自由，而是让任务、权限、状态、审查和回滚都有工程边界。