邮件助手工作流

📄← 模块索引↗ · 📄↑ 总索引↗

完成本节后，你应当能够：

• 解释邮件助手工作流对智能体系统的贡献。
• 判断何时该使用它、何时更简单的设计就已足够。
• 将该模式实现为可观察、可测试的组件。
• 识别其主要的成本、安全与可靠性风险。

将邮件智能体用于分类、起草、检索，以及需要明确审批才能发送的受控操作。

邮件场景同时涉及不可信内容、敏感数据、身份识别，以及具有实际后果的副作用。

箭头表示控制流与数据流的走向，不一定对应不同的模型。图中的方框可以由一个确定性函数、被多次调用的同一个模型，或多个不同模型来实现。在整个流程中应保留追踪标识符（trace identifiers）。

1. 对用户意图进行分类。 在实现之前，先写清楚输入、预期输出、负责人和失败条件。
2. 解析并核实收件人。 让这一决策在日志或结构化状态中可被观察，以便后续评估。
3. 只检索所需的上下文。 在此边界处应用最小权限原则，并验证相关假设。
4. 起草但暂不发送。 记录结果以及足够复现或诊断所需的元数据。
5. 检查语气、附件与敏感内容。 在继续之前，将结果与明确的验收标准进行比较。
6. 要求用户确认。 依据既定策略，将失败情形导向重试、回退方案，或人工审核。
7. 发送并记录结果。 把观察到的行为加入回归测试集与运维记录中。

• 状态（State）： 在结构化的运行记录中保存消息、工具调用、观察结果、产出物、决策理由、尝试次数、token 用量、延迟以及最终状态。
• 契约（Contracts）： 为每个组件定义带类型的输入、带类型的输出、允许的副作用、超时时间和错误类别。
• 控制（Controls）： 使用最小权限凭证、白名单工具、有界循环、输入校验、输出校验，并为有实际影响的动作设置审批关卡。
• 可观测性（Observability）： 在符合隐私规则的前提下，记录 prompt 或其版本、模型与参数、工具参数、工具结果、异常、时间戳和成本。
• 评估（Evaluation）： 测试具有代表性的案例、边界案例、对抗性案例和失败恢复案例，并与最简单可行的基线进行比较。

对于「回复 Alex」这类请求，先确认是哪一位 Alex，起草回复内容，展示收件人，然后等待审批。

输入：用户目标 + 约束条件
状态：{run_id, step, observations, budget, status}
决策：下一个有边界的动作
校验：权限、参数与策略
执行：模型调用、确定性代码或工具
观察：结构化结果或分类后的错误
停止：验收标准通过、预算用尽，或转交人工

• 该使用场景确实证明了此模式优于更简单的一次性调用。
• 输入、输出与成功标准都已明确。
• 工具调用及其副作用均已校验并获得相应权限。
• 循环设有硬性预算上限和有意义的停止条件。
• 失败情形会触发安全的重试、回退方案，或转交上报。
• 质量、延迟与成本被一并测量。
• 回归测试中至少包含一个失败案例。

1. 什么样的可观察失败，会表明这一模式被误用了？
2. 哪一部分应当是确定性的，而不应交给 LLM 处理？
3. 每一步所需的最小上下文是什么？
4. 人工审批或上报关卡应设在哪个位置？
5. 哪个指标能证明新增的复杂度是值得的？

为一个范围狭窄的任务实现一个最小可行版本。保存三条轨迹：一次成功的运行、一次可恢复的失败，以及一个必须停止或上报的案例。为每条轨迹编写一个回归测试，并将结果与直接生成的基线进行比较。