大家好，我是你们的朋友架构君，一个会写代码吟诗的架构师。
北邮附近的饺子馆开源Skill封面一家经营近 20 年的饺子馆，把自己做成了 AI 能调用的接口。
这件事比“再做一个点餐小程序”更值得琢磨：当入口从网页转向 Agent，小店怎样让机器拿到可信、可执行的数据？
我的判断是：技术门槛不算高，但接口意识很超前。
金谷园饺子馆门店它不是聊天壳，而是一组业务能力
金谷园以自身名义在 GitHub 开源了一个 MIT 许可的 Skill。它不是让模型背下门店资料，而是把地址、营业信息、推荐菜、动态、排队与到店自取等能力，拆成 Agent 可以查询的结构化接口。
金谷园Skill的GitHub仓库现在的架构分成两部分：仓库主要是 Skill 包和 Node.js CLI，通过 REST API 取数；另有独立的 MCP 服务，使用 Streamable HTTP。换句话说，Skill 不是 MCP 服务端源码，MCP 也不等于整个 Skill。
金谷园Skill说明与门店信息一个请求怎么跑起来？
只想查询公开信息，可以在兼容的客户端里接入远程 MCP。不同客户端字段可能略有差异，核心地址是：
JSON{
"mcpServers": {
"jinguyuan": {
"url": "https://mcp.jinguyuan.cloud"
}
}
}
调用链很朴素：
TEXT用户提问 -> Agent识别意图 -> MCP调用门店数据 -> 返回结构化结果 -> Agent组织答案
Skill早期能力展示图里展示的是项目早期的六项能力，仓库后来已经继续扩展，不能把这张图当成当前上限。比数量更重要的是：每项能力都有明确输入、输出和失败边界。
门店数据通过Skill与MCP到达Agent查询信息和执行动作，必须分开
远程 MCP 适合查门店、菜品和排队信息，但填入一个地址，并不能让 Agent 直接替你取号或取消。
真正的取号、本人进度和取消动作，需要安装 Skill、完成授权，并在本轮操作中明确确认。这条边界非常重要：读操作可以开放，写操作必须有身份、确认、幂等与审计。
小项目也有生产环境的坑
开源初期的演示里，服务曾因为 CloudBase 依赖缺失而无法返回数据。这反而是一本很真实的架构教材。
Agent调用时的依赖故障把类似服务放到生产环境，至少要守住三点：实时数据带采集时间和新鲜度；外部依赖失败时能降级，不拿旧数据冒充当前状态；有副作用的动作必须可追踪、可重试，也能防重复执行。
这件事真正值得看的地方
它的意义不是让每家餐馆都去训练模型，而是让真实业务开始思考：怎样把自己的信息与服务，变成机器能理解、能调用的能力。
招牌是给人看的，接口是给 Agent 用的。技术可以小，边界不能糊；能被调用，也不等于应该被随便执行。
