Token认知三部曲之二：亚信下一代BSS，形成统一度量衡的价值交易中心

OpenAI合作揭示专业软件企业的新竞争

2026年10月6日，OpenAI公布与合同管理软件公司Ironclad的合作，并邀请专业软件公司参与Computer Use研究。双方选取了涵盖法律、商务和采购工作的11项任务，为每项任务设置8至50条评价标准，在软件练习环境中构造合成训练任务，通过强化学习利用练习与反馈改进模型。行业经验以任务、规则、验收标准和环境的形式，进入了模型训练过程。

这件事首先说明了，通用模型正在深入专业领域。模型开始学习如何遵循业务规则并操作专业软件，并确认最终结果符合要求。专业软件积累多年的业务经验，正在成为模型能力发展的重要来源。

这对于专业软件企业的压力是不言而喻的，随着模型逐步掌握专业知识，用户可能更多地通过Agent发起工作，由模型组织软件执行。原来依托软件界面、操作熟练度和实施经验形成的竞争优势，可能会在新的能力供给模式下荡然无存。在这种情况下，包括我们在内的每家软件企业需要回答的是，客户凭什么还要继续购买我们的产品？我们自己的能力该如何形成护城河？

软件企业不能轻易的将自身的行业经验让出去，同一条学习路径，OpenAI能做，我们也可以做。OpenAI的研究展示了行业任务和反馈用于模型训练的可行方式，那我们也可以把自身经验用于可控的后训练，形成专用技能和行业执行能力。基础模型可以持续引入，任务定义、训练环境、评价方法和训练成果则应成为我们掌握的产品资产。模型能力与专业系统共同构成可交付的行业智能。

在典型的一个BSS运营支撑系统中，客户、套餐、订单、计费和结算具有明确规则，长期运行又积累了大量异常处理经验，许多任务的结果能够通过业务状态和账务记录验证。这些条件，使BSS适合将行业经验转化为可练习、可评价、可改进的智能能力。

Totogi的Agentic BSS组织方式

它山之石可以攻玉，在决定如何构建亚信的下一代BSS前，我们先看看其他厂商是怎么做的。

Totogi是一个很好的案例，研究Totogi，需要同时看它的经营系统、业务执行和产品交付。它采用了两种进入方式：以云端BSS套件服务客户，也在运营商的存量系统之上增加本体和Agent能力。两种方式面向不同的系统条件，共同追求交付速度和能力复用。

1. 经营系统提供完整的商业链条
Totogi的Wholesale BSS覆盖CRM、产品目录、报价配置、订单、Charging、Billing以及伙伴结算，并提供套餐设计与推荐等AI工具。其AWS原生、多租户SaaS架构，让多个客户共享产品底座，软件服务采用按使用量定价的方式。这里的产品选择同时涉及业务功能和交付经济性：新增一个客户，能够复用多少已有能力。

2. 存量改造依靠可执行的本体及业务模型
Totogi披露的架构包括数据层、本体层和AI层：数据层读取已有系统的结构、配置与流程；本体层表达实体、动作、约束和有效性规则；Agent据此检查拟执行的动作并协调跨系统操作。例如，套餐升级要同时检查合同条件、网络资源和账期限制，将冲突识别提前到业务提交之前。这是它把业务知识接入执行的具体机制。

3. 业务Agent围绕跨系统工作交付
Totogi在2026年9月披露，过去一年新增七个生产部署，其中包括连接通话信息、CRM与CPQ，把销售需求转为报价和订单，以及处理订单失败。这些供应商披露的案例表明，它正以具体业务问题切入存量环境，再扩展使用范围；各项效果仍需结合客户条件判断。

4. 研发Agent改变能力交付方式
AWS与Totogi联合发布的案例，将需求分析、架构设计、开发、代码检查和测试组织为多Agent流程，使用Amazon Bedrock上的Claude模型，通过工作流管理状态，并把检查和测试反馈给开发环节。业务Agent负责运行中的工作，研发Agent参与软件变更，两条路径共同影响客户的改造成本。

由此来看，Totogi的布局已经超出单一本体产品。它试图让行业知识服务于业务执行、系统集成和研发交付，再通过共享底座扩大复用。

我们应该吸收Totogi的经验，并发展自己的特色。亚信已经具备CRM、Billing、SBC、AITOP等能力基础，下一步要做的是在统一任务的基础下实现完整的衔接。本体和规则约束执行，后训练指导并评价模型完成专业任务的能力，验证体系判断两者是否有效，最终在统一度量衡上建立价值结算中心，这几者需要共同进入我们的规划。

在BSS重构中形成自己的Benchmark

BSS的AI Native重构给了亚信一个同时建设产品与行业能力的机会。

建设下一代Token Driven BSS的过程中，我们本身就需要拆解任务、梳理规则、定义验收条件和开展测试，在这个环节中，我们应该把任务规范、规则配置、执行记录和验收用例一起沉淀下来。这样一来，重构每推进一条业务流程，就增加一组可以练习和评测的任务，让不同的模型在这些任务上运行并接受验证，逐步形成的就是我们自己的BSS Benchmark。

eTOM曾经为通信行业提供了流程分类和逐层拆解的共同参照，它的基本单位是流程。但在Agent时代，我们可能会把基本单位进一步变成任务。也就是说，过去是以流程为中心组织IT系统，未来可能是以任务为中心组织智能系统。所以，eTOM曾经定义了电信软件的流程语言，AI时代，需要重新定义的是电信智能的任务语言。

我们可以在此基础上建立内部L1至L5任务体系，把业务域、流程、任务、子任务和原子动作连接起来，我们以套餐变更为例。

对亚信而言，建设任务体系可以与Agentic BSS重构同步进行，Benchmark在这个过程中逐步形成，可以按照以下的步骤组织建设：

• 第一步：梳理当前系统，建立任务地图
  以eTOM为流程参照，从客户需要完成的工作出发，识别订单办理、账单争议、伙伴对账等任务及其跨系统依赖。内部可采用L1至L5，将业务域、流程、可验收任务、子任务与原子动作关联起来；这套层级表达业务粒度，难度、风险和自主执行范围另行标记。
• 第二步：形成统一的任务规范与验收标准
  每类任务统一定义输入、环境、工具、约束、完成标准、KPI、Cost、Token和Outcome。完成标准确认交付是否合格，KPI观察质量、速度与稳定性，Cost核算完整代价，Token保留各模型的原始计量，Outcome则由实际业务数据验证。任务规范提供可重复的训练与评测标准，具体任务的范围、授权、预算、期限、验收和责任，应在受理时确认，形成任务契约。
• 第三步：建设练习与验证环境
  从可授权使用的配置、脱敏案例和合成场景中构造正常业务与异常情况，覆盖资源不足、接口超时、重复提交和账期冲突等问题。验证同时检查最终业务状态、必要的执行证据和异常处置；套餐开通要关联合同、订单、资源与服务验收，不能仅凭Agent报告完成来确认成功。确定性检查与专家验收共同提供评价依据，行业评价专模可以辅助检查专业结果。
• 第四步：开展多个模型的测试并计算Token效度
  在相同任务、质量和时限要求下，重复运行不同模型，确认合格标准结果数量R，核算约定范围内的完整总成本TCO，计算Token效度。
  失败调用、重试、工具使用、验证、人工介入和返工都应计入TCO。完成时间、稳定性及异常处置记录，用于检验交付条件和分析差异。经过专门优化的Agent方案单独评测，保留模型、工具、规则、配置及成本口径的版本。不同任务分别计算效度，评测结果应显示各方案适用的业务条件。
• 第五步：将评测结果用于生产、研发与经营
  • 模型选择： 按任务、难度和业务条件判断，哪些模型达到交付要求，哪些模型在成本或速度上更优。
  • 生产路由： 将评价结果转为实际调度策略，常规工作使用经济的合格方案，复杂情况升级模型或转交人工，并用生产反馈持续校准。
  • 研发与后训练： 从失败记录中区分模型、规则、工具和编排问题，选择值得投入的技能或训练方向，再用独立测试验证改进。
  • 成本优化： 检查缓存、重试、任务拆分和模型替换的收益，同时确认业务质量保持达标。

这套Benchmark的积累过程，就是亚信把BSS经验转化为自身智能能力的过程。 它的独特性来自业务条件、异常经验、可复现环境和验收依据的共同沉淀。

做到这一步，之前提出的度量衡就有了可运行的产品形态，Benchmark不仅是BSS的测试集，更是BSS领域内关键任务的Token效度记录表，持续记录不同模型及Agent方案在相同交付条件下的合格产出、完整成本与效度表现。这些记录直接为模型选择、生产路由、后训练和成本优化提供依据，成为亚信持续积累、直接服务研发与经营的行业资产。

以Token效度支撑Token交易与清结算

度量衡建立之后，智能服务的经营仍需要解决一个问题：模型供应商按Token或算力提供资源，Agent和工具共同完成任务，客户则按照合同购买服务。各方的计量方式、收费方式和交付责任不同，需要有人将它们对应起来。

下一代BSS应当承担这一职责，把模型侧的资源账、业务侧的交付记录和客户侧的合同账连接起来。Benchmark帮助选择交付方案，生产记录证明实际完成情况，合同规则决定收费与分账。Token效度用于方案比较与成本管理，客户收费依据合同约定的计量单位和价格规则。BSS将几者关联，才能同时支持投入产出核验和商业结算。

亚信已有的Billing支持计费、账务与多方结算，SBC支持多量纲场景计费，AITOP布局Token运营、模型路由与多方对账。 在这些基础上，可以把“任务计量与智能服务清结算”作为一个明确的产品模块，形成四项相互衔接的能力。

• 服务目录与订购：明确客户购买什么
  将可交付任务定义为服务，约定适用范围、验收标准、时限、价格和责任。客户目标经过确认，成为交付方接受的服务承诺；每次受理再明确具体对象、授权和预算，形成任务契约并关联订单。Benchmark为供给方案提供比较依据，实际承诺由服务经营者确定。
• 履约证据与任务计量：关联消耗与交付
  为任务建立统一标识，关联订单、合同、参与方、资源用量和执行记录。执行结果需要与权威业务状态核对，再按约定验收。例如，套餐变更需要确认套餐生效、资费正确及相关账户状态符合要求。BSS接收经过核验的交付记录，使消耗、结果与责任能够追溯。
• 经营核算与任务计费：分别计算投入效率与商业费用
  供给侧保留各模型的原始Token、算力和工具用量，客户侧按合同采用订阅、使用量、合格标准结果或组合计价。采用按标准结果收费时，以约定的验收结果为计费依据。同等标准结果适用相同约定单价时，不同Token消耗可以对应相同客户费用，底层模型调用仍按供应商实际规则核算。由同一任务关联客户收入与完整交付成本，经营者才能看清服务毛利。
• 多方清结算与争议处理：按商业关系确认各方应收应付
  根据各方合同与履约记录确认应收应付，完成费用归集、清分、对账和结算。模型与工具采购费用、伙伴收入分成分别核算；任务重开、交付补救和费用调整，也需要保留对应依据。参与一次任务的各方承担何种责任、取得何种收入，由商业约定确定。

我们应优先打造Token Driven BSS与持续运营服务。运营商确定面向客户的服务承诺，亚信提供任务受理、计量、账务与清结算产品及运营支持，各方按合同承担相应责任。通过复用任务规范、规则和验证资产，降低新增客户与新场景的交付成本，成熟能力再向企业智能服务经营扩展。

通用模型可以学习行业，拥有行业经验，不等于拥有智能时代的壁垒。经验必须转化为可学习的能力、可验收的交付和可持续的收入，亚信的下一代BSS要完成这项转化。专业软件企业的产业位置，需要靠新产品和经营结果重新争取。