本文章中的“企业内部 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 则更常面对大量异构系统和版本。经济上内部追求业务 ROIToB 还要覆盖售前、实施、定制、支持、渠道和客户获取成本。最需要避免的误区是把责任从一方完全推给另一方。客户不能把流程和数据质量问题全部交给供应商供应商也不能用“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 的终点是可复制的客户价值。两者可以共享技术底座却必须分别设计责任、指标、治理和经济模型。只有理解这条边界企业才不会把内部试点误判为产品能力也不会把外部销售额误判为已经完成规模化。欢迎关注微信公众号 LLMAgent技术分享企业 Agent 落地的两场战争内部经营闭环与 ToB 外部规模赋能参考资料[1] KPMG, Global AI Pulse Q2 2026, 2026-06https://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-12https://www.deloitte.com/us/en/insights/industry/technology/path-to-agentic-transformation.html[3] IBM Institute for Business Value, Redesign for enterprise AI, 2026https://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-07https://arxiv.org/abs/2602.16666[5] Deloitte, Agentic AI is scaling faster than guardrails, 2026-04-24https://www.deloitte.com/us/en/insights/topics/emerging-technologies/ai-agents-scaling-faster.html[6] KPMG US, AI Quarterly Pulse Q2 2026https://kpmg.com/us/en/media/news/q2-ai-pulse-2026.html[7] KPMG, Global AI Pulse Q3 2026https://kpmg.com/xx/en/our-insights/ai-and-technology/ai-pulse.html[8] Microsoft, 2026 Work Trend Index, 2026-05-05https://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 modelshttps://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-pool-and-bridge-models.html[10] Microsoft Azure Architecture Center, Deployment Stamp Patternhttps://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp[11] MuleSoft, Connectivity Benchmark Report 2026https://www.mulesoft.com/lp/reports/connectivity-benchmark[12] AWS Well-Architected SaaS Lens, Tenant isolationhttps://docs.aws.amazon.com/wellarchitected/latest/saas-lens/tenant-isolation.html[13] OWASP, Multi-Tenant Security Cheat Sheethttps://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html[14] AWS Bedrock AgentCore Evaluationshttps://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html[15] Google Cloud, Gen AI evaluation overviewhttps://cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview[16] Google Cloud, Vertex AI SLAhttps://cloud.google.com/vertex-ai/sla[17] Microsoft Azure, Service Level Agreementshttps://azure.microsoft.com/en-us/support/legal/sla/[18] Google Cloud, Vertex AI Agent Engine pricinghttps://cloud.google.com/vertex-ai/generative-ai/pricing#vertex-ai-agent-engine[19] Salesforce, Agentforce Pricinghttps://www.salesforce.com/agentforce/pricing/[20] EDPB, Guidelines 07/2020 on controller and processor conceptshttps://www.edpb.europa.eu/documents/guideline/guidelines-072020-on-the-concepts-of-controller-and-processor-in-the-gdpr_en[21] 中国网信网《中华人民共和国个人信息保护法》2021-08-20https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm