重庆老系统里的填单日常

重庆很多制造和商贸企业，前台跑着一套用了十多年的 ERP、进销存或报关辅助系统。界面是表格，操作靠鼠标和键盘，没有开放 API，供应商也不再做二次开发。销售要录订单，库管要录出入库，报关员要录品名、规格、数量、币制，物流要录提货信息。一天几百上千次录入，错一个字就要退回重来。浏览器智能体被寄予的期望很直接：能不能替人把这些单填了。本文把 WebMCP 的能力边界、老系统的现实约束和重庆本地的落地顺序拆开讲。

WebMCP 想解决的正是“猜界面”

传统浏览器自动化靠识别 DOM、找按钮、填输入框，页面一改版就断。WebMCP 换了一个思路：网站主动把功能注册成工具，智能体调用工具，而不是猜页面。按 Cloudflare 与 Chrome 侧公开的介绍，站点可以用 document.modelContext 这类接口注册工具、定义参数结构，也可以在标准 HTML 表单上加声明式注解，让表单直接变成可调用工具。工具在访问者浏览器内、同源执行，调用结果按结构化格式返回。

对老系统来说，这个差别很实际。RPA 是“看见什么点什么”，WebMCP 是“知道这个系统能做什么”。前者依赖界面稳定，后者依赖站点愿意开放。问题也在这里：重庆的老系统大多没有能力也没有动力去改代码，主动注册工具这一步，谁来补？

Cloudflare 把开关做出来了

2026 年 9 月 28 日，Cloudflare 在 Kitesurf 更新里宣布支持 WebMCP，并提到站点所有者可以用一个开关打开 WebMCP，公共演练场里可以在 Cloudflare Radar 的 Application 面板查看效果。2026 年 10 月 21 日，Cloudflare 又发文介绍 Commerce.com 如何把店面准备好迎接智能体购物，文中说会继续投入 WebMCP，先从帮助智能体更容易发现站点工具做起。两条信息连起来看，Cloudflare 的路线是：边缘侧注入桥接，站点少改代码，智能体按工具调用。

这是厂商一手材料，也要按厂商口径读。开关打开不等于业务自动化完成，认证、授权、业务约束、人工确认仍然由站点自己负责。对重庆企业来说，Cloudflare 的方案适合已经托管在边缘、愿意开放工具的站点；内网老系统不在这个覆盖范围里。

生态还在早期，别把演示当产能

据 PromptArmor 在 2026 年 10 月 6 日的分析，webmcp.com 注册表当时收录了 2,959 个使用 WebMCP 工具的站点；Chrome 和 Edge 处于源试用阶段，Shopify 把工具自动加到部分店面，ChatGPT 的内置浏览器以“站点工具”的方式支持。这些是二手汇总，数字会变，但能看出一个事实：支持面在扩大，离“随便一个老系统都能接”还很远。

重庆企业容易被演示打动：屏幕上智能体自动打开页面、填好表单、点提交，看起来很顺。演示环境通常网络干净、账号权限全开、页面没验证码、数据是准备好的。真实环境里，登录态会过期，字段会联动，必填项会变，审批流会卡住。评估时要按真实环境跑，不要按演示环境签合同。

老系统难在哪

一是技术栈。不少系统只支持旧版浏览器或 ActiveX 控件，现代浏览器智能体根本进不去。二是网络。系统在内网，智能体在云端，中间没有通道；要在内网部署桥接，又涉及服务器、证书、运维。三是登录与权限。老系统常用共享账号，操作日志只记到账号，不记到人；智能体一接入，责任更难分清。四是业务校验。数量、单价、税率、币制之间有联动，填错一个字段，后面全错。

这四道坎决定了 WebMCP 在重庆的落地顺序：先做查询和预填，再做草稿，再往后才谈提交。查询类操作即使出错，代价是“查得不对”；提交类操作出错，可能是错单、错款、错报关。顺序颠倒，项目很容易在首次错单后停摆。

登录态是另一个现实问题。老系统常用短信验证码、动态口令、单点登录，智能体没有办法独立完成。可行做法是把登录交给人工，登录后的会话交给智能体，同时限制会话时长和可访问页面。这样既保留认证，又不让智能体持有长期凭证。

搬到重庆要改什么

改造方式：能改代码的系统，加一层内部桥接，把常用表单注册成工具；改不动的系统，保留 RPA 或人工，不要为了统一技术路线硬上。混合架构在工厂里是常态，不丢人。

部署位置：内网系统配内网智能体，数据不出厂区；确需外部模型时，只把脱敏后的字段发出去，原文留在本地。等保 2.0 的边界防护、安全审计、入侵防范要求，要覆盖到桥接服务。

语种与字段：重庆企业的物料描述、客户简称、地区叫法有本地习惯，表单字段还常有缩写。工具的参数定义要和主数据对齐，否则智能体填得进去、业务对不上。

监管与责任：涉及个人信息、报关、发票、合同的表单，要明确自动化处理的范围和人工复核环节。生成式人工智能服务面向公众的备案要求、数据分类分级要求，按实际场景对照，不要一刀切。

成本：桥接开发、内网部署、日志存储、人工复核，四项加起来往往比想象中高。先算一个表单的账：人工每天填多少次、每次多少秒、错一次返工多少分钟，再对比改造投入。

一个具体的试点流程

以库存查询为例，试点可以按五步走。先选一个内网系统和一个只读账号，确认查询结果不包含成本价、客户信息等敏感字段。再在系统前加一层内部桥接，把“按物料编码查库存”“按仓库查可用量”注册成两个工具，参数只允许物料编码、仓库、批次。接着让智能体在测试环境跑两周，记录查询成功率、字段错误、响应时间。然后接一个业务员试用，保留人工复核，比较两边结果。复盘后再决定是否扩到第二个仓库。

这套流程的价值在于把“能不能做”拆成“哪个字段能做、哪个仓库能做、哪类用户能用”。WebMCP 的能力是通用的，企业的数据边界是具体的，试点要把具体的边界跑出来。

桥接由谁维护

桥接服务不是一次性交付。系统升级、字段增减、权限调整，都会让工具失效。企业要明确维护责任：是 IT 自己维护，还是集成商按年维护，费用怎么算。很多项目在验收后三个月开始出问题，就是因为没有人负责桥接的日常维护。签合同时把维护范围、响应时间、升级责任写清楚，比演示效果重要。

能替与不能替

查询、检索、字段预填、草稿生成，这些可以交给浏览器智能体，人工做复核。提交订单、确认价格、发起付款、报关申报、签署合同，这些必须有人确认。AI 不签字、不承诺、不替代判断。把这条写进流程，比在提示词里写十遍“谨慎操作”有用。

还有一个容易被忽略的边界：智能体替人填单，填的是“人已经决定要填的内容”，不是替人做决定。价格怎么定、供应商选谁、这批货走哪条线，仍然是业务判断。工具能加速执行，不能替代决策。

另外，不要让智能体替人“理解需求”。车间说要“一批急件”，这句话背后可能是交期、可能是质量、可能是客户关系。智能体可以把历史订单、库存、产能摆出来，但不能替业务判断哪一批先做。工具能缩短信息收集的时间，不能替代业务上的取舍。

可执行的起步动作

挑一个高频、低风险、字段固定的查询表单，比如库存查询、客户资料查询、物流轨迹查询，做两周试点。记录三组数字：人工平均耗时、智能体平均耗时、人工复核发现错误的比例。三组数字放在一起，才能判断值不值得继续。试点期间保留原流程，不要一上来就切换，避免业务中断。

试点结束后做一次复盘，重点看两件事：哪些字段智能体总是填错，说明参数定义或主数据有问题；哪些环节人工复核花的时间比原来还多，说明这个场景不适合自动化。复盘结论写下来，再决定下一个场景，不要凭感觉扩张。

资料来源与口径说明

  • Cloudflare 博客《How Commerce.com and Cloudflare are getting storefronts ready for agentic commerce》，2026 年 10 月 21 日，厂商一手材料。
  • Cloudflare 博客《The road to the agentic browser: A Kitesurf update》，2026 年 9 月 28 日，厂商一手材料。
  • webmcp.com 注册表 2,959 个站点、Chrome 与 Edge 源试用等生态数据，来自 2026 年 10 月 6 日的第三方分析汇总，属二手材料。

说明：厂商文章中的能力描述属于厂商自述，实际可用性取决于浏览器版本、站点改造程度和企业网络环境。本文不虚构重庆企业案例，试点数据需由企业自行采集。