从 Demo 到生产系统¶
单元 31|难度:综合|前置:Agent 主线全部内容|目标:把所有能力组织为一套可上线架构
Demo¶
生产系统¶
生产系统必须回答:
- 模型超时或限流怎么办?
- 参数格式正确但业务含义错误怎么办?
- 工具已成功、响应却丢失,是否会重复执行?
- 服务重启后任务从哪里恢复?
- 用户是否有权读取数据和调用工具?
- Prompt 或模型升级后如何发现效果回退?
- 怎样限制步骤、Token、成本和执行时间?
- 怎样解释一次失败发生在哪一步?
八个生产化支柱¶
1. 结构化边界¶
模型输出使用明确 Schema;解析成功之后仍要做业务校验。语法合法不代表操作合理。
2. 受控工具¶
模型只提出工具名和参数,后端负责身份、权限、参数、配额、幂等与真正执行。
3. 状态持久化¶
任务、步骤、输入、输出、重试次数和版本写入可恢复存储。Redis 可保存运行视图,数据库保存关键事实。
4. 超时、重试和降级¶
只有适合重试的错误才重试;重试必须有上限、退避和幂等保护。必要时切换模型、走固定流程或转人工。
5. 人工审批¶
外部发送、删除、支付、控制设备等高风险操作必须设置审批或策略引擎。
6. 可观测性¶
记录 task_id、trace_id、模型、Prompt 版本、工具参数、响应、耗时、Token、成本和最终结果。
7. 评测¶
使用固定案例集检查结构化成功率、工具选择、参数、任务完成率、延迟、成本与人工接管率。
8. 安全¶
最小权限、租户隔离、数据脱敏、Prompt Injection 防护、沙箱和审计。
工作流与 Agent 的边界¶
固定、可枚举、高风险的步骤优先使用确定性工作流。只有需要理解自然语言、动态选择工具或处理开放问题的局部节点使用 Agent。
成熟表达:
生产系统通常是确定性工作流包裹少量 Agent 节点,而不是让模型自由控制整个系统。
与 IoT 经验的映射¶
| IoT / 后端经验 | Agent 生产化 |
|---|---|
| MQ 重复消费 | 工具重复调用 |
| 设备命令下发 | 高风险 Tool 执行 |
| OTA 状态机 | Agent 长任务状态 |
| Redis 在线状态 | 运行状态 / Checkpoint 视图 |
| 消息链路追踪 | Agent Trace |
| 规则引擎 | 确定性 Workflow |
| 离线重连 | 任务恢复 |
完成标准¶
- 能不看文章讲出八个生产化支柱
- 能画出确定性 Workflow 包裹 Agent 的架构
- 能把至少五项 IoT/后端经验迁移到 Agent
- 能回答 Agent 生产化标准回答
- 开始 可恢复 Agent Workflow 项目