博客一个零售企业的 Web 端客服智能体上线三个月仍超时率 23%。问题不在模型，在五个被跳过的工程化决策：传输层选型、安全沙箱、错误链阻断、Token 成本模型、全链路可观测。
一个零售企业的技术负责人找到我们时，他们的 Web 端客服智能体已经"开发完成"三个月了。每次客户问"我的订单到哪了"，系统平均响应 4.7 秒，超时率 23%，任务完成率不到 60%。排查下来，模型选型没问题，Prompt 也打磨过多轮——真正卡住的是五个被跳过的工程化决策。本文把这五个决策掰开来讲，每个都附上我们在交付过程中踩过的坑和最终落地方案。
Web 端智能体与桌面端最大的区别在于：浏览器里没有持久进程，一切通信都走 HTTP。传输层的选择决定了整套系统的延迟上限、重连策略和鉴权复杂度。市面上三条路：SSE（Server-Sent Events）、WebSocket、以及 2025 年随 MCP PR #206 引入的 Streamable HTTP。我们在协议变天：新版 RC 无状态架构与 Streamable HTTP 深度拆解中完整分析过这次协议层面的变化，这里聚焦工程选型结论。
SSE 在 MCP 早期被选为标准传输方式，设计思路很朴素——HTTP POST 发请求，/sse 端点推结果。双通道分离在 Demo 阶段跑得通，但上到生产环境立刻暴露三个致命问题。腾讯云开发者社区的一篇技术分析给出了实测数据：1000 并发下 SSE 平均响应时间从 18ms 飙到 1.5s 以上，原因是每个 SSE 连接都要在服务端维持独立的长连接状态，Linux 默认 1024 文件描述符上限一碰就垮[1]。更头疼的是企业防火墙和代理服务器会主动掐断长时间静默的 SSE 连接——不是偶发，是必然。
Streamable HTTP 的解法很彻底：砍掉专用 /sse 端点，所有通信统一走单一端点（通常是 /mcp）。服务器根据响应内容动态决定是否升级为流式传输。对于 Web 端智能体，这意味着不需要维护双通道状态机，断线重连就是一次普通 HTTP 重试——天然幂等。
下面这张对比表是我们在三个实际项目中验证过的结论：
| 维度 | SSE（HTTP+SSE） | WebSocket | Streamable HTTP |
|---|---|---|---|
| 连接模型 | 双通道（POST + SSE 长连） | 全双工单通道 | 统一端点，按需流式升级 |
| 1000 并发延迟 | 1.5s+ | ~200ms | ~150ms |
| 断线重连 | 需重建双通道，状态易丢失 | 需心跳保活 | 无状态请求，天然幂等 |
| 企业防火墙穿透 | 差（长连接常被中断） | 中 | 优（标准 HTTP） |
| 鉴权复杂度 | 高（两通道各自鉴权） | 中 | 低（Bearer Token 一次） |
| 浏览器兼容 | 原生支持 | 原生支持 | 原生支持（标准 fetch） |
我们的结论：2026 年新起 Web 端智能体项目，直接上 Streamable HTTP。MCP 官方已在 2025 年 RC 版本中将 Streamable HTTP 列为推荐传输方式，原有的 HTTP+SSE 方案进入维护模式。阿里云开发者社区的一篇文章也印证了这个方向：长时任务场景下，协议层必须支持流式推送中间结果，而 Streamable HTTP 是目前唯一兼顾"无状态请求的运维简单性"和"按需流式的实时性"的方案[2]。
企业智能体最核心的价值是"能干活"——查 CRM、调 ERP、发邮件、操作数据库。但每多一个工具接入，就多一条越权路径。一个客服智能体如果不加约束地拿到了退款接口的调用权限，Prompt 注入攻击可以让它把全店订单退款。
MCP 的工具调用机制从 Function Calling 一路演进到今天的标准化协议，在工具层面提供了两层防护。第一层是工具声明机制：每个工具必须在服务端显式注册名称、描述、参数 Schema 和权限标记，智能体只能调用已注册的工具列表，无法动态发现或构造调用。第二层是OAuth 2.0 授权码流程的集成——智能体不直接持有 API Key，而是通过标准的授权码流程换取短期访问令牌，令牌的作用域在授权阶段由管理员划定。FastMCP 2.x 生产级部署中我们详细拆解过这套架构在工程上的落地方式。
工程上的落地要点：
required_scope，比如"查询订单"工具只需要 order:read，"创建退款单"需要 refund:write。智能体在不同会话中可能获得不同作用域的令牌。amount 参数传成负数试图"退款变充值"的情况，服务端校验直接拦截。一个反面教训：我们早期项目里，工具调用的鉴权做在了网关层（API Gateway），智能体侧直接持有长期 API Token。结果一次 Token 泄露后，攻击者绕过了智能体直接调用内部接口。现在我们的标准做法是：Token 永远不离开智能体运行时，所有外部调用经过 OAuth Proxy 做令牌交换——外部拿到的永远是短期、窄作用域的访问令牌。
这条是我们之前一篇关于智能体错误传播链分析的延续。核心结论一句话：多步推理中第 2 步的微小错误，到第 7 步会放大为不可恢复的方向性偏差。Web 端场景比桌面端更棘手——用户盯着浏览器等结果，不会容忍智能体在错误路径上推理 5 分钟。
阿里云开发者社区 2026 年 5 月的一篇文章点出了同样的困境：从"单次对话"到"长时任务"的跨越中，最容易被忽视的是中间状态的验证机制[2]。我们的工程实践是：每 3 步插入一个规则化检查点（Checkpoint）。
具体做法：
对于高频、高风险操作（如退款、权限变更），把第 3 步检查点替换为人工确认——智能体暂停推理，推送一条确认消息到运营面板，人工点击"继续"后才进入下一步。这个设计在零售客户的客服智能体中把错误退款率从 1.2% 压到了 0.03%。
Web 端高频智能体场景——比如电商客服、工单路由——每天数千次对话，Token 费用如果不做模型，月底账单会让你怀疑人生。但"一刀切用最便宜的模型"同样危险：复杂查询交给小模型，答非所问的返工成本远高于省下的 Token 费。
成本模型的核心是分级路由。BetterYeah 的 2026 企业智能体指南给出了一个被多家验证过的策略：将简单/常见问题路由到成本效率模型，复杂/罕见问题路由到高能力模型[3]。我们在实际项目中拆了三层：
| 层级 | 场景 | 推荐模型 | 单次对话 Token 成本（估算） |
|---|---|---|---|
| L1 意图识别 | "我的订单到哪了""退货流程是什么" | Gemini 3.5 Flash / Haiku 4.5 | 0.002–0.008 元 |
| L2 业务推理 | "这个订单为什么延迟，能加急吗" | Claude Sonnet 4.5 / GPT-4o-mini | 0.02–0.15 元 |
| L3 复杂决策 | "结合用户历史购买+库存+物流，推荐替代商品" | Claude Opus 4.7 / GPT-4o | 0.30–1.20 元 |
关键不是模型单价，而是路由准确率 × 缓存命中率。Gemini 3.5 Flash 的上下文缓存命中后单价低至 0.025 元/百万 Token——但如果路由把 L3 级问题误判为 L1，返工成本是缓存节省的 50 倍以上。我们现在的路由策略是"就高不就低"：分类器置信度低于 0.85 时，自动升级到上一层模型。
另一个被低估的成本项是工具调用本身的延迟和费用。一个客服智能体平均每次对话调用 3.7 次内部 API，如果每个 API 响应 200ms+，叠加效应会让对话体验明显变慢。我们的优化手段是工具调用并行化——不依赖彼此结果的 API（如"查订单"和"查用户等级"）同时发出，把串行 800ms 压到并行 250ms。
传统 Web 应用的监控三板斧是延迟、错误率、吞吐量。智能体多了一个维度：任务完成率——不是说 HTTP 返回了 200 就算成功，而是用户的问题是否被真正解决。
阿里云开发者社区的文章把"全链路可观测性"列为 2026 年企业智能体从 Demo 到生产的四大跨越之一，并指出当前产业现状：大多数团队的监控只覆盖了 API 调用层，对智能体推理链路上的中间状态完全盲视[2]。
我们的埋点方案覆盖四个层级：
技术实现上，我们用 OpenTelemetry 的 Span 嵌套来追踪整个推理链路——一个对话是一个 Trace，每个推理步骤是一个子 Span，工具调用是孙 Span。配合 Grafana 大盘，可以实时看到"当前有多少智能体会话正在执行、各处于哪一步、平均完成率"。这套方案在零售客户的项目中跑出了 94.7% 的任务完成率和 <800ms 的平均响应延迟。
以一个中等复杂度的 Web 端客服智能体为例（对接 CRM + 订单系统 + 知识库，日均 500–2000 次对话）：基础设施（云函数/容器 + 数据库）月费约 2000–5000 元，模型调用费月均 3000–15000 元（取决于路由策略和缓存命中率），加上初次开发的工程人力投入。总启动成本通常在 10–30 万元区间，后续运维月费控制在 1–2 万元。
桌面端智能体运行在持久进程中，状态天然保存在内存和本地文件系统；Web 端智能体每一次 HTTP 请求都是无状态的，需要外部存储（Redis/数据库）来保持会话上下文。这导致 Web 端的重连恢复、并发隔离、会话过期策略远比桌面端复杂——但优势是部署零门槛，用户打开浏览器就能用。
不需要。Streamable HTTP 是一个传输层机制，可以脱离 MCP 独立使用。它的核心价值是"统一端点 + 按需流式升级"，任何需要服务端向客户端推送实时结果的 Web 应用都可以受益。但如果你的智能体需要对接多个外部工具系统，MCP + Streamable HTTP 是目前最完整的组合——工具注册、安全鉴权、流式传输在一个协议栈内解决。
从我们交付的 7 个企业智能体项目来看，一个包含 3–5 个工具集成、具备多步推理能力的 Web 端智能体，从需求对齐到生产上线通常需要 6–10 周。时间主要花在工具对接（内部 API 适配、权限梳理）和安全审计上，模型调优反而只占 20% 不到的工时。
最后附上优码云（umayun）交付的某零售行业客户 Web 端客服智能体项目的关键指标，作为上述五个决策的落地验证：
如果你正在评估 Web 端智能体的落地可行性，或者已有的原型系统在生产环境中表现不及预期，查看我们的完整案例库，或直接联系我们做一次技术评估——通常在 1 个工作日内给出架构建议和成本估算。