通过 MCP 连接的 AI 代理追踪分摊

通过模型上下文协议（MCP）将 AI 代理连接到工作区后，即可用自然语言让它追踪成本在各分摊步骤中的流向。无需运行报表或编写 SQL：只需提出问题，代理就会调用 PlaidCloud 的分摊追踪工具来查找模型、解释变化、沿链路回溯，并回答假设性问题。

任何通过 MCP 连接的客户端都可以使用，无论是聊天代理（Claude Desktop、ChatGPT）还是编码代理（Claude Code、Cursor），因为它们都通过 MCP 服务器访问同一组工具。

前提条件

包含分摊步骤（allocation_split、allocation_rules 或 allocation_dim）的项目。
已通过 MCP 连接到工作区的 AI 代理，请参阅 AI 编码代理入门。

可以问什么

向代理提问……	它会做什么	背后的工具
“这个项目中有哪些分摊模型？”	列出每个模型、其各阶段以及产出的结果表	`allocation_model_find`
“`cost_line_rev` 是如何计算的？”	显示被拆分的成本池、拆分所依据的驱动因素以及目标表	`allocation_describe`
“`cost_line_rev` 从 2025 年到 2026 年为什么发生了变化？”	对比两个期间，并将变化归因于成本池规模与驱动因素构成的差异，同时列出贡献最大的科目	`allocation_root_cause`
“什么为 `cost_line_rev` 提供数据？”	沿上游链路回溯：驱动因素、源成本池和导入	`allocation_lineage`
“`revenue_by_line` 在哪些地方用作驱动因素？”	列出所有按该表拆分的分摊	`allocation_driver_usage`
“如果美国收入增加 100 万美元会怎样？”	按各结果当前在成本池中的占比，将变化拆分到每个受影响的结果上：在扇出的各结果之间可累加，而不是对每张表取最坏情况	`allocation_forward_impact`
“如果装配成本中心的人数驱动因素增加 10 会怎样？”	在新的驱动因素权重下对固定成本池重新切分，显示哪些目标增加、哪些减少。如果结果表由多个步骤写入，则拒绝回答，而不是重新切分一个不属于该分摊本身的成本池；如果驱动因素与模型上次运行时所做的拆分不再一致，同样拒绝回答	`allocation_driver_scenario`

实际示例

一位财务分析师注意到某条按收入驱动的成本行同比下降，于是提出了一个问题。代理在后台调用多个分摊工具，完整地回答了这个问题。

您提问： 我们基于收入的成本分摊（cost_line_rev）在 2026 年相比 2025 年似乎下降了。发生了什么？它由什么构成？如果美国收入变动 +100 万美元会怎样？

代理回复：

它是什么。 cost_line_rev 是您的作业成本法（ABC）模型中按收入驱动的阶段。它取一个成本池（group_amount，限定为一组损益表科目），并按 revenue_by_line 中的收入进行拆分，在每个实体、年度和月份内加权。

为什么下降（美国，2025 → 2026）。 分摊到美国的成本从 712 万美元降至 299 万美元，减少 413 万美元（-58.0%）。这不是构成变化：美国在成本池中的占比在两年中都稳定在约 23%。原因是总成本池缩小，并集中在少数几个科目：

科目 2025 2026 变化

700000 $2.58M $1.09M −$1.49M

701000 $1.85M $0.77M −$1.08M

610000 $1.71M $0.72M −$0.99M

670000 $0.68M $0.29M −$0.39M

702000 $0.30M $0.13M −$0.18M

这五个科目基本解释了全部变动。

由什么构成。 cost_line_rev 由 revenue_by_line（拆分驱动因素）和 gl_pool_entity（成本池）构建。

注意：该驱动因素是共享的。 revenue_by_line 同时也驱动 cost_line_cs 和 cost_line_admin，因此收入重述会波及这三者。

您的美国 +100 万美元情景。 这 100 万美元按每个结果当前在成本池中的占比分摊到共享该驱动因素的各结果上，因此各表的估算值加起来等于总变化，而不是每张表都重复完整的 100 万美元，您会得到 cost_line_rev、cost_line_cs 和 cost_line_admin 各自的数值，可以直接求和。如果将问题缩小到单个目标，则估算值仅应用于该部分。

科目	2025	2026	变化
700000	$2.58M	$1.09M	−$1.49M
701000	$1.85M	$0.77M	−$1.08M
610000	$1.71M	$0.72M	−$0.99M
670000	$0.68M	$0.29M	−$0.39M
702000	$0.30M	$0.13M	−$0.18M

分析师无需打开任何一张表，就得到了完整的答案：变化的幅度、背后的科目、血缘关系，以及假设分析的影响范围。

对答案的可信程度

流畅的答案不一定正确。现在，每个“为什么发生变化”的答案都会附带一段通俗的说明，告诉您可以在多大程度上信任它，这样，看似合理但不可靠的数字会在您据此行动之前被标出，而不是埋没在文字之中。除了解释之外，代理还会告诉您：

置信度：高、中或低，反映变化的分解是否清晰。由单一明确原因驱动的变化置信度为高；多个原因相互重叠，或数字未能完全对账的变化，置信度较低。当结果由多个分摊分支构成时，置信度会按每个分支对变化的贡献大小加权，因此一个小而不可靠的分支不会拖低原本清晰的答案；但如果某个分支的数字本身存疑（拆分未对账、数据过时或无法归因），仍会拉低整个答案的置信度。
通俗表述的注意事项，例如：原因是多个重叠因素的混合，而不是单一因素；答案依赖于当前的层次结构或驱动因素权重；部分变化可能是数据完整性造成的假象（某个期间尚未加载完毕），而不是真实的变动；为分摊提供数据的成本池或驱动因素近期未重新加载，因此数字可能基于过时的数据；或者假设分析的数字无法在各目标之间累加。
明确说明无法进行的对比。 大多数答案会为所报告的变动提供参照：与一年前的同一变动对比，以及与近期各期间对比，以便您区分正常的一年与趋势的断裂。对于由同时分摊多个值列的步骤所写入的表，这两种对比都不会生成，因为它们都是为单列答案设计的。过去这一点不会提示，因此答案看起来像是已经尽可能利用了数据，而实际上是按设计提前停止了。现在它会在限制中明确说明，同时给出没有更窄的问题可以替代提问的原因，并说明答案中的任何数字都不会因此被撤回：金额是精确的，缺少的只是背景信息。

当代理无法确定精确原因时，它会明确说明，并指出可以让它清晰作答的范围或筛选器，而不是编造一个听起来很有把握的说法。而且由于置信度和注意事项是答案的一部分，它们会随答案一起传递：如果您让后续代理做总结，这些可信度信号不会被悄悄丢掉。

新鲜度提示（当底层数据在设定时间窗口内未重新加载时降低置信度）默认关闭，由管理员按工作区开启，管理员还会设定多近算作新鲜（对于仅按季度或按年刷新的数据，该窗口应更长）。如果团队有意使用较旧的数据，在有人选择启用之前，它不会干扰您。

开启后，它会作用于所有读取数据仓库的答案：“为什么发生变化”的解释，以及两种假设分析的答案，后者尤其重要：假设分析使用模型上次运行时实现的占比来传播或重新加权，因此数据过时恰恰是估算最不可靠的情况。

有两点限制了它能告诉您的内容，并且适用于所有答案，而不仅限于假设分析。第一，它只查询直接加载到 PlaidCloud 中的表的年龄：由工作流步骤构建的表只能报告该步骤上次运行的时间，这与数据何时到达是两个不同的问题，因此特意不去查询，而不是给出错误的数字。第二，它指出每种类型中最旧的表（一个成本池、一个驱动因素），因此当假设分析扇出到多个步骤且不止一个驱动因素过时时，只会告知您其中之一。这两种情况都不会把过时的表报告为新鲜。

须知

如果一张结果表由多个分摊步骤产生，代理不会猜测是哪一个步骤导致了变化：它会列出候选步骤，并请您指明具体是哪一个。当您的问题缩小到只有其中一个步骤产生的行时（例如仅由它分摊的某个区域），代理会识别出这一点并自动追踪该步骤，同时告知您它这样做了。

指明某个步骤是告诉代理要描述哪个步骤，而不是要度量哪些行。 它报告的变化是整张表的，并且是精确的；无法归因于单个步骤的是各因素之间的拆分，因此对于有多个写入方的表，代理会保留该拆分，说明该数字涵盖了所有写入该表的步骤，并主动提出依次通过其他每个步骤追踪该表。每次这样的重新运行都是一次独立的度量：它既不是该步骤在您所看变化中的份额，也不是对该步骤单独的度量：这些步骤写入的是同一列，这正是拆分被保留的原因，因此返回的变化仍然涵盖所有这些步骤。

这适用于无论另一个写入方是什么的情况。不属于分摊的步骤，例如向结果表追加行的步骤，永远不是追踪的候选对象，因此不会提示您选择，但它的行同样计入总数，代理现在会如实说明这一点，而不是把它的变动并入拆分之中。

“如果这个成本池增加……会怎样”这类答案，会按各目标当前在成本池中的占比把变化拆分到扇出的各个结果上，因此各表的数字是可累加的，而不是各自都是最坏情况的上限。它们反映的是模型当前的占比：是对变化落点的一个范围明确的估算，而不是精确的预测。如果针对的是驱动因素或基准表而不是输入成本池，则会按驱动因素假设分析处理（见下文），因为更改驱动因素是对固定拆分重新洗牌，而不是增加数值。

这类分析请明确指定期间。 与“为什么发生变化”的问题或驱动因素假设分析不同，前瞻性假设分析不会为您推断期间列。如果不指定，估算将涵盖所有期间，而不是您心目中的时间窗口。

前瞻性假设分析通过查询写入每个目标的步骤来计算该目标的占比。当该查询失败时（该步骤的表没有期间列，或数据仓库拒绝了查询），该目标现在会完全不提供估算，并附上原因。过去它会报告到达该目标的全部变化，也就是一个上限，却与实测的答案呈现得完全一样，而该步骤下游的一切又据此估算，导致整个分支看上去都是正常的数字。

由此带来三点，答案会逐一说明：总数只涵盖已度量的目标；未度量步骤的下游不会据此估算，因此这些目标在答案中缺失，而不是被猜测；仅根据写入某个目标的部分来源度量的目标会明确说明这一点，并指出无法读取的步骤。该部分数字是对可读取内容的真实度量，因此成立，但它不是该目标的全部，缺失的部分可能更大、更小，或符号相反。请不要将其视为下限。

询问驱动因素的变化会产生什么影响，例如“如果装配成本中心的人数驱动因素增加 10 会怎样？”，代理会在新权重下对固定成本池精确重新切分，无需重新运行模型。它会显示哪些目标增加、哪些减少，并且增减合计净额为零，作为内置检查。它只做能够精确计算的事情：单个简单的拆分，搭配简单的驱动因素。任何更复杂的情况，例如基于层次结构或带筛选/条件的分摊、新增全新的驱动因素成员，或使某个分组变空的变更，都会拒绝并说明原因，而不是给出估算。

请使用驱动因素表中拼写的列名。 当某个步骤把驱动因素列以不同的名称传递下去时，应使用驱动因素表自己的名称提问，如果写错，答案回引的也是这个名称。结果的读取方向则相反：发生变动的成本中心和分组，使用结果表中拼写的名称，因为筛选和读取结果时用的就是这些名称。在大多数步骤上，两者是同一个名称。

按某个字段分解变化，会把具有相同值的行归为一组，而没有值的行也会归为一组。因此，在所比较的期间内每一行都为空的字段，会产生一个包含全部变化的单一分组，看起来是最集中的结果：只有一个成员、全部变动、完全可信。

现在，代理会告知您该字段在这些行中未填写，并保留集中度数字，而不是将其报告为 100%。它会建议改用已填写的字段，或者完全去掉分解，在这种情况下，它会自行找出最能解释变化的字段。如果第二个分组字段已填写，则分解是真实的，并照常报告，只是会注明那个空字段。空值显示为 (no value) 或 (blank)，两者是区分开的：从未填写的字段与明确设置为空的字段是不同的两回事。

受影响的始终只有分解。总体变化、其总数以及归因方式一直都是正确的。

当您没有指定字段时，代理会选择最能解释变化的字段，有时答案恰恰是该字段没有任何值的那些行。这是真实的发现，而不是故障，因此会如实报告而不是隐藏：某项成本悄然不再被标记，值得了解。

但是，“未分配的行增加了”在几乎总是填写的字段上与在几乎总是为空的字段上，含义大不相同。现在答案会在同一句话里说明属于哪种情况，例如：“最佳切分是 cost_centre 的未分配行：在所比较的期间内，cost_centre 在 12% 的行上有值”。只有 12% 的行填写了的字段几乎没有被使用；而 95% 的行都填写了的字段，则存在值得追查的真实缺口。极稀疏和极完整的字段会显示为不到 1% 和超过 99%，而不是 0% 或 100%，因为在这里这两者都不可能是真的。

搜索之前，代理会先向数据提一个快速的问题，以排除全程只有单一值的字段，或划分得过细而根本不能作为分组的字段。当该问题无法回答时（数据仓库无法度量的列类型，或连接中断），过去它会转而搜索所有字段，在出现问题的那一刻恰恰解除了这两项限制。

现在它会说明搜索没有运行，并用自己的话表述：这是对搜索的限制，而不是关于数据的发现。这一措辞与所比较的期间太大而无法搜索时的提示不同，因为您可以采取的措施也不同：在那种情况下，应缩小期间；在这里，应指定想要检查的字段，无论原因是什么这样做都有效。只有当故障是暂时性的，重试才会有帮助。

如果请求按表中没有的字段进行分解，现在会收到相应的提示，并附上表中实际有的字段，以便您一步纠正问题。过去，答案会完整且自信地返回，只是缺少分解，也没有任何说明表明曾尝试过分解；“进一步分析”的建议则指向完全不相关的地方。在一个真实模型上，连续四个问题都是这样返回的。

在链路更上游，规则有意不同。分摊所添加的字段只存在于其下游的表上，因此在您所询问的表上存在的字段，在向上追溯两个阶段时往往确实不存在。此时追踪会按该阶段实际拥有的字段分组，而不是丢失该阶段的分解，并告知您省略了哪些字段。

该说明针对的是较早的阶段，并且会明确这一点：“该阶段无法使用您所要求的分解”。它不是针对答案中打印的成员表：那些成员属于您所询问的表，按您要求的完整分组列出。较早阶段较粗的分组用于计算其自身的集中度数字，其成员不会列出。随之给出的建议同样会点明该阶段：如果还想要它的成员，请按所有被追踪阶段都具有的字段分组。在 2026 年 8 月之前，该说明写的是“is not in this answer”，并解释为“so the members you see are grouped only by the rest”，而建议则说该字段不在“the traced table”上：这指向的是打印出来的表，把它描述成了它并非的样子，还建议去掉一个本来有效的字段。

如果分解因其他原因缺失，例如数据仓库出现暂时性故障，答案也会以同样的方式说明，指出无法生成分解的阶段：总数已度量且不受影响，并提供重试。缺失的是细节，而不是错误。

当总数在两个期间之间从正数变为负数时，例如某个成本中心由净支出变为净贷项，既没有有意义的方法把变动分配给各驱动因素，也没有有意义的百分比：从很小的正数摆动到很大的负数，会得出类似 -10,013% 的数字，没有任何意义。

代理一如既往地拒绝对这样的变化进行分配。现在的不同之处在于，它会把这一点作为理由说出来，而不是先给出关于度量方式的通用说明：那样读起来像是解释，却与正下方打印的那一行相矛盾。对于跨越零的变化，不再显示百分比；两侧的金额以及变化本身都是精确的，不受影响。

请把这两个期间视为独立的数字：现在答案会在拒绝的那一行同时打印两者，并说明它们是您所询问的切片，还是整列。要查看是什么发生了变动，请添加分解维度：跨越零的总数无法拆分成原因，但其背后每个成员的变动读起来是正常的，答案通常就在那里。

每个答案的末尾都附有可以运行的下一步建议。过去有两种情况没有提供任何建议，而它们恰恰是您最容易卡住的两种：总数跨越零，以及代理完全无法汇总的阶段。现在两者都带有建议，后者会指明需要检查的表以及最可能的原因（该阶段的表缺少期间列），这样您可以先排除这一点，再假定是暂时性的数据仓库故障。

同样，当您已经把问题限定到某个成员时，答案不再建议限定到成员。该建议来自链路更上游记录的限制，而不是您提出的问题，却被当作适用于此处而在所述限制中重复出现。

仍有一种情况不提供下一步建议：当对驱动因素表的独立读取与实现的拆分不一致时，答案会说明这一点，但无法建议能解决问题的重新运行，此时有用的做法是直接检查驱动因素表，这是另一个请求，而不是对当前请求的调整。

提示

通过表的名称（cost_line_rev）或 id 引用表，两者都可以。
对于变化类问题，请指明要比较的期间（例如 2025 年与 2026 年），必要时再加上科目或实体等分解维度。
从宽泛的问题开始（“这个项目中有哪些分摊模型？”），再逐步深入；代理会保持对话线索，因此后续问题会基于同一个模型。
假设分析有两种：数值变化（“这个成本池增加 100 万美元”）按当前占比估算，并在各目标之间可累加；驱动因素变化（“重新加权这个驱动因素”）则精确重新切分，净额为零。请按您想要的那一种来表述问题。