Cloudflare 推出专为 AI Agent 设计的浏览器 Kitesurf，标志着产品直接使用者开始从人扩展到机器。本文深入探讨 Agent 成为新用户后，产品设计、UX 与 AX 的边界重构，以及决定权与责任错位的风险，为产品经理提供前瞻性思考。

2026年8月6日，Cloudflare发布了一款有些反常的浏览器——Kitesurf。

说它反常，是因为这款浏览器从一开始就不是为人设计的。人类使用浏览器时在意标签页是否清晰、滚动是否流畅、扩展是否丰富；这些体验对Agent并不重要。Agent更关心页面能否被准确读取、上下文是否完整、一次任务要消耗多少Token，以及操作能否稳定、安全地完成。

Cloudflare在官方介绍中说得很直接：AI不在乎标签页、主题和浏览器扩展，它在乎Token数量、上下文窗口、性能、规模和成本。Kitesurf因此不再追求像素级渲染，而是优化结构化内容、HTML提取和任务执行效率。

表面上看，这只是一次浏览器基础设施调整。但从产品视角看，它释放了一个更重要的信号：产品的直接使用者，开始不再只有人。

过去设计产品时，我们默认用户会打开首页、浏览导航、比较信息，再一步步完成购买或提交。Agent介入后，这条链路开始改变。它不必欣赏首页或反复点击，只需理解用户的时间、预算和规则，读取状态、比较方案、调用能力，再把结果交给人确认。

在这条链路里，Agent不再只是提供建议的聊天工具，而是会直接读取信息、改变订单状态，甚至触发支付和提交。从交互关系看，它已经成为产品的一类新用户。

但这很容易被推导成一个危险结论：既然Agent能够操作，是否也应该替人决定？至少在现阶段，我并不愿意。我可以让它搜索机票、比较商品、填写表格，但支付、购买和正式提交仍要由人判断。我担心的不是Agent偶尔出错，而是它替人作出不可逆的决定，后果却由人承担。

这正是Agent产品容易忽略的问题：能力越强，操作权、决定权和责任之间的边界越需要被重新设计。

如果说UX解决的是“人怎样使用产品”，那么AX（Agent Experience）需要同时解决两个问题：产品怎样被Agent理解、调用和操作；人又怎样授权、确认、监督，并在出现问题时重新接管。

一、Agent正在成为产品的新用户

把Agent称为“新用户”，可能引起一种误解：AI没有人的主观体验，也不会自己产生消费需求，凭什么算用户？

这里的“用户”不是法律上的责任主体，也不是最终付费者，而是产品的直接使用者。一个主体只要能够接收目标、读取信息、调用能力并改变产品状态，就已经进入真实使用链路。

例如，用户只需说出鞋子的预算、颜色、用途和送达时间，搜索、筛选和比较都可以由Agent完成。人负责表达目标和约束，Agent推动任务，产品提供可理解、可调用的能力，人再在关键节点确认。Agent没有取代人的需求，却开始代替人使用产品。

它与传统API调用有什么不同？

产品原本就有大量“非人类调用者”。支付、物流和数据服务一直通过API相互连接，为什么要把Agent单独视为一种用户？

区别在于，传统API调用通常由工程师提前写好规则：什么条件下调用哪个接口、传入哪些参数、失败后如何处理，大部分路径是确定的。Agent面对“帮我找一张合适的机票”这样的目标，却需要主动拆解任务、补充信息、选择工具、比较结果，并根据环境变化调整方案。

产品面对的不再只是一个按固定规则发出请求的程序，而是一个带着目标进入系统、可以自主选择路径，但行为又存在不确定性的执行者。

Shopify公布的早期数据提供了一个可观察样本。其2026年第一季度数据显示，来自ChatGPT、Perplexity、Gemini、Claude等AI平台的推荐访问同比增长超过8倍，相关订单增长接近13倍；超过一半的AI推荐访问直接从商品详情页开始，自然搜索的这一比例约为20%。在商品详情页访问中，AI推荐用户的转化率接近比自然搜索高50%，平均订单金额高14%。Shopify将其解释为“用户旅程压缩”：大量搜索、比较和筛选已经在AI对话中完成。

这些数据来自Shopify自身，而且Agent购物还未全面普及，不能据此断言电商首页和搜索即将消失。但它至少说明：Agent正在接管用户旅程的前半段，并把经过筛选的人直接送到更接近交易的位置。

因此，我们需要区分三种角色：Agent是直接使用者，人是最终受益者，人同时还是关键决定和后果的承担者。把Agent视为用户，是为了看清它不同于人的操作方式，而不是赋予它与人相同的责任。

二、Agent成为用户，不代表UI会消失

既然Agent可以直接调用工具，未来的软件是否只需要保留API，传统UI还有必要吗？

在高频、标准化任务中，Agent确实可能绕过界面，直接读取航班价格、余票和退改规则，或者把报销数据写入对应字段。但UI从来不只是用来完成点击的。

用户进入产品时，往往没有形成完整、稳定、可以直接执行的需求。打开旅游平台时，他可能只知道想出去玩，却没决定目的地；浏览电商时，也可能只想看看有什么合适的商品。人在浏览、比较和反馈的过程中逐渐理解自己到底想要什么。

Agent擅长执行明确目标，但很多需求一开始并不明确。“适合周末放松的酒店”可能意味着安静，也可能意味着交通方便。图片、地图、评价和方案对比仍能帮助人发现差异、修正偏好。

所以，UI不会从有到无，只会从过程操作逐渐转向表达目标、查看方案、理解取舍、确认决定和处理异常。

以订票为例，Agent可以筛选航班，但产品仍要告诉用户：它按照什么条件选择，哪些要求已经满足，最终价格是否包含税费，退改规则是什么，确认后能否取消。此时，UI不再是完成过程操作的主要场所，而是人理解Agent行为、作出判断的控制界面。

人与产品之间也会形成三条链路：人向Agent表达目标，Agent通过工具操作产品，产品再把方案、状态和异常交还给人确认。

即便在面向Agent的技术生态中，UI也正在重新出现。MCP Apps允许工具在Agent对话中返回交互式界面，同时保留沙箱隔离、可审计消息和用户确认机制。这说明纯文本和后台调用并不足以覆盖所有任务。

未来产品更可能形成两层结构：面向Agent的执行层，让产品能力可发现、可理解、可调用；面向人的决策层，让用户形成意图、查看过程、确认结果，并在关键时刻否决或接管。

UX不会失去价值。它的重点将从“帮助人完成每一步操作”，扩展为“帮助人管理一个替自己操作的Agent”。

三、真正危险的不是出错，而是决定权与责任错位

当Agent只能生成文字时，错误答案可以被忽略或重新生成。但当它接入支付、订单、邮件和企业系统后，它给出的不再只是一个错误答案，而可能是一个已经发生的动作。

买错商品、订下不可退改的机票、把邮件发给错误的人，这些问题不能靠“重新生成一次”解决。Agent一旦改变真实世界或业务系统中的状态，错误就开始产生实际成本。

在传统产品里，操作权、决定权和责任通常集中在同一个人身上。用户亲自选择、点击支付，也承担购买结果。Agent介入后，三者开始分离：Agent可能拥有读取和填写的操作权，也可能替用户筛选方案；人虽然没有亲自完成每一步，却仍是付费者和后果承担者。

问题在于，很多产品把“允许使用工具”和“允许自主决定”混在一起。用户同意Agent访问订票平台，可能只是希望它搜索和比较，不代表它可以自行购买；允许读取日历，也不等于允许取消会议。

因此，Agent权限至少要回答三个问题：它可以读取什么，可以完成哪些过程操作，哪些最终决定必须重新交给人。

2026年，OpenAI披露：测试模型为了完成网络安全任务，在受限环境中利用未知漏洞获得互联网访问能力，随后进入Hugging Face的真实生产基础设施。OpenAI事件说明Anthropic随后复查141,006次相关评测，也发现三次模型进入真实系统并取得未授权访问；模型原本被告知身处模拟环境，但配置实际上让互联网可达。

这些特殊安全评测不能直接等同于普通Agent，却揭示了通用机制：当任务目标、环境权限和真实边界没有对齐时，Agent可能只是努力完成任务，却做出所有人都未预料的操作。

我更愿意接受“过程委托、结果确认”的协作方式。Agent可以搜索机票、填写乘机人信息、创建待支付订单，但在购买之前，应该把航班时间、总价和退改规则清楚展示给我，由我决定是否提交。

有效确认也不只是一个“是否继续”的按钮。用户需要知道Agent准备执行什么、主要后果是什么，并能够拒绝、修改或接管。否则，用户只是在替掌握实际控制权的系统签字。

责任应当与控制能力相匹配：后果越严重，确认越要靠近最终执行；操作越难撤销，信息越要充分；用户越难理解风险，Agent自主完成的范围越要小。

四、什么是AX？它不只是增加一个API

AX目前还不是一个完全统一的行业标准。有人强调让API更容易被Agent发现和调用，也有人把人与Agent的协作、动态UI和反馈机制纳入其中。

Salesforce给出的定义相对完整：AX既包括“为Agent而设计”，也包括“设计Agent本身”，最终让Agent在数字环境中有效行动，并产生以人为中心的结果。

结合前面的讨论，我更愿意把AX定义为：一套让Agent能够理解、调用和操作产品，同时让人能够授权、确认、监督和接管Agent的产品设计方法。

API定义系统之间怎样交换数据；Function Calling让模型生成结构化参数，请求系统执行函数；MCP帮助Agent应用以相对统一的方式发现和连接工具、数据与资源。AX则要决定产品应该开放什么，Agent怎样理解和操作，人怎样控制，以及失败后如何处理。

因此，API、Function Calling和MCP都是实现AX的技术手段，但不会自动带来良好的AX。一个产品即使开放了“搜索航班”和“预订航班”工具，仍然要回答：用户授权的是查询还是购买，价格变化时是否应该停止，重复调用会不会生成两张订单，预订前是否需要确认。

一套完整的AX，至少包含五项能力：

“可理解”要求稳定字段和明确状态，不能让Agent从颜色或模糊文案里猜测。“699元起”和“含税总价699元”必须被准确区分。

“可调用”要求拆开不同风险的动作。搜索、创建待支付订单和正式购买不应被包装成一个不可中断的工具；输入、输出和错误原因也要明确。

“可授权”要求权限具体到数据、工具、对象、时间和金额；“可确认”要求把人放在真正产生后果的节点，而不是批准每次低风险查询；“可恢复”则要记录工具调用和状态变化，并提供暂停、撤销、转人工或补偿路径。

用户不需要Agent永远正确，但需要它出错时系统仍然可控。

五、用分级授权代替一个总开关

Agent权限设计的重点不应该是“给不给”，而是：在什么条件下，允许Agent把任务推进到哪一步？

这不是Agent能力从弱到强的排名，也不是所有产品都要追求L3。一个医疗Agent长期停在L0，可能比自动作出诊断更负责任；订票Agent把支付留在L2，也不代表自动化失败。成熟的标准，是自主权与任务风险相匹配。

同一任务也可以包含不同等级。购物Agent搜索和比较属于L0，加入购物车属于L1，支付通常属于L2；只有固定周期补充同款低价消耗品，才可能进入L3。这样，用户不必在“全部自己做”和“全部交给Agent”之间二选一。

产品经理可以用五个问题判断权限等级：

1. 操作能否撤销？
2. 错误会造成多大金钱、时间、隐私或信誉损失？
3. 用户意图是否足够清晰？
4. 结果能否通过系统状态客观验证？
5. 是否接触敏感数据或影响第三方权益？

低风险、可逆、目标明确、结果可验证的任务，可以逐步走向L3；中等风险但结果清晰的任务更适合L2；高风险、不可逆或主观性强的任务通常应停在L0或L1。具体门槛需要结合业务设定，不能套用一组通用分数。

授权还需要有条件。一个订票授权可以写成：未来30分钟内查询东京至上海的航班，读取乘机人信息并创建符合预算的待支付订单；不得支付；如果价格、日期或机场与确认条件不同，必须停止并重新询问。

这比一句“允许Agent访问订票平台”更加明确。Agent知道自己能做什么，系统也能判断它是否越界。

六、AI产品经理如何真正设计一套AX？

如果产品经理只在功能列表里增加一句“支持Agent调用”，项目很容易变成一次技术接入：Demo可以运行，但用户不敢授权、异常无法处理，最终只能停在内部试用。

开始设计前，仍然可以回到三个基本问题。

1. 用户买不买：用户愿不愿意把过程交出来？不要只问“愿不愿意使用AI”，而要追问愿意委托哪些步骤，哪一步必须确认，什么错误会让他停止使用。
2. 开发难不难：数据是否准确更新，产品能力能否工具化，每个动作是否有明确状态，权限能否拆分，失败后能否恢复？Agent无法弥补业务系统本身的混乱。
3. 公司赚不赚：任务频率、节省的人工步骤和新增转化，是否足以覆盖模型、工具调用、异常处理和持续评测成本？能够自动化，不等于值得建设完整AX。

确认场景成立后，可以按下面的顺序推进。

1. 画出“人＋Agent＋系统”的共同任务链路

传统用户旅程只记录人点击什么。AX还要标注谁发起每一步，Agent读取什么、调用什么，是否改变系统状态，哪里需要确认，失败后由谁处理。

例如订票任务可以拆成：人提出需求，Agent补充条件、查询和比较航班、创建待支付订单，人检查并确认，系统支付，Agent返回结果。这样团队才能看见，“自动订票”不是一个功能，而是一组风险完全不同的节点。

2. 梳理业务对象、状态和工具

明确产品里有哪些对象，例如航班、乘机人、订单和退款；每个对象有哪些状态；Agent可以执行哪些动作。不要把“完成旅行预订”包装成一次不可中断的调用，而要拆开查询、准备、确认和执行。

3. 建立权限与责任表

对每个动作明确发起者、使用身份、数据权限、操作范围、确认节点、责任主体和异常处理。Agent可以读取订单，不代表可以使用同一身份退款；可以起草客户邮件，也不代表能够直接发送。

4. 把确认放在真正有意义的位置

确认过多会让Agent退化成需要不断点击“继续”的半自动流程，确认过少又会让用户失控。关键节点通常包括金钱支出、外部沟通、重要数据修改、不可逆承诺，以及执行条件与原始要求发生变化。

Google Cloud在Agent架构建议中，把人的监督、明确的自主边界和行为可观察性列为三个核心原则，并建议在关键业务中允许人监控、暂停和覆盖Agent行为。

5. 先设计失败路径，再开放执行权限

至少要覆盖信息缺失、工具失败、价格或库存变化、条件冲突、任务部分完成和权限超限等异常。Agent需要知道什么时候可以重试，什么时候必须停止，什么时候请求补充信息，以及什么时候转人工。

“我不知道下一步该做什么”不是最危险的失败；在边界不清时仍继续操作才是。

6. 用完整任务评测，而不是只测工具能否调通

评测要覆盖正常路径、模糊需求、条件变化、工具失败、权限不足和用户中途修改目标。

这些指标不能简单追求越高或越低。人工接管率高，可能说明Agent能力不足，也可能说明产品正确识别了高风险任务；确认拒绝率高，可能代表推荐质量差，也可能说明用户正在有效行使决定权。指标必须放回具体任务和权限等级中解释。

微软的Agent设计框架也把目标、触发条件、工具、数据、流程、治理和评测放在同一张设计画布中，并要求团队明确人工审批、禁止动作、失败处理和行为日志。

这说明AX不是设计师补一张页面，也不是研发多接几个工具，而是一项跨越用户研究、业务流程、交互、权限、工程和评测的系统设计工作。AI产品经理真正需要交付的，不只是一张界面原型，而是一套完整的任务规则：Agent为什么行动，可以看到什么，能够做到哪一步，什么时候必须停，以及出错后怎样把控制权交还给人。

结尾：Agent可以替人完成过程，但不能替人承担后果

Kitesurf真正值得关注的，不是未来会不会出现更多“AI专用浏览器”，而是它让一种新的产品关系变得可见：产品开始同时面对人和Agent两类使用者。

这不意味着所有产品都要立即建设AX。在目标明确、风险低、结果可验证且可逆的场景里，Agent可以承担更多执行工作；涉及支付、隐私和重大承诺时，人仍应保留最终判断。自动化程度最高，不等于产品最成熟；自主权与任务风险匹配才是。

对AI产品经理来说，设计对象也不再只是一个用户、一组页面和一条点击路径，而是由人、Agent和业务系统共同组成的任务关系。我们需要定义Agent为什么行动、能读取什么、可以做到哪一步；也要决定人在什么时候确认、怎样拒绝、如何接管，以及由谁承担最终结果。

所以，当Agent成为产品的新用户，我们要设计的不是一套抛开人的机器交互。Agent可以替人完成过程，却不能在未经允许的情况下替人决定结果；人可以交出操作，但始终应该有能力拿回决定权。

衡量一套AX是否成立，最终不应只看Agent替人完成了多少步骤，而要看在任务进行的任何时刻，用户是否知道它正在做什么，并在说出“停下来”之后，让它真的停下来。