导读一个企业客户尽调（KYB）Agent 连续调用多个企查查 MCP 数据工具，已发起的调用都正常完成；风险扫描显示目标企业最近三年存在司法风险，但 Agent 没有继续下钻明细，便生成并提交了报告。这次任务算成功吗？应该按模型 Token、工具调用次数、数据能力消耗，还是最终报告收费？当 Agent 开始自主规划、调用工具并交付结果，席位已经无法解释一次任务的真实成本。企业需要同时看清模型计算、数据与工具能力、业务任务结果三本账，并用任务、状态、预算和 Trace 把它们关联起来。
1. 三个产品变化，为什么最终都落到“三本账”
2. ⼀次 Agent 任务，⾄少包含四类事件
3.从“调用成功”到“可审计”：状态与计量必须分开
4. 预算如何真正管住 Agent
5. Trace 如何⽀撑调⽤归因与费⽤审计
6. ⼀份企业客户尽调报告如何汇总多次调用
7. 为什么结果计价仍然困难
分享嘉宾｜杜⻁ 企查查科技股份有限公司 技术总监
出品社区｜DataFun
01
三个产品变化，为什么最终都落到“三本账”
近期，企业办公 Agent 市场连续出现产品整合信号。
据财新报道，阿里此前以 QoderWork 为基础整合悟空和 MuleRun；目前，千问办公已作为一站式 AI 办公平台上线，并深度接入钉钉生态。
豆包企业版:正以 Agent 形态进入飞书知识、文档、群聊、会议和团队工作流。
WorkBuddy Enterprise：则以统一平台承载智能编码、AI 办公和智能体托管，并进一步融合腾讯文档、网盘和企业知识能力。
三条路径并不相同，却指向同一个变化：竞争焦点已经不只是“谁拥有一个更聪明的 AI 助手”，而是谁能成为 Agent 进入企业知识、数据、工具和流程的统一入口。
入口统一之后，下一个必须回答的问题就是：一次 Agent 任务究竟消耗了什么，又应该怎样计量？
席位订阅不会消失。企业仍然需要用账号和席位管理身份、权限、协作空间、基础功能与服务等级。但 Agent 进入工作流后，“一个员工、一个账号、一份价值”的关系开始松动：一个 Agent 可以服务多名员工，一名员工也可以调度多个 Agent；即使没有人持续点击界面，模型推理、数据获取和工具执行仍在产生消耗。
德勤在《SaaS meets AI agents》中指出，传统订阅和席位许可可能逐步与按用量、Agent 或结果计价融合。其援引 Gartner 的预测认为，到 2030 年，至少 40% 的企业 SaaS 支出可能转向按用量、Agent 或结果计价。这是趋势判断，不是已经发生的事实；更现实的路径，是进入“基础订阅 + 用量 + 任务 + 可验证结果”长期并存的混合计价阶段。
但计价方式可以组合，底层账本不能混在一起。
第一本账是模型计算账。记录模型、版本、输入与输出 Token、推理时延，回答"AI 思考和生成消耗了多少”。
第二本账是数据与工具能力账。记录 Agent 调用了哪些 MCP Server、哪些 Tool、获得了什么专业数据能力，回答“任务使用了什么外部能力”。
第三本账是任务与结果价值账。记录任务是否完成、交付了什么产物、是否达到验收标准，回答“最终完成了什么”。
模型 Token 回答不了企业股权穿透的价值，工具调用成功也证明不了尽调报告已经完整。三本账必须分别记录，再在任务层关联。
这也是企查查 MCP 面对的真实工程问题。企查查智能体数据平台向 Agent 提供企业数据、法律数据和智能文档解析能力。当 Agent 可以自主调用近两百项数据工具时，产品不仅要解决“数据能不能调用”，还要回答每一次调用是否必要、是否有效、如何计量、能否追溯。下文将结合企查查 MCP 的实践，拆解这套任务账本和成本治理链路。
02
一次 Agent 任务，至少包含四类事件
传统 SaaS 常把一次页面请求作为基本记录单元；Agent 工作流则更适合把“任务”作为上层容器，再记录任务内部连续发生的事件。
模型事件发生在规划、路由和生成阶段。它需要记录模型版本、输入输出 Token、耗时和终止原因。一次任务可能有多次模型调用，例如先制定计划，再判断数据是否足够，最后组织报告。
工具事件发生在 Agent 调用 MCP Tool 时。它需要记录 Server、Tool、版本、参数摘要、调用状态、重试和耗时。一次工具调用可能拿到数据，也可能只得到候选主体、空结果或需要补充输入的信号。
数据事件描述 Agent 实际获得了什么专业数据能力。它需要关联查询主体、数据维度、数据时点、计量规则及结算结果。数据事件与工具事件相关，但不是同一个概念：同一个 Tool 可能分页取数，也可能因为主体合并、缓存或重复调用保护而采用不同计量结果。
任务事件描述业务目标的生命周期，例如任务创建、等待补充、执行中、报告生成、验收通过或终止。任务事件不只关心某一个工具是否正常完成，而关心“必查项是否覆盖、报告是否形成、未决问题是否披露”。
因此，一次 Agent 任务并不是一条调用日志，而是由四条事件流共同组成：
模型事件解释计算，工具事件解释执行，数据事件解释专业能力消耗，任务事件解释业务交付。
图 1 · 一个 task_id 如何关联模型、工具、数据与任务事件
03
从“调用成功”到“可审计”：状态与计量必须分开
Agent 系统最容易出现的一类统计误差，是把“工具调用正常完成”直接计入“任务成功”。在企业数据场景中，至少要区分三个层次。
第一层：调用成功
MCP 请求正常完成，协议响应和 Schema 校验通过，服务端没有发生网络或系统错误。这一层回答的是“技术执行是否完成”。
第二层：结果可用
返回数据与目标主体一致，关键字段和数据时点满足当前步骤需要，空结果、候选主体和历史记录没有被误解。这一层回答的是“本次返回能否支撑后续判断”。
例如，工具成功返回了三个重名企业候选项，属于调用成功；但在用户确认唯一主体之前，结果还不能用于风险结论。再如，风险工具返回“当前未发现公开记录”，可以作为带时点和数据源边界的结果使用，却不能被改写成“该企业绝对不存在风险”。
第三层：业务任务完成
所有必需步骤已经执行，报告或其他产物已经生成，证据、数据时点、缺失和冲突得到披露，并达到约定的验收标准。这一层回答的是“业务目标是否完成”。
这个区分在 MCP 2026-07-28 中更值得注意。新版 Tasks 扩展给长任务提供了 working、input_required、completed、failed 和 cancelled 等技术状态，但 completed 表示请求生命周期到达终态，不天然等于业务结果合格。业务系统仍需要独立定义“结果可用”和“验收通过”。
图 2 · 调用成功、结果可用、业务任务完成是三层不同判断
把三种成功区分清楚还不够，还需要把每次调用的身份、任务、链路、能力、计量和结果记录下来。如果账单只能显示“某用户调用某工具一次”，技术团队很难排查重复调用，采购方也无法判断消耗是否合理。
一条可审计的计量事件，至少要回答六类问题。
谁发起。租户、用户、Agent、客户端和授权凭据是谁。
属于什么任务。关联哪个任务、哪一轮请求，以及哪个幂等键。
走过哪条链路。对应哪个 Trace、Span 和父级操作。
使用什么能力。调用哪个 Server、Tool 和版本，查询什么类型的主体或数据。
如何计量。采用模型 Token、数据积分还是任务单位，预占多少、最终结算多少、是否命中重复调用保护。
结果如何。调用、结果和任务分别处于什么状态，耗时多少，使用哪一版计量策略。
task_id 聚合业务任务，request_id 支撑幂等与结算，trace_id / span_id 连接调用链；计量结果与三层状态分别记录，再在任务层完成关联。这样做的关键，不是把所有成本换算成同一种 Token，而是让模型、数据工具和业务任务保持各自语义。
04
预算如何真正管住 Agent
用量计价最大的风险不是价格高，而是不可预测。Agent 可能选择低效路径、重复翻页、连续重试，甚至围绕同一个主体反复调用相近工具。只在月底提供一张汇总账单，已经太晚。
更稳妥的控制链路是：
任务估算 → 预算预留 → 工具执行 → 结果验证 → 成功结算或失败回滚 → 任务汇总
截至 2026 年 8 月，企查查智能体数据平台（企查查 MCP）覆盖企业数据、法律数据和智能文档解析三类领域，形成 9 个 MCP Server、197 个工具和 27 个业务 SKILL。平台积分不是模型 Token，而是数据与工具能力的计量结算单位：不同能力可以使用不同计量规则，同一查询主体还需要通过合并计量和用量保护降低无效重复消耗。
在企查查 MCP 的工程链路中，额度控制不能只是“余额减一”。更完整的实践包括：调用前预占额度，工具成功且满足结算条件后确认消耗，失败或不满足条件时回滚；同一个请求重试时保持幂等；相同请求并发到达时由一次真实执行服务多个等待方，避免重复访问下游和重复结算。
预算还应分层设置：任务级预算控制一次任务最多消耗多少，Agent 级限额控制日常运行，租户级限额守住总体合同边界，主体级保护控制围绕同一家企业的重复调用。月度封顶可以作为其中一种可配置策略，但具体阈值应由业务策略版本管理，不应写死在 Agent Prompt 中。
异常熔断则需要关注“有没有继续取得进展”，而不只是“有没有报错”。同一工具与参数反复调用、连续失败、长时间无新证据、预算快速消耗或时延显著异常，都可以触发停止、降级或请求用户确认。
图 3 · 从预算预留到结算、回滚与异常熔断
05
Trace 如何支撑调用归因与费用审计
一次 Agent 任务通常横跨 Host、模型服务、MCP Client、MCP Server 和下游数据服务。只有请求日志，没有跨服务 Trace，常见问题就很难回答：某次积分消耗来自哪个用户目标？同一个工具为什么调用两次？第二次是业务需要、自动重试还是并发重复？最终报告引用的是哪一次结果？
工程上需要区分四类标识。
task_id 聚合一项业务任务及其最终产物；request_id 定位一次请求，并支撑幂等、计量和故障排查；trace_id 连接跨服务的完整执行链；span_id 定位规划、工具调用、下游查询或报告生成中的某一个操作。
MCP 2026-07-28 已正式规范通过 _meta 传播 W3C Trace Context，固定使用 traceparent、tracestate 和 baggage 等约定，使 Host、SDK、MCP Server 与下游服务可以进入同一条可观测链路。在企查查 MCP 的工程实践中，业务任务、调用请求、Agent 运行任务和 Trace 分别管理，避免用一个 ID 同时承担业务聚合、幂等结算和链路观测等多种职责。
Trace 可以支撑归因，却不能代替授权和业务验收。trace_id 证明“请求经过哪里”，不证明“调用者有权访问什么”，也不证明“报告结论正确”。费用审计需要把 Trace 与身份、计量事件、策略版本和任务结果共同关联。
图 4 · task_id 管业务聚合，trace_id 管跨服务路径
06
一份企业客户尽调报告如何汇总多次调用
下面以企查查 MCP 的企业客户准入尽调（KYB）场景为例，观察多次工具调用如何汇总为一个可验收的业务结果：
请帮我对 XX 有限公司做一份完整的 KYB 核验报告，重点核验主体真实性、股东结构及最近三年的司法风险。
这个任务不是“一次查询”，而是一条有顺序、有分支的执行链。
第一步，确认主体。先通过名称和统一社会信用代码确认唯一企业；如果命中多个候选主体，任务进入补充确认，而不是选择一个最像的企业继续执行。
第二步，建立当前企业画像。查询当前工商登记、经营状态、法定代表人和主要股东，形成后续所有调用共同使用的主体锚点。
第三步，识别股权与受益所有人。调用受益所有人识别及相关股权工具，直接引用企查查 MCP 返回的最终受益股份、表决权等聚合结果；禁止 Agent 自算穿透路径比例或臆测中间层，未返回项明确标记为“未披露”或“本次未核验”。
第四步，先扫描再下钻风险。先用风险扫描工具获得各风险维度的计数和分布，只对非零或任务明确关注的维度继续查询明细。与逐个工具“散弹枪”式调用相比，“先扫后钻”既降低无效调用，也让预算与证据覆盖更容易解释。
第五步，汇总任务结果。Agent 将多个工具结果组织为主体真实性、股东结构、受益所有人、司法风险和待核事项等章节，并保留数据时点、来源和调用依据。
在这条链路中，每个 Tool 都可以分别判断“调用是否成功”，每份数据都要判断“结果是否可用”，而整个 KYB 任务只有在必查项完成、报告形成、证据可追溯且未决事项明确时，才能进入“业务任务完成”。
任务消耗也不是由报告字数决定。主体是否复杂、股权穿透层级、风险维度数量、历史跨度和证据要求，都会改变数据工具调用及最终报告的信息充盈度。企查查智能体数据平台的积分在这里承担的，是把近两百项数据能力变成可计量、可追踪、可控成本的能力消费，而不是把模型输出字数换算成价格。
企查查 MCP 提供的不只是一次企业查询，而是将主体确认、企业画像、股权穿透、风险扫描和报告汇总组织为 Agent 可调用、可计量、可追踪的企业数据能力。
图 5 · 多次模型、工具和数据事件如何汇总成一份 KYB 报告
07
为什么结果计价仍然困难
结果计价最接近客户价值，也最容易被高估成熟度。
第一是归因。一份报告由模型、外部数据、行内知识、Agent 编排和人工确认共同完成，很难把全部价值归给其中一个环节。
第二是责任边界。数据服务商负责事实与数据边界，模型负责生成与解释，业务人员负责最终决策。三者不能因为采用统一结果价格而模糊责任。
第三是验收标准。“生成报告”“必查项完整”“人工审核通过”和“最终授信获批”是完全不同的结果，合同必须明确验收停在哪一层。
第四是结果滞后。风险降低、销售转化或授信质量可能在数月后才能观察，还受到市场和人工决策影响，无法全部在任务结束时结算。
因此，更现实的方向不是用结果计价替换一切，而是建立混合模型：基础订阅承载身份、权限和基础服务；模型 Token 计量计算；积分计量专业数据与工具能力；标准任务包覆盖可定义的流程交付；只有边界清楚、可验证的部分，才引入结果增量计价。
对于正在建设 Agent 平台的团队，可以先用五个问题检查自己的成本治理是否完整：
模型计算、数据工具和任务结果能否分开核算？
每一笔消耗能否关联发起人、任务、调用链和最终产物？
是否区分调用成功、结果可用和业务任务完成？
是否具备预算预留、限额、幂等、回滚和异常熔断？
所谓“结果”是否有明确、可验证的验收标准？
Agent 上岗后，软件的价值单位正在从席位延伸到能力、任务和结果。席位仍然重要，但它只能解释“谁可以使用”；下一代企业软件还要解释“哪个 Agent 为了什么任务，调用了什么能力，消耗多少，交付了什么，结果能否复核”。
真正可持续的 Agent 商业模式，不是找到一个新单位替代席位，而是把三本账记清楚、关联好，并让每一笔消耗都能回到业务任务和可信结果。
动手试一试 · 企查查智能体数据平台
为 AI 智能体注入真实的商业世界。企查查智能体数据平台提供企业数据、法律数据和智能文档解析三类 MCP 服务，覆盖企业核验、受益所有人识别、风险扫描、尽调报告、法规案例查询和文档解析等场景。
企查查 MCP 已接入 WorkBuddy / QwenWork / TraeWork 等主流 AI 工具，也支持任意兼容 MCP 协议的 AI 客户端。
访问平台官网，查看能力中心、SKILL 广场与接入指南，或直接在线体验。
参考资料（节选）
千问办公相关：财新《阿里整合 QoderWork、悟空、MuleRun 三款智能体》，2026-07-03；千问办公《产品介绍》。
飞书：《飞书里的豆包如何支持团队协作》。
腾讯云：《WorkBuddy Enterprise》。
Deloitte Insights：《SaaS meets AI agents》，2026。
MCP 官方资料：《The 2026-07-28 Specification》，2026-07-28；《MCP Tasks》；《SEP-414 · OpenTelemetry Trace Context Propagation》。
分享嘉宾
INTRODUCTION
杜虎
企查查科技股份有限公司
技术总监
负责企查查智能体数据平台的工程落地与产品能力建设，持续推进企业数据、法律数据和智能文档解析能力进入 AI Agent 场景，实践方向包括 MCP 协议、Tool / Resources / SKILL 设计、Agent 计量结算、反幻觉与可信调用链路。
本文对计量字段和任务链路的描述，是基于企查查 MCP 实践形成的工程抽象，用于技术交流，不等同于生产库表、接口字段或对外商业计费承诺。
往期推荐
AI Search+ES 9.4.X 最佳实践:“更快、更准、更安全的企业级搜索引擎”"为 AI Agent 提供坚实底座”
客服、审批、运营、协同——阿里董晓庆出品 DACon「Agentic Workflow」论坛，谈数字员工如何重构企业流程
点个在看你最好看
SPRING HAS ARRIVED
