——一个生产级交易型 AI Agent 的完整架构设计与实践在过去一年里我刻意避免去做“看起来很炫”的 AI Demo而是选择从一个极其具体、简单但高风险的业务场景入手商品查询 → 下单 → 订单确认 → 执行交易因为这是第一个会让我认真思考“如果 LLM 出错系统还能不能兜住”的问题。这篇文章完整介绍一个我自研的生产级交易型智能体AI Shopping Guide它不是 Prompt 工程展示也不是工具堆砌而是一个真正考虑了状态、权限、回滚、安全与可观测性的 AI 应用系统。一、为什么要“反直觉”地做一个这么复杂的系统在大量 Agent 项目中我反复看到三种常见风险LLM 拥有直接写业务状态的能力系统状态与对话状态混杂在 Prompt 中出错只能靠“再问一次”这些在“查资料 / 写代码”类 Agent 中问题不大但在交易型系统中是致命的。所以这个项目从第一天起就立了三条不可妥协的原则原则一句话解释LLM 零写权限LLM 永远不能直接修改任何业务状态状态机硬闸门关键动作必须经过 FSM 决策纯函数执行订单编辑是确定性的、可回滚的二、整体架构概览职责清晰而不是“一个 Agent 解决一切”系统采用清晰分层 克制设计而不是把所有能力堆进一个 Agent。前端 (Next.js / React) ↓ API Routes (BFF 安全拦截) ↓ ToolLoopAgent执行引擎 ↓ FSM状态与权限控制 ↓ 工具系统查询 / 下单 / 存储 ↓ Redis / Vector / 可观测性为什么不是“一个大 Agent”因为在生产环境里Agent ≠ 系统控制器。LLM 擅长理解意图但不适合管理状态处理边界条件保证一致性做最终执行决策所以我把它降级为“建议者”。三、Agent 设计ToolLoopAgent prepareStep 路由模式系统并没有让 LLM 自由选择工具而是通过ToolLoopAgent prepareStep明确控制每一轮行为。Agent Loop 核心思想Step 0必须先问 FSM —— 我现在能不能干这件事 Step 1如果是交易路径走强约束执行 Step 2才允许进入 auto 模式自由查询这种模式解决了一个关键问题“Agent 是在思考还是在执行”而不是让这两件事混在一起。四、FSM整个系统最重要的“安全闸门”这是一个极简但强约束的三态 FSM状态含义IDLE空闲 / 查询态AWAITING_CONFIRMATION等待用户确认EXECUTING系统自动执行核心规则非常重要只有 EXECUTING 状态系统才允许 createOrderLLM 在 AWAITING_CONFIRMATION 状态下被禁止调用业务工具所有状态变更必须由代码触发不接受 LLM 直写FSM 不是“为了优雅”而是为了兜底。五、订单系统纯函数草稿编辑而不是“让 LLM 写 JSON”订单编辑的核心不是 Prompt而是一个纯函数applyActionsToDraft(draft, actions) → newDraft | error为什么这是整个系统的“定海神针”每一步编辑确定性任一 action 失败整体回滚不依赖 LLM 的“猜测正确性”LLM 只负责输出**“我想做什么”**而系统代码负责决定“你能不能这么做以及结果是什么”六、检索系统不迷信向量不排斥传统方法在商品搜索上我没有走“纯向量”的流行路线而是选择BM25 向量检索 动态权重融合原因很现实场景BM25Vector冷启动✅❌可解释性✅❌语义泛化❌✅系统会根据 query 特征自动调整权重而不是一刀切。七、防御深度一个请求要经过 6 层防护层级防护点L0会话 / 页面 / Tab 隔离L1前置拦截负数、nonsenseL2Agent 意图分类L3FSM 状态闸门L4业务字段级校验L5本轮地址隔离这不是“过度设计”而是对 LLM 不确定性的尊重。八、可观测性看得见 Agent 在“想什么”系统接入 Langfuse但做了两个关键约束可观测 ≠ 强依赖追踪失败不影响业务每一次FSM 状态转移工具调用记忆读写都有独立 Span可以完整还原 Agent 行为路径。九、这套架构解决了什么问题问题是否解决LLM 幻觉✅非法写状态✅交易误执行✅多轮对话错乱✅可回放 / 可调试✅十、总结这是一个“工程视角”的 Agent而不是 Prompt 展示这个项目我最满意的地方不在于功能多少而在于我敢把它放到生产环境我敢让别人 review 架构我敢在面试中被深挖每一个决策Agent 的未来不是“更聪明的模型”而是“更克制的系统设计”。项目演示 视频演示https://pan.baidu.com/s/1mMAHbi_Vz26D6gQfXHmfGQ?pwdgqfn
从“能跑的 Agent”到“敢上生产的 Agent”
——一个生产级交易型 AI Agent 的完整架构设计与实践在过去一年里我刻意避免去做“看起来很炫”的 AI Demo而是选择从一个极其具体、简单但高风险的业务场景入手商品查询 → 下单 → 订单确认 → 执行交易因为这是第一个会让我认真思考“如果 LLM 出错系统还能不能兜住”的问题。这篇文章完整介绍一个我自研的生产级交易型智能体AI Shopping Guide它不是 Prompt 工程展示也不是工具堆砌而是一个真正考虑了状态、权限、回滚、安全与可观测性的 AI 应用系统。一、为什么要“反直觉”地做一个这么复杂的系统在大量 Agent 项目中我反复看到三种常见风险LLM 拥有直接写业务状态的能力系统状态与对话状态混杂在 Prompt 中出错只能靠“再问一次”这些在“查资料 / 写代码”类 Agent 中问题不大但在交易型系统中是致命的。所以这个项目从第一天起就立了三条不可妥协的原则原则一句话解释LLM 零写权限LLM 永远不能直接修改任何业务状态状态机硬闸门关键动作必须经过 FSM 决策纯函数执行订单编辑是确定性的、可回滚的二、整体架构概览职责清晰而不是“一个 Agent 解决一切”系统采用清晰分层 克制设计而不是把所有能力堆进一个 Agent。前端 (Next.js / React) ↓ API Routes (BFF 安全拦截) ↓ ToolLoopAgent执行引擎 ↓ FSM状态与权限控制 ↓ 工具系统查询 / 下单 / 存储 ↓ Redis / Vector / 可观测性为什么不是“一个大 Agent”因为在生产环境里Agent ≠ 系统控制器。LLM 擅长理解意图但不适合管理状态处理边界条件保证一致性做最终执行决策所以我把它降级为“建议者”。三、Agent 设计ToolLoopAgent prepareStep 路由模式系统并没有让 LLM 自由选择工具而是通过ToolLoopAgent prepareStep明确控制每一轮行为。Agent Loop 核心思想Step 0必须先问 FSM —— 我现在能不能干这件事 Step 1如果是交易路径走强约束执行 Step 2才允许进入 auto 模式自由查询这种模式解决了一个关键问题“Agent 是在思考还是在执行”而不是让这两件事混在一起。四、FSM整个系统最重要的“安全闸门”这是一个极简但强约束的三态 FSM状态含义IDLE空闲 / 查询态AWAITING_CONFIRMATION等待用户确认EXECUTING系统自动执行核心规则非常重要只有 EXECUTING 状态系统才允许 createOrderLLM 在 AWAITING_CONFIRMATION 状态下被禁止调用业务工具所有状态变更必须由代码触发不接受 LLM 直写FSM 不是“为了优雅”而是为了兜底。五、订单系统纯函数草稿编辑而不是“让 LLM 写 JSON”订单编辑的核心不是 Prompt而是一个纯函数applyActionsToDraft(draft, actions) → newDraft | error为什么这是整个系统的“定海神针”每一步编辑确定性任一 action 失败整体回滚不依赖 LLM 的“猜测正确性”LLM 只负责输出**“我想做什么”**而系统代码负责决定“你能不能这么做以及结果是什么”六、检索系统不迷信向量不排斥传统方法在商品搜索上我没有走“纯向量”的流行路线而是选择BM25 向量检索 动态权重融合原因很现实场景BM25Vector冷启动✅❌可解释性✅❌语义泛化❌✅系统会根据 query 特征自动调整权重而不是一刀切。七、防御深度一个请求要经过 6 层防护层级防护点L0会话 / 页面 / Tab 隔离L1前置拦截负数、nonsenseL2Agent 意图分类L3FSM 状态闸门L4业务字段级校验L5本轮地址隔离这不是“过度设计”而是对 LLM 不确定性的尊重。八、可观测性看得见 Agent 在“想什么”系统接入 Langfuse但做了两个关键约束可观测 ≠ 强依赖追踪失败不影响业务每一次FSM 状态转移工具调用记忆读写都有独立 Span可以完整还原 Agent 行为路径。九、这套架构解决了什么问题问题是否解决LLM 幻觉✅非法写状态✅交易误执行✅多轮对话错乱✅可回放 / 可调试✅十、总结这是一个“工程视角”的 Agent而不是 Prompt 展示这个项目我最满意的地方不在于功能多少而在于我敢把它放到生产环境我敢让别人 review 架构我敢在面试中被深挖每一个决策Agent 的未来不是“更聪明的模型”而是“更克制的系统设计”。项目演示 视频演示https://pan.baidu.com/s/1mMAHbi_Vz26D6gQfXHmfGQ?pwdgqfn
