企业官网建设流程全解析

这周 AI 圈子里值得琢磨的消息不算多，但三条线放在一起，基本能看出接下来半年的走向：一边是 Gemini 3.1 Pro 这样的旗舰模型开始认真谈“定价对标”，把 API 价格战拉到了新高度；另一边，智能体从 Demo 走向业务一线，销售、客服这些最传统的 SaaS 场景正在被逐一拆解；再加上本地推理在能效上的拐点信号，整个行业对“算力该怎么用”这件事，正在换一套计算方式在重新算账。

对做应用、做产品的团队来说，这三件事其实是一件事：模型能力不再是稀缺资源，怎么把模型能力组织成稳定的产品服务，才是真正的分水岭。这篇周报我不做新闻流水账，只挑这三个信号，分别拆一下背后的逻辑、成本账，以及落到项目里的实际影响。适合正在选模型、搭智能体、或者纠结“到底要不要做本地部署”的团队参考。

1. Gemini 3.1 Pro 定价对标：旗舰模型的价格锚点正在移动

1.1 定价对标到底在“对”什么

Gemini 3.1 Pro 这一波消息出来，圈内讨论最多的不是参数，而是“定价对标”四个字。很多人第一反应是问它对标谁，但稍微想深一层就会发现，问题更值得拆解：旗舰模型这个档位，定价锚点本来就不是随便定的，它同时锚定的是参数规模带来的成本、同类产品的竞争策略、以及客户对“高质量推理”的心理价位上限。

目前公开信息里虽然没给出最终价格表，但按这类旗舰模型一贯的定价逻辑，不外乎三块：输入 token 单价、输出 token 单价、上下文缓存价格。Gemini 3.1 Pro 这一代把长上下文作为核心卖点，那么在超长输入场景下的缓存折扣就会成为定价表里最关键的变量。因为真实业务里，绝大多数成本峰值来自反复调用同一批上下文——比如客服智能体把企业知识库塞进系统提示词，每次会话都在重复收费。缓存价格设计得不好，再低的单价也扛不住实际用量。

对标逻辑上，它真正较劲的其实是“单位推理成本下的综合能力”。模型厂商自己在算一笔账：如果输出质量能接近甚至超过上一代闭源旗舰，同时把价格压低到一个独立开发者能随手调用的水平，那么整个上层的应用供给就回不去了。换句话说，这次定价对标不只是对着竞品报价单做调整，而是在重新定义“旗舰模型该值多少钱”这件事。

1.2 算一笔账：按 token 付费的真实成本

做应用的团队看价格，通常犯一个错误：只看输入和输出的单价，忽略三个隐藏因素——请求的实际 token 结构、缓存命中率、以及批量接口的折扣幅度。理论上 Gemini 3.1 Pro 如果按主流旗舰区间定价，假设输入约为竞品的六折、输出约为七到八折，看起来是一个很划算的入场价格，但落到真实业务账单，完全可能是另一回事。

我按一个典型的 RAG 客服场景粗算过一笔账。假设每次用户提问，系统需要携带 1 万 token 的知识库上下文，生成 800 token 的回答。如果完全不命中缓存，一次会话的输入成本就是 1 万 token 的输入价。按市面上常见的输入单价来框算，一次对话大约花费 0.01 到 0.02 美元量级。听起来不多，但如果智能体日均承载 3 万次会话，一天就是 300 到 600 美元，一个月接近 1 到 1.8 万美元。这时候如果能命中缓存，输入部分的成本能压掉 80% 以上，账单瞬间变成了个位数千美元量级。

所以定价评测不能只看表面单价格局，要直接按自己的调用特征建模。我自己的习惯做法是拿三个典型场景各跑一周：高频短会话、超长文档分析、批量离线任务，分别统计输入输出比例和缓存命中率，再乘上最新价格表，才能判断“定价对标”到底是不是真的对自家项目有利。Gemini 3.1 Pro 这种走长上下文路线的模型，只有缓存设计到位，才可能把长上下文的价格优势真正落到应用层。

1.3 对开发者的实际影响

定价对标背后还有一个容易被忽视的影响，就是它直接决定了一批应用的形态。过去旗舰模型很贵的时候，开发者普遍不敢把长文档、大知识库直接塞进上下文，只能被迫做复杂的 RAG 切片、检索、重排，工程成本非常高。如果 Gemini 3.1 Pro 真的把长输入价格压到某个临界点，一批应用会重新回到“直接把原文喂进去”的极简路线，检索增强变成可选优化而不是必经步骤。

这会带来一个很具体的连锁反应：技术栈又要换一轮。做 RAG 的中间件团队要重新找位置，向量数据库不再是一切的入口，上下文工程会取代一部分提示词工程。对普通开发团队来说，这个阶段不该急着重构现有架构，但可以把手头最痛苦的检索链路做一次成本对比，看看到底是继续优化检索划算，还是直接换长上下文模型更省事。

2. 智能体冲击 SaaS：软件正在从“订阅”走向“按结果付费”

2.1 为什么说智能体在冲击 SaaS

SaaS 的经典生意模式是“按人头订阅”：卖的是软件使用权，不管客户用得好不好、有没有产生结果，月费照付。这几年转向按使用量、按 API 调用计费，已经算是一种妥协。但智能体的出现相当于把付费逻辑推到了另一个极端——按任务完成量计价。比如一个销售线索初筛智能体，可以按“有效线索条数”收费；一个售后客服智能体，可以按“成功解决的工单数”收费。客户不再为软件付钱，而是为结果付钱。

这种变化对 SaaS 厂商真正构成冲击的地方不在计费方式，而在交付边界。传统 SaaS 交付的是工具，客户拿到工具后要靠自己的人去用它。智能体交付的是“能干活的东西”，它把工具、判断、执行甚至一部分决策都包进去了。同一个客户，过去需要五个人操作一套 CRM 系统完成线索清洗，现在一个销售智能体跑一趟就能出结果，人员结构、预算结构、采购对象全变了。

举一个很典型的例子，智能体客服接入千牛这类电商客户端。以前商家要买客服软件、配知识库、培训客服人员，人力成本和软件成本是叠加的。现在一个智能体客服接进来，前期投入主要是知识库整理和流程配置，日常运行按会话量计费，边际成本很低。对商家来说，这不是“换了个客服软件”，而是把客服从固定成本变成了可变成本。预算决策从采购软件的 IT 部门，转移到了业务部门。

2.2 从销售智能体到客服智能体：两个真实的替换场景

我观察到的替换路径通常不是直接掀翻整套 SaaS，而是先从最标准化的模块开始切。销售智能体是最典型的高价值场景。销售流程里的线索初步筛选、客户画像补全、意向度打分、初次触达邮件的起草，这些环节高度流程化，非常适合智能体先跑通。一个合格销售每天最多认真跟进二三十个线索，但一个销售智能体在系统稳定的前提下可以覆盖上百条线索的初步摸底，再把人力的精力集中在最有价值的少数线索上。

这里涉及的不是简单的“能跑”问题，而是业务指标的重新定义。销售智能体到底算不算“冲击”了 CRM SaaS？短期内不算，因为 CRM 还是数据底座；但从预算结构看，客户会越来越倾向于为“有效线索数量”付钱，而不是为“一个账号的月费”付钱。二者的本质区别在于：SaaS 卖的是工具，用不好是你的问题；智能体卖的是结果，没结果就是它的问题。这个责任转移，会让销售团队的采购逻辑彻底变掉。

客服智能体则是另一种逻辑的替换。客服 SaaS 的核心价值是工单系统、知识库、人机协作界面，这些不会消亡，但“值班”这件事正在被智能体吃掉。前几个月我在几家公司看到同一个趋势：夜间咨询和节假日咨询全部交给智能体处理，人工只负责转接过来的疑难客诉。这种切换一旦完成，客服团队从两班倒变成只保留日班，节省的远不止软件订阅费，还包括大量人力成本。

2.3 被冲击的不是软件，而是交付模式

说智能体要干掉 SaaS，这个判断太简单了。严格说，被冲击的是“躺着收订阅费”的交付模式。SaaS 软件本身的功能——数据存储、流程管理、权限控制、报表分析——依然是刚需，但这些功能正在退居为底座，真正的成品是跑在底座之上的智能体服务。

这意味着，传统 SaaS 厂商只有两条路：要么自己变成智能体供应商，把软件能力封装成可调用、按结果计费的智能体；要么退到幕后，做一个被智能体调用的“工具底座”。两条路都不好走，但第二条路的利润空间会被明显压缩，因为它的价值越来越像基础设施，而基础设施的定价权从来不在自己手里。

对应用开发团队来说，这个趋势反而带来一个窗口期。智能体冲击 SaaS 的过程中，最缺的不是模型，而是行业 Know-how 向智能体工作流的转化。懂销售流程、懂售后链路、懂数据权限边界的人，现在有机会用一个智能体框架把这些经验固化下来。平台搭建的智能体和用 Python 构建的智能体背后，拼的其实就是这个转化能力，下一节我会具体展开。

3. 本地推理的能效拐点：Token per Watt 才是硬指标

3.1 什么是能效拐点

本地推理不是什么新概念，端侧跑模型的尝试一直都有，但长期处于“能跑但不好用”的尴尬状态。这周之所以把“本地推理的能效拐点”单独拿出来说，是因为几个维度同时发生了变化：模型变小但能力不缩水、手机和 PC 的 NPU 算力提升、以及能效比的计量单位从“每秒能跑多少 token”变成了“每瓦特能跑多少 token”。

过去判断本地推理行不行，大家只看推理速度：每秒输出 10 个 token 就觉得能用，20 个 token 就算流畅。但在真实产品里，速度只是体验的一半，功耗直接决定设备发热、续航和应用形态。能效拐点的意思是：同样一个 7B 级别模型，在最新的端侧芯片上，每秒能生成的 token 数除以功耗，跨过了一个临界值——每瓦特跑出的 token 数足够高，让“本地推理”成为日常应用可依赖的默认选项。

这可以类比成电动车与燃油车的分水岭。燃油车看百公里加速，电动车时代大家改看百公里电耗，因为电耗直接决定续航和电池成本。本地推理的能效拐点也一样，模型不是跑不动，而是过去跑得太费电、发烫、续航崩，产品根本不敢默认开启。当每瓦特能效跨过某个阈值，产品经理才敢把“本地推理”作为默认选项写进需求文档。

3.2 量化与硬件加速：本地推理为什么“忽然”变快

这一波本地推理能效提升，主要来自三个方向。第一是量化技术的成熟，从 8bit 量化到 4bit 量化，模型体积和内存占用大幅下降。一个 7B 模型用 4bit 量化后可以压到 4GB 左右，这就在主流设备的物理内存和 NPU 缓存可承受范围内了。第二是芯片厂商在端侧 NPU 上的投入，高通、联发科、苹果这几代芯片的 AI 算力翻倍式增长，并且配套的推理框架和算子库逐步完善。

第三是大模型推理框架针对特定硬件的适配，比如 llama.cpp 这类框架不断优化调度器、内存布局和线程分配，同一个模型在新旧框架上的表现可能差出一倍以上。我实测过一个 8B 模型，同样的设备和模型文件，新版本的推理框架配合硬件加速，token 生成速度提升了近 80%。所以很多时候感觉“本地推理突然变快了”，并不是模型本身变了，而是工程侧终于把硬件潜力挖了出来。

这里要提醒一点，量化不是无损的。4bit 量化在复杂推理和代码生成上的能力损失是真实存在的，尤其对需要数字计算和工具调用的场景影响会更明显。我的建议是：先拿自己实际业务的评测集跑一遍对比。很多团队只拿一两个问题测一下“感觉差不多”就上生产，后面遇到边界 case 时排查起来非常痛苦。

3.3 什么场景最适合本地推理

从成本账看，本地推理最适合三类场景。第一类是隐私敏感型业务，比如医疗问答、法律咨询、企业内部的数据分析，数据不出设备本身就是刚需。第二类是延迟敏感型交互，比如语音助手、实时翻译、机械臂控制，本地推理省掉网络往返的那几十毫秒，在体感上可能是决定性的。第三类是高频但低复杂度的任务，比如文本分类、信息抽取、意图识别，这类任务不需要顶级模型，只要能跑的模型加低延迟就足够。

我在实际项目里用得最多的是第三类。举个例子，智能体的意图路由模块：用户先输入一句话，系统要先判断这个意图是“查订单”还是“转人工”还是“闲聊”，然后再决定要不要调云端大模型。这个判断用本地小模型做，速度快、免费、稳定，把高成本的云端调用量过滤掉一大半。单看每次调用的价格可能不觉得多，但乘上日活用户数和调用频率，一个月能省下的额度相当可观。

OpenClaw 加 ROS 这类机器人方向的项目更是本地推理的受益者。机器人执行任务时，动作决策和避障判断都必须本地完成，网络往返的延迟不可接受。以前我们做这类项目只能用规则加传统算法，现在一个量化后的小模型嵌入到机器人主控里，可以直接根据环境描述生成动作序列。虽然不能处理特别复杂的推理，但已经足够让机器人具备“听得懂人话”的基本能力。

3.4 本地推理的边界与坑

但本地推理绝不是万能的。最大的难点是模型能力天花板：本地能跑的模型规模通常是 7B 到 14B 级别，再大就超出端侧硬件的内存和算力范围。这意味着复杂推理、长文档深度分析、多步工具调用，本地模型还是拿不稳。我见过一些团队踩过的坑是：为了追求本地推理的零成本，硬把一个需要复杂 reason 的任务塞给小模型，结果准确率大幅下滑，最后还要靠云端模型兜底补错，整体成本反而更高。

另一个容易被忽略的坑是内存带宽。本地推理的瓶颈往往不是算力峰值，而是内存带宽。模型权重需要不断地从内存搬到计算单元，内存带宽不够，算力再强也跑不快。这也是为什么高性能手机跑大模型比老设备流畅那么多，不只是 NPU 变强了，内存带宽和容量也同步升级了。

做本地推理选型时，我建议重点关注三件事：第一，模型必须是量化后能完整放进内存的，预留操作系统和其他应用的内存占用；第二，要实测连续推理的发热和降频情况，跑五分钟和跑十分钟的性能往往完全不同；第三，要规划好本地模型和云端模型的混合路由，让每个请求都走最合适的路径。只有把这些都想清楚，本地推理的能效拐点才能变成你自己的成本拐点。

4. 智能体工程化：从 Demo 到生产的路有多长

4.1 框架选型：Coze、Dify 与自研的取舍

智能体从 Demo 到生产，第一步往往卡在框架选型上。现在市面上智能体平台和框架非常多，Coze、Dify、LangChain、以及各种自研方案，各有各的适用场景。我的建议是：需求越标准化，越倾向平台；需求越定制化，越倾向代码自研。不存在放之四海而皆准的答案，只有匹配度不同的取舍。

Coze 这类平台的优点是上手极快，图形化编排、插件生态、发布渠道都是现成的，非常适合快速验证业务逻辑。如果一个智能体项目只需要“知识库问答 + 简单工具调用 + 多渠道发布”，用 Coze 两三天就能搭出可用版本。但它的缺点是深度定制能力受限，复杂的权限控制、私有数据回流、精细的 prompt 版本管理，平台很难满足。遇到这类需求，就要走上代码路线了。

Dify 这类偏工程化的平台处于中间地带，它提供了数据接入、工作流编排、模型管理等模块，比纯代码搭建快，比 SaaS 平台更可控。但要注意，平台不是万能的，接入越多，平台的抽象层成为瓶颈的可能性越高。我见过一个团队在 Dify 上搭建了一个看起来完备的客服智能体，但切到生产环境后发现并发调度和监控不满足要求，最后还是推倒重写成 Python 服务。选型时多想想半年后的规模，能少走很多弯路。

4.2 多智能体协作：任务编排与上下文传递

比单智能体更难的是多智能体协作。真实业务很少能由一个智能体独立完成整个流程，常见的是“主控智能体 + 多个专业智能体”的协作结构。主控负责理解用户意图、拆分任务、派发给专业智能体，专业智能体各自处理一块，最后再由主控汇总结果。这种结构下，最核心的难点是任务编排和上下文传递。

任务编排要解决的是“谁先做、谁后做、可以做还是必须做”的问题。我自己的经验是流程优先用代码固化，而不是全靠模型自由发挥。比如一个“客户投诉处理”智能体，分流到售后查单、方案生成、补偿审批这几个环节时，审批节点是硬规则，不能交给模型判断。该用代码判断的用代码判断，模型只负责生成内容和做非结构化决策，这样系统才可控。

上下文传递则是另一个大坑。多智能体协作时，每个子任务需要什么上下文、父任务要把哪些结果回传、消息太长会不会爆掉 token 上限，这些都要提前设计。我的建议是：上下文只传必要信息，别把整场对话都塞给每个子智能体；关键数据用结构化字段传递，不要在自然语言里靠模型去“理解”。多智能体协作的价值不是把所有事情都抛给模型，而是让每个智能体在有限的上下文里把一件事做到位。

4.3 行为审计：智能体最容易被忽略的一环

智能体上了生产之后，行为审计属于“不做不知道，做了吓一跳”的环节。很多团队搭建智能体时只顾着调 prompt、测准确率，没有想过一个问题：如果智能体做了意想不到的事，你怎么知道？智能体的行为不是纯代码逻辑，它有自主决策的成分，这决定了它可能在你没预设到的路径上做出动作。行为审计要解决的核心问题就是：发生了什么、为什么发生、要不要止损。

我建议在生产环境里至少保留两类审计数据：一是智能体每一步的关键输入与输出快照，二是工具调用的完整日志。快照可以看到智能体当时的上下文里有什么，工具调用日志能看到它实际执行了什么操作、改了什么数据。这不仅是排障的依据，还是持续优化 prompt 和 workflow 的基本素材。特别是多智能体协作场景，某个结果不对时你根本不知道是哪个环节出了问题，没有日志就只能靠猜。

更严格一点的场景，比如智能体有写操作权限的，还需要加一层审批或双人复核机制。我见过一个项目，智能体自动给客户发优惠券，结果 prompt 解析出了偏差，把“满 100 减 20”理解成了“每个订单直接减 20”，等发现时已经发出去几百张。这种事很难完全避免，但配合审计日志和阈值告警，至少能在损失扩大之前叫停。

4.4 平台智能体与代码构建智能体的区别

平台搭建的智能体和用 Python 构建的智能体有什么区别？这是很多开始接触智能体的人都会问的问题。简单说，平台智能体是把“模型编排、工具调用、知识库管理”这些能力封装成可视化配置，上手快、迭代快，适合业务节奏快、逻辑相对标准的场景。用 Python 构建的智能体则是把控制权完全握在自己手里，复杂逻辑、权限控制、数据处理、私有化部署都更灵活，代价是需要一支能持续维护的工程团队。

具体到实际选择，可以从三个维度判断：团队构成、业务复杂度、运维能力。如果是业务团队想做智能化升级，没有专职 AI 工程师，那平台就是最合理的选择，别硬去写代码。如果已经有工程团队，业务里涉及复杂的权限体系、私有部署要求、或需要与现有系统深度集成，那就该走代码路线。硬用平台去套复杂业务，或者硬用代码去实现简单的问答机器人，都是在给自己找麻烦。

我个人的观点是，这两条路线不是对立的，而是一个连续谱系。成熟的智能体项目通常会结合两者：用平台快速跑通原型、验证业务流程，用代码处理核心调度、数据链路和审计体系。搭建智能体的核心不是选哪条路，而是搞清楚哪些能力要靠平台快速解决，哪些控制权必须握在自己手里。这个边界在项目启动阶段就要明确，不然后面重构的成本会非常可观。

5. 做智能体项目踩过最深的坑

说一个我自己的教训。早期做一个销售线索初筛智能体时，我把所有精力都放在 prompt 和模型选型上，反复调提示词、换模型，测试集上的准确率从 78% 磨到 88%，觉得差不多了。结果一上真实数据就翻车：模型对客户回复里的“再考虑考虑”这类表达，识别成“有意向”的比例非常高，销售团队跟着假线索跑了一周，差点把项目否定掉。

后来复盘发现，问题根本不在模型，而在于我把一个信号判断问题完全交给了模型。正常的做法应该是用规则穷举“明确拒绝表达”和“明确意向表达”这两类高置信信号，模型只负责处理模糊地带。就这么一个改动，准确率直接拉高到 94%，还是同一个模型、同一个 prompt。这件事之后我给自己定了一条规矩：能用规则先说清楚的部分，永远不要让模型自由发挥；模型只做规则覆盖不了的事。

这也是我做智能体项目最核心的体会——智能体不是模型能力的堆砌，而是规则、流程、数据、模型四件事的协同。单点上的最优配置，不如系统上合理的分工配置。尤其是这一周看到 Gemini 3.1 Pro 定价对标、智能体冲击 SaaS、本地推理能效拐点这三个消息，我反而觉得方向更清晰了：模型会越来越强、越来越便宜，但把模型变成一个可靠的结果，靠的还是工程化能力。规则兜底、审计留存、能力边界清晰，永远是智能体项目里最值钱的部分。