数据是公开的,代理走的路径不是——于是他的 mock 成了我的文档
来源:dev.to — 2026-09-30
📋 概述
一位叫 Pouya 的开发者读了作者的帖子,认为他的诊断是错的,于是克隆仓库提了这个项目的第一个外部 PR。他的判断听起来很合理:故障来自模型猜文档类型、编造查询语法,所以把真实 schema 和可用示例写进工具描述,让模型被告知形状而不是去猜。作者照着他的示例跑了一遍,结果全是错的——查询里多了一个多余的点,字段名有六个根本不存在(claim.subject、finding.finders、patch.findingRef、patch.commitHash 等)。问过之后才知道原因:Pouya 当时跑不通那套 MCP,在 Context MCP endpoint 上撞了 401,只能对着 LM Studio 上的离线 mock schema 测试查询生成逻辑,字段名就是这么来的。所以问题从来不是模型幻觉,而是「数据公开可查」与「代理实际走的鉴权路径」之间那道缺口——一个为了阻止模型编 schema 的补丁,差点把一份不匹配的 schema 装进模型读取它的地方,而那比它想修的 bug 更糟。
🔑 核心要点
- 作者刻意区分两条路径:公开可查的数据集不需要密钥,而代理真正走的是需要组织级 token 的 MCP 端点。
- PR 作者把真实 schema 写进工具描述,方向合理,但表中六个字段名与真实数据库不匹配(如 claim.subject、patch.findingRef)。
- 他还写出了两条跑不通的示例查询,原因是一个多余的点,以及文档 id 大小写敏感(finding-B1 而非 finding-b1)。
- 真实原因不是幻觉:贡献者在 MCP 端点上撞了 401,只能在离线 mock schema 上验证查询生成逻辑。
- 作者的关键判断是:写在工具描述里的猜测会以文档的权威抵达,因此比运行时猜测更危险。
- 他还自曝一次自我纠偏:早期草稿特意选了个读起来更干净但属于「挑样本证明观点」的例子,被评审在发布前拦下。
💡 金句
运行时猜错只是一个猜测,而写在工具描述里的猜测,是以文档的权威抵达的。
👍 0
👎 0
← 返回 dev.to 首页