背景
日常工作中，我需要处理来自全球各地用户关于产品的各种问题，这些问题都是通过邮件进行沟通的。
问题
在处理邮件的过程中，大部分时间其实是用来翻译和查询用户资料等操作。比如一位俄罗斯用户反馈 API Bug，此时我需要：
- 先将邮件翻译为中文以理解问题；
- 根据 email 查询用户信息，比如用户的 ID、消费量（是否是大客户）等；
- 根据前面的信息思考如何回复；
- 将回复转为对方的语言（例如俄语）并发送。
在这个过程中，只有"思考如何回复"才是核心的工作内容，其他工作都比较繁琐。
方案
为了提升工作效率，我决定利用 Agent 来完成邮件撰写、翻译以及用户信息查询和分析。
架构
在架构选择上，我选择了单层 Agent。这是因为 Agent 的工作比较简单，单层 Agent 已经完全够用，使用多 Agent 反而会增加维护成本，造成不必要的 Token 消耗。
工作模式
在工作模式方面，我没有采用 Plan-and-Execute 模式，因为整体回复的过程已经积累为成熟的工作流，Agent 直接按流程处理即可。我采用了 ReAct 模式，让 Agent 根据所获得的上下文来处理后续需要调用的工具以及回复方式。
记忆
用户反馈的问题同质化比较高，比如充值未到账、API 错误等，让 Agent 拥有记忆可以降低后续人工干涉的成本。记忆主要分为以下几类：
- PREFERENCES：跨客户的沟通偏好，比如邮件语言要简洁、不要太多客套话这类规则。采用 md 文件格式存储，因为内容少，md 文件完全足够，且方便人工编辑。
- Customer Facts：每个客户使用一个 md 文件进行记录，存储用户相关的信息。
- Remembered Cases：存储客服案例，积累各类问题的处理方式，比如充值未到账通常会引导用户查看 Credits 页面，API 报错则要求用户提供请求参数等信息。使用向量存储，支持模糊搜索，对于案例参考，找到类似的案例即可，无须精确查询。
在存储案例时，为什么使用 db 而不是 markdown？主要基于以下三点考量：
- db 是结构化的，对于按 Email、时间进行筛选更加稳定；
- db 更方便做向量索引，支持模糊/类似的案例搜索；
工具设计
针对日常需求，设计了以下几项工具：
- translate_email（翻译邮件）：将邮件翻译为中文或目标语种。
- get_user_info（获取用户信息）：利用 Posthog 的 API 查询用户的 ID、充值金额等信息。
- search_knowledge_base（搜索知识库）：将 CometAPI 的文档作为知识库进行向量搜索，以此作为回复用户的资料参考。
- recall_similar_cases（查找类似案例）：参考类似案例的回复方式，复用历史沟通经验，提升回复质量。
- get_contact_history（获取用户历史沟通记录）：输入邮箱返回与此邮箱的沟通记录，在回复邮件时，通过沟通记录让 Agent 总结，可以快速了解沟通背景。
评估 AI 质量与优化
在遇到 Agent 回复质量不佳时，利用 LangSmith 检查 Agent 获得的上下文、可用 Tool 列表来定位问题并优化。
效果
经过实际运行，处理邮件数超过 100 封，效率提升了 75%。