1. 从“对话框”到“工位”：AI Agent 落地的分水岭在哪

很多人对 AI 办公的理解还停留在“打开一个网页，把需求敲进去，复制结果再粘贴到文档里”。这个阶段我称之为“对话框阶段”——AI 是一个外挂的问答机器，你问它答，答完你手动搬运。这个模式的问题非常明显：上下文靠人脑记，流程靠人手串，一旦任务超过三步，人就成了整个系统里最不可靠的那个环节。

AI Agent 要跑进真实工作流，核心变化只有一个：它不再等你发指令，而是自己判断“下一步该干什么”。这听起来像一句废话，但真正落到办公场景里，差别是巨大的。对话框模式下，你问“帮我写个周报”，它给你一段文字；Agent 模式下，你告诉它“每周五下午把本周的项目进展整理成周报发给相关同事”，它会自己去翻记录、汇总、排版、确认收件人、发送，中间遇到信息缺失还会主动来问你。

我观察下来，AI Agent 在办公场景真正跑通的关键，不在于模型有多聪明，而在于三个“接得上”：接得上数据源（能读到邮件、文档、表格、聊天记录）、接得上操作权限（能写文档、发消息、改状态）、接得上判断逻辑（知道什么情况该做什么、什么情况该停下来问人）。这三件事缺一个，Agent 就退化成“高级一点的对话框”。

这篇文章我想聊的是两个最典型、也最容易跑通的 AI 办公场景：信息聚合与流转、多步骤任务编排。这两个场景覆盖了绝大多数办公室里的重复性工作，也是目前 Agent 落地最扎实的方向。不管你是刚接触 Agent 概念的产品经理，还是想给自己团队搭一套自动化流程的技术负责人，这两个场景拆开来看，都能找到可以直接抄作业的部分。

提示：本文讨论的 Agent 落地，默认基于“有明确数据源和操作接口”的办公环境。如果你的工作数据完全散落在个人设备里、没有任何结构化接口，那第一步不是上 Agent，而是先把数据归拢到可访问的地方。

2. 场景一：信息聚合与流转——让 Agent 当“信息搬运工”

2.1 这个场景到底在解决什么问题

办公室里有一类工作，技术含量不高但极其耗神：把散落在不同地方的信息收集起来，整理成统一格式，再分发到该去的地方。比如每周的项目进度汇总、每月的报销单据整理、客户反馈的归类分发、会议纪要的提取与派发。这些活的共同特点是：信息源分散、格式不统一、时效性要求高、重复性极强。

人做这些事的问题不是做不好，而是做久了会烦、会漏、会拖延。我见过太多团队，周报制度推行三个月就名存实亡，不是因为大家不想写，而是“收集-整理-分发”这条链路太长了，中间任何一环卡住，整个流程就断了。Agent 在这个场景里的价值，不是替代人的判断，而是把“搬运”这个动作自动化，让人只负责判断和决策。

2.2 拆解一条完整的信息流转链路

我拿一个最常见的场景来拆：每周项目进度汇总与分发。这条链路拆开来看是这样的：

1. 触发：每周五下午 4 点，或者某个项目状态字段变为“待汇总”时触发。
2. 采集：从项目管理工具拉取本周所有任务的状态变更记录，从聊天群组里提取本周的关键讨论，从共享文档里读取本周更新的内容。
3. 清洗：把不同来源的信息统一成同一套字段——任务名、负责人、当前状态、本周进展、下周计划、风险点。
4. 生成：按照固定模板生成周报草稿，把缺失的字段标出来。
5. 确认：把草稿发给项目负责人确认，负责人可以修改或补充。
6. 分发：确认后发送到指定群组或邮件列表，同时归档到知识库。

这六步里，第 2、3、4、6 步是 Agent 可以完全接手的，第 1 步是配置一次就固定的，第 5 步必须留给人。很多人搭 Agent 失败，就是因为想把第 5 步也自动化掉——让 Agent 自己判断“这个进展写得对不对”，结果要么过度自信发出去一堆错误信息，要么过度保守什么都来问，反而更累。

2.3 采集环节的坑：数据源比你想象的脏

我实际搭这套流程的时候，最大的时间不是花在写生成逻辑上，而是花在处理数据源的脏数据上。举几个我踩过的真实例子：

• 项目管理工具里，任务状态字段有人填“进行中”，有人填“in progress”，有人填“推进中”，还有人干脆空着。
• 聊天群组里提取关键讨论，结果把“今天午饭吃什么”也提取进来了。
• 共享文档里，有人用标题层级标记进展，有人用加粗，有人用批注，格式完全不统一。

处理这些问题，我的经验是不要试图让 Agent 去理解所有格式，而是先做一层标准化映射。具体做法是维护一张映射表，把常见的状态写法归一到标准值：

这张表看起来笨，但它比让模型去“猜”要可靠得多。模型猜错的成本，远高于你花半小时维护一张映射表。而且这张表是可以逐步积累的——每次发现新的写法，加一行就行。

注意：采集环节一定要做“空值兜底”。如果某个任务的负责人字段是空的，Agent 不能自己编一个名字填进去，而应该标记为“待确认”并在确认环节高亮出来。我见过一个团队因为 Agent 自动填了错误的负责人，导致周报发出去后当事人完全不知道自己在负责这个任务。

2.4 生成环节：模板要“死”，内容要“活”

生成周报草稿这个环节，很多人喜欢让模型自由发挥，结果每次格式都不一样，读的人很痛苦。我的做法是模板固定、内容填充。模板长这样：

本周进展： - [任务名]：[状态] | [负责人] | [本周具体进展] 下周计划： - [任务名]：[计划内容] | [负责人] 风险与阻塞： - [任务名]：[风险描述] | [需要谁支持]

Agent 要做的，是把采集到的结构化数据填进这个模板里。如果某个字段缺失，就填“待补充”，而不是让模型去编。这样做的好处是：格式永远一致，读的人一眼就能找到关键信息；缺失的地方一目了然，确认的人知道该补什么。

至于“本周具体进展”这种需要一定概括能力的字段，可以让模型基于采集到的原始记录生成一句话摘要，但一定要限制长度（比如不超过 50 字），并且要求它只基于已有信息概括，不允许添加原文没有的内容。我通常会在提示词里加一句：“如果原始记录中没有明确说明进展，就填‘本周无明确进展记录’，不要推测。”

2.5 分发环节：权限和确认是两条红线

分发看起来简单，其实是整个链路里风险最高的环节。发错群、发错人、发了不该发的内容，后果可能很严重。我的做法是：

• 分发目标写死在配置里，不让 Agent 自己判断“该发给谁”。配置一次，之后每次都用同一套目标。
• 发送前必须有人确认。确认的方式可以很简单——Agent 把草稿发到一个只有负责人能看到的地方，负责人回复“确认”或直接修改后回复“确认”，Agent 才执行发送。
• 发送后留痕。每次分发都记录时间、内容摘要、确认人、发送目标，方便追溯。

这三条看起来是“不信任 Agent”，但实际用下来，正是这三条让团队愿意把这件事交给 Agent。因为大家知道，最终发出去的东西是经过人确认的，Agent 只是把前面的脏活累活干了。

3. 场景二：多步骤任务编排——Agent 当“流程调度员”

3.1 什么任务适合交给 Agent 编排

信息聚合解决的是“把东西收拢再发出去”，多步骤任务编排解决的是“按顺序做一串事，中间还要根据情况做判断”。典型的例子包括：新员工入职流程（开通账号、分配设备、拉群、发指引）、客户投诉处理流程（记录、分类、派单、跟进、回访）、内容发布流程（撰写、审核、排版、发布、监测）。

这些流程的共同特点是：步骤多、有依赖关系、中间有判断分支、涉及多个系统。人来做不是不行，但容易漏步骤、容易在判断分支上出错、容易因为某一步卡住就整个停摆。Agent 的价值在于：它不会忘、不会烦、可以同时跑很多条流程，而且每一步都有记录。

但要注意，不是所有多步骤任务都适合 Agent。我总结了一个简单的判断标准：如果这个流程的每一步都能用“输入-处理-输出”描述清楚，且判断条件可以写成明确的规则，那就适合；如果大量依赖人的主观判断和临场发挥，那就不适合，或者只适合把其中一部分自动化。

3.2 把流程拆成“节点”和“边”

搭多步骤 Agent 的核心工作，是把一个模糊的流程拆成明确的节点和边。节点是“要做的一件事”，边是“做完之后下一步去哪”。我拿“客户投诉处理”来举例：

• 节点 A：接收投诉信息（来源可能是邮件、表单、聊天消息）。
• 节点 B：提取关键字段（客户名、问题类型、紧急程度、涉及产品）。
• 节点 C：根据问题类型和紧急程度判断派给哪个处理组。
• 节点 D：生成工单并派发。
• 节点 E：等待处理组反馈。
• 节点 F：根据反馈判断是否需要升级或回访。
• 节点 G：记录处理结果并归档。

边就是这些节点之间的连接关系，比如 A→B→C→D→E→F→G，其中 C 到 D 之间可能有一个判断：如果紧急程度是“高”，直接派给值班负责人；如果是“中”或“低”，走正常派单流程。F 到 G 之间也有判断：如果客户反馈“未解决”，回到 D 重新派单；如果“已解决”，进入 G。

拆到这个粒度，Agent 要做的就清晰了：每个节点是一个独立的处理单元，边是控制逻辑。这样做的好处是，任何一个节点出问题，你可以单独调试那个节点，而不需要把整个流程推倒重来。

3.3 判断分支怎么写才可靠

多步骤编排里最容易出问题的就是判断分支。我见过太多 Agent 在“如果……就……”这里翻车。翻车的原因通常有两个：判断条件写得太模糊，或者判断依据的数据质量太差。

判断条件模糊的例子：“如果客户情绪激动，就优先处理。”什么叫“情绪激动”？模型可能把“我很着急”判断为激动，也可能把“你们怎么回事”判断为激动，还可能把“希望能尽快回复”也判断为激动。这种模糊条件，不同时间跑出来的结果可能完全不一样。

我的做法是把判断条件量化。还是上面这个例子，改成：“如果投诉内容中包含‘紧急’‘立刻’‘马上’‘投诉’等关键词，或者客户在 24 小时内重复提交了同一问题，则标记为高优先级。”这样条件就明确了，模型只需要做关键词匹配和计数，不需要做主观判断。

判断依据数据质量差的例子：根据“客户等级”字段决定处理优先级，结果这个字段在系统里有一半是空的。这种情况下，Agent 要么卡住，要么瞎猜。我的做法是在判断之前加一个数据校验节点：如果关键字段缺失，先走“补充信息”流程，把字段补全了再进入判断。宁可多一步，也不要让 Agent 在数据不全的情况下做判断。

3.4 等待和超时：流程不能无限期挂着

多步骤流程里有一个很容易被忽略的问题：某一步需要等人反馈，但人可能一直不反馈。比如工单派出去之后，处理组三天没动静。如果没有超时机制，这条流程就永远挂在那里，Agent 也不知道该干什么。

我的做法是给每个“等待类节点”设置超时时间，超时后触发一个“催办”动作。具体来说：

超时时间设多长，取决于具体业务。我的经验是宁可设短一点，催办比不催办好。催办最多让人觉得烦，但不催办可能导致整个流程卡死，后果更严重。而且催办动作本身也可以由 Agent 自动完成，不需要人盯着。

提示：超时机制一定要有“升级”路径。第一次超时发提醒，第二次超时抄送负责人，第三次超时转人工。不要让 Agent 无限次催办同一个人，那样只会让催办消息被忽略。

3.5 状态记录：让流程可追溯、可恢复

多步骤流程跑起来之后，最怕的是“不知道跑到哪了”。尤其是当流程数量多起来之后，如果没有状态记录，出了问题根本查不到原因。我的做法是每个节点执行完都写一条状态记录，记录内容包括：流程 ID、节点名称、执行时间、输入摘要、输出摘要、执行结果（成功/失败/等待中）、失败原因（如果有）。

这些记录不需要多复杂，一张表就够了。但有了这张表，你可以做很多事情：查某个流程当前卡在哪、统计每个节点的平均耗时、发现哪个节点最容易失败、在流程中断后从最后一个成功节点恢复。我实际用下来，这张表的价值远超预期——它不仅用于排错，还成了优化流程的依据。比如发现某个节点平均要等 20 小时，那就要考虑是不是这个环节本身设计得不合理。

4. 两个场景背后的共同基础设施

4.1 数据接入层：Agent 的“手”和“眼”

不管是信息聚合还是任务编排，Agent 要干活，首先得能“看到”数据、“摸到”系统。这一层我称之为数据接入层，它决定了 Agent 的能力边界。接入层做得好，Agent 能读能写；做得不好，Agent 就是个只会聊天的摆设。

我实际搭的时候，接入层主要处理三类东西：

• 读数据：从文档、表格、数据库、消息记录里读取内容。关键是统一读取接口，不管底层是什么存储，Agent 调用的方式是一样的。
• 写数据：往文档里写内容、往表格里填数据、往系统里发消息。关键是权限控制，Agent 只能写它该写的地方。
• 触发事件：定时触发、状态变更触发、消息触发。关键是触发条件要明确，不能模棱两可。

这一层不需要多先进的技术，但需要稳定。我见过一些团队用很花哨的方式做接入，结果三天两头断连，Agent 跑一半卡住，反而比人工还慢。我的建议是：接入层优先选成熟的、有文档的、社区活跃的方案，不要为了技术新颖而选冷门方案。

4.2 记忆与上下文：Agent 不能“做完就忘”

多步骤流程里，Agent 需要在不同节点之间传递信息。比如节点 B 提取了客户名，节点 D 生成工单时要用到这个客户名。如果 Agent 没有记忆，每个节点都从零开始，那它要么重复劳动，要么丢失信息。

我的做法是给每条流程实例维护一个“上下文对象”，所有节点读写都通过这个对象。上下文对象里存的是结构化数据，不是原始文本。比如存{customer_name: "张三", issue_type: "物流延迟", priority: "高"}，而不是存一整段聊天记录。这样做的好处是：节点之间传递信息时不会失真，而且方便做校验——如果某个节点发现customer_name是空的，可以立即触发补充信息的动作。

上下文对象还要有生命周期管理。流程结束后，上下文可以归档；流程中断后，上下文要保留，方便恢复。我通常会给上下文加一个过期时间，比如 30 天，过期后自动清理，避免存储无限膨胀。

4.3 人工介入点：什么时候必须让人来

Agent 再能干，也有它不该做决定的时候。我的原则是：涉及对外发送、涉及资金、涉及权限变更、涉及人事决策的环节，必须有人确认。其他环节可以尽量自动化。

人工介入点的设计，关键是让确认变得简单。如果确认流程很复杂——比如要登录某个系统、找到某个页面、填一堆字段——那大家就会抵触，宁可自己动手做。我的做法是把确认动作做到最简：Agent 把需要确认的内容整理好，通过大家日常用的渠道（比如聊天消息）发出来，确认人只需要回复“确认”或“修改：xxx”就行。确认动作越轻，大家越愿意配合。

还有一个经验：人工介入点不要设太多。我见过一个流程设了五个确认点，结果每个确认点都要等人，整个流程跑下来比人工还慢。我的建议是只保留最关键的确认点，通常是“对外发送前”和“不可逆操作前”这两个。

5. 实测下来最容易翻车的几个地方

5.1 模型“自作主张”补充不存在的信息

这是我在信息聚合场景里踩过的最大的坑。Agent 在生成周报时，发现某个任务的进展字段是空的，它没有标记“待补充”，而是根据任务名推测了一个进展填进去。结果周报发出去，负责人一看：“我根本没做这个，它怎么给我写上了？”

这个问题的根源是模型被训练成“尽量给出完整答案”，所以遇到缺失信息时倾向于补全而不是留空。解决办法是在提示词里明确要求：“如果某个字段没有明确来源，必须填‘待补充’，禁止推测或编造。”同时，在生成后的校验环节加一条规则：检查所有“待补充”字段是否被正确标记，如果发现模型填了内容但原始数据里没有对应来源，就拦截并报警。

5.2 流程跑一半卡住，但没有告警

多步骤流程最怕的是“静默失败”——某个节点出错了，但没有人知道，流程就停在那里。我遇到过好几次：工单派发出去了，但处理组没收到，因为消息发送接口返回了错误，但 Agent 没有把这个错误暴露出来。

解决办法是给每个节点加执行结果校验。节点执行完后，不仅要记录“执行了”，还要记录“执行结果是否符合预期”。比如发送消息后，要确认消息确实出现在目标渠道里；写入数据后，要确认数据确实写进去了。如果校验不通过，立即触发告警，通知相关负责人。告警渠道就用团队日常用的渠道，不要另建一套，否则没人看。

5.3 权限给太大，Agent 做了不该做的事

Agent 需要操作权限才能干活，但权限给大了风险很高。我见过一个案例：Agent 被授予了“删除文档”的权限，结果在清理临时文件时，误删了一个重要文档。虽然最后从回收站找回来了，但这件事让团队对 Agent 的信任度大打折扣。

我的做法是最小权限原则：Agent 只拥有完成当前任务所必需的最小权限。需要读文档就给读权限，需要写文档就给写权限，但删除权限默认不给。如果确实需要删除操作，走人工确认流程。另外，所有写操作都要有日志，方便追溯。

5.4 流程版本更新后，旧流程跑不通了

流程不是一成不变的。业务变了，流程也要跟着改。但改流程的时候，如果已经有流程实例在跑，就可能出现“旧实例跑到一半，发现节点已经变了”的情况。我遇到过：流程更新后，某个节点的输入字段名改了，结果正在跑的旧实例到这个节点时找不到字段，直接报错。

解决办法是流程版本化。每次修改流程，生成一个新版本，旧实例继续用旧版本跑完，新实例用新版本。这样虽然管理起来稍微复杂一点，但避免了“改流程导致在途实例全部失败”的问题。实现方式可以很简单：流程定义里加一个版本号，实例启动时记录当前版本号，执行时按实例记录的版本号加载对应的流程定义。

6. 从这两个场景往外延伸，还能做什么

这两个场景跑通之后，我发现很多其他办公场景其实是它们的变体。比如“会议纪要自动生成与派发”本质上是信息聚合（采集会议录音转文字、提取待办事项、分发到相关人）；“竞品动态监测”本质上是信息聚合（定时采集公开信息、去重、分类、生成简报）；“跨部门协作流程”本质上是多步骤编排（把涉及多个部门的审批、交接、确认串起来）。

我的建议是先把一个场景做深做透，再考虑扩展。不要一上来就搭一个大而全的平台，试图把所有场景都覆盖。我见过太多团队花几个月搭了一个“通用 Agent 平台”，结果每个场景都跑不通，因为每个场景的细节都不一样，通用平台反而什么都做不好。正确的做法是：选一个最痛、最重复、数据源最清晰的场景，把它跑通，跑稳，然后再看下一个场景能不能复用已有的节点和接入层。复用度越高，扩展成本越低。

还有一个延伸方向是把 Agent 的执行结果反哺回数据源。比如信息聚合场景里，Agent 生成的周报可以自动归档到知识库，下次有人问“上个月项目进展怎么样”，可以直接从知识库检索，而不需要重新采集。这样 Agent 不仅是一个“执行者”，还是一个“记录者”，长期来看价值更大。

最后分享一个我自己的体会：Agent 落地最大的障碍往往不是技术，而是信任。大家不放心把事交给 Agent，是因为怕它做错。所以前期一定要把“确认”和“留痕”做好，让每一次 Agent 的执行都有记录、都可追溯、都可回滚。信任是一点点建立起来的，等大家发现 Agent 做的事确实靠谱，自然就愿意把更多事交给它。这个过程急不得，但一旦跨过去，效率提升是实实在在的。