让一个通用语言模型帮你写一个 Axon 函数，你会得到两种答案之一。诚实的那种是礼貌地拒绝。危险的那种，是一段自信满满的代码，调用了 rollupByDay() —— 一个在任何版本的 SkySpark 中都从未存在过的函数。
这不是智能上的失败，而是接触面上的失败。Axon 是一门用于构建分析逻辑的领域特定语言：小巧、奇特而优美，它的 folio 查询模型和 defcomp 组件系统，在任何训练语料中都找不到相似之物。模型读过数百万行 Python，却几乎没读过一行你的代码。
Axon MCP Server 的存在就是为了解决这个问题，而且它用的是最朴素的办法：不去微调模型，而是把真实的语料放在一次工具调用之内。
问题的形态
一个被幻觉编造出来的 Axon 函数，比没有答案更糟。在 Python 里，一个臆造的方法一秒钟就会抛出 AttributeError。而在建筑分析平台上，一条看起来合情合理的规则可以通过语法检查、部署到正在运行的现场，然后悄无声息地产出错误的能耗数据，直到一个月后才有人注意到基线漂移了。
所以需求从来不是「让助手听起来很流利」。而是：每一条建议都必须来自真实存在的东西，而且助手应当能够证明这一点。
被索引的内容
Axon MCP Server 索引三类内容，并通过 Model Context Protocol 全部对外暴露：
- SkySpark 文档 —— 数千个 HTML 页面被抓取并切分
- Axon 函数 —— 来自同步的项目文件夹与离线库导出
- 操作符用法 —— 真实的调用点，而不只是函数签名
当前版本的核心数据：30 到 60 秒内索引 4,000+ 份文档页面，查询响应时间 低于 50 毫秒，并配有 24 小时缓存，后续启动瞬间完成，无需从零重新抓取。
为什么解析器比嵌入模型更重要
人们很容易把索引当成一个已解决的问题：每 500 个 token 切一刀，把切片嵌入，然后收工。这种做法对散文尚可接受，对代码则糟糕透顶。
按固定字符数切分一个 Axon 函数，你会时常把一个 do ... end 块从中间劈开。第一个切片是有条件却没有主体，第二个是有主体却没有条件。两者嵌入出的向量基本毫无意义，而且两者都会心安理得地出现在搜索结果里。
Axon MCP Server 转而使用一套专门构建的 tree-sitter 语法 进行解析。这带来三项实实在在的收益：
- 切片落在语句边界上。 被检索到的切片是一个完整的思路，因此读到它的助手看到的是合法代码。
defcomp单元被呈现为组件的接口。 当有人询问某个组件接受什么、返回什么时，这个问题有了结构化的答案，而不是从上下文里猜出来的。- 注释被保留为搜索信号。 解释一条规则为何存在的那句话，往往正是自然语言提问的最佳匹配，而粗糙的解析器会把它当作非代码丢弃。
语义搜索的功劳归于嵌入模型。而语法解析，才是让被嵌入的东西值得被搜索的原因。
有据可依，而非能说会道
这带来的差别一点也不微妙。
右侧那一栏就是这个产品的全部意义。助手并不是在耍聪明，而是在担责。它找到了东西，能指出它来自哪里，而且它用来抵达那里的调用图是双向的 —— 你既可以问某个函数调用了谁，也可以同样轻松地问谁调用了它。
技术栈简述
全程 TypeScript，使用 Model Context Protocol 通信。FlexSearch 负责关键词检索，LanceDB 搭配 HuggingFace Transformers 嵌入负责语义检索，tree-sitter 负责结构解析，Prisma 之上的 SQLite 存储项目与索引运行的元数据，Web 端点则使用 OAuth 2.1。
运行需要 Node.js 20 或更高版本。其余一切都可离线工作；运行中的 SkySpark 实例是可选的，仅用于解锁执行与实时查询功能。
这到底是给谁用的
- SkySpark 开发者：编写暖通空调、能源与 sparks 逻辑，想要一个真正懂这个平台的结对程序员，而不是一个拿 Python 模式往上硬套的
- 楼宇自动化集成商：整合那些目前散落在十几个项目文件夹和某位资深工程师记忆里的知识
- AI 辅助开发者：需要准确的上下文，并且已经学会不再轻信那些自信满满的语法
最后这一类才是真正诚实的受众。这里的价值并不在于助手变得更聪明，而在于它不再对一门从未学过的语言自信地给出错误答案。
Axon MCP Server 以 source-available 形式发布于 github.com/Project-SandStar/AxonMcpServer。项目页面 提供了完整的工具清单与安装指南。