简介：文章围绕电商购物智能体的整体架构展开，重点对比同一套提示词、技能与工具契约在不同运行路径下的能力差异。通过梳理面向消费者与面向商家两类智能体的设计边界，说明托管式与自管式方案在控制力、接入成本、安全闸门、可观测性和运维复杂度等方面的区别，帮助技术团队在涉及订单、库存、价格等敏感业务时做出更稳妥的选型判断。
在电商购物智能体的落地过程中，很多团队都会经历类似的过程：演示环境里的对话很流畅，搜索商品、推荐组合、生成购物车方案都不错；但一旦进入真实业务系统，涉及库存扣减、价格读取、订单创建、售后政策查询等操作，开发者和业务负责人就会变得谨慎。
原因并不复杂。演示环境通常只关心“能不能完成对话”，而生产环境关心的是：
因此，对比不同运行路径，不只是技术选型问题，更关系到智能体系统能否安全、稳定地进入生产环境。尤其当智能体开始触达资金、库存和价格时，运行路径的差异会被迅速放大。
本文讨论的并不是两个互不相关的产品，而是同一套电商购物智能体能力在两种典型运行方式下的差异。
从设计上看，整套系统可以抽象为两个角色：
面向消费者的购物智能体：负责商品搜索、比价、组合方案、加购物车、回答订单与售后政策问题，并记录用户偏好。它对接的是商品目录、购物车、订单和政策系统，统一收敛到一个后端接口中。
面向商家的经营智能体：负责解读经营数据、维护商品信息、处理库存与订单异常、调整价格、策划促销活动。它对接的是分析、商品、库存、定价和营销系统，同样收敛到另一个后端接口。
两个角色各有五条核心业务流，以技能形式存在。关键点是：系统提示词、技能、工具契约和安全闸门只定义一次。
同一套定义可以运行在两条差别明显的路径上：
自管式运行路径：由业务方自行维护主循环，控制智能体每一步的工具调用、记忆抽取和强制取数逻辑。控制力最强，运行时行为最可控，但需要团队具备较强的工程能力。
托管式运行路径：由平台侧维护主循环，通过标准化接口调用企业自己的业务系统。接入更快，工程负担更小，但控制力相对弱，定制运行时行为的能力受限。
本文的核心就是比较这两类路径在电商购物场景下的具体差异。
在比较差异之前，需要先明确两者的共同基础，否则容易产生误解。
无论是自管式还是托管式，智能体的系统提示词只编写一次。提示词中约定的角色边界、业务规则、语气风格和安全要求，不会因为运行路径不同而需要重写。
技能目录是固定且一致的。例如“搜索商品”“组合购物车方案”“查询订单状态”“回答售后政策”等技能，都由同一组定义描述其输入、输出和适用条件。
工具契约描述的是智能体调用企业系统时需要遵循的接口约定，包括参数结构、返回格式、异常处理和幂等要求。这份契约只定义一次，不同路径都会遵循同样的约定。
安全闸门用于在敏感操作前进行拦截、确认或阻断。例如在真实创建订单前，可能要求重新验证库存和价格；在修改商品信息时，可能需要二次确认。这个闸门逻辑也只定义一次。
正是因为这些基础定义只有一份，所以当我们比较运行路径时，比较的不是“能不能做”，而是“在什么控制力度和工程成本下做”。
这是最根本的区别。
在自管式路径下，主循环由业务团队自己编写和运行。这意味着团队可以决定：
在托管式路径下，主循环由平台侧维护。团队只需要提供后端接口和工具契约，不必关心循环内部状态如何传递。其代价是，当需要扩展自定义行为时，只能依赖平台提供的能力边界。
在电商场景中，最敏感的不是“推荐了什么”，而是“是否真的下单”“是否真的修改了价格”“是否真的扣减了库存”。
自管式路径可以做到：
托管式路径虽然同样支持安全闸门，但闸门的触发方式、失败提示、重试策略和审计记录格式往往由平台控制。业务方可以实现“需要确认”，但很难完全自定义“确认前还要做什么”。
自管式路径需要团队承担主循环的开发、测试、部署和监控工作。这意味着需要配备熟悉智能体运行机制的工程人员。
托管式路径则更接近“接入即用”。团队的主要工作是实现后端接口，将商品、订单、库存、价格等系统能力暴露成工具契约。接入速度快，适合希望先验证业务价值的团队。
自管式路径的日志、轨迹和状态完全由团队自己掌握，可以方便地与现有日志平台和监控系统集成。当出现错误订单或异常价格变更时，排查链路更完整。
托管式路径的可观测性依赖平台提供的跟踪信息。关键行为可能都有记录，但定制化和与其他内部系统的整合程度会受限。
自管式路径在主循环中插入额外逻辑较为容易。例如，当用户偏好与价格敏感策略冲突时，可以自定义优先级规则；当需要接入内部风控系统时，可以在工具调用前增加风控校验节点。
托管式路径若要实现同等扩展，通常只能通过增加新的工具或调整提示词来间接完成，无法修改主循环本身。
| 对比维度 | 自管式运行路径 | 托管式运行路径 |
|---|---|---|
| 主循环归属 | 业务团队自行编写维护 | 平台侧托管维护 |
| 接入难度 | 较高，需开发主循环 | 较低，主要实现后端接口 |
| 控制力度 | 强，可自定义每一步运行逻辑 | 相对弱，受平台能力边界约束 |
| 安全闸门实现 | 可在严格自定义流程中使用 | 使用平台闸门能力，定制能力有限 |
| 敏感操作审计 | 可完整记录调用链和快照 | 依赖平台提供的审计信息 |
| 可观测性 | 易与内部监控和日志系统集成 | 集成深度受平台支持限制 |
| 扩展能力 | 容易插入额外逻辑和风控节点 | 主要通过新增工具或提示词调整实现 |
| 运维责任 | 团队承担主循环稳定性与版本升级 | 主循环运维由平台承担 |
| 适用阶段 | 生产环境、强合规场景、复杂业务规则 | 快速验证、中等复杂度、工程人力有限场景 |
当业务具备以下特征时，自管式路径更值得优先考虑：
例如，当购物智能体需要根据用户会员等级、历史订单和实时库存动态调整优惠方案时，自管式路径可以在主循环中灵活组合这些条件。
当团队面临以下情况时，托管式路径可以更快带来业务收益：
选型时不应简单判断哪种路径更好，而应回到一个核心问题：当智能体触碰资金、库存和价格时，边界责任是否清晰？
如果业务要求每一步敏感操作都具备完整、可定制的审计与控制能力，且团队具备工程能力，那么自管式路径更符合要求。
如果当前阶段的核心目标是快速验证业务价值，且敏感操作可以先通过标准闸门和二次确认满足风险控制要求，那么托管式路径是合理起点。
另一个现实策略是分阶段演进：先用托管式路径接入核心工具，验证智能体的交互质量和业务效果；随后在进入深水区之前，将关键流程迁移到自管式主循环。由于提示词、技能、工具契约和安全闸门只定义一次，这种迁移不会推倒重来。
从托管式路径迁移到自管式路径时，需要重点评估以下方面：
确保原有后端接口和工具契约在新路径下不做破坏性变更。尤其是参数结构、错误码和幂等语义，需要保持一致。
对历史运行记录中的订单、库存和价格操作进行快照保留。迁移过程中不要丢失关键审计信息。
确认智能体在不同路径下的身份标识、权限边界和数据隔离策略一致。尤其在涉及商家经营数据时，权限映射不能出现漂移。
自管式路径需要自行处理工具调用超时、部分失败和重试逻辑。应明确哪些操作可以自动重试，哪些必须人工介入。
迁移后需补齐主循环运行状态、工具调用成功率、安全闸门触发次数等监控指标，并配置相应告警。
电商购物智能体的关键挑战，不在于能否生成流畅的推荐对话，而在于如何安全地触碰订单、库存和价格等真金白银业务。
本文对比的自管式与托管式运行路径，本质上是在回答同一个问题：当智能体拥有行动能力时，边界责任应该放在哪里。
自管式路径把责任放在业务团队手中，用更高的工程成本换取更完整的控制力、审计能力和扩展能力。托管式路径把主循环交出去，用更低的接入成本换取更快的验证速度，但在敏感操作上的控制力相对有限。
理解这一差异之后，选择就不再是“哪个更好”的问题，而是要根据业务阶段、风险承受能力和工程资源，判断在当前时点应该承担哪一类成本。对于即将进入生产环境的电商团队而言，最稳妥的方式往往是：用统一的能力定义保持长期一致性，用分阶段的路径选择降低落地风险。