AI Agent 不是下一个风口，而是对互联网产品逻辑的重写

先分清：Chatbot 是对话，Agent 是做事

客服机器人最常见的使用方式是：用户输入“订单怎么还没到”，机器人返回一段知识库文案。这个流程里，机器人只做了信息匹配。如果订单卡在物流仓库，它看不到订单状态，也无法改地址或催发货。用户只好转人工。

Agent 的使用方式是：用户说“我的订单还没到”，Agent 拆解成两个动作——调订单 API 查状态，再调物流接口看节点。如果发现仓库滞留，它先按规则补偿 10 元优惠券，再通知用户。完成这些动作后，它才生成回答。对话只是结果，动作才是产品。

维度	Chatbot	Agent
输入	一次性问题	一个目标
过程	检索/匹配	拆解、调用、验证
能力边界	在知识库内	在可调用的工具范围内
失败时	回答“我不能处理”	换一个工具或请求人工
产品形态	对话框+FAQ	任务编排+工具 API

Chatbot 和 Agent 的模型可能是同一个。差别在工程结构：Agent 多了一个“工具层”。它先把用户目标转成内部步骤，再调用外部系统执行，把返回值拿回来继续判断。这个循环通常叫 ReAct。下面是一个简化过程：

flowchart LR U[用户目标] --> A[Reason 拆解步骤] A --> B[Act 调用工具] B --> C{Observe 检查结果} C -- 缺信息 --> A C -- 完成 --> D[交付结果]

用公式表达：Agent = 大模型 + 工具调用 + 记忆 + 环境反馈。这意味着以前藏在页面背后的“操作路径”必须变成机器可读的 API 或结构化数据。没有这一步，产品就只剩一个聊天框。

生态：融资、开源、创业公司

过去两年，Agent 相关的融资和开源项目数量上涨很快。我不打算重复 PR 稿里的“亿元融资”，只看对开发者可验证的几件事。

开源框架：LangChain 早期用 Chain 概念封装调用，LangGraph 把流程改成图；Microsoft AutoGen 强调多 Agent 对话；CrewAI 把 Agent 组织成团队；OpenAI Swarm 先作为实验仓库公开，后来演变为 Agents SDK。这些项目都在解决同一个问题：让模型能稳定地调用外部工具。回答只是最后一步。
大模型厂商：OpenAI 在 2023 年给 API 加入 function calling，Anthropic、Google 随后跟进。做产品的人不需要自己训练模型，但需要决定“让模型能碰哪些系统”。
创业公司：Cognition 的 Devin 面向软件开发，Harvey 面向法律文件，Decagon 面向客服，Sierra 做数字化员工。它们共同特征是：把价值放在某个岗位的任务完成率上。

对创业者来说，现在有机会的生态位是把模型接进行业里的脏活：权限、审批、数据格式、异常回滚。谁把这些流程磨平，谁的企业订阅才有理由持续。

三个落地案例：客服、法律、售后

案例一：Klarna 客服

Klarna 在 2024 年 2 月发布过一组数据：AI 客服处理了用户服务中约三分之二的对话，平均处理时长从 11 分钟降到 2 分钟以内。数字来自官方新闻稿，口径和今天未必一致。值得拆的是它怎么接进业务系统。

Klarna 把订单查询、退货入口、支付记录这些服务从人工客服的内部工具中拆出来，做成 Agent 可调用的 API。模型负责理解用户意图、决定调用哪个接口；接口返回后，模型把结果翻译成用户能看懂的话。遇到低置信度或用户要求转人工，再把会话转移给人类客服。

如果只接一个 FAQ 知识库，它不可能把平均时长从 11 分钟降到 2 分钟。产品逻辑的价值就在这里。

案例二：Harvey 法律助手

法律场景比客服更严格，因为错误成本高。Harvey 的做法是把大模型嵌入律师已有工作流：合同审查时，Agent 先对合同做结构化拆解，标注风险条款、缺失条款和责任上限，再交给律师复核。律师自己仍然看原始文件，但很多初级检索耗时被去掉。

Harvey 的落地很慢，企业内部要先做权限隔离、文档权限映射和审计日志。这也解释了为什么 Agent 项目上线周期长：产品逻辑改了，IT 权限逻辑也必须跟着改。

案例三：Sierra 数字员工

Sierra 由 Bret Taylor 等人创办，定位是企业级智能客服。它给客户提供的是一个能处理售后问题的 Agent，企业管理员可以在后台配置策略、知识库和升级条件。与上一代聊天机器人不同的是，Sierra 把原来需要人点的按钮拆成了 API，再配上对话框作为前端。

售后 Agent 执行退货、改地址、查订单等操作时，会把每次操作记录下来，作为审计凭证。企业采购的标的从软件部署变为按任务交付结果的服务。

互联网产品逻辑被改了什么

交互方式：从点到托付

过去产品设计的目标是让用户少想：按钮要清楚，路径要短。Agent 时代的设计目标是让系统自己跑完路径。用户说“帮我订下周三去上海的高铁”，Agent 自己查车次、选座、支付。产品界面的重心会移到“目标输入框 + 授权管理 + 执行记录”。

流量入口：从搜索结果到任务输出

搜索引擎给网站送的是点击，Agent 给产品送的是调用。用户可能直接让 Agent 算出最低价并下单，不再打开十个页面比价。产品要进入这个流程，不能只靠网页 SEO，还需要把商品、库存、价格、配送信息做成结构化数据或 API。

流量入口的变化会直接冲击广告收入。广告位建立在“用户会看页面”的假设上，Agent 不产生浏览，直接产生结果。未来一段时间，可以观察一家公司的 API 调用量、广告点击量的比例变化。

商业模式：从曝光计费到任务计费

互联网广告收入模型是 CPM（按千次展示付费）和 CPC（按点击付费）。Agent 执行任务时，没有展示和点击，只有“完成”。所以新的计费单位大概率是“成功执行一次”或“节省一个人工时长”。比如客服 Agent 按解决次数付费，物流 Agent 按异常处理次数付费。

这也意味着，产品经理需要重新定义什么是“转化”：以前是注册率、下单率，以后可能是授权率、任务完成率。

未来 12 个月看什么

到 2026 年底或 2027 年初，观察这些指标：

授权能力：产品是否允许 Agent 代用户登录、操作、支付。没有授权，Agent 只能看不能做。
任务完成率：官方能否公开“X% 的任务在无人参与下跑完”。这比“对话通过率”更能证明 Agent 价值。
每任务成本：Agent 调用模型、API 和人工复核的总成本，是否低于人工完成同一任务的成本。
流量结构：搜索/信息流广告收入同比下降，还是 API/Agent 调用收入上升。
安全事件：因为 Agent 越权操作导致的负面案例，会影响监管和权限开放节奏。

不用等风口，也不用马上换掉现有产品。下周可以做一个实验：把产品里一个高频、低风险的动作（比如查余额、改预约时间）做成 API，让模型可以调用。找 10 个真实用户说出目标，记录有多少任务被 Agent 完整跑完、有多少在中途掉线。完成率超过 80%，再考虑扩展到支付级操作。如果完成率不到 50%，问题多半出在工具接口和权限设计。

出处说明：Klarna 案例的数据来自其 2024 年 2 月官方新闻稿；Harvey、Sierra 的信息来自公开产品介绍。各公司数据可能已更新，使用前请核对官方口径。本文不构成投资或采购建议。