文章摘要
Agnes AI

我们习惯于把聊天工具看成沟通软件：打开微信，是为了回复消息；进入 Teams，是为了参加讨论；使用 QQ，是为了联系某个人或加入某个群。

但工作本身早已大量发生在聊天里。

“这个问题今天看一下。”

“下周准备上线。”

“你先整理一版。”

“会议结束后把结果发群里。”

这些句子没有使用任务管理系统的固定格式，却已经包含了目标、时间、负责人和下一步行动。聊天记录表面上是一串消息，实际上也可能是一份不断变化的工作安排。

因此，一个值得继续观察的方向是：聊天工具会不会逐渐成为新的工作入口？

这里的“入口”不只是让 AI 在聊天里回答问题，而是让 AI 从对话中理解工作，识别任务，在确认边界之后连接后续的执行流程。

从自动回复到工作协作

早期的聊天 AI 往往可以抽象成这样一条链路：

1
收到消息 -> 调用模型 -> 生成回复 -> 发回聊天窗口

这条链路适合问答和简单客服，却不太适合真实工作。因为真实工作首先要解决的不是“怎么回答”，而是几个更基础的问题：

  • 这条消息是在闲聊，还是在布置工作？
  • 任务是明确指派给谁，还是只是讨论中的一个建议？
  • 截止时间和完成标准是什么？
  • 是否需要用户确认之后才能开始？
  • 后续执行需要访问哪些文件、系统或外部服务？

如果 AI 直接把每条消息都当成任务，结果很快就会变得不可控。它可能把一句讨论当成承诺，也可能在没有确认的情况下替用户接受安排。

更合理的未来工作流，也许会是：

1
2
3
4
5
6
7
8
9
聊天消息
    -> 识别工作意图
    -> 合并上下文
    -> 提取任务和时间节点
    -> 确认责任与权限
    -> 生成执行计划
    -> 调用工具执行
    -> 校验结果
    -> 在聊天中回报进度

这时，聊天工具不再只是 AI 的输出界面，也成为 AI 获取工作上下文的入口。

一项工作通常分散在多条消息里

聊天中的工作安排很少一次说完。比如一个项目群里可能出现这样的对话：

1
2
3
4
成员 A：这个需求下周要上线。
成员 B：接口今天先联调。
成员 C：部署脚本还没有整理。
成员 A：周五下午统一验收。

单看任何一条消息，都很难说它是一项完整任务。把它们放在一起，才会形成一个相对清晰的工作上下文：

1
2
3
4
5
6
项目：某业务系统上线
时间节点：周五下午验收
当前阶段：接口联调
风险：部署脚本尚未整理
潜在下一步：准备部署脚本并完成上线前检查
状态：待确认

未来的 AI 可能会在这里承担一种“工作上下文整理器”的角色。它不一定马上做出决定，而是把分散的信息先组织起来，提示用户确认：

1
2
3
4
我从项目群中识别到一项可能需要你跟进的工作：
在周五验收前准备部署脚本并完成上线前检查。

是否将它加入工作任务？

这一步很重要。识别到任务，不等于已经获得执行授权；看见安排，也不等于可以替用户答应安排。

任务需要一种统一的中间表示

如果未来要让微信、QQ、Teams 共用一套 AI 工作流，第一步可能不是分别编写三套提示词，而是把不同平台的消息转换成统一结构。

例如：

1
2
3
4
5
6
7
8
9
10
11
@dataclass
class NormalizedMessage:
    platform: str
    conversation_id: str
    message_id: str
    sender_id: str
    sender_name: str
    text: str
    timestamp: datetime
    mentions: list[str]
    reply_to: str | None

在此基础上，AI 可以进一步生成任务对象：

1
2
3
4
5
6
7
8
9
10
11
12
{
  "title": "准备部署脚本",
  "description": "在验收前完成上线准备，并整理脚本",
  "assignee": "待确认",
  "requester": "成员 A",
  "deadline": "周五下午",
  "acceptance_criteria": ["脚本可运行", "完成本地验证"],
  "source_platform": "teams",
  "source_conversation": "项目群",
  "status": "pending",
  "confidence": 0.78
}

任务对象并不一定要立即进入某个正式的项目管理系统。它也可以先作为 AI 的工作记忆，等待用户确认，再进入下一阶段。

聊天平台可能扮演不同角色

不同平台的开放能力并不一样，这会直接影响未来的工作形态。

微信：日常工作上下文的入口

微信公众号和服务号提供了正式的服务端 API，包括 Access Token、消息回调、客服消息、模板消息和订阅通知等能力。相关接口可以在微信开放文档中查看。

但这不等于微信个人号也有同样的公开能力。个人聊天往往只能通过本地数据读取、桌面自动化或其他受限方式接入，稳定性、合规性和可维护性都需要单独评估。

也许微信更适合承担“发现日常安排”的角色：从项目群、同事私聊和临时讨论中收集上下文，再把确认后的任务交给后续系统。

QQ：社群和轻量协作的入口

QQ 机器人平台提供了官方 Bot 接入方式，开发者可以使用 AppID、AppSecret 和 Access Token，并通过事件订阅与消息接口参与群聊、频道和单聊。QQ 机器人官方文档已经提供了启动接入和 SDK 参考。

它可能更适合社群、兴趣组织和轻量协作场景。AI 可以在群内识别活动安排、资料收集和简单分工，再通过私聊或任务系统继续推进。

Teams：企业工作流的执行入口

Teams 的 Bot 和 Agent 文档把一对一聊天、群聊和频道区分开来。频道和群聊通常只向 Agent 提供被 @mention 的内容，一对一聊天则更适合问答、记录和触发其他系统。Microsoft Teams Agent 文档对此有详细说明。

Teams 还支持 Bot、Microsoft Graph、Adaptive Cards 和 Workflows。通过 Webhook 接入外部事件时，需要注意消息大小、请求频率和重试行为。官方文档也提示，新的 Microsoft 365 Connector 正逐步退出，新的集成更适合采用 Workflows。Incoming Webhooks 文档

因此，Teams 可能更接近“工作执行入口”：任务确认之后，AI 可以继续查询项目资料、创建记录、触发自动化流程，并把结果通过卡片或消息返回给团队。

一个正在形成的 AI 工作流

我在本地的 chat-sys-workspace 中做过一个微信聊天数字分身原型。它目前主要验证了几件事：

  • 从本地聊天记录读取消息和会话上下文。
  • 识别当前聊天中的话题线程。
  • 通过规则和模型判断是否应该回复。
  • 使用历史消息作为语气参考，生成候选回复。
  • 通过预览或桌面 UI 完成发送，并保存处理记录。

它当前的主要流程大致是：

1
2
3
4
5
wechat-cli / 微信窗口识别
    -> Conversation Analyzer
    -> Social Supervisor
    -> Reply Generator
    -> 预览或发送

这套设计里已经有一个很有价值的原则：先判断是否应该参与，再决定说什么。

如果继续向工作场景扩展，可能会出现另一条分支：

1
2
3
4
5
6
7
8
9
聊天消息
    -> Conversation Analyzer
    -> Task Extractor
    -> Work Context Builder
    -> Task Supervisor
    -> Planner
    -> Executor
    -> Result Verifier
    -> Progress Reporter

普通聊天仍然走原来的回复流程；包含工作安排的消息，则可能进入任务流程。两者共享消息读取、上下文管理和审计能力，但不应该混在一起处理。

AI 执行工作时，确认仍然是关键步骤

未来的 AI 可能会越来越擅长执行，但“能够执行”不代表“应该直接执行”。尤其是下面这些动作，通常需要明确确认：

  • 替用户接受一项新的工作安排。
  • 向同事承诺交付时间。
  • 修改代码、文档或生产配置。
  • 创建工单、日历事件或外部记录。
  • 发送带有个人信息、商业信息或敏感内容的消息。
  • 提交、发布、删除或支付。

一种可能的状态流转是：

1
2
3
4
5
6
7
8
detected       已识别
pending        待确认
accepted       已接受
planned        已规划
in_progress    执行中
blocked        被阻塞
review         待检查
done           已完成

AI 可以自动完成“识别”和“建议”，但在进入 accepted、in_progress 或对外发送之前，需要根据任务风险设置不同程度的人机确认。

进度回报可能重新回到聊天里

如果任务从聊天中产生，进度也许不必完全依赖另一个任务管理界面。AI 可以在原来的对话中回报：

1
2
3
4
5
6
任务已确认，当前进度：

- 已找到现有构建脚本
- 已整理 Windows 启动步骤
- 正在执行本地验证
- 验证完成后再提交变更

完成后则可以给出更明确的结果：

1
2
3
4
5
6
任务已完成：

- 已整理部署脚本
- 已完成本地构建验证
- 已记录变更说明
- 是否提交到远程仓库，等待确认

这样，聊天工具就不只是任务的来源，也成为任务状态的反馈界面。

仍然存在的边界

这种未来工作形式并不是把所有聊天都交给一个全自动机器人。至少还有几个问题没有简单答案：

  1. 如何区分正式指派、随口建议和普通讨论？
  2. 多个群聊中的同一项任务如何合并？
  3. “周五前”到底对应哪个时区和具体时间？
  4. AI 能读取多少聊天历史，哪些内容不能离开本地？
  5. 任务执行失败时，由谁负责判断下一步？
  6. 如何避免 AI 在群聊中过度发言或重复汇报？
  7. 不同平台的机器人权限和数据保留规则如何统一？

这些问题说明，聊天 AI 的核心难点仍然不是语言生成，而是上下文、权限、责任和可验证性。

结语：聊天工具可能成为新的工作入口

未来的 AI 也许不再只是一个需要主动打开的聊天窗口。它可能存在于工作群、项目讨论和日常消息之间，持续理解上下文，发现任务，整理安排，在合适的时候向人确认，然后连接到文件、代码、日历、工单和自动化工具。

这还不是一个已经确定的产品形态，更像是一种正在形成的工作想象。

我的本地项目目前只验证了其中一部分：如何读取聊天、识别话题、判断是否参与，以及生成一条合适的回复。下一步更值得探索的，也许不是让回复更像真人，而是让 AI 能够从聊天中理解工作，在明确边界之后参与执行。

如果这个方向成立，那么微信、QQ、Teams 等聊天工具的角色可能会发生变化：它们不再只是沟通软件，而会逐渐成为人和 AI 共同进入工作的第一扇门。