如何衡量智能体创造的真实价值：评《北京市关于加快智能体引领发展的若干措施》之四
原创 洪延青 2026-08-07 14:30 福建
从Token规模走向有效任务
编者按
关于智能体，本公号发表过以下文章：
《北京市关于加快智能体引领发展的若干措施》第六条提出鼓励发展“Token经济”，培育Token即服务、智能体即服务、结果即服务等商业模式，探索制定Token服务质量评估和计费规范，推动从Token消耗量计费转向价值计费。第八条进一步提出支持建设“Token工厂”，探索发放Token券和智能体服务券。第三条要求建设标杆场景，推动前沿部署工程师驻场共创；第五条提出发展以OPC为代表的新型创业模式；第十条则明确对技术攻关、共性平台和示范应用给予支持。
把这些安排放在一起看，北京对人工智能产业的政策视野已经发生了一个值得注意的延伸：从模型训练走向规模化推理，从软件销售走向智能体服务，从技术供给走向任务交付和结果计费。这种延伸具有较强的前瞻性。它说明，政策开始面对智能体进入真实生产以后产生的新问题，而不再只关注模型本身。
但政策视野向后延伸，并不意味着价值尺度已经自然形成。恰恰相反，它把一个更基础的问题推到了前面：
⚡ 核心问题
究竟应当用什么衡量智能体创造的真实价值？
Token最容易统计，模型调用次数、智能体数量、平台注册量和理论算力规模，也都很容易形成直观数字。问题在于，计量方便不等于评价准确。一个系统消耗了大量Token，不等于它完成了大量有效任务；完成了一批任务，也不等于企业流程因此得到改善；局部流程效率有所提高，更不必然形成持续收入、新产品或者公共价值。
这里需要先划清一道边界。Token可以计量投入，调用可以描述运行过程，任务完成属于直接产出，流程改善才是业务结果，持续经营和公共服务提升则是更长周期的价值。几个层次彼此联系，但不能相互替代。北京发展智能体经济，需要建立的正是这样一条从资源投入通向实际价值的证据链。
一、Token可以计量投入，但不能直接成为价值尺度
Token是模型处理信息的基本技术计量单位。智能体需要处理更长的上下文、维持更长的任务链路，还会频繁调用外部工具，Token消耗因而成为智能服务成本结构中的重要变量。
《若干措施》第六条提出通过异构协同、存算协同、智能调度、推理缓存复用和任务路由等方式提高Token效率，方向是准确的。推理成本下降，同样的算力可以支持更多任务，中小企业和个人创业者使用智能体的门槛也会随之降低。从这个意义上说，Token效率当然构成智能体产业竞争力的一部分。
但这仍然只能说明投入效率，不能直接说明价值。
同一项任务，在不同模型中可能对应不同的分词结果。模型参数规模、推理机制和基础设施不同，每个Token背后的实际计算成本也不一样。把不同模型、不同任务产生的Token简单相加，很难得到一个稳定、可比较的产业价值指标。
智能体完成任务的真实成本也远不止Token。搜索、数据库、地图、支付和专业软件等外部工具调用，向量检索和长期记忆的存储，网络与终端执行，人工复核和异常处置，以及失败、重试和返工造成的额外损失，都可能进入一项任务的完整成本。只计算Token，会把其中相当一部分成本留在统计之外。
更重要的是，Token消耗与任务价值之间没有固定比例。同样完成一项合同审查，低效系统可能反复读取材料，调用多个智能体相互讨论，再多次修改结论；成熟一些的系统则可能依靠结构化检索、明确规则和合理缓存，以更少Token形成相同甚至更好的结果。前者消耗了更多智能资源，却不能因此被认定为创造了更多价值。
这一区分还会影响政策激励。如果把Token调用规模直接作为产业规模或者项目绩效，上下文越冗长、系统循环越多、失败后的重试越频繁，统计出来的“Token经济”反而越繁荣。这不是政策本意，却可能成为真实的执行结果。
所以，更准确的关系应当是：
Token衡量的是智能生产资料的消耗，而不是智能产品的价值。
Token可以用于成本核算、基础设施规划和系统效率比较，但不能直接说明智能体完成了什么任务，更不能直接折算为企业收入、流程改善和社会效益。北京所称“Token经济”，更适合被理解为一种以规模化推理和智能任务执行为基础的新型服务经济，不宜理解为Token数量本身构成了新的价值形态。
发展Token经济，真正要提高的，是每一单位推理资源转化为有效任务和业务结果的能力。
二、从Token到真实价值，中间有五层证据
从《若干措施》的整体结构看，第一、二条支持模型和驾驭层技术，第三、四条推动场景和终端应用，第五、六条讨论组织和商业模式，第八、九条提供要素和生态支持，第十条配置财政和项目工具。文件实际上已经隐含了一条从技术投入通向产业价值的链条。现在还需要回答的是，这条链条中的每一层究竟能够证明什么。
处在最前端的是资源投入。算力、Token、模型调用、存储、网络、外部工具、数据处理、开发部署和人工审核，都属于这一层。它回答的是：为了建设和运行智能体，投入了多少资源。
投入之后，首先要形成的是系统能力。响应速度、连续运行稳定性、工具调用成功率、任务中断后的恢复能力、跨模型和跨芯片迁移能力，以及权限控制、异常中止和回滚能力，反映的是系统能否稳定、可控地工作。
系统能够运行，还不等于任务已经完成。第三层因而是有效任务结果：任务完成率、一次成功率、符合质量要求的比例、人工接管率、失败和重试次数，以及错误操作和权限越界情况。到这一层，评价才开始回答智能体是否真正完成了被委托的任务。
任务完成以后，还要继续观察流程结果。完整业务周期是否缩短，人工交接是否减少，错误率和投诉率是否下降，客户等待时间是否缩短，库存周转是否改善，研发和产品上市周期是否压缩，这些变化才说明智能体有没有让企业流程整体变得更好。单个任务的成功，不能替代对完整流程的观察。
最后才是企业和社会价值。是否形成新的产品和收入，客户是否持续付费和续约，企业经营成本和现金流是否改善，公共服务质量是否提高，项目能否形成可复制、可持续的运营模式，都属于这一层。它回答的是，流程变化能否进一步转化为较长周期的经济和社会价值。
五个层次之间存在因果联系，但这种联系需要证据，不能靠指标名称完成跳跃。产生一定规模的Token，只能证明形成了相应的推理负载，不能证明完成了一定数量的有效任务。任务数量增加，也不能自动证明企业整体流程得到改善。即使流程处理时间缩短，也不等于企业利润一定增加，因为需求、价格、组织调整和其他因素可能同时发挥作用。
归因问题尤其不能忽略。智能体项目往往与流程标准化、数据治理和管理调整同时进行。业务结果发生变化时，需要区分其中有多少来自模型能力，有多少来自流程重构，又有多少来自组织管理方式的改变。标杆场景应当尽可能建立上线前后的业务基线，记录智能体具体介入了哪个环节，并通过持续运行判断变化是否稳定。对于重要项目，还可以采用分阶段试点、相似业务单元比较等方式，尽可能形成合理参照。
在任务层面，可以进一步引入“单位有效任务成本”：
单位有效任务成本 =（模型与工具成本＋人工复核成本＋失败和重试成本＋预期风险损失）÷ 符合质量要求并完成闭环的任务数量。
这里最重要的是“有效”二字。任务表面上已经完成，结果却需要大量人工返工；或者系统以扩大数据访问、跳过必要审批、增加错误风险为代价降低成本，都不能被认定为有效完成。否则，所谓效率只是把一部分成本和风险移出了统计范围。
因此，智能体价值评价需要坚持一个基本原则：
⚡ 评价原则
逐层记录，逐层证明，不以投入替代产出，也不以局部效果替代最终价值。
三、从Token计费转向结果计费，仍要校正质量和风险
《若干措施》第六条提出Token即服务、智能体即服务和结果即服务。这三种服务模式的差别，并不只在于计费名称不同，它们交付的对象不同，供应商承担的责任也随之变化。
Token即服务主要交付推理资源，供应商通常对资源可用性、响应速度和基础服务质量负责。智能体即服务交付的是能够完成特定任务的系统，供应商需要进一步对工具接入、任务编排和运行稳定性承担责任。结果即服务继续向后延伸，把交易单位从技术资源转向可验证的任务结果，服务商相应承担更直接的质量和交付责任。
从Token消耗量计费转向价值计费，方向是正确的。它可以推动服务商从出售调用量走向交付任务结果，也会迫使系统持续优化推理成本、工具调用和人工复核。但问题没有到此结束，因为“结果”本身并不是天然清楚的。
客服智能体如果按照处理咨询的数量付费，服务商可能倾向于尽快结束对话，结果却是再次来电和投诉增加。采购智能体如果只按降价幅度评价，质量、交付和供应链韧性就可能被忽略。政务智能体如果只看处理速度，也可能损害程序、公平和审慎判断。这些场景说明，结果指标设置得过窄，智能体就会围绕指标优化，而不再围绕真实目标优化。
还有一种更隐蔽的偏差。服务商可能优先承接容易完成的任务，把复杂客户和高风险事项转交人工，于是智能体的任务成功率很高，人工团队承担的剩余工作却更难、更重。评价时不能只记录智能体完成了多少任务，还要记录它拒绝、转交和失败了哪些任务，以及人工团队实际承担了多少剩余工作。
所以，结果需要经过质量、风险和长期效果校正。客服除了处理量，还要看一次解决率、再次来电率和投诉；生产调度除了产量，还要看质量、能耗和设备损耗；销售智能体除了线索数量，还要看真实成交、客户留存和退款；政务服务除了速度，还要看程序合法、错误纠正和当事人救济。
第七条提出的安全治理，也应当直接进入价值计算。一个系统降低了表面成本，却增加个人信息泄露、错误付款或者未经授权的数据外发，不能认定其创造了更高价值。能够计入智能体产出的，只能是经过质量和风险校正的价值。
这也意味着，结果即服务并非简单更换一个价格单位，而是在重新界定任务、质量、风险、证据和责任。对于任务边界尚不稳定、结果难以完全归因于供应商的项目，不宜立即实行纯结果付费。更稳妥的安排，是把基础服务费、资源使用费和结果绩效费组合起来，并随着任务边界逐渐清楚、结果标准逐渐稳定，再提高结果付费的比例。
四、不同政策对象，需要不同层次的评价尺度
《若干措施》涵盖模型、驾驭层、场景、终端、创业、Token、算力、开源和出海等不同政策对象。这些对象处在价值形成链条的不同位置，如果采用同一组指标评价，结果往往不是失之过早，就是停留在过于初级的层次。
第一、二条支持基础模型、驾驭层和中间软件栈，评价重点应当放在系统能力和资源效率，包括长程任务成功率、工具调用稳定性、中断恢复、跨模型迁移和单位有效任务成本。参数规模、最大上下文长度和理论Token吞吐量仍然可以统计，但只能说明部分技术能力，不能替代真实任务检验。
第三、四条支持标杆场景、前沿部署工程师（FDE）驻场共创和智能终端，评价重心需要继续向任务和流程移动。项目应当说明原有业务基线，证明智能体能够在真实生产环境中持续运行，并记录任务完成率、人工复核、错误率和完整业务周期发生了什么变化。智能终端也要区分产品销售、功能激活和持续有效使用，不能把“搭载智能体功能”直接等同于已经创造价值。
第五、六条支持OPC、智能体即服务和结果即服务，评价需要进一步进入经营层面。有没有真实客户，能否形成持续收入，客户是否续约，合规记录是否稳定，经营者短期无法履职时业务能否继续，这些都比注册数量和调用规模更能说明新组织、新服务是否真正成立。
第八条支持Token工厂、公共算力和服务券，主要应当看有效负载，而不是名义规模。设备建成、理论算力形成和Token产出增长，只能证明基础设施供给增加。真正具有产业意义的，是有多少容量能够稳定调度，有多少承载真实生产任务，又有多少由非补贴客户持续付费使用。
第九条支持开源和出海，评价也需要从传播数量走向持续采用。开源项目不能只看代码量、下载量和注册开发者数，还要观察维护是否持续，是否被真实产品采用，有没有降低企业集成和迁移成本。智能体出海则要进一步观察境外客户是否持续使用和续约，是否形成稳定服务收入，以及产品能否长期满足当地的数据、安全和行业要求。
第三篇讨论的流程成熟度【智能体如何逐级重塑企业流程——评《北京市关于加快智能体引领发展的若干措施》之三】，同样可以与这条评价链对应起来：工具辅助主要看个人任务效率，环节嵌入看单个流程节点，有界闭环看完整任务结果，端到端编排看整体流程效果，原生重构则进一步评价组织、产品和商业模式是否形成持续变化。
成熟度不同，证据要求也应当不同。用企业收入评价尚处在技术原型阶段的项目，要求过早；用模型调用量评价已经进入生产运行的成熟项目，又明显不够。评价尺度必须随着项目成熟度向后移动。
五、财政资金应当随着价值证据进入，也随着证据不足退出
《若干措施》第十条提出统筹财政资金、政府投资基金和市场化基金，实施重点项目，并对技术攻关、共性平台和示范应用给予支持。要提高这些资金的使用效率，关键不是要求所有项目一开始就证明最终商业价值，而是设置与项目阶段相匹配的价值证据门。
技术原型阶段主要证明基本能力能否实现。早期技术探索具有不确定性，应当允许失败，不能在这一阶段就要求项目提交成熟的商业结果。
进入生产中试以后，评价尺度要随之变化。项目应当在真实业务中证明能够稳定完成任务，记录人工接管、错误、重试和安全事件，并与原有流程基线进行比较。只在演示环境中取得良好效果，还不足以进入大规模推广。
到了示范推广阶段，项目需要证明其不只在一个特殊团队或者特定环境中有效，还能够在第二个部门、工厂、机构或者相近场景中复制，而且复制成本可以接受。
进入市场化阶段，则要进一步证明客户愿意持续付费，补贴逐步减少以后项目仍能运行，服务商也具备持续维护、迁移和事故处置能力。
这几个阶段需要的证据不同，但有一条要求是一致的：项目每进入一个新阶段，都应当提供新的证据，不能反复使用早期技术指标解释后期生产和经营问题。长期无法进入真实生产环境、始终依赖驻场团队、没有稳定使用主体，或者补贴停止后即停止运行的项目，应当及时退出。
退出不是对技术创新失败的惩罚，而是高风险创新政策维持资源配置效率所必需的正常机制。允许失败，也应当允许资金停止继续支持已经不能提供新证据的项目。
Token券和智能体服务券也需要体现这种阶段差异。企业首次尝试智能体时，可以按一定额度补贴推理和服务成本，降低采用门槛；进入生产运行后，补贴应当逐步与企业自有投入、真实任务、质量结果和稳定运行挂钩；到了成熟商业阶段，财政支持则应逐步退出，避免长期替代真实市场需求。
政府部门和国有企业的首购首用，也应从采购抽象的“智能体平台”和Token额度，逐步转向采购明确的任务能力。采购文件需要说明要解决的业务问题、原有流程基线、质量边界和验收证据。对于尚不适合纯结果付费的项目，可以采用基础服务费加任务质量绩效费，但不能只以系统上线或者模型接入作为完成标准。
六、最终需要证明的，是智能体成为生产力
北京提出Token经济，反映了人工智能产业正在从集中训练走向规模化推理，从模型能力走向智能体服务。这一政策判断具有现实基础。
但北京真正需要建立的，不能只有一套Token统计体系。更重要的是形成一套贯通资源投入、系统能力、有效任务、流程结果和最终价值的评价体系。
Token能够说明使用了多少智能资源，调用能够说明系统运行了多少次。只有经过质量和风险校正的有效任务，才能说明形成了直接产出；只有任务进一步改善企业流程、形成持续收入或者提高公共服务质量，才能证明智能体真正成为生产力。
不同政策措施应当适用不同层次的指标，不同成熟度的项目也应当提供不同层次的价值证据。财政支持随着证据逐步进入，并在证据长期不足时及时退出，正是这套评价体系转化为政策执行机制的关键。
北京发展智能体经济，当然需要关注规模。但有意义的规模，不是孤立地产生了多少Token、接入了多少模型或者建设了多少平台，而是有多少推理资源转化为稳定服务，有多少调用转化为有效任务，有多少任务转化为流程改善，又有多少流程改善最终形成持续的企业价值和公共价值。
北京需要关注Token，但不能止于Token。Token可以计量投入，调用可以描述过程；只有在受控条件下可靠完成的任务，以及由此带来的流程改善和持续价值，才能证明智能体真正成为了生产力。
END
文章索引
数据保护官（DPO）社群主要成员是个人信息保护和数据安全一线工作者。他们主要来自于国内头部的互联网公司、安全公司、律所、会计师事务所、高校、研究机构等。在从事本职工作的同时，DPO社群成员还放眼全球思考数据安全和隐私保护的最新动态、进展、趋势。2018年5月，DPO社群举行了第一次线下沙龙。沙龙每月一期，集中讨论不同的议题。目前DPO社群已超过400人。关于DPO社群和沙龙更多的情况如下：
DPO线下沙龙的实录见：
域外数据安全和个人信息保护领域的权威文件，DPO社群的全文翻译：
传染病疫情防控与个人信息保护系列文章
关于数据与竞争政策的翻译和分析：
健康医疗大数据系列文章：
网联汽车数据和自动驾驶的系列文章：
网络空间的国际法适用问题系列文章：
《网络数据安全管理条例（征求意见稿）》系列文章：
《数据安全法》的相关文章包括：
赴美上市的网络、数据安全方面的两国监管乃至冲突方：
个性化广告或行为定向广告（behavioral targeting advertising）系列的文章：
内容安全方面的文章如下：
第29条工作组/EDPB关于GDPR的指导意见的翻译：
数字贸易专题系列：
关于中国数据出境安全管理制度的文章
美国方面的个人信息保护立法的文章：
关于印度的数据保护和数据治理政策和技术文件的文章有：
关于数据的安全、个人信息保护、不正当竞争等方面的重大案例：
关于保护网络和信息系统安全的相关文章包括：
围绕着TIKTOK和WECHAT的总统令，本公号发表了以下文章：
关于我国数据跨境流动监管体制变革的系列文章：
针对审计在数据安全、个人信息保护、AI安全的作用与落地实操，本公众号发布过的文章：
关于中国的网络安全审查制度，本公号发表过的文章：
关于个人信息安全影响评估的文章如下：
围绕供应链安全，本公众号发表文章：
关于AI与标准化工作，本公号发表的文章：
关于新加坡数字化（包括个人信息、网络安全、人工智能等）方面的改革，本公号发表的文章：
关于健康医疗数据方面的文章有：
关于欧盟技术主权相关举措的翻译和分析：
美国利用法律和政策工具单边化地维护或强化美国的安全和经济利益，本公众号曾发表文章：
关于AI技术的系列读书笔记：
本公号发表过的关于数据执法跨境调取的相关文章：
地缘政治与跨国科技公司运营之间的互动影响：
关于AI“情感交互”和“拟人化互动”，本公号发布过以下文章：
关于业务场景中数据跨境流动的文章如下：
关于欧洲的人工智能监管方面的立法、政策和实践方面的文章：
关于我国对人工智能技术和应用的监管发展，本公号发布过以下文章：
关于人工智能安全和监管，本公号发布过以下文章：
本公号曾发表的人脸识别系列文章：
针对美国的人工智能监管政策发展，本公众号发表过如下文章：
关于我国《个人信息保护法》的立法、标准化和执法等内容，本公号发表的相关文章包括：
通过技术增强对个人信息的保护，例如匿名化、假名化技术，隐私增强技术，以及通过技术手段或模式强化个人信息主体的权利实现和意思表达，越来越成为值得关注的主题。本公号曾经发表的文章包括：
关于域外在数据、电信、外国投资方面所建立的国家安全相关的审查机制，本公号发布过以下文章：
本公号发表过的关于数据要素治理的文章有：
关于数据抓取和公开数据保护，本公号发布过以下文章：
关于AI能力扩散议题，本公号发表过以下报告：
关于AI风险治理和数据保护的交叉，本公号发表过的文章：