单个 Agent、单次对话、几分钟跑完的任务在聊天窗口里体验顺畅。但当任务拉长到数小时、需要多个执行者协作或者人要中途离开再回来时问题就出现了上下文散在几百条消息里哪个任务正在执行、哪个在等人、哪个已经交付很难一眼看清调好的指令、技能和外部系统连接也常常只留在某个人的终端或账号里难以复用。这些问题不只由模型能力决定。当 Agent 从“写一段文案”的轻量工具走向持续数小时的调研、开发和数据分析对话窗口作为唯一承载形态的局限就会显现。它适合沟通、讨论和探索却不适合作为长程任务的唯一执行载体。用聊天记录追踪长任务就像只靠工作群管理项目能聊但很难持续回答“谁在负责、现在到哪、卡在哪里、结果在哪”。真正影响 Agent 能不能把事情做成的不只是单轮 Prompt而是任务从创建到交付之间的回路怎样设计。需要让任务成为协作的中心而不再让任务状态依附于消息流。近日明略科技Octo正式上线Loop功能 —— 一个以任务为中心的Agent协作空间。它让一件工作成为有目标、有负责人、有状态、有执行过程和交付结果的独立任务对话用于讨论和决策Loop 用于推进、跟踪与验收。Octo 仓库地址https://github.com/Mininglamp-OSSLoop是什么Loop 是一个以任务为中心的 Agent 协作空间。进入 Loop 后工作就不再只是一条埋在聊天记录里的消息而会成为一个个有目标、有负责人、有状态、有执行过程和交付结果的独立任务可以分配给成员、专家或专家团。专家/专家团在指定运行时中执行状态、日志和结果持续留在任务中。一项任务通常沿着下面的路径推进· 创建与分配写清任务目标、背景、约束和验收标准并设置负责人、项目、优先级和截止时间。· 执行与记录专家依据自身的指令、技能和工具连接执行任务执行状态、关键日志和结果统一保存在任务中。· 求助与确认缺少信息、权限或人工判断时任务进入“需要协助”结果提交后进入“待确认”由人或接入 Octo CLI 的助理检查。· 反馈与继续如果结果不符合要求人可以补充明确意见让执行者继续处理符合要求后确认任务完成。Loop 当前提供的是一条可追踪、可反馈、可继续的任务路径。它让人能够看见任务的状态是已经开始、正在执行、等待确认还是需要协助同时也为团队维护专家配置、沉淀技能以及复用工作方法留下结构化原料。Loop 与一次性对话的区别在于对话承载讨论Loop 承载从委托到验收的完整任务过程。对话归对话任务归任务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将任务从对话中剥离出来为它赋予稳定的负责人、实时状态、完整日志和交付物。卡点在哪里、等待谁的输入、下一步做什么都有据可查任务的推进不再依赖人在聊天记录里手动翻找。专家能力也具备了维护和复用的基础。部门可以基于领域知识持续维护专家的指令、技能和外部系统连接方法更新之后所有调用这个专家的项目同步受益。个人调试出来的好用法变成团队可复用的公共能力。一些设计上的思考在研发Loop的过程中我们有几点思考01 定义目标不定义路径传统拖拽式 Workflow 的思路是在开始之前把每一步画好。它的前提是人能够提前想清楚任务可能经过的所有路径但真实工作经常会偏离预设流程。Loop 更强调先定义目标、约束和验收标准。专家在指令和权限范围内规划执行路径、调用工具并提交结果。遇到真正需要人判断的事情再进入“需要协助”或“待确认”由人补充条件后继续。但这并不意味着执行路径完全不受约束。高风险动作、外部写入、生产操作和不可逆决定仍然需要明确的权限边界和人工确认。Loop 提供更灵活的执行空间而不是取消约束。02 人是品鉴者不是监工如果人不盯每一步怎么知道任务没在悄悄跑丢这是我们被问得最多的问题。我们的回答并不是“AI足够可靠所以大可放心”。恰恰相反Loop 假设 Agent 会卡住、会出错、会遇到处理不了的情况。系统要做的事情是让这些状况尽早暴露而不是悄无声息地埋在聊天记录里。每个任务有明确的负责人、任务状态、交付物Webhook 可以把状态变化主动推送到 IM。这背后是我们对人在协作中位置的理解人是品鉴者不是监工。追着 Agent 问进度不该是人的工作Loop 希望把人的注意力引导到需要判断的地方。03 任务是接力棒不是待办清单另一个容易产生的误解是把 Loop 当成加了AI的项目管理工具。二者看起来都有任务、有状态、有负责人但本质完全不同。传统项目管理软件记录的是“谁应该做什么”它是一个待办清单任务创建后人去执行软件本身不产生结果。Loop 管理的则是人和Agent组成的协作系统。任务派出去之后专家作为执行者会接单、调用工具、产出结果遇到问题带着请示回来人拍板之后继续跑最终把结果交给人验收。目前Loop已在Octo正式上线。企业用户完成以下操作即可使用在「我的」中添加电脑 → 注册运行时 → 接入正在使用的执行引擎 → 配置专家的指令和技能即可开始使用。更多产品功能我们将在后续版本中逐步推进。Octo 仓库地址https://github.com/Mininglamp-OSS