企业官网建设流程全解析

先说结论

这个圈子的技术路线分歧，到 2026 年第三季度基本结束了。

OpenAI 在 9 月 29 日的 DevDay 上发了 Dots，每个 dot 配一台云电脑，能进 ChatGPT 桌面、网页、移动，还能进 Slack 和 Teams。同一天，Manus 发了 2.0 和多 Agent 群聊应用 Cue，五天后以「做私人 AI 助理」的定位拿了超 5 亿美元融资。再往后两周，10 月 13 日，阿里千问官宣了内嵌在千问 App 里的 Personal Agent「千问Go!」。

三件事挤在两三周里发生。这不是谁抄谁，是模型能力、协议标准、推理成本三条曲线同时越线了。

而它们选的技术路线，如果你把宣传语剥开看执行层，会发现高度一致：协议优先，界面兜底，关键动作回人工。

下面把这四条路线拆开讲，重点是每条路线的工程契约差别在哪。

图 1 Personal Agent 定位矩阵：执行路线 × 履约闭环

一、判据不是「能不能」，是「有没有契约」

很多讨论停在「这个产品能不能订餐厅」这一层。我觉得这是错的问法。能，几乎所有路线都能。真正的问题是：

• 它做这件事的时候，有没有一个幂等键？重复执行会不会重复下单？
• 它失败的时候，你能不能知道它失败了？还是要靠再截一张图来猜？
• 它成功的时候，服务端有没有留下证据？还是只有一张截图？

这三个问题背后是同一件事：契约。有没有一份可静态校验、可单测、可回归的接口约定。

四条路线的差别，本质是契约强度的差别。

二、L1 读屏加模拟点击：把别人的界面当 API 用

技术栈大概是这样的：截屏，视觉模型定位目标控件，输出坐标，注入点击或输入事件。跑在端侧，或者跑在云手机的虚拟环境里。

它的优点非常大，大到很多人低估：不需要任何一家服务商配合。理论上只要有界面，它就能操作。这也是为什么手机厂商和做手机助手的团队特别喜欢这条路线——它的供给是无限的。

但它的工程缺陷同样致命，而且是结构性的，不是靠模型变强能补的：

第一，没有稳定的元素标识。视觉模型给的是坐标，坐标随分辨率、字号、深色模式、A/B 实验、改版而变化。你没法对「屏幕中间那个蓝色的按钮」写单元测试。传统 UI 自动化好歹还有 accessibility id 和 xpath 可以退化，纯视觉路线把这些都放弃了。

第二，无幂等键，重复执行就是重复下单。界面上没有 request_id 这个东西。网络超时了，你不知道刚才那一下点没点进去。这是所有 L1 路线在写操作上翻车的根因。

第三，结果判定靠「再截一张图」。页面写「提交成功」就算成功？那如果页面写的是「已受理，审核中」呢？如果页面根本没变呢？没有服务端返回码，归因就只能是猜测。

第四，也是最要命的一条：你是在绕过平台意志使用它的能力。

这一点在中国有非常明确的实证。2025 年 12 月，豆包手机助手（和努比亚合作的机型，3499 元、限量 3 万台）因为读取微信和银行 App 触发风控，随后下线了「操作微信」的能力。

这个事件我认为应该被写进行业教科书。它说明的不是「模型不够强」，而是：在国民级应用面前，读屏路线的可达边界不由你的技术决定，由对方的风控策略决定。你永远不知道哪一天能力就没了。

安全注脚：把 L1 用在只读采集（查信息、比价、抓页面状态）风险可控；一旦让它承载写操作，等于把一个没有幂等语义、没有服务端日志、权限边界由对方随时可收回的通道，接到了资金和合同上。这在任何安全评审里都过不了。

图 2 Personal Agent 执行路线的四段演进与行业收敛

三、L2 浏览器内 Agent：稳定一档，但天花板是「服务不在网页上」

第二条路线接管的是浏览器。技术栈换成了 DOM、无障碍树、CDP 协议，能拿到结构化的页面信息，能读到网络响应。

代表产品一堆：OpenAI 的 Operator 系（后来并进了 ChatGPT Agent 和 Dots）、Anthropic 的 Claude for Chrome、Perplexity 的 Comet、Manus 的云端沙箱。

它比 L1 好在哪：有结构可解析，有选择器可退化，有网络日志可采，DOM diff 能给出相对可靠的结果判定。可观测性上好一个量级。

它的问题也很具体：

• 选择器和可访问性节点依然是脆弱契约。页面改版就是破坏性变更，而且对方不需要通知你。
• 跨标签页状态要自己维护。一个任务开六个标签页，上下文窗口里塞不进去，就得自己做状态外置。
• 触达不到原生 App。这一条在中国特别致命。

最后一点值得展开。L2 路线隐含一个假设：服务交互发生在网页上。在美国，这个假设大致成立——退款、改签、比价、预约，很多都能在 Web 流程里自助闭环。但在中国，大量服务触点活在电话客服、人工审核、App 内工单、线下预约里。你的浏览器 Agent 再强，它打不进那通电话。

这也是为什么我觉得千问Go! 的官方叙事里出现「电话联系服务方」「客服电话不通转图文客服」不是偶然，那是被场景逼出来的设计。

四、L3 平台协议授权：能力是被注册进来的

第三条路线，商家主动把能力开放出来，Agent 调接口。技术上就是工具清单加 Schema 声明，参数可静态校验，返回值有错误码语义，调用带 request_id。

这条路线的工程优势是压倒性的：幂等、可归因、可审计、可回归测试。它终于让 Agent 系统能被当成一个正经的分布式系统来运维。

2026 年这条路线上的动作非常密集：

• 阿里侧，千问开放平台 8 月 10 日上线，面向手机、PC、AI 眼镜三类终端开放接入，合作方以「标准化协议」接入自有智能体，首批名单里有顺丰、自如、盈米基金、哈啰、闪送、飞常准、美的美居，以及阿里系的菜鸟和夸克。开发者侧的千问 AI 平台文档明确支持 MCP，Responses API 接 MCP Server，单次上限 10 个。
• Google 侧，A2A 做智能体互联与发现，AP2 做支付授权框架，UCP 联合商家做商业协议，印度已经有 Gemini 内嵌 Flipkart 购买按钮的落地。
• OpenAI 侧，DevDay 上发了 MCP events 用于插件自动化（规范本身还处于 proposed 状态），以及跨 16 家合作伙伴的用量互通。

这里有一个我认为被低估的信号：MCP 正在变成跨厂商事实标准。它由 Anthropic 提出，但 OpenAI 和 Google 都在接。对做企业 Agent 的同行来说，这意味着工具层的投资复用性比一年前好得多——你写的 MCP Server 不只服务一家模型。

但 L3 的天花板同样明确：它完全取决于商务谈判能签下多少家。协议是硬的，生态是排他的。顺丰接了千问，不代表它会接豆包。

安全注脚：L3 不是天然安全的。工具清单变长之后，工具投毒、参数注入、越权调用都会跟着来。开放协议接入必须配一套工具准入评审，不能商家说注册什么就注册什么。这块我在系列第 3 篇展开。

五、L4 混合架构：路由权必须在编排层

现在能理解为什么大家收敛到同一个形态了。

豆包手机助手二代（2026 年 9 月 16 日发布，NaviX Ultra）的官方表述我认为值得逐字读：MCP 与 A2A 协议优先，GUI 兜底，人工确认，另外配了一套 SAEP 公示机制。

千问Go! 的「操作已授权平台 + 必要时电话或图文客服交涉」，结构上是同构的。

OpenAI Dots 的机制也一致：后台研究限只读，高影响动作走 Auto-review，敏感动作交还人。

三家在不同大洲、不同生态、不同模型底座上，独立收敛到了同一个架构。这种收敛比任何单一产品的功能列表都值得注意。

把它映射到分层架构上大概是这样：

关键点只有一个：路由决策权必须集中在编排层，不能下沉到模型单次推理里。

如果让模型自己在每一步决定「这步我用 API 还是用点击」，你会得到不可复现的行为路径，也就无法做回归测试。正确做法是编排层持有一张能力路由表：这个动作、这个平台、这个风险等级，走哪条通道，降级顺序是什么，什么时候必须停下来问人。这张表要能版本化、能测试、能在故障时回滚。

图 3 三条执行通道的技术栈对比

六、给做架构的同行三条判据

如果你正在评估或者自建一套 Personal Agent 能力，我的建议是别比功能列表，比这三条：

判据一：该动作有没有幂等键。没有的通道，不得执行支付、下单、提交申请这类写操作。这不是性能问题，是资金安全问题。

判据二：失败能不能归因。只能靠「再截一张图」判断结果的通道，不配承载高影响动作。判据很朴素：出问题时你能不能在十分钟内说清楚是哪一步、哪个通道、对方返回了什么。

判据三：有没有留下服务端证据链。无日志即无审计，无审计即无法通过合规评审。这条在中国尤其硬——智能体支付相关的行业公约已经在提「关键交易节点可信存证」，强制性国标也已立项。

三条判据都指向同一件事：L1 应该被限制在只读采集，写操作一律回人工确认。把 L1 当「万能适配层」是架构性错误，它会在你意想不到的地方，以你无法解释的方式失败。

七、下一篇预告

这一篇讲的是「怎么动手」。但我在整理材料时最好奇的问题其实是另一个：为什么千问Go! 首批官宣的案例，选的是航班延误理赔和购物价保退差价——都是「把钱要回来」，而不是「把钱花出去」。

这个问题我想了挺久，答案指向一个工程事实：逆向交易对手方有明确的拒付动机，所以它不是自动化问题，是博弈问题。而博弈问题没有标准接口可调用。

系列第 2 篇拆这个：逆向履约场景的状态机、多通道降级链，以及为什么 Agent 的最后一公里是一通电话。

讨论

你们团队现在有没有在跑界面级的 Agent 自动化？如果有，写操作是怎么处理幂等的——是靠业务侧唯一键、还是靠「先查后写」的乐观策略？我目前看到的实践里，后者在改版时特别容易出事。评论区聊聊你们的踩坑方式。

参考来源

以下为本篇引用的公开信息，检索与核验截止 2026 年 10 月 13 日。

1. 千问推出 Personal Agent「千问Go!」：可申请理赔、购物保价．上海证券报·中国证券网，2026-10-13．http://www.cnstock.com/commonDetail/801354

2. 阿里千问升级个人 AI 助理，Personal Agent「千问 Go!」即将发布．IT之家，2026-10-13．https://www.ithome.com/1/012/244.htm

3. 阿里推出个人 AI 助理「千问Go!」：可跨平台代办航班理赔、价保比价等个人事务．AIHub，2026-10-13．https://www.aihub.cn/news/qianwen-go-launch/

4. 实测千问开放平台（三类终端接入与首批合作方名单）．新京报，2026-08-10．https://www.bjnews.com.cn/detail/1786344285129403.html

5. MCP 接入说明（Responses API 与 MCP Server）．千问 AI 平台官方文档，2026-10 核对．https://platform.qianwenai.com/docs/developer-guides/tool-calling/mcp

6. OpenAI DevDay 2026 发布梳理（Dots、Agents API with computer use、MCP events、Pro 档位）．Agent Skills 汇编，2026-09-29．https://agentskills.codes/blog/openai-devday-2026-recap-agent-builders

7. 努比亚豆包手机助手二代 NaviX Ultra 路线说明（协议优先、GUI 兜底、人工确认）．艾媒咨询，2026-10-06．https://www.iimedia.cn/c1104/117830.html

8. 豆包接入抖音电商，端内完成咨询到支付．腾讯新闻，2026-03-17．https://news.qq.com/rain/a/20260317A076Q100

9. QuestMobile 2026 年 6 月 AI 原生 App 月活榜（千问 1.67 亿、豆包 3.82 亿）．IT之家转述，2026-07-14．https://www.ithome.com/0/976/383.htm

10. Manus 恢复独立运营、2.0 与 Cue、超 5 亿美元融资与 Cascade 框架数据．智东西／新浪财经，2026-10-08．https://finance.sina.com.cn/roll/2026-10-08/doc-iniunvxm3821244.shtml

11. x402 vs AP2 vs ACP：代理支付协议对比．DEV Community，2026-09-29．https://dev.to/quinn_854b15f517d8632ed4f/x402-vs-ap2-vs-acp-which-agent-payment-protocol-should-you-build-on-2026-fij

分层架构表、三条判据、路由权集中的建议为作者基于公开信息的工程判断，非任何厂商已披露实现。