𝗖𝗼𝗺𝗺𝗼𝗻 𝗣𝗶𝘁𝗳𝗮𝗹𝗹𝘀 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗘𝗺𝗮𝗶𝗹 𝗔𝗴𝗲𝗻𝘁𝘀
你的邮件智能体在测试时运行良好。然后你将其上线。一夜之间，智能体开始回复自己的消息。客户收到了三次相同的回答。对话线程支离破碎。
这些失败发生在基础设施层面，而不是因为你的 LLM prompt。
在发布之前，请检查以下九项内容：
无限循环 (The Infinite Loop) Webhook 在你的智能体发送回复时触发。这又触发了另一个 Webhook。你创建了一个循环。 修复：在代码顶部过滤掉智能体的邮箱地址。如果发送者是智能体，则停止处理。
重复消息 (Duplicate Messages) 网络波动。你的端点 (endpoint) 响应不够快。系统再次发送相同的通知。 修复：对消息 ID 进行原子检查 (atomic check)。使用 Redis 或 Postgres 确保每个 ID 只处理一次。
竞态条件 (Race Conditions) 两个工作进程在同一毫秒处理同一个事件。仅靠去重 (deduplication) 在这里会失效。 修复：使用带有 30 秒限制的线程锁 (per-thread lock)。在锁内检查智能体是否已经回复过。
数据截断 (Truncated Data) Webhook 通常只携带摘要，而不包含完整的正文。大型邮件可能会以截断事件的形式到达。 修复：始终使用 ID 通过 API 获取完整消息。不要依赖 Webhook 的负载 (payload) 来获取内容。
对话线程断裂 (Broken Threads) 将回复作为新消息发送会破坏 Gmail 或 Outlook 中的对话分组。 修复：在每次响应中传递
reply_to_message_id。通过thread_id而非主题行 (subject line) 来匹配回复。人工修正 (The Human Correction) 人类在发送第一封邮件几秒钟后，又发送了一封后续修正邮件。你的智能体对两者都进行了回复。 修复：设置 30 到 60 秒的冷却时间 (cooldown)。将连续的消息合并为一次回复。
回复风暴 (The Reply Storm) 逻辑漏洞导致智能体瞬间发送数百封邮件。 修复：设置每个线程的发送预算 (send budget)。如果智能体在 5 分钟内发送了 3 条消息，请停止运行并提醒人工介入。
垃圾输入 (Garbage Input) 垃圾邮件和自动回复 (out-of-office) 触发了你的 LLM。你为无用的推理 (inference) 付费。 修复：使用收件箱规则来拦截不良发送者，或将自动邮件路由到不同的文件夹。
403 错误陷阱 (The 403 Error Trap) 出站规则可能会拦截发送。这会返回 403 错误。标准的重试逻辑会无休止地尝试该错误。 修复：将 403 视为终结错误 (terminal error)。不要重试。如果你收到 503，则可以重试。
像过滤器、锁和限制 (caps) 这类枯燥的修复方案，才是保障智能体安全的关键。
来源: https://dev.to/qasim157/common-pitfalls-building-email-agents-and-fixes-29kg
可选学习社区: https://t.me/GyaanSetuAi