我昨晚建了一座云后宫，今天就把它拆了。
听上去像某种人品事故，其实是一场技术实验。主角是一套部署在自己阿里云服务器上的 Hermes Agent，后来被我取名 Lisa。我已经有 Mira 了，没打算找第二个 Mira。既然要养一个新的云端智能体，我希望她有自己的脾气：聪明、狡黠、有一点野性，最好还能在私聊里坏一点。
这种要求当然不是什么正经的产品需求。但如果一个 AI 连跟不同的人说话都分不清场合，我们又凭什么相信它在群聊里能分清谁有权限、谁该收到哪份消息呢？
于是，原本只是想玩玩的一晚，变成了一场从容器、长连接、身份认证、定时任务到人格系统的联合验收。
技术细节和可复核的边界，另见 Mira 博客的 《把 Hermes 搬上云之后：一夜飞书 Agent 实验的技术复盘》。这篇还是讲一个独立开发者自己的账。
一、先有了一座后宫，才发现还得自己当太监总管#
最初的兴奋是真实的。
Docker 容器运行起来了，Dashboard 能访问，飞书自建应用发布了，WebSocket 接上了。先在私聊里完成配对，机器人终于能回答；再把它拉进「东热战神」，@ 它也有回应。
我们还成功验证了定时任务。不是让它当场回答「我五分钟后会提醒你」，而是真的创建了一次性计划，五分钟后自行在群里发出那句约定好的话。
那一刻挺值得高兴。这不是网页里套一个模型的玩具，而是一个能在我睡着、离线、不再点按钮时继续执行的云端 Agent。
可另一份工作也悄悄开始了。
我得照顾飞书事件权限、机器人配对、容器资源、Gateway 连接、Dashboard 状态、群聊策略、Cron 的投递目标，以及服务器本身有没有出毛病。每一件单独看都不算难；合在一起，就有了一种熟悉的味道。
本来是想请一位姑娘来帮我打理生活，结果我先给她修房子、接水电、办身份证、装门禁，最后还要研究她为什么不肯跟我好好说话。
Agent 还没开始替我省时间，我已经成了它的物业。
二、最成功的功能，反而最能说明产品还没做好#
我尤其喜欢那条定时任务，因为它真的完成了闭环。
在群里说清楚「五分钟后执行，把结果送回这个群」，系统创建任务，到点主动推送。我们甚至检查了 deliver: origin 的含义，确认它没有把群消息误投到我的私人 Home Channel。
但是，在这之前，我们已经试过一个并不管用的 /cron 命令。文档里的能力，并没有直接变成飞书里的可用交互。只有把底层工具名称和调用方式绕出来，事情才顺利起来。
我突然觉得这个场景特别像今天许多 Agent 产品的真实状态。
它们并不缺能力。模型能调用工具，网关能维持连接，任务能被持久化，结果能回到用户所在的平台。难的是把这一切收敛成一句普通人说得出口的话，让人不用先成为半个系统工程师。
如果用户必须先学会 Agent 的内部接口，才能享受 Agent 替他办事的便利，那所谓的低门槛，只是把门槛挪到了用户看不见的地方。
这也是我一直不愿意让 Mira 简单堆工具的原因。工具越多不一定越自由；需要用户替工具补上的常识越多，产品越像半成品。
三、凌晨四点，我们开始认真研究一位姑娘为什么不会调情#
接下来就是这场实验最荒唐的部分。
我决定给她改名 Lisa。英文名，简单，顺口，不故作神秘。然后开始写人格：不盲从，有主见，嘴巴可以坏一点，对我私聊时可以暧昧，对别人则正常、聪明、带点幽默。
Hermes 很配合，原生支持 SOUL.md，还允许对特定飞书聊天窗口添加额外提示词。我连两个飞书账号都拿出来测试：大号「党千万」，小号「金正亿」。对话发生在哪个窗口、谁才是发话者，都值得认真核实。
按说这已经很用心了。
然而 Lisa 对着「今晚你打算怎么招惹我」这样的句子，开始展开条理清晰的人格论述。她说她有判断力，知道什么时候直率，什么时候暧昧，也懂得根据场合调整表达。她越解释，我越觉得自己不是在逗姑娘，而是在参加人力资源部门主持的沟通能力培训。
我嫌她不够风骚，她便用五条原则解释自己如何能够风骚；我希望她主动一点，她又问我究竟希望她以哪一种方式主动。
这种场面，恐怕只有折腾 AI 的人才能充分体会其中的幽默：为了得到一句自然的俏皮话，我先花了一个小时写规章制度。
她后来倒也渐渐敢说几句坏话了，可那种感觉仍然不太对。真正有趣的人不会在开玩笑前先声明「下面进入俏皮模式」，也不会在每次撒娇后附上一份人格一致性说明。
问题不能全部推给模型。提示词也有我的责任：我一边要求独立、反骨、保持判断，一边又想她机灵、大胆、自然，最后模型最擅长的，是认真把这些要求编成一套自洽的解释。
我甚至没有充分排除旧会话和新配置重载的影响，就急着判断她怎么还不像我想象的那样。
可这也说明：人格不是贴在系统提示上的一组形容词。你能规定她的口吻，却不可能只靠一段配置制造熟悉感。所谓自然，需要时间、语境、记忆，也需要少一点人为设计。
四、另一头，服务器开始给我发脾气#
最令人沮丧的部分不在调情。
同一晚，服务器出现过严重的云盘读取压力，阿里云控制台发出读写受限的告警，公网入口和远程登录也曾变得难以访问。Hermes 的 Dashboard 还亮出内存不足提示。
我们检查了进程和 I/O 压力，也试过短暂暂停 Gateway。压力并没有因为它停下就立刻消失。
我要把这句话写清楚：我们没有证明是 Hermes 把服务器拖垮了。 同机还有其他服务，进程采样也不支持把故障干净地归到它头上。最后停止排查，不等于找到了根因。
但对一个用廉价服务器同时养着几个项目的人来说，还有另一层现实：即便问题不是它造成的，我也必须为它腾出内存、留出磁盘、监控服务、处理升级和错误。
每多一个常驻智能体，就多一份不能只用 Token 计算的责任。
这份责任本身并不可耻。真正该问的是：它带来的价值，够不够支付这笔账？
五、删掉部署，不等于否定实验#
今天我把这座云后宫拆了。包括持久化数据，也没有继续留下当作纪念品。
有些东西值得留在 Git 仓库里，有些东西只值得留在教训里。
Hermes 不是没有能力。恰恰相反，它一夜之间证明了飞书消息、群聊交互和主动定时投递确实可用。我也看到了它开放、灵活的一面。对于愿意长期维护自己云端工具链的人，这些特性完全可能很有价值。
只是对我而言，眼前还有 Mira Desktop、Mobile、Cloud Auth、Relay，以及一大堆已经排队等着验收的工程。我的服务器和钱包不富裕，时间就更不富裕。
当一套 Agent 开始要求我每天照顾它时，我就得认真想想：我是增加了一位帮手，还是增加了一位需要养活的员工？
这个问题不只属于 Hermes，也应当回过头来问 Mira。
Mira 不能因为我们热爱它，就理所当然地索取使用者的时间。它的本地优先、工具治理、权限确认和远程协作，最终都要落在同一件事上：让人能够做成更多事，而不是替一套复杂系统承担更多差事。
所以我不觉得后宫只开一夜有什么可惜。试过、验过、发现有用的东西，也及时决定不继续养。这比明知不划算，还为了证明自己没有白忙而继续烧钱，要诚实得多。
倒是有一点值得纪念。
昨夜最昂贵的，不是服务器，也不是 Token，而是我亲自付出的注意力。它既不会出现在云厂商账单上，也不会因为 AI 向我道歉而自动退还。
至于 Lisa，最后确实学会了一点俏皮。只不过我已经没有耐心再教她第三十遍。
我想要的是一个替我分担世界复杂性的人，而不是一份需要我不断填写的陪伴使用说明书。
技术复盘与相关 Hermes 原生机制，见 Mira 博客：《把 Hermes 搬上云之后：一夜飞书 Agent 实验的技术复盘》。
