企业官网建设流程全解析

本文章中的“企业内部 Agent”指企业为自身员工和业务流程建设或采购的 Agent；“ToB 外部赋能”指向其他企业出售 Agent 产品、平台、解决方案或运营服务。两者可能共用模型与平台，但价值责任、工程边界和商业逻辑并不相同。

目录

• 一、执行摘要

• 二、为什么同一套技术会形成两种落地逻辑

• 三、企业内部 Agent 落地的六个主要难点

• 1. 价值责任：平台负责建设，却没人对经营结果负责

• 2. 流程重构：局部任务更快，端到端流程没有变化

• 3. 数据与系统：知识库能回答，不代表系统能执行

• 4. 可靠性与治理：评测对象从答案升级为行动链

• 5. 成本与经营核算：Token 价格不是完整成本

• 6. 员工采用与组织变化：给账号不等于进入工作方式

• 四、ToB 企业外部赋能的八项关键设计与交付难题

• 1. 产品标准化与客户定制持续冲突

• 2. 异构系统集成让“标准连接器”变成长期工程

• 3. 多租户隔离必须贯穿 Agent 全链路

• 4. 客户私有评测无法被公共基准替代

• 5. SLA 从系统可用性升级为任务有效性

• 6. 定价和单位经济模型尚未稳定

• 7. 安全、合规和合同责任跨越多方供应链

• 8. 客户成功、升级和退出都是产品能力

• 五、共同难点相似，但责任位置不同

• 六、企业应该如何选择建设路径

• 七、一种常见但非唯一的路径：从内部闭环走向 ToB 规模化

• 八、两类场景分别应该看什么指标

• 九、结论

一、执行摘要

当前讨论企业 Agent 时，人们经常把两个不同问题混在一起：一类是企业如何让 Agent 在内部真正产生经营结果；另一类是技术或平台厂商如何把 Agent 能力卖给外部企业，并实现规模化交付。前者面对的是一个组织内部的流程、数据、权限和岗位重构，后者面对的是跨客户的产品标准化、多租户隔离、合同承诺、客户成功和单位经济模型。

两类场景共享模型、知识、工具、评测和安全底座，但失败方式完全不同。内部 Agent 最常见的问题是“做出来却用不深，使用了却算不清价值”；ToB Agent 最常见的问题是“单个客户能交付，但每增加一个客户都要重新定制，收入增长没有转化为产品毛利”。

本文判断：企业内部 Agent 的核心任务，是把智能能力嵌入业务并形成经营闭环；ToB 外部赋能的核心任务，是把这种能力封装成可隔离、可配置、可计量、可承诺、可升级的长期产品。因此，不能简单把内部 Agent 平台开放给客户，也不能把 ToB 产品的活跃度指标直接当成客户内部的经营价值。

企业内部 Agent 与 ToB 外部赋能的目标、难点和成功单位

二、为什么同一套技术会形成两种落地逻辑

企业内部 Agent 的边界是一个组织。它可以接入统一身份系统、业务数据和内部 API，也有机会推动流程负责人修改审批、岗位和绩效机制。它的最终成功单位不是 Agent 数量或 Token 调用量，而是“可信完成的业务结果”：例如流程周期缩短、一次解决率提高、风险损失下降或业务容量增加。

ToB 外部赋能面对的却是多个独立企业。客户拥有不同的数据规则、遗留系统、部署环境、采购制度和风险偏好，供应商通常无权直接改变客户流程，却要承担产品稳定性、数据处理、安全运营和合同服务责任。它的成功单位因此是“可续约的客户价值”：客户愿意持续使用、扩容和续费，同时供应商仍能维持健康交付成本与毛利。

这意味着从内部走向 ToB，不只是增加销售和界面，而是发生一次责任跃迁。内部平台可以依靠管理命令、跨部门协调和人工补位解决部分问题；ToB 产品必须把这些控制做成产品能力、租户机制、运营证据和合同条款。内部 Agent 可以借助组织管理补控制缺口，ToB Agent 必须把控制产品化、租户化、证据化和合同化。

三、企业内部 Agent 落地的六个主要难点

1. 价值责任：平台负责建设，却没人对经营结果负责

内部 Agent 往往由技术团队或创新部门牵头，业务部门提供场景，安全和法务负责审批。看似多人参与，却可能没有唯一业务责任人（Owner）对端到端结果负责。KPMG 2026 年第二季度对 20 个国家和地区 2,145 名高级管理者的调查显示，只有 24% 表示 CEO 对 AI 驱动的业务结果负责；具备更高层责任机制的企业，在战略信心、业务价值和 ROI 建立方面表现出更强相关性。[1] 这是整体 AI 口径，不能证明责任机制单独造成回报，但足以说明责任与价值之间存在明显联系。

Agent 内部落地必须在上线前明确四件事：谁拥有业务结果，谁拥有风险，改善相对于什么基线，什么条件下缩小自治或停机。平台团队可以承诺身份、评测、链路追踪（Trace）和运行稳定性，却不能替业务部门承诺销售转化、供应链周转或客户满意度。

内部 Agent 不是一款普通软件，而是一名没有编制、却拥有系统权限和预算消耗能力的“数字员工”。难点不是它会不会回答，而是谁授权、谁监督、谁付费、谁承担错误结果。

2. 流程重构：局部任务更快，端到端流程没有变化

许多项目先把 Agent 塞进旧流程：自动生成材料后仍需多级审批，自动诊断后仍由人工重复核对，客服回复更快但转人工率和退款损失没有下降。Deloitte 2026 年对 501 名至少已经试点 Agent 的美国企业领导调查显示，只有 5% 认为流程已经高度适配 Agent，只有 20% 准备好围绕自主 Agent 重构流程。[2]

IBM 2026 年研究也把流程、数据和决策权列为高规模、高 ROI 的主要障碍；受访者估计，业务与 IT 环境摩擦会侵蚀 21% 的 AI ROI。[3] 这个 21% 是管理者估算而非审计结果，但它提醒企业：Agent 提升任务速度后，等待、返工、例外和跨部门协调可能成为新的主要成本。

内部场景应以端到端流程为对象设计 Agent：明确正常路径、例外队列、人工接管（Human Handoff）、审批权限和失败补偿，并同时观察周期、一次通过率、异常损失和最终损益。内部规模化的核心单位不应是 Agent 数量，而应是“已经被重构并形成损益闭环的业务流程数”。

3. 数据与系统：知识库能回答，不代表系统能执行

内部 Agent 要面对分散的数据所有权、冲突文档、隐性经验和大量遗留系统。Deloitte 同一调查中，72% 的受访者表示缺少统一、可访问的数据，67% 认为集成成本过高且复杂。[2] 文档进入向量库只能解决部分检索问题，不能自动确定哪份制度有效、某字段由哪个系统负责，也不能保证 Agent 重试时不会重复下单或重复记账。

企业需要按任务建立最小可信数据面：规定权威数据源、版本、更新时间、权限和不可用时的降级路径；对产生业务副作用的 API 加入幂等、事务、状态核验和补偿机制。内部团队的优势是能够推动系统负责人改造接口，但这需要业务优先级和预算，而不是仅靠 Agent 平台绕过旧系统。

4. 可靠性与治理：评测对象从答案升级为行动链

Agent 的路径会随模型、提示词（Prompt）、知识、工具状态和策略版本变化，只评最终答案无法发现越权工具选择、危险参数和失败重试。《Towards a Science of AI Agent Reliability》2026 年 9 月更新的 v3 版本对 15 个模型在 GAIA 与 τ-bench 上的分析表明，能力提高不自动等于运行更稳定和可预测。[4] Deloitte 2026 年另一项覆盖 24 国、3,235 名 AI 项目参与者的调查中，仅 21% 自报拥有成熟的 Agent 治理能力。[5]

内部企业应建立离线黄金集、对抗集、线上 Shadow/灰度和生产监控四层评测，并将 Agent 审计的最小单位定义为可重放的“授权—决策—行动—结果”链。模型、Prompt、Skill、知识和工具任何一项变化，都应触发与风险等级相匹配的回归门禁（Regression Gate）。

5. 成本与经营核算：Token 价格不是完整成本

内部 Agent 的成本还包括检索、工具 API、沙箱、重试、人工复核、日志、安全运营和异常处置。KPMG 2026 年对美国大型企业的季度调查显示，仅 26% 的受访企业对 AI 运营成本拥有完整的实时可见性，33% 把不了解使用成本列为 Agent 部署挑战。[6] KPMG 2026 年第三季度全球调查则显示，只有 12% 持续把 AI 价值与成本进行对照评估。[7]

企业应核算“每个可信完成任务的完整成本”，并把返工、超时或产生错误副作用的任务排除在成功分母之外。对于低价值高频任务，规则、小模型、缓存和批处理可能优于长链推理；对于高价值低频任务，则可以接受更多推理和人工审批。

6. 员工采用与组织变化：给账号不等于进入工作方式

Agent 会改变岗位边界、审批权和绩效衡量。Microsoft 2026 Work Trend Index 对 10 国 20,000 名工作中使用 AI 的员工调查显示，组织文化、经理支持和人才制度等组织因素，对受访者报告的 AI 影响解释力约为个人努力的两倍。[8] 这一结果来自已使用 AI 的员工和自报影响，不能直接当作生产率测量，但说明采用问题不是一次培训可以解决。

内部落地需要让一线员工参与异常定义和验收，明确哪些能力增强岗位、哪些任务被取消、哪些高风险决定仍由人承担。如果考核仍奖励旧的人工动作，员工就会绕开 Agent；如果只强调使用率，又可能出现为了完成指标而制造调用量。

责任、流程、系统集成和价值核算四个结构性断层

四、ToB 企业外部赋能的八项关键设计与交付难题

1. 产品标准化与客户定制持续冲突

ToB 客户会要求自己的 Prompt、知识结构、审批、模型、部署区域和 SLA。单个灯塔客户可以靠工程师深度定制交付，但如果每个客户形成代码分支，模型升级、连接器兼容和评测成本就会随客户数量增长。项目收入看似增加，产品毛利和交付速度却持续下降。

更可持续的方式是“稳定内核＋声明式租户模块”：把模型策略、Prompt/Skill、知识源、工具、评测、权限策略和 UI 通过版本化配置组装；只有监管、性能或隔离要求足够高的客户才进入专属部署单元（Deployment Stamp）。AWS 和 Azure 的 SaaS 架构都将共享、专属和混合部署视为不同权衡，而非一套架构服务所有客户。[9][10] 专属托管、专业服务和深度定制本身并非失败，关键是其价格能否覆盖交付成本、版本能否持续升级、合同终止后能否退出。

ToB 产品化的关键不是减少所有定制，而是让定制发生在可配置、可评测、可升级的边界内。无法进入产品模块的客户特例，应明确价格、支持周期和退出方式，避免永久分叉。

2. 异构系统集成让“标准连接器”变成长期工程

不同客户的 CRM、ERP、工单、IAM、字段含义和审批流程不一致。MuleSoft 2026 Connectivity Benchmark 调研 1,050 名大型组织 IT 负责人，其中 95% 表示存在系统集成挑战，50% 称数据孤岛阻碍 AI 应用。[11] 这是一项供应商研究和受访者自报数据，不代表具体故障率，但反映了外部 Agent 面临的普遍连接摩擦。

ToB 厂商需要建设统一业务数据模型、连接器 SDK、能力契约、字段映射、幂等/重试/补偿框架，并把“建立连接”和“业务动作通过验收”分开计量。内部团队可以要求某个系统改接口，外部供应商通常只能兼容客户现状，因此连接器维护、版本兼容和实施伙伴能力会成为产品的一部分。

3. 多租户隔离必须贯穿 Agent 全链路

普通 SaaS 的多租户问题已经不止数据库隔离，Agent 又增加了会话记忆、向量索引、Prompt 缓存、工具凭据、Trace、评测样本和异步任务。AWS SaaS Lens 明确区分租户隔离与一般认证授权：用户通过认证，并不自动意味着不能访问其他租户资源。[12] OWASP 多租户安全指南也指出，共享基础设施中的单点缺陷可能暴露多个租户。[13]

租户上下文必须由可信身份令牌派生，并在数据、检索、缓存、工具、消息、日志、备份和客服排障链路重复校验，不能依赖 Prompt 告诉模型“只访问某客户”。跨租户泄漏对于内部系统可能是部门级权限事件，对于 ToB 平台则可能同时触发多客户通知、监管、赔偿和品牌危机。

4. 客户私有评测无法被公共基准替代

相同回答在不同客户的政策、术语和权限下可能一对一错。ToB 产品需要三层评测体系（Evaluation System）：平台公共集验证通用能力，行业集验证领域规则，客户覆盖集（Tenant Overlay）验证客户自己的流程和边界。AWS AgentCore Evaluations 与 Google Vertex AI Evaluation 都支持自定义评测器、数据集或规则，但工具本身不会替供应商解决客户验收标准冲突和标注成本。[14][15]

每次模型、Prompt、Skill、连接器或安全策略升级，都应同时运行三层评测；客户私有样本在隔离环境执行，平台只汇总经过约定的指标。没有客户覆盖集，供应商只能证明产品“通常可用”，无法证明它在该客户规则下仍然正确。

5. SLA 从系统可用性升级为任务有效性

云服务 SLA 通常承诺 API 可用性或错误率，不承诺 Agent 最终完成业务任务。Agent 结果还依赖客户网络、身份系统、知识质量、第三方 SaaS 和模型，因此只写“99.9% 可用”无法描述真实体验。Google Vertex AI 与 Azure 的 SLA 都包含具体服务范围和排除条件，正式合同必须依据所选区域与 SKU 核定，而不应把平台可用率直接等同业务成功率。[16][17]

ToB Agent 至少需要拆分四层服务目标（SLO）：平台 API 可用性、P95 延迟、任务技术完成率、经抽检的业务正确率；对高风险动作还要增加未经授权动作、人工批准完整性和恢复时限。对客户依赖可以定义排除条件，但供应商仍应提供端到端状态、降级和证据，而不是要求客户逐个联系底层模型商和工具商。

6. 定价和单位经济模型尚未稳定

Agent 任务的 Token、工具、沙箱、检索和重试成本高度波动。按席位收费容易在重度客户上亏损，按 Token 收费又难映射客户价值。Google Vertex AI Agent Engine 按运行资源、会话或记忆及底层模型等组件计费；Salesforce 同时采用按用户、会话、积分或动作等多种方式，说明行业仍在探索合适的价值计量单位。[18][19]

供应商需要建立 tenant/run 级成本账本，外部定价可采用“平台订阅＋包含额度＋可解释超量＋高价值动作”的组合。每个租户的模型路由、预算、缓存、并发和循环步数都应可配置。真正要优化的是客户生命周期毛利，而不是单次模型调用毛利。

7. 安全、合规和合同责任跨越多方供应链

数据处理角色必须针对每一种具体活动分别识别，不能简单按“客户是控制者、供应商是处理者”一概确定。客户业务处理、平台运行日志、反滥用监控、人工支持和模型改进可能具有不同目的与决定主体；供应商若超出客户指令，自行决定训练或产品分析目的，其角色也可能改变。EDPB Guidelines 07/2020 明确 controller/processor 是功能性概念；中国《个人信息保护法》第 21 条则要求委托双方约定目的、期限、方式、数据种类、保护措施和双方义务。[20][21]

ToB 合同需要覆盖数据是否用于训练、驻留与跨境、分包商、身份委托、审计、重大模型/Skill/MCP 变更、事故分级、证据提供、赔偿、退出迁移和删除证明。每个模型商、云服务、OCR、搜索和 MCP Server 都可能进入供应链。ToB Agent 出售的不是一次模型调用，而是一条跨越客户身份、客户数据、第三方工具和外部供应商的责任链。

8. 客户成功、升级和退出都是产品能力

Agent 上线后，客户仍需确定业务 Owner、建立基线、培训员工、处理例外并定期复盘。如果供应商只交付技术而不帮助客户进入经营闭环，就容易出现“验收完成但没有持续使用”。外部供应商无法代替客户重构组织，却需要用客户成功（Customer Success）机制推动客户责任人完成价值验证。

升级同样复杂。模型、Prompt、Skill、知识解析器和连接器 API 的变化都可能改变行为，大客户还会要求冻结窗口、提前通知和固定版本。供应商需要租户分组灰度、兼容矩阵、版本支持期限和自动回滚。客户退出时，还要能够导出配置、知识清单和审计记录，删除长期记忆、索引、缓存和派生数据，并提供约定的证明。[10]

五、共同难点相似，但责任位置不同

两类 Agent 场景在价值、流程、数据、工程、成本和规模化方式上的差异

两类场景都需要评测、Trace、身份权限、安全审计和成本计量，但责任位置不同。内部 Agent 的价值 Owner 在企业内部，平台是能力提供者；ToB 场景则需要客户业务 Owner、供应商产品/客户成功团队和实施方共同负责。供应商可以承诺产品和服务，却通常不能单方面承诺客户最终经营结果。

数据边界也不同。内部场景主要处理岗位、部门和数据域权限；大型集团内部如果跨法人、地区或监管域运营，其复杂度也可能接近多租户系统。ToB 通常还需要法律实体级租户隔离、地区驻留、分包商治理和删除证明。工程上，内部可以少量深度集成，ToB 则更常面对大量异构系统和版本。经济上，内部追求业务 ROI，ToB 还要覆盖售前、实施、定制、支持、渠道和客户获取成本。

最需要避免的误区，是把责任从一方完全推给另一方。客户不能把流程和数据质量问题全部交给供应商，供应商也不能用“AI 可能出错”免除平台隔离、安全缺陷和按约处理数据的责任。事故归责应按平台缺陷、客户配置、第三方工具、模型变化和人工批准等类型预先定义，并保留足够证据。

六、企业应该如何选择建设路径

如果企业的主要目标是改善自身核心流程、数据高度敏感、差异化规则较多，并且能够组织业务与技术共同重构流程，优先建设内部 Agent 闭环更合理。企业可以采购模型、工具和平台，但应自己掌握业务 Owner、评测集、权限策略、关键知识和价值台账。

如果企业拥有可跨客户复制的行业方法、标准数据模型、连接器能力和持续交付团队，才适合把 Agent 做成 ToB 产品。一个内部成功用例并不自动构成外部产品：还需要证明租户隔离、配置化、客户私有评测、部署矩阵、SLA、合同责任、客户成功和退出能力。

对于同时做内部平台和 ToB 产品的企业，建议采取“双层架构”：底层共享模型网关、评测、Trace、身份、安全和成本计量等基础设施；上层分别建立内部经营产品和外部租户产品。两者可以复用技术组件，但不要共用未经隔离的数据、权限、运营指标和发布节奏。

七、一种常见但非唯一的路径：从内部闭环走向 ToB 规模化

从内部可用、内部规模化、标杆客户共创到 ToB 规模复制的四阶段路线

这条路径适合已经拥有内部平台或内部灯塔场景、计划将能力产品化的企业，并不是所有 ToB 厂商的必经顺序。纯 ToB 厂商可以直接从设计伙伴或标杆客户共创开始，但必须独立完成客户价值、跨客户复制和单位经济验证，不能把客户项目验收等同于产品成熟。

第一阶段验证内部可用：选择一个价值明确、风险可控的流程，建立业务基线、唯一 Owner、可信完成率和人工接管机制。第二阶段验证内部规模化：形成 Agent资产目录（Agent Registry）、权限与 Trace、成本台账、回归门禁和跨流程运营制度。

第三阶段不是立即大规模销售，而是与少量标杆客户共创，验证跨企业适配。此时重点不只是功能，而是租户隔离、配置化、客户评测、合同边界和 SLA 试运行。任何需要修改产品内核的客户特例，都要判断它是行业共性、付费扩展还是应被拒绝的永久分叉。

第四阶段才验证 ToB 规模复制：产品内核稳定，伙伴能够交付，版本可灰度升级，客户价值可以复盘，续约和毛利能够覆盖完整生命周期成本。如果价值主张来自内部灯塔案例，应先证明其经营闭环；无论采用哪条路线，没有证明跨客户复制和交付毛利，就不把项目制收入当成产品成功。

每道阶段门都需要三类责任人和四类证据。责任人包括业务 Owner、评测 Owner 和风险 Owner；证据包括业务基线、端到端审计记录、失败回滚演练和成本账本。进入标杆客户阶段后，再增加客户覆盖集、集成工时、90 天采用和租户级毛利。具体阈值由任务风险与商业模型决定，但必须在进入下一阶段前书面确定，而不是上线后再解释。

八、两类场景分别应该看什么指标

内部 Agent 的一级指标应是流程结果：端到端周期、一次通过率、人工转交率、异常损失、业务容量和实际损益。二级指标才是任务成功率、活跃使用、Token、延迟和人工复核。若 Agent 使用增长却没有改善一级指标，应优先检查流程和责任，而不是继续增加功能。

ToB Agent 的一级指标应覆盖客户价值和商业健康：客户达到首个价值的时间、90 天采用、任务可信完成率、续约率、扩容率、租户级毛利和交付工时。平台可用率、连接器数量和调用量是必要运行指标，但不能代替客户是否续约和供应商是否可盈利。

两类场景都建议采用“可信完成”口径：可信完成率＝同时满足“结果正确、权限合规、过程可审计、成本在预算内、失败可恢复”的任务数 ÷ 总任务数。任一条件不满足，该任务就不计为可信完成。这比简单统计响应成功或调用次数更接近真实价值。

九、结论

企业内部 Agent 和 ToB 外部赋能并不是同一条路线的早期与晚期，而是两种不同的经营系统。内部落地解决的是组织能否让 Agent 获得正确目标、数据、权限和责任，并兑现到流程与损益；ToB 外部赋能解决的是供应商能否将不确定的智能能力封装为跨客户可复制、可承诺、可持续交付的产品。

内部 Agent 的终点是经营闭环，ToB Agent 的终点是可复制的客户价值。两者可以共享技术底座，却必须分别设计责任、指标、治理和经济模型。只有理解这条边界，企业才不会把内部试点误判为产品能力，也不会把外部销售额误判为已经完成规模化。

欢迎关注微信公众号 LLM&Agent技术分享

企业 Agent 落地的两场战争：内部经营闭环与 ToB 外部规模赋能

参考资料

[1] KPMG, Global AI Pulse Q2 2026, 2026-06：https://kpmg.com/xx/en/media/press-releases/2026/06/growing-adoption-signals-progress-as-cost-visibility-and-accountability-drive-ai-value.html

[2] Deloitte, The path to agentic transformation, 2026-08-12：https://www.deloitte.com/us/en/insights/industry/technology/path-to-agentic-transformation.html

[3] IBM Institute for Business Value, Redesign for enterprise AI, 2026：https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-process-redesign

[4] Towards a Science of AI Agent Reliability, arXiv v3, 2026-09-07：https://arxiv.org/abs/2602.16666

[5] Deloitte, Agentic AI is scaling faster than guardrails, 2026-04-24：https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html

[6] KPMG US, AI Quarterly Pulse Q2 2026：https://kpmg.com/us/en/media/news/q2-ai-pulse-2026.html

[7] KPMG, Global AI Pulse Q3 2026：https://kpmg.com/xx/en/our-insights/ai-and-technology/ai-pulse.html

[8] Microsoft, 2026 Work Trend Index, 2026-05-05：https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization

[9] AWS Well-Architected SaaS Lens, Silo, pool, and bridge models：https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-pool-and-bridge-models.html

[10] Microsoft Azure Architecture Center, Deployment Stamp Pattern：https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp

[11] MuleSoft, Connectivity Benchmark Report 2026：https://www.mulesoft.com/lp/reports/connectivity-benchmark

[12] AWS Well-Architected SaaS Lens, Tenant isolation：https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/tenant-isolation.html

[13] OWASP, Multi-Tenant Security Cheat Sheet：https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html

[14] AWS Bedrock AgentCore Evaluations：https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html

[15] Google Cloud, Gen AI evaluation overview：https://cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview

[16] Google Cloud, Vertex AI SLA：https://cloud.google.com/vertex-ai/sla

[17] Microsoft Azure, Service Level Agreements：https://azure.microsoft.com/en-us/support/legal/sla/

[18] Google Cloud, Vertex AI Agent Engine pricing：https://cloud.google.com/vertex-ai/generative-ai/pricing#vertex-ai-agent-engine

[19] Salesforce, Agentforce Pricing：https://www.salesforce.com/agentforce/pricing/

[20] EDPB, Guidelines 07/2020 on controller and processor concepts：https://www.edpb.europa.eu/documents/guideline/guidelines-072020-on-the-concepts-of-controller-and-processor-in-the-gdpr_en

[21] 中国网信网，《中华人民共和国个人信息保护法》，2021-08-20：https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm