桌面助手在关键时刻应该可靠而克制

Core Claim

企业税务和法律工作里，智能体最危险的时刻，不是它把一个概念讲错了，而是它在没有人看见的情况下改变了外部世界。邮件草稿可以修改，引用缺口可以补，错误的解释可以被复核人拦下来；但如果一封发给客户的邮件已经离开 Outlook/M365，收件人、法律依据、语气和信心等级都已经进入真实业务关系，系统就不能再把它当成一次普通的模型失误。

Lawless Desktop Assistant 是围绕这个边界做的桌面智能体原型。它可以读取授权后的 Outlook/M365 邮箱，识别事项上下文，准备原生 Outlook 草稿，把来源和主张挂到结构化交付物上，并把定时运行保存成可恢复的会话。它不能静默发送、回复、转发、删除、归档或发布工作成果。高风险动作要么从 MCP 工具面上消失，要么被运行时拒绝，要么进入 ActionGate，由人类复核人明确批准。

这个设计看起来没有“AI 自动操作你的电脑”那么戏剧化，但更适合法律和税务这样的专业工作。项目的核心判断是：桌面智能体应该先成为一个本地授权与审查工作流框架，把模型输出变成草稿、来源、主张、状态和待批准动作；只有在人类确认之后，外部世界才应该被改变。

任务看起来很小：写好草稿，然后停住

一个普通的税务工作早晨，合伙人或资深顾问打开 Outlook，可能会看到几类消息：跨境预提税问题、条约解释请求、上一份备忘录的追问、会议安排、客户补充材料。智能体真正应该帮忙的地方，是那些机械但耗时的环节：读取邮件正文，识别事项，检查草稿箱里是否已有草稿，找到事务所模板，做适度研究，写出干净的 HTML 邮件，并把它保存到 Outlook 原生草稿箱。

最后一步故意很平淡。真正的产出不是已经发出去的邮件，而是一封等待审查的草稿。

这个选择改变了整个系统。草稿仍然在专业人士的审查界面里，所以可以被自动创建；结构化交付物仍然是内部工作成果，所以可以被系统提交和校验；但 send-mail、reply、forward 这类动作不应该在后台自动发生。当前 M365 策略暴露的是读取和准备工具，例如邮件列表、邮件读取、草稿创建、日历读取、事件创建、To-Do 读取；隐藏的是发送、回复、转发、删除、移动、创建规则、修改邮箱设置、上传文件、分享网盘项目、移除账号等会改变外部状态的工具。

这不是表面上的权限列表，而是一条职业规则：准备可以自动化，承诺必须被审查。

为什么通用桌面智能体不够

许多桌面智能体演示把屏幕当成一个通用操作面：只要模型能点击、输入、浏览、调用工具、记住上下文，它就看起来能做很多事。但税务和法律工作不是一个普通的控制问题，而是一个带有控制面的信任问题。

税务复核人需要知道的，不只是“模型回答了什么”。更重要的是：

• 它读取的是哪封邮件、哪个事项、哪个客户记录？

• 草稿里的法律或税务判断由哪些来源支持？

• 哪些主张是直接支持，哪些只是类比、背景或反向材料？

• 它真的在 Outlook 里创建了草稿，还是只在聊天里写了一段文字？

• 引用在 Outlook 渲染后还能不能点击、还能不能对应到真实来源？

• 有没有动作已经改变了外部世界？

• 如果这是定时任务，它读了什么、调用了什么工具、会话在哪里恢复？

这些问题把桌面版本推向了“工作流框架”，而不是一个单纯聊天助手。这个框架做三件事：控制模型能看见哪些工具；把工作成果变成带来源、状态和主张的类型化交付物；在外部动作发生前，记录一个必须由人批准、拒绝或手动接手的节点。

Outlook/M365 是授权边界

在这个项目里，Outlook 不只是输入来源。它是内部准备和客户可见沟通之间的边界。

邮件分诊技能围绕按文件夹限定的读取设计：从当前收件箱读取，检查当前草稿箱，并参考最近生成的草稿交付物，再决定是否创建新草稿。这样做很重要，因为全邮箱读取可能把已经删除、过期或无关的邮件重新带回工作流。专业服务里，“已经有草稿但又生成一封”不是小问题，它可能制造冲突意见、打乱复核人的判断，也会让用户在最需要信任的地方失去信任。

复杂邮件不能只做摘要。智能体需要判断紧急程度和主题，把消息关联到客户或事项，搜索事务所认可的模板，在邮件提出法律或税务问题时做必要研究，然后写出结构化 HTML 草稿。邮件正文也要适配原生邮箱：段落使用 <p>，小标题用轻量 <strong>，真实检索到 URL 的来源才做成可点击链接，没有验证的引用只能保留为文本，不能伪装成链接。

草稿会配套生成一个 email_draft 交付物。这个交付物保存原始邮件引用、草稿链接、事项 id、复核摘要、来源引用，以及“打开草稿”这样的动作意图。复核人可以在 Outlook 里读草稿，同时在桌面应用里看到来源和审查元数据。

技术重点不在 Outlook 本身。Gmail、SharePoint、文档管理系统、税务研究连接器都可以使用同样模式。关键是每个连接器都必须有明确策略：哪些内容可读，哪些成果可准备，哪些状态可以写入内部工作区，哪些动作必须人工确认。

来源预检把引用变成运行时状态

税务和法律智能体里，最重要的交付物常常不是最终备忘录，而是中间证据包。专家需要根据这个证据包决定：这段备忘录或这封邮件是否值得信任。

Lawless Desktop 的交付物运行时把来源和主张当作一等字段。一个法律研究交付物可以包含来源 id、标题、引用、URL、摘录、jurisdiction 字段，以及指向来源 id 的主张对象。交付物提交时，运行时不会只是把 JSON 存起来，而是会检查交付物类型是否有效、必填字段是否存在、正文里的引用标记是否能解析、主张是否指向真实来源 id、来源链接是否可打开、摘录和引用是否在可行时匹配抓取文本、邮件草稿是否有必要的收件人类元数据。

因此复核人看到的不是一团无法审查的文本，而是一组可操作状态：

• ready 表示没有发现阻塞性的机械问题。

• ready_with_warnings 表示可以进入审查，但存在来源、引用、摘录或门控动作风险。

• needs_attention 表示复核人不应把它当作干净工作成果。

• blocked 表示交付物连基本结构条件都没有通过。

这里借用了评测系统里的一个关键经验：模型必须产出的对象本身，也是系统可改进的一部分。普通段落很容易藏住缺失支持；类型化交付物有可检查的把手。如果主张 C1 指向来源 S99，而 S99 不存在，运行时可以在复核人花时间读完整段文字之前先把问题标出来。

当前交付物运行时的验证主要是合成评测，但它击中了产品真正关心的失败模式：有效和无效交付物、无法解析的引用、主张指向不存在的来源、来源文本匹配和不匹配、链接失败、伪造验证器标记、邮件草稿字段缺失、外部动作进入 ActionGate、批准、拒绝、完成、手动接手和执行失败。这个阶段最需要的不是泛泛的“模型效果很好”，而是底层工作流框架能不能稳定拦住错误形态。

ActionGate 是草稿和外部动作之间的停顿

ActionGate 让“关键时刻要克制”这件事变成系统行为。

交付物运行时会识别动作意图。只要动作看起来会外部化结果，例如 send、submit、delete、remove、archive、move、reply、forward、post、publish、share、upload、deliver、transmit、modify email、batch modify email 等，就会被强制放入 ActionGate。ActionGate 有自己的状态：pending、approved、rejected、done、manual handoff、failed。它还记录交付物 id、运行 id、动作标签、payload、时间戳、决策备注和执行结果。

复核人可以批准、拒绝，或者在连接器不能安全执行时改为 manual handoff。批准不等于执行。运行时仍然要求一个合法的执行完成状态，非法决策或非法完成状态会被拒绝。这个区分很重要，因为很多批准系统把“用户点了 approve”和“事情已经发生”混在一起。这里把批准和执行拆成两个状态转换。

放到邮件审查里，智能体可以准备邮件，也可以创建一个打开 Outlook 草稿的动作；但人类复核人仍要阅读草稿、核对依据、改语气、确认收件人，并决定是否真的应该发出。如果智能体提出更危险的动作，ActionGate 会让危险可见，而不是把它藏在工具调用历史里。

定时任务需要痕迹，不只是提醒

专业助手很容易想做定时任务：每天早上分诊收件箱，准备简报，检查待处理草稿，更新事项记录，总结昨天发生了什么。问题是，定时任务经常发生在没人盯着的时候。

桌面调度器的处理方式是让每一次运行都可观察、可恢复。定时任务保存提示词、cron 表达式、选择的技能、可读名称、运行状态和最终会话。执行过程中，应用会记录当前工具、当前文本、流式事件和实时会话 id；结束后，会写成一个可重新打开的会话记录。

定时运行还有更严格的权限模式：允许创建草稿和提交交付物；拒绝外部化 MCP 动作，除非它们本质上仍是草稿式创建；文件写入限制在已知本地工作成果目录；命令执行被阻断。这个折中很实际：无人值守时，系统仍能做准备性工作，但它改变外部世界的能力要比有人在场时更弱。

当前桌面版本默认的定时种子任务是工作日早晨分诊。每日简报技能也遵循同一原则：收集昨天的草稿、To-Do 项和日历事件，汇总今天的日程和到期任务，给用户创建一封简报草稿，但绝不自动发送。草稿出现本身就是健康信号；如果它没出现，用户也能回到运行轨迹里排查，而不是只能猜自动化是不是失效了。

专家怎么接手

这个项目不假设税务专家会被替代。它改变的是专家注意力的落点。

没有工作流框架时，复核人可能要从空白回复开始：找旧邮件线程，找模板，回忆适用依据，写分析，粘引用，再检查语气。有了框架，复核人的起点变成一个准备好的包：Outlook 原生草稿、短摘要、原始邮件链接、带来源的法律主张，以及仍然被 ActionGate 拦住的动作。

这不会消除专业判断，反而会集中专业判断。专家要检查的是：问题有没有识别对，引用的依据是控制性规则还是背景材料，假设有没有披露，语气是否适合客户关系，合伙人是否会要求更保守的表达，以及这封邮件到底该不该发。

本地证据里的 Sarah Chen 税务 persona 是一个有用的复核目标：IRAC 结构、保守解释、IRC 和 Treasury Regulation 的完整引用、置信等级、多路径分析、风险量化和披露意识。persona 不是资深税务律师的替代品，它的作用是把专家期望显性化，让草稿可以被一套更清楚的标准检查。

当前结果和边界

当前证据支持四个具体结论。

第一，桌面运行时已经有可工作的 M365 暴露策略。验证脚本确认准备类工具会暴露，高风险工具会隐藏，并且暴露和隐藏的工具数量会回写到连接状态里。

第二，交付物运行时能捕捉项目真正关心的机械失败：schema 错误、无法解析的引用、主张来源缺失、来源匹配或不匹配、链接失败、邮件草稿字段缺失、外部动作进入 ActionGate、批准/拒绝、manual handoff 和执行器失败。

第三，默认邮件提供方会根据运行时可用性调整。应用读取已保存的 Outlook/Gmail 偏好，和当前连接的 MCP 客户端对齐；首选提供方不可用时会回退；MCP 可用性变化后会重写引擎提示词；断开的 Gmail 不会继续出现在设置选择器里。

第四，定时任务被当作可恢复工作会话，而不是不可见的 cron 任务。调度器会保存任务定义、可读元数据、运行状态、执行会话，并记录耗时，用于后续计费或工作流复核。

有一个内部目标需要谨慎表述：早期项目笔记把目标写成把 30-40 分钟的研究和起草，压缩到 2-3 分钟复核工作流。当前本地证据支持的是这套工程工作流框架已经存在，并能围绕这个目标运行；它还不能证明在不同事务所、不同税种、不同复核人、真实客户环境里都有稳定的统计型效率提升。

限制

Lawless Desktop Assistant 是本地优先，这正是它适合 Outlook/M365 和事务所内部工作的原因，同时也带来限制。应用必须运行，定时任务才会触发；连接器必须保持授权；Outlook 和 SharePoint 的权限问题会阻断模板或消息读取；按文件夹限定的读取能减少旧邮件混入，但不能消除所有邮箱边缘情况。

来源预检可以抓断链、缺失引用 id、引文不匹配和不支持的交付物结构；它不能独立判断一个税务立场是否审慎，客户是否遗漏关键事实，或者合伙人的风险偏好是否变化。ActionGate 也只解决一个窄问题：防止智能体静默执行高风险外部动作。它不会让一个被批准的动作自动变得正确。如果复核人批准了错误草稿，系统能保留决策轨迹，但专业判断仍然属于人。

更大的产品边界是，不是每个法律工作流都适合桌面。卖家侧专利和 TRO 工作流更适合云端工作区，因为用户需要低配置入口：上传材料、看到进度、审查交付物、之后再回来继续。桌面版本适合另一类场景：专业环境已经有本地授权、Outlook 审查、内部定时任务和专家批准，产品价值就在这些边界上。

我从这个项目里学到的东西

最有用的抽象不是“智能体自治”，而是“经过授权的准备工作”。

一旦这个词清楚，设计选择就不再神秘。读取工具更容易开放；草稿工具有价值，因为它保留了人工复核；SubmitArtifact 是模型输出和复核人注意力之间的桥；来源预检把引用变成状态；ActionGate 让危险动作可见；定时任务只有在留下记录，并且权限比实时工作更严格时，才适合自动运行。

这就是我希望专业桌面智能体具备的形态。它应该帮助专家更快到达复核决定；它应该让来源、假设和动作意图可检查；当草稿即将变成客户沟通时，它应该停下来，展示工作成果，然后等待人。

参考材料

1. lawless-desktop-agent-foundry/src/desktop/main/engine-adapter.ts
2. lawless-desktop-agent-foundry/src/desktop/main/artifact-store.ts
3. lawless-desktop-agent-foundry/src/desktop/main/scheduler.ts
4. lawless-desktop-agent-foundry/scripts/verify-artifact-runtime.mjs
5. lawless-desktop-agent-foundry/scripts/verify-ms365-tool-policy.mjs