HTN 规划作为多服务器 MCP 工具编排的协调层

核心问题是跨服务器 MCP 工作流如何实现可复现的工具排序和执行前检查。作者提出用 HTN 规划器决定序列，再由中间件执行，而不是每一步都让 LLM 选择工具。

• 使用场景：MCP 服务器不能调用其他服务器的工具，跨服务器流程必须由宿主协调。作者关注实验室自动化、科学协议和受监管流程中的复现需求。
• 现有做法：作者称，ReAct 式逐步决策可能让相同目标产生不同工具序列，还会为每次工具调用增加推理往返；执行前也没有完整计划可供专家授权。
• 核心观察：HTN 方法可表达专家掌握的程序分解，原始动作可映射为 MCP 工具调用；运行时再绑定跨动作的数据依赖。
• 提出的系统：三层协调架构分离规划、绑定与执行。研究范围是消费已有 HTN 领域后的协调问题，领域生成由配套论文处理。

这是一篇架构与可行性演示论文，不是攻击或防御评测；正文没有定义攻击者、攻击成功条件或安全威胁模型。

相关研究围绕层次规划、工作流执行和 LLM 编排展开。第2节将领域生成视为上游问题，将本文定位为下游协调架构。

HTN 规划与领域学习

• SHOP、SHOP2 与 GTPyhop：Nau 等（1999、2003、2021）的系统构成规划基础；GTPyhop 用 Python 函数表示动作和方法。本文只使用任务分解片段。
• HTN-MAKER、CURRICULAMA：Hogg 等（2008）与 Li 等（2024）研究 HTN 学习；ChatHTN（Muñoz-Avila 等，2025）交替使用 LLM 近似分解和符号验证。
• L2HP：Puerta-Merino 等（2025）从自然语言生成 HDDL。Oswald 等（2024）、Guan 等（2023）的规划模型生成工作被作者归为互补的上游研究。

规划驱动的协调与科学工作流

• ROSPlan：Cashmore 等（2015）在 Robot Operating System 内嵌 PDDL 规划器。作者称它是最接近的架构前例：规划器位于异构执行器之上。
• Nextflow：Di Tommaso 等（2017）处理手工编写工作流的分布式执行；作者将本文的区别写为由规划器生成工作流，并通过 MCP 服务器执行。
• SHOP2 Web 服务组合：Sirin 等（2004）允许规划期间执行信息服务；本文先固定可检查的计划，再联系服务器。

LLM 规划与工具调用

• ReAct、Toolformer：Yao 等（2023）、Schick 等（2023）代表作者对照的 LLM 驱动工具编排范式；Ruscone 等（2025）的 MCP 科学助手也采用这一模式。
• ReWOO、LLMCompiler：Xu 等（2023）、Kim 等（2024）分别使用预先承诺的计划变量和 LLM 生成的任务 DAG。作者称二者仍由 LLM 合成计划；Felendler 等（2026）的一次性代码生成则按请求重建协调逻辑。
• LLM+P 与规划能力批评：Liu 等（2023）让 LLM 调用经典规划器；Valmeekam 等（2023）主张 LLM 应作为正式计划的翻译者或评论者。

基线与本文定位

• 概念基线：ReAct 式逐步调用，以及 ReWOO、LLMCompiler 的一次规划方案用于讨论推理次数；本文没有在共同基准上实测这些方法。

作者将区别归于先生成符号计划，再绑定和执行。配套论文 Jacopin 等（2026）负责从 MCP 服务器材料生成领域，本篇消费这些产物。

三层协调架构把工具排序与运行时数据分开：规划器生成包含占位值的动作序列，绑定层声明工具接口，中间件在调用过程中解析真实输出（Figure 1）。

规划层：只生成符号计划

• 规划器：使用 GTPyhop v2.0.1；领域文件定义动作与方法，问题文件定义初始状态和任务。本文只用 HTN 任务分解，不用其目标网络功能。
• 任务结构：所有顶层任务均为复合任务，方法返回全序的子任务元组。动作参数和状态值使用占位值，规划期间不调用真实 API。
• 检查范围：作者称规划器可检查任务顺序和前置条件可满足性，专家可在实际执行前检查输出计划。

绑定层：声明动作与工具的对应

• 接口映射：JSON 配置把每个原始动作映射到一个服务器和一个工具，可附参数映射及 JSON-path 输出提取器。
• 一对一对应：每个原始动作包装一个已公布工具。图数据库记录服务器、工具与动作之间的映射边及其参数绑定。
• 手工提取器：八个演示服务器都没有声明输出 schema，因此输出提取器由人工编写。作者称绑定层可独立进行 schema 验证。

执行层：在运行时绑定数据

• 上下文传递：中间件依序调用工具，把提取出的命名输出存入执行上下文，再替换后续动作中的上下文模板。
• 跨服务器边界：原始动作只绑定一个服务器；HTN 方法不必知道服务器身份，跨服务器数据流在绑定与执行边界实现，执行不重新进入规划。
• 宿主接口：两个 MCP 工具分别生成计划和获取执行计划；后者返回客户端协调标志及逐步调用信息，由宿主中间件执行。

控制器与推理次数主张

浏览器计划控制器通过 FastAPI 后端运行同一流程，Server-Sent Events 逐步报告开始、完成、错误及毫秒时长，供运行后审计。

作者给出的架构比较是 N+1→2：N 步的逐步 LLM 编排需要初始决策及每次观察后的推理，HTN 方案则由 LLM 请求规划和执行，随后不再参与。这是架构计数，不是实测耗时改善；论文未报告具体 LLM 模型，也未提供 LLM 基线运行结果。

实验主要检验架构能否执行及重放既定计划，没有进行 LLM 编排基准比较。第4节报告真实药物靶点发现演示、PCR 模拟，以及另外三个领域的实现覆盖。

实验设置

• 模型与规划器：未报告实际运行的 LLM 被测模型或裁判模型；规划工具为 GTPyhop v2.0.1。
• 真实服务器：OpenTargets、UniProt、Reactome、KEGG、RCSB PDB、AlphaFold DB、ChEMBL、PubMed；共公布 140 个工具，演示使用 8 个（Table 1）。
• 计划规模：药物靶点领域有十个原始动作和六个方法；演示执行存储的乳腺癌计划，使用其中八个动作。
• 运行协议：同一计划连续执行三次；服务器为 Node.js stdio 子进程，启动后复用。首次为冷进程，后两次为暖进程（Table 2）。
• 指标与判定：报告 Wall-clock、Executed、步骤顺序及服务器分布；PCR 另报告动作数、吞吐和成功比例，没有 LLM 评审或人工一致性结果。
• 对照与重复：未实测 LLM 驱动基线；药物靶点演示重复三次，PCR 未报告各配置的重复次数。

主结果

据 Table 2，同一八步药物靶点发现计划在八个真实服务器上重放：

表格较宽，可左右滑动

运行	子进程状态	Wall-clock	Executed
1	cold（刚启动）	35 s	8/8
2	warm（复用）	29 s	8/8
3	warm（复用）	15 s	8/8

• 结构复现：Table 2 图注及第4节报告三次的步骤顺序、服务器分布和上下文替换链相同；作者将其作为结构复现证据。
• 输出与计划的区别：第5节称中间标识符等值随底层 API 的变化而变化，重放保持不变的是计划结构。
• 耗时解释：作者称外部 API 延迟主导总耗时，Table 2 图注提到本例的 ChEMBL，以及其他会话中的 PubMed；这些数值不构成相对 LLM 的加速结果。

PCR 模拟：计划长度与执行

• 测试对象：三服务器 PCR 准备领域，包含移动、液体处理和模块控制；使用模拟 MCP 客户端，作者称其实现 Opentrons Flex API 接口。
• 报告结果：4 个样本的计划为 55 个原始动作，96 孔板为 611 个；吞吐约为 16.5 actions/s，作者报告所有配置成功比例为 100%（第4节）。
• 证据条件：这些结果来自模拟客户端；论文未给出全部配置列表、每配置运行次数或成功比例分母。作者认为可替换为物理服务器而保留规划和绑定层。

另外三个领域：实现覆盖

• DNA 提取：Opentrons Flex 上的四服务器 Omega HDQ 协议，三个场景的计划长度为 89–129 个动作；具有完整绑定层映射（第4节）。
• 另外两个领域：连接 MaBoSS 与 PhysiCell 的多尺度 TNF 癌症建模，以及三服务器抓放机器人场景；第4节明确它们只运行规划层。
• 作者的解读：作者认为这些领域支持将领域编写与协调分别处理；这不等同于三个领域都已完成真实服务器执行。

其他消融与分析

• 工具面统计：Table 1 按六类证据整理八服务器的工具，公布总数 140，演示调用数 8。
• 参数与消融：论文没有报告独立消融表、统计显著性检验或 LLM 基线数值。
• 图的可读范围：Figure 1 给出规划、绑定、执行及隔离服务器的架构文字，没有定量实验曲线；提供的文本无法支持曲线或点簇位置分析。

作者明确的后续工作包括实测 LLM 工具调用比较，以及更丰富的分支。这些方向写在第5节；实验覆盖事实另列如下。

作者指出的局限与后续方向

• 基线与耗时：未报告实测 LLM 驱动基线；作者称墙钟加速主张需要经验性工具调用比较，并将其留给未来工作（第5节 Limitations）。
• 领域分支：规划器可按前置条件选择方法，但演示的药物发现领域大体线性；作者将更丰富的分支列为未来工作（第5节 Limitations）。
• 接口推广：作者推测，经适度修改可推广到隔离 REST 端点、不能直接委派的多智能体工具系统及科学工作流管理器；这是猜想（第5节 Generalisation）。

实验覆盖范围

• 真实执行：药物靶点演示连接八个真实服务器，同一存储计划连续运行三次，调用八个公布工具（Table 1、Table 2）。
• 模拟执行：PCR 使用三服务器模拟 MCP 客户端；论文报告配置成功比例，但未报告分母或每配置重复次数（第4节 Scaling）。
• 领域实现：DNA 提取具有完整绑定映射；TNF 癌症建模和抓放机器人只运行规划层（第4节 Coverage）。
• 绑定条件：八个真实服务器均未声明输出 schema，JSON-path 输出提取器由人工编写（第4节 Tool–action correspondence）。
• 模型比较：论文未报告实际运行的 LLM 模型、LLM 基线耗时或查询记录；推理次数减少来自架构分析（第3节、第5节）。

HTN 规划在这里承担跨服务器工具协调层的角色。作者关注 MCP 宿主逐步选择工具时的复现、推理成本和执行前检查问题。

• 架构设计：规划器先输出全序原始动作；JSON 绑定层指定服务器、工具和输出提取规则；中间件运行时传递结果，不重新规划。
• 真实演示：八服务器药物靶点发现计划连续重放三次，每次完成 8/8 步，保持相同顺序与服务器分布（Table 2）。
• 运行耗时：Table 2 的冷进程运行为 35 s，两次复用进程运行分别为 29 s、15 s。作者称耗时受外部 API 延迟主导，没有实测 LLM 基线可供比较。
• 模拟规模：PCR 模拟中，4 个样本对应 55 个动作，96 孔板对应 611 个；作者报告所有配置成功比例为 100%，但未报告分母（第4节）。
• 领域覆盖：DNA 提取三个场景为 89–129 个动作，并有完整绑定映射；TNF 癌症建模和抓放机器人只运行规划层（第4节）。

作者认为，分离规划、绑定和执行能让计划成为独立于运行的可检查产物。当前证据支持架构可行性和既定计划的结构重放；论文将实测 LLM 编排比较及更丰富分支留给后续工作。