你的智能体没有营业时间的概念

一家中型 SaaS 公司的支持智能体正确处理了一起计费纠纷。它读取了工单，检查了客户账户，发现了重复收费，执行了退款，并发送了一封礼貌的确认邮件。每一步都是正确的。唯一的问题是时间戳：客户所在时区的凌晨 3:14。客户在睡梦中醒来看到退款通知，以为自己的信用卡被盗刷了，在公司有人醒来解释之前，就向银行提交了欺诈申诉。

在那个工作流中，没有任何环节是传统意义上的 Bug。智能体没有产生幻觉，没有选错账户，也没有算错退款金额。它只是完全不知道凌晨 3 点是一个告知别人资金变动的糟糕时间。这个模型读过的人类睡眠习惯相关文本比世界上任何人都多，但它的行为表现仍然像是在对待一个随时待命的服务端点，只要你调用它，它就是清醒的。

这是智能体设计中最隐蔽的失效模式之一。我们花费了巨大的精力关注智能体是否做了“正确的事”，却几乎没有花精力关注它是否在“正确的时间”做这件事。两者并不等同。一个动作可能内容正确但时机错误，而时机上的失败往往才是客户真正会注意到的。

“立即执行”是无人选择的默认设置

当你编写智能体循环时，隐含的契约是：接收输入、决策、执行。执行发生在决策做出的那一刻。中间没有间隔，因为没人设置间隔。“立即执行”并不是你的团队讨论出的政策 —— 它是政策的缺失，是一个没有理由暂停的 while 循环的自然形态。

对于很大一部分智能体操作，即时性是没问题甚至必要的。回答问题、查询订单状态、起草供人工审阅的回复 —— 这些都应该尽可能快地发生。问题在于，同样的循环，带着同样的零延迟默认设置，也管理着那些即时性反而有害的操作：

• 发送面向客户的电子邮件或短信
• 向值班人员升级事件
• 在共享频道发帖，其中的通知会弹窗提醒十几个人
• 触发后续跟进流程（“我们注意到你还没有完成设置”）
• 提交一个会进入某人早间队列的工单

每一项操作都有“好”时间和“坏”时间，而智能体对待它们就像对待数据库读取一样。关于这些操作何时触发的决定是由编写执行层的人隐含做出的，而他们在写下 await sendEmail() 时，几乎肯定没有考虑过时区。

营销界在十年前就吸取了这个教训。发送时间优化（Send-time optimization）现在是任何严肃的电子邮件平台的入门门槛 —— 共识是接收者当地时区的早上 8–10 点效果最好，工具会自动错开全球发送时间，确保没人会在半夜被吵醒。智能体的构建者们正在从头开始重新学习这一点，因为智能体发出的外部邮件不经过营销技术栈。它通过智能体拥有的任何工具进行 HTTP 调用，而该工具对接收者的时钟毫无概念。

两种工作：随时性工作与仅限日间工作

解决方法始于一个智能体自身无法做出的区分。智能体可以采取的每一个动作都属于两个类别之一，你必须明确地标记它们，因为模型不会这么做。

随时性工作（Anytime work）是计算和内部状态变更。读取数据、运行分析、更新内部记录、准备草案、为工单丰富上下文。这些工作在发生时，接收端没有人类。它们可以而且应该 24/7 全速运行。如果你的智能体整晚都在静静地对工单分类、完善 CRM 记录并预先起草回复，那就是系统在按预期运行。

仅限日间工作（Daylight work）是任何涉及人类注意力的操作。界定标准很简单：完成这个动作是否会产生通知、中断或对特定个人的期望？ 如果答案是肯定的，那么它就是日间工作，“现在执行”不应该是自动的答案。它应该排队，直到人类清醒、合适的窗口期 —— 除非紧急情况覆盖了这一规则，我们稍后会讨论这一点。

这种拆分的威力在于，它让智能体在保持最大生产力的同时，依然体贴周到。智能体并没有慢下来；它只是将工作中产出成果的部分与交付成果的部分分离开来。晚班完成所有准备工作，早晨交付结果。一个在凌晨 2 点遇到问题的客户，会在早上 8 点看到一份已经完全解决的回复等待着他，这比凌晨 2 点的骚扰通知体验更好，也比业务时间才开始处理的慢节奏人工回复体验更好。

大多数团队从未划清这条界线，因为智能体的工具列表并不鼓励这样做。send_email 和 update_record 在同一个架构中并排存在，看起来同样无害，并由同一个推理步骤调用。你必须在工具级别（而不是提示词中）标注它们是否会触及人类。

Agent 缺失的上下文

加载中…