企业官网建设流程全解析

1. 这篇技术文章想回答什么问题

过去一年，几乎所有关注 AI 应用落地的人，都听过一个词：Agentic Commerce。从投资路演到技术大会，从大厂产品 PR 到独立开发者的 demo，它被描述成电商的下一个形态——用户不再打开 App 搜索、比价、下单，而是让一个 AI Agent 帮自己完成购物决策，甚至自动完成交易履约。

但现实很冷静：Agentic Commerce 到今天为止，仍然处在非常早期的阶段。真正跑通的生产级案例少，稳定盈利的更少，多数项目停在 demo 和 POC（概念验证）阶段。如果你在电商公司做技术，大概率已经收到过类似指令："研究一下 Agentic Commerce，看看我们能不能做。" 但等你翻开资料，会发现网上绝大多数内容都在讲概念和愿景，真正能指导落地的工程细节非常少。

这篇文章想回答一个更直接的问题：这项技术没有大规模起飞，到底是卡在模型能力上，还是卡在工程体系上？

我的判断是：瓶颈不在大模型能不能"理解"购物意图，而在现有工程体系支撑不了"决策型系统"所需要的确定性、可控性和可验证性。这不是一个算法问题，而是一个系统问题。下面我会拆开来讲，并且会给出工程团队现在就能开始实践的落地路径和代码骨架。

2. 先把概念边界讲清楚：Agentic Commerce 不是聊天机器人，也不是推荐系统

讨论一个技术为什么没落地，最容易犯的错是把概念混在一起。所以我们先界定边界。

2.1 它和传统电商系统的区别

传统电商系统的用户路径是 "人找货"：用户输入关键词，搜索引擎返回商品列表，推荐系统根据历史行为猜测偏好，用户自己完成比较和决策。整个链路里，决策权在用户，系统只提供候选和辅助信息。

Agentic Commerce 的设想是把决策权部分甚至全部转移给 AI Agent。用户只需要表达一个模糊目标，比如"给我安排一套春季通勤穿搭，预算 3000 元以内"，Agent 需要自己完成：

• 理解用户偏好、历史订单、尺码、风格
• 搜索候选商品，跨店铺比价
• 判断库存、配送时效
• 结合用户预算做出推荐和排序
• 在用户授权后完成下单、支付、物流追踪

这已经超出了传统推荐系统的边界。它需要的不是一个更好的排序模型，而是一个能独立执行多步任务、并在不确定信息下做决策的自主系统。

2.2 它和 Chatbot / Copilot 的区别

很多人把 Agentic Commerce 理解成"能聊天的购物助手"，这其实是严重的低估。

这个表格想说明的是：Agentic Commerce 的问题不只在于"模型能不能 chat"，而在于"系统敢不敢为模型的决策负责"。这决定了它不可能像聊天机器人一样快速铺开，也决定了它的工程要求完全不同。

2.3 为什么要区分这些概念

因为不同阶段的团队，实际能做的事不一样：

• 如果你的目标只是做一个"智能导购助手"，本质是对话系统 + 检索增强，今天的技术栈已经可以支撑；
• 如果你想做的是"授权 Agent 自动下单"，就需要处理支付、风控、售后、合规等一系列高确定性要求；
• 如果你想把两者连起来，做成一个能替代人类执行完整购物流程的 Agent，那就必须解决这篇文章后面要讲的全部问题。

明确这一点，我们才能理解：Agentic Commerce 真正难的不是"生成"，而是"可靠"。而这个可靠，不是靠调 prompt 能解决的，需要工程体系整体升级。

3. 直接原因：demo 很惊艳，生产环境很骨感

既然概念本身有明确价值，为什么没有大规模落地？最容易观察到的一层原因是：Demo 和生产环境之间的差距太大了。

3.1 Demo 中的成功是预设条件下的成功

绝大多数 Agentic Commerce 的 demo 视频，都是在以下条件下展示的：

1. 商品池经过人工筛选，数量有限，不存在垃圾商品和虚假信息；
2. 用户意图提前设计好，Agent 只需要在一个窄路径上完成任务；
3. 底层调用的是测试环境的 mock API，不涉及真实库存、价格波动和支付；
4. 没有同时跑上千上万个用户的并发请求，不需要考虑预算上限。

在这些条件下，当前的大模型确实可以展示出很好的任务拆解和工具调用能力。但进入生产环境后，情况完全不同。

3.2 生产环境的真实复杂度

真实电商环境里，Agent 要处理的问题包括：

• 商品数据噪声：同一个商品可能有多个 SKU，价格随时变动，库存时有时无，图片和详情页可能充满营销话术，甚至有些商品链接本身就是虚假的；
• 用户意图漂移：用户前一刻说要买商务通勤装，后一句又提到周末要去露营，Agent 需要判断哪个才是当下真正要执行的目标；
• 跨系统状态一致性：下单时看到的库存、价格和实际支付时不一致，这是电商系统的常态；
• 长尾场景无穷无尽：优惠券叠加规则、区域限售、发票要求、售后政策，每一个都会在真实场景中冒出来。

一个在生产环境跑的真 Agent，需要为这些情况准备策略，而每多一个策略，系统复杂度就往上涨一个台阶。

3.3 一个更根本的问题：概率系统做确定性业务

这是我认为最关键的一点，值得专门解释。

大模型在本质上是一个概率生成系统——同一个输入，多次调用可能得到不完全相同的输出。而电商交易在本质上是一个确定性业务——订单号、支付金额、库存扣减，任何一个环节出现不确定性，都会变成资损或者客诉。

你可能觉得：我们可以在 Agent 后面加一层规则和校验，把不确定性挡住。但问题在于，Agent 的中间步骤越多，概率性积累的风险就越大。如果 Agent 要执行 8 个步骤，每个步骤的准确率都是 95%，那整体成功率只有 66%；如果每个步骤是 99%，整体也只有 92%。这对聊天场景可以接受，但对交易场景远远不够。

Agentic Commerce 想要规模化落地，第一步不是提高单次生成质量，而是建立一套机制，把概率系统的误差控制在交易系统能够容忍的范围内。这需要工程架构上做分层，而不是在模型层面解决。

4. 结构性原因：缺少"端到端可验证"的工程基座

如果说上一节讲的是"生产环境复杂"，这一节的判断更直接：当前 Agent 工程体系，还没有为交易系统准备好"可验证性"这个最基本的基础设施。

4.1 传统软件的验证方式，很难直接套用到 Agent 上

传统软件工程里，我们有单元测试、集成测试、回归测试，有 CR（代码评审）、CI/CD，有配置管理和灰度发布。这些机制的共同前提是：系统的行为是确定的，我们可以对一次代码变更写出明确的期望输出。

到了 Agent 系统里，这个前提被动摇了。同样一个 prompt，同一套工具，模型可能给出不同的路径。一个功能做出来了，但"怎么证明它是对的"这件事，比"把它做出来"难得多。

具体表现在：

• 没有标准的测试集：传统系统可以用真实历史数据做回归，Agent 系统需要的是"意图 + 期望行为路径 + 期望结果"三类数据，这需要大量人工标注；
• 没有稳定的断言方式：传统测试断言结果是确定的，Agent 的结果是文本，如何判断"推荐了正确商品"这件事本身有歧义；
• 没有成熟的混沌测试方案：Agent 对外部工具调用失败、模型输出格式异常、用户中途改口，这些异常组合几乎无法穷举。

4.2 可观测性的颗粒度远远不够

做电商的人都知道，一个交易系统必须有全链路追踪：从用户请求到订单落库，每一步都要有日志、traceId、监控指标。否则出了问题，根本无法定位。

但 Agentic Commerce 需要观测的粒度又多了一层：不仅要看到"系统做了什么"，还要看到"模型为什么要这么做"。这包括：

• 模型接收到什么上下文？
• 它选择了哪个工具，为什么？
• 工具返回了什么，模型如何解读？
• 如果 Agent 中途改变了计划，是什么信息触发的？

这类"决策过程日志"不是传统日志系统的标准能力。现在的做法通常是靠 LangSmith、Langfuse 之类的 trace 工具去补，但距离电商交易系统要求的审计级别还差得很远。

4.3 缺少标准的评测与准入机制

在没有可靠评测之前，任何 Agent 功能上线都是一场赌博。传统电商上线一个推荐位，可以靠 AB 测试看转化率、GMV 等指标；但 Agent 系统上线后，最关键的指标——"用户是否对 Agent 的决策满意"——很难自动化衡量。

更麻烦的是 Agent 系统的评测有滞后性：用户可能在一周后因为 Agent 推荐的某件商品质量差而申请退货，这个信号会延迟很久才能反馈到系统。这让"快速迭代、快速验证"的互联网方法论变得苍白。

我的判断是：Agentic Commerce 起飞的前提之一，是先出现一个行业级或至少企业级的标准评测集和准入流程。这一步没做好，后面的规模化都无从谈起。

5. 成本原因：多步 Agent 调用会指数级放大成本

关于成本，行业内讨论其实不少，但很多讨论停留在"API 单价贵不贵"的层面。实际真正的问题是：一个多步 Agent 任务的成本，不是单次推理成本的简单叠加，而是多次生成、工具调用、失败重试的综合成本。

5.1 成本被系统性低估

假设一个 Agentic Commerce 任务需要经历"理解需求 → 搜索 → 比价 → 推荐 → 确认 → 下单"6 个阶段，其中搜索和比价阶段可能各有 3 次 LLM 调用。一个任务下来，可能涉及 10 次以上 LLM 推理调用。

而你看到的每一次"成功调用"背后，还有大量你看不到的成本：

• 失败重试：工具调用返回异常时，模型要重新理解错误信息并调整计划，这会产生额外的 token 消耗；
• 上下文累积：每一步的对话历史都会追加到后续请求里，越往后单次请求的 token 成本越高；
• 多候选生成：有些系统为了让决策更可靠，每次会生成多个候选方案让模型自评，成本乘上数倍；
• 评测和仿真：上线前需要跑大量离线评测，这部分成本常常被忽略，但开销巨大。

5.2 成本控制需要从架构层面解决

单纯"选一个便宜的模型"解决不了问题。更合理的方式是分级使用模型、控制上下文长度、设计缓存机制。比如：

• 意图识别、信息抽取这类简单任务，用小型模型 + 强约束的 prompt 模板；
• 只有涉及复杂推理、多步规划、争议裁决的任务，才调用满血旗舰模型；
• 对用户画像、商品属性、历史订单这类稳定信息，提前索引和缓存，不要每次都放进上下文；
• 设计"预算熔断"机制，当单个任务的累计成本超过阈值，自动降级为人工接管。

这块我会在后面给一个实际代码示例，属于现在的工程团队马上可以动手优化的方向。

5.3 成本究竟会降到什么水平才算临界点

我们无法准确预测（也不应该声称某个具体数字），但可以给出一个判断框架：只有当"Agent 完成一个订单的边际成本"低于"人工客服处理的边际成本"时，规模化才有商业逻辑。不同品类、客单价、毛利率，这个临界点完全不同。高客单价的奢侈品、复杂决策的 3C 产品，能承受的成本远高于低毛利快消品。

所以，一个理性的商业策略不是等模型降价后把 Agent 铺到所有品类，而是优先在容错成本高、决策价值高、毛利空间大的品类里先跑通闭环。

6. 信任原因：交易场景的容错率极低，责任归属不清

讨论 Agentic Commerce 时，还有一个经常被忽略的问题：用户对 AI 自动交易的信任门槛，远高于对 AI 生成内容的信任门槛。

6.1 错误类型完全不同

内容生成类 AI 犯错的代价是"信息不准"，用户最多觉得不靠谱，不会产生资金损失。但 Agentic Commerce 一旦出错，后果是直接的：

• 推荐了错误商品，用户退货的物流和人力成本谁承担？
• 下单后价格变动，Agent 按旧价格执行，差额谁负责？
• Agent 在多个平台比价后跳转到某个渠道，返利/佣金归属如何追溯？
• 用户投诉说"我从未授权这笔订单"，平台如何证明授权链路真实存在？

这些问题的本质不是技术问题，而是责任归属和信任架构的问题。

6.2 现在的技术方案能解决什么，不能解决什么

可以解决的部分：

• 通过"人工授权确认"环节保留最终决策权；
• 通过完整的操作日志和决策审计追踪，回放 Agent 每一步行为；
• 通过风控模型识别异常交易模式，人工介入复核。

暂时难以解决的部分：

• 用户对 Agent 的信任，需要经历大量"正确示范"才能建立，而一次严重错误可能摧毁所有信任积累；
• 行业统一的责任认定标准还没有形成，各平台规则不互通；
• 用户（尤其是下沉市场用户）对"把决策权交给 AI"这件事的心理接受度，还很不确定。

6.3 这决定了产品形态的设计方向

既然信任问题短期内无法根治，产品设计上就更应该遵循一个原则：永远给用户一个确认点，永远让用户保留退出权。

• 推荐阶段可以自主，下单阶段必须确认；
• 常规订单可以批量处理，大额/异常订单强制人工；
• 默认自动执行后，允许用户随时查看执行链路上的任意一步，并打断回调。

这不是技术保守，而是负责任的做法。Agentic Commerce 的落地路径，可能不是从"全自动"出发，而是从"半自动 + 强确认"逐步演进。每增加一层信任，就放开一部分自主权，才是更现实的方式。

7. 哪些场景会先跑通：从半自动到全自动的演进路径

讲了这么多阻碍因素，这一节回到建设性的角度：哪些场景最有可能先跑通 Agentic Commerce？

7.1 适合先落地的场景特征

根据前面分析的原因，我们可以反推出"最适合优先落地"的场景特征：

1. 低频、高客单价：用户愿意多花时间确认，Agent 一次错误造成的绝对损失可控；
2. 决策链路透明：用户能够理解 Agent 的推荐逻辑，不需要黑盒决策；
3. SKU 复杂度适中：商品属性结构化程度高，不需要在非结构化信息里猜；
4. 毛利空间足够：能覆盖 Agent 的成本，甚至因为提升客单价/转化率而带来增量；
5. 责任边界清晰：平台能够定义清楚 Agent 和用户的权责边界。

按这个标准，下面这些品类比"全品类自动购物"更可能先跑通：

• 高客单价的 3C 产品：用户需求明确（"5000 元以内、拍照好、续航强的手机"），决策参数比较标准化；
• 复杂决策的旅行预订：机票酒店组合、退改规则复杂，Agent 的价值足够大，用户愿意接受确认流程；
• 企业采购（B2B）：审批流程本身存在，Agent 辅助选型，人工保留审批权，天然自带责任归属体系；
• 订阅制/标品复购：用户购买频次高、行为稳定，Agent 学习成本低，信任可以逐步建立。

相反，低客单价、高 SKU 随机性、用户低价敏感的快消品场景，Agent 的短期价值反而有限——推荐错了损失不大，但用户不会因为一个 AI 助手替代自己刷商品流而付出多少额外成本。

7.2 一个建议的演进阶段模型

与其一开始就憋个大招做"全自动购物 Agent"，不如按这个节奏推进：

第一阶段：决策辅助（Copilot）系统帮用户做信息收集、比价、参数对比，但所有交易动作由用户手动完成。这个阶段本质上还是工具增强，用户承担全责，系统只需要保证信息的准确性。

第二阶段：半自动执行（Semi-Agentic）系统可以代用户执行部分无风险或低风险操作（查询库存、加购物车、填写信息），但支付环节必须用户确认。这个阶段系统承担的是执行准确性和信息正确性，用户保留终审。

第三阶段：授权自动执行（Autonomous under Supervision）用户在特定场景、特定预算额度内授权 Agent 自动完成交易，系统提供完整的操作审计、异常拦截和熔断机制。这个阶段系统才真正承担交易链路的责任，对工程体系的成熟度要求极高。

第四阶段：完全自主（Fully Autonomous）Agent 长期独立执行日常采购并自行做出绝大多数决策。这是最理想化的形态，需要行业级基础设施和监管框架的成熟。从现状看还有相当长的距离。

团队在规划 Agentic Commerce 时，最理性的选择是先在"第二阶段"设计产品闭环，积累数据和信任，再逐步放开到"第三阶段"。跳过阶段直接做第四阶段的尝试，大概率会踩在信任和责任的雷区上。

8. 工程团队现在就能做的：搭建 Agentic Commerce 落地基座

前面的分析主要讲现状和原理，这一部分是对工程师真正有用的环节。哪怕你现在只是在一个普通电商项目里，仍然可以先搭建三个基础能力：决策追踪、分级模型路由、人工审批闭环。这三件事不依赖行业标准，今天就可以开始。

8.1 决策追踪：让每一次 Agent 行为都可审计

要做 Agentic Commerce，第一件事不是把模型接进来，而是先把"决策日志"设计好。下面是一个简化的决策事件结构，用 JSON 表示：

{ "trace_id": "agct-20250415-abc123", "session_id": "user-87342", "timestamp": "2025-04-15T10:32:07+08:00", "agent_flow": "shopping_assistant", "step": "product_search", "model_call": { "model": "deepseek-v3", "input_tokens": 1823, "output_tokens": 421, "latency_ms": 876 }, "selected_tool": "search_products", "tool_args": { "query": "春季通勤穿搭", "budget_max": 3000, "category_ids": ["men_clothing", "shoes"] }, "tool_result_summary": "返回 25 个商品，按相关性排序", "model_decision": "选择其中 3 个商品进入候选列表", "decision_reason": "符合预算上限，品牌偏好匹配度高", "human_review_required": false }

这个日志结构的关键点：

• trace_id必须贯穿整个交易链路，方便 join 订单系统的日志；
• step和selected_tool可以还原 Agent 执行路径；
• model_call记录成本指标，方便算单任务成本；
• decision_reason不一定百分百可靠，但可以作为人工审计的线索；
• human_review_required是给下游审批系统传递信号的字段。

建议把这个日志当成交易日志同等对待，写入独立的审计存储。它和后端服务日志的区别在于：后端日志回答"系统发生了什么"，决策日志回答"Agent 为什么这么做"。

8.2 分级模型路由与预算熔断

这里给出一个可落地的 Python 示例，实现一个简单的分级调用决策函数：

""" 文件路径：agentic_commerce/llm_router.py 功能：根据任务类型和预估成本，选择不同级别的模型，并设置预算熔断 注意：模型名称和配置请以实际项目为准，这里演示的是路由思路 """ import time import json from dataclasses import dataclass, field @dataclass class RouterConfig: light_model: str = "light-llm" # 小模型 heavy_model: str = "heavy-llm" # 旗舰模型 max_task_cost: float = 0.08 # 单任务最大成本，单位：美元 max_task_steps: int = 12 # 单任务最大步骤数 fallback_to_human: bool = True # 超过预算是否强制人工 cost_history: list = field(default_factory=list) def classify_task(user_intent: str) -> str: """ 简单意图分类，决定使用哪条执行路径。 返回：light | medium | heavy """ simple_keywords = ["查物流", "看订单", "查优惠券"] complex_keywords = ["对比", "推荐", "预算", "安排", "计划", "哪个更合适"] for kw in simple_keywords: if kw in user_intent: return "light" for kw in complex_keywords: if kw in user_intent: return "heavy" return "medium" def call_llm_with_router(user_intent: str, context: dict) -> dict: """ 分级调用 LLM。这里用 sleep 模拟调用，实际项目中替换为真实 SDK。 """ level = classify_task(user_intent) model_name = { "light": RouterConfig.light_model, "heavy": RouterConfig.heavy_model, }.get(level, RouterConfig.light_model) # 实际项目中应该从 SDK 返回结果解析出 token 数和耗时 start = time.time() # mock 调用 response_text = f"[{level}] 任务已处理: {user_intent}" time.sleep(0.05) latency_ms = int((time.time() - start) * 1000) cost_record = { "level": level, "model": model_name, "input_tokens": 500 if level == "light" else 3000, "output_tokens": 100 if level == "light" else 800, "latency_ms": latency_ms, } RouterConfig.cost_history.append(cost_record) # 熔断检查 total_cost = sum(_estimate_cost(c["model"], c["input_tokens"], c["output_tokens"]) for c in RouterConfig.cost_history) if total_cost > RouterConfig.max_task_cost: return { "status": "needs_human", "message": "任务成本超过预算阈值，已转人工处理", "cost_history": RouterConfig.cost_history } return { "status": "ok", "level": level, "model": model_name, "response": response_text, "accumulated_cost": total_cost, "cost_history": RouterConfig.cost_history } def _estimate_cost(model: str, input_tokens: int, output_tokens: int) -> float: """ 估算单次调用成本，真实项目中应该用对应模型官网的价格列表。 """ rate_map = { "light-llm": {"input": 0.0001, "output": 0.0002}, "heavy-llm": {"input": 0.001, "output": 0.002}, } rates = rate_map.get(model, rate_map["light-llm"]) return input_tokens / 1000 * rates["input"] + output_tokens / 1000 * rates["output"]

这段代码演示的是三层设计：

1. 意图分类器：把简单任务和复杂任务分流；
2. 成本累计器：记录每次调用的 token 用量和估算成本；
3. 熔断器：超过预算后，不再继续尝试，而是降级转人工。

生产环境还要考虑并发任务隔离，不能把不同用户任务的成本记录混在一起，这个示例里用全局 list 只是演示思路。

8.3 人工审批闭环：交易动作必须留确认点

最后一个示例，演示如何在交易执行前插入人工审批环节：

""" 文件路径：agentic_commerce/checkout_guard.py 功能：在 Agent 执行下单动作前，插入人工授权检查 依赖：需要对接已有的订单系统、审批系统 """ from enum import Enum class RiskLevel(Enum): LOW = "low" MEDIUM = "medium" HIGH = "high" class ApprovalStatus(Enum): PENDING = "pending" APPROVED = "approved" REJECTED = "rejected" def calculate_risk_level(order_amount: float, user_history_count: int, new_merchant: bool) -> RiskLevel: """ 风控规则示例： - 金额小 + 老用户 + 非新店铺 => LOW - 金额大或新店铺 => MEDIUM - 金额大且是新店铺 => HIGH 实际项目应接入完整风控系统。 """ if order_amount < 500 and user_history_count > 10 and not new_merchant: return RiskLevel.LOW if order_amount > 5000 and new_merchant: return RiskLevel.HIGH return RiskLevel.MEDIUM def create_approval_task(order_snapshot: dict) -> dict: """ 创建审批任务，返回审批单。 这里只是骨架，真实项目需要写入审批库，并推送给用户/风控人员。 """ risk_level = calculate_risk_level( order_amount=order_snapshot["amount"], user_history_count=order_snapshot["history_count"], new_merchant=order_snapshot["new_merchant"] ) approval_id = f"appr-{order_snapshot['order_id']}-{risk_level.value}" if risk_level == RiskLevel.LOW: # 低风险场景：只要用户单点确认即可，不需要风控人工审核 approval = { "approval_id": approval_id, "status": ApprovalStatus.PENDING.value, "approval_type": "user_confirm", "message": f"本次消费 {order_snapshot['amount']} 元，请确认是否由 AI 助手代付。" } else: # 中高风险：需要用户确认 + 风控人员复核 approval = { "approval_id": approval_id, "status": ApprovalStatus.PENDING.value, "approval_type": "manual_review", "message": f"订单需要人工复核，原因：风险等级={risk_level.value}" } return approval # 调用示例 order_snapshot = { "order_id": "ORD-20250415-001", "amount": 3200, "history_count": 6, "new_merchant": True } approval_result = create_approval_task(order_snapshot) print(json.dumps(approval_result, ensure_ascii=False, indent=2))

这个例子的核心思想是：Agent 可以自主完成信息收集和推荐，但真正发生资金动作前，必须插入一个审批节点。审批的粒度可以由风险等级动态决定，低风险场景用户点一下确认即可，高风险场景引入人工复核。这种"自主 + 审批"的混合模式，比完全自动更适合当前阶段的用户信任水平。

9. 常见问题与排查思路

下面把我在这类项目里见过的高频问题做一个汇总，按照问题现象、可能原因、排查方式、解决思路来组织：

10. 工程团队现在应该采取的行动

分析到最后，落到可执行的结论上。如果你在一家电商公司做技术，并且被要求"评估 Agentic Commerce"，我的建议是不要先花大量时间调研概念，而是从下面三个最小动作开始：

10.1 打造一个带完整决策日志的"AI 导购" MVP

不要急着做自动下单。先做一个插入现有推荐流程中的 AI 导购助手，它只做两件事：分析用户真实需求、生成推荐结果。但从第一行代码开始，就引入完整的决策日志，记录每一次用户输入、模型输出、工具调用。这个 MVP 的价值是：让团队积累 Agent 行为数据，找到模型在真实用户输入下的失败模式，而不是被精心设计的 demo 误导。

10.2 构建一个离线评测集，开始做回归测试

从真实用户会话中挑选 500 到 1000 条有代表性的请求，请运营和客服团队标注理想行为（推荐结果、回复风格、是否要转人工），形成一个离线评测集。之后每改一次 prompt、每换一个模型，都跑一遍这个评测集，对比通过率。这一步能把"模型表现"从主观感受变成可量化的指标，是后续所有优化的基础。

10.3 设计资金操作的安全边界

在系统架构上，从一开始就把 Agent 的执行能力圈在一个范围内。具体来说：

• Agent 可以查询商品、生成内容、调用比价工具；
• Agent 不能直接发起支付，必须经过审批节点；
• 高金额/高风险操作必须由风控系统复核；
• 所有操作必须有完整审计日志，最小保留期限覆盖交易争议期。

这三件事不需要等到大模型能力再升级一轮才能做，现在就可以动手。等这三件事做得足够扎实，真正做全自动 Agent 时，基础才会稳固。

11. 关于 Agentic Commerce 后续演进的几个判断

最后，给出几个基于当前技术趋势的推断。它们不是定论，但是可以作为团队规划的参考。

第一，模型能力不再是 Agentic Commerce 的主要天花板。多步推理、工具调用、长上下文，这些能力在过去一年进步很快，接下来仍然会继续进步。不会因为"模型不够聪明"而阻碍落地，反而会因为"工程跟不上模型的决策速度"而形成新的瓶颈。

第二，Agentic Commerce 的竞争焦点会从"谁能做出惊艳 demo"，转向"谁能提供可靠、可审计、可评测的工程体系"。这和移动互联网早期很像：最终胜出的不是第一个做出 App 的公司，而是把 crash 率降到最低、把用户体验打磨到极致的公司。对 Agent 领域来说，这个"极致的工程体验"对应的是决策可解释、成本可控制、风险可熔断、行为可审计。

第三，行业级基础设施会出现，但早期是各家企业自建。Agent 的评测基准、安全协议、审计标准，目前还没有一个被广泛接受的行业方案。早期入场者会自建这套体系，这既是成本，也是壁垒。等到有企业跑出了行业标准，后面的追随者进入门槛会骤降，但先发优势和数据集壁垒已经形成。

第四，Agentic Commerce 的增长可能不是线性爆发，而是"慢热-爬坡-陡增"的路径。信任的建立需要时间，但一旦用户习惯了"AI 代决策 + 人工确认"的购物方式，行为转变的速度可能会比预期快。对技术团队来说，关键是在"慢热期"把数据、流程、基础设施沉淀好，而不是等风口来了再匆忙补课。

说得更直白一点：Agentic Commerce 不是"能不能做"的问题，而是"什么时候做、怎么做、用什么体系保障"的问题。它是一个系统工程问题，不是一个模型能力问题。现在入局不晚，但需要想清楚自己在这个链条里的位置——是做基础模型、做中间件、做场景应用，还是先把用户信任的土壤培育出来。每个位置都有机会，但需要的资源和节奏完全不同。