在 Doctolib，我们的使命不仅仅是构建我们所梦想的医疗体系——我们正在改变健康专业人员与技术之间的互动方式。两个雄心勃勃的目标驱动着我们：让使用我们解决方案的健康专业人员感到满意，并加快我们的创新步伐。但雄心壮志伴随着巨大的责任，尤其是在支持我们的用户方面。
随着我们平台的增长，支持请求的数量也在增加。传统的方法是简单地根据需求线性扩展我们的支持团队。然而，我们看到了不同思考的机会：如果我们能够在维持高客户满意度的同时，实现可持续的支持成本，那该多好？如果技术能够帮助我们的支持团队专注于他们最擅长的事情：为复杂案例提供富有同情心的人性化服务？
这个挑战促使我们探索 AI 技术的前沿，特别是自主智能。我们正在构建一个不仅仅是回答问题的系统——它能够像经验丰富的支持代理一样思考、分析和行动。这并不是要取代人际互动，而是要增强它。通过智能处理常规查询，我们使支持团队能够专注于那些人类专业知识和同情心最为重要的案例。
什么是代理性（agentic）？
在“agentic”这个词中有“agent”，这并不是巧合。
代理性系统本质上是一个由专业的 AI 代理 组成的网络，像一个协调良好的专家团队一样朝着共同的目标努力。可以把它看作是一个虚拟组织，每个成员都有特定的技能和责任。
每个代理都由大型语言模型（LLM）驱动，但在以下方面受到严格限制：
• 一个定义其角色、上下文和专业知识的专业提示 • 一组特定的工具可供使用
让我们通过一个来自我们支持系统的例子来具体说明。其中一个代理是“数据检索器”（Data Retriever）——一个专注于收集客户信息的专家。虽然它可以深度访问我们的客户数据 API，但它只能使用经过精心策划的一组端点。这种专业化确保了效率和安全性（最小特权原则）。
代理之间的交互由一个有向图结构来管理，其中：
• 每个节点是一个计算/处理步骤：它可以是基于 LLM 的代理或只是一个确定性函数 • 每条边定义了可能的通信路径 • 信息流遵循这些预定义路径，具体取决于前一个节点的输出
在后台，我们的代理性系统基于 LangGraph 构建，这是一个强大的框架，用于协调这些复杂的代理交互。
在之前的几个季度中，我们开发了一个增强检索生成（RAG）引擎，它通过我们的支持知识库丰富 AI 的响应。你猜怎么着？它现在将成为我们代理性系统的一个专业代理！
超越聊天机器人：重新构想支持互动
糟糕的虚拟助手聊天体验
我们都曾经历过与聊天机器人对话的挫败感，心中明确希望与人类交流的目标。
要么聊天机器人提供的选项有限，没有一个符合你的需求，要么是一个自由文本字段，让你可以对机器发泄怒火（?），但却无法得到你想要的结果。
这正是我们绝对不想要的。
阿尔弗雷德 ?️！请把大红按钮拿来
我们设想了一种根本不同的方式，而不是强迫用户通过僵化的决策树，或让他们在自由文本框中无助地呼喊：一个数字管家，提供与熟练人类代理相同的深思熟虑、智能的服务。
就像一个训练有素的管家，阿尔弗雷德：
• 理解客户的需求，即使这些需求没有完美表达 • 知道该问哪些问题以及何时提问 • 机智地收集我们的系统中 readily available 的信息 • 向他们提供清晰、可操作的解决方案——我们的 ✌️大红按钮✌️ • 所有这一切都通过动态用户界面完成
从愿景到现实：一个现实世界的例子
对于2024年第四季度，我们想要解决一个具体但常见的场景：管理医生日历的访问权限。例如，它可能是“嘿，阿尔弗雷德，我想给玛丽亚·史密斯只读访问我的家庭咨询日历”。
但说实话，客户很少一开始就提出如此精确的要求。
一个更现实的场景可能是这样的对话：
• HCP: 我想给我的日程安排提供访问权限 • 阿尔弗雷德: 当然，我看到您组织中有几个人，您提到的具体是哪个？ 1. 玛丽亚·史密斯 2. 约翰·多 • HCP: 玛丽亚·史密斯 • 阿尔弗雷德: 我还看到您有多个日程：您希望玛丽亚访问哪个？ 1. 日程 1 2. 日程 2 3. 日程 3 • HCP: 日程 1 • 阿尔弗雷德: 好的。您希望给予玛丽亚什么级别的访问权限？ 1. 只读 2. 预订管理 3. 完全访问 • HCP: 预订管理 • 阿尔弗雷德: 我明白您想要给玛丽亚·史密斯访问您的日程 1，访问权限为“预订管理”。要执行此操作，请按确认按钮。
HCP 提交确认按钮；
✨ 玛丽亚·史密斯现在可以访问日程 1 ✨
相当时尚，对吧 ?？
技术挑战与设计决策
管理 AI 幻觉
作为非确定性系统，大型语言模型确实会产生幻觉。有时少，有时多。这是一个事实，也是我们无法忽视的方程式的一部分。
在与工程师、法律部门和领导层进行广泛讨论后，我们确立了一个关键原则：LLM 永远不会直接执行敏感操作。更改议程访问的最终步骤始终掌握在用户手中。这种“人类在环”方法确保了 安全性 的同时保持 效率。
但这一决定带来了自身的复杂性：如何确保我们向用户展示的内容实际上是在他们点击确认时将要执行的？换句话说，如何确保当我们显示“Maria Smith”时，实际上发送的请求体中不是 John Doe 的 ID？
安全性和访问权限
一些 AI 代理需要访问客户数据以有效地完成他们的工作。然而，遵循 最小权限原则，我们决定不向它们提供提升的“✌️admin✌️”访问权限。相反，我们实施了一种更细致的方法：
• 代理继承与其协助的用户完全相同的权限 • 这需要复杂的应用程序上下文传播 • 每个 API 调用都遵循现有的授权边界 • 安全性与我们常规用户交互保持一致
生产规模扩展
让我们看看这些数字：
• ~1,700 个支持案例每天 • 假设每个对话有 ~10 次交互 • 每天产生 ~17,000 条消息
虽然从纯吞吐量的角度来看，这个量是可管理的，但它带来了有趣的挑战：
• 在多次交互中保持对话上下文 • 确保响应时间的一致性 • 进行监控和记录以确保质量
技术实现
现在是深入技术细节的时候。正如你可以想象的，有很多事情要说，但为了使这篇文章易于理解，我挑选了一些。屏住呼吸，穿上你的泳衣吧！
服务间认证
我们的服务使用 JSON Web Tokens (JWTs) 进行通信，实施了一种强大的认证方案：
Service A (Alfred) → JWT → Service B (Agenda)
每个 JWT 包含两个关键的信息（声明）：
• 受众 (aud): “你在和谁交谈” — 目标服务 • 发行者 (iss): “你是谁” — 调用服务
可以把它想象成一封安全的介绍信：“亲爱的 Agenda 服务 (aud)，我是 Alfred 服务 (iss)，这是我的凭证，已用我们共享的密钥签名。”
但我们更进一步。每个服务维护一个明确的允许调用者列表。即使签名完全有效，如果 Alfred 不在某个服务的“批准调用者”列表中，请求也会被拒绝。这种双重检查机制确保服务只与那些他们明确信任的服务进行通信。
用户上下文传播
记住我们让阿尔弗雷德与他所帮助的用户拥有相同权限的原则吗？以下是我们如何实现它的：
用户通过我们的身份提供者（Keycloak）进行身份验证。结果，他们会获得一个JWT作为身份的证明，该证明将与请求一起传播。
当阿尔弗雷德发出请求时，它携带两个令牌：
1. 服务到服务的JWT（证明阿尔弗雷德的身份） 2. 用户的Keycloak令牌（携带用户身份）
通过这种方式，目标服务可以：
• 验证阿尔弗雷德是否被允许发起调用 • 应用与直接用户请求相同的权限检查 • 维护一致的安全边界
这就像阿尔弗雷德同时拥有他的管家证书和来自他所帮助用户的授权信——两者都是代表用户执行操作所需的。
安全操作执行
我们的一项核心原则是，AI 代理不应直接执行敏感操作。但我们如何在保持顺畅用户体验的同时实现这一点呢？我们的目标如下：
每当 AI 代理决定是时候对议程授权进行更新时，它将构建完整的请求（url、http 方法和有效负载）并将其传递给一个 确定性节点。该节点将会
1. 确保参数不是由 LLM 产生的幻觉（事实检查） 2. 将其发送到一个操作请求检查器，负责获取所有引用资源的新数据，并返回技术和人类可读的形式
例如，假设 AI 代理构建了以下有效负载：
{
"method": "POST",
"endpoint": "/api/v1/agenda_authorizations",
"payload": {
"user_id": 42,
"agenda_id": 123,
"access_right": "read_only"
}
}操作请求检查器将获取相应的数据，以便向用户展示其含义：
• John Doe • Agenda A • 只读访问
这样，前端可以呈现一些 人类可读 和 准确 的内容，这意味着当我们显示“John Doe”时，使用的是 John Doe 的 ID，而不是 LLM 产生的幻觉内容。
评估
对于这项重要任务，我们利用 Literal.ai，这是一个专门用于人工智能评估的平台。
我们的核心指标是：
1. 成就水平：1-到-3 的评分标准，将 Alfred 的输出与既定的基准进行比较 2. 效率： - 图的执行延迟 - 步骤数量：执行过程中访问的节点数量 — 最优步骤数量
展望未来 ?
我们仍然处于与Alfred旅程的早期阶段。虽然我们最初专注于日历访问管理作为概念验证，但这仅仅是一个开始，我们正在探索其他支持场景，在这些场景中，这种代理方法可以带来价值。
我们所建立的基础——经过对安全性、用户体验和技术限制的仔细考虑——为扩展Alfred的技能库提供了坚实的平台。
