task-decomposition

name	task-decomposition
tier	meta-meta
description	Decompose each verification rule into independent sub-tasks and assign the optimal method (rule, code, LLM, manual) to each. Use when converting extracted rules into implementation plans, when a rule skill is too expensive or inaccurate and needs restructuring, or when designing a multi-step verification pipeline. Covers MECE decomposition, method selection via the four-dimension decision matrix, cost-benefit analysis, and source tagging. Also use when auditing an existing workflow for cost optimization opportunities.

任务分解与方法分配——柳叶刀方法

为什么叫「柳叶刀」

外科手术用柳叶刀，不用斧头。核查任务的分解也是如此——每一刀都要精准，切在方法论的边界上，而不是随意劈开。

每条核查规则看起来是一个动作，实际上是一条操作链。以「核查发票日期是否在合同有效期内」为例，实际包含：定位发票日期字段 → 提取日期值 → 标准化日期格式 → 与合同日期比对 → 生成批注。这五个步骤各自需要不同的处理方法。

把整条链丢给 LLM 处理当然能跑通。但成本是精细分解方案的 100 倍，出了问题也无法定位是哪个环节错了。柳叶刀方法的核心：把每条规则切到方法论上同质的最小单元，然后为每个单元分配最便宜且能胜任的方法。

MECE 分解原则

将核查规则分解为子任务时，必须满足 MECE（互斥穷尽）原则：

互斥——任意两个子任务不做重复的事。如果子任务A提取了发票日期，子任务B就不应再提取发票日期。重复意味着浪费和潜在的不一致。

穷尽——所有子任务合在一起覆盖整条规则。不能有遗漏。如果依次执行所有子任务，规则应当被完整核查。

每个子任务有且仅有一个输入和一个输出。上一个子任务的输出是下一个子任务的输入。这形成了一条接口清晰的流水线。

何时停止分解

当子任务在方法论上是同质的——即只需一种方法就能完成——就停止分解。如果一个子任务仍然需要两种不同的方法（比如先用正则提取，再用 LLM 判断），说明它还不是原子级别，需要继续切分。

标准分解链

大多数文档核查规则的分解遵循这条链路：

定位 → 提取 → 标准化 → 判定 → 批注

不是每条规则都有全部五个阶段。有些规则不需要标准化（提取值已经是目标格式），有些通过时不需要批注。但这条链路是可靠的起始框架。

流水线拓扑

根据规则类型不同，流水线有三种典型拓扑：

• 线性：单文档、单字段。定位 → 提取 → 标准化 → 判定 → 批注。大多数阈值检查属于此类，如资本充足率核查。
• 汇聚：来自不同文档或不同章节的两个字段。两条平行的定位-提取链在判定步骤汇合。发票金额与合同金额的交叉验证属于此类。
• 扇出：一条规则应用于文档内的多个条目（如验证发票中的每一行项目）。定位步骤产出 N 个条目，每个条目独立流过后续链路。此时规模维度至关重要——如果 N 很大，方法分配必须考虑单条目成本。

分解示例：发票核查

以「核查发票金额是否与合同约定一致」为例，完整分解如下：

序号	子任务	输入	输出	分配方法	依据
1	定位发票金额字段	发票全文	字段位置	正则	增值税发票金额字段位置固定，标记明确
2	提取发票金额	定位到的区域	数值（浮点数）	正则	格式可预测：¥xxx,xxx.xx
3	大写金额交叉校验	小写金额 + 大写金额文本	一致/不一致	Python	中文大写转数字后比对
4	定位合同金额条款	合同全文	段落文本	LLM (Tier 3)	合同格式多样，金额条款位置不固定
5	提取合同金额	定位到的段落	数值（浮点数）	正则 + Python	正则提取数字，Python 处理万/亿单位换算
6	金额比对	发票金额, 合同金额	通过/不通过	Python	纯算术比较（允许配置容差范围）
7	生成批注	所有提取值	批注字符串	模板	「发票金额 {X} 元与合同约定 {Y} 元不一致，差异 {Z} 元」

七个子任务中只有一个需要 LLM 调用。其余全部由正则或 Python 代码完成，成本为零。

决策矩阵

分解完成后，为每个子任务分配处理方法。分配依据四个维度的综合评估。完整的决策矩阵及详细用例参见 references/decision-matrix.md。

四维度定义

维度	含义	低（1-2）	中（3）	高（4-5）
确定性	输入格式的可预测程度	自由文本，无固定格式	半结构化，已知章节但格式多变	固定模板，字段位置精确
规模	每份文档需处理的条目数量	1-5 个	10-100 个	1,000 个以上
语义深度	需要的语言理解程度	零——纯模式或数值	中等——实体识别、简单上下文	深度——判断、充分性评估、意图推理
成本敏感度	单文档预算约束	不限（一次性审计）	中等（每月数百份）	紧张（每日数千份）

方法优先级

始终优先选择最便宜的能达到准确率要求的方法：

规则/正则 → Python 代码 → LLM 调用 → 人工审核

不允许跳级。先试正则，不行再试代码，代码不行再试 LLM，LLM 不行才上人工。每次升级必须有下级方法失败的证据。

注意四个维度之间存在交互作用。高规模加高成本敏感度会强力推动选择代码方案，即使中等语义深度在正常情况下指向 LLM。相反，低规模可以放松成本压力，使得 LLM 在理论上可以用复杂正则解决的任务上也成为可行选项。让维度的组合引导你，不要被任何单一维度绑架。

决策速查表

确定性	规模	语义深度	成本敏感度	推荐方法
高	任意	低	任意	正则 / 规则
高	任意	低	任意	Python 代码
中	高	低	高	代码 + 正则
中	低	中	低	LLM
低	任意	高	任意	LLM
低	高	高	高	低层级 LLM + 抽样校验
任意	任意	任意	—	人工（兜底）

成本效益意识

方法分配不是纸上谈兵，它直接决定了生产环境的单文档成本。

实战案例：发票匹配合同

某企业需要将 31,800 张发票与 15,940 份合同进行匹配。暴力方案：对 5.07 亿个配对全部调用 LLM 比对。

按 SiliconFlow API 定价（以 Qwen2.5-7B 为例，输入 ¥0.35/百万 token，输出 ¥0.35/百万 token），每次比对按 500 token 输入 + 100 token 输出计算：

• 单次调用成本：约 ¥0.00021
• 5.07 亿次调用：约 ¥106,470

十万元人民币只为了做配对匹配，这在任何业务场景下都不可接受。

柳叶刀方法的分层方案：

层级	方法	输入规模	输出规模	消减率	成本
1. 供应商名称 + 合同编号精确匹配	正则	5.07 亿对	25,200 匹配	99.5%	≈ ¥0
2. 金额区间（±5%）+ 日期重叠	Python	剩余未匹配	12,400 候选	97.6%	≈ ¥0
3. 行项目描述语义比对	LLM (Tier 3)	12,400 候选	7,652 确认	精准过滤	≈ ¥170
4. 低置信度匹配人工审核	人工	~200 不确定	~200 解决	兜底	≈ ¥700

总成本：约 ¥870。是暴力方案的 1/122。准确率相同，可调试性更强。

成本计算模板

在分解阶段就估算单文档成本：

子任务	方法	单次成本	每文档调用次数	小计
定位章节	LLM Tier 3	¥0.001	2	¥0.002
提取字段	正则	¥0.000	5	¥0.000
标准化	Python	¥0.000	5	¥0.000
交叉比对	Python	¥0.000	1	¥0.000
语义判定	LLM Tier 2	¥0.003	1	¥0.003
批注生成	模板	¥0.000	1	¥0.000
单文档合计				¥0.005

将单文档成本乘以预期文档量，与开发者用户确认预算是否可接受。如果超预算，优先优化成本最高的子任务——通常是单次调用最贵或调用次数最多的 LLM 步骤。

核心原则：先廉后贵

永远把便宜的过滤器放在前面。让正则和代码先消减 90%+ 的工作量，只把剩余的疑难部分交给 LLM。这不仅降低成本，还提升了调试能力——因为到达 LLM 步骤的数据已经被前序步骤严格筛选过。

来源标记

每个子任务的输出必须携带 extraction_method 字段。这不是可选的元数据——这是核查系统的承重结构。

来源标记支撑三项不可或缺的能力：

调试定位——当核查结论出错时，标记告诉你是哪个子任务、哪种方法产生了错误。没有标记，你面对的是一个黑盒。例如：金额比对失败，标记显示 extraction_method: regex，说明是正则提取阶段出了问题，而非判定逻辑有误。

成本归因——标记让你精确计算每种方法的实际成本贡献。哪些 LLM 调用在消耗预算？哪些正则步骤在免费贡献准确率？这些数据驱动优化决策。

置信度校准——不同方法有不同的可靠性特征。正则提取的结果非对即错，没有中间地带。LLM 提取的结果有置信度分布。来源标记直接输入 confidence-system 的方法先验（method prior），使置信度分数具备校准基础。

标记规范

在项目范围内保持一致的标记值：

标记值	含义
regex	正则表达式提取
python_calc	Python 计算或转换
llm_tier1 ~ llm_tier4	对应层级的 LLM 调用
template	模板填充（批注生成等）
manual_review	人工审核

多智能体协同 —— 不要用锁

如果一个任务大到你打算用 agent_tool 起多个子智能体并行做，按独立单元分片（一个规则一个子智能体、一份文档一个子智能体），让子智能体之间不需要通过共享可变文件来协同。

来自一个友邻团队的失败教训：他们让所有子智能体平等，通过共享协同文件领任务，并加锁防抢占。两类失败必然出现：

1. 锁被持有太久，或者干脆忘了释放。即便锁机制工作，二十个智能体的吞吐会下降到只有两三个的水平 —— 大部分时间都在等。
2. 系统脆弱：智能体可能在持有锁时崩溃，或重复获取自己已经持有的锁，或干脆不获取锁就更新协同文件。

KC 偏好的两种模式：

• 单调度器 —— TaskManager 一次发一个任务给主 conductor。无锁，无 peer 协同。这是 ralph-loop 的默认架构。
• 按单元分片 —— 用 agent_tool 起子智能体时，每个子智能体只负责一个不重叠的切片（一规则、一文档）。子智能体的状态写到自己的 sub_agents/<taskId>/ 下，共享产物（rule_skills/<id>/、workflows/<id>/）按规则路径分开。Block 11 的 git 自动提交把共享路径的写入序列化，按规则分片让"后写覆盖前写"不再是问题。

如果两个本应并行的子智能体非要相互通信才能推进，那它们其实应该是一个任务（顺序跑）或一条流水线（父智能体发完 A 再发 B），而不是平行的 peer。

反模式

LLM 万能论

把整份文档丢给 LLM，提示词写「请检查是否符合规则X」。演示时效果漂亮，生产中成本灾难。

典型案例：某项目将发票号码格式校验交给 LLM 处理。发票号码是固定的 20 位数字，一条正则 ^\d{20}$ 就能搞定。LLM 每次调用消耗 2000 token，准确率反而低于正则（LLM 偶尔会「理解」出不存在的格式问题）。成本差异：正则 ¥0 vs LLM ¥0.001/次 × 10 万张 = ¥100。

诊断信号：如果一个子任务的输入格式完全可预测，且不需要语义理解，它不应该用 LLM。

正则过度工程

为了覆盖所有可能的日期格式写了 500 行正则，结果维护成本极高，遇到新格式就崩溃。

诊断信号：如果正则需要频繁修补或超过 3 行，考虑这个子任务是否应该升级到 LLM 处理。

黑盒流水线

子任务之间没有中间输出，只有最终结论。出错时无法定位是哪个环节的问题。

典型案例：资本充足率核查流水线输出「不通过」，但无法区分是提取的资本充足率数值有误、还是比较逻辑有 bug、还是文档中根本没有这个字段。

诊断信号：如果调试一条规则需要从头到尾重新跑一遍，说明缺少中间检查点。

巨石端到端

不分层，每个子任务都对每份文档执行，即使前序步骤已经可以短路。

典型案例：贷款申请交叉验证流水线对每份申请执行完整的七步核查，即使第一步「定位」就发现文档中缺少相关章节。合理做法：定位失败 → 直接输出「字段缺失」→ 跳过后续步骤。

诊断信号：如果流水线对明显不适用的文档也消耗完整的处理资源，说明缺少短路逻辑。

过早优化

在核查逻辑还没验证正确之前就花大量时间优化方法分配。

正确顺序：先全部用 LLM 跑通 → 在 Samples/ 上证明核查逻辑正确 → 再逐个子任务尝试推向更便宜的方法，每次替换后验证准确率保持不变。先对再便宜，不能反过来。分解本身是最难的部分，方法分配随时可以调整。

与其他技能的衔接

任务分解在 KC 生命周期中处于规则提取和技能编写之间。

输入：来自 rule-extraction 的规则目录。每条规则是一个原子级、可测试的核查要求。如果规则尚未达到原子级别，先退回给规则提取环节做进一步分解，再进入任务分解。

输出：每条规则的子任务分解清单——每个子任务包含定义好的输入、输出和分配方法。这份分解清单直接输入 skill-authoring，成为技能文件夹的实现蓝图。分解清单同时也是测试契约：每个子任务的输出都可以独立测试和验证。

方法分配同时指导 skill-to-workflow 中的层级选择。当技能被蒸馏为工作流时：

• 正则/代码子任务 → scripts/ 中的代码
• LLM 子任务 → prompts/ 中的提示词
• 人工子任务 → 质量控制层的升级路径

分解方案不是一成不变的。通过 evolution-loop 的测试迭代，你会发现某些方法分配需要调整——以为是确定性的子任务出现了需要 LLM 处理的边界情况，以为需要 LLM 的子任务其实一条正则就能解决。更新分解方案，用 version-control 记录变更。

如果你发现一条规则很难分解为干净的子任务，这通常意味着你还没有充分理解这条规则。回到开发者用户那里去。问他们人工核查这条规则时的实际操作步骤。他们的人工流程往往就是最佳的分解蓝图——它揭示了再多抽象分析也无法发现的自然子任务边界。