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