日历承载的不只是一个个时间块，也反映人们如何规划一天、与他人协调，以及为重要的事情腾出空间。Dropbox旗下的Reclaim定位为日历助手，通过AI为任务、习惯和会议寻找时间并调整安排，帮助管理这种复杂性。当输入与预期结果明确时，这种方法效果很好。但人们也会用Reclaim处理不那么直接的日程需求。
随着AI助手与自然语言界面能力增强，人们有了使用Reclaim的新方式。我们设想，用户可以用自己的话描述一个日程目标，即使它不能直接对应某项现有设置或命令。不过，仅凭这些话，还不足以决定真实日历上应发生什么。Reclaim仍需要赋予请求含义的上下文，包括已有日程、用户的空闲时间，以及会影响改动的偏好和约定。
把自然语言请求与相关日历上下文连接起来，可以让人们少花时间判断应该使用哪些设置或操作。但构建这种体验，并不只是给现有产品加上AI界面。我们需要重新思考Reclaim如何把对话请求变成日历变更，同时保留已有的日程安排系统。
让Reclaim面向AI演进，而非推倒重来
对于工程师，重构从Reclaim原本管理日历的方式开始。日历变更意义重大，因为时间很宝贵，而且已安排的事件通常涉及其他人。任何新的AI能力，都应当像Reclaim的自然延伸，并与已有的排程逻辑协同工作。
在重新设计前，Reclaim主要通过两种方式修改日历。用户可以自行进行具体改动，例如移动事件或更新设置。同时，Reclaim的自动排程器在后台运行：寻找任务、专注工作和午餐等重复习惯的合适时间时，它会考虑每个人的偏好与空闲情况，并在日程变化时调整这些时间块。
AI智能体的出现，带来了潜在的第三种使用方式。用户不一定要选择具体设置或命令，而可以用自己的话表达希望做什么。智能体随后解释请求，查看日历中相关部分，判断Reclaim能够怎样提供帮助。
但在引入智能体前，我们需要解决若干挑战。大型语言模型根据训练数据中的模式生成答案，因此可能以不同方式解释同一个请求。例如，“明天给这件事腾出时间”这样的开放请求，可能让智能体寻找一个空闲时间块、创建新事件，或者移动日历中已有的安排。每种选择对用户日程的影响不同，有些也会影响其他人的日历。
这种可变性，让AI智能体有别于Reclaim已经支持的两条路径。虽然三类参与者形成决定的方式不同，它们都必须依赖同一套排程逻辑。建立一条只供AI使用的路径，会重复实现功能，也会使不同界面的行为更难保持一致。我们需要一个系统，把模型连接到正确的日历信息和Reclaim能力，同时控制它如何使用这些能力。最终，我们设计了一个在Reclaim现有架构内运行的智能体平台。
构建智能体平台
智能体平台为模型提供相关的日历详情与Reclaim功能访问能力，同时控制模型能够看到什么、做什么。模型解释用户的话，判断用户意图；智能体则通过提供Reclaim指令、相关日历上下文和工具来管理更大的过程。工具允许它请求Reclaim查询信息或执行具体操作。工具返回信息后，智能体可以把信息再发给模型，用于决定下一步。这种反复交互称为智能体循环。
在这个过程中，Reclaim只向智能体提供与当前请求相关的日历信息和工具，而不是一次性开放所有内容。这帮助智能体专注当前任务，并将操作限制在适当范围。对于更复杂的请求，智能体可以把其中一个具体部分交给专门的子智能体。内部检查清单和审查步骤帮助整个请求保持在预定轨道上。
最终，我们选择自行构建智能体循环、工具和上下文收集系统，并直接连接模型提供商，而不是依赖通用的智能体框架。原因是，我们起初探索的一个框架落后于希望使用的提供商API，而且包含比Reclaim所需更多的结构。自行拥有这些部分，使我们能够围绕排程需求设计它们，更快采用提供商的新能力，并在不重建其余平台的情况下使用不同模型提供商。这也意味着要维护更多代码，不过，用智能体辅助处理这些代码抵消了一部分额外工作。
同一套工具系统以两种方式支持模型上下文协议（MCP）。在Reclaim的智能体循环内部，MCP客户端让智能体可以使用其他服务的兼容工具。另一方面，Reclaim的MCP服务器通过支持的AI客户端（包括Claude和ChatGPT）提供部分Reclaim工具。这些客户端采用自己的模型和智能体循环，但能够调用Reclaim内部使用的同一套工具。
智能体平台帮助Reclaim处理开放请求，但对于它提出的任何改动，我们仍需要保护措施。用户需要能够在这些变更写入实际日历之前审查它们。
让日历变更保持一致，并且可以审查
在内部，Reclaim将每项排程能力表示为一个 Schedule Action。这是我们对标准操作的内部称呼，例如创建或更新事件、改变RSVP回复、查询空闲时间。无论请求来自用户、自动排程器还是智能体，都会使用同一个Schedule Action类型，包括相同的验证和提交过程。
这条共用路径很重要，因为一次日历变更可能影响多个事件。移动会议可能改变某人的空闲情况，也可能让Reclaim调整用户日历上其他位置的灵活事件。如果每类参与者使用独立实现，工程师就需要重复这些规则，并在产品演进时保持各个版本一致，久而久之会变得繁琐。由于三类参与者使用相同的Schedule Action，工程师可以在一个地方改变操作行为，而不是更新三个版本。这帮助Reclaim在不同界面间表现一致。
但即使Reclaim以一致方式处理变更，用户仍需要判断更广泛的影响是否符合其意图。因此，我们开发了预览模式（Preview Mode）：它提供一个临时日历版本，让用户在改动应用到实际日历前，审查AI建议和通过聊天提出的变更。用户能够在变更生效前，看到事件或设置的调整会怎样影响其余安排；随后确认变更符合预期，并在向其他参与者发送日历更新前，检查对共享事件的影响。
为了让预览模式足够快，我们把自动排程器重构为纯函数。其中一个含义是，它能够计算拟议日程，而不向用户的实际日历保存任何内容。用户每次调整预览时，Reclaim都可以重复计算。由于繁忙日历和多参与者会议需要大量数据，Reclaim在适合快速检索的数据存储Redis中保留容易访问的数据副本。每当事件移动，它还会更新预览中参与者的空闲情况，使下一次计算反映当前拟议的日程。
让AI工作流程连贯起来
现在，从自然语言请求到经过审查的日历变更，Reclaim有了一条一致路径。智能体平台把模型连接到相关日历信息与产品功能；Schedule Actions让拟议更新经过产品的排程逻辑；预览模式则在任何改动到达日历或其他参与者之前，将影响展示出来。这些部分结合起来，为Reclaim扩展了AI能力，同时保留人们已经依赖的排程体验。
这项工作也进一步说明，AI要在正在进行的工作流程中发挥作用，需要什么：模型需要周边信息来理解请求，需要受控的执行方式，也需要在结果继续推进之前进行审查。在Reclaim中，一个排程目标可以从对话转变为拟议日程，再转变为批准后的日历更新，而不必要求用户先把它翻译成具体设置或命令。
这次重构的长期价值，是让产品能够自由演进而不走向割裂。随着AI改变人们求助的方式，Reclaim可以通过同一排程基础引入新能力，而不是每次都增加一套独立体验。对于Reclaim，这为随着模型改善、用户发现新的时间管理方式而扩展AI辅助工作流程，提供了一个实用框架。
～ ～ ～
如果构建创新产品、体验与基础设施让你感到兴奋，欢迎与我们一起构建未来！访问 dropbox.jobs 查看开放职位。
暂无评论内容