软件开发早期，部署是一件很“手工”的事：代码打包、通过 FTP 上传服务器、SSH 登录、解压、改配置、重启服务，再刷新页面确认有没有报错。任何一个环节出错，都可能需要靠人工备份目录回滚。

后来持续集成/持续交付（CI/CD，Continuous Integration / Continuous Delivery）把这条链路变成了流水线。开发者提交代码后，系统自动跑测试、构建镜像、发布到环境、观察状态，必要时触发回滚。代码从“写完”到“上线”，不再依赖一连串人工搬运。

办公 Agent 正在经历类似的阶段。

现在的大语言模型（LLM，Large Language Model）已经能写周报、整理会议纪要、生成邮件、总结资料、分析需求，真正卡住效率的地方往往不是“生成得不够快”，而是生成结果仍然停在对话框里。内容要进入腾讯文档、Notion、邮箱、问卷、会议系统，还需要用户复制、切窗口、粘贴、改格式、填收件人、检查标题、点发送。

这就是办公场景里的“最后一公里”。

flowchart LR
    A[用户提出任务] --> B[AI 生成内容]
    B --> C{结果在哪里?}
    C -->|停在对话框| D[人工复制]
    D --> E[切换应用]
    E --> F[粘贴并修格式]
    F --> G[发送或归档]

    C -->|进入 Connector| H[选择目标应用]
    H --> I[授权与调用接口]
    I --> J[自动创建文档/发送邮件/写入系统]

办公 Agent 的 CI/CD，本质上就是让 AI 不只负责“生成”，还负责把结果交付到工作系统里。

为什么“生成能力”不是完整生产力

很多 AI 工具已经能完成内容生产，但输出结果通常只是纯文本、Markdown 或一段结构化回答。问题在于，办公流程并不以“对话框里有答案”为结束，而是以“结果被正确放到目标系统”为结束。

一个常见的项目周报流程可能是这样：

这里浪费的不是“思考时间”，而是大量机械动作。知识工作者频繁在应用之间切换，每一次切换都打断当前上下文；当一天里反复执行几十次复制、粘贴、改格式、发邮件，这些动作就会成为真正的效率瓶颈。

CI/CD 解决的是代码交付链路里的人工搬运；办公 Agent 的 Connector 解决的是 AI 输出到业务系统之间的人工搬运。

Connector：把 AI 输出送到目标应用

QClaw V2 的 Connector 可以理解为办公 Agent 的交付层。AI 在 QClaw 里完成任务后，不再只是给出一段文本，而是可以把结果写入指定应用，例如腾讯文档、腾讯问卷、腾讯会议、ima、Notion、QQ 邮箱、网易邮箱等。

Connector 的关键价值不在“模型更会写”，而在“模型写完以后能执行动作”。

图中展示的是 Connector 连接办公应用的入口。对用户来说，这类能力表现为“把结果写入某个工具”；对系统来说，它背后通常包含应用授权、目标选择、格式转换、接口调用和执行状态反馈。

一个完整的 Connector 工作流大致是这样：

sequenceDiagram
    participant U as 用户
    participant A as QClaw Agent
    participant M as 大语言模型
    participant C as Connector
    participant App as 目标办公应用

    U->>A: 整理本周项目进展并写入腾讯文档
    A->>M: 生成结构化周报
    M-->>A: 返回标题、正文、表格、待办项
    A->>C: 请求创建文档
    C->>App: 通过授权接口写入内容
    App-->>C: 返回文档链接和状态
    C-->>A: 返回执行结果
    A-->>U: 给出文档链接和完成状态

这里的“授权接口”通常会涉及 OAuth 2.0。OAuth 2.0 是一种授权框架，用来让第三方应用在用户允许的范围内访问目标服务，而不需要用户把账号密码直接交给第三方。用户完成一次授权后，Connector 可以在授权范围内创建文档、发送邮件或读取必要信息。

用开发里的概念类比，Connector 更像部署阶段的执行器：

没有 Connector 时，AI 只完成 build；加入 Connector 后，AI 开始具备 deploy 能力。

典型场景：周报写入文档

以“整理项目周报并写入腾讯文档”为例，传统方式需要用户经历多次切换：

flowchart TD
    A[让 AI 生成周报] --> B[复制内容]
    B --> C[打开腾讯文档]
    C --> D[新建文档]
    D --> E[粘贴内容]
    E --> F[调整标题层级]
    F --> G[修复表格和列表]
    G --> H[复制文档链接]
    H --> I[发送给团队]

Connector 介入后，流程可以压缩成一个明确的任务指令：

整理本周项目进展，包含：
1. 已完成事项
2. 风险和阻塞
3. 下周计划
4. 需要协同的人

生成后写入腾讯文档，并返回文档链接。

系统需要做的不只是把文本贴进去，还要处理结构映射：

这个环节很重要。办公自动化的体验差异，常常不在“有没有写进去”，而在“写进去以后是不是还能直接用”。如果粘贴后格式全乱，用户仍然需要手工修一遍，自动化链路就只完成了一半。

典型场景：会议纪要发送邮件

邮件场景更接近“带风险的自动交付”，因为发送动作一旦完成，内容就会到达外部收件人。适合的流程不是盲目自动发送，而是把生成、校验和确认拆开。

flowchart LR
    A[会议录音/笔记] --> B[生成会议纪要]
    B --> C[提取行动项]
    C --> D[生成邮件标题和正文]
    D --> E{是否需要人工确认}
    E -->|是| F[用户确认收件人和内容]
    E -->|否| G[按规则直接发送]
    F --> H[Connector 调用邮箱发送]
    G --> H
    H --> I[返回发送状态]

一个更稳妥的任务写法可以是：

根据以下会议记录整理纪要，生成邮件草稿：
- 收件人：项目组 6 人
- 邮件标题：本周需求评审会议纪要
- 正文包含：结论、待办项、负责人、截止时间
- 发送前让我确认

这种写法把“生成”和“发送”之间加了一个人工确认点。内部周报、个人备忘录可以直接写入；对外邮件、合同相关内容、客户沟通内容，最好保留确认步骤。

Multi-Agent：从万能助手到职责拆分

QClaw V2 还有一个 Multi-Agent 能力，也就是“多虾人设”。它允许用户创建多个不同性格、不同专长的 Agent，并让它们承担不同任务。预设角色包括偏写作表达的“无不言”、偏情绪支持和沟通建议的“林且慢”、偏工程实现的“代可行”。用户也可以自定义角色，例如理财分析、运营复盘、代码审查、产品需求拆解等。

图中展示的是多角色 Agent 的入口。它的核心不是“换个头像聊天”，而是把不同任务拆给不同的角色配置：每个 Agent 可以有独立的提示词、行为边界、知识偏好和工具权限。

从工程设计角度看，Multi-Agent 对应的是单一职责原则。一个 Agent 如果同时负责写作、编程、情绪沟通、数据分析、会议纪要、邮件发送，它会变成一个“万能对象”。表面上什么都能做，实际很容易出现角色混乱：写技术方案时语气太营销，处理客户邮件时又过于工程化。

把 Agent 拆开以后，职责会更清楚：

flowchart TD
    U[用户任务] --> O[协调 Agent]

    O --> W[写作 Agent]
    O --> P[产品 Agent]
    O --> E[工程 Agent]

    W --> W1[生成文案/周报/邮件]
    P --> P1[拆解需求/提炼优先级]
    E --> E1[写代码/查问题/评审方案]

    W1 --> C[Connector]
    P1 --> C
    E1 --> C

    C --> D[文档]
    C --> M[邮箱]
    C --> N[会议系统]

Multi-Agent 更适合稳定、重复、边界清楚的任务。例如：

Multi-Agent 的价值不是让用户同时拥有更多聊天窗口，而是让复杂办公流程具备“分工”。一个角色负责生成，一个角色负责检查，一个角色负责交付，自动化链路会更接近真实团队协作。

Connector 和 Multi-Agent 的组合方式

Connector 负责交付，Multi-Agent 负责分工。两者组合起来，办公 Agent 才能从“会回答问题”变成“能跑流程”。

一个需求评审后的自动化流程可以设计成这样：

flowchart TD
    A[输入会议记录] --> B[会议 Agent 提取结论和待办]
    B --> C[产品 Agent 整理需求变更]
    C --> D[工程 Agent 标注技术风险]
    D --> E[写作 Agent 生成纪要邮件]
    E --> F[用户确认]
    F --> G[Connector 写入腾讯文档]
    F --> H[Connector 发送邮件]
    G --> I[返回文档链接]
    H --> J[返回发送状态]

这条链路里，每个角色都只处理自己擅长的部分：

这种模式很像工程里的流水线加微服务：流水线负责顺序和状态，微服务负责单一能力。办公 Agent 也需要类似结构，否则所有能力都堆在一个对话框里，越用越难维护。

哪些场景适合接入办公 Agent CI/CD

不是所有任务都应该自动化。判断一个办公流程是否适合接入 Connector，可以看三个条件：

1. 是否高频出现；
2. 是否有固定格式；
3. 是否存在明确的目标应用。

满足这三个条件，自动化收益通常比较明显。

一个简单判断标准是：如果任务失败后的修复成本很低，可以提高自动化程度；如果任务失败会影响客户、资金、权限或生产系统，就必须加入人工确认和审计记录。

上手时要先跑通一条小流水线

办公 Agent 自动化不要一开始就做复杂编排。更稳的方式是挑一个每天都会重复的低风险流程，把它做成端到端闭环。

可以从这样的流程开始：

把今天的工作记录整理成日报，要求：
1. 按“完成事项 / 风险问题 / 明日计划”分段
2. 用表格列出任务、状态、负责人
3. 写入腾讯文档
4. 返回文档链接

一条小流水线跑通后，再逐步增加能力：

当流程稳定后，再把 Multi-Agent 加进来。例如日报场景可以拆成三个角色：记录整理 Agent 负责清洗输入，项目管理 Agent 负责识别风险，写作 Agent 负责生成最终版本，Connector 负责写入文档。

使用 Connector 时要注意的坑

办公 Agent 一旦具备执行能力，就不再只是“聊天工具”。它会访问文档、邮箱、会议和知识库，所以工程上必须关注权限、可靠性和可追踪性。

权限要按最小范围授权

能只写入文档，就不要授权读取全部文档；能只创建草稿，就不要默认允许直接发送。OAuth 2.0 授权时要关注范围，尤其是邮箱、企业知识库、会议记录这类敏感系统。

外发动作最好加确认

邮件、客户通知、对外文档共享都属于外发动作。AI 可以生成草稿，也可以填好收件人和标题，但发送前保留确认步骤会更安全。

生成邮件草稿并列出收件人，等待我确认后再发送。

格式转换要反复校验

Markdown 到文档块、表格到目标应用原生表格、代码块到富文本样式，都可能出现格式损耗。高频流程最好固定模板，让 Agent 按固定结构输出，减少转换失败。

重试要避免重复创建

如果网络抖动导致 Connector 不确定任务是否执行成功，简单重试可能创建两份文档或重复发送邮件。理想的实现应当支持幂等设计，也就是同一个任务多次执行不会产生重复副作用。用户侧可以通过任务命名、日期标识、确认提示降低重复风险。

关键流程需要日志

自动化流程越长，越需要知道哪一步失败了。是模型生成失败、授权过期、目标应用接口报错，还是用户确认超时？没有日志，排查会很困难。

办公 Agent 的真正变化

办公 Agent 的竞争点正在从“回答得好不好”转向“能不能接住真实工作流”。单纯生成内容，只是把知识工作的一部分搬进对话框；Connector 把文档、邮件、会议、问卷等系统连接起来，才让 AI 输出有了落点。

QClaw V2 的 Connector 对应交付层，Multi-Agent 对应分工层。前者减少复制粘贴、切换应用和格式修复，后者让不同类型的任务由不同 Agent 承担。组合起来，办公自动化就不再是“问一句、答一句”，而是可以形成一条从输入、生成、检查到交付的流水线。

软件开发里的 CI/CD 改变了代码上线方式；办公 Agent 的 Connector 化，也会改变 AI 在日常工作中的位置。AI 不只是在对话框里生成答案，而是开始进入文档、邮箱、会议和团队协作系统，成为工作流的一部分。