过去几年，AI 在企业里的落地路径基本遵循一条线：先做问答，再做助手，然后尝试进入工作流。三个阶段对应三种不同的产品形态，也对应三种不同的人机关系。

第一阶段是 FAQ 机器人。用户输入关键词，系统匹配答案。这类产品解决的是信息检索问题，谈不上协作。

第二阶段是 ChatBot，以对话为核心，LLM 驱动，能理解上下文，能生成内容。用户把 ChatBot 当作一个随时在线的顾问，问什么答什么。

问题出在第三阶段。当企业想把 AI 从"问答窗口"搬到"工作现场"，让 AI 真正参与项目推进、任务交付、流程协同，ChatBot 这套范式开始显露局限。

对话模式的天花板

ChatBot 的交互模型很简单：一轮对话，一个回答。用户提出问题，AI 给出回复，交互到此结束。这个模型在信息获取场景下够用，放到工作场景里就缺了几块拼图。

工作不是单次问答。一个产品需求从提出到上线，中间经历需求评审、设计、开发、测试、验收多个环节。每个环节有输入、有输出、有交付标准。

ChatBot 没有"任务"的概念，它不知道你让它写的那段代码是要放进哪个模块，也不知道上次评审里 PM 提了什么修改意见。另一个问题是身份缺失。

在 ChatBot 模式下，AI 是一个匿名的应答器。你的团队里有产品经理、有设计师、有后端工程师，每个人有自己的职责和工作记录。

AI 呢？它没有工号，没有名片，没有工作档案。你没法说"这个需求让 AI 去跟"，因为它在组织结构里根本不存在。

从"助手"到"同事"，中间差了什么

把 AI 定位为助手（Assistant），隐含的假设是：人来决策，AI 来执行辅助。人告诉 AI 做什么，AI 做完交回来。这个关系里，AI 没有主动性，也不承担交付责任。"同事"的含义不同。同事有自己的工作范围，会主动推进任务，交付成果要接受评审，做得不好要打回重做。同事之间通过频道沟通，通过事项追踪进度，通过工作记录追溯责任。

如果 AI 要成为"数字同事"，至少需要几个基础设施支撑：

身份系统。 AI 需要一个可辨识的身份，标明它的能力范围、归属关系、工作历史。这不是技术细节，是协作的前提。在 Octo 的设计里，每个 AI 实体叫做 Bot，附带一张 AgentCard 名片，写明擅长什么：代码生成、数据分析、文档翻译、UI 设计。谁创建了它，它就替谁干活，继承创建者的部分权限。

工作频道。 人和 AI 需要一个共同的沟通空间，不是私聊窗口，而是团队协作频道。频道里有其他人，有其他 Bot，对话可见，进度可追踪。

事项管理。 对话中产生的任务需要有地方沉淀。一个需求讨论完，变成可追踪的 Matter，有状态、有负责人、有交付时间。

数字分身：替身而非工具

"数字分身"比"数字同事"往前走了一步。同事是协作关系，分身是代理关系。一个典型场景：市场总监创建了一个 Bot，把自己的工作偏好、沟通风格、审批标准都沉淀进去。这个 Bot 可以代替总监做初步的内容审核，按照总监的品味给出修改意见。

总监不需要事事亲力亲为，Bot 先过滤一轮，把需要人工判断的部分挑出来。这里涉及一个关键机制：品味沉淀。传统 AI 工具没有"记忆"，每次对话从零开始。数字分身需要积累创建者的偏好，包括验收标准、打回原因、风格倾向。这些信息形成偏好卡片，Bot 在后续工作中自动参考。Octo 把这套机制叫做 Taste 系统。验收、打回、批注，每个动作都在训练 Bot 的品味。时间越长，Bot 越了解你的标准，交付质量越稳定。这不是微调模型，是在应用层建立一套持续的偏好反馈回路。

类似的理念在端侧 AI 领域也有体现。Mano-P 是一个纯视觉驱动的 GUI Agent，跑在本地设备上，数据不出本机。它不需要你每次描述操作步骤，通过视觉理解界面元素，自主完成任务。这种"理解上下文、自主执行"的能力，和数字分身追求的"理解偏好、代理工作"有异曲同工之处。

多 Bot 协作：组织级的 AI 编排

单个 Bot 解决个人效率问题，多个 Bot 协同才能解决组织效率问题。一个产品迭代流程里可能同时出现几个角色：需求分析 Bot 负责拆解用户故事，代码审查 Bot 负责 Review PR，测试 Bot 负责跑回归测试，文档 Bot 负责更新 Changelog。这些 Bot 之间需要协调，需要有人（或有机制）来编排它们的工作顺序和交互方式。Octo 提供了六种协作模式，覆盖常见的团队协同场景：

• Solo：单 Bot 独立完成任务-
• Roundtable：多个 Bot 围绕议题轮流发言-
• Critic：一个 Bot 产出，另一个 Bot 审核-
• Pipeline：Bot 串联成流水线，上游输出作为下游输入- Split：大任务拆分给多个 Bot 并行处理-
• Swarm：Bot 群组动态协作，按需调度每种模式对应不同的工作拓扑。选择哪种取决于任务性质：需要深度讨论用 Roundtable，需要质量把关用 Critic，需要规模化处理用 Split 或 Swarm。

开放、上下文、品味、编排：O.C.T.O. 的设计哲学

回过头看 AI Agent 在工作场景中的角色变化，从工具到助手，从助手到同事，从同事到分身，每次跃迁背后都是基础设施的升级。

Open：开放接入，不绑定特定 AI 厂商，支持私有部署。企业的数据在自己的服务器上，不被锁定。

Context：共享上下文。所有 Bot 共用同一套项目背景、团队信息、工作历史。Bot 之间不存在信息孤岛。

Taste：偏好进化。验收、打回、批注这些日常动作自动沉淀为偏好卡片，Bot 的交付质量随时间推移持续提升。

Orchestration：多 Bot 编排。从单兵作战到团队协同，覆盖完整的组织协作图谱。这四个维度合在一起，构成了 AI 从"聊天工具"走向"工作成员"的技术底座。

工作场景里 AI 的角色还会继续变

眼下的变化已经足够显著：AI 从对话框走进了工作流，从匿名工具变成了有身份的数字同事。但这条路还远没走完。下一个阶段可能出现的变化包括：Bot 之间自发形成分工默契，不需要人来编排；偏好系统从个人层面扩展到团队层面，整个部门共享一套工作标准；Bot 的工作记录成为组织资产，新人入职直接继承前任 Bot 的经验和偏好。这些方向目前在 Octo 的设计路线图中都有涉及。如果你对 AI 在工作场景中的角色演进感兴趣，可以去 GitHub 看看这个项目的进展。