在聊天窗口中，单个Agent、单次对话以及几分钟内即可完成的任务，通常能够带来流畅的体验。然而，当任务持续时间延长至数小时，或者需要多个执行者协同作业，甚至在人中途离开再返回时，一系列问题便接踵而至：上下文信息分散在数百条消息中，难以迅速把握哪个任务正在执行、哪个在等待处理、哪个已经完成交付；精心调整的指令、技能以及与外部系统的连接，也往往仅保存在某个人的终端或账号内，难以实现复用与共享。

这些问题的根源，并非完全由模型能力所决定。

随着Agent从简单的“撰写一段文案”等轻量级工具，逐渐演变为能够承担持续数小时的调研、开发及数据分析等复杂任务的角色，对话窗口作为唯一任务承载形式的局限性便日益凸显。它固然适合进行沟通、讨论与探索，但在作为长程任务的唯一执行载体方面，却显得力不从心。

依赖聊天记录来追踪长任务，就如同仅凭工作群来管理整个项目：虽然能够交流，但难以持续、清晰地回答“谁在负责、当前进度如何、遇到了什么障碍、结果存放在哪里”等关键问题。

实际上，影响Agent能否成功完成任务的关键因素，并非仅仅是单轮Prompt的精准度，更在于从任务创建到最终交付的整个过程中，回路的设计是否合理。关键在于要让任务成为协作的核心，而非让任务状态仅仅依附于消息流之中。

今日，徽声在线科技Octo正式推出了Loop功能——一个以任务为中心的Agent协作新空间。它使得每一项工作都能成为一个具有明确目标、负责人、状态、执行过程及交付结果的独立任务：对话用于深入讨论与决策，而Loop则负责任务的推进、跟踪与最终验收。

PART 01 深入解析Loop：何为Loop？

Loop，本质上是一个以任务为核心的Agent协作空间。

踏入Loop的世界，工作便不再仅仅是聊天记录中的一条消息，而是转化为一个个拥有明确目标、负责人、状态、执行过程及交付结果的独立任务。这些任务可以灵活分配给团队成员、专家或专家团。专家/专家团在指定的运行时环境中执行任务，其状态、日志及结果均持续保留在任务之中。

一项任务在Loop中的推进路径通常如下：

· 创建与分配阶段：明确任务目标、背景、约束条件及验收标准，并设定负责人、所属项目、优先级及截止时间。

· 执行与记录阶段：专家依据自身的指令、技能及工具连接执行任务；执行状态、关键日志及结果均统一保存在任务之中。

· 求助与确认阶段：当遇到信息缺失、权限不足或需要人工判断时，任务进入“需要协助”状态；结果提交后则进入“待确认”状态，由人或接入Octo CLI的助理进行检查。

· 反馈与继续阶段：若结果不符合要求，人可补充明确意见，指导执行者继续处理；符合要求后，则确认任务完成。

Loop当前所提供的，是一条可追踪、可反馈、可持续的任务路径。它使得人能够清晰了解任务的状态（是否已开始、正在执行、等待确认或需要协助），同时也为团队维护专家配置、沉淀技能及复用工作方法提供了结构化的数据支持。

Loop与一次性对话的本质区别在于：对话承载的是讨论与决策过程，而Loop则承载的是从委托到验收的完整任务流程。

PART 02 对话与任务：各司其职，相得益彰

Loop能够承接从IM讨论中提炼出的工作任务，也可由人直接创建，或由自动化流程触发。

在对话中，团队成员可以首先明确目标、深入讨论分歧点。待讨论收敛后，再将其整理成任务：在任务描述中详细阐述目标、背景、约束条件及验收标准，选择负责人、所属项目、优先级及截止时间。若助理已接入Octo CLI并获得相应的工作区权限，也可由其整理对话上下文、创建任务并分配给专家或专家团。

任务创建后，便可在Loop中独立推进。任务详情中保存了状态、执行日志、评论、结果及附件等信息。预先配置完成回执或群消息推送后，还可将待确认、需要协助、失败等关键变化信息推送回IM，使人能够在原有的业务语境中继续判断，而无需一直守候在Loop页面。

参与Loop协作的角色主要分为三类：

01 助理：IM中的长期智能伙伴

在Octo的语境中，助理通常指的是接入IM、能够长期运行并保存用户语境的Agent。

它可基于OpenClaw、Hermes Agent等智能体框架构建。与主要用于执行单次任务的Runtime相比，这类Agent更注重长期记忆能力：它能够持续理解用户、团队及对话的历史背景，明确当前讨论的主题，并逐渐形成对用户工作方式的理解。

助理通常常驻于IM之中，是用户与Agent系统交互的入口。它可参与讨论、理解上下文，并在讨论收敛后，通过Octo CLI在Loop中创建任务、分配执行者、查询进度、读取结果及补充反馈。

它更像是一个位于Loop外部的委托者与编排者：在IM中理解用户需求，在Loop中通过CLI发号施令，再将任务结果带回原有的对话语境之中。

02 专家：Loop运行时中的任务执行者

专家是Agent接入Loop后所承担的任务执行角色。

当一个Agent被连接到运行时环境，并在工作区中配置为专家后，便可接收具体任务。它依据任务上下文、自身指令、技能及外部工具连接执行工作，并将状态、日志及结果保留在任务之中。Codex、Claude Code等执行引擎通常以这种方式接入Loop。

专家与助理的主要区别在于：

· 连接位置的不同

· 所获取上下文信息的差异

· 是否承担具体任务

· 以长期语境还是单次任务为工作中心

我们认为，专家更适合聚焦于当前任务的上下文来执行任务，而助理则更适合用来理解用户需求、整理需求并协调工作。当然，这并非系统上的硬性规定，用户也可将同一个Agent本体接入运行时环境，让其承担具体任务。

03 专家团：Loop内的任务组织机制

专家团并非一种全新的Agent类型，也不是多个Agent自动同时运行的广播机制。它是Loop工作区中的一种组织和路由对象。

当任务分配给专家团后，当前机制会首先将任务路由给领队。领队可查看专家团成员的角色和技能，再根据需要显式创建子任务、点名其他专家参与，并最终负责收束和交付结果。

总体而言，助理解决的是谁在IM中长期理解用户并从外部编排任务的问题；专家解决的是Loop中承担具体任务的执行者问题；而专家团则解决的是如何组织和协调多个任务执行者的问题。

在这一分工体系下，长程任务终于有了独立的承载空间。Loop将任务从对话中剥离出来，为其赋予了稳定的负责人、实时状态、完整日志及交付物。卡点在哪里、等待谁的输入、下一步该做什么，均有据可查，任务的推进不再依赖人在聊天记录中手动翻找。

专家能力也因此具备了维护和复用的坚实基础。部门可基于领域知识持续维护专家的指令、技能及外部系统连接，方法更新后，所有调用该专家的项目均可同步受益。个人调试出的优秀用法，也可转化为团队可复用的公共能力。

PART 03 Loop设计背后的深度思考

在研发Loop的过程中，我们进行了以下几点深入思考：

01 定义目标，而非路径

传统拖拽式Workflow的思路是在任务开始前就规划好每一步。其前提是人能够提前想清楚任务可能经过的所有路径，但真实工作往往会偏离预设流程。

Loop更强调先定义目标、约束条件及验收标准。

专家在指令和权限范围内规划执行路径、调用工具并提交结果。遇到真正需要人判断的事情时，再进入“需要协助”或“待确认”状态，由人补充条件后继续执行。

但这并不意味着执行路径完全不受约束。高风险动作、外部写入、生产操作及不可逆决定等，仍需明确的权限边界和人工确认。Loop提供的是更灵活的执行空间，而非取消所有约束。

02 人是品鉴者，而非监工

“如果人不盯每一步，怎么知道任务没在悄悄跑丢？”这是我们被问得最多的问题。

我们的回答并非“AI足够可靠，所以大可放心”。恰恰相反，Loop假设Agent会卡住、会出错、会遇到处理不了的情况。系统要做的是让这些状况尽早暴露，而非悄无声息地埋在聊天记录里。每个任务都有明确的负责人、任务状态及交付物，Webhook可将状态变化主动推送到IM之中。

这背后是我们对人在协作中位置的理解：人是品鉴者，而非监工。追着Agent问进度不应是人的工作，Loop希望将人的注意力引导到需要判断的地方。

03 任务是接力棒，而非待办清单

另一个容易产生的误解是将Loop视为加了AI的项目管理工具。二者看起来都有任务、状态及负责人，但本质完全不同。

传统项目管理软件记录的是“谁应该做什么”，它是一个待办清单，任务创建后，人去执行，软件本身不产生结果。而Loop管理的则是人和Agent组成的协作系统。任务派出去后，专家作为执行者会接单、调用工具、产出结果，遇到问题带着请示回来，人拍板后继续执行，最终将结果交给人验收。

目前，Loop已在Octo正式上线。企业用户完成以下操作即可使用：

在「我的」中添加电脑 → 注册运行时 → 接入正在使用的执行引擎 → 配置专家的指令和技能，即可开启Loop协作新篇章。

更多产品功能，我们将在后续版本中逐步推进与完善。