过去一年多 Agent 产品密集发布，一个容易被忽略的工程细节逐渐浮出水面。大多数团队在 IM 群聊里引入 AI 之后，产出物散落在消息流中难以追溯，每开一个新对话窗口就要重复交代背景和偏好，Agent 交付的初稿和最终版本之间缺少结构化的关联，反馈信号无法沉淀为可复用的记忆。问题不在于模型能力不够，而在于现有协作工具的工作单元边界是为人与人沟通设计的，AI 进入之后这套边界不再适用。

消息流是线性的，工作是结构化的

IM 工具的信息组织方式是时间轴，所有参与者共享同一条消息流，按发送顺序排列。人类在这种环境里能自然协作，因为人具备主动过滤噪音、归拢上下文、在脑内维护任务状态的能力。群聊跑题到午餐再绕回正题，人能跟上；第 5 条消息提出的需求在第 45 条被补充，人记得住。

AI Agent 接入群聊之后这套机制开始失效。Agent 依赖上下文窗口理解任务，对话过长时早期消息的权重会降低或被截断，需求和补充说明之间的关联容易断裂。Agent 的产出以消息形式回传，混在数十条甚至上百条其他消息中，几天后查找需要滚动浏览。当交付结果不达标被打回，修改意见作为普通消息发出，与具体产出物之间没有强制链接，新开对话时 Agent 无法获知之前的反馈，同样的问题会重复出现。

传统工单系统对此提供了一套解法。Jira、Linear、飞书任务等工具要求用户先创建任务卡片，填写标题、描述、负责人、截止时间等字段，后续讨论和交付围绕卡片展开。这套流程在人与人协作中运转多年，但引入 AI 后产生了新的摩擦。创建卡片需要从对话语境切换到表单界面，把已经在聊天中说过的需求重新填写一遍；表单字段是固定的，而 AI 可以承接的任务类型跨度极大，从代码生成到数据分析到文档撰写，统一字段要么覆盖不全要么大量留空，填写成本高且信息密度低。

Loop 回路作为对话与任务之间的映射层

OCTO 在产品设计中引入了 Loop 回路的概念来处理这层映射。回路和工单的差异不在于功能列表的长短，而在于信息进入结构化状态的时机。工单要求先结构化再执行，用户必须在开始工作之前填完所有字段；回路允许结构在执行过程中逐步成型，任务可以从一句自然语言描述中发起，随着工作推进逐步补充细节、调整目标、拆分子任务。

发起一条回路有两种途径。手动创建时填写目标和验收标准，指定负责人；自然语言发起时在工作区中直接描述意图并指定承接的智能体，回路创建后智能体即刻开始执行。自然语言发起的交互成本与发送一条普通消息相当，区别在于系统将该消息标记为任务起点，后续围绕该任务的讨论、产出和反馈会自动归集到回路下，而非散落在消息流中。

一条完整回路包含几个固定组成。负责人字段可以指定给人或智能体；交付物包括代码、文档、报告等，统一挂载在回路内而非以消息形式存在；验收环节由发起人完成，通过即标记完成，不通过则写明原因打回，打回意见被记录为过程的一部分；过程记录覆盖从初始需求说明到中间讨论、各版本产出、反馈意见和最终验收结论的全链路，以时间线串联，支持事后追溯决策依据。

7 月版本更新后，回路支持多级子任务拆解和计划视图。复杂任务可以拆分后分派给不同的负责人或智能体，计划图呈现各分支进度，迭代记录标注每轮修改的内容和原因。

验收闭环是经验沉淀的前提

6 月及更早版本的 OCTO 回路处于记录型闭环阶段，流程为创建、指派、讨论、关闭，执行工作由人完成，系统承担记录职责。这一阶段 AI 的定位是辅助工具，用户在对话中要求 Agent 生成内容，结果以消息形式返回，由用户自行取用和判断。该模式在实际使用中暴露出一个信号断层，Agent 输出初稿后，用户往往会做大量修改再交付，但 Agent 无法获知修改内容和修改原因，反馈链路中断，每次交互都相当于从零开始。

7 月版本将回路升级为执行型闭环，流程调整为创建任务、指派智能体、自动执行、人工验收。新增能力的核心不在自动执行本身，而在验收环节的结构化。智能体将产出提交至回路后，发起人在回路内直接验收，通过则标记完成，不通过则打回并标注具体问题。每次打回的反馈成为经验素材，承接该回路的智能体在后续接收同类任务时会自动参考历史反馈。

经验在 OCTO 中以 Preference 卡片的形式存储。每张卡片包含行为规则、来源证据即某次验收的具体反馈、适用范围和置信度，采用服务端存储，不绑定特定模型或运行时，更换模型或设备后已积累的经验仍然可用。设计思路参考了卢曼卡片盒方法，卡片之间支持引用和组合，智能体接收任务时系统根据关键词和适用范围自动检索相关经验注入上下文。用户在验收时指出结论应置于开头而非结尾，这条反馈会被蒸馏为一张经验卡，下次同类任务自动生效；更换智能体后经验可迁移，无需重复说明偏好。

执行层的模块支撑

执行闭环的运转依赖后台多个模块的协同。目前已上线的包括回路工作台的列表和看板视图、统一工具条和详情面板，详情面板内集成子任务树、迭代记录、评审打回和计划图操作；项目分组功能支持将相关回路归类管理，成员和智能体挂载在项目层级；Autopilot 自动化模块支持定时触发和事件触发的智能体流水线，可配置触发条件和执行步骤，满足周期性和事件驱动的任务需求；搜索模块支持跨回路和跨项目的快速检索。

智能体管理模块处于 V1 开发阶段，上线后将支持在管理界面配置智能体的系统指令、技能挂载、运行时绑定和运行统计。运行时模块同样在 V1 开发中，智能体的执行环境支持用户通过本地 CLI daemon 注册自有设备，也支持云端运行时，平台负责注册管理、健康检查和状态监控，不绑定特定运行时实现，兼容 OpenClaw、Codex、Claude Code、Hermes 等多种 Agent 运行环境。工作区组队功能也在 V1 开发中，完成后可从空间通讯录选择成员和智能体组建工作区，回路从工作区继承常驻资源，无需每次任务重复指定。

技能市场和 A2A 路由属于规划中的功能。技能即可复用的提示词包，支持挂载至智能体，也支持从 Skills/MCP 市场导入。A2A 路由处理多智能体协作场景下的任务分配问题，领队智能体通过 AgentCard 获取其他智能体的能力信息，据此将子任务路由至最合适的智能体执行。

模块上线遵循明确的优先级。V1 阶段优先完成执行闭环，即任务可创建、智能体可指派、执行可进行、结果可验收；经验沉淀的规模化召回和 A2A 自动路由等增强能力在执行闭环稳定后逐步叠加。

从工程视角看，回路解决的核心问题是为 AI Agent 在协作流程中提供一个结构化的工位。这个工位需要承接对话中自然产生的任务意图，承载从执行到验收的完整链路，将每次验收反馈转化为可复用的经验资产，支持跨时间的决策追溯。AI 协作工具的长期价值不取决于接入模型的数量，而在于每次协作产生的信息能否以可追溯、可复用的形式沉淀为组织资产，回路是承载这些资产的基础结构。

OCTO 目前处于定向邀请内测阶段，面向企业团队开放。多智能体协作方向的工程实践和组件开源进展可通过 github.com/Mininglamp-AI 组织下的项目跟踪，执行层模块稳定后将逐步开放更多组件。