告别硬编码接口，CAD 几何内核如何变身 A2A 智能体

从单体到分布式：几何内核的 A2A 智能体演进之路

在传统的 CAD 二次开发体系中，C++ 几何内核与 OpenGL 渲染引擎往往像连体婴一样紧密耦合。对于拥有底层自研内核的团队而言，这种架构在单机时代或许能带来极致的性能，但在 AI Agent 爆发的今天，却成了阻碍智能化转型的最大绊脚石。当我们需要让大模型"看懂"图纸、"操作"模型时，硬编码的接口让每一次功能扩展都变得异常沉重。

想象一下，你的 AI 助手想要执行一个"检测所有厚度小于 0.1mm 的薄壁区域"的任务。在传统架构下，你可能需要编写复杂的 C# 包装器，通过 P/Invoke 调用底层的 C++ 函数，还要小心处理内存泄漏和线程同步问题。更糟糕的是，如果未来想把这个能力开放给云端的其他智能体协作，现有的紧耦合代码几乎无法直接复用。

破局的关键，在于将原本深埋在项目深处的几何算法，重构为独立的、基于 A2A（Agent-to-Agent）协议 的远程智能体。这不仅仅是接口的封装，而是一场从"单体应用"向"分布式智能体网络"的架构革命。

解耦之道：构建独立的 GeometryAPI 层

重构的第一步，是必须狠心切断几何计算逻辑与渲染上下文的直接依赖。在很多老旧项目中，render_manager.cpp 里混杂着 BVH（包围体层次结构）构建代码，main.cpp 里散落着临时的射线相交测试。这种" spaghetti code"让 AI 根本无从下手。

我们需要设计一个纯净的 GeometryAPI 类，它不依赖任何 OpenGL 上下文，只关注数据与算法。这个类的核心职责是提供一套清晰、原子化的几何服务接口。例如，不再让 AI 去遍历三角形列表，而是直接暴露如 getThinParts(float max_thickness) 或 getIntersectingPoints(Ray ray) 这样的高阶语义方法。

在数据结构设计上，为了适配后续的网络传输和零拷贝需求，我们必须重新审视内存布局。传统的面向对象做法可能会为每个顶点创建对象，带来巨大的内存开销和缓存未命中。在面向 AI 智能体的架构中，推荐采用 SoA（Structure of Arrays） 布局，将坐标 x、y、z 分别存储在连续的数组中。这不仅有利于 SIMD 指令加速，更重要的是，它为后续的零拷贝序列化打下了基础。

// 推荐的数据结构设计：紧凑且易于序列化
struct Point {
    float x, y, z;
    // 支持从原始浮点数组构造，方便与 GPU 缓冲互操作
    explicit Point(const float* arr) : x(arr[0]), y(arr[1]), z(arr[2]) {}
};

struct Ray {
    Point origin;
    Point direction;
    // 内部算法自行处理归一化，对外屏蔽细节
};

struct Intersection {
    Point point;
    int triangleIndex; // 使用索引而非原始指针，便于跨进程/网络传递
    float distance;
};

注意这里的一个关键变化：Intersection 结构中不再持有 Triangle* 原始指针，而是使用 triangleIndex。在单体应用中，指针是最快的引用方式；但在分布式 A2A 架构中，指针是无效的。使用索引配合全局共享的内存池或对象 ID 映射，是实现跨进程通信的前提。

零拷贝与序列化：性能平衡的艺术

将本地 C++ 能力转化为远程 A2A 服务，最大的挑战在于性能。几何计算通常是数据密集型的，如果每次请求都要进行深度的对象序列化和反序列化，网络延迟和 CPU 消耗将让实时交互成为奢望。因此，零拷贝（Zero-Copy） 理念必须贯穿数据传输的全流程。

在加载模型阶段，loadModel 函数应直接复用已有的内存池机制。解析 STL 或其他格式时，数据不应经过多次复制，而是直接落入预分配的内存池中。BVH 树的构建也应基于这些原始数据的索引进行，避免构建额外的副本。

bool GeometryAPI::loadModel(const std::string& filename) {
    clear();
    // 关键：解析器直接填充内存池，无中间拷贝
    if (!parseSTLToPool(filename, m_trianglePool)) {
        return false;
    }
    // BVH 仅存储索引，指向内存池中的数据
    m_bvh = std::make_unique<BVH>(m_trianglePool.getAllIndices());
    m_bvh->build();
    return true;
}

当这一层能力被封装为 A2A Tool 时，我们需要在网络序列化层面做文章。对于大规模的网格数据，不要尝试一次性将整个模型通过 JSON 传输。相反，应该采用流式传输 或分片引用的策略。

在 A2A 协议中，Artifact 对象可以携带二进制数据。我们可以设计一种自定义的二进制载荷格式，直接在内存块级别进行传输。客户端（Client Agent）收到数据后，可以直接将其映射到本地内存地址，无需逐字段解析。对于射线相交这类查询，请求包只需包含射线的原点、方向向量以及必要的元数据（如坐标系变换矩阵），响应包则只返回相交点的索引列表和距离。这种"最小化传输"策略，能将网络开销控制在微秒级，确保几何智能体的响应速度足以支撑实时交互。

此外，内存池的生命周期管理也需适配分布式场景。在单体应用中，对象销毁由析构函数自动完成；而在远程服务中，必须引入显式的资源租约机制。可以通过 A2A 的 Task 状态机来管理：当任务开始时锁定相关内存块，任务结束或超时后自动释放，防止远程调用导致的内存泄漏。

封装核心算法为标准 Tool

有了干净的 API 和高效的数据传输通道，下一步就是将具体的几何算法注册为 A2A 协议下的标准 Tool。这是让大模型能够"调用"几何内核的关键一步。

在 A2A 架构中，Tool 的定义不仅仅是函数签名，更包含了语义描述、参数约束和示例。我们需要将原本硬编码在 C# 或 C++ 中的功能，转化为机器可读的元数据。

以"薄壁检测"为例，这是一个典型的工业质检场景。在重构前，这可能是一段写死在按钮点击事件里的 C++ 循环；重构后，它应当成为一个独立的 Tool：

{
  "name": "detect_thin_walls",
  "description": "分析当前加载模型的几何厚度，识别出厚度小于指定阈值的区域。适用于注塑件缺陷检测。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "max_thickness_mm": {
        "type": "number",
        "description": "最大允许厚度阈值（毫米）",
        "minimum": 0.01
      },
      "coordinate_system": {
        "type": "string",
        "enum": ["local", "world"],
        "description": "结果返回的坐标系"
      }
    },
    "required": ["max_thickness_mm"]
  },
  "outputSchema": {
    "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "triangle_index": {"type": "integer"},
        "thickness": {"type": "number"},
        "centroid": {"type": "array", "items": {"type": "number"}}
      }
    }
  }
}

同样的逻辑适用于射线相交 、布尔运算 、体积计算等核心功能。对于射线相交，Tool 的输入是射线参数，输出是有序的交点列表；对于布尔运算，输入可能是两个模型的 ID 或文件路径，输出则是新生成的模型数据引用。

在实现层面，这些 Tool 的后端逻辑直接调用前述的 GeometryAPI 类。由于 API 已经与渲染逻辑解耦，Tool 的执行完全可以在无头（Headless）模式下运行，甚至部署在独立的计算节点上。这意味着，前端渲染界面可以保持轻量，繁重的几何计算被卸载到了专门的"几何智能体"上。

利用 Agent Card 暴露几何能力

当所有的几何算法都被封装成标准的 Tool 后，如何让其他智能体发现并使用它们？这就轮到 Agent Card 登场了。

Agent Card 是 A2A 协议中的"名片"，它以 JSON 格式描述了智能体的身份、能力、认证方式以及支持的交互模式。对于我们的几何内核智能体，Agent Card 是其对外服务的唯一入口。

一个典型的几何智能体 Agent Card 可能长这样：

{
  "name": "CAD-Geometry-Core",
  "description": "高性能几何计算引擎，提供薄壁检测、射线追踪及布尔运算服务。基于 C++ 内核，支持零拷贝数据传输。",
  "url": "https://geo-agent.internal.corp/v1",
  "version": "2.1.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateful": true
  },
  "skills": [
    {
      "id": "geo.thin_wall_check",
      "name": "Thin Wall Detection",
      "description": "Identify regions with thickness below threshold."
    },
    {
      "id": "geo.ray_intersect",
      "name": "Ray Tracing",
      "description": "Calculate intersections between rays and mesh geometry."
    },
    {
      "id": "geo.boolean_op",
      "name": "Boolean Operations",
      "description": "Perform union, difference, and intersection on solids."
    }
  ],
  "authentication": {
    "schemes": ["Bearer"],
    "credentials": "internal-service-token"
  }
}

通过这张"名片"，任何接入 A2A 网络的客户端智能体（比如一个负责自然语言理解的对话 Agent，或者一个负责工艺规划的调度 Agent）都可以动态发现这个几何服务的存在。它们不需要知道底层是 C++ 还是 Rust，也不需要关心内存是如何管理的，只需要根据 Agent Card 中的描述，构造符合 inputSchema 的请求，即可调用强大的几何计算能力。

这种机制彻底解决了异构系统互通的难题。以前，C# 前端调用 C++ 内核需要繁琐的 DLL 导出和类型映射；现在，一切变成了标准的 HTTP/JSON-RPC 交互。即使是运行在 Python 环境中的 AI 框架（如 LangGraph 或 AutoGen），也能无缝集成这个几何智能体，实现跨语言、跨平台的协同工作。

架构演进：从硬编码到智能协作

回顾整个重构过程，我们实际上完成了一次深刻的架构演进。

在改造前，调用链路是僵硬的：UI 按钮点击 -> C# 事件处理 -> P/Invoke 调用 -> C++ 临时函数。这条链路上充满了硬编码的逻辑，任何变动都需要重新编译整个项目，且无法被外部系统复用。

改造后，调用链路变成了灵活的智能协作：用户自然语言指令 -> 编排 Agent (Client) -> A2A 协议路由 -> 几何智能体 (Remote Agent) -> 执行 Tool -> 返回结构化 Artifact。

在这个新架构中，几何内核不再是某个特定软件的附属品，而是一个独立的、可被任意调用的智能体。它可以同时服务于多个前端：一个是传统的桌面 CAD 界面，一个是 Web 端的轻量化查看器，甚至是一个完全由语音驱动的巡检机器人。

特别值得一提的是内存池管理与网络序列化之间的平衡策略。我们在 C++ 层保留了高效的内存池以确保计算性能，而在网络边界通过索引映射和二进制流传输来规避序列化开销。这种设计既没有牺牲底层几何引擎的毫秒级响应能力，又成功将其接入了分布式的 A2A 生态。

未来的 CAD 开发，将不再是单纯的功能堆砌，而是智能体的编排。当你需要一个新的功能，比如"自动修复破损网格"，你不需要从头写代码，只需训练或配置一个新的 Agent，让它调用现有的"网格加载"、"拓扑分析"和"几何修补"Tool 即可。这种组合式的创新能力，正是 A2A 协议赋予几何内核的全新生命力。告别硬编码接口，让你的 CAD 内核真正变身为企业级 AI 生态中的智慧大脑。