原文地址 汇尘轩 - 锦恢的博客
前言
我的工作内容之一是开发blender的mcp，从而构建3d资产生成的agent（记住，是辅助！而不是全自动）。同时，我还是 OpenMCP 的作者，致力于打造闭环的 mcp agent 迭代与验证部署平台。如果你经常逛AI圈子，会发现一个现象，demo千千万，能用的，好用的产品却非常稀少。这里面涉及到的技术问题很多，你硬要我说出最关键的「问题」，恐怕就是下面两点了：
-
大模型的幻觉
-
你的幻觉
大模型的幻觉
相信大家多多少少都看过网上一堆大V天天在那边跟你讲什么「aha moment」，「四步微调」，「幻觉严重」，但是真的什么是大模型的幻觉，相信只是浅尝辄止使用过大模型的朋友未必有一个立体的认知。
大模型幻觉的定义
大模型的幻觉存在很多不同的定义，但是对于开发 AI 应用的朋友来说，你只需要知道如下关于「幻觉」的定义即可：
所谓大模型的「幻觉」，指大模型不知道自己不知道什么，遇到它不知道的事情，它会胡编乱造。
幻觉对于 Agent 的开发到底有多么恶劣的影响呢？我给你们举个例子，这个例子就在我编写的 OpenMCP 的教程里面 Implementing a Read-Only MCP Server for Neo4j in Go (SSE)
一个例子展示什么是大模型的幻觉
比如我们开发了一个 mcp，可以让大模型拥有查询数据库的能力，从而知道一些只有我们内部人员才知道的信息。有了这个能力，agent 就有望能够成为一个领域的客服机器人。
但是在开发的时候，你大概率会遇到类似于我这样的问题。
我现在询问 AI，「请列出最新的 10 条评论」，AI的回复如下：
AI 表示：我不知道呀！
这个时候你感到匪夷所思，因为自己写的这个工具提供的能力足以查到最新的评论了，然后你展开调用过程看一下 AI 是怎么干活的：
你发现 AI 查询「评论」这个条目的数据是使用的 Comment 这个类型来查询的，这显然是不对的，因为，如果你是一个啥都不懂，但是稍微学过数据库原理的实习生，你的老板交给 “查询最新评论的任务”，你要做的第一件事难道不是先熟悉一下这个数据库里有啥吗？可以看到，AI 啥也不问，直接一顿操作，然后得到一个空的结果，然后告诉我们，它不知道评论。
大模型不加以询问「到底哪个类型代表评论」就直接基于「Comment」这个类型进行查询就是典型的「大模型幻觉」，它不知道自己不知道「评论到底是哪个节点类型」，就直接拿 Comment 去尝试。当然，特殊训练过的 text2sql 模型大概率会展示更加“聪明”的结果，因为特化训练过了，但是对于我们想要开发 AI Agent 的应用工程师，我们肯定不会自己从头训练一个大模型，这不现实。
如何解决幻觉？
先说结论，不给定「应用场景」和「设计边界」的情况下，以目前的技术水平，不可能根本解决幻觉问题。
设计边界（英文 design boundary，软件工程术语，代表了系统的重要功能边界，说人话就是，一个软件/系统能做什么，不能做什么，你只要能完整说明白这两件事，就能说明一个软件/系统的设计边界，从而提出合理的设计预期和设计工期）
幻觉产生的根本原因我不想在这篇文章中细挖，因为从模型架构和数值计算等不同学科能得到不同的结论。而且说实话，知道幻觉产生的根本原因对于「应用开发者解决幻觉对 AI Agent的危害」这件事没有太大的实际帮助。
所以，这里我分享一下解决幻觉的主要方法。解决一切幻觉的前置工作就是先确定「应用场景」和「设计边界」，如果你执意说，我一定要做一个啥都能干的 AI Agent，很好，你应该去寻求 VC，而不是点开我这个无名之辈的拙笔涩墨来谋求茶余饭后的谈资。
比如对于上面的例子，上面那个例子的 AI Agent 的场景就是数据库查询，它的设计边界就是，能帮你查询你的数据库的信息，它不能做到下面这几件事：
-
帮你预定明晚的餐厅
-
帮你应付下周的课设报告
-
帮你的女朋友买演唱会门票
-
扮演一只可爱的猫娘
-
…
好，明确了这只 AI Agent 的设计边界后，有两种方法可以解决上面的问题：
-
通过系统提示词，做法：通过 openmcp 来进行调试
-
MCP 工具的原子化拓展：扩充 mcp 服务器的原子技能
受限于文章篇幅，在此就不做赘述了，下面是最终的效果图：
当然，也可以放在浏览器里面进行 mcp 调用，这样不用花钱：
具体做法请移步：觉得 MCP 太消耗 token？ 不妨试试这款插件，让你使用网页版本大模型也可以使用 MCP！
哔哔！
你的幻觉
阻碍 AI Agent 开发的，除了大模型的幻觉，可能还有开发者自己的幻觉。
其实原因我也在上面让诸位管中窥豹了，在 pretrain scaling law 逐渐不凑效的如今，大模型的能力边界越来越明确了。
所谓 pretrain scaling law 指的是不断地堆积参数和数据能让大模型的智能程度不断上升，这也是大模型能成功的底层逻辑。但是随着 openai 和 grok 团队在 2024 年超大型大模型的训练和评测结果出炉，预示着 pretrain scaling law 基本到头了。所以 2025 年很多团队的方向都是 inference scaling，人机对齐 和 多模态 了，最大的果子已经摘得差不多了。
但凡用过大模型解决过大规模实际问题的朋友一定体验过被气死的感觉，一开始对大模型很高的期待也随着这几年的使用逐渐理念了起来。
我旗帜鲜明地鼓励大家都去用大模型降低工作时间，多些时间陪伴家人，游山玩水，体悟人生；同时，我也旗帜鲜明地反对神化大模型和矮化大模型，把大模型饭圈化，这种透支公众对新技术心理预期的行为必须被抵制。
为什么说这么多呢？因为我就是想要表达一个观点，大模型再nb，也只是一个程序，一个算法，一个解决方案，它不一定适用于所有场景。如果你在一个就不应该用大模型来做的领域，试图开发 AI Agent 来解决问题，这注定是失败的。而且失败的原因你可能会归结为“大模型太垃圾了！”“那个叫锦恢的天天鼓吹 AI Agent 和 MCP 的未来”，“不是我烂，是基模烂”。
真的，真实案例！我就遇到过几个身边的朋友，完全就是这个德性。做 AI Agent 完全不关心软件的设计边界和 MCP Tool 的设计方法论，一问就是，哎呀，这个不行是大模型基座不行，和我有什么关系。
不是哥们，你们这样是做不成事情的。我们的目的是开发出可以帮助我们减少工作负担的智能体程序，不是让你练习 git clone 的。
大模型不知道自己不知道，这是大模型的幻觉，结果搁你们这儿，你们的幻觉不比大模型低呀！
真的，朋友们，AI 时代不要抛弃自己的大脑，多多像一个科班一样，学习 AI 技术的底层知识（别想了，我只是一个学生，lz 不卖课），我相信，这才是享受 大模型 技术红利，造福社会的途径。
最后给我最近做的 OpenMCP 打一个小广告，OpenMCP 是一个一体化的 MCP 开发与部署解决方案，官方站点
如果觉得好用，欢迎给我们点一个 star：LSTM-Kirigaya/openmcp-client
最近刚看过
