Siqi Liu / 结构性必须 - 数字孪生的AI 混合架构

1. 纯范式的“成本悬崖”

在前一部分里，我们已经区分了 MCP（基于工具）和 Code-as-MCP 在两个关键维度上的差异：

一是动作是如何被表示的，二是系统在什么时候进行校验。

这些差异在小规模场景下并不显眼，但当系统复杂度上升，如果强行把所有问题塞进单一范式，问题会以一种非线性的方式暴露出来。

我们在实践中反复遇到两种“成本悬崖”。

第一种发生在工具侧。

当代理被要求完成诸如“列出数据集中所有异常”这样的任务时，标准 API 工具往往会一次性返回成千上万条结果。

这些结果如果被原样序列化并注入上下文，很快就会消耗掉数十万 token。

后果并不只是成本上升，而是更系统性的：

• 响应延迟急剧增加
• 上下文窗口被挤占
• 模型开始丢失最初的约束和指令

工具本来是为“精确控制”设计的，但在高数据密度场景下，却反而成了上下文的主要压力源。

第二种悬崖出现在代码侧。

在另一端，如果为了完成一个本质上是原子操作的任务（比如“选中对象 #42”），却让代理去生成、执行一段脚本，那同样是一种过度设计。

这类任务本身不需要复杂逻辑，却额外引入了：

• 代码生成延迟
• 运行环境和依赖风险
• 执行失败的更多可能性

结果是：系统为了表达能力，牺牲了原本可以获得的确定性和速度。

问题并不在于哪一种范式“更先进”，而在于：

当它们被用到不适合的地方时，成本会突然失控。

基于这个判断，我们最终采用了一种双轨执行结构。

2. 架构：带有“上下文匝道”的双轨系统

在实现上，系统并不尝试同时混合两种范式，而是把执行路径拆开。

轨道 A：确定性控制环（标准 MCP）

这一条路径专门用于：

• UI 操作
• 状态变更
• 单实体、低返回量的查询

它的特点是约束强、动作集合有限，所有行为都可以在调用前通过 schema 校验。

这条路径的目标是：快、确定、可验证。

轨道 B：生成式分析环（Code-as-MCP）

另一条路径则用于：

• 批量数据处理
• 聚合、统计、可视化
• 需要多步逻辑的复杂计算

这里我们刻意放弃强约束，换取表达能力。生成的代码运行在沙箱中，直接面对数据源，而不是上下文窗口。

3. 上下文匝道：什么时候切换轨道

系统会持续监控一次观测返回的数据密度。当一个标准工具调用的返回结果接近或超过预设的 token 阈值时，编排器不会再把完整结果注入上下文。

取而代之的是三个步骤：

1. 中止注入：阻止大规模 JSON 进入上下文
2. 数据下沉：将结果写入共享存储（如 CSV / Parquet）
3. 返回元观测：明确告知代理数据位置，并要求通过代码工具处理

这一步不是优化，而是强制状态转移。

代理此时无法继续使用工具路径，只能切换到代码轨道。

5. 实验：同一任务下三种架构的表现

我们选取了一个真实的数字孪生任务作为对比基准：

在 1 万个实体上做一次全量异常筛选，并生成 PDF 报告。

针对这个任务，我们分别实现了三种方案：纯工具（A）、纯 Code-as-MCP（B）、以及带上下文匝道的混合架构（C），观测如下：

A. 纯 Tool（Pure MCP）

• 总耗时：约 13 分钟。
  • 其中 AI 分析对话约 11 分钟。
  • 工具调用 7 轮，约 3 分钟。
• Token 使用：一次全量分析若不截断需要约 51 万 token。为避免爆炸，我们对所有 API 返回结果做了截取。
• 结果质量：由于上下文被严重压缩，最终异常分析准确度只有约 23%。

这印证了前文的判断：在高数据密度场景下，Tool 成为了上下文的主要压力源，而不是“精确控制”的优势方。

B. 纯 Code-as-MCP（Code 作为唯一范式）

• 总耗时：约 23 分钟。
• 工具调用：15 轮（大部分是围绕代码执行的控制与补救）。
• 结果质量：异常分析准确度约 85%。

业务上结果明显更好，但代价是整体耗时几乎翻倍，而且很多时间花在「生成和修正代码」本身，而不是 I/O 或工具调用。

C. 混合架构（Tool + Code + 上下文匝道）

• 总耗时：约 4 分 30 秒（04:36:26 – 04:40:58），中间经历了清晰的 “Tool → Code” 切换。
• 关键轮次：
  • R2：entities_keyword_search 返回约 108,634 tokens，系统判定 Oversized，写入 CSV，仅保留 100 行指针信息。
  • R3：entities_browse 精炼后依然达到 512,675 tokens，再次触发 CSV 下沉，保存 500 行详细记录。
  • R4+：进入 execute_data_analysis，Python Sandbox 内部循环处理数据约 3.5 分钟。
• Token 视角：
  • 原始返回：512,675 tokens。
  • 系统限制：2,000 tokens。
  • 实际上下文负载：被压缩成一个“文件路径字符串 + 提示语”。等价于把 0.5M token 压成几十 token，约 256 倍缩减。

从延迟拆分看：

• 大数据获取 + I/O：约 5 秒（读写 + CSV offload）。
• 分析与生成：约 3.5 分钟，全部发生在沙箱代码环境中，而非 Chat 主线程。

这符合模型预期：在混合架构下，I/O 成本几乎可以忽略，主要成本变成“代码生成与迭代”，且被局限在数据平面内部。 在同一个「1 万实体异常筛选 + 报告生成」任务上，纯 Tool 方案在 13 分钟内只给出了约 23% 的有效结果；纯 Code 方案虽然将准确度提升到约 85%，却把总耗时拉长到 23 分钟；而带上下文匝道的混合架构，在约 4 分 30 秒内完成同样任务，将分析准确率提升到约 90%，同时避免了 50 万级 token 的上下文爆炸。

6. 不止是数字孪生：这种混合结构还能去哪儿？

虽然本文的出发点是数字孪生，但“控制平面用 Tool、数据平面用 Code，加上一条最小化的切换规则”本质上是一种结构模式，而不是行业特例。

在其他领域里，我们也能看到类似的任务谱分布：

• 金融分析

  • 高频下单、风控指令，更像“紧急停机”：需要严格 schema 的 Tool（交易 API）。
  • 策略回测、组合再平衡，更像“全量异常筛选”：需要 Code-as-MCP 在沙箱里跑大规模计算。
  • 典型混合用法是：“用 Code 分析持仓，再用 Tool 下达极少量、可验证的指令”。

• DevOps / SRE

  • “在 1GB 日志里找到出错请求”：天然适合 Code（grep / 脚本 / pandas）。
  • “重启某个 pod / 缩容某个 deployment”：必须走 Tool（Kubernetes API），保证安全和可审计。
  • 这里的 off-ramp 很像是：“日志查询超出上下文 → 写入文件 → 交给代码工具处理，再把结果映射回少量控制命令”。

• 数据驱动应用的一般模式

  只要一个系统同时满足：

  • 状态是开放且可变的；

  • 决策依赖多轮反馈；

  • 同时存在“低数据量高风险操作”和“高数据量低风险分析”，

    那么这套Tool 控制平面 + Code 数据平面 + 简单匝道的结构，就有很大概率是比“纯 Tool”或“纯 Code”更稳的解。

总结：回到系统结构

我们三篇合在一起，讲的是一个演化过程：

• 1：用结构层 / 动作层 / 成本层，把“多轮交互”“Tool vs Code”这些直觉问题，抽象成可讨论的结构变量。
• 2：在这个抽象之上，给出了一个实际可运行的混合架构原型：双轨执行 + 上下文匝道，把“什么时候应该用 Tool，什么时候必须用 Code”变成一个可实现的状态转移。
• Part 3：通过在 1 万实体上的实验数据（Pure Tool / Pure Code / Hybrid）的对比，把这个架构从“合理”收束到“必要”：
  • 纯 Tool：13 分钟，约 23% 准确率，上下文被迫截断。
  • 纯 Code：23 分钟，约 85% 准确率，但整体延迟失控。
  • 混合架构：约 4 分 30 秒，约 90% 准确率，并且通过一次简单 off-ramp 避免了 50 万级 token 的上下文爆炸。

所以，这个系列最后想表达的并不是“工具比代码好”或者“代码比工具强”，而是：

在一个开放、反馈驱动、数据量跨度巨大的系统里，我们很难用单一范式去同时撑住控制平面和数据平面。真正可行的做法，是承认两者的结构差异，把它们摆在合适的位置，然后在需要切换那一刻，通过一条非常简单的规则，让 Agent 换到另一条轨道上。

数字孪生是这样一种结构最直观、收益最明显的场景之一。