在自动化工作流中隔离 LLM 邮件
当 LLM 智能体（agent）开始发送邮件或审批工单时，问题性质就发生了变化。这不再仅仅关乎你的提示词（prompt）是否有效，而是你的系统现在依赖于三个层面：决策、执行和验证。
如果你将这些层面混为一谈，你的团队将很难理解智能体究竟做了什么。
邮件步骤通常看起来像是工作流的终点。但实际上，它正是故障最先显现的地方。智能体可能会正确地对请求进行分类，但却将其发送给了错误的人，或者使用了过期的链接。你必须隔离测试和追踪（traces）。
一个稳定的设计不会试图一次性测试智能。相反，你应该将系统划分为小的契约（contracts）：
- 输入契约（Input Contract）：定义智能体使用的数据以及它可以请求的操作。
- 执行契约（Execution Contract）：定义一个操作如何转化为一封特定的邮件。
- 可观测性契约（Observability Contract）：将日志、收到的消息和最终的系统状态关联起来。
不要将邮件逻辑放在自由提示词中。LLM 可以建议一个操作，例如 "send_followup_email"。然而，模型不应决定邮件头、收件人或重试策略。应使用确定性代码（deterministic code）来处理这些转换。
这种方法降低了运维风险。LLM 提出建议，系统进行验证，执行器负责发送。
为了保持清晰的可视化，请追踪以下四个信号：
- 智能体做出的决策及其使用的上下文。
- 发送给邮件执行器的最终命令。
- 在隔离收件箱中收到的消息。
- 点击链接或确认操作后的最终效果。
从初始事件到最终点击，使用共享的 trace_id。这有助于你快速定位错误。你会知道故障是发生在模型、工具策略还是执行器（worker）中。
请遵循以下清单以实现更好的自动化：
- 每次执行都有其独立的
trace_id。 - LLM 仅请求符合有效模式（schema）的操作。
- 邮件执行器会重新验证收件人和模板。
- 每个测试场景都使用其独立的隔离收件箱。
- 最终点击确认了预期的状态变更。
- 日志让你能够追踪案例，而无需凭空猜测。
分离这些步骤会增加一些工作量。但它能带给你非常有价值的东西：解释为什么发送了邮件或为什么邮件发送失败的能力。
Optional learning community: https://t.me/GyaanSetuAi