文章目录
业务不会等人打开聊天框才发生变化。一项任务完成了，一个约定时间到了，外部系统出现了需要关注的情况。如果每次都要先由人发现，再整理成提示词，Agent 仍然只处在工作链路的末端。
主动 Agent 的设计，是让已经接入系统的事件成为工作的入口。它关注的是何时需要判断、如何把上下文带给执行者，以及怎样控制行动的范围。
事件是“发生了什么”的记录
事件可以是一个时间点到达，也可以是任务状态变化、外部业务通知或设备信号。事件驱动意味着系统围绕这些变化组织动作，而不是要求 Agent 永远盯着环境反复询问。
一个定时任务可以在约定时间唤醒 Agent；一个分工任务的完成结果，可以让等待它的工作继续。两者都把“等待”与“执行”分开。
对非技术读者而言，可以把它理解为有明确收件规则的工作台：通知来到之后，系统先识别它属于哪件事，再交给合适的处理流程。
先筛选，再让模型判断
企业系统可以产生很多变化，并非每一条都值得调用大模型。简单条件适合由确定的规则处理：是否到了时间、状态是否完成、是否属于目标项目。
当变化需要解释、归纳或跨系统判断时，Agent 再介入。例如，“任务已完成”可以由程序识别，“这个结果对项目计划意味着什么”可能需要 Agent 结合上下文分析。
| 阶段 | 适合承担的工作 |
|---|---|
| 接收事件 | 保留来源、时间和关联对象 |
| 规则筛选 | 判断是否满足明确条件 |
| Agent 处理 | 理解复杂上下文并决定下一步 |
| 执行动作 | 在授权范围内调用工具或应用 |
| 保存结果 | 记录发生了什么，供后续工作使用 |
表格可以左右滑动
这一分工让推理资源集中在有意义的判断上。它也是早期主动 Agent 理念中“事件总线与筛选”的核心：先组织变化，再组织智能。
brazosd 已经具备的入口
当前 Agent 支持一次性和周期性定时任务，可以创建、暂停、恢复和删除计划。任务到达时间后，由系统负责唤醒对应工作，不依赖浏览器持续打开。
智能体分身也有明确的完成等待能力。发起分工的 Agent 可以等待指定运行的结果，而不是反复读取对方聊天历史，猜测它是否已经完成。
平台的实时事件还服务于会话进度与云盘界面更新。需要区分的是：界面收到文件变化通知，并不代表当前产品已经提供“任意文件变化自动触发任意 Agent”的通用规则入口。
接入监控、传感器或其他业务事件，是可以沿着这套架构扩展的方向，但每个来源仍需相应连接、事件契约和触发配置，不能把架构愿景写成所有场景已经开箱即用。
事件驱动首先是可靠性问题
通知可能重复，处理可能失败，网络可能中断。一个可用的主动系统必须知道事件属于哪次工作、是否处理过，以及失败后应当怎样继续。
尤其对于修改数据或调用外部服务的动作，重试不能随意扩大影响。系统需要保存执行状态，并结合业务唯一标识和结果检查控制重复操作。
这也是为什么“让 Agent 一直运行”并不能解决所有问题。持续运行只是资源状态，正确处理一次事件需要明确的任务状态与恢复语义。
主动不等于不受约束
一项计划应该有清楚的工作范围。用户授权定期整理资料，不等于授权它任意删除文件、改变组织权限或开始其他业务。
定时和事件触发改变的是开始工作的时机，执行时仍需遵守身份与资源权限。遇到任务没有明确决定的重要事项，Agent 仍应把决定交还给人。
暂停后续计划与中断已经开始的运行也有不同含义。良好的产品设计需要让这两种控制可以被理解和检查。
从聊天工具走向业务参与者
主动 Agent 的价值，是减少“人把系统变化重新转述给软件”的环节。它可以围绕已接入的事件参与流程，并把结果继续交给其他应用或人。
无状态运行与休眠让等待不必等于持续占用活跃计算；云函数承接确定的重复逻辑；权限体系限定真实动作。三者共同决定主动能力能否长期、可靠地进入业务。