代理助手：安全的日历和Gmail集成

我的观点是：构建安全、可用的代理助手，以处理日历、Gmail和连接的应用程序，需要设计一个以权限为先的运行时，将规划与行动分开，并从一开始就在执行层中预先构建审计和回滚流程。本文提供了一个紧凑的工程检查清单和可运行的提示，以实现这一目标。

代理助手的权限设计

从每个用户的OAuth和最小权限范围开始。使用用户绑定的OAuth，而不是共享服务账户，除非管理员明确要求进行域委托。Google关于细粒度权限范围的文档是基础；将每个代理能力映射到单个OAuth范围，并记录该范围的可读意图。保持令牌不出现在提示中。将其存储在一个保险库中，仅在执行服务的调用时注入凭证，该服务会强制执行策略。

我们观察到，认为权限是产品用户体验的团队，具有明确的同意界面和范围预览，收到的支持工单要少得多。我们遇到的一个问题是，因天真的刷新逻辑导致令牌的泛滥；集中管理刷新并定期轮换刷新令牌。

规划与行动

将助手分为规划者和执行者。规划者生成离散的行动计划：阅读最近的线程，提出两个会议时间，撰写草稿邮件。执行者仅在政策检查通过后，以及对于敏感操作，经过人工确认后才执行。这一模式防止模型即兴生成特权操作，并使授权可审计。

实际权衡：为人工确认带来更长的延迟与降低风险。对于许多日历和邮件操作，30到60秒的人工实时等待是可以接受的。对于高频任务，批量批准比逐个操作点击效果更佳。

测试、日志和恢复

每个操作都必须生成一个不可变的审计条目，包含请求的意图、规划者输出、政策决策、执行者调用和返回的API响应。保持可重放的指令格式，以便进行重放和回滚。提供一键撤销最近N个操作的功能，并提供创建补偿事件的恢复流程，例如取消一个事件并发送纠正的后续通知。

我们观察到，没有外部政策引擎的提示级别保护是无效的。在实践中，模型会建议看似合理但违反政策的更改。当置信度低于校准阈值时，拒绝任何写入操作的执行门减少了这些事件的发生。

产品和工程检查清单

1. 每个用户的OAuth，具有最小权限范围和明确的同意文本。 2. 令牌保险库和在运行时注入凭证的执行服务。 3. 规划者/执行者的分离与政策检查。 4. 对于敏感操作的人工干预升级。 5. 不可变的审计日志和可重放的操作格式。 6. 具有清晰用户界面的撤销和补偿流程。

将产品用户体验与设计人机工作流程中描述的工作流程模式联系起来，并利用AI代理与聊天机器人中关于代理区别的初学者指南来证明规划者与执行者的分离。

自己试试看。下面的提示演示了规划者输出与执行者安全指令的不同。期待来自规划者的简短JSON样式计划和来自执行者的简短确认。

这个提示要求模型生成候选会议时间的受限计划和理由；将其作为规划者使用。期待2到3个候选时间段和一句话理由。

你是一个会议规划者。用户今天有3个空闲时段：上午10:00，下午2:30，下午4:00。返回三个候选会议时间，采用ISO格式，并对每个时间段给予一句话的理由，以及一句话的隐私说明，说明邀请是否涉及外部电子邮件。

这个提示是为了执行者。它期待人在创建事件之前提供人类确认令牌以及显式的政策检查通过。

执行者：给定用户确认令牌X和规划者计划Y，只有在policy_check(policy_id:calendar_write)返回通过时，调用Calendar.CreateEvent，字段为{start,end,attendees,summary}。如果policy_check失败，返回失败代码和所需的人类操作。

一个反对论点是严格控制减缓了采用速度。我的估计是，当团队强制执行这些模式时，早期用户保留率改善，因为信任增加，尽管初始激活速度较慢。权衡很明显：如果没有这些控制，更快的发布会带来可衡量的风险和更高的修复成本。