ARTICLE · 1009175
(理论版)网站、APP、小程序与 Agent:企业数字资产体系的生产关系、战略价值与利润最大化协同框架
(后天还有一个PPT版本,更易理解)
执行摘要
研究截点:2026 年 8 月 29 日。企业规模、具体行业、现有 IT 成熟度、预算与跨境经营范围:未指定。 因此,本报告以“中国大陆为主要经营法域、企业已有 ERP/CRM 或核心业务系统、可能存在跨境业务、不以一次性替换全部核心系统为前提”作为通用咨询假设;涉及金融等强监管行业时,再提高控制等级。
本报告最重要的结论不是“网站、APP、小程序、Agent 谁会取代谁”,而是:
四者并不是四代相互替代的软件,而是企业数字生产体系中四种不同的产权结构、交互机制和价值捕获方式。
网站掌握开放互联网身份与公开可发现性;APP 掌握终端驻留与高频用户关系;小程序掌握超级平台内的低摩擦触达与交易;Agent 掌握的是一种此前软件很少拥有的东西——从用户意图到跨系统执行的调度权。
2026 年的宏观背景已经足以说明为什么这不再只是“IT 部门的问题”。WIPO 最新数据表明,29 个经济体的无形资产投资在 2025 年首次突破 10 万亿美元;自 2008 年以来,无形投资增长速度超过有形投资三倍。软件与数据库是 2013—2023 年增长最快的无形资产类别,实际年增长率约 7.3%,而组织资本、品牌同样快速增长。WIPO 的分析特别强调,AI 的长期经济影响不仅来自芯片和数据中心,而来自企业围绕 AI 重构的数据、软件、组织流程与知识资本。[WIPO, World Intangible Investment Highlights 2026]
因此,企业数字资产的真正“资产核心”不是四个前端壳,而是其背后的:
域名与品牌 → 身份 → 客户关系 → 数据 → 产品主数据 → 业务规则 → API → 工作流 → 权限 → 交易系统 → 组织知识 → Agent Skills → 评估体系。
从战略上,我建议采用一句高度压缩的原则:
自有状态(Own the State),租用流量(Rent the Reach),标准化能力(Standardize the Action),治理智能(Govern the Intelligence)。
也就是说,企业可以租用苹果应用商店的分发能力、微信的社交与支付生态、OpenAI/Anthropic 等模型的智能能力,但客户身份、核心业务状态、订单/账本、主数据、业务规则、API、权限和组织知识不应永久锁死在任何一个外部平台里。
这一区分极其重要。平台生态可以明显提高价值创造能力,但战略管理研究同时发现:越依赖生态专有的互补技术,企业越容易受到平台架构变化、性能瓶颈和调整成本影响。对 2008—2015 年 24 万余款 iPhone App 的研究正说明了这种“生态价值创造—依赖风险”的权衡。[Agarwal & Kapoor, Organization Science, 2023]
所以企业最优架构不是:
网站系统APP系统小程序系统Agent系统
而应该逐步成为:
企业统一数字核心│┌───────────────┼────────────────┐│││身份/权限主数据/数据交易/流程│││ CRM / ERP / PIM / OMS / MES / Core / WMS│API / Event / MCP│┌──────────────┼──────────────┐│││网站APP小程序└──────────────┬──────────────┘│Agent│外部 AI / 内部 AI / 人
网站、APP、小程序是“呈现与交互界面”,Agent 是“理解、决策与编排层”,API 是“能力边界”,核心业务系统才是“事实与资产状态”。
这意味着 Agent 最不应该做的事情,是直接变成数据库、ERP 或核心账本。更合理的方式是:
Agent ≠ System of Record;Agent = Policy-Bounded System of Action。
即“受企业政策、权限、审批和审计约束的行动系统”。
OpenAI 当前的 Agents SDK、Function Calling、MCP 工具体系都已经体现了这种结构:模型可以决定调用哪个工具,但真实业务逻辑仍可由企业自己的应用执行,并可要求显式审批;Anthropic 的 MCP/Agent Skills 体系也同样把“模型、技能、工具、企业系统”分成不同层。[OpenAI Agents SDK] [OpenAI Function Calling] [Anthropic MCP]
利润最大化也因此不等于“全部 Agent 化”。正确目标是:

也就是:
新增毛利 + 人力/运营成本节约 + 库存/资本效率提升 − 云与模型等增量成本 − 治理成本 − 风险预期损失。
网站、APP、小程序和 Agent 只有在共同提高这个式子的结果时,才是资产;否则,它们可能只是不断烧钱的数字负债。
企业数字资产的生产关系与价值逻辑
首先必须区分两个经常被混为一谈的概念:
经济上的数字资产,和会计上的无形资产。
WIPO 对无形投资的经济统计范围非常广,包括软件和数据库、研发、品牌、设计以及组织资本等;而 IFRS 的会计确认门槛明显更窄。IAS 38 将无形资产定义为“可辨认、无实物形态的非货币性资产”,要求企业能够控制相关资源,而且许多企业内部形成的品牌、客户名单、商誉等即使具有巨大经济价值,也不能简单作为自行生成的无形资产确认。[WIPO] [IFRS IAS 38]
这意味着现代企业实际上需要同时维护两张“资产负债表”:
视角 | 回答的问题 |
法定会计资产负债表 | 哪些投入符合会计确认、计量、摊销和减值条件? |
战略经济资产负债表 | 哪些能力决定未来现金流、利润率、客户黏性与竞争壁垒? |
后者尤其重要。一个企业可能拥有十年积累的客户行为数据、成熟搜索排名、数百万 APP 用户、复杂供应链规则和训练成熟的 Agent 工作流,但其中大量价值并不会直接完整显示在会计资产负债表上。WIPO 甚至估算全球企业无形资产价值在 2025 年已接近 100 万亿美元;但这属于经济价值估算,不能直接等同于 IFRS 或中国企业会计准则下的账面资产。[WIPO corporate intangible assets 2026]
中国的制度也已经开始明确处理这一差异。财政部《企业数据资源相关会计处理暂行规定》自 2024 年起实施,其适用范围既包括符合企业会计准则条件、能够确认为无形资产或存货的数据资源,也涉及企业合法拥有或控制、预计能产生经济利益、但由于不满足资产确认条件而未确认的相关数据资源。换言之,“数据有价值”不等于“数据可以直接入表”。 [财政部相关说明]
从“生产关系”而不是“产品形态”的角度,可以把四者看成以下四种关系。
网站:企业与开放互联网之间的直接产权关系。 企业可以控制自己的域名、服务器、内容、URL、数据结构和商业规则。搜索引擎影响流量,但并不直接拥有企业的网站。Google 官方说明,结构化数据能够帮助搜索引擎理解网页中的企业、产品和其他实体;OpenAI 当前也允许网站通过 OAI-SearchBot 进入 ChatGPT Search 的候选范围,并能够追踪来自 ChatGPT 的推荐流量。[Google Structured Data] [OpenAI ChatGPT Search]
因此官网正在从:
Human-readable Website
演化成:
Human-readable + Machine-readable Corporate Presence
这会重新抬升网站在 Agent 时代的战略地位。
APP:企业与用户之间建立较深关系,但分发土地来自操作系统平台。 企业控制业务代码、客户体系和后台数据,却依赖 iOS/Android 等系统的设备能力、审核、应用商店和政策环境。APP 生态并没有被小程序或 AI 消灭:Apple 公布的 2025 年 App Store 生态所促成开发者销售与交易超过 1.4 万亿美元,且 2025 年 App Store 前 100 名 App 中超过 40 款已经包含面向消费者的 AI 能力。[Apple, 2026]
这反而说明未来更可能是:
APP × AI
而不是:
AI → APP 消亡
小程序:企业将部分数字生产关系嵌入超级平台。 微信提供巨大的身份、社交、支付、搜索、扫码和流量环境,从而大幅降低用户启动服务的摩擦;代价则是企业更加依赖平台规则和 API。腾讯截至 2026 年第一季度披露微信和 WeChat 合计月活已超过 14 亿,而微信小程序在 2024 年促成 GMV 达 8 万亿元人民币。[Tencent Weixin & WeChat]
因此小程序的正确战略定位不是“廉价 APP”,而是:
Platform-Embedded Transaction Node
超级平台内部的轻量交易与服务节点。
Agent:生产关系变化最大。
传统软件的基本生产关系是:
人↓理解软件↓寻找页面↓点击按钮↓填写参数↓软件执行
Agent 则可能变为:
人提出目标↓Agent 理解意图↓选择能力/API↓获取上下文↓制定步骤↓调用工具↓系统执行↓验证结果↓人确认 / Agent继续
OpenAI 当前 Function Calling 的正式流程就是模型产生工具调用,然后由应用侧执行真实代码并将结果返回模型;MCP 进一步允许模型连接外部数据、服务与工具。Anthropic 对 Agent 的描述和 MCP 实现也体现相同方向。[OpenAI Function Calling] [Anthropic MCP]
所以 Agent 真正攻击的并不是“APP 本身”。
它攻击的是:
为了完成一项工作,人必须学习并操作大量软件界面的成本。
这一点会改变整个软件价值链。
过去企业的软件价值主要体现在:
功能数量 × 用户数量。
未来会越来越体现为:
可被调用的业务能力 × 数据质量 × 权限可信度 × 工作流成熟度 × Agent 执行成功率。
这也是为什么 MCP 等协议值得战略关注。2026 年 7 月 28 日发布的 MCP 规范把它定义为连接 LLM 应用与数据源、工具的开放协议,并已包含正式的授权机制和安全要求;OpenAI 与 Anthropic 均已支持 MCP。[MCP Specification 2026-07-28]
但这不意味着未来所有企业都必须把 MCP 作为唯一接口。更稳妥的企业原则是:
内部业务能力以稳定 API/事件为核心;MCP 是面向 Agent 的适配层,而不是取代核心 API 的新单体架构。
由此,可以得到整个报告最重要的一张“生产资料所有权地图”:
企业必须尽可能自有│品牌 / 域名 / 客户ID / 主数据 / 权限 / 业务规则订单 / 账本 / API / 知识 / 评估│┌──────────┴──────────┐││租用分发租用智能││Apple / 微信 / 搜索OpenAI / Anthropic││APP/小程序Agent└──────────┬──────────┘│企业现金流
这可以浓缩为一句战略原则:
不要试图拥有所有流量和所有模型;要拥有决定未来现金流的“状态”和“规则”。
这与生产率研究中的“J 曲线”理论也吻合。Brynjolfsson、Rock 与 Syverson 的研究指出,AI 一类通用技术往往必须与大量企业特定的无形投资互补,包括流程、软件、数据和组织变革;因此初期投入可能先增加,而生产率收益在配套资产形成以后才释放。[American Economic Journal: Macroeconomics, 2021]
这也是为什么:
买一个大模型账号 ≠ 企业完成 AI 转型。
真正耗时和值钱的是企业内部那些没人愿意做、但最终决定 ROI 的工作:数据治理、接口化、权限体系、流程重构、主数据治理、知识结构化、评估和组织制度。
四类数字资产的战略比较与协同机制
下表按照你指定的十个核心维度进行比较。需要特别说明:其中“会计资产性”仅是通用判断,最终确认必须依据企业所采用会计准则、项目合同、控制权、开发阶段和审计判断。
维度 | 网站 | APP | 小程序 | Agent |
功能定位 | 企业公开身份、品牌、内容、SEO/AI 搜索入口、线索、开放交易前台 | 高频服务、深度客户关系、移动设备能力、认证交易 | 微信等超级平台中的低摩擦服务与交易节点 | 意图理解、知识检索、决策辅助、跨系统编排与执行 |
面向对象 | 人 + 机器。机器可读性最高 | 以人为主,也可向系统/API 开放 | 主要面向平台内的人 | 人 + 机器;未来也可能 Agent-to-Agent |
可发现性 | 开放互联网最高:URL、搜索、外链、搜索引擎、AI crawler | 应用商店、品牌搜索、广告;开放 Web 可发现性相对弱 | 微信搜索、扫码、聊天分享、线下场景等生态内强,生态外弱 | 取决于嵌入位置、工具描述、API/MCP、Agent 商店/平台推荐;潜力极高但生态仍快速变化 |
可执行性 | 中—高;接入账户、支付、API 后可直接交易 | 高;设备权限、登录、支付、推送、离线能力丰富 | 高;特别适合轻量交易、扫码和服务流程 | 潜在最高;可连续调用多个工具,但执行权限必须受到严格政策约束 |
数据/API 依赖 | 静态站低,交易型网站中高 | 高 | 高且同时依赖企业 API 与平台 API | 最高;没有数据、工具/API 的 Agent 往往只是聊天机器人 |
成本结构 | 建设成本相对低;持续成本主要为内容、SEO、CDN、安全、开发运维 | iOS/Android 开发、测试、版本适配、应用商店运营、SDK、安全、获客成本较高 | 前端开发通常轻于独立 APP,但有微信生态运营、接口适配和平台规则成本 | 模型/API/Token、知识库、集成、评估、可观测性、安全、人工审核;边际成本随调用量增加 |
法律/合规风险 | 隐私/Cookie、内容、网络安全、跨境数据、电子商务 | 在网站风险上增加设备权限、SDK、App Store/Android 商店隐私与审核规则 | 在一般数据合规上叠加平台规则、支付及用户数据接口要求 | 最高复杂度:隐私、错误决策、提示注入、越权执行、生成内容、模型风险、知识产权、AI 专项法规 |
可计入会计资产性 | 符合 IAS 38/SIC-32 条件的开发成本可能资本化;宣传性及部分运营支出通常费用化 | 自有软件若满足开发阶段与控制等条件,可形成无形资产;外部 SaaS/服务并非自动资本化 | 自主控制的软件代码可能符合条件;平台账号、流量和平台服务不能因具有价值就自动确认为资产 | 自有代码/特定可控成果视事实可能资本化;模型 API、SaaS 服务及大量配置费用通常更可能体现为期间成本,须逐项判断 |
长期价值与折旧 | 域名、品牌、内容知识可非常长期;网站技术层更新较快。SIC-32 特别提示网站最佳估计使用寿命通常较短 | 客户关系和后台资产可长期积累,客户端技术因 OS/API 变化持续迭代 | 用户关系和交易数据可积累,但前端价值受微信规则/API 变化影响更大 | 模型层可能快速贬值;数据、工具、权限、工作流、评估集和组织知识反而可能持续升值 |
竞争壁垒 | 域名、权威内容、品牌、自然搜索历史、公开知识图谱 | 安装基数、账户体系、行为数据、网络效应、设备能力、使用习惯 | 微信生态触达、线下二维码密度、会员关系、支付与运营闭环 | 专有数据 + 企业知识 + 业务权限 + 高质量工具/API + 工作流 + Evals + 信任和审计;基础模型本身通常不是最稳固壁垒 |
会计判断方面,IAS 38 要求可辨认性、控制和未来经济利益等条件;内部生成品牌与客户名单等不能简单确认。对网站,SIC-32 更明确规定,运营阶段支出一般在发生时费用化,除非满足 IAS 38 条件,而且被确认为无形资产的网站,其最佳估计使用寿命通常应较短。[IAS 38] [SIC-32]
云服务尤其需要警惕“花了很多钱,因此肯定是资产”的错误。IFRS Interpretations Committee 对 SaaS 配置/定制的分析指出:如果客户并不控制供应商的软件,而且配置活动没有形成独立、受客户控制的资产,往往不能确认无形资产;只有例如新增代码能够由客户控制等特定情况下,才进一步判断是否满足 IAS 38。[IFRS SaaS configuration/customisation]
四者真正的协同不是“同一个功能开发四遍”,而是建立任务路由规则:
用户任务 | 首选界面 | 战略原因 |
“这家公司是谁?产品是什么?” | 网站 | 开放发现、可引用、公共信息主权 |
“我每天都需要使用这项服务” | APP | 高频、驻留、通知、设备能力 |
“我偶尔需要交钱/预约/扫码办事” | 小程序 | 低安装摩擦、平台身份与场景触发 |
“事情复杂,我不想自己一步步操作” | Agent | 意图理解、知识检索、跨系统编排 |
“我不知道该买哪个产品” | 网站内容 + Agent | 公开发现 + 个性化决策 |
“我要真正付款/签署/确认高风险操作” | APP/Web/小程序受控确认层 | 强身份、明确 UI、法律凭证与用户确认 |
“我要让其他 AI 帮我调用企业服务” | API/MCP | 面向机器的能力接口 |
特别值得注意的是,2026 年这已经不只是理论。OpenAI 当前的产品发现体系允许用户在 ChatGPT 中发现和评估商品,而购买流程正在重新强调商户自有网站或 APP 完成结账;同时企业也可以提供结构化商品 feed,让 AI 理解实时价格、库存与产品属性。也就是说,Agent 正在成为新的发现与决策层,但商户自有数字资产仍然是交易与履约的重要基础。[OpenAI Product Discovery] [OpenAI Product Feeds]
这正好验证了你的原始判断:
Agent 并没有消灭网站,反而使“企业是否拥有机器可读的网站、商品数据和接口”变得更加重要。
我建议企业未来增加一种过去很少被正式管理的能力:
Machine Discoverability,机器可发现性。
它至少分成两类:
公开知识可发现性:
官网↓语义清晰的 HTML↓Schema.org / JSON-LD↓产品、组织、门店等结构化数据↓搜索引擎 / AI Search
Google 明确利用结构化数据理解网页中的实体;OpenAI 则明确说明开放 OAI-SearchBot 是网站具备 ChatGPT Search 收录资格的重要条件。[Google] [OpenAI]
业务能力可发现性:
企业 API / MCP↓清晰的工具名称↓输入输出 Schema↓权限说明↓能力描述↓Agent发现工具↓调用
OpenAI 当前已经引入 Tool Search,依靠 namespace、MCP server 和工具描述动态发现所需能力;MCP 规范也要求工具具有名称与描述其 schema 的元数据。由此可以推论:未来企业除了 SEO,还必须管理一种“Capability Discoverability”——机器是否知道企业具有什么能力、何时可以调用以及如何安全调用。[OpenAI Tool Search] [MCP Tools]
但我不建议现在就把它包装成玄学式“AI SEO”。Google 本身仍强调标准化、准确的结构化数据和传统可抓取网页;机器可发现性的本质不是欺骗模型,而是:
让真实企业能力变得结构化、可信、实时并可验证。
企业级参考架构:零售、制造与金融
以下三个架构采用同一原则:
One Digital Core, Multiple Human Surfaces, One Governed Machine Surface。
一个数字核心,多个面向人的界面,一个受治理的机器执行面。
其中 Agent 原则上不直接连接生产数据库进行自由写入;所有写操作经过领域 API、权限判断、风险引擎和审计。这一设计与当前 MCP 对授权、安全政策和用户授权决策的架构原则相一致,也与 OpenAI 支持对 MCP 工具设置显式批准要求的设计方向一致。[MCP Architecture] [OpenAI MCP]
零售企业:全渠道消费与 Agent Commerce

核心数据流:
商品主数据由 PIM 作为权威来源,库存来自 WMS,价格与促销由 Pricing Service 管理;网站、APP、小程序不再维护彼此独立的商品事实。公开商品数据同步生成网页 Schema/Feed,从而同时供传统搜索和 AI 商品发现使用。用户身份、会员、交易和行为事件回流 CRM/CDP;订单进入 OMS,再协调库存、支付、物流和售后。
OpenAI 2026 年的 Agentic Commerce/Product Feed 文档已经非常直观地说明了这种机器消费结构:结构化商品 feed 可以提供价格、库存、卖家等上下文,使 ChatGPT 更准确地发现商品。[OpenAI Agentic Commerce]
建议关键接口:
product.search、product.get、inventory.get、price.quote、promotion.eligible、cart.update、order.prepare、order.create、payment.intent.create、order.status、return.request、loyalty.balance。
这里有一个非常关键的语义设计:
不要直接暴露:
create_payment()
而优先设计:
prepare_payment()↓risk_check()↓user_confirmation()↓execute_payment()
把“计划”与“不可逆执行”分离。
Agent Skills 建议:
商品顾问、需求澄清、商品比较、库存查找、智能凑单、优惠组合解释、订单查询、退换货资格判断、售后分诊、客服知识检索、营销活动分析。
真正付款、高额优惠、退款、会员权益修改等应设置更高权限和用户确认。
零售场景的利润逻辑是:

因此 Agent 在零售里最有价值的地方不是“把客服聊天机器人做得更聪明”,而是把:
发现 → 比较 → 决策 → 加购 → 交易 → 售后
连接成一条可测量的利润链。
制造企业:从数字渠道走向生产智能

制造业中,网站更多承担企业/产品/供应商门户作用,APP 适合现场拍照、扫码、设备通信、离线操作,小程序适合经销商、维保、备件查询和轻量订单;而 Agent 最有价值的空间通常发生在跨系统知识劳动中。
典型数据流:
设备异常→ IoT / Historian→ 异常检测→ Agent读取报警记录→ 查询设备手册→ 查询历史维修记录→ 查询备件库存→ 生成诊断建议→ 人工批准→ CMMS创建工单→ 工程师APP执行→ 维修结果回流→ 知识更新
这比单纯“对 MES 加一个聊天框”有战略价值。
建议关键接口:
machine.status.readalarm.history.readbom.readmanual.retrievepart.inventory.readquality.case.searchmaintenance.history.readworkorder.prepareworkorder.createschedule.simulatesupplier.status.read
Agent Skills:
设备故障诊断、维修 SOP 检索、历史故障归因、备件推荐、生产异常总结、质量根因分析、CAPA 草案、供应商异常分析、排产方案模拟、技术资料问答、研发 BOM 影响分析。
对于涉及人身安全、设备安全、质量放行的操作,不应让通用 Agent 自主作最终决策,而应:
Agent建议→ 确定性规则→ 工程/质量负责人→ 正式执行
这里的利润来源与零售完全不同:

所以制造业的北极星指标不是 DAU,而可能是:
OEE、非计划停机时间、MTTR、一次良率、库存周转、工程师解决问题时间。
这恰恰说明“数字资产”必须最终对应真实生产能力,而不能陷入纯互联网式流量思维。
金融企业:渠道数字化与受控智能执行

金融场景应采取四者中最严格的“执行分层”。
例如客户说:
“帮我把 20 万元转给张三。”
Agent 不应该拥有:
ledger.write
而应获得:
beneficiary.lookup↓balance.read↓transfer.prepare↓fraud/risk check↓display transaction↓step-up authentication↓explicit confirmation↓transaction service execute↓ledger posting
最终改变资金状态的是确定性交易服务,不是语言模型。
建议关键接口:
account.balance.readtransaction.searchproduct.info.readcustomer.profile.readcashflow.analyzesuitability.checktransfer.preparepayment.preparecase.openappointment.bookdispute.open
Agent Skills:
账单解释、交易检索、现金流分析、产品知识问答、申请表预填、服务分诊、投诉总结、客服坐席辅助、内部政策检索、AML/欺诈调查材料汇总。
在高风险活动上,建议坚持:
Agent 可以解释、整理、模拟、准备;是否允许它决策和最终执行,要由法律责任、金额、可逆性、模型错误成本决定。
这不是保守,而是最优经济设计。
因为一个 Agent 自动完成 99.9% 普通交易节省的人工成本,可能被极少数高额错误交易一次性吃掉。
因此企业需要计算:

Agent 应不应该拥有写权限,本质上是期望收益—尾部风险问题,不是技术团队觉得它“能不能调用 API”的问题。
分阶段实施路线图、组织治理与预算
这里最容易犯的错误是:
先立项“做一个企业 Agent”,然后再找它能干什么。
顺序应该完全相反:
利润池 → 工作流 → 数据 → API → 权限 → Agent。
而不是:
模型 → Demo → 找业务场景。
学术研究中所谓 AI“生产率 J 曲线”已经说明,通用技术需要大量互补组织资本才能释放长期价值;因此企业应把流程重构和数字底盘视为 AI 投资本身,而不是额外的“IT 整理工作”。[Brynjolfsson, Rock & Syverson]
短期:约 0—6 个月,重点不是大规模 Agent 化,而是“盘资产、统一状态、建立接口纪律”。
首先建立 Enterprise Digital Asset Inventory:
域名网站APP小程序公众号/平台账户API数据库数据集模型PromptAgentSkills知识库SDKSaaS核心系统第三方平台依赖
每项记录:
Owner、成本、调用量、收入贡献、数据等级、用户、供应商、替换成本、会计处理、合规责任、退出方案。
随后建立“渠道任务地图”。不要问:
APP 有什么功能?
改成问:
客户有哪些 Job-to-be-done,每一种任务应该由哪个入口以最低总摩擦完成?
建议短期完成以下里程碑:
里程碑 | 建议目标 |
企业关键主数据 Owner | 客户、产品、订单、供应商、设备等核心对象全部明确权威来源 |
关键 API 目录 | Top 20—50 个高价值业务能力接口化 |
IAM/SSO | 员工、客户、服务账户、Agent 身份体系明确 |
数据分级 | PII、敏感、商业秘密、公开信息等分类 |
官网机器可读化 | Organization/Product 等结构化数据、robots/crawler 策略明确 |
Agent Pilot | 优先 2—4 个“高频、可测、低不可逆风险”流程 |
Eval 基线 | Pilot 上线前先获得人工成本、时间、成功率和错误率基准 |
此阶段的核心禁令是:
Agent 不允许为了赶 Demo 进度直接拥有生产数据库万能账号。
中期:约 6—18 个月,进入“统一业务能力层”。
重点形成:
System of Record↓Domain APIs↓Event Bus↓API Gateway↓Policy / Identity↓Website / App / Mini Program / Agent
网站、APP、小程序开始共享领域服务,而不是三个团队各自产生业务逻辑。
例如会员等级规则只存在于:
loyalty-service
而不是:
website会员逻辑app会员逻辑mini-program会员逻辑agent-prompt里面再写一遍
这会显著降低未来维护复杂度。
Agent 侧建立:
Agent Gateway + Tool Registry + Model Router + Eval + Trace + Approval Service。
OpenAI 当前的 Agents SDK 和 MCP 已把 tracing、工具调用、审批等做成标准能力方向;MCP 2026 年规范也正式把授权和安全考虑纳入协议。[OpenAI Agent Integrations & Observability] [MCP Authorization]
中期 Agent 权限建议至少分四级:
等级 | 权限 |
L0 | 公开知识 |
L1 | 登录后只读企业/用户数据 |
L2 | 可准备操作,但执行前必须确认 |
L3 | 可在金额、对象、时间等严格 policy 内自主执行 |
L4 | 高风险自主决策,原则上只在极少量充分验证场景使用 |
绝大多数企业的生产 Agent 首先应该集中在 L1—L2,而不是追求所谓“完全自主”。
长期:约 18—36 个月及以后,目标才是形成“机器可交易企业”。
这时企业不只是拥有一个内部 Agent,而应该拥有一套:
Machine-Callable Enterprise Capability Layer
即外部可信 Agent 也可以在授权以后调用企业能力:
外部Agent↓企业Agent Gateway↓身份认证↓Capability Discovery↓Quote / Search / Book / Order↓Policy↓交易确认↓System of Record
未来企业可能同时面对:
Human Customer
和
Machine Customer / User Agent。
在零售场景,这已经开始具象化。OpenAI 当前允许商户通过结构化产品数据进入 Agentic Commerce/Product Discovery,其商品发现和最终结账正在形成“AI 发现—商户系统履约”的分工。[OpenAI Agentic Commerce]
长期架构应该具备:
多模型路由、Agent-to-Agent、统一能力目录、可组合 Skills、实时风险引擎、全链路审计、机器身份、API/MCP 出口以及供应商退出机制。
组织上,建议不要让“AI 部门”独立吞下全部权力,而设置一个跨部门 Digital Asset & AI Governance Council:
CEO / COO / CFO│Digital Asset & AI Governance Council│ ┌─────┼──────┬──────┬───────┐业务CIO/CTOCISO法务财务/审计│Platform EngineeringData GovernanceAI/Agent EngineeringProduct Teams
职责应明确:
业务负责人对业务结果负责; CIO/CTO对架构和技术债负责; CISO对身份、权限、供应链和攻击面负责; 数据负责人对数据质量和使用边界负责; 法务/合规对法律适用和用户权利负责; CFO/会计负责资本化政策、资产登记、摊销/减值和 ROI; 模型团队只对模型本身负责,不能独自决定 Agent 有多大生产权限。
预算估算。
由于用户未指定规模和行业,下面不是市场报价,而是本报告的咨询级情景估算,币种为人民币,适用于约 18—36 个月建设周期,并假定不包括整体替换 ERP/Core Banking、不自研基础大模型、不建设超大 GPU 集群、不进行大型并购。
档位 | 典型情景 | 建议总投入 |
低档 | 50—300 人企业;已有 SaaS/ERP;单一地区;约 5—10 个关键集成;网站/小程序/Agent 轻量建设 | 150万—400万元 |
中档 | 500—5000 人;多个业务单元;APP+小程序+网站均较重要;15—40 个系统接口;正式数据/AI 平台 | 800万—2500万元 |
高档 | 全国性或强监管大型企业;50+ 系统;多法人/多地区;24×7;高可用、安全、私有数据平台、复杂 Agent | 3000万—1.2亿元以上 |
对于一个典型中档项目,我会建议大致按以下经济结构思考,而不是先按产品采购清单分钱:
数据 + API + 系统集成30%—40%网站/APP/小程序渠道重构15%—25%Agent/知识/工具/Eval15%—25%身份/安全/治理/合规10%—15%云资源/可观测性/运营/预备金10%—20%
这些比例是项目规划建议,不是会计标准或市场统计。
最值得特别强调的是:
预算不足时,宁可少做几个 Agent 场景,也不要省掉 API、身份、日志和评估体系。
因为一个漂亮但无法访问真实企业状态的 Agent 只是 Demo;
而一套干净的业务能力层,即使今天没有 Agent,也能同时提升网站、APP、小程序和传统自动化。
风险、合规与会计治理
Agent 时代会把过去分散在“软件安全、数据合规、业务内控”中的风险汇聚到同一个执行主体上,因此风险等级并不是线性增加,而可能是乘法关系:

一个只回答公开 FAQ 的 Agent,即使偶尔答错,风险有限。
一个能:
读工资+读客户隐私+发邮件+退款+修改合同+付款
的 Agent,哪怕模型错误率非常低,也可能产生严重尾部风险。
中国大陆方面,《生成式人工智能服务管理暂行办法》的适用边界尤其值得企业区分:面向中国境内公众提供生成式 AI 服务属于其适用范围,而企业内部研发、应用生成式 AI、但没有向境内公众提供服务的情形并不适用该办法的相同规定。[国家网信办《生成式人工智能服务管理暂行办法》]
这意味着:
内部员工 Agent 与公开客户 Agent,在监管设计上不能简单视作同一种产品。
同时,中国《人工智能生成合成内容标识办法》及配套标准已于 2025 年 9 月 1 日实施,对适用范围内的生成合成内容规定显式/隐式标识机制。[国家网信办]
若企业在欧盟经营,2026 年 8 月 2 日已经是新的关键日期:欧盟委员会开始执行 AI Act 的相关制度,Article 50 等 AI 透明度要求也从该日适用,包括某些与用户直接交互的 AI 系统以及 AI 生成/操纵内容的透明度义务。[European Commission AI Act]
因此,企业的风险清单至少应做到以下级别:
风险 | 典型表现 | 缓解措施 | 强制控制点 |
个人信息泄露 | Prompt、RAG、日志或第三方模型暴露客户/员工信息 | 最小化采集、字段脱敏、数据分类、权限隔离、用途限制、生命周期管理 | PII Gateway + DLP |
Agent 越权 | 用户只要求查询,却执行退款/删除/发送 | 最小权限、read/write 分离、scope token、交易限额、审批 | Policy Engine |
Prompt Injection | 网页/邮件/文档恶意指令诱使 Agent 泄露数据或调用工具 | 外部内容划为不可信数据、工具白名单、隔离执行、输出验证、secret 不进入 prompt | Trust Boundary |
幻觉 | 错误产品、错误合同解释、错误业务事实 | 权威数据源、RAG 引证、确定性业务规则、拒答、人工升级 | Eval + Grounding |
不可逆操作 | 付款、删除、合同签署、订单取消 | “prepare → confirm → execute”三阶段;step-up authentication | Transaction Gate |
模型供应商锁定 | Prompt/Workflow 全绑定单一模型 | Model Router、抽象工具层、OpenAPI/MCP、数据与状态留在企业 | Exit Plan |
平台锁定 | APP/小程序严重依赖某一平台身份、API 或流量 | 自有域名、统一 ID、企业 API、可迁移后台、跨入口会员体系 | Dependency Register |
生成内容合规 | AI 文案/图片无标识、误导用户 | 适用性判断、生成标识、内容分类、人工审核 | Content Governance |
模型错误法律责任 | Agent 给出错误金融/健康/法律等高风险建议 | 使用场景分级、限制自主决策、专业人员复核、留痕 | Human-in-the-loop |
SDK/供应链 | APP 第三方 SDK 采集额外数据或遭攻击 | SBOM、SDK 白名单、签名、依赖扫描、Privacy Manifest | Software Supply Chain |
跨境数据 | 海外模型/API 造成数据跨境 | 数据地图、法域路由、数据驻留、必要性评估、脱敏 | Data Residency |
会计误资本化 | 将 SaaS 订阅、研究、营销、一般运营成本全部“数字资产化” | 研究/开发阶段分开核算;项目工时和成果登记;逐项评估控制权 | CFO + Auditor |
数字资产减值 | 技术淘汰、平台政策变化导致资本化软件价值下降 | 生命周期管理、减值触发指标、技术债指标 | Asset Review |
业务连续性 | 模型服务中断导致核心流程瘫痪 | 人工 fallback、确定性流程、双模型/多供应商、熔断 | BCP/DR |
APP 还存在额外的平台合规层。Apple 当前 App Review Guidelines 明确要求,如果 App 将个人数据分享给包括第三方 AI 在内的第三方,应清楚披露并取得明确许可;App Privacy 信息也要求开发者申报自身及第三方合作方的数据收集行为。[Apple App Review Guidelines] [Apple App Privacy]
所以 APP + Agent 并不是把 OpenAI/Anthropic API 接进去就结束,而必须形成:
用户数据↓用途判断↓同意/合法性基础↓必要字段筛选↓脱敏↓模型路由↓结果验证↓日志策略
在会计治理上,应特别建立一个 Digital Asset Register,但不要把它与会计资产台账混为一谈。
建议分成:
A. Strategic Digital Asset Register所有具有未来经济价值的数字能力B. Accounting Intangible Asset Register满足会计确认标准的资产C. Digital Operating Expense RegisterSaaS / API / 平台 / AI 调用等期间成本
这样就能同时避免两个极端:
一种极端是:
“软件、数据都是费用,没有资产价值。”
另一种极端是:
“花在数字化上的钱都应该资本化。”
两者都不对。
IFRS 的核心判断依然是控制、可辨认性、未来经济利益以及确认标准;SaaS 供应商控制的软件并不会因为企业投入大量定制成本,就自动变成企业控制的无形资产。[IAS 38] [IFRS SaaS decision]
从战略资产折旧角度,我建议企业甚至建立一种经济折旧模型,独立于法定会计摊销:

这样可以看出:
一个漂亮但被某个平台完全锁住的前端,经济折旧很快;
而一套干净、稳定、多个渠道都在调用的 order-service,可能越用价值越大。
所以数字资产真正值得资本化思考的方向不是:
“我们今年写了多少代码?”
而是:
“我们今年形成了多少可重复使用、受企业控制、能持续产生现金流的数字能力?”
KPI、ROI 与利润最大化计算
这一体系最忌讳用“下载量、访问量、Token 数、Agent 对话量”等虚荣指标替代经济结果。
第一层必须是:
Economic KPI。
第二层才是:
Channel KPI。
第三层是:
Technical KPI。
建议最终形成如下 KPI 树:
企业经济利润│┌───────────────┼────────────────┐收入成本资本效率│││转化/客单/留存人工/IT/渠道成本库存/设备/营运资本│┌──────┼──────┬──────┐网站APP小程序Agent
网站 KPI
重点不是 PV,而是:
Organic Qualified TrafficAI/Search Referral TrafficQualified Lead ConversionSEO/AI Assisted RevenueStructured Data CoverageCrawler AccessibilityPublic Information AccuracyCost per Qualified Lead
OpenAI 当前会在 ChatGPT Search 推荐链接中提供 utm_source=chatgpt.com,企业已经可以开始把 AI Search 推荐流量纳入归因体系。[OpenAI Publisher FAQ]
APP KPI
建议重点看:
30/90/180-day RetentionAuthenticated Active UsersTransaction ConversionRevenue per Active UserPush → Action ConversionCrash-free SessionsCost per TransactionChurnShare of High-frequency Transactions
APP 的经济价值尤其应该通过:

进行 cohort 比较,而不是简单把所有 APP 用户收入都归功于 APP。
小程序 KPI
重点应是:
Open → Transaction ConversionQR → Service CompletionMini Program GMVCost per Completed ServiceRepeat UseMember Binding RateOffline-to-Online ConversionPlatform Dependency Ratio
最后一个指标非常重要。
可以定义:

这个数字不是越低越好,但应该进入董事会的风险视野。
如果 80% 数字收入依赖一个平台,平台其实已经成为企业非常重要的隐性“地主”。
Agent KPI
Agent KPI 最容易被 Token 指标带偏。
真正关键的是:
Task Success Rate:任务是否真的完成;
First-pass Resolution:是否一次解决;
Human Escalation Rate:有多少最终转人工;
Tool Success Rate:工具调用成功率;
Unauthorized Action Rate:越权执行率,目标应接近零;
Grounded Answer Rate:关键事实是否来自权威数据;
Cost per Successful Task:每个成功任务综合成本;
Cycle Time Reduction:流程时间减少多少;
Agent-caused Loss:Agent 导致的退款、返工、投诉、错误决策损失;
Revenue per Agent-assisted Journey:Agent 参与路径产生的贡献毛利。
因此:

而不能只算:

更高级的 Agent ROI 应写成:

例如:
人工客服原来处理 100 万次任务,综合成本 10 元/次;
Agent 处理 70%,Agent 综合成本 1.5 元/次;
但 10% 仍需要人工复核,平均 4 元;
Agent 错误导致每年预计损失 80 万元。
则年度经济收益不能简单说:

而应该把复核成本、失败任务、风险损失、额外云成本全部扣除。
企业级总 ROI 建议采用三年 NPV,而不是第一年成本节约。

其中:
= 初始开发、集成和组织变革投入;
= 每年增量现金流;
= 企业资本成本或内部 hurdle rate;
= 评估期限。
总经济收益建议拆为:

其中:

而不是把新增销售额全部当收益。
例如 Agent 推荐带来 1000 万元新增销售,如果贡献毛利率只有 30%,经济贡献首先是约 300 万元,而不是 1000 万元。
对于制造业:

对于库存:

注意库存释放属于现金与资本效率改善,不能与利润简单重复计算。
对于网站/APP/小程序转化效果,最好使用实验或准实验:
A/B TestGeo TestHoldoutMatched CohortDifference-in-Differences
不要简单使用:
“上线 Agent 以后销售增长 10%,所以 10% 全是 Agent 带来的。”
否则 ROI 很容易被宏观经济、促销、季节性和渠道变化污染。
最终,建议董事会只盯住五个数字:
董事会指标 | 回答的问题 |
Digital Contribution Profit | 数字体系真正创造多少贡献利润? |
Digital Revenue Share | 多少业务已具备数字交易能力? |
Shared Capability Reuse Rate | API/数据/服务是否真正被多个入口复用? |
Cost per Completed Customer Job | 完成客户真正任务的成本是否下降? |
Risk-adjusted Agent ROI | AI 自动化的利润是否覆盖错误、治理和模型成本? |
这样就不会出现一个典型错误:
网站团队追 PV,APP 团队追 MAU,小程序团队追 GMV,AI 团队追调用量——结果四个部门 KPI 都完成了,公司利润没变。
真正的管理方式应该是:
四个渠道共享经济 KPI,渠道指标只是解释变量。
战略结论与企业最优协同模型
如果把整个研究压缩成一个企业战略模型,我会把企业未来的数字体系分成六层:
┌──────────────────────────────┐│智能层 Intelligence││ Agent / Skills / Evals│├──────────────────────────────┤│交互层 Interaction││ Website / App / Mini Program │├──────────────────────────────┤│能力层 Capability││ API / MCP / Event / Workflow │├──────────────────────────────┤│状态层 State││ Customer/Product/Order/Data│├──────────────────────────────┤│核心系统 System of Record││ ERP/CRM/MES/Core/WMS/PIM│├──────────────────────────────┤│实体生产层 Physical││ 工厂/员工/门店/仓库/设备/资本│└──────────────────────────────┘
这六层之间最重要的战略关系是:
交互层会快速变化;能力层应该稳定;状态层必须属于企业;智能层必须可替换;实体层最终兑现价值。
这直接给出了“网站、APP、小程序、Agent 谁最重要”的答案:
没有一个单独最重要。
它们掌握的是不同种类的权力。
网站掌握的是:
Identity & Discoverability——身份与开放发现权。
APP 掌握的是:
Presence & Relationship——终端驻留和长期关系权。
小程序掌握的是:
Distribution & Friction Reduction——平台分发和摩擦消除能力。
Agent 掌握的是:
Intent & Execution——意图理解与执行调度权。
而企业真正应该牢牢掌握的是:
State & Capability——业务状态与核心能力。
因此我不同意“未来 Agent 会使网站/APP/小程序全部消失”。
更准确的判断是:
Agent 会使大量“为了操作软件而操作软件”的 UI 逐渐贬值,但不会使所有数字界面消失。
可视化浏览、品牌表达、法律确认、复杂比较、支付、身份认证、线下扫码、设备交互、沉浸式体验,都仍然需要不同类型的界面。
但 Agent 会把过去必须由人做的:
打开→ 搜索→ 找菜单→ 筛选→ 复制→ 比较→ 填表→ 跨APP切换→ 再输入
压缩成:
表达目标→ 确认结果
于是未来软件最大的变化不是:
Software → Agent
而可能是:
GUI-centric Software → Capability-centric Software。
软件不再主要以“多少个页面”衡量,而开始以:
企业有多少可靠、受控、可调用的能力。
这也是为什么我认为未来十年真正值得企业资本化思考的数字资产排序,大致会变成:
品牌与信任↓客户身份与关系↓高质量主数据↓业务规则↓领域API↓工作流↓知识库↓Agent Skills↓Evals / Feedback↓具体模型
最下面的基础模型反而可能是最容易被替换的一层。
今天领先的模型未必永远领先,因此企业把护城河建立在:
“我们用了某个最强模型”
非常危险。
真正稳固的 Agent 壁垒更可能来自:
别人没有你的数据,没有你的历史业务知识,没有你的流程,没有你的合法权限,没有你的客户关系,也没有经过数百万次真实任务不断优化出的评估与反馈体系。
这才属于企业。
这也是本报告最核心的“数字资产主权观”:
模型可以租,平台可以租,流量可以租;核心状态不能租丢。
在利润最大化条件下,我建议企业最终形成:
┌────开放互联网 ─── Website│消费者 / 企业 ──────┼──── 移动终端 ───── APP│├──── 微信生态 ───── Mini Program│└──── AI生态 ─────── Agent│Agent Gateway│Identity / Policy / Audit│API / MCP / Event│┌──────────┬──────────┬──────────┐CRMERPOMSMES...└──────────┴──────────┴──────────┘│企业数据│真实业务│现金流
于是企业拥有了一种非常强的战略特征:
入口可替换,模型可替换,平台可替换,但企业自身的业务状态、客户关系和生产能力不可替代。
这也是判断数字化项目到底是不是“资产”的最终标准。
真正的资产不是:
“我们有一个 APP。”
而是:
APP 消失以后,那些客户、订单、数据、品牌、业务规则、API 和关系还在不在?
真正的 Agent 资产也不是:
“我们部署了一个 AI 助手。”
而是:
换掉模型供应商以后,那些 Skills、知识、工具、权限、工作流、评估数据和生产能力还在不在?
如果答案是“在”,企业真正积累了数字资本。
如果答案是“不在”,企业主要是在替平台积累资产。
因此,对网站、APP、小程序和 Agent 最优的企业战略,可以浓缩为四句话:
网站要做成企业在开放互联网里的数字产权。
APP 要做成高价值客户关系的长期终端。
小程序要做成超级平台中的低摩擦交易接口。
Agent 要做成企业业务能力的受治理智能调度器。
而它们下面必须共享同一套:
身份、数据、API、规则、交易系统、知识和审计。
最终,互联网企业竞争的演化可以概括为:
Web时代争夺“被找到”↓APP时代争夺“被安装”↓超级平台时代争夺“被分发”↓算法时代争夺“被推荐”↓Agent时代争夺“被选择 + 被调用”
所以,企业未来面对的竞争已经不只是一种传统 SEO:
“人能不能找到我?”
而增加了两个新问题:
“机器能不能准确理解我?”
“机器有没有能力安全地与我交易?”
这会把未来企业分成两类。
一类企业只有网页、APP 和小程序的“表面数字化”:
人来了→ 看页面→ 自己操作
另一类企业逐渐形成真正的机器可调用企业(Machine-callable Enterprise):
人或Agent提出需求→ 企业身份可被发现→ 产品/服务机器可理解→ 价格/库存实时可查询→ 能力可调用→ 权限可验证→ 交易可执行→ 结果可审计
后一类企业拥有的就不再只是“几个软件产品”,而是一套新的数字生产资料。
这也是为什么,从战略上看,你最初提出的命题——
“相对于实体,数字资产的地位正在逐渐可以相提并论。”
并不意味着软件会替代工厂、土地、机器和人。
更加准确的表述是:
实体资产决定企业能生产什么;数字资产越来越决定这些生产能力能否被发现、被组织、被交易、被调度和被规模化。
因此真正优秀的现代企业,并不是:
实体企业或互联网企业二选一。
而会逐渐成为:
实体生产能力 × 数字资产 × 智能执行能力。
这三个乘数中的任何一个接近零,企业整体价值都会被显著压制。
核心权威来源
本报告优先使用官方、标准制定机构及同行评审学术来源。以下资料是进一步进行董事会级战略设计、数字资产估值、架构治理和投资立项时最值得保留的一组基础文献。
主题 | 权威来源 |
全球无形资产投资 | WIPO — World Intangible Investment Highlights 2026 |
企业无形资产价值 | WIPO — The Value of Corporate Intangible Assets Worldwide |
无形资产会计确认 | IFRS Foundation — IAS 38 Intangible Assets |
网站成本会计 | IFRS Foundation — SIC-32 Intangible Assets—Web Site Costs |
SaaS 定制成本 | IFRS — Configuration or Customisation Costs in a Cloud Computing Arrangement |
中国企业数据资源会计 | 财政部 — 企业数据资源相关会计处理暂行规定相关说明 |
APP 经济规模 | Apple — App Store ecosystem 2026 |
APP 隐私/AI | Apple — App Review Guidelines |
微信/小程序生态 | Tencent — Weixin & WeChat |
Agent 工具调用 | OpenAI — Function Calling |
Agent 编排 | OpenAI — Agents SDK |
MCP 与企业工具 | OpenAI — MCP and Connectors |
Agent Skills | Anthropic — Agent Skills |
MCP 标准 | Model Context Protocol — Specification 2026-07-28 |
网站机器可发现性 | Google Search Central — Structured Data |
ChatGPT 网站发现 | OpenAI — ChatGPT Search |
Agent Commerce | OpenAI — Agentic Commerce |
AI 与组织资本 | Brynjolfsson, Rock & Syverson — The Productivity J-Curve |
平台生态依赖研究 | Agarwal & Kapoor — Value Creation Tradeoff in Business Ecosystems |
中国生成式 AI 监管 | 国家网信办 — 生成式人工智能服务管理暂行办法 |
中国 AI 内容标识 | 国家网信办 — 人工智能生成合成内容标识办法 |
欧盟 AI 监管 | European Commission — AI Act |