环境 AI 架构：设计不会被用户关掉的常驻智能体
大多数团队构建的环境 AI，用户上线就关。
这个模式高度一致：团队内部演示功能，所有人都认为理论上有用，但上线两周内禁用率就超过 60%。这不是模型质量问题，而是架构问题——更具体地说，是打扰阈值问题。团队在设计环境智能体时，考虑的是 AI 能做什么，而不是用户在没有主动求助时能忍受什么。
从显式调用（"问 AI"）到环境监控（"AI 观察并行动"）之间的鸿沟，不只是 UX 问题。它需要从根本上不同的系统架构、不同的事件模型，以及关于 AI 智能体何时才算赢得发言权的不同心智模型。
架构分野：拉取 vs. 推送
传统 AI 助手是拉取式的：用户发起，模型响应，会话结束。每次交互都有边界。模型的上下文窗口是某一时刻的快照。对话结束后，AI 进入休眠。
环境智能体是推送式的。它们持续运行，订阅事件流——文件系统变更、日历事件、通信信号、监控指标——并自主决定何时将某件事浮出水面。上下文窗口不再是快照，而是用户环境的持续更新的物化视图。
这在架构上有几个重要的本质区别：
- 状态必须跨会话持久化。 智能体需要记住三小时前观察到的内容，才能理解当下正在观察的内容。单会话上下文不够用；你需要持久的、流原生的状态存储。
- 智能体处理的信号量远多于它会浮出的信号量。 聊天机器人对收到的所有内容都响应，因为用户只发送他们想要答案的内容。环境智能体每小时可能摄入数千个事件，却一次都不打扰用户。过滤就是产品。
- 延迟要求是不对称的。 用户等待响应可以忍受 2-3 秒。环境智能体基于过时数据触发则破坏性得多——打扰发生在错误的时刻，依据的信息已经过时。
使用 Kafka 或 Pulsar 等消息代理的事件驱动架构能很好地处理这一问题，在规模下实现亚 100ms 延迟，并将观测层与行动层解耦。大多数团队忽视的是：架构是容易的部分。难的部分是打扰阈值。
打扰阈值问题
62% 的告警被接收团队忽视。SRE 团队将告警疲劳列为首要运营问题。知识工作者平均每 2 到 3 分钟被打扰一次，每次打扰后需要约 23 分钟才能重新进入专注状态。
这些数字早于环境 AI。它们描述的是人类对数字打扰的一般忍耐力。环境 AI 并非从零开始；它继承了用户对通知系统、推送提醒和自动纠错的 所有负面联想。
打扰阈值问题有两种失败模式：
过于激进：智能体频繁打扰，每次打扰价值偏低，用户习惯性地不看就驳回建议。功能变成壁纸。更糟的是，用户开始将 AI 与噪音画等号，这会毒化未来更高价值信号的信任。
过于保守：智能体浮出的打扰极少，用户忘记它的存在。他们不会注意到智能体漏掉了重要内容。功能悄悄萎缩，不产生任何价值。
校准这一平衡不是提示工程问题。它是系统设计问题，需要显式的阈值逻辑、置信度门控，以及让系统随时间学习用户偏好的反馈机制。
设计事件管道
环境智能体需要三个独立层协同工作：观测、过滤与投递。
观测是大多数团队的起点，但也不是他们挣扎的地方。订阅事件、构建 webhook、读取文件系统变更——基础设施已经存在。问题在于你选择观测什么。观测范围过广的环境智能体在上游产生太多噪音。将观测层的范围严格限制在对用户关心的事情有可靠预测性的信号上，是第一道约束。
过滤是大多数实现失败的地方。原始事件流包含的潜在触发远多于你应该浮出的数量。有效过滤需要：
- 置信度阈值，低于该阈值时智能体行动但不打扰。它可以记录笔记、更新内部状态或排队批量审查——但不应将低置信度观察作为实时打扰浮出。
