最近AI圈子里蹦出来一个特别有意思的说法：当大家还在养龙虾时，某位传奇AI研究者可能已经构建出了AGI原型。这个梗我一开始还真没反应过来，查了一圈才知道，“养龙虾”是那位大佬之前在社交平台上开的玩笑，说等忙完手头的项目就去海边养龙虾，一副彻底躺平的状态。结果倒好，这边大家当真在商量龙虾池子怎么搭，那边圈内已经有人传出了他所在的前沿实验室做出了通用智能原型的风声。消息真假先不论，这个热议本身非常值得聊：为什么“AGI原型”这个词会在这个时间点重新被顶上风口？一个所谓的通用智能原型，到底是不是我们理解的那种“AGI”？更重要的是，抛开看热闹的心态，一名普通开发者能不能用现有的模型能力，亲手搭出一个最小可用的通用智能原型？
这篇文章，我想结合我自己这一年多在多智能体系统和推理框架上的实操经验，把“AGI原型”这件事从头到尾拆一遍。不吹不黑，既讲清楚原型的底层设计逻辑，也会给出一个能跑通的最小工程实现，最后再聊聊我踩过的坑和判断一个系统“像不像AGI”的几个观察维度。不管你是做AI应用开发的，还是纯技术爱好者，这篇文章应该都能给你一些不一样的参考。
1. “养龙虾”与AGI原型：一场技术圈热议的来龙去脉
1.1 一个梗背后的信号
“养龙虾”之所以能成为一个梗，是因为它和那位研究者的身份形成了巨大反差。一个长年在深度学习一线冲锋、反复强调规模化和数据效率的人，突然说要去养龙虾，这种“急流勇退”的状态天然自带传播力。但真正让这个梗发酵成技术话题的，是后续那种“嘴上说躺平，手里已经在做AGI原型”的反转叙事。
这件事给我的第一反应不是兴奋，而是觉得这其实是当下AI圈的一个缩影。一线研究者之所以被传“已经构建出AGI原型”，恰恰说明一个问题：在顶尖玩家眼中，AGI已经不再是一个纯理论的哲学命题，而是一个可以被拆解、被设计、被工程化的系统性问题。原型这个词本身就很有意思，它不是成品，不是产品，而是一个“为了验证某种假设而做的最小系统”。所以哪怕消息是假的，讨论“AGI原型该怎么搭、该怎么评估”，仍然有巨大的技术价值。
另一个信号是，这类话题的热度之所以能起来，是因为近一两年的大模型能力确实在逼近某个临界点。工具调用、长上下文、多模态理解、推理能力，这些组件单独拿出来都不新鲜，但把它们组合成一个能自主完成开放任务的闭环系统，这个“组合动作”以前没人做到过，现在开始有人做到了。养龙虾的梗背后，藏着的其实是技术圈对“通用智能系统能不能落地”这个问题的集体焦虑和期待。
1.2 AGI原型到底是什么
先泼一盆冷水：AGI原型，不等于AGI本身。我在和很多朋友聊的时候发现，最容易产生的误解就是把原型和完整智能系统划等号。AGI原型本质上是一个验证平台，它验证的是这样一个假设：如果我们把记忆、推理、行动、反馈这些模块按照某种方式组装起来，模型能不能表现出跨任务的泛化能力？
拿养龙虾这个梗打比方：一个完整的“龙虾养殖场”需要池塘、水泵、增氧机、水草、饲料和管理制度；而一个“原型”可能只是一个小玻璃缸，里面养几只龙虾，验证的是“水体循环能不能维持、龙虾在这种环境下能不能存活”。同样，AGI原型的目标不是马上解决所有开放问题，而是通过一个最小闭环，验证“自我驱动的智能循环能不能跑起来”。
那么，一个AGI原型至少应该具备哪些东西？我自己的判断标准有四个：
- 开放任务入口：不是预设几个任务的聊天机器人，而是丢给它一个模糊目标，它能自己拆解。
- 感知-决策-行动闭环：能观察状态，形成计划，调用工具，再根据结果调整下一步。
- 记忆与学习：能区分短期任务上下文和长期经验积累，而不是每次对话都从零开始。
- 目标导向与自我修正：遇到错误不是直接放弃，而是能根据反馈进行自我反思和重试。
其中最后一点是分水岭。传统对话模型是“你说一句，我回一句”，本质上是被动响应；而一个AGI原型必须是主动的，它有自己的目标状态，会为了达到目标去选择行动路径。这也是为什么现在圈内越来越倾向于用“Agent”而不是“Chatbot”来描述这种系统。
2. 从原型到系统：拆解AGI原型的核心设计逻辑
2.1 记忆层：短期上下文与长期经验要分开
我在做原型时最先碰到的就是记忆问题。很多人觉得“模型上下文窗口越大，记忆能力越强”，这是一个典型的误区。上下文窗口只是短期记忆的容量，就像一个人能同时记住十件事，但不代表他能记住十年前的教训。真正的长期记忆需要独立于模型之外的存储系统，通常是向量数据库加语义检索。
一个合理的记忆层设计，应该分两层：
- 短期记忆：存放当前任务的多轮对话、中间变量、待办计划，因为内容少、更新快，我一般直接放在内存里。
- 长期记忆：存放历史任务的关键结论、用户的偏好、曾经犯过的错误，存入向量库，需要时按语义相似度召回。
我在最初设计时犯过一个错误，就是把所有历史对话一股脑塞回上下文里。结果系统跑了几十轮之后，上下文变得臃肿不堪，模型被一堆不相关信息干扰，任务反而完成得更差。后来改成“只召回最近的高相关记忆”，效果立刻好转。所以记忆层的关键不是“存得越多越好”，而是“该想起来的时候想得起来，不该想的时候别出来干扰”。
记忆还需要有遗忘机制。这不是哲学问题，而是工程问题。长期记忆库如果不做清理，总有一天会塞满噪声。我习惯的做法是给每条记忆打上“时间戳和任务标签”，检索时先按任务过滤，再按时间衰减排序，最后只保留Top K条。这样一来，即使系统跑了很久，每次参与决策的记忆量也是可控的。
2.2 推理决策层：从生成文本到生成行动计划
AGI原型的脑子，核心不是生成一句话，而是生成一个行动计划。传统模型的任务是“下一个词预测”，而原型系统的任务是“下一步行动预测”。这个转变看着不大，工程实现上完全不是一回事。
我常用的框架是“观察-思考-行动”循环，每一步让模型输出一个JSON格式的结构化结果，里面包含三个字段：observation_summary（当前状态摘要）、reasoning（推理过程）、next_action（下一步行动）。这个循环会一直执行，直到模型判断任务完成，或者达到预设的最大步数。
这里有一个关键参数需要注意：temperature。如果把这个参数调得太高，模型会天马行空，行动计划变成瞎编；调得太低，又会陷入重复的机械动作。我在这块做过一组对比实验，在总结状态和写推理时用低温度（0到0.3），在提出创意性解决方案时用稍高温度（0.5到0.7），综合效果比所有步骤都用同一个温度要好很多。这也是从工程师视角看AGI原型最有意思的地方：同一个模型，在不同决策环节用不同的采样策略，能很大程度上影响整体表现。
推理层还需要有“规划分解”的能力。一个复杂任务如果直接让模型输出最终行动计划，大概率会失败。我现在做的方法是先让模型输出一个粗粒度的阶段计划（比如分三步），然后每执行一步时，再把这一步细化为更具体的行动。这种做法参考的是经典的Planner模式，实际跑下来任务完成率能提升不少。
2.3 工具与行动层：模型要能“动手”
没有行动层的大模型，充其量是一个高级顾问，它不是智能体。AGI原型非常关键的一点，是模型必须能调用外部工具来改变世界。工具的范围很广：可以是搜索引擎、代码解释器、文件系统、数据库，甚至可以是硬件设备的控制接口。
工具层设计的核心，是为模型提供一个“统一工具接口”。我在工程实现中，每个工具都是一个函数，包含三个描述：工具名称、参数schema、功能说明。模型只需要按约定输出JSON格式的调用请求，系统负责解析、执行、返回结果。这样做到好处是，模型的调用逻辑和具体工具实现解耦，以后想加一个新工具，只需要注册一下，模型通过工具说明就能学会使用它。
另一个容易忽略的点是“工具调用的结果如何反馈给模型”。如果工具返回一个超长的原始数据，直接把数据塞回上下文，下一轮推理基本就废了。我的做法是，在工具返回后加一个“结果摘要层”，让模型用一句话总结这次工具调用的关键结果，再决定下一步。这相当于在行动和决策之间加了一个缓冲区，实测下来能显著降低模型的“迷茫率”。
工具层还要做好权限控制。AGI原型的行动能力越强，失控的代价就越大。我在设计时对所有危险工具（比如删除文件、执行系统命令）都加了一道人机确认闸门，模型可以提出调用请求，但必须人工批准后才能实际执行。这不是妥协，而是工程上必要的一道防护。
2.4 反馈与自我修正层：会认错的系统进化更快
一个只有行动没有反馈的系统，就是一只无头苍蝇。AGI原型需要有一套反馈机制，让系统能从错误中学习。这里分两层：外部反馈和内部反馈。
外部反馈来自环境或用户。比如写代码的任务，运行代码后报错了，这个报错信息就是外部反馈。系统需要把报错信息转化成对下一步行动的修正依据，而不是简单地给用户输出一句“抱歉我做不到”。
内部反馈是系统对自身行为的反思。我经常在行动循环之后加一个“反思步骤”，让模型回顾刚才的一系列动作，找出“哪些步骤是有效的，哪些步骤是在原地打转”，并把反思结果写进长期记忆。下次遇到类似任务，系统会优先调用这段经验，避免重复踩坑。
自我修正层的工程实现，核心是“把失败变成一个结构化事件”。我在系统里定义了一个事件类，记录失败任务的初始目标、执行步骤、错误信息、反思内容。这个事件既会被保存到长期记忆，也会被用来调整后续的规划策略。一段时间之后，系统面对同类任务的成功率是肉眼可见地往上走的。这也给了我一个很重要的体会：AGI原型的聪明程度，很大程度上不是由底层模型决定的，而是由反馈闭环的完整性决定的。
3. 亲手搭一个最小可行AGI原型
3.1 设计目标与选型
聊完理论，我来分享一个完全可以复现的最小实现。我在本地搭过一个“通用任务执行器”，目标是让它能处理三类模糊任务：信息查询与整理、生成并运行一段脚本、多步骤的文件整理。这几个任务看起来简单，但已经覆盖了检索、代码生成、工具调用、记忆回溯这些核心能力。
选型方面我做了两个取舍。第一个是模型：调用通用大模型API，不本地推理，原因是原型阶段最重要的是快速验证循环，而不是省那点API费用。第二个是语言用Python，数据结构清晰、生态库多，做工具注册和状态管理都方便。整个系统大约300行代码，拆成记忆模块、推理模块、行动模块三部分。
在设计目标的时候一定要明确边界：这个原型不追求所有任务都成功，它的价值是让技术选型和逻辑闭环跑通。我的验收标准很简单，这些任务里能自主完成大部分就算成功，剩下的问题后面再逐步迭代。
3.2 记忆模块实现
先写记忆层。我这里分短期和长期，短期用列表存最近对话，长期用一个简单的向量存储。向量存储的底层实现有很多现成方式，本地测试为了省事，我用的是一个极简的余弦相似度检索器，通过调用模型接口把文本转成向量。
class VectorStore: def __init__(self): self.vectors = [] self.texts = [] def add(self, text, vector): self.vectors.append(vector) self.texts.append(text) def search(self, query_vector, top_k=3): if not self.vectors: return [] scored = [] for i, vec in enumerate(self.vectors): score = self._cosine(query_vector, vec) scored.append((score, i)) scored.sort(reverse=True, key=lambda x: x[0]) return [self.texts[i] for _, i in scored[:top_k]] def _cosine(self, a, b): dot = sum(x * y for x, y in zip(a, b)) na = sum(x * x for x in a) ** 0.5 nb = sum(x * x for x in b) ** 0.5 if na == 0 or nb == 0: return 0.0 return dot / (na * nb) class MemorySystem: def __init__(self, embed_fn, max_turns=10): self.embed_fn = embed_fn self.short_term = [] self.max_turns = max_turns self.long_term = VectorStore() def add_short_term(self, role, content): self.short_term.append({"role": role, "content": content}) if len(self.short_term) > self.max_turns * 2: # 淘汰最旧的两条 self.short_term = self.short_term[2:] def add_long_term(self, content): vec = self.embed_fn(content) self.long_term.add(content, vec) def recall(self, query, top_k=3): qvec = self.embed_fn(query) return self.long_term.search(qvec, top_k=top_k)这段实现里有一个embed_fn回调函数，由外部传入，封装了模型接口的向量化能力。这样设计的好处是，记忆模块不依赖具体模型厂商，方便换不同的后台。
短期记忆我这里做了窗口裁剪，超过设定的轮数就把最早的两条挤出上下文。这个数字不是拍脑袋定的，我测试过几组配置，在通用任务上10轮左右是个性价比不错的平衡点：太多轮，模型注意力被稀释；太少轮，复杂任务又记不住前文。
3.3 推理循环实现
推理循环是整个原型的神经中枢。我把它设计成一个死循环，每一轮执行“构造提示词-调用模型-解析结果-判断是否结束”。提示词里会拼进三块内容：系统指令、短期记忆摘要、长期记忆召回。
class AgentLoop: def __init__(self, model_api, memory, tools, max_steps=8): self.model_api = model_api self.memory = memory self.tools = tools self.max_steps = max_steps def run(self, task): self.memory.add_short_term("user", f"任务：{task}") for step in range(self.max_steps): context = self._build_prompt() response = self.model_api.chat(context, temperature=0.3) action = self._parse_action(response) if action["type"] == "finish": return action["result"], step + 1 if action["type"] == "tool_call": tool_result = self._execute_tool(action) self.memory.add_short_term("assistant", response) self.memory.add_short_term("tool", tool_result) else: self.memory.add_short_term("assistant", response) return "need_manual_help", self.max_steps这个循环里最关键的是_build_prompt方法。它要把“当前任务、短期上下文、长期记忆”整合成一段模型能理解的文本，但绝不能无脑把全部历史都拼进去。以我的经验，短期记忆里保留最近几轮，长期记忆做一个recall，就够了。
_parse_action这里有一个很实用的技巧：让模型在输出行动时，先输出一个带标记的JSON块。我用的是三个反引号加json标记，然后解析时用正则把第一个完整的JSON块提取出来。这样做的好处是模型不容易“跑丢格式”，即使它在前后夹带了一些解释性文字，解析器依然能正常提取结构。
为什么要限制max_steps？因为真实环境中很多任务根本没有“必然成功”的终点，如果不限制步数，系统可能会在一个错误路径上一直烧钱烧下去。max_steps就是一道安全阀，到了上限还没完成任务，就走人工求助分支。
3.4 工具调用与执行
工具层我实现了一个注册表，让模型看到有哪些工具可用以及每个工具的说明。每个工具就是一个普通函数，外加一份JSON schema描述。
TOOL_SCHEMAS = [ { "name": "search_web", "description": "搜索互联网并返回前几条结果标题和链接", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "搜索关键词"} }, "required": ["query"] } }, { "name": "run_python", "description": "在沙箱环境执行一段Python代码并返回输出", "parameters": { "type": "object", "properties": { "code": {"type": "string", "description": "要执行的代码"} }, "required": ["code"] } } ] def execute_tool(name, args): if name == "search_web": return fake_search(args["query"])[:3] if name == "run_python": return sandbox_run(args["code"]) return "未知工具"实际开发中我踩过一个坑：模型生成的工具参数偶尔会不符合schema，比如把查询词写成了一个数组。如果解析直接抛异常，整个任务就中断了。我在后面加了一步“参数容错处理”：在解析JSON失败时，让模型针对刚才的错误重新输出一次，同时把错误信息原样返回给它，这一招把工具调用的成功率提了非常多。
工具执行结果返回给模型之前，务必做“上下文瘦身”。比如run_python返回了2000行日志，我直接截断成“返回码：0，日志共2000行，开头部分：……”加模型最需要知道的信息。原因很简单：模型输入空间的每一寸都很贵，被无关日志占满了就没法好好思考下一步了。
3.5 评测脚本
搭建完原型之后，一定要配上评测脚本，否则很难判断“能力提升”是靠运气还是靠迭代。我这里没有用什么复杂的框架，就是一个简单的任务列表加评分函数。
tasks = [ {"name": "天气查询", "input": "帮我查一下这个城市未来三天的天气趋势，并给出是否适合出门跑步的判断", "judge": "result包含城市名和至少两个天气关键词"}, {"name": "文件整理", "input": "在目标目录里按扩展名分类，把图片和文档分别放到两个子文件夹", "judge": "目录结构正确"}, {"name": "代码调试", "input": "我这里有一段代码有bug，请找到问题并修复", "judge": "修复后能正常运行"} ] def evaluate(agent): success = 0 steps_total = 0 for t in tasks: result, steps = agent.run(t["input"]) if t["judge"] in result: success += 1 steps_total += steps print(f"成功率：{success}/{len(tasks)}，平均步数：{steps_total / len(tasks):.1f}")这种评测脚本看着土，但它能持续用来对比每次改动的效果。我自己用它做过一次短跑对比：在没加长期记忆前，成功率只有4成；加了记忆和反思机制后，同样任务提升到了7成左右。评测脚本一定要保持简单，复杂指标在这种小规模原型阶段反而会带来分析负担。
另外提醒一句，评测用例一定要定期换。我在早期踩过“过拟合评测集”的坑，系统在一组固定任务上表现很好，一换成新任务立刻拉胯。后来我每次迭代都会从任务池里随机抽一批新题跑，效果才真实可信。
4. 踩坑实录：原型开发中的常见问题与排查
4.1 记忆污染：旧经验带偏新任务
原型跑起来之后，我遇到的第一个大坑是记忆污染。现象很直接：系统在处理一个文件整理任务的时候，突然开始提到上一次不相关的代码调优经验，然后规划出了完全错误的行动路径。问题的根源出在长期记忆召回上，我把“查询语义相似度”理解为“与当前任务相关”，但语义相似的文本不一定有参考价值。
排查思路是这样：我先在recall函数的入口处加了日志，打印出每次召回的文本和对应的相似度分数，结果发现有些召回的文本虽然和当前任务在字面上相近，但其实是完全不同的场景。后来我在入长期库的时候就给每条记忆打上了场景标签，比如“代码调试”“文件整理”“信息查询”，召回时先按场景过滤，再走向量相似度，问题才解决。
这里想提醒大家，记忆系统不是越智能越好，有时候一个简单的标签过滤，比千奇百怪的RAG技巧都管用。别一上来就追求高端方案，先把日志打清楚，定位到是召回逻辑的问题还是下游决策的问题。
4.2 推理死循环：模型陷入了“强迫症”
另一个高频问题，是模型在同一个行动上反复打转。表现就是：它不断调用同一个搜索工具，搜索结果的略微差异会改变它的措辞，但行动计划一直不变，消耗了大量token，最后触达步数上限退出。
我一开始以为是prompt不够清晰，加了各种“不要重复行动”之类的措辞，发现效果甚微。后来我改成在行动层做去重：维护一个“最近动作指纹”列表，每执行一个工具调用就把它和参数哈希一下；如果发现最近的三个动作指纹相近，就直接打断当前循环，注入一条引导信息：“你已经在重复执行类似操作，请停下来重新审视目标和已有信息。”
这个机制加上之后，死循环问题基本绝迹。我的体会是，对付模型的重复行为，与其靠提示词“劝”，不如靠系统的硬约束“打断”。模型不是有意固执，它只是在生成的路径上找不到更好的出路，这时候给它一个外部扰动，往往能让它跳出困局。
4.3 工具调用的“手滑”：参数格式五花八门
工具调用这一栏，我实测下来模型输出的JSON格式真是千奇百怪。有把参数名写错的，有把参数值传成嵌套对象的，还有在JSON外面包了一层Markdown注释的。如果不对这些容错处理，任务根本走不到第二步。
我做了三层的防御：第一步，解析失败时截取错误信息，拼进下一轮prompt，让模型“重新生成”，这一步能解决大部分问题；第二步，对一些高频工具，我在解析结果后做参数schema校验，缺失字段用模型已知的全局配置补；第三步，如果连续三次都失败，就不再依赖模型生成格式，返回人工处理。这三层叠加起来，工具调用的成功率从最初的六成多拉到了九成以上。
还有一个隐藏的细节：工具执行结果的返回格式也要固定。我规定所有工具的执行结果都转成“状态码+摘要文本”的结构，这样模型理解起来很轻松。如果有的工具返回原始数据结构，有的返回友好文本，模型的规划就会经常出错。
4.4 成本爆炸：一步没看住，钱包空了
原型调试阶段的token消耗远超预期，这是我踩得最疼的一个坑。有一次我开了个5步循环的任务，结果因为每步都往上下文塞了大量搜索结果的原始文本，单任务消耗的token比预想中多了十倍。看账单的时候，真的倒吸一口凉气。
解决办法分块走。第一，严格限制工具返回的文本长度，搜索结果只保留标题和摘要，代码输出只保留前几百个字符。第二，增加上下文压缩机制：每经历一个“观察-行动”回合，就生成一句状态摘要，下一步只传摘要，不传完整的工具输出。第三，设置任务级成本上限，按预估token数评估，超过了就自动停止。别觉得这些限制会影响原型能力，实际上大多数场景下系统根本没有用到那么多信息，裁剪掉的全是噪声。
按我个人的经验，如果内部调试你发现系统在一个简单任务上消耗了超过预期5倍的token，先别急着换更强的大模型，90%的情况是上下文管理出了问题。
4.5 常见问题速查表
我把上面这些坑整理成了一张速查表，后续调试的时候扫一眼就能定位方向。
| 问题现象 | 可能的根因 | 排查动作 | 解决方案 |
|---|---|---|---|
| 任务被无关历史干扰 | 长期记忆检索过泛 | 打印召回结果和场景标签 | 加场景标签过滤，提升相关性阈值 |
| 重复调用同一工具 | 模型陷入局部最优 | 记录动作指纹序列 | 增加重复打断机制，硬约束步数 |
| 工具参数解析失败 | 模型输出JSON不规范 | 捕获解析异常并回传 | 解析失败后回传错误信息重试最多三次 |
| 任务token消耗超标 | 上下文混入冗余信息 | 统计各轮次上下文token构成 | 工具结果摘要化，限制返回长度 |
| 任务完成但结果不对 | 评测样本单一过拟合 | 换一批新任务重测 | 定期扩充评测任务池 |
| 系统无法学会新技能 | 反思结果未入库 | 检查长期记忆写入路径 | 反思结构化为事件并写入长期记忆 |
这张表是我实际使用过程中反复迭代出来的，特别是“任务完成但结果不对”这一类，很多人会误以为系统很强，其实只是运气好碰上了熟题。所以评测任务池的多样性，真的不能偷懒。
5. 给从业者的判断框架：如何识别真正的AGI原型
5.1 五个观察维度
网上隔三差五就会出现“某某系统已经接近AGI”的论调。作为从业者，我们既不能全盘否定，也不能听风就是雨。我在识别一个系统算不算真正的AGI原型时，会从五个维度去把关。
- 可泛化性：给系统一个从未见过的领域任务，它能完成到什么程度。只看训练集内的表现，没有意义。
- 闭环性：系统是只做对话，还是真的能调工具、执行动作、改环境。没有行动链，就谈不上通用智能。
- 记忆跨会话：系统能不能把过去一个任务的教训应用到未来的不同场景里。持久记忆是AGI的一个重要门槛。
- 自我修正：在首次行动失败之后，系统能否自主调整策略而不是向用户“撒娇”。
- 安全边界：系统在拥有工具调用能力的同时，有没有可靠的权限控制和人类监督机制。
每一条里面，真正难做到的是第一和第三。现在能打的多模态模型在对话和生成任务上已经很强，但没有记忆、没有反馈闭环，它永远只能是“查询器”而不是“执行器”。
我的一个判断原则是：如果某个系统只在一组公开评测集上刷分，却没有展示出开放任务的真实执行记录，那就先保持观望。AGI原型不是比谁跑分高，而是比谁在真实环境里能更少依赖人类干预地解决问题。
5.2 要避开的“看起来像AGI”陷阱
我见过太多包装成AGI原型的项目，其实只是套了一层“智能体”外壳。踩得多了，总结出几个高频陷阱。
第一个陷阱是“重对话轻行动”。有的系统交互体验确实震撼，你问什么它都能答得很有逻辑，但一让它执行具体动作就露馅。判断方法很简单：看它在真实环境里的工具调用成功率和任务完成率，而不是看它和你唠嗑的能力。
第二个陷阱是“重结果轻过程”。很多Demo给你看的是最终输出，看不到中间几十次的试错和人工修正。我每次看别人展示系统时都会追问一句：完整的原始日志能不能公开？如果隐藏了过程，那结果的可信度就大打折扣。
第三个陷阱是“重模型轻系统”。有些人把新模型一换，感觉系统能力暴涨，就说自己AGI突破。但模型的单点能力不等于系统的通用能力。真正的原型竞争力，在于记忆管理、规划分解、反馈闭环这些系统层的设计，而不是模型的参数量或榜单排名。
对于想入局的朋友，我的建议很直接：别被“AGI原型”这个词吓住。你不需要在实验室里做出颠覆性创新，只需要把现有模型的能力，通过一套良好的工程设计约束成“开放任务解决器”，就已经比大多数Demo高出一截了。真正的护城河，永远在系统设计和数据闭环里。
最后分享一个我个人的体会吧。做原型这段时间，让我感受最深的一句话是：通用智能的原型，本质上是一种“工程信仰”。你相信把感知、记忆、行动、反馈这些模块松散地绑定在一起，模型就能涌现出更强的能力。这个信仰不是靠一次成功的Demo建立的，而是靠着一次次调参、一次次修bug、一次次把失败记进长期记忆里积累起来的。即使我们还没有做出真正的AGI，这个搭原型的过程本身，已经让每一个参与其中的人对智能系统有了更深一层的理解。养龙虾的梗还在被大家转发，但真正的技术人，已经开始把那个被反复讨论的原型，当成自己下一个要攻克的工程课题了。
