1C: Platform Tools —— 把 1C 企业级开发搬进 VS Code，并接进 AI 代理

一、一个具体的场景

凌晨两点，俄罗斯加尔金边疆州某 ERP 实施公司的运维窗口里，配置师 Sasha 面对一份刚导出的配置源码：3000 多个元数据对象、40 万行 BSL 代码、散落在七个分支上的定制扩展。传统 1C 开发工作流要求他打开 Windows 桌面版 1С:Enterprise 配置器，慢得像在开一辆 1998 年的卡车——而团队三个月前刚刚全部迁移到 Linux 与 Cursor。 就在这时，yellow-hammer/vscode-1c-platform-tools 出现了。它不是一个"1C 语言的 AI 代码补全插件"，而是把 1C 开发这套沉重的仪式整体搬进现代编辑器的基础设施型扩展：项目树、元数据树、属性面板、测试面板、调试器、流水线、ER 图谱，再加上一个真正的 MCP 服务器，让 Claude Code / Cursor 这类 AI 代理可以直接驱动 1C 平台执行命令。

二、它要解决的到底是什么问题

1C:Enterprise 是俄语区 ERP 市场的绝对主导平台，其配置器（Configurator）是一个基于 Windows 桌面、仅支持 BSL/OneScript、界面停留在 2000 年代审美、且完全闭源的 IDE。它的元数据模型（配置、目录、文档、寄存器、报表、角色）有自己的 XML 序列化格式（*.cf、*.cfe），有自己的一套专有扩展点机制，也有一整套围绕 vanessa-runner（Open Source 替代配置器 CLI）建立起来的社区工具链。 这个项目做的事情，本质上不是"写一个更好的插件"，而是做 1C 生态的 VS Code 语言服务器兼操作总线：

• 同时支持三种项目形态：配置器源码目录（packagedef）、1C:EDT（Java 集成开发环境）格式、OneScript 脚本工程；
• 把 vanessa-runner 的几十条命令收进一棵可视化的命令树（信息库、配置、扩展、外部文件、发行版、启动、测试环境、依赖）；
• 用 VS Code 原生 Test Explorer 承载 1C 测试：支持 Vanessa Automation（.feature）、xUnit/Vanessa-ADD、YAxUnit、OneScript（OneUnit 与 1testrunner）、1bdd 五套框架；
• 提供条件断点、变量改写、扩展与外部处理器调试、性能采样；
• 内置 ER 图谱交互编辑器（cytoscape + elkjs 布局），可导出 Mermaid / Draw.io / SVG / PNG；
• 通过 ibsrv 发布文件型信息库，在浏览器里直接调 HTTP/Web/OData 服务；
• 扩展了 VS Code 的 customEditors、断点、调试器、walkthrough、键位，几乎接管了整个编辑器外壳。

三、用一个比喻理解它的架构

如果把 1C 平台比作一台只能从驾驶舱操作的挖掘机，那么这个扩展就是加装在挖掘机上的第二套驾驶舱，并且同时配了一个能听懂人话的调度员（MCP）。

• 它不重写挖掘机，所有真正的算力（加载配置、跑测试、启动企业平台）仍然发生在 1С:Предприятие 客户端和 vanessa-runner 进程里；扩展做的是遥控器；
• 它提供三种遥控通道：人在 VS Code 面板里点（图形）、脚本调用命令行（MCP/IPC）、以及 CI 里跑（Docker 镜像 + ibcmd）；
• Docker 模式的价值在于把"本地那台必须装 1C 商业平台的 Windows 工作站"抽象掉——命令在容器内跑，路径自动映射，ibcmd 走服务端组件，让 GitHub Codespaces 这类无 GUI 的云端开发环境也能干活。

四、AI 代理这一层，是它最有想象力的地方

项目内嵌了 19 个 SKILL.md 技能包（resources/skills/1c-platform-tools-*/SKILL.md），按域拆分为配置、调试、依赖、EDT、扩展、OData、流水线、测试、会话等。每个技能都以"任务 → Command ID → MCP 工具名"的三列表格描述能力边界。 更关键的是 src/shared/agentGate.ts 这个代理门禁：代理发起的调用不允许弹出交互式窗口（因为用户可能根本没坐在电脑前——可能在用手机或 Web 会话）。无法非交互执行的命令会返回结构化错误，并附带"改用哪个参数化命令"的提示。这是一种很成熟的 Agent 工程直觉：把 GUI-only 的命令显式隔离出 Agent 通道。 代理还有一条"文件触发器"通道：在 .cursor/1c-platform-tools-run-command 写入一行命令 ID，扩展执行后删掉文件。数据侧则通过标准 OData 接口读取，避免为 AI 单独造一套数据通道。

五、代码质量：一份罕见的"重测试"工程

从仓库结构看，这是一个成熟度相当高的 TypeScript 工程：

• 603 个 .ts 文件，功能代码 362 个、测试代码 241 个，测试/功能文件比约 0.67；
• CI 用 xvfb-run -a npm test 跑真实的 VS Code Extension Host 集成测试，另有一个三平台矩阵（Ubuntu / Windows / macOS）专门做"活进程 argv 与输出编码"测试；
• pretest 串联了 schema 生成校验、编译、tsc --noEmit 类型检查、eslint --max-warnings 0，质量门禁相当严格；
• 72 个 Markdown 文件、约 52 万字节的文档，其中 docs/ 下 22 篇功能手册（admin.md 32KB、metadata.md 34KB、tools.md 33KB），配套 VitePress 站点与 walkthrough 引导式教程；
• 代码注释密度极高且为俄语，几乎每个导出函数都带 JSDoc，说明了"为什么这样写"（如 githubToken.ts 解释为何必须用 SecretStorage 而非 settings.json——后者会随 Settings Sync 外传甚至被提交进 Git）。 架构上，代码被切成 src/app（注册与生命周期）、src/commands（21 个命令族）、src/features（23 个业务特性：元数据、集群、调试、EDT、流水线、测试……）、src/shared（69 个横切模块）、src/webviews、src/utils 六层，典型的特性驱动 + 命令注册表结构，边界清晰。

六、争议与局限：必须说清楚的部分

1. 强依赖商业闭源平台。仓库没有 Dockerfile、不提供任何官方镜像，文档明说 1C 授权不允许分发含平台的公开镜像。Docker 模式要用户自建镜像，CI 用它必须自备 1C 账号与 releases.1c.ru 凭据。对没有 1C 授权的团队来说，"开箱即用"是不成立的。
2. 元数据编辑深度有限。扩展能浏览、检索、按子系统过滤元数据，能编辑部分属性，但它并没有重写配置器；复杂的表单设计、模板编辑仍依赖原生配置器或 EDT。
3. 生态极度地域化。BSL、1C:EDT、vanessa-runner 体系对中文开发者几乎没有生态基础，属于典型的垂直封闭市场工具。
4. 单点维护风险。仓库有 234 星、25 fork、6 位贡献者，44 个 open issue——热度对垂直工具不算低，但核心仍集中在作者一人（Ivan Karlo）身上，靠 Boosty 和云-tip 捐赠维持。
5. Windows 中心的残留。即便主推 Linux/Docker/Codespaces，调试器、配置器 GUI、部分测试框架仍需要本地 1C 客户端，ibsrv 的文件锁处理、路径编码、进程终止都留有大量 Windows 特判（src/shared/ibsrvDataLock.ts、shellEscape.ts）。
6. 成熟度仍在爬坡。版本号还是 0.9.x，每两三天发一个补丁版本（v0.9.3 → v0.9.14 密集迭代），说明 API 与行为尚未稳定锁定。

七、行业意义：一条值得注意的线索

这个项目最值得关注的不是 1C 本身，而是它示范了遗留平台如何"反向适配"AI 时代：不去改造那个改不动的闭源平台，而是站在编辑器这一层，把平台能力重新包装成 AI 代理可以理解（MCP 工具 + SKILL.md）、可以调度（命令树 + 文件触发器）、可以自动化（流水线 + Docker + CI）的接口。 这条路径与当年"用 IntelliJ 插件生态改造 Struts/Spring 老项目"、"用 VS Code 远程开发改造本地 IDE 工作流"高度同构：当底座不可动时，就在旁边建一个可编排的控制平面。 对任何手握存量封闭系统的团队——从老旧 MES 到金融核心——这都是可复用的思路。

八、适合谁，不适合谁

适合：

• 已有 1C 存量资产、正在做 DevOps 或云原生改造的俄语区实施团队；
• 想把 AI 代理真正接入遗留业务系统调度的技术负责人；
• 需要在 Codespaces / 容器化 CI 中跑 1C 测试流水线的团队。 不适合：
• 没有 1C 授权与项目的团队（依赖链无法闭合）；
• 期望"AI 自动重构 1C 代码"的人——它的 AI 部分是执行与调度，不是代码生成；
• 中文生态的独立开发者（BSL 工具链与社区都在俄语区）。

结论：这是一个工程质量远超同体量垂直工具、但部署前提极其苛刻的 IDE 扩展。它把"1C 开发"这件事从 1998 年的卡车驾驶舱，搬进了 2026 年的智能代理调度台。