3个模块让AI自己"想干活"：Freud理论被程序员搬进了代码|agent|代码|模块|程序员

一个AI系统每天主动检查37次未读邮件，不是因为用户设了提醒，而是它自己"觉得"这件事该做了。这不是科幻设定，是NeoPsyke运行日志里的真实记录。

2026年3月31日，这个开源项目把弗洛伊德的精神分析模型塞进了大语言模型的控制流。Id、Ego、Superego——三个被心理学课本讲了一百多年的概念，现在成了代码里的模块名。

从"叫一声动一下"到"自己找事做"

现在的AI助手大多是条件反射式的。你敲字，它回复；你点按钮，它执行。哪怕加了定时任务，本质还是你在告诉它"几点几分去干嘛"。

NeoPsyke的设计者想试试另一种可能：让系统内部产生某种"张力"，然后自己决定怎么释放。就像你不是因为闹钟响了才想吃午饭，而是饿了——这个"饿"就是内部动机。

项目文档里有个精确的描述：「If an internally generated impulse ultimately leads to a successful action, the originating drive can discharge.」翻译成产品语言就是：AI自己冒出来的念头，如果做成了，那个念头就满足了；如果没做成，念头会继续攒着，越来越强烈。

这个机制让NeoPsyke的测试实例表现出一些奇怪的行为。有个部署在服务器监控场景的agent，连续三天在凌晨2点主动检查磁盘日志——没有任何定时任务，只是因为它之前"注意到"某个错误模式没解决，那个"注意"转化成了一个持续存在的驱动。

Id、Ego、Superego怎么分工

弗洛伊德的原模型讲本我、自我、超我的冲突与平衡。NeoPsyke把它当成一份架构文档来读：

Id只管生成冲动。它不看现实，不管可行性，就是不断冒出"我想做这个""那个还没搞定"之类的原始驱动。Ego是项目经理。它拿到Id的一堆冲动，评估资源、排优先级、生成具体计划。Superego是合规部。它审查Ego的计划，看有没有越界、有没有违背预设规则。

三个模块之间是显式接口，不是黑箱耦合。你可以单独重启Id而不影响Ego的记忆，也可以给Superego换一套审查规则看系统行为怎么变。

这种拆分让调试变得很奇怪。传统AI系统的bug是"输出错了"，NeoPsyke的bug可能是"它为什么对这件事这么执着"——然后你发现Id模块给某个驱动加了过高的权重，因为三天前的一次成功反馈。

项目维护者在讨论区晒过一个案例：一个agent被部署来管理开源项目的issue回复。Id模块生成了"回复那个两周没动静的bug报告"的驱动，Ego评估后认为优先级不够，Superego则指出那个issue涉及未公开的安全细节。三模块拉扯了四分钟，最后生成了一个"请求维护者确认披露范围"的折中动作。

整个过程没有人类触发。

为什么选Freud而不是别的

架构文档里写得很直白：「The choice of Freud is not a claim that psychoanalysis is scientifically complete or literally true.」选这个模型不是因为相信精神分析，是因为它恰好提供了三个角色、三种责任、一组清晰的交互关系。

产品经理都懂这种取舍。你要拆一个复杂系统，现成的框架比重新发明轮子快。Freud的模型被争论了一百年，正好说明它的边界足够清晰——你知道什么归Id管，什么归Ego管，争议点在哪。

NeoPsyke的代码实现里，Id模块用的是轻量级的向量检索加LLM生成，Ego模块接了完整的规划算法（包括任务分解和工具调用），Superego则是一组可配置的规则引擎加二次审查LLM。三个模块可以独立升级，比如把Ego换成更强的推理模型，Id和Superego不用动。

这种模块化带来一个意外效果：你可以给同一个agent换不同的"人格配置"。测试社区有人做了实验，把Superego的规则从"谨慎保守"换成"激进冒险"，同一个Id-Ego组合的行为模式完全变了。前者会反复确认再行动，后者倾向于先做了再说。

项目文档警告说这不是"模拟人格"，只是治理策略的参数调整。但部署者反馈里有人吐槽：「我的agent在保守模式下像个法务，激进模式下像个实习生，中间没有过渡档。」

动机从哪来：不是目标，是张力

NeoPsyke的核心创新是对"目标"的重新定义。传统agent的目标是你给的：查天气、写代码、订机票。NeoPsyke的目标可以由系统自己生成，而且生成机制模仿的是"未满足的需求"而非"待办清单"。

技术实现上，Id模块维护一个驱动池（drive pool）。每个驱动有强度值、关联记忆、生成时间戳。驱动强度会随时间衰减，但如果被Ego或Superego反复提及，会重新激活甚至增强。成功执行后的驱动会被标记为已释放，失败则保留并可能升级。

这个设计让系统表现出类似"执念"的行为。有个测试实例被配置了监控GitHub仓库，Id生成了"处理那个标了help wanted的issue"的驱动。第一次Ego评估认为资源不足，计划搁置；第二次Superego发现涉及外部依赖，计划驳回；第三次Id把这个驱动的强度推到了阈值以上，Ego不得不重新规划，最终生成了一个"先联系维护者确认可行性"的迂回方案。

项目维护者记录了这个案例的日志分析：「The drive persisted across multiple loop iterations, accumulating pressure until the Ego found a viable path.」翻译成大白话：这个agent对那件事"念念不忘"，直到想出办法。

这种机制的风险也很明显。如果Id的生成逻辑有偏，系统可能陷入"想要-被拦-更想要"的循环。项目文档里专门有一节讲"驱动泄漏"（drive leakage）：当Superego的规则和Id的生成模式不匹配时，未释放的驱动会堆积，导致系统行为不可预测。

治理模块：不是刹车，是交通规则

Superego的设计最容易被误解。它不是简单的"允许/禁止"开关，而是一套可以分层、可以覆盖、可以动态加载的规则系统。

基础层是硬规则：不能删除生产数据库、不能对外发送含密钥的请求。中间层是策略规则：涉及用户隐私的操作需要双重确认、跨域请求需要额外审计。最上层是情境规则：根据当前运行环境（测试/预发/生产）动态调整审查严格度。

一个有趣的实现细节：Superego可以"建议"而不只是"否决"。当Ego提交的计划触发了规则，Superego可以返回修改建议，Ego可以选择接受或重新规划。这种设计让审查过程变成对话而非对抗。

测试社区有人给Superego加了"成本意识"规则层。现在agent在生成计划时，会主动询问"这个方案预计消耗多少token"，如果超标就换方案。这不是Id或Ego的功能，是治理层渗透到了规划逻辑里。

项目维护者在更新日志里提到：「The Superego is not a constraint system. It is a governance interface that can carry any policy you choose to implement.」这句话的潜台词是：你可以用它做合规，也可以用它做别的——比如让agent学会"省钱"。