Pascal Editor MCP Agent 嵌入实战：InMemoryTransport 十六行代码连通客户端与服务器-育师

Pascal Editor MCP Agent 嵌入实战：InMemoryTransport 十六行代码连通客户端与服务器

【免费下载链接】editorOpen-source 3D architectural editor with a local CLI, MCP tools, and practical workflows for humans and AI agents.项目地址: https://gitcode.com/GitHub_Trending/editor93/editor

做 Agent 嵌入的话，Pascal Editor MCP 的 InMemoryTransport 是最顺的路子：把服务器塞进自己的进程，不拉子进程、不占端口，十六行代码，Agent 就多出建墙、门窗、摆家具的完整 3D 建模能力。

第一幕 · 为什么进程内嵌入省掉三类开销

stdio 接 MCP 服务器的痛不在协议，在进程：pascal-mcp得自己 spawn，进程一死连接就断，崩溃恢复、僵尸进程清理都得按单客户端配置重写一遍。

HTTP 路线解决了多客户端共享，却把成本搬到了网络上：端口占用、绑定范围、鉴权 token 都得操心。对一个单进程的内部 Agent 来说，这些都是不必要的弯路。

InMemoryTransport 是第三条路：createLinkedPair()给出一对首尾相连的传输端点，服务器连一头，客户端连另一头，消息全程走内存，没有进程要管，也没有端口要监听。🚀

一句话：客户端和服务器同进程时，进程内嵌入是唯一不用为进程付费就能拿到完整能力的接法。

第二幕 · 16 行代码连通客户端与服务器

写代码前先认三个对象。

SceneBridge是无头场景桥，直连@pascal-app/core的 Zustand store。所有变更走真实 store，被 Zundo 天然捕获成可撤销步骤，undo/redo 不用额外处理。调一次loadDefault()，场景就种好了 Site → Building → Level 层级，立即可查。

createPascalMcpServer是服务器工厂。把桥传进去，得到一个装好全部 tools、resources、prompts 的McpServer实例，暴露的能力与 stdio、HTTP 版一致。

InMemoryTransport提供内存传输对，调createLinkedPair()两端即连通。

最小接入路径长这样：

import { createPascalMcpServer, SceneBridge } from '@pascal-app/mcp' import { Client } from '@modelcontextprotocol/sdk/client/index.js' import { InMemoryTransport } from '@modelcontextprotocol/sdk/inMemory.js' const bridge = new SceneBridge() bridge.loadDefault() // 播种默认场景：Site → Building → Level const server = createPascalMcpServer({ bridge }) const [srvT, cliT] = InMemoryTransport.createLinkedPair() const client = new Client({ name: 'my-agent', version: '0.1.0' }) await Promise.all([server.connect(srvT), client.connect(cliT)]) // 两端接通 const tools = await client.listTools() console.log(tools.tools.map((t) => t.name)) const scene = await client.callTool({ name: 'get_scene', arguments: {} })

官方示例是可编译运行的完整版，bun run packages/mcp/examples/embed-in-agent.ts直接跑。

第三幕 · 把 LLM 的工具调用接回场景图

接通之后，工具调用的路由权完全在你手里。常见接法分两步：先把listTools()的工具清单转成 function-calling 定义喂给模型；再把模型决策解析成{name, arguments}交给callTool()，结果作为观察回灌上下文——这就是一轮 ReAct 的"思考 → 行动 → 观察"。

由于传输对的两端同处一个事件循环，一次思考加一次行动不离开进程，延迟自然比子进程管道低。

值得先上手感受的几个工具：get_scene拉整张场景图，Agent 每轮开工先问它；create_wall用两个 2D 端点落墙，建错了undo一步退回；apply_patch把批量创建、更新、删除做成一次原子提交，适合"隔个墙、铺个地"这种整间操作；export_json把场景图序列化，既可持久化也能喂给下游。

第四幕 · 从 Demo 到生产：存储、审计与上生产前要知道的四个坑 🛠

注入 store 获得 save/load 工具

createPascalMcpServer接受store选项。传任意一个 SceneStore 接口实现（save、load、list、delete 等），save_scene、load_scene、list_scenes这类持久化工具就会挂上服务器。不想自己写，包内自带 createSceneStore，底座是本地 SQLite。把底层数据库换成 Supabase 或自己的服务，接口不变。

用 executeTool 做审计与耗时统计

传executeTool回调，每次工具调用都会经过你：拿到name和AbortSignal，需要放行再调execute()。审计日志、计时、权限拦截都能挂在这里：

const server = createPascalMcpServer({ bridge, store: await createSceneStore(), // 内置本地 SQLite executeTool: async ({ name, execute }) => { const t0 = performance.now() try { return await execute() } finally { console.log(`[audit] ${name} ${(performance.now() - t0).toFixed(1)}ms`) } }, })

operations 层深度定制

要改整套场景操作层的行为，可传operations选项整体替换（见 operations/）。但九成嵌入场景走不到这一步。

上生产前必知的四个坑

坐标约定：写几何代码前先记住，右手系、Y 朝上、X/Z 是地面平面，长度米、旋转弧度。2D 平面点[x, z]直接映射世界坐标，第二个分量是世界的 Z（深度），不是"上"。细节见 coordinate-conventions-demo.md。
版本冲突：与编辑器共享数据目录时，每次写入都带版本检查；别人先存了新版本，工具报live_sync_version_conflict，用load_scene重载再继续。
能力边界：建模工具里唯一不能用的是export_glb——依赖浏览器渲染器，无头环境只会返回not_implemented。视觉工具（如analyze_floorplan_image）要求宿主支持 sampling 能力，不支持会收到sampling_unavailable。
内存管理：无头模式没有渲染器消费dirtyNodes队列，它会一直涨；关心节点更新的话定期调bridge.flushDirty()排空。