夜雨聆风
浅浅盘一下 Claude Code 源码里的 8 个隐藏新功能在水务行业的应用前景
今天圈内有个挺有意思的事。
Claude Code 的源码因为一个比较低级的问题被公开了，很多人第一时间去看架构、看实现、看 Agent 设计。对开发同学来说，这里面有很多值得研究的内容。对我来说，真正吸引我的，反而是另一部分：
那些藏在源码里、还没有正式上线的新功能。
说实话，源码和底层架构我并不算内行，你真让我去盘实现逻辑、盘工程设计，我也未必能讲得很透。但我对产品功能一直很感兴趣。一个产品将来想往哪走，很多时候就写在这些“尚未公开”的细节里。
所以这两天也借助 AI，和身边几位更懂技术的朋友一起，把这份源码里比较有意思的隐藏功能梳理了一遍。看下来最大的感受是：
Claude Code 想做的，已经不只是一个写代码的工具了。
它在往“持续在线、主动协作、跨端延续、多 Agent 分工”的方向走。真把这些功能都做出来，形态上会非常接近很多人想象中的“超级 Agent 助理”。
下面就按我目前看到的信息，盘一盘其中 8 个比较有意思的点。
1. Buddy，你的 AI 宠物
源码里有一个叫 BUDDY 的功能，设计得很像一个“绑定型陪伴角色”。
从现有信息看，它至少包括这些设定：
-
可以给 Claude Code 配一个 Buddy -
一共有 18 种物种可以选 -
有 5 个属性 -
有明确的稀有度体系，从普通到传说 -
普通概率大约 60%，传说大约 1% -
还有 1% 的概率出现闪光版 -
Buddy 由用户 ID 哈希决定，基本没法靠反复注册去刷稀有度 -
据说预计会在 5 月上线
这个功能一眼看上去会让人觉得“有点花”，但它背后其实是很典型的产品思路：
给一个工具增加陪伴感、归属感和身份感。
对于命令行产品来说，这种设计挺少见。因为这类工具一般更强调效率、能力、专业性，很少会主动加这种轻养成元素。Claude Code 把这个东西埋进去，说明他们对“用户黏性”和“长期使用关系”这件事是动过心思的。
从水务场景看，这个功能本身不太好直接套进去。
宠物、稀有度、闪光版这些设定，更偏消费级产品表达。如果真要结合行业场景，可能只能借鉴“专属助手”这个思路，比如为调度员、运维人员、水管家配置一个长期陪伴的个人助手形态。但原封不动搬过去，意义并不大。
所以这个功能我会把它理解成：
很有产品感，很有趣，但更偏体验层。
2. Kairos，主动模式
如果说 Buddy 还偏“有趣”，那 Kairos 就是我觉得真正值得重视的功能之一了。
从源码信息看，Kairos 是一套完全不同的主动交互模式。进入这个模式以后，Claude 不再只是“等你发问再回复”的工具，而更像一个始终在线的助手。它会有自己的每日日志，还会调用这个模式下的专属工具，例如：
-
给你发送文件 -
给你推送通知 -
主动输出一些过程信息
这个功能最核心的变化，是交互关系变了。
过去你把 Claude Code 理解成一个响应式工具，你问一句，它回一句。
Kairos 体现出来的方向，是它想从“被动响应”走向“主动协助”。
这件事一旦做成熟，意义会很大。因为它改变的不是某一个按钮、某一个命令，而是产品角色本身。它会更像一个常驻在线的工作搭子，甚至有点接近“数字助理”的雏形。
这个点如果放到智慧水务语境下，反而是非常容易理解的。因为水务很多业务天然就适合“主动式”能力，比如：
-
主动推送异常告警 -
主动生成运行日报 -
主动汇总风险小区变化 -
主动提醒设备状态波动
所以 Kairos 这个功能，本身虽然来自 Claude Code，但它背后的产品思路，其实和很多智慧水务正在追求的“主动运营”方向很接近。
3. Auto-Dream，做梦
这个功能名字很玄，叫 Auto-Dream。从目前的信息看，它其实已经有灰度迹象了，通过 /memory 就能开启。
它的机制大概是这样：
当你不使用 Claude Code 的时候，系统会在后台自动启动一个“做梦进程”，去整理你之前让 Claude 存下来的所有记忆，尽量避免记忆越积越乱，最终影响后续使用。
这个功能挺有意思，因为它其实是在处理一个大家都越来越会遇到的问题：
当 Agent 开始拥有长期记忆之后，记忆本身怎么治理？
记住东西当然很重要，但只会一味地存，不会整理、不懂归纳、不做去重，时间一长就容易出现信息冲突、上下文漂移、偏好混乱，最后记忆反而成了负担。
所以 Auto-Dream 的价值，不在“做梦”这两个字，而在它说明产品已经意识到：
记忆不是越多越好，关键在于能不能持续整理。
这个能力如果借到水务场景里，是有一定参考价值的。因为很多系统今天的问题，也不在于没数据，而在于数据存了很多，知识沉淀却很弱。比如工单记录、设备故障、投诉原因、处置经验，这些东西如果长期缺乏自动整理和归纳，最后只是越堆越多，很难形成真正可复用的知识库。
所以这个功能在产品层面不显山不露水，但其实挺关键。
4. Daemon，变身后台服务
第四个功能是 Daemon 模式。
这个名字对开发同学来说应该不陌生，它的意思大致就是“后台守护进程”。放到 Claude Code 身上，就是让它不再只是一个临时打开、执行命令的工具，而是像数据库服务、Web 服务那样，长期在后台运行。
这个变化很重要。
因为一个只在你打开窗口时才工作的系统，和一个即使你不盯着它、它也持续运行的系统，在产品能力上完全是两个阶段。
Daemon 模式意味着 Claude Code 想往“服务化”方向继续走。它可以在后台一直待命，持续监听、持续处理、持续提供能力。这种形态天然更适合：
-
长任务 -
持续监控 -
多步骤执行 -
跨时段协作
这个功能如果放在水务里，理解起来就更直观了。因为水务很多系统天生就是长期运行的，像监测、告警、调度、巡检辅助，本身就要求后台常驻。所以 Daemon 这类能力，在行业系统里是很实用的。
从 Claude Code 的角度看，这也说明它正在脱离“单次命令工具”的边界，往“可持续运行的工作基础设施”靠。
5. UDS Inbox，跨会话通信
这个功能我觉得也非常有看点，叫 UDS Inbox。
它能做的事，是让不同的 Claude Code 会话之间可以互相发消息。比如你同时开了三个 Claude Code 窗口，以前它们彼此隔离，互相不知道对方的存在。有了 UDS Inbox 之后，不同会话之间就可以通信了。
乍一看这像是个“小功能”，但其实背后对应的是一个很关键的方向：
多个 Agent 或多个任务上下文之间，开始具备协同能力。
以前很多 AI 工具虽然也能多开，但每一个窗口本质上都是孤岛。
你在 A 窗口分析需求，在 B 窗口改代码，在 C 窗口看日志，它们之间没有天然的联系。
如果会话之间能够通信，就意味着很多更复杂的协作形态有机会成立。比如：
-
一个会话负责调研 -
一个会话负责规划 -
一个会话负责执行 -
一个会话负责审查
它们之间可以传递信息、同步状态、补充上下文。
这个思路如果拿到智慧水务里去看，也很有启发。因为很多行业系统的问题，本质上也是“系统会做事，但彼此不通气”。如果未来真是多智能体协作，通信机制一定是基础能力之一。
所以 UDS Inbox 这个功能，可能外表不热闹，但从架构方向上看，很值得留意。
6. Teleport，跨机器传送
这个功能对很多人来说可能会很有吸引力，名字也起得很直白，叫 Teleport。
它的能力就是把整个工作会话，从一台电脑传送到另一台，把所有上下文一起打包带走。你可以在公司电脑上做到一半，回家以后在另一台设备上继续打开 Claude Code 接着干，不需要重新解释一遍背景，也不需要自己再手动补上下文。
这个功能看起来简单，但体验上会非常明显。
因为很多时候我们使用 Agent 的最大痛点之一，不是它不会，而是上下文丢得太快。换了设备，换了环境，换了终端，就像重新认识一遍。
Teleport 解决的其实是“工作连续性”的问题。
这个能力放到水务行业里，同样是有用的，尤其适合那种办公室、现场、移动端切换比较频繁的场景。只不过它更多提升的是使用体验和协同连续性，本身不直接创造业务能力。
所以我会把它看成一个非常实用的增强项。
它未必最“炸裂”，但真正上线后，用户应该会很有感知。
7. Ultraplan，30 分钟远程规划
这个功能非常像“重型模式”，叫 Ultraplan。
按照源码里的描述，你输入 /ultraplan 再加一段任务描述，系统会在云端启动一个远程 Claude Code 实例，调用 Opus 4.6 模型，花最多 30 分钟去探索你的项目、分析可行性、拆解规划步骤，目的是帮助你提前避坑。
这个功能最有意思的地方，在于它默认承认了一件事：
有些任务不是几轮对话就能想清楚的。
它需要更长的探索时间，需要更完整的项目阅读，需要更系统的推演。传统聊天式交互，很难天然承载这类工作。所以 Claude Code 这里给出的思路是，针对复杂任务，直接拉起一个独立的远程实例去慢慢研究。
这其实已经有一点“远程工作代理”的意思了。
如果这个功能最终成熟，影响应该会很大。因为它不只是帮你回答一个问题，它是在帮你做一段阶段性的脑力工作。
这个方向放到水务里，也不是完全没有场景，比如规划方案比选、项目前期研判、实施路径拆解，都能参考这种思路。但行业项目往往受现场条件、历史系统、组织流程影响很深，所以它更适合做辅助分析，暂时还不太适合直接拿来替代正式方案工作。
8. Ultrareview，多 Agent 审查
最后一个是 Ultrareview。
你输入 /ultrareview，系统会在云端启动一支“Bug 舰队”，默认 5 个 Agent，最多 20 个，每个 Agent 从不同角度去审查你的代码，整个过程大概 10 到 25 分钟。
这个设定看起来确实很有“暴力美学”的感觉。
过去我们说代码审查，更多还是一个人看一遍，或者少数几个人一起看。Ultrareview 体现出来的思路，是把“并行审查”这件事做到极致。让多个 Agent 同时从不同维度出手，比如：
-
逻辑正确性 -
潜在风险 -
边界条件 -
性能问题 -
风格一致性
这么做最大的价值，是它不再依赖单一视角。
某种程度上，相当于给代码评审加了一层“多专家同时会诊”的机制。
这个能力在软件开发里会非常直接。但如果问它和水务有没有直接结合点，那我会觉得相对有限。因为它核心还是代码审查，更适合研发团队。真要借鉴，也更多是借鉴“多角色并行复核”的思路，而不是功能本身直接迁移到业务系统。
最后聊两句
把这 8 个功能放在一起看，会发现 Claude Code 想去的方向其实挺清楚的。
它已经不满足于做一个“你问一句，我答一句”的代码助手了。
它在慢慢补齐几类关键能力：
-
更强的长期记忆 -
更持续的后台运行 -
更主动的服务方式 -
更多会话之间的协同 -
更完整的跨端连续性 -
更重型的复杂任务处理能力
从这个角度看，Buddy 这种功能是表层的“产品感”，Kairos、Daemon、UDS Inbox、Ultraplan、Ultrareview 这些，才更像是在搭下一阶段的骨架。
如果这些都逐步落地，Claude Code 最终呈现出来的，可能真的会越来越接近一个“超级 Agent 助理”。
至少从这次泄露出来的线索看，它想做的事情，已经远不只是“帮你写点代码”这么简单了。
其他精彩分享：
2025年中国智慧水务深度研究——【第三章 技术分析（重新修正版）】