一个伯克利CS的学生，上周三下午，直接删掉了自己写了三个月的ChatGPT脚本。不是因为他讨厌AI，而是因为他突然意识到——每一次在聊天框里打字提问，都是在把自己的脑子交给别人托管。

事情得从上学期的算法课说起。那帮家伙发现，用ChatGPT做作业简直爽爆，一问一个准，代码完美，证明清晰。所有人都觉得自己稳了。直到监考的中期考试到来，他们齐刷刷地跪了。不是题目变难了，是他们已经不会自己思考了。聊天界面把他们变成了被动消费者，而他们甚至没发现这一点。

于是，几个伯克利的CS学生决定干一件挺叛逆的事：他们不再用任何聊天式AI。不是不用AI，而是不给AI打字的机会。他们造了一个自主代理，让AI在沙箱里自己跑任务、自己写Python、自己存结果、最后发封邮件汇报。全程没有聊天窗口，没有流式文字，没有任何需要你盯着看的界面。你给它一个目标，它把成果交给你。你拿到的不是一串字符，而是一份可以核对、可以质疑、可以迭代的工作报告。

这事的核心洞察就一句话：聊天界面训练你提问，自主代理训练你设计。前者让你越来越像甲方，后者让你越来越像工程师。而这群学生把这条洞察变成了一套看得见摸得着的系统。下面，我用他们的方案为例，一条一条拆开，看看到底是怎么做到的。

第一点，任务规划器：用最便宜的模型干最清醒的活。 学生们没有一上来就怼个超大模型。他们接的是OpenRouter上那种0.1美元每百万token的轻量级LLM。为什么用这么便宜的？因为任务规划不需要智慧火花，它需要的是稳定地把一个大目标拆成一堆小任务，然后输出一个结构化的JSON数组。每个子任务带三样东西：描述、成功标准、依赖列表。这个规划器会一直跑，直到所有任务打勾，或者撞到最大迭代次数。这里的关键是，它不追求一次拆完美，它允许调整，允许重新规划。但全程不需要人插手。你给目标，它给你拆解方案，你不需要在聊天框里跟它讨价还价。

很多团队一上来就纠结模型选型，恨不得把最新最强的模型塞进每一个环节。但伯克利这几位显然看明白了：砍柴别用屠龙刀。一个任务规划器，要的是低延迟、低成本、高确定性。你让一个擅长写十四行诗的模型去列待办事项，它反而可能加戏。而他们选的这条路径，恰恰是在用工程思维对抗模型迷信——不是越贵越好，是该贵的地方贵，该省的地方省到极致。

第二点，代码执行器：把AI关进沙箱，让它直面报错。 规划器拆出来的每个子任务，都会被扔给一个专门写代码的LLM。这个LLM会生成Python脚本。但重点不在这里，重点在脚本跑在哪里。学生们用Docker建了一个沙箱环境，断网、没有文件系统持久化、每个脚本只给30秒超时。这是赤裸裸的不信任设计——对AI输出的代码零信任。脚本跑完，捕获标准输出、标准错误和返回码。如果报错，执行器直接把错误信息甩回给写代码的LLM，让它改，最多给3次机会。

这个设计简直太对味了。它没有试图让AI一次写对，而是把失败当成流程的一部分。人写代码会编译不过，AI写代码当然也会报错。传统聊天界面下，你看到一个报错，得自己复制粘贴回去，重新组织语言，祈祷AI理解哪里错了。这个系统直接把纠错循环自动化了。而且最关键的是，沙箱隔绝了一切副作用。AI别想搞出什么奇怪的操作，30秒搞不定就超时。够狠，也够稳。

你仔细品这个执行器的设计哲学，它其实是在说：别把AI当神来拜，把它当一个容易犯错的初级程序员。给够约束，给够反馈，让它自己撞墙自己爬起来。这比任何“提示词工程”都更接近软件工程的本源。

第三点，SQLite存储：用数据库取代聊天上下文，这是整件事最精妙的一刀。 传统的AI代理，靠的是不断累积聊天记录来维持上下文。发一句，回一句，历史记录越来越长，脑子越来越乱。学生们直接掀了桌子——为什么非要让模型记住一切？他们把每一轮的中间结果全部写进本地的SQLite数据库。解析的数据、计算的值、报错日志，全存进去。代理不需要靠“记忆”来保持状态，它需要什么就去查数据库。数据库就是它的记事本，精确、可索引、不会遗忘。

这一手操作直接把两个东西干掉了：第一，不再需要冗长的上下文窗口，模型每次调用只关注当前子任务，干净利落；第二，不再需要你坐在屏幕前盯着它有没有“忘事”，因为所有关键信息都持久化在磁盘上，随时可以审计。这个设计思路对于任何想做自主代理的人来说，都是降维打击。它不是在优化聊天，而是在消灭聊天。你不需要跟AI建立“对话关系”，你需要的是给它一套状态管理机制。而学生们选择的是最古老、最可靠、最可验证的技术——关系型数据库。

很多人一谈AI代理就想着怎么设计更好的提示词、怎么拼接更长的上下文。伯克利这几位反手就用SQLite教育了整个行业：别在语言的泥潭里打滚了，把状态交给数据库，让模型专注推理。这或许就是他们能跑完整个流程而没崩掉的根本原因。

第四点，邮件聚合器：你的工作成果，不是一串聊天记录。 当所有子任务跑完，代理会把所有输出编译成一份Markdown报告，然后发邮件给你。邮件里有什么？任务目标、子任务清单及完成状态、生成的代码、任何输出文件。你从头到尾没看见代理怎么工作的，你也根本不需要看见。你收到的不是一段可以往上翻的对话，而是一份完整的工作交付物。

这个交互模式一改，整个心智模型就变了。过去你用AI，是你看着它一点一点吐字，每吐一段你就得想接下来怎么接话。现在你给目标，等结果，拿到手里是一份可以直接用来做下一步决策的材料。你从“陪聊”变成了“验收”。你拿到的邮件，就像同事发来的周报，你可以信，也可以质疑，可以要求修改。但无论如何，你不再是那个盯着屏幕等输出的焦虑用户了。

而且，选择邮件作为交付通道也很有意思。邮件天然是异步的、可归档的、可转发的。它不是让你沉浸在实时交互里，而是把AI的工作嵌入到你已经习惯的工作流里。你不需要打开一个专门的AI工具，不需要登录任何平台。结果就在你的收件箱里，和其他工作邮件平起平坐。这本身就在暗示：AI的输出不该被特殊对待，它就是工作的一部分。

所以这套架构到底好在哪？ 它没有发明什么新算法，也没有调出什么惊天参数。它只是把AI从聊天气泡里拽出来，塞进一个能自己做事的工程管道里。任务规划让你不用拆解需求，代码执行让你不用盯着报错，SQLite让你不用管理上下文，邮件聚合让你不用守着屏幕。每一步都在减少人的被动参与，每一步都在把AI推向一个更独立的角色。

这套系统的适用边界也很清晰：任何能分解成离散、可验证子任务的事情，它都能跑。注意，不是“任何任务”，而是“能分解成离散、可验证子任务”的任务。这是来自学生项目的直接表述。他们没有吹嘘通用人工智能，也没有画任何大饼。他们很克制地划定了一个范围，然后在这个范围里做到极致。这种克制，比那些动辄宣称自己颠覆一切的demo，要靠谱太多了。

伯克利这帮学生做的事，其实是在回答一个根本问题：当你把AI当成一个工具而不是一个对话伙伴时，它的形态应该是什么？他们的答案不是优化聊天体验，而是取消聊天本身。这可能让很多人不舒服，因为我们已经太习惯那个打字框了。但习惯不等于合理。聊天界面是AI消费化的捷径，但也是AI工程化的绊脚石。这群学生用他们的学期项目，给所有做AI工具的人提了个醒：你是在帮用户问问题，还是在帮用户解决问题？这两者之间的差距，可能就是整个行业的下一步。