环境型AI智能体的设计：唤醒流程、低成本休眠状态以及安全唤醒方式。

大多数关于AI智能体的论述都是从请求到达、循环开始运转的那一刻讲起的。而那种能够自主监控收件箱、队列和仪表板的环境型智能体，几乎始终处于相反的状态：没有任何事情发生，系统必须反复判断是否有新事务开始出现。本指南正是探讨这种空闲状态。读完之后，你将能够设计出决定智能体何时启动的机制，将其待机成本降至接近零，确保每次启动都不会出现重复、数据过时或恶意注入的问题，并能够衡量这一整套设计是否真的能为被其打扰的人带来帮助。

一个警示性案例：为每一个“拒绝”付费

想象这样一个团队：他们开发了一个智能代理来监控团队的支持邮件箱和值班频道。目标很简单——在任何人注意到之前，就标记出所有需要人工处理的内容。在演示中，这个原型表现得相当出色。然而当第一张月度账单寄来时，其金额竟然超过了该团队用于购买IDE许可证、CI服务时长以及可观测性工具的所有费用总和，而这个智能代理在30天内仅完成了大约11次有效操作。

原因在于一种无人明确规定的架构。为了“监控”收件箱，系统会每两分钟运行一次定时任务，收集最新的消息，并询问某个前沿模型是否有需要处理的消息。在一个月的时间里，这样的操作大约进行了两万两千次。几乎所有的回答都是经过仔细考虑后的“没有”。那十一个“有”的答案固然出色，但整体结果仍以否定为主。该系统所花费成本最高的操作，其费用是其他操作的约三倍，那就是确认一切都没有变化。

在同一基础设施的其他地方，还有一个古老的cron任务，它会每分钟检查一次磁盘使用阈值。在整个运行期间，它几乎没产生任何成本。这正体现了整个话题的教训：等待是需要人为设计的，而非默认发生的现象。

需要牢记的核心理念是：环境代理的界定更多取决于能唤醒它的因素，而非它被唤醒后所执行的功能。真正的工程挑战在于设计一个尽可能低成本的筛选机制，从成千上万的输入事件中判断哪些值得模型关注，同时还需要一种在未被触发前不会产生任何成本的休眠状态。聊天代理无需面对这类问题，因为发送消息之前就已经有人判断过其价值。一旦将这个人从触发流程中移除，分类工作就落到了你的身上。如果试图用大型模型本身来解决这个问题，实际上等同于雇佣了最昂贵的专家来处理这些信息。

这些内容基于几个需要单独探讨的概念：持久执行能力（能够暂停运行数天而不消耗计算资源）、时间定位能力（智能体醒来后必须重新了解的“现在”状态），以及长期运行的智能体的目标偏移问题。它们会在后面相关章节中详细阐述。

每个提示语本身都是一种事件

聊天请求看似是智能体的自然起点，但实际上背后隐藏着大量准备工作。在任何字符被处理之前，发送请求的人已经完成了三件事：首先判断该情况值得采取行动，这属于优先级筛选；其次将其概括为几句话，这就是上下文构建；最后在特定时刻发送请求，这涉及时机把握。实际上，聊天智能体不过是建立在由人类驱动的事件层之上的另一个智能体罢了。

LangChain提出的“环境代理”这一概念指的是那些能够接收事件流并作出响应的代理，它们可能同时处理多个事件，从而取代了人类的角色。三种免费服务因此都消失了。剩下的只是一个工程难题：需要处理五种不同类型的输入，而每种输入的表现各异：

• 消息。 由人向代理发送的内容。这类输入较为少见，已经过人类判断的过滤，并且带有明确的意图。这是最简单的情况。
• 调度任务。 Cron及其衍生工具。无论是否发生了任何事件，调度任务都会按计划执行。这很有用，因为它能捕捉到事件流遗漏的内容，但也很浪费资源，因为大多数调度执行后并无任何反馈。

事件。 Webhook、队列消息、表格中的新行。这些是由外部世界主动推送给你的。它们大量且突发地出现，毫无筛选机制，而且由其他系统或陌生人生成，而非你的用户。

监控。 状态变化触发：拉取请求变为可合并状态、文档被编辑、客户停止回复。这些并不会自动推送给你，必须有人主动察觉，而这种察觉行为本身也需要付出成本。

阈值。 某项指标突破了设定界限。这是运维领域最古老的触发机制，历经数十年的实践积累了关于警报疲劳、频繁波动及死区的宝贵经验，如今系统构建者正在重新发掘这些知识。

设计闲置代理意味着要决定这些组件如何组合。哪些组件能够唤醒该代理？原始信号与模型之间是什么？当代理醒来时，它会重新构建关于世界的哪些信息？如果方向出错，就会出现上述情况——模型每隔两分钟就解读一次静默状态；而如果方向选反，代理就会在它本应捕捉的事件发生时一直处于睡眠状态。

唤醒漏斗：将分诊视为阶梯

关键的经济学事实是，模型调用是你所能设计的成本最高的条件判断方式。让前沿模型回答“这重要吗？”所需的成本，比用数据库过滤器处理结构化数据并得到相同答案的成本高出五到七个数量级。因此，实际的工作架构从来不是从事件直接传递到模型的直线关系，而是一个漏斗结构：由多个阶段组成，每一阶段的成本都低于下一阶段，同时也会丢弃大部分传入的数据。

第一阶段：结构化规则

第一阶段几乎不耗费任何成本。它只是简单的代码，用于检查事件的属性：类型、发送方、标签以及事件来源的存储库或队列。邮件通知、自动提醒、机器人评论，以及代理程序并不负责的项目相关事件，都可以直接被放入此处而无需任何过滤。在典型的收件箱中，大部分原始数据根本不需要进一步处理。如果在这一阶段被丢弃的原始事件还不到一半，那说明你的规则可能过于宽松了。

第二阶段：去抖动与合并

事件会成批出现，且都源于同一原因：同一个讨论线程中可能有数十封邮件，一次推送中包含三十次提交，某个出现故障的交换机会发出数百条警报。代理应当关注的不是单个事件，而是其背后的整体状况。因此，这一阶段会设置一个短暂的时间窗口，根据讨论线程、拉取请求或事故等关联键对传入的事件进行分组，并为每种状况生成一个综合信号传递出去。

在这个阶段也需要耐心。一份文档一旦被修改，很可能在接下来的几分钟内还会被多次修改。如果你在最近一次修改之后的固定间隔时间而非首次修改时进行检测，就能大幅减少检测次数，而且每次检测都能获得更完整的状况。每当有多个编写者同时操作共享状态时，都会出现同样的原理：四十次连续的事件通常对应一个事实。

关于监控的注意事项：先轮询再对比，切勿边轮询边判断

监控机制需要做出成本决策，而其他触发方式则无需。必须要有某种机制来察觉变化，而实现这一目标的方法恰好有三种：

• 源端主动推送。通过Webhook或订阅机制在状态发生变化时通知你。既然有这样的方式，就应当使用它。

轮询并对比。按照预定时间间隔获取当前状态，将其与之前的快照进行比较，只有当存在差异时才触发事件。

轮询并判断。按照预定时间间隔获取状态，然后向模型询问相关情况。这正是开头场景中出问题的原因。

轮询本身应享有比那种描述更好的声誉。轮询的成本很低，真正昂贵的才是判断过程。通过定时任务获取页面、对其生成哈希值并与之前的哈希值进行比对，每年的成本微乎其微。许多系统并不提供网络钩子功能，因此“绝不进行轮询”并非可行的规则。真正的原则是：轮询的结果必须是差异对比，而非模型调用。先获取快照进行比对，只有检测到变化时才将其作为事件纳入处理流程，再让该事件与其他所有内容一起经过相同的规则和分类器处理。某事物是否发生了变化可由哈希函数来判断，而该变化是否有意义，则是需要用模型来决定的问题。

第三阶段：低成本分类

那些能够通过规则筛选并整合的输入，会被送入一个小型、快速且成本低廉的模型，该模型的提示词被刻意设计得非常简短，例如“用一个词回复：紧急、相关或忽略”。这其实就是应用于警报系统中的那种常见的模型路由机制：低成本层级负责处理固定规则无法表达的模糊情况，只有“相关”和“不确定”的结果才会被上报。一个准确率约为92%的小型模型，搭配成本是其三十倍的大型模型，正是这一层级存在的全部理由。如需更全面地了解智能体成本的具体构成，请参阅基于架构的智能体AI成本模型。

第四阶段：智能体

只有到了这一步，完整的实施流程才会开始，包括具体的情境构建、所需工具以及预算规划。在正常的转化漏斗中，仅有极少数原始流量能发展到这一步，而且每一起相关事件在到达时都已以特定情境的形式呈现，而非单纯的独立事件。

第五阶段：人工干预

转化漏斗还会继续延伸到人工处理环节之后，因为人工处理本身也是一种筛选机制——它需要判断哪些发现值得投入人力去处理。这一最终阶段决定了整体系统的成败，下文将专门介绍这部分内容。

重新设计的计算逻辑

从一开始就将其应用于该团队。假设他们将收件箱的接收方式从轮询改为 webhook，并添加结构化规则，这样就能剔除大约70%的原始事件，因为那些都是新闻邮件和自动发送的邮件。通过按对话线程合并，又能再剔除剩余内容的约60%。随后一个小型分类器会将剩下内容中的大约85%标记为“忽略”。如今，该前沿模型每月的运行次数从两万二千次降至大约三十次，但依然能完成同样的十一种重要操作。每次有效唤醒的成本降低了不止一个数量级。

令人惊讶的是，精确度也有所提升。现在的每次唤醒都会分析一个连贯的场景，而非仅仅是在两分钟时间窗口内随机出现的片段，因此模型有更充分的依据进行推理。

良好休眠：闲置代理为何无需成本

在休眠状态之间，理想的运行环境代理根本不存在。它不会在后台默默运行；没有进程、没有容器，也没有任何运行环境支持。它的全部存在形式都存储在某个数据库中：一个身份标识、配置信息、指向其内存的指针以及一系列订阅列表。这正是“等待即状态”这一持久化执行理念的逻辑极致体现。处于暂停状态的进程只是静态数据，而存储静态数据正是云服务提供商提供的最廉价的服务之一。

这意味着唤醒进程实际上是一种重建过程。所有用于恢复暂停工作流的规则在这里都更为严格地适用，因为在这一过程中根本没有人会监督。

重新设置时间

在沉睡六天之后苏醒的智能体需要被告知当前时间，并且必须重新计算它所持有的所有相对参考值。如果在周二写下“截止日期是周五”这样的备注，到了下周一就显然错了。应向智能体提供其所有者时区下的当前时间以及它上次苏醒的时间，这样它就能知道自己已经沉睡了多久。

将内存视为可能过时的数据

在智能体不在场期间，世界仍在不断变化。存储在内存中的信息应当带有时间戳，并在使用前重新验证，同时苏醒后的处理流程应优先采用最新读取的数据而非记忆中的旧值。这与人类审批环节暂停工作流时所采用的策略相同：将决策绑定到某个快照上，然后在执行恢复时重新验证。

以目标为基准重新定位

在长时间运行的智能体中，目标会每轮根据当前上下文重新构建，这就是为何目标会在数周内逐渐偏移的原因。而“唤醒”过程则是从零开始构建上下文，这既可能是目标偏移风险最高的时刻，也是纠正偏差的最佳机会。如果操作得当，每次“唤醒”都会重新读取目标定义。如果一个智能体每年被重建两百次，那就意味着有二百次机会无需额外成本就能让它回归初始目标。

正因如此，那些每次唤醒时都开启新会话、将连续性信息保存在外部内存和文件中而非让记录不断累积的设计，其表现远优于那种会积累数月旧数据的单一永久会话。当前编程工具中的定时任务功能——以本文撰写时的知名示例 Claude Code 的常规功能为例——大多采用这种每次运行都重置的模式。对于那些见识过数周旧上下文会对智能体行为产生何种影响的人来说，这无疑是个明智的选择。

优秀的唤醒上下文应包含什么

在真正编写之前，“重构”这个概念听起来很抽象。一个设计良好的唤醒提示语就像是由系统逐部分整理而成的任务简报：

• 未编辑的目标文件。 说明该智能体存在的理由以及其功能限制。

时钟。校长所在时区下的当前时间，以及上一次唤醒的标记时间。

状况。触发此次唤醒的汇总摘要。并非四十条原始事件，而是对这些事件的概要描述。

最新状态。状况所涉及的所有项目的当前值，这些值在唤醒时获取，并标注有对应的时间点。

相关记忆。由早期唤醒留下的少量持久性记录，例如“该客户更喜欢在晚上接听电话”或“上次触发此警报的原因是缓存问题”。这些记录按需调取，不会被累积。

预算限制。本次唤醒的令牌上限、可用工具以及自主操作范围。

注意缺少了什么：早期唤醒过程的记录。虽然每次唤醒都会在结束前将所学内容提炼并存储到内存中，从而保留其结论，但每次会话的临时数据会被丢弃。这样的权衡使得第200次唤醒时的状态仍与第二次时一样清晰。此外这也有助于控制成本，因为几千个标记的简短说明就能替代可能长达数十万的记录文本。

带有大语言模型特色的交付保障

“唤醒”过程也意味着要面对分布式系统固有的各种问题。

交付操作至少会执行一次，因此每个唤醒请求都必须是幂等的。队列服务和Webhook服务都有可能向您发送相同的消息两次。对于无状态的通知器而言，重复的消息只是噪音；但对于拥有执行工具的代理来说，重复的消息可能导致相同的不可逆操作被执行两次。解决方法是采用标准做法：从事件中生成幂等性键，并在执行任何不可撤销的操作之前对其进行验证。如需了解相关原理的复习资料，请参阅Node.js POST端点中幂等性键的运作方式。

环境代理还需要进行第二次、针对具体情境的检查。因“PR #482 可以合并”而被唤醒的代理在采取行动前应确认该拉取请求仍然可以合并。它被唤醒可能已经过去了几分钟，此时可能有其他人或另一个代理已经处理过该问题。在唤醒时刻发生的竞争条件属于常见的共享状态竞争，只是因果之间的延迟时间更长而已。

事件流存在漏洞，因此每个监控系统都需要定期进行对账处理。终端设备可能会发生故障，订阅服务也会到期，而服务提供商有时会擅自停止数据传输而不通知用户。仅依靠对事件响应来构建的监控系统最终会错过某些事件而无人察觉；从外部看，因无事件发生而保持沉默的代理与因故障而无法工作的代理看起来并无区别。解决此问题的方法既古老又朴实：通过定期的缓慢扫描，将实际状态与事件流报告的内容进行比对，这其实与支付系统核对预期金额、扣款金额及实际到账金额的原理类似。利用推送技术处理延迟问题，用扫描机制确保数据真实性。

更深入的问题：攻击者、注意力分配、并发问题及流量风暴

触发因素即攻击面

以安全视角重新审视这五种输入类型。任何能够发送事件的人实际上都可以触发环境代理。Webhook负载、邮件正文以及那些能够引发代理激活的评论都属于不可信文本，它们会传递给拥有工具访问权限的模型。与聊天不同，在代理激活时没有人在场来发现异常情况。一封精心设计的“紧急”邮件不仅会浪费代理的激活资源，还会决定代理的思考方向，而这正是几乎所有提示注入链的开端。

所有标准的缓解措施都应适用。必须将事件内容严格视为数据处理。对环境代理的隔离程度要高于聊天代理。需将私有数据访问、接触不可信内容以及外部通信这三项危险功能分开；具备广泛工具和向外发送消息功能的收件箱监控代理同时拥有这三项功能，还相当于多了一个“门铃”。针对环境系统还需添加一条特定规则：自主性应与你对触发因素的信任程度成正比。由你自己的日程安排引发的唤醒可以采取行动，而由外部来源的内容引发的唤醒则应主要以通知为主。

在该循环中，人类是最稀缺的资源

环境代理产生的大部分内容都是对人的打扰，而打扰这种“货币”一旦过度使用就会贬值。LangChain的代理收件箱功能很好地描述了一种实用模式，即唤醒后的代理向人提出请求时可遵循的三步流程：

• 通知。仅用于提供信息，无需采取任何行动。
• 提问。代理在继续执行前需要一个具体事实。
• 审核。代理已准备好某个行动方案，希望获得批准。

针对具体场景的洞察是：这个阶梯结构同时也可作为质量评估标准。记录人们对每次干扰的反应——是采取行动、忽略还是置之不理。这样就能为整个流程提供精确的衡量依据。如果某位客服人员的通知有80%被忽略，那就不仅仅是80%的效率损失，这实际上是在训练人们关闭通知功能，而一旦他们这么做了，那20%的有效信息也会随之消失。在语言模型出现之前，警报疲劳就已经困扰着监控系统的推广多年，而再出色的警报文本也无法改变这一状况。

并发处理：一种兼具优势与风险的超能力

环境智能体的定义包括能够同时处理多个事件，而这一细节很容易被忽视。聊天智能体只负责一次对话处理，而环境智能体可以同时有四十个实例在运行，每个实例都处于独立的纯净上下文中，并且都对共享的现实拥有部分认知。你在不知不觉中就构建了一个多智能体系统，同时也面临着相应的共享状态问题。由相关事件引发的两个实例可能会争夺同一张票、在同一个线程中写入相互矛盾的答案，或者都承担同一项任务，但由于这些纯净上下文之间没有任何信息共享，它们彼此都无法察觉。

按优先级大致排序的缓解措施如下：

• 通过关联键对实例进行划分，使每种情况都拥有自己的状态。你在第二阶段构建的分组规则同样可以作为所有权判定标准：每种情况只对应一个实例，不会出现并行副本。

当分区机制不足时，可通过单一写入器来实现路由写入。

在两个唤醒操作确实必须作用于同一对象时，采用乐观并发机制，将冲突视为错误处理，这样第二个写入器会重新评估其操作而非覆盖第一个写入器的内容。

如果漏斗结构设计合理，大部分情况下这些功能都能免费实现，这并非偶然。用于分组事件的关联键与用于保护状态的拥有权键天然就应该是相同的键。

风暴模式

单个上游事件就可能产生一万条关联事件。简单的漏斗结构会将这些事件转化为一万次唤醒操作，导致令牌消耗急剧上升，并在事件发生过程中触发四十条通知，从而使频道被静音。运营团队很久以前就通过检测异常波动和事件分组解决了类似问题。

相应的代理机制类似于风暴检测器，它会将当前的事件发生率与基准值进行比较，一旦出现激增就会将处理流程切换到另一种模式。在风暴模式下，所有相关情况会被汇总为一种状况，一个代理会被唤醒并收到摘要信息，同时会接到具体指令：当前正遭遇风暴，请对其进行总结，找出最可能的常见原因并发送一条通知。成本控制固然重要，因为工作负载的尾部往往是预算被消耗严重的地方，但注意力分配的问题更为关键。在事件发生期间，正是当事件发生率上升时，人们处理干扰的能力也会下降。风暴模式就是让处理流程顺应这种变化而调整的机制。

将空闲代理视作产品来衡量

有两个数值最为重要：

• 每次有效唤醒的成本。将总花费除以事后被认为有价值的唤醒次数。这就是应用到自身系统中的成本效益分析。
• 分类的精确度与召回率。这些指标可以通过离线方式高效评估。将过去30天的事件输入候选流程，对比该流程本应触发的唤醒与人们实际的反应情况。

那种回放工具属于少数几乎可以免费构建的评估手段，因为相关标签早已存在于工单历史中。它将流程调整从主观判断转化为可量化的差异。

依赖时间的自主性

另一种实现成本较低却出奇罕见的模式是：让预警系统的自动干预阈值取决于触发时机以及能联系到谁。如果在周二上午11点，人们都在线上、紧急停止按钮触手可及且爆炸范围已明确知晓，便有理由自动进行干预；但到了周日凌晨，或许只需发出警报即可。

这并非过度谨慎，而是一种以时间为变量所做的期望值决策。在工作时间发起请求的成本较低，而在夜间则非常高。与此同时，由于无人监控，人工监督带来的好处——即有人发现错误的可能性乘以该错误的代价——也会在夜间降低。因此误差项占据主导地位，阈值应趋向于要求采取行动，但实际上由于没有人在场响应，这就意味着需要推迟处理。

将其编码为一种查询机制，该机制综合考量触发事件的可靠性、操作严重性以及人工处理的可能性，然后将这些因素映射为三种结果之一：立即执行、排队到上午处理或立即通知。排队到上午处理的选项其实起着至关重要的作用。环境代理在凌晨3点注意到的大多数问题，作为上午8:55再处理的待审事项是完全没问题的，这些事项会与代理建议的操作方案一同被整理好，在人们喝第一杯咖啡的时间左右送达。

真实系统中的模式

专为人类设计收件箱的邮件助手

LangChain的参考环境代理负责处理邮件：它起草回复、保存消息并进行任务升级。它的交互设计比内容起草功能更具指导性。该项目的团队将人工干预视为一种降低风险、简化部署流程、建立信任并强化长期记忆的手段，而非妥协之举。他们的“代理收件箱”是一个可查看的界面，列出了人与各代理之间所有未处理的对话，相当于将通知、提问和审核流程具象化。该项目有个流传已久的玩笑：如果被忽视了，那肯定是代理的错——这恰恰反映了当前的注意力经济模式：代理的存在是为了更明智地利用人们的注意力，而当它做不到这一点时，笑话便出现了。

编码工具中的定时代理

主要的编程助手平台都在不断增加能够根据时间表或仓库事件自动运行的助手，而非依赖用户提示；Claude Code的例程以及由GitHub触发的运行就是许多开发者都见过的例子。请查阅最新文档，因为这些功能发展得非常快。这类平台存在两种常见的设计思路，而两者都支持本文的观点：每次运行都会开启一个全新的会话，连续性通过文件和内存来维持，而非依赖无止境的记录文本；此外，触发机制采用的是传统的基础设施，如cron表达式、webhook过滤器以及条件化YAML文件，在整个处理流程中并不涉及任何模型。由于智能处理成本高昂，而触发机制成本低廉，因此这些产品将二者分开设计。

基础设施观察者

云服务提供商已经描述了用于监控基础设施并主动上报问题的自动化代理的工作模式。设计良好的系统正是将本指南中的理念付诸实践的典范。事件来自平台的原生事件总线，因此可以免费进行结构化过滤。在调用任何代理之前，这些事件会先被关联分析。对于任何重要问题，代理只会生成报告供人工审核，而不会自行修复。值得借鉴的一点是信任等级机制：拟采取的行动影响范围越大，其在通知、询问和审核的层级中所处的位置就越靠上。仅观察可以自主进行，而实际干预则需在监督下执行。

四分之一年后：轮询团队

等重新设计稳定后，再从启动状态回到团队工作。现在的处理流程包括网络钩子、带有十分钟静默期的信息流整合、一个提示词长度甚至能写在索引卡上的小型分类器，以及每月大约三十次前沿模型的运行。有两个结果尤为突出：每次有效运行的成本降低了约四十倍；而且出乎意料的是，识别准确率反而上升了。之前的轮询设计会将情况随意分割成两分钟的时间片段，至少有两次因此忽略了某些整体上显然应该得到“是”答案的局部情况。

因此，重新设计带来的好处不仅仅是降低成本。通过将事件整合在一起，模型的判断质量得到了提升，因为它终于能够评估整个情况而非随意的片段。问题从来不在定时任务本身，而在于要求模型对任务的每一个时间点都进行判断。

选择构建模块

这个技术栈中的大部分组件应通过购买或复用方式获取，而非自行开发。

• 触发基础设施。 Cron及其托管版本；EventBridge、Pub/Sub、Kafka等事件总线与队列，以及普通webhook；还有Temporal、Restate或Inngest等工作流引擎中的调度与信号功能，这些工具还能提供持久化存储。漏斗图的第一阶段和第二阶段正好对应着这些工具现有的功能。

环境-智能体框架。具备持久化存储、中断处理和定时任务支持功能的LangGraph，以及开源的Agent Inbox；各类主流编程智能体的调度与触发模式，例如Claude Code的脚本功能以及GitHub Actions的集成方案；还有越来越多可将邮件或Webhook转换为智能体任务的连接器。评估这些工具时应从三个方面考量：分类处理在何处进行（应在模型之前）、唤醒机制能重建什么信息，以及最终用户能看到什么内容。

分类层级。任何小型、快速的模型都适用。关键在于精简的提示词设计以及离线回放评估，而非所选择的模型本身。

消息收件箱。若希望使用现成的界面，可选用LangChain的Agent Inbox；或者利用团队现有的沟通渠道，如Slack、邮件或工单系统，同时需明确并规范使用三种操作指令。

将你的创新预算用于漏斗机制和尾随上下文重建，其余的一切都可以购买现成的解决方案。调度器早已经过数十年的实际测试，是成熟的技术；而自行编写的、每两分钟轮询一次模型的循环则并非如此。

整个设计仅需几行伪代码即可实现。按照从上到下的顺序理解其工作流程：首先是免费的规则检查，在突发情况尚未平息时会返回空结果；接着是低成本的分类处理；之后是为防止重复发送而设置的重试保护机制；再是从当前时间重建尾随上下文；接着是读取目标文件并获取最新数据；随后是在预算范围内运行代理程序；最后通过三种收件箱操作之一完成消息发送。

async def on_event(evt):
    if not rules_pass(evt):            return                  # stage 1: free
    sit = coalesce(evt, window="10m")                          # stage 2: situations, not events
    if sit is None:                    return                  # burst still settling
    if triage_small_model(sit) == "ignore": return             # stage 3: cheap
    if seen(sit.idempotency_key):      return                  # at-least-once armor
    ctx = rebuild(now(), goal_file, fresh_reads(sit))          # stage 4: wake = reconstruction
    outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
    inbox.deliver(outcome.verb, outcome.summary)               # notify | question | review

注意幂等性检查的位置：在简单的过滤操作之后，但在任何复杂或不可逆的操作之前。它也可以放在更早的位置；关键在于绝不能让重复的请求到达 agent.run。在真实系统中，rebuild 阶段也是适合进行“行动前检查”的时机，因为这是首次获得新状态的时刻。

故障模式指南

• 轮询陷阱。频繁要求一个性能较高的模型去检查实际上并无内容的情况。解决办法：在调用任何模型之前先进行规则处理和数据合并，然后再调用性能较低的模型。
• 连锁故障。一次故障会引发数千次后续问题。解决办法：启用风暴模式，配备速率检测器，进行完全的数据合并，仅使用一个代理并发送一条通知。

双重唤醒问题。重新传递的事件会到达能够执行实际操作的代理。解决方案：在唤醒信号上使用幂等性键，并在对情况采取行动前进行验证。

过时唤醒问题。决策仍基于触发事件发生时的快照，而现实情况早已发生变化。解决方案：每个唤醒信号在采取任何行动前都会重新读取时间、获取最新状态并再次验证事实。

外部注入的唤醒问题。外部来源的内容决定了自主代理应关注什么。解决方案：将事件内容视为数据，根据触发源的可靠性来调整自主程度，并对环境中的代理实施比聊天代理更严格的隔离措施。

沉默的收件箱。干扰控制的精准度逐渐下降，最终人们不再理会通知。解决办法：记录每条通知的已处理、已忽略状态，若已处理率低于50%则视为系统故障。

隐形的断层。某个Webhook数月前就停止发送数据，直到续费到期才有人发现。解决办法：监测延迟情况，查明真实状况，并通过逐步校验的方式处理问题，假设数据流存在错误。

永恒的守护进程。某个会话持续运行数月，却逐渐偏离初始目标。解决办法：每次唤醒时创建新会话，将连续性信息保存在文件和内存中而非记录文本中。

午夜的意外。最危险的操作往往发生在深夜，因为那时没人能够提出反对。解决办法：让相关操作经过审核流程，根据时间设定自主决策的阈值，并随时准备可立即使用的取消机制。

一周起步计划

1. 审查你的触发条件。列出今天可能启动智能体的所有路径以及每条路径的运行成本。将那些属于“定时调用模型”的路径标记为首要需要修正的部分。
2. 构建第一阶段方案。在每个触发条件前设置结构化过滤器，并测量被过滤掉的请求比例。如果该比例低于一半，说明你的规则过于保守。

合并处理。选择线程、拉取请求、事件或客户等关联键，添加边缘去抖功能，并将代理的输入类型从“事件”改为“状况”。

添加分类层级。使用输出仅为一个词的小型模型，然后根据上个月的事件及人们实际给出的回应构建回放评估机制，在依赖该机制之前先计算其精确度和召回率。

确保操作安全。添加幂等性键、先检查后行动机制以及重建流程：时钟、最新读取数据、目标文件。

设置分级通知机制。明确规定通知、询问和审核的输出类型，将其发送到可追踪的位置，并开始记录每项操作是已被处理、被忽略还是被搁置。

运行两次测试。重新播放数据流以确认风暴模式能将其聚合，同时关闭一个Webhook一小时，以验证扫描功能能否检测到空缺。最后，首次计算每个有效数据流的成本，并将其显示在代币消耗量旁边。

总结：环境感知与人类投入

关于智能体界面未来的发展方向存在诸多争论。一方认为聊天界面只是过渡形式，未来智能体将越来越多地存在于事件流中，在人们之前就发现问题。注意力是知识工作者最稀缺的资源，那些能够自行专注监控、仅在必要时才占用用户注意力的软件，显然才是更优秀的软件。

另一方指出，配备工具的全天候智能代理恰恰会带来上述所有风险：不可信的触发条件、唤醒时无人在场，以及深夜时的自主决策能力。从这种观点来看，该提示并非多余的负担，而是一种同意形式；每将一个人排除在操作流程之外，风险就会从行动时刻转移到安全机制的质量上。

双方各有所言，而漏斗正是两者交汇之处。虽然可以监控所有内容，但请注意，上述案例能够成功的关键在于传统工程方法：过滤、去抖动、幂等处理、对账任务以及避免警报疲劳。任何操作仍需获得许可，这正是“通知、询问与审核”流程所体现的：自主进行观察，通过层级上报来采取行动。其实现方案是让代理广泛监控、少频繁唤醒，并在更改任何重要内容之前寻求批准。

一个实用的练习只需一个晚上时间。挑选你工作日中最密集的通知流，为其设计一个漏斗结构：哪些内容可以通过简单规则过滤掉，哪些可以合并处理，哪些可以用小型模型进行分类，以及哪些确实需要人工干预。在编写任何代码之前，你就已经设计出了第一个闲置代理。